I don't think this stuff is expected to go any faster. To be fair to microsoft, the frequency of updates is already pretty respectable (latency and quality on the other hand...). The rumors are that MS will start mixing in functional changes more. Of course this seems like a mistake, their competitors really aren't mixing it up much on the fundamental level anymore (Google churned pretty hard because they needed too, but Jelly Bean seems to have marked where they broke out the functcion).

Microsoft is only bested on the 'faster' (latency and frequency) front by Linux Desktop distros, and see how much that has made people in the wider market care. It's a shame because Android updates are pretty infrequent *and* get deployed extremely slowly. This means a great deal of mobile Chrome browsers continue to have SSL vulnerabilities, mitigated somewhat by most reputable servers having addressed it on their end. If MS was botching a security update that badly the community would be all over them. Though again, the wider market doesn't really care except to be pissed at having to deal with frequent update related interruptions (where again I think linux desktop distros seem to have the right balance of availability but not being so heavy handed).

I don't download that stuff, but as a netflix user who also has DVD rips and DVR recordings that I manage under XBMC, I can easily understand the appeal of having the content locally and in a form that can be integrated with media from other sources.

Netflix outages are frustrating. When it is up, sometimes I can't stream the best quality in real time. Sometimes the client has to be kicked in the head for no apparent reason to make it stream at all or stream the best reasonable quality. Any seeking takes a relatively long time, and won't seek with the same precision as xbmc will. It does an admirable job of a UI, but it's not my favorite. I wish the streaming service could be mated with third party applications better to allow more than just netflix's concepts of show organization and playback control to work with their content, as well as the ability to prebuffer the highest quality regardless of my current conditions. I also find it excessively wasteful if I feel like rewatching something and knowing it redownloads it every time, which is where I would like to jump to 'just buy the damn thing' were there a convenient legal option without DRM.

That all said, they still have a great deal better software experience than amazon prime...

I had pretty much given up all hopes of DRM-free video via legitimate channels, even as music is pretty much DRM-free exclusively.

I'm not getting my hopes too much, but like DRM-free music before it, I'll be very eager to give them my money instead of buying DVDs with it.

I'm however fully expecting like eBooks, the DRM-free selection will remain sad and pathetic.

As virtualization became 'cool', people said 'look how many instances you can cram on these gigantic boxes'. This quickly became 'how many instances am I going to lose if this goes down' or 'how many do I have to live migrate to service this thing?'. The cost advantages of scale with a larger box are quickly offset by practical issues. As such, if you need that much memory in a single system, those sort of boxes are still very valued (in-memory databases and some particular sorts of modeling for example). If the workload naturally fits into more nodes of smaller size, it frequently makes sense to opt for the higher node count. There is of course different break points depending on judgement calls, but most places seem to think of two sockets as about the sweet spot.

So you have a quad-core with hyperthreading.

But in general I agree with the sentiment. I do think comparing random whitebox with the big POWER boxes fails to capture the whole reality, but it's easy enough to note that alongside that random whitebox there are enterprise grade suppliers using the common architecture. A person able to slap together a whitebox x86 may not be as useful for business continuity on his own left to those decisions, but those same skillsets can be employed toward an enterprise solution while staying in the x86 family. POWER does not scale down yet, and that is one of IBM's missions. I'm skeptical they will succeed, but at least they acknowledge ecosystem as a key need.

It is a market segment that is seeing growth, and the hype machine has gone into overdrive under the assumption that anything that grows will grow indefinitely overtaking anything it conceivably could in its path.

The reality like all other times before is that it might get more adopted than it should before receding to the appropriate amount as it plateaus as the hype gets done. Thin clients have been around for ages even as the hype behind them has erupted and died out multiple times. They clearly have their role but it is clearly not the end-all, be-all that these companies bill it as.

