Linux Desktop Without X11

A writes "Rocklyte systems have announced the first version of their Athene Operating System. It is a desktop and embedded operating system built on the Linux kernel, but without the "aging X11". Instead, it uses the SciTech SNAP graphics system with which it is possible to completely re-theme the desktop to look like the famous AmigaOS GUI or another famous UI. For backwards compatibility, an X11 server is also available in the system. The system can run completely off the CD, without needing to be installed on the harddrive."

Comments

Who would *want* Aqua on Linux?

[0x0d0a]

Aqua is the most dog-slow, RAM-hungry POS in existence. I've always considered it the biggest *problem* with using OS X, since you can't use OS X without having to have this huge beast bogging down your machine.

Never get anywhere...

[Junta]

Proprietary and closed will keep this where it is. A shame really. There should be more effort to replace X.

X is nice, but is showing it's age. Problems I see:

Memory usage. It is true that application pixmap memory gets counted as X mem, not application memory, but X's primitives are, well, too primitive. The amount of memory required to represent widgets of high level toolkits in X is way too high because everything is represented by some really basic primitives, *especially* when apps draw complex things (i.e. gradients) and those things just have to be stored as pixmaps, even though they *could* be described in far less memory. Same goes for toolkit buttons that all look *similar* but not identical, even if heavily themed, they could share resources and modify them as needed for equal flexiblity consuming *much* fewer resources.

Network transparency. People always praise X for it's network transparency. This is just plain wrong, it sucks at that function. It may be better than other systems in many ways, but being the best does not mean it doesn't suck...

One thing is that it is way too bandwidth intensive. *Especially* here the X primitives are just *too* primitive for their own good. Drawing a button could be reduced to a single, small, insignificant amount of traffic, but in X, the client must describe every detail of just how to draw the button. With Xaw, they reduce the pain by using ass-ugly widgets that can be represented with relatively few X primitives. Meanwhile, modern good looking widgets make things ten times worse for the network. Even buttons with complex themes could be represented with a small amount of traffic if only the primitives were more sophisticated.

It follows that more sophisticated 'primitives' would improve the 'network transparency' for the end user in terms of look and feel as well, since the system attached to the screen can dictate how widgets look rather than the remote system running the app. In X if you run an application on two different systems, the remote themes dictate look and it detracts from the transparency and consistency aspect of things.

Also, when the connection is interrupted or the system serving the display to the program dies, the program dies with it. This is ugly. On the other hand, I don't think the MS approach of having each system have it's own screen is too hot either (RDP). What I would like to see is a hybrid of the approaches. Having the 'screen' like functionality of RDP/VNC where running where applications continue to run in the event of an interruption, but have application windows interleave with other windows rather than be kept in separate 'desktop' windows.

I can see two solutions:
A completely new project to make a somewhat X-like system with more useful primitives. The native network protocol need not be X compatible, but an application running on *top* of it could provide X compatibility. That way, the project could truly ditch all the legacy stuff and start afresh, leaving the option of the legacy stuff for those that *need* it, and not forcing it upon those who do not. The difficulty associated with the anti-aliasing of fonts a while back proves that legacy stuff is really making progress difficult. I think this is the best way to go.

As a compromise, could GTK and/or QT be implemented as X extensions, where GTK/QT widgets would be primitives rather than basic shapes and raw pixmap data? While it would not address the 'screen-like' functionality I would wish, it would serve to reduce memory usage and network traffic. It would probably still be bloated a bit much, but if people are *really* adverse to ditching X, this would make it a lot more tolerable.