> Interesting; sounds a bit like a cross between {
> Debian/GNU NetBSD, Debian/GNU kFreeBSD } and
> Bluewall { http://bluewall.es.gnu.org/ }.
Since a long time I have the opinion that there should be a place
where the several free operating system developers come together
and help out in developing the several systems.
> Sounds like it could be fantastic for an OS design
> course; also, as you say, good for stable,
> heterogenous environments.
Not only in course design but also think of an "Free Software Systems
Engineering Catalog".
Imagine a collection of "HOWTO"s - I want to call
it that for the ease of discussion - for specific "appliances" on the base
of a OS - for example "KDE Office Appliance", "GNOME Office Appliance",
"E-Groupware Appliance", "Kolab Appliance" - where each HOWTO specifies
the installation, configuration and monitoring the given appliance from the
operating system to the application. And these HOWTOs are "linked" in the
catalog
to fine-grained "use-cases" as for example "financial tracking", "customer
management" or "mathematical training" (think of that as you can use a
app such as Office Calc for financial calculations but also for some
"visual" mathematics). And also in the catalog you will find "skill charts"
where the skills for installation, configuration and monitoring a OS and
userland apps are linked to the above HOWTOs so that you can by
filling in the skills chart for yourself/your employees exactly come to the
solution which "use-case" you should fulfill with which "appliance".
So you get from this catalog a true engineering catalog of "system components"
you can combine together.
This is in my opinion only possible with a "true stable" OS base with a
actual userland.
> Two problems:
>
> * different kernel-based features { zones vs other
> solutions on other OSs, zfs not (yet?) native
> on Linux, dtrace only on two of those so far,
> networking and storage management differences, ...
> };
> how do you come up with as much as possible a
> unified approach to documentation and to learning
> the alternatives?
For one the several features such as zones which are not
available for all the platforms I will leave out in the beginning.
Because my goal is to teach the basic skills over all the operating systems.
So I want to begin by listing the "building blocks" of the operating systems
such as "console", "terminal", "shell", "devices", "users" and so on
and one for one teach them (by writing unified docus for all OSes).
Someone with these basics can easily look up the OS specific features as zones.
> * base system freeze will eventually result in only
> running on museum hardware; no new drivers
> or features (at least none that don't backport with
> little or no changes to the rest of the
> respective kernel tree, unless you're compromising
> your other goals). Also, the evolving userland
> will eventually get to where it really wants
> features that the unevolving kernels won't have.
> Even > for a course curriculum, keeping the kernels
> unevolving means it will eventually be relegated to
> a _history_ of OS design course.
About the "obsolescence": There I have no great problems,
because I read, hear and "know" that the free operating systems
today can handle the actual hardware and also much older
hardware. Many businesses have chosen Linux because they could
then use some older PC for "new" use cases without buying new
HW.
Maybe, Sir, I don't understand your obsolescence problem.
Then explain it to me with some examples, please.
> The cooperation sounds interesting and possibly very
> worthwhile, although given the possibility of
> what amount to planned obsolescence (2nd point
> above), I wonder if there would be enough
> interest to achieve much there. Similar point on the
> promotion of heterogenous environments.
The cooperation part is really new. The Unix guys have
real problems with working together.
I see it as my biggest challenge to bring together the
OpenSolaris devs with the *BSD devs with the Linux devs.
But I want accomplish that. And I will be successful, I promise.
Just now, I don't know how to overcome the "hatred" in the
hearts of the users and devs alike for the other Unix-like OSes.
> A long, slow kernel update cycle (with snapshots of
> the then current kernels being used as a
> starting point only once the first multi-kernel
> distro is out and stable) might address the
> obsolescence issue, while still honoring the other
> concerns. It would also ensure that the
> opportunity for improving cooperation would be in
> depth and open-ended.
I want to start a "backporting" of actual drivers to the
"kernels" existent in Menhir.
With a "frozen" base system the testing will be easy I think
AND
The real interests in (home) users and developers are in
application land today I think.
So with this I can create maybe a stable development platform
for actual applications.
> I think that if you could engage as many Austin Group
> (http://www.opengroup.org/austin/)
> participants as possible, you could at once work for
> more uniform standards compliance among
> heterogenous implementations, and yet also for more
> dynamism (albeit the responsible sort) in
> the standards process itself.
> How's that for an initial comment? :-)
Thank you for your thoughts and for writing them here.
regards
Gueven
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
