> 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!
Writing a Unix clone in about a month
31–40 of 140 posts
Re: Writing a Unix clone in about a month
#32Missed opportunity to call it Drewnix.
Re: Writing a Unix clone in about a month
#33Waiting for an OS that treats GPU(s) as a first class citizen ...
Re: Writing a Unix clone in about a month
#34I 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?
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> 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!
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> 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!
Re: Writing a Unix clone in about a month
#37Waiting 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
#38> 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!
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> 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
#40I 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…