Live data from Hacker News

Writing a Unix clone in about a month

drewdevault.com

101–110 of 140 posts

Re: Writing a Unix clone in about a month

#101
post #7

I was interested in Hare until I found this immensely self-defeating FAQ item: https://harelang.org/documentation/faq.html#will-hare-suppor... As a baseline, I support developers using whatever license they would like, and targeting whatever operating systems, indeed, writing whatever code they would like in the process. That doesn't make this specific policy a good idea. Even FSF, generally considered the most extre…

My real showstopper with Hare is the lack of multithreading. In the modern world, we need to be making parallelism easier not harder!

Re: Writing a Unix clone in about a month

#102
post #99

Earlier quoted context omitted.

Unix signals do... a lot of things that are separate concepts imo, and I think this is why there are people who don't like it or take issue with it. You have SIGSTOP/SIGCONT/SIGKILL, which don't even really signal the process, they just do process control (suspend, resume, kill). You have simple async messages (SIGHUP, SIGUSR1, SIGUSR2, SIGTTIN, SIGTTOU, etc) that get abused for reloading configuration/etc (with hack…

The Windows mechanisms you're mentioning were also added over the course of many, many years. Much of Windows also happened a long time after UNIX signals were invented. If you're including all that other stuff, it's probably fair to include all of the subsequent development of notification mechanisms on the UNIX side of the fence as well; e.g., poll(2), various SVR4 IPC primitives, event ports in illumos, kqueue in…

Yeah, it definitely is (especially since SIGIO is a thing :)). Even the Unix signals had more added to them over time (SIGWINCH and friends iirc came from the BSDs).

A lot of the mechanisms are very OS specific but I do think they're good comparisons to have with signals as well.

Re: Writing a Unix clone in about a month

#103
post #99

Earlier quoted context omitted.

Unix signals do... a lot of things that are separate concepts imo, and I think this is why there are people who don't like it or take issue with it. You have SIGSTOP/SIGCONT/SIGKILL, which don't even really signal the process, they just do process control (suspend, resume, kill). You have simple async messages (SIGHUP, SIGUSR1, SIGUSR2, SIGTTIN, SIGTTOU, etc) that get abused for reloading configuration/etc (with hack…

The Windows mechanisms you're mentioning were also added over the course of many, many years. Much of Windows also happened a long time after UNIX signals were invented. If you're including all that other stuff, it's probably fair to include all of the subsequent development of notification mechanisms on the UNIX side of the fence as well; e.g., poll(2), various SVR4 IPC primitives, event ports in illumos, kqueue in…

Except much of these UNIX later development were done by their derivatives and are often available with certain degree of incompatibility among them (or not even at all)

Re: Writing a Unix clone in about a month

#104

Earlier quoted context omitted.

As I wrote in some older discussion about UNIX signals on HN, the root problem (IMHO, of source) is that signals conflate three different useful concepts. The first is asynchronous external events (SIGHUP, SIGINT) that the process should be notified about in a timely manner and given an opportunity to react; the second is synchronous internal events (SIGILL, SIGSEGV) caused by the process itself, so it's basically lo…

At least the first two are also conflated in a typical CPU’s trap/interrupt/whatever-your-architecture-calls-it model, which is what Unix signals are essentially a copy of. So this isn’t necessarily illogical.

SIGHUP and SIGINT have no CPU-level equivalent.

Re: Writing a Unix clone in about a month

#106
post #67

Earlier quoted context omitted.

I believe this was the 3rd time I’ve seen this book being recommended this week. It must mean something.

It is a must for anyone serious about UNIX programming. Additionally one should get the TCP/IP and UNIX streams books from the same collection.

Is the Unix streams book “Unix Systems V network programming”?

Re: Writing a Unix clone in about a month

#107

This is really cool. Reminds me of the original Unix was invented in a couple weeks while Ritchie's family went on vacation to CA to visit his in-laws. Source: UNIX: A History and a Memoir Paperback – October 18, 2019 by Brian W Kernighan (Author)

But I think it’s relevant to say that before writing Unix he was working on Multics for a long time already. Unix was a “simplified” version of it, if I remember well. So it didn’t “spring out of thin air.”

Where did the quoted text come from? Something might have gotten edited.

Re: Writing a Unix clone in about a month

#108
post #18

> I also finally learned how signals work from top to bottom, and boy is it ugly. I’ve always felt that this was one of the weakest points in the design of Unix and this project did nothing to disabuse me of that notion. Would love any resources that goes in more details, if any HN-er or the author himself knows of some!

"signalfd is useless" is a good article: https://ldpreload.com/blog/signalfd-is-useless It goes into the problems with Unix signals, and then explains why Linux's attempt to solve them, signalfd, doesn't work well.

That is a good article. I found myself nodding in agreement while reading it, thinking "Yeah, I've been bitten by that before".

How does Windows handle this? There's still signals, but I believe/was under the impression that signals in Windows are an add-on to make the POSIX subsystem work, so maybe it isn't as broken (for example, I think it doesn't coalesce signals).

Re: Writing a Unix clone in about a month

#109
post #27

Waiting for an OS that treats GPU(s) as a first class citizen ...

If programming GPU drivers was not something only a handful of employees with NVIDIA or AMD badges could do (because of NDAs, non-public documentation and immense complexity), somebody would have tried.

Re: Writing a Unix clone in about a month

#110
post #67

Earlier quoted context omitted.

It is a must for anyone serious about UNIX programming. Additionally one should get the TCP/IP and UNIX streams books from the same collection.

Is the Unix streams book “Unix Systems V network programming”?

That one is also relevant, yeah.

Although, I did a mistake, I was thinking about all Richard Stevens books for networking, that go beyond plain TCP, UDP, IP.

https://en.wikipedia.org/wiki/W._Richard_Stevens

Unfortunelly given their CS focus, they are kind of on the expensive side, I read most of them via libraries, or eventually getting my own copies.

Post reply on HN