[CentOS] CentOS CVE "database"?

[Nate Duehr]

Was working on a project tonight to document CVE fixes applied to servers, and 
noted that RedHat has completely jacked up their website.

In the past, I've usually just used their website for links to their CVE list, 
as well as links to their Errata to look up specifics for CentOS machines.

It sure looks like these links are either permanently gone from the public 
pages to be hidden internally only available to Subscribers, or... 

RedHat's Marketing folks have completely destroyed what was once a valuable 
information-filled website.

Either way... the question now becomes...

Is there something similar to RedHat's CVE listings by year and number hosted 
by anyone in the CentOS community or by CentOS itself for CentOS?  I haven't 
had much luck with my GoogleFu tonight.

Thanks, 
Nate
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS CVE "database"?

[Nate Duehr]

Appears it's back up, just as a follow-up.

On Oct 8, 2011, at 12:01 AM, Nate Duehr wrote:

> Was working on a project tonight to document CVE fixes applied to servers, 
> and noted that RedHat has completely jacked up their website.
> 
> In the past, I've usually just used their website for links to their CVE 
> list, as well as links to their Errata to look up specifics for CentOS 
> machines.
> 
> It sure looks like these links are either permanently gone from the public 
> pages to be hidden internally only available to Subscribers, or... 
> 
> RedHat's Marketing folks have completely destroyed what was once a valuable 
> information-filled website.
> 
> Either way... the question now becomes...
> 
> Is there something similar to RedHat's CVE listings by year and number hosted 
> by anyone in the CentOS community or by CentOS itself for CentOS?  I haven't 
> had much luck with my GoogleFu tonight.
> 
> Thanks, 
> Nate
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Can anyone talk infrastructure with me?

[Nate Duehr]

On Jan 26, 2012, at 4:59 PM, John R Pierce wrote:

> On 01/26/12 3:43 PM, Gordon Messmer wrote:
>> Yes, the cost for a T1 will seem very high.  It is antiquated telco
>> tech.  T1s are generally very reliable, but very very slow.
>> 
>> 1.5Mbps is not faster than 40Mbps.  There's nothing hidden in the way
>> they advertise speeds.
>> 
>> DSL and DOCSIS technologies have advanced and matured over the last
>> couple of decades.  T1 has not.  A T1 connection is the same now as it
>> has always been.
> 
> a modern T1 (aka DS0) is likely delivered to the end premises over HDSL 
> using 2 pairs.   while its slower than those consumer oriented 
> technologies you mention, its far more reliable and has a guaranteed SLA 
> (service level agreement) you won't get from DOCsis (cable) or end user 
> ADSL, and tends to have very deterministic latencies...

Wow, that's just ... wrong.

There's nothing to "mature" in a T1.  It's a telco transport standard that is 
well-known, and utilized everywhere as part of the Bell System standards for 
multiplexing and demultiplexing from smaller circuits to larger and back down.  
Ratified by the ITU for decades.

"T1" is a channelized synchronous telecommunications circuit type first 
designed in the late 60s, updated in the 70s.  After removing framing bits, 
1.544 Mb/s.

"DS0" is a sub-channel of a T1 when broken up into frames.  Extended SuperFrame 
being the typical method these days.  24 of them at 64K per channel.

"HDSL" is a completely different technology than T1.  

"DOCSIS" is the name of the standard utilized to deliver data services over a 
Cable Modem.  

"ADSL" is a single-pair high speed connection that's very distance limited from 
the origination point.

"SLA" is a Service Level AGREEMENT.  The key word being AGREEMENT.  Your 
businesspeople are free to negotiate with any provider of ANY of the above 
technologies for anything they're willing to pay for.  TYPICAL SLA's might be 
as stated above, but it's a contract... negotiate whatever you like.

What you might want SLA's on when ordering IP bandwidth: 

- Maximum CONTINUOUS data rate upstream AND downstream simultaneously, and what 
thresholds are considered an OUTAGE on the SLA even if traffic is still flowing.

- Latency from your end of the circuit to a known point will never EXCEED "X" 
amount or it will be considered an outage under your SLA.

