Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Projects incompatible with the GPL: I'm aware of several efforts where GPL code was not allowed to avoid having to meet GPL obligations.
You get centuries worth of man-hours for free, and you are explicitly allowed to stack non-GPL code on top of GPL. Pretty much every company in the hardware industry that believes it has something to hide does it this way.
Processors with unusual architectures that would require significant porting efforts.
In no way or form does that imply you can't use anything from the Linux sources. In fact, being multitargeted already makes Linux a much easier subject for porting in general.
Operating systems that strictly serve as execution environments for bytecode interpreters: verified code platforms, Javacard implementations, SDR platforms, etc.
Android, ChromeOS
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Combuster wrote:You get centuries worth of man-hours for free, and you are explicitly allowed to stack non-GPL code on top of GPL. Pretty much every company in the hardware industry that believes it has something to hide does it this way.
I'm not saying it's always the right decision, I'm just saying it happens, and not infrequently. Interpreting the GPL is actually pretty tricky since it has a very limited case history, and some legal departments say "I'd rather not risk it".
In no way or form does that imply you can't use anything from the Linux sources. In fact, being multitargeted already makes Linux a much easier subject for porting in general.
Operating systems that strictly serve as execution environments for bytecode interpreters: verified code platforms, Javacard implementations, SDR platforms, etc.
Android, ChromeOS
Right well I'm not really interested in a pedantic argument about whether or not Linux can do X. Of course with enough effort Linux (or anything else for that matter) can be used for whatever you want. My point was just that there are many real-world scenarios where Linux is not automatically the best choice. Specifically I was responding to the following statements:
There IS a one-size-fits-all operating system. It's Linux.
So? It's fun to look at different designs and fiddle around with them and consider new concepts in operating systems, but it goes without saying that these "fun projects" are never going to beat Linux when it comes to use in the real world.
Right well I'm not really interested in a pedantic argument.
Then I suppose it wasn't a good idea to make it look like Linux is automatically the worse choice, and we'll leave it at that
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
iansjack wrote:What about real-time applications; are you familiar with them?
No, but you can compile Linux for increased real-time support.
I just wanted to chime in here. We use Red Hat Linux on my ship's Sonar system, which is a real-time system. And it is an absolute, unmitigated nightmare. The RT support that Linux has is nowhere near good enough to run time-critical applications without needing to be reset every 2-4 hours (at best), and also loses data on a regular basis - just *poof* into the aether.
There is no one-size-fits-all OS. Period, end of story.
Lithorien wrote:The RT support that Linux has is nowhere near good enough to run time-critical applications without needing to be reset every 2-4 hours (at best), and also loses data on a regular basis - just *poof* into the aether.
Then run it through an appropriate debugging tool, figure out why it needs resetting every 2-4 hours and why it's losing data on a regular basis, and patch it. Also if you're using stock Red Hat Linux you won't have a real-time kernel; I assume you've already installed a real-time kernel?
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
