you said “latest thread” and I like “didn’t he called for a truce” the I see this comment was three days ago… obviously he has said everything and the opposite by now.
True. But tbh, you can find ppl making time for themselves or not, in most salary ranges. Extreme poverty is another issue ofc. That’s why we have social welfare, to avoid extreme poverty.
Where I live, when meeting ppl they don’t introduce by asking “so what do you do?”, instead the phrasing is somewhat akin to “what do you spent your time on”. Even though they mean “what is your profession”, it allows me to stir the discussion to “what I like” or what kind of subject I enjoy discussing at that time eg philosophy, theatre, books, etc.
PF itself is not tailored towards ISPs and/or big orgs. IPFW (FreeBSD) is more powerful and flexible.
OpenBSD shines as a secure all-in-one router SOHO solution. And it’s great because you get all the software you need in the base system. PF is intuitive and easy to work with, even for non network gurus.
Docker is a concept resembling FreeBSD's jails that were introduced in year 2000, having much better isolation, much better security than Docker has had for a long time (perhaps even now jails are still superior to Docker).
Better isolation, better security, but far fewer gists and shared config-files shared ok the Internet for common tasks. Docker comprehensively wkn thr popularity contest, and is often the more convenient solution because of it, in a worse is better way.
People comparing Docker and Jails don't really understand that Docker is 99% about packaging and composing software. From that perspective Jails are nothing like Docker containers. No versioning, no standard, no registry, no compose, no healthchcks, no tree of containers, etc. etc. etc.
If you want to compare Jails to something on Linux then I think LXD is probably much closer to what Jails are.
That is not really accurate? Linux traffic control (tc, [0]) exists since Kernel 2.2. It can introduce traffic latency and a few other network conditions, like packet loss.
Hmm kind of... I was referring to the fact that dummynet models pipes with a fixed bandwidth and centralized scheduler. Packets are released according to very high precision transmission timing. This means that serialization delay, queue buildup, and link behavior are simulated in a way that resembles real network conditions. Dummynet can provide a highly deterministic timing and queue behavior, which made it popular in networking research and WAN emulation experiments. TC cannot do that with the same accuracy.
I think much like other tools, think SELinux vs OpenBSD (unveil, etc) TC is more flexible (does more things) but there are _some things_ that can't do, and even for things both can do *BSD solutions are much simpler.
AFAIK the most common is ARC but there are other areas as well.
On Linux, ARC memory is reclaimed using the kernel shrinker API which has historically been a problem. There has been several bugs leading to OOMs or system freeze due to high memory usage on systems that use ARC heavily.
On FreeBSD ARC is integrated directly with the VM subsystem. The stack is simpler, less bug-prone.
Now this is not a ZFS algo/whatever problem. It's an implementation/subsystem issue but it's still something to keep an eye on for the ZFS admin.
ps. I'm using ZFS on Linux for 15 years on a self-hosted, home backup server and only once I've had mem issues leading to crashes when I misconfigured the ARC. So it's fairly _stable_ but still not FreeBSD-level stable.
> … the kernel shrinker API which has historically been a problem. …
Is that still a problem?
A few weeks ago I noted a change in ARC-related documentation for OpenZFS on Linux. I can't remember the details (I can find them, if necessary) but I do remember that it was a significant improvement for Linux users.
reply