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

[Mark Rousell]

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

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

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

(Sorry, I realise that this is going off topic).

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

[Mark Rousell]

On 05/05/2021 23:53, Yasha Karant wrote:
> From the list you reference below, I find
>
> Amazon Web Services
>
> (AWS) is *NOT* a small (market share, startup, etc) for-profit entity.
> Is AWS looking at an alternative to licensing IBM RH EL that AWS can
> use without any license for fee?  AWS has ample internal technical
> staff to maintain any software system AWS deploys, provided source is
> available.
Note that Amazon already has Amazon Linux available to host on AWS which
is their own customised rebuild of RHEL.

As for RHEL licence fees, it's not Amazon's problem. One way or another,
the customer pays for RHEL's licensing fees if they choose to host RHEL
on AWS. That said, I imagine that CentOS is popular on AWS and so it
makes sense for Amazon to culture and support Rocky so that users who
might previously have chosen CentOS (and who don't want or need CentOS
Stream) can go with Rocky.

Supporting an open source project like Rocky is also good public
relations in general for Amazon.

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

[Mark Rousell]

On 05/05/2021 00:38, Yasha Karant wrote:
> I have not attempted to get a "dev" IBM RH license that supposedly is
> at no cost -- has anyone done so and down a full buildable source
> download?

Just go here to create a free dev account (which allows up to 16 RHEL
instances and, of course, access to the source):
https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.redhat.com_=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=ObAgDY_TU7L4qolv1HO4YKSLeRAOSzDkm6OTpx47idw=8oCGvFp4dJb4JYifT2CdSkj6ZNstAyKIQHh0qmtXEoc=
 . I have a free dev account. It is very
easy to sign up.

Once you have an account you can easily download the sources. It is
obviously buildable if you can figure out how to build it. I've never
tried. Other clever people are kindly willing to do that for me!

The source (for RHEL 8.3, as an example) is downloadable as a 20.1GB ISO
containing, I believe, SRPMs. I did download it once but I've never
bothered to look inside it.

Building from the RHEL source RPMs (and removing the Red Hat proprietary
IP) is left as an exercise for the reader. ;-)

Thus building an open source clone of RHEL with the Red Hat proprietary
IP removed is of course possible, but no one said it had to be easy or
straightforward.

It is not surprising in my opinion that it has taken the Rocky project
some time to get to an initial RC state. As far as I am aware, Alma was
only able to do it more quickly because CloudLinux was already a rebuild
of RHEL (with their own customisations) and so they already had a
working build system in place that they could alter to produce a 'pure'
clone in the form of Alma.

> Does this also access the update buildable source for the installable
> "binary" updates provided by IBM RH EL for the licensees?

I think so, yes. There is an 'Errata' section in the downloads area for
RHEL that has a list of advisories. If you look at the details for each
advisory then you can see a list of updated packages for it and this
usually includes download links for both binary RPMs and source RPMs.

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

[Mark Rousell]

On 04/05/2021 23:41, Leon Fauster wrote:
> The source are at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.centos.org=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=0Cvrr_2WDkcsrPdHGtY_tjL0G9TG69QDuL7UWeyXUhc=ujZIUv5p_MGjr0gtRL9D7zIJAitkNauyt8wOXo1WxwQ=
>

That's CentOS isn't it? That's fine if one wants to try and build CentOS
but if one is building a RHEL clone (with Red Hat proprietary IP removed
of course) then one would need the RHEL sources. The RHEL sources are
available from 
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_downloads_=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=j7HyDpnhirEMJBg_NyqSf43v4NrMklLO4X7inAV3jK0=rd9KTZHBwuQQQ7W-Q27rrfW6d3PRUEOiLF2R0s3xmDg=
  as long as you have
a suitable account.

And, in any case, after CentOS 8 support ends then the only CentOS
sources will be CentOS Stream sources which, as has been discussed at
length, will not be suitable for many use cases.

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

[Mark Rousell]

On 04/05/2021 21:42, Yasha Karant wrote:
> Your statement at the end indicates that I have missed a source
> distribution channel.

Sorry, which statement is that?

Just for the avoidance of doubt, my comment about "Discourse" was a
reference to the Discourse software https://urldefense.proofpoint.com/v2/url?u=https-3A__www.discourse.org_=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=Rv6JPgfKB6WloyI9yzgIIJbr2llfrUuvqHQYxk1NNJw=h7okDDver9ejoWFtsZ0S8V58a9TPFpgQrea3hqgyB5U=
 >> that Alma uses in place of a more
traditional web forum.

> You state that there will not be a CentOS 9 and only a CentOS Stream
> perpetual alpha or beta channel.

To be clear, I'm just an observer of all this but surely the whole point
of Red Hat's infamous announcement is that CentOS 8 is to be the last
version of non-Stream CentOS. So we know that there will not be a CentOS
9. And we do know that there will be a CentOS Stream 9 because they have
announced it.

> I thought that IBM RH would not directly release buildable production
> EL source, but would channel it under a CentOS moniker.

To the best of my knowledge Red Hat never announced any change to the
release of RHEL source in accordance with the software licences. If you
have access to RHEL then you have access to the source ISOs.

> How does IAS Springdale, Rocky, Alma, etc., get buildable production
> source for IBM RHEL9?

