Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comments

top

The IPv4 Internet Hiccups

rekoil Re:IPv6 would make the problem worse (248 comments)

While in practice most admins configure /64s as subnets, there's nothing preventing netblocks that are smaller than /64. I have /127 point-to-point subnets on my network, and /96s going to server racks. You need a /64 in order to do RA, however, but you can use DHCPv6 instead on smaller subnets.

about a month and a half ago
top

How Google Broke Itself and Fixed Itself, Automatically

rekoil More likely case (125 comments)

What's more likely - I've run into exactly this scenario before, in fact - is that the configuration generation system regenerates configs on a regular schedule, and at one point encountered a failure or spurious bug that caused it to push an invalid config. On the next run - right as the SREs started poking around - the generator ran again, the bug wasn't encountered, and it generated and pushed a correct config, clearing the error and allowing apps to recover.

about 8 months ago
top

Interviews: Q&A With Guido van Rossum

rekoil Re:Why did Python avoid some common "OO" idioms? (242 comments)

In python, that's correct. There's some method name mangling to ensure that devs writing code calling private methods know what they're doing, but otherwise it's allowed. In other languages (Java for example) private methods are completely hidden from outside classes.

about a year ago
top

Ask Slashdot: Building a Web App Scalable To Hundreds of Thousand of Users?

rekoil Re:Silly priorities (274 comments)

Disclaimer: Another Twitter engineer here. What my apparently former colleague said, plus X.

Also: Don't be afraid to add caching layers when you see your web server or DBs start to run hot. Putting a memcached instance in place in "front of" your database layer is much easier than sharding the database layers to relieve load - eventually you'll have to do both, but you'll definitely want the memcache layer first. Same with web caches/proxies - putting varnish or squid in front will take some pressure off before you need to implement load balancers.

about a year and a half ago
top

The Data That Drove Yahoo's Telecommuting Ban

rekoil Re:I can slack off anywhere (529 comments)

That's true, and everyone who knew how to use it did, because Cisco's VPN client software is crap.

about a year and a half ago
top

SpaceX Pressure Hammers Stuck Valves; Dragon's ISS Mission Back On Track

rekoil CEO that knows his tech (170 comments)

Could you imaging the CEO of Northrop Grumman or Lockheed being able to talk about the engineering issues at this level of detail? Or even the head of NASA? This is why I bought TSLA stock.

about a year and a half ago
top

Groupon Still Losing Money, CEO Is Fired And Leaks Final Email

rekoil Re: For those who are concerned about me (207 comments)

His severance package is $378.36. not $378 thousand or $378 million, Three Hundred and Seventy Eight dollars and Thirty Six cents.

about a year and a half ago
top

SPDY Not As Speedy As Hyped?

rekoil Re:Not so fast...YET (135 comments)

In fact, if SPDY support was ubiquitous tommorrow, I would be surprised to see SPDY+TLS used for third party ad serving for this very reason.

Good news here: Google's DoubleClick and AdSense ads are served over SPDY today. In fact, I'm not aware of any Google properties that don't use SPDY, since they're all routed through the same GFE (Google FrontEnd) proxy farms.

more than 2 years ago
top

SPDY Not As Speedy As Hyped?

rekoil Re:Too many connections (135 comments)

The good news there is that connections to Google's ad networks DO run over SPDY now, assuming a compatible browser.

more than 2 years ago
top

SPDY Not As Speedy As Hyped?

rekoil Re:Why not BEEP? (135 comments)

Because no one's bothered to ship a BEEP implementation in a major browser release?

more than 2 years ago
top

SPDY Not As Speedy As Hyped?

rekoil Re:The problem with the test ... (135 comments)

SPDY as implemented requires SSL, since the protocol capability is negotiated by a TLS extension on port 443. There's no spec for negotiating SPDY on a standard HTTP port - it would only work if the capability was assumed on both sides before the connection (for example, URLs that start with spdy:// instead of http:/// which connects to a different TCP port on the server).

more than 2 years ago
top

SPDY Not As Speedy As Hyped?

rekoil Re:Single domain? (135 comments)

That only works if all of those hostnames resolve to the same IP addresses. The main optimization in SPDY is the elimination of the need to make multiple TCP connections simultaneously, but all of those resources must live on the same server. If the resources have different hostnames, you might be able to detect hostnames that point to the same IP and then interleave those, but I don't know if the current implementations do that yet.

Most CDNs, however, return different IPs for nearly every query, and web developers use multiple hostnames pointing to the same resources to get non-SPDY multiplexing today. This sounds like an optimization that's easy to accomplish dynamically, though (if request is SPDY, don't spread the resources across different hostnames).

