I hate to defend Adobe but it literally says "Annually, paid monthly" right under the price.

They should for sure list the annual price and the monthly price but it's not "burried".

So it's not really a cancellation fee, but is that how they message it?

If I see: "Annual Subscription - $120/year, billed $10/month" I assume I'm paying $120 even if I cancel after 6 months.

But, if I cancel after 6 months, and the message to me is "$60 cancellation fee", I'm very confused - I thought I was paying the remaining $60 I owe them...? The amount may be the same but it's confusing nonetheless.

Wait, so you'll pay the $60, and then, will you lose access?

Any time I've had a similar subscription, you retain access for the full period.

The messaging has usually been something like: "Annual subscription cancelled at the end of current period. Access ends on 12/31/2026" (even if today is 6/1/2026)

That's why the "cancellation fee" comment is weird to me - there's no need to message that way, since "pay the rest of the committed period" seems to be a common (and at least to me, very understandable) way to handle this.

Even with monthly services, I don't think I've ever had an immediate loss of access - it's there until the end of the billing cycle. As it should be, IMO. The only exception would be if I force-deleted my account as well as that's a very explicit "I'm done-done" signal to the service provider.

Probably? There are services that are relatively nice and will let you use your membership until the last day (even for trials!), but there's also others that are non-refundable and will just yank your access.

Hm so you're saying all the SaaS runners should put "Lifetime, paid monthly" in small print under their price? Bam, goodbye churn.

> They should for sure list the annual price and the monthly price but it's not "burried".

Buried prices are the next frontier of consumer protection. I've gotten burned by looking up a store product online and then when attempting to purchase finding that unless you ordered it through the site for in-store pickup, you get a higher price. Car dealerships were the same the last time I bought one. And while I appreciate Tesla's challenge in expressing TCO, subtracting average fuel costs from the price of a car smells bad in the same way.

Seems intentionally manipulative.

The cancellation fee is usually the part that's buried.

Maybe years ago, but today it very plainly says:

>Fee applies of half your remaining annual commitment if you cancel after Nov 01

and for the prepaid option

>No refund if you cancel after Nov 01

https://www.adobe.com/#mini-plans-web-cta-creative-cloud-car...

Very normal thing to say.

You don't think an extra 66% of people in any state getting off their asses and voting could affect the vote in a meaningful way?

Correct, the sentiment would have been the same distribution of votes across states. The electoral college distribution would have been the same 312 to 226 and not close at all

The way you talk about things could have easily resulted in California’s 54 electoral college votes flipping to the majority resulting in 366 electoral votes for the winner. Your numbers are spread across where people actually live after all, as opposed to a campaign swing state

How is he being "punished"?

I've always wanted to deal with cache invalidation in my terminal.

Call it "memoized CLI" instead, you'll sound super cool

I'd suggest something more realistc than a CEO suffering any consequences for their actions.

> Set up Strata on this PC for me: https://github.com/Niko1221/Strata - follow docs/AI_SETUP.md in that repository.

And I thought piping to bash was bad

I've never understood the security argument people are making when they complain about `curl foo | bash`. I get that these scripts sometimes mess up your bashrc or whatever, but from a security perspective I see no issue. You are already installing software from the same domain. If they were going to do something nasty, they could do it with any of the software you are using from them. It doesn't have to be the setup script.

To compare it to just one other option: when you run `npx foo`, you know* that you’re getting the same public artifact that anyone else running it at the same time would get. (If you have a `min-release-age` configured, you also benefit from that.) If I wanted to distribute software like this, I’d include npm-shrinkwrap.json; then, with `npx foo@1.2.3`, you could be similarly confident in getting the same app every time.

(I picked this option for ease of comparison, getting a couple of major security wins with very low effort; I don’t recommend `npx`ing stuff in an otherwise unprotected environment either.)

* well, you can be somewhat more sure

So to be clear; the solution is then something like

`curl https://raw.githubusercontent.com/my/domain/setup.sh | sh`

Note we dont even have a hash there - just a promise that a third party (github) has a log of whatever was hosted at that url.

maybe then we'll pin hashes instead of filenames, and oops now anybody can fork my/domain and hand out a link that looks official with whatever contents they wish

While I don't think piping curl into bash is the most secure, npm installing has proven time and time again to open yourself up to supply chain attacks. At least with curl you know that you're getting the supply chain put together by the software author. With npm, every single library is a vector for attack every time you update.

You’d be getting the supply chain put together by the software author in either case. It’s common to do both badly, but if you care about doing it well, that’s easier with npm (e.g. shrinkwrap, as mentioned) and can be taken farther (the non-varying artifact thing).

Npm dependencies resolve at install time though, so some of the pinned versions may have changed ownership or otherwise been modified since the author pinned them. With the curl | bash solution you're getting a singular supply chain packaged by the author at release time.

Package versions released on npm are immutable, so no, they can’t. If you have unpinned transitive dependencies: that’s why I mentioned npm-shrinkwrap.json a couple of times.

And again, npm is also an example of “a singular supply chain [selected] by the author” in this way. On top of what cpuguy83 mentioned, curl | sh is vulnerable to compromise anywhere on the stack serving the script (domain name, host, maybe CDN, GitHub account if it’s just a redirect to GitHub as they regularly are), and coming back to what I originally said, even the real author might decide to serve you a special version of the script that nobody else is getting. You’d never know.

