HN Theater @HNTheaterMonth

There's this great USENIX talk by Timothy Roscoe [1], which is part of the Enzian Team at ETH Zürich.

It's about the dominant unholistic approach to modern operating system design, which is reflected in the vast number of independent, proprietary, under-documented RTOSes running in tandem on a single system, and eventually leading to uninspiring and lackluster OS research (e.g. Linux monoculture).

I'm guessing that hardware and software industries just don't have well-aligned interests, which unfortunately leaks into OS R&D.

[1] https://youtu.be/36myc8wQhLo

⬐ est31

I think making it harder to build an OS by increasing its scope is not going to help people to build Linux alternatives.

As for the components, at least their interfaces are standardized. You can remove memory sticks by manufacturer A and replace them with memory sticks from manufacturer B without problem. Same goes for SATA SSDs or mice or keyboards.

Note that I'm all in favour of creating OSS firmware for devices, that's amazing. But one should not destroy the fundamental boundary between the OS and the firmware that runs the hardware.

⬐ dist1ll

Building an OS is hard. There's no way around its complexity. But closing your eyes and pretending everything is a file is a security disaster waiting to happen (actually, happening every day).

And furthermore, OS research is not only about building Linux alternatives. There are a lot of operating systems that have a much narrower focus than full-blown multi-tenant GPOS. So building holistic systems with a narrower focus is a much more achievable goal.

> As for the components, at least their interfaces are standardized

That's not true once you step into SoC land. Components are running walled-garden firmware and binary blobs that are undocumented. There's just no incentive to provide a developer platform if no one gives a shit about holistic OSes in the first place.

⬐ simonh

> There are a lot of operating systems that have a much narrower focus than full-blown multi-tenant GPOS.

I hear some of them are used to manage embedded components in GPOS systems. Oh, wait…!

⬐ dist1ll

Narrow focus =/= only control one hardware component

⬐ MisterTea

> But closing your eyes and pretending everything is a file is a security disaster waiting to happen (actually, happening every day).

What is this in response to? GP never mentioned file interfaces.

⬐ Godel_unicode

Sure they did, they talked about the abstractions present in Linux.

⬐ MisterTea

I'd like to know why they believe this.

⬐ GekkePrutser

> But closing your eyes and pretending everything is a file is a security disaster waiting to happen (actually, happening every day).

How so? I can see the limited access control in Linux is an issue, and for this reason augmented security MAC (Mandatory Access Control) controls exist like SELinux and AppArmor.

But I don't see how the nature of everything being a file is a vulnerability in itself.

I'd be happy to learn how though.

⬐ dist1ll

It was a lame attempt at humor, a roundabout way of referring to the simplifying assumptions that *nix systems generally make of the underlying machine.

⬐ dist1ll

Not that in itself, it was more of a jokey way of referring to simplifying assumptions made by *nix systems.

⬐ fanf2

If you want to follow the principles of capability security, then a key part of the strategy is to eliminate “ambient authority”, that is, any kind of globally accessible way of obtaining a capability.

In traditional unix-like systems, file descriptors are very close to capabilities. But the global filesystem namespace is a source of ambient authority.

There are a couple of ways to fix this issue: fine-grained per-process namespaces like Plan 9, so that the filesystem’s authority can be attenuated as necessary, so it becomes more like a capability. Or eliminate absolute pathnames from the API, so you have to use functions like openat() to get an fd relative to an existing fd.

⬐ lbotos

Also one by Bryan Cantrill recently around the stack of black boxes:

https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...

The IME gets a lot of hate around here, but let's not get distracted by it: higher-privilege co-processors running code outside the main OS' control is becoming (or already is) the norm everywhere. Intel-based PCs are just one instance of it (and perhaps not even the most egregious one).

Most hardware has evolved to effectively run the main OS under a sandbox where it "thinks" it is in control, but isn't.

A nice talk on this: https://www.youtube.com/watch?v=36myc8wQhLo

⬐ uncletammy

> higher-privilege co-processors running code outside the main OS' control is becoming (or already is) the norm everywhere

There may be good arguments for allowing these types of "features" but this is not one of them. I'm so tired of seeing "it's fine because everyone else is doing it too"

⬐ marcosdumay

The GP is not saying anything is fine.

⬐ nicce

Well, he kinda makes it sound like that the fight is over and it is time to move on.

⬐ CrLf

Quite the opposite. While IME is discussed to death, the same loss of control is happening everywhere and becoming more and more entrenched.

Like mentioned elsewhere in this thread, the problem isn't the presence of these types of components, but how opaque to the user (read: highly technical user) they are. Also they exist because there is demand for their features.

The talk I linked makes the case that OS development is failing by pretending these co-processors are outside its scope, and hardware vendors just go and do their own thing on the side. I add that this incentivizes proprietary firmware instead of open one. I mean, if there were pressure (from paying customers) for Intel to support open-source IME firmware, they'd do it. After all, they just want to sell more chips.

⬐ smaudet

We need more exploits of these co-processors running in the wild. This stuff is done in the name of security but is incredibly insecure by nature. We know e.g. the NSA requests builds with this stuff turned off, but if more govts are affected then fewer will put up with this, the markets can follow.

⬐ blueflow

Yes, and its a movement into the wrong direction. I do not trust the vendors to run code on co-processors that i have no control over. I somewhat expect it to be spyware and ads/data collection soon.

⬐ ethbr0

And support DRM to protect media companies' IP.

Because $$$ talks, and there's a lot of money in media.

⬐ nicce

Well, luckily we have TPM chip just for that...

⬐ pedro2

Nope. kernel module mei_hdcp exists on modern systems.

⬐ d110af5ccf

nope, that's blacklisted on all my machines

⬐ wmf

Tech is actually much bigger than media. The tail keeps wagging the dog for some reason.

⬐ _nalply

I have taken the time to watch the talk.

What I have learnt (to my dismay): Complex hardware has their own software, like IME, but they do important things you can't turn off. The danger in this: hardware-based exploits. In other words, the security of an OS is irrelevant if there is some shoddy closed-source software on your system running hardware components. Linux already has lost the control of hardware. It's like virtualization, but on the hardware level.

People talk about switching off the IME, but that's barking up the wrong tree.

What's proposed: redesign hardware and write an OS encompassing all hardware functions. Don't accept opaque SOCs where your OS is just an API consumer.

This is controversial because of course DRM components want to be a black box, for example.

⬐ _nalply

Follow-up: Now I am afraid the victory of Asahi running Linux on Apple Silicon systems is only superficial. Apple still has a tight grip on how hardware is ran on a level lower than Linux.

