These types of projects tend to have a flash of appeal, especially to people used to Linux, because it lessens one degree of unfamiliarity, but they don't seem to stick around for to me obvious reasons.
It's hard to get involved with something like a BSD project because you have to learn a lot and put in enough effort to get committer rights. And then if you want to move the needle you have to do even more work and build consensus without getting overly emotional when people disagree with you. But it is the path I would recommend to have a lasting impact, and I am speaking from experience as a FreeBSD and NetBSD src committer.
Also, pkgsrc is one of the strong points of NetBSD, coupled with pbulk and pkgin. Wrapping that all up in an opinionated installation (like Omarchy recently did to Arch) would be a more survivable effort. But as my friend Larry McVoy would say, it means you don't always get to drive the big red fire truck by yourself.
Historically that hasn't been my experience, but it looks like that's because I never enabled the Solr-based Full-Text Search! Thanks for mentioning this, as I'm going to turn this on right away:
Widely used in commercial and military weapons sights.. EOTech (famous/infamous depending). The legendary FN (Belgian military contractor) just announced one.
You can find random PDP, VAX, even X86 systems that have lifespans 20+ years. As for a single boot probably a much smaller corpus, maybe some forgotten Sun SPARC in a telco on -48V DC power bus.
A VAXCluster or Sysplex(S/390) would I guess be more analogous but those can be a bit Ship of Theseus since you can change the hardware out over time.
For VMSClusters 8 to 10 years seems to be a pretty common uptime for long lived clusters. I worked a gig a few years ago that had a VMSCluster that was up for 19 years at that point. Started on alpha, migrated to itanium, then I helped migrate it to x86. It was the oldest I've personally seen, though I have heard legends of much older.
My current contract has a PDP-11/70 running RSX-11 that's been up since 1992. It's uptime is longer than mine! Poor thing is getting retired next year though.
Wow. I can't imagine the thought process of going from accumulating a decade of Microsoft shares and experience during a pivotal era and deciding to plow it into a consumer scam op.
for some reason, the tech industry attracts these types like flies to...well, you know the saying. They aren't the majority of folks drawn to tech but outside of maybe finance, it seems to be their preferred habitat.
It's easier to see in hindsight but servers have eaten a lot of macro economic headwinds.
1999 and 2002 correspond roughly to telecom and dotcom bubbles popping. So open source operating systems were also pulled up into these positions through a lot of work and by the early 2000s it was kind of obvious this was the way forward.
2008 financial crisis really knocked the high end (RISC/UNIX/Itanium) and started the long migration to renting vs owning. In hindsight it's remarkable how much money used to just be there in the economy of all this. But I guess it still is, considering how expensive public cloud is.
Dell puts a fair amount of engineering into their servers (as do other main brands like HPE and Lenovo) so it's unfortunate they've lost their roots from the old mail order sales company.
If someone else is paying I'd prefer one of these big OEMs for established firmware lifecycle, spare parts and long gray market availability, shock (shipping) and thermodynamics engineering. If I'm paying, Asus or MiTAC (Tyan) are good enough.
I was fortunate enough to work with a fair bit of sun gear (3/260, 4/670, enterprise 250/450 and even some big iron 6500s) back in the day.
These days, I've got several Dell 5820 style workstations and I'm pretty sure someone who interned at sun in the 1990s is now running dell's workstation division. The medium sized dell deskside towers have nearly identical vibes as those old workstations, and are a pleasure to work with.
AFAIK those sold relatively well, considering the TCO of both sides (NICs were very expensive and there were like a dozen companies vying for position once upon a time). They were also interesting because they were cut-through. CX4 was noticeably lower latency than SFP+. So a very fast, but feature limited architecture which is probably why other players like Cisco and then Arista (aka Broadcom) took over.
You can, to some degree, do an online defrag with zfs rewrite -P now although it is not the primary intent. The displayed fragementation may not go down or may even increase, but all the files will go through the allocation policy. zfs fragmentation display is a little misleading, it measures free space fragmentation.
I don't think there is a ton of overlap. tokio is appropriate for general userspace apps, ranging anywhere from a CLI, GUI, API or web app. DPDK and SPDK are specialized fast paths for building network data paths and storage solutions that come with tradeoffs: DPDK uses poll mode drivers, outside of the operating system, which have various implications including busy waiting and taking over the interface. That is why DPDK is fast, no kernel/userspace context switching and copies, and the drivers are tuned for the polling model. But it's not a general purpose building block.
Fwiw with ef_vi you have full control over the event queue - you don't need to busy-spin it, you can choose whatever strategy you prefer.
> tokio is appropriate for general userspace apps
Yep, and for those I wouldn't recommend it. But tokio is also widely used in performance-critical infrastructure and web services. For those I'd say it can definitely be worth taking a second look at kernel bypass.
ef_vi is a solarflare proprietary feature which is now a support product, AMD moved on to Pensando. Once you move away from busy poll, you rapidly lost grounds to use DPDK. The PMD is a deliberate design to elide latency and lower interconnect taxes like PCIe traffic and cache/memory bandwidth by batching queue maintenance, that is the bargain made with a PMD. The field opens to OS native fast paths which have fewer downsides outside of that niche. Application developers are rarely concerned with this because it's far from where the bottleneck is for them.. a web service is rarely primarily a data mover, while a proxy is. Tokio has more in common with Golang than something like DPDK.
It's hard to get involved with something like a BSD project because you have to learn a lot and put in enough effort to get committer rights. And then if you want to move the needle you have to do even more work and build consensus without getting overly emotional when people disagree with you. But it is the path I would recommend to have a lasting impact, and I am speaking from experience as a FreeBSD and NetBSD src committer.
Also, pkgsrc is one of the strong points of NetBSD, coupled with pbulk and pkgin. Wrapping that all up in an opinionated installation (like Omarchy recently did to Arch) would be a more survivable effort. But as my friend Larry McVoy would say, it means you don't always get to drive the big red fire truck by yourself.
reply