If yes, you can store that data with fixed size tmpfs - while on servers with modern NVMe handling 5 Gbyte/sec I would not bother.
581 karma · joined February 26, 2022
If yes, you can store that data with fixed size tmpfs - while on servers with modern NVMe handling 5 Gbyte/sec I would not bother.
Though when frontend devs cannot explain which CORS headers and for which origins they do need (again, I'm sysasmin, not even daily reader of Mozilla Developer Network), chances for server/infra level like Varnish to be mentioned is close to 0. With higher chances k8s cluster introduction to be mentioned.
I know couple of frameworks/systems support it, especially in php world.
Looks like that it's lost in layers - dev guys don't care much, sysadmins are sort of extincted, noone to bother to add Varnish into request processing queue. Needless to say, people ok HN even complain on Nginx configs,while for base caching it's much simpler, from my perspective.
can you describe a bit more? I cannot connect the dots here on how terabytes are tied to free v6 tunnel - likely I'm missing some details. Thank you in advance.
No doubts I'm not an expert in Caddy and there are some chances it has unique selling proposition, but I'm yet to find it.
My take on Caddy was - something to let your quickly-crafted-something-newshiny-loneley-dev-docker-container-to-be-available-to-the-world - sort of the same case if I do some tests (we call it MVP here) on my great-idea Flask app and I need plain reverse proxy in front of it with SSL termination, as noone except me and may be couple of Shodan bots won't see.
Yet not mentioned unclear stable releases policy for Caddy.
Hope it clarifies for you.
Not saying that you are not right, but for clarity, on Podman, and in lesser terms Systemd, there are valid points from RedHat - at least from my perspective as system administrator. I suggest you to make your own mind from this article[1].
> According to Walsh's presentation, the root cause of the conflict is that the Docker daemon is designed to take over a lot of the functions that systemd also performs for Linux. These include initialization, service activation, security, and logging. "In a lot of ways Docker wants to be systemd," he claimed. "It dreams of being systemd."
My key take - Docker's developers cared about moving forward fast and making dev's life easier, not about integrating into existing systems well (which probably alone is the reason why Docker was born - see how FreeBSD guys keep believing they have Jails and it's superior over Docker).
> RUN set -eux; \
> groupadd -r postgres --gid=999; \
> useradd -r -g postgres --uid=999 --home-dir=/var/lib/postgresql --shell=/bin/bash postgres; \
> install --verbose --directory --owner postgres --group postgres --mode 1777 /var/lib/postgresql
If we start managing [our] systems, won't we become those weirdo sysadmins we successfully (like 80%) escaped by moving things to Docker? Those guys in sweaters were annoying and moaning on "do this, don't do that, chmod 777 is not good for security"
Really curious now what it was so.
I don't see how it defeats the point - it still nice init / services manager, it still provide features say sysvinit couldn't do at all for my _services_ and management/lifecycle of services.
How often I tackle with resolved or networkd or timesyncd - not even sure, may be once a 2-3 months, while systemd-as-service-manager I do almost every day.
Mind providing some example on your setup/cases?
> Both methods install the CLI tool, python3.12
Won't that require some compiler (GCC?), kernel headers, openssl-dev/gzip/ffi/other_lib headers to be present on end user system and then compiling Python?
At least that's my experience with ASDF-VM, which uses someother Python-setup toolkit under the hood.
As sysadmin I've seen many cases when not letting backend to serve static files drops latency and load significantly. In the worst case, X-accel-redirect is still better than serving through most of the frameworks.
For other stuff, let that nerdy CorpIT handle your system.
FreeBSD still lacks basic LTS functionality and keeping distribution coherent.
May be one day some vendor will create LTS distribution based on FreeBSD with at least 5 years support cycle?
Some people say that Systemd units are complicated or even Nginx configs are complicated or ... . Probably for those who do "Guile Scheme" everyday, it's easy peasy.
From my own experience, AFAIR, Django (python based web framework) tend to have settings defined in Python code, not in some sort of INI files/Config DSL or OpenProject heavily relies on Ruby code for configs - from my perspective [as operations guy] this requires extra work on unparsing those "beatiful" things like lambdas or whatever is cool new stuff people can put in such "configs". But for developers of Django/OpenProject - it's their daily stuff and not a problem at all.
So I'd say - depends on product's target audience.
Hum, I have not considered this aspect before - I mean I've realized that AWS probably cannot use Redis [until they pay back], but that users (customers) would be affected...likely I'm biased here cuz not using managed services of that sort, sat having Redis + Sentinel setup of our own.
how to track those? I'm on the way of applying 24H2 update right now and laptop's uptime is 28 days, I may have many such settings changed, if I follow your idea correctly