Slashdot Mirror
Keith Packard's Xfree86 Fork Officially Started
Reivec writes "I was having a discussion with Keith Packard on IRC about the current developments in the XFree86 Saga and
politics already discussed here earlier, and I learned many interesting things. The project has a new website, xwin, and things are getting underway. 'We're in the process of building community, from that we can construct a government. It's a hard process to construct a representative system from what we have now, so it will take a bit of time. Weeks, not months. --Keith'" Read on for some more details. Update: 04/13 03:30 GMT by T : Reader Khalid points to this informative interview with Packard at Linux Weekly News, too.
"
The site is has only been up a day or so and there isn't a lot on it right now, but he would like to see a lot of community involvement on the site and many user submitted stories to get conversation rolling. A french site has already taken
notice and posted some information on xwin as well. Since such a fork could make a large impact on many *NIX users, I felt the need to ask, 'assuming you had an active fork under development, how interchangable would you expect it to be with Xfree (assuming release builds). Do you think distros would be quick to change if it offered improvements? Or could they
provide both and have the user choose upon installation?' Keith replied, 'Given that distros will have input into how it gets built, I expect they'd be interested in a version closer to what they need. And, given that RH and Debian maintainers are both actively encouraging changes, it's hard to see how they wouldn't want to follow. (or lead).' So if you have had any interest at all in the XFree86 development, this is definitely a community site you should
take advantage of."
On previous discussions of the (then) possible fork right here on slashdot, I remember reading how ATI had sent the drivers to the XFree86 fellows. Months passed, and the drivers hadn't been incorporated yet (and if memory serves still aren't). And doesn't that just discourage manufacturers from supporting linux?
If I were to guess, several months ago, what fundamental OSS project would fork next, I would've picked XFree86. The signs were all there. Slow pace of development. Closed inner development core. Bugs left unfixed.
I'm about to upgrade my machines. The new release comes with XFree86 4.3.0. I'm already aware of some stuff that works in 4.2 but is broken in 4.3. There was no response to a couple of bug reports that I sent in last year, so it's not a surprise to me.
I'm waiting the obvious forthcomming trolling, from the peanut gallery, about the fork, and how its going to be fodder for the OSS lobby. I do not find it a problem. I see it as a natural evolution of things. It's just like 4-5 years ago, when RMS was dragging his feet on gcc development, egcs got forked, and eventually became the new gcc. Right now, gcc 3.2 is a damn good compiler, and I doubt that we'd have it, without that fork.
This is so what we need. Starting over. Nobody wants to do it and hides behind the excuse of a veil of "volunteer work" that somehow implies nobody can criticize even if what you put out is inadequate.
Yes, people realize it's volunteer work. But there need to be results, or just keep everything on your private network and never publicly release anything for fear that people will criticize it. The time for endless projects with lofty goals and ideals but substandard output is over. We're in that phase where we need to just get shit finished and done, and get it done right the first time.
There will be the standard "So where is your project?" replies. They are no less ineffective and pointless than they have ever been. I'm simply stating an opinion, and as "volunteers" you can choose to disregard it. But that simply means the stagnation will continue, and criticisms like mine will continue.
There are entire open source 3D engines, kernels, raytracers, and more that are excellently designed and work well, but we still don't have a decent graphical user interface desktop solution for Linux.
"Either shit or get off the pot." - Randall, Clerks
"Sufferin' succotash."
Every day.
Honestly, how often do you need remote xwindows?
Well, I'm typing this response courtesy of a remote browser window. I'd say less than half my applications are running on the machine I'm sitting in front of at any given moment, for various different reasons.
The fact is, myself and the majority of people I know who have any sort of real UNIX desktop experience find ways to use remote X windows every day.
We shouldn't lose functionality or have to jump through hoops just because someone decided without any sort of numbers to back it up that networking is X's "problem". Nor should we be inconvenienced when a bunch of whiny new Mandrake users buy into that bullshit and decide immediately that their machine isn't snappy enough.
Bottom line: Any problems you have with the speed of your X desktop almost certainly have nothing to do with X's ability to spit out pixels. Until someone can disagree with that and provide numbers to indicate that X's networking is to blame, there's no compelling reason to rip it out.
I'm not trying to pick on you individually, I'm just tired of seeing what appears to be completely groundless nonsense posted as if it's obvious fact.
Game... blouses.
This is so what we need. Starting over. Nobody wants to do it and hides behind the excuse of a veil of "volunteer work" that somehow implies nobody can criticize even if what you put out is inadequate.
Don't forget that it's a freakin' buttload of work to do! X has been around for decades now... working to replace it isn't going to happen overnight, or probably even over the course of a year. Just look at Berlin (or whatever it's called now, I forget). It's been in the works for as long as I can remember, and as far as I know, the user base isn't exactly noteworthy.
Replacing X is like abandoning the Earth to terraform Mars just because cleaning up the Earth is too much work....
-"One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man." -EH
All of the special stuff that specific vendors can do is in the hardware itself, while the drivers just provide an interface to that hardware. Any special tricks that the drivers have are probably either just specific parts written in assembly to make them faster or cheats like turning off certain features at certain times to make the frame rate higher while hoping the users won't notice the difference in quality.
Both nVidia and ATI have done this kind of cheating, by the way, which makes sense since both of them are very hesitant to give out open source drivers. Perhaps they are ashamed of their code. I wouldn't be surprised if the managers ask the programmers if they should open source it, then the programmers think, "Oh crap! My code looks like shit and has all sorts of vulgar comments! Uh, no boss, open sourcing is bad. Yeah, thats it."
No special things would be lost by open sourcing drivers. No development would be handed to the competition. The competition would still have to develop their own silicon, which the drivers don't help with at all. If someone really wanted to copy your design, they could, *gasp*, look at the white papers if they exist, or use a myriad of other high-tech techniques to look at it and figure out how you did what. And even then, almost every cool trick on silicon is already patented, and protected that way.
There is NO REASON WHATSOEVER TO NOT OPEN SOURCE DRIVERS. Get that into your head.
I'm not asking them to. I'm disputing the claim that you can "win" by using closed software, when the whole purpose of free software is to NOT use closed software. I see no reason why I should ignore the ideals of free software in order to be "sensitive to their needs". I would much rather not use their product.
IMHO, no drivers at all are better than using binary drivers. I would rather Linux loses if winning means becoming non-free. Better to die on your feet, and so on.
The difference here is that you are being pragmatic and I am being idealistic. If I wanted to be pragmatic I wouldn't use Linux in the first place. I'd just use Windows.
Don't forget that it's a freakin' buttload of work to do! X has been around for decades now...
I don't believe the notion behind the xwin site is to replace X by starting over from scratch. This is more along the lines of where Berlin is headed.
Based on the various linked articles, this will be a code fork, not a ground up rewrite. Take the stuff that works, then split it up into bite size chunks that individual developers can manage more efficiently. This isn't reinventing the wheel. Sounds more like trying to make it round again.
The line must be drawn here. This far. No further.
As pointed out elsewhere, network transparency is virtually free, especially when the clients and server run on the same machine.
Simply put, clients must talk to the X server in order to make requests, read keyboard/mouse input, etc.
How would you suggest the clients and server communicate with each other?
I'd probably look for a mature communications mechanism which has been pounded to hell and back by as many users as possible in as many environments as possible. You're writing a cross-platform windowing environment, so portability is a concern.
Can anyone suggest a cross-platform, mature communications mechanism that doesn't impose any more overhead than necessary?
Let's see -- X could either use a highly-refined, well-defined communications mechanism which damned near (if not EVERY) OS vendor supplies (in the form of IP and UNIX domain sockets where available), or it could define its own communications mechanism which would probably not work nearly as well on nearly as many platforms.
And the parent is modded 3? Is there a "+1, unjustified crap" rating I somehow haven't noticed?
Somebody get that guy an ambulance!
All of the special stuff that specific vendors can do is in the hardware itself, while the drivers just provide an interface to that hardware. Any special tricks that the drivers have are probably either just specific parts written in assembly to make them faster or cheats like turning off certain features at certain times to make the frame rate higher while hoping the users won't notice the difference in quality.
Drivers describe in software what the hardware is capable of. Do you know for sure that ATI wouldn't be giving the farm to NVidia with OSS drivers? I agree likely not, but I can't say for certain.
Both nVidia and ATI have done this kind of cheating, by the way, which makes sense since both of them are very hesitant to give out open source drivers. Perhaps they are ashamed of their code. I wouldn't be surprised if the managers ask the programmers if they should open source it, then the programmers think, "Oh crap! My code looks like shit and has all sorts of vulgar comments! Uh, no boss, open sourcing is bad. Yeah, thats it."
Or maybe they've optimised it for Windows, and would expose in some way the IP one of thier business partners. Fun? Yes! Good business? No.
No special things would be lost by open sourcing drivers. No development would be handed to the competition. The competition would still have to develop their own silicon, which the drivers don't help with at all. If someone really wanted to copy your design, they could, *gasp*, look at the white papers if they exist, or use a myriad of other high-tech techniques to look at it and figure out how you did what.
They I guess we can do the same and write our own drivers, right? Seriously, even if the competition does that, they part with a big chunk of change in doing so - which re-evens the field. An OSS driver could significantly reduce this cost, un-evening it again
And even then, almost every cool trick on silicon is already patented, and protected that way. There is NO REASON WHATSOEVER TO NOT OPEN SOURCE DRIVERS. Get that into your head.
OK, OK, no reason to yell,I actualy agree with you. I'm trying to build bridges and allay fears, not beat people into submission, though.
Soko
"Depression is merely anger without enthusiasm." - Anonymous
I have to run X->xlib->window manager->windowing library->desktop environment->various daemons just to get a desktop equivalent to Windows 95.
And your problem with it is what? Seems to me like you have an aesthetical problem with it. I think this chain of components is what makes unices so powerful and the lack of it why I dislike MS windows.
It all feels cobbled together to me, and I get sluggish performance.
Just because MS windows has a monolithic kernel/graphics renderer it doesn't mean it isn't cobbled together behind it's surface. X is just open about this from the beginning. Again this seems like you have just an aesthetical problem with this. And regarding the performance, benchmark tests show a negligible difference between X and MS Win, and why give up a pile of advantages just for a few more fps?
Not to mention conflicting interfaces, dependencies, and so forth. You've all heard the standard complaints.
Conflicting dependencies are a completely other field of unix, and dealing with this should be part of another developement.
Remote X is not as widely used as it is endlessly hyped to be. If you want that, use the normal XFree86 project. Linux needs a real, innovative desktop environment. If you really need remote capabilities, can't it be added on or kept as a separate build option?
Oh no, not again. For the last time, the problems of X are not caused by the remote capability unless you show different. And to do that, there is more needed just to say "X has remote capabilities, MS Win has not, X has disadvantages in comparison to MS Win -> X is disadvantaged because of the remote capabilities."
I have to run X->xlib->window manager->windowing library->desktop environment->various daemons just to get a desktop equivalent to Windows 95.
>>>>>>>>>>
There should be a test in software architecture as a requirement for posting to Slashdot. The layering you're bitching about is present in all software systems. It's just that with Windows, they don't have names that the marketing people spit out all the time.
KDE - Higher level services in user.dll
Qt - MFC, User.dll, Commctl.dll, Comdlg32.dll
xlib - GDI32.dll
X server - Kernel end of GDI
XAA - DDI
A deep unwavering belief is a sure sign you're missing something...
What Keith is talking about in that paper is very useful, but most of it is not about speeding up local uses of X11. And the things that do apply to local uses of X11 also pretty much apply to XP and Macintosh, because those also use a client/server architecture, just like X11.
Nothing wrong with being corporate-controlled, per se. Regardless, Keith's suggestion for governance seems to shift the choice to the community (or, at least to those people who'd care enough to participate).
Besides, it's not about ideology or even the type of government. More important are the characters of the leaders. All the different ideologies did well and poorly depending on the leaders of those bodies. In this case, I believe Keith Packard, Jim Gettys and the whole gang forming xwin to be honorable and community-oriented people.
And again, you're missing the point. X is *not* the GUI. Everyone, repeat that until you understand it. Run X with a light window manager rather than the heavy desktop environments, and everything will respond much better than windows. After using a real OS for awhile, I absolutely cannot stand clicking the start button and having to wait half a second for a menu to pop up.
X is not the performance problem. It's unoptimized, eye-candy-filled but non-functional Gnome and KDE that need help. Those who claim that X is "holding back Linux" don't understand what X is.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?