Arch Linux 18
なんか今回のことで日経Linuxが廃刊になった理由が分かった気がした 問題ってね 見たくなければ見えないのよね なんでロケットが打ち上げ失敗するか分かったでしょ こんなんでもね へっ素人が事情も知らずに偉そうに みたいな感じで終わっちゃうのよね 現に失敗してるって一番重要なことはワキによけてね んで進歩は無くなる そんなもん 問題点って誤魔化そうとすれば幾らでも無限に出来るからね 今流行りのウソつき大谷事件とか典型ね Archの問題でもなければましてやLinuxの問題でもない Archの想定するユーザーでない人が何となく格好いいから程度の理由でArchを使おうとすることにより生じる問題だろう Archが想定するユーザーは自力で直せるか、少なくとも修正に必要十分な情報をコミュニティに提供できる人だけ 以下の「1.4 ユーザー中心であること」をよく読むべき https://wiki.archlinux.jp/index.php/Arch_Linux >>224 俺の環境でも起きてる。設定 > 仮想キーボードで fcitx5からfcitx5ランチャーに選択した時点で キーボードレイアウトがもれなくUSに変わり、loadkeys コマンドも全然効かない(動くがus に しようがjp106にしようが結果に反映されない)。 /etc/locale.conf も /etc/vconsole.conf も正常。 で、対策としては起動したらキーボードを設定し、あとはスリープを使う。という超後ろ向き 対策。Macで使ってる英語キーボードをこっちでも使ったら解決なのかも。 fcitxはキーボード設定を上書きするらしい fcitxの設定で解除できる さんくす。 fcitx5設定画面が、ツールチップメニューの設定からしかいけなくなってたことと、そこで 入力メソッドオフが今までUSでもよかったのがキーボード・日本語を設定しないといけなくて そいつが普通の設定のキーボードのレイアウトを上書きする というトラップ 一見さんには分からんわ ちがった。 お気に入りテーマを入れようとして説明見たら設定で入力メソッドが後ろの方にあって、そっちで やることって書いてあって。。。恥。 上書きしているわけじゃなくて、個別で設定を持っているだけだろ。 確か、vconsole.confはdebianにはない設定ファイルだし。 ~/.config/fcitx5/profile ではなくて? 個人設定だけどなぜ全体の設定で出来ないのか… fcitxって全体の設定はあるのだろうか? iBusの方が好みだけどAUR使わないとだしね /etc/vconsole.conf はArch系にしかないので、fcitx configration toolが気を利かせて vconsole.conf と連動しろよってのはfcitxには酷な話。 逆に設定画面で言語と地域の主ペインを入力/出力デバイスの主ペインの前に持って きてればユーザが入力メソッドに先に目が行くだろうにって思ったりするが、それで 困ってんのは日本人と中国人くらいだろうからなあ。 >>224 カスタマイズやテーマを設定できるので全体設定でやられたら他ユーザーに影響が出ちゃう vconsole.confってsystemdが読んでんのかと思ってたけどArch固有なの? もうOpenBSDのチームで作られたものしか信用できない… 今すぐアップグレードしろってアナウンス出てるな Arch Linux - News: The xz package has been backdoored https://archlinux.org/news/the-xz-package-has-been-backdoored/ >>254 それ読んでたんだけど、 ldd "$(command -v sshd)" ってやって、「liblzma」が出てこなければ とりあえずは、大丈夫って書いてあんね ただ、この問題のコミッター2年ぐらい前から活動してて700件ぐらいコミットしてたらしいし 他にもなにかあるかも知れないから、注目しとかないと 残念な事にアクティブなメンテナの一人が実行犯のようだからxxなら信用出来るという類いのものではないような 報告者は偶然バックドアに気が付いたらしいけど、しばらく放置されてRHELやdebianのstableにも入ってたら大問題だっただろうな 奴が関わった部分は精査しないとな、脆弱性の種が仕込まれてるかも これを発見したのがMicrosoftのエンジニアってのがなかなか… >>257 几帳面にベンチマークとるデータベースシステムのエンジニアが偶然見つけた感じ 本当にラッキーだったね もし過去のコミットにも仕込んでてstableなディストロにまで波及したら大事だな libarchiveにもJiaT75が疑わしい変更を加えていた模様(2021年 ネットバンクのパスワードと抱えたほうがいいの?(´・ω・`) >>252 他のディストリビューションはsshで外に晒してた奴は クリーインストールで入れ直せって言ってるぞ あと認証関係全部やり直し >>263 それ、侵入されちゃった可能性があるからじゃないの? Archは、sshとリンクしてないから大丈夫 散々古いだのパッチが多いだの文句言われてるdebianの仕組みが役に立ったのか。 liblzmaに関してはxzの上流が配布してるtarballに悪意のあるもんが含まれてたけどgithubで公開されてる方には入ってなくてArchは後者の方使ってたから一応それに関しては実際は問題ないって話もあるみたい? まあ攻撃者があちこちにいっちょ噛みしてて他にも色々出てきそうやけど >>266 でも Archは余計なパッチ入れてなかったから助かったんですけど… >>267 そもそも、Archでは、sshとリンクするパッチないんで攻撃成立しないけど 念の為、ソースを変更した、xz 5.6.1-2を緊急でリリースした って感じだと思いますよ これはほんとにたまたまだろ。 archの場合は基本的に何もせずにただ放流するだけだから、こういう類の攻撃には一番脆弱といえる。 それに、今回のはfedoraやsuseなども影響受けているので、任意のライブラリであってもほぼ必須扱いなものということだろう。 >>269 そうそう たまたま、一番脆弱なはずの、Archだけが影響うけませんでした 他にも何か仕込まれてる恐れがあるから JiaT75が関わる以前の5.3.1に戻したほうがいいって話もあるな でもそこまで戻したら依存関係で色々ぶっ壊れるって言ってるね 5.3.1ベースに元からのメンテナーに頑張って修復してもらうしかないな アメリカさんあたりがテロリストとして犯人○してくんねぇかね >>255 てかこの対処あかんやろ lddのmanに書いてあるけど信頼できるかわからん疑惑の実行ファイルに対してlddすんのはアウトや >>276 ちょいちょい、その指摘されてますけど ぶっちゃけ、対処ってか、確認だから、やる必要ないっすよ とりまArchユーザーがやるべきことは、いつも通りアプデして、xz 5.6.1-2 に更新するだけです 問題ってね 見たくなければ見えないのよね なんでロケットが打ち上げ失敗するか分かったでしょ こんなんでもね へっ素人が事情も知らずに偉そうに みたいな感じで終わっちゃうのよね 現に失敗してるって一番重要なことはワキによけてね んで進歩は無くなる そんなもん 問題点って誤魔化そうとすれば幾らでも無限に出来るからね 今流行りのウソつき大谷事件とか典型ね . 問題点って 誤魔化そうとすれば幾らでも無限に出来るからね 今流行りのウソつき大谷事件とか典型ね . 違法賭博は大谷がやったんだよ。でもそれ言うと極悪人みたいな扱いになっちゃうでしょ? 問題点に注目するヤツは「空気の読めない悪人」だから。 これをLinuxでもロケットでも政治でもやるわけな日本人は。 脆弱性の件でシステムアップグレードしてから起動してるといつの間にかハングアップすることが増えた NVIDIAのドライバをアップグレードするときにファイルが競合したから強制上書きオプションつけてやったんだよね ゲームは特に問題なかったから関係なさそうだが またシステムアップグレードしてみるか いつの間にかWaylandでNVIDIAドライバから出力したディスプレイのリフレッシュレートが正常になってた ゲームのfpsもx11の方がいいらしいし、waylandにするメリットって何? waylandはモダンで安全性や保守性の高い仕組みで作り直したいという開発側の都合で始まったものに過ぎないので 単なるユーザーとしてはwaylandの方が完全に上位互換と見なせるようにになるか十分に普及するまで使う意味はない Xはもうメンテナンスしてる人いないから 将来性が全く無いのと、セキリュティの面でも穴だらけ 実際win10出るまでは7使い続けるのが正解だっただろ 実際win10出るまでは7使い続けるのが正解だっただろ >>291 KDEの話ですが、タッチパッドのジェスチャーとかタッチパネル系とか そういう新機能はWaylandにしか追加されないので ラップトップで使ってるとかならメリットはあるかもです もともと、モバイルファーストのwin8もどきのgnomeが主導してるってのも影響してんのかな ぶっちゃけ、デスクトップならどっちでもいい >>291 ゲームってSteamのWineベースのWindows互換レイヤー使ってるやつだろ? WineのWaylandサポートがまだ実験段階だから反応悪いのが当たり前 Waylandの使用が推奨されてるのはXの抱える諸々のセキュリティの問題に配慮されてるからだよ ただ厳密になった分、使い勝手が悪くなってユーザーの不満が溜まってる どのみち現状ではWaylandに移行する気は起きないな Xの互換で諸々の問題も解決するならいいが、 現状Waylandって使えんよね ゲームはWindowsでやりますし。 hidpiのノート使ってるとwayland楽だ >>300 Waylandは、nVIDIAが悲惨なだけで、AMDだと、まぁまぁ普通に使えますよ Arch+KDEでおなじみの、StearmDeckも、Waylandですね タッチパネルは、Waylandじゃないと、マウスのエミュレートになっちゃって フリックとかできませんから… その辺は全部libinputだからXでも同じようには設定できたはずと思うけど。 自分は既にX本体は使ってないから忘れたけど。 Arch公式のRubyのバージョンってなんでずっと3.0なの? Debian stableよりも古い >>306 やっぱり問題にはなってたのね 最新版が入るのはいつになるか分からないし諦めてrbenv使うかあ なるべくpacmanで完結したいんだけどな 最近はちょくちょくパッケージのメンテナが連絡不能になっているから ユーザーは増えてきても実際には末期状態かもしれないな rubyってちょっと油断するといつのまにか入れられるんだよね。 pythonは諦めてる(一応自分でも使ってる)けど、rubyまで滑り込んでくるのは我慢ならない。 >>309 数少ない国産の有名言語だから(比較的) 無下にしないであげて…自分は入れてないけども システムアプデ後にあるパッケージのsystemd daemonが起動せず とりあえずパッケージのリビルドでまた起動するようにはなったけれど たぶん依存パッケージの指定がどれか漏れてるとかなんだろうけどどのパッケージに依存しているか不明っていう\(^o^)/ 昨日辺りでpythonが上がったからな。しばらくすったもんだするかも。 cups がプリンタを見つけられなくなった。 1つ前にダウングレードしたら復活。 バグトラッカーが使いにくくなったなあ… kittyとweztermがまともに動かなくなったぜ なぜかalacrittyだけ無事だった icu が上がったらおまえらキレそうだな ffmpeg も同時に上がったら発狂しそうだな >>312 そーだったのかw chirp-nextが起動不能になったもんだから、ターミナルで起動 してエラーメッセージみたら納得したw fcitx5デーモンを立ち上げない場合端末の不具合は発生しない…つまり原因は… archlinux.jpのssl証明書、期限切れじゃないか? 久々にArchで環境作ったら mozc、mozc-ut共 AURでビルドエラーで止まる。 いつか直るかな。 とりあえずanthy使ってる。 >>321 DEなんだか知らないけど、 fcitx5-mozcならリポジトリにありますので mozc使うなら、fcitx5がいいですよ >>321 mozc-utだけど自分の環境ではちゃんとビルドできてるな 自分の経験上メモリが8GB未満なら必ず失敗する とりあえず~/.cache/bazelを削除して再ビルドするのがいいかも なぜかArch公式のfcitx5-mozc勧めてる人いるけど古いしemacs mozcが使えなくなるから使ってる人はいないと思う >>323 横だし話はまったく別だが、 > 自分の経験上メモリが8GB未満なら必ず失敗する これマジ?最近の状況全く知らんが、そもそも論として、ビルドに8GB食うとは思えないし、 食ったとしてもスワップ行くだけ、つまり遅いだけで通るはずなのだが。 (少なくともWindowsならスワップは自動増加がデフォなのでメモリが足りなくて落ちることはない。クソ遅くはなるが。 そしてLinuxには未だにスワップを自動増加する設定がなさそうなのはショボ過ぎだが) >>323 emacsってデフォアプリなんすか? 私のArchには入ってませんけど ビルドでコケるよりはマシな気がしますが… >>322 入れました。 fcitx5-mozcだけで、使えるのですね。 mozcというパッケージが必要と思い込んでいました。 古いらしいですが、特に問題無いので このパッケージのを使います。 ありがとう。 >>323 メモリ、8GBちょうどなんですけどね。😥 もう一回ビルドしてみます。 >>323 ~/.cache/bazelを削除して(実はこれも前回やりましたが)、 ERROR: /home/yamato99999/aur/mozc-ut/src/mozc-ut-git/src/protocol/BUILD.bazel:140:14 Compiling protocol/user_dictionary_storage.pb.cc failed: (Exit 1): gcc failed: error executing CppCompile command (from target @@com_google_protobuf//src/google/protobuf:protobuf) /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 62 arguments skipped) Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging INFO: Elapsed time: 334.405s, Critical Path: 39.55s INFO: 1055 processes: 511 internal, 544 linux-sandbox. ERROR: Build did NOT complete successfully ==> エラー: build() で問題が発生しました。 中止... mozc-ut こんなエラーでビルド止まります。 mozc も同じです。 何でしょね? 噂ではswap領域が十分でもsystemd-oomdが強制終了させるという話がありますね 他の環境(fedora)自前でmozc buildしてるけど最近のgccじゃ通らんclangで完走した やっぱりbazelは面倒だな mozc-utはもはやArch必須パッケージみたいなものだからなんとかしてほしいところ UT辞書はライセンスバカがしょーもないことを触れ回ったせいでビルド済みバイナリを配布するのも難しい状況だし CC=clang CPP=clang++ bazel ..... 環境変数つけるだけじゃ? read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる