You just want to start the client up as a specific user on bootup, right? That doesn't necessarily imply a login.
Probably what you want to do is stick something like su -c "rc5clientthingy --option blah" rc5user </dev/null 2>&1 >/dev/null & in one of your init scripts. Bonus points if you set up a full-blown SYSV script for it (a la/etc/rc.d/init.d).
You probably want this to start in runlevel 2, 3 or 4, as those are the "network-enabled" ones. (if you're using standard runlevel configurations)
One day they will run out of reserves and they'll have two choices. 1) Don't add any more features, no matter how important they may be or 2) break existing programs and change the layout.
Although the subnetting (sub-division of a parent network) features of IPv4 do not offer much flexibility, they have served to relieve congestion, ease management, and provide performance gains. These were meagre benefits, and did nothing to increase the effective number of addresses availible for allocation. Yet, they could still provide a way for the IETF to reduce the need to implement a new IP addressing scheme.
Crap isolation filter:
The subnetting features of IPv4 are inflexible and useless. They did reduce congestion, provide performance gains, and make management easier, but none of that matters because subnetting does provide any more addresses to allocate. However, the IETF can use subnetting to fix the current address shortage.
Crap removal filter:
IP subnetting can potentially be used to remove or reduce the need to implement a new IP addressing scheme, although that was not its original purpose.
Interpretation filter:
So far, IP subnetting has had limited usefulness. However, the IETF could take advantage of it to re-use individual IPs in different subnets. Doing so would at least temporarily remove the need to switch to IPv6.
Plain English filter:
Subnets aren't that useful. We should use the fields to get 4 more octets in our IP addresses instead.
Conclusion:
This guy is the most horrid writer I have ever encountered. I have known functional illiterates who could draft more readable and well-thought-out documents.
I strongly suspect that author was under the influence of multiple controlled substances at the time of the document's composition.
Dude, it's just a binfmt-esque hack... and it's even being phased out because binfmt does precisely the same thing, while being somewhat more general about it... ---
The owners of IRC servers ban abusive people, not programs - they will not ban you because of the IRC client you use.
That's not actually completely true; does anyone remember when Microsoft Comic Chat came out? It dumped all kinds of crap data in band (for the character emotions and so forth), such that it was extremely obnoxious to be in a channel with people using it. Having to put up with "(#WEIFEOU#@5*UR)" or some crap at the beginning of every send phrase got very annoying, very fast. You got 5 or so people in a channel using the client, and it basically killed the conversation for everyone else.
Even worse, in the first few versions, the CTCP implementation was severely broken -- it sent PRIVMSGs instead of NOTICEs for replies, which could have resulted in infinite loops between the two clients trying to respond to each other. (although it generally didn't, as that version of Comic Chat provided no way for a user to send CTCP messages... thankfully)
However, a lot of people still thought MS CC was really cute. Once they were using the client, they didn't really give a damn if they were dumping crap in channels -- they couldn't see it themselves, so why should they care? It finally got so bad that channel operators began to ban CC users on sight. Things continued to spiral downwards, though, and some IRC networks were compelled to politely (or often not so politely) ask people to stop using the Comic Chat client, "or else".
Today, although the functionality has, I believe, now been folded into the current Microsoft chat product, you won't see it used on normal IRC networks, nor is it a default. We won, but barely. It took a concerted effort on the part of the channel and server adminsitrators to preserve the networks for the rest of us.
I'm not really sure how or if this relates to the AOL/MS IM war, but I just felt like this little bit of history might be relevent somehow.
No, I didn't mean to imply that they could use it in that fashion either! The specific problems I was making reference to are:
1. it leaves our hypothetical dissident less time to hide/escape/destroy documents -- if they can just walk down the hall checking each room with the detector instead of bursting in and searching each one "manually" it goes a lot faster
2. even if the hypothetical dissident could conceal himself, it wouldn't do any good. They'd use the detector to sniff him out in the priesthole or whatever he was hiding in
There, happy? I'm not attributing magical powers to this thing, okay? ---
Fast operation string hashing algo or not - nothing beats an int lookup as is the case with X11's protocol. You cannot dispute this.
Indeed, I cannot; nor was I trying to do so. The thing is, though, one string hashing operation can probably pull even with about fifty int lookups or so.
While one operation over IIOP is slower than one over X, Berlin aims to use much fewer of them.
There's another factor to consider, too, which I just remembered something about -- if I remember correctly (and I could in fact be very wrong on this), IIOP is only used for inter-ORB communication. Intra-ORB communication doesn't have to use IIOP, and my understanding is that it generally doesn't -- i.e. each ORB has its own more optimal protocol, with IIOP being used as a more generic "fallback" for compatibility with other ORBs. Depending on the ORB, the ORB-specific protocol may compare more favorably with lighter-weight protocols.
Does Fresco use normal blocking (non-oneway) CORBA calls (forgive my ignorance) for most of its operations? If this is the case the socket round-trip time latancy will kill your remote performance. If use use oneway calls, on the other hand you risk not delivering the request. You lose both ways.
Whoa whoa whoa... I thought we were still talking about Berlin... the widget hierarchies and aspects of layout control were taken from Fresco, but from what I understand (I need to read up on Fresco more) Berlin modifies it a little and has an entirely different drawing model (much more like NeWS), and a somewhat lighter-weight event model. Based on my understanding of things, Berlin's guts are not that similar to Fresco at all.
As to your actual question, pretty much everything Berlin does over CORBA is two-way, to the best of my knowledge. FWIW, I'm really more of a hanger-on to the project than an architecture guy, so take my architectural statements with a grain of salt.
As for having the complete Fresco GUI lib linked dynamically via a shared lib into the client: true, the code of the shared lib is common to all processes, but the data associated with each "instance" of the shared lib is not. I concede this point is probably not much of an issue.
Yeah, that's what I meant about WSS. It's probably not large, but it is admittedly significant.
You may not believe this - but I like the idea of Fresco - it seems to be a rather elegant design. I merely disagree with its transport mechanism. Good luck with the project.
Thanks, but unless you meant that you liked the ideas which Berlin had inherited from Fresco, I think you have the wrong project in mind: Berlin != Fresco. You might be able to call it "Son of Fresco", but I'm not sure.:P
All we would do would be futzing around with configuration files and recompiling kernels to install the latest patches.
That's why you have one or two sysadmin guys on hand to do that stuff for them. In a corporate environment, the users generally don't and shouldn't have root on their desktop machines, and the users shouldn't have t be responsible for configuring and maintaining their machines.
1. X clients on the same machine as the X server use the shared memory extension and not translated over the wire.
Wrong. Show me something other than a game that does this for anything but displaying bitmapped images. Local or not, most operations still take a trip through a socket, Unix domain or otherwise. The only way you'll get the majority of graphics operations in a typical application to go through XSHM is to reimplement the entire set of X drawing primitinives yourself in your application, and scribble on the shared bitmap directly. And if you do that, you don't get to take advantage of availible 2d acceleration, either. It might actually end up being slower on a good accelerated X server.
2. CORBA is largely a glorified RPC hack that requires socket round-trips for each remote request (can you say slow?). Oneway calls don't help you here as they are unreliable by design - read OMG's CORBA specification. Each of CORBA's on the wire requests has a big header which includes the name of the remote function name - in ASCII no less! The longer the name of the remote function - the longer it will take to process the remote request. This cannot possibly be more efficient than a finely tuned graphics-specific protocol such as X11.
Variations in function name length aren't going to have an appreciable effect on performance. Worst-case, you look up the function in a hash table, but most common hashing algorithms are _not_ slow. I can see where some of the other header crap might have an influence, but again, the whole idea is not to couple the client and server as tightly over the network as is done in X.
X11 isn't exactly finely tuned either (although it's certainly lighter than IIOP for what it does) -- that's why we have lbxproxy and friends. But anyway, the point is not to have to do an over-the-wire request for each drawing primitive. Look at the design of something like NeWS if you don't believe that very very minimal communication between the client and server is possible when drawing things on the screen and related things.
3. A CORBA call will only be native if the server code is physically linked into the client binary - either shared or staticly. This would make the process size of your CORBA clients much bigger than the current X client/X server model, and resultantly with many process - much slower.
Actually it's the other way around -- things get loaded into the server, not vice versa. (*cough* NeWS *cough*) (which is not to say that everything must be in-process)
Additionally, you are aware that shared libraries only get loaded once under any self-respecting Unix? Memory usage from the text segments of the library isn't going to significantly increase after the first couple processes load the library. Admittedly, I'm not sure about working set size in general.
Time and benchmarks will determine which of us is more correct with regard to performance considerations, but I do know you can throw out the sundial right now.
---
The truth is probably somewhere in between...
on
Is X The Future?
·
· Score: 1
It's not as bad as I probably implied in my post, but neither is everything peachy-keen. The X design (and that of the current set of extensions) is hitting a wall. Rather than argue with you further, I'll simply ask you to consider the following:
Here are some situations that illustrate the problems I am talking about. I would suggest that you carefully research the problems inherent in doing each of the following:
Take a nontrivial X application and make it fully ICCCM compliant.
Make a hand-held X terminal, or any other embedded X implentation. It has to be complete enough to display Netscape and all other popular X apps.
Add antialiased fonts to X, while ensuring the following:
All existing X clients get antialiased fonts when using an X server that supports them
Retain the ability to use existing X font servers (in some cases, replacing the server is not possible, because of fonts in an old proprietary font format that certain apps require)
New applications will work on servers that do n't support antialiased fonts
Write a word processor in X that can print, without writing your own display abstraction on top of X for the onscreen WYSIWYG display. Bonus points if you can do without the extra display abstraction for printing itself; there are relevent X standards.
Implement clipboard functionality in X on par with Windows or Mac environments, while still retaining interoperability with existing applications
Implement sharing colormap cells between apps (as Windows does), so those that require a large number of colors (but don't, say, palette-cycle) don't have to allocate a private colormap and cause annoying palette disturbances
Most of these things are possible, but all of them are severely non-trivial to do. Study the relevent X standards, and try and figure out how to accomplish these things, learn what the problems are, and you will understand why I say what I do.
---
I don't really understand the logic here
on
Is X The Future?
·
· Score: 1
Your reasoning seems to run something like:
Given:
X has network transparency
Other such systems do not therefore:
Any new system that is not X will not have network transparency.
Given:
Any new system that is not X will not have nework transparency
Network transparency is critical therefore:
X should not be replaced by a new system.
That doesn't wash: the first argument is flawed. X was not the first, nor was it the last, network-transparent "GUI" (NeWS comes to mind). Even Win32 is capable of network transparency -- without breaking the existing APIs! I've used Windows Terminal Server before; if it weren't hamstrung by NT's other architectural issues, it'd be every bit as useful as X.
I think it's a realistic expectation that anything that could replace X would have network transparency. Certainly, all of the alternatives I'm aware of that are currently in development do. (Y Windows, Berlin, etc...)
As far as uniform means of graphical communication between Unices, again, all of the alternatives I'm aware of build on quite a few different Unices (Y Windows, Berlin, etc...)
X and related protocols are really horribly designed; their extensability and network transparency are their only redeeming qualities. People seem to cling to these features irrationally, in the face of all the other deficiencies, as if they were some marvel of engineering. They represented some degree of foresight on the part of the designers, but they are most certainly not unique to X.
---
Re:Berlin and Fresco are even slower
on
Is X The Future?
·
· Score: 1
Sundial? hardly. Marshalling/demarshalling overhead is dealt with in two ways:
more things [can] go in the display server -- with CORBA, in-process stuff is no more expensive than a native method call (which is actually what it reduces to). You aren't forced to put stuff in the server, either; just what you need/want for adequate performance.
X tries to break everything down into very low-level primitives to send over the wire. That's hardly lightweight. It'd be insane for Berlin to use CORBA like that, and it doesn't. Things are done at a much higher level of abstraction, meaning a lot less client<->server communication is necessary. In some respects, it's a little closer to NeWS, minus the evil horrendous ugly widgets.
You can certainly use Berlin under X (which is mainly how it's being developed right now). It's also conceivable that someone will write an X server for Berlin in the future, so the transition would not likely be that painful. If Berlin turns out good and people want to adopt it, anyway. Which I think it will. ---
Doesn't thread Only partly true. In the server, that's largely an implementation issue; in the clients, the X libraries can be re-entrant. However, the API is still not very thread-friendly.
Fonts unscalable. (Yes, I know about the TrueType servers That's just bogus. Very nearly all X servers have support for scalable Postscript fonts built in. However, there are still very very serious problems with X font handling -- for example:
treatment of glyphs as monochrome bitmaps pervasive -- If you want antialiasing, you need to redesign the entire font system from scratch, and incompatibly, as the existing APIs simply will not allow antialiasing. Older programs would not be able to take advantage of the antialiased text extension without being rewritten, either.
no concept of pair kerning or other typographical niceties. X is worthless for decent typesetting.
no real device-independence -- You can display to a screen, but can you use the same API for a printer, or some other more exotic device?
Non-GPL If it doesn't bother RMS (XFree86 was adopted the GNU project), it shouldn't bother you.
All this being said, X is just generally an absolutely horrible design. Its only two redeeming qualities are:
network transparency (although too finely grained for optimal performance)
complete extensability (although at the cost of duplicate interfaces for backwards compatibility)
...and these are exactly the two qualities (and tellingly enough, the only two) that people cite when they hail X as a marvel of engineering. It most certainly is not. It has survived and works "well enough" only because the designers did have barely enough foresight to add these features to "save the design from itself," so to speak.
The X design absolutely, unequivocably sucks otherwise. It's a mish-mash of extensions, each making up for design deficiencies in the layer beneath it. It's like what was already be an ugly suit, but there's hardly any original fabric left -- it's been so worn and patched that it's all patches on patches on patches.
Berlin and Y are both better. Why not use them?
Perhaps because neither is finished yet? Some more developers would be nice, though.
Yes, I know, "Berlin"...a piece of software that can do nothing more than render polygons does not an X replacement make.
You should check by more often. We've got text rendering and widgets, now. OOohh... clicky buttons.:)
Yes, agreed, it's been pretty slow, but things are beginning to pick up now. It'll still be a while before it's ready for primetime though; I sure hope nobody's suggesting we abandon X until then:P
But then were is X going to be, and were WOULD it have been had those people added some input and made X better?
All designs have a limited lifespan, including X. X simply cannot be extended indefinitely. It'll be good for a few years yet, but then what?
Let's say you're on a sinking ship with no lifeboats. Do you really want everyone bailing water, or do you want some of the people to bail while others work on finding land or another ship?
You might be able to keep the ship afloat longer if everyone stays and bails, but then everyone will eventually drown when the ship finally does sink. It's better to think ahead and make sure that everyone has somewhere to escape to.
I think it would be a mistake to diverge from X, it's networkable capabilities are unique and is one of the reason's I'm interested in Linux.
Anything that could successfully displace X is going to need the same general sort of capabilities. Certainly, Berlin is networkable as well, and you get finer-grained control over which side of the connection individual pieces of the system run on, too, as well as a lot of other things that you can't easily do in X. (although Fresco, upon which Berlin's design is based, can help)
Just because something works "well enough" does not mean that it could not be improved upon.
---
Yes, but there are some caveats...
on
Is X The Future?
·
· Score: 1
I think the point of this article is: X has the ability to do everything that you describe natively or with a few extensions?
However, the design of the original interfaces means that these extensions need to have completely incompatible interfaces. If you want antialiased fonts under X, for instance, you can't just extend the existing font stuff to do antialiasing -- its design won't permit that.
So, you have to create an entirely new font API, font server protocol, etc etc. Then you have to support two font interfaces for the sake of compatibility. And there's no way for legacy apps to take advantage of anti-aliasing, as they'd be using the old API. Some apps would get antialiased text, some wouldn't.
You'll eventually end up with three or four APIs and implementations of the same thing, and in fact that's already happened to X in some areas (study ICCCM sometime). To make it worse, any modern program or X server is going to have to support all of them for the sake of compatibility.
X servers are not lightweight things; it's this accumulation of extensions and interfaces that is one of the major reasons why. It can only get worse -- due to the same factors that have allowed X's rather broken initial design to be "fixed" and survive for so long, throwing out older extensions and interfaces is NOT an option.
I went to the page on it to look into getting the specs, but it was patented and not available while their "partners" developed products based on the design.
If it's patented, then the specs are a matter of public record. Go look up the patents, and there you go. If the patent numbers are not listed on the page, they'll probably tell you what they are if you ask.
Slashdot Mirror
You just want to start the client up as a specific user on bootup, right? That doesn't necessarily imply a login.
Probably what you want to do is stick something like su -c "rc5clientthingy --option blah" rc5user < /dev/null 2>&1 > /dev/null & in one of your init scripts. Bonus points if you set up a full-blown SYSV script for it (a la /etc/rc.d/init.d).
You probably want this to start in runlevel 2, 3 or 4, as those are the "network-enabled" ones. (if you're using standard runlevel configurations)
Berlin-- http://www.berlin-consortium.org
One day they will run out of reserves and they'll have two choices. 1) Don't add any more features, no matter how important they may be or 2) break existing programs and change the layout.
or, 3) subclass the existing interfaces
Berlin-- http://www.berlin-consortium.org
That's more readable in places than the original text...
Berlin-- http://www.berlin-consortium.org
Can someone translate?
Here goes...
Clarification filter:
Although the subnetting (sub-division of a parent network) features of IPv4 do not offer much flexibility, they have served to relieve congestion, ease management, and provide performance gains. These were meagre benefits, and did nothing to increase the effective number of addresses availible for allocation. Yet, they could still provide a way for the IETF to reduce the need to implement a new IP addressing scheme.
Crap isolation filter:
The subnetting features of IPv4 are inflexible and useless. They did reduce congestion, provide performance gains, and make management easier, but none of that matters because subnetting does provide any more addresses to allocate. However, the IETF can use subnetting to fix the current address shortage.
Crap removal filter:
IP subnetting can potentially be used to remove or reduce the need to implement a new IP addressing scheme, although that was not its original purpose.
Interpretation filter:
So far, IP subnetting has had limited usefulness. However, the IETF could take advantage of it to re-use individual IPs in different subnets. Doing so would at least temporarily remove the need to switch to IPv6.
Plain English filter:
Subnets aren't that useful. We should use the fields to get 4 more octets in our IP addresses instead.
Conclusion:
This guy is the most horrid writer I have ever encountered. I have known functional illiterates who could draft more readable and well-thought-out documents.
I strongly suspect that author was under the influence of multiple controlled substances at the time of the document's composition.
Interpretation filter:
This guy is on crack.
Berlin-- http://www.berlin-consortium.org
I get 2 second ping times on IRC all the time. Does this mean NASA will be running an ircd on their next interplanetary probe?
*grins*
Berlin-- http://www.berlin-consortium.org
It already exists, and I believe has been published in part.
Berlin-- http://www.berlin-consortium.org
Dude, it's just a binfmt-esque hack... and it's even being phased out because binfmt does precisely the same thing, while being somewhat more general about it...
---
Well, if you're outside the US then US law can't touch you anyway, so you may as well just download it and look at it.
Right. US law just nails the software authors' asses to the wall instead. Remember what happend to Phil Zimmerman...
---
The owners of IRC servers ban abusive people, not programs - they will not ban you because of the IRC client you use.
That's not actually completely true; does anyone remember when Microsoft Comic Chat came out? It dumped all kinds of crap data in band (for the character emotions and so forth), such that it was extremely obnoxious to be in a channel with people using it. Having to put up with "(#WEIFEOU#@5*UR)" or some crap at the beginning of every send phrase got very annoying, very fast. You got 5 or so people in a channel using the client, and it basically killed the conversation for everyone else.
Even worse, in the first few versions, the CTCP implementation was severely broken -- it sent PRIVMSGs instead of NOTICEs for replies, which could have resulted in infinite loops between the two clients trying to respond to each other. (although it generally didn't, as that version of Comic Chat provided no way for a user to send CTCP messages ... thankfully)
However, a lot of people still thought MS CC was really cute. Once they were using the client, they didn't really give a damn if they were dumping crap in channels -- they couldn't see it themselves, so why should they care? It finally got so bad that channel operators began to ban CC users on sight. Things continued to spiral downwards, though, and some IRC networks were compelled to politely (or often not so politely) ask people to stop using the Comic Chat client, "or else".
Today, although the functionality has, I believe, now been folded into the current Microsoft chat product, you won't see it used on normal IRC networks, nor is it a default. We won, but barely. It took a concerted effort on the part of the channel and server adminsitrators to preserve the networks for the rest of us.
I'm not really sure how or if this relates to the AOL/MS IM war, but I just felt like this little bit of history might be relevent somehow.
---
No, I didn't mean to imply that they could use it in that fashion either! The specific problems I was making reference to are:
1. it leaves our hypothetical dissident less
time to hide/escape/destroy documents --
if they can just walk down the hall checking
each room with the detector instead of
bursting in and searching each one "manually"
it goes a lot faster
2. even if the hypothetical dissident could
conceal himself, it wouldn't do any good.
They'd use the detector to sniff him out
in the priesthole or whatever he was hiding
in
There, happy? I'm not attributing magical powers to this thing, okay?
---
Fast operation string hashing algo or not - nothing beats an int lookup as is the case with X11's protocol. You cannot dispute this.
Indeed, I cannot; nor was I trying to do so. The thing is, though, one string hashing operation can probably pull even with about fifty int lookups or so.
While one operation over IIOP is slower than one over X, Berlin aims to use much fewer of them.
There's another factor to consider, too, which I just remembered something about -- if I remember correctly (and I could in fact be very wrong on this), IIOP is only used for inter-ORB communication. Intra-ORB communication doesn't have to use IIOP, and my understanding is that it generally doesn't -- i.e. each ORB has its own more optimal protocol, with IIOP being used as a more generic "fallback" for compatibility with other ORBs. Depending on the ORB, the ORB-specific protocol may compare more favorably with lighter-weight protocols.
Does Fresco use normal blocking (non-oneway) CORBA calls (forgive my ignorance) for most of its operations? If this is the case the socket round-trip time latancy will kill your remote performance. If use use oneway calls, on the other hand you risk not delivering the request. You lose both ways.
Whoa whoa whoa... I thought we were still talking about Berlin ... the widget hierarchies and aspects of layout control were taken from Fresco, but from what I understand (I need to read up on Fresco more) Berlin modifies it a little and has an entirely different drawing model (much more like NeWS), and a somewhat lighter-weight event model. Based on my understanding of things, Berlin's guts are not that similar to Fresco at all.
As to your actual question, pretty much everything Berlin does over CORBA is two-way, to the best of my knowledge. FWIW, I'm really more of a hanger-on to the project than an architecture guy, so take my architectural statements with a grain of salt.
As for having the complete Fresco GUI lib linked dynamically via a shared lib into the client: true, the code of the shared lib is common to all processes, but the data associated with each "instance" of the shared lib is not. I concede this point is probably not much of an issue.
Yeah, that's what I meant about WSS. It's probably not large, but it is admittedly significant.
You may not believe this - but I like the idea of Fresco - it seems to be a rather elegant design. I merely disagree with its transport mechanism. Good luck with the project.
Thanks, but unless you meant that you liked the ideas which Berlin had inherited from Fresco, I think you have the wrong project in mind: Berlin != Fresco. You might be able to call it "Son of Fresco", but I'm not sure. :P
---
All we would do would be futzing around with configuration files and recompiling kernels to install the latest patches.
That's why you have one or two sysadmin guys on hand to do that stuff for them. In a corporate environment, the users generally don't and shouldn't have root on their desktop machines, and the users shouldn't have t be responsible for configuring and maintaining their machines.
---
I meant that they'd know where I was as a result of the detector.
---
1. X clients on the same machine as the X server use the shared memory extension and not translated over the wire.
Wrong. Show me something other than a game that does this for anything but displaying bitmapped images. Local or not, most operations still take a trip through a socket, Unix domain or otherwise. The only way you'll get the majority of graphics operations in a typical application to go through XSHM is to reimplement the entire set of X drawing primitinives yourself in your application, and scribble on the shared bitmap directly. And if you do that, you don't get to take advantage of availible 2d acceleration, either. It might actually end up being slower on a good accelerated X server.
2. CORBA is largely a glorified RPC hack that requires socket round-trips for each remote request (can you say slow?). Oneway calls don't help you here as they are unreliable by design - read OMG's CORBA specification. Each of CORBA's on the wire requests has a big header which includes the name of the remote function name - in ASCII no less! The longer the name of the remote function - the longer it will take to process the remote request. This cannot possibly be more efficient than a finely tuned graphics-specific protocol such as X11.
Variations in function name length aren't going to have an appreciable effect on performance. Worst-case, you look up the function in a hash table, but most common hashing algorithms are _not_ slow. I can see where some of the other header crap might have an influence, but again, the whole idea is not to couple the client and server as tightly over the network as is done in X.
X11 isn't exactly finely tuned either (although it's certainly lighter than IIOP for what it does) -- that's why we have lbxproxy and friends. But anyway, the point is not to have to do an over-the-wire request for each drawing primitive. Look at the design of something like NeWS if you don't believe that very very minimal communication between the client and server is possible when drawing things on the screen and related things.
3. A CORBA call will only be native if the server code is physically linked into the client binary - either shared or staticly. This would make the process size of your CORBA clients much bigger than the current X client/X server model, and resultantly with many process - much slower.
Actually it's the other way around -- things get loaded into the server, not vice versa. (*cough* NeWS *cough*) (which is not to say that everything must be in-process)
Additionally, you are aware that shared libraries only get loaded once under any self-respecting Unix? Memory usage from the text segments of the library isn't going to significantly increase after the first couple processes load the library. Admittedly, I'm not sure about working set size in general.
Time and benchmarks will determine which of us is more correct with regard to performance considerations, but I do know you can throw out the sundial right now.
---
It's not as bad as I probably implied in my post, but neither is everything peachy-keen. The X design (and that of the current set of extensions) is hitting a wall. Rather than argue with you further, I'll simply ask you to consider the following:
Here are some situations that illustrate the problems I am talking about. I would suggest that you carefully research the problems inherent in doing each of the following:
Most of these things are possible, but all of them are severely non-trivial to do. Study the relevent X standards, and try and figure out how to accomplish these things, learn what the problems are, and you will understand why I say what I do.
---
Your reasoning seems to run something like:
therefore:
therefore:
That doesn't wash: the first argument is flawed. X was not the first, nor was it the last, network-transparent "GUI" (NeWS comes to mind). Even Win32 is capable of network transparency -- without breaking the existing APIs! I've used Windows Terminal Server before; if it weren't hamstrung by NT's other architectural issues, it'd be every bit as useful as X.
I think it's a realistic expectation that anything that could replace X would have network transparency. Certainly, all of the alternatives I'm aware of that are currently in development do. (Y Windows, Berlin, etc...)
As far as uniform means of graphical communication between Unices, again, all of the alternatives I'm aware of build on quite a few different Unices (Y Windows, Berlin, etc...)
X and related protocols are really horribly designed; their extensability and network transparency are their only redeeming qualities. People seem to cling to these features irrationally, in the face of all the other deficiencies, as if they were some marvel of engineering. They represented some degree of foresight on the part of the designers, but they are most certainly not unique to X.
---
Sundial? hardly. Marshalling/demarshalling overhead is dealt with in two ways:
---
You can certainly use Berlin under X (which is mainly how it's being developed right now). It's also conceivable that someone will write an X server for Berlin in the future, so the transition would not likely be that painful. If Berlin turns out good and people want to adopt it, anyway. Which I think it will.
---
X is ugly in several respects:
Only partly true. In the server, that's largely an implementation issue; in the clients, the X libraries can be re-entrant. However, the API is still not very thread-friendly.
That's just bogus. Very nearly all X servers have support for scalable Postscript fonts built in. However, there are still very very serious problems with X font handling -- for example:
If it doesn't bother RMS (XFree86 was adopted the GNU project), it shouldn't bother you.
All this being said, X is just generally an absolutely horrible design. Its only two redeeming qualities are:
...and these are exactly the two qualities (and tellingly enough, the only two) that people cite when they hail X as a marvel of engineering. It most certainly is not. It has survived and works "well enough" only because the designers did have barely enough foresight to add these features to "save the design from itself," so to speak.
The X design absolutely, unequivocably sucks otherwise. It's a mish-mash of extensions, each making up for design deficiencies in the layer beneath it. It's like what was already be an ugly suit, but there's hardly any original fabric left -- it's been so worn and patched that it's all patches on patches on patches.
Berlin and Y are both better. Why not use them?
Perhaps because neither is finished yet? Some more developers would be nice, though.
---
Yes, I know, "Berlin"...a piece of software that can do nothing more than render polygons does not an X replacement make.
You should check by more often. We've got text rendering and widgets, now. OOohh... clicky buttons. :)
Yes, agreed, it's been pretty slow, but things are beginning to pick up now. It'll still be a while before it's ready for primetime though; I sure hope nobody's suggesting we abandon X until then :P
---
But then were is X going to be, and were WOULD it have been had those people added some input and made X better?
All designs have a limited lifespan, including X. X simply cannot be extended indefinitely. It'll be good for a few years yet, but then what?
Let's say you're on a sinking ship with no lifeboats. Do you really want everyone bailing water, or do you want some of the people to bail while others work on finding land or another ship?
You might be able to keep the ship afloat longer if everyone stays and bails, but then everyone will eventually drown when the ship finally does sink. It's better to think ahead and make sure that everyone has somewhere to escape to.
---
I think it would be a mistake to diverge from X, it's networkable capabilities are unique and is one of the reason's I'm interested in Linux.
Anything that could successfully displace X is going to need the same general sort of capabilities. Certainly, Berlin is networkable as well, and you get finer-grained control over which side of the connection individual pieces of the system run on, too, as well as a lot of other things that you can't easily do in X. (although Fresco, upon which Berlin's design is based, can help)
Just because something works "well enough" does not mean that it could not be improved upon.
---
I think the point of this article is: X has the ability to do everything that you describe natively or with a few extensions?
However, the design of the original interfaces means that these extensions need to have completely incompatible interfaces. If you want antialiased fonts under X, for instance, you can't just extend the existing font stuff to do antialiasing -- its design won't permit that.
So, you have to create an entirely new font API, font server protocol, etc etc. Then you have to support two font interfaces for the sake of compatibility. And there's no way for legacy apps to take advantage of anti-aliasing, as they'd be using the old API. Some apps would get antialiased text, some wouldn't.
You'll eventually end up with three or four APIs and implementations of the same thing, and in fact that's already happened to X in some areas (study ICCCM sometime). To make it worse, any modern program or X server is going to have to support all of them for the sake of compatibility.
X servers are not lightweight things; it's this accumulation of extensions and interfaces that is one of the major reasons why. It can only get worse -- due to the same factors that have allowed X's rather broken initial design to be "fixed" and survive for so long, throwing out older extensions and interfaces is NOT an option.
---
I went to the page on it to look into getting the specs, but it was patented and not available while their "partners" developed products based on the design.
If it's patented, then the specs are a matter of public record. Go look up the patents, and there you go. If the patent numbers are not listed on the page, they'll probably tell you what they are if you ask.
---
I'd hate to be the cop walking through a door not knowing where someone with a gun is standing.
...and I'd hate to be a political dissident trying to hide behind a door from lots of people with guns who happen to know precisely where I am.
---