neobrain

Yes, this had been temporarily permitted until recently, and AFAIK they continue doing so illegally at the moment.

For context, this refers to "Chat Control 1.0", allowing facebook and other messaging providers to scan chats for harmful content (which they had been temporarily allowed to do by a recently expired law).

This is still problematic, but the far more dangerous Chat Control 2.0 that would weaken end-to-end-encrypted messengers like Signal is not being discussed here.

Not to diminish the gravity of the new development, but the defeatist "no way to prevent this" narratives that are already popping up here are getting old -- when in fact it looks like 2.0 is off the table for good because protest against it has proven effective.

See https://asahilinux.org/2024/01/fedora-asahi-new/#speakers

The effect is understated there, perhaps because Apple speakers are actually somewhat usable without this feature. For the X13s, the speakers might as well not exist in the current state on Linux.

Unlikely. I've been daily-driving the predecessor (X13s). While it's usable and technically all drivers are there, it's far from "without pain" due to endless number of small but annoying quirks. Just to give you an idea: boot fails 4 out of 5 times, external displays aren't recognized unless plugged in/out several times, sporadic resets during overnight sleep, etc. On top of that speakers will sound prohibitively tinny due unimplemented software-side speaker protection. I haven't tried T14s, but at least the audio issues will still apply there.

Apple devices supported by Asahi are a far more polished experience.

This seems to be mainly brought up by people concerned they'd lose banking apps than people who actually have issues. It's rooted phones that often get blocked, whereas those that run LineageOS/microG without rooting are largely fine.

Yes, there are certainly banks that block more aggressively, but if you look at e.g. iodéOS's forums most of them work fine: https://community.iode.tech/t/banking-finance-and-insurance-...

Anecdotally, I've also seen a lot of stories of people reaching out to support about overblocking actually seeing success. Apparently there are often enterprise reasons for the block and it literally just needs a customer to complain for engineering to be able to act.

Is there some special feature I'm missing? I would only call it a marginal improvement. If that. I fail to see what the big deal is.

