The UNIX system has been in wide use for over 20 years, and has helped to define many areas of computing.
Post
Replies:
15
Boosts:
14
wish they explained the significance of a virtual circuit!!! that's another pouzin neologism which was immediately twisted out of recognition
Network information is kept internally in both a high-level status table and a collection of virtual circuits,
wish this was explained
The virtual circuits deliver messages from site A to site
B (the virtual circuits connect sites, not processes} in the
order they are sent. If a message is lost, the circuit is
closed. The mechanism defends the local site from the
slow operation of a foreign site.
this is so curious for so many reasons! maintaining message ordering is interesting too but i wonder if it could be muxed?
i'm rly curious about this site-to-site communication that wraps individual messages from users bc that is how a ddos-resistant anonymity catenet that hides traffic might work
oh i'm so sad they just drop handles to remote resources when the link breaks! this is where a dependency graph could make sense since progress through it can be halted and resumed!
i do like the idea of recovery manager though. one thing we didn't attempt to do in the pants task graph was any form of retry, or any codification of special conditions around a subgraph. why? because someone else didn't like it. sigh!
i do kind of like the idea of a named sync context being the locus of a recovery condition, so that if any tasks syncing to the context fail, the context can free its pages. this would absolutely propagate sideways (tasks declaring two contexts would blow up if one does) and upwards (if the sync context can't recover, goes up to its parent context)
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
