Imagine if all the energy spent whining on the purity of a system being insufficiently private or decentralized or somehow loyal to a fight against the man, was spent instead on actually improving those systems. They're open source.
9,714 karma · joined July 28, 2008
Performance of high-scale/low latency systems, counter-censorship systems, embedded systems, distributed VR systems, web browsers, compilers, some kernel work, even the occasional webapp.
Contact: lally.singh AT gmail
But that didn't pan out.
No, because the entire distinction falls apart pretty quickly into "shit I like to discuss and care about" and "shit I don't care about and don't want to talk about."
Systems programming lives and dies by the details you want to ignore. The economics of large software production are mildly affected by language design. But weaknesses there are easily overcome with engineering practices and additional tooling. Almost every complaint about C++ safety I've ever heard hasn't been a problem for me for decades, because I know what libraries, practices, and tools solve those problems. But I've yet to work with another language - and I've programmed in a shit-ton of languages - that gets out of the way as well as C++ when I want to systems-program. Even C. C is strictly lower level, but its lack of abstraction facilities gets in the way more than some of the modern numerical-type-safety stuff of C++ does.
I just finished my work on a 2.5 yr rust project that was very low-level. The problems I had with it were that the language and library designs will always be behind the current state of the art in performance. Hardware and systems APIs change quickly, and they can shift the optimal design decisions easily for different workloads. E.g. chiplets on your CPUs can change where you want to put your io_urings, their workers, and any relevant sq_poll threads. Your NIC's DMA/TLS facilities can change your memory pool policies - do you want zero-copy APIs, or is the copy required anyways because of all the CPU-local work you have to do? Do you preallocate and feed giant buffers to register with the io_uring, or do you need to share your memory pool with the rest of the application? Do you use a single mutex for the pool, a hierarchy between thread-local and global? Do you also use a chiplet-local allocator?
What's nice about C++ is that your fight isn't against the language and runtime. They don't care what your situation is. They'll work. You do have to assemble it, and other languages make some assemblies a lot easier to do.
Yes Rust and its libraries are getting better. But so's C++.
I can't say much about Solaris, I used it - much later - on sparc and amd64.
I can say that I was writing 16 bit windows apps in '95, including drivers and VxDs, and Win 3.1 was a piece of garbage inside and out.
A bug in the software is a bug in the process, and the process is the job of leadership. They've never cared about software quality. They'll put out lots of books about it, lots of talks, lots of claims. But they won't actually put out quality software. It's not in their DNA, never was.
It's not their size nor their age that makes this hard for them. Plenty of larger, older companies put out better product ever day. It's just them. Someone in each size class is the best, and someone else is the worst. MS has been the worst the entire time.
Windows was only ever better than DOS, by the same vendor. It's been awful compared to any competitor it's ever had. Really. I don't see a non-gaslighting argument for Windows anywhere.
Compare to a thinkpad keyboard FRU. They have fluid drains and still cost $99 for a top-end laptop. My daughter's chromebook keyboard replacement at school was $16.
How does it compare to tor hidden services?
Perhaps repro should become the basis of peer review?