6 ms·

26 years of FreeBSD and counting... IIRC in about 99 I got sick of Mandrake and RH RPM deps hell and found FreeBSD 3 CD in a Walnut creek book. Ports and BSD p

26 years of FreeBSD and counting... IIRC in about 99 I got sick of Mandrake and RH RPM deps hell and found FreeBSD 3 CD in a Walnut creek book. Ports and BSD packages were a revelation, to say nothing of the documentation which still sets it apart from the haphazard Linux. The comment about using a good SERVER mobo like supermicro is on point --- I managed many supermicro fbsd colo ack servers for almost 15 years and those boards worked well with it. Currently I run FreeBSD on several home machines including old mac minis repurposed as media machines throughout the house. They run kodi + linux brave and with that I can stream anything like live sports. Also OpenBSD for one firewall and PFSense (FreeBSD) for another.

movedx 10mo ago
Lovely stuff. The industry would be so much better off if the family of BSDs had more attention and use. I run some EVE Online services for friends. They have manual install steps for those of use not using containers. Took me half a day to get the stack going on FBSD and that was mostly me making typos and mistakes. So pleased I was able to dodge the “docker compose up” trap.
- BrouteMinou 10mo ago
  Can you explain why "Docker compose" is a trap?
  - hakfoo 10mo ago
    For my two cents, it discourages standardization. If you run bare-metal, and instructions to build a project say "you need to install libfoo-dev, libbar-dev, libbaz-dev", you're still sourcing it from your known supply chain, with its known lifecycles and processes. If there's a CVE in libbaz, you'll likely get the patch and news from the same mailing lists you got your kernel and Apache updates from. Conversely, if you pull in a ready-made Docker container, it might be running an entire Alpine or Ubuntu distribution atop your preferred Debian or FreeBSD. Any process you had to keep those packages up to date and monitor vulnerabilities now has to be extended to cover additional distributions.
    - esseph 10mo ago
      Something like harbor easily integrates to serve as both a pull-through cache, and a cve scanner. You can actually limit allowing pulls with X type or CVSS rating. You /should/ be scanning your containers just like you /should/ be scanning the rest of your platform surface.
    - clan 10mo ago
      You said it better at first: Standardization. Posix is the standard. Docker is a tool on top of that layer. Absolutely nothing wrong with it! But you need to document towards the lower layers. What libraries are used and how they're interconnected. Posix gives you that common ground. I will never ask for people not to supply Docker files. But to be it feels the same if a project just released an apt package and nothing else. The manual steps need to be documented. Not for regular users but for those porting to other systems. I do not like black boxes.
      - skydhash 10mo ago
        Why I move from docker for selfhosted stuff was the lack of documentation and very complicated dockerfiles with various shell scripts services config. Sometimes it feels like reading autoconf generated files. I much prefer to learn whatever packaging method of the OS and build the thing myself.
- recursivetree 10mo ago
  As one of the guys who develops a EVE Online service: While you were able to get by with manual install steps that perhaps change with the OS, for a decent number of people it is the first time they do anything on the CLI on a unixoid system. Docker reduces the support workload in our help channels drastically because it is easier to get going.
  - clan 10mo ago
    I can sympathize. It makes sense. But... As a veteran admin I am tired of reading trough Docker files to guess how to do a native setup. You can never suss out the intent from those files - only do haphazardous guesses. It smells too much like "the code is the documentation". I am fine that the manual install steps are hidden deep in the dungeons away from the casual users. But please do not replace Posix compliance with Docker compliance. Look at Immich for an unfortunate example. Theys have some nice high level architecture documentation. But the "whys" of the Dockerfile is nowhere to be found. Makes it harder to contribute as it caters to the Docker crowd only and leaves a lot of guesswork for the Posix crowd.
    - arthurfirst 10mo ago
      Veteran sysadmin of 30 years... UNIX sysadmin and developer... I use docker+compose for my dev projects for about the past 12 years. Very tough to beat the speed of development with multi-tier applications. To me Dockerfiles seem like the perfect amount of DSL but still flexible because you can literally run any command as a RUN line and produce anything you want for layer. Dockerfiles seem to get it right. Maybe the 'anything' seems like a mis-feature but if you use it well it's a game changer. Dockerfiles are also an excellent way to distribute FOSS to people who unlike you or I cannot really manage a systems, install software, etc without eventually making a mess or getting lost (i.e. jr developers?). Are their supply chain risks? sure -- Like many package systems. I build my important images from scratch all the time just to mitigate this. There's also Podman with Podfiles if you want something more FOSS friendly but less polished. All that said, I generally containerize production workloads but not with Docker. If a dev project is ready for primetime now I port it to Kubernetes. Used to be BSD Jails .
- windward 10mo ago
  You've put that command in quotation marks in three comments on this topic. I don't think it's as prevalent as you're making out.
- fridder 10mo ago
  I wonder how it would work with the new-ish podman/oci container support?
naikrovek 10mo ago
It really is amazing how much success Linux has achieved given its relatively haphazard nature. FreeBSD always has been, and always will be, my favorite OS. It is so much more coherent and considered, as the post author points out. It is cohesive; whole.
- jimbokun 10mo ago
  Just another instance of Worse is Better?
- quesera 10mo ago
  Linux has turned haphazardry into a strength. This is impressive. I prefer FreeBSD.
  - actionfromafar 10mo ago
    I like the haphazardry but I think systemd veered too far into dadaism.
    - arthurfirst 10mo ago
      THIS. As bad as launchctl on Macs. Solution looking for a problem so it causes more problems -- like IPv6
      - dralley 10mo ago
        You can't be serious thinking that IPv4 doesn't have problems
        arthurfirst 10mo ago
        Of course not. But IPv6 is not the solution to Ipv4's issues at all. IPv6 is something completely different justified post-facto with EMOTIONAL arguments ie. You are stealing the last IPv4 address from the children! - Dual stack -- unnecessary and bloated - Performance = 4x worse or more - No NAT or private networks -- not in the same sense. People love to hate on NAT but I do not want my toaster on the internet with a unique hardware serial number. - Hardware tracking built into the protocol -- the mitigations offered are BS. - Addresses are a congintive block - Forces people to use DNS (central) which acts as a censorship choke point. All we needed was an extra pre space to set WHICH address space - ie. '0' is the old internet in 0.0.0.0.10 --- backwards compatible, not dual stack, no privacy nightmare, etc I actually wrote a code project that implements this network as an overlay -- but it's not ready to share yet. Works though. If I were to imagine my self in the room deciding on the IPv6 requirements I expect the key one was 'track every person and every device every where all the time' because if you are just trying to expand the address space then IPv6 is way way way overkill -- it's overkill even for future proofing for the next 1000 years of all that privacy invading.
AdieuToLogic 10mo ago
> The comment about using a good SERVER mobo like supermicro is on point --- I managed many supermicro fbsd colo ack servers for almost 15 years and those boards worked well with it. I completely agree. Supermicro mobo's with server-grade components combined with aggressive cooling fans/heat sinks running FreeBSD in a AAA data center resulted in two prod servers having uptimes of over 3000+ days. This included dozens of app/jails/ports updates (pretty much everything other than the kernel).
- wowczarek 10mo ago
  Back when I was a sysadmin (sort of 2007-2010), the preference of a colleague (RIP AJG...) who ran a lot of things before my time at the org, was FreeBSD, and I quickly understood why. We ran Postgres on 6.x as a db for a large Jira instance, while Jira itself ran on Linux iirc because I went with jrockit that ran circles around any JVM at the time. Those Postgres boxes had many years of uptime, locked away in a small colo facility, never failed and outlived the org that got merged and chopped up. FreeBSD was just so snappy, and just kept going. At the same time I ran ZFS on FreeBSD as our main file store for NFS and whatnot, snapshots, send/recv replication and all. And it was all indeed on Supermicro server hardware. And in parallel, while our routing kit was mostly Cisco, I put a transparent bridging firewall in front of the network running pfSense 1.2 or 1.3. It was one of those embedded boxes running a Via C3/Nehemiah, that had the Via Padlock crypto engine that pfSense supported. Its AES256 performance blew away our Xeons and crypto accelerator cards in our midrange Cisco ISRs - cards costing more than that C3 box. It had a failsafe Ethernet passthrough for when power went down and it ran FreeBSD. I've been using pfSense ever since, commercialisation / Netgate aside, force of habit. And although for some things I lean towards OpenBSD today, FreeBSD delivers, and it has for nearly 20 years for me. And, as they say, it should for you, too.
  - boatwombat 10mo ago
    I still remember AJG vividly to this day. He also once told me he was a FreeBSD contributor. My journey with FreeBSD began with version 4.5 or 4.6, running in VMware on Windows and using XDMCP for the desktop. It was super fast and ran at almost native speed. I tried Red Hat 9, and it was slow as a snail by comparison. For me, the choice was obvious. Later on I was running FreeBSD on my ThinkPad, and I still remember the days of coding on it using my professor's linear/non-linear optimisation library, sorting out wlan driver and firmware to use the library wifi, and compiling Mozilla on my way home while the laptop was in my backpack. My personal record: I never messed up a single FreeBSD install, even when I was completely drunk. Even later, I needed to monitor the CPU and memory usage of our performance/latency critical code. The POSIX API worked out of the box on FreeBSD and Solaris exactly as documented. Linux? Nope. I had to resort to parsing /proc myself, and what a mess it was. The structure was inconsistent, and even within the same kernel minor version the behaviour could change. Sometimes a process's CPU time included all its threads, and sometimes it didn't. To this day, I still tell people that FreeBSD (and the other BSDs) feels like a proper operating system, and GNU/Linux feels like a toy.
