I thought the early section comparing USB APIs was interesting.
The middle section comparing UNIX culture to colonialism was okay but kind of a long bow to draw and bordering on off topic.
And the ending about meritocracy and blaming straight white men just came out of nowhere and didn't fit at all. It seemed like a kind of bait-and-switch; I came for the tech talk about UNIX, and ended up sitting through the last five minutes out of politeness.
In answer to the question about "who should be excellent to whom?", the simple answer is "all of us". But to bring it back to the title of the talk, UNIX doesn't come into it. Cultural problems don't come from UNIX. UNIX is not costing us anything there.
The complaint about the video's statements at the end, about somehow this is all exclusionary, seem very weird to me. And another poster was flagged, for mentioning this?
The sad part is, it terms of learning skills, this is literally the most equality laden industry.
You can used a decade old computer, a used raspberry pi, an old discarded laptop and learn, code, read, play. There's no wall, no secret knowledge, and OSS software has code, and man pages, and information everywhere.
There are endless websites and communities, forums, mailing lists, and no one cares who 'webname45' is, or what their skin colour is, or orientation.
This field is about intellect, not about going to a entitled school, or even school at all! You can be a high school drop out, and easily succeed here! So many people are self taught, and it has nothing to do with privilege, or cost, or access, none... none of that is a barrier to learn in this field.
Complaining about "this is complex" is asinine, and conflates "learning stuff" with privilege.
"Learning stuff" is not exclusionary, when there is no bar, no restrictions on doing so. When anyone can do so.
People growing up in third world nations, malnourished, hungry, poor or no schooling, with english as a second language, easily pick this stuff up.
Because all it takes is intellect, raw intellect. Not learning, not background, no help needed, no money needed, but just intellect and reading.
And if you're going to call intellect or "knowing stuff you can understand for free" barriers, it's you that's the problem.
Look at the video games industry. People travel from all over the world to study in *Dundee* of all places, which for the Americans here is about the side of Bridgeport, Connecticut, simply because the universities there offer the best courses possible about developing and marketing video games.
Why?
Because in the 1980s, when Dundee was the heroin death and teenage pregnancy capital of Europe and unemployment was at something like 45%, one of the employers that *was* there was Timex, where they made the Sinclair ZX Spectrum, and so everyone had a ZX Spectrum because everyone's dad "knew a man down the pub who could get them". Everyone owned one, so everyone who had a modicum of talent could write games for them, and if your games were any good then within a day or two everyone in your high school had a copy of it.
Loads of folk in the tech industry who grew up in Scotland in the 1980s owe their livelihood to some guy in the Planet Bar in Lochee who could get knocked Spectrums for 100 quid...
Many interesting points in that talk. I have a question for the knowledgeable:
The author mentions that the C CPU and memory model is based on a single-core, linear-memory background that belies the complex internals of modern CPUs. Then he mentions Rust as an example of a departure from that model. How is Rust better able to utilize modern CPU features (multi-core, pipelined, out-of-order...) and GPU?
C compilers already optimize for CPU instruction order on multi-issue pipelined CPUs. Multithreading in C, however, is left as an exercise to the coder. You manually need to use locks and make sure no race conditions are occurring, which is hard in large programs. Also, no function is thread safe unless you're explicitly told so.
I don't use Rust very much, so someone correct me if I'm wrong, but the ownership and borrowing system makes the compiler fail if you transfer data to child threads and then use it in the main one. It's just safer to parallelize code, and you'll do it! (unlike in C, where it may be better not to risk it)
> Multithreading in C, however, is left as an exercise to the coder.
Well, it is a systems implementation language, so it cannot, and should not, impose too many guardrails.
And yes, sometimes systems implementations need to do things that even all the checks built into Rust would scream loudly about. Rust, which is also meant to implement system code with, acknowledges this duality, that's why the `unsafe` keyword exists.
And while the complexity of avoiding race conditions does exist, we have good solutions for it. One such solution is CSP. Passing state and synchronizing via messages is an incredibly natural and logical way to think about the structure of concurrent codebases.
Rust prevents data races by the help of the borrow checker (by preventing multiple threads using the same resource concurrently), and it also helps by disallowing sending objects to other threads if they were not marked as capable of such.
The principal difference is that rust constrains aliasing somewhat more than c. The practical differences currently are more relevant to compilers than cpus, since architectures do not provide a way for programs to provide aliasing information to the cpu, and so cpus do their alias analysis dynamically, in a way that works as well for rust as for c. But one can imagine an architecture which allowed programs to supply aliasing information statically. This would be relevant for both c and rust, just somewhat more so for rust.
Besides being a polical problem as per sibling comment, it is interwinded with UNIX, fixing some of the problems means moving away from being an UNIX as first step.
Kind of ChromeOS and Android kind of have been doing, depending on the Linux kernel and little else.
The more I saw the "So What" slide after each deficiency exposed, the more I saw it as subverting the whole presentation. Yes, there are problems, but it appears that didn't prevent UNIX&Linux from persisting and succeeding in many forms of computing. The presenter curiously forgot to mention "worse is better" principle.
Yes, but the problems are always multifaceted. So sometimes even an apparent weakness might come off as a strength or a non-issue in a different situations. For example it's interesting that for all its technical excellence Windows isn't present in the HPC space.
HPC is not a very well defined term or domain, and Windows not being free beer is probably only a small part of the reason. While some of HPC is close to universities, cash is not a general problem in this domain by far.
What about Unix/Linux being easier to automate, what about them having better performance on some important axes (like file systems)?
What about it being easier to open up and tweak? To reach inside the kernel?
I find your reply to be a little bit strange. As often you're throwing some claims in the air, and only back those up with seemingly irrelevant links. I've never used Azure which is behind that "HPC" link, but at least Azure != Window in my book.
I doubt that Windows licensing costs are that significant compared to HPC hardware. If there are good technical reasons to run on Windows, licensing shouldn't be an issue.
Windows source code only being available through a tedious process might be a big problem. The free beer part is only a small aspect, and being accessible might be more important (as I said).
You haven't reacted to Windows filesystems seeming slower (can only judge from my work PC), and slow filesystem are pretty sure a bad thing for many HPC workloads.
I don't know much about Windows administration, but from all I've witnessed it's a lot of manual clicking around and fixing configurations that get periodically overridden. Scripting tools, like Powershell, and package managers for sure exist, but Windows never had an equally pronounced administration culture like Unix had. Heck, look at cmd, it's a bad joke (and I still begrudgingly use it because Powershell never seemed inviting to me to learn, and doesn't seem nice for interactive use).
It might even have become better with Powershell and everything, but things don't change overnight.
For kicks I asked ChatGPT about it and it basically told me the same thing.
PS: not a fanboy, I'm writing this from my Windows dev machine.
To save everybody's time: this is about straight white men making an OS for them and thus terrible for everybody else.
And it has some puzzling examples. For example if you want to kill a process according to the presenter you need "ps auxwww | grep process_name | grep -v grep | awk '{print $2}' | xargs kill -9". He compares that to GUI Mac OS process manager and how the Unix way is exclusionary for anybody other than straight white men.
Well, how about "pkill process_name"? How can you put the GUI way into a script? Should we replace all code with GUIs, even the presenter's Rust and Python? Why does he pretend that Linux graphical desktop environments like Gnome or KDE don't exist? Can we answer any of these questions without whitestraightmansplaining? Press the flag story button to find out.
If you have not watched the video, trabant00’s comment will sound somewhat odd. However, the presenter does indeed draw parallels between C and Colonialism around 17:25 into the video, the part about macOS is at roughly 25:30, and the “straight white men” part at around 30:25. Without this context I do think it is difficult to understand why trabant00 wrote what they wrote, especially as the video very much starts out on a much more technical note.
I initially set out to save other people from the bait and switch from unix to politics but then I made a convoluted comment which confused people even more...
Why did you feel the need to bring sexual orientation, skin color, and gender into this? Do straight white men get the chance to voice an opinion without being dismissed as straight white men? Could we, maybe, when discussing technical matters, talk about the topic at hand, instead of discrediting people straight away for their inherent properties..?
*edit:* as trabant00 pointed out, this is actually brought up by the speaker towards the end of the video, I didn't catch this the first time. I apologise for jumping to conclusions here.
> To save everybody's time: this is about straight white men making an OS for them and thus terrible for everybody else.
That's not what the talk is about, that's one of the examples of brokenness he's talking about, as is the kill example, and yes they are deliberately troll-y examples.
The talk is about the very last statement "sometimes you have to drop your tools and make new ones" whether that's "everything is a file", "do one thing and do it well" (the ps example), or the way communities are structured. You don't have to agree with him on any of them but to dismiss them as "whitestraightmansplaining" is to duck as the point flies over your head.
> The talk is about the very last statement "sometimes you have to drop your tools and make new ones"
Go ahead and make them. I see no army of white straight men with unix swastikas stopping everybody else from making their kernel/OS exactly the way they want it.
The talk is not about building new stuff. The talk is about attacking some people based on their race, gender and sexual orientation. The talk is about gaining power over a tool and a community, ousting the ones who built it because "it's wrong and we'll fix it". The talk is political with a thin veneer of tech.
The talk is what it is, the points are the one he makes, there's no emperor's clothes that only you can see but fly over my stupid old head. If the talk would be about building there would be a presentation of some code skeleton or at least some design schemas.
I’ve met benno at various linux.conf.au and pycon events. Lovely fellow. It’s a nice surprise to see someone I know from the Australian scene pop up on the HN front page.
The middle section comparing UNIX culture to colonialism was okay but kind of a long bow to draw and bordering on off topic.
And the ending about meritocracy and blaming straight white men just came out of nowhere and didn't fit at all. It seemed like a kind of bait-and-switch; I came for the tech talk about UNIX, and ended up sitting through the last five minutes out of politeness.
In answer to the question about "who should be excellent to whom?", the simple answer is "all of us". But to bring it back to the title of the talk, UNIX doesn't come into it. Cultural problems don't come from UNIX. UNIX is not costing us anything there.