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

>>39
Playstation 3

>>39
GUI is app which uses the API(libfbui) of the windowing system(the driver for framebuffer system) which runs (in case of FBUI) in kernel space.

Some would say, "But Microsoft tried the in-kernel graphics thing, and look what a mess it is!"

It is true that (A) Microsoft's pre-XP OSes were not stable or well designed and (B) Microsoft has used an in-kernel GUI approach. But to assume that B implies A is poor reasoning, as is the assumption that any such implication is valid for other developers. Such bad reasoning or superstition ignores the true causes of Microsoft's failures, which are:

    * Microsoft project managers and/or programmers have proven themselves to be poor at more than just creating stable operating systems, which suggests poor project management or design, and/or poor coding and/or insufficient testing.
    * Microsoft mainly borrows its ideas from others, and anyone who merely copies others' work is bound to make mistakes due to lack of understanding and/or ability.
    * Microsoft has a different goal than I do: their goal is money, whereas my goal is to create an effective and efficient software subsystem having the smallest possible size. History is littered with examples of companies that operated purely by the profit motive and who cut corners or skipped necessary steps, leading to disaster.
    * Microsoft's windowing system is, like X Windows, a big, bloated piece of software and as every engineer knows, the larger and more complex a system or subsystem is, the more likely it is that there will be bugs.

Liberation from Bloat
FBUI's most important role in my opinion is the reduction of software bloat. Why make a fuss about bloat? Software bloat is bad because:

    * Software bloat keeps us all on the treadmill of always buying new hardware, which ultimately new software makes painfully slow, thus we are always falling behind. But the software makes the system slow because it is poorly designed and poorly implemented and rushed work, with the frequent consequence that it is bloated. Thus the purchasing-treadmill is economically and materially wasteful. It profits the few while making the many suffer unnecessarily.

    * Bloat is also bad for the Environment (which we live in and rely upon) since the manufacture of computer equipment involves the use of numerous very nasty chemicals which inevitably end up in the soil, water and air. Similarly the disposal of electronics results in chemicals leaching out of circuit boards, LCDs (which contain mercury) et cetera, which then enter the biosphere. We cannot afford to pretend this problem doesn't exist and we cannot afford to leave it to self-serving politicians to solve. It is better to solve the problem at the source: buy less hardware. (Article)

    * Liberation from bloat is liberation from rushed work, poorly managed projects, and bad engineering. It is liberation from those project managers and programmers who, rather than produce better, leaner, less buggy software, pass on the consequences of their bad choice to users who must pay to upgrade their hardware to accommodate the bloat. And as that software gets bigger and bulk is piled upon bulk, increasing numbers of bugs and vulnerabilities arise which require, you guessed it, more upgrades.

Windowing as a kind of hardware-like multiplexing
One of the underlying concepts and motivations for FBUI is the idea that a window can be viewed like a piece of hardware : a set of physical pixels. In this sense, the OS just does what it minimally should: it multiplexes access to the (abstract) hardware items, i.e. windows. This is a key reason why FBUI belongs in the kernel, because the bare minimum that a kernel should do is multiplex access to hardware. Even exokernels, which place every driver in userspace, are considered multiplexers.

Besides limiting GUI bloat, it also minimizes the interface to the simple and elegant ioctl interface.

You could have a GUI right from boot time, as the Enhanced Functionality module demonstrates with its simple line-drawing pattern: As soon as the penguin appears, you have EF graphics appearing.

FBUI could be improved so as to entirely replace the framebuffer device and framebuffer console so that you could never deal with any of that.

FBUI could provide the basis for a completely graphical startup à la Macintosh.

>>40
``Kernel graphics driver'' also isn't an OS. There's a confusion of terminology here which stems from the fact that nobody in this thread knows what the hell he's talking about except possibly >>6 and >>7.

>>46
I assure you that I do know what I'm talking about. However, I have a policy of only making irrelevant troll posts in order to accelerate the untimely demise of this board.

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.

>>48
A lot of it has to do with Linux's memory management. Honestly, Linux's VMM sucks for the weirdass usage patterns Firefox has. Try running it on FreeBSD and you'll note that it's almost every bit as fast as the Windows version. That speed difference is a better comparison of X11 vs. Windows rendering.

Linux is a server kernel, and its performance is tuned for server applications. Linus Torvalds does not give a shit about desktop users. As far as he's concerned, they can all go fuck themselves.

Eunuchs fags should have circlejerked around BSD if they wanted their OS to succeed.

>>48
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.
Profiling compilation. The Windows binary running under Wine outperforms the binary most distros' package managers provide. It has fuck all to do with X.

BUT HO HO HO THIS TIME HE'S MEGA-COCK, THE FASTEST FAGGOT IN THE WORLD.

>>49
Try running it on FreeBSD and you'll note that it's almost every bit as fast as the Windows version.
Until npviewer.bin shits itself and the entire thing locks up until you kick it with a killall -9 npviewer.bin.

Fucking flash.

>>53
if you want flash, just run a windows version of firefox in wine.
linux flash is notoriously buggy and slow.
i've often wondered why the freebsd people bothered making a linux plugin wrapper for firefox when a windows plugin wrapper would work so much better.

>>51
Firefox 2 was already much faster, and it didn't ship profiled on any platform. Try again. (Besides, there's more speed advantage in MSVC vs GCC than in nonprofiled vs profiled)

All this talk about using WINE, why not just cut out the middle man and use Windows?

>>56
The next time I install a copy of Windows, if I ever do it again in the rest of my life, it will be Windows 7 Scurvy Edition.

>>56
windows is slower and less stable than wine on freebsd.
windows vista and windows 7 are more stable than wine on linux, though.

>>58
it is possible to have a native implementation less stable than a container that emulates it (noting that the emulation is not correct and may perform unexpectedly if it does not also correctly emulate bugs and inconsistencies)
1/10

>>59
Most programs rely on bugs to operate properly, and eliminating these bugs will make them perform unexpectedly rather than curing them of flaws.
0/10

>>59
i'd rather have a few completely broken programs not work than have the whole system crash.

>>55
You're full of shit on several levels.

From >>49 and >>51 it follows that FreeBSD does PGO.

YHBT

Loonix doesn't have any native windowing/gui capabilities. Ask a Loonix expert, the command line is superior and all you need.

The practicle advancement known as GUI is actually for fags. A real OS never has to advance beyond the command line.

Swim away FBUI fish, swim away

FWE seems to be his project now. FBUI seems to be stalled

>>66
FBUI is dead because it was built on top of undocumented hacks and no one gave a fuck when it broke. Expect FWE to disappear as soon as tiny kernel changes break it as well.