woof-CE needs you

News, happenings
Message
Author
User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#981 Post by peebee »

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.
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#982 Post by saintless »

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 :D

Toni

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#983 Post by mcewanw »

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
Last edited by mcewanw on Sat 17 Jun 2017, 02:56, edited 1 time in total.
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#984 Post by mcewanw »

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
github mcewanw

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#985 Post by saintless »

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

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

#986 Post by Sailor Enceladus »

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.
Attachments
Screenshot.png
(23.05 KiB) Downloaded 129 times
Last edited by Sailor Enceladus on Mon 03 Jul 2017, 19:12, edited 6 times in total.

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#987 Post by mcewanw »

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

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#988 Post by saintless »

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
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#989 Post by Sailor Enceladus »

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.

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#990 Post by belham2 »

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 :cry: . 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"

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

#991 Post by Sailor Enceladus »

belham2 wrote:P.S. Nobody liked our thread about "memory lane" projects :cry: . 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.
Last edited by Sailor Enceladus on Mon 03 Jul 2017, 10:32, edited 1 time in total.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#992 Post by greengeek »

belham2 wrote: Nobody liked our thread about "memory lane" projects :cry: . 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!

User avatar
James C
Posts: 6618
Joined: Thu 26 Mar 2009, 05:12
Location: Kentucky

#993 Post by James C »

greengeek wrote:
belham2 wrote: Nobody liked our thread about "memory lane" projects :cry: . 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

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#994 Post by greengeek »

Ta JC - much obliged.

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

#995 Post by Sailor Enceladus »

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)
Attachments
Screenshot.png
(49.43 KiB) Downloaded 1352 times

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#996 Post by BarryK »

Hi guys,
Someone might want to consider this insertion for 0setup:

http://barryk.org/news/?viewDetailed=00589

Note, I don't commit to woof-CE, as since I retired from the frontline of Puppy development, I don't want to be seen as interfering, or as trying to get back behind the drivers wheel, so to speak.

So, the link has a suggestion, for anyone who wants to investigate it.
[url]https://bkhome.org/news/[/url]

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#997 Post by belham2 »

BarryK wrote:Hi guys,
Someone might want to consider this insertion for 0setup:

http://barryk.org/news/?viewDetailed=00589

Note, I don't commit to woof-CE, as since I retired from the frontline of Puppy development, I don't want to be seen as interfering, or as trying to get back behind the drivers wheel, so to speak.

So, the link has a suggestion, for anyone who wants to investigate it.

Dam#, I am slapping my forehead reading Barry's link....suddenly, some of the un-explained "why didn't the correct package get built- in" when using the Ubuntu-based woof-CE builds now makes sense. I am going to do a few new ubuntu-woof-CE-builds after first inserting Barry's code in 0setup--will try the insertion where he suggests and also in a couple of different places in the script, and see what happens. Thanks, Barry!

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#998 Post by BarryK »

belham2 wrote:
BarryK wrote:Hi guys,
Someone might want to consider this insertion for 0setup:

http://barryk.org/news/?viewDetailed=00589

Note, I don't commit to woof-CE, as since I retired from the frontline of Puppy development, I don't want to be seen as interfering, or as trying to get back behind the drivers wheel, so to speak.

So, the link has a suggestion, for anyone who wants to investigate it.

Dam#, I am slapping my forehead reading Barry's link....suddenly, some of the un-explained "why didn't the correct package get built- in" when using the Ubuntu-based woof-CE builds now makes sense. I am going to do a few new ubuntu-woof-CE-builds after first inserting Barry's code in 0setup--will try the insertion where he suggests and also in a couple of different places in the script, and see what happens. Thanks, Barry!
While you're at it, here is another one to consider. I posted about a bug in /etc/rc.d/0setup that on certain hardware can cause a hang at bootup, or a delay:

http://barryk.org/news/?viewDetailed=00586

woof-CE still has the offending line, or what I think is the cause, at line 761:
https://github.com/puppylinux-woof-CE/w ... rc.sysinit
[url]https://bkhome.org/news/[/url]

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

#999 Post by rufwoof »

I used WoofCE for the first time since quite a while ago (with little success back then). This time, first run failed as I tried to be clever and opt for likely inappropriate choices. Second time I used the example 'defaults' choice and built tahr 32bit pae which is running great (I went for one of the oldest kernels for that ... so a bit outdated). Today I've build tahr 6.0.6 amd64 with a 4.1.11 kernel. That's also running as well, initially the fonts were a bit 'off' (not as clear/smooth as the 32bit version, but after a lot of trying different things they came good). Todays WoofCE run took around 40 minutes total build time running on a 10 year old amd phenom 4 core with 2GB (internet down link speed of around 80Mb/sec). The final folder content size is showing just under 6GB of disk space used that includes the iso and devx sfs.

Really neat. And simple enough for the likes of me to use. Thanks.

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#1000 Post by mavrothal »

rufwoof wrote:Really neat. And simple enough for the likes of me to use.
You might be interested in the woof-next branch of woof-CE.
Is building a "puppy" much closer to upstream (with apt-get and everything!) which you may prefer.
Currently is at alpha/early beta stage as Jamesbond stopped working on it a couple of years now. However, if someone shows interest and asks informed, constructive questions, I think he may be willing to help.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

Post Reply