so! i'll start off the first bump with an interesting note: with the new clone3 syscall, you can set your cloned process's desired pid. pretty cool to be able to do. the use case is pretty niche, of course, and you run into the same concerns about collisions which crop up any time you start using magic numbers with system resources, but it's still pretty cool to have the option!

>>108212125
so which one of them has a dick?

File: 1710391836726663.png (327 KB, 1400x2000)

327 KB PNG

>>108212320
my head canon is the red one

Fork/clone are evil. They are severe mistakes that affect nearly every aspect of a unix-based system.
Since file descriptors are inherited on forks and this cannot be disabled, any resource referred to by a file descriptor cannot be released until all child processes close that fd, even if it was created in a library and they don't know about it.
CLOEXEC helps, but only if a forked process calls exec soon after, and all userspace code has to diligently set it on every fd it opens, and every syscall has its own way of doing it (EFD_CLOEXEC, O_CLOEXEC, SOCK_CLOEXEC, etc). If you forget to set CLOEXEC on an fd and then spawn a process, it'll live on in that process until it dies.
Any crypto library that generates secure random numbers has to call getpid to detect forks and reseed their RNG if it changes, or forked processes will generate identical keys/nonces/IVs and that is VERY bad.
If you strace a process and see a bunch of getpid calls all over, it's probably to detect forks because something will break and it needs to fix that. So wasteful.
I suspect fork only exists because the designers of unix were too lazy to make a proper API for passing certain fds to a child process, and we'll be paying the price until the end of time.

>>108212408
what if instead of inheriting copies of file descriptors, we use

CLONE_FILES

and share the same file descriptor table? :^)

>>108212428
If only there was a CLONE_NOTHING option that would give the fork an entirely blank file descriptor table. Then we could start to unwind some of this cancer.

>>108212408
>>108212428
on a more serious note, the new https://man7.org/linux/man-pages/man2/close_range.2.html syscall could probably help. it's a bit annoying to need to call this before you exec, but you could just put it into a wrapper function that you call instead
i know it's a kludge, but it works consistently for all file types
>>108212464
desu that's probably not an unreasonable expectation, especially with the way they've added the new arg struct to clone3. i could see that happening one day

>>108212464
>>108212470
oh hey wait a minute. i hadn't read the close_range manpage in a while. there's an option to set cloexec on all your fds! that's *almost* what you want, isn't it?

>>108212470
>>108212485
Hmm, I didn't know about that one. Still annoying that it's opt-in, and the only benefit over closing everything in /proc/self/fds is performance, but this does make it easier to do.
It'd be even better if CLOEXEC was close-on-fork instead, then you wouldn't have issues with long-lived forked processes keeping files open.

>>108212320
Why not both?

>>108212320
neither, they're both my wives

File: 1710392234749745.jpg (1.31 MB, 2169x3817)

1.31 MB JPG

>>108212566
well, one of them has to get knocked up
>>108212603
quite impossible, i fear. really bordering on deranged

>>108212623
I didn't realize I was talking to a faggot, my bad

File: 1710391612225365.jpg (363 KB, 1762x2048)

363 KB JPG

>>108212625
you are forgiven

>The raw clone() system call corresponds more closely to fork(2) in that execution in the child continues from the point of the call. As such, the fn and arg arguments of the clone() wrapper function are omitted.
i think i definitely prefer fork-like semantics. i don't really like having to pass a new entry point to the cloned child

>>108212125
you're keeping your troonimeism in stealth mode, and I approve, think of the children

File: 1710393526535861.jpg (121 KB, 1000x750)

121 KB JPG

>>108213234
i am thinking of the children
our future children

>>108213243
it's alright just behave

File: 1737266808838483.png (253 KB, 500x500)

253 KB PNG

>>108213682
you must be a detective

damn, i *really* thought this one would garner a lot more interest. clone3 is so fucking complicated lol. surely there's a lot to discuss...

>>108212294
>with the new clone3 syscall, you can set your cloned process's desired pid
I was wondering why you would do this at all and found the explanation:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2075035.html
https://en.wikipedia.org/wiki/CRIU
It's for restoring a process from disk, exactly how it used to be. And since programs can know their own PID you have to put the PID back as it was.
That sounds insane and indeed:
>A note on this: this is a project by various mad Russians to perform c/r mainly from userspace, with various oddball helper code added into the kernel where the need is demonstrated... However I'm less confident than the developers that it will all eventually work! So what I'm asking them to do is to wrap each piece of new code inside CONFIG_CHECKPOINT_RESTORE. So if it all eventually comes to tears and the project as a whole fails, it should be a simple matter to go through and delete all trace of it.

