のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:126,816,243人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレFedora 総合スレッド Part 55

    fedora覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    951 = 949 :

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

    952 :

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

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

    954 = 942 :

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

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

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

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

    955 = 942 :

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

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

    956 :

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

    957 = 946 :

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

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

    959 :

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

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

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

    960 = 942 :

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

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

    962 :

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

    963 :

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

    964 = 942 :

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

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

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

    965 = 942 :

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

    967 = 949 :

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

    968 = 942 :

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

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

    971 :

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

    973 :

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

    974 :

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

    975 :

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

    976 :

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

    979 = 976 :

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

    980 :

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

    983 = 975 :

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

    984 = 974 :

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

    987 = 977 :

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

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

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

    988 = 977 :

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

    989 :

    並列化出来るだろボケ

    990 = 974 :

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

    991 = 977 :

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

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

    992 = 974 :

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

    993 = 977 :

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

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

    994 = 974 :

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

    995 = 975 :

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

    999 :

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


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / fedora一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について