+1amigo wrote:2byte gets it! Very well put, fellow.
I spent a few hours trying to connect listed builtin files with right pet.spec files in woof before giving up. I hadn't realized it's full of debs.
This looks liked good progress -Aitch wrote:At least this discussion seems to be drawing package management to a focus, so that, at least must be good, as long as agreement is reached on not doing things that are causing problems, right?
I don't feel it's Barry's duty to do anything, but he should do what is best for Puppy, which would be to help.As devs do you not feel you have a right to ask Barry to help sort out the chaos he's created, or risk good devs forever leaving/forking, in an effort to create a good working, useable and updatable OS
That is one of the things a "real" package management system would hopefully fix.Puppy is reduced to sort of being a throwaway OS which you don't so much update, as replace with a slightly less broken later version....
Nobody is forcing you to upgrade, but it is much better then the current system, as Aitch called it, "being a throwaway OS which you don't so much update, as replace with a slightly less broken later version....". You can currently overwrite woof-installed packages (and it usually works, if there aren't any extra dependencies needed).Here's the thing. Package management is highly problematic with a system that specializes in frugal installs. The right way to upgrade or change out packages is to rebuild the whole system - which is not a job for the package manager. The PPM should be simple and help you keep your save file small.
Are you talking about a package list inside a package repository? Package lists are needed for description searching and looking for package dependencies before downloading the package. Every distribution I know of that has a repository system has a package list - there is no reason why Puppy can't have one."connect listed builtin files with right pet.spec" This illustrates why the idea of a central database of package specs is un-workable. They require lots of work to compose and are rarely up-to-date -they also have no easy way of reflecting past their status.
amigo wrote:jemimah, I believe that a re-think of what comprises a 'frugal' installation would make package-management still possible. For instance, drop the 'frugal' part and simply install the whole system to a disk-image -no need for a save file, only needs a tiny initrd, and uses no RAM for parts of the system. Simply put, a loop-mounted system-in-file. Only the kernel and small initrd would be separate -just as now. I built just such a distro before -nooby would have loved it!
Even without some of the above, a different tactic with the initrd would make it possible and workable to install packages on a 'frugal' system. Even most LiveCD distros which are based on 'real' distros, do a better job with their intirds. The thing is, that by the time the kernel mounts the 'real' root, the system should appear completely normal -where even the normal init scripts work as expected -only the fstab looks different. And this is true whether or not union mounts are used or some other system of integrating various pieces into what looks like one 'whole'.
I think any system can be individually tailored; I use my own checks, uninstaller, etc... Remastering is simple, but rarely needed. The present system is light years ahead of something like TC.jemimah wrote: Puppy is fantastic for the niche it's designed for - but it's not great for anything else. Trying to fix that is just going to be an exercise in futility.
Just my opinion, carry on.
You want to run from ram if disk I/O is very slow or if disk writes are undesirable - like USBflash, CD, or old hard drives, or maybe if you want to be able to shut down your disk to save power.amigo wrote:"from RAM on low spec machines" I never have been able to understand this rationale. If a system is weak, whhy sould one want to occupy 'any' RAM which is not necessary?. Especially when you consider that, onve a program has been run or is running, there are 'two* copies of it in RAM. The only penalty which one pays for not running in RAM is the startup-latency which only occurs the *first* time the program is started. Plus, there are other things which can be done to improve those latency figures.
Honestly, I'm not exactly sure what all features are implemented by Puppy's 'frugal' installations. My impresion has been that some parts of the system are located in the initrd and may or may not be overlayed by the contents of the save file. Does the save file only include config files and other highly-selected items, or can it also contain installed programs? Is the save file an sfs? If so, I find that very wasteful in one sense -it means you have to always create a copy of it, in RAM or on-disk, to be able to then update at the end of your session. Maybe this is the 'crux' the lenghty times to save on shutdown. I find the idea of using a normal FS-image using ext2/3/4 much more palatable -you can write to it directly and continuosuly, re-size it, etc. With ext4 you can even have transparent on-the-fly compression. You can also achieve compression on ext2 or ext3 by using a kernel patch ('e2c' project on SourceForge). You can also use compression and even an alternative to union-mounts with the new brtfs file system. In short, the drawbacks to not using an 'sfs' can be worked around in several ways, if that is the bottleneck.
My impression, taken from a couple of polls which have been done here, is that most Puppy users use a frugal installation, and that they do that because of the ease of manually installing it, if wanted, and/or because it allows them to have a Puppy installation co-reside with a pre-installed Windows OS without the need for any partitioning and less out of having to work with a low-spec machine. If that is the case, then the use of RAM as a hard-disk substitute would seem to be a bad choice. And the use of write-only save files -if that is the case.
The light-weightness or agility of Puppy is mostly due to the non-use of kde, gnome and other such bloated software. There is a significant and 'feelable' speed-up when starting programs for the first time which are in RAM instead of being read in from disk. But, they all have to be loaded into RAM during boot-up which is why it is difficult to make Puppy boot up faster. My kiss-5.0 starts, from grub-prompt to GUI login, in right at 10 seconds here (on a Pentium IV) -even though it has to read everything from disk, link it all, etc. I think it gets there faster than if I spent time loading it all into RAM and then load and link it from there. And I can still improve the boot-time a little, I think, without going to extremes.
At the very least, it is pretty obvious that most Puppy users *do* use a frugal install, so more effort should be put into making that go as smoothly and quickly as possible -perhaps by having an initrd dedicated to frugal installs, instead of wasting hundreds of lines of code and time, by checking for all the other possible way to run Puppy. Things like pfix=ram are nice and useful, but not often needed and mostly exist as a work-around to fix other design flaws -in my hardly-humble opinion, LOL. In this same category, I would put things like 'use a separate save-file for separate users', when the obvious solution was there all along -have a real multi-user-capable system just like everybody else. That capability had to be built *out* inetntionally, and makes it completley unwise to use Puppy as a server or for other mission-critical purposes. It also makes it difficult, if not impossible without patching or hacks, to use some software like Chrome browser, etc.
Every single drawback goes back to a concious design choice which was made. And every advantage which Puppy may have over any other distro, could be implemted in such a way to avoid the drawbacks. Wanna run as 'root', autologin as root, autologin as root straight to the desktop? No problem. It doesn't mean that you have to completely eliminate the choice of doing otherwise.
The save file or the main .sfs file (e.g. pup_411.sfs)?Honestly, I'm not exactly sure what all features are implemented by Puppy's 'frugal' installations. My impresion has been that some parts of the system are located in the initrd and may or may not be overlayed by the contents of the save file.
The save file contains installed programs and every other change you make to the system.Does the save file only include config files and other highly-selected items, or can it also contain installed programs?
No, it is an ext2 or ext3 filesystem in a file. Maybe even ext4 these days.Is the save file an sfs?
There is usually no copy of the save file - it is not loaded into RAM.If so, I find that very wasteful in one sense -it means you have to always create a copy of it, in RAM or on-disk, to be able to then update at the end of your session.
The only shutdown problems I've heard of are specifically related to filesystems not being unmounted; lately I think just Samba mounts.Maybe this is the 'crux' the lenghty times to save on shutdown.
That's what the save file is.I find the idea of using a normal FS-image using ext2/3/4 much more palatable -you can write to it directly and continuosuly, re-size it, etc.
That sounds interesting. What would the performance be like on an old, slow machine?With ext4 you can even have transparent on-the-fly compression. You can also achieve compression on ext2 or ext3 by using a kernel patch ('e2c' project on SourceForge). You can also use compression and even an alternative to union-mounts with the new brtfs file system. In short, the drawbacks to not using an 'sfs' can be worked around in several ways, if that is the bottleneck.
You have a good sense of humor. What the poll indicates is that, with a very few rare exceptions, nobody really cares what's happening under the hood, and even fewer really understand it. That's actually a vote for leaving things pretty much alone.noryb009 wrote:We have kind of gotten off topic.
As I see it, there are 4 steps for making a new package format:
1) Decide the format (a new format, judging by the poll)
Simply incredible...noryb009 wrote:We at least took a sample* of the signed up "Suggestions" board readers. 16/25 people voted for a new format, which is 64% - almost two thirds of the users. You are welcome to put up a poll in a more viewed area, but until we get more data, we should to use the data we have - which is to create a new package format.
* I can't link directly on the forum as the link contains brackets. Real path is: http://en.wikipedia.org/wiki/Sample_(statistics)
The "fat initrd" was pretty much a passing thing. 99% of the time a small initrd is used.amigo wrote:Thanks for helping out there with the meaty answers. So, when you boot a 'frugal' installation, the intrid (a fat one?) is used, setting up the main sfs as the root partiton, then the save file is unioned above that? Is that about the flow of things?
jemimah, 2byte just posted that a few responses agojemimah wrote: This is old but mostly still accurate:
http://puppylinux.com/development/howpuppyworks.html
2byte wrote: Jemimah, I agree Barry should not rewrite woof to suit us, but I don’t think he would have to. I am not a woof expert by any means but there has to be a place during the build when the pets and packages are being added where a branch could be made to a separate routine that could assemble the package/file info for use in the database. If we presented a plugin bash routine that would do this surely he could call it from woof at the appropriate spot.
The plugin could produce a record of the package/pet with a complete list of files. The file paths, permissions, owner:group, size, time added, and md5 could be produced. Probably the package type and, if it’s a distro package, where it came from could also be recorded. If the package/pet has a dependency list, build script or info, or pinstall or doinst script then that could be recorded too. At the very least we could produce the package name and related file list.