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.
no more dumbass unpatachable manufacturer OS builds and no open source security hole riddled dumpster fires. Don't you remember the story from a few days ago that there's a new android exploit discovered like every 5 minutes?
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?)
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
> 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.
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.
Wel F*CK ME!
It's colored rectangles!
"Flyin' in just a sweet place,
Never been known to fail..."
Too bad Jolla doesn't have the financial power to make it really take off.
Circumcision is child abuse.
Actually, Minix sounds like a much better base for Android, given that Google prefers BSD code in the userland, and only uses Linux for the kernel. Had they used Minix, they could have used the complete package under the same license, or even made it proprietary. Given how much Google contributes to the BSDs, I'm surprised that they didn't go that route.
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 all you have is a hammer, every problem starts to look like a thumb.
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
Qualcomm, they don't provide Linux drivers for later kernels.
How are they going to fix this problem by switching to yet another OS?
As if an OS based on Java apps wasn't slow enough, now we get an OS based on Javascript shovelware.
The OS is actually C++, the javascript stuff is just skinning.
When all you have is a hammer, every problem starts to look like a thumb.
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...
When all you have is a hammer, every problem starts to look like a thumb.
Just because you *have* the code, doesn't mean you can GPL the code. The author is the only one that has that right (because they own the copyrights) unless they delegate those rights to someone else
or unless they gave you a license.
like a BSD license
or is your intention to simply steal it and stick a GPL on it.
which is 100% doable when switching from BSD to GPL (but not the other way around).
BSD is license designed for the freedom of developers developers.
it basically states:
"you are allowed to do what the fuck you want with the code, even keeping it all for yourself and only releasing binaries, but you can also release it"
GPL is about freedom of end users. A user should always be provided with the freedom o code they are running, so they too can modify it not (not only you as a dev). it thus comes down to "you are allowed to do what the fuck you want to do with the code. but if you give out to someone elsr, they shoukd get the same rights to tinker ad you did".
If you look closely, the second is basically the first, but with the additional requirements to pass down the freedoms to the next.
now play close attention : nothing in a permissive license like BSD would prevent you to add this extra clause. it s all about letting you, the dev, do whatever the fuck you want, and adding the requirement is something you might want to.
(otoh, copyleft license require that transmit further down under the exact same condition you received. you receive it as GPL, the next one must be getting GPL.
And that GPL doesn't allow you to remove that requirement.
relicensing problems do exist, but they concerne smaller details.
- older BSD license required a name mention. it's not only "do what you want " (a change to GPl would be ob the list),but also "required to spell name in any product you hand out. (which goes against the GPL. GPL won't rely adding restrictions )
- gpl has versions. some softwar is licensed as "GPL v2-only" so you caan't release under anything else (because copyleft asks you to keep the rights)
other explicitly mention future: "gpl v3 or anything more recent" so on the day GPL v6 is out you can use it.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Swift and Perl
Task Mangler
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
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/
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.