Yeah. I’m surprised businesses haven’t been quicker to setup self-hosted Mastodon as their primary, and then mirror that to Twitter and Bluesky and such, for disaster recovery protection.

Mastodon doesn’t by design, so they’re gonna have a much, much harder time there.

In theory, yes. But what early switching folks are reporting is that the total impressions are much lower on Mastodon, but the total engagement is much higher, for the same effort.

Which is confusing unless we factor in what we know about Twitter farming bot account on purpose to create a false appearance of success.

Of course, there’s still the matter of Twitter genuinely has orders of magnitude more users. So as an either/or proposition, no way does it, yet, make sense to ditch Twitter for Mastodon.

But for the value-to-reach ratio, with the same effort applied to both, anyway, Mastodon is actually already a better value than Twitter.

All that to say, yeah, Twitter is better, purely due to the user base, and Mastodon’s algorithm actually treats creators better. Which we kind of already knew, as it was created by people fed up with Twitters abusive algorithms.

Well that just got added to my interview question bank…heh.

I hope GIMP is able to do the same!

That would be amazing. Gimp hating user design has been a joke punchline for so long, I can’t even say where I would start fixing it.

most evidence suggests that piracy goes down in response to easily accessible and affordable market conditions.

The assholes know this too. We’re about due for another round of deshitifcation, just long enough to restore complacency.

I do not advocate for piracy. I advocate for archiving.

Exactly. And if the assholes make it illegal for librarians, well then yo ho ho.

Salutes

It means that pirates don’t have to wait for release dates, because Netflix didn’t secure their servers.

But it’s a good thing that Netflix serves DRM to my devices through my paid account. We wouldn’t want me watching it later without paying them again!

Fair enough.

Here’s what I remember: invoking SQL containing inserts from bash has resulted in lost data, when fairly unsurprising database things happened, since bash didn’t really expect to be in charge of logging the details of the attempted change. For the error, it wasn’t something surprising - maybe it was “max connections reached”, stuff that will just happen sometimes.

The data loss was probably solveable in bash, but the scripter didn’t think to (and probably would have needed more effort in a full development tool).

but how do people have the patience to deal with all of that in the beginning?

Whenever I was frustrated with a stupid undecipherable error message, I would just tweak my vim config a bit.

Within a few minutes, my rage at the error would be completely replaced with rage toward vimscript.

Then I would revert my vim config change, and return to the undecipherable error message with a fresh perspective. mainly relief that at least it’s not vimscript.

Joking aside, I really did learn vim mostly during coffee breaks or while waiting on some long running build process.

This is why I asked what sort of problems have you ran into before,

Lol. I’m fucking old. I don’t remember details.

assuming you haven’t been doing risky things with the connection.

Ha! Not a safe assumption, though. I’ve maintained even more shitty code than I’ve written, and that’s a lot! Lol.

I find this argument somewhat weak.

Lol. Me too. I was just trying to give the shorthand version.

Your explanation is much better.

Edit: but it doesn’t sound like you really needed a detailed answer from me, anyway.

Bash is for system maintenance, not for business logic.

That is such a good guiding principle. I’m gonna borrow that.

Thank you. I wasn’t thinking about that. That’s a great point.

As long as any complex recovery logic fits inside the SQL, itself, I don’t have any issue invoking it from bash.

It’s when there’s complicated follow-up that needs to happen in bash that I get anxious about it, due to past painful experiences.

That’s a great point.

I post long enough responses already, so I didn’t want to get into resilience planning, but your example is a great highlight that there’s rarely hard and fast rules about what will work.

There certainly are use cases for bash calling database code that make sense.

I don’t actually worry much when it’s something where the first response to any issue is to run it again in 15 minutes.

It’s cases where we might need to do forensic analysis that bash plus SQL has caused me headaches.

Sure.

I’ll pick on postgres because it’s popular. But I have found that most databases have a similar number of error codes.

https://www.postgresql.org/docs/current/errcodes-appendix.html

It’s not an specific error that’s the issue, it’s the sheer variety of ways things can go wrong, combined with bash not having been architected with the database access use case in mind.

What do you suppose bash could do here?

• For the love of all that is holy, it’s not 1970, we don’t need to continue to tolerate “if … fi”
• Really everything about how bash handles logic bridging multiple lines of a file. (loops, error handling, etc)

I’m sure there’s space for a clear alternative to arise though, as far as scripting languages go.

The first great alternative/attempt does exist, in PowerShell. (Honorable mention to Zsh, but I find it has most of the same issues as bash without gaining the killer features of pwsh.)

But I’m a cranky old person so I despise (and deeply appreciate!) PowerShell for a completely different set of reasons.

At the moment I use whichever gets the job done, but I would love to stop switching quite so often.

I hold more hope that PowerShell will grow to bridge the gap than that a fork of bash will. The big thing PowerShell lacks is bash’s extra decades of debugging and refinement.

it’s (bash) good enough for small tasks that you don’t expect to grow in complexity.

I don’t think you’ll get a lot of disagreement on that, here. As mention elsewhere, my team prefers bash for simple use cases (and as their bash-hating boss, I support and agree with how and when they use bash.)

But a bunch of us draw the line at database access.

Any database is going to throw a lot of weird shit at the bash script.

So, to me, a bash script has grown to unacceptable complexity on the first day that it accesses a database.

That said, I don’t necessarily agree that bash is bad from a maintainability standpoint.

My team uses bash all the time, but we agree (internally as a team) that bash is bad from a maintainability perspective.

As with any tool we use, some of us are experts, and some are not. But the non-experts need tools that behave themselves on days when experts are out of office.

We find that bash does very well when each entire script has no need for branching logic, security controls, or error recovery.

So we use substantial amounts of bash in things like CI/CD pipelines.

“There are still the billion other footguns built directly into bash that will destroy hopes and dreams, but”

That’s well put. I might put that at the start of all of my future comments about bash in the future.