Really? I've chosen a salt consisting only upper & lower-case letters and digits. I then processed it like this:

echo -n "salt1234" | md5sum

The resulting MD5: e6f23ea50a901510fda62e4319e726ba

So, what's my salt?

It's even that puny MD5 hash that everyone keeps saying is broken (not that it isn't) so this should be easy for you.

That assumes that the salt is as trivially brute-forced as the license and medallion numbers. The reason this data could be brute-forced was because there's only so many possible license plate numbers, and that that 'many' is easy work for a computer. A proper salt would be as many bits as the hash itself, but computing 2^128 hash values requires more CPU time than anyone has.

That said, a hash is an overly-complex solution to this problem. Just take all the plate numbers, randomize them in a list, then just output their position in the list. "Plate #415" isn't going to be decoded into "HQD 1853" no matter what you do.

It turns out that figuring out if you have native IPv6 is kind of hard.

Every month or so I'd decide to check the modem to see if it was still in "IPv4-only" mode, and it was. Occasionally I'd plug my computer directly into the modem to see if it was able to get IPv6 access, but it wasn't. Whenever I had to call my ISP, I'd ask about IPv6 deployment, but they never had any idea what I was talking about.

Then one day I read an interesting fact on the internet: When the modem says it is in IPv4-only mode, that has nothing at all to do with whether I have IPv6 access. It's just in reference to how the modem communicates with the ISP's servers to get its configuration data. Other than that, it's just a bridge and passes along any packets it happens to receive regardless of any mode it might be in. So the only thing you need to worry about with regard to the modem is whether it is DOCSIS 3.0, as apparently most of the 2.0 modems drop IPv6 packets just for shits and giggles. That or they pass them just as easily, and everyone is just confused.

Then I read about someone discovering their IPv6 when they ran "tcpdump -n ip6" and saw some IPv6 packets. This seemed like an entirely worthwhile thing to try, and so I did, and to my surprise, I saw some IPv6 packets.

At first I assumed it wasn't actually usable, but that I was just seeing some stray packets from the ISPs work on deployment that wasn't complete yet. However, I was curious what was going on, so I studied the packets for a while. There were quite a lot of ARP packets, requesting responses from numerous global and link-local addresses, all being sent from a link-local address. So I tried pinging that address, and I got a response.

After quite a lot of work I eventually figured out that it was working IPv6 access, but that Linux simply wasn't picking up on it because for some idiotic reason, when configured as a router, it ignores router advertisement packets. You can override this setting, but it's the default, and why the setting exists at all is a mystery, since routers need to know where to send packets just as much as any other computer. My guess is that most of the testing was done via tunnels, and you don't need to accept router advertisements when you're routing through a tunnel because you set the route up manually, and so someone thought that all routers would have manually configured routes and so to accept router advertisements on a router would be a mistake.

Does such a thing exist?

I looked at the ones at Wal-Mart just last night. Only about 1/4 of them supported IPv6, and they were the $150 models. The others made no mention of IPv6 anywhere on the box, except for one which mentioned that it supports "IPv6 pass-through," but I have no idea what good that does for you unless you plan to simply use your new router as a switch (I don't think Wal-Mart sells switches, so maybe you do) and have your actual router somewhere inside your LAN.

We will probably see something like that, but they are actually upgrading to IPv6. I have native IPv6 with Time Warner, and I live in a stupid small town no one cares about. However, you can't have "dual stack" without an IPv4 address, and so carrier-grade NAT is going to have to happen, even if it happens alongside native IPv6 support. Also, customers won't be happy being told that they need to replace the router they bought just a year ago, and they especially won't be happy if they're told that the new one they've bought won't work with their internet access either, and so ISPs will have no choice but to continue supplying an IPv4 address for a long time after they've completed their IPv6 deployment, even if it's only a carrier-grade NAT address.

So I expect we'll all end up on carrier-grade NAT eventually, and those of us who give a shit will upgrade our LAN to support IPv6 and just forget about IPv4.

A post further below prompted me to re-examine my math on that exponential curve in Google's graph. It looks to be increasing by a factor of 2.5 every year, which would put it at 100% in 2018.

However, there's still the matter that the curve has really become linear this year. If it had remained exponential, we'd be at 6.25% next year, but here we are five months into 2014 and we're only up to 3.4%, whereas if we'd stuck with that same growth rate, we'd be up to 3.8% by now. So it really doesn't seem like we'll make it to 6.25% by the end of the year.

Given that the new linear growth appears to be about 1% over six months, that would put us around 2062 before we reach 100%. I don't think it will take anywhere near that long, but at the same time, the linear growth we've seen over the past five months shows that you can't trust exponential growth to remain constant.

So, again, sometime after 2020 isn't an unreasonable estimate.

At the beginning of the year, I looked at those Google IPv6 stats. I noted the exponential increase in IPv6 usage, calculated the exponent, then calculated the time necessary to reach 100%.

Ten years, a.k.a. 2024. ...and since the beginning of the year, the curve on that graph has flattened out, so a projected date would be even further into the future.

Granted, 100% availability isn't the same thing as "large-scale IPv6 deployment" but at the same time, until everyone is able to use it, it isn't going to be taken as seriously as IPv4.

I'm not sure why it's taking so long. Last I checked, Comcast was up to 25% deployment, and Time Warner Cable was up to 7% deployment.

Indeed, Time Warner is my ISP and, despite living in a small town of no importance, I discovered I have native IPv6 a month ago when I ran "tcpdump -n ip6" just to see if anything at all was there. Still took me a day to figure out how to get Linux to use it, as Linux by default refuses to accept router advertisements when configured as a router (which it was due to my Hurricane Electric tunnel), as if a router wouldn't need to know where to send packets. The fact that IPv6 functionality isn't well thought out and hasn't been widely tested seems to be a major issue with getting it to work, but once you do figure out all of the configuration misunderstandings, it does seem to work well.

About two months ago my modem quit working, and Time Warner gave me a DOCSIS 2.0 modem to use while I sent it in for repair. Why they're still handing out modems that aren't IPv6 compatible, I have no idea. They need to get rid of those things.

Just last night I was looking at home routers at Wal-Mart, and only about 1/4 of them claimed to support IPv6 on the box. One claimed only "IPv6 pass-through." Even for the ones which support it, it's questionable how well. I downloaded a Tomato firmware that supposedly supported IPv6, only to find that while they may have included the IPv6 support in the kernel, the GUI largely had no clue how to deal with it. For example, I tried to set up static DHCP addresses in the same way its done for IPv4 addresses, by clicking on the address and typing in what address I want that computer to have instead. It took me to the static address configuration page, but the maximum length of the input field was too short for an IPv6 address. I'm pretty sure that the address was only a link at all due to accident, in that the GUI software just didn't realize that it should create links for IPv4 addresses and leave the IPv6 addresses unlinked as it doesn't know how to them. I don't think it was even running DHCPv6, I think it only did stateless address autoconfiguration. I ended up having to run pfSense in a virtual machine, as configuring the umpteen daemons necessary to perform the functions of a router in Linux proved to require more days of work than I cared to put into it.

Anyway, I think the router issue is the biggest one. Old ones don't support IPv6. Most new ones don't support IPv6. ...and almost no one is going to go buy a new one just to get IPv6 when they can still reach Facebook via IPv4, especially someone who just bought one this year and so they already think they're relatively up-to-date. (...and the ones I saw that did support IPv6 were the most expensive ones, the ones where it'd only cost twice as much to just buy a computer instead.) Given that 2020 is only six years away, I don't think that imagining that most of us will still be IPv4-only in 2020 is unrealistic. Six years is not a long time to hold on to a router. I don't think I know anyone who owns one that isn't at least that old already.

