Vanilla Dpup 9.0.x -> Vanilla Upup 22.04 (beta)

[dimkr]

Hello all,

I intend to retire Vanilla Dpup 9.0.x soon, because most users who choose it over 9.1.x will be better served by Vanilla Upup 22.04 (warning: beta quality).

9.1.x has reached a higher degree of overall polish, and has some important security fixes that can't be backported to 9.0.x without breaking stuff.

Vanilla Upup 22.04 comes as an ISO image, uses Puppy's traditional initrd.gz, supports overlay (and uses it by default, instead of aufs), it's small (well below the 300 MB mark if you use a smaller kernel package), apt is included, and it's fairly barebones, so you can install whatever you want. Like Vanilla Dpup, it doesn't need devx and the kernel sources SFS to install extra drivers.

What do you think? Is there any use case of 9.0.x that's broken on Vanilla Upup 22.04?

[Duprate]

Good morning, Dimkr! I have previously expressed my preference for Vanilla Dpup 9.0.x. I prefer it to compile the Kernel and to watch movies on an Intel NUC connected to the TV. However, I'm always willing to try a new OS. I'm curious about Vanilla Upup 22.04. In Dpup 9.0.x I need the devx....

Vanilla Dpup 9.0.x is in a very stable version, Vanilla Upup 22.04 is in beta version....

[bigpup]

Released stages of a Puppy Linux version
https://forum.puppylinux.com/viewtopic.php?t=3683

[dimkr]

I need the devx....

In Vanilla Upup 22.04, you can just apt install build-essential pkg-config autoconf bison flex [...], and don't need devx. In Vanilla Dpup 9.2.x, it will be this way too, making it much smaller than 9.1.x and 9.0.x.

Vanilla Dpup 9.0.x is in a very stable version, Vanilla Upup 22.04 is in beta version....

True, but this will change soon. Ubuntu 22.04 will be released soon, and Vanilla Upup (just like Dpup) doesn't use any prebuilt packages that can break, so it will be released shortly after the Ubuntu release.

[Duprate]

I've been using FatDog64 for years as my "battle system". I also use VoidPup64-22.03+3, VanillaDpup-9.0.37, bionicpup32-8.0+29-uefi. I've used slacko64-8.2.1, DebianDog Bullseye, tahr-6.0.5_PAE, and the non-puppy MakuluLinux-LinDoz-2021-06-27. I only mentioned these, because they all have something in common: They are malleable, I start all with the wiak initrd (wdlgo-300) which I admire for its simplicity and efficiency. So I compile my kernel, just overlayfs, without relying on the AUFS patch.

In these systems, I use all browsers without restrictions, Windows or Linux games, different programs with the greatest efficiency.

VanillaDpup-9.1.x with frugalify, VanillaUpup-22.04 and perhaps KLV-Airedale, at this point, are beyond my ability to comprehend, and my principle that "only the simple things work".
Congratulations on your work "VanillaDpup-9.0.x"!

[dimkr]

VanillaUpup-22.04 [...] beyond my ability to comprehend

What about it makes it hard to comprehend? It comes as an ISO image, exactly as you like.

[retiredt00]

Dear dimkr
Vanilla Upup 22.04 is nice and stable, but I’m struggling to understand why is better than a “live install” or a “network install” image of Ubuntu.

Let me explain.
Is a minimal ISO with no apps, no utils, no major infrastructure. Just a set of SFSs that allow the user to boot almost any machine (BTW the kernel/firmware is now really huge almost 140+ MB! zdrv almost doubled!) to a minimal desktop and then configure it in a read-write folder or mounted image. Pretty much as in a normal full install but with different folder structure (as seen from the root of the partition - not the filesystem).
There goes the idea “you did a mistake. just start without savefile and you are fine”. Now is “you did a mistake. just start without savefile and rebuild your system” !
Because by the time it becomes usable with the standard apps Upup has 300MB worth of SFSs and 1GB+ worth of apps in the read-write upper layer (specially if you do not know how to best handle apt’s appetite).

Then instead of the very versatile aufs is running the teutonic overlayfs, a filesystem mostly used for dockers and containers (neither of which are in the Upup design philosophy). And of course overlay does not allow loading and unloading the immutable SFSs on the fly.
BTW Vanilla Upup 22.03 was coming in both Aufs and Overlayfs flavors. What happened to Aufs versions? You have mentioned many times that aufs has problems but I can not remember seeing one besides the occasional 1-2 week delay to catch up with conflicting kernel fs-handling changes.

Further more Vanilla Upup is not compatible with any older pets or SFSs, due to the move of everything into /usr, but it is fully compatible with the latest Ubuntu.

Finally Vanilla Upup, that is to replace vanilla Dpup, has no x86 version and comes only as x86_64.

So is basically an Ubuntu spin off!

I guess this may be good, but what is really the appeal of this system over the mother distro, Debian/Ubuntu and its flavors?
You can argue that “this is the way forward”, but to where? What is that distinguishes a vanilla Upup ISO from a bare installation disk and a full install?
Of course you can also tell me “if you don’t like it, don’t use it” but I’ll still ask because I likely miss something of your line of thought.

