from:"Konstantin Olchanski"

On Sun, Aug 08, 2021 at 07:38:07PM -0700, Yasha Karant wrote:
> Apple products and the Apple OS (currently based upon BSD) are
> proprietary.  If one needs service (hardware or software), one
> effectively must use an Apple store (at least in the USA).  The
> colleague is retired and has little money (this is the downward
> mobile USA economy save for the neo-liberal profiteers).  She got a
> used/refurb Lenovo Carbon X1 and I just installed a working Linux on
> it -- everything worked "out of the box".

I am sympathetic with people on fixed income. All of us heading in that 
direction.

But as the saying goes, a stingy person pays twice, a fool pays forever.

A frugal person would do a careful evaluation after assigning $$$ numbers
to the value of the data and to the number of hours spent (now and forever),
as balanced against the $$$ cost of hardware, software and services.

Cheapest solution may be a backblaze subscription. You never know until
you do the numbers.

You cannot have something for nothing, you have to spend real $$$ somewhere and
you should never value your time at $0/hour.

P.S. This would be $10 please. Payable to my paypal.

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

Re: Disk reliability - and swap out`

In the Province of British Columbia, AC-side electrical equipment
is designed by registered Professional Engineers (PE) and worked
on by licensed electricians. At TRIUMF these people are better
than average.

Equipment we have built for SNOLAB and CERN was certified
by an outside licensed inspector and has the CSA and CE marks. Inspectors
were pretty strict and required a few changes in order to pass muster.

Equipment below 50V generally does not need to be inspected/certified,
but I, as an end-user, always ask "where is the fuse?" and "is this
a fuse of the right type?" (I know there are different types of fuses
but it is not my job to select the correct one).

We take electrical safety very seriously.

P.S. You cannot use a quarter to jumper blown fuses on current
generation electronics. You are lucky if you can even see
the fuse without a microscope. Replacing blown fuses is generally
done by electronics technicians and they will not honor the request
to "just jumper it!".

P.P.S. A physics lab is not Boeing with their "only flies down" airplanes
and "what time is now?" space ships.


K.O.


On Tue, Aug 10, 2021 at 04:10:26PM -0700, Yasha Karant wrote:
> A proper circuit breaker, hopefully with external or simple panel
> removal access (not remove from rack, open chassis, remove ... ),
> will work fine and typically is better than a fuse.  A "soldered in
> place" fusible link also will work, but is much more difficult to
> service and replace.  Anyone who puts a jumper over an overcurrent
> device (the "coin in the fuse box"), other than for diagnostic
> testing, needs to be both educated and reprimanded.  Note that if
> there is a power supply (typically from the mains), one needs a
> circuit breaker both for the power supply and for the items that the
> power supply is supplying. Clearly, the safety engineering unit is
> not verifying that any custom apparatus meets basic fail-safe
> practices -- I am not suggesting actual UL, etc., testing and
> certification for a specific experimental data or control device
> (although I do look for such certifications on the actual circuit
> breaker -- accidents are not nice).
> 
> On 8/10/21 4:00 PM, Konstantin Olchanski wrote:
> >On Tue, Aug 10, 2021 at 03:34:00PM -0700, Yasha Karant wrote:
> >>One SSD had an internal short and turned into a space heater,
> >>luckily there was no fire. End excerpt.
> >>
> >>Clearly, there is very poor safety engineering and/or quality
> >>control
> >
> >you will not be amused to learn how many electronics lack
> >proper fuses and protections against internal and external
> >shorts. even here, I have seen good people forget to put fuses
> >on newly built boards.
> >
> >>(as with certain Li batteries that did similar things in
> >>personal devices being operated by the user).
> >
> >that's different. SSD stores bits, Li battery stores Joules,
> >and "bits do not burn".
> >
> >>If that SSD had been inside a laptop (presumably, inside a rack mounted
> >>disk farm and there were fire extinguishers and possibly a machine room fire
> >>suppression system), things could have had a much worse outcome
> >>(most laptops have combustible materials).
> >
> >tangled server rooms, laptops, men, guns, horses all together.
> >
> >laptop battery probably will not have enough oomph for a good SSD fire,
> >cannot supply enough Amps, will shutdown before things get hot. ditto
> >for laptop power supply (60 W vs 600 W PC power supply).
> >
> >server chassis with rack mounted SSD in a server room has such good cooling
> >that the shorted SSD will only get slightly warm. also server power supply
> >will probably shutdown quickly because of undervoltage condition. so no fire.
> >
> >in this particular case, the computer was in an experimental area,
> >that has combustible materials, etc.
> >
> >>
> >>As for the small amount of storage, the commentator is at a
> >>reasonably well funded (through government sources and possible
> >>tax-deductible or glamour philanthropy) HEP facility.
> >>
> >
> >We also have a $$$ printing press in our basement (I have a key!) and
> >we can transmute lead into gold (only slightly radioactive).
> >
> >K.O.
> >
> >>
> >>Much of the world, including non-collaboration funded university research
> >>facilities have rather poor funding at most entities within the USA
> >>(not all faculty members can be at Harvard, Stanford, etc.) --
> >>administrative and some instructional facilities typically can get
> &g

Re: Disk reliability - and swap out`

On Tue, Aug 10, 2021 at 03:34:00PM -0700, Yasha Karant wrote:
> One SSD had an internal short and turned into a space heater,
> luckily there was no fire. End excerpt.
> 
> Clearly, there is very poor safety engineering and/or quality
> control

you will not be amused to learn how many electronics lack
proper fuses and protections against internal and external
shorts. even here, I have seen good people forget to put fuses
on newly built boards.

> (as with certain Li batteries that did similar things in
> personal devices being operated by the user).

that's different. SSD stores bits, Li battery stores Joules,
and "bits do not burn".

> If that SSD had been inside a laptop (presumably, inside a rack mounted
> disk farm and there were fire extinguishers and possibly a machine room fire
> suppression system), things could have had a much worse outcome
> (most laptops have combustible materials).

tangled server rooms, laptops, men, guns, horses all together.

laptop battery probably will not have enough oomph for a good SSD fire,
cannot supply enough Amps, will shutdown before things get hot. ditto
for laptop power supply (60 W vs 600 W PC power supply).

server chassis with rack mounted SSD in a server room has such good cooling
that the shorted SSD will only get slightly warm. also server power supply
will probably shutdown quickly because of undervoltage condition. so no fire.

in this particular case, the computer was in an experimental area,
that has combustible materials, etc.

> 
> As for the small amount of storage, the commentator is at a
> reasonably well funded (through government sources and possible
> tax-deductible or glamour philanthropy) HEP facility.
>

We also have a $$$ printing press in our basement (I have a key!) and
we can transmute lead into gold (only slightly radioactive).

K.O.

>
> Much of the world, including non-collaboration funded university research
> facilities have rather poor funding at most entities within the USA
> (not all faculty members can be at Harvard, Stanford, etc.) --
> administrative and some instructional facilities typically can get
> much more.  Many universities now outsource to paid "cloud" storage,
> with all of the issues that may entail.
> 
> On 8/10/21 3:08 PM, Konstantin Olchanski wrote:
> >Hi, Larry, thank you for this information, it is always good to see
> >how other people do things.
> >
> >I am surprised at how little storage you have, only a handful of TBs.
> >
> >Here, for each experiment data acquisition station, we now configure
> >2x1TB SSD for os, home dirs, apps, etc and 2x8-10-12TB HDD for recording
> >experiment data. We use "sort by price" NAS CMR HDDs (WD red, etc).
> >
> >All disks are doubled up as linux mdadm raid1 (mirror) or ZFS mirror. This is
> >to prevent any disruption of data taking from single-disk failure.
> >
> >(it is important to configure the boot loader on both SSDs to boot
> >even if the other SSD is dead).
> >
> >I am surprised you use 1TB HDDs. We switched to SSD up to 2TB size (WD blue 
> >SATA SSDs).
> >
> >Failure rates of HDDs, the only reliable data is from backblaze:
> >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.backblaze.com_b2_hard-2Ddrive-2Dtest-2Ddata.html&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=NXYkiOfF7bPKBqi2iMgqsqrtLHRVdP7lIO-L5J4AmqQ&s=DgUuM1BVcm4jUkUWsi_DNMAjvkuy1zl1oaDQzrC4YAk&e=
> >and
> >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.backblaze.com_blog_backblaze-2Ddrive-2Dstats-2Dfor-2Dq2-2D2021_&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=NXYkiOfF7bPKBqi2iMgqsqrtLHRVdP7lIO-L5J4AmqQ&s=lPk2j2mTwp6uDzrZYUsP2rIxyRiacBHZOU0o7R5mUqM&e=
> >
> >Failure rates of SSDs, seems to be very low, I only have 2-3 failed SSDs. 
> >One SSD had an
> >internal short and turned into a space heater, luckily there was no fire.
> >
> >For backups of os and home dirs we use amanda and rsync+zfs snapshots. 
> >Backups
> >of experiment data is not our responibility (many experiments use usb hdds).
> >
> >
> >K.O.
> >
> >
> >On Tue, Aug 10, 2021 at 10:55:35AM -0400, Larry Linder wrote:
> >>There are 25 systems in our shop, all linux based, a linux based server,
> >>and synology Disk Station running raid 1.   The Disk Station has 12 TB
> >>of space.  6 TB per for each raid level.
> >>
> >>We buy only one brand of disk with the black label.  They are typically
> >>1 TB.
> >>
> >>User boxes has a SSD drive for the OS and a 2 TB disk for th

Re: Back UP

On Mon, Aug 09, 2021 at 04:36:29PM -0400, Larry Linder wrote:
>
> Cron is now broken so you can't scehedule reliable backups.
> This got broken in SL 6.9 worked in SL 6.5.
> The reason is that it is looking for files from yum.  Whot does yum have
> to do with cron I heav yet to figure it out.
> 

Cannot confirm. cron works just fine here. by design, it can bog down
if some cron jobs never complete. this can happen to cron jobs
that run "yum update". is that what you see? easy to fix by removing
offending cron jobs.

> 
> My advise if you don't want to be forever the support team - buy a MAC.
> 

a "+1" on this one.

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

