From Newsgroup: comp.misc

Lawrence DrCOOliveiro wrote:

On Fri, 19 Dec 2025 13:32:25 +0000, Geoff Clare wrote:

A major exception to that is ZFS: native and very dependable in
FreeBSD (and works great as the root filesystem), but a horribly
fragile dkms mess in Linux.

ZFS is a memory hog, though, isnrCOt it

Not really when compared to e.g. modern web browsers. IIRC the rule
of thumb with ZFS is to have at least 1GB of RAM for each TB of
storage. My old file/media server had 4.5TB of storage and 4GB of RAM
and worked fine. The new one has 6TB of storage and 16GB of RAM.
(Thankfully purchased months ago before RAM prices skyrocketed.)

Best confined to a dedicated storage
appliance, not something you want to run on a general-purpose machine.

My file/media server is effectively a dedicated "appliance" although
I built it myself instead of buying something off-the-shelf. However,
I believe plenty of people use FreeBSD with ZFS as a general purpose desktop/laptop system.

Fun fact: even Oracle will not offer ZFS on its own Linux distro, but
it will give you btrfs instead.

No doubt because of the licensing issue that is the reason ZFS has to
be installed via dkms on Linux instead of being native.
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Mon, 22 Dec 2025 13:38:24 +0000, Geoff Clare wrote:

Lawrence DrCOOliveiro wrote:

Fun fact: even Oracle will not offer ZFS on its own Linux distro,
but it will give you btrfs instead.

No doubt because of the licensing issue that is the reason ZFS has
to be installed via dkms on Linux instead of being native.

Guess who controls the licensing of ZFS?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence DrCOOliveiro wrote:

On Mon, 22 Dec 2025 13:38:24 +0000, Geoff Clare wrote:

Lawrence DrCOOliveiro wrote:

Fun fact: even Oracle will not offer ZFS on its own Linux distro,
but it will give you btrfs instead.

No doubt because of the licensing issue that is the reason ZFS has
to be installed via dkms on Linux instead of being native.

Guess who controls the licensing of ZFS?

Indeed, although the situation is more complicated than that simple
phrasing implies.

When Sun open-sourced Solaris (including the original ZFS) they created
their own licence for it, and the reason ZFS can't be included in the
Linux kernel is that Sun's licence is incompatible with the GPLv2
licence used for Linux.

When Oracle bought Sun they took Solaris back to being closed source
and the community forked the OpenSolaris code as Illumos and the ZFS
code as OpenZFS. Since ownership of the original code transferred
to Oracle, only they could change it to a different licence (e.g. one compatible with GPLv2), which I suppose could be considered a form of
control over the OpenZFS licensing, but equally they can't prevent
OpenZFS (or Illumos) from being developed and distributed under the
original Sun licence.

At least, that's how I understand the current situation (IANAL).
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Tue, 23 Dec 2025 13:38:44 +0000, Geoff Clare wrote:

Lawrence DrCOOliveiro wrote:

On Mon, 22 Dec 2025 13:38:24 +0000, Geoff Clare wrote:

Lawrence DrCOOliveiro wrote:

Fun fact: even Oracle will not offer ZFS on its own Linux distro,
but it will give you btrfs instead.

No doubt because of the licensing issue that is the reason ZFS has
to be installed via dkms on Linux instead of being native.

Guess who controls the licensing of ZFS?

Indeed, although the situation is more complicated than that simple
phrasing implies.

Oracle control the copyright on (original) ZFS. They own it. They can
license it under any terms they wish. They can offer it with their own
Linux distro if they wish. But they canrCOt, or wonrCOt. But they will
include btrfs.

The only Oracle product that includes ZFS, that I know of, is Solaris.
Which has been in rCLlegacy maintenancerCY state for some decades now.

Vote of confidence in the quality of your own product? They have heard
of it!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence DrCOOliveiro wrote:

The only Oracle product that includes ZFS, that I know of, is Solaris.
Which has been in rCLlegacy maintenancerCY state for some decades now.

