Pretty sure even that is still over-anthropomorphising. The LLM just generates tokens, doesn't matter whether the next token is "strawberry" or "\STOP".
Even talking about "goals" is a bit ehhh, it's the machine's "goal" to generate tokens the same way it's the Sun's "goal" to shine.
Then again, if we're deconstructing it that far, I'd "de-anthropomorphise" humans in much the same way, so...
OSS isn't anti-alternative at all? Just because you don't pay for the software doesn't mean there's no competition.
Even well-established software can have meaningful alternatives. Look at ripgrep. While it hasn't replaced grep as a distro default, it's still being used by folks that find it a better solution for them.
Don't you remember how hostile people were to ripgrep just because ag or find + xargs + grep existed? Or the same with meson because cmake exists and cmake because autotools exists? Or systemd or clang? It takes an unusualy stubborn person or strong corporate backing to actually create an alternative to an established open source project.
Probably the ability to recoup the cost with a subscription after sale (or one-time purchase like FSD). Lower the cost to get into as many homes as possible, then at least a few folks will pony up for it.
When I worked for Northrop, they offered a "9/80” schedule. Every pay period, you would work 80 hours in 9 days. Monday thru Thursday, you would work an additional hour (so 9 total), then have every other Friday off.
I never did this personally, but I worked with civilians that did 9 80s. If management isn't willing to consider "exotic" schedules, 9 80s seem like a really good starting point and a pretty sweet deal
I used mercurial at one job and my experience was that the day-to-day differences were largely philosophical, especially if you primarily interact with VCS through your IDE, like me. Mercurial’s CLI API is supposedly cleaner, but I hardly interacted with it.
Mercurial has immutable history, so no squashing commits, no deleting branches, at the time I was using it there was no amending commits, in fact reverting a commit doesn’t even come enabled out of the box! Some folks loved it; no changing history, everything documented as it happened. We practiced trunk based development, so no branches except for hotfixes, so there wasn’t a lot of sprawl.
Ecosystems largely don’t support mercurial, so that’s definitely a consideration. Since Merge Requests and feature branches are largely practiced now, I feel like there’d be a lot of noise in a repo if folks used mercurial.
I don’t particularly miss mercurial, personally. I’m less into “pure” workflows and forcing behaviors. I think git is super flexible and generally practical and I’m overall pretty happy with it.
By default, Mercurial doesn't allow editing of public history pushed to or pulled from a remote repository. There are no such restrictions for local revisions, which are considered draft. And if you configure the remote as a draft repository, you can keep some remote revisions as draft before publishing them.
The history editing capability of Mercurial is arguably more advanced than git, especially in a collaborative setting, because of Changeset Evolution [1], and the Evolve extention [2]. The former keeps track of metahistory of commits. The former keeps track of the metahistory of commits, and synchronises it between repositories. The latter provides a set of expressive command line tool to edit history. With them, collaborative history editing and stacked PR is a pleasant experience.
Basically none of this post is true. History in Mercurial is thoughtfully mutable (much more than Git) with public and draft phases; hg backout is part of the base distribution; it fully supports the PR model and better ones like stacked diffs. Ultimately it lost because of GitHub, but it lives on as Fig at Google and Eden at Facebook (both of which heavily use mutable history, of course).
Talking about flexible mutable history, there are two more official extensions to be mentioned:
- evolve [0], which allows to rewrite history lossessly (without ever risking losing data)
- absorb [1] which takes uncommitted working copy changes, and for each hunk finds the last commit that touched those lines, and rewrites it. It's an extension originally from Facebook, in core since 2018. Works like magic: no "fix" commits ever more.
Plus, all of this is available using mercurial locally and interacting with git (and github) remotely, via hg-git. Admittedly, this requires to be a bit of an advanced user, but the gains in ergonomics are tangible.
>The public phase holds changesets that have been exchanged publicly. Changesets in the public phase are expected to remain in your repository history and are said to be _immutable_
Note that in Git all history is mutable, even if published.
Regarding 'backout' (and 'revert'), to the best of my knowledge, it does not revert commit, it creates a new one (reverting changes), and I frankly do not know is that's possible at all to amend commit in Mercurial (when I worked with it, that was definitely not possilbe, but that was a long time ago)
In Mercurial all history is mutable too, there's just a UI failsafe that prevents you from mutating public history unless you manually override it. Git is just plain bad in this regard.
hg backout is like git revert. Creating a new commit is correct if you want to e.g. propagate the change through continuous deployment.
And hg commit --amend has existed for a long time.
Marking commits as public is mostly a safeguard against accidentally altering history that others may already depend upon. This is just there to provide awareness of the giant footguns hiding when editing history after it has been shared (git contains the same footguns without safeguards). You can revert the status of a commit from public to draft and then change it. Just like in git, it's very dangerous to do so, but hg makes it very obvious. The command is
That's what Terraform pretty much is. All it does is manage a graph of dependencies/resources and then relies on a provider, which implements the CRUD.
Not super familiar with Hashicorp's other product Nomad but I'd think it have a similar approach, but more of a continuous lifecycle check?
Official docs: https://docs.gitlab.com/ci/jobs/job_logs/#custom-collapsible...