Vanilla OS v2 intends to be EASY for ALL users and PCs

[Clarity]

VanillaOS distro (NOT the VanillaPUP found on the forum) just got a very intersting reiew -

Even though it has a Live Mode and can be booted via either Ventoy or SGF2D from its ISO file, it is unlike any forum distros in how it handles Persistence Management and applications. It has a persistence management akin to a discussion in the KL section on continuous backup session management using alternates.

Persistence ONLY WILL exist when the distro is installed. It appears to install in a 3 partition configuration.

Its uniqueness goes beyond the installed configuration; rather what makes it DESIRABLE is its Package Management system which will install a package from every known major source we know of except

• PETs

• SNAPs

• Portables

And in review of their forum they may be open to adding a PET feature to their Package Manager in the future.

They can also be found on GIT, here.

This OS may influence other distros to copy in the future.
.

[Jasper]

Was curious and looked at their site.

It requires 50Gb to install the OS (A/B partition)

Alongside having to reboot each time an application is installed.

[amethyst]

It requires 50Gb to install the OS

That size is definitely NOT EASY on my eyes.

[fredx181]

It requires 50Gb to install the OS (A/B partition)

Aargh, even winblow$ requires less (I think).

[Clarity]

This forum's KLs have a 'feature' for session management, that they have copied or they mimic; namely uupper_changes and upper_changes1. Thier naming of these are different, of course. They just implement it automatically.

But, I can see much of what they are attempting in resource use with an aim at universal provisioning.

Is it different...Yes. Yet, as the video reports, some of this is compelling.

P.S. The ISO file running LIVE is not 50GB. Let's not confuse system size as somehow reflective of system behavior. And operationally, LIVE, is not such.

[wiak]

Well, you CAN get the best of both worlds... well, some of the 'best'... containers and apx multi-distro package management support...

As I reported back in March:
viewtopic.php?p=84288#p84288

Tried VanillaOS tonight. Pretty intesting distro with its apx container functionality that supports Ubuntu, Arch, fedora package management.

Alas, despite looking glossy and being fast enough on my relatively powerful laptop I really don't like Gnome desktop.

When I say "Tried VanillaOS" I had actually used the weedogit method so was booting it as a FirstRib overlayfs distro so also had full upper_changes save on demand and thus FirstRib-based rollback support. Well, the result of that would be different to any rollback mechanism provided automatically in normal install of VanillaOS, but what I was trying was its use of containers to allow installation (via its package manager 'apx') from most mainline distros (apx using apt, or xbps etc...) - that apx container mechanism worked fine. My only grump, per the above, is that Gnome desktop heavier than I desired, but FirstRib initrd installed VanillaOS variant works fine with same sort of save on demand persistence as all KL-based distros. i.e. I made a FirstRib/KL-type frugal install per the resulting installation directory shown in attached image - I boot that via the grub2 already available on my laptop:

menuentry "vanillaOS" {
insmod ext2
search --no-floppy --fs-uuid --set 424d8f42-e835-4111-9053-dd086b3d38e8
linux /vanillaOS/vmlinuz w_bootfrom=UUID=424d8f42-e835-4111-9053-dd086b3d38e8=/vanillaOS w_changes=RAM2
initrd /vanillaOS/initrd.gz
}

I used my script wd_grubconfig to auto-generate the above for me per usual. Anyway, all that was back in March and I'd forgotten about it and haven't booted it up since, but was an interesting exercise when I was looking into containers and the use of VanillaOS apx package management methodology. I wouldn't say it blew my mind at all since, to be honest, one good package manager is good enough in my opinion (most just duplicate each other albeit with different sizes of repo) - that and the FirstRib/KL ability to also include apps via addon sfs (or uncompressed directories), though, yes, you can also install the likes of flatpak, snap, or use AppImages (I rather like the latter too).

Note that I used an uncompressed (i.e. normal) directory 07squashfs-root containing the overall VanillaOS root filesystem (I could have named that anything as long as 07 the first two digits to indicate what layer of the overlayfs FR initrd puts it at). I could of course have used mksquashfs utility to squash that up, but works fine either way and useful uncompressed for some manual tweaks of my own... Yes, I could have added 10gtkdialog...blahblah to this as well for some more KL-type functionality and include Fred's save2flash util as well, but I didn't on this occasion.
NOTE2: Don't be confused with my own VanillaOS test - that certainly runs VanillaOS for container and apx functionality, but since I'm using FirstRib/KL initrd method and not the initrd of VanillaOS the persistence methodology I'm using is that of FirstRib/KL and not that of VanillaOS.

