I can read countless stories of people who use things like EC2 and express disdain toward users afflicted by downtime because they didn't understand how to work it. When all is said and done, the users using EC2 'right' seem to end up having to worry all the frustrating details of HA they worried about before, 'Cloud' doesn't change that. The 'promise' is that you naively slap your workload into a 'cloud' provider and you don't have to think so hard about all of that. Even if Amazon doesn't explicitly make that promise, they certainly benefit from the general buzz along those lines and don't do a whole lot to quell that impression with non-technical decision managers.
Now you may say people who naively do that are overvaluing the 'cloud', and while that may be true, one has to seriously wonder what the value of 'cloud' is. I would say a large population of companies 'doing it right' end up spending the money to 'rent' computing power and then end up having to keep on their IT staff anyway and end up saving nothing or spending more.
*Particularly* initiatives like the US government 'moving to the cloud' needs to keep in mind they can't just ditch all those IT experts, and with that in mind, do you still achieve meaningful savings?
The open source web mail interfaces are not even close to what gmail does.
On this point I have to disagree. gmaill is highly capable and all, but I actually prefer roundcube's interface over gmail's.
I also disagree that maintaining a mail server competently is that hard for a single domain with maybe a half-dozen users. If you stick to packages provided by a linux distribution, distribution updates will handle most security updates. Many ISPs have blessed relays for your use that alleviates the blacklist problem significantly.
That said, I have co confess current state of gmail makes it hard to find reason to do it yourself. The only reason I could think of is fear for what google could do in the future given the fact they really can hold your email address hostage. If you pay for your own domain (using any subdomain like offered by dyndns or co.cc is begging for them to hold your domain hostage down the road (as dyndns already has done to its users), landing you in the same place. Since so many free offerings from other companies have either evaporated or 'altered' in unacceptable ways, it's not unreasonable to be wary of Google's take on the perceived business value of free email with ads. If data suggests the cost is higher than the revenue sometime later, say goodbye to your email.
Just to add, the interface can be abstracted from the email storage.
Currently, I have both roundcube and squirrelmail exposing my imap mailboxes. I tend to use roundcube, but other users tend to use squirrelmail. There are some capabilities in squirrelmail not in roundcube.
Last I checked, You have to shutdown a VM to take a snapshot.
Odd, the underlying stuff is agnostic, though a shutdown is a good idea in lieu of something like vmware guest utils to coordinate disk activity with the hypervisor snapshot.
VLAN support in a later release, maybe
That is an odd omission, that's pretty easy to do...
If your RHEV-M server goes down, auto-restart-VMS capability also goes down
A disappointing limitation, but do they at least support some sort of fail-over to have multiple HA RHEV-M instances?
No equivalent to storage vMotion
Not surprised, most people in KVM town misunderstand what storage vMotion specifically does, and the few instancesc when they learn, they tend to respond with a strange look along the lines of 'why would you care about that'. The thing is they have the harder case of storage and host at the same time (which at last check VMware didn't bother with), but not the presumably more straightforward case of just the storage backing.
now suddenly you wouldn't even need to change management tools or admin skillsets to migrate to the competitors' platform....
That's my point, already VMware is less a virtualization company and more a virtualization *management* company. The free hypervisors before and particularly the mantra that no VMware infrastructure is complete without vCenter make that plain enough. It also *seems* from an outsider's perspective that the people working ESXi half are a very different team than vCenter (they just seem very very differently minded, and I think I like some philosophies in ESXi that clearly aren't central to vCenter development).
Now this company faces a lot of threat, *particularly* in academic circles that inherently trend toward open solutions like Xen or KVM. One strategy would be to flow with the trend and allow those solutions to sit on the bare metal, but make those environments a possible opportunity for sales while also reducing the chances these environments evolve a management solution that displaces VMware at the top of the stack as well.
To be fair, some observers even inside China claim that wouldn't have much of an impact on anyone as that particular organization isn't paid attention to by anyone.
Keep in mind that increasingly, VMware is seeing the individual hypervisors as little more than an means to the end of selling their higher-order management software (vCenter and such). I would not be surprised if one day vCenter ends up managing Xen and/or KVM the same way it will manage ESXi.
(Disclaimer, though I don't work for the mentioned company, I do stand to benefit for business they conduct)
So, the *storage migration* feature (where backing store changes with nothing else changing) is not currently implemented as far as I know by anything other than VMware in x86 world (though perhaps the building blocks are there now in one way another). Other than that (live migration, DRS but with more flexible criteria, HA VM restart, and failure avoidance), Adaptive computing has an offering built on KVM. http://www.adaptivecomputing.com/products/moab-adaptive-computing-suite.php Their product pages are fairly vague and hard to get a feel for it (mainly because virtualization is a relatively small subset of the product), you kind of need a demo to get a whole picture. This is probably the most polished offering I've seen with my own eyes and touched with my own hands. They actually have quite a few customers using vCenter under the covers because they did some stuff above and beyond VMware with VMware's own products, and have all of it working for VMware and KVM except storage migration which is limited to VMware at the moment.
IBM also has at least two products with GUI, VMcontrol I've never used and LoadLeveller is starting to accept KVM VMs as workloads IIRC. IBM will also bundle the aforementioned Adaptive product bundled with hardware if you like.
I've heard some talk about OpenStack, but never seen it in action so I can't speak for or against it other than to say their goal ostensibly lies in this direction.
I've seen marketing material for RHEV-M which suggests a vCenter-like set of capabilities, but no hands on to *really* vouch for or against it. T
In general, the biggest thing to prepare yourself at the low level is a drop in I/O performance. virtio-blk and virtio-net mitigate it pretty well, but if you like using e1000 because you don't have to sweat Windows drivers in guests, the performance will be on the floor relative to VMware, for example (and KVM maintainers know and don't care).
For those who would choose not to carry insurance... That's a personal decision.
The problem is when a choice not to insure blows up in their face, if it gets so bad they cannot feed themselves or their family, they won't be good little serfs and die of starvation saying 'my bad', they will take whatever measures they can, and no, there aren't enough living-wage earning jobs to go around right now to readily give everyone legitimate means to securing enough stuff to eat without public assistance programs.
That's a personal decision. For most motivated people with marketable skills, not paying unemployment tax or an unemployment insurance premium allows them to save their "oh crap" fund at a greater rate (that's right where the money I am currently forced to pay into unemployment would go, if I were not forced)
See, a 'oh crap' fund with only what *would* be your contribution to unemployment premiums would be burnt through in very short order. The whole insurance industry works on the principle of averages, and on average you pay more than you get, but when you actually need it, you'll generally get more than you paid in.
Those who don't save, well they surely have friends who might take them in and spaghetti and ketchup don't cost much so they won't starve.
See, I think this is unfair. If I am willing to part with some of my money to keep someone from getting too desperate, but my neighbor with equal ability to do so opts not too, then my goodwill costs me about twice as much and both myself and my neighbor benefit equally. This is the essential issue of resolving communal issues that private industry does not do so well. Most individual problems can be well served by private industry, but when it comes to the point where a person must part with money for an indirect (where it seems only someone *other* than you benefits at first glance) and/or intangible benefit, it's not going to pan out so well.
that would be me excersizing my own personal freedom and right to be safe in my person and posessions.
Except when you're not home, in which case you want deterrence through increased police patrols if the crime rate does go up. After the fact, you need more police resources to try to get back what was rightfully yours. If you are home and your ITG plan fails you and you get killed, then you certainly can't be the one to try to enforce the law to punish the perpetrator. Those resources are a shared community burden. Sometimes it cannot just be about how alert and how many bullets you got for your gun, and you can't pretend that a problem is *always* an individual problem and never a societal/communal problem.
Unemployment insurance could become a private industry. Charitable donations may increase.
Allowing people to *optionally* carry insurance is generally a high risk, because many will opt out and the potential costs associated with opting out to society are frequently much higher than being certain that it is infeasible for someone *not* to be covered. This is even assuming private unemployment insurance won't come up with a ton of rationalizing to rarely pay out benefits.
I find that a moral justification isn't going to carry weight with people advocating throwing those on welfare and unemployment under the bus, as moral implications one way or the other are obvious.
I would picture cowering as a bit more than relenting to spend just enough to keep some of the population not quite desperate enough to destabilize your society. It is a practical argument, that the costs associated with law enforcement incurred by a 'no handout' philosophy will be higher than tolerating some welfare and unemployment (and the latter also *looks* much better).
Because: -Your day-to-day house energy usage doesn't involve accelerating a ton of mass to 60-70 mph repeatedly -As a corollary, your house is not having to constantly spend energy to fight air resistance to maintain a high velocity -Your car is poorly insulated with very large windows meaning the reduced volume of air to climate control is offset by the inefficiencies of dealing with thermal and light energy outside the car (even on pretty hot days, your house A/C generally gets to cut off a lot, in a car, that compressor generally has to run constantly on moderately hot days to maintain the same comfort).
Though 24kWh lasting two days still seems *very* optimistic. lights and refrigerator only would be my guess, and you probably would want to leave that fridge closed as much as possible. A/C might be ok so lang as not overly aggressive (might get 5-8 hours of runtime to spread out across the two days).
I know this is a troll, but I fear some people actually think that cold-turkey entitlement cutoff makes sense.
If you yank the support out from under such a large portion of the population who *cannot* realistically find work right now (and even if they can find work with non-living wages), you make a lot of people very desperate. Out of this desperation at best you will have higher crime rate as people resort to whatever means possible to keep themselves fed and sheltered. On the worse end of the scale of possibilities, the internet tough guy lynch mobs for the rich become real. This is why the rich and comfortable should not begrudge welfare and similar things, they are the things pacifying the poor to stave off more risky behavior. Police forces will need more money and those not on welfare would incur higher risk. This is also why the wealthy should be all about tax hikes if the government situation seems sufficiently dire to threaten those programs, it would be far cheaper than the alternative.
Foreign aid is a little less absolute, but similar principles apply. If *no one* helps then violence bred by desperation is likely to threaten our resources, our travelers, whatever these nations can get at to extract resources from wealthy nations. You think no one should 'steal' from one and give to another, but without foreign aid there is a chance the afflicted nation will endeavor to steal with no regard for the welfare of the victims. At that point you'd gain the perspective that calling foreign aid spending 'theft' is really inaccurate. Scaling things back I could see, but I think that foreign aid is a small piece of the pie.
I also agree that our military is overextended and measures must be taken to scale back our presence, but being all or nothing stands to seriously destabilize some places absolutely dependent upon our presence.
It is not infrequent that I find myself scheduling/monitoring the reboot of thousands of servers on the other side of the globe. I don't support crap hardware, so I'm not going to be sweating having to be there in person, even if I don't have on-duty local technicians. I do get a bit less ambitious in scale when dealing with sensitive services, but I still do the stuff remotely, just take longer to roll the reboot over the servers.
Incidentally, I rarely support Windows, these are mostly Linux configurations.
So lazily written applications are not salvaged by spending gobs on money on Oracle database licensing... Nothing new. I don't consider this evidence that server uptime is a scared cow, I consider it to be a testament to how Oracle databse configurations are overpriced and falsely get attributed as the most rock solid base to build upon.
The point is simple, getting rid of reboots due to updates doesn't get rid of the other many scenarios where a system may reboot, go down, or even just an application crash. Ergo, if you dread a server rebioot, the hosted applications are doing it wrong.
Ok, yes, the MS system is technically less capable (and frustratingly so, since something like lsof is baked in and sometimes you have something as trivial as a config file to deal with).
The subsequent *behavior* is not necessarily a bad thing from a practical perspective. If you play things just right, and deal with your system the right way, you might be able to restart the bare minimum stuff around a library update by leveraging the features in a Linux environment to their fullest. It is about 1000 times more likely that you'll not keep good track of that and omit things, resulting sometimes in stale libraries, or, as another person mentions, a time bomb if an update opens the existing inode for rewrite instead of unlink, then write (I've seen some things do this, presumably in the hopes of making the new code effective sooner, but almost always with the result of a segfaulting process for reasons beyond my understanding).
For reasons already stated, one physical server should have/comprise a 'critical service'. Even if your update mechanisms achieve perfect continuity, there are so many things *impossible* to avoid that will one day take that down.
The problem I have with kSplice is it is a solution to a problem that most everyone stopped caring about years ago. People with real work to do stopped treating the output of uptime as a sacred cow and started putting the resiliency at the application layer in multi-server environments. Relatively low outage of a component for scheduled maintenance is nice, but reducing that to zero is well beyond the point of diminishing returns since the app better not care if that server goes down anyway (or else for all your efforts an uncorrectable ECC error will come and just ruin your day).
It's been a while since I read up on it, but if I recall it worked kind of like a rehook of system calls as the opportunity arises. This means you don't have a particularly strong assurance that a security or bug fix actually is in effect for all running instance of an application, and it also limited the sorts of updates that could go in. It's kind of like how you could update glibc without explicitly restarting any daemons, but you won't actually see the benefit of that update until you actually take the hit to let the application exit and restart to induce load of the better code into ram.
Hate to admit it, as much as MS got made fun of for rebooting after every update, it really is the way to go in a practical perspective if you don't want to be bitten by some kernel/glibc vulnerability even after you *think* you've updated.
I know a handful of 'oh hell no I'm not doing facebook' people (I'm one of them). They want meticulous control over how they communicate and with whom they communicate, and that flies in the face of the whole point of facebook. I understand this. I understand you can be meticulous and all that with facebook in theory, but then I see no benefit to using Facebook at all over other forms of communication, so why bother.
What I don't get is why about half of the people I know who have consistently said this about facebook have started pestering me to join Google+. How the hell does Google get people to make an about face like that?
Sure, implementing standards in *theory* should mean the browser choice doesn't matter. The problem is the difference between theory and practice. You think you write in standards, but you only validate that in one browser, you may accidentally not be standards compliant. Conversely, you may fairly be totally standards compliant, but a browser defect results in your site not behaving correctly. Or a standard could be sufficiently vague as to have multiple implementations vary in behavior without being able to point at any particular one as non-compliant.
All this is ignoring that things like browser crashes, memory exhaustion, and security issues are critical issues to worry about that generally have no bearing on standards compliance.
If standards meant the choice and version of a browser wouldn't matter, then why would there be a choice of browser and version in the first place?
In projects that have stable branches actively maintained, developers tend to do a good job of discipline in not doing large changes. When they do have a large, potentially long term change to enact, they push it to a branch with 5-6 months of time to release, and maybe push minor feature additions to a minor feature release.
Now firefox has dispensed with all that and all major features, minor features, and bugfixes/security issues into a single cycle. That release cycle is sufficiently short such that major tweaks will inevitably destabilize a 'release', and generally every release will have one or two major changes that *should* undergo a few months of being restricted to the adventurous before being spewed out to the masses.
Linux gets a pass simply because organizations like Debian, RH, Novell, and Canonical designate maintenance branches (with varying degrees of restraint in backporting risky things).
So I've made uclibc based installs and suffer from 'glibc'-isms, so I do take the point that in some crowds 'Linux' does still specifically refer to kernel.
However, I still fail to see the relevance of any of Adobe's Android specific work being credibly associated with 'Linux'. If they had some noise around libva and friends, ok, but I don't see Adobe-level work on Android as being relevant at all to non-Android use of Linux.
This is just delusional. The part where he compares the launch to OSX launch was particularly goofy. It pretends that WebOS is a platform that *hasn't* had over two years in the open market to mature. Comparing OSX launch (completely different OS than previously released by Apple) to a tablet launch using an OS that has had a comparatively long time to work out the kinks is just sad. Further complicating things is they showed this thing off nearly 6 months ago in pretty much the same state as it was at launch. With all the intervening time, they didn't seem to complete these evidently 'trivial' fixes.
This also overlooks another major sore spot for the reviews. Even the most favorable expressed disappointment in the dimensions and particularly the weight. Most noted the fact that HP seemed to be chasing the iPad 1 size and weight, though with a considerable bump in hardware performance.
The application space seems unfortunately sparse. They indicated a number of key partners at their announcement in February that didn't seem to actually show up. Netflix being a notable example. They have had an incredible homebrew community that can churn stuff out quickly (probably due in no small part to the ease of Linux SDL code for the desktop being ported to the phone), but it just hasn't been enough. I'm reminded of early on when a very select set of software producers took a leap of faith and released WebOS software on Pre launch, only to abandon it when the market reality set in.
The marketing message is also a bit confused. The Veer keeps saying 'small phone because you want a tablet and why would you want a big phone', but at the same time all their demos and discussions focus around their unreleased 'big phone' Pre 3 as the optimal companion to their tablet.
I may be a bit bitter over the fact that HP seems to have neglected their phone product launch efforts trying to chase this tablet market, and I personally don't want any tablet and might have been interested if they got a Pre3 in my hands in a reasonable time frame instead. Rubbing salt in the wound, the announcement of 'making things right' for early adopters that were told the software upgrades would go further than they did would be $50 off the higher priced tablets seemed to emphasize just how much they are thinking tablets above phones.
So if you get pedantic, sure, 'Linux' means/meant the kernel and only the kernel.
In *practice*, Linux has come to describe the distributions that all use glibc, xorg, kernel, gtk, qt, etc. As far as application developers go, the kernel underneath it all is interacted with rarely if at all. Adobe in *particular* has no reason to be making Linux *kernel* specific calls, so it *is* disingenuous to hold up Android work as their 'Linux' support. Adobe hasn't done anything to support the specific kernel of any other platform, so trying to say 'Linux means kernel, so Adobe is fine to say that' is just not right.
In truth, the *closest* to a mainstream 'Linux' has been WebOS, but it's fringe and skips the Xorg/GTK/QT part of the equation (though they do use SDL).
So at the low level, there is SDL, at the high layer, QT or GTK. In terms of the middle ground, how does Cairo compare with Quartz? We are talking capability, not compatibility. If you want to recompile existing OSX or Windows projects, that's different (with GNUstep and libwine respectively coming the closest, but very very far from production ready, though at least EVE online thought libwine was sufficient).
To second, binaries are quite workable, but claiming support for 'Linux' may be more complicated than supporting, say 'Ubuntu and/or Fedora'. Some people may bemoan the multi-distro situation, but covering RHEL and Ubuntu largely covers your bases. I occasionally do have reason to execute ancient Linux binaries still, and they generally are passable still. Do you ruffle the feathers of Slackware and/or OpenSuSE and/or Gentoo? Perhaps, but the share is small and they can reasonably take care of themselves if the work has been done to assure RHEL and Ubuntu functionality.
Slashdot Mirror
But it didn't break its promises.
I can read countless stories of people who use things like EC2 and express disdain toward users afflicted by downtime because they didn't understand how to work it. When all is said and done, the users using EC2 'right' seem to end up having to worry all the frustrating details of HA they worried about before, 'Cloud' doesn't change that. The 'promise' is that you naively slap your workload into a 'cloud' provider and you don't have to think so hard about all of that. Even if Amazon doesn't explicitly make that promise, they certainly benefit from the general buzz along those lines and don't do a whole lot to quell that impression with non-technical decision managers.
Now you may say people who naively do that are overvaluing the 'cloud', and while that may be true, one has to seriously wonder what the value of 'cloud' is. I would say a large population of companies 'doing it right' end up spending the money to 'rent' computing power and then end up having to keep on their IT staff anyway and end up saving nothing or spending more.
*Particularly* initiatives like the US government 'moving to the cloud' needs to keep in mind they can't just ditch all those IT experts, and with that in mind, do you still achieve meaningful savings?
The open source web mail interfaces are not even close to what gmail does.
On this point I have to disagree. gmaill is highly capable and all, but I actually prefer roundcube's interface over gmail's.
I also disagree that maintaining a mail server competently is that hard for a single domain with maybe a half-dozen users. If you stick to packages provided by a linux distribution, distribution updates will handle most security updates. Many ISPs have blessed relays for your use that alleviates the blacklist problem significantly.
That said, I have co confess current state of gmail makes it hard to find reason to do it yourself. The only reason I could think of is fear for what google could do in the future given the fact they really can hold your email address hostage. If you pay for your own domain (using any subdomain like offered by dyndns or co.cc is begging for them to hold your domain hostage down the road (as dyndns already has done to its users), landing you in the same place. Since so many free offerings from other companies have either evaporated or 'altered' in unacceptable ways, it's not unreasonable to be wary of Google's take on the perceived business value of free email with ads. If data suggests the cost is higher than the revenue sometime later, say goodbye to your email.
Just to add, the interface can be abstracted from the email storage.
Currently, I have both roundcube and squirrelmail exposing my imap mailboxes. I tend to use roundcube, but other users tend to use squirrelmail. There are some capabilities in squirrelmail not in roundcube.
Last I checked, You have to shutdown a VM to take a snapshot.
Odd, the underlying stuff is agnostic, though a shutdown is a good idea in lieu of something like vmware guest utils to coordinate disk activity with the hypervisor snapshot.
VLAN support in a later release, maybe
That is an odd omission, that's pretty easy to do...
If your RHEV-M server goes down, auto-restart-VMS capability also goes down
A disappointing limitation, but do they at least support some sort of fail-over to have multiple HA RHEV-M instances?
No equivalent to storage vMotion
Not surprised, most people in KVM town misunderstand what storage vMotion specifically does, and the few instancesc when they learn, they tend to respond with a strange look along the lines of 'why would you care about that'. The thing is they have the harder case of storage and host at the same time (which at last check VMware didn't bother with), but not the presumably more straightforward case of just the storage backing.
now suddenly you wouldn't even need to change management tools or admin skillsets to migrate to the competitors' platform....
That's my point, already VMware is less a virtualization company and more a virtualization *management* company. The free hypervisors before and particularly the mantra that no VMware infrastructure is complete without vCenter make that plain enough. It also *seems* from an outsider's perspective that the people working ESXi half are a very different team than vCenter (they just seem very very differently minded, and I think I like some philosophies in ESXi that clearly aren't central to vCenter development).
Now this company faces a lot of threat, *particularly* in academic circles that inherently trend toward open solutions like Xen or KVM. One strategy would be to flow with the trend and allow those solutions to sit on the bare metal, but make those environments a possible opportunity for sales while also reducing the chances these environments evolve a management solution that displaces VMware at the top of the stack as well.
To be fair, some observers even inside China claim that wouldn't have much of an impact on anyone as that particular organization isn't paid attention to by anyone.
Keep in mind that increasingly, VMware is seeing the individual hypervisors as little more than an means to the end of selling their higher-order management software (vCenter and such). I would not be surprised if one day vCenter ends up managing Xen and/or KVM the same way it will manage ESXi.
(Disclaimer, though I don't work for the mentioned company, I do stand to benefit for business they conduct)
So, the *storage migration* feature (where backing store changes with nothing else changing) is not currently implemented as far as I know by anything other than VMware in x86 world (though perhaps the building blocks are there now in one way another). Other than that (live migration, DRS but with more flexible criteria, HA VM restart, and failure avoidance), Adaptive computing has an offering built on KVM. http://www.adaptivecomputing.com/products/moab-adaptive-computing-suite.php Their product pages are fairly vague and hard to get a feel for it (mainly because virtualization is a relatively small subset of the product), you kind of need a demo to get a whole picture. This is probably the most polished offering I've seen with my own eyes and touched with my own hands. They actually have quite a few customers using vCenter under the covers because they did some stuff above and beyond VMware with VMware's own products, and have all of it working for VMware and KVM except storage migration which is limited to VMware at the moment.
IBM also has at least two products with GUI, VMcontrol I've never used and LoadLeveller is starting to accept KVM VMs as workloads IIRC. IBM will also bundle the aforementioned Adaptive product bundled with hardware if you like.
I've heard some talk about OpenStack, but never seen it in action so I can't speak for or against it other than to say their goal ostensibly lies in this direction.
I've seen marketing material for RHEV-M which suggests a vCenter-like set of capabilities, but no hands on to *really* vouch for or against it. T
In general, the biggest thing to prepare yourself at the low level is a drop in I/O performance. virtio-blk and virtio-net mitigate it pretty well, but if you like using e1000 because you don't have to sweat Windows drivers in guests, the performance will be on the floor relative to VMware, for example (and KVM maintainers know and don't care).
For those who would choose not to carry insurance... That's a personal decision.
The problem is when a choice not to insure blows up in their face, if it gets so bad they cannot feed themselves or their family, they won't be good little serfs and die of starvation saying 'my bad', they will take whatever measures they can, and no, there aren't enough living-wage earning jobs to go around right now to readily give everyone legitimate means to securing enough stuff to eat without public assistance programs.
That's a personal decision. For most motivated people with marketable skills, not paying unemployment tax or an unemployment insurance premium allows them to save their "oh crap" fund at a greater rate (that's right where the money I am currently forced to pay into unemployment would go, if I were not forced)
See, a 'oh crap' fund with only what *would* be your contribution to unemployment premiums would be burnt through in very short order. The whole insurance industry works on the principle of averages, and on average you pay more than you get, but when you actually need it, you'll generally get more than you paid in.
Those who don't save, well they surely have friends who might take them in and spaghetti and ketchup don't cost much so they won't starve.
See, I think this is unfair. If I am willing to part with some of my money to keep someone from getting too desperate, but my neighbor with equal ability to do so opts not too, then my goodwill costs me about twice as much and both myself and my neighbor benefit equally. This is the essential issue of resolving communal issues that private industry does not do so well. Most individual problems can be well served by private industry, but when it comes to the point where a person must part with money for an indirect (where it seems only someone *other* than you benefits at first glance) and/or intangible benefit, it's not going to pan out so well.
that would be me excersizing my own personal freedom and right to be safe in my person and posessions.
Except when you're not home, in which case you want deterrence through increased police patrols if the crime rate does go up. After the fact, you need more police resources to try to get back what was rightfully yours. If you are home and your ITG plan fails you and you get killed, then you certainly can't be the one to try to enforce the law to punish the perpetrator. Those resources are a shared community burden. Sometimes it cannot just be about how alert and how many bullets you got for your gun, and you can't pretend that a problem is *always* an individual problem and never a societal/communal problem.
Unemployment insurance could become a private industry. Charitable donations may increase.
Allowing people to *optionally* carry insurance is generally a high risk, because many will opt out and the potential costs associated with opting out to society are frequently much higher than being certain that it is infeasible for someone *not* to be covered. This is even assuming private unemployment insurance won't come up with a ton of rationalizing to rarely pay out benefits.
I find that a moral justification isn't going to carry weight with people advocating throwing those on welfare and unemployment under the bus, as moral implications one way or the other are obvious.
I would picture cowering as a bit more than relenting to spend just enough to keep some of the population not quite desperate enough to destabilize your society. It is a practical argument, that the costs associated with law enforcement incurred by a 'no handout' philosophy will be higher than tolerating some welfare and unemployment (and the latter also *looks* much better).
Because:
-Your day-to-day house energy usage doesn't involve accelerating a ton of mass to 60-70 mph repeatedly
-As a corollary, your house is not having to constantly spend energy to fight air resistance to maintain a high velocity
-Your car is poorly insulated with very large windows meaning the reduced volume of air to climate control is offset by the inefficiencies of dealing with thermal and light energy outside the car (even on pretty hot days, your house A/C generally gets to cut off a lot, in a car, that compressor generally has to run constantly on moderately hot days to maintain the same comfort).
Though 24kWh lasting two days still seems *very* optimistic. lights and refrigerator only would be my guess, and you probably would want to leave that fridge closed as much as possible. A/C might be ok so lang as not overly aggressive (might get 5-8 hours of runtime to spread out across the two days).
I know this is a troll, but I fear some people actually think that cold-turkey entitlement cutoff makes sense.
If you yank the support out from under such a large portion of the population who *cannot* realistically find work right now (and even if they can find work with non-living wages), you make a lot of people very desperate. Out of this desperation at best you will have higher crime rate as people resort to whatever means possible to keep themselves fed and sheltered. On the worse end of the scale of possibilities, the internet tough guy lynch mobs for the rich become real. This is why the rich and comfortable should not begrudge welfare and similar things, they are the things pacifying the poor to stave off more risky behavior. Police forces will need more money and those not on welfare would incur higher risk. This is also why the wealthy should be all about tax hikes if the government situation seems sufficiently dire to threaten those programs, it would be far cheaper than the alternative.
Foreign aid is a little less absolute, but similar principles apply. If *no one* helps then violence bred by desperation is likely to threaten our resources, our travelers, whatever these nations can get at to extract resources from wealthy nations. You think no one should 'steal' from one and give to another, but without foreign aid there is a chance the afflicted nation will endeavor to steal with no regard for the welfare of the victims. At that point you'd gain the perspective that calling foreign aid spending 'theft' is really inaccurate. Scaling things back I could see, but I think that foreign aid is a small piece of the pie.
I also agree that our military is overextended and measures must be taken to scale back our presence, but being all or nothing stands to seriously destabilize some places absolutely dependent upon our presence.
It is not infrequent that I find myself scheduling/monitoring the reboot of thousands of servers on the other side of the globe. I don't support crap hardware, so I'm not going to be sweating having to be there in person, even if I don't have on-duty local technicians. I do get a bit less ambitious in scale when dealing with sensitive services, but I still do the stuff remotely, just take longer to roll the reboot over the servers.
Incidentally, I rarely support Windows, these are mostly Linux configurations.
So lazily written applications are not salvaged by spending gobs on money on Oracle database licensing... Nothing new. I don't consider this evidence that server uptime is a scared cow, I consider it to be a testament to how Oracle databse configurations are overpriced and falsely get attributed as the most rock solid base to build upon.
The point is simple, getting rid of reboots due to updates doesn't get rid of the other many scenarios where a system may reboot, go down, or even just an application crash. Ergo, if you dread a server rebioot, the hosted applications are doing it wrong.
Ok, yes, the MS system is technically less capable (and frustratingly so, since something like lsof is baked in and sometimes you have something as trivial as a config file to deal with).
The subsequent *behavior* is not necessarily a bad thing from a practical perspective. If you play things just right, and deal with your system the right way, you might be able to restart the bare minimum stuff around a library update by leveraging the features in a Linux environment to their fullest. It is about 1000 times more likely that you'll not keep good track of that and omit things, resulting sometimes in stale libraries, or, as another person mentions, a time bomb if an update opens the existing inode for rewrite instead of unlink, then write (I've seen some things do this, presumably in the hopes of making the new code effective sooner, but almost always with the result of a segfaulting process for reasons beyond my understanding).
For reasons already stated, one physical server should have/comprise a 'critical service'. Even if your update mechanisms achieve perfect continuity, there are so many things *impossible* to avoid that will one day take that down.
The problem I have with kSplice is it is a solution to a problem that most everyone stopped caring about years ago. People with real work to do stopped treating the output of uptime as a sacred cow and started putting the resiliency at the application layer in multi-server environments. Relatively low outage of a component for scheduled maintenance is nice, but reducing that to zero is well beyond the point of diminishing returns since the app better not care if that server goes down anyway (or else for all your efforts an uncorrectable ECC error will come and just ruin your day).
It's been a while since I read up on it, but if I recall it worked kind of like a rehook of system calls as the opportunity arises. This means you don't have a particularly strong assurance that a security or bug fix actually is in effect for all running instance of an application, and it also limited the sorts of updates that could go in. It's kind of like how you could update glibc without explicitly restarting any daemons, but you won't actually see the benefit of that update until you actually take the hit to let the application exit and restart to induce load of the better code into ram.
Hate to admit it, as much as MS got made fun of for rebooting after every update, it really is the way to go in a practical perspective if you don't want to be bitten by some kernel/glibc vulnerability even after you *think* you've updated.
I know a handful of 'oh hell no I'm not doing facebook' people (I'm one of them). They want meticulous control over how they communicate and with whom they communicate, and that flies in the face of the whole point of facebook. I understand this. I understand you can be meticulous and all that with facebook in theory, but then I see no benefit to using Facebook at all over other forms of communication, so why bother.
What I don't get is why about half of the people I know who have consistently said this about facebook have started pestering me to join Google+. How the hell does Google get people to make an about face like that?
Hulu+ is same price as Netflix, *and* wastes your time by making you watch commercials....
Sure, implementing standards in *theory* should mean the browser choice doesn't matter. The problem is the difference between theory and practice. You think you write in standards, but you only validate that in one browser, you may accidentally not be standards compliant. Conversely, you may fairly be totally standards compliant, but a browser defect results in your site not behaving correctly. Or a standard could be sufficiently vague as to have multiple implementations vary in behavior without being able to point at any particular one as non-compliant.
All this is ignoring that things like browser crashes, memory exhaustion, and security issues are critical issues to worry about that generally have no bearing on standards compliance.
If standards meant the choice and version of a browser wouldn't matter, then why would there be a choice of browser and version in the first place?
In projects that have stable branches actively maintained, developers tend to do a good job of discipline in not doing large changes. When they do have a large, potentially long term change to enact, they push it to a branch with 5-6 months of time to release, and maybe push minor feature additions to a minor feature release.
Now firefox has dispensed with all that and all major features, minor features, and bugfixes/security issues into a single cycle. That release cycle is sufficiently short such that major tweaks will inevitably destabilize a 'release', and generally every release will have one or two major changes that *should* undergo a few months of being restricted to the adventurous before being spewed out to the masses.
Linux gets a pass simply because organizations like Debian, RH, Novell, and Canonical designate maintenance branches (with varying degrees of restraint in backporting risky things).
So I've made uclibc based installs and suffer from 'glibc'-isms, so I do take the point that in some crowds 'Linux' does still specifically refer to kernel.
However, I still fail to see the relevance of any of Adobe's Android specific work being credibly associated with 'Linux'. If they had some noise around libva and friends, ok, but I don't see Adobe-level work on Android as being relevant at all to non-Android use of Linux.
This is just delusional. The part where he compares the launch to OSX launch was particularly goofy. It pretends that WebOS is a platform that *hasn't* had over two years in the open market to mature. Comparing OSX launch (completely different OS than previously released by Apple) to a tablet launch using an OS that has had a comparatively long time to work out the kinks is just sad. Further complicating things is they showed this thing off nearly 6 months ago in pretty much the same state as it was at launch. With all the intervening time, they didn't seem to complete these evidently 'trivial' fixes.
This also overlooks another major sore spot for the reviews. Even the most favorable expressed disappointment in the dimensions and particularly the weight. Most noted the fact that HP seemed to be chasing the iPad 1 size and weight, though with a considerable bump in hardware performance.
The application space seems unfortunately sparse. They indicated a number of key partners at their announcement in February that didn't seem to actually show up. Netflix being a notable example. They have had an incredible homebrew community that can churn stuff out quickly (probably due in no small part to the ease of Linux SDL code for the desktop being ported to the phone), but it just hasn't been enough. I'm reminded of early on when a very select set of software producers took a leap of faith and released WebOS software on Pre launch, only to abandon it when the market reality set in.
The marketing message is also a bit confused. The Veer keeps saying 'small phone because you want a tablet and why would you want a big phone', but at the same time all their demos and discussions focus around their unreleased 'big phone' Pre 3 as the optimal companion to their tablet.
I may be a bit bitter over the fact that HP seems to have neglected their phone product launch efforts trying to chase this tablet market, and I personally don't want any tablet and might have been interested if they got a Pre3 in my hands in a reasonable time frame instead. Rubbing salt in the wound, the announcement of 'making things right' for early adopters that were told the software upgrades would go further than they did would be $50 off the higher priced tablets seemed to emphasize just how much they are thinking tablets above phones.
So if you get pedantic, sure, 'Linux' means/meant the kernel and only the kernel.
In *practice*, Linux has come to describe the distributions that all use glibc, xorg, kernel, gtk, qt, etc. As far as application developers go, the kernel underneath it all is interacted with rarely if at all. Adobe in *particular* has no reason to be making Linux *kernel* specific calls, so it *is* disingenuous to hold up Android work as their 'Linux' support. Adobe hasn't done anything to support the specific kernel of any other platform, so trying to say 'Linux means kernel, so Adobe is fine to say that' is just not right.
In truth, the *closest* to a mainstream 'Linux' has been WebOS, but it's fringe and skips the Xorg/GTK/QT part of the equation (though they do use SDL).
So at the low level, there is SDL, at the high layer, QT or GTK. In terms of the middle ground, how does Cairo compare with Quartz? We are talking capability, not compatibility. If you want to recompile existing OSX or Windows projects, that's different (with GNUstep and libwine respectively coming the closest, but very very far from production ready, though at least EVE online thought libwine was sufficient).
To second, binaries are quite workable, but claiming support for 'Linux' may be more complicated than supporting, say 'Ubuntu and/or Fedora'. Some people may bemoan the multi-distro situation, but covering RHEL and Ubuntu largely covers your bases. I occasionally do have reason to execute ancient Linux binaries still, and they generally are passable still. Do you ruffle the feathers of Slackware and/or OpenSuSE and/or Gentoo? Perhaps, but the share is small and they can reasonably take care of themselves if the work has been done to assure RHEL and Ubuntu functionality.