Hacker Newsnew | past | comments | ask | show | jobs | submit | WolfeReader's commentslogin

Please use a dedicated password manager, instead of a browser-based one. KeePass is likely the best going forward.

@taviso had claimed the exact opposite: https://lock.cmpxchg8b.com/passmgrs.html

EDIT: Yes, he claimed that for online password managers, not keepass. I thought the argument was about password managers in general.


Where?

> Good examples of simple and safe password managers are keepass and keepassx


Browser-based password management serves the purpose of locking users into a specific browser; I'd much rather have the freedom to switch browsers at will without the cognitive tax of securely moving all my creds every time I want to switch my main browser.

That's not what that is saying. It's saying don't use an _online_ password manager instead of the browser one. In the very opening they state that simple implementations are great and even lists some. Then the rest of the article dives specifically into online password managers, which are something else.

You're right. Edited my comment.

Out of curiosity, why KeePass versus Bitwarden? I've been using Bitwarden for years, but if there's a specific reason I should be using KeePass instead, I'm open to changing.

KeePass is just an encrypted database file with UI around it for usability. You can keep the db on a USB drive, sync it through a cloud storage, e-mail it to yourself, whatever ... It's really not that complicated. BitWarden is the above as a service, I reckon.

Nb. The above refers to KeePassX. No idea what the KeePass without the x is about. Naming things. So hard.


Bitwarden has taken investor money, sadly. It's still in good shape for the moment. But the time will come when they place profits above other needs; it's a matter of when, not if.

If it is a process, running in the same user context, with the ability to read/dump arbitrary memory -- As the KeePass database is decrypted it would "store all passwords in memory in plain text" too.

The fix isn't Edge Vs. Chrome. Vs KeePass Vs. Bitwarden, it is "How do I have my passwords exist in a different execution context than [evil process able to read all memory]?"

Android and iOS have an "answer" to this problem. Desktop OSs having all processes running side by side in the user's execution context, do not. It is only as secure as the least secure process running.


This makes me miss running Qubes a few years ago, and keeping BitWarden in a separate VM from everything else. I've never felt as secure as when I had that setup.

"I thought about using fossil many times but it seems codex and claude have deeper integration with git."

Don't let "agentic" "coding" be the reason to avoid fossil.

Fossil and other VCS are much easier for humans to use than Git is; there's no reason to have an LLM burning up tokens and the environment to do tasks you'd do yourself quickly and correctly.


Yes, things that are not LLMs continue to be useful and interesting even though LLMs exist.

I hate what AI hype is doing to peoples' brains here.


I was a loyal magit user for a decade. Now I use jujutsu from the command line. It's actually really nice.

Git is noticeably slow on Windows. Git is built to run on top of Unix commands, which work great on Linux and Mac. For Windows, the commands have to be installed separately, and there's a performance penalty for each call. Individual Git commands are usually fine, but anything that calls several steps in sequence will visibly drag.

(WSL gets around this entirely.)


afaik far bigger factor is that windows file io is just generally much slower than linux. both of these are further exacerbated by av solutions which are ubiquitous in windows. that is why ms introduced "dev drive" in windows few years back which in their own benchmarks showed biggest gain specifically with git: https://blogs.windows.com/windowsdeveloper/2023/06/01/dev-dr...

I hardly see developers with Windows anymore, I guess this is one of the many reasons.

I have to use Windows for work. With WSL, it's actually perfectly fine! Which is really more of an endorsement of Linux than Windows.

I last developed on Windows in the time where I had to fiddle with Git Bash, Cygwin and manually setting my PATH. It was not a fun time.

I've had two Pocketbooks and never encountered these issues. Sounds like you had some bad luck.

Kobo works with Libby if you use Adobe Digital Editions as an intermediary.

From the Libby web page, you have an option to download the ASCM. Load that onto ADE, and you have the book. Then plug in your Kobo and transfer the book. It even respects the loan duration!

This isn't perfect, but it works, so I can't agree that Libby and Kobo are absolutely incompatible.


I tried that, and it was incredibly frustrating to have to run back to the PC every time, not to mention vacations and things like that. At that point you don't even need Libby since you can do the same with digital editions off your library's website.

I truly hope you're buying books as well - authors (and editors, illustrators, translators, etc) should be rewarded for their art.


One of my favourite writers only publishes on Amazon, so I subscribe to their Patreon to offset the fact I "acquire" their books with alternate means.

Yes, it's not hard to do both.


The Kindle scene is a disaster that shows the dangers of prioritizing DRM. Meanwhile, I'm buying DRM-free books and keeping them in Calibre and reading on KOReader. It's a great experience.


Mercurial has a more consistent CLI, a really good default GUI (TortoiseHg), and the ability to remember what branch a commit was made on. It's a much easier tool to teach to new developers.


Hmm, that feels a bit subjective - I'm not going to say X is easier than Y when I've just finished saying that I found both tools to have a lot of black magic happening.

But what I will point out, for better or worse, people are now looking at LLMs as Git masters, which is effectively making the LLM the UI which is going to have the effect of removing any assumed advantage of whichever is the "superior" UX

I do wish to make absolutely clear that I personally am not yet ready to completely delegate VCS work to LLMs - as I have pointed out I have what I like to think of as an advanced understanding of the tools, which affords me the luxury of not having an LLM shoot me in the foot, that is soley reserved as my own doing :)


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: