Linux-Development-Sys Digest #127, Volume #7 Tue, 31 Aug 99 02:14:15 EDT
Contents:
Re: LILO oddity. (Greg de Freitas)
Re: why not C++? (Phil Hunt)
Eschewing Filesystems... (Christopher Browne)
Re: libc or glibc? (Christopher Browne)
linux driver examples from rubini ([EMAIL PROTECTED])
SCSI device scan order. (Seth Mason)
Re: LispOS? (Christopher Browne)
Re: MySQL, chroot and shared libs ("Sean O'Dell")
Re: how to 'scandisk' in linux (H. Peter Anvin)
Re: MySQL, chroot and shared libs ("Sean O'Dell")
Re: Avoid Zombies (Kaz Kylheku)
Re: Normal User X shutdown (Keith Wright)
Re: why not C++? (Benoit Goudreault-Emond)
Re: what is the largest partition Linux file system can handle? (Mark Hahn)
Re: Normal User X shutdown (Kaz Kylheku)
Re: The optimization debate (was: why not C++?) (Christopher Browne)
----------------------------------------------------------------------------
From: Greg de Freitas <[EMAIL PROTECTED]>
Subject: Re: LILO oddity.
Date: Mon, 30 Aug 1999 12:44:23 +0000
Reply-To: [EMAIL PROTECTED]
Peter Samuelson wrote:
>
> [Omri Schwarz <[EMAIL PROTECTED]>]
> > I'm in 2.2.7. I build 2.2.10.
> > I make a new first entry for 2.2.10 in lilo.conf.
> >
> > I run lilo. no error messages.
> >
> > I reboot. Boom, I'm back in 2.2.7.
>
Maybe you're booting from a DIFFERENT lilo?
I mean the "boot = /dev/???[N]" line _may_ have been changed ! (by you!)
Someone else suggested posting your lilo.conf here.
I second that.
:-)
--
Ciao 4 now, Greg.
# Email : mailto:[EMAIL PROTECTED] #
# Email : mailto:[EMAIL PROTECTED] #
# To Live, To Love, To Learn, To Leave A Legacy. #
------------------------------
From: [EMAIL PROTECTED] (Phil Hunt)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 30 Aug 99 22:04:29 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
> [EMAIL PROTECTED] (Phil Hunt) wrote:
> >Since you feel like that, may I suggest you design something better.
>
> Thats a bit like asking someone who thinks the space shuttle is an
> over complex
> and over expensive piece of kit to go design a better vehicle in their
> garage.
I disagree. I contend that it is possible for a person working on their
own in their spare time to design a reasonable programming language, and
implement a (perhaps crude and scaled-down) version of same. For
example, Python.
> However , your bluff is (almost) called my friend:
>
> ftp://sunsite.unc.edu/pub/languages/loor/loor020.tgz
>
> Its an interpreted OO language I'm working on in my spare time.
Good for you!
> Its not
> brilliant and isn't going to change the face of programming as we know it
> but I think it proves that I can put at least some of my money where my
> mouth is.
--
Phil [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Eschewing Filesystems...
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 02:18:24 GMT
Note: Followup redirected, as this isn't relevant to Linux or UNIX.
On 30 Aug 1999 18:00:51 -0300, SPAM THIS!! <[EMAIL PROTECTED]> wrote:
>On 30 Aug 1999 20:22:00 GMT, Vladimir Z. Nuri
<[EMAIL PROTECTED]> puked this up onto the newsgroups:
>>this is a pet peeve of mine that I plan to write a new essay
>>around. imho one of the fundamental problems with computer science
>>as it is practiced today is a very poor/feeble/immature awareness of
>>the concept of a sandbox and its utterly crucial relevance to
>>software and hardware design.
>
>Please explain this sandbox of yours in detail. What exactly would
>a program be barred from doing? To keep a virus from infecting other
>programs, you'd have to bar all programs from being able to open
>any file, which would make it impossible to install new programs if
>all programs were constrained to the sandbox.
>
>To prevent filesystem corruption (which would ultimately cause OS
>corruption), you'd have to make it completely impossible to directly
>access a filesystem. This would create a problem for filesystem checkers.
>You wouldn't be able to access a filesystem anyway because you have to
>make it impossible to open a file! Of course, these are all blind
>assumptions-- I don't actually know anything about this sandbox concept
>of yours, which is why I am asking you to explain it in more detail.
Ah, but you have missed the other points; The Ultimate Operating
System won't actually *have* a filesystem.
It doesn't have files, because that is a Naughty Computer-Oriented
Abstraction that isn't Truely User Friendly.
Of course, this does beg the question of what sorts of abstractions
would be used to group together related information.
It *would* be a legitimately useful discussion to hear about the
mechanisms have been used to organize data in Persistent Object
systems like:
- Grasshopper
- EROS
- Lisp Machines
This would almost certainly be relevant to "not-working-yet" systems
like like NASOS or Tunes, which eschew the use of filesystems in favor
of the intention of using persistent data.
This is even of *some* interest with UNIX-like systems when you start
thinking about attaching persistent metadata alongside files so as to
represent things like ACLs. It's got to persist *somewhere...*
--
Now I know someone out there is going to claim, "Well then, UNIX is
intuitive, because you only need to learn 5000 commands, and then
everything else follows from that! Har har har!" (Andy Bates in
comp.os.linux.misc, on "intuitive interfaces", slightly defending
Macs.)
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/osnovel.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: libc or glibc?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 02:17:28 GMT
On Mon, 30 Aug 1999 12:43:11 +0800, Arthur Chiu
<[EMAIL PROTECTED]> wrote:
>People are talking about changing from libc to glibc. I'm using
>RH5.2. I can find descriptions of libc by 'info libc' but get
>nothing with 'info glibc'. What's the difference between libc and
>glibc?
libc 5 is a heavily-hacked-on version of GLIBC 1, which has only
reliably worked on IA-32, although there are apocryphal stories
suggesting that it might have at some point worked with Alpha.
libc 5 is no longer being maintained.
GLIBC 2 is the newer edition of GLIBC, written with specific attention
to architecture independence, which has the result that it works on
many other architectures (such as Alpha, PPC, MIPS, StrongARM, ...)
on which Linux runs.
GLIBC 2 also takes into consideration a variety of UNIX, ANSI, and ISO
standards that libc5 never did.
GLIBC 2 provides functions that are increasingly thread safe, which is
of importance to people using SMP-capable systems.
GLIBC 2 provides more portable system calls so that programs should
seldom need to resort to:
#include <linux/anything.h>
This helps with portability, allowing software to more easily port to
and from Linux.
See also <http://www.gnu.org/software/libc/libc.html>
--
Rules of the Evil Overlord #71. "Before employing any captured
artifacts or machinery, I will carefully read the owner's manual."
<http://www.eviloverlord.com/lists/overlord.html>
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/linuxresearch.html#GLIBC>
------------------------------
From: [EMAIL PROTECTED]
Subject: linux driver examples from rubini
Date: Tue, 31 Aug 1999 01:30:46 GMT
Has someone been able to make rubini's examples
work on 2.2.+
Is there an archive where I can get a copy of such?
Thanks
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Seth Mason <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.help,comp.os.linux.setup
Subject: SCSI device scan order.
Date: Mon, 30 Aug 1999 19:18:05 -0700
Kernel 2.2.12.
NCR based PCI SCSI adapter.
qlogic fibrechannel adapter (PCI).
My system is setup to boot off of /dev/hda which resides on the NCR
internal scsi adapter, and I use the qlogic adapter to for external high
speed storage. My problem is, the kernel appears to load the driver for
the qlogic adapter first and then the NCR scsi adapter. This is a
problem, b/c the kernel then tries to mount root off of the qlogic
adapter and not off of the NCR scsi adapter.
I'd like to force the kernel to load the NCR driver first, or
assigned a fixed /dev/hda device name to the internal HD (/dev/sda).
I've looked at devfs, but don't think that this is the appriate solution
for this problem.
Does the kernel load drivers based on priority on the PCI bus or
alphabetically in the "low-level scsi drivers" section of xconfig?
-Any help would be appreciated
-seth
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.emacs,gnu.emacs,gnu.misc.discuss
Subject: Re: LispOS?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 02:17:27 GMT
On 29 Aug 1999 16:10:11 -0700, Chris Mahmood <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Depeche) writes:
>> I, too, think that this is a sad affair. I wonder if there would be
>> support for a true LISP based openSource reimplementation.
>Well, how much longer will it be before we can just boot emacs?
Your mission, if you choose to accept it, is to provide patches to
emacs and/or gnuclient to permit it to run as one of the Hurd
servers...
[I actually got Hurd to boot last night, for the first time... The
documentation is only *partly* out of date, as far as installation
goes; the problem is that going on into configuration looks to be a
Barrel Of Laughs... Not...]
--
((lambda (foo) (bar foo)) (baz))
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/oshurd.html>
------------------------------
From: "Sean O'Dell" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.networking,comp.os.linux.security
Subject: Re: MySQL, chroot and shared libs
Date: Mon, 30 Aug 1999 20:16:20 -0700
Well, your suggestion actually lead me to the actual problem I think. I
tried using the domain name for the mysql server and got pretty much the
same results. However, when I tried the plain old IP address, it worked
just fine. So, it's got something to do with my DNS lookup activities
somewhere. Gonna track that down...thanks for the info!
-Sean
<[EMAIL PROTECTED]> wrote in message
news:7qek65$a29$[EMAIL PROTECTED]...
> In comp.os.linux.development.system Sean O'Dell <[EMAIL PROTECTED]> wrote:
>
> [ summary: mysql can't connect to local mysql server in
> a chroot'd environment ]
>
> Mysql makes a named pipe in /tmp for local connects. I'd bet
> your chroot'd environment doesn't have /tmp, or doesn't have
> the named pipe that mysql needs.
>
> Regards,
>
> Craig
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Crossposted-To: redhat.config,redhat.general
Subject: Re: how to 'scandisk' in linux
Date: 31 Aug 1999 01:00:32 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: zackary <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> hello guys
>
> I wonder how to check my disk 'health', as in windows'XX' it have
> 'scandisk' to check the bad block, file system and etc. So what should i
> use to check those things in linux. Would you guys guide me.
>
It's called "fsck" in Linux and is executed automatically on bootup
when appropriate.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
------------------------------
From: "Sean O'Dell" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.networking,comp.os.linux.security
Subject: Re: MySQL, chroot and shared libs
Date: Mon, 30 Aug 1999 20:05:40 -0700
Well, it actually does have /tmp, but not that named pipe. As well, I can't
see any pipes in /tmp either, or I might just try hard linking to them.
Nevertheless, it gave me the bright idea of maybe not connecting "locally"
and just using the IP...if mysql isn't smart enough to catch on and revert
back to the named pipe thingy, maybe that'll solve the problem.
-Sean
<[EMAIL PROTECTED]> wrote in message
news:7qek65$a29$[EMAIL PROTECTED]...
> In comp.os.linux.development.system Sean O'Dell <[EMAIL PROTECTED]> wrote:
>
> [ summary: mysql can't connect to local mysql server in
> a chroot'd environment ]
>
> Mysql makes a named pipe in /tmp for local connects. I'd bet
> your chroot'd environment doesn't have /tmp, or doesn't have
> the named pipe that mysql needs.
>
> Regards,
>
> Craig
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Avoid Zombies
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 03:48:45 GMT
On Tue, 31 Aug 1999 01:03:51 +0200, Sven Heursch
<[EMAIL PROTECTED]> wrote:
>Kaz Kylheku wrote:
>
>> On Mon, 30 Aug 1999 16:31:41 +0200, Sven Heursch
>> <[EMAIL PROTECTED]> wrote:
>> >Hello,
>> >
>> >I have now idea how do avoid Zombies which are created from threads over
>> >the pthread_exit() call.
>> >Any ideas?
>>
>> Threads that are not marked detached must be collected with pthread_join().
>
>yes, but I have a thread thats marked as detached! And after the
>pthread_exit() call of the thread I got a zombie task struct.
>Why?
>With processes I can destroy the zombies by calling wait(). Is there a
>possibility to do the same with threads?
Ah, wait. I'm wrong; The parent of the thread process created by pthread_create
is the thread manager. This process gets the child termination signal and
should actually collect the thread regardless of the detach state.
I think you may have a buggy library. What version of glibc2 do you have?
There have been a number of painful bugs in the LinuxThreads library that is
integrated into glibc2. I recall that there was one issue with the glibc that
went into RH 5.1 whereby threads were not being reclaimed properly, so programs
that created a lot of threads dynamically would quickly hit the limit. I don't
remember the details.
------------------------------
From: Keith Wright <[EMAIL PROTECTED]>
Subject: Re: Normal User X shutdown
Date: 30 Aug 1999 23:53:41 -0400
Thomas Gibson <[EMAIL PROTECTED]> writes:
> When running init level 4, what is the best way to allow a normal user
> to perform a system shutdown ?
If Normal is sitting at the console, set /etc/inittab so that Ctl-Alt-Del,
does a shutdown (many distributions set this to re-boot, but what good
is that? You can always wait for shutdown and then hit it again.)
If Normal is logged in remotely, I can't imagine why you would want
to allow this, but I suppose you could give em access to a set-uid
root script that does it.
--
-- Keith Wright <[EMAIL PROTECTED]>
Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
--- Food, Shelter, Source code. ---
------------------------------
From: [EMAIL PROTECTED] (Benoit Goudreault-Emond)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 03:17:36 GMT
In article <[EMAIL PROTECTED]>, NF Stevens wrote:
[snip]
> int main (void)
> {
> char *p = NULL;
> printf ("%p\n", GetAddress (*p));
^^
> return 0;
> }
The behavior of the marked tokens is undefined. You are dereferencing a
NULL pointer; that will compile, but the behavior is known to be undefined.
In other words: the problem occurs *where you call the function*, not within
the function 10 lines down the function header (where you don't recall what
the hell was going on).
This was hashed out on c.l.c++.m some time ago.
--
Benoit Goudreault-Emond
CoFounder, KMS Group ; Student, B. Comp. Eng, Concordia University
``Being too close to a fireball can worry a man --- to death.''
-- Zeb Carter in "The Number of the Beast" by Robert A. Heinlein
Note: the "From:" address is not correct to protect myself against spam.
My actual e-mail address is: ``bgoudem AT axess DOT com''
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.development.apps.comp.os.linux.setup
Subject: Re: what is the largest partition Linux file system can handle?
Date: 31 Aug 1999 03:41:00 GMT
> trying again. never got any answer on this yet.
perhaps because you've screwed up your address.
> Any one knows what is the largest partition Linux ext2 can handle?
I presume you really mean "largest filesystem" here. as I recall,
with 4K blocks, which is a good idea, it's around 150 TB.
> But every time I reboot, I get errors on that fs (missing inodes, or
well, how are you rebooting?
> this is using SUSE 6.1, kernel 2.2.5
that's hardly a modern kernel; there may also be updates to your fsck.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Normal User X shutdown
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 04:32:31 GMT
On 30 Aug 1999 23:53:41 -0400, Keith Wright <[EMAIL PROTECTED]> wrote:
>If Normal is logged in remotely, I can't imagine why you would want
>to allow this, but I suppose you could give em access to a set-uid
>root script that does it.
What happened to sudo? I haven't seen it in recent Redhat distro's.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: The optimization debate (was: why not C++?)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 02:18:04 GMT
On Sun, 29 Aug 1999 22:18:32 GMT, Stephen E. Halpin <[EMAIL PROTECTED]> wrote:
>On 28 Aug 1999 18:07:27 GMT, [EMAIL PROTECTED] (Christopher Browne) wrote:
>>On 27 Aug 1999 12:03:05 +0100, Paul Flinders
>><[EMAIL PROTECTED]> wrote:
>>>[EMAIL PROTECTED] (Paul D. Smith) writes:
>>>> On a micro level, I believe the best way is to write the code the most
>>>> straightforward way possible first, _then_ when it all works, come back
>>>> and see where you can tweak it to be faster. Remember, slower, working
>>>> code is always better than faster, broken code.
>>>
>>>That's true unless the very slowness _is_ the breakage.
>>>
>>>Also with more multimedia stuff fast but not completely accurate can be
>>>preferable to slow but complete (i.e would you prefer speech recognition
>>>which ran in real time but which occasionally got it wrong to speech
>>>recognition which took 5 minutes to recognise 10 seconds speech but always
>>>got it right).
>>
>>Slower, working code that reads in a straightforward manner, which
>>thereby makes it easy to make code transformations, is easier to
>>optimize than slightly faster code where bits have been tuned, and
>>thereby are virtually non-modifiable.
>
>I think you missed the point of the previous poster. He is not talking
>about "slightly faster code", he is talking about a 30:1 difference using
>heuristics to produce results which are probabalistically correct. You
>cant do it everywhere, but where you can do it, its a win. Another
>example of what the previous poster was getting at is lossy compression,
>where MPEG can produce far better compression ratios for audio and video
>than lossless compression schemes can, and its an acceptable tradeoff
>in many cases. On the other hand, you wouldnt store your company's
>financial data using a lossy compression algorithm.
The examples of "faster code" that have been quoted so far have
amounted to:
"reorder the loop so that it decrements rather than incrementing."
That's not a fundamental algorithmic change that would change the
order of complexity of the program.
My contention is that there is little merit to looking for those
little reorderings; better to write straightforward code, that will be
easier to mutate when analysis is done to find bottlenecks.
It absolutely is the 30:1 improvements, or 300:1 improvements, that
are the primary optimization goal.
By trying to get the 10% improvements early in the game, that is
liable to make it harder to go after the bigger gains that can come
later once the full scope of the system is known.
"Optimization hinders evolution." -- Alan Perlis
Once optimized once, it's harder to optimize the code again.
>More to the point you make, there are times when slightly faster is
>the difference between working and not working in a hard real-time
>system, and you have to live with it. Its all part of the tradeoffs
>that an engineer must make. If you havent seen the code for a box
>where 100% of code and data memory are used and it runs hard real-time
>at >98% utilization, its quite a sight :->
Some years ago, I worked on a financial system where they "optimized
too early." (A prototype that was a "6 month stopgap fix" stayed in
production for 6 years...)
The bank wanted us to mutate it into something new, when what was
truly necessary was to throw out the whole system and rearchitect
something new *from scratch.*
The notable problem with it was the date format; YYMMDD was mandated,
and when the system was managing pensions, there were ample
opportunities for *BAD* "Y2K" errors what with there being a few
people left with birthdates in the 1800's, and virtually everyone over
70 years of age.
There were a couple of "windowing" algorithms in use; once 1994 came
along, 6 year bond certificates started encountering calculation
problems, and when there is a billion dollars being managed, this is
just a bit of a problem...
The system had been tuned up several times by the time I got to it; it
was nigh unto impossible to modify. The system was retired in 1994;
replaced by something new(er).
There were lots of cases in this system of reports that ran for many
hours due to less-than-intelligent selections of database indices;
very often there were opportunities for *HUGE* performance
improvements when we changed a few loops to pick more appropriate
indices.
That was easy enough in cases where report structures had not been
tuned too much; it proved more difficult when previous programmers had
started optimizing too early.
--
"Optimization hinders evolution." -- Alan Perlis
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
** 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
******************************
