If you were to design a client operating system with the goal of being used by two billion people, what would it look like?
We might soon find out what Alphabet’s looks like. Today’s announcement’s from Alphabet’s Google is expected to reveal "Andromeda", the merged Android/Chrome OS. Executives have been hyping today’s event …

If I were to design a client operating system with the goal of being used by two billion people I wouldn't be starting out worrying about the kernel.

I'd be much more concerned about a security model that prevented applications grabbing data without the user being aware of it and sending it off to places the user has never heard of. That's largely all stuff that should sit in a protection ring somewhere between the application and the kernel.

I will of course never get to design a client operating system used by two billion people (though I have in the past designed bits of operating systems that were widely used) because the only reason those two billion people are ever going to be offered a client operating system is in order for it to slurp surreptitiously while they are distracted.

"I'd be much more concerned about a security model that prevented applications grabbing data without the user being aware of it and sending it off to places the user has never heard of "

I think you need to add a few more things along those lines. One being to stop the OS itself doing the same thing. Another being to protect malware vandalising rather than grabbing the data. The third being to prevent the system from being hijacked for Bitcoin mining, spamming, DDOS or anything else.

Those are the current concerns. There's always the possibility of something new coming down the line next year.

Sad isn't it? The main criteria for an OS in this day and age are more centred on what it needs to prevent than on what it needs to facilitate. I suppose the explanation is that the last several decades have been spent on providing facilities and not enough on security. It's time to redress the balance.

Those things that an OS needs to prevent are things that should never have been allowed to happen in the first place.

Security and software correctness are heavily intertwined and such monstrosities as out-of-bounds reads on arrays, buffer overflows, or pointers reading beyond the buffer at which they are pointing should be disallowed at as low a level as possible.

Indeed. Just because Linux is good doesn't mean it's perfect. QNX, as an example, has much smaller footprint, and a real-time design, making it - or something like it - more suitable for embedded applications and the IoT. Or even for a mobile phone where it is critical that it doesn't drop a phone call because the OS is concentrating on something else.

If it's using Little Kernel, then yes, it's a microkernel. LK's author Travis is a big fan of ukernels. He tends to hang out on #osdev on the Freenode IRC network giving advice on operating system design.

QNX is a good OS but Blackberry devices were no better from using it than Android for using Linux, iOS for using BSD, Windows Phone for using NT. All these devices managed to present modern, efficient user friendly phone experiences. And that's all that matters from a user perspective. The choice of micro or monolithic kernel is a sideshow.

As for IoT devices, I expect the main driver for what kernel / OS they use is what tools are available, how well they work, how much they cost and what if any runtime license does the manufacturer have to pay per unit. Since the tools for Linux are generally excellent and the runtime cost is zero, it's clearly going to be the defacto choice unless there is a reason to choose differently.

"Since the tools for Linux are generally excellent and the runtime cost is zero, it's clearly going to be the defacto choice unless there is a reason to choose differently."

There is good reason and it's not even systemd. I don't see any of the current OS architectures, either Windows or Unix-like, offering the defensiveness needed under modern conditions. I think that over the next few years we're going to see a new architecture that places more emphasis on security. It's all very well providing perimeter security to try to keep invaders out. Let's not assume that we can do that all the time because PEBCAK won't let us. So what can we do to minimise damage if they're in?

Problem is, there's not much you CAN do once they're in. Once the first wall goes down things can start to cascade. Furthermore, security frequently interferes with productivity. And for now at least, productivity takes precedence over security, as the job needs to get done first. What good's a lock if no one has the key, for example?

Re: Should have happened years ago

>There wasn't a good reason for ChromeOS and Android to be separate things in the first place.

Really? There are a lot of inherent issues with Android that Google want rid of. One was mentioned in the article - Java, and another you'll have read of many times in these forums - the slow speed of updates because each new build is specific to a specific hardware configuration (so requires the cooporation of original chip manufacturers).

Re: Should have happened years ago

