Live data from Hacker News

Writing a Unix clone in about a month

drewdevault.com

31–40 of 140 posts

Re: Writing a Unix clone in about a month

#31
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!

Would love to read a blog post about that.

Re: Writing a Unix clone in about a month

#32

Missed opportunity to call it Drewnix.

Fun fact: Linus Torvalds originally named his fledgling OS as “Freax”, but it was an FTP site admin who came up with “Linux” and the rest is history. So perhaps the opportunity is not completely missed…

Re: Writing a Unix clone in about a month

#33
post #27

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

That wouldn't be too hard if GPU's would have a stable interface. Try programming a GPU in Assembly language and see how that goes. The experience sucks, but that's the level that needs to be targeted in case of an OS.

Re: Writing a Unix clone in about a month

#34
post #29
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…

I don't think that Apple particularly cares about porting their software to Linux. Do you feel the same about Apple? That with such an attitude, they surely cannot succeed?

Apple releases a great deal of open source software, which, so far as I'm aware, all runs on Linux as well. At least Swift, clang, and LLVM, all run on Windows as well. So does their Objective C compiler, so of Apple's programming languages, that leaves AppleScript. I would not describe AppleScript as robustly successful.

I believe Apple could probably get away with keeping Swift proprietary, or only supporting Apple platforms. But they don't. I have no inside-track information on why that is, but I suspect the reason is fairly simple: developers wouldn't like it.

Re: Writing a Unix clone in about a month

#35
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!

Signals are at the intersection of asynchronous IO/syscalls, and interprocess communication. Async and IPC are also weak points in the original Unix design, not originally present. Signals are an awkward attempt to patch some async IPC into the design. They're prone to race conditions. What happens when you get a signal when handling a signal? And what to do with a signal when the process is in the middle of a system call, is also a bit unclear. Delay? Queue? Pull process out of the syscall?

If all syscalls are async (a design principle of many modern OSes) then that aspect is solved. And if there is a reliable channel-like system for IPC (also a design principle of many modern OSes) then you can implement not only signals but also more sophisticated async inter-process communication/procedure calls.

Re: Writing a Unix clone in about a month

#36
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!

I always felt VMS' mailbox system was much more elegant, but I imagine it's an ugly mess under the surface too.

https://wiki.vmssoftware.com/Mailbox

Re: Writing a Unix clone in about a month

#37
post #33
post #27

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

That wouldn't be too hard if GPU's would have a stable interface. Try programming a GPU in Assembly language and see how that goes. The experience sucks, but that's the level that needs to be targeted in case of an OS.

For example, in the past Amiga computers had a 'GPU' (although much less powerful than todays GPUs) with a stable interface. It was a first class citizen in its OS. It also was incredibly easy to target in Assembly language.

Re: Writing a Unix clone in about a month

#38
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.

Re: Writing a Unix clone in about a month

#39
post #36
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!

I always felt VMS' mailbox system was much more elegant, but I imagine it's an ugly mess under the surface too. https://wiki.vmssoftware.com/Mailbox

[deleted]

Re: Writing a Unix clone in about a month

#40
post #24
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…

"We cannot effectively study, understand, debug, or improve, the underlying operating system if it is non-free. We actively work with the source code for the systems on which we depend, and we are not interested in supporting any platforms for which this is not possible." I understand that you don't like it, but how do you come to regard a statement like this as "arbitrary?" It's exclusive, for sure. "Purity test" is…

You're right, it isn't arbitrary. I removed that word from the post and edited it to express my opinion more clearly.
Post reply on HN