Vanilla Dpup 9.x (x86 and x86_64) (old thread)

[dimkr]

Dear @dimkr, please tell me which version of WINE should I use in Vanilla PUP64?

Take the one from PPM, it's the one most likely to work.

However, there is a problem with it: Puppy, by design, doesn't support "multiarch" installations that have both 32-bit and 64-bit libraries side-by-side. To run many Windows applications, you need a 32-bit Wine. If you need to run a 64-bit application, the one from PPM is the one you should bet on.

The inclusion of apt plus https://github.com/puppylinux-woof-CE/woof-CE/pull/2771 will solve this problem, and allow 32-bit and 64-bit Wine to coexist on the same Puppy.

[dimkr]

-- accidental double comment --

[dimkr]

Oh... 'technically' not a fork

Thanks for confirming this is not a fork. I was worried that somehow I accidentally copied your code.

almost identical underlying implementation

you already copied that idea with your frugalify 1.sfs, 2.sfs, 3.sfs loop creation per WeeDog addlayers algorithm

I have absolutely no idea what you're talking about here. Vanilla Dpup images that use frugalify still have puppy_*.sfs, adrv*.sfs, etc', not 0.sfs, 1.sfs, etc'.

The implementation details are different.

I don't know what the "addlayers algorithm" is, so even if I want to, I can't copy it. The frugalify algorithm for sorting SFSs is in https://github.com/puppylinux-woof-CE/f ... ify.c#L348: bdrv_*.sfs first, puppy_*.sfs second, then the rest is sorted by version number or alphabetically if no valid version number is found. Is this the "addlayers algorithm"?

and as for the 19MB instead of 20MB because of zstd compression instead of xz, well that is just a ridiculous comment.

You misunderstood me. What I'm saying is, I'm using zstd, so the compression ratio is worse, but still: my implementation yields a smaller 19 MB SFS, compared to your 20 MB SFS. If it's smaller despite the worse compression, then the implementation must be different enough to debunk your claim of stolen code or intellectual property.

Stop continually stealing credit and instead reference previous works

Stop blaming me for things I didn't do and spreading false accusations.

[wiak]

You misunderstood me. What I'm saying is, I'm using zstd, so the compression ratio is worse, but still: my implementation yields a smaller 19 MB SFS, compared to your 20 MB SFS. If it's smaller despite the worse compression, then the implementation must be different enough to debunk your claim of stolen code or intellectual property.

Well I'm pretty sure you will know what you have trimmed out to make it smaller. I imagine it would be PAM-related.

Point of concern remains that any reputable developer/researcher would credit previous works they have undoubtably noticed in their research activities prior to putting their implementation together. Not doing so (not giving acknowledgement/credit to earlier published ideas/work) is pathetic, certainly unprofessional, and not worthy of the respect you appear to crave.

[dimkr]

Well I'm pretty sure you will know what you have trimmed out to make it smaller. I imagine it would be PAM-related.

Feel free to imagine things, but my SFS includes PAM, untrimmed, with the entire modules directory.

undoubtably noticed

I noticed a thing called "WDL" and your various comments in many topics in the forum.

I know there's some use of symlinks and some use of numbered SFSs, but that's all I know about WDL, and I never looked at its code.

The references I did use when I wrote frugalify were written by me, years ago:

https://github.com/dimkr/rlsd2/blob/mas ... amfs/build
https://github.com/dimkr/sdaemons/blob/master/init.c
https://github.com/dimkr/sdaemons/blob/ ... akelogin.c
https://github.com/dimkr/sdaemons/blob/master/syslog.c
https://github.com/dimkr/sdaemons/blob/master/vtman.c

EDIT: forgot to mention https://github.com/dimkr/lazy-utils/blo ... cttyhack.c

frugalify.c is heavily based on these, and it's not hard to see the similarity.

Now the hypothesis that frugalify is a C translation of something from WDL sounds less likely, doesn't it?

But no matter what I say, you'll still say this is a lie.

[rockedge]

@dimkr I don't under stand why I am mentioned here! Why are you dragging me into something?

What the $%#k is your problem?

Not one single conversation with you has been non-contentious it seems. Please point something out if I am wrong.

Why not participate and help solve the on going crashing search engine and disappearing search indexes problem?

[wiak]

Thu Apr 01, 2021
viewtopic.php?p=21543#p21543

perhaps as an add-on like wiak has done for apt/dpkg. Keep in mind that for apt/dpkg additional dependencies are at least recommend (if not required?) such as gpg support.

Actually, I also dislike the approach of adding APT to Puppy, for two reasons: ... many packages just don't work (for example, stuff that depends on D-Bus service activation from user sessions, because Puppy has only a "system" D-Bus instance) 3) supporting APT and fixing all these incompatibilities increases the bug surface in a way, IMHO, Puppy can't handle.

I agree entirely. I did not contribute my dpkg_apt_PAM sfs addon to Puppy community with a view that in that simplest add-on form it should be merged into official Puppy. I just contributed it, because I can, for those who wanted to easily experiment with apt alternative in Puppy and more so for cases when they were having trouble installing some larger packages via PPM or pkg alone, which I know can happen.

and as for,

I have absolutely no idea what you're talking about here. Vanilla Dpup images that use frugalify still have puppy_*.sfs, adrv*.sfs, etc', not 0.sfs, 1.sfs, etc'.

I assume you don't know your own code then. Or have you changed things in later 'frugalify init' such that a user running the command 'mount' does not evidence/show the 'underlying' 0.sfs, 1.sfs (well I see on looking back on it that you used .sfs0, .sfs1 and so on - not a difference of import), and so internally modded from alphabetic to numbered sfs addon form? i.e. mount previously showed exactly that internal numeric numbered sfs addon 'trick' that was used to increase number of layers available. From you comment I must have dreamed this too and failed to understand your little C code init program algorithm:

by wiak » Wed Apr 07, 2021
viewtopic.php?p=22061#p22061

So booting dpup OS1 from usb and checking with: mount | grep overlay
gives this result to show how the layers are assembled:
[per frugalify C init numbered sfs layers:]

Code: Select all

overlay...lowerdir=/save/.sfs0:/save/.sfs1:/save/.sfs2:/save/.sfs3:/save/.sfs4:/save/.sfs5:/save/.sfs6,...work

Please see attached Screenshot (Screenshot_WDL_dpupos2.png)

[per WDL initrd/init numbered sfs layers]
Note that this has been booted from hard disk /mnt/sda1 on my system and result of mount | grep overlay is:

Code: Select all

overlay ...,lowerdir=save_sfs00:06:05:04:03:02:01,...work

Similar, hmmm?

[dimkr]

What the $%#k is your problem?

My problem? It's wiak who mentioned you.

And I'm only defending myself here against wiak's (false) accusations.

From you comment I must have dreamed this too and failed to understand your little C code init program algorithm:

The SFS names are the same as in Puppy, SFSs are sorted using frugalify.c's sfscmp() function, and the mount points are numbered. bdrv_*.sfs is mounted at .sfs0, puppy_*.sfs at .sfs1 and so on.

Can you accept the truth that nothing is copied from WDL, please? Thank you.

[wiak]

I have never suggested, by the way, you may or may not have ever written an init in C. Who has not done that who has worked on embedded systems??? - I used to do the same way back in around 1999 when I used to teach embedded system design - no issue there. I'm talking about here and now on Puppy Linux forum though - not ancient history. Projects get published here, the work is known (despite your saying you never checked) and good quality development/research always involves acknowledging ideas and implementations rather than pretending (conveniently) they do not already exist.

You know very well what WeeDog (WDL) is and not just a term you noticed out of the side of your eye. In fact you have been the one trolling many of the comments I have made elsewhere to dispute them - near enough always on threads related to WDL or KLV more recently.

