Re: leapp-upgrade from SL79 to AL89 ?

[Patrick J. LoPresti]

[EXTERNAL] – This message is from an external sender

On Thu, May 16, 2024 at 4:08 AM Nico Kadel-Garcia 
mailto:nka...@gmail.com>> wrote:
>
> I did this sort of stunt years ago with previous Red HGat and RHEL,
> and even had some tools to switch Scientific Linux releases to the
> matching CentOS releases and back. I do *not* recommend it! Resolving
> the library differences for core libraries, and getting the file
> systems built with the features of newer "mkfs" tools is not a trivial
> problem. The time and cleverness expended is usually better spent on
> your backup process.

I will echo this advice.

Based on 20+ years of painful experience, I recommend you forget about upgrades 
and instead turn your effort towards getting your infrastructure to where you 
would be comfortable reinstalling any O/S on any server at any time.

Unfortunately, I suspect this is the sort of thing that is usually learned only 
through painful experience.

 - Pat

Re: XFS vs Ext4

[Patrick J. LoPresti]

On Tue, Dec 5, 2023 at 1:51 AM Paul Robert Marino 
wrote:
> With NFS always go with EXT4 because NFS isn't compatible with 64bit
inodes, so you need to disable a flag with XFS for "inode64" which means on
files over 2GB XFS' will need to create multiple inodes instead of 1 at the
beginning of the file which hurts it's performance.

Can you provide details on this, or a reference?

Even NFSv2 had fixed-size 32-byte/256-bit file handles. NFSv3 (1995) made
them variable size and up to 64 bytes / 512 bits. Linux NFS may have taken
a while to catch up, but I am pretty sure anything from the past decade
will be fine with 64 bit inodes.

We have been using XFS over NFS for at least 10 years now, with partitions
in the hundreds of terabytes and individual files in the hundreds of
gigabytes. No problem. I have no idea why anyone would consider ext4 for
any serious application.

 - Pat

Re: Fermilab/CERN recommendation for Linux distribution

[Patrick J. LoPresti]

On Wed, Dec 7, 2022 at 1:45 PM Konstantin Olchanski  wrote:
> - NFS-Root support. Last I tried, RHEL-8 would not NFS-boot without major 
> effort.

Diskless clients (NFS root) are working fine for me with AlmaLinux
9.1. The main prerequisite is installing the "readonly-root" package.

> - NIS support. ("LDAP need not apply"), scheduled for removal in RHEL, still 
> works just fine in Ubuntu/Debian.

Yes, Red Hat ripped it out in RHEL 9. Very annoying. You can restore
it by installing the nss_nis, ypbind, and yp-utils packages from
Fedora Core 34 or 35 or 36 or 37. The binary RPMs work or you can
rebuild. You will probably also want to rebuild the autofs RPM with
the libnsl2-devel package installed so it will contain
/usr/lib64/autofs/lookup_nis.so.

That does it if you manage your nsswitch.conf by hand. If you want to
go whole hog, you will want to restore the "nis" profile for
authselect. I just copied it from the authselect sources into
/etc/authselect/custom/nis and now "authselect select custom/nis"
works.

Alma has been serving us well so far. Nice to see our choice being
validated by CERN/Fermilab.

 - Pat

Re: [SCIENTIFIC-LINUX-USERS] devtoolset-12?

[Patrick J. LoPresti]

Thanks, Pat.

So these are your sources? Or they came from somewhere else?

Trying to decide whether to build it for myself or if I can grab it
from a repository.

 - Pat

On Mon, Oct 3, 2022 at 5:32 PM Patrick Riehecky  wrote:
>
> Hello,
>
> The devtoolset-12 SRPMs were added to the SL7 source repo because they
> were needed to build the new firefox and thunderbird packages.
>
> I try to have the sources for our build chain up where folks can grab
> them if they feel so inclined.
>
> Hope all is well
>
> (also) Pat
>
> On Mon, 2022-10-03 at 17:09 -0700, Patrick J. LoPresti wrote:
> > I usually get the "Developer Toolset" from the CentOS SCLO repo:
> >
> > <
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__mirror.centos.org_
> > centos-2D7_7_sclo_x86-
> > 5F64_=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-
> > pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=ZJXIiTv5j5Ii4VbKCAWc3apPcMn
> > 8xC3xxrDAjLmQxDM_oqm8D6SZhkUvGs51HzLQ=S0w8ejHJsXnQBefhuY4f0nNsah-
> > C7i1nE84p6Zo-twI=  >
> >
> > Recently, devtoolset-12 SRPMs have appeared under
> > <
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinu
> > x.org_linux_scientific_7x_SRPMS_SL_=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA
> > =gd8BzeSQcySVxr0gDWSEbN-P-
> > pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=ZJXIiTv5j5Ii4VbKCAWc3apPcMn
> > 8xC3xxrDAjLmQxDM_oqm8D6SZhkUvGs51HzLQ=OtVPzeR8BE2QVyhuoE_oMTKV0ggS7
> > dhp4t1Nc7OXfQQ=  >.
> >
> > Two questions:
> >
> > 1) What is the relationship (if any) between these Developer Toolset
> > packages and those from the CentOS repository?
> >
> > 2) Are the RPMs deliberately omitted, or did I miss them?
> >
> > Thanks!
> >
> >  - Pat
>