- Whether or not an UPSTREAM routing outage will be considered an SLA OUTAGE by 
your local carrier/ISP in terms of your bill. (In other words, how many 
backbone connections do they have and can they route around a problem, or are 
you stuck waiting for their one piddly edge router to be fixed in the case of 
fly-by-night providers.)

- In the case of a cable cut, are trucks rolled 24/7, or only during business 
hours?

Etc etc etc... there's more.  Read up.

SLA's are themselves a playground for lawyers and businesspeople to dicker 
over.  

Now the real world: 

- Any company relying on a single IP connection via a single route... is so far 
down the food chain they're not going to get service during a larger scale 
outage anyway.  

And... remember...

- An SLA just gives you a refund of your money for the outage.  It doesn't keep 
you in business if the service provider doesn't keep their side of the bargain.

- If you have something that must be connected to the Internet 24/7 or you're 
out of business... buy more than one connection.  An SLA won't matter at all 
when the backhoe cuts the only path out of your building.  

- Or... host it in a data center that has far more than one backbone connection 
via more than one physical route.

Let's not mix all the technical details up with the business ones.  That 
posting was the most misleading post I've read in quite a while, and shows a 
lot of the misconceptions out there.  

*** ANY of the above technologies can deliver a certain number of bits, at a 
certain latency, a certain direction, across a certain type of physical media, 
to some network at the other end. ***

Whether that upstream provider has oversubscribed upstream connectivity, has 
latency issues, doesn't respond to fix their circuits in the middle of the 
night, pays you back for outages, scratches your back at the beach after 
signing that multi-million dollar bandwidth contract with giant SLA attached 
large enough to fund their entire fleet of trucks for a year... 

That's all up to the contract...
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Faster and faster

[Nate Duehr]

On Mar 27, 2012, at 2:08 PM, Piero wrote:

> Thanks for your hard work and great product,

Agreed, other than that I'm struggling to keep all the machines up! (GRIN!)

Nate

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] screen brightness changes depending on which application is run

[Nate Duehr]

On Apr 8, 2012, at 12:18 PM, Jeff Cen wrote:

> Hi,
> 
> I found my LCD screen brightness increase when I use firefox and other white 
> background editors and screen brightness decrease when I use dark background 
> applications, such as terminals with black background .  The change in screen 
> brightness depending on the applications has been annoying. 
> 
> 
> My centos version is ver 5.7 64 bit.  Has anyone seen a similar problem or 
> have a solution for that?  Thanks in advance.
> 
> Jeff

Jeff, 

Does your machine have an ambient light sensor?  

Light from the monitor, reflecting off of you, will often trigger changes in 
the amount of light the ambient light sensor is seeing.

Happens most with large changes like switching from a bright white (browser) 
background to a dark one, just as you describe in your symptoms.

Nate
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] screen brightness changes depending on which application is run

[Nate Duehr]

On Apr 11, 2012, at 11:29 PM, allan wrote:

> Is your monitor an LED type? It could have dynamic brightness. My tv does the 
> same thing - also annoying.

I have also seen that "feature" on an HP monitor with LED backlight.  I believe 
it was a feature one could turn off in the monitor's built-in OSD menu.

Nate
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Documentation question

[Nate Duehr]

Apologies if this is a FAQ or it's simply due to a lack of volunteers. 


I'm curious why the CentOS Documentation here: 
http://www.centos.org/docs/5/

...stops at CentOS 5.5.

And also why there is no: 
http://www.centos.org/docs/6/


*** Curiosity killed the cat. ***


Thanks, 

Nate
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] system date using ntp client is drifting

[Nate Duehr]

On Jun 4, 2012, at 1:59 PM, Kaushal Shriyan wrote:

> Hi,
> 
> I have a set of servers whose system time is drifting. I am running ntp
> client on CentOS 5.8. My config is here -> http://fpaste.org/s55U/
> Anything i am missing?

Fire up ntpq, and type "peers" and see if they're seeing their upstream 
servers.  If not, hunt down the firewall or other filter problem.

Additionally, ntp will refuse to sync if it's too far out.  Use ntpdate [server 
IP] to force the issue first. If the machines have a bad CMOS battery and won't 
keep time, ntpdate package can be configured to force time sync (which is a bad 
hack) at boot-time.

After getting the clock in sync, "hwclock --systohc" to push it into the CMOS 
clock.  

Nate
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] system date using ntp client is drifting

[Nate Duehr]

On Jun 4, 2012, at 2:42 PM, John R Pierce wrote:

> On 06/04/12 1:27 PM, Nate Duehr wrote:
>> Additionally, ntp will refuse to sync if it's too far out.  Use ntpdate 
>> [server IP] to force the issue first. If the machines have a bad CMOS 
>> battery and won't keep time, ntpdate package can be configured to force time 
>> sync (which is a bad hack) at boot-time.
> 
> the standard EL5 /etc/rc.d/init.d/ntpd script does this automatically, 
> unless its been disabled via /etc/sysconfig/ntpd

Interesting.  I hadn't looked at the scripts in a while.  

The reason no one ever did it "in the old days" was for fear of an NTP server 
going out of whack.  ntpdate should be used sparingly and with knowledge that 
one is doing it... automating it is usually a bad idea.  (Especially by 
default.)  As I said in the original reply, it's a nasty hack.

IMHO, ntpdate package install should be just to get the tool installed, no 
automation.  If it's installing automated setting by default, that's not right. 
One should have to turn ON automated ntpdate at startup/shutdown after 
understanding the risk.

>> After getting the clock in sync, "hwclock --systohc" to push it into the 
>> CMOS clock.
> 
> setting SYNC_HWCLOCK=yes  in said above config file will do this, too.

Was just giving him the way to do it in real-time.  The config file only does 
it at startup/shutdown, last I looked.  Haven't looked recently.

Sounds like there's been some goofy decisions made somewhere along the line for 
ntp and ntpdate... an NTP server can be compromised and date/time changed 
across an envrionment (or more likely, it can have some type of failure 
itself...) and the old tenets of ntp were there for a reason...

1. ntp doesn't sync if it's too far out of whack... 
2. ntpdate should be operated by hand... not automated... 

Oh well.  Those unwilling to learn from past mistakes are doomed to repeat 
them, right?  (GRIN!)

Nate
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Swap Partition in CentOS 5.8

[Nate Duehr]

On Jun 18, 2012, at 5:55 PM, Woodchuck wrote:

[snipped swap/pagefile list of statements]

> Thanks to the list for any answers!


Nothing in your list was phrased as a question.  What are you trying to 
determine?  If the list of statements was accurate?

Nate 
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6.2-x86-64

[Nate Duehr]

On Jun 20, 2012, at 1:59 PM, Gene Heskett wrote:

> I found a yumex, which is not part of the 64 bit install, but it wants a 
> way older version of python-2.4 whereas we have 2.6.6-something after the 
> post install upgrade.
> 
> 1st Question:
> Is there anything that can be done about this?  Or is there something 
> better, like a 64 bit synaptic to replace yumex?
> 

You may be unfamiliar with CentOS in that many tools you might find "standard" 
on regular distros, aren't part of the upstream package list for "Enterprise" 
Linux.  As delivered from upstream, it's a fairly "stripped" distro.

Yumex is not packaged by upstream, so it's not part of CentOS proper.  

However, there are repositories that build packages to run under CentOS which 
aren't part of upstream or CentOS, such as EPEL:
http://fedoraproject.org/wiki/EPEL

yumex in particular, if you're partial to it, is available in various flavors, 
all ready to install.

> Mail problem:
> 
> I've been using a fetchmail -> procmail system here for years to unload 
> kmail from its mail pulling duties, making it many times easier to use.
> 
> Adjuncts to that are spamassassin, clamav, and mailfilter
> 
> There appears not to be any 64 bit builds of clamav and mailfilter.

Many 32-bit packages run just fine on 64-bit CentOS via the use of 32-bit 
libraries.  

A quick look through a machine that has both stock CentOS software repositories 
and EPEL enabled shows that there are packages for all of the above, except 
mailfilter.  Mailfilter appears to be somewhat Debian-centric and the 
Debian-distro-derivatives all seem to have updated packages.  I've never used 
it, even though I'm a fan of both "camps" for various things.

Looking it over, it looks like it utilizes POP to go take a look at mail and 
dump spam prior to the POP transfer of whatever is left over?  Honestly, most 
folks have moved on to IMAP, long ago... IMHO.  YMMV.

