FreeBSDを語れ Part57

**名無しさん＠お腹いっぱい。** · 2023/04/23(日) 09:50:57.81

**名無しさん＠お腹いっぱい。** · 2023/07/27(木) 22:22:27.66

>>814
3TBや4TBモデルと比べてだけど
購入日時が半年ほど違う同一モデルを二つ持ってて両方ともによりも5度以上高い
あと音が僅かにうるさくなった
813はケースに入れずに裸で運用してる
もう片方は自作のアルミケースに固定してて温度が10度くらい低い

**名無しさん＠お腹いっぱい。** · 2023/07/27(木) 22:22:39.95

>>822
秒針つきアナログ風時計は？と問われれば
xclock -update 1
と答え候

**名無しさん＠お腹いっぱい。** · 2023/07/27(木) 22:25:07.99

>>748
ツンツン

**名無しさん＠お腹いっぱい。** · 2023/07/27(木) 23:33:11.91

　　☆;.+*
　　:ﾟ+｡.
　　☆;.+*:
　　ﾟ+｡.☆;
　　.+*:ﾟ+｡.
　　☆;.+*:ﾟ
　　+｡.☆
　　／⌒＼
　　(　　　)
　　｜　｜
　　｜　｜
　　|　　|
　　|　　|
　　|　　|
　　|　　|
　　| °Д° |
　　|　　|
　　|　　|
　＿|　⊃／(＿＿_
／　└-(＿＿＿_／

**FreeBSDでwimeを使っている君** · 2023/07/29(土) 21:29:26.54

>>824
xcalc 使用者なので、即、xclock を思い出しましたが、
以下の理由で、即、却下しました。

・長針と短針が長三角形で根元が太く
　針が重なった時に見にくい。
・時計の目盛りを刻んでいるのはよいが、
　長針と短針が短くて不自然に見える。
・秒針が長くて不自然。

いま気づいて「cairo-clock」を入れましたが、サイズ変更も
できていいですね。
あ、でも、BackGroundColorがBlackで透過にならないのか。
透過にしたければ、「compton-conf」か「compton」が必要なのか。
じゃあ、単体で透過するEmiClockでいいです。

こういう話題こそ「環境を語れ」スレで、すべきですよね……。

**名無しさん＠お腹いっぱい。** · 2023/07/29(土) 22:45:23.27

pkgに小熊猫116が来てる
なのに雷鳥115はまだ来ないんだな

**名無しさん＠お腹いっぱい。** · 2023/08/02(水) 12:11:02.44

GNU tar使うのに態々gtarから打たないといけないのは面倒

**名無しさん＠お腹いっぱい。** · 2023/08/02(水) 12:40:59.64

>>829
鬱陶しいのはわかるが、gtarを使わなきゃいけない場面がそんなにあるか？

**名無しさん＠お腹いっぱい。** · 2023/08/02(水) 18:06:16.28

そこにgtarがあるなら使わざるを得ないな

**名無しさん＠お腹いっぱい。** · 2023/08/02(水) 18:59:05.88

aliasしときなよ

**名無しさん＠お腹いっぱい。** · 2023/08/03(木) 04:44:19.01

全体的にGNUのコマンドのほうがいいとはよく言われるが、ことtarに関してだけはgtarよりbsdtar(libarchive)の方が良くね？

**名無しさん＠お腹いっぱい。** · 2023/08/03(木) 06:38:43.79

>>833
だな。grepもいつしかGNU grepを使わなくなった。ただこっちは慣れだけかも。

**名無しさん＠お腹いっぱい。** · 2023/08/03(木) 14:36:42.09

>>834
PCRE互換がBSD grepにはない
gnugrep -P
pcregrep
pcre2grep

tarはlibarchiveが便利
zipや7zの独自なオプション名覚えなくて済むし

**名無しさん＠お腹いっぱい。** · 2023/08/03(木) 22:11:25.23

make worldをクロスビルドしてるけどまだ終わんねえ
もう1時間半たっちゃったのに

**名無しさん＠お腹いっぱい。** · 2023/08/03(木) 22:41:20.10

portsはクロスビルドできないのしらなくて
仕方ないからproxmoxでi386環境作ってビルドしてるけどqemuってかkvmって以外に遅いのな

4G-XでXを起動してEmacsを動かしてみたけど流石に画面解像度が低すぎて使いにくい
800x480だったか、VTに日本語フォント喰わせた方が楽だった。
Xの方は小さめのフォントにして起動時フルスクリーンなら使えそうかな。
キー入力の自由度目当てなんでなんか代替案を探してみるか。

**名無しさん＠お腹いっぱい。** · 2023/08/03(木) 23:10:23.45

ハードディスクがガリガリ言わなくなってて確認したらsudoの「パスワード:」で止まってた
後はmake installworld distributeとハードディスクイメージの作成みたいだからすぐに済むかな

>>837
i386ならjailを使ってamd64上に環境を作ってportsをビルドできたと思う

**名無しさん＠お腹いっぱい。** · 2023/08/03(木) 23:15:51.37

80486 RAM4MBで386bsdの世界創生
してた頃はのどかだったなぁ…

**名無しさん＠お腹いっぱい。** · 2023/08/03(木) 23:55:06.37

えええええ
まじっすか

start_init: trying /sbin/init
init died (signal 6, exit 0)
panic: Going nowhere without my init!
time = 1691072421
KDB: enter: panic
[ thread pid 1 tid 100001 ]
Stopped at 0x4
db>

**名無しさん＠お腹いっぱい。** · 2023/08/04(金) 15:26:13.29

>>839
6時間くらいだっけ？朝make worldかけて帰宅したら終わってるサイクルで使ってたw

【豚】 · 2023/08/07(月) 00:29:40.73

Release schedule reminderに続いてCode slush begins / KBI freezeも１日早いの？
この調子ならリリースアナウンスも１日早く来るはずだ・・・・・・！

**名無しさん＠お腹いっぱい。** · 2023/08/07(月) 01:50:53.60

豚?

**名無しさん＠お腹いっぱい。** · 2023/08/07(月) 15:02:18.64

twmを入れてemacsを最大化するのはうまくいかなかった。
正確にはemacs自身に最大化させることができなくて、twmからならきっちり画面いっぱいにはできた。
たぶん、twmがフルスクリーンの依頼を受け付けてないんだろうと思ってctwmを入れてみたらf11でフルスクリーンをトグルできた。

**名無しさん＠お腹いっぱい。** · 2023/08/07(月) 16:39:43.61

>>844
ウィンドウの上のバーを管理してるのはWMです
アプリが自分で最大化してるわけではありません
アプリは通知を受けてウィンドウを再描画するだけです

【大凶】 · 2023/08/08(火) 01:00:22.81

>>843
00:00〜00:59までは名前欄に "!omikuji" でおみくじタイム

**名無しさん＠お腹いっぱい。** · 2023/08/08(火) 10:05:50.83

>>846
知らなかった
ありがとう

**名無しさん＠お腹いっぱい。** · 2023/08/08(火) 14:10:05.00

>846
fushianasanじゃないのか？

**名無しさん＠お腹いっぱい。** · 2023/08/08(火) 15:57:06.54

悪いやつはどこにでもいるな

**名無しさん＠お腹いっぱい。** · 2023/08/08(火) 18:24:33.52

hが入ってるだけ良心的だろ！！１１１

**名無しさん＠お腹いっぱい。** · 2023/08/08(火) 18:55:01.84

no rest for the wicked

**fusianasan** · 2023/08/08(火) 20:46:49.30

https://ja.wikipedia.org/wiki/Fusianasan

【中吉】 · 2023/08/08(火) 23:25:22.15

遅ればせながらApril-June 2023 Status Reportを途中まで読んだ
ページを自動的に機械翻訳するようにして読んでるんだが興味深いものがあった
> FreeBSD カーネルの物理メモリ圧縮
マジで！？と思って詳細ページを確認してみたけど超がっかり
Memory CompactionのことであってMemory Compressionのことじゃなかった
いや、大事なことには変わりないんだけど

【男の娘】 · 2023/08/08(火) 23:36:14.72

他に気になった部分は
>boot FreeBSD from an in-memory SquashFS file system.
あたりかなあ
tarfsは既にCURRENTに組み込まれてるし次はハンマーかな？

**名無しさん＠お腹いっぱい。** · 2023/08/09(水) 14:52:38.66

gigazineでvimの作者が亡くなったと報道してたが
FreeBSDのviはなんじゃらほいと思ったので
man vi
やってみたら

HISTORY
The ex editor first appeared in 1BSD. The nex/nvi replacements for the
ex/vi editor first appeared in 4.4BSD.

AUTHORS
Bill Joy wrote the original version of ex in 1977.

古い
vimとやらは入ってなかった
まあemacsとmgしか使わないのでどうでもいいんだが

**名無しさん＠お腹いっぱい。** · 2023/08/09(水) 19:57:41.31

>>855
英語読めてるかな?
nviは4.4BSDからだから1994年だぞ

**名無しさん＠お腹いっぱい。** · 2023/08/10(木) 09:39:16.92

13.2Rにeeemonの導入成功。ほとんど弄る必要が無かった。

**>>840** · 2023/08/10(木) 16:17:43.38

聞いたに書いてあったは
https://qiita.com/yamori813/items/bbdd91296602940cdbda
> 14Rで消される事になりますが、FreeBSD/mipsは13CURRENTの途中でgcc4からclangに変更され、その時点でカーネルが落ちるようになったので、12Rが実質的最後のリリースになります。

酷い扱いされてるwwwって言うのは簡単だけどやる人がもういないってことなんだな

**名無しさん＠お腹いっぱい。** · 2023/08/10(木) 17:59:33.69

> gccでのクロスのフルビルドは1時間以内でできるのですが、clangになってパラビルドしても5時間近くかかるようになりました。
clangクソ過ぎﾜﾛﾀw

**名無しさん＠お腹いっぱい。** · 2023/08/10(木) 18:57:11.44

elvis使えば良い

**名無しさん＠お腹いっぱい。** · 2023/08/10(木) 19:52:44.63

>>858
MIPSのマシンは記憶に無い
なんかあったっけか

富士通あたりか？

**名無しさん＠お腹いっぱい。** · 2023/08/11(金) 00:47:20.89

ZRouter.org絡みの話ですね
mipsもarmv6も終了のようです

**名無しさん＠お腹いっぱい。** · 2023/08/11(金) 01:11:33.85

>>861
補足すると元々はJuniperのコードでCiscoにいたwannerがメインに突っ込んだとか
ターゲットはBroadcom,IDT,Atheros等のSOC

**名無しさん＠お腹いっぱい。** · 2023/08/11(金) 01:28:42.78

Sony NEWSなわけないよな

**名無しさん＠お腹いっぱい。** · 2023/08/11(金) 07:05:31.13

今時mipsを使う男の人って

**名無しさん＠お腹いっぱい。** · 2023/08/11(金) 10:17:38.44

だからrouter等のembeddedだと言ってるのにw

**sage** · 2023/08/12(土) 16:07:16.24

に　ほ　ん　ご　で　か　け

**名無しさん＠お腹いっぱい。** · 2023/08/14(月) 01:27:25.87

今度は本気のようだな
FreeBSD 14.0-RELEASE Release Notes
https://www.freebsd.org/releases/14.0R/relnotes/

**名無しさん＠お腹いっぱい。** · 2023/08/14(月) 09:50:10.54

14はUnsupported多いですね
https://www.freebsd.org/platforms/

**名無しさん＠お腹いっぱい。** · 2023/08/14(月) 10:20:06.32

ユーザーも開発者も居ないから維持できねぇしする気もないんだと
あとClangのクロスtoolchainなのかx86以外のアーキテクチャのサポートがダメなのか知らんけど軒並み諦めてるな

**名無しさん＠お腹いっぱい。** · 2023/08/14(月) 11:55:56.66

もうNetBSDに行くしかないのかなあ

**名無しさん＠お腹いっぱい。** · 2023/08/14(月) 13:11:43.40

夕飯までには帰って来なさいよ

**名無しさん＠お腹いっぱい。** · 2023/08/14(月) 19:03:45.34

OpenBSDは頑張ってサポート出来てるのに…
どうしてこうなった

**名無しさん＠お腹いっぱい。** · 2023/08/14(月) 19:22:28.95

こうして少年はLinuxへと旅立って行った

**名無しさん＠お腹いっぱい。** · 2023/08/14(月) 20:17:35.66

こだわりや思い入れはあるんだがそろそろ限界か

**名無しさん＠お腹いっぱい。** · 2023/08/14(月) 23:18:13.45

その後その少年の姿を見た者はいない…　　fin

**名無しさん＠お腹いっぱい。** · 2023/08/15(火) 06:59:11.19

そして少年は大人になる

**名無しさん＠お腹いっぱい。** · 2023/08/15(火) 10:40:07.23

>>869
インフラ整備できない限界集落みたいになってきたね

**名無しさん＠お腹いっぱい。** · 2023/08/15(火) 23:58:34.47

>>869
VAX11は元々サポートしてなかったのか

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 01:05:04.98

amd64
aarch64
これだけあれば十分でそ？

そのうち Apple M2 も出たりしてなw

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 05:09:56.72

Tier 1に昇格したaarch64ヤバない？

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 05:58:03.48

BSD 系は普通の利用（サーバとかデスクトップ）だと今後も衰退の一途だろう
もう先は無い
でも組み込み系だとそれなりに使われているので、各種CPUはサポートし続けたほうが良い
X11とかDEは一切いらない。CLIモードで組み込み機器用に使えればそれで良い
生き残る道はそれだけだ

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 06:55:06.00

XだのDEだのを、自前でサポートしていた時期があったかのように言うじゃん

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 07:49:00.65

これしかない、こうすべきだ、という論評ほど役にたたないものはない。大体オレの前提条件と合わない。なのに、こういう場合はどう、と問うと、そんな奴ぁいねえといわれる。

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 11:01:15.37

まぁそんな考え方もあるよね
って程度

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 11:40:24.81

考えてるけど見〜て〜る〜だ〜け〜〜〜

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 12:59:22.25

役に立たないと決めつける論評ほど役に立たないものはない

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 13:35:32.25

幽霊は鏡に写らなくていいよな

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 14:24:29.65

VPetはoneko

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 20:48:29.04

https://i.imgur.com/zWJUXFW.jpg

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 22:59:09.14

>>882
DEはさほど負担じゃないでしょ
問題はvideoに限らずdriver
/dev/consoleすら作れなくなると開発者も去っていく

**名無しさん＠お腹いっぱい。** · 2023/08/16(水) 23:21:34.32

>>890
ポイント貰うだけ貰うか

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 03:07:39.02

>>891
そうねぇ今なら例えばofficeアプリが必要ならGoogle App.で済ましてしまえばいい
実際にそうしている企業だってあるからそれで行けばまともなWebブラウザだけ動
けばライトユーザーなら問題ないだろう
ほとんどはね

Linuxの抱えている問題を一つ挙げておこうか
Linuxのバグのライフタイムは実は昔も今もあまり変わっていない
平均的に発生したバグは1年以上残るしコードサイズの増加率は増えていてもバグの
発生率もそれ程変わってはいない
そしてコードの量が増えているのはほとんどがデバイスドライバだ

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 07:40:58.24

なに？最近はvesa frame bufferも動かなくなってるの？

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 08:09:15.93

何が言いたいのかよくわからんな
デバイスドライバ書いてバグが増えるぐらいならデバイスドライバ書くなってこと？

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 08:42:46.54

>>893
ドライバー以外でも、リリース毎に3万行位ずつ増えてる感じだよ
とんでもない化けもんだよ

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 08:55:38.04

Windowsのカーネルとデバイスドライバーは分離されてるよね
なんでそういう風にできないのだろう

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 10:17:30.31

>>897
されてません
配布形態としてドライバとミドルウェアとアプリの区別すらないものさえありますし
ミドルウェア相当がドライバに含まれるものも多いです

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 14:27:35.75

ＣLIって何？CUIじゃないの？

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 14:58:19.61

キャラクター・ライク・インプット　CLI

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 16:24:48.86

>>895
想像力過多だな
コードを書けばバクが必ずある
コードサイズが増えていくものはバグも増える、恐らく永久にバグはなくならない
それだけの話だ

コードをたくさん書くのは表面的な作業以上に多くの開発力が必要だ
コードを書かずに済まそうというのは恐らくはいい考えだろう

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 17:47:32.96

command line interface

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 19:10:50.57

アイデアの１つとしてはrumpkernelがある
Runnable Userspace Meta Program
実装はNetBSDのカーネルのドライバやファイルシステムをユーザランドに持ってきたものがある

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 19:41:32.78

GNU HurdはRump kernelをドライバーに採用した
元々全てをユーザーランドで動かすマイクロカーネルなんで、まさにうってつけだった
GNU Hurdは面白くなってきたよ

**名無しさん＠お腹いっぱい。** · 2023/08/17(木) 23:35:03.00

Hurdは今世紀中に完成する?

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 00:02:27.61

サグラダ・Hurd

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 00:12:45.33

完成が遅れるほど、基本設計が古過ぎるポンコツになるんでないの？
既に動いている他のは少しづつでも改良されて、新しいものも取り込んでいるのに。

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 03:35:06.69

>>899
俺も>>902だと思っていたけどWikipediaを見たら
CLI (Command Line Interface) ＝ CUI (Character User Interface)で、
CLI (Command Line Interpreter)とは別のものらしい、、、、、と思いきや結局おなじもの？

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 04:08:29.85

Hurdは設計が古すぎるので性能が出ない
Machベースのマイクロカーネルなんて話にならん

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 04:23:07.86

rumpkernelのキモはOSとドライバを完全に分離できるところにあるのにHurdなんてポンコツの話されてもな

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 04:51:14.60

実験的なものでしかないけど実際に試せるものが以下にあるんだな
https://github.com/rumpkernel
概念的にはこっちを見ると良い
https://en.wikipedia.org/wiki/Unikernel
rumpkernelで提供されるデバイスドライバとapacheなどのアプリケーションをリンクして
直接KVMなどのハイパーバイザー上で動かすことのできるパッケージがrumprun-packages以下になる
一応mysql, PHPはあるからLAMPっぽい事ができる最低限のものはあるというか（笑
Linuxの環境に対して4%程度のコードベースでアプリケーションの実行環境を作るとかな

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 06:07:32.51

今のGNU Hurdは2年おきくらいにリリースされてるよね
英語版wikipediaですら更新されてないくらい注目度低いけどw
Minix3も誰か引き継いでハッテンさせないのかな

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 07:17:47.69

アッー！

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 07:26:08.59

カーネル開発は難しいというイメージ戦略に成功したHurd。
Linux の陰の応援団だよ。

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 08:26:27.89

GNU Hurdのアーキテクチャが古いとか…無知というのは怖いもんだなw
今は何でもコンテナで動かす時代
マイクロカーネルがコンテナと相性が良いのは間違いない
ま、取り敢えず↓これでも読んどけ
https://mhatta.medium.com/gnu-hurd-strikes-back-4021433d506d

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 08:46:44.01

スレチでマウント取り出すのって爺っぽいが

**名無しさん＠お腹いっぱい。** · 2023/08/18(金) 22:48:29.81

>>908
command line interpreterってREPLのある処理系だろ

**名無しさん＠お腹いっぱい。** · 2023/08/19(土) 10:48:37.82

>>915
Machのメッセージパッシングが2桁ぐらい遅くて、とても遅くてシステム全体の足を引っ張っているのは周知の事実でいくつも論文出てるよ
原因も判っている
コンテキストスイッチでCPUキャッシュを使い切ってしまうこと

**名無しさん＠お腹いっぱい。** · 2023/08/19(土) 11:00:27.45

Hurdなんか先がない
MacOSがに元々はメッセージパッシングによるマイクロカーネル構造だったMach3.0をわざわざメッセージパッシングを単なる関数コールに置き換えてモノリシックカーネルにした
なんてのは力技の現実的解決方だがそうするしかなかったんだな
AppleはやったがHurdにそこまでの工数かけることは現実的ではないだろう

L4系列でやっている桁違いのメッセージパッシングの高速化は大きな制約を課して行っているもので使うメッセージの種類、性質の設計に関わる

**名無しさん＠お腹いっぱい。** · 2023/08/19(土) 11:01:11.03

以後俺はHurdの話はしないからそのつもりで

**名無しさん＠お腹いっぱい。** · 2023/08/19(土) 11:03:05.70

>>918
もちろんMachのIPCは遅いがそれは高機能だからだ
無意味に遅くしてる訳じゃない
GNU Hurd使ったことあるか？思ったほど遅くないぞ
ベンチマークも出てるし見てみればいいじゃん
ちなみに論文読んでるならVirtual Machine Extensions(VMX)使えばマイクロカーネルのコンテキストスイッチを速く出来るというのも知ってるはずだ
そりゃそうだ、やってることはコンテナ動かしてるのに近い訳だから

**名無しさん＠お腹いっぱい。** · 2023/08/19(土) 11:35:45.74

>>919
Appleがやったんじゃないよ
Mach上のBSD実装は最初からそういうものだった
リソース投入したのはCMUとかユタ大学辺りだよ
それがそのままNEXTSTEPで採用された

実験的にマイクロカーネル外でも実装したがすぐに放棄された
だからHurdが大真面目にやろうとしててみんな驚いた