There’s this program on nix that lets you type a comma, then any application name that exists anywhere in the Nix repos. It then downloads that app and runs it once, without “installing” it. Sometimes I find myself running something dozens of times this way before I realize it should probably be in my config.
Readit Newsxyzzy_plugh commented on Start all of your commands with a comma (2009) rhodesmill.org/brandon/20... · Posted by u/theblazehen
xyzzy_plugh commented on Start all of your commands with a comma (2009) rhodesmill.org/brandon/20... · Posted by u/theblazehen
Every tool and shell that lay in arm's reach treated the comma as a perfectly normal and unobjectionable character in a filename.
You may enjoy learning about the [ binary.
xyzzy_plugh commented on Postgres Postmaster does not scale recall.ai/blog/postgres-p... · Posted by u/davidgu
Why do you need a connection to a database during the meeting? Doesn't it make more sense to record the meeting data to some local state first, and then serialize it to database at the end of the meeting or when a database connection is available? Or better yet, have a lightweight API service that can be scaled horizontally that is responsible for talking to the database and maintains its own pool of connections.
They probably don't even need a database anyway for data that is likely write once, read many. You could store the JSON of the meeting in S3. It's not like people are going back in time and updating meeting records. It's more like a log file and logging systems and data structures should be enough here. You can then take that data and ingest it into a database later, or some kind of search system, vector database etc.
Database connections are designed this way on purpose, it's why connection pools exist. This design is suboptimal.
It took me a long time to realize this but yes asking people to just open and write to files (or S3) is in fact asking a lot.
What you describe makes sense, of course, but few can build it without it being drastically worse than abusing a database like postgres. It's a sad state of affairs.
Another commenter is currently down voted for something similar, but I'll share my controversial take anyways: I hate pre-commit hooks.
I loathe UX flows where you get turned around. If I try to make a commit, it's because that I what I intend to do. I don't want to receive surprise errors. It's just more magic, more implicit behavior. Give me explicit tooling.
If you want to use pre-commit hooks, great! You do you. But don't force them on me, as so many projects do these days.
xyzzy_plugh commented on Show HN: difi – A Git diff TUI with Neovim integration (written in Go) github.com/oug-t/difi... · Posted by u/oug-t
For vim heads also worth checking out tpope's fugitive:
https://github.com/tpope/vim-fugitive
Very useful for inspecting and staging changes, making commits, etc.
I find you can pretty much do anything with it, and it's much faster than anything else, but it does have a slight learning curve. The documentation is very good!
xyzzy_plugh commented on · Posted by u/tartoran
Disappointing but not surprising. There's few organizations as principled and integrous as MSF, and they are generally lovely to work with. They do really good work.
xyzzy_plugh commented on Disrupting the largest residential proxy network cloud.google.com/blog/top... · Posted by u/cdrnsf
> These efforts to help keep the broader digital ecosystem safe supplement the protections we have to safeguard Android users on certified devices. We ensured Google Play Protect, Android’s built-in security protection, automatically warns users and removes applications known to incorporate IPIDEA SDKs, and blocks any future install attempts.
Nice to see Google Play Protect actually serving a purpose for once.
xyzzy_plugh commented on Ask HN: How do you keep system context from rotting over time? · Posted by u/kennethops
1. You make it declarative. The system definition should be checked in to a repository, or multiple repos. If you're not using infrastructure as code, you should be. This is table stakes.
2. Systems should be explicit, not implicit. Configuration should be explicit wherever possible. Implicit behavior should be documented.
3. Living documentation adjacent to your systems. Write markdown files next to your code. If you keep systems documentation somewhere else (like some wysiwyg knowledge system bullshit) then you must build a markdown-to-whatever sync job (where the results are immutable) else the documentation is immediately out of date, and out of date documentation is just harmful noise.
4. If it's dead, delete it. You have version control for a reason. Don't keep cruft around. If there's a subnet that isn't being used, delete it.
Lastly, if you find yourself in this situation and have none of the above, ask yourself if you really have the agency to fix it -- and I mean really fix it, no half measures -- then do so. If you don't, then your options are to stop caring or find a new job. The alternative is a recipe for burnout.
If you can’t deliver to the DLQ, then what? Then you’re missing messages either way. Who cares if it’s down this way or the other?
Not necessarily. If you can't deliver the message somewhere you don't ACK it, and the sender can choose what to do (retry, backoff, etc.)
Sure, it's unavailability of course, but it's not data loss.
We don't stand a chance and we know it.