Running unmodified Linux programs on Fuchsia
fuchsia-review.googlesource.com
fuchsia-review.googlesource.com
This seems to be new (circumstantial) evidence that Fuchsia is supposed to eventually replace Linux in Android.
What we can clearly see here is that an Android replacement must be able to either run Android apps / games or have the same officially supported version of this said app / game, (Like Adobe Photoshop Express or Pokémon GO for iOS or Android or ‘New Platform’)
The first route is the quickest for them to support the existing Android app ecosystem from day 1 or the alternative is to rewrite these apps for this new OS platform which takes years. The former route was the obvious choice for them.
Yes, supporting apps for a competing platform gives some developers a convenient excuse to not develop for your platform specifically. But you still get the benefit of their work for the other platform. And not supporting those apps gives users a solid reason to not use your platform at all.
I could maybe justify the current iteration of Pinephone as an experiment, try and make an app and buy it through my company as a freelancer, but Purism would need to have quite a few major apps before I could justify the cost. My heart wants me to support these projects. It almost feels like a moral imperative if we want to actually own and control our mobile hardware ever.
But it almost feels like going off and living in the woods to save the environment, the altenative needs a few more of the mod cons for any kind of serious adoption.
This has genuinely caused me a lot of anguish.
I'm considering trying to drop my day job hours to 4 days so I have more freedom for side projects and this might be the nudge I needed.
OS/2 was never really successful outside of that domain.
It depends on how you define "replace", I suppose, but Windows really seems to have less and less importance in a lot of spaces.
On the other hand, Apple has been very careful to include this sort of "backwards compatibility" in all their systems for a while. It's usually not maintained as long as Microsoft does, but from m68k -> ppc -> i386 -> amd64 -> armv8 they're always supported at least the last architecture and runtime, so early OS X could run apps from System 7/8/9.
This was true even for Microsoft.
Windows NT/2000/XP was effectively a new operating system that was able to run Windows applications.
Microsoft worked very hard to reproduce old bugs and undefined behaviors so that old binaries will continue working on the new Windows.
I think Windows 2000 didn't have nearly as much compatibility work as XP.
I guess Windows 95 came out because NT was a lot for a 386 or 486? And also different priorities as far as compatibility.
You had to enable it with regsvr32 /enable slayerui.dll or something like that.
Additional useful reading: https://devblogs.microsoft.com/oldnewthing/20120102-00/?p=87...
We entered the new millennium with the concept that most computers could use most extension hardware with (relatively) little effort, and you could upgrade your computer's basic operating system at will; even change it to another one entirely.
I'd love to update my still-decent Android phones that have long since stopped receiving security updates, but I can't. This is objectively inferior, a massive regression from general computing.
> I'd love to update my still-decent Android phones that have long since stopped receiving security updates, but I can't. This is objectively inferior, a massive regression from general computing.
this is one of the smelliest BS i've read on hn in the last year or two. phones before android were not upgradable AT ALL. if you were lucky, you could put a bigger memory card, and that was it.
nowadays you can access most of the sources of the os for your average android smartphone, you can rebuild the os and reflash it yourself. doing such thigs was a basically just wet dream in early 2000s.
Sure, some carriers restricted updates - but that's still a problem Android faces.
They weren't general computing devices. They were for making phone calls, sending SMS messages, and tracking contacts. The security risk profile did not include access to social media accounts and/or online banking.
For many folks, and a growing many folks, their phones are now their primary computing devices. For many folks, their primary computing devices no longer receive security updates.
> you can rebuild the os and reflash it yourself.
Tell me how I do that if I cannot root the phone.
What you need is a bootloader that is not locked so you can boot a different OS instead.
In my experience most major Android vendors do support bootloader unlocking.
Apparently I dreamed of doing Series 30, Series 40, Symbian and Windows CE updates.
If you show me such a device, I would instantly ditch my iphone, pretty much the only reason I have one is the great hardware and the lack of google supervision. I even bought a pinephone, but it needs a lot of work (and a new hardware iteration) before it can become truly usable.
And who enabled that? Not everyone wants to admit it, but it was IBM together with Microsoft which made this possible. This openness was thanks to a proprietary vendor wanting to make one operating system that ran on a wide variety of hardware.
The chaos of the embedded world is Linux's doing.
Which is the funny thing, given how much closed source drivers have hurt android as far as I can tell.
On x86, you can just grab a Windows or Linux .iso and it will enumerate all hardware via PnP and install the appropriate drivers. This is something that is sorely missing in the Arm world. Instead you get semi-closed BSPs, source code thrown over the wall, and you have to write your own device-tree files and often kernel code to get something to run. SSBA is a start but only targeting the server market.
It absolutely is a problem. There is plenty of not-that-old hardware that will only work on previous versions of windows.
There's also _mountains_ of _terrible_ binary drivers that cause serious stability concerns.
The very same hardware somehow works perfectly fine on Linux. No kernel panics (not a single one in 12+ years of running it on Realtek crap), no intermittent connectivity problems, no weird GPU bugs, nothing of the sort.
What I mean is: I can go to the store and buy a random thing, and I can just assume there will be a driver at all and my PC will find it.
I work for a company which manufactures industrial PCs with touch interfaces, and one thing we noticed with our X86 line is that we can just stop caring about drivers. Although everything down to the touch panel and the mainboard is custom, you can just throw a windows OR a Linux (Ubuntu) iso at it and it will work 99%. This is not about Windows vs. Linux, but about PnP vs. no PnP.
(Still not reason enough for me to go back to Windows tho)
Yes it is. Let alone the inability to study the source code and other goodness of open source, there are old drivers that are not maintained anymore and that can't run on newer versions of Windows, where hardware that is not maintained anymore by the manufacturer still works on Linux because the open source driver can still be adapted to run on newer versions.
Proprietary drivers are a problem wherever they exist.
Closed source drivers are a nightmare for users.
This is all just to say, I don't think "GPL drivers" and "PnP generic images" are as separate as you're suggesting.
Some companies just flagrantly violate the GPL, and little ever comes of it.
Others ship minimal shims in the kernel, and put the proprietary bits in userland code or some such. This seems to be more common, where vendors will technically release their kernel fork, but the code will be obfuscated or just generally useless without the proprietary blob that goes with it.
I'd much rather the kernel just have a stable ABI so these kernels could at least be freely updated instead of being stuck with the hacked together fork with its proprietary shims.
Sometimes I wonder if Linus could go back and do it over, if he would license Linux under the BSD license instead of GPL. He's never seemed like a particular stickler for free software ideology, and has welcomed connections between Linux and industry. I don't know that it bothers him that much to see Linux used in proprietary software.
Not trying to start a flame war over licenses here, just speculating. And maybe this could be easily refuted by a link to one of his email rants, who knows.
So I very much doubt he would license it under BSD or similar.
Having said that, he has also stated that he is glad he stuck to GPLv2, as he is not a proponent of the TIVO clause, IIRC his words were something to the effect of 'I just want the code contributed back to the kernel'.
However, he sees things like adding it as being a pretty significant change to the GPL, and does not like the fundamentally changing the deal. If GPL v3 consisted only of wording clarifications to ensure it worked properly in more regions and perhaps to allow apache license compatibility, he would presumably have had no objections, but of course, would be unlikely to have been able to relicense the kernel, given the kernel's numerous contributors and lack of "or later version" clause.
https://sfconservancy.org/copyleft-compliance/ https://sfconservancy.org/copyleft-compliance/enforcement-st... https://sfconservancy.org/copyleft-compliance/firmware-liber... https://sfconservancy.org/news/2020/oct/01/new-copyleft-stra...
From the proposal:
> An important cautionary lesson we should draw from WSL1 is that the performance of starnix will hinge on the performance of the underlying system services that starnix exposes to the client program. For example, we will need to provide a file system implementation with comparable performance to ext4 if we want Linux software to perform well on Fuchsia.
The WSL is a revival of the POSIX layer.
"Broad software compatibility was initially achieved with support for several API "personalities", including Windows API, POSIX, and OS/2 APIs – the latter two were phased out starting with Windows XP."
Even WSL1 is technically very different from the old POSIX layer. The old POSIX layer used classic NT processes and POSIX APIs were routed in user space to NT syscalls via ntdll. WSL1 uses lightweight picoprocesses and implements the Linux syscall API in-kernel, rather than doing POSIX API to NT syscall mapping in user-space. Windows NT POSIX (and Interix/SFU/SUA) are conceptually much closer to Cygwin than to WSL1.
I wonder whether they will end up with the result of falling back to a real Linux kernel running in a VM eventually if they go with this route, as WSL -> WSL2 ended up with.
This is very, very, cool stuff. It positions Fuschia as approximate to a lingua franca OS.
https://www.kernel.org/doc/html/latest/admin-guide/syscall-u...
At the end of the day, x86 is x86. Different operating systems use different loaders/dynamic linkers, different filesystem layouts, different APIs, but still the same machine code and still the same calling conventions. WINE, in a nutshell, merely presents the Windows environment (by wrapping Linux calls in Windows calls) to an executable that is running otherwise natively, there isn't a virtual machine or an emulator involved. There is no sandbox or security (as that is a non-goal).
The problem is that various DRM and anti-cheat products use undocumented Windows syscalls to do their job, and syscalls are something that you can't just wrap with a function. This extension will allow WINE to ask Linux to send it unhandled syscalls (via SIGSYS), so that it can emulate them (making it a misnomer for the first time).
The Linux and Windows calling conventions are pretty different.
Yes, virtualized Linux is somewhat less well-integrated, e.g. at the filesystem level, but that is getting better with tools like https://virtio-fs.gitlab.io. Most importantly, it's path that others are also taking, so you can share their work. This Fuschia-specific approach won't benefit from anyone else's work.
They even mention that they're going to support virtualized Linux as well, so here they're just proposing to do a lot of extra work.
I guess Google doesn't have to care how much extra work they create for themselves.
Since the overhead of each SYSCALL is ~1000 cycles and that this overhead just keeps getting worse thanks to things like Spectre, I'd say that's a real high performance operating system you've got there Google. History shows us that developers never choose microkernels. The only reason people use the things is because big corporations force us to. Like how Intel preinstalled MINIX on its chips without the consent of its customers. Where are the early authentic Google values that technology should be simple fast and stay out of the way? Your o/s is bad and you should feel bad for all the reasons Linus explained to Tannenbaum back in 1992.
If Google was smart they would support something people love which makes perfect technical sense, like Cosmopolitan, which enables normal POSIX programs to boot as unikernels that needn't incur any syscall overhead at all. The Actually Portable Executable format is also a valid disk image that can boot on bare metal in Google's Cloud. This is perfect for our brave new world of cloud services where instances only really need sockets to talk to network services like bigtable and therefore don't care about the overhead of a timesharing system. Google created this new world, yet it fails to understand its own creation if we consider how Fushcia is dragging us into the past by resurrecting designs that were too slow even during the days where multitenancy on a single machine mattered. See https://github.com/jart/cosmopolitan and https://github.com/jart/cosmopolitan/issues/20#issuecomment-... to learn more.
Regarding Cosmopolitan, one issue is that different executables can't talk to each others efficiently because they are in separate unikernels. If they are running in the same unikernel then you have essentially zero security, unless your unikernel is actually running another kernel!
In other words, unikernels aren't great for consumer devices.
This is possible given they designed it in a micro-kernel like fashion, where things are more modular and a lot more can be done straight from the userspace without going for the expensive 0 ring barrier.
From the docs:
> Rather than running Linux binaries in a virtual machine, `starnix` creates a _Linux runtime_ natively in Fuchsia. Specifically, Linux program can be wrapped with a _component manifest_ that identifies `starnix` as the _runner_ for that component. Rather than using the _ELF Runner_ directly, the binary for the Linux program is given to `starnix` to run.
> In order to execute a given Linux binary, `starnix` manually creates a `zx::process` with an initial memory layout that matches the Linux ABI. For example, `starnix` populates `argv` and `environ` for the program as data on the stack of the initial thread (along with the `aux` vector) rather than as a message on the bootstrap channel, as this data is populated in the Fuchsia System ABI.
This is basically also how Chrome works, except that it serves otjer api's.
On Fuchsia, apparently the OS attach a binary which is a program on its own, to the binary that is executing and that in its "manifest" tell it will need a linux syscall proxy, which is this starnix that get stitched to the executable doing all calls in the same process.
On Fuchsia case this will end to be much more efficient because there will be no IPC communication involved just jumps on the code sector.
Also, just as Chrome gave them a seat at the table of web standardisation, and a chance to try new ideas that didn't have to go through Mozilla's approval process, having a kernel of their own allows them to influence the OS design space in ways that are more aligned to their business goals, and without needing Linus's approval.
I think that someone at google built fuschia for the sake of building it. Their core business is still search, that's all Android is. If they launch their own fuschia based handset, people are unlikely to switch, OEMs are unlikely to switch. It's just a failed concept.
Last I checked (years ago), the userspace was implemented partially with musl, which reads
> 'musl, pronounced like the word "mussel", is an MIT-licensed implementation of the standard C library targetting the Linux syscall API,
Now, they're announcing running Linux programs on Fuchsia. Sure seems to me they're implementing a Unix-like system, even if their kernel was written from scratch.
The BSD world doesn't consider the userspace very separate from the kernel space, it's all part of a single system.
I would argue it's very much 'based on Unix' as soon as they start adding POSIX APIs. They're adding POSIX APIs because they work.
>Fuchsia does not require that programs use libc's ABI. Programs are free to use their own libc, or to do without.
As has been said in other comments, it's not much different from Wine or Linux emulation in FreeBSD.
But I’m afraid you have to someday accept that some of Big Tech is ‘using’ Linux as a stop gap to either create their own proprietary subsystems around it or a completely new OS compatible with Android for which they pretend ‘they care’ about Linux.
They only care if it’s only for their interests as we can evidently see for Fuchsia Android support and WSL2 GPU hardware acceleration support.
As far as Big Tech, EEE is a legitimate concern.
As far as Google, they've demonstrated countless times they're not to be trusted. If someone does business with them, they are being foolish. Fortunately, outside of search and chrome, they're not very competent, so they're not much of a threat.
https://en.wikipedia.org/wiki/Embrace%2C_extend%2C_and_extin...
As to your ad hominem in the end there, perhaps you should learn to engage with a level of respect presented to you by your peers, as it is that kind of discourse does little but put on display how your harsh words are little more than a projection. A better type of conservation is expected here.
Also Linux has millions of lines of legacy that people are having to maintain and work around This claim lacks concrete evidence. The number of lines of code that are here for legacy reasons is unknown but 1 million since like an exageration. More importantly, most of legacy code is confined (does not affect non legacy code). Of course linux because of backwards compatibility has many suboptimalities and developer productivity could be higher without it, but this argument isn't enough to outweight the order of magnitude difference in human resources (and expertise (hardware makers))
with all the knowledge learned All? I think most of the fuschia devs had no significant role in the Linux kernel codebase, it's not like they had hired Greg kroah-hartman. But essentially, fuschia has not access to useful knowledge that is only encoded as comments in the Linux kernel. And the knowledge about past mistakes is lost unless you spend years reading the linux mailing lists and commit history.
Hence the economics point still stand, of course a world without my ad hominem would be better, but such an hypothetical world is precluded for as long as a community like HN is unable to see such striking NIH issues.
As for the point about Fuchsia not having knowledge because they didn’t personally build Linux, that isn’t my point. What I’m saying is that they can look at what Linux (and other OS’s) have done and skip over lots of pathways that have been proven over the last three decades to be dead ends or inefficient, while mimicking those systems and conventions that are proven to work. I’m sorry but you seem to be going out of your way to ignore the fact that Fuchsia is, whether or not you want it to be or think it should or will be.
Disclosure: I work on Fuchsia.
[1] https://www.usenix.org/conference/nsdi13/technical-sessions/...
You can see, though, large parts are TBD.
Disclosure: I wrote the doc linked above.