Keith Packard's Xfree86 Fork Officially Started 578
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."
So, what now? (Score:3, Interesting)
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
Oh, and, FSP? (first substantive post)
Re:So, what now? (Score:5, Insightful)
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? (Score:3, Interesting)
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 suppo
Re:So, what now? (Score:3, Interesting)
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? (Score:2, Interesting)
Re:So, what now? (Score:5, Insightful)
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? (Score:5, Interesting)
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
Re:So, what now? (Score:4, Insightful)
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? (Score:4, Insightful)
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? (Score:5, Insightful)
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? (Score:5, Insightful)
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? (Score:3, Interesting)
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 ma
Re:So, what now? (Score:4, Insightful)
I would have thought that was blindingly obvious. It makes the system far more viable and attractive for many people. Video drivers are often a make or break deal - Linux doesn't support your graphics card? Linux doesn't get installed.
As I recall, the primary complaint against BeOS was that it lacked drivers. When they made BeOS free, I would have tried it out, but it wouldn't even have been able to connect to my ISP (it lacked CHAP authentication, I think). You want the same complaint levelled against Linux too?
No. People don't install Linux so they can fire up their favourite text editor and look at the source. They install it to get something done.
Now, the open development model greatly increases the rate at which Linux improves - which is responsible for the features people use to get something done. But the second Linux doesn't get things done for people, it'll be thrown out for something that does.
If you take a look at Linus' policies, you will find that he is essentially pragmatic. He recognised the need for binary-only kernel modules, he also made it clear people using them were on their own, and the kernel hackers will not touch tainted bug reports.
It might not bother you, but video drivers are a make or break deal for a hell of a lot of people.
Bollocks. They are just ideals you don't like in this situation. Namely, it's better to have a system that is 99% Free and works very well for people, rather than a system that is 100% Free and works adequately for a small number of people.
Demand away. And what's this about Linux "winning"? What a juvenile attitude. It isn't a competition.
US Patents! (Score:3, Insightful)
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
Re:So, what now? (Score:5, Insightful)
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.
Re:So, what now? (Score:4, Interesting)
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? (Score:3, Interesting)
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 il
Re:-1, Fundamentalist (Score:3, Insightful)
Re:So, what now? (Score:3, Informative)
The reality of doing business for these vendors dictates [closing driver source code], however.
Quoting from Eric S. Raymond's essay "The Magic Cauldron":
Re:So, what now? (Score:2)
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.
Uh, hasn't this already been done, as of XFree86 4.0?
Re:So, what now? (Score:5, Informative)
Re:Binary drivers? (Score:4, Interesting)
Re:So, what now? (Score:4, Informative)
The libc/glibc difficulty wasn't, precisely speaking, a fork. Linux used to use its own C library ('Linux libc' or 'libc'), and after a while the Linux developers decided to switch to using the GNU C library ('GNU libc' or 'glibc'), and Linux libc was abandoned.
Re:So, what now? (Score:4, Informative)
It's more complicated than that. Linux libc (libc5, and earlier libc4) were derived from GNU libc1 (1.07.4 according to this site [uclibc.org]). Linux libc then evolved separately while people worked on glibc2, and when glibc2 became usable, first Red Hat, then the others, started to use it as the default libc, and libc5 was abandoned. So, yes, libc5 was a fork, a purely utilitarian one which eventually became a dead end (unlike egcs which became the new gcc).
Re:So, what now? (Score:5, Informative)
Why dont they allow donations? (Score:2)
Why dont they accept project specific donations? Hell even freenet accepts donations and Xfree the most important of all the current linux projects wont accept donations?!
Ok, so they complain theres not enough developers, development seems to go at snail pace, I see the project and only Carl and Keith are working on it, so while they work on that what happens to Xrender?
See whats going on here? We need more developer power to build Xfree at the same speed KDE and Gnome are being built. When freenet devel
Meanwhile... (Score:5, Funny)
> 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.
Meanwhile, have patience with the looting and plundering...
Linked to today on OSNews (Score:2, Interesting)
Maybe we'll finally get a decent version of X instead of these whiny "don't criticize things even though we put this stuff out for the public" volunteers ignoring patches and stagnating things.
I know there are people who will reply saying nothing is wrong with X, or making long lists of excuses justifying things about X, or saying they've never had problems with X and that all these "sheep" who say X is bad are stupid and ignorant. I simply disa
xwin- Quartz (Score:5, Interesting)
Re:xwin- Quartz (Score:5, Interesting)
Re:xwin- Quartz (Score:5, Insightful)
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 (Score:2, Interesting)
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 (Score:5, Informative)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
>>>>>>>>>>
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 (Score:5, Informative)
Re:xwin- Quartz (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:3, Insightful)
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
Lots of people have already done that (Score:3, Interesting)
Re:xwin- Quartz (Score:4, Informative)
Not a surprise. (Score:5, Insightful)
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. (Score:3, Funny)
Re:Not a surprise. (Score:4, Insightful)
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? (Score:3, Insightful)
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? (Score:5, Insightful)
Every day.
Re:What are their priorities? (Score:5, Informative)
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.
Yep! (Score:3, Interesting)
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 environm
Re:What are their priorities? (Score:2, Insightful)
Re:What are their priorities? (Score:2)
VNC is *okay* but it doesn't have the robustness of ICA.
Yea, I know, ICA isn't free; but that doesn't make it no good.
Re:What are their priorities? (Score:4, Insightful)
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? (Score:5, Informative)
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? (Score:3, Insightful)
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
Re:What are their priorities? (Score:2)
And on the whole X speed thing, I'd like to point out that the GUI on SGI's Irix machines is X11, and it's certainly fast enough. A couple of years back I remember a day when I used a then-ancient SGI Indy (133mhz cpu) running X11, a Sun workstation running X11, and a Win2K box in the space of a few hours, and the X11 boxes wiped the floor with Win2K on GUI responsi
Re:What are their priorities? (Score:2)
2. This is not xwindows' job. Gui differences are at a higher level than X.
3. I agree with you here.
the usual misconceptions (Score:5, Informative)
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 (Score:3, Funny)
"Hey guys, look at this, there has been flight similator code in here!"
Re:the usual misconceptions (Score:3, Insightful)
Re:the usual misconceptions (Score:5, Informative)
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 (Score:3, Insightful)
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)
Re:the usual misconceptions (Score:3, Informative)
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
Re:the usual misconceptions (Score:5, Insightful)
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 (Score:5, Informative)
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 (Score:5, Insightful)
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 (Score:3, Informative)
Re:What are their priorities? (Score:2)
Look at the nasty way that remote X works, just for an example. To tunnel remote X over some other protocol, you have to do some serious programming to support it's unusual methods. Meanwhile, with something like VNC, or Citrix, all you have to do is tunnel a single port. Also, it would be nice if X had a higher-level interface to it, so that you don't have to, essentially, send a video over te network to disp
Re:What are their priorities? (Score:5, Insightful)
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? (Score:4, Insightful)
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 [xwin.org]. 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 [xwin.org] is a start.
As to your ideas, here are my thoughts:
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. ;-)
Let the debate begin. (Score:3, Insightful)
The licencing debate.
Is it going to stay X11 or will it be moving to another licence?
Re:Let the debate begin. (Score:4, Insightful)
BTW, vi is better. Emacs sucks.
what about VNC (Score:4, Insightful)
In my experience there are different situations that one wants an X-terminal. One is where one has a highly networked user space and one wants a high fidelity graphical experience no matter where the computer you are executing on is physically located as long as its a high bandwidth connection.
In my owm personal world of some 600+ linux servers spread around the united states, I dont need nor can a support a decent X graphics experience. In fact W is intolerable even on many local connections. Instead I find I get much better performance using VNC as my remote graphical interface. Its fidelity is slightly lower but its lightning fast and works in all sorts of situations where X is painful (like double firewalls and high security environments). The crititical thing is the response time of the mouse when doing things like menu pulldowns, and for example draging a 3-D rendered object to rotate it on the screen.
I dont know why but X is horrible for thos operations. while VNC is fluid. VNC is also more stable when connections close down unexpectedly or even expectedly (like I put my local computer to sleep).
so my feeling is the existing X works damn well for high bandwidth connections and local stuff. if there's an argument over its direction its arguing over minutia. what really need to happen is to evolve an X for low bandwidth connections. In theory X should be much faster than VNC since it should be able to send less information than VNC has to. but currently its not up to par
Re:what about VNC (Score:2)
they're both needed. (Score:5, Informative)
This solution is terrible in the thin client scenario. And that may be one of the reasons that thin clients haven't taken off in places were using that approach would be a no-brainer ( call centers, college labs, etc. ). Large number of identical machines that wouldn't need maintaince other than to reinstall the OS and the remote desktop application.
Framebuffer solutions place all the rendering, font handling, *everything* on the 'remote server' or 'RAS' ( you pick ).
If you get a chance to observe a citrix or terminal services rollout, ask for the specs on their servers, and how many users can fit on those. It's almost not worth it.
XWindows is much, much easier on the 'client' Without even trying, as much developers aren't taking into consideration X protocol Server/client roundtrip issues when designing/coding.
If you just what to get to your computer, a framebuffer may perform slightly better than X, though X would still do a good job. But in the case of a large number of users connecting to a single server, each with their own session, X is *much* better.
Re:what about VNC (Score:3, Informative)
Yay (Score:2)
It sure beats having but one graphical server to choose from. It also beats having a bloated GUI tied into the kernel that you have no control over.
On a split being good (Score:5, Interesting)
I was reading this paper that Keith Packard and James Gettys wrote and its plain he has a clue and are really interested in concentrating on performance.
http://keithp.com/~keithp/talks/usenix2003/html
The paper deals with network performance, but it was the "lets be practical "methodology that impressed me and it seems they are really on the road it finding solutions for speeding up X and also in many cases the popular X toolkits themselves.
Not to mention the "cool" stuff that Keith has done.
This fork isn't bad, its about time.
I say it now: XFree is Dead (Score:5, Insightful)
I predict in a years' time XFree will be pretty much stagnant at the codebase it's at now, but will have a couple of releases just to make themselves look like they're still relevant. Meanwhile we'll all be fighting with instructions in how to strip out XFree and replace it with KP's xwin, and the linux desktop movement becomes the big loser. Sigh.
Re:I say it now: XFree is Dead (Score:3, Insightful)
I wonder if XCB and XCL are related to this projec (Score:4, Informative)
I noticed that both XCB and XCL [pdx.edu] and xwin are sponsored by Portland State University.
For those who are too lazy to click on the link XCB stands for X C bindings and meant to replace Xlib. The main point is to make X clients to talk to X server asynchronously (unlike Xlib) which will beinifit the speed. For compatibility they still keep XCL (Xlib compatibility layer). In fact these projects created quite an excitement [sourceforge.net] on enlightment-devel mailing list. Well, at least Rasterman [rasterman.com] is excited.
Overall, i think, this might turn out very poisitive for all of us.
Re:I wonder if XCB and XCL are related to this pro (Score:5, Informative)
Doesn't sound like a fork yet (Score:4, Informative)
Hopefully, whatever happens, X development will improve. We'll see if it winds up being something other than XFree86 in the end.
How can we donate money to individual projects? (Score:2)
I want to donate maybe $30, but I want to donate my money to a specific projects development, in a democractic way.
I think if X team is going to accept donations, it should work something like how transgaming works. Can you set it up so certain projects can accept donations, like maybe Xrender, and our money gets used to hire full time programmers to work on it?
With donation money, there wont be such a problem finding developers.
I will pray that... (Score:3, Insightful)
Just my thoughts, best of luck to the project!
fud fuel? (Score:2, Insightful)
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.
Deja Vu: History of GCC and the ECGS (Score:5, Interesting)
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 [gnu.org]
Lingo..... (Score:3, Funny)
X works great for me (Score:3, Interesting)
Effects on Gnome, KDE, Window Managers? (Score:3, Interesting)
Re:Effects on Gnome, KDE, Window Managers? (Score:5, Informative)
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.
Re:Effects on Gnome, KDE, Window Managers? (Score:3, Interesting)
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 fu
First Lie Post (Score:4, Funny)
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.
Comment removed (Score:4, Insightful)
development guides (Score:4, Interesting)
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... (Score:4, Interesting)
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
They Key Is.... (Score:3, Insightful)
New technology is cool. Better configuration is manditory. I am looking forward to see how this plays out.
Re:Uh oh. . . (Score:5, Interesting)
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).
Re:unification (Score:5, Insightful)
Allow me a small story here friend, as to why I don't agree with your stance.
Once upon a time, there were 2 racing teams. Once was rich, one was poor. The rich one was dedicated to winning at all costs, and kept all of thier knowlege and glory to themselves. The poor one wanted to win too, but only really wanted to make a car go fast - winning was secondary. They would share what they learned and spread it around to all of the racers - including the Rich team.
When the rich team came into the racing league, they were slow. But they learned from the Poor team, and took what they learned and raced hard all of the time. They built newer cars, faster cars, better cars than they had. The poor team was too interested in maintaining the status quo - they would only tweak what they had, never really delving too deeeply into the whole package they raced. They started to notice the the Rich Team was gaining on them way to fast, and got worried.
Eventually, one of the members of the poor team suggested that they scrap some of thier methods - more or less gut the car and re-build it, eliminating some of the old weight it was carying around, and integrate newer, better technologies. The rest of the team scoffed at this - "We're doing rather well with what we have now. We don't need any distractions while we're dealing with the Rich Team - be quiet, please." The team member who spoke up realised that dealing with the Rich Team was in reality the distraction, not his wanting to re-build the car so it was at it's best and fastest. Winning was secondary (though he really wanted to win, too). So, he quit the team, and trundled off with one of the Poor teams backup cars, and proceeded to gut it.
When he showed up on the first race day, he was hardly noticed. His car sputtered, it smoked, it didn't run right. Next race he was better. He gained new insights into how to make the poor teams cars work better. He got faster and more reliable still. By the 7th race, he was doing faster laps in an un-painted car than the Poor team was in thier tried and true one. The leader of the poor team - who was in the fight of his life with the Rich Team by this time - came over and asked how he got so fast so quick. The leader was shown what was done to the car - and he learned too. "Hey, we can do this - and quickly, can't we? BTW, if you just adjusted this over here this way..."
With thier passion for going fast renewed, and thier focus restored to where it should be, the Poor team was re-joined, having been made stronger for the split. The Rich team was now the team quaking in fear...
So, friend, IMHO sometimes splitting resources is a good thing in the end. It's all about perspective.
Soko
Re:Remote XWindows (Score:5, Insightful)
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?
Remote CANNOT be an "option" (Score:4, Interesting)
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.
Re:This will be the end of X (Score:3, Insightful)
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,
Have a little faith, xwin is in good hands. The xwin peop