You're right about that. A friend and I created a free online game, and many people who've played it (all certainly kids of one sort or another) have tried to run a server, but they can never seem to get past that dreaded "forward a port" step. I even wrote the most detailed instructions I could but as far as I know no one has successfully followed them. The one person who did only did so with some help from me. It seems he got tripped up by a Hamachi tunnel that was also showing up when he used the "ipconfig" command. Someone else didn't even know what a router might even look like and suggested I add a photo.

The big problem is that, even if I successfully explain how to access and log in to their router, there's still a completely proprietary interface past that point and I can't explain to them what anything they'll see there means, or what they'll have to click on to find what they need, or what it'll even say when they do find it. A web site called portforward.com has made a good effort at documenting router configuration pages, but their site layout is less than ideal, which is why I wrote my own instructions and only refer people to portforward.com towards the end, with detailed instructions on how to navigate the web site.

It also doesn't help that some routers don't support NAT reflection, and so if we sent those players to their internet IP address when they try to connect to their own server, they'd be unable to connect. We resolved that by having the game server tell the server list their LAN IP, and then when a player connects from the same IP as the game server, we give them the LAN IP instead of the internet IP, which allows them to connect, but it also has the effect of making it always appear that their forwarding is working just fine even when it isn't. They either have to get another player to test it, or find an online port scanner.

My friend looked into it. It's apparently almost undocumented and rather proprietary, just a commonly-supported form of proprietary. Last I knew he'd found some program that was able to tell the router to open a port and was just going to include it along with the server, but I don't know if that's ever happened. We've kind of lost interest in development as the game's usage numbers are incredibly low. ...and, as you say, it's often not enabled anyway.

I'd love to see IPv6 become more widely deployed, as it would mean that the only problem we'd have would be the Windows firewall, which is a huge pain in the ass, but it's a much smaller problem to solve.

I was wondering about that too when reading about address types. They seem to have not bothered to allocate any of that vast address space for "do whatever the fuck you want with it" purposes. ...and it all seems to be because they decided to forget about "site-local addresses" until they could come up with a concrete definition of what a "site" was.

Why they thought they had to define it, I have no idea. It's a simple fact that some part of the address space needs to be reserved for private "whatever you feel you need to do with it" use, like the private address ranges in IPv4. I don't think anyone but the standards committees cares whether "site" is well-defined or not.

Something else that really seems absurd to me is that there's exactly one loopback address. With IPv4, you don't just have 127.0.0.1, you have 127.x.x.x, and I've actually done things that involved different services running on port 80 accessible via different loopback addresses. It isn't possible to do that in IPv6 because, despite the vast address space, they didn't see fit to assign more than one address for loopback purposes. The only good thing about this is that IPv4 won't go away, and so at least I'll always have all of those IPv4 loopback addresses to play with.

Low-frequency solutions are no substitute for what an actual oscilloscope can do, but when you're trying to learn electronics, being able to see what the circuit is doing at all is far better than just guessing what it is doing. Multimeters have a use despite their 1 Hz sample rate, and a measly 20 kHz sample rate is going to be much more useful than that.

That said, just as soon as you can replace them with anything else, you'll decide that sound cards suck.

