Live data from Hacker News

Writing a Unix clone in about a month

drewdevault.com

121–130 of 140 posts

Re: Writing a Unix clone in about a month

#121

Impressive, super cool, and inspiring! Example of “creating something impressive in X days” requires a lot of experience and talent that is built over years .

Versus now... I changed the text on a button with an internationalized string. It only took me about a week. I put the English string in the catalog, updated a number of tests, run the tests on the local system, pushed the change to staging cluster, fix unanticipated test failures, push the change to production, contact the translators to have the string translated to a number of languages, and have documentation upd…

I suggest you use translation management tools, so the translator gets the strong as soon as you add it to the catalog.

Buy anyway there's no "then vs now" when you are really comparing "prototype" to "deliver to users". It took Unix decades to get those strings translated.

Re: Writing a Unix clone in about a month

#122

Earlier quoted context omitted.

I only read part of the FAQ. I find the desire to keep the complexity low by limiting the compiler lines of code and not using LLVM interesting, but I wonder how practical it is. The FAQ admits that because of this, it generates slower code. So it shifts the complexity to the software codebase, by telling the users to “use assembly where needed”. Seems a bit like Python’s philosophy of not introducing too much optimi…

I doubt it is a real problem for anything other than number crunching. I like to use tcc during development (which does very little, if any optimizations) to speed up compilation and I never noticed any regressions in performance, even for GUI software. Throughput just isn't that big of a deal for most applications (although latency and resource usage is, but that's not affected by choice of compiler).

You are using C (with TCC) for GUI apps? with what GUI framework or library?

Re: Writing a Unix clone in about a month

#123

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.”

Unix was a kind of play word for Unique as an anti-thesis for Multics that latter was originally designed for modern multi-user and multi-process OS. Ironically as any real-world OS Unix eventually becomes multi-user system similar to Multics but the name stucked. Granted Unix has a very simple (as in simple as possible but no simpler) multi-user permission and security system that work reliably for many decades until now. Of all the organizations NSA actually even come up with a better replacement for the modern Unix permission and security model with SELinux, but most users just ignored and disabled SELinux although it's installed by default by many major Linux distros [1].

[1] SELinux is unmanageable; just turn it off if it gets in your way:

https://news.ycombinator.com/item?id=31176138

Re: Writing a Unix clone in about a month

#124

Earlier quoted context omitted.

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.”

Unix was a kind of play word for Unique as an anti-thesis for Multics that latter was originally designed for modern multi-user and multi-process OS. Ironically as any real-world OS Unix eventually becomes multi-user system similar to Multics but the name stucked. Granted Unix has a very simple (as in simple as possible but no simpler) multi-user permission and security system that work reliably for many decades unti…

I understood it was Unix for 'one mechanism' or 'unified' instead of the broad everything-but-the-kitchen-sink Multix approach. That was the joke I understood. Notthing about single-user.

Re: Writing a Unix clone in about a month

#125

Earlier quoted context omitted.

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.”

Unix was a kind of play word for Unique as an anti-thesis for Multics that latter was originally designed for modern multi-user and multi-process OS. Ironically as any real-world OS Unix eventually becomes multi-user system similar to Multics but the name stucked. Granted Unix has a very simple (as in simple as possible but no simpler) multi-user permission and security system that work reliably for many decades unti…

Not something that you can disable on Android, or on properly managed Linux servers, where devs only get what they should touch on.

Re: Writing a Unix clone in about a month

#126
post #60

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)

I think you mean Ken Thompson. I can't be bothered searching through youtube interviews but I'm pretty shure that on more than one occasion, he tells a story something along the lines of having a disk driver, some programs, and maybe some other components. His wife went on a trip and he figured it would be enough time to fill in the gaps and make a complete OS.

Yes. But it is written in no edit stone now. I’m sorry for the future google searches in which this received top billing instead of Ken Thompson’s name.

Re: Writing a Unix clone in about a month

#127

Earlier quoted context omitted.

I doubt it is a real problem for anything other than number crunching. I like to use tcc during development (which does very little, if any optimizations) to speed up compilation and I never noticed any regressions in performance, even for GUI software. Throughput just isn't that big of a deal for most applications (although latency and resource usage is, but that's not affected by choice of compiler).

You are using C (with TCC) for GUI apps? with what GUI framework or library?

I used SDL2. Not actively working on that project anymore, but I picked it due to requirements - fast startup, low latency, low memory usage, portability anywhere (linux on multiple distros, CPU architectures and multiple rendering backends, any Windows version from XP to 11...). C fits that very well IMO and I don't regret choosing it.

Re: Writing a Unix clone in about a month

#128
post #59

Earlier quoted context omitted.

Really??

Yep, https://en.m.wikipedia.org/wiki/Apollo_Computer https://marte.unican.es/

And TUNIS, in Concurrent Euclid.

https://en.wikipedia.org/wiki/TUNIS

https://archive.org/details/concurrenteuclid00holt

https://en.wikipedia.org/wiki/Concurrent_Euclid

https://en.wikipedia.org/wiki/Euclid_(programming_language)

Re: Writing a Unix clone in about a month

#129
post #10

Hare looks like an interesting language. Though this limitation will limit its adoption in this multicore age I think: From the FAQ https://harelang.org/documentation/faq.html .... Can I use multithreading in Hare? Probably not. We prefer to encourage the use of event loops (see unix::poll or hare-ev) for multiplexing I/O operations, or multiprocessing with shared memory if you need to use CPU resources in parallel.…

> However, the upstream standard library does not make reentrancy guarantees, so you are solely responsible for not shooting your foot off.

Well, that not only rules out multi-threading, but also usage in interrupts. Quite a limitation for a "systems programming language" methinks.

Re: Writing a Unix clone in about a month

#130
post #109

Earlier quoted context omitted.

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.

The point (for some) of writing your own OS is that you do something only a handful of people can do ...

Writing GPU drivers is not hard per se. It is impossible if you don't work at the vendor and have access to internal documentation.

Knowing how to write a kernel (which incidentally I am doing for the second time) doesn't mean you have years to dedicate to reverse engineer something as complicated as a GPU

Post reply on HN