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

help-circle


  • OK, so I looked though my browser history, and here are some relevant pages I found:

    I don’t remember how much I used each one, but eventually I pieced together enough information information to get the Browserpass extension working in the Google Chrome flatpak. But three of those links are KeePassXC, which should be useful for adapting this for your use.

    The main file that was having problems was the Browserpass Native Messaging Hosts file in my config directory for the Chrome flatpak, ~/.var/app/com.google.Chrome/config/google-chrome/NativeMessagingHosts/com.github.browserpass.native.json. Originally it was a symlink to a file at /usr/lib/browserpass/hosts/chromium/com.github.browserpass.native.json:

    {
        "name": "com.github.browserpass.native",
        "description": "Browserpass native component for the Chromium extension",
        "path": "/usr/bin/browserpass-linux64",
        "type": "stdio",
        "allowed_origins": [
            "chrome-extension://naepdomgkenhinolocfifgehidddafch/"
        ]
    }
    

    The call to /usr/bin/browserpass-linux64 did not see to work for me, so I ended up making a copy of the file in the NativeMessagingHosts directory and modified it to point to a script in my home mount:

    wile_e8 NativeMessagingHosts $ diff com.github.browserpass.native.json.orig com.github.browserpass.native.json
    4c4
    <     "path": "/usr/bin/browserpass-linux64",
    ---
    >     "path": "/home/wile_e8/.config/browserpass/browserpass.sh",
    
    

    I don’t remember why I picked to do it inside the ~/.config directory, but it worked so I left it. And here is the script I put at ~/.config/browerpass/browserpass.sh:

    #!/bin/sh
    cd ~
    /usr/bin/flatpak-spawn --host /usr/bin/browserpass-linux64 2>/tmp/error.log
    

    I don’t remember how I came up with that script, it must be somewhere in the four links at the top.

    Finally, I needed to use Flatseal to allow access to the script. In the Google Chrome settings, under “Filesystem->Other files”, I added an entry saying ~/.config/browserpass:ro. Also modified from the default in Flatseal, I have “Filesystem->All user files” enabled, along with “Socket->D-Bus session bus” and “Socket->D-Bus system bus”. I don’t know how necessary the last three are, but I’m not messing with it now that I have it working.

    So, that’s what I did to get the Browserpass extension working in the Google Chrome flatpak. You’ll have to modify some things to get it working for KeePassXC, or for Firefox. But that general pattern should work.






  • Hasn’t Android had a thing for a while where it gives update priority to people who manually check for updates? Like, my phone (7a) didn’t say an update was available, but then I clicked the “Check for update” button, and now it said Android 14 is available.

    So I don’t think anyone who really wants the update soon needs to sideload the OTA, just check for an update and you’ll probably get it.





  • So, as someone that’s been on flavors of Ubuntu/Linux Mint for me personal computer since Breezy Badger, any good distro recommendations? I’ve been using Ubuntu Mate and upgrading in place for the last ~5 years, so I’ve mostly avoided Snaps, but I’m looking to upgrade my computer and I’m probably going to need a fresh install. I’d like to stay on the Ubuntu/Debian tree, but I’ve been using RHEL on my work computer for a while now, so I’m not totally unfamiliar with that distro branch.

    Also, should I be as concerned about Flatpaks as everyone seems to be concerned about Snaps?


  • wile_e8@lemmy.worldtoAndroid@lemdro.idAndroid 14 Beta 5
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    1
    ·
    1 year ago

    Existing beta users, what say you? Have the latest betas been stable enough to install on my daily driver? Are there a lot of useful advantages over Android 13? If I’ve waited this long to install the beta, should I just stay on 13 until the official release?


  • I agree that those shouldn’t be patented - they’re ideas, not implementations. If you have a particular ingenious implementation for one-click shopping, go ahead and patent it. But don’t sue people if they come up with a different way to do the same thing - that just means your implementation wasn’t particularly novel.

    So yes, there have been some bad software patents given out. That just means that the process for giving software patents needs to be reformed, not that we need to get rid of software patents.



  • I think patents make some sense for software, if you patent a particular algorithm you developed for doing something useful. An example I always use for a good software patent is Google’s original PageRank algorithm - it was a specific algorithm that provided significantly better search results than existing search algorithms. But that patent just covered one specific algorithm for ranking search results, not the idea of searching the web (which was around before Google). Patents that are given for an idea, not an implementation, are bad.

    This article is unclear, but it sure makes it seem like this patent was given for the idea of sending video from one device to another, not a specific algorithm for doing so. So that would be a bad patent. But I don’t think it means we should get rid of software patents altogether.