True, but I wanted this to be something anyone could do with equipment they might already have lying around and also get a feel for what gravity is actually doing.
Switching on a machine that displays "9.8m/s²" isn't that much removed from looking it up in a book.
Well, sure, but this is HN ... timing the fall of an object is one thing (Gallileo deserves a mention or three here).
"Measuring gravity" suggests more continuous measurement, such as what myself and various scaly mates used to do 40 odd years past with LaCoste and Romberg gravity meters that may or may not have had a shop built element to them for use in light aircraft to run grids across country scale areas.
I had a similar reaction when learning 8086 assembly and finding the correct way to do `if x==y` was a CMP instruction which performed a subtraction and set only the flags. (The book had a section with all the branch instructions to use for a variety of comparison operators.) I think I spent a few minutes experimenting with XOR to see if I could fashion a compare-two-values-and-branch macro that avoided any subtraction.
Comparing for equality can use either SUB or XOR: it sets the zero flag if (and only if) the two values are equal. That's why JE/JNE (jump if equal/not equal) is an alias for JZ/JNZ (jump if zero/not zero).
There's also the TEST instruction, which does a logical AND but without storing the result (like CMP does for SUB). This can be used to test specific bits.
Testing a single register for zero can be done in several ways, in addition to CMP with 0:
TEST AX,AX
AND AX,AX
OR AX,AX
INC AX followed by DEC AX (or the other way around)
The 8080/Z80 didn't have TEST, but the other three were all in common use. Particularly INC/DEC, since it worked with all registers instead of just the accumulator.
Also any arithmetic operation sets those flags, so you may not even need an explicit test. MOV doesn't set flags however, at least on x86 -- it does on some other architectures.
An earlier draft had a section discussing how IPv4x would work with NAT routers. Essentially, an IPv4x packet would be a UDP/IPv4 packet using a port number (84) that's been allocated to IPv4x.
Old routers would be a normal UDP packet inside a normal IPv4 and route it normally. New routers would detect UDP port 84 and treat it as an extended IPv4x packet.
I took all that out because I wasn't writing a proposal for something we should actually implement in the real world, but an alternate history "What if people who wanted IPv4 but with extra space got their way" and the story was already too long.
No. Which doesn’t prove the technology has not been adopted. The internet also consists of much more than public-facing websites. So what’s your point?
My point is that we're still dependent on IPv4. For all the progress IPv6 has made, no-one is willing to switch IPv4 off yet. Until we do, we're still constrained by all the problems IPv4 has.
Plenty of people are switching v4 off. Facebook run basically all of their datacenters without v4. T-Mobile USA use only v6 on their network. Thread only supports v6 in the first place
There are plenty of other places doing the same thing, but these examples alone should be sufficient to disprove "no-one is willing to turn v4 off".
This wasn't a proposal, but an alternate history. The world where the people who wished for IPv4 but with extra address space get their way. By the end I come down on being happy with we're in the IPv6 world, but wishing interoperability could be slicker.
Note though that I'm not proposing IPv4x as something we should work towards now. Indeed, I come down on the side of being happy that we're in the IPv6 world instead of this alternative history.
Switching on a machine that displays "9.8m/s²" isn't that much removed from looking it up in a book.
reply