devtoolset-12?

[Patrick J. LoPresti]

I usually get the "Developer Toolset" from the CentOS SCLO repo:



Recently, devtoolset-12 SRPMs have appeared under
.

Two questions:

1) What is the relationship (if any) between these Developer Toolset
packages and those from the CentOS repository?

2) Are the RPMs deliberately omitted, or did I miss them?

Thanks!

 - Pat

Re: Fermilab/CERN recommendation for Linux distribution

[Patrick J. LoPresti]

On Mon, Oct 25, 2021 at 5:45 PM Nico Kadel-Garcia  wrote:
>
> It's getting harder.

Singularity containers for CentOS 8 (and latest Ubuntu etc.) work fine on
SL7, for now. Of course this is not a long-term solution, since "kernel too
old" will surely crop up eventually.

This is an awful decision by CERN/Fermilab. Red Hat has a financial
incentive to keep CentOS Stream unsuitable for production use. And even if
they are not passively (or actively) crippling it, what third-party
software is going to offer support for "CentOS Stream"? The whole thing is
almost laughable.

The right decision is to restart Scientific Linux. Obviously that is not
going to happen, which leaves organizations like mine in a bind. I am not
sure what we will do, but CentOS Stream is definitely not it.

 - Pat

Re: Pondering a switch to Debian

[Patrick J. LoPresti]

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.

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

 - Pat

Re: Rhel 8

[Patrick J. LoPresti]

On Sat, Jan 23, 2021 at 5:28 AM Mark Rousell 
wrote:
>
>
> 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. ;-)

This is missing the point. There is precisely nothing any system with
systemd does that they could not do before systemd existed. Maybe they boot
a few seconds faster, every year or two when they do reboot? Ha ha.

systemd is the purest example ever of "change for the sake of change". It
solves literally zero problems while introducing several. All cost + no
benefit = idiotic.

Re: Rhel 8

[Patrick J. LoPresti]

On Fri, Jan 22, 2021 at 4:01 PM Yasha Karant  wrote:
>
> Was Torvalds behind SystemD, etc.?  Just curious.

Are you joking?

systemd is the creation of Red Hat employee (and professional idiot)
Lennart Poettering. Worst thing that ever happened to Linux.

Re: CentOS 8 EOL; CentOS Stream?

[Patrick J. LoPresti]

It has been almost exactly seven years since Red Hat bought CentOS (
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_scientific-2Dlinux-2Dusers-40fnal.gov_msg01499.html=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=k9C3FsK8ruGItyjO2valZJ7PiSyD6dfXo0o_uJDy9vc=hWYvmZ1dB98Fa5LjmQDAIUbm_0aIxLNdps_vUzte8CI=
 ).
I admit this move took longer than I expected. I suppose I was so early I
was functionally wrong.

The cost of switching to Ubuntu for us is large; we have big investments in
RPM and related technologies. I guess we have to start exploring it anyway.

Very curious how CERN and Fermilab will respond to this.

 - Pat

Re: SL 6

[Patrick J. LoPresti]

On Wed, Oct 14, 2020 at 11:21 AM Larry Linder <
0dea520dd180-dmarc-requ...@listserv.fnal.gov> wrote:
>
> I would be interested in a contribution to help support this effort.
>
> We have a number of SL 6.9 boxes, we would stay there for a while as all
> of our cad tools work.  There are some things it doesn't have but we
> have never noticed them because they are not useful in the day to
> day running of a Business.

You want to discover "containers". I recommend Singularity, but really any
implementation can scratch this particular itch.

 - Pat

Re: Calibre current

[Patrick J. LoPresti]

On Thu, Jan 30, 2020 at 12:02 PM Andrew C Aitchison
 wrote:
>
> On Thu, 30 Jan 2020, Yasha Karant wrote:
>
>
> > Calibre needs RuntimeError: Failed to load icu with error:
> > /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by
> > /opt/calibre/lib/libicui18n.so.64)
>
> I'm running SL6 and Ubuntu19... so don't know the exact details for RHEL7
> but the softwarecollections repo should have a devtoolset-8-gcc package
> (or more likely a set of packages) with a with suitable compiler and
> runtime.

The devtoolset-X packages will not help with this problem, unless
maybe you are recompiling Calibre itself. The main purpose of the
devtoolsets is to let you use a newer compiler to create executables
that can run on an *unmodified* RHEL7 system. Red Hat has hacked the
devtoolset GCC to use rely only on the original libstdc++; i.e. the
original CXXABI.

This error just means the executable you have requires a newer
libstdc++. The certain way to get one is to compile a newer GCC from
source on RHEL7. One of the artifacts of this build will be the newer
libstdc++.so that you need. Make sure the newer libstdc++.so.6 resides
in your LD_LIBRARY_PATH, and your Calibre executable might run. At the
very least, it will fail differently.

As a short cut, you could try copying libstdc++.so.6 from a RHEL8
system and put it somewhere in your LD_LIBRARY_PATH. But that might
create new missing dependencies of its own, or be incompatible with
the RHEL7 dynamic linker, etc. I have not tried it because I get
around this sort of issue by compiling GCC.

 - Pat

Re: Q: Centos vs SL

[Patrick J. LoPresti]

 (five years on...)

On Thu, Nov 27, 2014 at 11:25 AM Jos Vos  wrote:
>
> On Thu, Nov 27, 2014 at 12:22:23PM -0600, davef...@protev.com wrote:
>
> > Now that Redhat has bought Centos...
>
> Red Hat did not buy CentOS.

I guess he should have said "acquired".

https://urldefense.proofpoint.com/v2/url?u=https-3A__investors.redhat.com_ir-2Dresources_investor-2Dfaqs_what-2Dacquisitions-2Dhas-2Dred-2Dhat-2Dmade=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=BV0CfvsDb_uC3rnZYwldekc4Iywghe9P6dycLXOnQMc=r6HX73U2aHBisE3xexunUm2_-aTc6aBuKJ_m6KivVF8=
 

Now that Red Hat owns CentOS and IBM owns Red Hat, I wonder when CentOS 8
will be released.

Does Scientific Linux (principals and/or community) have a contingency plan
if the answer turns out to be "never"?

 - Pat

On Sat, Nov 29, 2014 at 5:29 AM Jos Vos  wrote:

> On Fri, Nov 28, 2014 at 04:37:37PM -0800, Konstantin Olchanski wrote:
>
> > > On Thu, Nov 27, 2014 at 12:22:23PM -0600, davef...@protev.com wrote:
> >
> > Please reread the news coverage and the press releases.
> >
> > My reading between the lines is that CentOS people were made
> > an offer they could not refuse.
> >
> > BTW, today, whois shows centos.org as registered by Red Hat. (Used to be
> > registered by one of the CentOS main developers).
>
> Not specifically meant as an answer to you, but as a comment in general:
>
> Some open source people (a community I consider myself part of, but
> not in this sense) tend to act like communists and look at companies
> acting in the open source world in a suspicious way (this word has
> already been used in this thread), some maybe even think capitalism
> is bad in general.
>
> Well, some companies indeed are evil and try to hijack and/or abuse
> open source software and its community.
>
> But in general, remember that today's major open source projects
> couldn't live without the support from (commercial) companies, where
> Red Hat is even one of the main players.  And until now RH has proven
> to play the game pretty well.
>
> Without Red Hat there was not Fedora, no RHEL, no CentOS (also not
> in the previous incarnation) and no SL.
>
> It's understandable that people around the CentOS community look at
> the RH/CentOS case in a critical way: I also did that myself.  But
> we have to live with the situation and it's not that bad now.
>
> Just my $0.02...
>
> --
> --Jos Vos 
> --X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
> --Amsterdam, The Netherlands| Fax: +31 20 6948204
>

Re: clang and Scientific Linux

[Patrick J. LoPresti]

On Mon, Aug 10, 2015 at 3:34 PM, Keith Smith fernlea...@gmail.com wrote:

 I have looked for solutions on the web and many are partial or requiring
 complete source build of clang.

Clang is actually pretty easy to build from source. And it comes with
extensive unit tests, so if make check succeeds, you almost
certainly have a solid build.

 - Pat

