Sounds like an issue with your WiFi adapter/driver. You can verify this by creating a mobile hotspot on your phone and connecting your PC to it and see if you get the same issue, if you do then it proves it’s got nothing to do with your router.
Another thing you can check is your journalctl logs - run journalctl -f before launching the game, then run the game and quit it when you run into the DNS issue, and check the logs at the time the issue occurred. If there’s indeed a hardware/driver issue, the errors should show up in the logs.
If it’s a driver issue, there may not be much you can do about it besides reporting the bug and implementing some sort of workaround (eg using a VPN). Of course, depending on the error, there may be a fix you can apply, like turning of aspm for your chip. A better option would be to replace the WiFi chip/adapter you’re using and get something that’s better supported under Linux, like something with an Intel or Atheros chip. But check journalctl first and see how it goes from there.
It’s not that simple. The biggest issue is that Apple Silicon uses 16K memory page sizes instead of the 4K pages used by pretty much every other architecture out there. This means you’d need a kernel patched for 16K pages - but that would also cause an issue with drivers and other apps designed with 4K pages in mind. So there’s a lot of work done in that area to get both the kernel and apps working. Even then, some apps may never work, and so you’d have to resort to using hacks like microVMs to run a 4K kernel and then run the app on top of it, but that introduces it’s own set of issues of course.
Then there’s the issue of hardware components - of course Apple hasn’t open-sourced any of their firmware/drivers, so most of the Asahi drivers were developed by reverse engineering. The GPU was the biggest piece of work, the reverse engineering done to get it to a workable state by the Asahi team was nothing short of genius. In fact the current state of the OpenGL driver is so good that it’s far, far more compliant to the spec compared to macOS itself - macOS only supports OpenGL upto 4.1 and is not certified either (and technically no longer supported by Apple), whereas Asahi supports up till 4.6 - and it’s still being improved. See: arstechnica.com/…/asahi-linux-projects-opengl-sup…
Similarly, a lot of wizardry was done to get the sound going, and not only did they get it going - they even improved the DSP so it sounds even better than macOS! (Scroll down to the speakers section here: asahilinux.org/2024/01/fedora-asahi-new/).
But in spite of all that, there’s still a lot of work to be done, such as getting Thunderbolt and DisplayPort going, as well as improving compatibility with x86 apps (using krun and FEX) and more GPU improvements etc and support for the M3 and newer chips… Even then, Asahi is already in a usable daily-driver state for many users, and it’s improving at a rapid pace.
So long story short, the Asahi team had to do a ton of work to get it all going on a complex, closed piece of hardware like Apple Silicon - and it’s genius levels of work, the level of which I can barely comprehend - and isn’t something any random distro can pull off.
In the footnotes they mention GPT-3.5. Their argument for not testing 4 was because it was paid, and so most users would be using 3.5 - which is already factually incorrect now because the new GPT-4o (which they don’t even mention) is now free. Finally, they didn’t mention GPT-4 Turbo either, which is even better at coding compared to 4.
If you want to make it fancy we could do a presentation type thing, like via slidesgo.com or similar, but since this is on/for Lemmy, I think we should just keep it simple and make it a normal post.
For the anniversary day, maybe we could have a post showcasing a few highlights of our community over the past year, something like Spotify’s Wrapped, but for Lemmy - so maybe a highlight of the most upvoted posts/comments, most profilic posters, membership counts, major server changes and little victories (maybe share some of your experiences in keeping the ship afloat)?
You can sill use Medicare to create the USB and then add your favorite antimalware rescue CD to it, like the Kaspersky/Avira ones, but if it’s an unknown malware you’d have to use other analysis tools like Sysinternals RootkirRevealer, Autoruns etc. If you want to fix Windows stuff then it’s best to get a WinPE-based live CD with these tools, like Sergei Strelec, Gandalf etc.
Before y’all get excited, the press release doesn’t actually mention the term “open source” anywhere.
Winamp will open up its code for the player used on Windows, enabling the entire community to participate in its development. This is an invitation to global collaboration, where developers worldwide can contribute their expertise, ideas, and passion to help this iconic software evolve.
This, to me, reads like it’s going to be a “source available” model, perhaps released under some sort of a Contributor License Agreement (CLA). So, best to hold off any celebrations until we see the actual license.
This has nothing to do with Arch or Bazzite, it’s actually a bug in recent kernels. Switching to Mint only fixed it for you because Mint uses an old kernel.
The fix/workaround is to enable “above 4G decoding” and “resizable BAR” in your BIOS. If your BIOS does not have these options, you can either downgrade to an earlier kernel (or OS image if you’re on Bazzite), or switch to a patched kernel like the Cachy kernel.
I did! Used to have a Samsung 49" ultrawide. After using it for a couple of years, I sold it and got a 16:10 32" QHD, which I found worked better for me (+ one or two laptop screens for chat / random stuff when I’m doing serious work).
The biggest issue I had with the ultrawide is that most of the games that I played weren’t optimised for it, especially in some games where things like the mini-map might be at the far end of the screen, or worse, if it was an older game then you’d have to put up with black bars, or play the game in windowed mode.
Is that all? Will that remove all the traces of arch?
There will be some other minor dot files in your /home which you might want to review, like .bashrc, .bash_profile, .profile etc. These should be mostly harmless, but if you don’t recall customising them, then yeah free to nuke all the dot files. Also be aware that some programs also leave their configs outside the .config folder, like Firefox might have a .mozilla folder, GTK programs might create a .themes folder, vim has .vim. So you might want to review and delete these as well, if you want a clean config.
As for the last step - just before you boot into your new distro, you might to get rid of the Arch/Endeavour entries from your ESP/UEFI. Run efibootmgr to see your current UEFI boot entries, then nuke the entries using efibootmgr --delete-bootnum -b #.
And to get rid of the GRUB configs, delete your <ESP>/EFI/grub folder. I’m guessing your /boot is on your root partition? If not then you’ll also need to delete /boot/grub.
Now when you install your next distro, you should get a nice and clean GRUB install.