The GNU/Linux Corner

[KnightoftheWind]

The HQ has been lacking a proper GNU/Linux thread for too long, so I took it upon myself to create one, in the spirit of Free Software and Richard M. Stallman. Chat about your distro of choice, your triumphs, your failures, and news regarding our favorite Unix family.

I'll start: Debian is the best OS of them all, and you're a damn fool for sleeping on it!.

[Acrux]

It's a UNIX system! I know this!

[rusty_shackleford]

I use Arch, it just werks. Originally started using it eons ago because every other distro had a package manager that was slow as shit, and pacman was very fast.

[Segata]

I use Ubuntu like a good casual, kubuntu for my VM. I know how it works and I don't have to be learning new stuff, although I hate it when I upgrade and something breaks.

[KnightoftheWind]

I use Ubuntu like a good casual, kubuntu for my VM. I know how it works and I don't have to be learning new stuff, although I hate it when I upgrade and something breaks.

Ubuntu is the Windows of Linux, it just gets continually worse every year. But if you're going to use it I would recommend avoiding Snaps and Flatpaks and just stick to your package manager. Appimages are at least somewhat better because they're just files, but I've never had a good experience using Snaps and Flatpaks. They always end up breaking something eventually, and they were made to solve a problem that frankly did not exist.

[Decline]

i have a steam deck btw so i use steamos btw

Ubuntu is the Windows of Linux, it just gets continually worse every year.

Linux is the Windows of Linux.

At least its still somewhat POSIX compliant I guess and the linuxisms are generally non-retarded, at least compared to Win32-API.

Flatpaks are obviously retarded because they just duplicate what's in your native packages and a single program comes with gigabytes of cruft. And of course every little program needs its extra version of cruft. But what are you going to do when people seriously and without batting an eye make electron desktop apps? Flatpak is a retarded solution to an insane problem. Which is how I use it, as an electron containment gulag. I just backup .var/ and have a snapshot of all the insane electron crap. New computer? Just extract the backup and everything is back exactly where I left it.

AppImages are OK when they work, which is about 50% of the time, otherwise they're an unmitigated disaster.
Snap is Flatpak with the good parts removed and bad engineering slapped on top.

[KnightoftheWind]

i have a steam deck btw so i use steamos btw

Ubuntu is the Windows of Linux, it just gets continually worse every year.

Linux is the Windows of Linux.

At least its still somewhat POSIX compliant I guess and the linuxisms are generally non-retarded, at least compared to Win32-API.

Flatpaks are obviously retarded because they just duplicate what's in your native packages and a single program comes with gigabytes of cruft. And of course every little program needs its extra version of cruft. But what are you going to do when people seriously and without batting an eye make electron desktop apps? Flatpak is a retarded solution to an insane problem. Which is how I use it, as an electron containment gulag. I just backup .var/ and have a snapshot of all the insane electron crap. New computer? Just extract the backup and everything is back exactly where I left it.

AppImages are OK when they work, which is about 50% of the time, otherwise they're an unmitigated disaster.
Snap is Flatpak with the good parts removed and bad engineering slapped on top.

https://flatkill.org/

[Decline]

https://flatkill.org/

Red Had talking out of its ass, news at 11.

What that security expert autist doesn't mention is that the alternatives, including native package managers, aren't any better. And even if there was a magical PM that would solve all the security problems while still staying functional, the packaged applications would still be hot garbage on a level of magnitude above whatever package manager was used to install them. Note that 90% of the stuff he complains about is related to the apps, not the PM.

The fundamental problem is that sw development just like anything else that requires effort is decentralized by necessity and this introduces all sorts of trust issues.

[KnightoftheWind]

https://flatkill.org/

Red Had talking out of its ass, news at 11.

What that guy doesn't mention is that the alternatives, including native package managers, aren't any better. And even if there was a magical PM that would solve all the security problems while still staying functional, the packaged applications would still be hot garbage on a level of magnitude above whatever package manager was used to install them. Note that 90% of the stuff he complains about is related to the apps, not the PM.

Package managers were/are great because they're a one-stop shop for all of your applications. Nowadays developers have to play whack-a-mole with 4 different, competing standards that interfere with one another. And I particularly like Debian's package manager because everything is "guaranteed" to be more stable, especially compared to Arch where you basically CONSOOM updates until your PC eventually breaks for one reason or another. We had a great thing going with .deb files too, until Snappies/Flatties came along and threw a monkey wrench on the whole thing.

[Decline]

https://flatkill.org/

Red Had talking out of its ass, news at 11.

What that guy doesn't mention is that the alternatives, including native package managers, aren't any better. And even if there was a magical PM that would solve all the security problems while still staying functional, the packaged applications would still be hot garbage on a level of magnitude above whatever package manager was used to install them. Note that 90% of the stuff he complains about is related to the apps, not the PM.

Package managers were/are great because they're a one-stop shop for all of your applications. Nowadays developers have to play whack-a-mole with 4 different, competing standards that interfere with one another. And I particularly like Debian's package manager because everything is "guaranteed" to be more stable, especially compared to Arch where you basically CONSOOM updates until your PC eventually breaks for one reason or another. We had a great thing going with .deb files too, until Snappies/Flatties came along and threw a monkey wrench on the whole thing.

So, this flatpak stuff does exist because there is a very good reason for it: Handing control to the developer. The native package management found on Linux is egalitarian in these sense that all packages are treated equal. Which is simply not the case. In reality, apps that users install on their computer to interface with it are way more important than some obscure library dependency of that app. Those apps get all the exposure and therefore all the bug reports, including those of its ocean of dependencies.

In the egalitarian model of native package managers, any component of that dependency ocean can change at any time and introduce unpredictable issues. This becomes especially tiresome if you are so unfortunate to maintain an electron app, with hundreds of dependencies. No, native package managers do not guarantee that everything is stable. Debian is especially egregious in that regard because Debian's decentralized culture leads to years old outdated packages that often lead "fun" bug reports on your issue tracker.

This is why these news package managers are all app centric. The app's maintainer describes exactly what version he wants of what dependency and because its all packaged independently from app to app, he knows what is running on your system and there are no surprises. Of course, this comes at the cost of extra disk space, but disk space is cheap these days.

[KnightoftheWind]

Red Had talking out of its ass, news at 11.

What that guy doesn't mention is that the alternatives, including native package managers, aren't any better. And even if there was a magical PM that would solve all the security problems while still staying functional, the packaged applications would still be hot garbage on a level of magnitude above whatever package manager was used to install them. Note that 90% of the stuff he complains about is related to the apps, not the PM.

Package managers were/are great because they're a one-stop shop for all of your applications. Nowadays developers have to play whack-a-mole with 4 different, competing standards that interfere with one another. And I particularly like Debian's package manager because everything is "guaranteed" to be more stable, especially compared to Arch where you basically CONSOOM updates until your PC eventually breaks for one reason or another. We had a great thing going with .deb files too, until Snappies/Flatties came along and threw a monkey wrench on the whole thing.

So, this flatpak stuff does exist because there is a very good reason for it: Handing control to the developer. The native package management found on Linux is egalitarian in these sense that all packages are treated equal. Which is simply not the case. In reality, apps that users install on their computer to interface with it are way more important than some obscure library dependency of that app. Those apps get all the exposure and therefore all the bug reports, including those of its ocean of dependencies.

In the egalitarian model of native package managers, any component of that dependency ocean can change at any time and introduce unpredictable issues. This becomes especially tiresome if you are so unfortunate to maintain an electron app, with hundreds of dependencies. No, native package managers do not guarantee that everything is stable. Debian is especially egregious in that regard because Debian's decentralized culture leads to years old outdated packages that often lead "fun" bug reports on your issue tracker.

This is why these news package managers are all app centric. The app's maintainer describes exactly what version he wants of what dependency and because its all packaged independently from app to app, he knows what is running on your system and there are no surprises. Of course, this comes at the cost of extra disk space, but disk space is cheap these days.

I think the bigger problem here is using Electron for your "app". Obviously soydevs are not going to like using the native package managers for their software.

[Decline]

Package managers were/are great because they're a one-stop shop for all of your applications. Nowadays developers have to play whack-a-mole with 4 different, competing standards that interfere with one another. And I particularly like Debian's package manager because everything is "guaranteed" to be more stable, especially compared to Arch where you basically CONSOOM updates until your PC eventually breaks for one reason or another. We had a great thing going with .deb files too, until Snappies/Flatties came along and threw a monkey wrench on the whole thing.

So, this flatpak stuff does exist because there is a very good reason for it: Handing control to the developer. The native package management found on Linux is egalitarian in these sense that all packages are treated equal. Which is simply not the case. In reality, apps that users install on their computer to interface with it are way more important than some obscure library dependency of that app. Those apps get all the exposure and therefore all the bug reports, including those of its ocean of dependencies.

