general/other Will FreeBSD eventually migrate from CentOS to Ubuntu for its Linux emulation?

I was just wondering if FreeBSD will eventually migrate away from using CentOS libraries for its Linux emulation. The LinuxJails wiki instructs how to set up an Ubuntu chroot for running Linux software, and I have had far more success running Linux software under an Ubuntu chroot, and with far less effort, than I ever had with manually downloading RPMs from a CentOS mirror, installing them, and hoping that it would work only to find all too often that a new enough version of the library didn't exist in CentOS 7. Not to mention that there's no easy way to uninstall a manually installed RPM.

It seems like migrating to use of an Ubuntu chroot and just using apt, or perhaps some FreeBSD frontend for the sake of integration, to handle installing software would not only be far more convenient for end users of FreeBSD but far less of a maintenance burden for the FreeBSD team as well.

It seems like this is the direction that things are headed in already, and the LinuxJails work is just the initial testbed, but I haven't seen any public discussion about what the actual plans for the future are. Has anyone heard anything, or does anyone who's actually involved in this work know anything they can share?
 
Yes. That's the tool used in the LinuxJails wiki I mentioned above. It's what I used to set up my Ubuntu chroot. I'm just wondering if this is eventually going to become, in some way, the default way of handling Linux software on FreeBSD -- though perhaps with more integration with ports and packages.
 
I'm not sure it's a good idea at all to recommend using rpm with the userland in /compat/linux. I know this is documented, but IMHO, if you want to use a separate package manager, you should do so in a jail to avoid problems.

