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."
Dropping one of X's best features will not make X obsolete. I use this every day, I will never give it up.
Give me Classic Slashdot or give me death!
... From a marketing standpoint. That's it. It's hard to immediately discern how it's pronounced, it's got seven uneven letters, it's relatively long and it has no obvious immediate meaning or collection of related possible meanings based on the roots of the word.
...
So what if 'ouvert' is 'open' in French. I didn't know that. Lot's of people don't know that. Learning that doesn't make you go "ooooo, that's so cool". It just makes you go, "oh".
Open source projects, especially projects of any magnitude should try, from time to time, for some true open source marketing. Unfortunately, engineers, no matter how smart they may be at one thing, are frequently not as smart as they think they are at many things, and so they drop the ball in some areas. This is a decent example.
Of course, 'Vim' and 'Emacs' aren't exactly stellar examples of naming, either, but on the other hand they haven't had much success outside certain circles, and they're both pretty amazing editors. Someone might say that has more to do with their vertical learning curves compared to, for example, 'Word' but their names certainly didn't help
Chr0m0Dr0m!C
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!
I've often said that open source software projects need to do better or at least some marketing. Seemingly little details mean a lot.
For example, most commercially marketed software packages have web sites whose opening page clearly dewscribes the function of the software and then goes on to elaborate on what the software can do for you. Conversly, most open source project homepages start with a change log. Compounded by the fact that most have rediculous names that are not at all intuitive, many do not describe what the software does in a sensible fashion. Then worst of all they go on to compare their incomplete feature set with Windows, gleefully noting "Soon" or "In Progress" next to the missing feature.
You've got to put a marketing spin on your project if you want people to use it. Always highlight and stress its features and strengths. Never advertise its weaknesses. Don't compare the project to better or more feature rich works. If you must offer comparisons, compare the project with known products that are indeed inferior in quality or feature sets and use products that are generally well known ion the comparisons. Finally, and this is perhaps most important, bury the zealotry. DO NOT so much as imply that people should use your project because this other one sucks. If you must post this type of zealotry, save it for the developers page, somewhere that regular users should have NO reason to ever go.
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.
But when done right, they can release often but still have stable released. See the GNOME project. They have a very strict policy in not breaking compatibility between minor versions and not changing big things during freezes. As a result, the GNOME 2.x series are more stable than any previous GNOME releases. Compare the stability of GNOME 1.0 with 2.0: huge difference!
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...
I think his point is that X *is* the protocol. XFree86 is an implementation of that. Without the X11 protocol, you might as well call it pork chops.
Give me Classic Slashdot or give me death!
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!
You have not understood how open source developement works. There is not a fixed amount of development power that can be distributed among the number of existing projects. A fork can ultimatively tab new sources of creativity and also the pure stimulus of competition can mean a boost for both projects.
I strongly believe that this is e.g. true for gcc/egcs but also for KDE/GNOME. None of the projects would be where they are without the competition of the couterpart.
Cheers
KdenLive/PIAVE - non-linear video editing
> ...I just wonder if it would have been better to try and accomplish this within the project that currently exists?
Maby they did not succed.
The actual reason for X's poor performance, AFAICT, is that it doesn't expose all the hardware acceleration. Most recent video cards (including cheap ones like i810) have things like textures and gradients available at the hardware level. Xlib doesn't have such things though, it's full of primitives like "draw an arc", which comes up a whole lot less in modern GUI programming. So when GTK wants to create a shaded background, it passes it to X pixel by pixel (well, line-by-line) and X passes it to the card that way. A faster system would make the card do the work.
This is difficult because not all cards have the same acceleration, and widget systems are going to need to support both this and the original X. Even so, we do it for 3d with opengl, so why not here?
Sig:Why copyright isn't a fundamental human right
Anything that wants to have a snowball's chance in hell to replace X is going to have to be network transparent, too.
Sorry, but the GNU autobuild tools suck. They start with a broken idea (Hey, let's give everybody a *different* makefile, so that you can't debug makefile problems! Hey, let's build the Makefile itself from a file which is automatically created, so you can't tell which of the four levels has the build problem!) and break things from there.
As usual, djb's got the innovative ideas. Google for djb and redo.
-russ
Don't piss off The Angry Economist