justinlardinois

> When several Samsung Galaxy Note 7 smartphones spontaneously exploded in August, the South Korean company went into overdrive. It urged hundreds of employees to quickly diagnose the problem.

> None were able to get a phone to explode.

What exactly does that process look like? I'm imagining a bunch of QA techs in a warehouse hoping for failure.

I'm not sure how that would help the problem. When you're talking about thousands or more devices, counterattacking them individually wouldn't be feasible.

Also I imagine many botnet owners secure the devices they take over so that others can't steal them for their own botnet.

Don't remind me; yesterday's discussion[0] about dooring was among the biggest shitshows I've seen on Hacker News. There's something Godwin-esque about online discussions concerning the relationship between cars and bicycles.

[0] https://news.ycombinator.com/item?id=12674533

Laws and courts will of course vary throughout the world, but my understanding is that you're generally not responsible for getting hit from behind, unless you're reversing or something, so I'm not sure why this is any more of a problem for self-driving cars.

Unless of course the car behind you is also self-driving. But then we've really just recursed.

This. The reality is that no one will buy a self driving car that leans towards killing them over pedestrians.

> Is "productivity" really the only measure of job satisfaction?

Productivity is a side effect of good employees working in a good environment. Programmers aren't satisfied because they're productive; they're productive because they're satisfied.

Not an unreasonable question.

http://www.bloomberg.com/news/articles/2013-02-28/silicon-va...

My first exposure to anything programming related was some web publishing courses I took at a community college when I was a teenager. The classes were intended for people with a graphic design, rather than developer bent, so the classes were mostly focused on HTML, CSS, and web design-relevant Photoshop tricks.

I credit those classes with sparking my interest in programming, but they didn't actually cover it to any extent. Instead there was this attitude that you could just find a Javascript file or Perl CGI script that would do what you need, and when necessary you could shoehorn it in, despite having little to no understanding of the involved programming languages. GitHub didn't exist yet, so there wasn't a centralized, trustworthy source of free Javascript modules; instead you had to find them on sketchy ad-riddled sites and hope they did what they said they did. I remember there were even sites that would sell scripts, a concept that feels totally alien to me now in 2016.

tl;dr Invented here syndrome is a big thing for web designers who aren't developers

Being asked to demonstrate knowledge of common algorithms is "hazing"?

This is in part because much of the US is almost impossible to get around without a car.

In my line of work I often end up working with queries where you'll have a handful of JOINs and need to SELECT a dozen or more columns. In those cases writing out staff.foo or students.bar gets old really fast.

I agree that s1 and s2 are bad though, as I said in another comment.

> If there is already a correlation with the same name then append a number.

And then applies it for this query:

  SELECT first_name AS fn
    FROM staff AS s1
    JOIN students AS s2
      ON s2.mentor_id = s1.staff_num;

I think that's terrible. s1 and s2 sound to me like they're instances of the same table that you had to JOIN with itself for some reason.

While silent truncation is of course bad because it limits the potential entropy of a password, if implemented consistently it's technically not any worse than a limit that's presented to the user. But just wait until the new hire doesn't know about it and implements a form without it, and then all of the sudden users are entering the same "long" passwords they always have and scratching their heads when it fails.

Do you have a link to any reading about this? I'm curious.

Can't tell if this is snark or just really bad advice.

I was talking about maximum password lengths, not minimums.

33 characters (and I often see less) is a far cry from a gigabyte. I think it's clear I was talking about unreasonably low limits.

To be honest vi and vim are different enough that as someone who was taught on vim, I get lost when I have to do anything beyond opening a file in vi.

Yes.

Am I missing something here? That's like an asthma drug whose side effect is shortness of breath.

I think his point was that if your password is stored on your phone, two factor authentication doesn't actually add any security because it's no longer two factor.

As in using PGP or something?

Why would you assume that? A site's password requirements are public information, so you should expect an attacker to read them.

If I recall correctly, Medium uses this login method.

There are a lot of smartphone apps that almost never log you out and would benefit from this. I recently had some trouble trying to remember how to log into the Taco Bell app after a session that lasted ~2 years. And I've lost count of how many friends have been unable to remember their Snapchat password and just creating a new account instead when they get a new phone.

> Length between 7 and 33 characters

I've never understood why sites limit password length. You're (hopefully) hashing it anyways; the length of what the user enters has no bearing on what you're storing in your database.

Isn't that on Spotify and Google to implement?

That's not the point. Default is king.

Might be worth reading: https://news.ycombinator.com/item?id=12626314

The word "most" gets thrown around a lot in political arguments. Do you have some insight into what the majority of people believe that we don't?

After reading up on C99 I take back what I said. I definitely thought some of those features were older than they are.