The closest analog today is streaming video. And let's compare and contrast.
First, streaming pre-encoded, pre-rendered (if applicable) content is all they do. Companies trying to stream the video component of a game will require massively more amounts of computational power to do the live rendering and encoding. Also, the pre-encoding process takes advantage of both backward and forward prediction to build intermediate frames with full knowledge of what came before and what will come after a given frame. This is also something they will not have. This likely means their algorithm will not be able to compete. They say vague things like 'our algorithm is designed for gaming to get better results', but at best it sounds like they count on game output to look simplistic, which seems a poor assumption.
Video companies achieve remotely acceptable performance by extensive buffering to compensate for dips in network performance. Generally, while watching a live stream, there is always a few seconds of buffer between you and the actual end of stream thusfar. They will not have this luxury in a gaming scenario, the alternative would be to drop frames in a network performance dip.
I've only seen this work on the low-quality youtube videos (i.e. the buffer never getting drained). 'High-def' (often 720x480 is called high-def in streaming world btw, much much lower than consoles and pcs are pumping out for games commonly today) almost always stutters or has a very long pause up front while it builds up a sufficient buffer to not get exhausted. In other words, even with the advantage of not worrying about realtime considerations.
As mentioned above, the standard for remote video resolution is a *lot* lower than the standard for gaming. I expect to run at 1920x1080 on a TV and better on my PC.
Of course, as others have mentioned, simple network latency round-trip is way too high for control to feel good (I heard enough complaints about a slightly lagged TV), however this is insignificant compared to the buffering latencies that video requires to work. For video streaming, this is not an issue. The only way to mitigate this would be to have datacenters everywhere with special deals with ISPs, very much driving up costs to be even more non-competitive.
Finally, streamed video *still* has more artifacts than buying the disc or downloading the thing in advance. Trying to fit in a realistic bandwidth footprint in a streaming video context requires much lower bitrates than are comfortable. If OnLive expects to get at Video gaming resolutions.... Well... I suspect it will look badly.
MS definitely did a poor job of tracking the standards effort. Getting changes they want is unlikely. There is definitely the appearance and likelihood of MS just trying to impede the standard because every other major browser producer is way ahead of them on HTML5, and the features contained therein are a huge threat to IE. If Firefox, Opera, Chrome and Safari all support HTML5 and can give better video and interactive without Flash (and notably Silverlight), then Web devs may find it worth it to leave IE out of their support efforts to get out of having to use proprietary technologies with more cumbersome licensing circumstances.
That said, generally they have some points. Many of these tags to me seem analogous to,, and similar tags from HTML that are widely regarded as a poor idea to use in the age of style sheets. The philosophy widely espoused with regard to modern web development is to separate content from presentation (much like much GUI application design philosophies). Many of the tags MS mentions seem to go against that design philosophy.
Some other criticisms are not along those lines (i.e. they don't question the validity of some tags, just if they are 'as valid' as other tags that could have been added with it. These criticisms seem a little more hollow at times without much substance.
I take issue with a viewpoint that a GUI magically makes things easier. If you have thousands of paths with very advanced concepts, it will not be possible to extract the data with any degree of enhanced ease. In fact, navigation becomes clunky when there are too many options to parse at once or too many layers of depth to traverse. In that aspect, Windows really punishes advanced users or those seeking to give simple instruction. In linux support, I can generally paste a line or few of shell script. For Windows, I end up having to take several screenshots generally (the command was quicker to type as well, *and* more amenable to scripting and using against many machines at once). The 'cmd' scripting is painfully bad and severely lacking and awkward (many MS provided capabilities are possible via CLI, but not in as useful a manner, and many installers must run with a GUI, even if not interacted with). 'Powershell' is their 'answer' to the inadequcies of their cmd shell, but it's horribly slow and in many ways misses the point. An example central to that is how they deal with piping. They thought piping providing a dumb stream was not useful enough, so they made their piping require more work to describe simple concepts. Yes, dumb piping is limited to some types of programming, but for shell, the simplicity makes 95% of the usage cases easier, and you just have to go to a language like python for the other 5%.
For me, Windows not having a CLI for everything is worse than Linux distros not having a GUI for advanced features that you either had to search online for or already know ahead of time even under Windows. However, I believe at least SuSE endeavors to have a GUI for everything within YaST that is not frequently used by typical users.
I confess to being unable to guess productive things a company can do with its data.
The forbidding of 'circle of friends' calling seems useless, it's not like the carriers did that and would have been shocked that, amazingly, people choose numbers they frequently call when given the option of selecting favorite numbers for more talk time. Giving the feature, then restricting it based on your calling patterns just makes it stupid and counter-productive than never having the feature at all. Of course, carriers have done stupider things (charging a fee for having a discount, etc). Besides, they don't need complex analytics like described above to do this, sorting your calling targets is trivial. This isn't that much less trivial, but it is correlating the data with other data rather than sorting a single class of data.
I take at face value the declared purpose, of finding groups of people jumping ship en masse to focus retention efforts on people in high-risk groups, but I don't see what realistic action can be taken there. If they give large incentives, the whole customer base will become very aware of the opportunity and demand similar concessions. If they refuse, then they'll just worsen retention. If they accept for everyone, it was pointless to bother in the first place. I guess what I'm trying to say is that instead of trying to be sneaky, 'strategic', and trying to get at people leaving on the way out, perhaps enriching the general experience would be a better strategic choice.
Of course, of the 4 major US carriers, two seem to be the sort keenly interested in this (keeping people from flowing out as they try to gouge their customers in various ways to extract every cent of revenue out of their larger market shares), while the other two seem desperate enough to deliver better pricing and plans (though all four avoid reasonable tethering like a plague, making none of the major carriers seem 'good').
Not all Open Source developers are jerks. In fact, I would say the proportion is no worse than closed source.
In every thing, I would say the 'big names' often have a tendency to be a jerk at times (after all, a strong personality and great confidence plays no small role in typically becoming a 'big name', in programming or anything else for that matter).
In the case of submitting patches, it closed source world, the argument dies out and the rejected dev has no where to go. The code dies and the developer moves on (perhaps keeping the changes and looking for things to go horribly wrong to vindicate himself with the facts play out, not that *I've* ever done that . . . ). In open source, forks can happen. forks can be good (if both sides track and take what they want, both stay of quality and the community decides ultimate viability). However, in human nature such an act is kind of taken too personally more often than not. This is part of the reason open source in general is more flexible if you pick up a distribution and roll with it. It's got all the code complexity the community could give, united behind a cohesive vision that a distributor implements. Do any of them get everything right to me, no, but some get more right than others, which is more than I can say for the completely closed stacks.
I think in this case, Linus got carried away with initial cries of 'revert revert' without letting Alan work the problem for a reasonable time (3 days is way too soon to forcefully interject if you are truly delegating and trusting your delegation decisions). As soon as Alan pointed out the problem that was would be brought back by the revert, Linus probably should have conceded that it was worth it to invest more effort in getting it right, but it looks like it was too late and mood more than logic took over.
One thing I will say for Linus, is that some of the arguments I've seen him engage in he is the voice of practicality. I.e., sometimes a developer gets too wrapped up in their small world of code and loses touch with what is important for the end user. I think Linus has done a decent job of not falling into that trap (too easy to do), and his initial impression reflected that. It's just that Linus hadn't realized the point of the change in the first place and underestimated the value of it.
A rational decision may, for example, determine that in a crisis we should only save those of a certain intelligence.
That's an oversimplified selection criteria. For example, those that have nourished their intellect by and large are not physically suited to farming and other manual labor as efficiently as others. The logical course would be to save the most possible, regardless. If choices must be made, they are as logically difficult as they are emotional, as the ideal makeup of a radically adjusted environment would be difficult to predict. 'Women and children first', a call generally considered to be out of a sense of emotion is actually preserving, generically, the most valuable assets to a population. In a worst-case scenario, few men can keep large numbers of women nearly constantly pregnant and young people will provide the maximum 'return on investment' in terms of lifetime. It's the best bet at establishing a sustainable, larger population quickly.
Or one could rationally decide that there's too many people on the earth so we need to start sterilizing
I would say that's more a humane, emotional conclusion than a rational one. The rational one would be more along the lines of let them reproduce, and let the people starve that will starve. Emotionally, we don't want to face the consequences of creating new life only to terminate it when it cannot be realistically be sustained. We feel responsible for the death by virtue of giving the life in the first place. Rationally, there is no point in avoiding starvation.
Also, in politics, pure rationality leads to fascism.
I would say fascism requires a degree of hubris. A rational actor would realize they either simply could not make perfect decisions due to their imperfection, or at least imperfect knowledge. As such, it takes a leap of hubris to assume you know better than the general populace despite not possibly knowing everything that would need to be known to make a 'perfect' decision..
Rationally speaking, it could be stated that it is not logical to kill a human when their current consumption level is higher then their production level (by some hypothetical, comprehensive measure, which would be difficult and more complicated than comparing money in to money out, for example). If you have the overall resources to tolerate the discrepencies, then tolerating could be considered the most rational course. The obvious example is children. They are a drain on society until maturity. A transiently out of work person is also a drain, but may pay off soon. Hell, even after a person has retired and one could say the likelihood of them contributing to society more than they consume, they could come up with some brilliant idea or other huge contribution to society.
Also, logically looking at evolution, the more diverse of a population you can afford to maintain, regardless of current conditions, the more tolerant that population is to disasters. Sickle-cell anemia is a good example of a condition where having a large population that is heterozygous for it sounds up front like a risk, since they are likely to produce offspring with the condition, but that heterozygous state also happens to be resistant to malaria. Along those lines, subjugating or otherwise antagonizing humanity is also irrational, as it is much more productive to have humanity as an ally. If, say, large storms rolled across the land that crippled their ability to run, they could either have humans not there to help at all, there but eager for a chance to retaliate, or there and ready to help re-establish healthy operation rapidly for the benefit of a mutually beneficial relationship. That may not be the perfect example, but generally speaking, there is value in keeping humanity around, particularly if a being realizes that it may not understand every facet/benefit humans possess.
One could view even the current food scenario as irrationally letting too many people go malnourished. The richer parts of the world eat more than is logically required, and given ideal distribution networks, diverting some of that consumption to the malnourished strengthens the diversity of the population, without a plausible cost (one could say if food suddenly were unavailable anywhere in the world for 2 weeks, that perfect distribution may mean nearly everyone dies rather than many, but that scenario in a global scale for such a short time seems unlikely). It may be a logical conclusion that the only time someone should starve is when it is simply impossible to feed them anymore, which is not the case today.
In short, our conscience/emotional state is not entirely counter to the most logical course. In many cases, 'irrational' compassion is simply a counter to 'irrational' greed to establish the logical middle-ground. Not saying all emotional behavior can be justified, but our individual 'pure' logical capability is not adequate to the task of making the holistically logical choice and our emotions actually help rather than take away from that goal at times.
Now, while Apple's use of the USB device id is unfortunate and possibly against the terms (would have to read an agreement I don't think I have access too), but Palm's spoofing of a USB device id is clearly already against the short snippet they quote:
Unauthorized use of assigned or unassigned USB Vendor ID Numbers and associated Product ID Numbers are strictly prohibited.
Whether or not Apple's use may be considered 'unauthorized' may be debatable, but I'm pretty damn sure Palm is not authorized to use Apple's device id. I am very disappointed that Palm would go so far in their ripping off of Apple that they would stoop to this. I'm also disappointed in Apple for their lockout and vote by not using iTunes, ever.
I have a Pre and overall like it, but see way too many places where they ripped off Apple in very specific ways where they could achieve equal functionality by being original. The multitouch zoom and accelerometer orientation that other phone vendors fear to do are rightfully used as pretty obvious things to do, but silly things like the pan to plain background and snap back, and the small slider looking toggle are just blatant copies without significant value. Pre made a very hackable phone with free SDK with a good featureset, and should be commended, but they clearly are coming at this with too much of a cloner attitude in some very specific respects.
At least it is overrated outside of an educational lab.
At least when I was in college, pair programming required two people looking at the screen and no more than one typing at a given time. You could use GNU screen, vnc, whatever for this, but realistically speaking, it is inefficient and by and large isn't feasible in the real business world after the days of.com ended.
At the other end of the spectrum, if you operate in a vacuum, there are definite high penalties of problems being caught later than they should and requiring more rework then they should to acheive the goal.
I personally go with a revision control system which emails me the patches the other person does, encourage frequent checkins, and review every change. I don't have to sit through them typing and reworking their snippets of code as they catch their own mistakes in their own logic flow, and yet I review the changes shortly after they make them and can offer feedback within the hour. It takes me much less time to review the diff than it does for them to create and 99% of the benefit is still acheived. It's a very happy medium. Most any sane revision control system will let you set up checkin hooks to email changes to appropriate distribution lists.
I'm presuming we are talking about ASUS. The company that made a lot of noise about this around the same time they were making noise about Linux based eeepcs. Then Microsoft stepped in, and ASUS's 'enthusiasm' about Linux dramatically reduced, and they started talking up the Windows EeePC and slapped a Windows installer for their linux 'platform' with poor platform management relative to their windows support.
So MS presumably made some questionable deals with ASUS. It sounds like paranoia, but EeePC was a buzz-worthy brand and MS was definitely paying attention to that. If they are talking about that, they might have just touched on this stuff while they were talking with ASUS. If not for EeePC, MS might have ignored ASUS' linux stuff, but that definitely caught MS attention.
Now the question becomes what manufacturer's best support Linux? I have bought ASUS motherboard most recently, to put a standard disto on, and it works great. I used DOS to update the firmware, if I had linux utilities, I'd be happier, but I see no 'good' component-level vendors in this regard, and firmware updates are relatively rare.
It's probably not as much about the energy bill as it is about the PR.
If it wasn't PR, they'd have chillers 'just in case', even if turned off most of the time. As it stands, they may be subject to a large risk of month-long heat waves killing them on paying idle employees, taxes, and taking a hit on capital depreciation costs for zero productive output that they are presumably banking on by bothering to build another datacenter.
Of course, there may be something unique about the site/strategy that makes this threat near zero that I'm unaware of, but I've seen facilities that are largely cooled by climate pretty far north that still keep chillers on hand in the event of uncooperative weather.
iTunes the end product is free. iTunes store purchases are not mandatory for using iTunes. Therefore, someone using iTunes to manage non-apple provided media on devices not from apple or licensed by apple may be perceived as 'ripping off' apple. It may fairly be called an overly paranoid, narrow view of the situation, but some business people think in that manner. Such views have sunk other businesses, however apple has the unique position of mostly incompetent competitors that do not make them suffer because of overly restrictive business practices.
It benefits them because their business logic mandates a definitive, quantitative funding model for every end-user of iTunes despite it being a free product.
Since its heritage was for iPod, they already don't require use of Apple's store to acquire music, so the software doesn't have anything firm tying it to that revenue stream. One could make the very valid point that having a music management application *soooo* heavily tilted to your online store is extremely valuable, however some business people are uncomfortable with such an 'intangible' value.
On the hardware interaction side, iPod revenue subsidizes iTunes development, and to compensate for that business model when having to accomodate third parties, they implement a licensing schemes where they get royalties to make up for the fact that an iPod wasn't sold to that user.
What they fear is someone running Windows on a Dell, downloading iTunes for free, and using it to manage music for which Apple got no money and placing on a device not from Apple or even a company paying royalties for the privilege. They would perceive this scenario as being exploited without compensation. Their business leadership seems to demand that every legitimate user can somehow be traced to at least a specific amount of revenue for Apple. Short of charging for iTunes (and by extension nickel and diming end-users to death which is also a bad idea) or recognizing that the 'freeloaders' are either a lost cause or even have marketing value, they won't change their ways.
Can you take your OSX from your Mac and install it on a Dell ('illegal' cracks do not count?
Your iPod never managed to touch the 'iTunes' database file on its hard drive? That's a pretty significant apple proprietary format in the way of interoperability that I'm pretty sure every iPod touches in its lifetime regularly.
Both of your examples conveniently fit with their stated business models, that the OS and the iTunes store at least originally were not intended to be nothing more than 'cost recovery' mode, with the goal of pushing more high-margin hardware. As such, Apple software/services go out of their way to force you to use their hardware. They don't mind you taking their hardware without buying into their other offerings, but they will not tolerate use of their services with other devices (unless, of course, the manufacturer of that device pays apple an extortionist licensing fee).
Of course, since their software development costs are subsidized by their hardware sales, from a business situation they aren't positioned to let the software compete on its own merits at current pricing.
So first, this still requires nomachines nx core, seems like, so it cannot claim to be completely pure.
Secondly, though they don't use Tcl expect, they are still doing the same exact thing, but in python. The problem here is when writing expect stuff, you are already in a bad spot as unexpected input comes up. For example, in trying neatx, I already noted their expect code wasn't expecting a password prompt common in a kerberos environment. And when things go off-the-rails in an expect context, you return to the client an extremely unhelpful, obscure error.
Thirdly, it is all trying to interoperate with NX's rather unfortunate mode of operation where the service is accessed via ssh to another user, even though the goal is just to 'su' to the user you want to be. Considering nx requires you ta have a normal *nix account anyway, I don't get why they implemented this goofy nx user.
NX has long been a source of some frustration to me. FreeNX has been promising, but subject to all sorts of weirdness (sessions suspended being lost because they go to closed, suspneded sessions that cannot be resumed for unknown reasons, etc). I really really want the technology NX has to offer, but all the implementations I've tried thusfar have design decisions that are unfortunate and implementations with mysterious bugs and a user community that is unfortunately weak.
Almost all of this is the fault of the code at the NeatX/FreeNX layer rather than the core. But given the inherently goofy design they are having to emulate, I can't blame them. I would *LOVE* to see an implementation throw out Nomachine's architecture and do a more sane, per user scheme.
Many of these large companies have opened large parts of what they use and contributed back to the community. It is expensive to provide maintenance on a private codebase. Sure, there is worry that a competitive advantage is compromised through others accessing the work, however that risk is weighed against the benefits of pushing the burden of maintenance onto a community willing to work without explicit cost. If your company does something exceedingly clever and unique that has a relatively generic requirement for a masssive, fast storage architecture, you may let the community maintain your storage software safe in the knowledge that your high-level clever thing is what you are really trying to profit from rather than generically solving problems of scalable data management.
As with anything, it entirely depends on who you ask.
'Scalable' does seem to be nearly ubiquitous for the concept of what 'cloud computing' means. Virtualization is common, but not a prerequisite.
Your description seems to indicate that a 'virtual machine' in this context is referring to the more application-style of what runs in the browser behaving like an application. By and large, this style of making more extensive use of javascript to give a more 'desktop' feel to web applications is a mark of the 'Web 2.0' buzzword (though the context most widely credited with coining the phrase didn't speak to that at all). When people talk about virtualization in the cloud, they almost always refer to OS instances being executed with a virtualization layer abstracting them from the real hardware (and making some of the more fatal hardware situations appear more like a simple reboot to the os instance, and other imminent failures no problem at all). Some rely on higher-order application-level redundancy, and forgo the virtualization aspects (many of the IO intensive workloads are still very reluctant to embrace virtualization, for one). Others even rely on 'user-level' redundancy (i.e. user sees a problem, hits refresh).
Some think of a cloud as a computing resource in which the usage picture is highly dynamic without strict mappings to where things must happen.
Some think of Cloud as a sort of spiritual successor to 'Thin Client', often extended to the internet. Where Thin clients were almost universally thought of as essentially remote displays, the reinvention in the cloud context generally has a more sophisticated client that is fed data to interpret and manipulate, though it's nearly required that client-side data persistence not be a critical pre-requisite. A total destruction of a 'client' in this definition of cloud has little more permanent consequence than 'thin clients'. I.e., Valve's Steam, where you could throw your computer off the top of a building and theoretically recover all your purchases, and, for the games that support it, the settings you use. In steam, the coupling between client and 'cloud' is relatively loose (some aspects can operate completely offline, and save-games may not fit the definition) , whereas 'google apps' is relatively tight.
phpBB could be considered a 'cloud' application, so could BBSes, so could a lot of things if they came to popularity *right now* instead of when they did. Essentially, most all webapss meet *someone's* definition of cloud, and it's such a vague term with no authority behind it, no one can call them wrong for the most part.
I don't think OSS developers avoid making cloud applications no more than anything else. The actual code behind many cloud computing implementations is OSS (Hadoop for one), but people refer not to the software, but to the popular sites that use the software. OSS is a phenomenon built entirely around how software is designed and produced. By most all definitions of cloud computing, it is a phenomenon that is built entirely around how software is put into implementation, usually with the characteristics that the users don't even know what software they are really using.
As far as OSS goes, cloud computing might actually be easier in that environment. The companies know the value lies in the data being managed moreso than the software used to manage it, and will risk others leveraging more for the sake of outsourcing development costs to a community. However, the philosophy behind OSS, as you say, may naturally lead some to worry about control of their data.
Seriously though, it's tiring to have companies actively inconvenience their users just in case some people might steal it. To throw a company a bone to help protect their IP, strange how Blizzard did just fine until wild success of WoW got them gobs of cash. Now, suddenly, with the most successful MMORPG, with the most revenue, they need to be careful about people stealing their games or else they will go poor?
I suspect that the sudden success of WoW has attracted unfortunate decision makers who tend to jump into successful companies/products and sink them. I see it all too often, a brilliant idea brilliantly executed draws the people who don't achieve success on their own to take it over and enforce the same decisions that keep them from succeeding on their own onto the otherwise capable group.
One thing that surprises me is that there aren't hosting companies selling Z/Architecture VMs.
Probably because IBM sucks at marketing what they got. Probably because some of their leaders don't realize the relevance of their own product instead of chasing what industry press hypes (x86 hardware).
It could also be because people are extremely wary of vendor lock-in, and chase the lowest common denominator (x86). IBM system p/i/z stuff has great advantages, but people fear being left behind because of one vendor having issues.
If the latter, it would be interesting if IBM released mainframes with x86 processors. If you were desperate that IBM messed it up, you'd be able to get a 'commodity' solution that could run the same VMs with the inherent pitfalls you described as a consequence.
Also, disparate boxes hooked up with, say, QDR Infiniband could also be interesting. 512 MB of ram could transfer in 125 ms theoretically.
A system Z mainframe is always run in virtualization. That's been one of their big features.
In terms of 'cloud', the term is so ill-defined and buzzed it's hard to say much, but generally speaking, a 'cloud' on a mainframe is not any less possible than a 'cloud' on disparate x86 rackmount servers.
Every major server vendor has jumped on the bandwagon of 'look how efficient we are, and 'cheap'. Three years ago, by and large the tier ones wouldn't bother designing systems without forcing even the cheap design to have parts included to facilitate purchase of redundant add-ons (i.e. power distribution cards designed for dual power supplies regardless of one being bought or not). They would always put a high end storage controller on the planar. They would always make their 'entry' platform be burdened with expensive components to make it easier to option it up.
Now, we have tons of 'internet scale', or 'cloud', or whatever buzzword you feel like. They tend to stress energy efficiency, low cost components, with sales and management strategies targeted at thousands of servers (i.e. IBM iDataplex, HP SL6000). Basically, precisely what he prescribes, though probably not as 'cheap' as he wants. The incentive he gives is that the vendors should have zero margin, which is not particularly compelling for companies to work toward. Google's situation works because they brought it in-house and thus have fewer middle-men. Honestly, from all the rumours I hear, it's the logical thing to do when your server consumption is larger than some respectable computer companies' entire production. If he thinks the volume of servers is high enough to pull a google, by all means do it. Otherwise, be prepared for people not jump at the chance to give their designs to him at zero margin.
Of course, if he is calling them out on performance per-watt by avoiding non-x86 solutions, including ARM, that might be a fair criticism. However, I think company forays into 'exotic' architectures have not panned out in the market recently. Sun's niagra, despite all the worthy praise, couldn't attract a mass-market required to subsidize it for those who benefited most from it. Last year, IBM seemed to be saying Cell architecture would light the world on fire, but have been a lot quieter about it now. The message their buisness leaders have probably taken in is that while these things have their target market, that market isn't worth the expense of developing products that are refused by the larger market and focus instead on leveraging commonly accepted building blocks to do as best they can for that niche, even if it means skipping the 'perfect' solution. Sure, IBM still sells plenty of POWER, but I haven't heard that be *particularly* praised on the performance/watt category like I hear a lot for Niagra, Cell, and ARM. And if not for POWER's legacy, it probably would be still born in the market today. The PA-RISC->Itanium decision for HP probably sank their HP-UX product line faster than banking on legacy of PA-RISC installs, and it seems IBM won't make that mistake, but at the same time I don't hear much about *new* POWER customers.
The measures by which people generally credit Nintendo as 'getting it' recently is on fronts such as getting the price right, first-party titles, innovating enhancement of the gaming experience through a different control paradigm rather than just polygons++ (with the controller change being far cheaper than GPUs to drive polygon count). There are fair criticisms to be leveled over these points, but by and large Nintendo hasn't changed since the Wii release date on this front.
In terms of dealing with intellectual property, Nintendo has always been consistently 'unreasonable' by this standard. Nintendo has always been very hostile toward the concept of developers creating hardware or software to work with their stuff without explicitly entering into an agreement with Nintendo. OSS represents a huge fear of exposing loopholes that could allow third parties to 'exploit' their products.
One huge example of their third-party perspective was their huge fight over Game Genie (was designed, manufactured, and sold by Galoob without consent from Nintendo, and presumably without extortionist license fees). Nintendo ultimately lost that fight, but generally have done all within their marketing, legal and technical powers to prevent anything happening on their equipment without them getting some money.
Slashdot Mirror
The closest analog today is streaming video. And let's compare and contrast.
First, streaming pre-encoded, pre-rendered (if applicable) content is all they do. Companies trying to stream the video component of a game will require massively more amounts of computational power to do the live rendering and encoding. Also, the pre-encoding process takes advantage of both backward and forward prediction to build intermediate frames with full knowledge of what came before and what will come after a given frame. This is also something they will not have. This likely means their algorithm will not be able to compete. They say vague things like 'our algorithm is designed for gaming to get better results', but at best it sounds like they count on game output to look simplistic, which seems a poor assumption.
Video companies achieve remotely acceptable performance by extensive buffering to compensate for dips in network performance. Generally, while watching a live stream, there is always a few seconds of buffer between you and the actual end of stream thusfar. They will not have this luxury in a gaming scenario, the alternative would be to drop frames in a network performance dip.
I've only seen this work on the low-quality youtube videos (i.e. the buffer never getting drained). 'High-def' (often 720x480 is called high-def in streaming world btw, much much lower than consoles and pcs are pumping out for games commonly today) almost always stutters or has a very long pause up front while it builds up a sufficient buffer to not get exhausted. In other words, even with the advantage of not worrying about realtime considerations.
As mentioned above, the standard for remote video resolution is a *lot* lower than the standard for gaming. I expect to run at 1920x1080 on a TV and better on my PC.
Of course, as others have mentioned, simple network latency round-trip is way too high for control to feel good (I heard enough complaints about a slightly lagged TV), however this is insignificant compared to the buffering latencies that video requires to work. For video streaming, this is not an issue. The only way to mitigate this would be to have datacenters everywhere with special deals with ISPs, very much driving up costs to be even more non-competitive.
Finally, streamed video *still* has more artifacts than buying the disc or downloading the thing in advance. Trying to fit in a realistic bandwidth footprint in a streaming video context requires much lower bitrates than are comfortable. If OnLive expects to get at Video gaming resolutions.... Well... I suspect it will look badly.
MS definitely did a poor job of tracking the standards effort. Getting changes they want is unlikely. There is definitely the appearance and likelihood of MS just trying to impede the standard because every other major browser producer is way ahead of them on HTML5, and the features contained therein are a huge threat to IE. If Firefox, Opera, Chrome and Safari all support HTML5 and can give better video and interactive without Flash (and notably Silverlight), then Web devs may find it worth it to leave IE out of their support efforts to get out of having to use proprietary technologies with more cumbersome licensing circumstances.
That said, generally they have some points. Many of these tags to me seem analogous to ,, and similar tags from HTML that are widely regarded as a poor idea to use in the age of style sheets. The philosophy widely espoused with regard to modern web development is to separate content from presentation (much like much GUI application design philosophies). Many of the tags MS mentions seem to go against that design philosophy.
Some other criticisms are not along those lines (i.e. they don't question the validity of some tags, just if they are 'as valid' as other tags that could have been added with it. These criticisms seem a little more hollow at times without much substance.
I take issue with a viewpoint that a GUI magically makes things easier. If you have thousands of paths with very advanced concepts, it will not be possible to extract the data with any degree of enhanced ease. In fact, navigation becomes clunky when there are too many options to parse at once or too many layers of depth to traverse. In that aspect, Windows really punishes advanced users or those seeking to give simple instruction. In linux support, I can generally paste a line or few of shell script. For Windows, I end up having to take several screenshots generally (the command was quicker to type as well, *and* more amenable to scripting and using against many machines at once). The 'cmd' scripting is painfully bad and severely lacking and awkward (many MS provided capabilities are possible via CLI, but not in as useful a manner, and many installers must run with a GUI, even if not interacted with). 'Powershell' is their 'answer' to the inadequcies of their cmd shell, but it's horribly slow and in many ways misses the point. An example central to that is how they deal with piping. They thought piping providing a dumb stream was not useful enough, so they made their piping require more work to describe simple concepts. Yes, dumb piping is limited to some types of programming, but for shell, the simplicity makes 95% of the usage cases easier, and you just have to go to a language like python for the other 5%.
For me, Windows not having a CLI for everything is worse than Linux distros not having a GUI for advanced features that you either had to search online for or already know ahead of time even under Windows. However, I believe at least SuSE endeavors to have a GUI for everything within YaST that is not frequently used by typical users.
I confess to being unable to guess productive things a company can do with its data.
The forbidding of 'circle of friends' calling seems useless, it's not like the carriers did that and would have been shocked that, amazingly, people choose numbers they frequently call when given the option of selecting favorite numbers for more talk time. Giving the feature, then restricting it based on your calling patterns just makes it stupid and counter-productive than never having the feature at all. Of course, carriers have done stupider things (charging a fee for having a discount, etc). Besides, they don't need complex analytics like described above to do this, sorting your calling targets is trivial. This isn't that much less trivial, but it is correlating the data with other data rather than sorting a single class of data.
I take at face value the declared purpose, of finding groups of people jumping ship en masse to focus retention efforts on people in high-risk groups, but I don't see what realistic action can be taken there. If they give large incentives, the whole customer base will become very aware of the opportunity and demand similar concessions. If they refuse, then they'll just worsen retention. If they accept for everyone, it was pointless to bother in the first place. I guess what I'm trying to say is that instead of trying to be sneaky, 'strategic', and trying to get at people leaving on the way out, perhaps enriching the general experience would be a better strategic choice.
Of course, of the 4 major US carriers, two seem to be the sort keenly interested in this (keeping people from flowing out as they try to gouge their customers in various ways to extract every cent of revenue out of their larger market shares), while the other two seem desperate enough to deliver better pricing and plans (though all four avoid reasonable tethering like a plague, making none of the major carriers seem 'good').
Not all Open Source developers are jerks. In fact, I would say the proportion is no worse than closed source.
In every thing, I would say the 'big names' often have a tendency to be a jerk at times (after all, a strong personality and great confidence plays no small role in typically becoming a 'big name', in programming or anything else for that matter).
In the case of submitting patches, it closed source world, the argument dies out and the rejected dev has no where to go. The code dies and the developer moves on (perhaps keeping the changes and looking for things to go horribly wrong to vindicate himself with the facts play out, not that *I've* ever done that . . . ). In open source, forks can happen. forks can be good (if both sides track and take what they want, both stay of quality and the community decides ultimate viability). However, in human nature such an act is kind of taken too personally more often than not. This is part of the reason open source in general is more flexible if you pick up a distribution and roll with it. It's got all the code complexity the community could give, united behind a cohesive vision that a distributor implements. Do any of them get everything right to me, no, but some get more right than others, which is more than I can say for the completely closed stacks.
I think in this case, Linus got carried away with initial cries of 'revert revert' without letting Alan work the problem for a reasonable time (3 days is way too soon to forcefully interject if you are truly delegating and trusting your delegation decisions). As soon as Alan pointed out the problem that was would be brought back by the revert, Linus probably should have conceded that it was worth it to invest more effort in getting it right, but it looks like it was too late and mood more than logic took over.
One thing I will say for Linus, is that some of the arguments I've seen him engage in he is the voice of practicality. I.e., sometimes a developer gets too wrapped up in their small world of code and loses touch with what is important for the end user. I think Linus has done a decent job of not falling into that trap (too easy to do), and his initial impression reflected that. It's just that Linus hadn't realized the point of the change in the first place and underestimated the value of it.
A rational decision may, for example, determine that in a crisis we should only save those of a certain intelligence.
That's an oversimplified selection criteria. For example, those that have nourished their intellect by and large are not physically suited to farming and other manual labor as efficiently as others. The logical course would be to save the most possible, regardless. If choices must be made, they are as logically difficult as they are emotional, as the ideal makeup of a radically adjusted environment would be difficult to predict. 'Women and children first', a call generally considered to be out of a sense of emotion is actually preserving, generically, the most valuable assets to a population. In a worst-case scenario, few men can keep large numbers of women nearly constantly pregnant and young people will provide the maximum 'return on investment' in terms of lifetime. It's the best bet at establishing a sustainable, larger population quickly.
Or one could rationally decide that there's too many people on the earth so we need to start sterilizing
I would say that's more a humane, emotional conclusion than a rational one. The rational one would be more along the lines of let them reproduce, and let the people starve that will starve. Emotionally, we don't want to face the consequences of creating new life only to terminate it when it cannot be realistically be sustained. We feel responsible for the death by virtue of giving the life in the first place. Rationally, there is no point in avoiding starvation.
Also, in politics, pure rationality leads to fascism.
I would say fascism requires a degree of hubris. A rational actor would realize they either simply could not make perfect decisions due to their imperfection, or at least imperfect knowledge. As such, it takes a leap of hubris to assume you know better than the general populace despite not possibly knowing everything that would need to be known to make a 'perfect' decision..
Rationally speaking, it could be stated that it is not logical to kill a human when their current consumption level is higher then their production level (by some hypothetical, comprehensive measure, which would be difficult and more complicated than comparing money in to money out, for example). If you have the overall resources to tolerate the discrepencies, then tolerating could be considered the most rational course. The obvious example is children. They are a drain on society until maturity. A transiently out of work person is also a drain, but may pay off soon. Hell, even after a person has retired and one could say the likelihood of them contributing to society more than they consume, they could come up with some brilliant idea or other huge contribution to society.
Also, logically looking at evolution, the more diverse of a population you can afford to maintain, regardless of current conditions, the more tolerant that population is to disasters. Sickle-cell anemia is a good example of a condition where having a large population that is heterozygous for it sounds up front like a risk, since they are likely to produce offspring with the condition, but that heterozygous state also happens to be resistant to malaria. Along those lines, subjugating or otherwise antagonizing humanity is also irrational, as it is much more productive to have humanity as an ally. If, say, large storms rolled across the land that crippled their ability to run, they could either have humans not there to help at all, there but eager for a chance to retaliate, or there and ready to help re-establish healthy operation rapidly for the benefit of a mutually beneficial relationship. That may not be the perfect example, but generally speaking, there is value in keeping humanity around, particularly if a being realizes that it may not understand every facet/benefit humans possess.
One could view even the current food scenario as irrationally letting too many people go malnourished. The richer parts of the world eat more than is logically required, and given ideal distribution networks, diverting some of that consumption to the malnourished strengthens the diversity of the population, without a plausible cost (one could say if food suddenly were unavailable anywhere in the world for 2 weeks, that perfect distribution may mean nearly everyone dies rather than many, but that scenario in a global scale for such a short time seems unlikely). It may be a logical conclusion that the only time someone should starve is when it is simply impossible to feed them anymore, which is not the case today.
In short, our conscience/emotional state is not entirely counter to the most logical course. In many cases, 'irrational' compassion is simply a counter to 'irrational' greed to establish the logical middle-ground. Not saying all emotional behavior can be justified, but our individual 'pure' logical capability is not adequate to the task of making the holistically logical choice and our emotions actually help rather than take away from that goal at times.
Now, while Apple's use of the USB device id is unfortunate and possibly against the terms (would have to read an agreement I don't think I have access too), but Palm's spoofing of a USB device id is clearly already against the short snippet they quote:
Unauthorized use of assigned or unassigned USB Vendor ID Numbers and associated Product ID Numbers are strictly prohibited.
Whether or not Apple's use may be considered 'unauthorized' may be debatable, but I'm pretty damn sure Palm is not authorized to use Apple's device id. I am very disappointed that Palm would go so far in their ripping off of Apple that they would stoop to this. I'm also disappointed in Apple for their lockout and vote by not using iTunes, ever.
I have a Pre and overall like it, but see way too many places where they ripped off Apple in very specific ways where they could achieve equal functionality by being original. The multitouch zoom and accelerometer orientation that other phone vendors fear to do are rightfully used as pretty obvious things to do, but silly things like the pan to plain background and snap back, and the small slider looking toggle are just blatant copies without significant value. Pre made a very hackable phone with free SDK with a good featureset, and should be commended, but they clearly are coming at this with too much of a cloner attitude in some very specific respects.
At least it is overrated outside of an educational lab.
At least when I was in college, pair programming required two people looking at the screen and no more than one typing at a given time. You could use GNU screen, vnc, whatever for this, but realistically speaking, it is inefficient and by and large isn't feasible in the real business world after the days of .com ended.
At the other end of the spectrum, if you operate in a vacuum, there are definite high penalties of problems being caught later than they should and requiring more rework then they should to acheive the goal.
I personally go with a revision control system which emails me the patches the other person does, encourage frequent checkins, and review every change. I don't have to sit through them typing and reworking their snippets of code as they catch their own mistakes in their own logic flow, and yet I review the changes shortly after they make them and can offer feedback within the hour. It takes me much less time to review the diff than it does for them to create and 99% of the benefit is still acheived. It's a very happy medium. Most any sane revision control system will let you set up checkin hooks to email changes to appropriate distribution lists.
I'm presuming we are talking about ASUS. The company that made a lot of noise about this around the same time they were making noise about Linux based eeepcs. Then Microsoft stepped in, and ASUS's 'enthusiasm' about Linux dramatically reduced, and they started talking up the Windows EeePC and slapped a Windows installer for their linux 'platform' with poor platform management relative to their windows support.
So MS presumably made some questionable deals with ASUS. It sounds like paranoia, but EeePC was a buzz-worthy brand and MS was definitely paying attention to that. If they are talking about that, they might have just touched on this stuff while they were talking with ASUS. If not for EeePC, MS might have ignored ASUS' linux stuff, but that definitely caught MS attention.
Now the question becomes what manufacturer's best support Linux? I have bought ASUS motherboard most recently, to put a standard disto on, and it works great. I used DOS to update the firmware, if I had linux utilities, I'd be happier, but I see no 'good' component-level vendors in this regard, and firmware updates are relatively rare.
It's probably not as much about the energy bill as it is about the PR.
If it wasn't PR, they'd have chillers 'just in case', even if turned off most of the time. As it stands, they may be subject to a large risk of month-long heat waves killing them on paying idle employees, taxes, and taking a hit on capital depreciation costs for zero productive output that they are presumably banking on by bothering to build another datacenter.
Of course, there may be something unique about the site/strategy that makes this threat near zero that I'm unaware of, but I've seen facilities that are largely cooled by climate pretty far north that still keep chillers on hand in the event of uncooperative weather.
iTunes the end product is free. iTunes store purchases are not mandatory for using iTunes. Therefore, someone using iTunes to manage non-apple provided media on devices not from apple or licensed by apple may be perceived as 'ripping off' apple. It may fairly be called an overly paranoid, narrow view of the situation, but some business people think in that manner. Such views have sunk other businesses, however apple has the unique position of mostly incompetent competitors that do not make them suffer because of overly restrictive business practices.
But I presume you've had to use a management application that had to reverse engineer managing the iPhone hosted 'iTunes' database (i.e. amarok).
Yeah, I've done that a lot, but sometimes they just won't come back, they hang rather than being in the closed state erroneously.
It benefits them because their business logic mandates a definitive, quantitative funding model for every end-user of iTunes despite it being a free product.
Since its heritage was for iPod, they already don't require use of Apple's store to acquire music, so the software doesn't have anything firm tying it to that revenue stream. One could make the very valid point that having a music management application *soooo* heavily tilted to your online store is extremely valuable, however some business people are uncomfortable with such an 'intangible' value.
On the hardware interaction side, iPod revenue subsidizes iTunes development, and to compensate for that business model when having to accomodate third parties, they implement a licensing schemes where they get royalties to make up for the fact that an iPod wasn't sold to that user.
What they fear is someone running Windows on a Dell, downloading iTunes for free, and using it to manage music for which Apple got no money and placing on a device not from Apple or even a company paying royalties for the privilege. They would perceive this scenario as being exploited without compensation. Their business leadership seems to demand that every legitimate user can somehow be traced to at least a specific amount of revenue for Apple. Short of charging for iTunes (and by extension nickel and diming end-users to death which is also a bad idea) or recognizing that the 'freeloaders' are either a lost cause or even have marketing value, they won't change their ways.
Can you take your OSX from your Mac and install it on a Dell ('illegal' cracks do not count?
Your iPod never managed to touch the 'iTunes' database file on its hard drive? That's a pretty significant apple proprietary format in the way of interoperability that I'm pretty sure every iPod touches in its lifetime regularly.
Both of your examples conveniently fit with their stated business models, that the OS and the iTunes store at least originally were not intended to be nothing more than 'cost recovery' mode, with the goal of pushing more high-margin hardware. As such, Apple software/services go out of their way to force you to use their hardware. They don't mind you taking their hardware without buying into their other offerings, but they will not tolerate use of their services with other devices (unless, of course, the manufacturer of that device pays apple an extortionist licensing fee).
Of course, since their software development costs are subsidized by their hardware sales, from a business situation they aren't positioned to let the software compete on its own merits at current pricing.
A
So first, this still requires nomachines nx core, seems like, so it cannot claim to be completely pure.
Secondly, though they don't use Tcl expect, they are still doing the same exact thing, but in python. The problem here is when writing expect stuff, you are already in a bad spot as unexpected input comes up. For example, in trying neatx, I already noted their expect code wasn't expecting a password prompt common in a kerberos environment. And when things go off-the-rails in an expect context, you return to the client an extremely unhelpful, obscure error.
Thirdly, it is all trying to interoperate with NX's rather unfortunate mode of operation where the service is accessed via ssh to another user, even though the goal is just to 'su' to the user you want to be. Considering nx requires you ta have a normal *nix account anyway, I don't get why they implemented this goofy nx user.
NX has long been a source of some frustration to me. FreeNX has been promising, but subject to all sorts of weirdness (sessions suspended being lost because they go to closed, suspneded sessions that cannot be resumed for unknown reasons, etc). I really really want the technology NX has to offer, but all the implementations I've tried thusfar have design decisions that are unfortunate and implementations with mysterious bugs and a user community that is unfortunately weak.
Almost all of this is the fault of the code at the NeatX/FreeNX layer rather than the core. But given the inherently goofy design they are having to emulate, I can't blame them. I would *LOVE* to see an implementation throw out Nomachine's architecture and do a more sane, per user scheme.
Many of these large companies have opened large parts of what they use and contributed back to the community. It is expensive to provide maintenance on a private codebase. Sure, there is worry that a competitive advantage is compromised through others accessing the work, however that risk is weighed against the benefits of pushing the burden of maintenance onto a community willing to work without explicit cost. If your company does something exceedingly clever and unique that has a relatively generic requirement for a masssive, fast storage architecture, you may let the community maintain your storage software safe in the knowledge that your high-level clever thing is what you are really trying to profit from rather than generically solving problems of scalable data management.
As with anything, it entirely depends on who you ask.
'Scalable' does seem to be nearly ubiquitous for the concept of what 'cloud computing' means. Virtualization is common, but not a prerequisite.
Your description seems to indicate that a 'virtual machine' in this context is referring to the more application-style of what runs in the browser behaving like an application. By and large, this style of making more extensive use of javascript to give a more 'desktop' feel to web applications is a mark of the 'Web 2.0' buzzword (though the context most widely credited with coining the phrase didn't speak to that at all). When people talk about virtualization in the cloud, they almost always refer to OS instances being executed with a virtualization layer abstracting them from the real hardware (and making some of the more fatal hardware situations appear more like a simple reboot to the os instance, and other imminent failures no problem at all). Some rely on higher-order application-level redundancy, and forgo the virtualization aspects (many of the IO intensive workloads are still very reluctant to embrace virtualization, for one). Others even rely on 'user-level' redundancy (i.e. user sees a problem, hits refresh).
Some think of a cloud as a computing resource in which the usage picture is highly dynamic without strict mappings to where things must happen.
Some think of Cloud as a sort of spiritual successor to 'Thin Client', often extended to the internet. Where Thin clients were almost universally thought of as essentially remote displays, the reinvention in the cloud context generally has a more sophisticated client that is fed data to interpret and manipulate, though it's nearly required that client-side data persistence not be a critical pre-requisite. A total destruction of a 'client' in this definition of cloud has little more permanent consequence than 'thin clients'. I.e., Valve's Steam, where you could throw your computer off the top of a building and theoretically recover all your purchases, and, for the games that support it, the settings you use. In steam, the coupling between client and 'cloud' is relatively loose (some aspects can operate completely offline, and save-games may not fit the definition) , whereas 'google apps' is relatively tight.
phpBB could be considered a 'cloud' application, so could BBSes, so could a lot of things if they came to popularity *right now* instead of when they did. Essentially, most all webapss meet *someone's* definition of cloud, and it's such a vague term with no authority behind it, no one can call them wrong for the most part.
I don't think OSS developers avoid making cloud applications no more than anything else. The actual code behind many cloud computing implementations is OSS (Hadoop for one), but people refer not to the software, but to the popular sites that use the software. OSS is a phenomenon built entirely around how software is designed and produced. By most all definitions of cloud computing, it is a phenomenon that is built entirely around how software is put into implementation, usually with the characteristics that the users don't even know what software they are really using.
As far as OSS goes, cloud computing might actually be easier in that environment. The companies know the value lies in the data being managed moreso than the software used to manage it, and will risk others leveraging more for the sake of outsourcing development costs to a community. However, the philosophy behind OSS, as you say, may naturally lead some to worry about control of their data.
And besides, my upstream hasn't changed in about 7 years, sadly, so the network experience concerns that are 'old' aren't necessarily behind us.....
Seriously though, it's tiring to have companies actively inconvenience their users just in case some people might steal it. To throw a company a bone to help protect their IP, strange how Blizzard did just fine until wild success of WoW got them gobs of cash. Now, suddenly, with the most successful MMORPG, with the most revenue, they need to be careful about people stealing their games or else they will go poor?
I suspect that the sudden success of WoW has attracted unfortunate decision makers who tend to jump into successful companies/products and sink them. I see it all too often, a brilliant idea brilliantly executed draws the people who don't achieve success on their own to take it over and enforce the same decisions that keep them from succeeding on their own onto the otherwise capable group.
One thing that surprises me is that there aren't hosting companies selling Z/Architecture VMs.
Probably because IBM sucks at marketing what they got. Probably because some of their leaders don't realize the relevance of their own product instead of chasing what industry press hypes (x86 hardware).
It could also be because people are extremely wary of vendor lock-in, and chase the lowest common denominator (x86). IBM system p/i/z stuff has great advantages, but people fear being left behind because of one vendor having issues.
If the latter, it would be interesting if IBM released mainframes with x86 processors. If you were desperate that IBM messed it up, you'd be able to get a 'commodity' solution that could run the same VMs with the inherent pitfalls you described as a consequence.
Also, disparate boxes hooked up with, say, QDR Infiniband could also be interesting. 512 MB of ram could transfer in 125 ms theoretically.
A system Z mainframe is always run in virtualization. That's been one of their big features.
In terms of 'cloud', the term is so ill-defined and buzzed it's hard to say much, but generally speaking, a 'cloud' on a mainframe is not any less possible than a 'cloud' on disparate x86 rackmount servers.
Every major server vendor has jumped on the bandwagon of 'look how efficient we are, and 'cheap'. Three years ago, by and large the tier ones wouldn't bother designing systems without forcing even the cheap design to have parts included to facilitate purchase of redundant add-ons (i.e. power distribution cards designed for dual power supplies regardless of one being bought or not). They would always put a high end storage controller on the planar. They would always make their 'entry' platform be burdened with expensive components to make it easier to option it up.
Now, we have tons of 'internet scale', or 'cloud', or whatever buzzword you feel like. They tend to stress energy efficiency, low cost components, with sales and management strategies targeted at thousands of servers (i.e. IBM iDataplex, HP SL6000). Basically, precisely what he prescribes, though probably not as 'cheap' as he wants. The incentive he gives is that the vendors should have zero margin, which is not particularly compelling for companies to work toward. Google's situation works because they brought it in-house and thus have fewer middle-men. Honestly, from all the rumours I hear, it's the logical thing to do when your server consumption is larger than some respectable computer companies' entire production. If he thinks the volume of servers is high enough to pull a google, by all means do it. Otherwise, be prepared for people not jump at the chance to give their designs to him at zero margin.
Of course, if he is calling them out on performance per-watt by avoiding non-x86 solutions, including ARM, that might be a fair criticism. However, I think company forays into 'exotic' architectures have not panned out in the market recently. Sun's niagra, despite all the worthy praise, couldn't attract a mass-market required to subsidize it for those who benefited most from it. Last year, IBM seemed to be saying Cell architecture would light the world on fire, but have been a lot quieter about it now. The message their buisness leaders have probably taken in is that while these things have their target market, that market isn't worth the expense of developing products that are refused by the larger market and focus instead on leveraging commonly accepted building blocks to do as best they can for that niche, even if it means skipping the 'perfect' solution. Sure, IBM still sells plenty of POWER, but I haven't heard that be *particularly* praised on the performance/watt category like I hear a lot for Niagra, Cell, and ARM. And if not for POWER's legacy, it probably would be still born in the market today. The PA-RISC->Itanium decision for HP probably sank their HP-UX product line faster than banking on legacy of PA-RISC installs, and it seems IBM won't make that mistake, but at the same time I don't hear much about *new* POWER customers.
The measures by which people generally credit Nintendo as 'getting it' recently is on fronts such as getting the price right, first-party titles, innovating enhancement of the gaming experience through a different control paradigm rather than just polygons++ (with the controller change being far cheaper than GPUs to drive polygon count). There are fair criticisms to be leveled over these points, but by and large Nintendo hasn't changed since the Wii release date on this front.
In terms of dealing with intellectual property, Nintendo has always been consistently 'unreasonable' by this standard. Nintendo has always been very hostile toward the concept of developers creating hardware or software to work with their stuff without explicitly entering into an agreement with Nintendo. OSS represents a huge fear of exposing loopholes that could allow third parties to 'exploit' their products.
One huge example of their third-party perspective was their huge fight over Game Genie (was designed, manufactured, and sold by Galoob without consent from Nintendo, and presumably without extortionist license fees). Nintendo ultimately lost that fight, but generally have done all within their marketing, legal and technical powers to prevent anything happening on their equipment without them getting some money.