Sylpheed Portable for Linux? [SOLVED]

[geo_c]

Is there a portable or appimage version of Sylpheed for Linux floating around anywhere?

Now that I have a powerhouse working jackalpup system, I'm thinking of firing up a clean boot with no-save and installing only the most absolutely necessary applications from the repositories and using as many portables as are available Then remastering the lean install and saving future system changes by remastering any significant updates.

I'm already running about 15 portable apps including Wine, Zoom, Gimp, Musescore etc. It'd be nice to run Sylpheed as a portable also.

[mikeslr]

Hi geo_c,

Well, I now have an SFS, a portable and an AppImage of Sylpheed 'floating around' because I just created them. But I'm not going to provide any because (a) each is about 160 Mbs; (b) they're for Bionic64 which may not work under jackal and (c) I subscribe to the adage "Give a man a fish and you've fed him for one day. Teach a man to fish and you'll feed him for a life-time."
Considering your objectives --not just sylpheed-- showing you how to roll your own is more efficient.
You'll need to install two applications: PaDS 1.1.7, from here viewtopic.php?p=6355#p6355 and Create Portable AppImage from here, viewtopic.php?p=3250#p3250.
Edit: Thank you again Taersh and fredx181 for creating and publishing those applications, respectively. Without them, I would also just be someone waiting for someone else to feed me.

Create a folder somewhere on /mnt/home [or if your working without a SaveFile/Folder on any mounted partition]. Name it something like ‘temp’. In that folder create another folder named ‘sylpheed’ --without the quotes. Open Puppy Package Manager. Change the setting at the top --which by default reads “Auto Install”-- to “Download All (packages and dependencies). Especially for an AppImage you'll want it to contain All dependencies. After all the packages have been downloaded –it takes some time, Bionic64 had 26-- move all the packages into the sylpheed folder.
Right-Click the sylpheed folder and from the pop-up menu select “Combine to SFS”. Installing PaDS created that Right-Click Option. PaDS will decompress all the downloaded packages and re-assemble them in their proper locations in a work-folder in /root. After it does that, a GUI will open which looks something like this:

PaDS creating sylpheed sfs.png (71.13 KiB) Viewed 2180 times

I’ve already used the GUI to make some changes: slypheed selected at the top-left, x-internet-mailnews selected as the Menu-category, and the 64x64.png as the display icon. There’s one further change I’ll make before clicking Finished. The Exec: box reads sylpheed %U. Delete the %U. Puppys don’t use that command. [For future reference, they also don’t use a %f command and its presence generates an Error. I don’t know of any command following the name of the executable Puppys use. I would delete any.]
PaDS will create an SFS at /root. Move it from there before doing anything else. If you SFS-Load it from there and then unload it, it will be deleted. If you can live with an SFS, you’re probably finished. If there’s a problem: with the SFS loaded, (a) try starting it via the terminal: /usr/share/applications/sylpheed.desktop’s Exec= identifies the executable; and (b) pfind that executable, file-browse to it, Right-Click it and select ListDD to see if any dependencies are missing.

To create both an AppImage and a portable, first create another folder named, for example, sylpheed_jackal. Left-Click the SFS, select View, and from the window which opens copy ALL the files into the sylpheed_jackal folder.
File-browse to the Create-Portable AppImage and Left-Click it. It’s GUI will look this this:

Create Portable's GUI.png (72.05 KiB) Viewed 2180 times

Click the Folder Icon below “Select the directory to use as ‘AppDir-root’, then file-browse and select the “sylpheed-jackal’ folder. Where it asks “type command to be executed, e.g. abiword” type ‘sylpheed’ without the quotes. For future reference the command will always be that which followed Exec= in /usr/share/applications/YOUR-APPLICATION.desktop.
During its process Create-Portable AppImage provides an opportunity to test with instructions. When completed both an AppImage and a portable-folder will have been created.

Neither PaDS nor Create-Portable AppImage are 100% foolproof. But they work most of the time once you've found all dependencies. And they did work with sylpheed for bionicpup64 -- or at least I think so. Tests did not reveal any problems. But I don't use sylpheed so don't know what hidden problems may be lurking.

[mikewalsh]

.....or if you're like me - and have more space than you're ever really going to use! - you create dedicated "work areas". I have four of 'em, on the second partition of my secondary internal drive. At 3 TB, what am I likely to use all that for..?

Mike IS quite right, though. Far more effective to teach you how to create stuff for yourself, rather than rely on the goodwill of someone else to do it all for you. And most of us LIKE helping others out where we can.

