I've always enjoyed the practical research and projects that happen at the CalPoly schools, my friends who attended always seemed to be doing some very neat hands-on work.
Anecdotally, my occasional interactions with Linux kernel source code have always impressed me with how the project manage to effectively structure such a large C codebase. Until I look at FreeBSD code, which is even more impressively organized. Both of these projects have really helped me think about how to best organize huge complicated systems.
I'm also curious about what impressed you. Most of my interactions with Linux code have been trawling through either crufty or just poorly-written subsystems/drivers because they're causing me problems, which I realise is a bit of a biased sample.
If that were the Windows source, you wouldn't have been able to find it. Parts of the "driver" would be found in seventeen different systems, using seventeen different styles of coding, using macros that look the same but act differently in different files, leaving the driver as nothing more than a side-effect of the whole.
I was working with network drivers and the core network stack. I've heard bad things about questionable device driver implementations, I could only imagine what you saw.
If you're willing to share I'd be interested in hearing more about what you learned. What is it about those two codebases that you've used to inform your own choices?
The kernels are pretty sizeable and pretty specialized pieces of software so it's kinda fascinating that useful lessons for other projects could be extracted from it.
I did an internship where I had to write fake network devices to test some server platform firmware configuration. I spent a bunch of time digging around the core PCIe code and Linux network stack. The first few weeks were a bit overwhelming but by the end of the internship I was really impressed with how clean and relatively understandable the interactions between userland, kernel space, and hardware operations were. It really made me aware about the importance of deliberately designed API surfaces that are critical to millions of users.
I also enjoy C programming, and it was interesting to see how the developers built out such a complex system without the more friendly programming language structures that I was first exposed to in school (mostly C++ and Java).
Wow, this has been submitted exactly twice: today -- and 17 years ago.[0] (No comments then either, probably because there isn't too much to say? Even the work itself draws pretty tepid conclusions.)
WRK is basically void of drivers which is where all the pain generally is (and also where comparative survey may be kind of interesting, both the OS APIs and subjective quality? at least to me..). I am not sure if that is reflected on the others where they will dominate SLOC.
Doing a comparative survey on this justice would be a monumental undertaking, there's just not much to see here - some counters and statistics and box plots don't seem to work here.
I've always enjoyed the practical research and projects that happen at the CalPoly schools, my friends who attended always seemed to be doing some very neat hands-on work.
Anecdotally, my occasional interactions with Linux kernel source code have always impressed me with how the project manage to effectively structure such a large C codebase. Until I look at FreeBSD code, which is even more impressively organized. Both of these projects have really helped me think about how to best organize huge complicated systems.
I'm also curious about what impressed you. Most of my interactions with Linux code have been trawling through either crufty or just poorly-written subsystems/drivers because they're causing me problems, which I realise is a bit of a biased sample.
If that were the Windows source, you wouldn't have been able to find it. Parts of the "driver" would be found in seventeen different systems, using seventeen different styles of coding, using macros that look the same but act differently in different files, leaving the driver as nothing more than a side-effect of the whole.
... I might not miss that codebase.
And don't forget the brainf*k hungarian notation...
I was working with network drivers and the core network stack. I've heard bad things about questionable device driver implementations, I could only imagine what you saw.
If you're willing to share I'd be interested in hearing more about what you learned. What is it about those two codebases that you've used to inform your own choices?
The kernels are pretty sizeable and pretty specialized pieces of software so it's kinda fascinating that useful lessons for other projects could be extracted from it.
I did an internship where I had to write fake network devices to test some server platform firmware configuration. I spent a bunch of time digging around the core PCIe code and Linux network stack. The first few weeks were a bit overwhelming but by the end of the internship I was really impressed with how clean and relatively understandable the interactions between userland, kernel space, and hardware operations were. It really made me aware about the importance of deliberately designed API surfaces that are critical to millions of users.
I also enjoy C programming, and it was interesting to see how the developers built out such a complex system without the more friendly programming language structures that I was first exposed to in school (mostly C++ and Java).
Note that Diomidis is at AUEB, not CalPoly.
Wow, this has been submitted exactly twice: today -- and 17 years ago.[0] (No comments then either, probably because there isn't too much to say? Even the work itself draws pretty tepid conclusions.)
[0] https://news.ycombinator.com/item?id=194927
I think we were all just hoping you (or another guilty party) would comment on this.
WRK is basically void of drivers which is where all the pain generally is (and also where comparative survey may be kind of interesting, both the OS APIs and subjective quality? at least to me..). I am not sure if that is reflected on the others where they will dominate SLOC.
Doing a comparative survey on this justice would be a monumental undertaking, there's just not much to see here - some counters and statistics and box plots don't seem to work here.