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."
sounds like it was written by a bunch of Riff-Raff...
Do not look into laser with remaining eye.
Time to completely fucking change everything so I have to re-learn how to use the phone and write my apps. Change for the sake of change, dontcha know.
Not invented here... once again. Sigh. I hope it dies
What Google needs to do is upgrade Android to use cgroups for app isolation, and switch to using JVM bytecodes so they can recycle the vast amount of work in the OpenJDK project.
I assume the ultimate motivation for this project was as a backup plan in case of a disastrously adverse ruling in Oracle v. Google that would have led to Google deciding to excise any connection between Android and Java. It's probably since taken on a life of its own, as these things tend to do. (Also, I wonder if the names Fuchsia & Magenta are references to the ill-fated Pink OS that started life as a ground-up Mac OS rewrite at Apple and morphed into the Taligent corporation?)
Wel F*CK ME!
It's colored rectangles!
"Flyin' in just a sweet place,
Never been known to fail..."
Targeting 120fps is also good for media consumption, since it's a least common multiple of 24fps and 60fps. If they want to do more set-top boxes, this might help. Downside is if it's not fully variable and 50Hz countries get left out.
Too bad Jolla doesn't have the financial power to make it really take off.
Circumcision is child abuse.
I'm curious what it's using for an init system.
Perhaps this is partly in reaction to the migration of the major Linux distributions to systemd.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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.
Qualcomm, they don't provide Linux drivers for later kernels.
How are they going to fix this problem by switching to yet another OS?
You need 120 fps because the batteries currently last too long. That's why.
So what's the official excuse for dumping Linux? If that were to happen, I would have to give Google a big, "Fuck You, NVidia!" and stop developing for Android. It would be years, and many thousands of development hours wasted.
The Linux kernel development process is a total PITA and I don't mean in the combative, degrading and misogynistic attitudes prevalent on the mailing list. The actual process and leadership is broken.
* They keep flawed external user space APIs in place in "Major Releases" for compatibility with broken apps. Not that major releases mean anything anymore.
* They consistently and openly break internal APIs in a way that drivers will fail to compile as a way to brow-beat vendors into not shipping binary blobs.
* Linus himself has said it has become bloated and shitty (not an exact quote), but no push has been made to debloat or clean it up. The video drivers are probably the worst offenders; I ran duplo to detect code duplicates and it totally filled up my hard drive.
* How long has NTFS been around? Long enough that the internal driver ought to be able to safely write to it.
* The development process has become so segregated that there is no cross talk. For example compressed RAM, compressed SWAP and a compressed file system each expand and recompress data between each other even when they use the same compression method.
* The kernel continues to add unnecessary build requirements like bc and perl even though Rob Landley (toybox and formerly busybox maintainer) has provided several (not-accepted) patches. Add that to the insanely large repo size and you basically have to pay people to touch it now.
* Too many more reasons to mention, but it works, I use it, people use it, businesses use it and there is no real competitor at the moment to force them to compete and actually fix stuff - new features make news, cleaning up 1000 lines of duplicate code doesn't - I hope magenta inspires a 1000 paper-cuts cleanup campaign.
Alphabet* (Google) basically used linux in the beginning because that is what the android project started on and the alternatives at the time didn't have the same level of support for embedded architectures that could be used in phones and tablets. Sure, the BSDs had some support for the processors, but decent accelerated 3D graphics ruled them out (not that it is superb in Linux either). Now that they have a large market share, they can leverage that into vendor support, but since many of them don't want to open source their code and help their competitors reverse engineer the hardware that their company invested lots of time and money in, it is useful to have a relatively stable internal API that Alphabet can control without arbitrarily being overruled because some old IBM mainframe still uses that bug/feature.
-- Yes I said Linux without the GNU --- musl-libc, toybox, jwm, X11 and st is all you need for a basic desktop system
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.