Posted by nathannaveen 18 hours ago
It's an important detail to take into account. I'm sure this optimization makes sense, and the size of additional memory is not that big, but I believe it's good to "measure, not assume" as some load bearing model might say.
In reality, the article is about correctly caching a path:policy mapping while working within the limitations of eBPF and Linux filesystem semantics. If you read the article in that context rather than wondering 'what is new and interesting about memoization in eBPF?' it's a lot more interesting.
I probably would have titled this 'Calculating cache keys for filesystem paths in eBPF' or something, since that's the cool and interesting problem that was solved.
Edit: link to the SELinux kernel Access Vector Cache (AVC): https://elixir.bootlin.com/linux/v3.4.64/source/security/sel...
If your calculated policy is a function of the entire path, you'd normally need to key the calculated policy by the entire path and its relevant properties (underlying inodes) as well, no?
There are path-based LSMs in the Linux kernel that do not employ such caching. If you found a solution for this which also works in the corner cases and results in speed-up in real life scenarios, I'd be interested :)
Additionally, we are thinking of evicting the inode associated with the directory from the cache if a directory is moved. Doing this would probably catch a ton of edge cases and make it simpler.
> Alan Kay, a longtime proponent of agent technology, provides a thumbnail sketch tracing the more recent roots of software agents: “The idea of an agent originated with John McCarthy in the mid-1950’s, and the term was coined by Oliver G. Selfridge a few years later, when they were both at the Massachusetts Institute of Technology. They had in view a system that, when given a goal, could carry out the details of the appropriate computer operations and could ask for and receive advice, offered in human terms, when it was stuck. An agent would be a ‘soft robot’ living and doing its business within the computer’s world.” (Kay 1984).
[1] https://scispace.com/pdf/an-introduction-to-software-agents-...
https://www.eginnovations.com/blog/agentless-vs-agent-based-...
https://www.reddit.com/r/sysadmin/comments/js8h65/looking_fo...
https://www.ibm.com/docs/en/aix/7.2.0?topic=tools-performanc...
https://jolokia.org/agent/jvm.html
https://www.oracle.com/technical-resources/articles/javase/j...
Insofar as you know.. there could be plenty of killer secrecy and gadgetry that was surreptitiously injected by your build/deployment/distribution systems ;)
Edit: the customers, in some cases, did indeed run interpreters that were bad, but that's not my lookout! Buy me a fancy beverage and I'll tell you a story sometime
An agent may or may not also be a daemon. It can be a cron job where the only daemon was cron not the agent, and the agent doesn't persist and isn't a daemon.
It can be purely ephemeral where the only daemon was ssh or http or any other other generic communication service that is merely how the agent was delivered.
Countless ordinary "things that run on a host and perform tasks for some other host" were always called agents. Some of those were also daemons, just as they were also programs.
Nagios, crowdstrike, chef, puppet, ansible, vmware/kvm/virtualbox, jenkins... etc all have a slave part that runs (usually in the form of a daemon) which is and always was called the agent.
Makes the post a joy to read