_kp6z · HackerTrans

The author also drastically overestimates the capabilities of cloud vendors. CDN and edge have been and will continue to be great business (as you well know) despite pundits predicting their sublimation to cloud subsidiaries for over a decade. For one, capacity planning a public cloud is a lot different and a lot harder than cdn/edge. So the cloud vendor must then act a lot like a cdn/edge, which none have shown any competence in doing. There's a reason Amazon still uses Akamai, Level3, and others for their own Prime Video. CloudFront is a joke in comparison to any prime CDN in terms of network breadth, latency, and overall support from the vendor.

_kp6z

6년 전discuss

Apple has had the performance per watt crown for quite some time. These chips are not very good for anything outside of prototyping, otherwise hyperscalers would run a sea of small nodes.

_kp6z

6년 전discuss

illumos concern trolling, this has nothing to do with engineering leadership and is just lashing out a bad faith personal attack because you are friends with joyent people. Being unable to acknowledge that he served his sentence and is reformed indicates you are just hung up on a failed project that is as useful as spilled milk.

_kp6z

6년 전discuss

Brian Behlendorf and Matt Macy are both fantastic engineers, other people contributed but this is ultimately the kind of thing that must be led by a small number of (in this case two) extremely senior engineers working together for a common outcome with raw technical ability to get everything off the ground and prove it works; and refined leadership skills to stick around til it's actually done!

_kp6z

6년 전discuss

Google's handling of these critical archives they were given is pretty abhorrent. The usenet archives should really be made public since there is no business value to them and they don't care about usenet.

_kp6z

6년 전discuss

I have a huge soft spot for NetBSD because it was my first BSD and first foray into kernel work. The more alarming issue affecting Open and Net is that commodity computer architecture has wildly changed in the past 10 years. A late 1980s style locks and CVs approach to SMP is only good for a handful of cores. Consequently, if you run one of these on what are becoming standard desktop class systems like Ryzen, you are throwing away a great deal of performance (and therefore energy efficiency). Basically modern computers look a lot like an HP SuperDome or whatever from 2000 which is wild and inconvenient for programmers, but reality. FreeBSD (HEAD) is now generally competent on something like an Epyc or multi-socket intel box, and there isn't much left to eek out on an 16-thread laptop.

I funded and helped stabilize a technology called Epoch Reclamation into FreeBSD that can be thought of like a cleaner version of Linux' RCU at least for tracking object liveness. One of the most interesting things I've seen go into FreeBSD recently is a further improvement on that, a novel form of safe memory reclamation directly in UMA: https://reviews.freebsd.org/D22586. This is really exciting because for instance RCU suffers from time of use to time to free issues in Linux, and this new holistic approach really does not for fast turnover workloads.

NetBSD does have a form of SMR called pserialize(9), but ignoring some of the algorithmic weaknesses it also has a lot of global or oversized locks in critical subsystems like the VFS and network stack that turn it into a fairly non-SMP friendly system let alone consideration for different memory latencies like NUMA.

A lot of these ideas from FreeBSD can be copied into Net and Open but the code bases have diverged greatly where it's not some simple forklift (for instance Net and Open use a similar kernel memory allocation that is totally different than Free).

_kp6z

7년 전discuss

Sounds like a pretty clueless layoff, I guess I expected better from Mozilla than usual corporate derp. If there was truly no dead weight, surely the management could have scaled back their own comp for misdirecting the company? Very few people understand what it means to be a leader in corporate world.

_kp6z

7년 전discuss

Heh except if you actually read the comments I present Linux as the high water mark twice for security and stability.

Maybe - and I'm only saying this because I care - you should consider through hiking and come back to the discussion when you are less easily offended by the facts at hand into low grade trolling and have requisite attention span and reading comprehension to participate meaningfully in the conversation.

_kp6z

7년 전discuss

I don't think I can agree scientifically. OpenBSD developers do subjectively seem to think more holistically about security, and having less features lowers the total number but not the ratio and in practice it doesn't seem to have what I would consider a statistical magnitude difference in the type and ratio of incidents that plague C Unix-likes. In the article the author links to one of Ilja van Sprundel's excellent talks; the takeaway is basically that more eyes actually work for security and you could therefore infer Linux is a magnitude more secure than BSD.

I've been quite negative in this thread because the overall debate on these topics is pretty frivolous. We already have the tools at our disposal to do magnitude greater secure software and splitting hairs over which BSD has better defaults is missing the forest for the trees.

_kp6z

7년 전discuss

I use OpenBSD for fun on a couple systems and it is a cute OS, there are things to love about it. But the grandstanding is funny.

_kp6z

7년 전discuss

Yes, run https://github.com/antonblanchard/will-it-scale on operating systems with hilarious grandstanders like OpenBSD and Illumos, then run it on Linux and compare the results. Run a highly parallel make on a modern server and tell me which OS remains usable for other work. OpenBSD runs acceptably on 2-4 core laptops with HT disabled because a desktop workload doesn't typically invoke a lot of the kernel implementation during steady state, but you can do it there with a moderate disk and network load. That said, syscalls are more expensive in OpenBSD than contemporary operating systems so even as a uniprocessor OS it is funny.

_kp6z

7년 전discuss

Sure, say you configure a Linux, OpenBSD, and FreeBSD machine to provide some useful service. A "stack" as they call it these days. None of these OSes are going to have a large attack surface outside that "stack", and that is the primary liability in running an internet service. There are relatively rare occurrences like the TCP SACK bug that affected Linux and Netflix' non-default FreeBSD RACK TCP stack. Every UNIX-like written in C without formal verification is subject to incidents like that from time to time. Every other security concern is addressed in an OS-agnostic fashion with failure domains, limits of scope/networking, access controls, monitoring, and operations procedures.

Now what Linux, and to a lesser degree FreeBSD, can do is survive real world usage at scale. OpenBSD cannot. It would fall over or require magnitude more machine count to do the same workloads that people use Linux and FreeBSD to run. So all the exploit mitigation diatribe and "great defaults" and pet projects are cute but funny when you try and throw shade onto others with them. As I said, there are some kernels of truth that pertain less about security and more about overall health in FreeBSD this doc accidentally hits on, but running some hobby software like opensmtpd on openbsd isn't going to save the world from real cybersecurity issues.