I know more than one person who felt that they wanted to install _everything_ on their workstation machine, so they wouldn't have a problem loading it on later if they wanted it later.
One person actually started digging around researching how to get into the DNS with his spiffy new named. Not because he needed it, but because the "everything" install included it, and he assumed, in his newbieness, that he needed to use it.
I'm somewhat tempted to do the same thing, but I don't. For example, if I installed a server machine without a news server, and later decided I wanted to make it a news server, you no longer have that slick GUI to load it in for you, you have to rpm and stuff. It's natural, under those circumstances, to be tempted to load in the news server just in case you might want it later.
Upgrades that occur in a timely fashion?! How about really, incredibly way too frequent!
I don't know about Suse and Caldera, but Redhat has been releasing so !@#$ frequently that our patch maintenance costs are much higher for redhat than for sun, dec or sgi - and that's not even accounting for the fact that we have far more suns than redhat machines!
What's more, redhat has been ceasing to release new patches for some of these myriad os versions pretty quickly, leaving critical production machines orphaned with regard to patches.
We've had to say "sorry, we'll only support the last minor within a given major" (EG: 4.2, 5.2, but not 5.0 or 5.1 or 6.0), to contend with the overexuberant release schedule and lack of matching patch schedule. (patches for the last minor within a major are provided for much longer)
Please, please, please, redhat: take a hint from the other vendors and Fred Brooks. Way frequent releases bad, more significant infrequent releases good.
If you want a production track and a development track, that's different. But so far, I don't see any such distinction in redhat's versioning system aside from the betas. It's good to stick to the last minor within a major (although our clients hate it, and may come to hate us as a result:( ), but as far as I can tell we don't even know if 6.2 will be the last of the 6.x's until 7.0 beta is announced - so we end up waiting an additional n months before we know if we can adopt 6.2.
Hopefully I'm reading too much into this, but the announcement seems to make it sound like you're only welcome to attack microsoft's controlled target machine, not even your own machines. This almost sounds like a ploy to make UCITA sound more palatable, but having a single MS-blessed target machine is no substitute from being able to test on your own machines and publish the results!
Hopefully I'm reading too much into this, but the announcement seems to make it sound like you're only welcome to attack microsoft's controlled target machine, not even your own machines. This almost sounds like a ploy to make UCITA sound more palatable, but having a single MS-blessed target machine is no substitute from being able to test on your own machines and publish the results!
I've gotta agree, nothing appears to have changed.
I just got off the phone with E*Trade. They took my application over the phone, I answered the questions honestly, and they told me I wasn't considered suitable for the IPO.
Surely this isn't what Redhat had in mind? Didn't they -want- the small investor to have a chance to get in on this?
Slashdot Mirror
Linux is Linux?
Not in security patch administration it isn't. There things are already quite fragmented.
Don't get me wrong, I don't want to see fragmentation, but I'm not going to pretend it doesn't exist if it does, either.
I don't really agree.
I know more than one person who felt that they
wanted to install _everything_ on their workstation machine, so they wouldn't have a problem loading it on later if they wanted it later.
One person actually started digging around researching how to get into the DNS with his spiffy new named. Not because he needed it, but because the "everything" install included it, and he assumed, in his newbieness, that he needed to use it.
I'm somewhat tempted to do the same thing, but I don't. For example, if I installed a server machine without a news server, and later decided I wanted to make it a news server, you no longer have that slick GUI to load it in for you, you have to rpm and stuff. It's natural, under those circumstances, to be tempted to load in the news server just in case you might want it later.
Upgrades that occur in a timely fashion?! How about really, incredibly way too frequent!
I don't know about Suse and Caldera, but Redhat has been releasing so !@#$ frequently that our patch maintenance costs are much higher for redhat than for sun, dec or sgi - and that's not even accounting for the fact that we have far more suns than redhat machines!
What's more, redhat has been ceasing to release new patches for some of these myriad os versions pretty quickly, leaving critical production machines orphaned with regard to patches.
We've had to say "sorry, we'll only support the last minor within a given major" (EG: 4.2, 5.2, but not 5.0 or 5.1 or 6.0), to contend with the overexuberant release schedule and lack of matching patch schedule. (patches for the last minor within a major are provided for much longer)
Please, please, please, redhat: take a hint from the other vendors and Fred Brooks. Way frequent releases bad, more significant infrequent releases good.
If you want a production track and a development track, that's different. But so far, I don't see any such distinction in redhat's versioning system aside from the betas. It's good to stick to the last minor within a major (although our clients hate it, and may come to hate us as a result
Is there any software that will take a
compressed gif as input, and produced an
uncompressed gif as output?
How about software that will take a compressed
gif as input, and produce an RLE-gif as output?
Has anyone determined for certain if RLE gif's
are legal? The GD maintainer seems to be
concerned that they may not be.
Hopefully I'm reading too much into this, but the
announcement seems to make it sound like you're
only welcome to attack microsoft's controlled
target machine, not even your own machines. This
almost sounds like a ploy to make UCITA sound
more palatable, but having a single MS-blessed
target machine is no substitute from being able to
test on your own machines and publish the results!
More info about UCITA here.
Hopefully I'm reading too much into this, but the
announcement seems to make it sound like you're
only welcome to attack microsoft's controlled
target machine, not even your own machines. This
almost sounds like a ploy to make UCITA sound
more palatable, but having a single MS-blessed
target machine is no substitute from being able to test on your own machines and publish the results!
More info about UCITA here.
I've gotta agree, nothing appears to have changed.
I just got off the phone with E*Trade. They took
my application over the phone, I answered the
questions honestly, and they told me I
wasn't considered suitable for the IPO.
Surely this isn't what Redhat had in mind? Didn't they -want- the small investor to have a chance
to get in on this?