WindowsやめてLinuxデスクトップ！ 6
■ このスレッドは過去ログ倉庫に格納されています
きっかけは、当初の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/
5, https://mao.5ch.net/test/read.cgi/linux/1514310320/ 破壊神meたんの存在忘れてたわ。
使ったことないからw guiに限定するなら、漢字talkとかNeXTは衝撃的だった。バブル絶頂期だったんで社長に買ってーっていったら、cubeが来た。 先ずは数人の方が自分のリンクした画像をご覧下さり、御礼を申し上げます、アリガト。
>>143
自分も少し難しいことを言ってる人の大方は「知ったか」って印象があるけど偶には「知ったか」じゃないから。
人の文章を改造して決めつける習性は例え相手が自分の気に入らない者でも慎むべきで治ることに期待してる。
1）自分の>>114の趣旨は>>112氏のレスをみてLinuxはプログラム作成で中々イイ環境と言いたかった。
Windowsもプログラム開発環境で負けてないならWindowsも負けてないぞ、程度で良いのでは。
2）対比としてWindowsユーザーは君のような熟練者でないなら相応の対価を支払うべきって趣旨。
Linuxユーザーにも未熟者がいるだろって反論ならLinuxに足を踏み入れたからには自分の環境は自分が作れって考え。
それに再インストールの経験はないけどイザとなればアクチがないから再インストールの敷居はないに等しい。
＞そのICは使ったこと無いから仕様書をDLして調査しないといけなくなるし、
74LS74はハードを少し噛れば遭遇する、ありふれたTTLだけど最近はFPGAが多いのか、逆に自分はFPGAは知らない。
＜修正理由＞
正常に動かないから修正したけど修正前の仕様だと74LS74から（8bit）CPUに常時信号が来るので8bitPCが起動しない。
データバス（例え1bitでも）が占有されるから。価格が74LS244の半額だったので動けば節約になると魔が差した。
アクセスされた時だけデータ信号を返すLS244の有難味を実感してる。昔は一方向にしか信号を出さないから働きが悪い、
って印象だったけど重要な役割があることを再認識した。CPUへの入力バッファでよく使われてた理由を改めて理解した。
>>135
自分の興味や関心のあること以外関知しませんし無知ですので自分の環境は自分が作って下され。
自分も現状でFT245RLを介してテキストの読み書きは確認できたけどバイナリーで壁に当たってるから。 >>155
pc-unixなんて無料の開発環境がゲット出来るから始めた。なんて同世代のオッサンは多いはず。 マイコンのBASICからスタートしてMS-DOS経由でWindows
そして汎用機
で、またWindowsの世界に戻ってクラウドでLinuxに着地
結局、MS-DOSが一番使いやすかったように思う >>157
FDでファイル管理
io.sys
msdos.sys
command.com
自分は、MS-DOSで遊んでいないで、
Linuxというものに触れていたかった。
GUIでしかインターネットできないと思いこんでいたあの日。
Linuxがあれば、CUIでインターネットができていたのになあ。
あのときはwgetコマンドで満足していたと思う。 Linuxユーザは使いにくいデキの悪い道具使える俺ｽｹﾞｰしてるだけにしか見えん。 そういうのはOpenindianaユーザーに言ってくれ 料理人が料理するときにセラミックの包丁つかうか、鋼の包丁を自分でメンテしてつかうかぐらいの差だろ。
鋼の包丁はメンテすればクソ切れ味いいけど、料理人がみんな包丁研げるわけじゃない。
鋼の包丁は放置すると錆びるけど、できの悪い道具じゃないだろ。 道具は使う奴によって左右されるからね。仕事で使う以上、他の選択肢ないし。デキが良かろうが悪かろうがwindowsもlinuxも使わないと飯食えない。 WindowsとRTOSの案件は山ほどあるけどLinuxの案件はほとんど無いな >>157
自分もMS-DOSは良かったと思ってる。
DOS後期で、DOS-Extenderを使えば、32BITアドレッシングが使えたので64KBや1MBの
制約も無くなったし。でも一般人がWin95を買ったのでDOS用アプリを作っても使って
貰えない状況が生まれてしまった。
それに、マルチブートもPC-9801なら、起動時のTABキーで最初から簡単に出来た。マシンが
デフォルトでそれを前提にしていたので、今のようにGrubとWindowsとのごちゃ混ぜで苦労する
ことも無かった。
DOSはCUIと言ってもパーティション作成もマルチブートの設定も、テキスト的なGUIで容易に
設定できたし、JGなどのGUIなDTPツールは今のWordよりも使い勝手が良いくらいだった。
そして、データやアプリの設定、インストール状態はそのままで、OSだけを再インストールする
ことも簡単に出来た。それも非常に短時間で済んだ。 >正常に動かないから修正したけど修正前の仕様だと74LS74から（8bit）CPUに常時信号が来るので8bitPCが起動しない。
>データバス（例え1bitでも）が占有されるから。価格が74LS244の半額だったので動けば節約になると魔が差した。
>アクセスされた時だけデータ信号を返すLS244の有難味を実感してる。昔は一方向にしか信号を出さないから働きが悪い、
>って印象だったけど重要な役割があることを再認識した。CPUへの入力バッファでよく使われてた理由を改めて理解した。
トライステートバスバッファとフリップフロップってまず「同じもの」では無いよね。
それを流用できると判断した時点で頭おかしいんじゃないの。 包丁使うところでペティナイフ使って俺ｽｹﾞｰしてるのがLinuxユーザだろw はいはい。
すごいです。
恐縮です。
ペティナイフで十分だったり、時には石器も使いますよ。過不足なく使いなれた道具で人様に迷惑かけない程度で日々を過ごしてます。 >>170
アレ？
使ったこと無いから仕様書をDLして調査しないといけなくなるし、
忙しいのでそこまでやりたくない。って昨日>>143で言わなかったか？
忙しいなら、ここに入り浸ってることが不思議だ、本当に忙しいのかと言う疑念が尽きない。
質問に回答できなから忙しいと逃げて失敗の原因が明示された途端にノコノコ顔を出すとは。
まぁ失敗の原因を既に明示してるから少し調べれて後付けなら高校生でも指摘できる。
時間に余裕ができたので自分の作った回路図を始めたばかりの状況で失敗も経験値。
それにしても舌の根も乾かぬうちに前言を撤回し不具合の原因が明示された途端に
態度を豹変し上から目線で他人を酷評することに人間として恥ずかしくないのか？ 俺スゲ〜してるハッカー見たことないから俺スゲ〜してるユーザーしか見たことのない>>171には同情する >>169
PC98のブート選択は凄いよかったね。
初めてPC/AT互換機でマルチブートするとき意味分からなかったわ。 MS-DOSは自分でPCをコントロールしている感が身近に感じられて良かった。
でもCやアセンブラでシステムコール読んで…というのは、
スクリプトでかなりのことが出来るLinuxに馴染んだら面倒だといまは思える。
Linuxは細かいことまでスクリプトで出来て良い。
UNIXから継承した、デバイスファイルという概念やハードウェアにアクセスするコマンド群。
コマンドなどの結果を自由自在に扱えるツール群。
ついでに、ソフトの設定がテキストであることが多い点。
Windowsは何かするに面倒だしその為に覚えた知識も陳腐化する。
Linuxにして良かった。 >>173
そう見えるとしたら君がそうなんじゃないかな？ Linuxも設定ファイルとかログでバイナリ増えてきたけどね。
俺的には嫌な風潮だなぁ。
それでもWindows使うよりはLinuxでXfce使ってる方が遥かに使いやすいね。
OfficeだけナントカなってくれたらもうWindowsに縛られることなくなるんだけどなぁ。 >>179
あと、MSライセンスのない日本語フォントで、
旧来のMSフォントと完全互換のあるようなやつがあったら最高
ITはどうしても、自由がいい。ただそれだけ。
MS嫌っておきながら、.net coreは素晴らしいなんて思っている。 ラジコのタイムフリーを録音できるアプリがリリースされたら
Windows捨てれるのだが、、、 >>181
Linuxの場合は、ラジコのタイムフリーを録音できるように設定するのであって、
その機能に特化したアプリを探さないのが一般的なLinuxの使い方。
ttp://d.hatena.ne.jp/nyanonon/touch/20161015
ここに出てくるwget, dd, ffmpegはもともとLinuxからWindowsに移植されたもの。
swfextractはswftoolsに入っている。certutilはlibnss3-toolsに入っている。 >>182
これはご親切にありがとうございました。
cron弄ったりするのが面倒なのであまり調べてませんでした。
感謝です。 >>182
部品が充実しているものな。
シェルスクリプトなんかを利用して、作文するわけだ。
マクロ的なプログラミングだ。 自動化を手間だと考える老害が死なないと一人当たりGDPは伸びないんだろうな、まさに日本社会の癌 プログラム言語を一つも覚えずpc使ってる若造の方が多い気がする。 >>187
スマホでスマホアプリが作れて
それが高収益上げてる時代に何を言ってるんだか その程度で十分ならいいんじゃね。俺は興味ないけどね。 スマホで作れるスマホアプリでどこまで作れるのか試してみればいいだけ。
それで自分の目的を達成できるのなら十分じゃね。 それもプログラミングと言えるよね〜
だけど、老害にはわからんのだろう ははは。そうだね。
プログラムできるからね。
小中学生がその手のツールで授業やれば良いと思うよ。 なぜかマグナキッドおもいだした。
大昔からその手のアプローチあるけど、その先を目指す人がいてくれるから悪い事じゃないと思ってる。 プログラミングだのスクリプト記述だのしなくても使える物があるなら、
世の殆どの人間はそっちを選ぶ パソコンおじいちゃんはプログラマ全員がZ80の機械語を読めてアセンブラから自作したソフトを売って利益を上げないと気が済まないんだよ >>173
別人なんだけどさｗ
FM7のPSGが云々と書いてあるから、PSGをPIO代わりに使ったんだろ？
なら「起動しない」ってのは原因が別にあるよなｗよく壊さなかったなお前ｗｗｗ
>>198
>パソコンおじいちゃんはプログラマ全員がZ80の機械語を読めてアセンブラから自作したソフトを売って利益を上げないと気が済まないんだよ
そこにいるお爺ちゃんは6809だぞｗ >>196
そう見えるとしたら君がそうなんじゃないかな？ ドングリの背比べって言うより目糞鼻糞だな、8ビット比べって。 話が変わるが、ふと思ったことがあったので。
日本語フォントは、やはりオープンなものを使うべきだと思う。
職場のPCをLinuxに置き換えようとして、フォントはどうなるんだろうと思った。
MSフォントで作成された文書が外部からやってくる。
しかし、LinuxでMSフォントを使うことは制限されている。
日本語フォントは、国主導で、IPAなどのフォントを強制すべきだと思った。 IPAはバックスラッシュが間違えてるんじゃなかったか？ 今のLinuxはプログラミングしなくてもネットの頂き物で使える環境にできるけど
更にスクリプト（言語）だけでも駆使できれば相当パソコンの利用範囲が広がると思う。
スクリプトで作成されたアプリも頂いて便利に使ってる。頂ける物は有り難く頂いている。
ただググっても無ければ可能な範囲で作るかな、って気にもなるけど探せば90％以上ある。
その辺りはコアのWindowsユーザーも同じ状況だと思うから案外Linuxも併用してたり。
プログラミングができなくてWindowsに止まることしか出来無い輩がヤッカミで来てるのかとも思う。
その類のWindowsユーザーの本音の叫び
何でLinuxがそんなにイイんだ、Windowsも開発環境は無償だから俺様用アプリを「タダ」で作くれ！
Linuxユーザーその1（アプリを作ることに積極的な方）
知らん、そんなこと。Linuxで環境構築してるし必要とあらばアプリを作って更に使い易くする。
Linuxユーザーその2（アプリを使うことに積極的）
知らん、そんなこと。自分のことは自分ですれ、園児の時に教わったろ。お前は園児並みのオツムか。
ただLinuxを使う前提なら親切な、その1のコアなユーザーがお裾分けしてくれることがあると知恵がついた。
作ることも排除しないけど基本、作るより先ずは探す。因みに自己紹介を兼ねてる。
念の為、その他のLinuxユーザーの存在もあるかと。 >>207
なにがいいたいの？
単に便利な道具としてLinuxを使ってるだけだから考察は無意味 >>204
それって結局あなたの職場がWindows使えば解決する話じゃん 探す時間より作った方が早かった時が多くなってきてる。で、動くときになって既存の物が見つかるパターンも増えてきた。 情報洪水の弊害は早いヒトだと半世紀ぐらい前から警鐘ならしてたな。
AIがもう少し便利に使えるようになったら「AIに訊いちゃえ」ってなるんだろうけど
それまでは「うきー！探すより作ったほうがはえぇぇぇ！」ってのを我慢するしかないだろうね。 >>206
呼ばれたような気がした、釣られたか。
今回のFT245RLを監視・制御する6809ルーチンでC言語的な STA , X+ （A7 80）インクリメントは使った。
下を印刷して実質ハンドアセンブルした。ミニアセンブラだとアドレッシングモードが思うように反映しない。
http://www.6809.net/6809/?6809%CC%BF%CE%E1%C9%BD
一昨日バイナリーの送受信もできてるようになった。なのでFM-7で作ったコード
（意地でもモニタを見て、手書きで書き写したりしない）をLinuxに送ることができたのでテキストにした上
「ハンド」ディスアセンブルして、このスレに貼ろうと考えたけどケチを付ける人が必ずいるから止めた。
因みにバイナリーの確認はLinux側でreadしたバイナリーデータをエコーバック（write）でFM-7に返した。 そういえば、VC++のMFCの一部を改良するより、大規模に自作の関数群に入れ替えた
方が上手く行った事がある。なぜなら、MFCのソースを正確に解読するのに時間がかか
る事、解読できても、少し修正する程度では自分がやりたい事ができるような設計には
そもそもなっていない事、既存のMFCの基礎に不具合を生じさせないためには、むしろ
自前のコードが複雑になってしまい、バグの発生確率が高まること、などがあった
（できないわけではないが、自分が実装したいコードとはアルゴリズムが余りにも異な
るため、お互いのコードのすり合わせの部分が巨大になると予想されたから。）。 >>199
＞原因が別にあるよなｗ
他の切り口・方法でも確かめてるから原因は他にはない。因みにAY-3-8910を外してパータンを利用してる。
1）トライステートバスバッファとフリップフロップの違いってことに関して
正解を明示する前にこの類の回答があるだろうと用意してた引っかえ問題で原因を提示したあとでは気抜けた。
理由は制御できるタイプのフリップフロップなら代用は利くから。ただコスト的にも回路的にも無意味なだけ。
背景として74LS244の予備が一個で74LS74の予備が数個あったので動けばコスト的にも有利と魔が差した訳。
2）よく壊さなかったな
含み笑いが出る、君も知ったかだね。この辺りは実体験のあるなしの違いも大きいかな。
ハードに損傷を与えるか否かは原因が決まってる。某インターフェースの規格を作った人から昔聞いていた。
＞そこにいるお爺ちゃんは6809だぞｗ
それを知ってる君も同世代だろ。 >>214 は、>>211 >>212 へのコメント
何が言いたかったかというと、自分で作った場合には色々なメリットがある
ということ。
1. 一度作ってしまえば、自分の思い通りに改良しやすい。
2. ライセンスに翻弄されることもない。
3. もし自分の腕が良いなら、例え表面的には既存のものと同じ機能であっ
ても、実は自分で書いた方がコードの効率も可読性が良いかも。
4. 3.の結果、改良も容易で、改良後の安定性も高くできるかも（あなた次第で）。
5. 日本語対応なども自分のコードならとても上手くできて、不具合0。 >>216
プログラマーあるあるだねｗ
折れ的にはCStringクラスが鬼門なんだよなぁ。ATL／WTL使うとインクルードの順番やら制御用のマクロ定義やらﾏﾝﾄﾞｸｻー・・・で。 CString だけ使って、ATL, WTL 使わない方が良いかも。 >>222
ある。解決策が見出せないので、GPL、LGPLには距離を置くしかない状態にある。 >>221
既存のモジュールでの、不具合の解決法や、やりたい事のやり方を見出すのに
一苦労する時間を考えると、意外にも自分が作った方が効率が高い事がある。 >>216
スレタイ的にはスレ違いの可能性があるけどけどWindows関連の話題でも建設的な話題は良いと思う。
MFCで開発したアプリを如何にLinuxに移植するかと言う観点ならスレ違いでもなくなるし。
指摘してる内容もその通りだけど他の人からの意見のように既存コードを利用する時と新規に開発する時の
メリットとデメリットの見極めが難しい点もある。何回も使わなければ既存コードの利用も捨て難い。 この統失さんがFMシリーズを語るスレで独り相撲しているのを見てしまったｗ >>224
そりゃそういうケースが無いとは言わないけど
変更部に対する保証を考えると自作のコードは1バイトでも短い方がいいよね >>228
人的資源を使ったらその時間に比例するコストがかかるのは当たり前だろ >>231
自分で作るとコストが高いって話なのに本人かどうかは関係ないって何よ？ >>227
そうなんだけど、その「閾値」が皆が思っているよりも低いと言うか、他人の作った物
を使うと一見楽できそうでいて、その実、支配される事になりかねないという現実に
最近が気が付いた。そして、当然出来そうな機能が実は「できるようなってない」。
英語のQ&Aサイトで「なぜそれができるようになっているとあなたは思うのだい？」と
回答されている事があって、言われてみればそうだな、と目から鱗が落ちた。 >>232
あ、ごめん自分(の使える工数)で作ると、ね
単純に詳細設計から単体検査までにかかるコストより
作らないで基本設計と結合で増えるコストの方が低いことが多いから
単体検査出来てないモジュールなら作り直してもいいけど 話をスレタイに戻すと、コマンドレベルで大昔から存在するような物だと、古舞を知ってるなら検証が不用だし、パイプなりシェルスクリプトで使えばコストはかからん。
で、あっちへふらふら、こっちへふらふらなバージョンが変わる度に微妙に仕様の変わる物より、大昔から変わらず動作する物の方が良くないか?
コストってか、効率を考えると何が自分にとって最適か見えてくる。 >>232
君はソフトウエアを開発したことがあるのか？
＞自分で作るとコストが高いって話なのに本人かどうかは関係ないって何よ？
作ったことがあれば当然の内容なのに質問してる意味が、そもそも判らない。
自分で作るとコストが高いって意味は少なくても二通りあるだろ。
一つは新規に作らなければならない時に個人間の能力の違いで差が出る場合。
もう一つは既存のコードが利用できる場合と新規に開発した時の差を考える場合。
通常は金を払っても既存のコードが利用可能であれば利用した方がコストは低い。
これで判らないなら、この人の相手はするだけムダだ。 お前ら大規模プロジェクトの話してるの？
個人レベルの趣味プログラミングの話ししてるの？
その辺すり合わせもせずにいきなりコストの話してるとかお前ら働いてないのか？ >>238
＞その辺すり合わせもせずにいきなりコストの話してる
そう考えるなら、君からその点を指摘しても良かったのではと。
コストと言う用語が出た時点では受託か自社開発は別として金の動きはあるのではと思うけど
趣味でも仕事でも>>236氏が指摘する、より効率的な解を求めることの検討でないないのか。 win10に疲れて更にMSから酷いメールが来てこのスレにたどり着いたら
1が同じような人で笑ったわ win10に疲れるような人がLinuxに耐えられるのかね？ 何年か前は、光学ドライブを買うとLinuxドライバも付いている場合があった気がしたけど、
今は消えちゃった。一度消えたものは元には戻らないかな。歴史を見ると。Linuxは
一回きりの大事なチャンスを逃したからもう復活は無いかも。 >>241
なかーま
>>242
何にもお節介されない、静かなのが一番だね
OSは静かであるべき。 >>243
全部、カーネルに組み込まれているからではないの？
Linuxつかっていてドライバ組み込んだことあるのは、ハードウェアRAIDくらいだわ。 >>245
勘違い。訂正。
ドライバはそれさえも不要だった。
やったのは、ハードウェアRAIDの管理ツールの導入。 読む事は出来るし、ISOイメージを焼く事も出来ると思う。
問題は、パケット・ライト。
以前に説明どおりにやってみたら、書けたけど、トラブルが発生し
再フォーマットしないとメディアが使えなくなってしまった。
ちなみに、自分はプログラミング経験も豊富だし、PC暦は数十年ある。 コストって自分の給料も含まれるわけで、時給5000円の奴が1週間かけて作るとする場合、成果として20万の以上が見込まれない場合はいみないじゃん。
まぁ、こんな計算をしないと何も出来ない大きな会社に技術力なんて蓄積される事はなく、どっかに丸投げするしかできないようになるけどね。 >>248
既存のフレームワークに新しい機能を入れたい場合に、時として
次のような事が起きる事がある：
1. そのやり方を調べるのに1週間かけても、まだ分からない。
2. ソースを根気良く解析してようやく何をすれば良いかが分かってくる。
3. しかし、フレームワークがそのような機能追加を前提にしていない場合、
困った問題が起きる。
4. 例えば、フレームワークのメンバ関数に「virtual」修飾があったなら、
修正が少なくて済んだのに、実際は修飾されていないので修正が非常に
困難であるとか。これは例えば、デストラクタが virtual 修正されて
いないなど、推奨された初歩的な習慣に反した事をフレームワークの
ソースが行っている場合なども該当する。
5. フレームワークを修正する事は推奨されていない。そうなると、逆に
修正が大規模になってしまう。この辺は端的に説明するのは難しいが。
ちなみに virtual修飾は一例なので、それだけが問題の全てではない。
自分や自分の部署のソースであれば、必要に応じて既存のソースを少し
修正する事が出来るので問題は大きくなりにくい。ところが、修正する
事が推奨されていないフレームワークの場合、どこかで問題が生じて
しまうことがあるということ。それがどこで起きるかは一概には言え
ない。ホンの僅かに修正するだけで問題が収まるのに、それができない
から、フレームワーク以外の部分に大規模なコーディングが必要と
なったりする。
例としては、MFC の DockBar だ。 既存の物に従うか、オレオレを作るかの2択の問題で、一番なのはmfcを窓からぶん投げるじゃね。
winでの開発なんてdirectx1の頃が最後で良く知らんがmfc以外の選択肢ないの? ■ このスレッドは過去ログ倉庫に格納されています
