Bundles are kind of cool in the way you describe, but they're an absolute bitch to maintain when your code base is not aimed specifically at the Mac. And the lack of inter-bundle dependency tracking is pretty tragic - you can remove a bundle and completely break things, and you can't really know when upgrading a bundle will break something that depends on it.
So yeah, superficially I agree with you, but in practice I find that the debian system, and for that matter the Redhat system, work a lot better.
How often do you put your machine to sleep? How often do you change networks? How often do you activate a bluetooth device that was powered down? None of these are reliable with Linux on the GUI - I've taken to just doing everything on the command line. Even then, the Wifi drivers just fall down when you have two base stations with the same ESSID - they switch randomly between the two, often choosing the one with the least signal strength.
And when was the last time you tried switching monitors? Windows Just Handles this. Linux falls flat on its face. Even if you know how to tweak XrandR on the command line, half the time it doesn't work. Doing it from the control panels is completely hopeless.
Compiz is eye candy. It's not even pretty. I do not get what all the fuss is about Compiz. Of all the things to spend countless hours of hack time on, this is one of the most useless. I'm sure it was fun, and I don't begrudge people their fun, but it makes no difference at all to the average user, because they are never going to use it.
Make the control panels work, every time. Make the bluetooth stack work every time, and not occasionally get unrecoverably wedged. Make the Wifi support work every time. Make sleep/wake work every time. Make monitor switching work every time. This is what matters. All this other stuff is great once you have the basics working, but without the basics working, it Just Doesn't Matter.
That's just it, though. Who it's good enough is geeks who can defend themselves, and people who are using dirt simple vanilla configurations that never change. I agree that in those two cases, it works.
Who it doesn't work for is the average user, who has a laptop that moves around a lot, who isn't technically savvy, and who needs the thing to just work. For that, like it or not, the Mac wins hands down, and Vista does pretty good as well.
Unfortunately, the last 5% really does matter when it comes to widespread adoption.
The KDE apps I use crash a lot, and it's hard to figure out why because there are so many interdependent processes. I pretty much gave up on KMail and switched to Evolution. I really prefer Qt over Gtk, but KDE has made a very poor impression on me so far.
The problem isn't that Linux is copying Windows. It's that it's copying it badly. I make it a practice to alternate between Windows, Linux and Mac and really use them, so that I can get a sense of what is good and bad about them.
Currently, where Linux shines is the command line, and the package managers (I'm biased toward Debian). The GUIs work, mostly, but they aren't nearly as stable as Windows Vista, and they don't add any real value that Vista doesn't have.
Vista shines in that it's stable, and reasonably pretty. That's really about it. If you aren't a Windows power user, it's perfectly usable (if you are you might prefer XP, because it's less secure, and thus less troublesome at least until it gets infected). I find it pretty hard to get anything done on it though without installing Cygwin, which is a bit of a cheat.
Mac OS X shines in that it's pretty, stable, and reasonably easy to use. And the command line doesn't suck, although package management isn't anywhere near as good as Debian/Ubuntu. OS X also seems to have the best media support, as long as you don't care about playing Windows Media Player files (I don't).
Linux could clean Windows' clock if the GUI were more dependable. Right now it's pretty good, but occasionally falls flat on its face. Bluetooth support isn't dependable, and even networking support isn't 100% dependable at the GUI level. So of the three operating systems, unfortunately Linux is the one I find most frustrating to depend on on a day-to-day basis, even though it's the one I am rooting for.
The root cause is twofold. First, SMTP is inherently opt-out, not opt-in. By default, you always accept an email message unless it is from someone you know is a spammer. Being able to accurately identify the sender isn't all that helpful because most senders will be unknown to you, and thus whether or not they are spammers will not be known. Furthermore, generating new identities ought to be cheap, but in order for knowing the identity of the sender to be useful in the context of SMTP, it has to be expensive.
Contrast this with a pull-oriented email strategy, where my server contacts yours because we are "friends," to see if you have anything new to say to me. Now no traffic passes unless the recipient wants it to. The sender has no opportunity to attempt to fool the recipient, because there is no context for unsolicited traffic.
In this case, knowing the identity of the sender isn't all that important. We need to know that the message is from a person we said we wanted to hear from, but we do not need to know precisely who that person is. Receiving messages is a question of preference, not trust. If you start sending me spam, I un-friend you, and that's it - no more junk mail from you.
Well, as another person mentioned, whitelisting is pretty useless because it's easy to forge a sender address. It's not a good argument for a pull protocol, but with a push protocol like SMTP, it's a real problem. If whitelisting were widely and effectively implemented, it would be one more incentive to spammers to crack your friends' and relatives' address books.
Not really. AIM and Skype do a pretty good job of it. So does ssh. It's a simple matter of public key cryptography, coupled with some variety of introduction and rendezvous mechanisms appropriate to the various ways you might know another person online.
Seriously, the problem with every anti-spam countermeasure I've seen so far is that they are all based on using SMTP as a mail transport. And SMTP is a protocol designed for a civilized Internet - one where every email sent is assumed to be one that the designated recipient wants.
In order to stop spam, we need to stop using SMTP and switch to a protocol that rejects mail by default. Unfortunately, this requires a flag day, and nobody's put forward a protocol like this yet, so we're still stuck with insane amounts of spam.
Sounds a lot like spam...
on
Sleep Mailing
·
· Score: 1
Are they sure this stuff actually came from her? I get spam like this all the time - just not from people I know.
VoIP and peer-to-peer work better with end-to-end connectivity. They can be made to work across NATs, but it's a *huge* headache. They can also be made to work by passing all traffic through corporate servers, which is great for corporations who want to be able to collect tolls, but kind of sucks for end users who don't want to pay them.
Most internet users are individuals, not corporations. So yes, in your situation, you're sitting pretty for now, but your situation doesn't generalize to the average user.
There's work on this happening in the IETF. And you can already do this with Teredo, which any Windows Vista machine has installed. The trick is that you need to spoof AAAA records in the DNS to make it all work, and that's non-trivial and interacts badly with DNSSEC. However, not to worry - if you just do the AAAA translation on the host that's doing DNSSEC validation, you can validate the A record, then provide a translated address to the application.
So the short answer is that if you want to do this, the technology is available, but it's not yet turnkey - you need to be a geek to get it working at this point. Stay tuned - in a few months that story will probably change.
Eh? You think your IPv4 address is untraceable? Think again. IPv6 actually has some very serious privacy-enhancing features, like temporary addresses, which are intended to be used once and then discarded, so that web sites can't track you by IPv6 address. Of course, they can still track you to the prefix, but that's no worse than what you have right now with IPv4.
On the other hand, with IPv6 addressing, you get end-to-end connectivity to the machine in your house, and you can generate IPv6 addresses randomly, which means that a virus trying to infect your computer has to try 2^64 different IPv6 addresses in order to get a single packet to your host. So it makes a lot of attacks that are dead easy in IPv4 really hard in IPv6. Big win. And it makes VoIP and peer to peer work a *lot* better. Another big win.
But yeah, if you spend all your time surfing internet porn sites, IPv4 and IPv6 are pretty much equivalent, so there's no reason to upgrade.
The latter. But you will probably need to at least install new firmware in your router. If you're running Linux, Vista or OSX 10.4 or 10.5, and you have good IPv6 connectivity, it will mostly Just Work, but you need IPv4 connectivity to connect to most internet sites these days, so you can't run v6-only yet.
That would be really cool. There are challenges, however - if you make yourself available via IPv6, devices that support IPv6 but don't have IPv6 connectivity may mistakenly try to do IPv6 first and time out. This was a problem with Mac OS X briefly, although it's fixed in the latest versions. I'm not sure what Windows Vista does these days.
Point being, enabling IPv6 is not without cost. I have it enabled for my domains, and have gotten complaints. Telling the person doing the complaining to download the latest version of the software fixed the problem, but not every provider is going to be willing to do that. Although since/. is a geek site, they ought to be willing to do it.
There's a flaw in your argument: the reason the used book market is a social benefit is because of the stranglehold that exists on out-of-print copyrighted works as a consequence of copyright being effectively permanent. In fact the Internet is a much more efficient way of distributing out-of-print copyrighted material; the only reason it isn't the preferred mechanism is that it's illegal.
This is not to say that I think used bookstores are a bad thing - I think they are a good thing. But there is *huge* value in free exchange of information, and that is a natural application for the Internet.
Eh, the whole downtown is covered in habitrails, so you can walk from building to building in short sleeves, because you don't ever have to go outside. It's kind of like living on a really big space station, only with gravity.
1. No, it doesn't. The zone is signed once, and then queries are served out of cache. The server does not have to sign its response to each query. 2. Some firewalls are broken? What else is new? 3. This isn't true. Every name server out there except for djbdns supports dnssec. It took some real work to add that support, sure, but the work is already done. If you want DNSSEC support, you can have it now. 4. Hm. I had to add a single cron job to automatically resign the zone once an hour. Big whoop. 5. Publishing a name in the DNS requires cooperation from the parents. This is a non-issue. 6. No, it doesn't. It requires that validating clients reject unsigned data from zones that are signed, and provides a secure way for those clients to determine whether or not a zone is signed. This is why DNSSEC protects against the Kaminsky bug. If we took this feature out, DNSSEC would be useless.
Argument by vigorous assertion? If people are interested in delving deeper, reading the namedroppers and dnsop mailing lists for the month around the release of the Kaminsky bug would be instructive.
With DNSSEC, if the person running the root were to sign incorrect data and publish it, this would be easily detected by the consumers of that data. So it would only serve to create an embarrassing international incident - you couldn't use it to actually fool anybody.
When you read this article, I think it's virtually impossible to come away with a correct impression - this is a really bad case of the game of telephone.
The situation is that the major DNS vendors have all produced patches to their DNS server software that increases the entropy of the queries these servers send, so that now instead of spoofing being something that can be done with the relatively trivial hack Dan came up with, you now have to pretty much bludgeon the network to death for about 24 hours to get a successful attack.
So it's still possible to get a successful attack, but it's much, much harder. And if you do such an attack, it's really easy to detect.
So what the IETF is now discussing is how to exclude even the 24-hour bludgeoning attack. This is very different than what we were discussing in secret before the Kaminsky attack was revealed to the public. So "do nothing" really isn't as bad an idea as it sounds from reading the article.
Also, the quotation at the bottom of the article from Paul Hoffman is pure nonsense. The fact is that the main barrier to DNSSEC deployment right now is that the government hasn't yet signed the root. They are about to sign the root. The next barrier to DNSSEC deployment is that.COM isn't signed (.ORG is very close to being signed, and a lot of other TLDs are already signed as well). The reason.COM hasn't been signed is largely because they have an excuse. Since the root isn't signed, signing.COM isn't all that useful. Once the root is signed, the excuse for not signing.COM goes away.
Now, once.COM is signed, how much work is it to sign your zone? It takes about an hour to set up. I know because I've already signed all my zones. So this means that any organization that has a fiduciary responsibility to make sure you don't get spoofed (e.g., your bank) can *easily* sign their zone, once.COM is signed.
It is *not* necessary for every zone on the internet to be signed. It is merely necessary that those zones that really matter, and are most likely to be attacked, like bankofamerica.com, get signed.
Next, ISPs have to protect their DNS caches, or else you, if you really care about security, have to install a validating resolver. Installing a validating caching nameserver is not trivial, but it's not that hard. Importantly, it is no harder than installing a hacked caching name server - one that includes one of the several hacks proposed in the DNSEXT working group the other day.
So this is why serious people, including me, are arguing that doing nothing is actually the right thing. That's really an incendiary way of putting it: the fact is that the geeks have come up with a protocol that does the job. We have implemented servers that do that protocol. We have implemented clients that do that protocol. You can get them for free, or you can pay for nicer versions (my company makes one). What is missing is that the people who write the checks haven't written the checks yet.
So when the people who write the checks come to us and say "can't you make it secure," a lot of us answer "we did, why don't you use what we did." It's a little bit PHBish to come back at this point and demand that we do Yet Another DNS security system, particularly one that's a bad hack, when a system already exists and is deployable and not a hack, that will work much better than any of the proposed hacks.
So that's why some of us argued for doing nothing. We are simply telling the PHBs of the world "no, we already did what you need, go deploy that and stop bothering us," not "security isn't important."
Slashdot Mirror
Bundles are kind of cool in the way you describe, but they're an absolute bitch to maintain when your code base is not aimed specifically at the Mac. And the lack of inter-bundle dependency tracking is pretty tragic - you can remove a bundle and completely break things, and you can't really know when upgrading a bundle will break something that depends on it.
So yeah, superficially I agree with you, but in practice I find that the debian system, and for that matter the Redhat system, work a lot better.
How often do you put your machine to sleep? How often do you change networks? How often do you activate a bluetooth device that was powered down? None of these are reliable with Linux on the GUI - I've taken to just doing everything on the command line. Even then, the Wifi drivers just fall down when you have two base stations with the same ESSID - they switch randomly between the two, often choosing the one with the least signal strength.
And when was the last time you tried switching monitors? Windows Just Handles this. Linux falls flat on its face. Even if you know how to tweak XrandR on the command line, half the time it doesn't work. Doing it from the control panels is completely hopeless.
Compiz is eye candy. It's not even pretty. I do not get what all the fuss is about Compiz. Of all the things to spend countless hours of hack time on, this is one of the most useless. I'm sure it was fun, and I don't begrudge people their fun, but it makes no difference at all to the average user, because they are never going to use it.
Make the control panels work, every time. Make the bluetooth stack work every time, and not occasionally get unrecoverably wedged. Make the Wifi support work every time. Make sleep/wake work every time. Make monitor switching work every time. This is what matters. All this other stuff is great once you have the basics working, but without the basics working, it Just Doesn't Matter.
That's just it, though. Who it's good enough is geeks who can defend themselves, and people who are using dirt simple vanilla configurations that never change. I agree that in those two cases, it works.
Who it doesn't work for is the average user, who has a laptop that moves around a lot, who isn't technically savvy, and who needs the thing to just work. For that, like it or not, the Mac wins hands down, and Vista does pretty good as well.
Unfortunately, the last 5% really does matter when it comes to widespread adoption.
The KDE apps I use crash a lot, and it's hard to figure out why because there are so many interdependent processes. I pretty much gave up on KMail and switched to Evolution. I really prefer Qt over Gtk, but KDE has made a very poor impression on me so far.
The problem isn't that Linux is copying Windows. It's that it's copying it badly. I make it a practice to alternate between Windows, Linux and Mac and really use them, so that I can get a sense of what is good and bad about them.
Currently, where Linux shines is the command line, and the package managers (I'm biased toward Debian). The GUIs work, mostly, but they aren't nearly as stable as Windows Vista, and they don't add any real value that Vista doesn't have.
Vista shines in that it's stable, and reasonably pretty. That's really about it. If you aren't a Windows power user, it's perfectly usable (if you are you might prefer XP, because it's less secure, and thus less troublesome at least until it gets infected). I find it pretty hard to get anything done on it though without installing Cygwin, which is a bit of a cheat.
Mac OS X shines in that it's pretty, stable, and reasonably easy to use. And the command line doesn't suck, although package management isn't anywhere near as good as Debian/Ubuntu. OS X also seems to have the best media support, as long as you don't care about playing Windows Media Player files (I don't).
Linux could clean Windows' clock if the GUI were more dependable. Right now it's pretty good, but occasionally falls flat on its face. Bluetooth support isn't dependable, and even networking support isn't 100% dependable at the GUI level. So of the three operating systems, unfortunately Linux is the one I find most frustrating to depend on on a day-to-day basis, even though it's the one I am rooting for.
The root cause is twofold. First, SMTP is inherently opt-out, not opt-in. By default, you always accept an email message unless it is from someone you know is a spammer. Being able to accurately identify the sender isn't all that helpful because most senders will be unknown to you, and thus whether or not they are spammers will not be known. Furthermore, generating new identities ought to be cheap, but in order for knowing the identity of the sender to be useful in the context of SMTP, it has to be expensive.
Contrast this with a pull-oriented email strategy, where my server contacts yours because we are "friends," to see if you have anything new to say to me. Now no traffic passes unless the recipient wants it to. The sender has no opportunity to attempt to fool the recipient, because there is no context for unsolicited traffic.
In this case, knowing the identity of the sender isn't all that important. We need to know that the message is from a person we said we wanted to hear from, but we do not need to know precisely who that person is. Receiving messages is a question of preference, not trust. If you start sending me spam, I un-friend you, and that's it - no more junk mail from you.
Well, as another person mentioned, whitelisting is pretty useless because it's easy to forge a sender address. It's not a good argument for a pull protocol, but with a push protocol like SMTP, it's a real problem. If whitelisting were widely and effectively implemented, it would be one more incentive to spammers to crack your friends' and relatives' address books.
Not really. AIM and Skype do a pretty good job of it. So does ssh. It's a simple matter of public key cryptography, coupled with some variety of introduction and rendezvous mechanisms appropriate to the various ways you might know another person online.
pics, or it didn't happen!
Seriously, the problem with every anti-spam countermeasure I've seen so far is that they are all based on using SMTP as a mail transport. And SMTP is a protocol designed for a civilized Internet - one where every email sent is assumed to be one that the designated recipient wants.
In order to stop spam, we need to stop using SMTP and switch to a protocol that rejects mail by default. Unfortunately, this requires a flag day, and nobody's put forward a protocol like this yet, so we're still stuck with insane amounts of spam.
Are they sure this stuff actually came from her? I get spam like this all the time - just not from people I know.
VoIP and peer-to-peer work better with end-to-end connectivity. They can be made to work across NATs, but it's a *huge* headache. They can also be made to work by passing all traffic through corporate servers, which is great for corporations who want to be able to collect tolls, but kind of sucks for end users who don't want to pay them.
Most internet users are individuals, not corporations. So yes, in your situation, you're sitting pretty for now, but your situation doesn't generalize to the average user.
There's work on this happening in the IETF. And you can already do this with Teredo, which any Windows Vista machine has installed. The trick is that you need to spoof AAAA records in the DNS to make it all work, and that's non-trivial and interacts badly with DNSSEC. However, not to worry - if you just do the AAAA translation on the host that's doing DNSSEC validation, you can validate the A record, then provide a translated address to the application.
So the short answer is that if you want to do this, the technology is available, but it's not yet turnkey - you need to be a geek to get it working at this point. Stay tuned - in a few months that story will probably change.
Eh? You think your IPv4 address is untraceable? Think again. IPv6 actually has some very serious privacy-enhancing features, like temporary addresses, which are intended to be used once and then discarded, so that web sites can't track you by IPv6 address. Of course, they can still track you to the prefix, but that's no worse than what you have right now with IPv4.
On the other hand, with IPv6 addressing, you get end-to-end connectivity to the machine in your house, and you can generate IPv6 addresses randomly, which means that a virus trying to infect your computer has to try 2^64 different IPv6 addresses in order to get a single packet to your host. So it makes a lot of attacks that are dead easy in IPv4 really hard in IPv6. Big win. And it makes VoIP and peer to peer work a *lot* better. Another big win.
But yeah, if you spend all your time surfing internet porn sites, IPv4 and IPv6 are pretty much equivalent, so there's no reason to upgrade.
The latter. But you will probably need to at least install new firmware in your router. If you're running Linux, Vista or OSX 10.4 or 10.5, and you have good IPv6 connectivity, it will mostly Just Work, but you need IPv4 connectivity to connect to most internet sites these days, so you can't run v6-only yet.
That would be really cool. There are challenges, however - if you make yourself available via IPv6, devices that support IPv6 but don't have IPv6 connectivity may mistakenly try to do IPv6 first and time out. This was a problem with Mac OS X briefly, although it's fixed in the latest versions. I'm not sure what Windows Vista does these days.
Point being, enabling IPv6 is not without cost. I have it enabled for my domains, and have gotten complaints. Telling the person doing the complaining to download the latest version of the software fixed the problem, but not every provider is going to be willing to do that. Although since /. is a geek site, they ought to be willing to do it.
How about walking in a forest on a cool summer morning, watching the dew steam off of the grass?
The more books are printed, the fewer opportunities there are to take walks in forests...
There's a flaw in your argument: the reason the used book market is a social benefit is because of the stranglehold that exists on out-of-print copyrighted works as a consequence of copyright being effectively permanent. In fact the Internet is a much more efficient way of distributing out-of-print copyrighted material; the only reason it isn't the preferred mechanism is that it's illegal.
This is not to say that I think used bookstores are a bad thing - I think they are a good thing. But there is *huge* value in free exchange of information, and that is a natural application for the Internet.
Trust me, there's very little need for Trojans at a typical IETF meeting.
Eh, the whole downtown is covered in habitrails, so you can walk from building to building in short sleeves, because you don't ever have to go outside. It's kind of like living on a really big space station, only with gravity.
It was kind of cold in my hotel room, though.
1. No, it doesn't. The zone is signed once, and then queries are served out of cache. The server does not have to sign its response to each query.
2. Some firewalls are broken? What else is new?
3. This isn't true. Every name server out there except for djbdns supports dnssec. It took some real work to add that support, sure, but the work is already done. If you want DNSSEC support, you can have it now.
4. Hm. I had to add a single cron job to automatically resign the zone once an hour. Big whoop.
5. Publishing a name in the DNS requires cooperation from the parents. This is a non-issue.
6. No, it doesn't. It requires that validating clients reject unsigned data from zones that are signed, and provides a secure way for those clients to determine whether or not a zone is signed. This is why DNSSEC protects against the Kaminsky bug. If we took this feature out, DNSSEC would be useless.
Argument by vigorous assertion? If people are interested in delving deeper, reading the namedroppers and dnsop mailing lists for the month around the release of the Kaminsky bug would be instructive.
With DNSSEC, if the person running the root were to sign incorrect data and publish it, this would be easily detected by the consumers of that data. So it would only serve to create an embarrassing international incident - you couldn't use it to actually fool anybody.
When you read this article, I think it's virtually impossible to come away with a correct impression - this is a really bad case of the game of telephone.
The situation is that the major DNS vendors have all produced patches to their DNS server software that increases the entropy of the queries these servers send, so that now instead of spoofing being something that can be done with the relatively trivial hack Dan came up with, you now have to pretty much bludgeon the network to death for about 24 hours to get a successful attack.
So it's still possible to get a successful attack, but it's much, much harder. And if you do such an attack, it's really easy to detect.
So what the IETF is now discussing is how to exclude even the 24-hour bludgeoning attack. This is very different than what we were discussing in secret before the Kaminsky attack was revealed to the public. So "do nothing" really isn't as bad an idea as it sounds from reading the article.
Also, the quotation at the bottom of the article from Paul Hoffman is pure nonsense. The fact is that the main barrier to DNSSEC deployment right now is that the government hasn't yet signed the root. They are about to sign the root. The next barrier to DNSSEC deployment is that .COM isn't signed (.ORG is very close to being signed, and a lot of other TLDs are already signed as well). The reason .COM hasn't been signed is largely because they have an excuse. Since the root isn't signed, signing .COM isn't all that useful. Once the root is signed, the excuse for not signing .COM goes away.
Now, once .COM is signed, how much work is it to sign your zone? It takes about an hour to set up. I know because I've already signed all my zones. So this means that any organization that has a fiduciary responsibility to make sure you don't get spoofed (e.g., your bank) can *easily* sign their zone, once .COM is signed.
It is *not* necessary for every zone on the internet to be signed. It is merely necessary that those zones that really matter, and are most likely to be attacked, like bankofamerica.com, get signed.
Next, ISPs have to protect their DNS caches, or else you, if you really care about security, have to install a validating resolver. Installing a validating caching nameserver is not trivial, but it's not that hard. Importantly, it is no harder than installing a hacked caching name server - one that includes one of the several hacks proposed in the DNSEXT working group the other day.
So this is why serious people, including me, are arguing that doing nothing is actually the right thing. That's really an incendiary way of putting it: the fact is that the geeks have come up with a protocol that does the job. We have implemented servers that do that protocol. We have implemented clients that do that protocol. You can get them for free, or you can pay for nicer versions (my company makes one). What is missing is that the people who write the checks haven't written the checks yet.
So when the people who write the checks come to us and say "can't you make it secure," a lot of us answer "we did, why don't you use what we did." It's a little bit PHBish to come back at this point and demand that we do Yet Another DNS security system, particularly one that's a bad hack, when a system already exists and is deployable and not a hack, that will work much better than any of the proposed hacks.
So that's why some of us argued for doing nothing. We are simply telling the PHBs of the world "no, we already did what you need, go deploy that and stop bothering us," not "security isn't important."