Time enough wasted. Let's not say any idea copied then. Let's just say not acknowledging existing more-than-similar projects (dpkg/apt sfs addon for Puppy) is a, should I say, a bit 'weird' in the Puppy Forum Community circumstance; not integrated into woof-CE certainly - and certainly no init being written in C for WDL - all that entirely your efforts for sure.

[rockedge]

@dimkr You did this the last time as well. The old "what!? me?" tactic.

You've been less than friendly to me more often than not. Just write the code.

[wiak]

What the $%#k is your problem?

My problem? It's wiak who mentioned you.

@dimkr You did this the last time as well. The old "what!? me?" tactic.

You've been less than friendly to me more often than not. Just write the code.

To be fair, I did mention you @rockedge, but only since I was talking about your having used WDL dpkg/apt and thus knowing of its existence - not many on this forum probably know anything about it so maybe would otherwise be led to believe I was making its existence up. Similarly, its hard to show similarity between parts of C code in comparison to shell scripting - but these fine details are of little importance to me - indeed most of the small init wasn't what I referred to - rather it was that one addlayers loop rearrangment making the .sfs0, .sfs1 and so on idea, which indeed is needed to implement the necessary bdrv under puppyXXX.sfs prior to any dpkg/apt sfs addon working (I went through same process but had to re-use Puppy adrv since not myself working on Puppy init system redesigns). What I don't like is the lack of acknowledgement of any prior work - and seemingly especially if not from a woof-CE dev and worse if some variant of Dog distro (not that 'Dog' is an adjective that I'm using to suggest such distros are particularly similar to each other since actually they are often very different from each other also).

I suppose I simply do not like uncollaborative devs who ignore all other work but produce similar (later).

WDL dpkg/apt sfs addon for Puppy is far from off-topic regarding this recent thread content (I never have been talking about 'code copying', but rather 'duplicating' of ideas without credit/due-acknowledgement for the original earlier implementations). Nothing occurs in vacuum (not by any of us), and research is about citing previous works (since they tend to at the very least inspire further developments), but let's just move on and pretend the WDL-contributed-to-Puppy dpkg/apt sfs addon is off-topic and in no way related then. No competition from me about the addon sfs size by the way - really ridiculous - I'm sure yours is much much better ...

[rockedge]

How about somebody write some code to do the Puppy Linux Wikkawika conversion for all pages to html or xml format? I have dove in and am fully immersed in rescuing the freaking Puppy Linux Wikka site from itself. The Wikka project has been declared over, as in discontinued. So a software change has to be done.

I've decided on MediaWiki for now and I need a tool that does not really exist...yet. So looks like I'll just drop everything and do that. I might just dump the entire Wiki idea, no one to do the administration.

The WikkaWiki as it stands is a HUGE magnet for spam attacks and can barely be used.

I did get a tip from a forum member on an old archived conversion tool that takes directories of html pages and will import them into MediaWiki. This might work. Just need directories of html pages that once were WIkka pages.

@wiak @dimkr I was hoping to release a beta KLV-Airedale, but no time now and I've lost momentum.

Personally I think peebee's VoidPup's are already the most interesting direction as far as Puppy is concerned. Add in Vanilla DPup's added flexibility in loading multiple <xx>drv.sfs to VoidPup and these discussions will be moot.

[dimkr]

The WikkaWiki as it stands is a HUGE magnet for spam attacks and can barely be used.

How about migrating the wiki to a GitHub wiki?

If you want to put more effort into stuff like KLV, you don't have to face the PHP/database/spam related maintenance burden if you go for a fully hosted ("cloud") solution.

Vanilla DPup's added flexibility in loading multiple <xx>drv.sfs

If you do an apples-to-apples comparison, I wouldn't say it's more flexible. https://github.com/puppylinux-woof-CE/woof-CE/pull/2779 only adds support for bdrv as a layer below the main SFS - nothing more, nothing less. The only reason I added this bdrv concept is to allow existing users of ISOs to benefit from the addition of apt, which sits in a lower layer to prevent Debian's /etc/group, etc' from overriding Puppy's files.

The Vanilla Dpup ext4 images use frugalify, which is more flexible. It has an artificial limit of 32 SFSs, puts a SFS called "bdrv_*.sfs" below "puppy_*.sfs", and anything else above (after sorting by version if possible, otherwise alphabetically). Technically, you can call the SFSs 0.sfs, 1.sfs and so on, but the ext4 images just use the traditional SFS names.

[wiak]

Personally I think peebee's VoidPup's are already the most interesting direction as far as Puppy is concerned. Add in Vanilla DPup's added flexibility in loading multiple <xx>drv.sfs to VoidPup and these discussions will be moot.

Yes, I've become interested in a Puppy for the first time in over eight years because of VoidPup. Sometimes it is simple additions (such as Void's xbps) that make all the difference and certainly the limits of traditional Pups alphabetic layering along with its PPM is what drove me in other directions from it in the first place (so VoidPup still needs that issue addressed). Having said that I valued the forum for collaboration, despite not working on Puppy itself longer per se, so, rightly or wrongly, I've instinctively always battled for forum space for recognition and respect for other ideas than those of Puppy itself. I've certainly had (and caused) many an argument because of that view - maybe shouldn't bother. Truth is, I'm tired now, maybe tired of software matters altogether so at least good to see some developments going on here and there - especially when collaborative and not just individual talent demonstrations. I have no illusions about the limits of my own talents - I somehow sometimes manage to engineer simple ideas into something more complex that works - but never very complex - but I'm no fanatic about computing, especially nowadays when I'm also getting old and older, so maybe the world of Puppy should indeed be left to those who wish to demonstrate how clever they are. Some think I'm like that (according to comments I've had against me) but actually I don't value much of my own work at all - just been a bit lucky at times that some simple ideas I've had and implemented have come together reasonably well - all could be improved by someone more skilled without much effort at all. But big deal - it's just software and a hobby.

Decided not to comment further.

[rockedge]

to benefit from the addition of apt, which sits in a lower layer to prevent Debian's /etc/group, etc' from overriding Puppy's files.

Yes this is a problem with the apt sfs addon I am using now. I have scripts to fix and return the Puppy components needed for clean shutdowns or reboots. I have written about the details, which involve the busybox links being replaced by systemd links during certain upgrades.

If you want to put more effort into stuff like KLV, you don't have to face the PHP/database/spam related maintenance burden if you go for a fully hosted ("cloud") solution.

We already use a "cloud" host to support all things puppylinux.com and what was once murga-linux.com. Actual IT support for anything hosted remotely costs money every month. We have very limited budgets. Basically what one gets is floods of emails from "the cloud" complaining how suspicious processes are running and fix it now or have the account disabled. Which means I have to fix it, maintain it and monitor it or it's game over. Good luck getting anything fixed or customized when dealing with the IT people at the hosting services. Only $$$$ speaks loud enough. Best thing it seems is to pay the basic rent and do the designs and work ourselves.

Lucky both forums and the Wikka are not effected by the Github redirect certificate problems...because they are not on GitHub.

Using GitHub is an idea. But just the fact that we are using Git to host the main Puppy Linux pages is causing HUGE security certificates problems and https problems since redirects have to be used to reach the Git hosted pages yet using the puppylinux.com domain. This causes MAJOR certificate ownership problems. GitHub will not play ball. For example the entire group of email addresses, xxx@puppylinux.com can not receive mail, our mail server refuses them because of certificate overlaps causing DNS resolver problems. Every day I tinker with this problem to find a fix. Asked in forums all over the world. Solution is stop using Github redirection of puppylinux.com. That will not happen so on a regular basis I stare at warning messages and icons about the screwed up security issues with no end in sight.

Lots of thing are easier said than done. I know for sure I can not pay for some cloud service IT dept to run and maintain one site, never mind the other three we have going now.

I do splurge for VIP support though and that gives us the right to ask the IT techs questions.

