The Tiny X Server Fork Is Still Being Maintained

[phoronix]

Phoronix: The Tiny X Server Fork Is Still Being Maintained

The tinyx fork of the X.Org Server back from version 1.2.0 with Xvesa support and replaces XFree86 era code in some lightweight Linux distributions like Tiny Core Linux and Puppy. One of the developers has commented on the recent X Server security vulnerability that remained unresolved for more than two decades...

http://www.phoronix.com/vr.php?view=MTU2NzA

[dh04000]

I wish XMir and Xwayland were based on TinyX. Just saying.

(Assuming this fork has what current drivers and DE's need to run anyway)

[curaga]

Whee, apparently there's three different projects named TinyX now. The old Kdrive one, and two current ones. Ibidem's is https://github.com/idunham/tinyxserver AFAIK, which is different from the TC one linked in the article.

For what it's worth, I didn't find the X code that bad. In fact I quite enjoyed it, it was the first time I got to delete close to a million lines of code. Made me feel really productive!

I wish XMir and Xwayland were based on TinyX. Just saying.

I believe both have removed rootless code as useless for normal users. Not too good a starting point for a rootless server like X[MW]*.

(Assuming this fork has what current drivers and DE's need to run anyway)

TinyX servers have the drivers integrated -> you can't use Xorg drivers on them. The goal is small binary size, supported drivers: Xvesa and Xfbdev.

[Ibidem]

Whee, apparently there's three different projects named TinyX now. The old Kdrive one, and two current ones. Ibidem's is https://github.com/idunham/tinyxserver AFAIK, which is different from the TC one linked in the article.

For what it's worth, I didn't find the X code that bad. In fact I quite enjoyed it, it was the first time I got to delete close to a million lines of code. Made me feel really productive!

https://github.com/idunham/tinyxserver is my git repo, yes.
To go with it, I use https://github.com/idunham/tinyxlib.
The starting point was Amigo's project (http://distro.ibiblio.org/amigolinux...1-tiny-1.2.61/), which apparently was based off the xwoaf notes.
technosaurus and goingnuts on the Puppy Linux forums did a bit of work on it (releasing the occasional snapshot), and I was rather disturbed at the idea of an X server that old without patches, so I went through the list of security issues for X and backported the fixes. And somewhere along the line Iguleder picked up the project; from what I understand, he referred to the TinyCore TinyX as a guide to getting it working on amd64.

The relevant threads (that I recall off the top of my head) would be:

http://www.murga-linux.com/puppy/viewtopic.php?t=62145

http://www.murga-linux.com/puppy/viewtopic.php?t=51478

http://www.murga-linux.com/puppy/viewtopic.php?t=78941

http://www.murga-linux.com/puppy/viewtopic.php?t=89272

I'm not sure where to point at, but a project known as "microsaurus" was also one of the projects that used it; one release was here:

http://www.murga-linux.com/puppy/viewtopic.php?t=72671&start=46

The "bzImagegtk.tar.gz" is an archive containing the kernel, which contains the initrd, which is the OS.

[frign]

Direction of Wayland

I don't like the direction Wayland is going and the concept of having to write the same code for every new compositor over and over again.
Today, if you want to write your own implementation, people tell you to just write a Weston-extension. If you don't want to, have fun writing thousands of LOC just to get started.
Why don't the Wayland-devs once and for all offer some kind of libwayland-compositor implementing a basic compositor-interface while still offering old functionality (same applies to evdev, events and so on).

I like to see projects like the Tiny X Server fork, because it shows that X is more flexible than you might think, after cutting out the legacy code.
To be fair: Yes, in Wayland, every frame is perfect. But what's the price? Most compositors are just implemented with EGL, which requires DRI and accellerated graphics. Have fun setting this up on your embedded server.

[curaga]

Hm, so I think this is the difference between the Puppy and TC forks, based on the above links.

The TC fork aims to run everything sans bling, while the Puppy fork aims to be even smaller, but it does not run all apps (gtk2 was mentioned). Then there's the libc difference, with TC using glibc to be as compatible as possible, but the pupngo version using static musl.

[Iguleder]

Have fun setting this up on your embedded server.

That's right - it's pretty much impossible to get Wayland to work in extremely restricted environment (without udev, *GL*, etc'). That's why I decided to port Tiny X and tinyxlib to x86_64 - this is the only portable Linux graphics stack I'm aware of, which can be built statically against musl and doesn't depend on acceleration. It wasn't hard to port - I just examined the diff against Tiny Core's code.

The Tiny X Xfbdev is ~950 KB on x86_64, when built against musl. Pretty much any classic Xlib window manager works against it - I use Ratpoison.

[frign]

Nice!

That's right - it's pretty much impossible to get Wayland to work in extremely restricted environment (without udev, *GL*, etc'). That's why I decided to port Tiny X and tinyxlib to x86_64 - this is the only portable Linux graphics stack I'm aware of, which can be built statically against musl and doesn't depend on acceleration. It wasn't hard to port - I just examined the diff against Tiny Core's code.

The Tiny X Xfbdev is ~950 KB on x86_64, when built against musl. Pretty much any classic Xlib window manager works against it - I use Ratpoison.

Very cool!

Yes, I will definitely check this out in the near future. Being a suckless developer, I'm especially interested in how that could work out in combination with dwm .
We're discussing a dwm based on Wayland, but given dwm (and ratpoison) are so minimal and lean in regard to the need of compositing, Wayland is probably a step too far and really over-the-top given you have a minimal environment.

What particularly annoys me is Weston's hard-dependency on PAM.

Could you use some help on your tinyx- and tinyxlib-projects? I'd be eager to support you!

[daniels]

Today, if you want to write your own implementation, people tell you to just write a Weston-extension. If you don't want to, have fun writing thousands of LOC just to get started.
Why don't the Wayland-devs once and for all offer some kind of libwayland-compositor implementing a basic compositor-interface while still offering old functionality (same applies to evdev, events and so on).

we did write a libwayland-compositor - it's called weston. and you can write plugins for it.

[daniels]

That's right - it's pretty much impossible to get Wayland to work in extremely restricted environment (without udev, *GL*, etc').

weston runs perfectly well without (e)gl(es), running the pixman software renderer. works on top of drm/kms or fbdev.