that_leaflet

joined 2 years ago
MODERATOR OF
[–] that_leaflet@lemmy.world 2 points 22 hours ago* (last edited 22 hours ago)

A recovery code. I did a test install of Aeon and was given the code: dhnhlgc-fbndjbni-ufrkcfnk-nfebvtut-ftkkiiur-tijidtub-hujnucgu-erduhije

64 digits, but only alphabetical and a certain subset (16/26) due to weirdness of keyboard layouts.

[–] that_leaflet@lemmy.world 1 points 23 hours ago (2 children)

TPM is used for measured boot. Measured boot can check various parts of the system to ensure they are the expected values haven’t been tampered with. You don’t want a part of the system to be replaced with malware and not realize it.

If it detects something changed, it won’t release its secret. It may signal to you that something malicious was done or something benign that the OS updated didn’t account for.

[–] that_leaflet@lemmy.world 8 points 2 days ago (7 children)

TPM unlocking FDE is complicated for me. I fully understand measured boot and support it, but it seems less secure to me than manually unlocking the disk.

Once the disk is unlocked and you’re put onto the display manager, I feel like there are many more vulnerabilities that could be exploited to gain access to your data.

With manually entering the disk password, the data is locked. You either need to brute force it or use the XKCD wrench method.

So I feel TPM+Pin is the best for security. Unfortunately Aeon, which is based on OpenSUSE and implements TPM, doesn’t support TPM+Pin. I think it’s mainly due to how poor and widespread TPM support is. It could lock you out entirely.

[–] that_leaflet@lemmy.world 13 points 3 days ago (4 children)

Not any PiP window, only ones that use the protocol. Firefox should use it. Though I'd be surprised if there wasn't some Kwin extension to automatically make the PiP windows always on top like the extension you mentioned or the Gnome "PiP on top" extension

[–] that_leaflet@lemmy.world 10 points 4 days ago

I didn't say people were forced to use snap, just that they're the default. But if they're to be made the default, they should be a good experience.

  • A couple years ago they switched Gnome Calculator a preinstalled snap and it had very long launch times despite being such a simple app.
  • Later on they made Firefox a snap (and removed the deb) despite it having long launch times and no native messaging support (used by stuff like password managers).
  • They made a snap version of Steam and pushed it to the stable channel despite it having many known issues. Those using the graphical store only have the option to get the snap version of Steam as the store is snap-only. It took them a while to make games work by removing a bunch of snap's sandboxing for it.

As for the sandboxing stuff. Ubuntu using AppArmor, a Mandatory Access Control (MAC) that is used to make the system more secure by creating profiles used to confine certain pieces of software. If they try to do something the profile doesn't allow them to do, it gets blocked.

Snap uses AppArmor to manage the sandbox of snaps. However, AppArmor isn't the only MAC around. Fedora and OpenSUSE use something else called SELinux, which has a similar purpose. But snap doesn't speak SELinux, it only speaks AppArmor. So none of the fancy AppArmor profiles used to contain snaps actually work on those distros, the sandbox it does have is so weak it's insignificant. Canonical could have addressed this by adding SELinux support to snap, but they haven't, they pretty much only care about Ubuntu and Debian. And as I mentioned before, Ubuntu patches AppArmor to add more functionality. But they have failed to upstream these patches, so only Ubuntu (and maybe Debian?) have access to the strongest sandboxing snap can offer.

On the other hand, flatpak uses bubblewrap to sandbox its applications. Bubblewrap uses standard Linux security features to sandbox apps rather than a specific MAC. That means the flatpak sandbox is strong regardless of which distro you are using. Although it does have some downsides. Flatpak doesn't speak to either MAC, which can be a problem since the MAC can confine the flatpak application more than is expected. For example, OpenSUSE ships some SELinux policies that allows Wine/Proton to function as expected. However, these policies don't get installed when you use Steam or any other launcher as a flatpak. It's something you have to do manually. Meanwhile if flatpak actually talked to the MAC (like snap does with AppArmor), then this wouldn't be a problem.

[–] that_leaflet@lemmy.world 12 points 4 days ago (3 children)

By far the worst part about Ubuntu is snap. Canonical has failed its community and the wider Linux community with it in so many ways.

For Ubuntu users

  • Canonical replacing working debs with snaps. Whether it be long launch times, missing functionality, or broken. They have addressed such issues, but they should have been fixed before becoming the default.
  • Terrible snap store moderation. Malicious apps have made their way onto the store numerous times. Old abandoned apps are not hidden.

