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.

Benefits to putting a windowing system inside the kernel include:

    * It prevents the windowing system (GUI) from becoming bloatware because kernel resources are supposed to be limited.
    * It simplifies the interface to the graphics subsystem for applications to a small number of ioctl calls, whereas under X it involves pipes and/or shared memory.
    * In-kernel graphics can be used for a non-passive graphical startup, to alleviate the awkward switch from text mode to graphics mode under Linux.
    * In-kernel graphics could permit moving the current Linux console code out of the kernel.
    * FBUI could in future provide access to the whole graphics-card memory, which normally cannot be accessed from userspace.

FBUI currently does not support:

    * The concept of nested windows
    * Unlimited event queues
    * Kernels other than 2.6.9

Regarding that last point: After 2.6.9, bugs appeared in the frame buffer device (fbdev) that prevented the use of FBUI. The 2.6.23 frame buffer device layer or virtual terminal also have significant problems.

import FBUI

Unix fanatics discover what Microsoft and Apple realized a decade ago.

Jesus Fucking Christ. That X bullshit need to be erradicad, and fast. And I'm not talking just about the implementations either. If drawing a fucking pixel or processing a mouse move event requires 4 context switches and a pair of data serializations your architecture is bad and you should feel bad.

>>5
Protip: OS X is a Unix, and Aqua is not part of its kernel. Windows did indeed make the GUI part of the kernel up until Vista, and that decision single-handedly created its reputation as an extremely unstable OS. There's a good reason Vista divorced the GUI from the kernel.
X may be a mess, but this is would only make things worse. And also you're an ignorant buffoon.

>>5
Everybody hates X already. Quit acting like there's some cult of X. You're also wrong in every other possible way.

>>7 has read the Unix Haters Guide.

>>5
well then write something better. the problem with x is that it works well enough, and no one has written a replacement for it that works as well as it does.

I've been using x for 5 years; should I be seeing problems with it that I don't?
Other than driver problems with cards that appear here and there (which aren't really X's problem), what's all the hubbub about, bub?

>>6
OS X
Nobody cares.

>>11
I care

>>12
I came

>>12
You're a nobody.

>>14
No, I use a Mac.

>>10
It's big and slow. And the API sucks, so people write even bigger and slower libraries to interact with it.
But you probably have incredibly overpowered hardware so you don't notice that.

>>15
Aaaannnd nobody cares. You should kill yourself.

>>17
I care.

FUBU is a clothing company. It includes casual wear, sports wear, a suit collection, eyewear, belts, and shoes. The name is a backronym for "For Us, By Us", indicating that the product line was produced by black Americans for a primarily black American market.

BRB FBUI

>>18
You're a nobody.

The problem with X is performance, but it's no surprise that its Internet white knights can't see it. And no, Vista didn't move to an "X model". Drawing something or getting a mouse move item still requires just a user-kernel context switch (whether the drawing occurs in userland or kernel is not important), and all the data is passed in the most efficient format possible (not some network-like protocol).

If you think this is untrue, then please explain to me why things that draw stuff to the screen (say, web browsers for example) manage to run 10 times as fast in Windows as they do in Linux*, even though OpenGL applications or direct overlay video run at similar performance in both.

At 2GHz it's mostly bearable, but with the CPU downclocked to 600MHz, I can SEE how it draws the stuff. The last time I saw that in Windows was in a 386.

* I actually benchmarked this on a nightmare page (think MySpace-like). Plugins were disabled on both platforms; actual speed difference factor was 4.8.

>>6
You're wrong.  I just thought you should know that.

>>23
What about my being wrong?

>>24
You're wrong.  You are wrong.

>>25
What about his your're wrong?

>>26
Yowr urong.

PLEASE, DON'T MAKE IOCTL POSTS.

But the idea to have a graphical interface in kernel is nice.  You can have kernel consoles, teletype COM ports, modems, why not have graphics too?  With some thinking it can be made a character device.

>>8
But it didn't get much better since the times of Unix Haters Handbook.

>>22
You are right, Firefox and Openoffice on Windows are noticeably faster.  X also lacks consistent keyboard input configuration.  But it doesn't mean that kernel graphics will be better.

Sounds sort of like Anonix wmfs.

>>28
Eye-oh-cottle

>>30
aye-ock-tull

If you put the graphics into the kernel, doesn't that mean that you can no longer run the applications on a different system than the display? You know, the one thing that X11 can do quite easily that is a pain in the fucking ass on any other system.

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

>>28
When was the last time you saw a graphics driver stable enough to incorporate it into a kernel?

>>32
This, also. Though to be fair, nowadays that's probably a minority use case, and you could still have both systems running side by side.

>>33
last time you saw a graphics driver stable enough to incorporate it into a kernel?
Windows.

>>34
The grown-ups are talking, kid. Go play with your blue screens.

>>35
MacOSX

>>35
BeOS

>>35
AmigaOS

>>36-38
Are you just pulling names out of your ass now? None of those operating systems have GUIs running as part of the kernel.

>>39
Kernel Graphics Driver!=GUI