It may also turn out that the corkscrew is not a problem and keeps the craft pointed in the right direction, similar to how rifling improves the accuracy of bullets. It might just look disturbing to the people on the ground, and not upset the pilot or passengers. If you recall, the test run had two instabilities at that point in the flight, and rolling was the less hazardous one. I wouldn't be surprised if Melvill let it spin, rather than correcting, to keep it from doing anything else.
For that matter, if a part detatched from a spinning launch vehicle, it would be (slightly) more likely to fly clear of the vehicle, rather than hitting the vehicle further back.
The prize and competition works to generate interest in the problem. Having a successful solution (especially one whose developer has gotten commercial contracts) to compete with should generate at least as much interest.
Kerry doesn't need the vote of any slashdot reader in Massachusetts. No matter how many or how few vote for him, he will get MA's electoral votes, which are all that matter. In 2000, I voted for Nader, despite wanting Gore to win, and my electors all voted for Gore.
In a tight race like this, if you live in a state that is overwhelmingly one way or the other, you would do more to help your candidate win if you did not vote on election day and instead went to a contested state and offered to provide transportation to voters of demographics generally in favor of your candidate and unlikely to vote (Unless there are other elections locally that you also care about). You could make more of a difference by writing letters to unlikely voters in swing states. The election is not going to be won based on a candidate convincing voters without opinions; it will be won by a candidate convincing his supporters to go to the polls. If you convince just one democrat non-voter in a swing state to vote, you've done more than you can possibly do in an uncontested state at the polls.
I don't think anyone's losing money on this setup. His suppliers charge him what they agreed to; he seems to be doing fine; his competitors probably don't notice someone this size (or differentiate themselves on service).
Once this type of setup is commonplace, I bet he'll be pretty rich, pretty tired of it, and ready to do something else. He sells out to some big company that sees that he's been making money with the system. Before long, the situation is that big companies provide your communications wirelessly from equipment in space rented from neighborhood homeowners. Then the cycle repeats. The big companies don't really have to worry about competition from individuals, because the individuals don't have the attention span to compete over the time scales that matter, and will eventually become the next wave of services the big company offers.
Using a list for the loop seems to me to be 12 times slower on build 1.5.0-beta-b32c. Instead of taking 5 nanoseconds on my system, it takes 60 nanoseconds. So it's important to use the more efficient loop any time your loop iterations take less than 600 nanoseconds or so and you're doing enough of them to add up to something substantial (I was testing with 100000000 iterations to get things into the order of a second). For anything other than the innermost loops of databases or matrix multiplications, it's just not going to matter.
If this were actually an issue on any practical code, they'd make the JIT compiler determine that the iterator is constant in the loop, and use a copy of the loop with the ArrayList versions inlined when it's an ArrayList.
If you still want to use for loops over arrays, you should be aware that the new for loop syntax also works for arrays.
Actually, C/C++ had a lot of good ideas, but it took a while for Java to get them right. The new Generic Types add compile-time typechecking and remove a lot of typecasting without adding a huge amount of complexity to the language like C++ templates do, and without causing multiple copies of the code to be generated. Enums in Java are full-fledged classes of actual objects with methods, unlike in C where they are just markers (they are object constants instead of integer constants; no difference in efficiency for comparison). Static include is actually more like Python's "import", where you can skip the class name for some class statics. Formatted output is much the same, and was just waiting for other features. Varargs has strong checking in Java, unlike C; the called function can limit the type of the extra arguments, can find out at runtime how many it got, and can't run off the end of the set, because it gets them as a Java array.
Java, unlike C++, has a policy of putting features off to become future extensions any time the language team can't specify them right at the time. C++ is constantly finding that changes they need to make break things that they've been recommending. Java's main mistake so far has been that they didn't have arrays use generic types, so the two don't play quite right together. Of course, that was a matter of historical necessity, because Java wouldn't have gotten to the point where generic types were worked out correctly without supporting arrays.
They later clarified this to be 283 patents that the owners could sue Linux users over and not have the case thrown out immediately. They don't believe that any of the patents would stand up and actually apply to Linux. This is just a measurement of the risk that someone will have to fight a court case to prove that Linux is in the clear. They haven't publically revealed the list of patents because that would make the penalty for losing three times as high.
It doesn't cope with world hunger, the war in Iraq, or many other issues. SPF doesn't really have anything to do with unsolicited email. Its only intented effect is to make solicited email more distinctive. This can eliminate some significant false positives in spam filters (email that would be spam if it weren't sent from a government agency that you had applied for a grant from, for instance).
SPF will not prevent or help mark any email as SPAM. It will mark a lot of phishing scams as forgeries. It will let people avoid having spam sent with their address forged on it. It will give people sending non-spam to people who know them a way of marking their email as non-spam in a way that is very difficult for spammers to imitate.
Everything can, in theory, be reverse engineered. However, some things are easier to invent the way the original inventor did than to reverse engineer.
There are some inventions which are just totally mysterious to the user. Trying to figure out how a computer chip works by examining it is generally impractical. It is much easier to just make a different one which behaves the same in the circumstances of interest.
There are some inventions which could be figured out with a bit of examination. The workings of an adjustable chair, for example, wouldn't be too hard to replicate.
There are some inventions which are completely obvious once someone's thought of them, but where it was tricky to identify details of the problem they solve. For example, I have a can openner which is substantially better than other can openners because the handles are thick enough to spread out the force on the hands. It's completely obvious that it's good and why it's good, but it took 40 years for someone to actually make such a can openner.
This last class makes the "obvious" test very difficult, because many things are obvious in hindsight that were not obvious when they were invented, as demonstrated by the fact that the technology existed to implement them for a long time without anyone doing so. In fact, the hallmark of a good design is that it is immediately obvious to anyone who sees it, even though it would be unintuitive until that point.
I've been using the SUS for a while, and it's done a good job of limiting the damage from this sort of thing. I never knew it was available for Windows, though...
They obviously went with Linux because Windows didn't have built-in support for TCP/IP yet and Microsoft thought this internet thing would never catch on. Finding a mail server that would run on Windows in '95 was hard enough, let alone a cgi-capable web server.
The actual compilation step is no big deal; it doesn't actually require any user interaction, and it's reasonably quick. Chances are that you'll spend longer downloading than compiling. The hard parts are configuring and installing the new kernel. Installing is a bit tricky because you want to be able to switch back if the new one doesn't work. Configuring is tricky because there isn't a non-expert tool for it. There really ought to be a configuration tool which would start with a distro-specific configuration, check the devices you have installed, ask you to plug in each USB device you use in turn, check the filesystems in your fstab and detected on your devices, and generate a configuration that supports everything.
All of this is easier in 2.6 than in 2.4 and before, because the kernel developers decided that they really wanted the build process to be efficient and accurate (which they care more about than people who don't do it constantly) and they wanted the configuration system to be consistant and well-specified.
Have you actually read the standard licensing information for RFCs? Once an RFC is published, it's pretty much set in stone. You need the permission of the author in order to reformat it, let alone make any substantial changes to it. The main difference between Java and RFCs is that people care about using the trademark "Java" for whatever they're doing, while "RFC 2068" isn't worth trademarking, let alone trying to apply to modified versions.
Really, standards should only be replaced and never modified. Now, it is true that the Java standards are set by a process inaccessible to just about anyone, but there's no reason that one has to affect the Java standard in order to develop software, any more than one has to be Linus in order to work on Linux. Sure, you can't affect the official version, but that only matters as far as users care what is official, which they clearly do not if they're using your patches.
What is more of a concern is whether Java will become fragmented due to Sun failing to include other people's good ideas.
Linux conforms pretty closely to POSIX and SUS, which are closed standards. GCC conforms to ISO C99 (at least, when you tell it to). Firefox conforms to RFC 2068 and HTML 4.01. Most OSS programs conform to some standard or other. Most projects are not able to change the standard and unwilling to break compatibility.
The real issue is how much is left unspecified by the standard and available for innovation. Good standards will contain well-defined areas of uncertainty, where the behavior is entirely up to the implementation to specify, with good ideas coming to be required parts of later standards.
In the case of java, any option starting with -X to either java or javac is non-standard. So you just have to make your exciting new features depend on a -X flag and you'll pass the test suite (which, by definition, won't use any non-standard options).
It is not a uniform substance, but rather two chemicals dissolved in water. The article doesn't say specifically, but I'd guess at higher and lower temperatures, the chemicals come out of solution and/or undergo irreversible chemical changes. It's a bit like jello except with the gel and the solution behaviors backwards; freezing it or boiling it causes it to separate and behave normally.
If I have just committed, or just updated (and had no local changes), my working directory agrees exactly with the archive it is from. It should be possible to get the same agreement between one archive and another archive in the same circumstances.
That is, if a remote archive contains all of the changesets from the local archive, and I update the local archive with the remote one, the local archive needs to notice this operation (so that it knows I have those changesets), but, from the point of the remote archive, I haven't done anything new, because I only added changesets it already has.
I suspect that the underlying issue is that arch fails to drop empty changes. If you commit after you've just committed, you'll generate an empty changeset and a commit message for it. Really, a changeset should have to change something; otherwise, success should be reported with no revision generated. Similarly, if you are applying a changeset from a star-merge and you have all of the changesets it is composed of (you've gotten everything that was merged in, and there were no additional changes by the merger to resolve conflicts), then no revision should be generated. (You don't even need to note the fact that you've now applied that changeset, because applying it again wouldn't do anything)
I've actually used arch myself for most of a year now, and found the way a single archive works to be a significant improvement over CVS, but I have yet to get multiple archives to interact nicely. It looks like it would work well for cases where each archive is autonomous and no archive automatically picks up changes from other archives (i.e., the fully distributed case), but not for cases where some archive is kept up-to-date with respect to another archive (any centralization at all). Of course, arch is still ahead of CVS (the other system I have experience with) in that CVS doesn't support any relationships between repositories.
I'm not sure what you mean by a "pivot" branch, but I can see how it would work to have an arrangement of archives such that each person has an incoming archive and an outgoing archive, and a "committed" state is when outgoing has all of the private archive, and the private archive has all of the incoming archive. If you don't have any central point, it doesn't matter that you can't have synchronization.
On the other hand, I think it would be difficult to manage a with a lot of participants that way, simply because you'd have to search for changes in everyone's outgoing archives in order to get up-to-date. If your model involves cooperating with others, rather than simply accepting or rejecting their work, and the goal is for the group to have mostly a common consensus with some individual proposals, you really benefit from having the (groupwise, although not necessarily globally) central point which is the result of all the outgoing archives and the source of (most of the contents of) all of the incoming archives; but then the process has no fully-commited state.
(I find it amusing that Tom Lord's system doesn't actually support multiple people agreeing with each other, and each copy tries to get the last word)
Some of the machines listed on IBM's site look like tanks, although I can't really tell for sure from the pictures. The machines I've gotten from KC Computers have been humvee-like, at least, even if they aren't IBM-class. As for whether they last upwards of 5 years, you'll have to ask me about my current desktop in a year and a half, and my machine at work in 4 and a half years, but I bet they will.
I'd be interested to hear if anyone has actually gotten happy with distributed development under arch. I tried a reasonably simple case a few weeks ago, and couldn't get it to feel right.
What I was trying to do was to have a two-layer revision control system, where I have a private archive in addition to the project archive, and I check into the private one all the time, and transfer changesets to the project archive when I'm happy with it. That way, I can be halfway through refactoring a big chunk of code, have it completely broken, but have the work so far revision controlled so that, if I accidentally wipe out my build tree, I can recover it.
The problem I ran into was that I couldn't get the two archives to agree exactly on the current status: whenever I transferred my changes up from the private archive, it added a log message to the project archive, and my private archive wasn't up to date, because it didn't have the message. When I updated my private archive from the project archive (either to pick up the message or to get other people's changes), I had to put in a log message, which the project archive then didn't have.
It seems like arch really ought to support getting two archives in perfect sync, as well as disregarding a commit to a remote archive that only adds changesets already in the local archive (as well as disregarding the changesets themselves, which it does do).
The article says that Tom Lord claims that a comprehensible interface for arch should be ready by the end of the year. Arch really is the right design, and will be ideal once there's a sane interface.
I have a Pentium 90 from IBM that's been running practically continuously since I got it at a fire sale in '95. You can still get the tanks; it's just that people go for the flimsy ones.
ISPs do provide IPv6 addresses for free when they provide IPv4 addresses. Every IPv4 address has a corresponding IPv6 address. One of the points of moving to a huge address space is that you can assign each old address a new address and not use up a significant portion of the new address space.
What would be interesting is if ISPs would assign a static IPv6 address to customers who have dynamic IPv4 addresses. If the ISP has IPv6 at all, they have a huge block of addresses, which they could trivially assign to their customers by account number. And then there would be people who would set up IPv6-only sites or sites where the IPv6 address was more reliable, because the address was free.
If you look at the article's figure, the VoIP they're talking about isn't the same VoIP that has 911 issues. They're talking about POTS lines connected to an IP network instead of to a switched network; it's only IP once it gets to the phone company. This is the system that, IIRC, British Telecom is considering, but it's different from Vonage and such, which uses IP between the phone and the provider and sometimes has problems with 911.
Really, the term "VoIP" ought to be replaced with a bunch of more specific terms. The same term is, unfortunately, used for realtime audio transferred entirely over IP and set up by an internet-based protocol, transfer of telephone number and audio data by IP to a POTS gateway, and transfer of audio data from a POTS phone switch to other POTS phone switches. The first would be, for example, a point-to-point audio for an IM system, and you wouldn't expect 911 (or any other phone number) to work. The second is what home users might use, and 911 needs special support. The third is what the article is about, and 911 calls will use a different path anyway (routed directly from the switch to the local call center).
Slashdot Mirror
It may also turn out that the corkscrew is not a problem and keeps the craft pointed in the right direction, similar to how rifling improves the accuracy of bullets. It might just look disturbing to the people on the ground, and not upset the pilot or passengers. If you recall, the test run had two instabilities at that point in the flight, and rolling was the less hazardous one. I wouldn't be surprised if Melvill let it spin, rather than correcting, to keep it from doing anything else.
For that matter, if a part detatched from a spinning launch vehicle, it would be (slightly) more likely to fly clear of the vehicle, rather than hitting the vehicle further back.
The prize and competition works to generate interest in the problem. Having a successful solution (especially one whose developer has gotten commercial contracts) to compete with should generate at least as much interest.
They are allowed to use a pilot and two dummies with the right size and weight, rather than actual passengers.
Kerry doesn't need the vote of any slashdot reader in Massachusetts. No matter how many or how few vote for him, he will get MA's electoral votes, which are all that matter. In 2000, I voted for Nader, despite wanting Gore to win, and my electors all voted for Gore.
In a tight race like this, if you live in a state that is overwhelmingly one way or the other, you would do more to help your candidate win if you did not vote on election day and instead went to a contested state and offered to provide transportation to voters of demographics generally in favor of your candidate and unlikely to vote (Unless there are other elections locally that you also care about). You could make more of a difference by writing letters to unlikely voters in swing states. The election is not going to be won based on a candidate convincing voters without opinions; it will be won by a candidate convincing his supporters to go to the polls. If you convince just one democrat non-voter in a swing state to vote, you've done more than you can possibly do in an uncontested state at the polls.
I don't think anyone's losing money on this setup. His suppliers charge him what they agreed to; he seems to be doing fine; his competitors probably don't notice someone this size (or differentiate themselves on service).
Once this type of setup is commonplace, I bet he'll be pretty rich, pretty tired of it, and ready to do something else. He sells out to some big company that sees that he's been making money with the system. Before long, the situation is that big companies provide your communications wirelessly from equipment in space rented from neighborhood homeowners. Then the cycle repeats. The big companies don't really have to worry about competition from individuals, because the individuals don't have the attention span to compete over the time scales that matter, and will eventually become the next wave of services the big company offers.
Using a list for the loop seems to me to be 12 times slower on build 1.5.0-beta-b32c. Instead of taking 5 nanoseconds on my system, it takes 60 nanoseconds. So it's important to use the more efficient loop any time your loop iterations take less than 600 nanoseconds or so and you're doing enough of them to add up to something substantial (I was testing with 100000000 iterations to get things into the order of a second). For anything other than the innermost loops of databases or matrix multiplications, it's just not going to matter.
If this were actually an issue on any practical code, they'd make the JIT compiler determine that the iterator is constant in the loop, and use a copy of the loop with the ArrayList versions inlined when it's an ArrayList.
If you still want to use for loops over arrays, you should be aware that the new for loop syntax also works for arrays.
Actually, C/C++ had a lot of good ideas, but it took a while for Java to get them right. The new Generic Types add compile-time typechecking and remove a lot of typecasting without adding a huge amount of complexity to the language like C++ templates do, and without causing multiple copies of the code to be generated. Enums in Java are full-fledged classes of actual objects with methods, unlike in C where they are just markers (they are object constants instead of integer constants; no difference in efficiency for comparison). Static include is actually more like Python's "import", where you can skip the class name for some class statics. Formatted output is much the same, and was just waiting for other features. Varargs has strong checking in Java, unlike C; the called function can limit the type of the extra arguments, can find out at runtime how many it got, and can't run off the end of the set, because it gets them as a Java array.
Java, unlike C++, has a policy of putting features off to become future extensions any time the language team can't specify them right at the time. C++ is constantly finding that changes they need to make break things that they've been recommending. Java's main mistake so far has been that they didn't have arrays use generic types, so the two don't play quite right together. Of course, that was a matter of historical necessity, because Java wouldn't have gotten to the point where generic types were worked out correctly without supporting arrays.
They later clarified this to be 283 patents that the owners could sue Linux users over and not have the case thrown out immediately. They don't believe that any of the patents would stand up and actually apply to Linux. This is just a measurement of the risk that someone will have to fight a court case to prove that Linux is in the clear. They haven't publically revealed the list of patents because that would make the penalty for losing three times as high.
It doesn't cope with world hunger, the war in Iraq, or many other issues. SPF doesn't really have anything to do with unsolicited email. Its only intented effect is to make solicited email more distinctive. This can eliminate some significant false positives in spam filters (email that would be spam if it weren't sent from a government agency that you had applied for a grant from, for instance).
SPF will not prevent or help mark any email as SPAM. It will mark a lot of phishing scams as forgeries. It will let people avoid having spam sent with their address forged on it. It will give people sending non-spam to people who know them a way of marking their email as non-spam in a way that is very difficult for spammers to imitate.
Everything can, in theory, be reverse engineered. However, some things are easier to invent the way the original inventor did than to reverse engineer.
There are some inventions which are just totally mysterious to the user. Trying to figure out how a computer chip works by examining it is generally impractical. It is much easier to just make a different one which behaves the same in the circumstances of interest.
There are some inventions which could be figured out with a bit of examination. The workings of an adjustable chair, for example, wouldn't be too hard to replicate.
There are some inventions which are completely obvious once someone's thought of them, but where it was tricky to identify details of the problem they solve. For example, I have a can openner which is substantially better than other can openners because the handles are thick enough to spread out the force on the hands. It's completely obvious that it's good and why it's good, but it took 40 years for someone to actually make such a can openner.
This last class makes the "obvious" test very difficult, because many things are obvious in hindsight that were not obvious when they were invented, as demonstrated by the fact that the technology existed to implement them for a long time without anyone doing so. In fact, the hallmark of a good design is that it is immediately obvious to anyone who sees it, even though it would be unintuitive until that point.
I've been using the
SUS for a while, and it's done a good job of limiting the damage from this sort of thing. I never knew it was available for Windows, though...
They obviously went with Linux because Windows didn't have built-in support for TCP/IP yet and Microsoft thought this internet thing would never catch on. Finding a mail server that would run on Windows in '95 was hard enough, let alone a cgi-capable web server.
It's up 45% against 2 years ago, so it looks from the stock that Sun didn't quite die a few years ago and is recovering now.
The actual compilation step is no big deal; it doesn't actually require any user interaction, and it's reasonably quick. Chances are that you'll spend longer downloading than compiling. The hard parts are configuring and installing the new kernel. Installing is a bit tricky because you want to be able to switch back if the new one doesn't work. Configuring is tricky because there isn't a non-expert tool for it. There really ought to be a configuration tool which would start with a distro-specific configuration, check the devices you have installed, ask you to plug in each USB device you use in turn, check the filesystems in your fstab and detected on your devices, and generate a configuration that supports everything.
All of this is easier in 2.6 than in 2.4 and before, because the kernel developers decided that they really wanted the build process to be efficient and accurate (which they care more about than people who don't do it constantly) and they wanted the configuration system to be consistant and well-specified.
Have you actually read the standard licensing information for RFCs? Once an RFC is published, it's pretty much set in stone. You need the permission of the author in order to reformat it, let alone make any substantial changes to it. The main difference between Java and RFCs is that people care about using the trademark "Java" for whatever they're doing, while "RFC 2068" isn't worth trademarking, let alone trying to apply to modified versions.
Really, standards should only be replaced and never modified. Now, it is true that the Java standards are set by a process inaccessible to just about anyone, but there's no reason that one has to affect the Java standard in order to develop software, any more than one has to be Linus in order to work on Linux. Sure, you can't affect the official version, but that only matters as far as users care what is official, which they clearly do not if they're using your patches.
What is more of a concern is whether Java will become fragmented due to Sun failing to include other people's good ideas.
Linux conforms pretty closely to POSIX and SUS, which are closed standards. GCC conforms to ISO C99 (at least, when you tell it to). Firefox conforms to RFC 2068 and HTML 4.01. Most OSS programs conform to some standard or other. Most projects are not able to change the standard and unwilling to break compatibility.
The real issue is how much is left unspecified by the standard and available for innovation. Good standards will contain well-defined areas of uncertainty, where the behavior is entirely up to the implementation to specify, with good ideas coming to be required parts of later standards.
In the case of java, any option starting with -X to either java or javac is non-standard. So you just have to make your exciting new features depend on a -X flag and you'll pass the test suite (which, by definition, won't use any non-standard options).
It is not a uniform substance, but rather two chemicals dissolved in water. The article doesn't say specifically, but I'd guess at higher and lower temperatures, the chemicals come out of solution and/or undergo irreversible chemical changes. It's a bit like jello except with the gel and the solution behaviors backwards; freezing it or boiling it causes it to separate and behave normally.
If I have just committed, or just updated (and had no local changes), my working directory agrees exactly with the archive it is from. It should be possible to get the same agreement between one archive and another archive in the same circumstances.
That is, if a remote archive contains all of the changesets from the local archive, and I update the local archive with the remote one, the local archive needs to notice this operation (so that it knows I have those changesets), but, from the point of the remote archive, I haven't done anything new, because I only added changesets it already has.
I suspect that the underlying issue is that arch fails to drop empty changes. If you commit after you've just committed, you'll generate an empty changeset and a commit message for it. Really, a changeset should have to change something; otherwise, success should be reported with no revision generated. Similarly, if you are applying a changeset from a star-merge and you have all of the changesets it is composed of (you've gotten everything that was merged in, and there were no additional changes by the merger to resolve conflicts), then no revision should be generated. (You don't even need to note the fact that you've now applied that changeset, because applying it again wouldn't do anything)
I've actually used arch myself for most of a year now, and found the way a single archive works to be a significant improvement over CVS, but I have yet to get multiple archives to interact nicely. It looks like it would work well for cases where each archive is autonomous and no archive automatically picks up changes from other archives (i.e., the fully distributed case), but not for cases where some archive is kept up-to-date with respect to another archive (any centralization at all). Of course, arch is still ahead of CVS (the other system I have experience with) in that CVS doesn't support any relationships between repositories.
I'm not sure what you mean by a "pivot" branch, but I can see how it would work to have an arrangement of archives such that each person has an incoming archive and an outgoing archive, and a "committed" state is when outgoing has all of the private archive, and the private archive has all of the incoming archive. If you don't have any central point, it doesn't matter that you can't have synchronization.
On the other hand, I think it would be difficult to manage a with a lot of participants that way, simply because you'd have to search for changes in everyone's outgoing archives in order to get up-to-date. If your model involves cooperating with others, rather than simply accepting or rejecting their work, and the goal is for the group to have mostly a common consensus with some individual proposals, you really benefit from having the (groupwise, although not necessarily globally) central point which is the result of all the outgoing archives and the source of (most of the contents of) all of the incoming archives; but then the process has no fully-commited state.
(I find it amusing that Tom Lord's system doesn't actually support multiple people agreeing with each other, and each copy tries to get the last word)
Some of the machines listed on IBM's site look like tanks, although I can't really tell for sure from the pictures. The machines I've gotten from KC Computers have been humvee-like, at least, even if they aren't IBM-class. As for whether they last upwards of 5 years, you'll have to ask me about my current desktop in a year and a half, and my machine at work in 4 and a half years, but I bet they will.
I'd be interested to hear if anyone has actually gotten happy with distributed development under arch. I tried a reasonably simple case a few weeks ago, and couldn't get it to feel right.
What I was trying to do was to have a two-layer revision control system, where I have a private archive in addition to the project archive, and I check into the private one all the time, and transfer changesets to the project archive when I'm happy with it. That way, I can be halfway through refactoring a big chunk of code, have it completely broken, but have the work so far revision controlled so that, if I accidentally wipe out my build tree, I can recover it.
The problem I ran into was that I couldn't get the two archives to agree exactly on the current status: whenever I transferred my changes up from the private archive, it added a log message to the project archive, and my private archive wasn't up to date, because it didn't have the message. When I updated my private archive from the project archive (either to pick up the message or to get other people's changes), I had to put in a log message, which the project archive then didn't have.
It seems like arch really ought to support getting two archives in perfect sync, as well as disregarding a commit to a remote archive that only adds changesets already in the local archive (as well as disregarding the changesets themselves, which it does do).
The article says that Tom Lord claims that a comprehensible interface for arch should be ready by the end of the year. Arch really is the right design, and will be ideal once there's a sane interface.
I have a Pentium 90 from IBM that's been running practically continuously since I got it at a fire sale in '95. You can still get the tanks; it's just that people go for the flimsy ones.
ISPs do provide IPv6 addresses for free when they provide IPv4 addresses. Every IPv4 address has a corresponding IPv6 address. One of the points of moving to a huge address space is that you can assign each old address a new address and not use up a significant portion of the new address space.
What would be interesting is if ISPs would assign a static IPv6 address to customers who have dynamic IPv4 addresses. If the ISP has IPv6 at all, they have a huge block of addresses, which they could trivially assign to their customers by account number. And then there would be people who would set up IPv6-only sites or sites where the IPv6 address was more reliable, because the address was free.
If you look at the article's figure, the VoIP they're talking about isn't the same VoIP that has 911 issues. They're talking about POTS lines connected to an IP network instead of to a switched network; it's only IP once it gets to the phone company. This is the system that, IIRC, British Telecom is considering, but it's different from Vonage and such, which uses IP between the phone and the provider and sometimes has problems with 911.
Really, the term "VoIP" ought to be replaced with a bunch of more specific terms. The same term is, unfortunately, used for realtime audio transferred entirely over IP and set up by an internet-based protocol, transfer of telephone number and audio data by IP to a POTS gateway, and transfer of audio data from a POTS phone switch to other POTS phone switches. The first would be, for example, a point-to-point audio for an IM system, and you wouldn't expect 911 (or any other phone number) to work. The second is what home users might use, and 911 needs special support. The third is what the article is about, and 911 calls will use a different path anyway (routed directly from the switch to the local call center).