With curl|bash you are literally getting anything that happens to be in that script. These are frequently poorly constructed, so not check hashes or pin dependencies they install. Even security companies (see trivy supply chain attack) get these badly wrong.

I'm not replying here to say one is better than than the other (npm has obviously had its share of problems) but rather to combat claims that curl|bash is somehow safer, it absolutely is not, in fact it's all the bad stuff about npm without the pretense of being potentially safe.

You can detect the use of curl|bash server side, hence it's an essentially undetectable attack vector. People have shown poc attacks of that kind all the way back in the 2010s

https://news.ycombinator.com/item?id=17636032

The original blog is no longer available though.

But I've not had that stop me from doing that myself, I am more towards the "I like easy" then the "I want to be secure" crowd

There’s a snapshot on web archive:

https://web.archive.org/web/20250109045029/https://www.idont...

How would you do that? Just rely on the user agent? I use curl quite a lot, but don't pipe to a shell.

IA link to the linked blog: https://web.archive.org/web/20250109045029/https://www.idont...

The setup script often runs privileged (by calling sudo) and that's not unexpected when installing new software.

When I install something, and it asks for my root password later, I will be much more likely to think "hold up, this ain't right".

  cat >> ~/.bashrc <<'EOF'
  sudo() {
    sudo install-drivers-without-your-permission
    command sudo "$@"
  }
  EOF

(this is not an endorsement of curl | sh, just an indictment of the state of software)

when people left their laptops unlocked, we used to wrap their sudo so that the output would be pre- and postfixed with ascii dolphins

Can you give me a popular example that requires sudo? I don't think that is very common at all.

every single bash replacement for one.

oh my zsh is a specific example.

chsh requires sudo on most installs.

People with less experience normalize that behaviour and when the domain is not trusted the habit let their guard down. See all the clickfix attacks.

The real problem is that we just aren't using package managers. We should be using package managers. Package managers are really really good.

I push binaries from untrusted sources through VirusTotal before running them. Piping a Bash script from curl bypasses that. Furthermore, such Bash scripts, when they aren’t self-contained, make security checks more difficult than a self-contained archive, installer, or binary, even when downloading the script without immediate execution.

You could always curl the install script, and modify it to run the virus scan in between the build and install steps.

Nothing is stopping anyone from pointing their agent to that script to review and audit it before running it.

I don’t believe an agent can do that effectively without a sandbox to run the script in, if the script isn’t self-contained.

And everyone running a research agent on every download can’t be the solution. It’s much more effective to crowdsource a security database based on hashes. But for that, the downloads need to be self-contained.

The intended workflow is to download the install scripts, download the source code, read them both, and then start running things. That’s how Open Source is secured. Piping from bash to curl is just the most obvious warning flag.

And practically zero people are actually using this "intended workflow" in the real world.

Yes, the status quo is quite bad, which is why it gets complained about a lot.

There is no argument. It's just people's reflex reactions.

The technical excuses they come up with (e.g. that the server can detect it and send different content) are just post-hoc justifications for their instinct.

Just ignore them.

It's `curl foo | sudo bash` that's the bigger objection. Running software usually shouldn't require root, and then the equivalence argument you make doesn't hold.

Concern over "sudo" requirements is always fair but it' nothing to do with curl+bash over how else you download and ran it.

Installing from distribution package is much safer than curl+bash because it doesn't require you to extend trust to anybody else. You could argue that malicious code could still pass through the distribution mechanism, but at least it's fully auditable and you're guaranteed to be in the same boat as everyone else.

a script isn't getting hashed to see whether or not it's the one the website intended to serve you, for one.

what use is hashing every piece of software that goes thru the distros package manager just to throw caution to the wind at the layer above it?

w.r.t. "it's already from the same domain" , well most bash/z install scripts either invoke a package manager or they download and untar a package that has nothing to do with the host domain, anyway.

Piping to bash is definitely worse because there is no plan mode in bash. Agents also normally don't execute anything transparently, at worst you'll see it doing something weird in the logs.

Yeah, I was surprised at first then had to dig through setup.py and setup.sh files to figure out.

And yet people will let AI agents run autonomously on their machines. I feel like we're reaching peak YOLO with security.

Or use a twm

twm(1)? <https://manpages.debian.org/trixie/twm/twm.1.en.html>

one of many options.

> Such collusion might well be a violation of anti-trust law

The Memory cartel do not care about silly things like laws

Most town centres are 90% boarded up forgotten realms. They have been in decline for decades, blaming it on people riding e-scooters and illegal e-motorcycles is laughable.

It's a catch-22. They're boarded up realms because even after the online shopping revolution and attempts to regenerate them people don't want to go because they're full of deadbeats and ASB. Who would want to open a business there? For christ sake our local McDonalds is now playing Mozart at full blast in the evening outside to try and keep the ferral youth away as it's in the bang center and a popular hangout spot. It's somewhat working to an extent, but they're still around.

There's going to be a generation of ex-youths nostalgic for Mozart from their days hanging around McDonald's - I'd get shares in Classic FM if you've got money.