This document proposes a mechanism for running unmodified Linux programs on Fuchsia. The programs are run in userspace process whose system interface is compatible with the Linux ABI. Rather than using the Linux kernel to implement this interface, we will implement the interface in a Fuchsia userspace program, called starnix. Largely, starnix will serve as a compatibility layer, translating requests from the Linux client program to the appropriate Fuchsia subsystem. Many of these subsystems will need to be elaborated in order to support all the functionality implied by the Linux system interface.
[…]As we expand the universe of software we wish to run on Fuchsia, we are encountering software that we wish to run on Fuchsia that we do not have the ability to recompile. For example, Android applications contain native code modules that have been compiled for Linux. In order to run this software on Fuchsia, we need to be able to run binaries without modifying them.
Just more signs that Google has big plans for Fuchsia. With Google it’s always difficult to assess if they’ll go through with it, but I think they intend for Fuchsia to become the base operating system across Chrome OS, Android, their smart devices like Google Home, and everything else they might one day make. The project is too wide and deep to be anything else.
This sounds rather like how WSL1 does/did things – set up a fake kernel ABI that gets passed to a userspace translation process for running on the real kernel (yes I’m oversimplifying, but the basic idea isn’t too different).
MS apparently had enough issues doing this that they effectively gave up and switched to heavily paravirtualized and integrated VMs instead. I wonder if Google is going to go through the same process, or if this is just a toy project for some Fuchsia dev to get used to the guts of the system?
I’m a little sad at where Google wants to go with Fuchsia though, as it will probably mean the final death of the custom phone ROM world, and all that goes with it (practically and ideologically).
The1stImmortal,
I didn’t think anything was wrong with the way microsoft was doing it before. By far and large linux syscalls map into windows ones. There are certain things where windows has no equivalent, like “fork” (ie “clone” syscall). But still these can be dealt with. I think that the bigger problem for MS is that linux is a moving target and linux developers have a tendency to write a lot of linux specific solutions without coordinating with the rest of the world (windows, BSD, mac, etc). As a result MS is constantly having to play catch up in order to remain compatible with linux. Not only is this a lot of work, but care needs to be take to avoid regressions in native windows subsystems. So IMHO there wasn’t a problem with the linux subsystem per say, but a VM is a whole lot easier than a long term commitment to mirror linux kernel development.
As I user, I actually prefer the original linux subsystem running directly on the host and in the same file system, but honestly I didn’t need it anyways because I don’t find myself using windows that much.
Nobody knows. Google doesn’t have a good track record for keeping projects around, but this one could be different.
It will depend on how locked down the hardware is. if Fuchsia hardware ends up being more open and easier to re-program than ARM, I might take it over android. On the other hand they could lock it down like apple does. I have no clue. I have to reserve judgement until I see it.
Linux is not so much a moving target, the kernel may change but userland remains compatible and has for a long time. MS don’t need to worry about the driver interfaces etc, since they only implement an interface compatible with the linux userland, and have their own driver layers etc.
At the source level, compatibility goes even further back – stuff written to compile on early unixes will still build and run on linux today, and most open source code builds on multiple unix-like platforms including linux, macos, freebsd, solaris, aix etc.
bert64,
The kernel has good backwards compatibility, however I was referring to the new syscalls and interfaces that are added to linux. Misc things like containers namespaces, even file descriptors, etc may not boil down other windows primitives in a straightforward fashion, yet if a linux program uses them they won’t be able to run correctly on windows. This is what I meant by linux being a moving target…the linux subsystem on windows needs to be continually updated to the latest syscall APIs.
Now that they’re moving to the VM approach it will be a lot less work to support. Although the result is less integrated.
Alfman you need to look at freebsd, blackberry and wxworks effect as well. You see that WSL1 failure is to be expected.
Lot of people have the idea that new syscalls/interfaces is the biggest failure but that only part of the story turns out to be a small part of it. First you kind of need to define new.
kcmp has been a syscall provided by Linux kenrel since 2012 only now is it usage coming popular. There can be 20 year delay between a syscall being added to the Linux kernel and its application usage coming popular. The more a system call/interface is used the more different corner cases of behavour applications can be depending on.
“”This is what I meant by linux being a moving target…the linux subsystem on windows needs to be continually updated to the latest syscall APIs.””
WSL1 write up that was not 90% of the problem. 90% of the problem with WSL1 is how much Linux stuff does not map to NT API/Windows kernel the worst cases totally mirror behavior. With this level of incompatibility WSL2 makes sense. Of course the 10% of the problem does not make it easy.
Really for something that does not have I am not compatible kernel you need to look to blackberry qnx attempt, freebsd and wxworks. So you have a compadibleish kernel are you home no.
Really its a surprise to most people how big of a lag there is between new features being added to the Linux kernel and those features coming majorly used. Cgroupv2 we are seeing on that 3/4 year lag between the kernel getting it and userspace starting to use it heavily this is short. Its not uncommon to see features added to the Linux kenrel then take a decade to come into major usage.
Latest syscall API by what define. If you mean the latest in the latest released Linux kernel that is a no. If you mean latest as in the latest syscalls Linux kernel userspace has decided to make popular usage of that is the problem. This problem is tricker than you would like.
A syscall/interface could be refined in the Linux kernel for decade before Linux userspace starts using the interface in a big way so that gives time to develop unique quirks. Of course some people will answer just implement all syscalls except that is also a no. Not all new syscalls/interface to the Linux kernel live to coming common usage. Linus rule do not break userspace does not mean you cannot remove a syscall/interface if you are the only user. Yes some stuff remained a single user being the developer for a decade or more before being removed.
https://man7.org/linux/man-pages/man2/syscalls.2.html is a good read but its only the start.
https://man7.org/linux/man-pages/man2/kcmp.2.html
This has a absolute marker of a syscall not being popular at this stage. That right glibc does not include a wrapper for it so user wishing to use it has to do it manually with limited sanity checks. This is the second killer. So that syscall you have not implemented because no body using it comes popular glibc starts using the syscall you need to update glibc to fix a security fault welcome to screwed because you can now be starting a half decade to a decade behind.
To implement every syscall/interface Linux kernel has is going to take a lot of man power and is also a never ending tread mill and you will be wasting a lot of resources that route as well. Wine project has exactly the same problem but its Windows applications on non windows platforms.
Compatibility layers bring their own level of hell to make with the fact that not all features a OS has will be used. It is surprising to most people how little of the Windows interfaces wine in fact implements because quite a bit of the Windows API/ABI nobody uses that kept there just in case because Microsoft documented it and something might use it its roughly 30-40% of the documented Windows API/ABI that has not been used outside sample code.
Freebsd/wxworks compadiblity layer for Linux binaries has found over time about 90% of Linux kernel features come into popular usage yes the other 10% end up disappearing. So implementing everything Linux kernel exports will give you a huge man power problem and flushing 10% straight down the toilet. But they have also shown once you have implemented something that a quirk in the Linux implementation that the Linux applications expect may take a decade or more for you implementing Linux compatibility layer to come aware of it this makes the process very much 2 step forwards 1 step backwards process as its very hard to say this syscall that is implemented is right.
So there is a lot of we have implemented X syscall we now need to revisit X syscall because new application Y uses it slightly different and has now showing that syscall has A behavior but we implement B behavior darn that was the behavior the syscall had when it was introduced to the Linux kernel we did not know about it because nothing we have run has used it that way before. Of course this gets a worst nightmare because the developer who implemented B behavior who might be able to convert it into A behavior can be long gone so new developer has to start from scratch to fix the problem. Yes this X,Y,A,B values here can be filled in for freebsd linux layer, wxworks linux layer, WSL1 in each case many thousands of times heading in the direction of millions. If you swap Linux kernel for windows and are doing this same text for wine is also basically the same repeating story. Compatibilitt layers are not easy its fairly much the same problem as emulators.
Most emulators of game platforms and the like have the advantage the programs are set in stone not getting updated. Emulating something like Linux or Windows the applications are getting updated so you have a moving treadmill problem space.
oiaohm,
I don’t know what you mean by failure. Obviously it works for linux, but the result is that software becomes less portable, though not everyone cares about that.
Do you mind sharing the link for the write up your are referring to?
That’s pretty much what I was saying about linux being a moving target. With respect to wine, I think win32s are a slower moving target, but on the other hand they can be complex with poorly documented side effects.
https://github.com/microsoft/WSL/discussions/4022
You will find stuff noted in different places.
–Take a look at https://mybuild.techcommunity.microsoft.com/sessions/77003 from about 18:00, the discussion of file system differences with regards to open file descriptors.–
Do note the second link no longer works but if you can find that video will give you a good run down on one of the brick walls for WSL1. Remember file system/file handles is core to Linux expected behaviors over and over again. Difference in handling of open file descriptors is a serous deal breaking problem. Attempting to implement Linux file handling logic on NT objects in that videos goes on to explain total miss match problem. WSL1 issue is not that they cannot implement syscalls core feature of Linux/Unix/BSD that everything is a file does not match the NT model that everything is a object. Also the Linux/Unix/BSD idea that a file can be deleted yet the programs that had opened it can still be accessing is also not a NT model feature. NT model is you delete something it goes away instantly. You delete something it goes away instantly that the exact property eglstreams with it buffers brought to Linux.
There is a very different permission model and behavior model between the Linux/Unix/BSD that everything is a file and the NT/VMS everything is a object.
Please note wine developers are looking at a kernel module in Linux under the idea name of ntsync to attempt to handle some of the incompatibility in the same area. The Linux/Unix/BSD file model is generally more permissive on what it allows than the NT object model allows. So wine on Linux/BSD/Mac OS is less painful with this issue than WSL1 on Windows NT object model.
90% of WSL1 major issues on github all relate to the handling difference in some way of a file handle. So not syscalls as such but a fundamental problem where the two OS kernel designs just don’t agree with each other.
–With respect to wine, I think win32s are a slower moving target, but on the other hand they can be complex with poorly documented side effects.–
That is not exactly true. One of the reasons why Valve is backing wine is to be able to sell old games that no longer work under current versions of Windows.
Linux kernel is even more poorly documented on it syscalls as well, When making something like WSL1 that is not under GPLv2 for compatibility it also means you cannot go reading the Linux kernel source as documentation. Yes fun that most of the Linux kernel written documentation is also under GPLv2. So once you restrict yourself to what you can legally look at to make a Linux compatibility layer under a non GPLv2 license you have almost no documentation at all. So wine is in a lot better position. Yes this is another fundamental problem for those attempting to improve WSL1. Making choosing to go VM with WSL2 look like the sane move.
vxworks and qnx are other micro kernel they implements it Linux compatibility in userspace and it GPLv2 licensed so looking at the Linux kernel source code is fine.
WSL1 under GPLv2 when its lacking proper separation from NT kernel its not going to fly past Microsoft legal.
Fuchsia could follow vxworks and qnx lead. You do have to remember the existence of usermode Linux as well. So making a Linux compatibility layer can be insane amount of work that most avoidable by either VM or usermode Linux. Lot of people forgot colinux and others like it that have been usermode Linux running on non Linux OS systems.
Sorry when I was typing wxworks I was meaning vxworks. Also note some reactos developers tried doing Linux compatibility like WSL1 as well with reactos being gpl license looking at Linux kernel was not a problem but also hit the fundamental differences like handling of file handles.
WSL1 and Fuchsia attempts at Linux compatibility are different classes of problems as well. I don’t think Fuchsia will have the fundamental incompatibility problem its hard enough doing a compatibility layer without that.
oiaohm,
It’s an interesting link with a fairly good representation of all sides of this issue. That it comes down to differences in file descriptor functionality is pretty much inline with what I thought. I was wondering about the 90% claim itself, and this is the only quote I could find about that:
https://github.com/microsoft/WSL/discussions/4022
I agree with his point, but the number itself sounds a bit arbitrary.
Yes, we agree on that. The syscalls have different implementation semantics that make a direct compatibility layer challenging. A lot of linux functionality gets added behind file descriptors, which is different from the way windows works. Consequently it requires more complexity to implement. Anyways, the VM requires much less work to run linux code, and that’s why MS took this path. This isn’t as good for everyone, but it is what it is.
The big question is whether the selling points for WSL1 get nullified now that MS is switching to a VM based WSL2. For me I think the answer would be yes. WSL1 was a very good alternative to having to use something like cygwin. But without the transparency of linux and windows processes running on the same host, I’m not sure what the point of WSL2 is because I’d just as readily run a full install of linux either in a VM or bare metal.
https://mybuild.techcommunity.microsoft.com/sessions/77003
Alfman its the video that has disappeared that had the break down in source of problems with Microsoft developer explain why WSL2 and why it was next to impossible to implement WSL1 to full functionality that gives the 90% problem number. I referenced that issue because someone else mentioned the video that I cannot give to you because I cannot find it online any more.
cygwin that a interesting point most of the problems that made cygwin ported applications not work right and services for unix(yes Microsoft posix layer) are the same-things that break WSL1 or result in performance breaking work around in WSL1. This is basically fundamental different that has quite a few effects.
There is a real good example of a fundamental difference.
You open file, you delete file now you write to file this works under Linux/Unix/BSD system. The file ceases to exist when it closed by all processes that have it open. Windows/VMS you open a file you delete a file you attempt to write to file error because file is deleted.
Think of the deleted file example on Linux with wine you can code delete file in the windows code to also close the file handles open to the file then when you attempt to write to that file you attempted to write to a closed handle so generate error windows application expected. So quite light overhead. Linux/BSD/Unix is generally allows more its lot simple when you have allows more to make it allow less to generate the same outcome. Its a really hard problem when you fundamental problem is the other way where the platform allows less but you need it to allow more.
On the Linux kernel mailing list ntsync idea recently from wine developers is in some of windows locking primitives they in fact allow more than the Linux ones leading to some horrible work around in wine that are not performant as well.
These are fundamental design choices differences. There were a long list of them covered in that video and how they really ruin your day from a person implementing WSL1.
There is a lot in the bug report were people are going works for me. Reality those implementing WSL in the video presentations and blogs on the topic that have either now been moved or deleted detail fundamental problems. Microsoft developers did well to get as far as they did before seeing the fundamental wall.
Remember as we move to wayland using DMA BUF on Linux this is file handles. Socket behavour is linked to file handles. Fork is linked to file handle behavior…. So having a fundamental problem with file handles and you are running Linux binaries you are in big trouble.
The problem here if you have one of these fundamental design problems in your way when doing a compatibility layer its the true elephant in the room that you can try to ignore at first with the logic you will at some point work around it. The problem here the more you attempt to work around the elephant instead of removing it more filled the room gets the less space you have and the more and more complex it gets todo things until you wake up have to solve the elephant problem somehow by removing the elephant.
Alfman there is horrible point where a VM is faster than a compatibility layer the cause of this is some fundamental incompatibility. The fundamental problem elephant with WSL1 that Microsoft developers detailed has a room you basically cannot enter without hitting the elephant because its 90% of room space.
Yes we have benchmarks that show the WSL1 problem:
https://www.phoronix.com/scan.php?page=article&item=wsl-wsl2-tr3970x&num=8
Alfman I am not saying that WSL1 could not have it place. But when you look at benchmarks you see places where WSL1 wins over WSL2 due to being able to beat VM but you also see WSL1 losing a more lot in performance to WSL2. Yes that fundamental problem elephant results in generally poor performance of WSL1.
VM Performance/Fundamental problem elephant is smaller than the WSL1 one so this results in WSL2 being generally better performing.
This generally poor performance WSL1 I don’t expect to see on Fuchsia we don’t see this with the freebsd compatibility layer or QNX Linux compatibility layer or the vxworks Linux compatibility layer. Fundamental problem=performance problems. The goal for a good performing compatibility layer is to have to lease number of fundamental incompatibility problems needing major workarounds.
WSL1 is a good example of when a compatibility layer on a OS is not going to work out well and you should consider VM design of some form instead.
oiaohm,
I saw the missing page before. I can only take your word for it, but I hope you understand why a “page not found” url does me little good when seeking clarity.
I’m sure we can list many subtle difference, but as I quoted before “Even though WSL1 might be at 90% completion with the last 10% impossibly difficult to implement, I suspect that the current 90% of functionality is actually good enough for many, many developers.”. It’s kind of why I wanted to see the specifics, but they are missing, oh well.
I don’t mean to be a pest, but rather than being told about it, it would be nicer to have a link.
That’s kind of the point I was making with bert64 earlier. It’s solvable but it takes more work and exceptions to the handlers to replicate the way linux works.
Somebody should tell phoronix.com that’s an awful way to represent the benchmarks. They usually do a good job but that circular chart is practically unreadable for me. I pray he doesn’t continue sacrificing clarity for artistic expression. At least the “mean of all test results” is readable, but it does not give a clue of what subsystems are responsible.
Going over individual benchmarks WSL 1 performs significantly better at some whereas WSL 2 performs significantly better at others. I’m afraid the reason isn’t immediately clear to me. You have any thoughts? It would be very interesting to identify the underlying culprit(s).
Something concerns me about his conclusions. I noticed that all the GCC benchmarks do terribly under WSL 1, while the single LLVM benchmark was dead even. These benchmarks are fine individually, but when you start counting several GCC benchmarks that measure the exact same bottlenecks, it biases the final totals. I don’t know whether phoenix did this intentionally, but he can change the score arbitrarily just by adding and removing more GCC compilation tests, which doesn’t seem objective. So I think there are deficiencies with phoenix’s conclusion methodology as it stands. But the individual tests are probably fair
Alfman on the WSL1 side when you look at the benchmarks you can see a clear repeating trouble maker if you understand the benchmarks.
Benchmarks doing a lot of file operations WSL1 is tanking. There is also the heavy context switch cost of windows with extras WSL1 is adding on top. There are some horrible things in Windows design with events and other things that add a lot of processing on context switches Linux kernel does not have. This is another one of the elephants of incompatibility. If a context switch is too fast is easy to add no operation instructions to add more time to make program happy but when you have the reverse its not a fixable problem without having to-do major kernel alterations.
WSL2 has a lot of the hyper-v issues. The big one processes heavy on memory allocation and free operations being slow with balloon memory in hyper-v enabled. Yes WSL2 is using balloon memory so that when Linux application frees memory with kernel it also freed on the windows host and the reverse for allocated. This is something that could be address with option to say this application needs Linux kernel give X amount memory to play with while its running and Microsoft has also since then done a few tweaks to how the balloon allocate works. Yes the result is those benchmarks doing that take a performance hit. This is possible addressable problem by giving users controls to tweak or fine tuning the balloon allocator(that Microsoft has been doing). These are not impossible class problems not like the ones WSL1 is running into.
–I noticed that all the GCC benchmarks do terribly under WSL 1, while the single LLVM benchmark was dead even.
GCC is something that is very heavy in file operations basically I/O and also is heavy in context switching so this is going to hurt WSL1 badly because it basically punching straight into WSL1 two really unfix-able defects.. LLVM does a lot more allocate and de-allocate in memory. LLVM hit WSL2 weak point that comes from hyper-v at the same time its hitting the WSL1 weak point why the benchmark is so far behind bare metal Ubuntu. This does change in newer versions of WSL2 of course it still does catch up with bare metal Ubuntu.
Alfman I guess you were just looking at WSL1 vs WSL2 the Ubuntu value in those benchmarks is important. If there is no performance problem in the benchmark WSL1 vs WSL2 vs Bare metal Ubuntu should come out close to each other. That LLVM benchmark has a huge gap between Ubuntu and the WSL offerings so there is a problem there.
In that benchmark set there were a few showing Ubuntu/Linux kernel not clocking the cpu correctly.
Please note those benchmarks I gave are getting a little old. Since then Microsoft has been able to improve WSL2 performance by altering some of the balloon memory logic big one is delaying return of memory to windows by a little bit so a rapid allocate operation after a free does not result in as many operations. Of course WSL1 performance has not improved in performance in fact its slightly worse now. Yes the Linux kernel has fixed up the cpu clocking issue somewhat.
oiaohm,
Except that’s not the case across the board.
I accept that’s your opinion, but I obviously should not take it as fact without any supporting evidence. Surely someone has profiled the system calls responsible, but given the phoenix benchmarks you and I are just guessing.
The ubuntu values are interesting but It’s not an apples to apples comparison so not all that useful. A lot of WSL2’s advantage might have absolutely nothing to do with syscalls/translation and everything to do with IO commit policy inside the VM. If we’re not careful in accounting for these differences, the benchmarks may not be measuring what we assert they are measuring. For example, say I mounted two different file systems and they had different commit intervals, if I tried to use the benchmarks as proof of which file system is better irrespective of the details like cache size and commit intervals, well that would be misleading. So I think we need more data and measurements than those that have been shared so far to identify bias.
Are there truly unfixable WSL1 performance problems? Well…maybe, but I’m skeptical of that and benchmarks alone don’t prove that something can’t be fixed especially when we haven’t identified specificity what’s responsible. If you’ve got stronger evidence though, I sure would like to see it!
–A lot of WSL2’s advantage might have absolutely nothing to do with syscalls/translation and everything to do with IO commit policy inside the VM.
Except we can in fact account for this. WSL2 is using hyper-v. Turns out hyper-v for big server deployments have been benched in insane detail in many research papers some of these are over 10000 pages of detailed reports. Using that carefully you can install a stock Ubuntu in a hyper-v with a particular configuration and get inside rounding error on benchmark results to WSL2. Those studies also tell you that configuration of hyper-v is not ideal for performance. The way the WSL2 balloon memory configuration has to be is hurting perform of some applications inside WSL2 but its also preventing a particular memory starvation problem that can happen as well if the VM is heavily allocating.
OS IO commit policy– This is the right kind of track. Think about it Linux you can delete a file from 1 application but those applications that have the file still open its not deleted. So the IO commit has been delayed for the delete. This is a lot simpler than having to emulate this.
I said file handles more than syscalls/translation for WSL1. The way Linux kernel file handles behave is very much directly linked to how the Linux IO commit system behaves they were developed basically with each other so fit each other perfectly.
Yes attempting to make a compatibility layer for one OS applications on another OS when you IO commit system design is truly incompatible you are in for performance hell in places.
–Are there truly unfixable WSL1 performance problems?
I really wish I had that video on a site I could give from the developers of WSL1 and WSL2 because they do document the defects of WSL1 and they are unfix-able in any easy way. You cannot magically turn windows NT IO system into behaving like Linux IO system without risking bring everything down on you.
futex2 work with Linux is to add feature to the Linux kernel for wine to deal with areas that wine cannot make work well with Linux kernel current design.
Compatibility layers at times require horrible in kernel redesigns. Now this is where Windows stablish ABI for drivers come back and bites. Yes to fix some of WSL1 issues would require altering the windows driver ABI that was also mentioned in that video that I cannot find another copy of.
To be correct with software almost nothing is unfixable if you can put in enough work but there is a point were stuff is declared unfixable because in the process of fix this problem you will create huge number of incompatibilities.
Linux with wine has been in a very much different place if stuff required changes all the way though the stack its been possible. There are a long list of changes to Linux and BSD kernel cores are linked to letting wine run well. WSL1 being the other way to wine if it was ever to perform well in all cases would be needing Windows kernel modifications as well some of those be kernel driver ABI breaking changes something Microsoft attempts to avoid. Yes these changes would be breaking anti-viruses/anti-cheat…. stuff so large number of upset users with applications that will not run.
If you have data you want me to consider, then you’ll have to cite it specifically, but regardless Ubuntu benchmarks doesn’t tell us that much about WSL1 versus WSL2 on windows.
I understand that is your hypothesis, but do you have any profiling data at all to support it? Your opinion is that it can’t be optimized, my opinion is that WSL1 probably can be optimized, but microsoft does not want to add the new file handling complexities to windows in order to make it happen. Still, I feel it could be done and it could be optimized if the will and resources were both there.
You don’t need magic, just code. After all WSL2 manages to do it and it is obviously running on top of the NT IO system (even though it’s not doing it directly). In principal, the same IO patterns inside the VM can be emulated outside of the VM for WSL1. All the same logic could be done on the host side and it would not be slower. I personally am not convinced that WSL1 translation logic is causing the slowdowns, I think it may be a simple case of the WSL2 VM doing more caching and possibly delaying write longer to give it an advantage. I certainly would test all of this. But again this comes back to needing profiling data to identify exactly where the differences are rather than the two of us making these assumptions.
That’s the thing, I doesn’t make much sense to even speculate about what it would take to fix it before we’ve even determined the exact cause. Just because feature “X” is slow doesn’t mean it’s necessarily a significant problem in typical applications. Rather than guessing, I’d really like to identify the specific bottleneck(s) with GCC, it might be something stupid like a build process not detecting all CPU cores under WSL1 (just as an example).
FreeBSD has had a Linux translator for a while, so there is precedence for this kind of thing. FreeBSD is also a lot closer Linux then Windows is though.
https://docs.freebsd.org/en/articles/linux-emulation/article.html
I’m pretty sure this is a way to get lots of software running now rather then later.
Flatland_Spider,
Yeah, it’s all the same idea for the same reason. Do you ever find yourself needing to use this on BSD? I can think of certain things like my UPS driver, which is a linux binary with no source…it’s unclear to me if the linux driver would work on BSD, it might…
https://www.freshports.org/devel/linux_libusb/
However I think even freebsd encounters issues with linux specific features not having a 1:1 mapping to existing kernel primitives.
https://forums.freebsd.org/threads/what-about-epoll-syscall-in-freebsd-10.47991/
https://freebsd-jail.freebsd.narkive.com/6aLbpD6A/timerfd-in-freebsd-jail
http://www.reddit.com/r/freebsd/comments/6yu4z3/signalfd_timerfd_create_missing_on_freebsd/
As a developer I have a dilemma of whether to use Linux-specific APIs at all. On the one hand I’d like to use the more portable POSIX APIs, but some things like async IO are inconsistent in linux due to deeply rooted async limitations with files in the linux kernel. Consequently the POSIX AIO implementation on linux has to be emulated in userspace using blocking threads. Alas, this scales so poorly that many of us are discouraged from using it at all and resort to linux specific APIs instead.
https://github.com/shkhln/linuxulator-steam-utils/wiki/Compatibility
Flatland_Spider Just because something has a long history does not mean its a long history of being a dependable choice. There are multi parties who have done this Wxworks, blackberry, freebsd newest being WSL1 all have not been a dependable choice.
Everyone in the FreeBSD camp admits it’s a weapon of last resort, and it should only be used as a stop gap.
My position is if the Linux kernel is needed, fire up a VM. Translation/emulation made sense when resources were more limited then they are now, and as cool as translation/emulation is, 1 vproc, 1GB RAM, and 20GB of disk space is pretty cheap these days. Putting resources towards a hypervisior are resources better spent.
Fuschia may have the advantage of only having to support a enough to get whatever software they’re trying to get running running.
Google is also large enough to be able to persuade companies into supporting Fuschia natively.
@Flattland Spider
Without knowing more about the problem I cannot say but two issues stand out. System coders can duck an issue as too complex or sometime impossible when its’ really just a question of having a proper look and taking care. The second issue is hybrid approaches. There’s nothing stopping the majority of calls being emulated while the remainder can be virtualised?
I’m not a big fan of throwing phyical resources at a problem just because it makes solving it easy. I prefer smarter code.
@HollyB
Smarter code would be ideal, but sometimes, people get a black box dropped in their lap and told to make it work.
Yes, and that is happening with modern VMs and hypervisors. 🙂
Intel and AMD have worked to accelerate VMs and reduce the number of x86 operations which require emulation and allow much more direct access to the hardware.
Other chips have had VM extensions added which allow VMs much more direct access to the hardware as well. NICs and server centric GPUs are the main ones.
Paravirtualized drivers (VirtIO) have been written to take advantage of the hardware extensions and create a much thinner surface then emulated hardware provided.
Hypervisors can pool resources, like deduplicating memory pages. Assuming security isn’t a critical concerns.
Kernels have been updated to take advantage of the paravirt drivers and to run under a hypervisor much more efficiently.
There is research into MicroVMs (Firecracker), which use very minuscule amounts of resources while being a full VM rather then a container. Although they do reuse concepts from containers.
Modern VMs can be, and are, much thinner then we think, and the BSDs putting resources into an efficient hypervisor would be the smart play.
So yes. Very little is emulated these days and most stuff is passed directly through to the hardware. Work is ongoing to VMs much more like a container for production stuff.
@Flatland Spider
I was talking about OS subsystems not VMs.
Maybe coders aren’t up to the job. It wouldn’t be the first time. Measure twice, cut once…
I think WSL1’s main problem was the speed of file operations. This was mainly due to having to emulate a POSIX-like FS on top of NTFS, and the fact that NTFS is just slow compared to Linux’s filesystems. Also process/thread creation is much slower in the NT kernel, which posed a problem for Linux software which expects to be able to create lots of short-lived processes very quickly. Although NT has very much the same kind of abstractions as Unix, there is enough of an impedance mismatch to make it a bit awkward. I don’t think Fuchsia will suffer from the same problems, since it is designed more around the Unix way of doing things.
At this point I am more intrigued by the prospect of Fuchsia (or its Zircon kernel) joining Linux and the BSDs as a third platform to build a FOSS operating system on. I hope the end product will be such that it is possible to use it for building a community desktop OS with support for Gnome/KDE/et al.
Seeing as Google does Open source with code drop development, it will never reach a community development level. You’ll get a periodic release of the Google kernel and then you will need to adapt whatever software you want to run on top. I don’t expect any meaningful community coordination springing up.
Maybe if Fuchsia will be forked into Lady’s Eardrops, it’ll stand a chance of becoming something widely usable, but then you lose the advantage of using the same thing as Google.
Managed open source can work well. It needs people to have the same goals though and trust. Problems only occur when one or either side wants everything their way all the time.
I hope that (for Fuchsia) the end product is something unique and modern and interesting; and that it doesn’t become “yet another turd floating in the sea of blah” (an alternative to Linux, FreeBSD, OpenBSD, OpenSolaris/Illumos , Hurd, … for the existing 100+ distros with minor superficial/pointless differences because they’re all slapped together from the same inbred pool of FOSS pieces).
The danger is that by providing a Linux compatibility layer they remove the incentive for anyone to write native Fuchsia software; and without native Fuchsia software you end up with “slower with inevitable compatibility problems and features that are irrelevant because nothing in user-space uses them” as a marketing strategy (likely causing the death of Fuchsia).
Note: Microsoft’s WSL was immune to this problem – because Windows already had established dominance (for desktop) there was no risk, and WSL became an effective tool to take market share away from Linux (for server/cloud, especially for Azure which is about a third of Microsoft’s revenue).
What “Linux apps”? There’s very little commercial interest towards Linux and it’s mainly just some games. The possibility of running an emulated version of Gimp or Firefox is hardly going to threaten Fuchsia’s native application portfolio.
Besides the primary incentive here is to enable running Android apps on Fuchsia. As the document states, some Android apps contain “native” code, which in this case means code native to Linux. (As the underlying platform on Android is “Linux”.)
@Sj87
I coded to be portable from day one. I don’t code anymore but when I was running Linux in dual boot as a trial which was 80% successful there was a small task I wanted to do. Over one hour later and still trying to install and make sense of the developer tools and compile whatever it is I wanted to compile I gave up. Linux “ease of use” from my point of view is designed as “take a perfect sphere and roll it in a perfect line”. Most of the knowledge of how to code or use it “insttitutional”. While help is available it’s from the point of view it’s technocratic and you still have no clue afterwards plus whataboutary and a shrug if you get nowhere. It’s succeed or fail hard. As Linux has no meaningful consumer software market it’s not a great incentive. And no it’s not because the user is stupid or can’t read manuals or is out of their comfort zone.
As for applications 99.9% of tutorials and examples out there are Photoshop. I’m not spending my entire life learning Gimp simply so I can translate between the two and I’m not a person who necessarily needs the colour spaces and other key features which Gimp does not provide.
HollyB,
The thing about portability is that it’s fairly trivial to do if you stick to more portable frameworks and/or posix APIs and such – literally just a rebuild. However it’s common practice for both windows and linux to use platform-specific APIs and that’s when things become harder to port.
Things like games are usually easier to port because their main loops tend to be highly abstracted from the OS in the first place. However if you have a GUI desktop application that’s hard coded around win32 interfaces, there’s going to be significantly more work creating abstractions and/or write conditional code everywhere.
To be fair, it depends on the specific software. When I was migrating to linux, it took some getting used to because many of the tools and conventions are different between unix and windows – it didn’t happen in a day and I had earlier experience with unix. Of course I wanted to use linux, so I made the effort, but not everyone is willing. Everyone has their own favorite tools.
Funnily enough I was never a big fan of either the gimp or photoshop. I hated photoshop’s rather ineffective use of mouse buttons compared to other software, which probably stemmed from it’s apple roots. I personally liked Jasc paint shop pro before being purchased by Corel. Photoshop obviously has huge brand name recognition, but there’s actually a lot of professional grade tools out there.
These days I’ve gravitated strongly towards vector graphic programs like inkscape because they fit my needs far better than gimp or photoshop can for things like logos and technical diagrams. It has a learning curve too, but it’s been well worth it for me. My kids also enjoy learning these programs and IMHO it’s good for them to learn.
When it comes to software, there isn’t a one size fits all.
@Alfman
Abstract early, abstract often. Use flags. Put the effort into writing your equivalent modules if needed. There. Done.
It’s not just games but the majority of applications development. In some cases you don’t need unique features. If your application will die a million deaths if you don’t use that one single unique feature provided by one function on one OS you probably don’t understand the problem. There’s nothing unique about game development and the majority of code can find use in any application. Don’t be an idiot and hardcode something if you don’t have to. Boom. Done. Don’t work in a silo and learn from real time systems, industrial systems, different industries and different consumer level businesses. Boom. Done. Don’t start from scratch every time and code a new application or new framework entirely around every single new groundbreaking must have feature which comes out. Boom. Done. Portability is a relatively small up front investment you only have to do once. I coded in a text editor to the OS API and had a page full of flags to cope with a range of OS and versions and development platforms. There are entire cross-platform development environments out there if you are lazy. There are no excuses.
Other than that can you stop undermining everything I say just so you can put on the act of sounding plausibly clever. It’s irritating.
HollyB,
Well, the reason games tend to be different is because they tend to have an in-game UI with no OS native controls whatsoever. This is what I was referring to. The primitives needed to blit an image to a screen and play a sound buffer are more generic & portable than native UIs.
I generally agree it should be done, but it isn’t something we always have control over. Very often the parameters of the project are in the hands of management. Also I’d point out that many of us are working with legacy code and don’t get the opportunity to make choices that would have made portability easier. It’s not ideal, but often times things like portability and security aren’t a priority (until they are).
Are you irritated with something I am saying specifically or just irritated that I reply at all? If it’s the former, then let me know what it is, but if it’s the later, I think I should be entitled to share my opinion on the topic just like you.
Thanks for the “sounding plausibly clever” compliment…I know that’s not what you meant but it made me laugh anyways. We could use more of those 🙂
@Alfman
.
.
Sigh. This is your point of view of game development and quick and dirty codebases developed by sloppy developers. In any case I sense you are reframing again to slide things closer to a point far away from what I originally asserted and this is getting boring. I don’t play kiss chase.
The points I made originally about portability and how to achieve portability for applications regardless of problem domain still stand. The fact I used industrial and business methods with game programming was unusual but not unique among high performance application and high performance graphics application developers at the time even if the games industry in the main produced quick and dirty throw away code on a title by title basis. While not optimised for games specifically it’s not impossible to build a game off the code for any scenegraph and vice versa. The difference between a GUI application and full screen window application is very small as makes no difference. You can slap in and rip out interface code to your hearts content and this will be 1% of critical logic at most, implement your own GUI or slap a graphics surface on a GUI SDK surface. It makes no odds. The focus on GUI and frambuffer is a complete distraction from discussing portability so please don’t tell me my job.
HollyB,
I’ve responded with my own opinion about the points in your own posts, that’s all.
Just know that my comments are aimed at your personal work.
I contest this assertion, the more native APIs you are using, the more difficult porting will become. In a lot of business applications the UI can be a significant portion of the coding effort due to complex states and functionality being coupled to windows in the form of windows specific event loops, windows specific messages (WM_PAINT, etc), windows specific controls, windows specific functions like GDI, etc. All of that stuff has to be ripped out and reimplimented. This is not only time consuming, but you may miss things and end up with unwanted differences (controls don’t align like they used to, etc). Games will typically have way less platform specific code owning to the fact that their UI is usually already self-contained. They need very little OS-specific functionality beyond simple things like blitting it to the screen. There may be some exceptions of course, but I don’t see a reason to deny that this is generally the case with most games.
I wouldn’t dream of telling you your job, but I think I have made a compelling argument why there can be a difference in practice.
Oops, sorry I didn’t mean that. To clarify, I meant my comments are not aimed at your personal work. Obviously I know nothing about your personal work and I hope you can appreciate the comedy of my error, haha 🙂
The commercial interest in Linux is primarily for server and scientific use – things like MySQL, web servers , NAS, MATLAB, etc. This is why Linux dominates for server and HPC. For Google; almost everything they do internally (Google File System, search, spam, marketing data analysis, …) is built on Linux. For Fuchsia developers, they use Linux for development tools (build servers, revision control, etc).
Note that none of this is “apps”. Native Linux apps either suck or get ported to something with market share (FireFox, LibreOffice, GIMP, Blender, … – all ported to Windows and OSX).
No; that’s just one throw-away example not the primary incentive; and as an example it doesn’t actually make sense (Android uses a heavily modified fork of Linux, so for Android apps they’d really want Android compatibility not Linux compatibility per se). Of course if their goal is for Fuchsia to dominate the smartphone market (and replace Android); then their best bet is to force people to write native code plug-ins for Fuchsia by refusing to provide any Android compatibility layer (and not just because an Android compatibility is likely to be abused by malware to bypass Fuchsia’s security enhancements).
Nothing you said seems to make much sense.
Linux-compatibility is a prerequisite for supporting the whole Android system. Google’s kernel-level patches don’t change the way Linux applications work, they deal with kernel internals.
Linux is “patched heavily” between every single kernel release yet never affects user-space apps. Duh!
Obviously when a Google dev says they want to enable Linux support to pave way for supporting Android apps, I believe him more than some random guy who begs to differ.
Firefox has never been “ported” to Windows — already the initial 0.1 release supported both Linux and Windows. It isn’t a Linux app per se anyway; I only referred to it as one because I was talking about running the Linux version of Firefox on top of another OS via the Linux emulation layer that is being discussed in this thread…
You need to do some basic research. Start here: https://developer.android.com/guide/platform
As you can see the majority of “the whole Android system” is built on top of Java. The problem is that a few rare apps have plugins (likely via. Java’s native interface – see: https://en.wikipedia.org/wiki/Java_Native_Interface ). They are not native Linux apps (and do not depend on the same “/proc” or package manager or udev or systemd or anything you’d find in any normal Linux distro). Instead they’ll depend on Android’s user-space (and file system layout and …). The kernel API may be the “same” (if you ignore major differences in scheduler, etc), but only a fool would think that matters.
Firefox began as a fork of Mozilla (which came from Netscape) – the initial Firefox release was just a continuation of code that had existed for a decade or more.
My point is that there’s no “killer app” to convince people to use Linux for desktop. They’ll switch to OSX to use photoshop, or they’ll switch to Windows to use MS-Office, but they won’t switch to Linux because they can just install every app they might care about on Windows and not bother.
sj87,
Even though android uses linux, most android apps are not directly exposed to it in any way so in principal it should be very easy to switch out for another OS.
As a linux developer, at one point I wanted to get linux software working on android, but it just wasn’t the same. The linux kernel itself is compatible, but the user-space is completely different so I had to relegate myself to the fact that linux software isn’t compatible with stock android.
If the reporting is true, fusia would be an extremely easy target for linux devs to support, certainly much easier than android. I’m sure android (aka java) support is easily feasible, but after all the legal trouble google has had with oracle I don’t know if there is a legal motivation to switch.
Fuchsia might end up having a lot of merit, but I am cautious until we see how restrictions & vendor locking play out.
Alfman, Brendan
I understand you didn’t read the documentation so you’re talking nonsense due to not understanding the scope of things.
The spec draft for supporting “Linux apps” on Fuchsia only deals with kernel system calls as well as a filesystem abstraction implicitly exposed by those syscalls.
The only motive mentioned in the spec is to support Android apps that have native Linux code bundled in.
This project isn’t about allowing one to execute a FOSS desktop stack on top of Fuchsia, hell no.
I guess Thom shouldn’t just pull random notes out of his a… mailing lists with no understanding of the context, when he doesn’t even bother reading them for himself.
sj87,
Did you read the rest after the summary??
Read it again…
Sure android applications containing native code is mentioned, but this is only one possibility. POSIX compatibility is specifically mentioned, which would add compatibility for loads of preexisting linux software and libraries. I’m pretty sure that is what they are talking about quite literally.
I don’t know what google’s plans are for Fuchsia to be honest. Will they create a full desktop stack? I don’t know, but then I never claimed they would either. There’s no reason they couldn’t do it. But I would say, based on their own documentation, that yes they do plan on supporting POSIX compliant linux ELF binaries. That sounds good to linux developers like me. To be clear though it remains to be seen whether I’ll actually approve of Fuchsia.