I think the iOS team is facing a tough (and interesting) problem. They need to keep the edge they have in terms of app quantity and specially quality, so introducing big changes that break or degrade how apps look or behave and require big changes by developers can jeopardize their advantage.
On the other hand change in unavoidable. They cannot stop in time. Each iOS version that gets released with minimal changes is another catch up that will need to take place in a later version. The more changes are delayed the bigger they get. Android and even Windows Phone are moving forward and so needs Apple.
I think that there can be a certain feeling inside Apple that is not exactly change aversion but maybe is something close. They got iPhone so right and had so much success with it that maybe there is some fear that introducing significant changes can mess things up...
It also works for some commands even if you never run them before. For instance curl --i<nsecure> (and I never ran curl --insecure). Also pressing tab will display all curl flags starting with i and a one line description from the man page. Pretty neat.
"But 4x less CPU."
You are seriously naive if you think the number of logical cores the hypervisor presents to your VM is the sole determiner of CPU execution resources.
Here is a counter example, imagine I have two VM host servers with 16 logical cores. On one I could pin each VM to 1 logical core, on the other I could run 300 VMs and give each VM 24 logical cores... The first one is going to perform much better.
Also some hypervisors (for example VMware) only executes a VM when they have as many cores as the VM has cores available for execution. So having many logical cores in your VM can negatively influence CPU scheduling.
He's not naive; you're being overly cynical. This is like pointing out that an SSD could technically be programmed to work much more slowly than a 5200 RPM drive and thus be a worse value than Linode's spinning platters — unless you have a reasonable belief that somebody is actually doing that, it's just FUD.
Based on the benchmarks I've seen, it appears that Linode really does give the kind of concurrency you'd expect from four cores (i.e. if your problem is parallelizable, you can scale up on Linode better than Digital Ocean, whereas Digital Ocean will work much better if your program is serial and needs to hit the disk a lot).
Actually, hypervisor details aside, 8 VCPUs fully pegged at 100% user or system time will consume 4x the capacity of 2 VCPUs fully pegged at 100% user or system time in a domU, assuming comparable chips. Always and regardless of how Xen schedules the VCPUs onto actual nodes.
Your hand-waving about the hypervisor is unwarranted, since hypervisor interference under Xen shows up as its own time from the perspective of the domU (steal%) and nobody worth mentioning actually does hosting with VMware.
You don't know if the first one will perform better or not. It depends on the workload of each VM. If most of the VMs are idle most of the time, when one of them needs CPU the second setup may even perform better.
And I doubt that Linode runs more VMs per host than DO. Judging by the pricing is probably the other way around.
> Also some hypervisors (for example VMware) only executes a VM when they have as many cores as the VM has cores available for execution. So having many logical cores in your VM can negatively influence CPU scheduling.
Good thing Linode and DigitalOcean don't use VMware.
No. Just because you get 8 vCPU on Linode does not mean you have 4x the CPU. You share those 8 vCPU with dozens or hundreds of other servers (depending on VM size). More small slices of a pie that is the same size, is not really more.
On Linode it is never hundreds. "On average, a Linode 512 host has 40 Linodes on it. A Linode 1024 host has on average 20. Linode 2048 host: 10 Linodes; Linode 4096 host: 5;"
On the other hand as far as I know DO don't tell how many VMs share a host.
I too tried moving to DigitalOcean because their offering seemed very compelling. Turned out to be a huge mistake.
After waiting some weeks for Arch to be re-released I finally booted an Arch image. Not a week had passed and some kernel upgrade had already made the system unavailable (no network on vm). I forced nothing, just ran sudo pacman -Syu as I always did on Linode.
Support didn't care. For days I tried responding to the ticket that I opened, talking to them on the irc, via mail. Nothing. I tried to request help to at least recover the files. Nope, nothing they can do.
I did not understand the true value of good support. Now I do. Back to Linode.
They provide virtual hardware, how is it their if fault you can't manage your software using of it? I'm glad I use Debian/Ubuntu. It also sounds like you never took a backup snapshot.
For two reasons: First they created a "supported" image that had no IgnorePkg = linux as it should since they don't support upgrading the kernel. They did this on their Ubuntu image. They failed to it with the Arch image. Second, you have no access to the kernel that is used to boot the system. Even after upgrading system kept booting the old kernel but network was still down. Nothing a user can do at this point.
You can access a recovery image on linode I'm guessing there is no such thing available for Digital Ocean is why he was asking for help in recovering files (even prgmr offers a recover images that you can use to recover files).
The fact that he didn't get any help is a problem that is what support is supposed to do and if he expects a higher level of support than Digital Ocean provides and Linode provides that I see no problem.
I wasn't talking about backups I was talking about a Recovery option which allows you to boot into linux and mount your existing virtual drives to extract data or fix errors/look at logs.
Hmm, I still don't follow you. Does Linode have this? After moving I haven't found any difference in features. Perhaps I just wasn't using this on Linode? What does it let you do that restoring from a backup can't?
(The use case in this thread is backups as voidlogic mentioned.)
The use case I gave was looking up logs to see how something failed and to access files that aren't backed up but still exist on the virtual drive (this can happen when the OS fails to boot). You can also repair the virtual install if you accidentally messed up a configuration file or something like that.
Well, Arch is not that good for a server because of this reason. I love it as a developer for a desktop system, but for server I'd definitely use Debian.
How is this Arch's fault? The user did the same thing he/she normally does on Linode. This is a case where the Linode ops really understand Arch and everything just works (the 'linux' package isn't installed on the image) but the provide the latest kernels. On DO I also originally ran into this issue but support never gave a clear reason as to why, from digging around it appears to be with the 8139cp/too kernel modules (they don't load). It seems like some kind of version issue but I haven't had the time to play around with this more.
The post is a bit confusing, though, because well before you get to the line that you quoted, the article states:
"And we’re upgrading all Linodes to 8 cores! Right now. As in all you need to do is reboot to double the computing power of your Linode. By the time the host refresh is completed the average Linode will be running on hardware that is less than 1 year old."
I, for one, thought that it was ready now after reading that. In fact, from the comments, it's clear that for some customers, this is in fact ready:
"BizzarTech: Rebooted my 1024 and moar cores!!! Thank you!!"
No, the move to new hardware and increase in the number of available cores is separate. If you reboot right now you'll get access to more of the 'cores' on the host system (though I suspect they're really just "threads" in Intel terminology). But you're still running on the older L5520 hardware.
RSS should not be a core functionality of a web browser but guess what should? Google Now... I like Google Now but why can't it be implemented as an extension? Does it really make sense to have Google services entangled with the browser? With sync it is at least possible to deploy your own server even if the option is hidden behind a flag (and google refuses to add an option in the UI). And then there is the new tab page with another search bar just some hundred pixels below the omnibar that has the same functionality. And a new launcher... When applications start implementing their own launchers it's usually a sign they are becoming bloated. Remember Nero (not so) SmartStart?
This a team of amazingly smart people who reinvented the browser so probably there are good reasons supporting these decisions and I'm not smart enough to understand them.
On the other hand change in unavoidable. They cannot stop in time. Each iOS version that gets released with minimal changes is another catch up that will need to take place in a later version. The more changes are delayed the bigger they get. Android and even Windows Phone are moving forward and so needs Apple.
I think that there can be a certain feeling inside Apple that is not exactly change aversion but maybe is something close. They got iPhone so right and had so much success with it that maybe there is some fear that introducing significant changes can mess things up...