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.
I went to xwin.org but could not find any type of list of what they hope to achieve. Not a good start for a project. Perhaps they haven't quite got around to posting the list.
Here's what I'd like to see done:
1. Performance. There needs to be some serious performance boosting. Rip out a whole lot of fluff. Honestly, how often do you need remote xwindows? Yes, there is a use for it, but that should be a seperate build altogether.
2. Standardization. Flexibility is nice, but having every damn program do things differently is annoying. It's also a very bad thing if you are trying to break into the mainstream.
3. Easier configuration. It can be a real bitch to get xwindows running properly. Considering the huge amount of differing hardware in the wild, I'm not so sure it would be possible to simplify it too much. Oh, well.
My 2 cents.
-- Will program for bandwidth
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."
If we accept binary drivers then we haven't turned these people to our side. They have turned us to their side.
How can we turn someone to our side who would be in essence - by opening up thier drivers - giving thier R&D budget to the competition?
Hey, I'm all for drivers provided in source too, would preffer that and I do say to hardware makers "Source, please!!!" every possible chance I get. The reality of doing business for these vendors dictates otherwise, however. IMHO, binary video drivers for OSS projects are still better than none at all. They'd still be - in a way - supporting Free Software, while keeping thier shareholders happy. 2 out of 3 ain't bad.
Soko
"Depression is merely anger without enthusiasm." - Anonymous
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
The only thing I'm worried about is Microsoft leveraging this
to knock up the FUD factor another notch (bam). I've got visions
in my head of 'can't trust those free software people, they've
got personal agendas, major breakup, project may die, Microsoft
has always been a wonderful unified blah blah blah'.
I sure hope there's a prepared statement from XFree86 and Mr. Packard
to counter this, should this become an issue.
I personally think that remote X is one of the most amazing thing about X Windows. Especially in the office environment.
I personally would like to see the remote X windows feature kept by both forks, but as an installable option instead of bloating X out for those who have no need of it. Both need to be an option.
Perhaps a separate xserver-xfree86-remote option instead of choosing xserver-xfree86?
Regarding the forks/split of X projects, the last thing I'd like to see is a lack of standardization in the GNU/Linux arena for X. One of the most option used complaint about GNU/Linux is the lack of standardization (even with the LSB).
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.
great point - I wish X apologists could answer that simple question. Without a doubt, everything since windows nt 4.0 has had a great desktop response even on low end hardware. You can feel the difference right away, less flickering on scrolling, smoother window movement and general clean and responsive gui. Clearly, there is something wrong with X to the extent that it doesn't perform as well. Perhaps most people have the reason wrong, and the the network transparency isn't it, but to sweep the problem under the rug as a 'configuration problem' is just pure bs. Linux is a great os, but lets get real about what it is and isn't that great at yet.
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.
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.
No, nobody wants to rewrite X because writing an X-Server is a freaking shitload of work and in every piece of software there are large portions of code which can be reused.
The process of developing is "see problem -> fix problem without causing any new ones", not "see problem -> write a complete new software -> see a quadrillion new problems -> have to handle them first for years -> forget what you were intending to fix at the first place"
xwin is a fork, not a rewrite, and this is good. And please remember that the fork is necessary not for technical reasons but because of the old team refusing to improve their own software!
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
"Evolving" in this case seems to be endlessly adding extension after extension to the point that the extension protocol has become much more essential than the original protocol itself.
.NET applications, as well as pumping windowing graphics through 3D accelerated polygons now. Those kinds of things are features I would like to have in a free, open source Linux desktop. I'm sick and tired of clicking menus and have small but noticable bits of lag, window trails when dragging around, and insanely stupid taskbars, and then realizing even Windows 3.11 provided a snappier and more smoothly consistent interface.
I see no problem with moving to a more monolithic feel for integration and performance benefits. I know that's an unpopular opinion around here. Custom window managers, theming, and so forth would still be possible (you mention Windows, and Windows XP implements this and can be exploited with such programs as StyleXP). Right now, X is a massive bitch to develop for. If for that reason alone, it's my apparently radical opinion that large chunks of it should be re-evaluated.
Look at it this way. X11 was designed for older days and older hardware. Even Microsoft is trying to replace its aging Windows library with entirely
There's a point where you realize that running dozens of apps beginning with "G" or "K" or "x," all with different looks, consistencies, and oddities (to this day, I will never get over the fact that Xine's open dialog is labeled "://" and the tooltip displays "MRL browser"...can't just say "Open"?) is a shambled mess. Choice is good, but sometimes you have to call things like they are and realize consistency and integration is important too. Windows is seen as the ultimate in forced and unnecessary integration, and so Linux has been pushed as far away from that as possible and conceptualized into this entire idealist mindset. I wish it would retain the middle-ground and just do what works best. Heck, that's what Linus does (i.e., BitKeeper).
I'm trying to be constructively critical here, though I realize I may not be helping anything. But at least I really want Linux to succeed in this area. Offering my opinions is the only way I feel like I can help. Take them or leave them.
"Sufferin' succotash."
Wow, you use it to keep your e-mail synced. That must mean everyone uses it, and so despite the fact that "yes, X has some issues," the fact that it is remotely capable justifies it.
Remote X is still not as widely used as it is endlessly hyped to be. You and I both know the majority of XFree86 users do not use that feature.
"Sufferin' succotash."
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.
That doesn't eliminate the latency. Instead, it will just lead to the same behavior we get on Windows, where busted applications not only fail to redraw themselves properly but also do bad things to the entire desktop. It also makes applications unusable over high-latency links.
it is impossible to do complex restrictions on the size of a window (such as a range of ratios or multiples of certain sizes)
Under X11, applications have to live with the window size they get. That is absolutely essential; trying to put "complex restrictions" on window size would be a disaster. It is exactly those kinds of design decisions that make Windows so much worse than X11.
I suspect this is a combination of excessively complex toolkit programming and perhaps some basic failures of X such as an inability to deliver or respond to expose events quickly enough.
Pretty much all the visual artifacts you get on opaque resizing on X11 for local applications are due to poor toolkit or application code. Mozilla, for example, is absolutely awful, and so are many KDE applications. Compare how unresopnsive Mozilla is to Dillo (however, Dillo still flickers--another thing that can be avoided by a reasonably written toolkit).
Having said that, however, all major window systems are client/server systems, and for good reasons. No matter how you slice it, there is the possibility of arbitrary latencies in such systems, even for applications running locally. Applications and toolkits should be written to deal reasonably with latency, but most aren't.
The only way to avoid problems with latency is to put actual code server-side. None of the major attempts at that have succeeded, and I think for good reason. A modest compromise is to put structured graphics server-side; Apple has already done that in OS X and X11 is getting server-side structured graphics as part of XRENDER.
So, in practice, a well-written X11 toolkit can easily get good opaque resizing for local applications running on an unloaded machine. And if the machine is loaded or if the application is running remotely, nothing will make opaque resizing look good in general.
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?
....what happens first.
Forks often rejoin the root tree once they've accomplished their goals, either intentionally or otherwise.
I have a gut feeling that unless the xwin project really refactors (i hate that word) a LOT of stuff, it's not going to be something that people are dying to install, except for the bleeding edge/at-work beta tester (these guys really piss me off, they spend more time recovering from crashes than actually working) types.
Wait it out - software development (especially in larger projects) is a meritocracy -- no one pays attention to you unless you accomplish something that makes a difference. Given what I've read about the reputation of this guy, he's probably going to bring a lot of good, but lets just wait for it to happen instead of getting all reactionary, eh? You're just wasting your time. Parade or throw tomatoes when something *really* big happens.
Pfft, how many times do I need to say "I've got no problem with people using closed source binary drivers" before it sinks in. Why is it that idiots like you insist on confusing idealism with fundamentalism?
I would have thought that was blindingly obvious. It makes the system far more viable and attractive for many people. Video drivers are often a make or break deal - Linux doesn't support your graphics card? Linux doesn't get installed.
As I recall, the primary complaint against BeOS was that it lacked drivers. When they made BeOS free, I would have tried it out, but it wouldn't even have been able to connect to my ISP (it lacked CHAP authentication, I think). You want the same complaint levelled against Linux too?
No. People don't install Linux so they can fire up their favourite text editor and look at the source. They install it to get something done.
Now, the open development model greatly increases the rate at which Linux improves - which is responsible for the features people use to get something done. But the second Linux doesn't get things done for people, it'll be thrown out for something that does.
If you take a look at Linus' policies, you will find that he is essentially pragmatic. He recognised the need for binary-only kernel modules, he also made it clear people using them were on their own, and the kernel hackers will not touch tainted bug reports.
It might not bother you, but video drivers are a make or break deal for a hell of a lot of people.
Bollocks. They are just ideals you don't like in this situation. Namely, it's better to have a system that is 99% Free and works very well for people, rather than a system that is 100% Free and works adequately for a small number of people.
Demand away. And what's this about Linux "winning"? What a juvenile attitude. It isn't a competition.
X is not as precious as an earth. Replacing X would be more like abandoning a smoke-filled factory with endless rooms and machinery added onto it at odd angles with difficult procedures to follow, making it very hard to work there or learn how in the first place. Just start over clean and fresh with new ideas.
;-)
Why not simply tidy up the factory? I will agree that X is quite cluttered with old ideas that may not be implemented in the best way, but if you try and build a replacement, you had better make sure that it can do *everything* that the current X can do. Then, you can tout your cleaner architecture and new features as an advantage over X.
It would be much easier and far less daunting to start with the current version of X, pick something you don't like, and work on that. Make a more flexible, powerful system that then uses an X compatability layer to restrict that power to what X can handle, but make sure that it can *at least* to everything that X can already handle, otherwise you will simply break stuff and irritate people.
But if your intent on starting a replacement from scratch, I'll see you in 10 years
Actually, there is a great reason not to open source drivers: the fact that you can't write a graphics driver today without infringing on a top of phony US patents.
Both Nvidia and Ati can't open source their drivers because they would open themselves up to countless frivolous lawsuits. Heck, even trivial stuff like drawing a b&w mouse cursor by XORing is patented! Do you have any idea how much of the rest of obvious ideas relevant to graphics programming are patented?
As long as the preposterous US patent system is not abolished, I see no way for them to open source their drivers.
Well, right now I have a Web Cam in my desk that doesnt work under Windows XP or 2000, only works under Windows 9x. The manufacturer is out of bussines an said that no driver will be written for XP or any future version of Windows...
I know many similar cases, where the company sink and the specs of the hardware are kept closed, so nobody can update the driver.
But, this same camera works great under Linux using an free software driver.
So, when youre talking about your preference for an binary only driver supported by the manufacturer remember that by not being free/open your hardware can cease to function in a new version of your favorite OS if the company disapear.
I still prefer not to buy the hardware if I can only get a binary only version without free alternatives.
-------------------------------------------- Se você consegue ler aqui então fala português. Óbvio
One of the main advantages of X is its universal.
Once you get an incompatible fork it will loose that and fall into total disarray, hindering the OSS movement.. if not killing it.
We are already convoluted as it is, we DON'T need this.
---- Booth was a patriot ----
Simplicity for users. Xfree86 has been perhaps the single biggest factor limiting Linux's wide spread adoption (I can not count the number of times I have almost put my fist thru the moniter simply because some setting out of hundreds is wrong in some random text file)...
New technology is cool. Better configuration is manditory. I am looking forward to see how this plays out.