The advent of large data pipes, even in residential service in most areas, and 
effective local filtering probably means that mailfilter is marginalized 
non-mainstream software, at best, these days.

Doing some quick Googling, mailfilter doesn't seem very popular at all with the 
RedHat-derivative camp.  The only distro that seems to have ever had it 
pre-packaged is Mandriva.  You might look at whatever changes they made to make 
their x86_64 package.  It's not in Fedora either... 

https://admin.fedoraproject.org/pkgdb/acls/list/m*?_csrf_token=1320052a8a44a38e84b472e63f9cba4db006ea38

Nate
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6.2-x86-64

[Nate Duehr]

On Jun 20, 2012, at 3:27 PM, Gene Heskett wrote:

> As for partiality, no way, synaptic, adapted for rpms is by far the best 
> package manager I've used in the last 5 years since I bailed on fedora at 
> about 6 or so.

Understand that sentiment, Gene.  I like aptitude myself for Debian-based 
systems, but everyone has a favorite.

It sounds like you have much of your repo problem for RPM sources for the tools 
you want understood now.  I would caution that some repos out there are set up 
by individuals who are interested in fixing something, they make a few 
packages, and then they disappear when they lose interest.  

I suggested EPEL because it's a large project, based off of an even larger one 
(Fedora) and there's probably not going to be any major disruptions in it as 
far as interested-parties goes, so security and version updates of most 
packages in it should keep flowing unless upstream sources abandon them.

> I just pulled the clamav stuff, not terribly complete unless the utils are 
> part of the main package, but have not attempted an rpm -ivh on that kit 
> yet.  I got the huge majority of the stuff with FF, at 
> 
> which I found via a google search.

Highly recommend adding reputable repos to your local system and then using yum 
search [packagename] or similar... I haven't seen the name choonrpms before, 
but I'd kinda want to know who they are before installing their packages.  Just 
a thought.  Take or leave.  (Someone who knows who they are, may be chuckling 
at that... I don't know... I haven't researched it.)

> I'm getting close to that in N. Central WV, phone and internet are on the 
> local cable, getting about 385k/sec dl speeds on average.  But I have kept 
> my own email corpus here since 1998, over 7Gb of it now, and old, probably 
> bad habits are hard to break.  Old being relative of course since I'm only 
> slightly younger than dirt at 77.  Retired (almost, I take a small plane 
> ride tomorrow to go look at a transmitter that is off the air) from the 
> local CBS affiliate as the CE from 1984.9 to 2002.6.

I will add my vote that even though running ones own mail server is a fun 
challenge, at some point in the past I decided to leave it to younger pros who 
get paid to wrangle with spammers and what-not, and now only run mail servers 
I'm paid to deal with.  (GRIN!)  

I migrated old mail that I thought I couldn't live without to the IMAP account 
and said goodbye to the time-suck that a modern mail server has become.  (I 
still operate mail servers for my employer, but at home... it's nice to just 
forget about it and read my mail. GRIN...)

Neat to run into another RF "geek".  Never made my living at it, but I maintain 
some Amateur Radio FM repeaters and some Public Safety FM and P-25 systems.  
Nothing high power, broadcast or TV, but as things are generally co-located on 
mountains... have seen many broadcast systems up close, and had the "5 cent 
tour" from the Station Engineers in the area.  

Be careful with that high-power stuff... but you know that already.  No tower 
climbing at 77... let one of us young whippersnappers do that silly stuff.  I'm 
about half your age, and I still don't really like it.  Just a necessary evil 
in volunteer organizations... strap on the safety gear, and get going.  

You mentioned a small plane... I do small planes for fun these days, and I'd 
much rather be doing that, than climbing a tower. (GRIN!)

> Thanks, I'll see if I can google that when I get back from the trip & get 
> over my aches & pains from crawling around in that elderly Harris 50kw 
> transmitter.

