Should the terms 'Frugal' and 'Full' be changed, to what & how

[rockedge]

@tosim Is it alright in this form? Does it make any impact?

viewtopic.php?t=6953

[tosim]

@rockedge MOST DEFINITELY! I'm glad to see you've locked it. Many thanks.

[esos]

In general pups/dogs work in frugal mode as root.
It can be install manually by extract the ISO contain to a folder in a partition medium like internal/external hard drive, pen drive etc. and figure it out bootloader to make the system working. Partition type or format is neccessary to install a OS. It is so many steps for frugal installation particular confusing for new user, so the developer create, I think it call "puppy installer" to make easy installation for any user.
The advantage of frugal installation is you can do multiboot in one partition with so many OSs in it as you wish.
Persistence data is just additional feature to the OS (Not all developers provide this feature)

Not sure who first introduce "Frugal" maybe puppy, but frugal or poorman installation is common in linux world like ubuntu, debian and any others and some provide with persistence data also, but some of them work on second partition only, thats not good for multiboot purposes.

The other characteristic of Frugal is normally portable also.

ISo live medium is bootable ISO file and can run/load the OS without installation until you see the desktop and use it as as normal system and you are lucky if it provides with persistence data (some work by design).
Almost all ISO live is possible to boot as frugal also.

Ubuntu, debian and others by design provide or offer Full installation of OS base on their recommandation. Normally Installation neccessary in one specific partition and normally this partition is not to be share with other OS.

In my understanding "Full" or "Frugal" is NOT the same.
I have no reason to change Frugal.
Frugal is just a name with specific characteristic, I mentioned above.

Good luck with other name but it will not change the installation style.

[rockedge]

@esos The installation type names will not change. We'll just define it properly in obvious places.

I think more get it the idea than not. But we'll try to provide good explanations in easy to see/find places until the next generation will know the differences.

When Puppy Linux catches interest not many will care about if "frugal" is the right descriptor.

[mikeslr]

So, I finally got around to doing what I said: ran Puppy Install to see what information it provides. I did that running Bionicpup64.

Questions.

1. Is this statement correct? “Puppy Installer” is an application included in a Puppy via Woof; consequently only by changing Woof can the text displayed be altered?

2. Or using Woof can a Puppy Creator exclude ‘Puppy Installer” or modify the text it displays?

3. Does anyone know of any application other than Puppy Installer by which newbies are likely to deploy Puppys to create a Full operating system?

4. Does anyone know if other, still supported, Puppys display any text other than what appears on these images?

The following are screenshots taken of the GUIs while running Puppy Installer. There numbers reflect the sequence with the 2nd and 4th GUI absent because not relevant to the question. [Sorry, you'll have to click the images to actually read the text. I have not yet digested the tricks to using postimg.cc. Suggest Right-Click > Open in a new Tab.]

1

3

5

@ Wizard, tosim and rockedge: Nice synopsis. viewtopic.php?t=6953&sid=d491c7a56bdc3f ... fa2843978b

I’ve never done a Full install. There are only two things I know about it from reading the posts of others.

1. They are almost impossible to repair if something goes wrong.
2. When compiling applications or rendering videos which involve changing codex or containers a Full install significantly reduces the time required.

Is any of that true? How true? and should any of the above be included in rockedge’s post?

While there’s no way to change the content of ISOs already ‘in the wild’ that doesn’t serve as a justification for continuing to perpetrate a problematic condition. And while rockedge’s post goes a long way to dispel misconceptions about Full and Frugal, how do you get newbies to read it?
All we can be certain of is that the person using Puppy Installer has the information that Puppy Installer provides. The above screen shots show that Puppy Installer already provides some advice. Is it sufficient? In partiulcar, note that the 3rd screen shot displays this about Full: ”...Use only if there is not enough RAM and the CPU is too slow.”

Fossapup’s OP, for example, states “approx minimum System Requirements: 2007 era 64bit core2duo cpu & 2gb ram” https://www.forum.puppylinux.com/viewto ... 5464#p5464 (Emphasis supplied). Someone might assume that a Full install would significantly lower that minimum. But you know what they say about ‘ass u me’. Would a Full Install significantly lower the minimum RAM requirement?

I note rockedge’s post uses color to emphasize some information and attract attention to it. The first two screenshots reveals that color and bolding can be employed in the text displayed.

If the only way to create a Full Install is via Puppy Installer running from a Puppy, then there’s a good chance the User already has an internet connection. Could a ‘Help’ button trigger the opening to rockedge’s post?

All of which lead back to the questions “How can we effect that change?”

[geo_c]

Fossapup’s OP, for example, states “approx minimum System Requirements: 2007 era 64bit core2duo cpu & 2gb ram” https://www.forum.puppylinux.com/viewto ... 5464#p5464 (Emphasis supplied). Someone might assume that a Full install would significantly lower that minimum. But you know what they say about ‘ass u me’. Would a Full Install significantly lower the minimum RAM requirement?

Not to hi-jack the topic, but it strikes me as funny that the miminum is listed as such, because I run a small laptop with a single celeron 1.6mhz processor and 2gb of ram, and fossapup runs fine. However, I can't really watch youtube videos comfortably, but that's the browser resource and not the operating system. Plenty of other stuff like checking email and so forth is totally functional on that minimal system. I don't believe doing a full install would help that situation a whole lot, but I never tried. Maybe I should do an experiment on it.

[Jasper]

Hi all

I came across this thread and would see myself as a "newbie". There are a large number of posts within the thread and I will be honest to admit I have not read all of them.

I wanted an OS that was light in resources but still have a purposeful repository of applications available to me if I wanted to add as and when required.

My preferred method of using the Puppy was to have it self-contained and therefore not interfering with the existing OS ie Windows.

My understanding of the term "Frugal" was that it would provide me with everything but the only restriction was that it was contained in a space limited by myself eg DVD-RW or USB flash drive.

Also, I thought the only benefit for having a "Full" installation was that it would allow me to create a Swap partition that would be used in the event that I run out of RAM.

My concern was that in the event that I made errors or messed around with the OS that I would break it and it would become unusable and I could not rollback the changes.

[wiak]

Also, I thought the only benefit for having a "Full" installation was that it would allow me to create a Swap partition that would be used in the event that I run out of RAM.

My concern was that in the event that I made errors or messed around with the OS that I would break it and it would become unusable and I could not rollback the changes.

There is so much misinformation on this forum it reminds me of social media in general!

Full install certainly allows use of swap. Also, when things go wrong it is certainly 'repairable' if you understand the system well enough - you can't repair a car if you know nothing about car mechanics!

But i think you are referring to using rollback as a way a non-technical user can easily roll back to a previous working state after breaking a distro at some stage?

Unfortunately, I don't believe Puppy Linux itself has that ability in its design (except in the sense you can delete your save folder or save file and get back to the start... or use a copy of the save file/folder if you happen to have made one). Unfortunately a save file or save folder is uncompressed so can become pretty big over time, so backing it up is not the dream solution some make it out to be. Nevertheless, you can avoid that issue to a large extent if you remaster your Puppy distro once you have built up the system to the way you want it and that way keep your save file or save folder very small.

If you mess up a full installed distro - well, you can just reinstall that and you are 'back to the beginning' again too! However there is generally not any easy rollback mechanism at all except for whatever the distros package manager provides.

It is true though that in principle frugal installation can with some distros be implemented such that you do get proper rollback support. KLV-Airedale (and some others), for example, does provide easy rollback capability, but currently that has to be arranged manually - a simple utility could be written to automate that rollback facility though; I have no doubt at all that would be a very useful facility to work on as both an alternative and an enhancement to full remastering (you can for example merge rollback files, but not necessarily all of them, for use with KLV-Airedale - and not simply do a full merge/remaster). A particularly useful feature with KLV in practice is that, again, rollbacks can be left as uncompressed directories or made into squashed filesystem sfs files (to save storage space) or a mixture of these.

[geo_c]

Also, I thought the only benefit for having a "Full" installation was that it would allow me to create a Swap partition that would be used in the event that I run out of RAM.

A swap partition is no problem with a frugal install provided that you are partioning the drive in the first place, I suppose it would be more difficult with a windows dual boot, though I seem to remember that if I booted from grub on a USB thumb drive into a frugal install residing on windows partion, and the grub thumb drive had a swap partition formatted, then puppy would load the swap also.

Unfortunately a save file or save folder is uncompressed so can become pretty big over time, so backing it up is not the dream solution some make it out to be.

A particularly useful feature with KLV in practice is that, again, rollbacks can be left as uncompressed directories or made into squashed filesystem sfs files (to save storage space) or a mixture of these.

I make a backup copy of my save folder at least once a week. Then I move those backups to a USB drive and only keep save folders with significant changes, thereby creating a rollback archive. Yes it takes space, but good back up practices tend to use storage space. I usually just keep two folders on my working partition, the current, and the most recent backup. Very handy. I can experiment, break things, and reboot into the backup, immediately make another backup, and delete the broken current folder, all in the space of a couple minutes.

I just tried this with KLV, and that does not work, or I did something wrong, but at any rate, when trying a couple times with KLV, XFCE gave me an authorization message on boot, and unmounted drives refused to show up anywhere in the file structure. So I realized there's more to it with KLV.

I could benefit to know the procedure for rollback in KLV, which would allow me to setup a working daily driver easier.

[wiak]

I just tried this with KLV, and that does not work, or I did something wrong, but at any rate, when trying a couple times with KLV, XFCE gave me an authorization message on boot, and unmounted drives refused to show up anywhere in the file structure. So I realized there's more to it with KLV.

I could benefit to know the procedure for rollback in KLV, which would allow me to setup a working daily driver easier.

Well of course you can make a copy (or copies) of your upper_changes save folder or upper_changes.ucimg save file with KLV. Why on earth would that not work? An exact copy is an exact copy!

But yes, constant copies of whole upper_changes is a pretty rough rollback mechanism (I wouldn't really call that rollback - terminology again... rather it is a complete copy of previous system state, when merged with pristine rootfs, whereas a more sophisticated rollback system is more incremental in the way it works). Would work though; in Puppy or in KLV - you must indeed have done something wrong though I don't know how since that method is just a straight backup copy (or copies).

Much easier method available with KLV (just add a 2 digit number to the upper_changes folder, say starting at 50upper_changes, and on next boot that will be used as top read-only layer and a new upper_changes (without 2 digit number) will be auto-created for top read-write layer. Then when you want to make a new rollback point just rename that upper_changes to 51upper_changes, or simply, say 51rollback - whatever - only the 2 digit number is important to specify order of the rollbacks - can otherwise call the folder whatever you like, and/or make it into a sfs file if you want to save space).

Of course there is a caveat to any rollback mechanisms - if a reliable package manager is involved or used on your system - it will build its own database of what has been installed or removed. However you arrange rollbacks must not damage the package manager database. So, for example if you had a 50change, 51changes followed by a 52changes and finally the read-write upper_changes, you couldn't suddenly delete, say 51changes and expect all to remain well - you must keep the logical progression intact since packages will likely be added and the pkg manager database needs continuous rollback progression. Hence you would delete top upper_changes first, and then 52changes if you also wanted to rollback before that, and so on.

[rockedge]

@geo_c The roll back method in KLV is relatively straightforward. Simply renaming the /upper_changes directory to /NNupper_changes as in something like /51upper_changes will let KLV know to create automatically a new /upper_changes and any new perisitance after the /51upper_changes is created will go into the new upper_changes directory. There can be an entire chain of /51upper_changes, /52upper_changes, /53upper_changes and then the most recent will be /upper_changes.

Also possible is to squash these NNupper_changes into something like 51changes.sfs, 52chnges.sfs. A former member of the forums once wrote a pair of simple scripts that can be used when KLV-Airedale is run in RAM0 that will save the changes and write them to a NNchanges.sfs file which increment in number like 51changes.sfs, 52changes.sfs, 53changes.sfs each time the save.sh script is called. Then using a mergechanges.sh script that takes all of the SFS save files and merges them into one named 50changes.sfs

All of the numbered SFS file will load at boot. Any numbered uncompressed directories will be loaded at boot. A custom roll back mechanism could be created to handle this in a user friendly way fairly easily but I have not made such tools yet.

Otherwise just squash the /upper_changes manually and save as a backup or copy uncompressed a backup of the /upper_changes and set it aside on a safe place. I have used the same /upper_changes and just kept swapping in the new 07KLV-airedale_rootfs.sfs

The w_changes=RAM0 mode I tested with those save.sh and merge_changes.sh scripts and that works but is no where near being production ready.

@dimkr No, there is no automated build system to update and/or repackage the KLV specific packages. At this time this is a manual method that I use to configure KLV to be a KLV-Airedale. This is a solution to the question of "how does one setup a KLV-Airedale automatically?".

That's the beauty of the build system, lots of hands on control and invention in a straightforward way. Sky's the limit as they say.

[wiak]

A former member of the forums once wrote a pair of simple scripts that can be used when KLV-Airedale is run in RAM0 that will save the changes and write them to a NNchanges.sfs file which increment in number like 51changes.sfs, 52changes.sfs, 53changes.sfs each time the save.sh script is called.
...
The w_changes=RAM0 mode I tested with those save.sh and merge_changes.sh scripts and that works but is no where near being production ready.

Yes, let's be fair about this - that was rufwoof in his better days and he wrote that way back in 2019. However, no-one taken that task on since - so definitely a lot to be done there to make that ease of rollback mechanism 'production ready'...

[puppy_apprentice]

Also, I thought the only benefit for having a "Full" installation was that it would allow me to create a Swap partition that would be used in the event that I run out of RAM.

With Frugal there is no problem to have swap partition or swap file.

[geo_c]

So, for example if you had a 50change, 51changes followed by a 52changes and finally the read-write upper_changes, you couldn't suddenly delete, say 51changes and expect all to remain well - you must keep the logical progression intact since packages will likely be added and the pkg manager database needs continuous rollback progression. Hence you would delete top upper_changes first, and then 52changes if you also wanted to rollback before that, and so on.

Thanks @wiak, that right there was the problem I believe. I just add-hock deleted the rollback saves in between and renamed an earlier backup to upper_changes again.I forgot about the numbering system.

edit: removed extraneous info for clarity

I see how it works now, the highest number is copied to upper_changes along with the lower numbers, so I could go back 5 versions as long as I delete upper_changes and the 4 versions below that, and let KLV load the highest number as upper_changes.

[rockedge]

I see how it works now, the highest number is copied to upper_changes along with the lower numbers, so I could go back 5 versions as long as I delete upper_changes and the 4 versions below that, and let KLV load the highest number as upper_changes.

Yes that's it. If one does not want to delete the NNupper_changes it can be renamed by removing the 2 digit NN from the prefix position.

examples:

Code: Select all

/51upper_changes.sfs  -> /upper_changes51.sfs
/51upper_changes -> /No-51upper_changes

I have a testing version called KLV-Boxer-alpha2 that is a KLV but uses a jwm+Rox desktop instead of xfce4. This is one of the most modular setups of that type with many of the default packages being supplied as SFS files contained in the base ISO or system root. Notice how each is numbered in name indicating to the initrd.gz to load them during the boot phase. The JWM+Rox version has plenty of room for improvement especially porting over Puppy Linux JWM customization utilities to work in KLV-Boxer for easy desktop appearance and structure changes. KLV-Boxer is one of the most efficient distro's there is but it is in a early alpha stages of development and I am working more on KLV-Airedale because of the more polished xfce4 desktop and is much further advanced with assimilated technology borrowed from DebianDog(s) and Puppy Linux distro's. Hence the name "Kennel Linux". Any distro that is boarding at the kennels and has a good idea has potential of that idea being borrowed and jammed into a KLV.

Screenshot(25).png (47.12 KiB) Viewed 921 times

I refer to these installations as "frugal" when describing how they are structured on a storage medium. Seems like the single word describes what it takes a page of text to detail. Frugal as in resource demand is lighter than the full install type. I have not done a full install other than Windows XP and Win 7 on VirtualBox machines on virtual HDD's in any way in about 12 years.

[puppy_apprentice]

Is this working like in Porteus .xzm modules?

porteus.jpg (32.01 KiB) Viewed 909 times

porteus2.jpg (41.13 KiB) Viewed 909 times

[Jafadmin]

For my $0.02 I think they should be changed to "Happy" and "Cranky". Hopefully this settles everything ..

[mikeslr]

In college two friends and I took a course given by a professor who had a phenomenal grasp of the subject. He could lecture for an hour and half after only referring to his notes at the beginning. Unfortunately, although he would start talking about one thing, it would remind him of something else. He'd begin talking about that, but diverge when reminded of something else. My friends took copious notes. I took none, just sat back and enjoyed the performance. He reminded me of Professor Erwin Corey.
https://www.youtube.com/watch?v=RHlLmYVCzKY
https://www.youtube.com/watch?v=MxtN0xxzfsw
I figured I'd read the course material and a couple of 'outside' books.
My friends did much better than I on the mid-term. So I asked them how they studied for it. One explained: "We got together, tore our notes up into strips, tossed them in the air. Then, like a jig-saw puzzle we reassembled them, but thematically.

We seem to have diverged, again.
The object of this thread was to try to figure out what can we do to prevent newbies from inadvertently selecting a 'Full Install'.
Jasper's post, https://www.forum.puppylinux.com/viewto ... 529#p68529 was important --not for the details about the specific misunderstanding he had-- but for wiak's clear response, "There is so much misinformation on this forum it reminds me of social media in general!", https://www.forum.puppylinux.com/viewto ... 531#p68531.

How can we get newbies to not start out on the wrong path. It may be a question like this one,
https://youtu.be/PZgIDEdNzQs

I am even more inclined to go along with the suggestion by amethyst and someone else: Remove the capability to initiate a 'Full Install' from Puppy Installer. .

Perhaps provide an application, downloadable from a thread on the Forum, which thread would have all the pro, cons, cautions and advice we can provide. At a minimum, anyone believing that a Full install was what he or she needed would have to ask, or searching find that thread and the discussions about "Full Installs".

[puppy_apprentice]

Currently we have this:
viewtopic.php?p=68395#p68395
And i think that this info will be in LMPro article so we have to wait for new users (readers) reaction before we make changes.
Plus above info or this:
https://puppylinux-woof-ce.github.io/install.html
should be included in next ISOs.

[bigpup]

I made this an issue at Woof-CE web site, but I am not sure, this is the place, that can change this.
Really, all the different installers, that are in a Puppy release, just need to be edited to remove full install, as an install option.

Even when it was originally offered as an install option. It was only to maybe help people with very, very low amounts of RAM. ( a frugal install can provide low RAM usage, using boot option pfix=nocopy)
Also because Puppy Linux always gives you choices.
But to provide full support for a full install.
Puppy needs to have extra code in the operation processes to support it.
Who is keeping up with this code to make sure it still works 100%?

Full install is no longer needed as a way to install Puppy.

Installs should only be offered as two ways:

Burning the contents of the Puppy ISO to a CD/DVD or placing ISO contents on a USB stick, SD card.
A frugal install to any type drive, that has read/write ability. (USB, SD card, SSD, hard drive)

All the features of Puppies operation, are only available, with these type installs.

Full install prevents, some features from being used. They will not work, in a full install.
Time to stop providing that install option.
Plus, no one is even making sure, Puppy releases, even work 100%, in a full install.
Yes, there can be issues.

Full install option, should be removed from any of the Puppy installer programs, that are provided in any Puppy versions, now being developed or released.

[wiak]

Is this working like in Porteus .xzm modules?

I don't know the working details of Porteus at all, but I just checked their website about .xzm modules and note they are squashfs files but for some reason I don't know Porteus doesn't use straight mksquashfs to produce them but instead some utility called dir2xzm and similarly xzm2dir to uncompress them. I'm not sure therefore what that is all about - the utility naming reminds me of dir2pet in Puppy Linux, except apparently squashfs files. The .tgz components TinyCoreLinux uses to build up its distro filesystem are also squashfs files, but TCL doesn't use aufs (or overlayfs) but instead symlink method of merging everything together (which overlyfs-based distros on this forum are now similarly using to implement sfs-load when not using aufs).

In KLV you don't need to squashfs them up at all - can just leave addon layers as uncompressed directories, or optionally you can make sfs files out of them to save storage space. To make KLV addons get added into the overlay merge you simply make the directory name (or the sfs file name) start with two digits (NN) to indicate what layer position you want it merged into the overlay at. Hence to disable that addon you simply don't use NN at the front of the name (I usually just stick a D at the front indicating disabled - since I sometimes re-enable later by removing the D; rockedge seems to like pre-pending a NO to dir-or-sfs-file name as alternative to D, but anything will have same effect).

[puppy_apprentice]

I meant loading mods according to the numbering.

What i like in Porteus is that you can easily switch to another DM, you have to change
003-xfce.xzm-->003-lxde.xzm or use load=lxde as kernel switch.

[wiak]

I meant loading mods according to the numbering.

What i like in Porteus is that you can easily switch to another DM, you have to change
003-xfce.xzm-->003-lxde.xzm or use load=lxde as kernel switch.

Yes, seems to be. I have a memory that Debian Live uses same idea though I have no idea how they do their implementation of that. Why limit matters via fixed alphabetic modules I always wondered.

So, yes, you could easily arrange to switch the likes of DM via similar switch to what you describe using KLV (meaning for the addon layer module choice by NN numeric; don't currently have a kernel grub switch line, but just a couple of lines of extra code even a KLV user could add to their external w_init file). I think you could do similar with DebianDogs module numbering effect too.

Main difference with KLV frugal install is ability to use compressed sfs and/or uncompressed dirs as layer modules or mix of the two, and that user-editable w_init (simple text file containing commands) makes it easy for user who wants to dabble in development to simply include any addon code at any layer they so choose (doesn't even need numbered for that since can just modify the mount overlay code line directly since it is in w_init - so could have a selection of w_inits for different DM and other setups as yet another alternative DM etc... selection mechanism - only the one named exactly as w_init gets used and user can employ a symlink to point to whichever w_init setup desired; all that facility is already in KLV).

[puppy_apprentice]

Porteus is old Slax derivative. If i remember well old Slax have used similar modules too so you could make own version of Slax by selecting modules (with DE and applications) on the Slax website and later download ISO.

[wiak]

Porteus is old Slax derivative. If i remember well old Slax have used similar modules too so you could make own version of Slax by selecting modules (with DE and applications) on the Slax website and later download ISO.

Yes, I've never tried Slax, but know about how innovative it was or is; its creator Tomas Matejicek was ahead of his time (earlier than Puppy overall I think, but similar early Knoppix era also) with lots of that work so a lot of frugal install tricks introduced there: https://web.archive.org/web/20070703235 ... ngelog.php

For example:

v 3.0.24 (1th of January 2004):

- SLAX is the new name for Slackware-Live!
- Now created by Linux Live scripts

[mikeslr]

Can we get back on point?

See my posts here, https://www.forum.puppylinux.com/viewto ... 444#p68444 and here, https://www.forum.puppylinux.com/viewto ... 584#p68584.

If you guys want to discuss something else, how about starting a different thread for that?

And for what it's worth, I agree with bigpup's last post, https://www.forum.puppylinux.com/viewto ... 590#p68590

[williwaw]

I made this an issue at Woof-CE web site, but I am not sure, this is the place, that can change this.
Really, all the different installers, that are in a Puppy release, just need to be edited to remove full install, as an install option.

is there any installer choice in woof-CE that does not offer the full option?

[wiak]

Can we get back on point?

See my posts here, https://www.forum.puppylinux.com/viewto ... 444#p68444 and here, https://www.forum.puppylinux.com/viewto ... 584#p68584.

If you guys want to discuss something else, how about starting a different thread for that?

And for what it's worth, I agree with bigpup's last post, https://www.forum.puppylinux.com/viewto ... 590#p68590

We are discussing the terms frugal and full install and what they entail and mean overall (and what they might mean in the future for distros that gradually improve their frugal functionality and facilities - time does not stand still). What is not on point exactly?

I believe it has already been agreed that it is too late to change the terminology so the discussion is more general now and why bother starting a new thread on topic of frugal and full install(?) - this one does fine. Or is the announcement of some obituary of some King or Queen or something missing?

Frankly, this forum has gradually become far less active in terms of discussions about technology - a lot has now just truly off-topic (or should be there) so trying to limit and narrow perspectives on actual technological discussion is not a good idea if you want this forum to have any discussion at all! Rockedge is definitely trying to increase scope for discussion before it all grinds to a halt, so any old-timer views that stagnate and limit activity have had their day.

[rockedge]

is this working like in Porteus .xzm modules?

In a similar fashion but not designed as modular as Porteus is. I used some Porteus inspired boot mechanisms early on.

It's more like Puppy Linux SFS's loading adrv, ydrv but more flexible.

[mikeslr]

Sorry, wiak. I missed the point of those posts. I'll re-read them.