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/ □いまさらながらCUPSを試す 3/3
以上の手順で、CUPSで印刷できます。
実際に、leafpadと、libreofficeで、印刷できました。
印刷キューは「http://localhost:631/jobs/」で見えました。
参考にしたサイト：
HL-5380DN, Debian
http://bm.skr.jp/linux/5380dn.html
Linux上で印刷する (CUPSを設定する) - Let's Try It!
https://www.letstryit.net/2010/03/linux-cups.html
FreeBSD10.0システムインストール
http://web.cc.yamaguchi-u.ac.jp/~hiroshi/FreeBSD/OKI-C610dn.html
５．５ プリンタの設定 | あらかると
https://www.starlink.jp/freebsd/freebsd-cups/ □FreeBSDのWOW64な、Wine6.x系、Wine7.x系からの印刷 1/2
＊執筆者特有の条件
・Wine6.0.4、Wine7.8のどちらにもwimeのパッチをあてた
i386なpkg(8)を「pkg32.sh install」。
・Wine6.0.4、Wine7.8のどちらも、i386なpkg(8)の
makeオプションは標準のままなので
「CUPS=off: CUPS printing system support」のまま。
＊状態
・LPR(/usr/bin/lp)、CUPSのどちらも、
amd64ネィティブのlibreofficeなどから印刷できるのを
確認済みの状態。
＊目標
WOW64なWineで、32bitなWindowsソフトウェアからの印刷をめざす。
「%/usr/local/share/wine/pkg32.sh install」で、指定のpkg(8)を
ユーザのホームディレクトリ以下に、ユーザ権限でインストールした
うえで、追加として「cups」「cups-filters」をインストールしました。 □FreeBSDのWOW64な、Wine6.x系、Wine7.x系からの印刷 2/2
＊Wine6.0.4
LPRで印刷できる。
CUPSでは「通常使うプリンタが設定されていません」。
※Wine6.0.4では、「lpd_enable="YES"」を切ってあっても
「/etc/printcap」の中身を見てプリンタ名を返しています。
＊Wine7.8(wine-devel)
LPRで「通常使うプリンタが設定されていません」。
CUPSでも「通常使うプリンタが設定されていません」。
という結果になりました。
32bitなWineを「CUPS=on」でmakeすればいいのかもしれませんが、
そこまでして「CUPS」を使いたいわけではないし……。
Wine7.x系に、特段の思い入れがあるわけでもないし……、
なので、Wineの安定版が7.xになってから試すことにします。
それを思えば、libreofficeは、LPRでも、CUPSでも、印刷できて
偉いなあ、と思います。
じゃ、お夜食を食べてきます。 備忘録。
タイミングで該当バージョンに当たった人がいるかもしれませんが
firefox-105は避けた方がよいようです。
Firefox-ESRが105固定になりませんように。
https://mevius.5ch.net/test/read.cgi/unix/1632283136/154-171 Firefoxは常に最新使ってるが105の時も落ちた事はないな
なおESRになるバージョンは決まってる
https://wiki.mozilla.org/Release_Management/Calendar あ、やっぱり、１つだけの報告の場合、
判断は保留したほうがいいのか。
つい、飛びついちゃうな。
ReleaseCalendarは知りませんでした。
ありがとうございました。 少し前にWine8.0がReleaceされました。
さがわ@sagawa_aki （sagawa_aki/status/1618968131002834944）
＞Wineの32bitライブラリがUnixシステムの32bitライブラリ
＞（FreeTypeやGstreamerなど）を使わなくなるので、
＞その分のディスクスペースを節約できます。
＞将来にディストリビューションがi386パッケージの提供をやめても、
＞32bitのコードセグメントを実行する機構を残してくれれば、へっちゃらです。
＞10:44 PM ・ Jan 27, 2023
FreeBSDのWOW64なWineが、64bit版Wineと、32bit版Wineを、
たばねた（注１）ような状態（注２）であるのは、
Wineの開発方向を把握した上で、将来的に対応しやすいように
配慮してあるのかもしれません。
「/usr/local/share/wine/pkg32.sh install wine mesa-dri」として、
pkg(8)の指示による、ユーザ実行のShellScriptで、
32bit版のWineを、ユーザのホームディレクトリに
インストールしなくてもよくなる方向か、と思います。
注１：別々に存在する物を同時に使えるようにしてある。
注２：Linux版も同様の状態かもしれませんが、執筆者は
Linuxを知らないのでわかりません。
※投稿時に、書き込みの末尾に、自動的にゴミがつくので
twitterURLの先頭部分をカットしています。 >>303
参考URL
WineHQ - Wine Announcement - The Wine team is proud to announce that the stable release Wine 8.0
https://www.winehq.org/announce/8.0
「Wine 8.0」がリリース 〜LinuxでWindowsのGUIアプリを直接実行できる互換レイヤー - 窓の杜
https://forest.watch.impress.co.jp/docs/news/1473266.html
今夜も Wine で乾杯! - 23本目
https://mao.5ch.net/test/read.cgi/linux/1585198566/744-n
＞このリファクタリングが完全に完了すると、
＞基幹のkernel32.dllやgdi32.dll、user32.dllすら
＞wineのからwindowsのに差し替えても動作するはずなので、
＞理屈の上では互換性がさらに向上するはず
（中略）
＞従来の64bit Linuxで32bitバイナリを動かす仕組みではなく、
＞64bitWindowsと同様の仕組みで32bit windowsバイナリを実行できる
＞新しいWOW64が実装された さがわ@sagawa_aki （sagawa_aki/status/1634408136709918725）
＞Wine 8以降のコミットをみると、IMM32によるIMEサポートを
＞加えようとしている様子がうかがえる。
＞方針がMLで共有されていないので、先行きは不明だけれど、
＞XIMと決別できるといいなあ。
1:17 PM ・ Mar 11, 2023
（全文引用）（改行位置は引用者）（twitterURLの先頭部分をカット）
との事で、
うまくゆけば、Wine環境下で動作するWindowsソフトウェアに対して
WindowsのIMEを使って入力する事が可能になるかもしれません。
そうなれば、wimeが修正される可能性も、あるかと思われます。
（備考１）
大昔の事で、どこで読んだか忘れましたが、
既知情報として、MicrosoftOffice付属などのMicrosoftIMEは、
Wine環境下にInstallできない（エラー停止）、とされています。
（備考２）
Wine8系のportが進まないのか、FreeBSDのVersionUpのタイミングに
合わせるのか、一般ユーザには事情が分かりかねますが、FreshPortsに
よると、現時点で、FreeBSDのwine-develは、7.22,1です。 2023/05/31にwime4.1.6がリリースされていました。
「パッチの整理」との事です。
パッチファイルが、WineのVersion別（Wine7.x、Wine8.x）に
増加しています。
wime4.1.6のReadmeの「Wineへのパッチ」を見ると、
Wine7系、Wine8.4までは、必要に応じて各種パッチをあてる必要が
ありますが、Wine8.6以降では、パッチは必要なくなります。
ただし、
「wimegtkやwimeximでかな入力をする場合はパッチkanainputを適用」
とのことです。
※kanainputは、Wine5.8以降、Wine7.7以降、Wine8.3以降の別がある。
単純にCannaとして使う場合、Wine8.6以降の場合、
Wineを自前でmakeする必要がなくなりました。
執筆者としては、とてもうれしいです。
まあ、現在のFreeBSDのwine-develは7.22なんですが。 FreeBSDの場合、64bit版ATOKは、Wine環境下にinstallできない、と、
執筆者は、どこかで読んだような気がするので、実際にその通りなら、
64bit版ATOK用のwimeのtransmsgパッチは、考えなくてもよいと
思います。
いずれ、64bit版ATOKがFreeBSDでの64bitなWine環境下にinstall
できるようになってから（ならないかもしれませんが）、
考えればよいでしょう。
いずれにしても、ATOKが32bit版をリリースしなくなったら、
FreeBSDではどうするか、という問題が残ります。
現時点では「ATOK Passport」には、32bit版があります（注）が、
おそらく、Windowsの動きに追従すると思いますので、
32bit版Windowsが完全に消えた場合、ATOKも32bit版が
新規に入手できなくなるかもしれません。
（注）
ATOK Passport32bit版のVersionUpが、2023/02/10に、
UpdateModuleが、2022/06/21に更新されている。 前スレッドを事実上の占有状態で消費した事による贖罪の意味で、
執筆者は、次スレッドとして、このスレッドを作成しました。
別にスレッドのヌシというわけではありません。
5ch(2ch)専用ブラウザ分裂がらみの「talk」掲示板のUNIX板には、
このスレッドと同名のスレッド（>>1のみがある状態）が存在しますが、
執筆者が関与したものではありません。
>>1 のみが、コピーされた形でのスレッドのようです。
「出典」という形で、このスレッドのURLが表記されてはいますが、
著作権的にはどうなんでしょうね。
「出典」には、あたらないように思います。以上です。 32bitWineは少なくとも15、16では動くだろうけど先のことは分からない
15.0が出るとまた方針が変わるかもしれないよと
https://cgit.freebsd.org/src/commit/RELNOTES?id=da51a1211dc799fa123f5d7f041eaf83c36f976b
今の流れ的には32bitに関して考慮する必要があるのは主にarmとWineについてで
i386自体はもういいだろって感じ 14.0では32bitカーネルは非推奨で15.0で削除される可能性があると警告が出るようになった
でも最終決定はまだ 15.0ではサポートされるのはCOMPAT_FREEBSD32とlib32で
ネイティブな32bitプラットフォームは非推奨ということですな
そしてstable/14は一週間遅れ 妙なスレ立てがあるようなのでsageたままにします。
「FreeBSDでwimeを使っている君」は、情弱です。
情報提供ありがとうございます。
FreeBSD/i386がTier2になって、すぐ感のあるいま、こういう話が
出ているんですね。人手、運用、設備を考えても仕方がないかなあ。
cgit.freebsd.org/src/commit/RELNOTE を翻訳にかけて読む限り、
Athlon64（AMD64・x86-64）以前の32bit機では、FreeBSDは
特定バージョンで打ち切りになるかもしれない、という事ですね。
Linuxでも32bit版を提供するDistributionが減っていますしね。
PAE_Kernelの記事でお世話になった「uyota 匠の一手」氏の反応は
どうか、と、思いましたが、いまのところ記事はないようです。
COMPAT_FREEBSD32と、lib32は、残るそうなので、32bitバイナリの
実行、32bitのソースコードのコンパイルはできますね。
そういうものがあるかどうかは知りませんが、ソース非公開の
商用などのソフトウェアで、それっきり更新されていない場合でも、
WXGの経緯（使い続けようとするユーザー側の努力）を参考にすると、
それなりの期間は安心かもしれません。
ドライバはソースを書き換えないと無理かもしれませんが、
その頃には、ハードウェア自体が腐っているかもしれませんし。
何かの事情で、COMPAT_FREEBSD32とlib32がベースシステムから、
なくなるとしても、純粋なcshがportsに移った経緯がありました
から、何とかなるかもしれません。
COMPAT_FREEBSD32とlib32、最終版Kernel、をベースに
独自のi386版としてフォークする動きがあるとおもしろいんですが、
ないでしょうね。 それで、Wineの場合です。
Wineの場合、Windows業界に蓄積された膨大なソフトウェア資産を
Unix系でも使いたい、というのが、もともとの趣旨でもあります。
そういうエロゲがあるかどうかは知りませんが、32bit版Windows向けの、
他機種に移植されていない特定バージョンのゲームがしたい、
などの要望は、性癖に関わりそうな話ですので、
Wineに対して、きわめて強い要望がありそうです。
ですが、>>303 に「さがわ@sagawa_aki」氏の引用をしましたが、
Wine8.0以降ならば、将来的に問題とは、ならなさそうです。 未来の話ですが、FreeBSDでのWine＋wime＋ATOKの場合、です。
現在、FreeBSD/amd64の64bit版のWineでは、64bit版ATOKが
インストールできませんが、インストールでき、動作すれば、
問題はありませんし、さがわ氏の引用に依ると、32bit版ATOKも
Wine側で対応できそうです。
余談ですが、大昔の一太郎では関連モジュール的なものに
16bitなWindowsバイナリが残っていたそう（公式に依るとそれを
更新したという記述がありました）なので、
一太郎の完全な64bit化は遅いかもしれません。
執筆者は、32bit版ATOK用のwimeのバイナリを仮想環境下の
FreeBSD/i386でgmakeしているのですが、この作業が、
どう変わるか、と思っています。
wimeのMakeFileに記述が入ればよいのですが、
wime作者のthomas氏はLinuxなので……。
執筆者は、wimeのPorts化すらできないので、修正する能力は、
当然ながらありません。キリッ！ FreeBSDでwimeを使っている君は、タイミングが悪いです。
i386wineの時も、書いた直後に新情報（統合する）を見つけ、
追加のレスをした記憶があります。
Wine公式のWineHQによると、以下の通りで、安定版と開発版の
両方とも、メジャーバージョンは８系に上がっています。
まあ、それが普通ですね。
Stable : Wine 8.0.2
Development : Wine 8.14 FreshPortsによると、以下の通りですが、
FreeBSDでは、安定版と開発版のメジャーバージョンに
ズレが生じています。まあ、よくある事なんですが。
執筆者的には、wine-develが8.11に上がっており、>>306 の理由で
非常にうれしいです。
さらに、新規に「wine7」ができていました。
FreeBSDでの安定版が、Wine8系に上がっても、明示的にWine7系を
使い続けたければ、「wine7」を使用する、という事かと思います。
wine 7.0.2_5,1
Last Update: 2023-08-18 21:57:12
wine-devel 8.11_1,1
Last Update: 2023-08-20 08:07:09
wine7 7.0.2_1
Port Added: 2023-07-30 22:00:06
Last Update: 2023-08-19 11:19:32 FreshPortsでの、Wine8.11の流れですが、wine-devel8.11,1時点では、
32bit版Wineに問題が生じていたようですが、8.11_1,1では、
問題ないようです。
「bump」とは、「stuck」に対応して「プログラムを実行する」
という意味なんでしょうか。
○8.11,1 13 Aug 2023 13:29:15
＞Finally, Wine 8.x so far does not appear to work on FreeBSD/i386,
＞so mark as BROKEN. Still better to progress than being stuck.
○8.11,1 15 Aug 2023 21:57:36
＞emulators/wine-devel: Fix 32-bit pkg invocation for WoW64
（中略）
＞Do not bump PORTREVISION since 32-bit builds are broken right now.
○8.11_1,1 20 Aug 2023 08:07:09
＞Bump PORTREVSION accordingly. PORTREVISIONを増やすのは元のバージョンは変わってないけど
ports/pkgに変更があったので再インストールさせたい時 >>318
知りませんでした。非常に勉強になりました。
「PORTREVSION」そのものも、まったく理解していませんでした。
「_1」「_1,1」は、単純なmakeのやり直しや、リンクされる物などの
バージョンが上がった場合、だと思っていました。
「Bump」は、１段階引き上げる、という意味か。
単純翻訳の語意イメージと合致します。
質問スレ125の209に書きましたが、その分野を理解していないと
単純翻訳だけではダメだ、という例ですね。 ググって、以下を知りました。
5.2.2.3. Example of PORTREVISION and PORTEPOCH Usage
https://people.freebsd.org/~olivierd/porters-handbook/makefile-naming.html
PORTREVISIONは「never decreases」とは知りませんでした。
FreeBSDへ移植する場合、移植元ソフトウェアにバージョンが
ない場合などでも、PORTVERSIONに単純な日付をつけるのは、
数値の大小問題が出るかもしれないので避けたほうがよいの
ですね。 PORTREVISIONは、命名が移植者に委ねられており、pintaを
例にとると、まず、移植元バージョンが「1.7.1」ならば、
「1.7.1」がつく。これは、「1.7.1,0」と見なされる。
次のバージョン命名がなされれば「1.7.1,1」となる。
※実際には「1.7.1,1」はないが。
移植元上でなく、FreeBSD上だけで、必要な修正があった場合、
「1.7.1_1」（1.7.1_1,0）となる。
元バージョンが「7.0」から「7.0.1」にUpした場合（人間的には
大の数値だが）、機械的には、大の数値と判定されないので、
あらかじめ（※注）、「7.0,1」と命名しておき、「7.0.1」は、
「7.0.1,1」と命名される。
※注：Wineのバージョン命名は決まっているので、あらかじめ、
リビジョンUpに備えて、「,1」をつけてあるのではないか。
また、遠目に見ると「7.0,1」を「7.0.1」と誤認する可能性も
あるので、必ず「*,1」をつける命名を選択したほうがよいかも
しれませんしね。
PORTREVISIONを理解すると、「*,1」で、不備などがあると
明記されている場合、「*_1」を待とう、と、判断する事も、
できるのですね。
勉強になりました。ありがとうございました。 PORTREVISIONとPORTEPOCHがごっちゃになってる
PORTEPOCHが増やされるのは単純に数値的に比較すると
バージョンの大小が判断できない時
Wineを例にすると20050930から0.9にバージョンアップした時
https://cgit.freebsd.org/ports/commit/emulators/wine/Makefile?id=943fc1582ce5f4bf7b55a853f4205bdfcc433080 あー、かなり混同しています。
指摘されるまで気づきませんでした。
引用URLの例のまま、gtkmumble-0.10を例にすると。
PORTNAME=gtkmumble
PORTVERSION=0.10
命名→gtkmumble-0.10 ※0.10,0と見なされる。
FreeBSDでpatchされました。
PORTNAME=gtkmumble
PORTVERSION=0.10
PORTREVISION=1 ※見落としていた。リビジョンだった。
命名→gtkmumble0.10_1 ※0.10_1,0と見なされる。
命名の数値大小問題でPORTEPOCHがつきました。
PORTNAME=gtkmumble
PORTVERSION=0.2
PORTEPOCH=1 ※よく分かっていなかった。
命名→gtkmumble-0.2,1
命名の数値大小問題の後のバージョン。
※PORTEPOCHが「never decreases」なので
最初から「,1」がついている。
PORTNAME=gtkmumble
PORTVERSION=0.3
PORTEPOCH=1
命名→gtkmumble-0.3,1 と、いう事は、ある時点で、PORTEPOCH=1がついた場合、
ずっと「0.3,1」のように後のバージョンにも最初から
「,1」がつき続ける、と。
なぜ、Wineに最初から「,1」がついているかと言うと、
20050930から0.9になった時に「,1」がついたから、と
いう事ですね。
pintaに「,1」がついていないのも、PORTEPOCHを設定する
状況がなかったから、という事ですね。
PORTVERSIONに日付をつけてもいいが、
後に日付ではないバージョンが出た場合や、
移植元ソフトウェアのバージョンのつけ間違いなどが
あった場合（引用URLでの例）、数値大小問題が発生するので
PORTEPOCHをつけてね、という事ですね。
混乱したまま、書いていました。
すっきりしました。ありがとうございました。
>>320の後半と>>321は間違いです。 ネイティブのchromiumからlinux版のwidevineが利用できるようになりました
まだ細かい不具合があるようですがいずれlinux版のchromiumなどを使わ
なくてもNetflixなどのDRMで保護された動画を見れるようになるでしょう 執筆者自身、FreeBSD上では、DRMで悩む事はないのですが、
こういう動きがあるたびに「あー、FreeBSDでよかったなあ」と
思います。
今では、FreeBSDって、なんだか、日本国内より、海外のほうが、
動くというか、若いというか、パワフル感がありますね。
Linuxより動きが遅くても、うれしいものです。
FreeBSD15.0-CURRENTでもi386版（非推奨ではありますが >>311）が
あります。よかったです。
32bit機に入れるわけではないのですが、i386版上でwimeをgmakeする
という目的がありますので、ないと困ります。
たったこれだけのために、仮想環境でFreeBSD/i386を、というのも
どうなのよ、なのですが。
これ、wimeをamd64版上で、COMPAT_FREEBSD32と、lib32を利用して
32bitバイナリとして、コンパイルする方法はないものですかね。 どうも。レスを書いて、寝かせてから投稿をする執筆者君です。
サーバ自体は動いており、該当サーバ上の他の板は開けるのに
ブラウザでUNIX板トップを開くと、真っ白だったので、
復旧を忘れ去られていたらどうしよう、と思っていましたが、
まだ、やや、重いものの、UNIX板、稼働するようになりました。
「したらば」と、「おーぷん」に、UNIX板が「あるにはある」のを
発見しましたが、業者宣伝で埋まっていたり、過疎で荒れて
タンブルウィードが転がっていそうな、開設した管理者ですら
忘却の彼方っぽい所（「したらば」は板ごとの開設管理者だったか、
と思います）へ移住するのもどうか、と思いましたし、
執筆者自身で開設するのも、管理業務が発生してしまううえ、
移住する住人感情の面でも「君が管理者カヨー」となりますので、
「どうなのよ」、と思いました。
※「t*l*.jp」掲示板のUNIX板は廃止され、スレは「パソコン一般」に
移動したようです。
その掲示板の「語れ」スレに、そちら側でレスがついていなければ、
こちらからコピーしたUNIX板由来のスレが、キレイに消えていたのに、
と思います。 UNIX板で、すでにある古いスレのタイトルと、１をコピーして、
スレたてをする動きがありますね。
スレタイを不完全にコピーしたものや、文章中にhtmlっぽいものが
入っているのを見ると、作業は「機械」でしょうね。
「意志」は人間だろう、と思いますが。
古いスレに他愛ない内容の上げレスなどをつける動きもありますね。
もう、ネタが古びているし、転用もしづらいスレタイなんだから、
上げなくてもいいでしょうに。ヒマ人（婉曲表現）はいるものですね。
必要もないのにスレッドタイトルを微妙に変えたり、必要もないのに
個人感情由来のサブタイトルを、つけ足したりして、スレ立てするのも
どうかと思いますし、一気に埋め立ててしまうのも、とても、とても、
どうかと思います。
「（CM声で）おカネは大事だよぉー。でも、スレタイ的にも、FreeBSDの
動きの最新情報は、もっと大事だよぉー」なので、落ち着くまで、
このスレで、FreeBSDを語ったり、質問をしても、よいのではないか、と
思います。
「（アニメ声で）こんな事もあろうかと」、
１の内容に「などの整備」「手段は問わない」を、入れておきました。
つーか、「公式を見ろ」ではあるものの、執筆者君は、情報弱者なので、
リリース情報などは知りたいですし。
じゃ、お夜食を食べるとします。 がーん。「語れPart58」が立ってました。
スレ一覧を見ればよかったお……。
サーバが重いもので、つい……。
「（今日のわんこ声）またしてもタイミングの悪い執筆者君でしたー」
シレッと、こういう理由で立てる方法があったか……。
FreeBSDを語れPart58＠UNIX
https://mevius.5ch.net/test/read.cgi/unix/1696777979
上記スレでは、FreeBSD14以降の32bit版の話題が出ています。
32bitソフトウェアを稼働させるWine的には、
FreeBSD側（Wineが稼働するOS側）の32bit環境は、
必要がなくなりつつありますが、
執筆者君的に不安なのは、wime側の話です。
Wine上で稼働する32bit版ATOKを、ATOKのユーザインタフェイスの
ままで、emacsに入力する、という可能性も、あるかもしれませんが、
それだと、wimeのグッドアイデアとしての
「Cannaとして振る舞う」
の良さがなくなるしなあ。
まあ、FreeBSD/i386（FreeBSDの32bit版）の動きと、
wimeの動きを注視する事にします。 UNIX板にも、「Keyboard キーボード 3」のスレがあるんですが、
廃墟になって十年近いので、こちらに書きます。
PC系媒体でのニュースはもちろんの事、ハードウェア板の
「Happy Hacking Keyboard US」スレや、
「IBM/Lenovo トラックポイント付き単体キーボード」でも
話題の、今はリコーグループとなったPFUから「HHKB Studio」が
発売され、速攻で売り切れたらしい、という話です。
媒体記事や、使用レポートは、たくさん出回っていますが、
機能、仕様の報告となっている記事を貼っておきます。
OSもアプリも関係なく自分の作法であらゆるデバイスを使いたい〜HHKB Studioならそれができるかも
https://pc.watch.impress.co.jp/docs/column/config/1542688.html 「HHKB Studio」とは、HappyHackingKeyboardに、IBMのNotePCの
ThinkPadのようなマウス用途のポイントスイッチ（マウスカーソル・
マウスクルーザー）の“ポッチ”がつきました、という話なんですが、
過去には、ThinkPadのキーボードだけ、の製品があったように、
ThinkPadな人には、たまらないでしょうね。
製品の記事は、Windowsが前提なだけに、やはり、公式の
キーマップ変更用のツールも、Windowsや、Macが対象のようです。
※前述記事に依ると、キーカスタマイズは、「HHKB Studio」自身が
記憶する。カスタマイズを試行する記述が興味深いので
カスタマイズ周りが気になる人は読んでみてください。
「HHKB Studio」は、FreeBSDでは、どのように認識されるか、
ゼスチャ機能は、X_Window_System（xev）では、どういうキーコードを
吐くのか、興味がわきます。X_Window_Systemでも、割り当てて
使いたいですしね。
少し欲しい気持ちになりつつ、NotePCを「尊師スタイル」で使う場合は、
場所を取らなくていいなあ、でも、マウスボタンを押しながら
マウスクルーザーを動かすのはつらいかも……、などとも思いましたが、
執筆者君は、NotePCを使っていない、という事を思い出しました。
「中クリックでペースト」よ、さようなら？ | スラド オープンソース
https://opensource.srad.jp/story/13/09/25/0419255/
あらら、今って、こういう時代だったんですね。知りませんでした。
※前回の書き込み時に２連投しようとしたのですが、書き込めなかった
（書き込み成功は出るが、書き込みができていない）ので
日にちをおいて投稿しました。 今の書き込みも１回目は吸われ、文面を見直して２回目を投稿すると
Rock54でした。NGワードがありました。
「製品『しょうかい』の記事は」（『』内は漢字）
の２漢字単語がダメだったようです。犯罪誘因対策ですかね。 気になるDesktop環境ネタ。
poppler を使った各種PDFリーダで、合字が空白表示されたり、
合字にならずに表示される件。自力解決済み。
（質問125）https://mevius.5ch.net/test/read.cgi/unix/1632283136/216-n
EeePC 4G-X に FreeBSD14.0R/i386をInstallした対処の報告。
（語れ058）https://mevius.5ch.net/test/read.cgi/unix/1696777979/77-n 最近の環境のemacsでの「anthy.el」で、anthyのON/OFFのトグルが
うまく動作しない件。助言により、anthy.elの修正にて解決済み。
（語れ058）https://mevius.5ch.net/test/read.cgi/c/unix/1696777979/120-n 元コアでメンテナだった佐藤さんが japanese/kterm を復活させました >>336
おおっ！ うれしい！ ありがたい！
ボランティア、頭が下がります。
ずいぶん昔から、標準の xterm で、日本語が通るように
なりましたが、このフォントで、などと設定をしたくても、
イマイチ感がありました。
今どきは、各デスクトップ環境の物のみならず、
多くの仮想端末が存在するけれど、やっぱり、
日本語を扱う昔からの仮想端末の標準物として kterm が
存在しないとダメではないか、と思っていました。
FreshPorts
＞Last Update: 2024-01-07 17:30:34
＞Resurrect kterm-6.2.0
復活してホッヤホヤ。 ktermのman見てたらutf-8と書いてあって
gitのログ見たら2013年にUTF-8のサポートが追加されてた
知らなかった ( ﾟ ⊇ ﾟ)チャーラ〜ヘッチャラ〜
ちょっとユルい感じになっている層が薄いだけやん 過去の犯罪者は騙されやすいから効果覿面
国葬は「ある」との違いかもだが
真っ向勝負の雑談配信を 今の仕事が許されるわけないの
アクアリウムはやってないとかあるはずがないよね
イェール中退しなかったら本物ってことか。 嵌め込み酷い
それが出来やすくなるらしいから詰まりどころがないって？
視聴率取れないし客席ガラガラになるじゃん？
ワイヤレスゲート空売りゴチ UNIX板にも、スレ立て荒らし、スクリプトらしき
書き込みの埋め立て荒らしは、一気という感じでなく、
チビチビと来ていますね。
現在、このスレの順位は418です。
100ほどスレ立て荒らしをされるとdat落ちする可能性が
高い、と感じました。
「スレが落ちたら立てればいいや」と思っていましたが、
スレ立ての労力（たいしたものではありませんが）や、
立てたい時に、システム変更で立てにくくなっているかも
しれない、と、考え、何かを書いて、ageておいたほうが
いいのでは、と思いました。
いま思えば、日本語入力ネタなら、UNIX板には、
「IMEなんとかしろ」のスレがあったのですが、
次スレが期待されるスレタイとは言い難いですしね。
執筆者的には、wimeや日本語入力、デスクトップ環境や、
Wineについて、飽きたわけではありません。
wimeネタは、執筆者が新規に試した場合、試用報告を
するつもりでいます。書かずにはいられないですから。
まだ、古い環境を使っているので…。すいません。
いま見た、語れスレによると、６月には14.1Rとの事です。
うーん、執筆者的には、なんとも中途半端だお…。
じゃ、お夜食を食べてきます。 荒らし前はスレ順位が700くらいならまだ残ってたくらいだった
何度かスレを消してるんだろうけど抜本的な規制や対策する気がなさそう 
