Linux-Misc Digest #601, Volume #25 Mon, 28 Aug 00 18:13:04 EDT
Contents:
Re: Linux, XML, and assalting Windows ([EMAIL PROTECTED])
Re: why I'm in a bad mood ("Andrew N. McGuire ")
Re: Compiling GNOME - Compiler can't find GDK-Pixbuf (Ken Conroy)
Re: Linux, XML, and assalting Windows ([EMAIL PROTECTED])
Re: Restaurant Booking System (Grant Edwards)
Re: Headless X86 Linux system (Peter Mitchell)
Re: why I'm in a bad mood ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.os.linux,comp.text.xml,comp.os.linux.setup
Subject: Re: Linux, XML, and assalting Windows
Date: Mon, 28 Aug 2000 20:30:20 GMT
> As such, while it would be possible to describe all of a system using
> an XML document, that would probably be rather useless, as you need
> some substrate on which the XML is to be stored.
>
> In effect, XML _can't_ be the "base;" there needs to be a serial
> stream on which to place the XML-formatted material. You need
> something below it.
>
> It seems more useful to talk about that specific "thing that is
> below."
Okay. Today we have an architecture where we store our programs and
data on a persistent medium (usually a hard disk). We could in fact
execute directly against the hard disk (skipping the need to implement
memory). There are two problems with this approach. The first is that
it would be slow. Yet that isn't necessarily the biggest problem. The
biggest problem is fault tolerance. If you have a crash, and the only
representation you have was the one you were running against, you are
simply out of luck. (Like typing byte codes in to a Commadore 64. It
crashes, and you end up starting over, typing the byte codes in all
over again.)
So, what we have done is create an architecture where we keep a rather
stable instance of our configuration information on disk (generally in
a file system). Then if our system happens to crash, we can turn it
off, turn it back on, and be up and running again.
We do this, even though we could simply save and restore our current
state to disk. Rebooting is necessary though, because we don't have
systems stable enough that we can be absolutely sure our image will
never crash.
Looking at our storage vs. the memory images in a computer system, we
see a rather significant drop in complexity. Data structures in memory
being far more complex, and executable code being far more complex in
memory than that which exists in storage (EPROM).
We also see storage showing a significantly reduced amount of change
when compared to memory. Files in storage tend to be rather fixed,
with few changes, while what is expressed in memory varies widely over
time. (Keep in mind, this is all relative! Compared to the return
stack, nothing on disk changes much, no matter how we pound the disk.)
The point of what I am trying to get across is that storage really
serves as a working, dynamic definition of what programs can be
executed in memory, without requiring all those programs to be loaded
into memory at any given time. Almost everything that ends up
executing in memory was defined in storage.
This model works very well, as long as storage is more static than
dynamic. And as long as storage remains rather simple, without too much
complicated structure.
How does networking modify the model we have been using? It is
complicating the underlying structure. The mostly simple tree (a
directory structure) is becoming more of a general net, like a tree of
nodes with links into locations in other trees, on other computers.
And storage is becoming more dynamic. I am installing and removing many
more applications than I was in the early 90s. And compared to what I
was doing in the 80's, I thought I was doing too many installations
then!
One could argue at this point that we have already seen most of the
changes to computer systems that we are going to really need. That the
rate of installs and reconfigurations is going to slow down. I don't
really think so.
We can get more stability without requiring major changes to existing
operating systems and applications by constructing a "storage"
for "storage". In other words, instead of rebooting solely to storage
(where if I have a failure, I am really out of luck), I can instead
access a more fundamental definition of storage. It is this layer that
can make use of definitions of storage constructed in XML.
The result is a model that looks like this:
X ==> Storage ==> Memory
Where X is that "Thing Below" you wanted to talk about.
Does this help?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Andrew N. McGuire " <[EMAIL PROTECTED]>
Subject: Re: why I'm in a bad mood
Date: Mon, 28 Aug 2000 15:39:30 -0500
On Mon, 28 Aug 2000, [EMAIL PROTECTED] quoth:
~~ Date: Mon, 28 Aug 2000 12:52:52 -0500
~~ From: [EMAIL PROTECTED]
~~ Newsgroups: comp.os.linux.misc
~~ Subject: why I'm in a bad mood
~~
~~ I just got through overwriting a bunch of files that worked with an
~~ "update" that doesn't. I'll eventually get it all fixed, but
~~ meanwhile...to all the hotshot programmers out there...
And this is precisely the reason you adhere to a sound backup
regimen right? :-)
~~ 1) will you please try out the makefiles you ship on some system other
~~ than your own before you ship them? I'm really getting tired of getting
~~ halfway through a make, only to find that some program is not available on
~~ my system or some directory does not exist or your C code is non-standard.
I know you are just venting, thats fine. However, it would be more
productive to point out bugs in the Makefile or really any bug
to the maintainer(s)/bug list that is probably mentioned in the
README that came with the source. Well-tested patches are always
good to send as well, if possible. Just make sure your correct it
is a bug (I got burned on this recently).
~~ 2) if you're calling your program an "update", please make it backward
~~ compatible with the previous version. If it's not backward compatible,
~~ call it something else and, for crying out loud, don't overwrite the older
~~ version.
It has been my experience that the configure/make/make install process
only backs up your previously installed version about 50% of the time.
It seems to be about the same 50% of well maintained programs that also
provides an uninstall target in the makefile. Obviously these stats
are just guestimates and not reliable. But even if it were 90%, would
you want to bet your working system on that? Always best to have a
backup.
anm
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Andrew N. McGuire ~
~ [EMAIL PROTECTED] ~
~ "Plan to throw one away; you will, anyhow." - Frederick P. Brooks, Jr. ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: Ken Conroy <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux.mandrake,comp.os.linux.setup
Subject: Re: Compiling GNOME - Compiler can't find GDK-Pixbuf
Date: Mon, 28 Aug 2000 17:04:07 -0400
Colin Watson wrote:
> Ken Conroy <[EMAIL PROTECTED]> wrote:
> >For some reason, after making and installing (via the included
> >instructions) the gdk-pixbuf library (this is one of the few that do
> >not come with a .spec file, so I just did a normal ./configure, make,
> >make install) the next components to be compiled and installed (all the
> >components listed before gdk-pixbuf compiled into RPMs and then
> >installed without a hitch) I recieved a message telling me that the
> >compiler couldn't find the gdk-pixbuf library.
>
> The runtime library (the bit that lets you run programs linked against
> the library) is not the same as the development library (the bit that
> lets you compile programs linked against the library). Did you also
> build and install the development library?
>
> >My current non-default compiler options (or rather, the options used by
> >the configure script) are as follows:
> >MACHTYPE=i686-mandrake-linux-gnu
> >HOSTTYPE=i686
> >CFLAGS="-06 -fomit-frame-pointer -mpentiumpro -mcpu=pentiumpro
> >-march=pentiumpro -ffast-math -fexpensive-optimizations"
>
> Hmm. Well, I would use somewhat more conservative options, but I guess
> mad optimizations are what Mandrake is about. ;)
>
> --
> Colin Watson [[EMAIL PROTECTED]]
> "Is this legal?"
> "That question is OFF-TOPIC here." - alt.binaries.cracks FAQ
Thanks for the info, makes me feel like my IQ should be dropped 30 points
for not thinking of that sooner. D'oh!
>Hmm. Well, I would use somewhat more conservative options, but I guess
>mad optimizations are what Mandrake is about. ;)
Hell Yeah! Even using PPro over Pentium opts (when you have a
686-compatible processor, that is) produced a small but noticable
improvement in speed - so I'm working on doing that with all my new apps to
make my system as fast and effecient as possible. I AM crazy, stuff like
this doesn't surprise any of my friends. I once even tried to O/C a
scientific calculator, I swear it shaved a few milliseconds off the
calculation time, but the HSF broke off...
Sorry, no kickass quote here, but I have to say you picked a good one :>
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.os.linux,comp.text.xml,comp.os.linux.setup
Subject: Re: Linux, XML, and assalting Windows
Date: Mon, 28 Aug 2000 21:02:44 GMT
> >*** (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.
>
> Have you got a DTD to represent formal definitions? Perhaps based on
> Z?
>
> If you do not have a language for representing formal definitions,
> then all you're saying is that "someone could use XML as a substrate
> to represent a formal definition language." Which does nothing about
> implementing such a thing.
I have scratched out a couple, but nothing that is likely to impress
you. However, just a few simple scratches assured me that I could have
defined and expressed most of the configuration changes I heard about
in a recent IBM "hints and helps" session on DB2.
The basic format was "If you have this problem, here is your fix".
Mostly a reinstall of a component, running a utility with certain
options to set up communication between machines, add a table, etc.
>
> >*** (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.
>
> But is it _appropriate_ to apply the change?
>
> If a change affects the behaviour of a system, then it is not safe to
> assume that this change in behaviour is _appropriate_, as there may be
> local usage and configuration that depends on the old behaviour that
> would _BREAK_ when "fixes" are pushed in automagically.
So we have to define "automatic". What I was really trying to say
here, is that once we have identified a common problem in the
installation and configuration of a certain software component, that
fix should "automatically" be applied. Today, we educate people, and
re-apply, re-apply, re-apply, all over the place.
On the other hand, suppose in a future world we require software (even
scripts, since the over head is really rather low) to be packaged in
XML, and possibly signed to avoid modification.
Now when a virus like one of the Outlook scripts shows up, automatic
rejection is probably appropriate.
Suppose a font is found to have an error. Like little used character
is encoded in the wrong position. Again, the kind of fix that is
pretty safe to automatically apply.
Suppose I am having a configuration problem. Then this base system can
go look for a fix based on what software component I am having problems
with, and the likely software components that might be involved. I
could as a user ask for this fix to be "automatically" applied.
And this mechanism is providing for the ability to back out fixes with
more confidence as well.
> >*** (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.
>
> XML can be used to "define" anything.
>
> But "define" is not the same as "identify."
>
> _Identification_ of correct configuration is not something that can be
> done as automatically as you imply.
The XML defines what its decision points are, which are well defined by
the application. As long as the application is consistent with its
vocabulary when refering to these decision points, other software
components can reference them, especially if they apply to their own
configuration.
For example, take DB2. Some decision points are really of the form "Is
DB2 installed locally, or will access use a DB2 client". If a DB2
client is being installed, the machine name (IP address) of the DB2
server is needed.
The application developer understands what their decision points are,
and what is required on the disk to render those decisions within the
configuration of their product. Lacking an Install program to hide
this information, the developer ends up documenting them in the XML for
their application instead.
Documented decision points are provided data, and that data can be
recorded.
> >*** (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.
>
> And if there is a need to roll back changes, what then?
>
> And if transactional changes are made that _cannot_ be rolled back
> along with the changes in configuration, _what then_?
>
> For instance, suppose a configuration change is made to the accounting
> system, a cheque is printed based on that configuration, and then it
> is determined that the configuration was bad, and should be rolled
> back.
>
> The system must have a way of distinguishing between the configuration
> data that is to be rolled back, and transactional data (like recording
> info about a cheque that was printed) that _CANNOT BE ROLLED BACK_,
> even if the amount or payee was _WRONG_.
>
> If you try to imply XML has the slightest thing to do with resolving
> these kinds of issues, then you're _drastically_ naive.
>
The simulation I was talking about was the construction of storage,
given the user's machine, answers to configuration decision points, and
installed software components.
Not inputs to their applications, inputs into this Layer X under
storage that we are talking about. (Simulating their machine would
require their context, OS, applications, etc. Not a very likely
ability any time soon.)
Many times the result of such configurations are applications that
don't work. If you are trying to debug one of these problems remotely,
it is useful to be able to "simulate" what lead to a non-functional
install.
A facility that records decision points and documents at a high level
what components are installed would aid this particular problem.
Transaction processing is something all together unrelated to this
point, though it is interesting.
> >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.
>
> Evidently you want to build Fundamentally Unimportant Systems, because
> systems that are actually important require abstractions that can't be
> oversimplified just for the sake of pushing it all into the
> procrustean bed of "pretending to be pervasively about XML."
Nope. The simplist abstraction possible is a simple disk image. I can
use a simple tool like this to generate working versions of really
complicated computer systems. Can't I?
The point is that files are files and have to be in the proper place
for everything to work, independnent of what they are used for. If you
simply insure the proper structure, you don't have to distingish
between the installation of data, applications, drivers, or even the
OS. You have to have enough information to insure a proper rendering,
and to identify a proper rendering, but you don't have to know why.
> --
> (concatenate 'string "cbbrowne" "@" "ntlug.org")
> <http://www.hex.net/~cbbrowne/linux.html>
> "Now, if someone proposed using people who spam comp.sys.* groups with
> political screeds in place of lab rats for drug testing, I'd
> wholeheartedly concur". -- John C. Randolph
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: alt.os.linux,alt.os.linux.suse,comp.os.linux.setup,uk.comp.os.linux
Subject: Re: Restaurant Booking System
Date: Mon, 28 Aug 2000 21:26:02 GMT
In article <8oehck$pjj$[EMAIL PROTECTED]>, CJ Llewellyn wrote:
>"Phil" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> You're forgetting he's taking online bookings. I presume
>> payment needs to be made as well.
>Urm, how many restaurants have you been to lately ? Payment is
>usually made after the meal has been consumed.
It's not uncommon for restaurants (after getting fed up with
no-shows) to require a credit-card number to secure an advanced
table reservation. If you don't show up, they charge your
credit card a fee to cover loss-of-use of the table.
Around here (Minnesota) golf courses have started doing that
when you reserve a tee time in advance.
>It does raise an interesting point, that of varifing the person
>making the booking is a genuine customer.
I suppose you could mount a new sort of DOS attack, where a 'bot
constantly reserves all of the tables at all of the restaurants
of the chain...
--
Grant Edwards grante Yow! It's today's SPECIAL!
at
visi.com
------------------------------
From: Peter Mitchell <[EMAIL PROTECTED]>
Subject: Re: Headless X86 Linux system
Date: Mon, 28 Aug 2000 14:34:17 -0700
My mistake on the line in /etc/inittab; should be more like
S1:12345:respawn:/sbin/getty /dev/ttyS1 D38400 vt100
In my case I use a laptop connected through a serial port to
watch the boot-up process, and after this I can use the same
system or I can use telnet to control the machine.
Another problem - unless you make changes (I've forgotten to
which file, but it might be /etc/hosts.allow), you can't run
halt, shutdown, reboot etc except from the keyboard. This
includes running them from the serial terminal.
Peter
* Sent from AltaVista http://www.altavista.com Where you can also find related Web
Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: why I'm in a bad mood
Date: Mon, 28 Aug 2000 16:31:27 -0500
On Mon, 28 Aug 2000, Andrew N. McGuire wrote:
> On Mon, 28 Aug 2000, [EMAIL PROTECTED] quoth:
>
> ~~ Date: Mon, 28 Aug 2000 12:52:52 -0500
> ~~ From: [EMAIL PROTECTED]
> ~~ Newsgroups: comp.os.linux.misc
> ~~ Subject: why I'm in a bad mood
> ~~
> ~~ I just got through overwriting a bunch of files that worked with an
> ~~ "update" that doesn't. I'll eventually get it all fixed, but
> ~~ meanwhile...to all the hotshot programmers out there...
>
> And this is precisely the reason you adhere to a sound backup
> regimen right? :-)
It's certainly one of the reasons, and two hours later I'm back in
business, but just because I have a backup doesn't mean it should be open
season on my system. Installing a rather mundane application should not
be a risky proposition.
But you're right, I am venting 8^)
--
------------------------------
** 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
******************************
