Possible Spam: Re: OSMA 5 on Fedora Core 4
Patrick_Boyd at Dell.com
Patrick_Boyd at Dell.com
Thu Sep 7 08:46:33 CDT 2006
Robert,
To be perfectly honest I don't know what the motivation was. It may have been to reduce the possibility of litigation, however I like to think it was just to protect customers systems and data from potential problems of using untested software/hardware combinations just for the sake of doing what we feel is right for our customers.
Patrick Boyd
-----Original Message-----
From: linux-poweredge-bounces at dell.com on behalf of Robert Ham
Sent: Thu 9/7/2006 2:35 AM
To: Boyd, Patrick
Cc: linux-poweredge-Lists
Subject: RE: Possible Spam: Re: OSMA 5 on Fedora Core 4
Patrick,
OK, we'll have to agree to disagree. The decision has been made and it won't be changed. However, I'm still interested in *why* the decision was made; for my own understanding of the motivations that gave rise to the software that we won't argue about.
You said that performing a reconfigure on a PERC 2 can "cause data loss" under certain circumstances. What do you, exactly, by "data loss"? A full system lock up, or something less catastrophic?
Following on from my previous email, I'm still interested in understanding why you've taken responsibility for protecting your customers. Is it because of the risk of litigation if the software fails?
Regards,
Robert
--
Robert_Ham at bristol-city.gov.uk
0117 92 22494
Analyst Programmer
Children and Young People's Services IT
Bristol City Council
>>> <Patrick_Boyd at Dell.com> 06/09/2006 16:43:07 >>>
First off OMSA installs itself as 3 services that start at boot.
Therefore OMSA is always running regardless of if the user does anything
or not. That is why an untested software/hardware combination that were
not designed to work together can cause system instability.
>You claim your intent was to "stop users from getting themselves into a
state where they could cause more harm than good".
We haven't tested or designed for the software in this state. We don't
know what the user could do to hurt themselves. But as an example, newer
OMSA code attempting to perform a reconfigure on a PERC 2 can cause data
loss under certain circumstances. That's a good enough reason for me to
try and stop users from using OMSA on a system that supports PERC 2.
We could argue this design decision until we are blue in the face. We
just need to accept that this is the design. You may believe it to be
incorrect while I believe that it is correct. That's the way software
design is sometimes, you can't be 100% correct according to everyone. So
in this case we've done what we feel is right to protect our customers,
and I'm sorry that you feel this wasn't the correct action, but I
believe we must just agree to disagree.
Patrick Boyd
Dell Storage Software Engineer
(512)728-3182
-----Original Message-----
From: Robert Ham [mailto:robert_ham at bristol-city.gov.uk]
Sent: Wednesday, September 06, 2006 10:23 AM
To: Boyd, Patrick
Cc: Brown, Michael E; linux-poweredge-Lists
Subject: RE: Possible Spam: Re: OSMA 5 on Fedora Core 4
Patrick,
How will installing the software cause system instability? Surely
executing the software is what jeopardises stability, not installation?
And on that, how exactly can OSMA cause instability? What is the
problem that these RPM installation scripts were intended to solve?
You claim your intent was to "stop users from getting themselves into a
state where they could cause more harm than good". Firstly, what kind
of harm are you talking about? And secondly, why are you taking on this
responsibility? Why not just write the software and package it
normally? One of the consequences of your intent is that you have
restricted the use of your software in a most unhelpful way.
"Why even install software if its not going to work?" Good question.
But assuming that the answer will always be "no" is.. an assumption.
And a bad one; there have been many instances where I have wanted to
install a software package without the intent of using it. Generally
for the purposes of getting myself out of a sticky situation.
Robert
--
Robert_Ham at bristol-city.gov.uk
0117 92 22494
Analyst Programmer
Children and Young People's Services IT
Bristol City Council
>>> <Patrick_Boyd at Dell.com> 06/09/2006 15:15:29 >>>
During the install design we decided to do whatever checks we could on
the hardware to prevent OMSA from causing system instability. On windows
this meant a full requirements checker that checks firmware, BIOS,
drivers, and system type. On linux we had to settle for system type
since we couldn't get some of this information reliably. The intent of
this was to stop users from getting themselves into a state where they
could cause more harm than good to their systems and install time checks
were determined to be the easiest method of ensuring this protection.
Why even install software if its not going to work?
I'm sorry that you do not agree with the decision but that is our
install method. It's intent was not to punish people, but to protect
people.
Patrick Boyd
Dell Storage Software Engineer
(512)728-3182
-----Original Message-----
From: linux-poweredge-bounces at dell.com
[mailto:linux-poweredge-bounces at dell.com] On Behalf Of Robert Ham
Sent: Wednesday, September 06, 2006 8:44 AM
To: BSmith at lyrix.com
Cc: Brown, Michael E; linux-poweredge-Lists
Subject: Re: Possible Spam: Re: OSMA 5 on Fedora Core 4
Brian,
Firstly, I'm afraid you're wrong. The pre-installation scripts are not
intended for dependency checking. From
http://www.rpm.org/RPM-HOWTO/build.html#SCRIPTS :
6.7. Optional pre and post Install/Uninstall Scripts
You can put scripts in that get run before and after the installation
and uninstallation of binary packages. A main reason for this is to do
things like run ldconfig after installing or removing packages that
contain shared libraries.
Secondly, yes, Dell has every right to package their software any way
they see fit. Similarly, I have the right to point out how badly
they've done it and suggest improvements.
Thirdly, I notice you said " They chose RPM ... for the package to
verify that the system you are installing on is in fact supported by
Dell." You meant 'the software', didn't you? You meant: verify that
the system is supported by 'the software', right? You weren't talking
about Dell support contracts were you? Were you?
Finally, though it may seem as though I want the contents of
srvadmin-deng-5.0.0-463.i386.rpm, I do not (it won't work with my
hardware, see?) I just want peace, harmony, and well written software.
Robert
--
Robert_Ham at bristol-city.gov.uk
0117 92 22494
Analyst Programmer
Children and Young People's Services IT
Bristol City Council
>>> <BSmith at lyrix.com> 06/09/2006 13:51:01 >>>
The job of RPM is to allow software designers and package maintainers to
support the installation of their packages. Built-in to RPM is the
facility to check that all pre-prequisites have been met. This is why
you
cannot install an rpm designed for a different architecture and cannot
install an rpm that requires libraries that you don't have installed (or
the proper version). RPM supports %pre and %post scripts in order to
allow the software developers and package maintainers to perform
additional
operations and checks of the system both before and after package
installation. This is what the scripts are supposed to do. Dell has
every right to package their software any way they see fit in order to
support their hardware. They chose RPM, and RPM supports the ability
for
the package to verify that the system you are installing on is in fact
supported by Dell.
Since I assume you've already tried the RPM options --nodeps and/or
--force
and/or --noscripts options to RPM and you are so intent on installing
the
package on your unsupported system, then use rpm2cpio to get a cpio dump
and have at it. Then it's just a dumb archive of files, which is
seemingly all you want.
- Brian
"Robert Ham"
<robert_ham at bristol-ci To:
<colin.schuster at gmail.com>
ty.gov.uk> cc:
Michael_E_Brown at dell.com, linux-poweredge at lists.us.dell.com
Sent by: Subject: Possible
Spam: Re: OSMA 5 on Fedora Core 4
linux-poweredge-bounce
s at dell.com
09/06/2006 05:52 AM
Should we remove /sbin/shutdown? That can bring the machine down. Or
all
of /usr/bin/*? They can cause core dumps. Saying that an RPM should
refuse to install because it the software it contains might be decrease
stability is ludicrous. The responsibility of deciding whether to
install
the software lies on the shoulders of the administrator, and they have
already made that decision when the RPM is installed. We know this
because
they're installing the RPM! For the RPM scripts to then turn around and
say "I'm sorry, but the responsibility to administer this machine is
mine.
I will stop now, regardless of what you have asked me to do" is beyond
absurd.
You, in fact, cannot argue that the purpose of RPM is to *prevent* me
from
installing software, regardless of whether or not the software is deemed
by
the RPM authors, or anyone else, as "dangerous" in whatever
circumstances.
The purpose of RPM is to *enable* me to install software. The purpose
of
the scripts in an RPM is to DO WHAT THEY ARE TOLD and not WHAT THEY
THINK I
WANT. For an RPM script to second guess an administrator is an insult,
and
the insult comes from the RPM packagers. In this case, that is Dell. I
would like them to answer for themselves.
Robert
--
Robert_Ham at bristol-city.gov.uk
0117 92 22494
Analyst Programmer
Children and Young People's Services IT
Bristol City Council
>>> "Colin Schuster" <colin.schuster at gmail.com> 06/09/2006 10:28:58 >>>
One could argue the purpose of RPM is also to do these types of checks
in
order to prevent you from installing software that might do more harm
than
good on a particular machine - like cause a core dump and bring the
machine
down.
> I don't understand how the fact that the software will not do
> anything useful on my particular hardware has resulted in an RPM which
> throws up an error when there is no problem installing the RPM into
the
> filesystem. That's the purpose of the RPM; not to try and determine
whether
> the software in it will work. The software will do that itself.
There's
no
> logic to this, unless I'm missing something. Am I missing something?
>
_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge at dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq
_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge at dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq
_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge at dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq
More information about the Linux-PowerEdge
mailing list