My present favorite solution is to use an FT245RL (a $5 USB chip that implements a simple parallel FIFO buffer, with drivers for Linux and FreeBSD already in your kernel) along with an AT89S52 (a $1 re-programmable microcontroller with 32 I/O pins, though I usually end up dedicating 15 of them to the programming interface and communication with the FT245RL, leaving only 17 for general-purpose use) and just write little programs for the microcontroller to read/write whatever data I want and transfer it to/from the PC. I even built my own programmer for the AT89S52 using the same two chips and a Perl script. (Naturally, the AT89S52 used in the programmer was programmed via other means -- I used a parallel port.) This generally allows me to do anything digital that I want to do. (Obviously my wants aren't that great.)

For analog, I attach a MCP3301 ($3 12-bit ADC w/ SPI interface) to the FT245RL & AT89S52 combo, which allows reading everything from DC up to 100 kS/s. At $3 a chip, adding multiple channels is inexpensive as well, and I've used up to eight simultaneously, driving them all with the same control signals and just reading the resulting eight data bits in parallel. While this is barely better than audio frequencies, the major advantages are that there is no DC filtering, and that you actually know what input voltages correspond to the values you read from the ADC. Sound cards are really only meant to record frequencies and relative amplitudes.

Of course, at this point you're up to about $25 to $50 depending on how much stuff you had to buy and how much stuff you already had, and you've invested a hell of a lot of your time. Time is quite valuable. Spend enough of it and you might as well have picked up a second job and just earned the money to buy that oscilloscope. ...but if you are a student, putting these chips together is kind of something you should be learning how to do. The big time-waster for me was the software, as I wrote an assembler, a script to drive the programmer, software to run in the microcontrollers, and any software needed on the PC to record and display data.

So a sound card is a rather attractive solution to people who don't already have an oscilloscope and can't justify the expense of one. The needed components are minimal, and the software already exists. Sure, sound cards can't measure DC, but you probably have a multimeter that can, and anything not DC, like a 0.1 Hz square wave, is still going to be visible as little spikes which at least lets you know something is going on, which is better than not knowing. Only very low frequency sine waves aren't going to be visible at all, but they're not that common, and in fact are rather hard to generate.

If you're looking at the modem's status page (192.168.100.1) and it says IPv4-Only, that actually has nothing to do with whether you have IPv6.

The quick and easy way to find out is to just run "tcpdump -n ip6" and see if anything shows up. I didn't realize I had IPv6 until I did that, as the configuration changes I made to Linux to support a Hurricane Electric IPv6 tunnel rendered it unable to configure itself automatically with my native IPv6. Even after knowing it was there, it took me a couple of days to figure out how to get it working. Seems the OS support for IPv6 isn't completely sorted out, and so you run into a lot of odd things that work in strange ways that you then have to sort out. In particular, if you want to use a Linux box as a router, you have to set up a DHCPv4 client, a DHCPv6 client, a DHCPv4 server, a DHCPv6 server, radvd, and get the kernel parameters sorted out so that it will actually accept router advertisements and route packets at the same time. I eventually gave up and just run pfSense in VirtualBox, but even figuring out how to get that to work wasn't trivial. Thus, I wouldn't conclude that you don't have IPv6 until you see tcpdump fail to show any IPv6 packets after running for ten minutes.

Well, the good thing is, even if IPv4 disappears from the internet, it'll still exist on your LAN, and so you can continue to access computers on your LAN via IPv4. I ended up configuring the firewall on my computers to block all incoming connections via IPv6, and just use IPv4 when connecting between them via SSH. As such, I'm using IPv6 basically as an internet-only protocol, which seems to make a lot of sense: I have little IPv4 addresses for my little LAN, and big IPv6 addresses for the big internet.

Indeed. If QoS becomes standard, then god-forbid you attempt to develop a new real-time network application, as the QoS won't recognize its real-time nature and so you'll get 500 ms ping times.

I really don't understand what need QoS is supposed to fill. There's an option for it on my router, and I once tried my best to utilize it. Netflix loves to figure out the size of your internet connection and use all of it, nevermind what anyone else in the house might want to do. So I tried to figure out how to fix this, but QoS isn't about giving everyone the share of the internet that belongs to them. It's about letting some users take bandwidth away from others. When the hell would I want that?

Say I have a dozen people in a house sharing one internet connection. Obviously I'd like to dedicate 1/12 of it to each person, and then, take whatever isn't being used at the moment by some people and divide that equally between everyone else. Then, if someone decides to make a VoIP call, it either fits in their share, or it fits when they get the leftovers, or they just don't get to fucking make their call, because if they want to have control over a larger fraction of the bandwidth, they need to pay more than 1/12 of the bill. So what if the other users are merely doing bittorrent? Presumably they're doing it because they want to, and they're paying for a share of the internet too, and so they can do whatever they want with it.

I really don't want my ISP to be doing any QoS. I don't care if they are oversubscribed. If they're oversubscribed ten to one, then guarantee me that 1/10th of my bandwidth -- I can fit a VoIP call in that just fine -- and let me have the rest only when its available. There's no need at all to take into consideration what type of traffic it is, and doing so will just screw me whenever other customers are doing something more blessed.

The point is, we still consider those stupid humans to be intelligent, at least in the sense of what we're talking about when we say "artificially intelligent." They may not be very smart, but we don't insist that they're non-thinking machines of the organic variety. The Turing test isn't designed to detect when we've achieved intelligent artificial intelligence. It's designed to detect when we've achieved any sort of artificial intelligence.

That said, I still doubt this bot has achieved even that. Can't test it since it's obviously slashdotted.

To be a truly fair test, the test must be a comparison, e.g. "one of these two people is actually just a computer program. Can you tell us which one?" Without a comparison, you're left with what everyone mentions: When chat bots were first introduced, nearly everyone was fooled by them, because they didn't know that "it's just a computer" was a plausible explanation for the person's stupidity, leaving the only logical conclusion to be that they were simply talking to an incredibly stupid person, or one which was intentionally trying to be a pain in the ass.

...and that latter point is important as well. I've read about some of these contests where the humans were doing their best to trick the judges into thinking they were a computer, which obviously skews the results. I've heard about other contests where the humans were also given awards for being "the most human human" if they were judged by the most people to actually be a human, so at least some of these contests are more legitimate.

Google is a complete pain in the ass sometimes. I don't recall exactly what I was searching for, but I was once searching for something about decibels, in which I knew that the content I was looking for would never mention the full word, but only the abbreviation "dB" instead. Google assumed that the "db" in my search query was an abbreviation for "database" and I never could figure out how to get it to stop giving me nothing but results about databases.

You'd better hope so if you want to play Descent again. It's impossible to find a joystick these days without a dead zone, a spot in the middle of the axis where you can wiggle the stick a little without the value reported to the OS being changed.

Descent, being designed for proper joysticks, is simply incompatible with dead zones. You need to turn slowly left, so you move the stick a little, and nothing happens. Your brain's immediate instinct is to assume it simply moved the stick too little, and so it tries moving it twice as far, but still, nothing happens. So then your brain doubles that, but still, nothing happens, as you've only just now reached the edge of the dead zone. So your brain doubles up again, and suddenly you're turning 8x faster than you wanted.

I tired, but it's apparently impossible for the brain to learn the limits of the dead zone such that it can reliably move the stick just barely past the dead zone to make a slow turn.

I actually thought about making a Descent-like game about a year ago, but attempting to play the old Descent with modern joysticks revealed the above problem, and without a proper joystick, there's just no fucking point.

This is getting sad. I see this posted somewhere in the comments of every article about cable television on Slashdot. Aren't people on Slashdot supposed to be smart enough to not accept facts without question simply because they support whatever argument they'd like to make?

It does seem some people on the internet are smart enough to question the story: link and link.

Others seem far too blinded by their desire to believe the story to realize just how likely it is that it is complete bullshit, like this guy who even put "fairy tale" in the title of his story. At first I thought maybe he was presenting it as a fairy tale, but with no argument against the story being presented, I can only conclude that he believes that commercial-free cable television did exist at one time, but has now become a "fairy tale" as it no longer exists.

...and just to make sure I get down-modded, I'll also point out the other popular myth Slashdot is unable to recognize as such: that "hacker" originally meant "intelligent person who is able to make technology do awesome things." Sorry, people, but the only time the word had any meaning besides "criminal" was when it meant (and still means) "to do something in an incorrect way which never the less works," e.g., "I think I can hack that equipment to do what we need." As such, applying the word to computer criminals is entirely appropriate, as they break into computers by exploiting the software on those computers in clever ways to do things that software wasn't intended to do. The legality of the action is irrelevant to the word. Even with the original definition, a hacker isn't something one should aim to be, but rather, being able to hack is merely a useful skill to have. Defining yourself as a hacker makes no more sense than defining yourself as an ass wiper. Yes, you have to wipe your ass, and it's good that you can do it, but if that's how you choose to define yourself then there's something wrong with you.