I would assume that (a) they download it from Red Hat using an account
with legitimate access to RHEL (such as a free dev account), (b) modify
it to remove Red Hat trademarked IP, and (c) design and operate a build
system that allows them to build it. They will presumably get the RHEL9
source ISO as and when RHEL9 is available.

I have a free Red Hat dev account (the same account type that has now
been extended to cover 16 free RHEL licences) and I can freely download
the ISOs containing the source.

> Does one have to buy the source from IBM RH? Will IBM RH or another
> IBM entity house the production source for the current production EL? 
> What about the defect correction, including security defects, as well
> as minor release, update production source?

Nothing has changed to the best of my knowledge. It's all available
according to the GPL terms. (Yes, I know that the RHEL software almost
certainly contains code licensed under other software licences but GPL
is certainly the main one that is of concern.)

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

[Mark Rousell]

On 04/05/2021 21:51, Jack Aboutboul wrote:
> Yes and contrary to the pure FUD that has been spread around, the AlmaLinux 
> OS Foundation is in fact a 501©6 non-profit and our governing board includes 
> a leadership from diverse backgrounds, some from industry and even Simon 
> Phipps, former president and current standard & policy director at the Open 
> Source Initiative. We strongly feel like the scientific community needs a 
> seat at the table as well.
>
> We set this up precisely to prevent the mistakes of the past and any 
> “acquisition.” The project is open to any and all, forever to own and 
> participate in. This model works well as it allows for transparent 
> operations, communal ownership as well as a mechanism through which 
> corporations can sponsor the ongoing efforts of the Foundation.
>
> We are in the process or re-doing the website and we will publish a page on 
> the board and its members, including meeting minutes when they happen, etc.

This is all very good to hear. Thanks for the information.

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

[Mark Rousell]

On 04/05/2021 20:51, 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".

Didn't the founder of Rocky leave CentOS before it was 'bought' by Red
Hat? My understanding is that both Alma and Rocky are getting
foundations set up to support and own them, making it much harder for
them to either be bought out or acquihired.

As I understand it, CentOS was not 'bought' as such by Red Hat because
there was no single entity to buy. What Red Hat did (as I understand it)
was to hire all the key developers and then independently buy the rights
to trademarks and IP, etc.

A proper foundation structure with a defined constitution/mission should
in theory protect against that kind of buy out/acquihire. Even if all
the future key developers are hired by a competitor, the software,
trademarks, IP, etc. will not be so easily purchased.

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

[Mark Rousell]

On 04/05/2021 18:01, Yasha Karant wrote:
> then one is forced to either Rocky or AlmaLinux, assuming either
> pushes out an EL 9 clone as soon as CentOS or other IBM RH buildable
> source is released.

Well, we know there's not going to be a CentOS 9. There will obviously
be a CentOS Stream 9 but, as you say, that is not a viable replacement
for those who want RHEL's stability without paying Red Hat for it.

The point of Rocky and Alma is to be downstream of RHEL so one assumes
that they will do an EL9 clone as soon as they can after it exists.

> Otherwise, for those who do not have a too heavy investment in
> hardware "driver" or specific software/systems application RPMs, there
> is Canonical Ubuntu LTS.  Ubuntu lacks anything similar to this list,
> as from my direct sign up and inspection of AlmaLinux does that distro
> as well -- both have something similar to "Ask Ubuntu" that is much
> more cumbersome and much more eyecandy than this straightforward
> list.  And, many more "non-systems" comments, much less of an
> "engineering" approach than this list.

The problem is that mail lists are so last century in the eyes of many.
Personally I like mail lists but I know I'm in a diminishing minority.

There's nothing stopping a third party creating a mail list for Ubuntu
or Alma but I regret to say that I doubt it would get many takers. Note
that Ubuntu has a busy forum here, Ubuntu Forums
, which is what people often desire nowadays.
And Alma has its Reddit and a (dreadful in my opinion) Discourse group
at AlmaLinux - AlmaLinux Discussion Community
.

Some people love Discourse, others detest it. It seems very lightweight
to me.

Re: Rhel 8

[Mark Rousell]

On 24/01/2021 18:07, Mark Rousell wrote:
> As for why less bloated (as many would see it) or over-expanded (as
> many would see it) init systems have not been more widely adopted


s/or over-expanded/or not-over-expanded/

Re: Rhel 8

[Mark Rousell]

On 24/01/2021 16:26, Serguei Mokhov wrote:
> On Sun, Jan 24, 2021 at 11:00 AM Mark Rousell  
> wrote:
>> BUT... the fact that SysVInit is seen as outdated is NOT a reason in and of 
>> itself to support SystemD.
>> There may have been and, in many people's opinion, there were and are better 
>> init systems
>> to replace SysVInit than SystemD. "Better" being both a technical and a 
>> political/social/industrial construct.
> Mark, please name the better ones. And possibly why have they not been
> widely adopted?

Hehe, as I said before, I claim nothing and merely report common views.

On that basis, I will note that many people take the view that there are
numerous init systems available that have the key benefit, in their
view, of *not* trying to be vastly more than an init system really needs
to be.

