Puppy Linux Discussion Forum

sunburnt · Joined: 08 Jun 2005 Posts: 5089 Location: Arizona, U.S.A.

Yes; I said a properly setup standard loose file install would have read-only and read-write partitions ( or dirs. if installed to a single partition ).
And yes, a new virused file can be made or copied over one in the SFS file. That`s not the SFS files fault, it`s the loose file system of the Save file.
You`re sort of mixing apples with oranges, but you did say "in Puppy". So "in Puppy" you are correct of course, the SFS file only makes for quick recovery.

When I say Squash files I don`t mean SFS necessarily. I usually specify. Though SFS files are one type and could be included in some cases.

Consider... If the Squash file is not unioned with a Save file or any loose file system then it`s hard to hack. But access to the partition could.

disciple · Posted: Sun 26 Feb 2012, 04:11 Post subject:

Q5sys · Joined: 11 Dec 2008 Posts: 1126

Moose On The Loose · Joined: 24 Feb 2011 Posts: 970

sunburnt · Joined: 08 Jun 2005 Posts: 5089 Location: Arizona, U.S.A.

Moose On The Loose; Yes, aufs will run more than one union at a time. Config. files and app. installs should be separate. Put work in a dir.
I see what you`re getting at here and I`ve thought the same in the past. Then I realized that the union is an unnecessary complexity to be rid of.

disciple; As I said, a non-unioned Squash file is safe from the union`s effects. It`s compiled with --prefix (/path/mountPoint) so it works when mounted only.
ChoicePup did this and it worked very well. As typical with Puppy variants it`s no longer with us, but it`s "proof of concept" is what`s important.
Now if Puppy package builders ( and Barry? ) would use it... Problems solved.

amigo; I agree again. A CD / DVD is a horrible boot / run device for an O.S. And the H.D. is the old standard, a USB flash drive is a more modern device.
A PC with 2GB or more of ram doesn`t need a swap, so it`s suited for flash. Flash isn`t perfect, but... Mass storage is still the realm of a H.D. of course.
PXE booting`s great for large groups of PCs, but not so much for 1 to 3 PCs.

disciple · Posted: Sun 26 Feb 2012, 20:42 Post subject:

amigo · Joined: 02 Apr 2007 Posts: 2647

Something is wrong here. Two or three people are starting to agree with me sometimes... Was it something I said?

Aitch · Joined: 04 Apr 2007 Posts: 6815 Location: Chatham, Kent, UK

nice, amigo...

Aitch Smile

amigo · Joined: 02 Apr 2007 Posts: 2647

+

Not used to getting much love around here...

greengeek · Posted: Mon 27 Feb 2012, 12:39 Post subject:

.
Interesting topic. Some heated debate.

I vote for two things:

1) A continuation of the current fragmented status quo.
2) A newly defined package management/control system that satisfies the devs who see a need for change.

Why both approaches? Because I would compare Puppy’s development to evolution itself - variety is hugely important. Greater central control brings less variety. There is no reason why multiple “Puppy breeds” cannot co-exist.

Maybe some devs want a tighter pedigree (fine - no problem), but don’t forget that mongrels are often more appealing. I’m happy to see a “Pedigree Puppy” evolve, as long as other puppies are free to interbreed whatever they want under the Puppy name.

Sometimes one puppy breed survives because a single dev keeps it so.

Look at what ttuxxx has done with 2.14x It is perfect for those who use it and like it. And of course there are many other individual puppies in use on different machines, and those machines would be in landfills if not for those mongrel offshoots of puppy. It is a good history, and there will always be room for offshoots, even if a tighter “core” is built into other puppies.

So, if some devs want a different approach then maybe it is necessary to define a project involving a group of likeminded devs who wish to collaborate on a tightly controlled, new line of Puppy.

So, if some devs would like a tighter PPM, what will be it’s structure?

(sorry for the use of the word “mongrel”. It sounds mean but is intended respectfully)

sunburnt · Joined: 08 Jun 2005 Posts: 5089 Location: Arizona, U.S.A.

amigo; You`re knowledgeable and so opinionated. A good place to be. This tends to make one brutally honest, but I`m not saying that`s you...
This all of course makes a target of you. My same problem is with politics. Different parts of anything are seen as good or bad, depends on your view.

My continued view is that there`s a lot to like about Squash files. There`s many ways to use them in a O.S., some fix problems, some don`t.
Read-only files should be in a Squash file without a writable union over it. This makes everything in the Squash file "rather" secure compared to Puppy.
Don`t use a union to add execs. and libs., use the paths and added dirs. /root/my-applications/bin:/root/my-applications/sbin ... /root/my-applications/lib
If these paths are at the end of PATH then what`s added can`t overshadow anything. If you want it to act like Puppy does, just put these paths at the start of PATH.
To change what`s in the Squash file a simple remake takes a few minutes. Not much worse than installing many of the .pet apps., all in all...
I hate long dir. path names "my-applications and my-documents". Use /root/apps. and /root/docs instead.

amigo · Joined: 02 Apr 2007 Posts: 2647

I actually (optionally) use a couple of SFS's in my distro. wait, let me say exactly what I mean: I use file-system images which use the squashfs. I use them (optionally, remember) for the kernel-source and for kernel-modules -where read-only is usually no problem. *But*, they are part of a package so that the package-accounting still works. I only use them for these large components (kernel-source 460MB unpacked and modules ~60MB at the moment).

My arguments have not been against the use of squashfs in itself, in the right places. I'm against the idea of composing them from a mongrel-mix of files from all over the place without any way to account for them, or more importantly, easily reproduce the image when needed. I certainly see the logic in combining several *packages* inside an SFS, but including a bunch of maybe-duplicated or mixed-source libraries is not so good. You know, you could always just use a ramdisk or tmpfs and 'install' packages there on the fly, too. I just think that most of the ideas in use for adding 'modularity' to LiveCD's are a little crude.

It's kinda like the arguments about using AppDirs (or other similar concepts), where everything goes in its' own directory -which necessarily are gonna be non-standard locations -vis-a-vis PATH and LIBRARY_PATHs. Libs should nearly always be put in the standard locations -otherwise every program which is gonna use them must be told where they are. This is fine when you need to have multiple versions, for example, but should be avoided when possible. AppDirs, if placed under /opt are in the correct place, and it is 'legal' to create a link in /opt/bin to point to them -that means you don't need wrappers and PATH-setting for every program contained in an AppDir.

Q5sys · Joined: 11 Dec 2008 Posts: 1126