DaemonForums  

Go Back   DaemonForums > Miscellaneous > Off-Topic

Off-Topic Everything else.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 30th January 2015
fn8t's Avatar
fn8t fn8t is offline
Real Name: Ego
Shell Scout
 
Join Date: May 2014
Location: Tao
Posts: 120
Default Exokernels and Rumps

These two kernels are completely different. I am just putting two small points of interest into one post.

I was thinking about embedded platforms and the monolithic kernel style used on many of them. Then the idea of a platform that rather then installing your base OS, it built your exokernel environment per specifications made during installation. Your entire system micro-configured during installation (beyond the configurations required by a monolithic kernel). There are monolithic models that allow you a very similar setup already. But, the dynamics of an exokernel would require such a different development and installation (designed for modular audience needs). Would the extra bare metal of the exokernel be worth all that development? Should such a kernel only be developed when it is actually needed. Or, could the a large variety of useful implementations be developed into a operating system distribution? I have nothing interesting to really throw out about this, but just mentioned it due to the moment of awe I entertained.

On a completely different level of applicable employment, I was looking into NetBSD Rump Kernels. Do you think this innovation is going to get any gas?

It kinda reminds me of the pkgsrc initiative. It seemed like one of the drives behind pkgsrc was to get some unified development from package maintainers of different systems. Kinda like saying, "This isn't just for NetBSD, its for everyone", "But, we're in charge". This hasn't worked out so well, as far as I can tell. Dragonfly forked their own package manager rather than stay with pkgsrc. Even though the source files of packages are all the same and all that needs be done is writing patches per your systems specific installation requirements. Dragonfly said "Nah, we'll do this on our own". I actually don't know why it went down that way. It was probably a very reasonable and productive decision.

I'm not saying that Pkgsrc maintainers are disappointed. Many NetBSD users I've conversed with seem happy with the pkgin binaries that are already available, even though some packages available for compilation via pkgsrc are not available in binary repositories. But, it does seem like the same kind of initiative behind the thinking of NetBSD's projects. There is a big difference between cross availability of drivers and a unified package manager. That's just what came to my mind, anyway. Any thoughts?
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 09:42 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick