ajoberstar

It's not even the same ballpark.

Definitely. Should have phrased it as "cant's see it's that reasonable a use of time _for most people_".

I was on my 3rd Synology over the last 12 years or so. They were solid and something I didn't have to pay attention to.

But the drive lock-in tipped me over the edge when I needed to expand space. I'm getting burned out with all of these corporate products gradually taking away your control (Synology, Sonos, Harmony, etc.).

Even though it takes more time and attention, I ended up building my own NAS with ZFS on Debian using the old desktops I use for VMs. I did enjoy the learning experience, but I can't see it's that reasonable a use of time.

It doesn't seem like you're talking about the same thing the article is. Graham doesn't say "you must be a good writer to be a good thinker".

> This is only true of writing that's used to develop ideas, though. It doesn't apply when you have ideas in some other way and then write about them afterward — for example, if you build something, or conduct an experiment, and then write a paper about it. In such cases the ideas often live more in the work than the writing, so the writing can be bad even though the ideas are good.

Writers who have trouble expressing thoughts in a non-native language are not actually developing the idea in that language. That doesn't mean they are producing bad ideas, but it _might_ mean they won't produce good writing (in that non-native language).

I took the essay to be highlighting that if you use writing as a tool for thinking, clunky writing is likely to highlight places where your ideas themselves aren't clear or correct yet. The iterative process of refining the writing to "sound good" will help shape the ideas.

This seems to be a commonly expressed idea in other forms. For example, when thinking through ideas in code, the process of making the code more "beautiful" can also result in a clearer expression of more correct ideas.

Nest thermostats have a heat and cool mode where you have setpoints for each. On older ones there was a limit on how close the two could be set.

That's not what happened. Downstream was building from source, that source just had malicious code in it.

One part was binary, the test file (pretty common), but checked into the repo. One part was in the build config/script, but was in the source tarball and not in the repo.

Git would make you merge or rebase, but yes there wouldn't be a conflict. They're saying Pijul would let you directly push without having to deal with the diverging histories.

As with other versions of Datomic, this is not open source (only binaries are Apache licensed).

EDIT: Rephrased to sound less snarky. Not inherently a bad thing, but it's a limiting factor for many, including myself.

EDIT 2: Typo

VS Code brought Language Server Protocol, so I don't think the "vision" balance is as one-sided as you imply.

I believe it's because it's from The World Ahead issue, which iirc always has bylines unlike the normal weekly paper.

I personally haven't had a reason to use Oracle's because I like having the latest version and any actively maintained LTS versions available for development and would prefer to use one vendor for all of them. Eclipse Temurin and Azul Zulu are the two I've personally used, but I'm not aware of any technical differences. They should all work the same since they're built from the same code.

Most of the big vendors are running the TCK tests to certify compatibility as well.