> 10. The FOSS axiom "More Eyes On The Code" works, but only if the "eyes" are educated.
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?".
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? :)
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.
> 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.
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.
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).
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.
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.
Hi, I'm the author. Thanks for taking a look. This is basically a tool to help manage a "Dockerfile" repo (along the lines of https://github.com/jessfraz/dockerfiles), where you build any tools you want into images that you control. This can be really useful for personal use or within a company.
Why build tools into Docker images? Love it or hate it, there are many senses in which Docker is currently the best medium that we have for distributing and running dev tools. Here's an article making that argument: https://jonathan.bergknoff.com/journal/run-more-stuff-in-doc....
On the contrary: Docker is currently the best way, bar none, of distributing tools like this one to developers. Kudos to the Super Linter developers for doing this right.
Indeed. I went through it all about three years ago and learned a ton (starting from essentially "I have a table saw but I don't know what the miter slots are for").
Many great examples here, and my wife and I do many of the same things, but it's not always this easy. If your child is receptive to these things, like the children in the article, that's great. Our younger one is receptive and our older one is getting there as he ages. If we judged ourselves as parents based on just the younger, we'd think we were amazing parents making all the right choices. If we judged ourselves just on the older, we'd think we were completely ineffective at, e.g., fostering independence.
I just hope nobody's reading this and feeling bad about their parenting. The personality of the child is critical.
In other words, it becomes the concern of the person shipping the code, rather than the concern of the person trying to run the code. That's exactly how it should be.
I have a really hard time parsing `unless`. Whenever I encounter it in Ruby or CoffeeScript code, it takes me 10-30 seconds to stop and understand what's happening with the code.
Generally, postfix conditionals are a bad idea because they are garden-path sentences [1] by design.
Glad you find them valuable, but IMO they epitomize what many other comments in this thread have said about CoffeeScript's poor readability.
If I create a file in my project named requests.py, then a sibling file's `import requests` starts importing that file, instead of the library. Maybe name conflicts are "basically fixed" in the sense that there are ways to avoid them, but there is still surprising and magical (in the worse possible sense) behavior to trip over.
> Regarding hyphens and such in package names pretty much every language has restrictions on identifier names.
This particular restriction is an artifact of the bad design of treating paths on disk as special language tokens instead of string literals.
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?".