折れたピン直したけど J29 のピンの先っちょが少し欠けてて、このピンは Vcc だけどたくさんあるうちの Vcc がひとつぐらい欠けても起動してくれそうなものなんだけど、ダメだった
折れたピン直したけど J29 のピンの先っちょが少し欠けてて、このピンは Vcc だけどたくさんあるうちの Vcc がひとつぐらい欠けても起動してくれそうなものなんだけど、ダメだった
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
『FF7R』や『原神』はPS5でどう変わるのか。PS5後方互換機能により、きれい・なめらかになるタイトルリストが有志により作成される | AUTOMATON https://automaton-media.com/articles/newsjp/20201118-143657/
@akahana 少なくとも 2002 年には wireless keyboard 出してる。その頃のそれで OpenFirmware の操作まで出来たかは定かではないけど、2007 に Magic Keboard 出た時点ではもう Intel Mac だったし EFI をそれで操作できたはず。
“Even major corporations occasionally fall into the wasei-eigo trap, Tsuruta said, citing Hitachi’s long-running “Inspire the Next”, and Toyota’s Olympic-inspired “Start your Impossible”.” https://www.theguardian.com/world/2020/nov/18/hello-work-or-job-centre-language-experts-japan-english
“nonetheless catchy, English titles for government business, including Hello Work (job centres), My Number (a 12-digit ID system), and, more recently, Go To Travel”
https://www.theguardian.com/world/2020/nov/18/hello-work-or-job-centre-language-experts-japan-english
日本の謎英語シリーズがガーティアン紙に盛大に dis られとる…… >> 'Hello work' or job centre? language experts spell trouble for Japan's mangled English | Japan | The Guardian https://www.theguardian.com/world/2020/nov/18/hello-work-or-job-centre-language-experts-japan-english
@akahana だって Mac て昔から無線のキーボード／マウスだし Web から最新の OS イメージとってきて再インストールとかてきたじゃん
GitHub のほうで何らかの便宜図ってそういう風になるようになってるのならしらないけれど、そもそも開発者は GitHub あんま見てないはずだし
普通に master は master だと思うけど https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/refs/
@akahana まあ HTTP/HTTPS にしろ Wi-Fi/Bluetooth にしろ、Apple EFI はずいぶん昔から実現してたけど
@akahana UEFI 2.7 からは Wi-Fi や Bluetooth も喋るようになったよ
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
あ、なんだ、UEFI の Redfish の credential って普通に Basic 認証でいいのか……。
@akahana 5 年ぐらい前に Intel + HP が「UEFI に HTTP/HTTPS と RESTful API の I/F が規格として入ったことだし、IPMI と PXE を捨てて RESTful API でアクセスして HTTP で boot しようぜ！」っていう発表をしたという背景があります
Terminal.app、True color どころか 256 色ですら怪しいし、他の色々を考えても基本的に機能が足りない
Terminal.app は色数とかの機能が色々しょっぱいのであんまちゃんと表示できないと思う。iTerm2 ならちゃんと綺麗に表示されるよ
このアカウントは、notestockで公開設定になっていません。
まあ複数のマシンをまとめて iDRAC や iLO の Web インターフェースで眺めたり SNMP を舐めたりする、とかしはじめると色々機能とライセンス欲しくなるんだろうなとは思いつつ、そういう使い方してないからな……。
IPMI、power cycle と SoL と fwupdate があれば満足してしまうので山程ある機能をまるで使えていない
@charsiuCat 最初のほうに RISC とは雖も……という最近の複雑化したプロセッサへの反省と RISC-V でその反省をどう生かしたかが載ってるはず
IPMItool やめて真面目に redfish 経由で叩くの楽しそうだなとおもってるけれど、curl -k https://<bmc-ip>/redfish/v1/Systems/ とかやると credential をちゃんと用意せいって言われてやる気が失せた。いや、curl なんかじゃなくてちゃんと client 作ればいいんだろうけれども……。
最近の HP や Dell の IPMI (iLO, iDRAC)、真面目に Redfish 実装しててかなり笑えるよ。
$ curl -k https://<bmc-ip>/redfish/v1/
とかやると json がバッと返ってくる。
まあでも ipmitool 経由でエイヤってやれば power cycle できるし SoL も触れるし、わりとどうでもいいやってなってる。BMC に対して ssh もできるしね。
Dellの鯖触る機械出てきそうだからマニュアル読んでたけどDellのIPMIこれHPEよりライセンスでかなり機能絞られてて買っときゃよかったわとなるなど
pre-UEFI Armはそれが主流で、UEFIだとFDTをファームウェアからカーネルに渡すという認識
PC 向けに DeviceTree 使うときはファームウェアに DTB 入っててうまい具合に UEFI から kernel に渡してくれるということなのかしら。
ACPI ってヴェンダーが記述した ASL をコンパイルした blob がファームウェアに内蔵されていると思うけれど、DeviceTree って DTS を自分で記述して自分で DTB にしたのを kernel といっしょにロードする必要があるイメージ。
Z80 の高速化テクニック、最近 HARD 社（PC-88 や PC-98 向けの R-18 ゲームメーカー）が同人誌として当時の色々載せたムック出してて、そこに Z80 の高速化話も書いてあった
このアカウントは、notestockで公開設定になっていません。
とはいえ ACPI と違って OS 書く側が DTS を書かないといけない気がするのはちょっと大変な気がする
DeviceTree って IEEE 標準入ってるのか、それならまあまあアリか……?
で、device treeももともとIEEE規格で現代的なバージョンも https://www.devicetree.org/ で文書化が進んでいるのでありじゃねとなっていたのだけれども、まあ
の投稿
prime@mstdn.poyo.me
このアカウントは、notestockで公開設定になっていません。
Arm の二の舞になるまえに今のうちにどっちかに固めておくのと良さそうだけど、結局 Arm みたいにカオスな状態になる未来が見える
前提として（おるみんさんは知っているだろうけれど）Armは例によって例のごとくカオスな状態でUEFIがDTBを提供する環境とACPIを提供する環境があるらしく、RISC-Vはどっちになるのという論点があった
OS つくるよ的なことを言っている Twitter に生息する人、めちゃくちゃ居るので同定できない
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
というか RedStar は Cent OS 派生なのであんまそこから派生させても面白くは……。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ACPI 自体は UEFI と同じとこが策定してるし、Aarch64 向けの ACPI の実装もあるわけだし、RISC-V も PC 向けの要求が高まると屈する他ない気はする
RISC-VのUEFIもACPIを推すx86-64と実装を共通化したい勢とdevice treeでいいだろ勢の衝突があった（今どうなってるのか追っていない）
バグってたり若干セキュリティの穴があったとしても、IPMI でごにょごにょするより REST API で雑に OS をインストールしたり power cycle したりしたいし、Bluetooth マウス／キーボードでファームウェア設定をしたいというのが人情なんだなあ。
UEFI も ACPI も、architecture independent かつ OS の bootstrap や device scan に必要な諸々の手続きに対して簡単にアクセスするための framework としてはまあまあ妥当なんだよね。まあここらへん、USB Type-C の理想と現実、みたいなのに近い
まあ UEFI に RESTful API server や Bluetooth protocol stack への I/F が規格として実装されているのはどうか、というのはわかるけど、人間便利さには負けるのだよな
複雑すぎるしセキュリティ上どうやねんというのはとってもわかるけれども、bootloader と OS を自作しようとしたときにはやっぱり便利さに負けてしまう
@rooty2
8086 互換が real mode、
286 以降のメモリ保護機能を有効化したのが protect mode（そしてそれでアクセスできる 1MB 以上のメモリ空間が protect memory）、そして AMD64/Intel 64 の 64-bit mode が long mode だよ。
富岳CPU A64FX用ディープラーニングライブラリの深層 -研究者が語る開発の軌跡- - fltech - 富士通研究所の技術ブログ
https://blog.fltech.dev/entry/2020/11/18/fugaku-onednn-deep-dive-ja
「富岳ユーザーおよび世の中のArmv8-A命令セットを採用するCPUのユーザーの事を考えた場合、DL処理ライブラリのデファクトである本家のoneDNNに最高にチューニングされた実装が最初から組み込まれていた方がよいと考えました。そこでIntelと協業し、我々の開発成果を積極的に本家oneDNNへプルリクエストしていくことを決めました」
「我々が開発したXbyak_aarch64と、それを使ったArmv8-A命令セット向けに最適化したソースコードは、本家oneDNNに正式に取り込まれています。今後も、我々が開発したArmv8-A向けに最適化した実装は継続的にプルリクエストを出していく予定です。いつか、皆さんのお手元のスマホの上で、我々が開発したソフトウェアが動作する日が来ることを夢見て、研究開発を継続していきます」
UEFI は C や C++ や Rust で driver や bootloader が記述できるし、long mode だから広いメモリ領域が使えるし、そもそも UEFI の API で FAT32 の読み書きができるし、いいことばかりだ
BIOS 時代はブートローダーのサイズが HDD の最初のセクタ 512Byte から更に MBR パーティションテーブルを差し引いた 446 Byte にバイナリサイズが制約される上に real mode だから 64KB の壁と 640KB の壁があるという n 重苦で、そんな中でもマウス使えるようにしたりネットワーク使えるようにしたり複雑な FS を読んだり、黒魔術が過ぎる
dynamic binary translator on dynamic binary translatorやばすぎでしょ
moby自体はdocker社がやってるものだからDeveloperKitを買ってないってことは別に頑張ってない
μ-op fusion とかしてて x86 の decoder ほんとうに黒魔術という感じがある
の投稿
prime@mstdn.poyo.meこのアカウントは、notestockで公開設定になっていません。
ただ、いくつかのポイントはあって、
- Apple が PowerVR 捨てて GPU も含めてフルセットを自前の SoC にして技術が成熟してきた
- Aarch64 や RISC-V の台頭で ISA 以外は自前で設計というのも増えてきた
- Intel が落ち目
あたりはある気がする
Intel 自身が昔から RISC に乗り移りたがってたし、実際内部的には CISC → RISC の変換噛ましてるわけで、かつスマートフォンや iPad の流行で Arm の流れは来てたので、いつ Apple が Arm に乗り換えるかのチキンレース状態だったのがようやくマジになったカンジがある
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ただ、その後に開発者に配られた Apple Silicon Mac mini の Developer Kit は iPad Pro とかの A12Z を積んでいて、M1 という名前が出たのはつい先日のことなので、便宜的というよりは発表当初は Apple Silicon ＝ A シリーズの新しい SoC という認識を皆が共有していた、という考えです
Apple Silicon は 6 月の WWDC で Aarch64 の Mac が発表されたときにそこで使われる SoC の名前として出たのが初出だと思う。
このアカウントは、notestockで公開設定になっていません。
最悪 QEMU で Linux 建てた中で Docker 動かしたら動かんことはなさそうではある（まあ Mac で Docker したい人がそれをしたがるかは別
Parallels は Apple から支援を受けて公式に開発中だけど、まだ終わってはいない
Apple Silicon 向けの Hypervisor.Framework はもう APIドキュメントがかなり前から公開はされているので、Arm 向けのハイパーヴァイザーを自作できる人間なら気合いで Apple Silicon Mac 向けのハイパーヴァイザーも作れると思う。
とはいえこれは時間の問題だし Ruby が動きゃ Homebrew も動くだろうから、そこはまあまあ問題なさそう。
Rosetta 2 は Rosetta のときより JIT compile や DBT の技術が成熟してるので、まあまあ大丈夫そうだと思うけれど、Ruby や Python、V8 （を使う Google Chrome）のような JIT をバリバリチューニングしてるバイナリを走らせるのはたぶんうまくいかなさそうで、実際 Ruby チームとか今絶賛 porting 頑張り中っぽい
Fat binary ＝ 二つのアーキテクチャ向けの機械語をどっちもひとつのバイナリに置いておく
Rosetta ＝ Fat binary に加えて、古いアーキテクチャ向けの機械語しか入ってなかったときにはがんばって翻訳して実行する
Rosetta 2 ＝ Rosetta の改良
MC68000 → PowerPC で Fat binary、PowerPC → Intel で Rosetta というのを Mac は今までやってきていて、今回は Rosetta 2 が載っています
なので USB-DAC を使っていてもノイズ原を減らすと音質（というか S/N 比）が向上する可能性は十分にあるのだけれど、果たしてそれが元より人間に識別可能なノイズであったかどうかは別問題
USB Audio はディジタル通信ではあるけれどもアイソクロナス転送なので、エラー訂正などしないのでゴミ品質の回路だとノイズ乗りまくり、という可能性はある
蟹オンボならともかくUSB-DACならDACまではデジタル通信だしエラーなんてそうそう起きないからUSB機器を取り付けるだけで音がまるっきり変わるなんてことは普通の環境ならあり得ない
このアカウントは、notestockで公開設定になっていません。
あと分岐を別れて狭い世界に、というのはあんまりよくわかってない（Apple は昔から Arm やってたわけで
別段 Intel Mac 以前だって Motorola/IBM/Apple 連合で独自プロセッサやってた（＝PowerPC）し、むしろ Apple というのは独自のことが大好きな会社であるからなあ
このアカウントは、notestockで公開設定になっていません。
Lisp はべつに人間が歩み寄ろうぜ！という思想ではなくて M 式とかちゃんと用意してたのに、なぜかみんな S 式しか使わなかったという認識
加えて、構文解析も [] の対応が取れているか確認する以外にひとつも構文木を考えなくていいのでラクチン
私は Brainf*ck 推しです。なんせ字句解析しなくても 1 文字 1 トークンで処理できる
このアカウントは、notestockで公開設定になっていません。
git reflog はうっかり git reset --hard とかで消したデータも帰ってくることがあるよ。べんり。
git gc するとゴーストデータ消すだけじゃなくて圧縮とかもかけなおすっぽいから多少軽くなる
ずっとといっても、ある程度溜まった時点で裏で GC してるはずだから完全に全て残すわけじゃないけどね
git gc で gabage collection を発動させるとそういうゴミデータが消えて軽くなるよ。
Git はデータを差分じゃなくて常にスナップショットで保存したりしているので歴史が積み重なると重くなる。それに、Git の tree に残ってない commit とかも git reflog で参照できることからもわかるとおり、実はずっと残している。
あとなんかgitリポジトリにすると実データの1.5倍か2倍くらいディスク食いませんか？俺だけ？
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
1984年に出たものを「比較的最近の〜」と紹介したが，これは40年くらいは全然「最近」のうちだよという時間感覚によるのであって，脳が2000年で止まっているからというのではない，断じて．
paiza.ioでコンパイラを作る - Qiita https://qiita.com/koturn/items/3b667eddee768062ec46
@kozue ちなみに paiza.io はあくまでホスティング環境であってコンパイラでもないです
omasanori/hugs98: A snapshot mirror of http://darcs.haskell.org/hugs98/ retrieved on 2020-01-24
https://github.com/omasanori/hugs98
Hugs98は北極に埋まる可能性を増やすためにこないだGitHubにミラーした。
Social Engineering Toolkit (SET) で Phishing site 建てるしかないようなドメインじゃん
このアカウントは、notestockで公開設定になっていません。
*A-STAR っての見た時点で真面目に読む気なかったのでちゃんと読んでないことがバレてしまった（たしかに piaza.io になっててわろた
このアカウントは、notestockで公開設定になっていません。
ほぼ GHC しかない Haskell くん……（いや、それしかないわけじゃないけれどもね）
このアカウントは、notestockで公開設定になっていません。
paiza.io だけで完結して開発するにしても、Brainf*ck のコンパイラならたぶん速攻で書けるのではなかろうか
このアカウントは、notestockで公開設定になっていません。
まあそれ C で define しまくって ALGOL の見た目だ！ってやるやつと大差ない話になるんでは……。
ところで paiza.io でコンパイラを作るのがしんどいかどうかというと、途中まで手元で開発して最後に paiza.io に投げれば解決や
WebAssemblyを出力する自作C++コンパイラでWebアプリケーションを開発する回
このアカウントは、notestockで公開設定になっていません。
そのサイトがとてもひどいサイトなのはもとから知られてるから記述がイカれてるのはまあいいとして，コンパイラを自作という概念自体はべつに突飛ではないと思う。
この、何から何までデタラメ書いてるサイトなんなん？
コンパイラを自作とかいう突飛な概念に？？？と思いつつも全然自作してねえし理解不能だ
＞C++は、スマホアプリやWebアプリの開発に広く普及しているコンパイラ型プログラミング言語です。
C++でスマホアプリ書けるなら、Javaとかいう糞言語使うことはなかったな。これ書いた奴C++を1行も書いたことねえんだろうな
コンパイラとは？構造や自作方法、おすすめのコンバイラの選び方を解説！インタプリタやアセンブラとの違いとは？ | A-STAR（エースター）
https://agency-star.co.jp/column/compiler
子宮移植後のサル出産成功、子も順調に成長 慶大チームなど発表 - 毎日新聞 https://mainichi.jp/articles/20201117/k00/00m/040/330000c
x64 → Aarch64 は JIT compile というより DBT (Dynamic Binary Translator) なので微妙に違う技術（JIT compile が援用できる部分もある
Rosetta 2、ブラウザとかJITがあるアプリだとJS→x86_64のJIT→arm64のJITって二段階になるからつらそうだよね
