jjnoakes

60 ms·

661.
by jjnoakes 9y ago
This only matters if it isn't about the money...
662.
by jjnoakes 9y ago
These days the gcc and clang memory/address sanitizers can do this quite nicely, and they tend to have low overhead as well (in my limited experience so far).
663.
by jjnoakes 9y ago
Have you found decent frontends which let you sync files between Windows, Linux, Mac, Android, and iPhone, using S3 as the backend? If so, I'd love a few pointers, because I've been looking for something like that.
664.
by jjnoakes 9y ago
What's the connection between Flight Sim Labs and Retina-X?
665.
by jjnoakes 9y ago
With the caveat that it's apples-to-oranges (algorithmic changes to the JavaScript version (~4x) are not in the Rust version (~5.9x)).
666.
by jjnoakes 9y ago
> The BSD licence is objectively worse than the BSD+Patent Grant. I'm not a lawyer, but I have heard a few claim the opposite: BSD plus the explicit restricted patent grant was worse than BSD (or MIT) with no explicit patent grant (
667.
by jjnoakes 9y ago
> You can only influence which branch it takes, you can't force it to jump to an arbitrary place. Assuming you've mitigated spectre v2, right? If you are vulnerable to v2, I can take any other indirect branch in your program (w
668.
by jjnoakes 9y ago
Is this true? I'm no spectre expert but I thought that if you could detect cache changes correctly, you could infer the value of memory that you did not have mapped (but the other process did) as long as the other process changes its c
669.
by jjnoakes 9y ago
Is this true though? I'm no spectre expert, but my layman understanding is that since you can poison branch predictors, you can direct the other process to execute a gadget that wouldn't normally be executed. This means you can co
670.
by jjnoakes 9y ago
> Pattern matching is much, much cleaner than a switch with the branches extracted in separate functions I don't think that's what is being suggested. I think the suggestion is to move the entire switch statement to a separate
671.
by jjnoakes 9y ago
Care to point out where you think we're getting our meanings crossed? (In a way that isn't snarky would be nice). And you should also explain why you think my claims of irrelevance are solely based on my whims, when I've prov
672.
by jjnoakes 9y ago
> I also said to use a package manager. Package managers are outside the scope of this discussion though. I agree they are great when they can be used, but for various reasons they can't be used (no root access, the software or the
673.
by jjnoakes 9y ago
> Where the hell do you think I made that claim? Right here: https://news.ycombinator.com/item?id=16144785 You said: "Don't install random binaries either. The security implications of that should be fairly obv
674.
by jjnoakes 9y ago
> Everything about curl | sh is inherently untrustworthy Nope. Only one item is of minor concern (which I've covered many times in this thread) and it has an easy and known solution. The rest of your objections are not specific to
675.
by jjnoakes 9y ago
> Just because you have a URL, doesn't mean it is connecting to the expected IP. Ignoring how weak of an argument that is, I don't see how that is any different of a risk between curl-pipe-to-sh and regular software downloads.
676.
by jjnoakes 9y ago
You didn't answer the 'random ip' question. > Piping curl, means you can't be sure it came from the author's site. Assuming you take the same precautions you'd take with any other software download (like usi
677.
by jjnoakes 9y ago
Why would you be using an IP and not a URL? And why wouldn't you trust the source of the install script as much as any other installer? Do you audit the binary installers you use as well? I don't disagree about a minor difference
678.
by jjnoakes 9y ago
In what way is it more of a risk over downloading and executing an installer from the same site? The only reason I can think of is if the script partially downloads and only half executes. Doesn't seem "massive" though...
679.
by jjnoakes 9y ago
Why would you be using a random ip? That incantation is usually used with a URL where you would have just downloaded and installed the software manually anyway. There are various arguments against the curl-piped-to-shell idiom but "ran
680.
by jjnoakes 9y ago
I only think this applies to certain ecosystems (ones where the motivation or incentive to provide the software doesn't align with ensuring user's safety or security). The native apps I run on my Linux laptop, for example, I trust
681.
by jjnoakes 9y ago
Title is a little clickbaity; these are decent examples for where higher order functions may provide more clarity than for loops, but there are also good examples where for loops provide more clarity than higher order functions. Knowing whe
682.
by jjnoakes 9y ago
He said C11, not C++(11).
683.
by jjnoakes 9y ago
> If you statically link to an LGPL library, then the entire codebase (your code and the library) must be covered under an LGPL compatible license. This isn't right. You can statically link proprietary code to LGPL libraries and the
684.
by jjnoakes 9y ago
He doesn't just have a single drive though, he has (at least) two (the drive in active use and the off-site backup drive). Not the ideal 3-2-1 rule of thumb, but also not a ticking time bomb.
685.
by jjnoakes 9y ago
Because reviewing and being familiar with material is different from knowing it, and even if you know a topic, surely you can learn more.
686.
by jjnoakes 9y ago
Those means different things. Their wording means "we checked X sites and 77% of them met some criteria", which can be extrapolated to higher values of X (assuming the proper statistical care is taken, etc). Your wording implies t
687.
by jjnoakes 9y ago
And then go back in time and call it in the air?
688.
by jjnoakes 9y ago
The risk isn't a function of developer count alone; for example, a simple and polished feature-complete library with one developer is lower risk than a beta version of a huge complex distributed system with 100 developers.
689.
by jjnoakes 9y ago
Comparing passwords to a list of compromised ones doesn't leak anything. Just ignore the user name. And hashing on the client in addition to the server doesn't save you from any mitm attacks.
690.
by jjnoakes 9y ago
> PW + random salt protects you against reused passwords. That only protects you if every other site does it. If you salt your passwords and some other site which doesn't is compromised, you are hosed too if your users reused passwo

More ›