Suppose that some commercial development tool requires gcc-3.0.1 or above.
They make an RPM. What should they require? "gcc >= 3.0.1"? Wrong. A user of RedHat 7.2 can have gcc-2.96 and gcc3-3.0.4. Maybe "gcc3 >= 3.0.1". Nope. RedHat 8.0 will have gcc-3.1 (maybe even gcc-3.2) and no gcc3 package.
Handling of incompatible versions of the same software is done ad hoc, without any strictly established and well designed rules. Either the old or the new version gets a number appended to the package name (glib10, kde2, gcc3).
And which kernel should it be? What if I want some feature (e.g. smbfs support) and Microsoft only signs the kernel without it? There are thousands of different configurations, and it's unreasonable to ask anybody, even Microsoft, to sign all of them.
However, only Mozilla project uses this name to promote the project.
Others simply state that they are compatible with Mozilla.
Netscape could have gone after them, but they didn't.
Now if AOL loses the Mozilla trademark, it will be a very
interesting question whether Microsoft and others will have
to drop "Mozilla compatible" from their browsers.
Basically, if you steal and give away stolen goods, those who get those
goods have to return them. I wonder if it applies to trademarks.
What if the new habitants adapt to extreme cold, populate the polar areas and lock the vital resources (water, CO2) on the poles, and thus hinder further attempt to redistribute those resources closer to the equator, where the climat is more palatable to humans?
If you nuke a polar cap with CO2, you could get more CO2 in the air. If you nuke a polar cap covered by lichens, you could end up with carbon dust on the poles and CO in the air.
Well, obviously, if the government cannot influence the company
within a reasonable timeframe, then the vulnerability should be disclosed.
If I wasn't living in the United States, perhaps I would try this
tactic at least once to give the US government benefit of doubt.
If they fail, then no need to try it again. If they actually force
the company to make the patch, it may be a good thing.
Shouldn't we report the su exploit in Tru64 to the US government now?
Like "a company in your country is making unsafe software and refuses
to fix it, please consider if you still want to buy their software
for the government and the military".
Well, let's say you are building a spaceship and you require software that was satisfies certain conditions, e.g. the testing time needs to be at least 5 times more than the coding time, and every function needs to be unit tested. In addition, you require logs confirming that the testing has indeed taken place. I'm pretty sure that none of the companies you mentioned would try to sell the the products they are selling on the consumer market.
Does it mean that you should give up and buy the database for your spaceship in CompUSA? It depends on the risk. It a single failure can be fatal for the mission, you really should try to find a company that would satisfy your requirements, even if it would cost much more than the off-the-shelf products.
Now, we are talking about the government of Peru (if you don't know that, shut up and read the article). If the government cannot do its job, much more people are going to be hurt than if a spaceship explodes. It's pretty reasonable for the government of Peru to set requirements that most off-the-shelf software would not satisfy.
CVS uses [kgnp]server (Kerberos, GSSAPI, NTLM, Password)
as its communication
protocol. It's not even encrypted.
Oh, yes, very "informative".
From cvs.info (Direct connection with GSSAPI):
The data transmitted is _not_ encrypted by default. Encryption
support must be compiled into both the client and the server; use the
`--enable-encrypt' configure option to turn it on. You must then use
the `-x' global option to request encryption.
My understanding is that the JPL come with a way to calculate gravitational effects with more precision, thus saving fuel required to correct the orbit. Hardly anything exciting, but it became the "planet freeway" in the journalist's imagination. Another uninformed, overhyped article on CNN, not to mention the "Artist's concept of interplanetary superhighway", apparently not reviewed by any knowlegeable person.
The reference to "dark matter" makes no sence to anybody ever studied general relativity. External gravitational field doesn't vary significantly in the Solar system, therefore it's irrelevant. Even if we all accelerate in the gravitational field of some dark matter, we do it uniformly.
This doesn't change virtual resolution. Having virtual resolution different from physical resolution is quite inconvenient, especially if you have a taskbar or panel that you don't want to disappear from the screen simply when you move your mouse.
What if we take another approach? When stable kernels were released in the past, they were not tested enough to be called stable. Hordes of new users would find hundreds of bugs, and the developers had to fix them instead of doing new development.
Would starting the new development branch immediately after the stable release help? Hardly. It's the time when a lot of work has to be done on the stable branch.
But what if we make sure that the stable kernel is indeed stable when it's released, not after the "stabilization"? The only solution to make kernel stable is to test it a lot before it's released.
I don't think we should be afraid of "debian syndrome". Kernel is much more monolithic than a disribution, and if e.g. IDE doesn't work well, it takes much more efforts to downgrade it safely compared to downgrading e.g. Mozilla.
The fundamental problem with the development branch is that issues with one part of the kernel affect all developers and testers. If I e.g. want to test ACPI and know how to fix it, but I don't know how to fix IDE, I won't test the latest 2.5 kernel.
I believe that the best solution would be to have branches for different subsystems. IDE changes would be merged to the trunk only when they are stable enough for other developers. It's important that the development on the branches is done openly, step by step, so that an interested developer could find the exact place where a bug was introduced. But this style of development doesn't require doing everything in the trunk. In fact, to keep the kernel relatively stable the development should be done on specialized branches.
More stable development kernel would mean more testers. More testers would mean stable release, which is truly stable, at least compared to 2.2.0 and 2.4.0. And that would eliminate the need to force developers on stabilizing the branch that is supposed to be stable form the beginning.
I have a depressing feeling that my body is less secure than old Outlook Express, yet I cannot upgrade it. Until we have a patch, the vulnerability should not be disclosed:-)
RedHat has a policy that all their packages must be compiled by RedHat without manual intervention in some controlled build environment, which only uses RedHat packages. An exception is made for closed-source projects, such as Netscape (they are reassembled into packages without compilation), but not for open source projects. One of the reasons why RedHat doesn't ship OpenOffice is because building it requires Sun JDK, which is not a part of RedHat Linux.
As far as I know, the Linux kernel itself doesn't have to pass a compile test with maximum features enabled to be released. This is bad and should be fixed.
This is true for any version of the kernel. If you have a kernel without sound support, you have to recompile the kernel to get sound.
Modules solve this problem only in part.
Compiling new modules for the old kernel usually works, but is not guaranteed to work. In particular, NFS client support cannot be added witout reboot.
Slashdot Mirror
Then they should rename USS Jimmy Carter to USS Richard Nixon or maybe USS Deep Throat :-)
Handling of incompatible versions of the same software is done ad hoc, without any strictly established and well designed rules. Either the old or the new version gets a number appended to the package name (glib10, kde2, gcc3).
And which kernel should it be? What if I want some feature (e.g. smbfs support) and Microsoft only signs the kernel without it? There are thousands of different configurations, and it's unreasonable to ask anybody, even Microsoft, to sign all of them.
That should be makemuchmuchshorteruniversalresourcelocator.com
Strange that you don't realize that the lack of a standard is a problem.
Basically, if you steal and give away stolen goods, those who get those goods have to return them. I wonder if it applies to trademarks.
Where do you want to go toady? Don't you trust the readers to decide?
If you nuke a polar cap with CO2, you could get more CO2 in the air. If you nuke a polar cap covered by lichens, you could end up with carbon dust on the poles and CO in the air.
Have you considered the fact that "the roving prison" doesn't have to be on the equator? You should be ashamed :-)
The guy was so in hurry to post it, that he even misspelled "crackers".
Just because you grew up on a farm in Iowa, it doesn't mean you shouldn't know how to spell field, yield and relative.
If I wasn't living in the United States, perhaps I would try this tactic at least once to give the US government benefit of doubt. If they fail, then no need to try it again. If they actually force the company to make the patch, it may be a good thing.
Shouldn't we report the su exploit in Tru64 to the US government now? Like "a company in your country is making unsafe software and refuses to fix it, please consider if you still want to buy their software for the government and the military".
There are other ways to become root, e.g. ssh root@localhost with private key authentication.
Does it mean that you should give up and buy the database for your spaceship in CompUSA? It depends on the risk. It a single failure can be fatal for the mission, you really should try to find a company that would satisfy your requirements, even if it would cost much more than the off-the-shelf products.
Now, we are talking about the government of Peru (if you don't know that, shut up and read the article). If the government cannot do its job, much more people are going to be hurt than if a spaceship explodes. It's pretty reasonable for the government of Peru to set requirements that most off-the-shelf software would not satisfy.
Lord ARCHer
From cvs.info (Direct connection with GSSAPI):
The data transmitted is _not_ encrypted by default. Encryption support must be compiled into both the client and the server; use the `--enable-encrypt' configure option to turn it on. You must then use the `-x' global option to request encryption.
The reference to "dark matter" makes no sence to anybody ever studied general relativity. External gravitational field doesn't vary significantly in the Solar system, therefore it's irrelevant. Even if we all accelerate in the gravitational field of some dark matter, we do it uniformly.
This doesn't change virtual resolution. Having virtual resolution different from physical resolution is quite inconvenient, especially if you have a taskbar or panel that you don't want to disappear from the screen simply when you move your mouse.
Would starting the new development branch immediately after the stable release help? Hardly. It's the time when a lot of work has to be done on the stable branch.
But what if we make sure that the stable kernel is indeed stable when it's released, not after the "stabilization"? The only solution to make kernel stable is to test it a lot before it's released.
I don't think we should be afraid of "debian syndrome". Kernel is much more monolithic than a disribution, and if e.g. IDE doesn't work well, it takes much more efforts to downgrade it safely compared to downgrading e.g. Mozilla.
The fundamental problem with the development branch is that issues with one part of the kernel affect all developers and testers. If I e.g. want to test ACPI and know how to fix it, but I don't know how to fix IDE, I won't test the latest 2.5 kernel.
I believe that the best solution would be to have branches for different subsystems. IDE changes would be merged to the trunk only when they are stable enough for other developers. It's important that the development on the branches is done openly, step by step, so that an interested developer could find the exact place where a bug was introduced. But this style of development doesn't require doing everything in the trunk. In fact, to keep the kernel relatively stable the development should be done on specialized branches.
More stable development kernel would mean more testers. More testers would mean stable release, which is truly stable, at least compared to 2.2.0 and 2.4.0. And that would eliminate the need to force developers on stabilizing the branch that is supposed to be stable form the beginning.
I have a depressing feeling that my body is less secure than old Outlook Express, yet I cannot upgrade it. Until we have a patch, the vulnerability should not be disclosed :-)
As far as I know, the Linux kernel itself doesn't have to pass a compile test with maximum features enabled to be released. This is bad and should be fixed.
Modules solve this problem only in part. Compiling new modules for the old kernel usually works, but is not guaranteed to work. In particular, NFS client support cannot be added witout reboot.