Eh.

For a hobbyist it's pretty neat. I don't expect to be extracting a lot of value from hobbyist PCB designs.

That some PCB manufacturer is willing to do a small batch of my PCB design & I don't have to pay for it, just give them a shout out & write about it, that seems pretty neat.

I've never seen it used to mean "preinstalled on most systems". Although e.g. people like vi keybindings because vi is preinstalled on most systems.

Either way, I think you can argue for workstations, it's worth configuring software to your liking, and worth installing software that helps you be productive.

Though, the only software I've seen people excuse for having 'bad defaults' have been things like vim, emacs, tmux.

Anyway.

Do people get the impression that LLMs are worse at frontend than not? I'd think it's same with other LLM uses: you benefit from having a good understanding of what you're trying to do; and it's probably decent for making a prototype quickly.

I get the impression languages like k are a good example of this. (That C code looks as dense/concise as k).

I could read that as: wanting to do something interesting that others would benefit from.

Though, I don't really think that's a good reason to filter out things to be enthusiastic about.

Flakes do 2 things:

1. Declaration of the inputs and outputs of some Nix codebase. 2. Pinning the versions of this input sources.

The dependency pinning is similar to package.json/package.lock etc. which are common in language-specific package managers.

Using Nix for per-project development dependencies is quite good. It's nice to be able to return to a project & not have to fuss over which tools/libraries need to be installed.

My experience using NixOS on desktop is that it's 95% wonderful, 5% very painful.

If you run into friction with NixOS, you may need to have a wider/deeper understanding of what you're trying to do, compared to the more typical Linux OSs which can be beaten into shape.

With NixOS, you pay all the complexity up front.

Modules let you express the system in smaller, composable, reusable parts rather than express everything in one big file. (There are other popular tools which support modules: NixOS, home-manager, flake-parts).

That devenv also provides "batteries included" modules for popular languages (including linters, LSPs) is also a benefit.

As the author points out, that Emacs is a highly extensible 'operating system' which makes it relatively easy to bring different tasks together. -- This ought to be a natural parallel to what the agentic tools are trying to do (use MCPs and skills etc. to bring different functionality to the LLM execution environment).

That LLMs can help users extend emacs ought to lower the difficulty curve.

Still. It's silly to wish that Emacs could be the LLM's best friend, rather than demonstrating how it is.

RE: "what if in the future all coding skills are irrelevant". My experience has been that good results from LLMs come from putting good thought into its usage. They're quite far from a magic "push the button and get the result you want" where the skill doesn't matter.

With magit, the routine git tasks are very fast & flowing, git becomes highly discoverable, and complex tasks are made easy.

For example of things that are tedious on the CLI: magit makes it easy to make "--fixup" commits (since you can select the commit you intend to fix up). Or if you want to use something like git-absorb, that's also easy in magit.

Or magit makes it easy to stage/unstage line by line.

Emacs is highly customisable. There's not really a hard difference between "configuration" and "extension". Whereas with e.g. VSCode, very few people would write their own extensions. -- So it's a good point that with LLMs, the barrier to customise Emacs to exactly how you want it is even lower.

I'd also argue that since practically everything in Emacs is text (as opposed to a rich GUI interface), Emacs itself ought to make for a nice interface to LLM functionality.

Laptop keyboards will always be disliked by someone: the standard keyboard layout is awful, and dealing with this either involves trying to stick to the conventional design (wherein different people will dislike different changes); whereas a good keyboard design is going to be so far from the standard keyboard that laptops aren't going to do that.

(People will quibble about where to put the arrow keys or however many modifier keys there are or that caps lock is badly placed.. but the most glaring issue is that the spacebar doesn't need to be over 6x the size of other keys).

It's a problem if the OS is inconsistent/unclear about what scan codes are required to do things.

The impression I get of WCH and their CH32 line is it ... draws heavy inspiration from STM32.

WCH provide English translated datasheets and reference manuals. They're fine.

Their own recommended toolchain is a fork of GCC. But as far as I can tell, they haven't shared their changes anywhere. The specifics of the changes they've made are a bit beyond my understanding, though.

With the open source distributions of GCC toolchains work just fine. I've built Rust crates as firmware libraries for them.

That the CH32X035 is very simple to design for (& low cost) means I'd rather make use of it for hobbyist keyboard PCB designs compared to the RP2040.

e.g. By using a cryptography library / algorithm someone else has written, I don't need to think about it (although someone has done the thinking, I hope!). Or by using a high level language, I don't need to think about how to write assembly / machine code.

Or with a tool like a spell-checker: since it checks the document, you don't have to worry about spelling mistakes.

What upsets is the imbalance between "tasks which previously required some thought/effort can now be done effortlessly". -- Stuff like "write out a document" used to signal effort had been put into it.

For sufficiently complex manipulations, I find the "selection-action" ("motion-action") to be more intuitive than "action-motion". Even with vim, I'd often like making use of visual mode.

I think the main limitation to this that I believe is it's probably a bit slower for quick + frequent edits compared to vim.

I see the "Why Ki?", and then it has this:

> Being first-class means that it is not an extra or even sidekick; it is the protagonist.

Eh.

I find it quite off putting.

I guess my expectation is that someone enthusiastic enough to write a text editor with a value proposition of "it's got good tree-sitter-based navigation" would want to discuss why they thing syntactic selection is neat.

Seeing cliche LLMisms doesn't signal the same level of care to me.

I think you'll have to be more specific.

Or I guess to compare with your other observation: """Even with all this protection, Iran [sent] enough ballistic missiles to overwhelm the defences""" -- It's not a binary of "have missile defense or not => every missile will be shot down". An amount of missile defense will make it harder for missiles to successfully hit a target.

Similarly with hypersonic missiles, it's not the binary of "I have a missile that's difficult to defend against, I win".

Having a sword which can defeat a shield isn't in itself sufficient to obsolete the shield. (Infantry can be killed with bullets, yet infantry remain an important part of fighting despite that).

To my understanding, the main difference between "curl directly to bash" and "curl to a temp file, then execute the temp file" is "the attacker could inject additional malicious commands when curl'd directly to bash".

If you're not going to then also read all the source code from the download script (& the source code used to produce the binaries), this suggests the attitude of "I mistrust anything I can't read; but will trust anything I could read (without having to read it)".

It seems more likely that malicious code would be in a precompiled binary, compared to malicious commands injected into "curl to bash". -- Though, if there have ever been any observed cases of a server injecting commands from "curl ... | tee foo | bash", I'd be curious to know about these.