71–74 of 74 posts
Earlier quoted context omitted.
I actually think this isn't even surprising from OpenBSD philosophically. They still subscribe to the Unix philosophy of old, moreso than FreeBSD and much much more than Linux. That is, "worse is better" and it's okay to accept a somewhat leaky abstraction or less helpful diagnostics if it simplifies the implementation. This is why `ed` doesn't bother to say anything but "?" to erroneous commands. If the user messes…
> That attitude may seem out of place today It absolutely doesn't. Everywhere I've worked we were instructed to give terse error messages to the user. Perhaps not a single "?", but "Oops, something went wrong!" is pretty widespread and equally unhelpful.
But the local user who operates pf is already trusted, normally it would be root.
In either case, no error should be silently swallowed. Details should be logged in a secure way, else troubleshooting becomes orders of magnitude harder.
Earlier quoted context omitted.
The article is about allowing bandwidth restrictions in bytes/second that are larger than 2³²-1, not about how fast pf can filter packets. I guess few people with faster ports felt the need to limit bandwidth for a service to something that’s that large. FTA: “OpenBSD's PF packet filter has long supported HFSC traffic shaping with the queue rules in pf.conf(5). However, an internal 32-bit limitation in the HFSC servi…
> silently wrap around, producing incorrect and unpredictable Now I'm more scared to use OpenBSD than I was a minute before. I strongly prefer software that fails loudly and explicitly.
a_long = an_int * another_int;
Also,
an_int = a_long;