If I am wrong, please point out. I would be happy.

⬐ EricE

People have been worrying about Apple locking stuff out for decades - and they haven't. And why would they? What do they gain by restricting access to the hardware? It just doesn't make sense. People love to ascribe all sorts of motives to them that are, quite frankly, utterly ridiculous. They aren't perfect - no one company is - but they certainly are one of the better choices given where things are going in general.

⬐ _nalply

No need to be negative ("utterly ridiculous").

And you seem to have misunderstood me. It's not about Apple locking something, its about Apple software on the hardware of your Asahi Linux system.

⬐ dottedmag

Apple M* CPUs do not have anything like that.

Their coprocessors are not higher-privileged. On the contrary, they are all isolated from AP, each other and main memory (by IOMMU).

⬐ smaudet

Hmm. If Apple were easier to develop on I'd consider buying their M chip laptops for that reason alone.

My issue last I worked with one was that userspace was ridiculously restricted - they have made it antagonistically difficult to do anything on a Mac. Normal PC, despite the nonsense in the hardware, remains fairly easy to work with, as long as you aren't doing security critical stuff.

⬐ dottedmag

You might be interested in following https://asahilinux.org/ then

⬐ Xelbair

Sure, but does the separate co-processor needs access to network stack? for a typical end user? definitely not.

⬐ nullc

Is any remote management system available to the public using the ME stuff on consumer systems? I haven't seen it.

And when you look at server hardware the have completely different backdoor facilities.

It really looks like pure pretext, especially since there isn't just a simple bios option to comprehensively and completely disable it.

⬐ wmf

https://www.meshcommander.com/

⬐ None

None

⬐ bragr

It does if you want remote management, which almost every IT department does.

⬐ salawat

...And which almost every pther computer decidedly does not, and more problematically, every other computer user has no visibility into the configuration, implementation details, or actual specs of said highly privileged component.

It's one thing to have it, but if it sits out of my reach, sorry hoss, I just don't trust you that much, and the fact you and your buddies all do it and are the only shops in town doesn't make me feel any better.

⬐ boppo1

Can we not have separate enterprise and individual classes of processor?

⬐ wmf

Consumer PCs already don't have vPro/AMT, although Intel can't afford to make separate hardware so there's a concern that the out-of-band hardware path could be activated later by malware.

⬐ ranger207

Heck, ECC is already market-segregated

⬐ bubblethink

This is also segmented. The remote management stuff is marketed as vpro which is not available in all SKUs. However, all Intel processors need the ME.

⬐ Spooky23

We do. Every time this topic comes up, everyone gets angry about something that doesn’t affect them, at all.

⬐ vetinari

We do, sort of.

In order to have network access, Intel Management Engine is not enough, it does not have full network access at all. You need Intel AMT (also marketed as "vPro"), and that one is paid extra. With CPUs featuring such support being separate SKUs, so you would definitely know -- and you can check in ark. You also need to pair it with Intel ethernet or wifi, any other network interface is not good enough.

So here you have it, your separate class of processor.

⬐ _jal

But almost no non-corporate machine owner wants it.

I think you would agree that machine owners should control the administrative interface as well, which means the ME should be easily disabled.

But instead the kill-switch points the other direction. There is a switch to disable it, but only certain government users apparently get easy access to it.

That's one of the aspects of this that leaves room for a lot of disquieting theorizing.

⬐ goodpoint

This is plain false.

⬐ chasil

No IT department wants their remote management at BlackHat.

https://www.runzero.com/blog/ilo-vulnerabilities/

I'm not sure that iDRAC is much better; haven't checked lately.

⬐ snuxoll

At least with IPMI interfaces on servers they have a dedicated NIC port you can put on a restricted network.

⬐ Sirened

Yep, the practical difference between a hidden higher privldihe level and another random coprocessor on the system bus which can send memory writes to your core's internal MMIO region (common on ARM based SoCs, anyways) is quite literally zero. If you can write arbitrary physical memory, the entire system is cooked (well, mostly, but RIP SGX). IME is no worse than random DSP, ISP, ML, etc. cores on your average SoC in terms of its privilege in the system. Don't miss the forest for the trees.

⬐ Kukumber

They banned Huawei equipments for less than that

How come Intel get away with it?

I went ahead and i disabled it

⬐ alex_duf

It's about who's your threat. The us government probably like having an American company (Intel) that distributes an attack vector. But they probably don't like being distributed one.

⬐ smaudet

Except the irony is it's baked into their systems as well, so you distribute your own national security threat...

It's like phone lines, Intel agencies loved being able to arbitrarily tap lines, at least until they started having their own lines tapped as well.

If I were China or Russia I'd have stockpiled a couple bugs in these backdoors and I'd be waiting to cause major economic disruption to the US govt with their own systems... so then it's just a game of who can knock out the other's comms first (which is as I understand it doctrine generally speaking in conflict, but)

⬐ alex_duf

> Except the irony is it's baked into their systems as well, so you distribute your own national security threat...

From the article posted by OP

>sets the 'High Assurance Program' bit, an ME 'kill switch' that the US government reportedly[11] had incorporated for PCs used in sensitive applications[12][13];

[11] links to a dead website, but it makes you understand the US called dibs on disabling it

⬐ clhodapp

Architecturally, that is fine... but if it's not open and well-specified it will continually face (well-deserved) distrust.

⬐ hsbauauvhabzb

‘Everyone else is doing it’ is a bad excuse. Arbitrarily focusing on intel has made it so others know if they perform shady actions then it’s possible they’ll also become an arbitrary target.

The disproportionate hate is a good thing, if you ask me.

⬐ dizhn

Thank you thank you thank you. I've been trying to find this talk forever after watching it once. I immediately knew this was it when I saw it under this particular thread. Super Illuminating stuff.

⬐ captainmuon

I think this model is completely wrong and should be inverted. The main CPU should be on top and run completely transparently. If you want secure coprocessors for DRM and cryptography, they should be subordinate black boxes.

⬐ uni_rule

Like a tpm module?

⬐ captainmuon

Yeah, or like a HSM for example.

⬐ coldacid

I for one would be fine with a TPM that is on its own silicon and carrier rather than on the processor die or otherwise inside the CPU package. Then I could disable it when I don't want it working, without possibly killing my processor by doing so.

⬐ StillBored

I sorta disagree with the premise of that talk, although the problem is real.

Its just that even that talk vastly underestimated just how many microcontrollers exist on a modern machine.

