(old)Puppy Linux Discussion Forum

amigo wrote:But wait, I want to use /usr mounted on NFS and run without X as I am building a server. Can your init system do that? And, if I run as you suggest, what happens if the X server won't start on my video hardware? And what about if I want a sane multi-user system where every users needs to login?

I _could_ add those, but probably won't unless sponsored (I don't think this is something most users really want). X needs root priveledges anyhow and I have made the Xserver and window manager configurable so that gdm, slim or some other display manager could be used for login and wm selection. The way I set up my initramfs, everything is outside of /usr (however it requires a special build of X, wm and terminal emulator since they expect for certain things to be in /usr/share/...) This allows the rest of the system to be bootstrapped however you wish inside the terminal emulator.... and since the whole X environment is <500kb compressed it can be fit inside the kernel in order to enable a tftp boot on systems without a hard drive with /usr being mounted via nfs/cifs/9p and $HOME as well or built from /etc/skel. I want to look into Rob Landley's inittmpfs patches though (similar to tinycore's patch) to reduce the RAM usage and allow swap backing but mostly to not waste 8MB if / is remounted for a full Xorg+glibc system from your favorite distro.

Uncle Barry outdoing himself again.

Retirement eh?

I think he BK has an agenda mates Ha! Ha!

"""""""

Quirky Snapshot Manager

http://bkhome.org/news/?viewDetailed=00034

" The Quirky Snapshot Manager takes a snapshot of the entire partition and saves it as a compressed file. You can "roll back" to that snapshot whenever you want.
That's the essence of it.

Furthermore, there can be any number of snapshots, a whole history of them, and any earlier snapshot can be rolled back to.

Here is the GUI: "

" Comments:
Snapshots limit Posted on 26 Dec 2013, 20:18 by admin
One point that I should qualify: if the limit is set to 5 snapshots, it does not mean that after taking 5 snapshots, you can't take anymore.

You can keep taking them.

What happens is that the older snapshots get deleted. So, you have 5, the latest snapshot, and four earlier ones (which are delta-files). Any older snapshot is gone. '

Chris.

If we wanted continuous snapshotting, we should just use a versioning file system. Its great that Barry is finally getting to research the stuff that interests him though, he always end up discovering something (not always related, but usually interesting and/or important).
I would probably have just used find to get only the files with timestamps newer than the last snapshot which is probably sufficient in a system with union filesystem capability and would eliminate the need for an arbitrary number of snapshots.
To minimize the snapshot size you could use diff or a binary diff depending on the file type (edelta or xdelta)
The cool part is you could start with your original snapshot and selectively apply filters to merge later snapshots.
... but thats too simple and obvious, so I assume (and hope) it has already been done.

dejan555 wrote:So wanderer why such haste for "CE" ?
Are you afraid puppy is going to disappear? Because it's not.

Wanderer started this thread when Barry went into retirement (and disappeared for about 2 months) and there was a genuine concern for Puppy's survivability.

His "CE" proposal was to spark interests among people here to come together and build a "community-built" puppy (CE is probably isn't the best choice for the name; as it is already used for something totally different); proving that Puppy can continue to exist without Barry. His was a practical idea and he got on to build and released a few ISOs himself while people were still talking and debating about the "future of Puppy without Barry".

Sure, his released CEs were based on old kernels and probably isn't up to the quality that Puppy are usually held to but remember that wanderer himself admitted that he is not a "dev" and he is still learning.

What is more important that the ISOs released by wanderer is that his action inspired others to do something too - e.g to come up with Woof-CE (=rightful descendant/fork of Barry's Woof) and new Puppy releases based on Woof-CE (dpup, the new slacko, and others).

Now that Woof-CE is going strong, Puppy based on Woof-CE are available; there is no more questions of whether Puppy will survive (it will). In my opinion wanderer and the thread has achieved his objective. It is time to close and put this thread to rest.

Thank you wanderer. You live up to your name

EDIT: Of course, if wanderer or anyone else wants to transform this thread into discussion of a CE puppy in the usual meaning of the word ("take an existing base of official Puppy and mold into a version based on community feedback"), then feel free to do so - I'm not discouraging that at all. Just that, for me, post Barry, all mainline Puppies already feels like CE .

Well said James Bond the new woof CE is fantastic and I thank Wanderer for his iniative in starting this thread and agree their is now Slacko and DPup etc so thank you for your efforts to spur others on.

I know I didn't agree with the Pup'n'go thing but he still achieved what he set out to do even if it may be a little different to his original idea of one CE distro.

I agree one CE Distro days are gone we have exciting variants.

BarryK, a few years back, passed the baton of the official "Puppy" monocle to the team of @Playdayz plus @01Micko. They produced, what may be considered, the first "Community Edition" of Puppy Linux.

@Wanderer, thru this thread, took on the task or attempting to replicate that same theme that Puppy528 did for Puppy Linux back then. In the past couple of months, I have noticed as has just been already pointed out below, how, even that PUP528 too, has expanded and upgraded as well as other developers taking advantage of ideas inspired by this thread.

There should be an Official Puppy Linux distro of some sort
Should there be a continue to march forward in a new thread, one idea is to "consider" the march to be an upgrade or replacement of THAT older OFFICIAL PUPPY DISTRO that Barry had passed the baton on. Maybe, even, get that baton passed to the new Puppy Linux distro (for 32bit. and 64bit PCs) so that entering new users would/could identify an official version with a sense of clarity as well as gaining some understanding of the various other disrto offering generated in this community..

Lastly, we should STOP referring to Puppy Linux as something for OLD PCs. What would be appropriate, maybe, is to say that official Puppy Linux will live harmoniously on any PC (not just old ones). The whole idea of this constant focus of old, is not always seen as something some newbie may want. Puppy Linux exploits any/all hardware it sees when booting for user advantage (I do understand drivers and kernel provisioning, BTW).

@Wanderer, again, THANKS! This thread has caused a rethinking and good ideas to be tossed on the table for understanding, discussion, review, analysis, and products (WOOF and distros)

Happy Holidays to everyone as we progress into a new year. I think, this thread, if for no other value, has caused a greater sense of harmony in approaches with the multitude of contributors trying to help.

Cheers!

We can also STOP saying that Puppy Linux is intended for use as a live CD or frugal install, but not as a full install.

nubc wrote:We can also STOP saying that Puppy Linux is intended for use as a live CD or frugal install, but not as a full install.

But, stress that the new user may want to become familiar with Puppy using a Live CD BEFORE they do a full install.

What @TLChost offers is a very comfortable starting position for anyone coming to Puppy Linux. I have been a Live users for all PUPs that I run on a continuing basis. I do recognize and have tested, both, frugal and full. But, I have NOT found a good reason for me to move from running Live because all of my PCs have enough RAM to accomodate the PUP systems I run. Further, there are 2 PCs that are never (sometimes rarely) booted after initial setup.

What I think, as is pointed out by @Nubc is that the PUP announcement might need addressing such that everyone clearly sees that PUPs can run in any one of the following 3 manners of use:

• LiveDVD - where the booting DVD will load into RAM for PUP use, while providing a simple method to save one's work.
• Frugal - where the contents of the ISO can be transferred to the HDD/USB media to provide booting and a simple method to save one's work.
• Full - where the system can be installed to the HDD/USB and used in a traditional fashion.

Just some ideas to consider as we are challenged to make it simple for users to have a good clear path to some level of comfort in their PUPPY use.

One of the problems the Linux industry is wrestling with is the transition from the older-style BIOS approach to UEFI. This is going to have an impact on the decision process at boot-time such that some form of consistency will need establishment in Puppyland addressing this. This would mean that no matter which PUP is selected, the steps to do Live, Frugal, or Full would be the same for every PUP on ANY PC system.

Thanks, again, @Wanderer and everyone, direct or indirect.

anikin wrote:

Ghost Dog wrote:Simargl as Package Management Lead Dev

Why does it have to be simargl?

A real package manager - as opposed to a small number of user-compiled packages in PPM - seems to be something people want.

Didn't Jejy69 do something similar?

Ghost Dog wrote:

anikin wrote:

Ghost Dog wrote:Simargl as Package Management Lead Dev

Why does it have to be simargl?

A real package manager - as opposed to a small number of user-compiled packages in PPM - seems to be something people want.

Didn't Jejy69 do something similar?

However. PPM does have the advantage that it is simple enough that even I can understand it. It works for most people and so whatever new system is used has to be about as simple from the users point of view at least and any new complexity must come with some massive advantage to make people want that instead of PPM. Remember the average PC user is the target.

Maybe PPM could be reconfigured like a two-pane browser with the easy (traditional) method on the left, and a portal to the hard way (using other distros packages) on the right.

Then you could have confidence in the standard packages that are part of the traditional puppy PPM, but if you wanted to you could also have a go at more 'experimental stuff' by following the processes outlined in the other pane in order to get hold of non_locally_compiled_and_tested foreign packages.

Best of both worlds. Is it possible?

Ghost Dog,
Discussing PPM is one thing. Using the the discussion to whitewash simargl is quite a different ball game. Let's stay focused on what's good for Puppy and the community, and not waste our precious time on their detractors.

greengeek wrote:Maybe PPM could be reconfigured like a two-pane browser with the easy (traditional) method on the left, and a portal to the hard way (using other distros packages) on the right.

Then you could have confidence in the standard packages that are part of the traditional puppy PPM, but if you wanted to you could also have a go at more 'experimental stuff' by following the processes outlined in the other pane in order to get hold of non_locally_compiled_and_tested foreign packages.

Best of both worlds. Is it possible?

The current PPM will let you instal foreign packages. I think it does it about as well as can be expected. Perhaps a better thing would be to work out a way to somehow sandbox the foreign packages so that if they install a library their library won't mess up another program's operation. Since all install files (RPM,DEB etc) are sort of compressed archives, it should be possible to make a script look at the contents and work out how to make things work.

I haven't had my morning coffee yet but part of the method I think will work is to add to the library path with a script that runs the application. If where the libraries got put is placed first, only programs that specify the library with a full path would have trouble.

Moose On The Loose wrote:a better thing would be to work out a way to somehow sandbox the foreign packages so that if they install a library their library won't mess up another program's operation.

What a great idea. Maybe the 'foreign' portion of the PPM could be nothing more than an sfs - so that it allows the foreign package to be run in a nondestructive way, then discarded at next boot if unsuccessful. Sort of like a "static_package_on_the_fly"

greengeek wrote:Maybe the 'foreign' portion of the PPM could be nothing more than an sfs - so that it allows the foreign package to be run in a nondestructive way, then discarded at next boot if unsuccessful. Sort of like a "static_package_on_the_fly"

Things other than sfs and {2,3,4}fs files can be unioned. For instance you could install all Debian Wheezy packages to /mnt/sda1/wheezy and union it to / ... likewise for any variant of any distro.

technosaurus wrote: For instance you could install all Debian Wheezy packages to /mnt/sda1/wheezy and union it to / ... likewise for any variant of any distro.

If that process was used - how easy would it be to "un-union" or unload or disconnect those packages if they started to show an undesirable effect and the user wanted to get rid of them? I was thinking that an sfs was easier to disconnect (unload) but is an sfs really no different to the unioning you have described?

An SFS is a file system image. You can make a file system image using any file system you like. Any of them can be used any of the ways normal file systems are used -including adding them to a union mount -either as read-only or as read-write if the file system permits that(SFS, cramfs, and cromfs do not).

amigo wrote:An SFS is a file system image. You can make a file system image using any file system you like. Any of them can be used any of the ways normal file systems are used -including adding them to a union mount -either as read-only or as read-write if the file system permits that(SFS, cramfs, and cromfs do not).

For file systems that are read only, having a writable layer above them makes it look to the user like a write can be done. Making a utility that can make a new SFS from the old with the changes can be added as a "rebootish" option so that the user can do it on demand.

I want everyone to understand that I am NOT a Linux distro/application developer. But, over the years, I have heard and understand rationales presented for compressed filesystems as well as use of SFSs as well as unioning and other ideas and implementations.

One of the things that is constantly thrown onto the table is the notion of install packages "trashing" a running system.

Here's my problem
Excepting for the often times when a newer distro is released and where a user tries to use/install the new distro to the PC using the old distro's older save-file(s), I have not witnessed any general user complaints of installing package(s) that locks or crashes their Puppy distro system.

Questions

• Even though its a conceivable occurrence, are package installation crashes happening?
• And if so, at what scale?
• Does the current package system really need a re-architecture?
• Should or will any new approach be simple for new and experienced users to extend PUPPY with subsystems and application should a user desire?

Curious