As a Canadian I have no idea what 72˚F means or feels like: is it warm or cold? I do know what 22˚C feels like and how to dress for it. How "intuitive" a temperature number is completely learned behaviour and cultural acclimation.
Pounds vs kg: see above. All the non-American people seem to have "intuitive" grasp of metric measurements.
> 0-100 MPH lines up well with car speeds, which is usually the thing you're measuring with that. KPH is excessively granular for that. Probably not by design, but yeah.
So 'more granularity' is good for temperature but not for speed. Got it.
> The feet/inches vs meters/cm thing matters less. It's base-12 vs base-10. You can do decimal feet or fractional meters of course, but it's less common, so apparently both ways are fine.
By "foot" do you mean 'regular' foot or survey foot:
Because there are two different units in the US customary system, used for basically the same purpose, that use the same name. And the "foot" isn't the only unit like that:
Here's another one: which weighs more, a pound of feathers or a pound of gold? A pound of feathers. Because feathers use one 'pound-system' [1] and is 453g, while gold uses another pound-system [2] and is 373g. But of course an "ounce" of gold (31g) is more than an "ounce" of feathers (28g), because Troy is 1/12 of pound but Avoirdupois is 1/16. In addition to the above "ounces" there is also "fluid ounces".
I didn't say it's about being used to one. It can be "in the 20s" C for multiple months, kinda silly. 22.0˚C also feels different from 22.5˚C. There's a right amount of granularity for temperature and for speed.
Foot and pound have unambiguous meanings in the US. There's a reason the whole survey foot and gold-pound thing is trivia that nobody knows, they're niche or abandoned systems that you only use if you're being clear that it's not regular feet or pounds. I also know that the US system is technically not "imperial," but nobody cares.
> The nice thing about imperial (as well as the customary system used in the US) is that it's based on measurements that people have found useful over thousands of years. They're human units, adapted to what people need to do with them, not the other way around.
US customary is not "thousands" of years; temperature (Fahrenheit) only came out in 1724 for example, and many other units were only standardize much more recently:
Second, even with-in the system itself there was also sorts of inconsistencies. Until just a few years ago there were two "foot" units; one was recently retired:
Here's another one: which weighs more, a pound of feathers or a pound of gold? A pound of feathers. Because feathers use one 'pound-system' [1] and is 453g, while gold uses another pound-system [2] and is 373g. But of course an "ounce" of gold (31g) is more than an "ounce" of feathers (28g), because Troy is 1/12 of pound but Avoirdupois is 1/16. In addition to the above "ounces" there is also "fluid ounces". And let's not forget about the third system [3], which got replaced by… the metric system in 1971.[4]
> Think about it. Imagine you were never taught a measurement system. You find yourself needing to come up with a unit to make measurements for wooden planks you're going to use to build a house. Would you choose a unit as long as a meter? Or one as short as a centimeter or even a decimeter?
Millimeters. That single unit gets you down to very small scales (finer than 1/16") and to large lengths: four significant digits (9999mm) gets you to the equivalent of >32' (~11yd).
You misunderstood me. It's based on measurements that people have been using for thousands of years. The Romans had feet and miles, for example - not exactly the same lengths, but for the same purposes. The Japanese shaku is almost exactly the same as a US foot. A Japanese Shō is about half a gallon. A Chinese jīn is just slightly larger than a pound. There's a reason for this.
> there was also sorts of inconsistencies
I never claimed otherwise. But do notice that the survey foot and standard foot weren't used for the same purposes, and the difference between them wasn't likely to confuse anyone except maybe people new to the field.
> Here's another one: which weighs more, a pound of feathers or a pound of gold?
Yep, Troy weights. And no one's sure where the Troy system came from. The main reason for its use is because of international trade. Also not something regular people (i.e. people that didn't work directly with precious metals) would have had contact with.
> Millimeters
Hah! Yeah right. Look at all the various non-metric systems that have existed throughout history. Did any of them use something like millimeters to measure wooden planks? Why not?
> As evidence for this Australia/NZ/EU do everything in millimetres in construction.
They do it because the metric system is mandated there and it doesn't give you reasonably sized unit for that scale of work.
Try this: go to a home center (or whatever it's called there - the place you buy building supplies) and measure some drywall. Do the measurements you made agree to the advertised ones within half a millimeter? Compare the dimensions of drywall sheets from different pallets and manufacturers. Do their dimensions agree to within half a millimeter? If not, that's a sure sign you're using units poorly adapted for purpose.
> […] but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.
This was not a "mistake":
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
> Yes it's 3A. They didn't need to make the new protocol have separate state from the old one.
Except there will be a period of time when many 'network elements' (routers, firewalls, servers (web, SMTP, DNS, etc), clients) will not be updated for the new protocol so you may also need 3B.
And this will be true for any IPng, and not just the one that just happened to be chosen to be for "IPv6" (which was SIPP, over CATNIP and TUBA; see RFC 1752).
> Let me keep my old address on the new protocol.
You can/could. You can encourage people who have addresses in the older protocol to use the new one with "free" "automatic" address assignments in the new one to encourage translation and tunnelling:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
And the 'old' IPv4 addresses are available in the new IPv6 world:
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
6to4 and NAT64 are not what I'm saying. Those involve a relay server and v4 translation, and there's an entire memo on why that's unreliable and abandoned. I want to switch to fully native IPv6 without changing any of my addresses. There's no reason this should be impossible.
> I want to switch to fully native IPv6 without changing any of my addresses. There's no reason this should be impossible.
… except for the fact that you have to have completely new data structures and packet format to fit more address bits, and once you change the structures you need a new version field so any gear that sees a packet knows where to use the old code paths or new ones.
Then you're at the point where you have to push new code everywhere to handle these changes, and some nodes will have only the old code and some the new code, so now you're into translation and/or tunnelling to make sure the old addresses can talk to new addresses. Depending on their risk tolerance, some operators will enable the new code and some will not.
You also have to update DNS with new records, as A records are hard-coded to 32 bits. So now you're updating DNS libraries and user land.
There is no way to expand address space without going through all the same issues as what we call "IPv6" (originally SIPP) has gone through.
I know. All these things were possible and completed for IPv6, but that's only part of the battle. The rest is making it easy for users at various levels to migrate. IPv6 didn't do that, that's why we're stuck in today's situation.
IPv6 added an unnecessary requirement to change all existing routes, which is huge. If still using old v4 addrs in v6, there should be no need to change DNS yet. You shouldn't need a different DNS or DHCP server, only one that supports both protocols (also shouldn't be forced to use SLAAC). V6 translation to/from v4 should be doable at any hop instead of relying on a flaky anycast relay. The later stage of migration should just be that people start using longer addresses given that both ends are v6 and DNS etc supports it then. Even still there should be no requirement for every hop along the route to be v6, only the ones that go deeper than /32 near the ends. But we got all these extra constraints because of ipv6 design decisions.
Why spend all this energy complaining about v6 not doing something that it did do?
> The later stage of migration should just be that people start using longer addresses given that both ends are v6 and DNS etc supports it then
It seems your only real problem is that you completely missed the early part of the transition. We've been in what you're calling the later stage for twenty or so years now.
IPv4-compatible v6 address was only for dual-stack hosts talking over a v4 network. They still had their own v6-native addresses that they had to use if they wanted a v6 network. So this isn't what I described where the v6-native route is the same as the v4 route, or a superset in the later stages (shared down to /32, v6-only in deeper subnets).
The thing I want to solve isn't just v4 routers in the middle, that's more of a bonus. All the routers between my machine and any service probably support v6 anyway, but a bunch of services are v4-only because of the migration effort. They should be able to turn on v6 without having to change everything about their networking.
Wasn't "dual-stack hosts talking over a v4 network" what you wanted?
v4 routers don't understand and can't route v6 packets, so you can't use the same route for both of them. v6 packets have to go to a router that understands v6, and v4 packets have to go to a router that understands v4.
I have no idea what "or a superset in the later stages (shared down to /32, v6-only in deeper subnets)." is trying to say.
It's perfectly possible to turn v6 on without changing anything at all about your networking. When e.g. Windows Vista came out, hundreds of millions of people did exactly that.
Why can't the service just set up NAT64 to accept your v6 connections on their v4 servers?
I wanted switching to v6 to involve the minimum necessary changes. You keep your old /32. If you're sending from a /32 to a /32, it follows the same path of routers that an ipv4 packet would follow, that's what I meant by same route. There could be a v4-only router in the middle requiring translation, but I'm not even assuming that's a common issue at this point.
"or a superset in the later stages (shared down to /32, v6-only in deeper subnets)": The ipv6 state would be a superset of the ipv4 state. So if a router owns 1.2.3.4 in v4, it also owns that in v6. The ownership of 1.2.3.4.5 below that would only be part of v6 state.
What we got instead was two separate states, or parallel networks. Switching to v6 means changing everything all at once.
> Why can't the service just set up NAT64 to accept your v6 connections on their v4 servers?
It's not that simple, otherwise they would've done it. They have stuff like multiple addresses, geo DNS, and rate-limiting. Separate issue, AWS was v4-only for a long time and still treats it as more first-class because of how many internal things need to change for v6, well beyond just having hardware + OSes support it.
> All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.
There is no 'just' extending the address length:
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
You also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code that cannot be update to reach extended-address-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
> For TechSavvy I believe it was dynamic /64 by default but static /56 for free on request.
"On request" meaning you told your CPE equipment to send a DHCP-PD packet, i.e., you didn't have to call them and ask for something special with your account.
I did phone them to request the static /56, and to assign PTRs. I didn't try requesting the /56 before I called them so I can't say whether that would have worked or not. If you're saying it would have I'll believe you.
I have to ask: why the two accounts/alts with almost identical handles? Even if I suspect you’ll assert there’s no reason for me to assume you’re the same person as the GP.
> Even with Germany it turned out that Angela Merkel did grave mistakes and Germans were able to find out about those only after she left office. Being continually in office gives you the ability to hide your trials.
A "required absence" is a thing in a number of sensitive positions, especially financial/regulated industries.
> I think you're missing the mark by putting the blame on morals while ignoring actions such as Reagan dismantling unions and removing accountability from news reporting
Also cutting tax rates and encouraging 'pass-through' S-Corps, the latter of which really helped many people skirt taxes:
In the late 1990s, under Clinton, the US was in a fiscal position such that people were worried about US Treasuries (bonds) not being available anymore because of surpluses. Then there was Bush (wars, tax cuts), the GFC, Trump 1.0 tax cuts, Trump 2.0 tax cuts: and people are wondering how the US can solve its fiscal mess? How about you go back to 1997 (tax rates), the last time this was a non-issue.
While tech bros and Wall Street may get a lot of press of getting lots of money, the recent book The Everywhere Millionaire: Who Is Really Rich in America and How They Got There seems to show (using IRS data, etc) a large portion of the wealth being held in private hands.
Interview on Bloomberg's Odd Lots:
> In 2014, the economists Owen Zidar and Eric Zwick were asked by the Treasury to conduct a study on the tax burden of private business owners. It was tricky to figure out how much these sorts of business owners — auto dealers, contractors, the like — actually owed in taxes: After Reagan's 1986 tax reforms, pass-through businesses and other accounting tricks became widespread enough to obscure this class of wealthy Americans hiding in plain sight. The research they conducted led to their new book The Everywhere Millionaire: Who Is Really Rich in America and How They Got There, and one of their central findings is that there are about three million private business owners who have an average wealth of around $25 million. They call this group “Main Street Millionaires” and their influence on the economy and politics in the US is considerable. We speak with Zidar and Zwick today about how they measured the actual number of rich people in America by sifting through reams of tax forms, why income inequality started to rise in tandem with the growing number of pass-through businesses, and how it's possible that the collective revenue of the nation's dentists far exceeds that of the NFL.
(Lots of other interviews as well as the book just came out a few months ago, so the authors did a book tour.)
Some take aways from the books:
> According to Zidar and Zwick, Main Street Millionaires hold over 13x more wealth than the Forbes 400. And where do they hold it? In pass-through entities (like LLCs and S-corps) in various industries. Which industries in particular? Zidar and Zwick note that the top five are:
> 1. Legal services. This is mostly law firm partnerships.*
> 2. Financial investment activities. This includes venture capital, private equity, and hedge fund managers.
> 3. Auto dealers. These are the local, independently owned dealerships that sell new and used cars.
> 4. Professional and technical services and management consulting. This includes independent consulting firms and other specialized professional practices.
> 5. Oil and gas extraction. This includes fracking companies in North Dakota, Pennsylvania, and other states.
An interesting observation: a radiologist working at a hospital may make much less if they're an employee of the hospital, versus something like a 'consultant' who use an pass-through S-Corp at the same hospital doing the same work.
Pounds vs kg: see above. All the non-American people seem to have "intuitive" grasp of metric measurements.
> 0-100 MPH lines up well with car speeds, which is usually the thing you're measuring with that. KPH is excessively granular for that. Probably not by design, but yeah.
So 'more granularity' is good for temperature but not for speed. Got it.
> The feet/inches vs meters/cm thing matters less. It's base-12 vs base-10. You can do decimal feet or fractional meters of course, but it's less common, so apparently both ways are fine.
By "foot" do you mean 'regular' foot or survey foot:
* https://www.nist.gov/pml/us-surveyfoot
Because there are two different units in the US customary system, used for basically the same purpose, that use the same name. And the "foot" isn't the only unit like that:
* https://en.wikipedia.org/wiki/Pound_(mass)
* https://en.wikipedia.org/wiki/Pound_(force)
Here's another one: which weighs more, a pound of feathers or a pound of gold? A pound of feathers. Because feathers use one 'pound-system' [1] and is 453g, while gold uses another pound-system [2] and is 373g. But of course an "ounce" of gold (31g) is more than an "ounce" of feathers (28g), because Troy is 1/12 of pound but Avoirdupois is 1/16. In addition to the above "ounces" there is also "fluid ounces".
[1] https://en.wikipedia.org/wiki/Avoirdupois
[2] https://en.wikipedia.org/wiki/Troy_weight
reply