more than 2 years ago
top

SPDY Not As Speedy As Hyped?

rekoil Re:What is the big deal with SPDY? (135 comments)

1. HTTP Pipeline support proved very difficult to implement reliably; so much so that Opera was the only major browser to turn it on. It can be enabled in Chrome and Firefox but expect glitches. By all accounts SPDY's framing structure is far easier to reliably implement.

2. WIth SPDY, it's not just the content that's compressed but the HTTP headers themselves. When you look at the size of a lot of URLs and cookies that get passed back and forth, that's not a insignificant amount of data. And since it's text, it compresses quite well.

3. SSL is required for SPDY because the capability is negotiated in a TLS extension. Many people would argue that if this gets more sites to use SSL by default, that's a Good Thing.

4. If you're running SPDY, the practice of "spreading" site content across multiple hostnames, which improves performance with normal HTTP sites, actually works against you, since the browser still has to open a new TCP connection for each hostname. This is an implementation issue more than an issue with the protocol itself; I expect web developers to adjust their sites accordingly once client adoption rates increase.

5. The biggest gains you can get from SPDY, which few have implemented, is the server push and hint capability; this allows the server to send an inline resource to a browser before the client knows it needs it (i.e. before HTML or CSS is processed by the browser).

But as someone else as pointed out, the author's test isn't really valid, as he didn't test directly to sites that support SPDY natively, he went through a proxy.

The website I work for is supporting SPDY, and the gains we've seen are pretty close to the ~20-25% benchmarks reported by others. As many have pointed out, this author's methodology is way broken. I'd recommend testing to sites that are known to support SPDY (the best-known are Google and Twitter), with the capability enabled and then disabled (You can set this in Firefox's about:config, Chrome requires a command line lauch with --use-spdy=false in order to do this, though).

more than 2 years ago
top

Inventor of the TV Remote Control Dies

rekoil Re:Parrot TV (113 comments)

I remember these. They weren't even electronic - each button on the remote caused a tine to be pulled and released which was tuned to a specific ultrasonic frequency. This is why the early remotes were called "clickers" - releasing the tine made a metallic clicking sound. It also meant that random ambient sounds that matched the target frequency could cause your TV to turn on/off, change channels, etc on its own.

There were also remotes that weren't even wireless, with a 10' long tether wire to the unit. The advertised "advantage" of these was that they didn't need batteries.

more than 2 years ago
top

Huawei Claims 30Gbps Wireless 'Beyond LTE'

rekoil Re:So? (146 comments)

Hear hear. For example, my mother uses 3G (and soon LTE) for internet access to her home, which is a rural area that isn't served by either cable or DSL, and has no line-of-sight access for satellite service.

more than 2 years ago
top

Microsoft Issuing Unusual Out-of-Band Security Update

rekoil Re:Better Writeup (156 comments)

That's how perl was fixed - XOR each incoming key with a random value generated when the hash is initialized.

more than 2 years ago
top

Microsoft Issuing Unusual Out-of-Band Security Update

rekoil Re:Changing a hash function... (156 comments)

The real problem here is that it's fairly easy to compute a set of hash keys that are known to generate collisions on a specific hash table implementation. The easiest fix by far - the fix that perl implemented in 2003 - is to generate a random value when the hash is initialized, and XOR each incoming key with it before processing. That breaks collision prediction on the attacker's side quite effectively.

more than 2 years ago
top

Microsoft Issuing Unusual Out-of-Band Security Update

rekoil Re:Priorities (156 comments)

To be precise, it elements with equal *exit* hash values - the same hash key will simply overwrite prior values. Internally, the language runs a hash algorithm against the key and uses the resulting value to generate an index to the array that *actually* holds the key/value pair. If multiple keys hash to the same index, then the value will actually be another array, containing all the key/value pairs that mapped to that index. You then need to walk that index to find the key you're looking for.

The downside of this, of course, is that if all of your keys map to the same hash value, then you have to walk the list of *all* key/value pairs to find your value. Producing this scenario on demand is how you kill servers with it.

The "real" code fix so far is to transmute the key with a random value (generated at application startup, or at instantiation of the hash map) before running the hash algorithm, thus making it impossible to predict which keys will generate hash collisions. This is how perl was fixed this back in 2003 :)

Most folks seem to simply be setting limits on the number of fields in POST (or the maximum size of a POST payload) for now until they can fix their code. Putting limits on the number of HTTP headers in a request is needed as well, as apache itself puts headers in a hash map.

more than 2 years ago

Submissions

rekoil hasn't submitted any stories.

Journals

rekoil has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?