Linux-Development-Sys Digest #795, Volume #6 Tue, 8 Jun 99 01:13:57 EDT
Contents:
Re: system call (NTVO910)
Re: Proposal for XML Configuration files (Christopher Browne)
Re: the ultimate OS (Sid Cammeresi)
Re: TAO: the ultimate OS ("G. Sumner Hayes")
Re: Proposal for XML Configuration files (Mario Klebsch)
Re: TAO: the ultimate OS (David Fox)
Re: TAO: the ultimate OS ("G. Sumner Hayes")
Re: TAO: the ultimate OS ("G. Sumner Hayes")
Re: select() vs. poll() ("G. Sumner Hayes")
Re: Large CD-ROM file errors...? ([EMAIL PROTECTED])
Re: Linux development tools - new : download freeware compiler with IDE and
GuiDesigner for Linux & Windows ("Max Reason")
Re: TAO: the ultimate OS ("G. Sumner Hayes")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (NTVO910)
Subject: Re: system call
Date: 8 Jun 1999 01:38:58 GMT
thanks so much for your response, Stefi
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.unix.programmer,comp.os.linux.development.apps
Subject: Re: Proposal for XML Configuration files
Reply-To: [EMAIL PROTECTED]
Date: Tue, 08 Jun 1999 00:24:01 GMT
On 06 Jun 1999 16:49:00 -0400, Keith Wright <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Kaz Kylheku) writes:
>> Get real, config files rule. The more syntaxes the merrier.
>
>You lost me there. If there is a reason for another syntax, then
>go for it, but it's hard for me to believe there are programs so
>novel that one of the existing syntices won't work.
*Multiple independent implementations* may rule; the more syntaxes is
most definitely *not* the merrier, as this forces more complexity onto
anyone that wants to understand the schemes.
I rather like the IETF principle that they will not approve a protocol
until there are at least two implementations. *That* expresses the
*true* need, which is to have the ability for multiple programs to
safely access the same data file.
The way I'd put it is, "The more independent parsers that parse the
format, the merrier!"
I'd suggest the somewhat different thought that it would be attractive
to have a small number of syntaxes that provide different degrees of
flexibility, and well-debugged parsers for each.
Three approaches of varying sophistication would be:
a) A very simple key/value scheme, for those cases where there will be
very simple configuration information. This is roughly equivalent to
".ini" files.
b) A somewhat more sophisticated key/structure scheme, providing
somewhat more sophistication, with such things as:
- Key/value
- Something corresponding roughly to C "structs"
- Something corresponding to (IDL "sequences" | Scheme "vectors")
- Something corresponding to (Python/Objective C/Smalltalk
"Dictionaries" | Perl "Associative Arrays")
- Some reasonable form of "typing" system.
This is roughly equivalent to libPropList.
c) Scheme, for cases where it is not sufficient to merely provide static
configuration data.
This requires embedding a full-scale language into the application.
Scheme is almost certainly the best choice for this purpose...
A Really Valuable Thing to provide in *all* cases would be some sort of
"signature" system so that an automated tool may be able to determine
what applications such config files are supposed to be associated with.
>> >Is there anybody in the web thinking about a standard on this topic,
>> >maybe based on XML?
>>
>> Good luck convincing everyone to use whatever scheme you come up with.
>
>As you have (probably accidentally) pointed out, the best solution
>in many cases will be to use Guile to embed a Scheme interpreter,
>thus making your config file a real programming language, instead
>of a random pile of hacks.
>
>What does XML, (a document format description language) have to do
>with it? I want to be able to configure like this:
>(set! startup-hook
> (lambda argv (if (null? argv)
> (display-splash "file"))))
This is nice insofar as it allows combining data and code in a
configuration file.
This is somewhat "evil" insofar as it means that attempts to analyze the
configuration file may represent an instance of Turing's Halting
Problem.
That being said, it may still be an acceptable approach given the
stipulation that the file must contain only s-expressions. A "reader"
process should be able to grab and parse the s-expressions. Predicting
what will happen from the above "startup-hook" may be a bit problematic,
but so long as there is no expectation to analyze macros, it should be
OK.
A Neat Thing to do with a Scheme-based methodology would be to have some
sort of metadata that indicates what application-specific functions
exist, which would allow *some* searching for particular aspects of
configuration...
--
"Unlike computers, guns don't have Y2K problems..."
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/langlisp.html>
------------------------------
From: [EMAIL PROTECTED] (Sid Cammeresi)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc
Subject: Re: the ultimate OS
Date: 8 Jun 1999 02:05:46 GMT
Reply-To: [EMAIL PROTECTED]
>>>This sounds a whole lot like:
>>>a) Tom Lord's "Berkeley DB" (which isn't the same thing as db-lib), and
>>Haven't heard of that.
><ftp://emf.net/users/lord/src/bdb-1.0.tar.gz>
This link is, ahem, broken. :)
>b) Providing space-efficient representation of Very Small Files.
>c) Allow the filesystem to nest.
I suppose, but these seem a bit redundant.
>The practical use of this would be that an application would create a
>"document" that would actually be a filesystem, and which would thereby
>provide an entirely natural way of associating arbitrary attributes with
>the document.
You could do this with BFS today.
>But it would be *real* slick if a process could do a traditional "mount"
>to make it easy to write scripts to manipulate documents without needing
>to have the original application involved.
Or just insert its own device drivers into a protected runtime environment
so that it doesn't need such hackery....
>The "ugly" bit is that there would be a need to allow the FS to resize
>itself dynamically, for instance when that icon gets added to the
>document. It would be quite natural, after the "umount," to run some
>equivalent to fsck that would remove unused "blocks."
Filesystem-level support is sounding better by the minute.
sc
--
Sidney CAMMERESI | icbm: 40.112 N, 88.200 W
http://www.omni.cx/~sac |
PGP: 65 6F B3 DA CA 3E 3B 09 | Cxi tie parolas Anglen kaj
32 C8 17 1C 0A 79 2F 3F | Esperanten.
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Mon, 07 Jun 1999 22:32:05 -0400
[Warning -- this post is certified 100% content free]
Christopher Browne wrote:
> There may be some valid criticism that UNIX systems represent a
> combination of components "pasted together." Of course, if the "duct
> tape" is robust enough, that process can provide you with pretty decent
> results.
I think that's an excellent characterization. The UNIX philosophy
is to provide some scraps of metal and an enormous roll of duct
tape. With those -- and possibly some scraps of your own -- you
can conquer the world.
It's the Lego philosophy and it's the reason that Turing machines
are cool -- don't design for a few specific goals, design so that
you can be bent into a lot of different shapes.
> Some years ago, he indicated that Linux was something of a "stopgap"
> measure that would likely be replaced by Hurd. In retrospect, Hurd has
> been *real* slow coming, and will likely never eclipse Linux.
There are a handful of great quotes from the Linus/AST flamefest:
"Of course 5 years from now that will be different, but 5 years from
now everyone will be running free GNU on their 200 MIPS, 64M
SPARCstation-5." Andrew Tanenbaum, 1992.
"You'll be rid of most of us when BSD-detox or GNU comes out, which
should happen in the next few months (yeah, right)." -- Richard
Tobin, 1992. [BSD did follow within a year]
"I am aware of the benefits of a micro kernel approach. However, the
fact remains that Linux is here, and GNU isn't --- and people have
been working on Hurd for a lot longer than Linus has been working on
Linux." Ted T'so, 1992.
"Anyone who says you can have a lot of widely dispersed people hack
away on a complicated piece of code and avoid total anarchy has never
managed a software project." Andrew Tanenbaum, 1992.
Though the last one is a bit of a cheat -- AST is really saying (if
you look at the context) that you need a dominant central figure to
hold together a free software project. That's debatable but not
laughable -- you might argue that some of the BSD projects or Apache
provide counterexamples.
--Sumner
------------------------------
From: Mario Klebsch <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer,comp.os.linux.development.apps
Subject: Re: Proposal for XML Configuration files
Date: Mon, 7 Jun 1999 20:08:56 +0200
Keith Wright <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] (Kaz Kylheku) writes:
>> Get real, config files rule. The more syntaxes the merrier.
>You lost me there. If there is a reason for another syntax, then
>go for it, but it's hard for me to believe there are programs so
>novel that one of the existing syntices won't work.
Well, a lot of config files are programs of part of programs. There
are config files that are /bin/sh script and other config files are
perl scripts. Emacs uses lisp programs as config files.
IMHO the only config file, that really needs some reworking, is
sendmail.cf. But the reason for its complexity is, that sendmail.cf
is more a language than a config file. :-)
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 07 Jun 1999 20:02:00 -0700
[EMAIL PROTECTED] (Vladimir Z. Nuri) writes:
> the essay, I acknowledge, is challenging basic philosophical assumptions
> or dogmas of the OS community. i.e. MEMES more than laying out
> lines of code (which hopefully is the ultimate end goal).
On the contrary, the essay is a collection of cliched truisms that no
one could possibly disagree with but no one is sure how to accomplish.
I'm sorry to become testy, but its insulting to be told that the idea
of a stable, easy to use and flexible system ``challenges [my] basic
philosophical assumptions.''
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Mon, 07 Jun 1999 22:40:56 -0400
[Followups to *.advocacy since this is clearly offtopic. I know I
should resist, but I'm weak.]
"Vladimir Z. Nuri" wrote:
> when you actually quote paragraphs of the essay that you
> disagree with or you feel reflect my cluelessness, I will
> be happy to address them..
You said that to me. So I did it. Then you accused me of nitpicking,
cited minimal C++ experience as sufficient knowledge of OO design,
insulted me, and ignored every single one of the points that I
disagreed with.
You must have some odd definition of "address them"...
--Sumner
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Mon, 07 Jun 1999 22:55:48 -0400
[Aside: I just sent a fairly nasty post. Had I seen this before, I
wouldn't have. Sorry. I'll ignore any followups to it.]
"Vladimir Z. Nuri" wrote:
> are you suggesting the high layers shouldn't use objects,
> or use "non c++-like" objects?
Not C++ objects, and not objects at all for some things. "Everything
is a file" is not great, but it _does_ cut to the heart of the matter:
in a lot of contexts, it's the data that is important and the code is
just there to slice it, dice it, and present it.
> instead of just reactively what is your proactive suggestion?
Study some and write a toy OS or two, then come back and try to give
this a cut.
It's a tremendously hard problem. I'm working on a UI of my own that
does things in what I consider to be the Right Way, but I've been
working on it for years now and it'll be years more before it's
released (if ever). One of the big problems I've hit is that things
that seem like great logical abstractions turn out to be severely
broken; that requires finding newer, better abstractions and working
with those. I've been assiduously devouring every HCI book and paper
I can lay my hands on, but it's still a fairly opaque problem.
> the constant need to have all kinds of different entities
> is a tower of babel of software. I do believe future OSes
> will have integrated/unified vision similar to what I propose
> in the paper.
That is a noble goal to strive for, and I think it's one aim of
most new OSes. Plan 9 certainly has an integrated, unified
vision. But...
> the exact form is not clear to me yet.
....it's the exact form of the vision that makes or breaks the
system. Plan 9 certainly doesn't beat Windows or BeOS on the
"usable by computer illiterates" test, even though Windows doesn't
have a unified vision (unless 100% Market Share is a vision).
> I was hoping to flesh it out cooperatively with other ppl. you,
> being an authority, would be an excellent candidate..
I'm hardly an authority. Not even a PhD. Maybe a serious amateur.
I hack TCP servers and crypto for a living.
If I had the answer, I'd gladly give it to you. I don't have it,
I just think that your paper is farther from the answer than most
of the current literature on the topic which leads me to believe
that reading up on what's going on could give you some useful
ideas.
> I admit that in the essay, perhaps places where I refer to
> "objects".. the more well understood term may be "classes"..
> will revisit this.
Argh! No! I'm out of school, I don't need any more classes!
Oh, wait. That's not what you meant by classes.
Seriously, C++-style classes are not the one-size-fits-all
abstraction that you're looking for IMO.
--Sumner
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: select() vs. poll()
Date: Mon, 07 Jun 1999 23:07:33 -0400
Bj�rn Reese wrote:
> However, select() is still more portable as it is
> supported on most older Unices and several non-Unix
> platforms, such as OS/2 and Win32.
Caveat: On Win32 the semantics are different. select()ing on
things other than network sockets doesn't work, in general.
WaitForMultipleObjects* and WSAAsyncSelect are preferred.
If you're just working with sockets, select() out to work (though
a socket fd isn't a small positive integer and other stuff is
screwy).
--Sumner
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.misc
Subject: Re: Large CD-ROM file errors...?
Date: Tue, 08 Jun 1999 00:50:23 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I got a friend to burn the StarOffice 5.1
download onto a CD-R for me
>
> On getting home, I booted up Linux (2.2.9, with
full CD support
> including Joliet compiled in) and tried to copy
the 70.6MB file.
> However, Linux could only see the first 16MB or
thereabouts.
I've got the same problem with CD-R's written
under Win95. If you look at /var/log/messages
you'll see some errors like this:
kernel: isofs_read_level3_size: More than 100 file
sections ?!?, aborting...
I got around this by patching fs/isofs/inode.c,
just above this error message, and another similar
one, to use 10000 retries insted of 100. It looks
like some CD-R's will get written with many
fragments.
Can anyone confirm this is the fix?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Max Reason" <[EMAIL PROTECTED]>
Subject: Re: Linux development tools - new : download freeware compiler with IDE and
GuiDesigner for Linux & Windows
Date: Mon, 7 Jun 1999 17:55:57 -0000
Martin Maney wrote in message <7jhp0a$72$[EMAIL PROTECTED]>...
>Max Reason <[EMAIL PROTECTED]> wrote:
>> I'm not sure how you came to those conclusions, but you are mistaken.
>
> By looking at your web pages, Max. The "notes.txt" document
> in particular seems to be quite clear, although from what you say
> perhaps it is clear but no longer accurate:
Yes, the notes.txt file did slip past me. The XBasic web-page where
you download XBasic seems pretty clear on review, but you are right
the old and obsolete notes.txt file did slip by.
>> available as freeware. You can download the full, unrestricted, non-demo
>> professional edition of Linux XBasic and/or Windows XBasic, and yes
>> you can make standalone executables. For information and downloads,
>> see http://www.maxreason.com/software/xbasic/xbasic.html .
>
> You might want to review your pages. The statement that it is free,
> at least in the beer sense, must be well-buried under what reads like
> it is promotional hype for a commercial product. Perhaps you could
> lose the bulk of that, rewrite notes.txt, and generally make it look less
> like a commercial product that has to convince us to part with our cash
> by tossing buzzwords about? Or just add a clear statement early on
> that "real" XBasic is now free, not just the restricted demo version.
Yes, the intro page was extracted from a long-ago XBasic flier that
therefore does has a commercial tone - but is also a useful overview.
Rather than sit down and write something new I just cut and pasted.
I did not realize I'd have to worry about that lingo when I was making
something available for free, so I concentrated on the other XBasic
download, information, and project pages - plus helping a new XBasic
programmer convert the documentation to HTML and put on the web.
You are the first to complain about the tone, mostly I've heard thanks.
Nonetheless, I'm trying to be helpful, nothing else, so I have made
some changes to the web-pages (except the "offensive" overview)
to reflect the suggestions made in this newsgroup. I edited the
erroneous notes.txt and will replace the old one tonight.
>> I moved on to other projects years ago and simply decided to
>> make XBasic available for anyone who would enjoy having it.
>> That is the current situation.
>
>(discussed later; kept for reference)
>
>> Though I know a majority of Linux programmers wired C and C++
>> years ago and will not be much interested in *anything* that has the
>> letters "basic" associated with it, I also know that some others will
>> appreciate an integrated program and GUI development environment
>> that is easier to learn and quicker to program than C.
>
> Yeah, "basic" is something of a dirty word (don't ask me about
> writing business apps in AlphaBasic, please), and there's no
> shortage of other "simple[r]" languages in the Unix world. But
> maybe there's a place for a basic variant with a graphical GUI
> designer... I might even guess that there probably is. Any world
> that can include rabid Perl fans... :-)
>
>> Anyway, bottom line is - XBasic is just another free resource for Linux.
>
> At this point it's "freeware"; I gather that you're willing, in principle,
> to open it up, but I'm not sure if you're willing to open it to the point
> that most Linux developers would call "free" (unqualified). This
> would be a real concern if I were seriously considering doing any
> substantial work with it. I don't know, Max: the language may not
> be a toy, but it seems as though that's what you're releasing it as.
> You say it's no longer an active project, so we can't count on
> support from you, but there's no source, so no one else can do
> anything. This is really the worst of both worlds
> (commercial/closed vs open source) for a serious tool.
I must admit I don't understand what you mean by that paragraph.
What do you mean by "free = unqualified". I really don't know what
you mean by that, but I thought Linux was free BUT qualified - in the
sense that certain restrictions apply. Also, I somehow suspect
Linus has not agreed to answer every question everyone wishes
to ask - so in the sense you seem to mean, Linux is not supported.
When I say XBasic is no longer an active project, I mean I am not
making money off it so I cannot guarantee to spend unlimited time
"supporting it" - whatever that means. I have answered every
technical questions I've received, but obviously I cannot guarantee
to support 10,000 or 100,000 or 1,000,000 programmers if for
some reason freeware XBasic caught on big-time.
As for the question of "XBasic source code", I am perfectly willing
to make all the XBasic source code available. In fact, I would love
to do that precisely for the reasons you imply --- I'd love to have
dozens of skilled programmers enhancing XBasic. If someone
competent and diligent wanted to take over management of the
XBasic source code, that's fine with me. Sure, I'll stay available
to answer questions, but... Actually, I have not read about how
the core Linux crew manages Linux, and for that reason I'm quite
ignorant (meaning "no knowledge from experience") about how
such management would be organized. That's why I'd prefer
someone with that knowledge/experience do it right.
Are you volunteering? :-)
Scared you, huh?
max
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: TAO: the ultimate OS
Date: Mon, 07 Jun 1999 23:11:04 -0400
Nix wrote:
>
> "G. Sumner Hayes" <[EMAIL PROTECTED]> writes:
>
> > For example, do you understand why there was a boom in object
> > databases (like you propose for the filesystem) about 5 years ago
> > and why people have become much less interested in the idea today?
>
> I've been wondering about that. What *was* wrong with them?
Bruce Stephens' answer is good. I'd add that the nice features of
object databases didn't supplant the nice features of relational
databases; a lot of new databases are object-relational databases,
which is marketroid for "neither of those clean, simple designs
actually worked for all purposes so we're on a quest for another".
--Sumner
------------------------------
** 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.development.system) 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-Development-System Digest
******************************