This is one of the great things about this community. Many of us have - or have HAD to - develop ways round various problems, issues, and general procedures for doing things under limited resources. The latter is not as relevant these days as it used to be, with really old machines getting gradually retired & replaced with newer, more capable ones. At least 2 members of the community have 64 GB of RAM to play with; several - myself included - have 32 GB of the stuff. Many have between 8-16 GB nowadays. I know it's getting away from Puppy basic principles, but the future never stands still, and is usually here before we realise it. It's astonishing how quickly you start to take humungous amounts of RAM for granted!

BTW; I DO have Thunderbird portables available if you're interested.... Never could get on with Sylpheed. Too much manual setting-up for my liking, and it never would work with one of my a/cs....

Mike.

[snoring_cat]

Just out of curiosity, do you have preference for using Sylpheed over the built-in Claws-mail?

[geo_c]

Considering your objectives --not just sylpheed-- showing you how to roll your own is more efficient.
You'll need to install two applications: PaDS 1.1.7, from here viewtopic.php?p=6355#p6355 and Create Portable AppImage from here, viewtopic.php?p=3250#p3250.

Well, I kind of feel like Eric Idle at the Bridge of Death after Sir Lancelot answers the questions correctly and crosses over, when Sir Robin exclaims, "That's Easy!" And we Python fans all know what happened next.

But we'll see soon enough. If anything the idea that one can just 'download all the dependencies' from the package manager is news to me. Although I've seen the choice many times, the implications just never sank in, as with so many things I've seen and forgotten about.

Thanks to both MIkes, it's a lot to expect of people to give long instructional posts, and I appreciate that about the puppy community. I've learned a lot in the past six months that has transformed Puppy into a first rate full time OS for me.

I found myself weighing the value of remastering versus simply using save files, The question I couldn't exactly answer is "What is the advantage of having a read only system?" And my final conclusion is that if I build it from the ground up, I will have a clean theme and work-flow customized system that can be re-started from scratch without a whole of work. In other words, even more flexibility to experiment and break things.

[geo_c]

Just out of curiosity, do you have preference for using Sylpheed over the built-in Claws-mail?

Yes, it's just a preference. I like Sylpheed, it's super fast, the mail is easy to store locally and view in a text editor once archived, and I've been using it ever since I first booted Lucid Puppy, even in Windows while I was still a Windows user.

It is a bit of hassle to set up. It has to be done manually in most cases, but I also fetch mail pop3 from everything except one MSOutlook work account. I phased out my gmail account for the most part by having everything forwarded from there and never sending outgoing mail from google. I'm anti-Big Tech, because they are anti-Me.

I tried Claws, and I was never a Thunderbird fan to begin with. It's just more than what I want from email. I just want text messages, not calendars, and mailing lists, and html display. Sylpheed does the trick for me.

[mikeslr]

...I found myself weighing the value of remastering versus simply using save files, The question I couldn't exactly answer is "What is the advantage of having a read only system?" And my final conclusion is that if I build it from the ground up, I will have a clean theme and work-flow customized system that can be re-started from scratch without a whole of work. In other words, even more flexibility to experiment and break things.

There's a third possibility you should know about. I'm in the process of writing a "Tip" about when to Remaster, and alternatives. But the short version is this:
amethyst --formerly known as nic007-- published a Utilities Suite which includes a module --Save2SFS--for creating either an adrv.sfs or a ydrv.sfs --or sequentially both. Both adrv.sfs and ydrv.sfs would be 'READ-ONLY'. The module uses as its source your SaveFile or SaveFolder plus whatever applications you've installed but haven't yet Saved. If you don't have a SaveFile/Folder, it just uses the last.
After you create an a-or-ydrv, you can delete your SaveFile/Folder or move it so that it won't be used --safer if you find a problem and have to revert. If you want you can create a new SaveFile/Folder and continue exploring, or boot into a READ-ONLY OS; or create two menu listings --one using the pfix=ram argument-- and choose either.
The latest version is here, viewtopic.php?t=1694
Earlier discussions on the 'old-forum' can be found here, https://oldforum.puppylinux.com/viewtop ... lities&i=1
All of 4 pages, total.
Using Save2SFS is both faster and less error-prone than remastering. The reason it works is that all Puppies will, on boot-up, use both adrv.sfses and ydrv.sfses if they are present; and because of priorities given such files: "Always remember the pecking order: savefile contents > adrv >ydrv">Puppy_Version_#.sfs. That is, your SaveFile has the highest priority. Its contents will always be used. Non-Conflicting contents of adrv.sfs will then be used; then non-conflicting contents of ydrv.sfs and lastly non-conflicting contents of the applications the Dev built into the Puppy_Version_#.sfs.
There are still some reasons to remaster; and amethyst's Suite provides applications for that. They, also, are less prone to human-error and faster than the builtin application.

