Slashdot Mirror

What are you talking about? Doesn't OpenOffice run over the X11 Windowing System? Just install it on a server and run it from your X terminal.

I hear X doesn't run well with high latency, but that is Al Gore's problem. It's his job to fix the innernet tubes! If you just can't live with it, I suppose you could try porting OO to PicoGUI.

We don't need no vector graphics, what's wrong with bitmapped GUI's?
Actually, there is (was?) an open source alternative to vector based graphics long before Microsoft thought up this feature. It was available as the Pico GUI project. I just recently browsed their site, so it may just be down or... dead -- in which case there's always Google's cache. It's also still on SourceForge and freshmeat. It was originally meant for handhelds, but was supposed to expand onto the desktop.

If I designed a window system today, it would have themeable standard widgets, and the protocol (function calls for local, some sort of RPC for remote) would only have to specify the widgets to be used, as opposed to all the drawing operations, which is what X11 does.

Also, it wouldn't require each and every event (mouse move, click, ...) to be communicated between server and client. Rather, clients would be able to indicate which events they wish to receive for each widget (basically like onclick, onmouseover and friends in HTML).

All this is simultaneously going to do away with the many competing and incompatible GUI toolkits for X and the non-themeability of Windows and Aqua, and make network transperency work without huge bandwidth requirements and sluggish responsiveness.

It's worth pointing out that this window system exists in the form of PicoGUI. Sadly, the site is currently down.

By the way, what is it about OpenGL that makes it so suitable for acceleration, yet it's horribly slow when implemented in software?

I hope this means we're gotting one GOOD X server, instead of one that has the drivers but not the features, and one that has the features but not the drivers.

I still believe the Right Thing is to have an efficient system for local display, and a widget-based protocol (a la PicoGUI) for remote display, though.

Something like that does exist in picogui, see screenshot although this is blurring, not the scatter you write about. This way the background doesn't distract, but you can still see what's there.

Something like that does exist in picogui, see screenshot although this is blurring, not the scatter you write about. This way the background doesn't distract, but you can still see what's there.

I'm not talking about toolkit competion on top of X - that's somewhat a bad thing, because there's tons of repetition of effort, and the end result is inconsistency. That X allows this is its major shortcoming. I'm also not talking about eliminating X's network transparency - that's its best aspect, and must be preserved at all cost.

I want something with server-side widget rendering. This should be plugable and themeable, so their could still be competition. But since clients would communicate on the level of "put a button here" instead of "draw a grey rectangle with text here," it would be easy for all the programs on a display to have a consistent UI. There are some attempts to do this, PicoGUI and Fresco, but I want them to become popular, to compete, and to retain X compatibility (by having clients which are rootless X servers). It would take a few years, but the Linux status quo could move to something better than X, and we'd win in the long run.

It was featured a little while ago. It's a replacement for X, the window manager and the toolkit for today's lighter, more active PDA lifestyle.

See here but it's currently down. Head on over to #picogui on irc.slashnet.org for more info until the site comes back up.

So... perhaps the answer is to rework X.

Yeah, it's called PicoGUI. The problem with X (or the flexability with X, depending on how you look at it) is that you can do anything you want. It is the canvas -- what you put there is up to you. Of course, that means absolutely no consistancy. But, if someone does try to standardize the common functionality, it may not be taken too well and may just wind up joining the bazillions of other projects that have tried to do the same thing.

The Furby can run PicoGUI.

These are trying to make a difference:
Directfb, Cairo , Fresco and PicoGUI

The discussion about framebuffering was on the XFree86 open discussion mailing list last month.

You may want to look around. The project you describe probably already exists. The only one like this I can think if is PicoGUI, however I'm not sure if it has all the features you described.

Wouldn't it be nice to have a terminal window that actually knew the difference between a canvas and a text widget on the server side and acted appropriately?

How I understand it, X does this because it was made for a server/terminal model--the server running X clients, and cheaper terminals running the X "server". Expecting the terminal to use more processing power would mean either more expensive terminals or poor performance. Why else would X have been designed this way? X was created long ago when the mainframes ran the code and ruled the world.

It sounds like you don't want X at all. I believe there are several projects which work similar to what you describe. The only one I can think of off the top of my head is PicoGUI. Maybe I just don't know enough about the X protocol, but it seems to me it would be easier to start over, and it appears some have done so. If you're serious about wanting those features in a display server, then you may want to start using/working on one of these projects and help evangelize it.

I don't have enough problems with X to see the point in switching yet. Though I do recognize it as archaic and understand why one of these projects may be better. If I had the time and patience, I'd probably try to help out, but I don't...maybe you will fare better. I suppose it'd be time better spent than on something like Xouvert. Not to knock the guy who started the project--Xouvert will most likely be useful. The only problem is getting the video card manufacturer's support for "rogue" systems...

ack...slashdot plaintext still requires escaping lesser-than signs...sorry for the broken post. :-(

My biggest annoyance with Linux (and other *nixen) has been X11. Admittedly, XFree86 is a fantastic piece of work and it offers great compatibility with every other version of X out there, but at the same time there are so many things wrong with it.

First off, it's slow. Plain and simple. It takes a long time to start up, and drawing operations seem very inefficient - ever tried to watch a movie? I realize that this is a side-effect of X originally being intended to be used over a network, but I have two arguments against this. First off, it would be better to have a snappy graphics subsystem running locally, with an optional networked system on top of it. Secondly, the protocol used by X11 can't be too efficient; at least, TightVNC uses less bandwidth. I think PicoGUI gets it right. The startup time could probably be reduced a bit by using the OS's keyboard etc. drivers - which would also save users from having to configure them once for the OS and once for XFree86.

Secondly, XFree86 is huge. Several megabytes get you a graphical subsystem with keyboard and mouse support - but we already have all of these in the kernel. The kernel framebuffer does just fine on my < 4 MB 486, now try to get XFree86 running on that. Okay, X11 offers a lot more functionality, but often you won't need that - how many people run their X server and clients on the same machine?

Configuring XFree86 can be a real nightmare. Fortunately, starting from 4.0 there's a VESA driver, so now one can be reasonably sure that it works with any modern graphics card. However, the last 4 times I installed XFree86, it wouldn't work with 32 bits color depth. I know I need to configure with depth 24 and fbbpp 32, but the installers I've seen never got it right by themselves.

Finally, I would like to say that I am happy enough to have XFree86. I just wish it would be better. I also know that some have said that XFree86 can be quite fast if programmed right, but the fact remains that I can't watch movies under XFree86 that run smoothly under Windows on the same machine, and Opera/Windows blazes away whereas Opera/Linux is ``merely'' fast.

My biggest annoyance with Linux (and other *nixen) has been X11. Admittedly, XFree86 is a fantastic piece of work and it offers great compatibility with every other version of X out there, but at the same time there are so many things wrong with it.

First off, it's slow. Plain and simple. It takes a long time to start up, and drawing operations seem very inefficient - ever tried to watch a movie? I realize that this is a side-effect of X originally being intended to be used over a network, but I have two arguments against this. First off, it would be better to have a snappy graphics subsystem running locally, with an optional networked system on top of it. Secondly, the protocol used by X11 can't be too efficient; at least, TightVNC uses less bandwidth. I think PicoGUI gets it right. The startup time could probably be reduced a bit by using the OS's keyboard etc. drivers - which would also save users from having to configure them once for the OS and once for XFree86.

Secondly, XFree86 is huge. Several megabytes get you a graphical subsystem with keyboard and mouse support - but we already have all of these in the kernel. The kernel framebuffer does just fine on my some have said that XFree86 can be quite fast if programmed right, but the fact remains that I can't watch movies under XFree86 that run smoothly under Windows on the same machine, and Opera/Windows blazes away whereas Opera/Linux is ``merely'' fast.

Try PicoGUI with the ncurses input/output devices.

i don't see use in realtime irc reporting, but the stats page is interesting.
i only wish it were more informative;
quantity would be better served by icons or even colors;
the more active are brighter and the less active duller.
i would like to see "average day in past week/month/year" as a ratio comparing to total,
so for example the entry for week could read "19:133"
meaning there were 19 commits in the average day last week.
this would better show changes in activity.

Hmm, I've been using an embedded linux with a NON X gui for at least 2 years now....

it's called picogui

Plus you dont have to buy it, and it's much smaller.

PicoGUI isn't X, or X compatible. It's a completely new GUI framework. It's design goal is not compatibility with other GUIs, but to explore a unique architecture that especially benefits handheld computers and other embedded systems

That should've read:

I completely agree. X is horrible. PicoGUI seems to be doing well, and hopefully it'll address these problems when it's more mature. I can't say for sure, though, because i'm really not very Linux-smart, and i couldn't get it to compile. (Oops :D )

Forgive my idiocy. I've spent too long posting to forums that use stuff like [url=http://www.blah.com]. Sigh.

Just as Linux, BSD, SCO and a few others all provide implementations of (more or less) the "UNIX" specification on i386 hardware, there are multiple implementations of the X11R6 standard on i386-based unixes.

If you don't like XFree86, the folks at XiG would be happy to sell you a copy of AccelX. MetroLink systems still offers Metro-X (which was the bomb back in the RedHat 4 days...dunno about now), and if you don't have any money to spend, you can still download, compile and use the honest-to-god MIT/XConsortium X11R6.6 server.

If you want a windowing system that's not based on X11, your options are a bit more slender, but they're there. The Fresco project (formerly "Berlin") looks promising, as does PicoGui.

Not sure if you guys are familiar with picoGUI, but it's goal is to fix all of the current problems with XFree86. I think the url is: www.picogui.org. They have some nice screenshots too.

Not sure if you guys are familiar with picoGUI, but it's goal is to fix all of the current problems with XFree86. I think the url is: www.picogui.org. They have some nice screenshots too.

Karma to burn (not like it really matters anyway)!
OZ doesn't have an email client. OZ is just the underlying filesystem and system, not the gui or the applications. Opie is the default GUI/application set that OZ uses. PicoGUI is really coming along, though, and that's another option for a GUI.

I can't dispute your claims on the Revo, however, because I've never owned one. I can say that I prefer my Zaurus over my old Visor Deluxe, however, even though most people claim PalmOS is "better". The interface surely isn't better and it's a nightmare to develop for, which is a big reason I like the Zaurus. If there's not an application out there that does what I want the way I want it I don't have to go spend hours upon hours learning new APIs just to make a small application. I can just use my knowledge of linux development and qt and directly apply that.

URL: http://dunkels.com/adam/contiki/links.html

System information and emulators

Commodore 64/128

The Commodore 64 is based on the 6510 CPU, which is a 6502-derived 8-bit CPU. It has 64k of RAM and 16k ROM which includes a BASIC interpreter and some basic I/O services. Graphics is provided by the VIC chip which has 16 colors and a maximum resolution of 320x200 in hi-res mode. It provides a 40x25 raster of characters in character mode. The three voices of digital sound is produced by the SID chip.

The Commodore 128 is an extended version of the Commodore 64 that contains a 8510 CPU which is capable of 2 MHz operation and can address 128k RAM (hence the name Commodore 128). It also has a Commodore 64 compatibility mode which is extremely similar to a regular C64 but with a few minor differences.

The SuperCPU is a 20 MHz 16-bit 65816-based computer that is plugged into the back of the Commodore 64 or 128. It uses the C64 keyboard and joysticks for input and the VIC and SID chips for audiovisual output. The SuperCPU is capable of addressing several megabytes of memory and is usually used together with a 16 megabytes RAM expansion board.

There are no SuperCPU emulators avaliable.

• The VICE emulator is capable of emulating a large number of Commodore machines. It emulates the C64, the C128, the VIC20, most of the PET models, and the CBM-II. VICE runs under Windows, Linux, FreeBSD, and a number of other host systems.
  
• Joakim Eriksson's Web C64 emulator, written in Java, runs as an applet within a web browser.
  
• Per Håkan Sundell's CCS64 emulator works under Windows and DOS.
  
• The ec64 emulator is developed for Linux and was originally written entirely in x86 assembler.
  
• An article by Simon N Goodwin about C64 emulators.
  
• The Commodore emulators category in the Dmoz has more links.
  

Commodore 64/128

There are plenty of alternative operating systems for the C64, mostly written in 6502 assembler. Some of them are far from complete, however, and only appear as dark shadows on a few web pages - MagerValp's SMOS and my own osT are among those.

• GEOS from 1986 probably is the most well-known graphical operating system for the C64. It is still sold commercially by CMDKEY.com.
  
• LUnix NG is an open-source multi-tasking operating system with TCP/IP/PPP-support, a *nix-like command shell, and a number of *nix-like utilities such as ls and cp.
• Craig Bruce's ACE is a text-based single-tasking operating system for the 64 and the 128. It provides a *nix-like command shell, a text-editor, a terminal program for the SwiftLink RS232 interface, as well as device drivers for a lot of devices
  
• GeckOS/A65 is a multi-tasking operating system with TCP/IP support and a *nix-like command shell.
  
• Wheels is a version of GEOS that requires RAM expansion to run.

With its 20 MHz and megabytes of memory, the SuperCPU is powerful enough to run fully-fledged graphical operating systems that rival early Machintosh or Microsoft Windows systems.

• Wings is a TCP/IP-enabled graphical operating system for the SuperCPU. It includes a MOD music player, JPEG viewer, web page download utility, etc.
• JOS is an older version of Wings.
  

TCP/IP and PPP connectivity

To surf the web, send or read email, etc., the first step is to actually get in touch with the Internet. This requires both physical access to an ISP, either via a modem and a phone-line or an Ethernet broadband connection, and the TCP/IP software running on the C64.

There are a number of programs that make it possible to reach the Internet with a C64/C128.

• LUnix NG contains a TCP/IP stack and a PPP implementation which makes it possible to reach the Internet using a modem and a dial-up ISP.
  
• GeckOS/A65 also contains a TCP/IP stack, but no PPP dialer.
  
• My own uIP TCP/IP stack has been used for some time to run a web server on a Commodore 64. uIP currently does not include a PPP dialer.
  
• Novaterm 10 contains a PPP dialer and enough TCP/IP code to be able to run telnet over the Internet.
  

SuperCPU

All of the above mentioned SuperCPU operating systems have TCP/IP support.

• The Wave is a web browser for the SuperCPU (and not for the Commodore 64/128 as the web page claims) that runs under the Wheels operating systems. Here is another page with information about The Wave (that also falsely claims that The Wave is for the Commodore 64/128). The latter page also includes screenshots of The Wave in action.
  

Small graphical user-interfaces (GUIs)

User interfaces for embedded systems range from the simple buttons on the front of a washing machine to those of fully fledged web browser type interfaces on information stations. The underlying technology varies from simple electronic circuits to full-scale PC compatibles.

• PicoGUI is a GUI architecture designed for embedded systems to desktop machines. It does not require any supporting GUI system and can be used on anything from graphical screens to text based systems. Their smallest target system are handheld terminals and the compiled object code size is on the order of hundreds of kilobytes.
  
• Microwindows/NanoGUI is a graphical user interface system designed to run without support from an underlying system. On 16-bit systems Microwindows is about 64k large.
  

The smallest web browsers are usually specially designed for the limitations of embedded systems and other specialized computers such as car navigation systems, set-top boxes and medical equipment. There are also a few small web browsers for old DOS PCs available.

• Interniche's NicheView Portable Embedded Web Browser is probably the smallest full-featured web browser around with its 35 kilobytes code footprint. There is also an additional JavaScript module available.
  
• AU-systems' AU Mobile Internet Browser supports both HTML/TCP/IP and WML/WAP as well as SSL. It occupies 340 kilobytes of code (plus an additional 190 kilobytes for the protocol stacks) and uses 5 kilobytes of RAM when idle (plus 8 kilobytes used by the protocol stacks). Extra RAM is used when downloading web pages.
  
• The Fusion WebPilot Embedded Micro-Browser supports much of the features found in modern web browsers including frames, authentication, and JavaScript. The web page does not specify memory footprint.
  
• MicroDigial's Graphical MicroBrowser supports tables, frames, images as well as FTP as uses 260 kilobytes of code memory and requires a minimum of 210 kilobytes of RAM apart from that. A demo version is available.
  
• The 2net Alice Web Browser is intended for handheld computers and PC based architectures and requires 400 kilobyte of free RAM and 200 kilobytes of code memory. It includes a TCP/IP stack.
  
• WebBoy is a fully-fledged browser with SSL support intended for 386 DOS boxes with more than 4 megabytes of memory. Includes a TCP/IP stack.
  
• The Arachne web browser runs under MS-DOS or Linux and requires at least 1 megabyte of memory. Does not include a TCP/IP/PPP stack.
  
• Lynx is probably the most well-known text-based web browser around. It is ported to many different operating systems and architectures including MS-DOS.
  
• The Off by One Web Browser has been labeled as the smallest web browser ever, but is quite large in comparison with other small web browsers. It is 1.1 megabytes large and requires support from an underlying Windows operating system.
  
• Mirko Sobe's BOSS-X HTML browser for 8-bit Ataris is not a full web browser, but an off-line HTML viewer with hyperlinking abilities written in three days.
  
• The pre-alpha v0.3 GEMWeb browser supports 640x480x16 VGA.
  
• The Atari Phoenix Web Browser is a non-existant vapor-ware web browser project intended for the 8-bit Ataris.
  

I tend to think that with the advent of picoGUI and GTKfb (potentially), X-Windows could (stress on could; I love X-Windows) be phased out. These systems offer a new way to access video hardware and framebuffers, etc. directly and as a direct result, they could offer a much more responsive, faster and enhanced GUI.

Your mileage might vary, but I'm very interested in these projects...

I have mixed feelings about this one. Although having a Qt port of Mozilla is nice, because it prompts developers to properly separate function from UI, I think the reason it is so poorly maintained is simply because there is no need for it.

The reason I used Mozilla is that GTK is my favored widget library, and I didn't want to install any other. There are other browsers for Qt, for example, Opera, which is smaller, faster, and more standards-compliant than Mozilla (or it's stripped-down version, Phoenix). If the point of porting Mozilla to Qt is running it on a Zaurus (or similar handheld), I say ``Don't bother''. Opera is optimized for such environments. Yes, it's closed source, and it's free for non-commercial use, just like Qt is.

So, to conclude, I don't care much what happens to Mozilla/Qt. Atomic Navigator, the browser in PicoGUI, also needs developers.

I think it's also neat that PicoGUI supports multiple (programming) languages simply by having a documented net protocol -- language bindings talk directly with the renderer over the net, instead of wrapping some C interface.

PicoGUI is also small and cross platform. It's certainly not as old as Fresco, but it looks like they're going to lap Fresco pretty easily.

On another front -- what's Fresco's comparison to NeWS? NeWS, a competitor to X from Sun (late 80's?), had some concepts that were similar to Fresco (and PicoGUI). Considerably more display logic was on the server (renderer). It apparently had lots of bugs and issues, but it actually did reach a usable state. Have they learned from this predecessor? Neither project seems as flexible (NeWS used Postscript for its widgets, so new widgets could be nearly arbitrarily complex)... that flexibility may have been NeWS downfall.

Anyway, it always seemed like a neat idea and an important project to learn from.

Just wait... someone will release a Linux distro that runs on it, and you might even get a port of PicoGUI for it. $299 is a pretty good price for 400MHz/64MB device.

Actually, it does support overlapping windows. See this screenshot for proof.

Look here. It can run zsnes. I can play Final Fantasy VI. What else do you need?

Regards, Tobias

As always, what you should use depends on your needs. If X works perfectly for you, then great. As a "frame-buffer oriented network-transparent graphics API" it'd be hard to beat. As the foundation for kits like Gtk and Qt (and even PicoGui sometimes) it works well.

However, as a platform (a standard for application creation) X is sub-optimal for users and developers.

The value of a standard comes not only from what it allows you to do, but what it forbids.

Suppose I write 3 programs to perform the same tasks under different GUIs: Microsoft's, Apple's OS X Quartz/Aqua, and X11R6. A Mac user can sit down without looking at the instructions and use his familiar old mouse motions, menu commands, and keystrokes with hardly a glance at the new stuff. A Windows(tm) user has nearly the same advantages. The icons for the same feature (Save, Print) look exactly the same, regardless of the program.
Of course that's not the case for X programs. Whenever I sit down at a new X11 program, I have to spend a few minutes recalibrating the basics ("How to I copy/paste, again?")

Because X allows the developer so much freedom, it deprives the user of the ability to anticipate how a program will operate. "The program can do nearly anything" sounds like an advantage, until you try to predict what a program will actually do!

Note that a weakness of Apple and Microsoft's GUI systems is that the "forbidding" part of their standard often comes in the form of "law" instead of "code". The taboos are enforced by developers getting chastised by the GUI vendor or the public when a non-ituitive program is released.

A weak method- the lag time for feedback is long, and if the offending developer works for the GUI vendor, he might insert loopholes into the rules.). But it produces superior results to X programs, where the users lack an imposing rulebook to point to as formal justification for their complaints. Improvements may happen, but there's nothing forcing them to converge on one way of doing things.

Some common responses to this argument:
"You want a toolkit, not X"
Maybe so. If a user's desktop could only run one toolkit, she'd never see an unfamiliar interface. This has the problem of discarding pre-existing programs, but argument-by-popularity is a logical fallacy (I'm talking about what solution would be best, not cheapest short-term). Better than using a single toolkit, though, is somehow allowing the application to be written independent of toolkit, and obeying whatever HCI conventions a particular user enjoys. PicoGui tries to do this.

"No one can be sure what the best interface is. Keeping flexibility gives us power."
In theory it does, but at the expense of accessibility. Too often it means that developers who don't want to be "HCI Researchers" find themselves wrestling with UI code that's entangled their applications.
PicoGui (and other "next-generation" UI systems) attempt to resolve this by keeping the application programmer further from the UI code than is traditional. (They haven't been totally successful yet)
He can't mess with the per-pixel alignment of buttons, because that's outside of the application's control.
This is fundamentally better than the way Apple and Microsoft's traditional Human Interface manuals have worked, because enforcement of the rules is done not by humans (punishing programs that act wrongly) but by software (doing the work for you, so it's guaranteed to do it right).

Some information for the curious:

1. Micah (the lead developer) compiled some info at http://picogui.org/wiki/view/Main/PicoGUI and http://picogui.org/wiki/view/Main/FAQ
2. it is not X. It cannot run X apps. No way. Period.
3. it is very early in development. I use it for a few things, specially in my PDA, but it's a living-on-the-edge experience.
4. there are client libraries for C and python; there are the beginnings of a tcl library, dunno how usable, and an old perl library which needs work. There is also a waba (java) library, but I don't have any idea of its status.

1. a terminal widget that runs things like mutt, emacs, lynx|links|w3m
2. a web browser; porting mozilla sounds like the obvious choice
3. and, of course, apps.

Some information for the curious:

1. Micah (the lead developer) compiled some info at http://picogui.org/wiki/view/Main/PicoGUI and http://picogui.org/wiki/view/Main/FAQ
2. it is not X. It cannot run X apps. No way. Period.
3. it is very early in development. I use it for a few things, specially in my PDA, but it's a living-on-the-edge experience.
4. there are client libraries for C and python; there are the beginnings of a tcl library, dunno how usable, and an old perl library which needs work. There is also a waba (java) library, but I don't have any idea of its status.

1. a terminal widget that runs things like mutt, emacs, lynx|links|w3m
2. a web browser; porting mozilla sounds like the obvious choice
3. and, of course, apps.

Check out the screen shots for more.

OPIE candy

PicoGUI candy

Just to show a few.

Three words: PicoGUI.

``I currently use Windows for ease of use.''
That's the exact same reason I use Linux and OpenBSD. Try to do some of the more advanced networking stuff. Try coding, especially cross-platform software. UNIX-like is easy, Windows is hard.

``you can specify what programs you want to handle certain types of files''
That's a good point. mutt has it. lynx has it. Mozilla has it. gentoo (the file manager) has it. Now if they all used the same database...again, standards rule, and not because there are so many to choose from.

``the operating system remembers your choices''
That is, until you install that other media player that steals your files from your favorite media player, or try that alternative browser or email client that brutally makes itself the default...this is one of the reasons I dislike windoze.

One thing I would very much like to have is good OpenGL support. Linux does OpenGL, and so does my graphics card. Than why can't I get my video card to do OpenGL under Linux??? Answer: because the graphics card market is a huge mess where not even the boards from the same factory are compatible with each other, and, again, lack of an open, universally (or near-universally) adopted standard (that is, hardware level, in this case). VESA did the right thing bak then, where are they now?

The issue outlined above, and others like it (think Winmodems [sic], printers, soundcards, network cards, etc. they all provide the same functionality, but are completely incompatible) is not so much a problem of Linux per se, as it is a problem with hardware manufacturers. It's probably cheaper to write a Windows driver than to make the hardware compatible with other hardware, or maybe making it compatible would be a patent infringement? Still, it would be nice to have hardware that Just Works (WOW) because it's standardized, instead of having to write a new driver for every other piece of hardware that is released.

Where should Linux go? Well...I am a great fan of QNX's modular and extremely scalable architecture. I know that Linux is very scalable already, and I know that Linux dislikes, or at least used to dislike, microkernels. I think that QNX has proven that microkernels can rock, so maybe it's time to take the last few steps and convert everything to modules and go microkernel. Or maybe I should be convert to Hurd.

Another thing that would be good for Linux to have is a reworked GUI system. This goes for all Unices, BTW. X is king of network transperent operation, and there's hardly a day that I don't use it, but it has it's flaws. I think the way to go is to have a lean and mean system for local stuff (think: raw speed, multimedia, BeOS) and implement a network-transparent system on top of that (PicoGUI is one of my favorites, it uses bandwidth efficiently and is highly portable). Of course, applications should choose between systems at run time, quite like it is done with X. For efficiency, I think something along the lines of detecting wether it's run remotely or not, and load a different set of libraries for each case. Again, though, I think this is not a Linux issue.I have a really hard time thinking of anything in Linux that really needs improving...So, yeah, they should go on a vacation.

Sorry for the long post...this is just like a brain dump.

---
savecore: No core dump

If you look at some of the real next generation GUI projects out there like Fresco or PicoGUI client-server architecture is still important in the design, but other changes are happening: the applications communicate with the server at a higher level, the server handles rendering in more modern ways, etc.

But client/server is definitely a good thing, and itn't just for running remote apps.

I've been working on an alternative GUI that might be better for cases like this, since the widget toolkit is implemented server-side, and client applications require hardly any memory.

Seriously though, how fast could this be? I know that there are some ARM processors with built in 3D acceleration.. maybe that's what it's targeting?

How many things in X will we need to fix?

Looking for this? I personally think X (or at least XFree86) is outdated at the core. This has been solved by adding numerous extensions, but that doesn't really solve the problem. Can an application programmer count on the presence or functionality of extensions on any system? What we need is a new design, based on the experiences with X.

I like network-transparency (it's a huge win in some situations), but X uses far too much bandwidth. What about a widget-based approach like PicoGUI? Add window overlapping and implement smoothed fonts on server-side, then write a rootless X-server for it, and I think many people might have a shot at running it on their desktops.

• Berlin Consortium
• QTopia
• PicoGUI
• Relevant Freshmeat Trove
• Google's Linux specific engine results

Although this is a big april fools hoax, a real example of a GUI that works on the console can be found over at PicoGUI. (as featured formerly on /. and elsewhere)

The display framework of PicoGUI is so extensible that it will work on everything from a text-only 2 line LCD display (or smaller) up to a fully realized 3d environment courtesy of OpenGL (needs someone to code it but the OpenGL "display" driver is already in there).

Some examples:

X-Chat/PicoGUI running using PicoGUI's ncurses driver on the console:
http://www.picogui.org/sshotdetail.php?index=47

A couple of PicoGUI apps running on a 4 line Text LCD:
http://www.picogui.org/sshotdetail.php?index=64

PicoGUI running on OpenGL:
http://www.picogui.org/sshotdetail.php?index=60

This is mostly possible because of PicoGUI's strict distinction between content and presentation (Remember the design goal of the original HTML? - Bingo.) Anyway, it's a neat project to check out; the support for this is in and working now; it runs on everything under the sun; and development continues to progress at an extremely rapid pace.

~GoRK

Although this is a big april fools hoax, a real example of a GUI that works on the console can be found over at PicoGUI. (as featured formerly on /. and elsewhere)

The display framework of PicoGUI is so extensible that it will work on everything from a text-only 2 line LCD display (or smaller) up to a fully realized 3d environment courtesy of OpenGL (needs someone to code it but the OpenGL "display" driver is already in there).

Some examples:

X-Chat/PicoGUI running using PicoGUI's ncurses driver on the console:
http://www.picogui.org/sshotdetail.php?index=47

A couple of PicoGUI apps running on a 4 line Text LCD:
http://www.picogui.org/sshotdetail.php?index=64

PicoGUI running on OpenGL:
http://www.picogui.org/sshotdetail.php?index=60

This is mostly possible because of PicoGUI's strict distinction between content and presentation (Remember the design goal of the original HTML? - Bingo.) Anyway, it's a neat project to check out; the support for this is in and working now; it runs on everything under the sun; and development continues to progress at an extremely rapid pace.

~GoRK

Although this is a big april fools hoax, a real example of a GUI that works on the console can be found over at PicoGUI. (as featured formerly on /. and elsewhere)

The display framework of PicoGUI is so extensible that it will work on everything from a text-only 2 line LCD display (or smaller) up to a fully realized 3d environment courtesy of OpenGL (needs someone to code it but the OpenGL "display" driver is already in there).

Some examples:

X-Chat/PicoGUI running using PicoGUI's ncurses driver on the console:
http://www.picogui.org/sshotdetail.php?index=47

A couple of PicoGUI apps running on a 4 line Text LCD:
http://www.picogui.org/sshotdetail.php?index=64

PicoGUI running on OpenGL:
http://www.picogui.org/sshotdetail.php?index=60

This is mostly possible because of PicoGUI's strict distinction between content and presentation (Remember the design goal of the original HTML? - Bingo.) Anyway, it's a neat project to check out; the support for this is in and working now; it runs on everything under the sun; and development continues to progress at an extremely rapid pace.

~GoRK

Although this is a big april fools hoax, a real example of a GUI that works on the console can be found over at PicoGUI. (as featured formerly on /. and elsewhere)

The display framework of PicoGUI is so extensible that it will work on everything from a text-only 2 line LCD display (or smaller) up to a fully realized 3d environment courtesy of OpenGL (needs someone to code it but the OpenGL "display" driver is already in there).

Some examples:

X-Chat/PicoGUI running using PicoGUI's ncurses driver on the console:
http://www.picogui.org/sshotdetail.php?index=47

A couple of PicoGUI apps running on a 4 line Text LCD:
http://www.picogui.org/sshotdetail.php?index=64

PicoGUI running on OpenGL:
http://www.picogui.org/sshotdetail.php?index=60

This is mostly possible because of PicoGUI's strict distinction between content and presentation (Remember the design goal of the original HTML? - Bingo.) Anyway, it's a neat project to check out; the support for this is in and working now; it runs on everything under the sun; and development continues to progress at an extremely rapid pace.

~GoRK

Actually, the X window system falls into your "Intercepting Graphics Libraries" bin. The widgets in X are not standardized. Applications usually use a shared library to provide any widgets they need, and the widget sends drawing commands. This lets apps use any widget set they want, but it's relatively high bandwidth.

There are a few GUIs that can send widget commands via a network though. PicoGUI, a project I have been working on for a while, does this. I think Photon (QNX's GUI) can do this as well. There are a lot of advantages- in PicoGUI's implementation, all the widgets are implemented in the server. The network communication is very low bandwidth, and the server has all the information it needs to redraw the screen or scroll without any interaction with the client. This for example would make a remote web browser take some network activity to load a page, but viewing and scrolling the page would be done without any network access. The disadvantage to this system is that it requires completely rethinking the GUI, so there isn't much software available for it yet.

<shameless plug> of course we could always use help with the PicoGUI project :) </shameless plug>