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."

Comments

So, what now?

[dspeyer]

Wow, It's been a long time since something comparable happened. I guess the glibc/libc split is probably the closest. That settled out reasonably quickly, (though it left some freakish version numbers that still cause trouble). I suppose one can hope for something similar here.

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?

Editors: can we get Keith for a /. interview?

Oh, and, FSP? (first substantive post)

Re:So, what now?

[Anonymous Coward]

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?

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?

Re:So, what now?

[BJH]

The gcc/egcs split was more recent, and more acrimonious. Thankfully, that panned out in a way that benefited gcc, rather than hindering its development.

I just hope the same thing happens in this case. Keith Packard has been doing some very good work in XFree86 lately, but there have been accusations that he's too 'corporate-controlled' (I have no knowledge as to the truth of these accusations one way or the other).

Re:So, what now?

[Soko]

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?

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 /. interview?

Please!

Soko

Re:So, what now?

[inode_buddha]

I have no idea either way ath the moment, but being "corporate-controlled" might just be a good thing for people who need video drivers. After all, video card manufacturers *are* corporations.

Re:So, what now?

[nathanh]

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.

If we accept binary drivers then we haven't turned these people to our side. They have turned us to their side.

Re:So, what now?

[Soko]

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

Re:So, what now?

[Anonymous Coward]

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.

Re:So, what now?

[nathanh]

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?

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, binary video drivers for OSS projects are still better than none at all.

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.

Re:So, what now?

[Soko]

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.

I would rather as well. If there were 2 nearly functionaly equivilent products, but once used Open Source drivers and the other not, I'd take the vendor supporting Open Source without question. Unfortunately, we don't have this choice (at present), since all video card drivers seem to be binary only. We can't "win" them over if they're regarded as the enemy, though.

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.

To each thier own. I'd rather they get to know us and like us. Maybe then they'll be more receptive to providing a more open solution, rather than keeping all of thier specs under lock and key.

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 said - 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, - which mentions nothing of binary drivers. Perhaps I should of separated that a bit more. You see my idea, here? Or would you go all the way to the gates of hell in order to prove yourself right?

I'd just use Windows.

I have my answer. ;^)

Soko

Re:So, what now?

[Soko]

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

Re:So, what now?

[RichiP]

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.

Re:So, what now?

[el_oso]

I consider myself a pragmatic person. And I definitely use Linux because is better for my needs than Windows, I am also idealistic, but that is not my main reason. Is quicker to type a 'for' in bash than click 50 times (you know how to do it,though). GNU/Linux is faster, modular and you can do much more without a GUI (like calculations in a cluster).

It's true that finding drivers or supported hardware can sometimes be a pain on the neck. Also, some niceties like DVD and video playing could be hard (or illegal) to use in your computer or sometimes not as good as in Windows.

I have heard a lot of times that people complain about 'Linux' because Y hardware doesn't work or because you cannot play something as simple as a Quicktime movie (thank you xine). The thing is that these people don't think that the manufacturers are the responsible, they *blame* Linux in general.

This is a paradox, because manufacturers don't want to make drivers for linux because they are afraid to release the specs. *If* they make binary-only the OSScommunity doesn't like them. Manufacturers don't care that much because it doesn't represent a big percentage of the user base. But the userbase doesn't grow (as quickly) because most of the end users don't like this lack of hardware support.

IMHO, no drivers ->THE WORST, binary only that depend on one version ->BAD, binary only drivers that can adapt to your changes (like nvidia drivers) ->GOOD, OS drivers ->BETTER.

So, I share Keith's point of view that XFree86 should have an API that can be used by the manufacturers. At least we could get more drivers. After that perhaps we can convince them to release the source code.

Re:So, what now?

[nathanh]

I'm trying to build bridges and allay fears...