In the past those controllers were isolated to a few areas (disk controllers, higher end network cards), but the drive over the past decade+ for more efficient devices and "universal" packetized buses (ex PCIe, USB), has sprinkled them in places simply to monitor utilization and adjust bus clocks, as well as packet scheduling and error/retry logic, etc, etc, etc. I was reading about some of the latest m.2 NVMe controllers a while back and IIRC there were something like a half dozen independent Arm's just inside the controller. The last fully open disk stack on a PC was probably an MFM/RLL controller in the mid 1980's.

So, while I would love if the manufacture of every little USB device or whatever published the full register documentation, firmware listings, whatever, that ship has long sailed. The worst part isn't looking for the piles of scattered SPI flash eeproms on random boards, its the integrated "Secure" sides of these devices which happen to be all but invisible. None of that is going to be documented anytime in the near future. Every single one of these companies hides their "secret sauce" in the firmware of these devices, be that how to minimize latency on a NVMe device, to how to get maximum throughput on a wifi chip, to how to increase a DRAM controllers power efficiency. In some of these cases, the firmware probably isn't even that special, they are doing basically the same thing as every one of their competitors, but you will never get them to admit it.

So, imagining that an "OS" can control this mess like a 1960's mainframe is nonsense. Modern mainframes don't even control stuff at that level anymore.

So like software abstractions, we have hardware abstractions which provide higher level constructs for low level software to talk to. Be that something like XHCI where the system talks to generic endpoint queues and a processor does all the low level packet building/scheduling or its something like the tiny integrated cores making decisions about which parts of a CPUs clock and power domains need to be dynamically enabled/disabled for a given perf/power profile and the OS talks to generic firmware interfaces to set policies. To even LBA disk layouts which abstract away all the details of flash channels, COW, wear leveling, NAND error correction, bit pattern sensing, page/block erase sizes, etc.

In the end, if someone wanted to actually work on this problem, the first step towards open hardware isn't really building a RISC-V system, its building competitive NIC's, keyboards, USB controllers, etc, etc, etc with open hardware designs. What we have today is like linux, everyone wants to work on the kernel, no one wants to maintain old crufty code in Make. So, in the end swapping an x86 for a RISC-V doesn't give you more open hardware if its still got its own management processors tied to the same closed hardware IP for literally everything else in the machine.

⬐ smaudet

"the first step towards open hardware isn't really building a RISC-V system, its building competitive NIC's, keyboards, USB controllers, etc, etc, etc with open hardware designs"

Actually it's building the software tools to emulate these, USB is a dense standard, you will have more luck emulating a working USB device first pass before building out the supporting infrastructure.

Once you can emulate/design your open chip computer, then you can start doing test runs/production runs. The market for such a thing will be limited to engineers and tech enthusiasts, at least until some hardware tech startup starts outcompeting the other players on the market.

⬐ CrLf

I agree that having an integrated OS control every random co-processor in a machine would be undesirable, and that hardware abstractions are a good thing.

But co-processors that can break OS' assumptions (regarding security, for example) sound like they should be under OS control. Not that this means under control of a single kernel but, at least, under control of some set of components that are developed together.

⬐ akira2501

> higher-privilege co-processors running code outside the main OS' control is becoming (or already is) the norm everywhere.

I don't think this fact is what you should focus on. That fact the blobs are binary, closed, proprietary, signed but not easily verifiable by the user, and not easy to disable is the problem.

The promise is they're going to "improve security for PCs." Yet, they're using techniques that we know to be invalid. There's no reason to tolerate this.

⬐ freedude

When you consider both at the same time it is cause to pause and speculate on how malware might take advantage of this built-in tool.

⬐ armchairhacker

They can have a physical switch or tool to disable it, or sell separate chips with/without IME.

Unfortunately there isn’t really incentive for Intel to do this, unless larger companies / governments refuse to run IME-enabled chips due to security concerns.

⬐ XorNot

Ironically government probably mostly doesn't care. The assumption of networked systems is that they're compromised if they have any internet connectivity. If it's really important then you air-gap it, and if it needs networking then you still isolate that network.

Governments do you use public internet VPN sometimes...via accredited boxes which handle the tunneling for them and are the one point of ingress (and have a commensurate price tag).

⬐ coryrc

Government != NSA

⬐ XorNot

Irrelevant. For anything classified aka serious, you start with these assumptions. If it's not classified, then it's basically about as confidential as a business process is.

Which is to say, all they want from their suppliers is "yeah, ME is safe. Also buy these tools to manage your fleet."

⬐ lazide

Governments and large companies are the ones who are explicitly requesting this functionality. End users don’t give a rats ass, it’s managed computed where the money is here.

That it can be used to back door the machine is the primary use case for the audience, as that is what lets them do a remote reinstall of Bob’s broken workstation somewhere, or any number of other legit use cases.

You should check out this other talk https://www.youtube.com/watch?v=36myc8wQhLo . It goes into a bunch of details about how many parts there are inside modern SoCs.

>As a research computer, Enzian is designed for computer systems software research and deliberately over-engineered. Enzian has a big server-class CPU closely coupled to a large FPGA, with ample main memory and network bandwidth on both sides."

Why potentially use Enzian hardware?

Well, watch a few minutes of the following talk at the following time offset by Professor Timothy Roscoe of the Systems Group of the Dept. of Computer Science at ETH Zurich -- and see if the argument he makes is not a persuasive one:

https://www.youtube.com/watch?v=36myc8wQhLo&t=828s

Related: https://people.inf.ethz.ch/troscoe/

Related: https://enzian.systems/faq/

>"Q. Is Enzian open-source?

A. We’re releasing all of the software we write for Enzian as open source.

It is our goal to also open-source as much of the FPGA doughnut as we can, including our implementation of ECI, which is needed to understand how to talk to the CPU in more interesting ways than just shared memory. We will own the board design, so it may be possible and/or a good idea to release that as well, but (as we have discovered) the hardware industry has very different ideas about what can and cannot be released."

Related: https://news.ycombinator.com/item?id=33145411

> I would really like to know if my x86 'linux PC', is actually running another 'hypervisor' OS that runs Linux - it seems like a recipe for security vulnerabilities.

There's not so much a "hypervisor" OS, but instead a congealed set of many different OSes, some realtime OSes, some possibly old Linux variants, some possibly closed source proprietary one-off OSes. I suggest taking a look at the talk Bryan mentioned: https://www.youtube.com/watch?v=36myc8wQhLo

Link to the other talk he references in this talk

https://youtu.be/36myc8wQhLo

And yes, this is (as ever) a call to arms on fixing a massive security problem we all have.

⬐ pclmulqdq

