From: cross@spitfire.i.gajendra.net
In article <69727196$0$666$14726298@news.sunsite.dk>,
Aharon Robbins wrote:
>In article <10ktbbd$ge1$1@reader2.panix.com>,
>Dan Cross wrote:
>>...or you could just run FreeBSD and avoid the whole issue. Why
>>bother with Linux? What's so special about it that people feel
>>_compelled_ to run it?
>
>I don't use ZFS, so maybe your question is what's so special
>about the combination of ZFS and Linux?
Yes, it was specifically about Linux and ZFS.
I do have a few follow-ups about some of your comments; inline.
>But if you're really asking the general question, I can tell you:
>
>1. The user land is usually based on the GNU tools: No arbitrary limits
>applies. I have no idea if there are still fixed limits in
>the BSD user land.
My sense is that, at this point, pretty much all of these have
been removed. Having seen the source for many of the GNU tools,
I'd put the BSD tools somewhat above them in terms of quality
and polish. I would counter that most have useful man pages,
while some GNU tools seem to still rely on `info` for their
primary documentation.
>2. These days, just about *everything* just works, without fuss or muss.
>
> - Install on even fairly new hardware goes smoothly
> - Installers are usually graphical
> - One's choice of GUI environments (I use Ubuntu Mate)
> - Software updates (at least on Ubuntu) work super smoothly
> - Installing additional software is trivial
I don't have many problems installing things on FreeBSD, it does
support multiple desktop environments, and installation of third
party software is trivial. In the next release, the base system
will be changed to use the package management system, so updates
to the base system will use the same mechanism as third party
software.
The graphical installer thing is kind of an odd one to me; I've
heard this several times before. I get that the TUI may not be
to everyone's taste, but surely you don't install the OS all the
time?
On the other hand, look at the installation process for (say)
Arch. Not only is it non-graphical, it's extremely manual. And
I'm often surprised at how many things are missing from from
either the Pacman or AUR repos: the `oo2c` compiler came up in
comp.lang.oberong the other day; it wasn't on my Arch system,
but worked just fine on FreeBSD.
>3. Linux performs quite well, and certainly better than Windows
>(yeah, not the comparison).
I think performance of BSD relative to Linux is quite good,
though it likely depends heavily on what one is doing. Netflix
pushes hundreds of gigabits through the FreeBSD networking stack
on a single system; but UFS always "felt" slower than ext2
because of the way they handled metadata updates; on the flip
side it didn't tend to lose my data. :-)
>I don't remember which BSD I recently tried to bring up in a VM
>(maybe FreeBSD) but installation was like jumping back 40 years
>in time to the ASCII-art spinning wheel. It didn't even come up
>with a GUI, or else it was X with TWM and no menus, or something
>ridiculous like that.
>
>I'll agree. A lot of it is familiarity, but also the fact that I see no
>compelling reason to switch. Why climb a brand new learning curve
>just to get to the same point I'm already at?
Well, in this specific case, it was because ZFS is maintained
out of tree, and a kernel update could break the filesystem. If
the system in question is, say, an NFS server or something, it
seems unecessarily risky to use ZFS on Linux just to run Linux.
>I have real work to get done, I don't need to spend weeks learning
>how BSD does the same thing I already know how to do.
Would it really be weeks, though?
>4. The elephant in the room: Everybody else is on Linux, which
>means if I want something commercial that only runs on Linux, I
>can get it. Not so on *BSD.
That's why I'm sitting in front of a Mac. :-D Note this is
also the strongest argument for Windows.
This is admittedly a weak area in the BSD ecosystem, but I would
counter that it's also somewhat niche.
The BSDs often have Linux compat layers for these use cases,
though I confess I've never used them and don't know how well
they would fare for complex use cases.
It bears point out, however, that ironically we're talking about
this because of software that's native and integrated into
FreeBSD, but requires out-of-tree shenanigans that are fragile
on Linux. This is, perhaps, a rare case of something that runs
natively on FreeBSD, but requires hacks to run on Linux, rather
than software native to Linux that requires hacks on FreeBSD.
>I've been using Linux as my daily driver since mid-1997. It's done
>real well for me. Why switch to something that I don't see is
>better?
To be clear, I'm not necessarily saying that you should.
But if you wanted to do something esoteric (like run ZFS on
Linux, which I consider mildly esoteric) that works better on
BSD, one must ask, why try to force that square peg into a
round hole? Linux has perfectly adequate in-tree filesystems
that perform well and are robust; on the other hand, as pointed
out, a kernel update could break your system pretty
spectacularly; workarounds exist, sure, but why open yourself up
to that possibility if you don't have to? I mean, if it's just
as a learn exercise, then ok...but for production systems? I'm
not sure that's a great idea.
There's also the matter that the rate of change on Linux is high
and distros change things in seemingly gratuitous ways. systemd
vs system V-style init vs /etc/rc and inittab, and so on are the
obvious examples, but I would point to things like the `ip`
command replacing `ifconfig` and `ss` replacing `netstat` as
more subtle examples.
I think the first time I installed Linux was in 1993 (or perhaps
early 1994), and at the time it reminded me of SunOS; not when I
look at it, it's nothing like that at all. I think we should
agree that the Linux you ran in 1997 just isn't the same Linux
as today, and we are all constantly changing the way we do
things as Linux evolves. This isn't bad per se, but it does
weaken the argument about having to relearn things, though
granted it happens in a much more incremental, ship of Thesius
kind of way. Nevermind that plethora of distributions that all
do things slightly differently (though in fairness there seem to
be only a few family strains...).
There's also the matter of Linux being a near monoculture. Just
as with biological systems, these are susceptible to all sorts
of external dangers, so it is with software. Diversity in terms
of the systems we run produces, I think, more robust and higher
quality software. My own experience is that when I write
software that make sure runs across a variety of different
systems (Linux, *BSD, macOS, illumos...) the result tends to be
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
