[-] ashx64@lemmy.world 0 points 1 day ago* (last edited 1 day ago)

I don't really mind. 90hz is my sweet spot. It feels smooth enough and I'm not unnecessarily taxing my hardware for comparatively little improvements.

The only valid complaint I see is that 120hz is a little more versatile because it divisible by 24 and 30, while 90hz is only divisible by 30. So not as good for content that runs at 24fps. But even then, I still don't mind, I don't notice any presentation issues.

[-] ashx64@lemmy.world 3 points 1 day ago

Brew applications are also unsandboxed unless the app developer chose to opt-into sandboxing.

Personally, I while I love sandboxing, I chose to use brew and other third-party installation methods because I didn't want to use the App Store (and actually couldn't unless I signed in using an Apple account, which I didn't want to do).

[-] ashx64@lemmy.world 5 points 2 days ago

If you use apps from the App Store, they will be sandboxed.

If you download apps elsewhere, they may or may not be sandboxed. It's an opt-in thing.

Whether you choose to have guaranteed Sandboxing from the App Store but at the cost of Apple's increased meddling is up to you.

[-] ashx64@lemmy.world 6 points 5 days ago* (last edited 5 days ago)

They said GUI everything AND "just works". I was more so referring to the latter.

My point is that nothing "just works". With immutables, your system is less likely to break after updates, but introduce other headaches.

On a traditional distro, you can use pretty much any format. Traditional packages like deb/rpm, flatpak, snap, Nix, distrobox, etc.

That's not the case for immutables. Bazzite primarily uses flatpak, but (1) not all apps are available as flatpaks, (2) not all apps work well as flatpaks, like IDEs, (3) apps may have permission issues that require some know-how and tweaking to fix. Bazzite also comes with Homebrew and Distrobox, but (1) Homebrew doesn't have many GUI apps for Linux, (2) apps may not behave as expected in containers and don't integrate as well. Finally, as a final resort, there's layering but that (1) requires the terminal, (2) may not be allowed in the future as Universal Blue is going more bootc native without rpm-ostree support, (3) may not even run Fedora in the future if they like their "distroless" version more.

[-] ashx64@lemmy.world 8 points 5 days ago

There is no right answer. While I love immutables, they bring their own set of problems to the table.

[-] ashx64@lemmy.world 2 points 5 days ago

The problem with entire concept is the assertion that “after updates are run, the expected values are updated”. If the administrator can cause the expected values to be updated, you must assume that an attacker who can replace GRUB, in your example, can too, rendering the whole thing ineffective

This TPM stuff is focused on verifying the integrity of the the boot chain. It's meant to protect against things like replacing GRUB or changing GRUB options in a malicious way. If that stuff is detected, the system won't boot.

It's goal is not to prevent malicious changes in userspace, after the system is booted. Protections against malicious userspace modifications must come elsewhere, like SELinux, AppArmor, sandboxed apps, Wayland, etc.

If the administrator can not cause the expected values to be updated, we’re into an Android like situation, where the vendor decides what you’re allowed to run on your machine. Neither outcome is better than what we have now

What do you mean by vendor here? Initially we were discussing applications doing some sort of system integrity check to decide whether or not the application would run. But now it seems like you are referring to the distro deciding whether or not you are allowed to do things.

But again, these checks are just for the OS and it would not make sense to try and turn this into a DRM-like system when Secure Boot is much better suited for that task.

And distros already control what you can and cannot do by how they choose to build the OS. Lets consider Aeon and Universal Blue.

Aeon is an OS that implements things that Poettering is discussing. Uses TPM to verify the integrity and unlock the disk if everything is fine. It also is immutable, which limits user customization in some ways as part of its philosophy. It discourage OS modifications and encourages use of Flathub and distrobox.

The Universal Blue family of distros does not implement Poettering's stuff (though there is an option to do so). But it has similar restrictions as Aeon, discourages OS modifications, encourages use of Flathub/Homebrew/Distrobox.

My point is that verifying the boot chain integrity largely does not matter when it comes to user choice. While the two I mention do have restrictions, they are only philosophical, you could build a system that has these boot chain integrity checks and it not immutable. Measured Boot is great for this task because it puts the user is control, you don't need to worry about the software being signed with some third party's key to boot.

Lennart Pottering has an unfortunate habbit of deciding to fix problems that don’t actually need fixing, then coming up with a vastly overcomplicated solution

I agree in some respects. I like immutable distros, flatpaks, and sandboxed/containerized stuff, but sometimes you just need to install software on the host, unsandboxed. The big thing is that immutable distros want the OS and software on top to be cleanly separated.

Some say to use Hombrew, which will take up quite a bit of space and will not always work (like SELinux permission issues) and I don't necessarily like it how puts all its dependencies on your PATH.

Notably, Systemd came up with system extensions. Seems complicated, have never gotten around to using them.

Then I look over at BSD land and their solution is stupidly simple. OS stuff goes into places like /usr/bin while user installed stuff goes into /usr/local/bin. I don't really see why immutable distros can't just have a normal package manager but have everything installed to a different place like /usr/local/bin and put that on the PATH.

[-] ashx64@lemmy.world 3 points 6 days ago

The problem I see with that is that these values are far from regular. At the very least, the TPM will be checking the Linux kernel, bootloader, BIOS firmware. Any update to those will result in different measurements. And it's not just the version that matters, but also the configuration. And there's more things the TPM can measure, like connected hardware devices.

To reiterate, it's not the case that the distro provides a hash of what the measurement should be. When you install, the actual software gets installed gets measured and recorded. That first measurement is automatically trusted, assumed to be good. It's unique to your machine. Your machine will only boot so long as those measurements match. Those measurements only get updated when measurements are re-run, which is done after system upgrades.

Creating an allow list that works for most people would be next to impossible. The Secure Boot approach is much more suited for this task. I can only see this TPM allow-list approach working on corporate machines with controlled hardware and software updates. But at that point, using a custom secureboot key is easier and less liable to break.

[-] ashx64@lemmy.world 8 points 6 days ago

It's not vague at all if you know Poettering and have watched his talks.

This is about securing the boot chain to ensure the integrity of the OS. Ie, someone hasn't replaced your GRUB with one that looks exactly the same but secretly records your disk password.

It does so in a decentralized way, so anything like Play Integrity would not make sense in the slightest. It's the TPM chip measuring values and ensuring they match previous recorded values (and the values to change, such as after updates, so after updates are run, the expected values are updated). It's not a Secureboot-like system that would make it more feasible to have a Play Integrity-like system.

[-] ashx64@lemmy.world 34 points 6 days ago

That's not at all what this about. Poettering has given quite a few talks about this subject, that being Linux boot chain verification and integrity.

One of the core concepts is measured boot. The TPM on your CPU measures the values of various pieces of software in the boot chain. If a measurement does not match, then the system will not boot because it could be compromised.

And unlike secure boot, this is a decentralized system. It's not some corporation like Microsoft saying "this software is signed with this approved key, so it may boot". It's your own system checking the software and recording the expected value so that when you boot up, it checks again to make sure they match.

It's not about apps asking doing things like DRM checks or anything like that. In fact, it can't. GrapheneOS implements a system just like this to ensure the OS has not been tampered with.

13
Minecraft 26.1 Snapshot 5 (www.minecraft.net)
[-] ashx64@lemmy.world 2 points 2 weeks ago

7-zip does have a linux CLI, which works well.

The most basic command you need to use is 7zz x archive-name to extract an archive. Building a GUI around it doesn't seem like it would be too much trouble honestly, wonder if anyone has done that.

[-] ashx64@lemmy.world 8 points 2 weeks ago

You shouldn't do sudo pacman -Sy banana. That results in a "partial upgrade", which Arch doesn't support. Instead, you want to do sudo pacman -S banana.

26
submitted 2 weeks ago* (last edited 2 weeks ago) by ashx64@lemmy.world to c/gnome@discuss.tchncs.de
10
Minecraft 26.1 Snapshot 4 (www.minecraft.net)
submitted 2 weeks ago by ashx64@lemmy.world to c/minecraft@lemmy.world
[-] ashx64@lemmy.world 42 points 2 weeks ago* (last edited 2 weeks ago)

I wish they were more clear on this. Is this about existing AI features? Future AI features? AI images?

My only real complaint is that I would prefer it to never show the AI answer by default, I would just like to see the button to get the AI answer. And to be clear, I know I can set DDG to behave that way, but I do a lot of searches in private tabs too.

I actually do find the AI summary helpful. When it comes to basic programming questions, like to remind me of syntax or arguments, it gives a useful answer most of the time.

But I don't want to see AI images. And I'm hesitant to agree to future AI features because of how aggressively some companies push them in your face.

30
submitted 2 weeks ago* (last edited 2 weeks ago) by ashx64@lemmy.world to c/linux@lemmy.ml

Warning

This is not meant for novice users. This is for those who (1) really like sandboxed apps, (2) like to tweak the permissions of their apps, and (3) are comfortable using the command line.

And of course, don't trust strange scripts on the internet without at first reading them and understanding them.

About

This script uses flatpak as the sandbox, which is convenient as it allows you to use existing tools like Flatseal to configure the sandbox.

I built this because I like my apps sandboxed. I will mostly use it for playing games. This will let me tailor the permissions the games need perfectly, ie no network for single player games and network for multiplayer games.

And to answer the question of "Why not Steam/Heroic/Bottles/Lutris". There's a few reasons. This script keeps games sandboxed from each other, is lighterweight, and was made for my own enjoyment.

I've also been working on a bubblewrap version that reuses host binaries and libraries which I may share later. It's lighter weight and in theory more secure (less shared with host, better for browsers thanks to having access to unprivileged namespaces).

But anyways...

How to use

There are two files. The script, called "sandbox", and the template flatpak manifest, called "sandbox.yml".

