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
love love this method of resolving conflicts by giving users tools to override or work around. sign of Giving A Shit About Users:
In any case, files with unresolved conflicts are marked so normal attempts to access them fail, although that control may be overridden.
could be annoying but seems like an effective compromise
A trivial tool is provided by which the user may
rename each version of the conflicted file and make
each one a normal file again.
LOVE keeping absolutely every version like this. it codifies the situation where "i can't fuck with this rn but i can't risk losing anything" which i SO relate to
Then the standard set of application programs can be used to compare and merge the files.
ediff bae !!
ooooh so i totally think they made the wrong choice here
The system strives to insulate the users from reconfigurations, providing continuing operation with only negligible delay.
yeah ok but that's just an SLA. it's not "insulating users" that's just doing your job
Requiring user programs to deal with reconfiguration would shift the network costs from the operating system to the applications programs.
(1) HUGE leap from "users" to "user programs" lmao
(2) is it "user" or "application" programs? if the users own files they might care whether they're being rehomed lol
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
