Linux-Development-Sys Digest #182, Volume #6 Sun, 27 Dec 98 09:13:49 EST
Contents:
Re: Registry for Linux - Bad idea (Craig Kelley)
Pussy shot from behind 9857 ([EMAIL PROTECTED])
Re: Registry for Linux - Bad idea (George MacDonald)
Re: 2 stacks? (marian)
Re: Not link libc (H. Peter Anvin)
Re: Virtual PC (H. Peter Anvin)
Re: Threads and PIDs (Bill Morgan)
Re: Registry for Linux - Bad idea (Tristan Wibberley)
Re: Registry for Linux - Bad idea (Tristan Wibberley)
Re: How to run Windows Applications on Linux (Irina Rempt)
Re: Registry for Linux -> Use CORBA!!! (Caspian Maclean)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Craig Kelley)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 26 Dec 1998 22:11:17 -0700
In article <[EMAIL PROTECTED]>,
Michal Mosiewicz <[EMAIL PROTECTED]> wrote:
->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.
1) Nothing is stoping you from doing it yourself.
2) You haven't demonstrated how the comparative advantages outweigh
the disadvantages of not implementing it. For example:
->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.
This is nothing which cannot be done in an easier manner with text
files.
->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.
No it wouldn't. Explain EXACTLY in which ways it is easier to use
your database system than it would be to `tar xvf /my/backup/device`.
->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.
Text files allow this.
->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.
I suppose they have never heard of rdist?
I administer about 8 linux servers over a few dozen acres of land, I
never have to go to any one of them to do anything. I download some
new package and run 'updatemachines' which sends it out to all the
applicable destinations (some machines need certain upgrades while
others do not). It does all of this over ssh, so it is all encrypted
and I can safely send /etc/shadow files around.
Can you think of any more "benefits"?
->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.
Corallary: It's in Windows so we must have it.
->2) It's wrong becouse it's not compatible with my favourite text editor.
Corallary: It doesn't use an API so we must fix it.
->3) It's wrong becouse it might fail, which indirectly means that it will
->fail for sure.
Corallary: Why implement an untested idea? Come back with some
numbers and maybe we can talk.
->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.
And you still have yet to show even one benefit of a registry.
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
From: [EMAIL PROTECTED]
Subject: Pussy shot from behind 9857
Date: 27 Dec 1998 02:14:06 GMT
The sex gallery !
It's all FREE here !
FREE xxx memberships,
passwords,pic,thumbnails,and
much more ! Now featuring live
hott erotic talk !
Cum by today ! WE'RE WAITING !
http://www.thesexgallery.com/
fglnuklecejymrxilybkcwbcelfjjyptrsgdddhqqkud
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sun, 27 Dec 1998 08:00:34 GMT
Craig Kelley wrote:
>
> In article <[EMAIL PROTECTED]>,
> Michal Mosiewicz <[EMAIL PROTECTED]> wrote:
>
> ->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.
>
Ahem, please name 1 idea that is unique to Windows! The Registry
is not unique to MS Windows! Also windows is a fundamentally different
design, anyone who understands the difference can immediatly see that
a Registry as implemented on Windows is simply an unworkable solution
to the problem stated(What problem stated!!!). Quite frankly anything
that comes from Windows should be treated with extreme prejudice!
MS earned the reputation they now have.
> 1) Nothing is stoping you from doing it yourself.
>
> 2) You haven't demonstrated how the comparative advantages outweigh
> the disadvantages of not implementing it. For example:
>
I whole heartedly agree, any design for Linux should pass the
open scrutiny of those who have your wisdom.
> ->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.
>
You are comparing high performance component based applications with
a kernel based operating system. If you try talking about high performance
component based apps on Linux then you might have something.
> This is nothing which cannot be done in an easier manner with text
> files.
Text files are simple/reliable/elegant and in unix/linux have a highly
tuned set of tools to manipulate them(ed/sed/grep/awk/...). It's
what makes unix/linux such a highly leveraged environment! Having
said that, there is also value in the component based application
model. This is why GNOME, KDE are using CORBA to implement a
component framework. At some point in the future it might be nice
to also do component based daemons/servers. At that point an
efficient config system will become more useful. For now we
should build this at a higher level and *AFTER* the technology
proves itself move it downwards towards the daemons. We should
NEVER make the system boot sequence dependent on it. i.e. the
system should ALWAYS be bootable from flat files!
>
> ->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.
>
> No it wouldn't. Explain EXACTLY in which ways it is easier to use
> your database system than it would be to `tar xvf /my/backup/device`.
A RDBMS provides a significantly more powerful environment which might
be useful for some configurations. However these sonfigurations will
most likely be the exception and not the rule. So if such a system is
to be supported then it should *NEVER* be a requirement. Allowing this
as an option would ber a better approach.
>
> ->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.
>
> Text files allow this.
Yes and no. In very large configurations there are many dependencies,
being able to capture this information and manipulate it via RDBMS
systems is valuable in that context. In most small sytems such
a solution is overkill. You are right that text files could be
the lower layer and a RDBMS could/should be used for the additional
functionality i.e. proper layering.
>
> ->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.
>
> I suppose they have never heard of rdist?
or NIS!
>
> I administer about 8 linux servers over a few dozen acres of land, I
> never have to go to any one of them to do anything. I download some
> new package and run 'updatemachines' which sends it out to all the
> applicable destinations (some machines need certain upgrades while
> others do not). It does all of this over ssh, so it is all encrypted
> and I can safely send /etc/shadow files around.
>
> Can you think of any more "benefits"?
>
> ->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.
>
> Corallary: It's in Windows so we must have it.
Windows is flawed. I don't want flawed stuff, therfore I don't want windows
stuff. Q.E.D.
>
> ->2) It's wrong becouse it's not compatible with my favourite text editor.
>
The implementation of a MS style Registry on unix/linux violates a number of the
design principles of unix/linux. You don't appear to understand the *value*
of simplicity nor the purpose of a kernel in the first place. You
might want to try reading some books on the design of unix. Try starting
with "The unix programming environment" by Kernighan and Pike.
<Snip>
--
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: marian <[EMAIL PROTECTED]>
Subject: Re: 2 stacks?
Date: Sun, 27 Dec 1998 19:13:04 +0000
This is a multi-part message in MIME format.
==============A02A45F1907A926DE9035267
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
jan david mol wrote:
> 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
There is a nice patch for gcc that puts flags around the return address part
of the stack. All you do is recompile and it secures your app.
==============A02A45F1907A926DE9035267
Content-Type: text/x-vcard; charset=us-ascii;
name="szczepk.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for marian
Content-Disposition: attachment;
filename="szczepk.vcf"
begin:vcard
n:Szczepkowski;Marian
tel;cell:0418 104 844
tel;fax:+61 3 9362 0529
tel;home:+61 3 9687 7713
tel;work:+61 3 9687 7713
x-mozilla-html:FALSE
org:JOZEP
adr:;;35 Sussex Street;Yarraville;Victoria;3013;Australia
version:2.1
email;internet:[EMAIL PROTECTED]
title:Manager
x-mozilla-cpt:;-25920
fn:Marian Szczepkowski
end:vcard
==============A02A45F1907A926DE9035267==
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: Not link libc
Date: 27 Dec 1998 08:20:42 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: [EMAIL PROTECTED]
In newsgroup: comp.os.linux.development.system
>
> I am writing a small dedicated network server that only makes a few
> system calls. The server uses the new sendfile() system call and to get
> it working with older versions of glibc i had to use the macro
> _syscall4(). Now I want to know if one could skip the libc totally and
> only use direct system calls? OK, it will be a mess and not portable,
> but one can get quite a speedup out of it.
> What is involved? Have anyone done this?
>
Sure you can -- libc is fundamentally just a wrapper around the kernel
system calls. At least theoretically, you could issue them directly.
If you're writing in assembly, on x86, you can use int 0x80 to issue
system calls (with the arguments stuffed into registers); other
platforms use other system call methods, but they are usually similar
in principle.
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bah�'� -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Mis�rables
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: Virtual PC
Date: 27 Dec 1998 09:39:22 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: [EMAIL PROTECTED]
In newsgroup: comp.os.linux.development.system
>
> Do you remember the days when you could buy a card with Z80 and plug it
> into your Apple II so you could run CP/M and it's applications?
>
> And there are similar products from Sun that let you run Windows in an
> add-on card on a SPARCstation.
>
> If that can be done, would it be much more difficult or even much easier
> to buy a PC with 2 cpus and run Linux on one cpu and Windows on the other?
>
Sure, but conventional SMP PC's don't do what you want; they're
designed to run the same OS on both. You want to replicate a lot more
of the surrounding support hardware as well, and add support for
catching I/O coming out of the slave system.
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bah�'� -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Mis�rables
------------------------------
Date: Sun, 27 Dec 1998 00:49:38 +0000
From: Bill Morgan <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Threads and PIDs
strace has a command line switch (-f) that instructs it to trace
child processes that may help follow the new thread.
My question on threads: On my SMP system, why does it seem that
a new thread only runs on the processor that it was created on?
> Jody Hagins wrote in message
>.... Why do I not see any system calls with strace when
> >creating a thread?
>
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sun, 27 Dec 1998 13:07:13 +0000
Reply-To: [EMAIL PROTECTED]
manu wrote:
>
> > Your must not be an engineer. Two motto from my 3rd year systems professor
> > are:;
> > 1) if it aint broke, don't fix it.
>
> and I thought the "arianne" (sp?) rocket disaster a couple of years ago
> made people rethink the smartness of this approach when it comes to
> software!
The difference there was that the old software for arianne 4 wasn't
broke, but it doesn't work for arianne 5, which is a different system.
I have password files, I have bind config files. The password files
work, but no-one is suggesting that we use them for bind config. The
bind config files work for bind config, so lets keep on using them for
that, and nothing else.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sun, 27 Dec 1998 12:45:53 +0000
Reply-To: [EMAIL PROTECTED]
Michal Mosiewicz wrote:
> 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.
>
I think no. 4 is a very valid argument.
No. 1 is most definately stupid.
No. 2 & 3 come together with a very rational argument.
No. 3 obviously is true for every method, but which ever method you use,
you should be able to recover and reset data manually using commonly
available tools from a separate code base. The tool should also be one
that the admin finds easy to use so the fixing can be done quickly and
correctly. It should also allow for the data to be fixed in text form at
least (absolute emergency when things have *really* gone to pot), with
other methods available (such as your one cmdline database query). We
currently have some of that, but are lacking the ability to use
different methods easily.
Maybe someone should start a project to keep the current flexibility (ie
text config files with task specific format) and add the tools to make
world wide network config easy and fast. Unfortunately I do not have the
experience for this. I just want to keep my text config as it is for
single machines and small networks.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development,comp.os.linux.development.apps
From: [EMAIL PROTECTED] (Irina Rempt)
Subject: Re: How to run Windows Applications on Linux
Reply-To: [EMAIL PROTECTED]
Date: Sun, 27 Dec 1998 14:50:09 GMT
[EMAIL PROTECTED] wrote:
> Santa's making a list. If You could have any piece of software ported
> to Linux, other than Microsoft's what would it be?
The Linguist's Shoebox. It's a relatively simple database program with
a few useful quirks, e.g. a tool for making interlinear translations.
And it doesn't run under Wine. If Santa gave me that, I'd never have to
run Windows again...
Irina
--
[EMAIL PROTECTED] http://www.xs4all.nl/~bsarempt/irina/frontpage.html
=============================================================================
Whose fan is in his hand, and he will throughly purge his floor, and
gather his wheat into the garner; but he will burn up the chaff with
unquenchable fire. Matthew 3:12
=============================================================================
------------------------------
From: [EMAIL PROTECTED] (Caspian Maclean)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux -> Use CORBA!!!
Date: 27 Dec 1998 21:18:16 +0800
In article <[EMAIL PROTECTED]>,
George MacDonald <[EMAIL PROTECTED]> wrote:
>For now I would settle for all new apps putting user config
>information in one directory under my $HOME. Currently I
>have about 30 .something files and directories there!!!
>How about it then could everyone start putting user config
>files in
> $HOME/.userStore/applications/${applicationName}
>or something similar?
I like that idea. I don't like .userStore as the name though.
I'd prefer the word seperation to be e.g. .user_store
and the name "user store" doesn't seem quite right for the part
of the home directory that is storing configuration information.
I suggest .conf_store or .config.
------------------------------
** 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
******************************
