login
Search
Zack Smith announced that he has been working on an in-kernel 2D GUI for the 2.6 Linux kernel [forum] called FBUI. Based on the framebuffer, the project page explains, "FBUI is a small, in-kernel graphical user interface for Linux. It permits you to put windows in each framebuffer-based virtual console, to read keyboard input and track the mouse pointer." The core software measures in at a mere 26k, adding an additional 17k for a graphical library, 30k for a window manager, and 38k for a terminal emulator.
Currently distributed as a tarball that extracts into the 2.6.8.1 Linux kernel [story] source tree, the project aims to minimize bloat, and to be useful in "resource-limited platforms such as embedded devices." Attempting to test the software on my own server I found that the installation process is not yet intuitive, and suspect that the gui is currently not compatible with all framebuffer devices. Further information including a screen shot can be found on the project's home page.
From: Z Smith [email blocked] To: linux-kernel Subject: in-kernel GUI project Date: Sat, 30 Oct 2004 15:14:35 -0700 Hi all, I've been developing an in-kernel 2D GUI for kernel 2.6. It's based on the framebuffer with the event subsystem providing mouse and keyboard. I'd like to welcome you all to take a look at the current work at home.comcast.net/~plinius/fbui.html. Thanks, Zack Smith
From: Rik van Riel [email blocked] Subject: Re: in-kernel GUI project Date: Sat, 30 Oct 2004 19:06:47 -0400 (EDT) On Sat, 30 Oct 2004, Z Smith wrote: > I've been developing an in-kernel 2D GUI for kernel 2.6. > It's based on the framebuffer with the event subsystem What about video cards where the framebuffer does not provide for acceleration, but the X drivers do ? Do you plan to use the X server for better performance on such systems ? -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
From: [email blocked] Subject: Re: in-kernel GUI project Date: Sat, 30 Oct 2004 19:17:00 -0400 On Sat, Oct 30, 2004 at 07:06:47PM -0400, Rik van Riel wrote: > On Sat, 30 Oct 2004, Z Smith wrote: > > > I've been developing an in-kernel 2D GUI for kernel 2.6. > > It's based on the framebuffer with the event subsystem > > What about video cards where the framebuffer does not > provide for acceleration, but the X drivers do ? > > Do you plan to use the X server for better performance > on such systems ? > According to the website it's bloat so I imagine no. Why didn't someone think of this before, put it in the kernel solve software bloat! </sarcasm>
Neat
This sounds neat, tho' by the time this gets near stable, even the embeded systems are running at several gigahertz and have gigabytes of RAM :)
While the idea is interesting
While the idea is interesting, there's a whole host of troubles with security and stability that can come about from putting something as complex as a full featured GUI within the kernel.
Additionally, there seems to be some features severely lacking in this implementation-- overlapping windows, while inconvienient at times, are critical for most modern GUI applications. Dialog boxes and messages, while doable without overlapping windows, tend to be awkward and visually unpleasant.
A minimal GUI architecture is a perfectly fine idea, but I see no reason at all to put it in the kernel. It's far more trouble than it's worth. With the help of something like uClibc, I'm sure one could put together a framebuffer based window management system in very little memory. Possibly even a full fledged X server.
I differ
This is a nice approach to a simple system. In particular, if somebody is looking for a kiosk, a system devoted to just one function (think embedded), system management (bios, etc), this looks ideal. Personally, I will still keep doing KDE work, but I still like this approach.
Non-X11 GUI libraries for Linux exist
A minimal GUI architecture is a perfectly fine idea, but I see no reason at all to put it in the kernel. It's far more trouble than it's worth. With the help of something like uClibc, I'm sure one could put together a framebuffer based window management system in very little memory.
In fact there are several projects that have tried to do something
like this (for one overview see http://www.linuxdevices.com/articles/AT9202043619.html ). But they don't seem to get much visibility. X11 seems to
be good enough for most people. Old or stripped down versions of X11 work fairly well even on
low-end systems if you don't try to use bloated GUI libraries
and frameworks like Gnome or KDE.
doesn't make much sense to be kernel based
Its a bad idea putting stuff like this in the kernel.
-every kernel release, you'll need a new patch for that kernel to use it (so maintainability is hard)
- kernel interfaces change a lot, so thats another aspect that will affect it a lot,
- if theres a problem with the GUI, the whole kernel will most likely stop and die. At least if its a seperate program, the gui could be just reloaded
Tiny-X is only 1.1 megs (the included binary on the site at least). I haven't tried, but I'm betting that someone could mess around with it and reduce that size to 750kb probably, but if anyone wants to bet, I'm betting around 500kb, at least (maybe it would be a good challenge).
I'm also curious where you are getting your Xwindows figures from..
The only devices which would have the power to run kernel 2.6, would also be able to muster up 1 meg of harddisk space for an x-server. And the advantage of the Xserver is that it will run any Xwindows app. its no good having efficiency if all that could run is a clock.
Overall, I think it is a good idea (someone had to eventually try something like this), but would probably be better done independant of the kernel. Anything which can run a framebuffer probably can run an extra meg of data, and anything which can run a framebuffer I'd imagine you'd want to maximise compatibility.
Maybe its best to have some kind of xwindows support at least.. It might be bigger overall, but at the end, the extra 300kb it might take to get everything running, might be worth it.
Auzy
The driver on demand project
Not quite
The space overhead of X11 is not really in the X server itself but in the multitudes of supporting libraries required. For instance, with the latest XOrg release libX11 alone adds another MB, while the whole /usr/X11R6/lib directory consumes about 67MB.
That said, GPE makes X11 work for embedded devices (PDAs) so it is certainly possible. Shoving it all into the kernel doesn't seem to bring any real benefits while having some serious disadvantages.
So, you really have zero clue?
"I haven't tried, but I'm betting that someone could mess around with it and reduce that size to 750kb probably, but if anyone wants to bet, I'm betting around 500kb, at least (maybe it would be a good challenge)."
Arm-chair developer, go away.
Right Direction
Actually, I feel that this is the right direction to take. If you place the core parts of the GUI into the kernel, you can take full advantage of the hardware as well as kernel subroutines without allowing userspace processes to directly access the hardware (as X does). This will also allow kernel developers eliminate special-case powersaving functions for X that don't even work half the time. Even imagine a GUI subsystem that can't be pre-empted by other processes. I'd guess one of the next steps would be to provide a minimal userspace X server that does the translation from X to the linux kernel's native GUI interface for compatibiliy.
eh?
whats so innovative about this? isn't this pretty much exactly what Windows does? woop.
...
do you realize the poor responsiveness of X ?
I didn't try FBUI but any attempt to lower the GUI thickness is good.
For the record, Dave Cutler, the original creator of Windows NT hated the fact Microsoft asked him to put the GDI into the kernel.
Yes it has bloated the windows kernel as its creator thought, and yes, it made windows NT/2000/XP an user centric OS !
Now, X seems years behind speaking of responsiveness.
(see my recent post for example : http://www.linuxquestions.org/questions/showthread.php?postid=1253629#po...)
I'm a linux and an open source supporter happy administering all my linuxes servers.
But for years, my attempts to switch my desktop to linux have been a fiasco.
mac os x uses x window
I think x is catching up. XORG is the future of X11 and the open source desktop. The best place for a gui is in user space.
I fully agree
Listen, I have to be honest. XFree86 performance hasn't always been that great. But Composite & Keith Packard's xcompmgr, although still beta code, show me that Xorg can easily become as responsive as (or more responsive than) Mac OS X/Windows XP.
Right now, using Xorg 6.8.1, an Nvidia GeForce 4 card and xcompmgr -n, I can report that I see NO delay, redraws or any general "UI delay" when working with my system. Now, xcompmgr has a couple of bugs still (superficial ones, mostly), and from what I hear Composite only has good support with Nvidia's drivers, but this still shows me that we aren't far off.
That's all to say, we don't need to move the windowing server into the kernel. We can do this in userspace, and do it well.
Getting a more responsive X is easy
"Now, X seems years behind speaking of responsiveness."
Actually X is very responsive. If you're using X as a desktop system, just give it a higher priority. I usually renice to -20 the following processes:
* my X server
* my Window Manager
* my panel
This usually gives a pretty hefty interactive boost.
RE: do you realize the poor responsiveness of X ?
Perhaps you need help as I and others have been using Linux only desktops and laptops successfully for years, even in a non-cooperative Corporate environment where all desktops/laptops and most of the servers have been running Windows NT/2000. An environment where Citrix, Lotus Notes, Cisco VPN, MS Office and a host of other such apps were the stable daily diet. It also saved us from having to complete the annual MS software audits the company demanded.
There was nothing required that couldn't be done under Linux and some things were definitely better, no viruses, though we had to keep anti-virus software running under Linux to protect the Windows boxes other people were using, plus the stability and the increased productivity of not needing the frequent and heavy downloads to clear up or stave off virus/worm attacks.
RE: Right Direction
Isn't this the approach that MS took with NT4?
It might save context switches, but any errors in the GUI system could now be a show stopper - which reduces the stability of the system.
This all goes back to the old argument on whether you want a monolithic or micro kernel.
Do the benefits outweigh the potential disadvantages? For an embedded device that might not have a MMU, an error in one process might take down the whole system anyway, and the hardware is fixed and well known, so this could be a useful solution.
For general purpose systems I think that the track record of video drivers causing problems in Windows shows that this isn't always worth the gains in responsiveness.
Dumb idea
Oh great, let's just steal one of Microsoft's all-time WORST ideas: kernel-level graphics calls. Want to know why Windows NT took a nosedive in stability after WinNT 3.51? Because Microsoft moved the GDI into the kernel. Linux does NOT need this. I hope Linus nixes this.
what a clever guys commenting
what a clever guys commenting up things here
Finally!
I'll be able to put Linux on my watch!
Seriously, it's amazing what crazy stuff people will do just because the kernel's build system is so configurable. If you want to turn Linux into DOS with protected memory and built in GUI go for it. Not my bag, but that's the whole point of a configurable kernel.
Do you need Windows with anot
Do you need Windows with another name? :( I don't need it!
Oh come on
His implementation is so small because it has no features at all, putting the X-server into the kernel doesn't make it magically less bloated, it will be only smaller if the same can be done with less code, which isn't really the case (In other words: he could as well write a user space x server from scratch).
But leave him be, it's a fun project, he isn't putting all graphics into the kernel and bloating it, he's just painting on the framebuffer, very harmless.
Framebuffer
Frambuffer is mark as "experimental" in the kernel.
Bad Idea
From security point view a flaw in GUI can quite fatal than if GUI was in userspace (yes I am feeling a little paranoid).
Kernel space needs be protected!
Do you want to see kernel panic because of error in GUI? (don't think so)
And also I like to have to option to use a Command Line Interface without loading GUI.
Coming soon...
... the in-kernel web browser, email client and word processor. stay tuned.
Contiki?
Maybe we should consider porting Contiki (http://www.sics.se/~adam/contiki/) to the Linux kernel. That should give us a GUI (with overlapping windows, no less!) as well as a web browser, email client, IRC client, etc.
;-)
Just make Emacs your kernel, and you're all set... ;-)
(Laugh, people.)
This is a joke, right?
Placing a GUI into the kernel? If the World hasn't learned one thing from the Windows series, it's that integrated GUI/OS is a bad idea for almost every single reason you can imagine.
GUI in Kernel : not necessarily a bad idea
Hi guys,
It's sure, bringing a GUI in kernel means security problems etc.
But maybe your view of the problem is very restrictive.
This GUI needn't be a replacement for the X-windows system or whatever. I think it can be useful for machines in which you don't need a heavy GUI but that you want to be accessible in a user-friendly interface instead of pure console. Having a mouse and multiple windows can be time-savvy when you make maintenance operations. There is a lot of applications for this in-kernel mini GUI.
Joa
Light weight GUI in user-land
...and what stops you from implementing a very light weight GUI in user-land?
a mouse and multiple windows
gpm, screen, vtsplit ?
Why implement a terminal emulator inside the kernel?
sick joke
what sort of a sick joke is this ???
Please continue this work!
All current linux GUI is bloated!!!
=) Thanks man for your work.
HOPE this will bring change to the currently unsnappiness of GUI of LINUX.. and eventually beat Windows in terms of GUI resposiveness....
I really like the idea of GUI in kernel.. if this is best in terms of performance.. of course we can also deal with the security with the help of the whole community.. =)
THIS DOES NOT COMPETE WITH X11!
Fools, this is for embedded developers without the capability to do X! Jesus, read the frigging article! Stop with the stupidity.
Light weight GUI's
LinuxDevices.com has a list of existing light weight GUI's that can be used for embedded purposes without needing X. Why not just use or contribute to one of those instead of starting from scratch again?
X-window always has port's vulnerability
FBUI could does not have this vulnerability.
FBUI is good for quicker games, too.
NIH
Because the developers of this probably suffers of NIH syndrome, like many others..
Note that this is a problem, anyway I think that hell will freeze well before a GUI is accepted inside the official kernel (well I think I would have lost my bet for web server..)!
Wat r u talkin'bout?
Wat r u talkin'bout?
web server
A web server was included in 2.4 kernel. It was removed from 2.5 so it is not present at 2.6 (afortunately)
Don't need Tux server anymore
As I understand it, Tux was necessary because 2.4 had higher context-switch and I/O overhead, so doing zero-copy static page serving in the kernel was a win. With 2.6, much of that overhead has been eliminated, making Tux pretty much useless. Now, it's nearly as fast just to let Apache to do the whole thing.
actually, Apache was the problem
As far as I understand it, the slowness of Apache's "pre-fork" model was the problem. This model of how to serve up pages crippled it, making performance rather poor. TUX was added to address this for static pages at least.
Then several people noted that other pure user-space web servers perform just as fast as TUX (for example, see THTTPD) implying that the problem wasn't the kernel/user overhead, it was Apache's model. THTTPD and others used basic tried and true select for handling multiple connections, making them quite a bit faster than Apache.
Now, Apache has different goals, performance only being one of them - so their pre-fork model is in place for a reason. I suspect that if they went to a true select model (or one of the more scalable equivalent such as epoll or some such) they'd get even better performance, with little or no loss in functionality. Maybe not, I don't know enough of why they used the pre-fork model to begin with.
IMHO, X-windows is too big to
IMHO, X-windows is too big to manage it.
Simplicity & clearity is all that we have.
If we compare it with human body, X-windows is just like eyes.
And it's size more larger than human head!
BIG eyes and it is isolated...