自分もそう思っていたんですが、文面読み返してそっちの意味かーと納得してしまった（今更…）。

これなのかなあ、Taishanとかなんとか920とか。ARMっぽいっすね。

华为推出鲲鹏920芯片，号称最强性能
https://time.geekbang.org/column/article/77335

しばらく見ない間に色々面白いものが出てることは分かったけど…やっぱ財力ないとキツイよなあ。

とはいえ「今すぐ使える」ソフトウェア環境がどの程度の質かとか考えるとやっぱPCでいいやとかなっちゃうんだろうな、自分。

OrangePi AIpro(20T) https://ja.aliexpress.com/item/1005007285508803.html
24GB物＋ケース電源一式で\62743、12GB物＋ケース電源一式で\49372って、下手なPC買うよりか面白そうなお値段だこれ（でもそのお金すらないんだけどさあ）。

今使ってるPCよりも小さくて高性能でも、放熱と電源とケースがしっかりしていないと怖くて主戦力に据えられないなというのは、なんとなく。

なにこれ…手元のPCを軽く超えちゃってるんですけど。

OrangePi AIpro (20T) Built for AI
http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-AIpro(20t).html

LicheeRVだとArm/RISC-V切り替えができるみたいだけど https://wiki.sipeed.com/hardware/en/lichee/RV_Nano/1_intro.html 、Milk-VだとDuo S以外は配線しないと切り替えられないみたい（デフォルトはRISC-V側）。 https://spotpear.com/wiki/Milk-V-Duo-S-RISC-V-ARM-switching.html

CV18xxの類、RISC-V coreだけでなくArm coreでも動くらしいので（みんなRISC-V core狙いだと思うけど）、Armも含めて真面目に対応とかなると作業量が倍になるのがツラす…

SG2000、別名CV1812CPとか言うらしいので多分この辺に情報はあるっぽい。
https://github.com/milkv-duo/duo-buildroot-sdk/tree/develop/build/boards/cv181x

luckfoxのu-boot、mainline入りは流石にまだ無いか…

でも明るいニュースだなコレ。SG2002対応のMilk-V Duo向けのu-bootも、いずれはmainlineに入ってくれると良いな（lichee RV nanoとかも来ないかなー）。

@omasanori うぅ64MB物か…（Milk-V Duoは64MB/256MB両方持ってるんですが、ブートローダの都合でOpenBSDは256MB物でしか起動できないんですよね…）

でもこれどっちなんだろ、Milk-V Duoでも64MB物(CV1800B)なのか、256MB物(SG2002)なのか。

https://github.com/u-boot/u-boot/blob/master/configs/milkv_duo_defconfig
な ん で す と

ソフトウェア資産をすぐクズに変えていくアーキテクチャなんか怖くて使えねえ、というのがMSXの終焉を見た率直な感想。エミュレータにも限界はある。

…って書くとかなり原理主義な感じっすね。

まあバイナリ（アプリやデータ）はいつかクズにされてしまう以上、ソースをリコンパイルすればどうにかなるとか、テキストに近い可搬性のあるデータ形式で持っておくとか、そういう形で自衛（抵抗）するしかないかなーって。

今後はこういう「自由」に対してお金を払う時代なのかなあ。Milk-V Pioneerみたいに（欲しいけど高くて買えん）。

https://milkv.io/pioneer

x86の互換性って、CPUのアーキテクチャが変わってもOSは確実に動くという（かなりガチな）互換性なのに対し、Armの互換性ってアプリケーションのバイナリは動くけどOSはCPUごとに作り直そうねという割とユルい互換性というのが自分の理解。

なのでどうも一抹の不安があってな…ArmはArmで嫌いではないんだけども。

x86もSoC化したりパーツの置換ができないような構造になったりしてあれこれいじる余地が減りつつあるじゃんよ、というのはあるとして…とはいえ、Armのように完全に置換不能なものにされるのもなんか面白くねーなーというのが正直な気分。

（そういう意味では、IntelがQualcommに食われる→x86-64の終焉、と言われてしまうとフクザツな気分なのですよね）

ソフトウェア文化を作った企業の一つ、だろうなあ…Z80を擁するZilogと同じように。

このアカウントは、notestockで公開設定になっていません。

インテル株が上昇、クアルコムが過去数日に買収打診との報道 (2024.09.21) https://www.bloomberg.co.jp/news/articles/2024-09-20/SK4M2LT0AFB400

IntelがQualcommに食われるとしたら、本当に時代の終焉かもしれんな。Windowsもx86/x86-64を捨ててArm化しそう。

（Kaveri使いだった身としては、RYZENになってからの周囲の掌返しっぷりにちょっと辟易していたり…まあ性能が良ければメーカーなんかどこだって良い、ではあるんだけどさ）