But you're building those bridges with binary drivers and closed source. What's the point? You might as well use free software on Windows because the end-result is the same. You're still using a closed source system. Why do you think Linux has a greater marketshare than arguably better systems like MacOSX, BeOS, or QNX? It's not the price because BeOS didn't get any attention even when they made it cost-free. It's not the applications because MacOSX has many more. It's not the variety of supported platforms because the majority of Linux users use x86. The primary reason why Linux is winning is because Linux is open source. That's the distinguishing feature of Linux. It's the whole POINT of Linux.

I've seen your rationale which is "better to get drivers now and convince them of the benefits of open source later". I disagree. There's no incentive for the vendor to change their policy when they have already sold you the hardware. All you've really done is prop-up the binary-driver business for a couple more years. Much better to let the vendors know our rules up front. Then they can play if they want to and there are no nasty surprises later on. If they decide that their specs and/or source are more important than selling their hardware, doesn't bother me, Linux will do just fine without them. Another vendor will always appear who is willing to release the code or the specs.

Pragmatism is all well and good - it gets the job done - but a pragmatist has no ideals. You might be using Windows XP tomorrow for whatever reasons. And that's fine. I've no problem with that. But if you want Linux to win then you'll demand code for your drivers. If you want Linux to win then you need to be an idealist.

Re:So, what now?

[JimDabell]

But you're building those bridges with binary drivers and closed source. What's the point?

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.

It's not the price because BeOS didn't get any attention even when they made it cost-free.

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?

The primary reason why Linux is winning is because Linux is open source. That's the distinguishing feature of Linux. It's the whole POINT of Linux.

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.

Much better to let the vendors know our rules up front.

...and you think companies like NVidia are going to turn around and say "Oh my God! We'll get right on that, because we can't possibly afford to lose our primary market of Linux geeks"? Get real.

If they decide that their specs and/or source are more important than selling their hardware, doesn't bother me, Linux will do just fine without them.

It might not bother you, but video drivers are a make or break deal for a hell of a lot of people.

Another vendor will always appear who is willing to release the code or the specs.

...and this may shock you, but those people aren't going to go out and buy a new graphics card to run Linux either.

Pragmatism is all well and good - it gets the job done - but a pragmatist has no ideals.

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.

But if you want Linux to win then you'll demand code for your drivers.

Demand away. And what's this about Linux "winning"? What a juvenile attitude. It isn't a competition.

Re:So, what now?

[CristianoMonteiro]

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.

Re:So, what now?

[Catiline]

The reality of doing business for these vendors dictates [closing driver source code], however.

Quoting from Eric S. Raymond's essay "The Magic Cauldron":

If you are a hardware vendor, you may fear that open-sourcing may reveal important things about how your hardware operates that competitiors could copy, thus gaining an unfair competitive advantage. Back in the days of three- to five-year product cycles this was a valid argument. Today, the time your competitor's engineers would need to spend copying and understanding is a damagingly large portion of the product cycle, time they are not spending innovating or differentiating their own product.

This is not a new insight. ...[skip two examples]... Acceleration to Internet time makes this effect bite harder. If you are really ahead of the game, plagarism is a trap you want you competitors to fall into!

In any case, these details don't stay hidden for long these days. Hardware drivers are not like operating systems or applications; they're small, easy to disassemble, and easy to clone. Even teenage novice programmers can do this -- and frequently do.

There is no practical business reason for closed source drivers: it is a false sense of security in protecting the innovations that really don't have (or need!) much protection nowadays. Furthermore, since you have already achieved the full value of R&D money spent (by developing your product), there is no "loss" (as you put it, "giving their R&D budget to the competition") to account for. Indeed, in this view releasing drivers under a "mandatory sharing" license such as the GPL multiplies the value of said research as it allows you to gain more free (zero cost) research as those who would copy your R&D must release their alterations to your code.

Re:So, what now?

[Cyno]

Manufacturers? What about us consumers who have to deal with the lack of drivers or features? X isn't some trivial linux package, it is the heart of my system. Today without a video card with good X support Linux is basicly worthless as a desktop system.

I heard ATI had good X support, but half the cards I tried I couldn't get working properly, half the time I needed to use the vesa driver and get no video or 3D acceleration from a 3 year old video card.

