So it begins. We are past the unlimited money stage and now the cuts begin to make AI somewhat profitable.

Expect more of that in the coming months.

But it’s only white space. That’s kinda racist.

I have a Quest 2 and tried to get it to run wired with Steam Link. I spent about an hour or two so far, trying to get it setup, but so far it doesn’t show up on Steam Link.

From what I have read it should be possible to get it working, but apparently it’s not as easy as on Windows, where it’s really plug and play.

That said, PCVR is not a high priority for me, hence I haven’t spent a lot of effort getting it running.

Deploy broken code straight to prod?

Sounds like you are having trouble with English. I don’t really understand what you are asking and judging by the comments of the others here I am not alone with that.

Maybe run your question through Google Translate or an LLM and post the result here so that we have a chance to actually understand what you are talking about.

Means he’s unemployed. “Living at the edge of his benefits check”

In this context, YAGNI is a very good principle, because incidentally, working too much ahead to avoid technical debt can actually cause technical debt.

The writer made the whole essay because saying “just ask your engineers what they need to improve” wouldn’t make him money.

I wonder if the writer ever worked as an engineer.

Tech debt is a term directed at managers to convince them to not always go for the quickest and dirtiest hack.

It’s not a term that’s ever meant to describe anything to an engineer.

Technical debt is a management term.

The reason we use it is to tell non-technical management people why implementing a simple feature might take an hour on a fresh project and a week on an old legacy project.

It’s used to tell them why we shouldn’t go with the quickest and dirtiest solution but instead should go with a more expensive proper solution.

It also tells management why we might have to spend some time imrpoving our code base without any tangible improvements to the customer.

And because it’s a term that speaks to non-technical management it uses financial language, becausee that’s what they understand. Technical debt means “I am choosing to cut corners today, but we will have to pay up in the future by fixing stuff that wouldn’t be broken if we do it right today.”

And because it’s aimed towards non-technical management and not towards developers, it’s of course not very specific. Non-technical management doesn’t need to understand about dependency hell, unclean code or bad developer documentation. That’s not their field and it doesn’t have to be.

The real problem in OOPs example wasn’t that there’s no clear metric or definition of technical debt. The problem was that non-technical managemnt thought that technical debt is an engineering concept instead of a management one, and thought that they themselves were allowed to meddle with it.

The right way to handle that is to ask the people who are actually impacted by technical debt what they want to improve. Any developer can quickly give you a good list of the most pressing tech debt issues in their code base. No need to pull in someone from outside of the project to make up some useless KPIs that will end up missing critical topics.

Btw, engineers already have engineering terms for what’s described as technical debt. E.g. “dependency hell”, “low test coverage”, “outdated dependency”, “bad code style”, “unoptimized code” and so on. And since these are engineering terms, they actually have specific meanings and most of them are testable and quantifiable in some specific way.

As lower/middle management, you are crushed from both sides. Upper management demands from you what to do, and the people under you hate what you are forced to implement. It’s actually really annoying and difficult. I was department lead and went back to just developing.

It’s immutable Fedora. Immutability is something that not even regular Fedora uses, because it causes weirdness and potential trouble if you don’t just use it as a wrapper for flatpak.

This.

The only point of brazzite is that you don’t have to spend hours setting up, configuring and debugging. If that doesn’t work, there is no point in using brazzite.

That’s the issue though. When everything works it’s great. But it’s so easy to bungle something up (be it user error or bugs in distros).

I’m running a 4070. Performance is really nice. Modern games pinned at vsync speed of 144FPS. The next day I’m down to 0.2FPS. Stays like that for a few days. Reboots don’t help. Can’t find anything debugging or googleing. After a few days it’s back up.

Turns out, I run games through heroic installed via flatpak, and flatpak keeps its own copy of Nvidia drivers. That version needs to be perfectly in sync with the system driver version. So dnf update breaks that and the games fall back to CPU rendering, and flatpak update plus reboot fixes it again. Running flatpak update first followed by dnf update makes sure performance always sucks.

Took me a very long time to figure that out, and I imagine someone without an IT background might never figure that out.

Apart from if they are going to use their PC for anything else than gaming.

Fair point about /c/linux_gaming. OPs question wasn’t really about gaming though and it was specifically about ubuntu/kubuntu.

So if anything, the OP should not have been in /c/linux_gaming, but the answers are on topic.

But even in regards to gaming, Mesa drivers are stable enough nowadays that even a bit outdated ones don’t make a lot of tangible difference unless you are hunting for every last frame. In which case a beginner’s distro isn’t for you anyway.

The average casual gamer will have no issues with Ubuntu.

Yes, but if there’s a guide on how to use some software with a Linux distro, there’s always a guide for Ubuntu and often nothing else. I can’t remember if I have ever seen a guide for 3rd party software for Brazzite.

That’s ok for someone who either does nothing or is advanced enough to adapt the guide to their OS, but for anyone between these extremes it’s a major downside.

These hoops don’t matter for beginners. They are usually fine with what Ubuntu provides, or more to the point, don’t even know what they might be missing.

Steam Survey is quite skewed by only showing what gamers use. That’s quite a hefty selection bias, and of course it shows that gamers prefer the Steam Deck and gaming distros.

The distro itself is fine for beginners. But the main advantage of Ubuntu over e.g. Linux Mint or Brazzite or any of the other beginner distros is that if e.g. third-party software has a guide on how to use it on Linux it’s almost always about Ubuntu. That is the real advantage of Ubuntu. Kubuntu doesn’t have that.

*buntu are mainly beginner distros. They work fine out of the box, but many long-term users don’t like them for ideological reasons.

The main advantage of Ubuntu over any other distro is that everything as an Ubuntu guide. The same is not true for Kubuntu, and if you stay in GUI, Ubuntu and Kubuntu share almost no similarities. The settings, the pre-installed default apps, all that differs greatly.

Thus the main reason for using *butnu is gone when using anything else than Ubuntu.

Which kinda sucks, because I like KDE much more.