As for why less bloated (as many would see it) or over-expanded (as many
would see it) init systems have not been more widely adopted, one can
only observe that there are many possible reasons for this and technical
ones, whilst certainly amongst them, are not necessarily the only ones.
As I say, one must evaluate contentious systems not only in a purely
technical light but in a political, social and industrial context too.

Re: Rhel 8

[Mark Rousell]

On 24/01/2021 02:52, Lamar Owen wrote:
> Straight SysV init does not meet the needs of many server setups,
> especially server setups that need to dynamically change the daemon
> mix that is currently running.  Virtualization hosts, software-defined
> networking setups, and what is typically called 'cloud' services are
> use cases for things systemd does well.  The antiquated concept of
> runlevels works fine for relatively static workloads; not so much for
> more dynamic workloads on the server side.

This is undoubtedly the case but of course it doesn't necessarily follow
that SystemD is the correct solution. And that's where the controversy
arises.

> Difficult?  That is the understatement of the decade.  I prefer to
> honestly evaluate new technologies with a bit more pragmatism; do I
> like having to learn a different way of doing things?  Not really; but
> after Debian adopted systemd I took more notice.

The thing is, one cannot wisely evaluate something on *purely* technical
grounds because its function in reality may not be entirely or purely
technical. Issues of politics and control of industry and/or mindshare
are relevant too.

And, even on purely technical grounds, one of the key criticism of
SystemD is *NOT* the need to learn something new; the criticism is about
how SystemD is structured and its ongoing bloat and growth. Learning new
stuff is part and parcel of working in any capacity with computers and I
have seen no one seriously complain about learning anything new in
relation to SystemD. It is what they have learned that has concerned
them and led them to be critical.

> but the potential vulnerability footprint is much smaller

To say the least: This is a view that is not necessarily globally
shared. ;-)

It's different, sure. But not necessarily smaller and not necessarily
more visible, more manageable, more identifiable, or more fixable.

> But even then virtually every systemd installation will happily run a
> SysVInit-style initscript (and will log to /var/messages in plain
> text), just like Upstart before did in EL 6 (well enough that people
> forget that EL 6 didn't run a straight SysV Init anymore).

As ever, the fact that SystemD can run SysV scripts is not the problem
and does not solve its problems as many people see it.

It is the structure and overall design of SystemD (and, in many people's
views, its political/social/industrial context) that are the problems
that many people see with SystemD.

Very few people mind a new init system. That's why people seem to have
forgotten about Upstart. What people clearly do mind is how a certain
init system is designed and implemented and how it seems to be growing
beyond being an init system.

In other words, SystemD specifically is the problem as many people see
it, *not* new init systems in general.

> SysV Init was a substantial upgrade from what came before (I remember
> those days, running Xenix V7 and System III), but in today's
> containerized, virtualized, dynamic server world it simply isn't
> sufficient for a large enough percentage of real-world server workloads.

Sure. I think it safe to say that the majority of those who are critical
of SystemD would not disagree with you on this.

BUT... the fact that SysVInit is seen as outdated is NOT a reason in and
of itself to support SystemD. There may have been and, in many people's
opinion, there were and are better init systems to replace SysVInit than
SystemD. "Better" being both a technical and a
political/social/industrial construct.

Re: Rhel 8

[Mark Rousell]

On 23/01/2021 02:20, Yasha Karant wrote:
> I had not heard the history of SystemD in any detail.  What, if any,
> were the software engineering and design justifications for SystemD? 
> I recall some vague mentions of "designs for the future"

Have a look at the SystemD Wikipedia entry which links to the SystemD
home page.

As I understand it the initial impetus for SystemD (as with all the
other competing init systems) was the perception that SysVInit was/is
obsolete or not suitable for modern life. One of SystemD's claimed
advantages over SysV was faster booting. However, in my experience
similarly specced SysV machines seem to boot faster!

It's difficult to say anything about SystemD without it becoming
political/religious but my impression is that the bloat and mission
creep that SystemD seems in many people's views to suffer from (i.e. it
is no longer just an init system) is perhaps less about "software
engineering and design justifications" and perhaps more about mindshare
grab and ecosystem control. I claim nothing; I merely report common
views. ;-)

Re: Rhel 8

[Mark Rousell]

For what it's worth, Debian (with SystemD) has a LTS version:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.debian.org_lts_=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=i5ehAuGzumUursAzQvltYnLOsvm3z8pbqtb3U8UKd9Q=Ga1isLA9_dB_btXvMDqKyniiS3Karm8DKd1M5SCVRCc=
 . And there is Oracle Linux as well, of
course, which is definitely intended for enterprise use (yes, I know
it's a rebuild of RHEL, with optional additions, but I include here it
for completeness).

But this begs the question of "what *really* is an 'enterprise' distro?".

To my mind it's less about about having "enterprise" in the name or in
the marketing and more about whether or not you feel you can trust it in
your particular enterprise. As such, Debian and Devuan (even though the
Devuan team is very small) definitely qualify for "enterprise" use  in
my opinion. They are reliable, trustworthy distros that many people run
their businesses on.

If they move more quickly in terms of kernel, libraries, etc. than the
likes of RHEL and its rebuilds then that is not necessarily a bad thing.
The software world as a whole is moving much more quickly than it used
to and RHEL's long term stability is not necessarily the advantage that
it might once have been. It really does depend on your specific use case
and enterprise, technical or business needs. I state the obvious when I
say, for example, that a HPC cluster's longer term stability needs are
probably very different to a web server's long term stability needs. And
yet both use cases need a good distro that one can rely on. It doesn't
necessarily have to have "enterprise" in the name, though.

> Was Torvalds behind SystemD, etc.?  Just curious.

No, he was not! He has been critical of it in the past, as I recall.

SystemD is a Red Hat project and the original author was the
controversial figure of Lennart Poettering.

SystemD's continued seeming mission creep causes a great many people to
be very suspicious of it. (Which is just about the understatement of the
Century so far. ;-) ).



On 23/01/2021 00:01, Yasha Karant wrote:
> My understanding is that only SuSE, Red Hat, and Ubuntu produce open
> systems ("free to port" with attribution and removal of copyrighted
> logo intellectual property) "enterprise" distros -- and all of these
> in current production release use SystemD, etc., baggage.  Was
> Torvalds behind SystemD, etc.?  Just curious.
>
> On 1/22/21 3:55 PM, Mark Rousell wrote:
>> On 22/01/2021 16:30, Larry Linder wrote:
>>> My only wish is that the SL community start a New Linux based on SL 6.9
>>> and erase all the needless junk added to SL 7.5.   Mainly dump the
>>> systemctl crap.   If only expands the number of characters I need to
>>> type to get it done and contributes nothing to operational efficiency -
>>> more bloat ware.
>>
>> This is in Debian too.
>>
>> If you want a Debian without SystemD then check out Devuan.
>>
> .

Re: Rhel 8

[Mark Rousell]

On 22/01/2021 16:30, Larry Linder wrote:
> My only wish is that the SL community start a New Linux based on SL 6.9
> and erase all the needless junk added to SL 7.5.   Mainly dump the
> systemctl crap.   If only expands the number of characters I need to
> type to get it done and contributes nothing to operational efficiency -
> more bloat ware.

This is in Debian too.

If you want a Debian without SystemD then check out Devuan.

Re: [SCIENTIFIC-LINUX-USERS] scientific.org

[Mark Rousell]

(I've been forced to post this via the Outlook.com web UI. It's vile. Sorry.)

On 11/06/2020 15:34, Larry Linder wrote:
> When I did a search on the internet for the problem.  There were a
> number of reports from other distributions of linux 6.10 with the same
> problem.
>
> I tried their recommended fix but did not work.
> They added aline into smb.conf.
>client max protocol = NT1  
>
> They also indicated that windows 10 had an issue with samba.  Several of
> our laptops running a stripped Windows 10 can see the server but not
> now.

I don't know if this will be helpful to you here and now but here goes. I 
believe that the "client max protocol = NT1" line limits the SMB version to 1. 
However, SMB1 is now deprecated in Windows 10[1]. So, with a current default 
Windows 10 configuration combined with "client max protocol = NT1" in your 
smb.conf files, your Linux and Windows boxes won't be able to talk to each 
other. Furthermore, Samba itself is in the process of deprecating SMB1 with a 
view to removing it entirely in due course, if I remember correctly.

Ideally you should force a higher version of SMB in Samba such as SMB2 or SMB3 
(as long as all your Linuxes have an up to date Samba).

Alternatively you can force install SMB1 in your Windows 10 boxes but this is 
definitely not recommended[2].

To re-enable SMB1 in Windows 10, use the 'Turn Windows features on or off' tool 
to re-enable it. You can separately enable or disable SMB1 client and server 
modes in W10. You can also do it at the command line via PowerShell if you wish 
(Google for instructions).




Footnotes:-
1: 'SMBv1 is not installed by default in Windows 10 version 1709, Windows 
Server version 1709 and later versions' 


2: 'Stop using SMB1' 

Re: Is Scientfic Linux Still Active as a Distribution?

[Mark Rousell]

On 22/02/2020 23:41, Keith Lofstrom wrote:

As a community of scientific, like-minded Linux users,
let's begin to prepare a rudimentary plan B, and hope
that we never need to implement it.


Well, the CentOS mail list is at 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailman_listinfo_centos=DwIF-g=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=WF8T40FT0U5V7kj7iMquqnj_1MT5nTKBVGHEoEszz5k=AGMtN89abK1cjNUIXDYTnF-KxAl0uRLLX1psW4vbkJc=
 

I suspect that general purpose discussion of Linux customisation has moved away 
from mail lists to web forums.

Re: Is Scientfic Linux Still Active as a Distribution?

[Mark Rousell]

On 22/02/2020 02:15, Yasha Karant wrote:
Two comments.

I am not pursuing the IBM FUD (Fear, Uncertainty, Doubt)
[...]

For the avoidance of doubt, I do not think you are pursuing FUD about IBM. I 
was not the person who accused you of that. Indeed, I think you are being 
sensibly cautious.

I just said that it seems to me that IBM does have a profit motive to keep 
CentOS (or some other free access to Red Hat or a functional equivalent) 
available for the foreseeable future.

I understand the current for-profit business arguments that IBM will continue 
to make CentOS viable and stable.  I also do not trust these for the long term 
unless there are some strong fiscal reasons to do so for the long term (e.g., a 
change in taxation policy and enforcement).