There is no reason that a desktop should be written in Java to host Android apps any more than Windows should be written in WinRT to host Windows Store apps. The two can co-exist. Besides which, Java is merely the programming language that most (not all) apps are written with on Android. It says nothing of how the code is packaged or executed.

Re: Should have happened years ago

@Dave 126

ChromeOS was a skunkworks project that Google allowed to become a project. But it soon started duplicating infrastructure associated with a full-blown OS: local storage, printing, multimedia. Want a browser-based OS? Try Firefox OS and see how well that's doing. OTOH want a sandboxed Android with no local storage? And as for app delivery via the browser, well we've now got "progressive web apps". ChromeOS was certainly useful developing some of the stuff but has now outlived itself.

The security and update aspects of Android are now well (or at least much better) understood by Google and support is probably built in to anything new. But you can't turn the clock back. A new micro-kernel OS might give them much more scope to push out security patches. A micro-kernel and JIT architecture should cope with most hardware issues but you can also bet that the licence for the new OS will allow less leeway when it comes to hardware and drivers. The latter might also give Google greater access to the Chinese market where Android dominates but without Google's services.

Re: Should have happened years ago

>the slow speed of updates because each new build is specific to a specific hardware configuration (so requires the cooporation of original chip manufacturers).

Hence the microkernel? It seems to me that (power) efficiencies are to be had by de-layering the software and having a monolithic system, but that makes updates - especially when there are third-party mods from the telco networks - difficult to impossible.

The reason we don't have microkernels Windows after NT3.51 is that, while they are "the right thing to do" it requires lots of copying of data in and out of the kernel which is slow - and relevant to today - power-inefficient. It was safe, secure, and a performance dog which led to NT4. The interesting point will be if its better than running bytecode. If it is, they may be able to pull off a a switch from virtualisation to microkernel without too much of a hit to the user.

While from a user's POV making the OS secure is moot if the application layers are handing out data to all-comers, Google may have an interest in making sure all the data is funneled through them, rather than crime syndicates. The point about FLOSS is that it accumulates features and can afford to play the long game. Linux could easily end up being a threat to Android.

It will be interesting to see if Google makes a move to secure their OS or if they will rest on their volume of market share.

Re: Should have happened years ago

" The point about FLOSS is that it accumulates features and can afford to play the long game. "

Slow and steady wins the race, as they say. For example, remember the year of the Linux desktop? Long game...

