nvim-orgmode [1] is also available. Knowledge from emacs orgmode should carry over without much issue. I didn't feel like there was a need to reinvent the wheel like neorg does when there were powerful notetaking solutions available; does anyone have a comparison breakdown of features and capabilities?
While the TrailOfBits post is informative, they extrapolate the wrong premise from Brendan Gregg's original post[1]. Brendan's statement was originally about the particular set of eBPF tools created for observability (especially his own). These tools (like bcc and bpftrace) are specifically geared towards observability and were not built for security in mind, nor will they be "patched" or fixed for these purposes.
Does this imply that eBPF is a bad foundation for security-focused tooling? Brendan states the following at the close of this blog post:
> There is potential for an awesome eBPF security product, and it's not just the visibility that's valuable (all those arrows) it's also the low overhead. These slides included our overhead evaluation showing bcc/eBPF was far more efficient than auditd or go-audit. (It was pioneering work, but unfortunately the slides are all we have: Alex, I, and others left Netflix before open sourcing it.) There are now other eBPF security products, including open source projects (e.g., tetragon), but I don't know enough about them all to have a recommendation.
> Note that I'm talking about the observability tools here and not the eBPF kernel runtime itself, which has been designed as a secure sandbox. Nor am I talking about privilege escalation, since to run the tools you already need root access (that car has sailed!).
This reads to me that security tooling built on top of eBPF is possible and various organizations are in-flight making it happen (such as Falco[2], Tetragon[3], and Tracee[4]). These teams have recognized the shortcomings of eBPF and are layering other kernel-instrumentation capabilities such as kprobes and LSM hooks into their solutions.
Additionally, the TrailOfBits blog post states:
> Developers need to be aware of pitfalls like probe unreliability, data truncation, instruction limits, concurrency issues, event overload, and page faults. Workarounds exist, but they are imperfect and often add complexity.
These inherent limitations exist primarily because eBPF is a virtual machine within kernel space. Many of these constraints exist because eBPF programs should _never_ lock up the kernel. The eBPF verifier[5] does some checks on the possible code paths the program can take, such as finite bounded loops, null checks on variables, etc. The foundational aspect here is that the eBPF virtual machine is designed to protect the kernel while running programs in kernel space, and that imperfect/complex workarounds may be needed by security-focused projects to respect that foundation.
System76's next flagship, "Virgo," will be in-house designed and has a trackpoint keyboard with a layout will be similar to their line of Launch keyboards [1].
They've been teasing their Virgo prototype [2] [3] [4] on their social media feeds.
Execution is everything, including the buttons. Someone designing this might also want to look at the Trackpoint buttons from before Lenovo switched to flat keyboards, and see the tactile merits of that (even when combined with flat keyboards).
I wanted to chime in here that I agree with (1) as well.
In the time before Chrome, Firefox market share grew in part because of how aggressively Google and the rest of the web advertised for them. However, that market share peaked and shrunk after Chrome was released; Google shifted _all_ of their advertising from Firefox for Chrome.
I would switch to Apple Maps if there was an easy way to use it on Windows. Apple has no supported Maps website, though you can view Apple Maps through DuckDuckGo. But that's clunky and doesn't solve my use case of mapping routes on my desktop computer and then pulling them up in Apple Maps on my iPhone.
> Org grammar for tree-sitter. It is not meant to implement emacs' orgmode parser, but to implement a grammar that can usefully parse org files to be used in neovim and any library that uses tree-sitter parsers.
This grammar is in active development and is being used by nvim-orgmode/orgmode [1], a org-mode neovim plugin.
We're in the middle of updating the org syntax document. I've been preoccupied and haven't gotten a chance to take another pass, but there should be a new version out in the next month or so. See also [0].
[1] https://github.com/nvim-orgmode/orgmode