• 14 Posts
  • 17 Comments
Joined 2 years ago
cake
Cake day: June 14th, 2023

help-circle



  • I run Fedora Silverblue on a N100.

    It’s very usable. For most actions, it feels pretty similar to my much more powerful desktop. but has some limitations.

    • I am able to run two 1440p monitors at 144hz via HDMI, but the screen occasionally blacks out for a second due to HDMI limitations. Running at a lower refresh rate should avoid the issue.
    • Gnome shell animations aren’t running at 144hz, even with triple buffering (never tested if it maintains 144hz with just one monitor at 1440p). Haven’t tested KDE.
    • I am able to comfortably run Minecraft with 60+ fps with performance enhancing mods, though at like 5 chunks rendering distance. Honestly it’s fun to play this way, feels nostalgic. Though performance will dramatically drop if you try to play a video at the same time, though dropping it to like 480p or even 720p helps a lot.

















  • Don’t believe so, best that’s currently available is skimming through the video to look at the slides.

    Here’s my short summary of the presentation, I tried to denote what’s being worked on (open PR), what’s kinda being done (WIP), and things stuff they’d like to be done in the future (wishlist). May be somewhat wrong.

    • Flatpak is stagnant
    • Red Hat is working on a better way to preinstall flatpak apps (open PR)
    • Flatpak should is slowly moving towards OCI and away from ostree (more tooling available, don’t need to maintain their own tools)
    • Better permission handling that is more backwards compatible (open PR)
    • Should directly use Pipewire instead of Pulseaudio (WIP)
    • Allow user namespaces in flatpak sandbox (WIP)
    • Move dbus proxying into dbus brokers (wishlist)
    • Improve network sandboxing (wishlist)
    • Improve drivers handling, currently drivers need to be built for each runtime, could cause issues if using EOL app on new hardware (wishlist)
    • Work on portals directly improves flatpak



  • I haven’t watched the video yet, but keep in mind “resource usage” being lower isn’t always better.

    For example, Plasma had an issue for some people where animations would not happen, freeze the system momentarily, and stutter. The reason why turned out that these people were using slow drives. Plasma was trying to load the bytecode for the QML animations from disk, but the IO operation took too long so the animation suffered. Had this bytecode been stored in memory, the performance would have been better.

    But I also don’t want to discount the fact that some (perhaps most) of the time, high resource usage is a bad thing caused by poor programming and using technologies that are heavier, like Electron. Whether those tradeoffs are worth it are another matter.

    I wish more developers actually used their software low-end devices to find performance issues. I recently got an Intel N100 and it’s actually been a decent experience on Linux, though Gnome shell’s animations are a bit stuttery even on Gnome 48. Haven’t tested any other desktop though.