In the egalitarian model of native package managers, any component of that dependency ocean can change at any time and introduce unpredictable issues. This becomes especially tiresome if you are so unfortunate to maintain an electron app, with hundreds of dependencies. No, native package managers do not guarantee that everything is stable. Debian is especially egregious in that regard because Debian's decentralized culture leads to years old outdated packages that often lead "fun" bug reports on your issue tracker.

This is why these news package managers are all app centric. The app's maintainer describes exactly what version he wants of what dependency and because its all packaged independently from app to app, he knows what is running on your system and there are no surprises. Of course, this comes at the cost of extra disk space, but disk space is cheap these days.

I think the bigger problem here is using Electron for your "app". Obviously soydevs are not going to like using the native package managers for their software.

Electron soy is just the point where you have to give up and invent AppImage. The issue would still exist without Electron though.

[KnightoftheWind]

So, this flatpak stuff does exist because there is a very good reason for it: Handing control to the developer. The native package management found on Linux is egalitarian in these sense that all packages are treated equal. Which is simply not the case. In reality, apps that users install on their computer to interface with it are way more important than some obscure library dependency of that app. Those apps get all the exposure and therefore all the bug reports, including those of its ocean of dependencies.

In the egalitarian model of native package managers, any component of that dependency ocean can change at any time and introduce unpredictable issues. This becomes especially tiresome if you are so unfortunate to maintain an electron app, with hundreds of dependencies. No, native package managers do not guarantee that everything is stable. Debian is especially egregious in that regard because Debian's decentralized culture leads to years old outdated packages that often lead "fun" bug reports on your issue tracker.

This is why these news package managers are all app centric. The app's maintainer describes exactly what version he wants of what dependency and because its all packaged independently from app to app, he knows what is running on your system and there are no surprises. Of course, this comes at the cost of extra disk space, but disk space is cheap these days.

I think the bigger problem here is using Electron for your "app". Obviously soydevs are not going to like using the native package managers for their software.

Electron soy is just the point where you have to give up and invent AppImage. The issue would still exist without Electron though.

Despite the concerns related to Arch, the AUR is well-regarded for it's breadth of software and ease of use. It has that going for it, and for those who enjoy using Arch-based distributions I've heard nothing but good things about it. Package managers are very useful and objectively superior to Snaps and Flats. Appimages I will say are a decent compromise for those who need more of a sandbox, but it's not ideal, and software that is well designed doesn't need to be sandboxed. The less dependencies you have the more long-term your program will be. The issue here is soydevery and software bloat, not package managers. I will stand by that.

[Lutte]

I don't like how flatpak imposes restrictions that just break many programs (for eg, if you try to install a browser in it, it won't be able to communicate with a password manager. Wow, so useful.) but it WAS invented to fix a REAL problem. Most developers would appreciate being able to release software and have it work on linux without waiting for packagers to package their software, without dependencies that will silently break and end up causing wrong bug reports etc. But on linux this is close to impossible because most library developers have a stick up their arse and refuse to, once and for all, set up stable ABIs and APIs. While the kernel may have stable ABIs when it comes to user-space software, this isn't nearly enough.

https://www.gamingonlinux.com/2022/08/v ... -on-linux/

Even the most basic building block of software, the standard C library, is happy to break things after updates.

This is why something like flatpak is desired and desirable. As a developer, you release something there with frozen dependencies and it work, and it doesn't have the taint of package managers touching your software.
You mentioned being a debian user, well, packagers are people who are happy to patch software they do not understand.
Like this :
https://www.schneier.com/blog/archives/ ... ber_b.html
Causing ssh keys generated with their beautiful patch to not actually be all that random.
The model of third parties touching your software without understanding your code base is wrong to begin with.

win32, by the way, isn't a beautiful API, but it's a stable building block and it works, and it's why gaming on linux can become a thing. Native linux gaming will never ever be a thing again, people who have ported to linux know making frozen, proprietary software for it is a major pain in the butt, and Proton provides a stable, fixed target that will work until the end of times, which is not the case of anything native. I legitimately welcome game developers to NEVER release anything native on linux because that is far more painful to deal with than programs that are tested against proton. If you're a game dev who wants to care about linux, please just test against proton, and fix your software to use apis that work well on proton if it doesn't, but don't try to make native builds. Native builds are for suckers.

