𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍

       🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆. 
 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 𝖋𝖊𝖆𝖙𝖍𝖊𝖗𝖘𝖙𝖔𝖓𝖊𝖍𝖆𝖚𝖌𝖍 

Ceterum Lemmi necessitates reactiones

  • 22 Posts
  • 1.39K Comments
Joined 3 years ago
cake
Cake day: August 26th, 2022

help-circle






  • Shamelessly shilling my OSS project, rook. It provides a secret-server-ish headless tool backed by a KeePass DB.

    • Headless server
    • Optional and convenient integration with the kernel keyring (on Linux), for locking the server to only provide secrets to the user’s session
    • Provides a range of search, list, and get commands
    • Minimal dependencies and small code base make rook reasonably auditable

    You might be interested in rook if you’re a KeePassXC user. Why might you want this instead of:

    • Gnome secret-server, KDEs wallet, or pass? rook uses your (a) KeePass DB, while most other projects store secrets in their own DBs and require (usually manual) sync’ing when passwords change.
    • One of the browser secret storage? Those also keep a bespoke DB which needs to be synced, and they’re limited to browser use. Rook supports using secrets in cron jobs or on the command line (e.g. mbsync, vdirsyncer, msmtp, etc, etc).
    • KeePassXC? KeePassXC does provide a secret service that mocks Gnome secret-service, but you have to keep KeePassXC (a GUI app) running even if you only rarely use the UI. Rook can also be used on a headless machine.
    • The KeePassXC command line tool? That requires entering the password for every request, making it tedious to use and impractical for automated, periodic jobs.

    Rook is read-only, and intended to be complementary to KeePassXC. The KeePassXC command line tools are just fine for editing, where providing a password for every action is acceptable, and of course the GUI is quite nice for CRUD.


  • Broadcom, as you’ve discovered. That’s the one brand that I’ve always had trouble with; they go out of their way to be closed source: never publishing specs, never responding to developers. They’re horrible to the point where I will not buy any product that uses Broadcom chips. Which used to be a PITA because they were also common.

    Fingerprint readers, in general, also widely seem to be poorly supported.

    One of my computers has a MediaTek wireless chip where WiFi isn’t supported but Bluetooth does.

    A lot of people have problems with NVidia cards; I’ve not had trouble with either AMD or Intel GPUs (although, I think all Intel GPUs are CPU integrated?).

    Multifunction printers are still iffy, and even just plain printers can give grief; I’ve come to believe that this is simply because CUPS is ancient and due for a completely new, modern printing service. It’s an awful piece of software to have to work with.



  • I agree! You aren’t OP, so I’m unclear whether you were agreeing or disagreeing with my skepticism about letting developers off the hook for providing parking being a good idea. It seems good for developers, but bad for urban planning.

    Especially in Oregon, which is not known for its extensive and comprehensive public transport systems. The regional rail is Spartan, and Portland is the only city with any light rail at all, and it’s aenemic at best. Eugene’s bus system is adequate, largely thanks to the University, but getting around the state and within cities completely without a car is impractical. It would be a different story if the state boasted rail, light rail, and bus systems at the European level, but it doesn’t; letting developers build housing without allowing for parking seems like it only benefits developers.



  • I agree. Arch has been my current favorite distribution for several years now, but it’s almost impossible to maintain without having to drop into the shell occasionally. I have EndeavourOS installed on my wife’s laptop and she’s been happily using it for nearly a year; bauh helps with software installs, but I still generally drop into a shell for the full -Syu upgrades, and you have to use the shell at least once just to install bauh as it’s not a core package.

    You might be able to avoid the shell to use bauh if you use the AppImage; I haven’t tried that. bauh can apparently do system upgrades, but I haven’t tried that yet and I need to see how it handles news; Arch is fairly cavalier about pushing out breaking changes that require extra user steps which need to be discovered by reading the news posts.

    I agree that Arch isn’t the best “first linux” distribution.




  • Native apps are being replaced with web apps.

    Are they?

    A few years ago it seemed for a while that Electron was cropping up everywhere, but it’s been tapering off over the past couple of years. I don’t think I’ve come across a new Electron app in the past several months, and every project that did start out as Electron now has several native alternatives. Riot/Element is a good example.

    The trend I see is away from web apps. It’s still a popular platform and for anything that is fundamentally networked I’d agree that few native apps are being developed. I haven’t seen a native version of the Home Assistant client interface, for instance. But for web apps to replace native apps, there’d have to be a trend to either move native apps to the cloud, or for platforms like Electron to surge and displace native toolkits. I observe that the reverse of the latter is happening; and for the former, while there are a lot of cloud-ifying projects, I don’t see that they’re replacing native apps.




  • Many of these recipes feel like that, don’t they?

    I’ve just accepted that I have no palette. I can taste the difference between Starbucks and my home brew, but I’d be lying if I said I could taste a difference between drip, immersion, pour-over, Aeropress, or French press, much less whether the water was 201⁰F or 195⁰, or the brew was properly bloomed.

    I taste gross differences: dark vs light roast; cold brew vs hot; home brew vs cheap office pod machine; how strong the cup is. Everything else is noise.

    I don’t doubt some people have palettes where such fiddly recipes yield noticeable gains; I don’t know whether to envy or pity them.