jbergknoff
Joined 12 years ago
Karma
507
Submissions
88
Member since
Oct 20
Recent submissions
Comment · 2 years ago
Comment · 2 years ago
Yeah, I found it very interesting how McCullough (Masters of Rome) idolizes Caesar and holds Cicero in contempt, and Harris is exactly the opposite.
Comment · 3 years ago
AM/PM is bad, but I have a GE microwave which requires you to also set _the date_ when you're setting the clock. How could somebody think that was a good idea? :)
Comment · 3 years ago
Packages had an incident two days ago, also: https://www.githubstatus.com/incidents/sn4m3hkqr4vz. I noticed it when a Terraform provider download was failing, citing a 404 from objects.githubusercontent.com.
Comment · 3 years ago
> The easiest practice to implement for peak Git efficiency is to stick to a subset of commands
This has been my experience as well.
Great article, thanks! I've been using essentially this same subset of commands for many years, and it's worked extremely well for me: does everything I need/my team needs, and avoids complication. I'm glad to have this as a reference I can point people to when they ask for git advice.
Comment · 4 years ago
Yes, there are threshold cryptography schemes with "distributed key generation" [1] in which the parties end up holding shares but the full secret is never known to any party. Then, to your point about "the only time they key was known was when the parties reached quorum after the fact": in these schemes, some threshold of the parties can cooperate to compute a function of the secret (e.g. a signature, or a ciphertext) without any of them ever knowing the secret.
FROST is one example of such a threshold scheme, for computing Schnorr signatures: https://eprint.iacr.org/2020/852.pdf
[1] https://en.wikipedia.org/wiki/Distributed_key_generation
Comment · 4 years ago
If I've already reviewed a PR and the author makes further changes, I definitely prefer to review an add-on commit. If the history is rewritten/rebased, then IME the entire PR needs to be re-reviewed from scratch. If we're talking about a <10 line change, then, by all means, rebase to your heart's content. With anything more complicated than that, rebasing a branch that's already been looked at can be disruptive and I'd strongly recommend against it (though squash-and-merge after review is fantastic).
Comment · 5 years ago
I'm a big fan of using containers to distribute and run tools. It's an underappreciated use case. I wrote about its benefits (and drawbacks) a few months ago: https://jonathan.bergknoff.com/journal/run-more-stuff-in-doc....
Subuser looks interesting, nice work! I love to see progress in this space.
Comment · 5 years ago
I recently got an external monitor for my work Macbook. I plugged it in and soon found out that closing the laptop doesn't put it to sleep anymore. I can kind of see why somebody would want this behavior in some situations. I can't at all see why this would be the default, or why there would be no way to toggle the behavior.
> I continue to be disappointed with Apple's desktop experience.
Same here.
Comment · 6 years ago
Great work on the book, and thank you for writing about the self-publishing process [1]. I'm in the process of writing a book, and your writing has addressed several things that have been on my mind.
[1] Especially https://www.jeffgeerling.com/blog/2016/self-publish-dont-wri...
Comment · 6 years ago
Thanks for that feedback! I'll update the readme.
One thing that could help with this is if somebody points an LLM at all these foundational repositories, prompted with "does this code change introduce any security issues?".