This is just crazy. Its rather difficult to support an OS like this, but I thought it was all a lack of support or documentation to write the drivers. I hadn't heard the devs were holding drivers or becoming the bottleneck. I mean, c'mon, get some professionals to work on this already. Sheesh.

xwin- Quartz

[Anonymous Coward]

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!

Re:xwin- Quartz

[Enahs]

The DirectFB project has 2D going nicely, and is working on 3D. It's Linux-only at the moment, but that can change. :-D

Re:xwin- Quartz

[Overly Critical Guy]

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

Re:xwin- Quartz

[Jameth]

One: X is not a GUI. That's the field of KDE and GNOME. You can't blame X just because they suck.

Also, it doesn't necessarily need starting over: That'll just kill its potential on one front for the sake of more ease at reaching another. X has a lot of good features (don't bash remote Xwindows) and totally pulling out of it could screw up what support is already there. If it's fixable, it should be fixed, and I still think it is fixable.

Re:xwin- Quartz

[Man In Black]

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....

Re:xwin- Quartz

[FuegoFuerte]

Remote X is not as widely used as it is endlessly hyped to be.

Excuse me? I use it all the time. And that's just at home. Using my laptop for something? Pop up a display from my main box on my laptop. Makes things like keeping email synced so much simpler. Just use the same installation of the same browser. Forward X over SSH. Do all sorts of crazy and wacky things windows users can only dream about. Yes, the networked aspect of X is important. VERY important I'd say. If it weren't, why would Microsoft be trying to catch up to it? (RDP, anyone?) Yes, X has some issues, but the remote feature is one thing that absolutely should NOT go away.

Re:xwin- Quartz

[Metrol]

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.

Re:xwin- Quartz

[Ozan]

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!

Re:xwin- Quartz

[Overly Critical Guy]

"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.

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 .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.

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.

Re:xwin- Quartz

[Overly Critical Guy]

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.

Re:xwin- Quartz

[Ozan]

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."

Re:xwin- Quartz

[be-fan]

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

Re:xwin- Quartz

[be-fan]

Why the fuck does everyone thing that the remote capability adds overhead to X? X communicates via UNIX domain sockets (very fast in Linux) over a local connection. In Windows, GDI.dll communicates with the kernel via LPC (lightweight procedure calls, another form of IPC). For any of these mechanisms, shunting IPC communication to a remote connection is trivial and has no performance impact in the general case. Hell, even with COM, something much more low-level (which is based on C++ virtual function calls) network transparency has no performance hit in the local case.

Re:xwin- Quartz

[uchian]

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 ;-)

Re:Uh oh. . .

[dspeyer]

We're in the process of building community, from that we can construct a government.

Sounds kinda totalitarian to me. . .

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).

Not a surprise.

[mrsam]

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.

Re:Not a surprise.

[entrigant]

I, think, it just, may be, possible, that you are, overusing, commas. ;)

Re:Not a surprise.

[Anonymous Coward]

Uhm.. Is there any software that RMS doesn't drag his feet with? So far as I can tell, all the FSF/GNUware over there except for some with corporate connections like gcc and glibc are nice dust collectors with a few devoted GNUers who can't keep up.

IMO he's also really lucky that the egcs people were such nice folk and willing to re-merge under the 'gcc' name. I sure as hell wouldn't have, with the new restrictions it's imposed.

Things are much better now but GCC is still widely unappreciated and receives far too little resources. I've got bugs in there that are YEARS old, and I've even sent patches to fix some of them that have been flat out dropped into a void.

Just browsing the lists lately, it appears they are just NOW, after around 14+ goddamned fucking years, going to start using ANSI/ISO C89/90 in GCC instead of K&R C. Ugh, what a waste of their piddly resources.

What are their priorities?

[rossz]

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.

Re:What are their priorities?

[AtrN]

how often do you need remote xwindows

Every day.

Re:What are their priorities?

[ShadeARG]