deleted 10mo ago
[deleted]

movedx 10mo ago

Lovely stuff. The industry would be so much better off if the family of BSDs had more attention and use. I run some EVE Online services for friends. They have manual install steps for those of use not using containers. Took me half a day to get the stack going on FBSD and that was mostly me making typos and mistakes. So pleased I was able to dodge the “docker compose up” trap.

BrouteMinou 10mo ago
Can you explain why "Docker compose" is a trap?
- hakfoo 10mo ago
  For my two cents, it discourages standardization. If you run bare-metal, and instructions to build a project say "you need to install libfoo-dev, libbar-dev, libbaz-dev", you're still sourcing it from your known supply chain, with its known lifecycles and processes. If there's a CVE in libbaz, you'll likely get the patch and news from the same mailing lists you got your kernel and Apache updates from. Conversely, if you pull in a ready-made Docker container, it might be running an entire Alpine or Ubuntu distribution atop your preferred Debian or FreeBSD. Any process you had to keep those packages up to date and monitor vulnerabilities now has to be extended to cover additional distributions.
  - esseph 10mo ago
    Something like harbor easily integrates to serve as both a pull-through cache, and a cve scanner. You can actually limit allowing pulls with X type or CVSS rating. You /should/ be scanning your containers just like you /should/ be scanning the rest of your platform surface.
  - clan 10mo ago
    You said it better at first: Standardization. Posix is the standard. Docker is a tool on top of that layer. Absolutely nothing wrong with it! But you need to document towards the lower layers. What libraries are used and how they're interconnected. Posix gives you that common ground. I will never ask for people not to supply Docker files. But to be it feels the same if a project just released an apt package and nothing else. The manual steps need to be documented. Not for regular users but for those porting to other systems. I do not like black boxes.
    - skydhash 10mo ago
      Why I move from docker for selfhosted stuff was the lack of documentation and very complicated dockerfiles with various shell scripts services config. Sometimes it feels like reading autoconf generated files. I much prefer to learn whatever packaging method of the OS and build the thing myself.
recursivetree 10mo ago
As one of the guys who develops a EVE Online service: While you were able to get by with manual install steps that perhaps change with the OS, for a decent number of people it is the first time they do anything on the CLI on a unixoid system. Docker reduces the support workload in our help channels drastically because it is easier to get going.
- clan 10mo ago
  I can sympathize. It makes sense. But... As a veteran admin I am tired of reading trough Docker files to guess how to do a native setup. You can never suss out the intent from those files - only do haphazardous guesses. It smells too much like "the code is the documentation". I am fine that the manual install steps are hidden deep in the dungeons away from the casual users. But please do not replace Posix compliance with Docker compliance. Look at Immich for an unfortunate example. Theys have some nice high level architecture documentation. But the "whys" of the Dockerfile is nowhere to be found. Makes it harder to contribute as it caters to the Docker crowd only and leaves a lot of guesswork for the Posix crowd.
  - arthurfirst 10mo ago
    Veteran sysadmin of 30 years... UNIX sysadmin and developer... I use docker+compose for my dev projects for about the past 12 years. Very tough to beat the speed of development with multi-tier applications. To me Dockerfiles seem like the perfect amount of DSL but still flexible because you can literally run any command as a RUN line and produce anything you want for layer. Dockerfiles seem to get it right. Maybe the 'anything' seems like a mis-feature but if you use it well it's a game changer. Dockerfiles are also an excellent way to distribute FOSS to people who unlike you or I cannot really manage a systems, install software, etc without eventually making a mess or getting lost (i.e. jr developers?). Are their supply chain risks? sure -- Like many package systems. I build my important images from scratch all the time just to mitigate this. There's also Podman with Podfiles if you want something more FOSS friendly but less polished. All that said, I generally containerize production workloads but not with Docker. If a dev project is ready for primetime now I port it to Kubernetes. Used to be BSD Jails .
windward 10mo ago
You've put that command in quotation marks in three comments on this topic. I don't think it's as prevalent as you're making out.
fridder 10mo ago
I wonder how it would work with the new-ish podman/oci container support?

naikrovek 10mo ago

It really is amazing how much success Linux has achieved given its relatively haphazard nature. FreeBSD always has been, and always will be, my favorite OS. It is so much more coherent and considered, as the post author points out. It is cohesive; whole.

