Puppy In-House Development
- Iguleder
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
Puppy In-House Development
(I'll start with an apology - it's been a long time since my last major contribution to Puppy )
Motives
The world is closing in!
Evil, big projects and companies (systemd, GNOME, Red Hat, Canonical) make it harder for community distros to survive.
It seems more and more packages are getting emotionally attached to systemd, PulseAudio, Glib, WebKit, GNOME 3.x and other evil projects. As time goes by, it's getting harder and harder to build a small and fast distro like Puppy because of the mutual dependencies between these bloated packages.
The Solution
IMHO, true independence is the way to go: have our own systemd, our own udev, our own graphics stack, etc'. Hard to maintain, but the best way to go if we don't want another project's developer to decide for us which packages are going to be included in Puppy.
I've been working on replacements for:
- BusyBox
- sysvinit or systemd
- udev
- syslogd and klogd
- Bash and dash
- X.Org
Currently, it's possible to run a X server, with JWM and a handful of GTK1 applications, all linked statically, 64-bit. All this goodness can be easily packed in a humble 15-30 MB image.
The Big Picture
While having our own packages brings flexibility, using another distro's packages (as in Lucid and Slacko) has the benefits of easier development and security updates.
This in-house development project is an effort to create a set of statically-linked (totally independent) packages that form a "core" for Puppy. Since they have no external dependencies, they provide the flexibility we had before the Woof days, but still, allow the use of another distro's packages (because the're static): the best of both worlds.
This package set has three uses:
- A common base for all puppies (i.e a common API for applications that are guranteed to work across all versions)
- An add-on for existing puppies, which provides lightweight alternatives to today's heavier applications (i.e a GTK1 mtPaint is lighter than a GTK2 build)
- A Tiny Core-like Puppy, which boots to a small X server with JWM and a few applications - you fire up a package manager and instal only what you want
Building
This package set consists of many components:
- lazy-utils (still lacks network applets like ifconfig)
- devd from lazy-utils
- syslogd and logd from lazy-utils
- loksh, a Linux port of OpenBSD's ksh
- tinyxserver, a x86_64 port of tinyxserver by idunham; supports GTK1 and JWM
- Applications (X-Chat, mtPaint, Beaver, emelFM, Mrxvt and more)
- A dead-simple GTK1 package manager frontend, lpackage
- A simple union file system, luufs
Everything is written in C and builds statically against musl. devd supports Linux 2.6.32 and above, with devtmpfs mounted at /dev.
It's pretty easy to build a tiny, statically-linked distro from all these packages - I already have a working, concept distro, which uses Linux 3.10.x (the latest LTS) and achieves a JWM desktop, under x86_64. The whole building procedure is automated and supports both x86 and x86_64.
Next Steps
I'm working on package management - package removal seems buggy, but installation works great.
Motives
The world is closing in!
Evil, big projects and companies (systemd, GNOME, Red Hat, Canonical) make it harder for community distros to survive.
It seems more and more packages are getting emotionally attached to systemd, PulseAudio, Glib, WebKit, GNOME 3.x and other evil projects. As time goes by, it's getting harder and harder to build a small and fast distro like Puppy because of the mutual dependencies between these bloated packages.
The Solution
IMHO, true independence is the way to go: have our own systemd, our own udev, our own graphics stack, etc'. Hard to maintain, but the best way to go if we don't want another project's developer to decide for us which packages are going to be included in Puppy.
I've been working on replacements for:
- BusyBox
- sysvinit or systemd
- udev
- syslogd and klogd
- Bash and dash
- X.Org
Currently, it's possible to run a X server, with JWM and a handful of GTK1 applications, all linked statically, 64-bit. All this goodness can be easily packed in a humble 15-30 MB image.
The Big Picture
While having our own packages brings flexibility, using another distro's packages (as in Lucid and Slacko) has the benefits of easier development and security updates.
This in-house development project is an effort to create a set of statically-linked (totally independent) packages that form a "core" for Puppy. Since they have no external dependencies, they provide the flexibility we had before the Woof days, but still, allow the use of another distro's packages (because the're static): the best of both worlds.
This package set has three uses:
- A common base for all puppies (i.e a common API for applications that are guranteed to work across all versions)
- An add-on for existing puppies, which provides lightweight alternatives to today's heavier applications (i.e a GTK1 mtPaint is lighter than a GTK2 build)
- A Tiny Core-like Puppy, which boots to a small X server with JWM and a few applications - you fire up a package manager and instal only what you want
Building
This package set consists of many components:
- lazy-utils (still lacks network applets like ifconfig)
- devd from lazy-utils
- syslogd and logd from lazy-utils
- loksh, a Linux port of OpenBSD's ksh
- tinyxserver, a x86_64 port of tinyxserver by idunham; supports GTK1 and JWM
- Applications (X-Chat, mtPaint, Beaver, emelFM, Mrxvt and more)
- A dead-simple GTK1 package manager frontend, lpackage
- A simple union file system, luufs
Everything is written in C and builds statically against musl. devd supports Linux 2.6.32 and above, with devtmpfs mounted at /dev.
It's pretty easy to build a tiny, statically-linked distro from all these packages - I already have a working, concept distro, which uses Linux 3.10.x (the latest LTS) and achieves a JWM desktop, under x86_64. The whole building procedure is automated and supports both x86 and x86_64.
Next Steps
I'm working on package management - package removal seems buggy, but installation works great.
- Attachments
-
- screeny-thumb.png
- (17.42 KiB) Downloaded 4187 times
-
- devd.png
- (37.73 KiB) Downloaded 5110 times
Last edited by Iguleder on Thu 13 Feb 2014, 22:53, edited 9 times in total.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
Good initiative, Iguleder. Repo cloned.
Two suggestions:
1. Can you implement module blacklisting? Some modules/hardware combinations are problematic for some people (but works for others); so selective blacklisting is important.
2. Xvesa is for x86 only, but Xfbdev is not (and work almost as well); and it seems to still build even in the latest Xorg, so perhaps it is a easier goal to reach.
cheers!
Two suggestions:
1. Can you implement module blacklisting? Some modules/hardware combinations are problematic for some people (but works for others); so selective blacklisting is important.
2. Xvesa is for x86 only, but Xfbdev is not (and work almost as well); and it seems to still build even in the latest Xorg, so perhaps it is a easier goal to reach.
cheers!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
May I suggest an aid to development? Stop using cryptic and unnecessarily abbreviated names for things. I suppose this got started back when computer memory was limited. Those days are long gone. Now there is plenty of memory, computing power and display space for descriptive names to be used and properly spelled out. If only a few people have any idea what you're talking about, how does that help development?
- Iguleder
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
Sometimes, choosing your battles is the key to success.
ps lists processes and ls shows the contents of a directory: I can't (and don't want to) change people's habits.
jamesbond - trying to build a small X
ps lists processes and ls shows the contents of a directory: I can't (and don't want to) change people's habits.
jamesbond - trying to build a small X
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
You're right. I thought Xfbdev is small because it is one of (remaining few) the kdrive servers, but when counting the depedency it is not that small either. It is *still smaller* than the full Xorg, though.Iguleder wrote:jamesbond - trying to build a small X
On another note, amigo, technosaurus, goingnuts and ibidem have combining forces to create a working tiny X server - they have it going for x86 but I didn't follow enough to know whether they have have the generic framebuffer version which works cross-platform.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Re: Puppy In-House Development
Your project sounds like a great idea to me. I have been rather concerned to see how much the Woof project hitches the Puppy wagon to the big distros and their potential bloat. I understand why some users will benefit from that approach, but I think there are many other users who would see great value in pursuing the original Puppy mantra of "lean and mean".Iguleder wrote:As time goes by, it's getting harder and harder to build a small and fast distro like Puppy because of the mutual dependencies between these bloated packages......
but the best way to go if we don't want another project's developer to decide for us which packages are going to be included in Puppy.
I personally would welcome an even faster Puppy that was a bit of a mongrel (in a nice way of course ) rather than a pimped up show pooch.
I trust Puppy developers more than I trust Ubuntu ones. Not sure how justifiable that feeling is but hey, that's how I feel...
- Iguleder
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
Tried the last XFree86 and amigo's tiny X11 - both fail to build.jamesbond wrote:On another note, amigo, technosaurus, goingnuts and ibidem have combining forces to create a working tiny X server - they have it going for x86 but I didn't follow enough to know whether they have have the generic framebuffer version which works cross-platform.
I guess I'll write a proof-of-concept Wayland-style thingy: two processes, one that "allocates rectangles" and receives redrawing requests, then creates a frame from all rectangles and a sample "client" of this server.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
I hope you don't mind me commenting guys I am very excited by your ideas and like the back to mean and lean approach your formulating.
Yesterday I had actually given up on Puppy but by chance saw this and want to encourage your efforts.
I am no coder but if you ever release an iso for testing and would like a tester then I'll help out so all I can say guys don't give up this is awesome.
Yesterday I had actually given up on Puppy but by chance saw this and want to encourage your efforts.
I am no coder but if you ever release an iso for testing and would like a tester then I'll help out so all I can say guys don't give up this is awesome.
Ibidem has newer tinyx xfbdev xvesa build - view this
Haven t tested your tiny apps yet but this really looks promising.
Haven t tested your tiny apps yet but this really looks promising.
Actually building a puppy???...it might just catch on.
Using the worlds bloatiest disto as your file base always stuck me as a bit silly.
Is Xorg too untameable of a beastie? I try to build without all that xcb crap for a start. Perhaps a more modular approach with it... I mean half the time you have to add a driver in any case...eg nvidia/ati..so a 'vesa' base and then driver packages tailored for each cardset.
I would apply the same thinking to wifi which is another source of size increase....usually in the form of bulkiy firmware and STA drivers.
all sounds fun
thought I'd chime in since a similar subject has crept in on another thread I am waffling on.
mike
Using the worlds bloatiest disto as your file base always stuck me as a bit silly.
Is Xorg too untameable of a beastie? I try to build without all that xcb crap for a start. Perhaps a more modular approach with it... I mean half the time you have to add a driver in any case...eg nvidia/ati..so a 'vesa' base and then driver packages tailored for each cardset.
I would apply the same thinking to wifi which is another source of size increase....usually in the form of bulkiy firmware and STA drivers.
all sounds fun
thought I'd chime in since a similar subject has crept in on another thread I am waffling on.
mike
Link to present tiny-Xserver-0.03 source
If small is the goal, have you seen this:
http://www.menuetos.net/
A full X operating system with lots of apps that will fit on a floppy. It's pretty cool and seems to be actively developed, 32 & 64-bit.
Download:
http://www.menuetos.org/M32.htm
http://www.menuetos.be/download.php?CurrentMenuetOS
CatDude made a bootable ISO at a huge 1492k.
http://www.menuetos.net/
A full X operating system with lots of apps that will fit on a floppy. It's pretty cool and seems to be actively developed, 32 & 64-bit.
Download:
http://www.menuetos.org/M32.htm
http://www.menuetos.be/download.php?CurrentMenuetOS
CatDude made a bootable ISO at a huge 1492k.
Puppy Linux Blog - contact me for access
I didn't do a large amount of work--mainly got it working with musl and backported some security fixes (speaking of which, there's another one to patch...).jamesbond wrote:You're right. I thought Xfbdev is small because it is one of (remaining few) the kdrive servers, but when counting the depedency it is not that small either. It is *still smaller* than the full Xorg, though.Iguleder wrote:jamesbond - trying to build a small X
On another note, amigo, technosaurus, goingnuts and ibidem have combining forces to create a working tiny X server - they have it going for x86 but I didn't follow enough to know whether they have have the generic framebuffer version which works cross-platform.
But yes, Xfbdev does build and run.
When compiled against tinyxlib, I will say that colors don't work quite right--hex #RGB colors are not recognized, though I know goingnuts was doing something about that.
Sure did. I stumbled across it many years ago but didn't realise it was still being developed.
01micko wrote:Smokey.. did you know BK was a part of that project?
http://www.goosee.com/explorer/index.html