Please write like a normal human and put the effort in to type what you want to say. Using AI to make your writing is not only lazy, it's bland, tiresome, and disrespectful of the reader's time.
I hope this doesn't become the new norm where government becomes the bottleneck for innovation in the AI space.
It's worrying that with no formal and transparent policy framework that the government will be picking winners and losers and stifling innovation.
There's been no public policy, executive order, legislation, or otherwise on this, I wonder if anyone has filed FOIA requests for these decisions or the conversations between the Executive Branch and AI companies.
yep and and it forces every application to deal with the C FFI. It's beautiful in linux that I can access the full kernel API from an int 0x80/syscall instruction + a few register loads without having to link against crap. I can write a simple cat utility in a dozen or so lines of assembly.
Direct system calls are an amazing idea. The NtDll and bsd models are worse. The whole libc becomes a security boundary without the protection of kernel space. So much windows malware and process tampering happens because now you have a library (ntdll) fully in userspace that is given special privileges, which now becomes a huge attack surface. Then you have to deal with breakages between the built in libc versions and the kernel
This syscall overhead isn't as much as you suppose it is; for workloads where the syscall overhead actually makes a difference there are robust low-syscall paths for io/latency sensitive operations with DPDK, io_uring, and futex being a few examples.
And there are robust performant methods on linux for syscall interception/tracing, see seccomp unotify, bpf tracepoints, ftrace.
Very cool! would be interesting to see about combining this with other bpf program types like xdp progs, or socket map attached programs to integrate L7 http features downward.
In practice, mostly scaling sessions and ephemeral data (caching) across multiple intances of a microservice on multiple machines. Seperating the kv store and the application allows upgrading each application while retaining availability and avoiding loss of session data.
Remember, a lot of the memory safety benefits from go and rust and eBPF don't apply to the kernel eBPF! Kernel eBPF enforces semantics that verify array and loop bounds, memory accesses, and correctness of programs via the verifier. I think for most usecases, it is still best to write eBPF in C!
Agreed. Software patents were a mistake in general. It is impossible to implement a modern video codec without using work in patents because of how overbroad and poorly written they tend to be.
I would love to use openbsd. I really wanna give it a try but the filesystem choices seem kinda meh. Are there any modern filesystems with good nvme and FDE support for openbsd.
I frequently see freeBSD jails as a highlighted feature, lauding their simplicity and ease of use. While I do admire them, there are benefits to the container approach used commonly on linux. (and maybe soon freebsd will better support OCI).
First it's important to clarify "containers" are not an abstraction in the linux kernel. Containers are really an illusion achieved by use of a combination of user/pid/networking namespaces, bind mounts, and process isolation primitives through a userspace application(s) (podman/docker + a container runtime).
OCI container tooling is much easier to use, and follows the "cattle not pets" philosophy, and when you're deploying on multiple systems, and want easy updates, reproducibility, and mature tooling, you use OCI containers, not LXC or freebsd jails. FreeBSD jails can't hold a candle to the ease of use and developer experience OCI tooling offers.
> To solve the distribution and isolation problem, Linux engineers built a set of kernel primitives (namespaces, cgroups, seccomp) and then, in a very Linux fashion, built an entire ecosystem of abstractions on top to “simplify” things.
This was an intentional design decision, and not a bad one! cgroups, namespaces, and seccomp are used extensively outside of the container abstraction. (See flatpak, systemd resource slices, firejail). By not tieing process isolation to the container abstraction, we can let non-container applications benefit from them. We also get a wide breadth of container runtime choices.
Hmm I think he's being a little harsh on the operator.
He was just messing around with $current_thing, whatever. People here are so serious, but there's worse stuff AI is already being used for as we speak from propaganda to mass surviellance and more. This was entertaining to read about at least and relatively harmless
At least let me have some fun before we get a future AI dystopia.
Linux /home is far from a free for all. flatpak, landlock, selinux, podman, firejail, apparmor, and systemd sandboxing all exist and can and do apply additional restrictions under /home
Please write like a normal human and put the effort in to type what you want to say. Using AI to make your writing is not only lazy, it's bland, tiresome, and disrespectful of the reader's time.