Slashdot videos: Now with more Slashdot!

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.

And if SOCKS isn't enough, you can also do ssh -w 42:42 to link a pair of tun interfaces between the two sides. (Slightly less cool because you have to manually configure networking on both ends for it.)

And then the summary decides to hold compression up as the super amazing feature that nobody has ever heard of...

Because FOSS still doesn't place some arbitrary BS restriction on fixing stuff.

Yes, it's true that a lot of users won't have the knowledge to do it, or won't be competent enough. Heck, even the people who can fix bugs won't have the time to fix every bug they encounter. But at least FOSS doesn't just outright ban you from doing it.

It's not meant for an economy. Bitcoin is intended as a way to move your dollars around, not as a replacement for dollars.

It shouldn't be too surprising that Bitcoin is bad at something it wasn't designed to do, but that's not a good reason to avoid using it for what it was designed to do.

There have always been. Don't make the assumption that this'll always be true.