My hacky solution for this when working with others has been using git post-receive/commit hooks to execute the org document (babel, pandoc, emacs html export, etc), so anybody with any editor can, if they understand the format, make changes without having to have emacs.
I heavily abuse commit hooks in my hacky CI/CD pipelines though, so ymmv.
Emacs org-mode and babel are what I use instead. Very powerful alternative to Jupyter imho, but of course not for everyone.
I have used commit hooks so that non-emacs users could push updates that still get executed to avoid the emacs tie in though, the biggest issue with it I've found.
As a greybeard sysadmin, this is why I write pure html5/css3 with as little js as possible, and where it can't be avoided, vanilla with no frameworks.
I really have grown to hate most frameworks... (and I don't hate em, but for the devs who push them... it's become the new Java, another bane of linux admins everywhere.)
eBPF is such a supertool that is slept on. I have been working on turning my nftables into it, (on low-latency/high-throughput targets) may I ask how you are using it with Rust?
Sure! I use the aya framework (https://aya-rs.dev) that provides the kernel-side bindings to write the probes in Rust, and the userspace tooling to load it in the kernel, interacts with maps, etc. Quite a joy to work with, and has all the niceties you'd expect from using Rust.
We write XDP apps for custom dataplanes where traditionally DPDK would be used (routers and such). Our upcoming network acls are written this way, so close to your netfilter usage.
I do worry about running so much stuff in kernel space though. Imagine a widespread 0day that hits the kernel, or kernel panics causing kernel crashes that require reboots, the user space priv escalation, etc...
Are you doing fail-open or fail-closed? I've been on the fence on that.
What is the current legal status of eBPF? It used to be that loading any non-trivial eBPF into kernel involved GPL-only stuff, and both the eBPF program and the program that used it had to be GPL.
Well, yes, but this only matters if you distribute the compiled probes: you'll have to distribute the source for the probes. And, thankfully, this is not AGPL where network interaction counts, so:
- a cloud provider writing a dataplane using ebpf does not have to provide the source
- a company selling on-prem software (e.g. esxi) that ships with ebpf probes would need to distribute their source
No it is not, especially the filter controls, and a few other "add-ons" that are not actually core parts of LLMs. As for what they actually do with it, we don't know that either unless by leaks.
# Ensure history is written after every command, allowing it to persist across sessions
shopt -s histappend # Append to history instead of overwriting
PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND"
# Set the history size (adjust as needed)
HISTSIZE=50000 # Number of commands kept in memory
HISTFILESIZE=1000000 # Number of commands kept in the history file
# Add timestamps to history (format: YYYY-MM-DD HH:MM:SS)
HISTTIMEFORMAT="%Y-%m-%d %H:%M:%S "
# Ignore duplicate and space-prefixed commands
HISTCONTROL=ignoredups:ignorespace
# Save multi-line commands as a single entry
shopt -s cmdhist
# Allow history expansion with Ctrl + R
bind '"\e[A":history-search-backward'
bind '"\e[B":history-search-forward'
Also, if you are on shells you worry about, use gnu screen (or tmux if you prefer) imho. It will give you a second layer of history to be able to dig through.
I fear we are about to see refreshed patent trolling conflicts regarding software designs, as it's all in the IP these days, which is the "moat" you are looking for.
I heavily abuse commit hooks in my hacky CI/CD pipelines though, so ymmv.