Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Google Android Operating Systems Linux

Google's Upcoming 'Fuchsia' Smartphone OS Dumps Linux, Has a Wild New UI (arstechnica.com) 219

Posted by msmash from the shape-of-things-to-come dept.
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."
This discussion has been archived. No new comments can be posted.

Google's Upcoming 'Fuchsia' Smartphone OS Dumps Linux, Has a Wild New UI More

Google's Upcoming 'Fuchsia' Smartphone OS Dumps Linux, Has a Wild New UI

Comments Filter:

  • Magenta? (Score:5, Funny)

    by TWX ( 665546 ) on Monday May 08, 2017 @03:54PM (#54379899)

    sounds like it was written by a bunch of Riff-Raff...

  • Well, it's been a few years now. (Score:5, Insightful)

    by Anonymous Coward on Monday May 08, 2017 @03:57PM (#54379911)
    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.

    • What's the init system? Not systemd? (Score:4, Interesting)

      by Ungrounded Lightning ( 62228 ) on Monday May 08, 2017 @05:53PM (#54380913) Journal

      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.

      • I think Google might roll their own distribution or at least might have someone capable of doing that for them if they didn't like the features chosen by the distributions.

      • Re: (Score:2)

        by MSG ( 12810 )

        GNU/Linux systems are migrating to systemd. Embedded systems and Android probably won't. There's really no connection to make here.

        • We are using systemd for our commercial Embedded ARM Linux system solutions for our customers. You have heard of Yocto, right ? https://www.yoctoproject.org/ [yoctoproject.org]

          • Re:What's the init system? Not systemd? (Score:4, Informative)

            by Eravnrekaree ( 467752 ) on Tuesday May 09, 2017 @09:40AM (#54384113)

            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.

      • Perhaps this is partly in reaction to the migration of the major Linux distributions to systemd.

        Android is not a GNU/Linux desktop. It is a Linux kernel.

        Claiming that anything happened in the Linux world other than something directly with the Linux kernel itself has an effect on Android is just silly.

    • Time to completely fucking change everything so I have to re-learn how to use the phone and write my apps.

      Now that you mention it, it's rather refreshing to not hear a word about Java. Maybe Google learned their lesson?

  • Not invented here... once again. Sigh. (Score:5, Interesting)

    by exabrial ( 818005 ) on Monday May 08, 2017 @04:00PM (#54379947)
    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.

    • Re:Not invented here... once again. Sigh. (Score:5, Funny)

      by rahvin112 ( 446269 ) on Monday May 08, 2017 @04:26PM (#54380163)

      Use already invented software when they can reinvent everything from scratch by a bunch of engineers right out of school? Do you even know who google is?

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      Well, I think the base of Magenta is LK, which is on practically every Android phone out there (it serves as the bootloader), so the base of it has been around a few years already.

      • Well, I think the base of Magenta is LK, which is on practically every Android phone out there (it serves as the bootloader)

        Often, but not always. LK is often the basis of the Trusted Execution Environment OS as well.

    • Not sure that would help the problems Magenta is trying to solve. TFA suggests a primary reason for the effort is a more stable driver interface in the kernel, which could make long-term support and OS upgrades a lot easier.

    • 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.

      App isolation of the sort provided by cgroups (which is mostly about resource accounting) really isn't that much of a problem in Android. The addition of SELinux has done far, far more to improve overall system security than cgroups could, and there is still more that can be done with SELinux. Don't get me wrong, there are ways in which cgroups could help, but most of them can be just as effectively achieved by SELinux, with less disruption to the architecture.

      As for JVM bytecodes, that would be very bad

    • Not invented here... once again. Sigh. I hope it dies

      Translation "I don't know anything about it and new knowledge always hurts my head."

      I hope Linus recognizes the danger and gets busy thinking about how Linux needs to change to stay out in front of the upstart. This one is not going to die so don't waste your time bleating about it.

    • And bring Android's management of short-term heap space up to at least where Java was 15 years ago.

      Seriously. Android DOES NOT deal well with apps that promiscuously create lots of transient objects that fall out of scope almost immediately after creation. Java itself has, since at least 1.4 (circa 2001).

      With Android, you basically have to create your OWN pseudo-heap using object pools (and write your classes so they can be restored to 'new' condition). Otherwise, Android's braindead "stop the world" GC wil

  • Green and orange? (Score:2, Insightful)

    by Hognoxious ( 631665 )

    Well I can't stand UIs that use three very similar shades of grey, so they had to go to the other extreme.

    Of course looks aren't everything, but there are plenty of GUIs that look good and are shit to use, but very few the other way round.

  • Backup Plan for Oracle v. Google (Score:5, Interesting)

    by santiago ( 42242 ) on Monday May 08, 2017 @04:22PM (#54380131)

    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?)

    • > (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?)

      I don't think so since two different companies are involved but it definitely seems "weird".

      Maybe the moral of the story is if your project is named after a color, exit now before it fails. :-)

    • 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

      Mac homage or not, T-Mobile has sued Aio Wireless [theverge.com] and Engadget [techdirt.com] over the use of magenta.

    • There was also the (really, really, really) ill-fated "Project Pink [wikipedia.org]"; where Microsoft managed to take the limited, but quite popular and successful in its niche, product line they'd acquired from Danger/Sidekick and leave nothing but smoking ruins.

      That one was...genuinely impressive.

  • 120 fps .. someone FINALLY groks UI ! (Score:3, Insightful)

    by UnknownSoldier ( 67820 ) on Monday May 08, 2017 @04:35PM (#54380239)

    That is fantastic news that they are targeting 120 fps ! I hope this helps push all the other vendors (phones, monitors, etc.) stop stop targeting a shitty 30 fps experience.

    At our Fortune 50 company I'm always educating our UX and Graphic Designers about the reasons why we run our app at 60 fps. Kind of hard to argue when they see a demo first hand. :-) Now if only the rest of the company would get on board ditching the crappy 30 fps that people seem to think is "good enough."

    I wonder if Google is trying to target VR at some point placing a safe bet of 120 so they can hit the magic 90+ FPS required? The 120 fps for apps is just a bonus [arstechnica.com]

    > Android hung around inside Google for about five years before it launched on a real product.

    So basically Fuschia is a tech demo today -- that may, or may not ship.

    I wonder if they are going to ignore the whole Android ecosystem or embrace it, because 2 billion devices running Android is pretty hard to ignore.

    • Re:120 fps .. someone FINALLY groks UI ! (Score:5, Insightful)

      by omnichad ( 1198475 ) on Monday May 08, 2017 @04:56PM (#54380435) Homepage

      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.

      • How closely are video standards tied to mains frequencies these days? There was obviously a strong technical reason for it back when video transmission was analog; and quality timebases were rather hard to come by; and technology has a considerable amount of inertia; but with contemporary hardware if anything except the PSU can even detect the mains frequency, you probably have a hardware problem; and essentially everything(aside from PSUs) is low voltage DC gear with very, very, accurate and fairly versati

        • Backward compatibility has kept them locked together. There has been a small push by a few for variable frame rate screens (especially byuu of higan), but no wide manufacturing and adoption. Targeting a single monolithic frame rate should be a very intentional process in the meantime.

          I wish I could just buy the PAL version of a few of my favorite British shows - they don't seem to do a great job with the conversion to 60Hz. But unless I have equipment that can handle the frame rate, I'll be no better off

    • That is fantastic news that they are targeting 120 fps ! I hope this helps push all the other vendors (phones, monitors, etc.) stop stop targeting a shitty 30 fps experience.

      Strikes me as buzzwordy and shallow, I hope this isn't indicative...

  • They are doing this to go after the Rooters (Score:3, Insightful)

    by Zombie Ryushu ( 803103 ) on Monday May 08, 2017 @04:38PM (#54380269)

    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.

    • Actually, they're going after Linus, and you, and me.

    • 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.

  • I really like having Linux as the backbone to my device. The amount of freedom and ability to script in tasks is one of the main reasons why I've gone with Android over iOS. Hopefully this new OS allows the same level of freedom and scriptability.

    • Linux needs some competition, it's gotten a bit into that smug/cantankerous middle aged zone. What Linux does not need is to be sidelined in the handset space. I doubt that will happen, but it could. One thing: Linux kernel devs need to pull the proverbial head out of ass and start understanding some new design techniques. The alternative is to fade, like *BSD, which now hangs on mostly as an Apple symbiote.

  • When will they pop up?

  • By removing it from the GPL, they're just tivoizing the code.

    • By removing it from the GPL, they're just tivoizing the code.

      That's not an issue. I will just put it back under GPL, and you can too. If patents prevent that, then it is shit that nobody should waste their time with.

      • Re: (Score:2)

        by ameoba ( 173803 )

        Community Android development is pretty much dead anyways. Google drops code for the core OS & tells hardware manufacturers what they need to implement to make their hardware work against a Google code drop.

  • Jiri says "updating all projects", then goes autistic... doing something. Anybody know what's up with that? I thought Google was supposed to be able to handle load...

    • Jiri says "updating all projects", then goes autistic... doing something. Anybody know what's up with that? I thought Google was supposed to be able to handle load...

      Here's a nice one:

      ERROR: Error for hook(update) for project "fonts"
      ###... [ugly stuff that makes slashdot barf] ...### 100.0%
      curl: (35) gnutls_handshake() failed: The TLS connection was non-properly terminated.

      Somebody tested this?

      • Sorry, but I will need to declare that Google's code checkout system is crap. I meant to give them a pass for not just posting the code on github, but I just can't. In two words: this sucks.

        • OK, built. The TLS issue was transient... a retry got past it. Not impressed by transient issues like that, though.

          Built on a stock Ubuntu system without issues. Some warnings, mainly about deprecated Libc defines. Good that it built. Now, I just happen to have a NUC to boot it on...

  • I don't know about you guys, but to me that thing looks a bit like Googles Hurd. I doubt it will overtake *nix any time soon.

    • I don't know about you guys, but to me that thing looks a bit like Googles Hurd. I doubt it will overtake *nix any time soon.

      It's nothing like Hurd, it is actually a viable project, and apparently, already relatively mature as a bootloader.

  • Who's fault is kernel 3.18? (Score:4, Interesting)

    by viperidaenz ( 2515578 ) on Monday May 08, 2017 @06:40PM (#54381193)

    Qualcomm, they don't provide Linux drivers for later kernels.

    How are they going to fix this problem by switching to yet another OS?

    • Re:Who's fault is kernel 3.18? (Score:5, Insightful)

      by cheesybagel ( 670288 ) on Monday May 08, 2017 @07:12PM (#54381335)

      They aren't. It's gonna be worse. Since the OS is gonna be BSD/Apache based it means even more of the manufacturers won't release the drivers back into the open which means upgrades not made by them will be impossible.

      • Isn't the complaint of vendors that they want to develop against a stable API, yet Linus and his minions keep changing things under the covers?

        In Windows, a binary driver for Vista (2007) may or may not still work in Windows 10 (2017). Albeit one won't get a decade of technological advancement nor bug or security fixes.

        Binary blobs might be everywhere, perhaps, under Fuchsia, yet still offer the ROM community the latest kernel on old devices.

    • How are they going to fix this problem by switching to yet another OS?

      Obviously they are not. Fuchsia is not about making it easier for OEMs to issue updates, it is more about cutting Linux out of the toolchain so that Google will be free to go full evil. Not that they specifically intend to go full evil, but they desire the freedom to do that.

  • Google already have a Magenta AI project. Is it wise to reuse the same name for something else? We already had the problem with the Go language (well, in that case at least it was "Go!" vs "Go")

  • They should rename Fuchsia to Firehose. Actually, it sounds like Google Wave for smartphones. Yaayy!
    Look what they did there, I never thought I'd consider buying an iPhone Whoda thunk?
  • But seriously if the group [tizenassociation.org] backing Tizen (Intel, LG, & Samsung to name a few) get their act together they are positioned to swoop in and take the market while Google tries to steer it to their new walled garden. Tizen [tizen.org] is OSS top to bottom so there is no locked down portion. Although I'm sure each OEM will try to slap something proprietary on it to make it their own. They need to address the security holes [arstechnica.com] that were recently identified and clean up their codebase but it's theirs to lose.

  • I'm surprised it took so long. (Score:5, Insightful)

    by technosaurus ( 1704630 ) on Monday May 08, 2017 @10:57PM (#54382253)
    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

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Close