Linked by Thom Holwerda on Sat 4th Aug 2012 00:54 UTC
Google This tweet from Tom Warren made me smile. So, it's 2012 and tablets are finally able to do what the Amiga did in 1985. Seems like a bit of a stretch to be excited about that, right? Sure, until I caught myself getting excited - only a bit, but still - by this piece of news. Update: removed me being an annoyed child.
Thread beginning with comment 529705
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: KISS
by WereCatf on Sat 4th Aug 2012 21:17 UTC in reply to "RE[4]: KISS"
WereCatf
Member since:
2006-02-15

And I fear that multi-user support will increase this slowness, actually... I'm pretty sure of that because I dealt with multiuser issues during my career.


Does your Windows, Mac or Linux device slow down as you add more and more user accounts on it?

I mean, the device will have to store the state of the session when you switch between users (running apps, configs, connections, ecc)... Android has to keep that state in memory somehow, in RAM or swap it to the flash memory... It's not a minor concern, It can be very resource hungry.


Of course the state would be saved in the permanent storage, there would be no benefit from keeping it in RAM at all times except when you switch users, and well, that's not something you do every few minutes. It doesn't consume resources after it's been saved to storage.

Then you have the file owner/permission issue. You don't want that your files can be modified by another user. Android will have to implement that too.


ext2/3/4 filesystem already handles that, Google only needs to check that Android itself uses those. It's not as large an issue as you seem to believe.

That's why I think adding multiuser support to a mobile OS is a big fat stupid idea. Good multiuser support is a complex thing. It's not trivial nor "free".


Proper multi-user support is mostly a kernel - and filesystem - thing, the layers on top of that are merely an extension of kernel and filesystem functionality.

Reply Parent Score: 5

RE[6]: KISS
by sergio on Sat 4th Aug 2012 21:58 in reply to "RE[5]: KISS"
sergio Member since:
2005-07-06

Proper multi-user support is mostly a kernel - and filesystem - thing, the layers on top of that are merely an extension of kernel and filesystem functionality.

Yeap, the problem is that you have to present it to the user in a friendly and mobile-like way. Use cases for Phone/tablets are totally different than a PC.

For example, every time you lock/unlock your device, you will have to authenticate with your passcode AND your user. It's minor detail yes, but there's lots of minor details with you go multiuser.

To name one big technical issue: Android allows user level apps to run as a daemon in the background. If you go multi-user you have to keep running their daemons in the background even if the active user don't use them. It impacts directly on performance and energy consumption.

As I said before, there's lots of "details". Multiuser isn't trivial at all.

Reply Parent Score: 0

RE[7]: KISS
by WereCatf on Sun 5th Aug 2012 09:45 in reply to "RE[6]: KISS"
WereCatf Member since:
2006-02-15

For example, every time you lock/unlock your device, you will have to authenticate with your passcode AND your user.


Err, why would you have to do that? You'd unlock the device just as you do now, only that there could be a dropdown-menu in some corner for changing to another user. When logging in to Windows, for example, do you always type your username or do you just click on your avatar? Most people do the latter and there is absolutely no technical reason for why it couldn't work the same on Android. Similarly, instead of a password one could just use the same methods one uses already: a PIN, face unlock, gestures etc.

To name one big technical issue: Android allows user level apps to run as a daemon in the background. If you go multi-user you have to keep running their daemons in the background even if the active user don't use them.


Android could just as well kill the daemons when the user is changed and restart them when that previous user logs in the next time.

As I said before, there's lots of "details". Multiuser isn't trivial at all.


It's more trivial than you think. You're giving a lot of totally bogus "issues" as examples, like e.g. that one must always log in with a username and password, and I don't know if you are deliberately trying to make it look harder than it actually is or if you just don't really understand multi-user task - and filesystem - mechanics. If it is the latter I offer to explain things or I can point you to resources if you would like to know more.

Reply Parent Score: 4