sidkshatriya

I was clicking and clicking hoping for the reflow madness to stop.

Thanks for this tip -- BTW we need to click _each_ orb.

Occationally a previously untamed orb will start making its presence known until it is stopped. OK I think I have been able to catch every orb now. Now onto read about the future of text layout.

> People inside Microsoft are fighting to drop mandatory Microsoft Account

This is the minimum peace offering acceptable to your long suffering users.

I've used macOS for years and still don't understand their windows minimize/restore logic. I'm always hunting for my minimized window. Yes, the fault probably lies with me.

OTOH the Windows UI is far better well designed and intuitive. But yeah... I'd rather fumble around in macOS: Windows is always trying to upsell a service that I don't need. If I say no it will helpfully keep reminding me (my answer is never going to change). I have 32GB ram and a recent processor being fed tons of wattage -- it feels so bog slow.

Windows needs to fix itself fast.

Decline often happens slowly, gradually and then suddenly. Could anybody imagine Intel where it is now ? This could happen to Microsoft and is probably already happening as we speak.

> sad to see how the fully AI generated "why this matters" section in the blog gives a lingering vibe of slop.

I am quoting this verbatim from offending section:

Why this matters

The traditional eBPF workflow is: write C for the BPF side, compile with clang, then write Go or Rust or Python for the userspace side. Two languages, separate build steps, multiple processes.

With Whistler 1.0, the workflow is: write Lisp. The compiler, loader, and userspace application share a process. You can develop at the REPL — modify a probe, re-eval the form, see results immediately. The feedback loop is instant.

Seems like a reasonable paragraph. I sincerely feel we must stop tainting things with the "slop" pejorative unless it really seems egregious. Also in 2026 is it easy to be so confident about what was generated by a human, edited by a human or generated by an LLM ?

My main metric is: does the paragraph add value ? It does to me as a summary.

FWIW... I have modified packages on Fedora and installed them. The workflow is very simple... of course, not as simple as NixOS but here goes:

# clone the package definition

$ fedpkg clone -a <name of package>

$ cd <name of package>

# install build dependencies

$ sudo dnf builddep ./nameofpackage.spec

# Now add your patches or modifications

# now build the package locally

$ fedpkg local

# install locally modified package

$ sudo dnf install ./the-locally-built-package.rpm

You're right ... you cant check that snapshot into version control and share with your machines etc. When you need that level of control and need to scale your configuration to other machines NixOS sounds like the right choice. If it's for your own machine and you just want to try out a new windows manager non-destructively use snapshots.

I like your analogy and it does make sense.

But note that I did caveat my suggestion: "Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision."

Here is a simple workflow with mutable systems like Fedora that I think a lot of people are missing. AI could be brought into this workflow also for those who want that:

(1) Take a snapshot of your current system (snapper+btrfs on Linux, bectl on FreeBSD+ZFS)

(2) Make destructive changes like install a new windows manager, some drivers etc.

(3) If everything worked out well, continue

(4) If something failed badly, restore from (1) using the snapshot restore -- Your system is as good as before

This workflow replicates many of the benefits of NixOS without the complex nix scripting that can be often needed.

Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision.

[From the article "Why I love NixOS"]

> There is also community-maintained support for FreeBSD, though I have not used it personally

I have tried to use the nix package manager on FreeBSD recently. I tried doing some basic things without success. Seems quite broken and unusable, which is a pity because nix on macOS seems decent. FreeBSD is much closer to Linux so there is no technical reason why nix can't be a success on FreeBSD.

nix on FreeBSD just needs more contributors to fix bugs and make popular packages work ! I wonder if it will ever happen. FreeBSD is niche and nix is somewhat niche (still). It's a double niche problem !

+1, Guix is quite good with some tricks up it's sleeve compared to Nix.

I am not a fan of S-expressions but using scheme is more reasonable than nix+bash to me.

On the negative side, guix can be slow. It is also not a very pragmatic os. NixOS does non-free firmware and drivers without issue. You need to jump through some hoops for this with Guix. This is not an issue if you plan to run guix in a VM though.

Excellently explained writeup. Kudos on explaining the shockingly multiple kernel bugs in a (a) simple (b) interesting way.

TL;DR the main issue arises because the context switch and sampling event both need to be written to the `ringBuffer` eBPF map. sampling event lock needs to be taken in an NMI which is by definition non-maskable. This leads to lock contention and recursive locks etc as explained when context switch handler tries to do the same thing.

Why not have context switches write to ringBuffer1 and sampling events write to ringBuffer2 (i.e. use different ringBuffers). This way buggy kernels should work properly too !?

Usually workarounds/quirks need the highest level understanding of the device driver and the device. There are few people in the world with such mastery and fewer people capable of translating this to another operating system. In concept this is simple but in most cases it is difficult.

> but real life workload are not "Geometric Mean".

A good benchmark suite consists of good benchmarks chosen carefully. These benchmarks are not chosen randomly. They represent diverse ways to "stress" or exercise the system. Real life workloads are indeed closer to "Geometric Mean" of various benchmarks by definition because real life workloads are diverse. Not everything would be like sqlite3 which is single pattern of file system usage.

Geekbench, Cinebench, 3DMark etc. are all averages or geometric means of various benchmarks also.

> When I use firefox, sqlite performance matter more than any random benchmark.

You've selected a single benchmark (sqlite) and said it's so important to you that it overrides everything else when you are comparing ZFS vs btrfs.

If you feel that a single benchmark like sqlite is good enough then that is fine -- your decision. I am hesitant to do the same and prefer geometric mean.

ZFS is worse than btrfs in performance.

Check out https://www.phoronix.com/review/linux-617-filesystems/5 "Geometric Mean of all test results". You will find that OpenZFS is ~35% slower than btrfs.

