Linux-Misc Digest #563, Volume #25 Fri, 25 Aug 00 19:13:02 EDT
Contents:
Re: Linux, XML, and assalting Windows ([EMAIL PROTECTED])
Re: Operating system file name restrictions? Where? (Jon Guyer)
Re: splitting files compatible to linux and winnt (Fabian Gebhardt)
Re: How do you pronounce GNOME? (Andrew Stephenson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.os.linux,comp.text.xml,comp.os.linux.setup
Subject: Re: Linux, XML, and assalting Windows
Date: Fri, 25 Aug 2000 22:40:10 GMT
Okay, let's try again.
Suppose you wanted to provide a computer system configuration
management facility that:
* Does not require developers to deliver anything more than their
own software
* Supports a single, separate Software Rendering Facility
* Maintains a meta model of the software rendered in the computer
system
* Supports all OS platforms.
* Supports all software in the same way (OS, Drivers, apps, etc.)
* Possible to not require the OS to be operational
* Allows configuration fixes to be formally defined
* Allows such fixes to be accessed over the web
* Allows such fixes to be applied automatically
* Allows setup options to be recorded and managed.
* Allows configurations to be simulated for debugging purposes.
* Allows interactions between software to be formally defined
* Allows interactions to be accessed over the web
* Allows interactions to be managed automatically
* Can express a product differently based on platform
* Can express a product differently based on role.
* Can be used to express a range of products
* Can be used to define distributed systems
* Only requires support for features needed by the target system
* Can be used in pervasive systems.
* Can be built on open standards
Let�s try to discuss what it is going to take to make the above
happen. This is complicated, so to make discussion simple, I have
noted 26 points (marked with *** in the text, and zero based). Let�s
beat these to death and make a call whether we accept them or not.
If we get past all 26 points, then we have the design. Then (IMHO) we
only have to make it happen, and then we can claim we changed the world.
*** (-1) XML
This is not a point to argue. Some of you don't like XML. Fine. XML
is simply a way to describe structured data. So is a database.
Nothing magic. XML is text and thus fluffy. Another "no big deal"
given that compression techniques are well understood. And XML is an
extensible standard well suited for Web delivery. Still, any kind of
file can be delivered over the Web, so again: nothing magic!
If it saves you some heartburn, substitute your favorite structured
data format for any reference to XML. Just make sure references between
elements, variables, and nested paths to external structures are
supported. We also need to be able to easily (by some documented
standard) be able to render your representation into other, arbitrary
structured representations. So if you have something better than XML
with this feature set, great.
I happen to believe that XML provides what we need to do this task, its
an open standard, it's simple, and so just go with it. But it isn't
magic either. So let's try to focus on the feature set!
*** (0) First and foremost, we need this feature set!
We are getting more platforms. Some of us want to use Linux. Others
want Linux to be part of vast distributed, Internet base applications.
These things are devilish to setup and configure, and as more platforms
and faster platforms are rolled out, we need to be able to configure,
reconfigure, configure again, develop more, deploy, etc. faster,
better, across more platforms than one can imagine! Cars, palm pilots,
shirts, streets, dog collars, laptops, and airline seats! Our
applications are going everywhere!
How are we going to do this without this feature set? Point Zero is
this: We have to have this feature set! It is not an option! (well,
IMHO anyway...)
*** (1) All software requires and only requires a processor, memory,
I/O, and storage
Keep you sights on our target! Many Operating Systems on many
platforms, running many different versions of abstraction layers we
might not have even yet defined!
If our solution is going to support all Operating Systems, be simple,
possibly run independent of the OS, etc. then we have examine the very
basic, common nature of all current computer systems. At their core,
computer systems are constructed from only four basic resources:
Processor
Memory
Input/Output
Storage
All programs, operating systems, drivers, etc. are software. They are
computer programs. These are the only resources a computer program can
possibly require. All other resources we talk about are nothing more
than abstractions built on top of these basic four.
*** (2) A computer system is properly configured if and only if its
storage is properly constructed.
The observation to make is that storage is the sweet spot of control
for computer systems. Storage is the only thing left once the computer
system has been powered down. If the computer is off, you have no
processing, I/O, or memory. Only storage. Any Software we expect to
be able to use when the system is turned back on *must* reside solely
(and properly) in storage.
*** (3) All software is limited by the nature of computation.
No program can be written outside the four resources listed above.
Only these four resources are needed, and always this four. Get the
representation in storage correct for any program, and it will execute
properly. Get it wrong, and it doesn�t work.
*** (4) Abstractions are useful, but will not deliver our feature set.
Today we mix the software and its configuration management using
install programs and facilities of various designs. They all depend on
the OS and services of a given computer system. We construct layers of
abstractions through Operating Systems, languages, libraries, services
etc. in order to build more and different resources types out of the
basic four. The thicker we layer on the abstractions, the better
things work� so long as the abstractions themselves are installed
sufficiently well to be operational. (I am Ignoring that little side
issue of performance � Performance is *not* a point to argue here!)
We find ourselves limited by the �resource abstraction� approach,
however. Different platforms define different services, interfaces,
and other abstractions. Approaches like Java work, but not when
different implantations and versions begin to conflict with each other.
Besides, abstraction layers require software and developers to buy into
using them, and to build software to implement and use the resource
abstractions.
I might be wrong, but I have not seen any new abstraction models that
cover all the ground we are aiming to cover here!
Still, resource abstractions are very, very useful. This is what
operating systems do. They (and their services) define a set of
resource abstractions that divide the basic four up, making software
development possible.
Bottom line, abstractions are tied to operating systems and services,
and cannot by nature provide support across platforms and independent
of platforms.
*** (5) Defining software in abstract using XML, and rendering that
software into a representation in storage is a
fundamentally different approach from what we are doing
today.
This design separates the abstract representation of software from the
process of rendering it. The rendering engine belongs to someone other
than the software developer. The software developer must expose to the
rendering engine the constraints for how to construct a valid image
within their supported platforms. The feature set of the Software
Rendering Facility becomes consistent across all software delivered
using the Facility.
There are many aspects of this design that make it very different from
what we are doing today. Most are pretty obvious. Especially the way
we encode the structural requirements into install packages. When we
have problems, we have to uninstall and reinstall to access this
information! Very Annoying!
*******
Still with me? Great! We have the theory (or not!) Now we can
examine whether the theory can be applied successfully to get us our
feature set!
*** (6) Does not require developers to deliver anything more than their
software
Developers would use something like XML to describe what should be
constructed in storage to properly "render" their applications. This
amounts to Files, Environment variables, entries in configuration
files, directories. And possible references to other software that may
be required. (The developer does not have to define this other
software, just reference it.)
A file system is nothing more than structured storage. I believe most
will agree that XML can indeed be used to define structured storage. I
guess someone could argue that a file system is not structured data, or
that a file system is the one structured data form cannot be described
by XML. Such arguments would be pretty stupid, however.
One could argue that file systems are so strange that describing what
changes are required to install an application is nearly impossible.
Yet programs really only require a set of files, directories, registry
settings, and a few configuration setting changes. Even the most
complicated installs don�t amount to too much more than that.
Assuming that some facility can be used to render the developer's XML
representation of their program into storage, there is no reason the
developer should add anything to their XML other than information that
is directly useful to produce a proper rendering of their software into
some target computer system. And if they do add additional
information, the tagged format of XML allows such information to be
easily disregarded.
*** (7) Supports a single, separate Software Rendering Facility
The idea of XML (XSL, XSLT, and XPL) is the belief that the abstract
definition of structured information can be automatically rendered into
a (often more limited and refined) structured representation. The
resulting representation takes the limitations of the target format and
other factors into consideration.
Today XML is used to do this for web pages accessed over phones in
Japan. The format required for such devices is far different than that
provided to full browsers. Yet the same information is rendered into
representation appropriate to both, on the fly.
I guess someone might argue that file systems are far more complicated
than user interfaces. Or that managing and merging of documents is
simple compared to building directories and copying files, making
registry entries etc. I really don�t think this is the case. File
systems are really far more simple.
XML is being used today successfully to manage UI representations and
to build and blend representations of information into documents. It
could be used to do the same for storage.
In information processing applications, the XML defines the data in a
form separate from any number of rendering facilities such as XSL,
XSLT, XML parsers, and other tools. Furthermore, these tools operate
on hosts of data from different XML sources. This all sounds like the
same problem I am writing about, only the target (storage) is different.
I am not aware of any factor involved in defining software and file
systems that poses a significant problem to building a single Software
Rendering Facility.
*** (8) Maintains a meta-model of the software rendered in the computer
system
Once the XML for a software component has been used to render it within
a computer system, it does not have to be discarded. This XML (along
with a record of what changes the Software Rendering Facility made on
behalf of this software) can be retained in order to manage the system
through time.
It may often be the case that software that is to be available not be
rendered into a computer system at all times, but rather on demand. A
Meta-model of the computer system�s configuration is key to this type
of concept.
*** (9) Supports all OS platforms.
All the major OS platforms have the same, basic storage
representations. Yet even if they didn't, they still must structure
their storage in some way. And XML can be used to define whatever that
structure should be. And yet, at the same time, XML can be used to
define what storage should look like on NT and Linux as well.
Of all the issues one might have, the idea that a single XML definition
can define storage for any given target platform seems to be pretty
easy to accept.
*** (10) Supports all software in the same way (OS, Drivers, apps, etc.)
All software is software. It has to reside in storage somewhere, in
the form of files, registry settings, directories, etc. To manage
different types of software in different ways is simply arbitrary and
artificial. In fact, to get to a difference one has to get all the
abstractions up and running before you start trying to manage the
computer system.
Attempts to manage a computer system from within its own abstraction
model (as defined by its Operating System and Services) only adds to
the complexity, problems, wasted time, expense, etc. of managing the
computer system�s configuration.
Whether literally or logically, the approach described here manages the
storage image outside the abstractions defined by the target computer
system.
*** (11) Possible to not require the OS to be operational
Managing only storage reduces the minimal configuration required to
manage a computer system. If storage is completely defined and managed
using XML backed software, then the only thing that has to be
operational is the file system and the Software Rendering Facility.
Bootstrapping can be used to reduce this minimal configuration
further. (First the Software Rendering Facility makes sure the
computer system boots, then it runs its more complex operations on top
of a working Operating System)
*** (12) Allows configuration fixes to be formally defined
Configuration fixes are changes to storage. XML provides a means of
providing a formal definition of such fixes. These are changes to the
file system, registry, etc. This is storage, and as such it can be
defined in abstract using the tags and references the developer's have
defined in the XML definition of their software.
I see no big problems to formally defining configuration fixes using
XML.
*** (13) Allows such fixes to be accessed over the web
XML over the Web. Do we really have to argue this one?
*** (14) Allows such fixes to be applied automatically
If the fix is delivered in XML, applied to the storage configuration as
defined by the XML of the installed packages, the installation should
be automatic. This is aided by the idea that the Software Rendering
Facility maintains a meta model for the computer system through time.
*** (15) Allows setup options to be recorded and managed.
The options one sets today as one installs are nothing more than
decision points in determining how the application should be rendered
into storage. The abstract XML representation of an application can
certainly define what these decision points are, and how to query the
user for them if necessary. Yet given that they are tagged and
defined, the software rendering facility can collect and understand the
data used at these points as well. This is again, structured
information.
*** (16) Allows simulated configuration for debugging purposes.
Because the decision points are defined in the abstract representation
of the application, various inputs can be simulated.
*** (17) Allows interactions between software to be formally defined
XML provides the means for developers to define referenced points
within their software that may be referenced by other software. For
example, a software developer�s kit may define libraries and include
files that may need to be referenced by software written to make use of
these libraries, or by development tools.
The applications that need to use these resources need to specify
registry entries to these resources or modify environment variables,
etc. The tags are define by the software developer�s kit, so these
resources can easily be referenced in the application�s XML.
Furthermore, if a number of venders of such kits are supported by the
application, then different connections and setup information can be
specified by the application�s XML for each kit.
*** (18) Allows interactions to be accessed over the web
XML and the web.
*** (19) Allows interactions to be managed automatically
Because the Software Rendering Facility has all the XML of all the
pieces, it is not too hard to imagine that it can manage these
interactions where they are not ambiguous, and prompt the user to
resolve the issues where they are. Again, options can be recorded,
adding to the meta understanding of the computer system by the Software
Rendering Facility.
*** (20) Can express a product differently based on platform
It is all about expressing a product in a way sensitive to the target
system.
*** (21) Can express a product differently based on role.
Being sensitive to the role a computer system is to play is just
another set of options.
*** (22) Can be used to define distributed systems
This is simply a matter of XML referencing other XML and managing and
collecting information across the Software Rendering Facility used on
each computer system. Again, distributed systems are collections of
structured information. They interact. They refer to each other. We
are doing this today with HTML on the Web. We can do this to link
the storage of distributed systems.
Yet here I have built up the ability to construct a set of
applications, define a set of target computer systems, and define in
one place how a distributed program is to be expressed across all the
systems taking part.
Better yet, so long as the Software Rendering Facility maintains its
understanding of each computer system, a single computer system can be
managed even if it is taking part in a number of different distributed
applications.
*** (23) Only requires support for features needed by the target system.
The Software Rendering Facility for a give computer system is only
concerned about building its valid storage. Structures that are not
present in that system and abstractions and facilities not used in that
system need not be understood or supported in the Software Rendering
Facility. These things are simply tags that are skipped, since they do
not apply.
*** (24) Can be used in pervasive systems.
Pervasive systems are not really any different that Linux. Besides,
our system merely needs to build a valid storage image for the
pervasive system at hand. If that is just an image burned in EEPROM,
so be it. If the image must be organized, or compiled, so be it. As
long as the processes are described in the XML, and the Software
Rendering Facility for the device knows how to make the mapping to the
device, it doesn�t matter what the storage is or how it is constructed.
*** (25) Built on open standards
XML, XSL, XSLT as well as other possible future standards such as XPL
or XmlOS.
(Or perhaps your own favorite structure storage definition, if you are
one of those that find XML offensive in some way.)
*********
This design is about doing configuration management at the lowest, most
basic level. We don�t want to use complicated abstractions, because
doing so will only tie our hands. This is about simple, fast, and down-
right low to the ground.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jon Guyer <[EMAIL PROTECTED]>
Crossposted-To:
comp.sys.mac.programmer.help,comp.sys.mac.programmer.misc,comp.sys.mac.misc,microsoft.public.windowsnt.misc
Subject: Re: Operating system file name restrictions? Where?
Date: Fri, 25 Aug 2000 18:59:44 -0400
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (David C.)
wrote:
> UNIX is definitely the system of "give the user enough rope for him to
> hang himself."
... and put it around his neck and cinch it up real tight in case he
doesn't know how to do it himself...
--
Jonathan E. Guyer
<http://www.his.com/jguyer/>
------------------------------
From: Fabian Gebhardt <[EMAIL PROTECTED]>
Subject: Re: splitting files compatible to linux and winnt
Date: Sat, 26 Aug 2000 00:56:11 +0200
split
or use rar.
Rar is available for Linux and Windows.
--
CU, Fabian Gebhardt
E-Mail: [EMAIL PROTECTED]
ICQ#: 77948091
Homepage: http://www.ki.tng.de/~gebhardt
Schul-Seite: http://www.ebg.org
------------------------------
From: [EMAIL PROTECTED] (Andrew Stephenson)
Subject: Re: How do you pronounce GNOME?
Date: Fri, 25 Aug 00 22:50:51 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] "<[EMAIL PROTECTED]>
" writes:
> 1. Is it gnome, like the man who sits by your pond. OR
> 2. Is it Gee-Nome, as in the human gnome project. OR
> 3. Is it pronounced similar to GNU, like Gu-Nome.
>
> Any Ideas?
Hope other answers have proved satisfactory. (I say '1', FWIW.)
This reminds me of an old and corny joke, about a Frenchman who
visits London, only to discover how little he understands about
the British and their strange language. Pronunciation especially
gives him problems: "bow", "bough", "chow", "chough", "cough",
"dough", etc. But gradually he works out some rules which seem
to work, so happy at last he prepares to enjoy his visit. Then,
passing a theatre, he notices a publicity board outside, quoting
a review: "Cats... pronounced success!"
--
Andrew Stephenson
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.misc) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Misc Digest
******************************
