jbergknoff

> 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?".

Yeah, I found it very interesting how McCullough (Masters of Rome) idolizes Caesar and holds Cicero in contempt, and Harris is exactly the opposite.

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.

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

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'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.

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.

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...

Thanks for that feedback! I'll update the readme.

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....

Yeah, I'm seeing the same. The branch reflects the new commit, but the PR open for that branch does not show it.

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.

I wrote an article a while ago arguing this point: https://jonathan.bergknoff.com/journal/run-more-stuff-in-doc...

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").

For people interested in this stuff who haven't seen Next Level Carpentry, I highly recommend it: https://www.youtube.com/channel/UCXRNHTVpEdhz9BIvomETGiQ.

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.

> https://covid19.healthdata.org/united-states-of-america/texa...

Am I missing something? It doesn't look like this has any data on hospitalizations. The graphs are all based on "projected" data.

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.

[1] https://en.wikipedia.org/wiki/Garden-path_sentence

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.

This is amazing! I'd be interested in more details about capturing the IR signal, both by the invasive method and the "operate an LED in reverse" method.

At one point I thought about trying to do something similar with my old garage door opener, but ended up not pursuing it.

I think anything that treats paths on disks/library names as string literals would be workable. So, for instance, the stuff from the importlib standard library would probably be good enough if it was a top level/global construct that worked with quoted strings.

> from './app/utils.py' import numbers

> One of my favorite Python features is the way that the files and directories your application is made of map one-to-one with how you import and use them in code.

Funny to see this stated explicitly in this way. In my opinion, this is one of Python's biggest flaws (I'm a big fan of everything but the module system). Paths to files on disk should be treated as string literals, not magic unquoted strings that look like they're language keywords.

You can easily end up in situations where a directory in your project's tree has a name conflict with some library, and this causes issues, which is mind-bogglingly bad design (incidentally: also not a one-to-one map). If you don't live and breathe Python, and accidentally put a hyphen in a filename, God help you.