The idea of /compat/linux is to provide a stable Linux userland that works fine as an overlay and with FreeBSD's Linux emulation. Ports of Linux software build upon this, so you shouldn't need anything other than pkg. That said, Centos was an obvious choice given the very long term support it provided. Now that this seems to change, I assume FreeBSD will switch to a different userland, and Ubuntu might be a choice (although its LTS is only half as long as Centos' was). Note I'm in no way related with Linuxulator ports/packages (other than maintaining the MakeMKV port, which just needs these ports), so I don't know the current direction of discussions. In any way, the maintaing effort won't be less, as you can't just install a .deb package to /compat/linux; it must be repackaged and some minor changes are needed.

In a nutshell: If you want to deviate from the official Linux userland in /compat/linux for whatever reason, use a jail … that's the safe choice.
 
I'm not sure it's a good idea at all to recommend using rpm with the userland in /compat/linux. I know this is documented, but IMHO, if you want to use a separate package manager, you should do so in a jail to avoid problems.

The idea of /compat/linux is to provide a stable Linux userland that works fine as an overlay and with FreeBSD's Linux emulation. Ports of Linux software build upon this, so you shouldn't need anything other than pkg. That said, Centos was an obvious choice given the very long term support it provided. Now that this seems to change, I assume FreeBSD will switch to a different userland, and Ubuntu might be a choice (although it's LTS is only half as long as Centos' was). Note I'm in no way related with Linuxulator ports/packages (other than maintaining the MakeMKV port, which just needs these ports), so I don't know the current direction of discussions. In any way, the maintaing effort won't be less, as you can't just install a .deb package to /compat/linux; it must be repackaged and some minor changes are needed.

In a nutshell: If you want to deviate from the official Linux userland in /compat/linux for whatever reason, use a jail … that's the safe choice.
There´s Almalinux that is supposed to continue where CentOS stopped, it´ll be probably a safe choice.
 
Once upon a time you could pick from various different distributions. Not sure why they all disappeared, probably because of a lack of maintenance on them, which caused them to go stale.

emulators/linux_base-debian # Debian based
emulators/linux_base-f10 # Fedora, including f7, f8 and f9
emulators/linux_base-fc9 # Fedora Core, including fc3, fc4, fc6, fc7
emulators/linux_base-gentoo-stage1 # Gentoo based, including stage2 and stage3
emulators/linux_base-rh-7 # RedHat based
emulators/linux_base-suse-9.3 # SuSe based
 
Once upon a time you could pick from various different distributions. Not sure why they all disappeared, probably because of a lack of maintenance on them, which caused them to go stale.
It's a lot of maintenance work for even a single of them, so …

There would be another alternative: Not using a distribution at all. It's perfectly possible to bootstrap a GCC-based toolchain targeting Linux on FreeBSD – BTDT. Building upon this, it would also be possible to build all packages for Linuxulator from source :)

But then, as I've been told on IRC as well, nobody wants to maintain all this. It would basically mean to do all the work a Linux distribution is doing yourself ;)

edit: It would have advantages. You'd end up with a "clean" build for all Linux stuff, and ultimately, it should be possible to add Linux "flavors" or "slave-ports" (whatever would be better suited, just thinking loudly here) to almost any port. But then, somebody would have to do all that work, so, will never happen anyways :)
 
There would be another alternative: Not using a distribution at all. It's perfectly possible to bootstrap a GCC-based toolchain targeting Linux on FreeBSD – BTDT. Building upon this, it would also be possible to build all packages for Linuxulator from source
One of the reasons these ports existed was so a port could depend on them. If you take that registration away there would be no way to consistently build all other linux-* ports that require a linux_base and additional Linux libraries/dependencies. This would effectively remove all Linux based ports (and as a consequence their packages).

But then, as I've been told on IRC as well, nobody wants to maintain all this.
That was sort of my point. I see a lot of new users wanting all sorts of things but nobody wants to do the actual work. Ports don't magically appear and keep themselves up to date. Someone has to put in time and effort, in some cases even a lot of time and effort.
 
One of the reasons these ports existed was so a port could depend on them. If you take that registration away there would be no way to consistently build all other linux-* ports that require a linux_base and additional Linux libraries/dependencies.
I think you misunderstood me. The alternative would be to build these ports (of course including linux_base) from source, instead of repackaging whatever some distribution has to offer. This would give some advantages (e.g. some port would exist providing the cross-toolchain needed to build Linux binaries for FreeBSD), but as it amounts to all the work a Linux distribution is doing, I wouldn't expect it to ever be done. Just wanted to mention it is technically possible ;)
 
This would give some advantages (e.g. some port would exist providing the cross-toolchain needed to build Linux binaries for FreeBSD), but as it amounts to all the work a Linux distribution is doing, I wouldn't expect it to ever be done. Just wanted to mention it is technically possible
Don't know if you've ever tried to build, let's say RedHat from source? We're so frigging spoiled with our source and ports tree, you just make and everything happens automagically. Building RPMs on RH or DEB files on Debian/Ubuntu is a horrid experience. Technically possible, yes. Easy to do? No, not by a long shot.

So why put in all that effort (with the additional risks of breakage) when you could simply "massage" the original distribution RPMs, Debs, or whatever other format is common, and force it into /compat/linux.

That said, and maybe answer the original question, there may be a shift happening. I have no insights into what the devs are doing, but seeing CentOS basically got shafted since RedHat took over, it might be time to switch to a different linux_base. And if I look at non-open source packages that are available the primary focus seems to have shifted from RedHat based to Debian/Ubuntu based. RedHat/CentOs packages appear to be an afterthought nowadays.
 
Don't know if you've ever tried to build, let's say RedHat from source? We're so frigging spoiled with our source and ports tree, you just make and everything happens automagically. Building RPMs on RH or DEB files on Debian/Ubuntu is a horrid experience. Technically possible, yes. Easy to do? No, not by a long shot.
You'd never use any distribution-specific package building foo when doing THAT, of course. Just plain ports framework and vanilla source, using a compiler you built as part of a GNU toolchain targeting Linux.

And that, yes, I've done that before. It was once necessary when the linux-c7-devtools were "broken" by creating binaries requiring a version of libstdc++ that linux_base didn't have to offer, so all I could do was temporarily resort to bootstrapping the toolchain myself. You can admire the mess here (up to line 216): :D
Note however that it's not as messy any more with a more recent GNU toolchain, but I needed one matching what linux-c7 ports were shipping :)

So why put in all that effort (with the additional risks of breakage) when you could simply "massage" the original distribution RPMs, Debs, or whatever other format is common, and force it into /compat/linux.
In a nutshell, a simple way to add more Linux packages. Something you want to use needs, e.g. ffmpeg? Sure, add a Linux flavor to this port and install it ;)

