Key question, how will system updates be delivered and who controls them ?
Please not carriers or device makers.
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 …
I have no gospel answer for you, but looking at the clues should give you grounds for optomism:
1, ChromeOS is regularly updated directly from Google
2, The foot-dragging attitude of OEMs and carriers toward Android updates frustrates Google, to the extent they have had the Nexus and Google Play Edition range of phones to show OEMs 'how it's done'.
3, This new OS is a chance for Google to undo rushed decisions made in Android's early days (when they were desperate to catch up with iOS)
how much will it call home?
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.
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.
>As for IoT devices... ...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.
Three big reasons:
The size of OSs such as QNX are a tenth the size of Linux. This is important if your application is taking power from an AA cell or harvesting it from piezo-electric switch or from elsewhere.
Also, IoT applications may be more of a pain in the arse if they go wrong- QNX has a longer, more battle-hardened pedigree in critical systems than Linux.
Yet more, Linux isn't a real time OS.
The idea that Linux is a panacea is mere shabby thinking, or at least narrow thinking based upon the presumption that a computer is a discrete lump of X Mhrtz and Z MB etc
"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?
There wasn't a good reason for ChromeOS and Android to be separate things in the first place. It was just a case of Google's left hand not knowing what the right was doing.
I expect whatever they reveal will be reminiscent of RemixOS which is basically desktop android.
>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).
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.
Secondly, the speed of updates is a totally orthogonal issue.
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.
Be interesting to see what they come up with.
>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.
" 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.)
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.
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.
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.
"There is no reliable way to stop Windows 10 from restarting itself whenever it feels like."
In the 'update' settings, turn your active hours to run from 00:00 to 23:59. It will then not restart itself ever unless you directly order it to.
So you're wrong, though I do agree that the entire 'active hours' thing is ridiculous.
"In the 'update' settings, turn your active hours to run from 00:00 to 23:59. It will then not restart itself ever unless you directly order it to."
No, YOU'RE wrong. Nice try, but Active Hours are limited to an eight-hour window (trust me, I looked because I'm a night owl). You can't do what you just described.
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...
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.
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.
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.
If they don't let vendors modify the software at all, then there is no way for OEMs to differentiate their Android2 phones. Physical appearance alone isn't enough, since most phones look pretty similar these days.
If Google tries to lock things down too much, OEMs might not choose to follow.
That's why Android introduced Overlays. The idea is that the custom stuff can be shoved off to Userland and away form the sensitive stuff. No reason Andromeda couldn't do the same. What Google wants and needs (for legal protection) is the ability to keep the nuts and bolts of the system under their control the way Apple does.
>If Google tries to lock things down too much, OEMs might not choose to follow.
So what? If an HTC get too big for their boots, there will be a Huawei or OnePlus (or a Bloggs MK1 with Qualcomm SoC, Sony camera and LG display... same difference) to fill their place. [please update my references according to how far through 2016/17 we are].
Speaking as a fan of the Sony Xperia Z (Compact) range, there is little that Android OEMs can do to differentiate themselves.
My friend is still using his iPhone 4S - and beyond replacing its battery himself, has cheerfully taken no interest in mobile phones since he bought it. He's vaguely 'normal'. I'm not, so I'll use my cheap (and seemingly indestructibly plastic) Huawei until I get a Project Mango Lenovo (Y'know, the one with the 3D depth mapping )
Well the risk for Google is that if a couple big vendors decide not to follow Google into Android2 land, and fork Android1 and develop their own layers, then suddenly Google goes from 80% of the market to 40%. That would deal a massive blow to their advertising business as those people would end up using Bing or DuckGoGo for search, and other non-Google services.
I think Google thinks they are so indispensable for those services that no one would dare leave them, but I don't think the average person would even notice if you replaced Google with Bing for their searches. For the type of searches the average person does they are the same. Here Maps is a good alternative to Google's, and so forth. Google isn't indispensable, they just think they are.
"I think Google thinks they are so indispensable for those services that no one would dare leave them, but I don't think the average person would even notice if you replaced Google with Bing for their searches. For the type of searches the average person does they are the same. Here Maps is a good alternative to Google's, and so forth. Google isn't indispensable, they just think they are."
Oh? How about putting them all under one search? How would Bing talk to Here, for example to link a search to a map? Or what about all the metadata Google can aggregate such as traffic data? Last I recall, here's traffic data isn't nearly as robust since they lack scope.
If Samsung started using them they'd get that scope pretty quickly.
Another possibility would be HERE Maps collaborating with Apple to combine their traffic data. Between the two (especially if Samsung went from Google to HERE) suddenly Google would be the one lacking scope.
How when Google has access too all those computers and other devices? Google has more reach than Apple and here doesn't have a huge network of users monitoring traffic the way Waze and the like do. Plus Google through Android can directly analyze mobile data traffic to get information. Who else can do that?
"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."
That's not really Google's problem to blame. There's no standardized method of presenting hardware in most ARM setups that we know about. It's all set up just so and presented to the system via boot images and memory maps. It's like going back to the days of the PC ISA bus, jumpers, and hand-inputting ports and so on. Mind you, for an embedded device like a smartphone, this is actually a good way to go since unlike in a PC the hardware can't be adjusted in its working life. However, this creates wiggle room for highly-competitive component manufacturers who protect their products even more than Google does. Since they produce actual physical hardware, they can and do employ patents, NDAs, and trade secrets to "black box" their products. Thus all their drivers are submitted to device manufacturers as binary blobs. GPL is no help against a patent.
So far the results were fairly mixed. Windows, probably the most famous system based on OOP principles, has changed so often into so many directions, you can hardly see the original idea of objects (Windows and GUI elements) passing around messages (events).
BeOS seems to have been rather decent, but thanks to it being closed source and rather incompatible, it didn't actually have a chance.
My guess, and I actually hope that people will proof me wrong, is that it'll be just a mess like Android. A system far to complex to be maintained without the help of Google. A system that offers so little useful functionality under a coat of shiny stuff. A system that sees locking out the user as a security feature. Much of this won't be because of the system design itself, but because of the people such a design will attract.
However there is one really good thing that could come out of this. It could attract the systemd/freedesktop people away from Linux.
This post has been deleted by its author
I don't think they had a choice. Microkernels tend to have one nasty little fault with them: lackluster performance (usually because of lots of context switching between the kernel and userland). Especially with stuff like graphics (and in other fields, high-speed low-latency networking), maximum performance tends to require getting close to the metal, and microkernels are built to prevent this for security reasons (seL4, for example, is only formally verified if you don't use DMA, which happens to be one of those ways to speed up hardware access when throughput is necessary). Since Microsoft had to sell to the end-user who was waking up to 3D graphics offerings from 3dfx, ATi, and newcomer nVidia, something had to give. QNX never had to really deal with this because high-performance graphics weren't on the top of the priority list where it's used. But 3D games ARE a noteworthy section of Android's app assortment. So this does raise the issue. How can Google balance the competing needs of high performance and high security?
You keep saying that but the context switch time is a function of the hardware and X86 of any type is appallingly slow at doing this.
NT 3 as designed by Dave Cutler depended on the context switching speed that a VAX processor could provide. This was heavily assisted in the VAX with a dedicated block and register to speed the switch up.
The 4 modes of the VAX, kernel. executive, supervisor, user, these were all used.
The X86 family have this as well but only kernel and user are used because the context switch speed is stupidly slow.
Last I checked, ARM (the dominant tech in the mobile world) isn't that much better. Plus another thing with context switching is when data has to be transferred between contexts (such as raw data from a network driver being processed into userland). It seems noteworthy that no microkernel OS AFAIK has been successfully deployed in areas such as 3D gaming and low-latency networking where high throughput is required, and consumers WILL demand high performance.
>I'd like to think this bringing together ChromeOS and Android means going more GNU and free, but this being Google I doubt it.
However much Google do to maintain Andromeda, manufacturers have consistently shown they just want to fire and forget - leaving Google ostensibly at the helm of an OS with billions of unsecure devices - and n100 millions of vulnerable users. Google need to be in control - less permissive licensing is an easy route to blocking irresponsible manufacturers.
Users don't care about Free/GNU but they're (ever so) slowly beginning to get the concept of 'secure'.
Does this now mean it has now been acknowledged that there was no foul pay with Google using the java API?
I guess the link to the article 'Oracle ultimately prevails in the litigation on appeal' means no, despite the subsequent article by Shaun Nichols 'Oracle loses (again) in battle to get Google Java case retried (again)'
"But Google doesn’t need Java any more, and the more distance it puts between itself and its Java-based legacy"
I doubt we will see Google drop Java anytime soon.
I've been at this game for years and read The Mythical Man Month when it was first published (I still have the book) - in all these years I have to say that it's still a very effective judgement on how far we have not progressed with project management.
It will all end in tears.
Biting the hand that feeds IT © 1998–2020