• 0 Posts
  • 363 Comments
Joined 1 year ago
cake
Cake day: April 13th, 2024

help-circle







  • refalo@programming.devtoTechnology@lemmy.mlNewpipe
    link
    fedilink
    arrow-up
    2
    ·
    5 months ago

    I disagree, there are many resources for making and distributing android reproducible builds, including third-party F-Droid repos like IzzyOnDroid mentioned in my previous link.

    And to my knowledge there is no technical requirement that F-Droid actually needs to build OR sign packages on behalf of anyone… I haven’t seen any actual official rationale listed for it, but I assume one of the main reasons is convenience for the developers so they don’t have to provide their own builds and deal with signing/losing keys.

    I understand that the risk of problems can be somewhat mitigated in F-Droid by using reproducible builds, but I don’t consider that sufficient for the most privacy-conscious users because:

    • reproducible builds are not required by F-Droid

    • it is not made clear to the user that a particular package even supports reproducible builds

    • the verification of reproducible builds is not made plainly visible somewhere publicly if at all

    • a user can still easily be misled by a one-off rogue package that is NOT reproducible, due to the previous point

    • independent verifications of those builds reliably made by others are not common



  • In my experience… not really. I would say SDL makes the task of writing controller support code within your own applications easier and higher-level, but in reality it still has not much to do with “drivers” (I assume you mean kernel modules), which the kernel and OS stack already provide multiple unified interfaces for with things like jsdev/evdev/udev/hidapi, regardless of how you access those subsystems (via SDL or otherwise).