SCIENTIFIC-LINUX-USERS Archives

January 2020

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Konstantin Olchanski <[log in to unmask]>
Reply To:
Konstantin Olchanski <[log in to unmask]>
Date:
Fri, 31 Jan 2020 18:30:30 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (102 lines)
On Fri, Jan 31, 2020 at 02:42:53PM +0100, Jean-Paul Chaput wrote:
> 
> Just to supply another point of view, I'm sticking (i.e. the whole
> network I manage) to SL7 (and CentOS8 afterward) because RHEL is the
> only open source OS that is qualified for big VLSI CAD tools
> (Cadence, Mentor, Synopsys). This is my only reason, but it's a
> mandatory one...
> 

Definitely valid consideration. In data acquisition the scope
of what we must provide is very small, but still we use some
big commerial tools, FEMLAB (electric and magnetic finite element
simulations), assorted FPGA compilers (Altera, Xilinx),
and they all seem to work ok on both centos and ubuntu. Some other
major tools, SolidWorks (3D mechanical design), Altium (PCB design),
do not run on Linux at all (any Linux), so those people are
suck with Windows laptops and desktops.

Also luckily, our stuff does not need to be qualified or certified,
so as long as things work and lights blink and data flows, all is good.

Actually, for vendor support, I see a consolidation on Debian-based Linux,
RaspberryPi comes with Debian based OS, Nanopi seems to be Ubuntu, Phidget
toys come with Debian drivers, a brand new board with Xilinx FPGA just arrived
in the mail, also runs ARM Debian. If not Debian, then it is a custom rolled userland,
often based on busybox. No RedHat/Centos/Fedora anywhere in sight.

>
> I take this occasion to send a big thank for the SL team and it's
> great jobs all those years.
> 

Seconded. Certainly carried us through what, 15 years of worry free
and trouble free Linux OS? Yup, since SL3 in 2005 on our first 64-bit AMD Opteron
machines, until 2020 today.

K.O.



> 
> Best regards,
> 
> On Thu, Jan 30, 2020 at 06:25:34PM -0800, Konstantin Olchanski wrote:
> > On Thu, Jan 30, 2020 at 05:57:24PM -0800, Yasha Karant wrote:
> > >
> > > At this point in terms of application support for EL 7 (including SL
> > > 7) from external entities (such as Calibre -- there are others), I
> > > am going soon to be forced to go to another Linux. ...
> > > 
> > > Any advice would be appreciated.
> > > 
> > 
> > We are looking at Ubuntu -
> > 
> > - direction is very stable, each next release is "the same as the previous release",
> >   no surprises, no strange changes, no confusion.
> > - trivial upgrade path from version N to version N+1. (works as well as MacOS).
> > - easy to google problems and solutions
> > - works well on laptops (Red Hat was always behind on Wifi and other important drivers)
> > - commonality with Raspberry Pi and other SoC systems (everything is Debian or Ubuntu based, nothing is Red Hat based).
> > - many hardware vendors now supply Ubuntu and Debian centric drivers and support
> > 
> > Now that both Ubuntu and Red Hat use systemd, NetworkManager & co management
> > of both has become very similar.
> > 
> > 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).
> > 
> > Since building rpm packages was always a major pain, I am not sure I want to figure
> > it all out again with CentOS/EL-8 just to find out that I cannot (or I can?) build
> > RPM packages that work on all three - el6, el7 and el8. Might as well cut out
> > the middleman and use "git pull; make install" to install and manage the 2-3-4 scripts
> > that I manage with RPM packages right now.
> > 
> > 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".
> > 
> > -- 
> > 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
> 
> -- 
>       .-.     J e a n - P a u l   C h a p u t  /  Administrateur Systeme
>       /v\     [log in to unmask]
>     /(___)\   work: (33) 01.44.27.53.99              
>      ^^ ^^    cell:      06.66.25.35.55   home: 01.47.46.01.31
> 
>     U P M C   Universite Pierre & Marie Curie
>     L I P 6   Laboratoire d'Informatique de Paris VI
>     S o C     System On Chip

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

ATOM RSS1 RSS2