There’s https://gitlab.com/android_translation_layer/android_translation_layer which can already run BeatSaber apparently.

I think games specifically might be easier than most other apps as they are probably often little more than a 2D canvas displaying a regular Linux app with quite limited use of android-specific APIs.

Inconsistent time before sleep is likely the kernel waiting for IO to sync to disk.

Not going to sleep at all implies a serious issue that prevented the kernel from doing so. Check your logs!

Suspend reliability greatly depends on the firmware of your specific device as it controls the wakeup.

On my Framework 16 for instance, it is very reliable these days. I can’t remember the last time it woke up unexpectedly and I’m not sure whether it happened even once since the firmware update that fixed a major oversight in keyboard wakeup (waking when a key was pressed through a closed lid).

In Hyprland, how it works is that you define the screen lock command (e.g. swaylock) in hypridle and that gets wired into logind somehow such that you can loginctl lock-session.

I then (also in hypridle) define a before sleep hook that locks the session.

I believe the proper way to do this would be to run your lockscreen as a systemd unit that is WantedBy and Before suspend.target. This would in theory take care of making it idempotent and reliably show the lockscreen before initiating suspend.
A friend of mine has this sort of setup and, while it is reliable, the lockscreen is still racy and sometimes only triggers after suspend. Might be the lockscreen unit not signalling its readiness to systemd properly though.

And this is why you want atomic updates folks…

Did you/your distro set up realtime ulimits correctly such that pw can acquire rt priority?

There is no distribution that does what you’re looking for. All the ones recommended by others in this thread are just generic distributions that do nothing special to separate user applications and I have no idea why they saw fit to mention them at all.

The best recommendation here is Qubes but that’s arguably not a distro but rather its own operating system that can then run some instances of distros inside of it with strong separation between those units.

The only thing that somewhat goes the direction you want is Flatpak but it’s not anywhere close to Androids really quite solid app separation scheme.

The reality of it is that most Linux desktop apps are made with the assumption that they are permitted to access every resource the user has access to with no differentiation; your SSH or GPG private keys are in the same category as the app’s config file.

Standard APIs to manage permissions in a more fine-grained manner are slowly being worked on (primarily by the flatpak community IME) but it’s slow and mostly focused on container stuff which I’m not convinced is the way forward. There does not appear to be any strong effort towards creating a resource access control design that’s anywhere near as good as Android’s in any case though.

The closest thing we have is systemd hardening for system components but that’s obviously not relevant for desktop apps. It’s also (IMHO) inherently flawed due to using a blocklist approach rather than an allow-list one. It’s also quite rigid in what resources it controls.

I’m not convinced any of the existing technologies we have right now is fit for a modern user-facing system.

Here’s what I think we ought to have:

• A method to identify applications at runtime (e.g. to tell apart your browser from your terminal and your editor at runtime)
• A generic extensible way to declare resources to which access should be controlled within a single user context (i.e. some partition of your home filesystem or some device that your user generally has access to such as your camera)
• A user-configurable mapping between resources and applications; enforced by kernel-level generic mechanisms

No need for any containers here for any of this; they’re a crutch for poor legacy distro design that relies on global state. I don’t see a need for breaking the entire UNIX process model by unsharing all resources and then passing in some of them through by overly complex methods either.

Eventhough they’re quite simple and effective, I’m not convinced UNIX users are a good primitive to use for application identification like Android does it because that implies user data file ownership needs to be managed by some separate component rather than the standard IO operations that any Linux apps ever uses for everything.
I think this should instead be achieved using cgroups instead which are the single most important invention in operating systems that you can actually use today since UNIX IMHO.

The missing parts are therefore a standard for resource declaration and a standard and mechanism to assign them to applications (identified via cgroup).
I haven’t done much research into whether these exist or how they could me made to exist.

Someone started working on a Vulkan driver for TeraScale GPUs a few years ago:

https://gitlab.freedesktop.org/Triang3l/mesa/-/tree/Terakan

I believe it can run some demos add even works on windows.

If you’re not going to post what I asked for, nobody can help you.

Or just generally df -h | grep tmpfs and look for any significant usage.

I don’t know what this tool is or how it gets its “memory” metric. If you want to continue to use it, please ascertain that these values correspond to RSS by cross checking with i.e. ps aux. RSS is the memory exclusively held by a given process which is typically what mean by the “memory usage” of any given process. Note however that this does not count anonymous pages of a process that are swapped or shared with other processes.

Going into my task manager (Resources), I can see my using is using roughly 18/32GB of RAM despite closing all apps.

This does not tell you (or us for that matter) anything without defining what “using” means here. My system is “using” 77% of RAM right now but 45% of memory is available for use because it’s cached.

Please post the output of free -h aswell as swapon.

Next, please post the contents of /proc/meminfo.

Do you use ZFS?

That doesn’t make any sort of sense in this scenario.

There’s nothing further I can tell you. You’ll need to figure out which parts those sensors correspond to to draw any sort of conclusion.

I’d recommend you try the out-of-tree driver I linked. You can just rmmod the normal one and insmod the custom one at runtime.

First of all you need to figure out which sensor this even is. On my nct6687, there’s a sensor on the PCIe slot that is constantly >90° and that appears to be totally normal.

Could you post the output of sensors?

Here is how it looks like on my machine:

nct6687-isa-0a20
Adapter: ISA adapter
+12V:           12.26 V  (min = +12.14 V, max = +12.46 V)
+5V:             5.06 V  (min =  +5.00 V, max =  +5.08 V)
+3.3V:           0.00 V  (min =  +0.00 V, max =  +3.40 V)
CPU Soc:         1.02 V  (min =  +1.02 V, max =  +1.04 V)
CPU Vcore:       1.27 V  (min =  +0.91 V, max =  +1.40 V)
CPU 1P8:         0.00 V  (min =  +0.00 V, max =  +0.00 V)
CPU VDDP:        0.00 V  (min =  +0.00 V, max =  +0.00 V)
DRAM:            1.11 V  (min =  +1.10 V, max =  +1.11 V)
Chipset:       202.00 mV (min =  +0.18 V, max =  +0.36 V)
CPU SA:          1.08 V  (min =  +0.61 V, max =  +1.14 V)
Voltage #2:      1.55 V  (min =  +1.53 V, max =  +1.57 V)
AVCC3:           3.39 V  (min =  +3.32 V, max =  +3.40 V)
AVSB:            0.00 V  (min =  +0.00 V, max =  +3.40 V)
VBat:            0.00 V  (min =  +0.00 V, max =  +2.04 V)
CPU Fan:        730 RPM  (min =  718 RPM, max = 1488 RPM)
Pump Fan:         0 RPM  (min =    0 RPM, max =    0 RPM)
System Fan #1:    0 RPM  (min =    0 RPM, max =    0 RPM)
System Fan #2:  490 RPM  (min =  421 RPM, max =  913 RPM)
System Fan #3:    0 RPM  (min =    0 RPM, max =    0 RPM)
System Fan #4:  472 RPM  (min =  458 RPM, max =  939 RPM)
System Fan #5:    0 RPM  (min =    0 RPM, max =    0 RPM)
System Fan #6:    0 RPM  (min =    0 RPM, max =    0 RPM)
CPU:            +37.0°C  (low  = +30.0°C, high = +90.0°C)
System:         +25.0°C  (low  = +22.0°C, high = +48.0°C)
VRM MOS:        +22.0°C  (low  = +20.5°C, high = +66.0°C)
PCH:            +21.5°C  (low  = +18.5°C, high = +49.0°C)
CPU Socket:     +21.0°C  (low  = +19.0°C, high = +56.5°C)
PCIe x1:        +92.0°C  (low  = +76.5°C, high = +97.0°C)
M2_1:            +0.0°C  (low  =  +0.0°C, high =  +0.0°C)

Note that I use the https://github.com/Fred78290/nct6687d/ kernel module though. The upstream one doesn’t label many temps.

I also have several virtual machines which take up about 100 GiB.

This would be the first thing I’d look into getting rid of.

Could these just be containers instead? What are they storing?

nix store (15 GiB)

How large is your (I assume home-manager) closure? If this is 2-3 generations worth, that sounds about right.

system libraries (/usr is 22.5 GiB).

That’s extremely large. Like, 2x of what you’d expect a typical system to have.

You should have a look at what’s using all that space using your system package manager.

EDIT: ncdu says I’ve stored 129.1 TiB lol

If you’re on btrfs and have a non-trivial subvolume setup, you can’t just let ncdu loose on the root subvolume. You need to take a more principled approach.

For assessing your actual working size, you need to ignore snapshots for instance as those are mostly the same extents as your “working set”.

You need to keep in mind that snapshots do themselves take up space too though, depending on how much you’ve deleted or written since taking the snapshot.

btdu is a great tool to analyse space usage of a non-trivial btrfs setup in a probabilistic fashion. It’s not available in many distros but you have Nix and we have it of course ;)

Snapshots are the #1 most likely cause for your space usage woes. Any space usage that you cannot explain using your working set is probably caused by them.

Also: Are you using transparent compression? IME it can reduce space usage of data that is similar to typical Nix store contents by about half.

You can do it but I wouldn’t recommend it for your use-case.

Caching is nice but only if the data that you need is actually cached. In the real world, this is unfortunately not always the case:

1. Data that you haven’t used it for a while may be evicted. If you need something infrequently, it’ll be extremely slow.
2. The cache layer doesn’t know what is actually important to be cached and cannot make smart decisions; all it sees is IO operations on blocks. Therefore, not all data that is important to cache is actually cached. Block-level caching solutions may only store some data in the cache where they (with their extremely limited view) think it’s most beneficial. Bcache for instance skips the cache entirely if writing the data to the cache would be slower than the assumed speed of the backing storage and only caches IO operations below a certain size.

Having data that must be fast always stored on fast storage is the best.

Manually separating data that needs to be fast from data that doesn’t is almost always better than relying on dumb caching that cannot know what data is the most beneficial to put or keep in the cache.

This brings us to the question: What are those 900GiB you store on your 1TiB drive?

That would be quite a lot if you only used the machine for regular desktop purposes, so clearly you’re storing something else too.

You should look at that data and see what of it actually needs fast access speeds. If you store multimedia files (video, music, pictures etc.), those would be good candidates to instead store on a slower, more cost efficient storage medium.

You mentioned games which can be quite large these days. If you keep currently unplayed games around because you might play them again at some point in the future and don’t want to sit through a large download when that point comes, you could also simply create a new games library on the secondary drive and move currently not played but “cached” games into that library. If you need it accessible it’s right there immediately (albeit with slower loading times) and you can simply move the game back should you actively play it again.

You could even employ a hybrid approach where you carve out a small portion of your (then much emptier) fast storage to use for caching the slow storage. Just a few dozen GiB of SSD cache can make a huge difference in general HDD usability (e.g. browsing it) and 100-200G could accelerate a good bit of actual data too.

If you wanted a distro where everything is set up for you OOTB, not requiring tinkering, you should not have installed Arch mate.

That’s just an ACK and Elizabeth replied that she’ll resend again with further changes.

Nothing is in any tree that is going to Linus yet AFAICT.

We could be reasonably sure that it’ll go to Linus if it’s in char-misc but that hasn’t happened yet. I’m also actually not sure whether Greg’s or Arnd’s tree is the canonical one there.

Fake news. It’s merely a re-send of the patches; nothing landed yet.

The Phoronix article and their title makes that clear; you editorialised it to state differently. (Also, that’s…cringe.)

If this is for a user programs rather than system components that must be managed by apt, you could use Nix.

By its nature, it keeps track of all dependencies in a queryable format and Nix stores are actually quite portable; you can just

nix copy /nix/store/6gd9yardd6qk9dkgdbmh1vnac0vmkh7d-ripgrep-14.1.1/ --to /mnt/USB-drive/

and that will copy that store path aswell as any dependency (including transitive deps) to e.g. a USB drive.

You’d then do the inverse in the target environment to do the opposite:

nix copy /nix/store/6gd9yardd6qk9dkgdbmh1vnac0vmkh7d-ripgrep-14.1.1/ --from /mnt/USB-drive/

And then /nix/store/6gd9yardd6qk9dkgdbmh1vnac0vmkh7d-ripgrep-14.1.1/ aswell as its entire runtime dependency tree would exist in the air-gapped system.

Because Nix store paths are hermetic, that’s all you need to execute e.g. /nix/store/6gd9yardd6qk9dkgdbmh1vnac0vmkh7d-ripgrep-14.1.1/bin/rg.

You’d obviously just adjust your $PATH accordingly rather than typing all of that out and typically would install this into what Nix refers to as a profile so that you have one path to add to your $PATH rather than one for each package.

I used a single package here but you could build an entire environment of many packages to your liking and it’d be the exact same as far as Nix is concerned; it’s all store paths.

You do need /nix/ to exist and be writeable in the target environment for this to work though.

From Windows

Low-latency VRR that works correctly

It does not feel quite right in kwin and the rather new “proper” support in Hyprland doesn’t feel right either.

In hyprland you actually have to enable a special option and set a lower bound for VRR because it doesn’t handle LFC with cursors, so a game running at 1fps will make your cursor jump around once per second which is totally unusable. With LFC that would typically result in at least e.g. 90Hz.