This is an amazing talk, and I think I have seen it on HN before. It lays out the problem of operating systems on modern computers well. I'm not sure that it offers the right solution by continuing to offer a system with the same set of abstraction layers as a solution to the problem of the "operating system" abstraction.

I think the folks at Oxide are probably closer to the right track by silo-busting the BIOS, OS, and hypervisor layers of a modern VM-hosting stack.

Edit: I should also add that this talk lays out a huge, gaping hole in the field of OS research, which might be its most important contribution.

⬐ imglorp

But it's not an OS problem; the OS being written that way is only the symptom because it can't touch the real hardware.

Cantrill and Roscoe both pointed at the SOC vendors: if there's a new problem to solve, they add more proprietary, undocumented, cores and enclaves with tightly held secret functions and OSes of their own, all of which are out of visibility of the OS. Some of them are even designed at odds with the user's interests, such as DRM goop.

This gets back to the war on general purpose computing as Cory Doctrow put it. The hardware is ceasing to work for the user's interest and is starting to work for everyone else in the stack against the user.

⬐ rapjr9

There is another area that computer scientists are not studying much and namely new architectures for computers. Is Von Neumann the best and only option? It seems so called computer scientists are not really studying computers at all, they are studying applications. The fundamental science of computers is the hardware architecture and the operating system, and computer science almost completely ignores fundamental basic research in both of them.

It is also a worry that the hidden code in the SoC's subsystems might be hidden for a reason, namely to give control of computers to someone other than the user and OS. That seems a perfect way to compromise all computers while giving an illusion of security. That's why the Intel Management System has been controversial (TPM's also), but in truth there are many processors on the SoC's that each have enormous security implications that the OS does not control. This has been an issue for decades. I remember people running code on the floppy drive MCU for Amiga's, so this has been known about for a long time. Cell phones are intentionally designed so the OS has no control over basic cellular radio functionality. There is a totally separate processor with its own non-public firmware controlling the radio. Whoever writes the code for these subsystems has enormous power with very little oversight.

⬐ anthk

CS in Europe requieres a big chunk of Math and EE...

⬐ tsimionescu

How different is this really from the fact that hardware designs themselves are proprietary? You can do computing without (what we commonly call) software, and much hardware does that - so even if 100% of the software running on your system were open source, that doesn't mean that your system is not compromised; you can very easily build a hardware key logger, and have it send the password over a cable (sending it over the internet through pure hardware would be quite hard, but modulating a signal shouldn't be). Note that even if the hardware design were open, you would still have a hell of a problem trying to check whether an IC actually matches the open design.

The only solution to these problems is actually regulation and trust. There is just no realistic way to actually check that your system is not doing some of the things you don't want it to do. Instead, you have to go to the source and make sure you can trust the vendors you buy from, and in order to do so, they themselves have to have hiring and shipment etc practices that allow this type of trust.

⬐ pclmulqdq

I have a background in digital circuits and computer architecture, and I completely disagree with you that these SoC components should be run by the traditional CPU cores. Most of these cores have strict latency guarantees or security boundaries that are much harder to achieve when you are trying to share silicon with the general-purpose code running on the machine, and since the cores are so small, it does not meaningfully save silicon to use them.

OSes are generally terrible at providing strict latency guarantees. If you will crash the CPU if you don't do [X] every 10 microseconds, you should not be telling the operating system to do [X]. This is the case of audio systems, radio systems, PCIe, and almost every other complicated I/O function. These could all be done with hardware state machines, but it is better (cheaper) to use a small dedicated CPU instead.

When I refer to security boundaries, a lot of people think that "security through obscurity" is the idea. It is not. It is more similar to closing all the ports on a server and applying "API security" ideas to hardware. It is a lot easier to secure a function that has a simple queue interface to the main cores than to secure a function that shares the main cores - Spectre and Meltdown have showed us that it might be impossible. Yes, these secure enclaves are used for DRM crap and other nonsense, so I can see why you might not like the existence of that core, but even if you erase the DRM software from that core and make it work for the user completely, you still will want the boundary.

Not to mention that every modern motherboard these days has a board management controller, which cannot be part of the CPU, and controls power and resets.

From a hardware perspective, these SoCs and motherboards really need to be heterogeneous systems. It's up to the system software to work with that. Heterogeneous SoCs really have nothing to do with taking power away from the user. The user can program all of these cores, but we live with abstractions that make it very hard.

⬐ jclulow

It's fine to have many smaller CPUs in the system, for all the purposes you state. The software that runs on them needs to be open, though, and something we can understand, fix, or even replace completely as needed. The operation of the components also needs to be documented so that it's possible to do that not just in principle but in practice.

We've added several small cores of our own to the systems that make up the Oxide rack, but critically we can control them with our own (open source) software stack. The large scale host CPUs where hypervisor workloads live can communicate with those smaller cores (service processor, root of trust, etc) in constrained ways across security and responsibility based boundaries.

⬐ pclmulqdq

It helps a lot that you are working with server-style computing, where you can realistically do this.

Things like audio and radio functions (eg bluetooth and wifi) have algorithms that are very proprietary and often patent-encumbered. The hardware architectures for radios are also similarly weird and proprietary. That kind of thing would result in a binary blob (at best) in a fully-open-source environment.

Hot take: I don't mind if Dolby or a wifi chipset vendor hides their software from me as long as it has very strict definitions for its role and a very narrow I/O interface.

> So as someone else commented, a mainframe isn't really a computer, it's a whole cluster of closely-coupled computers, many with dedicated functionality. Quite possibly all implemented with different architectures, instruction sets, programming languages, bit widths, everything.

Nearly all computers more powerful than a simple microcontroller look like this in 2022.

If you find this fact surprising, you'll probably want to take a look at this talk from USENIX ATC '21: https://www.youtube.com/watch?v=36myc8wQhLo

This would be a good place to start:

USENIX ATC '21/OSDI '21 Joint Keynote Address-It's Time for Operating Systems to Rediscover Hardware

https://www.youtube.com/watch?v=36myc8wQhLo

I'm guessing it's Tim Roscoe's keynote on how most fundamental questions about what the hardware is actually doing are invisible to traditional OS abstractions:

https://www.youtube.com/watch?v=36myc8wQhLo

Roscoe's talk is fairly long (the video is > 1h), but the basic thesis was taken up in a segment of Bryan Cantrill's 20 min OSFF talk:

https://www.youtube.com/watch?v=XbBzSSvT_P0

Both talks are very good; I recommend watching both, in either order.

⬐ 323

Yes, it was Tim Roscoe's one.

⬐ michaelwww