The attack is more precise. Need to know precisely when to pop up the input form of interest. Sure this information could allow them to disambiguate the context so that a random memory change in a random app doesn't trigger a false positive. Of course the whole point was also to demonstrate how well they could do without any remotely suspicious permissions.

So in the OS side, at the very least it seems that an obvious indication of application focus change would go a long way toward making this seem not right.

On the application side, I think applications that are likely to get sensitive information should always display a consistent randomized watermark in their application. Let's say they make an 'always at the top' bar with two randomized words. With that, the sensitive input forms that try to be phished will look incorrect because the watermark suddenly changes.

Of course, that comes with its own headaches and negates some of the benefits of a VM architecture. Paravirtualized networking is however pretty adequate for most workloads.

It's not like you have to do VM *or* baremetal across the board anyway. Use what makes sense for the circumstance.

In my experience, KSM hasn't helped as much as it promised. It depends heavily upon the workloads. It also impacts memory performance. If things are such that KSM can be highly effective, then a container solution would probably be more prudent.

CPU throughput impact is nearly undetectable nowadays. Memory *capacity* can suffer (you have overhead of the hypervisor footprint), though memory *performance* can also be pretty much on par with bare metal memory.

On hard disks and networking, things get a bit more complicated. In the most naive way, what you describe is true, a huge loss for emulating devices. However paravirtualized network and disk is pretty common which brings it in the same ballpark as not being in a VM. But that ballpark is relatively large, you still suffer significantly in the IO department in x86 virtualization despite a lot of work to make that less the case.

Of course, VM doesn't always make sense. I have seen people make a hypervisor that ran a single VM that pretty much required all the resources of the hypervisor and no other VM could run. It was architected such that live migration was impossible. This sort of stupidity makes no sense, pissing away efficiency for no gains.

So to the extent this conversation does make sense (it is pretty nonsensical in a lot of areas), it refers to a phenomenon I find annoying as hell: application vendors bundle all their OS bits.

Before, if you wanted to run vendor X's software stack, you might have to mate it with a supported OS, but at least vendor X was *only* responsible for the code they produced. Now increasingly vendor X *only* releases an 'appliance and are in practice responsible for the full OS stack despite having no competency to be in that position'. Let's see the anatomy of a recent example of critical update, OpenSSL.

For the systems where the OS has applications installed on top, patches were ready to deploy pretty much immediately, within days of the problem. It was a relatively no-muss affair. Certificate regeneration was an unfortunate hoop to go through, but it's about as painless as it could have been given the circumstances.

For the 'appliances', some *still* do not even have an update for *Heartbleed* (and many more didn't bother with the other OpenSSL updates). Some have updates, but only in versions that also have functional changes in the application that are not desired, and the vendor refuses to backport the relatively simple library change. In many cases, applying an 'update' actually resembles a reinstall. Having to download a full copy of the new image and doing some 'migration' work to have data continuity.

Vendors have traded generally low amounts of effort in initial deployment for unmaintainable messes with respect to updates.

nVidia actually did sell it pretty well though. It wasn't in any way a better experience, but the brand name did actually carry the product as I recall.

It was one of the reasons that the relationship between Intel and nVidia went so far south, Intel made it impossible to have third party chipsets and nVidia lost some revenue opportunity. People rightly critical of the technical aspects were not the downfall of the product line, Intel locking down their platform was.

In short, this stuff *could* in theory fly. In practice, I don't think AMD has the brand strength. People still seem to look to nVidia as 'the go-to' brand more often than AMD in the PC component world.

Looks like someone didn't get the memo...

Don't worry, I can fix it. Just send me your bank account number and your social security number for verification...

The funny thing in your story is that the word that makes it narrow down the most is the pronoun 'she'. I would guess you either work for HP or IBM. Massive stock buybacks and continual layoffs is the modus operandi of most of the companies, but female ceos are a little bit more rare. Of course they do and say the exact same things so they could all probably replace their CEOs with chatbots that just always says 'buyback some more stock and layoff more people' and no one would notice.