On 11/07/2017 04:59 PM, David Sommerseth wrote:
> On 07/11/17 23:10, ToddAndMargo wrote:
>> On 11/07/2017 10:09 AM, David Sommerseth wrote:
>>> On 04/11/17 01:14, ToddAndMargo wrote:
>>>>
>>>> I do realize that RHEL is just next to unmaintained code.
>>>
>>> Hey, cut the FUD crap please. And this isn't the first time you come
>>> with such bullshit either.
>>
>> It is a long running observation and not FUD or bull s***.
>
> I strongly disagree in your observations, when you label the efforts of
> producing a rock solid Linux distribution which is designed to survive a
> decade long installation.
>
>>>
>>> RHEL is fully maintained and updated according to their release process.
>>> Bugs and security issues are fixed during the complete life cycle of
>>> each major release. That is quite far from "unmaintained code".
>>> Insisting on running RHEL 4 today is running unmaintained code.
>>
>> This is true. RH has their own proprieties. One if them is getting
>> paid for their consulting. The open source model is such. And since
>> I can not afford to put them on my payroll, I am dead last on
>> getting anything fixed. (I can barely afford to keep a roof over
>> my head with this never ending recessions, which has slowly started
>> to break by has not tricked down to me yet.)
>
> Which gives you even less reasons to complain about what RHEL is and how
> it is designed to be as a Linux distribution.
>
>> And I did not say "unmaintained code". I said "next to
>> unmaintained code". There is a difference.
>
> And both are wrong in regards to the context of RHEL and how it is
> maintained.
>
> [...snip...]
>>
>> 1) It does not operate on modern C236 small business based server
>> motherboards. That would be
>
> I do NOT see that being listed here:
> <https://hardware.redhat.com/&quicksearch=C236>
>
> Hence, there is NO reason to be surprised here. To get through the
> certification takes lots of efforts, both from Red Hat and the hardware
> vendor. And neither have put efforts into this specific system.
>
> Many years ago, I worked a bit on the test suite which is used for the
> RHEL certification. At that time, it could take up to a week to finish
> a complete certification run. And after that came evaluation of the
> results the certification run provided. That evaluation also indicated
> if anything needs to be improved before being certified.
>
>> 7.2 not compatible with C236 and RSTe motherboard
>> https://bugzilla.redhat.com/show_bug.cgi?id=1353423
>> Reported 2016-07-06 (by me)
>>
>> And if you read the bug report, you will find that their reason
>> for NOT fixing the issue is that they do not have the hardware
>> available DESPITE the fact that I told them who to call, phone
>> number and all, over at Supermicro to get free hardware.
>
> This is probably a way more arrogant and ignorant attitude of you than
> you are aware of. You really don't think Red Hat already have
> established vendor relation with Super Micro? There are 1019 various
> certified systems from Super Micro as far as I can see. It would not
> even surprise me if Red Hat have at least one designated hardware
> partner contact just for Super Micro.
>
> Red Hat isn't a tiny garage company doing fun stuff. They're an
> enterprise with 10k+ people hired spread over 90 offices across the
> world. How much have you been paid in RHEL subscriptions? And why
> should they focus on your needs when NYSE is on their doorstep asking
> for some other and more important hardware to be certified?
>
>> So, EVEN IF I WANTED TO, I can not use EL Linux on ANY
>> new C236 based small business server. And I reproduced
>> the issue on two separate server for them.
>>
>> Why? Again, because "EL Linux as 'next to unmaintained'".
>
> No. Not (next to) unmaintained. UNSUPPORTED due to NOT BEING
> CERTIFIED. You picked the wrong hardware. Deal with it.
>
> [...snip...]
>
>> You ever have the experience of find your business' tasks
>> and contacts missing when you fire up your machine and
>> can't figure out why it keeps happening? (Good thing I am a
>> back up whore.) I almost had a heart attack.
>>
>> Again, because "EL Linux as 'next to unmaintained'".
>
> No. Because you are using RHEL in an inappropriate and unsupported way.
> You do not accept that the blue car is blue.
>
>> 3) You get you ass made fun of and requests out right
>> rejected because you are so out of date. The folks over on
>> NMap's list think you are out of your mind for operating
>> anything that is so out of date and refuse to help you.
>>
>> Case in point. Here are two rejections from Simple Scan:
>>
>> https://bugzilla.gnome.org/show_bug.cgi?id=789890
>> https://bugzilla.gnome.org/show_bug.cgi?id=789892
>
> Upstream GNOME development IS NOT RHEL package maintenance. Again, blue
> cars are blue.
>
> Before each single package RH ships, either through the various
> repositories or as a new minor release, these packages are sent via a
> boatload of regression and functional testing. And then a set of
> install/uninstall/reinstall/upgrade/downgrade tests. This is to ensure
> the package has a predictable stability. I do not say this is flawless
> and that updates don't breaks thing ever. But in the vast majority of
> various updates, when running on SUPPORTED hardware, the issues are
> scarce and the long-term stability is very good.
>
> You do not get that kind of stability by upgrading to newest latest
> release every now and then. Any upgrade needs to be evaluated and
> vetted and once approved it will go through lots of testing. This
> doesn't happen over a weekend or two.
>
> And with RHEL7, GNOME packages do get version rebases. But only for
> each minor release. And only when it is considered safe to do such a move.
>
> [...snip...]
>
>> If you find an issue in a program, it is very unlikely
>> that the developers will even look at the problem. You
>> can report it to Red Hat, but it is very unlikely that
>> they will fix it either, unless you are under contract
>> with them. That is the way open source's economic
>> model works.
>
> It is not about open source's economic at all. Does Red Hat ship the
> software you use through their repositories? Do you run the software on
> certified hardware? Have you paid a subscription with support? If yes
> to all of these questions, then you can complain about things not
> working. If any of these 3 questions is a "no", then you need to either
> do it yourself or find someone else willing to do the job for you.
>
>> Again, because "EL Linux as 'next to unmaintained'".
>
> Wrong again. Blue cars will always be blue. And red bikes will also
> be, surprise, red.
>
> [...snip...]
>
>> I have two C236 based small business server running out
>> there now. I have not noticed any difference in stability
>> over EL Linux. But I have noticed a YUGE difference in
>> frustration trying to work on them.
>
> Try using CERTIFIED HARDWARE next time. Really.
>
> [...snip...]
>
>> RH does have its own proprieties. Their target customer is
>> large businesses, not small businesses and certainly not
>> consumers. It is about getting their consulting fees.
>> So they drag their feet and call it stability. They have
>> to make a living too.
>
> Again, you want RHEL to be something it is not designed to be. You are
> yet again complaining that your blue car is not orange. And guess what:
> Nobody cares about that! If you want an orange car, pick an orange car
> next time. In the mean time, deal with it that the car is being blue.
>
>> This is the way the open source model works. You want
>> something fixed, you need to pay for it. It is what it is.
>
> Again, this is not open source model. This is standard business models.
> If you want something fixed, do it yourself or pay someone to do it for
> you.
>
> When software is open source it just _facilitates_ that YOU (or anyone
> you engage) can fix it, without needing to go over any massive hoops.
> The source code is available, it is just to dive in. If you're not
> willing to do that, you have neither any valid reasons to complain.
>
>> Please do not take my analysis personally. My analysis of EL Linux
>> is based on years of frustrating experience with it. Again,
>> I do acknowledge your frustration with my observations. It is
>> not personal.
>
> I don't take this personal at all. You are just barking up the wrong
> tree for the wrong reasons. And that is not fruitful in any way. And
> venting your frustrations because your expectations of the blue car not
> being orange is just plain noise on this list.
>
> I challenge you to become a Fedora and Fedora EPEL package maintainer to
> see what kind of work is behind the work you basically just take for
> granted. Take one of those missing or "outdated" packages and get it in
> shape for both Fedora and Fedora EPEL and we can discuss again about
> being "next to unmaintained".
I am not that skilled.
>
> Bullshit talks, code walks.
By the way, I do code in Perl 5 and 6. EL Linux is
a nightmare with all its outdated Perl. Look
at what I have to do to get a YUM update through:
# yum --skip-broken --exclude perl-libs.otherarch --exclude
net-snmp-libs --exclude libsemanage upgrade
Whenever I trip across a bug in Perl6 (and I find a lot of them),
I tell the developers over on their chat line and in two weeks to a
month, "dnf upgrade rakudo" (Fedora)
fixes the issue.
Same with Perl 5, although I find very few bugs in
P5 as it is mature.
I should NEVER expect this from EL Linux. This is my fault.
This is not what EL Linux is meant for. Need a bug fixed,
too bad. This is frozen code.
I JUST TRULY adore that fact that some of my Perl code
works in Fedora but not EL Linux. <Editorial Comment
AAAAHHHHHH !!!! </editorial comment>
I have been turned down for help before as the issues
in Perl I have tripped across ARE fixed, but not in
EL Linux. I have tried removing all of EL Linux's Perl code
and install the good stuff manually, but I never manage
to get rid of all the old, bad stuff successfully. Again,
my fault for not picking a Kaisen OS.
And you are correct. I am using EL Linux incorrectly.
It is meant to run on old, outdated hardware that is
a pain in the ass to find, running old, outdated software
meant to be frozen in place. EL Linux is not meant to
be run on anything new or otherwise current.
And you know the Cxxx series of chipsets have been around
for a while now. Just not long enough to be out of
production at which point it will appear on Red Hat
compatibility list.
I should not be expecting Osmo or anything else current
to run on it. And if I find a bug in any of the outdated
stuff it ships with, I should learn to live with it.
It is only meant to work with what it ships with.
I just upgraded a CentOS 5 server. It was over seven years
old. It just keeps running and running. But its was time as things
were going to start failing hardware wise. So EL Linux did
its thing as you described. But, I need to point out, that
Fedora would have too, if I had not upgraded. The Ask Fedora
folks still yield question on Fedora servers that are very old indeed.
EL Linux is perfect for a set and forget installation that
needs to be frozen in place for a lot of years, providing
your stuff work to start with on it.
Yes RH is a YUGE company and yes they have a lot of
relationships with vendors. How do you explain these
remarks of theirs?
https://bugzilla.redhat.com/show_bug.cgi?id=1353423#c12
"I don't have the hardware to dig deeper."
https://bugzilla.redhat.com/show_bug.cgi?id=1353423#c21
"No, as I have already said, we don't have the hardware
to try."
Giving them Supermicro's phone number and who to talk to
did not help.
What you describe is not what they practice. Again,
this is open source and I can not afford the consulting.
This is my fault for choosing an Anti-Kaisen OS.
It is my fault for expecting a Blue Car to have
all four of its wheels attached and to expect it
to drive on modern roads. EL Linux was a really
bad choice for me to standardized on.
You are correct. I am not using EL Linux as it is intended.
|
