Slashdot Mirror
Next Generation X11
Rene Rebe writes "The German News site Golem is running a report (babelfish translation) about the next generation X11 projects, like the OpenGL X-Server Xgl, Luminocity as well as Enlightenment 17. The report is including many screenshots and five videos."
I enjoyed reading the machine translation from german. Makes you think about about how language works and it's down right funny. My favorite line (from a comment): "With open SOURCE is too much abgekupfert." Don't know what it means, but I find my self agreeing...
The world is made by those who show up for the job.
X11 is not just for Linux, you know!
If all this should have a reason, we would be the last to know.
How about implementing dynamic X server reconfiguration to allow connecting and disconnecting external monitors to laptops on the fly? How about using different resolutions on these monitors?
Right now Linux/X11 is horribly behind both Windows and Mac OS X, being unable to detect an external monitor being connected and change resolution accordingly.
> come by any Apple Store and pick up a mini
This is illegal where I live. Here, we have to give money to a store in order to get something from them. Sigh.
Many complain that CPU speed does not increase much from the user perspective but what if the new X11 tech brings us GPU based jpeg decompression?
Surf your photos and they go straight to the GPU instead of storing a CPU decompressed bitmap in RAM, the speedup would be incredible. Low CPU usage in laptops as GPU does the work.
Remote X11 display without recompression of the network stream? It would become as fast as surfing. Requested jpegs being send straight to the receivers GPU, simply upgrade the GPU in school computers to get very fast thin client Linux boxes.
Look at Apple's Core Image in Tiger: possibilities will be amazing.
It has actually be shown a number of times that fancy features (such as integrating a physics engine into the desktop as so) actually leads to a more complex and harder to use system. I have to congratulate these guys on what they've achieved, but at the same time I have to wonder if this is the right direction to take, especially since Linux's only major flaw is in fact its lack of usability.
surely you can see the immediate need and usefulness of transparent windows and wobbly windows. Not to mention that the present versions of X11 are only using from 50 to 100 megabytes of memory when modern systems have 512 to 1 gig available. I think once we get the bugs worked out of these new features, then we can look into more advanced stuff like "hot-plug monitors" and dynamic resolutions.
Plugged in how?
This is something I spent a *long* time explaining to some people on a forum about a related subject. Network transparency doesn't involve significant overhead, dammit!
There has to be some way for an application to talk to X. So, you remove the network protocol, how do you want to talk it to X then, magic? In order for two different programs to talk to each other there has to be some kind of protocol, no way around it.
Now, networking indeed can slow things down a little due to things like latency. But that's effectively inexistent if you're talking on the local host. And X already has shared memory communication as well. On Linux there are also the so called Unix Sockets, which is pretty much like TCP/IP, only with even less overhead since it's done locally, so it can be implemented in a simpler way.
However, as far as an application is concerned, an Unix socket and a TCP/IP one are exactly the same thing, so it makes no sense to get rid of network transparency - you wouldn't win anything with that anyway.
Hey look no pointless curley braces or semicolons... just like Python
This gets dragged out every... damned... time... X gets a mention anywhere.
The argument goes like this:
A> X is bloated.
B> No it isn't.
A> But what about network transparency? That's useful.
B> You actually use that crap? Fine, network transparency is neat. But there should still be a way to shut it off.
Welcome to the next point in that argument -- the realization that any time the windowing system and its processes are running in separate processes, some form of communication will have to result ni order to allow the client to do such nifty things as detect mouse clicks or draw things to the screen.
Now that you're dealing with communication between processes, there are many ways to handle the problem. They all involve some mechanism by which communication can occur.
Let's see... two programs with a need to communicate with each other... we wouldn't have a mechanism which has been tested and refined over many years to be pretty darned good at communication, would we? Where would we... hmmm... let me think, I know that at some point there must have been the need for communication at some point in the history of computing...
Oh! A network stack! It's perfect! It not only allows high-performance, low-overhead local communication via highly optimized mechanisms which are available on damned near every operating system on which anyone in their right mind would ever want a windowing system (see contest rules for details, some exceptions apply, mileage estimates provided by EPA methods), but has a built-in mechanism for communication between machines!
Hoo, boy.
The point is, sarcasm mostly aside (maybe), that there is the need for programs to communicate. This isn't a requirement which you can simply opt out of, like, say, FAT support or unneeded sound card drivers. This is a requirement that you can't get rid of, and to use something that doesn't allow network usage is basically to limit yourself to mechanisms which are much less widespread in availability than an IP stack.
An IP stack is a good tool for the task at hand, and it just so happens to be really damned hard to remove networking from it.
I'd be interested if you could provide a counterexample -- find a widely available, generally reliable IPC (interprocess communication) mechanism which is for the most part platform-agnostic and doesn't require tons of massaging in order to get the data into the right format. Bonus points abound if it does not include the ability to communicate across a network, which you requested be unavailable.
Somebody get that guy an ambulance!
It doens't matter if XP has the features or not...you're forgetting that the current version of Windows is Longhorn.
The correct answer is that 'Longhorn's tight integration with hardware thanks to Microsoft's close engineering work with card makers that provides a level of performance unachievable by any other vendor.'
Because, you know, even though Longhorn is over a year away we still talk about it in the present tense.
At least if you're within Redmond's Reality Distortion Field, which is growing to be as big if not larger than Jobs'...
Don't go there expecting anything you'll be able to use in the near future. I fully expect HURD 1.0 to be released before we're done.
/. is a stream of fools bitching at Mark/Andrew/me for not working hard enough on Y. I work on it in _my_ time, and people telling me what I ought to be doing usually causes me to go do something else entirely.
Please don't join the mailing list and ask "is anyone still working on this?" or "when will feature x be included?", because I'm tired of telling people to fuck off. We're working on it, we'll work on the features _we_ want in the order we feel like doing them. If you want something done you can do it yourself or pay someone else to do it for you.
Apologies for the rant: the usual followup to that link being posted on
Phil
( phil -at- y -hyphen- windows -dot- org )
I guess today is a passable day to die.
You mean that babelfish translates?!
Man, all this time i was thinking it was only generating random words in given language. All of it were lies. LIES!
A computer makes it possible to do, in half an hour, tasks which were completely unnecessary to do before.
Phil, get back to work and make me some cool graphics pronto!
While I agree with most of this, it should be pointed out that local X connections (i.e., the ones in which the server and the client run in the same machine) are usually done via UNIX sockets, not IP (witness the socket in the /tmp/.X11-unix directory while you are running an X session). The reason for it is that UNIX sockets offer less overhead than a TCP/IP stack.
Also, in modern toolkits (GTK, QT) images are usually sent via shared memory (again, only possible when the client and server are in the same machine), which is much more effecient than sending them through sockets.