Linuxは、開発環境が40年前と同レベル
間違ってもらっては困るのは、それはコマンドライン・メインなのが主因ではないということ。
本当の一因は、本来手書きでも簡単な Makefile の作成をわざわざ難しくしてしま
う autotools を権威に流されたのか多くのプロジェクトが使ってしまっている事にある。
高々 Makefile 1つ作るためにも以下のような工程を踏まなければならない。
本来、典型的には、ソースファイルである *.c, *.cxx, *.cpp を指定するだけ
でも自動生成する事が出来るはずなのに、ツール類が馬鹿だからそうなってない。
なのに、「Linuxはプログラマーには便利」などと嘘情報が流れるから、普及しない。
しかも、カレントディレクトリのスクリプトの実行に「./configure」などと「./」
の指定が必要なのも馬鹿丸出し。ファイル名に大文字小文字の区別がされているのも馬鹿。
ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが
$ find . -name '*.c' | xargs -n 1 -i cp -p {} /xxx/aaa
などとしなくてはならず長すぎ、馬鹿ですか? しかも、'*.c'の部分が、*.c と書かれている
説明が溢れているがそれだとbashが展開してしまうのでたまたま上手く行く事はあっても、
実際には正しくない。また、mountしないとディスクが認識出来ないのも初代PC-8001の
レベル。PC-8801で自動マウントできるようになったのに(いつの時代(苦笑))。まずは、
不便さを認めるなければ、改善すらままならないのにそれすら全否定。正直に便利と思って
るなら井の中の蛙で馬鹿で無知なだけだ。そして、僅か1点でも間違いがあれば全てが間違って
いるように全否定してしまうLinux信奉者の愚かさもアホとしか言いようがない。 正直、C89以前のCなんか読めたものじゃないし、
かといってC++11以降の機能使いまくったソースも読めたものじゃない。 >>637
嘘だよ。初心者に優しいのは、テキスト編集だよ。
英語が苦手なだけでしょ。 マウントなんて、大分前からクリックするだけやんけ
それよりディスクの故障チェックもできないとか、そっちのほうが怖いよ >>633
へー、今はむしろナウいんだけどな
取っとけるし 見通しがよいかどうかはシステムのサイズによる。複雑になれば階層構造のレジストリのほうがいいに決まってる。
基本的な型は用意されてるし、細かくセキュリティも設定できるし、読み書き用のAPIも用意されてる。
OS起動時に必ずバックアップを取ってから起動してくれるのもメリット。
なんでもviで作業したいというのが諸悪の根源。開発環境が50年前とい言われても仕方がない。 >>665
英語苦手じゃないけど、ちょっと言ってる意味がわからん。とりあえず、レジストリはめんどくさいぞ。 レジストリより環境変数のほうが使いやすいよな!!!
って人は少ないだろう。 みかんとしいたけだったらみかんのほうが美味しいよな 何も足す必要がないということは究極を極めているということであろうか。 xmlの優位性はテキストだということだけれども、実際テキストエディタでxmlを閲覧すると醜悪そのものだよね。 >>4
Windowsのビルドって、どれぐらいかかるか知ってる? >>669
そういう意味なんだけどね
テキスト編集の方が楽だけど、設定ファイルの雛型に
書いてある説明が英語なのは、日本人にとって辛いかなと
慣れればなんてことないけど。 ちなみに勘違いしてるみたいだけど
autotools 作ったのはGnuではないよ。
自動的にMakefile作るシェルスクリプトが回覧されていく
うちに、みんなで改良加えて、なんとなく出来上がったのを
Gnuが採用しただけだよ。移植性を重視してたからね。
別に好きな奴使えばいいんだよ。気に入るのが無ければ
自分で作ればいい。それが自由であることの尊さなんだから。 autotools使うのは、それだけ多くのライブラリに依存
しているからで、その分のコードを書く手間を
省けるのだから、大したことでは無いね。移植性も
高まるし。でも、それが必要ないなら、別にMakefile添付でも
全然問題ないし、そういうプロジェクトも少なくない。
他のビルドツール利用でも良いし。なんか
勘違いしてない?これらはあらかじめ与えられてるん
じゃなくて、享受するものだよ。嫌なら自分でやるんだ。
近所の落ち葉をかたずけるのと同じさ。君のために
誰かのためにやるんだよ。そう思うなら、自分で
どうにかするんだよ。 良いこと言うね、全くそのとおりだわ
読んでねーけど INIのように書式とデータ構造とAPIが共通化されてるテキストベースの多層構造の設定を保持するメカニズムがあればよいんだよ、Linuxに。 ハイ論破厨ってたまに5chで見るけどいつも論破できてないよな。同一人物? 「ハイ論破」はダサいという風潮はとうにご存知だが必要不可欠な機能
C/C++やPerlのセミコロンみたいなもの 私たち日本人の、日本国憲法を改正しましょう。
『憲法改正國民投票法』、でググってみてください。
平 和は、勝ち取るものです。拡散も含め、お願い致します。 >>684
あなたは、日本人じゃない気がする。
日本人なら絶対しない「ご存知」「機能」の使い方してるから。 へー、LinuxにはJSON読み書きする「共通化されたAPI」ってあるのかぁ。
知らなかったな。
Cで使おうと持ったらインクルードファイルは何をしてして、どんな関数呼べばいいんだろう?
定番のunistd.hかな? JSONってそんないいもんじゃないよね、コメント書けないのは致命的 jsonが爆発的に普及したきっかけはバイナリ保存はしたくないけど、オブジェクトをそのまま保存したいって需要だから
設定に使うとしても開発者よりなんだよな。linuxは開発者フレンドリーだから開発者マインド無いときついってのは理解できるけども。 階層が深くないならiniが見やすくていい
階層が深いならyamlだし、記述性ならxmlだし、どれも一長一短あるけど、テキストエディタで開く設定ファイルならiniは使いやすい 複数行コメントを書けて、日本語も問題ない、Ruby が良い
=begin
複数行
コメント
=end Windows界はいろんな産業ロボットを使ってモノを生産しているのに
Linux界はいまだに手作りでモノを生産しているようなもんだからね。 >>1
Unix は世界最古のOSらしいので、最初は良かれと思って決めたものが、
使ってみると使いにくかった、ということはあるかもしれない。
一例として、
$ コマンド名 パラメータ >a
などとして、リダイレクトするとき、stdout と stderr が分かれている
のも、現実的には不便。
$ . スクリプト名
と先頭にピリオドをつけないと環境変数がスクリプトによって設定できない
のも不便。
どちらも、DOS では修正されていた。DOS の方が後発だから。 資本制企業はいかに人件費を削って量産するかを常に考えている。
少ないプログラマでより多くをと。
ところがオープンソースの世界はコーディングすること自体が楽しい
って人々の集いだからな。効率化へのインセンティブが小さい。 >>697
別の環境変数で処理したいなら別の端末を開けば良いわけだから、
スクリプト内での設定を反映しないという仕様は、今となっては
アリガタ迷惑だと思う。
ただ、行儀の悪いわけの分からんスパゲッティーで解読するのも
時間の無駄なスクリプトも多いが。 >>697
stdout と stderr と時系列的に合わせて出力しないと、解読しにくい
場合があるので、結局、2つの出力を合成したいことが多く、
1&>2 a
だったか、覚えていられないような変な記号を書かなくてはならない。
あと、tee コマンドも覚えにくい。 というか何もかも覚えられない
脳が退化しているのか? &> a
と、
1>&2 a
の両方の書き方があったり、export が必要あったり無かったり、
そんなアホみたいなものは、むしろ高級な脳であるほど覚えられない。
高級な脳は、共通原理や一般法則だけを覚えようとし、単純で無意味な情報は
削除される傾向があるから。 >>1
なんという愚かなOSなんだろう。
DOSと同じことがこんなに長くなる :
[DOS]
$ コマンド名 >a
[Linux]
$ コマンド名 1>a 2>&1 >>703
> [DOS]
> $ コマンド名 >a
↑間違い
> [Linux]
> $ コマンド名 1>a 2>&1
↑1は不要
正しくはこうだよ
[DOS]
$ コマンド名 >a 2>&1
[Linux]
$ コマンド名 >a 2>&1
参考
http://tooljp.com/windows/doc/stdout-stderr/stdout-stderr.html
> (4)標準出力と標準エラー出力を同じファイルにリダイレクト
> mycmd.exe > stdout-stderr.txt 2>&1 >>705
DOS に関しては、そもそも原則として多くのツールが、stderr を使わない流儀
だったので、stdout だけをリダイレクトすれば十分だったんだ。
だから、その意味で、
[DOS]
$ コマンド名 >a
は間違ってない。
要は、トータルの使い勝手で考えた場合だから。 ほらほら、間違いを指摘されて、
焦ってきてるぜwww つまり、DOSコマンドは設計に沿わないアプリが多かったということかな? >>709
いや違う。
最初からそれを前提にしていたので間違ってない。
あなたは、DOSの事知らないからそんなこと言ってるのでは。 >>710
いや、むしろ、stderr を滅多に使わないのがDOSの流儀だった。
少なくとも、コンパイラのエラー表示は100%、stdout に出ていたし、
その他のフリーソフトなんかの表示もほぼ、そうだった。 使いにくくなるだけなのに、stderr を使っているソフトが多いのは、Unix系の
プログラマには、実は真の意味では頭の悪いのがいっぱい混じっているから
ではないか。 明言していない前提
他社を憶測で知らないもの扱い
ごく主観的な流儀
主観的な使いにくさでOSの草分け的な開発者を無能扱い
これだけでまともに取り合う気がなくなる。 元々、stdoutとstderrが分れているのには理由がある。
理由もなしに分けたりしないという想像力があれば憶測でモノを言うと恥ずかしいことぐらいわかりそうなもんだが。
標準出力がUIを兼ねていたのでユーザーへのメッセージがerrで塗りつぶされるのが良くないし、
出力結果を次のコマンドに渡すときなどにerrメッセージが混ざると困るし、
コマンドが入力待ちの状態の時、errなんか出たらなにで止まってるのかわからないからな。
当時は無視するしか無いerrもあって切り分けるしかなかった。
例えば標準出力をファイルを書き込んでる最中にエラーを出力するにはstderrに出すべきだろ。
それを使いにくくなるとは。。。 >>715
コンパイラの出力をパイプで渡していくのは時代遅れだと思う。
今は、ファイルに書いて渡せば良い。 >>714
古い時代とはまた違った、今の時代に合った CUI の流儀がある。
Unix好きの人には、古いものを維持し続けようとする人が多すぎるのか、
または、古いソースを使いまわし続けすぎているためか、古い流儀のまま
になっているために効率が下がっている。 >>716
ファイルに書いて渡すと遅くなる
ディスクが遅いとかいう話じゃなくて
並列処理ができなくなるという話 >>719
実際のコンパイルは、a1.c, a2.c, a3.c, ・・・ などを別のCPUコアに渡して、
マルチコアでコンパイルするので、既にCPUコアが完全に使用しきられている。
なので、それ以上、コアに空きが無いので、パイプを使っても並列度が
上がることはほぼ無い。
一方、いったんファイルに書いてもファイル・バッファにキャッシュされ、
実際のディスクへの書き込みは、全く行われないか、または、ずっと後
になってから行われ、コンパイル作業中にはRAM上でデータの受け渡し
が行われるためディスクの遅さは全く関係しないと言っても過言ではない。 >>720
パイプを使っている今はね。
ファイルを作ると遅くなるって言ってるの
今のやり方が最適なの。だからCPUコアを使い切れている >>721
パイプを使っても、0.000001% 位しか速度差が出ないのに、
gccなどのコマンドラインはめちゃくちゃ使いにくくなる。 コンパイラのエラーメッセージは標準出力に出て問題ないだろ。*nix系でも出るぞ。何いってんだこいつ。 パイプを使わないと動画をリアルタイムにエンコード出来ない >>725
別にパイプを使うなとは言ってない。
そういうケースでは使っていい。 どうやら時代遅れなのはお前の頭だと気づいたようだなw 違うな。
古いものと新しいものを逆さに捕らえる人がいて困る。 そもそもstderrの使い方知らなかっただけじゃないの? >>729
そんなことない。
stderr が有っても敢えて使っていなかった DOS の選択は賢いと思ってる。 >>1
gcc や clang も、include path の設定が無視されることがある。
複雑に複数の言語処理系がインストールされている場合に、
include path が勝手に「コマンドPATHから推定して」 決められて
しまい、それを修正したいために、環境変数などを設定しても
優先順位がおかしくて、なかなか修正されないことがある。
しかも、その状況を確認するには、-v オプションを付けて
出てくる長いメッセージを解読しなくてはならない。
また実は、バイナリになってしまってからは修正すること
が難しいパス設定が存在することもある。
その場合は、ソースから make する際に、./configure
のパラメータで決められてしまっている。
つまり、バイナリレベルでは、動作が変えられるように
出来ていない欠陥品が多い。 $ prog1 | prog2 | prog3 > job1.out
$ # で済むところを
$ prog1 > tmp1
$ prog2 < tmp1 > tmp2
$ prog3 < tmp2 > job1.out
$ rm tmp1 tmp2
$ # ってやるのか? >>732
最初のようなパイプでつなぐような表記を、コマンドラインから打つこと自体、問題なんだよ。
むしろ、ファイル名を指定して、少しずつ進んでいくほうが賢い。コマンドラインからだと。
型のあるプログラムだとコンパイラがエラーを出してくれる確率も高いが、
コマンドラインからだと、わずかな間違いが重大な問題に発展しやすい。
それに、どうせ、打ち間違える確率が高いので、何度も試すことになり、最初から
実行し直しになることが多い。
$apt-cyg show | grep -i nantoka
や
$コマンド名 | less
みたいなことやら無くちゃならない頻度が高すぎ。長すぎて馬鹿だ。
こんな設計思想、ダメだ。 正直期待してなかったけど、初めてまともな返答をしてくれたね。
君は自分が世界の中心ではないということを理解すべきだ。
君のために存在するものなど何もない。
それでも適切な方法で助けを求めることはできるはずだ。
〇〇をうまく使えないという理由で〇〇の作者の頭が悪いなどというなら
誰も助けてくれないし君にとって良いことなど何も起こらない。
まあ、それはそれとして、シェルのヒストリ機能や行編集機能は使ってる?
ターミナルエミュレータの copy&paste は?
これらを使ってもまだ大変だと感じるなら Emacs なんかが助けになるかもしれない。 You! Visual Studio codeをinstallしチャイナyo! #ifdef なんかも設定に応じて認識して、ちゃんとコードの色に反映してくれるからねえ。 バランスが取れておらず、かつ、統一感もない。
それが Linux。
また、安さ以外に売りが無いのに最新のハードと最高の通信環境を要求する。 最新のハードを要求する前に、最新のハードのドライバを用意したまえ。 WINE もバイナリは新しい Linuxを要求するのに、Emulator としては、
64BIT Windows はサポートしていなかったりする。
つまり、新しいハードでしか動かないのに、古いOSしかエミュレートできない。
訳分からん。 あたらしいプログラムはPowerShelも対応するようにして
徐々に移行していったらええのに 貼れと言われた気がした
【田】Windows10のダメな点
・個人情報を勝手にネットに垂れ流す
・診断データと使用状況データをMicrosoftに送信する機能をレジストリでオフにしてもなお8時間で4000回、93つの異なるIPのMicrosoftサーバへデータが送信されている
・エロファイルを持っている場合はそれも全て晒される
・間違ってロリファイルを持っていた場合はネットに繋いでいるだけで警察が来る
・死ぬほどUIがダサく異様に使いづらい
・ダサい上に抑揚のないフラットデザインのため、どのウィンドゥが手前で奥なのかわからない
・かつてあった多くの機能の半分以上をカットし、使わない機能をてんこ盛りにしたデブOS
・起動が超遅い。見かけ上早く起動したように見えるだけでほとんどのソフトを読み込んでいない
・スリープ復帰速度はほとんど変わらず
・ファイル圧縮・解凍速度も遅いまま。フリーウェアの圧縮・解凍ツール使ったほうが200%以上高速化する
・ファイルコピー速度が壊滅的に遅い。フリーウェアの高速コピーツール使ったほうが400%は速い
・メモリ使用量が馬鹿みたいに多い。初期は少なく見えるが使えば使うほど多くなる
・タブレットでも動くように設計されているが、利便性もデザインもiPadの足元にも及ばないゴミ
・標準ブラウザにEdgeとかいうゴミを採用。機能が少なすぎる上におそろしく遅くて使い物にならない
・無料のセキュリティソフトと称する重いウィルスソフトが多数憑依している
・仮想デスクトップと称するゴミを搭載。フリーウェアの仮想デスクトップソフトの半分の利便性もない。
・Win8で削除したスタートボタンを恥を忍んで復活させた
・しかしスタートメニューにまつたくいらんメトロや宣伝がゴチャゴチャついて無駄に肥大化、邪魔。機能性がない
・非アクティブウィンドウもスクロール可とかいう、昔からできるような機能を大げさに宣伝
・タッチパネルとして使いやすいUIとして喧伝しているが、デスクトップPCで画面の汚れるタッチ操作を行うのはよほどの馬鹿だけ
・ダサくて見づらいゴミフォント「游書体」がデフォルト設定
・ほとんど反応しないゴミ丸出しの音声認識アシスタントCortana搭載。画面に向かって話しかけているぼっち野郎の姿はバカそのものw リダイレクトやら、
パスに文句言ってる人がいるが、
OS の問題じゃなくてシェルの仕様の話だろ
シェルを変えればいいだけ パスの書式だけならそれで何とかなるけど、構造だけはどうにもならない事がある
\\PC名\共有名\〜 みたいな表記はCreateFileとかに直接投げてそのまんま動く位、
ファイルシステムの構造とそれを実現する為の実装に密接してっかんな VSCodeが出たから、
「やっと、やっと、まともなIDEがLinuxでも使えるようになった! MSがやってくれた! ありがとうMS!」
ってことなんだろうね。 IDEを使ってるのではなく使われてるレベルなんだろーな
別に自分の好きなようにやりゃいいだけだろ Linuxの開発環境はVSCodeが出る前は vi使え! とか大声でいうやつがマジで居たぐらいに貧弱だったな。
環境改善に尽力してるMicrosoft様々だわ。 >>749
Kateでイイじゃん
VSCodeだと、テレメとってくるから
VSCodium入れてっけど
Kateばっか使ってる >>751
VSCodiumの作者が、そう言ってて
わざわざ毒なしのVSCode提供してくれてるから
フィードバック提供しないって
設定すればイイだけなのかもしれんけど
デフォルトでOnになってるし
Officeもそうだけど、そういのばっかり
熱心にやってきて
なにシレット仕込まれるか分かんないから
VSCodium入れてる >>752
マジか。
MSは中国並みに情報収集熱心だな。
中国は国策でやってるわけだが、アメリカもなんぞ法律でもあって情報集めろってやってんのか? >>753
なんなんだろうね
ほんと
ヨーロッパだと、そいうのわりと敏感で
問題になってるみたいだけど 開発環境云々もUbuntu Japanese Teamによる志賀慶一氏のライセンス違反認定が取り消されないのも、
全部無能な鍋田コピペのせい。
鍋田コピペが悪い。 >>754
ね 国によってフィードバックのデフォルトに変化があったりするのかね GCC使ってる時点で性能をスポイルしてるからね。
40年前と同じで問題ないのさw VSCの中の人じゃないが、テレメがあるとしても基本的にはどの機能がどれだけ使われてる
とか、デバッグ情報とかそんなんじゃないかな。"ユーザーエクスペリエンスの向上"のため。
そういうのも集められるのはイヤ、と言われるとアレだけど。
たまにハックしたバージョン入れててそれがクラッシュして、そういうユーザーに限って
SNS等にキレた書き込みをしたりw そういうのもクラッシュトレースを見れれば安心w
今時のOSって、いろんなことを登録するじゃん。あれとかね...
ま、あからさまに個人情報を集めたりしてそれがバレると今時大変なことになるからなあ。 cmakeとか、masonとかninjaとか良く分からん >>751
VCですらMSアカウント必須になって久しいのにテレメトリ無いとは思えんな
コマンドラインのコンパイラさえMSアカウント無いと使えないよ