Linux-Development-Sys Digest #242, Volume #6 Sat, 9 Jan 99 06:14:14 EST
Contents:
Re: disheartened gnome developer ([EMAIL PROTECTED])
Re: Open Configuration Storage - was Registry for Linux (Leslie Mikesell)
Re: disheartened gnome developer (Michael Powe)
Re: PCMCIA support under 2.1.131 - how? (Edward A. Falk)
Re: Open Configuration Storage - was Registry for Linux (George MacDonald)
Re: Why I'm dumping Linux, going back to Windblows (Peter Samuelson)
Re: What is function or utility to get PID using Program name? (George MacDonald)
Re: Why I'm dumping Linux, going back to Windblows (Johan Kullstam)
Tx == errors on a 2.1.132 and 2.2.0-pre5 (John v/d Kamp)
Re: Registry for Linux - Bad idea (George MacDonald)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Fri, 08 Jan 1999 17:33:44 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (jedi) wrote:
> Troll Tech, whatever you or I might think of them, are
> still just a company. Idealism and wishful thinking
> won't alter that or change the constraints that companies
> operate under.
Troll Tech, whatever you or I might think of them, is 7 persons,
some of which I know and consider my friends. It is not some sort
of faceless multinational corporation.
I have seen them do a lot more that what was needed as a company, just
because they have ideals. They have always gone the extra mile just
out of kindness. Dammit, if I were them, and had taken as much sillyness
as I know they have, I would have kicked the board and gone home long ago.
Please notice I have no commercial relationship with TT, they owe me
nothing, and I owe them just appreciation for giving things away.
--
Roberto Alsina (KDE developer)
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Open Configuration Storage - was Registry for Linux
Date: 9 Jan 1999 02:00:56 -0600
In article <[EMAIL PROTECTED]>,
Frank Sweetser <[EMAIL PROTECTED]> wrote:
>>
>> And will you be able to copy among the config sets as easily
>> as you can with files to duplicate an existing setup before
>> starting to make changes?
>
>no reason why not to.
If you take the data out of normal files, you somehow need to provide
most of the functionality we take for granted with files: access
permissions, copying, deleting, renaming, compressing, diff'ing,
doing backups, and so on. Or at least import/export with files.
>the application itself won't directly grab the information. it'll just
>call the opstore_get_config (or whatever) function, which in turn consults
>the metadata information, and from there gets the information from a flat
>text file, http, /proc, RDBMS, or whatever other module has been defined.
>the app won't even know where the data is coming from, let alone have to
>really care.
Someone has to care, since someone has to configure it. The last
thing I want is yet-another-protocol service to manage in the name
of making things simpler. If this needs more than ordinary files
and possibly NFS, can it use some existing protocol like http or
LDAP?
Also, if you set up a hierarchy of settings, who will be in
control? I lean towards anarchy myself and like schemes where
the most local system must explictly request data from it's 'parent'
system and is allowed to override or ignore it, but I know others
take the opposite approach.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: Michael Powe <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 08 Jan 1999 23:37:21 -0800
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
>>>>> "Luke" == Luke Scharf <[EMAIL PROTECTED]> writes:
>> Please study the subject (communism) before spouting
>> off. Firstly *nothing* is free. Under classic communism,
>> *everybody works for the common good*. What do you suppose
>> your neighbors would do to you if *you* sat on your duff and
>> didn't *work*?
Luke> I've never read Marx, and I may be biased by my own
Luke> philosophy. I got the impression that in *IDEAL* communism,
Luke> everyone works for the common good, and the people who work
Luke> harder get the respect of the community. Those who are lazy
Luke> get no respect. I.E. it's still capitalism with the
Luke> currency being time & effort in one direction and esteem in
Luke> the other.
Not exactly. Marxism is a branch of communism; ideals of communal
living have been around for a couple millenia. Marx's theory was that
labor was the underlying ethic of societies and that eventually it
would replace the capitalism of bourgeois 19th C Europe. Capitalism
is the opposite of communism in the sense that it values money over
human beings. Marx tried to interpret human history in terms of the
development of labor and its impact on societies; whereas conventional
bourgeois history treats only in terms of the acquisition of money.
Whereas the bourgeois defines "progress" as the increasing efficiency
at accumulating dollars, communism sees progress as the gradual
freeing of the individual from the slavery to material wealth.
Of course, not every fairy tale has a happy ending. If you actually
read some of Marx's writings, though, you'll see why he made such a
huge impression in 3rd world countries. He offered poor people a way
out of their desperation at a time when capitalistic countries offered
them only the dangerous end of the barrel of a gun.
mp
8<---------------how-easy-is-it-to-demunge-an-address?------------------->8
#! /usr/bin/perl # if you are [EMAIL PROTECTED] (Another Luser):
while ($line = <>){ if ($line =~ m/^\s*$/ ){ last; }
if ($line =~ m/^From: (\S+) \(([^()]*)\)/){ $from_address = $1; } }
if ($from_address =~ m/\S+NOSPAM\S+/){ $x = index($from_address, NOSPAM);
substr($from_address, $x, 6+1) = ""; printf("The real address is %s\n",
$from_address);}else { printf("No munge, just plain %s\n",$from_address);}
printf("\nBrought to you by the Truth In Mail Headers Foundation\n");
8<-----------------------here's-one-example------------------------------>8
- --
Michael Powe
[EMAIL PROTECTED] http://www.trollope.org
Portland, Oregon USA
=====BEGIN PGP SIGNATURE=====
Version: GnuPG v0.9.0 (GNU/Linux)
Comment: Encrypted with Mailcrypt 3.5.1 and GNU Privacy Guard
iD8DBQE2lwb6755rgEMD+T8RAjvtAKCeAoAa1bSdSj7mkHqxVvZD6J2WvACgkAoS
odfbG6sQh8TCsrgYM+PEEiY=
=lOMr
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Edward A. Falk)
Subject: Re: PCMCIA support under 2.1.131 - how?
Date: 8 Jan 1999 23:22:20 -0800
>PCMCIA is a separate package. The latest version may be 3.0.7.
Hi thanx to all who replied. I found the drivers at stanford. I'm
a little surpised there wasn't at least a pointer to them in the
kernel README file.
-ed falk
--
-ed falk, [EMAIL PROTECTED] *********************#*********
Visit http://www.rahul.net/falk/whatToDo.html ****#*#**************F******!**
and read 12 Simple Things You Can Do ****!*!!**********!************
to Save the Internet ***************#****#******#**
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Open Configuration Storage - was Registry for Linux
Date: Sat, 09 Jan 1999 08:56:16 GMT
Leslie Mikesell wrote:
>
> In article <[EMAIL PROTECTED]>,
> Frank Sweetser <[EMAIL PROTECTED]> wrote:
> >>
> >> And will you be able to copy among the config sets as easily
> >> as you can with files to duplicate an existing setup before
> >> starting to make changes?
> >
> >no reason why not to.
>
> If you take the data out of normal files, you somehow need to provide
> most of the functionality we take for granted with files: access
> permissions, copying, deleting, renaming, compressing, diff'ing,
> doing backups, and so on. Or at least import/export with files.
>
What do you mean? Perhaps you misunderstand. It is my intention to
allow the use of flat files to store the data. The configuration
service would have a module that understands the format of
the particular file thats being used to store the data.
I firmly believe that the decisions with regards to storage should
be made by the administrators of a system. For example on a large
system many of the values may be stored in a Database, if that is
the method of data management that is chosen by the administrators.
In other words a configuration service should be storage and
access neutral. I think those decisions are policy decisions
and I don't believe a config service should dictate policy.
A file format that is text based and human readable/editable
will be supported and will be the default. Sites that wish to
use other storage and access mechanism while have to configure
the config service to do it that way. This will give CLI based
users a familiar model, it will empower GUI models with
writable config's and it will be extensible to networking environments
where configuration issues are complex and require other
mechanism. Also supported will be greater security granularity.
This indeed will be a complex system, however the model provided
to developers will be simple. Consider what goes on behind
gethostbyname();
> >the application itself won't directly grab the information. it'll just
> >call the opstore_get_config (or whatever) function, which in turn consults
> >the metadata information, and from there gets the information from a flat
> >text file, http, /proc, RDBMS, or whatever other module has been defined.
> >the app won't even know where the data is coming from, let alone have to
> >really care.
>
> Someone has to care, since someone has to configure it. The last
> thing I want is yet-another-protocol service to manage in the name
> of making things simpler. If this needs more than ordinary files
> and possibly NFS, can it use some existing protocol like http or
> LDAP?
There is a protocol ACAP, see RFC 2244 which is designed to addess
the networking aspect of application configuration. But it should
be hidden behind a common interface, so that normal flat files
can be used if desired. You should visit
http://andrew2.andrew.cmu.edu/cyrus/acap/
They have one doc that does a comparison of the various protocols
and why they created a new one. My approach is to build an
architecture that can use any of these, perhaps with some limitations.
Decisions as to what level of security, performance, extra features
should be left to site administrators as much as possible. Admin
policy will have a significant bearing on these decisions. At the
simplest level one needs a
get - i.e. read, select, ...
and to store some kind of
set - i.e. write, update, ...
and perhaps some kind of
start transaction - open, ...
end transaction - close, ..
The goal is to keep it as simple as posssible, so that it can map
onto each of the underlying mechanisms.
>
> Also, if you set up a hierarchy of settings, who will be in
> control? I lean towards anarchy myself and like schemes where
> the most local system must explictly request data from it's 'parent'
> system and is allowed to override or ignore it, but I know others
> take the opposite approach.
Good question. I consider control a policy decision, so a system
should be configured to support the desired control/security model.
What you describe is close to the current model, i.e users
generally can set most values. Some are defined in files that are
only writeably by another user(typically root). In single user
systems, peoples home systems, small offices ... that kind of model
works fine. However if a machine is located in a medium to
large sized network, things change. More centralized storage
of information can be desirable for administration and security
reasons. The solution I am proposing considers this just as
valid as the "anarchy" mode you describe. i.e. yet another
policy decision, and opStore won't be dictating policy. So,
don't fear, I have no plans of removing text editable
files or cutting users off from control. In fact I may
be able to open it up a little bit more, again assuming
things are configured that way.
It would be nice to be able to throw a switch and allow
an app running with a specific uid access to write a
config variable used by every account on a machine.
i.e. support a "single user, multiple account mode".
Impossible to do all this? Absolutely not! Difficult?
Of course, making complex things simple always is.
Don't think I can do it? Have a look at treeps,
http://24.1.97.22/gmd/tps/treepsfm.html
Making an intuative view of the processes running
on your system is no piece of cake.
--
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: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: 9 Jan 1999 02:51:32 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Johan Kullstam]
> > every program feeling that it's its god-given right to introduce
> > its very own slightly incompatible version of regexp syntax.
[Tristan Wibberley <[EMAIL PROTECTED]>]
> AFAIK there are basic syntax and advanced syntax, no more.
There is basic (grep) and advanced (egrep). But then Emacs has some
extentions (aggravated by the fact that in a LISP string object you
have to escape all your backslashes), and Perl has a *lot* of
extensions. I don't know Python. I also don't know the relevant state
of [onmg]awk.
I think the classic regexp apps (vi, sed, etc) mostly use regex(3).
Which I think is pretty POSIX-confined. But even so there exist at
least two or three semi-standard but independent implementations of the
regex library (which contains regex(3)), and many apps come with the
source to one of those in case your brand of Unix doesn't have a system
copy. The upshot being that even in an app that doesn't intend to be
nonstandard, it's anyone's guess whether it supports `+' in a regexp.
I have a theory that any application that gains sufficient complexity
eventually forks off Henry Spencer's regex code just to add
incompatible syntax.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Subject: Re: What is function or utility to get PID using Program name?
Date: Sat, 09 Jan 1999 09:18:46 GMT
JiSook Kim wrote:
>
> Hi!
>
> What is function or utility to get PID using Program name?
>
> thanks, jisook.
Try "pidof"
or this should work as well
grep Name /proc/[0-9]*/status | awk -F/ '/xearth$/ {print $3}'
Change xearth to be whatever process name you are using.
--
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)
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 09 Jan 1999 05:33:27 -0500
[EMAIL PROTECTED] (Leslie Mikesell) writes:
> In article <[EMAIL PROTECTED]>,
> Johan Kullstam <[EMAIL PROTECTED]> wrote:
>
> >well my point is that there are a lot of options and it's hard to
> >remember them. i know the main ones for tar and grep and ls, but cpio
> >is hopeless.
>
> Better to have the options and have to view the man page in another
> window sometimes than to need the option and not have it.
it's not the *presence* of options that i am railing against. it's
the almost total lack of *consistency*. if there were more
consistency i wouldn't *have* to keep consulting man pages.
--
Johan Kullstam [[EMAIL PROTECTED]] Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED] (John v/d Kamp)
Subject: Tx == errors on a 2.1.132 and 2.2.0-pre5
Date: Fri, 08 Jan 1999 21:19:25 GMT
Hi !
I downloaded a 2.1.132 and a 2.2.0-pre5 and took a look at them both,
but what i get is a lot of trouble with my eth0 cards...
instead of getting Tx, I only get error's ... but the connections seem
right. If I type 'ifconfig' I see all good Rx stuff, but the Tx stuff
is only errors and no good. I use RedHat 5.1. Did I forget something
to upgrade, or did I forget to compile somthing for in the kernel?
2.0.34 works just fine
btw. I have a ide zip, and scsi emu on for my writer. but now the zip
becomes a scsi drive too, and I can't find it anymore!!! please tell
me what device I should be using or where to find it what the right
device it is. And why does a zip drive change from /dev/hdd1 to
/dev/hdd4 and back when I eject a disk? (if I put in the same that was
ejected, this doesn't happen).
Thanks,
John
John v/d Kamp
e-mail: [EMAIL PROTECTED]
homepage: http://huizen.nhkanaal.nl/~blade
ln -sf /dev/null /dev/brain
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Fri, 08 Jan 1999 21:50:02 GMT
Johan Kullstam wrote:
>
> George MacDonald <[EMAIL PROTECTED]> writes:
>
> > Nice solution! That handles the new conventions on linux perfectly.
> > Linux seems a bit more organized and better thought out than other
> > unix implementations, well at least with regards to configuration.
> >
> > I would like one file that is higher up than than appconf.d that
> > allows the location of appconf.d to be configured. My reasoning is that
> > on other unix's the /etc area is in root is sometimes quite small, so may
> > not be capabable of holding it. I can envisage other systems
> > wanting to put the "appconf.d" directory in /usr/lib or usr/share,
> > ... I kind of like the linux way, but perhaps we should allow for
> > the placement elsewhere.
>
> put user application configuration in /usr/etc. place systems/boot
> stuff in /etc. this mirrors the /usr/bin v /bin and /usr/sbin v /sbin
> splits.
>
> also, there's no need for the `conf.d' part. simply being part of
> /etc means its a configuration file. the `d' can maybe stay but i
> think that's redundant too.
>
> if the application has *one* configuration file, it could be a
> straight file under the appropriate etc directory. if the application
> has more than one file, make a directory.
>
> it it not so clear how to manage shared data, i.e., two applications
> want the same data (e.g., bash and csh both want a default path. i'd
> be nice to maintain one and have the other follow automatically).
> perhaps links (hard or soft) would be useful.
>
> > You definately nailed one of the problems though!!
Information should be defined in one place only, except where it
is replicated for performance and/or for service discontinuty reasons.
--
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)
------------------------------
** 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
******************************
