intro
I'm often asked why I prefer FreeBSD, other BSDs, or Solaris over
Linux. Here is an attempt to detail every instance in which Linux
infuriates me. Perhaps the Linux community can use this information to
help improve itself. I'm not interested in feedback on these comments
unless it will specifically solve a problem detailed here. Obviously,
because of the preponderance of minorly different Linux distributions,
these comments may not apply to all versions. I primarily have used
RedHat/Fedora/Mandrake systems.
Now, I certainly hate things about other systems as well - Windows,
Solaris, even my first love, FreeBSD. But Linux far and away takes the
cake in general annoyance, probably because at first glance it appears
like it would be pretty decent...
non-functional package management
Tue Mar 8 16:23:39 PST 2005
Today I was working on upgrading zlib installed on an old Mandrake
version, because of numerous security problems. Of course, I wondered
"How much depends on zlib anyhow?" man rpm. rpm -R will tell you what
packages a package depends on, but not what it requires. pkg_info
has flags to tell you either. I asked linux admins if I was missing
something. They said that I should rpm -e zlib and see what depenencies
cause the operation to fail. I was then told that I could write a for
loop or some perl to determine this as well. Of *course* I could, I'm
not bloody stupid - but the fact that rpm doesn't have the capability to
do this easily is indicative of how lame of a package management system
it is.
In any event, to update this, I have to hunt down the SRPMs for a
newever version of Mandrake and rebuild them on an older version.
nonstandard package versioning
Tue Mar 8 16:30:39 PST 2005
My work is security. A fair amount of my time I have to spend assessing
security vulnerabilities and determining what maintenance actions have
to be taken in a heterogenous environment. RedHat and its derivatives
have the brilliant strategy of not actually updating system packages,
but instead patching old versions and bumping revision levels. I
understand the reasoning behind this. However, in practice, it's a
crap idea.
Network vulnerability assessment tools can't determine what versions of
software you're running without actually attempting to exploit/crash
those services. Instead of me tracking one version number across
multiple platforms, I have to remember what version number and revision
in each RedHat-type distro contains the appropriate security fixes. The
resulting confusion in many cases contributes to the original security
problem.
Let's see, what's the difference between openssl-0.9.7d-1 and
openssl-0.9.7d-1.1.101 again?
nonstandard packaging, period
Tue Mar 8 16:40:54 PST 2005
Another thing I hate about how RedHat distros work is that everything is
split from its vendor-distributed packaging into blah and blah-devel.
This leads to sensible people doing things like expecting programs that
require openssl to build, when openssl is installed. Of course, you
need openssl-devel or "libopenssl", a package that RedHat invented, not
distributed by openssl.org at all. Almost useless for most people,
and makes the already cluttered package list even worse.
dependency hell
Tue Mar 8 16:44:28 PST 2005
# rpm --rebuild openssh-3.9p1-3mdk.src.rpm
Installing openssh-3.9p1-3mdk.src.rpm
error: failed build dependencies:
pam-devel is needed by openssh-3.9p1-3mdk
tcp_wrappers-devel is needed by openssh-3.9p1-3mdk
db1-devel is needed by openssh-3.9p1-3mdk
XFree86-devel is needed by openssh-3.9p1-3mdk
gtk+2-devel is needed by openssh-3.9p1-3mdk
Openssh requires XFree86 and gtk+? Actually, no, IT FUCKING DOESN'T.
This is typical of Linux distributions - requiring ridiculous amounts
of useless dependencies, making it a pain in the ass to have a minimal
install. Now what am I supposed to do? Install XFree86 libraries,
build openssh and then forcibly remove them? Or shall I just hunt
down a spec file and start rolling my own package? I guess the easiest
is to install the srpm, edit the spec and rebuild. Just what I need,
a package management system that's harder to use than just building
from source.
If this were FreeBSD and these dependencies were on by default(which
they aren't, thank god), I'd just "portupgrade openssh -M
WITHOUT_USELESS_CRAP=yes". What I'm probably going to push for is moving
to using pkgsrc under Linux, and Solaris for that matter.
outdated concepts
Tue Mar 8 20:49:27 PST 2005
Ah, procfs. How do I loathe thee? You make concepts like chrooting and
jails far more painful, you hinder the implementation of trusted OS
functionality, you've caused loads of race conditions and other security
problems and access control bypasses...and for some unknown reason,
Linux loonies like to configure systems by echoing various crap to tiny
hidden corners of you - the worst UI for such configuration since ndd. I
was overjoyed to find that RedHat can actually use sysctl.
corporate backing and EOLs
Tue Mar 8 20:58:43 PST 2005
Sun has provided support and update for Solaris 8 for years and years.
It was initially released what, 5 years ago? I still actively get
patches and updates for it. The FreeBSD 4.x branch was probably started
sometime around that timeframe, and is still supported as well. Before
the switch to Fedora, RedHat releases were being EOLed after a year or
two, leading to a mess of 7, 8, and 9 installs all over. Fedora Legacy
gives you only 1.5 years of support before you're screwed. Of course,
you can pay for corporate versions of various Linux distros, but why?
One source of irritation about Linux has always been that there is
a distinct lack of production-ready, well-supported distributions,
even though there are ridiculous amounts of "Joe's -O3 Linux
distro featuring something to make it behave like a BSD" style
distros. Basically, there's Fedora Core(which gets EOLed far too
fast), Debian(which is way too crufty and old in the stable branch,
with a horrible installer), and Slackware(honestly, not much wrong
there, but hard to convince people to use). I like some things about
distros like SuSE, but you do have to buy them if you want real support
and access to ISOs right after release.
FreeBSD has always been free, non-commercial, and well-supported.
Solaris is now "free" for some purposes and is updated long after
release. If you have an environment of hundreds of Linux machines, your
choices are to shell out cash, spend half your time upgrading machines,
fall hopelessly out of date with security updates, or roll your own
distribution.
bourne, bourne again, what's the difference?
Tue Mar 8 23:51:21 PST 2005
I can't count how many times I've had to patch up someone's boneheaded
shell script that breaks under almost every OS except Linux, because
RedHat uses bash as /bin/sh. People keep using #!/bin/sh in their
scripts, when they really mean /bin/bash. Linux users seem not to even
know how to write Bourne shell scripts at all, or to know what the
difference is. There's this perception that if you write something that
only runs on Linux, it's somehow better than something that only runs on
Solaris.
Then there's the fact that /bin/bash is a dynamically linked, complex
shell. Root's shell should not be bash, not zsh, or perlsh, or any crap
like that. It should be simple, old, /bin/sh. I've personally seen
disasters that have occured because of dynamic linking of the root
shell, both under Linux and FreeBSD. FreeBSD recently moved to having
dynamic linking in the base /bin system, but does include /rescue with
statically linked binaries for when things go terribly wrong. Linux
doesn't. So when things go terribly wrong, you're terribly fucked.
/bin/random
Wed Mar 9 00:14:54 PST 2005
Fine, RedHat - just put every single program in /bin or /usr/bin, or
their sbin equivalents. Ignore the /usr/local or /opt conventions. I
guess it's completely irrelevant to you that some people might want to
have site-specific stuff in /usr/local, or they might want to find out
what stuff came with the system instead of the stuff that was added from
third party packages later on. But wait - there *is* no system - Linux
is just a kernel, so they say. So the userland is an arbitrary jumble of
whatever some distro-roller feels like. Lovely.
FreeBSD has a clear concept of this. There's a base system, which you
can update, recompile and merge quite easily for upgrades, and then
there are things that are added third-party, through packages or ports.
There's accountability and centralization, not a bunch of crack-addled
johnny-come-lately college linux geeks randomly slamming a bunch of
interdependent packages together until a base install takes up over 1G
and no one knows what a standard configuration is.
stale or bleeding
Wed Mar 9 09:36:25 PST 2005
"Use Debian", you say. Which branch, the "stable" one where packages
are usually years out of date? Or one that's called "testing", but is
"really stable"? I like this quote by Jem Matzan: 'The Debian project
seems to be the epitome of the misguided belief that old is equivalent
to stable. Packages in the Debian "stable" or even the "testing" and
"unstable" branches can be months or years old.'
the rpm show
Wed Mar 9 09:48:44 PST 2005
Yes, I realize this isn't supposed to be the rpm hate list. But one last
one, please. Removing an rpm removes files that have changed from their
original checksum - i.e., config files that you'll probably be wanting
after you're done upgrading. Nuff said.
ubuntu
Sun Aug 12 16:16:42 PDT 2007
So, to test out some bugs in native Linux, I installed an Ubuntu VM, which
took an absurdly long time. After installation, I find out that you can't
even decide what stuff you have installed - if you want to remove say,
a garbage package like Evolution, the package manager wants to uninstall
the whole ubuntu-desktop package. Some things never change - even supposedly
advanced and user-friendly distributions are still incredibly sloppy. Oh,
and can someone provide me with a good reason that I should watch a splash
screen with a progress bar instead of something actually USEFUL, like boot
messages?
Debian. OpenSSL.
Mon May 19 16:53:19 PDT 2008
Enough said.