If you want a kinder world - one with fewer scams, less violence, and so on - then put your energy into making sure that everyone has food to eat, a table to eat it on, and a safe way out of relationships that turn bad.
You can shorten the iTerm guy's response to this critique as "I disagree" and not lose any of the nuance. If you care why he disagrees, by all means read into it, but if you primarily care about not having network-based ML tooling in your terminal, his disagreement is a sufficient response on its own to your concerns. Decide accordingly.
My day job, many years ago now, adopted a language developed by a Fortune 50 company as an open-source project. We did not negotiate any kind of long-term support agreements with the vendor, and they have since shuttered the team that was working on the language.
This sucks, frankly. My org made the decisions it made for reasons I recognize, but they also adopted some very foreseeable risks, which are now coming home to roost.
The practical consequences of this decision range from "you can't have syntax highlighting in your editor" (annoying human factors problem) to "we are maintaining complex remote environments to support development, with a substantial daily operational cost" (financially reportable, and therefore "substantial" in some ways that the human factors sometimes aren't).
@owen Plus the inevitable "no secure versions of a critical lib exist anymore that are compatible with this language," and likely having to pick up ownership of a fork of that lib to fix that problem, since it is somehow the least-intensive way to fix that problem.
Direnv has been a great help for me in getting out of the habit of storing creds in dotfiles. I wrote up some patterns I've found useful: https://grimoire.ca/code/direnv-patterns/
gripe: the AWS terraform provider reports space utilization for EFS (NFS-as-a-service) volumes as attributes, so the resulting state file is always, permanently, out of date
this has no practical consequences, but if you're storing state locally via git, it produces a lot of spurious diffs
The actual fuck if IBM acquires Hashicorp is that so much of Hashicorp's value as a maker of development tooling is tied up in free contributions. Some of those are from large organizations who made a considered decision to support Hashicorp (eg. Amazon, who write their own providers for Packer and Terraform), but many are from individual devs or small shops who are just trying to get their own jobs done.
None of those people will see any compensation for the value they added to this deal.
One of the reasons I pulled out of doing open source infrastructure development, scrubbed my Github profile, and otherwise dropped out of Free Public Software Development is that I am bone tired of giving free labour to these fucks.
I'm particularly frustrated right now because I tried to search "OC Transpo fines" and got nothing but news articles about their fare-enforcement practices.
That's search failing to meet the (underspecified) needs I have, but it's also in part because OC Transpo does not publish that information in the first place.
@danhulton Crawling links is a cataloguing strategy! I think it's one predicated on the idea that the web is too large and too rapidly-changing for manual curation, but that's … debatably true? It's too large for one person or organization to catalogue, I'll grant, but there are other alternatives besides spidering.
@owen I think I care less about cataloging "the web" these days and am happy to settle for "the parts of the web that other people like me have decided are any good."
Like, I'd be thrilled if my searches never included link farms or hate sites or AI spam sites, etc.
And I THINK I'm okay with that index not being perfect, line missing a good chunk of stuff that hasn't been approved yet. Actual experience would have to bear it out, but it feels like an okay trade-off.
Companies like Google have framed the answer as a single, free-text field, with the promise to find something for any query from a corpus consisting of pages found by progressive mechanical indexing of links. That demonstrably is useful, both for Google and for at least some of its users, but equally, that demonstrably is not universally valuable.
With public for-profit search on the internet breaking down badly - and with Google, Bing, DDG, and their also-ran peers breaking down particularly badly in the direction of "here's a thing you can buy" - I think the time is actually ripe for a discussion of what we, as users, want out of search, and more generally how we want to find information on the internet.
There are technical and philosophical rationales for combining development and operation into a single organization, certainly, but those explanations ring hollow because the people in those organizations rarely have the agency to decide policy at that level. And yet, there has been a widespread shift to a recognizable "devops" approach across a wide range of technically-mediated businesses.
Unfortunately, deciding that it's no longer someone's job to do operational work, such as capacity planning or continuity management, does not relieve the consequences when those tasks are ignored or done badly.
Does anyone on this webbed site remember pre-AltaVista-era library search computers and their interfaces? If you do, do you know the names of any of the software packages that provided those catalogues?
You don't. We accept these risks on a daily basis, in service of getting useful work done. The observed reality is that that trust is violated only rarely (or, if you're of a more particular frame of mind, only violated in ways we discover rarely).
Computers as modernly constructed mediate relationships, and the security of the computer is only as good as the trust in those relationships.
We can have trust relationships with people we know only sparingly! We do that all the time - we trust that the grocery store isn't selling us fake olive oil, or that our clothes are made of cotton and not asbestos, too. Those beliefs, too, get violated, but intermittently.
It doesn't disagree with your larger point, this is still one product out of millions, but I found it interesting that cooking oil is one of those things that's actually frequently falsified.