sidkshatriya

The networking subsystem is probably the place where FreeBSD is most competitive with Linux.

Linux just supports so much more hardware capabilities and fancy ways of doing things (e.g. io_uring, bpf logic in kernel etc.) that an expertly setup and tuned Linux system will probably exceed the networking speed of FreeBSD and provide more features while doing so. I'm not a networking expert by any means but this is what my understanding is.

I use FreeBSD for mostly for taste and the other reasons I outlined in my detailed answer above even though Linux is superior performance wise.

> in part because I can’t decide whether to go with pkgbase or not…

pkgbase is optional in FreeBSD 15 BTW.

One way to upgrade the base system and another to upgrade packages just feels inconsistent to me and pkgbase finally resolves that. I've not had any problems with pkgbase. I love it and would highly recommend it.

Diversity of programming languages, operating systems, cultures, human languages, countries, music etc. always gives a fresh perspective I've found. You may go back to what you prefer at the end but it gives you learnings that are at a "higher level" :-)

> Is this still true, given how much runs through systemd now?

Yes, still true. On FreeBSD you will realize what complexity systemd might be hiding from you and what additional features it provides. BTW I don't actually like rc init on FreeBSD that much ! I feel that rc.d can learn a lot from more modern init systems like systemd, dinit etc. I don't like reading highly complex rc scripts !!

Yes, FreeBSD current is quite usable. It's fun to start using the new features as they are added to kernel and userland immediately !

NetBSD - situation does not seem that good. Project feels less active now.

OpenBSD - has a fanatical band of security obsessed users. Not going away anytime soon.

FreeBSD - It chugs along. Why is FreeBSD worth trying out ? See my reply above.

14.4 is a maintenance release. If you're installing FreeBSD today, use 15.0

Why FreeBSD ?

- Well manicured OS, excellent docs. More performant than OpenBSD in every way and approaches Linux performance in some areas (e.g. Networking)

- FreeBSD tends to have fewer features in almost all areas compared to Linux which makes it more approachable and more difficult to mess up.

- Though it has fewer features, it still has a lot of features -- many big companies (Netflix most famously) still use it today for critical functions.

- FreeBSD Kernel and Userland developed together -- it has got that undefined "cohesive" feel

- Has less layers of abstraction than Linux, gets the job done. Because there are fewer layers it's easier to understand what is going on and potentially easier to fix.

- FreeBSD is great if you want to learn pf, zfs, ...

- Worth your while if you are bored of the Linux monoculture and just want to try something a bit different (but not tooo different)

- Changes slowly, so good for setting up on a server that you want to just leave running without too much maintenance

- Will increase your Linux skills because diversity always helps the human brain

- Very simple daemon configuration via /etc/rc.conf

- FreeBSD `bectl` controlled zfs boot environments are just so life changing and amazing. (this is possible via snapper on Linux + btrfs but needs complex installation and is not so integrated).

- FreeBSD will accept (smallish) PRs via GitHub if you find a minor bug. Otherwise it uses the decent Phabricator interface at https://reviews.freebsd.org . This is much better IMHO than the mailing list workflow of Linux. The barriers to contribution are lesser than Linux !!

- FreeBSD still has that warm fuzzy small "community" feel which I like

At one time this was an interesting comparison... but now Linux has gotten so much development that even if FreeBSD was Betamax and Linux VHS (in the past)... I would say that Linux is now DVD ... and FreeBSD still remains betamax.

Don't get me wrong, FreeBSD is simple, elegant, consistent and well manicured. It seems to have picked up some pace again. I'm rooting for it.

I've tried this ... I've haven't got much mileage on this, sadly.

