Fedora 総合スレッド Part 61
■ このスレッドは過去ログ倉庫に格納されています
>>444 勉強になりますありがとう。私ジジイで文字コード論争を見てきたつもりですが知りませんでした emacsで矢印文字が半角の幅になるのって、こういうの関係してるのかな >>445 右矢印ってのが→なのか分からんけど、→は2192 RIGHTWARDS ARROWだとすると、 https://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt で、 2190..2194;A # Sm [5] LEFTWARDS ARROW..LEFT RIGHT ARROW と定義されてて、これを見るとAとなっていて、これは曖昧幅文字にあたる なのでちゃんと対処しないと半角で表示されてしまうだろう 対処方法は状況によって違うので適宜検索してくれ そもそもeast asian width仕様に完全準拠したフォントは結構珍しい 準拠すると同じ言語の文字がチグハグな幅になったりするしな。unicodeが悪いよunicodeが font問題は機械学習で切り込めそうだな やっても地味であんま儲からないと思うが >>448 同じ言語の文字がちぐはぐってどういう事?意味が分からん 言語って何?ロケールの事? ロケールは同時に複数存在しない認識だけどね >>451 Linuxの場合はwcwidth()ハックで対処可能だ エディタのパッチは不要 もちろん文字幅の判定にwcwidth()使ってなければ無理だけど、普通は使ってる >>453 対応できてるエディタ教えて 反例うpするから >>455 反例てw そもそもエディタなんてそんなに知らんからな それにこの問題は端末エミュ上の問題だ 端末エミュ上のエディタなんてEmacsとVimしか知らんよ 両方wcwidth()ハックじゃない方法で対応可能だ 端末の場合は文字がいわゆる半角か全角かは極めて重要な問題だ 端末エミュとアプリでズレがあると、それがそのまま表示のズレになる GUI版の場合は、アプリがフォントの幅を把握して描画してるので、EAWな文字が半角であろうが全角であろうが表示がズレることはない せいぜい矢印が半角になってて気持ち悪いぐらいなもんだw >>456 どっちも使ってるから 使えるフォント教えてくれ ギリシャ語の文章が全部FULLWIDTHで書かれて読みにくい、か、日本語の文章の中に出てくるギリシャ文字が全部HALFWIDTHで書かれて読みにくい、のどっちかは等幅だと発生しない? ターミナルが崩れるのはもうそういうものだと思って妥協してるわ。 フォント初心者なのだが、エディタのフォントはこだわりなければ noto sans mono でいい? O, 0 とか l, 1 の区別が付きやすければいいのだけど。 >>461 TakaoGothic以外で良いのあったら上げて欲しいわ ターミナルの種類も頼む >>452 日本語とかギリシャ語のこと。ロケールは全く関係ない 例えば>>460 は日本語フォントだとギリシャ語は全角になることを挙げているが east asian width仕様ではギリシャ語の全ての文字がそうなるわけではなく、JISコード(を含むCJKに元々存在していた文字コード)にある文字だけが全角になる で、実際のフォントはそんなアホな作り方をしないので仕様を無視してそろえて作られる すると>>457 の言うように端末の把握している幅とずれる 実際にどうなってるかはフォントによるので一貫した解決は無理。精々、合成フォント作るときに仕様に外れた文字を消すぐらい >>463 ギリシャ語にはそんな問題が有るのか でも日本人はαβみたいなギリシャ文字は使うけど、ギリシャ語のテキストは見ないからなw 曖昧幅文字にギリシャ文字が含まれてるけど、これを全角で表示する必要が有るのか? 半角の方が絶対良いだろう Unicodeのバグだなw ちなみに、ここはFedoraスレだから、端末エミュは普通にGNOME TerminalでOK 曖昧幅文字を全角にする設定がある でフォントは、Migu 1Mを好んで使っている これはコーディング用フォントなんで、1と大文字アイや小文字エルや縦棒と区別付く ゼロと大文字オーも区別付く 曖昧幅文字は全角になる Fedora36でGnome TerminalをIPAゴシックで使ってるけど 全角設定では○×と入力すると○を消せなくなる 半角設定なら消せるけど表示がおかしい emacs -nwを起動するとその中では問題なく表示できるし消せる 今試したら半角設定だとemacs -nwでも表示がおかしかった ○と×が半分重なってる >>467 Emacsは自前で文字幅を割り出してて、曖昧幅文字は全角になる なので上手く行く 他のアプリはwcwidth()を使ってると、glibcの実装は半角幅を返すのでおかしくなる これを修正するのがwcwidth()ハックだ >>469 端末エミュ、アプリ、フォントの3つが足並み揃えないとおかしくなる アプリ毎にサウンドの出力デバイスを切り替えたいけど、GNOMEで出来ないな… もし出来るならやり方書いてるWebページを教えてください HelvumっていうPipeWire用のアプリを見つけた これはマジで凄い! 本当にPipeを繋げて出力デバイスを選択できる LをスピーカーでRをBluetoothに出力するとかも簡単にできる(もちろん意味ないけどw) しかしながら、アプリのデフォルト出力先を覚えてくれないので、例えばブラウザとかは動画を停止して再生しただけでデフォルトに戻ってしまう 今のところ常用出来ないけど可能性は感じる バージョンアップに期待 今までUbuntuをずっと使ってたんだが試しにFedora36入れてみて少し使ってみてるけど、かなり安定してるような気がする 安定性やセキュリティってUbuntuとFedoraだと一般的にどっちが上なの? >>475 昔はどうだったか知らないけど安定性は悪くない Ubuntu LTSの方がトラブルは多かった印象 自分の技量の問題かもしれないが セキュリティは常に最新版を入れていれば大丈夫 アップデートは早い >>476 なるほど了解 枯れたバージョンのがいいのかとFedora36を入れてみたけど37を入れても問題はないのかな? Fedoraは最新バージョン入れても日常使いなら問題はない感じ? >>477 横だけど dnf update で偶に~~だけど ほぼ大丈夫 2005年頃から使い始めて15年程経つ。Fedora10の頃だとグラフィクドライバーが統一されてなくて インストールに苦労した経験がある。小さな不具合はあるとして大きな不具合がなければ良いで使ってる 訳を語ると長いから省くけどアプリ制作ではwindows、アプリを使用するOSとしてはLinux Fedora35から「dnf upgrade」でFedora36にできなかったのでDVDメディアを使ってFedora37にした Evolutionでバックアップデータをリスト-したが最初は反映されてなかったがいつのまにか反映されてた fedoraはメンテ期間が短いし、LTSもないしな かと言って、最新を追いかけると稀に躓くし 昔の定義が悪さしてると嫌なんで、半年に1回インストールして変わったところ見てる fedora core 1 から使ってるが バージョンによってまちまち 新しいハードだとFedoraの新しいもの好きという特性が光るな まえにオンボ(Intel)とRadeonの2つのGPU積んだマシン使ったことあったけど 何もせずにアプリ(Window)単位でのGPU切り替えをさらっとサポートしてたのは感動した Fedora自体が地雷原上等で突き進むためのものなので ソフトウェアマネージャーからインストールするとたまにインストール中から進まなくなったりするね あれはつかえない。でもまあ36から少し安定してきた。 とにかく今はdnfでインストールしてください。 >>483 OSの大型アプデのときはクリーンインストールが鉄板だと思う LinuxだけじゃなくWindowもMacも必ずそうしてるけど、おかげで大きなトラブルなくやってこれた 環境を再構築するのは面倒だけど改めてアプリを整理する機会にもなるしいいよね >>492 仰る通りなんだけど 面倒に感じるようになった 歳だな >>495 分かる 俺は以前は1こ飛ばし 今は2こ飛ばし KDE用、Gnome用ってED毎に仮想環境で準備するけど、変化が少ない時は直ぐ潰しちゃう つかFedora使うのにGnomeしか選択肢なくない? KDEってどの辺がいいの? 36 から 37 に上げたが すんなり上がったw 珍しいw >>502 ibus−anthy の立場がなくない? fedora37,firefoxで日本郵便クリックポストの支払いページヘの遷移ができず以下のエラーが出ます。。 安全な接続ができませんでした wallet-link.fep.sbps.jp への接続中にエラーが発生しました。The peer used an unsupported combination of signature and hash algorithm. エラーコード: SSL_ERROR_UNSUPPORTED_SIGNATURE_ALGORITHM pop_os+firefoxでは問題ないため、firefoxではなくfedoraの問題かなと思うのですが。。 また、bugzillaにfedora34における同様の不具合が報告されているようなのですが、 読み解くことができませんでした。 解決法をご存知の方もしいらしたら教えてください。 >>505 update-crypto-policies --set LEGACY >>506 できました!すごい。 どうもありがとうございました。 より堅牢なLinux起動プロセスを求めて ―Fedora,段階的な「Unified Kernel Image」サポートに向けてスタート https://gihyo.jp/article/2022/12/daily-linux-221222 俺はいいアイデアに見えたけどな。initrd の管理は内部的には結構複雑だし セキュアブートとUEFI必須だなこれは なくても動くけど意味はなくなる セキュアブート必須とは全く思えなかったけど 単に個々のPCで作成していたinitrdをFedoraチームがビルドしたものを使うって事でしょ そうなると柔軟性が無くなるけど、UKI自体を複数用意してユーザーが選択出来るようにするって理解した >A unified kernel image is an all-in-one efi binary containing kernel, initrd, cmdline and signature. The secure boot signature covers everything, specifically the initrd is included which is not the case when the initrd gets loaded as separate file from /boot. リンクの元ソースより initrdもセキュアブート対象になる もう一つの理由はユーザーがinitrdを生成することはカーネルパニックを起こす原因になりうるからとある UEFI関係なくそういうものでしょ。u-bootとかもセキュアブートを実現するときはinitrdを含めるよね ただここまでに言ってるのはセキュアブートが必須かどうかでinitrdがセキュアブートの保護の範囲内かとは関係ない オラオラオラオラーッ! 無駄無駄無駄無駄ーッ! 貧弱貧弱ゥ! あやつらの自由の意味は、自由に使っていいものでなくて、ライセンス的にGPLv3でみたいな縛りのある自由だから、いらんわ、って思った > Freed-ora は Fedora 環境にインストールすると非フリーの RPM がインストールされていないか確認し、GNU Linux-libre カーネルをセットアップしてデフォルトのカーネルに設定。以降は非フリーのパッケージがインストールされないよう RPM のライセンスタグを確認するとのこと。 >>514 ・DKMSが必須のマシンにはインストールできなくなる。 ・おそらく、固めたものを丸ごとEFI領域に置くことを想定しているように思うけど、サイズは大丈夫か? プリインストールマシンだと500MBかそこらしかないので、問題になる。 ところで、SwayとBudgieがSpinに追加された。 F37にしたらうちの糞古いグラボでffmpegのh264 HW デコーダが CPUデコードにフォールバックするようになって 糞古いCPUでまともに再生できなくなった vainfoにもvdpauinfoにもh264サポート出てこなくなったから Mesaから削除されたんかな してない mpvで解像度とコーデック指定でつべ見てる見てた >>526 ちょっとむずいけど コンパイルすれば使えると思う gpuドライバーとかは最初からロードされてないといけないけどdkmsでインストールするようなものは動的にロードしても大抵平気だからなんとかなるんじゃない 圧縮イメージなら容量もなんとか…というか多分新規にインストールするマシンを想定しているのでは ありがとう。去年の秋頃にあったアレのことか。 完全に他人事だったわ 流石に毎回コンパイルし直すのはアレなんでrpmfusionのに入れ替えた 15秒ルール賛成w 問題になる状況の詳細がよくわからんが… 15秒で正常にシャットダウンできないなら平常運用時の作りに問題があって、それは改善すべきだ、という認識が常識になって欲しい と思う てか理想は3秒でしょ 組み込み機器のファームにちょっと関わってた事があるが、ハードって突然電源断に対応するためにキャパシタ(コンデンサ)を持ってたりする。で、ファーム担当者はハード担当者から圧を受ける訳ですよ そんな、15秒で落とせないようなソフトの開発者は、ソフトと一緒に電源キャパシタをセットで売る事を想像しろよwwww、と思う。それよりソフトの作りを改善するほうが遥かに楽だろ、て話 反対かな。俺は記事にあるように結構な数のVMを使ってるんだよね。 これを考えると15秒は速すぎる。 これはタイムアウト、つまり最遅速度の話で上位のソフトが適切に落ちれば通常これより早くシャットダウンできる。 日頃から2分掛かります。ということではない。 シャットダウン速度を早めるにはこの方法ではなくミドルウェアやアプリケーションのシャットダウン速度を改善してほしい。 次起動したらVMやToolboxがぶっ壊れないことが保証されるなら15秒にしてもいいけど なんか怖いなあ もう少し具体的に批判してくんないかな。君らのほうがアホっぽい 常時5、6個のコンテナ常時動かしてるけど15秒だとshutdown処理完了するか微妙だわ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる