Puppy Linux 日本語 フォーラム

Linux も派生しすぎて、わかりにくくなってしまっている。もう少し、収束してwindows に対抗しないと、一般には普及しないんじゃないでしょうか？

私も以前はそう思っていました。しかし、これについては諦めています。Linux の開発者やユーザーは自分の好きなようにしたいのだと思います。cloudy さんもデスクトップの見た目で bionicdog を選んだのでしょう?

情報やサポートが最も充実しているのは ubuntu 本家だと思います。有料サポートもあります。windows のような至れり尽くせりの環境を求めるなら、とりあえず ubuntu。

Windows から Linux に移行するのなら、一遍に移行せずに、併用しながら徐々に移行していくのがよいと思います。また Linux もいくつかのディストリビューションを試してみるといいと思います。

wine は多用すべきではないと考えています。最後の手段です。ほとんどの場合、Linux の機能やアプリで windows と同じことができます。私は年賀状も puppy で作って印刷します。wine を使うのは、古い windows 版「電車でGo!」をするときだけです。

ありがとうございます。
ubuntuがいいなと思ってました。BionicDogもubuntuの血も引いているのかなというところも決め手だったかなと思います。パソコンが遅いんで、軽いということも条件でした。
最初はwine中毒でスタートしてLinux でいままで通りwindows フリーソフトを使い、長い時間をかけLinux に慣れ、いつの間にかwindows にお別れしたいなと思ってます。

Windows 95 で初めて Windowsを使い、Windows 2000 のころには Linuxをメインに使っていました。WindowsでできることはたいていLinuxでもできます。
最近のアプリは Windows/Mac/Linxで動くマルチプラットホームのものが多いです。前面で仕事してるのはそれぞれのアプリなので、それを管理・支援するOSは小さくてけっこう。これが Linux、そしてパピーを使う理由。

Word とか Excel とかで送られてくるファイルはLinuxで、当初 Abiwaord と Gnumeric。最近はLibreOffice があるのでなんとかなります。フォントの問題は残りますが。
困ったのは一太郎です。一太郎ビューアーはWindows版しかありません。ポータブルWineを開発したのはそのためです。もう忘れたけれど、一太郎で書かれたファイルをPuppy Linux上でクリックするとポータブルWineと一太郎ビューアーが起動して普通に読めるよう設定することができました。

それから7年くらい経ったでしょうか。最近にWineが必要になったのは、Second Life や Opensim。いずれもパピーで動きます。ただ、ボイスチャット部分を Vivox社に頼っており、SLVoice はWindows版しかありません。その部分だけ、SLVoice.exe をWineで動かす仕組みがあるとのことで、今回いろいろ探して Wine-8.0 のSfsを発見し、いま使っています。OpensimではOKですが、Second Life では成功しておらず、そのときだけWindowsを起動しています。

Windowsでなければならないケースに、Nvidia グラフィックボードのドライバ。Linux版はあるので重宝していますが、グラボにある動画のハードウェア支援エンコードが Windows版にしかありません。動画キャプチャではWindowsにお世話になっています。

portablewineの開発者のシノバーさんよりコメントいただけるとは光栄です。
表現が正確でないかも知れませんが、portablewineはwindows ソフトを使うたびにwineの環境を展開するんですよね？例えば複数のwindows ソフトを同時に使用するとき、それぞれのソフトを起動するたびにwineの環境を展開しようとして、なにかがお互いに干渉してしまうようなことはあるのでしょうか？
繰返しの質問になってしまうかも知れませんが、portablewineとwineのメリットとデメリットをご教示願えますか？

cloudy さんが書きました: ↑24/07/23(火) 23:17複数のwindows ソフトを同時に使用するとき、それぞれのソフトを起動するたびにwineの環境を展開しようとして、なにかがお互いに干渉してしまうようなことはあるのでしょうか？

開発当時に複数のWindowsアプリを同時に動かすことは想定していなかったのですが、じっさいにはちゃんと動くようです。２つめのアプリはすでにマウントされているSFSを利用することになるようです。SFSと言いましたが、実際には wineserver が動いてます。

WineはLinux上でWindowsアプリを動かすものですが、当然にムダがある。１つのWindowsアプリを動かすために、Linuxのシステムが動き、その下で wineserver、さらにその下にWindowsアプリ.exeです。ディスクスペースもですが、CPUリソースとRAMも消費します。そこに2つめのWindowsアプリとなると、そのどちらもいっぱいいっぱいになる可能性があります。
特にRAMがいっぱいになると、スワップ・ファイルにアクセスすることになって、体感的に「ひっかかり」を感じるでしょう。

仮想端末で top コマンドを叩けば各プロセスのCPU使用率やメモリの占有、
free コマンドを叩けば swap が起きているかわかるのかな。

マルチタスクのwindows でソフトを複数起動するなんていうことは当たり前のことですが、Linux wineでwindows ソフトを複数起動するとリソース的な制約が顕著になってしまうということですね？
portablewineを通常wineと比較した場合のメリットとデメリットをご教示願えますか？以下の推測は正しいですか？
✕.sfsより環境をメモリーに展開するため少し時間がきる。
○.sfsより直接環境をメモリーに展開するためハードディスクの節約になる。
□いずれにせよ環境をメモリーに展開するのは同じなためメモリーの消費は通常wineと同じ。

シノバー さんが書きました: ↑24/07/11(木) 09:14 ポータブル版Wineでwineserverを常駐させる方法としては、メモ帳あるいはエクスプローラーなどを開き最小化にしておくという方法もあるかと。

おっしゃるように、メモ帳などを開いておけば、都度.sfsより環境をメモリーに展開する必要がなくなり、ほぼ通常wineに対するデメリットはないということになりますね？

(横から口をはさむのはどうかと思いつつ) このスレッドは私が立てたのだから、コメントしても構わないですよね?

実際にやってみればいいのでは?
・squashfs (sfs) 形式の wine をOS起動時にロードした場合はどうか
・apt で wine をインストールした場合はどうか

これらを portable wine と比べてみて、パフォーマンスがいい方法を取ればいいのではないですか。

追記
これまでにも書いていますが、実験をする場合は、portable wine を登録したシステムではなく、新規に用意した環境で行なって下さい。

ありがとうございます。
そうなんですけど、初心者には、なかなか、実験するのが、おっくうなんですよね。実験失敗して、現状復帰できなくなっちゃってもいやですし。
理屈では、こうなるというところだけでも、教えていただければ難有いといったところです。
特に否定されなかったってことは、わたしの推測は、外れてはいないっていうことですかね。

理屈だけでは前進しません。実験で確かめなければ。

保存ファイル or フォルダをバックアップしておけば、もとの状態に戻せます。また、保存ファイル or フォルダがなければ、初期状態になります。簡単バックアップと簡単リカバリーがライブCD方式のメリットだと思いますが。

bionicdog にはバックアップツールはないのですか。なくても、自分で保存ファイル or フォルダを別の場所にコピーすればいいだけだと思います。

cloudy さんが書きました: ↑24/07/24(水) 06:35以下の推測は正しいですか？
✕.sfsより環境をメモリーに展開するため少し時間がきる。
○.sfsより直接環境をメモリーに展開するためハードディスクの節約になる。
□いずれにせよ環境をメモリーに展開するのは同じなためメモリーの消費は通常wineと同じ。

まずお答えしたいことは、SFSはメモリ上に展開されるわけではありません。その代わりにCPUの負荷は少し大きくなります。したがって、そこの部分で時間がかかるのは事実です。

「通常Wine」を「.petや.debパッケージをインストールすること」と解釈します。それに対してWineのシステムファイルを単一のSFSに圧縮格納する場合との比較をおっしゃっているのだと思います。SFSファイルはパピーのシステムファイルがみんなそうなっていて、「ライブCD方式」とおっしゃっているのもそのことをさしているのかと想像します。するとこれは Wineに限らずパピーのシステムの根幹の問題ですね。

あえて実験するまでもなく Debian や UbuntuなどシステムファイルをHDD上に展開する方式と、パピーがすべてのシステムファイルを数個のSFSファイルにまとめてHDDに保存する「フルーガルインストール」方式がじっさい「小型軽量」を発揮していることをみれば明らかではないでしょうか。

パピーのHDD上での占有スペースは圧倒的に小さいです。
メモリの占有は説明が難しくなります。パピーに限らずLinuxは実装RAMをできるだけ活用しようとするので、メモリの占有率を比較してもあまり意味がありまあせん。私はスワップが発生するかどうかが判断材料と考えてます。

パピーのマジックを理解するのはなかなかたいへんだと思います。しかしcloudyさんが「ライブCD方式」と呼んだのは、なかなか的を射ているかもしれません。
パピーのそもそもの出発点は、ライブCDから起動して、実用的な速度で OSを動作させる技術からです。
CDだけでなく USB-1.1 のころのフラッシュメモリに対応したのもパピーですし、現在でもパピーの優位は動かないと思います。内蔵HDDでもノートPCのそれは遅いので、やはりパピーに軍配が上がるかと思います。
技術の詳細はさておき、CPUの負担は少し増えても、低速のメディアへのアクセスを極力少なくすることで総合的なパフォーマンスをあげるという設計になっています。

本題からずれていくけど、勢いで。

シノバー さんが書きました: ↑24/07/24(水) 23:49パピーのそもそもの出発点は、ライブCDから起動して、実用的な速度で OSを動作させる技術からです。