[geo_c]

Well,

An interesting thing happened on the way to the Sylpheed AppImage Party. I installed the three recommended pets/scripts last night before going to bed, and this morning I noticed that the XFE's right click function is busted. It just hangs using 25% of cpu indefinitely. So, I believe that's because one of those pets adds entries or modifications to the right click function.

A possible conflict might be the fact that I have another right click script installed on ROX. I need to locate that, as I have forgotten what it's called and where on the forum I got it. I believe it 'adds a program to the ROX desktop' among other options. I will go back to a previous save file and make a comparison.

i think this is where I need to consider starting with a clean system, as this one I'm working in is quite bloated. I've made use of several available scripts and utitilites or the past 9 months.

Thanks @mikeslr for the tip about adrv and ydrv. That sounds like the best alternative for my purposes.

@geo_c

[mikeslr]

i think this is where I need to consider starting with a clean system, as this one I'm working in is quite bloated. I've made use of several available scripts and utilities or the past 9 months. @geo_c

Before you abandon your current system, open Menu>Setup>Puppy Package Manager, Click the Uninstall tab and take screenshot's of what you've installed.
I do that before a remaster or Save2SFS. Saves guessing. But then, I have the memory of a sieve.
Examining what you've installed can sometimes provide a clue as to why a conflict now exists.
Except for adrv, fdrv, ydrv and zdrv, SFSes have the lowest priority. Those I just mentioned will always be used if present when you boot-up and can't be unloaded except by moving them to where they won't be found and rebooting. But other SFSes can be loaded and unloaded on-the-fly. [The only applications which are problematic when run as SFSes are those requiring python. If there are conflicting python modules with higher priority, Puppys will use those rather than the modules required by the application in SFS form].
But I don't think that Sylpheed is creating the problem unless you installed it or still have files left-over from your previous attempts. The recipe I gave first created an SFS. If you're using an SFS you can unload it and see if the problem persists. The other two forms --AppImage and Portable-- don't write files to your System. When you start them they mount at /tmp: Puppy makes use of the files they contain by following a path thru /tmp, but only for and to that application. /tmp is not a location where installed applications would ordinarily look for components. One of the great advantages of AppImages and portables.

[geo_c]

But I don't think that Sylpheed is creating the problem unless you installed it or still have files left-over from your previous attempts.

No, you're right it's not Sylpheed because I only got as far as installing the pets and firing them up to see what they looked like. I never even tried to create an sfs or portable. On next boot I noticed the right click issue in Xfe on two different installs on different machines.

I do think I'll a start with a clean puppy, and build the system up from scratch. Right now my savefiles are 4.5gb. So I could clean up the current system by deleting all kinds of data and executables, libraries, etc, but I would feel better going with a fresh start.

I mean the beauty of it is I have puppy installed frugally on several machines, I can simply boot into a clean system on one while running my fully developed system on another. I don't even have to take screenshots.

[geo_c]

i think this is where I need to consider starting with a clean system, as this one I'm working in is quite bloated. I've made use of several available scripts and utilities or the past 9 months. @geo_c

Before you abandon your current system, open Menu>Setup>Puppy Package Manager, Click the Uninstall tab and take screenshot's of what you've installed.

Well Puppy is just the most fun OS around. I decided to start from a clean boot in RAM. With my fully developed system booted on another computer as a reference. Since I have neatly tucked away all the scripts and pets, and rc config files and so forth on a usb hard drive, along with my current bloated system saves, I've just migrated my entire desktop theme to a clean system in a matter of an hour or two. And also to my surprise I was able to install Rainlendar2 simply by doing a file search in Xfe and copying all the Rainlendar2 files to the clean system. This was important to me, because it's a very productive calendar app and since they upgraged, there are no pet packages available in the package manager anymore, and also no portables for linux available.

I haven't installed Sylpheed in the clean system yet, so I think I'll make an extra pupsave and install the Create-Portable64 pets and try it there when I'm fresh.

Puppy is fun in that basically you can swap files between several systems just by browsing through the pupsaves. I copied everything I could find called JWM and GTK, and then installed the latest JWM-Desk, and boom, it all came up taskbar, icons, window styles, etc.

Sweetness.

Once I get the basics on this system, I think I'll try a remaster before I put my personal information into the system, such as email accounts.

[mikeslr]

Hi geo_c,

While waiting for my first cup of coffee to kick in before I do anything dangerous, I re-read this thread. Two thoughts. PaDS does create a Right-Click menu listing. So there's a possibility it did create the problem you encountered. The work-around: PaDS does not use python which, AFAIK, must always be installed. And you don't need PaDS to always be available. So, after installing PaDS, use it to create a PaDS SFS. Then uninstall PaDS. Whenever you need PaDS sfs-load it. [Shows you what I mean by dangerous. While typing this it finally occurred to me that you can probably just download PaDS, decompress it and dir2SFS the decompressed folder].

