Eyron

Technically, it might be faster, but that's not usually the reason. Email servers generally have to do a lot of work to confirm email messages are not spam. That work usually takes significantly longer than any potential DNS savings. In fact, that spam checking is probably the reason you see the secondary domains used.

When the main domain used for many purposes (like servers, users, printers, vendor communications, accounting communications, and so forth) It leaves a lot of room for misuse. Many pre-ransomware viruses would just send out thousands of emails iper hour. The mass communicating server could also reduce the domain reputation. There are just so many ways to tarnish the reputation of your email server or your email domain.

Many spam analysis systems group the subdomains and domain together. The subdomains contribute to the domain score and the domain score contributes to the subdomain score. To send a lot of emails successfully, you need both your servers and domains to have a very strong and very good reputation. Any marks on that reputation might prevent emails from being received by users. When large numbers of emails need to be controlled, it can be hard to get everyone in the organization to adhere to email rules (especially when the the problems aren't users, but viruses/hackers) and easy to just register a new domain, more strictly controlled domain.

Some of the recent changes in email policies/tech might change the game, but old habits die hard. Separate domains can still generally be more successfully delivered, have potential security benefits, and can often work around IT or policy restrictions. They might phase out, but they might not. The benefit usually outweighs the slight disadvantage that 99% of people won't see.

tl;dr

Better controlled email reputation.

It can be pretty easy to get up a second-hand console cheap, free, and/or as a gift.

Have you ever seen how much good/working stuff people throw away? If you're a little bright, you can get people to pay you to haul their "junk" away.

Time isn't the only factor for adoption. Between the adoption of IPv4 and IPv6, the networking stack shifted away from network companies like Novell to the OSes like Windows, which delayed IPv6 support until Vista.

When IPv4 was adopted, the networking industry was a competitive space. When IPv6 came around, it was becoming stagnant, much like Internet Explorer. It wasn't until Windows Vista that IPv6 became an option, Windows 7 for professionals to consider it, and another few years later for it to actually deployable in a secure manner (and that's still questionable).

Most IT support and developers can even play with IPv6 during the early 2000s because our operating systems and network stacks didn't support it. Meanwhile, there was a boom of Internet connected devices that only supported IPv4. There are a few other things that affected adoption, but it really was a pretty bad time for IPv6 migration. It's a little better now, but "better" still isn't very good.

You should probably read/know the actual law, rather than just getting it close. You're probably referring to 18 USC 922 (d) (10), which includes any felony-- not just shooting. That's one of 11 listed requirements in that section, which assumes that the first requirement (a) (1) is met: not an interstate nor foreign transaction. There's a lot more to it than just "as long as you don't have good evidence they're going to go shoot someone"

Even after the sale, ownership is still illegal under section (g)-- it just isn't the seller's fault anymore.

This is basic information that should be known to any gun safety advocate. "Responsible" gun owners must know those laws, plus others backward and forward. One small slip-up is a felony, jail, and permanent loss of gun ownership/use. Are they really supposed to listen to those who can't even talk about current law correctly?

The law can be better, but you won't do yourself any favors by misrepresenting it.

Voyager - if I didn’t love Voyager Janeway would kick my ass.

No need for threats. Voyager is good.

Blink twice if you need help.

It seems you are mixing the concepts of voting systems and candidate selection. FPP nor FPTP should not sound scary. As a voting systems, FPP works well enough more often than many want to admit. The name just describes it in more detail: First Preference Plurality.

Every voting system is as bottom-up or top-down as the candidate selection process. The voting system itself doesn't really affect whether it is top down or bottom up. Requiring approval/voting from the current rulers would be top-down. Only requiring ten signatures on a community petition is more bottom up.

The voting systems don't care about the candidate selection process. Some require precordination for a "party", but that could also be a party of 1. A party of 1 might not be able to get as much representation as one with more people: but that's also the case for every voting system that selects the same number of candidates.

Voting systems don't even need to be used for representation systems. If a group of friends are voting on where to eat, one problem might be selecting the places to vote on, but that's before the vote. With the vote, FPP might have 70% prefer pizza over Indian food, but the Indian food vote might still win because the pizza voters had another first choice. Having more candidates often leads to minority rule/choice, and that's not very good for food choice nor community representation.

That many steps? WindowsKey+Break > Change computer name.

If you're okay with three steps, on Windows 10 and newer, you can right click the start menu and generally open system. Just about any version supports right clicking "My Computer" or "This PC" and selecting properties, as well.

Do you remember the Internet Explorer days? This, unfortunately, is still much better.

Pretty good reason to switch the Firefox, now. Nearly everything will work, unlike the Internet Explorer days.

• Firefox User

Do you use Android? AI was the last thing on their minds for AOSP until OpenAI got popular. They've been refining the UIs, improving security/permissions, catching up on features, bringing WearOS and Android TV up to par, and making a Google Assistant incompetent. Don't take my word for it; you'll rarely see any AI features before OpenAI's popularity: v15, v14, v13, and v12. As an example of the benefits: Google and Samsung collaborating on WearOS allowed more custom apps and integrations for nearly all users. Still, there was a major drop in battery life and compatibility with non-Android devices compared to Tizen.

There are plenty of other things to complain about with their Android development. Will they continue to change or kill things like they do all their other products? Did WearOS need to require Android OSes and exclude iOS? Do Advertising APIs belong in the base OS? Should vendors be allowed to lock down their devices as much as they do? Should so many features be limited to Pixel devices? Can we get Google Assistant to say "Sorry, something went wrong. When you're ready: give it another try" less often instead of encouraging stupidity? (It's probably not going to work if you try again).

Google does a lot of wrong, even in Android. AI on Android isn't one of them yet. Most other commercially developed operating systems are proprietary, rather than open to users and OEMs. The collaboration leaves much to be desired, but Android is unfortunately one of the best examples of large-scale development of more open and libre/free systems. A better solution than trying to break Android up, is taking/forking Android and making it better than Google seems capable of.

I’m fully aware how rirs allocate ipv6. The smallest allocation is a /64, that’s 65535 /64’s. There are 2^32 /32’s available, and a /20 is the minimum allocatable now. These aren’t /8’s from IPv4, let’s look at it from a /56, there are 10^16 /56 networks, roughly 17 million times more network ranges than IPv4 addresses.

/48s are basically pop level allocations, few end users will be getting them. In fact comcast which used to give me /48s is down to /60 now.

I’ll repeat, we aren’t running out any time soon, even with default allocations in the /3 currently existing for ipv6.

Sorry, but your reply suggests otherwise.

The RIRs (currently) never allocate a /64 nor a /56. /48 is their (currently) smallest allocation. For example, of the ~800,000 /32's ARIN has, only ~47k are "fragmented" (smaller than /32) and <4,000 are /48s. If /32s were the average, we'd be fine, but in our infinite wisdom, we assign larger subnets (like Comcast's 2601::/20 and 2603:2000::/20).

These aren’t /8’s from IPv4. let’s look at it from a /56, there are 10^16 /56 networks, roughly 17 million times more network ranges than IPv4 addresses.

Taking into account the RIPE allocations, noted above, the closer equivalent to /8 is the 1.048M /20s available. Yes, it's more than the 8-bit class-A blocks, but does 1 million really sound like the scale you were talking about? "enough addresses in ipv6 to address every known atom on earth"

The situation for /48s is better, but still not as significant as one would think. With Cloudflare as an extreme example: They have 6639 IPv4 /24 blocks, but 670,550 IPv4 /48 blocks. Same number of networks in theory, but growing from needing 13-bits of networks in IPv4 to 19-bits of networks: 5 extra bits of usage from just availability.

That sort of increase of networks is likely-- especially in high-density data centers where one server is likely to have multiple IPv6 networks assigned to it. What do you think the assignments will look like as we expand to extra-terrestrial objects like satellites, moons, planets, and other spacecraft?

I’ll repeat, we aren’t running out any time soon

Soon vs never. OP I replied to said "never". Your post implied similarly, too-- that these numbers are far too big for humans to imagine or ever reach. The IPv6 address space is large enough for that: yes. But our allocations still aren't. The number of bits we're actually allocating (which is the metric used for running out) is significantly smaller than most think. In the post above, you're suggesting 56-64 bits, but the reality is currently 20-32 bits-- 1M-4B allocations.

If everyone keeps treating IPv6 as infinite, the current allocation sizes would take longer than IPv4 to run out, but it isn't really an unfathomable number like the number of atoms on Earth. 281T /48s works more sanely: likely enough for our planet-- but RIPEs seem to avoid allocating subnets that small.

IPv4-style policy shifts could happen: requirements for address blocks rise, allocation sizes shrink, older holders have /20 blocks (instead of 8-bit class A blocks), and newer organizations limited to /48 blocks or smaller with proper justification. The longer we keep giving away /20s and /32s like candy, the more likely we'll see the allocations run out sooner (especially compared to never). My initial message tried to imply that it depends on how fast we grow and achieve network growth goals:

30 years? Optimistically, including interstellar networks and continued exponential growth in IP-connected devices? Yes.

. . .

Realistically, it’s probably more than 100 years away, maybe outside our lifetimes

That wasn't what I said. 2^56 was NOT a reference to bits, but to how many IPs we could assign every visible star, if it weren't for subnet limitations. IPv6 isn't classless like IPv4. There will be a lot of wasted/unrunused/unroutable addresses due to the reserved 64-bits.

The problem isn't the number of addresses, but the number of allocations. Our smallest allocation, today, for a 128-bit address: is only 48-bits. Allocation-wise, we effectively only have 48-bits of allocations, not 128. To run out like with IPv6 , we only need to assign 48-bits of networks, rather than the 24-bits for IPv4. Go read up on how ARIN/RIPE/APNIC allocate IPs. It's pretty wasteful.

There's a large possibility we'll run out of IPv6 addresses sooner than we think.

Theoretically, 128-bits should be enough for anything. IPv6 can theoretically give 2^52 IPs to every star in the universe: that would be a 76-bit subnet for each star rather than the required 64 minimum. Today, we (like ARIN) do 32-48-bit allocations for IPv6.

With IPv4, we did 8-24-bit allocations. IPv6 gives only 24 extra allocation bits, which may last longer than IPv4. We basically filled up IPv4's 24-bits of allocations in 30 years. 281 trillion (2^48) allocations is fairly reachable. There doesn't seem to be any slowdown of Internet nor IP growth. Docker and similar are creating more reasons to allocate IPs (per container). We're also still in the early years of interstellar communications. With IPv4, we could adopt classless subnetting early to delay the problem. IPv6's slow adoption probably makes a similar shift in subnetting unlikely.

If we continue the current allocation trend, can we run out of the 281 trillion allocations in 30 years? Optimistically, including interstellar networks and continued exponential growth in IP-connected devices? Yes. Realistically, it's probably more than 100 years away, maybe outside our lifetimes, but that still sounds low when IPv6 has enough IPs for assigning an IP to every blade of grass, given every visible star has an Earth. We're basically allocating a 32-48 bit subnet to every group of grass, and there are not really enough addresses for that.