and include expensive endpoints like git blame, every page of every git log, and every commit in your repository. They do so using random User-Agents from tens of thousands of IP addresses, each one making no more than one HTTP request, trying to blend in with user traffic.
That's insane. They also mention crawling happening every 6 hours instead of only once. And the vast majority of traffic coming from a few AI companies.
It's a shame. The US won't regulate - and certainly not under the current administration. China is unlikely to.
So what can be done? Is this how the internet splits into authorized and not? Or into largely blocked areas? Maybe responses could include errors that humans could identify and ignore but LLMS would not to poison them?
When you think about the economic and environmental cost of this it's insane. I knew AI is expensive to train and run. But now I have to consider where they leech from for training and live queries too.
You like the marketplace? I dislike it. Or at least its form. I appreciate that there is sharing of actions.
But I dislike having to navigate between repo and marketplace pages. I dislike that I have to assess who publishes them and inspect whether they and the code are trustworthy, and I have to assess risk or whether to copy or extract the relevant code. (And then you have to add and configure via text and magic strings and look up params elsewhere which of course is a consequence of the tech, not a fault of the marketplace itself.)
I feel it adds so much indirection and diffusion it's hard to do good trustworthy actions/code well. Which if course stands against it's usefulness of sharing workflows and actions. I know I'm more concerned and more thorough with that stuff than most people.
I would dislike the first/referenced commit description as verbose as well. It describes a user or change drafting journey without ever saying concisely or separately what the commit actually does and why. If it at least had that summary up top in a first block or separated with --- separator it'd be much better.
I like the first part of the suggested alternative but I would never put a discovery journey into the commit message, or a "an hour of my life wasted". I would put them in a MR comment - or separated block in the MR description with the intention of it not becoming part of the merge commit description.
The journey is not relevant to the code and changes. When you think of looking at it one year later, you can see the value of a description of the change, but I don't see value in the discovery journey. The journey is more relevant in team-knowledge and workflow of how to work with the code base, and inter-personal team building.
Too much bloat of irrelevant information diminishes discoverability and conciseness of descriptive and useful information. It's noise.
I would hate to have to open Jira tickets to be able to understand code or code changes in Git history.
I guess it depends on the quality of the summary. And how usable your issue system is.
I'm sure I would continue to feel uncomfortable though, about the code and history itself not being self-describing. Issue systems change, become unreachable, etc.
I hate the default merge commits. I got quite frustrated when a FOSS project rejected (or didn't come to a conclusion) my proposal for merge commits to also follow the commit formatting guidelines.
The cherry on top is merge commits describing which branch is being merged. But the branch disappears with that merge. I consider it worthless. The branch name is a name of the drafting process. There is no value to it when it lands.
Oh no, not Discourse :( I never liked Discourse. I guess mainly for the UI and UX/navigation.
Still likely an improvement for approachability. For a mailing list you essentially need pre-knowledge and a client to use reasonably well. A [Discourse] forum may need an account, but is hosted and straight-forward.
Given that it's already established I see why the question of alternative forms and platforms wouldn't even come up.
It can't be the terminal that decides what inhibits and what doesn't. It must be the user or programs themselves.
How would implementing it in the terminal rather than shell look like? As a user choice? I don't see how that's reasonably possible.
Reading the other comments it seems like there's already inhibit commands.
If the shell does not provide a command or alias, or they can't because the inhibit API is system dependent, it's on the user to define. The user could define a fg alias or command, fg for foreground, which executes the command with inhibition.
🤷 This didn't point out anything that's not a technical consequence and Microsoft planned for.
The overall ecosystem migration is not simple because of prevalence and variance in use, but it's still a huge net positive in my eyes.
I wouldn't call it messy. It's planned out, and the kind of process and concerns most senior devs are familiar with from any kind of tech migration. It's pretty clear with clear and well-defined concerns and solutions in my eyes.
this project was created due to wanting to give control of communication and data back to the people
The "giving control of communication" goal seems to contradict the "viewer automatically shares without a choice" and the dependence on good-intent node owners not moderating their node content.
If a node owner hosts a community, what prevents them from moderating that community?
This feels way too apologetic by MS to me. Dunno if that's mainly the reporting in this article.
When asked by BleepingComputer about this development, cybersecurity researcher Amit Assaraf continued to claim that the extension did contain malicious code. However, there was no malicious intent from the publisher, commenting that "in this case, Microsoft moved too fast."
They "accidentally included" stuff that didn't belong in there. They obfuscated their code. Multiple red flags were hit.
For me, moving fast in blocking spread seems warranted. Maybe it shouldn't trigger removal on installs immediately, depending on how fast they can check.
The authors ban circumvention and outdated dependency the cause but not an issue claims were dubious at best as well.
Sure, maybe no ill intent. But that doesn't mean security practices should not happen.
What makes GitLab CI better than GitHub Actions in your eyes?
I've not extensively used either, and GitLab CI has been a while, but they felt pretty similar. I had put them into the same category.
We use Jenkins at work. I administrate it. For the most part, I find it horrendous.