tldw - *nix OS's are using an outdated hardware model and new OS research and design is badly needed to build operating systems that are actually whole system solutions

⬐ rishflab

I watched this talk a while ago and it initially blew my mind and made me very upset with the state of OSDEV.

The speaker basically says OSDEV ignores the reality of modern computers. There are multiple binary blob operating systems with direct memory access running on a modern computer. OS researchers live in a linux bubble ignoring this. While this is true, I don't see how this is a technical problem for engineers to solve. This is a cultural/political/economic/moral problem.

Companies want to keep their stuff secret and governments want to be able to put backdoors into computers. How can an operating system software verify that the hardware is doing only what the operating system is telling it and nothing else if the operating system cannot verify the circuit layout of the computer? How can software verify the circuit layout? Afaik the only way to do this is look at the chip(s) through a microscope which is out of the scope of OSDEV.

I feel like this speaker has gotten me all riled up about nothing.

Is it this one?

https://www.youtube.com/watch?v=36myc8wQhLo

USENIX ATC '21/OSDI '21 Joint Keynote Address-It's Time for Operating Systems to Rediscover Hardware

Edit or this one (not a talk but a paper)?

https://www.usenix.org/system/files/osdi18-shan.pdf

LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation ... We propose a new OS model called the splitkernel to manage disaggregated systems. Splitkernel disseminates traditional OS functionalities into loosely-coupled mon- itors, each of which runs on and manages a hardware component

⬐ kodah

Similar enough! The one that I'm thinking of was the only actual non Linux talk (and really, OS development talk) at a OS Dev conference.

I'm curious, Lineage OS is an Android derivative, correct?

Isn't Android mostly isolated in its enclave?

See https://youtu.be/36myc8wQhLo

> Maybe we could do all the "smart" stuff in the OS and application code, and just attach commodity dumb flash chips to our computer.

Yeah, this is how things are supposed to be done and the fact it's not happening is a huge problem. Hardware makers isolate our operating systems in the exact same way operating systems isolate our processes. The operating system is not really in charge of anything, the hardware just gives it an illusory sanboxed machine to play around in, a machine that doesn't even reflect what hardware truly looks like. The real computers are all hidden and programmed by proprietery firmware.

https://youtu.be/36myc8wQhLo

⬐ colejohnson66

Apple’s SSDs are like that in some systems, and they’ve gotten flack for it.

⬐ aseipp

No, they look like any normal flash drive actually. Traditionally, for any hard drive you can buy at the store, the storage controller exists on the literal NVMe drive next to the flash chips, mounted on the PCB, and the controller handles all the "meaty stuff", as that's what the OS talks to. The reason for this is obvious: because you can just plug it into an arbitrary computer, and the controller abstracts the differences from the vendors, so any NVMe drive works anywhere. The key takeaway is the storage controller exists "between" the two.

Apple still has a flash storage controller that exists entirely separately from the host CPU, and the host software stack, just like all existing flash drives do today. The difference? The controller just doesn't exist on the literal, physical drive next to the flash chips. Because it doesn't exist; they just solder flash directly on the board without a mount like an M.2 drive. Again, no variability here, so it can all be "hard coded." And the storage controller instead exists by the CPU in the "T2 security chip", which also handles things like in-line encryption on the path from the host to the flash (which is instead normally handled by host software, before being put on the bus). It also does some other stuff.

So it's not a matter of "architecture", really. The architecture of all T2 Macs which feature this design is very close, at a high level, to any existing flash drive. It's just that Apple is able to put the NVMe controller in a different spot, and their "NVMe controller" actually does more than that; it doesn't have to be located on a separate PCB next to the flash chips at all because it's not a general 3rd party drive. It just has to exist "on the path" between the flash chips and the host CPU.

⬐ aseipp

Flash storage is incredibly complex in the extreme at the low level. The very fact we're talking about microcontroller flash as if it's even the same ballpark as NVMe SSDs in terms of complexity or storage management says a lot on its own about how much people here understand the subject (including me.)

I haven't done research on flash design in almost a decade back when I worked on backup software, and my conclusions back then were basically that: you're just better off buying a reliable drive that can meet your your own reliability/performance characteristics, and making tweaks to your application to match the underlying drive operational behavior (coalesce writes, append as much as you can, take care with multithreading vs HDDs/SSDs, et cetera), and testing the hell out of that with a blessed software stack. So we also did extensive tests on what host filesystems, kernel versions, etc seemed "valid" or "good". It wasn't easy.

The amount of complexity to manage error correction and wear leveling on these devices alone, including auxiliary constraints, probably rivals the entire Linux I/O stack. And it's all incredibly vendor specific in the extreme. An auxiliary case e.g. the case of the OP, of handling power loss and flushing correctly, is vastly easier when you only consider some controller firmware and some capacitors on the drive, versus the whole OS being guaranteed to handle any given state the drive might be in, with adequate backup power, at time of failure, for any vendor and any device class. You'll inevitably conclude the drive is the better place to do this job precisely because it eliminates a massive amount of variables like this.

"Oh, but what about error correction and all that? Wouldn't that be better handled by the OS?" I don't know. What do you think "error correction" means for a flash drive? Every PHY on your computer for almost every moderately high-speed interface has a built in error correction layer to account for introduced channel noise, in theory no different than "error correction" on SSDs in the large, but nobody here is like, "damn, I need every number on the USB PHY controller on my mobo so that I can handle the error correction myself in the host software", because that would be insane for most of the same reasons and nearly impossible to handle for every class of device. Many "Errors" are transients that are expected in normal operation, actually, aside from the extra fact you couldn't do ECC on the host CPU for most high speed interfaces. Good luck doing ECC across 8x NVMe drives when that has to go over the bus to the CPU to get anything done...

You think you want this job. You do not want this job. And we all believe we could handle this job because all the complexity is hidden well enough and oiled by enough blood, sweat, and tears, to meet most reasonable use cases.

I can recommend the related talk "It's Time for Operating Systems to Rediscover Hardware". [1]

It explores how modern systems are a set of cooperating devices (each with their own OS) while our main operating systems still pretend to be fully in charge.

[1] https://www.youtube.com/watch?v=36myc8wQhLo

⬐ ksec

Our modern system has sort of achieved what microkernel was set out to do. Our Storage and Network each has their own OS.

⬐ rhizome

And if the entire purpose of computer programming is to control and/or reduce complexity, I should think the discipline would be embarrassed with the direction in which the industries have been going the past several years. AWS alone should serve as an example.

⬐ notriddle

> And if the entire purpose of computer programming is to control and/or reduce complexity

