X Windows Must Die! 446
Kernel Sanders writes: "I frankly don't see much light at the end of the tunnel. X is too deeply embedded in the Unix world to be easily dislodged, and the lack of a GUI standard on the platform doesn't appear likely to be resolved. Maybe the embedded space can offer some salvation -- programmers will *have* to forgo X to run on smaller devices, and perhaps this will be the wedge that gets X out of all our lives."
Re:Handhelds.org has it on on iPaq (Score:2)
-russ
There IS NeWS (Score:2)
Well, there IS NeWS. ("KNEE-wiss", not "news") Or at least there was. Built on Display Postscript. Nothing in the standard window management defined in terms of pixels (so the screen resolution didn't foul you up).
Big complaint is that, while it had a lot of handy capabilities it was somewhat slower than X. That was a decade ago, when processors were a LOT slower, AND NeWS didn't cache fonts. But that was then.
With today's processors the differential in speed might not be a problem. Either would "snap". And NeWS should be an ideal vehicle for taking maximum advantage of graphics accellerators, which might make it pass X.
(Or at least I THINK it would be good. I haven't been into the guts of it.)
Grasshopper Group (Gillmore, Henson, Daniels, in no particular order) did a quite workable one for the Apple Macintosh running A/UX about a decade back. When Apple wouldn't let developers know who was using A/UX OR forward mailings, they cut a deal with Sun to do an X/NeWS merged system. Which Sun then dropped, but wouldn't release the rights to their code.
Maybe, after a decade, Sun might want to reconsider and open-source it. That would provide a nice starting place.
If not, what was done once can be done again.
Name stood for "NEw Window System". Maybe it could be resurrected and renamed OlWS. B-)
Re:Corporate Rock Pig (Score:2)
The pig part relates to our reputation (in the UK at least) for being alcohol fueled maniacs. This doesn't stop us selling several thousand CD's a year, or playing some quality gigs. In the last month alone we've played London twice, Leipzig in Germany and Oporto in Portugal. Fitting that in around work is a nightmare though.
Chris
X is software engineering at its worst (Score:3)
The truth is that it takes very little code to do what X does. One of the most minimal windows managers for X, Blackbox, is approximately 12,000 lines of C++ (the author likes to give a line count). Think about that. 12,000 lines of code to simply act as an interface between you an X in a very minimal way. You could write an entire GUI, including hardware-specific code, in 12,000 lines. Maybe it wouldn't be KDE, but it shows how far off base we've become. Don't believe it? here [ultratechnology.com] is a functioning GUI, which doesn't use any external libraries for graphics, done in a few kilobytes of object code.
Re:It's not THAT bad (Score:2)
Personally, I think the correct approach would be for a windowing system to be completely local. That way, you can slap on a light-weight X server or whatever server if you need remote capabilities. No "morphing" required. This is what (I believe) the first incarnation of Berlin was, but unfortunately they've hopped on the remote object bandwagon.
Re:We couldn't really do this until now (Score:2)
That depends on your definition of success. The BeOS port is reportedly pretty flaky at the moment, but I'd say the Win32 port is almost there. Certainly it's usable today (it's good enough to run gimp under Win32), even if it's not yet quite as stable as the X version.
Re:We couldn't really do this until now (Score:4)
Ummm ... GTK+ has such a layer. It's called GDK [gnome.org].
The GDK library provides a layer of abstraction that sits between GTK+ widgets and applications and the underlying windowing system. Instead of making calls directly to the X window system, applications call GDK when they need to draw to the screen or handle events.
This extra layer of abstraction provides several advantages. First, it increase portability. Porting GTK+ (and hence, to a large part, GNOME) to another windowing system reduces to porting the GDK layer. A port to Microsoft Windows has already been done. Also, it allows GTK+ programs to transparently use a number of X extensions that may or may not be present. If they are not present, GDK provides substitute functionality in terms of standard X calls. Finally, in many cases, the GDK calls are simpler than the corresponding X calls. Some rarely used parameters are omitted and the correct values for other parameters are determined automatically.
----
Re:We couldn't really do this until now (Score:3)
I can't speak for Qt, but GTK+ is not built on X. It's built on gdk, and GTK+ apps will run on any platform that gdk does. Yes, gdk was originally built on X, but it has since been ported to Win32 and BeOS, and work is underway porting it to Microwindows/Nano-X [censoft.com].
As an embeded programer (Score:5)
I program embedded systems. We are switching our Os from vxWorks to linux, because linux has some features we need. (We are accually doing a hybred, some processors will still use vxWorks, where they do real time processing, but those that just control the box are going to linux.
X is a big advantage to us, and the biggest part of it is remote display. We don't have a display of any sort on the machine, nor a keyboard. If we want to run a program it has to display across the network. I can log into whichever processor I need, start a xgdb session back to my desk and debug. Sure there is remote debugging in gdb, but that doesn't work so nicely.
I think you will find more embedded systems devoplers going to X because is allows them to remotly display debugging back to the desktop. There are free implimentations of X, and plenty of libraries and expirence working with it. Drop that into the box, and once it works anyone can use it.
Re:You want Windows then. (Score:2)
---- ----
Re:bullcrap (Score:3)
Re:It's not THAT bad (Score:2)
"One or the other" seems like a very Windozy viewpoint.
--Elrond, Duke of URL
"This is the most fun I've had without being drenched in the blood of my enemies!"
Re:[OT] Re:Corporate Rock Pig (Score:2)
Yup. I've taken a couple of months out to sort out my career and a certain other matter
Unless of course Richard and Alien Dave do another impromptu electronic set in the meantime. Belle and I were barely able to contain ourselves watching Alien's two finger keyboard playing on Friday - although Richard did have to spoil the illusion by pointing out the keyboard wasn't plugged in
Chris
Re:There IS NeWS (Score:2)
I don't think Apple had anything to do with the X/NeWS merged system.
Right. As I said, it was the same people who had previously done, independently of Apple, a NeWS for A/UX, which they wanted to sell to A/UX users. When they got no marketing support from Apple, they contracted with Sun to build the X/NeWS thingie for Sun.
By failing to support such outside developers, Apple proved that A/UX was what it had been rumored to be - a mechanism to enable US government departments to check the "it has a UNIX" box to satisfy the upper eschelons (who were trying to standardize the government computers on Unix).
Later on A/UX proved to be handy for checking that applications were 32-bit clean, when Apple migrated their OS - since it required such cleanliness to run Apple apps. So Apple told the developers they wouldn't certify anything that didn't run on A/UX, as a handy way to get things ported.
They should open-source it. People have been asking for this for 12 years now. I think the original (ie non-X merged) version should be made available. Please, Scott?
Yes: Pretty please with syntactic sugar on it!
X fonts (Score:4)
The problem with X is that you can't really get anything but glyph bitmaps from the fonts. Even when you're using a scalable font -- it still rasterizes the glyph at the requested size and then sends you a monochrome bitmap.
You can't get kerning info, you can't get unicode mapping tables, you can't get various other glyph metrics; the list goes on and on.
No arbitrary linear transformations of glyphs either -- at least not unless you want to do it yourself after-the-fact on a low-resolution monochrome bitmap.
Okay, let's say you request a glyph bitmap much larger than you actually need, so you can transform/antialias it and then scale down (this is what The GIMP does, for example).
Whoops. Most X font servers crap out above a certain glyph size. (last I tried, XFree86's did)
I'm a graphic designer and a programmer; I know what I need from a font subsystem to do more than simply display some text, and I know X's font subsystem would have to be replaced for me to get it from X.
(and note that thanks to the existing design, the replacement would have to be incompatible, or you'd have to implement both the old and new protocols, duplicating a lot of code
We Have X Because Sun Wanted to Keep Da Goodies! (Score:5)
About fifteen years ago, Sun [sun.com] pulled a classic move akin to the blunder Apple [apple.com] made in not licensing the MacOS. Sun had a beautiful system called "NeWS" (for "Networked Windowing System"). It used PostScript for the basic rendering model, but added interaction, threads (!), object-oriented programming, and networking. Windows were defined by PostScript clipping paths, which meant you could have a window shaped like a text string if you wanted (years before X added the Shape extension). It was more powerful than Display PostScript (which, I think, came along a little later), and like the Berlin Project, [berlin-consortium.org] widgets could be run server-side. You'd send PostScript code (which could contain objects, threads, etc.) down a socket, and the server would execute it. Like eXene, [bell-labs.com] which runs under Concurrent ML, [bell-labs.com] you could, conceptually, at least, make an object in its own thread that was a widget. No callbacks - just a while (1) loop (well, a tail-recursvie function in eXene - CML is functional).
But Sun wanted to keep full control of NeWS to itself (just like with Java nowadays). It pissed off so many people in the community that everybody else got together behind X, knowing full well that X was much worse. As it was once explained to me by Andy van Dam, [brown.edu] the industry settled on a steam locomotive because Sun didn't want to share their bullet train.
NeWS of course died a slow and lingering death. For a while, it was included as an extension to Sun's Openwin X server. It was fun - you could scribble all over the root window with PostScript with a couple of lines of code. Eventually, I think Sun dropped NeWS entirely because no one used it.
An old story.....
Re:We couldn't really do this until now (Score:2)
Time I took another look then. Until now I've had to use some god-awful Motif porting tool whenever a GUI app I've written on Unix needs to run under Windows. Being able to concentrate on the underlying code rather than the GUI would make life a lot easier. And coding in GTK+ rather than Motif would be great
Chris
No X?...finally (Score:2)
A lovely summary of all that's wrong with X (Score:5)
Possible the greatest work of literature ever written about X. Guaranteed to entertain you for several minutes at least. I think he hangs around
Really, it's solid stuff. Think about it, instead of having a knee-jerk reaction.
w/m
It's not THAT bad (Score:3)
I'm not saying we should keep the problems as some kind of testament to the good features--I'm saying let's not throw out the baby with the bathwater.
--
X is no "millstone" (Score:4)
It's underway! (Score:3)
http://www.berlin-consortium.org/ [berlin-consortium.org]
Still unstable, but getting there!
Re:A Better Written article on Why X-Windows is Ba (Score:2)
<blockquote>For some perverse reason that's better left to the imagination, X insists on calling the program running on the remote machine "the client."</blockquote>
<P>To help the author out, the server is the machine or more appropriately, software, providing a service. The client is the software needing the services. Labelling machines as clients and servers is not necessarily the 'right thing' unless you're running a large VAX machine with dumb terminals. At any rate, it seems obvious, when you understand how X was designed to work, that the software package needs a number of things to be able to work. It needs a screen to display on, and a keyboard to get input from or maybe a light pen or plastic rodent thing. It needs a font management utility and basically anything else that would help it talk to the user.</P>
<P>Putting most or all of those 'services' into a package would make it the 'server' software. Thus, X is the server and the software package is the client.</P>
<P>If you still think this is strange, you're not allowing for the possibility of multiple layers of abstraction
<P>To give credit where credit is due, the author does manage to pull out a lot of features of X that were added, naturally, as after-thoughts because the hardware didn't exist yet. That said, the 'other answers' (ahem, Windows or BeOS) don't really excite me much, and I'd be much more impressed with a ground-up redesign of X.</P>
Re:A Better Written article on Why X-Windows is Ba (Score:2)
An interesting article, yes. Considering its a part of the Unix Haters Handbook [catalog.com], I had a slight smile before even starting to read it. The writer's inability to understand why clients and servers are called clients and servers on X was what made me laugh first.
To help the author out, the server is the machine or more appropriately, software, providing a service. The client is the software needing the services. Labelling machines as clients and servers is not necessarily the 'right thing' unless you're running a large VAX machine with dumb terminals. At any rate, it seems obvious, when you understand how X was designed to work, that the software package needs a number of things to be able to work. It needs a screen to display on, and a keyboard to get input from or maybe a light pen or plastic rodent thing. It needs a font management utility and basically anything else that would help it talk to the user.
Putting most or all of those 'services' into a package would make it the 'server' software. Thus, X is the server and the software package is the client.
If you still think this is strange, you're not allowing for the possibility of multiple layers of abstraction ... because it is in a different way that you should think of yourself, the user, as the client of the machine that holds all your software for you (the server). Being the client of a client of a server isn't that strange when you work in a manufacturing field, but for some reason, Comp. Sci. people have brain deficits in these ways and see normal human beings as stupid or silly.
To give credit where credit is due, the author does manage to pull out a lot of features of X that were added, naturally, as after-thoughts because the hardware didn't exist yet. That said, the 'other answers' (ahem, Windows or BeOS) don't really excite me much, and I'd be much more impressed with a ground-up redesign of X.
Re:bullcrap (Score:2)
X starts faster on my box, too, but Windows starts up faster than linux --> KDE.
Re:We couldn't really do this until now (Score:2)
Re:Someone obviously doesn't understand X ... (Score:2)
VNC is faster than X over a slow modem. I regularly use Xvnc and a remote VNX client, because it works better. It's faster, platform-independant, and I can reconnect without losing work. If my modem hangs up, a true remote-X session kills all of may apps. Crufty.
---- ----
STOP trying to make UNIX like Windows! (Score:2)
I don't want you telling me how my windows, menus, titlebars, and desktop are arranged or operated, thank you.
UNIX is about being able to get your hands dirty and being able to design an environment that suits you. That includes what my X desktop looks like -- or how it works.
Gnome pisses me off. KDE pisses me off. The various OEM's CDEs piss me off. olwm sucks. They pretty much are all an attempt to wield the same GUI/HCI stratification and conformity that the Microsoft family of products enforces. I don't like it much there, either (though with the greater tweakability of Win98+'s GUI, my desktops are almost unusable by anyone else besides me. That's too bad for them, who shouldn't be using my computer anyway.)
X is too deeply embedded in the Unix world to be easily dislodged
Look -- you either want a strict GUI standard, or you want choice. If it's GUI standardization you're after, having more than one windowing system is just an ineffectual attempt to try and uphold your open-source cred. What is gained by having (say) five different windowing systems that all look and work the same?
My point is, if you want an alternative to X, don't complain that everything doesn't look the same. If someone does replace X, it better actually BE different, not just be made by a different person.
Keith "you can have my peculiar fvwm2 config when you pull it from my cold dead fingertips" Tyler
--
Re:bullcrap (Score:2)
I think you've missed the point almost entirely. The GNOME and KDE folk are busy trying to gain some ground back from Windows on the usability front. This is a laudable effort to be sure but leaves all the original problems of X intact.
These aren't merely the things that it (perhaps rightly) doesn't address, like consistency of GUI. Authentication is still a prize pain. There is no mechanism for adding extensions dynamically making use of them in practice almost impossible.
Papering over a dubious API with n layers of toolkits and RAD tools is something that should be left to M$. Every time I hear yet another /. reader say something like: "that's the Unix way, it can't be improved upon - innovation, no thanks", I despair.
If a piece of software has had no real improvements in 5 years, then it's a sign that it needs a serious redesign. X is moribund: let it die in peace.
Amen (Score:2)
A Linux GUI needs consistency. Repeat this. While inconsistency under the guise of "choice" is a good way to scare off newbies who are not 1337, it is just a major headache for anybody who want to *quickly* *accomplish* *tasks* without becoming intimitely familiar with the idiosynchrasies of the various parts of the GUI. Look - I may not be a super unix guru, but I'm not the dullest person either. I am a programmer, but I am *also* a user. There are times I want to wear my user hat but *not* my programmer/hacker hat. Unlike in star wars, everything good should NOT need hacking on to work well.
Re:It's not THAT bad (Score:2)
There's nothing saying that you needn't have plugable window/widget managers for a new non-X system. And keep in mind, X has it's own widgets, which nobody uses.
For a look at a plugable, cross-platform UI, look at Swing [sun.com] from Sun for Java. (Sometimes refered to as the Java Foundation Classes, fortunately it's nicer than the Microsoft Foundation Classes where it seems they stole their name from...) It's got pluggable look-and-feels (so it's basically skinnable - although none of the current l&f's seem to be particularly skinnable user-wise). There are many things I don't like about X, and most of them have to do with the fact that the pluggable windows/widget managers happen to be done client-side when they really should be done on my server... (Try running a pic-based GTK+ theme, using a pic based Sawmill scheme, over a 56.6K modem connected at 46.6Kbs - then see if you like pic-based schemes...)
Arrrggghhh.... (Score:5)
In short, do the people who post "X sucks let get rid of it!" to threads like this have ANY feckin' clue?
"It's slow - lets get rid of it!!!":
Is it really slow? Seems fast enough to me, and I started out with X11R6 on Sparcstation 1's. Perhaps you are confusing X with XFree86?
Also, most other windowing systems have a huge advantage over X, ie they are called as library or system functions, whereas X was designed as a PROTOCOL for network transparency. This has an impact on speed but only slight, and if the X client and server are running on the same host there is no reason why they can't communicate via shared memory or some other X extension (see below). However X has something that these procedure call window systems don't: SEAMLESS network transparency. If I show you my desktop you have absolutely no way to tell which windows are running locally and which are running on various other machines round here.
"It's bloated! lets get rid of it!":
What is bloated exactly? X the protocol is a very lean protocol (though very chatty), designed with extensibility and low-latency connections in mind. ie if you can't do it with X, then go write an EXTENSION. Implementations are a different story, but again X != XFree86. (though XF4 is a different story - leaner and faster).
If the implementation you use is bloated go use a different one. Have a look at handhelds.org they're working on a small footprint X server for handhelds.
"Xlib/Xt suck!! let's get rid of X!":
Then don't use Xlib or Xt! Use Qt or GTK+.
"X sucks for fonts. let's get rid of it!":
Firstly, I bet you havn't read the X-Font-Deuglification HOWTO. Go to linuxdoc.org/HOWTO and read it and find out how to make all those sites like microsoft.com, dabs.com, etc, look right under netscape. Don't blame X cause it wasn't setup right! Blame your Vendor.
Secondly, X apparently won't handle anti-aliasing of fonts as it stands now. ("So let's get rid of it!"). HOWEVER do you know why anti-aliasing of fonts was invented? Cause in the mists of time, a lot of computers had terrible resolution screens. Anti-aliasing is a HACK to make fonts look better, nowadays we nearly all have at least 100dpi displays so you are better off setting X up CORRECTLY and getting clear fonts without anti-aliasing.
Thirdly, if there truly is a problem with font handling in X, well then let's do something about this small problem. Either implement an extension (Display Postscript springs to mind - most commercial Unices have this), or else fix X if needs be so that X11R7 has even better font handling.
In Summary:
X is one of the most amazing software concepts ever! It's like Unix, a timeless classic.
- If it can't do something, extend it!
- If it has a limitation, then get it fixed for the next major release of the X protocol!
but please stop the silly misinformed whinging and whineing.
Re:bullcrap (Score:2)
---- ----
Re:We couldn't really do this until now (Score:2)
Download GDK. Oh, you can't, because although it is a separate library it still forms an essential part of the GTK+ package. The fact that GTK+ hasn't been *successfully* ported to another system is proof of how many X-isms are in the GDK/GTK+ code. So my original comment is still valid, an Xlib emulation layer would still be required below GDK - or else a major rewrite of GDK.
Chris
Re:We couldn't really do this until now (Score:2)
That doesn't say anything about its dependence (or lack thereof) on Xlib. The fact is that Xlib, and therefore X windows, still draws every primitive you see on the screen, whether you're running KDE, Gnome, or anything else. Gdk, GTK, and Gnome add successive levels of abstraction to form higher-level primitives, but basic commands like "draw a line" or "shade this box" all go back to Xlib. Gdk strings a whole bunch of these together to make drawing buttons & such easier, and GTK itself strings a lot of Gdk commands together to make columned lists, scrolled windows, and the like. But if you can somehow pull all that off without using Xlib, drop me a line and I'll send you a cookie. Because it's not gonna happen.
Porting gdk to other operating systems is a matter of changing from the Xlib API to whatever API Windows uses to do things like "draw a line" or "shade this box". GTK+ is "not" built on X only in the sense that it runs on better platforms, and in saying this you're not conveying the whole truth - X is your only option if you're running Unix.
--
extensions (Score:2)
... and therin lies the problem. We've been doing this for the past 20 years, and it's starting to add up. Almost everything in X is an extension now, and the code required to support them is really adding up.
To X or not to X (Score:2)
--The knowledge that you are an idiot, is what distinguishes you from one.
Re:bullcrap (Score:2)
---- ----
Re:We couldn't really do this until now (Score:2)
Mmm
Chris
Re:Microkenel nice? Don't we remember Mach? (Score:2)
Remote Display can be put into something New! (Score:2)
So we should just keep working with it because it does remote display? No! Write a new standard that does remote display, better font support (like the article mentioned) and gets rid of tons of unneeded code.
There are a lot of things I'd love to see in a GUI system: You mentioned remote display, I'd love to see something that cuts down on the overhead (ever tried to do remote display over a modem?). Maybe some kind of two way communication where the remote system looks for the graphics binaries on the client and just sends data to update rather than data for the whole binary. (If the client has them). BTW: Windows can do remote display but it does suck, its even slower than X.
I'd also like to see some kind of standard widget set built into the server itself. (GTK would be fine with me). Its soooo incrediably annoying when I find programs that look really cool but don't run correctly (or not at all in my window manager).
I'd still like to see mulitple window managers to have different looks though. Some people need a Windows/Mac look. Personally I love BlackBox. Which as far as GUI's go I feel is pretty innovative.(and its really small. If anyone wanted to take the chalange in the article to put the GUI and kernel on a floppy, try BlackBox!)
Q3A isn't very slow using XF86 && glX either, now is it?)
I really hate to point this out but there was a benchmark [linuxgames.com] at Linux Games that shows Windows beating Linux in 3d accelaration with several different cards. Personally I think this has a lot to do with X.
Never knock on Death's door:
Before someone says anything more... (Score:2)
X support is a necessary evil, but that doesn't mean we should keep X as the primary desktop architecture.
Additionally, Berlin doesn't rely on any one kernel graphics architecture (or even there being one). I think right now they've got postscript, OpenGL and GGI display kits in various stages of completion. It's not really dependent on any one "Linux-specific" architecture.
Worst-case, on a commercial Unix with only an X server for graphics support, it can even display on that.
X - Why it's bad for programmers too. (Score:2)
No more worrying about re-draws, or where the window is on the screen in pixels.. just clean virtual co-ordinates, scaled by the windowing system at the display end. Buttons and input handled by the display and only important information sent back to the client as and when it it is needed, defined by the client's application when the object was created. Applications simple enough that in only a few lines of code an application can get a window displayed, scaled and controlled.
This is the dream of many a programmer. Instead, X is archaic, making the programmer at the application end do all the hard work, sending large pixel maps down the network every time a window is uncovered etc. all of which the display side of things should know how to control more efficiently anyway.
How many megabytes of code is written just to do the basic control of a simple window? Wouldn't it be better if all this is taken out of the application's hands, unless it asks to have that degree of control?
What's needed is a new windowing system which does all the hard work for the programmer and the application, is networked like X and gives an X api for backward compatibility.. but with the application being given it's own virtual display which is mostly managed for it by the windowing system.
This would solve three problems:
- Application complexity.
- Network bandwidth.
- Backward compatibility.
The downside would be that the display system on the computer displaying the data would have to be more capable..it would have to know how to redraw windows for it's clients, it would have to know how to scale, scroll and generally transform the windows and their contents. it would need a get deal more computing power and memory than X, in other words. The other side of the coin would be that the code would only be there once.. the applications would be FAR smaller and FAR less complex, helping with stability and speed, especially over a network.The only question is.. who is going to do the hard work and write such a system?
Re:OSS R&D (Score:5)
Eros:
http://www.eros-os.org/
MIT Exokernel Operating System
http://www.pdos.lcs.mit.edu/exo/
HURD(for its experiments in translators)
http://www.gnu.org/software/hurd/hurd.html
and a billion and one other OS projects. While many of these do not provide much, there ideas and ideals (and often bastards there of) are often incorporated into more frequently used OSs.
For innovation on the other fronts check out:
Freenet
http://freenet.sourceforge.net/
Berlin (for combining a lot of good ideas)
http://berlin.sourceforge.net/
GiNaC (algebraic extensions to C++)
http://www.ginac.de/
LyX (What you see is what you Mean editor)
http://www.lyx.org/
There is a ton of innovating software out there, all developed in open source. It's just you don't see giant leaps forward in computer science and gui interfacing. But then, you never do anyway! Innovation is a gradual process, and takes a LOT of time. But it is out there, you just have to start looking
A lot of times, people will look around on their desktop and say, "Gee, nothing here looks new." But that's 1) Because you've been sitting there i front of that desktop for who-knows-how-long(oh god, that's not 5.0 is it?!). When's the last time you installed something new? And 2) Because vendors try to plop down in front of you an interface that is intuitive. And what is intuitive in gui's? Almost always it is something you're already familiar with(almost nothing is truly intuitive). So you get the same-old same-old in front of you.
So get out there and look for something already! Find something you think is cool and work on it, or start working on your own idea. Even if it doesn't succeed, its ideas can probably be passed on to something that will.
Re:We couldn't really do this until now (Score:2)
True. This was probably a consequence of the Athena team's lack of experience in developing a networked system for windowing. A recent article I read (I regret taht I can't remember where) openly stated that some aspects of X were ill considered with hindsight. At the level of the X protocol it's probably to late in the day to do any major re-engineering. Or maybe not
Chris
Re:A lovely summary of all that's wrong with X (Score:2)
-Superb0wl
Um, why? (Score:2)
Moreover, if you want to do an embedded device and don't want the X overhead, port or implement your widget set in GGI or something and don't use X.
Re:We couldn't really do this until now (Score:2)
I have looked a lot of GTK code.. and yeah GDK is a little X centric.. but not really. I mean your GOING to have a hard time getting other ports working PERIOD.
Hello you are porting an entire graphics library to a totally new operating system, you have to account for all the nuances(read:BUGS!!!) and flaws and benefits of doing graphics rendering on that operating system
Its not pretty doing that in the Win32API which I believe accounts for much of the untidy unstable stuff. I like GTK a lot and I think that a key to success is getting something that CAN run very fast and have direct access to hardware.. Ive used the Gimp in windows and.. it works rather well if you ask me
Ive done minor work even and was not disappointed with the gimp..
The point is it is getting more stable every day and it is really a nice toolkit with a damn good design. So what if the middle layer is tied to one Platform that IMO is the point.
Tune it up take advantage of the OS's features so that once you got the middle layer working Viola the apps are ALL there and running beautiful and fast as ever. Is that not the point of the middle layer of the GDK?
Jeremy
If you think education is expensive, try ignornace
We couldn't really do this until now (Score:4)
There are still a number of Unix apps we use that are purely X-based. Look at some of the eye-candy apps that come with any default install of Linux.
GTK+ and KDE are becoming the new toolkits of choice for Unix GUI programmers. As we have to rely less and less on X-tied programs, we can get closer and closer to dumping this beast.
Any new system would probably need to be able to run an X emulation layer at some point. The cool thing about keeping X around this long is that we've learned a great deal about how to optimize gfx operations under Unix - we can use all of this information later to build ourselves a top-notch windowing system. Even X is running pretty fast right now. If we trimmed it down and got it running direct to an API on the system, we'd blow Win32 GUI stuff away.
bullcrap (Score:4)
I personally don't see that as "worse." I see that as giving users the choice of desktop managers. Motif is beautiful, and i can put up with Gnome. I used to run KDE and it was tolerable. The thing is, at the root, X is X and all your binaries will run on any of them. The way i look at it, you even GET to pick what your desktop looks like.
Basically, the impression i got from from this article is that ol' Monty wants to run Windows 95 on Unix! he wants a standard DE and i have to stand up and disagree. And if you still don't like X, run lynx and vi. that's the beauty of the *nixes. You don't HAVE to do anything you don't want to. That's why i like it, and that's why i use it.
-Superb0wl
Look at our options... (Score:4)
There is a Display Ghostscript [aist-nara.ac.jp] project, and many people have heard about the Berlin [berlin-consortium.org] project. I've watched Berlin a bit, and I'm not sure it's going in a direction I like (they seem to only want one widget toolkit, which is both good and bad).
Obviously, for any of these projects to take off as projects independent of X (right now, they are often used as a layer on top of X), framebuffer support in the Linux kernel must be improved. Therefore, before we go off trying to re-write the world, a good foundation of security and stability must be built into the kernel.
I know many people don't like the idea of having graphics in the kernel, though this can be worked around by having modules that merely open a pathway to the video registers and memory and grant you safe access to the hardware (i.e., no more suid-root graphics systems).
Blah, I'm beginning to ramble (plus I really need to get some work done...)
--
Ski-U-Mah!
Stop the MPAA [opendvd.org]
Re:We Have X Because Sun Wanted to Keep Da Goodies (Score:3)
While some of the political issues you mentioned were factors in the community's decision to go with X, there were technical issues as well. It's been so long that I don't remember all of them, but some that come to mind are
There were plenty of great features in NeWS, and some of them are enjoying a comeback today. But it's worth remembering that NeWS wasn't a clear-cut technical win. X carried the day for a variety of reasons.
Re:He said it...Mac OSX (Score:2)
But the real problem is not that we have themes that look as good as Aqua, and may in fact not have some of Aqua's shortcomings. The real gap is in the rendering. If we aim for Aqua, and neglect to also aim to duplicate Quartz, we lose.
Quartz is the real power for OS-X. It generates the OpenGL, QT and Postscript display. Aqua is just a theme, like Afterstep, Gnome, K. It's useability and power come from Quartz, X Window's real competitor.
Tom
Re:We couldn't really do this until now (Score:2)
Probably easier from the point of view of Qt than GTK+, as the former is already very portable. I haven't downloaded a CVS version of GTK+ lately but I know they are aiming to improve portability so it could soon be true for GTK+ as well as Qt.
One thing I always liked about GTK+ was that it avoided the Xt Intrinsics. Xt always seemed to be a dubious halfway house between a GUI toolkit and Xlib itself - adding little in the way of flexibility (apart from variable argument widget creation routines), and much in the way of bloat.
Perhaps it's just the former XView programmer in me starting to shine through
Chris
Re:Yes (Score:2)
Have you even seen Mandrake? I'll be the first to admit that Linux is not for everyone, but one of the great advantages of Linux over MS is you can get a distribution tailored to your needs, and then you can tailor more precisely to your needs.
You obviously need a good visual user interface out of the box, with easy installation. So, try Mandrake. Not only does it do all the crap you want (like automounting CD's) and I don't know what the heck you're talking about "installing and icon quickly is not done". What the hell does that even mean?
BTW, if your bank had any brains at all they'd have web based banking from home on a secure server so ANYBODY can use it. That's how my bank is, and I jump back and forth between Windows, Linux, and Irix - they did such a good job it looks and works the same on all.
That is the future.
I'm sorry, I shouldn't have even answered this uninformed troll. My apologies to everyone else.
----------
Re:X fonts (Score:2)
Exactly; as I said, the X font subsystem simply does not meet the needs of these kinds of applications.
the X litany (Score:5)
Accept any substitute.
If it's broke, don't fix it.
If it ain't broke, fix it.
Form follows malfunction.
The Cutting Edge of Obsolescence.
The trailing edge of software technology.
Armageddon never looked so good.
Japan's secret weapon.
You'll envy the dead.
Making the world safe for competing window systems.
Let it get in YOUR way.
The problem for your problem.
If it starts working, we'll fix it. Pronto.
It could be worse, but it'll take time.
Simplicity made complex.
The greatest productivity aid since typhoid.
Flakey and built to stay that way.
Re:No, thanks to Moore's law, X will live forever! (Score:2)
Checke this out
A linux distro [linux-embedded.com] that is about 8 MB. It includes X and networking capabilities.
If this is bloat then all the software in the world is bloated. And windows is just obese.
Handhelds.org has it on on iPaq (Score:5)
Re:I Agree (Score:2)
Sure... If you cannot handle configureing your WM (Score:2)
Re:Uhh. . .pass the crack pipe this way. . . (Score:3)
The X-Windows Disaster [catalog.com]
What happens to XCalc when you resize it too many times? [catalog.com]
Official Notice, Post Immediately! [catalog.com]
The ICCCM Sucks [catalog.com]
jojo on UI [catalog.com]
Motif Angst Page [catalog.com]
XBugTool Horror Stories [catalog.com]
-Don
Not Quite (Score:3)
XFree86 has already addressed the Bad Thing in two different ways - with DGA (much faster) and GLX. GLX is the future of X display - clients draw into an OpenGL accelerated window (woo hoo!).
Who wants to start porting gdk to GLX?
Re:Not Quite (Score:2)
Try again. SunRays (nee Corona nee NewT) redirect the whole framebuffer across the network. Think VNC in hardware.
You want Windows then. (Score:3)
Okay, X may have a few problems. But I happen to like the fact that interfaces can be different. I like the choice of different toolkits. What would be very cool is if some of these toolkits played nice together.
Maybe if there was some kind of keybinding database that these toolkits use by default, so that paste is always ctrl-v, for example, whichever toolkit and program you use. That would eliminate a lot of the problems. Surely this wouldn't be *that* hard to implement. Anyone like to comment?
No alternative (Score:4)
And BTW, X has plenty of problems but user interface inconsistency is not one of them. X is low-level and user interface standards are clearly not in its domain. The fact that, say, a middle mouse click can do anything at all in an X application is not a drawback of X -- it's a side effect of the UNIX world being fragmented, idiosyncratic, and, yes, free to do whatever one wants.
Kaa
It's the approach and language, not X11. (Score:3)
Until people move to languages and methodologies that emphasize runtime safety, runtime type information, and component based programming, these problems aren't going to get fixed. In fact, that's the real point of the UNIX Hater's Handbook.
Of course, people try to use dynamic loading in XFree86, the Linux kernel, and Microsoft Software. In fact, MS COM probably represents the best attempt at doing this kind of thing, but without language support, it is ultimately too complex to be really useful. Plan 9 has a different take on modular software composition, but they have not demonstrated that it scales (Plan 9 is pretty simplistic, IMO), and it pays for the use of C in a lot of context switches.
As long as the mainstream of free software writes in C/C++, this simply isn't going to change. Any new attempt is just going to get as bloated and complex as the previous systems when it hits the real world.
But as far as 1970's style, C/C++ systems go, X11/Linux is the best there is, and I'll continue using it until I see anything better come along.
Re:bullcrap (Score:2)
Re:It's not THAT bad (Score:2)
I agree. I find X quite useful, and am adamantly opposed to throwing it out.
My biggest fear is that if we do throw X out, we're going to end up with a Linux-only in-kernel graphics subsystem, unportable and incompatible with everything. Let's not also forget we'd also throw out a whole hell of a lot of existing code.
If folks are so keen on reinventing the wheel, take a lesson from Transmeta. Invent a lightweight windowing system that can "morph" itself into different flavors. Have it be able to speak the X protocol through a heavyweight plugin if need be. Maybe it could speak other protocols for different platforms, too.
I Agree (Score:2)
To some Extent, GNOME and KDE are helping to solve the problem, but IMO it's the wrong approach.
We really need a more sensible GUI system; getting an app up and running shouldn't be this difficult; sadly, all the futzing with Xresources and stuff is all too real.
One thing I think a replacement GUI toolkit needs is a standard window manager with standard widgets. This is probably the biggest barrier to most people ever accepting Unix as their desktop (even technical people where I work dislike X, because every program looks, feels, and works differently.)
Furthermore, a revised GUI system needs to recognize that today's clients are high-powered machines, not dumb monitor+keyboard+terminals. It need to let the client do most of the processing. It also needs to have working functionality for basic concepts like the clipboard (cutting and pasting between X apps is just silly....which cut buffer do I use?!?)
I hope Berlin truly improves upon the ideas presented in MSWindows/Aqua to deliver a new GUI system that is usable. Making any concessions to X for (compatibility) would be such a disappointment.
The need for _EVOLUTION_ (Score:3)
A good adjustment will be somthing provided that has what we all love:
a) Remote display capabilities
b) The guarantee that an xterm on my system will behave the same as an xterm on my boyfriend's system when I'm trying to get something done @ his place.
c) Configurability
d) *Thats all I could think of right now*.
I'm quite disappointed that we didn't take this opportunity, when someone has pointed out that this aspect of *nix is dying, to talk about the new, the more innovative and skillfull approach to creating a GUI in general. Now that we have better monitors, more memory, more developers getting excited about contributing to their community...more of everything... Since we couldn't do that, after such a simple article, I wonder what this means....?
To kill X doesn't mean we get rid of the good stuff, it simply means we improve.
Nuff Respec'
DeICQLady
7D3 CPE
What a dimwit! (Score:3)
"Well, I hate to burst your bubble, folks: Linux (and even the FreeBSD to a lesser extent) is just as overweight as most other operating systems these days. The kernel alone (when compiled), can take up anywhere from 700K to 1.2MB, depending on the configuration and whether drivers are compiled in. The GNU C library is likewise huge, nearly twice the size of the comparable BSD C library."
1) 700K - 1.2MB is "just as overweight as most other operating systems"? I challenge ANYONE to run Windows95/98/NT/2K, any non-free Unix or MacOS with less. Yeah "most of that is DLLs/Systemware"--so? If the OS requires it it's part of the OS.
2) Bloat IS bad in a piece of software--but libraries are a whole different beast. It isn't a "piece of software"--it's a library of software that's largely non-interdependent. Larger libraries generally means more available subroutines--but the subs don't call themselves so the bloat isn't a maintenance nightmare.
--
Re:bullcrap (Score:5)
- Aqua doesn't have the flexibility, user base and developer base of X. (huh?)
- It's the only thing that runs on Linux. I've no choice. ("I can't install them on my Linux and FreeBSD boxes at home.")
- No one has managed to do better (on Unix, that is) ("Sure, there are a bunch of things that could be improved on X but I don't see any other initiatives out there that is even remotely close to accomplish what X has done. ")
Wonderfully convincing.
He said it...Mac OSX (Score:3)
Once upon a time the world took the GUI que from Apple Computer. Look what it did for M$. Give a little time and the Unix community can do the same with OS X. Whatever Apple does will be adaptable and maybe will give the community a few hints on what to do next.
To the statement that no original GUI work has really been done in X-Windows, I say this...re-inventing the wheel is great, but why not refine it to make it do what you want? Building iff of other people's ideas id how we humans got here, so why snub people for it.
Learning curve (Score:3)
The cliff might be useful in keeping newbies away but if you *want* to attract normal users you have to make that cliff into a decent slope.
OSS R&D (Score:4)
Molog
So Linus, what are we doing tonight?
No (Score:4)
I would never go from X to a hyper-accelerated GUI which only provides local display, and have to use third-party programs to display remotely! Have you ever tried to do serious work over VNC or PCAnywhere? (Hint: It's _dog_ slow.) And some of us still have to use slow lines from time to time, thankyouverymuch.
(Q3A isn't very slow using XF86 && glX either, now is it?)
If X sucks... let's make something better (Score:4)
Sure, it would be a large project, but if you want something done right, you gotta do it yourself. So, let's organize a group to start working on something like this. Maybe even have sub-groups working to port X toolkits over to our new system. (I think this would be possible) Then anyone who wanted to could port their applications over to this, without having to worry about much at all.
Is anyone interested in this? Let's start a project, and do this. The time is ripe for something like this. This is your chance to make a big difference in the Linux or Opensource community. I think I may even register a sourceforge project. If anyone's interested, write me email.
Challenge Accepted! (Score:3)
How could I perform this feat? Easy, really:
- Exclude ALL non-essential kernel options
- Compile in all essential options in, so module code isn't needed
- Recompile X with no debugging, and -O2 to minimize space. Shred the symbol tables, too. And only compile in the stuff needed by GGI
- Use GGI and EvStack for all graphics, and use the GGI X server. Better still, dump X and use Berlin.
- There are some -great- lightweight window managers out there, now. A WM doesn't really need to take a gazillion bytes.
- A browser is easy. Again, plenty of lightweight ones around. That really isn't any big deal.
- Shells! (Ooops, no, that's Pernese.) Shells are no big deal. You're talking about a 3-line program, which reads a line, then sends that to system(). Wow, this is going to take space.
Then, all you need to is remove all symbol tables, dynamically link ANY code used more than once, and statically link everything else.Oh, and minimise the number of directories. Those just waste space. You don't need them, except for organising thoughts. Also use a minimal filing system - inefficiencies there chew up disk space like nothing else. (You could stuff a 20 meg application in the dead space of most HD's.)
Last, if the gap is minimal, use 1-sector/track floppies. Then you don't have the inter-sector gap, which should give you about 1-2K per track extra.
Re:We couldn't really do this until now (Score:3)
Nick
invalid comparitions. (Score:5)
Sure, QNX is lighter then linux. It wasn't designed to be like linux either. Linux does more for the programer then QNX. Now for embedded systems (which QNX wants to play) this is bad, but for a general purpose OS, or server OS this is good.
The parts of X that make it slow are also the parts I use day to day. The machine I'm typing on now has a slow CPU (68030 if I remember right), but I don't care because the programing I'm typing into is running on a 300mhz sparc (maybe faster I don't know) Desptie sharing the sparc 10 other users all my programs run fast enough, and the boss finds one good machine to be cheeper then 10 cheaper not as good machines. I like not having a fan on my desk.
Perhaps we should start blasting telnet for being slower then sitting at the console.
I've only twice seen situations where X was slow. The first was when running my sun3, which has a slow X because of the slow framebuffer. The other was when running across a 14.4 dial-up. (Needs to further explinnation, though it could be speeded up, graphcis still take a lot of time to transfer at that speed)
Bloat is not a valid arguement, at least not where you site Fred Brooks. For thsoe who don't remember, Fred Brooks was the leader of a project that turned out something an order of magnatude more bloated then anything else. I know folks today who swear at unix because OS/390 is so much better. (I have no expirence with OS/390, but I know it is a direct decendant of what Fred Brooks did) The point, bloat isn't to be aimed for, but you need to balance features with bloat. Each time you add a feature you add a few lines of code. Sometimes it isn't worth it, and sometimes you should step back and find a better way, but in the end you cannot get a full functioned program without many lines of code.
Bloat is not a problem if the programed is well designed. Each person knows their part, and how it fits in with the whole. I don't know what George and Suzie are doing, but when they completely re-write their part of the code from scratch (to make it better) I don't care because in the well designed program it doesn't affect me.
Re:A lovely summary of all that's wrong with X (Score:3)
If you don't WANT normal users to be able to immediately perform basic operations, they WHY do we evangelize *nix as the solution to all problems?! If we DON'T want Linux on the desktop, then let's stop pushing it. If we DO, then let's adapt ourselves TO the user. We can't just say "Hey, Linux is the best desktop OS on earth! But, by the way, we refuse to bend in your direction to accomodate you. You have to behave the way we say."
It's just ridiculous. New users shouldn't have to expect to have to do things over and over again, before actually seeing results. If we want them to, then let's stop preaching to *normal* computer users because that is obviously then not our audience.
extensions don't kill people, legacy kills people (Score:4)
You're right. ~14 years, modulo some preliminary work. Sorry.
The problem is not the X protocol, nor its extensibility.
It's the extensions.
Most of the core X extensions and related protocols (the ICCCM stuff is really the worst offender by far, followed by the font stuff) are incredibly poorly designed, and not themselves particularly extensible.
Try discarding all the existing extensions and then rewriting them properly, on top of the existing X protocol. Assuming you did it right (and with 14 years of experience to refer to, it'll be easier), you'll end up with a very nice, clean, extensible system.
The only problem is, at that point, you either have to take all the old extensions back, or you may as well not bother calling it X, because it won't be compatible with anything.
Otherwise, you may as well just redo the X protocol a bit to fix the couple (minor) deficiencies it has... and... hrm... if you're going to be doing that, why not just scrap it completely and redesign from the ground up anyway?
It should, of course, be extensible.
Extensibility is a very good thing, but, like customizability, if it has to be used too much, then there's something fundamentally wrong with your original design (in this case, primarily the core extensions).
Re:He said it...Mac OSX (Score:4)
As I understand it, PS and PDF are very different beasts when it comes to licencing from Adobe. I do not know the details, but I believe it is quite possible to write a proper PDF display system without any help or fees from Adobe. I believe this goes for the name "PDF", as well, which anyone can use, whereas "PostScript" requires a licence from Adobe if you wish to use the name.
As far as OpenGL, there are no licencing issues there that haven't already been dealt with in the UNIX world. Just call it something other than OpenGL, like hmm... for example, MesaGL. You get the idea.
Once Apple releases some more documentation on their Display PDF system, it may become practical to re-engineer it. Apple may, in fact, support it in some way. I wouldn't expect them to give away ALL the crown jewels, but it WOULD be in their best interest if the rest of the world used system at least half-way to Aqua to make it fairly easy to port between the two systems.
Re:A lovely summary of all that's wrong with X (Score:5)
Nobody's blaming X itself for the mistakes of its designers. I'm blaming ignorant hypsters like yourself for all the insincere uninformed cheerleading that led to the widespread adoption of X11, in spite of all of its severe technical problems. Stop being such an appologist for bad design and poor execution.
I tried to make constructive criticism in that chapter, comparing it to NeWS's downloadable code and extensible protocols. NeWS was certainly not perfect, but X11 had a lot to learn from it, and people like you still refuse to open your eyes to that fact.
The software we're using today has evolved into a model much closer to NeWS than X11. Web servers are like NeWS clients (the program that runs an application remotely). The web browser is like the NeWS server (the program running on the user's machine), that controls the display. The web server can download html and javascript to the browser, that interacts locally with the user, much in the same way that NeWS clients download PostScript code to the NeWS server.
So before you tell me that NeWS's model of downloadable extensibility sucks and nobody uses it, you should do some research and check out that new craze that everybody's been talking about recently, called the world wide web. If you have never heard of the web, and can't find a book about it in the library or your local book store, just search for "www" on yahoo.
-Don
A Better Written article on Why X-Windows is Bad (Score:5)
Anyone who reads this article may be inclined to yell FUD, FUD, FUD as has been written in comments to this article or MSFT supporter but not in this case.
Don Box is a migrant user interface designer and graphics programmer. Don received a BSCS degree from the University of Maryland while working as a researcher at the Human Computer Interaction Lab. Don has worked at UniPress Software, Sun Microsystems, the Turing Institute, Carnegie Mellon University, Kaleida Labs, and Interval Research. He ported SimCity to NeWS and X11 for DUX Software.
X-Windows has serious problems that are evident to anyone who has ever done any serious investigation but since it's *nix most people put up with it's clunkiness. Similar to how an alternative to GNU getopt(3c) has not been written yet, because getopt works well enough (or so people think).
--
My crappy response (Score:3)
He goes on to complain about window managers being broken away from X. COME ON! Modularizing code into small components is only a good thing. God knows we don't want to end up with a windowing system that is basically unchanged (except for the applications and the window chrome) since 1984.
I don't agree with ALL the criticism, but X must DIE - soon. A new graphics architecture (with a legacy plugin for handling old school X apps) is needed.
Gee Wiz graphics after he mentions FVWM in the paragraph before???? I think Apple's focus groups must have included my grandmother, chimps and those people who operate their computer by blowing into a straw. YUK! Every "serious" computer user I know hates the MacOS. Granted: They don't attempt to appeal to serious users.
I do think he's right. Big Linux Vendors: create a project to make the next generation windowing system with all those nifty features. Don't forget to invite the BSD folks.
to replace X, one must have: (Score:3)
If we really want X replaced, we have to deliver something a lot better than X has now in order to justify the trouble to developers and users to make the switch. Simply being "just as good" won't cut it. Perhaps Berlin will be worthy when it's finished, but we're not quite there yet.
Check out Microwindows (Score:3)
This is being developed for the embedded market. OTOH it also has development environments running under X. Therefore anyone who wants can develop real applications to microwindows, and let people run it on whatever graphical system they want...
Cheers,
Ben
Re:It IS that bad... (Score:4)
The componentization of the window manager was in the abstract a good idea, but the execution (ICCCM) was an abortion. You say that X wouldn't have survived as long without it. But if X had died because it was stuck with one bad window manager, then we wouldn't be in this dead end prediciment that we're stuck with today!
X should have been designed to self destruct. Like shareware that expires after a few months. I wish somebody would patent X11, and sue everyone who tries to use it. Where are SGI's lawyers when we need them?
The ICCCM window manager protocol is like an emergency tracheotomy performed with a rusty crowbar, that's been inflamed and oozing infected pus for the last decade. ICCCM is the scab on a stigmata that will never heal. But people keep trying to fix the problem by enlarging the hole in the neck and sticking tubes down it! Isn't it about time to just cut the head off and bury the body?
There's nothing clean nor extensible about the X protocol, and to make such a statement ignores reality and history, and promulgates bad taste. NeWS had an truly extensible protocol that allowed clients to dynamically download code to the server at run time. X extensions just don't cut it. You could just as well call Perl a clean simple well designed language with an easy to learn syntax, if you're going to distort the facts so grossly.
-Don
Re:It's not THAT bad (Score:3)
Other GUI's have remote display. I've heard that the OS X interface is capable of remote display on any device that can display PDF; corrections solicited. (Now, does this mean I need to upgrade my laser printer to one that can support a ssh client?)
Who says "size matters?" (Score:5)
X is a protocol that allows a number of different workstations to interoperate. That RS/6000 xterm will react to my window manager in the same way that a local xterm will. No surprises.
A program that uses the X libraries and the Intrinsics (Xt) toolkit can usually be recompiled on any other system with X Window support, and run as is. If the program uses GNOME, KDE, Motif, or any other set of libraries that run on top of X, the only requirement is that those libraries must also be installed. But the program runs the same on all of those systems where those libraries are installed.
Is X a large program? Certainly. It could have been designed differently and work well on a single architecture. A window manager could have been integrated into it. Hell, add a file manager with tree-views. Microsoft took this tack, but if you write a program using the Windows libraries, they will only work on Intel boxes (or maybe Alphas, prior to Windows 2000).
X offers configurability. Not generally very easy, but it is there. Don't like the fact that your window manager binds CTRL-F4 to "Window Close?" Change the parameters and restart your window manager. How easy is that on Windows?
X allows you to separate the fact that you wish to draw a circle from the actual act of rendering that circle. Send a graphics request to a display, and the display will figure out how to draw that circle. It doesn't matter that the program may be running on a different machine than where the display is. It works.
If you are running NT, try opening a DOS command prompt on your neighbor's box, with the commands appearing on your box. You can probably purchase a special utility to do this (and install it on both boxes), but that capability is not built into Windows. On X, all you have to do is to be able to authorize myself via the network (rlogin, rstart, ssh, xauth). Voila!
X reigns supreme when you wish to work on multiple computers, but don't want to hop around from keyboard to keyboard. It was developed for such a collaborative environment, and is machine neutral (works on Intel, Motorola, Alpha, HP, and many other chip sets), network neutral (it works with DECNet, TCP/IP, and Unix sockets), workstation neutral (just need an X server for the computer(s) you wish to work on), and operating system neutral (you can get X servers for Unix, Linux, Windows, Macintosh, and a lot more).
Do you wish for better graphics support in X? Well, if you have an anti-aliasing library that will render fonts better IN A MACHINE-NEUTRAL WAY, then donate code to the Open Group to perform the function and everybody wins! Bitstream offered their Speedo font technology for font scaling. Others have donated other technologies. XFree86 has done wonders with having it work on microcomputers.
It's open source. Add what you think is missing. Yes. This will make it even bigger, of course.
Smaller isn't always better. I can remove X Window from my Linux system, and have a character-oriented prompt. Doesn't take up much disk or memory space as X, but it doesn't offer me as much flexibility.
(void) lar3ry();
--
X isn't all bad. (Score:5)
If there ever is a replacement for X, I hope it's done by people with the engineering know-how as those who made X. Look at it. It's survived and remained useful for around 20 years. It's been ported to platforms the original programmers never even imagined (handhelds, Windows, you name it).
For any system to last that long (X, TCP/IP, ethernet) it has to have been well designed and designed to be used in cases the original designers might not have imagined.
That's my rant... I like X. It works very well for me.
Re:We couldn't really do this until now (Score:3)
Ummm
If we trimmed it down and got it running direct to an API on the system, we'd blow Win32 GUI stuff away
Xlib is a very lean and fast library, I think it would be hard to improve on it in userland. If the alternative you're suggesting is an in kernel GUI, then think again. This is why stability in Windows NT suffered during the transition from NT 3.51 to 4 - the clean distinction between kernel and GUI was broken in the name of efficiency. This allowed calls direct to the hardware, and buggered NT's stability.
Chris
Re:He said it...Mac OSX (Score:4)
The trouble is that the MacOS X GUI relies on technology licensed from a number of sources: OpenGL from SGI and Display PostScript from Adobe. Open sourced alternatives are available, although GNUStep's Display GhostScript is a shadow of what it would need to be to provide a viable alternative to it's commercial brethren.
So the question is, given that Linux and the *BSD's have the basis of a GUI as good as Aqua in the form of X, where should development be expended? Should it go on creating a semi-clone of OpenSTEP/Aqua in the form of GNUStep, or on providing alternatives in X itself. I think we would be better served by XFree86 developers pursuing anti-aliased fonts, etc. in the existing X framework - the game of catch-up is far easier here than in trying to reverse engineer the Aqua GUI to a greater or lesser extent.
(And does anyone know if Aqua is network transparent like X? I've never used NeXTSTEP or OpenSTEP so I'd be keen to know).
Chris
Re:It IS that bad... (Score:3)
X was developed in the MIT environment, which at the time consisted of big servers, pathetically underpowered workstations (no local storage, <=8 bits per pixel), and 10Mbit Ethernet everywhere. Thus, the architecture of X presumes that most of the computing power resides on the central servers, and the servers and clients will be able to communicate at high speed.
In the modern Internet, with massively overloaded servers, workstations capable of running Quake and Unreal Tournament, and dial-up modem connections, each of these assumptions turns out to be exactly wrong.
(You could even view the Web as an attempt to address the same problem -- distributed computing with a graphical interface -- and one far better adapted to existing environment than X.)
Widget sets should reside on the client side (I'm using "client" and "server" in the conventional sense here, not the inverted X usage). The application on the server shouldn't have to say, "draw a rectangle here with these dimensions, with this text here with these fonts, etc...", followed by events and drawing instrucitons traversing the net as the user drags the mouse. It should just say, "here's the menu description, don't bother me again until the user chooses something from it."
If that approach had been adpoted, we wouldn't have distinct Motif apps and KDE apps and GNOME apps. We'd just have X apps, rendered as Motif or KDE or GNOME (or Win32 or Aqua or AfterStep or...), depending on how your workstation is configured. And we'd be deploying these apps across the (low-bandwidth) Internet, not just across (high-bandwidth) LANs.
"I've never seen anything fill a vacuum so quickly and still suck."
--Rob Pike on X
Can I have a pint of what he's drinking. (Score:3)
Seriously, it seems that he doesn't understand the underlying flexibility of X - that the display and application can be in separate locations.
This is something that the Windows world lacks. So PC-Anywhere et al allow remote control, but these are limited to one simultaneous controlling user. (Ever tried to remotely connect to a NT box to run some admin utility that can only be controlled from the console, only to find that someone else is controlling some other application at the same time).
A window manager is a matter of choice - you don't even need one if only running one application under X. I currently run fvwm2, mainly to the small footprint and a cronic lack of disk space. I could be running sawmill/sawfish this weekend (he didn't mention that one), or maybe try the latest CVS snapshot of enlightenment.
His other main criticism was on the size of the code. The QNX installation he quoted is a very basic environment, I believe only using basic VESA modes with no acceleration. Yes it fits on a floppy, but then I ran Gem/DOS 3.2 from a single 360K floppy 11 years ago. X (and the Linux kernel itself) is certainly more complex in nature than the QNX demo software (which is only a demo after all, and not a fully featured OS).
Oh, and he got the name wrong - there's no such thing as X Windows. I have an instant distrust of journalists who get the name of software wrong - it never bodes well on the content of their articles.
Don't criticise what you can't understand!
Alternatives (Score:3)
D11 [sgi.com] - Proposed replacement for X11 (from 1995), but I don't think it made it past the idea/proposal stage.
Berlin [berlin-consortium.org] - Under development, "Latest News: June 12, 2000: 0.2 is out".
See also: Berlin page at Sourceforge [sourceforge.net]
It IS that bad... (Score:5)
I would like to note that I don't agree with some of the criticisms in the article -- for example, I think the componentization of the Window manager and various other items is generally a Good Thing. X wouldn't have survived as long as it has if something like the 80s-era window managers were part of the standard server.
While X has a lot of good points (network transparency, platform independence, flexibility in window management), those doesn't make up for its defects. It IS possible to design systems with these characteristics that don't have the downsides that X does.
The underlying X protocol is incredibly clean and extensible, but there are now so many (effectively mandatory) extensions that the code required to support them makes the X server software absolutely huge. ICCCM is a nightmare in its own right.
Moreover, many of these extensions/auxiliary protocols (a prime example would be the X font system) were not designed in the same forward-looking manner as the basic X protocol, meaning that it is necessary to replace, rather than enhance them. However, since existing software still relies on the old extensions, it's not possible to drop them -- you end up with even more redundant code bloat.
X doesn't really give you any choice with regard to widget toolkits, either. You're stuck with the one the app was compiled with, or, more often, coded soley against.
With an architecture like Berlin (or a number of others), it's possible replace the widget set in any or all all apps with the one of your choice -- on the fly.
There's also the problem that EVERY primitive operation in X requires the request to be marshalled/demarshalled across process boundaries.
The address space separation (and consequent easy network transparency) between client and server is not a bad thing, IMO, as it helps stability, but I belive the X designers made a fundamental mistake when they cut the client/server boundary at such a low level.
Having to do this sort of low-level chatting across process boundaries really hurts performance.
Architectures like Berlin maintain the client/server separation, but cut down on the performance hit by communicating at a significanty higher level of abstraction. This means a decently-written Berlin app, even if using a chunky protocol like IIOP, would create significantly less IPC traffic (in bytes) than the equivalent X app.
Of course X has DGA. X has shared memory. Unfortunately, those only work locally. If you rely on them, you just shot network transparency. Whoops.
And, there's another problem: instead of writing graphics drivers independent of any one application class or GUI architecture (which means basic kernel support), everyone's been writing drivers directly for the X server. (Thanks, XFree86!)
This means that to even reach a usable stage, every non-X project has to rewrite their own driver suite from scratch (as a rule, X drivers make too many assumptions about X for the code to be readily reusable for other things).
Although we have fbcon now, fbcon is pretty much unaccelerated, and doesn't have that broad a range of hardware coverage. Berlin is still mostly tested on top of X as a result.
If you have to keep X around to run Berlin, or face severely reduced hardware support, then what's the point?
X has been repeatedly marginalizing other graphical efforts this same way. (Who here has heard of Y Windows, for example? How many of you know someone who uses it? What hardware does it support?)
Thankfully, due to GGI, Berlin can run on fbcon and KGI -- if KGI ever becomes more widespread, Berlin might finally be able to break free of X.
It's time we stopped relying on the X server for everything graphical.
It's too late to throw out the bathwater, baby or no. It's outgrown the bathtub and eaten your dog.
It's time to break out the napalm...
Re:bullcrap (Score:3)
I use motif, because I'm a minimalist. Its simple, elegant, agile, and functional without all the doodads. In other words, its very fast and its speed is the eye candy I see! I use Motif on 486 boxen with minimal RAM, where its speed still shines. Its simplicity is purely beautiful!