Re: Disk reliability - and swap out`

Hi, Larry, thank you for this information, it is always good to see
how other people do things.

I am surprised at how little storage you have, only a handful of TBs.

Here, for each experiment data acquisition station, we now configure
2x1TB SSD for os, home dirs, apps, etc and 2x8-10-12TB HDD for recording
experiment data. We use "sort by price" NAS CMR HDDs (WD red, etc).

All disks are doubled up as linux mdadm raid1 (mirror) or ZFS mirror. This is
to prevent any disruption of data taking from single-disk failure.

(it is important to configure the boot loader on both SSDs to boot
even if the other SSD is dead).

I am surprised you use 1TB HDDs. We switched to SSD up to 2TB size (WD blue 
SATA SSDs).

Failure rates of HDDs, the only reliable data is from backblaze:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.backblaze.com_b2_hard-2Ddrive-2Dtest-2Ddata.html&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=NXYkiOfF7bPKBqi2iMgqsqrtLHRVdP7lIO-L5J4AmqQ&s=DgUuM1BVcm4jUkUWsi_DNMAjvkuy1zl1oaDQzrC4YAk&e=
 
and
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.backblaze.com_blog_backblaze-2Ddrive-2Dstats-2Dfor-2Dq2-2D2021_&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=NXYkiOfF7bPKBqi2iMgqsqrtLHRVdP7lIO-L5J4AmqQ&s=lPk2j2mTwp6uDzrZYUsP2rIxyRiacBHZOU0o7R5mUqM&e=
 

Failure rates of SSDs, seems to be very low, I only have 2-3 failed SSDs. One 
SSD had an
internal short and turned into a space heater, luckily there was no fire.

For backups of os and home dirs we use amanda and rsync+zfs snapshots. Backups
of experiment data is not our responibility (many experiments use usb hdds).


K.O.


On Tue, Aug 10, 2021 at 10:55:35AM -0400, Larry Linder wrote:
> There are 25 systems in our shop, all linux based, a linux based server,
> and synology Disk Station running raid 1.   The Disk Station has 12 TB
> of space.  6 TB per for each raid level.
> 
> We buy only one brand of disk with the black label.  They are typically
> 1 TB.
> 
> User boxes has a SSD drive for the OS and a 2 TB disk for the users
> space and 32 G RAM. and a quad or six core AMD processor.  The graphics
> boxes get a Video card with lots of ram.  3 D rendering on a slow video
> care wast's a lot of users time.
> 
> The server has a SSD for the OS and 6 TB for user apps /
> library /usr/local and /opt.  It also has a mirror disk that keeps a
> copy of the server locally.
> 
> These systems are on 24 / 7 and accumulate a lot of hours.  No matter
> what the make mechanical disks have a life span.  For grins I used to do
> a post mortum on disk that failed.   There were to types of failures,
> the spring that returns the arm holding the heads cracks.  The second
> type of failure is the main bearings.  Newer disk seem to have less of a
> bearing failure rate.  
> To prevent operational problems we just swap out the disk on each box at
> about 5,000 to 7,000 hr.  The manufacturer says they are good for 10,000
> hr. See the fine print in the Waranty,  You have to remember this is a
> money making operation and down time is costly.
> 
> Backups run at 12:29 and 0:29 in the AM.  At the end of the morning back
> up a copy is sent to a remote site. 
> 
> For security we shut down the network at 6:20 PM, bring it up at 0:01 AM
> and shut it down after back up is complete.  We bring it back up at 6:45
> AM.  
> 10 yeas ago we had a fixed IP and the Chineese found it by just
> continually pounding on the door.  The return IP was 4 hops to a city
> north east of Shanghi.  They had installed a root kit on our server,
> disabled cron.  When you changed the passwd to the server a few
> millisecond later it was sent to china.  We got rid of the fixed IP and
> reloaded all the systems.  So when you shout down the network to your
> provider the next time your start it you get a different IP.
> 
> We don't give the disks away as they contain a lot of design data,
> SW,Cad programs, part programs for our mill etc.  We donate them to a
> charity that drills the disks and recycles the rest.
> 
> Larry Linder

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

Re: timeshift

2021-08-08 Thread Konstantin Olchanski

On Sun, Aug 08, 2021 at 04:09:04PM -0700, Yasha Karant wrote:
> 
> Assuming that she obtains a, say 1 Tbyte, external USB drive
> (powered from the USB port and either mechanical or SSD), she plans
> to do incremental backups to the backup drive.
> 
> ... what ... would anyone recommend?
> ... [need] tool [that] actually "works".
>

get a mac and use the built-in incremental backup tool called "time machine".

spend more $$$, save on time, headache medicines and torn hair repair (assuming 
you still had any).

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

Re: customize Xsetup_0 , file is not executed

2021-08-03 Thread Konstantin Olchanski

On Tue, Aug 03, 2021 at 09:37:53AM +0200, Ekkard Gerlach wrote:
> 
> /etc/X11/xdm/Xsetup_0 in  is NOT executed, what could be the reason?
>

you are not running xdm. you probably have gdm or lightdm or systemd-dm or 
whatever.

the xdm startup scripts are pretty well documented and pretty well understood,
but all this new stuff is an undocumented mess, different on every linux. IMO.

one solution could be to run vanilla xdm, then your Xsetup should work.

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

Re: Scientific Linux Advice

2021-06-29 Thread Konstantin Olchanski

On Tue, Jun 29, 2021 at 06:43:12AM +, Nick Matchett wrote:
> I hope that someone could help me identify an individual or business that 
> would be able to help me with the following problem.
> My business has some software that we acquired the responsibility to maintain 
> and support, and currently sits on Scientific Linux version 6.3.  
> Unfortunately, we are at a stage where our customers are asking to bring the 
> software onto a more current version of a Linux platform.
> We would like to migrate to Red Hat or CentOS version 7.9  (or perhaps 
> version 8)


Oh, boy! We are on the receiving end of such problem with Altera. Their latest 
fpga compiler
does not support cyclone-1 FPGA, the last version that does still by a miracle
runs on ubuntu and centos7, and of course Altera will never update it. As if 
nobody needs
to compile cyclone-1 fpga code.

If, like in this case, your application still does something useful and your 
customers still
want to run it, perhaps simplest is not to monkey around with it, just package 
it
as a VM container that runs on current-ish linuxes.

> I hope that someone could help me identify an individual or business

I wish you best luck with hiring the right staff, contractor or consultant to 
resolve your trouble.

K.O.


> 
> 
> 
> We have been working on a migration from Scientific Linux 6.3 to Redhat 7.9.
> 
> Unfortunately, we have limited Linux OS skills in our business, and we have 
> approached this with a fresh RH 7.9 install and then applying the RPM of our 
> software.  There is a big mismatch between Scientific Linux 6.3 to Redhat 7.9 
> in terms of libraries, file structure and type of libraries between the 
> software and we have not been able to reconcile those.
> 
> 
> 
> I would appreciate any suggestion or advice on the best upgrade path to 
> achieve this update  and would be happy to take recommendations on 
> individuals or companies who might be interested in a professional service 
> engagement to help solve the problem.
> 
> 
> 
> Thanks in advance

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

Re: any update on CERN Linux and CentOS-8 situation?

2021-05-06 Thread Konstantin Olchanski

On Thu, May 06, 2021 at 12:19:18PM +, James M. Pulver wrote:
>
> Believe me, I'd prefer to not deal with technical licenses and have a simple 
> site licence option for software. I have more than enough commercial software 
> on Windows that I have to support that add way too much time just for their 
> crappy licensing changes etc...
>


To amplify. "free" licenses are only free in the sense that cost of my labour 
is valued at $0/hour.

"A free license here, a free license there", can quickly add up to 1 FTE or 
more to handle them.


K.O.




> 
> --
> James Pulver
> CLASSE Computer Group
> Cornell University
> 
> 
> 
> 
> From: owner-scientific-linux-us...@listserv.fnal.gov 
>  on behalf of Mark Stodola 
> 
> Sent: Tuesday, May 4, 2021 4:42 PM
> To: owner-scientific-linux-us...@listserv.fnal.gov
> Cc: scientific-linux-users
> Subject: Re: any update on CERN Linux and CentOS-8 situation?
> 
> For our use, free is definitely a positive, but not a requirement.
> 
> We deploy our product's control systems and are really looking for the
> long term stability and security patches.  I wouldn't have a problem
> with purchasing licenses, as long as it didn't get in the way.  That
> meaning, not having to deal with serial numbers, subscriptions, and
> phoning home.  I want something I can buy, deploy, and forget about with
> regards to licensing.  This is a logistics issue.  I don't want to dump
> that responsibility on our customer long term and not all of our
> machines are remotely accessible to manage ongoing license maintenance.
> 
> This is likely in stark contrast to the HEP community, as I see that
> more of a site-wide deployment managed by a team dedicated to the job.
> 
> Best Regards,
> Mark
> 
> --
> Mr. Mark V. Stodola
> Control Systems Manager
> 
> National Electrostatics Corp.
> P.O. Box 620310
> Middleton, WI 53562-0310 USA
> Phone: (608) 831-7600
> Fax: (608) 831-9591
> 
> On 5/4/21 2:51 PM, James M. Pulver wrote:
> > Honestly, I've seen a lot of the FLOSS community prefer Rocky over Alma, 
> > and I think it's because Rocky is actually not backed by any company. 
> > However, we see how that went before, and I just think Rocky as described 
> > is ripe for CENTOS 2.0 to me. It's even run by one of the CENTOS founders, 
> > so -- maybe he's learned his lesson, but I don't see that as a positive for 
> > Rocky - it's neutral at best. I mean, CENTOS was bought by Red Hat and then 
> > "killed". Oracle? not even a blip. CloudLinux? Not a blip. Princeton, not a 
> > blip. I.e. all the rebuilds with a organization behind them that isn't 
> > dependent totally on community funding were basically unaffected here. The 
> > major distros that are going strong are company backed (Including SuSE, 
> > Ubuntu, RHEL, etc), except for Debian that seems to be the exception that 
> > proves the rule to me. And most of what Yasha et al seem to be looking for 
> > is a professional rebuild that is free - which might be a contradiction in 
> > terms, except for communities maintaining what they need for their use.
> >
> > This is why I (and I guess Yasha etc) are so disappointed that all the HEP 
> > labs can't get together to fund what? 5 FTE across all of them to re-create 
> > SL for the HEP community? Or some sort of Internet2 license that is 
> > affordable of RHEL (maybe that's the secret goal). Is that really a huge 
> > part of the CERN, Fermilab, etc all the labs budget? I imagine it's less 
> > than the commercial RHEL license costs. But we do have Alma (and others, 
> > including Oracle - wish I trusted them even a little) donating that rebuild 
> > to the world at large, so there's some people interested in putting 
> > donations out there.
> >
> > Anyway, digression aside, it's hard to do more than wait and see I guess - 
> > and much of that waiting is maybe for EL9 and to see if Rocky releases 
> > something that creates a better community than Alma has managed. Though I'm 
> > still betting on a company backed project getting going and keeping going 
> > much better in the short term anyway.
> > --
> > James Pulver
> > CLASSE Computer Group
> > Cornell University
> >
> >
> >
> > 
> > From: owner-scientific-linux-us...@listserv.fnal.gov 
> >  on behalf of Jack 
> > Aboutboul 
> > Sent: Tuesday, May 4, 2021 2:39 PM
> > To: Dave Dykstra
> > Cc: Bonnie King; Konstantin Olchanski; scientifi

Re: any update on CERN Linux and CentOS-8 situation?

2021-05-06 Thread Konstantin Olchanski

On Thu, May 06, 2021 at 01:22:06AM +0100, Mark Rousell wrote:
> On 05/05/2021 23:13, Konstantin Olchanski wrote:
> >
> > Things seem to be much quieter and event-less in the BSD and Debian (& co) 
> > camps.
> 
> I greatly fear that the BSDs are gradually losing the battle to keep up
> with Linux in terms of newer features and support for certain classes of
> hardware.
>

In a sense, that battle was lost years ago, when linux implemented
a better TCP/IP stack and when SGI extended Linux to work
well of 1000-CPU NUMA machines.

And yet, the BSDs are still here.

>
> It saddens me to note that both iXsystems (TrueNAS, previously
> FreeNAS) and Netgate (pfSense) are looking towards Linux, not BSD, for
> their next generation of larger-scaling, higher-throughput systems.
>

For these applications, most important is performance of ZFS+NFS/Samba+TCP/IP.

ZFS being an OS into itself, is reported to work well inside BSD kernels,
but is not as happy inside the linux kernel, the ZFS and Linux tend to fight
over data caching, i/o scheduling, etc

So whale fights elephant, better ZFS on BSD, better networking on Linux, and
who knows how it comes out.

>
> In the case of iXsystems, the new TrueNAS Scale is Linux based. And in the
> case of Netgate, their new TNSR product is based on Linux. Eventually it
> seems likely that both companies might well want to rationalise on one
> underlying OS.
> 

Those are also business decisions, not purely technical. I can see how they gain
by standardizing everything on Linux, especially when anything embedded,
anything SoC is "linux first". If they want to run the same code scaling
from "Raspberry PI NAS" to "big iron NAS", Linux would be the way to go.

>
> And FreeBSD itself has recently experienced the Netgate-related
> Wireguard incident.
> 

Nobody is safe from such things. Strength of a project is in how well they can 
survive/recover.

>
> As for Debian, they certainly had what one might call an 'event' with
> the decision to choose SystemD. ;-)
> 

At least in Debian it is all above board, with voting, public discussion, and 
all.

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

Re: c++17,17,20... - was Re: [SL-Users] Re: any update on CERN Linux and CentOS-8 situation?

2021-05-05 Thread Konstantin Olchanski

On Tue, May 04, 2021 at 11:00:00PM +0100, Andrew C Aitchison wrote:
> On Tue, 4 May 2021, Konstantin Olchanski wrote:
> 
> >- first slide of "distribution landscape" is nonsense,
> >with everybody stuck with el7 for another 3 years and
> >bye, bye, c++14, c++17, c++20.
> 
> Is Red Hat Developer Toolset 10
> https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2Dus_red-5Fhat-5Fdeveloper-5Ftoolset_10_html_10.0-5Frelease-5Fnotes_dts10.0-5Frelease-23Changes-5Fin-5FDTS&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=Chv7ZrLnQII3dvv1o48KTg7YAxT9SNUUCkOkflNOCd4&s=bZUlWtCI03IJ95QWY-_DTkmqMdwOzXq8PVBkiR1dZLM&e=
> not an option ?
> 
> (OK, C++20 support in g++ 10.2.1 is "experimental).
> 

And so what?

I can take SL-6 and graft modern versions of all important packages,
one does not even need the devtoolset, GCC is easy to build from sources.

But this is no longer "SL-6", it is "SL-6-KO1", at best.

Same thing, "CentOS-7 with devtoolset, php from webtatic, python from pip, 
kernel from ELREPO, etc" is not CentOS-7.

It is an irreproducible Franken-monster-bashed-together-locally thing.

Is this the new standard, the best way to go, "the new thing" for production 
environments?

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

Re: any update on CERN Linux and CentOS-8 situation?

2021-05-05 Thread Konstantin Olchanski

On Mon, May 03, 2021 at 05:54:35PM -0400, Jack Aboutboul wrote:
>
> I am a long time Fedora person and now the community manager of AlmaLinux.
>

Hi, Jack - good to hear from AlmaLinux. I wish you and your project best luck
and speedy progress.

I do not think of Alma Linux, Rocky Linux, etc as competitors ("who is 
better?"),
to me they are partners at a common goal, like the two guys on both sides
of a two-man wood saw.

My biggest worry is with Red Hat throwing more unexpected curved balls, as they 
have now
done 3 times (RH "E" Linux, "purchase" of CentOS, unexpected death of CentOS 
Linux).

Things seem to be much quieter and event-less in the BSD and Debian (& co) 
camps.

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

Re: [SCIENTIFIC-LINUX-USERS] [SL-Users] Re: any update on CERN Linux and CentOS-8 situation?

2021-05-05 Thread Konstantin Olchanski

On Tue, May 04, 2021 at 10:57:11AM +, Jose Marques wrote:
> 
> My view is that Stream is exactly what RHEL say it is, a development 
> distribution to which 3rd parties can contribute to RHEL development and from 
> which 3rd parties can base their own distributions. It's not for end users, 
> or small organisations that need timely security updates and other fixes and 
> can't produce same themselves.
> 

This is exactly what puzzles me. The food chain seems to be:

{GNOME,systemd,Poettering,etc} -> Fedora -> CentOS Stream -> RHEL

The purpose of RHEL seems to be clear: stuff that reaches RHEL has been 
hammered enough that it mostly works.

The purpose of Fedora is clear: this is the bleeding edge; whatever work, 
works; whatever is broken, we fix tomorrow, but no promises.

But what is CentOS Stream in the middle? How is it different from Fedora? Is it:

a) stuff that is not good enough yet for RHEL? (needs more hammering until it 
works). (but "not good enough for RHEL" probably means "not good enough for 
me"?).
b) just Fedora N-1?
c) "best of" selection of packages from Fedora N, N-1, N-2, etc?
d) all of the above plus secret/proprietary/NDA fixes for security and hardware 
bugs?

Perhaps the answer truely is as Red Hat have been saying all along - "this is 
our internal development process". But in this case,
how/why would anybody recommend "an internal development process" "thing" for 
any kind of production use?

Hmm... If quality is good enough, maybe it is ok. Let's see how quickly they 
fix security CVEs...

I pick 
https://urldefense.proofpoint.com/v2/url?u=https-3A__cve.mitre.org_cgi-2Dbin_cvename.cgi-3Fname-3DCVE-2D2021-2D20194&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=sQ-t16h7TvSNSg14oOkP3OA9VQIwY5urkmx0Y8St1Ag&s=_KIWEZZuAYWDdj8EKFq_cRWj8pd7FVIpDRkwEgf5FLo&e=
  at random, I follow the references through
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1912683&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=sQ-t16h7TvSNSg14oOkP3OA9VQIwY5urkmx0Y8St1Ag&s=Du4owy_SkXFPmqI1EwXiR4lZK-N8TXox9jLiT6UkCrw&e=

- Fedora: all versions affected, fix available
- RHEL: affected, see 
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_security_cve_cve-2D2021-2D20194&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=sQ-t16h7TvSNSg14oOkP3OA9VQIwY5urkmx0Y8St1Ag&s=x3x-RjLGL0IsdZPTdzZXPZVEv5Gp0qpciVucyHZqwsU&e=

- CentOS Stream: no info, google search for "CVE-2021-20194 centos" and "... 
centos stream" yields nothing. ("... ubuntu" yields the expected 
notvulnerable/fixreleased page)

Ok, maybe some obscure CVE was bad choice. How about the "sudo" CVE-2021-3156? 
I do not see any notice of resolution for centos stream. (I see notices for 
RHEL, Ubuntu, Fedora, etc. Of course CentOS "Linux" follows the RHEL CVEs).

Now I have to ask, does "CentOS Stream" even follow the CVE process? (notices 
of vulnerability, "fix available", etc). (CentOS "Linux" follows the RHEL CVE 
process, of course).

Not that I am dumping on CentOS Stream, I am just trying to understand how it 
works as a suggested replacement for CentOS Linux.

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

Re: [SL-Users] Re: any update on CERN Linux and CentOS-8 situation?

2021-05-04 Thread Konstantin Olchanski

On Mon, May 03, 2021 at 09:14:11PM +, Dave Dykstra wrote:
> Here's a presentation at HEPiX'21 from CERN that's publicly available:
> https://indico.cern.ch/event/995485/contributions/4256466/

Thank you for the link, I was not aware of this presentation.

For further reading, it contains a link to the March meeting of the linux
future committee: https://indico.cern.ch/event/1019875/

All materials are publically available, the zoom chat transcript requires
a CERN login (which I have), I am reading through the stuff now.

First impressions from the HEPIX presentation:

- there is no explanation how CentOS Stream is a technically acceptable
replacement
for CentOS Linux. There is many questions here, none answered.

- there is no suggestion of reviving the CERN+FermiLab collaboration
(named SL or otherwise). This is surprising, if Princeton can roll out
a "new centos", CERN+Fermilab have even more resources to do same.

- there is no suggestion of CERN providing extended support for CentOS-8. To
me, this would be the obvious path forward.

- first slide of "distribution landscape" is nonsense, with everybody stuck
with el7 for another 3 years and bye, bye, c++14, c++17, c++20.

- second slide of "distribution landscape" has LHC experiments changing horses
in the middle of Run 3. Good luck with that.

- no discussion of "red hat takedown/takeover of centos, 2.0" scenario for
Rocky Linux & co.

First impressions from the "linux future" meeting in March:

- 30 minutes of our Troy Dawson leading Red Hat's video presentation:
https://videos.cern.ch/record/2756480 (where they say "rail", they mean RHEL,
took me a while to catch this)

- "CC7 is not an option to use for RUN3 at CMS", page 4,
https://indico.cern.ch/event/1019875/attachments/2214410/3751654/lfc002.pdf

- support for 64-bit ARM is a requirement (good, but what about existing 32-bit
ARM and 32-bit x86 machines?)

- page 5, key take away, "Most likely moving to CS8 is your best option, as
this allows for a trivial upgrade path to EL8 at a later date".

(Is this true? Can somebody point me to the instructions for upgrading Centos
Stream 8 to RHEL 8? A quick google search finds nothing)

- Linux BOF slides
https://indico.cern.ch/event/995485/sessions/386343/attachments/2209929/3739897/hepixLinuxBoFMarch16th2021.pdf
- Linux BOF 82 min video https://videos.cern.ch/record/2756412

- Ben Maurice slides https://codimd.web.cern.ch/p/Zcc5CqncC#/1

- zoom chat (requires cern login) - all questions raised are reflected in Ben
Maurice slides.

Bottom line.

All arrows point at CentOS Stream, but there is no review/evaluation of it's
technical suitability
for HEP specific needs. Good/bad/etc compared to el7 and compared to non-RPM
alternatives (ubuntu,
etc). And there is many questions, none answered.

It looks like everybody will have to do their own evaluation and decide for
themselves.

P.S.

Do watch Troy's video!

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

Re: any update on CERN Linux and CentOS-8 situation?

2021-05-03 Thread Konstantin Olchanski

On Mon, May 03, 2021 at 11:25:22AM +, Bonnie King wrote:
>
> There hasn't been any official statement. On the Fermilab side we are holding 
> discussions and gathering feedback from experiments and other collaborators.
> We are working on it and will make an announcement soon.
> 

Ok, thanks. I hope you find the discussions on this mailing list as useful 
input into your deliberations.

I wish it did not take 6 months to sort it out, but I guess (a) with covid, 
everything takes longer (true for me),
and (b) it reflects the size of the doo-doo red hat have stepped on (instead of 
walking around it).

At TRIUMF, my feeling is that there will be further splintering of Linux user 
base, the central
computing group is likely staying with red hat, for the experiments, we replace 
SL6 with Ubuntu,
one big experiment group just upgraded SL6 to CentOS-7 and is likely to stay 
there, for new installs
we offer a choice of Ubuntu or CentOS-8 (with the caveat of no support after 
December). RaspberryPi,
nano-pi, etc is all Raspbian (debian).

Looks like a repeat of the UNIX fragmentation of the 1990-ies, where 
everybody's computer is just slightly
different to cause trouble.

The main driver of linux choice is "latest c++" (c++17, c++20) and "latest 
python".

K.O.



> Bonnie King
> 
> 
> From: owner-scientific-linux-us...@listserv.fnal.gov 
>  on behalf of Konstantin 
> Olchanski 
> Sent: Saturday, May 1, 2021 9:27 AM
> To: Dave Dykstra
> Cc: scientific-linux-users
> Subject: Re: any update on CERN Linux and CentOS-8 situation?
> 
> On Fri, Apr 30, 2021 at 09:35:02PM +, Dave Dykstra wrote:
> > Both Fermilab and CERN have stated that they plan to use CentOS 8 stream
> > for now (or Scientific Linux 7 or CentOS 7) and will evaluate later
> > whether or not to switch to one of the clones.
> 
> Interesting. I do not see any information about this and I believe
> I receive both internal and external official communications from CERN.
> 
> Do you know who and when made this "centos stream" statement?
> 
> K.O.
> 
> 
> >
> > Dave
> >
> > On Fri, Apr 30, 2021 at 10:35:18AM -0700, Konstantin Olchanski wrote:
> > > Any news or updates on the status of CERN Linux?
> > >
> > > Per https://linux.web.cern.ch/centos8/ CERN users are strongly encouraged
> > > to use CentOS-8 while the same page states that support for CentOS-8 will
> > > end at the end of this year. Update is promised "during Q1 2021", today
> > > we are 1/3 into Q2 2021, and there is no new information.
> > >
> > > The CentOS forums are graveyard quiet. (censored?)
> > >
> > > Any information from the FermiLab side of things? Any information from 
> > > the SL side
> > > of things? Any rumours?
> > >
> > > I opened a support ticket with CERN about this, let's see what they say.
> > >
> > >
> > > --
> > > 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
> 
> --
> 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

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

Re: any update on CERN Linux and CentOS-8 situation?

2021-05-01 Thread Konstantin Olchanski

On Fri, Apr 30, 2021 at 09:35:02PM +, Dave Dykstra wrote:
> Both Fermilab and CERN have stated that they plan to use CentOS 8 stream
> for now (or Scientific Linux 7 or CentOS 7) and will evaluate later
> whether or not to switch to one of the clones.

Interesting. I do not see any information about this and I believe
I receive both internal and external official communications from CERN.

Do you know who and when made this "centos stream" statement?

K.O.


> 
> Dave
> 
> On Fri, Apr 30, 2021 at 10:35:18AM -0700, Konstantin Olchanski wrote:
> > Any news or updates on the status of CERN Linux?
> > 
> > Per https://linux.web.cern.ch/centos8/ CERN users are strongly encouraged
> > to use CentOS-8 while the same page states that support for CentOS-8 will
> > end at the end of this year. Update is promised "during Q1 2021", today
> > we are 1/3 into Q2 2021, and there is no new information.
> > 
> > The CentOS forums are graveyard quiet. (censored?)
> > 
> > Any information from the FermiLab side of things? Any information from the 
> > SL side
> > of things? Any rumours?
> > 
> > I opened a support ticket with CERN about this, let's see what they say.
> > 
> > 
> > -- 
> > 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

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

any update on CERN Linux and CentOS-8 situation?

2021-04-30 Thread Konstantin Olchanski

Any news or updates on the status of CERN Linux?

Per https://linux.web.cern.ch/centos8/ CERN users are strongly encouraged
to use CentOS-8 while the same page states that support for CentOS-8 will
end at the end of this year. Update is promised "during Q1 2021", today
we are 1/3 into Q2 2021, and there is no new information.

The CentOS forums are graveyard quiet. (censored?)

Any information from the FermiLab side of things? Any information from the SL 
side
of things? Any rumours?

I opened a support ticket with CERN about this, let's see what they say.


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

Re: [EXTERNAL] Re: Code bias video, watch it ASAP

2021-04-27 Thread Konstantin Olchanski

On Tue, Apr 27, 2021 at 04:49:00PM +, Queen, Steven Z. (GSFC-5910) wrote:
>
> I don't think this list is an appropriate place for political discussions.
>

I agree, I think the OP should not have brought this subject on this list.

>
> Hopefully an administrator will intervene.
> If this continues, I will unsubscribe.
> 

Unfortunately, technical, policy and political issues mix together and
there is no avoiding that. Ignoring them is dangerous, they have a way
of catching up to you in whatever cave or monastery or retreat you choose
to hide in.

K.O.


> 
> From: owner-scientific-linux-us...@listserv.fnal.gov 
>  on behalf of Nico 
> Kadel-Garcia 
> Sent: Tuesday, April 27, 2021 9:04 AM
> To: LaToya Anderson 
> Cc: Andrew C Aitchison ; Keith Lofstrom 
> ; Mailing list for Scientific Linux users worldwide 
> 
> Subject: [EXTERNAL] Re: Code bias video, watch it ASAP
> 
> On Sun, Apr 18, 2021 at 7:24 AM LaToya Anderson
>  wrote:
> >
> > Data does not remove bias. And one can and should both read the article and 
> > watch the movie.
> >
> > STEM Academy Instructor
> 
> Data rather than mere exposition helps prevent bias. How do you refute
> or counter unfair bias except with data?
> 
> The movie is, itself, profoundly biased. It didn't explore at all why
> a public housing project might benefit from cameras on the door of a
> densely populated building with numerous poor, old, or unhealthy
> tenants. The movie was an icon of "Critical Theory", portraying the
> attempt to use science and engineering for social problems as a plot
> against the oppressed.
> 
> I've lived in scary neighborhoods of London. London accepts and
> expects a degree of CCTV monitoring that is outrageous to Americans.
> Sadly, citizens can't *get* the videos when a crime occurs, and
> photographic evidence can be misused against the innocent. Been there,
> done that, watched a London parking cop frame the photos they took to
> document a parking ticket, really ticked him off when I very obviously
> took photos at angles that showed the car was, in fact parked near a
> sign that gave permission and curb markings that matched.

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

Re: Code bias video, watch it ASAP

2021-04-26 Thread Konstantin Olchanski

Thank you for highlighting this important issue. With recentish New York Times
reports on image recognition software labeling US congressmen as monkeys and
criminal courts using "algorythms" for bail and sentencing decisions, I think
there is cause for severe concern.

All involved with software and computer systems should be aware of such things.

Given the general level of incompetence (see the Boeing 737-MAX airplane 
programmed
to fly into the ground if one external sensor is hit by bird) and the incoming 
era
of robocops firing "only non-lethal" weapons on targets identified "by 
algorithm",
I think there is reason to worry.

K.O.

On Sun, Apr 18, 2021 at 07:24:39AM -0400, LaToya Anderson wrote:
> Data does not remove bias. And one can and should both read the article and
> watch the movie.
> 
> STEM Academy Instructor
> 
> On Sun, Apr 18, 2021, 6:59 AM Nico Kadel-Garcia  wrote:
> 
> > On Sun, Apr 18, 2021 at 6:22 AM Andrew C Aitchison
> >  wrote:
> > >
> > > On Sun, 18 Apr 2021, Nico Kadel-Garcia wrote:
> > >
> > > > The movie is very strong on "feels", very poor indeed on data.
> > > >
> > > > A much better article, with far less "feels"
> > >   ^^
> > > Is that a deliberate example of the bias in the video ?
> >
> > No, it's an evaluation of the video and a pointer to a much more
> > succinct, more specific article.
> >

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

Re: FWIW: AlmaLinux now available.

2021-04-03 Thread Konstantin Olchanski

On Sat, Apr 03, 2021 at 11:39:17AM -0400, Lamar Owen wrote:
>
> AlmaLinux stable release is now available.
>

Question is: but for how long? until red hat pulls a centos on them?

P.S.

My message is "FU!D". Fear, check! Uncertainty, check! Deception? Nope, happened
before, will happen again. cease&desist letters, AT&T/BSDI and SCO/IBM-style
law suits, offers-you-cannot-refuse to principal developers, etc.

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

Re: In search for SL 6.5 replacement - mint evaluation

2021-03-17 Thread Konstantin Olchanski

 even the ones that are set to mode 000.
> These are Complete with account name and userID. !
> 
> 5.  Last but not least:
> I wanted to install KiCad using the SW manager.  It worked, crated the
> icon and put the files in /usr/bin/1001/bla/bla/bla.  So I can install a
> program.  A typical system in our shop may have 12 logins from engineer,
> software engineer, manufacturing, purchasing etc and the list goes on.
> So each has to load a copy of the program.  Remember owner, groups,
> userID doesn't work properly.  you can inspect the passwd and group, and
> they look good.  Run pwconv and grpconv to update shadows, run the check
> programs it looks good, it still doesn't work.  I have not stumbled on a
> way to set it up so it works. 
> 
> 6. We downloade VMware 16, it install and worked.  Thank You VMware.  We
> are going to buy it.
> 
> 7. Now the real insidous part:  I used the sw manager to remove the
> KiCad and it worked.  Ten minutes later I became root and tried to
> install it again.  It worked but the install was the same place as
> before.  I then removed it and went for another cafeene fix.  It was
> still removing files.  What it was doing was doing was running rm -rf *
> from /  as root.  All there disks about 1.5 T of file were gone.   Nice
> programming botch. 
> It tells you a lot lot about the lack of testing that has gone into
> these systems. 
> Just think if you did this on cloud setup result, a clear blue sky.
> 
> Fortunately we have several back ups.
> 
>   score: $4000 / 2 programs  - 0 working system  Not a costly as Cent8
> and non available RH.
>   Trashed DVD and removed.
> 
> Conclusion:  Systems using systemd are not able to be set up to do what
> we need done. You basically have swaped "Bill" computer for "IBM's"
> computer.  You can't set /opt and /usr/local/bin to other disks. We
> don't use LVM.  I can only imagine the cost of running our 50 systems.
> 
> We chucked Cent8, and Mint 20.1 DVD's, and reformated Flash drives.
> 
> Next:  Devian - a fork in Debian with out systemd is next. Std UNIX
> flavor and then we will try BSD.
> 
> If you look at Linux over the last 20 years it has gone no place. things
> are still broken.  Contributors have spent time working on eye candy,
> hiding functionality and trying to make it like Windows 10 - another
> convoluted disaster. It is "moron aware" sw.
> 
> If Linux had any leadership group or company it could have been by now a
> world class OS. the 20 years have been wasted, Windows 10 would never
> have happened, you wouldn't have a zillion distrobutions that have the
> same flaws.
> 
> SystemD is a pleague that will kill linux.  IBM will abandon the users
> just as it did with the development of OS/2 and what MS did with windows
> 3.0.  Don't trust them.
> 
> My Boss's words.  Each keystroke or mouse click costs $,  If you measure
> the time it takes to find and run a task the new scheme is many times
> more expensive than running an app with a 4 char. name. 
> 
> Sill in search of 6.5 replacement
> 
> Larry Linder

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

Re: scientific.org

2021-03-05 Thread Konstantin Olchanski

To add. all official published results must be done using "official analysis",
and for the purposes of this discussion, said "official analysis"
often runs exclusively on RedHat-flavour linuxes.

> 
> Most HEP (and sometimes other) "academic" collaborations have
> collaboration agreements for all member institutions (or groups or ...
>
> That was my meaning of NDA.
> 

That has nothing to do with Linux and Red Hat. I do not know
why you bring it up. And you did not get it completely
right, either. In Physics, we do not have to sign legal NDAs
to participate in experiments and projects. It is basically
an honor system, and everybody plays by the rules
and/or breaks the rules per basic human nature. Books have
been written about this stuff.

K.O.

On Fri, Mar 05, 2021 at 04:30:13PM -0800, Yasha Karant wrote:
> Most HEP (and sometimes other) "academic" collaborations have
> collaboration agreements for all member institutions (or groups or
> individuals) that no work done by the collaboration may be published
> or discussed without permission from the collaboration, typically a
> set of PIs (often not a democratic vote -- one person whose name may
> appear on the published papers or public presentations, one vote --
> but rather some of the "group leaders" or the like).  These
> limitations not only apply to announcement of research results, but
> (often) deep details of the apparatus, that these days, can include
> software, applications, and perhaps computer environments (e.g.,
> modifications to an OS, special OS drivers for specific hardware,
> etc.).  Once it has been decided that something can be released,
> then it is -- equivalent to a NDA.  Typically again under this sort
> of NDA, all of these details may be revealed to the funding
> agency/ies (those who "pay the bills") but the agency has agreed not
> to release this in public.  In the USA, save for classified
> (weapons, clandestine services, etc.) material, those things
> developed by Federal Government agencies are "public".
> 
> That was my meaning of NDA.
> 
> On 3/5/21 4:02 PM, Konstantin Olchanski wrote:
> >>At some point ...
> >
> >Yasha you are writing some very strange stuff.
> >
> >>NDA collaboration contracts that exist for the various
> >>CERN/Fermilab experiments ...
> >
> >if your NDA stands for "non-disclosure ...", then I must say that
> >I do not believe there are any secret agreements between experiments
> >and linux vendors. We do have NDAs with hardware vendors for
> >access to secret documentation and secret firmware source code,
> >but I never heard of any special agreements with any Linux vendors.
> >
> >if you know something we do not know, please tell us more.
> >
> >>... Your observations on RHEL indicate that except for those
> >>who license RHEL for fee with an IBM RH support contract, RHEL is
> >>not an viable stable long-term (nor immediate) alternative.
> >
> >I must put it on record that I did not say any such thing.
> >
> >I say:
> >
> >a) RHEL8 is here and you can use it free of charge (16 free subscriptions)
> >b) you can upgrade your CentOS-8 machine to RHEL8 with minimum trouble (I 
> >posted instructions on this list here)
> >c) Red Hat made a serious mistake back in December by announcing "the end of 
> >CentOS as we know it" without providing (a) and (b) ahead of time
> >d) by not providing 32-bit x86 and 32-bit ARM versions of RHEL they are at a 
> >severe disadvantage in places like a typical Physics lab (CentOS used to 
> >provide both, but they killed it).
> >
> >So there. There is nothing wrong with RHEL8. If it works for you, use it!
> >

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

Re: scientific.org

2021-03-05 Thread Konstantin Olchanski

> At some point ...

Yasha you are writing some very strange stuff.

> NDA collaboration contracts that exist for the various
> CERN/Fermilab experiments ...

if your NDA stands for "non-disclosure ...", then I must say that
I do not believe there are any secret agreements between experiments
and linux vendors. We do have NDAs with hardware vendors for
access to secret documentation and secret firmware source code,
but I never heard of any special agreements with any Linux vendors.

if you know something we do not know, please tell us more.

> ... Your observations on RHEL indicate that except for those
> who license RHEL for fee with an IBM RH support contract, RHEL is
> not an viable stable long-term (nor immediate) alternative.

I must put it on record that I did not say any such thing.

I say:

a) RHEL8 is here and you can use it free of charge (16 free subscriptions)
b) you can upgrade your CentOS-8 machine to RHEL8 with minimum trouble (I 
posted instructions on this list here)
c) Red Hat made a serious mistake back in December by announcing "the end of 
CentOS as we know it" without providing (a) and (b) ahead of time
d) by not providing 32-bit x86 and 32-bit ARM versions of RHEL they are at a 
severe disadvantage in places like a typical Physics lab (CentOS used to 
provide both, but they killed it).

So there. There is nothing wrong with RHEL8. If it works for you, use it!

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

Re: scientific.org

2021-03-05 Thread Konstantin Olchanski

On Thu, Mar 04, 2021 at 06:27:07PM -0800, Yasha Karant wrote:
>
> Has anyone tried the Institute for Advanced Study Springdale (IAS)
> EL 8 distro?
>

What for? I have my "16 free RHEL subscriptions" to run my 1 el8 machine
for developing and supporting the MIDAS data acquisition package.

As for everything else, at this very moment, I am:

a) converting all our RaspberyPi and FPGA SoC machines (about 10 of them) from 
CentOS-7.3 to Raspbian (ARM Debian)
b) converting our VME processors to Ubuntu and 32-bit Debian (and updating the 
VME kernel drivers to linux-5.8)
c) telling everybody to install Ubuntu or wait for CERN ("We will keep you 
informed about
any developments in this area during Q1 2021." with Q1 ending in 25 days or so).

If RHEL8 (or clone) for 32-bit ARM and 32-bit x86 did exist... but... I think...

The ship has sailed.

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

Re: not all ports detected on 7-port Sabrent usb hub

2021-02-12 Thread Konstantin Olchanski

>
> As for “$1 devices”, my Sabrent hub cost $36.99 before tax.  I am curious
> where one goes for a “real” hub (at least 7 ports) — although somehow I
> have a hunch that there are many different definitions of “real” out
> there.
>

I tend to go by manufacturer respectability rather than price. For network 
gear, joints like Juniper
would be 1st tier, joints like ASUS and Linksys are maybe 2nd tier, stuff sold 
in London Drugs
with "made in USA" label covering a "made in China" label convering a "make in 
Taiwan" label is 3rd tier.
Have not looked at USB stuff recently, but same idea.

>
> # dmesg output #
> [27424.944664] usb 5-1.3: new high-speed USB device number 24 using xhci_hcd
> [27425.035451] usb 5-1.3: New USB device found, idVendor=0bda, 
> idProduct=5411, bcdDevice= 1.36
> [27425.035465] usb 5-1.3: Product: 4-Port USB 2.0 Hub
> [27425.037951] hub 5-1.3:1.0: USB hub found
> [27425.039281] hub 5-1.3:1.0: 4 ports detected
> [27425.315678] usb 5-1.3.4: new high-speed USB device number 25 using xhci_hcd
> [27425.416560] usb 5-1.3.4: New USB device found, idVendor=0bda, 
> idProduct=5411, bcdDevice= 1.36
> [27425.416574] usb 5-1.3.4: Product: 4-Port USB 2.0 Hub
> [27425.418566] hub 5-1.3.4:1.0: USB hub found
> [27425.419901] hub 5-1.3.4:1.0: 4 ports detected

Looks like your device is 2 cascaded 4 port USB hubs. Only USB2 hub is 
detected, so possibilities:

- the USB3 hub component is not supported
- you are connected to a USB2 port in your computer
- you have a USB2 cable between computer and hub

USB idVendor 0BDA, idProduct 5411 is a Realtek RTS-5411 chip:
https://urldefense.proofpoint.com/v2/url?u=https-3A__devicehunt.com_view_type_usb_vendor_0BDA_device_5411&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=9RT_QbE5MKyrbOu3FBU8XX_WGxM-cswGe02M-VBN0eo&s=O_-gbOH5EjVMaUHBPS8IdRgk608wYOy7h-cUTpCKxQ8&e=
 

Data sheet:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datasheetspdf.com_pdf-2Dfile_1146777_Realtek_RTS5411_1&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=9RT_QbE5MKyrbOu3FBU8XX_WGxM-cswGe02M-VBN0eo&s=CBzYq4qVgEBTf5XOp2JAE2qcQOBDeH3AWDoaBJ3Y7sc&e=
 

Per data sheet, is a 4 port USB2/USB3 hub (so 2x 4-port hubs detected by linux 
is correct).

The best I can tell, linux drives it with the generic USB hub driver.

So:

a) all 7 ports should work (in USB2 mode, so plug a mouse or a keyboard to 
check)
b) no idea why the USB3 component is not detected. most likely you are plugged 
into a USB2 port (or a USB3 port disabled in the BIOS, or blownup, etc)

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

Re: not all ports detected on 7-port Sabrent usb hub

2021-02-12 Thread Konstantin Olchanski

On Thu, Feb 11, 2021 at 04:17:46PM -0500, Stephen L. Talbott wrote:
> 
> Is there an reason why a rather vanilla SL-7.9 system might report “4
> ports detected” on a new, Sabrent 7-port, powered USB 3.0 hub (HB-BUP7)?
>

Some of these usb switches have interesting internal structure (separate usb2
and usb3 hubs, two 4-port hubs cascaded from each other, etc) and the linux
usb hub driver may be confused and fail to enable all the ports.

You can see the bus structure that linux can see in the output
of "lsusb" and in /sys/bus/usb/devices/. There may be some error
messages in "dmesg" ("cannot enable port", etc).

And possibility of defective device cannot be ruled out,
these $1 products do not go through any QA.

Also if you have reports of device "HB-BUP7" working for somebody,
it means nothing. Makers of $1 USB devices are notorious
for shipping completeley different devices (different chips,
different linux drivers) under the same part number. Bait-and-switch
in action.

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

Re: numfmt issue on SL 7.9; possible bug?

2021-02-10 Thread Konstantin Olchanski

here goes, all on physical machines.

sl6, macos: no numfmt, sorry

ubuntu lts 20.04, centos-7, rhel-8 (ahem!):

$ echo 0 | numfmt
0

perhaps your 80387 chip is faulty. (happened to us once
on an R3000/R3010 SGI workstation)

K.O.



On Wed, Feb 10, 2021 at 06:17:26PM -0600, ~Stack~ wrote:
> Greetings,
> 
> Curious if anyone else can replicate this. I initially saw this in a
> certain upstream vendor 7.9, but I'm having issues replicating it
> and it's only in a certain environment (virtual and I've done
> strange and awful things to that as I've been trying to understand
> an unrelated project). However, I was trying to figure out if it was
> other places as well. Sure enough, I can replicate it on every
> single one of my SL 7.9 instances that I've tested.
> 
> The short, numfmt should not return 'nan' when passed a zero.
> 
> $ echo 0 | numfmt
> nan
> $ rpm -q coreutils
> coreutils-8.22-24.el7_9.2.x86_64
> 
> If I try on any other distro (Ubuntu/Debian/CentOS 8), it returns 0
> as it should.
> 
> $ echo 0 | numfmt
> 0
> $ rpm -q coreutils
> coreutils-8.30-8.el8.x86_64
> 
> I may not be able to replicate it as reliably as I would prefer on
> upstream vendor, but every single SL 7.9 system I've tried has had
> coreutils-8.22-24.el7_9.2.x86_64 and incorrectly returns 'nan'.
> 
> I'm hoping the devs can confirm and/or offer suggestions.
> 
> Thanks!
> ~Stack~

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

Re: converting to RHEL8...

2021-02-07 Thread Konstantin Olchanski

On Thu, Feb 04, 2021 at 10:07:43AM -0800, Konstantin Olchanski wrote:
> > Here we go. Conversion from CentOS-8 to RHEL-8 in 5 easy steps.
> > 
> > Instructions for converting CentOS to RHEL are posted here:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_articles_2360841&d=DwIDAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=IBWdeVmMPbkgwCr8Ir6R307eFH3-2aZ9vYnQ7mEhhHM&s=Hhj0voUDSXlQKw63jIuVJYcerY5Bmru62tOJwbHKuMk&e=
> >  
> > convert2rhel-0.15-1.el8.noarch.rpm from github is not signed
> > To be continued...

Updated version of convert2rhel is out. RPM still not signed.

[root@daqlabpc ~]# rpm -vh --upgrade convert2rhel-0.16-1.el8.noarch.rpm 
...
[root@daqlabpc ~]# convert2rhel 
...
WARNING - By continuing you accept this EULA.
Continue with the system conversion? [y/n]: y
...
Running the 'rpm -Va' command which can take several minutes. 
... ... ... (no kidding. but it is a slow computer)
[02/07/2021 10:01:17] TASK - [Convert: List third-party packages] 
***
WARNING - Only packages signed by CentOS Linux are to be reinstalled. Red Hat 
support won't be provided for the following third party packages:
certbot-1.11.0-1.el8.noarch  Fedora Project@epel
ganglia-3.7.2-33.el8.x86_64  Fedora Project@epel
zfs-release-1-8.1.noarch N/A   
@@commandline
...
Continue with the system conversion? [y/n]: y
...
WARNING - The following packages will be removed...
Package
Vendor/Packager  Repository
---
---  --
centos-logos-80.5-2.el8.x86_64 CentOS 
Buildsys  @AppStream
centos-logos-httpd-80.5-2.el8.noarch   CentOS 
Buildsys  @AppStream
rhn-client-tools-2.8.16-13.module_el8.1.0+211+ad6c0bc7.x86_64  CentOS 
Buildsys  @AppStream
python3-rhn-client-tools-2.8.16-13.module_el8.1.0+211+ad6c0bc7.x86_64  CentOS 
Buildsys  @AppStream
python3-rhnlib-2.8.6-8.module_el8.1.0+211+ad6c0bc7.noarch  CentOS 
Buildsys  @AppStream
...
Continue with the system conversion? [y/n]: y
...
[02/07/2021 10:04:34] TASK - [Convert: Subscription Manager - Download 
packages] 
Successfully downloaded the subscription-manager package.
Successfully downloaded the subscription-manager-rhsm-certificates package.
Successfully downloaded the python3-subscription-manager-rhsm package.
Successfully downloaded the dnf-plugin-subscription-manager package.
Successfully downloaded the python3-syspurpose package.
...
[02/07/2021 10:04:49] TASK - [Convert: Subscription Manager - Replace] 
**
Removing non-RHEL subscription-manager packages.
Upon continuing, we will uninstall the following subscription-manager pkgs:

Package  Vendor/Packager  
Repository
---  ---  
--
dnf-plugin-subscription-manager-1.27.16-1.el8.x86_64 CentOS Buildsys  
@BaseOS
python3-subscription-manager-rhsm-1.27.16-1.el8.x86_64   CentOS Buildsys  
@BaseOS
subscription-manager-1.27.16-1.el8.x86_64CentOS Buildsys  
@BaseOS
subscription-manager-rhsm-certificates-1.27.16-1.el8.x86_64  CentOS Buildsys  
@BaseOS
Continue with the system conversion? [y/n]: y
...
[02/07/2021 10:05:50] TASK - [Convert: Install RHEL certificates for RHSM] 
**
Installing RHEL certificate to the system.

[02/07/2021 10:05:50] TASK - [Convert: Subscription Manager - Subscribe system] 
*
Building subscription-manager command ... 
... activation key not found, username and password required
...
Username: hah...@hahaha.example.com (email address as usename will not work!)
...
Password: letmein
...
Registering system by running subscription-manager command ... 
Registering to: subscription.rhsm.redhat.com:443/subscription
HTTP error (401 - Unauthorized): Invalid username or password. To create a 
login, please visit 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_wapps_ugc_register.html&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=rPpmkxaspgfc9oWErBJ6ENXC7F1bGr0WF49JwjMUCNg&s=CT3gIQCVO3HZE3pYHadDsBlSsh0IytjibeQ9PyxBbjY&e=
 
...
Username: enter user name from "you are logged in as", no the email address
...
Password: letmein
...
Registering system by running subscription-manager command ... 
Registering to: subscription.rhsm.redhat.com:443/subscription
The system has been registered with ID: ...
The registered system name is: daqlabpc.triumf.ca
...
Manua

Re: converting to RHEL8...

On Thu, Feb 04, 2021 at 01:59:08PM -0800, Yasha Karant wrote:
> 
> Thus, it appears only an install from the web is available, not the
> ability to create local images (e.g., on bootable optical media or
> bootable USB flash drive).  For reasons of both throughput
> limitations as well as network interruptions, I prefer to do a
> "fresh" install from local media.  Is there a mechanism short of
> duplicating an entire distro web site of producing such an image for
> Springdale 8 EL?
> 

Off-topic here. Please take it to the Springdale support forum.

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

Re: converting to RHEL8...

These instructions are insecure, set you up for a supply-chain attack:

a) RPMs are loaded over plain "http" (no "https")
b) RPM signature is not checked

A more secure sequence would:

- wget 
https://urldefense.proofpoint.com/v2/url?u=https-3A__somewhere_rpm-2Dsignature-2Dkey&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=Bwvu8ORtdwu_qqgSySYBdSQ5VFU2sSZyj1XlHQ96Gz4&s=OuX1i3RoFfYAZJrzTBCVE8ywgKYMw1puabTsB1I4ljM&e=
 
- independantly verify this signature
- rpm import it
- rpm check signature before installing (or use yum, confirm package signature 
is enabled)


K.O.


On Thu, Feb 04, 2021 at 03:42:31PM -0600, Ching Him Leung wrote:
> I have not tried RHEL yet, but I have some success converting from CentOS 8 
> to Springdale 8 on a VM. Here are some instruction I found on rocky linux 
> forum
> 
> dnf update -y
> rpm -e --nodeps centos-backgrounds centos-indexhtml centos-gpg-keys 
> centos-linux-release centos-linux-repos centos-logos
> rpm -ivh \
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__springdale.princeton.edu_data_springdale_8_x86-5F64_os_BaseOS_Packages_springdale-2Dappstream-2D8-2D0.sdl8.2.noarch.rpm&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=Bwvu8ORtdwu_qqgSySYBdSQ5VFU2sSZyj1XlHQ96Gz4&s=3awxciVrCSZEziaUehriWnMttfwlCRKuMKjepx6bbz0&e=
>   \
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__springdale.princeton.edu_data_springdale_8_x86-5F64_os_BaseOS_Packages_springdale-2Dcore-2D8-2D0.sdl8.2.noarch.rpm&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=Bwvu8ORtdwu_qqgSySYBdSQ5VFU2sSZyj1XlHQ96Gz4&s=xBX0ndIbr0GKnXILKqPO-qmzF3uRMRJoqW64SxEgvjE&e=
>   \
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__springdale.princeton.edu_data_springdale_8_x86-5F64_os_BaseOS_Packages_springdale-2Drelease-2D8.3-2D0.42.el8.x86-5F64.rpm&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=Bwvu8ORtdwu_qqgSySYBdSQ5VFU2sSZyj1XlHQ96Gz4&s=EB5q0Mf4XnrLhTF5rmgjfjnR71LWhzI4xDHIRPwvwx8&e=
>  
> dnf distro-sync -y
> 
> the distro-sync will reinstall every package 
> 
> Ching Him

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

Re: Pondering a switch to Debian

On Thu, Feb 04, 2021 at 10:56:39AM -0800, Patrick J. LoPresti wrote:
> On Wed, Feb 3, 2021 at 4:58 PM Keith Lofstrom  wrote:
> >
> > So - who else is contemplating a move to Debian?
> 
> We will be following CERN and Fermilab's lead, whatever that is.
> 

Same here. We build experiments that are located at CERN, and people
who run these experiments are most comfortable if we use linux supported
or at least approved/annointed by CERN.

With the covid lockdown at CERN and everybody there working from home,
my contacts do not have any insider information. I used ot have some contacts 
through ROOT,
still watch that space and I see that ROOT have binary kits for every MacOS, 
for every
Ubuntu, for recent Fedora, for CentOS-7, but NOT for CentOS-8. I think there is 
a message here.

>
> But the longer we go without knowing, the more uncomfortable we get.
> Anybody have any inside information on their thinking?
> 

We all know what happened last time this happened (RHL->RHEL kerfuffle).

This time, I suspect that Red Hat did not see CERN, ATLAS, LHC experiments,
US DOE Labs in their list of paying customers and went ahead without consulting
with them.

Me, I am not worried, between debian/ubuntu, "free" RHEL and upcoming CentOS
reincarnations, our needs for open source operating systems are covered.

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

Re: Pondering a switch to Debian

On Thu, Feb 04, 2021 at 09:45:03AM -0500, Lamar Owen wrote:
> On 2/3/21 7:52 PM, Keith Lofstrom wrote:
> >... I'm thinking about
> >abandoning 25 years of Redhat experience and switching to
> >Debian, while my aging brain can still handle change.
> >...
> >So - who else is contemplating a move to Debian?
> 
> 
> [lowen] I am.
>

Lowen - thank you for your excellent write up. I am puzzled by a couple
of things and I have a few comments:

- you say good words about professionalism and make good noises
about the high quality of Debian, but you do not elaborate why
you think Ubuntu is lacking in this department.

- you illustrate nicely the problem of linux - half the people worry
about choosing the right linux for their personal laptop (to be groomed
to perfection) and half the people need a linux to run 10-20 computers
used by other people with requirements of minimum maintenance and
maximum uptime. The same linux is not the right linux for both uses!

- professionalism of Debian was recently put into the spotlight
as they re-voted to re-confirm their commitment to systemd (the issue
was that systemd prevented use of some other packages that some
people felt they should have the freedom to use. they were voted down).
check it out and make your own conclusions.

- "feature parity" of all Linuxes is nicely illustrated. I think one
would write pretty much the same report about migrating to BSD
or MacOS - all opensource packages are available pretty much on
all platforms, including Windows.

> 4.) Speaking of Altera Quartus II version 13.0sp1 (NOT version
> 13.1!) for MAX7000 CPLD and Cyclone II/IV/V FPGA development.  The
> simulation tools are substantially different between Quartus 9 and
> 13.0sp1 for the MAX7000, and I have projects in both versions.  This
> was also a bit of a challenge, as I had to hand-build and install an
> older version of libpng to get it to run.

- yes, this is a battle. we have and we use Cyclone-1 FPGA boards,
so running old versions of Quartus is a must. I am impressed
that quartus 13.0sp1 can be made to run on current debian/ubuntu
only "with little blood". Intel have now dropped support for even more FPGAs
from the current quartus, so it looks like we will be battling
this forever. (Our hardware guys are grumbling about switching
to Xilinx, there is some unhappiness about Altera FPGAs...)


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

Re: converting to RHEL8...

On Mon, Feb 01, 2021 at 12:26:00PM -0800, Konstantin Olchanski wrote:
> 
> Here we go. Conversion from CentOS-8 to RHEL-8 in 5 easy steps.
> 
> Instructions for converting CentOS to RHEL are posted here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_articles_2360841&d=DwIDAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=IBWdeVmMPbkgwCr8Ir6R307eFH3-2aZ9vYnQ7mEhhHM&s=Hhj0voUDSXlQKw63jIuVJYcerY5Bmru62tOJwbHKuMk&e=
>  
> convert2rhel-0.15-1.el8.noarch.rpm from github is not signed
> To be continued...

[root@daqlabpc ~]# rpm -vh --install convert2rhel-0.15-1.el8.noarch.rpm 
error: Failed dependencies:
   dnf-utils is needed by convert2rhel-0.15-1.el8.noarch
   python3-pexpect is needed by convert2rhel-0.15-1.el8.noarch
[root@daqlabpc ~]# 

[root@daqlabpc ~]# yum install dnf-utils python3-pexpect
[root@daqlabpc ~]# rpm -vh --install convert2rhel-0.15-1.el8.noarch.rpm 

[root@daqlabpc ~]# convert2rhel --disable-submgr --enablerepo  
--enablerepo  --debug

I do not know what REHEL_RepoID1 and ID2 are supposed to be. I do not have any 
Red Hat repos
in my /etc/yum.repos.d, I only have CentOS, epel, etc.

Dead end?

Let's try to use the subscription manager...

[root@daqlabpc ~]# convert2rhel --debug
...
WARNING - By continuing you accept this EULA.
Continue with the system conversion? [y/n]: y
...
WARNING - The following packages will be removed...
PackagePackager 
Repository
--- 
--
centos-logos-80.5-2.el8.x86_64 CentOS 
Buildsys  @AppStream
centos-logos-httpd-80.5-2.el8.noarch   CentOS 
Buildsys  @AppStream
centos-linux-release-8.3-1.2011.el8.noarch CentOS 
Buildsys  @BaseOS
centos-linux-repos-8-2.el8.noarch  CentOS 
Buildsys  @BaseOS
rhn-client-tools-2.8.16-13.module_el8.1.0+211+ad6c0bc7.x86_64  CentOS 
Buildsys  @AppStream
python3-rhn-client-tools-2.8.16-13.module_el8.1.0+211+ad6c0bc7.x86_64  CentOS 
Buildsys  @AppStream
python3-rhnlib-2.8.6-8.module_el8.1.0+211+ad6c0bc7.noarch  CentOS 
Buildsys  @AppStream
Continue with the system conversion? [y/n]: y
...
WARNING - Only packages signed by CentOS Linux are to be reinstalled. Red Hat 
support won't be provided for the following third party packages:
Package  Packager  
Repository
---    
--
certbot-1.11.0-1.el8.noarch  Fedora Project@epel
convert2rhel-0.15-1.el8.noarch   N/A   
@System
ganglia-3.7.2-33.el8.x86_64  Fedora Project@epel
google-chrome-stable-88.0.4324.146-1.x86_64  Chrome Linux Team 
@google-chrome-64
zfs-release-1-8.1.noarch N/A   
@@commandline
... and more
Continue with the system conversion? [y/n]: y
...
[02/04/2021 09:56:06] TASK - [Convert: Subscription Manager - Install] 
**
[02/04/2021 09:56:06] CRITICAL - The 
/usr/share/convert2rhel/subscription-manager directory does not exist or is 
empty. Using the subscription-manager is not documented yet. Please use the 
--disable-submgr option. Read more about the tool usage in the article 
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_articles_2360841&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=iel0E8JL_svyu_6W2ZUso-H4dxqnH78q5ZLs2Y3GXAU&s=juJeIzssALq8uliLKAAoGsvuo4IptowyO_g8EO7iuq4&e=
 .

Dead end?

In the comments section of 
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_articles_2360841&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=iel0E8JL_svyu_6W2ZUso-H4dxqnH78q5ZLs2Y3GXAU&s=juJeIzssALq8uliLKAAoGsvuo4IptowyO_g8EO7iuq4&e=
  there is some information
on what to do next, with dates 1-3 Feb 2021 (i.e. fresh just now) and promises 
from a Red Hat person
about "We are working on changes that will not require you to pre-download any 
package except convert2rhel."

So dead end for now, until Red Hat update the instructions.

To be continued...?

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

Re: converting to RHEL8...

On Thu, Feb 04, 2021 at 02:24:57AM -0500, Nico Kadel-Garcia wrote:
>
> > Here we go. Conversion from CentOS-8 to RHEL-8 in 5 easy steps.
> 
> Identically named RPM's do not necessarily have identical contents. To
> do a really *thorough* switch, you need to reinstall *everything*.
>

So you recommend as last step of conversion to run this:

foreach $rpm {
yum reinstall $rpm
}

I suspect this is unnecessary, but you are right, one will have a mongrel system
unless it is done. But do you know of any case where it makes a practical 
difference?
Even way back when?

>
> I used to publish scripts for this, for switching from RHEL to CentOS to
> Scientific Linux and other combinations.
> 

Time to dust them off, I guess.

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

Re: Pondering a switch to Debian

2021-02-03 Thread Konstantin Olchanski

On Wed, Feb 03, 2021 at 04:52:54PM -0800, Keith Lofstrom wrote:
> 
> So - who else is contemplating a move to Debian?  
> 

Count me in.

All ARM stuff is already Debian (Ubuntu/Raspbian/Raspios).

Tomorrow, I am converting my 3 ARM machines running CentOS-7 to Raspios,
next day, I am converting my 8 or so 32-bit-only VME processors from SL6 to 
Debian (32-bit).

If we could run RedHat-flavour stuff on all our hardware,
there could be a question. But running Debian-flavour stuff
on everything and RedHat-flavour only on x64_64?

>
> I very much hope to stay connected to the "scientific"
> aspect of our community.  Making big changes together
> with other science computationalists would be easier.
> 

I figure we stick together on this mailing list here.

>
> Easier still would be staying with an RPM distro, IF ...
>

... if they did not mess with RPM (yum replaced with dnf)
and made it easier to build RPM packages.

For installing cross-platform scripts, I am switching from RPM
to "git clone; make install (installs to /opt)".

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

converting to RHEL8...

2021-02-01 Thread Konstantin Olchanski

Welcome to my "convert to RHEL8" blog. As you might know, I have been running
Red Hat, SL and CentOS machines for about 25 years now. Lacking SL-8,
latest incarnation of this series is CentOS-8 and now powers-that-be
instruct us to use RHEL-8 instead. So,

Here we go. Conversion from CentOS-8 to RHEL-8 in 5 easy steps.

Main announcement of "16 free RHEL subscriptions" per "developer":
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_en_blog_new-2Dyear-2Dnew-2Dred-2Dhat-2Denterprise-2Dlinux-2Dprograms-2Deasier-2Dways-2Daccess-2Drhel-3Fsource-3Dblogchannel-26channel-3Dblog_channel_red-2Dhat-2Denterprise-2Dlinux&d=DwIDAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=IBWdeVmMPbkgwCr8Ir6R307eFH3-2aZ9vYnQ7mEhhHM&s=Nr6cQ40qpd7tUZVaiCs5XQ0MyOB6xi3VeKjzLmSVuYQ&e=

I do have a RedHat developer account. A few weeks ago, there was nothing there,
as of a few days ago, there is a "1 active subscriptions" page, as of today,
there is a "using 0 out of 16 entitlements" page. (I do not see any
email notices about all this activity and I do not see any blog messages
about this. So communications can be improved).

I also see a link to download RHEL8 ISO and DVD images, I did not try it yet.

So far so good.

BTW, when logging into the RedHat developer account, there is a number
of click-through agreements to "agree" with. Read them. If you
do not like them, tough!

Instructions for converting CentOS to RHEL are posted here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_articles_2360841&d=DwIDAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=IBWdeVmMPbkgwCr8Ir6R307eFH3-2aZ9vYnQ7mEhhHM&s=Hhj0voUDSXlQKw63jIuVJYcerY5Bmru62tOJwbHKuMk&e=

They start with "hire Red Hat to do the job" (fair is fair, nothing better
than expert help!), and move to the Convert2RHEL tool.

This tool, at
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oamg_convert2rhel_&d=DwIDAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=IBWdeVmMPbkgwCr8Ir6R307eFH3-2aZ9vYnQ7mEhhHM&s=abbG4Y8cEtfUdozsmDGSszrCG5MueYPy9xL-1FiW348&e=
, does not appear to be
an official Red Hat or CentOS product and I see only one author/maintainer
listed,
from Vsetín/Czech Republic. A tool directly developed and maintained by
RedHat/CentOS
would have been much preferred, especially by those worrying about
"supply-chain" integrity.

convert2rhel-0.15-1.el8.noarch.rpm from github is not signed, not even by the
author,
so the chain of trust going from "everything signed by centos" to "everything
is signed by redhat"
is not preserved. The possibility of downloading and running a trojaned
conversion
script is not eliminated.

Next, I see this: "Known issues: UEFI-based systems cannot currently be
converted to RHEL. (BZ#1899314)",
I am not sure if my CentOS-8 test system uses UEFI or Legacy boot, but I am not
worries
about this, fixing "broken grub" boot problems is routine. As likely as not I
will
replace the grub2 boot loader with syslinux, which is much more stable and also
easy to debug.

Next, I do not see in the instructions the step for obtaining and installing
a Red Hat subscription activation key. I assume I get the activation key
somewhere in my Red Hat developer account, but I did not find the button
to do this yet, and I do not know what to do with the activation key anyway.

To be continued...

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

Re: sudo fix for SL6

2021-01-29 Thread Konstantin Olchanski

On Thu, Jan 28, 2021 at 11:28:04AM +, Rhys Morris wrote:
> ... from the official sudo webpage

Ok, looks like this is it. from sudo.sw, version 1.9.5p2 fixes CVE-2021-3156,
download the el6 rpm file, install, looks okey. both 64-bit and 32-bit RPMs are 
available.

[root@ladd00 ~]# rpm --upgrade -vh 
/daq/daqstore/olchansk/linux/SL/sudo-1.9.5-3.el6.x86_64.rpm
[root@ladd00 ~]# sudo -V
Sudo version 1.9.5p2

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

sudo fix for SL6

2021-01-27 Thread Konstantin Olchanski

sudo is broken, CVE-2021-3156. Fixed packages are out for el7, el8, ubuntu.

There is a fixed package for RHEL6, sudo-1.8.6p3-29.el6_10.4.x86_64.rpm, see
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_errata_RHSA-2D2021-3A0227&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=DdnVo6dknCRTqounMfG7Q82qFx2i7ANhA2ba5RkXC4g&s=R-6UJIwBbW5KnUMkSLmGuGA03CoQQ0nkVLXkC2ogupA&e=
 

Now, any chance of fixed package for SL6? (just checked, no fix in CERN SLC6, 
no fix in EPEL).


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

Re: Rhel 8

2021-01-25 Thread Konstantin Olchanski

On Mon, Jan 25, 2021 at 11:31:08PM +, Miles ONeal wrote:
> 
> | For me, the issues are not policital, but technical:
> 
> Agreed. One of mine is that the surety of being able to drop a lower runlevel 
> and back up is gone. ...
>

If you ask me, systemd was designed and built to solve one and only one problem,
boot it's author's personal 1 core 300 MHz laptop as fast as possible. Today,
with 4 core 3000 MHz laptops and 16 core 4000 MHz "servers", many features
of systemd look quaint. ("waiting for USB devices to settle", really?).

Benchmarks that report "old" and "slow" SysV initscripts boot as fast as systemd
tend to support this viewpoint.

Each time I look at the systemd boot sequence trace, I see things like
"waiting 10 sec for disks that are not needed for booting" and
"waiting 10 sec for network not needed for booting". If unlucky, also see
"waiting forever for disk that failed and was removed" (hello, booting from 
degraded btrfs raid array).

How this stuff got into "E" linux and why paying customers put up with this,
is a mystery to me. Perhaps said paying customers "never reboot" and never
see systemd shortcomings (and get no benefit from "systemd fast booting").

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

Re: Rhel 8

2021-01-25 Thread Konstantin Olchanski

On Sat, Jan 23, 2021 at 06:41:39PM -0600, ~Stack~ wrote:
> 
> TL;DR synopsis.
>

Mr. Stack, Sir! Thank you for writing up this historical overview,
I read it with great enjoyment. Of course I have a few comments.

> It's just a tool.

I feel blindsided by this systemd business. I cut my teeth starting
with SGI IRIX circa 1992, and I am well aware of the shortcomings
of SysV init scripts. I am also well aware and I celebrate it's main
feature. Any and all problems I ran into could be fixed in a couple
of hours using "vi". (hack the bad script until it works).

So years later, "upstart", etc start showing up and I thought "whatever...",
it cannot be worse than SysV scripts. And sure enough. (SL4, SL5, SL6 era).

Then I read in the news this whole "systemd kerfuffle", and I think,
"whatever...", it cannot be that bad, if it is good enough for
Red Hat *Enterprise* Linux, should be good enough for me. Must be a tempest
in a tea pot, another vi/emacs holy war, for sure they will fix all
the bugs by the time I see it.

Then it shows up in all it's glory in SL7, and? With my eyes I see
that, yes, it is as bad as the worst naysayers have proclaimed.

For me, the issues are not policital, but technical:

- cannot ask "what order will you start things on boot?"
- does not start things on boot in the order I specified in the service files
- designed-in chicken-and-egg problem with systemd and dbus each starting first
  and registering with each other
- documentation is for latest version, but my computer has version N-5, half
  of advertised functions are absent
- the infamous bug report about systemd rejecting valid user names (in the 
nutshell,
  systemd author decreed "I decide what usernames are valid" and closed the bug)
- broken-out-of-the-box, "shutdown -r now" does not shutdown "NOW!!!". Tries
  to logout interactive users, unmount NFS filesystems (after shutting down
  the network), waits until programs users run in background terminate).

By this list, clearly, basic debugging and basic system operational needs
are not important to the systemd designers and developers.

And I guess it is all my fault, I should have rooted for the right team
back in 2002 (or whenever) on the Fedora and Debian mailing lists.
Instead, I was asleep at the switch, being a happy user of SL4/5/6.

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

Re: [EXTERNAL] Re: arstechnica: "CentOS is gone-but RHEL is now free for up to 16 production servers"

2021-01-21 Thread Konstantin Olchanski

On Thu, Jan 21, 2021 at 07:04:14PM +, Queen, Steven Z. (GSFC-5910) wrote:
>
> Appropriately, it was IBM that invented FUD as a sales-technique in the first 
> place.
> 

Alarming that IBM FUD is working against IBM. Decline of the mighty. Boeing 
airplanes
only fly down, NASA rockets cannot go to the Moon, etc.

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

Re: arstechnica: "CentOS is gone—but RHEL is now free for up to 16 production servers"

2021-01-21 Thread Konstantin Olchanski

> From the Arstechnica URL: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__arstechnica.com_gadgets_2021_01_centos-2Dis-2Dgone-2Dbut-2Drhel-2Dis-2Dnow-2Dfree-2Dfor-2Dup-2Dto-2D16-2Dproduction-2Dservers_&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=5UNRADR6PpQVqP97Jl4VT9V4oTZCHRSZp5Php98SpHI&s=HmS-gVxXfw2RalHvyfiHtb9c1M1J1HQ20J613PRjRDE&e=
 

Me, waiting for the dust to settle, still too much BS and FUD flying around 
right now:

- articles titled "rhel is now free" with small print "... starting in 
february..."
- cost of managing licences counted under "free"
- artificial limits of 16 systems (what if I need 17 for a couple of days?)
- red hat reported as officially stating "[this] ... isn't a fly-by-night ... 
program" (echoes of Mr.Nixon famously saying "I am not a crook")
- false dichotomies of individual vs team users, development vs production 
systems
- "free this year", next year, a maybe.

I think I will convert my one Centos-8 machine to the "starting in february"
free rhel license, just to experience the "new and improved".

P.S. And what about CentOS/RHEL on ARM? Today, we run CentOS-7 on ARM just fine,
but going forward? Does somebody expect us to run ARM with 
Raspbian/Debian/Ubuntu,
but stick with RHEL on x86? Really? In our detector lab, ARM machines just
about outnumber x86 machines. The direction that is going, maybe red hat got it 
right
and the "16 systems" limit will be a non-issue.


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

Re: Way Off Topic - HEP Network Symphony Orchestra

2020-12-22 Thread Konstantin Olchanski

On Tue, Dec 22, 2020 at 04:24:33PM -0800, Keith Lofstrom wrote:
> 
> There are probably more symphony fans than high energy
> physics fans (many physicists are both) ...
>

Hmm... I am not a fan. I am a blower of flutes and whistles!

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

Re: Update from Rocky EL

2020-12-17 Thread Konstantin Olchanski

Rumination time, I jump in.

> >Why did monolithic kernel Linux, based primarily upon the
> >non-production-environment OS Minix from Tanenbaum used as an
> >implemented example for teaching OS at the undergraduate level,
> >achieve sector dominance over micro-kernel BSD-derivatives? ...

Linux killed everybody with superiour performance, for every
competitor, both microbenchmarks and real-use performance
of the Linux kernel were/are measurably better.

> [what happened to BSD & derivatives?]
> ... it boils down to a great deal of uncertainty around BSDI,
> UCB's CSRG, Bill Jolitz, and 386BSD, all of which descended from
> the Unix codebase ...

The USL-BSD lawsuit came just at the right moment to cut the BSD
movement down at the knees. By the time the dust settled and
BSDs were running on PC hardware, Linux was already established.
correlate the timelines of lawsuit against Linux and BSD timeline:
https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_UNIX-5FSystem-5FLaboratories-2C-5FInc.-5Fv.-5FBerkeley-5FSoftware-5FDesign-2C-5FInc&d=DwIDAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=47s95Ne0aOss4Lm0rou8QPxpzTQCi3wXRAuoDuFUQCk&s=RFr_K56_2XQYOg5Dxhg6Opq3kewSaB-o7k4ldfvsSwk&e=
 .

> Linux is greenfield

I tend to think that was the key. Linux always had the advantage over BSD
in three areas (if you studied, programmed and used both, you already know 
this):

- better TCP/IP stack in Linux
- better virtual memory system in Linux
- better filesystems in Linux

In all three, Linux had the "green field" advantage, plus the incentive
to beat competitors (at the time, BSD UNIX, SGI/IBM/DEC/SUN Unix derivatives).

In the TCP/IP stack, Linux people implemented zero-copy transfers and support
for hardware-acceleration pretty much right away.

In the VM system they figured out just the right balance between
application memory, kernel memory and filesystem caches, compared to BSD
"active/inactive" (and nothing else).

In filesystems, Linux was the first to solve the problem of "no corruption,
no need for fsck" after unexpected system reboot (i.e. on crash or power loss).
(with ext3/ext4). (ok, maybe SGI was there first for the rich people, with XFS,
but look what happened, XFS is now a mainstrean Linux filesystem).

>
> Although, re-think your statement; Darwin with the macOS skin on it
> has a great deal more marketshare than Linux.  In many ways the
> BSD-system-layered-on-a-microkernelish core did win; just not the
> hearts of developers.
> 

I would say, MacOS "won" not because but despite it's BSD foundations.

If you look behind the curtain (heck, if you look *at* the curtain), you will
see a BSD-ish kernel firmly stuck in the 1990-ies. No semtimedop() syscall, 
incomplete
pthreads (no recursive locks), no /dev/shm (no command line tool to see and
control POSIX shared memory). The only visible kernel level innovation
are the "never corrupts" filesystem (mostly due to "never crashes" hardware, I 
suspect)
and improved VM (encrypted *and* in-memory compressed, impressive!).

Anyhow, today, MacOS wins at ping-pong while the game is hockey, if Apple still
built hardware for serious computing, for sure the MacOS BSD "win" would count.


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

Re: Springdale Linux

On Mon, Dec 14, 2020 at 01:27:31PM -0800, Yasha Karant wrote:
> >>
> >>>and ... CentOS RPMs are not 100% safe ...
> >
> >This is a very unexpected statement. I feel it should not be passed 
> >unquestioned.
> >

To followup on myself. Need a definition of "unsafe". Must make
a distinction between "centos is unsafe" vs "redhat is unsafe" vs
"linux is unsafe" vs "any use of computer is unsafe".

("safe as certified by recognized authority" need not apply,
cars and airplanes are certified for safety, but still crash).

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

Re: SL7 with security and bug fixes forever - how much work?

On Mon, Dec 14, 2020 at 12:54:27PM -0800, Yasha Karant wrote:
> ... Out of curiosity, how similar are the Apple Mac ARM CPUs to the CPU used 
> in
> the Fujitsu Fugaku HPC machine (A64FX 48C 2.2GHz)?

Hard to tell. (easy to tell, "just read the specs")

The Intel "magic souce" was always the "cache + memory controller" combo that
consistently runs a few cycles faster compared to competition (IBM, SGI, AMD, 
Altera,
Xilinx, etc), and people see this difference in real-world applications.

How good is the generic ARM cache and memory controller and the Apple cache and 
memory controller,
and in real world applications, remains to be seen. As of a few years ago (1 
GHz era), ARM chips
built for embedded use had pretty slow memory (i.e. single channel vs Intel 
dual/quad channel,
DDR3-1066 vs DDR4-3200, that kind of slow). Today's ARM? I guess I should run 
my memory benchmarks
on my RPi3/RPi4 boards and on the latest Xilinx ARM board we have in the lab...

And then there are the "performance/$$$", "performance/watt" and 
"performance/kg" metrics.

ARM always did well in "performance/watt", meaning that you can cram more of 
them
in the same cooling-limited volume, yielding good "performance/m^3", important 
for building
supercomputers.

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

Re: Springdale Linux

>
> > and ... CentOS RPMs are not 100% safe ...
>

This is a very unexpected statement. I feel it should not be passed 
unquestioned.

Is there any meat there or it's just a general statement on the security
of the CentOS build process vs the security of the Red Hat build process
vs the security of the Princeton build process? (including signatures of source 
code,
signatures of binary packages, security of the mirror network, etc).

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

Re: SL7 with security and bug fixes forever - how much work?

> 
> > ... Apple is leaving the X86-64 platform for an ARM platform. ...
> 
> The recent releases of macOS went 64-bit only ...
> ... transitioned from PPC to x86.
> ... cut out a lot of old software
>

I have one leg in the MacOS world and I went through both transitions,
PPC to Intel and 32-bit to "64-bit only".

I remember both were pretty much no-events.

Ran "fink update", "ports update", and all the linux-side software was good.
Joints like VLC, Firefox, Google-chrome, issued updated packages quickly.

Commercial things like the "amazing slow downer", I remember paying
for an updated license (an app well worth the money, recommended.
but very specialized of course).

Moving our linux work from x86 to ARM is similarly a non-event, except
for the need to cross-compile for some non-self-hosting embedded
machines.

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

Re: SL7 with security and bug fixes forever - how much work?

On Mon, Dec 14, 2020 at 02:36:20PM -0500, Serguei Mokhov wrote:
> >
> > I have done this in the past with mixed success, typical problems
> > include "cmake is too old", "autoconf/autotools are too old".
> 
> Having run into this at a smaller scale for one of the projects I ended up 
> using
> devtoolset-6 (and -7 as appropriate) that ships all this stuff such as
> newer GCC,
> GLIBC, etc.
> 

Yes, devtoolset is the advertised solution. I bought into it myself,
and then got burned after discovering that is it is missing one critical
32-bit shared library and it cannot be used to cross-compile 32-bit executables,
a "must have" for a couple of experiments that use hardware
with 600-1200 MHz Pentium-3 processors. (replacement hardware is in the USD$5000
price ranges, quantity "to be upgraded" is around 10, none of this has
been budgeted and 64-bit upgrade is not needed for the function
they perform).

Anyhow, is there commitment to devtoolset updates to c++17, c++20, c++21, etc?

For our MIDAS Data Acquisition package, we just started using c++11 recently,
and already we desire to use c++14 and c++17 features. (cannot, because of el7).

Then, there is the question whether SL7 "upgraded to latest versions of 
everything"
is still SL7. ("grand father's axe", etc). For a purist, SL7 is something
installed from an official installer image, adding packages from EPEL and ELREPO
starts pushing it. SL7 with custom-built linux kernel, glibc, sshd, httpd, kde,
php100 and python3000 is probably not SL7 anymore.

The label "SL7" is only useful if it refers to something well defined. If every
instance of SL7 has a different linux kernel, different versions of devtoolset,
different cmake, different python, etc, I would say SL7 no longer exists.

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

Re: SL7 with security and bug fixes forever - how much work?