[dimkr]

Yes this is a problem with the apt sfs addon I am using now. I have scripts to fix and return the Puppy components needed for clean shutdowns or reboots. I have written about the details, which involve the busybox links being replaced by systemd links during certain upgrades.

I had to do some ugly stuff to make apt less dangerous. I blacklisted some packages to prevent them from being installed (for example, busybox). All packages in the main SFS an their dependencies (including stuff like systemd, which we don't want) get installed in bdrv, before their files get deleted (to reduce size - the main SFS has these files), and versions are held back (for example, so apt upgrade doesn't replace busybox when it updates e2fsprogs). The packages in the main SFS are updated in every Vanilla Dpup release (and so will bdrv), so apt upgrade should only update user-installed packages, and that should be safe.

I'm still pretty sure there's no way to integrate apt cleanly, because Puppy doesn't have systemd, because some applications refuse to run as root, the menu structure is different, and so on. Puppy and Debian (even Debian with sysvinit, or even Devuan) are too different. But with all its limitations, apt on dpup > PPM on dpup, because PPM is slow and unreliable, and its UI is horrible. Despite all limitations, I think it shouldn't be hard to get apt to produce working installations of more packages, compared to PPM, because the latter doesn't do stuff like running post-installation scripts.

So far, most applications I tried, including Steam (which requires 32-bit libraries), worked! GNOME Software was broken, and it looks like pretty much anything that relies on D-Bus user sessions or stuff like polkit is more likely to fail, because Puppy is weird: it has both system-wide and session-wide D-Bus instances for root, but some applications want to use just the system-wide when when they run as root, so the other applications they talk to use the wrong instance of D-Bus.

When this bdrv thing is merged, I'll update the release notes so they state clearly: this is an experimental feature, or at least, something to use with caution, and never on mission-criticial installations.

Lots of thing are easier said than done. I know for sure I can not pay for some cloud service IT dept to run and maintain one site, never mind the other three we have going now.

How much does it cost per month to run all Puppy sites, and at what resource utilization?

[rockedge]

Four sites are on one hosting service with good support. Apache, PHP7.4+, MySQL 5.7+ and all the bells and whistles with all of the domain name registrations, we have it around $100-$150 per year as it stands. We are responsible for our web site's software and configuration completely plus the administration of the hosting account and the use of all of the features we require. For some remote IT to do this who wants a fee for it, would charge in the thousands per month.
The host service runs the web server , mail server, MySQL server, all the connectivity, some of the domain registration, also CloudFlare cache system, and provides relatively easy to manage security certificates which need to be renewed every 30-40 days. The service also does 90% of the security and has plenty of spam tools, but that does not deal with the web forum software or any other web site software directly. All that assembly, configuration, maintenance and monitoring we do.

[williwaw]

I had to do some ugly stuff to make apt less dangerous. I blacklisted some packages to prevent them from being installed (for example, busybox). All packages in the main SFS an their dependencies (including stuff like systemd, which we don't want) get installed in bdrv, before their files get deleted (to reduce size - the main SFS has these files), and versions are held back (for example, so apt upgrade doesn't replace busybox when it updates e2fsprogs). The packages in the main SFS are updated in every Vanilla Dpup release (and so will bdrv), so apt upgrade should only update user-installed packages, and that should be safe.

I'm still pretty sure there's no way to integrate apt cleanly, because Puppy doesn't have systemd, because some applications refuse to run as root, the menu structure is different, and so on. Puppy and Debian (even Debian with sysvinit, or even Devuan) are too different. But with all its limitations, apt on dpup > PPM on dpup, because PPM is slow and unreliable, and its UI is horrible. Despite all limitations, I think it shouldn't be hard to get apt to produce working installations of more packages, compared to PPM, because the latter doesn't do stuff like running post-installation scripts.

So far, most applications I tried, including Steam (which requires 32-bit libraries), worked! GNOME Software was broken, and it looks like pretty much anything that relies on D-Bus user sessions or stuff like polkit is more likely to fail, because Puppy is weird: it has both system-wide and session-wide D-Bus instances for root, but some applications want to use just the system-wide when when they run as root, so the other applications they talk to use the wrong instance of D-Bus.

When this bdrv thing is merged, I'll update the release notes so they state clearly: this is an experimental feature, or at least, something to use with caution, and never on mission-criticial installations.

Apt sounds more complicated than it would appear at first glance...

Is Pkg a better alternative than PPM?

[dimkr]

Is Pkg a better alternative than PPM?

I'm software engineer for living, and I always think in terms of problems and solutions.

A package manager is supposed to solve a problem: the user's inability to install software. A better solution for this problem would be a fast package manager, a reliable package manager, and so on.

In my experience, pkg's gtkdialog-based UI is slow like PPM, and the installation of Debian packages is just as likely to fail, because pkg doesn't configure packages like apt does. IMHO, pkg isn't a better solution compared to PPM (or at least, not a much better one) in any of the key areas I want to improve.

If I have to choose between PPM, pkg and apt, PPM is immediately crossed out. And because pkg suffers from mostly the same problems, only the third option remains. Is apt ideal? Of course not! Far from it, mostly because Puppy is different enough from Debian to break many packages. But at least, it's not as bad as PPM.

It's worth mentioning that apt has some unique advantages - for example, it's able to install both i386 and amd64 packages side-by-side, allowing the use of stuff like Steam and Wine, which require 32-bit libraries.

[rockedge]

The cool thing is when apt is adapted enough to run in Puppy Linux, it seems to work really well.
I've been using @wiak's apt_sfs_load_fossa_amd64.sfs in a Fossapup64 for many months now. I was able to do a very tricky installation of ZoneMinder in Fossapup64 easily (compared to doing it manually or semi-manually with PPM, never mind compiling and building it from source) and relatively pain free. I am pleasantly surprised everytime I run a full system upgrade or just update ZoneMinder how well APT is working.

There are some issues with this design though, over writting 2 important shutdown scripts and a symlink that prevent a clean Fossapup shutdown or reboot. This is easy to straighten out with some added modifications but that intails using a rough hack script that will replace the proper Puppy pieces.

I have actually complied the package manager XBPS from Void Linux, directly in both a Bionic64 and a Fossapup64 and have gotten it to work as intended. Of course at that point any (most) install by XBPS causes system breakage (mostly by replacing the glibc version). I never added the components to tell XBPS what was installed in the first place and slight differences in file structure design ususally will render a Puppy seroiusly broken.

This was mostly an attempt to influence others to actually look at some ideas for Puppy, as is the KLV project, a lever to use for leverage. Complete manipulation on my part. And now there is a VoidPup rolling along picking up momentum. I knew all along compiling XBPS for Puppy and just sticking it in there wouldn't work. But it sure pointed out some of the challanges @dimkr is facing to getting APT to mix into Puppy Linux fully.

Looking forward to trying out Vanilla when I get some time.

[dimkr]

I uploaded a test ISO built from the testing branch (= not the stable branch) to https://github.com/dimkr/woof-CE/releas ... -9.9.9.iso. A fix that makes it possible to install Wine is missing and some packages will need devx to be loaded, because some of their dependencies are in devx.

The first proper Vanilla Dpup with apt won't suffer from these problems, because the ext4 images include devx. But for now, this ISO is something you can try out and comment on.

EDIT: it starts to look good - https://github.com/puppylinux-woof-CE/w ... 1018341990

https://github.com/dimkr/woof-CE/releas ... -9.9.9.iso

With apt and all new features in woof-CE since October (the time I created the stable branch), Vanilla Dpup 9.1.0 testing builds are only 17 MB bigger than 9.0.24 and nearly all of that size comes from apt and its dependencies.

Even with this extra weight, the size of dpup is still under control: (ISO + devx) are 536 MB in Fossa64, 514 MB in Bionic64, 623 MB in the latest VoidPup64 beta, and 509 MB in the latest dpup testing build. Considering the number of built-in applications this seems like a small difference, but I don't think removing VAAPI drivers, extra fonts, etc' from dpup, in the name of size, is worth it.

[dimkr]

9.1.1 is out! (There's no 9.1.0, the automated releases job on GitHub starts the count at 1 )

9.0.x will still be updated weekly, at least for some time, and the updater won't update to 9.1.x. If you like 9.0.x, you can keep using it.

I updated https://vanilla-dpup.github.io/ accordingly.

Xdialog, the last user of GTK+ 2 except ROX-Filer and Sylpheed (which don't support GTK+ 3) has been replaced with @jamesbond's GTK+ 3 port.

(ROX-Filer and Sylpheed are gone in development builds of 10.x, and it's 100% free from GTK+ 2. But the 9.x series lives on, and the focus is polish and under-the-hood changes.)

apt and Synaptic are now included (they're responsible for the 16 MB increase in size):

The menu is updated automatically on package installation or removal.

@Maybe asked how to install Wine, and now it's easier than ever because 9.1.x uses the "merged /usr" directory layout like Debian and apt can be used to install 32-bit packages alongside the 64-bit ones:

This directory layout change makes 9.1.x incompatible with 9.0.x, so this update is manual.

Support for apt is not perfect, but it works well enough to install a working Xfce desktop:

And KDE works too:

PPM and pkg are still included for users who prefer them. I recommend you to treat apt like an experimental feature. (Maybe I'll remove PPM and pkg in 10.x, after apt is battle-tested enough.)

I decided to drop ISO releases and the 32-bit flavor in 9.1.x, to reduce the testing effort. If anyone wants to fork Vanilla Dpup and create a 32-bit variant or publish ISOs - feel free to do this, as long as it's clearly stated that this is a fork, spin-off, rebuild or whatever.

[williwaw]

@dimkr

What boot parameters does frugalify support concerning saves options? is there a document explaining somewhere?

[dimkr]

@williwaw

It's very limited.

https://github.com/puppylinux-woof-CE/f ... y#overview explains where and how implements persistency. Currently, the directory path is hardcoded.

https://github.com/puppylinux-woof-CE/f ... ot-options is the list of supported options.

[williwaw]

Thanks for the links.

I added pfix=ram, and of course booted into a pristine install without a save.

The functionality I hope to find in Vanilla is the ability to boot into a session with a save, but not necessarily have any further changes accumulate in the save when I shutdown. ie, the ability to rollback or create a snapshot. Is there a way to make a save read only in a build using frugalify?

Alternately, which builds do you anticipate keeping a traditional (non frugalify) functionality in the future?

[dimkr]

The functionality I hope to find in Vanilla is the ability to boot into a session with a save, but not necessarily have any further changes accumulate in the save when I shutdown. ie, the ability to rollback or create a snapshot. Is there a way to make a save read only in a build using frugalify?

I'm not 100% sure what the problem is, but I can recommend two solutions:
1) mksquashfs /initrd/save/upper /initrd/my-previous-save.sfs, then boot with pfix=ram
2) cp -a /initrd/save/upper /initrd/previous-save-backup

The first will build a SFS from your current save. Then, if you boot with pfix=ram, you're stuck in the saved state and further changes don't get saved. The second solution is simply a backup of your save folder: if you boot with pfix=ram, you can move the backup to its original location, then boot again without pfix=ram to start saving to it again.

My intention is to drop ISO releases and 32-bit builds for 9.1.x and beyond, because they're a huge burden. I don't have optical drives, ancient x86 laptops and a complicated setup with save folders+files like some users do. I can't test everything in my limited time. As I said earlier - I'm keeping 9.0.x alive, at least for some time, so if you want an ISO release, this is where you can find it.

Extra boot parameters in frugalify are always open for discussion, if they're truly useful, small and safe to implement.

[Clarity]

Hi @dimkr

... Extra boot parameters in frugalify are always open for discussion, if they're truly useful, small and safe to implement.

Another PUP developer, @gyrog has devoted an appreciable amount of time on PUPs init + shutdown processing.

One of his useful features is the generation & placement of the SAVESPEC file for ease of save-session management.

It turns out to be extremely useful, no matter if the PUPs are booted from its ISO file/IMG file/on-disk files/etc.

• Will this technology continue in this PUP?

• And will it continue in all future WoofCE PUPs as you continue to guide all of its development?

I did test the current Vanilla v9.x ISO file booting in a BIOS QEMU-KVM environment.

I also ask if the 'PSAVE' parm will be maintained, as well, please.

Just curious.
P.S. I do understand the mission of the /upper/save folder in distro's design.

[dimkr]

It turns out to be extremely useful, no matter if the PUPs are booted from its ISO file/IMG file/on-disk files/etc.

• Will this technology continue in this PUP?

No. The only officially supported boot methods in 9.1.x are direct use of the image, as provided, or installation using the included installer.

If you somehow build an ISO image or try to put the image inside a partition and let the boot loader do some magic - you're on your own. Next time you have a SG2D/Ventoy/whatever related question, the answer is probably "no" or "no, and it's your problem because you have a non-standard setup".

[*]And will it continue in all future WoofCE PUPs as you continue to guide all of its development?

I don't know, I don't control or "guide" other developers. And quite frankly, I don't care what they decide to do. Those who want to keep building ISO images are free to do that and I don't interfere with that: ISO images are still the default in woof-CE.

I also ask if the 'PSAVE' parm will be maintained, as well, please.

Right now, it's unsupported. If I see that multiple users want it, and this is indeed the best solution for the problem they are trying to solve, I'll consider adding it.

You need to understand I have limited resources, and I'm trying to keep things as simple as possible. Getting rid of the slowness, complexity and bugs in initrd.gz (especially the init script inside) simplifies things a lot.

[Maybe]

Hi @dimkr!

I downloaded your new puppy and I'm very glad that I can play with him.

I'm having trouble installing this puppy on a clean usb flash drive. I downloading the IMG image to a flash drive using the EasyDD program from @BarryK.

After creating a bootable USB flash drive, when restoring a laptop, the system does not boot, it shows a black screen and a blinking cursor.

Maybe the reason is that my laptop does not support uefi, or maybe the usb flash drive is formatted somehow wrong (but EasyDD seems to serve its purpose well).

I also thought that maybe after creating a bootable USB flash drive, I did not install a bootloader on it. I tried to use the grub4dos utility, but this program gave a message that there is no boot flag in the partitions of the usb flash drive. This is strange because gparted showed that the first of the two fat32 partitions had the boot and efi flags.

Another oddity. EasyOS has the same .img image as Vanilladpup. But the image EasyOS_v_x.x.img easily opens in EasyOS or Easy Pup from @BarryK, like a regular folder or archive. But, unfortunately, the Vanilladpup_v_x.x.img image cannot be opened. I wanted to manually (not using a terminal) copy the files to a flash drive and create the drub4dos bootloader myself. I did this with all puppies and EasyOS before.

Dear @dimkr, please help me. Tell me what am I doing wrong? I can't wait to see the new Vanilladpup.

From Dmitry (Russia)

[dimkr]

Dear @dimkr, please help me. Tell me what am I doing wrong? I can't wait to see the new Vanilladpup.

Did you decompress the image before trying to write it to the flash drive, and before trying to open it?

For example:

Code: Select all

cd Downloads && gunzip vanilladpup-9.1.2-ext4-2gb-uefi.img.gz

If unsure, you can check if the image is compressed using something like this:

Code: Select all

cd Downloads && file vanilladpup-9.1.2-ext4-2gb-uefi.img*

I've tested https://www.balena.io/etcher/ and it decompresses the image before writing it to the flash drive. I don't know if the EasyOS tool does that too.