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."
It seems to me that if they are going to fork they might as well do something right from the ground up. They could build something like Quartz Extreme and then add the old version of X11 on top of it like Apple has done with OS X. Lots of possibilities!
Actually, it's strangely democratic. Seriously, the vast majority of successful Open Source projects have a single maintainer. X hasn't, and some might speculate that that's part of it's problem. I guess this has to be done to attract a large number of old X developers, but I really wonder if a benevolent dictator could make things work better (and if not, just use XFree86).
Sig:Why copyright isn't a fundamental human right
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.
X development has been somewhat slow, but it seems like the really big issue has always been drivers -- is there any way that new leadership can help get specs from manufacturers?
/. interview?
Getting drivers for X doesn't seem to be a problem, as long as those drivers are binary. I know, I know, Free Software, blah blah - however, if we're to turn these people to our side, we have to be sensitive to thier needs. In that vein, if xwin comes up with a clean, consistent API (perhaps even one that's linked into DRI or some other interface in kernel space) that all the video harware vendors can write to, without spelling out to thier competition how to trouce thier products in the next rev, they'll do much better I'm sure.
Editors: can we get Keith for a
Please!
Soko
"Depression is merely anger without enthusiasm." - Anonymous
Every day.
1) This isn't about XFree being fast for you. And if it performs as well as (say) Windows 2k or XP on modern hardware, then you've spent alot of time tweaking X, and probably your kernel. X should be decent out of the box, and it isn't. "Works good enough" isn't something that I personally like settling for.
2) Standardization is absolutely a point of X. I don't know how you can think otherwise. One of the biggest objections to this port is the possible breaking of the X standards.
3) There is no reason whatsoever that XF86Config needs to be the monster that it is. A logical hierarchy of settings would be a good first step. Alot of the crap in XF86Config is handled by drivers using a standardized interface in Windows - this is a reasonable model to copy. That would help eliminate the need for every distro that's trying to be user-friendly to write it's own hardware detection program.
There is no "fluff" there. X11 runs as a separate user-mode process from applications. That means that commands to it need to go from the user process to the display process. X11 uses an asynchronous protocol and a mixture of shared memory and UNIX-domain sockets. And for games and other applications, there is DRI.
It happens to be the case that the X11 protocol and semantics are well-enough defined that the same protocol works over fast networks, but you don't pay anything for that.
Macintosh (as far a I can tell) works the same way: a display server, user mode applicatins, and some IPC mechanism connecting them. The only reason remote display for the Mac doesn't work like X11 is because it lacks some high-level primitives.
Windows used to start out as a frame buffer library, but it, too, works pretty much like X11 these days: asynchronous communications between user-mode processes and a display server running in a separate address space. The only thing NT/XP do differently is that the display server runs i the kernel. You could put an X11 server in the kernel, but it probably wouldn't make a big difference in performance (and it would be a headache).
When a particular X11 implementatin is slow, it's usually because of bad drivers or bad configuration. With comparable drivers, X11 performance is top-notch--usually better than Macintosh and comparable to Windows. And many X11 applications are slow or inefficient because their developers assumed they were programming a frame buffer--an assumption that is wrong on all major GUI platforms these days.
In short, this "X is slow because of network transparency" is wrong in multiple ways. First, X11 is not slow compared to other popular windowing systems. Second, nobody has ever been able to describe a way in which X11 could be made faster by choosing a different IPC mechanism. People who criticize X11 for using IPC usually assume incorrectly that other systems don't use IPC, but they do.
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.
X11 is standardized. What is not standardized is GUI environments and toolkits. But there is a reason for that: people are still figuring it out. It's software evolution in action. And it's not like Windows or Macintosh have figured that one out either: on Windows, people use dozens of different toolkits, several of which come from Microsoft Similarly for Macintosh. Gnome and KDE are making an effort to interoperate, and that's all you can ask for.
Also, there are plenty of programs that need to "o things differently". X11 is not just a desktop window system, it's used for scientific and engineering applications, customer terminals, ATMs, banking workstations, embedded systems, and lots of other applications. Those environments should not look like a regular desktop.
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.
I think people are doing as well as they can, given limited information from manufacturers.
But because X11 is standardized, you can always buy a commercially supported X11 server. Those usually run very well on the latest hardware. If you are using XFree86, you are using something that's both free and experimental.
As far as I can tell, "the split" is over none of these issues. Both branches will remain network transparent window systems, they will remain compatible, and they will continue not to force toolkits or desktop software on users. If they tried to, they would cease being X11 implementations. What Keith probably will do is accelerate bug fixing and bringing extensions into the X11 server. And that's what really matters.
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.
Every day.
Absolutely. People who don't need it everyday are people who only use one computer (eg, home users with only one machine) or people who never realized how easy it is to run a program on another machine and display it on your desktop. Remove this ability, and you remove a huge reason for using unix/linux on the desktop in the first place.
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.
From the GCC FAQ
In April 1999 the Free Software Foundation officially halted development on the gcc2 compiler and appointed the EGCS project as the official GCC maintainers. The net result was a single project which carries forward GCC development under the ultimate control of the GCC Steering Committee
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.
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
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.
Check out their statement:
:: signatures clipped ::
A sizeable group of developers from the two leading free software
projects developing desktops based on the X Window System, KDE and
GNOME, have been discussing the current situation among themselves
and decided to draft and release this document.
We acknowledge the dedication of the XFree86 project in providing us a
free and innovative implementation of the X11 industry standard,
something we benefit from on a daily basis. Therefore, we want to
share our joint point of view with the community.
1. XFree86's recent technical progress, culminating in the 4.3
release, brought significant advancements to the X desktop. Prior
X Window System implementations were lagging behind the needs of
modern desktop users.
Cursor theming, simplified font configuration, dynamic screen
resizing, and so on address long-overdue usability issues with X
desktops. XFree86's robust solutions in these areas have been
invaluable.
However, the work is not done. Our goal is to provide the
community with desktop systems far beyond what anyone offers
today. We are ready to take advantage of an X Window System
implementation that continues to innovate.
2. GNOME and KDE have two interests in X:
- We would like to have a single organization where X innovation
occurs. By innovation, we mean the definition of new APIs,
specifications, and features - new additions to the foundations
that KDE and GNOME rely on.
- We would like to have a frequently-released, robust, stable,
open source implementation of these APIs, specifications, and
features.
We are explicitly distinguishing innovation from implementation,
because standards should be adequate to allow multiple
fully-interoperable implementations.
Within the development organization responsible for defining and
crafting new features to be adopted as standards, innovation
should happen in the open, with all affected parties able to
participate early in the process.
3. We do not want to take sides on the recent political wrangling of
who did what when and who should be in charge. Our hope is that as
a community we can find a way to involve everyone in X's
development and move forward with solving technical challenges.
4. It makes sense to us if the organization responsible for X
innovation also develops the most widely used open source
reference implementation. This ensures an emphasis on working
code, and provides a pool of active technical expertise.
5. We would like to see this forum work toward a unified
organization, governed by active contributors, that implements,
deploys, and standardizes new X innovations.
We do not want to take an a priori position on how this
organization should be organized or governed - that is a
conversation we're trying to start, rather than one we're trying
to end. We trust and will support the X community as they work to
address this issue.
A deep unwavering belief is a sure sign you're missing something...