4 ms·

I like FreeBSD a lot more than Linux at the administration level. I ran it as my desktop for a few years. The big problem: all the software I wanted to run ass

I like FreeBSD a lot more than Linux at the administration level. I ran it as my desktop for a few years. The big problem: all the software I wanted to run assumed the whole world was GNU/Linux. So I ended up running lots of Linux binaries under emulation. (yes, I could have compiled everything from ports. But the time I spent 3 days compiling OpenOffice to discover the port was known-broken put me off that a bit ...) Then I discovered Ubuntu and in particular synaptic and the Debian repos and had a "holy shit, this gets it right" moment. Haven't looked back.

gregory-nisbet 11y ago
I've read about the FreeBSD Linux emulation layer, but don't know that much about it. What exactly does it provide besides emulation of Linux system calls? How reliable is it in practice?
- davidgerard 11y ago
  This was ten years ago, I have no idea what it's like in 2015. It's a syscall emulator and a pile of libs from Red Hat. It was reasonably reliable. X font rendering was awful. But then, Linux at the time wasn't much better; Ubuntu had only just started on the process of making the Linux desktop less annoying.
  - floatboth 11y ago
    It is maintained. epoll support is coming to the linuxulator in FreeBSD 11. But you don't need it really. All the usual desktop software is available natively. Firefox, Thunderbird, Chromium, LibreOffice, Transmission, VLC, GIMP, darktable, ioquake3 :-) You don't need to compile anything (if you don't want to, say, use LibreSSL everywhere), pkgng is excellent.
    - david-given 11y ago
      > But you don't need it really. ...games. Is the syscall emulation layer good enough to run the Steam client and, to pick one at random, Kerbal Space Program?
    - tobik 11y ago
      > But you don't need it really. You need it to run Linux Docker containers on FreeBSD. More on https://wiki.freebsd.org/Docker https://wiki.freebsd.org/Docker
      - floatboth 11y ago
        I don't think that's a good idea. I don't want to run Linux anything ;-)
jake_morrison 11y ago
Honest question: has FreeBSD become more automation friendly? i.e. putting all the configuration in /etc/rc.conf may be nice for a systems administrator manually editing things, but makes it hard for installation scripts which configure the system incrementally (e.g. Ansible). One thing I like about Linux is support for /etc/foo.d directories instead of /etc/foo.conf. Or is this not a problem in practice? In our new "cloud native" systems we are ending up with a number of single-purpose VMs in AWS or GCP. So being able to run a minimal OS image with OpenBSD has it's attraction. At this point, it's easier to use CentOS or Ubuntu due to application compatibility. I suppose the next logical step is Docker or NixOS.
- JdeBP 11y ago
  Dealing with /etc/rc.conf isn't any harder than dealing with /etc/fstab, /etc/master.passwd, /etc/ttys, or any of the other text-files-with-specific-defined-formats databases. There's no reason to think that one only edits them manually. One manipulates the account database with tools such as "pw useradd" and suchlike. One can manipulate /etc/rc.conf{,.local} and its replacements with tools too. The OpenBSD people have a while back (http://www.openbsd.org/plus56.html http://www.openbsd.org/plus56.html) explicitly re-defined /etc/rc.conf{,.local} to be a database of name=value pairs (rather than a shell script with arbitrary content), precisely so that it can be manipulated and parsed by programs other than shells. They have the rcctl tool (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/rcctl.8 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...) which is explicitly designed to let one do things like rcctl enable ntpd and rcctl disable ntpd to enable and disable the ntpd service. Whilst FreeBSD has yet to catch up with the formality, the existence of tools such as sysrc (https://www.freebsd.org/cgi/man.cgi?query=sysrc https://www.freebsd.org/cgi/man.cgi?query=sysrc) mean that treating FreeBSD /etc/rc.conf{,.local} (and indeed other files that can be manipulated with sysrc such as /boot/loader.conf) as a similar database file is a growing idiom, FreeNAS becoming the exception and not the rule in this regard. Services managed on FreeBSD through nosh (http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...) have the advantage that they can use the daemontools envdir mechanism, which separates configuration variables for separate services quite simply and easily. This is a long-standing and well-understood mechanism, which has been around for approaching two decades at this point and which one can find widely discussed and documented. nosh has a mechanism for importing /etc/rc.conf{,.local}, moreover. In nosh there is also an rcctl shim that maps both to this envdir mechanism and to the native service management. So one can do the same rcctl things such as %rcctl get ntpd flags -p /var/run/ntpd.pid -f /var/db/ntpd.drift % which can read (and with the concomitant "rcctl set" modify, of course) the variables in a conventionally-placed envdir, and rcctl enable ntpd and rcctl disable ntpd which will make the appropriate service bundle modifications to enable and disable the service.

gregory-nisbet 11y ago

I've read about the FreeBSD Linux emulation layer, but don't know that much about it. What exactly does it provide besides emulation of Linux system calls? How reliable is it in practice?

davidgerard 11y ago
This was ten years ago, I have no idea what it's like in 2015. It's a syscall emulator and a pile of libs from Red Hat. It was reasonably reliable. X font rendering was awful. But then, Linux at the time wasn't much better; Ubuntu had only just started on the process of making the Linux desktop less annoying.
- floatboth 11y ago
  It is maintained. epoll support is coming to the linuxulator in FreeBSD 11. But you don't need it really. All the usual desktop software is available natively. Firefox, Thunderbird, Chromium, LibreOffice, Transmission, VLC, GIMP, darktable, ioquake3 :-) You don't need to compile anything (if you don't want to, say, use LibreSSL everywhere), pkgng is excellent.
  - david-given 11y ago
    > But you don't need it really. ...games. Is the syscall emulation layer good enough to run the Steam client and, to pick one at random, Kerbal Space Program?
  - tobik 11y ago
    > But you don't need it really. You need it to run Linux Docker containers on FreeBSD. More on https://wiki.freebsd.org/Docker https://wiki.freebsd.org/Docker
    - floatboth 11y ago
      I don't think that's a good idea. I don't want to run Linux anything ;-)

jake_morrison 11y ago

Honest question: has FreeBSD become more automation friendly? i.e. putting all the configuration in /etc/rc.conf may be nice for a systems administrator manually editing things, but makes it hard for installation scripts which configure the system incrementally (e.g. Ansible). One thing I like about Linux is support for /etc/foo.d directories instead of /etc/foo.conf. Or is this not a problem in practice? In our new "cloud native" systems we are ending up with a number of single-purpose VMs in AWS or GCP. So being able to run a minimal OS image with OpenBSD has it's attraction. At this point, it's easier to use CentOS or Ubuntu due to application compatibility. I suppose the next logical step is Docker or NixOS.

JdeBP 11y ago
Dealing with /etc/rc.conf isn't any harder than dealing with /etc/fstab, /etc/master.passwd, /etc/ttys, or any of the other text-files-with-specific-defined-formats databases. There's no reason to think that one only edits them manually. One manipulates the account database with tools such as "pw useradd" and suchlike. One can manipulate /etc/rc.conf{,.local} and its replacements with tools too. The OpenBSD people have a while back (http://www.openbsd.org/plus56.html http://www.openbsd.org/plus56.html) explicitly re-defined /etc/rc.conf{,.local} to be a database of name=value pairs (rather than a shell script with arbitrary content), precisely so that it can be manipulated and parsed by programs other than shells. They have the rcctl tool (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/rcctl.8 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...) which is explicitly designed to let one do things like rcctl enable ntpd and rcctl disable ntpd to enable and disable the ntpd service. Whilst FreeBSD has yet to catch up with the formality, the existence of tools such as sysrc (https://www.freebsd.org/cgi/man.cgi?query=sysrc https://www.freebsd.org/cgi/man.cgi?query=sysrc) mean that treating FreeBSD /etc/rc.conf{,.local} (and indeed other files that can be manipulated with sysrc such as /boot/loader.conf) as a similar database file is a growing idiom, FreeNAS becoming the exception and not the rule in this regard. Services managed on FreeBSD through nosh (http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...) have the advantage that they can use the daemontools envdir mechanism, which separates configuration variables for separate services quite simply and easily. This is a long-standing and well-understood mechanism, which has been around for approaching two decades at this point and which one can find widely discussed and documented. nosh has a mechanism for importing /etc/rc.conf{,.local}, moreover. In nosh there is also an rcctl shim that maps both to this envdir mechanism and to the native service management. So one can do the same rcctl things such as %rcctl get ntpd flags -p /var/run/ntpd.pid -f /var/db/ntpd.drift % which can read (and with the concomitant "rcctl set" modify, of course) the variables in a conventionally-placed envdir, and rcctl enable ntpd and rcctl disable ntpd which will make the appropriate service bundle modifications to enable and disable the service.