Slashdot Mirror
XFree86 Fork Gets a Name, Website
Piethein Strengholt writes "Today the Xfree86 fork is a fact. A new project has started and is located at: xouvert.org. Xouvert has been started due to the corporate structure and the slow development of XFree86. They hope to reduce the risk to XFree86 of incorporating new drivers and features."
If they're trying to include useful third party contributions, they could do worse than include NX, a revolutionary new compression and proxying technology that makes it possible to run an X session over a 9600 modem at a useable speed. But I didn't completely understand their policy on licences (the NX infrastructure is GPLed, whereas X is under the MIT licence).
perl -e 'fork||print for split//,"hahahaha"'
"ouvert" means "open" in French.
See my previous comment on NX compression. I'm typing this on Galeon running at work, displaying on my home computer over a 56K modem, because it's faster web browsing like this than running the browser locally. NX has to be seen to be believed.
The interesting thing is, this level of compression is only possible because of the high-level nature of X's network transparency - Citrix / RDP / VNC doesn't run anywhere near as fast.
perl -e 'fork||print for split//,"hahahaha"'
Frankly, it may be worth jettisoning a lot of the XFree86 baggage and starting anew.
Y, an X Windows replacement, looks extremely well designed and this guy wrote a pretty complete implementation for his thesis.
Why not port the useful bits of X - like the hardware drivers - over to this already-established well-designed base instead of trying to hack XFree86 into something of similar quality?
(Well, the obvious answer, ``to keep the applications`` is fair enough. But a compatibility module wouldn't be too hard, and worth the benefit in the long run.)
My biggest worry about this fork was that the developers were going to announce a "practical" approach to drivers, one that would include non-free drivers etc.
From the website:
"All code that enters the project is under the standard X11 license, or compatible free license as specified by the Free Software Foundation"
Public mailing lists should have been the method of communication for the xfree developers right from the start. This is great news. The use of Arch as the version control system is iceing on the cake.
Ciaran O'Riordan
Expert in software patents or patent law? Contribute to the ESP wiki!
It doesn't affect it. The people that believe that the X protocol is hampered by network transparency are wholly ignorant of how windowing systems work. Much of the perceived "slowness" of X programs are solely within the domain of the toolkits, themes, and applications that use them. All windowing systems use IPC for communication with the windowing system. Unix domain sockets are not exactly a burden with this regard. However, if one of the ignorant supporters of the removal of network transparency could be bothered to simply implement IPC over a different mechanism (quite possible), they would notice this.
I applaud this initiative. Might be what X needs to get back to life. A bit of competition always sounds like a good thing.
But if they are really serious at encouraging developpers to join this project, the first sensible thing to do would probably be to forget about the IMake crazyness that has been used for years by XFree86 and switch to something else for building the whole project.
Replacing it by the autoconf/automake mix would make the source tree much more appealing to potential developpers. And just to back up my claim, someone else also made the same comment on the xfree-xpert mailing list a few months ago:
(...)
[ I also hope that somebody with more drive than I have will some day decide that the X Makefiles are such a mess that they'd be willing to get rid of all that horribly broken imake crap and just fix them. What a broken build system! ]
Linus
(...)
Just my 0x02 cents...
It doesn't matter whether the name "sucks" or not. Does it matter to users? No: they don't actually care! Heck, they shouldn't even have to care. All they should know is that it works.
Does it matter to distributors? No: if Xouvert is good, Linux distributions will include it, no matter whether the name "sucks" or not.
Does it matter to developers? I don't think they, they care more about the code and the openness of the projects.
So, where is the problem?
"Of course, 'Vim' and 'Emacs' aren't exactly stellar examples of naming"
Vi and Emacs are not popular outside the Unix commandline community because they're console apps, not because of their names! You can rename Emacs to "PowerEdit 2000" but it's marketshare won't change!
The name is certainly not the most important thing. Many people say that Ogg Vorbis will fail just because of it's name. And what do we see? More and more MP3 player manufactures are adopting Ogg Vorbis. And again: users don't care. If they can use the technology easily, they will, no matter the name.
"Bascially an X server that has been stripped of all the features that the "average" person doesn't use, such as running remote desktops over networks and things."
Urgh, not this again...
The slowness is not caused by network transparency!
Locally, XFree86 uses a Unix Domain Socket for communicating with it's clients. On Linux, that's just as fast as shared memory. That's as close as you can get to not having network transparency.
Writing directly to the videocard's framebuffer is not "the modern way", it's "the 60s" way. Modern apps don't access hardware directly anymore: they do that via abstraction layers like the kernel. These abstractions don't necessarily degrade performance. But the most important of all, these abstractions provide portability and make sure that multiple applications don't conflict with each other (like, 2 apps trying to write the same hardware at the same time).
And dropping network transparency will piss off a lot of people, including corporations, and including Slashdot!
Look at GNOME: at version 2 they took a new path and are now walking towards simplicity. They're now aiming the average users instead of geeks. And what do you see? Slashdot geeks are massively upset about this because GNOME is not targeting them anymore!
In other words, even if you drop network transparency, Slashdotters won't stop complaining. I suspect that more and more people will by then start crying about putting back network transparency. And when Microsoft or Apple puts support for network transparency natively in their windowing systems, Slashdotters will suddenly complain that we need network transparency in order to succeed on the desktop!
I don't know about the djb tools, having never used them, but as far as the GNU tools go, I couldn't agree more.
I think my favorite part of the autoconf documentation is the part where it touts using the m4 macro system, claiming it is quick, and easy to learn. Maybe it is. I don't happen to agree, but that's not really even the point. When you're writing GNU build files, that it's m4 is only incidental; you're really writing into the autoconf/automake macro API and it's one of the most byzantine, insensible tools I've stumbled across.
Not to mention how much I love having to wonder if I need to look in Makefile.am or Makefile.in for something. Or maybe aclocal? Or hey, where did that autogen.sh file come from? Wait, no, maybe it's config.h? Now, was it automake before autoconf? Did acmkdir work right, or am I just confused? Why doesn't it know what LF_CPP_PORTABILITY means when it's right in the documentation? Oh shit, I must need to run reconf. And didn't I read a paper titled "Recursive Make Considered Harmful" somewhere? Then why is it so hard to not use these directories? And why will it completely fail if I don't have internationalization support, when my customer isn't paying me to internationalize it? Hey! Where did acconfig go?!?
*pant* *pant* *wheeze* Eh, you get the idea.
Mahnamahna!