Remote X is a lot faster than comparative solutions for Windows. VNC is horribly slow, almost unusable on a 100 Mbit/s LAN. It's alright if you drop your colors to 8bit or bgr233, but it is still horrid. X flies across my network at 24bpp and runs as smooth as the remote processor allows. Perhaps some decent compression would help here? I find remote X far too valuable to just throw out the window.

Re:What are their priorities?

[Dunkalis]

And here are some rebuttals to your points.

1. Performance. XFree is pretty fast for me, and while it could be faster, its still very usable. And I don't think network transparency really affects speed if you aren't using it, either. Locally, you're just using Unix sockets. It may add to the binary, and sit there and collect dust. I say that they add an option to disable network transparency, which is probably what you are talking about.

2. Standardization. This is not the point of X. Its a windowing system, not a toolkit or window manager/desktop. Everyone should use Qt, however :)

3. Easier Configuration. Most autoconfig tools like DrakXConf (or whatever it is) configures most hardware in a snap. And while the config files can be simplified, remember, its massive, complex and not some small project with two or three options. Its a freaking windowing system. Besides, how many times do you have to configure X, anyway? I just copy my XF86Config and replace it when I install a new distro.

Re:What are their priorities?

[arkanes]

Some rebuttals to YOUR points:

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.

Re:What are their priorities?

[Kunta Kinte]

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.

But what do you consider "decent". This is entirely subjective. Look, there are platforms out there that kick Windows butt very, very badly when it comes to performance. Some carry a premium ( Irix/MIPS ) others didn't ( BeOS ). MS still has a 90% monopoly.

How do you even know it's X is the problem?

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.

You couldn't be further from the truth.

Bro, It ain't a standard till you have multiple well tested implemenations that inter-operate. Granted X has had this for years, this fork does nothing to hurt the X standard either.

part 3 went over my head. sorry.

Re:What are their priorities?

[lewp]

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.

Re:What are their priorities?

[moncyb]

I went to xwin.org but could not find any type of list of what they hope to achieve.

It looks like they want to achieve extreme openness. They even put up Wiki, which means they're so open and carefree, they must emulate the goatse.cx guy. ;-)

I think the place to put your requests is WantonDesires. I think you have to register, though IIRC some Wiki sites don't require it, so maybe not. (I haven't used Wiki much.) It may be a good idea to learn how Wiki works first though...in some ways it's easy to use, but there are specifics you should understand. For example, the formatting has different rules than html. The HelpPage is a start.

As to your ideas, here are my thoughts:

1. It may be possible to optimize XFree some, but it sounds like you don't want XFree, but something else. Taking out the socket based communications would not only remove the remote abilities, but it would also reduce security.

   You are probably thinking something along the lines of DirectFB and XDirectFB. Programs use those libs to access the framebuffer device directly. From what I understand, you have to open the permissions on your framebuffer device or just run all your programs as root. Not good if you need decent security (or protection from a buggy program)--this is almost like running Win98. ;-)

2. I think there are arguments for and against enforcing specific standards, but I think most of the problems are either caused by applications not using X properly (it seems too many developers don't understand X, Unix, or even makefiles at all) or are outside the realm of X itself. I also think GNOME and KDE are unnecessary for the most part. They have probably caused a greater rift in standards...

3. Hardware configuration has always been a problem, not only for XFree86, but many other systems. PCI should help solve the problem. The PCI bus gives a vendor string, so determining the hardware you use should be easy. You'll need a massive database, but it should work. Same with USB. I wouldn't be surprised if they already have PCI and USB autodetect functions in xf86cfg, but I don't know because I manually edit my XF86Config file. I'm anal. ;-)

Re:What are their priorities?

[rsidd]

how often do you need remote xwindows

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.

the usual misconceptions

[g4dget]

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.

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.

Re:the usual misconceptions

[geekoid]

yeah, I loved the "rip ot the fluff" comment. Like there has been this pile of un-needed code that nobody ever noticed.
"Hey guys, look at this, there has been flight similator code in here!"