You wrote, "And also to my surprise I was able to install Rainlendar2 simply by doing a file search in Xfe and copying all the Rainlendar2 files to the clean system."

You might like this Gnewpet, https://oldforum.puppylinux.com/viewtop ... 89#p598673: - makes pets from installed packages. AFAIK, it won't duplicate settings or stored data files. But it will generate a pet including all the components in their proper places from the application's 'catalog' in /root/.packages. You can later decompress that pet, add the files, folders, and customization you created on your current system to the decompressed folder and then dir2pet/ or SFS that folder. Might save some time and labor.
Edit: I forgot that at some point I thought gnewpet was so generally useful that I re-published jpep's creation as an AppImage. viewtopic.php?p=18174#p18174. I was going to make certain the original could be found from the Additional Software Section when I found it.

[geo_c]

Shows you what I mean by dangerous. While typing this it finally occurred to me that you can probably just download PaDS, decompress it and dir2SFS the decompressed folder.

You wrote, "And also to my surprise I was able to install Rainlendar2 simply by doing a file search in Xfe and copying all the Rainlendar2 files to the clean system."

You might like this Gnewpet, https://oldforum.puppylinux.com/viewtop ... 89#p598673: - makes pets from installed packages.

Thanks @mikeslr. I have to do bread and butter work today, but I'll be working on all of these tasks throughout the week. Right now I'm typing from my clean system. I currently have two jackalpup saves to work from: thinjack and fatjack as I aptly named them.

I almost feel a new thread branching off of this one, maybe titled Pupsaves: Migrating to a fresh system. Last night I encountered some difficulty getting my wireless router connections, so this morning I scoured fatjack and looked for the necessary modules. Once I figured out the proper directory to copy the module libraries, I unloaded the failed module and connected using Barry's Simple Network Tool which instantly worked! I was a getting a little frustrated, as Fossapup has never worked with my laptop's installed realtek card (and I believe it's probably realtek's fault from what I remember from past searches and attempts) so I've always used a Ralink USB wireless dongle, which has never given me any problems, but I didn't remember how I initially installed it -- which goes to show how much we take for granted after a system is up and running. At any rate copying the modules to the proper locations solved the issue, and seemed to improve the situation, because I don't remember being able to connect with the Simple Network Tool in the past, I always had to use Frisbee.

so, I'm happy again. My thinjack pupsave backs up in a matter of seconds, I'd say 10 or less, whereas fatjack takes about 10 minutes to back up at this stage.

Which has me thinking about browsers, even the portables, their profiles and caches and where that's all stored, though I probably had a few zip archives and such lurking around in /root. The other factor contributing to fatjack's enormous size is probably Musescore and installed browsers using qt libraries and soundfonts that are all stored in the base system. I actually use portable Musescore at this point, and never uninstalled the package manager version for fear I might break QT5 if it was used by something else. When I view my installed packages in the package manager and see numerous libraries, I get a little skittish about uninstalling things.

[geo_c]

Hi @mikeslr

So using an expendable thinjack pupsave with no xfe installed, I installed the sfs/create portable pets, the Sylpheed packages, and ran PaDs, but I was missing a few Sylpheed libraries which I discovered by using the terminal method you outlined. So I deleted the sfs, and tried downloading the Sylpheed packages again. However, I believe I rolled an extra and perhaps quite large application into the mix called, 'sylph-searcher' which says it's a tool for searching text in mail folders. I thought perhaps the libraries and this application were linked. PaDs took quite awhile to organize the sfs and give me the dialogue screen. And now mksquashfs is building the sfs, which to my surprise is running all four of my cpu's at 98% for the last 25 minutes or so. Fortunately this machine doesn't generally run hot.

and.....

Holy crap this sfs is 1.3gb. That can't be right... but does it work?

Hey! It fires up and runs. I haven't hooked up an account yet, but everything looks right. I guess this 'sylph-searcher' app uses sql and must be seriously bloated. Perhaps I should try again without it. On the other hand, I should run it first and see if I like it. As an sfs, or eventually a portable or AppImage, why not?

I'll use this pupsave called thinjackMOD to do all my sfs/portable/appimage creation. Or maybe I'll save it as thinjackAPP and use saves of thinjackMOD to experiment and break things with.

post script note:
Sylph-searcher is a Sylpheed application that searches MH mailboxes and Sylpheed mail, but I have no idea how to use it. It has to be configured to a database, but there are no help files or hints of any kind. Still, it looks useful. I think I'll keep it.

