Slashdot Log In
XFree86 Fork Gets a Name, Website
Posted by
michael
on Sun Aug 17, 2003 12:15 PM
from the politics dept.
from the politics dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
That's nice, but... (Score:5, Funny)
Re:That's nice, but... (Score:5, Funny)
Yeah, I know how to pronounce it. But let's say I'm talking to a friend on the phone:
"So, you really gotta check out Xouvert."
"Zoo-what?"
"Xouvert!"
"How do you spell that?"
"X-O-U-V-E-R-T"
"Oh...wouldn've never guessed that on my own."
Giving projects you wish to succeed names that invite misspelling isn't a very good idea.
Parent
Re:That's nice, but... (Score:5, Funny)
rjrjr
Parent
Re:That's nice, but... (Score:5, Funny)
I'm a lee-nuchs, Guh-nome, Gah-Noo man 150%. The whole thing is about freedom man.
If they want to spell it "Raymond Luxury Yaught", but pronounce it "Throat-Warbler Mangrove", that's a-ok with me man.
Now pass me that bong.
Parent
Re:That's nice, but... (Score:4, Informative)
On kernel.org you can find the correct pronunciation [kernel.org].
Parent
Re:That's nice, but... (Score:4, Funny)
What do you mean? It worked great for Gigli!
Parent
Re:That's nice, but... (Score:3, Funny)
xwin.org (Score:3, Informative)
Re:xwin.org (Score:3, Interesting)
Is it true? Who knows, probably not. Is it an interesting rumor? Sure why not.
Re:xwin.org (Score:4, Informative)
Xouvert is the project that xwin.org was put in place to instegate.
Parent
Why not just implement a "testing" branch of X? (Score:4, Interesting)
It seems that this group wants to push the envelope of features in X. Why not just do something like the Linux kernel numbering? e.g. 2.4 -> stable, 2.5 -> testing. Then, people could make a decision as to if they wanted to run the bleeding edge in an attempt to use new features. It'd also save the hassle of building for 2 graphics systems, and merging patches between the two code bases.
On the first line of the page. (Score:3, Informative)
Looks like you got what you wanted.
Re:On the first line of the page. (Score:5, Informative)
Yes, it's starting as an experimental branch from XFree. Other experimentals include:
- GCC/EGCS
- Emacs/XEmacs
- Minix/Linux
- BSD4.4/OpenBSD/NetBSD/FreeBSD
See a pattern yet? They are doing their own source tree, their own code control, etc. This is not a branch of the official XFree86 project. This is a fork, which will be maintained independently of XFree86. It seems that one of two things will happen here.While I'm not against going out on a limb and doing something innovative, I just wonder if it would have been better to try and accomplish this within the project that currently exists?
Parent
Re:On the first line of the page. (Score:5, Insightful)
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
Parent
Re:On the first line of the page. (Score:4, Insightful)
Maby they did not succed.
Parent
Re:On the first line of the page. (Score:4, Interesting)
I personally applaud this fork, anything that encourages support, and let's be honest, momentum, to a application as critical as X, can't be anything but a good thing. One thing is for certain, these guys have made an effort to changes things; and that's far more than those in Xfree, or the aborted mess of a website, xwin, have done!
Parent
Re:On the first line of the page. (Score:4, Interesting)
Well, maybe because the XFree team isn't interested in anything except improving graphics drivers? I mean, I love X, I think it's a great concept, but XFree86 needs improvement. Not necessarily in overal concept, but in implementation. Lots of cleanup and rewrite work to be done that could make X a lot better than it already is.
But if nobody in the core team is interested in any of that, then you have no choice but to try other methods of getting it accomplished. However, I'm disappointed that I don't see any of the X developers I"d expect to see listed on the project page. It makes me hesitant to jump on this thing as a great move. Regardless, I don't think it's a bad move, but it's not the fork I've been waiting to see. I guess we'll have to see how things play out.
I'm encouraged by their choice of repositories though. It'll be good to see how Arch works for them. I anticipate they'll be very happy with it.
Parent
This is good. (Score:3, Interesting)
I hope they integrate NX compression (Score:5, Interesting)
Re:I hope they integrate NX compression (Score:5, Informative)
What is really needed is a driver for the XServer that will duplicate the current X command stream. This could then be sent to the NX proxy, and actually use it as a remote desktop. Also could use VNC, and it could also be useful for providing desktop pagers with full update capability.
Parent
Re:I hope they integrate NX compression (Score:5, Interesting)
I am talking about exporting your whole local session to another box. The server side, not the client side. The server side of NX makes a whole other X server, ie a new session. I'm talking about taking your normal X session, and exporting that.
Look at KDEs remote desktop feature. At the moment, it is a horrible hack, which takes screen shots and uses the VNC protocol to send them over the network. In an ideal world, it would just connect to the X server, say "I want all the drawing commands from now on.", and the X server would send that, which would be then translated to VNC or RFB or NX. This would be far less heavy weight, and far more responsive.
Parent
Re:I hope they integrate NX compression (Score:4, Informative)
http://xf4vnc.sourceforge.net/ [sourceforge.net]
Parent
For those who don't know... (Score:5, Informative)
Should be interesting. (Score:3, Funny)
Translated: By doing release early, release often, we should be able to produce a window system that is buggy enough to rival Windows 95a.
Re:Should be interesting. (Score:5, Insightful)
Parent
The Xouvert name (Score:3, Funny)
Name sucks. (Score:4, Insightful)
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
Right you are. (Score:5, Insightful)
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.
Parent
Re:Right you are. (Score:5, Insightful)
Who are you trying to market Xouvert to? To end users? Do you think they care? What are you going to tell them? To install an entire windowing system? As far as the end user is concerned, they shouldn't even *have* to know what the windowing system is called. There's no point in marketing Xouvert to end users. The only thing that matters is marketing "Mandrake Linux" or something to the end user.
I'd say the "marketing target" for Xouvert is developers. Do most developers care about the name? No, they care more about the code an openness of the project. So the name is not a big problem.
As for individual apps and the commercial world: do you think names like "Outlook Express" or "Powerpoint" are intuitive? There are only 2 reasons why people know what those apps do:
1) People told them.
2) They read the website or menu item description.
If people can tolerate those non-obvious names, why can't they tolerate open source software with non-obvious names? Distribution already add a description to menu items. Examples:
* Galeon Web Browser
* Evolution Email
* Gaim Instant Messenger
* kedit (Text Editor)
* Konqueror (File Manager)
Parent
Re:Name sucks. (Score:5, Insightful)
Many people (gasp!) don't have English as their first language - or do, but speak other languages - certainly enough to know that 'ouvert' means 'open'
Many other people don't judge apps by their name, either.
Parent
It doesn't matter (Score:5, Insightful)
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.
Parent
Drop XFree86, use Y instead (Score:5, Informative)
Y [ic.ac.uk], 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.)
Re:Drop XFree86, use Y instead (Score:5, Interesting)
Anyway, Fresco|Berlin is merely a GUI built on top of the GGI/GII interface. XGGI does much the same, but works with X instead.
The problem with X is that it is too bulky. We need a RISC GUI, with layers which supply the X API. GGI/GII seems like a good foundation. KGI does, too, but development with KGI is too stop-go.
Anyway, switching protocol isn't the solution. Neither is a simple re-implementation, or the addition of new code. What you need is a compartmentalization of the code, so that each part of the code can run efficiently and quickly.
Think of it this way:
Parent
My one worry is gone: Licensing (Score:5, Insightful)
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
First step: ditch IMake! (Score:5, Insightful)
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 [theaimsgroup.com] 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...
GNU autobuild tools suck. (Score:4, Insightful)
As usual, djb's got the innovative ideas. Google for djb and redo.
-russ
Parent
Re:GNU autobuild tools suck. (Score:5, Insightful)
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 [tip.net.au]" 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.
Parent
People who want to drop network transparency... (Score:5, Insightful)
Anything that wants to have a snowball's chance in hell to replace X is going to have to be network transparent, too.
Re:Excellent (Score:4, Insightful)
Parent
Re:Excellent (Score:4, Interesting)
But that kind of raw data pumpking is not very useful for normal applications, which don't need heavy bandwidth at all! You seem to think that your AGP bus is a fat-pipe framebuffer and that given a simple enough toolkit, it would somehow be a speedup to blast 32-bit screen dumps onto it at full speed. But even if this were the case, the content of those dumps would have to come from somewhere. In the API of every modern windowing system (including MS Windows) you'll find heavy reliance on some sort of message passing interface to make the nuts and bolts of the user interface; in short, every windowing system is "network transparent", it's just that most of them are only flexible enough to use one transport method, unlike X, which lets you choose the transport method. And I challenge you to find me any non-motion-video non-3D desktop application that is bandwidth or latency limited even on 100Mb ethernet, much less gigabit ethernet or local transport (get netperf on your own PC and check out the unix domain bandwidth!) Most any kind of local transport is going to have negiligible overhead compared to the overhead imposed by data inefficiencies in toolkits themselves (message redundancy, uneeded refreshes, etc.), and neither of these runs up against any kind of bandwidth or latency ceiling on a modern PC either. Both KDE and GNOME have major architectural inefficiencies outside of the widget rendering path. Search google.
And as far as burden of proof goes, you're the one proposing to throw away one of the most important features of the Unix desktop. I often hear complainers say that "90% of Unix users never need network transparency!"
I don't buy that number. You're getting the Windows market confused with the Unix market mate, I'd guess that 70-80% of regular Unix users do make use of network transparency becaue the vast bulk of regular Unix/X users are doing so in an administrative capacity. I'd love to see a Slashdot poll on this point.
Parent
Re:Excellent (Score:5, Informative)
Why do people not realize, that X-Windows is NOT sucking because of network transparancy! Any possible design of a clean API for a windowing system will more or less be automatically network transparent. The only this which is not network transparent are stupid ugly hacks. That said, we all know how X sucks, but it is has definitively nothing to do with network transparancy.
Cheers
Parent
Re:Excellent (Score:5, Informative)
See my previous comment on NX compression [nomachine.com]. 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.
Parent
Re:Excellent (Score:5, Insightful)
Parent
Re:Excellent (Score:4, Insightful)
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?
Parent
Re:Drop Network Transparancy , and drop X (Score:5, Insightful)
Parent
Re:Well then.. (Score:5, Informative)
You can't just dump some stuff somewhere on the net and then expect people to contribute. You have to prepare a lot of things, so that people can easily contribute without getting lost in the mess!
And I don't know who moderated you up but those moderators certainly didn't read the website. I quote:
"Sat Aug 16 00:59:49 PDT 2003 - You can't download anything yet. We have this website, XWIN is providing Wiki space, and Savannah is providing mailing list and bug tracking services. We are importing the Xfree86 source code into an arch repository right now; the current job is making a script to tag the source files every time a CVS checkout is done. The IRC logging bot still needs to be set up, and code written to archive the logs daily."
The website has only been up since yesterday! Accusing them for "keeping it secret" and shoot down their image is just stupid, when they've just started recently.
Parent
Re:Something to bring up (Score:5, Insightful)
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!
Parent
Agreed! (Score:5, Interesting)
I do think X is a bit creaky though, maybe it is time to start a new one, one where major (and even compatability-breaking) changes can happen. Some things on my wishlist:
*A single, standard, simple font system.
*Integration of a more modern toolkit and WM, even if it has to borrow heavily from GTK+ or another project. This would be inclusive, it wouldn't prevent you from using other toolkits and WMs (think WindowMaker instead of TWM in the base set).
*Ability to run like Quartz Extreme (as an OpenGL-based system). Also, not as a requirement, just as an option.
*There's no excuse for not vectorizing this from the bottom-up, and we'll be thankful when the commercial OSs get this done and we've already got it. Think about running your monitor at 1600X1200 and telling the system it's 200 DPI so it zooms everything accordingly. Apple has this up their sleeve now, and Longhorn might unleash it on Windows.
*Transparency, which personally doesn't get me hot and bothered, but I guess people think it's cool.
*Ability to act as the 'console' layer for the OS, no more framebuffer-for-console, X for graphical. Have the thing run a full-screen native terminal, and have the OS work with it.
*extensive database of video cards and monitors for easier configuration, this should be integral to the graphics system. It took me a LONG time to find the specs on some of my monitors and I'd rather not do it ever again.
*Generally simpler/more elegant design. I'm pretty sure that a lot of what's in XFree86 today is there just to prop itself up, while a newer system might have a better chance of coming out with a clean design.
Parent
Re:Terrible choice of name. (Score:4, Interesting)
It's already taken?
I suggest a re-name, but with an open naming contest this time.
In what system do we force project names on independent developers who didn't ask for an opinion? If Xouvert is a mistake, it's theirs to make. The code will survive if the project doesn't.
Parent
Re:Uhmmm... (Score:4, Informative)
Parent