I’d recommend Zorin. It has a UI similar to windows, easy to get into, great defaults, and being based on Ubuntu, most help on the internet will work just fine
I game, like a lot, and if windows beats me one more time i swear I’ll leave them for good. Is there a list of supported games? I just hit their site and only saw an nvidia gpx drivers too, did i simple miss the AMD stuff?
Intel and AMD drivers are part of the Linux kernel so you never need to think about drivers.
Check out https://www.protondb.com/ for something of a list of supported games, but generally most games just work (in Steam, go to Settings, Compatibility, and check the box for applying Proton on all games in library and not just the officially supported ones).
ProtonDB isn’t a complete list, but if you do struggle with getting a game to work, chances are somebody has posted a string you can paste into Steam to make the game magically work.
to add on to this, generally the only games that have issues are games with pretty serious anti cheat, and even many of those will still work. protondb will reflect this of course, but if you already know you mostly only play single player or cooperative titles, you can save a lot of time looking through your library
I appreciate what glorious eggroll does. And I’ve had no issues with the few games I’ve played on Steam.
I’ve been running Nobara for several months and it has been very stable though I find it is lacking a little polish around the edges in some areas. Kind of like how Mint was when I first started about 10y ago.
I’m trying out Fedora now for a while. On kernel 6.5. I was on 6.1 in Nobara. I have one game that’s crashing now (it wasn’t crashing in Nobara … go figure). So I may have to go back to Nobara or try to figure out what they did with Nobara vs Fedora that would help.
When Mint gets to kernel 6.x some day, I might jump back. (5.19 doesn’t support my GPU). Overall Mint became very polished. I hardly ever ran into weird issues. Although I do remember feeling Cinnamon blew up every so often.
Not sure if it’s still the same as it was back in my day, but KDE’s “release candidate” nomenclature was always a bit of a misnomer. You’d never see RC1 actually released as final. What it really means is that the alpha “feature refinement” beta “bug fixing” phase is over, and it’s the final testing phase for showstoppers. However, the definition of showstopper seemed always to be very wide. Thus, a lot of bugs still get reported and fixed during this phase, and RC really means “beta, but towards the end of the pipeline”.
Which is in contrast to the Linux kernel where a RC can be declared ship-ready and simply get renamed.
Admittedly there’s a fairly large impact difference between kernel level bugs, and say a bug in Okular…
The nomenclature is actually correct here, and a lot of other software use it, at least from everything I’ve seen. Release candidate means it’s stable and (usually) feature complete but could have bugs and needs testing before they launch it.
It’s still a misuse of the word - if your software needs testing it’s not a candidate you would release unless you’re a multi-billion gaming company or Cisco
Wiktionary: (software engineering) A version of a program that is nearly ready for release but may still have a few bugs; the status between beta version and release version.
Oxford: a version of a product, especially computer software, that is fully developed and nearly ready to be made available to the public. It comes after the beta version.
I couldn’t find more definitions from “big” dictionaries, but literally no definition I’ve seen agrees with you. I wonder why that is.
KDE has a predefined schedule for “release candidates”, which includes RC2 later this month. So “RC1” is clearly not going to be the final version. See: community.kde.org/…/February_2024_MegaRelease
This is at least somewhat common. In fact, it’s the same way the Linux kernel development cycle works. They have 7 release candidates, released on a weekly basis between the beta period and final release. See: www.kernel.org/category/releases.html
In the world of proprietary corporate software, I more often see release candidates presented as potentially final; i.e. literal candidates for release. The idea of scheduling multiple RCs in advance doesn’t make sense in that context, since each one is intended to be the last (with fingers crossed).
It’s kind of splitting hairs, honestly, and I suspect this distinction has more to do with the transparency of open-source projects than anything else. Apple, for example, may indeed have a schedule for multiple macOS RCs right from the start and simply choose not to share that information. They present every “release candidate” as being potentially the final version (and indeed, the final version will be the same build as the final RC), but in practice there’s always more than one. Also, Apple is hardly an ideal example to follow, since they’ve apparently never even heard of semantic version numbering. Major compatibility-breaking changes are often introduced in minor point releases. It’s infuriating. But I digress.
I get that there are a lot of novel are cool distros out there, but I just stick with Debian (or one of the other well known distros that have been around for decades).
I do it because from a security standpoint, they have my trust. Maybe in 10-20 years with a good reputation and history, but it’s not there.
The whole system is built using it, so every time your system will be the same when building from the same configuration. Even if you such to another computer, you will download locked versions of all packages and get the exact same system
In Ubuntu installing and removing a package doesn’t even guarantee it’s cleaned up
If the only thing you need to do is test out the different DEs, you should be able to just install each one and use something like lightdm to easily switch between them upon logging out.
Yeah I tried proton 8 and 7 too and no difference. I had this exact same issue in win7 too before I switced to Linux so I don’t think it’s an issue with proton.
I had an issue like this once, it turned out something with openGL had gotten messed up in my last system update, so although I thought I hadn’t changed anything, not even Linux native games would launch correctly. the solution that worked for me was just using my distros update tool to make sure everything was up to date, and that found and updated the broken package and since then everything’s worked for me
I’m starting to think it has something to do with my GPU/drivers aswell. Earlier when I ran the software updater it found an update for steam but while installing I got this message and I have no idea what it mean and how to sort it out
That really sucks lol, I was hoping you’d be on Mint or something. Did you install using Ubuntu’s app store thing that uses the awful snaps?
I’m guessing the normal Steam package installs the drivers for you seeing as I can’t find a guide that shows you how to install them on the same page as installing Steam.
I’m not sure how you can get that package on Ubuntu, but for what it’s worth Ive had a much better time ever since I switched from Ubuntu to Nobara. it really has everything I need for gaming out of the box and everything just works. I’m sure a full reinstall is way more of a hassle than you’d want to deal with rn, but if you get to that point I’d highly suggest nobara
I might treat my PC with a new motherboard, CPU and RAM in the near future so switching distros is not totally out of the question. This rig is almost exclusively for playing DayZ tho, so this issue is particularly irritating.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.