That's great for people who use the service strictly for network access. But for folks who use the ISP's other services (like email, news, and possibly even web hosting) are likely to find that none of the ISP's servers are visible when not using the ISP's DNS servers from inside the ISP's network. I know this is true for RoadRunner, because I tried exactly what you said, only to find that only RR's DNS knows about their email or news servers, for example.
The only real solution is to run a local caching-only DNS server, and set it up so that all queries except ".rr.com" domains go out normally, while sending queries for ".rr.com" to their servers.
Since there are quite a few free (either open or closed source) caching DNS servers for almost every OS, there really isn't a reason why everybody doesn't run a caching server anyway.
RH is only distro I have ever tried - and I tried many of them - would silently without any warning or prompt replace your config files with shipped version.
First, it doesn't do this without any warning...the output of rpm (which does the actual install) is forward to yum, or rhn, or whatever is running the "figure out everything I need and get it" process, and that is displayed to you when you are applying the patch. It clearly states in that output what happened with the file.
Second, for some updates (particularly security updates like this one), it is appropriate to save the old config file and load a default one, especially if that default one helps provide more security. Then, the admin can figure out what parts of the new default should be applied to their config, merge everything together, and restart the service.
These are the kinds of procedures that good admins do when they make changes to the system in any way.
Besides, if you read what I wrote, I have two perfect and beautiful children. So I gotta be doing something right. (Actually? They're not perfect but they are beautiful only 'cause they got that from my ex wife. They are, actully, really really well behaved and excel scholastically.)
I'm really sorry to break this to you, but this means nothing. I'm not knocking your kids or anything, because they may be really great and may end up turning out to be really great adults, but at 7 and 9 their "state" isn't always indicative of what they will turn out to be.
Case in point...a friend of mine had a very authoritarian and over-protective father, and although he was the great student, well-behaved generally (especially compared to some of the friends he had at the time), that strict lockdown authority left him pretty messed up, and he's been in and out of therapy for years now. And, if you had asked his father, he would have responded pretty much like you do about your kids, at least when they were 7-9 years old (later, maybe not as much).
Again, I'm not saying that this is the way your family is, but it's just something to think about.
Actually, I'd say exactly the opposite. SSL is used only on a fraction of the net, and in many cases, for many uses, self-signed certificates are as trustworthy as the CA's. Overall, I'd say that's not working.
SSL "doesn't work"? I guess I missed the articles on/. about Amazon, Google, eBay, PayPal, and every bank having issues with users not being able to connect to their secure servers, or with certificates showing up as not trusted, and the half-dozen impersonation attacks every week.
Like I said, there are definitely some problems that have happened, but overall the SSL certificate infrastructure is doing the job.
For any system to work and get widely deployed it has to be built on end-to-end, without a third party, trust. Each site has to be in control of their own keys and not dependent on someone elses good will and business.
How, exactly, do you purpose to do this with DNS? When you do a lookup on "example.com" for the first time, how do you check the signature if you don't have the public key? And, how do you get the public key in a trustworthy way without a third party?
Now, figure a way to make this scale so that it doesn't end up with IT administrators saying things like "Amazon, Google, and Microsoft are OK, but you can't view any other web pages because we don't have their DNS keys yet". Can you imagine if everyone who wanted to purchase at Amazon had to go to Seattle to pick up the Amazon SSL cert in person before they could create a secure, trusted connection? Because that's what would happen if Amazon used a self-signed cert and people wanted to be truly sure they were connecting to the real Amazon.
Part of the power of the Internet is that J. Random Blogger can put up some information on his personal domain that is exactly what you needed to know to get your install of Foobastic 2.4.12 to work with your hardware. Any secure DNS system that doesn't allow you to find that domain securely without any extra work on your part just isn't a viable solution.
Secure DNS makes this kind of impersonation impossible
Mmm, no. It makes this kind of impersonation possible by anyone who can coerce/corrupt/control some part of the chain of trust.
I think a public/private key secured DNS would make it much harder to have this kind of impersonation work.
The biggest issue would be how would you securely get the public key for a particular domain. In other words, if Verisign (or somebody) signs the public key for example.com, then how do you get that signed public key so that when you get a signed DNS response from the example.com nameserver, you know it came from somebody who controls the private key for example.com.
The current SSL certificate infrastructure is pretty similar to what you would need, and it seems to work pretty well. There are ways to game it, and bad guys do get SSL certs, but overall it works.
But, a lot of the reason it works is because of the money. Most people that want SSL certs with a public CA want it because they are making money off that cert (Amazon, eBay, etc.). The vast majority of domains don't need SSL, but if secure DNS started rolling out, it wouldn't be long before you would be suspect if your domain didn't use it. Even at $10/year for current "no verify" SSL certificates, that would get to be pretty expensive "just for DNS". Probably the only way to really make it work would be for the DNS certificate to be included in the domain registration price.
Technically, it would have to be both SP2 and SP3 to get close to "current", since SP3 is unlike every other previous Service Pack released by MS (at least as far as I remember). SP3 rolls up all the patches since SP2, but does not include SP2 patches. It does obsolete some of the patches included with SP2, but not all of them.
So, for as much protection as possible (while still running Windows XP), you need to install SP2 then SP3, then a few more patches that have been released since SP3.
Agreed. I generally don't go to eBay to buy a current piece of computer hardware, book, etc., but when I need something that isn't readily available in stores today or is very expensive new, eBay is the place to go.
I don't mind that some people have fixed-price-only listings there, but if the price isn't good, they won't get my business, and generally anything "current" isn't a good deal on eBay. I don't really understand how some sellers make even one sale when they are selling things that can be purchased at Amazon, Newegg, or even the local WalMart for less after you factor in shipping and taxes.
But, when you are trying to purchase a 48-port managed switch so you can do some configuration testing and learning at home, $200 from eBay is a lot better than $800 new.
I got tired of script-kiddies banging away at port 22 and filling up my logs and forcing me to make sure nothing was wrong (even though they don't have hope in hell of logging in, as they don't have a valid certificate for any user on my machine). Ever since I changed the port, I've seen no failures in the logs from anyplace that wasn't just a known user making a mistake.
Definitely true about services that pretty much have to run on fixed ports. MOD PARENT UP for this.
QoS, however, does *not* imply that all traffic gets delivered eventually. In fact, the primary mechanism for QoS with TCP/IP is to drop packets when traffic flows are too fast.
TCP is reliably delivery. By definition, those dropped packets will be resent at some future point.
It's possible that whatever higher-level protocol would treat this as some sort of "stop completely" command, but anything robust would keep retrying, and although it can eventually give up and time out, but I assume that such timeouts could be changed in such a way as to make sure that it never gives up.
Hmm. I'm not convinced. What about VoIP? I *like* my low-latency reliable VoIP, and I like the fact that my ISP is able to prioritize it over bulk traffic like BT. Ditto small HTTP traffic bursts, DNS requests, etc.
Prioritizing (i.e., QoS) is OK, but what Comcast did wasn't any sort of QoS...it was forging packets to say "please permanently disconnect". I know that some people may define cutting off connections as QoS, but it isn't. QoS implies that every connection gets to send all of its data, eventually.
There is considerably more metadata than the filename in all package systems.
Although I generally only use RPM, I have seen enough of others to know that each package has information inside it that says things like "supplies foo-2.8.0.so". For example:
$ rpm -q --provides openssh
config(openssh) = 4.3p2-24.el5
openssh = 4.3p2-24.el5
This sort of metadata is part of the headers that are downloaded by the package manager to determine whether the system needs the package, and what other packages might be needed to fulfill dependencies. So, the system probably won't even download the file just because it was renamed. But, even if it does download it, when it tries to install it, you would get an error because a newer version of the capability (RPM term) named "openssh" is already installed.
You could always force the install, but no package manager does this sort of downgrade as an out of the box default
5. Log IPs of machines downloading from your mirror.
6. Root them.
Even if you get this far without the system updating the package from a non-hostile mirror, you're rolling the dice again for your ability to execute an attack.
First, the vulnerable package has to be exposed to a public IP. Using OpenSSH as an example, it's installed on all of my Linux machines, but only one has it available on a public IP, so all the rest are safe (at least from an initial attack).
Then, you have to scan pretty much every port in case they have changed the default for the package...this can alert an IDS which could protect the system.
Last, you have to hope they download the package using the same IP address that the vulnerable program is bound to. In my case, my only exposed Linux machine listens for inbound connections on one public IP, and initiates most outbound connections on another public IP, with a few outbound on a third public IP (depending on the protocol and destination host and/or port). So, you could bang every port on the IP address that retrieved the package and still get nothing.
This is not a unique situation, either, as I work with several sites that do the same thing where connections to/from the same machine are on different IP addresses...one in which the in and out are behind completely different firewalls.
Yes a mirror can keep you from getting a security update. But if you don't contact that mirror every day you will eventually get a good mirror and update, and since none of the package managers will downgrade automatically this is a mostly theoretical exploit.
Also, the article says "the malicious mirror can provide the client a signed list of packages from the year before", but I don't see how that can cause a problem, either, if I have updated a package within that year.
If I have foo-3.1.0 installed and the malicious mirror offers me foo-2.8.0, then I won't download it, because it doesn't provide newer versions of anything.
The big key in all of this is signed packages (no pun intended), since that keeps the bad guys from modifying the package to claim to be foo-3.2.0 but really contain trojan-1.0.0. As long as the packages are signed, I can't see anything that a malicious mirror could do other than delaying you getting updates for a few days, which isn't good, but its really no different from waiting a day or two to update your production system until you have time to make sure the updates don't break anything.
There were a lot of games that had networking and in-game messaging before C&C or Warcraft 2, although those may have been the earliest RTS games with that feature. IIRC, even Doom had a limited version where you couldn't type arbitrary text, but could setup hotkeys to send certain strings.
Do you really have your firewall restricted in such a way that UDP packets are only allowed through if they come from specific ports?
In other words, do you care if a query to an external DNS server comes from port 15875 or port 15876 on a machine in your behind-the-firewall network? Likewise, do you care if incoming DNS queries to your DNS server come from port 28410 or port 28411 on Comcast's DNS server?
Since it's currently random (but fixed at startup of the server) in some DNS implementations, this shouldn't affect anything for 99.99% of people. Any sysadmin who sets up firewall rules that were so stringent as to assume a source port for a protocol that doesn't require a specific source port should have to deal with the trouble their stupidity caused.
No matter how good the upscaling chipset is, it cannot divine information that's not on the disc.
No, but it can improve on the existing image.
An example is anti-aliasing. A nearly horizontal line on a 640x480 image might be quite jagged. By merely stretching the image to give more pixels to work with, duplicated pixels can be changed to smooth out (anti-alias) the line. It's computationally intensive and might not help much, but in theory the apparent quality can be better for the viewer.
Call me a snob if you like, that does not change the fact I can tell the difference very quicly on my 56" HDTV between HD content and DVD content, especialy when the HD content was recorded with a HD camera, not upconverted from film.
This statement basically says you don't know what you are talking about, as conversion from film to HD formats (1920x1080 or 1280x720) involves a loss of resolution, sometimes massive depending on exactly how the image is stored on the film.
Film easily has a resolution of 4000x4000, so even using a film format where black bars are stored on the film, you end up with about 4000x2200 at the 16:9 HDTV aspect ratio. Film is then telecined to whatever HD resolution is required, which results in a loss in resolution, but you still have at least full HD quality at that point. Now, special effects aren't always rendered at full film resolution, so some movies (or TV shows) will not have the full film resolution in all scenes, but generally the lowest rendering these days is 2K, which is more than enough for 1920x1080.
What's probably confusing you is that HDTV cameras have more depth of field than most lens/film combinations on 35mm film cameras. This gives the scene a much more "in focus" look for more of the image, and gives the illusion that it is sharper. Film can do this, but it is more difficult due to the complex interaction between the type of lens, the film speed, and the lighting for the scene.
My personal home network uses bladed weapons (scimitar, dagger, etc.), and where I used to work used Tolkien names (the major internal routers were named after crossroads in Middle Earth, etc.).
The best part was the machine at home that did the VPN connection to work...it was named "Bilbo". See here for how this fits in with both naming conventions.
For Windows networks, you could use Distributed File System (DFS), and nobody ever needs to know any server name. Every shared directory is \\DOMAIN-NAME\ShareName, and can be hosted on any computer (or replicated to multiple computers).
You can use remote file system mounting to get the same effect on Linux, etc., but it's not quite as efficient, as requests will still always go through the server that is hosting the share, while in DFS, after the lookup, the connection is to the actual machine hosting the data.
This doesn't work for anything else (like FTP, SSH, or remote desktop hostnames), but it does do a good job for shared files, especially over a wide area distributed network.
Fault-tolerant at every practical level. This gets expensive, so you see datacenter failures take down large swaths of sites who don't have multiple locations.
I work on a site that has pretty much every conceivable fault-tolerance you can get short of multiple sites: multiple separate ISPs leading to router and firewall hardware that is redundant for each ISP along with multiple load-balanced front-end web servers connected to load-balanced database and file servers (with every server running Solaris). Everything has multiple power supplies connected to different mains feeds and different generators. All of this is frightfully expensive and heavily monitored.
Yet, the #1 thing that is causing downtime is the failure of the clustering software on the file servers to actually fail over if something goes wrong. So, whenever the file system mounts fail, the whole system is down until those servers are rebooted, which takes 1-2 hours because of the clustering software.
Yet, if those file servers would have been relatively cheap with no redundancy, they could have been re-booted quickly and the file system mounts automatically recovered within 15 minutes.
So, the moral here is that more fault-tolerance isn't always the best way to maintain uptime. Carefully deciding where to spend money on what type of fault-tolerance is going to get you more uptime in the long run of the real world, instead of spending unwisely to increase statistical uptime.
You're correct. The environmental issues caused by battery production is far less politically harmful, because a 45MPG hybrid sounds much better than 35MPG from a non-hybrid, when the reality is that it isn't much on an individual level, and isn't really anything in the big picture.
It's much easier for a politician to vote to allow a hybrid driver to use HOV lanes and get lots of support from people that want to "help the environment", but those 35MPG cars with 2 passengers in the HOV lane make the 45MPG hybrid with one passenger look a lot more wasteful to me. And, that 10MPG bus with just 8 passengers really kicks the hybrid's butt, especially if the bus uses CNG or other more enviromentally friendly fuel.
Then, there's electric powered subway or light rail, that although it does still use energy (what doesn't?), it doesn't directly emit any exhaust of any kind, so you can use some clean, renewable generation system (wind, hydroelectric, etc.) to power it with very little impact, and the passenger-miles per gallon-equivalent just leaps so far beyond that HOV-stealing hybrid that any extra enviromental damage caused by the hybrid's batteries becomes quite a big deal.
So, yeah, it's easy for a politician to make hybrid cars more palatable to own, but the ones that vote to expand public transportation and vote against allowing hybrids in the HOV lane are the ones that have it right in the long run.
A legit home user would have a tough time reaching 900GB - speed is ultimately irrelevant as long as it's fast enough to actually reach the limit. It's all about volume, and what would you be uploading, and to who, that would amount to over 900GB in a month on a domestic connection?
Torrents...that's what does it for me.
Now, you may say something about this not being "legit", but the only thing I torrent is TV shows that my recording failed on, and truly free stuff (Linux distros, etc.). If you are nice to the swarm and seed back for a while, you can get some massive upload amounts.
I'm still only about 300GB/month upload (see here for calculation), but I'm sure that number is still larger than you thought you'd see from a "legit" user.
That over 300GB/month upload, and it's only using 6.3% of my connection (15Mbps symmetric), so I could see how 900GB/month might be limiting somebody who has 100Mbps upload speeds.
It's kind of funny: I was the kind of guy who plastered his car with liberal bumper stickers. I haven't added anything to the Prius. I think the entire car is one big statement: "I give a shit."
Someone purchasing an electric (or hybrid-electric) car may "give a shit", but the reality is that with the massive environmental cost of making the batteries for their car, all they truly end up with is misplaced good feelings about themselves.
The short term personal savings on fuel cost and ability to use HOV lanes are strong sets of blinders that keep most people from seeing the long-term environmental reality of electric vehicles.
It's especially sad when vehicles like the Volkswagon Jetta TDI (mentioned by others here), the Mini Cooper, and other small cars can get 80% of the mileage of a hybrid without the extra up-front cost or the battery-induced environmental damage.
(Hint: Vista is your memory manager. Why should it waste cycles loading and un-loading files so you can have "free" ram when it can just, you know, keep some in memory until a program actually asks for the space?)
The problem with Vista is that is does waste cycles loading and un-loading files.
Instead of working like every other cache system in the world, Superfetch tries to guess what files you might need in RAM. Based on the complaints, it appears that it guesses wrong most of the time.
What this does is needlessly keep the hard drive seeking to load files, then when the user does ask for a file to be opened, they have to wait until the Vista-initiated disk activity stops before their request gets serviced. That's just bad design, and it gets worse because of how much more power this causes laptops to use.
Last, when users turn off this feature, the system becomes more responsive to their requests. If that isn't a sign that the caching algoritm in Superfetch isn't broken, I'm not sure what would be.
Slashdot Mirror
That's great for people who use the service strictly for network access. But for folks who use the ISP's other services (like email, news, and possibly even web hosting) are likely to find that none of the ISP's servers are visible when not using the ISP's DNS servers from inside the ISP's network. I know this is true for RoadRunner, because I tried exactly what you said, only to find that only RR's DNS knows about their email or news servers, for example.
The only real solution is to run a local caching-only DNS server, and set it up so that all queries except ".rr.com" domains go out normally, while sending queries for ".rr.com" to their servers.
Since there are quite a few free (either open or closed source) caching DNS servers for almost every OS, there really isn't a reason why everybody doesn't run a caching server anyway.
RH is only distro I have ever tried - and I tried many of them - would silently without any warning or prompt replace your config files with shipped version.
First, it doesn't do this without any warning...the output of rpm (which does the actual install) is forward to yum, or rhn, or whatever is running the "figure out everything I need and get it" process, and that is displayed to you when you are applying the patch. It clearly states in that output what happened with the file.
Second, for some updates (particularly security updates like this one), it is appropriate to save the old config file and load a default one, especially if that default one helps provide more security. Then, the admin can figure out what parts of the new default should be applied to their config, merge everything together, and restart the service.
These are the kinds of procedures that good admins do when they make changes to the system in any way.
Besides, if you read what I wrote, I have two perfect and beautiful children. So I gotta be doing something right. (Actually? They're not perfect but they are beautiful only 'cause they got that from my ex wife. They are, actully, really really well behaved and excel scholastically.)
I'm really sorry to break this to you, but this means nothing. I'm not knocking your kids or anything, because they may be really great and may end up turning out to be really great adults, but at 7 and 9 their "state" isn't always indicative of what they will turn out to be.
Case in point...a friend of mine had a very authoritarian and over-protective father, and although he was the great student, well-behaved generally (especially compared to some of the friends he had at the time), that strict lockdown authority left him pretty messed up, and he's been in and out of therapy for years now. And, if you had asked his father, he would have responded pretty much like you do about your kids, at least when they were 7-9 years old (later, maybe not as much).
Again, I'm not saying that this is the way your family is, but it's just something to think about.
Actually, I'd say exactly the opposite. SSL is used only on a fraction of the net, and in many cases, for many uses, self-signed certificates are as trustworthy as the CA's. Overall, I'd say that's not working.
SSL "doesn't work"? I guess I missed the articles on /. about Amazon, Google, eBay, PayPal, and every bank having issues with users not being able to connect to their secure servers, or with certificates showing up as not trusted, and the half-dozen impersonation attacks every week.
Like I said, there are definitely some problems that have happened, but overall the SSL certificate infrastructure is doing the job.
For any system to work and get widely deployed it has to be built on end-to-end, without a third party, trust. Each site has to be in control of their own keys and not dependent on someone elses good will and business.
How, exactly, do you purpose to do this with DNS? When you do a lookup on "example.com" for the first time, how do you check the signature if you don't have the public key? And, how do you get the public key in a trustworthy way without a third party?
Now, figure a way to make this scale so that it doesn't end up with IT administrators saying things like "Amazon, Google, and Microsoft are OK, but you can't view any other web pages because we don't have their DNS keys yet". Can you imagine if everyone who wanted to purchase at Amazon had to go to Seattle to pick up the Amazon SSL cert in person before they could create a secure, trusted connection? Because that's what would happen if Amazon used a self-signed cert and people wanted to be truly sure they were connecting to the real Amazon.
Part of the power of the Internet is that J. Random Blogger can put up some information on his personal domain that is exactly what you needed to know to get your install of Foobastic 2.4.12 to work with your hardware. Any secure DNS system that doesn't allow you to find that domain securely without any extra work on your part just isn't a viable solution.
Secure DNS makes this kind of impersonation impossible
Mmm, no. It makes this kind of impersonation possible by anyone who can coerce/corrupt/control some part of the chain of trust.
I think a public/private key secured DNS would make it much harder to have this kind of impersonation work.
The biggest issue would be how would you securely get the public key for a particular domain. In other words, if Verisign (or somebody) signs the public key for example.com, then how do you get that signed public key so that when you get a signed DNS response from the example.com nameserver, you know it came from somebody who controls the private key for example.com.
The current SSL certificate infrastructure is pretty similar to what you would need, and it seems to work pretty well. There are ways to game it, and bad guys do get SSL certs, but overall it works.
But, a lot of the reason it works is because of the money. Most people that want SSL certs with a public CA want it because they are making money off that cert (Amazon, eBay, etc.). The vast majority of domains don't need SSL, but if secure DNS started rolling out, it wouldn't be long before you would be suspect if your domain didn't use it. Even at $10/year for current "no verify" SSL certificates, that would get to be pretty expensive "just for DNS". Probably the only way to really make it work would be for the DNS certificate to be included in the domain registration price.
I believe if buy XP, it will be SP2 or 3 now.
Technically, it would have to be both SP2 and SP3 to get close to "current", since SP3 is unlike every other previous Service Pack released by MS (at least as far as I remember). SP3 rolls up all the patches since SP2, but does not include SP2 patches. It does obsolete some of the patches included with SP2, but not all of them.
So, for as much protection as possible (while still running Windows XP), you need to install SP2 then SP3, then a few more patches that have been released since SP3.
Agreed. I generally don't go to eBay to buy a current piece of computer hardware, book, etc., but when I need something that isn't readily available in stores today or is very expensive new, eBay is the place to go.
I don't mind that some people have fixed-price-only listings there, but if the price isn't good, they won't get my business, and generally anything "current" isn't a good deal on eBay. I don't really understand how some sellers make even one sale when they are selling things that can be purchased at Amazon, Newegg, or even the local WalMart for less after you factor in shipping and taxes.
But, when you are trying to purchase a 48-port managed switch so you can do some configuration testing and learning at home, $200 from eBay is a lot better than $800 new.
I'm not careful...I'm lazy. ;->
I got tired of script-kiddies banging away at port 22 and filling up my logs and forcing me to make sure nothing was wrong (even though they don't have hope in hell of logging in, as they don't have a valid certificate for any user on my machine). Ever since I changed the port, I've seen no failures in the logs from anyplace that wasn't just a known user making a mistake.
Definitely true about services that pretty much have to run on fixed ports. MOD PARENT UP for this.
QoS, however, does *not* imply that all traffic gets delivered eventually. In fact, the primary mechanism for QoS with TCP/IP is to drop packets when traffic flows are too fast.
TCP is reliably delivery. By definition, those dropped packets will be resent at some future point.
It's possible that whatever higher-level protocol would treat this as some sort of "stop completely" command, but anything robust would keep retrying, and although it can eventually give up and time out, but I assume that such timeouts could be changed in such a way as to make sure that it never gives up.
Hmm. I'm not convinced. What about VoIP? I *like* my low-latency reliable VoIP, and I like the fact that my ISP is able to prioritize it over bulk traffic like BT. Ditto small HTTP traffic bursts, DNS requests, etc.
Prioritizing (i.e., QoS) is OK, but what Comcast did wasn't any sort of QoS...it was forging packets to say "please permanently disconnect". I know that some people may define cutting off connections as QoS, but it isn't. QoS implies that every connection gets to send all of its data, eventually.
There is considerably more metadata than the filename in all package systems.
Although I generally only use RPM, I have seen enough of others to know that each package has information inside it that says things like "supplies foo-2.8.0.so". For example:
$ rpm -q --provides openssh
config(openssh) = 4.3p2-24.el5
openssh = 4.3p2-24.el5
This sort of metadata is part of the headers that are downloaded by the package manager to determine whether the system needs the package, and what other packages might be needed to fulfill dependencies. So, the system probably won't even download the file just because it was renamed. But, even if it does download it, when it tries to install it, you would get an error because a newer version of the capability (RPM term) named "openssh" is already installed.
You could always force the install, but no package manager does this sort of downgrade as an out of the box default
5. Log IPs of machines downloading from your mirror.
6. Root them.
Even if you get this far without the system updating the package from a non-hostile mirror, you're rolling the dice again for your ability to execute an attack.
First, the vulnerable package has to be exposed to a public IP. Using OpenSSH as an example, it's installed on all of my Linux machines, but only one has it available on a public IP, so all the rest are safe (at least from an initial attack).
Then, you have to scan pretty much every port in case they have changed the default for the package...this can alert an IDS which could protect the system.
Last, you have to hope they download the package using the same IP address that the vulnerable program is bound to. In my case, my only exposed Linux machine listens for inbound connections on one public IP, and initiates most outbound connections on another public IP, with a few outbound on a third public IP (depending on the protocol and destination host and/or port). So, you could bang every port on the IP address that retrieved the package and still get nothing.
This is not a unique situation, either, as I work with several sites that do the same thing where connections to/from the same machine are on different IP addresses...one in which the in and out are behind completely different firewalls.
Yes a mirror can keep you from getting a security update. But if you don't contact that mirror every day you will eventually get a good mirror and update, and since none of the package managers will downgrade automatically this is a mostly theoretical exploit.
Also, the article says "the malicious mirror can provide the client a signed list of packages from the year before", but I don't see how that can cause a problem, either, if I have updated a package within that year.
If I have foo-3.1.0 installed and the malicious mirror offers me foo-2.8.0, then I won't download it, because it doesn't provide newer versions of anything.
The big key in all of this is signed packages (no pun intended), since that keeps the bad guys from modifying the package to claim to be foo-3.2.0 but really contain trojan-1.0.0. As long as the packages are signed, I can't see anything that a malicious mirror could do other than delaying you getting updates for a few days, which isn't good, but its really no different from waiting a day or two to update your production system until you have time to make sure the updates don't break anything.
There were a lot of games that had networking and in-game messaging before C&C or Warcraft 2, although those may have been the earliest RTS games with that feature. IIRC, even Doom had a limited version where you couldn't type arbitrary text, but could setup hotkeys to send certain strings.
Do you really have your firewall restricted in such a way that UDP packets are only allowed through if they come from specific ports?
In other words, do you care if a query to an external DNS server comes from port 15875 or port 15876 on a machine in your behind-the-firewall network? Likewise, do you care if incoming DNS queries to your DNS server come from port 28410 or port 28411 on Comcast's DNS server?
Since it's currently random (but fixed at startup of the server) in some DNS implementations, this shouldn't affect anything for 99.99% of people. Any sysadmin who sets up firewall rules that were so stringent as to assume a source port for a protocol that doesn't require a specific source port should have to deal with the trouble their stupidity caused.
No matter how good the upscaling chipset is, it cannot divine information that's not on the disc.
No, but it can improve on the existing image.
An example is anti-aliasing. A nearly horizontal line on a 640x480 image might be quite jagged. By merely stretching the image to give more pixels to work with, duplicated pixels can be changed to smooth out (anti-alias) the line. It's computationally intensive and might not help much, but in theory the apparent quality can be better for the viewer.
Call me a snob if you like, that does not change the fact I can tell the difference very quicly on my 56" HDTV between HD content and DVD content, especialy when the HD content was recorded with a HD camera, not upconverted from film.
This statement basically says you don't know what you are talking about, as conversion from film to HD formats (1920x1080 or 1280x720) involves a loss of resolution, sometimes massive depending on exactly how the image is stored on the film.
Film easily has a resolution of 4000x4000, so even using a film format where black bars are stored on the film, you end up with about 4000x2200 at the 16:9 HDTV aspect ratio. Film is then telecined to whatever HD resolution is required, which results in a loss in resolution, but you still have at least full HD quality at that point. Now, special effects aren't always rendered at full film resolution, so some movies (or TV shows) will not have the full film resolution in all scenes, but generally the lowest rendering these days is 2K, which is more than enough for 1920x1080.
What's probably confusing you is that HDTV cameras have more depth of field than most lens/film combinations on 35mm film cameras. This gives the scene a much more "in focus" look for more of the image, and gives the illusion that it is sharper. Film can do this, but it is more difficult due to the complex interaction between the type of lens, the film speed, and the lighting for the scene.
My personal home network uses bladed weapons (scimitar, dagger, etc.), and where I used to work used Tolkien names (the major internal routers were named after crossroads in Middle Earth, etc.).
The best part was the machine at home that did the VPN connection to work...it was named "Bilbo". See here for how this fits in with both naming conventions.
For Windows networks, you could use Distributed File System (DFS), and nobody ever needs to know any server name. Every shared directory is \\DOMAIN-NAME\ShareName, and can be hosted on any computer (or replicated to multiple computers).
You can use remote file system mounting to get the same effect on Linux, etc., but it's not quite as efficient, as requests will still always go through the server that is hosting the share, while in DFS, after the lookup, the connection is to the actual machine hosting the data.
This doesn't work for anything else (like FTP, SSH, or remote desktop hostnames), but it does do a good job for shared files, especially over a wide area distributed network.
Fault-tolerant at every practical level. This gets expensive, so you see datacenter failures take down large swaths of sites who don't have multiple locations.
I work on a site that has pretty much every conceivable fault-tolerance you can get short of multiple sites: multiple separate ISPs leading to router and firewall hardware that is redundant for each ISP along with multiple load-balanced front-end web servers connected to load-balanced database and file servers (with every server running Solaris). Everything has multiple power supplies connected to different mains feeds and different generators. All of this is frightfully expensive and heavily monitored.
Yet, the #1 thing that is causing downtime is the failure of the clustering software on the file servers to actually fail over if something goes wrong. So, whenever the file system mounts fail, the whole system is down until those servers are rebooted, which takes 1-2 hours because of the clustering software.
Yet, if those file servers would have been relatively cheap with no redundancy, they could have been re-booted quickly and the file system mounts automatically recovered within 15 minutes.
So, the moral here is that more fault-tolerance isn't always the best way to maintain uptime. Carefully deciding where to spend money on what type of fault-tolerance is going to get you more uptime in the long run of the real world, instead of spending unwisely to increase statistical uptime.
You're correct. The environmental issues caused by battery production is far less politically harmful, because a 45MPG hybrid sounds much better than 35MPG from a non-hybrid, when the reality is that it isn't much on an individual level, and isn't really anything in the big picture.
It's much easier for a politician to vote to allow a hybrid driver to use HOV lanes and get lots of support from people that want to "help the environment", but those 35MPG cars with 2 passengers in the HOV lane make the 45MPG hybrid with one passenger look a lot more wasteful to me. And, that 10MPG bus with just 8 passengers really kicks the hybrid's butt, especially if the bus uses CNG or other more enviromentally friendly fuel.
Then, there's electric powered subway or light rail, that although it does still use energy (what doesn't?), it doesn't directly emit any exhaust of any kind, so you can use some clean, renewable generation system (wind, hydroelectric, etc.) to power it with very little impact, and the passenger-miles per gallon-equivalent just leaps so far beyond that HOV-stealing hybrid that any extra enviromental damage caused by the hybrid's batteries becomes quite a big deal.
So, yeah, it's easy for a politician to make hybrid cars more palatable to own, but the ones that vote to expand public transportation and vote against allowing hybrids in the HOV lane are the ones that have it right in the long run.
A legit home user would have a tough time reaching 900GB - speed is ultimately irrelevant as long as it's fast enough to actually reach the limit. It's all about volume, and what would you be uploading, and to who, that would amount to over 900GB in a month on a domestic connection?
Torrents...that's what does it for me.
Now, you may say something about this not being "legit", but the only thing I torrent is TV shows that my recording failed on, and truly free stuff (Linux distros, etc.). If you are nice to the swarm and seed back for a while, you can get some massive upload amounts.
I'm still only about 300GB/month upload (see here for calculation), but I'm sure that number is still larger than you thought you'd see from a "legit" user.
MRTG says I'm averaging 117.7 kB/s outbound on my router/firewall WAN port over the past few months. A little math gives us:
117.7 * 1000 * 60 * 60 * 24 * 30.4375 = 309,527,460,000 bytes/month
That over 300GB/month upload, and it's only using 6.3% of my connection (15Mbps symmetric), so I could see how 900GB/month might be limiting somebody who has 100Mbps upload speeds.
It's kind of funny: I was the kind of guy who plastered his car with liberal bumper stickers. I haven't added anything to the Prius. I think the entire car is one big statement: "I give a shit."
Someone purchasing an electric (or hybrid-electric) car may "give a shit", but the reality is that with the massive environmental cost of making the batteries for their car, all they truly end up with is misplaced good feelings about themselves.
The short term personal savings on fuel cost and ability to use HOV lanes are strong sets of blinders that keep most people from seeing the long-term environmental reality of electric vehicles.
It's especially sad when vehicles like the Volkswagon Jetta TDI (mentioned by others here), the Mini Cooper, and other small cars can get 80% of the mileage of a hybrid without the extra up-front cost or the battery-induced environmental damage.
(Hint: Vista is your memory manager. Why should it waste cycles loading and un-loading files so you can have "free" ram when it can just, you know, keep some in memory until a program actually asks for the space?)
The problem with Vista is that is does waste cycles loading and un-loading files.
Instead of working like every other cache system in the world, Superfetch tries to guess what files you might need in RAM. Based on the complaints, it appears that it guesses wrong most of the time.
What this does is needlessly keep the hard drive seeking to load files, then when the user does ask for a file to be opened, they have to wait until the Vista-initiated disk activity stops before their request gets serviced. That's just bad design, and it gets worse because of how much more power this causes laptops to use.
Last, when users turn off this feature, the system becomes more responsive to their requests. If that isn't a sign that the caching algoritm in Superfetch isn't broken, I'm not sure what would be.