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.

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.

Bazzite. Here’s why:

• Optimised for gaming (gaming optimised kernel, common tweaks pre-applied, all common gaming apps pre-installed like Steam, Mangohud etc)
• All necessary drivers pre-installed (game controllers, RGB, and even proprietary nVidia)
• A Steam-Deck like gaming experience, if you want (the Deck variant boots directly to Steam)
• Immutable and atomic (image-based OS updates, so updates either work or don’t - there’s no chance of a broken state)
• Easy rollbacks (just select the previous image in the GRUB menu)

But since you said:

how to squeeze the best performance out of this

and if you’re really serious about squeezing the best performance, then check out the Arch-based CachyOS - unlike most other Linux distros, Cachy has optimised x86-64-v3 and v4 packages in their repos, which means apps can make use of advanced CPU instructions such as SSE3, AVX512 etc. Most other Linux distros on the other hand still use x86-64-v1 for compatibility reasons, which unfortunately means that you’d be missing out on all the cool new optimised CPU instructions introduced over the past 16 years.

You can read more about microarchitecture levels (aka MARCH) here: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

In addition to the MARCH, Cachy’s packages have other optimisations such as LTO/PGO, optimised kernel with the BORE and Rusty schedulers which are better for gaming, plus several performance-oriented tweaks which you’d otherwise have to do manually on Arch (such as makepkg.conf tweaks, pacman.conf tweaks etc).

Finally, Cachy are always on the bleeding edge when it comes to gaming/driver/kernel/performance related stuff, so you’ll get all the good stuff even before Bazzite or other optimised distros. For instance, Cachy was the first distro to include the new nVidia driver which has explicit sync support for better Wayland compatibility, and they’re always on top of major Arch developments and provide detailed announcements which are relevant to gamers and performance freaks.

Eg, here’s their recent recent nVidia announcement:

Hi @here,

as you maybe noticed, we have rolled out the new NVIDIA Driver, which includes the explicit sync protocol and tearing for Vulkan. We have been prioritized to move this forward to finally resolve the wayland situation. Additionally arch has pushed CUDA to 12.5, which is NOT compatible with the current 550 driver (it needs the 555 Driver).

The beta driver is not perfect, but so far we are applying some fixes to avoid issues and restore performance problems with disabling the GSP Firmware load. This is handled via the “cachyos-settings” package.

Anyways, since some people maybe have problems with this driver, here is a short instruction to manually downgrade and block the driver:

[…]

If you are facing issues with the new NVIDIA Driver, reproduce the issues and then run “sudo nvidia-bugreport.sh” and report it to their forum: https://forums.developer.nvidia.com/c/gpu-graphics/linux/148

We are also shipping now an precompiled nvidia-open module. This will be also as default installed for users, which have supported cards as soon NVIDIA releases the 560 drivers.

The CachyOS Team

So as you can see, they’re pretty on to it with this sorta stuff.

Now the Bazzite team are also like the Cachy guys and keep up with this stuff, but because they’re based on Fedora, they can’t be as bleeding edge or as optimised as Arch. So it’s up to you - if you prefer stability, a primarily gaming-focused optimisations, and want something that “just works” then get Bazzite; or if you want an ultra-optimised distro to squeeze out the most performance out of your box but also don’t mind ocassionally diving into the terminal and getting your hands dirty, then get CachyOS.

cc: @01189998819991197253@infosec.pub

It’s faster and more memory efficient basically. skim also appears to have been abandoned (no updates in over an year), whereas two_percent is being actively developed.

Those of you reading this might also be interested in two_percent, which is a fork of skim, which in turn is a Rust implementation of fzf. two_percent is faster, more efficient and uses less memory than fzf, which is especially noticeable with large inputs.

Others here have already given you some good overviews, so instead I’ll expand a bit more on the compilation part of your question.

As you know, computers are digital devices - that means they work on a binary system, using 1s and 0s. But what does this actually mean?

Logically, a 0 represents “off” and 1 means “on”. At the electronics level, 0s may be represented by a low voltage signal (typically between 0-0.5V) and 1s are represented by a high voltage signal (typically between 2.7-5V). Note that the actual voltage levels, or what is used to representation a bit, may vary depending on the system. For instance, traditional hard drives use magnetic regions on the surface of a platter to represent these 1s and 0s - if the region is magnetized with the north pole facing up, it represents a 1. If the south pole is facing up, it represents a 0. SSDs, which employ flash memory, uses cells which can trap electrons, where a charged state represents a 0 and discharged state represents a 1.

Why is all this relevant you ask?

Because at the heart of a computer, or any “digital” device - and what sets apart a digital device from any random electrical equipment - is transistors. They are tiny semiconductor components, that can amplify a signal, or act as a switch.

A voltage or current applied to one pair of the transistor’s terminals controls the current through another pair of terminals. This resultant output represents a binary bit: it’s a “1” if current passes through, or a “0” if current doesn’t pass through. By connecting a few transistors together, you can form logic gates that can perform simple math like addition and multiplication. Connect a bunch of those and you can perform more/complex math. Connect thousands or more of those and you get a CPU. The first Intel CPU, the Intel 4004, consisted of 2,300 transistors. A modern CPU that you may find in your PC consists of hundreds of billions of transistors. Special CPUs used for machine learning etc may even contain trillions of transistors!

Now to pass on information and commands to these digital systems, we need to convert our human numbers and language to binary (1s and 0s), because deep down that’s the language they understand. For instance, in the word “Hi”, “H”, in binary, using the ASCII system, is converted to 01001000 and the letter “i” would be 01101001. For programmers, working on binary would be quite tedious to work with, so we came up with a shortform - the hexadecimal system - to represent these binary bytes. So in hex, “Hi” would be represented as 48 69, and “Hi World” would be 48 69 20 57 6F 72 6C 64. This makes it a lot easier to work with, when we are debugging programs using a hex editor.

Now suppose we have a program that prints “Hi World” to the screen, in the compiled machine language format, it may look like this (in a hex editor):

As you can see, the middle column contains a bunch of hex numbers, which is basically a mix of instructions (“hey CPU, print this message”) and data (“Hi World”).

Now although the hex code is easier for us humans to work with compared to binary, it’s still quite tedious - which is why we have programming languages, which allows us to write programs which we humans can easily understand.

If we were to use Assembly language as an example - a language which is close to machine language - it would look like this:

     SECTION .data
msg: db "Hi World",10
len: equ $-msg

     SECTION .text
     
     global main   
main:
     mov  edx,len
     mov  ecx,msg
     mov  ebx,1
     mov  eax,4

     int  0x80
     mov  ebx,0
     mov  eax,1
     int  0x80

As you can see, the above code is still pretty hard to understand and tedious to work with. Which is why we’ve invented high-level programming languages, such as C, C++ etc.

So if we rewrite this code in the C language, it would look like this:

#include <stdio.h>
int main() {
  printf ("Hi World\n");
  return 0;
} 

As you can see, that’s much more easier to understand than assembly, and takes less work to type! But now we have a problem - that is, our CPU cannot understand this code. So we’ll need to convert it into machine language - and this is what we call compiling.

Using the previous assembly language example, we can compile our assembly code (in the file hello.asm), using the following (simplified) commands:

$ nasm -f elf hello.asm
$ gcc -o hello hello.o

Compilation is actually is a multi-step process, and may involve multiple tools, depending on the language/compilers we use. In our example, we’re using the nasm assembler, which first parses and converts assembly instructions (in hello.asm) into machine code, handling symbolic names and generating an object file (hello.o) with binary code, memory addresses and other instructions. The linker (gcc) then merges the object files (if there are multiple files), resolves symbol references, and arranges the data and instructions, according to the Linux ELF format. This results in a single binary executable (hello) that contains all necessary binary code and metadata for execution on Linux.

If you understand assembly language, you can see how our instructions get converted, using a hex viewer:

So when you run this executable using ./hello, the instructions and data, in the form of machine code, will be passed on to the CPU by the operating system, which will then execute it and eventually print Hi World to the screen.

Now naturally, users don’t want to do this tedious compilation process themselves, also, some programmers/companies may not want to reveal their code - so most users never look at the code, and just use the binary programs directly.

In the Linux/opensource world, we have the concept of FOSS (free software), which encourages sharing of source code, so that programmers all around the world can benefit from each other, build upon, and improve the code - which is how Linux grew to where it is today, thanks to the sharing and collaboration of code by thousands of developers across the world. Which is why most programs for Linux are available to download in both binary as well as source code formats (with the source code typically available on a git repository like github, or as a single compressed archive (.tar.gz)).

But when a particular program isn’t available in a binary format, you’ll need to compile it from the source code. Doing this is a pretty common practice for projects that are still in-development - say you want to run the latest Mesa graphics driver, which may contain bug fixes or some performance improvements that you’re interested in - you would then download the source code and compile it yourself.

Another scenario is maybe you might want a program to be optimised specifically for your CPU for the best performance - in which case, you would compile the code yourself, instead of using a generic binary provided by the programmer. And some Linux distributions, such as CachyOS, provide multiple versions of such pre-optimized binaries, so that you don’t need to compile it yourself. So if you’re interested in performance, look into the topic of CPU microarchitectures and CFLAGS.

Sources for examples above: http://timelessname.com/elfbin/

First of all, I’m not the author of the article, so you’re barking up the wrong tree.

You’re using the unstable channel.

That doesn’t matter in the big scheme of things - it doesn’t solve the fundamental issue of slow security updates.

You could literally build it on your own, or patch your own change without having to wait - all you have to do is update the SHA256 hash and the tag/commit hash.

Do you seriously expect people to do that every time there’s a security update? Especially considering how large the ecosystem is? And what if someone wasn’t aware of the issue, do you really expect people to be across every single vulnerability across the hundreds or thousands of OSS projects that may be tied to the packages you’ve got on your machine?

The rest of your points also assume that the older packages don’t have a vulnerability. The point of this post isn’t really about the xz backdoor, but to highlight the issue of slow security updates.

If you’re not using Nix the way it is intended to be, it is on you. Your over-reliance on Hydra is not the fault of Nix in any way.

Citation needed. I’ve never seen the Nix developers state that in any official capacity.

From what I’ve heard so far, it’s NOT an authentication bypass, but a gated remote code execution.

There’s some discussion on that here: https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b

But it would be nice to have a similar digram like OP’s to understand how exactly it does the RCE and implements the SSH backdoor. If we understand how, maybe we can take measures to prevent similar exploits in the future.

This is informative, but unfortunately it doesn’t explain how the actual payload works - how does it compromise SSH exactly?

Multiple times a day, basically whenever I’m bored. Sometimes I get so depressed when there are no updates, that I install some random package or build something from source, so I can look at some text flying across my terminal, and look at all the cool stuff happening on my PC. I also have a journalct -f and btop running all the time as it’s interesting to see what’s happening behind the scenes.

I have a Zen 2, Zen 3+ and a Zen 4 system and they all work well very with various Linux distros (Arch, Fedora) and recent kernels.

It’s very likely that your bug is specific to early Ryzen CPUs/chipsets. A couple of folks on those reports mentioned their issues went away after a motherboard/BIOS upgrade. So I think you’ll be fine if you went for a more recent AMD CPU+mobo.

And the ones who install Arch on a MacBook need extra special therapy.

This is my my phone running Debian with XFCE:

So basically:

1. Update your system, don’t reboot yet
2. mkinitcpio.conf --> make sure you have microcode after the autodetect in the HOOKS line
3. /etc/mkinitcpio.d/<kernel>.preset --> remove the line ALL_microcode=(/boot/*-ucode.img)
4. systemd-boot users: arch.conf --> remove or comment out the initrd /amd-ucode.img (or intel-ucode.img) line
5. Run sudo mkinitcpio -p <kernel> to generate your new initrd, and then reboot

Optional: run grep microcode /proc/cpuinfo before and after the reboot to verify that your microcode version hasn’t changed after the reboot - which means that the new microcode loading method is working correctly.

On a tangential note, the above is a perfect example of why I don’t recommend Arch (and so-called “easy” derivatives like EndeavourOS) for newbies (ie people who don’t RTFM / keep up with Arch news / inspect their .pacnew files etc). Feel free to link this post in your future internet arguments. :)

matching other programs and platforms

Actually, Ctrl+C is the interrupt hotkey for pretty much every CLI app/terminal on every platform. Try it within the Command Prompt/PowerShell/Windows Terminal, or the macOS terminal - they’ll all behave the same.

The use of Ctrl+C as an interrupt/termination signal has a very long history even predating the old UNIX days and DEC - it goes back to the days of early telecommunications, where control characters were used for controlling the follow of data through telecommunication lines. These control characters, along with regular characters, were transmitted by being encoded in binary, and this encoding scheme was defined by ASCII (American Stanard Code for Information Interchange), published in 1963.

In ASCII, the control character ETX (meaning end-of-text; represented by the hex code 0x03) was used to indicate “this segment of input is over”, or “stop the current processing”.

Now what does all this have to do with with Ctrl+C you ask?

For that, you’ll need to go back to the days of early keyboards. Keyboards back then generated ASCII codes directly, and when a modifier key (Ctrl/Shift/Meta) on a keyboard was pressed in combination with another key, it modified the signal sent by the keyboard to produce a control character.

Specifically, pressing Ctrl with a letter key made the keyboard clear (set to zero) the upper three bits of the binary code of the letter, thus effectively mapping the letter keys to control characters (0x00 - 0x1F: the first 32 characters on the ASCII table).

• The ASCII code for ‘C’ is 0x43 (binary 01000011).
• Pressing Ctrl+C clears the upper three bits, resulting in 00000011, which is 0x03 in hex.

And would you look at that, 0x03 is the code which represents the control character ETX.

The use of ETX to interrupt a program in digital computers was first adopted by the TOPS-10 OS, which ran on DEC’s PDP-10 computer, back in the late 60s. It’s successor, TOPS-20 also included it, followed by the RSX-11 (on the PDP-11), and VMS (on the VAX-11).

RSX-11 was a very influential OS, created by a team that included David Cutler. It influenced the design of several OSes that followed, such as VMS and Windows NT. Cutler later moved to Microsoft and became the father of Windows NT. Early NT did not include a GUI, so it was natural to adopt existing terminal operation standards, including the use of ETX. In fact, NT’s internals were so similar to VMS that a lawsuit was in the works, but instead, MS agreed to pay off DEC millions of $$$.

Also, when UNIX first came out (1969), it ran on DEC hardware, and so they followed the tradition of using the ETX signal to stop programs. This convention flowed to BSD (1978) which was based on UNIX, and NeXTSTEP (1989), which was based on BSD. NeXTSTEP was developed by NeXT Computers, which was founded by Steve Jobs… and the rest is history.

Therefore, Ctrl+C is something that’s deeply rooted in history. You don’t just simply change something like that. Sure, you may be able to remap the keybindings, but it’s actually hardcoded into many programs so you’ll run into inconsistencies - that is, if you used the standard remapping tools built into GNOME/KDE etc.

If you want to truly remap Ctrl+C, you’ll want to do so at a lower level (evdev layer) so that it’s not intercepted by other programs, eg using tools like evremap or keyd. But even then, it’s not guaranteed to work everywhere, for instance, if you’re inside a VM or using a different OS, or in a remote session. So it’s best to remap the keys at the keyboard layer itself, which is possible on many popular mechanical keyboards using customisable firmware like QMK/VIA.

Laughs in Fedora 39

No.

No headphone jack, no buy. It’s not a question of whether a headphone jack is useful to you, it’s just the principle of it - there’s no good reason to remove it (especially for the asking price of FP5), and more importantly, it goes against what the Fairphone stands for, IMO. I can understand if it were some other profit-driven company making a shrewd business decision, but for Fairphone to do it, seems very unfair to me.