Slashdot Mirror
Wayland, a New X Server For Linux
An anonymous reader writes "Phoronix has a new article out on Wayland: A New X Server For Linux. One of Red Hat's engineers has started writing a new X11 server around today's needs and to eliminate the cruft that has been in this critical piece of free software for more than a decade. This new server is called Wayland and it is designed with newer hardware features like kernel mode-setting and a kernel memory manager for graphics. Wayland is also dramatically simpler to target for in development. A compositing manager is embedded into the Wayland server and ensures 'every frame is perfect' according to the project's leader."
Thank you sweet Jesus! Finally somebody is doing something that should have been done looooong time ago!
...spell the death-knell of X-based graphics drivers? Does this mean that such drivers will finally be folded into pure kernel modules with no fancy wrappers required? Does that also mean that we can eliminate X as a dependency for playing video games, and using Linux in multimedia or kiosk environments?
Javascript + Nintendo DSi = DSiCade
Xorg/XCB anyone?
Then there is that stuff from NeXT which is similar to OS X.
Then there is that BeOS-like server.
Framebuffer.
I think there was some sort of OpenGL server a number of years ago.
Uh, what else? None of these have replaced the X11 standard.
While I'm a firm believer in "If it ain't broke, don't fix it", I think it is good to see Red Hat developers (or any developers) looking to future needs and being allowed to devote development time towards those needs.
Xorg isn't broken for most users right now, but planning and creating alternatives is a good idea.
For including Wayland in Ubuntu:
http://brainstorm.ubuntu.com/idea/15205/
It is dangerous to be right when the government is wrong.
I still remember upgrading from X10. What a mess.
eliminate the cruft
ABOUT F'ING TIME.
X has been a case study in How Not to Write Software for twenty years now. Once upon a time, it was a pretty cool experimental software project. But for twenty years now, there have been exactly two kinds of X development:
A) Throw a layer on top of it to make it useable for normal people
B) Throw another driver underneath it to make it just barely work on your particular hardware.
Project A is fine until someone has to get beyond your little layer, in which case it's .xinitrc hell. Project B is just treading water, postponing the day that we all realize this indispensable software tool is a gigantic house of cards headed for collapse.
Probably some XFree86 dudes are reading this. Let me just tell you I appreciate your diligence in the nightmare of a job you've set yourself to, but the time has come. Take off and nuke the site from orbit. It's the only way to be sure.
xclock? xeyes?
More functionality into the kernel instead of out to the X server? To me it's just code executing here or there; the user-space X server has full access to video memory and registers (via privileged I/O and MMIO), and nothing about executing in Ring-0 automagically makes code run "faster."
What major bottleneck of context switching warrants moving these things into the kernel? Why can't we have flicker-free mode switching in userspace X drivers?
Support my political activism on Patreon.
Wayland-Yutani, "Building better X-servers"
-ubuntu others as you would have others ubuntu you.
1. it's very primitive. If you've got a VM to try it on, then go for it.
2. As AC on another post correctly listed the projects like this that have come before it. So, before everyone starts beating-up on X11, they need to check out the ample supply of unpopular alternatives.
The framebuffer is rarely discussed as yet another alternative to X11.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
As I understand it these graphics drivers are the prime reason that people can't move to alternate X servers, and that these drivers are preventing competition.
Is that correct?
Xorg isn't broken for most users right now, but planning and creating alternatives is a good idea.
In a sense I think it really is... Admittedly, not necessarily in a way that everybody would notice, as you said - but still...
What X is good at, basically, is putting simple UIs over a network. For instance, I can run XEmacs remotely over the internet, and performance is decent.
Presently, this feature of X is being under-utilized. We're using a network-transparent protocol for the display server, but most people aren't running apps from remote hosts, and applications aren't being written with this in mind.
Basically, for all the overhead associated with something like X to be worthwhile then one of a few possible conditions must be satisfied. Either applications must be designed such that they work efficiently over the network with the present limitations in the display protocol, or the display protocol must be enhanced or altered such that today's applications can run reasonably well over a network link.
Running X apps over an internet link versus a LAN is an extreme case, admittedly - but nevertheless, an old Athena app can do it, while the simplest of GTK or QT apps can have a real problem with it...
Bow-ties are cool.
None of these have replaced the X11 standard.
X11 in 2008 is a lot different from X11 in 1998. Much of the X11 API is never used, and therefore you can get away with making a much simpler X-server which only supports the new calls. It won't run very old programs without some sort of compatibility box, but those are fairly rare.
Finally! A year of moderation! Ready for 2019?
There's another project called Y Windows, which also aims to replace X with something that has less historical cruft.
The real question in my mind is whether this kind of thing does anything to address the big problems users are really encountering. Of course, not every open source project has to make large numbers of users happier. But the author of Y Windows says, for example, "I've got tired with the state of desktop GNU/Linux. Most of the problems that I see with it can be traced back to the underlying window system, X. So I decided to write its successor... "
For me as an end-user, the big issues are simply hassles with xorg not correctly recognizing LCD screens, so that it sets them to an inappropriate resolution, or the image appears offset. I have close to zero interest in gaming, so personally I just use the onboard video of my mobo, with only 2-d driver features, but the impression I get from people who do care about gaming (or fancy WMs) is that the big issue is drivers, not the internal structure of X.
As far as programming, the structure of X also seems like kind of a non-issue. Sure, X's APIs are heinously ugly, but almost nobody uses them directly.
The advantages listed by the article are things like a more manageable code base, a smaller memory footprint, and elimination of rendering artifacts. To me, none of those seem like major issues that I was all that worried about.
Find free books.
FTFA:Kristian Høgsberg... describes this project as "a new display server that implements just the tiny fraction of X features that we actually use when running a composited desktop.
I really hope that includes X forwarding, but it sounds like it doesn't. Network transparency is IMO the killer feature of X, it would be a shame to throw the baby out with the bathwater.
Give me Classic Slashdot or give me death!
The article describes this as a "new X server". However it quotes the author of said program pretty much implying this is some kind of a new, non-X video interface. He talks about "porting" GTK+ from X, and about writing native applications for it and a "new, rootless X server" in order to be able to run X apps. All things that would not be necessary if this were an X server.
In other words, this is not an X server.
It's "X Window System", or "X Window", or simply X.
#include
#define BORG_GUI "Windows"
int main(int argc, char **argv) {
Display *disp;
int screen;
Window win;
XEvent ev;
disp = XOpenDisplay(NULL); /* evil mode, resort to Win32 compatibility if called by wrong name */ /* always give your switches a default case */ /* good unix desktop beyond this point */ /* FIXME: replace someday */
screen = DefaultScreen("slashdot.org:0.0");
win = XCreateSimpleWindow(disp, RootWindow(disp, screen), 10, 10, 50, 50, 1,
BlackPixel(disp, screen), WhitePixel(disp, screen));
XSelectInput(disp, win, ExposureMask | NewbieMask);
XMapWindow(disp, win);
while(strmp(argv[0], BORG_GUI)) {
UINT iMsg = (UINT)ev;
switch (iMsg)
{
default:
iMsg |= MSG_BSOD;
MessageBoxA ((HWND) win, (LPCSTR) &fuck_you, (LPCSTR) &greetings_from_ms);
SendMessage ((* HWND) win, iMsg, NULL, NULL);
break;
}
return DefWindowProc(hwnd, iMsg, NULL, NULL);
}
SSL_connet ("apple.com:0.0", X11_FORWARDING | X11_REALM);
return 0;
}
Finnaly the X Server will (maybe) get the same performance of windows interface? I know about the network transparency but c'mon! any normal user NEVER use this and this feature kill any chance of a fast graphical interface
Religion: The greatest weapon of mass destruction of all time
Shuttleworth said he is going to pay devs to work on major upstream projects. He should focus on this. For one, it would affect both KDE and Gnome users, and it would solve a major problem with Linux. If he really wants Linux to compete with OS X in terms of interface, he should focus on the X Server first.
That being said, I hope Novell chips in some dev support, and that the KDE, Gnome, QT and GTK+ devs all chime on what they'd like to see changed.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Though before you think this will replace the current X.Org Server, Kristian explains "at this point wayland is just a prototype/playground for some ideas I've been toying with."
I read the article, and it sounded rather like kdrive. Fast, simple, no cruft. Nobody uses kdrive, though, and I didn't see any compelling reason from the article why wayland is going to change things. Hopefully someone can enlighten me.
The project implements a new X server. Clients (i.e. your applications) link against the gnome library which links against ... which links against the X library, which talks to the X server via tcp.
The X forwarding in ssh works like any other port forwarding: listen on the port, grab the data, send it through the ssh tunnel, dump it at the target port on the other side.
That's the simple version. Add to ssh some special-casing for X, and add to xorg and xlib a speed hack that lets it use unix sockets or shared memory instead of tcp. Not consequential.
Unless the server only implements the speedhacked ways of transferring data between clients and the server, you'll have X forwarding.
Most clients are on the same machine as the server, so implementing shared memory first seems like a good move, but X forwarding is used so often that the outcry would be massive if network capability is saved for last.
Besides, I'd guess that data is transferred in the same format independent of how it's transfered; so the work to do tcp instead of shared memory is minimal.
Don't panic :)
Booo-urns!
I hear a lot of (I bet) young people clamoring for X to die, and that would somehow improve Linux or Unix.
X does not need and should not be allowed to die. Sadly X11 is probably one of the coolest pieces of misunderstood software on the planet. It is a bit dated and it does need a code cleanup/refactor, but because of proper design, that can happen without breaking the system.
To those who have *no* understanding of X, they should try this:
ssh -XC some_linux_machine
eyes
What happens is that the "display" is a network device. Windows terminal server and citrix, even today, can't easily separate application from display. X has had it for years. It isn't an afterthought requiring drivers to probe and figure out what got changed on the display surface and send a block over the network (like citrix and VNC), no the display is rendered over the network.
X11, IMHO, is one of those hidden jewels in Unix that don't quite get. They focus on trying to make it like Windows or be a gaming platform, but UNIX is a "productivity" platform.
Like I said, I'm all for refactoring, cleanup, cruft-removal, etc. to the codebase, but keep X11.
Jon Smirl and David Reveman lobbied for a new xorg server built on OpenGL. It got little support from the community especially from Red Hat and Novell. Personally I think this was one of the greatest missed opportunities in the history of OSS. We could have had a modern xorg server replacement which rivaled Apple and Microsoft. Now we have the main xorg branch floundering from lack of interest and developers. Not to say there hasn't been progress made but no one can argue that xorg has the resources available to compete.
Ironically someone who argued against X on OpenGL now is working on his own xorg server replacement. Good luck to him and I hope he has better support.
The best education consists in immunizing people against systematic attempts at education. - Paul Feyerabend
At the same time, I'm trying to fix some of the problems with composite that we still have in the X server; input redirection, window resizing, syncing to vblank, throttling of animations and atomic, consistent redrawing.
That feature alone would make this rewrite worthwhile. This has been missing from our desktops for far too long.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
...or NEXTSTEP from 1989 onwards. :)
you had me at #!
We went through the same thing when switching to X.org from XFree86. When will nVidia support it? When will ATi support it? When will my driver be ported?
Why is X dealing directly with the drivers anyway? Why isn't there a thin graphics layer in Linux, like a framebuffer that supports acceleration? Write X to that. Then you can switch your X or use whatever GUI you want and you hardware still works. Freedom to choose, right? The mantra of Open Source?
I remember a bunch of very promising GUIs coming up in the early 2000s that really struggled without enough drivers. "The source is open, just port the thousands of drivers!" yeah sure.
boldly going forward, 'cause we can't find reverse
... just manage video configuration for programs that do direct video frame buffer access, or any such access that might be done in the kernel, for applications not involving X, or that can work better when bypassing X.
now we need to go OSS in diesel cars
Bits of the above post appear to make sense but sadly none of it can really be trusted due to this.
I thought Emacs would replace X11 altogether, but I was mistaken.
Ripley: What are you talking about? What users?
Van Leuwen: Developers...software engineers. It's what we call a FOSS project. They set up development environments to make the project usable...big job. Takes months. They've already been there over twenty weeks. Peacefully.
Ripley: How many people?
Van Leuwen: Sixty, maybe seventy users.
Ripley: Sweet Jesus.
Van Leuwen: Do you mind?
It got little support from the community especially from Red Hat and Novell
should be "Red Hat and NVIDIA". Apologies.
The best education consists in immunizing people against systematic attempts at education. - Paul Feyerabend
Context for those who need it
Networks really aren't fundamental to windowing environments. X was designed around the limitations of most Unix configurations of the time (a single server with clients running on fairly dumb terminals). When real workstations became available, network transparency became a nice feature that wasn't really needed in most cases. The question is whether the added complexity is justified by the importance of the feature.
Sorry to burst your bubble, but your whole post is basically clueless.
Yes, we know that X11 is networked, and that this functionality is "cool". But that doesn't mean that the design of X11 is good.
In engineering terms, the X server is currently a massive single-point-of-failure. Despite all the "coolness" you want to give it, when the X server dies, it kills the many hundreds of client processes that are connected to it on a busy machine. That's a ton of work gone down the tubes just because someone way back coded the X server as a noddy star point without disconnectable links, and now we are still living with that legacy.
The X server is a large program, and large programs always have latent bugs, and latent bugs cause programs to crash in corner cases. That is why X hangs or crashes occasionally when you do something out of the ordinary, or when you stress it too much. One process failing isn't generally too much of a disaster in other cases, but in the case of X it is always a disaster because of all the X clients it takes down, and the disaster is unrecoverable.
So no, sorry, but X11 is not designed well no matter how "cool" its networking may be. It badly needs a rethink for key system reliability reasons. SPoFs like this are no way to design a professional graphics subsystem.
Checkout MicroXwin (http://www.microxwin.com).
Like Windows NT X11 graphics is done in the kernel.
There is no IPC and no networking overhead. Company claims that the solution is small, fast and compatible with existing toolkits.
The native remote capability of X has always been nice but suffers badly on low bandwidth or low latency connections and kills everything if the connection is lost. NX from www.nomachine.com or the freenx variation makes remote work with X desktops much nicer and I hope future changes don't break this functionality.
That's actually a great point.
It's particularly annoying if you have some intermittent problems with, say, the mouse disappearing and the only way to recover is to restart X. Being able to restart X without killing all the clients would change such a problem from "completely ruins my entire user experience" to "mildly annoying".
HAND.
Yet Another X Server
My ism, it's full of beliefs.
I don't buy things I don't need. What's your excuse for overcompensating?
When it was good, it was very very good, but when it was bad, well, it was a windowing system written in Postscript that let you pass pieces of Postscript code back and forth between client and server to get things done, which could be appallingly insecure and buggy. (The fix for this was that Gosling later wrote Java with things he'd learned from NeWS.) (Postscript is essentially FORTH souped up with font knowledge, but it's good enough to handle objects in.)
Postscript means that WYSIWYG, really, rendered however you'd like. The terminal emulator, for instance, used Postscript, rendered at screen resolutions, and if you needed to print it, it rendered them at printer resolutions, or if you iconized a terminal window, that just set to font size to 1 point / 1 pixel, and you could still see any interactions happening in the icon. My boss was around 60, and constantly switching pairs of glasses if he needed to talk to somebody and also read his computer screen. We set his psterm default to 24-point font, and everything was Just Bigger, and he could just read it without messing around. Mouse tracking worked well, because you could make the tracking happen down in the server without the extra round-trip to the client, so if you had a slow network connection it was ok - you were passing data across the link, not pictures of the mouse, etc.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I'm just starting to learn about linux, so bear with me. I think I get it though.
x11 is the core of kdm/gdm, and wayland will improve the relationship between kdm/gdm and the graphics driver? is that right?
anything to help my old 9600xt. I hate installing that thing. my 7200gs is so much easier..
a single distro gaining popularity will be instrumental for standardizing what is expected of Linux for introduction into a larger market
the flaws in your biased & self interested statement are manifest. manifest and hilarious.
first off, i dont see what advantage linux has by gaining a larger market. will these corporate interest invest time and code into linux? will they provide free support to end users? will the people joining your standardized Linux gain anything from the homogenized OS they've switched to?
second, how will standardization improve linux's marketability? to what extend to we enforce homogenization? do we enforce a single wm on all users? do we enforce a single office suite? a single programming language?
third, how do you plan to tell everyone they must work on the same thing? do you think everyone will willingly conform to the standard patterns you wish to impose and stop working on the things they think are cool?
Linux's only strength is that it grants developers an open environment to develop novel new things. all I see in your desire is a self interested bid to crush out the free spirited developer spirit and to replace it with something tooled to replace commercial operating systems with something free, for your own good. honestly I dont think you or your desires contribute anything useful to the linux community, in fact I think the desire to make Linux conform to the expectations of the "typical" desktop has been the worst mistake the Linux movement.
Just curious. Wayland is also the name of my hometown.
Alas, it's one of those that is very hard to reproduce, but it happens pretty reliably when X is under high load -- I originally thought it had to do with mouse grabs because it happened 100% reliably with VirtualBox and kvm, but I've now also seen it happen when X was loaded and nothing was grabbing the mouse. I've googled around and found lots of similar, but not quite identical reports of mouse problems.
(No, it's not that the device disconnects, nothing in the dmesg log about disconnects, the mouse pointer moves fine, the X server just doesn't receive any events -- as reported by xev. Strangely this is the case both with the hardware mouse cursor and the software mouse cursor.)
It's driving me nuts, so I'm going to try reporting it as an xorg bug (happens regardless of programs running, etc.), but I'm not hopeful that anyone will be able to track it down.
It's quite easy to allow restarts of the windowing system, you just have a proxy between the "talks to hardware" bit and the "talks to clients" bit (see "screen" for the equivalent console app). The proxy would obviously have to be simpler and less prone to errors, etc. for this to make sense, but such a proxy would not need access to any hardware, so that should be pretty doable.
Thanks for the SIGPWR hint, btw. Handy to know.
HAND.
I have 8gb of RAM for the maching I only use to browse the web with, and you can guess how it scales from there. What's your excuse to act ghetto when prices are so low?
Can't fit more than one SO-DIMM in a laptop?
Having said that I run with 1gb of memory and rarely have memory issues. X has never crashed for me. Only outage I get is when I dice with death with the battery (disable auto-shutdown, I get about 15 minutes of power when the battery reads 0 mAh remaining)
When it was good, it was very very good, but when it was bad, well, it was a windowing system written in Postscript that let you pass pieces of Postscript code back and forth between client and server to get things done, which could be appallingly insecure and buggy
What we could do now! We could create a brand NEW windowing system but instead of Postscript, they could use... Javascript instead!!! Doesn't that just sound like a totally FABULOUS idea?
Deleted
I've read this before..
http://slashdot.org/article.pl?sid=01/10/23/1252214&tid=152
I can't help but think, that all this line of development we are currently seeing, could of been finished years ago. It was a project call GGI & KGI.
Have a look here!
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
Sorry, you are totally wrong, that's not how X11 works at all.
The client queues up a set of drawing commands (not bitmaps), at some point the queue gets flushed, and for a local display there's a context switch and the server updates the screen. This is exactly how Windows and OS X work as well. The only difference is that the X11 protocol was carefully designed to be asynchronous, so that when you run over a network connection rather than locally, you don't get killed by latency on round trips.
Browser apps are nice in many ways, but that's a separate issue from the display architecture.
Bad things about X11: primitive drawing model, too much hardware management (this is an X.org problem rather than an X11 one, really), a lot of legacy. Most of the things that are actually bad are being or have been fixed.
will it run xeyes?
"1) NO ONE programs with xlib"
Speak for yourself pal - Xlib is very useful for certain tasks. I've written a number of utilities and simple games in it.
*Most* people might not use it but *most* people don't code in assembler - that doesn't mean nobody does.
So says the developer himself: http://hoegsberg.blogspot.com/2008/11/premature-publicity-is-better-than-no.html
Well that's probably what he ment, you want the kernel to switch to one mode after booting up and then use that all the way until all your desktop icons are loaded. I believe Mac hardware does this in firmware.
But as the great-grandson of a blacksmith, I can tell you that Wayland is the archetypal smith of English mythology. In our town, which was established during the Dark Ages, and where metalworking is still a significant industry, the little road that led to the smithy is still named Waylands.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
Open an explorer window in Windows. Resize it. Notice the flicker and rendering artifacts. Open a Nautilus window in GNOME. Resize it. Notice the horrible flicker and rendering artifacts. This is without compositing. With it, you get other artifacts.
It doesn't matter what program or what machine you are using. You can compare the same thing using Firefox in Windows and Linux. A much slower Windows machine produces redraws with far fewer artifacts than a high-end Linux box. Since Windows does it better, the must be something wrong with X.
Football Odds
There is a big problem I have with X.org server since 1.5 series (1.3 in Fedora 8 is OK): booting the secondary card. I have a dual-seat desktop (two monitors, two keyboards, and two mice), and it is not possible to use it with X.org 1.5 server, because the code for booting the secondary card via the "int10" interface has been broken since 1.5 (see bug#18160). And it seems the X.org developers have no intention of fixing it, and they instead do marginal but new things like MPX. After all, new is cool, while fixing the bugs in the old code is not.
So, will Wayland work also on secondary cards?
-Yenya
--
While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
It seems that "compositing" and "compositor" have become the buzzwords of the month. I can't count how many times they've appeared on my screen in the past few weeks. But attempts to determine what any particular writer means by them generally don't succeed. Any idea what might be meant in this case that's different from what, say, X Windows (or Y Windows or ...) does?
Of course, I asked google to "define:compositing". Lots of definitions; none of them very helpful. Thus, I suspect that "A method of reducing the number of drill hole intervals within a database to intervals of equal length for a given drill hole" isn't what was meant here. Nor was "In deliberative procedure, compositing is the process of combining several motions into one composite motion", I'd guess. "The process of combining two or more images to yield a resulting, or 'composite' image" works, obviously, because every graphics app ever written does that. A dumb terminal that draws two characters on its screen does that. But I don't see any clues pointing to what's meant in TFA.
Are these just empty marketing buzzwords, or are they actually describing something that we should pay attention to?
(Of course, I expect a flood of responses with orthogonal definitions and/or vague descriptions that don't clarify much of anything. ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
This guy should set up a donations page... I would be excited to support this kind of project. I certainly hope he keeps it up!
People may wish to have a look at DirectFB: directfb.org
""At the same time, I'm trying to fix some of the problems with composite that we still have in the X server; input redirection, window resizing, syncing to vblank, throttling of animations and atomic, consistent redrawing. X specifies what the end results of a series of rendering requests must look like, but how the display looks while it's in progress is not discussed. GTK+ and Qt works around this to some extent by using double buffering, but we still see lag between window decorations and window contents while resizing etc. The wayland tag line is "every frame is perfect", by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker."
This single, and seemingly minor, problem, is a big part of what gives a Linux desktop that "homemade" feel to me. Things just don't quite behave right in transition. When I maximize a window there's this funky split second transitional period where things go funky and then snap back together after the operation is complete. Window contents do the same when resizing. Almost as if the program can't make up it's mind on where to put stuff.
Honestly, even though I've seen several other projects make similar claims and then fade away, if we can get this new graphics system up, running, well adopted, and well supported (as in video drivers), then this would really take Linux to a new level.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
I think the OLPC project has chosen a great software stack that has all the advantages of NeWS/PostScript.
Python is a great substitute for the PostScript programming language, and Cairo is a great substitute for the PostScript rendering model.
At that level, you can basically ignore all the stuff underneath, whether it's X-Windows and GTK, Microsoft Windows and DirectX or Mac OS/X and Cocoa. Python+Cairo also runs on "headless" web servers, for generating dynamic graphics.
-Don
Take a look and feel free: http://www.PieMenu.com
X: The First Fully Modular Software Disaster:
...A mistake carried out to perfection. X-Windows: ...Dissatisfaction guaranteed. X-Windows: ...Don't get frustrated without it. X-Windows: ...Even your dog won't like it. X-Windows: ...Flaky and built to stay that way. X-Windows: ...Complex nonsolutions to simple nonproblems. X-Windows: ...Flawed beyond belief. X-Windows: ...Form follows malfunction. X-Windows: ...Garbage at your fingertips. X-Windows: ...Ignorance is our most important resource. X-Windows: ...It could be worse, but it'll take time. X-Windows: ...It could happen to you. X-Windows: ...Japan's secret weapon. X-Windows: ...Let it get in *your* way. X-Windows: ...Live the nightmare. X-Windows: ...More than enough rope. X-Windows: ...Never had it, never will. X-Windows: ...No hardware is safe. X-Windows: ...Power tools for power fools. X-Windows: ...Putting new limits on productivity. X-Windows: ...Simplicity made complex. X-Windows: ...The cutting edge of obsolescence. X-Windows: ...The art of incompetence. X-Windows: ...The defacto substandard. X-Windows: ...The first fully modular software disaster. X-Windows: ...The joke that kills. X-Windows: ...The problem for your problem. X-Windows: ...There's got to be a better way. X-Windows: ...Warn your friends about it. X-Windows: ...You'd better sit down. X-Windows: ...You'll envy the dead.
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html
X-Windows:
Take a look and feel free: http://www.PieMenu.com
if you swap your monitor from 1024x768 to 1280x1024 30 times a second, MAYBE this would be a problem.
Otherwise, I'd put this as a problem looking for a reason.
There, that for ya.
There, that for ya.
The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid.
-Don
PS: I do like the stuff that's been done pulling the good code out of X and developing decent libraries like Cairo!
Take a look and feel free: http://www.PieMenu.com
Uglier than goatse.cx:
http://www.donhopkins.com/home/catalog/unix-haters/x-windows/XCalc.gif
That's what used to happen when you resize XCalc several times in a row. No wonder they call it the X-Stoolkit!
-Don
Take a look and feel free: http://www.PieMenu.com
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html
-Don
Take a look and feel free: http://www.PieMenu.com
I've been very critical of linux the past couple years, and this looks like the first real step in the right direction. I was excited when Mark Shuttleworth started pouring money into linux, only to be hugely disappointed when he couldn't steer the distro in one clear and concise direction, instead having to support a million different sub-distros.
Similes are like metaphors
WHAT IS YOUR DISPLAY?
/* Black. */
/* Whoops! No, I mean: */
/* AAAYYYYEEEEE!! */
/* Is that a SubStructureRedirectMask or a ResizeRedirectMask? */
display = XOpenDisplay("unix:0");
WHAT IS YOUR ROOT?
root = RootWindow(display, DefaultScreen(display));
AND WHAT IS YOUR WINDOW?
win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1,
BlackPixel(display, DefaultScreen(display)),
WhitePixel(display, DefaultScreen(display)));
OH ALL RIGHT, YOU CAN GO ON.
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
WHAT IS YOUR COLORMAP?
cmap = DefaultColormap(display, DefaultScreen(display));
AND WHAT IS YOUR FAVORITE COLOR?
favorite_color = 0;
favorite_color = BlackPixel(display, DefaultScreen(display));
(client dumps core & falls into the chasm)
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
WHAT IS YOUR VISUAL?
struct XVisualInfo vinfo;
if (XMatchVisualInfo(display, DefaultScreen(display),
8, PseudoColor, &vinfo) != 0)
visual = vinfo.visual;
AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST?
WHAT??! HOW AM I SUPPOSED TO KNOW THAT?
AAAAUUUGGGHHH!!!!
(server dumps core & falls into the chasm)
Take a look and feel free: http://www.PieMenu.com
198?-1983: V
1983-1984: W Window System
1984-1986: X1 - x10
1987-2008: X11
2008: Wayland?
Sorry, but I won't use it unless it is called X12 or Y.
Free unix account: freeshell.org
To quote Kristian Hogsberg's blog:
They got the headline wrong, though, it's not a new X server, it's a tiny display server + compositing manager. And it's a very young project with a lot of FIXMEs and hand waving.
and
The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server. One of the goals is to get an X server running on Wayland, first in a full screen window (like Xnest), then rootless, since X just isn't going aways anytime soon. Many more details in the NOTES file of the project.
Not an X server. Yet another attempt at a new window system. It's a pity it's not a new XServer. I'd love to see the original X concept modernized and called X12. A fast, network-transparent window system.
Most of the people calling for X replacements want to remove exactly what makes X cool and why it was originally used..... network transparency.