BSD/LinuxでのOffice/Desktop環境を語れ! Part03
FreeBSD(*BSD)/LinuxなどのUnix系OSで,クライアント環境を 構築するためには,Office系ソフトウェア,Desktop環境, などの整備が重要になってくるはずだ. そのための手段は問わない.またまた熱く語ってくれ. FreeBSD での Office 環境を語れ! https://pc5.5ch.net/test/read.cgi/unix/1094394684/ FreeBSD での Office 環境を語れ! その2 https://mevius.5ch.net/test/read.cgi/unix/1107211157/ >>100 肝心なことを書き忘れていました。 FreeBSDのX上のGUIなソフトウェアから、プリンタで正常に日本語が 印刷できる状態であれば、Wineで稼働するWindowsソフトウェアから 日本語の横書印刷は、できます。 Wine1.7.11+OpenOfficePortable3.2.0 で、縦書表示、縦書印刷を していましたが、一瞬の輝きだったようで、今では、横書印刷しか できません。 めったに縦書印刷をしないから……、 別にいいですけど!(田中みな実さんぽくむくれた表情)。 Wineで縦書がなかった時代から、縦書表示、縦書印刷ができていた CassavaEditorなら、今でも縦書印刷ができるかもしれません。 FreeBSD での Office 環境を語れ! その2@UNIX https://mevius.5ch.net/test/read.cgi/unix/1107211157/863 https://mevius.5ch.net/test/read.cgi/unix/1107211157/858-n 【指令】お前らの年賀状作成ソフトを報告せよ!@UNIX https://mevius.5ch.net/test/read.cgi/unix/1008926166/228-n ※↑スレのレス245の https://github.com/Torisugari/printha には、期待していたのですが、使ったよ、って記事がないですね。 ※レス228は、執筆者君です。以下のサイトを参照していました。 Linux+Wine+CassavaEditorではがきに宛名印刷する印刷設定の一例 - ぜんざいの耐えがたき甘さ https://sound.jp/zenzai/other/wine-cassava-setting.html GNOME42悪くない 少なくとも近年のFreeBSDのGNOMEらしからぬ仕上がり どうせ誰も使わんのだろうが >>103 追っかけている方はおられるんじゃないですか。 「かけまわる子犬。」氏はKDEを追っかけているし。 FreeBSDのKDEはdiscoverでpkgが扱える様になれば言う事無し 割り込んですいません。自己レスですが。 >>67-71 imm32.dll.soとimm32.dllの件 >>99 >今のWOW64なWineの仕組みだと、FreeBSD/amd64インストール時に >「lib32」を入れておかなくてもよいということです。 以上のレスは、以下のLinux板のWineスレで、理解が深まります。 i386-wineの統合のタイミングは、まさに今だった、 ということかもしれません。 今夜も Wine で乾杯! - 23本目@Linux https://mao.5ch.net/test/read.cgi/linux/1585198566/671-n FreeBSDを語れスレのテンプレで興味を持って来ました このスレは主にFreeBSDでwimeを使っている君と言う方が盛り上げている感じなんですね FreeBSDではどのデスクトップ環境がおすすめですか?推している方がいるようにKDEですか? ん? 語れスレのテンプレ?(ケンモメンぽく) えっ!やだっ!(田中みな実さんっぽく) けっこう活発なラズパイスレと一緒に関連スレになってる! 盛り上げると言うか、 「高スキルユーザさーん! 興味を持ってくださーい!」とか 「FreeBSDのWineで何かあれば、さがわ@sagawa_aki氏にも届け!」という 感じで報告しているだけで。 Linux板にはWineスレがあるんだけれど、FreeBSD特有のWineの話は、 Linuxには関係ないし、「FreeBSD限定のWineスレ」ってほどの 話題もないしね。 「おすすめのデスクトップ環境」って、Linux板文化っぽいね。 Linuxでも有名で、FreeBSDでも、FreshPortsでコミット回数が 多くて、よく使われている感じの、しかも、FreeBSD特有の問題が あれば、回避策が見つかりやすいやつ、で、いいんじゃないかな。 PCでのUnixは、Linuxが当然の前提、って感じなので、 FreeBSDだと……、という事が起こりやすいしね。 例のところを見ると、 「みなさん、普通にリッチなデスクトップ環境を使っているのね」 と思います。 触れないほうがいいかもしれないけれど(注)、リンクを書いておこう。 FreeBSD研究部 https://ja-jp.facebook.com/groups/freebsd.labo.japan/ (注) いいかげんPC-98は捨てろ@UNIX https://mevius.5ch.net/test/read.cgi/unix/1036951410/642-n >>109 > FreeBSD特有のWine 5chブラウザの動作報告などして下さると面白いかも知れないですね 5chなので Windowsの専ブラの動作報告などダサイでしょうから気が向いたらと言う事で 「wimeまとめ」の >>13 の「canna.el」への補足です。 執筆者は、「yc.el」を、現在まで使い続けてきました。 そのため、 >>13 での「canna.el」への言及が、中途半端で甘かった のですが、最近、「Yuuji」氏(注)による、EmacsへのCannaパッチを 知りました。 これが、FreeBSDの、pkg(8)の、flavor(Portsならmake option)の 「emacs-canna」の「もと」なのですね。 emacs23から数えて、13年ほど、まったく気づいていなかった、という 自身の検索の甘さをお詫びします。まことに申し訳ありませんでした。 (注)Twitterを見ると「ものずんごい有名人ではなかろうか」と 思いますが、まったく存じ上げませんでした。 FreeBSD13.0R/amd64で、 Wine(i386-wine-devel-6.12)+wime4.1.4+ATOK17(2004)+emacs-canna-27.2 を、使ってみましたが、 「やだっ! Mule時代みたい! 勘違いしないでね、ほめてるのよ!」 「yc.elでは、変換候補が一斉に出て、Emacsのエコーエリアが 数行ほどになるのに違和感があったのよね!」 と、誰だか分からない物まねをしながらウハウハです。 yc.elより、emacs-cannaのほうが軽いような気もします。 FreeBSDを使っていて良かったなあ、と、思いました。 https://twitter.com/hiroseyuuji/status/1511329334107140101 https://twitter.com/5chan_nel (5ch newer account) >>112 13-stableでpkgのwine6を使ってjanestyle4は動いた。この書き込みはそこから。 >>116 確かに動いた あっさりと https://i.imgur.com/uWiXdbE.jpg それも i386-wine-devel で使ってたやつがそのまんま wime氏、116氏、ありがとう そのうち私も何らかの成果があればご報告差し上げます >>117 自分のレス番間違えてしまった とにかく感謝してます wineは使わないけどV2Cだって13-stableで動くよ。 自分はV2C-Rを使ってて最近V2C/2に移行した。 そうそれ。 JAILで古いportsをビルドしてパッケージだけメイン環境に突っ込んだ。 スクリプトエンジンが変わってて動かんから古いエンジンを突っ込む必要があったり ちょっと手間だったけどV2C/2が快適に動いててこの書き込みしてる。 >>74 これをベースにした合成フォントがportsに来たみたいですよ FreshPorts -- japanese/font-udev-gothic: UDEV Gothic https://www.freshports.org/japanese/font-udev-gothic/ >>122 おおっ! Portsに来たぁぁ! 2つあるのか。明朝はないのね。 ん? 「Nerd Fonts」。「オタク文字」? って何だ? FreshPorts -- japanese/font-udev-gothic: UDEV Gothic https://www.freshports.org/japanese/font-udev-gothic/ FreshPorts -- japanese/font-udev-gothic-nf: UDEV Gothic (Nerd Fonts) https://www.freshports.org/japanese/font-udev-gothic-nf/ >>123 上流リポジトリ https://github.com/yuru7/udev-gothic HackGenの作者さんの様でテキストエディタや端末エミュレータ用の等幅フォントですね ナードフォントというやつは絵文字グリフが充実したフォントらしいです >>124 わざわざレスすいません。 モリサワの「BIZ UD」フォントからのPorts化なのでなく、 「yuru7」氏の二次的成果物(BIZ UD+JetBrains Mono)からの Ports化なんですね。 >>125 と、言われても……、なあ。 連日の長レスの後の短レスの投稿数の多さが恐いと思います。 Windowsは、「データを持って行って」ぐらいでしか 使ったことがないので、理解できませんでした。 今でこそ、Windowsが対応しておかないといけないキーボードは、 日本語か、英語か、ぐらいの選択ですが、昔は、Windowsが対応して おくべきキーボードがたくさんありました。 101/104英語、106/109日本語、PC9801系、AX、J3100(ATコネクタ)、 FM-TOWNS、親指シフト(最近まで現役だったみたい)、かなあ。 Controlキーが、左にしかない場合もあるし、Windowsさんには歴史が あるんだから、ぐちゃぐちゃとは言えないよね。 大昔(MS-DOS時代の話かもしれない)に読んだ、ATOKのバグ出し チーム(だったかな?)の記事。 バグ出しチームは、標準のキー割り当てで変換し(当たり前ですが)、 しかも、変換結果の漢字が何番目に出るかも記憶しているため、 即、変換結果を選ぶことができ、漢字変換が正確で速いのは良いが、 学習機能を使わない状態(無意識に学習機能を使わないようにしていた) だったため、学習機能の向上の役に立たない、ということに気づいた、 という話。 >>113 の件について追加。 FreeBSD13.0R/amd64+Wine(i386-wine-devel-6.12)+ wime4.1.4+ATOK17(2004)+emacs-canna-27.2 の 環境下において。 emacs-canna標準の、canna.el使用時の、漢字変換時に、 ごくまれに、WindowsなATOKの変換候補のGUI表示がされる。 もちろん、そのGUI表示で変換候補を選ぶことはできず、 単に描画されるだけです。 この描画は勝手に消えてくれないので、ATOKのプロパティを 表示(wimectrl -s)させて、プロパティをキャンセルすると、 ATOKのプロパティの描画と一緒に消えてくれます。 ただ、「たまになる」だけで確実に再現させることができません。 「標準のEmacs+yc.el」の時も、ごくごくまれになっていたと 記憶するのですが、条件を思い出せません。 実害はないのですが、一応、そういう現象がある、という事で。 それと、繰り返しになりますが、「標準のEmacs+yc.el」より 「emacs-canna」の方が、軽いように感じます。 「Emacs LispでCanna」と、バイナリで対応の「emacs-canna」なら、 当然かもしれません。 もう「標準のEmacs+yc.el」には戻れません。 >>127 もしご本人が読んだらどんな反応があるか目に浮かぶ様なご回答ですな >>130 恐いのは恐いんですが、悪口ではないんですよ。 ただ、キー割り当てやソフトウェアの挙動には、人間側として 不満があったとしても、よかれと思って考えられた設計思想や、 俗に語られる、タイプライターの配列の話などの、 いまさら変えられない歴史があるし、あえて、人間側が標準状態に 合わせるのも考え方として「ある」という話です。 ATOKのバグ出しチームの話も、「へえ、変換学習をさせなければ 変換先の順番が変わらないのだから、変換作業が速くなるね」と 感心したので、憶えていたのだと思います。 ATOKのスレで、ATOKの新規インストールをしたので、 「これから(自分流の入力をして)辞書を鍛える」というレスが 並んでいた中に、「短文でなく、長文で変換をしたら、文脈に 応じた変換結果になりやすいのに」というレスを見てからは、 執筆者も、文脈を読み取りやすい長さのタイミングで 変換するようになりました。そのレスには感謝しています。 そのスレで言及があった「窓使いの憂鬱」は知っていましたが、 共同使用のPCには入れられないし(共同使用相手がUnix系とは 限らない)、「窓使いの憂鬱」を入れられる環境なら、 Emacsな人なら、xyzzyを入れて「メモ帳」代わりに使っても よいだろうし、Windowsのダイアログ入力のコピペなどの すべてまでも、を、Unixっぽくするのも、どうなのか、 Windowsにおいて、「絶対にマウスを使たくないでござる」は、 難しいだろうな、人間には慣れる能力もあるのに、と、 思ったことがあります。 『UNIXという考え方−その設計思想と哲学』を読んで、 マウス操作もアリ(操作は、なるべく楽をしろ)なのだな、と、 考えを改めた執筆者君でしたー(きょうのわんこ風)。 ありきたりな環境で人並みに過ごすのか、楽をする為に人並み外れた途方も無い時間と労力を費やすのか まさに人それぞれと言う話でござるな まあどっちかというとWindowsならマウス無しのオペレーションも無くはないんだけどね。 > BSD/LinuxでのOffice/Desktop環境を語れ! Part03 GhostBSDのデザイン割と好きなんですが OpenRCに馴染めないのでパーツだけ拝借してそれっぽくしてみました https://i.imgur.com/HmjeR0v.jpg みなさん、フツーにリッチなデスクトップ環境を使っているのね。 計算機資源は、makeやコンパイルに振り向けるべきだよ、 それなら自作PCも安価で済むしね、という貧乏性な執筆者です。 大昔、初めてWindow Managerの仮想デスクトップを使った時は、 「わー、すげー」とか言って、いくつかの窓を仮想デスクトップへ 移動させたが、存在を忘れてシャットダウン。 仮想デスクトップマネージャみたいなものがあっても、 「見えていない物は忘れてしまう」という事に気づいて、 そもそも、仮想デスクトップは使わなくなった。 XのWindow Managerは、ソフトウェアを位置指定(-geometry)して 起動ができるので、「わー、すげー」とか言って、 「Emacsはこの位置で」などと、設定に夢中になったが、 同じソフトウェアを複数起動すると、ピッタリと同じ位置に 起動するので、先に起動していたのを忘れてしまう、という事で、 位置指定もやめた。ダメダメじゃん。 といっても、タイル型のWindow Managerへ行くほどでもないです。 > ※執筆者はC言語もMakefileも理解していない >>140 あははー。 執筆者のスキルを明示するためにサラッと書いたんですが。 前スレにwimeネタを初めて書いた時点で書きましたが、 執筆者は、C言語も、Makefileも、理解していません。 いちおう、見るには見ますが、修正する能力はありません。 ケアレスミス程度なら修正しますが。 さらに言えば、シェルスクリプトも、こみいったものだと、 追いきれず、途中で迷子になります。 wimeや、Wineに対して、*BSD業界の高スキルユーザさんに 興味を持ってほしい、というのは、それが理由なんです。 「FreeBSDでは、動かないんですが」 「さあ? Linuxでは普通に動いてるし」 「え゛え゛!」 って、ありそうでしょ。 執筆者しか、FreeBSDで、Wineが、ないと困るほどの状態で 常用しているユーザはいないのではないか、と思っていましたが、 FreeBSDでWineな方がおられました。 みなさん、WineのFreeBSDでの特有の知見を共有するためにも、 Wineをドンドン使いましょう【PR】。w (URLの後は引用です) https://twitter.com/stackfield_jpn/status/1528331070152019969 stackfield@stackfield_jpn FreeBSDでCarrara 8.5 64bitが動いたな。 wine 6.0な。wine-devel(7.4.1)だと動かんのだがおもしろい話。 8:04 PM · May 22, 2022·Twitter Web App https://twitter.com/5chan_nel (5ch newer account) FreeBSDの使い手でケンモメンねえ まさかとは思うが可能性はゼロじゃねえ vncやxrdpで入ろうとするとconsolekit-daemonがエラー吐きながら1分から2分くらい待たせやがるんだが何事かわかる? 例えばこんなの console-kit-daemon[7641]: WARNING: Error waiting for native console 9 activation: Inappropriate ioctl for device > なぜその吐いたエラーを貼らんのか? 寝起きで思い出した様に書いたから あとconsole-kit-daemonじゃないけど気になったのはこれ xrdp-sesman[1599]: [ERROR] sesman_data_in: scp_process_msg failed xrdp-sesman[1599]: [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans dbus-daemon[1440]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': timed out (service_start_timeout=25000ms) dbusが吐いたタイムアウトエラーの後に一応繋がりはするんだけどさ 結局手直しは諦め新規インストール用データセットへinstallworld、設定複製、 chrootして各種パッケージ入れて再起動し一応解決 リフレッシュ出来たと思う事にしました デスクトップ環境にリモートアクセスし操作する為のプログラム そんなこと言い出したらwineの話もアウツでは amd64、i386共に wine-devel-7.8 6.0では起動しなかったbecky2が起動 https://i.imgur.com/4lfNo2n.jpg 互換性が良くなってきている模様 winnyとかFLMASKはwineで動くのかな? 当時?はFLMASKのためだけに、vmwareを入れたりしてたけど FreeBSDのMATEに、 ・mate-desktop/mate-netbook https://github.com/mate-desktop/mate-netbook ・ubuntu-mate/mate-window-applets: Window applets for MATE Desktop https://github.com/ubuntu-mate/mate-window-applets ・ghostbsd/station-tweak: This is Station Tweak, a fork of MATE Tweak. https://github.com/ghostbsd/station-tweak この辺を野良ビルドで入れるのオススメ これのことか GitHubの利用をやめるようオープンソースソフトウェア非営利団体が強く呼びかけ - GIGAZINE https://gigazine.net/news/20220704-software-freedom-conservancy-give-up-github/ ギガジンを鵜呑みにしてしまう人っているのか Software Freedom Conservancyがどんな団体なのか の方がgigazine云々より重要じゃないか? >>143 今、気づきましたが、ハンドル名をコピペミスしている……。 「ERROR: 余所でやってください。[unix]」エラーのため、 書き込みをリトライしていたからだと思います。 >>156 https://www.winehq.org/search?q=atok 上記URLのWineHQ公式のデータベースでは、 2017/07/21にReleasedされたWine2.13で、ATOK2017が、Garbage評価、 という報告が出てきます。 この年度時点で、すでにwimeは熟成した存在で、執筆者君が、FreeBSDで wimeを試した初めてのレスが、前スレに書かれています。 この時点で、wimeに対するLinux業界での喜びの声は、沈静化しており、 執筆者の、Linux板のWineスレへのレスに対しても、「懐かしい」感の あるレスがありました。 たしかに「素」のWineでは、ATOKは動きませんが、 Wine+wime+ATOKで、CannaServerに見える形で動くので 周回遅れでのデータベース登録となっているのも事実です。 ※ATOK2017がwimeで動作するという報告は見あたりませんが。 日本語利用者がこのデータベースを参考にする可能性は、 比較的に低いと思われますが、誤解を生む登録だなあ、 と思います。 日本語を常用利用していない方が登録したのかなあ。 すでに、ずいぶん前から使っている方からすれば、いまさらでしょうが、 Emacs28.1で、文書中の全角空白(2byte空白)が赤のアンダーバーで 表示されるようになりました。 まあ、昔から設定によって全角空白などを表示させることはできましたが、 四角い形状で表示されたりして、執筆者的にはイマイチ感があり、 アンダーバー表示の控えめ感は、ありがたいと感じています。 ただ、Emacsのエコー領域に表示されるCannaの変換候補でも表示されます。 ※emacs-cannaで、canna.elを使用。 不思議なことに、全角漢字の候補のうしろにも表示されています。 漢字は全角なので、まあ、おかしくはないけれど、意味がない、と 思うのですが……、ああーっ!分かったー! 変換候補の一単語ごとの区切りの空白に全角空白を使用しているので、 それに反応して赤のアンダーバーが表示されているんだ! (ヽ´ん`) それぼく ごぶさたしております。 ニュー速(嫌儲)のキャラクターがカワイイので、つい見に行って しまう執筆者君です。 FreeBSD13.1R/amd64を新規インストールしました。 さて、執筆者がアテにしているソフトウェアはWineとwimeです。 WOW64となった現在のFreeBSDのWineでは、 32bit環境の展開で「versions do not match!」>>98 となったり、 wimeのwimectrlで「"libX11.so.6" not found」>>95 >>99 となったりの 過去がありますので、今のところ、FreeBSD13.0R/amd64の 「/var/cache/pkg/」からコピーして保存しておいた 「i386-wine-devel-6.12,1.pkg」を、FreeBSD13.1R/amd64に 「pkg add」で入れて使っていますが、普通に入って、普通に、 i386-wine-devel-6.12が使えています。 wimeのために、FreeBSD13.0R/i386でmakeした「imm32.dll.so」を 「/usr/local/lib32/wine/i386-unix/imm32.dll.so」に置いて wime(FreeBSD13.0R/i386でコンパイルしたもの)が稼働しています。 もちろん、Wineが6系なので、(他のdotファイルでもよいが).cshrcに 「setenv WINEDLLPATH /usr/local/lib32/wine」を設定しています。 こんなこともあろうかと、FreeBSD13.1R/amd64のインストール時の 「Distribution Select」で「lib32」を入れておきました。 FreeBSDのPortsのWineは、公式やLinuxと同じタイミングで、VersionUp する時もあれば、少し対応が遅く、ほぼ固定状態みたいな時があります。 i386-wineの時みたいな感じですが、まあ、ボランティアなので文句は 言えませんね。 余裕ができたらWOW64なWineを試してみます。 FreeBSD13.1R/amd64でのVirtualBOXの話です。 現在のPortsでもpkg(8)の「quarterly」でも、VirtualBOXのVersionは 6.1.36です。 pkg(8)でVirtualBOX6.1.36を入れ、FreeBSD13.1R/amd64をブートすると カーネルメッセージで、 KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type と言われます。 Solved - Virtualbox kernel module fails to load on FreeBSD 13.1-RELEASE | The FreeBSD Forums https://forums.freebsd.org/threads/virtualbox-kernel-module-fails-to-load-on-freebsd-13-1-release.85191/ 上記URLによると、2022/05/17時点の質問ですが、同じ状況が報告されて いました。FreeBSD13.0でpkgがビルドされたことが原因のようです。 Forumで話題になっているのは6.1.34の頃の話のようですが、 6.1.36の今現在も同様のエラーが執筆者の環境では出ました。 ところが、上記Forumのfyamamoto氏の書き込み通りの手順で問題は 解決されました。 こんなこともあろうかと、FreeBSD13.1R/amd64のインストール時の 「Distribution Select」で「src」を入れておきました。 〔次に続く〕 〔前からの続き〕 fyamamoto氏の手法は、あらかじめpkgで「virtualbox-ose-kmod」を インストールしておき、Portsから「virtualbox-ose-kmod」をmakeし、 カーネルモジュールだけをコピーするという手法で、正直なところ、 「make reinstall」でもいいような、とも思いますが、多少なりとも 時間や、計算機資源などが節約できるという利点があります。 執筆者は「基本的に、pkgでインストールし、一部のファイルだけを、 Portsでコンパイルされたバイナリで差し替えるため、workの下から コピーで持ってくる」という、いかにも情弱っぽい手抜き手法を Wineとwimeのために、とっていましたが、まさか、同じ手法を取る方が おられるとは思いませんでした。本当に驚きました。 fyamamoto氏の後の、mss_cyclist氏の書き込みで、 >I am not sure if this is necessary? >Code: >kldxref /boot/modules とありますが、「kldxref /boot/modules」しておかないと、 warning: KLD '/boot/modules/vboxnetflt.ko' is newer than the linker.hints file warning: KLD '/boot/modules/vboxnetadp.ko' is newer than the linker.hints file とのメッセージが出ます。 執筆者は、FreeBSD13.0R/amd64で、Athlon5350のRadeonR3を amdgpuで使っていましたが、FreeBSD13.1R/amd64では使えませんでした。 詳細としては、 カーネルメッセージの、rc.confの評価あたりで、画面出力がなくなる。 モニターの電源ランプは、画面出力が「ある」状態だが、 実際の画面出力は「ない」。 たんに、「画面出力がないだけなのか」と、かなり時間を置いて 画面出力に頼らずにログイン作業をしてみたが、ログインできないので、 リセットボタンでリブートするしかない。 やってみたこと。 ・「gpu-firmware-amd-kmod-banks」を入れてみた。 結果:状況変わらず。 ・「loader.conf」に「hw.amdgpu.exp_hw_support=1」を追記。 出典:https://running-dog.net/2021/04/post_2429.html 結果:状況変わらず。 〔次に続く〕 〔前からの続き〕 PCIeスロットに、RadeonHD4350(RV710)なビデオカードをさして radeon_drv.soを試してみましたが、 Fetal Server error : no screens found で、Xサーバが起動せず。 しかたがないので、GeForceGT730なビデオカードにさし直し、 pkg(8)から入れた「nvidia-driver-340」で使っています。 NvidiaDriverだと、「/boot/loader.conf」に「nvidia_load="YES"」と 「/etc/X11/xorg.conf」に「Driver "nvidia"」だけで使えるので ラクチンだなあ、と思います。 amdgpuが使えない、という最後の心当たりは、 AHCIブート(BIOSブート)で、FreeBSD13.1R/amd64をインストール しており、「UEFIboot」にしていなかったからかなあ? 、ぐらいです。 こんな風に変わっているよ、という助言などがあれば、 よろしくお願いします。 じゃ、お夜食、食べてきます。 xf86-video-ati/Makefile, xf86-video-amdgpu/Makefile に ONLY_FOR_ARCHS_REASON= KMS is required and currently only available on x86/arm64/powerpc64 なんて書いてあるし xf86-video-amdgpu/pkg-descr に On FreeBSD requires amdgpu KMS driver from graphics/drm-kmod. とあるけど graphics/drm-fbsd13-kmod はインストールしていたのか あと 13.0 から 13.1 にアップグレードしたのなら -kmod は ports で make し直す必要があるかと あわわ。即レス驚きました。ありがとうございます。 >>167 では、前提条件を書くのをコロリと忘れていました。 ○FreeBSD13.1R/amd64はクリーンインストール。 ○amdgpuを使うためにpkg(8)から入れた物は以下。 ・xf86-video-amdgpu-22.0.0 ・drm-fbsd13-kmod-5.4.191.g20220604_1 ・gpu-firmware-amd-kmod-banks-20220511 ○以下の設定をした。 ・rc.confに「kld_list="amdgpu.ko"」 ・xorg.confに「Driver "modesetting"」 ・「#pw groupmod video -m <ユーザ名>」 「drm-fbsd13-kmod」の代わりに「drm-kmod」「drm-54-kmod」も 試しましたが状況は変わりませんでした。 そもそもこれだけ熱心にレポート書いてる人が あんなしょうもない釣りやるとも思えんよね ここの嫌儲民はどちらかと言えばあの >>171 > ・xorg.confに「Driver "modesetting"」 modesetting じゃなくて "amdgpu" ではどうなるの? >>171 まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる >>165 のリンク先にも書いてある > カーネルメッセージの、rc.confの評価あたりで、画面出力がなくなる。 -kmod は pkg じゃなく ports からインストールするように ん? 何か嫌疑が、かかってます? 古くさい釣りAAが貼られていたのも、それがらみですか? 世の中、ヒマ人が多いんですね。 嫌儲板には書いたことはありません。閲覧のみです。 そんなことよりも、wimeを、以下略。 執筆者は、UNIX板では「FreeBSDでwimeを使っている君」で 書き込みをしています。※他の板では書いていません。 仮に、初歩的な質問をする場合で、通りすがりのフリを したくても、即バレてしまう文体なので、恥を忍んで固定名に するつもりです。 Linux板に書く場合も、これからは同様にするつもりです。 それもこれも、すべてwimeの宣伝のためです。 なぜ宣伝するかというと、wimeを、以下略。 さらに書き忘れていた。 執筆者がATIというかAMD系のビデオカードを選好するのは、 コンソールの文字が、クッキリ! ハッキリ! 白が明るい! という、高度成長時代のテレビのCMみたいな好みがあるから、 というのもあるのですが、nvidia-driver使用時の、i386-wineでは、 pkg install後に、「patch-nvidia.sh」を走らせる必要があるから、 というものでした。 まあ、手順が増えると何かのトラブルに合う確率が上がるだろうから、 できれば避けたい、という、実につまらない理由です。 で、i386-wineで「patch-nvidia.sh」を走らせてみると、 nvidia.comから現在自分のPCで稼働している、 pkg(8)のnvidia-driver-340-340.108に対応した、 NVIDIA-FreeBSD-x86-340.108.tar.gzをダウンロードして 以下のように展開する、というものでした。 ※もちろん、最初に走らせるだけでユーザ側での操作はありません。 [前の部分は略] => Extracting NVIDIA-FreeBSD-x86-340.108.tar.gz to /usr/local/lib32... x libnvidia-tls.so.1 x libGL.so.1 x libnvidia-glcore.so.1 => Cleaning up... ===> i386-wine-6.12,1 successfully patched for nvidia-driver-340.108_3 [終了] ファイルの差し替え処理のようです。 日本語入力メソッド総合スレッド@Linux@5ch掲示板 https://mao.5ch.net/test/read.cgi/linux/1472658083/139-140 上記のレスのおかげでwime 4.1.5がリリースされているのを知りました。 新規リリースに気づいていませんでした。ありがとうございました。 上記URLでは「ATOK17」とありますが、ATOK17は、2004年度版となります。 >ATOK17にあわせてATOK28W.IMEからATOK30W.IMEに変更したところ とのレスが正しいとすると、2015年度版(ATOK28)に対する処理を 読み替えて変更した、ということですから、もともとの「ATOK17」表記は、 おそらく「ATOK30」が正しいと推測されるので、ATOK2017での動作報告 かと思われます。 いずれまとめて手順の書き換えをする時用にメモしておこう。 >>15 に上記Linux板のURLを追加のこと、と。 >>174 >まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる そういうものとは、まったく知りませんでした。 今までカーネルモジュールを使うソフトウェアは、あまり使っておらず、 意識していませんでした。 >>>165 のリンク先にも書いてある まことにすいませんでした。 英語なもので、さらっと読み飛ばして、ポイントっぽいところだけを 読んでいました。 >>173 CUIのコンソールの出力がなくなり、CUIのloginまでいけない状態なので、 xorg.confの評価までは、いけていないのです。 drm-fbsd13-kmodをpkg(8)から入れず、Portsから入れてみる。 ○FreeBSD13.1R/amd64はクリーンインストール。 ○amdgpuを使うために入れたもの ・pkg(8):xf86-video-amdgpu-22.0.0 ・ports :drm-fbsd13-kmod-5.4.191.g20220604_1 ※pkg(8)と同じバージョン ・pkg(8):gpu-firmware-amd-kmod-banks-20220511 ・pkg(8):mesa-dri-21.3.8 ※注 ・pkg(8):mesa-libs-21.3.8 ※注 注 https://running-dog.net/2021/04/post_2429.html に 書いてあったのだが、すでに入っていた。 ○以下の設定をした。 ・rc.confに「kld_list="amdgpu.ko"」 ・xorg.confに「Driver "modesetting"」 ・「#pw groupmod video -m <ユーザ名>」 pkg(8)の「drm-fbsd13-kmod-5.4.191.g20220604_1」を、removeし、 portsから「drm-fbsd13-kmod-5.4.191.g20220604_1」を 入れましたが、以下のように状況は変わらずでした。 カーネルメッセージの、rc.confの評価あたりで、画面出力が なくなる。 モニターの電源ランプは、画面出力が「ある」状態だが、 実際の画面出力は「ない」。 で、リセットボタン。 まさか、「1分くらい待つと画面出力が始まる」とかじゃないで しょうね。 いえね、i386を使っていた頃は、VGA表示から精細な表示に 切り替わるのに10秒くらいかかっていたので。 うろ覚えだがgpu firmwareみたいな名前のpkgもportsで作り直しが必要だったような。 WoW64連呼してるのも本当なのかと疑問に思ってる wine/Makefile に # Wine assumes a WoW64 package is available, which is not the case on # FreeBSD yet. と書いてあるから 64bitと32bitを統合したWoW64じゃなくて64bitと32bitを同時に使えるようにした だけなんじゃないかと思うんだが違うんだろうか WoW64には64bit Wine側の対応が必要で64bitだけのWineとは違うはずだから Athlon Athlon5350なのにgpu-firmware-amd-kmod をインストールしているのが間違い 必要なのはgpu-firmware-radeon-kmodの方 分からないのならMeta ports の gpu-firmware-kmod あと -kmod なのだから pkg ではなく ports から試すように(特にトラブってる時には) amdなんて使ってないけどwikipedia見て調べてみた 180 書いたの俺だけどこれは関係無かったか wine 等とまるで関係ないんだがCinnamonが割とまともにつかえる 足りないと思ったものは適宜追加しながらお好きな人はどうぞ ただし画面ロックとシステム情報おまえらはまだダメか ヤらねばヤられる >>175 すいません。 Linux板のWineスレで、すでに「FreeBSDでwimeを使っている君」で 書いていました。 https://mao.5ch.net/test/read.cgi/linux/1585198566/449 >>186 Wineのスレではないので、良さげっぽかったり、便利っぽかったり、な 情報は書いてください。 スレタイは「Office/Desktop環境」となっていますが、 Unix系OSでOfficeソフトを使うような日常生活環境を構築するための 情報交換をしたい、人柱報告(>>4 など)も読みたい、というのが スレの趣旨です。 Desktop環境にしても、LinuxのDistributionにしても、構築する個人や、 コミュニティの好みで構築されているので、長短がありますから。 >>180 >>185 それ、サーバなマザーボードでの構成でしょ。 おそらく、後載せのRadeonR7は、「ダミーが刺さって」とのことから、 ビデオ出力に使わずに、演算に使っているのではないか、と感じました。 執筆者君の環境の場合、VGAを複数認識するような高価な環境ではなく、 ビデオカードをさすと、APU側のビデオ機能は無効になるマザーボードが ある、という、ローエンド環境に、ありがちな環境です。 もちろん、この試行中でも、いちいちビデオカードを外しながら 試していました。 おかげで、アルミ筐体の拡張スロットのネジがゆるくなってきました。 >>183 >64bitと32bitを同時に使えるようにしただけなんじゃ たぶん、そうだと思います。 >>38 >>67 あたりに書きました。 FreeBSDのWOW64なWineとはいっても、FreeBSD/amd64の場合、 そのままでは、64bitなWindowsソフトウェアしか使えません。 32bitなWindowsソフトウェアを使いたい場合は >>69 に 書いたように、シェルスクリプトを走らせて、 ユーザのホームディレクトリの下に 32bitなWine(バイナリ提供の様子)を展開しないと いけませんから。 以下のURLは参考まで。 http://hayabusa6.2ch.net/test/read.cgi/linux/1455088008/51-n https://mao.5ch.net/test/read.cgi/linux/1585198566/442-n https://mao.5ch.net/test/read.cgi/linux/1585198566/679-n なんだか、入門者の犬小屋スレみたいになっていますが、 みなさん、ありがとうございます。 amdgpu、以下の環境で動きました。 >>181 >>184 の通りです。 本当にありがとうございました。 すべては執筆者の、KernelModuleへの理解が足りなかったのが 原因でした。 ・pkg(8):xf86-video-amdgpu-22.0.0 ・ports :drm-fbsd13-kmod-5.4.191.g20220604_1 ・ports :gpu-firmware-kmod(MetaPort) *rc.confに「kld_list="amdgpu.ko"」 *xorg.confに「Driver "amdgpu"」 ※「modesetting」でも動いた。 CUIのコンソール(カーネルメッセージ)の出力が VGAから精細になり、 「やだっ!amdgpu.koとamdgpu_kabini*.koなどのKernelModuleが 正常に読み込まれたんだわっ!」と、誰だか分からない物まねを しました。 やはり、pkg(8)のKernelModuleが、13.0環境で作成されていたのが 問題だったのだと思います。 これなら、RadeonHD4350(RV710)なビデオカードも動くと思います。 ※試していませんが。 入れてて良かった「Distribution Select」で「src」、 「ports」もね! (田中みな実さんぽくキリッとキメ顔) >>189 Linuxの場合と同様64/32bit使用可な環境作って32bitアプリインスコすると ~/.wine/drive_c/Program Files (x86) ディレクトリが出来るのでどうなんでしょうねえ (emulators/i386-wine(含-devel)の頃には起こらなかった挙動) >>182 >>192 執筆者が「その程度のレベル」なのは、 前スレ当時から自己紹介しております。キリッ。 自分でKernelをReConfigureした場合、Ports由来のKernelModuleを 再makeしないといけない、というのは知っていましたが、 「まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる」、 というのは知りませんでしたし、さらに、標準のKernelで「.1」の差が 問題になる、というのも認識していませんでした。 この後に「その程度のレベル」な、謝罪のレスがあります。 >>191 執筆者の試行では、32bit環境の.wineのまま(新規生成していない)で、 WOW64なWineで32bitなソフトウェアが動きました。 WOW64のWineでwinebootで.wineを新規生成すると、「Program Files (x86)」が できていました。 まずは、おわびです(ガバッ、土下座)。 お散歩がてら「さがわ@sagawa_aki」氏のTwitterを見ていると 以下のようなTweetがReTweetされていました。 https://twitter.com/scp1979/status/1547002783227817985 >晋太郎@scp1979 >FreeBSD13.1でWineを起動したら「wine: could not load http://ntdll.so: (null)」と出て起動しなかった。 >ググても解決方法が見つからなかった... >pkg info -D wine を確認したところ、procファイルシステムが必要と書いてあったのでmountしたら起動した。 >#FreeBSD #Wine #備忘録 >8:39 AM ・ Jul 13, 2022・Twitter Web App 執筆者は青ざめました。 「wine: could not load http://ntdll.so: (null)」で このTweetより先に、大騒ぎした張本人だからです。 ※大騒ぎの初出は、以下のURL、2020/12/11(金)。 https://mevius.5ch.net/test/read.cgi/unix/1107211157/919-921 https://mevius.5ch.net/test/read.cgi/unix/1107211157/951 https://mevius.5ch.net/test/read.cgi/unix/1107211157/952-953 https://mao.5ch.net/test/read.cgi/linux/1585198566/449 https://twitter.com/5chan_nel (5ch newer account) で、前スレ951氏助言の 「setenv WINEDLLPATH /usr/local/lib32/wine」との設定をコメントし、 /etc/fstabに「proc /proc procfs rw 0 0」と、設定をして、 winecfgを起動すると、普通にwinecfgが起動しました。 執筆者が、procをマウントしていれば、騒ぐ必要がなかったミスとなります。 前スレの951氏にはWineのソースを調べ、助言レスをさせる、という手間を かけさせて、まことに申し訳ありませんでした。 Linux板のWineスレでも質問をして、申し訳ありませんでした 執筆者の不注意なミスにより、心配した方々に迷惑をかけて、 本当に申し訳ありませんでした。 あれれ? >>195 のWineのエラーメッセージ引用のかぎカッコ中に 「 h t t p : / / 」とありますが、執筆者は書いておりません。 投稿時に自動的についたものと思われます。 >>196 インストールのメッセージくらい読めというところだが 貴方が前スレの992に貼ったFreeBSD Forumsでも そのエラーの回避法としてprocのことが書いてある >>195 当時のリンク先のサイトのレスが書き込まれた日付をよーく見ると良いよ。 ついでにそれがportsに反映された時期も。 四ヶ月後に再度見に行くか?ったらまあしないだろうし そもそも当時の作業者が初耳!してるくらいだから。 あとprocマウントしてても多分そのエラーは当時は出てたと思う。 なんでかっつーと自分のマシンは最初からfdescfsとprocfsはmount済みなんで。 >>198-200 ○「wine: could not load ntdll . so : (null)」と出る件 ※5chに書き込んだ時点でゴミがつくので1byte空白をはさみました 前スレ919(2020/12/11)の執筆者のレス時点では、 https://forums.freebsd.org/threads/i-cant-run-windows-applications-with-wine-64bit.77253/ の、forumsが Oct 8, 2020 (2020/10/08)で、一時的に止まった時点を 執筆者は閲覧し、レスしていました。 Alexander88207氏(i386-wineのコミッタ)の Oct 8, 2020 (2020/10/08)の 書き込み(post-480654)では、 試してみて、同様の結果になる、と、報告しています。 ※執筆者はこの書き込みは見ていました。 それから、ずいぶんたってforumsが動き出しました。 tbyte氏の May 2, 2021 (2021/05/02)の書き込み(post-509356)では、 FreeBSD13のwine-devel-6.4でも同様です(執筆者意訳)、 と報告されています。 grahamperrin氏の Jul 11, 2021 (2021/07/11)の書き込み(post-522107)で、 Alexander88207氏に対して、「Do you still get a null there?」 と返しています。 Alexander88207氏の Jul 11, 2021 (2021/07/11)の書き込み(post-522113)で、 「But the workaround for this error is to mount procfs on /proc.」 と書かれました。(注) 〔次に続く〕 read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる