0001login:Penguin2023/12/28(木) 20:59:40.30ID:o+WHp/AG
0285login:Penguin2024/04/10(水) 12:05:39.12ID:qOINGveW
脆弱性の件でシステムアップグレードしてから起動してるといつの間にかハングアップすることが増えた
02872852024/04/10(水) 19:43:44.05ID:qOINGveW
NVIDIAのドライバをアップグレードするときにファイルが競合したから強制上書きオプションつけてやったんだよね
ゲームは特に問題なかったから関係なさそうだが
またシステムアップグレードしてみるか
0289login:Penguin2024/04/11(木) 22:08:51.37ID:WOK+swdT
いつの間にかWaylandでNVIDIAドライバから出力したディスプレイのリフレッシュレートが正常になってた
ゲームのfpsもx11の方がいいらしいし、waylandにするメリットって何？
waylandはモダンで安全性や保守性の高い仕組みで作り直したいという開発側の都合で始まったものに過ぎないので
単なるユーザーとしてはwaylandの方が完全に上位互換と見なせるようにになるか十分に普及するまで使う意味はない
Xはもうメンテナンスしてる人いないから
将来性が全く無いのと、セキリュティの面でも穴だらけ
実際win10出るまでは7使い続けるのが正解だっただろ
実際win10出るまでは7使い続けるのが正解だっただろ
0297login:Penguin2024/04/18(木) 23:11:08.63ID:xFPy5ABA
>>291
KDEの話ですが、タッチパッドのジェスチャーとかタッチパネル系とか
そういう新機能はWaylandにしか追加されないので
ラップトップで使ってるとかならメリットはあるかもです
もともと、モバイルファーストのwin8もどきのgnomeが主導してるってのも影響してんのかな
ぶっちゃけ、デスクトップならどっちでもいい >>291
ゲームってSteamのWineベースのWindows互換レイヤー使ってるやつだろ？
WineのWaylandサポートがまだ実験段階だから反応悪いのが当たり前
Waylandの使用が推奨されてるのはXの抱える諸々のセキュリティの問題に配慮されてるからだよ
ただ厳密になった分、使い勝手が悪くなってユーザーの不満が溜まってる どのみち現状ではWaylandに移行する気は起きないな
Xの互換で諸々の問題も解決するならいいが、
現状Waylandって使えんよね
ゲームはWindowsでやりますし。
hidpiのノート使ってるとwayland楽だ
0302login:Penguin2024/04/19(金) 17:06:41.96ID:2KKkUokK
>>300
Waylandは、nVIDIAが悲惨なだけで、AMDだと、まぁまぁ普通に使えますよ
Arch+KDEでおなじみの、StearmDeckも、Waylandですね
タッチパネルは、Waylandじゃないと、マウスのエミュレートになっちゃって
フリックとかできませんから… 0303login:Penguin2024/04/19(金) 17:43:26.60ID:wY2st0w1
その辺は全部libinputだからXでも同じようには設定できたはずと思うけど。
自分は既にX本体は使ってないから忘れたけど。
Arch公式のRubyのバージョンってなんでずっと3.0なの？
Debian stableよりも古い
>>306
やっぱり問題にはなってたのね
最新版が入るのはいつになるか分からないし諦めてrbenv使うかあ
なるべくpacmanで完結したいんだけどな 最近はちょくちょくパッケージのメンテナが連絡不能になっているから
ユーザーは増えてきても実際には末期状態かもしれないな
0309login:Penguin2024/04/25(木) 07:01:10.17ID:DHendrMY
rubyってちょっと油断するといつのまにか入れられるんだよね。
pythonは諦めてる（一応自分でも使ってる）けど、rubyまで滑り込んでくるのは我慢ならない。
>>309
数少ない国産の有名言語だから(比較的)
無下にしないであげて…自分は入れてないけども システムアプデ後にあるパッケージのsystemd daemonが起動せず
とりあえずパッケージのリビルドでまた起動するようにはなったけれど
たぶん依存パッケージの指定がどれか漏れてるとかなんだろうけどどのパッケージに依存しているか不明っていう＼(^o^)／
0312login:Penguin2024/04/28(日) 16:58:44.97ID:TD/1Xpsj
昨日辺りでpythonが上がったからな。しばらくすったもんだするかも。
0313login:Penguin2024/04/28(日) 21:26:43.02ID:D/L954Af
cups がプリンタを見つけられなくなった。
1つ前にダウングレードしたら復活。
バグトラッカーが使いにくくなったなあ…
kittyとweztermがまともに動かなくなったぜ
なぜかalacrittyだけ無事だった
icu が上がったらおまえらキレそうだな
ffmpeg も同時に上がったら発狂しそうだな
>>312
そーだったのかｗ
chirp-nextが起動不能になったもんだから、ターミナルで起動
してエラーメッセージみたら納得したｗ fcitx5デーモンを立ち上げない場合端末の不具合は発生しない…つまり原因は…
archlinux.jpのssl証明書、期限切れじゃないか？
久々にArchで環境作ったら
mozc、mozc-ut共
AURでビルドエラーで止まる。
いつか直るかな。
とりあえずanthy使ってる。
0322login:Penguin2024/05/11(土) 18:37:09.48ID:2tUA/r1D
>>321
DEなんだか知らないけど、 fcitx5-mozcならリポジトリにありますので
mozc使うなら、fcitx5がいいですよ 0323login:Penguin2024/05/12(日) 08:29:50.78ID:VRNQJeMw
>>321
mozc-utだけど自分の環境ではちゃんとビルドできてるな
自分の経験上メモリが8GB未満なら必ず失敗する
とりあえず~/.cache/bazelを削除して再ビルドするのがいいかも
なぜかArch公式のfcitx5-mozc勧めてる人いるけど古いしemacs mozcが使えなくなるから使ってる人はいないと思う >>323
横だし話はまったく別だが、
> 自分の経験上メモリが8GB未満なら必ず失敗する
これマジ？最近の状況全く知らんが、そもそも論として、ビルドに8GB食うとは思えないし、
食ったとしてもスワップ行くだけ、つまり遅いだけで通るはずなのだが。
(少なくともWindowsならスワップは自動増加がデフォなのでメモリが足りなくて落ちることはない。クソ遅くはなるが。
そしてLinuxには未だにスワップを自動増加する設定がなさそうなのはショボ過ぎだが) 0325login:Penguin2024/05/12(日) 14:40:44.63ID:d4bT51jn
>>323
emacsってデフォアプリなんすか？
私のArchには入ってませんけど
ビルドでコケるよりはマシな気がしますが… >>322
入れました。
fcitx5-mozcだけで、使えるのですね。
mozcというパッケージが必要と思い込んでいました。
古いらしいですが、特に問題無いので
このパッケージのを使います。
ありがとう。 >>323
メモリ、８GBちょうどなんですけどね。😥
もう一回ビルドしてみます。 >>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で完走した
0331login:Penguin2024/05/13(月) 07:48:08.13ID:ELtAGQGa
やっぱりbazelは面倒だな
mozc-utはもはやArch必須パッケージみたいなものだからなんとかしてほしいところ
UT辞書はライセンスバカがしょーもないことを触れ回ったせいでビルド済みバイナリを配布するのも難しい状況だし
CC=clang CPP=clang++ bazel .....
環境変数つけるだけじゃ？
>>329
> Mozc のビルドに失敗する (プロセスが強制終了される)
> ビルドが以下のようなメッセージで異常終了した場合:
>
> ...
> /bin/sh: 1 行: xxxx 強制終了
> ...
> make: *** [xxx/xxx ...] エラー 137
> ...
> メモリ不足になっていないか確認してください。
> ttps://wiki.archlinux.jp/index.php/Mozc
のとおり、実際にメモリ不足になると止まるように設定されているようだ。また、
> 従来はメモリー不足によりOSの応答性が著しく低下し、もしくは無反応になり、
> ユーザーはPCを強制的に再起動せざるを得ませんでした。
> この状況を改善するため「systemd-oomd」を導入し、
> システム的にメモリー不足に陥る前にユーザースペースで「OOM Killer」を実行してメモリーの空き容量を確保し、
> システムの応答性低下を緩和することになりました。
> ttps://kledgeb.blogspot.com/2022/07/ubuntu-2204-224-systemd-oomd.html
とあるから、とりあえずはビンゴっぽい。そのページの下のほうに書いてあるが、一時的に停止するには
> sudo systemctl stop systemd-oomd
だとさ。archでも全く同じかは知らんが。
ただまあ、ビルドに8GB食うのはおかしいと思うから、多分どれかのツールがメモリリークしてるのだろうが、
ディストリ側としてはどうにもならんから、この対処なのだろう。
(普通に考えれば、これならarchWikiに一時的解除の方法を載せれば良いだけだが、
それよりはメモリ不足で諦めさせたほうがいい、という判断になっているのは、
おそらく一時的に解除してビルドした場合、実際に再起動せざるを得ないケースに遭遇することになる、ということなのだろう)
というわけで、確定させたければ再起動上等で試してみるんだね。