Many Linux syscalls are unemulated and things like /proc/<pid>/fd/NN etc are not "magic symlinks" like on Linux so execve on them fails (i.e there is rudimentary /proc support, it's not full fleshed out).

TL;DR Linux containers on FreeBSD via the podman + linuxulator feel half baked.

For example, try using the alpine container... `apk upgrade` will fail due to the /proc issue discussed above. Try using the Fedora container `dnf upgrade` will fail due to some seccomp issue.

The future of containers on FreeBSD is FreeBSD OCI containers, not (emulated) Linux containers. As an aside, podman on FreeBSD requires sudo which kinda defeats the concept but hopefully this will be fixed in the future.

First, I read (article referred to in blog post):

https://blog.hofstede.it/integrating-freebsd-15-with-freeipa... [1] .

_Only then_ I read https://vermaden.wordpress.com/2026/02/18/native-freebsd-ker... [2]

[1] is more high level. [2] is a bit more detailed.

The nix language is maximally lazy. It does not evaluate things it does not need to. This is good because you don't want it to burn CPU building things (very expensive expressions!!) that it will ultimately not need for final derivation. I'm wondering if guix scheme is suited well for this task:

(a) evaluation is eager

(b) lots of variable mutation.

But perhaps lazy evaluation and lack of variable mutation in guix scheme is not such a problem after all for a nix _like_ system -- I don't know.

My theory: China became richer and more developed. So:

(1) Public transport became better and some people shifted to it

(2) Some people upgraded to cars

Anybody own an electric Two-Wheeler ? What has your experience been ? Pros and Cons ?

Thanks for your reply.

> It's a hard language design question and people focusing on this specific case have not really considered how it effects anything else. Sadly, language features and constructs are rarely isolated from other things, even the architecture of the code the programmer writes

And my suggestion is that Rust has got the balance right when it comes to pointers. I can use the traditional unsafe nullable pointer *SomeStruct when it can be null and use &SomeStruct when it cannot be NULL in Rust. Initialization can be a bit painful in Rust but the wins are worth it. Yes, initialization can be less efficient in Rust but then most of the time spent is spend in algorithms when they run, not during initialization of the data structure.

Rust has needless complexity when it comes to asynchronous programming. The complexity is off the charts and the language just becomes unusable. But the non-async subset of Rust feels consistent and well engineered from a programming theory perspective.

In summary, Rust has not compromised itself by using non-null references as the default pointer type and neither will Odin, if it takes a different approach towards references. Take the example of OCaml - it also takes a very principled approach towards NULL. OTOH Java suffers from NULL problems as every object could be null in disguise.

Nevertheless Odin is a remarkably clean and powerful language and I'm following its progress closely ! Thanks for building it !

> I have found that null pointers are usually very easy to find and fix, especially since most platforms reserve the first page of (virtual) memory to check for these errors.

This is true. However, you have done these fixes after noticing them at runtime. This means that you have solved the null problem for a certain control + data state in code but you don't know where else it might crop up again. In millions of lines of code, this quickly becomes a whack-a-mole.

When you use references in Rust, you statically prove that you cannot have null error in a function for all inputs the function might get if you use Rust style references. This static elimination is helpful. Also you force programmers to distinguish between &T and Option<&T> and Result<&T,E> -- all of which are so common in system's code.

Today it is safe to assume that a byte is 8 bits. Similarly it is safe to assume that the first page in virtual memory is non-readable and non-writable -- why not make use of this fore knowledge ?

> This is related to the drunkard’s search principle (a drunk man looks for his lost keys at night under a lamppost because he can see in that area).

This is a nice example and I do agree in spirit. But then I would offer the following argument: Say, a problem (illegal/bad virtual address) is caused 60% by one culprit (NULL dereference) and 40% by a long tail of culprits (wrong virtual memory address/use after free etc). One can be a purist and say "Hey, using Rust style references" only solves the 60% case, addresses can be bad for so many other reasons ! Or one can pragmatic and try to deal with the 60%.

I cringe every time I see *some_struct in Linux kernel/system code as function argument/return. Does NULL indicate something semantically important ? Do we need to check for NULL in code that consumes this pointer ? All these questions arise every time I see a function signature. Theoretically I need to understand the whole program to truly know whether it is redundant/necessary to check for NULL or not. That is why I like what Rust and Zig do.

> not every new language needs to conform to your ideas of what is or isn’t excusable / acceptable.

That's true. Which is why I wrote "IMHO" i.e. "In My Humble Opinion".

I'm not looking to create any controversy. _I_ don't like Odin's treatment of NULL. If you're cool with it, that's fine too.

All the standard libraries use naked ^T .

Maybe(T) would be for my own internal code. I would need to wrap/unwrap Maybe at all interfaces with external code.

In my view a huge value addition from plain C to Zig/Rust has been eliminating NULL pointer possibility in default pointer type. Odin makes the same mistake as Golang did. It's not excusable IMHO in such a new language.

I like Odin and hope for it to gain more momentum.

I have an important metric for new "systems" languages: does the language allow NULL for it's commonly used pointer type. Rust by default does not (References may _not_ be NULL). Here is where I think Odin makes a mistake.

In the linked blog post Odin mentions ^os.File which means pointer to File (somewhat like *FILE in C). Theoretically the pointer can be NULL. In practice, maybe I would need to check for NULL or maybe I would not (I would have to scan the Odin function's documentation to see what the contract is).

In Rust, if a function returns &File or &mut File or Box<File> etc. I know that it will never be NULL.

So Odin repeats the famous "billion-dollar mistake" (Tony Hoare). Zig in comparison is bit more fussy about NULL in pointers so it wins my vote.

Currently this is my biggest complaint about Odin. While Odin packages a lot of power programming idioms (and feels a bit higher level and ergonomic than Zig) it makes the same mistake that Golang, C and others make regarding allowing NULL in the default pointer type.

Wow ! Great use of MicroHS. What is the performance difference between interpreted MicroHS and warm compiled Haskell for a practical program eg. Shellcheck or similar ?

From the blog post:

> Even if your btrfs, after almost 18 years, still eats data in spectacular fashion.

Is this (by now) an urban legend ? Is btrfs any less reliable than, say, xfs/ext4 etc. nowadays ?

It’s wasm. If you object to wasm then you should object to javascript, its predecessor

> Why does AMD come across as so generally clueless when it comes to giving developers what they want, compared to Nvidia?

I have some theories. Firstly, Nvidia was smart enough to have a unified compute GPU architecture across all its architectures -- consumer and commercial. AMD has this awkward split between CDNA and RDNA. So while AMD is scrambling to get CDNA competitive, RDNA is not getting as much attention as it should. I'm pretty sure its ROCm stack has all kinds of hacks trying to get things working across consumer Radeon devices (which internally are probably not well suited/tuned for compute anyways). AMD is hamstrung by its consumer hardware for now in the AI space.

Secondly, AMD is trying to be "compatible" to Nvidia (via HIP). Sadly this is the same thing that AMD did with Intel in the past. Being compatible is really a bad idea when the market leader (Nvidia) is not interested in standardising and actively pursues optimisations and extensions. AMD will always play catch up.

TL;DR AMD made some bad bets on what the hardware would look like in the future and never thought software was critical like nvidia.

AMD now realizes that software is critical and what future hardware should look like. However it is difficult to catch up with Nvidia, the most valuable company in the world with almost limitless resources to invest in further improving its hardware and software. Even while AMD improves, it will continue to look bad in comparison to Nvidia as state of art keeps getting pushed forward.

Now if only they could bring their focus on performance to windows 11 as a whole.

It’s just shocking how much faster vanilla Linux is compared to vanilla windows 11.

Edit: by vanilla Linux I mean out of the box installation of your typical distribution e.g. Ubuntu without any explicit optimisation or tuning for performance

The impact of Effects are a bit less pervasive than null wouldn’t you say ? Effects can be used with code “in between” that knows nothing about effects. Performing and handling effects can be quite transparently

> a module system which is still better than Haskell

The module system though powerful is quite awkward and verbose. I personally prefer adhoc polymorphism (class/instance in Haskell, trait/implementation in Rust). That is really missed in OCaml and is likely to be missing for the next few years even though there have been (stalled) efforts like Modular implicits in the past.

Haskell and Scala seem to have many features lacking in OCaml. Some of those features are excessive I'll admit and OCaml can argue that it is more minimalistic (which is also useful).

Yes, effects are definitely a cutting edge feature in OCaml. But they are untyped which is a big limitation I would say.

TL;DR -- OCaml does many things well. It's a good language. My main point is that the language needs to speed up its pace of evolution. OCaml's lunch is being eaten up by lower level and performance oriented languages like Rust. At the higher level it is being squeezed by Lean, Haskell, Fstar etc.

Now OCaml values adding features carefully to the language so that there is no future regret. But being slow and conservative has _not_ minimized regret. The "O" in OCaml i.e. Objects (and Classes) is almost ignored nowadays. Janestreet, a large industrial user seems to be actively against using the "O" part of OCaml.

So here we have gotten the worst of both worlds -- a language that is evolving slowly and a language that has large features that are almost soft discouraged. My primary language is Rust and not OCaml (mostly dabble in OCaml) so I may not fully know what I'm talking about when it comes to OCaml.

I think this is the tension in most software. If you want to have excellent and correct software it will take time.

And if you want more features with a "fix as you go approach" you will often have huge technical debt and get saddled with poor interfaces, often forever.

But, I think OCaml errs too much on the side of getting it right the first time. The result is that state of the art keeps moving far ahead. By the time OCaml "catches up" the field of programming languages has moved far ahead. So OCaml always remains the Jack of all trades and the master of none (IMHO).

I like the direction OxCaml is taking. But the problem is that no one has another 10 years to see its learnings get folded back into OCaml. There is a real chance that OxCaml may diverge so much that it becomes impractical to merge it into OCaml. Flambda2 is another great piece of software that may also take a long time to come into OCaml proper.

So I feel that things need to be "speeded up" if OCaml has to become a bigger ecosystem. You can see that some big projects are moving away from OCaml -- facebook for instance used to have their python typechecker in OCaml. Their new one, pyrefly is in Rust. This could be an isolated story, no doubt.

Power chips are made by Samsung according to the article. The fab for that is probably in Korea.

How to record/replay and debug a program using reverse debugging through a small example program written in C.

You can also record/replay in a Linux VM on macOS

I'll second that. Incredibly good quality videos. The precision of the narration is simply amazing. Even if you don't intend to practice Prolog in your programming life, it's worth a listen.

If you don't have access to the hardware PMU then you can try https://github.com/sidkshatriya/rr.soft (which is a modification of the rr debugger).

It may not be commercial quality but its open source and free :)

[I built rr.soft]