Slashdot Mirror
Google's Upcoming 'Fuchsia' Smartphone OS Dumps Linux, Has a Wild New UI (arstechnica.com)
More details have emerged about Fuchsia, the new mobile OS Google has been working on. ArsTechnica reports that Fuchsia is not based on Linux (unlike Android and Chrome OS). Instead, the OS uses a new, Google-developed microkernel called "Magenta." From the article: With Fuchsia, Google would not only be dumping the Linux kernel, but also the GPL: the OS is licensed under a mix of BSD 3 clause, MIT, and Apache 2.0. Dumping Linux might come as a bit of a shock, but the Android ecosystem seems to have no desire to keep up with upstream Linux releases. Even the Google Pixel is still stuck on Linux Kernel 3.18, which was first released at the end of 2014. [...] The interface and apps are written using Google's Flutter SDK, a project that actually produces cross-platform code that runs on Android and iOS. Flutter apps are written in Dart, Google's reboot of JavaScript which, on mobile, has a focus on high-performance, 120fps apps. It also has a Vulkan-based graphics renderer called "Escher" that lists "Volumetric soft shadows" as one of its features, which seems custom-built to run Google's shadow-heavy "Material Design" interface guidelines. The publication put the Flutter SDK to test on an Android device to get a sneak peek into the user interface of Fuchsia. "The home screen is a giant vertically scrolling list. In the center you'll see a (placeholder) profile picture, the date, a city name, and a battery icon," the author wrote. "Above the are 'Story' cards -- basically Recent Apps -- and below it is a scrolling list of suggestions, sort of like a Google Now placeholder. Leave the main screen and you'll see a Fuchsia 'home' button pop up on the bottom of the screen, which is just a single white circle."
They are doing this to go after the Rooters. They want to close off the "Root your device and load whatever you want" hole in these devices.
(Android security platform engineer here)
Google has no interest in eliminating the ability to root. Quite the opposite, actually. There's a pretty strong sentiment among Google engineers in general, and the Android security team in particular, that it's important that users have the ability to fully own and control their own hardware. Take a look at how Chromebook security and the required "dev screw" works for an example of how we really think it ought to be.
What Google wants to eliminate is security vulnerabilities, which has many implications. I could write an essay on what they are and how they relate to each other, but here I'll just boil it down to: The best thing to do for the security of typical user devices is to lock them down rather tightly, including removing root. However, users who want to should be able to deliberately unlock their bootloader, after which they should be able to install and run whatever software they want, whether that's a slightly-modified stock image that includes the 'su' binary, or full-on custom ROMs.
But... OEMs have for many years not liked the idea of unlockable bootloaders. This has led the modding and rooting community to seek out and exploit privilege escalation vulnerabilities in the OS that allow them to modify the system. That's nice for modders and rooters, sort of, but really bad for the rest of the ecosystem, because privilege escalation vulnerabilities are at least as available to malicious attackers as they are to power users.
As the Android security team tightens down the hatches, notably (but not exclusively) by employing SELinux to block off most of the exploit chains, so even when you find a vulnerability in one app or system component you can't use it to do anything, modders and rooters are finding that it is getting harder and harder to find exploitable vulns. Yay for security, bad for rooting devices with permalocked bootloaders (which is most devices).
Zombie Ryushu (and many others) interpret this as Google being opposed to rooting, but what's really going on is just improving security. If you want to root, you should be able to root... but you should only be able to do it by explicitly unlocking the device security protections. And that unlocking process must be somewhat hard, to mitigate social engineering attacks. Hence: enable the hidden developer options, flip the OEM unlock switch, install adb and fastboot on a computer, connect via USB, adb reboot-bootloader, fastboot oem unlock, read the scary text on the display and manipulate the buttons to say "okay", etc. Nothing in that process is hard, but it's the sort of thing you're going to find difficult to social engineer a typical user into doing.
Bottom line: If you want to root, buy a device with an unlockable bootloader and root it. If you buy a device with a permalocked bootloader, don't be surprised if you find it can't be rooted. That's a Good Thing, it means that system security is solid.
Oh... one more point: SafetyNet's root detection also does not mean Google is opposed to rooting. It just means that Google understands that some apps don't want to run on rooted devices, and Google believes app developers should have that choice.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
systemd is actually far more modular and decentralized than the old event system and more customizable. The people who oppose it don't know what they are talking about and just oppose it as a knee jerk reaction because its new. Since systemd supports sysv init scripts, it has all of the functionality of sysv, it only adds additional functionality. So the anti-systemd mentality is not that they cannot use it the way they want, but they do not think that people should be allowed to use the additional functionality that systemd provides.
For instance, systemd is far more elegant if you need to be able to start service only when multiple other events have occured and multiple conditions have been met and provides a very elegant way to monitor and generate events in a standardized way. Its decentralized and loosely coupled because of the dbus oriented design. If you want to start a service when a user does an su, this becomes much easier with systemd.
You can write new daemons that monitor dbus that can be custom programmed however someone wants in any programming language to define when a service should be started. systemd has stock daemons that are controlled by the unit files, but you can also write init daemons in any programming language that have custom logic.
All of the disinformation against systemd is really destructive and damaging to Linux they misrepresent everything systemd does.
The fact is systemd is an enormous improvement that makes Linux far more flexible and easier to manage.