Would you please stop posting unsubstantive comments here? You've done this a fair bit, and it degrades the quality of the site—both itself and by encouraging others to do the same.
I'm sure you wouldn't litter in a city park. HN is also a park of sorts, so if you'd treat it with the same respect, we'd appreciate it.
The word is 'unsubstantive' and we use it to mean empty comments that lower the signal/noise ratio here. The idea on HN is if you have a substantive point, to make it thoughtfully; and if not, then simply to not comment until you do.
Why are you running data if you don't suspect a crime?
A friend of mine moved to a new neighborhood. Apparently, her neighbor was in the police. She said she was out walking her dog and the neighbor greeted her with her first name and middle name when she had barely moved in. We didn't know her legal middle name was different from what we called her. So we pretty much know he looked her up (driving licence info?) and he wants her to know he looked her up.
Illicit querying of NCIC should be a crime in and of itself that officers and anyone else with access (admin personnel & some security guards) are commonly prosecuted for.
We should have a right to security in our information, and privacy of it from meddlers and nefarious actors like the aformentioned neighbor. Sadly, many of my fellow Americans are all to happy to claim they have nothing to hide, despite how much that attitude continues to hurt them.
I'm not disagreeing with this, but I don't think we can trust people to make a system that, e.g., automatically collects and stores the locations of all cars with plates visible to all the roving police cars -- and then not use that information improperly.
I'm hoping that we'll gradually choose deliberate ignorance of certain things we could know because although the knowledge could be helpful in certain cases, it's also too dangerous.
It matters because to make the inference that he was connected to the police and misused police resources to find her information, that information has to not be readily available to the general public.
If she had been an owner, the information would be available to the public, and not even all that odd for a neighbor to look up (I look up sales records for houses that sell in my neighborhood to see what they sold for, for example, to get an idea of how the market is).
You’re making a bunch of leaps in logic here. How do you know he is law enforcement? Also, you said she just moved, so how does her license have her new address? So how exactly did he identify her to look her up?
Maybe he just saw a piece of her mail.
Edit: also, the most obvious question: why didn’t she do the normal thing and ask “hey, how do you know my name?”
* The implementation of cryptographic "signing" (really, virtually never signing but rather message authentication) is susceptible to implementation errors.
* The concept of signing is susceptible to an entire class of implementation errors falling under the category of "quoting and canonicalization". See: basically every well-known implementation of "signed URLs" for examples.
* Signed URLs have to make their own special arrangements for expiration and replay protection in ways that stateful authentication doesn't, either because the stateful implementation is trivial or because stateful auth "can't" do the things stateful auth can (like explicitly handing off a URL to a third party for delegated execution).
Stateless authentication is almost never a better idea than stateful authentication. In the real world, most important APIs are statefully authenticated. This is true even in a lot of cases where those APIs (inexplicably) use JWTs, as you discover when you get contracted to look at the source code.
Delegated authentication is useful situationally. But really, there aren't all that many situations where it's needed. It's categorically not useful as a default; it's a terrible, dangerous default.
Every time I read a API that uses signed/authenticated requests (AWS, Let's Encrypt ACME) I wonder exactly the same thing - why is this needed in the first place? If TLS guarantees lack of replays it seems to me like signed requests just protect their own complex infrastructure from reusing the same request twice...
I'm explaining where I'm coming from as a courtesy. I am also comfortable with the number and kind of HN readers who would simply take my argument as-stated without justification: "don't do signed URLs if you can get away with bearer tokens".
So really what everyone should do are PAKE schemes based on isogenies, because then we're all post-quantum secure, and, after all, it's only insecure if you do it wrong.
Generally speaking, when you sue someone, it's often in your best interests to give them an opportunity to settle, instead of going to trial. You often do this by listing all the awful shit about the other person that you're going to air at trial. We don't call that a 'Legal way to blackmail,' and neither is this.
> We don't call that a 'Legal way to blackmail,' and neither is this
I mean, if we're just going by Wikipedia, my non-lawyerly brain would parse this:
> It is coercion involving threats to reveal substantially true [...] information about a person to the public, a family member, or associates, or threats of [...] criminal prosecution.
as being precisely what's happening here. Breadcrumbs were thrown out in public with an implication to settle in order to avoid more getting out.
That sounds like "legal blackmail" to most laypeople.
Again, how is this different from a threat to sue? Should out-of-court civil settlements be made illegal? All of them are coercive in nature, and a lawsuit almost always results in a lot of dirty laundry being aired. Does this make every settled lawsuit 'legal blackmail'? If so, does the word even have any meaning?
“Scaled across Titan’s 18,688 Tesla GPUs, ”. I am sure that’s all Nvidia really cared about, they’d write anything that made their customers look smart.
Software engineering does not consist of preparing for and then giving short/intense performances.
Plenty of fields do - performing arts, film, trading, etc. all involve some form of short, intense, expensive activity to which you show up prepared and work in a burst of superhuman activity. But software isn’t like that at all - you get a problem and you dig into it, mull it over, research, etc. at your leisure until it’s done. We’re novelists, not actors.
This is true if you have very junior level responsibility, but as soon as you need to take any kind of leadership role others will be looking to you to contribute in a manner that is not ad hoc.
Also, you mention research. Research and preparation are synonymous.
Nope, not even slightly. Research is something you do after you know the problem at hand, to see if you find anything helpful. Preparation is something you do before you know the problem to minimize reaction time once the problem is revealed. Preparation is wildly inefficient, as it involves studying a bunch of material that will not turn out to be needed, just in case.
If you're writing software under the kind of time pressure where consulting reference material is unacceptable, something is deeply wrong. Most software engineers, most of the time, should be able to research topics as they come up rather than prepare (beyond the standard preparation in college).
Making long-term plans, building consensus around them, etc. is important, but is nothing like practicing for whiteboard interviews.
So wrong in so many different ways. The questions you research / prep for may be needed at some point in your career.
Much like programming. You program for all relevant edge cases, as one might be used at some point.
People who don’t prep are horribly lazy and are terrible at enumerating edge cases. The have buggy code that fails at some point. Laziness is by far the way worse quality? Though not the only sin.
Lack of sincere desire to be helping the team succeed and no innate talent are bad too.
>The questions you research / prep for may be needed at some point in your career.
And most people, most of the time, can and should research them as needed.
>You program for all relevant edge cases, as one might be used at some point.
Yes, because a program doesn't get to pause execution and defer to the human mind to ask "hmm, what do I do in this case?" A programmer does so all day every day.
>are terrible at enumerating edge cases
Any attempt to pre-compute the edge cases of all possible programming situations will be hopelessly inadequate. Enumerating edge cases requires analytical thinking in the moment, essentially the opposite of preparation.
This is wrong. If I want to handle a problem by researching it, I have a goal in mind ("solve problem X"), and I'll look for things that will help with it.
Interview preparation specifically avoids that approach. Instead, you're supposed to become familiar with every possible problem, in case it comes up during the interview. Most of them, obviously, won't, and from a "research" perspective that means that nearly 100% of the time you spent in preparation was wasted.
One more thing is that, research takes time. Companies want ability to cut short this time which is required from inception to delivery of a product. They prefer a candidate who already has prepared linear algebra, if you are going to work on deep learning at the company.
Like every other field, you need to practice and you need experience to do well. Maybe you can dive into a new framework without trying out any tutorials, but not everyone.
Sure. But at work, I know what I need to prepare for. Interviews don't exactly give you the questions ahead of time allowing you to prepare. So, preparation is not something they are testing for.
The idea of screening for a software engineering gene is patently absurd. In an ideal scenario, we screen for the ability to do the work the job requires. In the normal scenario, we screen for some mix of that and the ability to apply cookie-cutter techniques to (hopefully) novel problems in the space of ~45 minutes. Some companies also ask you to do a sample practical problem either on site or on your own time. None of this indicates anything about someone's "innate genetic talent", if there is any such thing.
And it’s illegal to try and screen on anything except ability to do the job. Be very careful if you find yourself thinking in terms of software engineering interviews being a general intelligence test — you are setting yourself up for a discrimination suit.
As you clearly demonstrate, intelligence has a genetic basis. However, it does not follow that there is variation among humans at the relevant genetic loci. The variation may have become fixed in an ancestral population of modern humans.
What I gave there is an absolutely standard assessment of the situation from the point of view of population genetics. Of course intelligence "is genetic" in some sense: that's why dogs and cucumbers are less intelligent than humans for most definitions of "intelligent". The question is about the phenotypic significance of current intraspecific genetic variation.
Most of these things have long since been disrupted:
Making meals :- go to a cafe, been around for centuries, uber eats etc. Worst case, get frozen meals (some are really good) and bung them in the microwave.
Driving Kids :- Taxi, bus, chauffeur, again have been around for ages, auto drive cars are not that far away, but will you be willing to abandon your kids to the machine?
Grocery and other shopping:- Amazon, online shopping.
Picking up:- If you can't manage to put things away yourself, then get a maid or cleaner.
As somebody else posted, most of these automated devices don't seem to have got much further than they were in the tech shows of the late 70's, they just have more "AI" built in the seem to be designed to make you purchase from their vendor.
> Driving Kids :- Taxi, bus, chauffeur, again have been around for ages, auto drive cars are not that far away, but will you be willing to abandon your kids to the machine?
There is one exception - the robo-vacuum. It's good enough today to run 99% unattended (you still have to empty the dust bin by hand and clean hairs from its wheels). It does a more thorough job than a human already.
We've had a Rumba for some time. In the early days it was used regularly, now almost never. I don't know why, but I find that 5 minutes with a manual vacuum achieves a far better result than watching the Rumba bash it's way around the room for 30 minutes or more.
I’ve found the wireless vacuum (eg Dyson) to be even better: you just pull it out, vacuum, put it back. It’s more powerful than a robovac and, without cord fussing, incredibly low overhead.
