Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Wild Penquin

Member
  • Content Count

    363
  • Joined

  • Last visited

Awards

This user doesn't have any awards

About Wild Penquin

  • Title
    Member

Profile Information

  • Location
    Finland
  • Gender
    Male

System

  • CPU
    i4790k
  • Motherboard
    Asus Maximus VII Gene
  • RAM
    32GB
  • GPU
    Radeon RX Vega 64
  • Case
    Lian Li DX-04
  • Storage
    Loads
  • PSU
    Works and is quiet
  • Display(s)
    Samsung LC34F791
  • Cooling
    Air
  • Keyboard
    Corsair K95RGB Platinum
  • Mouse
    Logitech G703
  • Sound
    Jazz, Progressive Rock, electronic music!
  • Operating System
    Arch Linux

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Some distributions install grub into the EFI partition, along with it's configuration files. Not all do, but that is one valid way to install grub. What this means, is that even after deleting all partitions of the said Linux installation, it's grub might still linger on and have it's configuration in the EFI partition. You can even have many grub installation in the EFI partition. If for whatever reason the default UEFI entry is the old grub UEFI entry, updating grub settings from the current Linux OS will not fix things - unless the said command also ensures the grub instance it
  2. This is true, which is why I prefer amd GPUs. Not only did the NVidia Linux drivers have a bit less-than-Window performance, their overall quality and stability is worse (also, no support whatsoever from NVidia; but for AMGPU drivers: if you know how to gather information from crashes, logs etc. - even better if you can run a debugger - it is actually possible to get help and bugs fixed with amdgpu by posting useful bug reports in trackers). As for OPs question: indeed Linux is not any magic wand, it does not make your PC magically perform better. In some corner cases it may be pos
  3. Your point is right in principle, but none of the examples you've given are native Linux games. They are using Vulkan but they are using the Windows implementation of it. Which means they still need to run trough Wine implementation of the Windows API (Windos Vulkan -> Linux Vulkan will include it's own computation costs, which might not be at all faster than, say, dxvk). Games which have a real Native Linux port run very well (X-COM series, Tomb Raider series for example).
  4. Also, look at your BIOS settings. It is likely your fans are controlled by the BIOS and fan curve settings are setting in a suboptimal way (considering acoustics etc). It does not make much sense to enable software fan control unless the BIOS settings are very limited and you really need it (always consider the scenario of a system hang when the processor is at a 100% usage loop - and if the fan control software doesn't work, fans will not ramp up).
  5. Also, I believe one can boot from GRUB to any correctly installed Legacy-bootable OS. I.e. if GRUB has been booted in UEFI mode, it can boot any (correctly installed) OS. If it has been booted in Legacy mode, it can not boot UEFI-enabled OSes, generally (emphasis because I'm not sure on the UEFI Grub -> Legacy boot chain, but there is no reason it should not work). But indeed as long as OP (or anyone who is asking any question) does not provide information about their setup, it is really difficult to give advice / instructions on any matter. As a general tip: learn h
  6. (sigh) this is still an issue with current Windowses? I though people haven't needed to deal with this kind of S**** since the UEFI booting came along. I only thought windowses overwrote MBRs (and in the very early days of UEFI though they were the only OS in the EFI, but that could have also been buggy/half-***ed UEFI implementations). Anyways, in this kind of situation grub has booted properly but it can not find it's configuration file. There are (at least) two places where it can reside in: in grub's dedicated folder "grub" in the root of EFI (I believe this is a bit no
  7. This has nothing to do with the problem, grub can load an OS from any disk and partition (if it is a sensible one; it might not do something like booting a DOS-based OS from an extended partition etc.). Post the output of "sudo lsblk" and "sudo blkid" here, that way we can help. The page can be daunting as it has loads of information out of which not all is relevant to you. To summarize the process is roughly: install os-prober (it is not installed per default in Arch), mount your windows partition and then run grub-mkconfig (as outlined earlier on that
  8. Well, it is not the only way - it is one way. I do agree on the insanity part. FOSS is not indeed a magic wand which will solve every problem, but it is one way to help facilitate this goal. Also, previously I was not referring to the end-user software (although it also does play a role - a closed source software can only be ported by the source rights holder, but with a more free license many other parties can facilitate a port). To re-iterate what I was trying to say: Currently, we have competing, closed source APIs and Libraries for every major OS (Windows, O
  9. Hi GCandy77, I'll try to answer your questions as you've numbered them. 1. dynamic mount via systemd units: First question: why do you need to do this? Wouldn't listing the partitions in fstab suffice? This is also in the grey box right in the beginning of the Manjaro forum post you've linked. (The OP there says the manual in in contradiction; I disagree with that, it's just a wrong interpretation the OP is making. I argue it makes sense to configure system so that the configuration is easy to read and change for humans. Systemd can have it's own
  10. @maplepants, I agree. Coming from a non-programmer, Java has been marketed as something it was never meant to be (or so I've been told), and it is not the only one of that kind of cases (well, it happens everywhere, in every field... reality doesn't often match with marketing - ever played a videogame which didn't live up to it's hype? Marketing is shady! ). It still has it's uses (despite misleading marketing) but the bytecode can not be as efficient as something compiled from a more efficiency-oriented language, say, C. There might still be some development possible here with i
  11. I think you are touching an important problem here. I'll start with an analogy from the history: way back in the emerging home-computer segment in the 70s and 80s, there were loads of different computers. They all had their own software, and a piece of software made for, say Commodore Amiga would not work on an Atari ST. The reason was they had different kind of hardware. At some point IBM PC became the standard as we know it today, kind of by half-accident (it was supposed to be a proprietary system, but then clones emerged, and I'm not sure IBM sued anybody, but in any case, then
  12. Also, after re-reading your post I noticed you are planning to use chroot. That is usually not necessary in case your bootloder is working. You can pass kernel parameters so that it will not start any X.org session. The official way would be to add: systemd.unit=rescue.target on these modern, systemd days but "single", "1" or "s" should also work as an alias coming from sysvinit days. How you do this depends on your boot loader. See: https://wiki.archlinux.org/index.php/Systemd#Change_default_target_to_boot_into This a bit less error prone than chroot (though tha
  13. Unless something is really screwed up (such as: stuff in /etc, out-of-tree files everywhere etc.) then there is no reason to reinstall. I would go as follows: Remove all packages installed from AUR (pacman -Rns ...) Re-install the graphics drivers as per the wiki Based on what you've told, this is all there is to fix. In case you have indeed used packages outside Arch repositories (which it does sound like - you mention an uninstallation script!), things might get a bit more hairy. The same page I've linked above has tips on how to list files not owned by any pa
  14. What are you specifically worried about? If your system works fine now, no damage was done. Overall IMHO the dangers of running sensors-detect is a bit exaggerated sometimes. That being said, it can cause lock-ups, or at least in theory even data corruption or some similar problems. But these issues are somewhat theoretical, yes still there is some real risk. The more obscure, and more locked-in like the H/W you are using, the greater the risk - but I don't know about all the details. Blame manufacturers who don't adhere to standards or open up their H/W sensors to software, for t
  15. I want to chime in with some personal experiences. In general, amdgpu drivers are of better quality than NVidias drivers (on Linux!). Examples on which they are better: tearing (or lack of it on amdgpu), minor stability issues, suspend support. That being said, NVidia drivers are not bad. I used them still in 2019 and they were certainly usable. There were some minor problems, but there was always some workaround, but for example, I was not able to completely eliminate tearing. Suspend didn't work. There were occasional driver related problems with NVidia and KDE Plasm
×