I don't think it's privacy that needs to be sacrificed, but ease of access. All the popular instant messaging systems, forum and blog software etc. are subject to spam. If it was harder to obtain an address on these services, it would be much harder for spammers to abuse them.
On the other hand, ease of access is one of their primary benefits. An additional hurdle for SMTP is the lack of centralised controls, which is an important thing for any de facto standard communication tool to have.
Unfortunately it.slashdot.org has already been poisoned; you actually posted that request to an elaborate mock-up of the real slashdot, and the replies are coming from l33t hackers who are supplying you with false DNS servers which currently appear to work correctly.
You'd best disconnect from the internet and burn your computer. It's the only way to be sure.
While we're bitching about Microsoft, what the fuck is up with the description for these patches?
A security issue has been identified that could allow a remote attacker to misrepresent a system action or behavior unbeknownst to users on Microsoft Windows systems.
They could at least mention something about DNS so you know what the patch is actually for without having to read the info on their site.
Interesting... I don't think it's quite that easy though.
Let's say a client wants to know the address of www.cs.example.edu, so it asks the nameservers for example.edu
Being a large university, the cs subdomain is delegated to the CS department's name servers. For whatever reason, they're not actually under.cs, so the (legitimate) server sends back:
cs.example.edu IN NS compsci-ns1.example.edu cs.example.edu IN NS compsci-ns2.example.edu Additional: compsci-ns1.example.edu IN A 1.2.3.4 compsci-ns2.example.edu IN A 1.3.4.5
Now, the query was for www.cs.example.edu, so the name servers are outside of bailiwick. We just ignore these records? Obviously not - we've just received a delegation to them, so knowing their addresses would be nice. Okay, so we drop any additional records unless they're providing us data we need, such as the addresses of name servers we've just received delegation info for?
But, what if an attacker knows we'll do that, and so it spoofs a reply:
www.cs.example.edu IN NS nasty.example.edu Additional: nasty.example.edu IN A 6.6.6.6
How does the resolver know this is an invalid response? It asked what it believes to be the authoritative nameserver for example.edu how to find www.cs.example.edu, and it's received a response delegating it to another server. It's also provided the address of that other server.
Let's get more interesting: we want to poison www.example.edu, after all. So maybe instead of our attacker feeding us a bogus name server for www.cs.example.edu, it just feeds us a bogus name server for example.edu:
example.edu IN NS nasty.example.edu Additional: nasty.example.edu IN 600000000000000 A 6.6.6.6
Okay, now we have an additional name server for the domain. With a really long TTL. Eventually we'll forget about the name servers, but this entry should remain for some time.
Not quite as easy as directly poisoning the target cache, but running a name server isn't difficult. We could also provide a name server in a different domain. It'll need to be properly delegated but registering domains isn't all that tricky.
I thought the general consensus was that the use of nuclear weapons against Japan actually saved a lot of lives. Warfare was still very, very bloody back then, and the Allies were facing an island assault (which is bad enough), against the enemies homeland (which is even worse). The Japanese weren't exactly known for surrendering peacefully, no matter how obvious it was they were going to lose. Remember Iwo Jima?
Of the 21,000 Japanese soldiers present at the beginning of the battle, over 20,000 were killed and only 216 taken prisoner.
There's a hell of a lot of soldiers on both sides of the fence who owe their lives to the use of nuclear weapons; and that's without considering the likely but unprovable theory that this show of force prevented other conflicts from even occurring. It's even possible that, without a "live fire" example of how horrific nuclear weapons are, the cold war may not have been so cold.
Fair enough, but how does one obtain the public key for each host you're talking to?
I don't know the details of how DNSSec is implemented, but my understanding is that the public keys are obtained through DNS. While it does mean an attacker probably only gets one shot at poisoning a resolver (because once it has the real public key it'll ignore anything the attacker sends it), if it does succeed then the resolver will ignore anything the real DNS server sends it.
That suggests you do need some kind of trust relationship so that when you receive a public key you can tell if it's the real deal or a fake one.
Also, yesterday I was reading about the problem of DNSSec making your entire zone walkable. This was basically because the NXDOMAIN responses had to be signed so you could trust them, but couldn't actually be signed because it's generally considered bad practice for a live DNS server to have the private key (the zones should be signed offline, then transferred to the DNS server). If this is the case, how does a DNS server decrypt messages encrypted with its public key?
My understanding is that they wouldn't; requests wouldn't be encrypted, but the responses are signed and that's how the resolver can determine whether the response is genuine or not.
I reckon this is the approach I'd take. C is simple, low-level enough that you get a good feel for how a computer really works, and similar enough to other languages that a lot of the stuff you learn can be re-used.
I started with BASIC, which teaches bad habits. You can learn bad habits in C, but you don't have to.
When I taught myself C, it was purely for writing games. And back then, you had a wonderful VGA framebuffer that you wrote values to and shit appeared on the screen. That was seriously awesome.
Nowadays, there's a lot of abstraction to allow for hardware acceleration and windowing and multitasking and all that other bullshit you didn't have to think about in DOS. SDL is the closest to "bare metal" you can probably get without making your son think you're making him use primitive computers nobody uses any more. Depending on why he's interested in the first place, this might be important.
Using SDL you can start really simply as I said before, treating the surface as a simple framebuffer and manipulating it directly. If he's interested in game programming, he's gonna have to learn a lot of math, so teaching him how to draw circles and lines by plotting the pixels manually might be a nice way to make it not seem so horrible. Plus, if you know what every part of the program does (even if it's primitive and your monsters are boxes and the player is a cross) you'll feel more of a sense of accomplishment than if you use some framework that does all the heavy lifting for you.
The other good thing about SDL is that lots of other people use it and there are lots of libraries to do various forms of heavy lifting, so if it turns out his interest is more casual and even the site of code for drawing antialiased lines makes him lose interest, you can then pull in some useful libraries to do the mundane things and he can still have fun with it.
Or, if you want to fuck with his head you can just teach him OpenGL and 3D programming from the start. It's likely it'll fry his brain, but if he survives he might become the next John Carmack.
BIND supports DNSSec; DNSSec is about cryptographically signing your DNS entries so resolvers know that the response they got was from the legitimate authoritative server for the domain.
This means that it's not something you can "just patch" - it actually requires people to do some work, which means it'll take a very long time to actually be widely deployed (by "people" I mean "every single person who administers one or more DNS zones"). You also have the usual problems with crypto, i.e. establishing a "web of trust" (it's all very well if records under google.com are signed, but how do you know they're signed by Google?).
Solvable problems, but inertia is a powerful force.
Well that would work, although since VeriSign's "SiteFinder" stunt some DNS servers (including bind) have an option to denote a zone as being "delegation only" zone, which would stop this attack from working. I don't know how widespread use of this option would be, though.
Assuming it's not, than poisoning.com would make it much easier: with one successful attack you could poison dozens of popular domains.
What could be interesting is combining this attack with zombies -- that way you don't need to trick a user into visiting a site with your links on it, you can just spam the ISPs name servers from one (or several) of their clients until you finally get lucky. Even better, the larger the ISP the more likely one of your randomly infected zombies will be within their network.
You could also have the ISP name server do some queries against a DNS server you control so you can look for any patterns in the query IDs and source ports, and use that information to narrow the search space for your actual attack.
I'm not really seeing any solutions to these attacks that don't simply turn it into an easy DoS. Fun times are ahead!
This doesn't cause problems for you, because if you read what Blindman wrote, they only use it for sites that don't work with Firefox. If you're creating web pages that are anywhere close to being modern, then you won't see hits from any version of IE from people like us.
It's not installations that matter, it's what people actually use.
Sorry, but they're actually pictures of houses they're planning to rob, and cars they're planning to steal.
Just did a search and some of them seem to be returning errors now - nothing like getting your problems published on slashdot to motivate people to fix them!
So are these services purely to allow people with MMS-incapable phones to see messages (I remember getting an SMS with a URL to view the message once upon a time with Telstra), or for sharing them?
If it's the former then requiring authentication might be possible, but that'd be a real pain for the latter. Having random, unguessable paths as unique keys is about all you can do without crippling the ability to share them.
Surely if they're relying on having unguessable URLs they wouldn't have any way to retrieve a list of them, so I guess this all stems from people publishing links to (private?) messages on public sites. At least, I hope that's the case.
The clearest way is whatever way you learned first when you were learning to code.
Not always, when I learned C I used "K&R" style braces (i.e. on the same line as the if/else clause), but switched to "GNU" style braces (vertically aligned) after a few years because of encountering code that used that style and deciding I preferred it.
There's good arguments for and against both styles, IMHO, so it just comes down to personal preference as you say.
Hmm, it looks to me like the main difference w.r.t. readability is that you added an extra blank line before and after the else in the C/C++ version, which you didn't have in the Perl version. That makes it stand out quite a bit.
It's annoying because it does change behaviour at a more technical level.
With non-hijacked DNS, if you enter a non-existent hostname, you DO NOT receive a "404" error. "404" is an HTTP status code which means "not found". This can only be generated by a web server and only makes sense in the context of requesting a resource from a web server, and the server decides it does not exist.
It follows from this that if the hostname does not exist, then you can't connect to a webserver at the address (because there is no address), and therefore it is completely impossible for you to receive a "404 error". Instead, your browser (or proxy) discovers the DNS lookup returned "non-existent domain", and does something other than trying to connect to the server. It may try variations on the address you provided, it may send a query for whatever you typed in to your favourite search engine, or it may display an error page/dialog. The point being, lots of people use "404" to mean any kind of error, whether it's a broken server or a missing resource or a host that doesn't exist; but that's technically wrong (the best kind of wrong).
This isn't too big a deal for web browsing, aside from overriding the user's preferences. But there are uses for DNS other than the world wide web, and there is no way for their DNS server to know whether you're looking up a website address or an SMTP server or a DNS server or an FTP server or anything else. This means that in order to provide this "feature" for mis-typed web requests, they fuck up everything else that does DNS lookups. Sometimes they try to implement workarounds to limit the damage it causes to other protocols, but they're always just workarounds and therefore "less good" than simply not screwing with the semantics of DNS in the first place. Remember when VeriSign did this and fucked up their fake SMTP server?
I don't really have a problem with OpenDNS doing this, as they're upfront about it and if people are willing to risk the problems this may cause for whatever benefit they perceive they're receiving, then that's their choice. The problem with ISPs "forcing" it on unknowledgeable users is that if they do have problems because of it, they're not likely to have any idea what's gone wrong or that the weird shit going on is because their ISP or whoever decided to try to monetize typos. After all, if your mail client says "connection refused" or "connection timed out" or "access denied, check your username and password", it's going to take you a lot longer to realise you've mistyped the server name than if it said "host does not exist".
You might be happy having other people subsidising your internet usage, but the other lighter users probably aren't that happy about paying more so you can download whatever it is you download.
I'm glad you qualified your position with "Personally", but in the scheme of things it seems a bit ridiculous to have pricing that absolutely relies on people not actually using the full service that they're paying for. Put simply: the ISPs are advertising something they cannot possibly deliver, and are relying on people simply not being able to find enough to do on the internet so they don't have to provide the service they sold their customers.
Okay, these might very well be a particular case where binary-only drivers are the best solution. I never claimed that requiring all drivers to be GPL or else be more annoying to support and use was a perfect solution that wouldn't cause any problems; merely that having additional motivation to opt for open drivers rather than proprietary may provide a nett benefit to consumers in the long run.
The changing ABI may well present an unnecessary barrier for these kinds of devices, but it's certainly not insurmountable; and the problems this causes may prove to be a worthwhile price to pay for the benefits that it brings in other areas.
Even better, this kind of pressure might lead to the improvement of development tools and methodologies such that it becomes viable for relatively small groups of volunteers to design and implement the software needed to perform these complex tasks. This would certainly suck for the people who currently make a living doing this, but most forms of progress usually do suck for someone.
Anyway, as you say, you're not really in the hardware business - you're writing and selling software for niche hardware. Just like with normal software, the more widespread the need for it is, the less likely you'll be able to compete with what's freely available. MS Office will probably no longer be sold in 10 or 20 years, because the free alternatives will have diluted the market so much that it's no longer viable to expect a return on the costs of development. But so long as you can find a small enough niche, it's unlikely free alternatives of sufficient quality will exist, so you will be able to sell software to fill that need.
Well the article is a bit light on details and I can't be bothered researching any more, but if all the guy did was write the software then it's entirely plausible he didn't do anything technical illegal, in a "guns don't kill people, people do" kind of way.
On the other hand, he almost certainly knew exactly what the software he was writing was being used for, so it'd be like selling guns to people you knew were committing armed robberies.
If that's the case, then maybe the prosecution simply tried to get him for the wrong crime. Just like if someone brought charges of armed robbery against someone selling guns, I would expect them to be thrown out by the judge (though one would imagine such an obviously false charge wouldn't make it to court in the first place).
I don't know if NZ law will allow them to try again with a more appropriate charge or not.
Well it comes down to marketshare, and the core assumption that Linux will continue to gain marketshare. Hardware vendors are in the business of making money, and they do that by selling hardware people want to use. If a lot of their potential customers are running Linux, then they'll definitely want their hardware to support Linux one way or another.
That's basically all it comes down to: "one way or another". By making it a little harder to release binary-only drivers, you provide encouragement to take the alternate approach.
Does it really seem unreasonable to be able to sell a closed-source driver for that device?
It's not unreasonable at all, if there's a market for it. It comes down to creating an environment that maximises the benefits to the majority (i.e. consumers) rather than the minority (producers). It's no secret that people are willing to pay good money for things they want, and if the environment is such that the easiest way to meet that demand is by selling hardware with open-source drivers, then that's what the producers will do.
Don't forget that Linux itself required dozens of developers working on it for years to get to where it is now, and people actually make money selling boxed copies of it with a bunch of other free software. But most of the big investments are coming from people who are selling hardware that Linux can run on, because they know the better it supports their hardware, the more attractive their hardware will be to buyers who want to run Linux.
Whether or not a particular HBA will have the critical mass needed to make such a driver more feasible if it's open than closed is another matter. The fact that using binary-only drivers is more annoying does create an incentive for vendors to have drivers supporting their hardware included in the mainline kernel, and makes it easier to obtain that critical mass. Certainly, if I'm purchasing a server to run Linux on there would have to be a very, very compelling reason to get one with hardware that would only work fully if supported by a binary-only driver, and that's a direct result of the current policy.
Devices where the driver defines the functionality of the device...
These cases are, IMHO, a particularly good example of how consumers would benefit from open drivers, because it forces the manufacturers to compete purely at the hardware level: performance (optimized paths for certain features, processor speed, memory size), quality (reliability, heat production) and cost are the only ways to differentiate yourself from your competitors. While this certainly does make things harder for producers, tougher competition does tend to benefit society as a whole. There's also the potential for additional beneficial side-effects: older hardware can be made to last longer, limited only by its actual capabilities and not the vendor's desire to make it obsolete by not supporting it.
Any intelligent person making that argument is really saying that they think all drivers should be GPL.
Which may well be the reason -- it seems reasonable to me that an intelligent person could indeed believe that, in the long run, making it too easy for vendors to provide binary-only drivers would hurt Linux in particular, and users of computers in general. Especially if one is also of the belief that operating systems will eventually become "commoditized" and there'll be no money to be made from selling them.
A similar theory is that a "constantly" changing ABI requires (okay, encourages) any hardware vendor who does decide to release binary-only drivers to keep them up-to-date, rather than release it and leave it untouched for 3 years while still claiming "full Linux support*", where the * means "except for features less than 3 years old".
I think it almost certainly hurts Linux in the short term, but in the long term it may be for the better. There's definitely an "open source" trend starting to build. Not that long ago the idea of an open source phone was ridiculous, but now there's Google's Android platform and Nokia and friends are open-sourcing Symbian. There's a lot of good reasons for hardware manufacturers to want quality, fully-featured open-source drivers for their hardware.
It depends on how the NAT device assigns port numbers to outgoing queries. Apparently the fix for this flaw is to ensure the source port for lookups is truly random; some devices may use very predictable sequences (such as our Cisco ASA at work, mutter mutter).
If you visit Dan Kaminsky's blog, there's a DNS checker in the right hand panel which allegedly tells you if you need to worry or not. It just looks to see if all your queries for their test domain name came from the same port number.
Slashdot Mirror
I don't think it's privacy that needs to be sacrificed, but ease of access. All the popular instant messaging systems, forum and blog software etc. are subject to spam. If it was harder to obtain an address on these services, it would be much harder for spammers to abuse them.
On the other hand, ease of access is one of their primary benefits. An additional hurdle for SMTP is the lack of centralised controls, which is an important thing for any de facto standard communication tool to have.
Unfortunately it.slashdot.org has already been poisoned; you actually posted that request to an elaborate mock-up of the real slashdot, and the replies are coming from l33t hackers who are supplying you with false DNS servers which currently appear to work correctly.
You'd best disconnect from the internet and burn your computer. It's the only way to be sure.
While we're bitching about Microsoft, what the fuck is up with the description for these patches?
A security issue has been identified that could allow a remote attacker to misrepresent a system action or behavior unbeknownst to users on Microsoft Windows systems.
They could at least mention something about DNS so you know what the patch is actually for without having to read the info on their site.
Interesting... I don't think it's quite that easy though.
Let's say a client wants to know the address of www.cs.example.edu, so it asks the nameservers for example.edu
Being a large university, the cs subdomain is delegated to the CS department's name servers. For whatever reason, they're not actually under .cs, so the (legitimate) server sends back:
Now, the query was for www.cs.example.edu, so the name servers are outside of bailiwick. We just ignore these records? Obviously not - we've just received a delegation to them, so knowing their addresses would be nice. Okay, so we drop any additional records unless they're providing us data we need, such as the addresses of name servers we've just received delegation info for?
But, what if an attacker knows we'll do that, and so it spoofs a reply:
How does the resolver know this is an invalid response? It asked what it believes to be the authoritative nameserver for example.edu how to find www.cs.example.edu, and it's received a response delegating it to another server. It's also provided the address of that other server.
Let's get more interesting: we want to poison www.example.edu, after all. So maybe instead of our attacker feeding us a bogus name server for www.cs.example.edu, it just feeds us a bogus name server for example.edu:
Okay, now we have an additional name server for the domain. With a really long TTL. Eventually we'll forget about the name servers, but this entry should remain for some time.
Not quite as easy as directly poisoning the target cache, but running a name server isn't difficult. We could also provide a name server in a different domain. It'll need to be properly delegated but registering domains isn't all that tricky.
I thought the general consensus was that the use of nuclear weapons against Japan actually saved a lot of lives. Warfare was still very, very bloody back then, and the Allies were facing an island assault (which is bad enough), against the enemies homeland (which is even worse). The Japanese weren't exactly known for surrendering peacefully, no matter how obvious it was they were going to lose. Remember Iwo Jima?
Of the 21,000 Japanese soldiers present at the beginning of the battle, over 20,000 were killed and only 216 taken prisoner.
There's a hell of a lot of soldiers on both sides of the fence who owe their lives to the use of nuclear weapons; and that's without considering the likely but unprovable theory that this show of force prevented other conflicts from even occurring. It's even possible that, without a "live fire" example of how horrific nuclear weapons are, the cold war may not have been so cold.
Fair enough, but how does one obtain the public key for each host you're talking to?
I don't know the details of how DNSSec is implemented, but my understanding is that the public keys are obtained through DNS. While it does mean an attacker probably only gets one shot at poisoning a resolver (because once it has the real public key it'll ignore anything the attacker sends it), if it does succeed then the resolver will ignore anything the real DNS server sends it.
That suggests you do need some kind of trust relationship so that when you receive a public key you can tell if it's the real deal or a fake one.
Also, yesterday I was reading about the problem of DNSSec making your entire zone walkable. This was basically because the NXDOMAIN responses had to be signed so you could trust them, but couldn't actually be signed because it's generally considered bad practice for a live DNS server to have the private key (the zones should be signed offline, then transferred to the DNS server). If this is the case, how does a DNS server decrypt messages encrypted with its public key?
My understanding is that they wouldn't; requests wouldn't be encrypted, but the responses are signed and that's how the resolver can determine whether the response is genuine or not.
I reckon this is the approach I'd take. C is simple, low-level enough that you get a good feel for how a computer really works, and similar enough to other languages that a lot of the stuff you learn can be re-used.
I started with BASIC, which teaches bad habits. You can learn bad habits in C, but you don't have to.
When I taught myself C, it was purely for writing games. And back then, you had a wonderful VGA framebuffer that you wrote values to and shit appeared on the screen. That was seriously awesome.
Nowadays, there's a lot of abstraction to allow for hardware acceleration and windowing and multitasking and all that other bullshit you didn't have to think about in DOS. SDL is the closest to "bare metal" you can probably get without making your son think you're making him use primitive computers nobody uses any more. Depending on why he's interested in the first place, this might be important.
Using SDL you can start really simply as I said before, treating the surface as a simple framebuffer and manipulating it directly. If he's interested in game programming, he's gonna have to learn a lot of math, so teaching him how to draw circles and lines by plotting the pixels manually might be a nice way to make it not seem so horrible. Plus, if you know what every part of the program does (even if it's primitive and your monsters are boxes and the player is a cross) you'll feel more of a sense of accomplishment than if you use some framework that does all the heavy lifting for you.
The other good thing about SDL is that lots of other people use it and there are lots of libraries to do various forms of heavy lifting, so if it turns out his interest is more casual and even the site of code for drawing antialiased lines makes him lose interest, you can then pull in some useful libraries to do the mundane things and he can still have fun with it.
Or, if you want to fuck with his head you can just teach him OpenGL and 3D programming from the start. It's likely it'll fry his brain, but if he survives he might become the next John Carmack.
BIND supports DNSSec; DNSSec is about cryptographically signing your DNS entries so resolvers know that the response they got was from the legitimate authoritative server for the domain.
This means that it's not something you can "just patch" - it actually requires people to do some work, which means it'll take a very long time to actually be widely deployed (by "people" I mean "every single person who administers one or more DNS zones"). You also have the usual problems with crypto, i.e. establishing a "web of trust" (it's all very well if records under google.com are signed, but how do you know they're signed by Google?).
Solvable problems, but inertia is a powerful force.
Wow, the grammar in that post really sucks. Sorry.
Well that would work, although since VeriSign's "SiteFinder" stunt some DNS servers (including bind) have an option to denote a zone as being "delegation only" zone, which would stop this attack from working. I don't know how widespread use of this option would be, though.
Assuming it's not, than poisoning .com would make it much easier: with one successful attack you could poison dozens of popular domains.
What could be interesting is combining this attack with zombies -- that way you don't need to trick a user into visiting a site with your links on it, you can just spam the ISPs name servers from one (or several) of their clients until you finally get lucky. Even better, the larger the ISP the more likely one of your randomly infected zombies will be within their network.
You could also have the ISP name server do some queries against a DNS server you control so you can look for any patterns in the query IDs and source ports, and use that information to narrow the search space for your actual attack.
I'm not really seeing any solutions to these attacks that don't simply turn it into an easy DoS. Fun times are ahead!
This doesn't cause problems for you, because if you read what Blindman wrote, they only use it for sites that don't work with Firefox. If you're creating web pages that are anywhere close to being modern, then you won't see hits from any version of IE from people like us.
It's not installations that matter, it's what people actually use.
Sorry, but they're actually pictures of houses they're planning to rob, and cars they're planning to steal.
Just did a search and some of them seem to be returning errors now - nothing like getting your problems published on slashdot to motivate people to fix them!
So are these services purely to allow people with MMS-incapable phones to see messages (I remember getting an SMS with a URL to view the message once upon a time with Telstra), or for sharing them?
If it's the former then requiring authentication might be possible, but that'd be a real pain for the latter. Having random, unguessable paths as unique keys is about all you can do without crippling the ability to share them.
Surely if they're relying on having unguessable URLs they wouldn't have any way to retrieve a list of them, so I guess this all stems from people publishing links to (private?) messages on public sites. At least, I hope that's the case.
The clearest way is whatever way you learned first when you were learning to code.
Not always, when I learned C I used "K&R" style braces (i.e. on the same line as the if/else clause), but switched to "GNU" style braces (vertically aligned) after a few years because of encountering code that used that style and deciding I preferred it.
There's good arguments for and against both styles, IMHO, so it just comes down to personal preference as you say.
Hmm, it looks to me like the main difference w.r.t. readability is that you added an extra blank line before and after the else in the C/C++ version, which you didn't have in the Perl version. That makes it stand out quite a bit.
I also much prefer aligning the {}'s vertically.
It's annoying because it does change behaviour at a more technical level.
With non-hijacked DNS, if you enter a non-existent hostname, you DO NOT receive a "404" error. "404" is an HTTP status code which means "not found". This can only be generated by a web server and only makes sense in the context of requesting a resource from a web server, and the server decides it does not exist.
It follows from this that if the hostname does not exist, then you can't connect to a webserver at the address (because there is no address), and therefore it is completely impossible for you to receive a "404 error". Instead, your browser (or proxy) discovers the DNS lookup returned "non-existent domain", and does something other than trying to connect to the server. It may try variations on the address you provided, it may send a query for whatever you typed in to your favourite search engine, or it may display an error page/dialog. The point being, lots of people use "404" to mean any kind of error, whether it's a broken server or a missing resource or a host that doesn't exist; but that's technically wrong (the best kind of wrong).
This isn't too big a deal for web browsing, aside from overriding the user's preferences. But there are uses for DNS other than the world wide web, and there is no way for their DNS server to know whether you're looking up a website address or an SMTP server or a DNS server or an FTP server or anything else. This means that in order to provide this "feature" for mis-typed web requests, they fuck up everything else that does DNS lookups. Sometimes they try to implement workarounds to limit the damage it causes to other protocols, but they're always just workarounds and therefore "less good" than simply not screwing with the semantics of DNS in the first place. Remember when VeriSign did this and fucked up their fake SMTP server?
I don't really have a problem with OpenDNS doing this, as they're upfront about it and if people are willing to risk the problems this may cause for whatever benefit they perceive they're receiving, then that's their choice. The problem with ISPs "forcing" it on unknowledgeable users is that if they do have problems because of it, they're not likely to have any idea what's gone wrong or that the weird shit going on is because their ISP or whoever decided to try to monetize typos. After all, if your mail client says "connection refused" or "connection timed out" or "access denied, check your username and password", it's going to take you a lot longer to realise you've mistyped the server name than if it said "host does not exist".
I think they meant, if you want an iPhone there's no competition between carriers: you can only get it through O2.
You might be happy having other people subsidising your internet usage, but the other lighter users probably aren't that happy about paying more so you can download whatever it is you download.
I'm glad you qualified your position with "Personally", but in the scheme of things it seems a bit ridiculous to have pricing that absolutely relies on people not actually using the full service that they're paying for. Put simply: the ISPs are advertising something they cannot possibly deliver, and are relying on people simply not being able to find enough to do on the internet so they don't have to provide the service they sold their customers.
Okay, these might very well be a particular case where binary-only drivers are the best solution. I never claimed that requiring all drivers to be GPL or else be more annoying to support and use was a perfect solution that wouldn't cause any problems; merely that having additional motivation to opt for open drivers rather than proprietary may provide a nett benefit to consumers in the long run.
The changing ABI may well present an unnecessary barrier for these kinds of devices, but it's certainly not insurmountable; and the problems this causes may prove to be a worthwhile price to pay for the benefits that it brings in other areas.
Even better, this kind of pressure might lead to the improvement of development tools and methodologies such that it becomes viable for relatively small groups of volunteers to design and implement the software needed to perform these complex tasks. This would certainly suck for the people who currently make a living doing this, but most forms of progress usually do suck for someone.
Anyway, as you say, you're not really in the hardware business - you're writing and selling software for niche hardware. Just like with normal software, the more widespread the need for it is, the less likely you'll be able to compete with what's freely available. MS Office will probably no longer be sold in 10 or 20 years, because the free alternatives will have diluted the market so much that it's no longer viable to expect a return on the costs of development. But so long as you can find a small enough niche, it's unlikely free alternatives of sufficient quality will exist, so you will be able to sell software to fill that need.
Well the article is a bit light on details and I can't be bothered researching any more, but if all the guy did was write the software then it's entirely plausible he didn't do anything technical illegal, in a "guns don't kill people, people do" kind of way.
On the other hand, he almost certainly knew exactly what the software he was writing was being used for, so it'd be like selling guns to people you knew were committing armed robberies.
If that's the case, then maybe the prosecution simply tried to get him for the wrong crime. Just like if someone brought charges of armed robbery against someone selling guns, I would expect them to be thrown out by the judge (though one would imagine such an obviously false charge wouldn't make it to court in the first place).
I don't know if NZ law will allow them to try again with a more appropriate charge or not.
Well it comes down to marketshare, and the core assumption that Linux will continue to gain marketshare. Hardware vendors are in the business of making money, and they do that by selling hardware people want to use. If a lot of their potential customers are running Linux, then they'll definitely want their hardware to support Linux one way or another.
That's basically all it comes down to: "one way or another". By making it a little harder to release binary-only drivers, you provide encouragement to take the alternate approach.
Does it really seem unreasonable to be able to sell a closed-source driver for that device?
It's not unreasonable at all, if there's a market for it. It comes down to creating an environment that maximises the benefits to the majority (i.e. consumers) rather than the minority (producers). It's no secret that people are willing to pay good money for things they want, and if the environment is such that the easiest way to meet that demand is by selling hardware with open-source drivers, then that's what the producers will do.
Don't forget that Linux itself required dozens of developers working on it for years to get to where it is now, and people actually make money selling boxed copies of it with a bunch of other free software. But most of the big investments are coming from people who are selling hardware that Linux can run on, because they know the better it supports their hardware, the more attractive their hardware will be to buyers who want to run Linux.
Whether or not a particular HBA will have the critical mass needed to make such a driver more feasible if it's open than closed is another matter. The fact that using binary-only drivers is more annoying does create an incentive for vendors to have drivers supporting their hardware included in the mainline kernel, and makes it easier to obtain that critical mass. Certainly, if I'm purchasing a server to run Linux on there would have to be a very, very compelling reason to get one with hardware that would only work fully if supported by a binary-only driver, and that's a direct result of the current policy.
Devices where the driver defines the functionality of the device...
These cases are, IMHO, a particularly good example of how consumers would benefit from open drivers, because it forces the manufacturers to compete purely at the hardware level: performance (optimized paths for certain features, processor speed, memory size), quality (reliability, heat production) and cost are the only ways to differentiate yourself from your competitors. While this certainly does make things harder for producers, tougher competition does tend to benefit society as a whole. There's also the potential for additional beneficial side-effects: older hardware can be made to last longer, limited only by its actual capabilities and not the vendor's desire to make it obsolete by not supporting it.
Does that mean it should be "Score: -5, Wikipedia Geek"?
Any intelligent person making that argument is really saying that they think all drivers should be GPL.
Which may well be the reason -- it seems reasonable to me that an intelligent person could indeed believe that, in the long run, making it too easy for vendors to provide binary-only drivers would hurt Linux in particular, and users of computers in general. Especially if one is also of the belief that operating systems will eventually become "commoditized" and there'll be no money to be made from selling them.
A similar theory is that a "constantly" changing ABI requires (okay, encourages) any hardware vendor who does decide to release binary-only drivers to keep them up-to-date, rather than release it and leave it untouched for 3 years while still claiming "full Linux support*", where the * means "except for features less than 3 years old".
I think it almost certainly hurts Linux in the short term, but in the long term it may be for the better. There's definitely an "open source" trend starting to build. Not that long ago the idea of an open source phone was ridiculous, but now there's Google's Android platform and Nokia and friends are open-sourcing Symbian. There's a lot of good reasons for hardware manufacturers to want quality, fully-featured open-source drivers for their hardware.
It depends on how the NAT device assigns port numbers to outgoing queries. Apparently the fix for this flaw is to ensure the source port for lookups is truly random; some devices may use very predictable sequences (such as our Cisco ASA at work, mutter mutter).
If you visit Dan Kaminsky's blog, there's a DNS checker in the right hand panel which allegedly tells you if you need to worry or not. It just looks to see if all your queries for their test domain name came from the same port number.
I couldn't for the life of me get NT working on that box ;)
Undoubtedly, but that has nothing to do with processor bugs.