

Oh yeah, for sure, but they do mean generative AI in this case, because it’s the hype du jour.


Oh yeah, for sure, but they do mean generative AI in this case, because it’s the hype du jour.


Yeah, I find it difficult, too, especially since management hasn’t caught onto this yet and still wants me to specialize.
And of course, the answer is that I should specialize in AI, because there’s currently a lot of new development happening there. But that knowledge is also getting obsolete by the minute, with ever more tools coming out and then again other tools that operate those tools for you.
The one thing I hold onto, is that no matter how the situation evolves, the basic job requirements for software engineering, i.e. being smart and being able to learn quickly, will always be an advantage.
I don’t think it’s possible to hold onto the confort zone from before, even if the industry implodes from the AI costs becoming transparent. But yeah, I do think we’ll land on our feet in one way or another.
Gradle uses Groovy or Kotlin for its DSL, though…
I had to start reading that three times over, because I saw they mentioned “Canadian” and just assumed the angle brackets are a joke in reference to the Canadians in South Park:



A bucket of bytes. 🙃
Also worth mentioning that universities generally see themselves as research facilities first and foremost. They teach students, because they want to get the next generation of researchers.
Sure, they’ll also do job training to some degree, because it’s a good argument to get more funding, but yeah, just not their primary goal.


Das Krebsrisiko, was von HPV ausgeht, wird um so viel gesenkt. Nicht das allgemeine Krebsrisiko.
Falls jemand bisher nur den Titel gelesen hat…
Jo, so wie auch so Motorsensen nochmal deutlich nerviger als Rasenmäher sind…


You’re right that there is a risk, that rebasing introduces compile errors or even subtle breakages. The thing is, version control works best, if you keep the number of different versions to a minimum. That means merging back as soon as possible. And rebases simultaneously help with that, but also definitely work best when doing that.
There may be reasons why you cannot merge back quickly, typically organizational reasons why your devs can’t establish close-knit communication to avoid conflicts that way, or just not enough automation in testing. In that case, merges may be the right choice.
But I will always encourage folks to merge back as soon as possible, and if you can bring down the lifetime of feature branches (or ideally eliminate them entirely), then rebases are unlikely to introduces unintended changes and speed you up quite a bit.


I don’t work with merges, so maybe I’m way off base, but I thought they meant, they’re working on another branch or fork, then merging the base branch into theirs every so often to get the newest changes, and then that creates multiple merge commits, which they can’t squash at the end…?
I’m not sure, about that last part, but the rest, I’ve definitely seen with contributors that didn’t know to work with rebases (and unfortunately we’re on GitHub, which only half-assedly supports working with rebases by default).


You might prefer working with rebases + fast-forward-only merges, if you want merge commits to be squashed…
(As in, there won’t be any merge commits. Your PR will look as if you forked, then coded real fast, and then opened the PR before anyone else pushed anything.)


Personally, I found it worth playing around with. I cared less than I thought where I had to move my eyeballs to, once I didn’t have to make the decision anymore.
And automatic tiling can also enable workflows that just don’t make sense with manual tiling, for example master-stack-layout where basically one window takes up half the screen and the other windows share the other half, and then you swap out which one’s the big window as you see fit.
But I also wouldn’t have written all that, if I didn’t have a way that you can easily try it out: You can add automatic tiling into KDE Plasma via Kwinscripts. Personally, I’m using Krohnkite: https://store.kde.org/p/2144146
(Easiest to install by going through the System Settings…)
I live in the year 2026, I’m pretty sure, and this still made so little sense to me, that I assumed they meant “hacking a water fountain” as in hitting it with an axe.
Kind of not surprising with the ruling a year or so ago, where Air Canada had to follow through on what its AI chatbot had told a customer.
Well, and I guess, due to basic logic. Any other webpage has to take responsibility for the content they publish, whether it is written by a human or by an LLM. There’s no good reason why Google should be treated differently here.
Still an interesting development, though. There’s no guaranteed way to make an LLM not say something. I guess, what they could do, is to run a regular script over the output before it’s displayed and then, for example, just not display anything, if those publishers’ names show up in the output.