I haven't been checking this for a while but I just checked and its getting fairly big.
http://therx.sf.net/osdev/
Pete
OSID
-
Nairou
Re:OSID
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.
Also it would be nice to be able to edit existing fields, like for clarification (what is 'DoOrS'?) or to add additional options to a list.
Also it would be nice to be able to edit existing fields, like for clarification (what is 'DoOrS'?) or to add additional options to a list.
Re:OSID
Another "feature request" - always provide two fields for entering a new password, and reject the change if the two entries don't match (to avoid typos).
Every good solution is obvious once you've found it.
-
Therx
Re:OSID
I don't know someone else added it and as they have used it I left it.What is DoRoS?
Maybe. I do delete accounts with no activity so if someone creates an account and can't get in then it will be removed and they can try again. To be honest though this site is not under dev anymore. The idea is to integrate it into Bonafide but despite sending him the OSID and offering the DB mr. xsism hasn't included it.always provide two fields for entering a new password
Pete
Re:OSID
I have seen a OS called DoOrS. But why is it a field?
-
arafel
Re:OSID
Also it would be nice if there will be more fields to chose from in dropdown menus.
i.e. more languages, compilers, targets, modes, etc.
And I suppose the DoOrS field should be removed (looks like
it were mistakenly added by someone. There is an OS named DoOrS, as already pointed out).
i.e. more languages, compilers, targets, modes, etc.
And I suppose the DoOrS field should be removed (looks like
it were mistakenly added by someone. There is an OS named DoOrS, as already pointed out).
Re:OSID
Exactly. I had problems with that in several areas:arafel wrote: Also it would be nice if there will be more fields to chose from in dropdown menus.
i.e. more languages, compilers, targets, modes, etc.
Target Platform. "Portable"? An OS is probably the must un-portable piece of software imaginable. I want to adapt my OS to several platforms, and enable the applications to be portable, but the OS certainly isn't...
Compiler / Assembler. "GCC / DJGPP"? Well, to be precise the compiler is g++ 3.3.x - which is quite different from DJGPP (gcc 2.95.3 IIRC). And that doesn't even tell the reader that I'm using GNU as (AT&T syntax) instead of NASM.
Development Platform. "Linux"? Just because I require GNU toolchain, which can just as well be set up under Cygwin, *BSD, or AmigaOS GeekGadgets?
BTW, all the multiple-choice fields should have an additional selection "undecided" for projects in their early stages.
An "aging" mechanism would also be nice, that marks entries to the OSID as obsolete if they haven't been edited in, say, 6 months or so.
Every good solution is obvious once you've found it.
-
Schol-R-LEA
Re:OSID
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.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.
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.