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."
1. Seth Nickell has posted a few videos showing the Luminocity window manager doing some super Open GL hardware acceleration tricks.
2. Interview: Rasterman Speaks of Enlightenment .17
3. XGL file format specs
Iran captures three CIA agents
Yeah wasn't there a Y windows in the works at one point.
You mean this?
Fresco was the other big contender.
The Linux Kernel is so flexable in how you can customize it for the hardware situation, its a shame you can't do the same thing for X.
Modern X actually does let you plug-in, plug-out all kinds of useless^H useful crap. It has actually matured into a fairly decent system, network transparency or no.
Where this article falls flat is on trying to make us believe that any of what we're seeing is "new". We've seen it all before, just with fewer cheap effects (e.g. the "wobbly windows").
Javascript + Nintendo DSi = DSiCade
enlightenment
luminocity
xgl
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.
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.
Oh brother.
...to be used in Linux...
...and its special feature is ability to use opengl rendered screens in place of bitmaps for window drawing...
There is a language being developed codenamed cairo..
No. Cairo is a 2D vector graphics library, not a language.
or Windows. or Mac. It is a cross platform library.
its a GTK fork...
No. It is not. The CVS head version of GTK uses cairo for drawing.
Among its features are multiple drawing back-ends. One is OpenGL, another is Render. Because it is a vector library, it may or may not render to bitmaps - depending on the backend.
A product is already being developed using this called luminocity.
Luminocity is a fork of the metacity window manager that has a built in composite manager that renders to OpenGL.
Now that that's been cleared up...
Schrodinger's cat is either dead or really pissed off...
Right. But you need to do this marshalling one way or another. Remove network transparency and you'd *still* have to provide data in some particular format and follow some particular protocol.
My point is that just getting rid of the network socket won't help you any. You'll still end sending exactly the same stuff but using another mechanism, incurring in pretty much the same overhead.
It's not like getting rid of the socket would suddenly free you from the need of communicating in some standard way with the server. How would it understand you otherwise?
If you're communicating by sockets, you have to make two context switches, right? One to call the kernel, and one from the kernel to the X server. Whereas if there was a system API, then it would be just one context switch: you call the kernel, end of story.
That is an argument for putting the GUI in the kernel, not for getting rid of network transparency,
If we count entire paths, it would be: you-kernel-x-kernel-you, vs. you-kernel-you.
No, a "context switch" is from one process to another, a process into the kernel is not a context switch, at least not in the same way.
For example:
1) FP - process 2 process requires save & restore of floating point registers, but process to kernel does not because the kernel does not do FP
2) General registers - process 2 process requires save & restore of all general registers because each process has its own state, when you make a system call, you bring all of your general registers in with you since the "state" of the system is your currently running process. Somem will be saved off in case the kernel clobbers them, to be restored on the way back out to the user process but worst case, that's only one save & restore and if you go back to a different process (which is usually the case, even in your example) then the number of saves & restores is the same either way.
3) There's more, but I'm too sleepy to type any of the rest.
Um, and how exactly would you communicate? So, you remove the protocol. And then?
An API is an interface that can be provided by instance for a library. Or it can be provided by an application and used by a library (plugins). But your application isn't *linked* to the X server, so it can't just call functions in it!
The only way to make what you say possible would require each application to be in the same address space as the X server, or for the X server to be in the kernel. Both approaches are quite horrible, IMO.
If the application is a module in the X server then a failure in the application can bring the whole server down. And there's no possible to have applications running with different permissions. Just wonderful, we can go back to MS-DOS levels of security and stability!
X in the kernel is a more viable approach, but forget about it. The kernel developers don't want it there for a good reason, and this isn't exactly removing the network protocol anyway - it's an entirely different system that wouldn't even look remotely like X.
I get the idea that you don't know much about software design. I'll say it again: You can't get rid of network transparency that easily! It has to be there because there has to be some way to talk to the server. I'll try to explain this way. Here are the most common forms of Unix IPC:
Network sockets
Unix sockets
Pipes
Shared memory
Message queues
Guess what? Except shared memory all of those are pretty much the same as network sockets. RPC (remote procedure call), which is probably what you mean by "API" works through network sockets. And shared memory is inconvenient to use for some things.
So, again: Unless the X server moves into the kernel, or the application moves into the X server there's simply nothing better than networking to make the application and server talk.