RFC-0082: Runnning unmodified Linux programs on Fuchsia

https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0082_starnix?hl=en

by pjmlp • 5 years ago

94 133 5 years ago

fuchsia.dev

josteink• 5 years ago

So… Google’s plan to rid itself of GPL’d dependencies moves one step further.

At what point are we going to call out Google for doing the “popular” embrace, extend, extinguish act?

bobthebuilders• 5 years ago

Good. I believe that competition will bring more innovation to the tech sector and the stacks we use.

nousermane2• 5 years ago

There are a few Linux-ABI-compatible platforms already, and have been around for a while:

- Solaris LX-branded zones;

- Microsoft WSL1;

- Google gVisor;

- Amazon Firecracker.

None of above done anything groundbreaking (other than ditching GPL). Why would you think LX-branded Fuchsia would?

rvz2• 5 years ago

At what point are we going to call out Google for doing the “popular” embrace, extend, extinguish act?

I thought that what Microsoft did to WSL was the first indicator of Embrace and Extend of Linux. I guess Linux was always 'used' as the testing bed for the giants for creating their own closed ecosystems.

Hardly surprising that Fuchsia exists for the same reason; as I previously predicted.

izacus8• 5 years ago

You want to call out Google for embracing and changing their own operating system?

afiori2• 5 years ago

Android is also a community, but I think they are talking about GPL-aided custom ROMs for mobile devices.

dogecoinbase• 5 years ago

The actual RFC 82: https://datatracker.ietf.org/doc/html/rfc82

"Not everybody is here, so lets talk until more people get here."

A perfect encapsulation of Google's approach to standards, I suppose.

approxim8ion2• 5 years ago

I think I'll stick to using unmodified Linux programs on Linux.

choeger2• 5 years ago

Fuchsia is going to hurt humanity. If that sounds exaggerated, consider that its license's sole purpose is to allow propietary drivers and other kernel modules. In a world where google wants to have clean hands and governments want to enforce policies on computers, what do you suppose will run on your android phone in the future? That's right, a government-mandated rootkit.

Edit: Of course, I know that this is technically possible already now, but if google creates an OS with the explicit support for such a contraption, there will be an industry where companies like Samsung can buy their "legal modules" for their target markets soon.

spijdar• 5 years ago

Okay, so, two things:

There are already many similarly licensed and capable OSes, some (e.g. FreeBSD) capable of running Linux executables. Are these hurting humanity? I guess you could argue that they've enabled proprietary OSes on, say, game consoles, which could be a negative on humanity.

The second is it strikes me as absurd that the thing standing in the way of government rootkits is copyleft licensing. The power to enforce GPL style licenses lies in government -- a corrupt government can just ignore it.

You can already ship proprietary kernel components with Linux. It happens all the time. It's why you can't use "normal" kernels on most smartphone devices. And it's easy for entities like the government or Google or Samsung or whoever to run their code in, say, TrustZone, or heck, just run Linux as a guest under a microkernel. So many ways to do it, and creating an evil BSD licensed OS with the primary purpose of furthering the surveillance state just feels ... silly to me. Because they just don't need to.

Tldr; I don't believe anyone who isn't already installed rootkits on our phones is holding out until they can do it "officially" with modules for a BSD licensed kernel.

choeger2• 5 years ago

As I wrote, the problem is not the license itself (although we see more and more problematic cases with liberally licensed software). The problem is that google does it explicitly to support propietary modules better. If you don't see how removing legal, organizational, and technical obstacles to controlled devices helps this modern policy, I cannot help you. Besides, this is not about surveillance anymore, that battle has long been lost. This is about enforcement.

hutzlibu6• 5 years ago

"Fuchsia is going to hurt humanity. "

You mean the world is the linux ecosystem?

Well I disagree and I will just say, that the way I see it, Fuchsia is just pragmatic with drivers.

You cannot really force the vendors to ship open source drivers for your OS. But you can make it easy for them to write them against a stable ABI.

