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
the LOCUS paper likes it but i don't rly care about version history in this case. i'm glad i remembered version control systems are cool though because that's another way i can defeat linus
OOOH WOW OMG
The LOCUS recovery and merge philosophy is
hierarchically organized. The basic system is responsible for detecting all conflicts.
this is kind of why i like the idea of making data scoped by default, because i don't think most files need to know about each other or consider a generic conflict system. all of these seem to be solutions to a problem of "how can we ensure global coherence" when a computer generally isn't about global coherence? not the way i use it
For those data types that it manages, including internal system data as well as file system directories, automatic merge is done by the system.
i do absolutely fuck with having semantic understanding of the structures the filesystem/vcs manages
If the system is not responsible for a given file type, it reflects the problem up to a higher level; to a recovery/merge manager if one exists for the given file type.
a recovery manager, maybe? but knowledge of merging seems like an ahierarchical property. i still like the idea of "merge manager"
To develop a merge procedure for any data type,
including directories, it is necessary to evaluate the
operations which can be applied to that data type.
yes! this is why i'm infatuated with my fractal zip!
they mention doing directory merge in the background and i'm like yes!
Automatic reconciliation of user mailboxes is important in the LOCUS replication system, since notification of name conflicts in files is done by sending the user electronic mail.
this seems like a mistake. if name conflicts are associated with the user who owns them, imo they absolutely should have a separate structure to record name conflicts under review. email is super complex
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
