Until we start seeing accelerated graphics drivers (KGI exists, but it hasn't really been "adopted") for something more general than XFree86 servers, you won't see any serious graphical environments adopted on Linux besides X. Handheld _or_ desktop.
Although... in the case of handhelds, it's certainly quite possible to get by on just the framebuffer, so I dunno.
Because a distant government, as point out, is far away from local interest which also means that it cannot hold its citizens in as tight a grip as a local, well informed government.
You mean like China? Not exactly my first choice for personal freedoms, even if they have become capitalist and relatively democratic now.
The bigger the empire, the more difficult revolution is, as well. They have a LOT more military and police resources.
Most modern revolutions against larger empires have only managed with external help (including the American Revolution), and they only extended to part of the empire. When there is no external help (e.g. the entire government is global), you're fucked.
Especially if it is not a blatantly totalitarian government but has to play by at least some rules.
...and you're living in a dream world if you think any government has to play by any rules. If you study history, you'll find that all governments eventually reach a point where the only option is revolution, unless the civilization collapses or is conquered first.
It's easier to disappear in a crowd of a few billion than in a country with few million inhabitants, informed authorities and well controlled borders. Even in the totalitarian Soviet Union you could hide from the authorities in the chaotic southern states or vast Siberia.
I think you also don't seem to realize how much harder it's become to actually hide anywhere in the past 50 years.
Even if it were easier to hide, I don't want to have to become an outlaw for the sake of freedom in the first place.
The abolishment of individual nations and all the crap that comes with nationalism is here.
I'd like you to think very, very carefully about what it's being replaced with. I don't think a single monolithic totalitarian state (as far removed as possible from local interests, even) is such a good thing. Many of these international institutions are very far removed from any sort of direct democratic process.
(Where was the slot for e.g. "UN Representative" on your last ballot? [you do vote, right?])
I think that at best we're exchanging one load of crap for another, and possibly a worse load of crap at that.
...but most probably you will only ever sell one copy of your program.
[ incredulous "hello, earth to Stary" look ]
That... just hasn't been happening, though...
You can even buy, for example, RH CDs without any mote of support and -- get this -- people are still buying them. Lots of Free Software-oriented companies actually make some (or nearly all -- i.e. Cheapbytes) of their money from continuously selling software-on-media-with-no-support.
Hell, RH even puts RPMs and even ISO images up on their site so people can download and/or burn their own, and people STILL buy CDs from them.
People even buy DEBIAN CDs for crying out loud -- there's NEVER any support for those, and Debian's a distro where apt-get mostly removes the need for a local copy on CD anyway...
Apparently, it's suprisingly difficult to saturate the market for copies of a particular piece of software.
Putting all your eggs in one basket is never a good idea.
You got that right. Yet another reason why a monolithic Linux-dominated IT world will be an unmitigated disaster, if we're ever unlucky enough to end up with it.
But really, shouldn't we all just be slagging Microsoft here??
I'd much rather not see monolithic anything (although Jeppe does make some good points in his reply, which I'll have to think about).
Since you brought it up, though, if I was forced to choose a monolithic environment, I'm not sure that a Linux-dominated IT world would be worse than the current Windows-dominated one.
Although I've seen some stupid things done on both sides, at least on the Linux/Unix side, you see coders actually bothering to do simple things like putting their VB implementations in security sandboxes (i.e. Gnome Basic).
diversity also = smaller chance of finding a particular exploit, thus restricting (and in some cases stopping) the transmission of a particular virus that can only use a limited set of exploits.
As a corrorlary to this, given sufficient diversity, it becomes impractical for a particular virus to carry the code necessary to infect all of the availible machines.
Putting all your eggs in one basket is never a good idea. You might be a smaller target, but if you do get hit (and it's foolish to think you're invulnerable), you're automatically 100% dead.
Among other things, this is borne out by quite a few thousand years of agricultural experience.
You'd be hard-pressed to find any farmers or biologists who would argue that monoculture is the best way to limit your vulnerablity to crop diseases, just because there are fewer possible diseases that could infect your crops.
Okay, so, my password is permanently attached to my body and I can't change it, but anyone can use a password-equivalent hash to falsify my identity/authorization?
...and this sort of scanner may even be able to detect emotional distress.
So, if I need to log in for some really important reason (e.g. I want to log back in before the rm -rf / does too much more damage), your system will detect that, and prevent me from logging in?
Re:extensions don't kill people, legacy kills peop
on
X Windows Must Die!
·
· Score: 2
Is there actually software out there that won't run if particular extensions aren't available?
Among other things, all window managers (ICCCM), and any X application that displays text.
Because the different formats are fairly deeply different. For example, you simply can not do a lossless type 1 to true type conversion. TrueType to Type1 is also potentially lossy because the hinting is lost.
I'm not talking about conversion; I'm talking about exposing generic programmatic interfaces. I'm aware of the differences between the font formats -- another example being some use 4-control-point Bezier curves (Type1), others use e.g. b-splines. In that particular case, the exported interface just has to be able to represent both.
Most of the time, it'd be stuff more like "give me handle for a a glyph object", "rasterize this glyph to this bitmap with these transformations", and the like, anyway. 90% of the time, the client won't care about the acutal outlines, and if it does, it can get them in data structures that manage a superset of the features availible in the supported font formats. The hinting engine would remain hidden behind a layer of abstraction.
The other systems you speak of tend to use only one format -- True Type.
Oh? What are all these Type 1 fonts doing laying around?
The printer ( or the printing system ) needs the outline files ( for example, postscript and PCL printers render fonts by themselves -- from the outlines. )
That's a good point... but see below.
So this idea of doing everything on the server side is just plain wrong, because you really need fonts on the client as well.
You do need to be able to access the fonts from the client. That says nothing of where they're actually stored. IMO, the ideal setup would be if you could ask the font server for a set of glyphs (a font "extract", if you will) in the requested native format (generally for sending to a printer or similar), or in a "generic" format for doing programmatic stuff with the glyph outlines (e.g. "Text to Outline" in Illustrator). It would select from the native font files availible, otherwise convert. Conversion sucks but it's better than nothing.
And the printing system resides on the same machine as the client, not the X server.
Actually, the printing system is not always on the client, either, on many Unix networks. You either embed the Postscript (or whatever) fonts in the document, or hope that the remote printer has them availible.
It's also very nice to be able to use the same imaging model for printing as for graphical display. Berlin (eventually), DPS and Quartz do this. X isn't really well suited to it.
BTW, if the X protocol is truly extensible, it begs the question -- why not just redo the font handling part of X and leave the rest of it. I'd certainly agree that X's font handling could be improved.
Because no existing X software that displayed text (in any fashion) would be compatible with the new font system. The X protocol is extensible, but the problem is that the last 10 years of software or so relies on an extension that is itself not extensible.
Do you feel like supporting two mostly redundant and mutually incompatible font systems at once?
If the X font protocol had been designed extensibly, there's no reason it shouldn't be possible to add facilities for retrieving font metrics and so forth.
Why should outline fonts be dependent on a particular file format, anyway? Other systems manage just fine with a generalized abstraction -- there's no reason the introduction of a client/server architecture should change that.
If most X extensions were as extensible as the base protocol they were built on, there wouldn't be a problem.
By the way, what you describe is precisely what a lot of these apps that want their own font directories do.
extensions don't kill people, legacy kills people
on
X Windows Must Die!
·
· Score: 4
* checks * You're right. ~14 years, modulo some preliminary work. Sorry.
The problem is not the X protocol, nor its extensibility.
It's the extensions.
Most of the core X extensions and related protocols (the ICCCM stuff is really the worst offender by far, followed by the font stuff) are incredibly poorly designed, and not themselves particularly extensible.
Try discarding all the existing extensions and then rewriting them properly, on top of the existing X protocol. Assuming you did it right (and with 14 years of experience to refer to, it'll be easier), you'll end up with a very nice, clean, extensible system.
The only problem is, at that point, you either have to take all the old extensions back, or you may as well not bother calling it X, because it won't be compatible with anything.
Otherwise, you may as well just redo the X protocol a bit to fix the couple (minor) deficiencies it has... and... hrm... if you're going to be doing that, why not just scrap it completely and redesign from the ground up anyway?
It should, of course, be extensible.
Extensibility is a very good thing, but, like customizability, if it has to be used too much, then there's something fundamentally wrong with your original design (in this case, primarily the core extensions).
You act as if the font system were the only area in which X doesn't meet my needs. It's not.
What's really required to fix X is that the X implementation needs to be stripped back down to the base protocol, and the extensions and auxiliary protocols rebuilt from the ground up based on the lessons learned from the past 20 years or so.
We're too late for that, though. We can't afford to jettison compatibility with X11 and its standard set of extensions; there's too much legacy out there. It'd have to be kept around in the codebase too.
I don't feel like doubling the size of the codebase for only an incremental improvement in functionality.
Assuming I had the time (or got enough people interested in the open source project), even if I only addressed the font subsystem, it'd be the same problem, only on a smaller scale.
I may as well just contribute to something to replace X, and get X11 compatibility through an X server component that didn't have to be part of the base implementation.
What sucks about X fonts is they've (?) never fixed its shortcomings. If you have StarOffice, CorelDraw, Framemaker and Canvas, you' have 4 additional installed directories of fonts for each app. And most will be incompatible with the others.
Exactly; as I said, the X font subsystem simply does not meet the needs of these kinds of applications.
"What is bloated exactly? X the protocol is a very lean protocol (though very chatty), designed with extensibility and low-latency connections in mind. ie if you can't do it with X, then go write an EXTENSION."
... and therin lies the problem. We've been doing this for the past 20 years, and it's starting to add up. Almost everything in X is an extension now, and the code required to support them is really adding up.
There are a LOT more things wrong with X fonts than just the lack of the ability to anti-alias (which is really just eye-candy).
The problem with X is that you can't really get anything but glyph bitmaps from the fonts. Even when you're using a scalable font -- it still rasterizes the glyph at the requested size and then sends you a monochrome bitmap.
You can't get kerning info, you can't get unicode mapping tables, you can't get various other glyph metrics; the list goes on and on.
No arbitrary linear transformations of glyphs either -- at least not unless you want to do it yourself after-the-fact on a low-resolution monochrome bitmap.
Okay, let's say you request a glyph bitmap much larger than you actually need, so you can transform/antialias it and then scale down (this is what The GIMP does, for example).
Whoops. Most X font servers crap out above a certain glyph size. (last I tried, XFree86's did)
I'm a graphic designer and a programmer; I know what I need from a font subsystem to do more than simply display some text, and I know X's font subsystem would have to be replaced for me to get it from X.
(and note that thanks to the existing design, the replacement would have to be incompatible, or you'd have to implement both the old and new protocols, duplicating a lot of code... yay, bloat)
I would like to note that Berlin expects to have an X server component availible eventually. Obviously, you're going to have to be able to display X apps for a long time to come.
X support is a necessary evil, but that doesn't mean we should keep X as the primary desktop architecture.
Additionally, Berlin doesn't rely on any one kernel graphics architecture (or even there being one). I think right now they've got postscript, OpenGL and GGI display kits in various stages of completion. It's not really dependent on any one "Linux-specific" architecture.
Worst-case, on a commercial Unix with only an X server for graphics support, it can even display on that.
Unfortunately, this particular baby's grown into an immense, slimy, tentacled beast that's strangling the development of graphical technology on Unix.
I would like to note that I don't agree with some of the criticisms in the article -- for example, I think the componentization of the Window manager and various other items is generally a Good Thing. X wouldn't have survived as long as it has if something like the 80s-era window managers were part of the standard server.
While X has a lot of good points (network transparency, platform independence, flexibility in window management), those doesn't make up for its defects. It IS possible to design systems with these characteristics that don't have the downsides that X does.
The underlying X protocol is incredibly clean and extensible, but there are now so many (effectively mandatory) extensions that the code required to support them makes the X server software absolutely huge. ICCCM is a nightmare in its own right.
Moreover, many of these extensions/auxiliary protocols (a prime example would be the X font system) were not designed in the same forward-looking manner as the basic X protocol, meaning that it is necessary to replace, rather than enhance them. However, since existing software still relies on the old extensions, it's not possible to drop them -- you end up with even more redundant code bloat.
X doesn't really give you any choice with regard to widget toolkits, either. You're stuck with the one the app was compiled with, or, more often, coded soley against.
With an architecture like Berlin (or a number of others), it's possible replace the widget set in any or all all apps with the one of your choice -- on the fly.
There's also the problem that EVERY primitive operation in X requires the request to be marshalled/demarshalled across process boundaries.
The address space separation (and consequent easy network transparency) between client and server is not a bad thing, IMO, as it helps stability, but I belive the X designers made a fundamental mistake when they cut the client/server boundary at such a low level.
Having to do this sort of low-level chatting across process boundaries really hurts performance.
Architectures like Berlin maintain the client/server separation, but cut down on the performance hit by communicating at a significanty higher level of abstraction. This means a decently-written Berlin app, even if using a chunky protocol like IIOP, would create significantly less IPC traffic (in bytes) than the equivalent X app.
Of course X has DGA. X has shared memory. Unfortunately, those only work locally. If you rely on them, you just shot network transparency. Whoops.
And, there's another problem: instead of writing graphics drivers independent of any one application class or GUI architecture (which means basic kernel support), everyone's been writing drivers directly for the X server. (Thanks, XFree86!)
This means that to even reach a usable stage, every non-X project has to rewrite their own driver suite from scratch (as a rule, X drivers make too many assumptions about X for the code to be readily reusable for other things).
Although we have fbcon now, fbcon is pretty much unaccelerated, and doesn't have that broad a range of hardware coverage. Berlin is still mostly tested on top of X as a result.
If you have to keep X around to run Berlin, or face severely reduced hardware support, then what's the point?
X has been repeatedly marginalizing other graphical efforts this same way. (Who here has heard of Y Windows, for example? How many of you know someone who uses it? What hardware does it support?)
Thankfully, due to GGI, Berlin can run on fbcon and KGI -- if KGI ever becomes more widespread, Berlin might finally be able to break free of X.
It's time we stopped relying on the X server for everything graphical.
It's too late to throw out the bathwater, baby or no. It's outgrown the bathtub and eaten your dog.
Slashdot Mirror
Until we start seeing accelerated graphics drivers (KGI exists, but it hasn't really been "adopted") for something more general than XFree86 servers, you won't see any serious graphical environments adopted on Linux besides X. Handheld _or_ desktop.
Although... in the case of handhelds, it's certainly quite possible to get by on just the framebuffer, so I dunno.
[] patents
They have exactly what you need.
You mean like China? Not exactly my first choice for personal freedoms, even if they have become capitalist and relatively democratic now.
The bigger the empire, the more difficult revolution is, as well. They have a LOT more military and police resources.
Most modern revolutions against larger empires have only managed with external help (including the American Revolution), and they only extended to part of the empire. When there is no external help (e.g. the entire government is global), you're fucked.
...and you're living in a dream world if you think any government has to play by any rules. If you study history, you'll find that all governments eventually reach a point where the only option is revolution, unless the civilization collapses or is conquered first.
I think you also don't seem to realize how much harder it's become to actually hide anywhere in the past 50 years.
Even if it were easier to hide, I don't want to have to become an outlaw for the sake of freedom in the first place.
The WIPO is one of the common sorts of international organization; therefore: no real democratic representation, no due process, no appeal.
I'd like you to think very, very carefully about what it's being replaced with. I don't think a single monolithic totalitarian state (as far removed as possible from local interests, even) is such a good thing. Many of these international institutions are very far removed from any sort of direct democratic process.
(Where was the slot for e.g. "UN Representative" on your last ballot? [you do vote, right?])
I think that at best we're exchanging one load of crap for another, and possibly a worse load of crap at that.
[ incredulous "hello, earth to Stary" look ]
That ... just hasn't been happening, though...
You can even buy, for example, RH CDs without any mote of support and -- get this -- people are still buying them. Lots of Free Software-oriented companies actually make some (or nearly all -- i.e. Cheapbytes) of their money from continuously selling software-on-media-with-no-support.
Hell, RH even puts RPMs and even ISO images up on their site so people can download and/or burn their own, and people STILL buy CDs from them.
People even buy DEBIAN CDs for crying out loud -- there's NEVER any support for those, and Debian's a distro where apt-get mostly removes the need for a local copy on CD anyway...
Apparently, it's suprisingly difficult to saturate the market for copies of a particular piece of software.
I'd much rather not see monolithic anything (although Jeppe does make some good points in his reply, which I'll have to think about).
Since you brought it up, though, if I was forced to choose a monolithic environment, I'm not sure that a Linux-dominated IT world would be worse than the current Windows-dominated one.
Although I've seen some stupid things done on both sides, at least on the Linux/Unix side, you see coders actually bothering to do simple things like putting their VB implementations in security sandboxes (i.e. Gnome Basic).
diversity also = smaller chance of finding a particular exploit, thus restricting (and in some cases stopping) the transmission of a particular virus that can only use a limited set of exploits.
As a corrorlary to this, given sufficient diversity, it becomes impractical for a particular virus to carry the code necessary to infect all of the availible machines.
Putting all your eggs in one basket is never a good idea. You might be a smaller target, but if you do get hit (and it's foolish to think you're invulnerable), you're automatically 100% dead.
Among other things, this is borne out by quite a few thousand years of agricultural experience.
You'd be hard-pressed to find any farmers or biologists who would argue that monoculture is the best way to limit your vulnerablity to crop diseases, just because there are fewer possible diseases that could infect your crops.
Okay, so, my password is permanently attached to my body and I can't change it, but anyone can use a password-equivalent hash to falsify my identity/authorization?
greeeeaat...
So, if I need to log in for some really important reason (e.g. I want to log back in before the rm -rf / does too much more damage), your system will detect that, and prevent me from logging in?
Among other things, all window managers (ICCCM), and any X application that displays text.
Because we haven't replaced X yet.
I'm not talking about conversion; I'm talking about exposing generic programmatic interfaces. I'm aware of the differences between the font formats -- another example being some use 4-control-point Bezier curves (Type1), others use e.g. b-splines. In that particular case, the exported interface just has to be able to represent both.
Most of the time, it'd be stuff more like "give me handle for a a glyph object", "rasterize this glyph to this bitmap with these transformations", and the like, anyway. 90% of the time, the client won't care about the acutal outlines, and if it does, it can get them in data structures that manage a superset of the features availible in the supported font formats. The hinting engine would remain hidden behind a layer of abstraction.
Oh? What are all these Type 1 fonts doing laying around?
That's a good point... but see below.
You do need to be able to access the fonts from the client. That says nothing of where they're actually stored. IMO, the ideal setup would be if you could ask the font server for a set of glyphs (a font "extract", if you will) in the requested native format (generally for sending to a printer or similar), or in a "generic" format for doing programmatic stuff with the glyph outlines (e.g. "Text to Outline" in Illustrator). It would select from the native font files availible, otherwise convert. Conversion sucks but it's better than nothing.
Actually, the printing system is not always on the client, either, on many Unix networks. You either embed the Postscript (or whatever) fonts in the document, or hope that the remote printer has them availible.
It's also very nice to be able to use the same imaging model for printing as for graphical display. Berlin (eventually), DPS and Quartz do this. X isn't really well suited to it.
Because no existing X software that displayed text (in any fashion) would be compatible with the new font system. The X protocol is extensible, but the problem is that the last 10 years of software or so relies on an extension that is itself not extensible.
Do you feel like supporting two mostly redundant and mutually incompatible font systems at once?
If the X font protocol had been designed extensibly, there's no reason it shouldn't be possible to add facilities for retrieving font metrics and so forth.
Why should outline fonts be dependent on a particular file format, anyway? Other systems manage just fine with a generalized abstraction -- there's no reason the introduction of a client/server architecture should change that.
If most X extensions were as extensible as the base protocol they were built on, there wouldn't be a problem.
By the way, what you describe is precisely what a lot of these apps that want their own font directories do.
* checks *
You're right. ~14 years, modulo some preliminary work. Sorry.
The problem is not the X protocol, nor its extensibility.
It's the extensions.
Most of the core X extensions and related protocols (the ICCCM stuff is really the worst offender by far, followed by the font stuff) are incredibly poorly designed, and not themselves particularly extensible.
Try discarding all the existing extensions and then rewriting them properly, on top of the existing X protocol. Assuming you did it right (and with 14 years of experience to refer to, it'll be easier), you'll end up with a very nice, clean, extensible system.
The only problem is, at that point, you either have to take all the old extensions back, or you may as well not bother calling it X, because it won't be compatible with anything.
Otherwise, you may as well just redo the X protocol a bit to fix the couple (minor) deficiencies it has... and... hrm... if you're going to be doing that, why not just scrap it completely and redesign from the ground up anyway?
It should, of course, be extensible.
Extensibility is a very good thing, but, like customizability, if it has to be used too much, then there's something fundamentally wrong with your original design (in this case, primarily the core extensions).
You act as if the font system were the only area in which X doesn't meet my needs. It's not.
What's really required to fix X is that the X implementation needs to be stripped back down to the base protocol, and the extensions and auxiliary protocols rebuilt from the ground up based on the lessons learned from the past 20 years or so.
We're too late for that, though. We can't afford to jettison compatibility with X11 and its standard set of extensions; there's too much legacy out there. It'd have to be kept around in the codebase too.
I don't feel like doubling the size of the codebase for only an incremental improvement in functionality.
Assuming I had the time (or got enough people interested in the open source project), even if I only addressed the font subsystem, it'd be the same problem, only on a smaller scale.
I may as well just contribute to something to replace X, and get X11 compatibility through an X server component that didn't have to be part of the base implementation.
Exactly; as I said, the X font subsystem simply does not meet the needs of these kinds of applications.
"What is bloated exactly? X the protocol is a very lean protocol (though very chatty), designed with extensibility and low-latency connections in mind. ie if you can't do it with X, then go write an EXTENSION."
... and therin lies the problem. We've been doing this for the past 20 years, and it's starting to add up. Almost everything in X is an extension now, and the code required to support them is really adding up.
We have to worry about meeting bills under the current system anyway.
Only a VERY, VERY small minority of musicians (and to a lesser extend writers) can live off of royalties.
If I could get paid for my work so that I didn't have to worry about royalties (which you can't really predict in advance), that'd be great.
There are a LOT more things wrong with X fonts than just the lack of the ability to anti-alias (which is really just eye-candy).
... yay, bloat)
The problem with X is that you can't really get anything but glyph bitmaps from the fonts. Even when you're using a scalable font -- it still rasterizes the glyph at the requested size and then sends you a monochrome bitmap.
You can't get kerning info, you can't get unicode mapping tables, you can't get various other glyph metrics; the list goes on and on.
No arbitrary linear transformations of glyphs either -- at least not unless you want to do it yourself after-the-fact on a low-resolution monochrome bitmap.
Okay, let's say you request a glyph bitmap much larger than you actually need, so you can transform/antialias it and then scale down (this is what The GIMP does, for example).
Whoops. Most X font servers crap out above a certain glyph size. (last I tried, XFree86's did)
I'm a graphic designer and a programmer; I know what I need from a font subsystem to do more than simply display some text, and I know X's font subsystem would have to be replaced for me to get it from X.
(and note that thanks to the existing design, the replacement would have to be incompatible, or you'd have to implement both the old and new protocols, duplicating a lot of code
I would like to note that Berlin expects to have an X server component availible eventually. Obviously, you're going to have to be able to display X apps for a long time to come.
X support is a necessary evil, but that doesn't mean we should keep X as the primary desktop architecture.
Additionally, Berlin doesn't rely on any one kernel graphics architecture (or even there being one). I think right now they've got postscript, OpenGL and GGI display kits in various stages of completion. It's not really dependent on any one "Linux-specific" architecture.
Worst-case, on a commercial Unix with only an X server for graphics support, it can even display on that.
Unfortunately, this particular baby's grown into an immense, slimy, tentacled beast that's strangling the development of graphical technology on Unix.
I would like to note that I don't agree with some of the criticisms in the article -- for example, I think the componentization of the Window manager and various other items is generally a Good Thing. X wouldn't have survived as long as it has if something like the 80s-era window managers were part of the standard server.
While X has a lot of good points (network transparency, platform independence, flexibility in window management), those doesn't make up for its defects. It IS possible to design systems with these characteristics that don't have the downsides that X does.
The underlying X protocol is incredibly clean and extensible, but there are now so many (effectively mandatory) extensions that the code required to support them makes the X server software absolutely huge. ICCCM is a nightmare in its own right.
Moreover, many of these extensions/auxiliary protocols (a prime example would be the X font system) were not designed in the same forward-looking manner as the basic X protocol, meaning that it is necessary to replace, rather than enhance them. However, since existing software still relies on the old extensions, it's not possible to drop them -- you end up with even more redundant code bloat.
X doesn't really give you any choice with regard to widget toolkits, either. You're stuck with the one the app was compiled with, or, more often, coded soley against.
With an architecture like Berlin (or a number of others), it's possible replace the widget set in any or all all apps with the one of your choice -- on the fly.
There's also the problem that EVERY primitive operation in X requires the request to be marshalled/demarshalled across process boundaries.
The address space separation (and consequent easy network transparency) between client and server is not a bad thing, IMO, as it helps stability, but I belive the X designers made a fundamental mistake when they cut the client/server boundary at such a low level.
Having to do this sort of low-level chatting across process boundaries really hurts performance.
Architectures like Berlin maintain the client/server separation, but cut down on the performance hit by communicating at a significanty higher level of abstraction. This means a decently-written Berlin app, even if using a chunky protocol like IIOP, would create significantly less IPC traffic (in bytes) than the equivalent X app.
Of course X has DGA. X has shared memory. Unfortunately, those only work locally. If you rely on them, you just shot network transparency. Whoops.
And, there's another problem: instead of writing graphics drivers independent of any one application class or GUI architecture (which means basic kernel support), everyone's been writing drivers directly for the X server. (Thanks, XFree86!)
This means that to even reach a usable stage, every non-X project has to rewrite their own driver suite from scratch (as a rule, X drivers make too many assumptions about X for the code to be readily reusable for other things).
Although we have fbcon now, fbcon is pretty much unaccelerated, and doesn't have that broad a range of hardware coverage. Berlin is still mostly tested on top of X as a result.
If you have to keep X around to run Berlin, or face severely reduced hardware support, then what's the point?
X has been repeatedly marginalizing other graphical efforts this same way. (Who here has heard of Y Windows, for example? How many of you know someone who uses it? What hardware does it support?)
Thankfully, due to GGI, Berlin can run on fbcon and KGI -- if KGI ever becomes more widespread, Berlin might finally be able to break free of X.
It's time we stopped relying on the X server for everything graphical.
It's too late to throw out the bathwater, baby or no. It's outgrown the bathtub and eaten your dog.
It's time to break out the napalm...
um, perhaps because fewer than 50% of computer users are script kiddies? (although some days I do wonder...)
... or are you using some definition of "minority" that's not in the dictionary?
Careful with your wording, there; connotations can be tricky things.
I think you meant something more like:
"I believe that musicians ought to actually get paid for doing their work[, rather than being forced to live off of royalties]"
Is that the case? If so, yes, I'd agree.
... and then the minority with rootkits can take advantage of the apathy of corporate software engineers.