[unios] A monkey wrench....
Faustino E Osuna
osuna@CTC.Net
Mon, 28 Dec 1998 16:18:58 -0500
From: Faustino E Osuna <osuna@CTC.Net>
This is a multi-part message in MIME format.
------=_NextPart_000_001C_01BE327D.C5FC4E20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I know this throws a monkey wrench into the brainstorming process, but =
has it occurred to anyone of creating multiple kernels? Maybe even =
dynamically loadable kernels (DLK)? Where once the OS starts up, it =
fires up the UniKernel (default kernel) then according to the needs of =
the individual application, it would load the associated kernel? Or the =
user (not the application) has the ability to unload and load a kernel =
on the fly. Or give the user the option of starting up with something =
other than the "UniKernel", a kernel specifically designed for their =
overall wants and demands.
I would think the latter suggestion would be more feasible. Having =
DLK's being loaded and unloaded every time the application runs would be =
somewhat redundant. Instead, there should be multiple kernel =
architectures that allow the user to reap the most benefits from his/her =
system. Of course, one major issue to this system would be the =
interface between the kernel and the application. There must be a =
standardization (ugh I hate standards).
A good example of this would be, that a business might want to dedicate =
UniOS system entirely for networking purposes (lets say a print server). =
They load the appropriate kernel that allows the application(s) and the =
network to benefit the most from the system (High-security and moderate =
speed). But on the other hand, we a home-user (like the most of us) who =
wants UniOS' power as well but the security doesn't have to be as high =
but the speed is a must or flexibility.
In my novice opinion, this would make UniOS more diverse and flexible. =
But it just might defeat the entire purpose.
Just an idea to chew on, I apologize for not elaborating too clearly. =
Of course ideas, suggestions, gripes...etc are welcomed.
- Enrique
PS - I haven't formally introduced myself, I'm Enrique expert slacker.
------=_NextPart_000_001C_01BE327D.C5FC4E20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
I know this throws a monkey wrench =
into the=20
brainstorming process, but has it occurred to anyone of creating =
multiple=20
kernels? Maybe even dynamically loadable kernels (DLK)? Where once =
the OS=20
starts up, it fires up the UniKernel (default kernel) then according to =
the=20
needs of the individual application, it would load the associated =
kernel? =20
Or the user (not the application) has the ability to unload and load a =
kernel on=20
the fly. Or give the user the option of starting up with something =
other=20
than the "UniKernel", a kernel specifically designed for their =
overall=20
wants and demands.
I would think the latter suggestion =
would be=20
more feasible. Having DLK's being loaded and unloaded every time =
the=20
application runs would be somewhat redundant. Instead, there =
should be=20
multiple kernel architectures that allow the user to reap the most =
benefits from=20
his/her system. Of course, one major issue to this system would be =
the=20
interface between the kernel and the application. There must be a=20
standardization (ugh I hate standards).
A good example of this would be, =
that a business=20
might want to dedicate UniOS system entirely for networking purposes =
(lets say a=20
print server). They load the appropriate kernel that allows the=20
application(s) and the network to benefit the most from the system=20
(High-security and moderate speed). But on the other hand, we a =
home-user=20
(like the most of us) who wants UniOS' power as well but the security =
doesn't=20
have to be as high but the speed is a must or flexibility.
In my novice opinion, this would =
make UniOS more=20
diverse and flexible. But it just might defeat the entire=20
purpose.
Just an idea to chew on, I apologize =
for not=20
elaborating too clearly. Of course ideas, suggestions, =
gripes...etc are=20
welcomed.
- Enrique
PS - I haven't formally introduced myself, I'm =
Enrique expert=20
slacker.