日付変わったし晩飯にするか……
OpenRGB - Supported devices
https://openrgb.org/devices.html?search=radeon+rx
Radeon RX 7900 XT がない。つまり私のィヌックスマシンのグラボが虹色に輝いているのは消せないということですね。
Solved: How to turn off LEDs on Linux - AMD Community
https://community.amd.com/t5/drivers-software/how-to-turn-off-leds-on-linux/td-p/676800
ウッス
でもこいつ GPU ファンが回らなくてこわすぎるので電源通ってるか確認する手段が LED しかないんだよな……
YouTube で 4K60fps 動画を縮小しながら流しつつ glxgears も実行しつつ supertuxkart を最大解像度で実行したらやっとファンが回った (というか明らかにハードウェア性能が過剰だろ今の構成では)
薄々気付いてはいたんだけどね、当時はまだ 4K 複数枚のマルチモニタとか 3D 弄りとかやるつもりがあったから……
(エアリプ) 本当におもしろい話なら別経路とかでも流れてくると思うので、信用ならん出口からの情報に雑念や偏見や邪魔なイメージを植え付けられた状態になるくらいなら存在ごと見なかったことにできる方がマジで有益です (個人の感想)
そもそもよほど重大かつ身近な影響の大きい話でもなければ、ごく少数の情報源からしか出てきていないような早期情報を急いで入手する必要性も薄いので、その点でも、信用ならん情報源を2つや3つブロックすることのデメリットなんて無視できるレベルだし有害性に至っては実用上ないとさえ言える
それもべつに党派性や嗜好の違いによるブロックとかではなく実績と姿勢にもとづく根拠ある低評価なので情報源が偏ってしまうとかの懸念も持っていないし (というか、少数のブロックで問題になるほど偏るような情報なんてそもそもそこまで真剣に悩むほど重大でない)
このアカウントは、notestockで公開設定になっていません。
Ruma - Your home in Matrix
https://ruma.dev/
News が2021で止まってるのが絶妙に不安にさせるが、リポジトリの更新は続いてるっぽい。 matrix チャンネルを見ないとだめか?
言い方が甘いかもしれないのでもう少しはっきり書いておくと、「害意があると思われる/その実績がある人が『本当のことを言った実績』があるからといって、いちいち発言を真に受けたり『本当のことかもしれない』と検証したり評価を見直したりしてしまうほどに信頼する相手に飢えてはいない」という感じ。中途半端な詐欺師の発言は信じるとか信じないとかじゃなくてそもそも聞かないべき。本当の発言の割合とか全然関係ない。
誇張でくだらん嘘をついて本当のことかのように言うのは害意あるいは加害でしかないし、「人は間違うもの」とかそういうレベルじゃなくて意図してやってるんだから三流未満であるか邪悪であるかその両方なのよ。しかもタイトルだけでなく本文までその調子だったりしたわけだからむしろ擁護する理由がない
まあ人の良すぎる人が詐欺師を信用しようと頑張るのをわざわざ止めるつもりはないが、私は間接的であっても詐欺師と繋がろうという気はないので適宜フィルタを強くかけていきますよというだけの話
設備・備品 #219: dGPU: GIGABYTE, Radeon RX 7900 XT GAMING OC 20G - 鯖缶 - Nopmine
https://redmine.potato.immo/issues/219
あと3ヶ月で保証切れるらしいし、まあ今は放置するか……となった
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
https://mastodon.cardina1.red/@lo48576/113158752142887921
ちなみにここから7時間弱が経ちましたが、エアコンなしで 31.7℃ 65%RH まで下がりました。やったね!
エアコンありで 31.5℃ 55%RH くらいがいつもの水準なので、多少湿度はあるながら概ね落ち着いた状態といえる
ただし夜これでいけるからと油断して空調の調整を忘れると、朝にむけて猛烈に暑くなってきて昼起きた際に煮干し状態になります
ADATA SU650の熱対策を行う: blogの辺境 ~目指せblogの一市民~
https://riku-zen.cocolog-nifty.com/blog001/2020/08/post-875aea.html
🦀、お前そんなところでも……
ADATA の SU650、あまりに安かったのでちょっと調べてみていたが、熱と TBW の低さでだいぶ評判が悪かった。やめとこう。
ちょっと余所見していた隙に 34.7℃ 55% になっていて号泣、エアコンつけました
デカい UB の修正プルリコをもらったので情けない悲鳴をあげながら merge しました、感謝……🙏
> クロス LAN ケーブル
古いパソコンと直接繋げられる。 Wifi より圧倒的にレイテンシが短い。大量のファイルとかをやり取りするのにすごく便利だった。これを使って古いパソコンを NAS として使ってる、めんどくさいデータ移行を後回しにできた。
いつの時代のPCですか
Cat6A クロスケーブルとか普通にあるからなぁ (自宅にスイッチングハブがなくてルータが壊れた人には……有益か?)
物理層の規格(1) - ネットワークエンジニアを目指して
https://www.itbook.info/network/phy01.html
> 1000BASE-Tからは、MDI/MDI-Xの自動認識機能が規格に組み込まれています。そのため、1000BASE-T以降の規格はストレートケーブルとクロスケーブルの使い分けの考慮は必要なくなりました。
「双方向」コミュニケーションの非対称性のグロテスクさに思いを馳せるなどした (いややっぱりしてない)
「双方向」という言葉はそれ自体は非常に抽象度が高いレベルでの定性的な話をしていて、そのレイヤーでは確かに対称性があるんだけど、基本的に少しでも具体化するとすぐに非対称性があらわれ、しばしば実態は力の格差などを伴ったりそれを補強・促進したり存分に発揮する方向に機能させるものだったりするので、上下のレイヤーでのニュアンス差が激しすぎてこわいね
知らない間に内容量が減っていることでおなじみ食品業界において容器を拡大してまで内容量を増やしているお茶
そもそもソフトウェア特許ってカスやねんという気持ちはある (念の為; この発言は所属組織を代表するものではありません)
ソフトウェア特許がなければ VP9 vs H.265 みたいな謎の派閥争いもなかったかもしれないし、Steam のデフォルトで入る Proton で WMV がデコードできず ATRI -My Dear Momemts- のムービーシーンの再生に失敗して無言でスキップされたことに気づかず進めた可哀想な Linux ユーザーもいなかったかもしれないのに……
どうでもいいんだけど最近bzip2あんまり見なくない?(zstdに押されてる気がする)
ネットワークにデータ流すときにちょっと縮んでほしいくらいならdeflateかLZ4でよい
あと LAME (mp3 のアレ) も「これパッチだから!ソフトウェアじゃないから!」つって配られてたりしたやつだね
このアカウントは、notestockで公開設定になっていません。
結果発表。
zstd は --ultra -21 (level 21)、 xz は --best (level 9) での圧縮。
parallel-n は -Tn による並列圧縮。
元の tarball は mastodon (この投稿を発射するサーバ) の先月のバックアップで、 mastodon の git リポジトリや postgresql の生 DB (not dump) などを含む。
生 tar: 9199626240 bytes (8.6 GiB)
zstd 直列/16並列 (完全一致): 1606277479 bytes (1.5 GiB)
xz 直列: 1391707412 (1.3 GiB)
xz 8並列: 1395747252 (1.3 GiB)
……というわけで、以下の両方の条件を満たす用途ならまだ zstd よりも xz の方が強そう。
* 2%くらいの差が気になる。
* 圧縮時間はあまり気にしない。
CDN 絡みだと正当化できる場面もあったりするのかね (まあだいたいデカいデータ配ってるのはゲームとかで、ゲームアセットは基本的にテクスチャ単位とかで圧縮かかってたりするけど……)
OS のアーカイブだったり、近年だと機械学習の云々とか、あの辺りも配布数が大きくなりうるし小さければ小さいほどよさそうか?
このアカウントは、notestockで公開設定になっていません。
TimSort以降も汎用ソートアルゴリズムは生まれているし、Zstandard以降も汎用圧縮アルゴリズムは生まれている
このアカウントは、notestockで公開設定になっていません。
通信帯域を考えれば衛星側にも十分な時間がある、言われてみるとそうかもしれん…… (いや知らんけど)
gzip (deflate) こそ zstd で完全に置換できる領域では。素人的にはもう互換性くらいしか deflate 系を使う理由は思いつかない
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
圧縮はヒューリスティックとか非決定性を入れ込む余地があるので本質的に遅くなりそうなのはわかるけど、伸長は決定的なのでそもそもどうすれば圧縮より遅くなるのやら
相対的に圧縮に近づけるという意味で伸長が遅いことはあるだろうけど、それ滅茶苦茶圧縮がシンプルでないと成り立たなそうなので絶対的には圧縮伸長いずれも早いということになりそう
どうなんだろ、メモリアクセスまわりとか何かめちゃくちゃ頑張るとキャッシュミス引き起こしまくって遅くしたりできるのかな (クソデカ辞書とか?)
それだと結局圧縮も同じ理由で遅くなりそうなので両方とも定数倍遅いみたいなところに落ち着きそうな気がする
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
なんか両方とも行列とかでシュッとやるとニュッと出てきそうみたいな幼稚園児の落書き並みのイメージしか持ってない
brotli は辞書を HTTP とか特定用例 (自然言語含む) に特化させたある種のチートコーデックなので、あまり一般の圧縮アルゴリズムと同じ土俵に並べて比較したくないですね……
雰囲気としては flac とかのようなメディアコーデックに近いものと思っている (圧縮対象についての事前知識が圧縮率に効いてくる系のもの)
WEBスピード向上・転送量削減する Brotli 圧縮と CDN の連携 | REDBOX Labo
https://blog.redbox.ne.jp/cdn_brotli.html
> Brotli は辞書式において122MBの大容量辞書を利用し、頻出する単語パターンの圧縮を効率化しています。122MBにも及ぶ辞書には、英語、スペイン語、中国語、ヒンディー語、ロシア語、アラビア語を含む13504語の単語または音節で使用される一般的なフレーズ、特にHTMLおよびJavaScriptが含まれているためWEB業界では高い圧縮率を誇っているようです。
[EDIT: たぶん引用部分の数字は 122 KB の typo <https://mastodon.cardina1.red/@lo48576/113162449075160357>]
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Brotli の辞書いまそんなでかいの (昔 120KB とか見た覚えがあるんだけどもしかしてそれ自体 MB のタイポだった?)
Google's new squeeze: Brotli compression open-sourced • The Register https://www.theregister.com/2015/09/23/googles_brotli_compression_opensourced
> The total size of the static dictionary is 122,784 bytes.
120 KB で合ってそう
このアカウントは、notestockで公開設定になっていません。
Compression Dictionary Transport (Shared Brotli) によるコンテンツ圧縮の最適化 | blog.jxck.io
https://blog.jxck.io/entries/2023-07-29/compression-dictionary-transport.html
> あとから「brotli 以外の圧縮(例えば zstd)でも使える方法なはずだ」ということで、名前をより汎用的な "Compression Dictionary Transport (CDT)" にリネームして現在の提案に至っている。
ホ㍂
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。