Re: SL 7.2

[Patrick J. LoPresti]

On Tue, Jul 14, 2015 at 5:11 PM, Nico Kadel-Garcia nka...@gmail.com wrote:

 I'm getting more and more inclined to give SL 7 a complete miss, and see if 
 SL 8 will be contemporary enough to ease my backporting work.

Or switch to a distribution with an explicit policy of we will never
adopt systemd. Do you know of any?

This is perhaps not a sufficient condition to have maintainers without
their heads up their backsides, but it is surely a necessary one.

 - Pat

Re: nfsv4 and rpcidmapd

[Patrick J. LoPresti]

Possibly related:

https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/526302

Assuming you are using FQDNs and the host's domain matches the Kerberos
domain, it sounds like you can simply comment out the Domain =  line in
idmapd.conf.

(I vaguely recall localdomain having special meaning in this context and
therefore being a bad idea. I always set it to something else. But I am
unable to find a reference, so maybe my memory is playing tricks on me.)

 - Pat


On Tue, Jun 30, 2015 at 1:47 PM, Orion Poplawski or...@cora.nwra.com
wrote:

 On 06/30/2015 02:39 PM, Eve V. E. Kovacs wrote:
  Yes, kereberos is used for password authentication; account information
 is
  supplied by our ldap server. Passwords are not served via ldap.
  Eve
 

 Perhaps something in that configuration is forcing the full domain to get
 sent.  Not sure.  idmap issues always give me headaches.

  On Tue, 30 Jun 2015, Orion Poplawski wrote:
 
  Date: Tue, 30 Jun 2015 15:30:41 -0500
  From: Orion Poplawski or...@cora.nwra.com
  To: Eve V. E. Kovacs kov...@anl.gov, scientific-linux-users@fnal.gov
  Subject: Re: nfsv4 and rpcidmapd
 
  On 06/30/2015 01:46 PM, Eve V. E. Kovacs wrote:
  We have an SL6 nfsv4 file server and a number of SL6 clients.
  We were careful to configure idmapd.conf on both the clients and the
 server to
  have the same domain name as follows:
 
  # The following should be set to the local NFSv4 domain name
  # The default is the host's DNS domain name.
  #Domain = local.domain.edu
  Domain = localdomain
 
  All of this worked until recently.
 
  Now, when I try to change the ownership of my file 'test' on one of the
  clients, I get an error:
  chown: changing ownership of test : Invalid argument
 
  On the server, I see errors in the log file:
   rpc.idmapd[6092]: nss_getpwnam: name 'kov...@hep.anl.gov' does not
 map into
  domain 'localdomain'
 
  This problem has various solutions posted on the internet. Some
 solutions
  claim that all that is required is to have the same domain name on the
 client
  and server. We already have this, but still have a problem. Another
 solution
  suggests changing the local NFSv4 domain name to match the DNS domain
 name
  (which looks promising, given the error message above).
 
  Has anyone else had this problem and/or know the fix?
 
  I would definitely recommend using the real domain name, but it does
 seem like
  the client is sending the hep.anl.gov domain name rather than
 localdomain,
  and I'm not sure why that would be if it is configured as you described.
  Either way *should* work.  Is kerberos involved at all?
 
 
  --
  Orion Poplawski
  Technical Manager 303-415-9701 x222
  NWRA, Boulder/CoRA Office FAX: 303-415-9702
  3380 Mitchell Lane   or...@nwra.com
  Boulder, CO 80301   http://www.nwra.com
 
 
  ***
  Eve Kovacs
  Argonne National Laboratory,
  Room L-177, Bldg. 360, HEP
  9700 S. Cass Ave.
  Argonne, IL 60439 USA
  Phone: (630)-252-6208
  Fax:   (630)-252-5047
  email: kov...@anl.gov
  ***


 --
 Orion Poplawski
 Technical Manager 303-415-9701 x222
 NWRA, Boulder/CoRA Office FAX: 303-415-9702
 3380 Mitchell Lane   or...@nwra.com
 Boulder, CO 80301   http://www.nwra.com

Re: RSTe ???

[Patrick J. LoPresti]

On Wed, May 13, 2015 at 8:56 PM, ToddAndMargo toddandma...@zoho.com wrote:

 Hi Pat,

 Thank you!

 Would it be faster, slower, or about the same as a dedicated
 LSI (or similar) controller when used in a high end workstation?

It is the same as any other software RAID. If you do a search for
software RAID vs hardware RAID, you will find as many opinions as
you could possibly want.

My own view: For a workstation with a few drives in a RAID0, RAID1, or
RAID10 configuration, I highly doubt you could notice any difference.
Where hardware RAID shines is on large disk arrays at more
sophisticated RAID levels.

 - Pat

Re: QA: Centos vs SL

[Patrick J. LoPresti]

On Thu, Nov 27, 2014 at 11:25 AM, Jos Vos j...@xos.nl wrote:

 Red Hat did not buy CentOS.

They employ the principals and own the trademark.

Are you saying they got them for free?

Current SL 6.5 security repo breaks X11 for Kickstart w/ updates

[Patrick J. LoPresti]

Executive summary: If you include repo .../updates/security in your
6.5 Kickstart config, add xorg-x11-drivers to your %packages
section.

...

For 6.6, Red Hat scattered the X server's driver modules into a ton of
xorg-x11-drv-* packages and added a master xorg-x11-drivers that
depends on all of them. Also, they added xorg-x11-drivers to the
@x11 group, causing all drivers to get installed whenever X is, in
general. This change appears idiotically gratuitous, but I am sure
they had a good reason.

Anyway, SL6.5 now includes the 6.6 X11 packages as security updates,
but 6.5 does not include xorg-x11-drivers in the definition of the
@x11 group. (Aside: Can updates override group definitions?) So, if
you include the updates/security repository in your Kickstart
configuration, X11 will fail to start because it will be unable to
find whatever module it needs for your video hardware.

A work-around is to add xorg-X11-drivers (or the RPMs for the
specific driver(s)  you require) to the %packages section. And then
leave a comment reminding yourself to remove it when you migrate to
6.6.

At least, this was my experience...

 - Pat

Re: kickstart packages question

[Patrick J. LoPresti]

On Wed, Oct 22, 2014 at 8:00 AM, Stephen Berg (Contractor)
stephen.berg@nrlssc.navy.mil wrote:

 If I put in a group to be installed that includes a package I don't want to
 install what's the proper way to set that up?

Not sure about proper, but I have found that -Package in the
%packages section rarely does what I want. So I just remove unwanted
stuff in the %post section like so:

rpm -e Package

or

yum --disablerepo=\* --assumeyes remove Package

The former will fail if Package is required by something else
installed on the system. The latter will remove Package and everything
that requires it, recursively.

 - Pat

Re: glibc-2.15-60.el6.x86_64.rpm

[Patrick J. LoPresti]

On Tue, Jul 8, 2014 at 11:58 PM, Yasha Karant ykar...@csusb.edu wrote:
 Assuming that the kernel has
 not been built against glibc 2.15, is there any relatively simple way to
 allow the user application to use the required glibc but to keep the kernel
 and related systems binary programs on the glibc against which the kernel
 was built?

Your question is confused. The kernel is not built against glibc;
quite the opposite, in fact. By design, the kernel is completely
independent of glibc.

That said, if your application needs a newer glibc, you can either
take Pat's suggestion and try the devtoolset, or you can simply:

 - copy a newer libc.so.6 into /path/to/lib/
 - set the LD_LIBRARY_PATH environment variable to /path/to/lib
 - run the application

In my experience, there is a decent chance this will just work,
depending on just how ancient your system is... You may find this
exposes other dependencies (libm, libpthread, etc). If so, you can add
them to /path/to/lib/. If and when that gets too annoying, you can
figure out how to use the devtoolset.

 - Pat

Re: Clarity on current status of Scientific Linux build

[Patrick J. LoPresti]

On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen lo...@pari.edu wrote:


 ??? That is not at all what I got from his reply.  What I got was that CERN
 will still be committing resources, but instead of duplicating effort
 they're joining up with the CentOS effort.

Whatever. The relevant questions are: (1) Will SL's goal continue to
be creating a re-spin of Red Hat Enterprise and *not* CentOS, since
Red Hat's clear goal in acquiring CentOS is to create divergence
between the two; and (2) what mechanism(s) will SL use to achieve that
goal? (Specifically, will SL compare the git sources against actual
SRPMs obtained via subscription?)

 That's part of the
 reason the CentOS team has changed the statement '100% binary compatible' to
 'functionally compatible' since they do mean different things, but the
 latter is more indicative of reality than the former ever has.

The *goal* of CentOS used to be binary compatibility, even if it was
never 100% achieved. Since the acquisition by Red Hat, that is no
longer even the goal, for obvious reasons.

 Red Hat is being as close to a good member of the community as is
 possible within the constraints of a publicly traded corporation,

Disingenuous claptrap. Red Hat is blatantly violating the clear intent
of the license that the authors of the code placed on their work. Why
Red Hat does this is frankly irrelevant.

 No one yet in this thread has provided a public, no
 login required, link to up-to-date sources for SLES 11.

Yes, you keep bringing this up as if it were an argument.

No one has provided a public, no login required link to an up-to-date
photo of my bare rear end, either, which would be precisely as
relevant. We are talking about Red Hat; the actions of SUSE, Oracle,
Microsoft, Tesla, and your cat have zero bearing on the discussion.

Nobody cares about SUSE because nobody cares about SUSE.

 - Pat

Re: Clarity on current status of Scientific Linux build

[Patrick J. LoPresti]

On Tue, Jul 1, 2014 at 5:09 PM, jdow j...@earthlink.net wrote:
 On 2014-07-01 08:16, Patrick J. LoPresti wrote:

 The *goal* of CentOS used to be binary compatibility, even if it was
 never 100% achieved. Since the acquisition by Red Hat, that is no
 longer even the goal, for obvious reasons.

 Pat, this is nominally impossible with modern compilers as I discovered a
 long time ago.

Incorrect.

 If GNU C has this same feature

It does not, and it never has.

See https://wiki.debian.org/ReproducibleBuilds or
https://blog.torproject.org/category/tags/deterministic-builds or
http://www.chromium.org/developers/testing/isolated-testing/deterministic-builds
or just try a search of your own.

 prattling about binary identity and so forth is nonsense.

Before accusing someone of prattling about a topic, may I suggest
learning something about it?

 This RHEL traceability issue is significant as is traceability back
 to creators for non-RHEL code replacements for RHEL proprietary software and
 for any add-on software provided by sources in the path from SL back to
 RHEL.

No, traceability is the irrelevant side issue here. (Granted, binary
reproducibility is also a side issue; just one where you happen to be
wrong.)

Once again, the only relevant question is whether and how Scientific
Linux can be a rebuild of Red Hat Enterprise *and not CentOS*, when
Red Hat's clear motivation and intention is to make those different
things.

 The issue at its base is who do you trust?

Whom. OK OK too pedantic.

I trust the Scientific Linux team. Obviously, I do not trust Red Hat
which includes CentOS. Time will tell how well my trust is placed.

 - Pat

Re: [SL-Users] Re: RedHat CentOS acquisition: stating the obvious

[Patrick J. LoPresti]

On Thu, Jan 16, 2014 at 2:07 PM, Konstantin Olchanski
olcha...@triumf.ca wrote:

 I find it puzzling that official announcements say nothing
 about CentOS trademarks, copyrights, etc being transferred
 to Red Hat - as that web page seems to imply.

It is also mentioned in Red Hat's FAQ:

http://community.redhat.com/centos-faq/#_centos_trademark

I find it somewhat interesting how much digging and reading between
the lines is required to learn what actually happened here, when it
can be fully summarized in four words: Red Hat bought CentOS.

But apparently, signing an employment agreement is joining forces
and selling your trademark is transfering it for stewardship. 2014
indeed.

 - Pat

Re: RedHat CentOS acquisition: stating the obvious

[Patrick J. LoPresti]

On Thu, Jan 16, 2014 at 2:30 AM, Jos Vos j...@xos.nl wrote:
 On Wed, Jan 15, 2014 at 10:49:51AM -0800, Patrick J. LoPresti wrote:

 [...] (Always remember that companies,
 like politicians, do not make statements to communicate information.
 They make statements to achieve a desired result. Their statements may
 happen to communicate information, but if and only if it helps to
 achieve their desired result.)

 It's probably because of my reading problems that I read this as
 companies are bad and they are lying all the time.  I know it's not
 said literally, but that's where reading between the lines comes in.

Is reading between the lines sort of like putting words in someone's mouth?

OK, this is going to be way off topic. But what the heck, I am on a
roll. Oh, and I will definitely be making some value judgments this
time.

Of course I do not think companies lie all the time. They tell the
truth when it is in their interest. They mislead and lie by omission
when it is in their interest. And they outright lie when it is in
their interest, if they can do so without legal or reputational risk.

Quick aside: Companies do care about their reputation, but not for the
same reason you or I do. Well, unless you are a sociopath. Companies
care about their reputation to the extent that loss of reputation
translates to loss of sales. Period.

Small companies are often an exception. They are still capable of
behaving like human beings, acting ethically and even altruistically
for its own sake. Large companies are not so capable, because a CEO's
fiduciary duty is to generate wealth for shareholders by any and all
legal means. Anything less would be a violation of that duty.

Most companies start small and good, but have steadily increasing
difficultly not being evil. Red Hat and Canonical, for example, were
unquestionably positive forces for Linux at one time. But it is highly
questionable whether we still live in that time. I think it is very
unclear whether corporate involvement in open source will ultimately
turn out to be a blessing or a curse. We are just now entering the
later chapters of that story...

To summarize my world view: Small corporations are good. Big
corporations are evil. Small government is good. Big government is
evil. I am still searching for a label that captures this view. I am
pretty sure communist is not it.

 - Pat

Re: RedHat CentOS acquisition: stating the obvious

[Patrick J. LoPresti]

On Wed, Jan 15, 2014 at 2:06 PM, David Sommerseth da...@sommerseths.net wrote:
 On 15/01/14 19:49, Patrick J. LoPresti wrote:


 - Red Hat (the company) considers Oracle (the company) one of their
 top two competitors.

 - Red Hat considers CentOS a competitor.

 - Red Hat believes acquiring CentOS will improve their bottom line.

 These statements are not attacks. They are neither good nor bad.
 They simply are.


 They simply are pure speculations.  You might be right in the first point,
 based on that both parties are commercial companies delivering competing
 products.

 But the rest is pure garbage.

At the risk of repeating myself... I refer you to Red Hat's 10-K filing:

http://www.sec.gov/Archives/edgar/data/1087423/000119312513173724/d484576d10k.htm#tx484576_1

See the Competition section on pages 12-14. Search for Oracle and CentOS.

So when I say, Red Hat considers CentOS a competitor, that is a
demonstrable statement of fact, appearing in an authoritative document
where lies can result in prison sentences. (Unsurprisingly, the
mission statement you keep citing appears nowhere in this document.
When choosing between words and legally binding words, which to
believe? Hm, hard to say...)

When I say Red Hat considers Oracle one of their top two
competitors, I base that on the same section of the 10-K, where
Oracle features far more prominently than any other company, save
perhaps Microsoft.

When I say Red Hat believes acquiring CentOS will improve their
bottom line, that is so blindingly obvious I am not even sure how to
debate it. Companies do not make acquisitions for the fun of it.

 And Red Hat hasn't /aquired/ Cent OS,

*Of course* Red Hat has acquired CentOS. SIngh et. al. are now
full-time RedHat employees (proof left as exercise for the reader).
The relationship could hardly be more clear.