[dimkr]

Well, you CAN get the best of both worlds...

But the result is not an immutable distro, you lose the main advantage of Vanilla OS.

[wiak]

Well, you CAN get the best of both worlds...

But the result is not an immutable distro, you lose the main advantage of Vanilla OS.

If that is the 'advantage' you are looking for. I was looking for apx package management ability to install packages from multiple upstream distro repos such as Fedora and Ubuntu and Void Linux, and also the container approach. But result, as I said is not VanillaOS per se, but is using VanillaOS root filesystem for that container/apx ability. Not sure what the 'immutable' characteristic is if persistence is also provided in normal VanillaOS install. The root filesystem, per usual FirstRib/KL approach can be a read-only sfs and in save on demand mode the boot-time system remains pristine if save is not done. Anyway, was just myself wanting to try apx and so on...My actual full comment to quote was:

Well, you CAN get the best of both worlds... well, some of the 'best'... containers and apx multi-distro package management support...

And I also did say:

NOTE2: Don't be confused with my own VanillaOS test - that certainly runs VanillaOS for container and apx functionality, but since I'm using FirstRib/KL initrd method and not the initrd of VanillaOS the persistence methodology I'm using is that of FirstRib/KL and not that of VanillaOS.

which puts my post comments in my intended context.

[Jasper]

This is a general question, I thought a "immutable" system enables updates/rollbacks.

@wiak

The root filesystem, per usual FirstRib/KL approach can be a read-only sfs and in save on demand mode the boot-time system remains pristine if save is not done

Sounds ideal to me

[wiak]

This is a general question, I thought a "immutable" system enables updates/rollbacks.

Immutable may mean different things to different people (e.g. in object oriented programming).

FirstRib/KL allows updates and rollbacks, but just hasn't yet had scripts added to automate that process - simple to do manually though, just a matter of taking the upper_changes read-write save persistence folder and adding a 2digit number to its filename (and optionally compressing that into an sfs file). Then it will be used as a read-only layer at that 2digit layer position and a new non-numbered upper_changes folder gets auto-generated for the new session saves. Repeat that process each time the distro is used and you end up with a series of numbered upper_changes folders (or sfs addons) and one unnumbered topmost read/write layer session save persistence folder. You can rollback anytime by going back to earlier sequence of numbered upper_changes folders with new empty topmost read/write upper_changes. A utility script could of course be written to handle that naming procedure on every shutdown - just no-one has tried writing that automation of rollback script as yet...

[dimkr]

An immutable distro allow atomic update or rollback of the whole OS, in a way that's safe against power failure, corruption, etc'. And it's safe against tampering with core OS files, because / is non-persistent (only the home directory is persistent). Some of these ideas don't belong in a Puppy-style distro, and compatibility with packages from multiple distros can be done with something like distrobox.

[wiak]

I'm not really into buzzwords and trends, but:

https://itsfoss.com/immutable-linux-distros/

Immutability is a concept in trend. Take a look at what are the options you have for an immutable Linux distribution.
...
An immutable distro ensures that the operating system's core remains unchanged. The root file system for an immutable distro remains read-only, making it possible to stay the same across multiple instances. Of course, you can change things if you would like to. But, the ability remains disabled by default.

How is it useful?

Traditionally, immutable distributions existed to allow for easier testing and container-based software development. Furthermore, immutability provides you with better security and reliable updates for your operating system.