And though I decided to keep the humungous Sylph-searcher (as an option to mount when needed), I also made a sane sfs of just Sylpheed, which took only a brief few minutes and runs great. I thought that having a giant sfs to run Sylpheed was anti-thetical to what I love about it in the first place, it's small size and speed.

[mikeslr]

1.3gb I thought that was very odd. But then --under Bionicpup64 [still my daily driver]-- when selecting just sylph-searcher in PPM's Search I got this:

sylph-searcher.png (35.88 KiB) Viewed 1912 times

Well, good to know that PaDS didn't die from acute indigestion.

By the way, I keep my SaveFile's relatively small by making extensive use of SFSes, AppImages and Portables*. The latter two can be located anywhere --such as within /opt-- but I place them in a folder on /mnt/home. I named it Pup-Apps and created a Rox Bookmark to it. Things on /mnt/ANYWHERE are not included in a SaveFile or SaveFolder. I'm not even sure if SFSes will function if you locate them within 'Puppy-Space'.
MikeWalsh's recent portables include a script which will create menu-entries no matter where you place their folders. For other portables and AppImages, if I use them often, I'll create my own. Otherwise, the rox bookmark suffices.

* The only things which have to be 'installed' are those unique to a Puppy. For example, I have a portable MasterPDFEditor. It, and several other portables, have Qt-lib dependencies. Although if need be one distro's version of Qt can sometimes/often/but-not-always be used under another --such as Slackware's under Ubuntu-- it's usually more efficient to just use packages in Puppys from their 'binary compatible' distro. Examining MasterPDFEditor's binary with ListDD under each Puppy tells me which libraries it needs. Those are installed. Then all the Puppys can use the one MasterPDFEDitor portable.

[geo_c]

By the way, I keep my SaveFile's relatively small by making extensive use of SFSes, AppImages and Portables*. The latter two can be located anywhere --such as within /opt-- but I place them in a folder on /mnt/home. I named it Pup-Apps and created a Rox Bookmark to it. Things on /mnt/ANYWHERE are not included in a SaveFile or SaveFolder. I'm not even sure if SFSes will function if you locate them within 'Puppy-Space'.
MikeWalsh's recent portables include a script which will create menu-entries no matter where you place their folders. For other portables and AppImages, if I use them often, I'll create my own. Otherwise, the rox bookmark suffices.

I also have a dedicated directory located on the home drive called 'portableAPP' which has about 15 portables and appimages, along with a library of sfs's not currently in use. The reason my pupsavefiles were getting so large has a lot to do with the fact that I installed some large applications before finding the portable versions. A couple like Musescore and gimp had large media files, along with appimage browsers like LibreWolf that might be storing caches and other files in the save. Also pets from ppm that uninstalled, like browsers that probably left files around that I never located. At the moment I'm mulling over the consequences of using appimages and sfs's as opposed to@mikewalsh's portables that symlink instead of copying files to the save. Sfs's, like LibreOffice seem to store a lot of files in the pupsave.

thinjack currently has only a few utilities like JWM 3 installed, along with LibreOffice, Sylpheed, and Tor-browser mounted as sfs's, yet already the savefile is 680M, and maybe some of the fat comes from files added by appimages I've run.

At the moment I'm booted in fatjack and decided to poke around to see what I can find, and I noticed the '/.cache' directory. Appimages like wine have around 150M cache files and the others seem to be about 30M here, 50M there. And I suppose it just all adds up after awhile.

As @mikewalsh often points out, modern hardware and storage is such that the file size isn't such a problem, and the real issue for me is backup time, and migration. The less dependent the base system is on files in the pupsave, the easier it is to migrate to a fresh boot, or different distro version altogether.

post script note
I may have forgotten to mention I that a made an sfs of Xfe and imported the config files from fatjack and it's running rather nicely in thinjack as an sfs, completing the migration process in under 24 hours and reducing the size of my savefile from 4.6GB to 680MB. The only real grunt work involved would be the manual copying of config files and themes, as well as resetting some symlinks and icons. Symlinks and their icons seem to be one thing that is hard to move in linux. Most of my symlinks (launchers) are relative links, and I thought that would be the sure bet, but some of them broke n the process and had to be re-linked.

[geo_c]

And now I have added the portable-appimage version of sylpheed to my arsenal.

Thanks @mikeslr

I'm pretty jazzed about making appimages and sfs's.

[mikewalsh]

@geo_c :-

Heh. Y'know, it's all relative.

I would guess that, over the years, many of us have come up with all kinds of 'work-arounds'.....to fix hardware issues.....to work around hardware constraints (CPUs, RAM, storage, networking, etc, etc.).....and sometimes simply to make our work-flow easier & more consistent.