Among the "GPU rendered terminal" options, afaik Ghostty is the only one that has proper search/context menus, tabs, and scroll bars. I'm sure it's easy to get by without, but compared to the overall value-add of these terminals (which exists indeed but isn't tremendous either) I find it quite a significant downgrade, so I appreciate that Ghostty has both.

With Dioxus, program logic compiles to native code instead of running it through a JS engine, and it ships its own HTML renderer (Blitz) instead of bundling a whole browser. So it's a lot more lightweight and performant than Electron.

As a minor bonus, the live-reload is also faster than what frameworks like React do. It truly has subsecond latency, which isn't exactly a game changer but is nice when iterating on visual details of an app.

(for context, you're replying to the author of an alternative nix input pinning mechanism, which means... they're probably aware of all that and yet they chose their wording like this anyway)

They are hiring specifically for that: https://old.reddit.com/r/ProtonDrive/comments/1spx14d/proton...

Nothing public yet, but this is the Nix output for taking the screenshot, to be executed via `nix run .#screenshot`:

        outputs.apps.x86_64.screenshot = {
          type = "app";
          program = toString (pkgs.writeShellScript "screenshot-script" ''
            set -euo pipefail

            EMU_SDK="${androidEmulatorComposition.androidsdk}/libexec/android-sdk"
            ADB="$EMU_SDK/platform-tools/adb"
            EMULATOR="$EMU_SDK/emulator/emulator"
            APK="${self.packages.${system}.debug}/myapp-debug.apk"

            SRC_DIR="$(${pkgs.git}/bin/git rev-parse --show-toplevel)"
            AVD_HOME="$(mktemp -d)"
            trap 'kill "$EMU_PID" 2>/dev/null; wait "$EMU_PID" 2>/dev/null; rm -rf "$AVD_HOME"' EXIT

            # Create AVD
            AVD_DIR="$AVD_HOME/screenshot.avd"
            mkdir -p "$AVD_DIR"
            cat > "$AVD_HOME/screenshot.ini" <<EOF
            avd.ini.encoding=UTF-8
            path=$AVD_DIR
            target=android-${platformVersion}
            EOF
            cat > "$AVD_DIR/config.ini" <<EOF
            AvdId=screenshot
            PlayStore.enabled=false
            abi.type=x86_64
            avd.ini.encoding=UTF-8
            hw.cpu.arch=x86_64
            hw.gpu.enabled=yes
            hw.gpu.mode=swiftshader_indirect
            hw.lcd.density=420
            hw.lcd.height=2400
            hw.lcd.width=1080
            hw.ramSize=2048
            image.sysdir.1=system-images/android-${platformVersion}/google_apis/x86_64/
            skin.dynamic=yes
            tag.display=Google APIs
            tag.id=google_apis
            disk.dataPartition.size=2G
            EOF

            echo "==> Starting emulator..."
            ANDROID_AVD_HOME="$AVD_HOME" ANDROID_HOME="$EMU_SDK" \
              "$EMULATOR" -avd screenshot -no-window -no-audio -no-boot-anim \
              -gpu swiftshader_indirect -no-snapshot 2>&1 &
            EMU_PID=$!

            echo "==> Waiting for boot..."
            for i in $(seq 1 90); do
              BOOT=$("$ADB" shell getprop sys.boot_completed 2>/dev/null | tr -d '\r') || true
              if [ "$BOOT" = "1" ]; then
                echo "    Booted after ~$((i * 2))s"
                break
              fi
              sleep 2
            done
            if [ "$BOOT" != "1" ]; then
              echo "ERROR: Emulator failed to boot" >&2
              exit 1
            fi

            # Enable dark mode
            "$ADB" shell cmd uimode night yes

            # Install and launch
            echo "==> Installing APK..."
            "$ADB" install -r "$APK"
            "$ADB" shell pm grant com.me.myapp android.permission.WRITE_SECURE_SETTINGS
            "$ADB" shell am start -n com.me.myapp/.MainActivity
            sleep 3

            # Navigate to settings screen by tapping "Notification Filters" button
            # This uses uiautomator to find the button by text for robustness
            "$ADB" shell uiautomator dump /sdcard/ui.xml
            BOUNDS=$("$ADB" shell cat /sdcard/ui.xml \
              | ${pkgs.gnugrep}/bin/grep -oP 'text="Notification Filters"[^>]*bounds="\K[^"]+' \
              || true)
            if [ -z "$BOUNDS" ]; then
              echo "ERROR: Could not find Notification Filters button" >&2
              exit 1
            fi
            # Parse bounds "[x1,y1][x2,y2]" to compute center tap coordinates
            X1=$(echo "$BOUNDS" | ${pkgs.gnused}/bin/sed 's/\[\([0-9]*\),\([0-9]*\)\]\[\([0-9]*\),\([0-9]*\)\]/\1/')
            Y1=$(echo "$BOUNDS" | ${pkgs.gnused}/bin/sed 's/\[\([0-9]*\),\([0-9]*\)\]\[\([0-9]*\),\([0-9]*\)\]/\2/')
            X2=$(echo "$BOUNDS" | ${pkgs.gnused}/bin/sed 's/\[\([0-9]*\),\([0-9]*\)\]\[\([0-9]*\),\([0-9]*\)\]/\3/')
            Y2=$(echo "$BOUNDS" | ${pkgs.gnused}/bin/sed 's/\[\([0-9]*\),\([0-9]*\)\]\[\([0-9]*\),\([0-9]*\)\]/\4/')
            TAP_X=$(( (X1 + X2) / 2 ))
            TAP_Y=$(( (Y1 + Y2) / 2 ))
            "$ADB" shell input tap "$TAP_X" "$TAP_Y"
            sleep 2

            # Capture and process screenshot
            echo "==> Capturing screenshot..."
            "$ADB" shell screencap -p /sdcard/screenshot.png
            "$ADB" pull /sdcard/screenshot.png "$AVD_HOME/raw.png"

            # Crop to content: remove status bar (top 128px) and empty space below
            # Per-App Overrides, then resize with high-quality Lanczos filter
            ${pkgs.imagemagick}/bin/magick "$AVD_HOME/raw.png" \
              -crop 1080x1100+0+128 +repage \
              -filter Lanczos -resize 540x \
              "$SRC_DIR/fastlane/metadata/android/en-US/images/phoneScreenshots/settings.png"

            echo "==> Screenshot saved to fastlane/metadata/android/en-US/images/phoneScreenshots/settings.png"
          '');
        };

Most people don't realize that the Asahi team ship features only once they work without quirks. For the set of supported hardware features, Asahi is much closer to a macOS experience than to an average x86 Linux laptop experience.

Meanwhile, Linux on my Lenovo X13s "works" but has tons of quirks: Boot fails 2 out of 3 times, the device hard-resets sometimes when waking up with a display connected, and the speakers are unusable due to lack of active overheat protection (and somehow this affects even external speakers). It technically works, but it's incredibly frustrating to use in practice.

If you plan to use Linux and don't need an ARM laptop, there's little reason to prefer a Qualcomm device over an x86 one currently. On the other hand, M1/M2 easily outperform a broad class of x86 laptops, and they have a Linux experience that's for many use cases close to on par with official vendor support.

+1 for this approach. For a mobile app, I made Nix spawn an ephemeral Android emulator instance for generating up-to-date screenshots, requiring no prior setup and leaving no lingering data around after running. Setting it up wasn't that high-effort in my case either; coming up with the idea was the hard part, the Nix code was one-shot by your favorite LLM.

Granted manually updating the screenshots isn't the most laborious task in the world, but the "upload-apk + take-screenshot + transfer-back-to-PC + edit" process is usually barely annoying enough that you end up almost never doing it otherwise (similar to the OP's experience in the closing paragraph).

