XFree86 10 Years Old 441
ChazeFroy writes "XFree86 is now 10 years old. To quote from the page, 'What makes this particularly eventful is that it is fully backwards compatible; this is a true testament to the spirit of the original X protocol of which XFree86 is its finest implementation.'" Ten years and
still binary compatible. Very cool.
suggested X changes (Score:2, Insightful)
Seems a bit... odd (Score:2, Insightful)
color depth (Score:1, Insightful)
binary compatibility (Score:0, Insightful)
Re:Seems a bit... odd (Score:2, Insightful)
Lets party (Score:0, Insightful)
Don`t get me wrong, having remote x terminals is a realy boutifull thing, but *not* at the cost of a single machine desktop speed, I am back getting the leaked BeOS dano to work to celebrate this birthday
interesting (Score:0, Insightful)
But if XFree can auto-detect now, perhaps I should give it another try...
Re:Seems a bit... odd (Score:5, Insightful)
And exactly that is the genius of X (in contrast with most other windowing systems that are based on API's). Therefore, it is easy to get network transparency, and backwards compatability does not confront you with the headaches that API binary compatability causes.
Maintaining compatability is just as simple (OK a bit less since it is a complex protocol, but the extention mechanism was very clever) as backwards compatability for ftp,nntp,dns etc.
Re:Much more importantly (Score:1, Insightful)
Yay for the BSD license (Score:1, Insightful)
Re:suggested X changes (Score:3, Insightful)
X is a network protocol. If you look at network protocol stacks you see layered design patterns everywhere. That's the beauty of X. It is confined to a layer, and performs that layer service extremely well. I know it has drawbacks and inefficiencies, but it is the best protocol so far.
Including widgets and component architectures is stepping on the upper layer. It violates layer independency, and introduces unneeded complexity. X is a large enough behemoth as it is.
Leave widgets separate, as they are now. It works, and it is elegant.
BTW, this is also why I disagree with the various alternatives to X that discard the network protocol, and go for direct hardware communication. It is a decision that mixes the graphical communication layer with the layer beneath it -- you gain some speed and loose lots of flexibility.
Binary compatible? (Score:2, Insightful)
Go ahead, grab XF86-2.1-bin.tar.gz [xfree86.org] and see if any of the binaries run
xload: Linux/i386 demand-paged executable ZMAGIC), stripped
-adnans
Re:binary compatibility (Score:2, Insightful)
but XFree86 retains compatibility for 10 years and it is "impressive"?
Apples and oranges..
DOS is a 16-bit operating system for 16-bit processors,
the argument against DOS compatibility was that
to do this, Windows had to include a lot of 16-bit
code, instead of being fully 32-bit.
This caused windows to be notoriously unstable,
(WinNT on the other hand, is fully 32 bit, which
is one of the reasons 2000/XP are more stable
than the old 95,98,Me branch)
X never had any such problems.
Retained backward compatibility is impressive, because it is an indicator of a good original design. (in the X case)
But backward compatibility that serves to retain a flawed design is bad. (the windows case)
Re:X kicks ass, XFree86 doubly so. (Score:3, Insightful)
Then someone would start to complain about lackine network transparency.
Come on, X is here now, and it works beautifully! Nor is it slow, as seen by the mailer Sylpheed, or Dillo. Or Qt Designer. It's obvious that the perceived slowness of X lies neither in the toolkits or the windowing system, but somewhere else.
For KDE and GNOME that slowness rather stems from the kparts/bonobo component architectures
Re:suggested X changes (Score:2, Insightful)
What you describe is DPS, Display PostScript. The display server can run and even store code snippets sent by the client. Thus you get a completely generic environment that can still draw you exact style of buttons on demand. Think of PostScript as the pre-web-browser equivalent of Java. (:
DPS never did have a free implementation (though Display Ghostscript is around nowadays - but I have no idea how complete / usable it is) but it or similar technology appears/appeared in NeWS, NeXTStep and now MacOS X.
Replacing X... (Score:1, Insightful)
Re:X kicks ass, XFree86 doubly so. (Score:5, Insightful)
So, you run Gtk+ right on the bare metal. Well, that's fine as long as you don't mind running full-screen. If you want to have more than one application running at once, someone has to arbitrate. That means you need a window manager. Then someone has to keep track of the mouse pointer - individual applications would otherwise fight over it. That includes drawing it, moving it around, changing it to the right sizes, shapes and colors on demand. I guess that would go into the window manager as well. Same goes for keyboard focus - applications can't all think they have the keyboard at the same time, now, can they? What the hey, throw that into the window manager too.
Cut 'n' paste between applications? Need some sort of message passing server. Throw that into the window manager as well, why don't we. Drag 'n' drop? More messages - have to support that in the new window manager. Session management (i.e. login, logout, and which applications to start up when you re-log-in)? Need something for that too. 3D calls to the graphics card? Someone had better arbitrate - you only want one application doing that sort of thing at a time. I guess the kernel could probably handle that, since it is already arbitrating the frame buffer.
By now you have a new "window manager" which has subsumed a lot of the complexity of the X server. Sure, you are no longer passing messages between two processes just to display 2D graphics, but I'm not really sure how much of a speedup you get just from that. As Jim Gettys (you're posting technical comments about X11, so I hope you know that name!) is fond of pointing out, lots of people think X is old, clunky and bloated, but nobody seems to be able to produce an alternative windowing system with equivalent (or even adequate) feature set but without comparable complexity.
Re:X kicks ass, XFree86 doubly so. (Score:2, Insightful)
http://www.nvidia.com/
Re:X kicks ass, XFree86 doubly so. (Score:2, Insightful)
Well, no
Actually KDE and GNOME would surely suffer from the same slowness in startup times even if implented (sp?) on Windows (the horror).
Then, of course, there's the utter lack of standardized widgets for doing just about anything. Which is where kparts, gtk, etc. come in.
GTK+ and Qt provides widgets, neither of these are slow if used as widgetlibrary, on the contrary, especially GTK is plenty fast. Qt suffer some from the gcc C++ linker.
But it's a sad statement that a GUI that is WELL over 10 years old (X11 predates XFree86) is just starting to get some decent standardized widgets (sorry, no, CDE, OpenWindows, Motif, etc. didn't cut the mustard even when they were new).
If only you weren't right...
Seriously what the various _UNIX_ desktop environments lack compared to Windows is a speedy component architecture. This is as stated above and in previous post not dependant on X. X handles the display and only the display. What the applications actually do behind the scenes are of no interest for X. Only what they display.
And with a well setup accelerated display, you shouldn't be suffering from artifacts or flickering.
On the problem of server for X, why do many seem to think the framebuffer would be better supported? I have no experience coding X-servers, nor any experience coding framebuffer support, so I ask: why should any one of those be easier? Enlighten me!
Re:X kicks ass, XFree86 doubly so. (Score:3, Insightful)
I've never seen one on linux[1] that I'd want to use everyday.
Sure KDE and GNOME et. al. are interesting toys, but their numerous kludges, bugs, inconsistencies, slowdowns, crashes, and poor GUI design annoy the hell out of me.
C-X C-S
[1] SGI's desktop wasn't bad, for a UNIX/X desktop.
Bit on the ugly, CDE-ish side, but at least everything seemed to work "right".
Backward Compatability of X (Score:2, Insightful)
If I understand the idea behind Perl 6 right, it won't quite run Perl 5 unless you compile the P5 code and decompile it to P6. If this happened to XFree86, wouldn't we see it as a stain on its history?
Let's try to make sure we can run this announcement (backward compat for 10 years) for all our projects.
Re:Why is it that... (Score:1, Insightful)
You say the old code is for legacy's sake, and want to take it out for newness sake. Code before 1995 can't POSSIBLY be good, can it?
You want an X server re-org? You want it to be more modular? Sorry, we already did that. It's called XFree86 4.0.
Re:X kicks ass, XFree86 doubly so. (Score:2, Insightful)
I'm also on a 33.6 modem. I guess I'm "old school."
Re:X kicks ass, XFree86 doubly so. (Score:2, Insightful)
I'm not afraid to say it--the fact that to use Windows requires little to no reading of HOW-TOs and thick manuals is a point in its favor.
"Yeah, but I bet you didn't pass your driver's test without reading the manual."
Read no manual, I learned from my dad.
"You don't need to be an auto mechanic to know how to drive, but you should at least know how to change a tire."
What would be the Windows equivalent to that? Adding/removing a program? These are simple operations compared to what I was referring to, things like making the GUI preemptive by using some command at the bash prompt. And such knowledge may be trivial to you and me, but to someone inexperienced with Linux, they'll just say "Well, that's stupid," and move on to to something that works for them outright. Why shouldn't they?
"The common Windows perception is that you don't need to know how to maintain your car."
Ideally, a computer should be able to maintain itself. And people don't credit Windows enough for how well it works. I'm not talking about the 9x line, either--I know how bad it was.
We have the ability to make things easier on the user. You seem to be suggesting that it doesn't matter, and that the user *should* be forced to manually maintain their computers on principle. That seems a step backwards, like a halt on progress. Should we get rid of automatic transmissions, power steering, and more, because drivers *should* drive it raw just to know how and what it's like? Why should computers be complex? Most other industries consider it a good thing to simplify and make their products more efficient.
"If you get a blowout you'll just call up your neighbor Marge who knows even less about computers than you do. Unfortunately that doesn't work when your blowout occurs on I15 in the middle of the Mojave Desert."
So I guess users should be forced to memorize refresh rates and command-line parameters to launch their GUIs as preemptive in high resolutions, simply because elitists feel they should take time out of their lives to learn such things as the format of a xf86config file or the correct timings for their monitor or which version of XFree86 uses their video card without crashing. Never mind that there is an equivalent car that takes care of most of that automatically.
Most developers, including in other industries, take the time to make their products user-friendly. Only in the Linux community have I encountered people who tell me it is good to keep things complex and time-consuming because it's supposed to be better that way. This is why I personally consider Linux to still be just a server OS, although KDE is really starting to look good.
This is all my opinion, of course.