The UNIX system has been in wide use for over 20 years, and has helped to define many areas of computing.
Post
Replies:
0
Their semantics in LOCUS are identical to those seen on a single machine Unix system, even when processes are resident on different machines in LOCUS.
every NFS mount ever spontaneously returns SIGBUS
ok i absolutely need to find this dissertation they just cited
Walker, B.J., Issues of Network Transparency and File Replication in Distributed Systems: LOCUS, Ph.D. Dissertation, Computer Science Department, University of California, Los Angeles, 1983
acm is sending me to a broken proquest link but i now phd dissertations are saved somewhere
i know someone at georgia tech i could ask them. or i could try the library of congress LMAO
literally this is the cite
Just providing these seemingly simple ipc facilities was non-trivial, however. Details of the implementation are given in [WALK83].
they're taunting me. i must find it
LOCUS permits one to execute programs at any site in the network, subject to permission control, in a manner just as easy as executing the program locally.
see this is why DARPA wouldn't go for it. ARPAnet hates permissioned systems. they all hate that shit. vint cerf is a google vp and this is exactly how LLM scrapers act when you permission them out of your face
The mechanism is entirely transparent, so that existing software can be executed either locally or remotely, with no change to that software.
P A N T S
A A
N N
T T
S S
The decision about where the new process is to execute is specified by information associated with the calling process.
trying to reach through the screen again because i finally found someone who cares
"structured advice list" all they need to say is dependency graph now
see here's the thing they knew they were building a goddamn operating system and that's one thing i didn't realize at the time
but their unix is obviously just my bazel
yeah so they did absolutely do better than me 40 years earlier and that's on me to catch up
The semantics of the available functions by which processes interact determines, to a large extent, the difficulty involved in supporting a transparent process facility.
posix reading my email screaming crying throwing up
The most difficult part of these functions' semantics is their expectation of shared memory.
TRUTHNUKE!!!!!!!
@hipsterelectron yup yup. immutability and object scoping, i propose. compilers that understand memory behavior. high-level dope!
Virtually all processes read and write substantial amounts of data per system call.
@hipsterelectron should we analyze/describe task resource behavior like on a rusty old mainframe? yes!
so funny story
As a result, most collections of Unix processes designed to execute on a single machine run very well when distributed on LOCUS.
this with pants and bazel except bazel literally only works in the "cloud". and the pants capacity for recursive/monadic tasks (dynamic dependency generation e.g. resolving a lockfile) is specifically how we could do outline compiles with twitter rsc locally and then farm scalac out to finish the job. so you control it locally and get results locally, and the cloud is used as extra capacity instead of controlling your organizational capacity
so google really didn't like that
literally these corps are nothing when we dream together. that was 2019 when google killed rust and pants because we showed them up and demonstrated their attempts to RCE every internet user with chrome and every software user with bazel were perhaps not such noble schemes to protect users against evil!
perhaps it's strange that the surveillance company who graciously negotiates TLS certificates for you keeps describing network code as tricky and unsafe! perhaps when they graciously offer a DRM ✅ that requires you to leave your python packages alone in a room with their server before publishing to pypi that........you are not keeping your users safe with the ✅!
(the astral engineer who slanders zip files wrote the microsoft DRM and removed pgp keys from pypi.)
astral got funding from google and chainguard and themselves contributed funds to one of the literally 3 separate rust2c "forks" of zstd. chainguard is the startup who developed the DRM ✅ technology
unfortunately, one of chainguard's cryptographers (santiago) is pretty cool. i should reach out to him because his work on attestation graphs is also how you'd do signed builds if you wanted to use your own hardware
which of course means process isolation guarantees..........and i happen to know an agender who's into that freaky shit
@hipsterelectron i play with VM APIs, but “gender”.
The new error types primarily concern cases where either the calling or called machine fails while the parent and child are still alive.
omg like gundam
When the child's machine fails, the parent receives an error signal. Additional information about the nature of the error is deposited in the parent's process structure, which can be interrogated via a new system call.
they did NOT defeat me here! i have saved lives with my signal handling tiered logging before
but they did put it in the OS, so i still gotta catch up
For those data types which the system understands, automatic reconciliation is done.
easy mode. what's next
Otherwise, the problem is reported to a
higher level; a database manager for example, who
may itself be able to reconcile the inconsistencies.
can the database be my manager
Eventually, if necessary, the user is notified and tools
are provided by which he can interactively merge the copies.
do scientists say this? i know i say this and i know pouzin says this. do people say this? dr. jennings says this. do scientists still say this? i bet they do. i need to find them. i want to build the future with them
4.1 Partitions
Partitions clearly are the primary source of
difficulty in a replicated environment. Some authors
have proposed that the problem can be avoided by
having high enough connectivity that failures will
not result in partitions. In practice, however, there
are numerous ways that effective partitioning occurs.
oh MAN that's the coldest "in practice" i've ever seen
Even when the hardware level is functioning, there are miriad ways that software levels cause messages not to be communicated; buffer lockups, synchronization errors, etc.
that's a really cute spelling of myriad. i like the y but somehow miriad feels less showy/extravagant and more focused/serious
see this is why you can't ever pretend to separate engineers from "SRE" work:
In addition, there are maintenance and hardware failure scenarios that can result in file modification conflict even when two sites have never executed independently at the same time.
the engineer can theorize
For example, while site B is down, work is done on site A. Site A goes down before B comes up. When site A comes back up, an effective partition merge must be done.
the practitioner can actualize. junyer the RE2 maintainer and a great teacher of mine was an SRE before he ended up maintaining the code that powers google search
this is exactly the kind of shit i would write
an immediate question is whether a data object, appearing in more than one partition, can be updated during partition.
i.e. "if google cloud goes down how fucked are you"
In our judgment, the answer must be yes.
JUDGEMENT! MUST BE! YES!
this was also why i realized atomic memory models were solving a different problem space!
in many environments, the probability of conflicting updates is low. Actual intimate sharing is often not the rule.
and if it is......localize those intimate motherfuckers!!! give them room to explore each others' address spaces!!!!!
i am quite surprised why they remain stuck in the mode of trying to adjudicate a best-effort answer to mutually conflicting modifications. like to me "conflicts" e.g. writing to the same location indicate that there is an unresolved user-level "conflict" between their scheduled tasks!
and this is where aaron turon's formal verification framework would say: the behavior is incorrect! it produces a data race!
that's why i proposed the named hierarchy of sync contexts (up to global). it takes our environment isolation mechanism and gives the user a structured resource (with a lifetime) they can use to express a sequence of modifications that can be unambiguously verified for correctness.
what is correctness?
in each sync context, modifications are built up as an ordered sequence of i/o operations, then explicitly committed. as these operations are evaluated during the blocking commit call, the only correctness requirement is that a named resource (file path) previously committed to the same context cannot match the name of a new resource.
note that this arises not as we engage in attempting to write a whole bunch of data, but when we allocate (e.g. open()) a resource handle. this should fail eagerly, and quickly, and unambiguously indicate a problem with user input, or with the input environment!
OMG NOOOOOOO I JUST READ THE NEXT PAGE THIS IS A MIND MELD