Linux-Development-Sys Digest #179, Volume #6 Sat, 26 Dec 98 09:15:16 EST
Contents:
Re: Registry for Linux - Bad idea (Steven Howe)
Re: Registry for Linux - Bad idea (Steven Howe)
Re: things I'd pay to have developed for Linux... (Tim Smith)
Re: Santa's List ([EMAIL PROTECTED])
Re: Possible MS legal threats to Linux and/or OSS ("John Burton")
Re: ppp dialin (with VJ compression) problems with dev.kernel 2.1.132 (Carsten Prinz)
Re: Registry for Linux - Bad idea (Nick Andrew)
2 stacks? (jan david mol)
----------------------------------------------------------------------------
From: Steven Howe <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sat, 26 Dec 1998 08:45:46 +0000
Reply-To: [EMAIL PROTECTED]
Michal Mosiewicz wrote:
> Richard RUDEK wrote:
> > [...]
> > I agree, a registry for linux is a bad idea. But I don't see how a standard
> > configuration procedure "naturally suggests a single file".
>
> Why is it a bad idea?
>
> Or, let me put it this way - what is better than a single database
> optimised for persistent configuration storage?
>
> In fact people are too tied to those fancy configuration files. They
> start to complain when it comes to start some netscape or some another
> configuration-hungry program. Just look at how your system (I mean
> Linux) starts. It takes a minute or so to boot up. Much of this time is
> spent on setting up the state of kernel. It takes hundreds of files to
> be open, tens of programs to be started and a lot of scripts to be
> interpreted. It consumes a lot of time. Unnecessary time.
>
> Some people say that is dangerous to have a single database
> configuration database. Isn't it dangerous to have a single filesystem?
> I'm far from suggesting that it should be a single file - it might be a
> single device. Sometime this database would be accessible as a set of
> text files (for text-addicted people) but the point is that a common
> filesystem is not necessary optimal database.
>
> Mike
>
> --
> WWW: http://www.lodz.pdi.net/~mimo tel: Int. Acc. Code + 48 42 2148340
> add: Michal Mosiewicz * Bugaj 66 m.54 * 95-200 Pabianice * POLAND
I can't remember how many times Win95 would not start because today it didn't
recognize my ethernet card. The Registry faulted,and I have to reload. Under
Linux, networking would not start. But the system would come up.These seperate
and independent config files let each deamon run independently of one another,
reducing the chance of a boot lockup. A directory of config files is better
then a single 'registry' file. Modification dates are the same for a registry
file. For unique config files, they can be a trace log.
------------------------------
From: Steven Howe <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sat, 26 Dec 1998 09:29:46 +0000
Reply-To: [EMAIL PROTECTED]
Michal Mosiewicz wrote:
> Robert Krawitz wrote:
> >[...]
> > > b) kernel space managment to accomplish ownership of database records
> > > and access rights (not only per user, but also per application)
> >
> > Why must it be in the kernel? That's just adding more bloat to the
> > kernel for something that can be done perfectly well in user space.
>
> What bloat? How do you feel your kernel is bloated by (stupid) things
> like, for example, consoles. They bloating you beautifully pure,
> lightweight kernel just to assure that you friend can't trash on your
> console and there is no anarchy in access to your screen. That's a
> bloat. Note how much bloat it appeared in the kernel since it came out.
>
> This is a kind of change-o-foby. I remember those discussions on things
> like KGI. Why is that so, that if there is anything similiar to
> something in Windows, there is always a natural 'I vote - no!' from many
> Linux users. After time resistance gets weaker and somebody notices some
> good sides of the solution. But precious time is wasted on disregarding
> every idea which is similiar to what we know from Windows.
>
> > This is not an issue of personal preferences. It's an issue of being
> > able to recover the system with minimal tools when something goes
> > wrong.
>
> My personal acceptance for global persistent storage is based on
> experience. I have some projects, that store their configurations in the
> database. And the system reconfigures online, sometimes several times
> per second. And I have no problems with recovering. It just recovers
> it's configuration with the rest of the database with a single command
> typed at the command line. But still I would like to be able to
> reconfigure the core of apache in the same manner I do it for my
> modules. Moreover it would be much easier to recover the whole system
> from the database.
>
> If you need more informations about how easy it's recover the system
> with chaotic configuration management, just go to a bigger ISP (using
> Linuks of course). In many cases things like passwords, aliases, domains
> and similiar configuration files are only shadows of some central
> database. That's why many ISP servers react on account changes in an
> hour or even a day. It's becouse they are not able to update those
> shadows more frequently with accurate effectivness. Ask them if it's
> easier to restore all informations from one central source, or to check
> if all the information is consistent.
>
> >And a simple text editor like ed is much less likely to go
> > wrong than some fancy graphical tool that requires X to be running and
> > has who knows what buffer overrun bugs that get triggered by some bit
> > getting flipped deep in the bowels of the index.
>
> What I had written had nothing to do with fancy graphical tools.
>
> > Humans are a lot more adaptable than computers. If I misspell this
> > worrd, I can see it very easily and fix it, if it's in a readable text
> > file. If I flip a bit in the index, unless the tools using the
> > database are very clever, this error won't be caught.
>
> I don't argue with this argumentation cause it's irrational. I never
> said that admin should type things in hex.
>
> >[...]
> > Whereas currently with Linux if it won't boot because there's some
> > configuration problem, I just slip in my handy Tom's root/boot disk,
> > mount the offending root filesystem, hunt around for the problem, and
> > back in business.
>
> Good you have such a small system to manage.
>
> >[...]
> > YaST, on SuSE, has an interesting approach of its own. It's basically
> > a terminal-driven front end to a batch of config files, and when you
> > make a change and then tell it to go ahead, it reruns the necessary
> > configuration scripts. Red Hat's control panel is similar, and I
> > think it sends the SIGHUP's itself.
>
> Sure there are tools to easier this stuff. As I said, on my servers
> ordinary configuration files tend to play a secondary role. Most of the
> things are being done in the central database, then shadowed to config
> files. Of course, if anybody is too tied to his vi - go ahead. But
> please, this is irrational argument, that every configuration must be
> done using text tool. Next irrational argument is that the system state
> description should be decentralised - it's naturally best if we can
> backup/restore the whole using single commands.
>
> And finally I should clarify, that my point is not to complain about
> that I have no registry (since I have some partial forms of that where I
> need it), but I _do_ complain about some people's hard minds. Arguments
> like:
>
> 1) It's wrong becouse it's built in windows.
> 2) It's wrong becouse it's not compatible with my favourite text editor.
> 3) It's wrong becouse it might fail, which indirectly means that it will
> fail for sure.
> 4) It's wrong becouse it's not made of chocolate.
>
> are these kind of arguments enough to dump every idea to /dev/null. Even
> the brightest.
>
> Mike
>
> --
> WWW: http://www.lodz.pdi.net/~mimo tel: Int. Acc. Code + 48 42 2148340
> add: Michal Mosiewicz * Bugaj 66 m.54 * 95-200 Pabianice * POLAND
Your must not be an engineer. Two motto from my 3rd year systems professor
are:;
1) if it aint broke, don't fix it.
2) keep it simple, stupid!
Most of your ideas violate good sound engineering policies. Since most of
the processes you wish to 'control' are independent in design and upgrade, a
single configuration tool would need constant updates as the developers of
at, cron, inetd, etc. update their work. You would need a central
management site (like Microsoft) to control it all. These processes are not
broke! they are independent. They don't need fixing via BigBrother means.
Text files are about as simple as one can get. One example that happned
after a typical Solaris installl. resolv.conf was not configured. I had no
nameserver and the master yp machine was not configured. Weill I just
created a resolv.conf and vi'ed nsswitch.conf to fix the system.
=====================
nameserver xxx
domain yyy.zzz.ddd
order host bind
=====================
Window's network configuration requires quite a few panels to set these
three lines. I generally set these three lines via a command like:
echo "nameserver xxx" >> /etc/resolv.conf
no editor needed. With such simple tools I have recovered unix systems. A
database is much to difficult to fix at such a low level (maybe a binary
editor would do?). Simple text files may not be as wizbang as a registry,
but they do work and are easy to configure and recover. Simple can be
better.
Look at our laws. Expansive, complex and difficult to fix.Then look at our
constitution. Simple, brief and no loop holes. Fixes are rarely need.
Our laws need the consitution; the consitution does not need our laws.
Registries need complex support systems to work, like laws.
config files need nothing but a text editor, like the consitution just a
pen.
Steven Howe
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Tim Smith)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: things I'd pay to have developed for Linux...
Date: 26 Dec 1998 01:33:32 -0800
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>I agree on that point. The people who are working on ext2 ACL's say
>that they don't want to make them standard yet because (among other
>reasons) it takes a lot more than kernel support to actually *use*
>ACL's -- a lot of user space has to be aware of them. I say, put ACL's
>in the kernel and let user space evolve. Nobody has to fully deploy
>them right away -- but it'd be nice to have them there so people could
>start patching GNU fileutils, etc. (I am *not* saying rush the job.
>Good technical design *does* of course have to come first.)
Actually, you can do ACL's in a way that requires very little changes to
user-mode code, yet still provides most of the useful functionality. The
key is to realize that for much, if not most, of the things people need
ACL's for, ACL's would work fine if they were attached to specific paths,
rather than to specific files.
An example of this kind of thing was ACL's on TOPS-10. ACL's were contained
in a file named ACCESS.USR. When the permissions on a file would not allow
a given operation, the system would check the ACCESS.USR of the file's owner.
ACCESS.USR contain a series of entries. Each entry had fields that specified
the following:
1. The name of a file. Wildcards were allowed.
2. The type of access being requested. E.g., read, write, execute.
3. The user/group requesting access. Wildcards were allowed. I think lists
were allowed, too.
4. The name of the program requesting access. Wildcards were allowed.
5. Whether access was to be allowed or denied.
The system would go through 'till it found an entry that matched the
operating being attempted, and that would tell if it was allowed or not.
This is not quite as flexible as an ACL scheme where the ACL is associated
with a particular file, and all the user utilities know how to manipulate
and preserve it, but by using wildcard and a little organization, it will
cover most situations.
(By the way...we've had this discussion before. I just searched DejaNews
to find an earlier description I posted of TOPS-10 ACL's, and I found a post
from last March where you were talking about ACLs for ext2fs, and I referred
you to a post of mine)
--Tim Smith
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Santa's List
Date: Sat, 26 Dec 1998 09:32:46 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> >
> > In article <75sml7$12ec$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Frank Miles) wrote:
> > > In article <[EMAIL PROTECTED]>,
> > > Adam P. Jenkins <[EMAIL PROTECTED]> wrote:
> > > >[EMAIL PROTECTED] writes:
> > > >> Have you tried WABI? Caldera offers it via mail-order. It isn't
freeware.
> > > >> Quicken is the ONLY application I still gave to run on Windows 95. At
work
> > > >> I need to run Lotus Notes (for security and compliance reasons).
> > > >
> > > >I couldn't find anything about WABI on Caldera's web page. Does WABI
> > > >support Win32? Last I heard it only supported 16-bit Win3.1 apps.
> > > >Please correct me if I'm wrong. Thanks.
> > >
> > > WABI is no more unless you can buy it from someone other than Caldera.
> > > Linux Mall used to have it.
> > > It only supported the Win3.1 apps AFAIK (that's all I use it for, and no
> > > you can't have it).
> >
> > I have a copy. I've never installed it. I can do almost everything
> > (except Quicken) using available Linux applications. Usually faster
> > and cheaper than with Windows 95/NT.
> >
> > After trying to reinstall Windows 98 for a friend, I want nothing to
> > do with that ugly mess. Windows 98 made a Slackware install look
> > friendly. I think I only had to reboot 14 times.
> >
> > > Wine (notably this last version, wine-981211) is getting better but it's
> > > not there yet.
> >
> > Santa's making a list. If You could have any piece of software ported
> > to Linux, other than Microsoft's what would it be?
> >
>
> mmm...., the programming tools are for ok me, so it would have to
> be Eudora and Agent. They better hurry up, otherwise the KDE/Gnome
> people will
> make something that is sufficient simple to use for the common user.
>
> Espen
>
Posix4 library
--
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "John Burton" <[EMAIL PROTECTED]>
Crossposted-To: misc.legal.computing
Subject: Re: Possible MS legal threats to Linux and/or OSS
Date: Sat, 26 Dec 1998 12:04:12 -0000
William Marvin wrote in message <[EMAIL PROTECTED]>...
>In <[EMAIL PROTECTED]>, on 12/22/98
> at 11:54 AM, Scott Johnson <[EMAIL PROTECTED]> said:
>
>>Even a damage of prestige would be significant. MS is well-known for
>>using FUD as a marketing tactic, and legal action (or even threats of
>>legal action) and/or hints of infringement might be enough to frighten
>>IS managers and CIOs into avoiding OSS...
>
>As long as Linux doesn't show signs of expanding beyond cult status, I
>don't think MS would have strategic reasons to attack it. Even assuming
>that the practical and legal obstacles could be overcome.
Microsoft would have no need to use legal means to attack linux if
it ever seriously affects their market. They just need to make their own
version of linux, but replace the current rather useless GUI with a better
one of their own which they retain copyright on. They can then sell
word etc. for it (which is how they make their money) and it would still
be linux, but you'd need to buy the microsoft version to run the decent
applications.
------------------------------
From: Carsten Prinz <[EMAIL PROTECTED]>
Subject: Re: ppp dialin (with VJ compression) problems with dev.kernel 2.1.132
Date: Sat, 26 Dec 1998 11:27:37 GMT
>>>>>>>>>>>>>>>>>> Urspr=FCngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 25.12.98, 18:09:30, schrieb Sion Masamune <[EMAIL PROTECTED]> zum=20
Thema ppp dialin (with VJ compression) problems with dev.kernel 2.1.132:=
> Hi there,
> i dunno if this is a stupid question, but howcome the vj-compression
> doesn't work with
> dev. kernel 2.1.132 ?
> 2.0.36 works fine, but whenever i try to dail-in to my isp i get the
> following errors:
> Dec 25 01:55:44 nomad modprobe: can't locate module ppp-compress-21
> Dec 25 01:55:44 nomad modprobe: can't locate module ppp-compress-26
> Dec 25 01:55:44 nomad modprobe: can't locate module ppp-compress-24
[snip]
The aliases for the compression modules are
alias ppp-compress-21 bsd_comp
alias ppp-compress-24 ppp_deflate
alias ppp-compress-26 off
===========================
Carsten Prinz
[EMAIL PROTECTED]
===========================
------------------------------
From: [EMAIL PROTECTED] (Nick Andrew)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 27 Dec 1998 00:29:31 +1100
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Victor
Lowther) writes:
>The main reason that flat text is nice IMHO is fault-tolerance. Try
>rm -rf /etc on a unix box, rebooting the system and see what happens.
It's fault resistant: the settings don't change until some person makes
a change. If the settings weren't changed and the kernel dies for some
reason, just reboot and it will work again.
Contrast with Win9x: applications are changing settings in the registry
*by themselves* all the time - if the "OS" dies, application settings
(even other applications) may be corrupt upon reboot.
Nick.
--
Zeta Internet SP4 Fax: +61-2-9233-6545 Voice: 9231-9400
G.P.O. Box 3400, Sydney NSW 1043 http://www.zeta.org.au/
------------------------------
From: jan david mol <[EMAIL PROTECTED]>
Subject: 2 stacks?
Date: 26 Dec 1998 13:41:31 GMT
Just an idea thrown into the world:
Would it be worth while to split our traditional stack into 2 stacks,
one to hold local variables/parameters and the other to hold return
addresses. That way, if a program screws up its local variables it cant
touch its calling stack (well less easy anyway), thus preserving
back-trace info which could get screwed up along otherwise.
I'm not sure if this is one for the GCC compiler guys or the kernel ones..
Of course if this is stuff which has to be implemented at kernel level it
would mean a slowdown in context-switches.. but a kernel compile option
could take care of that.. like it does with the profiling support. Maybe
problems could be at assembler level, for the CPU's I know only support
one stack natively.
Anyway, I know MY debugging sessions would be a hell of a lot easier when
the bugs don't mess up back-trace, and rewriting the headers/footers of a
zillion functions to use a separate memory block for local variables isn't
something one wants to waste time on.
--
Tsjauw,
Jan David
------------------------------
** 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
******************************
