5 ms·

My current home server passed 10 years in the autnum, but I've been running FreeBSD on servers since around 2000. The main gripe is probably Docker and/or soft

My current home server passed 10 years in the autnum, but I've been running FreeBSD on servers since around 2000. The main gripe is probably Docker and/or software depending on Linux-isms that can't be run natively without resorting to bhyve or smth alike that.

tosti 7mo ago
[flagged]
- jen20 7mo ago
  What exactly do you think pkg(1) is for? [1] [1]: https://docs-archive.freebsd.org/doc/10.3-RELEASE/usr/local/share/doc/freebsd/zh_TW/books/handbook/pkgng-intro.html https://docs-archive.freebsd.org/doc/10.3-RELEASE/usr/local/...
  - tosti 7mo ago
    I just use pkgsrc from netbsd
    - jen20 7mo ago
      Ah right, that doesn’t have binary distribution at all. Oh wait [1]. [1]: https://www.netbsd.org/docs/pkgsrc/bulk.html https://www.netbsd.org/docs/pkgsrc/bulk.html
      - tosti 7mo ago
        Who besides Joyent and NetBSD would ever do a bulk build? Portage can also do binary packages. That doesn't mean you have to have them. You can just not ever enable them and be fine.
        jen20 7mo ago
        By that logic, Docker doesn't have to do image distribution either...
        tosti 7mo ago
        In pkgsrc, building packages isn't done by default and 100% optional. I'm not sure what logic you're ascertaining here. There were operating systems before package managers and AFAICT IIRC the first package manager "repository" was a stack of floppies. But yes, there's always a choice to be made. Docker could separate out the image repository elsewhere. It could integrate buildroot. It could use a suitable initramfs generator. I'm not sure why present day devs like to create a hodgepodge of different distros mashed together and even do it all from CI, while the same CI could also run gmake on a source tree. For a sysadmin, docker would be fine. For a programmer, dealing with binary blobs all day, that's IMNSHO not what programming should be about.
- genthree 7mo ago
  Docker's what lets me spend more time using the software on my server than fiddling with it. I got the fiddling out of my system years ago, I just want shit to work now. I don't really care about it per se but having a cross-distro unified daemon config & supervisor, package manager, and ability to cram every single important file into a file tree (again, using the same interface to achieve this with every daemon) that has only those files in it (making backups and restores trivial) and then easily verify that I got all the important files (destroy image -> re-create, does it still look good? Then I got everything) makes everything so easy. I no longer put off trying a new service until the weekend because it'll take an unknown amount of time that could end up being hours. Odds are I can have anything available in the official Docker registry (which is approximately everything, these days) up in five minutes flat to try it out, and may not even need any further modifications for it to be ready for (personal) "production". I use Debian but don't even care, I haven't had to touch systemd once (thank god) and the only Debian-parts I even use are its ZFS, SSH, and Docker, with my ten or so actual user-facing services all just pulled and managed via Docker, ready to transfer to any other distro seamlessly, should I ever care to. Even Samba is under Docker (oh my god it is so much easier to configure for common use-cases this way). (I would definitely be using FreeBSD on my server if I cared about anything other than Docker, though—I haven't actually liked Linux for about fifteen years now)
- whizzter 7mo ago
  I've fixed too many linux-isms in code manually over the years, pkg/ports does what it should but since *nix tradition relies on hardcoded paths I often wanted out-of-tree builds for various software. And that's the thing, as I grow older I feel more and more that I just want the parts of computing that I don't want to _care_ about to be stupid simple. If I'm doing a program needing a recent version of some language that doesn't have a FreeBSD port yet and some database behind it, I don't really want to configure it all manually because I don't particularly care for porting the runtime or managing the database (that isn't exposed to the outside world anyhow). This is stuff where I don't want a large CI pipe or other management (or needing to remember to upgrade the packages if I upgrade the hosting OS). Stuff like this is why "the clouds are winning", friction should be linear depending on the effort I want to put into managing something. But going for real HW or even VPS a places an "upgrade tax" on me because I can't just let non-public services like an isolated DB just ride-along over major versions (maybe Jails with isolated userlands could be an option, but that becomes painful instead when needing newer versions of the application behind the veil).
- sauercrowd 7mo ago
  docker and flatpak/snap are _extremely_ different tools with very different purposes.
  - tosti 7mo ago
    Sure they're different. They all download blobs and can then execute them. Exactly how, when and why is completely different but they still get you blobs.
    - sauercrowd 7mo ago
      In the same way s3 is different to a dropbox, and a car being different to a bike. Can't tell if you're ragebaiting here, but I'm very confused by this question because they support an entirely different set of features, and if you use both it's painfully obvious how they're different. Docker is built for running services, distribution is part of that, but it's core is that you can pull an image and run random service on your machine packaged with all the right libraries, network them into your machine in the way you like so it can access the right things, constrain it's resources, and create our own image based on it. Snap/Flatpak is built to distribute applications, sandboxing being a core part of it, with applications wanting to integrate into distribution mechanics such as audio, URL handling, taking screenshots, ...
      - tosti 7mo ago
        Exactly. Yes, I've used them and it was horrible. For me, the difference is in do I get to compile this from sources myself or do I get someone elses compiler output? IOW it's not comparing vastly different vehicles, but rather a vehicle with its blueprint. Also, a long time ago it was commonly accepted that spaghetti code is awful. Docker replaces all that with spaghetti services and debugging gets much worse.
krylon 7mo ago
I have not thus far had anything to do with containers, so docker is unknown territory for me. I run audiobookshelf in a Debian VM via bhyve, but I was gonna run a Debian VM anyway.
BirAdam 7mo ago
You could just use podman.
- whizzter 7mo ago
  Theoretically yes, however still limited by how well the FreeBSD Linux layer handles syscalls. A year or so back I tried running .NET (just binaries, not via a container) since the port wasn't as far along as today and it crashed due to what I suspect was slight differences in signal handling defaults. And this is part of the situation that's going to get worse, io_uring will become more popular in language runtimes and iirc it's not trivial to emulate via existing FreeBSD mechanisms (kqueue). Iirc Mac docker uses xhyve (bhyve port/inspired) to run containers via Linux emulation, MS went for pv-Linux for WSL2, while FreeBSD has been "good enough" so far. But I think that for containers it's either time to shape up Linux emulation well (It's ironic that WSL1 ironed out their worst quirks just as WSL2 was introduced, although that was without io_uring) or just add an option for Podman to have a minimal pv-Linux kernel via bhyve to get better compatibility.
  - frumplestlatz 7mo ago
    Indeed, ideally we could get docker on FreeBSD using the same approach as is used on macOS — automatically run (one or more) Linux VMs under bhyve. I wonder if FreeBSD ought to consider a WSL2-style approach to Linux binary compatibility, too. Keeping the Linux syscall compatibility layer up-to-date has always been a resource problem, especially when syscalls depend on large, complex Linux kernel subsystems that just don’t map cleanly to FreeBSD kernel facilities.
  - akdev1l 7mo ago
    I’m confused because can already do this on MacOS, Windows and Linux Does `podman machine init` not work in FreeBSD? In those other platforms it will spin a small Linux VM to run containers on.
jbverschoor 7mo ago
Exactly the reason why I switched from FreeBSD to Debian, 25 years ago
- TacticalCoder 7mo ago
  The difference compared to a quarter of a century ago is that hardware virtualization is an ubiquitous thing now and that machines go so much faster that you don't even realize you're running in a VM anymore: it's pretty much transparent. I run Docker on my Linux servers inside a VM. There's no way I let Docker touch the bare metal, not with a ten foot pole. If people want or need to run Docker on FreeBSD, they can run a Linux VM under bhyve.

tosti 7mo ago

[flagged]

jen20 7mo ago
What exactly do you think pkg(1) is for? [1] [1]: https://docs-archive.freebsd.org/doc/10.3-RELEASE/usr/local/share/doc/freebsd/zh_TW/books/handbook/pkgng-intro.html https://docs-archive.freebsd.org/doc/10.3-RELEASE/usr/local/...
- tosti 7mo ago
  I just use pkgsrc from netbsd
  - jen20 7mo ago
    Ah right, that doesn’t have binary distribution at all. Oh wait [1]. [1]: https://www.netbsd.org/docs/pkgsrc/bulk.html https://www.netbsd.org/docs/pkgsrc/bulk.html
    - tosti 7mo ago
      Who besides Joyent and NetBSD would ever do a bulk build? Portage can also do binary packages. That doesn't mean you have to have them. You can just not ever enable them and be fine.
      - jen20 7mo ago
        By that logic, Docker doesn't have to do image distribution either...
        tosti 7mo ago
        In pkgsrc, building packages isn't done by default and 100% optional. I'm not sure what logic you're ascertaining here. There were operating systems before package managers and AFAICT IIRC the first package manager "repository" was a stack of floppies. But yes, there's always a choice to be made. Docker could separate out the image repository elsewhere. It could integrate buildroot. It could use a suitable initramfs generator. I'm not sure why present day devs like to create a hodgepodge of different distros mashed together and even do it all from CI, while the same CI could also run gmake on a source tree. For a sysadmin, docker would be fine. For a programmer, dealing with binary blobs all day, that's IMNSHO not what programming should be about.
genthree 7mo ago
Docker's what lets me spend more time using the software on my server than fiddling with it. I got the fiddling out of my system years ago, I just want shit to work now. I don't really care about it per se but having a cross-distro unified daemon config & supervisor, package manager, and ability to cram every single important file into a file tree (again, using the same interface to achieve this with every daemon) that has only those files in it (making backups and restores trivial) and then easily verify that I got all the important files (destroy image -> re-create, does it still look good? Then I got everything) makes everything so easy. I no longer put off trying a new service until the weekend because it'll take an unknown amount of time that could end up being hours. Odds are I can have anything available in the official Docker registry (which is approximately everything, these days) up in five minutes flat to try it out, and may not even need any further modifications for it to be ready for (personal) "production". I use Debian but don't even care, I haven't had to touch systemd once (thank god) and the only Debian-parts I even use are its ZFS, SSH, and Docker, with my ten or so actual user-facing services all just pulled and managed via Docker, ready to transfer to any other distro seamlessly, should I ever care to. Even Samba is under Docker (oh my god it is so much easier to configure for common use-cases this way). (I would definitely be using FreeBSD on my server if I cared about anything other than Docker, though—I haven't actually liked Linux for about fifteen years now)
whizzter 7mo ago
I've fixed too many linux-isms in code manually over the years, pkg/ports does what it should but since *nix tradition relies on hardcoded paths I often wanted out-of-tree builds for various software. And that's the thing, as I grow older I feel more and more that I just want the parts of computing that I don't want to _care_ about to be stupid simple. If I'm doing a program needing a recent version of some language that doesn't have a FreeBSD port yet and some database behind it, I don't really want to configure it all manually because I don't particularly care for porting the runtime or managing the database (that isn't exposed to the outside world anyhow). This is stuff where I don't want a large CI pipe or other management (or needing to remember to upgrade the packages if I upgrade the hosting OS). Stuff like this is why "the clouds are winning", friction should be linear depending on the effort I want to put into managing something. But going for real HW or even VPS a places an "upgrade tax" on me because I can't just let non-public services like an isolated DB just ride-along over major versions (maybe Jails with isolated userlands could be an option, but that becomes painful instead when needing newer versions of the application behind the veil).
sauercrowd 7mo ago
docker and flatpak/snap are _extremely_ different tools with very different purposes.
- tosti 7mo ago
  Sure they're different. They all download blobs and can then execute them. Exactly how, when and why is completely different but they still get you blobs.
  - sauercrowd 7mo ago
    In the same way s3 is different to a dropbox, and a car being different to a bike. Can't tell if you're ragebaiting here, but I'm very confused by this question because they support an entirely different set of features, and if you use both it's painfully obvious how they're different. Docker is built for running services, distribution is part of that, but it's core is that you can pull an image and run random service on your machine packaged with all the right libraries, network them into your machine in the way you like so it can access the right things, constrain it's resources, and create our own image based on it. Snap/Flatpak is built to distribute applications, sandboxing being a core part of it, with applications wanting to integrate into distribution mechanics such as audio, URL handling, taking screenshots, ...
    - tosti 7mo ago
      Exactly. Yes, I've used them and it was horrible. For me, the difference is in do I get to compile this from sources myself or do I get someone elses compiler output? IOW it's not comparing vastly different vehicles, but rather a vehicle with its blueprint. Also, a long time ago it was commonly accepted that spaghetti code is awful. Docker replaces all that with spaghetti services and debugging gets much worse.

krylon 7mo ago

I have not thus far had anything to do with containers, so docker is unknown territory for me. I run audiobookshelf in a Debian VM via bhyve, but I was gonna run a Debian VM anyway.

BirAdam 7mo ago

You could just use podman.

whizzter 7mo ago
Theoretically yes, however still limited by how well the FreeBSD Linux layer handles syscalls. A year or so back I tried running .NET (just binaries, not via a container) since the port wasn't as far along as today and it crashed due to what I suspect was slight differences in signal handling defaults. And this is part of the situation that's going to get worse, io_uring will become more popular in language runtimes and iirc it's not trivial to emulate via existing FreeBSD mechanisms (kqueue). Iirc Mac docker uses xhyve (bhyve port/inspired) to run containers via Linux emulation, MS went for pv-Linux for WSL2, while FreeBSD has been "good enough" so far. But I think that for containers it's either time to shape up Linux emulation well (It's ironic that WSL1 ironed out their worst quirks just as WSL2 was introduced, although that was without io_uring) or just add an option for Podman to have a minimal pv-Linux kernel via bhyve to get better compatibility.
- frumplestlatz 7mo ago
  Indeed, ideally we could get docker on FreeBSD using the same approach as is used on macOS — automatically run (one or more) Linux VMs under bhyve. I wonder if FreeBSD ought to consider a WSL2-style approach to Linux binary compatibility, too. Keeping the Linux syscall compatibility layer up-to-date has always been a resource problem, especially when syscalls depend on large, complex Linux kernel subsystems that just don’t map cleanly to FreeBSD kernel facilities.
- akdev1l 7mo ago
  I’m confused because can already do this on MacOS, Windows and Linux Does `podman machine init` not work in FreeBSD? In those other platforms it will spin a small Linux VM to run containers on.

jbverschoor 7mo ago

Exactly the reason why I switched from FreeBSD to Debian, 25 years ago

TacticalCoder 7mo ago
The difference compared to a quarter of a century ago is that hardware virtualization is an ubiquitous thing now and that machines go so much faster that you don't even realize you're running in a VM anymore: it's pretty much transparent. I run Docker on my Linux servers inside a VM. There's no way I let Docker touch the bare metal, not with a ten foot pole. If people want or need to run Docker on FreeBSD, they can run a Linux VM under bhyve.