Removing documentation

[Michelle Sullivan]

Royce Williams wrote:
> On Fri, Feb 12, 2016 at 5:56 AM, Jim Ohlstein <jim at ohlste.in> wrote:
>
>
>   
>> FreeBSD is different in that regard. The ports system is one of the things
>> that makes it great. Being able to choose whether to compile everything,
>> compile some ports and use official packages (or non-official repos) for
>> others, or entirely to use pre-built binaries is one of the great strengths
>> of FreeBSD and is one of the features that distinguishes it from most
>> flavors of GNU/Linux. There are even tools for creating repos fairly easily.
>> Have you ever tried to write a spec file for an RPM based distro? Ugh!
>> Unfortunately, dpkg is not designed for people in those first two categories
>> above. It can be made to work, but requires much more effort. Add in systemd
>> and the nightmare continues...
>>     
>
> Interestingly, my experience -- after having been an admin for 70+
> FreeBSD boxes for a 50K+ ISP user base for 12 years -- is different.
>
> It is the apt-get system that has never failed me, and it is FreeBSD
> that has regularly left me with a software installation so wrecked
> that I had to deinstall every third party package and start over, or
> spending hours scripting a search-and-destroy mission to clean up the
> mess.  When people with significant FreeBSD experience regularly
> recommend the "nuke it from orbit" remedy regularly to people in the
> forums, that's a sign that something is deeply wrong.
>   

And from my experience of building and running SORBS over the last 13-14
years on Linux and FreeBSD...

Linux:

rpms (centos) - every system that used them ended up being replaced
because of horrible dependency loops.
dpkg (debian) - every couple of years something needs to be upgraded and
the OS has to be nuked from orbit (9 out of 10 libc patch)
tgz (slackware) - everything compiled from source management was a
nightmare but *never* resulted in unbootable systems... dependency -
well you had to manage that yourself.

FreeBSD:

source upgrade (OS): only failed at 5.x and that was bad.
freebsd-update (OS): several failures - particularly 9.x, particularly
around 9.3-p5 and 9.0->9.3 (in one jump)
ports (pre-pkg) from source: mostly worked fine - problems with options
changing and defaults changing.
ports (post pkg) from source: exactly the same problems as pre-pkg plus
occasionally the DB would get corrupted and then you have to nuke the
entire package system from orbit and reinstall all the ports.
ports (pre-pkg) from precompiled: finding the right version for the
system was always the issue because it was generally a moving target
about what was on the system and what was not.
ports (post-pkg) from precompiled: pretty much nuke and reinstall
everything everytime to be 100% sure it's all done which pkg makes
trivial... except when the DB blows up... which is when you need to have
a list of your ports that you need on the system...

Note: I don't use pkg at all anymore, don't even bother testing, gave up
on that when it nuked a remote system and left me unable to get in...
which resulted in an OS reload (from late 8.x IPMI remote consoles don't
work so when pkg nukes the sudo install and you have only allowed ssh
logins as a user (not root) - which is the FreeBSD default... well
rather than spreading FreeBSD in the company (to 1000's of machines) we
(others in the company) are now looking at the alternative and replacing
the 50+ SORBS ones... Congrats guys!)

> My Linux/dpkg/apt-get experience is entirely different.  I have pushed
> dpkg-based systems through three major OS/ABI upgrades with one or two
> commands, almost without having to perform any manual steps at all --
> and when I did, someone had captured them as part of the package
> system, informed me about it up front in the release notes, and almost
> always empowered me to run a simple package command to do what needed
> to be done automatically.  To be clear, this is not "hey, the default
> version of perl has changed, please do one of these five things, and
> if they don't work, delete everything and start over"
> /usr/ports/UPDATING equivalent.  These were genuinely deep things that
> justifiably required a human to decide which way they wanted to go.
> And there was no ambiguity in the official documentation about which
> commands I needed to run -- because there was a single, official
> method included in the base OS.
>
> Managing software across FreeBSD OS upgrades, by contrast, is replete
> with manual software removal and reinstallation steps, hunting down
> old library dependencies, etc.  Recurring "nuke it from orbit"
> debacles, coupled with the necessity of /usr/ports/UPDATING, makes the
> ports system an order of magnitude less reliable than stock
> Debian/Ubuntu ports.  This upgrade/management friction makes me far
> less likely to want to try to upgrade a FreeBSD system, which, in
> turn, when faced with a new install of some kind, makes me far more
> likely to use and recommend Ubuntu server over FreeBSD.  This pains me
> greatly, as I have been a FreeBSD advocate/fan for fifteen years, and
> I believe that FreeBSD's tightly integrated kernel/userland/docs has
> the potential to be far superior.
>
> In the meantime, we keep reinventing the wheel.  And each time,
> /usr/ports/UPDATING survives.  And each time, the list of possible
> software management tools grows, such that each of them has to be
> mentioned in /usr/ports/UPDATING.  This is another sign that something
> is deeply wrong.  Any software management solution that does not kill
> /usr/ports/UPDATING forever is insufficient.
>   

Personally I think the system should be usable without /usr/ports at
all.... which funnily enough is (was) the case before pkg (is still on
my systems but that's another story.)

Anyone the nice thing is I now I just sit back and devote my time to
important things.

-- 
Michelle Sullivan
http://www.mhix.org/