Arch Linux 18
シリアルコマンドであるstty についてお伺いしたいです。
cat /dev/ttyUSB0
で、文字列を持ってきているのですがよく止まります。
シリアル接続を全く理解していないのですが、これは同期を失った状態なのでしょうか？
何かのオプションを与えることで対応は出来ますか？
サービスに登録して、くるくる回しています。 stty -F /dev/ttyUSB0 115200 raw
cat /dev/ttyUSB0
すいません。215の件は、こうです。 パラメータをみるとこんな感じです。
stty -F /dev/ttyUSB0
speed 115200 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost
-isig -icanon >>215
相手と通信速度あってないんじゃないの？ >>215 >>218
通信速度が合ってないとそもそも文字化けして
コンソール表示がまともにされないと思う
経験上シリアル通信の安定性は物理的な接続状態(電気的接触)が
肝だから、端子間の接触、ケーブル長の見直し(できるだけ短く)、
ケーブルのシールド化、GNDへのアーシングとか試すといいかも それとシリアルアダプタの制御チップが
中華コピーのバッタモンだと通信できたり
できなかったり安定しなかった >>35の者ですけど
ROCｍが6になって、動かなくなったので簡単なインストールスクリプト作りました
#!/bin/bash
AppName="stable-diffusion-webui"
cd ~/
git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git
cd ${AppName}
# 環境設定
sed -i \
-e 's/#\?export COMMANDLINE_ARGS=.*/export COMMANDLINE_ARGS="--upcast-sampling --opt-sub-quad-attention --no-half-vae --medvram"/' \
-e 's/#\?export TORCH_COMMAND=.*/export TORCH_COMMAND="pip install torch torchvision torchaudio --index-url https:\/\/download.pytorch.org\/whl\/rocm5.7"/' \
-e '$s/$/\nexport HSA_OVERRIDE_GFX_VERSION=10.3.0/' \
./webui-user.sh
# ショートカット
tee "/home/$(whoami)/.local/share/applications/${AppName}.desktop" <<EOF >/dev/null
[Desktop Entry]
Categories=Graphics;
Exec=sh ~/stable-diffusion-webui/webui.sh
Icon=applications-graphics
Name=$AppName
Type=Application
EOF
# 構築して起動
./webui.sh あ
ショートカットだめだった
パスがずれちまう
何おこってるのか分かんなくなるから、ターミナルで実行して作業バス追加して
これでOKかな
# ショートカット
tee "/home/$(whoami)/.local/share/applications/${AppName}.desktop" <<EOF >/dev/null
[Desktop Entry]
Categories=Graphics;
Exec=sh webui.sh
Path=/home/$(whoami)/${AppName}
Icon=applications-graphics
Name=$AppName
Type=Application
Terminal=true
TerminalOptions=--noclose
EOF emacsでuimのツールバーで? A Rと表示されていて日本語入力ができないのですが
無変換 変換 かたかな/ひらがな/ローマ字などにShiftやCtrlなどを組み合わせて押してみたのですが
なおりません
uim キーボードショートカットとかで検索しても関係ない情報が多くて困っています
firefoxは日本語入力できてます。ツールバーは? あ Rと表示されています
誰かどうやって直すかご存知のかたいませんか なんかwaylandっての？これも悪さしてるみたい
キーボード配列が何度設定してもrebootしたらusモードに戻る >>213
そんな感じでしょやっぱ
自分でなんとかしろとか簡単に言うけど
無理だっての >>224
emacsもuimもわかんないんだけど
fcitxの例ですけど、Waylandだと、変換候補の小さいメニューが
となりの画面のはじっこに飛んでったり無茶苦茶でしたが
fcitx5になって改善されました
そもそも、Waylandってクソな仕様で
アプリ側でウィンドウの配置できなくしやがったので
こういうの対応させるんの大変だと思いますよ やっぱ結局ね外国語のことなんか真面目に考えちゃくれないんだろうね
自分とこの言葉が使えないなんてそれ事実上使用不能ってことだよね
何十年も前からある問題なのにね
結局こうなるわけね >>227
なんで、わざわざマイナーなuimなんて国産使っといて
外国に文句いってんすか？ まだまだWaylandに対応できてないアプリも多いから
安定した環境を構築できない人は無理せずX11使った方が幸せだと思う >>230
日本、中国、台湾もなのかな？
あとベトナムとかスリランカだか韓国とか
Manjaroだと、asian-inputって括りっすね
ibusでも良いのかも知れないけど
ibus-mozcがAURにしかないから、なんとなくfcitx5になっちゃうね なんか今回のことで日経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つ前にダウングレードしたら復活。
バグトラッカーが使いにくくなったなあ… 
