1) you, 2) the ads analysis program, 2) Google developers/system maintenance staff who sign a blood oath that they will not violate user trust, and 3) government agencies that provide a lawful warrant or subpoena for the data.
About the second #2, first of all Google does not have the authority to enforce a blood oath so we know for a fact that you're at the very least grandstanding.
Second, lots of people have made actual blood oaths only to go back on them even when they know people will die as a direct result. And with only privacy on the line you can bet a lot more will break their trust. So if you actually believe that those people that you know won't violate people's privacy then you almost certainly don't know them as well as you think you do.
Third, google is a central clearinghouse of lots of information. That means they are a target to any number of interested parties.
Fourth, 'national security' letters, gag orders, etc. If these people who you know are so trustworthy then they likely won't even let on if they were made to violate somebody's privacy.
For all of these reasons and more, the simple truth is that if you have something private that you really don't want others to know about then you don't store it on google's servers. That should be patently obvious to anybody qualified enough to work at google.
I fail to find any reference for the delimiter-based argument for making print a function (I looked for reasons for a print function here [python.org], and that PEP has some references too). Note that they didn't just add brackets, they actually changed print's semantics from being a statement to being a function.
I can't find it either atm. I remember reading about it when looking at closures or tuples or something like that.
Anyway you might find thesetwo links might be worth reading.
Actually, the reason for the brackets in print() is that it is now a function where it used to be a statement. All the other statements are still there (like return or def, etc). The decision had nothing to do with delimiters.
Actually it was entirely to do with delimiters, because lack of () on a zero-arg function and lack of () on print was causing ambiguity in some situations.
But I see there are python fanboi moderators here.
It is flawed to hold up C as the only language that got things right just because it's popular
Which is why I said "most languages". I mentioned { and } and 'begin' and 'end' which covers the vast majority of computer languages. I didn't even mention C, you did and then you attempted to shoot it down -- that's the definition of a strawman.
If whitespace were such a great idea, one would think those pushing it so forcefully would be able to give rational arguments for it.
You really put that is a parenthetical? Hell most grocery stores can link you to a purchase with a great deal of confidence even when you pay with CASH -- and even when you don't use your store-issued ID card. For the vast majority of people the vast majority of the time, their IP address IS 'personally identifiable information'.
I had the exact same attitude as you about Python but, since I am fairly intelligent, I was able to figure out that the curly braces are an unnecessary and distracting hassle and the indentation is going to be there anyway, and so I changed my mind. Too bad you are not able to do that.
Python just recently added parentheses to print() function and zero-arg functions because, lo and behold 50+ years of computer science and thousands of years of mathematics were right. There actually is a reason to use characters to denote groups and blocks, and to note the difference between functions and variables.
Python's indentation requirements are like hungarian notation -- it sounds good to some people, but causes trouble in all sorts of annoying ways.
Also, python does use a block start/end character: the newline. Most other languages use a '{' or 'begin' to start a block or '}' or 'end' to end it. Python in contrast uses '\n' as a start symbol and '\n' as either a block continuation character or block terminator. Your language is not any different from those that use { and } except for being less well defined and more absurd.
The authors of this article missed three key points:
Actually, they didn't miss those points. The 'research' attempting to debunk Dvorak layout was done in the first place because Dvorak layout was a classic example of unhealthy markets. They are actively trying to counter those points, with FUD.
These people, Liebowitz and the other guy, were essentially payed by iirc Microsoft and others to debunk monopolies. Their theory is that all markets settle on the best product and that other things like exclusive contracts, payola, and network effects are irrelevant. In other words, Windows is the (was the) monopoly OS because it was the 'best' operating system.
They're kooks. I've tried dvorak and it's just feels clearly superior. It has better 'stats'. And while that is not proof per-se, there is no evidence to the contrary, that dvorak is worse or the same. People repeating these hacks do a disservice to everybody -- like the 'scientists' that get on the news and deny global climate change.
There's two real-world problems with it: copy-and-paste and generating Python code.
And posting code on forums, or any other place that doesn't assign meaning to invisible characters. Python is like the cat of programming languages... always freaking out about some imaginary thing. You'll be writing your code all nice and friendly like and then accidentally hit tab instead of spaces and then out of the blue Rrrwrwr!
Both are much less common than looking at badly-formatted code that it takes a bit to mentally parse which brace-delineated languages have.
Any programming editor has a simple command to reindent or reformat the code. If you're writing your program in Word you're in trouble no matter what language.
On the other hand ___adding ______somekind of ___workaround when posting is reallly annoying.
Sorry to ruin this with fact, but "chrome" is jargon that has been around for a very long time. I encountered it long before Netscape even had a product.
"Results 1 - 10 of about 18,400,000 for firefox chrome" including such top hits as "Fun with Firefox Chrome URLs".
You've got to be feeling pretty apologetic to credit a team developing a competing web browser with not knowing basics about firefox and mozilla suite.
In any case, either Google didn't know about chrome: (inconceivable) or they chose the name Chrome on purpose knowing that it would be a slap at firefox. Personally I think either case is pretty crummy of Google.
Looks like Google bought one of the key people behind Self and Hotspot, Lars Bak. So Google did apparently fund the development of V8, but since JavaScript basically is Self it sounds more like 'other people's' work to me.
In any case, V8 adds nothing substantial over TraceMonkey or SquirrelFish.
Chrome codebase is not "cross platform", in that you can't just go ahead and compile it for Linux. They are still implementing a Gtk ui - see
Or, to put it another way, Google's entire contribution to the Chrome browser was a non-crossplatform, non-portable UI. V8 and WebKit were done by others and are cross-platform. Google knows their browser is just polish on other people's success with WebKit and V8 which is why they stole the name "chrome" from Mozilla.
There's basically one thing that makes Chrome special and that's running tabs in a separate process (for plugins, nspluginwrapper already does this).
Google gets a lot more credit for Chrome than they deserve. If it wasn't done by Google it would be hardly even notable.
And conveniently misses the point that indenting is a style. It's like writing a web pages without CSS... yeah forcing you to write all the content in order and forcing you into one layout might be considered 'good' to some people. They might even have 'reasons' to 'back up' their argument.
But, like the space-indenting-is-great Python (and COBOL) crowd what they won't have is facts or figures.
Rampant bullshit. You'll get somewhat better performance out of HotSpot than the Microsoft or Mono CLRs--not that much better, but definitely better
First, Mono performance is abysmal compared to JVM. Second, wake me up when CLR can inline a method more than 32 instructions long, or with control flow (if, for, while, etc)... which won't happen because the combination of 'real' generics and a bytecode that forces the VM to track exact types throughout means CLR will always be stuck with poor performance compared to better designed systems.
Only if the memory you allocate is in large chunks. If it's in small chunks, but a lot of them, they you're screwed. Also, you memory will most likely get fragmented so that you waste a lot of it in odd-sized chunks that don't quite fit your allocations. This will also slow down your allocations and frees so they are far slower than GC performance.
Which is why you use garbage collection and 'memory hungry' environments like JVM for long-running server programs. Or you really, really carefully write your code to really carefully make memory allocations.
Why would you program in a Java that has different-just-to-be-different syntax, is less free, has smaller library of code, and runs slower on all systems including Win32 and much slower on Linux? Does mono live on planet Endor?
Ultimately the problem with indent meaning something is that a lot of programming is style, including indenting. Is COBOL a "bad" language because the meaning of a statement depends on which column it starts on? No... but it is a "boring" language because of that.
It's also lossy. When I type "}" my editor shifts the indent down just like when editing python and I type "^H" it does the same. The difference is that the C program forever is marked with how the structure of the program is supposed to be. The information that "the block ends here" is part of the program whereas in a python program there is no such information, and I say that because whitespace changes for all sorts of reasons but no editor ever adds or removes actual visible characters unless specifically told to do so.
You say people won't 'miss' flexible whitespace, and you're right. But what I will miss is 'end' or '}' or '.'. These things are in the code because they are useful information.
Feds: Hey you've been hacked... trust us, we know Campaign: Um, so how do you know that? Feds: They removed our backdoors Campaign: Oh... right... so what are you going to do about it? Feds: We only investigate if you reported it, but WE reported it to YOU, so YOU have to investigate it. See how that works? Campaign: *grumble*
So, if Windows or OS X supplied builds that supported more than just x86, they would have to write this duplicate code?
Ok, I see you are not a programmer, or at least not at a low-level. Normally, an API uses the native system's byte order (endian-ness) or network byte order (big endian). The X protocol can use either endianness, and that incurs overhead on the server to branch on each access or to provide two implementations.
Eh, that is true. I remember X forwarding to be the faster way to run mplayer, but I'll test that out later tonight.
mplayer is very advanced. It maybe dropping frames or doing any number of tricks to look smoother. But most likely it is the VNC client that is the problem, for instance that last time I tried it watching video was much faster using the Java applet on jdk 1.5 (I think) vs the tight?vnc client... the difference being that the applet automatically got acceleration from Java2D's advanced pipeline whereas the straight C program didn't.
So we can now say this with confidence: If an app needs *lots* of round trips [1] to the X server, VNC will be generally faster. The converse is also true. [2],
The trick is that it's not readily apparent what apps or operations those are. A press on a button element might take 3 round trips or it might take 30, depending on the toolkit and app and all sorts of things. The nice thing about VNC is that it's performance is very stable regardless of any of those variables.
I still say it. You've cobbled together a bizzare set of features and expectations
I reached into the the grab bag of my mind and pulled out a handful. You want more? You want a complete thesis on deficiencies of X? There's plenty, but frankly, given that you are bickering over the examples I used, I doubt that is your reason.
It's an information leak. ITYM resource leak. But not one that matters in practice.
No, it's an information leak. It's one of many reasons why the same X server cannot ever be used by multiple SELinux contexts that are to be isolated from each other.
Spoken like someone who has never understood X: mechanism not policy. X provides all the underlying mechanisms for applications to interact.
"the free market", "drill baby drill", etc. Mantras don't solve problems.
That's how the excellent XDnD protocol was added with no extra API calls, and allowed it to coexist with and supercede the more poorly designed protocols it supplanted. It's how XDnD has been extended to support all sorts of useful things.
I'm sorry, but what? You're using cut and paste as an example of something X has done right? Give me a break. The other day I had a dragged folder and it fly back after several minutes, out of nowhere to nowhere. And a terminal where ctrl-shift-v wouldn't paste the clipboard but right-click paste did. And the pride and joy, the clipboard that disappears when the application exits.
It is seriously deluded to think the X clipboard is anything but an unmitigated disaster... you may consider that an insult. I consider it a fact.
Ah, insult the people. A sure sign of a strong technical argument.
Correlation is not causation. How's that go?
xlsatoms | wc -c gives 14746. That's a whole 14KILO bytes permenantly taken up by atoms.
It's an information leak.
Er, it's a graphics system.
Used to create a user interface. User interfaces should have audio, and support video capture, etc.
It has the overhead of packing/unpacking data into structs. Huh? Doesn't any API have this problem?
No, not the ones that aren't network protocols. Most APIs pass their data as parameters, in registers, or as pointers.
ICCCM is complex and not that great. On the other hand, with the years of hindsight, large sections (some quite interesting) have dropped completely
ICCCM only exists because X11 has no thought to actual applications interacting with each other.
Lots of unused (even at the time) primitives like jaggy lines and circles designed for 1-bit displays.
I don't consider myself old, but I've used X11 running on 1 bit displays. They were cheap and so some universities ahd them in significant quantities. I'm pretty sure it's not possible to draw a smooth line or circle on a 1 bit display, but if you know how, feel free to revolutionise display technology.
The problem is they are still jaggy on N-bit displays. That's why nobody uses them.
Your list is, so far rather uninformed. Have you ever programmed with XLib or examined the X protocol? Are you just regurgitating one of the more peculiar slashdot memes?
Says you. I've programmed in Xlib directly, including talking the protocol in binary for one project (where Xlib was too large to use). I've used Xt, Motif, and then also the newer toolkits of course. I've also hacked on the server source a little bit (not open source).
It's rarely discussed because it's extremely slow.
The same was said about X11 around 1985 (in fact the same could be said about X today).
A morally equivalent X server today would be written in Python. And I'm not kidding, it would be a huge success... just look at projects like mercurial (hg) that are written in python and you'd never know by using it. I mean what does an X server do nowadays, when nobody uses the scan-convert built-in functions anyway? It just manages some records and lists and events, and tells the hardware what to do. Even a scripting language can do that.
X does not need and should not be allowed to die. Sadly X11 is probably one of the coolest pieces of misunderstood software on the planet. It is a bit dated and it does need a code cleanup/refactor, but because of proper design, that can happen without breaking the system.
And X has probably given unix wankers the most wet dreams of any software project on the planet.
Give me a break. Atoms stay around in memory forever, by design. There's no audio. It has the overhead of packing/unpacking data into structs. You can use shared memory, but it's no panacea. Lots of complicated stuff like ICCCM and Visuals and xauth. Ad hoc things like cut and paste via shared secrets. Can't disconnect/reconnect the same client. Lots of unused (even at the time) primitives like jaggy lines and circles designed for 1-bit displays. The list goes on and on. Seriously I could fill pages of just mentions of the problems, assuming you to know the details.
So what does X get right? You can run a program over the network. That's it. Awesome... except that almost nobody does this, and VNC basically solves that problem. Certainly if anybody cared to, VNC-alike could easily send individual windows instead of the whole screen, like they do with vmware and parallels. But nobody cares to do that because in reality it's not that big a deal.
We talk time and again about survival of the fittest in science class, yet we can't seem to acknowledge that species must adapt or die. Animal species that are hardy will thrive.
Also, you know what the problem with this is? The ones that are going to survive aren't going to be cute cuddly little puppy dogs. They're going to be cockroaches that can see heat and that shoot molecular acid on you while you're sleeping. They're going to be bird-eating spiders. Octopi that walk on land and reshape/recolor themselves to look like a tree or boulder... until they pounce and eat you.
You know, basically we'll all be living in Australia.
1) you, 2) the ads analysis program, 2) Google developers/system maintenance staff who sign a blood oath that they will not violate user trust, and 3) government agencies that provide a lawful warrant or subpoena for the data.
About the second #2, first of all Google does not have the authority to enforce a blood oath so we know for a fact that you're at the very least grandstanding.
Second, lots of people have made actual blood oaths only to go back on them even when they know people will die as a direct result. And with only privacy on the line you can bet a lot more will break their trust. So if you actually believe that those people that you know won't violate people's privacy then you almost certainly don't know them as well as you think you do.
Third, google is a central clearinghouse of lots of information. That means they are a target to any number of interested parties.
Fourth, 'national security' letters, gag orders, etc. If these people who you know are so trustworthy then they likely won't even let on if they were made to violate somebody's privacy.
For all of these reasons and more, the simple truth is that if you have something private that you really don't want others to know about then you don't store it on google's servers. That should be patently obvious to anybody qualified enough to work at google.
I fail to find any reference for the delimiter-based argument for making print a function (I looked for reasons for a print function here [python.org], and that PEP has some references too). Note that they didn't just add brackets, they actually changed print's semantics from being a statement to being a function.
I can't find it either atm. I remember reading about it when looking at closures or tuples or something like that.
Anyway you might find these two links might be worth reading.
Actually, the reason for the brackets in print() is that it is now a function where it used to be a statement. All the other statements are still there (like return or def, etc). The decision had nothing to do with delimiters.
Actually it was entirely to do with delimiters, because lack of () on a zero-arg function and lack of () on print was causing ambiguity in some situations.
But I see there are python fanboi moderators here.
It is flawed to hold up C as the only language that got things right just because it's popular
Which is why I said "most languages". I mentioned { and } and 'begin' and 'end' which covers the vast majority of computer languages. I didn't even mention C, you did and then you attempted to shoot it down -- that's the definition of a strawman.
If whitespace were such a great idea, one would think those pushing it so forcefully would be able to give rational arguments for it.
(which is linked only to your ip address)
You really put that is a parenthetical? Hell most grocery stores can link you to a purchase with a great deal of confidence even when you pay with CASH -- and even when you don't use your store-issued ID card. For the vast majority of people the vast majority of the time, their IP address IS 'personally identifiable information'.
I had the exact same attitude as you about Python but, since I am fairly intelligent, I was able to figure out that the curly braces are an unnecessary and distracting hassle and the indentation is going to be there anyway, and so I changed my mind. Too bad you are not able to do that.
Python just recently added parentheses to print() function and zero-arg functions because, lo and behold 50+ years of computer science and thousands of years of mathematics were right. There actually is a reason to use characters to denote groups and blocks, and to note the difference between functions and variables.
Python's indentation requirements are like hungarian notation -- it sounds good to some people, but causes trouble in all sorts of annoying ways.
Also, python does use a block start/end character: the newline. Most other languages use a '{' or 'begin' to start a block or '}' or 'end' to end it. Python in contrast uses '\n' as a start symbol and '\n' as either a block continuation character or block terminator. Your language is not any different from those that use { and } except for being less well defined and more absurd.
The authors of this article missed three key points:
Actually, they didn't miss those points. The 'research' attempting to debunk Dvorak layout was done in the first place because Dvorak layout was a classic example of unhealthy markets. They are actively trying to counter those points, with FUD.
These people, Liebowitz and the other guy, were essentially payed by iirc Microsoft and others to debunk monopolies. Their theory is that all markets settle on the best product and that other things like exclusive contracts, payola, and network effects are irrelevant. In other words, Windows is the (was the) monopoly OS because it was the 'best' operating system.
They're kooks. I've tried dvorak and it's just feels clearly superior. It has better 'stats'. And while that is not proof per-se, there is no evidence to the contrary, that dvorak is worse or the same. People repeating these hacks do a disservice to everybody -- like the 'scientists' that get on the news and deny global climate change.
There's two real-world problems with it: copy-and-paste and generating Python code.
And posting code on forums, or any other place that doesn't assign meaning to invisible characters. Python is like the cat of programming languages... always freaking out about some imaginary thing. You'll be writing your code all nice and friendly like and then accidentally hit tab instead of spaces and then out of the blue Rrrwrwr!
Both are much less common than looking at badly-formatted code that it takes a bit to mentally parse which brace-delineated languages have.
Any programming editor has a simple command to reindent or reformat the code. If you're writing your program in Word you're in trouble no matter what language.
On the other hand
___adding
______somekind of
___workaround when posting
is reallly annoying.
Sure it could. We'd just be hunting and gathering each other. Everyone can pitch in and help to serve man.
It's people. Soylent Google is made out of people!
Sorry to ruin this with fact, but "chrome" is jargon that has been around for a very long time. I encountered it long before Netscape even had a product.
"Results 1 - 10 of about 18,400,000 for firefox chrome" including such top hits as "Fun with Firefox Chrome URLs".
You've got to be feeling pretty apologetic to credit a team developing a competing web browser with not knowing basics about firefox and mozilla suite.
In any case, either Google didn't know about chrome: (inconceivable) or they chose the name Chrome on purpose knowing that it would be a slap at firefox. Personally I think either case is pretty crummy of Google.
Looks like Google bought one of the key people behind Self and Hotspot, Lars Bak. So Google did apparently fund the development of V8, but since JavaScript basically is Self it sounds more like 'other people's' work to me.
In any case, V8 adds nothing substantial over TraceMonkey or SquirrelFish.
Chrome codebase is not "cross platform", in that you can't just go ahead and compile it for Linux. They are still implementing a Gtk ui - see
Or, to put it another way, Google's entire contribution to the Chrome browser was a non-crossplatform, non-portable UI. V8 and WebKit were done by others and are cross-platform. Google knows their browser is just polish on other people's success with WebKit and V8 which is why they stole the name "chrome" from Mozilla.
There's basically one thing that makes Chrome special and that's running tabs in a separate process (for plugins, nspluginwrapper already does this).
Google gets a lot more credit for Chrome than they deserve. If it wasn't done by Google it would be hardly even notable.
You say you are amused, but CLR still can't effectively inline methods. And it never will.
And conveniently misses the point that indenting is a style. It's like writing a web pages without CSS... yeah forcing you to write all the content in order and forcing you into one layout might be considered 'good' to some people. They might even have 'reasons' to 'back up' their argument.
But, like the space-indenting-is-great Python (and COBOL) crowd what they won't have is facts or figures.
Rampant bullshit. You'll get somewhat better performance out of HotSpot than the Microsoft or Mono CLRs--not that much better, but definitely better
First, Mono performance is abysmal compared to JVM. Second, wake me up when CLR can inline a method more than 32 instructions long, or with control flow (if, for, while, etc)... which won't happen because the combination of 'real' generics and a bytecode that forces the VM to track exact types throughout means CLR will always be stuck with poor performance compared to better designed systems.
Only if the memory you allocate is in large chunks. If it's in small chunks, but a lot of them, they you're screwed. Also, you memory will most likely get fragmented so that you waste a lot of it in odd-sized chunks that don't quite fit your allocations. This will also slow down your allocations and frees so they are far slower than GC performance.
Which is why you use garbage collection and 'memory hungry' environments like JVM for long-running server programs. Or you really, really carefully write your code to really carefully make memory allocations.
Why would you program in a Java that has different-just-to-be-different syntax, is less free, has smaller library of code, and runs slower on all systems including Win32 and much slower on Linux? Does mono live on planet Endor?
Ultimately the problem with indent meaning something is that a lot of programming is style, including indenting. Is COBOL a "bad" language because the meaning of a statement depends on which column it starts on? No... but it is a "boring" language because of that.
It's also lossy. When I type "}" my editor shifts the indent down just like when editing python and I type "^H" it does the same. The difference is that the C program forever is marked with how the structure of the program is supposed to be. The information that "the block ends here" is part of the program whereas in a python program there is no such information, and I say that because whitespace changes for all sorts of reasons but no editor ever adds or removes actual visible characters unless specifically told to do so.
You say people won't 'miss' flexible whitespace, and you're right. But what I will miss is 'end' or '}' or '.'. These things are in the code because they are useful information.
Speaking as someone who grew up learning that "kilo-" means 1000, what I don't understand why we allowed some asshole CS people to steal our prefix?
Because base-10 is soooo 1900s. Get with the program.
--
One-one was a race horse, One-two was one too.
One-one won one race, One-two won one two.
Feds: Hey you've been hacked... trust us, we know
Campaign: Um, so how do you know that?
Feds: They removed our backdoors
Campaign: Oh... right... so what are you going to do about it?
Feds: We only investigate if you reported it, but WE reported it to YOU, so YOU have to investigate it. See how that works?
Campaign: *grumble*
Sounds about right.
So, if Windows or OS X supplied builds that supported more than just x86, they would have to write this duplicate code?
Ok, I see you are not a programmer, or at least not at a low-level. Normally, an API uses the native system's byte order (endian-ness) or network byte order (big endian). The X protocol can use either endianness, and that incurs overhead on the server to branch on each access or to provide two implementations.
Eh, that is true. I remember X forwarding to be the faster way to run mplayer, but I'll test that out later tonight.
mplayer is very advanced. It maybe dropping frames or doing any number of tricks to look smoother. But most likely it is the VNC client that is the problem, for instance that last time I tried it watching video was much faster using the Java applet on jdk 1.5 (I think) vs the tight?vnc client... the difference being that the applet automatically got acceleration from Java2D's advanced pipeline whereas the straight C program didn't.
So we can now say this with confidence:
If an app needs *lots* of round trips [1] to the X server, VNC will be generally faster. The converse is also true. [2],
The trick is that it's not readily apparent what apps or operations those are. A press on a button element might take 3 round trips or it might take 30, depending on the toolkit and app and all sorts of things. The nice thing about VNC is that it's performance is very stable regardless of any of those variables.
I still say it. You've cobbled together a bizzare set of features and expectations
I reached into the the grab bag of my mind and pulled out a handful. You want more? You want a complete thesis on deficiencies of X? There's plenty, but frankly, given that you are bickering over the examples I used, I doubt that is your reason.
It's an information leak.
ITYM resource leak. But not one that matters in practice.
No, it's an information leak. It's one of many reasons why the same X server cannot ever be used by multiple SELinux contexts that are to be isolated from each other.
Spoken like someone who has never understood X: mechanism not policy. X provides all the underlying mechanisms for applications to interact.
"the free market", "drill baby drill", etc. Mantras don't solve problems.
That's how the excellent XDnD protocol was added with no extra API calls, and allowed it to coexist with and supercede the more poorly designed protocols it supplanted. It's how XDnD has been extended to support all sorts of useful things.
I'm sorry, but what? You're using cut and paste as an example of something X has done right? Give me a break. The other day I had a dragged folder and it fly back after several minutes, out of nowhere to nowhere. And a terminal where ctrl-shift-v wouldn't paste the clipboard but right-click paste did. And the pride and joy, the clipboard that disappears when the application exits.
It is seriously deluded to think the X clipboard is anything but an unmitigated disaster... you may consider that an insult. I consider it a fact.
Ah, insult the people. A sure sign of a strong technical argument.
Correlation is not causation. How's that go?
xlsatoms | wc -c gives 14746. That's a whole 14KILO bytes permenantly taken up by atoms.
It's an information leak.
Er, it's a graphics system.
Used to create a user interface. User interfaces should have audio, and support video capture, etc.
It has the overhead of packing/unpacking data into structs. Huh? Doesn't any API have this problem?
No, not the ones that aren't network protocols. Most APIs pass their data as parameters, in registers, or as pointers.
ICCCM is complex and not that great. On the other hand, with the years of hindsight, large sections (some quite interesting) have dropped completely
ICCCM only exists because X11 has no thought to actual applications interacting with each other.
Lots of unused (even at the time) primitives like jaggy lines and circles designed for 1-bit displays.
I don't consider myself old, but I've used X11 running on 1 bit displays. They were cheap and so some universities ahd them in significant quantities. I'm pretty sure it's not possible to draw a smooth line or circle on a 1 bit display, but if you know how, feel free to revolutionise display technology.
The problem is they are still jaggy on N-bit displays. That's why nobody uses them.
Your list is, so far rather uninformed. Have you ever programmed with XLib or examined the X protocol? Are you just regurgitating one of the more peculiar slashdot memes?
Says you. I've programmed in Xlib directly, including talking the protocol in binary for one project (where Xlib was too large to use). I've used Xt, Motif, and then also the newer toolkits of course. I've also hacked on the server source a little bit (not open source).
It's rarely discussed because it's extremely slow.
The same was said about X11 around 1985 (in fact the same could be said about X today).
A morally equivalent X server today would be written in Python. And I'm not kidding, it would be a huge success... just look at projects like mercurial (hg) that are written in python and you'd never know by using it. I mean what does an X server do nowadays, when nobody uses the scan-convert built-in functions anyway? It just manages some records and lists and events, and tells the hardware what to do. Even a scripting language can do that.
X does not need and should not be allowed to die. Sadly X11 is probably one of the coolest pieces of misunderstood software on the planet. It is a bit dated and it does need a code cleanup/refactor, but because of proper design, that can happen without breaking the system.
And X has probably given unix wankers the most wet dreams of any software project on the planet.
Give me a break. Atoms stay around in memory forever, by design. There's no audio. It has the overhead of packing/unpacking data into structs. You can use shared memory, but it's no panacea. Lots of complicated stuff like ICCCM and Visuals and xauth. Ad hoc things like cut and paste via shared secrets. Can't disconnect/reconnect the same client. Lots of unused (even at the time) primitives like jaggy lines and circles designed for 1-bit displays. The list goes on and on. Seriously I could fill pages of just mentions of the problems, assuming you to know the details.
So what does X get right? You can run a program over the network. That's it. Awesome... except that almost nobody does this, and VNC basically solves that problem. Certainly if anybody cared to, VNC-alike could easily send individual windows instead of the whole screen, like they do with vmware and parallels. But nobody cares to do that because in reality it's not that big a deal.
We talk time and again about survival of the fittest in science class, yet we can't seem to acknowledge that species must adapt or die. Animal species that are hardy will thrive.
Also, you know what the problem with this is? The ones that are going to survive aren't going to be cute cuddly little puppy dogs. They're going to be cockroaches that can see heat and that shoot molecular acid on you while you're sleeping. They're going to be bird-eating spiders. Octopi that walk on land and reshape/recolor themselves to look like a tree or boulder... until they pounce and eat you.
You know, basically we'll all be living in Australia.