(old)Puppy Linux Discussion Forum

Sailor Enceladus wrote:

saintless wrote:We are not woof-ce developers and none of them seems interested with my ideas.

CE means "community edition", it's probably closer to this than your definition above: https://communitywiki.org/wiki/DoOcracy

But of course, how did I miss this?
Then I have to answer my own questions because I'm part of this DoOcracy and also seems I'm a woof-ce developer, right?
What is the point to ask questions about woof-ce then? And what is the point to have this thread open for discussion?

Toni

Hi saintless.

I think you are one of the few people on this forum with the credentials,
expertise and ability to implement your idea.

Don't wait for a woof-CE "policy". Just do it! Dive in!

Besides, the "Community" in this "CE" acronym can probably be counted on
"one's fingers and toes", to borrow an expression from Linus Torvalds.

It's certainly a community compared to Barry Kauler developing Puppy by
himself, but It's a community of developers rather than "the Puppy
community" at large.

My 2¢. Best of luck. BFN.

musher0 wrote:Don't wait for a woof-CE "policy". Just do it! Dive in!.

Thanks musher0.

I usually do that. Just liked to ask first if including kernel from different distro could cause some problems with special puppy scripts. There should be some important reason for compiling own puppy kernel each time. I guess I will have to find out for myself.
All the best!

Toni

saintless wrote:Just liked to ask first if including kernel from different distro could cause some problems with special puppy scripts.

Hi Toni....

Puppy relies on aufs - Puppy built kernels include aufs...if the other kernels you are considering don't include aufs then they won't work in Puppy.

@gyro has recently started some work looking at whether overlayfs could be used instead of aufs but has already identified that overlayfs is not as capable as aufs and therefore a Puppy using overlayfs would "behave differently"....

Cheers
peebee

Thank you peebee.

Overlayfs is the aufs replacement used in live-boot and I'm not sure it was a good default choice to replace aufs. But if aufs kernel module is the only thing to be aware of - then Puppy should work fine with standard Debian kernel (aufs-dkms package for building module is still available in latest Debian).
I will do some experiments. Thanks again!

Toni

saintless wrote:But if aufs kernel module is the only thing to be aware of - then Puppy should work fine with standard Debian kernel (aufs-dkms package for building module is still available in latest Debian).

Hi again

I'm not sure it's that simple (but that may be my lack of understanding) as I think the kernel has to be built with all the patches for aufs - this is what kernel-kit in woof-ce does to build the Puppy kernels.......

BTW - it takes about 60mins to build a new Puppy kernel on my desktop (very average power) so its no great burden to make them - kernel-kit has had quite a bit of work done to it in recent times and makes the process pretty easy.

peebee wrote:I'm not sure it's that simple (but that may be my lack of understanding) as I think the kernel has to be built with all the patches for aufs - this is what kernel-kit in woof-ce does to build the Puppy kernels.......

Hi peebee.

The standard Debian/Ubuntu kernel should have all patches needed to boot with aufs. Debian-live also uses aufs (and also options to boot with unionfs and now overlayfs).
But seems someone already did this in woof-ce even without aufs:
https://github.com/puppylinux-woof-CE/w ... 81958a516e

You can't share a good idea lately. Always someone else did the same and better before you

Toni

Hi Toni,

A bit off-topic on my part (well definitely off-topic since not woof-ce, just kernel related): I have had a similar thought about tiny core linux who also compile their own kernel even for dCore which otherwise relies mainly on underlying Debian/Ubuntu reps. Wish they just used standard Debian or Ubuntu kernels for all the advantages you mention of bug/security fixes and so on. Surely the increase in Puppy (or tiny core size) would not be significant enough to make that the reason for all the work re-inventing the wheel/compiling customised kernel). The Linux kernel is just the Linux kernel, the other aspects of the underlying operation and look and feel of the distribution basically remain Puppy however the kernel has been made.

