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

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

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.

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.

Nope! I tend mostly to use /org/repo and other subpages. The few times I find myself on / I’m just confused at how I wound up there and close the tab.

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.

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.

Yep. I wonder if that CRA compliance stuff won’t change that. Industries with strict demands on safety should be putting in work and resources to ensure that those demands are actually met, but how the CRA deals with FOSS took a bit of work to not be a complete disaster, and I can’t imagine it’s easy for FOSS projects to work out the details there.

As in:

1. The automotive industry absolutely should be CRA compliant,
2. it’d be nice for everyone if cURL was known to be CRA compliant,
3. compliance doesn’t appear by magic, someone has to put in work,
4. companies that should be CRA compliant should help with that work.

In the case where they don’t want to pitch in, well, something cURL-equivalent but known CRA-compliant won’t just fall off the back of a wagon, which means the companies that need compliance have a problem.

Then again, apparently the HPE Nonstop ecosystem has git available on their platform all through the spare-time efforts of all of one dude, which absolutely shows that critical systems are willing to rely on precarious software, so I’m not gonna hold my breath.

Yeah, it’s once again a case of a central piece of software in a very precarious situation, and businesses that aren’t … quite mindful of the fact that they’re making demands from someone they’re not paying.

Possibly, but the article didn’t seem to specify what the actual complaints were. Hopefully they’ve worked with some actual Apache to figure out some rebrand that’s decent towards the Apache (and addresses the complaints), but also doesn’t make the brand more different than it needs to be.

Why is this linking to what appears to be another link aggregator, rather than what appears to be the original blog post?

hey, a/s/f?

Also seems ripe for jokes about the missing d.

Though I guess the reasoning for why they’re changing it up is actually decent:

changing its corporate logo and overhaul its branding after being criticized by American Indian activists.

It’s the sort of thing that I think a lot of europeans will go “huh, what does a feather … ohhhh, riiiiiiiight …”. Like, my associations to the name are mostly the LAMP stack and a model of children’s bike that my parents have talked about. But we’re collectively also always rolling our eyes at people, especially foreigners, using stuff related to our heritage as marketing. Can’t imagine what that’d be like for the native americans and their history.

Well, bash should show up quickly enough. But yeah.

I’m also no longer much of a bash guy. Back when I was my scripts were a lot simpler, and broke in weird ways a lot more. And every time I picked up a new defensive habit, my bash became a little bit uglier, and I thought to myself “maybe I should just do this in Python”.

But this script would be a lot longer in Python.

IME I’ll rather find some openapi docs for Google than their actual product docs. As in, I’ll start out trying to read their kubernetes docs, then shortly after it’s “fuck it, I’m going to docs.rs/k8s-openapi”.

My actual worst case are Elastic’s docs, though. Somehow they have plenty of stuff in there, just never the stuff I’m trying to figure out.

For those who want to give it a go:

#!/bin/bash
set -euo pipefail

while read -rd ":" path
do
  for bin in "$path"/*
  do
    # don't error out if there's no manpage
    set +e
    man "$(basename "$bin")"
    set -e
  done
done < <(printf '%s%s' "$PATH" ":")

when you get sick of it, hit ^Z (ctrl-z) and go kill %1. Then you get to start all over from the start next time!

Bonus points for starting a tracker so you can count how long it takes to go from “eugh, what’s with that overwrought and excessively defensive bash script” to “fuck, now I’m doing it too”

Humans also frequently need to try a wrong approach first to get the idea of a better approach, no matter if we’re rested or not. Which is why it’s important to be able to throw away prototypes rather than push an “it seemed like a good idea at the time” to prod.

But having a good sleep, walk in a park, shower, etc lets us think better than if we’re just banging our heads in the same corner all day long. Breaks are important. General health, too.