how on earth does openssh not only have incredibly fucked versioning but is the only package i've ever seen to mention a "privilege separation" chroot path which actively breaks non-root builds. are you fucking kidding me bruh. "privilege separation chroot" defaulting to /var/empty and it immediately errors if it can't create it????? why are your version strings like that bruh?????
87
Replies
·
0
Boosts
not the "hard links to directories" part that's a super specialized use case
this is not a reason in itself but the biggest reason by far that hard-linked directories can't be done is because "historically" (which in OS terms means "unix did it because multics did it and suddenly 50 years have passed") the directory structure incorporates basically no form of indirection or abstraction and path resolution largely corresponds to pointer chasing around the hard disk
if you conceive of the filesystem as a kernel-level global data store (and POSIX requires you to think inside that box), this is.........i'm going to say it's more reasonable
actually, what this makes me really wonder is if filesystem designers ever stopped being bell labs HR
i'm relatively confident that persistent memory for many decades has been "one or more contiguous array(s) of fixed length(s) [with better performance for nearby writes]" and i just can't possibly express the feeling of betrayal and despair that i spent so much time studying the i/o patterns of pants subprocesses in build tasks when apparently nobody has ever spent any time studying i/o patterns in the OS
the only thing anyone can ever think of is "what if userspace i/o was more like interfacing with the hardware but still underwent ten levels of 'caching'"
alternatively, "what if you provided us a coroutine-based task model that distinguishes regions of in-memory computation time from logically-blocking i/o operations and also mapped borrowed and owned local variables to a virtual stack frame so our innovative lifetime model just fucking worked for explicitly-interrupted computations that can be efficiently executed in embedded kernels as well as web browsers and HPC code?"
"and what if tokio just ignored all that nerd shit and we casually didn't expose any stdlib abstraction so the entire ecosystem pulls in 300 deps and assumes multithreaded behavior?
so you can get weird deadlocks because nobody tests anything?
even though the coroutine transform and memery safety together makes behavior deterministic?
and is literally the one thing C could simply never do?
oh and then nobody in the entire world has ever heard of a shell pipeline so every single fucking ring buffer helpfully allocates memory instead of blocking
i looked up the pthreads API and screamed as if burned
i am learning so many interfaces that people who assuredly were considered experts and innovators in computing agreed to implement and it truly astounds me
i like the first linux threading impl https://www.man7.org/linux/man-pages/man7/pthreads.7.html#:~:text=LinuxThreads
LinuxThreads
The notable features of this implementation are the following:
In addition to the main (initial) thread, and the threads that the program creates using
pthread_create(3), the implementation creates a "manager" thread. This thread handles thread creation and termination. (Problems can result if this thread is inadvertently killed.)Signals are used internally by the implementation. On Linux 2.2 and later, the first three real-time signals are used (see also
signal(7)). On older Linux kernels,SIGUSR1andSIGUSR2are used. Applications must avoid the use of whichever set of signals is employed by the implementation.Threads do not share process IDs. (In effect, LinuxThreads threads are implemented as processes which share more information than usual, but which do not share a common process ID.) LinuxThreads threads (including the manager thread) are visible as separate processes using ps(1).
so the page tries REALLY hard to cast LinuxThreads POSIX nonconformance as problematic and i think every single one is Good Actually
particularly these two are evidence of desperation:
When a thread calls
execve(2), all other threads are terminated (as required by POSIX.1). However, the resulting process has the same PID as the thread that calledexecve(2): it should have the same PID as the main thread.
this is the first time it mentions "PID", but since these threads are just "processes with more sharing", they also have distinct PIDs--it is deeply misleading to (as in the first bullet) say only that getpid(2) returns a different value, since the PID is, once again, a kernel-level globally addressable value, much like the page cache.
no one on the fucking planet would ever claim that threads-as-processes should have been implemented by having the kernel mutate the fucking PID of a running process.
and exec() shouldn't be allowed if there are any threads instead of introducing riddle semantics
exec() is just an incredibly fucked API in the first place. "yes, i want to keep my PID the same, but start executing different code. no, i don't need to conserve any memory across the call, i have no need for partial evaluation"
