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