まず、リンクなどのご提案いただきありがとうございます。
はい、リンクだけにするというのは様々なページで何度も検討したのですが、未だにその方がよいという結論には至っていないのが現状です。
例えば、アプリケーション一覧のページは単に物量が多いだけではなく、編集を受ける頻度も高いと考えており、仰られている「更新が激しく膨大なリスト」に該当すると思っております。
ただ、そのアプリケーション一覧を全て英語版へのリンクに変更することを考えると、初心者から上級者まで誰に対しても、英語スキルがあってもなくても役に立つコンテンツではなくなってしまいます。
もちろん、英語が苦手な人はコミュニティに聞いていただく、という運用も理論上は可能だと思いますが、果たして初心者の方に気軽に聞いていただけるのかと言うと、なかなか厳しいのではないかと思っています。
また、仮に聞いていただくことができたとしても、毎回同じようなおすすめのソフトウェアの質問が続けば、回答する側も疲れてしまうでしょう。
このように、益のない議論[1]を繰り返さないためにも、
翻訳が不十分であったり、古くなっていたり、情報が不正確であったりしても、ベストエフォートで日本語訳の情報を提供し続けることに意味があると考えています。
もちろん、一部リスト(英語版のみに適用される場合など)はコピーだけして翻訳しないこともあります。そこはそれぞれの方にお任せしますし、古くなっているページが多い現状を考えると、英語版へ同期のみして、新たな訳出をしない、というのも許容できる範囲かなと思っています。
[1] https://wiki.archlinux.jp/index.php/%E8 … shed.22.29
また、情報の誤りに関する指摘もありがとうございます。
通常このようなご指摘に関しては、Wikiのアカウントをお持ちの方には議論ページで報告していただいた方が嬉しく思います。
(もちろん、複数の話題があったり、アカウントを持っていない場合に他の場所で報告していただくのは問題ありません。)
上でも軽く触れましたが、必ずしも不正確な情報が残ることが多いわけではないと考えています。翻訳者の知識のある範囲内であれば、翻訳の際に間違いに気付いて、英語版で修正してから翻訳することもあると思います。
また、英語版の方が編集を受ける機会も多く、比例するように間違った編集を受けることも多いでしょう。その場合には日本語版が正しいということになります。
さて、当該ページにつきましては近いうちに内容の更新をするつもりではありますが、ご自身で修正していただくことも歓迎いたします。
というのも、悪意を持った編集ではない限り、内容をよくするという同じゴールへ向かった編集であるため、仮に間違いが(本家のものか翻訳時のものかに関わらず)あったとしても、
それは1から修正するよりもはるかに編集が楽になります。
個人的な話、私は毎日編集しているのですが、スクロールしないといけない差分が出ていると結構げんなりしてしまっています。
あと、正直な話、このようなリストであれば大部分は機械的な同期をすればよく、翻訳しなければならない部分は少ないので、作業としてはかなり楽な部類に入ると思っています。
例えば、上の[1]のページの本文が大きく書き換えられたときの労力は結構大変なものでした。私が翻訳に慣れておらず、学習のために機械翻訳を使わないようにしているというのもありますが。
更に、現在ではwikiの外で管理されており、日本語訳を置く場所についてもかなり悩んでいる所です。
と、いうように考えていますがいかがでしょうか?
古いページにはTranslateme[2]というテンプレートをページ上部に貼ることで、英語版の参照を促すこともできるかと思っております。
wikiを編集いただき、またご意見までいただき、本当にありがとうございます。
wipefs --all /dev/sdx
この sdx は対象のデバイスに置き換える必要があります。今回だと (4GBのものだと) sda ですね。
まあ私は wipefs 使ったことないですが。
権限がルートなのは、マウントオプションで変更できたかなと思います。udevilなんかで自動でマウントされるようにしてあるのでしたらそちらに設定があったかと(udevilは始めからユーザー権限でマウントする気もしますが。)
手っ取り早いのは、root権限でパーティション内にディレクトリを作成、ユーザーが書き込みできる権限を付与し、その中のみを使う、という感じでしょうか。
一応調べてみました。
sudo sed -i -e "s/WOL_DISABLE=Y/WOL_DISABLE=N/g" /etc/default/tlp
Manajroはデフォルトで、TLP(電源管理)が入っていて、WOLが無効にされてるので有効化する
https://qiita.com/oioi/items/6ebe58aa313904ab9dbe
とのことです。
使われているOSがUbuntuとManjaroということで、ここではあまり詳細なサポートは期待できないと思いますが、私からは一般論だけ……。
私がWake On Lan を使っていたときはBIOSの設定以外はいじっていなかったような……
Archでは確かやったことがないので分かりませんが。
Ubuntuがどのような仕組みでWoLを有効化しているのかは分かりませんが、BIOSの設定なんかも一度確認されてみてはどうでしょうか。
また、マジックパケットの送信先をブロードキャストにして試してみるというのも案としてはあるかと。
あとはPCのLANポートとルーター(スイッチ)間がシャットダウン後にリンクアップしたままかどうかも確認した方がいいと思います。
WoL自体はOSと関係のない部分なので、問題の切り分けは特に重要になってくるかと思います。
>BIOSモードで起動するかUEFIモードで起動するか
こんな選択肢があったとは知りませんでした。
上記を知ってGoogle先生に問い合わせたところ、いろいろ知ることができました。ありがとうございます。
勉強になりました。m(_._)mまた、今後迂闊な発言がないように心がけたいと思います。
ブートローダーやファイルシステム周りは普段ほとんど意識することないですからねw
解釈によっては何も嘘は言っていないですし。質問とはズレていて勘違いはされそうなので補足した次第です。
私も現状の知識ベースで、確証を得ずに発言していることがほとんどですし、特に気にされることもないと思います。
間違いを認められるだけで十分だと思っていますよ。
しかし、Slack で質問していただければ、人も多いし解決も早くなるかなと思うのですが。
既存のシステムがBIOSであれば、そのままBIOSで問題ないと思います。
Live USBはUEFIで起動が可能なので、PCがUEFIに対応していたためUEFIで起動したのだと思います。既存のシステムには影響はありません。
既にGPTに変換されたようですが、MBRのままでも問題はないはずです。
また、fdiskでパーティションのサイズを減らしたとありますが、一般的には先にファイルシステム(ext4など)のリサイズが必要だったと記憶しています。
私だったら、sda4に/以下のディレクトリ構造を全て入れてしまって(sda4内にhomeディレクトリを作り既存ファイルを移動して、sda2の/やsda3の/varなどをsda4直下に移動)、fstabやブートローダーの設定を更新して、sda2とsda3のことは綺麗さっぱり忘れてしまうかもしれません。
BIOSにUEFIはインストールできない
UEFIをインストールする必要はなく、BIOSモードで起動するかUEFIモードで起動するか、ということだと思います。
UEFIは一般的にCSMによりBIOSモードでの起動をサポートしているので、それを利用して既存のシステムが起動しているのだと思います。
UEFIモードで起動するように設定し直す(GRUBをインストールし直す)こともできますが、わざわざそうするメリットもないと思います。
はい、一般には仰る通り Live CD などの環境から行うことが前提になると思います。
詳しく言うと、マウント中のパーティションは基本的に (ext系など) サイズなどを操作することができなく、何らかの方法でアンマウントする必要があるため、通常起動中のシステムで使用中のパーティションのサイズ変更は難しいと考えています。
ただ、Raspberry Pi OS なんかの例もありますので、init の段階などで適切にコマンドを実行すれば不可能ではないかと。Arch での例は存じ上げませんが。
また、これは Arch に関する質問なのでしょうか?例示されているリンクも redhat のものですし、Arch に関係しない質問であれば、より適切な場所があるかと思います。
同一機種ではなく、xfceも使っていませんが、手元の linux-5.6.13.arch1-1 と firefox-76.0.1-1 の環境で、 `echo mem | sudo tee /sys/power/state` をしてサスペンド後、電源ボタンで正常に復帰しており、再現できませんでした。
カーネルパニック時の画面の写真を外部アップロードサービスにアップロードしていただき、リンクを貼っていただけるともう少し詳しい情報が分かるかもしれません。
ですが、私はカーネルパニックにはあまり詳しくないので、解決できる保障はないですが……
もし過去バージョンで正常に作動していたのであれば、再度ダウングレードした上で問題が起きないことを確認されるとよいかと思います。
REISUB、というより Magic sysreq ですね。私が初期に勘違いしていて動作しないと思った原因は、Altキーを途中で離してしまったとかだった気がします。
`journalctl -f` でメッセージが表示されるので、それを開いた状態で Alt を押す→Sysrq を押す → (必要であれば Sysrq を離して) h を押す → Alt を離す、をして
journalctl が何かメッセージ(Sysrq のヘルプ)を表示するのであれば正常に作動していると思います。
あと、閉じてすぐだとプロセスが残っていたりするので、ps や pstree で終了していることも確認してみるといいかもしれないです。
推測ですが、そのエラーがスリープから復帰したタイミングというわけではないのであれば、以下のいずれか、
6.3 [ERROR]Cannot access secondary GPU: No devices detected
6.3.1 NVIDIA(0): Failed to assign any connected display devices to X screen 0
スリープから復帰したタイミングであれば、以下、
6.3.3 Failed to initialize the NVIDIA GPU at PCI:1:0:0 (Bumblebee daemon reported: error: [XORG] (EE) NVIDIA(GPU-0))
が近いでしょうか。
どれもぴったり一致するエラーメッセージはなさそうですね……検索してもヒットしませんでした。
可能であれば、挙げられた選択肢の中に書かれている解決方法を1つずつ試していくと、どれかでうまく解決できるかもしれません。