What you also didn't know is that I was building computers with discrete transistors forty-three years ago; I suspect you might have been in diapers at that time.
You realize that you've completely discredited yourself by writing that, right? You've shown that even though you really should should know better, you don't.
Pointing to an article that has somebody summarily dismissing IPv6 (which was a perfectly legitimate thing to do in 2004, but not anymore), when IPv6 is in fact being deployed, does not help your case. Using inappropriate terminology doesn't help either.
What does assembling now-obsolete computers have to do with IP networking, anyway? You might as well have said that you have a Ph.D. in Mathematics. While possibly impressive, it's irrelevant to the topic at hand. You're outside your field of expertise.
IPv6 is happening whether you like it or not. Yes, there might have been a better way to handle the transition (which clueful people like Dan Bernstein have already discussed), but it's happening and for good reasons.
But even with its too-many-octet queries, it's not going to do much damage. Most queries are for LOCAL NETWORK information only. The rest get cached before a demarc point or a tie point.
Please define "demarc point" and "tie point", justify your statement that "most queries are for LOCAL NETWORK information only", and give us some indication that have any idea what an IP network is.
My guess is that you're either a troll, a child, or a telecomm-industry "expert" who thinks he knows the Internet.
How droll. Do you realize what you've said in justification? Have you done router tables, ever?
This has got to be some of the most transparent, amateur trolling that I have ever seen. Have you ever "done router tables"?
Larger addresses mean that you can aggregate blocks of network addresses. My current small-ish ISP has several IPv4 netblocks. A cursory search brings up at least 4 netblocks, including: 65.x.x.0/19, 24.x.0.0/17, 24.x.128.0/20, and 204.x.x.0/24. That's 4 entries in every defaultless Internet routing table in the world! This happened because the ISP has been assigned various small address blocks as it grew.
Under IPv6, my ISP would have been assigned a huge netblock in the first place. As a result, there would be at least a four-fold decrease in the number of routing table entries needed worldwide to route packets to my ISP. Also, since my ISP's addresses might form a logical subnet of the addresses of one of its upstream providers, there would be a good number of sites on the Internet that don't need to have any routing table entries for my ISP at all, since the entry could be folded (presumably by the BGP server) into the upstream routing table entry.
I think Slashdot (and possibly TFA, if I had bothered to read it) are putting words into his mouth. Typically, when people talk about overloading "the DNS", they mean that important authoritative name servers (such as the root servers or the gTLD servers) will be overloaded. However, authoritative name servers can normally manage the amount of traffic they receive by controlling the (DNS) TTL values in the records they return, so it's really not a big issue.
The issue here is that requests between stub resolvers (whatever is the Windows-equivalent of libresolv) and caching nameservers, rather than between caching nameservers and authoritative nameservers. I suspect that Mockapetris is simply saying that some ISPs who are running their caching nameservers near capacity are well-advised to increase their capacity before Vista is released. That much is true.
First of all, you can request more than one record at a time - the specification explicitly allows for more than one Question in the message.
If you're a server, what do you set RCODE to if one of the requests returns NXDOMAIN and the other returns a record? What if, instead of NXDOMAIN, you get SERVFAIL?
Having QDCOUNT>1 is ambiguous, and is basically a bug in the RFC. The author of MaraDNS did some research a while ago, and determined that no DNS server really supports it. I quote from doc/en/misc/multiple.qdcount in the MaraDNS distribution:
Neither DjbDNS, BIND, nor MSDNS support queries where QDCOUNT > 1. DjbDNS
ignores queries where QDCOUNT > 1. Microsoft DNS server replies with a "format
error", and the qdcount is set to the number of questions sent to the server.
BIND 8 replies with a "format error", and QDCOUNT is set to zero.
Realistically, DNS servers should probably reply with "not implemented"
instead of "format error".
Some discussion of the fact that QDCOUNT > 1 queries are not handled
by modern-day DNS servers:
In summary, the nitty gritty implementation details of handling multiple
question queries in a single packet make this difficult to correctly handle.
I'm making the handling of multiple QDCOUNT queries a low priority in
MaraDNS.
Of course, it would be possible to update the standards---and every existing DNS implementation---to support QDCOUNT>1 in some specific way, for this purpose, but by the time it's deployed, we probably won't care much about IPv4 compatibility any longer.
Regarding DOCSIS, we realistically won't have to wait that long. People will be able to use RFC 1918 addresses to connect a tunnel between their on-site router and their ISP's router. Or, they should be able to use PPPoE to accomplish the same thing. Obviously, these are inefficient hacks, but they'll work well enough until the infrastructure is upgraded.
It assumes that a little problem with the hard drive is automatically an earthquake. It could just as easily be from too much bean-dip and burritos for lunch.
It's somewhat unlikely that multiple people in the same geographic area will all experience the effects of bean-dip and burritos within a few seconds of each other; You can pull useful information out of this data by averaging.
The funny thing is that Microsoft could easily do that, but---predictably---they won't. They're too concerned about their own pride to deliver good products to their customers.
You mount it in ext2 mode. ext3 is just ext2+journalling, and you can mount a ext3 partition as ext2. This doesn't replay the journal, so you won't get to see any data actually in the journal, but the rest of the data you can see.
Have you tried that? I just tried that on Linux 2.6.17-1-686 (packaged in Debian), and it doesn't work. IIRC, an ext3 filesystem is only backwards-compatible with ext2 when it's cleanly unmounted, and this behaviour is by design. Otherwise, you'd get data corruption when you try to replay the journal on a ext3 filesystem that's been modified (using an ext2 driver) since the journal was created.
And there are other ways that you can ensure that Linux will not write to the disk -- for example, `hdparm -r/dev/whatever' will tell the driver to not let Linux write to the disk, no matter what.
Yes, but it doesn't work how you might think hdparm -r sets a flag (via the BLKROSET ioctl) that is honoured by each individual filesystem driver, as well as the drive that presents block devices to user space (see ext3_load_journal in fs/ext3/super.c and open_bdev_excl in fs/block_dev.c). It is not handled by a lower layer like the IDE driver or the drive itself, unlike what you might think given that you're using hdparm.
The feature doesn't look designed to guarantee read-only operation, and I personally wouldn't consider it to be trustworthy. As you say, it doesn't seem likely that a court would take it as a given that all accesses were read-only (especially if you're trying to establish that a certain file was or wasn't deleted at a certain time). On the other hand, it's not always the rules of evidence that you're worried about. You don't want some Linux bug causing you to destroy your only copy of the information you need to solve a crime.
Come to think of it, I wonder how easy it is to modify the firmware on a hard drive these days. It would be an interesting exercise to put a dead man's switch, which wipes out some critical information and then deletes itself, into the IDE firmware. Hmm...
You can pull the card out of the Amiga and just hook it up to power, which could be supplied by any old 386 or 486 motherboard. It could talk to a modern computer via MIDI for control. They had a version of the host software for PCs, I think under Windows. The host software should run fine under modern Windows, or Win emulation on Linux. Alternately, the midi commands were published, you could cobble together a Qt Linux controller in a few hours.
If you take a core dump of the combined executable that is running in memory, just after the runtime dynamic linking process is complete, then the resulting core dump is a derived work of the program and all the libraries it loads.
In other words, the program that every end user will actually run is a derived work, and the dynamically linked ELF executable is just a fancy way of distributing that derived work to end users.
The idea is that distribution of copyrighted works (including derived works) is always covered by copyright law, regardless of what kind of mechanism you use. In that sense, transmitting the work using a dynamically linked binary is seen as equivalent to transmitting the work using encryption, compression, BitTorrent, or any other mechanism that ultimately results in the recipient gaining a copy of the work.
Eventually, Alexander told me that $4000 was too expensive for them and asked to meet me and discuss alternatives.
and then
A few days later, Alexander told me that he has consulted with his lawyers
I call bullshit. Unless lawyers in Israel are vastly cheaper than they are in North America, nobody would pay lawyers, and then take legal risks (which could involve paying the lawyers some more) in order to save only $4000.
Oh, nifty! I guess it replays recorded (encrypted) frames, hoping to capture the replies (even if they're just NAKs) in order to use them to get the IVs needed to crack the WEP key.
Yet another reason why encryption without authentication (or doing something with messages that have failed authentication besides dropping them to the floor) is a bad idea.
Slashdot Mirror
You realize that you've completely discredited yourself by writing that, right? You've shown that even though you really should should know better, you don't.
Pointing to an article that has somebody summarily dismissing IPv6 (which was a perfectly legitimate thing to do in 2004, but not anymore), when IPv6 is in fact being deployed, does not help your case. Using inappropriate terminology doesn't help either.
What does assembling now-obsolete computers have to do with IP networking, anyway? You might as well have said that you have a Ph.D. in Mathematics. While possibly impressive, it's irrelevant to the topic at hand. You're outside your field of expertise.
IPv6 is happening whether you like it or not. Yes, there might have been a better way to handle the transition (which clueful people like Dan Bernstein have already discussed), but it's happening and for good reasons.
Please define "demarc point" and "tie point", justify your statement that "most queries are for LOCAL NETWORK information only", and give us some indication that have any idea what an IP network is.
My guess is that you're either a troll, a child, or a telecomm-industry "expert" who thinks he knows the Internet.
This has got to be some of the most transparent, amateur trolling that I have ever seen. Have you ever "done router tables"?
Larger addresses mean that you can aggregate blocks of network addresses. My current small-ish ISP has several IPv4 netblocks. A cursory search brings up at least 4 netblocks, including: 65.x.x.0/19, 24.x.0.0/17, 24.x.128.0/20, and 204.x.x.0/24. That's 4 entries in every defaultless Internet routing table in the world! This happened because the ISP has been assigned various small address blocks as it grew.
Under IPv6, my ISP would have been assigned a huge netblock in the first place. As a result, there would be at least a four-fold decrease in the number of routing table entries needed worldwide to route packets to my ISP. Also, since my ISP's addresses might form a logical subnet of the addresses of one of its upstream providers, there would be a good number of sites on the Internet that don't need to have any routing table entries for my ISP at all, since the entry could be folded (presumably by the BGP server) into the upstream routing table entry.
I think Slashdot (and possibly TFA, if I had bothered to read it) are putting words into his mouth. Typically, when people talk about overloading "the DNS", they mean that important authoritative name servers (such as the root servers or the gTLD servers) will be overloaded. However, authoritative name servers can normally manage the amount of traffic they receive by controlling the (DNS) TTL values in the records they return, so it's really not a big issue.
The issue here is that requests between stub resolvers (whatever is the Windows-equivalent of libresolv) and caching nameservers, rather than between caching nameservers and authoritative nameservers. I suspect that Mockapetris is simply saying that some ISPs who are running their caching nameservers near capacity are well-advised to increase their capacity before Vista is released. That much is true.
If you're a server, what do you set RCODE to if one of the requests returns NXDOMAIN and the other returns a record? What if, instead of NXDOMAIN, you get SERVFAIL?
Having QDCOUNT>1 is ambiguous, and is basically a bug in the RFC. The author of MaraDNS did some research a while ago, and determined that no DNS server really supports it. I quote from doc/en/misc/multiple.qdcount in the MaraDNS distribution:
Of course, it would be possible to update the standards---and every existing DNS implementation---to support QDCOUNT>1 in some specific way, for this purpose, but by the time it's deployed, we probably won't care much about IPv4 compatibility any longer.
Regarding DOCSIS, we realistically won't have to wait that long. People will be able to use RFC 1918 addresses to connect a tunnel between their on-site router and their ISP's router. Or, they should be able to use PPPoE to accomplish the same thing. Obviously, these are inefficient hacks, but they'll work well enough until the infrastructure is upgraded.
We have already run out of IPv6 addresses. That's why we have NAT, which completely breaks the end-to-end model of the Internet.
Once IPv6 deployment is widespread, we'll finally be able to quit pretending that HTTP is a transport-level protocol.
It's somewhat unlikely that multiple people in the same geographic area will all experience the effects of bean-dip and burritos within a few seconds of each other; You can pull useful information out of this data by averaging.
Flash Paper
Indeed. Let's burn our paper and lumber instead of recycling them!
What was wrong with Nagios that you decided to go with NetCool?
The funny thing is that Microsoft could easily do that, but---predictably---they won't. They're too concerned about their own pride to deliver good products to their customers.
... because all the world's mass-market software.
Have you tried that? I just tried that on Linux 2.6.17-1-686 (packaged in Debian), and it doesn't work. IIRC, an ext3 filesystem is only backwards-compatible with ext2 when it's cleanly unmounted, and this behaviour is by design. Otherwise, you'd get data corruption when you try to replay the journal on a ext3 filesystem that's been modified (using an ext2 driver) since the journal was created.
Yes, but it doesn't work how you might think hdparm -r sets a flag (via the BLKROSET ioctl) that is honoured by each individual filesystem driver, as well as the drive that presents block devices to user space (see ext3_load_journal in fs/ext3/super.c and open_bdev_excl in fs/block_dev.c). It is not handled by a lower layer like the IDE driver or the drive itself, unlike what you might think given that you're using hdparm.
The feature doesn't look designed to guarantee read-only operation, and I personally wouldn't consider it to be trustworthy. As you say, it doesn't seem likely that a court would take it as a given that all accesses were read-only (especially if you're trying to establish that a certain file was or wasn't deleted at a certain time). On the other hand, it's not always the rules of evidence that you're worried about. You don't want some Linux bug causing you to destroy your only copy of the information you need to solve a crime.
Come to think of it, I wonder how easy it is to modify the firmware on a hard drive these days. It would be an interesting exercise to put a dead man's switch, which wipes out some critical information and then deletes itself, into the IDE firmware. Hmm...
What, using Linux? Here's a clue for you:
. . .
Um, or you could just leave it in the Amiga.
I think the legal theory is as follows:
If you take a core dump of the combined executable that is running in memory, just after the runtime dynamic linking process is complete, then the resulting core dump is a derived work of the program and all the libraries it loads.
In other words, the program that every end user will actually run is a derived work, and the dynamically linked ELF executable is just a fancy way of distributing that derived work to end users.
The idea is that distribution of copyrighted works (including derived works) is always covered by copyright law, regardless of what kind of mechanism you use. In that sense, transmitting the work using a dynamically linked binary is seen as equivalent to transmitting the work using encryption, compression, BitTorrent, or any other mechanism that ultimately results in the recipient gaining a copy of the work.
Lynx is, and it's been in reasonably widespread use for longer than a lot of the browsers you've listed.
From the article:
and then
I call bullshit. Unless lawyers in Israel are vastly cheaper than they are in North America, nobody would pay lawyers, and then take legal risks (which could involve paying the lawyers some more) in order to save only $4000.
This "Alexander" character sounds a lot like Slade from QuakeLives.
The headline should read: "Debian forks cdrtools"
Of course, that wouldn't be news, because Debian forks things all the time.
Ah. Makes sense.
I wonder if this program on my computer called "br()wz0r" is malware...
Silly me! I thought one-time pads were the only proven way to secure a wireless network. :P
Usually, but not in VHDL.
Oh, nifty! I guess it replays recorded (encrypted) frames, hoping to capture the replies (even if they're just NAKs) in order to use them to get the IVs needed to crack the WEP key.
Yet another reason why encryption without authentication (or doing something with messages that have failed authentication besides dropping them to the floor) is a bad idea.