> 
> > - direction is very stable, each next release is "the same as the previous release",
> >  no surprises, no strange changes, no confusion.
> 
> Mir -> Wayland, Upstart -> systemd, Unity -> Gnome Shell... sure were surprises to me, direction rather seems "not that stable" etc.
> 

I agree, but Red Hat went the same direction. Wayland, systemd, gnome.

>
> > - trivial upgrade path from version N to version N+1. (works as well as MacOS).
> 
> Nice, but not all that important in a professionally managed environment. And available on EL recently too (not sure how trivial, but it does exist).
> 

Hmm... "professionally managed" is a charged word. We have to manage
a large number of data acquisition stations, each one unique, each one with
it's own schedule and it's own users, some of them in remote locations (SNOLAB, CERN,
luckily somebody else now takes care of T2K/ND280 in Japan).

And there is a real problem. We have many data acquisition stations running SL6
and updating them to a current OS requires physically going to each station,
booting them from a USB installer, wiping the old OS, installing new OS, restoring
files from backups, the works. (no, in some physical locations, we cannot network-boot
the installer, cannot use a network-based kickstart, have to boot
from physical USB installer flash drive).

> 
> > - many hardware vendors now supply Ubuntu and Debian centric drivers and support
> 
> Which vendors support upgrading the Firmware on servers (I'm not talking about desktops or laptops) from a running Ubuntu system? (That's a genuine question - this is the main reason keeping me from considering generally running the latest Ubuntu LTS on all our bare metal and doe all the rest in VMs or containers).
> 

Since I write firmware myself, the function to upgrade the firmware on
a running system without having the reboot the OS is pretty much
the first thing that I implement (during firmware development,
rebooting the OS to load each new firmware test version gets old very quickly).

So I find it annoying that hardware vendors creare special "mystique" about
firmware updates, require special magical tools, dances with rubber chicken, etc.

If it were up to me, I would always provide the firmware binary file and the statically
linked linux executable (so it runs on any linux, no matter what userland shared libraries
are available) to load the binary file into hardware, to read the firmware from
the device (so you can clone firmware from one device to another) and to verify
the loaded firmware (so you can check that the correct stuff is loaded).

That said, "bum" firmware and "bricked" hardware is a fact of life that one
has to deal with regardless. Against the first one, you first update your test
machine, against the second one you learn to use the JTAG programmer tools
and dongles.

>
> > Now that both Ubuntu and Red Hat use systemd, NetworkManager & co management
> > of both has become very similar.
> 
> Well, yes, but then Ubuntu invented "netplan"...
> 

What tends to work well and is reasonbly reliable and fool proof
is "ifconfig" commands in /etc/rc.local. Not for everybody and in every
situation. But works ok in "build once, run for 5 years; touch nothing,
change nothing" physics experiments.

systemd and NetworkManager add unwanted dynamism and unpredictability
to booting, running and shutdown.

(FWIW, I was going to look an Ubuntu's netplan next week...)

> > Only big remaining difference is the package manager - apt vs rpm/yum, but even
> > here Red Hat have muddied the waters by switching to dnf and a new package format
> > (new checksum algorythms).
> 
> dnf is a replacement for yum, not rpm (which corresponds to dpkg, not apt), and supposed to be backward compatible. RPM package checksums have evolved in the past, without serious issues, with backward compatibility and options to create packages usable on older systems on newer ones. I haven't tried EL8 in this respect, but I doubt this has all changed.
> 

My typical need is to create a package that will install 1 perl script into /usr/bin.

15 years ago, RPM did not have an example of how to do this easily,
today, RPM does not have an example of how to do it easily. (no I am not
building gcc from a tarball with local patches).

> 
> I won't comment on "make install" vs. proper software management on production systems with packages.
> 

I love to do proper software management using a proper package manager,
but I question why developers of package managers (rpmbuild, I am looking at you!)
do not work extra hard to make it easier for me.

(Then soap, wash, rince, repeat for Debian, FreeBSD, MacOS).

> > I have been saying the above to everybody for the last 6 months and not a single
> > person so far had answered with "let's stick with Red Hat" or "let's stick with Red Hat
> > because of important reason X".
> 
> Well we had a couple of folks speaking up here already.
>

I guess I meant our local users here, not the whole universe. Sorry for confusion.


>
> There are a few more major differences (and the different package managing systems are rather peanuts compared to those):
> 
> * Support life time. EL: 10 years (admittedly, with limitations during the last 3). Ubuntu: 5 years (but limited to 3 years for a great many packages - especially quite a few important on desktops/laptops).
>

This turned out to be the wrong life expectancy measure. What we see is the prefectly
servicable SL6 is obsoleted overnight by ROOT (root.cern.ch) suddenly starting
to require C++11. Then things like MediaWiki ask for newer PHP, certbot asks
for newer python, etc. So you install devtoolset for C++11, PHP from webtatic,
pyhton3 from EPEL, but can this mongrel OS still be called SL6?

The usual mantra is "never upgrade!", but users demand "upgrade early, upgrade often!". Rock, hard place, etc.

> 
> * Stable kernel ABI. EL: stable over the whole lifetime for whitelisted interfaces, stable within minor releases for others. Ubuntu: no such thing. Actually, may backport ABI-changing changes from the lates mainline kernel anytime.
> 

Not in SL-6, not in CentOS-7. Each new kernel update breaks nvidia and/or ZFS drivers.

True, the (very simple) kernel drivers that I write and maintain do load and
work with each kernel, so some stability, for sure. (But latest kernels complain,
"you must recompile you driver with new GCC to deal with latest Intel CPU exploits").

>
> * Hardware enablement: EL: at least 5-7 years, with a single kernel flavour (with the above advantages regarding ABI stability). Ubuntu: May require "HWE" kernels (different base version) rather early. Actually will upgrade you automatically to those unless you're using a server installation.
> 

No way around this, if stock kernel does not have a driver for your hardware,
you have to use some other kernel, by hook or crook. Build kernel from sources,
in the worst case. True for any Linux, for any OS, Windows, BSD, etc. Only MacOS
has hardware and software in lock-step. (severe and unescapable lock-step).

>
> Again, I like Ubuntu. Nor do I want to start a big argument. Just felt compelled to add a few minor pieces of information to your statements.
>

Yes, good discussion. A shift away from Red Hat Linux after 15 years with SL,
and not quite 10 years with RHL (before "E") is a big deal, worthy of
big argument.

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada