Formerly known as [email protected] / server shuts down end June 25

  • 0 Posts
  • 5 Comments
Joined 3 months ago
cake
Cake day: June 10th, 2025

help-circle
  • You think if they used another licence it would be any different? Countless open source projects have a GPLv3 + proprietary licence which is way more evil than Apache - they poison the open source with GPLv3 so no competitor can contribute without revealing their changes while they themselves can use the proprietary licence. e.g. Trolltech and QT for example but there are many others.

    And frankly you should be blessed that you have a fully fledged, open source phone OS you may fork and build from. The OP wants a Linux phone OS and AOSP is a Linux phone OS. There are many forks of Android, closed and open that wouldn’t exist if Google had just decided to be proprietary from the get go. They were under no compulsion to do this but they did. If you have used LineageOS, or GrapheneOS for example then you are a beneficiary of this. You are completely at liberty to have a de-Googled modern phone OS powered by Linux right now.



  • Android is Linux. It uses a Linux kernel paired with a BSD based user land. Also there is an AOSP version of Android which is Android without all the Google bits. LineageOS and some other security oriented firmwares derive from it. That isn’t to say Google are necessarily happy about this entirely but at the same time, they open sourced most of Android and probably see it as a useful antitrust defence and the impact of flashed devices barely more than background noise.

    The issue of bootloaders is an orthogonal matter since Linux or not does not mean bootloader or not - many black box devices use Linux but you won’t be flashing them any time soon - TVs, set top boxes etc. I would argue that regardless of OS, there should be a right to repair law (e.g. in Europe) that allows people to maintain devices beyond their warranty. And if Samsung et al don’t want to do it, then they should have an obligation to unlock devices upon request.


  • I don’t really buy the “small incompatibilities” argument. The project strives for total compatibility, even down to the most esoteric parameter that nobody has ever heard of. And even that seems like overkill to me - there are alternative implementations of core commands on Linux and other *nix systems like BSD, Solaris etc. where the compatibility is way worse. For example, busybox is used in embedded Linux, and a containerized images like Alpine Linux.

    It also seems a bit rich to complain that uutils might get extended. GNU coreutils came into being because of dissatisfaction with the commands that came with the default *nix. Same for bash (vs sh), GNU cc (vs cc), GNU emacs (vs emacs) and so on. Was there somebody back then complaining about devs “spamming commits” that extended functionality?

    And other Rust applications won’t only work with uutils. That’s absurd. They’ll test the capabilities of the OS they’re built to run on either at build time with feature flags or at runtime by probing commands. Just like any other high level application.

    As for license, MIT is used for plenty other things in a typical Linux dist, e.g. X11.

    The biggest point of concern for a Rust rewrite is dependency integrity. Rust uses cargo to manage dependencies and absolutely everything in the Cargo.toml/Cargo.lock files has to be reviewed. The crates.io repository is beginning to support package signing and The Update Framework initiative but every single dependency of uutils would need to be carefully reviewed and signature validated for it to be considered trustworthy. Basically everything needs to get locked down, and wherever possible dependencies expunged altogether.


  • arc99@lemmy.worldtoLinux@lemmy.mlFan of Flatpaks ...or Not?
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    2 months ago

    While I wouldn’t want flakpak going deep into the OS I think the advantage of using them on the desktop is obvious. Developers can release to multiple dists from a single build and end users get updates and versions immediately rather than waiting for the dist to update its packages. Plus the ability to lock the software down with sandboxes.

    The tradeoff is disk consumption but it’s not really that big of a deal. Flatpaks are layered so apps can share dependencies. e.g. if the app is GNOME it can share the GNOME runtime with other apps and doesn’t need to ship with its own.