HN user
It's so telling and offputting.
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.
Excellent choice, the "Merge tag 'net-7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net".
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.
Same I had to do a double take. Would be pretty humourous if they somehow took advantage of crypto offloading to accelerate ai inference
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.
10gbe is a sweet spot at least for my homelab stuff. It's easy to find old enterprise gear for, cheap, and fast enough for everything I want to do.
https://lore.kernel.org/linux-security-module/adjwZAevNaDgui...
Patch for linux kernel adding support for enforcing Landlock rulesets from eBPF. In RFC stage now.
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.
This post goes over some of my trials and tribulations in making a clean user experience for TPM2-backed PIN authentication on Linux.
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.
It did something in the real world with real consequences.
It didn't. It made words on the internet.
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.
Quick tip: If you type .patch after the PR url it gives you a git patch. Do curl <github patch> | git am and you can apply and review it locally.
I was prepared to see something like a trimmed down / smaller weight model but I was pleasantly suprised.
I was excited to hear about the wafer scale chip being used! I bet nvidia notices this, it's good to see competition in some way.
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
This is pure dramaposting- "post-mortem" is so misleading and mischaracterizes the situation. I don't use bazzite, I don't know Kyle or anybody here, but I am tired of the drama.
All of the things listed in the blog are personal and technical disagreements, nothing morally reprehensible, no disrespect, nothing that would make anyone want to burn bridges like this.
It's fine to leave a project and to publicize disagreements but this comes across as spiteful.
What practical problems do you run into with systemd?
All the compliants I see tend to be philisophical criticism of systemd being "not unixy" or "monolithic".
But there's a reason it's being adopted: it does it's job well. It's a pleasure being able to manage timers, socket activations, sandboxing, and resource slices, all of which suck to configure on script based init systems.
People complain in website comment sections how "bloated" systemd is, while typing into reddit webpage that loads megabytes of JS crap.
Meanwhile a default systemd build with libraries is about 1.8MB. That's peanuts.
Systemd is leaps and bounds in front of other init systems, with robust tooling and documentation, and despite misconceptions it actually quite modular, with almost all features gated with options. It gives a consistent interface for linux across distributions, and provides a familar predictible tools for administators.
Yes, but you need cap_bpf now to load ebpf programs.
How about just allowing key enrollment with a physical button?
The workarounds we need to enable P2P communication on the internet are a shame... we need turn, stun, webrtc, all this stuff so two computers can talk without a dedicated port forward or public ipv4.
ipv6 is a beautiful protocol, (not perfect, but elegant) with a lot going for it. But the momentum of ipv4 is just too strong.
It's a mess... with no good solution. I tried to turn off ipv4 and github (shame on you) stopped working. But what are we supposed to do? Have the government mandate everyone switch? (oh wait half of US government websites are ipv4 only)
We did this to ourselves...
That's more of a job for an encapsulating protocol. (shadowsocks or similar) Wireguard isn't designed to be obfuscating alone. It's just a simple l3 udp tunnel with a minimal attack surface.
Hi,
I listened to the podcast it was interesting.
Gonna throw some questions you may or may not have gotten.
Are special devices like metadata or write-ahead log devices on the roadmap? Or distributed raid / other exotic raid types?
It would be interesting to hear your thoughts on these.
What do you think zfs got right with this and what did they get wrong?
I am into nix! it's me and my gf's daily driver. thank you.
Both are great tech but solve the problem of safety differently. I would say Fil-c is great for non-performance-critical (think like somewhere between c and go/java, still very fast) existing C programs where compatibility with the existing program / security is a big concern. think ffmpeg, nginx, sudo.
Fil-c:
- You have a great existing c program that may have memory bugs, and you wanna make it safer.
- Or you wanna write a new program in c, and be extra sure it's safe and don't mind a little performance penalty.
- Or you wanna find subtle memory bugs by building your c program with fil-c (asan style) and disable it for performance in your release build.
Rust is great when you want to build a new codebase from scratch, and have the time and patience to deal with the borrow checker. It also gives you some thread safety, (which is different from memory safety) at the development time cost of dealing with the borrow checker. Rust:
- A new codebase where you need multithreading and safety, and want excellent performance
- You need a broad ecosystem of existing packages
- Your problem space benefits from a robust type system.