Actually, I'd go with 'yes, if a bit hyperbolic' on this one. Even in a hypothetical libertarian utopia, the military and police functions are deemed within the legitimate scope of the state, and not exactly expected to be paid for by donations and bake sales(in fact, the bake sales would be specifically illegitimate since they'd be a particularly feckless flavor of state industry).
And, if you must have taxation, are you actually better off with incompetent, ideosyncratic, error-prone, and potentially insecure taxation, likely focused on shaking down easy targets in order to save money, rather than aiming for greatest possible procedural uniformity? Obviously, nobody enjoys the fact that things cost money, and essentially nobody would assert that our tax code, our budget, or both(usually both) are remotely optimal; but it is vanishingly unlikely that the reforms you(or anybody else) wants are something you'll be lucky enough to get as a product of the IRS flailing around in absence of the resources to operate as designed, or the state as a whole flailing around in an attempt to deal with budget shortfalls(unexpected ones in particular).
Even the wholly serious 'starve the beast' theorists tend to be dangerously optimistic about the order in which various organs of 'the beast' will atrophy(frequently not the order they want); as well as tending to ignore the fact that, until deficit spending becomes impossible(either through political impasse over debt ceilings, or because the world at large won't buy T-bills anymore) deficit spending actually makes government-provided services more attractive(given that the US government can generally borrow with minimal difficulty and at fairly good rates, the percentage of a given project funded by debt is, at least in the short to medium term, almost indistinguishable from a pure discount. In the suitably long term, or to people who have a gnawing fear of 'debt' as a concept, this is troubling; but aside from them, deficit spending actually makes it easier to sell government programs: even fairly half-assed ideas start to look good at a suitable discount.)
For these reasons, I'd maintain that any gloating about IRS dysfunction is deeply shortsighted and (unless it is specifically helping you avoid scrutiny of your stash in the Caymans), likely even self destructive: There are many potential gains to be realized through improvements in the tax structure and budget; but it is not actually that likely that they will be realized by unsystematic institutional starvation, while the consequences of a system too dysfunctional to even administer the already problematic tax code and budget as they are written are quite unlikely to be improvements.
Is there anything worth doing in 'web' that isn't covered by just combining the server and the content into one solid mass of bash HTTP parsers and dubious netcat abuse?
In fact, is there anything worth doing on the 'inter-net' for which something very similar isn't true?
With the one caveat that, unless your client was already selling herbal viagra and penis pills, you'd better allocate enough time for patching in perpetuity and/or until the money runs out.
Not like web servers haven't had their share of bugs; but you'd think Adobe had something to do with Wordpress.
A compelling use case, a way to use it without looking like a total glasshole, good battery life, no pictures of screaming Robert Scoble in the shower?
Damn, I didn't even mean to do that. My enthusiasm for terrible puns is gradually being migrated to some sort of hardware coprocessor lodged deep within my language systems. This can't be good.
So, which Linux distro that I installed in 2003 still has active security updates today? Which one even had more than four years of support? Today it's not big deal. I can install CentOS for free and get updates for ten years, but if I installed Linux back then I would have had to personally finance the security patches for at least half the deployment time.
I suspect that it's a matter of scale: If your use simply isn't all that big, or migration sucks; but isn't too terribly costly, the right to get support from anyone willing to offer it is mostly theoretical. Unless you, while personally small, are part of a larger market that wants the same thing, it just won't be economic to pay the necessary people to write the software and then deploy a handful of copies. The cost/unit will be insane.
If your use is much larger, though, or migration is a bowel-looseningly expensive labyrinth of pain, or both, the cost of getting the OS updated is the same; and now appears much more reasonable. In practice, the vendor may still be the best person to buy it from(given their familiarity with the product, your existing relationship, etc.); but the fact that you could buy elsewhere acts as an upper limit on the the price, since, while the vendor can likely command a premium, they cannot exert veto power over other market entrants in order to achieve a price calibrated closely to your maximum willingness to pay.
It's just the nature of software: Trivial duplication costs, fairly high production costs(alarmingly high if you really want it done right). Access is educational, can allow you to make comparatively small fixes for yourself, and similar, if you have the skill; but as a purely financial matter it matters most when you are working on a scale where "Actually, it'd be cheaper to fix the OS than it would be to port our applications to the new OS" is a statement of fact, not a negotiating tactic. With VMs (mostly) obviating driver maintenance issues(you still need to fix the old ones if they have vulnerabilities or other issues; but the fact that Linux 2.4x doesn't support a server you buy three years from now is a problem that can be solved with a thin layer of hypervisor, rather than horrific backporting) it becomes more practical to consider doing security fixes for the supporting OS until it's time for the entire system to die, rather than trying to port the application from hell just because the vendor doesn't love your OS anymore.
There may be an analogous hack(if MS was using a simple registry key, rather than something embedded in Windows Genuine Advantage(tm) to validate one specialty SKU, they might well have done the same elsewhere); but odds of the same one working are pretty much zero. There never was an 'embedded' version of Server 2003 for client devices.
Might be something to be found by sniffing around "Windows Server for Embedded Systems", which had a 2003-based version, as did "Windows Compute Cluster Server" and "Windows Storage Server".
Though, given the...'quality'... of software released by vendors with no particular software experience that are forced to include some software in their product(and even companies that should know better, like the ones that puke out painfully broken routers year after year), it would utterly fail to surprise me if the substantial majority of exploits under this scheme are based on idiotic behavior in the application, with the underlying OS and stock userland being dangerous mostly because they provide a familiar environment to work with once you've exploited the trivial weakness in the application.
It is true that a terrible application running on top of a linux image bodged together by clueless and apathetic amateurs would be even worse, so I guess this is better than nothing; but even if the OS were perfect, I suspect that overall security would remain at swiss cheese levels.
I'm guessing that usability will depend on whether the lack of vendor drivers causes it to fail into 'keep it simple, stupid' mode(in which case it'll be just fine, possibly even better than the more unpleasant Windows experiences; but the mac users will be displeased), or whether it will take a stab at being clever, as trackpad vendors have lately had the nasty habit of doing, mostly to everyone's regret and shame; but without even the minimal level of polish provided by the vendor. That would be a clusterfuck.
As long as it doesn't try anything fancy it'll be perfectly survivable. It's just if there's some half-exorcised ghost of Win8 gesture behavior in the firmware that it will refute a loving god every time you touch it.
It is possible, any but the most broken SD cards are reasonably well behaved block devices under the abstractions provided by readers; but the trouble is compatibility with embedded devices. You can format an SD card, or an SDHC card, or an SDXC card, in any FS you want; but if you pop it into a camera, don't expect the camera to do anything other than ask if you want to format the card.
Option 1: the plan is to include one of the card-reader modules that connects to the USB bus and encapsulates the card neatly behind the abstraction of a mass storage class device. The user then either reformats an ExFAT card, or quietly obtains a Free-but-patent-infringing filesystem implementation. This seems less likely; because that's just one more blob of code(in the SD/USB translation chip) that the user can't see in any real sense).
Option 2: The necessary I/O is directly hooked in per the SDXC spec, including support for any changes made since SDHC(I don't think that there were all that many; but they probably tweaked something just for giggles). The OS will be able to operate on the SDXC block device just fine; and use it without incident if reformatted; but you'll have to quietly bring your own solution to the table if you want to read ExFAT.
They may have to skip using the trademarked SDXC logo, since it may not be judged 'SDXC' if it doesn't read ExFAT out of the box; but you don't need to license ExFAT to ship 100% of the hardware needed to manipulate the SD card.
Argument one will be that these devices are in no way in contradiction with the fourth amendment because nobody with RF-permiable walls can have a reasonable expectation of privacy in anything they just leave lying around in the open like that. It's not different, aside from wavelength and a few hundred thousand dollars worth of hardware, from leaving things right next to a giant window, right?
If that one fails (sadly, this can be rated as only 'moderately' probable), its utility against Drugs, Terrorists, Pedo-terrorist-drugs, and similar threats to the community will be trotted out. If (again, sadly, this can be rated as only 'moderately' probable) the judge points out that 'utility' is actually orthogonal to 'legality' we will move to argument three:
The devices will be transferred to the jurisdiction of an entity with substantial clandestine activity(DEA, say) and all information pertaining to its use will be classified, and all information derived from its use will be laundered by 'parallel construction'; and any FOIA requests, evidence requests by defense attorneys, and similar uppity behavior will be referred to a blank denial on the grounds of 'potentially compromising classified sources and methods'.
I've read that Intel's current popularity is, at least in part, based on a willingness to accept margins at or below zero, which pushes their parts from "Actually reasonably competitive" to "Design win!", at an obvious cost in actually making money; but in my experience with Intel-based devices, they do a surprisingly good job of completely papering over any differences that you might notice or be annoyed by. All the Dalvik stuff works, Intel has been fairly aggressive about making sure x86 Android is something approaching a first-class citizen(or at least a second class citizen who can afford a butler), and their emulation layer for handling native ARM binaries works better than I would have expected.
You start to notice the major differences when poking around in the bootloader; intel dances off into their own merry little world when it comes to implementation of Fastboot and the bootloader(though, while they have a very different feel than ARM devices, they are more homogenous than the zillion-odd ARM SoC vendors combined with the few dozen device vendors working on top of them).
It remains to be seen if their share will survive once the shareholders start asking them if they plan to subsidize Android tablets forever; but so long as they are willing to the results actually seem to work pretty well. Notably unlike MIPS Android, now that's a winner...
As with Android, Samsung's sincerity in dealing fairly with other potential users would likely vary markedly based on how successful they are.
It's almost always the case, Free or proprietary, that if there's a single major entity behind a project, the project will end up taking on their objectives to a substantial degree(with the, sometimes important, sometimes irrelevant, caveat that in the case of Free licenses you can't 'take back' what you've already released, you can only let it rot, or try to render it irrelevant, while proprietary licenses, unless specifically constructed to be irrevocable, can usually be changed).
Back when the iPhone was really kicking asses and taking names, Google was a lot more...friendly...about Android, and the 'Android' that was actually worth building a phone around was a lot closer to AOSP(and, indeed, given the state of vendor skinning, AOSP was often better). As Google's position has improved, the details of what it takes to be a Google Product Buddy have apparently become steadily more draconian, and the percentage of 'Android' that is AOSP has declined, with a given OSS component typically ossifying right around the time a Google or Google Play Services equivalent comes out. Now, because Android is 'free', at least once you remove the Google stuff, Google has not been able to prevent things like FireOS(though Amazon had to duplicate a hell of a lot of Google services at least approximately to make it a contender), or the use of Android as a cheap, functional, firmware for media-stick widgets and stuff; but it's fairly clear that they view their position as better now.
I don't see why the same would not be true of Samsung: if they are treading water in 4th place, I suspect that they'll actually be pretty damned nice to anyone who wants to build a Tizen device(especially one that doesn't directly overlap with a Samsung product, or one that involves purchasing some Samsung silicon). If you want 'ecosystem' you can't fuck over your potential partners from day one(especially with the even cheaper Chinese guys nipping at your heels). The question becomes how things will change were Tizen to become more successful. How would Samsung attempt to maintain control? Delayed releases? A Google Play Services-like proprietary component increasingly vital to actually shipping what customers expect? Arbitrary breaking of stuff between rapid-fire releases? Also a question would be whether any 'FireOS'-like offspring would come of the process. Even if Tizen is only modestly successful, or even a failure as a 3rd party dev target, having a Linux + touch-friendly graphics layer project, with some sharing of development costs, is something that would appeal to a potentially much wider group of device producers, not necessarily interested in app stores. A reasonably low footprint firmware that can be mostly reused across any device that needs a UI, with a common company style and just application-level changes to support different interface requirements? Even if no 3rd party devs want in(aside from, perhaps, a few explicitly licensed deals with streaming providers for your TV or something like that), you still iron out your own inconsistencies.
As a 'samsung corporate firmware' Tizen could fail only through fairly heavy handed snatching of defeat from the jaws of victory. Outside of some very constrained systems, hard RTOS cases, and other specialty areas, there isn't anything particularly wrong with Linux as an embedded OS, nor are there any other glaring architectural horrors(though I think X11 vs. Wayland is still simmering down a touch, not sure how the real-world usage breakdown looks); and it seems perfectly reasonable that Samsung could cut costs, increase consistency across product lines, and maybe even ship fewer unsupported-and-broken firmwares and UIs by sharing more common code across products.
What is less clear is if this will turn into an 'ecosystem' (either in the limited sense of 'samsung products interoperating in a way that actually increases their value', which is trickier than it sounds and I wouldn't necessarily trust the 'smart TV' makers of the world to get right. Or in the stronger sense of 'Tizen' is a target that 3rd party developers can shoot for compatibility with, and one that they actually bother to do so.)
Given the amount of stuff Samsung slings, they can probably win even if only the more limited sense is achieved, or even only partially achieved. Less reinventing the wheel, fewer UIs that looked like they crawled out of a dadaist nightmare, shared engineering effort, etc. If they can't make "Linux +X11 and Enlightenment, or Wayland and Enlightenment" work, they have issues. Whether they can sell others on the idea is a different question.
Palm (in my beating-a-dead-horse opinion) actually did a damned good job with WebOS, not that it helped them; but there was absolutely zero continuity between the two(I vaguely remember a rumor of an emulator, or something; but nothing else). And that was for the best. Classic PalmOS worked amazingly well in constrained environments, and the 'conduit' sync concept was pretty elegant for a device that was expected to operate disconnected much of the time, occasionally syncing with a computer(or, if you were a power-user-nerd, via modem). Attempts to hack proper network connectivity in on top of it were always inelegant at best, and once you had substantial computer at your disposal, it was more or less impossible to forgive the various tradeoffs made to work with very low resource devices.
I'm not entirely convinced of this(most notably, despite their absurd superiority to the toy crap offered by PC compatibles, Apple, Commodore, etc., essentially all 'workstation' hardware and operating systems, and often the vendors that made them, were crushed into the dust and sold off, and are either extinct or hanging on as high end servers that once had workstation equivalents, like IBM's AIX-on-Power stuff. Superior; but too costly. Even today's crazy-price-is-no-object workstation will be effectively 100% a child of the cheap and awful PC compatibles, with the exception of OpenGL, since SGI gave that away shortly before they bled out.)
Aside from that, though, 'best' appears to be a tricky mark to hit, and a harder one to maintain, in mobile devices. Many of the components are substantially commodified, and those that are not are frequently tied together such that OEMs have limited choices(and often the same set of limited choices, as with the number of outfits that use Qualcomm chips in their US market phones, even if, like Samsung, they have their own; because that's what you do if you want Qualcomm radio silicon). The constraints of battery life and device size also keep 'best' from being an obvious specific direction.
The trouble with 'fork Android' is that (while certainly helpful, in terms of getting hardware you can actually buy, that isn't a dev board or similar, from power-on to an actually usable screen that you can interact with) is that the stuff that makes 'Android' 'Android' is substantially the spyware.
There are some changes you can make, that don't compromise the function much and thwart the less competent bugs (eg. being able to 'lie' and grant an app access to a falsified version of a resource); but if you start with AOSP and then add only apps that aren't 'monetizing' you as hard as they can, you'll end up with a pretty slim result. Between all the individual apps that are barely more than trojans, and Google Play Services,(plus, of course, the telco that is probably involved), there just isn't much left if you try to render an Android device safe. Unfortunately, neither Apple nor Microsoft are willing to help you much in this area. They are arguably incrementally better; but far less than you'd want.
Sounds somewhat like poor old classic PalmOS. Agile as hell on virtually no hardware at all; but increasingly lost and confused as capabilities expanded, and absolutely no logical room for growth, except perhaps as an emulator on something totally different.
They may well be absolutely lacking in foresight; but it's hard to imagine the density needed to ignore the size of the writedown HP took on autonomy. Buying Compaq was a lousy plan, and the assorted nonsense about realizing synergies and leveraging things and so on failed to materialize; but with Autonomy HP HQ outright said "Well, we paid 10 billion dollars for something that we can now only value at 1.2 billion; because we fucked up." That seems like the sort of thing that would go right into 'your head on a platter, now' territory, were it my money on the line at that scale.
That's why 'travel speed and cost' are such important variables. If travel is relatively expensive, 'this rock' is valuable even if there are trillions like it; because the trillions like it are somewhere else. If travel is extremely cheap, you pretty much have to enjoy risk of violent death and social disapproval, or reproduce at geometric rates until even trillions of rocks are a scarce resource, in order to bother fighting over a specific one.
(Also, unless your travel mechanism posits something super-handy for travel; but magically without broader implications for energy production and density and mass acceleration and delivery, 'assumptions about travel' quickly turn into 'assumptions about availability of hardware that would beat up today's thermonuclear weapons and take their lunch money. Unless the mechanism is 'magic clean teleportation that for some reason isn't good for telefragging, covertly removing the core of an opponent's planet and/or inserting a singularity to devour it, and doesn't destroy the very concept of barriers', it probably involves heroic energy, extraordinary velocities achieved by relatively massive objects, and/or dubiously sensible manipulations of spacetime. That would be the other...disincentive...toward violence. If space travel is too slow and difficult, the attacker will generally lose because of impossibly long supply chains and a tendency to be years or centuries behind by the time they arrive. If space travel is fast, so is sending a kinetic kill vehicle large enough to exterminate an entire planetary ecosystem, or leaving an off-the-shelf unobtanium reactor rigged to blow if somebody messes with your rock.)
Barring radically exotic/indistinguishable from magic travel techniques that aren't 'accelerate in the right direction, keep doing that until it's time to start decelerating', estimates are that nuclear propulsion is on the painfully low end of potential viability for travel within reasonable time. In a hypothetical scenario that features downright practical space travel, your potential combatants are probably going to be jumpier than Cold War game theorists about what will happen if anything gets out of hand.
For extra fun, of course, unless FTL communications are available, all diplomacy takes place with a substantial time lag, since most nontrivial objects are multiple light years from one another; but if travel is supposed to be practical, you'll be able to deliver a doomsday kinetic kill weapon almost as quickly as you'll be able to exchange a single hail and reply(possibly faster, since the weapon only needs to go one way, while dialog is a round trip, so anything that posits mass delivery at.5C or better but no FTL communication implies that the guy on the other end of the line can be a smoking crater before you even receive his response, if you so choose. And, since you'll both have several years of boiling public hysteria and gnawing panic as to whether or not he shot first, and there's a low-radar-profile asteroid with your name on it; there's plenty of room for two cultures to make contact and dispatch a first strike before they've even had time for a friendly chat. For further additional fun, preserving 'second strike' capability in the face of such destructive power would involve a whole class of rather nasty and well hidden systems, potentially with deadman's switches primed centuries ago, just waiting for a misunderstanding.)
Your basic "Naval Battles of WWII; but with space lasers!" is really the starry eyed optimist's space war.
It's hard to be optimistic about the fate of a competitor starting from behind(and with Samsung, not exactly a bastion of taste, UI/UX expertise, or other software virtues, as the most visible player) and up against Android(which arguably has some seriously fucked design problems, but is actively being worked on and has Google's vast cloud-dominion behind it), iOS(which has zero users who aren't Apple; but usually manages to show the virtues of having a competent dictator), and WP(currently pretty tepid marketshare; but is a testament to the fact that MS can actually bring some talent to bear on a problem if somebody beats the hubris out of them enough times in a row).
That said, despite my low hopes, it sure would be nice to see it do better. Despite years of development, Android still bears some serious scars of either things that seemed like a good idea at the time(presumably back when supporting extremely resource constrained devices was still a consideration, in the period not long after it was developed as a successor to the OS used in 'sidekick' devices) or which simply didn't pan out(the not-actually-a-JVM-really-we-swear turned out not to be fast enough, so they added native extensions, and ARM turned out to more or less steamroller the competition in the smartphone space at about the same time, so nobody actually cared whether cross-platform worked or not, except Intel, who simply wrote up another shim to handle ARM native components). They say...nice...things about how well the audio system performs, as well.
It ships on a wide variety of devices that you can actually buy, today; but Android is pretty hard to get enthusiastic about as a pile of stuff dumped on top of Linux. A slightly less dysfunctional pile of stuff wouldn't be revolutionary; but it would be nice.
I'd expect justice approximately never; but I have to imagine that HP has a few HNW shareholders with scary lawyers who will be calling for the blood of the HP people responsible unless the feds come up with something suitably good on Autonomy's books.
It could turn out to be even worse: the description you quote sounds very similar to the hype for the unforgivably dreadful Spore's space stage. That was so awful that even genocide couldn't break the tedium, though it was possible.
Arguably, the question of whether there will be war 'in space'(as opposed to space travel, along with some messy little ground wars on inhabited planets and any sufficiently large habitable constructs; but minimal involvement between the two), depends pretty strongly on what assumptions you bake in about travel speed and cost, as well as those about the difficulty and cost of exploiting tricky objects like gas giants or very low density clouds of gas and dust.
If travel is fast and cheap, the universe is huge, so you'll really need to be emotionally involved to take much risk on protecting this rock when there are trillions of other rocks just like it(though if Berzerkers break out, their travel will presumably also be fast and cheap, and then you have issues). If travel is too slow, war gets less likely because the offense is at a substantial disadvantage: even if you can build 'generation ships' or similar that can survive journeys in the decades to centuries range, the locals will be decades to centuries ahead of where they were when you started out, while your ship will be decrepit at best. On occasion, you'll get lucky and the locals will have nuked themselves into the ground shortly before you show up; but barring that it will hurt.
It's only really when travel is cheap and fast enough that you can viably send the fleet to somewhere; but slow and expensive enough that borders, resource pockets, and assorted other points of interest are highly valuable, that there's really a good case for something that actually looks much like terrestrial war.
Slashdot Mirror
That's horrible! Just horrible. Oh, the humanity!
Actually, I'd go with 'yes, if a bit hyperbolic' on this one. Even in a hypothetical libertarian utopia, the military and police functions are deemed within the legitimate scope of the state, and not exactly expected to be paid for by donations and bake sales(in fact, the bake sales would be specifically illegitimate since they'd be a particularly feckless flavor of state industry).
And, if you must have taxation, are you actually better off with incompetent, ideosyncratic, error-prone, and potentially insecure taxation, likely focused on shaking down easy targets in order to save money, rather than aiming for greatest possible procedural uniformity? Obviously, nobody enjoys the fact that things cost money, and essentially nobody would assert that our tax code, our budget, or both(usually both) are remotely optimal; but it is vanishingly unlikely that the reforms you(or anybody else) wants are something you'll be lucky enough to get as a product of the IRS flailing around in absence of the resources to operate as designed, or the state as a whole flailing around in an attempt to deal with budget shortfalls(unexpected ones in particular).
Even the wholly serious 'starve the beast' theorists tend to be dangerously optimistic about the order in which various organs of 'the beast' will atrophy(frequently not the order they want); as well as tending to ignore the fact that, until deficit spending becomes impossible(either through political impasse over debt ceilings, or because the world at large won't buy T-bills anymore) deficit spending actually makes government-provided services more attractive(given that the US government can generally borrow with minimal difficulty and at fairly good rates, the percentage of a given project funded by debt is, at least in the short to medium term, almost indistinguishable from a pure discount. In the suitably long term, or to people who have a gnawing fear of 'debt' as a concept, this is troubling; but aside from them, deficit spending actually makes it easier to sell government programs: even fairly half-assed ideas start to look good at a suitable discount.)
For these reasons, I'd maintain that any gloating about IRS dysfunction is deeply shortsighted and (unless it is specifically helping you avoid scrutiny of your stash in the Caymans), likely even self destructive: There are many potential gains to be realized through improvements in the tax structure and budget; but it is not actually that likely that they will be realized by unsystematic institutional starvation, while the consequences of a system too dysfunctional to even administer the already problematic tax code and budget as they are written are quite unlikely to be improvements.
Is there anything worth doing in 'web' that isn't covered by just combining the server and the content into one solid mass of bash HTTP parsers and dubious netcat abuse?
In fact, is there anything worth doing on the 'inter-net' for which something very similar isn't true?
With the one caveat that, unless your client was already selling herbal viagra and penis pills, you'd better allocate enough time for patching in perpetuity and/or until the money runs out.
Not like web servers haven't had their share of bugs; but you'd think Adobe had something to do with Wordpress.
A compelling use case, a way to use it without looking like a total glasshole, good battery life, no pictures of screaming Robert Scoble in the shower?
Damn, I didn't even mean to do that. My enthusiasm for terrible puns is gradually being migrated to some sort of hardware coprocessor lodged deep within my language systems. This can't be good.
So, which Linux distro that I installed in 2003 still has active security updates today? Which one even had more than four years of support? Today it's not big deal. I can install CentOS for free and get updates for ten years, but if I installed Linux back then I would have had to personally finance the security patches for at least half the deployment time.
I suspect that it's a matter of scale: If your use simply isn't all that big, or migration sucks; but isn't too terribly costly, the right to get support from anyone willing to offer it is mostly theoretical. Unless you, while personally small, are part of a larger market that wants the same thing, it just won't be economic to pay the necessary people to write the software and then deploy a handful of copies. The cost/unit will be insane.
If your use is much larger, though, or migration is a bowel-looseningly expensive labyrinth of pain, or both, the cost of getting the OS updated is the same; and now appears much more reasonable. In practice, the vendor may still be the best person to buy it from(given their familiarity with the product, your existing relationship, etc.); but the fact that you could buy elsewhere acts as an upper limit on the the price, since, while the vendor can likely command a premium, they cannot exert veto power over other market entrants in order to achieve a price calibrated closely to your maximum willingness to pay.
It's just the nature of software: Trivial duplication costs, fairly high production costs(alarmingly high if you really want it done right). Access is educational, can allow you to make comparatively small fixes for yourself, and similar, if you have the skill; but as a purely financial matter it matters most when you are working on a scale where "Actually, it'd be cheaper to fix the OS than it would be to port our applications to the new OS" is a statement of fact, not a negotiating tactic. With VMs (mostly) obviating driver maintenance issues(you still need to fix the old ones if they have vulnerabilities or other issues; but the fact that Linux 2.4x doesn't support a server you buy three years from now is a problem that can be solved with a thin layer of hypervisor, rather than horrific backporting) it becomes more practical to consider doing security fixes for the supporting OS until it's time for the entire system to die, rather than trying to port the application from hell just because the vendor doesn't love your OS anymore.
There may be an analogous hack(if MS was using a simple registry key, rather than something embedded in Windows Genuine Advantage(tm) to validate one specialty SKU, they might well have done the same elsewhere); but odds of the same one working are pretty much zero. There never was an 'embedded' version of Server 2003 for client devices.
Might be something to be found by sniffing around "Windows Server for Embedded Systems", which had a 2003-based version, as did "Windows Compute Cluster Server" and "Windows Storage Server".
Though, given the...'quality'... of software released by vendors with no particular software experience that are forced to include some software in their product(and even companies that should know better, like the ones that puke out painfully broken routers year after year), it would utterly fail to surprise me if the substantial majority of exploits under this scheme are based on idiotic behavior in the application, with the underlying OS and stock userland being dangerous mostly because they provide a familiar environment to work with once you've exploited the trivial weakness in the application.
It is true that a terrible application running on top of a linux image bodged together by clueless and apathetic amateurs would be even worse, so I guess this is better than nothing; but even if the OS were perfect, I suspect that overall security would remain at swiss cheese levels.
I'm guessing that usability will depend on whether the lack of vendor drivers causes it to fail into 'keep it simple, stupid' mode(in which case it'll be just fine, possibly even better than the more unpleasant Windows experiences; but the mac users will be displeased), or whether it will take a stab at being clever, as trackpad vendors have lately had the nasty habit of doing, mostly to everyone's regret and shame; but without even the minimal level of polish provided by the vendor. That would be a clusterfuck.
As long as it doesn't try anything fancy it'll be perfectly survivable. It's just if there's some half-exorcised ghost of Win8 gesture behavior in the firmware that it will refute a loving god every time you touch it.
It is possible, any but the most broken SD cards are reasonably well behaved block devices under the abstractions provided by readers; but the trouble is compatibility with embedded devices. You can format an SD card, or an SDHC card, or an SDXC card, in any FS you want; but if you pop it into a camera, don't expect the camera to do anything other than ask if you want to format the card.
I can think of two possible options:
Option 1: the plan is to include one of the card-reader modules that connects to the USB bus and encapsulates the card neatly behind the abstraction of a mass storage class device. The user then either reformats an ExFAT card, or quietly obtains a Free-but-patent-infringing filesystem implementation. This seems less likely; because that's just one more blob of code(in the SD/USB translation chip) that the user can't see in any real sense).
Option 2: The necessary I/O is directly hooked in per the SDXC spec, including support for any changes made since SDHC(I don't think that there were all that many; but they probably tweaked something just for giggles). The OS will be able to operate on the SDXC block device just fine; and use it without incident if reformatted; but you'll have to quietly bring your own solution to the table if you want to read ExFAT.
They may have to skip using the trademarked SDXC logo, since it may not be judged 'SDXC' if it doesn't read ExFAT out of the box; but you don't need to license ExFAT to ship 100% of the hardware needed to manipulate the SD card.
Argument one will be that these devices are in no way in contradiction with the fourth amendment because nobody with RF-permiable walls can have a reasonable expectation of privacy in anything they just leave lying around in the open like that. It's not different, aside from wavelength and a few hundred thousand dollars worth of hardware, from leaving things right next to a giant window, right?
If that one fails (sadly, this can be rated as only 'moderately' probable), its utility against Drugs, Terrorists, Pedo-terrorist-drugs, and similar threats to the community will be trotted out. If (again, sadly, this can be rated as only 'moderately' probable) the judge points out that 'utility' is actually orthogonal to 'legality' we will move to argument three:
The devices will be transferred to the jurisdiction of an entity with substantial clandestine activity(DEA, say) and all information pertaining to its use will be classified, and all information derived from its use will be laundered by 'parallel construction'; and any FOIA requests, evidence requests by defense attorneys, and similar uppity behavior will be referred to a blank denial on the grounds of 'potentially compromising classified sources and methods'.
I've read that Intel's current popularity is, at least in part, based on a willingness to accept margins at or below zero, which pushes their parts from "Actually reasonably competitive" to "Design win!", at an obvious cost in actually making money; but in my experience with Intel-based devices, they do a surprisingly good job of completely papering over any differences that you might notice or be annoyed by. All the Dalvik stuff works, Intel has been fairly aggressive about making sure x86 Android is something approaching a first-class citizen(or at least a second class citizen who can afford a butler), and their emulation layer for handling native ARM binaries works better than I would have expected.
You start to notice the major differences when poking around in the bootloader; intel dances off into their own merry little world when it comes to implementation of Fastboot and the bootloader(though, while they have a very different feel than ARM devices, they are more homogenous than the zillion-odd ARM SoC vendors combined with the few dozen device vendors working on top of them).
It remains to be seen if their share will survive once the shareholders start asking them if they plan to subsidize Android tablets forever; but so long as they are willing to the results actually seem to work pretty well. Notably unlike MIPS Android, now that's a winner...
As with Android, Samsung's sincerity in dealing fairly with other potential users would likely vary markedly based on how successful they are.
It's almost always the case, Free or proprietary, that if there's a single major entity behind a project, the project will end up taking on their objectives to a substantial degree(with the, sometimes important, sometimes irrelevant, caveat that in the case of Free licenses you can't 'take back' what you've already released, you can only let it rot, or try to render it irrelevant, while proprietary licenses, unless specifically constructed to be irrevocable, can usually be changed).
Back when the iPhone was really kicking asses and taking names, Google was a lot more...friendly...about Android, and the 'Android' that was actually worth building a phone around was a lot closer to AOSP(and, indeed, given the state of vendor skinning, AOSP was often better). As Google's position has improved, the details of what it takes to be a Google Product Buddy have apparently become steadily more draconian, and the percentage of 'Android' that is AOSP has declined, with a given OSS component typically ossifying right around the time a Google or Google Play Services equivalent comes out. Now, because Android is 'free', at least once you remove the Google stuff, Google has not been able to prevent things like FireOS(though Amazon had to duplicate a hell of a lot of Google services at least approximately to make it a contender), or the use of Android as a cheap, functional, firmware for media-stick widgets and stuff; but it's fairly clear that they view their position as better now.
I don't see why the same would not be true of Samsung: if they are treading water in 4th place, I suspect that they'll actually be pretty damned nice to anyone who wants to build a Tizen device(especially one that doesn't directly overlap with a Samsung product, or one that involves purchasing some Samsung silicon). If you want 'ecosystem' you can't fuck over your potential partners from day one(especially with the even cheaper Chinese guys nipping at your heels). The question becomes how things will change were Tizen to become more successful. How would Samsung attempt to maintain control? Delayed releases? A Google Play Services-like proprietary component increasingly vital to actually shipping what customers expect? Arbitrary breaking of stuff between rapid-fire releases? Also a question would be whether any 'FireOS'-like offspring would come of the process. Even if Tizen is only modestly successful, or even a failure as a 3rd party dev target, having a Linux + touch-friendly graphics layer project, with some sharing of development costs, is something that would appeal to a potentially much wider group of device producers, not necessarily interested in app stores. A reasonably low footprint firmware that can be mostly reused across any device that needs a UI, with a common company style and just application-level changes to support different interface requirements? Even if no 3rd party devs want in(aside from, perhaps, a few explicitly licensed deals with streaming providers for your TV or something like that), you still iron out your own inconsistencies.
As a 'samsung corporate firmware' Tizen could fail only through fairly heavy handed snatching of defeat from the jaws of victory. Outside of some very constrained systems, hard RTOS cases, and other specialty areas, there isn't anything particularly wrong with Linux as an embedded OS, nor are there any other glaring architectural horrors(though I think X11 vs. Wayland is still simmering down a touch, not sure how the real-world usage breakdown looks); and it seems perfectly reasonable that Samsung could cut costs, increase consistency across product lines, and maybe even ship fewer unsupported-and-broken firmwares and UIs by sharing more common code across products.
What is less clear is if this will turn into an 'ecosystem' (either in the limited sense of 'samsung products interoperating in a way that actually increases their value', which is trickier than it sounds and I wouldn't necessarily trust the 'smart TV' makers of the world to get right. Or in the stronger sense of 'Tizen' is a target that 3rd party developers can shoot for compatibility with, and one that they actually bother to do so.)
Given the amount of stuff Samsung slings, they can probably win even if only the more limited sense is achieved, or even only partially achieved. Less reinventing the wheel, fewer UIs that looked like they crawled out of a dadaist nightmare, shared engineering effort, etc. If they can't make "Linux +X11 and Enlightenment, or Wayland and Enlightenment" work, they have issues. Whether they can sell others on the idea is a different question.
Palm (in my beating-a-dead-horse opinion) actually did a damned good job with WebOS, not that it helped them; but there was absolutely zero continuity between the two(I vaguely remember a rumor of an emulator, or something; but nothing else). And that was for the best. Classic PalmOS worked amazingly well in constrained environments, and the 'conduit' sync concept was pretty elegant for a device that was expected to operate disconnected much of the time, occasionally syncing with a computer(or, if you were a power-user-nerd, via modem). Attempts to hack proper network connectivity in on top of it were always inelegant at best, and once you had substantial computer at your disposal, it was more or less impossible to forgive the various tradeoffs made to work with very low resource devices.
I'm not entirely convinced of this(most notably, despite their absurd superiority to the toy crap offered by PC compatibles, Apple, Commodore, etc., essentially all 'workstation' hardware and operating systems, and often the vendors that made them, were crushed into the dust and sold off, and are either extinct or hanging on as high end servers that once had workstation equivalents, like IBM's AIX-on-Power stuff. Superior; but too costly. Even today's crazy-price-is-no-object workstation will be effectively 100% a child of the cheap and awful PC compatibles, with the exception of OpenGL, since SGI gave that away shortly before they bled out.)
Aside from that, though, 'best' appears to be a tricky mark to hit, and a harder one to maintain, in mobile devices. Many of the components are substantially commodified, and those that are not are frequently tied together such that OEMs have limited choices(and often the same set of limited choices, as with the number of outfits that use Qualcomm chips in their US market phones, even if, like Samsung, they have their own; because that's what you do if you want Qualcomm radio silicon). The constraints of battery life and device size also keep 'best' from being an obvious specific direction.
The trouble with 'fork Android' is that (while certainly helpful, in terms of getting hardware you can actually buy, that isn't a dev board or similar, from power-on to an actually usable screen that you can interact with) is that the stuff that makes 'Android' 'Android' is substantially the spyware.
There are some changes you can make, that don't compromise the function much and thwart the less competent bugs (eg. being able to 'lie' and grant an app access to a falsified version of a resource); but if you start with AOSP and then add only apps that aren't 'monetizing' you as hard as they can, you'll end up with a pretty slim result. Between all the individual apps that are barely more than trojans, and Google Play Services,(plus, of course, the telco that is probably involved), there just isn't much left if you try to render an Android device safe. Unfortunately, neither Apple nor Microsoft are willing to help you much in this area. They are arguably incrementally better; but far less than you'd want.
Sounds somewhat like poor old classic PalmOS. Agile as hell on virtually no hardware at all; but increasingly lost and confused as capabilities expanded, and absolutely no logical room for growth, except perhaps as an emulator on something totally different.
They may well be absolutely lacking in foresight; but it's hard to imagine the density needed to ignore the size of the writedown HP took on autonomy. Buying Compaq was a lousy plan, and the assorted nonsense about realizing synergies and leveraging things and so on failed to materialize; but with Autonomy HP HQ outright said "Well, we paid 10 billion dollars for something that we can now only value at 1.2 billion; because we fucked up." That seems like the sort of thing that would go right into 'your head on a platter, now' territory, were it my money on the line at that scale.
That's why 'travel speed and cost' are such important variables. If travel is relatively expensive, 'this rock' is valuable even if there are trillions like it; because the trillions like it are somewhere else. If travel is extremely cheap, you pretty much have to enjoy risk of violent death and social disapproval, or reproduce at geometric rates until even trillions of rocks are a scarce resource, in order to bother fighting over a specific one.
.5C or better but no FTL communication implies that the guy on the other end of the line can be a smoking crater before you even receive his response, if you so choose. And, since you'll both have several years of boiling public hysteria and gnawing panic as to whether or not he shot first, and there's a low-radar-profile asteroid with your name on it; there's plenty of room for two cultures to make contact and dispatch a first strike before they've even had time for a friendly chat. For further additional fun, preserving 'second strike' capability in the face of such destructive power would involve a whole class of rather nasty and well hidden systems, potentially with deadman's switches primed centuries ago, just waiting for a misunderstanding.)
(Also, unless your travel mechanism posits something super-handy for travel; but magically without broader implications for energy production and density and mass acceleration and delivery, 'assumptions about travel' quickly turn into 'assumptions about availability of hardware that would beat up today's thermonuclear weapons and take their lunch money. Unless the mechanism is 'magic clean teleportation that for some reason isn't good for telefragging, covertly removing the core of an opponent's planet and/or inserting a singularity to devour it, and doesn't destroy the very concept of barriers', it probably involves heroic energy, extraordinary velocities achieved by relatively massive objects, and/or dubiously sensible manipulations of spacetime. That would be the other...disincentive...toward violence. If space travel is too slow and difficult, the attacker will generally lose because of impossibly long supply chains and a tendency to be years or centuries behind by the time they arrive. If space travel is fast, so is sending a kinetic kill vehicle large enough to exterminate an entire planetary ecosystem, or leaving an off-the-shelf unobtanium reactor rigged to blow if somebody messes with your rock.)
Barring radically exotic/indistinguishable from magic travel techniques that aren't 'accelerate in the right direction, keep doing that until it's time to start decelerating', estimates are that nuclear propulsion is on the painfully low end of potential viability for travel within reasonable time. In a hypothetical scenario that features downright practical space travel, your potential combatants are probably going to be jumpier than Cold War game theorists about what will happen if anything gets out of hand.
For extra fun, of course, unless FTL communications are available, all diplomacy takes place with a substantial time lag, since most nontrivial objects are multiple light years from one another; but if travel is supposed to be practical, you'll be able to deliver a doomsday kinetic kill weapon almost as quickly as you'll be able to exchange a single hail and reply(possibly faster, since the weapon only needs to go one way, while dialog is a round trip, so anything that posits mass delivery at
Your basic "Naval Battles of WWII; but with space lasers!" is really the starry eyed optimist's space war.
It's hard to be optimistic about the fate of a competitor starting from behind(and with Samsung, not exactly a bastion of taste, UI/UX expertise, or other software virtues, as the most visible player) and up against Android(which arguably has some seriously fucked design problems, but is actively being worked on and has Google's vast cloud-dominion behind it), iOS(which has zero users who aren't Apple; but usually manages to show the virtues of having a competent dictator), and WP(currently pretty tepid marketshare; but is a testament to the fact that MS can actually bring some talent to bear on a problem if somebody beats the hubris out of them enough times in a row).
That said, despite my low hopes, it sure would be nice to see it do better. Despite years of development, Android still bears some serious scars of either things that seemed like a good idea at the time(presumably back when supporting extremely resource constrained devices was still a consideration, in the period not long after it was developed as a successor to the OS used in 'sidekick' devices) or which simply didn't pan out(the not-actually-a-JVM-really-we-swear turned out not to be fast enough, so they added native extensions, and ARM turned out to more or less steamroller the competition in the smartphone space at about the same time, so nobody actually cared whether cross-platform worked or not, except Intel, who simply wrote up another shim to handle ARM native components). They say...nice...things about how well the audio system performs, as well.
It ships on a wide variety of devices that you can actually buy, today; but Android is pretty hard to get enthusiastic about as a pile of stuff dumped on top of Linux. A slightly less dysfunctional pile of stuff wouldn't be revolutionary; but it would be nice.
I'd expect justice approximately never; but I have to imagine that HP has a few HNW shareholders with scary lawyers who will be calling for the blood of the HP people responsible unless the feds come up with something suitably good on Autonomy's books.
It could turn out to be even worse: the description you quote sounds very similar to the hype for the unforgivably dreadful Spore's space stage. That was so awful that even genocide couldn't break the tedium, though it was possible.
Arguably, the question of whether there will be war 'in space'(as opposed to space travel, along with some messy little ground wars on inhabited planets and any sufficiently large habitable constructs; but minimal involvement between the two), depends pretty strongly on what assumptions you bake in about travel speed and cost, as well as those about the difficulty and cost of exploiting tricky objects like gas giants or very low density clouds of gas and dust.
If travel is fast and cheap, the universe is huge, so you'll really need to be emotionally involved to take much risk on protecting this rock when there are trillions of other rocks just like it(though if Berzerkers break out, their travel will presumably also be fast and cheap, and then you have issues). If travel is too slow, war gets less likely because the offense is at a substantial disadvantage: even if you can build 'generation ships' or similar that can survive journeys in the decades to centuries range, the locals will be decades to centuries ahead of where they were when you started out, while your ship will be decrepit at best. On occasion, you'll get lucky and the locals will have nuked themselves into the ground shortly before you show up; but barring that it will hurt.
It's only really when travel is cheap and fast enough that you can viably send the fleet to somewhere; but slow and expensive enough that borders, resource pockets, and assorted other points of interest are highly valuable, that there's really a good case for something that actually looks much like terrestrial war.