Only seven years actually. They made significant updates to Solaris
between 11.3 and 11.4 in order to get 11.4 certified to UNIX V7 in
2018 (and they were the first vendor to certify - AIX was two years
later).
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Jack Wallen is at it again <https://www.zdnet.com/article/freebsd-vs-slackware/>, still trying to
claim that

... FreeBSD is incredibly stable. I would go so far as to say that
it's the most stable operating system available.

This in spite of the problems he had with the install before!

He also repeats the old myth

Because FreeBSD is a descendant of the original AT&T UNIX code,
you can bet it inherited the stability of its predecessor.

None of the BSDs have *any* AT&T Unix code in them. AT&T filed an
actual lawsuit to see to that.

Interesting how he sees an inflexible, monolithic development model
as an advantage:

With Linux, the kernel is developed by one team, userland
utilities are developed by other teams, libraries are developed by
yet another, and documentation is created and maintained by
another. FreeBSD, on the other hand, does all of that via the same
team. What this does is create a highly stable, unified design
that is rock-solid and reliable in ways most other operating
systems can't touch.

If you want to argue age:

The first version of FreeBSD was released in 1993, which means it
has had a long time to mature.

then itrCOs worth noting that the first version of Linux was released
two years prior to that, so it has had an even longer time to mature.

Features that he somehow tries to suggest are FreeBSD-specific:

rCo Native support for an advanced, fault-tolerant ZFS file system
with pooled storage, snapshots, and data integrity.
rCo Lightweight containerization for running isolated services to
improve security and resource management beyond the traditional
chroot found in Linux.
rCo A built-in, efficient type-2 hypervisor for virtualization.
rCo Highly optimized TCP/IP stack, robust tools, and support for
modern protocols, perfect for network-intensive applications.
rCo ACLs, MAC frameworks (TrustedBSD), auditing, and encryption (GELI).

All of these have Linux equivalents that are as good or better.
Remember that Linux invented containerization. And I would say its
networking stack has long left the BSDs in the dust.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:

He also repeats the old myth

Because FreeBSD is a descendant of the original AT&T UNIX code,
you can bet it inherited the stability of its predecessor.

None of the BSDs have *any* AT&T Unix code in them. AT&T filed an
actual lawsuit to see to that.

Counterexample: https://github.com/freebsd/freebsd-src/blob/main/contrib/one-true-awk/awk.h

The copyright notice says 'Lucent' but that's an AT&T spinoff,
presumably the one that ended up owning that version of awk when they
did the split.

ItrCOs not a recent addition, either. The version in 4.4BSDLite2, https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/src/contrib/awk.research/awk.h,
has an explicit AT&T copyright.

Compare
with https://github.com/calmsacibis995/svr4-src/blob/main/cmd/awk/awk.h,
the same file in SVR4, and the relationship is obvious.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <wwveco3axh8.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell <invalid@invalid.invalid> wrote:

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:

He also repeats the old myth

Because FreeBSD is a descendant of the original AT&T UNIX code,
you can bet it inherited the stability of its predecessor.

None of the BSDs have *any* AT&T Unix code in them. AT&T filed an
actual lawsuit to see to that.

Counterexample: >https://github.com/freebsd/freebsd-src/blob/main/contrib/one-true-awk/awk.h

The copyright notice says 'Lucent' but that's an AT&T spinoff,
presumably the one that ended up owning that version of awk when they
did the split.

ItrCOs not a recent addition, either. The version in 4.4BSDLite2, >https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/src/contrib/awk.research/awk.h,
has an explicit AT&T copyright.

Compare
with https://github.com/calmsacibis995/svr4-src/blob/main/cmd/awk/awk.h,
the same file in SVR4, and the relationship is obvious.

--
https://www.greenend.org.uk/rjk/

The one true awk has its own license. Yes, it was from Unix awk, but
there's no AT&T kernel code in FreeBSD.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

arnold@freefriends.org (Aharon Robbins) writes:

Richard Kettlewell <invalid@invalid.invalid> wrote:

Lawrence D|ore4raoOliveiro <ldo@nz.invalid> writes:

