Nairou wrote:
I wish the account username and the OS name didn't have to be the same. I had to create a second account when I realized I couldn't change that.
I agree on this; the setup is pretty confusing. Also, it doesn't take into account that a) a member may be part of more than one project, and b) more a project may have more than one active member.
The fact that it limits the choice of languages to C, C++ or assembly is displeasing to say the least. The fact that assumes only one development language is also a potential problem.
'RISC'? Which RISC chip do you have in mind, PowerPC? Alpha? MIPS? ARM/XScale/Jaguar? For that matter, SPARC is a RISC design as well; why have a separate listing for it?
I disagree with Solar regarding portability, however. Portability is not a binary distinction; otherwise, virtually no non-trivial program could be considered portable (the fact that very few
are portable is a design factor, not an inherent issue; most packages could be designed to be largely portable if the designers chose). A large portion of an OS can in fact be portable, even though the whole cannot be, and designing an OS for ease of portablility is a goal that strongly affects the design. From one estimate I've heard, roughly 60% of the Linux kernel code is common between different platforms, and the percentage rises with non-kernel functions - pretty much only basic functions such as context switching, paging and low-level device drivers are system specific. The code bends over backwards to allow this - the Linux
kprintf() function, for example, does not access the console directly, and in fact can be redirected to any console it is connected to (most of the function is in fact devoted to logging the messages printed with it; chapter 2 of
Linux Core Kernel Commentary discusses the function in detail, as an example of the coding style of the kernel). This is admittedly a large part of why the Linux kernel is both so large and so difficult to read, but it makes implementing the system on a new platform relatively straghtforward.
Solar has already mentioned the problems with the 'Compiler/Assembler' listing. There should definitely be a separate listing for these two items, anyway, for as Solar points out, using a given compiler does not imply use of a given assembler.
Why does the kernel image file type have a separate listing for DWARF (a debugging variant of ELF), but not PE (the variant of COFF used by Windows)? PE is probably more widely used than original COFF is (for Windows compatibility), whereas I don't know of any OS which targets DWARF as it's
primary format.
The comments field (actually, 'Description' might be a better term, given how it is used) should be larger, I think; what you need for that is a textarea (not a textbox) that snaps to fit the page width, and is at least four lines deep. This is especially important since so few of the other fields are free-format.