Linux-Misc Digest #629, Volume #25 Thu, 31 Aug 00 01:13:02 EDT
Contents:
Re: Headless X86 Linux system ("Michael Westerman")
Re: what's up with Sun? ("Ingemar Lundin")
Re: can't reboot, init high CPU (John Hasler)
Re: Linux/unix programs 3312 ("Andrew N. McGuire ")
Re: Netscape Sucks, I need another option. (Steve Stellmacher)
Re: help: kicq core dumps (Eric Laffoon)
Re: Linux, XML, and assalting Windows ("paul snow")
Re: Pro*C (Akira Yamanita)
Re: Lilo broken??? ("JoAnn Elliott")
----------------------------------------------------------------------------
From: "Michael Westerman" <[EMAIL PROTECTED]>
Subject: Re: Headless X86 Linux system
Date: Thu, 31 Aug 2000 14:15:13 +1000
hence you set up a xserver and client to comunicate with the box.
sort of like a citrix meta fram client / server box its less restrictive
William Alexander Segraves <[EMAIL PROTECTED]> wrote in message
news:8ognh3$lqf$[EMAIL PROTECTED]...
> You may wish to try this yourself to see (some of) the limitations. Telnet
> to a Linux system from an MSDOS Prompt window on a Windows 95 system. Then
> try some simple tasks you normally do on a Linux system.
>
> Bill Segraves
> Auburn, AL
>
>
> "Hallvard Paulsen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> >
> > William Alexander Segraves wrote:
> > >
> > > In my previous, I failed to mention that the Linux and Windows
machines
> are
> > > on a LAN. Thus, any of the machines can control (in a limited way) one
> or
> > > more of the other Linux machines across the LAN.
> >
> > What do you mean by "in a limited way"
> >
> > --
> >
> > Hallvard P
>
>
------------------------------
From: "Ingemar Lundin" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy
Subject: Re: what's up with Sun?
Date: Thu, 31 Aug 2000 04:21:41 GMT
Well as Windows has as "kill em all and let god sort them out" company
behind it, so does *nix systems need one.
In line with open-source community philosofy? hm well..Sun doesnt seem to
care too much about it, almost acting as if they are a little yeoulos on all
the attentation Linux has gained for the past couple of years, make no doubt
about it, their aim is as commercial as MS, ie make the world evolve around
ther own perfectly good Unix system (Solaris 8)
/IL
"Y � r i k" <[EMAIL PROTECTED]> skrev i meddelandet
news:u5Up5.25575$[EMAIL PROTECTED]...
>
http://dailynews.yahoo.com/h/zd/20000824/tc/is_sun_really_public_enemy_no_1_
_1.html
------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Subject: Re: can't reboot, init high CPU
Date: Thu, 31 Aug 2000 03:11:45 GMT
> es I understand -- but I please note: syslogd was hung! It was a defunct
> zombie. (Normally these processes are in a sleeping state.)
Were the processes in state Z or D? Z means zombie, and uses no resources
other than a slot in the process table. D means uninterruptible sleep,
usually waiting on I/O. When processes hang in state D it means an I/O
problem, often hardware.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
------------------------------
From: "Andrew N. McGuire " <[EMAIL PROTECTED]>
Subject: Re: Linux/unix programs 3312
Date: Wed, 30 Aug 2000 23:33:43 -0500
On 30 Aug 2000, [EMAIL PROTECTED] quoth:
~~ Date: 30 Aug 2000 11:45:48 GMT
~~ From: [EMAIL PROTECTED]
~~ Newsgroups: comp.os.linux.misc
~~ Subject: Linux/unix programs 3312
~~
~~ mailto:[EMAIL PROTECTED]
~~
~~ I sell
~~
That says it all! *plonk*
anm
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Andrew N. McGuire ~
~ [EMAIL PROTECTED] ~
~ "Plan to throw one away; you will, anyhow." - Frederick P. Brooks, Jr. ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: Steve Stellmacher <[EMAIL PROTECTED]>
Subject: Re: Netscape Sucks, I need another option.
Date: Thu, 31 Aug 2000 04:48:25 GMT
Christopher Wong wrote:
> On Wed, 30 Aug 2000 21:16:40 GMT, Yura <[EMAIL PROTECTED]> wrote:
> >In article <[EMAIL PROTECTED]>, Paul Oliver
> ><[EMAIL PROTECTED]> wrote:
> >> Ben Ritchie wrote:
> >>>
> >>> Didn't he say he wanted something that _wasn't_ slow and buggy and
> >>> _can_ display pages correctly? :-)
> >>
> >> I know you're being sarcastic, but Mozilla's getting pretty stable, very
> >> fast (faster than Netscape is anyway;
> >
> >Are you for real? It can not even display menus quickly, I'm talking
> >about menus right below the title of the window. They are so slow,
> >they popdown so slow like if my Pentium2-333 would be a nasty
> >486/33mhz.
>
> When Mozilla advocates say Mozilla is fast, they generally mean the
> rendering speed. The UI, of course, is slow as a banana slug. Yechh.
>
> Chris
Well to be a positive influence on a budding Linux user, you can try to ween
yourself from windoze slowly. My sincere recommnedation and guidance to you
is check out the Maximum Linux website. There is also a Wine or VmWare option
of actually running your IE via emulator - not sure of performance.
There is also Galeon (gnome compliant) and kfm was already mentioned. The
other idea is to try Mosiac. I'm running Mosaic on an older 486 machine
running Win95.
Later,
Steve
------------------------------
From: Eric Laffoon <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux.mandrake,alt.os.linux,linux.dev.apps,alt.icq
Subject: Re: help: kicq core dumps
Date: Wed, 30 Aug 2000 21:42:55 -0700
Boris Friedman wrote:
> I installed mandrake 7.0 with KDE and downloaded icqlib and kicq
> packages. I have kicq0.3.0-4 and icqlib0.1.3-4 both from PowerTools
> distributed by RedHat software. kicq did come up, but when I tried to
> connect to the server, it core dumped. I tried to connect to
> icq1.mirabilis.com port 4000. I didn't remember my ICQ #, so I used 0.
> ICQ gave a segmentation fault with the following stack backtrace
> #0 0x4059a50a in __strdup (s=0x0) at
> ../sysdeps/i386/i486/bits/string.h:490
> #1 0x404d085a in icq_Init (uin=0, password=0x0) at icqlib.c:1158
> #2 0x805a8a5 in QString::find ()
> #3 0x805a4bb in QString::find ()
> #4 0x80585e5 in QString::find ()
> #5 0x8053c8c in QString::find ()
> #6 0x805264c in QString::find ()
> #7 0x4055c9ee in __libc_start_main (
> main=0x80525e0 <QString::find(char, int, bool) const+192>, argc=1,
> argv=0xbffffd14, init=0x80505a0 <_init>, fini=0x8081508 <_fini>,
> rtld_fini=0x4000a570 <_dl_fini>, stack_end=0xbffffd0c)
> at ../sysdeps/generic/libc-start.c:90
>
> Can anybody help me?
>
> Thanks
> Boris
>
kicq 3.0? Hmmm? maybe 0.3? It's hard to keep track. I was thinking kxicq.
Doesn't matter though. these are all relatively unstable and feature light
programs. Mandrake 7.0 comes with licq which will actually chat. I think it
is 0.81 and it works pretty good. You need the new QT fro 0.85 which is on
cooker.
I suggest you use the working software that came with Mandrake instaed of
debugging for Red Hat. ;-)
Eric Laffoon
--
------------------------------
From: "paul snow" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.text.xml,comp.os.linux.development.system
Subject: Re: Linux, XML, and assalting Windows
Date: Thu, 31 Aug 2000 04:54:42 GMT
Let me try this once more. What I asked was if you could see any gain from
separating and maintaing the abstract requirements of software components
from the scripts that render and maintain a particular configuration of
those components across a set of machines.
Would automatic generation of cfengine scripts help? If so, what
information would be needed to generate them? Is that information available
to the developer? How hard would it be to specify?
Bottom line: Can the information needed to drive application delivery be
separated from the process of delivering it?
You are the one with real cfengine experience. Perhaps cfengine scripts can
really only be written by programmers, though I would really doubt this is
the case. The scripting syntax is really simple and to the point.
Paul Snow
[EMAIL PROTECTED]
Christopher Browne <[EMAIL PROTECTED]> wrote in message
news:fvhr5.34905$[EMAIL PROTECTED]...
> Centuries ago, Nostradamus foresaw a time when [EMAIL PROTECTED] would
say:
> >In article <pb_q5.545915$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> >> Centuries ago, Nostradamus foresaw a time when [EMAIL PROTECTED]
> >> would say:
> >> >Sure you could use xml, as long as your install program can write it.
> >> >It would equivalent to the registry in WinX or the assorted /etc
> >files
> >> >(and more) in *x. But these mechanisms work (ugly as they may be in
> >> >their own unique ways). Why are you trying to fix the part of
> >software
> >> >installation & configuration that isn't broken?
> >>
> >> Indeed.
> >>
> >> What the world could use is some Better Tools for managing /etc files.
> >>
> >> For that purpose, I find I very much like cfengine
> >> <http://www.iu.hioslo.no/cfengine/>,
> >> which provides a rule-oriented system with operators for setting up
> >> directory links, modifying text-based config files (which is _very_
> >> nice for modifying things like /etc/hosts, /etc/fstab, and such),
> >> copying files into place, and Lots Of Other Stuff.
> >>
> >> There would be _some_ merit to creating an XML or SGML DTD to describe
> >> cfengine rules, thereby allowing cfengine configuration files to be
> >> managed using the fabled "generic XML editing tools," and validated
> >> before being dropped into place to give at least some _limited_
> >> guarantees of good behaviour.
> >>
> >> That would essentially amount to things like:
> >>
> >> <filestatusrules>
> >> <filestatusrule>
> >> <filename> /etc/printcap </filename>
> >> <mode> 644 </mode>
> >> <owner> root </owner>
> >> <action> fixplain </action>
> >> </filestatusrule>
> >> <!-- replacing "/etc/printcap m=644 o=root action=fixplain" -->
> >> <filestatusrule>
> >> <filename> /usr/sbin/sendmail </filename>
> >> <mode> 755 </mode>
> >> <owner> root </owner>
> >> <action> fixplain </action>
> >> </filestatusrule>
> >> <!-- replacing "/usr/sbin/sendmail m=755 o=root action=fixplain" -
> >->
> >> </filestatusrules>
> >> <editfiles>
> >> <editfile>
> >> <filename>/etc/apt/sources.list </filename>
> >> <appendifnosuchline> deb file:/brownes/knuth/debianstuff unstable
> >main
> >> </appendifnosuchline>
> >> <appendifnosuchline> deb http://alpha.onshore.com/debian local/
> >> </appendifnosuchline>
> >> <appendifnosuchline> deb http://hops.harvestroad.com.au/ debian/
> >> </appendifnosuchline>
> >> </editfile>
> >> <editfile>
> >> <filename> /etc/hosts </filename>
> >> <appendifnosuchline> 192.168.1.5 knuth.brownes.org knuth
> >cache
> >> </appendifnosuchline>
> >> <appendifnosuchline> 192.168.1.1 dantzig.brownes.org dantzig
> >> </appendifnosuchline>
> >> <appendifnosuchline> 192.168.1.7 godel.brownes.org godel
> >> </appendifnosuchline>
> >> </editfile>
> >> </editfiles>
> >>
> >> Mind you, the existing cfengine syntax _works_, which means that it
> >> would be likely to take some convincing to "force" anyone to move over
> >> to using an XML parser for this.
> >
> >The cfengine does indeed cover much of the ground we need to cover.
> >And you have made a very insightful observation in that XML could be
> >used to describe in general what a software component requires. But I
> >do not think the right approach would be to simply write cfengine
> >syntax rules directly into the XML. Instead, why not render the XML
> >into cfengine rules?
>
> Of course, what _really_ begs the question is why XML ever comes up in
> the first place.
>
> It sounds like what you're trying to do is to design something that
> cfengine would be perfectly suited for.
>
> Issues that come up in system configuration include:
> - Dealing with resource locking;
> - Describing and setting permissions;
> - Describing what links should exist, whether those be symbolic links
> or references in files (e.g. - having a host identified in
> /etc/hosts)
>
> The primary merit of XML is that (despite being considerably _more_
> difficult to parse than S-expressions) it is _somewhat_ less difficult
> to parse than SGML, and resembles the HTML that only the most
> pointy-haired of technical managers are incapable of coping with.
>
> XML buys you the ability to get a "cheap parser."
>
> It does not solve the other problems involved in building complex
> systems, which begs the question of why XML need get involved in the
> first place.
>
> >What you need to do is simply identify the data structures that will
> >need to be referenced by the cfengine. Then use a translator to
> >produce the cfengine rules. So, in your example, those constructs such
> >as machine names, ip addresses, filenames, etc. that may vary from
> >system to system should instead be referenced by a XML variable.
>
> Those constructs are intended to be the _invariants_; the whole point
> of the exercise is to establish the IP addresses, hostnames and such.
> They are _never_ generic.
>
> What could vary is where the configuration info may be put, and the
> cfengine language is designed to provide the ability to describe that
> sort of thing.
>
> >These variables represent decision points in how the software
> >component should be rendered, and vary from machine to machine, and
> >network to network.
> >
> >The values for these variables can be collected by prompting the user,
> >or as supplied by a separate XML description.
>
> By the way, I think you're rather confused about the nature of XML.
>
> It isn't a language that can _have_ "variables." It is a static
> language; nothing _can_ vary, so that the notion of "variable" is
> pretty nonsensical. There are entities, consisting of elements, which
> may have attributes. A Lisp-like perspective would view this as
> involving a set of "static bindings."
>
> >The question is, why use XML if I can just write the cfengine rules
> >myself?
>
> A good question indeed.
>
> >We have (in the cfengine) the need for the same kind of separation.
> >The use of cfengine requires a large scripting base which can define
> >the installation and health of a collection of systems on a network.
> >The generation of these scripts is the hardest part of the cfengine
> >approach. I am not a big user of cfengine, but I am unaware of any
> >standard for distributing applications that allows them to simply "drop
> >into" cfengine scripts.
>
> There are no common conventions for this, probably primarily because
> people haven't seriously thought to use it in this way.
>
> It would be a cool idea [for someone else to implement :-)] to build a
> packaging tool that would use cfengine as the installation tool rather
> than the random groupings of shell scripts that are often used with
> RPM and DPKG. I think this would be _reasonably_ practical, and that
> a reasonable design would include several scripts:
>
> a) One cfengine script to move files into place. This would run only
> once, and be fairly "hard coded."
>
> b) One, possibly written in something else, to ask the user and/or
> system any information that needs to be asked. For a web server,
> for instance, this might involve asking what port to accept
> requests on, as well as any proxies to pass requests to.
>
> This script would then 'fill in blanks' to generate other scripts.
>
> If you ever want to redesign configuration, you'd rerun this
> script.
>
> c) A cfengine script would then be set up to "fix up" the config
> files based on the parameters provided by b).
>
> This might involve filling in the HTTP port number, or fixing up
> permissions on files/directories, or indicating log rotation
> policies, or other such stuff.
>
> This script might be re-run as needed to clean up configuration; it
> would be a reasonably good move to rerun this on a regular
> [daily/weekly?] basis.
>
> >Do you think it would help if software were defined in XML abstractions
> >that could be combined and rendered into cfengine scripts in an
> >automated way? Or is there something about cfengine scripts that would
> >make this too difficult. In your XML example, the only problem I see
> >is that you hard coded IP addresses, machine names, directories, and
> >file names, some of which may need to vary if the description were to
> >be generalized. Some of the operations are pretty platform dependent,
> >but that I think is okay.
>
> I hard coded the IP addresses entirely intentionally; that was the
> whole _point_ of the exercise.
>
> As for "defining the software in XML abstractions," that either
> doesn't make sense, if we speak in any sort of "complete" sense, or
> represents something only _marginally_ useful.
>
> In the approach suggested above, there would be a whole "horde" of
> cfengine scripts of the various sorts.
>
> There would be _some_ value in the "second variety" being presented in
> a form that would make it easy to rewrite them into a more efficiently
> processed form.
>
> Thus, if we had the following sequence of "periodically-run" scripts:
> /etc/cfengine/packages/daily/apache
> /etc/cfengine/packages/daily/squid
> /etc/cfengine/packages/daily/zsh
> /etc/cfengine/packages/daily/ftpd
> /etc/cfengine/packages/daily/ftp
> /etc/cfengine/packages/daily/inetd
> /etc/cfengine/packages/daily/cfengine
> ...
>
> There are two approaches:
> a) Have cfengine run through them all individually, or
> b) [Somehow, magically] join them together to generate "master.daily",
> and have cfengine run once on One Big Script.
>
> If the "daily" things were represented in XML, or S-expressions, or
> some other "readily-walkable-tree," it would be straightforward to
> walk through them all and assemble that One Big Script in a somewhat
> optimized order.
>
> On the other hand, it could be just as easy, and require no
> fundamentally new code, to have the main file do:
>
> import:
> Hr00:
> /etc/cfengine/daily.master
>
> And (daily?) rebuild daily.master via:
> "echo 'import:' > /etc/cfengine/daily.master'
> "cd /etc/cfengine; ls packages/daily >> /etc/cfengine/daily.master"
>
> XML doesn't forcibly enter into this _at all_.
> --
> (concatenate 'string "aa454" "@" "freenet.carleton.ca")
> <http://www.hex.net/~cbbrowne/lsf.html>
> "DTDs are not common knowledge because programming students are not
> taught markup. A markup language is not a programming language."
> -- Peter Flynn <[EMAIL PROTECTED]>
------------------------------
From: Akira Yamanita <[EMAIL PROTECTED]>
Subject: Re: Pro*C
Date: Thu, 31 Aug 2000 04:57:49 GMT
[EMAIL PROTECTED] wrote:
>
> Thanks for the first valid answer to this question. It looks like this
> code calls some IBM specific stuff which won't help me however, at least
> I don't think it will. The gererated code looks something like the code
> generated by the Pro*C precompiler.
>
> I do appreciate the response however, it is up to the standards of this
> group which the previous responses were not.
Although I was unable to give a definitive answer, I find it
offensive when someone is so unappreciative as to put down
others' attempts at being helpful.
Maybe you should have stated that non-programmers need not reply.
Perhaps then you would have only gotten responses that are up to
the "standards of this group" as you put it. Either that or you
could have gone to a more specific newsgroup as I had suggested
(such as linux.dev.c-programming).
------------------------------
From: "JoAnn Elliott" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,alt.os.linux.mandrake
Subject: Re: Lilo broken???
Date: Thu, 31 Aug 2000 04:32:10 GMT
I was reading the new group.
What program is this? I had installed linux on my laptop and then decided to
restore my laptop from CD and now the lilo get to just up to the
line...."li..." and I removed the whold linux off and now was trying to
reinstall windows. Even did a fdisk and reformat and still the partial lilo
on reboot. I need to restore the MBR and get that thing off, please help me
as I have worked several hours on this project already.
please respond to me personally as well as the group.
JoAnn Elliott
[EMAIL PROTECTED]
------------------------------
** 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
******************************