(Yes, I'm being sarcastic, but it's worth noting that I'm a Linux user myself. I own multiple PCs, only one of which currently has Windows on it, and even that's out of use because I can't be bothered tracking down a year-and-a-half old bug report from when certain Window 7 boxes started failing to update -- mine was among them.)

Nothing to see here, move along

I don't see much to get excited about, certainly not from a user's perspective. Yes, there will be a degree of consolidation/defragmentation, for those who care about such things (pundits, mostly), but beyond that nothing obvious will change. Google's entire UX is the Cloud, the client is almost completely irrelevant.

Whatever Google is working on, you can be sure the end result is still going to be yet another VM, and some mechanism to retain backwards compatibility with the vast Android ecosystem (it's the Windows problem all over again).

What might actually be an exciting development, would be if Google dropped the RAD objective and moved away from VMs entirely, because then we might actually get something resembling efficient code that runs how it ought to on multi-gigahertz systems, rather than something that multitasks worse than a three decade old Amiga running at ~7MHz (no, even ART's precompiled method doesn't rid us of dependency bloat).

Sadly, no financially-motivated software ecosystem has any interest in such prosaic things as efficiency. They just want the software and money conveyor belts moving at breakneck speeds.

Now that it's clear I have no love for Java, and not much love for Google either, I would just like to add that this whole debacle over Google's supposed "copyright infringement" is a farce. APIs are methods, not software, and as such the applicable branch of law is patents, not copyrights. Restricting the use of methods is contrary to the ethos of Free Software (freedom 1), which is why Free Software advocates rejoiced when Oracle lost. Prohibiting the act of learning and reimplementing does nothing to "protect" Free Software, in fact it completely undermines its entire purpose.

Having said that, I will not mourn the death of Java, which is exactly what Oracle seems to be precipitating with its monopolistic practices. Good riddance, frankly.

Re: Damn and blast

Re: Damn and blast

That was no typo. Not sure how you think 'Strain' would work, unless you imagine me with a sieve under my puking cat in order to catch the chunky bits. Cue the joke about the waiter in an alleyway, three tramps, two cocktail sticks and a straw.

Re: Curtains for Windows

Re: Curtains for Windows

There is no reliable way to stop Windows 10 from restarting itself whenever it feels like.

There is no reliable way to stop Windows 10 from restarting itself whenever it feels like.

Yeah, I know I said it twice, but what the hell? [all caps, multiple exclamation marks etc]

How the living fuck can you leave it to do a simulation or render? The answer (apparently): Big jobs like that should be done on rented compute power like AWS - or MS's equivalent. Oh well. Arse burgers.

And no, Linux is not an option. I'm sure it's a lovely OS but the applications for many sectors just suck. Deal with it. The GIMP is to Photoshop what Windows is to Linux. As for serious CAD, don't make me laugh... it'll be streamed from the cloud to a thin client before Linux gets it properly. Sad really, cos it was all Unixy (though proprietary and useful) back in the nineties.

Re: Curtains for Windows

many of us HOPE for a replacement for Win-10-nic to "surface" (PUN-ishment deliberate) but I don't think _this_ is it.

Then again, who knows? Win-10-nic assumes we're all content consumers. Chrome kinda does, from what I've seen, and 'droid DEFINITELY does. All I can see is "content consumption" here, no actual work getting done. So, slab-fad, 2nd time around. Just keep the barphing cat away, we don't want to "inspire" anything with the '2nd time around' concept...

what chance is there that 'ghostbsd' would be the 'new windows'? Probably none...

Re: Curtains for Windows

I thought the restarts with the accompanying loss of state, and sometimes loss of data, was annoying, but then it started updating synaptics touchpad drivers every week, to broken drivers. The forcefed driver makes touchpad switch on and off in an infinite loop, occupying a CPU core and making the touchpad unusable. Input focus is also constantly taken away by the touchpad notifications.

After every reboot I thus need to uninstall the driver and install the driver from synaptic's website. As a normal user I haven't found a way to disable driver updates.

NT, or XP?

I think the proper analogy is XP, not NT. NT was a new architecture, separate from the legacy 3.x/95/98 codebase. XP was the reunification of these divergent streams. Similarly, Android represented a bit of an architectural departure with its unique JVM-based userspace. Andromeda will represent the reunification of that with the more traditional architecture of ChromeOS (so traditional that I'm running full Ubuntu in another window on this Chromebook right now).

Still trying to get a handle on what Andromeda will mean for us Chromebook users, BTW. *That* would be an interesting story to delve into.

Re: NT, or XP?

It's actually both things. Andromeda is both a new OS (like NT for the DOS/Win9x branch) and the one to replace the diverging branches of Android and ChromeOS. Though I'd point out that Windows 2000 was the first one to merge both branches ... XP was more popular, but Microsoft was already pointing in that direction when they released 2000.

Re: Will Andromeda be Ascendant?

Dropping Linux and the GPL completely?

Google claim to be pro open source, but they really aren't that into it and keep keeping their foot out the door so they can close things. Which they do while they also do a lot of stuff they never open.

Part of the problem with Android is that because the vendor can close stuff, they do, and then no one but the vendor can update the phone, and they don't because they have moved on to the new shiny they want you to buy. Android is the worse of all worlds because of the permissive licensing Google went out their way to have. Avoiding GPL projects as much as they could. If vendors couldn't modify the source and had to stick to a hardware platform standard, then we could update freely. If vendors had to open their modifications to the source, it could all be upstreamed and reworked and we could update freely.

I wonder if this new platform is going to be Linux or if they are just going completely closed and asserting themselves. Most consumers won't notice or care, least not for a while, and then it would just be the affects they notice not the cause.

I'd like to think this bringing together ChromeOS and Android means going more GNU and free, but this being Google I doubt it.