• 0 Posts
  • 110 Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle

  • “It will initially be flagships similar to the current generation Motorola Signature, Motorola razr fold and Motorola razr ultra since those will be the 2027 devices meeting our requirements including the expected updates and hardware memory tagging but it can expand over time,”

    This is great news in general, but it’s also a bit of a bummer that it will (at least initially) be limited to extremely expensive phones. The recently-announced Moto Signature has “a starting MSRP of €999”.

    But MSRP is a joke so I really have no idea what the street price will be in practice.


  • I love Debian. I’ve bounced around distros a lot, for various reasons, but I’ll always have a soft spot for Debian.

    The problem with reputations — both in terms of Linux distros and just in general — is that they tend to reflect conventional wisdom from 10-20 years ago. Sometimes that conventional wisdom was off-base from the start, and sometimes it’s just outdated.

    Like, “Debian is hard” and “Ubuntu is great for beginners”. That was true enough 20 years ago. But today, not really.

    My last distro-hop was to Bazzite because Debian didn’t have the latest GPU drivers that I needed (Debian 13 “Trixie” does now, btw). It was just bad timing that I upgraded to a brand-new GPU toward the end of Debian 12’s life cycle. If I’d waited another 6 months (or if I didn’t need good OpenCL/ROCm/Vulkan performance) I probably would’ve stuck with Debian.

    I’m fine on Bazzite, but I feel like if I ever hop again, it’ll be back to Debian. Now that I am comfortable with DistroBox, I won’t worry so much about older application packages in Debian repos; if push comes to shove I’ll just run it in a Fedora box or something like that. Drivers are the only thing to worry about, and I’m not likely to upgrade my GPU again for 5+ years so I should be fine.




  • There is certainly a very big amount of fuckery going on right now with nvidia drivers.

    “Right now” meaning every year for the past decade or two.

    It’s always something with Nvidia drivers. Performance+stability is more the exception than the rule.

    That said, AMD drivers have a bad rep too. Personally I’ve had zero issues since I switched to AMD but experiences seen to vary a lot from what I’ve read.

    Before that, I don’t think I ever got through a full year without at least one weekend lost to troubleshooting Nvidia bullshit. CUDA is a pain in the ass even on Windows.


  • Hmm, maybe I’m thinking more iPhone 3G era than original iPhone era? I recall a time when there weren’t many apps yet and you could put out anything marginally-functional for 99¢ on the app store and get some quick cash from it. I don’t remember $10-20 being the norm but maybe that was before I was onboard.

    I’ve certainly been burned by apps either breaking with iOS updates or no longer being available to download on the App Store (so you could keep using them, but only on existing devices that already had them installed).





  • I’m a software developer first and a gamer second. Being a “gaming” distro does not detract from anything else, really. It just means that getting proper GPU acceleration is easy, and you’re likely to want that for development too. That was actually why I chose Bazzite. I was tired of wrestling with CUDA and ROCm.

    It’s not “gaming” vs “developing”. That’s a false dichotomy.

    The real choice is immutable vs traditional. And I’ll admit, immutable distros have a big learning curve. But it forces you to learn techniques that will make your life easier no matter where you go. The time I spent wrestling with dependencies on Debian or Ubuntu or OpenSuse just because I didn’t know about Distrobox…

    Unless your needs are very narrow and unchanging, you’re likely to run into something that’s a giant pain in the ass no matter which distro you choose. I used to use Ubuntu LTSR so I could install a few big things in easy mode, but it made everything else harder because it was so outdated. Switched to OpenSuse Tumbleweed and everything was modern but those few vendors don’t support it so I had to wrestle with dependencies.

    The answer to this problem is Distrobox. It’s the answer on Ubuntu, it’s the answer on OpenSuse, and it’s the answer on Bazzite. I’m never going back to dependency hell because I can just run everything the environment it is specifically designed for.

    If you’re wondering “should I use distro X, Y, or Z”, the answer is simply “yes”. :D


  • On bazzite, your search order for apps/packages should be something like:

    1. Flathub
    2. ujust. This is more for general configs than specific apps, but take a look at what it offers.
    3. Homebrew
    4. Distrobox
    5. Podman/Docker images
    6. rpm-ostree

    rpm-ostree is a last resort because it compromises the “atomic” principle of the system, but in a pinch it will give you access to anything you could get with dnf on a regular Fedora install.

    Don’t sleep on Distrobox. I have a Debian box so I can run Signal from its official repo and install Geany with both GUI and CLI support. Once you export applications from distrobox they behave like first-class citizens within your desktop.

    I strongly recommend trying Distrobox. If you instead hop distros, you’re going to find yourself in a similar situation eventually, where something is unreasonably difficult. That’s why Distrobox exists; so you can get the best of all worlds.


  • It makes sense to me IF it actually works.

    Having extra capacity when a device is brand-new isn’t a huge boon, but having stable capacity over the long term would be. At least for me.

    Of course this will depend on your habits. If you replace your phone every year, then it doesn’t matter. If you’re a light user and only go through a couple charge cycles per week, it’ll matter less than if you go through 1-2 cycles per day.

    Personally I’m at around 1 cycle per day on my current phone, and after nearly 3 years (over 1000 charge cycles now) the battery life is shit — much worse than just 80% of its original battery life. Performance also suffers. With my last phone, I replaced the battery after 3 years and I was amazed at how much faster it was. I didn’t realize throttling was such a big problem.

    I might replace my current battery, but it’s such a pain, and it costs more than my phone is realistically worth.




  • They announced that they’re working with an OEM to support new non-pixel phones (perhaps even shipped with GOS).

    The Pixel 9 series will be supported for another 6 years, and GOS support for the Pixel 10 is probably coming after Google releases QPR1 source. Hopefully there will be viable replacements by then.

    Google is obviously going to keep making this more difficult but the rest of the world isn’t going to just sit still.


  • Thanks for posting the solution!

    If you happen to be using a BTRFS or XFS file system, you might want to try duperemove. It will help you reclaim usable disk space without deleting any files, by using those filesystems’ built-in support for data deduplication and copy-on-write. In other words, it will make duplicate files point to the same data on disk, but still work as individual files. Files will appear and function exactly the same, and editing one copy will not change another (unlike with hard links, for example). That way it won’t interfere with cases like Flatpak or Python virtual environments where you really need multiple copies of the same files.


  • Still good if you want ROM support or are willing to wait a few months to pick one up for dirt cheap.

    GrapheneOS only supports pixels, and LineageOS only officially supports a few more models. If you filter the official LineageOS devices list to 2024/2025 models, you’ll see Pixels, Moto G 5G, and OnePlus 12R. That’s it. Options are similarly limited for Calyx, e/OS, and others. So with most other recent phones, you’re stuck with all the stock bloat and spyware, or unofficial community builds.

    Also, they’re dirt cheap in practice in the US. MSRP is a joke. For most of the year, you could get an unlocked, brand new Pixel 9 for less than the MSRP of the low-end 9a. If memory serves, it dropped under $400 at times.

    Aside from that, they kind of suck. I wouldn’t even compare them to high-end phones. They are mid-range phones masquerading as high-end. Credit to Google’s marketing department, I guess.



  • Generally speaking, xz provides higher compression.

    None of these are well optimized for images. Depending on your image format, you might be better off leaving those files alone or converting them to a more modern format like JPEG-XL. Supposedly JPEG-XL can further compress JPEG files with no additional loss of quality, and it also has an efficient lossless mode.

    Do any of them have the ability to recover from a bit flip or at the very least detect with certainty whether the data is corrupted or not when extracting?

    As far as I know, no common compression algorithms feature built-in error correction, nor does tar. This is something you can do with external tools, instead.

    For validation, you can save a hash of the compressed output. md5 is a bad hashing algorithm but it’s still generally fine (and widely used) for this purpose. SHA256 is much more robust if you are worried about dedicated malicious forgery, and not just random corruption.

    Usually, you’d just put hash files alongside your archive files with appropriate names, so you can manually check them later. Note that this will not provide you with information about which parts of the archive are corrupt, only that it is corrupt.

    For error correction, consider par2. Same idea: you give it a file, and it creates a secondary file that can be used alongside the original for error correction later.

    I also want the files to be extractable with just the Linux/Unix standard binutils

    That is a key advantage of this method. Adding a hash file or par file does not change the basic archive, so you don’t need any special tools to work with it.

    You should also consider your file system and media. Some file systems offer built-in error correction. And some media types are less susceptible to corruption than others, either due to physical durability or to baked-in error correction.