neobrain

Obviously not ideal, but update latency is much better with other third party distributions like iodéOS or CalyxOS.

At least in contrast to other vendors, FP provides official support for microG, so this has been without noticeable loss of stability/quality for my use cases so far.

> As another example, WINE does not ban all former Microsoft employees, they just ban anyone who has ever looked at the Windows source code.

It's an interesting example given that Wine considers deriving code from traces of original components (like hypervisor traces) tainted and also bans LLM contributions for legal considerations: https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...

At least equally worth pointing out: Three different people are actively working on it, see https://indico.freedesktop.org/event/12/contributions/532/ .

> I already addressed that in my comment, right after the line you quoted.

Where? You suggested it would go through Murena instead, but you can fully disable third party services by disabling external push providers and by using on-device databases for GPS. e/OS directly offers this configuration during initial setup.

> And what would you say GrapheneOS does of those? Do you know, or do you just assume that GrapheneOS does the worse there?

I'm not necessarily trying to present either as "better" or "worse" since they both have their merits depending what exactly you're after (which I don't feel this is the right time/place to have a detailed rundown of). It was the root comment that posited e/OS was strictly inferior for people who care about freedom.

> I am not sure what you are trying to say here. I have never had an Android system that did not have OTA updates. Everything included... I usually like to install the apps I want?

The last bit of my sentence could easily be misread as an enumeration of three things ("microG", "OTA updates", "everything included"), but it was actually an elaboration: FP is the only vendor to support microG, and (in contrast to "unofficial" microG setups) it doesn't require sacrifices in convenience because standard features like OTA updates work just like with your average Android. Perhaps that's clearer?

(Notably "Everything included" does not mean it ships a thousand apps or something. To the contrary, FP stock OS is mostly vanilla Android)

Point being: I could install LineageOS on my last phone, but it was a poorly documented process, updates were a hassle (having to flash through custom recovery for lack of OTA), and I had virtually no confidence in data integrity when running major updates.

> Is it better to have microG contacting the Google servers or sandboxed Play Services going through a Graphene-powered proxy?

How about microG not contacting Google servers at all?

In any case you're presenting an unnecessarily binary argument though. Letting Google handle push notifications is different from using them as your location provider, and both are different from letting all Play Services lose on your system.

I'm not big on this general line on argument, but one point in particular:

> And of course, fairphone’s hardware and OS are nothing to write home about. For the freedom and security nerds they’re better off with GrapheneOS on Pixel or whatever upcoming Motorola phones will support it.

For the "freedom nerds", FP is one of the only (if not the only?) vendor to have official support for microG-based operating systems, seamless OTA updates and everything included. The Murena e/OS offering in particular is simple enough that the non-nerds that (perhaps less outspokenly) care about freedom can just pick it up with little change in habits.

> If there are tradeoffs, if would be nice if the customers can decide what to have, in a modular product.

A "modular product" has tradeoffs in and of itself (such as size, price, water resistance, …), which presumably would not fly for a majority of customers.

Where are you getting GPS from? Grandparent commenter talked about bluetooth beacons and parent suggested reading the docs.

The contact tracing APIs very deliberately avoided GPS for exactly the reason you mention.

Just curious, has suspend (to RAM) been working for you?

For me the nvidia driver just keeps waking up the system instantly - but my setup is deviating from the upstream flake in a few ways, so I'm just wondering if it's worth setting up the system from scratch if it's working for other people.

Other than that, can fully second that the flake is working great. Only gotcha is that CUDA-enabled packages (including Firefox) require using the flox binary cache unless you want to compile them from source, but then the package versions can lag behind a bit (and debugging nix cache issues is surprisingly difficult).

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.