RHEL, kernel vulnerabilities, and days of risk

RHEL, kernel vulnerabilities, and days of risk

Posted Mar 23, 2005 21:53 UTC (Wed) by dang (guest, #310)
Parent article: RHEL, kernel vulnerabilities, and days of risk

I am sure that the stability issue is a consideration, and it may be that any vendor is slightly screwed here.

Because this RHEL is targeted in part to backend DB tasks, there will be pressure to test long and hard before an rpm is revved. This is partly because there is zero room for problems on your platform db and partly because your friendly neighborhood DBA doesn't care so much about these types of bugs: If your db box is on a routable network or if you have users on the system you are already and always pooched. So if you want to rev an rpm on a DB box, you had better be damn sure that you mess nothing up because the cost/benefit for these types of changes aren't worth the cost of even a DB hiccup.

On the other hand, RHEL is also targeted to boxes with at least 80 and 443 public facing ( typically because you need or want certification for the client that connects to your backend db ), and here the pressure is different. Sysadmins for public facing boxes differ in their paranoia than do friendly neighborhood DBAs; they want these things fixed *now*. Then again, they usually have a lot of wiggle room to grab patches or patched SRPMS that are made available through other channels, so they don't necessarily have to wait.

I think any Enterprise distro is going to struggle a bit with these divergent pressures and will have to choose whether to offically release early ( and run the risk of DBAs bailing on updates ) or release later ( and have DBAs more comfortable with updates but have sysadmins a bit more skittery ). Ultimately I'm not sure that it matters as long as the notices go out and the fixes are available somewhere. The marketing weasels will always be there to spin things, though. That is the tricky part.

---

(Log in to post comments)