search

ravynsoft / ravynos

A BSD-based OS project that aims to provide source and binary compatibility with macOS® and a similar user experience.
https://www.ravynos.com
Other
5.63k stars 186 forks source link

Reconsider Linux as base #49

Closed izzimat closed 3 years ago

izzimat commented 3 years ago

With the introduction of Syscall User Dispatch in Linux 5.11, it is now possible to implement foreign system calls in a less hackish and performant manner. One example for this https://github.com/meme/limbo ( a mach-o loader and XNU syscalls translator for Linux). Of course, the benefits vs drawbacks of implementing syscalls in userspace still has to be considered.

The benefit Linux brings in terms of hardware support cannot be understated. Imagine Linux with coherent desktop experience with the ability to ride on macOS app ecosystem success. That's a winner in my book.

kettle-7 commented 3 years ago

Linux is great and all, but it has shortcomings, namely

You can ship a package, but there's a different format for Debian, Arch, Fedora/OpenSUSE/RHEL/CentOS, Slackware, and many distributions that don't have package managers. And to think of the month-long queues to get your package into something like the Debian repository...

probonopd could tell you a lot more about why Linux is not a good base for this project.

mszoek commented 3 years ago

Limbo looks pretty interesting. I suspect the team at Darling could make good use of it. I did notice it also has to emulate the BSD syscalls (of course) so I think using the FreeBSD kernel still has an edge here :)

@linuxkettle articulated the issues with using a Linux base really well. I love Linux and have used it for a long time. As a user, I love the choice I have. But as a developer it is a nightmare. You don't target "Linux": you target specific distros and all their peculiarities. For now I am going to focus my limited time on FreeBSD.

probonopd commented 3 years ago

I love Linux and have used it for a long time. As a user, I love the choice I have. But as a developer it is a nightmare. You don't target "Linux": you target specific distros and all their peculiarities. For now I am going to focus my limited time on FreeBSD.

Same here!

kettle-7 commented 3 years ago

What if we used limbo's Mach-0 loader?

kettle-7 commented 3 years ago

Also, I do agree with izzimat's compatibility point - FreeBSD can't suspend on my computer, so it sits there running all night and warming up my desk. And I can't change the brightness either, Linux does both of these fine.

mszoek commented 3 years ago

Also, I do agree with izzimat's compatibility point - FreeBSD can't suspend on my computer, so it sits there running all night and warming up my desk. And I can't change the brightness either, Linux does both of these fine.

Yeah, that's totally fair. Is it a lack of driver support?

LOL maybe we can use the Linux kernel with BSD on top like Apple did with Mach! 😂

mszoek commented 3 years ago

What if we used limbo's Mach-0 loader?

that could work. Apple's dyld is also open source IIRC.

What I would like to do eventually is write a hybrid MachO/ELF dyld which can load a MachO executable and resolve its symbols in either dylibs or ELF .so's so they would link against my frameworks without needing a second set built as dylib :) This is probably super complex but could be really cool.

kettle-7 commented 3 years ago

LOL maybe we can use the Linux kernel with BSD on top like Apple did with Mach! 😂

You may laugh at that, but I think there's a serious idea there, if we use a FreeBSD base and extend it with Linux drivers, we'll be able to get to a large number of devices (relatively) easily.

mszoek commented 3 years ago

Not sure about "easily" ... we would have to adapt all the syscalls in the C library to what Linux provides. And probably tweak some assembly code in the syscall gate. Then I think the runtime linker (ld-elf) might need some hacking to load stuff properly. Then there's the boot loader: can that load Linux? /dev and /proc are different between the two so stuff like devd would need changes. It's not at all trivial to replace a kernel.

Update: found this, which could help: https://github.com/zbm-dev/zfsbootmenu

grahamperrin commented 3 years ago

https://github.com/mszoek/helium/issues/49#issuecomment-843598774

can't suspend

If you raise this in a FreeBSD area, please provide a link. Thanks.

brightness

https://forums.freebsd.org/threads/79960/

mszoek commented 3 years ago

So. I have to admit that I'm still sort of considering this, especially after looking at supported laptop hardware lists for Linux vs FreeBSD and discovering that Firefox/BSD doesn't support things like Widevine for DRM (so no Netflix, for example). An alternate approach for hardware would be to port drivers from Linux/Darwin, but then are we stuck maintaining them all - & mostly without reference hardware? I'm not sure which avenue would be more work, tbh.

So, let's list the options:

  1. Do nothing.
  2. Add drivers to FreeBSD.
  3. Linux kernel with FreeBSD userspace.
  4. Full custom Linux distro with selected BSD-isms like pmake.
  5. Port to an existing distro & integrate with it.

I'm ruling out the full distro right away: it is way too much work for my limited time.

1 is the easiest, but leaves us with limited hardware & software support in some key areas that would result in poor UX overall. Things like Widevine might work in the Linux version of Firefox running in emulation (or maybe in the macOS version which we should be able to build someday), but the hardware problem remains.

2 would improve FreeBSD (yay) but needs an army of kernel developers and reference hardware to do the initial ports and agree to maintain them. So this is not a viable option for me to take on. And it does not solve things like the Widevine problem. helloSystem would still work.