A good many of us like to share our experiences - and what works for us - with this amazing bunch of people we have in the community. And of course, this then 'sparks' some people off at a tangent, thinking about something else, which may in turn evolve into something else that ends up benefitting the community.

-----------------------------------

For me, the whole concept of portables dates all the way back to the latter days of XP. I discovered PortableApps.com; over a period of time, I experimented with a good many of them. The Redmond 'beast', of course, needs regular re-installing to clear the cruft out.....or it used to, at any rate. For my last couple of re-installs before I said "Enough is enough", rather than going through my usual re-install routine, I used portable applications wherever I could. And the whole OS became so much sweeter to use, less cumbersome, more responsive.....and it stayed like that.

A lot of stuff, I simply ran from a couple of the largest flash-drives I could find. Later, I moved many of them onto an external USB HDD (larger capacity, just as portable).

Fast-forward to today. It took a few years, but I eventually became comfortable enough with Puppy to want to start doing constructive stuff with it.....on top of which, I wanted to give something back to this amazing community that had given me so much help. I've packaged a whole bunch of stuff; so much, I can hardly remember half of it. Yet, floating around in the back of my mind had always been the idea of wanting to replicate what I'd done in XP's latter years on Puppy itself.

Browsers were the first things, because they're the one thing no online community can do without; they're the 'glue' that binds us all together, and keep us in touch with each other. Yes, there's a lot more to computing than just the internet, but it's astounding how central this huge interconnected mess of electronic wizardry has become to our lives, isn't it? So much so, that some companies have moved their entire business model on-line. Adobe, for one.....so they can milk you continuously, unceasingly, never-endingly.....or at least for as long as you NEED to use their products.

----------------------------------------------------

I can't take all the credit for these portable packages, not by a long chalk. In so many ways, they've been a community effort; many folks have either helped out directly with code additions/modifications that have made scripts do what they're supposed to, or else with suggestions & tips to simply make them more usable. And of course, my own scripting skills have improved to the point where I feel comfortable adding stuff of my own devising......

The only thing I'll take credit for is that of assembling all this stuff into usable packages.....because if they're usable, I'm happy to run them myself. If they work for ME, I'm then happy to share.....but I will always give credit where credit is due.

My Puppies are starting to get to how I envisaged them, several years ago when I first joined the Puppy community.

-------------------------------------------------

As for the comment about space not being so important anymore, well; again, it's relative. My previous rig was inherited from my sister when she moved from XP to 7; as a 2005-vintage machine, it WAS pretty limited. I upgraded it to within an inch of its life, but was always limited by the fundamental DDR1 4 GB maximum. With this new rig, not only have I now got a way more powerful, efficient, far faster and less thirsty CPU that'll run rings around the old one in terms of what it can do, I've been able to 'max' the board out all the way to 32 GB of DDR4 RAM. I have so much more space to play with now, the sense of freedom it gives is quite intoxicating at times!

DDR5 is almost upon us.....and they're already working on DDR6 in the wings. Over the next 2-3 years, 64-128 GB of RAM is going to become commonplace. So, no; space is NOT the constraint it once was. Trouble is though, it encourages lazy coding.....

I could run pretty much any OS I wanted on here. But even though this current rig is no longer really a 'Puppy box', I stay with Puppy 'cos I'm used to it; I know what I'm doing with it; I like the way it works and its philosophy of how it does things.....and above all else, I love this community of ours, and the people in it.

