I am not scientist enough to judge this, so please someone enlighten me: most categories i've read through that find a shift do so with an increase of about 0.1-0.2 standard deviations. that does not sound significant to me. is that enough to make the claims this study makes?
the article mentions three types of stakeholders: contributors, debuggers and incident responders. it entirely fails to mentions consumers, who mostly care about backwards compatibility of changes, and thus about the type of a change. once the type is established, e.g. a change is breakimg, the consumer next cares about the scope to make downstream adjustments.
the part about broken promises regarding breaking changes is _kind of_ fair, but only assuming tooling isn't able to track reverts. accidental breakages occure with every approach and better to have an approximation than no information at all.
I've always wanted to do this, but can't get over the linux tty only supporting 256 colors. If I could get that higher and maybe add unicode support, I'd love to go tty only.
I agree that a `gh stack` command is not needed, but this feels to me like just a better UI feature for a good git workflow. It literally is about making multiple smaller PRs that build on top of each other.
demand for AI is not high, which is the current problem of the industry and the reason that AI companies are trying to shoehorn their technology into products everywhere.
these companies and the author of the article are trying to increase capacity for something that barely anyone wants in the software they use, which makes it all the more wasteful.
it is difficult to comprehend for me that soneone spends all this time thinking through and calculating how to harness as much energy as possible and then wants to use it for large language models instead of something useful, like food production, communication, transport or any other way of satisfying actual human material needs. what weird priorities.
I've been doing a similar thing using GhostSCAD[1], which is a relatively thin wrapper around OpenSCAD in Go. Not as typesafe, but my language of choice.
To add to the very short "valodating the result" section, let me recommend `git range-diff`.
Range diff takes two commit ranges and compares thor commits pairwise, wich is perfect for rebases, since after the rebase all commits still exist and should be mostly identical, just at some other place in the history.
Use it like `git range-diff main..origin/mybranch main..mybranch` to compare the local, rebased branch with the upstream branch.
This let's you easily verify that eitger mothing changed or that any conflicts were resolved well.
As someone who is not deep into linux desktop history: Can you please elaborate on the missing accessibility features in wayland or direct me to resources on that?
I've been using wayland for a while now and am very happy with it, but my accessibility needs are pretty basic.
The use of generative AI for art is being rightfully criticised because it steals from artists. Generative AI for source code learns from developers - who mostly publish their source with licenses that allow this.
The quality suffers in both cases and I would personally criticise generative AI in source code as well, but the ethical argument is only against profiting from artists' work eithout their consent.
That's awesome. I like the explicit nature of go and usually the verbosity is worth the benefits. But finding ways to improve upon it without losing the explicitness is great.