The UNIX system has been in wide use for over 20 years, and has helped to define many areas of computing.
hmmmm should a sync context also then be the locus of declaring tasks and their dependencies? that answers another question we never addressed in pants i.e. making the loading of rules into one of the operations of the system as opposed to loading everything in advance
i'm so upset how this wonderful paper is concluding ugh!!! they keep saying "transparent" to mean "opaque" and then they say their biggest problem was not being able to pretend a networked file was local hard enough. i don't believe that for a second. it's not "a failure of transparency" if viewing a remote file is spotty, you're not allowing the user to explicitly relocate that file!!!
We found that the primary motivation for remote execution was load balancing.
completely uninterested in your framing of your users' "motivation" (why are users not even named???) and this is also a ridiculous thing to state without whatsoever describing their experience of local load
anyway that shit was wild
seeing "remote execution" in a 1981 paper and knowing UCLA did it better than us in most ways was both exciting and scary
the google remote execution API is such fucking shit lmao
back to the BSD hagiography
Because 4.2BSD included many new facilities, it suffered a loss of performance compared to 4.1BSD, partly because of the introduction of symbolic links.
blaming two separate things for performance degradation lmao
Some pernicious bugs had been introduced, particularly in the TCP protocol implementation.
TCP is a fucking joke. the pernicious bug is TCP
Others, such as TCP/IP subnet and routing support, had not been specified soon enough by outside parties for them to be incorporated in the 4.2BSD release.
"outside parties" ??? this is still darpaslop and cerf does not let others specify his protocols for him
Commercial systems usually maintain backward compatibility for many releases, so as not to make existing applications obsolete.
complete falsehood. that's what we did at pants and what we do for spack because we are government workers and we achieve guarantees for our users
Maintaining compatibility is increasingly difficult, however,
skill issue, should have used spack
so most research systems maintain little or no backward compatibility.
debatable. very funny how rapidly this guy jumps between commerce and research lol
The implementation changes between 4.2BSD and 4.3BSD generally were not visible to users, but they were numerous.
i would think performance and bug fixes are user-visible, but whatever
For example, the developers made changes to improve support for multiple network-protocol families, such as XEROX NS, in addition to TCP/IP.
if i ever find myself wanting to feel bad i absolutely want to read cerf's code because i wanna know if he gives off vibes that would ring a bell
The most critical shortcoming of 4.3BSD was the lack of support for multiple filesystems.
oh bet
As is true of the networking protocols, there is no single filesystem that provides enough speed and functionality for all situations.
yeah cause you don't specialize per situation and provide a monolithic interface
It is frequently necessary to support several different filesystem protocols, just as it is necessary to run several different network protocols.
ridiculous comparison because you literally can't choose the filesystem per-file???? that's literally why i'm doing any of this????
The design of the networking facilities for 4.2BSD took a different approach, based on the socket interface and a flexible multilayer network architecture.
literally microkernels but only for network sockets
This design allows a single system to support multiple sets of networking protocols with stream, datagram, and other types of access.
how do you write file data? oh read()/write() that's it
Protocol modules may deal with multiplexing of data from different connections onto a single transport medium, as
well as with demultiplexing of data for different protocols and connections received from each network device.
literally file i/o when???
