Questions about woof-ce.

A home for all kinds of Puppy related projects
Post Reply
Message
Author
Lassar
Posts: 235
Joined: Tue 08 Jul 2014, 20:01

Questions about woof-ce.

#1 Post by Lassar »

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?

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

Re: Questions about woof-ce.

#2 Post by Sailor Enceladus »

Hello Lassar,
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?
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 thought woof-ce had made a iso, but I can't find it.

Where is the iso stored?
It goes into the /woof-out*/woof-output* folder (* being x86_xenial or whatever you chose) when ./3builddistro-Z is finished.

You might try git "rationalise" instead of "testing" because Billtoo has found a recent problem with creating the iso in testing.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

Re: Questions about woof-ce.

#3 Post by rufwoof »

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 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.

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.

Image

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).

Post Reply