Not this libertarian garbage again. So it's okay for a corporation to tread upon workers, pay them less than a living wage, force them to work long hours, and conspire to drive up prices for the goods they need, but heaven forbid the government get involved and regulate?
Oh, and I hate to reply to myself, but from the article:
Lofstrom estimates that an initial loop costing roughly $10 billion with a 1 year payback could launch 40,000 metric tons per year, and cut launch costs to $300/kg, or for $30 billion, with a larger power generation capacity, the loop would be capable of launching 6 million metric tons per year, and given a 5 year payback period, the costs for accessing space with a launch loop could be as low as $3/kg.
Or a launch loop, which is a practical alternative to a space elevator that doesn't require exotic materials. Not that it'll happen in this "no we can't do it, think of the {amoebas,corporations,children}!" age.
That's not quite true. The knob you're manipulating controls whether foreground processes receive a priority boost. The scheduling algorithm remains the same regardless.
That's a misguided attitude. The fewer knobs a system has, the better. We should make systems auto-tuning whereever possible. A scheduler should be able to detect the kind of workload it is being used for and adjust itself accordingly. In fact, that's exactly what CFS does.
Here's a simple heuristic: assign to each person a starting score of five. Each time someone uses "LOL" is a variation thereof in fleeting conversation, subtract one point. For each instance of "LOL" in a fixed medium (like an FAQ), subtract three. For "fail" used as a noun, subtract five. If that score dips below zero, there's a damn good chance that the person in question doesn't have anything valuable to contribute to anything I care about.
because 'snappyness' cannot be measured. It is much too subjective.
That's irrational bullshit. If you can perceive it, it can be measured. If you think you can perceive it, but can't find a way to measure it, you're probably not actually seeing anything at all, but suffering from observer bias.
ck's advocates are suffering from observer bias. They try his scheduler, and since they know they're trying his scheduler, and since we have a cognitive bias toward seeing what we expect to find, of course they claim it feels "snappier". Of course they can't bring up numbers to support this perception because there is no real effect.
You're honestly claiming that X couldn't be replaced by something significantly smaller, faster, and less-bloated?
Not significantly so, not with the same feature-set.
That the server-client paradigm makes sense for a software package where 99.9% of the users are running the client and the server on the same computer?
Separation of responsibilities is good software design practice. In reality, no matter what architecture you choose, you're going to need to separate out display and window management from application code. OS X, for example, has a WindowServer; Windows has various bits. The fact is that the network-transparent aspects of X11 simply don't add any overhead where it counts.
That there hasn't been a meaningful advance in fundamental graphical interface programming in the TWENTY TWO YEARS since the X11 protocol was instituted?
We're not using Xt and Motif anymore. Of course there's been advancement. But there is no need to discard what works: like I said, newer isn't automatically better.
That a system that allows (no, REQUIRES) multiple layers to add functionality is automatically superior (because of its "freedom") than one that handles some higher level stuff itself at the cost of mild restrictions on developers? Then why was BeOS so much faster and responsive than the X at the time?
That's funny. When we allow (no, REQUIRE) applications to go through "multiple layers" to reach fixed storage, we praise various filesystems and the VFS mechanism. By your logic, the operating system should do as little as possible to carve out sections of raw disk for applications to use and get out of the way. That's ridiculous.
BeOS was faster because it was a good all-around implementation.
Yes, you can blame KDE or Gnome or Adobe or even linux, but the fact remains that after tens of thousands of people developing for it, and millions of dollars invested in it, X is still a hell of a lot slower, harder to use, and buggy than it should be.
Err, maybe it is the fault of the entire desktop stack? Nice way to casually dismiss a good point. X11 itself is not the reason behind the bug you're complaining about in your favorite desktop environment. X11 has nothing to do with how "easy to use" an application is, for example.
Just like I said, you're using X11 as a whipping boy when your real problem lies with some other piece of software.
If the tool to configure X doesn't work, then X doesn't work. The UI *is* the application.
This statement is ridiculous. The argument I'm countering is "X11 sucks as a protocol and as a system, so let's throw it out and start over". That a particular GUI tool is deficient is no argument that X11 itself is broken. It's like saying a compiler is broken because of a problem with an IDE dialog box: why would you rewrite the compiler?
This request rasterizes the list of triangles in the order they
occur in the list.
and a poorly accelerated one.
There you go again, confusing implementation with core concepts. And in fact, render is accelerated well today, especially with modern drivers that use the EXA acceleration hooks.
It has been shown that X performs poorly remotely,
The passive voice is the universal voice of people who want to misdirect. X performs well remotely, and has for decades. What would you change, exactly, what would make it better? It's easy to claim that a technology is deficient, but much harder to show that it can be better.
If you want one command to rebuild your whole system, install Gentoo or a BSD. Or, just maybe, you can fucking think about what exactly it is that you want to change and recompile only the module you need to implement that change. On the other hand, that's not going to happen. Like most people who use "epic fail", you're an idiot.
No, it is your post that is full of bullshit. The facts are that X performed well on the hardware for which it was designed, which had a miniscule fraction of what's available today. That it crawled on something even slower than what it was designed for makes no difference.
As for unaccelerated rendering, the reason that's slow is that unaccelerated graphics work is inherently slow. You can only draw a box so quickly with a given hardware interface. X11 does the best job with what it has in that case. How can you complain, then, that X is slow when it's really the hardware that's slow?
As for X's "inherent design flaw" --- asynchronous operation (of which you have a muddle understanding) is not inherently bad. Far from having to wait for confirmation, the client sends a string of commands, and then, at some later time, might be notified that one of these commands failed. Since command failure is exceedingly rare, it doesn't matter. An application could wait for each command to complete successfully before sending the next, and that's what some applications and toolkits do when the user asks for synchronous operation. That's only useful for debugging, however: in practice, X11's asynchronous model is good for performance.
Each time a GUI does something unexpected, you can bet that you just experienced an X11 race condition.
It doesn't support a complete server-side 2D vector rendering interface, so that rasterizing didn't have to happen on clients and be sent over the wire.
It doesn't support forwarding audio or devices. When it's handled by separate apps, like pulseaudio, it requires setting up separate connections. It doesn't integrate dbus, so if you wanted remote apps to connect to a local bus, you need to setup a separate connection.
That's a legitimate criticism of the system as a whole, but it's not the job of X11 to handle audio. In other words, how is this an argument for throwing out X? If anything, it's an argument for An X11 extension for audio, which, IMHO, is a good idea in principle.
All that article shows is that Gosling's career had crested by 2002. His "new" design is spectacularly bad: it's essentially a lightly-moderated raw-framebuffer-access model of the kind that preceded X11. In Gosling's new model, for example, applications are supported to draw their own window borders.
What happens when an application freezes? Do you need to resort to a Windows-style dummy-window hack to retain control of the rest of the system? What about UI consistency? What about stacking policy? In Gosling's model, each toolkit needs to incorporate the functionality that is today handed by the window manager. It's terrible.
Yes, in principle, you could use a shared library and some PAM-like facility to control window policy, but that only works on the local machine. Remote applications would become even more inconsistent.
First of all, even raw X11 performance is perfectly adequate over a 10mbit LAN. That's the environment it was designed for, after all. If anyone doubts that it works, why not try it? With NX, X11 screams over even a dialup connection.
First of all, a "GUI" refers to what the user sees, not how that's implemented. There is no piece of software anywhere that provides a "GUI". What you're talking about is a toolkit. Toolkits have converged already in terms of functionality and appearance.
If you want to port to "Linux" (or really, Unix-like systems in general), you use GTK or QT these days. Period. You can argue about which toolkit is better, but the difference is arbitrary, and both are available under the permissive LGPL license.
Also, the X server is not licensed under the GPL, but under the X11 license, which permits practically anything, much like the BSD license. There are no "politics" involved with the X11 license. If your ignorance is so profound that you've never heard of the X11 license, one of the major Free Software licenses, you have no basis for commenting on the windowing system.
Apple, had it decided to extend X, would not have started using the Linux kernel, or any of the existing toolkits, but instead created an Aqua that simply talked to the X server the same way GTK and QT do today.
Oh, not this bullshit argument again. You lost it in 1990, you lost it in 1994, you lost it in 2003, and you're losing it again now.
First of all, GDI+ and Quartz have nothing to do with having "widgets in the server". They're drawing toolkits, comparable to Cairo or the QT vector stuff. In the GTK+ case, there isn't a separate "server" in which to run widgets. The OP is correct in stating that no current system does what you propose.
Second, you're confusing the benefits of having a common toolkit with those of having "widgets in the server". The advantage of the latter is a very slight latency decrease across a network connection. That's it. The complexity doesn't warrant the benefit, and X works just fine over a network connection without having the X server execute arbitrary bits of code.
Also, OS X has two major toolkits: Carbon and Cocoa. They're separate implementations. Argue if you'd like that GTK+ and Qt should look more visually alike, but that argument has nothing to do with X11.
Really, Linux should pull an Emacs and just use the last component of the version number as the version number. That way, we'll have Linux 30, Linux 31, and so on. (Four-component version numbers, as in 2.6.29.2 are ridiculous, especially when the first two components never change.)
X maps your video card's memory into its own address space, and that's reflected in its virtual size. If your video card has half a gigabyte of video memory, X's VSS will be at least half a gigabyte!
Also, leaks in other applications can make X appear to be bloated. For example, applications create pixmaps and send them to the X server for later use. The X server holds onto them on behalf of the client application. If the client forgets about one of these pixmaps, it will be X, not the application, which appears to have a leak. When the leaky client application terminates (or more precisely, when it disconnects from the X server), that memory will be reclaimed.
Bullshit. We've been using AM radio for over a century with no ill effects. Show me one study in a reputable peer-reviewed journal that supports your position and I might start to consider your ideas something other than rotting bullshit. Until then, go cavort with the Raellians and the homeopathy hawkers.
Remote X is a perfect example of just the bloat X contains.
Your "bloat" is a feature I use every day.
By the way, I always use remote VNC, and not Remote X. It has advantages like being usable over a WAN (not like X protocol)
I've yet to see a raster remote desktop protocol that's tolerable over anything slower than 10 megabit ethernet. Sure, in a pinch, I could use VNC , but it's painful. On the other hand, NX works just fine.
The problem is that OS X's X11 environment doesn't integrate well into the rest of the desktop. Apple could have done better: there's no particular reason all X applications need to be grouped under one icon in the Dock, or that the z-order needs to be royally screwed up. The window manager could differentiate based on X11 window class, for example. Apple's purpose was being able to claim X11 support, but in reality force anyone who wants a usable application to use AquaDrawingVectorCoreThingKit instead of cross-platform APIs.
Despite these shortcomings, X11 under OS X gets used all the time. Consider wireshark, for example.
Slashdot Mirror
Not this libertarian garbage again. So it's okay for a corporation to tread upon workers, pay them less than a living wage, force them to work long hours, and conspire to drive up prices for the goods they need, but heaven forbid the government get involved and regulate?
Oh, and I hate to reply to myself, but from the article:
Or a launch loop, which is a practical alternative to a space elevator that doesn't require exotic materials. Not that it'll happen in this "no we can't do it, think of the {amoebas,corporations,children}!" age.
That's not quite true. The knob you're manipulating controls whether foreground processes receive a priority boost. The scheduling algorithm remains the same regardless.
That's a misguided attitude. The fewer knobs a system has, the better. We should make systems auto-tuning whereever possible. A scheduler should be able to detect the kind of workload it is being used for and adjust itself accordingly. In fact, that's exactly what CFS does.
Here's a simple heuristic: assign to each person a starting score of five. Each time someone uses "LOL" is a variation thereof in fleeting conversation, subtract one point. For each instance of "LOL" in a fixed medium (like an FAQ), subtract three. For "fail" used as a noun, subtract five. If that score dips below zero, there's a damn good chance that the person in question doesn't have anything valuable to contribute to anything I care about.
That's irrational bullshit. If you can perceive it, it can be measured. If you think you can perceive it, but can't find a way to measure it, you're probably not actually seeing anything at all, but suffering from observer bias.
That's why we have double-blind controlled trials to test phenomena with slight effects.
ck's advocates are suffering from observer bias. They try his scheduler, and since they know they're trying his scheduler, and since we have a cognitive bias toward seeing what we expect to find, of course they claim it feels "snappier". Of course they can't bring up numbers to support this perception because there is no real effect.
That's why, in science, we use numbers.
Not significantly so, not with the same feature-set.
Separation of responsibilities is good software design practice. In reality, no matter what architecture you choose, you're going to need to separate out display and window management from application code. OS X, for example, has a WindowServer; Windows has various bits. The fact is that the network-transparent aspects of X11 simply don't add any overhead where it counts.
We're not using Xt and Motif anymore. Of course there's been advancement. But there is no need to discard what works: like I said, newer isn't automatically better.
That's funny. When we allow (no, REQUIRE) applications to go through "multiple layers" to reach fixed storage, we praise various filesystems and the VFS mechanism. By your logic, the operating system should do as little as possible to carve out sections of raw disk for applications to use and get out of the way. That's ridiculous.
BeOS was faster because it was a good all-around implementation.
Err, maybe it is the fault of the entire desktop stack? Nice way to casually dismiss a good point. X11 itself is not the reason behind the bug you're complaining about in your favorite desktop environment. X11 has nothing to do with how "easy to use" an application is, for example.
Just like I said, you're using X11 as a whipping boy when your real problem lies with some other piece of software.
This statement is ridiculous. The argument I'm countering is "X11 sucks as a protocol and as a system, so let's throw it out and start over". That a particular GUI tool is deficient is no argument that X11 itself is broken. It's like saying a compiler is broken because of a problem with an IDE dialog box: why would you rewrite the compiler?
Lies. Did you read the linked specification?
Triangles
op: PICTOP
src: PICTURE
src-x, src-y: INT16
dst: PICTURE
mask-format: PICTFORMAT or None
triangles: LISTofTRIANGLE
This request rasterizes the list of triangles in the order they
occur in the list.
There you go again, confusing implementation with core concepts. And in fact, render is accelerated well today, especially with modern drivers that use the EXA acceleration hooks.
The passive voice is the universal voice of people who want to misdirect. X performs well remotely, and has for decades. What would you change, exactly, what would make it better? It's easy to claim that a technology is deficient, but much harder to show that it can be better.
If you want one command to rebuild your whole system, install Gentoo or a BSD. Or, just maybe, you can fucking think about what exactly it is that you want to change and recompile only the module you need to implement that change. On the other hand, that's not going to happen. Like most people who use "epic fail", you're an idiot.
No, it is your post that is full of bullshit. The facts are that X performed well on the hardware for which it was designed, which had a miniscule fraction of what's available today. That it crawled on something even slower than what it was designed for makes no difference.
As for unaccelerated rendering, the reason that's slow is that unaccelerated graphics work is inherently slow. You can only draw a box so quickly with a given hardware interface. X11 does the best job with what it has in that case. How can you complain, then, that X is slow when it's really the hardware that's slow?
As for X's "inherent design flaw" --- asynchronous operation (of which you have a muddle understanding) is not inherently bad. Far from having to wait for confirmation, the client sends a string of commands, and then, at some later time, might be notified that one of these commands failed. Since command failure is exceedingly rare, it doesn't matter. An application could wait for each command to complete successfully before sending the next, and that's what some applications and toolkits do when the user asks for synchronous operation. That's only useful for debugging, however: in practice, X11's asynchronous model is good for performance.
That is an outright lie.
XRender
That's a legitimate criticism of the system as a whole, but it's not the job of X11 to handle audio. In other words, how is this an argument for throwing out X? If anything, it's an argument for An X11 extension for audio, which, IMHO, is a good idea in principle.
Unfortunately, most GUI configuration tools are absolutely horrid. I won't argue that.
For unequal-sized monitors, you can configure the outputs using xrandr, or for older systems, Xinerama.
All that article shows is that Gosling's career had crested by 2002. His "new" design is spectacularly bad: it's essentially a lightly-moderated raw-framebuffer-access model of the kind that preceded X11. In Gosling's new model, for example, applications are supported to draw their own window borders.
What happens when an application freezes? Do you need to resort to a Windows-style dummy-window hack to retain control of the rest of the system? What about UI consistency? What about stacking policy? In Gosling's model, each toolkit needs to incorporate the functionality that is today handed by the window manager. It's terrible.
Yes, in principle, you could use a shared library and some PAM-like facility to control window policy, but that only works on the local machine. Remote applications would become even more inconsistent.
First of all, even raw X11 performance is perfectly adequate over a 10mbit LAN. That's the environment it was designed for, after all. If anyone doubts that it works, why not try it? With NX, X11 screams over even a dialup connection.
Second, NX does support application sharing. I don't know where you're getting your information.
First of all, a "GUI" refers to what the user sees, not how that's implemented. There is no piece of software anywhere that provides a "GUI". What you're talking about is a toolkit. Toolkits have converged already in terms of functionality and appearance.
If you want to port to "Linux" (or really, Unix-like systems in general), you use GTK or QT these days. Period. You can argue about which toolkit is better, but the difference is arbitrary, and both are available under the permissive LGPL license.
Also, the X server is not licensed under the GPL, but under the X11 license, which permits practically anything, much like the BSD license. There are no "politics" involved with the X11 license. If your ignorance is so profound that you've never heard of the X11 license, one of the major Free Software licenses, you have no basis for commenting on the windowing system.
Apple, had it decided to extend X, would not have started using the Linux kernel, or any of the existing toolkits, but instead created an Aqua that simply talked to the X server the same way GTK and QT do today.
I have a Palm Pre because:
.
It's simple.
Oh, not this bullshit argument again. You lost it in 1990, you lost it in 1994, you lost it in 2003, and you're losing it again now.
First of all, GDI+ and Quartz have nothing to do with having "widgets in the server". They're drawing toolkits, comparable to Cairo or the QT vector stuff. In the GTK+ case, there isn't a separate "server" in which to run widgets. The OP is correct in stating that no current system does what you propose.
Second, you're confusing the benefits of having a common toolkit with those of having "widgets in the server". The advantage of the latter is a very slight latency decrease across a network connection. That's it. The complexity doesn't warrant the benefit, and X works just fine over a network connection without having the X server execute arbitrary bits of code.
Also, OS X has two major toolkits: Carbon and Cocoa. They're separate implementations. Argue if you'd like that GTK+ and Qt should look more visually alike, but that argument has nothing to do with X11.
Really, Linux should pull an Emacs and just use the last component of the version number as the version number. That way, we'll have Linux 30, Linux 31, and so on. (Four-component version numbers, as in 2.6.29.2 are ridiculous, especially when the first two components never change.)
X maps your video card's memory into its own address space, and that's reflected in its virtual size. If your video card has half a gigabyte of video memory, X's VSS will be at least half a gigabyte!
Also, leaks in other applications can make X appear to be bloated. For example, applications create pixmaps and send them to the X server for later use. The X server holds onto them on behalf of the client application. If the client forgets about one of these pixmaps, it will be X, not the application, which appears to have a leak. When the leaky client application terminates (or more precisely, when it disconnects from the X server), that memory will be reclaimed.
Bullshit. We've been using AM radio for over a century with no ill effects. Show me one study in a reputable peer-reviewed journal that supports your position and I might start to consider your ideas something other than rotting bullshit. Until then, go cavort with the Raellians and the homeopathy hawkers.
Your "bloat" is a feature I use every day.
I've yet to see a raster remote desktop protocol that's tolerable over anything slower than 10 megabit ethernet. Sure, in a pinch, I could use VNC , but it's painful. On the other hand, NX works just fine.
The problem is that OS X's X11 environment doesn't integrate well into the rest of the desktop. Apple could have done better: there's no particular reason all X applications need to be grouped under one icon in the Dock, or that the z-order needs to be royally screwed up. The window manager could differentiate based on X11 window class, for example. Apple's purpose was being able to claim X11 support, but in reality force anyone who wants a usable application to use AquaDrawingVectorCoreThingKit instead of cross-platform APIs.
Despite these shortcomings, X11 under OS X gets used all the time. Consider wireshark, for example.
It works fine these days. Plus, composite helps a lot.