FreeBSDを語れ Part49

■ このスレッドは過去ログ倉庫に格納されています
1デーモン君
垢版 |
2019/09/06(金) 20:47:50.69
The FreeBSD Project
https://www.freebsd.org/ja/

前スレ
FreeBSDを語れ Part47
https://mevius.2ch.net/test/read.cgi/unix/1507827321/
FreeBSDを語れ Part47 (再利用のため実質Part48)
https://mevius.2ch.net/test/read.cgi/unix/1508085628/

関連スレ
初心者もOK! FreeBSD質問スレッド その123
https://mevius.2ch.net/test/read.cgi/unix/1522192115/
2019/09/11(水) 17:47:22.55
おまえ、Linux板に行った方がいいんじゃね?
2019/09/11(水) 17:57:58.06
きっとLinux板で爪弾きにされて流れてきたんだろう
かわいそうに
2019/09/11(水) 18:20:22.55
FreeBSDは人材不足でもう保守できなくなっている。
GPLが嫌いだからこの板にいたがもう勝負は決したようだ。
2019/09/11(水) 18:34:18.43
後はグーグルが買ってダメにして

マイクロソフトがおいしくいただく、とw
2019/09/11(水) 18:34:54.72
きちんと保守できてるのはOpenBSDだろ。FreeBSDはもうオワコンかもな。
2019/09/11(水) 19:17:59.17
OpenBSDにはどこの金が入ったんだよ
2019/09/11(水) 20:26:51.81
保守状況を網羅している58が巨額の寄付をしたに決まっている
2019/09/11(水) 21:04:22.54
スパコンで負けモバイルで負け
デスクトップPCはそれ自体が縮小
最後の砦だったIAサーバーもDocker全盛

jailを上手く宣伝できてたらなー
2019/09/11(水) 21:14:36.34
勘違いしてる人がいるな。金で解決する問題じゃない。
穴のないコードを書こうと意識しているかどうか。
複雑でわかりにくいコードを嫌い、シンプルでバグのないコードに変えていこうとするメンバーが集まっているかどうか。
2019/09/11(水) 21:23:18.37
そんな意識の高い人達ってかっこいいですね。
FreeBSD Projectはどうなんでしょうか。
2019/09/12(木) 00:18:22.91
>>61
有力なパトロンがつかなかったのが痛いね
2019/09/12(木) 01:42:39.86
どうなるの(´；ω；｀)
2019/09/12(木) 05:27:59.03
個人商店のO

一応組織のF

カネを突っ込んでコントロールするならOの方がやりやすいな

googleがカネやクビを突っ込むとロクなことにならん
2019/09/12(木) 05:39:38.75
まずportsやmakeの複雑で意味がないコードを棄てたら?
2019/09/12(木) 06:47:45.56
例えば？
2019/09/12(木) 07:47:20.47
>>68

