Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Bulls... since when will self driving cars have (Score 4, Insightful) 451

by Dagger2 (#49290367) Attached to: Lyft CEO: Self-Driving Cars Aren't the Future

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.

Comment: Re:Now if they will sell them without MS Windows (Score 0, Troll) 161

by Dagger2 (#49208831) Attached to: Ultralight Convertibles Approaching Desktop Performance

If it would boot your Linux distro it'd also boot whatever malware was trying to trojan Windows and that's exactly what they're trying to avoid

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.

Comment: Re:Get ready for metered service (Score 1) 631

by Dagger2 (#49140463) Attached to: FCC Approves Net Neutrality Rules

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.

Comment: Re:Firewall through the Firewall? (Score 1) 147

by Dagger2 (#49127687) Attached to: Firefox 36 Arrives With Full HTTP/2 Support, New Design For Android Tablets

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.

Comment: Re:Great if optimizing the wrong thing is your thi (Score 3, Interesting) 171

by Dagger2 (#49083397) Attached to: HTTP/2 Finalized

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.

Oh! by the way, not everybody's connection is like yours, specially over mobile networks.

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.)

Comment: Re:Great if optimizing the wrong thing is your thi (Score 4, Informative) 171

by Dagger2 (#49079567) Attached to: HTTP/2 Finalized

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.

Comment: Re:BSD is more threatening than proprietary (Score 5, Informative) 551

by Dagger2 (#49012439) Attached to: RMS Objects To Support For LLVM's Debugger In GNU Emacs's Gud.el

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.

Comment: Re:SIP Replacement? (Score 1) 282

by Dagger2 (#48912885) Attached to: EFF Unveils Plan For Ending Mass Surveillance

For example, you can't run a Minecraft server on an IPv6 address.

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.

Comment: Re:Dewhat? (Score 1) 150

by Dagger2 (#48806917) Attached to: Wireless Keylogger Masquerades as USB Phone Charger

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.

Comment: Re:Dewhat? (Score 4, Informative) 150

by Dagger2 (#48806251) Attached to: Wireless Keylogger Masquerades as USB Phone Charger

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.

To downgrade the human mind is bad theology. - C. K. Chesterton

Working...