Is there a document that describes the packages that woof-ce downloads.
I am trying to make a minimal zenial 64 bit iso, and am partly guessing on what packages are needed.
I thought woof-ce had made a iso, but I can't find it.
Where is the iso stored?
I noticed that the xenial kernel is about 70 mb in size.
Is it possible to use the tahr64 kernel to cut down on the size?
Or when the puppy is running in ram, does the size of puppy not really correspond with the size of the kernel?
Questions about woof-ce.
-
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
Re: Questions about woof-ce.
Hello Lassar,
You might try git "rationalise" instead of "testing" because Billtoo has found a recent problem with creating the iso in testing.
I prefer using that smaller tahr 3.14.54 kernel in xenial64 and slacko64. You can build your own with ./kernel-kit/build.sh too.Lassar wrote:I noticed that the xenial kernel is about 70 mb in size.
Is it possible to use the tahr64 kernel to cut down on the size?
It goes into the /woof-out*/woof-output* folder (* being x86_xenial or whatever you chose) when ./3builddistro-Z is finished.Lassar wrote:I thought woof-ce had made a iso, but I can't find it.
Where is the iso stored?
You might try git "rationalise" instead of "testing" because Billtoo has found a recent problem with creating the iso in testing.
Re: Questions about woof-ce.
If you load the puppy sfs into ram at bootup it will use that amount of ram space. Handy for if on a external/removable device such as a CD/DVD ... where you can eject that to free up the device.Lassar wrote:when the puppy is running in ram, does the size of puppy not really correspond with the size of the kernel?
If you just let it run without copying to ram at bootup then it will read in what it wants, when needed. More often what's read in remains in cache (memory) once read in once. But does mean that the device being read from has to remain available during the session. If you're frugal booting from HDD then that's not a issue (unless if a external HDD).
The first is slower to boot, but loads a program quickly the first time its run, but is much the same time to load the program at subsequent re-runs, the second is quicker to boot, but is slower to load a program the first time its run .... and generally uses less ram space (as not all programs/libs will be read in at every session).
I HDD frugal boot, so I use the second choice ... and even with very large main puppy sfs files it still runs very quickly. I have some that are up at 2GB+.
Currently I'm setting up a 64bit based on Debian Live (that includes non-free firmware). Early days yet and currently just more or less just rox and jwm, where the puppy package manager is synaptic, alsa is instead pulseaudio ... and of course it has access to the full debian stable respositories. Its also multi-user (Ctrl-Alt-Fn and you're at another console that you can log in at ... and switch between sessions). So far with most of puppy scripts copied across into that its up to around a 400MB main sfs filesize, but as above it runs very quick. Bootup needs sorting however, as systemD-analyze is reporting a 21 second bootup time Wicd (network) looks to be the bottleneck as that's showing as the outstanding (furthest left) when I do a svg image dump of the analysis.
Long way to go yet to replicate typical puppy style/functionality. I'm still pondering whether to just add programs into the main sfs, or have them as separate sfs's. More inclined to the former as I quite like running with a empty main sfs and everything in the save file. But that will bloat out the size (but again somewhat trivial if using HDD).