Deliverer of ideas for a living. Believer in internet autonomy, dignity. I upkeep instances of FOSS platforms like this for the masses. Previously on Twitter under the same handle. I do software things, but also I don’t.

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

help-circle
  • chirospasm@lemmy.mltoAndroid@lemmy.worldGraphene vs LineageOS what's the diff?
    link
    fedilink
    English
    arrow-up
    24
    arrow-down
    1
    ·
    edit-2
    10 days ago

    GrapheneOS user here – for many years and several devices. Also had many devices, prior to that, running LineageOS.

    GrapheneOS

    First thing to weigh, between your two options, is that GrapheneOS is considered its own mobile operating system at this point, and the development of this mobile operating system is driven chiefly by privacy and security. While founded on AOSP, GrapheneOS gets such benefits as – but not limited to – more frequently updated kernel patches, code removal or alteration to abate zero-day vulnerabilities normally addressed more slowly (or not at all) in vanilla Android, the security of a re-locked bootloader (only available on Pixel devices), an isolated and sandboxed Google Play to access normal apps (microG and other replacements are considered, in GrapheneOS circles, less secure), isolated user profiles for different sets of apps that have the ability to push notifications to each other, hardened memory allocation, and so much more.

    Pixel hardware is a great fit for GrapheneOS due to the kind of security chipsets they employ, too. By selecting a device that allows users to re-lock the bootloader (other devices do not afford this), as well as leverage Pixel-specific hardware-level security features, there’s a measure of consistency for overall security provided to GrapheneOS users and developers, alike. The devs don’t have to provide workarounds, for example, in the same way other ROM makers do, such as for LineageOS. There can be focus. And that benefits everyone who is primarily interested in privacy and security in a phone OS.

    LineageOS

    Second thing to weigh, between your two options, is the intent behind LineageOS: it’s an open source variation of AOSP, and is considered both an excellent extension mechanism for aging Android devices and an open source alternative to vendor-created – and often vendor-locked – ROMs that come, by default, on a variety of devices. LineageOS has been focused on being one of the most consistent, open source ROMs around. This means the consistency in UX, features, and flexibility of LineageOS can translate between many targeted devices. Over 20 vendors of devices benefit from the hard work of LineageOS.

    Like GrapheneOS is focused on privacy and security for their users, LineageOS is focused on being a solid, consistent ROM for their users.

    Further Consideration

    I can go into the weeds of both, but at some point I made a decision to buy into the Pixel ecosystem – and subsequently learned about GrapheneOS as an option. I value what they offer, and I understand their stricter alignment with their approach to developing an OS.

    While I choose to lock myself into the Pixel lineup of phones, I would also consider LineageOS – modified to my own specs – if I had to shift to another device. Each have their strengths. Each have their focuses.


  • Features like this exist for putting the phone back at rest when there hasn’t been a successful unlocking for X hours – GrapheneOS, an Android OS, has a similar feature. The objective is to limit the window of time an attacker has to try to exploit anything the phone may have in operation during a not-at-rest state (when the user is still ‘logged in’ to the phone, certain background services / features may be available to exploit).

    Rebooting automatically, especially if the phone not has not been successfully unlocked recently, may place the phone in a less exploitable state, as those services / features might not be available without logging in first.







  • TrailSense, an easy to use, comprehensive wilderness tool.

    The goals of the developer are fun to consider:

    Goals

    • Trail Sense must not use the Internet in any way, as I want the entire app usable when there is no Internet connection

    • Features must provide some benefits to people using the app while hiking, in a survival situation, etc.

    • Features should make use of the sensors on a phone rather than relying on stored information such as guides

    • Features must be based on peer-reviewed science or be verified against real world data

    Likewise, the features being developed under those goals are great for getting outside:

    Features

    • Designed for hiking, backpacking, camping, and geocaching
    • Place beacons and navigate to them
    • Follow paths
    • Retrace your steps with backtrack
    • Use a photo as a map
    • Plan what to pack
    • Be alerted before the sun sets
    • Predict the weather
    • Use your phone for astronomy
    • And more




  • Dumb error messages like that have to do with the UI and UX. The user interface (UI) in APT has mostly to do with how easily users see, recognize, and understand descriptions of errors (that is, how text appears and is organized), and the user experience (UX) in APT has to do with how easily users can, say, follow-up, within the tool, to resolve those errors.

    An example of a better UI in APT could be grouping to-be installed packages with clear linebreaks and color, or highlighting how much space is to be used by bolding it. All good stuff that isn’t gonna kill my eyes when I have to scroll around to find what was / wasn’t installed properly.

    And that scrolling around is all about the UX. An example of a better UX could be installation bars rather than percentages to keep the screen from scrolling past errors too quickly, affordances for users to make decisions within APT to resolve dependency issues without it dropping back into the terminal (again, dumb error messages), or providing help within the interface without having to back out to the terminal and use APT with an operator.

    I think it would be great to keep those error messages you mention, like, front-and-center, even after an operation has wrapped up. Who wants hunt/grep through a full log?


  • chirospasm@lemmy.mltoLinux@lemmy.mlAny good Linux Tablet recommendations?
    link
    fedilink
    arrow-up
    13
    arrow-down
    1
    ·
    edit-2
    8 months ago

    It’s Linux-based hardware, so any OS could be installed easily if PureOS isn’t a good fit for OP. And, unlike the phone, it’s basically a computer, like one of their laptops (which have been fine).

    If we are talking about Pinephone, Fairphone, Librem 5, etc. – they all suffer uniquely. Modems drop on all these devices often enough, battery life sucks based on tasks, app support is sundry, screens are left wanting, and more. Phones are hard to make.

    I might class Linux-based hardware phones differently from Linux-based hardware tablets.