kev009

My hearsay, from friends and colleagues that work(ed) there, is that the shipped product is not really where you see these "heavy hitters".. a lot of the maintenance happens offshore.

If you read commit logs of, say kernel.org and a distro kernel, and aren't concerned you are blissfully ignorant (and it is worse for the broader userland repos). It's particularly bad when they don't track a kernel.org LTS. Their kernel orgs are pretty lean and this has been the status quo for decades. CVEs of sufficient stature like this will get fixed but majority of other issues slip by unnoticed. LTS is kind of a myth, it trades ABI and API stability for a lot of other issues.

These days there are too many choices for FreeBSD, you can submit a GitHub PR, Phorge PR, Bugzilla patch, Phabricator patch, mailing list patch... sharing the code is not the hard part. For NetBSD, a Gnats PR and/or mailing list comment with a patch or link is still the way.

Getting a person's attention who can and will do something is still challenging if you don't know whom, which is the same problem I saw sending patches to Linux mailing lists which went unanswered, and was given no specific feedback or path forward privately contacting the corporate maintainers.

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.

KDE is really great. I have a Threadripper FreeBSD desktop I do kernel work on and it is such a breath of fresh air compared to my work Mac.

I don't know the other servers well but Dovecot has good SEARCH support.

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.

I'm referencing the premium you pay to get some paltry VM in a public cloud with bizarre storage and networking that primarily make sense for the market maker versus the actual cost of the hardware. There are ways to make cloud economics work as a user, but only where staffing costs would dwarf spend (i.e. small businesses) and I've never seen them in practice.

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.

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.

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.

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.