jimbokun 10mo ago
Just another instance of Worse is Better?
quesera 10mo ago
Linux has turned haphazardry into a strength. This is impressive. I prefer FreeBSD.
- actionfromafar 10mo ago
  I like the haphazardry but I think systemd veered too far into dadaism.
  - arthurfirst 10mo ago
    THIS. As bad as launchctl on Macs. Solution looking for a problem so it causes more problems -- like IPv6
    - dralley 10mo ago
      You can't be serious thinking that IPv4 doesn't have problems
      - arthurfirst 10mo ago
        Of course not. But IPv6 is not the solution to Ipv4's issues at all. IPv6 is something completely different justified post-facto with EMOTIONAL arguments ie. You are stealing the last IPv4 address from the children! - Dual stack -- unnecessary and bloated - Performance = 4x worse or more - No NAT or private networks -- not in the same sense. People love to hate on NAT but I do not want my toaster on the internet with a unique hardware serial number. - Hardware tracking built into the protocol -- the mitigations offered are BS. - Addresses are a congintive block - Forces people to use DNS (central) which acts as a censorship choke point. All we needed was an extra pre space to set WHICH address space - ie. '0' is the old internet in 0.0.0.0.10 --- backwards compatible, not dual stack, no privacy nightmare, etc I actually wrote a code project that implements this network as an overlay -- but it's not ready to share yet. Works though. If I were to imagine my self in the room deciding on the IPv6 requirements I expect the key one was 'track every person and every device every where all the time' because if you are just trying to expand the address space then IPv6 is way way way overkill -- it's overkill even for future proofing for the next 1000 years of all that privacy invading.

AdieuToLogic 10mo ago

> The comment about using a good SERVER mobo like supermicro is on point --- I managed many supermicro fbsd colo ack servers for almost 15 years and those boards worked well with it. I completely agree. Supermicro mobo's with server-grade components combined with aggressive cooling fans/heat sinks running FreeBSD in a AAA data center resulted in two prod servers having uptimes of over 3000+ days. This included dozens of app/jails/ports updates (pretty much everything other than the kernel).

wowczarek 10mo ago
Back when I was a sysadmin (sort of 2007-2010), the preference of a colleague (RIP AJG...) who ran a lot of things before my time at the org, was FreeBSD, and I quickly understood why. We ran Postgres on 6.x as a db for a large Jira instance, while Jira itself ran on Linux iirc because I went with jrockit that ran circles around any JVM at the time. Those Postgres boxes had many years of uptime, locked away in a small colo facility, never failed and outlived the org that got merged and chopped up. FreeBSD was just so snappy, and just kept going. At the same time I ran ZFS on FreeBSD as our main file store for NFS and whatnot, snapshots, send/recv replication and all. And it was all indeed on Supermicro server hardware. And in parallel, while our routing kit was mostly Cisco, I put a transparent bridging firewall in front of the network running pfSense 1.2 or 1.3. It was one of those embedded boxes running a Via C3/Nehemiah, that had the Via Padlock crypto engine that pfSense supported. Its AES256 performance blew away our Xeons and crypto accelerator cards in our midrange Cisco ISRs - cards costing more than that C3 box. It had a failsafe Ethernet passthrough for when power went down and it ran FreeBSD. I've been using pfSense ever since, commercialisation / Netgate aside, force of habit. And although for some things I lean towards OpenBSD today, FreeBSD delivers, and it has for nearly 20 years for me. And, as they say, it should for you, too.
- boatwombat 10mo ago
  I still remember AJG vividly to this day. He also once told me he was a FreeBSD contributor. My journey with FreeBSD began with version 4.5 or 4.6, running in VMware on Windows and using XDMCP for the desktop. It was super fast and ran at almost native speed. I tried Red Hat 9, and it was slow as a snail by comparison. For me, the choice was obvious. Later on I was running FreeBSD on my ThinkPad, and I still remember the days of coding on it using my professor's linear/non-linear optimisation library, sorting out wlan driver and firmware to use the library wifi, and compiling Mozilla on my way home while the laptop was in my backpack. My personal record: I never messed up a single FreeBSD install, even when I was completely drunk. Even later, I needed to monitor the CPU and memory usage of our performance/latency critical code. The POSIX API worked out of the box on FreeBSD and Solaris exactly as documented. Linux? Nope. I had to resort to parsing /proc myself, and what a mess it was. The structure was inconsistent, and even within the same kernel minor version the behaviour could change. Sometimes a process's CPU time included all its threads, and sometimes it didn't. To this day, I still tell people that FreeBSD (and the other BSDs) feels like a proper operating system, and GNU/Linux feels like a toy.

deleted 10mo ago

[deleted]