It was just about time, considering there was a jestful tricking the developer of relayd to reprogram it to httpd. IIRC he got epic tricked into it! In the sense he didn't even know he was making a webserver until he actually made it. This may not be a very true version, but I love to believe so.
The camaraderie and passion in the project is mind boggling.
This file is a public interface exposed by Linux to other programs. So what if Linux caches its contents when eg. Python interpreter on launch will read this file. And it's not coming from some "fake" filesystem like procfs or sysfs. It's an actual physical file most of the time.
Thank you! That would be me. I am clueless on amd64 on how to speed up the boot process and maybe change a few fonts during boot.
I understand the reasons for no "how-tos". But sometimes they make sense for people like me. I wouldn't mind delving a bit deeper given some direction.
The first thing you'll want to do is port my TSLOG code to the OpenBSD kernel and start instrumenting things there. Send me an email, there's too much detail to get into for an HN comment.
I am not a programmer (yet). I am an openBSD fanboy. I've read stories of people reading the code and raving about the quality. It does tick 2 of the checkboxes you mentioned (not just one person). Does this qualify?
I needed to learn how a very specific OS thing worked and I read the code from Linux, openbsd, L4, hurd, minix, and a few other projects.
The openBSD kernel code was easiest to follow because it favored simplicity over all other things (improved security was just a byproduct).
For the record, the microkernels where hardest to follow despite having tons of books and a few experts nearby. But that's a whole different discussion
Yes, I think so. Being written by one person isn't a hard requirement, it's just that I feel like you get a better sense of programming style and someone's approach to problem solving when you read code that hasn't been touched by too many people.
Projects with a maintainer who strictly enforces code style and quality would still fit the description. From what I've heard, OpenBSD falls under this category. I'll add it to my list.
If people are interested in looking at Unix kernel implementations: Open Solaris code is out there, too. Now, i haven't looked at it myself (not a kernel hacker) and it's more like the exact opposite of a one person effort, but i heard praises about its alleged code quality more than once. So it might be educative (as far as the design of a commercial Unix kernel goes).
Vulkan seems to be incomplete. Graphics drivers for Nvidia are a problem due to the project not accepting blobs, not signing NDAs. And today I had a problem installing matplotlib (ninja gave some error). AFAIK, tensorflow and/or python libs are a problem with *nix as well.
My first reaction to your comment was that it was probably missing a "/s" at the end.
Rationale - I last did HTML when Netscape Navigator/ Communicator was still around. IIRC, usual discussion among us college students was how MS IE encouraged bad programming practices by ignoring (many?) unclosed tags, whereas Netscape wasn't as forgiving.
I've not seen much HTML since then (I definitely plan to, now). Your comment brought back some fond memories. Thank you! And mind blown.
The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. [0]
Edsger W. Dijkstra
CONTEXT:
Argument three is based on the constructive approach to the problem of program correctness. Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. Argument three is essentially based on the following observation. If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof’s requirements, then these correctness concerns turn out to be a very effective heuristic guidance. By definition this approach is only applicable when we restrict ourselves to intellectually manageable programs, but it provides us with effective means for finding a satisfactory one among these.
[0] Edsger Dijkstra - Turing Award Lecture - The Humble Programmer - 1972
What I love about openBSD documentation is that if it's not there in the docs, one can be sure that it doesn't exist.