RSS is no simpler. And in fact when you have to take account the ambiguity of different clients interpreting the sloppy specification differently it just gets more complex.

Even the trivial case of trying to include "&" in a title is ambiguous and different clients will handle it differently.

That’s helpful, thanks for replying

At least in the past it was GLM-4.6. IDK if it is ever changed.

https://github.com/anomalyco/opencode/issues/4276

I’ve heard that too, but since it’s a stealth model, I suspect they change it to whatever preview model provider that offers a free endpoint. In the past few months, I’ve gotten 4xx errors identifying the provider as DeepSeek.

Scrolling on desktop is also broken.

This is fixed

This seems like a great option for local usage. With 16 GiB of VRAM on the official (https://huggingface.co/poolside/Laguna-S-2.1-GGUF) Q4_K_M quant (which seems to be recommended) I can get about 50 t/s in and 10 t/s out. Definitely not winning any speed benchmarks but totally usable for background tasks.

The intelligent and decision making looks good overall. It seems to roughly compare to unsloth/Qwen3.6-27B-GGUF:UD-Q8_K_XL while being way faster on my hardware. It does often get stuck considering the same decision over and over again but maybe this is how it makes the better decisions.

However it does seem to have a bad habit of corrupting things (most often my name). It will rewrite kevincox to kevinc or kevcox or kevancox. Then fail to read directories or rewrite code with the wrong string and mess it up. Then it can't identify it's mistake.

Maybe I'll have try try out the Q8 model, but the description seems to push away from this one.

See also why houses are often painted when being staged for selling just so that the new purchaser can paint immediately after with their preferred colour. Wasteful but it works.

In minesweeper you start with nothing visible and explore while avoiding the bombs. In this you start with all of the hints visible and place the bombs.

However in practice it is very similar since identifying where the bombs are to not click them is exactly the same logic as identifying where the bombs need to go. The only functional difference ends up being that all of the hints are visible upfront rather than needing to discover them.

You don't place the bombs, but still find the bombs. And you still explore by finding x.

Traversing a linked list is terrible for performance. But in cases like the cache you are only poping from the front, appending to the back or removing which are all quite fast and require little pointer chashing.

Cache cost of individual allocations can be an issue but that can also be mitigated with a good allocator and even without special care can be quite performant in many applications.

I agree the linked lists shouldn't be the first structure you reach to. But there are situations where they can perform very well.

.eu is an exception as it is for the European Union but they don't consider themselves a country.

While they're commonly called "country codes", being a country is not a requirement for having one.

Consider .uk vs .gb

.aq for Antarctica

.ax is part of Finland (.fi)

and so on.

https://en.wikipedia.org/wiki/Dependent_territory

https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

I am not a huge fan of most of these, but a few do seem useful.

    : "${1:?missing argument, aborting!}"

I wouldn't use this because I would want to give $1 a name for the rest of the script, so I would assign. But it can be a nice way to give a clear error for missing required environment variables.

Many of the others (like truncating files) are probably more clearly written with dedicated commands, but may come in useful if you are going to extreme lengths to avoid dependencies outside of the shell.

Yo, author here.

You are very much correct and I 100% agree with you, I have updated the first example to include a snippet where a proper env-var is used to show of the automatic diagnostic.

Thanks for your feedback, much much appreciated!

For a short-lived script, the `${1:?missing argument}` stuff may be useful, but usually, I want to print some longer usage or help text in the error case.

I usually go with something like this:

  set -eu
  
  function eusage() {
    echo "Usage: $0 <input-file> <output-file>" >&2
    echo "Error: $@" >&2
    exit 1
  }

  infile=${1:-}; shift || eusage "Missing input filename"
  outfile=${1:-}; shift || eusage "Missing output filename"

The `${1:-}` in this case evaluates to an empty string if `$1` is not set, but `shift` fails when there is no argument to remove.

Agreed; author does note

> Why use the null-command when I could do VAR=${VAR:-default-value}?

and points out it's one less thing to typo, but that assumes the name is the same; I like e.g.

  TARGETFILE="${1:?need input file}"
  OPTIONALVAL="${2:-defaultvalue}"

$1 might also just be the first parameter for a function call, so you might not need that parameter to have a specific/readable name if the function is not very complex or long. I have plenty in my dot-files that are just one-line functions that don't need to be three-line functions just to give the single parameter it accepts a name.

"Shortcuts" like :? that tie together two unrelated things (checking a variable for a condition, expanding the value of that variable) drive me up the wall. It makes expressing just one of the two things harder than expressing both, leading to contortions when you want just one, like this use of :.

I use this for setting overridable defaults (this should hopefully actually be in the article I haven't read yet)

: ${DEBUG:=false}

debug is not only false, but garanteed to be set to something so that elsewhere the places that use it don't need extra syntax and checking in case it's empty, and yet you can just set it from the parent environment to override without touching the script or adding a commandline args parser.

And do me, reading this is almost as easy on the brain as just plain DEBUG=true.

Even if you aren't familiar with the extra syntax, like you're someone else in the future who needs to look at it, the two important words pop out, and probably don't mean NOT because whatever those extra bits mean, there's no !. So you get the idea well enough & cruise on.

...[edit] yep it's in the article. but one thing isn't, exactly

    condition && {
        then-cmd   # might exit > 0
        :          # ensure this block ends true
    } || {
        else-cmd
    }

In other words, maybe you should have figured out some other way to write the whole construct, but IF you want to write the if/else this way maybe for just readability or organization, and you want the else-block to only hinge on the initial condition and not also on whatever the then-block might do, then you need a safety-true at the end of the then-block.