Just some Internet guy

He/him/them 🏳️‍🌈

  • 0 Posts
  • 37 Comments
Joined 1 year ago
cake
Cake day: June 25th, 2023

help-circle












  • The identifier is unavoidable for push notifications to work. It needs to know which phone to send it after all, even if it doesn’t use Google’s services, it would still need a way to know which device has new messages when it checks in. If it’s not a phone number it’s gonna be some other kind of ID. Messages need a recipient.

    Also, Signal’s goal is protecting conversations for the normies, not be bulletproof to run the next Silk Road at the cost of usability. Signal wants to upgrade people’s SMS messaging and make encryption the norm, you have to make some sacrifices for that. Phone numbers were a deliberate decision so that people can just install Signal and start using E2E texting immediately.

    If you want something really private you should be using Tor or I2P based solutions because it’s the only system that can reasonably hide both source and destination completely. Signal have your phone number and IP address after all. They could track your every movements.

    Most people don’t need protection against who they talk to, they want privacy of their conversations and their content. Solutions with perfect anonymity between users are hard to understand and use for the average person who’s the target audience of Signal.




  • For me it’s not even that I hate the concept of AI. It’s that we’re shoving half baked AI literally everywhere we can without any fuck given to reliability, accuracy and safety, or even sustainability.

    • GitHub Copilot: code so bad I won’t even bother reviewing the PR. It doesn’t save time at all unless you suck at coding already.
    • Google Gemini/Bing Copilot: completely off the mark more often than not, it’s still faster to do a standard, well written web search.
    • AI assistants: they’ve always sucked and still sucks but hey at least the voice is realistic right. It still doesn’t understand what you say to it half the time.
    • Recall: nobody ever asked for that
    • AI summaries: I’d rather skim through articles, at least I know what I skipped.
    • AI translations: better than Google Translate I guess, but more of the same: it gets you by when reading foreign sites but the quality is still too bad to use it to translate my apps with it in a professional setting.

    They’re all impressive products on a technical level, but they’re basically really expensive alpha quality software that sucks a stupid amount of power for dubious gains.

    My other gripe is most of the time those feed your personal data to Microsoft/OpenAI for processing, because most people don’t have a quad RTX 4090 Ti setup to run any decent model locally at reasonable speeds. It’s using a jackhammer to nail a nail.


  • It depends where you draw the line of what is GrapheneOS. Everything they do is free and open-source. If you build it for emulator or Waydroid, it would indeed be FOSS: no proprietary blobs in sight unless you count your host’s GPU firmware to taint the whole thing. The build scripts to dump your firmware blobs from your own device, building GrapheneOS, bunding it all back together, sign the build and flash it on your device, all open-source.

    The only part where blobs are involved is the downloadable prebuilts which does include the blobs otherwise it wouldn’t boot at all. They’re not including blobs in their project. They’re including the blobs that are already on your device and also downloadable from Google. It’s not like they made their own proprietary blobs they hide the source for.

    The GNU guys say that’s unacceptable as any proprietary software is unacceptable, therefore the whole thing is tainted and worthless. They think the same thing of coreboot/libreboot.

    In my opinion, GrepheneOS is fine. It’s the best that can be done, and their project in itself is FOSS, even if running it on actual hardware requires a few blobs to be added, and it allows users to opt-in to installing a sandboxed Google package. The same I call Linux FOSS even if it can upload a firmware to my GPU so amdgpu works. At least the entire loading of the firmware is in my control, and I can verify that the blob being uploaded is the one I expect, even if the blob is proprietary.

    Nothing that you replace with GrapheneOS is proprietary. The blobs are a no-op. Running sandboxed proprietary code is better. It’s a net positive and reclaims some of your freedoms by being able to control and monitor the sandbox.


  • A functional desktop Linux is hard. Getting desktop Linux to boot and run stuff isn’t that hard in itself.

    The problem is mostly drivers. They’re made for Android specifically, and often for that device specifically as well, so getting them working outside of Android is hard. The second problem is of course manufacturer obstacles, they really don’t want you to do that.

    Technically getting a kernel and a working framebuffer is fairly “easy”, because it’s mostly already there, you could just replace the initramfs and run whatever init and software you want. It’s getting the GPU to do stuff that’s a lot harder. WiFi is alright but cellular is a complete nightmare. A lot of those are Java native libraries, which makes it non-trivial to use outside of the Android Framework. But all the kernel stuff, you already have ready to steal right from the manufacturer, or you can take the ones LineageOS uses. It’s only a matter of getting a useful userspace.

    And the phone landscape on Linux isn’t that interesting, so people’s attention have been around improving Android itself as it’s much more capable and mature, and is open-source. If Android was closed source we’d have Linux phones already, but for many FOSS entheusiasts, Android is fine and much better polished.

    If you’re lucky, PostmarketOS might support your device well. If you’re less lucky you might get a kernel that boots but you can only get a serial shell to it over USB. If you’re unlucky, nothing exists, and you have to do it yourself.


  • Apple is Apple, it’s not a super great example. They already had iBoot from the iPhones and iPads that they just adapted for the laptops, which is also what the M chips are. Apple’s firmware has always been rather quirky compared to more standard machines.

    If you look at the cloud, like AWS and their Graviton instances, they use plain old regular UEFI but ARM, which then can load GRUB and the kernel as usual there. Completely generic and basically the same as x86_64 UEFI. You can load any generic ARM distro there. We already know what ARM PCs would look like.

    The main thing here isn’t really x86 vs ARM, it’s embedded vs PCs. You can totally have non-BIOS and non-UEFI compatible machines with x86 CPUs in them, but I only saw this being done embedded in devices, in my case those were industrial machines. With ARM you’ll also see U-boot which is common in stuff like routers and IoT devices because it’s fairly easy to get working and can be controlled with serial ports. But for PCs, it’s gonna be UEFI if anything because Windows support. In the end, CPU is CPU, it runs code.

    Why not UEFI everywhere then? Because it’s overkill most of the time, and orders of magnitude more code and complexity which you just don’t need for a router. Your router can start executing its operating system directly from flash. You know in advance where the kernel is located, you don’t need to start initializing PCIe devices and a SATA controller and scan disks for GPT headers and find an EFI partition formatted as FAT32 to find an executable to load into memory and execute, no graphics card to initialize, no keyboard and mouse to monitor for menu, no menus to display because there’s no options, etc. UEFI firmwares aren’t small. The arm64 OVMF firmware for QEMU is a whopping 64MB, that’s more flash than my router even have.