when startup delays become bugs (dmraid)
przemek.klosowski at nist.gov
Mon May 20 21:27:48 UTC 2013
On 05/18/2013 05:17 AM, Nicolas Mailhot wrote:
> Le Sam 18 mai 2013 05:39, T.C. Hollingsworth a écrit :
>> On Fri, May 17, 2013 at 7:34 PM, Adam Williamson <awilliam at redhat.com>
>>> You could transfer the install to a system which contains a dmraid
>>> array, or add a dmraid array to an existing install (I think this thread
>>> has been considering only the case of the installed system itself being
>>> on the RAID array). Of course, the case where the installed system is
>>> not on the RAID array is much less 'urgent' - your system doesn't stop
>>> working, you just have to figure out you need to enable the service /
>>> install the tool in order to see the array.
>> Yeah, but you'd need to do some manual configuration there anyway.
>> Adding `yum install dmraid` to that isn't really a massive burden.
> That's really a terrible argument. It's why you get so many one thousand
> paper cut moments in IT nowadays.
IT failures tend to be either because the design is too simplistic or
too complex. Windows is in the first category: it only works in the
specific hardware configuration it was originally installed---although I
suspect that it's a deliberate choice to prevent illegal mass cloning,
rather than inability to make it more portable.
Of course Linux has built-in drivers for most popular chipsets so it
tends to boot on any hardware you put it on, at least in a basic mode.
I am quite happy with that---it allows me to do what I need to, in an
incremental way, rather than telling me that I am SOL and should have
started with a 'sysprep' but it's too late now.
I would say let's count our blessings and not expect that every possible
combination of hardware components will be supported in an optimal way.
Just as long as the whole thing reliably comes up, I'd be happy.
More information about the devel