He also repeats the old myth

Because FreeBSD is a descendant of the original AT&T UNIX code,
you can bet it inherited the stability of its predecessor.

None of the BSDs have *any* AT&T Unix code in them. AT&T filed an
actual lawsuit to see to that.

Counterexample: >>https://github.com/freebsd/freebsd-src/blob/main/contrib/one-true-awk/awk.h >>
The copyright notice says 'Lucent' but that's an AT&T spinoff,
presumably the one that ended up owning that version of awk when they
did the split.

It|ore4raos not a recent addition, either. The version in 4.4BSDLite2, >>https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/src/contrib/awk.research/awk.h,
has an explicit AT&T copyright.

Compare
with https://github.com/calmsacibis995/svr4-src/blob/main/cmd/awk/awk.h, >>the same file in SVR4, and the relationship is obvious.

The one true awk has its own license. Yes, it was from Unix awk, but
there's no AT&T kernel code in FreeBSD.

How about https://github.com/freebsd/freebsd-src/blob/main/sys/contrib/openzfs/module/os/freebsd/spl/spl_uio.c#L27
then?
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

I asserted:

The one true awk has its own license. Yes, it was from Unix awk, but
there's no AT&T kernel code in FreeBSD.

How about >https://github.com/freebsd/freebsd-src/blob/main/sys/contrib/openzfs/module/os/freebsd/spl/spl_uio.c#L27
then?

Harumph. I should not have been so glib. "There shouldn't be AT&T code
in FreeBSD" would have been better.

That code came from Sun, who paid <someone> to be able to release
Solaris as open source. So that's what you're seeing. It's part
of ZFS, which Sun developed originally.

I suspect that the AT&T copyright notices are simply copy/paste from
whatever file the Sun engineers copied before turning the file into
part of ZFS.

In any case, I doubt that there's anything illegal there. Any further questions should be taken up with the FreeBSD people.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:

A major exception to that is ZFS: native and very dependable in
FreeBSD (and works great as the root filesystem), but a horribly
fragile dkms mess in Linux.

How is ZFS fragile and messy in Linux, please? I only run it on my two
file servers, but no issues in the last decade or so. Haven't bothered
with it as root FS though.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Anssi Saari wrote:

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:

A major exception to that is ZFS: native and very dependable in
FreeBSD (and works great as the root filesystem), but a horribly
fragile dkms mess in Linux.

How is ZFS fragile and messy in Linux, please? I only run it on my two
file servers, but no issues in the last decade or so. Haven't bothered
with it as root FS though.

Every time you upgrade the kernel there is a chance that the ZFS dkms
install will fail.