Quite the contrary, actually: not using a browser extension makes you much more susceptible to phishing attacks, since your password manager won't be able to protect you from copy-pasting credentials into an imposter website.

Just injecting this here: What I've been missing is an equivalent for GitHub's "blame prior revision" feature to quickly follow through the history of individual source lines.

https://github.com/zed-industries/zed/discussions/42583

Thanks for building an awesome product :)

tl;dr for opt-out as per https://cli.github.com/telemetry#how-to-opt-out (any of these work individually):

export GH_TELEMETRY=false

export DO_NOT_TRACK=true

gh config set telemetry disabled (starting from version 2.91.0, which this announcement refers to)

The article is specifically not referring to information that's sent to Apple servers - it's about information on the phone only, accessible through forensics tools with physical device access.

Signal's server-side push notifications only contain a "wakeup" message. The actual message popup is displayed after decrypting the message contents locally on the device. Of the things you mentioned, only the time of notification is visible to Apple/Google.

If some provider like Proton states they are pricacy-focused and protect your data from governments, but can still offer loads of your private data when ordered to, that damages their privacy claim.

"Loads" of private data? When has this allegedly happened or how would it technically even be possible?

If you create an account, it may be worth looking into "starter packs", which are lists of accounts around specific topics to follow. That's an easy solution if you run into the "I don't know who to follow and there's no algorithm that'll tell me" problem.

I want a computer where I can basically install every non stock app in its own little world, where it thinks "huh, that is interesting, I seem to be the only app installed on this system".

NixOS containers are the most convenient way to do this, but those will map the entire global nix store into your container. So while only one app would be in your PATH, all other programs are still accessible in principle. From a threat-modelling perspective, this isn't usually a deal-breaker though.

There's also dockerTools, which lets you build bespoke docker/podman images from a set of nix packages. Those will have a fully self-contained and minimal set of files, at the expense of copying those files into the container image instead of just mapping them as a volume.

NixOS is very impressive but the marketing around it feels misleading. The reproducible claim needs a giant asterisk due to link rot.

It's a valid concern, though perhaps worth mentioning you will be able to restore your 10-year old config as long as the files downloaded from now-broken links are still in the Nix cache. Of course in practice, this is only useful to large organizations that have resources to invest in bespoke infrastructure to ensure supply chain integrity, since any `nix store gc` run will immediately wipe all downloads :(

Free for 6 months after which it auto-renews if I recall correctly.

They don't ask for credit card information when signing up this way, so even if true you won't be charged if you forget canceling.

Besides what others already mentioned, it's the only smart watch with an open source OS supported by the vendor themselves (that I know of anyway).

For me, it has been ready as a daily driver for more than a year. Battery life is shorter than macos but still long enough that I don't have to think about it (which I can't say about any x86 laptops, even when they use iGPUs).

The notable missing features are external displays (an experimental kernel branch is publicly available though) and the fingerprint sensor. That's about it, though. Given the amount of polish combined with the hardware, it's arguably the most polished Linux laptop experience you'll get.

- the pandemic tracking app without which you can’t enter an airport

Not sure if airports specifically used another mechanism, but the Android contact tracing APIs were actually reimplemented in microG, allowing these apps to work even on custom roms.

Your other examples don't hold universally either (banking apps are compatible with un-rooted custom ROMs more often than not, and not sure how many sports event apps use integrity checks), but your general point stands that it may come with trade-offs.

Cargo it's a nightmware to maintain

To my knowledge, the Linux kernel doesn't use Cargo to build Rust code.

Signal has profiles nowadays that can be used to connect with people without sharing phone numbers. The latter are only used for signup and discarded immediately after.

Most of the features in the article are already opt-in. It's not like Firefox just automatically translates articles against your will, for example.

Mozilla is mainly responding to inflammatory comments like yours by adding additional toggles to disable any sort of trace in the UI about those features even existing.

That problem is solved by the subsecond crate (an offspring of the Dioxus UI framework), demo here: https://youtu.be/Kl90J5RmPxY?t=1288

It's not integrated in Nannou specifically, but they're showing off Bevy and ratatui in that demo, both very popular frameworks in the Rust world. (In fact, Nannou is in the process of being rebuilt on top of Bevy.)

Runs pretty smoothly with iwd. I get occasional disconnects (one every few hours) that may equally be down to my local wifi (other devices have issues with it too). iwd instantly papers over them, so it doesn't impact me either way.

Given that you're already using Home Manager: Make sure to also take a look at plasma-manager! [1]

It extends HM's declarative config to KDE/Plasma's config files, which are harder to manage since they also contain volatile state like window geometry. For discovery, there is also a `plasma-manager` executable that prints out most (all?) active settings. In particular the keybindings are included in there.

(This doesn't directly answer your question, but maybe is informative regardless and/or helpful for finding related options)

[1] https://github.com/nix-community/plasma-manager