@kb10uy 理由は書かれていませんが意図的に後からlp64fに切り替えて https://github.com/kendryte/kendryte-gnu-toolchain/commit/289ea18741ac1f54e1752e1e7a8f16f1fa880ede からSDKをそれに合わせている https://github.com/kendryte/kendryte-freertos-sdk/commit/729878522ff284b9d89494685d0dfed62a58a815 ので嫌な予感がしますね（組み込み系でベンダーがサポートしていない新しいGCCを試したり違うABIにしたりするとハマるやつ）
Linaroの（またはArmの）あのバージョンのビルド済みツールチェーンを使うかヤクの毛刈りに追われるか選べみたいなことはよくある
M5StackというかESP32というか Tensillica Xtensa コア、今後開発環境がどれぐらい生き残ってくれるかみたいなのが気になり始めた
Xtensa自体はIntelのSoCに入っている関係でLinux Foundation傘下のSound Open Firmware https://github.com/thesofproject/sof でサポートされているのでいくらかのリソースは当分投入されそう
SOF、Intel以外のプラットフォームをサポートするコードが投入されるかどうか注目している
Intelが中心のOSS、既存のアプローチよりも設計がシュッとしていて興味深いけれど主要Linuxディストリビューションで標準採用される兆しがなく使おうとすると軌道に乗るまでに試行錯誤が必要でIntel自身も推してるのかそうでないのか今ひとつよくわからないものが散見される
Intel発じゃないプロジェクトにバンバンパッチを送るときのIntelはつよいのになぜ……
このアカウントは、notestockで公開設定になっていません。
'syscall call-from verification' - MARC https://marc.info/?l=openbsd-tech&m=157488907117170&w=2
OpenBSDがシステムコールを直接呼べるコードのアドレス範囲を指定するmsyscallを導入し始めた。これにより、ユーザーランドのコードは基本的に（起動のたびにレイアウトがシャッフルされる）libcを迂回してシステムコールを直接呼ぶことができなくなり、ある種の攻撃がより難しくなる。
OpenBSD上のGolangはLinux上と同様にlibcを経由せずシステムコールを直接呼ぶので、libcを経由するようにGolang側を修正するまでの間は本来よりも広い範囲がプロセス起動時に（ld.soによって）指定される。
このアカウントは、notestockで公開設定になっていません。
の投稿
dashie@pleroma.otter.sh
このアカウントは、notestockで公開設定になっていません。
単語数による従量課金の英文校正で大量にギリシア語とラテン語がねじ込んであるの，頭悪すぎない？
ヤフオクの売り上げをPayPayに出金したものの、使いどころがなったので、ヤフオクでPi4のファン無しアルミケースを落札したら、在庫切れとか言われた。代わりに同じ型のファンが付いてるやつはどうかと聞かれた。いやいや、本当は落札されてから注文するつもりだったんだろ。両タイプあるのを知りつつ、どのサイトもファン付きしか売ってないのを見て、あえてファン無しが欲しくて落札したんだぜ。
落札してから無いっていわれるやつ私もされたことある。しかも住所向こうに教えたあとだぜ？ひどいよね。規約違反だし。
このアカウントは、notestockで公開設定になっていません。
SSHGuardを導入した後、sshdに多要素認証の設定を試みていたらログイン失敗しすぎて自分がBANされて純粋な笑顔になった
sshdの設定を変えるときの定石として「最初にログインしたセッションを切らずに新しく端末を開いてSSHでログインを試す」というものがあるのですが、fail2banやSSHGuardの類で短期間に高頻度のログイン失敗を検知したらiptablesやpfなどにパケットをドロップさせるようにしていると最初のセッションも遮断されるのでおしまいです
BANされたこと自体はOOBでアクセスして事なきを得たけれど、他要素認証はまだうまくいっていない（keyboard-interactiveがなぜか動かないので公開鍵→チャレンジレスポンスができない。公開鍵→パスワードは動いたので考え方は間違っていないはずなのだけれども……）
Standard-A−Standard-AのUSBケーブル、いよいよAとBに分けた意味がなくなってて笑顔
miniやmicroなUSBにはOn-The-GoのためにAB両対応のポートがあるけれどStandardだと端子の位置が違いすぎて厳しい
後からならなんとでも言える、USBは最初から両対応のコネクタにして接続時にネゴシエーションすればよかった、ISOはUnicodeを蹴って32ビットのISO 10646原案を通せばよかった、……（実際やってたらUSBはコストが高いと判断されてなかなか広まらなかっただろうし、各社はISO 10646を無視してUnicodeを実装し第2のOSI呼ばわりされていただろうけれど）
USBが最初からType-Cだった世界、独創的な接続形態を生み出して機器を壊す人々の対応に追われるメーカーがあまりにもつらそう
USBが使われ始めた頃はただでさえPlug and Pray性が高かったので最初からType-Cでネゴシエーション必須だったら全然流行らなくて後から野心的な試みだった的な振り返られ方をするポジション
一般的な周辺機器だったら割とPnPでデバイスドライバーが準備されるようになってきたの本当にすごい
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
TLSのハンドシェイクが読める人はいるのでUSB PDで給電する人もいるかもしれない（？）
「本物のプログラマーはオールドスクール以外のフォーマットで遊ばない。再録カードは以ての外だ」
