> "It's phenomenal to me that code I've written in the last 20 years gets used in all sorts of places that I would not have thought of. My son's PS4 runs my code all the time. That's just bizarre. That's great."
It must be really cool to see that and be able to tell your son, "I made that".
>The biggest advantage of FreeBSD over Linux in area of networking is the ability to filter inbound network packets by process ID.
That sounds _awesome_ and I would really like to know more about that feature. While searching the man pages for ipfw(8)[0] and pc.conf(5)[1], I couldn't find anything about filtering by process ID. The closest thing I could find was the capability in pf to filter by process user/group. Is there more you can share about this?
That seems like a mistake or typo. It doesn't even make sense as PIDs are ephemeral and recycled, and installing per-PID rules would be inherently race prone, unless installed by the process itself. It would effectively be a fundamentally broken design.
It's possible there's some other mechanism implied here that permits attaching rules to tagged processes or groups. Maybe they were implicating per-process routing tables or jails, which actually create inheritable contexts amenable to long-term identifiers for ruleset reference, and aren't literally per PID.
It seems more likely they were just referring to UID/GID, but I guess iptables has had an ancillary module for that for quite awhile. In any event, I can't find the quote so it definitely seems it was wrong or at least misleading and they simply retracted it.
I certainly do. My pet project for this summer will be standing up a TuringPi (v1)[0] with 7 instances of networked Plan 9 (or 9front[1]). I'll certainly try exploring this area once that's ready.
Indeed, I hadn't realized that the parent comment I was replying to had been deleted. Furthermore, I wasn't aware that a deleted parent comment on HN would move my own to the parent's level.
I suppose you're right that PID filtering is both prone to problems and not actually available as a feature. On the other hand, Windows is able to offer per-process filtering via it's local firewall - not quite via PIDs but instead by specifying the filesystem path to the process binary. So, it must be possible to implement in some way for non-Windows.
It would be interesting to drag race the latest Linux and FreeBSD on the same hardware and see what the difference in networking speeds are, particularly if like firewall rules are applied. Both are used in a variety of firewall appliances but it's not obvious there's a clear winner given the same set of circumstances.
That's the type of benchmark I would love to see on Phoronix[0], Level1Techs[1], or ServeTheHome[2]. They've done great benchmarks with FreeBSD in the past, although they don't usually focus as much on network performance.
9 comments
[ 8.2 ms ] story [ 109 ms ] thread> "It's phenomenal to me that code I've written in the last 20 years gets used in all sorts of places that I would not have thought of. My son's PS4 runs my code all the time. That's just bizarre. That's great."
It must be really cool to see that and be able to tell your son, "I made that".
I’m getting killed in default-deny model of Linux firewalls. Just cannot block packets going toward a specific process.
That sounds _awesome_ and I would really like to know more about that feature. While searching the man pages for ipfw(8)[0] and pc.conf(5)[1], I couldn't find anything about filtering by process ID. The closest thing I could find was the capability in pf to filter by process user/group. Is there more you can share about this?
[0] https://www.freebsd.org/cgi/man.cgi?query=ipfw&apropos=0&sek...
[1] https://www.freebsd.org/cgi/man.cgi?query=pf.conf&apropos=0&...
EDIT: The parent comment where this quote came from was deleted.
It's possible there's some other mechanism implied here that permits attaching rules to tagged processes or groups. Maybe they were implicating per-process routing tables or jails, which actually create inheritable contexts amenable to long-term identifiers for ruleset reference, and aren't literally per PID.
It seems more likely they were just referring to UID/GID, but I guess iptables has had an ancillary module for that for quite awhile. In any event, I can't find the quote so it definitely seems it was wrong or at least misleading and they simply retracted it.
[0] https://docs.turingpi.com/specs
[1] http://fqa.9front.org/fqa1.html
I suppose you're right that PID filtering is both prone to problems and not actually available as a feature. On the other hand, Windows is able to offer per-process filtering via it's local firewall - not quite via PIDs but instead by specifying the filesystem path to the process binary. So, it must be possible to implement in some way for non-Windows.
[0] https://www.phoronix.com/
[1] https://www.level1techs.com/
[2] https://www.servethehome.com/