I would love to have a 100% open system. But because of proprietary standards and linux drivers policy, I am forced to use windows on my laptop. I rather would have a open OS and take just the proprietary drivers. Now I have to have the core proprietary and the drivers, with the alternative of messing with linux driver configs and custom kernels again. No thank you. I got work to do.

I would take fuchsia instead, if I could.

Which is open as far as I know, so I really do not see the way from here to government mandated rootkits. At least not through fuchsia.

fsflover8• 5 years ago

You cannot really force the vendors to ship open source drivers for your OS.

I wish Google did exactly that.

But because of proprietary standards and linux drivers policy, I am forced to use windows on my laptop.

How does it force you to run Windows? I don't understand. You just choose hardware designed for Linux and you don't need to care about the drivers at all.

hdjjhhvvhga3• 5 years ago

"Fuchsia is going to hurt humanity. "
You mean the world is the linux ecosystem?

No, humanity in general. There has been a decades-long battle between the powers that would love to have everything tightly controlled by the manufacturer (or a consortium of corporations with admissions for a lofty fee) and users who are aware of the advantages of open computing. It's a dividing line between actually owning a computing device and something like leasing it under certain conditions even though you paid for it. As everybody household has more and more computing device, and as these become much more user-hostile, transparency and openness is needed more than ever.

rvz2• 5 years ago

To be honest, I've been waiting for the Linux ecosystem to do something about the desktop and the phone and it seems that they can't get it as consistent as Apple. Anything Linux, Google always has to step in, hand-hold them and run with their own creation in the end.

Essentially, they 'used' Linux as a test-bed for Android and now replacing it all with Fuchsia which aims to be as consistent as macOS and iOS. Starting with the Nest Hub [0] where the user won't notice anything different, which that is the point.

Due to the mess created by the Linux distro ecosystem, the free form swapping of system components by the user and driver maintenance hell vendors dealing with an unstable kernel API, I won't be surprised to see Fuchsia overtake ChromeOS and Android even by this decade. Not surprised to see Fuchsia attempting to run existing Linux apps too.

This just makes the process even quicker and everyone is watching them out in the open in real time™

[0] https://www.theverge.com/2021/8/18/22630245/google-fuchsia-o...

nextaccountic2• 5 years ago

Linux was responsible to open countless drivers, and is the reason that I can enjoy my laptop with free drivers.

But fear not, you can still use non-free drivers with Linux!

edit: you said about chromeOS in another post. Congratulations, it uses Linux!

AnIdiotOnTheNet• 5 years ago

Arguably even Linux has given up in open drivers by allowing opaque firmware blobs.

codewiz• 5 years ago

You cannot really force the vendors to ship open source drivers for your OS.

But currently, mobile SoC vendors _are_ shipping open source drivers. They must release the source code of kernel-mode drivers in compliance with the GPL.

The problem with SoC drivers is that they're not upstreamed and upstreaming them would require major effort and specialized knowledge. SoC vendors work under intense scheduling pressure and feel the need to cut corners. In other words, this code remains outside the mainline kernel because it doesn't meet the quality bar set by Linux maintainers.

Many mobile hardware vendors don't even see value in maintaining a single kernel tree supporting all their SoCs: their approach is to freeze on an LTS kernel early in the development cycle of a particular generation and then never rebase their changes onto newer kernels. They also work mostly in secret until the new SoC is unveiled.

A stable driver API would appear to solve this problem, but actually causes huge constraints for kernel development while not solving the actual driver quality issue. GKI is an attempt to go down this path, but several kernel hackers disapprove it:

https://source.android.com/devices/architecture/kernel/gener...

johncolanduoni• 5 years ago

Do you feel the same way about Linux kernel features like eBPF and tracepoints that provide a stable ABI for monitoring all kinds of userspace and kernel activity?

varjag• 5 years ago

I'm a little more optimistic. Without external community lifecycle standards to adhere to, the factional nature of Google will make Fuchsia an ever-changing festival of APIs and implementations as their userspace is.

