WindowsやめてLinuxデスクトップ! 5
■ このスレッドは過去ログ倉庫に格納されています
きっかけは、当初のWindows10の暴君ぶりでした。 計画性のないアップデートで勝手に再起動し保存されていないデータを消滅させ、 時間がないときにもおかまいなく長く起動を待たせる。 おいおい、アップデートさせるためにノートパソコンを持ち出したんじゃないよ。 ポップアップもうっとうしい。 こうしてLinuxデスクトップをメインで使うようになりました。 懐かしい感覚を得られるようになりました。自分でPCをコントロールできる感覚です。 ずっとWindowsにその感覚を取り上げられていたものだと気づきました。 今や必要なサービスはブラウザさえあればほとんど受けることができます。 オフィスソフトには、LibreOfficeという素晴らしいものがあります。(MSオフィスとの互換性アリ) もう普段のデスクトップ環境としてLinuxデスクトップを選んでも差し支えありません。 こういう気付きをみなさんで共有しましょう! (WindowsやめてLinuxデスクトップ!の前スレ) 1、http://mao.5ch.net/test/read.cgi/linux/1479089662/ 2、http://mao.5ch.net/test/read.cgi/linux/1500357210/ 3、https://mao.5ch.net/test/read.cgi/linux/1507061282/ 4、https://mao.5ch.net/test/read.cgi/linux/1510842960/ まあMS嫌いでも選択肢としてLinuxがある時代はマシと言える 80年台後半から00年台前半まで、ほぼMS以外の選択肢は無かったからな 今はもうWebアプリの時代になったからブラウザさえ動けばOSなんか何でもいいって事で 逆にPC UNIXとしてLinuxしか選択肢のないこの時代はSolaris やBSD連中にとって冬の時代とも言えるw ubuntu studio 16.04LTS 64bit (Linux 4.13.0-36-lowlatency ) CPU Q9550s(CPUID=1067A、ucode 0xa0b(2010年の日付)) だけど、 CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' > STATUS: NOT VULNERABLE (Mitigation: OSB (observable speculation barrier, Intel v6)) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' > STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' > STATUS: NOT VULNERABLE (Mitigation: PTI) 未だ、BIOS、マイクロコードはUPDATEしていないけども、 現状とりあえず 3つ共 NOT VULNERABLE になった。\(^o^)/ >>736 unar コマンドで解凍したらいかが? >>739 > 今はもうWebアプリの時代になったからブラウザさえ動けばOSなんか何でもいいって事で >>697 の例もあるから、もうWindowsは面倒だよ ファイル名やディレクトリ名にスペースを使う感性が好きになれない Program Filesとか気持ち悪い >80年台後半から00年台前半まで、ほぼMS以外の選択肢は無かったからな どこの魔境だよ。半島か? >逆にPC UNIXとしてLinuxしか選択肢のないこの時代 IBMやOracleと付き合ってみればいいのに。 >>744 スペースの入ったパスは「"」で囲わないといけないけど 「"」付きのパス渡されるとエラー吐くマヌケもいるしな テキスト部分に、UTF-8 を使うのは良いけど、 ファイル名などのシステム要件には、半角英数字以外を使ってはならない 各アプリで対応していないから、バグる。 世界中のアプリ開発者の中で、 全角文字などのUTF-8 ファイル名で、テストしている者は、一人もいない 例えば、日本人が日本語のアプリを作るのにも、中国語・韓国語など、 世界中の数百あるフォントを導入して、テストしないといけなくなるから、絶対に無理。 ファイル名の部分だけで、何年もテストしないといけない 圧縮解凍アプリなどは、特にバグる。 それに例えば「ば」なら、Mac では「は」+濁点になるから、互換性がない 半角空白が入っていても、" " で囲っていないと、引数の区切りに解釈されてしまう。 コマンド "a b" → 1つの引数 コマンド a b → 2つの引数 コマンドプロンプト・PowerShell は、sjis, utf8 も指定できる 今日の教訓 ネットワークインストール中に電子レンジを使ってはいけない スペースだけならバックスラッシュの方が手っ取り早いだろ "hoge fuga" ↓ hoge\ fuga >>747 「世界中のアプリ開発者」とやらに謝った方がいいと思うよ。 >>747 テスト用のファイル名は「医療費一覧表」に決まってるだろ 思い込み激しいな。 世界中の開発者って証明どーするの? >>747 具体的にバグるアプリを教えてくれませんか? EUC-JPが出てこないところを見るに、ここのLinuxユーザはニワカばかりってことだなw 全角文字のファイル名は、圧縮解凍アプリなどで、バグる。 Mac の人は、全角文字のファイル名や、半角空白が入ったファイル名を、受け付けない バッチ処理などで連続的に処理していく中で、どこでバグるのか、よく分からない それに、家族👨 👩 👦 👦 などは規格もあいまいで、どう解釈されるのか分からない >>755 > 全角文字のファイル名は、圧縮解凍アプリなどで、バグる。 file-roller使ってるけどバグったこと無いのですが。 >>755 マカーだけど20世紀はそんな感じだったなぁ ぶっちゃけwinユーザーからもらったファイル展開するアプリ持ってるかどうかってだけ >>742 I will try it! Thanks. >>742 zipファイルのことなら、日本語パッチが当たったunzipを使う ttps://gist.github.com/hamano/573753 : : : : : |,: : ヽ: : ヽ; : : : ヽ; : \: :', : : |: : : ',: : : \: : \: : : :\: : ヽ: ', : : |: : : : '、: : : ヽ: :, ヽ-─‐: ヽ: : : ',: '、 : : |:l: : : ',ヽ;、: : :, く: -─` ̄ ̄l`_: : : :|: : '、 : : :|:l; : : ヽ,ヾ- 一 _ _ _ ',|´\:l: : : '、 : : : |'、: ,、r '' ` ィォ~'"´ ̄` 〈、 |: : : : :'、 |: : : ;>゙´ `┌─────────────┐ ト;: : ' ,_ │ │ : ヽ, ィfr'" ̄ _.| ネットって、 │ : : _ヽ Z' , '´ | マカーの嘘が │ : ::! -\ // ヽ ! すぐにバレちゃうから .│ : :.:', ゙ゞ、 \ _.| | : :.: `'ー-‐\ ,.r‐ 、| 面白いよねっw. ☆ │ : : : : : : : : : : ` ー──ユ 、 \. | : : : : : : : : : : : : : : : :./ノ ヘ ヽ │ \: : : : : : : : ,、 ‐' l´、 ヽ,`ニ´____________ゝイ /: : : : :,.r ´\ / ゝ、 \//:::::::\| /::/ /::::::| ヽ / : : : : : /.、 \\ 〈 ヽ ヽ::::::::::::::::::| /::/ /::::::::ト Y おじいちゃんの知識2000年くらいで止まってるんだろうな 「ファイルパスに日本語入ってるとちゃんと読めない」ソフトはいまだにあるね 日本語に限らず非ラテン文字全般だけど ファイル操作関連のライブラリが古いままなのかね >>760 unzipを上書きすれば、gnomeの右クリックメニューからの解凍や圧縮の機能にも反映される? >>755 思えば、Microsoft はセンスが悪いね。 UNIX では \ はエスケープ以外にはあまり使われない。使わない方がいいからだ。 MS-DOS 登場前からそうだったのだから、そこから学ぶこともできたはずだ。それなのにパスセパレータに \ を採用した。 これだけでもプログラマが眉をひそめるには充分だったのに、sjis だ。 ファイル名に使おうものなら sjis 専用にカスタマイズされた MS-DOS でしか扱えず、相互運用性が損なわれた。 p = strchr( filename,'\\') とやっただけでは見つかった *p が本当にパスセパレータなのか判別できない。 純正プログラムですら粗悪で、ソースコードも見ることができない。 確かに、こんな環境ではファイル名に使う文字は ASCII 英数だけにしておいた方がいいだろう。 現在でも、他人とやりとりするファイルではそうすべきだと思う。君の言い分は全面的に否定されるほどおかしなものではないと思うよ。 でも、自分でプログラム書いたことないでしょう? 前提となる知識も無く知ったかぶりするのはちょっとどうかなあ…… DOSは最初サブディレクトリがなくて後から追加されたんだよな。 セパレータを0x5Cにしたのはいわゆるポカミスだって何かで読んだ憶えがある。 UNIX系で使われてたEUCは0x80以上に割り当てられてた半角非アスキー(半角カタカナとか)が1バイトじゃないのが嫌われてたな、一部のプログラマーからは。 MSがパスのセパレータに\(0x5c)を使ったのが悪いの? sjisが0x5cを含めたのが悪いと思ってた ともかく、俺は0x5cがあったらその1byte前がsjisの1個目に 該当するかどうかを判定する処理を入れてた。 Linuxは楽だ。 EUCの時代のことは知らない Windows 版のRuby のirb も、全角文字を入力すると、バグる。 TeraPad も、サロゲートペアが、?? になってしまう 日本語の扱いでは、Linux 版のRuby が最良だけど、 それ以外のアプリでは、どう処理されるか分からない それに、家族👨 👩 👦 👦 などは規格もあいまいで、何文字かすら分からない DOS時代は8+3形式だったからファイル名に日本語つかうのは現実的じゃ無かったからね。 0X5Cが2バイト目に存在するのは仕方ない部分があるよ。 当時の半導体のコスト考えたら。 既にあったJISコードと互換性持たせて半角英数字、半角カタカナと全角と混在可能な当時としては使い勝手の良いコード体系だったんだよ。 全角は日本語以外考えなくて良かったし。 >>766 ごめん、「gnomeの右クリックメニューからの解凍や圧縮」(Nautilusかな?)を使っていないので、 分からない。 Nautilus Action Config Toolっていうのを使って、unzipを使うようにすればどうだろう。 コンテキストメニューの編集は他にも、python-nautilus というのもあるらしい。 ttps://askubuntu.com/questions/21953/how-do-i-customize-the-context-menu-in-nautilus/77285#77285 >>773 > 0X5Cが2バイト目に存在するのは仕方ない部分があるよ。 > 当時の半導体のコスト考えたら。 1バイト目が 0x81〜0x9F, 0xE0〜0xFC → 60通り 2バイト目が 0x40〜0x7E, 0x80〜0xFC → 188通り で、表現できるのは 60×188 = 11280文字 仮に0x5Cをsjisに含めなければ、60×187 = 11220文字 60文字分キャパシティが減るけど、そんなに切羽詰まっていたのだろうかw テレビ番組の名前を、ファイル名にしていた人もいたけど、 「Hello!!」みたいに、! を含んでいたので、 bash のヒストリと解釈されて、エスケープもできないで、バグるとかw ファイル名に、半角英数字以外を使うと、何かのアプリで、バグる >>775 JISコードと互換性なくせばできなくはないけど、 途中で1バイト飛ぶなんてコード体系もしあったらゴミクズ扱いされるだけだったろうね、当時は。 わざわざ0x5Cスキップさせるために余計なコードかかなきゃならないから。 メモリの価格を、バイト辺りいくら、なんて言ってた頃だし。 実際のところ、DOSはファイルネームを0x5cでエスケープするなんて無意味で馬鹿な処理しないからセパレータを0x2Fにしとけば問題なかったんだよね。 むしろWindowsだけがUnicode対応できてるだろ Windowsはメモ帳ですらUnicode制御文字まで対応してるのに LinuxのエディタなんかどれもこれもUnicode文字で制御乱れまくりだからな RLOとかRLEとかあるとカーソル動かせなくなったり ゼロ幅文字あるとカーソルの位置が合わなくなったり >>771 そういう判定は自前でやるべきものじゃないだろ >>774 おー、親切にどうもありがとうざいます。 gnomeのメニューの編集で試してみたいと思います! これができたら、新しいタイプの暗号化強化版のZIPを、 日本語ファイル名文字化けフリーで解凍できるぞ。 ちなみに、Windows10の、右クリックメニューなどから選択する標準の解凍機能では、 このタイプのZIPファイルの解凍は非対応だった。 アプリの充実と完成度の高さはWindowsのが良いからねー。 wineでWindowsアプリ使うのがベター。 >>782 Windowsのどこが完成度か高いんだよ。 Windows7や8から10にupdateしたらみんな動作不良になったぞ。 結局10を買わざるを得ないか、7や8を再インストールするかの選択肢しかない。 >>783 >Windows7や8から10にupdateしたらみんな動作不良になったぞ。 そりゃ動作に問題が出た例ばかり集めてればそう見えるだろw win10はちょっと酷いな まるでユーザーをテスター代わりに使ってるみたいだ 特に強制アップデートのHOMEエディションってなんだいありゃ? うちも人柱でproエディション1台飼ってるから笑えねえ('A`) Homeは地雷だったな だいぶマシにはなったが Windows10を使うならProにすべき でも、だいぶ設定を弄らないと使い物にならない 全体的に立体感がなくなって画面が見辛くなった 確かにhomeで作業的使い方はできないわな 作業用途ならlinuxの方がhomeよりマシだ その作業に使えるソフトがあればLinuxでもいいんだけどねえ >>787 同意です。 もし今、Linuxデスクトップ環境を使っておらず、他の人みたいにWindows10を使っていたとしたら、 どれだけ「あー!!!ク○!!!」と言ったかもわかりません。 もう2年ぐらいで7も使えなくなるから 早めにWindowsは見切ったほうがいい ChromeOSかLinuxが妥当 嫌いな連中が喚いてるだけだからこーいう話に具体的な中身があったためしがないねw 家だとWindowsでもLinuxでもいいんだよ。 スクリプト簡単に使えるから俺はLinux選ぶけど。 でも仕事だとヘボPCしか支給されないからWindowsは勘弁。 メモリー4GBじゃブラウザとメーラー開いてたら今どきの開発用エディタでさえ開けんわ! >>792 そりゃ言い過ぎだww officeが無いと仕事にならない環境もあるわけで、んなこと言ってると外に出て働けなんて言われるし ブラウザとメーラーだけでエディタ開けないって、他に問題あるんじゃねえの? それにしてもいきなり問答無用でうpでかかるってのはマジで迷惑 まあ、一般使用でwindowsが無視できないのは仕方ないわな 作業用途だとPro>Linux>homeだなぁ ウチは作業用PCはPro機とLinuxMint機に任せてるわ homeもあるけど専らネット・動画閲覧用だ >>776 あの時騒いでたのは君か。君には無理だろうね。そもそも、おすすめすることでもない。 そうする理由がある人間が責任転嫁せずに自分でメリット、デメリットを評価した上ですることだ。 もちろん遂行能力も必要だが自分でマニュアルを読むという程度のことだ。誰でもできる。 あの時の彼がうまくやってるかは分からないが。 >>776 文字化けするのは仕方がない事ですが、バグるのは仕様を満たせていないアプリのせいですよ。 Windowsアプリは、と言ってるのになんで、Windowsは、とわざと誤解するかねぇ。 そう言うところがLinuxユーザがまとめて嫌われる原因のひとつになってんだよな。 Windowsはhomeを常用にしたことない。 2KからずっとPRO以上にしてる。 じゃないとWindowsなんてまともに使ってられんw >>793 >officeが無いと仕事にならない環境もある そうよ、それこそMSの布石さ あと、MSフォントという仕掛けがあるので、 他社や、資産との互換性から、LibreOfficeにも安易に跳びつけない。 Windows10 Home で、WSL で、MS Store から、Ubuntu 16.04 LTS をダウンロードして、 Ruby をインストールする 最初から、Python, vim も入っている 200MB ほどダウンロードして、850MB ほどの容量。 ただし、GUI版ではなく、基本的な機能しかないけど だから、Windows10 Home でも、開発環境として、Ubuntu が使える。 ただし、サーバーのように常時実行はできない。 開発環境として使えるだけ Docker も使えない だんだん機能充実させるんだろうけど、今のところ誰得な感じかな 中途半端で使う人を選ぶね 先っちょしか入れられない感じ >>800 wslでlinux向け開発するのって、テストの段階のどの辺りまでwslで実施してるの? 単体テストまでならwslで行けそうだけど、それ移行は実行環境との差分があるから怖くない? wineでMSofficeもMeryエディタも使えるし(ウチはoffice2007使ってます)、フォントもIPAモナーかTakaoでほぼ代用になるので実用上ほとんど困ることは無くなりましたね MSフォントって言うほどトラップになるの? IPAフォント使ってるけど気になった事ないわ >>805 役所の書類とかは、罫線の位置ずれただけで容赦なく却下されるぞ >>776 一応補足しておくよ。 >「Hello!!」みたいに、! を含んでいたので、 >bash のヒストリと解釈されて、エスケープもできないで、バグるとかw $# いや、bash 使ってるけど…… $echo Hello!! Hello!! $# 実際にはこんなやり方はしないけどね。 $ >>805-806 LibreOfficeでIPAフォント使ったことあるけど、MSフォントが使われている既存のxlsxなどを開くと、 1ページにおさまらなくなる場合があるよね。 LibreOfficeでも、MSフォントがあれば、そういうファイルも崩れずに表示できたな。 どうせなら、MSフォントと”完全”互換のフォント開発してほしかった。 あと、なんでもかんでもエクセルファイルを添付してくるのやめてほしい。 PDFつかうようにリテラシー強化してほしい。 それなら崩れの心配しなくてよいだろうに。 >>800 >MS Store から、Ubuntu 16.04 LTS をダウンロードして なにか混入していないの? win10の更新失敗を繰り返すのでubuntuに戻りました。 この方が精神衛生的に良いわ。 >>804 一応一太郎ビューワーがwineで使えるのでファイルの中身を見るだけならなんとかなるんだけどなあ https://i.imgur.com/crkQq16.png あと、一太郎ビューワーですべて選択→コピーしてWordかLibre Officeに貼り付ける これならレイアウトの崩れは最小限で済む ちょっと面倒くさいけど 一応使えるだけマシかな https://i.imgur.com/B4lFgBa.png >>813 むしろ、彼が可哀想になってきたよ。>>767 でも書いたけど、MS-DOS に限定すれば彼の言うことも解らないではない。 C で書かれたプログラム prog を prog "a b" のように実行した場合、1 個目の引数の内容は a b となる。当たり前だ。Linux ならね。しかし MS-DOS では "a b" かもしれないし "a かもしれない。これが「クォーティングが必要になるような文字を使ってはならない」と主張する根拠になるだろう。 理解できなくはない。しかしそれは MS-DOS でのことだ。Linux ではない。 シェルの解釈が気に入らないなら、単純なラッパーのシェル書けばいいのにね。 >>815 >you are asking for it. 罰を求めているんだね(自業自得だ)→もう罰を与えられる This is the last warning. 最後のケイコクだよ→最後の警告の段階なので、まだ罰は与えられない だから、どうして同意になるのかわからないわ/// >>818 MS-DOS でのことを指しているのなら、MS-DOS でのポータブルな解決策は不可能だ。引数の解釈にシェルは関与しない。 MS-DOS ではプログラムに引数を渡すことはできない。渡すのはコマンドラインだ。 各プログラムにはコマンドラインのコピーが渡され、C の場合ならスタートアップルーチンが解釈して argv をセットアップする。だから処理系ごとに違う。 もうファイル名どころの話ではない。MS-DOS ではクォーティングはポータビリティを損なうのだ。 これはとてもつらい制限だった。だから彼の言うこともよく解る。MS-DOS ではどうしようもなかったんだ。 でも、そうでない世界があることも知っていた。プログラミングのテキストは大体 UNIX だったからね。 Google翻訳の精度が上がるケースは入力文が十分な量あるような場合に 限られていて、poファイルにあるような短いセンテンスだけを突っ込んだら 変な結果を返すことは今でも少なくない 人間が「UIの文章である」「ある特定のアプリケーションに関する文章である」 というドメイン知識を持った上で翻訳する文章の精度に到達するのは今のやりかた の延長では非常に困難 だから人間が頑張るしかない。 DOSだとコマンドラインで与えられたオプション解釈はアプリの責任だからなー Cてmain()がうけとるのはスタートアップが解釈した結果だし。 WindowsやLinuxは独自なスタートアップ書いたこと無いので知らんw DOSは0x0081〜0x00FFにコマンドラインで入力された文字がそのまま入る。 それを起動された側でスキャンして*argv[]の実体を作るんや。 なので、>>820 が言うとおりシェルが小細工できないのよ、DOSは。 半角127文字までしか入らないから小細工させる余裕が無いとも言える。 >>824 なるほど。ありがと。 そんな制限しらんかった。 >>817 linux・NT系コマンドプロンプト・MS-DOS で prog "a b" を試してみましたが、 どれも 1個目の引数は a b でした。 MSDOSでも"a b"なら「a b」という一つのパラメータ値として扱う仕様だから>>827 は正しい >>817 がおかしなこと言ってるだけ MS-DOSでオレオレスタートアップとかLinuxでオレオレシェルとか言うなら好きにしろって思うが、まぁ理解は出来る 今時MS-DOSもないだろって思うのでどっちかというとWindows32/64ビットコンソールアプリがどうなのか気になる >>828 それはいつの話だ? 少なくとも 20 年以上前の本物の MS-DOS の話をしていたつもりなのだが。 Windows での経験なんか無いよ。Linux を使えるようになったから捨てた。もう前世紀のことだ。 「そんな時代もあった」と思ってくれればよかったんだけどなあ。 とりあえず、こんなページ見つけたよ。 http://thinca.hatenablog.com/entry/20100210/1265813598 安定してる(Windowsにくらべれば)Linux上で 機能が充実かつ広範囲に使われてるWindows向けのアプリをそのまま使うのがベターだろ。 Linuxのネイティブアプリに期待できんし。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる