Slashdot Mirror
XFree86 Fork Gets a Name, Website
Piethein Strengholt writes "Today the Xfree86 fork is a fact. A new project has started and is located at: xouvert.org. Xouvert has been started due to the corporate structure and the slow development of XFree86. They hope to reduce the risk to XFree86 of incorporating new drivers and features."
It seems that this group wants to push the envelope of features in X. Why not just do something like the Linux kernel numbering? e.g. 2.4 -> stable, 2.5 -> testing. Then, people could make a decision as to if they wanted to run the bleeding edge in an attempt to use new features. It'd also save the hassle of building for 2 graphics systems, and merging patches between the two code bases.
Overrated / Underrated : Moderation
I think XFree has been lacking a lot of things for a long time, like true alpha blending between windows and such. Aside from things like the Render extension, this is a project that really hasn't gone much of anywhere in several years. Getting the features we need into the window system itself would position Linux much more prominently on the desktop.
If they're trying to include useful third party contributions, they could do worse than include NX, a revolutionary new compression and proxying technology that makes it possible to run an X session over a 9600 modem at a useable speed. But I didn't completely understand their policy on licences (the NX infrastructure is GPLed, whereas X is under the MIT licence).
perl -e 'fork||print for split//,"hahahaha"'
Is it true? Who knows, probably not. Is it an interesting rumor? Sure why not.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Perhaps it's *YOU* who should 'get it'.
Had you RTFA properly, you'd have seen the next line says
"All code that enters the project is under the standard X11 license, or compatible free license as specified by the Free Software Foundation."
See, that's not so bad, is it?
Seriously, I don't particularly like NDAs, but as long as the source code is 'free', then it's really not a problem IMHO.
David
XFree86 does seem a little bit bulky and slow to me. Like the Xouvert website said, it's going mainly towards stability rather than new features. Stability is all well and good, but you DO need fresh new features (or "new blood" as that site might say) every so often.
I'm not sure that the X source can legally BE forked (I know nothing about licenses), but even if it can, I'd rather have the Xouvert guys put in a brand new implementation using the same X protocol but much different code implementing it. It might be faster, and maybe even more stable (or easier to stabilize). Or maybe it'll go to hell because they can't code. Either way, it would still be a nice way to prove whether the fork was really necessary and worth it. There's another word I'm looking for but I can't remember what it is...
Just my two cents...
Something that i've seen a hot debate over before..
Many people have mentioned something along the lines of "X-lite"...
Bascially an X server that has been stripped of all the features that the "average" person doesn't use, such as running remote desktops over networks and things.
I hear so much complaints about how "X is so slow, buggy and internally is a total mess", etc. I've never personally had a problem with X, nor have i looked at the code myself, but it would be interesting.
Of course, the full-on XFree86 would still be available to all those who *do* want/need the extra features.
do() || do_not();
Check this link for my argument of why framebuffer isn't a good solution. Framebuffer is actually slower because it doesn't take advantage of the video card.
As far as I've been led to believe, there are *no* developers for the current Xfree, that being the need for a fork in the first place. Whereas now people may show an interest in working on Xfree, they have little hope of ever making an actual contribution (due to politics and the general lethargy surrounding the head honchos). So in that way, there really aren't any developers to lose.
I personally applaud this fork, anything that encourages support, and let's be honest, momentum, to a application as critical as X, can't be anything but a good thing. One thing is for certain, these guys have made an effort to changes things; and that's far more than those in Xfree, or the aborted mess of a website, xwin, have done!
All of the major UNIX vendors at one time or another have looked at implementing a shared memory transport for X messages on the theory that it would reduce overehead. In benchmarking, however, it was routinely found that Unix domain sockets imposed very little or in some cases less measurable overhead than shared memory. Net effect: no speedups to justify implementation. And in case you weren't aware, we do now have DRI and XV for 3D and video, which do dump network transparency in favor of speed in these extreme high-bandwidth cases. In fact, Linux+X outperforms Windows in terms of raw frame rate in many games on the same hardware (i.e. Quake+Nvidia).
But that kind of raw data pumpking is not very useful for normal applications, which don't need heavy bandwidth at all! You seem to think that your AGP bus is a fat-pipe framebuffer and that given a simple enough toolkit, it would somehow be a speedup to blast 32-bit screen dumps onto it at full speed. But even if this were the case, the content of those dumps would have to come from somewhere. In the API of every modern windowing system (including MS Windows) you'll find heavy reliance on some sort of message passing interface to make the nuts and bolts of the user interface; in short, every windowing system is "network transparent", it's just that most of them are only flexible enough to use one transport method, unlike X, which lets you choose the transport method. And I challenge you to find me any non-motion-video non-3D desktop application that is bandwidth or latency limited even on 100Mb ethernet, much less gigabit ethernet or local transport (get netperf on your own PC and check out the unix domain bandwidth!) Most any kind of local transport is going to have negiligible overhead compared to the overhead imposed by data inefficiencies in toolkits themselves (message redundancy, uneeded refreshes, etc.), and neither of these runs up against any kind of bandwidth or latency ceiling on a modern PC either. Both KDE and GNOME have major architectural inefficiencies outside of the widget rendering path. Search google.
And as far as burden of proof goes, you're the one proposing to throw away one of the most important features of the Unix desktop. I often hear complainers say that "90% of Unix users never need network transparency!"
I don't buy that number. You're getting the Windows market confused with the Unix market mate, I'd guess that 70-80% of regular Unix users do make use of network transparency becaue the vast bulk of regular Unix/X users are doing so in an administrative capacity. I'd love to see a Slashdot poll on this point.
STOP . AMERICA . NOW
"Are you saying that you'll remember www.xouvert.org as easily as you remember www.yahoo.com in 6 months?"
I don't know, but I'm pretty sure I will, if the project gets popular.
But that's not the point. If you can't remember the name anymore then that means you aren't getting exposed to it enough. When you're not getting exposed to it enough that means one of these two things:
1) You don't care. So why should you remember the name? No problem here.
2) The project died off. Why should you still remember the name? No problem here either.
"Ogg Vorbis btw, is a terrible name. I still can't tell which part stands for the codec and which is the file format."
Ogg is the file format, Vorbis is the codec. I remembered this since day 1 and I still remember it.
If you can't remember that that probably means you don't care. What good will it do to you if Ogg Vorbis has an easier to remember name, if you don't care?
At home it's great. I can keep one computer hooked up to the stereo and run XMMS from any computer in the house. I can do my work related crap on my laptop, plug it into the LAN and pick up on my desktop exactly where I left off. No need to copy files or anything. I can run mplayer on the local TV out of my laptop, and run any apps I might need on the laptop on my desktop without interfering with playback. If anything X is not transparent enough. We need a good way to switch apps from server to server, or even just detatch them completely. Something like screen. God I love screen.
Give me Classic Slashdot or give me death!
It's already taken?
I suggest a re-name, but with an open naming contest this time.
In what system do we force project names on independent developers who didn't ask for an opinion? If Xouvert is a mistake, it's theirs to make. The code will survive if the project doesn't.
Anyway, Fresco|Berlin is merely a GUI built on top of the GGI/GII interface. XGGI does much the same, but works with X instead.
The problem with X is that it is too bulky. We need a RISC GUI, with layers which supply the X API. GGI/GII seems like a good foundation. KGI does, too, but development with KGI is too stop-go.
Anyway, switching protocol isn't the solution. Neither is a simple re-implementation, or the addition of new code. What you need is a compartmentalization of the code, so that each part of the code can run efficiently and quickly.
Think of it this way:
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I could be mistaken but isn't that how /. came around? Hrm, and now that I check my sources the faq says:
Not to mention the problem I have giving them the address.
"No, the WORDS slashdot, THEN a period, THEN org... no no, you type the word DOT after slash. No, its one word. SLASHDOT then a PERIOD then, oh fuck it, here, i will type it for you."
I am NOT kidding. Wife kept on trying slash.dot.org last night, (an article she would like) and she is not an internet idiot.
Tequila: It's not just for breakfast anymore!
Network transparency is the single best thing about X
On that, no argument. X's implementation of network transparency is quite possibly the worst part of X, however. The X server is dumb and cannot be helped without some grotesque hacks. I'd really like to not cause a zillion expose events to happen every time I resize or move windows. I'd like to be able to program events locally and not have every single damn keystroke roundtripped. 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?
But you say there's local transports for local clients so we don't notice that. Then why the transparency in the first place?
I know about things like LBX. I also know that they're still not worth a damn on VPN tunnels which still impose big overhead on short packets. The fact is, a session on citrix is usable over a dialup, and X is not.
I've finally had it: until slashdot gets article moderation, I am not coming back.
I agree completely that a common deficiency in open source projects is that the software is not described adequately for those who are shopping around for a solution. But the description of a piece of open source software ought to be as informative as possible. That means giving as objective as possible information about the strengths and weaknesses of the software. If softwareA is better at taskFoo, then the descriotion should say so. Perhaps it should also indicate whether the developers plan to rectify that weakness in the near future.
Come now, they're joking, of course. A joke that, after reading many posts here, seems to have fallen flat. To confirm, Google for goddesses--there is no xouvert on any list. But mainly, the tip off is the word ouvert itself.
So, failed joke aside, they did pick a "nice, friendly, high-concept name", as you define it. It's just not in English.
(my, i can't believe i'm defending the name of an open source project--derivative oss naming is a particular bete noir (er, sorry) of mine.)
A third option is that both projects will be merged. EGCS no longer exists as a separate project, that work was eventually merged with GCC and released as GCC 3.
Well, maybe because the XFree team isn't interested in anything except improving graphics drivers? I mean, I love X, I think it's a great concept, but XFree86 needs improvement. Not necessarily in overal concept, but in implementation. Lots of cleanup and rewrite work to be done that could make X a lot better than it already is.
But if nobody in the core team is interested in any of that, then you have no choice but to try other methods of getting it accomplished. However, I'm disappointed that I don't see any of the X developers I"d expect to see listed on the project page. It makes me hesitant to jump on this thing as a great move. Regardless, I don't think it's a bad move, but it's not the fork I've been waiting to see. I guess we'll have to see how things play out.
I'm encouraged by their choice of repositories though. It'll be good to see how Arch works for them. I anticipate they'll be very happy with it.
"No nation could preserve its freedom in the midst of continual warfare."
--James Madison
I'm with you, while X isn't the simplest thing one could think of, it really does perform amazingly well. The frame buffer as a 'performance solution' is a total dead-end as writing a stream of pixels to a buffer is a LOT slower than using X to draw complete objects.
I do think X is a bit creaky though, maybe it is time to start a new one, one where major (and even compatability-breaking) changes can happen. Some things on my wishlist:
*A single, standard, simple font system.
*Integration of a more modern toolkit and WM, even if it has to borrow heavily from GTK+ or another project. This would be inclusive, it wouldn't prevent you from using other toolkits and WMs (think WindowMaker instead of TWM in the base set).
*Ability to run like Quartz Extreme (as an OpenGL-based system). Also, not as a requirement, just as an option.
*There's no excuse for not vectorizing this from the bottom-up, and we'll be thankful when the commercial OSs get this done and we've already got it. Think about running your monitor at 1600X1200 and telling the system it's 200 DPI so it zooms everything accordingly. Apple has this up their sleeve now, and Longhorn might unleash it on Windows.
*Transparency, which personally doesn't get me hot and bothered, but I guess people think it's cool.
*Ability to act as the 'console' layer for the OS, no more framebuffer-for-console, X for graphical. Have the thing run a full-screen native terminal, and have the OS work with it.
*extensive database of video cards and monitors for easier configuration, this should be integral to the graphics system. It took me a LONG time to find the specs on some of my monitors and I'd rather not do it ever again.
*Generally simpler/more elegant design. I'm pretty sure that a lot of what's in XFree86 today is there just to prop itself up, while a newer system might have a better chance of coming out with a clean design.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
One of the problems with xfree86 is that it is almost impossible to get patches considered. (ATI tried and failed.)
A lot of positive changes have happened to xfree86 since the threat of a fork. but none of them have addressed the fact that some of the leadership is using the position as resume/C.V. padding.
One of the primary maintainers of xfree86 made a statement where he admitted that he uses w2k as his desktop. and doesn't really use X. (check google for references, I'm too lazy at the moment.)
Xouvert my well get contributions from ILM, Pixar, Nvidia, ATI, and others that xfree86 had no interest in. Either xfree86 will become more focused on progress or the will become irrelevant.
Your premise that there is no mass rejection of qualified developers at present is wrong.
The premise that there are a finite amount of programmers, if you have less than five projects filling a need is also wrong.
This is the best news about the *n*x desktop in the last month.
To Jonathan Walther, William Lahti, RJ Bergeron, and everyone else involed, Thank you.
Work bio at MMWD
This problem has nothing to do with "Free" operating systems. It's about vendor support. You'd have just as much trouble (if not more) getting your card to work with OS/2, Be, a Mac, or whatever if the vendor doesn't support the system.
I used OS/2 for a while, but my sound card didn't work because the vendor only made Windows drivers, yet it worked in Linux because some guy (or a few guys) had soundcards with the same chipset, so they figured it out and wrote a driver. In a closed system, if you don't have vendor support, then you're sunk. In an open system, at least you'll have a chance.
In fact, if the drivers were open sourced ior the vendor supplied interface specs, they'd probably work better and have more support. The vendors are selling hardware, not the drivers, so there isn't a reason to keep this information secret. They say competitors would steal their designs, but I don't believe it. The hardest part is the internals of the chips--you don't get that from drivers and interface specs.
Yeah, sure companies cloned the SoundBlaster design, but a sound card is just a fancy D/A and A/D converter. Not much to it, and they were just cloning the interface because in DOS, there is no such thing as a driver. Eventually there would have been some sort of standard because only stupid people will pay megabucks for a sound card when a $20 card will fill all their needs. This won't work with a 3D video card. They are too complex. Sure, there are discount 3d card manufacturers, but interface specs won't help them at all.
Um, sure, but the exact same thing applies to imake -- and unless you're using a very common system with a bog-standard installation, imake fails more often than it succeeds.
:-) :-(
Imake and autoconf take fundamentally different approaches to configuration: imake says `give me a system type I know about, and I'll give you some makefiles' -- great, unless of course it doesn't know about your system, or if you've changed something. Autoconf, on the other hand says `I'll grovel around on your system and see what things it implements that I know about, and try to come up with a configuration' -- this works much better on disparate (though not so disparate that the probing just fails, or the set of features implemented is simply outside of what autoconf can use) or hacked platforms.
The imake approach is great if there's only a fairly small number of system types in use, but fails miserably when this isn't true.
In the early days of X, imake's approach was probably reasonable, but as X was ported to more and more systems, the number of unix variants exploded, and the number of home-grown linux variants &c increased (which all had different library versions installed), it became a bad joke. Of course this was hard for automake too, but it was far better place to cope with such a challenge.
Now, as many proprietary unix variants fall by the wayside, and the interfaces used in typical linux/bsd systems have become a bit more stable, maybe imake has become more practical again (I don't really know).
Another issue entirely is the implementations. I've wrestled with both, and as far as I'm concerned, both suck. No points there.
Personally I think that the autoconf method is far more elegant; in my mind the best solution would be something like autoconf, except rewritten in a language that wasn't m4, and perhaps more support for external input to tests -- for instance, if you could override the method it uses to check for library functions to always call some system-defined checker instead, it could be made more portable even to systems on which its (often rather shaky) testing methods don't work.
We live, as we dream -- alone....