In any case and regardless of the direction that vanilla D/Upup will go, one thing that I think might improve this (or any other) minimal system setup, is an app where a bunch of debs will be thrown in a folder and will transform to a usable SFS. I think there are utilities, in this forum and certainly in other distros, that can do that.
Such a utility will allow the users to make their own adrv/ydrv/devx/my_apps SFSs and use them whenever they want (even if this will require a reboot…)

Please do not get me wrong. I appreciate what you do. I just think that is made having the developer as a focus point rather than the user, and I am not a developer.
Hopefully, someone will come up and based on your foundation work will offer a U/Dpup version in the more traditional puppy style, i.e. small, efficient and fully loaded for everyday work and entertainment, OOTB.

Apologies for the rumbling.
Best

[dimkr]

Is a minimal ISO with no apps, no utils, no major infrastructure. Just a set of SFSs that allow the user to boot almost any machine (BTW the kernel/firmware is now really huge almost 140+ MB! zdrv almost doubled!) to a minimal desktop and then configure it in a read-write folder or mounted image.

And if I add another flavor, with a much smaller (and less Ubuntu-compatible kernel)?

(specially if you do not know how to best handle apt’s appetite).

Does apt install --no-install-recommends solve this problem? In Vanilla Dpup, that's the default.

BTW Vanilla Upup 22.03 was coming in both Aufs and Overlayfs flavors. What happened to Aufs versions?

I'm thinking about doing two flavors, one with a small, Puppy-style kernel and aufs, and another with a very Ubuntu-like kernel and overlay. I think people will complain if it's too barebones, but others will complain if it's too big and has default applications for everything, so I'm not sure if I also want to make the aufs flavor less barebones.

Finally Vanilla Upup, that is to replace vanilla Dpup, has no x86 version and comes only as x86_64.

It's not a replacement for Vanilla Dpup. But I do want to retire the 9.0.x builds soon, and I think Vanilla Upup could be a good alternative, once I understand the 9.0.x use cases and do some adjustments.

[retiredt00]

And if I add another flavor, with a much smaller (and less Ubuntu-compatible kernel)?

Will be welcome!

Does apt install --no-install-recommends solve this problem? In Vanilla Dpup, that's the default.

Correct but your average user will likely use synaptic.
The other size offender is language packs and localepurge is not even included.
Ideally should be installed and "auto configured" after the language had been set in quicksetup

I'm thinking about doing two flavors, one with a small, Puppy-style kernel and aufs, and another with a very Ubuntu-like kernel and overlay. I think people will complain if it's too barebones, but others will complain if it's too big and has default applications for everything, so I'm not sure if I also want to make the aufs flavor less barebones.

Again I believe will be welcome
Edit:
(the more traditional puppy style ISO with aufs and all the default apps)

People will complain no matter whet you do (I did already!), so I would not worry.
Besides if the 2 versions are compatible (for example all extra default apps go to an a/ydrv) the "picky" user can choose aufs or overlayfs, with or without default apps and will be hard to find something to complain (besides the /usr move - which might be a good idea to address in perget and sfs_load if possible - and the x86 thing)

[retiredt00]

sfs_load and sfs_load.overlay fail to start in vanillaupup-22.04.14 with a gtkdialog Error in line 20, near tocken '</vbox>': syntax error
This is either in PUPMODE 5 or 12 before any sfs is loaded. Just called from the menu or the terminal directly without further arguments.

If you just click on an sfs and ask to install, then the SFS is queued correctly but also /mnt/sfs_name.sfs is generated, sfs is mounted there and ROX opens the folder.
The same if you click on the sfs and prompt to remove it from the queue. Is removed from the queue but the SFS is mounted and opened in ROX again.

Finally after you click on an SFS and call sfs_load to install it, sfs_load now starts from the menu but fails to add or remove an SFS from the queu.

[dimkr]

sfs_load and sfs_load.overlay fail to start in vanillaupup-22.04.14 with a gtkdialog Error in line 20, near tocken '</vbox>': syntax error

As you see, beta quality. Fixed.

If you just click on an sfs and ask to install, then the SFS is queued correctly but also /mnt/sfs_name.sfs is generated, sfs is mounted there and ROX opens the folder.
The same if you click on the sfs and prompt to remove it from the queue. Is removed from the queue but the SFS is mounted and opened in ROX again.

Yes, it's a compromise. A user who knows the limitation of SFS loading only at boot time will just put the shiny new SFS in /mnt/home, select it in sfs_load and reboot, instead of clicking the SFS.

Finally after you click on an SFS and call sfs_load to install it, sfs_load now starts from the menu but fails to add or remove an SFS from the queu.

I'm not sure I understand

[retiredt00]

Ok, I'll wait for the next update for more.
Primarily because somehow I managed to wipe 2 partitions playing with the "compromised" sfs_load.
I'm not sure how exactly to reproduce it but it happened to me in 2 different installations and I'm not sure I want to try it again before the update.
I think it was when I was manually un-mounting or deleting the /mnt/sfs_name.sfs what was generated by sfs_load.overlay but I'm not sure
What I am sure of is that I never issued an rm -rf command to wipe the drive.

[dimkr]

Primarily because somehow I managed to wipe 2 partitions playing with the "compromised" sfs_load.

Oh no!

[Duprate]

Hi Dimkr! Thanks for the latest update, vanilladpup-x86_64-9.0.40.