Re:the usual misconceptions

[horster]

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.

Re:the usual misconceptions

[spitzak]

The horrid resizing behavior is due to the seperate window manager. There is absolutley no way to get a smooth update when two competing programs are resizing different parts of the display and there is no protocol method to say "don't draw this until this other thing happens".

The solution is to put the window manager into the toolkits like the buttons and everything else is. The result will be *better* than Windows, as Windows puts it in the server so there still is communication and it is impossible to do complex restrictions on the size of a window (such as a range of ratios or multiples of certain sizes) Windows also it relies of sending an event through the user program to synchronize the window changing size and the drawing, otherwise it would look as bad as X, but I don't recommend this route at all, just put the window borders into the user program.

The problem is that a thousand sheep here are going to bleat "but that will make it 'inconsistent' and it will 'confuse the user'". This naive response from so many is probably the most serious problem we are going to have in trying to fix X. Truth is: NOBODY is "confused" because the buttons are different colors, they are confused by crap interfaces! And the great Windows DOES NOT enforce lots of things (such as what shortcuts are used for menus) that people keep complaining about when they say that "windows is consistent and Linux is not". The truth is that "consistency" is the responsibility of the application programmers and trying to force it by making complex and slow interfaces so your favorite GUI method is forced on everybody is absolutely the WORST thing you can do.

Dragging windows (not resizing) does not have problems with the seperate window manager, so it is obvious that a lot of X programs do not respond to redraws very quickly. Some Windows programs have this problem too, but I would agree that not as many as Linux. Both X and GDI32 drawing engines suck almost equally badly so the amount of code in the app is about the same, and tests where lots of letters or rectangles are drawn indicate that GDI32 and Linux X are about equal speed. 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.

Re:the usual misconceptions

[g4dget]

I'm sorry but I don't get your point. Keith's paper is about X network performance. When you use X11 locally, it doesn't go over a network. It doesn't even go through the TCP/IP stack. Instead, it goes through a UNIX-domain socket and shared memory. The whole reason why X11 uses bandwidth fairly inefficiently is because its designers have always considered local usage and usage over a fast network to be of paramount importance: compressing the protocol more would have required more CPU overhead, and hence less efficient local performance.

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.

Re:the usual misconceptions

[be-fan]

Um, they were testing network communication here. They found out that network performance was less than optimal because of various reasons. It had nothing about local cases.

Re:the usual misconceptions

[Overly Critical Guy]

Ever tried developing for X? It's a huge, towering bitch that looks like an inside-out Jabba The Hutt.

Re:the usual misconceptions

[be-fan]

You can't. There are problems somewhere in the chain, but it's not in X. Far more common is poorly optimized applications. For example, right now I'm using KDE. Certain applications, even very widget-heavy, complex applications like Qt designer, resize very smoothly. For example, on my GeForce4Go, copying a 500x500 pixmap to a window (x11perf -copypixwin500) can be done at 2300 fps, or about 575 megapixels per second. For a general purpose display API, that's really fast, about 1/3 the total memory bandwidth of the graphics accelerator. But when resizing KDE Kontrol Panel, the image, not much bigger than 500x500, redraws at maybe 4 or 5 fps. The problem is not the raw speed of X, but how the application responds to resize requests. A great many X apps have the problem that they handle resize events very poorly, so when users who are just trying to Linux for a short-while try to test speed (by doing the usual resize window-quickly "test") they get a very misleading impression. Meanwhile, users who use the system all day (and almost never resize windows in that manner) don't notice stuff like that and wonder why anyone things it's slow. Another example. When I open a menu in Konqueror, and start the settings panel, the menu will sometimes go away and the area underneath won't redraw until almost a second later. The redraw is the matter of a single bit-blit. We've already established that X can do those really quickly. The problem is not that X isn't fast enough, but the application is trying to load the settings panel (waiting on the disk usually) and isn't responding to redraw requests in the meantime. There are ways to fix these problems:

1) Add some synchronization between apps and the window manager, so they resize smoothly. OS X has something like this: the window frame won't resize faster than the window contents can redraw. Since Quartz in general is little slow (because all drawing, even in QE is done in software), this leads to very jerky behavior, but is much more "elegant."
2) Multithread apps. This is the big one. A properly multithreaded GUI can respond to high-priority user events without being blocked on low-priority I/O events. It was only recently that Linux got threadsafe GUI libraries (Qt 3.x and Gtk+ 2.0) and large parts of KDE still aren't threadsafe.
3) Optimize drawing routines. Take Konqueror vs Internet Explorer. Try doing the "resize" test on the two. Each frame of resize animation is very time consuming. Thanks to CSS and other modern HTML, the *entire* page has to be laid out each frame. The algorithms for doing this in IE are much more mature than the algorithms for doing the same in Konqueror.

Re:the usual misconceptions

[g4dget]

The solution is to put the window manager into the toolkits like the buttons and everything else is.

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.

Re:the usual misconceptions

[aardvarkjoe]

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.

Re:the usual misconceptions

[g4dget]

Latency in dragging windows can be handled by a call that attaches a window to the cursor so it is dragged around until the mouse is released.

We are not talking about opaque moves--current windowing systems, including X11, handle those just fine by bit-blitting.

I can't think of any good equivalent solutions for resizing,

That is because there isn't any. In the simplest case, which you are thinking about, the user decides how big the window is going to be, by using the mouse. The GUI communicates the new size to the application, the application sends back the updated appearance of the window. One round trip.

I think it should be left up to the program and there will be latency. However as the program can say "resize the window to this" and immediately follow it asynchronously with the new image for the resized window, there will be much less latency than the current version where the window is resized by the window manager and there has to be at least a round trip to the program to get the new drawing.

That doesn't help. The user determines how big the window is going to be and the window has to follow. The application can't just pick a size preemptively and send out redrawing commands for that--if you can see the latency now during redraws, you would see the latency then because the window size wouldn't follow your mouse.

Furthermore, it's a fundamental policy decision under X11 that applications don't get to say "resize to this". That has less to do with usability, and more with being able to use the same programs on a very wide variety of displays: programs simply don't know about all the possible displays and environments to be able to do window management correctly. Putting window management into clients is fundamentally broken, and it would be a huge step backwards for X11 to do that without helping with anything (in fact, I pretty much guarantee it's not going to happen).

Of course, you are free to try this under X11: if you like, your toolkit can resize its own window. You are even free to override the window manager altogether. So, the functionality is already all there, but thankfully, no major toolkit uses it. Just don't expect people to use your application a whole lot if you do that. The few applications that try this (xmms, etc.) are a big pain to use on displays that don't satisfy the assumptions that their author had in mind.

The drawing code definately should support display lists, though I don't think much of the complex structure is needed, because *some* communication is acceptable. A program that draws a hundred buttons of different sizes should be able to send a display list that can draw a button once (keeping it in the server much like an X pixmap) and then send on redraw it just has to send the rectangles and labels of all the buttons and the command to run the display list on each of them.

Well, as I was saying, X11 is getting support for that. That's nice for all sorts of reasons, but it will not solve the problem in general because once you have a round trip, you have latency, even if you only send a little data. What it will do is let the server generate a resized image that's pretty close for normal mouse movements, until the application gets around to redrawing things. It will give the illusion of smooth opaque resizing.

But, then, the server could probably already do that with bitmaps: you resize the window and the server does smooth bitmap scaling to fill in until the update comes from the client. For the 200ms that's going to be on the screen, it's going to look just fine.

But let's keep our perspective here: GUI toolkits are not written for letting animated widgets dance around the screen in real time, they are optimized for mostly static displays. That's a deliberate design tradeoff, and one that meets day-to-day needs well. The only place where that kind of animation occurs during normal usage is with opaque resizing. I don't think it's worth putting a lo

fud fuel?

[Anonymous Coward]

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.

