Coq/Lean target very different use cases.

The implementation is great, since it doesn't add fix up profile on top factory calibration, but actually fully replaces factory calibration internal LUT. It worked wonders to completely fix my M1 MBP screen that got noticeably tinted over time. I don't mind brightness reduction since I almost never use it at more than 200 nits, usually around 100. Nominal 1600 leaves lots of buffer for decay over time.

I've had similar issue my OLED TV with the same fix. Got my LG C1 calibrated as well and it looks fantastic again.

It's a shame there are no iOS or Android phones that support calibration out of the box. Some iPads support subset of pro display calibration software (called fine tune calibration), but still lack full recalibration support.

I find it very surprising that nobody tried to make something like gRPC as an interop story for a new language, with an easy way to write impure "extensions" in other languages and let your pure/formal/dependently typed language implement the rest purely through immutable message passing over gRPC boundary. Want file i/o? Implement gRPC endpoint in Go, and let your language send read/write messages to it without having to deal with antiquated and memory unsafe Posix layer.

Something one doesn't see in news headlines. Happy to see this comment.

I usually google where a particular setting is now since I don't use the exact same words and the settings search is very literal.

If the hypothesis is correct, it sets an incredibly high bar for starting a new programming language today. Not only does one need to develop compiler, runtime, libraries, and IDE support (which is a tall order by itself), but one must also provide enough data for LLMs to be trained on, or even provide a custom fine-tuned snapshot of one of the open models for the new language.

There are two variations of the B permit one can get. An unrestricted B permit isn't tied to a specific employer and provides a path toward permanent residence (C permit) within five years for EU citizens or ten years for non-EU citizens. Based on my experience, EU citizens almost always get an unrestricted permit and are treated relatively well by the immigration process: at their first application, they receive a five-year B permit, and at the first renewal five years later, they automatically get a C permit. As a EU citizen you just need to find a job, and your right to work is essentially unrestricted.

The non-EU path is quite different. A non-EU citizen only gets an unrestricted B permit if they prove they have special skills that are not currently available on the local job market. There is a yearly quota for such permits. One can also be unlucky and get an L permit, which is for temporary work only. Moreover, restricted B requires yearly renewal with a demonstration of ongoing employment at each renewal.

If you get a restricted B permit (or L), you don't have any direct path to a C permit, no matter how many years you've lived in Switzerland. You can complete your bachelor's, master's, and PhD degrees and continue working for a university as a contractor afterward, and still not be eligible for the path toward a C permit after over a decade of living in the country. To get a C permit, the last two years prior to the application must have been on an unrestricted B permit, working a full-time, unlimited-term job contract. The change to an unrestricted B permit requires you to have become a "special talent" during those prior years; otherwise, it won't be granted.

And suddenly you can start playing with distributed software, even though it's running on a single machine. For resiliency tests you can unplug one machine at a time with a single click. It will annihilate a Pi cluster in Perf/W as well, and you don't have to assemble a complex web of components to make it work. Just a single CPU, motherboard, m.2 SSD, and two sticks of RAM.

Naturally, using a high core count machine without virtualization will get you best overall Perf/W in most benchmarks. What's also important but often not highlighted in benchmarks in Idle W if you'd like to keep your cluster running, and only use it occasionally.

- Don't try to provide backwards compatible subset of JVM APIs. While this might seem tempting to support very important library X with just a bit of work, I'd rather see new APIs that are only possible with your language / runtime. Otherwise you might end up stuck in never-ending stream of requests to add one more JVM feature to get yet another library from the original JVM language running. Focus on providing your own unique APIs or bindings to native projects that might not be easy to do elsewhere.

- Don't implement your own GC, just use mmtk [1]. It takes a really long time to implement something competitive, and mmtk already has an extensible and pluggable GC design that gets some of the best performance available today [2] without much effort on your end.

- Don't underestimate complexity and importance of multi-threading and concurrency. Try to think of supporting some form of it early or you might get stuck single threaded world forever (see CPython). Maybe you don't do shared memory multi threading and then it could be quite easy to implement (as in erlang). No shared memory also means no shared heap, which makes GCs's life much easier.

- Don't spend too much time benchmarking and optimizing single threaded performance against JVM as performance baseline. If you don't have a compelling use case (usually due to unique libraries), the performance might not matter enough for users to migrate to your language. When you do optimize, I'd rather see fast startup, interactive environment (think V8), over slow startup but eventually efficient after super long warmup (like jvm).

I see that jank is already doing at least some of the things right based on the docs, so this message might be more of a dump of mistakes I've done previously in this space.

[1]: https://github.com/mmtk/mmtk-core

[2]: https://dl.acm.org/doi/pdf/10.1145/3519939.3523440