>>108212408
>I suspect fork only exists because the designers of unix were too lazy to make a proper API for passing certain fds to a child process
Pretty much. They added whatever was easiest one syscall at a time.
Very early Unix only had exec(). The shell exec()s a process, the process inherits everything and does whatever, and then exit() invokes a new shell (which inherits the process's context and actually has to clean up all the fds).
fork() was an easy addition to that model. Dennis Ritchie brags about how few lines it took to implement.
(And then when they made the shell use fork() suddenly the cd/chdir command stopped working and it took them a bit to figure out that a forked process couldn't affect the shell that spawned it.)

>>108214584
how can you possibly restore the memory state of a process that isn't yours?

>>108214584
>mad Russians
the true innovators in computing
honestly does sound like a hilarious mess of a feature, very
>trust no one, not even yourself
to even want checkpoint/restore in user space

>>108212125
>clone(3)/(v)fork
clone3?|v?fork

>>108215062
regex is handy

bampu

>>108214584
sounds like early UNIX was a fucking mess and the only reason it survived back then was that nobody else had a fucking clue about anything.

>>108212125
>girl pokes condom
>has lesbo sex
>somehow gets a baby
huh

>>108218012
One thing I'll say for early Unix is that it has very little fat, some features are bad but all are useful.
With Multics before they even started implementing it they were already designing fancy features that had questionable utility and would prevent more useful extensions. (But also a lot of features that were clearly useful and that Unix took years to catch up with.)

>>108218415
what about the Minix kernel? Is it a bit better organized? I know it's a microkernel, but does it have any major drawbacks?

>>108218016
Anime logic.

>>108214584
>And then when they made the shell use fork() suddenly the cd/chdir command stopped working and it took them a bit to figure out that a forked process couldn't affect the shell that spawned it
that's a neat anecdote, where did you get it from?

>>108218467
To be clear, Multics is its own operating system that started development a few years before Unix (and that Unix took many ideas from) while MINIX is an implementation of Unix that came a lot later. So they're very different things.
I don't know much about MINIX. But it's probably constrained by Unix compatibility.

>>108218491
https://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf#page=7
It has a lot of juicy trivia like about the original godawful non-hierarchical filesystem. (This is one idea they happily credit Multics for so it's interesting that they didn't go hierarchical immediately.)

>>108218016
A mystery for the ages

File: unix hist dmr's www files.png (139 KB, 835x345)

139 KB PNG

>>108218548
Oh! Straight from dmr. I've read most of bwk's and a good bit of ken's writing on Unix (including those hilariously outdated yet irresistibly charming early guides) and scraped dmr's old homepage a good while ago, but haven't got around to reading all of it.
I've been working on a compiler implementation for some time, so that's what I've mostly been focused on, but once that reaches some satisfactory stage I WILL proceed with writing an OS! :^)

>>108218853
>earlyunicos
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/cray.html
Very interesting, hadn't heard of this saga. I've read a good few of these papers as they came up but never trawled his page.

>>108218974
I'd recommend going through a number of the early bell labs members' homepages, they're a treat. wonderfully web 1.0, very terse and information-dense writing

>clone
>fork
peak UNIX brain damage

>>108218012
>and the only reason it survived back then was that nobody else had a fucking clue about anything.
Ctrannies are liars. Normal people knew a lot about how to design operating systems and some of them are still in use today in modern mainframes. The command names were stolen from older operating systems. The open/close/read/write/control design was stolen from older operating systems. "mmap" was stolen from older operating systems. Allocate/free was stolen from older operating systems. Hierarchical file systems were stolen from older operating systems. Linkers were stolen from older operating systems. Unix didn't invent anything. C didn't invent anything either. It was just a castrated version of older languages.
https://en.wikipedia.org/wiki/Burroughs_Large_Systems
https://en.wikipedia.org/wiki/Multics
https://en.wikipedia.org/wiki/Incompatible_Timesharing_System
https://en.wikipedia.org/wiki/OS/360_and_successors

>>108219575
Nobody here is saying Unix invented these ideas. Just because those older operating systems did some of the same things doesn't mean they are straightforwardly superior to Unix.
Multics had a lot of good ideas and a lot of headscratchers and was so tied to its hardware that it could not possibly have succeeded the way Unix did.

>>108219681
>and was so tied to its hardware that it could not possibly have succeeded the way Unix did.
Unix was tied to its hardware too. It was written in PDP-7 assembly and then PDP-11 assembly. They rewrote the assembly version in C. But Unix being portable is bad because why do you want everything to be stuck with a bad 1960s operating system forever? If Unix wasn't portable, it would be gone when the PDP-11 became obsolete and people would be using something better instead.

File: 1710391547691991.jpg (688 KB, 2892x4096)

688 KB JPG

>>108218016
she is a girl with a penis
shocking, i know

bampu

>>108219786
proof?

>>108218548
>the original godawful non-hierarchical filesystem
you know, I think user-facing hierarchical fs are outdated. For most purposed, tag-based ones are superior

>>108219786
Scary...

>>108222196
Maybe tag-based FSs have a future but the early Unix filesystem was a DAG where any directory could hardlink to any other directory. There was no root directory and no such thing as an absolute file path, nor could you even spell a path to a file in another directory, you had to chdir there or link/move/copy it into your working directory to operate on it. Every directory had to contain the tty special file and if you forgot to add it then the shell would hang as it kept failing to open it in a loop and you had to ask someone else to fix the directory for you. The number of directories was fixed so that you had to take the system offline to create more. You really really don't want to go back to that

>>108212464
>>108212470
There's some stalled work on doing process spawning via io_uring. It would setup a stopped child process and the parent could then execute syscalls in the child's context. This has all of the benefits of the fork-exec pattern - composable, flexible process setup instead of the monolithic and limited CreateProcess that windows has - without the downsides.
And since the child is stopped it could easily start with a lot of things left blank and deferred to exec, e.g. it wouldn't have to do copy-on-write all the VMAs unless explicitly desired.

https://lwn.net/Articles/908268/
https://lpc.events/event/16/contributions/1213/attachments/1012/1945/io-uring-spawn.pdf

I hope that gets picked up some day.

>>108222298
that's really interesting, thank you

>>108213682
Least mentally buckbroken /g/ user.

>>108218415
The thing about Multics is that they actually did it. It was a finished product, being used until 2000. The fact that we're sill wading in Unixland is tragic. I think Ken and Dennis tried to make up for it with Plan9, but it was too late.
Multics had weird spots though. For example, a user was one process. So even though users got a virtual memory space and couldn't clobber memory that wasn't theirs, an unruly program could easily clobber their own. The memory was segmented though, so you'd have to try kinda hard to do that, and it lead to other neat things like dynamic linking and files being automatically mmap'd by default, basically.

>>108222652
They did do it, and what they did was cool, but Unix also did things and is also cool.
Some of the Multics features backfired and seem annoying to deal with, and I suspect they're even more intrusive than the Unix brain damage. There's no strong distinction between library functions and terminal commands, which in a way fits with the single-process session concept, but it turns out that it's pretty rare for the same routine to be useful for both and so a ton of library functions are postfixed with an underscore so you don't confuse them with user-facing commands. (You can still run them as though they're commands but they tend to either have no perceptible effect or crash your whole session.)
And this next complaint maybe isn't entirely fair since it's caused by Unix muscle memory, but "cd" is an alias for "create_directory", and if you run create_directory with an argument that already exists it deletes the existing file/directory (if it has other links, but directories on Multics often have multiple names). So when I tried Multics I sometimes accidentally deleted directories I wanted to use. I even replaced my home directory and had to figure out what happened and find another name to restore it from.
Multicsland is an impossible dream to begin with since it was never portable but I don't even know that it would have been better than Unixland.

>>108222196
> hierarchical is bad
Don’t tell the DNS guys or the URL guys that.
I’m still using uucp bang paths

>>108222296
super interesting bit of history right there. Unix is like a cemetery of bad ideas where the survivors are ugly but the buried are even uglier

>>108223323
I don't know if it's right to frame the original FS as a dead end or even to call it an "idea", it feels like a halfassed version of the Multics FS.
CTSS (Multics's predecessor, also used by Thompson et al) had a single flat layer of directories. No root directory, I think typically fewer than a dozen directories total, and every file was inside some directory or other. Since there's only one layer each directory can always be uniquely identified by its name, no messy relative paths. Clean and simple and very limited.
Multics had a modern-looking hierarchy. The really intriguing thing compared to CTSS must have been that directories are themselves files that can be contained in directories. It's not immediately obvious that you need the tree structure.
So if you're designing your little experimental mini-Multics the first thing you do is make your directory a kind of file that can be linked in other directories, and you see how far that gets you and where the problems crop up.
Then when you decide to make it hierarchical you impose this as an enforced convention on top of the digraph by always setting up the .. link. Early mkdir(1) was actually setuid, it manually created the parent directory link in userspace and the basic syscall required root to prevent ordinary users from mucking it up. It only got encapsulated later.
So you can draw a throughline where each successive step makes the system less crazy without actually discarding the previous step.

only good use of fork() I can think of is Factorio's ghetto non-pause save method

>>108223516
how do you know all this stuff? Is there a book you recommend on the history and evolution of OSs?

>>108223829
NTA but check out Multicians.org, lots of design discussion about Multics. Interesting stuff!

>>108223207
no, for most machine-exclusive things they're very useful. but humans apply categories to things, so eg an image is multiple things at once

>>108223323
>>108223516
Unix people copy things without understanding what they do or what problem they're supposed to solve. The hierarchical file system in Multics is about a way to organize information. The hierarchical file system in Unix is about copying what Multics did.

>>108224153
I put all my images in the “gifs” directory.
You need more?

Multics, more like Muttics.

>>108224732
Unix is literally pronounced the exact same way as "eunuchs" on purpose. Unix trannies are projecting again.

File: 1769636557848023.png (3.18 MB, 1869x2048)

3.18 MB PNG

>>108224825
>everyone who makes fun of non-DEC "operating systems" is a projecting unix tranny
Peak mental illness. Here, take your meds and seek rope ASAP.

>>108220552
are you the wife? no? then no proof for u
>>108222296
it's a great big world out there
>>108222196
imagine how much of a nightmare DAC would be (from a user perspective)
>>108222298
god damn that seems awesome. why's it stalled? apologies if that question is answered in the links you provided. haven't had a chance to read them yet
>>108225144
wow, she is LITERALLY me

bampu

>>108225144
whats that

>>108223829
The paper linked in >>108218548 describes how the filesystem evolved. Ritchie wrote some other good papers.
https://www.tuhs.org/Archive/Documentation/OralHistory/transcripts/thompson.htm and https://www.tuhs.org/Archive/Documentation/OralHistory/transcripts/ritchie.htm give context on how they actually saw Multics and treated its ideas. (Oral histories are goldmines, not so technically precise but pretty earnest about why things happened and how people worked and what might have influenced what. I remember the Kernighan one also being great. There are audio recordings too.)
I spent some time dicking around in CTSS and Multics emulators for research and internalizing how they worked. https://timereshared.com/ is a cool resource. I also second https://multicians.org/.
The mkdir thing I actually learned because of one of these threads while trying to figure out what the access syscall was used for historically. I found weird code by ripgrepping in a local clone of https://www.tuhs.org/cgi-bin/utree.pl, checked out the actual permission bits in an online emulator (either https://copy.sh/v86/?profile=unix-v7 or https://skn.noip.me/pdp11/pdp11.html), then googled and found https://utcc.utoronto.ca/~cks/space/blog/unix/UnixDirectoryFiddlingHistory.
Absorb enough different sources and you start seeing the connections.

>>108224685
I do!
>>108225673
>imagine how much of a nightmare DAC would be (from a user perspective)
what's a DAC? directory access control? I think Unix user permissions are really quite horrible anyway, comprehensive access control really is just a list of tags just the same, and thus could neatly be rolled into a tag fs.

>>108226298
discretionary access control (think chmod and chown)
https://en.wikipedia.org/wiki/Discretionary_access_control
contrast with mandatory access control (e.g. SELinux)

last bampu (likely for good)

>>108227385
ah I see. but then I don't see your point. tags are just about layout, the files themselves can have all the same attributes.

>>108225673
>why's it stalled?
Not sure if the original patchset was ever RFC'd (can't find anything on LKML) or if this was just a prototype, but someone from Suse picked it up 2 years ago, got some replies that aren't exactly "fuck yeah, ship it" and not much since then.

https://lore.kernel.org/all/20241209234316.4132786-1-krisman@suse.de/

So the usual combination of "someone has to keep working on it" and "needs kernel maintainer buy-in".

>>108226025
Estradiol, I think.

>>108228647
i guess i'm just thinking of doing something like a recursive chown. becomes a lot more complicated with tags
>>108230233
it's joever...

>>108232573
>becomes a lot more complicated with tags
well, chown has to touch every file individually already, I don't see how that's any different

>>108232646
from a user perspective, as i said. currently, it's easy to manage ownership of, e.g., all of my

~/Documents/

that becomes a lot less intuitive with tags

>>108232728
I really don't see how that's any different, worse even.
if you

chown ~/Documents

, only that dir's owner is changed, all the files within keep their old owner.
you'd need to tell chown to descend into Documents recursively to get it to work.With tags, you'd just tell chown to change the owner of every file tagged as Documents. much simpler