←back to thread

190 points psxuaw | 2 comments | | HN request time: 0.427s | source
Show context
rollcat ◴[] No.43537129[source]
I have mixed feelings about FreeBSD. Some stuff is genuinely good: major/minor release branches, the best ZFS experience you can get OOB, actual man pages, overall a lot "cleaner" than most Linux distros.

OTOH when you compare it to e.g. OpenBSD (or in many instances, even Linux), it's an actual mess. The default install leaves you browsing thru the handbook to get simple things to work; it has three (three!) distinct firewalls; the split between /usr/local/etc and /etc constantly leaves you guessing where to find a particular config file; even the tiny things such as some default sysctl value being an XML snippet - actually, WTF?

The desktop story is also pretty bad. OpenBSD asks you during installation, whether you'd like to use X11 - and that's it. You boot to XDM, you get a basic window manager, things like volume buttons just work, all in the base system - no packages, no config files. You can install Gnome or XFCE from there, and rest assured you'll always have a working fallback. FreeBSD still feels like 90's Linux in that area. Regarding usability, both are behind Linux in things like connecting to Wifi networks, but in OpenBSD's case you just save a list of SSIDs/passwords in a text file, and the kernel does the rest for you.

The author is praising jails. I think it's nice that you can trace the lineage all the way back to 6.x, it sings a song of stability. You can also put each jail on a separate ZFS dataset to get snapshot/restore, cloning, etc. But I think it's still a poor middle ground between OpenBSD and OCI. OpenBSD keeps making steps (privsep, pledge, unveil) to provide isolation, while remaining conceptually simple for the developer and imposing no extra maintenance burden on the operator. Containers by design are declarative, separate the system image from state, etc - it's a wholly different concept for someone used to e.g. managing stateful jails or VMs, but it reinforces what already were good design principles.

replies(5): >>43537232 #>>43537514 #>>43538655 #>>43540046 #>>43543318 #
throwaway2037 ◴[] No.43543318[source]

    > actual man pages
What is wrong with Linux man pages?
replies(1): >>43547313 #
rollcat ◴[] No.43547313[source]
Let's start with: there is no such thing as "Linux" man pages. There's <https://docs.kernel.org> but that only concerns the kernel itself.

How does a particular distribution handle its man pages is up to that distribution. You can browse what is generally considered to be the "standard" set of man pages online: <https://man7.org/linux/man-pages/> or <https://linux.die.net/man/>, but this is a third-party community effort. I've often found minor discrepancies between those resources and what I actually found installed on my system.

Debian does an absolutely amazing job: every executable in every package has to come with a man page, and if there isn't one, the maintainers will at least write a synopsis. You can also read these man pages online: <https://manpages.debian.org>; you get to browse by release, section, you even get translations. Some derivatives (e.g. Ubuntu) will provide their own online browser as well.

But this is where things start to get dicey. Most distributions make heavy use of GNU coreutils, glibc, GCC, etc. Some of these (like GCC) are complex, because the problem domain is complex. On the other hand, coreutils' level of unnecessary complexity is almost byzantine; to cope with that, the GNU project mostly abandoned man pages (these mostly just contain a synopsis) in favour of an in-house "info" system <https://www.gnu.org/software/texinfo/manual/info-stnd/info-s...>, which is basically TeX <https://tug.org> with layers on top.

But not all distros use GNU tools nowadays; e.g. Alpine (actually pretty popular, thanks to the Docker ecosystem) uses busybox and musl libc. However for some reason Alpine not only does not provide an online man page browser, but requires installing a meta-package to add the man pages to your system. The differences between GNU and busybox+musl are non-trivial (and not unlike GNU vs BSD).

You can blame the Linux ecosystem fragmentation, and you would be correct to point out there are three popular BSDs, each with its own goals and little quirks. My final point is about the quality of the documentation. Compare coreutils chmod(1) <https://linux.die.net/man/1/chmod> and OpenBSD chmod(1) <https://man.openbsd.org/chmod.1>. The former is a brief, dense, and intimidating wall of text that expects you to immediately grasp what "ugoa" or "rwxXst" stand for; you will only find out that the tool manages file access permissions once you dig through the third paragraph; the text concludes by referring you to "info coreutils aqchmod invocationaq". By contrast, OpenBSD's man page has a clear introduction, then paces you through explaining the basic; goes into detail over the octal and symbolic representations (with pretty tables); warns you about a common mistake; has several examples with explanations (including equivalences between octal and symbolic forms); and concludes by referring you to the POSIX standards.

Best of it, you can expect the same high standard of quality throughout the entire base system, from user commands to device drivers and kernel internals.

replies(1): >>43549225 #
1. rascul ◴[] No.43549225[source]
> Let's start with: there is no such thing as "Linux" man pages. There's <https://docs.kernel.org> but that only concerns the kernel itself.

Actually, there is.

https://web.git.kernel.org/pub/scm/docs/man-pages/man-pages....

It's included with many default distro installs.

replies(1): >>43555357 #
2. rollcat ◴[] No.43555357[source]
This is technically true, but this pretty much exactly illustrates my point. The SCM URL you've provided, you have to dig it up. It refers you to <https://man7.org/linux/man-pages/index.html>, which again, is a personal website of a member of the community. Then e.g. the fnctl(2) page comes from the 6.10 kernel release - AFAICT I can't browse the past releases or track HEAD. Compare with <https://man.openbsd.org> or <https://man.freebsd.org/cgi/man.cgi>, you can find both straight from the landing pages.

Meanwhile if you can't find man7.org (Google search results are only getting worse) and start browsing <https://docs.kernel.org>, it refers you to <https://www.kernel.org/doc/man-pages/> which refers you to <https://www.kernel.org/doc/man-pages/maintaining.html>, <https://www.kernel.org/doc/man-pages/missing_pages.html>, and Wikipedia - none of which seem to be relevant, can't tell because it's a wall of text rather than a man page browser.

Now imagine you have to fix a b0rked system that can't display its own man pages. You're now stuck with this mess.