つい最近、IdeaPad3マシンでMX-21WildflowerKDEエディションをテストしました。爆風でした。私が多くの秋にサンプリングした最高のオペレーティングシステムの1つです。この大成功は私の希望を後押ししたので、テストをこのディストリビューションのXfceエディションに拡張することにしました。つまり、今日の実験のトピックです。
ここでも同じことをします。同じハードウェア、同じ条件。これらの2つのフレーバーがどれほど似ているか（または異なっているか）を確認できるので、興味深い試みになるはずです。どちらかといえば、私のほろ苦いLinuxの経験から、KubuntuやXubuntuなど、ほぼ同一のディストリビューションバージョン間のバリエーションが膨大になる可能性があることがわかりました。だから私はここで何を期待するのか分かりません。始めましょう。
今回は運が悪い！
物事は最初からひどく進み始めました。ライブセッションを起動しました。ここまでは順調ですね。新しいハードウェアでよくある問題である1920x1080pxの14インチ画面では物事が小さく見えるため、視覚的な変更をたくさん行うことにしました。
すぐに、私は多くの問題に遭遇しました。物事をきれいにするプロセスは、MX-19.3で達成したものよりもはるかに難しく、KDEで行うよりも光年困難でした。ただし、スクリーンショットがないため、これらの詳細についてはまだ説明しません。理由は？ライブセッションが終了しました！
どうしてそうなった？さて、約1時間の化粧品の仕事の後、私は昼食に行かなければなりませんでした。バッテリー電源に取り組んで、私はラップトップを一時停止することにしました。私が戻ってマシンを起こしたとき、ライブセッションは再開されませんでした。壁紙（紫の花をモチーフにしたもの）しか手に入らなかったのですが、ログイン画面はありませんでした。何もない。何を試しても、セッションは再開されませんでした。再起動を余儀なくされたため、すべてのスクリーンショットが失われました。
その後の試行
残念ながら、ここからもうまくいきませんでした：
- 2回目の起動、壁紙のみ、デスクトップなし-起動シーケンスが動作中のセッションに進むことはありません。
- 3回目の起動、壁紙は3分間のみ、そして最後にライブセッションが表示されました。
今のところ、インストール自体以外は何もしないことにしました。プロセスは私がKDEエディションで持っていたものと似ていましたが、それでも少し異なっていました。一貫性ftw！ KDEの場合、GRUBステップはライブメディア上のものを含む2つのESPパーティションを提供し、それはデフォルトで（誤って）選択されたものでした。 Xfceのものはしませんでした。マークされた正しいハードディスク上のESPは1つだけでした。以前と同様に、全体で約4分かかりました。
再起動後、GRUBメニューには2つの同一のMX-21エントリが表示され、どちらがどちらであるかわからない場合は、XfceとKDEのインストールを区別できません。起動は速くありませんでした。実際、それは非常に遅かった。繰り返しになりますが、システムは起動後のスプラッシュステップでハングし、実際に何かを実行できるようになる前に、壁紙が数分間表示されました。
電源を入れると、画面が暗くなります。予測可能な。 P.S.ログイン画面の明るさを上げることはできません。それを長いログイン遅延と組み合わせると、本当に迷惑になります。
CPUがうるさかった。常に働いています。理由はわかりません。次に、Firefoxを実行しようとしました。起動するのに数分かかり、狂ったようにプロセッササイクルを食べました。やがて始まりましたが、奇妙でした。
Firefoxウィンドウの境界線に注意してください。ただし、実際のブラウザウィンドウは表示されていません。
GeckoMainは50％のCPUを数分間消費していました。
システムはあまり反応しませんでした。また、システムログにはクラッシュエラーの痕跡がすべてありますが、少なくとも、そのバイナリjournalctlのナンセンスではなく、わかりやすく、現実的な正直なメッセージはありません。
[]コード：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[]ページ：0000000044d2de81refcount：1 mapcount：-1マッピング：0000000000000000インデックス：0x0pfn：0x0
[]フラグ：0x7ffffc0001002（referenced | reserved | node =0 | zone =0 | lastcpupid =0x1fffff）
[] raw：0007ffffc0001002 ffffed4040000008 ffffed4040000008 0000000000000000
[] raw：0000000000000000 0000000000000000 00000001fffffe br /> []ページがダンプされた理由：bad pte
[922.363846] CPU：7 PID：8964 Comm：IPC I / O Child Tainted：P OE 5.14.0-4mx-amd64＃1Debian 5.14.16-1〜 mx21 + 1
[]ハードウェア名：LENOVO 81W0 / LNVNB161216、BIOS E8CN23WW 07/28/2020
[]コールトレース：
[] dump_stack_lvl + 0x46 / 0x5a
[] print_bad_pte.cold + 0x6b / 0xc6
[]？ __mod_lruvec_page_state + 0x7f / 0xa0
[] unmap_page_range + 0x749 / 0xc80
[] unmap_vmas + 0x78 / 0xf0
[] exit_mmap + 0x9c / 0x1f0
[] mmput + 0x56 br /> [] do_exit + 0x2fa / 0xa90
[] do_group_exit + 0x33 / 0xa0
[] get_signal + 0x170 / 0x8d0
[]？ do_epoll_wait + 0xdb / 0x760
[] arch_do_signal_or_restart + 0xf0 / 0x7a0
[]？ finish_wait + 0x80 / 0x80
[] exit_to_user_mode_prepare + 0x119 / 0x180
[] syscall_exit_to_user_mode + 0x23 / 0x40
[] do_syscall_64 + 0x48 / 0xc0
[] entry_SYSCALL_64_after br /> [] RIP：0033：0x7f830eb3a9b9
[]コード：RIP0x7f830eb3a98fのオペコードバイトにアクセスできません。
[] RSP：002b：00007f8302bb2a88 EFLAGS：00000246 ORIG_RAX：00000000000000e8
[] RAX：fffffffffffffffc RBX：00000000ffffffff RCX：000070f830eb3a9b9
[] RDX：0000000000000020 RSI：0> [] RBP：00007f830e790880 R08：0000000000000001 R09：000000007fffffff
[] R10：00000000ffffffff R11：0000000000000246 R12：0000000000000000
[] R13：00007f8302bb2cd0 R14：00007f830e71bb00 R15：00007f830e
これは、AHSカーネルが対処する必要のある問題のように見えます。私の予想では、このエディションは正しく作成されていなかったため、これまでに見たものすべてを含め、ハードウェア関連のプロセスが多数ありました。
さて、私のLinuxカーネルのクラッシュ分析の本を読むと、分析が非常に興味深いことがわかります。 CSレジスタダンプが0033（奇数の最後の桁、本の詳細）を指している場合、これは、ユーザーランドエラーによってトリガーされたカーネルoopsを意味します。ハードウェアエラーまたはシステムコールの不良がない限り、これは通常は不可能です。ラップトップは安定しており、MX自体（およびWindows 11）を含む他の2つのオペレーティングシステムで正常に動作するため、このバージョンには、IdeaPadのファームウェアとうまく連携しない不安定なプラットフォーム固有のモジュールがあると思います。
さらに、起動中に、AMDGPUエラーが画面に表示されます。これは、KDEを起動したときには表示されません。ヒント、これは、特にハードウェアアクセラレーション（デフォルトで有効）を使用することを想定していて、適切なファームウェアサポートがないため、システムがGPUを正しく使用できない場合に、Firefoxが起動しない理由を説明する可能性があります。したがって、CPUが回転します。ですから、これは本当に悪い問題のように見え、私のレビュー全体を殺してしまいます。
それ以外...
さて、視覚的なスタイリングは悪かった。 MX-19.3よりも悪い。したがって、xrandrでスケーリングを増やすと、ネイティブ解像度を超えて画像を爆破するなど、すべてがぼやけてしまいます。これを行うと、Conkyも画面から消えます。かなり悪いデザインです。
スクリーンショットでxrandrスケーリングの問題を実際に見ることはできないと思います...
フォントのスケーリングとフォントサイズの増加は、少なくとも正常に機能します。しかし、下部パネルを高くすると、多くの問題が発生しました。 PulseAudioアイコンとバッテリーインジケーターアイコンは、システムエリアの他のインジケーターとは別に動作します。残りのサイズは（自動または手動で）変更できますが、これらは独自に動作するため、見栄えが悪くなります。 Bluetoothアイコンもその素敵なスタイルを失い、1999年のGnome-2のような古代のアイコンになります。
これは私がまともな外観を得たのと同じくらい近いです。
また、デジタル時計を大きくする必要がありました。パネルにはドックのようなアプレットがありますが、アイコンを手動で再配置することはできないため、アイコンの固定を解除してから固定して、好きなように並べ替える必要があります。これらすべての不要な問題とハードウェアの問題を組み合わせると、不発弾が発生します。
結論
MX Linux MX-21 Xfceは、私のMX-21KDEレビューとは正反対です。 Xfceは、おそらくこれまでにこのディストリビューションで経験した中で最悪の経験です。一般的な動作の鈍さ、ログインのフリーズ、サスペンドとウェイクの問題、Firefoxの速度低下、カーネルoopsなどの理由で、実際には何も適切にテストできませんでした。しかし、視覚的なカスタマイズは、1つの重要な側面を示しました。それは、KDEがどれほど高度であり、Xfceでのスケーリングがいかに脆弱であるかということです。
見栄えのするデスクトップを作るためだけに、20〜30個の個別のXfce要素を手動で微調整する気にはなっていません。それは2005年であり、停止する必要があります。 MX-21のXfceバージョンは悪くはありませんが、壊れやすいものです。さらに悪いことに、ディストロは過去にはるかに良く動作したので、私たちの手にも回帰があります。私が言えることは、KDEバージョンを選ぶことです。これは素晴らしいことです（私が今まで試した中で最高のシステムの中で）。 Xfceはワークショップに戻って、深刻な手直しをする必要があります。悲しいかな、そのメモで、そして私の脳の中でいくつかの軽度の妄想が渦巻いているので、私たちはこの悲しいレビューを終了します。