I work at a Linux-dominant shop. Macs are somewhat common. People with Windows are kind of seen as weirdos.

We don’t use office packages all that much either; more geared towards markdown and git and programming languages. The office package I use the most is Google’s.

I haven’t had a machine with windows on it since Windows ME. I do have some training in windows server from over a decade ago (nearing two maybe?), but I’ve never used the knowledge.

Let’s just say that ME deserved its “Mistake Edition” moniker

Yeah, Ubuntu actually isn’t the first distro without GNU coreutils. Beyond Android and Busybox, there’s also stuff like Talos, which is something like … Kubernetes/Linux.

IME something like Kubernetes/Linux running “distroless” containers have a huge potential to displace traditional GNU/Linux in the server market, and I wouldn’t be surprised if someone manages to build a desktop out of it, either.

Also doesn’t help that the grammar reeks of LLM.

Hrm, the pre-commit issue is still open.

Like the others in that thread, I’m not married to pre-commit or the check happening before the commit as opposed to the push, I just want to have some easy-to-setup, standardized way of preventing myself from pushing stuff that will be rejected by CI.

One more puzzle piece here is that du won’t report on files that have been marked for deletion but are still held on to by some process. There’s an lsof incantation to list those, but I can’t recall it off the top of my head.

It used to be part of sysadmin work to detect the processes that held on to large files if df reports that you’re running out of space, and restart them to make them let go of the file. But I haven’t done that in ages. And if you restarted the host OS that should have taken care of that.

I assume you also know how to prune container resources.

fwiw if you do a cargo build you should be able to see the error messages in the correct context. If I replicate line 25 in a little test project and run cargo build I get

error: expected one of `.`, `;`, `?`, `else`, or an operator, found `{`
 --> src/main.rs:4:43
  |
4 |     let guess: u32 = guess.trim().parse() {
  |                                           ^ expected one of `.`, `;`, `?`, `else`, or an operator

error: could not compile `unacceptable-rs` (bin "unacceptable-rs") due to 1 previous error

If I try this with a blank helix config I don’t get any of the text output from rust-analyzer at all, just the three dots indicating there’s a problem there, so it’s unlikely it’s a bad design choice on helix’s part.

You’re missing a match after the = and before guess… on line 25.

The multiple statements on 37, 38, 39 after => also need to be enclosed in a {}.

Also, why is your error message all the way up on the top, far away from the error? Something seems misconfigured.

It’s even a tape archiving tool. Just pretty much nobody uses it in the original way any more.

Very much one of those “if it ain’t broke, don’t replace it” tools.

Yeah, there should be a clear separation between scripts, which should have a shebang, and interactive use.

If a script starts acting oddly after someone does a chsh, then that script is broken. Hopefully people don’t actually distribute broken script files that have some implicit dependency on an unspecified interpreter in this day and age.

That’s interesting I hadn’t thought about the JSON angle! Do you mean that you can actually use jq on regular command outputs like ls -l?

No, you need to be using a tool which has json output as an option. These are becoming more common, but I think still rare among the GNU coreutils. ls output especially is unparseable, as in, there are tons of resources telling people not to do it because it’s pretty much guaranteed to break.

I’ve been using fish (with starship for prompt) for like a year I think, after having had a self-built zsh setup for … I don’t know how long.

I’m capable of using awk but in a very simple way; I generally prefer being able to use jq. IMO both awk and perl are sort of remnants of the age before JSON became the standard text-based structured data format. We used to have to write a lot of dinky little regex-based parsers in Perl to extract data. These days we likely get JSON and can operate on actual data structures.

I tried nu very briefly but I’m just too used to POSIX-ish shells to bother switching to another model. For scripting I’ll use #!/bin/bash with set -eou pipefail but very quickly switch to Python if it looks like it’s going to have any sort of serious logic.

My impression is that there’s likely more of us that’d like a less wibbly-wobbly, better shell language for scripting purposes, but that efforts into designing such a language very quickly goes in the direction of nu and oil and whatnot.

No, but the weirdos who insist on spelling it “SystemD” always seem to hate systemd.

systemd is pretty great. I tend to start long-running processes as user services, and I’ve even taken to starting some apps that give an old laptop trouble with systemd-run and a slice with some memory restrictions. Easy peasy, works great, all declarative, no wibbly-wobbly shell scripts involved.

But what did you learn? What are we supposed to learn? Did you get any context, like how he actually went to anger management therapy later?

Or is this just guffawing and gawping at an old angry email from a tech celebrity?

This mail is 13 years old, and doesn’t seem relevant for anything? This post seems like a lazy attempt at shit-stirring.

Yeah, JSON is essentially a side effect of having JavaScript already. It makes sense that it shows up a lot of places, especially web. But just like with JS, it’s not really good, just ubiquitous.

I’ve very barely dipped my toes in dbus before, and the option to have something else is on its face attractive (not a fan of XML and the late 90s/early aughties style of oop), but JSON for a system interface?

I mean, Kubernetes shows that yaml can work, but in this day and age I’d expect several options for serialisation, and for the default to be binary, not strings.

String serialisations are primarily for humans IMO, either as readers or writers. As writers we want something with comments (and preferably no “find the missing }” game), so for that most of us would prefer something like TOML if the data is simple enough, and actually Yaml for complexity at the level of Kubernetes—JSON manages to be even more of a PITA at that level.

But machine-to-machine? Protobuf, cap’n’proto, postcard, even CBOR should all be alternatives to examine

Yeh. Ubuntu also discussed it back in 2019, and wound up keeping some of it so Steam would keep working.

I expect the willingness to bend over backwards for one proprietary and very profitable app doesn’t last forever, and given how involved gaming often is with pushing technology, it’s frankly weird that Steam is still shackled to 32bit like that.

You’ll likely also want to check out ruff for linting and formatting, by the same company that makes uv. It doesn’t enable a lot of lints by default, but there’s a long list of checks to enable.

They also have a typechecker, ty, which is still in early alpha. If it’s as good as their other tools I expect it to become the standard for typechecking Python. Currently you’ll likely want to go with pyright for that.

Turn on all clippy lints on day one – even the pedantic ones. Run the linter and follow the suggestions religiously. Don’t skip that step once your program compiles.

There’s a bunch of clippy groups to enable, but IME the pedantic ones can be kinda … not what you want. Especially the one about unnecessary moves annoy me, as it suggests what I consider an unnecessary long lifetime for a value instead.