| 1 |
On Tue, Sep 27, 2011 at 10:43 AM, Michael Mol <mikemol@×××××.com> wrote: |
| 2 |
<SNIP> |
| 3 |
> |
| 4 |
> Because, in this case, the hardware, which is unreplaceable, went tits |
| 5 |
> up. Meaning it no longer works. It can't be replaced, and they're SOL |
| 6 |
> until they get the software ported forward. Their remaining hardware |
| 7 |
> of the same vintage had already died on them, and they didn't have any |
| 8 |
> migration path or hedge set up. |
| 9 |
> |
| 10 |
> Other reasons--and this is why I *loathe* unnuanced "if it works, |
| 11 |
> don't touch it" mentalities--include security updates and migration |
| 12 |
> difficulty in the event of *necessity* of upgrades. |
| 13 |
> |
| 14 |
|
| 15 |
I sympathize with the hardware dieing, but one could argue (IMHO |
| 16 |
anyway) that that is as much a management problem on their part, or |
| 17 |
those supporting them, as it is an issue with the kernel. If someone |
| 18 |
is running a system which is critical and isn't planing for how to get |
| 19 |
new copies of the system or move forward to new hardware over time, |
| 20 |
then they are painted into a corner. |
| 21 |
|
| 22 |
I can pretty much promise you that one area likely to get LOTS of |
| 23 |
attention in this kernel series IS security updates, at least if they |
| 24 |
are kernel based security issues. That a major reason, if not the #1 |
| 25 |
reason, that this series of kernels exists. |
| 26 |
|
| 27 |
HTH, |
| 28 |
Mark |
Archives