XFree86 Fork Gets a Name, Website 647
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."
That's nice, but... (Score:5, Funny)
Re:That's nice, but... (Score:2, Informative)
XO (Score:3, Informative)
XO (pronounced: ex-oh).
ouvert is french for 'open'. ignore the prank the website is trying to play on you. i don't intend to add the french inflection 'zoovair' every fucking time i say it (much like i like my croissants to be crassandwiches). besides, the name XOPEN is already taken. so there you have it, folks. say it with: me XO is not Xfree86
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.
Re:That's nice, but... (Score:5, Funny)
rjrjr
Re:That's nice, but... (Score:3, Insightful)
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.
Re:That's nice, but... (Score:4, Informative)
On kernel.org you can find the correct pronunciation [kernel.org].
Re:That's nice, but... (Score:2)
Re:That's nice, but... (Score:4, Funny)
What do you mean? It worked great for Gigli!
Re:That's nice, but... (Score:3, Interesting)
Not to mention the problem I have giving them the address.
"No, the WORDS slashdot, THEN a period, THEN org... no no, you type the word DOT after slash. No, its one word. SLASHDOT then a PERIOD then, oh fuck it, here, i will type it for you."
I am NOT kidding. Wife kept on trying slash.dot.org last night, (an article she would like) and she is not an internet idiot.
Re:That's nice, but... (Score:2)
Re:That's nice, but... (Score:2)
Zoo-vehrt.
You big malaka.
Dino:"Hello, pretty lady. Tell me something, what's a beatiful braud like you doing with a malaka like this, huh?"
Gary: "She's into malakas, Dino".
Re:That's nice, but... (Score:2)
X - from X windowing system
Ouvert - French for 'open'
Thus, it is probably 'shoovair', or however the phonetic thing works.
Re:That's nice, but... (Score:2)
What kind of a name is Xouvert?
Xouvert is named after the ancient Babylonian goddess of open windows, wooden digging implements, and moonlight. A notorious ritual among the higher levels of Freemasonry has kept her memory alive until now. Xouvert, awake!
Re:That's nice, but... (Score:2)
It's a little tricky as the x is pronounced as 'by' as in 4x3 = 12, but the rest is as it looks, resulting in the full word being proounced "By oh you vert!"
Re:That's nice, but... (Score:2, Funny)
Re:That's nice, but... (Score:3, Funny)
Rhymes with Q*Bert (Score:2)
Humor aside, this is a shining example of how open source alienates ordinary people.
Re:That's nice, but... (Score:2)
Re:Xopen / Xhoover (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:3, Informative)
Re:xwin.org (Score:3, Informative)
Re:xwin.org (Score:4, Informative)
Xouvert is the project that xwin.org was put in place to instegate.
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:2, Informative)
Looks like I got what I was always afraid might happen.
Re:On the first line of the page. (Score:5, Informative)
Yes, it's starting as an experimental branch from XFree. Other experimentals include:
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?
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
Re:On the first line of the page. (Score:4, Insightful)
Maby they did not succed.
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!
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.
This is good. (Score:3, Interesting)
Re:This is good. (Score:2)
Furthermore it is likely that ideas which are useful will be integrated to the other fork, as we see with SAMBA and SAMBA TNG. This may very well be good for all parties involved.
Re:This is good. (Score:3, Interesting)
I disagree. This is not, or rather imo it should not be, a high priority. It's very pretty, but not exactly XFree's biggest problem. They need to solve the issues surrounding configuring X, and handling various input devices. They need to move it to a halfway usable build system. They need to stop forcing me to build and install a driver for every video card in the world even though I r
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.
Re:I hope they integrate NX compression (Score:2)
If I'm understanding you correctly, that's exactly what "nxagent" does - it appears on your local machine as a remote desktop, either in a window or full-screen. A "rootless" option, which will run individual remote applications under your local window manager, is apparently on the way.
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.
Re:I hope they integrate NX compression (Score:4, Informative)
http://xf4vnc.sourceforge.net/ [sourceforge.net]
For those who don't know... (Score:5, Informative)
French? (Score:2, Funny)
Because that was my first thought, dunno about anyone else...
Re:For those who don't know... (Score:3, Funny)
(j/k btw)
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)
The Xouvert name (Score:3, Funny)
What? (Score:2, Funny)
Idea dislexia? Are they really trying prevent new drivers and features?
Heh, if that were the case, I suppose they could stop at their name change and say they're done:)
Re:What? (Score:3, Informative)
Idea dislexia? Are they really trying prevent new drivers and features?
Heh, if that were the case, I suppose they could stop at their name change and say they're done:)
The only one with dyslexia here is you.
"to reduce the risk"... let's put it in baby english for you... "to make it easier"...
Rewritten: "They hope to make it easier for XFree86 to incorporate new drivers and features"
You quote something reasonable
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.
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)
Re:Name sucks. (Score:2, Insightful)
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.
Re:Name sucks. (Score:3, Insightful)
If you believe that, I have a bridge you may want to buy. I can also sell you a humour-detection meter.
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.
Re:It doesn't matter (Score:3, Interesting)
I don't know, but I'm pretty sure I will, if the project gets popular.
But that's not the point. If you can't remember the name anymore then that means you aren't getting exposed to it enough. When you're not getting exposed to it enough that means one of these two things:
1) You don't care. So why should you remember the name? No problem here.
2) The project died off. Why should you still remember the n
Re:It doesn't matter (Score:3, Insightful)
Yeah maybe he won't like the name. But that's not the point. _Why should he care?_ Why would he want to care?
Let's face it: if I propos
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:
Re:Drop XFree86, use Y instead (Score:3, Insightful)
That is what X was designed for.
Their release policy (Score:2)
Branch not fork (Score:2, Informative)
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
Re:Tune in to your own life at least (Score:3, Interesting)
This problem has nothing to do with "Free" operating systems. It's about vendor support. You'd have just as much trouble (if not more) getting your card to work with OS/2, Be, a Mac, or whatever if the vendor doesn't support the system.
I used OS/2 for a while, but my sound card didn't work because the vendor only made Windows drivers, yet it worked in Linux because some guy (or a few guys) had soundcards with the same chipset, so they figured it out and wrote a driver. In a closed system, if you don't hav
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
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.
Re:GNU autobuild tools suck. (Score:3, Informative)
Re:First step: ditch IMake! (Score:3, Interesting)
Imake and autoconf take fundamentally different approaches to configuration: imake says `give me a system type I know about, and I'll give you some makefiles' -- great, unless of course it doesn't know about your system, or if you've changed something. Autoconf, on the other hand says `I'll grovel around on your system and see what t
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:People who want to drop network transparency... (Score:3, Interesting)
On that, no argument. X's implementation of network transparency is quite possibly the worst part of X, however. The X server is dumb and cannot be helped without some grotesque hacks. I'd really like to not cause a zillion expose events to happen every time I resize or move windows. I'd like to be able to program events locally and not have every single damn keystroke roundtripped. Wouldn't it be nice to have a terminal window that actually knew t
Re:People who want to drop network transparency... (Score:3, Insightful)
I've used X over a dialup link. IT works for the most part just fine. Well programed apps have no problem. XV did just fine for instance displaying a picture on my screen. It took a while to display, but not that long really. Not something I'd like to do often, but considering I was on a dialup it was surprizingly useful.
Re:People who want to drop network transparency... (Score:3, Insightful)
Instead you want a display server that has the capability to execute local programlets, perhaps written in Postscript (as Nextstep did), or in Java or Parrot Bytecode. Then you want to transmit over the network calls to the procedures stored in your display server. That would be calls at the level of "display dialogue box w
While we're at it, is Fresco dead? (Score:3, Insightful)
XFree86 Fork Gets a Name, Website, Girlfriend (Score:3, Funny)
American Name of Xouvert (Score:3, Funny)
Re:Excellent (Score:2, Insightful)
Re:Excellent (Score:2)
Re:Excellent (Score:5, Insightful)
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?
Re:Excellent (Score:2)
How much time does this take? How do we know it's really significant without data?
Re:Excellent (Score:4, Insightful)
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.
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
Huh? (Score:3, Insightful)
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.
Re:Drop Network Transparancy , and drop X (Score:5, Insightful)
Re:And dont forget the move to WindowsTSE (Score:3, Interesting)
Re:NDAs? What the FUCK?!?!?! (Score:2, Interesting)
Had you RTFA properly, you'd have seen the next line says
"All code that enters the project is under the standard X11 license, or compatible free license as specified by the Free Software Foundation."
See, that's not so bad, is it?
Seriously, I don't particularly like NDAs, but as long as the source code is 'free', then it's really not a problem IMHO.
David
Re:WHY? (Score:2)
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.
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!
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.
Re:Something to bring up (Score:3, Informative)
This is the way every windowing system should be designed, even if you only want to display on one screen. It mimics reality -- there's a display over here, and there's a processor over there. Every "average" person uses a remote desktop. It shouldn't matter if the display is connected via a VGA cable or
Re:Terrible choice of name. (Score:3)
"Worse yet, naming a project after an obscure occult reference is likely to be offensive to those of various religions."
LOL.. ok.. either you're dimwitted cause you didn't get the joke or you're just trolling... anyways... the fact you got modded insightful speaks volumes about the karma system these days.
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.
Re:Terrible choice of name. (Score:3, Informative)
Re:Uhmmm... (Score:4, Informative)