For wider community

  • Broken or incomplete sandboxing on anything not Ubuntu. They not only rely on AppArmor, but also downstream patches. You have no sandbox on distros such as Fedora and OpenSUSE.
  • Canonical has full control of the store.

There are other smaller controversies, like Mir, Unity, and Upstart, but none are as bad as snap.

[–] that_leaflet@lemmy.world 4 points 5 days ago* (last edited 5 days ago)

There’s still plenty of inefficiencies to criticize.

  • Electron apps bundle an entire browser dedicated just to running the app. That takes up storage space and requires loading multiple instances of electron in memory if you’re running multiple electronic apps. Would be better if these apps could all share the same dynamically linked Chromium instance to run. Web apps are a decent alternative, but can lack desktop integration.
  • Rise of interpreted languages like JavaScript, though this is mitigated by JIT compilation.
[–] that_leaflet@lemmy.world 1 points 5 days ago* (last edited 5 days ago)
[–] that_leaflet@lemmy.world 6 points 5 days ago

Yup, just another hot fix update. There's been 4 of them so far this series. 1.21.1, 1.21.3, 1.21.7, and now 1.21.8.

[–] that_leaflet@lemmy.world 2 points 6 days ago (1 children)

A system that has updated from say Ubuntu 16.04 to 24.04 is different from a system that fresh installed Ubuntu 24.04.

The upgrade process is imperfect. It may keep older software around, old configuration files. Users may also make small tweaks and forget about them.

I remember like a year ago OpenSUSE Tumbleweed broke for users who had old installs. They were using the old networking stack, the upgrade system never migrated them to the newer networking stack. And since OpenSUSE’s test suite was only made up of new installs, the issue wasn’t caught until after it was released.

Fedora Atomic tries to solve this issue. When you update, the entire root filesystem is effectively replaced (the immutable parts anyway). Though it tries not to touch manual changes you make in places like /etc. It does something called a 3 way merge to preserve your changes and does keep better track of them than traditional distros.

[–] that_leaflet@lemmy.world 5 points 6 days ago (3 children)

I think I had this bug before where I had to change the tty to actually get into the graphical environment.

I used Aeon before, it wasn't bad. The default apps were better than Fedora Silverblue's (it had Tweaks preinstalled, didn't have Firefox installed as an RPM). It uses Distrobox rather than Toolbox, which is nice because Distrobox lets you specify a custom home for each box. Though Distrobox hasn't seen any development these past few months and their decision to use POSIX compliant shell script seems like a maintenance nightmare. Toolbox uses Go.

But my biggest problem with MicroOS is that I don't feel like the update mechanism is as robust as Fedora Atomic. At the end of the day, it's using zypper and btrfs snapshots. It doesn't have the same protections against configuration drift, you can only rollback to versions of the OS you've previously installed (with Fedora Atomic you can rollback to any specific commit, even ones you've never installed).

And Fedora Atomic's bootc is super nice for customizing your image.

[–] that_leaflet@lemmy.world 2 points 6 days ago* (last edited 6 days ago)

Personally, I am not a fan of this proposal. I'm one of the few people who actually like Fedora Flatpaks. I like

  • The focus on FOSS
  • The focus on more open software (standards that are not patented or have royalties)
  • More consistent build practices
  • Security (all apps use the latest Fedora Platform runtimes, pull all their dependencies from Fedora repos)
  • Better deduplication (vendored dependencies are all RPMs, Flathub dependencies may pull different versions or built differently which would limited deduplication)

Though they're not perfect. Perhaps the biggest issue is the lack of codec support. Personally, I think it would be better to rework this proposal to instead filter out the footguns in the Fedora Flatpaks, such as media players and browsers.

I also don't believe there's any plans in the proposal to allow the user to easily remove the filter in the GUI, even though there is a toggle to make Flathub available in the GUI. The two proposals would in effect make it more difficult to obtain software curated by Fedora.

 

In short, this change proposal seeks to get rid of Fedora Flatpaks for Atomic desktops. Fedora Flatpaks will still be used for the preinstalled apps, but all (or most?) other Fedora Flatpaks would be hidden by default.

Note this proposal does not enable Flathub, that's a separate Change proposal (currently not up for FESCO voting): https://discussion.fedoraproject.org/t/proposal-enable-flathub-by-default/157011

 

Haven't testing this myself, but I was quite intrigued by how simple this is.

Though the images aren't signed.

 

From Sebastian Wick’s Mastodon

Blender is getting HDR on Linux via Wayland before Windows! This isn't by accident, but shows how creating a system with a different design creates better results for users and application developers.

Firefox is in this same boat too. It will get HDR support on Linux* sooner than Windows. Firefox currently only supports HDR on MacOS.

view more: next ›