No, I' not saying it's worth the effort (and I definitely won't do it). But it would be nice ;)
 
I actually assumed the CentOS userland port was purposely incomplete but just good enough to bootstrap another such as the mentioned debootstrap, yum or (presumably) pacstrap.

I wonder how difficult it would be to maintain a tiny "Linux from Scratch" style set of binaries, just competent enough to bootstrap a proper distro. Much of this could be from busybox really.
 
I actually assumed the CentOS userland port was purposely incomplete but just good enough to bootstrap another such as the mentioned debootstrap, yum or (presumably) pacstrap.
I don't think so. There are ports of Linux software in the tree, and they depend on the linux-c7 packages. And there's a lot more in linux-c7 than required to run some distro bootstrapper for installing a jail.

I wonder how difficult it would be to maintain a tiny "Linux from Scratch" style set of binaries,
Not exactly "difficult", just a lot of work. Although our nice ports framework would sure be of some help ;)

just competent enough to bootstrap a proper distro. Much of this could be from busybox really.
Having the above, I'd really prefer to add Linux "flavors" to existing ports. When you've gone so far, why use some Linux distro at all?
 
Yeah, makes sense. Though;
Having the above, I'd really prefer to add Linux "flavors" to existing ports. When you've gone so far, why use some Linux distro at all?
I can't quite think of any specific port where we might like a Linux flavor to be fair. Usually Linux is a fallback when we don't have the option of a native FreeBSD version (proprietary, non-portable, drivers, etc).

Perhaps some games like Quake 2* where the Linux flavor might have some more mods available?

Of course the NVIDIA driver could be a good candidate for a flavor. It was a little mad that Linux compat was the default when it dragged in the entirety of a centos userland.

* Specifically 2 because Quake 1 and 3 solved the portability issue with QuakeC and Q3vm/lcc respectively.
 
Don't know if you've ever tried to build, let's say RedHat from source? We're so frigging spoiled with our source and ports tree, you just make and everything happens automagically. Building RPMs on RH or DEB files on Debian/Ubuntu is a horrid experience. Technically possible, yes. Easy to do? No, not by a long shot.
I have used source RPMs, yes, but not extensively. On the other hand, building stuff on Gentoo was fairly easy. Maybe it still is.

I wonder how difficult it would be to maintain a tiny "Linux from Scratch" style set of binaries, just competent enough to bootstrap a proper distro. Much of this could be from busybox really.
And how useful would this be? One of the problems with Linux is that there is no such thing as Linux. Every distro layers its own set of patches over even the most fundamental things, like glibc. There would be no guarantee that this Freebsd-flavored Linux would run the Linux binaries you're interested in.

And which binaries are you interested in running? If it's mostly desktop software, you should probably choose Ubuntu as the base. If it's server-side stuff, the most likely choice nowadays is probably Alpine because it's the distro most often used in Docker.
 
I'm thinking of dependencies. E.g. last time I tried (and, failed) to run Google Chrome, the linux-* ports were missing a lot of them ;)
Hah, yeah good point. I didn't consider all those thousands of little ratty libraries.

And how useful would this be? One of the problems with Linux is that there is no such thing as Linux.
That was pretty much my reasoning. Rather than following the ever changing crazyness of a specific distro like CentOS, Debian, Ubuntu, Fedora, etc which no-one can keep on top of. Instead have a minimal skeleton framework of binaries (not even considered a usable base) and then use the typical tools debootstrap, yum, pacstrap as you would in other minimal busybox environments (i.e Android).
 
That was pretty much my reasoning. Rather than following the ever changing crazyness of a specific distro like CentOS, Debian, Ubuntu, Fedora, etc which no-one can keep on top of. Instead have a minimal skeleton framework of binaries (not even considered a usable base) and then use the typical tools debootstrap, yum, pacstrap as you would in other minimal busybox environments (i.e Android).

Well, writing these lines under an emulated Devuan running Ungoogled Chromium (I wish so much this could be done native), I got Ubuntu, Debian, Devuan and CentOS running without much pain at all.
If you know some pitfalls of the deb based distro's, ending up editing 1 file and even apt was happy and didn't complain anything anymore.
So, everything one needs is there already, e.g. debootstrap
 
Back
Top