Compiling custom kernel is I suppose just that little extra step in an attempt for smaller distribution size but maybe one unnecessary step too far in terms of lots of effort for little advantage. Like you said, Debian kernel has provision/mechanisms for providing aufs support, so not a reason to need customised kernel compiling (and lots can go wrong with customised builds - it is so important and complex - better to rely on bigger development team for that).

Using stock kernels would have no negative effect on the features Pelo talks about - the 'passengers' product result should be pretty much identical, whether stock or custom kernel is used in the build. Passengers want something that 'reliably' works - well-maintained stock kernels much more likely to guarantee that result longterm.

William

Come to think of it... if you want the smallest possible system then the kernel should be compiled for a specific machine, for its specific hardware, for efficiency and to avoid the need for unnecessary external-to-kernel hardware driver modules. Otherwise, any kernel, for general use has to be somewhat general purpose.

A Puppy system could be built a little bit smaller for a specified machine hardware, but generally not significant enough to justify the effort. Actually, it is more likely to be developers (not passengers) who would consider customising their own systems in that way - lots of tinkering and risk in terms of stability/security is involved - the kernel obviously being a key component to get right so, for all but the tinkerers/developer-hobbyists, using well-maintained stock kernel should be preferred approach. Hence I don't understand Pelo's negative remarks regarding use of stock Debian kernels (or well-tested kernels from other major Linux system distributors) ...

I personally have a reasonable amount of technical proficiency, but still I would prefer to use stock kernels most of the time because its safer, easier, and leaves time for doing other things of more importance getting my system how I want it. It also means I can steal apps/modules/libs from the bigger distributions with much more certainly they will work as expected (particularly if I am also using lib components from these same distributions). i.e. customised kernel is a negative, not a plus

Hi William, nice to read comments from you again

mcewanw wrote:Come to think of it... if you want the smallest possible system then the kernel should be compiled for a specific machine, for its specific hardware, for efficiency and to avoid the need for unnecessary external-to-kernel hardware driver modules.

Actually Puppy-Rus-A from sfs has this tool. It makes very small custom kernel for the machine you run the tool and only the modules in use. I wrote about this long time ago in some of the DD threads. Maybe Puppy has similar option but I'm not sure.

Running official main Distro kernel is a big advantage regarding security fixes in my opinion. But adapting Puppy init to boot different distro has also some advantages from my testing. But lets not continue this discussion here. Maybe I will open new thread after some more testing.

Done:
https://github.com/MintPup/Puppy-Linux/ ... ian-kernel

Toni

I tried a "slacko_current" build yesterday. If you want to try to build a slacko-current yourself, I attached the folder I used for woof-CE below in a tar.gz, you just throw the folder into your woof-CE/woof-distro/x86/slackware folder with the 14.x ones, then when you run ./merge2out a new "current" option should appear for 32-bit. I added libedit, libXfont2 (xorg broke without this) libinput and libwacom for xorg_base_new, and a bunch of libs from 14.2 that some slacko pets still rely on into the adrv.

saintless wrote:Hi William, nice to read comments from you again :)

mcewanw wrote:Come to think of it... if you want the smallest possible system then the kernel should be compiled for a specific machine, for its specific hardware, for efficiency and to avoid the need for unnecessary external-to-kernel hardware driver modules.

Actually Puppy-Rus-A from sfs has this tool. It makes very small custom kernel for the machine you run the tool and only the modules in use. I wrote about this long time ago in some of the DD threads. Maybe Puppy has similar option but I'm not sure.

Running official main Distro kernel is a big advantage regarding security fixes in my opinion. But adapting Puppy init to boot different distro has also some advantages from my testing. But lets not continue this discussion here. Maybe I will open new thread after some more testing.

Done:
https://github.com/MintPup/Puppy-Linux/ ... ian-kernel

Toni

Hi Toni,

This is interesting stuff. I've now had a look at your related github readme. I'd like to do this with XenialPup cos XenialDog works better for webcam capture/ffmpeg for me and I think it is kernel-related. Also I don't like using unofficial kernel if Ubuntu provide perfectly usable ones. So I'll be happy if you expand any steps (for example including modules to use and so on). Saves a lot of time, thanks.