Like I say, it's all 'relative'.....and, talking of which, you might find that your sym-links survive better if you make them 'absolute' links as opposed to 'relative' ones. Because an absolute link uses the full $PATH, it doesn't matter where it goes, it still finds its target, whereas a relative one has to remain "in relation to" its target (not the correct way of looking at it really, but it's how I think of things!)

Mike.

[geo_c]

Thanks @mikewalsh, I always enjoy your long posts.

In my brief experience of using the Create Portables utilities I already have my go-to daily applications in portable format, Sylpheed, Xfe, QuiteRss, RainlendarPro2.

I was running into issues with my newly created thinjack pupsave. I botched up the wireless settings somehow so that only Barry's Simple Network Setup would see it. So after some hair pulling last night, I just decided to start the whole OS over. Thinjack was up to 1GB, 1/5 the size of my older bloated fatjacksave. At any rate, I started over and set up the clean working wireless right off the bat, and I think the original problem arose from the question that Network Setup asks about whether to list the module as 'working with WPA.' You have to choose 'YES.'

So I started over, and wow, it was worth it. I stored every relevant folder related to my system in /mnt/home/geo-settings by mimicking directory locations using dashes instead of slashes, so I stored relevant directories from /root/.config in a folder called /root-.config and so on. Then I just copied config files after loading the sfs's and portables, along with configs for jwm and rox, bookmarks, etc. In the end I got the whole thing equally as functional, theme-tweaked, and app-loaded as the original bloated fatjack pupsave, and all in a whopping 3 hours, with all of my accounts and personal application settings in tact. The new pupsave is much smaller than my first thinjack try to the point that my new OS is called: microjack weighing in at a whopping 400MB.

And it's fast!

I also realized it isn't so much that my relative links busted, because I actually keep them all relative to the /mnt/home location, so they aren't actually moved in that regard, what doesn't transfer are the icons for the symlinks. Those I had to reload by hand.

As I make sfs modules, I should probably make them available as a download at some point. They seem to work well.

Because @puddlemoon 's jackalpup is so feature rich to begin with, and @mikewalsh's portables are in full use, this OS is massively powerful in functionality and backups in about 10 seconds or less.

In the first few years of using puppy, I never imagined it would get this good.

[geo_c]

There's a third possibility you should know about. I'm in the process of writing a "Tip" about when to Remaster, and alternatives. But the short version is this:
amethyst --formerly known as nic007-- published a Utilities Suite which includes a module --Save2SFS--for creating either an adrv.sfs or a ydrv.sfs --or sequentially both. Both adrv.sfs and ydrv.sfs would be 'READ-ONLY'. The module uses as its source your SaveFile or SaveFolder plus whatever applications you've installed but haven't yet Saved. If you don't have a SaveFile/Folder, it just uses the last.
After you create an a-or-ydrv, you can delete your SaveFile/Folder or move it so that it won't be used --safer if you find a problem and have to revert. If you want you can create a new SaveFile/Folder and continue exploring, or boot into a READ-ONLY OS; or create two menu listings --one using the pfix=ram argument-- and choose either.
The latest version is here, viewtopic.php?t=1694
Earlier discussions on the 'old-forum' can be found here, https://oldforum.puppylinux.com/viewtop ... lities&i=1
All of 4 pages, total.
Using Save2SFS is both faster and less error-prone than remastering. The reason it works is that all Puppies will, on boot-up, use both adrv.sfses and ydrv.sfses if they are present; and because of priorities given such files: "Always remember the pecking order: savefile contents > adrv >ydrv">Puppy_Version_#.sfs. That is, your SaveFile has the highest priority. Its contents will always be used. Non-Conflicting contents of adrv.sfs will then be used; then non-conflicting contents of ydrv.sfs and lastly non-conflicting contents of the applications the Dev built into the Puppy_Version_#.sfs.
There are still some reasons to remaster; and amethyst's Suite provides applications for that. They, also, are less prone to human-error and faster than the builtin application.

Okay, I have taken the plunge and decided to try a ydrv.sfs. I did a standard remaster using the built in utility which came out pretty nice, incorporating all my recent sfs applications and rox options, icons, etc. It didn't transfer the Cairo Dock or desktop background, or any of my application configurations, which I decided not to do.

So after that I went ahead and loaded NicOS Utilities and I made a ydrv.sfs from my recent thinjack pupsave. However, being that I'm on jackalpup, a remaster of Fossapup, I'm wondering how the adrv.sfs being rolled into the new ydrv.sfs is going to react, since I was reading the threads you posted, and there were some issues involving adrv.sfs.

Since I have a usb install in addition to my hard drive install, I will copy the ydrv.sfs to the usb system and see what happens.

[geo_c]

@mikeslr

And that was a cool, but a fail. Still kind of a cool fail. I combined the adrv.sfs and ydrv.sfs in Jackalpup, which is more or less just Fossapup64 remastered. The first eye opener was the fact that it combined the stock cairo dock with my personal cairo dock. Two of everything. The second eye opener was realizing how fast the system responded because it was all running in ram I suppose. And the third eyeopener is the fact that all my links to portable and sfs applications were useless because there was no /mnt/home because there was no pupsave.

So, I like the speed of using a read only system. That's for sure.

As for portables, I would still be needing to launch them from a savefile, unless I linked to a particular drive and made a dedicated ydrv.sfs for that drive, say one for sda1, and one for sdb1, etc... unless there are other options I'm not considering. Which is okay, I'm still planning to use a savefile.

And that raises a lot of questions about how to structure things. Seems maybe the best way to go about it is to remaster a personal system with themes, apps, and system configs all present, but absent of portable launchers, and personal account settings. Then create a ydrv.sfs from that remaster, and make a save, install the launchers and personal settings and store those in the save.

I'll chew it on in my sleep tonight. And try again tomorrow evening.

@geo_c

[geo_c]

@mikeslr

Since I combined adrv and ydrv, is it possible just to delete adrv altogether? Or delete adrv and rename ydrv to adrv. I think that's approximately what was being suggested in the threads you linked.

EDIT:

To answer my own question, yes it is possible to remove the adrv after combining the two drvsfs's with save2sfs.

I removed the adrv.sfs from mnt/home and booted up with the combined ydrv.sfs. It seemed to be working, however Cairo dock had two shutdown buttons, and one remaining original launcher for the brightness script, and that gives me reason to pause and wonder about how I'm doing it wrong. I'll look at the Save2sfs routine a little closer and see what options I'm not taking advantage of.

[geo_c]

Hi geo_c,

While waiting for my first cup of coffee to kick in before I do anything dangerous, I re-read this thread. Two thoughts. PaDS does create a Right-Click menu listing. So there's a possibility it did create the problem you encountered. The work-around: PaDS does not use python which, AFAIK, must always be installed. And you don't need PaDS to always be available. So, after installing PaDS, use it to create a PaDS SFS. Then uninstall PaDS. Whenever you need PaDS sfs-load it. [Shows you what I mean by dangerous. While typing this it finally occurred to me that you can probably just download PaDS, decompress it and dir2SFS the decompressed folder].

You wrote, "And also to my surprise I was able to install Rainlendar2 simply by doing a file search in Xfe and copying all the Rainlendar2 files to the clean system."

You might like this Gnewpet, https://oldforum.puppylinux.com/viewtop ... 89#p598673: - makes pets from installed packages. AFAIK, it won't duplicate settings or stored data files. But it will generate a pet including all the components in their proper places from the application's 'catalog' in /root/.packages. You can later decompress that pet, add the files, folders, and customization you created on your current system to the decompressed folder and then dir2pet/ or SFS that folder. Might save some time and labor.
Edit: I forgot that at some point I thought gnewpet was so generally useful that I re-published jpep's creation as an AppImage. viewtopic.php?p=18174#p18174. I was going to make certain the original could be found from the Additional Software Section when I found it.

Again, thanks for all these resources @mikeslr. After creating a customized Rox theme as per this thread: viewtopic.php?t=4429 I'm now beginning to brainstorm a new remaster scheme, and sfs strategy.

So I'm having tangential thoughts about the subject. One has to do with the idea of creating a 'theme.sfs'. I'm considering the possibility of creating an sfs that contains folders such as /root/.config/rox.sourceforge.net and wondering if it would work to simply mount that sfs to change the ROX theme. So my plan is to try and make one, then test it on an unaltered ram boot by first creating an sfs with the directory structure of the desired system alterations, and loading it on the fly and seeing what happens. I'm not exactly sure until I try if that's even possible, but it seems probable that it could work. At that point, one could go from a personalized theme to stock install theme simply by loading/unloading the sfs, unlike using adrv and ydrv which can't be unloaded. Then these theme.sfs's could be loaded at boot, unloaded and changed on the fly. Part of me thinks that would probably make the system unstable. But maybe it would work just fine. I've been able to copy config folders in realtime and it seems to change with no hitch, though it's always good to restart X or JWM after making such a change.

~geo

[mikeslr]

Just to note that SFSes, AppImages and portables can still be used. You just have to start them by Right-Clicking >SFS-Load each session. A GUI will open asking on which partition you want to 'copy': scroll down to "NO Copy". Some SFSes will load entirely in RAM still enabling you to remove a USB-Key. Others won't: trial and error.

Portables can be located in /opt before creating the adrv/ydrv. Most SFSes can be converted to pets, then installed. Some such install will conflict with other 'installed' applications. Again, trial and error.

[geo_c]

Just to note that SFSes, AppImages and portables can still be used. You just have to start them by Right-Clicking >SFS-Load each session. A GUI will open asking on which partition you want to 'copy': scroll down to "NO Copy". Some SFSes will load entirely in RAM still enabling you to remove a USB-Key. Others won't: trial and error.

Portables can be located in /opt before creating the adrv/ydrv. Most SFSes can be converted to pets, then installed. Some such install will conflict with other 'installed' applications. Again, trial and error.

I did another remaster last night using the NicOS auto-remaster script, and I was pleased with the results. Cairo dock had a couple of double entries, but everything else seemed to work. Sfs applications were rolled into the new system, etc.

But, the script broke my pupsave from which it is was run. Fortunately I backup my system everyday.

The remaster runs fast, which is cool, has all my personal settings in it, which is also cool, but it takes up twice as much ram, 2.5GB as opposed to 1.2GB. So I'm still tinkering to find the right balance.

[geo_c]

For anyone who might want a Sylpheed.3.7.0.sfs package, see this thread:

viewtopic.php?t=4514