3 is conceptually ugly but seems actually viable for solving hardware compatibility. A syscall translation layer would have to be written that converts BSD-style to Linux-style - basically the opposite of what FreeBSD has for Linux syscalls. This could maybe be a LKM. Linux compatibility in BSD should still work. Userspace is still BSD so there's less porting effort but this doesn't solve the Widevine problem either. helloSystem should still work since the userspace hasn't changed.

We skip 4.

5 is a big effort of porting the Make system and Cocoa to Linux. Our Cocoa and libobjc came from there so it wouldn't be hard - I ported them to BSD. We would not be able to use helloSystem and would have to port/re-implement all of that on $DISTRO. However, this option solves both the hardware compatibility and provides the widest selection of commercial software support. There are quite a few lightweight distros with package systems (e.g. Arch, Slackware, CRUX, Void) which don't have too much "opinion" about how a system should be which could be used.

So - tough call and more research is needed! If the Linux compat layer solves the software availability problems, then option 3 might be the best choice. Only a syscall translator and few other bits at the edges of kernel/userspace would need to be maintained (and could maybe be upstreamed). Otherwise option 5 may be the ultimate best choice: there are direct analogs of the LiveISO build script, packages, etc and most of the helloSystem components are portable PyQT5 AppDirs. However, a big downside with any use of Linux is dealing with the GPL. A second issue is that ZFS on root is reportedly problematic both from a licensing POV (CDDL vs GPL) and also reported to be sometimes unstable. But Canonical is doing it, so ... maybe OK?

Let's explore how far the FreeBSD Linux compat gets us.

grahamperrin commented 3 years ago

From Update on FreeBSD Foundation Investment in Linuxulator | FreeBSD Foundation (2021-04-09, not visibly dated):

… Looking ahead in 2021, Edward is planning to continue his work on graphical app support …

https://github.com/mszoek/airyx/issues/49#issuecomment-850876774

… Things like Widevine might work in the Linux version of Firefox running in emulation …

https://wiki.freebsd.org/LinuxApps shows google-chrome-stable-87.0.4280.88-1 working. Context:

firefox-77.0.1+build1-0ubuntu0.18.04.1 is also listed as working, however I don't know whether that's true for Widevine in Firefox.

kettle-7 commented 3 years ago

I'm in support of option 3 - we have /usr/src available and therefore could recompile the FreeBSD userspace for Linux, and use ports instead of pkg.

Canonical is doing it, so ... maybe OK?

This may be a case of might is right, if Sun were to challenge Canonical in court, it would be a close match. If they did the same with Debian, Arch or especially us, there's a clear winner, and it won't be us.

mszoek commented 3 years ago

I'm in support of option 3 - we have /usr/src available and therefore could recompile the FreeBSD userspace for Linux, and use ports instead of pkg.

I already build the base and kernel from source so that part is easy :) Just build Linux instead or pull down a kernel binary from somewhere.

Pkgs might still work but I assume we will probably want to repackage many things as Bundles anyway and have our own App Store. So maybe they will become less important?

This may be a case of might is right, if Sun were to challenge Canonical in court, it would be a close match. If they did the same with Debian, Arch or especially us, there's a clear winner, and it won't be us.

Yep. But nothing says we HAVE to put root on ZFS.

kettle-7 commented 3 years ago

have our own App Store

https://github.com/linuxkettle/AppShop :~)

I originally designed it for helloSystem but probonopd had, let's say, a different opinion on how apps should be installed. I take side with neither party, I believe that App Shop should be installable as a third-party option, which means I can port it to Linux, and eventually maybe even macOS and Windows.

mszoek commented 3 years ago

Just leaving this syscall concordance here: https://www.lurklurk.org/concordance.html

mszoek commented 3 years ago

have our own App Store

https://github.com/linuxkettle/AppShop :~)

Awesome! Could it handle compressed disk images like DMG for apps? I want to be able to distribute the app bundle plus any README/docs, other tools, etc. Installation is just dragging the app bundle from the mounted image to /Applications, then drag mounted image to the Trash to unmount.

kettle-7 commented 3 years ago

Could it handle compressed disk images like DMG for apps?

Not DMG due to portability issues, but it will use archivemount and gzipped tarballs.

I want to be able to distribute the app bundle plus any README/docs, other tools, etc.

It already supports HTML in the description, I believe docs should be linked to in the app itself, ideally under the Help menu.

Installation is just dragging the app bundle from the mounted image to /Applications, then drag mounted image to the Trash to unmount.

That's the idea, with one difference - if you mount images then you need a daemon to take care of mounting and unmounting - heard of Snap? I think regular folders will do.

probonopd commented 3 years ago

if you mount images then you need a daemon to take care of mounting and unmounting

No. See AppImage :)

kettle-7 commented 3 years ago

AppImages self-mount when run. That means that when they exit, they (should) unmount. The catch here is that the mounted folders won't show up until they're mounted.

Wouldn't it be easier if you archivemount the tarball, then the user drags the folder inside to their Applications folder - or you unzip it there so they don't have to.

probonopd commented 3 years ago

That's basically like the Mac does it. I never liked the extra step of having to drag the folder to the Applications folder. Even on the Mac I would just double-click the dmg to open the disk image, and run the application straight from there without dragging it anywhere.