Low maintenance partially because they are functionally very limited ( much of what the kernel and userspace can do is locked-out) and partially because the mission-critical stuff lives in seldom-updated firmware.

High availability... Given how often 'reboot your phone' or ' clear the app data' is given as advice?

I just don't see many parallels with server environments.

The partitions that get updating are completely separate from user data. This myth keeps spreading for some reason though...

The only time user data gets wiped is when unlocking the bootloader which is a very valid security feature in order to prevent bootkits and data theft. It gives big clear warnings to backup your data before doing so.

Mine Samsung S4 mini reboots by itself once in a few days. Hadn't bothered to catch the reasons. And it surely knows how to hang itself for half a minute when doing large app updates or otherwise IO-heavy operations.

A limited functionality device that services a specific purpose, if we were to take it to the world of the web, would be a webservice.

If you were having a problem with one of your puppet&co managed web servers on some cloud host, would you: a. perform root cause analysis. b. redeploy the entire machine because fuck it, you have your recipes or whatever and spinning up a new instance is a super cheap operation.

That's what I read into when I think about the grandparent.

"you have no way to even specify them and each application has to bundle them all..."

Yeah, I think you're confusing a dependency free heaven for a dependency mess.

/beingargumentative :)

By all conceivable notions, no.

My devices restart for system updates and that's pretty much it.

I'll eventually have to replace the hard disks - I have seen SCSI to CF and SCSI to SDCard adapters that may do the trick.

Pretty much every device out there has multiple known security holes and they're not getting updated.

What was your point exactly in that respect?

I think this snappy scheme of Ubuntu might actually be what Android should have had from the start. It seems like it work in the embedded space when you don't want a traditional package manager.

Just because a few phone vendors stop pushing out updates after a period of time after launching the phone doesn't mean that Android doesn't support it. This might have been a valid criticism about years ago. But one that should be aimed at vendors and not Android.

Regarding vendor support, Google launched an initiative called "Compatibility Program" which every vendor must now agree to. Part of the agreement means they are required to support OTA updates if they plan to use the Android OS.

https://source.android.com/compatibility/overview.html

So I don't know what you're basing this off of?

All of which could be fixed with something like Snappy where the OS component that is improved could be pulled OTA by the customer.

The meta discussion is that customer cannot do that because a handset maker has no way of reasoning about how changes to a component of the system will affect all handsets out there, and so new versions of android sit in all-or-nothing testing limbo at the handset QA lab.

I know for a fact (because I've created my own ROM) that Android's OTA system is fully capable of updating single components. And the update the user downloads is not the entire ~200mb Android ROM, it could be a small 1mb zip file that only updates a specific library. For example a security release updating only OpenSSL.

Why Google doesn't do this and prefers using a point release system - instead of rolling releases - is a complicated question. One that I'd be curious to hear the reasoning for.

One UX consideration is that the users need to reboot their phone since the OTA update writes to the /boot partition and then triggers a reboot into recovery mode. Then recovery mode will automatically install the new update (preserving all user data) then boots back into the OS. This would be annoying to users if they had to do it often.

But the same behavior exists for any OS updates on OSX, linux, etc.

It's not a viable method for updating generic servers however. An update system needs to do a lot more than just swap out a file. You need to know about dependencies, restart services etc. It's also important for real world usage to be able to skip one update for one reason or another.

It could be interesting for single purpose Docker containers which can be restarted at will.

Yes, the Android ecosystem has an update problem. But that problem is largely due to external companies and not a technical limitation of Android.

So what OTA updates do you mean? If you mean stock Android updates removing root access...then that is exactly the expected behavior. Root is considered a security hazard and not supported by ASOP. As it should be.

I find it hilarious when people who use ROMs complain about how hard it is to modify the OS then complain about lack of security updates in the same thread. Bootloader locks and read-only filesystems are there for a very good reason.

perhaps we're talking past each other... because you seemed to miss my point... phones don't update single packages as updates are available like a typical linux distro would.

See my other comment, Android's OTA system is fully capable of updating single components. The downloads can be patch releases and not full images. Google actually recommends that vendors do this, over pushing full ROMs.

Vendors often don't do it because they are lazy or for logistical reasons. But it doesn't mean they can't.

That's a device/vendor choice, not Android as a whole.

> and when SELinux went into enforcing mode

On my stock rom it was in Permissive mode, as it is now on Cyanogenmod.

> Google is attempting to help protect users from bootkits/rootkits which has a side-effect of making modding harder

This is generally not Google's doing, it's the device manufacturers/carriers. And it's not always in the name of end-user security... which far too often abandon any updates on 1 year old devices.

> See my other comment, Android's OTA system is fully capable of updating single components

But it's not really. It's just downloading a zip file and extracting it. There is not 'apt-get' or 'yum update' functionality built into Android, and there probably can't be due to how custom every rom (even stock from the manufacturer/carrier) is. I would love it if my phone could do a "yum update" like thing and just yank down individual components as soon as they are available... but that's not reality unfortunately. When users do get updates, it's usually months after they were discovered to be at risk for some exploit due to carrier bureaucracy.

> Google actually recommends that vendors do this, over pushing full ROMs.

Mostly in the name of saving bandwidth for data capped users.

> Vendors often don't do it because they are lazy or for logistical reasons. But it doesn't mean they can't.

I think we agree here, but for different reasons.

However my busybox updater app does run in the background and does update busybox as needed automatically. Same with my su updater. So I suppose parts of my android are indeed auto-patched without my noticing.