I honestly don’t know where you got that idea from. I always thought the whole point of computer programming was to solve problems. If it makes things more complex as a result, then so be it. Just as long as it creates fewer, less severe problems than it solves.

⬐ smaudet

More complex systems are liable to create more complex problems...

I don't think you can get away from this - yes, can solve a problem, but if you model problems as entropy, increasing complexity increases entropy.

It's like the messy room problem - you can clean your room (arguably high entropy state), but unless you are exceedingly careful doing so increases entropy. You merely move whatever mess to the garbage bin, expend extra heat, increase your consumption in your diet, possibly break your ankle, stress your muscles...

Arguably cleaning your room is important, but decreasing entropy? That's not a problem that's solvable, not in this universe.

⬐ danuker

> but unless you are exceedingly careful doing so increases entropy

In an isolated system, entropy can only increase. Moving at all heats up the air. Even if you are exceedingly careful, you increase entropy when doing any useful work.

⬐ rhizome

What are some examples of complex solutions to simple problems? That is, where a solution doesn't result in a reduction of complexity? I can't find any.

And this is where the increased complexity is necessary for a solution, not just Perl Anti-golf or FactoryFactory Java jokes.

⬐ rbanffy

An interesting approach would be to standardize a way to program the controllers in flash disks, maybe something similar to OpenFirmware. Mainframes farm out all sort of IO to secondary processors and it was relatively common to overwrite the firmware in Commodore 1541 drives, replacing the basic IO routines with faster ones (or with copy protection shenanigans). I'm not sure anyone ever did that, but it should be possible to process data stored in files without tying up the host computer.

⬐ StillBored

http://la.causeuse.org/hauke/macbsd/symbios_53cXXX_doc/lsilo...

But, its still an abstraction, and would have to remain that way unless your willing to segment it into a bunch of individual product categories, since the functionality of these controllers grows with the target market. AKA the controller on a emmc isn't anywhere similar to the controller on a flash array. So like GP-GPU programming, its not going to be a single piece of code because its going to have to be tuned to each controller, for perf as well as power reasons never mind functionality differences (aka it would be hard to do IP/network based replication if the target doesn't have a network interface).

There isn't anything particularly wrong with the current HW abstraction points.

This "cheating" by failing to implement the spec as expected isn't a problem that will be solved by moving the abstraction somewhere else, someone will just buffer write page and then fail to provide non volatile ram after claiming its non volatile/whatever.

And its entirely possible to build "open" disk controllers, but its not as sexy as creating a new processor architectures. Meaning RISC-V has the same problems, if you want to talk to industry standard devices (aka the NVMe drive you plug into the RISC-V machine is still running closed source firmware, on a bunch of undocumented hardware).

But take: https://opencores.org/projects?expanded=Communication%20cont... for example...

⬐ rbanffy

> the controller on a emmc isn't anywhere similar to the controller on a flash array

That’s why I suggested something similar to OpenFirmware. With that in place, you could send a piece of Forth code and the controller would run it without involving the CPU or touching any bus other than the internal bus in the storage device.

⬐ StillBored

Adding a JIT to the mix only makes the problem worse, its a question of resources, your not going to fit all that code into a tiny SD micocontroller which has a very limited CPU/ram footprint even in comparison to sata SSDs. The resource availability takes another huge jump when you move to a full blown "array", which not only has all this additional disk mgmt functionality, but its going to have network mgmt functionality, etc. Some of these arrays have full blown xeons/etc in them.

Plus, disks are at least partially sold on their performance profile, and your going create another problem with a cross platform IR vs coding it in C/etc and using a heavyweight optimizing compiler targeting the microcontroller in question directly.

You also have to remember these are effectively deeply embedded systems in many cases, which are expected to be available before the OS even starts. Sometimes that includes operating over a network of some form (NVMe-OF). So it doesn't even make sense when that network device is shared/distributed.

⬐ StillBored

Fundamentally the job of the OS is resource sharing and scheduling. All the low level device management is just a side show.

Hence why SSD's use a block layer (or in the case of NVMe key/value, hello 1964/CKD) abstraction above whatever pile of physical flash, caches, non-volatile caps/batts, etc. That abstraction holds from the lowliest SD card, to huge NVMe-OF/FC/etc smart arrays which are thin provisioning, deduplicating, replicating, snapshoting, etc. You wouldn't want this running on the main cores for performance and power efficiency reasons. Modern m.2/SATA SSD's have a handful of CPUs managing all this complexity, along with background scrubbing, error correction, etc so you would be talking fully heterogeneous OS kernels knowledgeable about multiple architectures, etc.

Basically it would be insanity.

SSDs took a couple orders of magnitude off the time values of spinning rust/arrays, but many of the optimization points of spinning rust still apply. Pack your buffers and submit large contiguous read/write accesses, queue a lot of commands in parallel, etc.

So, the fundamental abstraction still holds true.

And this is true for most other parts of the computer as well. Just talking to a keyboard involves multiple microcontrollers, scheduling the USB bus, packet switching, and serializing/deserializing the USB packets, etc. This is also why every modern CPU has a mgmt CPU that bootstraps and manages it power/voltage/clock/thermals.

So, hardware abstractions are just as useful as software abstractions like huge process address spaces, file IO, etc.

Turns out our operating systems aren't operating systems at all, they're just user applications sandboxed far far away from the real hardware. It's frightening to realize just how many extra processors exist on modern computers and how exploitable all this extra code could be.

https://youtu.be/36myc8wQhLo

This reminded me of a recent talk: USENIX ATC '21/OSDI '21 Joint Keynote Address-It's Time for Operating Systems to Rediscover Hardware: https://www.youtube.com/watch?v=36myc8wQhLo

At 9:00 the speaker lays out some pretty conventional criteria for an operating system (multiplex hardware resources, abstract the hardware platform, protect software principals from each other), and points out that these things are increasingly outside the scope of what people call "the OS". https://imgur.com/dODDwnQ

⬐ matheusmoreira

This talk is fantastic and terrifying. I was aware that there were other processors running firmwares but I had no idea it was this bad. I really don't like knowing that I'm not really in control of the machine.

I suppose the best we can do now is to somehow load free software onto these hidden chips and completely replace the proprietary firmware. That won't be possible if they start locking the chips down so they only accept signed code...

First of all, watch this, and learn that there's a whole stack of layers below what Linux can even touch these days.

https://www.youtube.com/watch?v=36myc8wQhLo

For a theoretical understanding, with a much simpler model, I suggest the Nand2Tetris course.

⬐ rmbyrro

Great, thanks!

⬐ rmbyrro

This nand2tetris course seems really amazing, thanks a lot for pointing it out!

By watching the intro video, I was really excited to start it right away!

Very interesting. This reminds me a ton of L4, with its message passing style. I'm curious if it was inspired by L4.

It's a great talk, and my only disappointment was that I was hoping to hear about what comes after. After watching the OS talk that Cantrill references [0], I really want to know the answer to "what does an OS that runs across a bunch of heterogeneous chips look like?" Having Hubris be just a single-node OS was a bit of a let down, so I will be staying tuned for the sequels.

[0] https://www.youtube.com/watch?v=36myc8wQhLo

EDIT: Went to go read the docs and: "The operating system that originally made this point was L4, and Hubris’s IPC mechanism is directly inspired by L4’s"

⬐ bcantrill

Yes, definitely L3/L4 (and QNX) inspired! In terms of the Roscoe talk: I think it's a great talk because he talks about the problems, but I don't particular agree with the proposed solution. ;) In particular, I don't think it makes sense to have single operating systems spanning these wildly disparate, heterogeneous cores; to me, it makes much more sense for each to have its own (tiny) operating system -- e.g., Hubris.

⬐ lostdog

Thanks! I guess I'll check back in 5 years and see who was right.

Related: The keynote presentation from OSDI (Operating Systems Design and and Implementation) online conference: “It’s Time for Operations Systems to Rediscover Hardware”:

https://youtu.be/36myc8wQhLo

The presenter says that, of the 103 papers about operating systems published by OSDI in 2020 and 2021, only three were not about Linux!

⬐ throw0101a

Covered a few months ago:

* https://news.ycombinator.com/item?id=28374523

⬐ IshKebab

I just watched that too. Must have read the same comment. Anyway I agree with the first YouTube comment. It's only partially Linux's fault. SoC vendors would never want to give up control of the software that runs on the SoC to just anyone, so there's not really anything Linux can do about it even if it wanted to.

"Build your own SoC" is not really a viable solution for most people.

See also https://www.youtube.com/watch?v=36myc8wQhLo

I'm not sure what Oxide is doing, but creating an OS to replace the firmware on all kinds of 3rd party devices sounds, well, quite quixotic. I'd guess it's more like a common OS for the firmware of their own hardware (rack controllers and whatnot).

⬐ hinkley

> firmware on all kinds of 3rd party devices sounds, well, quite quixotic

You could say the same about device drivers in Linux. It was a very long process that required many, many hands. It took a long time even to cover all of the common devices let alone the more obscure ones.

> the resulting code is always upstreamed and open source

Are you saying there is 0 binary blobs involved in running a modern Thinkpad? I find that hard to believe (although i would love it). I'm guessing there's a few blobs in the kernel tree itself, and even more firmware blobs the kernel doesn't even know about.

On the topic of how Linux deals very little with actual hardware on modern machines, i really enjoyed this talk called "It's time for operating systems to rediscover hardware" [0]

[0] https://www.youtube.com/watch?v=36myc8wQhLo

⬐ kiwijamo

I think it is quite possible there is few if any binary blobs. I have a Lenovo X1 and everything pretty much works out of the box on base Arch Linux (and Debian before that). I think it also helps that my X1 has Intel graphics, Intel Wi-Fi, etc which has very good support which I know is not a given for others (e.g. Broadcom Wi-Fi, Nvidia graphics, et al). It is easily the best Linux experience I've ever had.

⬐ southerntofu

> I have a Lenovo X1 and everything pretty much works out of the box on base Arch Linux

I'd be curious to know if it actually works well with linux-libre (Linux without the binary blobs). It's apparently not maintained as a distro package but is available on the AUR.

Moreover, I'm still curious if all hardware functions without its own binary blobs. For example, is the networking firmware really free and replaceable, or is the proprietary firmware interoperable with a FLOSS driver? Likewise, is the entire system libreboot-able?

Sorry for nitpicking, i'm just looking for precise answer to a topic that's not widely questioned/debated to my knowledge.

⬐ maccolgan

If you wanted to use Linux-libre, wouldn't you just use Parabola?

⬐ rincebrain

I believe none of the major wireless NIC vendors these days ship cards that will do anything useful without a nonfree firmware blob, for example.

⬐ formerly_proven

GP is talking about drivers, you seem to be talking about firmware.

⬐ southerntofu

Correct, i'm slightly abusing semantics. I'm mixing them both under the category of "software that should be under user control", and interested about the FLOSS support for both.

⬐ jwildeboer

When firmware was stored in ROM/EEPROM, most FOSS folks had no problem with it. It was considered part of the hardware, so not that relevant. But when these were moved out of non-volatile memory (mostly for cost reasons), that changed the picture for some. While the result, after booting, is effectively the same. So no, I am not on the side that sees firmware blobs as something that MUST be made open. It would be good if it were, definitely. But it’s not a deal breaker for me, as long as the blobs are freely redistributable, for example via fwupd. Again, that’s my personal opinion.

⬐ southerntofu

> While the result, after booting, is effectively the same.

I'm not sure it's exactly the same. First, because having embedded firmware formed an incentive for hardware manufacturers to test stuff and fix bugs before hitting the market. Second, because who gets to push updates to our machine has serious political/security implications. We have reached a situation where the OS we choose to run has less and less control over our computing, and i find that worrying.

> it’s not a deal breaker for me, as long as the blobs are freely redistributable

Thanks for your explanation. I can completely respect this position, although i personally disagree. If you ever get the chance to bring up the issue (libre firmware/drivers and librebooting), please spare a minute to raise our disenchantment and mention the possibility to work with other distros (such as Debian, who also has ties to Lenovo) hand-in-hand with hardware manufacturers to improve the situation for everyone.

I don't exactly have any hope for it, but having Lenovo publish its entire hardware specs and playing nice with maintainers to provide libre firmware would definitely inspire confidence in their hardware. For the moment, it seems only Librem and Pine64 (and a few others) are manufacturers that can be approached on that topic. But like the original author (mmu_man) suggested, software freedom should be for everyone, not just people investing in specific hardware... and i'm pretty sure he would be thrilled to work on Haiku support for his Lenovo hardware given proper documentation ;)

⬐ jwildeboer

No. I specifically said drivers, not firmware blobs. As long as these blobs are freely redistributable, I personally have no problems with them. I understand some people do and that is understandable, but I don’t subscribe to that. This started at a time where non-volatile memory for firmware became a cost factor and companies decided to save a few bucks on the BoM and upload the blob as part of the initialisation/boot process. Which is fine with me.