Singh does not mention this detail in his own announcement
(http://www.karan.org/blog/2014/01/07/as-a-community-for-the-community/).
I guess it must have slipped his mind? Or maybe he figured nobody
would consider it relevant? Ha ha ha.

 So please, stop speculating.

None of the above is speculation. What Red Hat will do with their new
acquisition... Well, that is speculation, which I leave to your deep
wisdom.

 - Pat

Re: [SL-Users] Re: RedHat CentOS acquisition: stating the obvious

[Patrick J. LoPresti]

On Wed, Jan 15, 2014 at 3:34 PM, John R. Dennison j...@gerdesas.com wrote:

 Red Hat does not own CentOS, either the product nor the project.  Red
 Hat does not own the various marks.

Wrong.

http://www.centos.org/legal/trademarks/

The CentOS Marks are trademarks of Red Hat, Inc.

 - Pat

Re: RedHat CentOS acquisition: stating the obvious

[Patrick J. LoPresti]

On Wed, Jan 15, 2014 at 4:28 PM, Karanbir Singh mail-li...@karan.org wrote:
 On 01/15/2014 11:27 PM, Patrick J. LoPresti wrote:

 so, rather than looking at an opinion blog, why dont you go read the
 actual announcement ? see if that mentions this little detail...

Do you mean Red Hat's announcement?

http://www.redhat.com/about/news/press-archive/2014/1/red-hat-and-centos-join-forces

Or maybe Red Hat's FAQ?

http://community.redhat.com/centos-faq/

...

Oh, I see. You mean your mailing list message:

http://lists.centos.org/pipermail/centos-announce/2014-January/020100.html

Yes, I did miss that. Mea culpa.

My own interest is in Scientific Linux; I never much cared for CentOS.
And I admit to a strong cynicism about what this acquisition will
ultimately mean for SL.

But trolling? Certainly not. I would have been perfectly happy with
far fewer non-researched, ill-thought-out responses. Zero, actually.

 - Pat

RedHat CentOS acquisition: stating the obvious

[Patrick J. LoPresti]

RedHat is a company. Companies exist for the sole purpose of making
money. Every action by any company -- literally every single action,
ever -- is motivated by that goal.

The question you should be asking is: How does Red Hat believe this
move is going to make them money?

Those were statements of fact. What follows is merely my opinion.

Right now, anybody can easily get for free the same thing Red Hat
sells, and their #1 competitor is taking their products, augmenting
them, and reselling them. If you think Red Hat perceives this as being
in their financial interest, I think you are out of your mind.

SRPMs will go away and be replaced by an ever-moving git tree. Red Hat
will make it as hard as legally possible to rebuild their commercial
releases. The primary target of this move is Oracle, but Scientific
Linux will be collateral damage.

I consider all of this pretty obvious, but perhaps I am wrong. I hope I am.

 - Pat

Re: RedHat CentOS acquisition: stating the obvious

[Patrick J. LoPresti]

What spinoff do you mean? Did I miss something?

http://finance.yahoo.com/q/co?s=RHT+Competitors

http://en.wikipedia.org/wiki/Oracle_Linux

I suppose you could argue that Oracle comes behind Microsoft and
Novell on the list of Red Hat competitors (I wonder how Red Hat looks
at it?), but I do not think that changes my reasoning nor my
conclusions.

If you think the end result will be to make it _easier_ to obtain a
free clone of RHEL, then once again, I think you are out of your mind.
Yes, I am accusing Red Hat
(http://community.redhat.com/centos-faq/#_motivations) of lying... Or,
more precisely, of being highly selective with the truth.

Also again, I could be wrong. Time will tell.

 - Pat


On Tue, Jan 14, 2014 at 10:12 AM, Andrew Z form...@gmail.com wrote:
 Patrick,
 Why do you think oracle's spinoff is their major competition?

 On Jan 14, 2014 12:47 PM, Patrick J. LoPresti lopre...@gmail.com wrote:

 RedHat is a company. Companies exist for the sole purpose of making
 money. Every action by any company -- literally every single action,
 ever -- is motivated by that goal.

 The question you should be asking is: How does Red Hat believe this
 move is going to make them money?

 Those were statements of fact. What follows is merely my opinion.

 Right now, anybody can easily get for free the same thing Red Hat
 sells, and their #1 competitor is taking their products, augmenting
 them, and reselling them. If you think Red Hat perceives this as being
 in their financial interest, I think you are out of your mind.

 SRPMs will go away and be replaced by an ever-moving git tree. Red Hat
 will make it as hard as legally possible to rebuild their commercial
 releases. The primary target of this move is Oracle, but Scientific
 Linux will be collateral damage.

 I consider all of this pretty obvious, but perhaps I am wrong. I hope I
 am.

  - Pat

Re: RedHat CentOS acquisition: stating the obvious

[Patrick J. LoPresti]

So I decided to check the Competition section of Red Hat's annual
SEC regulatory filing (10-K):

http://www.sec.gov/Archives/edgar/data/1087423/000119312513173724/d484576d10k.htm#tx484576_1

(see pages 11-13)

Oracle and Microsoft are each mentioned seven times in this
section, far more than any other company. Granted, Oracle _Linux_ is
only mentioned once, but once is enough to show that Red Hat takes it
seriously.

Interestingly, Fedora and CentOS are also specifically named as
competitors. So I can rephrase my earlier question: How does Red Hat
believe the acquisition of this competitor will make them money?

(I have my guesses, obviously. Hint: What is Red Hat's strategy for
ensuring that Fedora does not compromise RHEL sales? What do you think
their strategy will be to ensure the same for CentOS?)

Anyway, enough speculation from me. We will all see what actually
happens soon enough.

 - Pat


On Tue, Jan 14, 2014 at 2:54 PM, Andrew Z form...@gmail.com wrote:
 Yes I meant oracle.
 Im not sure if oracle is the major competitor in os market for rh.
 From my expirience it is still windows vs unix in enterprise infrustructure.
 Speaking of oracle clone - it comes only with oracle products.  And even
 then, not that often. Again these are my observations over couple of yeara
 and ill be happy to reconsider if you have some statistics to support your
 point.

 From what I understand code for free was never an issue for rh. The
 companys bussines was to _provide services_ on top of open source os.

 On the contrary,  I think that the way to grow the rh bussines is to work in
 as many open source projects as possible. This way more people are fimiliar
 with this particular version of linux.