Noticed when my router evidently had most user space apps crash for some reason and, among other things, my domain 'lapsed', and I couldn't get it back for free. Now this is particularly crummy as unlike a 'real' domain, you can't just take it to another provider (you only have a host record in their domain, you don't actually have a domain that can be transferred) because you are mad.
All you can 'PXE' boot is WinPE, but most anyone wouldn't care about the distinction between that and PXE-bootstrapped iSCSI. PXE boot iPXE, then iPXE interprets root-path to start Windows with their native software iSCSI support. ipxe.org is a place you can do it yourself. xCAT automates everything from stgt iSCSI creation, to unattended windows install from DVD into iSCSI root, but may be a bit much for a home setup when you can just learn how to do it yourself manually at not much more effort.
Why bother spending $800 bucks for an OS you may not particularly like the style of anyway? For a task like this, I really don't see a particular advantage that Windows would hold unless all you know is Windows. The tools to do this sort of stuff are trivial to work in Linux (I personally think easier than Microsoft tools, but that may be a preference).
I would give MS the benefit of the doubt on a setup suggesting AD account management, though I haven't tried 389 which may have a nice integrated feel. Standard OpenLDAP+Kerberos realm is a little more work than setting up AD for a relatively small setup, but I see that as superfluous either way for this sort of setup.
Well with gPXE (pretty much dead now as the meat of the project forked to iPXE), most setups use tftp to transfer ~64 kilobytes and then other protocols take over (like http for a tftp workalike loading into ram or iSCSI for block storage loading content on-demand). Now with games, level load times may vary, but generally everything is in memory (or at *least* cache) when it comes down to actual gameplay.
Stateless ram-based OSes delivered can work too, but the multicast generally isn't worth it. A system can serve up dozens of reasonable OS images on a lan in really short order, and once boot is done, network no longer matters. Unless you make some significant effort designing your ethernet network right, the multicast is pretty much just broadcast, which becomes problematic for any participants of the network *not* intended to be a party to a transfer in progress.
My only hands on was a Pre-. If I was actively using it, it fared about the same as my Android device. But standby, well, my Android will last me at least a couple of days, but my Pre- wouldn't make it through the night unless it was plugged in. I did install an app that automatically went into airplane mode overnight and it tended to make it then, but I don't have to take that measure with my Android device and I can get middle-of-the-night calls.
Maybe In Pre2 or Touchpad world they worked it better. Since Pre- didn't get WebOS 2.0 and Sprint never got a Pre2, and I'm not particularly motivated to buy any tablet at all, my experience was limited.
I agree with most counts except more efficiently. I've missed the WebOS UI, the use of C/SDL to develop apps, and the fairly straightforward nature of the innards of the whole platform given a linux background since they seemed to have avoided reinventing the wheel as much as Google elected to do. But efficiency, at least measured in battery life, was something they never seemed to quite get right. My Android phone lasts a lot longer despite being much faster and having a bigger screen without a significantly higher capacity battery. I also didn't like the fact I could never have barcode scanning or similar (hardware design choice to not have autofocus camera, wtf?), no compass, and no third-party app access to things like the microphone (that last might have changed in WebOS 2.x, sadly no devices ever came to sprint for me to bother learning about).
There are projects without clear corporate backers that are moderately successful in their own right, but mostly not 'server' type projects. xbmc, xine, vlc, mplayer, and mythtv that comes to mind. Openoffice.org may have had Sun but I think the community had largely taken over and now you have Libreoffice.
Also, 'a large company' does not back Apache, many users of Apache back it. Since the users happen to be composed of businesses, yes your development community is comprised of companies. This applies to a lot of 'server'/'enterprise' projects.
On the flip side, I can't think of a single big project (including all the ones that you mentioned) that does *not* enjoy 'free' development and testing contributions from the community. My measure would be if the project reasonably continues in the face of any single corporate backer dropping out. The only instance mentioned that I think might fail that test is Android, because I think the business logistics are the main driver of Android's success moreso than the technical merits of the platform (which is serviceable and all, but I just don't see the ecosystem continuing without Google). There are plenty of niche projects that companies open sourced in search of free resources to no success that continue to effectively be solely driven by the company. Any project in *this* state (WebOS is closer to this in the spectrum than the 'big' projects) absolutely needs pretty much full-time commitment from the company if they ever hope to make it to 'big'.
A pressed optical disc is a matter of a few cents. That's significantly cheaper than the cartridges of yore and flash memory of the same amount. If you are implying user brings their own key to a kiosk, that *could* work, but I think you'd have a low attach rate for stores carrying the kiosks as most of the potential customers would be net connected and with the store being no different than buying it via network, the market is too small.
In terms of going full download over the internet, that really depends. First, you have to ascertain what percentage of the market has the capability to reasonably download the games. I suspect the percentage is relatively high, but I know of a few anecdotes of rural areas with no reasonable high speed internet option. Second, you have to figure of those that can, how many prefer optical media. On tech sites the community gives the feeling of being all in on download-only distribution models, but in the market I know several people who buy movies and games on disc even when they have downloadable options. If that is a large chunk of the market and MS dumps optical media and Sony doesn't, this could be a significant differentiator.
Finally, your options for backwards compatibility are limited. If your older library games just won't physically fit in the system, that's a problem.
(in fact, the "Linux-based" part is so unimportant in webOS that webOS can run on any kernel, as long as a WebKit and V8 implementation is there
Nope. For some apps, sure, but for any of the PDK type stuff, I'd say it's more 'linuxy' than Android (C code targeting SDL API seems more typical linux than what I hear you do in Android.
Volume buttons aren't exactly 'feature rich'. I had a hands on and yes, I could tell the touch capability was worse than my Android phone, but I thought it sufficient and understandable given the price point. Given the frequency and urgency that frequently comes with volume adjustment made the lack of volume control a deal breaker however.
Here's the thing, with WebOS it was nicely integrated. When I looked at the card view and saw each web page and each conversation in one unified, visually sane list, it was great. In Android, MDI is every app for itself. So I have to switch to the app then navigate within the app to find the piece of interest whereas in webos I just had to switch the app. I still haven't got an intuitive feel for when the built-in browser reuses an existing 'window' versus opening a new one in some cases.
It's really small details that make a big difference to me. A coherent, unified messaging app (simple trick of using libpurple, mostly). The ability to sanely manage multiple text conversations at once ('cards' compromising between full fledged desktop metaphor and mobile form factor). Architecture that prioritized keeping running apps running instead of arbitrary kills on 'background' applications. Architecture that didn't encourage every task switch to induce piss-poor home-written state restores (why is it when I switch to a browser, my SMS conversation closes when I switch back???).
For a complex project that is formerly closed, open sourcing is generally a big deal. It costs significant amounts of time and money. Real 'abandonware' only sees open source through an 'unofficial' labor of love by developers (e.g. star control 2). If they truly wanted to abandon, they'd just full stop on all efforts and let it die as a proprietary platform with no hope of revival.
It also doesn't make any support load go away. HP doesn't magically get out of any support obligation they may have by open sourcing it.
I seriously, seriously doubt that there are viable buyers at this point. I'm fairly convinced HP exhausted that option before open sourcing. Of course, open sourcing is much harder than just closing the whole effort down, so HP is spending money on WebOS for *some* reason.
The issue I see is I don't see how WebOS's 'magic' would have been so difficult to implement, and yet no one bothered. With WebOS effectively dead, I don't see Android, iOS, or even WP7 jumping up and down to repeat *any* move WebOS made. The simple move of including a chat feature built around libpurple is less work for more benefit, but no one else did it. Instead of having complicated and inconsistent rules about when an application is 'running' or 'backgrounded', the desktop-like 'card' management was much easier.
Of course, as much as I loved that multitasking interface, my WebOS device never got me nearly the battery runtime my android device has given me, and that might have been a contributor...
Realistically, I see WebOS evaporating as well is Tizen. Android is more than a technology platform, it is a brand. The word 'webOS' does not carry the marketing value that 'android' does. Apple has already set the pace of mobile experience being dominated by one-off applications more than more neutral web interfaces and so you have a significant network effect in play, no company backing means a distinct lack of applications for users and a dead platform.
Even if you subscribe to the theory the mobile market continues to show high volatility and there isn't the signs of insurmountable entrenchment like the desktop market and therefore anything including WebOS has a shot, WebOS is severely handicapped. It comes with the baggage of failing to bail out the once-great Palm, of sucking billions out of HP, and every appearance of being abandoned as a result. A technical advocate trying to get business leadership to recognize the value in the platform and commit to it has very little to no chance of convincing business leaders given the track record.
It's a shame too, ever since I had to go to an Android device, I've found the experience *highly* annoying compared to WebOS. -The gestures were so nice and smooth and I miss them. -As a corollary, 'back' was a lot more consistent (in Android, it ends up serving double duty for per-app 'back' and task switching if it thinks it appropriate). -Same for menus, Android apps are a mess with how inconsistently they deal with the menu button being pressed, and 99% of the time additional content is inelegantly dumped into one 'more settings' button. -When I switched away and back to an app in WebOS, the interface was just so much more sensible and showing what was going on better. -When I switch away and back in WebOS, the app was always consistent with where I left it last. In Android, it's a crap shoot. Sometimes the app just continues running in memory and is consistent when I return, sometimes that same app was killed arbitrarily by the OS and doesn't restore, sometimes an app faced with that inconsistency just always forces their piss-poor state restore every time they are backgrounded. -I could reasonably manage multiple textual conversations in baked in WebOS chat. Multiple chats open concurrently all under a single coherent messaging system. Now if I get gTalk, one app manages it and if I get SMS, something else handles it. If I'm chatting with someone and switch away to look up something and switch back, the SMS app has closed my conversation and I have to find it again.
What is being said is he can't figure out a *single* 'monster' company built on open-source software even allowing for services revenue. His list suggests a very high requirement for being 'monster', which may be useless as a criteria of the viability of open source as a business model. Stop the car analogies, it doesn't help.
I would say the fact that 'There are fewer open source companies' (that you've heard of) could *either* mean not as many people try (your implication) or that as many people try, but so many more fail with the open source route. I personally suspect there is a bit more truth in the latter. It seems that either: -You need a massive userbase You get a boost by having a much more straightforward free-to-use situation that could fuel your project becoming the de facto standard even if 99% of your users don't give you a dime (e.g. MySQL). Paying customers recognize they do need support, but find it better to have consistency between their non-critical, unpaid usage of your project and their critical usage. -You have some 'secret sauce' that is not open source. Google's real tech value comes in software that never leaves their datacenters. Most internet companies with a positive open source reputation fall under this category. You also have things like OSX, with Darwin being the open source stuff and most of the user-visible substance being closed source. -You use popularity of your internet-connected software to present ads/game referral links. The former is a ton of iOS/Android apps that are relying upon the laziness of people hitting up the market (sometimes even paying for it) rather than finding a free source or rebuilding it with those things changed. Another example is Canonical doing things like integrating Amazon MP3 purchase using their identifier as a referer. This latter sort of thing presents pretty much no impetus for someone to bother to dig in and change it, though I don't think Ubuntu's popularity suffices to drive a significant amount of revenue in this way.
Continuing to presume it is possible to embed the algorithm (I'll bet it isn't, probably requires more data and/or compute power than the individual sensors can provide, but hypothetically...). Embedding it in hardware doesn't make it any easier to reverse-engineer, it *does* make it at least somewhat more difficult in some scenarios. Software can (easily) be reverse engineered, so the fact that Hardware can too is no reason to shy from the strategy.
Embedding it the sensors accomplishes a few things. For one, the 'closed' source pill goes down easier amongst the community when it's traditional firmware. Exception comes when your entire platform is 'firmware' (e.g. Honeycomb tablets), but a very small population complains about the closed source nature of their laptop BIOS. For another, it gives freedom to take the software half of your business two ways. Either you have a total hardware/software solution with the two components meaningfully linked to one another (in many cases, a customer would perceive more value and be willing to pay more). On the other hand, you could put all your business into the 'hardware', and leave everything open source. You would have to work some on contributions and packaging the open source software for your product, but your investment would be lower.
Re:Only part of the population can think abstractl
on
The Condescending UI
·
· Score: 1
Problem being is any arbitrary representation by a computer is no more 'abstract' from the reality being tracked in cases like a desk calendar. Scrawling dates on an arbitrarily marked piece of paper to represent particular points in time is just as abstract representation of time as typing words into a computer.
Bookshelf representation is 'cute' and all, but I've never seen someone use *that* as the navigation method instead of searching a word they know is in the title. It's not like a list of titles or authors or anything overwhelm people because it's just 'too abstract', people just thought it looks neat. The same applies to all these constructs, highly impractical, not particularly less daunting than more straightforward alternatives, just a UI to have a certain aesthetic.
There are tons of examples of UIs that model the good *and* the bad of non-computer interfaces that were in use before many of the target users were even born. Arbirtary pagination that makes no sense in terms of where the content is broken up, or even requiring user to flip through irrelevant pages on their way to the desired page because that's the way it kinda works in paper media. This sort of phenomenon seems to be a deserving target of his displeasure.
As to the rest, I think the barrier to 'power user' is a bit lower than you expect. I know plenty of people not particularly inclined toward tech (not in a job inherently about technology, not playing games or otherwise doing much with a computer at home) and I have heard them express displeasure. The problem is 'do what they need to do and move on with their life'. If it is a task that they have to do 10 times a day and an over-simplified interface makes them spend 10 times the amount of time each time so they don't have to spend 5 minutes learning something, they've lost and they recognize that the simple path doesn't make sense after a few dozen times through it.
While I anticipate Google to have one of the most complex networks, they also probably have a more reasonable organizational structure populated by more talented individuals on the whole. I say this not because I think Google is magic, but I optimistically *hope* they aren't as bad as some of the companies I have dealt with. Most companies have a technical staff either not talented enough, bound up in an impossibly convoluted organizational structure that paralyses them in any efforts to technically advance the state of things, or some combination of the two.
Early large-scale adopters like Google have suffered the leading edge of vendors trying to get ready. In terms of the problems Google ran into, I'd wager a large chunk of them won't be inflicted again by the same company. Once kinks are worked out for even one customer, they are generally worked out for all customers.
That said, while I've seen a large amount of increased IPv6 capability from vendors (showing they have expertise *somewhere*), it's still an arcane art for almost everyone at these companies still yet relative to IPv4.
The whole point of the server service processors is to always work no matter what. To maximize the chance of this happening, the hardware vendors want the software running on them to be as tested and deterministic as possible. If end-user code fork bombs or triggers OOM killer to effectively ruin the running state of the service processor, that is bad. Ideally, you'd think an end-user would realize the blame was all their own, but two things occur: -'Why didn't you make your platform bullet-proof no matter how my code misbehaves?' -'I can't tell that *my* code is broken so I'm assuming perceived instability is due to the vendor'.
On the *other* hand, if you need to run custom code, you have an actual *operating system* to modify. Generally all the benefits of running *directly* on the service processor can be accessed by your choice of running in the managed OS and talking to the existing code or similarly doing it over the network.
From my *personal* perspective, I do have some stuff stored in a 'cloud' provider, but I *don't* trust any encryption they provide, I gpg it before upload. This is *not* stuff I'd care about the government seeing, incidently. My presumption is the gpg protection should suffice in the face of realistic attacks mounted by people who could do something apart from the government. Additionally, if broken, the damage would be recoverable.
From a business perspective, after talking to various companies, my take on the general outlook: -If it's material like advertising/marketing, wherever is cheaper, no confidentiality to sweat. -If it's material that the company doesn't explicitly care about, *but* is regulated to protect the confidentiality (e.g. incidental medical data subject to HIPAA accumulated by a non-medical company), then they would almost certainly put it on a 'cloud' *if* liability were part of the agreement. The rationale being they only care about being sued/not sued. If they don't have to store or audit the data and lawsuits pretty much go straight to the provider, they are very happy. No provider seems to be stepping up to offer that however. -If it's material that the company explicitly cares about (e.g. future product designs by a manufacturer), no way in hell. If they did outsource, they'd spend about as much money *auditing* their provider as they would protecting it themselves (if not more) and still not being as comfortable, so why bother. They feel the damages they could get through legal channels would likely not offset their opinion of their loss.
From the video, it looks like they are just saying the keyboard can slide around a bit, but you'd not want to do that for anything other than very light use. It looked pretty clumsy to get to those special keys when they showed someone typing...
Slashdot Mirror
Noticed when my router evidently had most user space apps crash for some reason and, among other things, my domain 'lapsed', and I couldn't get it back for free. Now this is particularly crummy as unlike a 'real' domain, you can't just take it to another provider (you only have a host record in their domain, you don't actually have a domain that can be transferred) because you are mad.
All you can 'PXE' boot is WinPE, but most anyone wouldn't care about the distinction between that and PXE-bootstrapped iSCSI. PXE boot iPXE, then iPXE interprets root-path to start Windows with their native software iSCSI support. ipxe.org is a place you can do it yourself. xCAT automates everything from stgt iSCSI creation, to unattended windows install from DVD into iSCSI root, but may be a bit much for a home setup when you can just learn how to do it yourself manually at not much more effort.
Why bother spending $800 bucks for an OS you may not particularly like the style of anyway? For a task like this, I really don't see a particular advantage that Windows would hold unless all you know is Windows. The tools to do this sort of stuff are trivial to work in Linux (I personally think easier than Microsoft tools, but that may be a preference).
I would give MS the benefit of the doubt on a setup suggesting AD account management, though I haven't tried 389 which may have a nice integrated feel. Standard OpenLDAP+Kerberos realm is a little more work than setting up AD for a relatively small setup, but I see that as superfluous either way for this sort of setup.
Well with gPXE (pretty much dead now as the meat of the project forked to iPXE), most setups use tftp to transfer ~64 kilobytes and then other protocols take over (like http for a tftp workalike loading into ram or iSCSI for block storage loading content on-demand). Now with games, level load times may vary, but generally everything is in memory (or at *least* cache) when it comes down to actual gameplay.
Stateless ram-based OSes delivered can work too, but the multicast generally isn't worth it. A system can serve up dozens of reasonable OS images on a lan in really short order, and once boot is done, network no longer matters. Unless you make some significant effort designing your ethernet network right, the multicast is pretty much just broadcast, which becomes problematic for any participants of the network *not* intended to be a party to a transfer in progress.
My only hands on was a Pre-. If I was actively using it, it fared about the same as my Android device. But standby, well, my Android will last me at least a couple of days, but my Pre- wouldn't make it through the night unless it was plugged in. I did install an app that automatically went into airplane mode overnight and it tended to make it then, but I don't have to take that measure with my Android device and I can get middle-of-the-night calls.
Maybe In Pre2 or Touchpad world they worked it better. Since Pre- didn't get WebOS 2.0 and Sprint never got a Pre2, and I'm not particularly motivated to buy any tablet at all, my experience was limited.
I agree with most counts except more efficiently. I've missed the WebOS UI, the use of C/SDL to develop apps, and the fairly straightforward nature of the innards of the whole platform given a linux background since they seemed to have avoided reinventing the wheel as much as Google elected to do. But efficiency, at least measured in battery life, was something they never seemed to quite get right. My Android phone lasts a lot longer despite being much faster and having a bigger screen without a significantly higher capacity battery. I also didn't like the fact I could never have barcode scanning or similar (hardware design choice to not have autofocus camera, wtf?), no compass, and no third-party app access to things like the microphone (that last might have changed in WebOS 2.x, sadly no devices ever came to sprint for me to bother learning about).
There are projects without clear corporate backers that are moderately successful in their own right, but mostly not 'server' type projects. xbmc, xine, vlc, mplayer, and mythtv that comes to mind. Openoffice.org may have had Sun but I think the community had largely taken over and now you have Libreoffice.
Also, 'a large company' does not back Apache, many users of Apache back it. Since the users happen to be composed of businesses, yes your development community is comprised of companies. This applies to a lot of 'server'/'enterprise' projects.
On the flip side, I can't think of a single big project (including all the ones that you mentioned) that does *not* enjoy 'free' development and testing contributions from the community. My measure would be if the project reasonably continues in the face of any single corporate backer dropping out. The only instance mentioned that I think might fail that test is Android, because I think the business logistics are the main driver of Android's success moreso than the technical merits of the platform (which is serviceable and all, but I just don't see the ecosystem continuing without Google). There are plenty of niche projects that companies open sourced in search of free resources to no success that continue to effectively be solely driven by the company. Any project in *this* state (WebOS is closer to this in the spectrum than the 'big' projects) absolutely needs pretty much full-time commitment from the company if they ever hope to make it to 'big'.
A pressed optical disc is a matter of a few cents. That's significantly cheaper than the cartridges of yore and flash memory of the same amount. If you are implying user brings their own key to a kiosk, that *could* work, but I think you'd have a low attach rate for stores carrying the kiosks as most of the potential customers would be net connected and with the store being no different than buying it via network, the market is too small.
In terms of going full download over the internet, that really depends. First, you have to ascertain what percentage of the market has the capability to reasonably download the games. I suspect the percentage is relatively high, but I know of a few anecdotes of rural areas with no reasonable high speed internet option. Second, you have to figure of those that can, how many prefer optical media. On tech sites the community gives the feeling of being all in on download-only distribution models, but in the market I know several people who buy movies and games on disc even when they have downloadable options. If that is a large chunk of the market and MS dumps optical media and Sony doesn't, this could be a significant differentiator.
Finally, your options for backwards compatibility are limited. If your older library games just won't physically fit in the system, that's a problem.
(in fact, the "Linux-based" part is so unimportant in webOS that webOS can run on any kernel, as long as a WebKit and V8 implementation is there
Nope. For some apps, sure, but for any of the PDK type stuff, I'd say it's more 'linuxy' than Android (C code targeting SDL API seems more typical linux than what I hear you do in Android.
Volume buttons aren't exactly 'feature rich'. I had a hands on and yes, I could tell the touch capability was worse than my Android phone, but I thought it sufficient and understandable given the price point. Given the frequency and urgency that frequently comes with volume adjustment made the lack of volume control a deal breaker however.
Here's the thing, with WebOS it was nicely integrated. When I looked at the card view and saw each web page and each conversation in one unified, visually sane list, it was great. In Android, MDI is every app for itself. So I have to switch to the app then navigate within the app to find the piece of interest whereas in webos I just had to switch the app. I still haven't got an intuitive feel for when the built-in browser reuses an existing 'window' versus opening a new one in some cases.
It's really small details that make a big difference to me. A coherent, unified messaging app (simple trick of using libpurple, mostly). The ability to sanely manage multiple text conversations at once ('cards' compromising between full fledged desktop metaphor and mobile form factor). Architecture that prioritized keeping running apps running instead of arbitrary kills on 'background' applications. Architecture that didn't encourage every task switch to induce piss-poor home-written state restores (why is it when I switch to a browser, my SMS conversation closes when I switch back???).
For a complex project that is formerly closed, open sourcing is generally a big deal. It costs significant amounts of time and money. Real 'abandonware' only sees open source through an 'unofficial' labor of love by developers (e.g. star control 2). If they truly wanted to abandon, they'd just full stop on all efforts and let it die as a proprietary platform with no hope of revival.
It also doesn't make any support load go away. HP doesn't magically get out of any support obligation they may have by open sourcing it.
I seriously, seriously doubt that there are viable buyers at this point. I'm fairly convinced HP exhausted that option before open sourcing. Of course, open sourcing is much harder than just closing the whole effort down, so HP is spending money on WebOS for *some* reason.
The issue I see is I don't see how WebOS's 'magic' would have been so difficult to implement, and yet no one bothered. With WebOS effectively dead, I don't see Android, iOS, or even WP7 jumping up and down to repeat *any* move WebOS made. The simple move of including a chat feature built around libpurple is less work for more benefit, but no one else did it. Instead of having complicated and inconsistent rules about when an application is 'running' or 'backgrounded', the desktop-like 'card' management was much easier.
Of course, as much as I loved that multitasking interface, my WebOS device never got me nearly the battery runtime my android device has given me, and that might have been a contributor...
Realistically, I see WebOS evaporating as well is Tizen. Android is more than a technology platform, it is a brand. The word 'webOS' does not carry the marketing value that 'android' does. Apple has already set the pace of mobile experience being dominated by one-off applications more than more neutral web interfaces and so you have a significant network effect in play, no company backing means a distinct lack of applications for users and a dead platform.
Even if you subscribe to the theory the mobile market continues to show high volatility and there isn't the signs of insurmountable entrenchment like the desktop market and therefore anything including WebOS has a shot, WebOS is severely handicapped. It comes with the baggage of failing to bail out the once-great Palm, of sucking billions out of HP, and every appearance of being abandoned as a result. A technical advocate trying to get business leadership to recognize the value in the platform and commit to it has very little to no chance of convincing business leaders given the track record.
It's a shame too, ever since I had to go to an Android device, I've found the experience *highly* annoying compared to WebOS.
-The gestures were so nice and smooth and I miss them.
-As a corollary, 'back' was a lot more consistent (in Android, it ends up serving double duty for per-app 'back' and task switching if it thinks it appropriate).
-Same for menus, Android apps are a mess with how inconsistently they deal with the menu button being pressed, and 99% of the time additional content is inelegantly dumped into one 'more settings' button.
-When I switched away and back to an app in WebOS, the interface was just so much more sensible and showing what was going on better.
-When I switch away and back in WebOS, the app was always consistent with where I left it last. In Android, it's a crap shoot. Sometimes the app just continues running in memory and is consistent when I return, sometimes that same app was killed arbitrarily by the OS and doesn't restore, sometimes an app faced with that inconsistency just always forces their piss-poor state restore every time they are backgrounded.
-I could reasonably manage multiple textual conversations in baked in WebOS chat. Multiple chats open concurrently all under a single coherent messaging system. Now if I get gTalk, one app manages it and if I get SMS, something else handles it. If I'm chatting with someone and switch away to look up something and switch back, the SMS app has closed my conversation and I have to find it again.
What is being said is he can't figure out a *single* 'monster' company built on open-source software even allowing for services revenue. His list suggests a very high requirement for being 'monster', which may be useless as a criteria of the viability of open source as a business model. Stop the car analogies, it doesn't help.
I would say the fact that 'There are fewer open source companies' (that you've heard of) could *either* mean not as many people try (your implication) or that as many people try, but so many more fail with the open source route. I personally suspect there is a bit more truth in the latter. It seems that either:
-You need a massive userbase You get a boost by having a much more straightforward free-to-use situation that could fuel your project becoming the de facto standard even if 99% of your users don't give you a dime (e.g. MySQL). Paying customers recognize they do need support, but find it better to have consistency between their non-critical, unpaid usage of your project and their critical usage.
-You have some 'secret sauce' that is not open source. Google's real tech value comes in software that never leaves their datacenters. Most internet companies with a positive open source reputation fall under this category. You also have things like OSX, with Darwin being the open source stuff and most of the user-visible substance being closed source.
-You use popularity of your internet-connected software to present ads/game referral links. The former is a ton of iOS/Android apps that are relying upon the laziness of people hitting up the market (sometimes even paying for it) rather than finding a free source or rebuilding it with those things changed. Another example is Canonical doing things like integrating Amazon MP3 purchase using their identifier as a referer. This latter sort of thing presents pretty much no impetus for someone to bother to dig in and change it, though I don't think Ubuntu's popularity suffices to drive a significant amount of revenue in this way.
Continuing to presume it is possible to embed the algorithm (I'll bet it isn't, probably requires more data and/or compute power than the individual sensors can provide, but hypothetically...). Embedding it in hardware doesn't make it any easier to reverse-engineer, it *does* make it at least somewhat more difficult in some scenarios. Software can (easily) be reverse engineered, so the fact that Hardware can too is no reason to shy from the strategy.
Embedding it the sensors accomplishes a few things. For one, the 'closed' source pill goes down easier amongst the community when it's traditional firmware. Exception comes when your entire platform is 'firmware' (e.g. Honeycomb tablets), but a very small population complains about the closed source nature of their laptop BIOS. For another, it gives freedom to take the software half of your business two ways. Either you have a total hardware/software solution with the two components meaningfully linked to one another (in many cases, a customer would perceive more value and be willing to pay more). On the other hand, you could put all your business into the 'hardware', and leave everything open source. You would have to work some on contributions and packaging the open source software for your product, but your investment would be lower.
Problem being is any arbitrary representation by a computer is no more 'abstract' from the reality being tracked in cases like a desk calendar. Scrawling dates on an arbitrarily marked piece of paper to represent particular points in time is just as abstract representation of time as typing words into a computer.
Bookshelf representation is 'cute' and all, but I've never seen someone use *that* as the navigation method instead of searching a word they know is in the title. It's not like a list of titles or authors or anything overwhelm people because it's just 'too abstract', people just thought it looks neat. The same applies to all these constructs, highly impractical, not particularly less daunting than more straightforward alternatives, just a UI to have a certain aesthetic.
There are tons of examples of UIs that model the good *and* the bad of non-computer interfaces that were in use before many of the target users were even born. Arbirtary pagination that makes no sense in terms of where the content is broken up, or even requiring user to flip through irrelevant pages on their way to the desired page because that's the way it kinda works in paper media. This sort of phenomenon seems to be a deserving target of his displeasure.
As to the rest, I think the barrier to 'power user' is a bit lower than you expect. I know plenty of people not particularly inclined toward tech (not in a job inherently about technology, not playing games or otherwise doing much with a computer at home) and I have heard them express displeasure. The problem is 'do what they need to do and move on with their life'. If it is a task that they have to do 10 times a day and an over-simplified interface makes them spend 10 times the amount of time each time so they don't have to spend 5 minutes learning something, they've lost and they recognize that the simple path doesn't make sense after a few dozen times through it.
While I anticipate Google to have one of the most complex networks, they also probably have a more reasonable organizational structure populated by more talented individuals on the whole. I say this not because I think Google is magic, but I optimistically *hope* they aren't as bad as some of the companies I have dealt with. Most companies have a technical staff either not talented enough, bound up in an impossibly convoluted organizational structure that paralyses them in any efforts to technically advance the state of things, or some combination of the two.
Early large-scale adopters like Google have suffered the leading edge of vendors trying to get ready. In terms of the problems Google ran into, I'd wager a large chunk of them won't be inflicted again by the same company. Once kinks are worked out for even one customer, they are generally worked out for all customers.
That said, while I've seen a large amount of increased IPv6 capability from vendors (showing they have expertise *somewhere*), it's still an arcane art for almost everyone at these companies still yet relative to IPv4.
The whole point of the server service processors is to always work no matter what. To maximize the chance of this happening, the hardware vendors want the software running on them to be as tested and deterministic as possible. If end-user code fork bombs or triggers OOM killer to effectively ruin the running state of the service processor, that is bad. Ideally, you'd think an end-user would realize the blame was all their own, but two things occur:
-'Why didn't you make your platform bullet-proof no matter how my code misbehaves?'
-'I can't tell that *my* code is broken so I'm assuming perceived instability is due to the vendor'.
On the *other* hand, if you need to run custom code, you have an actual *operating system* to modify. Generally all the benefits of running *directly* on the service processor can be accessed by your choice of running in the managed OS and talking to the existing code or similarly doing it over the network.
From my *personal* perspective, I do have some stuff stored in a 'cloud' provider, but I *don't* trust any encryption they provide, I gpg it before upload. This is *not* stuff I'd care about the government seeing, incidently. My presumption is the gpg protection should suffice in the face of realistic attacks mounted by people who could do something apart from the government. Additionally, if broken, the damage would be recoverable.
From a business perspective, after talking to various companies, my take on the general outlook:
-If it's material like advertising/marketing, wherever is cheaper, no confidentiality to sweat.
-If it's material that the company doesn't explicitly care about, *but* is regulated to protect the confidentiality (e.g. incidental medical data subject to HIPAA accumulated by a non-medical company), then they would almost certainly put it on a 'cloud' *if* liability were part of the agreement. The rationale being they only care about being sued/not sued. If they don't have to store or audit the data and lawsuits pretty much go straight to the provider, they are very happy. No provider seems to be stepping up to offer that however.
-If it's material that the company explicitly cares about (e.g. future product designs by a manufacturer), no way in hell. If they did outsource, they'd spend about as much money *auditing* their provider as they would protecting it themselves (if not more) and still not being as comfortable, so why bother. They feel the damages they could get through legal channels would likely not offset their opinion of their loss.
From the video, it looks like they are just saying the keyboard can slide around a bit, but you'd not want to do that for anything other than very light use. It looked pretty clumsy to get to those special keys when they showed someone typing...