I love ZFS but I am aware about the performance it delivers.

> There is one advantage of Linux over FreeBSD, which is not widely known. Linux has a huge database of known bugs in various peripheral devices, including Ethernet NICs, and when one of those is recognized it applies workarounds for the bugs.

Almost universal hardware support and workarounds for quirks is precisely the reason why everyone uses Linux even if they might want to use FreeBSD or something else. In other words, this advantage is known and is the reason why Linux is dominant in the server space today.

Why not create a boot environment and try out FreeBSD 15 with pkgbase ? If the experiment is successful just make the boot environment the default otherwise throw it away...

With such powerful tools I find it fascinating that FreeBSD users are not more willing to experiment !

btrfs is suffering from a lot of old bad publicity and some poor design decisions around RAID.

But by now it is a great file system if you don't go near RAID5/6. btrfs has its flaws (ZFS has its own flaws!). However:

- It's used a lot, especially by facebook and Redhat (on fedora)

- Gets a lot of testing

- Sees a lot of bug fixes

- Has a lot of features

I haven't read btrfs code but given that it is a popular file system and Linux code quality tends to be good in popular subsystems I would hesitate to say its code quality is worse than ZFS in any way.

> But the downside is enormous bloat

If you think Linux can have "enormous bloat" then Windows bloat by the same standards is terrifyingly humongous (and slow!).

you can use snapper + btrfs and the end result is like `bectl`. However it not as simple/integrated as ZFS Boot environments on FreeBSD

> Doesn't linuxulator + podman suffice?

No it is not reliable enough. Some syscalls not implemented, there are edge case issues with procfs etc. Best to execute in a Linux VM.

Thanks for the detailed response. Gives me a list of some cool things to explore and learn about !

Every year in various conferences and every new major Linux cycle there are new innovations in the Linux network stack too. To do a true comparison it would be fair to see what innovations exist in the Linux networking stack that have not yet been implemented in FreeBSD. Yes, networking is FreeBSD's pride and joy but Google, Intel and others have done a lot of work on the Linux network stack too (which should not be underestimated).

I don't know why I was downvoted here. One day, I was experiencing weird compilation errors. Clearing the `ccache` C/C++ compiler cache helped get past the problem. Yes, I could have investigated in detail what was the issue and if ccache had a bug but sometimes you don't have the luxury of investigating everything your toolchain throws at you.

I am impressed by the achievements of the Zig team. I use the ghostty terminal emulator regularly -- it is built in Zig and it is super stable. It is a fantastic piece of software.

This makes me feel that the underlying technology behind Zig is solid.

But I prefer Rust over Zig. The main difference is Rust chooses a "closed world" model while Zig chooses an "open world" model: in Rust, you must explicitly implement a trait while in Zig as long as the shape fits, or the `.` on a structure member exists (for whichever type you pass in), it will work (I don't use Zig so pardon hand wavy description).

This gives Zig very powerful meta programming abilities but is a pain because you don't know what kind of type "shapes" will be used in a particular piece of code. Zig is similar to C++ templates in some respects.

This has a ripple effect everywhere. Rust generated documentation is very rich and explicit about what functions a structure supports (as each trait is explicitly enrolled and implemented). In Zig the dynamic nature of the code becomes a problem with autocomplete, documentation, LSP support, ...

> The biggest issue I face daily are silent compiler errors (SIGBUS) for trivial things, e.g. a typo in an import path.

I don't use zig. My experience has been that caches themselves are sources of bugs (not talking about zig only, but in general). Clearing all relevant caches occasionally is useful when you're experiencing weird bugs.

P.S. As -current is essentially running the latest master branch commit it should be evident that FreeBSD will be unstable, liable to break at any point and may have horrible bugs.

So -current is good for experimentation but probably not too much more than that (unless you're Netflix with team of FreeBSD experts who famously like to run -current -- see https://news.ycombinator.com/item?id=47322830 ).

> Translation: whatever investments in time, tooling, training and documentation you made for 14.x, they were useful for about 18 months.

Don't agree. Not too many differences between 15.0 and 14.x -- there are some changes -- mostly improvements and enhancements, many just internal but nothing that voids your pre-existing knowledge of FreeBSD or changes your approach drastically.

> x.0 shouldn't be deployed in production because it is brand new ...

Is that true ? Could depend on how conservative you are. 15.0 came out in ~Dec 2025 and we're now in March 2026... I'd say 15.0+latest security fixes/errata should be OK for _most_ people ? 15.1 should be out in June 2026 for those who absolutely insist on waiting...

Yes, within Linux there is diversity -- I was not talking about that. The server space in 2026 is dominated by Linux.

Solaris ? Gone* WindowsNT ? Niche. HP-UX ? Gone* AIX ? Gone* macOS ? Not in server. FreeBSD ? Niche (smaller than WindowsNT though).

In another world there would be at least two open source server os-es battling it out (like in hardware where we have aarch64 vs x64 and so on).

(*) "Gone" means probably a rounding error by now.

Are you using pkgbase on 15 now or still using the old approach ?

>> and approaches Linux performance in some areas (e.g. Networking)

> FreeBSD has been the gold standard for networking features and performance for decades; not sure I'd agree.

This is the accepted wisdom. But reality on the ground is that Linux has probably surpassed FreeBSD in this domain too. With bpf programs making dynamic packet steering decisions in kernel space, io_uring, support for every hardware networking enhancement under the sun and $$$ being spent by everybody on the Linux networking stack (to speed up AI training or supercomputer clusters for example) I doubt a highly tuned Linux box will be slower than the equivalent FreeBSD one.

(P.S. I'm not a networking expert. This is my assessment though. Someone well versed with networking on both FreeBSD and Linux should confirm on this !)