VRR in other apps works quite well though. I’m not sure how intended it is but it allows for some nice power savings on my Framework 16; when it’s just a terminal refreshing a few times a second, the screen goes all the way down to 48Hz and when I actually scroll some content or move the cursor it’s still buttery smooth 120Hz.

Sway feels very good w.r.t. VRR but it cannot handle cursors at all (visible or invisible): whenever you move the mouse, VRR is deactivated and you’re at full refresh rate until you stop moving the cursor. It might also not be fine because I could only test a racing game due to the mouse issue and it’s so light that it always ran at a constant rate, so that’s not a great test as what differentiates good VRR from bad VRR is how varying refresh rate is handled of course.

Xorg VRR also never felt right; it felt super inconsistent. Xorg is also dead.

VRR is fundamental for a smooth gaming experience and power efficient laptops.

From macOS

Mouse pad scroll acceleration.

If you’ve ever used a modern macbook for a significant amount of time, you’ll know that its touchpad is excellent. I’d actually prefer a macbook touchpad over a mouse for web browsing purposes.
On Linux however, it’s a complete shitshow and the most significant difference is not hardware but software. You might think that, surely, it can’t be that bad. Let me tell you: it is.

Every single application is required to implement touch pad scrolling on its own; with its own custom rules on how to interpret finger movement across the touch pad. I can’t really convey how insane that is. There is no coordination whatsoever. Some applications scroll more per distance travelled, some less. Some support inertial scrolling, some don’t. Some have more inertial acceleration, some less.

Configuring scrolling speed (if your compositor even allows that, isn’t that right Mutter?) to work well in e.g. Firefox will result in speeds that are way too quick for the dozens of chromiums you have installed and cannot reasonably configure while making it right for chromiums will make it impossible to use forwards/backwards gestures in Firefox and applications that don’t implement inertial scrolling at all (of which there are many) will scroll unusably slowly.

It’s actually insane and completely fucked beyond repair. This entire system needs to be fundamentally re-done.

There needs to be exactly one place that controls touch pad (and mouse for that matter) scrolling speed and intertial acceleration, configurable by the user. Any given application should simply receive “scroll up by this much” signals by the compositor with no regard for how those signals come to be. My browser should never need to interpret the way my fingers move across the touch pad.

Accel key

Command/super is just a better accel key than control. Super is almost entirely unused in Linux (and Windows for that matter). Using it for most shortcuts makes it trivially possible to make the distinction between e.g. copy and sending SIGTERM via ^C in a terminal emulator. No macOS user has ever been confused about which shortcut to use to copy stuff out of a terminal because CMD-c works like it does in any other program.

It also makes it possible to have e.g. system-wide emacs-style shortcuts (commonly prefixed with control) and regular-ass CUA shortcuts without any conflicts. C-f is one char forwards and CMD-f is search; easy.

Unified Top bar/global menu

Almost every graphical application has some sort of menu where there’s a button for about, help, preferences or various other application-specific actions. In QT apps aswell as most fringe UI frameworks, it’s placed in a bar below the top of each window as is usual on Windows. In GTK apps, it’s wherever the fuck the developer decided to put it because who cares about consistency anyways.

For the uninitiated: On macOS there is one (1) standardised menu for applications to put and sort all of their general actions into. It is part of the system UI: almost the entire left side of the top bar is dedicated to this global menu; populated with the actions of the currently focussed application.

If you’re used to each application having this sort of menu in the top of its window, having this menu inside a system UI element that is not connected to the application instead will be confusing for all of 5 seconds and then it just makes sense. It’s always in that exact place and has all the general actions you can perform in this application available to you.

There is always a system-provided “Help” category that, along with showing macOS help and custom help items of the application, has a search function that allows you to search for an action in the application by name. No scouring 5 different categories with dozens of actions each to find the one you’re looking for, you just simply search for the action’s name and can directly execute it. It even shows you where it’s located; teaching you where to find it quickly and allowing for easy discovery of related functions.

When you press a shortcut to execute some action in the app, the system UI highlights the category into which the executed action is organised; allowing you to find its name and (usually) related actions.

Speaking of shortcuts: When you expand a category, it shows the shortcut of every action right next to the name. This allows for trivial discovery of shortcuts; it says it right there next to the name of the action every time you go and use it.

This is how you design a UI that is functional, efficient, consistent and, perhaps even more importantly, accessible. Linux should take note.