CBS does love their Harris stuff, eh?  I got to see the new solid state beast 
out here in Denver in person... 1KW modules, pop one out, pop one in... touch 
screen to gracefully fail one if you want to pull it... pretty amazing stuff.  
Paul (the Engineer here) really enjoys his broadcast radio and other radio 
toys.  That was one of the "five cent tours", seeing his new setup in a shared 
building with various other DTV systems co-located.  Newest site I've ever been 
in.  Nice setup.  Always interesting to see waveguide bigger than most sewer 
pipes and the associated filters.  Looks like an old steamworks for a 
steamship, but all "filled" with RF instead of water vapor... 

Enjoy your "retirement"... and 73 if you're a Ham... WY0X here.

Nate

p.s. Apologies to the list for the personal notes and digressing a bit... I 
don't think I know Gene well enough to send him private messages.  All the best.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Question about storage for virtualisation

[Nate Duehr]

On Jun 26, 2012, at 10:29 AM, Gordon Messmer wrote:
> 
> I don't believe there's any more or less need to do so.  I would 
> strongly recommend that you not segregate / and /usr.  Fedora and future 
> versions of RHEL/CentOS will expect a unified / and /usr.


I may be behind, but this is the first I've heard of this...

Any good references as to WHY?! they want to break this decades old convention?

Thanks, 

Nate

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Question about storage for virtualisation

[Nate Duehr]

Appreciate all the discussion, folks.  

Got some boxes that have some separate / and /usr, since we're a /usr/local 
religion shop. (GRIN...)  Someone long long ago, in a galaxy far, far away 
picked /usr as the split point, instead of /usr/local itself.  So...

Layers 8 and 9 of the OSI model, bite again... Religion and Politics. 

Guess we'll be moving to /opt or /usr/local being the separate mountpoint.  I'm 
sure this will be a happy internal discussion... hahaha... 

Nate 
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] run fsck manually

[Nate Duehr]

On Jul 9, 2012, at 12:03 PM, m.r...@5-cent.us wrote:

> Jerry Geis wrote:
>> Is there a way in centos to just go ahead and do this automatically?
>> 
>> /dev/sdal: Unexpected Inconsistency; [FAILED]
>> 
>> Run fsck Manually
>> 
>> (ie. Without –a or –p options)
>> 
>> ***An error occurred during the File system check
> 
> a) fsck -y -C [-c] /dev/sda1 (-c will check for bad blocks; it will take a
> *while*; run it overnight, or over dinner, or over the next looong
> meeting)
> b) Buy new disk, *now*, insert, rsync over.

He's not asking what to type at that point, he's asking how to keep the kernel 
from stopping at that point and just do the (possibly destructive, but 
often-times all that gets damaged/moved to lost+found, is open logs that were 
open when the system went down) fsck.

(Unfortunately I do not know the answer as to how to tell the initial fsck just 
to go ahead and do the destructive fsck pass, without human intervention, as I 
wouldn't want it to do that, but I see where the communication misunderstanding 
is happening in the e-mail chain.)

He's saying the desktop machines are "throwaway" and he doesn't want to take 
the time to go over and look... do the fsck and if it trashes the filesystem, 
he'll just re-image the machine later.  Meanwhile, the user isn't confused by 
the fsck message or interrupted by it, if the machine finds filesystem problems 
at boot time.

I would assume this is often a desired behavior on machines that have poor AC 
power at remote sites.   Give the fsck a try if I'm not there.

Nate
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Another NTP issue (fake leap second)

[Nate Duehr]

Yes, Java was grumpy.

--
Nate Duehr
denverpi...@me.com



On Aug 2, 2012, at 1:24 AM, Timo Schoeler  wrote:

> Hi list,
> 
> just out of curiosity: Was anybody affected by this?
> 
> http://lists.ntp.org/pipermail/questions/2012-August/033611.html
> 
> Cheers,
> 
> Timo
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Strange device labeling in 6.3

[Nate Duehr]

On Aug 9, 2012, at 7:43 PM, Kahlil Hodgson  
wrote:

> On 10/08/12 09:18, Reindl Harald wrote:
>> and that is why i use /etc/udev/rules.d/70-persistent-net.rules to
>> pin device-name / MAC and no mac-address in ifconfig-scripts since
>> many years
> 
> +1
> 
> Alternatively, with the biosdevname, you can pin the interface name to 
> the pci(e) slot. That way its a trivial exercise to get 'remote hands' 
> to swap out a dead nic -- no need to fiddle with the mac address.

