Linux-Development-Sys Digest #220, Volume #6 Tue, 5 Jan 99 16:14:55 EST
Contents:
Re: What does "set_fs( )" and "get_fs( )" ? (Josef Moellers)
Re: Registry for Linux - Bad idea (George MacDonald)
Re: Registry for Linux - Bad idea (Peter Samuelson)
modules and unresolved symbols. (James A Simmons)
Re: WDM Emulator, anyone? (Jürgen Schmied)
ISDN Cards (Bryan Hackney)
Re: Sound Blaster Live! (Peter Samuelson)
Re: 2 stacks? (Johan Kullstam)
Re: 2.2.0pre1 kernel: SMBFS: need mount version 6 (I have mount2.9g smbmount (Peter
Samuelson)
Re: ppp-compress-xx problem in 2.2.0-pre4 (Harald Arnesen)
Re: Poor NFS performance from Solaris to Linux (Peter Samuelson)
Re: disheartened gnome developer (Walt)
Re: Redefining time_t (Tristan Wibberley)
Re: Kernel v2.2 (Edward Lee)
Re: Sound Blaster Live! ([EMAIL PROTECTED])
Re: Registry for Linux - Bad idea (Robert Krawitz)
Re: Registry for Linux - Bad idea (Robert Krawitz)
Re: Registry for Linux - Bad idea (Robert Krawitz)
----------------------------------------------------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: What does "set_fs( )" and "get_fs( )" ?
Date: Tue, 05 Jan 1999 14:43:01 +0100
Kenneth Crudup wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says:
>
> >["strace"] outputs system calls in a C-like syntax.
>
> But won't help him in the kernel.
>
> The quick, non-authorative answer: "get/set_fs()" are routines for use in the
> kernel to load the "FS" register, which is commonly used as the destination
> (source? I forget) selector for a number of i386+ assembly op-codes. Most
> likely (I don't have my Rubini nearby) it's used as an assembly-language
> (#asm) hook to access user-space.
Not quite B-{)
You're right in stating that they allow access to the FS register (at
least on the i386 architecture), but AFAIK there is no instruction that
implicitly uses the FS (or the GS register). CS is implicitly used to
access instructions (Code Segment), DS is implicitly used to access data
(Data Segment), SS is implistly used to access stack (Stack Segment) and
ES is implicitly used in accessing the destination in string
instructions (MOVS, CMPS, SCAS, STOS, Extra Segment?). However, to use
FS and GS, one needs to employ a segment prefix.
BTW There are different definitions for [sg]et_fs for the various
architectures.
--
Josef Moellers [EMAIL PROTECTED]
UNIX - Live free or die!
PS Dieser Artikel enthaelt einzig und allein meine persoenlichen
Ansichten!
PS This article contains my own, personal opinion only!
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Tue, 05 Jan 1999 06:37:30 GMT
Tristan Wibberley wrote:
<Snip>
>
> Here is what I propose to be a fact - feel free to explain why I'm wrong
> (I would like to be, but I don't think I am):
> There will never be a single configuration format.
>
> This is because the people who maintain current software don't wan't to
> change it to what you want (they are die hards who wan't to KISS).
>
Agree SMOOCH(System Management with Object Oriented Config Helpers)->linuxconf
> With this fact in mind, you will never have one programatical interface
> and one general tool. So this is not a reason for what you propose.
> Agree?
every config file can be mapped through handlers to a single model. If
every file can be viewed via one browser why can't every config file
be edited by one config_editor tool!
>
> > Wouldn't it be nice if someone who is using
> > vi or emacs on a config file would not clobber changes that are pending in
> > linuxconf?
>
> Why? if the admin wants to do it let them - if your using linuxconf, you
> either won't care to touch the config manually or you know how to avoid
> clobbering.
Hmm, su root is a primitive locking mechanism!
>
> > Wouldn't it be nice if the folks at RedHat could concentrate on
> > making the interface truly first rate rather than coding plugins and allowing
> > for software changes everytime the author of a program gets industrious?
>
> It would be lovely, but whichever system you choose, this will have to
> be done. If a peice of software changes, the linuxconf module must be
> altered (by the way, no smart programmer will rewrite a whole format
> without it being absolutely necessary).
>
> So are you suggesting that once linuxconf gets written, all software
> that it can configure may not change (eg add new keys/remove them?) as
> they would even under your propsed scheme?
>
> -------------------------
>
> The only credible argument I've seen for a change is the network wide
> admin - and I'm not convinced that flat text files still can't do the
> job but with a network protocol for accessing them.
>
A large percentage of system config files have static config information,
applications are more dynamic and components even more so. It's for
the later of these I can see a need for higher levels of service.
In general though you are correct, there are solutions for all these
problem already available. However, each one only takes a bite
out of one part of the problem.
> For this argument:
> There are typically four locations for configuration files:
> /etc
> /usr/etc
> /usr/local/etc
> ${HOME}
>
On other versions of unix, there is /opt, /usr/local, /home/app_name, ...
> /usr/etc can be network mounted, /usr/local/etc can be network mounted,
> ${HOME} can be network mounted.
>
> most of the stuff in /etc (at least with debian) is stuff which should
> not be network mounted (hardware and network connection details), or is
> configurable in scripts so it can be network mounted too.
>
> This gives you the network configuration, stick in a server on the local
> machine so the config server can announce an update, and the server gets
> the system to update and restart relevent portions.
As a developer I want to be able to use a common library to get/set
config info. It would be nice if there was a common file format,
something like X resource files but more flexable. I also
would like to have such a system cope with multiple processes
trying to update the config files. Finally part of my apps
are now components and I want to be able to update a component
in one app(say in GNOME) and have another app recognize the
change and update it's config(say in KDE on another machine).
To do this I have to develop my own code, none of which has
anything to do with my applications functionality. To me
this is the problem that needs to be addressed.
>
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 5 Jan 1999 00:33:10 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Christopher Browne <[EMAIL PROTECTED]>]
> - I'm not sure if either SAM or SMIT are particularly extensible;
> that is one thing that Linuxconf offers that is nice.
Haven't used SAM. (Or Linuxconf.) SMIT is extensible though. Its
config data is a big piece of AIX's ODM database, and to extend it you
run a utility to compile and merge a text file into the ODM. The file
format is rather unwieldy, but, given the task at hand, I don't think I
could have done it better -- it needs to be awfully flexible.
One interesting thing I've noticed about SMIT is that it relies very
heavily on the Unix philosophy of little utilities that each do one
thing well ... kind of takes it to an extreme. To do its tasks it runs
little ksh scripts that, more often than not, are just wrappers around
tiny programs in /usr/sbin each of which does one very specific task.
`/usr/sbin/lsnfsexp' is a good example: it's a Bourne script basically
a couple of getopt and sed statements away from `cat /etc/exports'.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: James A Simmons <[EMAIL PROTECTED]>
Subject: modules and unresolved symbols.
Date: Tue, 5 Jan 1999 10:22:12 -0500
What causes unresolved symbols in modules. Thank you.
James Simmons
Linux System Admin
EdgeNet Inc.
[EMAIL PROTECTED]
http://www.edgeglobal.com/~jsimmons
------------------------------
From: [EMAIL PROTECTED] (Jürgen Schmied)
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Mon, 04 Jan 1999 20:26:31 GMT
Reply-To: [EMAIL PROTECTED]
>It should work with Wine, of course. If there are NT or Linux kernel
>hackers that are interrested, please e-mail me directly.
Sounds good.
If you have questions about interaction with wine and/or what already
existing code from wine you could use, mail me.
Ciao
Juergen
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: ISDN Cards
Date: Tue, 05 Jan 1999 10:02:53 -0600
Reply-To: [EMAIL PROTECTED]
Hello.
Does anyone have any pleasant experience with any ISDN cards? I know the
preferred approach is a Pipeline, but I'm trying to save a little money.
Thanks.
BH
--
Bryan Hackney / BHC / bhackneyatexpress-news.net
*
* Failure teaches only what not to do next time.
*
* Would you trust your mission-critical computing to a company
* that sells stuffed toys?
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.hardware
Subject: Re: Sound Blaster Live!
Date: 5 Jan 1999 02:37:35 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[ncc1701d <[EMAIL PROTECTED]>]
> I was just wondering if anyone using any version of Linux has sound
> working with the Sound Blaster Live! sound card?
Probably not. SBLive! only came out, what, last summer? Linux hasn't
caught on yet as a gaming platform, so gaming hardware generally
doesn't get as much priority from developers as other hardware (SCSI
adapters, for example) considered more essential to a system.
And yes, I believe Creative Labs redesigned the SBLive! with only its
own native API, so you can't really retrofit it with an existing driver
to a similar chipset.
> So the next question is.... Anyone working on it?
Dunno. Check on comp.os.linux.hardware (I'm crossposting), or ask
Creative Labs. It sounds odd to expect driver support from hardware
manufacturers (what are we, Microsoft?) but the Linux bandwagon is
getting bigger and bigger these days; it's only a matter of time before
a given vendor will start to figure out just how many of us take the
Hardware-Compatibility-HOWTO seriously, and start wanting to be on it.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: 2 stacks?
Date: 05 Jan 1999 09:24:27 -0500
[EMAIL PROTECTED] (Peter Samuelson) writes:
> [Stephen Lee]
> > How about making the stack grow forward instead of backward, that way
> > you can only overflow into unused stack memory rather than the return
> > address...
>
> Not a bad idea, but it would sort of require redesigning your CPU.
> Can't do it in software. (No, that *isn't* what `std' and `cld' mean
> on the i386!)
but you can effectively reverse the stack, you just make the memory
objects grow downward!
you could rewrite libc to chase strings backwards, but the easier (and
more perverse, yes?) way would be to simply rewrite the C compiler to
reverse index things so that
char A[10];
var loc
A[0] 0x0100
A[1] 0x00ff
A[2] 0x00fe
&c
reverse the sense of pointer arithmetic
A+2 == 0x00fe
++ decrements pointers, -- increments them &c.
and recompile libc.
--
johan kullstam
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: 2.2.0pre1 kernel: SMBFS: need mount version 6 (I have mount2.9g smbmount
Date: 5 Jan 1999 02:41:47 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Doug McClendon <[EMAIL PROTECTED]>]
> I upgraded to 2.2.0pre1 and can no longer smbmount a win95 share.
> kernel: SMBFS: need mount version 6
> smbmount 2.0.2 (perhaps I should rebuild now that system header files
> have changed?)
Yes, I think so. smbmount will only work on either 2.0 or 2.1/2.2,
depending on which header files it is compiled with. Debian
distributes two binaries.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Harald Arnesen <[EMAIL PROTECTED]>
Subject: Re: ppp-compress-xx problem in 2.2.0-pre4
Date: 04 Jan 1999 12:45:06 +0100
David Ronis <[EMAIL PROTECTED]> writes:
> There is a module request in ppp.c, and I suspect that the problem is
> that I need an alias in /etc/conf.modules. Unfortunately, grepping
> the source tree for ppp-compress doesn't show what it is.
alias ppp-compress-21 bsd_comp
alias ppp-compress-24 ppp_deflate
alias ppp-compress-26 ppp_deflate
--
Harald Arnesen, Apalløkkveien 23 A, N-0956 Oslo, Norway
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Poor NFS performance from Solaris to Linux
Date: 5 Jan 1999 03:58:30 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Steve Linton]
> > On Solaris 2.6 it may be possible to set an option to the NFS
> > server to make it work asynchronously.
[James Hewitt]
> I tried setting the sync option on Linux, but that made transfers
> very, very slow.
Nope, not what you want: `-o sync' basically disables write buffering
on the client. Which would just exacerbate your latency problem.
> > Runnign Linux on the Sun file server is another option.
> :) I have thought about this once or twice, but unfortunately most of
> our servers are workstations as well, and the apps we use are not
> available for Sparc Linux.
Hold that smiley. You might at least try it on a spare machine --
SPARC Linux *does* run Solaris binaries. At least that's the claim. I
don't know how well it works, since I have never run SPARC Linux. (It
would help if I had a SPARC.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Walt <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Tue, 05 Jan 1999 19:46:56 +0000
==============FB62832B82243AC6D815B2A9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
QT is doing an open source version for 2.0. Look at the Kde home page
http://www.kde.org
Qt is by far superior to the gnome development libs. Its WAY easier to write
apps for.
> On 22 Nov 1998 23:03:23 GMT, Christopher B. Browne <[EMAIL PROTECTED]>
> wrote:
> >In contrast, if you write code that uses Qt, you indeed *do* have to
> >negotiate licensing with Troll Tech or an assignee thereof depending on your
> >circumstances.
>
> So they might have to read a license agreement before playing around with
> the software. Big deal. If they don't want to deal with licensing
> issues, then they can just ignore Qt-devel and live in bliss.
>
> >It all really begs the important question:
> >
> > Why do you think Red Hat software would consider it a good idea to
> > promote Troll Tech's programming tools?
> >
> >That really is the upshot of it all.
>
> Red Hat wouldn't be promoting Qt at all, certainly not any more than
> they promoted xv, Metro X, or Applixware.
>
> >If someone installs Red Hat Linux, plays with Qt, and then decides that they
> >like it, they're going to have to pay Troll Tech the >$1K in order to use it
> >for anything commercial.
>
> Again, big deal. So, if they don't want to pay Troll Tech, they can
> just ignore Qt-devel.
>
> >Please explain how this is beneficial to Red Hat Software, when it is pretty
> >clear that they want to be involved in selling development and systems
> >integration services.
>
> It is beneficial in that some customers want Qt.
--
***********************
Walt Boring IV
[EMAIL PROTECTED]
***********************
==============FB62832B82243AC6D815B2A9
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
QT is doing an open source version for 2.0. Look at the Kde
home page
<BR><A HREF="http://www.kde.org">http://www.kde.org</A>
<P>Qt is by far superior to the gnome development libs. Its WAY easier
to write
<BR>apps for.
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>On 22 Nov 1998 23:03:23 GMT, Christopher B. Browne
<[EMAIL PROTECTED]>
<BR>wrote:
<BR>>In contrast, if you write code that uses Qt, you indeed *do* have
to
<BR>>negotiate licensing with Troll Tech or an assignee thereof depending
on your
<BR>>circumstances.
<P>So they might have to read a license agreement before playing around
with
<BR>the software. Big deal. If they don't want to deal with
licensing
<BR>issues, then they can just ignore Qt-devel and live in bliss.
<P>>It all really begs the important question:
<BR>>
<BR>> Why do you think Red Hat software would consider it a
good idea to
<BR>> promote Troll Tech's programming tools?
<BR>>
<BR>>That really is the upshot of it all.
<P>Red Hat wouldn't be promoting Qt at all, certainly not any more than
<BR>they promoted xv, Metro X, or Applixware.
<P>>If someone installs Red Hat Linux, plays with Qt, and then decides
that they
<BR>>like it, they're going to have to pay Troll Tech the >$1K in order
to use it
<BR>>for anything commercial.
<P>Again, big deal. So, if they don't want to pay Troll Tech, they
can
<BR>just ignore Qt-devel.
<P>>Please explain how this is beneficial to Red Hat Software, when it
is pretty
<BR>>clear that they want to be involved in selling development and systems
<BR>>integration services.
<P>It is beneficial in that some customers want Qt.</BLOCKQUOTE>
<PRE>--
***********************
Walt Boring IV
[EMAIL PROTECTED]
***********************</PRE>
</HTML>
==============FB62832B82243AC6D815B2A9==
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: Redefining time_t
Date: Tue, 05 Jan 1999 20:04:15 +0000
Reply-To: [EMAIL PROTECTED]
William McBrine wrote:
>
> BK> The [y2038] problem will fix itself;
>
> A dangerous assumption -- that's probably just what the programmers
> responsible for y2k problems thought.
I agree.
> I'd like to see it fixed now, if possible, while date problems are still
> on everyone's minds. After the y2k "crisis" loses its momentum, things
> might just slide along until 2036 or so. There's bound to be plenty of old
> 32-bit software still running at that time, and if the date problem isn't
> fixed now, it might not be done in time.
Not necessarily now, now. But soon now.
> On my 32-bit Linux system, gcc 2.7.2.1 already supports the "long long"
> type, which is 64 bits. time_t could be changed to a long long. (On my
> 32-bit NetBSD system, off_t is already a long long. Linux could benefit
> from that, too, as it allows files larger than 4 gigs.)
Long long should not be used - see below for why.
Isn't time_t guaranteed to be a 32 bit signed interger value
representing the time since 00:00 1 Jan 1970? If so, the format is not
guaranteed (good :), so no applications manipulate it directly (if they
do, let them break - it's the programmers own stupid fault). So you can
redefine it as 64bits, and change the libc functions. Then recompile and
everythings done except storage and communication formats that assume
32bits. Any sensible format holds a format version key, and the format
can be redefined with the new time_t.
Java applications will be fine.
You have to take this to standards authorities, not Linux newsgroups.
Linux complies to the Posix standards, it is that which must be
modified. Linux will follow.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: Edward Lee <[EMAIL PROTECTED]>
Subject: Re: Kernel v2.2
Date: Tue, 05 Jan 1999 12:12:43 -0800
Nop, modutils is not the right stuff.
Modules-X.X.X is a stealth package.
It is still hidden somewhere out there.
I am wondering why it is not included in the kernel sources.
Without it, i can't build any modules at all.
Piniek (aka Piotr Ingling) wrote:
> Dnia Mon, 04 Jan 1999 17:53:31 -0800, Edward Lee <[EMAIL PROTECTED]>
> napisa³(a):
>
> [...]
> >Where did you get the modules package to compile 2.1.132?Did you find a newer
> >modules package in debian somewhere?
> >I need the "-k" option of genksyms in the modules package.
> >With modules-2.0.0 (in sunsite & tst-11 mirrors), i can't even compile the
> >kernel.
> >
> I guess you mean modutils? Go to your nearest kernel.org mirror (links are on
> www.kernel.org) and from the /pub/linux/kernel/v2.1 directory get the
> modutils-2.1.121.tar.bz2
>
> Piotr Ingling
>
> e-mail: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Sound Blaster Live!
Date: 05 Jan 1999 15:18:32 +0100
"ncc1701d" <[EMAIL PROTECTED]> writes:
[...]
> So the next question is.... Anyone working on it? I'd be happy to beta test
> as I really want sound but have no idea how to even attempt writing a driver
> for the card....
Hmm... I think the new sound driver project has a working SB-Live
driver. What was it's name ... Alsa ?
You should be able to find it at freshmeat; there was an announcement
some days ago.
--Stefan
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 05 Jan 1999 09:26:21 -0500
[EMAIL PROTECTED] writes:
> > It is *not* dated, unscalable nor unwieldy. Using tools such as
> > secure shell or rdist one can easily write a program to update
> > numerous machines automatically. It took me less than an hour to come
> > up with a perl script which updates all of our Linux servers
> > automatically. It does this using RSA encryption, and requires each
> > machine's root password to be typed in before it will execute. The
> > reason why these things are so easy to construct: they use PLAIN OLD
> > TEXT and standard I/O.
>
> You, are a system administrator. You know perl, you're familiar with rdist,
> sounds to me like you used PGP to encrypt outbound data. Clearly, you have a
> command over the systems involved here.
>
> Not everyone does.
Anyone who's managing a large cluster of machines had *better* have
good command over the systems. Trying to hide the fact that large
systems are unpredictable and complex under a thin glossy veneer is
asking for trouble. Better that people understand that up front. A
person not familiar with Unix should not be managing a cluster -- or
more -- of Unix machines. Better that this person should realize it
up front than think that he does know what to do (because of all the
fancy user interfaces).
> > Linuxconf already works just fine, and it has managed to centralize
> > more configuration information in one easy-to-use place than Microsoft
> > has ever dreamed of (SMC is just a ghost of what linuxconf can already
> > do).
>
> It's my understanding that linuxconf works by directly accessing the text
> files when it needs to do work. Wouldn't it be nice if linuxconf only had one
> interface into all the configs?
No, because it still has to know all the gritty details. A sendmail
configuration editor won't be materially simpler to write if it has to
update a bunch of keys in a database vs. updating a sendmail.cf file.
The semantics are the hard part, not the syntax. Rationalizing the
semantics would help a lot more than rationalizing the syntax.
Wouldn't it be nice if someone who is using
> vi or emacs on a config file would not clobber changes that are pending in
> linuxconf?
Fine, so linuxconf can check before writing the file out. For that
matter, linuxconf could touch the file when it first changes its
internal state so that an emacs user will get a nasty message if s/he
tries to edit the file. I'd argue that all this fancy interface stuff
is intended for less knowledgeable users trying to maintain their home
or SOHO systems, not for large installations, and so that this is
somewhat of a red herring.
Wouldn't it be nice if the folks at RedHat could concentrate on
> making the interface truly first rate rather than coding plugins and allowing
> for software changes everytime the author of a program gets industrious?
Again, this is looking at the wrong issue. What changes when "the
author of a program gets industrious" are the semantics -- the schema,
if you will -- not the syntax. For example, there have been some
extensions to inetd.conf. These extensions are generally back
compatible, so an old inetd.conf file will work well enough on a newer
system. However, linuxconf still has to be fixed to know about these
changes. It doesn't matter whether the changes are to a text file or
to relational tables, anything that modifies an inetd configuration
has to know about the changes.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 05 Jan 1999 09:35:11 -0500
[EMAIL PROTECTED] (Christopher Browne) writes:
> - IBM's "SMIT" does decent logging of what it's doing, and can thus be
> instructive to the new administrator to indicate how it reconfigures
> those things that you select.
SMIT's a bit of a strange beast. It's great for making local changes,
but a real pain for making changes across a large cluster or MPP.
Fortunately it lets you preview (in all cases that I'm aware of) the
command that it's about to run, so it is useful for instruction.
SP/2's also have a command called dsh (basically an rsh-to-all-nodes
beast). The usual way I've seen SMIT used is to preview the command
that will run and then dsh it onto all of the nodes of the system.
I wouldn't be using SMIT in the first place if it weren't for the fact
that AIX is so very different from every other Unix variant I've
encountered. Fortunately, it's easy to use it once, see what it does,
and remember for next time around.
> - I'm not sure if either SAM or SMIT are particularly extensible; that
> is one thing that Linuxconf offers that is nice.
SMIT is extensible. A lot of software packages add modules to SMIT.
As to how they're added, I don't know.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 05 Jan 1999 09:39:03 -0500
[EMAIL PROTECTED] writes:
> As I said in a previous post, grafting new interfaces on the text files
> provides a standard interface, but introduces another layer of complexity
> with the middle layer that is the glue between text files and the utilities
> above it.
That's true, but these new interfaces are not critical to the
functioning of the system (unless they write garbage into the
configuration files, which is a risk with any scheme, although I'll
grant that one could argue that it's easier with text files). So if
something goes wrong with this interface layer all is not lost.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
** 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
******************************
