The anomaly of cheap complexity - Andrew Appel @ Freedom to Tinker: freedom-to-tinker.com/2022/08/

I see lack of standardization amongst hardware protocols as a leading cause of operating system complexity. That said when I look at Linux's code USB definitely seems to help... But that's by no means the sole source, and if like me you care about keeping not that old hardware in active this isn't an issue that's going away any time soon at all.

@alcinnz @stman will like this one. I am going to check out the slides!

Follow

@theruran Thank you for sharing it with me. Gonna read it with a lot of attention.

cc @thatguyoverthere
@vidak @natecull @50htz

@alcinnz Thanks for sharing !

· · Web · 1 · 0 · 1

@stman @thatguyoverthere @vidak @natecull @50htz @alcinnz

I found the slides (at least) to be well-informed on the issues discussed. The author is presenting a point-of-view that few free software advocates share or will even sit still long enough to consider, but that is nevertheless vital to the survival of free software.

How do we contain untrusted software components but still make use of them?

This question is a can of worms, and I wonder if it can ever be sufficiently addressed. Since we brought up Plan 9, it got me wondering again if it is even possible to evolve *nix/POSIX to be safer and more secure. It seems that too many people are satisfied with piling more cruft on top than tackling any fundamental issues with this cyber-architecture. I think it would be easier to convince people of a migration path that means they can use the same software in the medium-term. Still too few people are aware of the dangers of C and C++ much less the deeper architectural issues we keep discovering such as #Retbleed. And others are sold on the false sense of security offered by Rust. So we are facing not only technical complexity but also amidst a dis-/mis-information complex.

The FreeSilicon conference talk from the creator of GHDL in 2019 echoed what I was saying a few days ago: that software folks are uninterested in designing hardware, and hardware folks are uninterested in free software.

In my thread about the C locale braindeath, someone replied with their ideas of evolving the UI of *nix to pass around typed data structures instead. Is it even possible? I replied by saying that I think a compatibility layer would be a huge engineering project itself. For us, it seems more reasonable to start from scratch and implement things as we need. Reengineering the prevailing cyber-ecosystem seems like such a megaproject that even governments will not fund it.

@stman @thatguyoverthere @vidak @natecull @50htz @alcinnz

here is the Free Silicon conference presentation: peertube.f-si.org/videos/watch

And like you said, he also says there are too few computer hardware engineers and too many software engineers. I have been looking at job postings at semiconductor companies and they have pages and pages of engineer openings. I wonder what is happening? Perhaps their standards are so high because of the complexity of the tools they use, it is hard to enter the field even with an advanced degree.

One of the conference-goers is somewhat hostile toward the presenter at the Q&A, like, "why do you feel the need to make another tool?!" but at least he is undeterred and comes back for another presentation in 2022: peertube.f-si.org/videos/watch

@theruran @stman @thatguyoverthere @vidak @natecull @50htz @alcinnz C and C++ have the problem of nothing covers 100% of their uses. Privsep is something many newer languages don’t take into consideration, for example.

Unix user space ABIs could become a compatibility layer. Like how FreeBSD has Linuxulator as an emulation layer. Linux already has cgroups, and setting a compatibility layer could be an option.

The real answer is going to require evolving a popular *nix into a microkernel.

Sign in to participate in the conversation
Mastodon

The original server operated by the Mastodon gGmbH non-profit