Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Computer Science from the Bottom Up

bottomupcs.com

Post reply on HN
Print view View original

71–80 of 104 posts

Re: Computer Science from the Bottom Up

#71

Post by jamcohen »

optimalsolver wrote: post #14

I think these CS books should start with a philosophical look at what kind of thing computation actually is, rather than diving straight into UNIX file system structures with barely any context. But I guess that would be computer science from the top down.

Richard Feynman's lecture is a great resource for this: https://www.youtube.com/watch?v=EKWGGDXe5MA

He proposes a file clerk that gets progressively dumber and faster until they get so dumb that they can be simulated by an electronic circuit.

Re: Computer Science from the Bottom Up

#72

Post by cowanon22 »

If you truly want to learn computer science from the basics, I would recommend starting with Nand to Tetris https://www.nand2tetris.org/ and the corresponding book and labs (and Coursera courses), along with Code the hidden language... They cover how a computer is actually build from first principles. After this, Structure and Interoperation of Computer Programs and the Algorithm Design Manual.

Re: Computer Science from the Bottom Up

#73

Post by R0b0t1 »

khaledh wrote: post #59
Joker_vD wrote: post #31

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…

From "Operating Systems: Three Easy Pieces" chapter on "Process API" (section 5.4 "Why? Motivating The API") [1]: ... the separation of fork() and exec() is essential in building a UNIX shell, because it lets the shell run code after the call to fork() but before the call to exec(); this code can alter the environment of the about-to-be-run program, and thus enables a variety of interesting features to be readily bui…

This is not enough of an explanation as these things are still possible with CreateProcess.

I do remember reading the real explanation -- it was easier to implement fork. That's it.

Re: Computer Science from the Bottom Up

#74

Post by Joker_vD »

patrec wrote: post #64
Joker_vD wrote: post #31

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…

> The fork+exec has many unobvious advantages over CreateProcess, 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…

So what would the ideal API look like, in your opinion? CreateProcess, as it exists now, has lpStartupInfo->lpAttributeList parameter which is a huge and growing list of various flags and knobs; what would an extensible, declarative API look like in an OS written in OCaml?

> you don't want to break API compatibility all the time.

Indeed you don't, unless you're okay with forcing your users to rewrite all the libraries and/or applications every couple of years. That's true of any programming environment, imperative or not.

> various complex hacks (COW, various more "leightweight" fork alternatives

Copy-on-write is as much a hack as persistent data structures are: it's just more coarse-grained.

Re: Computer Science from the Bottom Up

#75

Post by Animats »

Joker_vD wrote: post #31

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…

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()"

It comes from a hack in Unix for PDP-11 systems. This was before paged virtual memory. "Fork" worked by swapping the process out to disk. Then it duplicated the process table entry, with one entry set to the swapped-out copy and one set to the in-memory copy. This was simple to implement, and would still work if you invoked something big enough that both sides of the fork could not both fit in memory. Thus, a shell could invoke a big compiler. That's the real reason.

There are lots of other ways to do it. Some other systems have "run" as a primitive. Plan 9 offers all the options - share code, share file handles, share data. Windows has more of a "run" primitive. QNX has a system where a new process starts empty but attached to a shared object, with control starting in the shared object. The shared object then does the work of loading the program to be executed, so the OS doesn't have to.

Re: Computer Science from the Bottom Up

#76

Post by megous »

dataflow wrote: post #56
megous wrote: post #53

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.

Users don't fork processes, it's a low-level system thing.

Re: Computer Science from the Bottom Up

#77

Post by dataflow »

megous wrote: post #76
dataflow wrote: post #56

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.

Users don't fork processes, it's a low-level system thing.

Why repeat the same thing as the sibling comment posted an hour ago...?

Re: Computer Science from the Bottom Up

#78

Post by ffhhj »

optimalsolver wrote: post #14

I think these CS books should start with a philosophical look at what kind of thing computation actually is, rather than diving straight into UNIX file system structures with barely any context. But I guess that would be computer science from the top down.

Start with a single instruction, like SBNZ (substract and branch if not equal to zero), and build a modern operating system with it.

Re: Computer Science from the Bottom Up

#79

Post by photojosh »

giveexamples wrote: post #70

a real bottom up would start from transistors, universal xor, flip flop memory, code execution, algorithmic complexity, data structures, abstraction, recursion, graphs, concurrency, distributed system design.

> transistors, universal xor, flip flop memory,

These are the 'bottom up' of computer engineering, which are implementation details (my course included semiconductor physics as well). Computer science tends to look at theoretical constructs like Turing machines instead of these. The remaining topics which are indeed computer science.

Re: Computer Science from the Bottom Up

#80

Post by jayrokk5959 »

Joker_vD wrote: post #31

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’s this?
Post reply on HN