Remote XWindows

[grolschie]

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).

Re:Remote XWindows

[hankaholic]

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?

Re:Remote XWindows

[Anonymous Coward]

Y'know, I've never given it much thought - but I'm running running on LTSP (http://www.ltsp.org) which is the Linux Terminal server project.

I've got a server which is relatively beefed up, and then have 486/586 machines scattered around the office. If one of them break down.... junk 'em.

As far as response time is concerned.... well, the terminals have 64MB, the network is 10/100, approx. 30% have sound (depending on whether I could be bothered enough giving the user that option), and everything opens extreeemly fast (except OpenOffice - but I keep an instance of that running on the server anyway to increase startup).

The cost? Well, in terms of modern IT budgets - nothing.

X without remote would kill my whole setup. I think the (likely) fork is a good thing, if for nothing else than shaking things up, but don't touch my remote....

All IMHO etc. etc - usual disclaimers apply.

Deja Vu: History of GCC and the ECGS

[NZheretic]

The ECGS fork of the Gnu Compiler Collection ( GCC ) was formed in 1997, because many felt that developement of GCC was not going fast enough and that the then GCC developer were not accepting or adopting mnay freely contributed patches that radically changed the then stable GCC toolset.

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

Lingo.....

[telstar]

"Weeks, not months."

• Sounds like how this whole Iraq thing went down. Should we expect the shock and awe phase shortly after that?

X works great for me

[b17bmbr]

what exactly does X lack? please. i have been using it for several years, and it has improved immensely, yes, but i have never had any problems with it. as forthe network thing, i use it in my classroom every day. i have a p3 serving up X to several boxes in my classroom, and not only has it never crashed, but it runs very fast over a 10/100 lan. why all the bitching? i don't get it.

Re:X works great for me

[SlickMickTrick]

Under Mac OS X 10.2, start playing a DVD. Check your CPU usage.

Now make a terminal semi-transparent. Drag it over the top, and watch the DVD play through.

Check your CPU usage. It hasn't changed.

My linux XFree-based desktop can't do that.

I think the future of linux desktops may lie with DirectFB and their rootless X server. All the remote functionality/backwards compatibility, only with a new, clean, and clever rendering engine.

May I say, I am constantly using Apple X11. The X protocol is great, and despite what some say, perfect for a practical world. It's just the XFree86 engine that's showing its age.

Effects on Gnome, KDE, Window Managers?

[billstewart]

So how much effect is this split going to have on the KDE - vs - Gnome toolkits and the various window managers out there?

Re:Effects on Gnome, KDE, Window Managers?

[spitzak]

Having written a toolkit I can tell you that it takes far *MORE* code to talk to a window manager than it would take to draw the window borders myself (remember that the toolkit already has to draw buttons so it has the code to draw the beveled edges). The "window" object in fltk is easily more than twice the size of the text editing object.

And no matter how much code is added, I still can't get the interface to work correctly, for instance to stack the windows in the order I want, or to cleanly make a full-screen window, or to allow the window to be dragged or resized by grabbing some point inside the window. All of these would be trivial if override-redirect windows were used by all applications.

Also you said "GTK window decorations would probably look much different to KDE ones to any other TK out there" which is exactly what I expected. It took only 10 minutes for somebody to blurt out the "oh no it's inconsistent and will confuse the user". Let's try it and see rather than parrotting this crap. Somehow must people can push a button in both a KDE and Gnome app despite the different appearances...

Re:Effects on Gnome, KDE, Window Managers?

[be-fan]

Check out their statement:

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. :: signatures clipped ::

First Lie Post

[Lord Sauron]

This is another American lie. Keith Packard, American official, is NOT free, he was easily subjugated by our dauntless troops. And he possessed not a fork, but a knife of mass destruction.

Note: I rewrote this message because some infidelic moderator modded it as offtopic. But I have no fear. Will trench my post and resist to the negative mods.

Remote CANNOT be an "option"

[spitzak]

This seems to be a common request here but it is wrong. X can use a number of protocols to update the display, it is possible to write a program were everything is done in client space. In current implementations of Xlib the fact that the display is local is detected and large amounts of code is swapped so that it talks to the server using very efficient mechanisms. So in a way "remote" has already been removed and is an option.

The remote ability of X does force design decisions in the protocol and interface, but you cannot remove these, because you would make "remote" impossible. Then you would have two display interfaces, one for local and one for remote.

You could make an argument that these design decisions are hurting X and that "remote" should be completely eradicated. That would be a logical argument (though I personally disagree).

But saying "remote should be an option" as though that is a physically possible solution is just wrong.

Let's see...

[Erik Hollensbe]

....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.

Re:-1, Fundamentalist

[nathanh]

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?

Yep!

[Skreech]

I use it every day too. I had a decision to make. I wanted to play games that came out and run misc Windows programs reliably. I also wanted to have a stable platform where I could store my email, have xchat up, have various persistant processes running (for 120+ days of uptime now).

So what was I to do? Get Linux and install wine? If I enjoyed pain, sure. Or: Get Windows and run a webserver, mail-fetching programs, Python for windows, xchat for windows, blahblahblah for windows? No, I need a Linux environment, not just some of the applications that happen to be compilable under win32.

I made two computers. Linux box is headless, Windows box is not (of course). Installed windows, installed cygwin, installed XFree86 on the windows machine (easy, cygwin package), got remote login to work. Presto, Windows and Linux co-existing the easy way. The only improvement would have to be a seperate monitor and keyboard, but that takes up physical space.

how often do you need remote xwindows

More like, how often do I need local xwindows? My answer is "never." Don't treat remote windows like it's a party trick. I'd say it's the most important feature, period!

Other important news

[MrNop]

Carsten Haitzler (The Rasterman) from Enlightenment project started to work on XCB !
XCB seems to be the super fast replacement of Xlib keeping X protocol ...

More infos

development guides

[BenjyD]

One major thing that seems to be needed is a detailed, up-to-date guide on how to develop fast graphical apps for xfree86. So many comments here saying "X is slow" are followed by comments blaming the toolkit/app developers.

A set of guidelines for modern xfree86 on how to get the best performance would help a huge fraction of the open-source world and improve the appearance of Unices on the desktop.

As a long-time UNIX user...

[squarooticus]

...what I would like to see is BOTH a local DRI (perhaps using SHM) AND continued network transparency.

Aside from that first time running Linux Doom over the network back in 1994 just to see how slow it would be, I have never had the desire to run a bandwidth-intensive X application over the network.

Yet, I still use X applications remotely, day after day---XEmacs, xmms, xterm, you name it---and I'm not about to stop.

Come to think of it, we already HAVE the two things I've listed above, so in fact, I'm already happy. Half-life under Wine plays frickin' fast, as does the native version of Wolfenstein 3D, and I can still run my other apps remotely.

I'd still be interested in seeing what Keith comes up with.

Finally, it sounds to me (from the older article that was linked to above) like David can go fuck off: if he doesn't use X anymore, then he should give up his spot on the XFree86 steering committee to someone with a stake in XFree's future. At a minimum, this should be someone who uses the damn thing!

Go, Keith! Some of the best applications in existence (XEmacs, gcc-3.x, and XFree86 itself) were adversarial forks.

Cheers,
Kyle

US Patents!

[Fefe]

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.

They Key Is....

[tenchiken]

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.

Re:This will be the end of X

[Adnans]

Once you get an incompatible fork it will loose that and fall into total disarray

This is not going to be the case at all. The "fork" will adhere to all the current standards. It will just be possible to develop different parts of the systems at a faster pace. It's also supposed to get us new goodies, that are build on the standard protocols, faster, and that's a good thing for the OSS cycle (hack, release, feedback, hack, release, ...ad infimum).

Have a little faith, xwin is in good hands. The xwin people are mostly responsible for the cool new stuff we're using right now anyway.

-adnans