There are two main kernel architectures for large operating systems; monolithic and micro. While these architectures are well thought out, well implemented (usually), and well understood, they have their faults. Mainly, the loading of modules and executables, management of memory, and interfacing between the kernel and software cause these architectures to be vastly complex. With this complexity comes a loss of speed and increased difficulty for the developer. There are other kernel architectures, such as the exokernel, that are vastly different from traditional architectures, but they still have performance issues caused by userland processes.
Post a Comment
Member since:
2007-05-31
Member since:2011-01-28
krtekz,
I am tired of most of the mobile device coverage too, but you know what? I notice those articles get a lot more comments than these articles do. Granted, that's probably because the fanboys/trolls jump all over them, but we have to face the sad possibility that maybe the real technical articles aren't very appealing to most osnews readers.
If I could make a good living writing technical articles, I'd have a blast with it, but I don't think the money's there. If I'm wrong: Thom please contact me, I'm sure I can help cover some fascinating technical subjects 
Member since:2005-07-14
I also like this article and the way the author manages to get the technical details across without alienating me. Yes sometimes it is better to explain it to me like I am a 5 year old.
Boo to all the coverage the patent wars seem to get on OSnews. Bring back well written and easily understood technical articles.
Edited 2011-12-30 12:43 UTC
Member since:2010-10-05
Member since:1997-10-01
Believe it or not, we agree with you. We encourage readers to turn us on to interesting new projects, and we welcome submissions of articles.
Of course, a lot of readers also care about mobile and legal issues too, but we'd certainly like to publish more about alternative, experimental, and new OSes too.
Member since:
2011-01-28
First off, thanks for the technical article, these are why I come here.
"Dreckig (German for dirty, or messy) is a real-mode operating system designed for simplicity and performance."
REAL-MODE?? Was that a misprint? Do modern compilers even generate that? I can't think of one good reason to target real mode these days.
"Multitasking becomes very impractical when only one process can execute. Workarounds can be written to do multi-threading and run different parts of the kernel at the same time, but this can lead to memory protection errors."
Even if multitasking can be added, it would be very difficult to run more than one instance of any utility as designed.
I'm not clear what's the technical difference between the "front end" and "back end", but it's odd that the shell is a backend component. Ideally it would just be another application.
I'm having trouble seeing what benefits this OS offers over others. Sure, loading a single file into RAM can be extremely fast, but that's easily replicated by using an "initrd" image under linux.
I appreciate that almost all operating systems start out this way before they have real file systems, and that's ok. But in the course of their existence they typically evolve to support dynamically loadable applications, it seems odd to stop with this design. Does Dreckig have any other strengths?
Member since:2011-12-30
I'm looking at the source code right now, and it is definitely 16-bit, real mode. It's... kind of refreshing, actually, in a way.
To the author, it might be nice to have some documentation as to your build process, for those of us who haven't dealt with this sort of thing in a while. 
Member since:2005-12-31
REAL-MODE?? Was that a misprint? Do modern compilers even generate that? I can't think of one good reason to target real mode these days.
Especially not if simplicity is a goal. Switching to protected mode is rather easy. I'd bet there are a lot of copy-this-code examples that you could just use (dunno, when I wrote my hobby OS I wanted to understand how it works, then wrote that one page of code myself), then have a flat, non-mapped 32-bit address space. That real mode segment juggling isn't really "simple" when you actually try to code something.
Member since:
2007-11-09
This type of design is a nightmare for security. Putting common user land tools into the kernel makes it far too easy to miss something and open up a gaping hole.
Part of the reason we go through all the complexity with a micro kernel or even a well designed monolithic kernel is privilege separation.
Member since:
2010-05-14
Member since:2011-01-28
RichterKuato,
"Why even have a kernel? Why not just make a direct to hardware application? or make the whole application firmware. That's what I'm sort of interested in. I believe that's how a lot of electronics used to be made."
osnews covered baremetal os a while ago...
http://www.osnews.com/story/24616/BareMetal_Node_HPC_kernel_in_6KiB
The idea is to write apps to run directly on hardware, but the OS aimed to eliminate the need to reinvent the wheel when it came to initialising the runtime. It also came with some networking support.
The problem with running custom apps in firmware is that firmware isn't portable, the specs are closed, and it's may not be possible to recover from a bricked system. Not that I haven't wanted to do it.
Member since:
2009-10-04
Very interesting. I'm glad to see more actual OS news on OSNews.
However, this is pretty pointless if it is only in real mode. If the purpose of this architecture is to get speed and simplicity, this is ridiculously stupid. You have to jump through hoops to code for real mode, and it's going to be slower anyway. Not to mention that you can't do real IO (IIRC) and have to rely on super slow BIOS interrupts...
Member since:2011-01-28
Zifre,
"However, this is pretty pointless if it is only in real mode. If the purpose of this architecture is to get speed and simplicity, this is ridiculously stupid. You have to jump through hoops to code for real mode, and it's going to be slower anyway."
Yep, I cannot think of a single good reason to design an OS around real mode today. 64K segments are a major impediment for any real load - unable to represent even a single bitmap without mucking around with intra-segment hacks. Even if those are overcome, you're still limited to some 640K of base memory.
Of course you can use "flat real mode", so the 64k limit is removed. But that implies switching to protected mode and back, why not just use protected mode?
"Not to mention that you can't do real IO (IIRC) and have to rely on super slow BIOS interrupts..."
It's not necessary to use BIOS interrupts in real mode any more than it is from protected mode. The only IO problem you'd have is reaching memory mapped devices that aren't mapped within the first 1MB.
Member since:
2008-07-12
I remember when reading about SmallTalk-80 that the compiler and all the source code was included as one transparent package.
Can this system operate the same way? Thus when ever you need a new application added you just compile it into the kernel. Now additional major thing I remembered is that ST-80 worked with snapshots so if the newest version messed up the system you could just revert back to before you made any changes in the code.
Edited 2011-12-29 02:51 UTC
Member since:
2006-12-06
Member since:
2006-01-06
Member since:
2009-04-17
Member since:2007-08-20
Member since:2005-07-06
Sorry, but it's NOTHING like the A8 OS. The Atari had a rather sophisticated OS - everything was a device that you would open and send commands to. The screen was the 'S' device, the full-screen editor was the 'E' device, the cassette was the 'C' device, and so on. Programs were loaded from (floppy) disk or cassette like a normal OS, and called the OS through a central vector table. Clearly, there was no sense of user vs kernel because this was a 6502, but it was nothing like how this 'Messy' OS is described.
Member since:2007-08-20
I was talking about the basic concepts, not implementation specifics.
The two main ways of running programs on those old systems are BASIC "programs" and ROM cartridges. The cartridge ROM is simply mapped into the "kernel" memory space, and BASIC programs are run by a built-in (i.e. "kernel") interpreter. There was no differentiation between kernel and user space (memory, processor modes, etc.).
BTW, I found your information about the 8-bit Atari OS very interesting. I never had an Atari 400/800, and I love learning about these old systems. Sometimes they had very elegant solutions.
(The article didn't seem to specify much about how device drivers and such would work in Dreckig OS, so I'm not sure if there are similarities or not.)
Member since:
2006-03-23
Like other users, I'm pleased to see more OS oriented news on OS news, although I understand the purpose of the other non-OS related articles (chiefly to draw traffic...).
Since 'the cloud' is all the rage these days, I think it would be cool if the OS pulled config/customizations/etc from there. I'm guessing networking isn't implemented yet as it wasn't discussed, but it would be interesting to have a unique OS lightly coupled with the cloud, even if only academically.
Member since:
2008-01-09
Member since:2005-11-16
Hi,
Often the primary goal of an OS like this is for the author to gain experience. From this perspective, you can say the design wasn't flawed and the OS has met it's primary goal.
- Brendan
Member since:2008-01-09
"I think the project might be a little be flawed by design... well, judging it by this quote of yours at least.
Often the primary goal of an OS like this is for the author to gain experience. From this perspective, you can say the design wasn't flawed and the OS has met it's primary goal.
- Brendan "
The experience gained by working on this concept and seeing what it does well and what it does not is invaluable, you are correct and we agree on it.
I should have said "the architecture of the OS" instead of the project perhaps.
Member since:
2005-07-18
This is common in the embedded world.
In fact, I'm currently using Quadros, which is essentially the same concept.
http://www.quadros.com/
Member since:2009-05-05
Member since:
2006-03-20
Member since:2009-03-17
Member since:
2005-07-06