Long term they'll just add friction in their ecosystem.

coldtea6• 5 years ago

Of course, I know that this is technically possible already now, but if google creates an OS with the explicit support for such a contraption, there will be an industry where companies like Samsung can buy their "legal modules" for their target markets soon.

What prevents one such now?

nnamtr• 5 years ago

How are rootkits possible in Fuchsia? IIUC, drivers run in user space, don't they?

monocasa6• 5 years ago

Since it's capability based, the kernel doesn't export a list of current processes. That arguably makes rootkits easier even if they live in user space.

pjmlp6• 5 years ago

Humanity was doing great before Linux happened, it will keep doing great afterwards.

legulere• 5 years ago

Linux is already destroying the environment by making updates for most android phones impossible turning them into throw-away products.

ssth• 5 years ago

No, not linux itself though, rather it is the phone manufacturer who do not want open their kernel source code so that random developer can reuse their phone even when outside support terms.

candrews1• 5 years ago

This is typically an issue with the manufacturer of the System on Chip, such as Qualcomm, Mediatek or Broadcom.

They’ve likely done some CBA and determined that porting their existing platforms to new operating systems requires a lot of work, and it’s far easier to sell a new SOC to OEM instead!

TLDR; blame Board manufacturers and not the Linux operating system/community as a whole. Although Google is trying so very hard to decouple the Operating system from the drivers as a whole.

dmytrish• 5 years ago

It's not like Apple products fare much better on the deprecation front, although for different reasons.

solarkraft• 5 years ago

Uh, okay. They could also have made it proprietary.

adib2• 5 years ago

... caveat to Google's track record of rapid launch and subsequent deprecation of platforms...

phh6• 5 years ago

Step -1: Forbid Linux Kernel Modules for security reasons

Step 1: Require OEM's userspace drivers to use stable ABI (Android 8.0-9.0) exposed over a bus

Step 2: Require OEMs to use your way of doing secure boot chain (Android 10)

Step 3: Require OEM's kernel-space drivers to use stable ABI, and force the usage of Linux Kernel Modules (Android 11 -- we already lost the GPL here)

Step 3b: Start implementing VM support. Find a nifty marketing reason to have VMs ("Privacy Core")

Step 4: Require OEMs to use your own signed kernel (Android 12)

Step 5: Have said micro-kernel load/exec original kernel's executables

Step 5: Say that for security's-sake, it will be better of the nifty VM if its OS is a micro-kernel

Step 6: Require OEMs that your own signed kernel also runs as hypervisor

Step 7: Expose bus defined at step 1 across the VM. Use it to move various components from original kernel to the new micro-kernel, "for security reasons"

Step 8: Have said micro-kernel load/exec original kernel's kernel-space drivers (stable thanks to step 3)

Step 9: OTA kernel defined at step 4 to new micro-kernel

Step 10: Extinguished.

ducktective• 5 years ago

Would Google even care about EEEing Linux? I might be naive here but I think they have technical reasons to switch to Fuchsia which is an RTOS...

Android phones don't have any semblance of FOSS/Linux/DIY sprint in them anyway...

phh6• 5 years ago

I might be naive here but I think they have technical reasons to switch to Fuchsia which is an RTOS...

Nowadays, Linux's realtime is pretty good. Steven Rostedt has extensive documentations on how to "debug" realtime on Linux. You know what's the number one source of non-realtime-ness in Linux? It's parts of hardware that Linux simply can't control. He found that on many PCs, the BIOS triggers SMI (to refresh the RAM IIRC), and said SMI blocks the CPU.

In case you're thinking "Surely this is an x86-only mess", well, sorry, but that's wrong. It's even worse for embedded systems with shared memory bus, where modem has higher priority over the bus, and can decides to stall any memory access made by the CPU.

Switching to Fuchsia won't change much wrt real-time. (Possibly with Fuchsia, it is harder for OEMs to footgun their drivers, which would still be an improvement)