William.

Hi William.

mcewanw wrote:So I'll be happy if you expand any steps (for example including modules to use and so on). Saves a lot of time, thanks.

Just did quick test with xenialpup-7.0.8-uefi.iso using the instruction in the github readme.md and it boots to desktop using the testing Debian kernel module (including saving in puduansave folder) after renaming:
puppy_xenialpup_7.0.8.1.sfs --> puppy_puduan_6.0.0.sfs
zdrv_xenialpup_7.0.8.1.sfs (you need only the firmware inside) --> adrv_puduan_6.0.0.sfs
I hope it is enough for testing what you need for now.

I'm busy with other things at the moment and I will not update the github instruction soon. In short to use official Ubuntu kernel choose some official Ubuntu-Xenial live CD/DVD and use:
/lib/modules and /lib/firmware from the Ubuntu main filesystem.squashfs in fdrv_puduan_6.0.0.sfs
/lib/modules from initrd.lz (official ubuntu live cd) in initrd.gz (from the Debian kernel test module)
vmlinuz (official Ubuntu live cd) instead vmlinuz (from the Debian kernel test module).
For 64-bit version you will have to make the changes inside the init script posted here and test it.

Toni

Sailor Enceladus wrote:If you want to try to build a slacko-current yourself, I attached the folder I used for woof-CE below in a tar.gz, you just throw the folder into your woof-CE/woof-distro/x86/slackware folder with the 14.x ones, then when you run ./merge2out a new "current" option should appear for 32-bit. I only updated the 3 top ftp.nluug.nl urls in it so far, removed dvdauthor, libconfig, libdaemon, libdv and libunique because they didn't exist in slacko-current... added libedit, libXfont2 (xorg broke without this) libinput and libwacom for xorg_base_new, and a bunch of libs from 14.2 that some slacko pets still rely on into the adrv (screenshot attached).

I found if I made the 3rd repository "salix-14.2" it works better (1st slacko-current-official, 2nd slacko-current-extra) and now only libtermcap is missing. Updated the "current" folder below. Trying another iso and if it works I'll remove the old attachment.

Sailor,

Have you ever did a pup build and gotten antiX/MX-16's excellent repos to work with it? I mean, it's all Debian stuff there, and those guys at antiX/MX have one hell of repo system setup (the backporting is just phenomenal in my opinion). Been wondering if I could work their repos into a Dpup build somehow, just not sure if it is: a) possible, and/or; b) how to exactly go about it.




P.S. Nobody liked our thread about "memory lane" projects . Thought for sure others would post and talk about whatever old pup they still keep around & running. Oh well, what's that saying: "Those who forget the past are doomed to repeat it"

belham2 wrote:P.S. Nobody liked our thread about "memory lane" projects . Thought for sure others would post and talk about whatever old pup they still keep around & running. Oh well, what's that saying: "Those who forget the past are doomed to repeat it"

Well said belham2.

belham2 wrote: Nobody liked our thread about "memory lane" projects . Thought for sure others would post and talk about whatever old pup they still keep around & running. Oh well, what's that saying: "Those who forget the past are doomed to repeat it"

Hi Bedlam - can you post a link to that thread please? cheers!

greengeek wrote:

belham2 wrote: Nobody liked our thread about "memory lane" projects . Thought for sure others would post and talk about whatever old pup they still keep around & running. Oh well, what's that saying: "Those who forget the past are doomed to repeat it"

Hi Bedlam - can you post a link to that thread please? cheers!

http://www.murga-linux.com/puppy/viewto ... 481#958481

Ta JC - much obliged.

I tried another "slacko-current" woof-CE build with Seamonkey (it didn't need gtk3). The adrv adds some missing libs from 14.2

https://www.mediafire.com/folder/kldh509odczdb/current (Mirror)