Just yesterday I saw Claude.ai use double dashes in its responses for the first time...

Exactly... How long until people figure out that LLMs emulate common writing patterns as their sole reason for being

Pacman does check for changes in configuration files, and adds .pacnew files instead of overwriting them:

https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave

> I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security.

Sadly, yeah. And will do anything only if they believe they can actually be caught.

An EU-wide bank I used to be customer of until recently, supported login with Qualified Electronic Signatures, but only if your dongle supports... SHA-1. Mine didn't. It's been deprecated at least a decade ago.

A government-certified identity provider made software that supposedly allowed you to have multiple such electronic signatures plugged in, presenting them in a list, but if one of them happened to be a YubiKey... crash. YubiKey conforms to the same standard as the PIV modules they sold, but the developers made some assumptions beyond the standard. I just wanted their software not to crash while my YubiKey is plugged in. I reported it, and they replied that it's not their problem.

Name and shame, and give them a trial by media.

> But you still haven't fixed the typo-prone keybinds!

Which key bindings are you referring to?

It's not a trap, I promise! Just fishing for ideas.

I literally meant the ones I quoted

> by running q: instead of :q

other than that don't have a bigger list since most of the defaults are bad, so didn't use them

Personally I mapped <leader>q to quit, and <leader>w to save, as well as <leader>x to save and quit.

>>broken SGX metadata protections

>Citation needed.

https://sgx.fail

https://en.wikipedia.org/wiki/Software_Guard_Extensions#List...

It looks this way at first glance, but at the end of the article is a link to the original:

> If you’d like an essay-formatted version of this post to read or share, here’s a link to it on pluralistic.net, my surveillance-free, ad-free, tracker-free blog:

> https://pluralistic.net/2026/01/14/sole-and-despotic/#world-...

This is a case of Publish on your Own Site, Syndicate Elsewhere - https://indieweb.org/POSSE

Firefox for Android, for one, shows the alt text at the top of the context menu that pops up when you long press an image.

If it's too long, it gets truncated, though.

You can tap on a truncated alt text to extend it.

> That’s typical usage of Awk, where you use it in place of cut because you can’t be bothered to remember the right flags for cut.

Even you remember the flags, cut(1) will not be able to handle ls -l. And any command that uses spaces for aligning the text into fixed-width columns.

Unlike awk(1), cut(1) only works with delimiters that are a single character. Meaning, a run of spaces will be treated like several empty fields. And, depending on factors you don't control, every line will have different number of fields in it, and the data you need to extract will be in a different field.

You can either switch to awk(1), because its default field separator treats runs of spaces as one, or squeeze them with tr(1) first:

  ls -l | tr -s' ' | cut -d' ' -f3

Cut has flags to extract byte or character ranges.

You don't have to use fields.

Can these flags be used to extract the N-th column (say, the size) of every line from ls -l output?

Yes.

    $ ls -l | cut -c 35-41

        22 
      4096 
      4096 
      4096 
      4096 
      4096 
      4096 
        68 
       456 
       690 
      7926 
      8503 
     19914

This is what I get:

  ls -l | cut -c 35-41
  
  6 Nov 1
  6 Nov
  6 Nov 1
  6 Nov 1

Well, sure. I said it did character ranges so you don't have to use fields.

What were you expecting? That your character ranges in ls would match mine?

> What were you expecting? That your character ranges in ls would match mine?

I would expect the command to work in any directory. Try a few different directories on your computer and you'll see that it won't work in some of them.

> I would expect the command to work in any directory.

But ... why expect that? That's not what "character ranges" mean.

I mean, I was only trying to clarify that `cut` is not limited to fields only.

> once you develop a good enough utility library for it.

What happens when everybody comes to the job with their own utility library and start working on the same codebase?

Would you like it if you had to get up to speed with several utility libraries your coworkers developed for themselves?

A common set of tools, like the Unix commands, makes it easier for people to collaborate. They were put in an official standard for a reason.

The 2 minutes wasted to write it doesn't move the needle, but the time that their present and future teammates will waste on reading it might.

It costs me more effort to read and understand a screenful of unfamiliar code than the equivalent "sort -k 1.1" or "uniq" while skimming through a shell script. This adds up.

Assuming teammates are all experts at linux commands. Fact: not everyone knows what "sort | uniq -c" does or can type it out on demand. Actually I'll be surprised if more than 25% of all software engineers can do that . If you don't believe me, ask random people inside and outside your company.

> It costs me more effort to read and understand ...

You don't need to. LLMs are meant for that. You probably will roll your own script anyway and none of this matters.

You are worrying about things that, in my experience, do not make any noticeable impact on overall productivity.