Earlier quoted context omitted.
Had Bell Labs been allowed to sell it in first place and that would have been exactly its outcome.
missing the sarcasm?
I think you are.
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
201–210 of 291 posts
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#202Earlier quoted context omitted.
There were always objections. "Unix went from being the worst operating system available, to being the best operating system available, without getting appreciably better." https://news.ycombinator.com/item?id=19416485 Which isn't to say that those POV were necessarily correct, just that it isn't all hindsight.
To be fair, there are always objections to any working piece of technology. It's not helpful to claim "it was never good design". It was a working design that drove technology to the point it is now, and in that sense it was hugely successful. What kind of perfect and pure tech do some people want, anyway? Pick anything, whatever they like -- say, Plan 9 or OS/2 or whatever -- and I can bet you in a parallel universe…
I certainly don't disagree that it was successful, and (coming into technology when I did) I've always personally liked it. I just found the writings around what came before interesting.
> I can bet you in a parallel universe where that tech won, someone on para-HN will claim that it sucked and it was never a good design and if only Unix had won.
I'd take the same side of that bet as you :-P
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#203Earlier quoted context omitted.
So would it be correct to say that functionally, it’s similar to DMA, but the API is different because “channels” expose a consistent interface while DMA doesn’t?
Channels only expose a consistent interface as long as there is no other mainframe other than an IBM one, or compatible. Once you have two, and you want portable applications, using channel I/O instructions directly inline goes out the window; you need an API.
One could say this about any library or OS feature. Berkeley Sockets, for example.
Porting code is easier when there are portable APIs. But that doesn't diminish from the quality of the abstraction.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#204Earlier quoted context omitted.
Amen to that. Unix was never a good design, and now is severely out of date. We can no longer afford to hack around it.
What a ridiculous statement. Yeah if it was possible to just jump to the best solution each time then we'd benefit massively, but that's not how any science works. The new awesome thing is always built on the back of what was done before. Electric cars have been around since the inception of the internal combustion engine but we didn't have electrical supplies with the energy density of gasoline to make electric cars…
The other OSes from Unix's era were already as good or better (or at very least there was a diversity of ideas). Then the regulation that prevent AT&T from being sold like the others causes Unix to win prematurely.
Maybe that's how Ford beat the earlier luxury cars in raw profit, but that's not how the ICE beat electric cars.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#205Earlier quoted context omitted.
Are you aware of any efforts by existing databaes or entirely new databases built with this realization in mind?
NoSQL is based on this realization. Rather than optimize for IO with normalization, denormalize and pipe data more or less directly from storage to clients, simplifying the compute and consistency model to make distributed data easier.
I see your analogy, but (NoSQL and its clients) are conceptually much higher up on the stack.
Interestingly, the paper does say:
[eBPF] enables applications to perform up to L7 protocol (e.g., HTTP or Memcached) processing.
Furthermore, some programmable NICs are able to execute eBPF programs directly on the NIC hardware.Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#206Earlier quoted context omitted.
It was re-written on an unsafe language that completely disregarded what has happened outside Bell Labs since 1961, at Burroughs, IBM, MIT, Xerox and other research cathedrals. It only took off thanks to Bell Labs being forbidden to sell it, so it got offered for a symbolic price, alongside source code to major universities, which then decided to build on top, instead of paying OS street prices. Had UNIX been sold in…
Thank you for being a breadth of wisdom in the UNIX-worshiping wilderness. You can always get mindshare being first massively underpriced thing to market.
Only that this doesn't even touch on design, or what parts could have been done better.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#207Earlier quoted context omitted.
Of course, you need some agent that can communicate with the hard disk and that knows how to manage memory. Maybe its one driver, maybe its several, but these can also just be objects. Live objects, I mean. Not just blobs of data, but actors that have behaviors and are always "running." You don't even need the concept of files or filesystems. And if you do, better left to a higher level
Isn't the whole point of persistent storage like hard drives to deal with the fact that computers shut off sometimes, and nothing can be "always 'running'"? Something below the object level (possibly part of the object system, possibly a layer below that) needs to read from disk and bootstrap all those agents/live objects/actors into existence.
Well of course they aren't running when the computer is off. And yeah, you'd need something to bootstrap the system the same way you need a bootloader
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#208Earlier quoted context omitted.
What if we surpass file systems completely? Imagine every process having its own "non-volatile" memory area, where all persistent state is kept between restarts, with a clean OS interface to share that state to other processes? Terminals and process hierarchy are a complete no-go in a fresh design. Every entity in the system can be identified through unique IDs which can be handed down to other processes based on dif…
Currently my mother has a Pictures folder which contains her pictures, where she can open them with the default photo viewer, with an editing program, and where she can trivially add files or make backups with the Windows Explorer. Any alternative interface I can imagine that offers the same flexibilty of using the same picture in multiple programs just ends up mimicking files. There's room to replace traditional fol…
Well, in a traditional file system, the basic unit of data is a specific notion of a file which is an untyped blob of octets with limited metadata like size, filename, some timestamps, and some very coarse access controls.
You could quibble about whether this counts as "replacing the notion of a file", but I could certainly imagine it might be useful to have a system that talks directly to disk whose basic unit of data has much more useful metadata, such as a canonicalized MIME type, much more granular access controls, much more granular access and edit history, etc. Has your mother ever downloaded a file with the wrong extension and been unable to open it? I know I have.
Similarly, the abstracted "everything is a file" notion of a file without random access, which includes sockets and named pipes and stuff, is an untyped, unsized stream of octets. Message-oriented protocols like WebSockets and HTTP can and in fact are built on top of that, of course, but it could have been the reverse: instead of a stream of octets, TCP could have been a stream of arbitrarily-large but finitely sized messages. There almost certainly would have been advantages to such an approach, and applications that didn't want the message framing and just wanted a stream of octets could have easily ignored it.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#209Mainframe designers had this problem under control by 1970. Mainframes had, and have, "channels". A channel is part of the processor architecture. It takes commands, sends them to a peripheral, and manages the data transfer in both directions. Channels have some privileged functions through which the OS tells them where the data is supposed to go in memory. The architecture of channels is well defined, and peripheral…
The PS/2 was not successful not because of technicalities but because IBM did not want it to be cloned. Third parties decided what the PC should be (mostly continue to be, there was less differences between cloners and the original PC than with the PS/2), and IBM followed. In insight, the PS/2 could not win in this context, because IBM did not matter anymore very early on for the history of the PC, regardless of peri…
> basically you need IOMMU and once you have it, well what else do you need?
Not sure where this exploit[1] stands now, but you may need a clean slate implementation that doesn't have to boot up with IOMMU disabled for legacy reasons.
[1] https://journal-bcs.springeropen.com/articles/10.1186/s13173...
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#210Some types of IO have been faster than CPU for quite a long time. For instance, a cache miss is typically about 200x slower than accessing data already in the register file. What this means in practical terms is if you miss cache all the time (aren't garbage collected languages wonderful?) your 4GHz CPU turns into a 20MHz pumpkin (or thereabouts), and a fully sequential read from a modern _spinning drive_ (150+ MB/sec) could produce more throughput. A consumer-grade 10GbE NIC will leave it completely in the dust, as will USB3.