Initially, Pandora's count of the number of songs you skipped was kept on the client, so reloading the page reset the number of songs you were allowed to skip. That seems to have been fixed now, but it was interesting while it lasted. Your workaround for Pandora's geographic limitations is in the same vein --- it'd have been easy for Pandora to make it work differently, but they didn't.
Considering the otherwise great quality of Pandora, I think their programmers just really don't like these restrictions, and implement them in the most half-assed way possible. Kudos to them.
Okay --- so the executable verifies itself to ensure its watermark hasn't been tampered with, right? So just edit out the portion that checks the watermark. Problem solved.
Your post demonstrates my point perfectly: the colon-separated hex notion screws up URL parsing, requiring algorithm changes for everyone, and as you see, lots of people still haven't gotten it right. Dotted-quad notation wouldn't have required nearly as much effort. The new notation was an unnecessary barrier to adoption.
We're talking about Joe Sysop and Joe Programmer, whose opinions regarding IPv6 are far more important than Joe Plumber's. These people see IPv6 as something exotic and frightening, and try to avoid it as long as they can. IPv6 should have been made as similar to IPv4 as possible; instead, the IETF tried to do too much too fast, and now we're paying the price.
Part of the reason some people feel more secure with NAT is that it's not possible to implement an "allow all" button. The closest thing would be a DMZ facility, but even that requires proactively designating a machine behind the NAT to receive the traffic. Some people feel more secure knowing that even if the firewall wanted to, it couldn't "just allow" all traffic through, but would require some active configuration to create a danger.
This attitude is a shortsighted and dangerous, but it's one reason NAT has so many fans.
You've hit the nail on the head. NAT dovetails very nicely with the "castle mentality" many network administrators have: this is mine, and you can't touch it. It's about control, and there are fewer more tangible symbols of control than your own network numbering scheme. Nobody wants to give up that sense of control by moving to IPv6.
But since 2005, you don't have to: IPv6 now has private address ranges just like IPv4's. Also, NAT has always worked with IPv6.
Since 2005, all four combinations of address spaces can work in principle: IPv4 inside, IPv4 outside, IPv6 outside; IPv4 inside; IPv6 outside, IPv4 inside (with DNS proxying), and obviously, IPv6 inside with IPv6 outside.
Whether this "castle mentality" is appropriate is a different debate. Moving to IPv6 for the public internet is too important to get bogged down in talking about NAT.
Me, I would have preferred to extend the dotted-quad notation over using the colon-separated hex format usually used for IPv6. Dotted quads look more familiar for network administrators, software developers, and so on. As you noted, IPv6 addresses look strange and scare people. This fear of the unknown is a barrier to adoption. Any unnecessary break with IPv4 hurts IPv6 adoption, and we can't afford that; IPv6 with dotted quads is better than IPv4.
You know this. I know this. But plenty of people don't, and the fact that we're even having an argument about this fact highlights the IETF's profound lack of pragmatism. People want their safety blankets, and ff the IETF hadn't opposed NAT and private networks in IPv6, we'd see much better adoption by now.
We could have tackled the NAT issue at a later time. One of the universal and timeless principles of change is to pick your battles. The IETF decided to fight for adopting IPv6 and eliminating NATs at the same time, and until they gave up on the latter, were badly losing both fights.
Try running multiple servers on multiple machines behind the same NAT, where one would like them to be accessible to the outside world via default port numbers.
To be fair, you can use a reverse proxy for this.
*IF* for some reason that didn't involve how many IP's you actually have available, you still wanted to utilize NAT for some reason, you still could do that with ipv6... no problem at all.
You can, but people were told for ages they couldn't. That's actually a big factor opposing IPv6's adoption.
Lots of smart, but idealistic IPv6 designers considered private networks harmful, and wanted to eliminate them from IPv6. They thought that by saying "no, there's no support for private networks, and you don't need them anyway", people would start making addresses public again.
They were right, but saying that wasn't very smart. RFC1918-style networks are safety blankets for network administrators, and when the IPv6 people threatened to take them away, they were terrified. Instead of moving to IPv6 and making their networks publicly-numbered, administrators stayed with IPv4. It's a classic case of perfect being the enemy of good.
Finally, in 2005, the IPv6 people realized the value of pragmatism and set aside reserved addresses with RFC4193. However, the delay and initial opposition to private networking has retarded IPv6 adoption by several years, at least.
You jest, but I'd love more integration. Why shouldn't I be able to connect to my cold, frozen car with a web browser and adjust the climate controls?
Why shouldn't I be able to wirelessly check how much milk I have in the refrigerator and pick some more up on the way home? (Or more likely to me, the refrigerator could tell me "you let your milk expire again, you idiot").
It's perfectly reasonable to configure a firewall to block everything by default and open small holes, just as you do with NAT. If you're relying on NAT to keep your network safe from incompetent network administrators, you have far bigger problems.
People are always willing to put up with a certain level of mediocrity as long as they don't have to think. We see it all the time with people using computers chock-full of spyware. Google Maps reloading won't be a problem for people until it actually takes less time to look up a route on paper.
Changing to IPv6 is hard. If there's any amount of incompatibility, we'll see something like the Digital TV debacle --- just think about the hoopla around that one and consider:
Most people have cable or satellite and aren't affected by the change
The government is subsidizing converter boxes for everyone else
Any change to IPv6 is going to be far worse --- and unlike in the Digital TV case, there's no spectrum freed up by the switch, which means no large moneyed interests pushing for the change.
Thus, the change to IPv6 must be automatic and transparent. Here are a few preconditions:
Existing "routers" must keep working: if an IPv4 customer plugs his IPv4-only NAT "router" into his IPv6 network, that device must keep working, or customers will complain. Most likely, some sort of proxying or tunneling will be required, and customers will get RFC1918 addresses.
IPv4 computers attached to IPv6 routers must keep working: that means that if a home NAT box connects to an ISP and gets an IPv6 address, it'll still have to hand out an RFC1918 IPv4 addresses to any connected host that asks for one. It'll have to do some tunneling or proxying so that the IPv4 machine "keeps working". People will return "routers" that break their Windows 98 machines.
IPv6 must be pitched as a beneficial feature: "routers" should have light-up "IPv6" logos so customers get a fuzzy, good feeling. Only later can certain sites risk being IPv6-only, and only much later can IPv6-only devices be marketable.
Taking advantage of IPv6, when present, must be automatic: if operating systems require any configuration beyond what you need for IPv4, people will just choose IPv4. IPv6 must be detected and used automatically.
A good model is the adoption of new mobile phone protocols. Old phones just kept working, and new ones transparently used either the old or the new protocol, but prominently showed the user which one he was using. Only recently was the old AMPS system turned off; we'll be stuck with GSM for a while longer. But these old systems don't cause much harm to the newer ones, so keeping them around is an acceptable price for progress.
You're aware that any decent firewall can filter packets without NATing them, right? The big problem with public IPs for everyone isn't access control, but network renumbering.
While I'm glad these guys were shut down, Mastercard and Visa shouldn't have had to do it. This case constitutes outright fraud, and the perpetrators should be punished like other criminals: with handcuffs, a jury, and iron bars.
We used to have strong consumer protection agencies. Then something happened. How many more electronic Elixir Sulfanilamide incidents (or real ones for that matter) do we need before we re-create the strong and sensible regulatory bodies that used to protect us?
I'll confess that I haven't used Drupal. But shouldn't any self-respect web framework in 2009 not put source code under a publicly-accessible directory? I mean --- that's basic. People knew not to do that 15 fucking years ago.
"If the documentation guarantees something, the implement should guarantee it" does not imply "if the document does not guarantee something, the implementation should not guarantee it."
Nor does "there is no stated guarantee now" imply "there should be no stated guarantee in the future."
The simple truth is that any self-respecting journaling filesystem should guarantee atomicity on rename.
Austrian School economists dismiss the use of empirical data and math in their analysis, and they make no concrete predictions. That's not science: it's mysticism.
Furthermore, laissez-faire has been tried to a great degree at various points in US history: consider the late 19th and early 21st centuries. Yes, some regulation remained, but if Laisse-Faire were really the way to go, you'd think the economy would improve as regulations weakened. The opposite happened: as regulations weakened, the economy started overheating and creating repeatedly.
Saying we should try real laissez-faire is like saying "okay, breaking one bone was bad, sure. But breaking every bone has never been tried. Let's do that."
Money laundering. Over at Wikileaks, there's a fascinating letter written by a member of the child pornography community. The author goes into quite a bit of detail about the overall organization and operation of the black hat community. You should take the letter with a grain of salt, of course, but it's certainly very interesting.
Read some of my other comments in this article. If you have read them, you haven't understood them.
I'm not asking for transactions, though they'd be nice too. I'm saying that filesystems should respect the implicit write barrier that rename has always represented. UFS with soft-updates maintains a dependency graph and ensures data blocks are written before meta-data ones. Old non-journaled filesystems managed to get rename right anway. ext3 manages to do the right thing as well. ZFS goes far beyond what I'm proposing, actually, and guarantees the relative order of every write. The problem filesystems are XFS, JFS, and ext4.
I'm not telling application developers to use a database; I'm explaining what's driving a remark others have made. Application developers can use whatever suits their need. If a database is what they want, then sure, use one. If something else is better, use that.
It's absolutely ridiculous to require the full power of a database in order to atomically update the content of a file with decent performance.
Actually, yes he does, because the operation he's requesting is to destroy the only known-good file. It's not the OS's fault that the programmer didn't actually make sure his new copy was good before he destroyed the old one.
No: taken as a whole, the operation the programmer is requesting is to atomically replace the content of the file. He doesn't need that to happen now. The programmer only requires that the file being manipulated is not left in an invalid state if and when the operation is committed to disk; i.e., atomicity. fsync expresses an entirely different requirement, that the data be written now; i.e., durability.
Data-before-rename isn't just an automatic fsync when rename is called. That's one way of implement a barrier, but far from the best. Far better would be to keep track of all outstanding rename requests, and flush the data blocks for the renamed file before the rename record is written out. The actual write can happen far in the future, and these writes can be coalesced.
In fact, you can't even implement what I'm talking about in terms of filesystem transactions. Barriers are separate beasts.
Say you're updating a few hundred small files. (And before you tell me that's bad design: I disagree. A file system is meant to manage files.) If you were to fsync before renaming each one, the whole operation would proceed slowly. You'd need to wait for the disk to finish writing each file before moving on to the next, creating a very stop-and-go dynamic and slowing everything down.
On the other hand, if you write and rename all these files without an fsync, when the commit interval expires, the filesystem can pick up all these pending renames and flush all their data blocks at once. Then it can write all the rename records, at once, much improving the overall running time of the operation.
The whole thing is still safe because if the system dies at any point, each of the 200 configuration files will either refer to the complete old file or the complete new file, never some NULL-filled or zero-length strangelet.
I wasn't trolling, dammit. A troll rating is not another way of saying "I disagree with this comment". If you disagree with a comment, reply, or say nothing if you don't want to erase your previous moderation. A troll disrupts the flow of conversation, which my comment did not.
No, users still win. Flash isn't a magical locked-down proprietary fairyland. There's no way for an application written in Flash to ensure it's being run on Adobe Flash and not, say, an improved and hacked-up Gnash.
Hrm. I didn't realize the public key was that weak. Thanks for informing me.
In that case, the simpler and more conventional thing to do would be for Amazon to just sign all ebooks, and for the Kindle to verify Amazon's signature before decrypting an E-Book.
Slashdot Mirror
Initially, Pandora's count of the number of songs you skipped was kept on the client, so reloading the page reset the number of songs you were allowed to skip. That seems to have been fixed now, but it was interesting while it lasted. Your workaround for Pandora's geographic limitations is in the same vein --- it'd have been easy for Pandora to make it work differently, but they didn't.
Considering the otherwise great quality of Pandora, I think their programmers just really don't like these restrictions, and implement them in the most half-assed way possible. Kudos to them.
Okay --- so the executable verifies itself to ensure its watermark hasn't been tampered with, right? So just edit out the portion that checks the watermark. Problem solved.
Your post demonstrates my point perfectly: the colon-separated hex notion screws up URL parsing, requiring algorithm changes for everyone, and as you see, lots of people still haven't gotten it right. Dotted-quad notation wouldn't have required nearly as much effort. The new notation was an unnecessary barrier to adoption.
We're talking about Joe Sysop and Joe Programmer, whose opinions regarding IPv6 are far more important than Joe Plumber's. These people see IPv6 as something exotic and frightening, and try to avoid it as long as they can. IPv6 should have been made as similar to IPv4 as possible; instead, the IETF tried to do too much too fast, and now we're paying the price.
Part of the reason some people feel more secure with NAT is that it's not possible to implement an "allow all" button. The closest thing would be a DMZ facility, but even that requires proactively designating a machine behind the NAT to receive the traffic. Some people feel more secure knowing that even if the firewall wanted to, it couldn't "just allow" all traffic through, but would require some active configuration to create a danger.
This attitude is a shortsighted and dangerous, but it's one reason NAT has so many fans.
You've hit the nail on the head. NAT dovetails very nicely with the "castle mentality" many network administrators have: this is mine, and you can't touch it. It's about control, and there are fewer more tangible symbols of control than your own network numbering scheme. Nobody wants to give up that sense of control by moving to IPv6.
But since 2005, you don't have to: IPv6 now has private address ranges just like IPv4's. Also, NAT has always worked with IPv6.
Since 2005, all four combinations of address spaces can work in principle: IPv4 inside, IPv4 outside, IPv6 outside; IPv4 inside; IPv6 outside, IPv4 inside (with DNS proxying), and obviously, IPv6 inside with IPv6 outside.
Whether this "castle mentality" is appropriate is a different debate. Moving to IPv6 for the public internet is too important to get bogged down in talking about NAT.
Me, I would have preferred to extend the dotted-quad notation over using the colon-separated hex format usually used for IPv6. Dotted quads look more familiar for network administrators, software developers, and so on. As you noted, IPv6 addresses look strange and scare people. This fear of the unknown is a barrier to adoption. Any unnecessary break with IPv4 hurts IPv6 adoption, and we can't afford that; IPv6 with dotted quads is better than IPv4.
Suit yourself, but I think it's important to get everyone on IPv6 now, and to wean them off NAT later.
You know this. I know this. But plenty of people don't, and the fact that we're even having an argument about this fact highlights the IETF's profound lack of pragmatism. People want their safety blankets, and ff the IETF hadn't opposed NAT and private networks in IPv6, we'd see much better adoption by now.
We could have tackled the NAT issue at a later time. One of the universal and timeless principles of change is to pick your battles. The IETF decided to fight for adopting IPv6 and eliminating NATs at the same time, and until they gave up on the latter, were badly losing both fights.
It has psychological benefits. It gives network administrators (especially incompetent ones) a sense of security and safety.
To be fair, you can use a reverse proxy for this.
You can, but people were told for ages they couldn't. That's actually a big factor opposing IPv6's adoption.
Lots of smart, but idealistic IPv6 designers considered private networks harmful, and wanted to eliminate them from IPv6. They thought that by saying "no, there's no support for private networks, and you don't need them anyway", people would start making addresses public again.
They were right, but saying that wasn't very smart. RFC1918-style networks are safety blankets for network administrators, and when the IPv6 people threatened to take them away, they were terrified. Instead of moving to IPv6 and making their networks publicly-numbered, administrators stayed with IPv4. It's a classic case of perfect being the enemy of good.
Finally, in 2005, the IPv6 people realized the value of pragmatism and set aside reserved addresses with RFC4193. However, the delay and initial opposition to private networking has retarded IPv6 adoption by several years, at least.
You jest, but I'd love more integration. Why shouldn't I be able to connect to my cold, frozen car with a web browser and adjust the climate controls?
Why shouldn't I be able to wirelessly check how much milk I have in the refrigerator and pick some more up on the way home? (Or more likely to me, the refrigerator could tell me "you let your milk expire again, you idiot").
It's perfectly reasonable to configure a firewall to block everything by default and open small holes, just as you do with NAT. If you're relying on NAT to keep your network safe from incompetent network administrators, you have far bigger problems.
People are always willing to put up with a certain level of mediocrity as long as they don't have to think. We see it all the time with people using computers chock-full of spyware. Google Maps reloading won't be a problem for people until it actually takes less time to look up a route on paper.
Changing to IPv6 is hard. If there's any amount of incompatibility, we'll see something like the Digital TV debacle --- just think about the hoopla around that one and consider:
Any change to IPv6 is going to be far worse --- and unlike in the Digital TV case, there's no spectrum freed up by the switch, which means no large moneyed interests pushing for the change.
Thus, the change to IPv6 must be automatic and transparent. Here are a few preconditions:
Existing "routers" must keep working: if an IPv4 customer plugs his IPv4-only NAT "router" into his IPv6 network, that device must keep working, or customers will complain. Most likely, some sort of proxying or tunneling will be required, and customers will get RFC1918 addresses.
IPv4 computers attached to IPv6 routers must keep working: that means that if a home NAT box connects to an ISP and gets an IPv6 address, it'll still have to hand out an RFC1918 IPv4 addresses to any connected host that asks for one. It'll have to do some tunneling or proxying so that the IPv4 machine "keeps working". People will return "routers" that break their Windows 98 machines.
IPv6 must be pitched as a beneficial feature: "routers" should have light-up "IPv6" logos so customers get a fuzzy, good feeling. Only later can certain sites risk being IPv6-only, and only much later can IPv6-only devices be marketable.
Taking advantage of IPv6, when present, must be automatic: if operating systems require any configuration beyond what you need for IPv4, people will just choose IPv4. IPv6 must be detected and used automatically.
A good model is the adoption of new mobile phone protocols. Old phones just kept working, and new ones transparently used either the old or the new protocol, but prominently showed the user which one he was using. Only recently was the old AMPS system turned off; we'll be stuck with GSM for a while longer. But these old systems don't cause much harm to the newer ones, so keeping them around is an acceptable price for progress.
You're aware that any decent firewall can filter packets without NATing them, right? The big problem with public IPs for everyone isn't access control, but network renumbering.
While I'm glad these guys were shut down, Mastercard and Visa shouldn't have had to do it. This case constitutes outright fraud, and the perpetrators should be punished like other criminals: with handcuffs, a jury, and iron bars.
We used to have strong consumer protection agencies. Then something happened. How many more electronic Elixir Sulfanilamide incidents (or real ones for that matter) do we need before we re-create the strong and sensible regulatory bodies that used to protect us?
I'll confess that I haven't used Drupal. But shouldn't any self-respect web framework in 2009 not put source code under a publicly-accessible directory? I mean --- that's basic. People knew not to do that 15 fucking years ago.
*sigh*
Can you people not grasp basic logic?
"If P, Q" does not imply "if not P, not Q".
"If the documentation guarantees something, the implement should guarantee it" does not imply "if the document does not guarantee something, the implementation should not guarantee it."
Nor does "there is no stated guarantee now" imply "there should be no stated guarantee in the future."
The simple truth is that any self-respecting journaling filesystem should guarantee atomicity on rename.
Sure: I'll decrease my standard of living, but I'll let you have the honor of going first.
Austrian School economists dismiss the use of empirical data and math in their analysis, and they make no concrete predictions. That's not science: it's mysticism.
Furthermore, laissez-faire has been tried to a great degree at various points in US history: consider the late 19th and early 21st centuries. Yes, some regulation remained, but if Laisse-Faire were really the way to go, you'd think the economy would improve as regulations weakened. The opposite happened: as regulations weakened, the economy started overheating and creating repeatedly.
Saying we should try real laissez-faire is like saying "okay, breaking one bone was bad, sure. But breaking every bone has never been tried. Let's do that."
i think that's the point. It will be a visible symbol of hegemonic domination.
Money laundering. Over at Wikileaks, there's a fascinating letter written by a member of the child pornography community. The author goes into quite a bit of detail about the overall organization and operation of the black hat community. You should take the letter with a grain of salt, of course, but it's certainly very interesting.
Read some of my other comments in this article. If you have read them, you haven't understood them.
I'm not asking for transactions, though they'd be nice too. I'm saying that filesystems should respect the implicit write barrier that rename has always represented. UFS with soft-updates maintains a dependency graph and ensures data blocks are written before meta-data ones. Old non-journaled filesystems managed to get rename right anway. ext3 manages to do the right thing as well. ZFS goes far beyond what I'm proposing, actually, and guarantees the relative order of every write. The problem filesystems are XFS, JFS, and ext4.
It's absolutely ridiculous to require the full power of a database in order to atomically update the content of a file with decent performance.
No: taken as a whole, the operation the programmer is requesting is to atomically replace the content of the file. He doesn't need that to happen now. The programmer only requires that the file being manipulated is not left in an invalid state if and when the operation is committed to disk; i.e., atomicity. fsync expresses an entirely different requirement, that the data be written now; i.e., durability.
Data-before-rename isn't just an automatic fsync when rename is called. That's one way of implement a barrier, but far from the best. Far better would be to keep track of all outstanding rename requests, and flush the data blocks for the renamed file before the rename record is written out. The actual write can happen far in the future, and these writes can be coalesced.
In fact, you can't even implement what I'm talking about in terms of filesystem transactions. Barriers are separate beasts.
Say you're updating a few hundred small files. (And before you tell me that's bad design: I disagree. A file system is meant to manage files.) If you were to fsync before renaming each one, the whole operation would proceed slowly. You'd need to wait for the disk to finish writing each file before moving on to the next, creating a very stop-and-go dynamic and slowing everything down.
On the other hand, if you write and rename all these files without an fsync, when the commit interval expires, the filesystem can pick up all these pending renames and flush all their data blocks at once. Then it can write all the rename records, at once, much improving the overall running time of the operation.
The whole thing is still safe because if the system dies at any point, each of the 200 configuration files will either refer to the complete old file or the complete new file, never some NULL-filled or zero-length strangelet.
I wasn't trolling, dammit. A troll rating is not another way of saying "I disagree with this comment". If you disagree with a comment, reply, or say nothing if you don't want to erase your previous moderation. A troll disrupts the flow of conversation, which my comment did not.
No, users still win. Flash isn't a magical locked-down proprietary fairyland. There's no way for an application written in Flash to ensure it's being run on Adobe Flash and not, say, an improved and hacked-up Gnash.
Hrm. I didn't realize the public key was that weak. Thanks for informing me.
In that case, the simpler and more conventional thing to do would be for Amazon to just sign all ebooks, and for the Kindle to verify Amazon's signature before decrypting an E-Book.