Sorry about that - was just alerted to it. I’ve disabled the “other” option now. It was fine a few hours ago, looks like we have a sick troll here. :/
Sorry about that - was just alerted to it. I’ve disabled the “other” option now. It was fine a few hours ago, looks like we have a sick troll here. :/
Nice, glad that got sorted. :) BTW could you edit the title please and mark it as [SOLVED]? Thanks!
I tested this myself on two identical VMs with 2GB RAM, one installed with Fedora 40 KDE, and another with Fedora 40 LXQt, both set to use X11 (because LXQt isn’t Wayland ready yet), both updated and running the latest kernel 6.8.10-300.fc40.
I logged into the DEs, opened only two terminal windows and nothing else, ran, and ran htop:
The KDE VM was unsable when I disabled swap - it completely froze on me. Meanwhile, LXQt chugged on just fine. Of
Of course, I could get rid of some bloat like akonadi, so I did that and rebooted my machine. Then I compared just the essential components, but I excluded plasmashell because it includes stuff like the panel and notifications, unlike LXQt where they’re all separate components so you can’t really compare them:
Component | Process_KDE | RAM_KDE | Process_LXQt | RAM_LXQt |
---|---|---|---|---|
WM | kwin_x11 | 99 | openbox | 18 |
Terminal | konsole | 76 | qterminal | 75 |
File Manager | Dolphin | 135 | pcmanfm-qt | 80 |
File Archiver | ark | 122 | Lxqt-archiver | 73 |
Text Editor | kwrite | 121 | featherpad | 73 |
Image Viewer | gwenview | 129 | lximage-qt | 76 |
Document Viewer | okular | 128 | qpdfview-qt6 | 51 |
Total | 810 | 446 |
plasmashell was sitting at 250MB btw in this instance btw.
Do you have base-devel
installed? If not, install that and try again.
The problem is that games don’t run at all or require major effort to run without issues.
A major cause for that is the distro - when it comes to gaming, the distro makes a huge difference as I outlined previously. The second major cause is the flavor of Wine you chose (Proton-GE is the best, not sure what you used). The third major cause is checking whether or not the games are even compatible in the first place (via ProtonDB, Reddit etc) - you should do this BEFORE you recommend Linux to a gamer.
In saying all that, I’ve no idea about pirated stuff though, you’re on your own on that one - Valve and the Wine developers obviously don’t test against pirated copies, and you won’t get much support from the community either.
The following list of software packages is required for ntfs file system support: ntfs-3g / ntfsprogs.
First of all, make sure you install ntfsprogs-ntfs3
from the AUR (this package doesn’t install the old/buggy ntfs-3g
driver).
Once it’s installed, you can then then attempt to fix drive using sudo ntfsfix /dev/nvme0n1p2 --clear-dirty
.
Run it a second time to verify, and that should do the trick. No need to boot into Windows.
Btw, in case you’re mounting this drive manually, make sure you specify -t ntfs3
, otherwise it’d use the old/buggy ntfs-3g
driver - which we don’t want. In fact, I’d say get rid of ntfs-3g
if you’ve got it - no point keeping it around if you’re on a recent kernel.
Unfortunately you chose the wrong distro for your friend - Linux Mint isn’t good for gaming - it uses an outdated kernel/drivers/other packages, which means you’ll be missing out on all the performance improvements (and fixes) found in more up-to-date distros. Gaming on Linux is a very fast moving target, the landscape is changing at a rapid pace thanks to the development efforts of Valve and the community. So for gaming, you’d generally want to be on the latest kernel+mesa+wine stack.
Also, as you’ve experienced, on Mint you’d have to manually install things like Waydroid and other gaming software, which can be a PITA for newbies.
So instead, I’d highly recommend a gaming-oriented distro such as Nobara or Bazzite. Personally, I’m a big fan of Bazzite - it has everything you’d need for gaming out-of-the-box, and you can even get a console/Steam Deck-like experience, if you install the -deck
variant. Also, because it’s an immutable distro with atomic updates, it has a very low chance of breaking, and in the rare ocassion that an update has some issues - you can just select the previous image from the boot menu. So this would be pretty ideal for someone who’s new to Linux, likes to game, and just wants stuff to work.
In saying that, getting games to run in Linux can be tricky sometimes, depending on the game. The general rule of thumb is: try running the game using Proton-GE, and if that fails, check Proton DB for any fixes/tweaks needed for that game - with this, you would never again have to spend hours on troubleshooting, unless you’re playing some niche game that no one has tested before.
Since you asked…
As an actual M1+Asahi user and a gamer: Asahi is not there yet. Right now, if you’re on macOS, Crossover (or Porting Kit) and/or Parallels is able to run more games and with better performance compared to Asahi (using krun + FEX). Also, Steam on macOS (non-native) is much more peformant compared to Asahi, where it’s currently slow and glitchy.
But that will all change in the future once the Vulkan driver and TSO patches are ready. FEX is also seeing a lot of improvements, so by the end of the year, there’s a good chance that gaming on Asahi would be much better than macOS.
Why not just leave them as NTFS for now? The new in-kernel NTFS3 driver is actually pretty decent (since kernel 6.2), and shouldn’t pose any issues if you’re just using it as a bulk data store.
Eventually when you replace the disks, you can can format your new disks as ext4 (or even better, use btrfs or bcachefs).
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: https://arstechnica.com/gadgets/2024/02/asahi-linux-projects-opengl-support-on-apple-silicon-officially-surpasses-apples/
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: https://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.
ElementaryOS doesn’t work on Apple Silicon, so that’s not an option.
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.
deleted by creator
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.
Medicat USB has a few hardware diagnostics tools on it. It’s based on Ventoy, so it’s more like a collection of ISOs as opposed to a single distro.
You can, if the laptop supports VLink/DP-in, such as the Minisforum V3.
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.
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.
I’ve disabled the “other” option now, someone hijacked the poll. Guess that’s what I get for allowing users to add their own options. >_<