Arch Linux 15
■ このスレッドは過去ログ倉庫に格納されています
>>552
ホンコレ
arch導入する前にxubuntuとmanjaro試したけど
linux初心者の俺には自分にとって必要、或いは不要な設定、パッケージが何なのか把握するのに難儀して運用断念した
archwikiのインストールガイドや推奨事項に沿ってarch導入した方が全然楽だったわ どの系統にも言えることだけど
ディストリは下流に行くほど悪い方向に複雑になる。
apt系ならDebianを使うのがいいしArch系なんか使うなら素のArchの方が良い。 Ubuntu Manjaroを経由してArchに行き着いたなぁ懐かしい
若かったよ 今も若いけど（念押し） archはdotfile育てるのと感覚が似てる
常に使っていて、最新の情報をストレスなく吸収できる人向け archを10年運用して今年manjaroにしてみたわ
他のユーザーがアップデートの検証してくれてる安心感がある manjaroは使う側としては悪くはなさそうだけど
運営してる側は相当無理してるよね
この前なんてアプデ前にRC10まで出ていたという噂が立っていたし yayみたく更新するパッケージとスキップするパッケージ選べないのかな >>566
それArchとしてはサポートしてない使い方だから積極的に出来るようにはしたくない開発者が多いんじゃないかなぁ 普及率の高いパッケージでも
実質1人のメンテナに依存していたというOSSあるあるだね。
あるあるというかそうじゃない方が珍しいくらい。 Archに限った話じゃねえけどゲーミング向けAndroidエミュがLinuxにないのがｸﾞﾇｩって感じ
ソースとか転がってないっすかね GNU。
まあGenymotionで事足りてるんだけどね
ゲーム用のエミュもVBox使ってるけどDLLで本体ソースは別物扱いかねぇ。ｸﾞﾇｩ 作れる人はいても保守できないから作らない。
フリーソフトは超絶スキルで完成させても維持は誰がやっても大変だからな。 Linuxのゲーミング需要は全体の1％存在することが分かってるんだから既存メーカーが移植すればいいのに Linuxユーザーはソフトウェアに金を払う文化がないから無駄だぞ >>579
動かすことなら
いっくらでも出来んでしょ?
pkgbuild
勉強したら宜しい
他の、ディストリよりシンプルで
サラッとbuildできるよ >>581
知らんがな
しんぱいなえら
みんながが、つかってる
ibusやらFcitxにしてどうぞ >>583
atokの最新版提供されてんなら
思う存分使えばいいよ
そんなの無いから
atokなんて使わない
って
のが支流 >>579がそういう類の回答は期待していないと分かってるのに、あえてする
>>581がそういう類の回答は期待していないと分かってるのに・・・
>>583がそういう・・・ ちなみにwineてatok動いたっけ？
ibus連携するかどうかは置いといて。 なんで態々めんどくさくて有料で古いatokなんてやるんや
意味わからん
普通に最近またmozc開発進んでるみたいだし、待っとればええやろ 久しぶりにカーネルをビルドしようと思って設定してるんだけど、CPUファミリーにryazenがないんだよね、gentooのドキュメントにはあるようなことが書いてるんだけど、これは古くなっちゃったの？ 最近は大企業管理ではないOSSがどんどん死んでいくな
Rubyの終焉も近いかもしれん yayは実質死んでもた
yao開発陣もparuへ移行したし、
けどparuってrustで書かれてること以外なんもないんよな OSSは開発者のモチベーションこそが全てだから
Rustで書かれている事でモチベが上がるならそれは多大なメリットなのだ。 大企業がバックアップしてようが古いツールチェーンは死ぬときは死ぬよ
パッケージマネージャを例にとってもRedHatが支援してたyumは死んだし なんかこのスレ変なのしか残ってねえな
Manjaroとかに流れたか 匿名掲示板において流動性の低い専門板は変なのしか残らない運命なのだ いつもXだから気づかなかったけど
最近のカーネルだとターミナルのスクロールバックできないよね
昔の古いインストールisoだとできる
archというよりカーネルの問題だと思うけど
今後はscreenでも使えってことになってる？ Linux5.9で削除された機能だな
https://www.phoronix.com/scan.php?page=news_item&;px=Linux-5.9-Drops-Soft-Scrollback
リーナス曰く誰も使ってないしメンテする人がいないからという理由らしい メンテがいません信用できない機能ですという感じで残しておいてくれた方が嬉しい時もある メンテナがいないっぽい機能は
下手にバグ報告すると機能ごと消されるというリスクがある。 まぁどうしても使いたいなら該当コミットをrevertして自分でコンパイルするしかないな >>539
うちも本番で使っているけど、
協力会社からチャレンジャーと言われたorz
安定してると思うのだけれどな… >>539
本番環境はちゃんと仮想化してバックアップしとけ。
>>608
そりゃそうだろ。
運用に大事なのは「設定・操作を再現できる」「イジった時／所だけ変わる」「元に戻せる」だからな。
ローリングリリースとか狂気の極み。 archlinuxarchive活用すれば特定の時間におけるバージョン固定はできそう >>608
うちはarchで開発環境にして、本番はubuntuの上にDocker環境でarchのイメージ使ってる。archでサーバーにするのが楽だと思うけど、サバ缶が嫌がる。 何度も言われているが
自分で構築したArchの管理は楽だが
他人が構築したArchの引き継ぎは地獄だから向いてない >>614
そのとおりかもしれないけど、archで開発してるほうがサバ缶よりドキュメント残してるんだぜ。
どんなディストリのサバでもサービスの立て方が明確じゃないサーバーの管理はクソだよ。
向いてる向いてないはサービスによるんだよ。 ドキュメント不足のCentOSサーバーと
ドキュメント不足のArchサーバーでは深刻度が段違い。
自分でArchサーバーを構築したのではなく
他人が構築したArchサーバーを引き継いだ経験のある人だけが
Archサーバーを賞賛していい。 パッケージマネージャを使う限りはそれほど変わりないと思うのだが他の OS と
Arch って package Manager 使った時のソフトウェアのバージョン固定てできるの？ クソがクソ比べするのはクソ過ぎて、そんな仕事したことない。
アマチュアの仕事ならやめたほうがいい >>613の要件のサーバーならarchのほうが圧倒的に楽。Docker動かすだけなんだからローリングリリースの方がアップデートせずに使えるから。 自分で構築から管理まで行うなら楽という認識は共通でしょう。
他人が構築したArchを引き継ぐ場合の話が論点。 実機でarch入れてるのはうちの社ではCI用サーバーしかない
コンテナやVMだとたくさんarch使ってる archの指針通りシンプルに使い続けていれば引き継ぎも楽だよ。無能がサバ缶やる前提で話すからややこしくなる。
pacmanでDockerを入れるか、aptでDockerを入れるかの違いだろ。 シンプルというのが
パッケージのバージョンを一切固定しないという意味ならそうなんだが
それはArchが楽というよりも
バージョンを上げても問題が発生しない楽なシステムをArch上で動かしてるというだけ。 >>625
認識が同じで安心したね、それを楽と言うか、大変と言うかはケースによって違うんだ。出向先の会社に建てるような小さいサーバーのケースではarchのほうが向いてる。
つまりケースによって違うってこと。
開発側のアプリケーションをそのまま使えないサーバーの運用には向いてない。
開発とサーバー運用を切り分けられない現場だとarchサーバーは難しい。 それって要はトラブル発生しなさそうな範囲にArchをバラ撒いておいて
Archを触れる自分の仕事を維持しようという狡猾な戦略だろ。
バージョンを上げてトラブルが発生しないような単純なケースなら
バージョンを維持した方が安定するんだからサポートの長いディストリを使うべき。
逆に最新のパッケージが必要になるケースでも実はArchは全く向いていない。
なぜなら最新パッケージの新機能を取り扱うようなピーキーなケースでは
バージョンをそこから更に上げると動作不良が発生する事が多々あるから
常にパッケージを最新に保つローリングリリースとは絶望的に相性が悪い。
どう転んでもArchを選択する積極的な理由は見当たらないね。 >>627
>Archを触れる自分の仕事を維持しよう
なんでそんなめんどくさい事をしなくちゃいけないのか。
あなたが言ってることはこれ
>開発側のアプリケーションをそのまま使えないサーバーの運用には向いてない。
>開発とサーバー運用を切り分けられない現場だとarchサーバーは難しい。 >>628
Archが向いているケースなんて存在しないって話なんだが。
具体的にArchの採用がメリットになるケースって何よ？
>>627で書いているように
単純なケースから最新バージョンのソフトウェアが必要となるケースに至るまで
Archの採用がメリットになるケースは一切見出せない。 最新のソフトウェアがガンガン使えるメリットあるじゃん
安定したサーバー運用だけが世の中ではないでしょう 依存関係クソくらえ
最新バージョンで動かないほうが悪いのだ コンテナイメージにarchってすごいな…
ミドルや使ったライブラリにセキュリティホールあってリビルドしたらほぼ全取っ替えだよね コンテナホストならubuntuでいいし、コンテナのベースイメージならalpineでよくね >>629
じゃあ逆にデスクトップとしてのarchの利点は？
指摘してるところが全部そのままデスクトップにも言えるんじゃない？ 利用者増えなくてもdebianのように生き残っていくからwin-win >>638
nvidia control panel は windows 版 nvidia proprietary driver 付属ソフトウェアで linux 用は無いような気がします
(ありましたらごめんなさい)
linux では同じものではないですがよく似たもので nvidia x server settings が nvidia control panel に相当するソフトウェアになるでしょうか
よく nvidia proprietary driver をインストールすると一緒に入っています
ドライバが動作しているときに共に動きます
詳細は arch wiki で参照できます インストール中の初心者です。
「arch-chroot /mnt /bin/bash」は成功するのですが、そのあと別なコマンドを打つと「bash: command not found」と表示されてしまいます。
どうすれば解決できるのでしょうか？ >>642
arch-chroot /mnt
最後の/bin/bashは不要かと どの種類のmozcを使ってもカタカナ英語変換が機能しないんだけど、何か他に入れないといけないパッケージとかある？
fcitx
fcitx-mozc-ut-unified
mozc-ut-unified
fcitx-configtool
fcitx-qt5
kcm-fcitx（デスクトップ環境がKDEなので）
は入ってる。
https://wiki.archlinux.jp/index.php/Mozc
↑ここを参考に他の種類のmozcも入れたがどれも機能しない。
郵便番号変換とかは機能する。
mozcの設定でカタカナ英語変換にチェックは入っている。（外してチェックを入れ直したりもした）
以前は特別な設定なしに使えたがクリーンインストールしたら使えなくなった。
環境は
Arch Linux
Linux 5.9.12（5.9.11だった頃から使えない）
KDE Plasma virtualboxで/var/cache使いまわしてインストールしまくるのが楽しいっす
無駄にlvmにしたりファイルシステム変えたりしとる >>645
パッケージって入力するとpackageって変換出来るようなやつだろ?
ちゃんと出来るけどな?
mozc-ut-unified-fullってやつ入れてる >>650
そのとおり。
それも入れてみたけどだめだったな。
ちなみにメイン機だけじゃなくてサブのラップトップでも同じ。こっちもArch Linuxでハードウェア以外は同じソフトウェア環境。
死ぬほど困るわけじゃないがなんとかしたいね。 そういえばUbuntuもそのうちポイントリリースやめてローリングモデルにするって言ってたな ■ このスレッドは過去ログ倉庫に格納されています
