• 0 Posts
  • 420 Comments
Joined 3 years ago
cake
Cake day: October 9th, 2023

help-circle
  • Welcome to the club.

    Remember the 3-2-1 backup rule. You are now directly responsible for the saftey of your database. You can’t blame big tech ai vibe coding.

    For mobile android, I reccommend KeepassDX.

    For ios I recommend Keepass Touch (one-time $2 for autofill & touch-id).


    Most people, myslef included, use syncthing to keep the database syncronized between devices when they’re on the same wifi network.

    Android is easy, the app is Syncthing Fork.

    IOS is a tad harder due to the apple file management restrictions, but möbious sync works very well as a front end for syncthing (one-time $5 for unlimited sync jobs, not needed if only use it for keepass).

    Both apps don’t always stay running the background (ios apps can’t even if they wanted too), so you do have to have to activly open the apps once in a while to sync.

    Beacuse of that, it’s important you set syncthing (or whatever method you use) to resolve conflicts when both “sides” have been modified since the last sync have by making a new file instead of overwriting one. You can easily merge the two datbase files back into 1 on desktop through keepassXC, delete the copy and let syncthing propagate the updated folder.


    Alternatively you could use a cloud provider of your choice to host the file. As long as the keepass app can access the cloud provider’s files. A “keep file offiline” feature is very helpful too. However, the same background process sync limitations will be in place. You will need to see how tge cloud provider handles conflicts, if it just picks and overwrites the loser, that could result in data lose.


    Another note, automatically syncing between devices doesn’t count as a true backup. If the database file gets corrupted (or you accedeidenty delete somethingg and clear the recycle bin) and that file is synced everywhere else, what good are multiple copies of the same bad file? You should be able to go back a week or two (syncthing does do file history if enabled).



  • You could, but the cloud is just someone else’s computer. If mozilla messes up and deletes a bunch of people passwords, like google did a few years ago, or they have a data breach like lastpass you’re screwed.

    If you choose to rely on any cloud password manager, I recommend maintaing a local database with at least any emails that will be needed for resetting passwords, 2fa recovery codes and anything else you consider essential to get through a failure of the cloud datbase.

    The inverse is true for anyone running a local database. An encypted copy, of at least the essentials, should be somewhere remote they can access without needing to lookup a password from their local database.




  • It solves a few problems podcasters have,

    1. ambiant noice; the typical “podcast/radio” microphones are designed to reject pretty much everything besides what is in front of them, and are very good at it (within limits you may not hear the hvac system but you’ll hear a door slam). The closer the microphone is the source(person), the less you have to turn up the volume. When you turn up a microphone’s volume, it’s going to turn up the volume of everything the microphone has captured; background noise, traffic, electrical interfernace, etc. The less you have turn up all the extra crap, the better the sound will be.

    2. multiple people in close promiximity. People sound different, one person might be soft spoken and the other might be loud. In order to hear the quiet person you need to crank their microphone up. If the two people shared a microphone, you’d have to find a balance between loud enough and too loud; ultimately that would lead to a viewer constantly having to adjust their volume depending on who’s speaking or paying an editor to do that.

    3. if the microphones are farther away, the loud person’s voice will get picked up by other people’s mic and will cause strange sounding effects from that person getting picked up by multiple microphones.

    4. consider the primary purpose of a podcast; people talking for a long period of time. Sound quality has to take priority. A news interview gets away with reduced sound quality because it’s for a short period of time, often less than a minute. But if they had us listening to that bad audio for an hour, most people would tune out.

    5. a lot of the problems I mentioned above could be fixed, or at least mitigated, with some audio editing before the episode is published. However, that doesn’t help a live podcast. It also takes a long time, a 1 hour podcast with bad audio could take a day to go through it all; you have to reduce the background noice, balance everyone’s audio, figure out how to make the softspoken person sound good without altering voice too while removing the background noise that’s sometimes just as loud as them. It’s even harder if eveyone is using 1 shared microphone, you end having to make edits everytime the speaker changes or accepting an infeiror product to save time. It’s a hell of alot easier(and cheaper) to just get sound quality right from the start. With that, you might only have spend a little time to make some minor adjustments.













  • Enough of the clickbait titles please. We’re here to escape the mainstream bullshit. If an article is intresting enough, at least come with up a short synopsis so we know what the topic is. “I got Targeted - frankwiles.com (software dev almost gets phished by fake project offer)”

    That being said, thank you for sharing it. This is an intresting read, the lengths hackers/scammers go to trick people. It wasn’t some “hollywood” crack the code bullshit, they came up with a plossible story and tried to get the guy to run malicious code. It reinforceses that the user is the weakest link, no matter how smart or careful we are. Security isn’t just about preventing yourself from getting hacked, minmizing damage and having a recovery options for when you fuckup is important too.