初期のパピーリナクスのシステムファイルは 100MBに収まりました。CDの容量は 640MBなのに、どうしてそんなに小さくする必要があったのでしょうか？
「それは当時のPCの実装RAMが少なかったからだ。」とお思いになるでしょう。たとえば実装RAMが250MBだったとすると納得がいく。
元のシステムファイルが全体で 400MBだったとしましょう。そのままでもCDに収まるが、 256MBのRAMには収まりきらないから、ファイル圧縮技術で100MBにまで圧縮した。
ここでふと疑問が沸きますよね。100MBに圧縮されていても、展開すると400MBになるではないか。
展開しなくても中のファイルにアクセスする方法はあるのです。解凍ソフトで「全解凍」しか使っていないと気付きませんが、中のファイルのリストが見られるので、中の１つのファイルだけを取り出すことはできます。

さて、実装RAMが最低でも1GBある時代にも圧縮は必要でしょうか。400MBのシステムファイルをCDにそのまま収めることはできます。（展開ではなく）解凍の手間が省けます。
しかしそうするとCDからの読み込みにすっごく時間が掛かる。100MBに圧縮できれば、読み込みの時間は1/4に短縮されます。
システムファイルを圧縮することの２つの利点を分かっていただけたでしょうか。

CDの例でお話しましたが、同じことは相手がフラッシュメモリなど低速のデバイスで同じことが言えますし、ノートPCに内蔵のHDDとて高速ではありませんから、似た影響はあります。
パピーが最小であることと最速であることの、これはひとつの要因であると指摘できるでしょう。もちろん、その圧縮されたシステムファイル(SFS）をそっくりRAMに格納できれば、爆速になることは間違いありません。

ありがとうございます。
.sfsを使用するフルーガルインストールは、コンパクトだし速いし、いいことずくめですね。そのぶん、ちょっと難しいことをしているため技術も必要でしょうし、CPUもちょっと考えることが多いということですね。
そしてportablewineについても同じことが言えるということですね。
じゃ世の中のLinux 全部、フルーガルインストールになってしまえばいいじゃないかと思いますが、ちょっと難しいことをしているぶん、大規模なシステムには向いていないということでしょうか。
特に問題なければこのままフルーガルインストールとportablewineでいきたいとは思っています。

cloudy さんへ
確か、ご利用のマシンはメモリ 1GBだったと思います。

家のマシンで bionicdog に近いと思われる bionicpup32 を実行し、wine portable でアプリを一つ実行、さらに、Firefox (Linux 版)で YouTube を表示すると、メモリ使用量は約 1GBです。

家のマシンはメモリ 4GBなので余裕がありますが、1GBだったらまったく余裕がありません。
windows は swap ファイルを自動で設定しますが、Linux はそうではないと思います。(bionicdog に自動設定があれば話は別ですが)
swap ファイル、または swap パーティションは設定されているのでしょうか?

シノバー さんが書きました: ↑24/07/25(木) 01:28 圧縮されたシステムファイル(SFS）をそっくりRAMに格納できれば、爆速になることは間違いありません。

お言葉ですが、これには現在、異論があります。本家フォーラムでも議論がありましたし、私も疑問を持っています。

NoblePup64 24.04 日本語化パッケージ (pet)
https://sakurapup.com/forum1/viewtopic.php?f=26&t=3668

カーネル行に pfix=fsck,nocopy を記述してみたら、sfs はコピーされなくなり、メモリ使用量は半減しました。システムの sfs もコピーされなくなるので、起動も速くなりました。
起動後の動作速度に違いは感じられません。(CPU の動作速度が遅いパソコンでは違いが生じるかもしれません。)

引用したのは Noblepup64 の例ですが、BookwormPup64 でも iso のサイズが 700MB を越える状況です。64bit windows を実行するマシンは最低でもメモリ 2GBですから、700MB という値がただちに悪影響を及ぼすとは思いませんが、Puppy のかつての常識が必ずしも通用しなくなってきていると感じます。パソコンの性能が飛躍的に向上したことも影響していると思います。

thinkpadnerd さんが書きました: ↑24/07/25(木) 14:15

シノバー さんが書きました: ↑24/07/25(木) 01:28 圧縮されたシステムファイル(SFS）をそっくりRAMに格納できれば、爆速になることは間違いありません。

お言葉ですが、これには現在、異論があります。本家フォーラムでも議論がありましたし、私も疑問を持っています。

パソコンの構成はさまざまあり、ケースに依るでしょう。CPUの能力、実装RAMの容量、主ストレージの入出力速度など。
パピーは実装メモリの半分をメドに、読み込める限りシステムSFSをRAMに読み込むというストラテジーだったかと思います。それが不適切な場合もあるでしょう。
だからといって、SFSを読み込むの読み込まないなど事細かにブートメニューに押し並べる Fossapupのやり方はいただけません。