同じことでもやる人たちが違えば違う結果になることも
コケても何故コケたかわかればいいだけでしょ

何か悪い方向で論争が激化しそうな雰囲気（何故か変換できた

OSの条件は自分があまり不自由なく使えればイイだろ。まぁ俺の意見だけど。
こう言うと誰もお前の意見など聞いてないと。それそっくり論争してる奴にノシ付けて返すから。

Ubuntuがのびず、アンドロイドやクロームOSが伸びた理由は単純で、それ用に一から作ったから
ハードが悪いとやっぱりだめで今は亡きリナックスザウルスも出来はよかったけどハード貧弱でそれが原因で消滅した

レッドハットがなんだかんだでリナックス系会社で唯一成功している
その理由はサーバ用にゼロから作ってそれを元に継続してやってるからだと個人的には思ってる
流用してそれっぽく作ったディストリビューションだといずれは内消える運命なのかなと

ワークステーションで聞いた事があるものとしてはSGIがグラフィックスワークステーションとかがあるけど、
グラフィックスワークステーションでは唯一のものだったらしいけど、それ専用にチューンしたからであって
他社のUNIXと何が違うのかという事はないらしい（伝聞）
一部で熱狂的なファンのいるiPhoneのIOSも専用にチューンされたものですよね？

サーバ用OSのバリエーションで作ったデスクトップやワークステーションが成功する訳が無い
目的が違うから分ける事自体には異論はないけど、それならサーバ用OSの流用ではなく専用のものを作った方がいいと思う
目的が違うならやる事も確実に違うんだから共通的に出来る事はあまりないと思うんだが、違うの？

単純に少ないリソース（人、モノ、金）でやる事が増えすぎたのかな
3倍の製品に3倍のリソースをかけられないとなると何処かに犠牲が出て来るかも

自動化とかでまかないきれればいいんだけどね
これでやめときます

疑問があるならfedoraのコミュニティに聞くべきでここに聞くべきじゃない。
ここの人間にはどうしようもない問題だし、多分ほとんどの人間は興味もない。
fedoraのコミュニティに聞けばオフィシャルな回答が得られるよ。
fedoraのコミュニティで聞いておいで。

>>954
そういうの聞くと、NextやBeOS思い出すわ

どっちも使ったことあるけど、スコープを絞れば良い(？)OSができるのは当たり前なんだけど、造りが良いだけじゃどうにもならないんだよね

リフレッシュレートって大事なんだね。

fedora20のKDEに変えたんだけど、「システム設定」から「モニタ設定」を選んでモニターの解像度とリフレッシュレートを合わせたのね。
そしたらなんか変、見た目におかしいとかノイズが乗るとかじゃないんだけど、モニター見てるだけで気持ち悪くなる。
なんじゃこりゃ、って思って昔のfedoraを立ち上げてモニター設定を確認したんだよ。そしたらリフレッシュレートが60Hzだった。
でもfedora20の「モニター設定」からはAUTOと30Hzしか選べないんだよね。で、どっちにしても気持ち悪くなる。
ええーいとxrandrで60Hzに変更したら、気持ち悪いのが直た。。。

まさかリフレッシュレートでこんな事になるとは(；´∀｀)

>>957
じゃあ意味ないじゃんFedora Nextって
スコープ狭めてるだけだよね
例としてあげたのものとFedoraNextの相違って何？

>>958
そもそもセルフビルドのカーネルを公開してるんだよ、ディストリビュータが
用途に応じて最適なコンパイルオプションだったりパッチだったりが必要なのに
共用のカーネルを使用するって意味だよ

もう、fedraは役割終えたんかのう

出てるよ
http://fedoraproject.org/ja/get-prerelease

商業ベースで成功しているのはハードウェアメーカとグーグル、フェイスブック、アマゾンの様なドットコム企業がほとんど
レッドハットのようなウィザード級を抱えない企業向けのサービスがある以上はフェドラのような新技術を追っかけるものも必要だと

