FreeBSDを語れ Part44 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>71
ダメって言うだけならお前ですらできるわ。 rpi2でwifiトングル使えるようになったんだろうか
rtl8192cuドライバの問題かもしれんが
pkgのgccがgcc5に改名したのか btトングルも問題ありだな
移植もbtpandだけぶっつけ程度で繋がらない機器とかあるし
どんだけ人居ないんだか 某LTE搭載ノートPCがFreeBSDで使えたらなあ… Windowsの上に仮想マシン載せてFreeBSD動かうほうが楽だろ。 ウインなにがしみたいなインターネットを危険に陥れる脆弱性だらけのバグバグOSもどき使ってる知恵遅れってまだいたんか
裏でどんだけ不気味な通信してることか 今ではウインなにがしの方が
はるかに安全であることを知らない知恵遅れが
まだいたとは。>>80は珍獣だな。 はるかに安全(笑)
乗っ取られまくってる現実すら知らないとか
>>81は知障丸出しで哀れすぎるな >>83
わざわざ松沢病院から書き込まなくていいよ。 SA-17:05.heimdal
EN-17:06.hyperv releng/10.3/crypto/heimdal/lib/krb5/ticket.c 直すの忘れてるよね 久しぶりに1年前使ってきたマシンをメンテしてたら
portsnap updateしたら
portsが
"/usr/ports/Mk/bsd.port.mk", line 1042: Unknown directive
みたいなエラー吐いて使えない
portsを丸ごと入れ替えてもダメ
ググった結果使っていた9.3Rは、去年の12月にサポート切れてたらしい
それでおかしくなったみたい
バージョンアップするしかないかな
現役マシンの10.3のサポート期限は2018年04月30日だけど、すぐだよな(汗 >>91
makeだけ新しいのを持ってきたらなんとかならんかな? >>93
9.3から10.3へのアップグレードは、ライブラリとか色々おかしくて
結局、11Rを新規インストールした!
まあその方が安心だよね >>98
公式ホームページの予定表通りだけど
それ以外でその手の告知ってどこ見ればわかる? 俺はお盆で実家に帰ったら、Ryzenでパソコン組んで11.1をインスコするんだ コアばっか増やすベンチ詐欺CPUとかよく買うわ
エンジニアはSingle Thread Ratingでしか比較しねえっつの
Single Thread Ratingあたり消費電力最低CPUとか紹介して欲しいわ FreeBSDは計算に向いてないから
計算するんならLinuxの方がいい
GotoBLASを作った後藤氏が
> ページカラーリングとかは当然行っていると思うのですが、
> 最近の巨大なキャッシュに対応させるようなことはしてい
> ないと思います。Linux もまだまだですが BSD 系列はメモリ管理の
> 粒度が小さすぎて、物理アドレスでの連続性があまり得られません。
> さらに、プロセスのスケジューリングでも同一のコアに固定した
> スケジューリングではなくて、コロコロと移動させてしまいます。
> ま、ベンチマークをとってみれば一目瞭然
という事で、ベンチを取ると、マルチコアでSIMD命令(SSE2やAVX)を使うような計算の場合
Linuxは理論値の90%以上を出せるけど
FreeBSDは70%程度だとか FreeBSDは高負荷中のスレッドをコロコロとコア移動するの? >>100
自分も公式ページしか知らないし見てない(´・ω・`)
MLかIRCで流れてるんじゃないかしら。 10.4 待ちで 11.1 なんかどーでもいい者としては手持無沙汰なんで
r321371 を 10.3 に持ってきたりして遊んでます。 もうコア単体での速度上昇は限界なのかもな
消費電力を犠牲にすれば別だが クロック数を語る時代はもう過ぎたからなあ
かと言って単位クロックあたりの演算能力が劇的に向上するわけでもないし
それでいて製造プロセスの技術向上によりシリコン面積あたりのCPU実装部分は年々小さくなっている
この減った部分を埋めるためにGPUやノースブリッジどころかサウスブリッジまで乗せるようになったのは当然の流れ
まだ隙間がある?CPUコアを増やそうか 14nmで足踏みしてるのはなぜだろうか
10nmのCoffee Lakeがキャンセルされ
新規発表されるのは14nmプロセスのものばかり
一方で7nmが製造成功し、5nmも視野に入っているという 分子的に倍数にならないタイミングとか解明されてない理由があるんだよ >>101
Ryzenは
まだサポートされてない。 >>116
Performance per watt TDPで比較して
M3-6Y30が4.5W
i3-5010Uとi5-4300Uが15W
Performanc per wattは
消費電力が低いM3-6Y30(7.6)が他の2つ(5.8)より高いスコアなのは妥当でないかい M3-6Y30...31.04pt/W
i3-5010U...48.64pt/W
i3-5010Uのほうがワットあたりパフォーマンスが高いって意味じゃないの? M3はクロックの低さをキャッシュで補っているから
処理が重くなるほど効率が悪くなるように見えるな
レイテンシも低いだろうしバランス悪いよね キャッシュはワンパ処理のベンチによく効くからな
pt/Wでの比較はかなり重要だろう Atom系は今のApollo Lakeで各コア2MBで
次のGemini Lakeから3MBになる
Gemini の次はMercury Lakeかな レイテンシが悪いって言いたいんだろ
そのくらい解釈できずにくだらないレスするお前は脳タリン 悪いってのもいわなくね?
普通大きい小さい。せめて長い短い。 要するにクロックが低すぎると電力効率が悪いってことでFA? キャッシュのレイテンシが低いのがバランスが悪いんだってさ。
dramのレイテンシが高いから間にsramを設けて、少ないsramで効率よくレイテンシ下げるのがキャッシュなのにね。 そんなこと議論してないだろ
救いようのないアホだなお前 >>129
線形ではないのだからそういう言い方はよくない。
高すぎても低すぎても電力効率は落ちるということ。
モバイルで要件がまず消費電力なら効率落としても消費電力を下げるのはあり。 でもさ、何かを処理するのに余計にバッテリ食うんだろ
ほんとにありなのか? >>137
夏場だと美味そうだな。>冷点心
どこのコンビニ出撃ってるか教えてくれくれ。 Intel "Gemini Lake" Low-power Architecture Features Wider Instruction Decode
ttps://www.techpowerup.com/235514/intel-gemini-lake-low-power-architecture-features-wider-instruction-decode
次期AtomのGemini Lakeが4デコード・4パイプらしい なんか*lake世代って*well世代に比べてPerformance per watt落ちてるよな
萎えるわ 11.1-Rに更新完了。
更新用のBEを現環境から作って/mntにマウント、chrootで閉じたら/usr/srcを11.1にして
再起動無しでカーネルのインストールからpkgの更新、不要ライブラリの削除まで全部やってから
更新用BEをアクティベートして再起動。
えらく簡単になりましたね。
特にBEをマウントしていじれるのでトラブルシュートがすごく楽。 11.1Rのクリーンインストールで、xorg 7.7_3 入れたけど、Xorg -configure が segmentation fault でエラーになるね。
まぁ、xorg.conf なしで動かすから良いんだけどね。 このように不具合は誰も報告しないので一向に枯れないオープンソース。
逆にクローズドで金払ってると動かんぞ、ゴラァって言ってくれるんだよね。 じゃあウインなにがしはなんでバグの数がうなぎ上りなんだよ? 多機能な上にユーザ数多いからじゃない?
BSDに限らずLinuxも、ユーザ数増えたら今の比じゃない程ぼろぼろ致命的な穴が出てくると思う
てか古いAndroidとか、Googleも匙投げて問題放置だっけ? >>148
セキュリティホール報告数はFreeBSDより少ないだろう。
デスクトップに関しては未だBSDはまともに使えない。キミは一体何を基準にバグの数を数えたんだ。 >>148
ウインなにがしはダダのハードウェアチェッカーだろ
例えるなら付属電池みたいなもの
脳みそある奴が使うような代物じゃない ブザマなれいさ製スクリプトウイルスに感染してないFreeBSDは最高やね ウインなにがしってPC買うたび消し去る前に一応動作チェックするけどさ
7あたりでUNIX系に追いつかれて以降わざとか思うほどGUI自滅し続けてるよな ttp://i.imgur.com/yuvPGGh.png
追い付かれ・・・ん??? >>146
>11.1Rのクリーンインストールで、xorg 7.7_3 入れたけど、Xorg -configure が segmentation fault でエラーになるね。
>まぁ、xorg.conf なしで動かすから良いんだけどね。
この場合はどこへ報告なのか悩む。
segmentstion fault でcore吐いて落ちるは明らかにバグだし、報告すべきなのは分かってるんだが。 結局のところ、11.1RでApollo Lakeはサポートされてるの?
(eMMCの問題の件) >>157
バカかどうかに関係なく、ユーザが多いといろんな環境で使われるからバグが発見されやすいんですよ。 発見されようと直せる人間が毛ほどしかいないんだから無意味だろ
つかこのアホはバグの酷さについてちょっとググることすらできんのか
ソース公開されてんだからその気になりゃ自分で直せるしな どっちがどっちのこと言ってるのかアホだと理解できんかも >>161
じゃあ>>146のバグもその気になって直してくださいな
直せる人間が毛ほどしかいないのがわかってるんならそれくらい協力できるでしょ そもそも直してまで使わなくても他に選択肢が腐るほどある パナソニックあたりの守銭奴経由して相続利権の社会的寄生虫を儲けさせるために協力するとか奇特すぎるだろw
まあ月30万程度のベーシックインカム制度でも始まれば何だって直してやらんでもないけどな 折角、直すって言ってるのに、
何で直してまで使わなくてもいい
みたいな言い方するんだよ。 >>146
ログを見てエラーの出ているライブラリなりアプリケーションをpkg removeで削除すれば
動くよ。 そんなバカな。ちなみに、エラーログは下。
--------
[ 226.174] (EE) Backtrace:
[ 226.176] (EE) 0: /usr/local/bin/Xorg (OsInit+0x38a) [0x5abfba]
[ 226.177] (EE) 1: /lib/libthr.so.3 (_pthread_sigmask+0x544) [0x8025cbd94]
[ 226.179] (EE) 2: /lib/libthr.so.3 (_pthread_getspecific+0xe5f) [0x8025cbbef]
[ 226.180] (EE) 3: ? (?+0xe5f) [0x7ffffffffff2]
[ 226.182] (EE) 4: ? (?+0xe5f) [0xe5f]
[ 226.184] (EE) 5: /usr/local/bin/Xorg (InitOutput+0x11ea) [0x47faca]
[ 226.185] (EE) 6: /usr/local/bin/Xorg (remove_fs_handlers+0x38b) [0x43b48b]
[ 226.187] (EE) 7: /usr/local/bin/Xorg (_start+0x17f) [0x42506f]
[ 226.188] (EE) 8: ? (?+0x17f) [0x80083417f]
[ 226.189] (EE)
[ 226.189] (EE) Segmentation fault at address 0x0
[ 226.189] (EE)
Fatal server error:
----------------------- ■ このスレッドは過去ログ倉庫に格納されています