Hybrids don't have a range problem, and they also aren't the subject of the article... LOTS of people have hybrids today; you don't notice them as much because they look just like their non-hybrid models. Pure EVs aren't selling well because they cost (a lot) more (in some cases 2x), have crap range (100-200mi vs 500-700mi), and take forever to recharge (hrs vs. mins.)

For the record, I make numerous 200+mi trips per year: 223mi 3-4x, 209mi 2x, 536mi 1x. Last year included a trip to Sebring FL (752mi)

That's ok, just make it all work like Facebook. That seems to be the standard progression of every app on every device on the market today.

You've clearly never worked in any admin position. When someone is being fired, only those required to make the firing decision (management, HR, etc.) will be in-the-know. At the time of firing, only those necessary to effect the dismissal (i.e. IT, security, etc.) will be told about it; and they won't be told shit as to why.

The mods are a bunch of stupid children. If they aren't happy with the way things are being run, they can work within the system tty to change it, or they can quit. Paid or not has nothing to do with it; unprofessional childish bullshit is just that. Trashing the site is what a 5yo would do.

Nope. If you have what's called a "legacy allocation", then your block is old enough to not be encumbered by any of ARIN's current rules.

The key annoyance of "chrome" is chrome. Opera is nothing more than a different skin on the same steaming turd. (and their devs have all but said so. They aren't happy with chromium's extreme memory consumption, but there's only so far they can go to "fix it".)

Cellphones operate in licensed bands. Thus, jammers are illegal.

Drones (RC crap) operate in unlicensed bands and must accept any interference that may exist. Jamming them is not, technically, illegal. However, jamming them would not be in anyone's best interest -- or really worth the effort. (how many jammers would it take to cover a mountain?)

Arming the DC10 is, of course, the correct answer. :-)

There are lots of switches running linux. Of course, linux isn't the thing doing the switching.

The question to ask is can you get to the OS and/or ssh configuration to remove whatever the vendor may have installed? (i.e. remove whatever ssh backdoor keys they left there.) In most cases, the answer is "Hell. No."

You'd be surprised just how hard it is to evict someone from a residential property.

(Commercial property, at least around here, 30 days and we can sell off or discard anything you left behind. And keep your deposit.)

On the other hand, if they cannot get credit, they really cannot afford to buy that house. They might be able to make the payments, otherwise, but lenders are a lot more risk averse -- and for damn good reason. Rents then naturally rise to the levels of a mortgage and *bam* the people who couldn't get financing also cannot stockpile cash to improve their ability to secure financing.

And yet, I see all the "for rent" and "space available" signs around town listing rents at basically the same rates I paid a decade ago.

RFC2131, Section 4.4.1

The word used is SHOULD. There are still plenty of DHCP systems that request (require) a broadcast reply. Go listen to the broadcast traffic on your cablemodem.

And I'm FAR TOO well aware of systems using the wrong hardware address in their requests -- more than one nic, and it uses the MAC from the first nic in all queries no matter which nic it's asking about or using. (and this is from an ISC DHCP client!)

TL;DR chaddr [Client Hardware ADDRess] is 16 bytes of whatever the client puts there.

(Replies in my network are broadcast so the boot agent can see them.)

Stock android has no means to handle DHCPv6. It's not there. At all. You can (maybe) root your device and (maybe) add it yourself. But that's beyond 99% of android users. ("root, run custom rom downloaded from internet" - lots of people do that.)

You can call it BS all you want, but there are environments where legal accountability is a requirement. Could you side-step their tracking voodoo? Probably, but that's even more tinkering with your android device.

Using the MAC as an ID is a flawed method. Devices come and go, MACs change (because the NIC changed, etc.) Ultimately -- and here's the end of it -- you'd have to be maintaining a registry of every device's MAC within your network to know what's what, where, and who's using it. Just gleaning a "list of mac's" is simple enough, albeit a tedious pain in the ass: arp tables, cam tables, watching broadcast traffic, etc. Knowing the location of each device gets a lot more tricky; sure wired devices will be tethered somewhere off a switch port, but that's not always enough. Wireless devices, on the other hand, can be anywhere. And none of that addresses who's device it is, who's using it, and exactly what it is. (OUI's only go so far, and assume no one is forging their MAC.)

When someone carries a device into the office, does something questionable with it, and then leaves, tracking the who/what/where/when becomes much harder. When the questionable act isn't mentioned for weeks or months, it can become impossible.

Case in point, I had to trace down a "hacker box" in the network. It was a lot easier because it was ON and ACTIVE at the time. Looking through cam tables, I could only go so far as an unmanaged hub. (yes, this company still used far too many hubs. even in 2003.) Careful inspection of the hub (and unplugging one port at a time), localized it to a desk. An unoccupied cubical, in fact. By the time I got to that desk, the machine had been turned off (it was still warm), the "warez" hard drive had been removed (windows registry remembers it), and the non-company 3com nic had been removed (again, registry -- which is how I knew 100% that's the machine I'm looking for.) That was the company computer for that desk, which is the only reason it was still there. Had he used one of his own machines, it could've simply disappeared without a trace. Moral of the story: I had a MAC, and it didn't tell me shit. The "who" was only discovered because his coworkers ratted him out :-) ("Who's been using X's computer?" They didn't know he was doing anything stupid with it.) And that only worked because it was in real time; had it been brought up a month later (nothing to trace) (and there not been a hub muddying the picture), any history logs would simply have ended with "I don't know. It was something at X's desk" [X having left the company many months ago. X's computer official off since it's builtin NIC, registered in company inventory, wasn't being used.]

so you are going to need to know, in advance, who's MAC is who's. You'd need that knowledge for a DHCP server too...

One does not pre-program the DHCP server with a list of MACs, nor does every client identify itself by MAC -- the client-id can be many things, MAC being but one of them.

In order for you to get the reply back from the DHCP server, it needs your MAC address.

*sigh* No it doesn't. A unicast reply needs a destination MAC, either the end client or a relay agent. A broadcast reply, however, DOES. NOT.

*sigh* Those devices ARE BROKEN! And the entire networking world knows it. SLAAC still requires ::/64, as far as I'm aware. However, privacy extensions no longer mandate this brain damage.

Hundreds of people have warned, just as I have, that people can be (and WILL be) stupid, and thus make these blanket assumptions.

No. No sane person assumes the size of a non-local network. A lot of the world does, in fact, bow to the stupid that is SLAAC, but it's not "everywhere", nor do hardware vendors worth their salt make any such assumptions or impose restrictions -- your network can be any size you wish. Your ISP is likely to assign you a ::/64 (60, or 56) because it's the lowest common denominator. (and because they tend to use cheap trash for CPEs.) Giving you anything smaller, while technically feasible, creates hurdles for people with little to no networking expertise.

And if you have android devices, it's the only way to get the damned things on your IPv6 network.