Definitely not gonna defend Microsoft's naming, let alone their versioning!
BatmanAoD
joined 2 years ago
I used it briefly when it first came out; otherwise no, my employers have used Slack.
Apparently the JS name was selected and announced in partnership with Sun from the very beginning, and Sun had the copyright over both Java and JapaScript up until the acquisition by Oracle. I had no idea, but that makes perfect sense.
Bugs around read-notifications are pretty bad. Slack still has those, but they're infrequent and transient, and often solvable with a hard-refresh.
I've never understood the hatred for Teams. I don't particularly like Slack, and Teams (from my limited experience using it) doesn't seem that much worse.
Oracle? Oracle owns Java, not JavaScript.
Edit: mea culpa! Sun owned both!
I'm not even saying that Google's data collection is innocuous. I'm just saying that this post is incorrect in its claim that Google is letting Gemini access your apps even if you try to turn that access off. Just because Google does some nefarious things doesn't mean you can't think critically about actual specific actions they take.
Oh, that makes much more sense; thanks.
I think the point of the question is what a hypothetical ideal language for CI/CD pipelines would look like.
The post doesn't say "imperative", it just differentiates between defining pipeline steps and defining the logic within a step.
...also, TCL? I haven't used it for ops, but my memory of tcl/tk is extremely negative.
...also also: a core part of a build, CI, or, CD pipeline is almost always invoking binaries to run a command. That's why shell scripts are so ubiquitous in pipeline-logic: invoking binaries is what they're for. And it's very difficult to do that a declarative way: Make comes close, but it's difficult to track any side-effects that aren't "update these files", and a huge amount of CI/CD is no longer just "update a file".
Both GitHub Actions and GitLab CI let you specify filepath rules for triggering jobs.