5 ms·

Small review of FreeBSD (I used it for a very short period of time, so I could be off the wall, though). PREFACE I've been using linux since the mid-90s. I kn

Small review of FreeBSD (I used it for a very short period of time, so I could be off the wall, though). PREFACE I've been using linux since the mid-90s. I know how to use the console, I compiled kernels, played with the old xfree86 config files and all that back in the day. THE GOOD OF FreeBSD: * Stable. It feels like a Unix out of the 80s. If you know what you're doing, it'll get the job done. * man pages - Haven't used them much on Linux recently, felt that they were on the level of command --help, but on FreeBSD they felt like reading an authoritative blog post. Clear and concise. * Cross-update versions - better than Debian. I personally never successfully had a seamless update between major releases, while FreeBSD did. * No systemd (for now) - Unfortunately, systemd is taking over Linux because the largest block of user-space OSS programmers work for RedHat, which pushes for systemd. IIRC, the reason Debian went with systemd is because their maintainers simply have no resources to commit to remove it from gnome, etc. However, as systemd grows in scope, FreeBSD will have to either play with it, re-implement it in a normal way (which will let other Linux systems find a way out), or stop being compatible with gtk, gnome, et al. THE IRRELEVANT: * BSD license - unless you're modifying and then distributing your modification, it doesn't matter. * "Fragmantation" - True, "FreeBSD" is less fragmented than "Linux", but "BSD" is more fragmented than "Linux" and "Debian" (or RedHat or Ubuntu or Arch...) is the same not fragmented as FreeBSD. Look at the Distro as the OS rather than the kernel. And it doesn't matter - If you're distributing OSS, then release it as POSIX and configure; make; make install, and let the distro figure out packaging. If you want to make life easier for the distro or releasing closed source software, Linux (on the server) has an order of magnitude more users than FreeBSD (https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Public_servers_on_the_Internet https://en.wikipedia.org/wiki/Usage_share_of_operating_syste... ), and if your program works with Debian, Ubuntu and RedHat/CentOS, you'll probably cover the vast majority of users. * Ports - Complicated to update, takes a long time (unless you have a fleet of servers), and can't be automated. And pkg is no better than apt. * ZFS - ZFS is being ported to Linux, and btrfs may one day become stable. Either way, in a few years you'll be able to run the same ZFS on Linux as on FreeBSD. THE GOOD IN LINUX * Update - On Debian, you run apt upgrade && apt update. And it updates everything. And if you're on a stable release, updates are only bug-fixes, so (short of bugs/regressions), it can be automated. FreeBSD, on the other hand, doesn't have enough maintainers to keep a stable ports tree, so every update can break your setup. So every update has to be taken care of manually. * Security - Yes, I know that "experts" like the FreeBSD kernel better and everything, but the FreeBSD kernel has bugs of its own, so practically the key to secure both is keeping them up to date. And most of the time you're using ports, which isn't really run by FreeBSD and subject to their code review. So as Linux has an easier time updating (see above), it would be more secure. * Directory structure - Why would you want a "blessed" vi? Why should a distro manager decide that /usr/bin/vi is (say) vim while neovim /usr/local/bin/nvi. If anything, Linux is a lot more "Unixy" (I do know that FreeBSD is the "traditional" way, but I think that Linux is a lot more Unixy) - Why shouldn't I be able to write my own libc without having to maintain my own kernel? On Linux I can replace glibc with muslc. Why can't I do the same on FreeBSD? If anything, this is what everyone's complaining about systemd: "It's not modular". Well, neither is the FreeBSD base. (Though in truth, FreeBSD seems much more careful about basic software hygiene than systemd). * Default software - Maybe I'm unique, but I kind of like bash. I don't see why it shouldn't be my default shell except "Well, if it didn't exist in the 80s, it won't exist now" (It could also be a licensing issue, but as a user I don't really care about that). Others will scream "ShellShock". Well, yes. Though ShellShock shouldn't be a security issue if you don't rely on userspace software to maintain security. The OS should assume that software will break, and defend against it. So things like pledge or SELinux are much more effective (and sustainable) than treating userspace bugs as security holes. Though in truth, I can't see why Apache should ever run bash honestly.

kev009 10y ago
Errr.. the linked article means no, it is not safe to just cron an apt-get upgrade. In theory Debian is maintaining ABI/API. In practice there are issues. Rolling releases in practice have better tradeoffs, but require continuous deployment. On a workstation there are really no significant issues. On a production infrastructure, you need to use poudriere to maintain your own repos and orchestrate a branching and installation strategy. btrfs seems like an elaborate hoax. ZoL is fine, but support and integration still go Illumos > FreeBSD > ZoL. There are enough commercial products using FreeBSD ZFS that it is robust. UNIX uses the shell for a lot of things, interactive users are just one infrequent process. Bash is harmful as a non-interactive shell. Change your interactive shell to bash or zsh, problem solved.
- dump12332-1 10y ago
  >Errr.. the linked article means no, it is not safe to just cron an apt-get upgrade. In theory Debian is maintaining ABI/API. In practice there are issues. Rolling releases in practice have better tradeoffs, but require continuous deployment. On a workstation there are really no significant issues. On a production infrastructure, you need to use poudriere to maintain your own repos and orchestrate a branching and installation strategy. There's a difference between manually logging in once a day and typing apt-get update && apt-get upgrade, seeing warnings, responding to them and applying and re-configuring/recompiling ports. One can take five minutes. One can take an hour. >On a workstation there are really no significant issues. Yes, and on linux you can run testing. But I want more stability on a server. > ZoL is fine, but support and integration still go Illumos > FreeBSD > ZoL. There are enough commercial products using FreeBSD ZFS that it is robust. For some reason, all of a sudden everyone thinks that ZoL is legally safe to use. I'm not a lawyer, but whatever. The point is that it's still new and not tested significantly, but it should be more stable soon. >UNIX uses the shell for a lot of things, interactive users are just one infrequent process. Bash is harmful as a non-interactive shell. Change your interactive shell to bash or zsh, problem solved. So write shell scripts against /bin/sh or dash. >Bash is harmful as a non-interactive shell. How is it harmful? I mean why are your putting your shell in an untrusted environment? Moreover, I understand if you like sh, tcsh, zsh or bash. My point is that it seems to me more of a "we always used tcsh/sh, so that's how it will stay forever" rather than "let's see what's the best default shell now and use it". And why can't both shells (or zsh, which is MIT licensed) be included in base?

kev009 10y ago

Errr.. the linked article means no, it is not safe to just cron an apt-get upgrade. In theory Debian is maintaining ABI/API. In practice there are issues. Rolling releases in practice have better tradeoffs, but require continuous deployment. On a workstation there are really no significant issues. On a production infrastructure, you need to use poudriere to maintain your own repos and orchestrate a branching and installation strategy. btrfs seems like an elaborate hoax. ZoL is fine, but support and integration still go Illumos > FreeBSD > ZoL. There are enough commercial products using FreeBSD ZFS that it is robust. UNIX uses the shell for a lot of things, interactive users are just one infrequent process. Bash is harmful as a non-interactive shell. Change your interactive shell to bash or zsh, problem solved.

dump12332-1 10y ago
>Errr.. the linked article means no, it is not safe to just cron an apt-get upgrade. In theory Debian is maintaining ABI/API. In practice there are issues. Rolling releases in practice have better tradeoffs, but require continuous deployment. On a workstation there are really no significant issues. On a production infrastructure, you need to use poudriere to maintain your own repos and orchestrate a branching and installation strategy. There's a difference between manually logging in once a day and typing apt-get update && apt-get upgrade, seeing warnings, responding to them and applying and re-configuring/recompiling ports. One can take five minutes. One can take an hour. >On a workstation there are really no significant issues. Yes, and on linux you can run testing. But I want more stability on a server. > ZoL is fine, but support and integration still go Illumos > FreeBSD > ZoL. There are enough commercial products using FreeBSD ZFS that it is robust. For some reason, all of a sudden everyone thinks that ZoL is legally safe to use. I'm not a lawyer, but whatever. The point is that it's still new and not tested significantly, but it should be more stable soon. >UNIX uses the shell for a lot of things, interactive users are just one infrequent process. Bash is harmful as a non-interactive shell. Change your interactive shell to bash or zsh, problem solved. So write shell scripts against /bin/sh or dash. >Bash is harmful as a non-interactive shell. How is it harmful? I mean why are your putting your shell in an untrusted environment? Moreover, I understand if you like sh, tcsh, zsh or bash. My point is that it seems to me more of a "we always used tcsh/sh, so that's how it will stay forever" rather than "let's see what's the best default shell now and use it". And why can't both shells (or zsh, which is MIT licensed) be included in base?