FBUI

Framebuffer UI (FBUI) is an in-kernel windowing system for Linux (kernel version 2.6.9 only, currently outdated) that sits on top of the framebuffer subsystem. Unlike the X Window System, FBUI consumes very little memory: the entire subsystem is about 50 kilobytes. FBUI supports features expected of modern windowing systems, such as moveable overlapping windows, multiple windows per application, events and common drawing functions, as well as windows on every virtual console. Graphics operations are executed on a first-come, first-served basis inside the kernel, and there is no server that queues requests.

Included with FBUI is libfbui, which provides abstractions for windows, events, images, fonts, etc., as well as quite a few sample programs such as load monitor, clock, calculator, scribble pad, image viewer, window managers, and a simple MPEG2 player.

FBUI, being only 50 kilobytes, offers solid proof that a windowing system need not be several megabytes in size, as is the case with X Window System.

FBUI is primarily intended to be a 2D graphics system, although it does include a triangle-fill routine.

Why people are still pretending Windows is not stable? I've had zero bluescreens in the last 5 years of so, and I frequently open multiple 3D applications at once, suspend the system while they're open, have upwards of 800+ TCP connections open, have over 200 processes, and so on...

The other day I had the video card malfunction due to overclocking. Result? Black screen for 20 seconds, then back on the desktop, with a "video driver has failed and has been restarted" message.

I don't see what a userland graphics system brings you. If the X server dies, all your X applications are gone anyway (same result in practice - in fact Windows is better here, as it can restart or switch video drivers without killing applications, albeit 3D applications might have to perform a device reset - most moder ones handle this correctly).

Having a centralized process handle expensive operations has other problems too, such as priority inversions (a program can have 95% of its CPU and memory usage in the X server, so you can't prioritize it properly).

Running applications remotely is actually a misfeature - it's unusable except on really fast connections (LANs mostly). A VNC / Remore Dektop approach gives much better results in practice, and Windows does that too (and yes, you can have multiple users logged on at once, and fuck, you can switch a session from remote to local and back and disconnect and re-logon - the X model is much, much more inconvenient).

>>33
Why Firefox is a lot faster under Windows than under Linux has been discussed to death, and doesn't have shit to do with X.
I'd love to hear the reasons. All I hear is "LOL X IS FINE YOU DON'T KNOW WHAT YOUR TALKING ABOUT" but all I see is that anything that uses X runs like shit. I really would like to know why.