I liked your talk, and the talk you referenced by Timothy Roscoe [0]. My understanding of your talks is that the issue we seem to be running into with system architecture design is that OS and userspace developers are clinging desperately to a dead model of the system as a homogeneous array of cores attached to large bank of unified memory. This falsehood is so deep that systems basically lie to us about 95% of their internal structure just so that we can continue playing out our little fantasy in obliviousness.

The biggest component of that lie is the unified memory assumption. To be fair to OS & app developers, writing for NUMA is hard, there are enough invariants that must be continuously upheld that it's impossible to just expect authors to keep everything in their in their head at all times. And using a language like C, described as "portable assembler", does not help at all.

Enter Rust, where the novel ownership system and strong type system allows encapsulating special knowledge of the system and packaging it up into contained bundle that can't be misused. Now you can compose multiple of these un-misuse-able (it's a word now) lego bricks reliably because the compiler enforces these invariants, freeing the author from the burden of reflecting on their design from N! perspectives every time they add a line. (Well, they still reflect on it, but they are privileged to reflect on it right after they make a mistake when the compiler complains instead of in an hours-long debugging session using a debugger or, worse, a specialized hardware debugging device.)

---

Your talk focuses on no_std, which is really a foundational necessity of such a new OS (the term "Operating System" feels too small now, maybe "Operating Environment"/OE? idk). I think the next important component is a path out of UMA-land, which I don't think is fully solved in Rust at the moment (that's not a knock, it's not solved anywhere else either). There's an ongoing Internals thread that started as a discussion about usize vs size_t across different architectures and now has dug down to questions such as "what even is a pointer?", "how are pointers represented as data?", and "how should you convert a bucket of bytes into a usable pointer?" [1] -- these are exactly the type of questions that Timothy's talk reveals as important (and has hitherto remained unanswered) and that you hinted at.

During the discussion, Ralf Jung presented an interface that would enable constructing a pointer from an integer by also separately identifying its provenance; I feel like this is a good direction.

    /// Returns a pointer pointing to `addr`, with the provenance
    /// taken from `provenance`.
    fn ptr_from_int<T>(addr: usize, provenance: *const T) -> *const T

---

What do you think of my summary? What do you think of the ongoing discussion on this Internals thread about the right way to construe Rust's memory model? What do you think of think of this idea presented by Ralf?

[0]: https://www.youtube.com/watch?v=36myc8wQhLo

[1]: https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-...

[2]: https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-...

⬐ infogulch

I should start a blog instead of using HN comments as an outlet.

⬐ metagame

Year after year some of the most interesting long-form material arises from Usenix and FOSDEM. Does anyone have a list of conferences similar in quality? Ideally related to computing, but really any conference of experts talking about interesting ideas would be nice to know about. Some people might mention Strange Loop, but I think the quality is a lot lower.

⬐ pjmlp

NDC is usually high quality.

Linaro Conference for embedded stuff.

Lambda Ultimate for anything FP related.

LLVM Meetings, GCC cauldron and JVM Language Summit if you are into language implementations.

And if you are into gaming GDC, although without Vault access, there is only a partial view.

⬐ metagame

Thank you very much!

Reminds me of Your computer is already a distributed system. Why isn’t your OS? from HotOS 2009:

https://www.usenix.org/legacy/events/hotos09/tech/full_paper...

We argue that a new OS for a multicore machine should be designed ground-up as a distributed system, using concepts from that field. Modern hardware resembles a networked system even more than past large multiprocessors: in addition to familiar latency effects, it exhibits node heterogeneity and dynamic membership changes

And now that I look at the author list, I see Roscoe, who gives the 2021 keynote that Cantrill recommends:

https://www.youtube.com/watch?v=36myc8wQhLo

⬐ thelazydogsback

QNX? - been around for a while - the first OS to run in protected 386 mode FWIR. (And I remember it booting from a single floppy :))

I know that I recommended it in the talk, but I highly recommend Timothy Roscoe's OSDI keynote[0] -- and may also be worth catching the Twitter Space we did a few weeks ago discussing it.[1]

[0] https://www.youtube.com/watch?v=36myc8wQhLo

[1] https://github.com/oxidecomputer/twitter-spaces/blob/master/...

⬐ zja

I discovered Oxide's youtube channel a couple weeks ago, and I've been really enjoying listening to your twitter space discussions. Thanks for all the interesting content!

⬐ sam_bristow

Oooh, thanks for pointing that out. I really enjoyed their "On the Metal" podcast while they were running it.

⬐ aidenn0

Given that you continuously recommend Roscoe's keynote, and you are working on a message-passing microkernel; will that microkernel support message passing between heterogenous cores with heterogenous physical address spaces?

⬐ bcantrill

I'm not sure what you mean by "continuously", but the answer to your question is "no, it doesn't."

⬐ CalChris

I liked your talk but I didn't get the connection with Wright's Law. You did a good presentation of WL but I just didn't get its connection with low latency and future hardware software co-design.

⬐ zozbot234

I guess the connection is just that Rust is an up-and-coming language, so developing with it is going to get gradually easier and cheaper as the surrounding ecosystem grows to a larger scale.

⬐ aidenn0

- Low latency is desirable

- Transistors are getting cheaper

- Therefore it is cheap to put computing closer to I/O (which reduces latency)

- That computing will not have the sorts of things a general-purpose CPU has (maybe no MMU, limited RAM, perhaps it's a harvard architecture)

⬐ hinkley

We're swinging from The Network is the Computer to The Computer is a Network

⬐ convolvatron

a channel controller! last time i used one of those it was a 68k hanging off a convex

⬐ dralley

Hey Bryan, just curious, what are your thoughts on the tradeoffs that Zig is making compared to Rust?

⬐ RobLach

That keynote is great. It feels like looking up and seeing the sun from the floor of a deep hole you've been too focused on digging.

⬐ sremani

Roasting a conference in the keynote is whole another level of charisma. This talk is impressive even for non-OS people like me.

I feel like this generally applies to all software developers. Software and its systems have largely evolved through accretion and that creates a strong network effect and eventually, a taller application stack. We're continually making everything more complicated because it's just easier to use other people work, especially when the barrier to entry for that work is low, i.e: Web/JS.

As a slight segue, I recently came across Timothy Roscoe's Usenix talk[1] on OS development on HN and I'm starting to think that a complete rebuild of modern computing might occur when the limits of the old OS architectures become too burdensome, at which point there could be an opportunity to "fix" the application stack and try something simpler. I sincerely hope the OS's of the future do not look like Linux or even attempt POSIX compliance.

[1] https://www.youtube.com/watch?v=36myc8wQhLo