問題はspanの様なバリエーションを作ってもレポジトリは分けずに一つのトリを維持しようとする事
目的が多様化しているのに一つにまとめる？まとまる？必要があるのかは疑問がある
クラウドならCoreOSの様に最低限まで省いたものだし、デスクトップならコマンド操作が必須ではないのかもしれない
それなのに従来のサーバ用のパッケージ管理をしかつ依存関係を維持して不要なパッケージが多数入る事は利用者にメリットが無い

CUI？CLI?は必要だけどシェル自体は速度がインタプリタ言語より数段劣るし、root権限奪取時の定番パターン
として/bin/shを起動するらしいのでセキュリティリスクになりそうかなとか
systemdはバイナリ化してあってもサービス起動にシェルがあり起動速度が上がりきらない原因かもなと思う
シェルが必須な内はデスクトップOSとしての地位は築けないと思う

>>963
ダウンロードしてきます

シェルは確かに遅いけど
開発やる人はそれなりのマシン使ってるんでは
自前で用意できなくても速いマシンをネット経由で使うって手もあるでしょ
工事中みたいにビルド請負もあるし

>>967
シェルのメリットは
今までの資産を流用できる
後は仕様が固まっている＝枯れているので追加学習が必要ない
従来の技術が使えて技術者が対応しやすいという

新しい事をやる際にはデメリットになるcvsやsubversionの頃に今のgithubの様なものを想像できた？
XFreeからX.orgになったのがWaylandに結びついているのかなと
車輪の再開発はするなっていう格言があるけど、メリットはあるのかなと
なんかもうシェルは抵抗勢力にすぎない気がする
言語仕様を変えなくても実装を変更してVM化するとかなんかあってもいいと思う
問題は誰もシェルの再開発なんて今更やろうとする人間はいない事かも

fedoraスレは入れ食いでマジ面白いわ

fedoraスレは中級しかいないよ
上級はubuntu行っちゃって、初級もubuntuからはじめるから
Linux歴の長い人でredhat系から離れたくないめんどくさがり屋がfedoraに残ってる。
だから面倒くさい質問はパス

また、内輪もめさせようとあれやこれや脳内妄想を広げてる人が

シェルとシェルスクリプトをごったにしてるやつがいるのもそのせいか

笑いが止まらんからもうやめてくれ

javaや.netはvm化してる、llvmって聞いた事無い？
多分シェルとシェルスクリプトをごっちゃにはしてないと思うけど
#!/bin/sh
はシェルに以下の文章を渡しますよだから結局はシェル実装の問題
コマンドライン操作用の言語を常時使用するコマンド記述用に使用するのは用途として誤りだよね
デバッグ終わったらコンパイルしてバイナリなりVMなりにしとけば速度が上がるでしょ

あとsystemdがサービス起動する際に”シェル”の機能を利用して実行しているっぽいんで、結局はシェル依存
ルート権限奪取の場合にまずシェル起動用コードを書くらしいですが、その応用でまずシェルを起動してからサービスを呼び出してもらいますみたいな感じ
systemdのサービス実行は
#!/bin/sh
systemdの記述サービス

>>973
めんどくさいから人に聞くんでは？

grep /bin/sh /usr/bin/system*
/usr/bin/system-config-date:#!/bin/sh
/usr/bin/system-config-keyboard:#!/bin/sh
/usr/bin/system-config-printer:#!/bin/sh
/usr/bin/system-config-printer-applet:#!/bin/sh
/usr/bin/system-config-selinux:#!/bin/sh
/usr/bin/system-config-users:#!/bin/sh
バイナリファイル /usr/bin/systemctl に一致しました
バイナリファイル /usr/bin/systemd-analyze に一致しました
バイナリファイル /usr/bin/systemd-ask-password に一致しました
バイナリファイル /usr/bin/systemd-cat に一致しました
バイナリファイル /usr/bin/systemd-cgls に一致しました
バイナリファイル /usr/bin/systemd-cgtop に一致しました
バイナリファイル /usr/bin/systemd-coredumpctl に一致しました
バイナリファイル /usr/bin/systemd-delta に一致しました
バイナリファイル /usr/bin/systemd-detect-virt に一致しました
バイナリファイル /usr/bin/systemd-inhibit に一致しました
バイナリファイル /usr/bin/systemd-machine-id-setup に一致しました
バイナリファイル /usr/bin/systemd-notify に一致しました
バイナリファイル /usr/bin/systemd-nspawn に一致しました
バイナリファイル /usr/bin/systemd-run に一致しました
バイナリファイル /usr/bin/systemd-stdio-bridge に一致しました
バイナリファイル /usr/bin/systemd-tmpfiles に一致しました
バイナリファイル /usr/bin/systemd-tty-ask-password-agent に一致しました

こんな感じでシェル依存です

面白いからそのまま続けて

シェルスクリプトは実は物凄く高度な事を簡単にやっている
(外部コマンドの力は借りてるが)
同じ事をJavaなりC#だけで書くとどんだけ大変な事になるか分からんのかね？

javaのVMは高速化のためのものじゃなく機種依存を吸収するためのもの
むしろ速度面は多少犠牲になってる

仮想コード化して早くしろといってるのか
マシンが十分早くなってるのにね、古いマシンをお使いなのかな

PC の型番も書かずに?

シェルの問題って確かマルチコア対応とかだったりする
UNIXはず～っと前からマルチコアでスレッド性能も良かった？にもかかわらずシェルはシングルスレッドで
頭からケツまで一行ずつ処理しているんだよ
何か外部のコマンドを実行する時は一々オーバヘッドの大きい外部プロセスを起動して一々環境変数を引き渡している

そもそもVM化の段階で最適化はするんだから、処理速度はあがるよ
シェルの実行速度はどこかのベンチで見たけどP言語(Perl、Ruby、Python)にすら遠く及ばない僻地にいるんだよ
GUIだとコピーアンドペーストでコマンドラインのcpをバックグラウンドで使っていると思う？
GUIだけしか使えない層にとってはシェルは速度低下と不明で不安を起こす原因でしかないよ
シェルをなくすと開発者は多分困るのは確か、だけど無いとメリットも多いのも確か
シェルにSELinuxのようなセキュリティモジュール評価機能とかシェル解析後シェルの中身を解析して動的にマルチタスクに変換して実行とかがあると
メリットは多いしセキュリティや性能の向上もできそう

セキュリティホールがあってルート権限奪取できるとかなると攻撃者はまずシェルを起動する
ネットワーク越しにGUI操作というのは結構難しいし大量に乗っ取ったりも出来にくいだろうし
シェルがなくGUIだけとなると攻撃の難易度は格段に上がる、ウイルスを作成できたり外部に秘密裏に通信できるようなコードを書けないと難しいし
ウイルスだったりネットワークに送信するのはプロにとっては発見しやすい”らしい”ので

シェルも含んだベンチのサイトはここです
http://d.hatena.ne.jp/satosystems/20121228/1356655565

並列化出来るだろボケ

仮想コードにするとMP化しやすいってどっかで教えてるのけ

>>989
見てきたけどプロセスじゃん、マルチスレッド化ってできるの
ループ内で&使ってバックグラウンド化といかでいいんだよね
それってスクリプト内で並列化してるんじゃなくコマンドを複数起動してるだけだよね

>>990
文法が単純でかつ使うものも限定的なんでシェル＋標準的なコマンドを組み込めば
並列化しやすいのかなと思っただけ
コンパイルの際に順序の最適化すれば並列化しやすい部分が明確になるのかなと
自動で並列化しやすいコード生成とかいうコンパイラとかありませんでしたっけ

依存関係がない単純な繰り返しとかはね
こういうことわかっていってるのかな

そりゃそうだけどね、複数シェルを同時に起動するとかあった場合に
シェル自体がVM化されてればスレッド呼び出して実行を繰り返すだけでいいんだと
busyboxとかあるのに同じようなライブラリは無いんだよね
ライブラリ化→言語に組込むとすればシェルで出来る事は大体網羅できるはずなんだけどな

あと依存関係はコード記述者が解決するものかなとスレッドサーフかどうかという事でいいんだよね

突っ込みすぎたみたいなのでこの辺でやめとくわ
自由に主張してみれば
たぶん、何も変わらないと思うよ
systemdとかでそういうこと（MP化＋アルファ）やってるから

思い込みが強すぎて何を言っても無駄みたいだな
話を噛み合わせる気もないみたいだし

長文なわりになにいってるのかさーっぱりわかりませんが