[apstls]

Sounds very cool.

I wanted to try this out, so I opened Windsurf for the first time in ages and clicked the "Upgrade Available" button, which sent me to: https://windsurf.com/editor/update-linux

  Did you install using apt or apt-get? If so...
  
  1. Update package lists
  
  sudo apt-get update
  
  2. Upgrade Windsurf
  
  sudo apt-get upgrade windsurf

Whle `apt-get upgrade windsurf` will technically upgrade Windsurf, instructing users to run a command that will attempt to upgrade all packages on their system is nuts when the command is provided in a context that strongly implies it will only upgrade Windsurf and has no warnings or footnotes to the contrary. Good thing I didn't ask Windsurf's agent to ugprade itself for me, I guess.

EDIT - I don't want to detract from the topic at hand, however - after upgrading (with `sudo apt-get install --only-upgrade windsurf` :)) and playing around a bit, the Codemaps feature indeed seems very nifty and worth checking out. Good job!

[kps]

So `apt-get upgrade $PACKAGE` has ridiculous semantics that no one would expect, and the actual syntax for upgrading a package is in neither the man page nor the command help.

[GuB-42]

I have been using Debian for literally decades and I didn't even know "apt-get upgrade $PACKAGE" existed. It is weird, it doesn't appear in the documentation, it doesn't work with the "apt" command, it means it is probably a relic of the past left there for compatibility reasons and you probably shouldn't use it.

My guess is that someone or some LLM hallucinated this command, "apt-get upgrade" is for upgrading your system, not for upgrading a single package, and it takes no extra argument.

For upgrading a single package, just do "apt install $PACKAGE". It is the same command as for installing. The semantics is rather clear to me, upgrading is like installing the new version on top of the old version. It also makes no sense to install a package you already have or to upgrade a package you don't have, but if you want to be sure, for example because you don't know if you already have the package installed or not, there are the --no-upgrade and --only-upgrade options.

[normie3000]

> So `apt-get upgrade $PACKAGE` has ridiculous semantics that no one would expect

Especially not an LLM!

[pxc]

Sure it is¹ (kinda):

  --no-upgrade
      Do not upgrade packages; when used in conjunction with install, no-upgrade will prevent packages on the command line from being upgraded if they are already installed. Configuration Item: APT::Get::Upgrade.

The canonical way to do the thing you want via apt-get is `apt-get install`. And if you read the man page from start to finish, it'd be clear to you... but it is tucked away there in the most obtuse, indirect, ungreppable way. :'D

That would be a great addendum to an EXAMPLES section! In the meantime, this is documented well and clearly in the tldr page for apt-get².

Fwiw, apt-get not only sucks, but has been known to suck for many, many years (more than a decade at least). Its interface sticks around because it's basically plumbing at this point. But you, as a user, should never use it (or `apt-cache` or `apt-*`, if you can avoid it.

Aptitude is preferable for a whole host of reasons, not least of which being that its upgrade commands have the semantics you'd intuitively expect³. They take packages as an optional list of positional args, and upgrade everything only if you don't pass any. (Aptitude also has a ton of other nice features and I highly recommend it.)

There's also an official new porcelain in APT itself, aptly called "apt". It preserves⁴ the semantics of apt-get's `upgrade` command, but its usage message actually matches that syntactically— hopefully it'll barf if you tell it `apt upgrade windsurf` or whatever.

But automation needs to rely on the ugly, old, disparate APT commands that have been around forever and can't really change. That probably goes, too, for things guides want you to copy and paste, or instructions handed over to LLMs.

(This is one reason that if you only learn to use APT from guides/tutorials whose primary concern is something other than documenting or teaching how to use Debian-based systems, you'll probably never learn to use the correct tools (the nicer, newer ones).)

--

1: https://manpages.debian.org/trixie/apt/apt-get.8.en.html

2: https://tldr.inbrowser.app/pages/linux/apt-get

3: https://manpages.debian.org/trixie/aptitude/aptitude.8.en.ht...

4: https://manpages.debian.org/trixie/apt/apt.8.en.html

[swyx]

hiya! team noticed your comment and agreed - and it is fixed.

    - const CodeSnippetTwo = `sudo apt-get upgrade windsurf`;
    + const CodeSnippetTwo = `sudo apt-get install windsurf`;

[Lvl999Noob]

Why not use apt?

[GuB-42]

apt-get has a more stable interface and is more suitable for scripts and instructions intended to be followed to the letter.

apt is better for interactive use and by people who are not just blindly following instructions.

Here there are arguments for both. As commands intended to be copy-pasted in a terminal, using apt-get makes sense as it is the safest choice. But it is also intended for humans, it is not a script, so maybe apt would be better. To me, both ways make sense.

[blks]

Did you also generate this with “AI”?

[swyx]

https://tenor.com/view/westworld-if-you-cant-tell-does-it-ma...

[rendaw]

My reading is that GP can tell, and they're trying to highlight it by asking a question.

[tbillington]

If you couldn't tell your food had been cut with sawdust would it matter to you if you found out?

[codebje]

I really love this comment, it's got a very "tree-falling-in-the-woods" vibe to it.

On the direct face of it, no, it turns out it doesn't matter: plant cellulose is not toxic to humans, a certain level of it is in many processed foods, and that information isn't secret.

By the time it matters to people, it's at the level where you can tell it's happened: large, pointy chunks, eg, or so much the flavour or texture is ruined. Or toxic contaminants, albeit at the significant risk that one might only be able to tell at the point of suffering from the consequences.

But if we modify the proposition a little, we get a statement about the possibility of a vegan's metaphorical sawdust being cut with ground beef. Now, it's more likely to matter. By and large, dietary choices like that are based on some belief structure, so the presence of the unwanted ingredient could be considered as an attack on the belief system.

When we move the metaphor back to AI generated code, does this reveal a belief system at play? If the resulting program is not poor quality, but the use of AI is objectionable nevertheless, does that make a "no AI in software" stance a sort of veganism for code? (And can we coin a good term for that stance? I vote for hominism, because while I quite like anthropism that leads to anthropic which is obviously not going to work.)

Given there's a regulatory number on acceptable bug parts per million for confectionary, is there a hypothetical acceptable bytes per million for AI-generated code that can still be called hoministic?

[latexr]

The HN guidelines explicitly ask you to steel man arguments you reply to. It is obvious that the point of the comment is not sawdust specifically; they could have used anything else, like cyanide, and the point would stand. Spending multiple paragraphs of rebuttal on a nitpick which fails to address the crux of the argument is precisely the kind of bad argument the HN guidelines aim to avoid.

[maleldil]

Is the result is molecular identical? If so, no.

[ethanwillis]

Yes, it does matter.

[zamadatix]

Wow, what's the upside to that syntax? I never would have guessed.