In this case, if for some reason git-core was broken in testing, I could easily upgrade it to the version from unstable with a command such as aptitude install -t unstable git-core. But if I installed git-core without the -t argument, the version from testing would have been chosen.
Yup, an external packet filter could be configured to drop all packets to/from a given IP address.
Determining what that IP address is, however, can be tricky. There are almost certainly multiple addresses used for this sort of thing, and they are probably different depending on which region you're in (wouldn't make sense for all the XP boxes in Germany to connect to the Japanese mirrors). The addresses in use will also change over time.
Best way to avoid this would be to block all traffic to/from the XP machines in question.:)
If the "firewall" is running on the Windows system in question, then there is no way to prevent the process doing the updating from hiding the fact from the firewall.
Oops, hit reply too soon...
This sounds like an excellent reason to avoid shitty vendors that release shitty products that rely on proprietary, GPL-violating kernel modules. And therefore, avoiding pretty much all enterprise software. Sorry, not an option in many cases. Oh, I agree the situation sucks, which is why I would like to see ALL binary modules to go away. I don't see how "pretty much all enterprise software" requires the use of proprietary binary kernel modules?
I actually meant like Debian, where backported security fixes usually do not change te kernel's ABI. If changing the ABI is unavoidable, then the package containing the kernel is renamed (e.g., linux-image-2.6.18-4-k7 -> linux-image-2.6.18-5-k7). Um, no. That's not how it works. Debian revs the package version number (the "4" to "5" in your example) for ALL changes, not just ABI changes. This is how the packing system knows that there is an update. Note that I said they change the package name, not the version.
Oh, you mean like RedHat Enterprise? So yeah, you go down that road, and happily install your binary kernel modules for EMC PowerPath (multi-pathing on a SAN.) Redhat comes out with a new kernel with the same version but with the backported fixes. I actually meant like Debian, where backported security fixes usually do not change te kernel's ABI. If changing the ABI is unavoidable, then the package containing the kernel is renamed (e.g., linux-image-2.6.18-4-k7 -> linux-image-2.6.18-5-k7).
Oh damn, that binary module no longer works, so I have to revert to the insecure version of the kernel if I want EMC branded and "psedo-supported" multi-pathing. EMC? What do you mean that you have no ETA for a new rev of powerpath that supports the new kernel rev? Note that this is a recurring problem. EMC NEVER supports a current point release of the OS, although sometimes you get lucky and the old module works with the new rev, although that seems to be rare. This sounds like an excellent reason to avoid shitty vendors that release shitty products that rely on proprietary, GPL-violating kernel modules.
Why would you need to keep the kernel current if you're using old hardware? If nothing else, for security fixes. That alone is a huge motivation. Not if you use a distribution that backports security fixes to the kernel present in their stable releases?
So home builders are holding their customer's hostage by requiring payment for services? No. If I contract a builder to perform some work, I would expect to pay him in exchange. However, if that builder died, or was too busy to take on new contracts, or went mad and stopped taking orders, I would be free to take my business elsewhere by finding another builder who will "hack on" my house.
Don't give me the whole "Software isn't the same, it's not tangible." Someone had to put time into it, and if they want to sell the result, they should be able to. RMS needs to get over his code jihad. Software is not the same, because the vendor usually restricts access to the blueprints (source code) without which are (for most practical purposes) necessary for the customer to modify the software.
Nonsense. If I were to take leave of my senses and decide to start running MySQL hosting service, I would be under no obligation to distribute the MySQL source code to anyone.
From what I can tell in many ways Torvalds stays with GPLv2 because it offers a compromise between openess of source code and a license that businesses can tolerate. This compromise is having open source running on otherwise closed software. GPLv3 would not permit this[citation needed] and therefore this would hurt the popularity of Linux, especially in th embedded arena.
Nobody uses the mysql_* functions anymore. Use database abstraction. PDO is the most common, though I really like the database stuff built into the new Zend Framework myself. Nonsense. Far too many projects still use the mysql (4.0! DEAR GOD WITHOUT EVEN PLACEHOLDERS IN QUERIES) module's functions. They can't use anything newer because it will break compatibility with most of their user base who are still using PHP 4.
Similarly we have the laughable register_globals situation; plenty of web applications written in PHP have "fixed" themselves to be compatible with installations where register_globals is turned off... by manually registering all GET, POST and cookie variables in the global namespace themselves...
Even if PHP grew a pair and obliterated php.ini altogether, making it secure by default in the process, the idiots who write web apps in it would still continue to manually open up huge security holes in this manner, rather than learn how to write code properly.
I guess because it would make everything more expensive. The consumer is the one who ultimately pays for our consumer protection laws, in the form of higher prices.
It really pisses me off how people whinge about "rip off Britain" and yet don't realise *ehy* it is that everything costs so much here.
Not a problem... the package build against libc 2.5 will depend upon it, so apt knows to upgrade libc6 too.
I'm sorry, which organisation?
You don't need to reinstall to create an encrypted filesystem for /home. That's Windowsthink!
Yup, an external packet filter could be configured to drop all packets to/from a given IP address.
:)
Determining what that IP address is, however, can be tricky. There are almost certainly multiple addresses used for this sort of thing, and they are probably different depending on which region you're in (wouldn't make sense for all the XP boxes in Germany to connect to the Japanese mirrors). The addresses in use will also change over time.
Best way to avoid this would be to block all traffic to/from the XP machines in question.
WU was still installed though.
If the "firewall" is running on the Windows system in question, then there is no way to prevent the process doing the updating from hiding the fact from the firewall.
And if you buy an all-Intel system then it will.
Hopefully these specs will mean the same thing for AMD/ATI systems some day.
I don't remember the G400 ever being competitive hardware.
Nonsense. If I were to take leave of my senses and decide to start running MySQL hosting service, I would be under no obligation to distribute the MySQL source code to anyone.
How intuitive! :)
Isn't that just another way of saying that you profit from holding your customers hostage to your proprietary software platform?
From what I can tell in many ways Torvalds stays with GPLv2 because it offers a compromise between openess of source code and a license that businesses can tolerate. This compromise is having open source running on otherwise closed software. GPLv3 would not permit this[citation needed] and therefore this would hurt the popularity of Linux, especially in th embedded arena.
Please show me where the new GPL prohibits commercial use of covered works?
Similarly we have the laughable register_globals situation; plenty of web applications written in PHP have "fixed" themselves to be compatible with installations where register_globals is turned off... by manually registering all GET, POST and cookie variables in the global namespace themselves
Even if PHP grew a pair and obliterated php.ini altogether, making it secure by default in the process, the idiots who write web apps in it would still continue to manually open up huge security holes in this manner, rather than learn how to write code properly.
I guess because it would make everything more expensive. The consumer is the one who ultimately pays for our consumer protection laws, in the form of higher prices.
It really pisses me off how people whinge about "rip off Britain" and yet don't realise *ehy* it is that everything costs so much here.
Please cite these alleged copyright violations!
But this feature seems to have been implemented back in February 2005.
Use the -I option.