And if you don't... 

Doing remote hands to swap a bad NIC with someone non-Linux qualified in 
another country, just became the seriously sucky part of your day.  BTDT.  Got 
the t-shirt.

Nate
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Advice on partitioning a Dell MD1200 disk array

[Nate Duehr]

On Sep 4, 2012, at 5:10 AM, Tony Molloy  wrote:

> Just remember I'm due to retire at the end of this month so this will 
> be my last big job for the Dept. And due to financial constraints I 
> will not be replaced. So I will be handing this machine over to a co-
> worker who is basically a Windoze admin with only a basic knowledge of 
> Linux so nothing too fancy.  ;-)

Hand him the machine and tell him to load Windows on it or whatever he wants to 
maintain for the next X years, relax for 30 days and enjoy retirement.  It's 
his problem now.  :-) :-) ;-)

Nate
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/

[Nate Duehr]

-- Original Message --
From: "Rainer Duffner" 


So, you will quickly be back to square one, unless you want to run stuff like 
Debian or Ubuntu, which are mainly Linux-kernel+some stuff nowadays, whereas 
RHEL + CentOS forms a complete system (with additional software that RedHat has 
developed or acquired over the years).


Been reading along and literally laughed out loud at this silliness.

The vast majority of that "system" was unavailable to CentOS, always, 
and WAS the "compromise" in running it.


Stuff like beating your head against getting Satellite running, or 
realizing RH hid away the meta-data from CentOS users to know what a 
security update was, versus a feature or bugfix, which went against what 
RHEL itself was SUPPOSED to do, but never really did... and couldn't 
control massive upstream ABI, API, or feature changes throughout the 
lifespan of the promised "support", even for paid RHEL.


This is definitely not true for most CentOS users and is hilarious.  
What "system"?  It NEVER existed on CentOS.  Can't even get patch 
management software to mesh up verion numbers between RHEL and CentOS.


We "put up with it all" for exactly one reason. It was a binary 
compatible re-spin of RHEL without closed/proprietary things.  That's 
it.


The rest is just noise.  If it isn't a re-spin anymore... well, we'll 
"put up with" other oddities of projects that don't reverse their 
multi-year commitments to support things, and even stop having to 
"fight" with years-old packages.


The IT world wants "rolling" OSes and perma-garbage always-broken 
releases today, apparently.


Our first company meeting about who we dump CentOS for was this morning. 
 Flipping architectures is a year long project at least, so we're out.  
Didn't announce alternatives THE DAY IT WAS KILLED, we can't be bothered 
anymore.


We literally don't have the time with piles of other commerical and 
cloud services following suit and capitalizing on WFH and everything 
else about Covid.  We already literally have to "fire" our firewall/VPN 
vendor for doing it, we're extremely annoyed with both Google and 
Microsoft and their changes, and we already have the continuous 
nightmare of literally EVERYONE releasing so many critical security bugs 
constantly and patching ramping toward daily... that everybody who makes 
that harder is flipped the bird and summarily tossed.


The good news: Covid business model changes at least highlighted who 
we're firing faster than any hemming and hawing as things deteriorate 
for years on any platform we use.  Whoever is reaching into our (not 
very deep) pockets will lose a hand this year, we have lost our patience 
for it.


RH and the so-called "CentOS Board" (majority of RedHat people) lost 
touch with what companies are already going through with multiple 
vendors bumping prices and lowering services.  Flipping distros will 
ultimately seem tame this year for corporate users.  We may have to 
switch entire cloud platforms and services to avoid the ultra-greedy 
companies.  But annoy us this year, we have zero patience.  We're done 
with it.


DUMP.  BYE.  You ticked us off in a long line of companies we have doing 
that.  Horrible timing for RH, but they'll survive on government graft 
and large contracts.  Go Big Blue.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Is Oracle a real alternative to Centos?

[Nate Duehr]

-- Original Message --
From: "Matti Pulkkinen" 


As someone who is considering moving to OL, I wonder if you could elaborate 
clearly on what specific concerns you have, without the insinuation and 
analogy? Oracle's proposition [1] seems pretty straightforward to me.

That they'' eventually treat it to the same lawyers who've changed Java 
licensing.




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos