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.

I’m also a fan of baud. I really should alias cat to baud -400 cat or thereabouts.

Bonus: run baud -800 bat --color=always and you get that wonderful old dot matrix printer feeling of the cursor just stopping whenever the color codes are being processed.

Be kind, rewind.

re: mksh I have snippets in my editor for shebangs++. E.g. #!<tab><enter> nets me

#!/bin/bash
set -euo pipefail

or

#!/usr/bin/env python3
# pyright: strict

etc

They are utility, as long as you don’t have a theme that randomly picks a new colour every time the token type changes.

It’s a bit like having a bunch of different tools or utensils in separate colours. Even if the drawer is messy and the colour ultimately arbitrary, you can pick out utensils because you’re habituated to looking for a given colour.

Just stick to one theme and you’ll get the same thing but for code. Theme hopping kills your habituation, and resets you to the “I can tell that these are different things because the colours are different” stage.

The stance coupled with the garish background colour reminds me of how Pike also had a very dismissive view of using colours for syntax highlighting, and then later opened up about having a kind of colourblindness.

Both of them also seem to mean colour when they write syntax highlighting. That’s just one typographic tool among many. We also use bold, italics, underline, and even whitespace to highlight programming syntax. We could write a lot of programming languages as if they were prose, but we don’t. People hate that and call it “minified code”.

Humans also have a great capacity for colour vision, much better than most mammals. Some of us are even tetrachromats. Our colour vision is basically a free channel of information: It’s always on; we don’t have to concentrate to be able to discern most colours. When things in nature are more colourful than usual, like leaves in fall or a colourful sunset, we don’t find it tiresome; we find it refreshing and seek it out. But when our built environment becomes all shades of grey, we tend to find it depressing.

But humans are also different in many ways here. Better or worse colour vision is one thing, but some are also prone to getting overstimulated; others require more than average stimuli. We have great selective attention as a species, but again, individuals vary. There’s no one syntax highlighting that works for everyone.

Ultimately we should just find some syntax highlighting that we find generally pleasant, and then stick with it until we reflexively use the information carried in those colours. Use habit formation for our benefit.

Tonsky may enjoy his garish background colour and have found a mushy colourscheme that works for him, but he’s also way off base in his assessment of colourschemes in general.

Yeah, I’m used to having my config in git. Buuuut I guess non-devs aren’t really used to that workflow.

Distribution usually isn’t considered a strong point for Python, though.

For other languages that build a static executable, the more expected method of distribution would be some automated workflow that builds artifacts for various os/architecture-triplets, that you can then just download off the project page.

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.

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.

Isn’t that just nitpicking?

No, because the definitions are phrased very differently. Software doesn’t have to be copyleft to be considered FOSS either, as is the case with tons of BSD and MIT and whatnot code that’s used in proprietary programs—all they have to do is make it clear that they’re using their software (and even that’s not a given).

Even with copyleft licenses like the GPL, as long as they never distribute their software to anyone they don’t have to offer them the source code either, as with so many backends. The AGPL gives consumers of distributed systems some more rights.

Free software is mostly about providing you rights when you encounter the source code, meaning that you’re allowed to modify it and share it. This is as opposed to stuff like “source available” licenses that permit you to read the source code, but not modify or share it.

Such a license would neither be regarded as free software nor open source.

Some other alternative could be making GPL-3.0-or-later + a Contributor License Agreement a more common option, so that it is possible to tell companies that if they want to use the library in some closed-source application, they need to work out a license deal.

CLAs are frequently involved in turning software proprietary though, so it isn’t exactly held in the highest esteem in the FOSS community.

And without a CLA you essentially get the Linux kernel situation, which will be stuck on GPL2 forever, since they can’t reasonably get everyone to agree to switch to GPL3, especially since some copyright holders are not just unwilling, but unreachable or dead (and in several jurisdictions copyright lasts for decades after death).

Personally I suspect public funding, similar to science, education and libraries, is a more likely option, though that’ll be an uphill political struggle a lot of places.