There’s a Dolphin plugin for this: https://github.com/Nyre221/dolphin-quick-view

Just use Termux and install the openssh package. You can also install mosh, which is better than vanilla ssh.

That’s an issue/limitation with the model. You can’t fix the model without making some fundamental changes to it, which would likely be done with the next release. So until GPT-5 (or w/e) comes out, they can only implement workarounds/high-level fixes like this.

This shouldn’t even be a question lol. Even if you aren’t worried about theft, encryption has a nice bonus: you don’t have to worry about secure erasing your drives when you want to get rid of them. I mean, sure it’s not that big of a deal to wipe a drive, but sometimes you’re unable to do so - for instance, the drive could fail and you may not be able to do the wipe. So you end up getting rid of the drive as-is, but an opportunist could get a hold of that drive and attempt to repair it and recover your data. Or maybe the drive fails, but it’s still under warranty and you want to RMA it - with encryption on, you don’t have to worry about some random accessing your data.

You should check out Nix the package manager, which is an even better option than Distrobox if you want to install stuff independently of your distro’s packaging system. The biggest advantage of using Nix is that there’s no container layer, so you’re running the binaries directly on your host OS - this means that the binary can have full access to system resources, which is handy if you need to run one of those apps with root privileges (try running a Distrobox exported app with sudo - it won’t work). Or say you want to install something like a terminal emulator - it’s not exactly practical to install it inside Distrobox, because now every time you run the terminal, you’d be viewing at your system from inside the container, which can makes things pretty messy.

Another advantage of Nix is that because you’re dealing with actual binaries and not just a shim script, it can handle command line arguments properly and also handle things like stdin/stdout properly. In fact there’s a bug right now with the way Distrobox export handles command line parameters, where it eats some of the parameters so your exported program may not work correctly. I had this issue with a Distrobox export of freerdp and raised an issue for it, but it still hasn’t been fixed. So until this is fixed, I’d advise staying away from running distrobox exported stuff, unless you’re using it for only simple apps/workflows.

Also, you don’t have the hassle of having to maintain/update the Arch or whatever OS is installed inside your containers.

Finally, with Nix you can easily roll back your transactions or switch between multiple versions of the apps - all of which takes place instantly, because all it’s doing is switching the symlinks in the Nix store.

If you were looking for answers to such questions 10 years ago, your best resource for finding a thorough, expert-informed response likely would have been one of the most interesting and longest-lasting corners of the internet: Quora.

I disagree, the best place for such answers used to be Reddit, and Stack Exchange for the techy stuff. Quora always felt like cancer for some reason and I never really used it.

Nice writeup!

Only thing is:

If you decided to do that, you have to reboot each time you install something, which obviously sucks!

You don’t have to reboot if you use the --apply-live switch, but of course, you’d still need to reboot for something like a kernel update. And of course, I wouldn’t recommend layering packages either, unless there’s no other alternative.

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.

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

Over-reliance on proprietary, closed-source products and services from megacorporations.

For instance, it’s really absurd that people in many parts of the world cannot function without WhatsApp, they can’t even imagine a life without it. It seems absurd that Meta literally has them by the balls, and these people can’t do anything about it.

Also the people who base their entire careers on say Adobe or Microsoft products, they’re literally having their lives dictated by one giant corporation, which is very depressing and dystopian.