Puppy In-House Development

[Iguleder]

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

[jamesbond]

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!

[Iguleder]

Tried to build Xvfb - not trivial at all. It's huge like Xorg, because of the fonts, drivers, etc'.

[Flash]

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]

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

[simargl7]

mkdir from lazy-utils can't make two directories at once.

this command

mkdir dir1 dir2

does nothing,

Don't know whether this qualifies as bug

[Iguleder]

Minimalism is not a bug

[jamesbond]

jamesbond - trying to build a small X

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.

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.

[greengeek]

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.

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

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]

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.

Tried the last XFree86 and amigo's tiny X11 - both fail to build.

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.

[darry1966]

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.

[darry1966]

I trust Puppy developers more than I trust Ubuntu ones. Not sure how justifiable that feeling is but hey, that's how I feel..


Yep second that - that comment is a bobby dazzler.

[goingnuts]

Ibidem has newer tinyx xfbdev xvesa build - view this
Haven t tested your tiny apps yet but this really looks promising.

[mikeb]

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

[Iguleder]

Sounds interesting, goingnuts!

Can you PM the patched sources, please? I'll take a look at GTK1 and the pupngo X server on Friday.

[goingnuts]

Link to present tiny-Xserver-0.03 source

[smokey01]

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.

[01micko]

Smokey.. did you know BK was a part of that project?

http://www.goosee.com/explorer/index.html

[Ibidem]

jamesbond - trying to build a small X

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.

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

[smokey01]

Sure did. I stumbled across it many years ago but didn't realise it was still being developed.

Smokey.. did you know BK was a part of that project?

http://www.goosee.com/explorer/index.html