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

41–50 of 104 posts

Re: Computer Science from the Bottom Up

#41

Post by Joker_vD »

kccqzy wrote: post #38
Joker_vD wrote: post #35

Earlier quoted context omitted.

Yes, I know. But you only figure it out after you've done you fair share of IPC and management of worker processes by hand. When you're a fresh student, this "fork+exec" just seems like a pretty ridiculous way to organize things: why not just launch the executable you want to launch immediately? Nope, that's at best postponed until the chapter on IPC, at worst it's never discussed at all, so you're left puzzled and w…

When you are a fresh student, and when fork/exec is too advanced for you, just use system(3). Not recommended for production use, but that's indeed the easiest way to launch an executable. Do we optimize our system call design for fresh students or for professionals?

We were talking about the presentation of "fundamentals" in the courses on Computer Science, right? The fork/exec design is highly non-trivial and so should probably deserve more discussion, with examples of alternative designs and design considerations, than mere "that's how new processes are created, nothing special here, let's move on".

Re: Computer Science from the Bottom Up

#42

Post by wmf »

kccqzy wrote: post #33
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…

Well we do have a library call for launching a new process called posix_spawn(3), but it's complicated mainly because they are a lot of options you want to configure when launching a process: which file descriptors would you like to close, which would you like to share with the newly created process, what uid the new process should have, what working directory it should have, etc. It's just a large and complicated ca…

Besides fork() and spawn() there's another option which is to create an empty process, configure it as needed, then start it. IMO this is what simple, orthogonal primitives looks like. This generally isn't possible in Unix but AFAIK it's possible in Mach.

Re: Computer Science from the Bottom Up

#43

Post by beckman466 »

Just read page one and two and I already LOVE the conversational style of writing from the author. Who the hell decided we should write textbooks in such a dry and formal way (this has been my experience). Maybe the textbooks fail me because the author is not able to translate their excitement into text (I have ADD, so there's that too)? Of course it's also due the nature of the copyright/IP system, together with the hierarchies inherent to capitalism. The competition between workers selling their labor works to the advantage of employers/capitalists.

Anyway, learning is basically just a long conversation where we learn about the feedback loops about whatever concept or system we are trying to understand and interact with. For me this author's style (and others like him) works a million times better to do that in an intuitive way.

Re: Computer Science from the Bottom Up

#45

Post by rambambram »

mariodiana wrote: post #39

I can't be the only one, but I feel pretty sure I'm in a minority among computer programmers. This "bottom-up" approach is just not the way my brain works. I definitely feel I'm a top-down sort of thinker and learner, and this puts me at a disadvantage, regarding the literature and approach in this profession. Are the terms describing the two approaches here "empirical" versus "rational"? I'm talking about building b…

You put into words what I've been feeling for a long time. So I guess you're not alone. I 'cope' by just turning it around: finding some meaningful project, decide what I want it to be, and then find out one step at a time how to get closer. That starts with me finding out - and then being comfortable enough with - a big overview of the project. Somehow I keep coming back at the 'work is like a hill' metaphor from Ryan Singer in his book Shape Up (from basecamp). https://basecamp.com/shapeup/3.4-chapter-13#work-is-like-a-h...

Re: Computer Science from the Bottom Up

#46

Post by megous »

dataflow wrote: post #40
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 I hate about fork is that it fundamentally doesn't even make sense. You fork a process with a window, what happens to that window? Does it get duplicated? Do both control the same window? It has no sensible behavior in the general case without cloning the whole machine, and even then, your network isn't going to get forked. There are limited cases where it could make sense, but the fact that that's not true in g…

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.

Re: Computer Science from the Bottom Up

#47

Post by Joker_vD »

megous wrote: post #46
dataflow wrote: post #40

Earlier quoted context omitted.

What I hate about fork is that it fundamentally doesn't even make sense. You fork a process with a window, what happens to that window? Does it get duplicated? Do both control the same window? It has no sensible behavior in the general case without cloning the whole machine, and even then, your network isn't going to get forked. There are limited cases where it could make sense, but the fact that that's not true in g…

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.

So, do threads get duplicated or shared? Or something altogether different happens to them?

Re: Computer Science from the Bottom Up

#48

Post by dataflow »

megous wrote: post #46
dataflow wrote: post #40

Earlier quoted context omitted.

What I hate about fork is that it fundamentally doesn't even make sense. You fork a process with a window, what happens to that window? Does it get duplicated? Do both control the same window? It has no sensible behavior in the general case without cloning the whole machine, and even then, your network isn't going to get forked. There are limited cases where it could make sense, but the fact that that's not true in g…

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.

Re: Computer Science from the Bottom Up

#49

Post by kps »

Joker_vD wrote: post #41
kccqzy wrote: post #38

Earlier quoted context omitted.

When you are a fresh student, and when fork/exec is too advanced for you, just use system(3). Not recommended for production use, but that's indeed the easiest way to launch an executable. Do we optimize our system call design for fresh students or for professionals?

We were talking about the presentation of "fundamentals" in the courses on Computer Science, right? The fork/exec design is highly non-trivial and so should probably deserve more discussion, with examples of alternative designs and design considerations, than mere "that's how new processes are created, nothing special here, let's move on".

If you want to look at it as ‘fundamentals’, fork only requires the concept of a task, whereas your top-level comment's suggestion also requires (a) secondary storage, (b) organized into files, (c) that can be named.

(That's not why Unix developed with fork, though.)

Re: Computer Science from the Bottom Up

#50

Post by userbinator »

brundolf wrote: post #2

This seems highly focused on systems; I wouldn't call it representative of "Computer Science" as a whole. Only maybe 2-3 of the classes in my computer science degree were focused on this kind of stuff. Still seems like a good resource, just perhaps mislabeled.

Yes, the same comment appears whenever this comes up on HN. Bottom-up would actually be something more like Nand2Tetris or Petzold's code.
Post reply on HN