Seems to me a KL style distro when providing container support (and that's easy enough) with its read-only core root filesystem overlay structure can be configured to be optionally immutable. Maybe I'm wrong - I'd have to study the likes of VanillaOS more closely to understand better, but doesn't interest me particularly. Distrobox is interesting should I ever decide containerisation becomes important to me personally - maybe increases security in this growingly insecure internet environment, but thus far I don't feel any particular need for the likes of containers in daily use anyway. The simple feature that remains important to me is save on demand (optional persistence) capability; whilst I could use rollback strategies, again, I don't actually have much use for that in my daily computer usage as yet - nice to have all these options though.

[pp4mnklinux]

- It's a fantastic presentation.

- It's a fantastic exposition.

- It's the future of linux.

- It's...

BUT WHEN YOU SEE THIS VIDEO, YOU MUST START AT MINUTE 13:33 https://youtu.be/tOm_zATjgqU?t=815

... so if you start waching at this point, you gonna understand "... BUT IT'S NOT FOR EVERYONE"

Having that in mind... the decission is really easy... ISN'T IT? hahaha

Have a nice day u all.-

[Clarity]

One of its feature, IIRC, is how it alternates session management, I very interesting approach offering some interesting benefits and additional options.

The distro certainly is cause for thought.

Thanks @wiak for showing your work efforts and it seems you understand much of what they are offering in its system's operation.

This distro takes much of its strong points from several things in the industry today and is aimed at 2023-2025 manufacturer's hardware in design of its systems, security, subsystems such as wayland, pipewire, containers, package management wrapped into "one off the shelf".

It is certainly interesting in its unique vision going forward. It is only going to get easier in user use. Its not yet at Chromebook level of completeness with ease of use, but it will get there.

There is an upside that is not mentioned in the video. With its design, I see no reason why this will be able to be coupled with a sister system where app-subsystem use will operate in a semi-cluster mode where the sister is local or in the cloud. But, its early and only at v2, today.

Linux has come so far in past 5 years. This is one example.

Be careful should you test this. It catchy!

[Jasper]

@wiak

Thank you for the detailed explanation

I do tend to update applications and make regular backups and then rollback if/when the OS breaks ie an application fails to work successfully/intended or interferes with an existing application.

The possibility of incremental backups is an advantage.

[stevie pup]

I've just had a look at the Vanilla OS site, and couldn't help notice the system requirements, 4Gb RAM minimum and 8Gb RAM recommended. Not exactly what we would call "lightweight" is it?

It also says they're in the process of changing the base from Ubuntu to Debian, so I will leave it well alone until the change has been completed.

[dimkr]

I've just had a look at the Vanilla OS site, and couldn't help notice the system requirements, 4Gb RAM minimum and 8Gb RAM recommended. Not exactly what we would call "lightweight" is it?

Is Puppy lightweight? A modern Puppy uses 140-300 MB of RAM in live boot. Together with pfix=copy or the default behavior of copying to RAM it there's enough room for the SFSs, RAM consumption is not very far from that of a big distro with a DE. Then, you need enough RAM for a modern browser with more than one tab open. If you have only 2 GB of RAM, good luck. I think 4 GB is the minimum to run Puppy comfortably (= with a modern browser).

[mikewalsh]

I tend to agree with Dima on this one.

I've been saying it for long enough; we've all grown very fond of quoting the ISO sizes of most Pups.....which are themselves small (-ish). What everybody conveniently overlooks is that when you run Puppy in the default manner - i.e., expand the contents of the ISO & let the whole thing load into RAM - it's then occupying around the same amount of space as it would HAD it been installed in "full" like mainstream distros.

Thus, say, for instance, we take PhilB's Xenialpup64 7.5....just for example. ISO size; 330 MB. Looks good, doesn't it? Once you boot the ISO, and everything's in place for a "standard", default, normal run, you can add another GB on top of that. It needs, on my desktop rig, 1276 MB.

We then add a modern browser - Chrome, say, or Firefox, and open half-a-dozen visually-intensive, 'busy' websites (call it around 200 MB per tab) - and you're suddenly using using another 300+ MB for the browser itself, along with a further 1000-1200 MB for tabbed content. Add this to the Puppy itself, and you're already up to a total of 2.6-2.8 GB.

And then you start to see where Dima's quoted 4 GB minimum comes from.....

Already, many of us are using far more powerful mchines than when, say, we first started with Puppy. I certainly am. And those folks running really old hardware are going to steadily dwindle in number, till their only options will be an older Puppy which may, or may not, even be able to run an up-to-date browser. At that point, they will have to obtain a more modern machine just to stay online.......either that, or bite the bullet, junk the PCs and go fully 'mobile'. Like billions of others already do.

Mike.

[dimkr]

I agree and have two more points to add:
1) Sometimes bigger is faster and smaller is slower - take out VA API drivers to reduce few MBs of size and now your browser will become a CPU hog that eats your battery when you watch online videos. Then, recompress every SFS with xz and a large block size. Smaller? Probably <= 30 MB or <= 10% smaller. Faster? No, many times slower, more CPU hungry and more RAM hungry.
2) In many computers, CPU and the GPU are either expensive, not upgradable or not worthwhile to upgrade (for example, if the CPU socket has changed, and you can't upgrade beyond this CPU generation or the one after it). RAM is cheap but sometimes it's soldered or the motherboard doesn't support more. However, storage is cheap and easy to expand. If you want to run a big but fast distro, a large enough flash drive or SSD that works with your computer should be easy to recycle from a "from parts" computer, or cheap and easy to find.

Therefore, if you want a "lightweight" or "fast" distro, size is the first thing you can compromise on. Low CPU usage, good utilization of the GPU and low RAM consumption should be the top priority, not size on disk.

An immutable distro needs at least 2x space compared to a "normal" distro because you always have at least two copies of the OS. Anyone would agree that reliability of OS updates and the ability to roll back an update are very nice features, including those that (wrongly) believe that a 2x bigger distro must be 2x slower.

[amethyst]

expand the contents of the ISO & let the whole thing load into RAM - it's then occupying around the same amount of space as it would HAD it been installed in "full" like mainstream distros.

Well, that may be true but then a full install is not loaded into RAM (just a small bit). If you go RAM wise at bootup then you need to compare apples with apples, ie. compare RAM usage of a big full install with a a Puppy loaded with the pfix=nocopy parameter. But we are now actually speaking RAM usage which really does not actually have anything to do with the actual size of the distribution. You can spin it as you like, other big linux distributions are at least 3 times as big as a Puppy (very conservatively estimated as say the Puppy ISO is 1GB compared to a big linux distribution ISO of at least 3GB). I assume the big distributions' files are also in a compressed state (as far as the contents of the ISO is concerned) like that of Puppy. Now let's assume the 1GB Puppy ISO expands to 2.5GB (uncompressed files) and the other Linux distribution 3GB ISO expands to 7,5GB (same decompression ratio). Now, that's quite a difference in size, isn't it? Also ridiculous to compare older Puppys with the new Puppys. As far as old machines goes, the older Puppy's are MUCH lighter on resources and also there is quite a difference performance-wise between a 32-bit and 64-bit distributions on an older "challenged" machine and nobody is going to convince me otherwise as I have been running older machines for ages. I've seen and experienced it for myself. And don't get me wrong - if you have new, flashy hardware, why the hell wouldn't you want to run the latest biggest, heaviest, all the bells and whistles distribution? Your machine can handle it. To be fair, if I had a new powerful machine, I would probably NOT have used Puppy.

[dimkr]

But we are now actually speaking RAM usage which really does not actually have anything to do with the actual size of the distribution.

A big SFS that gets copied to RAM occupies more RAM than a small SFS. No?

[amethyst]

But we are now actually speaking RAM usage which really does not actually have anything to do with the actual size of the distribution.

A big SFS that gets copied to RAM occupies more RAM than a small SFS. No?

We are not copying anything to RAM (except for the system files needed to get it to desktop). But here is an idea/suggestion. Most of us love Puppy because of the way, well, a frugal Puppy works. That's a huge draw card for me having my whole operating system basically locked in a read-only system, really excellent idea. Has the thought ever occurred to really make a big, fat (frugal) Puppy with all the bells and whistles one finds in the big distributions (plus of course the stuff that has been developed specifically for Puppy over the years). I think there will be users who will be interested in such a project. A fat "top of the line/cutting edge" Puppy, community version where the Puppy Community decides which stellar applications, etc. should be included in this "Rolls Royce" of Puppys (regardless of size).

[dimkr]

Here's a super big, "fat" Puppy with cutting-edge stuff - Wayland, PipeWire, Flatpak, you name it. Almost 1 GB in size, but ligher than any Puppy with a comparable set of features.

lxtask.png (50.9 KiB) Viewed 1833 times

[amethyst]

Here's a super big, "fat" Puppy with cutting-edge stuff - Wayland, PipeWire, Flatpak, you name it. Almost 1 GB in size, but ligher than any Puppy with a comparable set of features.

lxtask.png

That's cool , let's now add other huge applications that the community votes for. People that have used other big Linux distributions over the years may have excellent ideas of stuff that have been great for them and be included in this super whopper Puppy of all Puppys. So as far as added applications are concerned, get feedback on what people want in each category (just the "best", size not an issue).

[geo_c]

This is a general question, I thought a "immutable" system enables updates/rollbacks.

Immutable may mean different things to different people (e.g. in object oriented programming).

FirstRib/KL allows updates and rollbacks, but just hasn't yet had scripts added to automate that process - simple to do manually though, just a matter of taking the upper_changes read-write save persistence folder and adding a 2digit number to its filename (and optionally compressing that into an sfs file).

A utility script could of course be written to handle that naming procedure on every shutdown - just no-one has tried writing that automation of rollback script as yet...

This one missing automated rollback feature in the KL distros seems to me to be the one function left to make KL distros ready for world-wide distribution.

I have been using the numbered upper_changes approach perhaps as much or more than anyone using the KL distros. My KLV-airedale installations are 15 XXupper_changes deep and 9.5GB in total size, representing a collection of installed applicatons, system updates, and transitions from RC release versions. All works flawlessly, and at any time it's possible to rollback to a previous version in the evolution simply by prefixing the XXupper_changes directories with [some text]XXupper_changes.

All of this has to be done manually though, and I don't do it while booted into the OS, which I'm sure would crash the running system, instead it requires booting into another OS and making the changes, then rebooting back in.

In order to develop KL distros into an OS that a ordinary user can use, manipulate the upper_changes layers, and rollback while booted in the single dedicated KL OS, would require that automated script.

Sounds complicated to write to me. And I've often wondered what results I would get by doing something like copying the current upper_changes to a new XXupper_changes while running the system, but that approach seems to still require booting into another OS in regards to deleting the current upper_changes after copying it and before rebooting, which seems like a VERY BAD IDEA edit: I mean deleting the current upper_changes while still running from it is a very bad idea.

For a little insight on my upper_changes naming scheme, I include in the name transitions from one RC release to another so that if for some unlikely reason I would choose to rollback, I would also first replace all the system iso files with the earlier RC release files.

I also drop a marker file in the system directory indicating which RC release is being used by the current upper changes, along with an update marker file indicating the date of the last full system update.

[fredx181]

Ubuntu minimal requirement is 4GB ram, for Puppy it should be much less IMO, otherwise where would be the Puppy "philosophy" of being able to run on "older" computers !?

[mikewalsh]

@amethyst :-

Has the thought ever occurred to really make a big, fat (frugal) Puppy with all the bells and whistles one finds in the big distributions (plus of course the stuff that has been developed specifically for Puppy over the years).

Um.....correct me if I'm wrong, here, but I thought that this was exactly what csipesz has been doing for years with his "super-fat" Puppies? It's hardly a new idea, surely?

Do I detect a wee bit of sarcasm here, Nick? (No offence intended, mate, but I know you like keepin' ya Pups on the small side, don'tcha? )

Mike.

[dimkr]

Ubuntu minimal requirement is 4GB ram, for Puppy it should be much less IMO, otherwise where would be the Puppy "philosophy" of being able to run on "older" computers !?

You can run Puppy with 512 MB, 1 GB or 2 GB of RAM. But will you be able to run a modern browser (one where you can do your finance, watch Youtube, play Spotify ... with >= 4 tabs)?

Has the thought ever occurred to really make a big, fat (frugal) Puppy with all the bells and whistles one finds in the big distributions (plus of course the stuff that has been developed specifically for Puppy over the years).

Surprise surprise, size is nearly identical. The only trick Puppy has up its sleeve nowadays is compression. 10 years ago when coreutils was a considerable % of the total size of Puppy, replacing it with busybox was a big size reduction. And today's kernels are so big that dropping this or that esoteric driver doesn't matter. Today browsers are >100 MB, and these old tricks yield <%5 reduction, if not <1%.

[mikewalsh]

Ubuntu minimal requirement is 4GB ram, for Puppy it should be much less IMO, otherwise where would be the Puppy "philosophy" of being able to run on "older" computers !?

You can run Puppy with 512 MB, 1 GB or 2 GB of RAM. But will you be able to run a modern browser (one where you can do your finance, watch Youtube, play Spotify ... with >= 4 tabs)?

In one word.....NO. (And the state of the modern web is the culprit here; people EXPECT all the bells, whistles and fancy, flashing, in-yer-face graphics, don't they?)

(*shrug*)

Can't have it both ways, can we?

Mike.

[dimkr]

Can't have it both ways, can we?

IMO things like Gopher and Gemini (i.e. https://cheapskatesguide.org/articles/s ... -a-pi.html) are the closest you can get to "web browsing" with computers with < 2 GB of RAM. With a slow CPU even Gemini can be slow.