ah, this filter by timestamp might be very useful to me, thanks
ah, this filter by timestamp might be very useful to me, thanks
last year I had over 1TB freed by docker system prune on a dev VM. If you’re building images often, that’s a mandatory command to run once in a while.
I’ve been doing that for years. Rollbacks are very rare, to the point that it doesn’t make much of a difference whether I do them all at once or not, other than spending more time to do it.
If I wasn’t using containers for everything, sure. Otherwise it’s a bit of an excessive concern.
exactly my point, I’d suggest automating that before I bothered with PRs that upgrade versions, as it’s a waste of time.
“manual changes”, which connotes “local changes”
It doesn’t. Manual as in a PR with upgrades that you’re suggesting yourself, as opposed to running dependabot.
Putting up a PR with changes isn’t considered a manual anything.
If I have to open a PR myself, that’s very much a manual change.
that’s a lot of FUD, topgrade just upgrades using all package managers you have, it doesn’t do the upgrades itself bypassing the manager that installed it, or package authors.
dependabot is a tool for repos, not to apply local changes
That may work for a handful of projects. It’d be my full time job if I did it for everything I run. Also, I might simply suggest maintainers to adopt dependabot or an alternative before I spend time with manual changes. These things should be automated.
what’s the alternative? Write a PR yourself?
upgrade all things by default
Things I already have:
Things I could find useful once in a while:
Things I don’t care about and probably wouldn’t use:
I really don’t want:
Not really a feature:
Atuin*
I just sync my bash history with dotfiles and use FZF for recalling it. I’m not sold on it.
Also, the same history on different machines would be something I definitely do NOT want. I heavily rely on recent history to re-run commands on different machines with different projects and configurations. Mixing all that would be a mess.
you do have an nginx process with PID 2511847
using the port
get more info with
ps aux | grep 2511847
or kill it, if you need to spawn a new one with the right configuration
find out which process is really binding to 443 if you don’t recognize that port as being used
sudo ss -unapt | grep 443
This is such an underutilized and neglected behavior.
The very least a config parser should do is to log a warning.
because of garbage like that I always use the long option names in scripts, even when the short one would be obvious
I don’t think you can. But if it’s open source and popular, there might be a chance it will have a maintained fork should that happen.
Freemium feature creep might be a sign things are changing for the worst, as in, if more and more features are being added to the premium plan and the free version is stagnating; to the point the target public of the premium version is creeping to average users instead of aiming at commercial or power users.
check this out
They run smaller variations of it in their personal machines. There are models that fit in almost any machine, but IME the first model that is useful is the 32b, which you can probably run on the XTX. Anything less than that, only for the more trivial tasks.
ok, that’s it, I’m donating monthly
https://sw.kovidgoyal.net/kitty/support/