I think the reason Android would switch to Fuchsia is simply that Google is too big to rely on the community, and most engineers there don't have an opensource mind, so overall it makes it more convenient for Google to get rid of 3rd parties. Yes, it is a technical reason.

I agree that extinguishing is not Google's goal (which is why I didn't add embrace/extend). It is just a side-effect.

zeusk• 5 years ago

Fuchsia is definitely not an RTOS, it's an embedded system of sort. I had some experience with little kernel which served the basis for zircon, so I followed the project for a bit - they have no real time guarantees from what I could tell.

huibf3• 5 years ago

You forget the part where all of this was necessary precisely because OEMs couldn't be bothered to update their drivers to work with more recent versions of the kernel.

fsflover8• 5 years ago

One could require FLOSS drivers instead, so the community would have a possibility to update them later. This is exactly how it works on GNU/Linux phones, Librem 5 and Pinephone.

monocasa6• 5 years ago

I'm not sure how switching to a more permissive driver model and licence where now you won't even get the source to these drivers will make the situation better.

phh6• 5 years ago

Which kernel is latest high-end Pixel running?

Three years ago, gregkh did a presentation about LTS in Android. Guess who was using latest LTS kernels. Google? Nope. Sony and Essential are who.

Guess who upstreamed support for their phones in Linux kernel? Google? Still nope, again it's Sony.

How long was Pixel 1 supported? Ah yes, a whopping 3 years. (Same for Pixel 2 I believe). Who does better? Fairphone (circa 100 overall employees, and not many are software engineers), and nVidia.

Guess who provides major kernel upgrades? Sony (but not Google-certified sadly), and nVidia.

So far, Google hasn't shown any sign they are more capable than average OEMs to upgrade my devices.

user-the-name4• 5 years ago

Replacing an existing solution with a solution that better fits your requirements is not "Embrace, Extend, Extinguish", it's just good engineering.

Google doesn't have an obligation to use Linux. Linux doesn't offer what they need, so they stopped using it.

huibf3• 5 years ago

Most of the people who complain about stuff like this are those who run custom, degoogled Android ROMs and think they are entitled to Google's work forever.

gman83• 5 years ago

How would Google switching their platform's kernel from Linux to Fuchsia "extinguish" Linux? I'm pretty sure we'll be fine without Google.

fsflover8• 5 years ago

Google can use its monopoly position to force everyone from Android/Linux.

coldtea6• 5 years ago

How would Google switching their platform's kernel from Linux to Fuchsia "extinguish" Linux?

In that nobody would use it on mobile without continued development from Google (Android development can easily pause after say a 5-10 year transition period) and without Google apps and services on it.

At best, you'd have Samsung or some Chinese company keeping the flame alive for a short while.

After that everything now Android will be Fucscia based.

1vuio0pswjnm7• 5 years ago

DoubleClickOS

ncmncm• 5 years ago

I just wonder what is the difference between running and runnning. I didn't notice any clue in TFA.

asah• 5 years ago

Yikes, when did HN become such a bitter, hurtful community?

The HN I remember would celebrate this technical success.

oever• 5 years ago

The invention of dynamite was a great technical success.

The technical achievement here is not so special, but the implied goal (removing user rights by switching from a GPL to an MIT/BSD operating system on billions of devices) is.

izacus8• 5 years ago

Yikes, when did HN become such a bitter, hurtful community?

When reasonable people stopped commenting and engaging with bitter hateful commenters spewing bile in all the topics.

It happens sooner or later to most communities unfortunately - the toxic ranters push away any decent discussion with their ravings.

This topic is a nice example - so much wierd misinformation and misunderstanding just how Android and Fuchsia work (bot politically and technically).

jraph3• 5 years ago

> when did HN become such a bitter, hurtful community

I don't think this happened. However, since HN inception, more and more people (edit to clarify: in the general population) worry about bad uses of technical advances. This is true outside HN and it reflects in the community. Both are good things in my opinion.

When reasonable people stopped commenting