mk/*
2019/09/12(木) 07:55:09.69
>>69
してその心は？
71名無しさん＠お腹いっぱい。
垢版 |
2019/09/12(木) 08:01:13.22
iXsystemがパトロンやなかたけ？
YahooはLinuxに逝ってもた
2019/09/12(木) 08:04:02.74
>>66
どっかの過去ログでも「Oは独裁制でFNは選挙制」って言ってましたもんね。
その独裁者が金に左右される人物かどうかは分かりかねますが。
2019/09/12(木) 08:10:33.30
>>69
具体的な代替案は？
2019/09/12(木) 08:48:07.72
>>73
どうせ ports 経由の local/ はGNUでベタベタだろ

local/ にGNUの最低限の環境を突っ込んで後はぃぬと同じ

OSに mk/*　なんて全く役に立ってないんだし 全廃でおｋ
2019/09/12(木) 08:52:50.84
>>74
その結果既存のユーザーにどんなメリットがある？
2019/09/12(木) 09:25:58.48
>>74
最低限の環境とは？
2019/09/12(木) 10:50:01.76
>>62
というか数万、数千万項目の単体テストなんてお金貰わないと面倒でやってられないんだよ。
意識の問題ではなく品質が低いのはそれが理由。
バグ報告してたも碌に対応しないような輩がテストなんかしてるわけがない。
2019/09/12(木) 13:11:16.53
>>77
数万、数千万項目の単体テストなんて元々やってないでしょう。
バグレポートへの対応を早くやるだけでいいのでは
2019/09/12(木) 14:14:07.32
>>75
FreeBSDにしか通用しない煩雑なものを理解する必要がなくなる

ports は、パッケージを提供する側のことを考えて作られていてユーザの自由を制限するものでしかないんだよ

>>76
src/*
2019/09/12(木) 14:14:24.05
民間の開発ならどこもやってるよ。そもそもやらないと納品できないだろう。
2019/09/12(木) 14:16:10.79
失礼w

>>76
src/*
これは削除W

LFSというLinuxの配布があるが、それでインストールされるOSの起動に必要なもの以外全部だ。
2019/09/12(木) 14:27:12.15
一方Theoはstrlcpyの使用を義務づけた
(GNU的には批判有り)
2019/09/12(木) 14:34:03.89
GNUのやつらはstrlcpyが嫌いだろうねw

共産主義が宗教を嫌う宗教と同じものってことに似てるんだw
2019/09/12(木) 14:49:49.26
>>79
お前の脳みそが ports を理解できないだけだろが
このノータリンw
2019/09/12(木) 14:52:44.84
>>84
おいらが煩雑だと感じるものを一般ユーザが使える分けないんだよ
2019/09/12(木) 15:22:45.84
>>85
portsが煩わしいなら/usr/portsを削除するか、インストール時にportsを選択しなければいい。
FreeBSDにはバイナリパッケージの配布もあるし、貴殿の様な達人なら野良ビルドでも十分実用的な環境を構築できるだろう。
但し一つだけ声を大にしても絶対通らないことがある。それは個人の独断で不特定多数のports使用権を奪う事。
一個人のエゴでユーザーの選択の余地を無くしてしまう事にはあまり賛成出来ない。
どうしても実現したいのであれば、貴殿がプロジェクトの重鎮になるか、フォークして独自OSを作るしかない。
2019/09/12(木) 15:33:35.38
なるほどこれは危険だ。セキュリティ重視のLinuxで実装に反対されるのもうなずける

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

strlcpyが危険な例：

char cmd[] = "rm *.bak";
char buf[5];
strlcpy(buf, cmd, sizeof(buf));
system(buf);

（sizeof(buf) が5であるため、最初の5-1=4文字しかコピーされず、"rm *" が実行されることになります）
2019/09/12(木) 15:34:41.83
>>85
貴殿程の知識と情熱を持ってすれば難しいことではないはず
2019/09/12(木) 15:44:44.02
そうしてこのまま何も変えずに
だらだら長くやってたものだけが慣れてるというだけで使うものになっちまうんだよな。

ま、どうでもいいけど。
2019/09/12(木) 16:06:55.49
>>89
いくら素晴らしい知識や技術、理念を持っていても民意を得られなければ絵に書いた餅、宝の持ち腐れである
2019/09/12(木) 17:32:00.01
>>90
賛同してくれたか。

もう腐ったんだよ、BSDは。
2019/09/12(木) 17:37:21.97
>>80
FreeBSDの話をしています。
金もらって奴隷のように働かなきゃならない受託開発のやり方なんかどうでもいいんですよ。
2019/09/12(木) 18:07:23.80
なら金をもらえないやり方でどうぞ
2019/09/12(木) 18:10:36.20
金は後からついて来る、か。
美しいな。
95名無しさん＠お腹いっぱい。
垢版 |
2019/09/12(木) 18:11:24.86
別れはいつもついてくる
幸せの後ろをついてくる
2019/09/12(木) 18:53:37.04
Cの文字列処理ライブラリは何とかした方が良いよな…
少なくとも
struct String {
size_t length;
char *string;
};
を引数に持つ文字列処理ライブラリを標準に含めるべき
そうすれば不幸な事故はかなり防げるはず
2019/09/12(木) 19:10:25.27
>>96
シェルスクリプトあるいはスクリプト言語があるだろ
何でもかんでもCを始めとしたネイティブコードで処理しなきゃならないっていう脅迫概念を捨てろ
2019/09/12(木) 20:44:24.93
>>97
組み込みとかCを使うことなんて山ほどあるだろ
Cは人気言語第3位だぞ
2019/09/12(木) 20:53:03.34
>>96
そこは適材適所で、面倒だと思えば別の言語使えばいいだろ
標準型に文字列があったり、標準ライブラリで文字列操作が充実してるやつ
2019/09/12(木) 21:08:09.78
>>98
このスレはFreeBSDを騙れ?だろ
誰かコイツをつまみ出せ！
2019/09/12(木) 21:08:29.17
>>80
数千万項目とかどんだけでかいシステムなんだよw
2019/09/12(木) 21:28:23.82
蜂の巣で草
2019/09/12(木) 21:41:45.41
>>87
そんなコードを書くやつなら消えたほうが良いだろw
2019/09/12(木) 22:46:06.55
>>96
Golangを使うんや
2019/09/12(木) 23:01:20.45
日本語メーリングリストもこのくらい活発になればいいのにねw
2019/09/12(木) 23:13:54.07
FreeBSDスレなのにCを毛嫌いしてる奴が多くてﾜﾛﾀw
そんなにC使いたくないならWindowsでも使ってろ
2019/09/12(木) 23:57:04.30
>>95
ＪＡＳＲＡＣの方からきました
2019/09/13(金) 00:05:22.74
Goよいよね
2019/09/13(金) 00:15:07.90
>>95
それが私のSATAなのか
いつも目覚めればboot -s
2019/09/13(金) 00:23:22.68
>>96
Pascalのstring型が内部的にそうなってたと思う。
2019/09/13(金) 00:38:23.48
FreeBSDな人たちはstd::stringとか使わないの？
2019/09/13(金) 00:52:50.79
>>110
昔の言語はC以外はlengthを持つのが主流だったと思う
Fortranもそうだし
2019/09/13(金) 00:53:55.14
crystal使いはいないの？
俺も使ってない
2019/09/13(金) 03:46:38.01
>>111
使うよ(^o^)
2019/09/13(金) 04:08:39.23
>>106
そんなLinusさんみたいな事云わんでも(笑)
116名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 04:47:59.22
perl で何でもかんでもやってまーす
2019/09/13(金) 08:44:45.65
ファミリーベーシックで何でもかんでもやってまーす
2019/09/13(金) 10:06:11.87
COBOLはまだまだイケるぞ

経産省が棄てたんだからw
119名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 11:27:02.29
>>96
mallocしたポインタのオフセット[-1]あたりにsizeがある実装が多いから
それをもっと早く規格化すればよかったと思う
2019/09/13(金) 11:51:49.70
>>119
で型を間違えて大惨事と
NULLは0だ、intは４バイトだという老害が多いんですよまだまだ
121名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 12:05:51.57
mallocで管理されるsizeはバイト単位やろ
wchar_t が 32bit とか言う話か？
2019/09/13(金) 12:23:28.78
>>119
実装を規定するとか最悪やん
やるなら確保した領域サイズを取得する関数を規定すべき
2019/09/13(金) 12:29:36.21
>>101
碌にテストなんてやったことないというのがバレバレだなw
2019/09/13(金) 12:35:23.45
無駄なチェックを端折れて高速な処理を書けるからC使ってるのに、
遅い堅牢ならライブラリをC、C++に用意しろと言うような低レベルPGなら元からC、C++使うなってことだな。
2019/09/13(金) 13:48:35.80
今現在堅牢な高級言語は生き残ってるか?
2019/09/13(金) 14:06:11.98
堅牢な高級言語しか生き残ってないだろｗ
アドレスを直接扱える危険な言語って
たくさんの言語のなかどの程度あると思う？
2019/09/13(金) 14:10:10.06
>>123
へー、すごいねー
で、お前ん所のテスト密度っていくらぐらいなんだ？w
2019/09/13(金) 14:20:06.52
>>126
Cは元々アセンブラの代替として作ったものだからポインタが扱えて当たり前ですよ。
C = 高級アセンブラだから。それが嫌な人はFortranでも使っとけということで。
2019/09/13(金) 14:28:27.29
>>124
ならCじゃなくてアセンブラ使ってろよ
130名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 17:39:53.55
>>124
ほんそれ

関数入るたびに境界チェックするコードとか入れてたらCの有難味がないな
2019/09/13(金) 19:10:51.35
OpenBSDのportsに入ってたパッチw

--- texk/dvipsk/writet1.c.orig
+++ texk/dvipsk/writet1.c
@@ -1449,7 +1449,9 @@ static void t1_check_unusual_charstring(void)
*(strend(t1_buf_array) - 1) = ' ';

t1_getline();
+ alloc_array(t1_buf, strlen(t1_line_array) + strlen(t1_buf_array) + 1, T1_BUF_SIZE);
strcat(t1_buf_array, t1_line_array);
+ alloc_array(t1_line, strlen(t1_buf_array) + 1, T1_BUF_SIZE);
strcpy(t1_line_array, t1_buf_array);
t1_line_ptr = eol(t1_line_array);
}
2019/09/13(金) 19:11:33.33
>>131
ごめんなさい。

全然違うサイトに誤爆です。
2019/09/13(金) 19:57:49.49
>>130
Cなら
if ( checkfunc( func ) ) ...
と1行で書けるから大したことなさそうに見えるけど、これをアセンブラで書くと、
汎用レジスタ全部退避して、戻りアドレス設定して、新しいスタックポインタ設定して、
チェック処理を実行して、戻る直前に汎用レジスタ全部戻してリターンするので、
毎回こんだけの処理させてわざわざ遅くするのが嫌になるんだよね。
全レジスタの退避と復帰を毎回実行させるのってほんとに無駄に感じる。
本当は、破壊されてもいいレジスタは関数ごとに異なるはずなので、破壊されて困るレジスタだけ退避
するようにすれば最適化されていいんだけど、そうするとどこかを書き換えたとき、元に戻さないといけない
レジスタができて、それの退避を忘れただけで吹っ飛ぶ。
2019/09/13(金) 20:16:21.30
>>133
三行にまとめてくんないと、1ミリも理解できないんだけど
2019/09/13(金) 20:29:34.91
素敵なコンパイラなら4行くらいにまとめてくれないかな....
2019/09/13(金) 21:01:24.16
>>134
理解しなくていいよ。
x86系の知識だけで、とりあえず知ってるワードでマウント取ろうとしてるだけだから。
2019/09/13(金) 21:21:08.17
確かMS-C6.0の頃か？（うろ覚え）破壊しないレジスタは退避しなかった筈だが？ｗ
十数年前からメジャーどこのコンパイラは短い関数なら勝手にインライン展開するのが殆どだし
いつの時代の話をしてるんだかさっぱり
2019/09/13(金) 21:24:57.47
流し読みで読み飛ばしちまったけんども
アセンブラでプロシージャ書いたとこでコーダーがスタックポインタを設定する事なんて先ずありえんｗｗｗ
2019/09/13(金) 21:28:15.19
>>137
俺も最初そう思って ？？？ 状態だったけど、よく読んだらアセンブラで書いた時の話みたい
アセンブラで書く時に全レジスタ保存なんてよほど間抜けでないと普通しないけどな
2019/09/13(金) 22:25:06.94
知的障害者きてんね
2019/09/13(金) 22:35:27.85
支離滅裂さからは糖質の臭いがする
2019/09/13(金) 22:52:56.29
>>136
俺は一桁ロリに mount -f したい
2019/09/13(金) 22:57:17.03
さすがに一桁はないわ
2019/09/14(土) 00:36:34.21
>>119
それはC++の場合だな
Cではそんなことする処理系が無い
2019/09/14(土) 00:41:44.98
ちなみにC++では配列の各要素に対してデストラクタを呼ばなくちゃいけない都合上サイズが格納されている
146名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 05:03:45.80
>>142
おまわりさんこの人
2019/09/14(土) 05:13:55.38
童貞です
2019/09/14(土) 06:22:47.86
ｗｗｗ
2019/09/14(土) 10:12:55.40
>>133
レジスタ退避と復帰は専用の命令が有るけど、CPUは実際には見えてる以上にレジスタを持ってるから毎回律儀にメモリに退避とかしてないよ
150名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 10:53:54.50
https://mao.5ch.net/test/read.cgi/linux/1560665525/
286
俺はもうWindowsでVirtualBoxは諦めてるんだが、
FreeBSDとかSolarisとかどうしてもVirtualBoxでしか動かせなくて
必要なときはMacを使ってる。

FreeBSDとかSolarisがHyperVでも動かせるなら良いんだけど
どうもうまく行かない。
151名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 11:01:09.06
>>145
delete [] hoge;
のときですね
良く [] 付け忘れるので防止策教えてくだされ
2019/09/14(土) 13:04:16.01
>>133は、アセンブラでコード書いてると自然にそうなるってこと。
ルーチン内ではできるだけ汎用レジスタを使って処理したほうが早くなるから、最初にメモリから必要なデータを持ってきた後は
極力レジスタだけで処理するように書く。後からその処理の途中に別の処理を入れることになって、別の関数を挟んだとすると
レジスタの値を変えてはいけないから、その関数に入ったところで全レジスタを待避し、関数の終わりで戻さないといけなくなる。

Cで同じことをしてアセンブラに展開したコードを見ると、変数の値はメモリに置いておき、必要になったらレジスタにロードして
計算したら結果をまたメモリに戻すという処理をしている。後から途中に関数が追加されても、その関数はメモリから値を
持ってきて処理するからレジスタを退避する必要はない。関数に渡すパラメータなどもスタックに入れて渡すから
同じくレジスタを退避しなくて良い。

しかしこのやり方ではメモリとレジスタ間のセーブ/ロードが頻繁に起こるので、アセンブラのソースで見るといかにも効率が悪くて
遅いとわかる。当たり前だがメモリ - レジスタ間のセーブ/ロードはレジスタ内だけの演算よりずっと遅い。
そうするくらいなら、必要なときだけレジスタを退避・復帰させた方がまし。さらに、これがforなどのループ内で使われた場合、
この遅さがプログラム全体の遅さになる。Cコンパイラのコード生成は、アセンブラから見れば遅くて無駄だらけに見える。
その分、ソースが見やすいから便利なんだけれども。
2019/09/14(土) 13:06:51.37
>>151
今から作るならnew/deleteなんてやめてvectorとかにしなよ
deleteの[ ]付け忘れるような人は例外時の解放忘れとかもしそうだし
2019/09/14(土) 13:08:22.67
>>152
頼むから今時のまともなコンパイラ使ってから語ってくれ…
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況