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.

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

>>1-67 "Kernel graphics drivers are bad"
Would you like to be disproved by reality?
http://en.wikipedia.org/wiki/Direct_Rendering_Manager
The Direct Rendering Manager (DRM) is a component of the Direct Rendering Infrastructure, a system to provide efficient video acceleration (especially 3D rendering) on Unix-like operating systems, e.g. Linux, FreeBSD, NetBSD, and OpenBSD.

It consists of two in-kernel drivers (realized as kernel modules on Linux), a generic drm driver, and another which has specific support for the video hardware. This pair of drivers allows a userspace client direct access to the video hardware.

http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure
In computing, the Direct Rendering Infrastructure (DRI) is an interface and a free software implementation used in the X Window System to securely allow user applications to access the video hardware without requiring data to be passed (slowly) through the X server. Its primary application is to provide hardware acceleration of the Mesa implementation of OpenGL. It has also been adapted to provide OpenGL acceleration on a framebuffer console without an X Server running.

The project was started by Jens Owen and Kevin E. Martin of Precision Insight. It was first made widely available as part of XFree86 4.0 and is now part of the X.Org Server. It is nowadays maintained by Tungsten Graphics and others in the free software community. The part of the project about the 3D drivers is one of the High Priority Free Software Projects.

The DRI OpenGL support consists of several pieces.

    * The first is the Direct Rendering Manager (DRM). The DRM is a combination of at least two kernel modules, one of core DRM code and others providing APIs to userland to access different classes of video hardware.
    * Second is a userland driver module, which contains an OpenGL driver that typically prepares buffers of commands to be sent to the hardware by the DRM, and interacts with the windowing system for synchronization of access to the hardware.
    * Third, there is some sort of server. In X this is the libdri.so support module and a DRI-enabled DDX (2D driver). In the framebuffer implementation this is MiniGLX, which initializes the DRM and provides some X APIs to the userland driver despite the lack of an X Server.

Several Open Source DRI drivers have been written, including for ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 through Voodoo5, Matrox G200 through G400, SiS 300-series, Intel i810 through i965, S3 Savage, VIA unichrome graphics chipsets, and nouveau for NVIDIA. Some graphics vendors have written closed-source DRI drivers, including ATI and Kyro. The DRI is supported on Linux and FreeBSD, and it has been ported to NetBSD. Work is currently ongoing to port DRI to OpenBSD

On the X Developers' Summit for 2007 work on DRI2 started. The new rendering infrastructure improves several shortcomings of the old design. Among its significant improvements: the lack of internal locks and proper support for offscreen rendering, so that compositing and XVideo/OpenGL applications are properly managed.

lol DRM
http://linuxhaters.blogspot.com/2008/06/nitty-gritty-shit-on-open-source.html

>>70
So there are limited man hours going into improving an important open source project. So what's new?

lol WIKI FACTS

Citation needed