[KnightoftheWind]

I keep my PC as clean and minimal as possible, including the use of suckless programs. I would even switch from GNOME to something more lightweight but I enjoy the look and feel of it, therefore it remains. I'd imagine if your software is reliant on dozens of dependencies, then package managers may present a problem for you. But so long as you code in C (not C++), using open standards as much as possible, then you should never experience a problem. Flatpaks are attempting to Windows and Mac-ify the GNU/Linux ecosystem, not everything needs to be sandboxed and bloated to hell just so devs can make crap software in peace.

If you're a Linux user, you should not be using it with the mindset of "Oh, I want to use Photoshop and install Wine and use Steam!". Linux is fundamentally different, therefore the Windows-style of game development should never apply.

[Lutte]

not everything needs to be sandboxed

I don't care one iota about the sandboxing part of flatpaks and snaps (which is broken to boot).
What I care is that software should not have moving dependencies underneath them.

I'd imagine if your software is reliant on dozens of dependencies, then package managers may present a problem for you.

Have you read my post? Even the glibc, the most basic building block that almost all C programs depend on, can break your software after updates. It's not a problem of having too many dependencies, it's a problem that ALL dependencies are unreliable trash.

[Lutte]

If you're a Linux user, you should not be using it with the mindset of "Oh, I want to use Photoshop and install Wine and use Steam!". Linux is fundamentally different, therefore the Windows-style of game development should never apply.

Even Linus Torvalds disagrees with you. At debconf 2014 he stated that "valve will save the linux desktop" because he and many other bright minds working on the kernel considers the way user-space is developed to be cancer incarnate.
"if you're a linux user you should tolerate retardation" no.



The whole thing is worth a watch.

[Decline]

I think the bigger problem here is using Electron for your "app". Obviously soydevs are not going to like using the native package managers for their software.

Electron soy is just the point where you have to give up and invent AppImage. The issue would still exist without Electron though.

Despite the concerns related to Arch, the AUR is well-regarded for it's breadth of software and ease of use. It has that going for it, and for those who enjoy using Arch-based distributions I've heard nothing but good things about it. Package managers are very useful and objectively superior to Snaps and Flats. Appimages I will say are a decent compromise for those who need more of a sandbox, but it's not ideal, and software that is well designed doesn't need to be sandboxed. The less dependencies you have the more long-term your program will be. The issue here is soydevery and software bloat, not package managers. I will stand by that.

Soydevery is also just a consequence of the way we develop software. Electron/NPM just drives this over the top so it becomes a comical farce.

But for any non-trivial program you must ask the question 'Do I copy/paste from stack overflow, do i reinvent the wheel myself or do I pull from (trust) extern?' And that is a very tough question to answer, because none of the answers is correct. You have to evaluate what is the least worst answer depending on your specific problem for each problem. The latter can safe you a lot of time, at least during initial creation.

Then we live in an era where adding a new dependency to your project is very cheap, thanks to internet and tooling around it. So many developers will commit to soy out of necessity.

I skipped over your remarks about the objective superiority of native package managers, because they're just nonsensical marketing blurb.

If you're a Linux user, you should not be using it with the mindset of "Oh, I want to use Photoshop and install Wine and use Steam!". Linux is fundamentally different, therefore the Windows-style of game development should never apply.

> If you use Linux you shouldn't use software.

[KnightoftheWind]

I'm not saying something will never break, but you can MINIMIZE the risks by not filling up your software up with bloat, needless dependencies, and forced updates. Making Linux like Windows is not a triumph, it's stupidity plain and simple. Who cares if proprietary bloatware isn't as reliable on Linux in the long term?, I consider that a feature not a bug. Linus Torvalds is known for having many bad takes, and that is one of them.

Steam Proton only ensures the continued survival of Windows and the reliance on it, therefore it's cancer. The solution to your problem is simply to update less. Stick with what you already have and what you know works. There is not one use-case scenario for me, as an end-user, where Flatpaks or Snaps are even remotely desirable or useful.

[Lutte]

Electron soy is just the point where you have to give up and invent AppImage. The issue would still exist without Electron though.

Despite the concerns related to Arch, the AUR is well-regarded for it's breadth of software and ease of use. It has that going for it, and for those who enjoy using Arch-based distributions I've heard nothing but good things about it. Package managers are very useful and objectively superior to Snaps and Flats. Appimages I will say are a decent compromise for those who need more of a sandbox, but it's not ideal, and software that is well designed doesn't need to be sandboxed. The less dependencies you have the more long-term your program will be. The issue here is soydevery and software bloat, not package managers. I will stand by that.

Soydevery is also just a consequence of the way we develop software. Electron/NPM just drives this over the top so it becomes a comical farce.

But for any non-trivial program you must ask the question 'Do I copy/paste from stack overflow, do i reinvent the wheel myself or do I pull from (trust) extern?' And that is a very tough question to answer, because none of the answers is correct. You have to evaluate what is the least worst answer depending on your specific problem for each problem. The latter can safe you a lot of time, at least during initial creation.

Then we live in an era where adding a new dependency to your project is very cheap, thanks to internet and tooling around it. So many developers will commit to soy out of necessity.

I skipped over your remarks about the objective superiority of native package managers, because they're just nonsensical marketing blurb.

I agree with most of this, but with an addendum: there's a difference between not reinventing the wheel and importing large libraries and frameworks that do a great deal of things well, and importing a trillion of tiny libraries that barely do anything individually. The electron/javascript/ world of software development has gone totally nuts.

Something as simple as this :
https://qz.com/646467/how-one-programme ... ce-of-code
Should never have been a dependency. It's literally just one function, a simple one that anyone can write themselves. Yet it broke a large amount of stuff retarded javascript developers use because it was a dependency for so many things.

Obviously if you want, say, to make a native GUI, you'll import libraries like Qt or GTK, if you want to do web development, it would be smart to at least use something lightweight like flask, or a full fledged environment like django depending on your needs, nobody has the time to reinvent all the wheels. But importing a library that has just a few utility functions? lol no sod off.

People who despise electron app devs are right to despise them. They are a tumor upon the world of software development. Front end web devs are also gigantically retarded.

[KnightoftheWind]

If you're a Linux user, you should not be using it with the mindset of "Oh, I want to use Photoshop and install Wine and use Steam!". Linux is fundamentally different, therefore the Windows-style of game development should never apply.

> If you use Linux you shouldn't use software.

Is that supposed to be funny?. Why install Linux with the expectation of using Windows apps?, that's a recipe for frustration plain and simple.

[Decline]

there's a difference between not reinventing the wheel and importing large libraries and frameworks that do a great deal of things well, and importing a trillion of tiny libraries that barely do anything individually.

Of course. The C/C++ approach of simply not having dependency management forces you to condense your requirements. But even then you will end up writing your inhouse dependency management eventually and the development thereof as well as handling the dependencies itself will cost you a ton of time.

Then you have the new-age system programming languages like rust and go that implement dependency management and you save a lot of time but end up with electron soy all over again.

Its an unsolved, perhaps unsolvable, hard problem. In my opinion soydevery is here to stay, because that's clearly what most developers require.

[Lutte]

No, actually, Go did solve the problem. It's a mediocre language but as a platform they did everything right. It has version pining for dependencies, the dependencies are cached by google's mirrors (so if something like github is down you can still download and build against deps) and the language disallows dynamic linking for libraries written in the Go language (it still dynamically links against C deps, there is no choice there as some like the glibc behave erratically when statically linked).

Anything written in pure Go builds into a beautiful singular binary that you can just copy over any linux distro and works out of the box. This is why I have a particular fondness for small utilities written in Go.
Go's designers have immensely high quality taste when it comes to their view on how to build a platform.

[KnightoftheWind]

Automated updates are a huge problem that is rarely addressed in the software world. Nowadays it's automated a lot of time, and is called "auto update" as a result. But what I deem "update culture" encompasses more than this, it's the whole mentality of having to constantly update one's software, hardware and other products. It is similar to CONSOOMERISM but more about constant modifications masked as "cool updates" rather than replacement of physical products. A typical example are web browsers, or proprietary operating systems, like Windows and Mac.

Update culture is however not limited to computers or technology. It is the mindset of wider society being applied to software, we see it in things such as fashion, business, gossip, watching the news every day, browsing social media or constantly changing laws, it is the acceptance and approval of living in a constant stress of having to extort extreme amounts of energy just to keep up with artificially made up crap, to race against oneself and others in a never ending artificially sustained race with no winners, just with extremely exhausted participants. The current system of law requires constant everyday maintenance that's extremely costly, law needs to be constantly remade and rewritten to reflect any emerging trend in society because it is so unbelievably complex and tries to encompass every single aspect of our society. And ironically all of those changes are lost to time and even the bureaucrats forget about it,.

Software updates are usually justified by "muh security" and "muh modern features". Users who want to avoid these updates or simply can't install them, e.g. due to using old incompatible hardware or missing dependency packages, are ridiculed as poor idiots, and their suffering is ignored. In fact, update culture is cancer because:

1. It is a form of software consumerism, even if the updates themselves are gratis, they always come at a cost such as potential instability, requiring new hardware, forcing installing more dependencies, required learning to use the new version, or even dropping of old features and malicious code in the updates.

2. It is dangerous, updates regularly break things, and there are cases where a lot depends on software running smoothly. This can indeed effect software downloaded through package managers.

3. It is fruitless effort, wasting manpower and time and creating an intentionally high maintenance cost. Men, both users and programmers, ultimately become slaves to the software.

4. The security justifications are lies: a true concern for security would lead to unbloating and creating a minimal, stable and well tested software. Update culture in fact constantly pushes newly
created vulnerabilities with the updates which are only better in not having been discovered yet, i.e. relying on security by obscurity. This creates an intentionally endless cycle of creating something that will never be finished (even if it well could be).

5. It kills user freedom. With the example of web browsers, the constant meaningless updates of JavaScript and addition of "features" eliminates any small competition that can't afford to keep up with the constantly changing environment. This is why we have no good web browsers.

6. It is a huge security risk. The developer, whoever it is, has the power to remotely push and execute any code at any time to the devices of many users. In fact this can be seen as the definition of a backdoor. This is not just an issue of proprietary software either, there have been many Free Software projects pushing malware this way.

[Decline]

No, actually, Go did solve the problem. It's a mediocre language but as a platform they did everything right. It has version pining for dependencies, the dependencies are cached by google's mirrors (so if something like github is down you can still download and build against deps) and the language disallows dynamic linking for libraries written in the Go language (it still dynamically links against C deps, there is no choice there as some like the glibc behave erratically when statically linked).

Anything written in pure Go builds into a beautiful singular binary that you can just copy over any linux distro and works out of the box. This is why I have a particular fondness for small utilities written in Go.
Go's designers have immensely high quality taste when it comes to their view on how to build a platform.

I am well aware of the advantages of Go and the static-linkage-by-default certainly helps in cushioning the soy when the upstream maintainer suddenly disappears/does strange things. But I wouldn't go so far and call it solved.
And yes, Go devs generally are certainly more into Unix philosophy/sane principles than your average JS-Soylover. But this shows that soydevery is mostly a cultural problem than is less about the tools and more about their users.

Lets put it like this: There is nothing wrong with NPM as long as the user actually knows what he is doing.

[Lutte]

@KnightoftheWind
What you say is related to what I was speaking about when it comes to the lack of stability of the building blocks on linux.

JWZ once succinctly commented on this phenomenon well with a nice acronym: CADT.
https://www.jwz.org/doc/cadt.html

In February 2003, a bunch of the outstanding bugs I'd reported against various GNOME programs over the previous couple of years were all closed as follows:

Because of the release of GNOME 2.0 and 2.2, and the lack of interest in maintainership of GNOME 1.4, the gnome-core product is being closed. If you feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component. Thanks...
This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.

I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short.

It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?

But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.

[Goth-Girl-Supremacy]

Saeci knows more about Linux than Lutte will ever know about anything.

You should ask Saeci anything Linux-related instead of taking anything this Wikipedia'ing annamite says at face value.

[Segata]

You should ask Saeci anything Linux-related instead of taking anything this Wikipedia'ing annamite says at face value.

Why would we go to the codex to ask him?

[Goth-Girl-Supremacy]

Because you'll be talking to someone that actually uses Linux instead of someone that pretends they use Linux.

[Red7]

I use Ubuntu like a good casual, kubuntu for my VM. I know how it works and I don't have to be learning new stuff, although I hate it when I upgrade and something breaks.

Ubuntu is the Windows of Linux, it just gets continually worse every year. But if you're going to use it I would recommend avoiding Snaps and Flatpaks and just stick to your package manager. Appimages are at least somewhat better because they're just files, but I've never had a good experience using Snaps and Flatpaks. They always end up breaking something eventually, and they were made to solve a problem that frankly did not exist.

i read ubuntu is like win10+ of linux, pure spyware cancer.