61–70 of 104 posts
https://csunplugged.org/en/ “Computer science” is a terrible name. Astronomy is not called “telescope science”, and biology is not called “microscope science”.
The "computer" in "computer science" is referring to turing machines, automata, etc, which are subjects of theory of computation, which studies the nature of computable functions.
Earlier quoted context omitted.
You're forking a process, not the whole system. Sorry, but I fail to see the ambiguity. If the window is in the process as some framebuffer, it gets cloned too. That may not mean you'll get two windows on your monitor, because your display engine is HW thing, and not a process.
It's because you're thinking "it does X! it's not ambiguous!" but still missing that the question is over why it SHOULD do X instead of Y, not over whether it does X or Y. To a user, it sure as heck doesn't make sense to fork a process and still end up with one window for both of them. For lots of processes the process is its windows as far as the user is concerned.
Some earlier discussion:
1 year ago https://news.ycombinator.com/item?id=21903007
4 years ago https://news.ycombinator.com/item?id=13249675
7 years ago https://news.ycombinator.com/item?id=7611093
Slightly off-topic, but... am I the only one who is troubled by the fact that the explanations of "fork and exec" are almost never, ever, discuss the rationale for picking this design instead of "CreateProcess()" a.k.a. "just_launch_this_exe_file()", or even acknowledge this alternative design? A student would probably expect that to launch an app, there is a system call that would do exactly that: you pass it the na…
What are the advantages you see, that are not rooted in the fact that it's very difficult to create any remotely sane declarative API in a language as imperative and primitive as C? In other words which of these advantages would still apply if you wrote your OS in, say, Ocaml?
Splitting fork and exec allows you to roughly hew the process environment of a clone of the parent into shape, process state-wise, before you sacrifice it to birth the child-process which will inherit many of these desired (and generally a few undesired) traits. So one big advantage is that it allows you to re-use an existing (and growing!) set of imperative commands to modify aspects of a running process to specify the same aspects for a child process,and that piecemeal mutation is basically the only way to express anything of any complexity in C, particularly if you don't want to break API compatibility all the time.
The downside is that you generally end up inheriting a bunch of cruft that you really didn't want to, that the imperative and piecemeal nature opens up problems with race conditions, and that there is a lot of overhead only partially mitigated by various complex hacks (COW, various more "leightweight" fork alternatives, special flags to general purpose system calls that are only there to control behavior upon forking, ...).
Earlier quoted context omitted.
Depends on what do you mean by window. If the window lives in a X server and you clone the client, window will obviously not get duplicated. It's quite clearly defined what gets duplicated and what gets shared on clone()/fork(). There really is no ambiguity.
I'm not saying a particular implementation is ambiguous as to what it does . Obviously any implementation will do something . I'm saying that fork as a concept is ambiguous as to what it should do.
Earlier quoted context omitted.
I'm not saying a particular implementation is ambiguous as to what it does . Obviously any implementation will do something . I'm saying that fork as a concept is ambiguous as to what it should do.
POSIX defines what a POSIX compliant fork() must do.
Earlier quoted context omitted.
You're forking a process, not the whole system. Sorry, but I fail to see the ambiguity. If the window is in the process as some framebuffer, it gets cloned too. That may not mean you'll get two windows on your monitor, because your display engine is HW thing, and not a process.
It's because you're thinking "it does X! it's not ambiguous!" but still missing that the question is over why it SHOULD do X instead of Y, not over whether it does X or Y. To a user, it sure as heck doesn't make sense to fork a process and still end up with one window for both of them. For lots of processes the process is its windows as far as the user is concerned.
Earlier quoted context omitted.
It's because you're thinking "it does X! it's not ambiguous!" but still missing that the question is over why it SHOULD do X instead of Y, not over whether it does X or Y. To a user, it sure as heck doesn't make sense to fork a process and still end up with one window for both of them. For lots of processes the process is its windows as far as the user is concerned.
Fork isn't an idea that users need to have. Devs may need to know what their OS API's fork() does. No-one else cares.
* TI58C programmable calculator, a handfull of registers, load store, conditional jump, that's it, essentially a very simple assembly-like language. * then CBM basic, two letter variable names, only globals, line numbers and goto/gosub * then (turbo) pascal with scopes, still single process unicore everything * then a little 6502 assembly (not my cup of tea) * then OS/2 and unix, and Linux when it started, multiprocessing (and multi user) on unicore * ...and proper computer science (as in von Neuman, Turing, Chomski hierarchy, compilers, sorting searching and complexity, graphs, etc) * then chroot * then virtualization (on the mainframe lol, but with Linux) * then containers and in parallel to the virtualization axis threads and green threads
I'm grateful this allowed me to grow into the concepts step by step and grow an intuition for what's happening.
and I wonder if there is some kind of "bottom up" curriculum somewhere that follows such a path?