I have ZFS on an external SSD that I use to back up the Linux system on
my work laptop. (Being a work machine, I don't back it up to my
personal file server.) I got so fed up with dkms install failures that
I actually resorted to ZFS-fuse and took the performance hit (since it
didn't matter too much if the backup took longer).

Reports of ZFS dkms problems on Linux are easy to find...

https://bbs.archlinux.org/viewtopic.php?id=280416

https://askubuntu.com/questions/1539311/downgrade-kernel-to-install-zfs-dkms

https://forums.linuxmint.com/viewtopic.php?t=402097

https://forum.endeavouros.com/t/cannot-install-zfs/62770

That last one includes an answer that says, "In general, when using zfs
you are better off using the LTS kernel"

That's all well and good if your hardware is supported by an LTS
kernel, but if you need a newer kernel then you run a significant risk
of dkms install failures (while you wait for a new enough LTS kernel).
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:

A major exception to that is ZFS: native and very dependable in
FreeBSD (and works great as the root filesystem), but a horribly
fragile dkms mess in Linux.

How is ZFS fragile and messy in Linux, please? I only run it on my two
file servers, but no issues in the last decade or so. Haven't bothered
with it as root FS though.

It is an "out of kernel" blob of code. So any kernel change /could/
break it (and the kernel developers won't help fix the breakage because
it is "out of kernel" code.

So fragile -- yes, any kernel upgrade could cause ZFS to not compile so
you'd have no ZFS until you download the updated ZFS compatible with
the new kernel.

Mess -- maybe a bit of over statement there. It's no more a mess than
any other "out of kernel" driver that has to be patched to keep up with internal kernel changes.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Rich <rich@example.invalid> writes:

It is an "out of kernel" blob of code. So any kernel change /could/
break it (and the kernel developers won't help fix the breakage because
it is "out of kernel" code.

So fragile -- yes, any kernel upgrade could cause ZFS to not compile so you'd have no ZFS until you download the updated ZFS compatible with
the new kernel.

If one uses a little caution and checks ZFS compatibility before
updating the kernel then this is avoided.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <sm0tswfp2ok.fsf@lakka.kapsi.fi>,
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:

Rich <rich@example.invalid> writes:

It is an "out of kernel" blob of code. So any kernel change /could/
break it (and the kernel developers won't help fix the breakage because
it is "out of kernel" code.

So fragile -- yes, any kernel upgrade could cause ZFS to not compile so
you'd have no ZFS until you download the updated ZFS compatible with
the new kernel.

If one uses a little caution and checks ZFS compatibility before
updating the kernel then this is avoided.

...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?

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <10ktbbd$ge1$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> 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?

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.

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

3. Linux performs quite well, and certainly better than Windows
(yeah, not the comparison).

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?

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.

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.

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?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 22 Jan 2026 18:51:02 GMT, Aharon Robbins wrote:

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.

HererCOs another point: different BSDs do things differently --
different as in right down to the kernel level.

Compare: 300-over Linux distros on the one hand, versus less than half
a dozen BSD variants on the other. One offers a breathtaking, even
bewildering, level of variety of choice, with minimal interoperability
issues -- i.e. minimal fragmentation. The other offers much less
variety of choice, at the cost of much more fragmentation.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 2026-01-22, Aharon Robbins <arnold@skeeve.com> wrote:

In article <10ktbbd$ge1$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> 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?

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.

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

3. Linux performs quite well, and certainly better than Windows
(yeah, not the comparison).

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?

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.

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.

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?

Yes, Linux is becoming the new Windows - if you want something to
"just work", rather than become a project in itself.

Unfortunately there are still at least two major factions in the
Linux world, the debian/Ubuntu-like and the RedHat/Fedora-like,
and if your chosen tool was developed by fans of one camp you're
on a hiding to nothing trying to use it on the rival distribution.

Yes, some things really are truly portable, but not everything,
and the higher up the functionality-stack you go the less portable
it seems to be - understandably.

Fortunately I have a nice big virtualisation host, so deploying
a VM of the appropriate flavour for a tool isn't such a big deal
(CentOS, Alpine, Ubuntu, Windows, whatever).
--
Ian

"Tamahome!!!" - "Miaka!!!"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <69727196$0$666$14726298@news.sunsite.dk>,
Aharon Robbins <arnold@skeeve.com> wrote:

In article <10ktbbd$ge1$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> 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
higher-quality than if I only run it on any one of those.

I suppose it's a matter of balancing the benefits from the
network effects one takes advnatage of when one uses Linux with
the possibility of instability when one also chooses to use ZFS
or something like it. Which is more important is, of course, an
individual (or organization) question and there's no universal
answer. But I suspect, things like the installer aside, and of
course systemd, BSD and Linux are a lot closer than most people
expect.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Fri, 23 Jan 2026 08:13:35 -0000 (UTC), Ian wrote:

Yes, Linux is becoming the new Windows - if you want something to
"just work", rather than become a project in itself.

The difference is, that was never true of Windows: itrCOs just that
people had long experience with an ever-growing collection of voodoo/black-magic tricks (e.g. registry edits) to get things working.

Unfortunately there are still at least two major factions in the
Linux world, the debian/Ubuntu-like and the RedHat/Fedora-like, and
if your chosen tool was developed by fans of one camp you're on a
hiding to nothing trying to use it on the rival distribution.

Most command-line/scripting tools are very much in common. The package
managers may be different, but thatrCOs not a major stumbling block.

Yes, some things really are truly portable, but not everything, and
the higher up the functionality-stack you go the less portable it
seems to be - understandably.

Can you give examples of such interoperability issues, other than
perhaps GUI-based ones?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 2026-01-23, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Fri, 23 Jan 2026 08:13:35 -0000 (UTC), Ian wrote:

Yes, Linux is becoming the new Windows - if you want something to
"just work", rather than become a project in itself.

The difference is, that was never true of Windows: itrCOs just that
people had long experience with an ever-growing collection of voodoo/black-magic tricks (e.g. registry edits) to get things working.

For the large part, it was (and mostly still is). And where hacks were
needed they were already known.

Unfortunately there are still at least two major factions in the
Linux world, the debian/Ubuntu-like and the RedHat/Fedora-like, and
if your chosen tool was developed by fans of one camp you're on a
hiding to nothing trying to use it on the rival distribution.

Most command-line/scripting tools are very much in common. The package managers may be different, but thatrCOs not a major stumbling block.

Yes, some things really are truly portable, but not everything, and
the higher up the functionality-stack you go the less portable it
seems to be - understandably.

Can you give examples of such interoperability issues, other than
perhaps GUI-based ones?

I'm talking about high-end applications, e.g. 3D modelling software,
video editing, media servers. At this level I just want to launch
the installer, click "yes" "yes" "yes", then get on learning / using
the tool, not spending a day tracking down some obscure dependency,
or hacking the config files because the binaries are in /usr/bin
instead of /opt/thing/bin or whatever.
--
Ian

"Tamahome!!!" - "Miaka!!!"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Dan Cross <cross@spitfire.i.gajendra.net> 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?

Third party commercial applications will run on it. Matlab will not
run on BSD unfortunately.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 24 Jan 2026 08:49:01 -0000 (UTC), Ian wrote:

On 2026-01-23, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

Can you give examples of such interoperability issues, other than
perhaps GUI-based ones?

I'm talking about high-end applications, e.g. 3D modelling software,
video editing, media servers. At this level I just want to launch
the installer, click "yes" "yes" "yes", then get on learning / using
the tool ...

Such things are usually available in the package repos: no need to hunt
down installers from third-party sites, just select from the package
manager, click rCLInstallrCY and go.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 2026-01-24, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Sat, 24 Jan 2026 08:49:01 -0000 (UTC), Ian wrote:

On 2026-01-23, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

Can you give examples of such interoperability issues, other than
perhaps GUI-based ones?

I'm talking about high-end applications, e.g. 3D modelling software,
video editing, media servers. At this level I just want to launch
the installer, click "yes" "yes" "yes", then get on learning / using
the tool ...

Such things are usually available in the package repos: no need to hunt
down installers from third-party sites, just select from the package
manager, click rCLInstallrCY and go.

"Usually". Experience says otherwise.
--
Ian

"Tamahome!!!" - "Miaka!!!"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 22.01.2026 18:51 Uhr Aharon Robbins wrote:

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.

The FreeBSD setup is indeed tui-only. After setup, you can install X11
and desktops like KDE if you like.
--
kind regards
Marco

Send spam to 1769104262muell@stinkedores.dorfdsl.de

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 25 Jan 2026 11:02:52 +0100, Marco Moock wrote:

The FreeBSD setup is indeed tui-only. After setup, you can install
X11 and desktops like KDE if you like.

KDE is moving to drop support for X11, as I understand it.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 25 Jan 2026 08:50:21 -0000 (UTC), Ian wrote:

On 2026-01-24, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Sat, 24 Jan 2026 08:49:01 -0000 (UTC), Ian wrote:

On 2026-01-23, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

Can you give examples of such interoperability issues, other than
perhaps GUI-based ones?

I'm talking about high-end applications, e.g. 3D modelling
software, video editing, media servers. At this level I just want
to launch the installer, click "yes" "yes" "yes", then get on
learning / using the tool ...

Such things are usually available in the package repos: no need to
hunt down installers from third-party sites, just select from the
package manager, click rCLInstallrCY and go.

"Usually". Experience says otherwise.

All the ones you mentioned certainly are.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <10l2pga$i97$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:

Dan Cross <cross@spitfire.i.gajendra.net> 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?

Third party commercial applications will run on it. Matlab will not
run on BSD unfortunately.

Yeah, I get that. I do wonder whether it would work with the
Linux compat stuff, but really have no idea about that. I
suppose then I would ask, given the requirement to run an
application like Matlab, which implies Linux, why bother with
ZFS?

- Dan C.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <10l8sa1$ft6$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10l2pga$i97$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:

Dan Cross <cross@spitfire.i.gajendra.net> 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?

Third party commercial applications will run on it. Matlab will not
run on BSD unfortunately.

Yeah, I get that. I do wonder whether it would work with the
Linux compat stuff, but really have no idea about that. I
suppose then I would ask, given the requirement to run an
application like Matlab, which implies Linux, why bother with
ZFS?

I don't need ZFS. There are plenty of other reasons to like BSD.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <10ld2k2$5ce$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10lbjo4$r2n$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:

In article <10l8sa1$ft6$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10l2pga$i97$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:

Dan Cross <cross@spitfire.i.gajendra.net> 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?

Third party commercial applications will run on it. Matlab will not >>>>run on BSD unfortunately.

Yeah, I get that. I do wonder whether it would work with the
Linux compat stuff, but really have no idea about that. I
suppose then I would ask, given the requirement to run an
application like Matlab, which implies Linux, why bother with
ZFS?

I don't need ZFS. There are plenty of other reasons to like BSD.

That's fine. This discussion in particular was about ZFS on
Linux, though.

It did indeed start out that way, yes.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 25.01.2026 18:56 Uhr Lawrence DrCOOliveiro wrote:

On Sun, 25 Jan 2026 11:02:52 +0100, Marco Moock wrote:

The FreeBSD setup is indeed tui-only. After setup, you can install
X11 and desktops like KDE if you like.

KDE is moving to drop support for X11, as I understand it.

IIRC Wayland is also supported on FreeBSD, but I haven't tested it.
--
kind regards
Marco
Send spam to 1769363760muell@stinkedores.dorfdsl.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Mon, 5 Jan 2026 22:50:13 -0000 (UTC), I wrote:

Jack Wallen is at it again <https://www.zdnet.com/article/freebsd-vs-slackware/>, still trying to
claim that

... FreeBSD is incredibly stable. I would go so far as to say that
it's the most stable operating system available.

This in spite of the problems he had with the install before!

Now, in a new article
<https://www.zdnet.com/article/freebsd-linux-review/>, herCOs changed
his tune ever so slightly:

Once you get FreeBSD up and running, you can absolutely rely on
it.

Getting it up and running is the issue.

Kind of walking back his claims, without actually walking them back?

He continues:

However, upon glancing at the start menu, there were very few apps
installed. So, I fired up KDE Discover, only to find out it
wouldn't work. The reason for this is PackageKit, an open-source
software suite that simplifies the installation and management of
software packages on Linux systems. Simplify, being the operative
word.

Unfortunately, PackageKit continually crashed, so KDE Discover was
useless, and all app installations had to be done via the command
line. Given I'm very comfortable with the command line, that's
perfectly fine.

On a whim, I installed GNOME, but the GDM login manager wouldn't
start, so I stuck with KDE Plasma.

So he thought he had got it running, then tried to make a change, and
failed.

That rCLrock solidrCY claim is starting to sound more and more flimsy,
donrCOt you think ...

He also repeats the old myth

Because FreeBSD is a descendant of the original AT&T UNIX code,
you can bet it inherited the stability of its predecessor.

Now herCOs got a new analogy to try to prop his rCLstabilityrCY myth:

Imagine two companies that make cars. One outsources all of its
components from other manufacturers and assembles them in its
warehouse. The second builds all of its components and also
assembles them in its warehouse.

As you might assume, the second manufacturer's cars most likely
work and perform better than the first because it knows every part
that goes into creating the car and can make all sorts of
adjustments to improve every aspect of it. The first manufacturer,
on the other hand, doesn't have nearly the control over how those
components are built.

Except thatrCOs not how car manufacture works at all. *Everybody* buys
in outsourced components for at least some parts of their vehicles.
Are cars less reliable as a result? On the contrary, they are *more*
reliable (and safer) now than they have ever been.

A similar thing applies to Linux: the common distros were always, from
the beginning, built up out of modular pieces from a great many
sources. Over time, most of the rough edges in getting those pieces
working together have been smoothed out, which is why you can have
hundreds of Linux distros available, and interoperate so easily
between them.

By contrast, the BSDs have become too accustomed to having centralized
control over everything. This is why there are so few BSD variants,
yet there is so much fragmentation between them. Another result is, as
they try to adopt components coming from the Linux world, they are
unfamiliar with how modular, collaborative software development works,
and the quality of the result suffers.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.misc

A new article from Jack Wallen, entitled rCLI found the best Linux
server distros for your home labrCY <https://www.zdnet.com/article/best-linux-server-distros-for-your-home-lab/>, recommends a few of the usual suspects for getting experience with
servers: Ubuntu Server, Debian, Rocky (as the successor to late,
lamented CentOS), plus Fedora Server, which was a new one to me.

This quote is rather telling:

The primary reason I would recommend Debian as your server OS is
its legendary stability. There simply is not a more stable OS on
the planet. Some people might argue that Slackware is more stable
because of its Unix-like nature. I say this call is too close to
make, but either OS is solid. However, Debian is easier to use.

So, what happened to rCLrock-solidrCY FreeBSD? Remember this quote from
his first article:

Sure, I talk a lot about how reliable Debian is, but even Debian
can't touch the stability of FreeBSD.

I get the feeling he isnrCOt so keen on that any more ...
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 2026-02-21, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

A new article from Jack Wallen, entitled ???I found the best Linux
server distros for your home lab???
<https://www.zdnet.com/article/best-linux-server-distros-for-your-home-lab/>,
recommends a few of the usual suspects for getting experience with
servers: Ubuntu Server, Debian, Rocky (as the successor to late,
lamented CentOS), plus Fedora Server, which was a new one to me.

This quote is rather telling:

The primary reason I would recommend Debian as your server OS is
its legendary stability. There simply is not a more stable OS on
the planet. Some people might argue that Slackware is more stable
because of its Unix-like nature. I say this call is too close to
make, but either OS is solid. However, Debian is easier to use.

So, what happened to ???rock-solid??? FreeBSD? Remember this quote from
his first article:

Sure, I talk a lot about how reliable Debian is, but even Debian
can't touch the stability of FreeBSD.

I get the feeling he isn???t so keen on that any more ...

Nah, he's just imitating AI - saying the first thing that come sinto his head. --- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:

I get the feeling he isn't so keen on that any more ...

Umm... it's an article about Linux distros. Why would anyone mention
BSD?
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 21 Feb 2026 15:39:26 -0500 (EST), Scott Dorsey wrote:

On Sat, 21 Feb 2026 00:11:07 -0000 (UTC), Lawrence DrCOOliveiro wrote:

I get the feeling he isn't so keen on that any more ...

Umm... it's an article about Linux distros. Why would anyone mention
BSD?

After he was so keen on it before?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <10lbjo4$r2n$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:

In article <10l8sa1$ft6$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10l2pga$i97$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:

Dan Cross <cross@spitfire.i.gajendra.net> 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?

Third party commercial applications will run on it. Matlab will not
run on BSD unfortunately.

Yeah, I get that. I do wonder whether it would work with the
Linux compat stuff, but really have no idea about that. I
suppose then I would ask, given the requirement to run an
application like Matlab, which implies Linux, why bother with
ZFS?

I don't need ZFS. There are plenty of other reasons to like BSD.

That's fine. This discussion in particular was about ZFS on
Linux, though.

- Dan C.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.misc

At Fri, 6 Feb 2026 06:14:31 -0000 (UTC), Lawrence DrCOOliveiro
<ldo@nz.invalid> wrote:

On Mon, 5 Jan 2026 22:50:13 -0000 (UTC), I wrote:

Jack Wallen is at it again <https://www.zdnet.com/article/freebsd-vs-slackware/>, still trying
to claim that

... FreeBSD is incredibly stable. I would go so far as to say
that it's the most stable operating system available.

This in spite of the problems he had with the install before!

Now, in a new article
<https://www.zdnet.com/article/freebsd-linux-review/>, herCOs changed
his tune ever so slightly:

Once you get FreeBSD up and running, you can absolutely rely on
it.

Getting it up and running is the issue.

Kind of walking back his claims, without actually walking them back?

He continues:

However, upon glancing at the start menu, there were very few apps
installed. So, I fired up KDE Discover, only to find out it
wouldn't work. The reason for this is PackageKit, an open-source
software suite that simplifies the installation and management of
software packages on Linux systems. Simplify, being the operative
word.

Unfortunately, PackageKit continually crashed, so KDE Discover was
useless, and all app installations had to be done via the command
line. Given I'm very comfortable with the command line, that's
perfectly fine.

On a whim, I installed GNOME, but the GDM login manager wouldn't
start, so I stuck with KDE Plasma.

So he thought he had got it running, then tried to make a change, and
failed.

That rCLrock solidrCY claim is starting to sound more and more flimsy, donrCOt you think ...

He also repeats the old myth

Because FreeBSD is a descendant of the original AT&T UNIX code,
you can bet it inherited the stability of its predecessor.

Now herCOs got a new analogy to try to prop his rCLstabilityrCY myth:

Imagine two companies that make cars. One outsources all of its
components from other manufacturers and assembles them in its
warehouse. The second builds all of its components and also
assembles them in its warehouse.

As you might assume, the second manufacturer's cars most likely
work and perform better than the first because it knows every part
that goes into creating the car and can make all sorts of
adjustments to improve every aspect of it. The first manufacturer,
on the other hand, doesn't have nearly the control over how those
components are built.

Except thatrCOs not how car manufacture works at all. *Everybody* buys
in outsourced components for at least some parts of their vehicles.
Are cars less reliable as a result? On the contrary, they are *more*
reliable (and safer) now than they have ever been.

A similar thing applies to Linux: the common distros were always, from
the beginning, built up out of modular pieces from a great many
sources. Over time, most of the rough edges in getting those pieces
working together have been smoothed out, which is why you can have
hundreds of Linux distros available, and interoperate so easily
between them.

By contrast, the BSDs have become too accustomed to having centralized control over everything. This is why there are so few BSD variants,
yet there is so much fragmentation between them. Another result is, as
they try to adopt components coming from the Linux world, they are
unfamiliar with how modular, collaborative software development works,
and the quality of the result suffers.

Almost like a BSD "Cathedral" vs. the Linux distro "Bazaar"

From The Jargon File (version 4.4.7, 29 Dec 2003) [jargon]:

bazaar
n.,adj.

In 1997, after meditating on the success of {Linux} for three
years, the Jargon File's own editor ESR wrote an analytical paper
on hacker culture and development models titled The Cathedral and
the Bazaar. The main argument of the paper was that {Brooks's
Law} is not the whole story; given the right social machinery,
debugging can be efficiently parallelized across large numbers of
programmers. The title metaphor caught on (see also {cathedral}),
and the style of development typical in the Linux community is
now often referred to as the bazaar mode. Its characteristics
include releasing code early and often, and actively seeking the
largest possible pool of peer reviewers. After 1998, the evident
success of this way of doing things became one of the strongest
arguments for {open source}.
--
-v System76 Thelio Mega v1.1 x86_64 Mem: 258G
OS: Linux 6.18.9 D: Mint 22.3 DE: Xfce 4.18 (X11)
NVIDIA GeForce RTX 3090Ti (24G) (580.105.08)
"If a program is useless, it must be documented."
--- Synchronet 3.21d-Linux NewsLink 1.2