To run the script, manually install "sandbox.yml" to ~/.local/share/sandbox/sandbox.yml. Or, you can edit the script and update the variable TEMPLATE_PATH to where ever you want.

Then, to create a new sandbox, you just need to run ./sandbox app-name.

The script roughly does the follow

  1. Makes sure you entered a valid app name
  2. Makes sure you have flatpak-builder installed (will install it if not, also note the script uses a user remote)
  3. Builds an empty flatpak that depends on Freedesktop 25.08 runtime
  4. Installs the flatpak

The first time the app is run (flatpak run my.custom.app-name), a script will be created inside the sandboxed home called "start". On subsequent launches, this is executable that will be run.

Say if I wanted to play a Windows game, I would set the start script to umu ./path/to/game.exe.

But it can do anything. I also tested with the firefox .tar.xz and it worked without issue.

The script

sandbox.yml

app-id: domain.publisher.Name
runtime: org.freedesktop.Platform
runtime-version: '25.08'
sdk: org.freedesktop.Sdk
command: launcher
finish-args:
  - --persist=.

modules:
  - name: launcher-setup
    buildsystem: simple
    build-commands:
      - mkdir -p /app/bin
      # verify if 'start' exists. If not, create a default Hello World script.
      - |
        sh -c 'cat > /app/bin/launcher <<EOF
        #!/bin/sh
        TARGET="\$HOME/start"
        
        if [ ! -f "\$TARGET" ]; then
          echo "Creating default start script at \$TARGET..."
          echo "#!/bin/sh" > "\$TARGET"
          echo "echo Hello World from the sandbox!" >> "\$TARGET"
          chmod +x "\$TARGET"
        fi
        
        exec "\$TARGET" "\$@"
        EOF'
      - chmod +x /app/bin/launcher

sandbox:

#!/bin/bash

# bash safety options
# -e exits on failure
# -u exits on unknown variables
# -o pipefail exits on failed pipe
set -euo pipefail

################################################################################
### Usage Clause ###
####################

# make sure argument is provided for APP_NAME
if (( $# != 1)); then
    echo "Error: too few or too many arguments"
    echo "Usage: $0 app-name"
    exit 1
fi

################################################################################
### Configuration ###
#####################

# app details
DOMAIN="my"
PUBLISHER="custom"
APP_NAME="$1"

# flatpak manifest template location
TEMPLATE_PATH="$HOME/.local/share/sandbox/sandbox.yml"

################################################################################
### Functions ###
#################

# make sure flatpak version of flatpak-builder is installed
# installs it if necessary
check_dependencies() {
    if ! flatpak list --app | grep -q org.flatpak.Builder; then
        echo "flatpak-builder is not installed, installing now..."
        flatpak --user remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
        flatpak --user install --noninteractive flathub org.flatpak.Builder
    fi
}

# make sure a string only contains letters, numbers, and dashes
validate_string() {
    local input="$1"
    local var_name="$2"
    if [[ ! "$input" =~ ^[a-zA-Z0-9-]+$ ]]; then
        echo "Error: $var_name ('$input') contains invalid characters."
        echo "Allowed: letters, numbers, and dashes only."
        exit 1
    fi
}

cleanup() {
    # check if WORK_DIR exists to avoid errors if mktemp failed
    if [[ -d "$WORK_DIR" ]]; then
        echo "Cleaning up temporary directory..."
        rm -rf "$WORK_DIR"
    fi
}

################################################################################
### Execution ###
#################

# ensure flatpak-builder is installed as a flatpak
check_dependencies

# validate DOMAIN, PUBLISHER, and APP_NAME
validate_string "$DOMAIN" "DOMAIN"
validate_string "$PUBLISHER" "PUBLISHER"
validate_string "$APP_NAME" "APP_NAME"

# finalize app ID
APP_ID="$DOMAIN.$PUBLISHER.$APP_NAME"

# create temporary directory in current directory
WORK_DIR="$(mktemp -d -p "$PWD")"

# check if WORK_DIR was created
if [[ ! "$WORK_DIR" || ! -d "$WORK_DIR" ]]; then
    echo "Error: could not create temp dir"
    exit 1
fi

# run cleanup function on successful exit or on failure
trap cleanup EXIT

# copy flatpak manifest to WORK_DIR
cp "$(realpath "$TEMPLATE_PATH")" "$WORK_DIR/$APP_ID.yml"

# edit the app ID of the flatpak manifest
sed -i "s/domain.publisher.Name/$APP_ID/g" "$WORK_DIR/$APP_ID.yml"

# build the flatpak
flatpak run --filesystem="$WORK_DIR" org.flatpak.Builder \
    --user \
    --force-clean \
    --repo="$WORK_DIR/$PUBLISHER" \
    "$WORK_DIR/build_dir" \
    "$WORK_DIR/$APP_ID.yml"

# install the flatpak
flatpak --user install --noninteractive --reinstall "$WORK_DIR/$PUBLISHER" "$APP_ID"
view more: next ›

ashx64

0 post score
0 comment score
joined 2 weeks ago