Unlike a lot of communities, yours at least started on the correct side. Better to ban outright, than to slowly realize that you should have banned it.
When it comes to slow forum content, I think it's a fool's errand to try to determine if someone is using AI for their responses. Any of the tell-tale signs of AI are easily skirted by mentioning in their prompt to not do so. It goes back to how you can't sanitize human language which has been an issue with LLM's from the beginning.
Encouraging a culture of not using AI works to an extent, but I also tire of threads claiming the parent post is AI. There isn't a sure-fire way to know one way or another.
Indeed. Take a soft approach, or "wait and see", and you'll just allow your community to get infested with slop enthusiast crybullies that loudly protest any pushback against "genai content". The communities that draw a firm line and hold it will be the only ones that endure.
It was a surprise to us how vehemently some folk defended AI content and assumed it was their right to post it within our community.
We had no problems with people using it and posting elsewhere, it was the demands that we must allow it that were problematic and made us question whether we were doing the right thing.
No regrets now, though, as we see competitors being flooded with AI slop and they are too invested in it to change now.
He's stating a fact. Turn on showed in your options and scroll to the bottom of the comments on any popular story. There are so many agentic users here.
I just don’t even understand the appeal of having a bot interact on forums for you unless you’re astroturfing for your company or personal brand or whatever
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.
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.
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.
No fancy browser plugins, the ability to autotype, the db file could be synced with anything you can sync files.
Working search - not sure about BW, but it's opensource implementation (Vaultwarden nowadays?) simply didn't allow to search for the fields you didn't scroll yet to.
The biggest problem is lack of multi-edit functionality - you need keep it in mind if you leave somehwere a copy running 24/7.
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.
Luckily offering enterprise / credential sharing features is a decent freemium model. It still wins out in keeping compatibility with self hosted vaultwarden, are there other extensions that let you point to your own domain for the encrypted blob storage?
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.
Windows already has a secure kernel credential store, they could move the Edge password store there with a bit of effort, minimize the splash damage when you retrieve a single password to send over HTTP from the regular user space.
> Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials.
> Credential Guard uses Virtualization-based security (VBS) to isolate secrets so that only privileged system software can access them.
I was looking for an answer to this when it comes to using Edge password manager in particular, it uses Windows Hello as far as I know and while it does make 'synced' passkeys they don't seem to be usable anywhere than the original machine. Useful when reinstalling Windows at least.
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'm pretty sure macOS is more like iOS in this respect. At the very least, the passwords are typically secured biometrically and only the one being used is actually decrypted at the time of use.
"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.
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.
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...
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.
reply