ajoberstar
ajoberstar on Hacker News
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.
> The problem stems from the fact that Unicode encodes characters rather than "glyphs," which are the visual representations of the characters. There are four basic traditions for East Asian character shapes: traditional Chinese, simplified Chinese, Japanese, and Korean. While the Han root character may be the same for CJK languages, the glyphs in common use for the same characters may not be. For example, the traditional Chinese glyph for "grass" uses four strokes for the "grass" radical [⺿], whereas the simplified Chinese, Japanese, and Korean glyphs [⺾] use three. But there is only one Unicode point for the grass character (U+8349) [草] regardless of writing system. Another example is the ideograph for "one," which is different in Chinese, Japanese, and Korean. Many people think that the three versions should be encoded differently.
https://en.m.wikipedia.org/wiki/Han_unification
Seems like Wikipedia has a good overview of the issue.
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.
TL;DR still not open source (only binaries are Apache licensed).
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.
You can get a paid commercial support license for Oracle's JDK to get an extended maintenance window. But Oracle's publicly available builds don't require a paid license. However,they only provide public builds of the current Java version. If you want LTS, you have to pay them or use another vendors builds.
Oracle's builds of Java are open source as well. The OpenJDK codebase is shared across all of the vendors that provide builds.