I don't know that. It should be perfectly possible to make a machine that can drive as well as, or better than, a human can. Have we managed to make that already? I don't know, but from the info Google have been publishing, it actually looks like we have, or are pretty damn close.

Just because it's a machine doesn't automatically mean that it sucks at making decisions. Humans are machines too, and we let them drive.

No it's not. Malware is the excuse, much like child porn or terrorists are the excuse for internet filtering (and more or less anything else you want to force through as a law these days).

The real goal is to make it as hard as possible to switch away from Windows.

I might be guessing wrong here, but I'm thinking the primary intention of these new TLDs was to earn ICANN shitloads of money. It costs $185,000 just to apply for one, and $25,000/year to keep it.

Every Fortune 500 company doing the same thing would be a dream come true for them.

Perhaps... thus turning a lack of capacity into a profit center for the ISP. They're bad enough at having enough capacity as it is, without giving them a profit incentive to make their connections as bad as possible.

Because bandwidth works differently to those.

For electricity, water and gas, every bit of it you consume has to be produced somewhere and then shipped to you. This isn't true for bandwidth; bandwidth is produced on a constant basis at every link in the internet and is then thrown away if it's not consumed immediately. As a result, any bandwidth used at off-peak times has zero impact on the production cost, because you're using bandwidth that would've had to be thrown away anyway.

Yeah, it looks like the protocol involves sending a UDP packet to 239.255.255.250 port 1900, and waiting for any devices to send a packet back. The return packets will come from the devices' unicast address rather than the discovery multicast address, so you can't rely on normal state tracking to let the return packets in automatically.

The bugs are a bit convoluted, because there's a lot of them and this code originally landed for Mobile before being ported to desktop. There's Bug 1090535... the actual discovery code lives in SimpleServiceDiscovery.jsm.

Nope. Bug 1054959: it's searching your network for Roku or Chromecast devices so you can fling videos and tabs to them.

No... maybe. It depends.

Amdahl's law is in full force here. There comes a point where increasing the bandwidth of an internet connection doesn't make pages load faster, because the page load time is dominated by the time spent setting up connections and requests (i.e. the latency). Each TCP connection needs to do a TCP handshake (one round trip), and then each HTTP request adds another round trip. Also, all new connections need to go through TCP window scaling, which means the connection will be slow for a few more round trips. Keep-alive connections help a bit by keeping TCP connections alive, but 74% of HTTP connections only handle a single transaction, so they don't help a great deal.

Mobile networks (and, yes, satellite) tend to have high latency, so round-trips are even more of the problem there. Also... when people shop for internet connections, they tend to concentrate on the megabits, and not give a damn about any other quality metrics. So that's what ISPs tend to concentrate on too. You'll see them announce 5x faster speeds, XYZ megabits!!, yet they don't even monitor latency on their lines. And even if your ISP had 0ms latency, there's still the latency from them to the final server (Amdahl's law rearing its ugly head again).

Given all that, I think I'm justified in saying that the main problem with page loading times isn't the amount of data but the number of round-trips required to fetch it. Reducing the amount of data is less important than reducing the number of, or impact of, the round-trips involved. And that's the main problem that HTTP/2 is trying to address with its fancy binary multiplexing.

(Now, if your connection is a 56k modem with 2ms latency, then feel free to ignore me. HTTP/2 isn't going to help you much.)

The main problem isn't the size of the stuff that gets loaded. What's dozens of kb these days? Even a megabyte takes a tenth of a second to transfer on my connection. The problem is latency: it takes more than 100ms for that megabyte of data to even start flowing, let alone get up to speed. That's what the multiplexing is intended to deal with.

That said, the root cause of all this is the sheer amount of unnecessary stuff on pages these days. Fancy multiplexing or not, no request can finish faster than the one that's never made.

Yet. Yet.

There's nothing that says an AI can't do creative jobs. "Our current AIs can't do them" doesn't say anything about our future AIs.

Sure: the GPL strictly states that nobody is allowed to put handcuffs on you. BSD is more along the lines of "anybody can stick handcuffs on you".

If you don't want handcuffs on you, you want the former, not the latter.

Well, it is, but it does sod all to protect that openness, so BSDed software often ends up less open by the time you actually get a copy of it.

The only stuff the GPL doesn't let you do is remove other people's freedom. That should never be a problem unless you were planning to do that in the first place.

Yes you can! This worked fine the last time I tried it.

What didn't work fine was the client. The client actively disables IPv6 support in Java. The bug report is here if you wouldn't mind adding another useless request for them to fix their shit.

Needing to know the MAC address is just a limitation of the nRF24L01+ chip he was using. Conveniently though, the chip has an undocumented feature (or bug) that lets you trick it into giving the full packet, including the MAC address header. The only brute force scanning he ends up doing is to scan through all the different frequencies.

And the "key" is xored with the plaintext to get the "encrypted" text, and the typed character is in a single byte. So you only actually need a single byte of the MAC address.

And it happens to be the first byte, which for these Microsoft keyboards is always 0xCD. So you don't even need to bother figuring out what the MAC address is.