4 ms·
FreeBSD handbook is also very, very good. I think that the BSD's are each more or less self-contained has something to do with it. You can read everything about
by wheresmycraisin 4y ago
FreeBSD handbook is also very, very good. I think that the BSD's are each more or less self-contained has something to do with it. You can read everything about system services, for example, in the handbook without having to chase down systemd blog posts and compensate for various differences between versions and distros.
- gtirloni 4y agoThey are indeed very good but the pace of change being slower than Linux also makes it easier to keep things updated.
- ninjin 4y agoWhat if the slower pace is a conscious choice that makes the resulting documentation better and codebase more solid?
- gtirloni 4y agoIt's not (a conscious choice). There just are fewer people working on BSD. Linux has to handle an avalanche of developers wanting to merge their code.
- willnonya 4y agoNot being a disjointed mess of unrelated software helps too.
- SoftTalker 4y agoIt's also that the process of change requires documentation. You won't get changes committed without it.
- Enginerrrd 4y agoThat seems like the root cause here. Why on earth isn't that the standard everywhere?
- pm215 4y agoBecause writing documentation isn't easy, and a lot of people who like writing code don't much like writing docs. So for an open source project "the documentation matters" has to be a conscious choice (a cultural value, if you like), which is actively enforced by (a) the regular devs pushing back on contributions which don't have docs and (b) those devs demonstrating a commitment to the value by upholding it themselves, ie writing docs for their own contributions. Obviously "better docs" would be better for the users of software, but most people contributing to most open source projects (or indeed to most non-open source software!) are not doing so primarily for the altruistic goal of making users' lives easier. So the default position ends up being "do the stuff you find fun" or "do the stuff that your employer cares most about" or "do the stuff that fixes problems you personally are running into", which will often not be "great docs". (I speak as somebody who's involved with an open source project whose documentation is overall not all that great and which doesn't have a "new changes must have docs" rule, so I don't mean to throw stones here -- just trying to argue that you should probably expect that poor docs are the norm and good ones the rarity.)
- hestefisk 4y agoIt’s decent but nowhere half as good as OpenBSDs documentation. Not complaining but it’s just not kept up to date in some places. Use of Jails for modern containers (eg using iocage) is a good example.
- nix23 4y agoiocage is not part of the basesystem. It's a bad example.
- tux2bsd 4y agoFrom a FreeBSD comment I made the other day: > If you want to try FreeBSD just use the Handbook, it documents FreeBSD very well. That said betrays childish aspects e.g. they refuse to list that FreeBSD can run on Linux/KVM (the mere fact it can, I'm not talking in depth instructions). (from id=32369189#32372408)
- sigzero 4y agoIt lists KVM as an option in the very first part of Chapter 2 under the synopsis. https://docs.freebsd.org/en/books/handbook/book/#bsdinstall https://docs.freebsd.org/en/books/handbook/book/#bsdinstall
- tux2bsd 4y agoThis is what I was talking about: https://docs.freebsd.org/en/books/handbook/virtualization/ https://docs.freebsd.org/en/books/handbook/virtualization/ goes way back... (and into the contained bug report) https://forums.freebsd.org/threads/please-give-some-ideas-about-the-handbook-describing-freebsd-in-virtual-machine-how-to.78285/ https://forums.freebsd.org/threads/please-give-some-ideas-ab...