Sure, things might change but it seems to me that longer term changes are not 
easily predictable no matter what. I can only say that it seems to me that, for 
the foreseeable future, IBM and Red Hat have no good reason as far as I can see 
to shut down CentOS. In the current world, maximising profits from Red Hat is 
overall facilitated by there being what amounts to a free version of it easily 
available.

Second, the issue of support.  "My" university has changed dramatically under 
the current campus President.  Even under the previous campus administrations, 
the only supported entities were those for administrative computing controlled 
by the administration and that has, and had, no academic freedom.  Worthless 
for any research that interested me.  Most of these functions have been 
outsourced at this time.  The administrators in these areas have no background 
in science or engineering, but rather "management".  I am not deprecating 
anyone, merely putting things into perspective.  There is no internal support 
at my campus for academic freedom curiosity-directed disciplinary research, 
with some support for some persons to secure external funding.  My funding to 
do any of this was external, not internal.

It's a shame that your university computing environment has become so 
commoditised (although it is increasingly the way of things for most 
institutional computing services). It sounds like it's being run purely as a 
business, not as an education/research establishment per se.

Re: EL 8

[Mark Rousell]

On 03/02/2020 21:39, Stephan Wiesand wrote:

On 3. Feb 2020, at 22:23, ONeal, Miles 
<0be99a30c213-dmarc-requ...@listserv.fnal.gov>
 wrote:

 And there's no real reason to get the source from anywhere but RHEL, since 
it's freely available.



Care to share a pointer to the freely available SRPM for one of today's 
updates, like gnome-settings-daemon-3.28.1-3.el7_6.src.rpm?
.


I can't speak for the specific update you mention but in order to get Red Hat 
source all you need is legitimate access to it. One can of course buy a Red Hat 
licence (presumably Oracle can afford this) but access to the source code is 
also freely available. Just sign up for a Red Hat dev licence and, as per GPL 
requirements, you get access to the source RPMs (in a 9.8GB ISO).

The dev licence limits you to running Red Hat for development and test purposes 
as I recall but, as I understand it (I am not a lawyer), none of that prevents 
you from exercising your GPL rights with the source code.

Naturally, certain parts of all that code and associated files contain Red 
Hat's trademarked intellectual property and branding which is not covered by 
GPL, so if one wishes to redistribute the code then one has the easy little job 
of removing all the IP/branding first. ;-)

Re: Is Scientfic Linux Still Active as a Distribution?

[Mark Rousell]

Andrew Z wrote on 2/21/20 1:57 PM:
> It is odd that you have no budget to support critical systems for your
> department,  Yasha.
>
> What if you power servers down and see how "critical " they indeed are? And if
> they are not - then get fedora and be done with it.

I don't think Yasha said that he has no budget, did he, only that he in effect 
has a limited budget. Why is it limited? Could it be because it was possible to 
do what was needed within that limited budget?

Re: Is Scientfic Linux Still Active as a Distribution?

[Mark Rousell]

On 21/02/2020 19:21, Yasha Karant wrote:
In the simplest terms. I trust IBM to maximize overall return-on-investment 
(e.g., profit), and a "free" CentOS that truly competes with licensed-for-fee 
products does not fit that for-profit model.

Whilst I don't disagree that one should be cautious, it seems to me to be 
strongly in Red Hat's interest (and thus IBM's interest now) to maintain a 
free-to-access distribution that whets people's appetites for the paid version. 
This could change but, for the time being, it does seem to me that the profit 
motive works in users' favour with this particular open source operating system 
and its ecosystem.

Also, while Red Hat remains open source (which looks very unlikely to change) 
then there is nothing to stop another group replicating what CentOS, SL, Oracle 
and others have done. I admit that doing this from scratch today would probably 
be much harder than in the past but it's still technically feasible. Of course, 
to make it realistically sustainable might still require a profit motive and 
business plan of some sort.

Having said all that, I must admit that I can't see why Red Hat (and now IBM) 
really needs CentOS. If they are happy to make CentOS available for free why 
not just make Red Hat available for free but without the support?

Re: centOS 8

[Mark Rousell]

On 16/10/2019 21:14, Yasha Karant wrote:

Will the SL list continue to exist as a mechanism for raising issues
(and getting suggested solutions) for CentOS post-SL releases?  I have
found no equivalent list for either CentOS or the other possibility,
Ubuntu LTS (not RPM based, not RHEL based, but GNU Debian based).

Unless I am misunderstanding, there's a busy CentOS discussion list here: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailman_listinfo_centos=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=LeCE5FTE9ELEO-DkTyM3OO00T578L7XK6Q_1BGgVvEY=I7F8d8A3Q9Sx8bwIdQKZBsFb53b_dZ3dqZvzEWsSmqw=
 

Re: question regarding the future

[Mark Rousell]

On 03/05/2019 17:51, Olek Proskurowski wrote:
Unless IBM decides to charge "modest" download fee.

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.gnu.org_licenses_gpl-2Dfaq.en.html-23DoesTheGPLAllowDownloadFee=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=Z__OEEHQf3OcXZmcy1LsYtDdPjrt5r3uCreTxxqownw=1GuSaqR3SwwBTXPzoFLxhfhHB3nG2lN9SCtSyrTGMBg=

Well, even then, I don't think it would invalidate the principle that the GPL 
(and other open source licence) source could be redistributed (and modified) 
freely once initially downloaded by someone, anyone, with legitimate access to 
it.

Re: question regarding the future

[Mark Rousell]

On 03/05/2019 08:19, Tom H wrote:

Red hat can limit access to its source RPMs to its paying customers
and prevent free rebuilds

Whilst it is true that Red Hat could legitimately limit access to its source 
code to authorised users of its software, I don't think this could or would 
prevent free rebuilds from occurring.

For example, I have a free of charge dev licence for Red Hat Enterprise Linux 7 
(anyone can sign up to one of these at present). Most of this code is licensed 
under GPL (v2 mostly I think) and, as per that licence, RHEL have to give me 
access to the source code. Indeed, I can easily download two ISOs full of 
source RPMs from Red Hat's website.

Although Red Hat have an extensive end user licence agreement, it is generally 
accepted that no terms in such an EULA can extinguish the software licence 
terms under which copyright holders have chosen to distribute heir software. In 
this case that is the GPL and both Red Hat and myself are bound by it.

One of the terms of the GPL is that licensees (which includes Red Hat, me, and 
any other legitimate Red Hat customer) may modify the work as well as copy and 
redistribute the work or any derivative version of it. Furthermore, GPL 
prevents licensees from imposing any further restrictions of any of the rights 
that GPL grants.

Therefore, in brief, even though Red Hat have their own EULA and even though 
they could legitimately (under GPL) limit distribution of RHEL source code to 
their own customers (both paying and non-paying ones like me), they cannot 
prevent any of those customers from freely re-distributing the source code or 
modifying it. Thus a free re-distribution could still be created, no matter 
what.

The only limitation that Red Hat could feasibly add would relate to their own 
trademarked intellectual property that is not part of the source as such, such 
as trade names, trademark images, etc. I *presume* (but I am not certain and 
have not checked) that I might need to remove these trademarked properties from 
the source RPMs before redistributing the source code. This is, of course, 
exactly what the CentOS project did and still does.

As a matter of interest, can anyone confirm whether I'd need to remove Red 
Hat's trademarked intellectual property from their source RPMs before 
re-distributing them under GPL or could I re-distribute under GPL them 
unchanged?

Re: Clarity on current status of Scientific Linux build

[Mark Rousell]

On 23/06/2014 14:54, Steven Timm wrote:
 I was at the HEPiX meeting at which those slides were presented
 and there was further discussion during the course of the week
 as to what would happen.  RedHat/CentOS was also represented at that
 meeting in the person of Karanbir Singh.  You should not presume
 that the presentations given at that meeting are the final word.
 
 You notice that nobody with a cern.ch or fnal.gov E-mail address
 has responded to this thread up until now.  When they have
 something concrete they will respond with the details.
 
 Steve Timm

(Apologies if you've seen this twice. Posting via Hotmail is less than
ideal).

So, in short, complete clarity is not yet available, if I understand
correctly?

However, based upon the balance of probabilities, it looks likely that
SL7 will not be based directly on RHEL7 but on CentOS. If so, it does
raise the question of why continued with SL at all. It would be very sad
indeed if this is the case.

Re: Clarity on current status of Scientific Linux build

[Mark Rousell]

Thanks to everyone who commented and I apologise for the delay in replying.

So it seems that complete clarity is not yet available. Ok.

A couple more questions in the search for clarity:-

1) Can anyone confirm or deny that Red Hat places contractual
limitations on what a subscriber (who has access to the RHEL7 SRPMs) can
do with the source code so obtained? Yes, I know this has been discussed
but I don't think it has been explicitly confirmed. One must infer that
there are contractual limitations (otherwise why remove public access to
SRPMs) but it would be nice to be absolutely clear.

2) This is a legal question but it is relevant: If Red Hat uses a
contract with its customers to prevent a customer who is a recipient of
the GPLd source code (when received via SRPM) from redistributing it or
rebuilding it as they please, wouldn't this mean that Red Hat itself was
in breach of the GPL licence conditions?

Re: Clarity on current status of Scientific Linux build

[Mark Rousell]

On 27/06/2014 20:43, Lamar Owen wrote:
 On 06/27/2014 03:28 PM, Mark Rousell wrote:
 1) Can anyone confirm or deny that Red Hat places contractual
 limitations on what a subscriber (who has access to the RHEL7 SRPMs) can
 do with the source code so obtained?
 
 Please read http://lwn.net/Articles/432012/ and
 http://ebb.org/bkuhn/blog/2011/03/05/open-core-slur.html (especially the
 12th paragraph).

Yup, I've read those and whilst they address the issue they only answer
it by inference and reference, not quite as explicitly as I'd ideally like.

I think this the paragraph in the latter article you meant (it certainly
covers the key point you responded to):

I do have strong, negative opinions about the RHEL business
model; I have long called it the if you like copyleft, your
money is no good here business model. It's a GPL-compliant
business model merely because the GPL is silent on whether or
not you must keep someone as your customer. Red Hat tells RHEL
customers that if they chose to engage in their rights under
GPL, then their support contract will be canceled.

Indeed, I am aware of this. I was in fact going to write Can anyone
confirm or deny that Red Hat places contractual limitations (where the
contract is freely entered into) in my earlier message but it was too
much of a mental mouthful.

Whilst Red Hat can certainly create whatever contractual terms it wants
and customers can freely agree to them, this does not in general
automatically or necessarily mean that Red Hat itself is not in breach
of a licence (GPL in this case) by creating certain limiting contractual
terms with its customers. It does surprise that limiting a customer's
rights with respect to GPL (even if it just while the customer freely
chooses to remain a customer of Red Hat) is not a GPL-violating action
for Red Hat itself. Clearly, however, Red Hat's lawyers (and the FSF it
seems) think such a limitation is not a violation of GPL.

For what it's worth, such limiting contractual terms (even if freely
entered into) do seem on the face of it to be a violation of clause 6 of
GPL2 and possibly clause 12 of GPL3 (amongst others possibly). Anyway,
as above, it seems that FSF disagrees with me so I need to read GPL2 and
3 much more thoroughly!

 For legal advice, you should consult with your lawyer.  We non-lawyer
 types aren't qualified to give legal advice; the lawyers on this list
 won't likely give you legal advice in public, either.

Well, that's the usual advice but of course this does seem to be a
relevant issue.

Anyway, I accept that the question over Red Hat's legal right to
effectively restrict GPL can't go much further on this list.

Re: Clarity on current status of Scientific Linux build

[Mark Rousell]

On 27/06/2014 22:16, Mark Rousell wrote:
 On 27/06/2014 20:43, John Lauro wrote:
 One reason to remove public sources is to keep the load off of their
 servers.
 
 Yes, that's one reasons. There are other reasons too, of course. My
 might will infer that other reasons are the overridingly significant
 ones in this case. ;-)

Oops, a typo. I meant to write:

Yes, that's one reason. There are other reasons too, of course. One
might well infer that the other reasons are the overridingly significant
ones in this case. ;-)

Ask Red Hat for clarification about differentiating between RH source and CentOS on git.centos.org?

[Mark Rousell]

Apologies for starting a new thread but this seems to warrant one.

On another mail list where the issue of Scientific Linux versus RHEL7
has been mentioned in passing, an employee of Red Hat has offered to
seek clarification about the RHEL/CentOS source code
identification/verification/tracing issue with git.centos.org.

Here is the passage (written by me) that the Red Hat employee intends to
pass on for clarification if I take up his offer:

The problem with the source available via Git is that, whilst
no one doubts it is all there, it is apparently not currently
clear to anyone outside of Red Hat or CentOS what is the
unadulterated Red Hat source and what is source altered by
CentOS for its own build. It is not for nothing that the
source is now only being made publicly available via
git.centos.org and not directly from Red Hat. Third parties
such as Scientific Linux (and of course Oracle...) need to know
what is the unadulterated Red Hat source to be able to build
properly.

I understand that discussions are continuing to which I am not
privy but if you can shed light on how to unmistakeably extract
guaranteed Red Hat (rather than possibly altered-for-CentOS-
distribution) source code from git.centos.org then I
am sure the Scientific Linux community would love to hear about
it.

He says:
I am very happy to seek clarification.

May I quote or paraphrase the above?

Should I ask him to go ahead and seek clarification or should I tell him
to drop it? Is it worth taking up his offer, given the email from
CentOS-Devel written by Karanbir Singh and posted here by Yasha Karant
at 13:49:12 -0700, which seems to me to possibly address these source
code identification issues if I understand it correctly?

Would anyone like to craft a better phrased question than my own one
above (which is just a quote from an earlier message in the thread with
him)?

Re: Clarity on current status of Scientific Linux build

[Mark Rousell]

On 27/06/2014 23:00, Lamar Owen wrote:
 On 06/27/2014 05:07 PM, Mark Rousell wrote:
 Clearly, however, Red Hat's lawyers (and the FSF it
 seems) think such a limitation is not a violation of GPL.

 For what it's worth, such limiting contractual terms (even if freely
 entered into) do seem on the face of it to be a violation of clause 6 of
 GPL2 and possibly clause 12 of GPL3 (amongst others possibly). Anyway,
 as above, it seems that FSF disagrees with me so I need to read GPL2 and
 3 much more thoroughly!

 For what it's worth, Bradley Kuhn has spent a great deal of time and
 effort in dealing with GPL violations.  The fact that even he concedes
 it is likely not a GPL violation speaks volumes

As I observed in another message (posted at 22:26:52 +0100), I am not
aware of any comment by Bradley Kuhn (or anyone similarly knowledgeable)
about the specific issue at hand here and now.

As I said in that message, all of the comments by Bradley Kuhn and
others date from 2011 and relate to RH's kernel distribution changes at
that time; they do *not* relate directly to the new issue about
limitations surrounding SRPMs in general which limit things
significantly further as far as I can see. Whilst there are certainly
significant similarities between the kernel issue from 2011 and this new
issue, they are not the same.

 the fact that he, the
 FSF, etc, have not initiated a lawsuit against Red Hat for a GPL
 violation speaks even louder.

As above, this seems to be a substantively new issue. If it wasn't a
substantive new issue then these threads on the subject would not exist
at all and SL7 would be based on RHEL7 SRPMs.

I can fully understand why the changes in 2011 did not breach GPL:
Everything that was required was still available. However, limiting all
SRPM source code usability, the issue at hand now, is a different kettle
of fish. It is no longer an issue about preferred form or prominent
notice of changes or support for potentially arbitrary code changes that
so concerned people in 2011. This is different and substantively
extended although, as I mentioned above, it does share some similarities
to the 2011 issue.

I also expect to be shown at some stage how RH's new, extended,
behaviour on this matter still complies with GPL but I can nevertheless
say that my own reading of GPL2 (as in my other message I referred to)
indicates to me that limiting what a customer can do with source code
(regardless of the fact that they freely entered into a contract with
RH) puts RH and/or the customer in breach of GPL2. Of course, I should
note that I can only infer what RH's new, extended, behaviour is
because I haven't seen a contract that really describes any
limitation/restrictions/limits on what a RH customer can do in this context.

 I was taught as a child that actions
 speak louder than words; and inaction speaks louder yet, especially as
 he finds Red Hat's practice to be distasteful.

I agree but bear in mind that
a) The practice about which he commented in 2011 has been significantly
extended in such a way that it seems to me to bring new licence clauses
into play, and
b) lack of action does not in and of itself necessarily imply lack of
intent or lack of breach (as things stand now).

As I mentioned above and despite all my comment, I still won't be
surprised if nothing happens even now.

 If there were a case to
 be made I would think Mr. Kuhn or another similarly-opinioned individual
 would have made it by now; this issue has been around for a decade, it's
 not a new thing.

And yet it most certainly *has* taken on a new form. That changes
things. The threads about it on this mail list would not exist if there
had not been such a substantive, real world, change.

 I do find
 myself wishing that the people debating whether the exact right number
 of angels are dancing on the head of this particular GPL pin would
 instead spend some time helping to end the flagrant, constant, and
 obvious GPL violations with which I spent much time dealing time each
 week.

Aren't discussion of relevant issues such as this pretty much what he
seeks? :-) Contractually limiting what a customer does with SRPMs (note,
an extended issue compared to kernel source code limitations and
incomplete documentation back in 2011) seems like an obvious breach of
clause 6 of GPL2 to me.

Re: Clarity on current status of Scientific Linux build

[Mark Rousell]

On 27/06/2014 23:45, Lamar Owen wrote:
 On 06/27/2014 06:29 PM, Mark Rousell wrote:
 And yet it most certainly *has* taken on a new form. That changes
 things. The threads about it on this mail list would not exist if
 there had not been such a substantive, real world, change.
 On February 29, 2012, CentOS and SL both stopped support for version 4
 of their respective distributions.  However, Red Hat still has Extended
 Lifecycle Support for RHEL4 until February 28, 2015.  Where are those
 SRPMS?  Subscribers to the Extended Support can get them, but they're
 not publicly available, and never have been to the best of my
 knowledge.  RHEL3 was supported by the EUS mechanism until January of
 2014, yet CentOS 3 went out of support October 31, 2010 (can't rebuild
 if there's no public source from which to rebuild). That's a period of
 over three years where subscribers could get packages and SRPMS that
 were not available to the public.
 
 Again, this is not a new issue in general; it's just now impacting more
 people than before who are surprised by something that's been around for
 a long time.

Yup, I do take your point. Nevertheless, I still cannot help but observe
that:

a) It's a new issue in the specific context in which it matters here (as
I said, if it wasn't a new issue in this context then there would not be
the problem that is at hand),

b) the comments by Bradley Kuhn and others back in 2011 do not fully
apply to the situation at hand now (even though it is a longstanding
issue in general), and

c) as I said in my message posted at 23:41:46 +0100, just because it is
a longstanding issue that is increasingly common practice does not mean
that it is acceptable or that it will necessarily stand if well
challenged. It is all too easy for people to become inured to issues
like these and think that they are an inevitability or fully legal just
because there has been no real challenge to them, just because they are
there. Historical lack of action does not necessarily legitimise,
justify or explain current or future lack of action. Opinions can and do
change.

Re: Clarity on current status of Scientific Linux build

[Mark Rousell]

On 27/06/2014 23:41, Mark Rousell wrote:
 And then, finally, the
 banking industry lost a court case and the government regular got round
 to doing something about it. What had been totally accepted, barely
 questioned, common practice was outlawed and improperly taken fees had
 to be paid back.

s/government regular/government regulator/

Clarity on current status of Scientific Linux build

[Mark Rousell]

I've been following the discussions on this list about the changes in RHEL's 
source availability and I'd like to confirm my understanding of the current 
situation.

Someone on another mail list made this comment:

RedHat have said that they'll not be releasing source RPMs any more, so
the response by the Scientific Linux people has more or less been
Either use CentOS or our very own re-packaged CentOS thingie.

This is incorrect (in terms of both statements that it makes), isn't it.


Here is my current understanding. Please feel free to correct or confirm:-

1) RH now makes SRPMs available only to customers (but SRPMs are nevertheless 
still available on those terms).

2) The RHEL source is publicly also available on git.centos.org.

3) But it is not *absolutely* crystal clear what on git.centos.org is pure 
unadulterated RHEL source and what is CentOS source.

4) The SL project is writing tools to automatically extract RHEL source from 
git.centos.org.

5) SL7 will therefore be based on RHEL7 and definitely not on CentOS.

6) Anything I've forgotten?


Thanks to anyone who can help with this.