Ubuntu keeps getting better and better :smile: and very stable powerhouse too.

View this comment - View article - View full comments

Quoting: tfk

Quoting: dziadulewicz

Quoting: nwildner

Quoting: dziadulewicz

If you install it via the new Flatpak package from Flathub, you still need to set up some udev rules from the GitHub.

Now this is not good again for normal users; why are these "udev rules" (whatever they are) not just included with the Flatpak?

The fact here is that Oversteer do have udev rules - https://github.com/berarma/oversteer/tree/master/data/udev [External Link] - but Flatpaks do not distribute/install udev rules and that is by design - https://github.com/flatpak/flatpak/issues/961 [External Link] .As @tfk pointed out on the previous comment, udev access requires operating system admin and there is no API/ABI for the user to manipulate it.

Flatpaks use a different philosophy and they don't install stuff around normal configuration directories like `/etc`.

Also, it is hard to track `udev` rules for every existing device and software on earth in a centralized fashion, and some of them fall into more generic rules like "USB Input device" and you have to make customization that would apply to your specific device. That's why there is no curated list of udev rules for every device that exists, and it is up to the Linux Distribution providers to create a packages with specific udev rules if you think those oversteer udev rules should be bundle on every distribution

Some distros provide a really good amount of Udev rulesets for different devices. Examples:

- retroarch-autoconfig-udev-git - https://aur.archlinux.org/packages/retroarch-autoconfig-udev-git [External Link] - Rules to autoconfig usb and bluetooth gamepads for retroarch.
- nintendo-udev - https://aur.archlinux.org/packages/nintendo-udev [External Link] - Rules for joycons (and to fix controller ownership for steam). I can confirm this also works for Datafrog and 8BitDo controllers as well.

Udev rules can also be pretty destructive as well because it also depends on systemd changes. I had a 100% CPU usage experience in the past with OpenRGB keyboard backlight rules but the developer fixed it really quickly - https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/4166 [External Link] - I think this is a good reason to not bundle "by default" millions of udev rules that target specific devices.

So it will forever be an issue and manual tinkering is required? What about Snap? Udev workaround in Snaps [External Link]

That's the thing. I don't see this as a problem. The only external entity I trust with this is my distribution packaging team.

The rest I want to inspect and define myself.

An example I can give is my Wooting keyboard. Wooting provides an appimage for their management tool. But the udev rules are listed on their website. They don't try to force these rules on my system via an installer.

And that is good because ultimately I'm the one who is responsible for my system.

What do you mean you don't see this as a problem? This is not about you and me (seasoned Linux users). This means difficulty to install software with required (basic) functionality. So at least Flatpak does not suit this application.

Normal people will NEVER tinker if the installation package does not suffice installing it.

I think we have a MAJOR problem here once more if this same issue touches many more apps. Steering Wheel Manager is the only truly recommended Linux app on what it does as alternative to Windows equivalents (where normal people click and install and start to use it with all functionality).

View this comment - View article - View full comments

Quoting: nwildner

Quoting: dziadulewicz

If you install it via the new Flatpak package from Flathub, you still need to set up some udev rules from the GitHub.

Now this is not good again for normal users; why are these "udev rules" (whatever they are) not just included with the Flatpak?

The fact here is that Oversteer do have udev rules - https://github.com/berarma/oversteer/tree/master/data/udev [External Link] - but Flatpaks do not distribute/install udev rules and that is by design - https://github.com/flatpak/flatpak/issues/961 [External Link] .As @tfk pointed out on the previous comment, udev access requires operating system admin and there is no API/ABI for the user to manipulate it.

Flatpaks use a different philosophy and they don't install stuff around normal configuration directories like `/etc`.

Also, it is hard to track `udev` rules for every existing device and software on earth in a centralized fashion, and some of them fall into more generic rules like "USB Input device" and you have to make customization that would apply to your specific device. That's why there is no curated list of udev rules for every device that exists, and it is up to the Linux Distribution providers to create a packages with specific udev rules if you think those oversteer udev rules should be bundle on every distribution

Some distros provide a really good amount of Udev rulesets for different devices. Examples:

- retroarch-autoconfig-udev-git - https://aur.archlinux.org/packages/retroarch-autoconfig-udev-git [External Link] - Rules to autoconfig usb and bluetooth gamepads for retroarch.
- nintendo-udev - https://aur.archlinux.org/packages/nintendo-udev [External Link] - Rules for joycons (and to fix controller ownership for steam). I can confirm this also works for Datafrog and 8BitDo controllers as well.

Udev rules can also be pretty destructive as well because it also depends on systemd changes. I had a 100% CPU usage experience in the past with OpenRGB keyboard backlight rules but the developer fixed it really quickly - https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/4166 [External Link] - I think this is a good reason to not bundle "by default" millions of udev rules that target specific devices.

So it will forever be an issue and manual tinkering is required? What about Snap? Udev workaround in Snaps [External Link]

View this comment - View article - View full comments

Good to see Linux there on the poster with rest of the mainstream platforms nowadays :tongue:

View this comment - View article - View full comments

If you install it via the new Flatpak package from Flathub, you still need to set up some udev rules from the GitHub.

Now this is not good again for normal users; why are these "udev rules" (whatever they are) not just included with the Flatpak?

View this comment - View article - View full comments

There is also a DEB [External Link] package for Ubuntu but it is hard to find through the website. Flatpak is not installed on Ubuntu by default.

View this comment - View article - View full comments

Quoting: ThibugThe price doesn't surprise me for this kind of laptop. It's not really useful for someone like me, but I can really see some professionals using it as a daily driver. Being able to use a Wacom stylus to draw can be really useful on some field jobs (updating plans, drawing sketches for a customer...)

And the option to have a 4G module is the cherry on top for field workers, no need to use your phone battery!

To use this as a professional for field work with 5 hour battery (with light web browsing)? A field worker with this one would need extra battery packs in a backpack with em if doing anything other than what they call light browsing then. Or what do you mean or what am i missing :neutral:

How is it even possible that we're soon in '25 and our devices battery lives are nothing sort of joke and apparently we fly gadgets to other planets like Mars.

View this comment - View article - View full comments

Foldable but not affordable: 5 hours battery life promised for "light web browsing" in this price :cry:

View this comment - View article - View full comments

Quoting: Klaas

Quoting: JarmerBoilingSteam specifically says this about Manjaro:

“… I’m confident … probably …”

Yes. Probably confident. I agree that Manjaro has done unfortunate things.

Then again what distros have not? Some dropped using pure Arch after they moved to systemd which was found unfortunate with some (insane reason IMO but yeah they did).

Arch seems to be best as a BASE (like SteamOS) rather than a distro (which it's also kind of is not since user chooses what's to be installed, apart from few things).

View this comment - View article - View full comments

How was this even possible? Isn't SteamOS immutable for its boot to start with?

I hope something serious was technically learned now to not repeat this possibility ever again by a SINGLE GAME.

View this comment - View article - View full comments