Quite the contrary. People are considering the whole picture, not merely the technical aspect of things. They are also thinking about the long term consequences and what is at stake. Technical aspects do not live in a vacuum.

I'm quite happy that people are no longer unconditionally in awe about new tech stuff regardless of what is at stake.

I actually understand people who only want to consider technical stuff less and less, as someone who is interested in technical stuff a lot. Please, think critically.

It does not mean you need to be against Fuchsia or anything. Just broaden your sight and take the time to consider whether things are done according to your values, and don't be angry against people who do.

bryan_w• 5 years ago

This is so true. Just look at the number of comments on any technical post on here (e.g. the "how to write a syscall" post earlier today) vs any post having to do google/facebook/amazon.

It's pretty clear that some people are only on this site to hate on "big tech"

jeroenhd• 5 years ago

I think from a technical standpoint, Fuchsia as a modern redesign of an operating system is very interesting.

However, from a technical point of view, the Windows kernel is just as exciting but the restrictions on the source code and its use make it very hard to build excitement in a community like this.

From a practical standpoint, the whole goal of the project is to throw out the open source system because manufacturers can't be arsed to play nice with open source. The philosophy behind it undoes a lot of the technical merit that would otherwise make it exciting.

Had Red Hat, Canonical or another such company been behind the project, I think the community would be all over it. With the way things are going, this is probably going to go down in the open source world like Darwin has: a few hackers building on top of it, but mostly everything is left up to the big corporation managing it. This is entirely different from Android, where enhancements are often built into custom ROMs made possible purely by the GPL nature of the kernel source code, enhancements that more than once made their way into the core Android project.

While I'm excited about a brand new kernel, I'm disheartened by knowing this project is a harbinger of death for large parts of the custom ROM scene. When Fuchsia appears on phones, we'll be thrown back into the days of customising Windows Mobile installs, by moving around special DLLs and copying over magical data files. Open source makes it easier to modify existing code, but manufacturers won't be running the open source version of that code.

zokier• 5 years ago

The whole tech landscape was much more optimistic place 10-15 years ago. There was a time when "do no evil" was not a joke in relation to Google. Against Google the bitterness is especially understandable considering how high pedestal they have fallen from.

the_duke• 5 years ago

There is a lot of negativity here, but for once I'm going to defend Google.

I've been using Linux on all my (non-mobile) devices for a long time, but I'm excited about the potential of Fuchsia as a general purpose (including desktop) operating system.

## Capability Based Kernel

Each process gets its own custom environment and only has access to capabilities that it receives, either ambient ones provided at startup, or passed down from other process via "RPC".

Linux has a hodgepodge of isolation solutions with different levels of abstraction, ranging from namespaces or seccomp over Docker and other container solutions to selinux, AppArmor, Firejail, Snap and Flatpak.

In short: it's kind of a mess.

The low level functionality has been steadily evolving, driven by containers, but very little of the ecosystem was built with sandboxing in mind. Most of the end-user solutions are either a leaky sieve, fringe and barely used, or a pain to use. Often all three of them.

I have a really hard time seeing the Linux (desktop) ecosystem evolve into something that can be reasonably secure. Not because of lack of technical foundations, but because of ecosystem cruft and lack of motivation.

A new open source OS with sandboxing as it's core design element can open the door to actually secure ecosystem.

## Sandboxed Drivers

In Fuchsia drivers are regular processes and only get access to what they need via capabilities.

A big part of the Linux kernel is drivers. Many of them are buggy and have potential vulnerabilities. I'd much rather have my drivers running in an isolated environment. Especially with huge drivers that no one can audit anyway (eg graphics cards - the AMD graphics drivers alone take up a large percentage of the kernel)

YES, this does allow hardware manufacturers to not open source their drivers and keep their shoddy, badly written code private instead of polishing it somewhat and upstreaming it to the Linux kernel, denying any chance of auditing or customizing them short of reverse engineering. This definitely is a problem and a step in the wrong direction, which is my biggest concern about Fuchsia.

But it is my understanding that this is already the reality on mobile devices - most of them are based on a private kernel tree with a whole bunch of closed source drivers added.

## Library and Application Model

Fuchsia apps actually work a lot like Nix(OS). Apps are retrieved from a package registry and stored in an (immutable) blob store bashed on content hashes. Libraries are also shared between applications based on those hashes, which means different versions of libraries can be present and each application can have it's own set of libs.

As a NixOS user myself, this is exactly what I want.

In addition, system facilities like drivers and even higher level ones like an HTTP client use a standardized interface (via a FIDL schema and RPC) and can be swapped and plugged per application.

This opens a few interesting doors to application design. EG: you don't need to bake in an http client, you can just have bindings to the system interface, and let the OS provide the http client for you. (or let the user chose the implementation that they want).

This also has some interesting benefits for development.

---

In general, Fuchsia with its hybrid Kernel has made some really cool design decisions that would make it a great desktop and mobile OS, even for me as a big Linux supporter.

Do I trust Google to be a good steward of an open source OS and work with the community, rather than running a mostly "source available" project? Probably not. Do I have concerns about the effects on open drivers? Definitely.

But it's still a really cool effort, and a company like Google is one of the few players with the resources to actually make a new OS happen.

jraph3• 5 years ago

But it is my understanding that this is already the reality on mobile devices - most of them are based on a private kernel tree with a whole bunch of closed source drivers added.

On mobile devices, the proprietary drivers are in user space. The kernel can be recompiled (because providers are forced to provide the source for their modified kernel), with necessary patches, which helps create alternative ROMs. This probably won't be a possibility anymore with a kernel for which you don't need to provide the source code. The drivers will probably be back in the kernel and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space.

bestorworse• 5 years ago

On mobile devices, the proprietary drivers are in user space.

So, the situation would stay the same regarding that.

The drivers will probably be back in the kernel

Manufacturers putting drivers back into the kernel would be a step back for them since it would be more work than just using them in user space given there is a stable driver API.

and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space

I think people forget that Fuchsia is more than the kernel. It comprises more things than Linux. Being based on a microkernel design, the kernel part represent just a small surface of the whole 'system interface'. All the rest is in the user space. The Android (platform) part of the system will be layered on top of this 'system interface', and will not define all the user space per se alone. This 'system interface' is well defined and documented [0] and, similarly to the Android (platform), they also have a CTS that tries to ensure that [1]. For example, the software layer implementing the product representing the Nest Hub is outside the Fuchsia platform, as will be with the Android (platform). So, a manufacturer implementing a particular feature inside the kernel, or in other component like drivers, will still result in its device having a 'system interface' at least compatible with the oficial Fuchsia one; if it's not, but offers something more, we all would be in the same situation where the provider bundles that features in closed blobs anyway.

I think Fuchsia's decoupled system architecture will make using an alternative user space not a big problem, if not even easier that it is with Android based systems.

[0] https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0... [1]: https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...

raxxorrax• 5 years ago

The danger I see is that we get the bad mobile environments on other systems like desktop. I am an embedded dev and Fuchsia could be interesting. But it isn't really something I am waiting for. I like OSS much more than I like Google. And the lack of trust is deserved in my opinion.

The advantages seem very theoretical, the lack of tooling will be a problem at first. So there needs to be more compelling reasons to use it.

kgeist• 5 years ago

Reminds of WSL1, Microsoft originally also tried to have a translation layer between NT syscalls and Linux syscalls, but ended up scrapping all that in favor of a virtual machine in WSL2 due to a multitude of problems in WSL1. I wonder if Fuchsia has solutions to the problems encountered in WSL1 or are they doomed to repeat same mistakes?

jsnell• 5 years ago

Given that the document has a section on WSL1 as prior art, they're clearly aware of the problem. It seems that they're mostly assigning the problem to NTFS not having the performance characteristics expected by Linux programs written against ext4, which seems like a solveable problem when working on a green field and can design the filesystem accordingly. Microsoft did not have that luxury.

Do you think they're misdiagnosing the actual problem that WSL1 had?

saagarjha3• 5 years ago

WSL1 also ran into issues trying to cover the breadth of the Linux API, which has considerable surface area.

roca3• 5 years ago

Yes they are. The Linux API surface is huge. Reimplementing all of it in a compatible way is a colossal amount of work, work that is neverending as Linux evolves.

If they can impose restrictions on applications, e.g. say to Android devs "you can only use this set of syscalls" and use e.g. seccomp to enforce that on Linux-Android, maybe they can get those applications to work. But if they want people to just take any Linux application and run it, they'll have to implement all kinds of crazy stuff. Take rr for example, they'd have to implement ptrace and perf_event_open and other arcane features that you really, really don't want to reimplement.

Today they're probably thinking that with some bounded amount of work they can run "90% of Linux apps" or something like that. But Microsoft thought the same thing about WSL1 and it didn't pan out, hence WSL2. It's strange to me to see Google failing to learn from that mistake.

corty• 5 years ago

WSL1 mostly had problems due to the layering violations and poor design decisions in the windows kernel and low level system libraries. E.g. filesystem functionality like "what constitutes an acceptable filename?" or "is that file locked?" is not only implemented by the NTFS driver and filesystem layer but also partly or fully by a number of higher-level system libraries. A lot of that lives on top of the windows syscall layer.

The Linux syscall layer (which is most of WSL1) lives next to, not above the windows syscall layer. But e.g. for all that filesystem access functionality, WSL1 doesn't just have to talk to the NTFS driver and generic FS layer but also to a lot of Win32 system libraries. If it doesn't, things will break. If it does, you have dependencies across layers, syscall conventions and system services. WSL1 didn't work because windows internals are a mess.

saagarjha3• 5 years ago

Earlier discussion: https://news.ycombinator.com/item?id=26104667

ThinkBeat• 5 years ago

Personally, I hope they do not develop this. I think they should do away with the entire POSIX compatibility code.

I am excited for a new operating system to emerge, that are far too few choices these days.

I would love to see tools emerge that are all from 2016 (?) going forwards without the legacy of standard UNIX tools.

It has the promise of innovation. A chance to start with clean hands.

I hope the UNIX tools are not going to be the ultimate ways of interacting with a system.

Microsoft has gone a bit of a different route with PowerShell. I hope Google will too

pjmlp6• 5 years ago

It is already WIP, https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...

goodthenandnow2• 5 years ago

They are doing this to solve the chicken-and-egg problem of booting the adoption of Fuchsia. Without Android (ie. Linux) support, there's no way to pull off Fuchsia.

roca3• 5 years ago

WSL1 -> WSL2 wasn't only about filesystem performance. It looks like the Fuschia people are going to relearn those lessons the hard way. Namely, that it is much less work to make a real Linux kernel work well as a virtual guest than to reimplement compatible Linux kernel semantics in a host-OS-specific compatibility layer, and the former has better performance too. Also a lot of the work for the former is shared with other vendors whereas for the latter you're on your own.

mwcampbell• 5 years ago

What about Illumos's LX-branded zones? Bryan Cantrill has bragged about how complete that implementation is, about how it could even run something as exotic as the 100-language quine relay [1]. Sure, Joyent (who did most of the recent-ish work on this) ended up exiting the public cloud business, but surely that had more to do with the brutal winner-take-all nature of that space than any failure of the technology.

[1] https://github.com/mame/quine-relay

roca3• 5 years ago

That Quine thing probably uses almost none of the Linux kernel API. Some of the language runtimes do some interesting things, but even fancy ones like V8 are not that challenging in terms of kernel APIs.

So I don't know anything about Illumos Linux zones, but if they run rr or docker or Firefox or WINE I'll be stunned. (Note that Firefox, rr and docker (by default) use seccomp-bpf syscall filtering which would be an absolute beast to implement in your Linux compatibility layer.)

RFC-0082: Runnning unmodified Linux programs on Fuchsia

Related Stories