Intelが死にかけると困るんだけどなあ。イマドキのLinuxだけ使うとか、Windowsだけ使うって用途なら別にAMDでも困らないんだけど…昔のWindowsをエミュレーションで、という用途でAMDは本当に苦労したから。

このアカウントは、notestockで公開設定になっていません。

おっきなところがMastodon instanceの運用を開始するけど意外と早くに終わるってケースは結構多いような気がする。ニッポン放送のTUNER(tuner.1242.com)も2017年にできて2018年には潰れてるし。

…運用開始のニュースは残っているけど、潰れたってニュースを探しても見つけられないのは何かの力が働いてそう。

brid.gyでBluesky→Mastodonに来たものをブーストしても、MostrはこれをNostrには流さないか…

このアカウントは、notestockで公開設定になっていません。

結局二つの問題によることが分かった。
- ダミーロードを付けているし出力も弱いので、JumboSPOTを隣同士に置かないとダメ
- JumboSPOT間の周波数のずれが思ったより大きい（MMDVMCalでoffset値を取り直す必要があった）
結局ファームウエアも最新のものに焼き直してる。

やっぱJumboSPOTのファームを焼き直さないとダメなのかなあ。一応M17対応だし、ダミーロード越しになんかそれっぽい電波が出ることは確認できてるんだけど、もう一台同じような物を用意しても受信をしてくれない。

ううむ、今までVMware上のDebianではrtl_tcpがちゃんと動いていたのだけど、VirtualBox上だとRTL2832Uを認識しないのでrtl_tcpが動かない。その辺にあるLinux実機に挿せば良いので大きな問題にはならないけど、ちょっと面倒なことになったな…

とりあえず今年一番の（自分の中での）大きな出来事って、クレカを乗り換えたことだったりする。

20年近く某社のを使っていたけど、年会費払っていてもタッチ決済できないカードのままで、なおかつサービス終了するから別のカード発行するんでそっちへ移行して（でもカード番号変更の手続きは公共料金と携帯電話以外は自分でやってね）なんて対応をされちゃった以上、これは切り時かなって。

実際、変えて正解だったと思う。落とした場合のダメージはデカそうだけど、タッチ決済が使えるのは本当に有難い。

JCBだけの暮らしというのは結構難しくって、結局MasterかVisaは必要になる…

とりあえず（英語でやんないと面倒だったので放置しようと思ってたけど）FirefoxじゃなくChrome使ったら上手くいったんだけどね、参考にしてちょという内容のメールは送っといた。

使ったカードがカードというのもあるのかもしれないし（カード会社への問い合わせで問い合わせ先とか探すのが非常に面倒だというのもどうかと思うぞ＞某社）、どうしたもんかな…クレカを増やすとか乗り換えるというのも気分的になんか嫌だし。とはいえMaster系でないと困る場面もあるからなあ。

bad request返すってんならどこの何がbadかくらいの情報は寄越せって気がする。あと、フィードバック先の情報。問題が起きている、という状態のまま指くわえてぼーっとしてるほどこっちも暇じゃない。

あの件はMasterではないものの、カード会社への問いわせはやっていてそちらでは「問題無いですねえ」の一点張り。https://docs.3dsecure.io/3dsv1/ みたいにAPIが公開されている以上、カード会社ではなくAPI利用側の問題と捉えられているのかも。

Mastercard ID Checkで引っかかっているにしても、ブラウザ要件とか特に書いてないんだよなあ… https://www.mastercard.us/en-us/business/overview/safety-and-security/identity-check.html

とはいえ、このカード使って他のサイトで買い物した際はFirefoxでも問題なかったように記憶しているんだがなあ…

自分が遭遇したのは、3D secureでカード会社による認証がうまくいったにもかかわらず、その後400 bad requestで支払先のサイトから蹴られるという事象。カード会社による認証はうまくいっているので、支払い自体は成立してしまうという（実際はクレジットカードの正当性をチェックするための少額決済なので実際の請求は行われないかもしくは返金があるらしいのだが）。

クレジットカードの3D secureサービスが、Chromeだとちゃんと動いてFirefoxだと動かないケースってあるのかなあ？

sndioのblockモードって、データが来るまで/送れるようになるまでは待つとしても、どれだけのデータを受信したか/どれだけのデータを送信できたかsio_read()/sio_write()の戻り値を見る必要があるのか。

sio_read()やsio_write()で指定したバイト数すべてを受信/送信し終わるまで待つ、というものではないのね…（ちょい面倒だな）。

W: 2024-09-14 22:43:20.613 Cannot open the RSSI data file - RSSI.dat
CSoundPulse sampleRate 48000 blockSize 1920
M: 2024-09-14 22:43:20.717 Opened default:default Rate 48000
CSoundPulseReader blockSize 1920 channels 1
CSoundPulseWriter blockSize 1920 channels 1
M: 2024-09-14 22:43:20.717 M17Client-20240903 is running