I used microEmacs for a while when I used an Amiga because it came with it. It was probably limited compared to full Emacs but ultimately what stopped me was I couldn't remember all the key combinations, and I found vim for Amiga (it started there).
What made me keep with vim over other alternatives, including various IDEs I tried, is really that using vi/vim is more like having a conversation than doing all the work myself. By that I mean that every change starts with a command, like "i", then text to insert, ten . On its own that's actually more work, but vim understands what I just did and I can hit "." to repeat it - same with other editing commands, including ones which have smarts to them, like "cf.." which deletes from the cursor to the next period, and keeps the period. It remembers what I told it to search for. I can combine these, and a batch of changes can be reduced to "n" and "." keys.
Defining macros using "q" does the same thing, with longer command sequences. What makes it possible is the commands which have slight intelligence which let vim find where you want to make a change (nice regular expressions), copy and paste from surrounding text, and even cancel the macro if a condition isn't right. Simple "repeat these keystrokes" macros don't work that well.
It does take a while to get the experience where the awkwardness of the editing commands is replaced by the power of combining them like that. But I haven't personally used another editor that feels like it's a helper, rather than just a tool.
And I haven't even started on the ":" command line.
As I understand it, the social/political situation is complicated, but you can view it as "Burma" refers to the people (and overthrown democratic government, long disappeared in practice), and "Myanmar" refers to the military rulers and government, and supporters. "Myanmar" is essentially still at war with "Burma" (most of the people still consider themselves Burmese) but it has stopped short of genocide.
After the Boxing Day tsunami, Myanmar used soldiers to prevent aid workers from even attempting to help the injured Burmese, leading to thousands of more deaths. Since these were Burmese and not Myanmar, the Myanmar government didn't even pretend to care about them.
I figured that in the early days of the colonies, most documents were electronic, but for tradition the first printed works would be religious books, kept in the temples for the public to read. They would have a habit of folding the pages to mark the passages they wanted to remember, so the books were printed with corners cut off to prevent this sacrilege.
The same printing equipment was then used for other documents when the colony was more established, hence the cut corners on everything.
It's true that Iran's government was quite susceptible to being overthrown. There's an irony that democratic governments in developing nations were easier for CIA operations to overthrow because they had more freedom to operate, and as a result most of what remained were dictatorships in areas the U.S foreign policy concentrated on (Latin America, Middle East). Iran's current "theocracy-supervised democracy" is designed specifically to prevent that sort of thing from happening again.
The U.S itself is probably more vulnerable than you think. You have to realise that in all coups, the "front men" are presented (and seen as) patriots out to save the country. This is what made the presidency of George W. Bush so frightening to many people. Not only did it show the fragility of the inflexible U.S electoral process (Bush did not clearly win either election - in the end, both sides just settled for the results rather than risk escalating internal national hostility), it demonstrated that the same "patriots here to save the country" propaganda still works there, too. Though the Bush-fronted government took a wide liberty with the laws, they at least did not go as far as they could have. A more ruthless bunch could have gotten away with a lot more (and still might in the future).
In cast you didn't read that link, those things and the others in the list are just meant to be unstated assumptions that Americans take for granted - that being sort of the anthropological definition of culture. For example, if someone says they want to "watch the game", an American would assume it means baseball, basketball, or football (NFL), while in Canada it would be hockey or football (either CFL or NFL) or maybe baseball, and the U.K it would be football (soccer style) or cricket. It wasn't meant to say any of them are good or bad.
I agree. I even started working on a user interface protocol based on TCP (actually, any serial connection - RS-232 or USB would work just as well), but I didn't have time when moving to a house, and haven't started up again.
If you've done event driven GUI programming, you probably noticed much of it is in the form of (set up windows and controls),... etc, until the final (closes windows and so on). So why not define a standard set of messages so your application can be on a server, and your GUI is on your local machine? You only need one client (viewer) for any application on any server anywhere on the internet - much like a web browser works.
As opposed to traditional solutions which have consisted of shoveling megabytes of pixels down wires, and getting thousands of mouse/pointer/keyboard events back (X windows, remote desktop), neither of which you actually want.
My prototype (Java client, Python server) can open windows, display buttons and labels, not much more. It's called HICP (Holistic Interface Control Protocol). Someone else also tried something like that, using SOAP, called XUP (eXtensible User-interface Protocol) - at least they have a web site.
I wrote a story once where this was done (here. I kind of got tired of so many SF stories and movies solving traumatic injury with some sort of magical "healing tank" (maybe with effortless "nanobots") that I wondered to myself what sort of effort would really be needed to put someone together from just a bunch of pieces.
The closest similar stories I found were the beginning of "Neon", by Harlan Ellison in 1973, and an early chapter of "Count Zero" by William Gibson.
New updates have been installed. [Reboot new] [Reboot later]
No message; the system will be rebooted at some point anyway. Assume "reboot later". The only time you should have to reboot for any kind of update is an update to the kernel or file system.
You still have to tell the user that it's a good idea to do a reboot. While you're at it, you might as well offer the option to do it right now.
This one isn't even an error message, so I don't know what it's doing here, but anyway the time to give the user that option is when they're first informed of the update and allowed to choose to accept it (you're not going to suggest all updates get installed automatically without user notification, right?). So provide [Install and Reboot] [Install] [Skip update] options then. The two most annoying update-related things are 1) an unasked for update that reboots your computer in the middle of something (who cares if something was unfinished/unsaved?), and 2) needing to babysit an update just to hit "reboot" at the end (especially security updates that you don't want to go away and leave unapplied).
What it all comes down to is user interface design - the real stuff, not just how pretty your buttons look, but making things work. There is no shortcut. And one thing I've noticed, developers seem to stop at the point where something can work, and don't care if it will work. Too many deal with the will work part by just throwing out error messages for the parts they don't want to work at and going home with a job half done. I think that's what the original poster really takes issue with.
Actually, it's the opposite - the CRTC is trying to look relevant by adding layers of bureaucracy to anything it can justify. A friend of mine who works at a telecom company tells me that most carriers would love to have more competitive (and, ultimately, confusing) plans, but every calling plan must go through the CRTC and be approved after a long review, usually ending in rejection. Same goes for cable television rates (mandatory "basic" services and bundles, rather than individual channel subscription, preventing new stations from being made available until competitors are in a position to offer them as well, etc.).
A side note, the company he works for is government owned, and was therefore free from CRTC oversight until a decade or so ago - which is also when it's long distance rates stopped falling so quickly.
There is an argument that some regulation is needed to prevent customer abuse like you see in the U.S, but I think the CRTC goes too far. It's too bad, I expected the Harper government to do something about this, but apparently the "Conservative" in "Conservative Party" is just cosmetic (and this complaint is from someone who voted NDP last election).
Iraqis obstructed UN inspections in a way that indicates that they were up to something. They either were, or wanted it to appear that way to start a game of chicken with the US.
If they didn't have WMD, they could have diffused the situation at any time by allowing inspections.
And when they did? Six months later the U.S/U.K invasion happened. Lot of good that did them...
So the fact is that the Iraqis acted deliberately to goad the US into action.
I don't know what you think a "fact" is, but that's an interpretation. Another interpretation was that Iraq thought that the U.S was bluffing, given that many other countries (Russia, France) rejected the U.S position, and they were trying to call that bluff thinking that the U.S would eventually back down from international pressure.
The missing bit of the puzzle is, why? Was there a possible outcome that could have benefited top Iraqi leaders? Was there internal pressure (stupidly) forcing the confrontation?
I'd say the majority of international diplomacy consists of lying, and trying to figure out what the truth about the other guy really is. Given that, it's more than likely that Saddam Hussein and company honestly misunderstood the U.S position (under Clinton, remember, and generally cooperative with the international community as peers, presumably subject to pressure), and thought that a certain amount of beligerance would get the sanctions lifted (if you read the news reports pre-George W. Bush, it really was a completely different world, where the sort of war-hungry savagery of the U.S and U.K really was assumed to be a dead part of the past, and Iraq had the sovereign right to exist, and simply had to be managed until things improved some time into the future).
Remember, post war inspections showed that Iraq had been in essential compliance with the U.N resolutions for years. Compliance was a strong diplomatic card it earned and thought it could play.
I liked the idea and tried doing a design of my own. The thing I didn't like was that you now split up an operation into multiple instructions which couldn't operate concurrently, and I couldn't see how that could be sped up given instruction bus speed limits.
What I figured was to make the functional units more complex, so instead of having two inputs (left and right operand, implicit function), they'd also take an op code. This meant that I could reduce the number of addresses enough that a single move instruction could be packed into one byte. I don't recall for sure, but I think I used two bits to indicate the bus the move operated on, so you could get three moves happening at once (I think the last 2-bit pattern was reserved for special operations, but I don't recall what they were).
Branches were straightforward, in that the instruction read unit was just another functional unit, with left, right, and op input, you could just transfer the output from a logic/comparator unit to the op input of the instruction read unit to jump to the new (relative, I think) address or not.
Constants were defined by a special instruction unit operation which would accumulate 1, 2, or 4 subsequent bytes into the output register, ready to be moved elsewhere (as well as regular load/store from memory).
There was also a dedicated register file, where the op code was the register to read/write. Just in case the functional unit input/output registers weren't adequate.
I liked this idea because there'd be no speed penalty - in fact, a typical "regular" instruction would only be 3 bytes, so with the same input bottleneck it could even be faster.
It didn't get beyond a high level block diagram and instruction/unit descriptions. I'm sure I have a copy of it somewhere, but it got lost in a move (ironically).
Check your terms of service. If it's a typical consumer contract, then the company isn't legally obliged to actually perform any service for the money you give them, or reserve the right to change "at any time" the terms of service so what they promise doesn't matter anyway. Any service given is basically for PR purposes, to prevent too many customers from leaving.
This is done because the disparity in power between customers and corporations in high utility, capital intensive industries ("natural monopolies" in economics terms) is so large that customers have no practical choice (when some choice is available, "industry standard practice" generally means all options operate the same way - it's an informal collusion, even among competitors, because the competition is for revenue, not customer service, and they all practice every way of obtaining money from the customer that the others do).
This is why customer protection laws are important. They are meant to "write into" customer service contacts the minimum performance guarantees that customers, by collective political power, want but cannot demand through individual power. It's inefficient and still not generally adequate because corporations have political power too, but better than nothing.
As I recall, a technician forgot to plug in a hydraulic line on one strut. The real flaw was having only four landing legs - even one more would have made it stable if one failed.
All air international traffic control is in English.
You learn the language of the field you're working in. Programming is American English, so that's what you use in that case. I wrote a coding standards guide, and despite being in Canada, though I'm as nationalistic as the next toque-wearing chesterfield owner, I specified that symbolic names must use American spelling (color, not colour), because that is the standard, like it or not, and doing otherwise would just lead to subtle bugs (e.g. set "colour" and nothing happens, because the text control is using "color").
It's very difficult to get a concrete handle on Jonathan Schwartz' description of Sun's strategy, but not impossible. I don't know why Jonathan prefers generalities rather than actual examples, but it may be either not wanting to give away strategic secrets to competitors, or because it's just such a large company that there's no single example that he thinks stands out.
But there is a strategy. To take MySQL as an example, why spend a billion dollars on a free database?
First, it's both promotion, and a point of contact to get in touch with people who are doing something database-y - and might also want ZFS and Solaris. And maybe it's a pilot project for something that's going to need a lot of servers later - free software has to run on something. It's a combination of marketing and customer relations.
There are two kinds of customers, Jonathan points out - those which need expensive support contracts because their downtime would cost even more, and those who don't. Previously those who don't would by cheaper software, but by making all the important software free, there's no profit in competing at the low end anymore. This is exactly the niche that Microsoft Windows (and other Microsoft products) grew into, eventually displacing more and more Unix (including Sun) and mini/mainframe (DEC, IBM) systems. Free software forms a kind of firebreak around the profit services, preventing small competitors from doing the same thing again. Jonathan Schwartz doesn't actually say anything like this, but it is a side effect of free software, and Red Hat does the same thing. In this sense, buying MySQL and giving away the software preserves Sun profits (small companies can still compete, but by using the same software - MySQL, Linux, Solaris, Apache - they are now interchangeable with Sun, so there's no "Windows lock-in" effect).
Of course, if the software runs best on Sun hardware, all the better. For example, the UltraSPARK T1/T2 systems which run multithreaded workloads so well. Being able to, say, make MySQL more threaded would give them an advantage.
The "cloud computing" thing hasn't been really well defined, but is basically a potential development platform, like web applications. Like many, Sun has been trying for a long time to get the technology right, including a number of Java technologies (remember Jini and JXTA?). The ultimate goal with that is to basically break down the barrier between those "expensive contract customers" and "free software" customers by making "computing services" so flexible and easy that it's no longer a question of either a million dollar contract, or do it yourself - you can define where and how you want to access your computing resources, and exactly how much control you want over them, and just pay for what you want or need. And what you don't want to pay for, you do yourself. Obviously big customers can't be milked forever (the current recession is a big threat).
If there's one characteristic that Sun has displayed, it's trying to be ahead of the curve in the technology market. That means a lot of mistakes, and trying a lot of things in immature, unprofitable markets, with the hopes that when they hit the right thing, they'll make it big by being first. They don't want to be "Microsofted" like IBM was.
The downside is it looks like Sun is doing a lot of insane things, giving up profits in mature areas for "happy thoughts". I won't say whether these strategies are the best or most effective, or premature or just dumb. But of all the original Unix workstation makers, Sun alone is still around and independent. There must be a reason for that.
IBM has a long history of not only tolerating, but actively developing and promoting non-mainstream products. They still develop several operating systems (z/OS - from mainframe System/360 days, i5/OS - from AS/400, and System 38 and System 36 before that, AIX), and support others (Windows, Linux, Solaris), all to give customers no excuse for switching to a competitor. They support x86 servers, POWER based System p and System i (recently unified), mainframe System z. As well as blade versions of some.
This is in sharp contrast to HP, which gleefully killed off good products (and customer satisfaction) for feeble marketing reasons (like a market strategist would even know the difference between an Alpha and Itanium).
So there's a good chance that IBM would keep alive a lot of Sun hardware and software, only consolidating as needed. For example, System/36 and System/38 were merged into AS/400 smoothly enough to keep both sets of customers happy. And OS/2 was kept on life support for years just for those customers who had comitted to it, even if there was no new development for it. Maybe AIX and Solaris could be merged (AIX has a lot of partitioning magic and reliability tricks useful for IBM hardware that could be added to Solaris), the two companies' Java versions would do well with just one, and so on. But I doubt that Sun products would be wholesale slaughtered by IBM like some other companies might.
Slashdot Mirror
I used microEmacs for a while when I used an Amiga because it came with it. It was probably limited compared to full Emacs but ultimately what stopped me was I couldn't remember all the key combinations, and I found vim for Amiga (it started there).
What made me keep with vim over other alternatives, including various IDEs I tried, is really that using vi/vim is more like having a conversation than doing all the work myself. By that I mean that every change starts with a command, like "i", then text to insert, ten . On its own that's actually more work, but vim understands what I just did and I can hit "." to repeat it - same with other editing commands, including ones which have smarts to them, like "cf.." which deletes from the cursor to the next period, and keeps the period. It remembers what I told it to search for. I can combine these, and a batch of changes can be reduced to "n" and "." keys.
Defining macros using "q" does the same thing, with longer command sequences. What makes it possible is the commands which have slight intelligence which let vim find where you want to make a change (nice regular expressions), copy and paste from surrounding text, and even cancel the macro if a condition isn't right. Simple "repeat these keystrokes" macros don't work that well.
It does take a while to get the experience where the awkwardness of the editing commands is replaced by the power of combining them like that. But I haven't personally used another editor that feels like it's a helper, rather than just a tool.
And I haven't even started on the ":" command line.
As I understand it, the social/political situation is complicated, but you can view it as "Burma" refers to the people (and overthrown democratic government, long disappeared in practice), and "Myanmar" refers to the military rulers and government, and supporters. "Myanmar" is essentially still at war with "Burma" (most of the people still consider themselves Burmese) but it has stopped short of genocide.
After the Boxing Day tsunami, Myanmar used soldiers to prevent aid workers from even attempting to help the injured Burmese, leading to thousands of more deaths. Since these were Burmese and not Myanmar, the Myanmar government didn't even pretend to care about them.
I figured that in the early days of the colonies, most documents were electronic, but for tradition the first printed works would be religious books, kept in the temples for the public to read. They would have a habit of folding the pages to mark the passages they wanted to remember, so the books were printed with corners cut off to prevent this sacrilege.
The same printing equipment was then used for other documents when the colony was more established, hence the cut corners on everything.
It's an idiom by now, like "cut the mustard" or "pisses me off", which also don't make sense though the original phrases might have.
It's true that Iran's government was quite susceptible to being overthrown. There's an irony that democratic governments in developing nations were easier for CIA operations to overthrow because they had more freedom to operate, and as a result most of what remained were dictatorships in areas the U.S foreign policy concentrated on (Latin America, Middle East). Iran's current "theocracy-supervised democracy" is designed specifically to prevent that sort of thing from happening again.
The U.S itself is probably more vulnerable than you think. You have to realise that in all coups, the "front men" are presented (and seen as) patriots out to save the country. This is what made the presidency of George W. Bush so frightening to many people. Not only did it show the fragility of the inflexible U.S electoral process (Bush did not clearly win either election - in the end, both sides just settled for the results rather than risk escalating internal national hostility), it demonstrated that the same "patriots here to save the country" propaganda still works there, too. Though the Bush-fronted government took a wide liberty with the laws, they at least did not go as far as they could have. A more ruthless bunch could have gotten away with a lot more (and still might in the future).
EOL = "Enhance" Out Loud
In cast you didn't read that link, those things and the others in the list are just meant to be unstated assumptions that Americans take for granted - that being sort of the anthropological definition of culture. For example, if someone says they want to "watch the game", an American would assume it means baseball, basketball, or football (NFL), while in Canada it would be hockey or football (either CFL or NFL) or maybe baseball, and the U.K it would be football (soccer style) or cricket. It wasn't meant to say any of them are good or bad.
I contributed to the Canadian version.
I agree. I even started working on a user interface protocol based on TCP (actually, any serial connection - RS-232 or USB would work just as well), but I didn't have time when moving to a house, and haven't started up again.
If you've done event driven GUI programming, you probably noticed much of it is in the form of (set up windows and controls), ... etc, until the final (closes windows and so on). So why not define a standard set of messages so your application can be on a server, and your GUI is on your local machine? You only need one client (viewer) for any application on any server anywhere on the internet - much like a web browser works.
As opposed to traditional solutions which have consisted of shoveling megabytes of pixels down wires, and getting thousands of mouse/pointer/keyboard events back (X windows, remote desktop), neither of which you actually want.
My prototype (Java client, Python server) can open windows, display buttons and labels, not much more. It's called HICP (Holistic Interface Control Protocol). Someone else also tried something like that, using SOAP, called XUP (eXtensible User-interface Protocol) - at least they have a web site.
I wrote a story once where this was done (here. I kind of got tired of so many SF stories and movies solving traumatic injury with some sort of magical "healing tank" (maybe with effortless "nanobots") that I wondered to myself what sort of effort would really be needed to put someone together from just a bunch of pieces.
The closest similar stories I found were the beginning of "Neon", by Harlan Ellison in 1973, and an early chapter of "Count Zero" by William Gibson.
New updates have been installed. [Reboot new] [Reboot later]
No message; the system will be rebooted at some point anyway. Assume "reboot later". The only time you should have to reboot for any kind of update is an update to the kernel or file system.
You still have to tell the user that it's a good idea to do a reboot. While you're at it, you might as well offer the option to do it right now.
This one isn't even an error message, so I don't know what it's doing here, but anyway the time to give the user that option is when they're first informed of the update and allowed to choose to accept it (you're not going to suggest all updates get installed automatically without user notification, right?). So provide [Install and Reboot] [Install] [Skip update] options then. The two most annoying update-related things are 1) an unasked for update that reboots your computer in the middle of something (who cares if something was unfinished/unsaved?), and 2) needing to babysit an update just to hit "reboot" at the end (especially security updates that you don't want to go away and leave unapplied).
What it all comes down to is user interface design - the real stuff, not just how pretty your buttons look, but making things work. There is no shortcut. And one thing I've noticed, developers seem to stop at the point where something can work, and don't care if it will work. Too many deal with the will work part by just throwing out error messages for the parts they don't want to work at and going home with a job half done. I think that's what the original poster really takes issue with.
If you accused her of being a terrorist, the Neo-Cons would line up in a firing squad to pull the trigger.
Remember, a terrorist doesn't have to actually do anything terrorist-y to be a terrorist - that's what the whole "pre-emptive defense" doctrine means.
Yes, you can measure them in blood spilled: http://www.amnestyusa.org/amnestynow/diamonds.html
Actually, it's the opposite - the CRTC is trying to look relevant by adding layers of bureaucracy to anything it can justify. A friend of mine who works at a telecom company tells me that most carriers would love to have more competitive (and, ultimately, confusing) plans, but every calling plan must go through the CRTC and be approved after a long review, usually ending in rejection. Same goes for cable television rates (mandatory "basic" services and bundles, rather than individual channel subscription, preventing new stations from being made available until competitors are in a position to offer them as well, etc.).
A side note, the company he works for is government owned, and was therefore free from CRTC oversight until a decade or so ago - which is also when it's long distance rates stopped falling so quickly.
There is an argument that some regulation is needed to prevent customer abuse like you see in the U.S, but I think the CRTC goes too far. It's too bad, I expected the Harper government to do something about this, but apparently the "Conservative" in "Conservative Party" is just cosmetic (and this complaint is from someone who voted NDP last election).
I don't understand, I don't read with my ear.
Iraqis obstructed UN inspections in a way that indicates that they were up to something. They either were, or wanted it to appear that way to start a game of chicken with the US.
There are other possible reasons to obstruct weapons inspections. One could be exactly what the Iraq government actually claimed - that they didn't trust that cooperation would actually get the sanctions lifted: The Iraqis have said they believe that the United States would never agree to a suspension of sanctions but would instead find another reason to keep them in place, making cooperation, in their view, fruitless. Recent confessions from U.K Prime Minister Tony Blair seems to have borne out that position.
If they didn't have WMD, they could have diffused the situation at any time by allowing inspections.
And when they did? Six months later the U.S/U.K invasion happened. Lot of good that did them...
So the fact is that the Iraqis acted deliberately to goad the US into action.
I don't know what you think a "fact" is, but that's an interpretation. Another interpretation was that Iraq thought that the U.S was bluffing, given that many other countries (Russia, France) rejected the U.S position, and they were trying to call that bluff thinking that the U.S would eventually back down from international pressure.
The missing bit of the puzzle is, why? Was there a possible outcome that could have benefited top Iraqi leaders? Was there internal pressure (stupidly) forcing the confrontation?
I'd say the majority of international diplomacy consists of lying, and trying to figure out what the truth about the other guy really is. Given that, it's more than likely that Saddam Hussein and company honestly misunderstood the U.S position (under Clinton, remember, and generally cooperative with the international community as peers, presumably subject to pressure), and thought that a certain amount of beligerance would get the sanctions lifted (if you read the news reports pre-George W. Bush, it really was a completely different world, where the sort of war-hungry savagery of the U.S and U.K really was assumed to be a dead part of the past, and Iraq had the sovereign right to exist, and simply had to be managed until things improved some time into the future).
Remember, post war inspections showed that Iraq had been in essential compliance with the U.N resolutions for years. Compliance was a strong diplomatic card it earned and thought it could play.
I liked the idea and tried doing a design of my own. The thing I didn't like was that you now split up an operation into multiple instructions which couldn't operate concurrently, and I couldn't see how that could be sped up given instruction bus speed limits.
What I figured was to make the functional units more complex, so instead of having two inputs (left and right operand, implicit function), they'd also take an op code. This meant that I could reduce the number of addresses enough that a single move instruction could be packed into one byte. I don't recall for sure, but I think I used two bits to indicate the bus the move operated on, so you could get three moves happening at once (I think the last 2-bit pattern was reserved for special operations, but I don't recall what they were).
Branches were straightforward, in that the instruction read unit was just another functional unit, with left, right, and op input, you could just transfer the output from a logic/comparator unit to the op input of the instruction read unit to jump to the new (relative, I think) address or not.
Constants were defined by a special instruction unit operation which would accumulate 1, 2, or 4 subsequent bytes into the output register, ready to be moved elsewhere (as well as regular load/store from memory).
There was also a dedicated register file, where the op code was the register to read/write. Just in case the functional unit input/output registers weren't adequate.
I liked this idea because there'd be no speed penalty - in fact, a typical "regular" instruction would only be 3 bytes, so with the same input bottleneck it could even be faster.
It didn't get beyond a high level block diagram and instruction/unit descriptions. I'm sure I have a copy of it somewhere, but it got lost in a move (ironically).
In that case, I just use "password1", "password2", etc. - sites like that get the security they deserve.
Check your terms of service. If it's a typical consumer contract, then the company isn't legally obliged to actually perform any service for the money you give them, or reserve the right to change "at any time" the terms of service so what they promise doesn't matter anyway. Any service given is basically for PR purposes, to prevent too many customers from leaving.
This is done because the disparity in power between customers and corporations in high utility, capital intensive industries ("natural monopolies" in economics terms) is so large that customers have no practical choice (when some choice is available, "industry standard practice" generally means all options operate the same way - it's an informal collusion, even among competitors, because the competition is for revenue, not customer service, and they all practice every way of obtaining money from the customer that the others do).
This is why customer protection laws are important. They are meant to "write into" customer service contacts the minimum performance guarantees that customers, by collective political power, want but cannot demand through individual power. It's inefficient and still not generally adequate because corporations have political power too, but better than nothing.
As I recall, a technician forgot to plug in a hydraulic line on one strut. The real flaw was having only four landing legs - even one more would have made it stable if one failed.
My profanity of choice is "flocon de mais!", which sounds very bad to anyone who doesn't understand French, but translates to "corn flakes!".
Err! "phoque", not "foque"!
In French:
int monTampon[FOQUE_MAX];
In English:
int myBuffer[MAX_SEALS];
In medicine, the terms are Latin.
If you learn music, the terms are Italian.
Fencing terms are French.
Tae Kwan Do terms are Korean.
All air international traffic control is in English.
You learn the language of the field you're working in. Programming is American English, so that's what you use in that case. I wrote a coding standards guide, and despite being in Canada, though I'm as nationalistic as the next toque-wearing chesterfield owner, I specified that symbolic names must use American spelling (color, not colour), because that is the standard, like it or not, and doing otherwise would just lead to subtle bugs (e.g. set "colour" and nothing happens, because the text control is using "color").
It's very difficult to get a concrete handle on Jonathan Schwartz' description of Sun's strategy, but not impossible. I don't know why Jonathan prefers generalities rather than actual examples, but it may be either not wanting to give away strategic secrets to competitors, or because it's just such a large company that there's no single example that he thinks stands out.
But there is a strategy. To take MySQL as an example, why spend a billion dollars on a free database?
First, it's both promotion, and a point of contact to get in touch with people who are doing something database-y - and might also want ZFS and Solaris. And maybe it's a pilot project for something that's going to need a lot of servers later - free software has to run on something. It's a combination of marketing and customer relations.
There are two kinds of customers, Jonathan points out - those which need expensive support contracts because their downtime would cost even more, and those who don't. Previously those who don't would by cheaper software, but by making all the important software free, there's no profit in competing at the low end anymore. This is exactly the niche that Microsoft Windows (and other Microsoft products) grew into, eventually displacing more and more Unix (including Sun) and mini/mainframe (DEC, IBM) systems. Free software forms a kind of firebreak around the profit services, preventing small competitors from doing the same thing again. Jonathan Schwartz doesn't actually say anything like this, but it is a side effect of free software, and Red Hat does the same thing. In this sense, buying MySQL and giving away the software preserves Sun profits (small companies can still compete, but by using the same software - MySQL, Linux, Solaris, Apache - they are now interchangeable with Sun, so there's no "Windows lock-in" effect).
Of course, if the software runs best on Sun hardware, all the better. For example, the UltraSPARK T1/T2 systems which run multithreaded workloads so well. Being able to, say, make MySQL more threaded would give them an advantage.
The "cloud computing" thing hasn't been really well defined, but is basically a potential development platform, like web applications. Like many, Sun has been trying for a long time to get the technology right, including a number of Java technologies (remember Jini and JXTA?). The ultimate goal with that is to basically break down the barrier between those "expensive contract customers" and "free software" customers by making "computing services" so flexible and easy that it's no longer a question of either a million dollar contract, or do it yourself - you can define where and how you want to access your computing resources, and exactly how much control you want over them, and just pay for what you want or need. And what you don't want to pay for, you do yourself. Obviously big customers can't be milked forever (the current recession is a big threat).
If there's one characteristic that Sun has displayed, it's trying to be ahead of the curve in the technology market. That means a lot of mistakes, and trying a lot of things in immature, unprofitable markets, with the hopes that when they hit the right thing, they'll make it big by being first. They don't want to be "Microsofted" like IBM was.
The downside is it looks like Sun is doing a lot of insane things, giving up profits in mature areas for "happy thoughts". I won't say whether these strategies are the best or most effective, or premature or just dumb. But of all the original Unix workstation makers, Sun alone is still around and independent. There must be a reason for that.
IBM has a long history of not only tolerating, but actively developing and promoting non-mainstream products. They still develop several operating systems (z/OS - from mainframe System/360 days, i5/OS - from AS/400, and System 38 and System 36 before that, AIX), and support others (Windows, Linux, Solaris), all to give customers no excuse for switching to a competitor. They support x86 servers, POWER based System p and System i (recently unified), mainframe System z. As well as blade versions of some.
This is in sharp contrast to HP, which gleefully killed off good products (and customer satisfaction) for feeble marketing reasons (like a market strategist would even know the difference between an Alpha and Itanium).
So there's a good chance that IBM would keep alive a lot of Sun hardware and software, only consolidating as needed. For example, System/36 and System/38 were merged into AS/400 smoothly enough to keep both sets of customers happy. And OS/2 was kept on life support for years just for those customers who had comitted to it, even if there was no new development for it. Maybe AIX and Solaris could be merged (AIX has a lot of partitioning magic and reliability tricks useful for IBM hardware that could be added to Solaris), the two companies' Java versions would do well with just one, and so on. But I doubt that Sun products would be wholesale slaughtered by IBM like some other companies might.