原価低減

「原価低減」って「原価」と「低減」という一般的な単語の組み合わせですが,自動車業界では特別な意味を持つ言葉のようです.大手メーカーが下請けに納入させる部品を継続的に値下げさせる契約です.

何年か前にどこかのテレビ局の番組で知りました.その時の取材の例では2年で1%とかいう話だったと思います.悪質なのは,それが元請け(=大手メーカー)から下請けへの一方的な要請(強要)ではなく,双方で話し合って決めた形にしているところです.

誰が考えたって,実質的には大手の優位な立場を利用した下請いじめです.

大手メーカーは空前の売上・利益を上げ続けてきました.

昨今の「賃上げ」「価格転嫁」の趨勢の中でこの原価低減はどうなったのか気になっていました.NHKでは報じませんでしたが,昨日のテレビ東京で,大手自動車メーカーは今後も今まで以上に続けると明言していました.

自分たちは過去最高の利益を上げるが下請けへは納入品の値下げを続けさせる.下請けはどうやって賃上げすりゃいいんでしょう.

そんな大手自動車メーカーから企業献金を受けている現与党の党首(総裁)で首相のおじさんは,企業献金が政策決定を歪めたことは一切ない,とこれまた見え透いた嘘をついています

大企業が見返りのない献金などするはずはない,と多くの識者が語っています.

投資はギャンブルではないよ教

ある程度確率・統計を学び,世の中は因果律に支配されていることを念頭に生きて,日頃の国内外の政治,経済などのニュースもある程度追いかけていれば,「投資はギャンブルだ」ということが自然と結論として出てきます

ところがどっこい.「投資はギャンブル」でネット検索すると,「投資はギャンブルではない」という記事がずらりとヒットします.投資はギャンブルではない原理主義の宗教が蔓延しているかのようです.

バカバカしいけどいくつかの記事を斜め読みしたところ.

  • 投資とギャンブルは元本保証でなく最終的に “自己責任” (という本質)は同じ
  • 社会貢献している将来有望な会社への投資は間接的な社会貢献

なんてことが書かれています.そう,本質は同じなんです.また2番目は重大問題ですね.競馬,競輪,競艇,オートレースファンは馬の魅力や騎手や選手たちの人柄や将来性に賭ける人も少なくないです.そうした公営ギャンブルファンを敵に回しています.

こんなことまででっち上げないと差別化ができないということなのでしょう.

逆に民間企業がうちは社会貢献しています,人材育成していますと自称したところでその裏まで取って投資している人はどれだけいるんでしょうか.

FXやバイナリーオプションに至っては,誰が見ても危険なギャンブルです.

また,一番納得いかないのは巨大地震など大規模災害に対する投資のリスクを「ないよ教」のサイトが詳しく説明していないところです.AI投資などはある程度は加味していると思いますが,それでもリスクを科学的に言われている水準まで上げるとリスクが勝ってどこにも投資できなくなると思います

投資はギャンブルだと割り切って無理なく投資する(=賭ける)のが大事だと思います.

ギャンブルは期待値1未満

そうは言ってももともと売上から胴元(公営ギャンブル主催者)の取り分を取ってから払戻金を分配する公営ギャンブルに対して,投資は得した人損した人を平均すれば元本+αになる可能性が高いので別物でしょう,って筆者もずっと考えていました.その考えを変えたのが,この最高裁判決です.

外れ馬券が必要経費に当たるという判断は常識的に考えれば当たり前の話で,特に画期的とは思いませんが,関連のニュースでこの被告は自作のソフトで馬券を購入して経常的に利益を得ていたということを知って驚きました

以後競馬は投資の対象になり得ると確信していますし,似たような投票システムの公営ギャンブルには皆その可能性があると思います.

一方で投資にもFXのようにギャンブル性が高いものもあります,というかそれこそギャンブルそのものです😅

また期待値が1未満かどうかがギャンブルと投資の違いとすると,長らく低迷していた日本の株,外貨や暗号資産など,短期・中期的には期待値が1にならない状態が多々あります

投資の経験則

  • 金持ちは投資で儲けるが貧乏人は投資しても大して儲からないか損をする
  • 金持ちは大損したら補填されるが貧乏人は全部自己責任
少なくとも投資とギャンブルに明確な境界線はない,と.
いや,それでもできてない😅
南海トラフ地震は向こう30年以内に70〜80%,首都直下地震は同じく70%.
金融証券会社にしてみれば,リスクを過小評価しても最後は「自己責任」で逃げられます
期待値は1未満.
最高裁判事にも常識があったというところが画期的かもしれません😅
合法的に利益を上げ続けていく上で外れ馬券を経費と認めたこの最高裁判決は重要です.
もちろん莫大な時間とカネをかけてシステムを完成できればの話で,自分でやるつもりは毛頭ないです😅
場合によっては長期的にも.

Manjaro AMD64 ぶっ壊す

Workstation (WS)をぶっ壊すのは日常茶飯事ですが,これまであまり壊すことのなかったManjaro AMD64 (x86_64)をぶっ壊しました.

先日Manjaro AMD64がKDE Plasma Desktop 6にupgradeされて喜んだのですが,どうもzramがぶっ壊れているのに気が付きました.

色々調べて,systemd-swapが機能していないことがわかりました.systemctl statusで見ると,sysv_ipcがインポートできないことがわかりました.

更に調べると,このsystemd-swapはout-of-dateとなっていることがわかりました😥

それで,Archlinuxのzramのドキュメントを読みながら色々やっていたのですが,どれをやってもうまく行かず,挙句にはEFIをぶっ壊して起動しなくなってしまいました.

EFIがぶっ壊れてはサブWSであるSlackware64もブートできず,にっちもさっちも行かない状況に陥りました.

まずは,Slackware64のブート用USBメモリーから起動して,Slackware64のEFIとGRUBを直して起動するようになりました.ここまでは大した手間ではありませんでした.

このあと,Manjaroのパーティションに4月のバックアップをrsyncでコピーしましまたがうまくブートしません.libvirdがどうのこうのいう,本質的には関係ないエラーなんですが,そのエラーの先に進んでくれません.念の為,Manjaroのパーティションをformatしてからrsyncしましたが,同じ結果でした.

しかたないので,libvirtdを起動しないようにしてある仮想マシンのイメージからrsyncをかけたら,ようやくブートしました.

どうも,rsyncで差分をバックアップしたものからの復元はこのManjaro AMD64に限ってはうまくいかないようです.もちろんあるサブディレクトリー以下とか,特定のファイルについては簡単に復元できるのでバックアップを取る意義はありますが,まるまる起動可能なバックアップとして今までより頻繁に仮想マシンの仮想ディスクにクローニングすることにします.

まともに動くところまでロールバックしたところで,systemd-swapを消して,もう一度,Archlinuxのzramのドキュメントを読みながらやり直します.

udevルールによる方法

結局うまく行ったのは,Archlinuxのドキュメントのうち,udevルールを使う方法です.手順としては,

  1. これまで使っていたZramのサービスが起動しないようにする
  2. /lib/mdoules-load.d/zram.conf に, zram の一行のみ書く
  3. /lib/modprobe.d/zram.confに, options zram num_devices=8 の一行のみ書く
  4. /etc/udev/rules.d/99-zram.rules に,
    KERNEL=="zram[0-7]", SUBSYSTEM=="block", DRIVER=="", ACTION=="add", ATTR{comp_algorithm}="lz4", ATTR{disksize}="1024M", RUN+="/sbin/mkswap $env{DEVNAME}"
    の一行のみを書く
  5. /etc/fstabに,
    /dev/zram0 none swap defaults,pri=100 0 0
    /dev/zram1 none swap defaults,pri=100 0 0
    /dev/zram2 none swap defaults,pri=100 0 0
    /dev/zram3 none swap defaults,pri=100 0 0
    /dev/zram4 none swap defaults,pri=100 0 0
    /dev/zram5 none swap defaults,pri=100 0 0
    /dev/zram6 none swap defaults,pri=100 0 0
    /dev/zram7 none swap defaults,pri=100 0 0

    を書く
  6. 祈りながらリブート

だったと思います😥

1のあとの再起動で,zramモジュールがロードされていないことを確認,3の後の再起動でzramモジュールがロードされ,4のあとの再起動で/dev/zram0〜7ができていることをそれぞれ確認,など途中要所要所で動作確認をすると着実に進められます.

以上,未来の自分あてのメモでした.

厳密には,メインWSはMac miniで,Manjaro AMD64がサブWS,Slackware64の実マシンはサブサブWS,またはサブWSのサブOSです.
かんたんに書いてありますが,rsyncののち,chrootして,efibootmgrやgrubのツールを使って起動するように呪いをかけます.

KDE Plasma Desktop 6

いくつか動かしているLinuxの実マシン・仮想マシンでは,UbuntuとRaspberry Pi OSの一部のマシンを除いてデスクトップはKDE Plasma Desktopにしています.

先程updateをかけたら,Manjaro AMD64のデスクトップが,KDE Plasma Desktop 5から6にupgradeしました.

Debian AMD64はまだ5のままです.

Manjaro ARM64のKDE Plasma Desktopが6になるのが楽しみです.

VLCでRTSP見てます

本当にRTSPをRaspberry Pi (RPi)で見るのには七転八倒してきました.ここのところはVLCで見ていますが,VLCのupgradeが来るたびに良くなったり悪くなったりです.

現在は,Raspberry Pi 3 Model B+ RAM 1GB (RPi3+)とRaspberry Pi 4 Model B RAM 4GB (RPi4)の2台で見てます.どちらもRaspberry Pi OS (RPiOS) をSDカードにインストールして普通のPIXELで動かしています.

以前はRPi3+とRaspberry Pi 3 Model B (RPi3)を動かしていましたが,RPi3のWi-Fiインターフェースが故障し,有線LANではつながりますがいろいろ不便なので引退させ,RPi4に置き換えました.

ケース全体がパッシブなヒートシンクになっているケースに入れたRaspberry Pi 3 Model B (現在はRaspberry Pi 3 Model B+を入れてます).2022年8月撮影

現在のVLCの状況(2024年5月17日)

現在Raspberry Pi OSのVLCは,3.0.20で,もちろん関連するライブラリーに依存するところが大きいと思いますが,かなりひどいです.

画像の時間が止まったり急に動いたりの繰り返しです.

撮影したビデオでは順番が逆になっていて前半は遅れた分を取り返すべく,2倍近いスピードでタイムスタンプが進みますが,45秒でしばらく止まり,2秒分進みますがまた47秒でとまります.こんな感じの繰り返しです.防犯カメラが正常に動いているのは防犯カメラの専用アプリで確認してます

パフォーマンスの良いRPi4のほうでこれですから,RPi3+では使い物になりません.一刻も早く改善してほしいものです.

VLCでRTSP見てません(2024年5月19日追記)

結局今のバージョンのVLCはどうしようもないので,ffplay (FFMPEG)に切り替えました.ffplayだと音声が再生できないので,早くVLCがまともに戻ることを期待しす.

RPiOSのdefaultのデスクトップ.
RTSPサーバーが正常でない可能性は否定できませんが😅
Raspberry Pi 5 Model Bではずっとましですが時間軸のギクシャクはあります.