Ed MasteDigitalOcean: You haven't used our services in a while... "no matter what roadblock lies in your way, we’re here to help."
Me: My roadblock is that you stopped offering #FreeBSD images.
DigitalOcean: You can bring your own image!
Me: BYO images require ext3/ext4, which are not native FreeBSD filesystems.
Neal Gompa (ニール・ゴンパ) 
@emaste Why doesn't FreeBSD support it?
@Conan_Kudo The FreeBSD kernel does support ext3/ext4, but we have no tooling to build VM images on an ext3/ext4 filesystem, I'm not sure it's been tested as a root fs, the loader most likely doesn't support it, etc.
@emaste I assume it could be tested and made to work. DigitalOcean isn't the only provider with restrictions like this. It may be useful to do consider supporting it properly in FreeBSD...
Autolycus 🏴☠️@Conan_Kudo @emaste The only benefit of supporting ext in FreeBSD that I can see is mounting drives. It would be silly to use it for the root fs.
Scott Williams 🐧@autolycus @Conan_Kudo @emaste Back when I ran FreeBSD, the issue was that ext3/4 are GPL and not license compatible with the FreeBSD kernel, which to your point, is why there is limited mount support but not kernel level rootfs support. At the time at least, Linux wasn't great at ufs support either. Getting FreeBSD and Linux to directly share files was much more annoying than I expected it would be.
@vwbusguy @autolycus @Conan_Kudo #FreeBSD includes a BSD licensed ext2/3/4 implementation and there's no fundamental reason an ext3/4 rootfs is impossible.
@emaste @autolycus @Conan_Kudo Yeah, but last I checked it was very basic and didn't support journaling. Let me put it another way to illustrate the point: Why isn't zfs in the Linux kernel?
Neel Chauhan@emaste @vwbusguy @autolycus @Conan_Kudo You could use UFS for boot and ext4 for the system, would that work?
@neel @emaste @autolycus @Conan_Kudo I've been out of the #FreeBSD game for a several years, but last I checked, the driver was incredibly basic and didn't support journaling, so it wasn't really safe beyond read-only mounts (the reverse was also true for ufs on Linux). There's also no generally practical reason to do this on FreeBSD instead of supported filesystems like ufs, zfs, etc. Blindly reverse engineering Filesystems isn't trivial, especially with high risk for data loss.
@neel @emaste @autolycus @Conan_Kudo And yes, it is ironic that zfs's license isn't a showstopper for FreeBSD, but Linux's GPL is a conflict both ways (to be clear, I squarely blame Oracle for this wrt zfs). But openzfs via fuse on Linux is more developed and robust than the ext driver in the FreeBSD kernel.
@neel @emaste @autolycus @Conan_Kudo IANAL, but someone could also fork FreeBSD, license it under GPL, and hack the Linux ext drivers to work with the FreeBSD calls, but this goes against the ideology of much of the BSD community. Distributions might also possibly relicense their Linux kernel version to GPLv3 and ship zfs, but that might break the ability to contribute and changes back to the upstream kernel, which goes against much of the Linux ideology. Again, IANAL.
@vwbusguy You don't need to fork #FreeBSD. You can just port it and add it to the FreeBSD ports collection. See for example the #VirtualBox kernel module, emulators/virtualbox-ose-kmod
Bartek Jasicki@vwbusguy @neel @emaste @autolycus @Conan_Kudo You don't need to hack #FreeBSD, it has implemented Linux calls too, on BSD license. 😀 It is called Linuxator. So, ext drivers should work with FreeBSD, same as it is done with Wi-Fi and DRM drivers. All of them are "rip-offs" from Linux.
License also isn't a problem. Even FreeBSD kernel still has some code with GPL.
@thindil Linuxulator provides Linux syscalls for linux (userland) binaries, LinuxKPI is the implementation of a small set of Linux kernel interfaces for use by drivers.
Felix Palmen 📯@thindil @emaste Please understand that a #syscall is something completely different than some other, in-kernel, call. A syscall is the special way userspace can call something in the kernel, which needs a context switch. Some architectures have special CPU instructions for syscalls available, on other architectures, software-interrupts (that the kernel can handle) are used, etc.
Nothing of that is done for in-kernel calls, they're "just" function calls.
#FreeBSD #Linuxulator provides a set of #Linux-compatible syscalls. The #LinuxKPI project on the other hand aims to provide in-kernel Linux compatibility for use by certain drivers. They're completely unrelated.
BTW, you're missing a syllable, it's spelled LinuxULator 😉
@zirias Thank you for the correction. ☺️ Yes, I need to work more on my typing skills, especially in the early morning. 😀
@thindil Haha, that was just a gentle hint 😉. But I think it's really important to understand the difference between #Linuxulator and #LinuxKPI, although you're certainly right, *both* were further improved/extended in #FreeBSD 14.
BTW, I'm pretty sure there is *no* GPL-licensed code in the kernel. There is some GPL-licensed code in base, yes, but you can build base without it; the goal is always to provide a full BSD-licensed OS.
In fact, if I'm not mistaken, remains of GPL-licensed files in LinuxKPI are the main reason we still have drm-kmod drivers as a port (and not integrated with the base kernel), where this port includes these small parts of LinuxKPI. The drm drivers themselves are not GPL-licensed.
@zirias Any correction is always good. At least for me, I can learn something new. 😀
While in kernel there shouldn't be that code, I think I saw something to rewrite on the base system list. I didn't check recently.
DRM as port, I think there can be another reason. Its development isn't synchronized with the kernel development cycle. Having it as a separated port allows upgrading it without upgrading the whole system. Plus, there are other modules served as ports, without license problems.
@thindil 1. yes, as I said, #FreeBSD base had (and probably still has? I don't always follow it that close...) GPL-licensed parts. But they can never be absolutely required, you can build a working base without them, so anyone *can* have a "BSD-style" licensed OS from FreeBSD and do with it whatever a BSD license permits.
2. This reasoning about DRM in a port is often cited, but not really proven in practice. These drivers *need* #LinuxKPI, which *should* be part of the kernel (and largely is, the separate module only has GPL-licensed parts and it's ongoing work to replace them). So, you have a dependency on the LinuxKPI in the FreeBSD kernel anyways, you can't just use DRM drivers from some newer #Linux version. Therefore, the drm-kmod port is already a metaport, selecting the specific port based on the FreeBSD version you're running.
@zirias 1. I agree on this point. 😉
2. By "not-synchronized" I mean it is developed by different group of people, for different target (Linux). It is not just a different release cycle. Also, DRM isn't necessary in most cases. For example, Nvidia uses it only for Wayland, not for X. I don't know about AMD/Intel GPUs. I believe, there are several reasons of that situation. Reason: "if it works, don't touch" perhaps too. 😂
@thindil Well, one of the devs who is most active in that area told mit it's his goal to get drm-kmod back into base kernel, because it would remove quite some maintenance pain. And the ongoing efforts to replace GPL-licensed stuff (what's left right now is really minimal) are probably done for exactly that goal. That of course doesn't guarantee it will happen any time soon.
But remember where we came from: #FreeBSD 11 *did* have drm-kmod in the base kernel. It was very aged. It couldn't be updated because we didn't have the necessary #LinuxKPI bits and pieces. So, the "solution" then was creating that port, which could include lots of GPL-licensed code without creating a licensing problem for base.
@thindil BTW, that all said, I *do* agree that it's questionable whether GPU drivers that will only be needed for Desktop/GUI usage *should* be in base at all! After all, although #FreeBSD explicitly supports #Desktop usage, nothing else necessary for it is part of base.
But then, that's a different discussion. If it would be easier to maintain drm-kmod as a part of base, this will probably happen eventually...
@zirias Indeed, we will see. 🙂 Currently, the most important is, that it works. Sure, it requires more work during installation, but later it isn't so bad.
I prefer having a small base system. But that is just a matter of taste. 😉
@thindil @neel @emaste @autolycus @Conan_Kudo Technically true, but it seems to all be /sys/contrib and primarily device trees. Nothing under /sys/fs (where the ext driver lives) as far as I can tell, except to note that there are a couple of "cddl" named folders specifically for CDDL code, but I don't see anything similar for GPL.
@vwbusguy @thindil @neel @autolycus @Conan_Kudo
see sys/gnu: in there is gcov and a bwn (Broadcom WiFi) phy
@emaste @thindil @neel @autolycus @Conan_Kudo FWIW, Those are in process of being rewritten to BSD licensed code: https://wiki.freebsd.org/GPLinBase
You can personally, legally probably make it happen, but there is an ideological difference beyond the legal difference. I look at this GPL inclusion like Fedora packaging proprietary Intel firmware. It's a exception rather than the rule for the sake of practicality, but not at all an ideological opening of floodgates.
probono@thindil From what I have learned, GPL code _is_ a problem in that it prevents certain GPU kernel modules from being shipped in/alongside the FreeBSD base. But I've heard that said GPL code is in the process of being replaced by BSD licensed code.
@Conan_Kudo @probono @thindil Dual GPL/MIT (or even just MIT) for a driver makes a lot of sense for a hardware vendor, if your goal is to sell as much hardware as you can while writing as little software as possible.
@emaste @Conan_Kudo @probono My bad wording about "not a problem". 😉 GPL is compatible with BSD license but of course more limiting. That's why it can be used as a last resort. And true, #FreeBSD is rewriting all the GPL code into the BSD equivalent of it.
@vwbusguy @emaste @autolycus @Conan_Kudo
However, nowadays I run Fedora as a desktop and a mix of Fedora/Rocky as a server, using Fedora for my Mac Mini M1 server and Rocky on x86 servers.
FreeBSD doesn't work well with any nice hardware. OpenBSD does but has slow graphics.
drm-kmod is 2-3 years behind Linux and OpenBSD, and AX211 Wi-Fi is stuck at 802.11a when everyone else had 11ac/ax. FreeBSD is nonexistent on M1/M2 but not Linux/OpenBSD.
However, nowadays I run Fedora as a desktop and a mix of Fedora/Rocky as a server, using Fedora for my Mac Mini M1 server and Rocky on x86 servers.
FreeBSD doesn't work well with any nice hardware. OpenBSD does but has slow graphics.
drm-kmod is 2-3 years behind Linux and OpenBSD, and AX211 Wi-Fi is stuck at 802.11a when everyone else had 11ac/ax. FreeBSD is nonexistent on M1/M2 but not Linux/OpenBSD.
@vwbusguy A lot of work has gone into the FreeBSD ext2/3/4 implementation. ZFS via FUSE on Linux vs ext2 on FreeBSD from years ago isn't really a fair comparison (I'm also not sure there's any reason to use FUSE rather than native OpenZFS on Linux), but in any case it doesn't matter for this -- DigitalOcean says custom images are required to support ext3/4
@neel seems like it probably would, but still needs a lot of work to add support to our image build tooling and then test the result.
We build images via makefs, a userland filesystem creation tool, and it supports cd9660, UFS, and ZFS. We'd either need to add ext2/3/4 support to it, or (more likely) change the build to use the equivalent tool from the Linux world, or build another way altogether.
@Conan_Kudo @emaste Not just FreeBSD, but DigitalOcean doesn't even want Windows shops.
Windows Server is used by too many companies, doesn't DO want a share of the pie? Yes, most Windows shops use Azure, but enough use other clouds too.
Windows Server is used by too many companies, doesn't DO want a share of the pie? Yes, most Windows shops use Azure, but enough use other clouds too.
@Conan_Kudo it be made to work, certainly. It's just not worth a lot of effort when there are several other providers to choose from that have similar pricing and quality and support FreeBSD natively