As a former DoD Linux admin (one of the first for that organization), the best way I've found to keep everything in sync is to build updates yourself (essentially, you're doing the vendors work for them). I know of the guidelines you speak of and the regular advisories and it was quite a task to implement something reasonable. In the end though, the only way I could both satisfy both the security concerns and maintain the rpm database integrity was to build updated versions of the vulnerable software myself and install them.
`rpmbuild` is definitely your friend. Build a template spec, then as you need to update versions, you just modify a few details and away you go.
I worked primarily with Red Hat at the time (though I am working with SuSE now) and had the same problems you've described. They (the vendors) typically do not update quickly enough and if you ask them for direct support, you usually get the run around. The "minimum" version issue is particular painful, as it will show up, even if the vendor backports (I'm assuming you're catching these when running the "unix" scan util).
So long as the updated rpm "provides" everything the old version did, you should have no dependency issues. Good luck.
Careers do not cause marriages to fail. An individual's failure to recognize that the career is impacting the relationship, may be a contributing factor. Both husband and wife (regardless of who's in IT) have to take responsibility. If one feels they are being neglected because the job is consuming the other, then the neglected must communicate that to the consumed, and together they must solve the problem.
I don't object to the OP's thought's, but IT is not much different than being a Doctor or a lawyer (or any other job that may have to deal with after hours commitements). If both parties want the relationship to work, then it will (with perhaps a few extraordinary exceptions). Just an opinion.
I agree, it seems silly. But if you consider some Japanese companies, they plan as far as 100 years out in some cases. Fundamentally, it's not a stupid idea, but in todays market, I'm not sure that most of these companies will be able to survive for that amount of time. This could simply be a ploy on Verisigns part to get more money out of it's customers... who knows.
Well, I think articles like that shouldn't be taken at face value. The author is simply (in my eyes) pointing out characteristics being displayed by Tivo, Inc. and drawing conclusions. Of course, as you point at, news isn't new unless it's heart stopping news. I think Tivo will be around for many more years. But... if they don't adapt, then like all things, their market may dry up as people opt for cheaper more integrated solutions.
No, I dont. This _is_ a form of control on the part of M$ that is unparalleled in todays world. I cant think of any other situation where a software vendor has explicitly told me that I must curtail my content if I speak badly about them. Now, they do have the right not to allow the logo (copyright) to be displayed (assuming the logo is not public domain). But that's not how it's stated. M$ would have been better off saying "you must contact us to use the Front page logo on your web pages". The way it's stated (I think) infringes on the users freedom of expression (idealistically of course).
Slashdot Mirror
As a former DoD Linux admin (one of the first for that organization), the best way I've found to keep everything in sync is to build updates yourself (essentially, you're doing the vendors work for them). I know of the guidelines you speak of and the regular advisories and it was quite a task to implement something reasonable. In the end though, the only way I could both satisfy both the security concerns and maintain the rpm database integrity was to build updated versions of the vulnerable software myself and install them.
`rpmbuild` is definitely your friend. Build a template spec, then as you need to update versions, you just modify a few details and away you go.
I worked primarily with Red Hat at the time (though I am working with SuSE now) and had the same problems you've described. They (the vendors) typically do not update quickly enough and if you ask them for direct support, you usually get the run around. The "minimum" version issue is particular painful, as it will show up, even if the vendor backports (I'm assuming you're catching these when running the "unix" scan util).
So long as the updated rpm "provides" everything the old version did, you should have no dependency issues. Good luck.
Careers do not cause marriages to fail. An individual's failure to recognize that the career is impacting the relationship, may be a contributing factor. Both husband and wife (regardless of who's in IT) have to take responsibility. If one feels they are being neglected because the job is consuming the other, then the neglected must communicate that to the consumed, and together they must solve the problem.
I don't object to the OP's thought's, but IT is not much different than being a Doctor or a lawyer (or any other job that may have to deal with after hours commitements). If both parties want the relationship to work, then it will (with perhaps a few extraordinary exceptions). Just an opinion.
I agree, it seems silly. But if you consider some Japanese companies, they plan as far as 100 years out in some cases. Fundamentally, it's not a stupid idea, but in todays market, I'm not sure that most of these companies will be able to survive for that amount of time. This could simply be a ploy on Verisigns part to get more money out of it's customers... who knows.
Well, I think articles like that shouldn't be taken at face value. The author is simply (in my eyes) pointing out characteristics being displayed by Tivo, Inc. and drawing conclusions. Of course, as you point at, news isn't new unless it's heart stopping news. I think Tivo will be around for many more years. But... if they don't adapt, then like all things, their market may dry up as people opt for cheaper more integrated solutions.
No, I dont. This _is_ a form of control on the part of M$ that is unparalleled in todays world. I cant think of any other situation where a software vendor has explicitly told me that I must curtail my content if I speak badly about them. Now, they do have the right not to allow the logo (copyright) to be displayed (assuming the logo is not public domain). But that's not how it's stated. M$ would have been better off saying "you must contact us to use the Front page logo on your web pages". The way it's stated (I think) infringes on the users freedom of expression (idealistically of course).