Slashdot has notoriously always had a comically unfunny April 1st, and at this point I have to think the complete lameness of it all is the real meta-joke.
The whole "HTTP/2 stink" thing seems to be a bit of a meme, but it's remarkable how the people who state it vaguely wave their hands around and make unsupported claims.
1. HTTP/2 is *fantastic* for higher latency connections. If you're a small site and you can't afford to have geolocated servers around the globe, HTTP/2 offers a much better experience for those high latency connections. I've been using SPDY for a couple of years to service clients in Singapore from a server in the US (which for a variety of legislative and technical reasons I can't replicate there). It is absolutely better.
2. HTTP Pipelining is when you know that someone is just doing the "I oppose" thing and searching around for objections. HTTP pipelining is not supported by default in a *single* major browser because it has critical, deadly faults that render it useless. When people bring it up to oppose HTTP/2, their position is rendered irrelevant.
3. HTTP/2 removes the need to do script and resource coalescing. It removes the need to deal with difficult to manage image sprites. All of those are bullshit that are particularly onerous and expensive to little sites.
4. HTTP/2 makes SSL much cheaper to the experience. This is very good.
HTTP/2 is a *huge* benefit especially to the little guy. Google can do every manner of optimization, they can deploy across legions and armies of servers around the globe. This can be expensive and logistically difficult for little sites, especially if you want SSL. HTTP/2 levels the playing field to some degree.
It isn't about "a chip". It's about a system that is designed for a specific thermal and electrical load. nvidia probably got flak from notebook makers who were facing dissatisfied customers.
You only have to look at a lot of the nonsense comments throughout, such as yours -- people just contriving how "easy" everything is, and how simple it is. Yeah, and I'll bet all of you design notebooks. No? Then shut up.
To the best of my knowledge "head starts" in letters and numbers make no difference in long-term outcomes. I'm disappointed to hear Gates pushing for this sort of thing. Solid educational resources at the right developmental stages are critical for long-term success, not some sort of fast-track to the ABCs.
Investors don't care about 20% revenue growth y-o-y if EPS has tanked.
GOOG Earnings Per Share:
Link to Original Source
This got a lot of publicity but it doesn't really add all that much security. Supposing you choose 4 words from a dictionary of 200k (roughly the order of magnitude of the OED), you arrive at about 70 bits of entropy. Conversely, choosing a 10-character password from a 62 letter alphabet (a-zA-Z0-9) yields 59 bits of entropy- the difference is only a factor of 1024. Attackers aren't so dumb as to just try choosing random characters- they have very good priors on how common any particular character sequence is in the typical password and will mix and match entire words, with or without leetspeak substitutions, etc.
Of course no matter how rigorous your policy, it all goes out the window once your users type the same password into some other random site.
Complexity matters mainly if your attacker gains offline access to your hashes. Far and away the main source of password compromise is non-uniqueness (using the same password elsewhere). This is actually the main benefit of forcing a periodic password change. Graphical and gesture passwords are horribly insecure from shoulder surfers.
If you can, support as many factors as possible. Multiple factors gives your users flexibility- they may not always be able to receive an SMS or have a card reader handy. TPM-based virtual smart cards are super handy for remote auth from a domain-joined device- no cards or readers required.
Can't believe that to be the case, because that would mean the people in charge of Tesla's Marketing Department are complete morons - never has a new car salesman tried to "steer" a potential sale to their competitors.
Remember - most dealerships sell multiple makes. If one of their makes gives the dealership more kickback - the dealership pushes that make. Also, dealerships sell many models. They push the models they want - instead of simply answering questions, informing the consumer, and helping the consumer into an appropriate configuration. Finally - dealerships make a ton of money on "add ons". If a particular model has fewer available after sale add ons available - a dealership will avoid that model. This is all before considering the profits they make on service. Can't sell oil changes to Tesla buyers - so let's push the BMW or Porsche instead... Look. Tactics like these laws are simply fear. Dealerships suck. Everyone knows they suck. The only people I know who defend dealerships are people who work there.
Don't apply for a dev job. Assuming there was sufficient math in your PhD apply for a data science or data analyst role, which will include a fair share of programming but also mentally engaging work. Hiring managers for these roles look for people that have strong analytical skills and the ability to learn new things (proof: you have a PhD). What languages you know is secondary in these roles to how well you dig in to a problem and deliver insights.
Gotchas more than quirks:
- the day you realize you put a side effect in an assert() call.
- the day you realize GCC, maybe it was V2, not sure this is still an issue, exploits extra bits of precision in the Intel FPU, *only if* optimizations are enabled, which causes certain iterative floating point algorithms (eg SVD) to fail to converge.
In both cases everything works great in debug builds but goes to hell in release builds and it's incredibly painful to get to root cause.
for sure the first site I'd attack is obscure registrar namecheap...