@Liam Dawe

could you show us a

 
inxi -Fazy 

instead so that we have the full picture, or is it not pre-installed? :smile:

View this comment - View article - View full comments

Quoting: mphuZKernel 5.13? Why is it so old? After all, they said that 5.15 had already been installed.

Because Liam said:

Valve were kind enough to ship GamingOnLinux a review unit — here’s my own initial thoughts after spending a couple weeks with it.

which means most probably he got the same version everyone got before him.

View this comment - View article - View full comments

Quoting: jensDoes anybody knows what gave the push for KDE? (I’m just genuine interested in Valves thoughts and reasonings)

No, but it makes perfect sense.

View this comment - View article - View full comments

well it was a shame Croteam gave their loyal Linux fan base (+Vulkan) the middlefinger with SS4 and this, ever since AlenL left the company to join Google Stadia or what was it. SS4 ran horribly or not at all with Proton despite 10 engine + proton hacks combination and people also heavily complained about stuttering and bad performance issues since the beginning that were never fixed, so I made my choice ever since not supporting Croteam in the slightest anymore. Buying SS4 only because I was a loyal fan and out of good faith that they would eventually care to bring out the Linux version after some time was a big mistake.

View this comment - View article - View full comments

Quoting: SamsaiI highly doubt

well you can highly doubt anything, but the fundamental reason for Arch being a simpler, faster and less dependency-hell-prone distribution are those 2 simple facts, as stated here

In Arch Linux, partial upgrades are unsupported and only a single version of each shared library [is] in the official repositories, in contrast to other (non-rolling-release) distros.

This simple rule avoids (for the most part) the intractable issue that dependency hell is NP-complete [External Link]. Maintaining metadata for complex version resolution has the effect that Linux package managers are slow (2019) [External Link].

https://bbs.archlinux.org/viewtopic.php?pid=1956215#p1956215 [External Link]
, the rest like the package manager, the simpler packaging, take advantage of those principles, leading to more efficient code with much less needs and to a faster, cleaner system.
You can find more material with details on the internet.

Quoting: Samsai

Quoting: sudoerIMO, instead of hand-holding Linux users with untransparent/dark noob-friendliness, all it takes is to educate the user how to maintain his system, which in the case of Arch is super easy if you take some time to read it.

I have a feeling that regular computer users aren't going to read the manual from cover to cover to learn how to maintain their system. No matter how much fun Arch/Gentoo users seem to have doing it, I don't think it's the way forward for general adoption.

Regular computer users -you mean Windows users...- will break their systems no matter how many flatpaks they will use, and will continue to feel helpless when they will try to access their file system to find their file from another drive, while the flatpak will be showing them its own cut from the rest filesystem.

It's better to tell them 2 simple things to do to maintain their systems and let them use the latest native software, than creating helpless users left in the dark and having a holy cluster-mess of new each time holy-grail universal packages added to the already available ones. Mind that they are already staying in the dark with MS Windows, with the difference that it works.

View this comment - View article - View full comments

^^ That is what a true rolling release is, and that is how you avoid dependency hell once and for good. Desktop Linux is constantly evolving and moving forward, and this is the right approach.
Servers on the other hand based on prehistoric libraries and kernels can use flatpaks, snaps, appimages, whatever they desire to "patch" their fundamental problem. Those package formats were developed for servers in the first place if I remember correctly.

View this comment - View article - View full comments

Quoting: Purple Library GuyI don't think it's plausible that the difference is between "rolling" distros and distros with discrete releases. All that "rolling" means is that what you have is a snapshot of current development, it has no implications for dependency hell--or, if it does, the implication would be that some of the time, changes may have been made in different areas and not cleaned up before a "release" (because it's always live, there is no release) which might cause dependency problems.

No, the secret is in the libraries, check the 2 points here [External Link].

Therefore, pacman is faster and what appears to be as "superior" from the rest, by not having to calculate millions of breaking possibilities.

And furthermore, the AUR is such a good system which contains all the scripts for the user to build the software, always against the newest libraries! Plus it has ONE version, not 20 different PPAs with prebuild binaries, 10 different OBS places with incompatible/dummy-packages and whatever.

IMO, instead of hand-holding Linux users with untransparent/dark noob-friendliness, all it takes is to educate the user how to maintain his system, which in the case of Arch is super easy if you take some time to read it.

see: https://www.youtube.com/watch?v=rmXNLK3pWko&t=1644s [External Link]

View this comment - View article - View full comments

Flatpak is the future for stale distros still living in the '90s. For rolling distros (which IS the future) it's useless and stupid.

Switch to a rolling distro and you will never have dependency hell issues again, nor bloat your system with disputable package formats. Having a big amount of different flatpaks can also lead (internaly) to dependency hell.

View this comment - View article - View full comments

Quoting: CyborgZetaGood. I want to see more Flatpak adoption.

Me not at all. https://ludocode.com/blog/flatpak-is-not-the-future [External Link]

View this comment - View article - View full comments

Well many analysts and not only have predicted from the first very moment Epic started throwing trucks of (chinese) money in order to cannibalize the market that this would kill smaller stores sooner or later. Remember Swiney officialy told the court that they are expecting to see profits in 2024... remains to be seen if that will be proven right, all those years they are at loss, building armies of angry Fortnite teenagers while making ridiculous claims and being hypocritical. They are not competing head to head, despite them having tons of $ more than anyone else, sorry, they are just cannibalizing. It's the same thing M$ did reaching 95% userbase, that 95% is not a product of competition, we all know how they reached that %, from the days of CP/M 'til latest ".NET open-source" incident.

View this comment - View article - View full comments