Linux-Development-Sys Digest #119, Volume #7 Sat, 28 Aug 99 20:14:10 EDT
Contents:
Re: Shutdown Problem (David Fox)
Re: The optimization debate (was: why not C++?) (Christopher Browne)
Signal on blocking socket (Bayee)
Re: Signal on blocking socket ([EMAIL PROTECTED])
Re: why not C++? (Spike!)
Re: Strange thread & kernel behavior (Peter Samuelson)
how to 'scandisk' in linux (zackary)
restricted acces for users... ("x256")
mounting at startup ("x256")
Re: TAO: the ultimate OS (Nix)
Re: Adding a non-standard Parallel Port (Nix)
Re: How can I make device driver module to support many version of kernel? (Nix)
Re: X Windows developement (Nix)
Re: Linux's faults (Nix)
Re: Jesus: the ultimate OS (Nix)
Re: why not C++? (Nix)
Re: why not C++? (Nix)
Re: why not C++? (Nix)
Re: glibc-2.1.1 problems (Nix)
Re: Linux - Memory model / protection scheme (Nix)
Re: update_vm_cache (Nix)
----------------------------------------------------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.x
Subject: Re: Shutdown Problem
Date: 28 Aug 1999 11:28:49 -0700
Gert van der Knokke <[EMAIL PROTECTED]> writes:
> David Fox wrote:
>
> > Alan Swartz <[EMAIL PROTECTED]> writes:
> >
> > > stan168 wrote:
> > >
> > > > I was thinking if the user just want to turn off the power without
> > > > doing a shutdown properly. Is there any way to prevent the checking (fsck)
> > > > at booting time and data corruption?
> > >
> > > I'm curious: Why would you want to do that?
> >
> > Perhaps to use Linux as the basis of an appliance like a stereo system.
>
> Just an idea, I made a Linux based mp3 CD player and I use the UPS
> software to properly shut down the system. My power button is
> overruled by a relay as soon it it switched on, therefore you can't
> manually switch it off after that. An extra contact on the
> powerbutton 'informs' the system the state of the power switch and
> Linux does a nice shutdown -h now after it detects the power switch
> being released. (I used a standard double pole switch, one pole for
> the mains, the other for the 'powerstate' input. And the end of the
> shutdown procedure the relay is dropped by a line on the serial
> port. Neat and simple. This way a user can't accidently turn the
> system off (unless he pulls the plug of course) On such a system you
> can mount almost all of the system as read-only, just /tmp or /var
> as read/write. To be on the safe side you can force a sync after
> writing 'delicate' data to these directories.
I would be inclined to try to construct the writable file systems from
scratch in a ramdisk each time you boot. That way you don't have to
worry about pulling the plug. For an appliance it should be ok to
boot into the same state every time. You would want to store a few
settings like volume, that could be done by mounting a small partition
read write. If that partition ever got hosed you could just re-create
it using the factory settings.
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
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++?)
Date: 28 Aug 1999 18:07:27 GMT
Reply-To: [EMAIL PROTECTED]
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.
--
"Some sins carry with them their own automatic punishment. Microsoft is
one such. Live by the Bill, suffer by the Bill, die by the Bill."
-- Tom Christiansen
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
Date: Sun, 29 Aug 1999 02:56:40 +0800
From: Bayee <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Signal on blocking socket
Hi,
As from the "man 2 read", a read operation should return EINTR if a
signal is sent to a process. I tried it with a blocking socket read, but
there is no return when a signal is sent. I am using 2.2.7 kernal,
anyone knows the reason ?
Bayee
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Signal on blocking socket
Date: Sat, 28 Aug 1999 21:34:16 +0200
Bayee wrote:
> Hi,
>
> As from the "man 2 read", a read operation should return EINTR if a
> signal is sent to a process. I tried it with a blocking socket read, but
> there is no return when a signal is sent. I am using 2.2.7 kernal,
> anyone knows the reason ?
>
> Bayee
Don't set the flag SA_RESTART for your signal handler (see `sigaction').
Note, that it is also legal for `read' to return successful on a signal
instead with the error EINTR.
In other words, you can't count signals with the io primitives.
If you would check whether a signal has arrived after `read' returns, don't
rely on EINTR.
Instead check a flag that is set by your signal handler.
------------------------------
From: Spike! <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Sat, 28 Aug 1999 15:21:30 +0100
Tristan Wibberley <[EMAIL PROTECTED]> wrote:
>> BTW, has anyone read Stroustrup's paper where he suggests overloading
>> the whitespace operator? It's quite an elegant idea, for example
>> mathematicians would be able to write:
>>
>> v = a x + b y + c z;
>>
>> instead of the usual:
>>
>> v = a * x + b * y + c * z;
> Aren't we getting close the realms of forth now?
Doesn't look like it... Remember, in forth, all the values are push onto the
stack and only popped off when evaluated, so the above would be more like
z c * b y * a x * + + .
The '.' popping Top Of Stack and printing it to screen.
(can't remember the syntax for stuffing the TOS into a variable... I haven't
dabbled in forth for years)
--
______________________________________________________________________________
| [EMAIL PROTECTED] | "Are you pondering what I'm pondering Pinky?" |
| Andrew Halliwell BSc | |
| in | "I think so brain, but this time, you control |
| Computer Science | the Encounter suit, and I'll do the voice..." |
==============================================================================
|GCv3.12 GCS>$ d-(dpu) s+/- a C++ US++ P L/L+ E-- W+ N++ o+ K PS+ w-- M+/++ |
|PS+++ PE- Y t+ 5++ X+/X++ R+ tv+ b+ DI+ D+ G e++ h/h+ !r!| Space for hire |
==============================================================================
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Strange thread & kernel behavior
Date: 28 Aug 1999 14:38:43 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Esa J Kallioniemi <[EMAIL PROTECTED]>]
> Ok, I have dual 350 Mhz P2 machine with 128 MB memory. Linux is
> RedHat 5.2 with 2.0.36 kernel + addtional 2.2.9 selfcompiled
> kernel. I have written small proggy, that spawns 32 threads
> (LinuxThreads). When running "time proggy" I get about 0.04 secs with
> 2.0.36 kernel. BUT when running with 2.2.9 (with SMP on) I get
> extremely random behavior ! Time says anything between 0.04 and 5.0
> secs for the exactly same proggy...
Your 2.0.36 kernel is SMP, right? If not, your results may be strange
and undesirable but it's hard to compare the two kernels....
Anyway, it does look like a kernel bug. There have been some SMP
changes in the last three kernel revisions, so try 2.2.12. If 2.2.12
has the same problem, get back to us and post proggy.c (if it isn't too
large).
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: zackary <[EMAIL PROTECTED]>
Crossposted-To: redhat.config,redhat.general
Subject: how to 'scandisk' in linux
Date: Sat, 28 Aug 1999 20:30:59 GMT
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.
Thank You.
-azaria-
================== Posted via CNET Linux Help ==================
http://www.searchlinux.com
------------------------------
From: "x256" <[EMAIL PROTECTED]>
Subject: restricted acces for users...
Date: Fri, 27 Aug 1999 22:54:08 +0200
1) how can i deny users acces to / ? so they can only see what is in their
home dirs and not what is in /, /etc, /usr, /bin, etc
2) can anyone give me some more tips to increase security on my system ?
thx
x256
------------------------------
From: "x256" <[EMAIL PROTECTED]>
Subject: mounting at startup
Date: Fri, 27 Aug 1999 23:16:11 +0200
how can i (auto) execute commands at startup ? like 'mount /dev/hda1 /c' ?
thx
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 28 Aug 1999 00:04:00 +0100
[EMAIL PROTECTED] (Donal K. Fellows) writes:
> We see a bunch of known hard/intractable problems.
At least one (the `no viruses' constraint) requires either `no new code
may be written for this system' or a realtime analysis system that must,
to do its job *perfectly*, solve the halting problem.
Or so ISTM.
> We see bugger all in the way of implementation skeleton to help
> convince us to put in the amount of effort required to implement what
> you are calling for.
i.e. `a lot'.
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Adding a non-standard Parallel Port
Date: 27 Aug 1999 23:22:41 +0100
[EMAIL PROTECTED] (Peter Samuelson) writes:
> [Norm Dresner]
> > > Alas, I'm using the 2.0.36 kernel. Can I still do this?
> [Robert McGwier <[EMAIL PROTECTED]>]
> > Time to upgrade.
>
> Mmmm, not until Linux 2.2.12 comes out (RSN) and has been tested a
> little. Everything since 2.2.7 has been iffy, though I gather 2.2.11
> is OK with the three or four patches in the online release notes.
It's been panicking on me.
I've turned off auto-reboot-on-panic and I'll have a look at it next
time it dies and report it to l-k...
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: How can I make device driver module to support many version of kernel?
Date: 27 Aug 1999 23:30:57 +0100
Marcus Sundberg <[EMAIL PROTECTED]> writes:
> People/companies wanting to provide binary only modules can write
> their own (Open Source) compability layer and distribute it with
> their binary drivers. Seems to work just fine for Vmware.
And for coda, although in their case it's not binary-only that's the
problem but a fscking massive client. 10Mb for a module's data space
would *not* be good ;)
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: X Windows developement
Date: 27 Aug 1999 21:04:13 +0100
[EMAIL PROTECTED] (Sami Tikka) writes:
> Perhaps the XFree86 source also contains these
> documentations?
Yes, it does.
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Linux's faults
Date: 27 Aug 1999 23:14:08 +0100
Robert Krawitz <[EMAIL PROTECTED]> writes:
> It's possible for processes to share memory by means of the
> System V shared memory primitives (shmctl and such), or by mmap()'ing
> a file shared (the traditional method).
Linux does not support anonymous shared mappings yet :(((
> Linux also has a system call named clone() that allows two processes
> to share a number of resources. Don't use this, though, if you want
> your program to be portable.
pthreads, of course, are implemented in terms of clone().
(Indeed, so is fork(), although that emulation takes place within the
kernel.)
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: 27 Aug 1999 23:51:53 +0100
"Christopher R. Thompson" <[EMAIL PROTECTED]> writes:
> Further if you think Java is a language for computers I think you are
> mistaken again.
I fail to see what else it is. It certainly is a language, and it
certainly runs on computers...
> As ironic as it may seem Java was a solution to the varied CPU
> archithectures that allowed code to be portably translated across
> platforms. We already have that with GNU-C at the machine level and it
> fully supports objective C, and c++. Java will always require a
> translator and therfore an inefeciancy.
Wrong:
loki:/usr/packages/egcs/egcs/snapshot% ls -l egcs/gcc/java/
total 2921
drwxr-sr-x 2 compiler hackers 1024 Aug 25 19:22 CVS
-rw-r--r-- 1 compiler hackers 287510 Aug 25 19:22 ChangeLog
-rw-r--r-- 1 compiler hackers 7631 Aug 21 14:56 Make-lang.in
-rw-r--r-- 1 compiler hackers 12000 Aug 21 14:56 Makefile.in
-rw-r--r-- 1 compiler hackers 1513 Dec 19 1998 buffer.c
-rw-r--r-- 1 compiler hackers 1445 Dec 19 1998 buffer.h
-rw-r--r-- 1 compiler hackers 21163 Aug 21 14:56 check-init.c
-rw-r--r-- 1 compiler hackers 53377 Aug 21 14:56 class.c
-rw-r--r-- 1 compiler hackers 1619 Dec 19 1998 config-lang.in
-rw-r--r-- 1 compiler hackers 12961 Mar 24 19:05 constants.c
-rw-r--r-- 1 compiler hackers 1129 Dec 19 1998 convert.h
-rw-r--r-- 1 compiler hackers 55475 Aug 21 14:56 decl.c
-rw-r--r-- 1 compiler hackers 10802 Aug 21 14:56 except.c
-rw-r--r-- 1 compiler hackers 80467 Aug 21 14:56 expr.c
-rw-r--r-- 1 compiler hackers 45969 Aug 21 14:56 gjavah.c
-rw-r--r-- 1 compiler hackers 2468 Aug 21 14:56 java-except.h
-rw-r--r-- 1 compiler hackers 126 Dec 19 1998 java-opcodes.h
-rw-r--r-- 1 compiler hackers 2799 Feb 21 1999 java-tree.def
-rw-r--r-- 1 compiler hackers 38405 Aug 21 14:56 java-tree.h
-rw-r--r-- 1 compiler hackers 14314 Dec 19 1998 javaop.def
-rw-r--r-- 1 compiler hackers 3810 Aug 21 14:56 javaop.h
-rw-r--r-- 1 compiler hackers 6005 Aug 21 14:56 jcf-depend.c
-rw-r--r-- 1 compiler hackers 33635 Aug 21 14:56 jcf-dump.c
-rw-r--r-- 1 compiler hackers 14880 Aug 21 14:56 jcf-io.c
-rw-r--r-- 1 compiler hackers 30165 Aug 21 14:56 jcf-parse.c
-rw-r--r-- 1 compiler hackers 7792 Aug 21 14:56 jcf-path.c
-rw-r--r-- 1 compiler hackers 10010 Aug 21 14:56 jcf-reader.c
-rw-r--r-- 1 compiler hackers 89379 Aug 21 14:56 jcf-write.c
-rw-r--r-- 1 compiler hackers 9866 Aug 21 14:56 jcf.h
-rw-r--r-- 1 compiler hackers 4813 Aug 21 14:56 jv-scan.c
-rw-r--r-- 1 compiler hackers 3749 Aug 21 14:56 jvgenmain.c
-rw-r--r-- 1 compiler hackers 12616 Aug 21 14:56 jvspec.c
-rw-r--r-- 1 compiler hackers 2102 Apr 2 18:29 keyword.gperf
-rw-r--r-- 1 compiler hackers 5513 Apr 2 18:29 keyword.h
-rw-r--r-- 1 compiler hackers 2155 Aug 21 14:56 lang-options.h
-rw-r--r-- 1 compiler hackers 1767 Feb 4 1999 lang-specs.h
-rw-r--r-- 1 compiler hackers 15056 Aug 21 14:56 lang.c
-rw-r--r-- 1 compiler hackers 35927 Aug 21 14:56 lex.c
-rw-r--r-- 1 compiler hackers 18273 May 14 00:53 lex.h
-rw-r--r-- 1 compiler hackers 4530 Aug 21 14:56 mangle.c
-rw-r--r-- 1 compiler hackers 111364 Aug 25 20:25 parse-scan.c
-rw-r--r-- 1 compiler hackers 376945 Apr 30 00:31 parse-scan.output
-rw-r--r-- 1 compiler hackers 26662 Aug 21 14:56 parse-scan.y
-rw-r--r-- 1 compiler hackers 507778 Aug 25 20:22 parse.c
-rw-r--r-- 1 compiler hackers 25160 Aug 21 14:57 parse.h
-rw-r--r-- 1 compiler hackers 464599 Apr 30 00:27 parse.output
-rw-r--r-- 1 compiler hackers 366623 Aug 25 19:22 parse.y
-rw-r--r-- 1 compiler hackers 23491 Aug 21 14:57 typeck.c
-rw-r--r-- 1 compiler hackers 42969 Aug 21 14:57 verify.c
-rw-r--r-- 1 compiler hackers 2371 Aug 21 14:57 xref.c
-rw-r--r-- 1 compiler hackers 1785 Aug 21 14:57 xref.h
-rw-r--r-- 1 compiler hackers 12547 Aug 21 14:57 zextract.c
-rw-r--r-- 1 compiler hackers 2000 Mar 24 19:06 zipfile.h
gcj, the GNU Java frontend. To assembler like any other gcc frontend, of
course.
Do not conflate the Java Virtual Machine and the language into one; they
were designed in the light of each other, that is all. Otherwise they
are conceptually separate.
Languages which are far harder to compile than Java have been; eg there
are *very* efficient Lisp and Scheme compilers out there, despite the
equivalence of code and data in Lisp, and the existence of `eval'.
(You have to embed an intepreter into the runtime code to handle `eval'
in the general case. But it only gets used for `eval'led stuff, and
maybe not for all of that.)
> The idea that code be
> transportable and then install a unique processor to make it run well
> seems just a little bit strange to me.
Why? The UCSD P-system did it back in the early 80s. All the Infocom
games did it (with the `Z-machine') and it is because of that that I am
able to copy Zork off my C64 floppies, throw it onto my Linux box and
run it (via an interpreter of course).
Do *that* with a 20 year old non-interpreted program. Unless it's
written in damned portable C (which means there is not much it can do as
so much changes over time, even in the Unix world) you are probably
stuffed. And if it's a binary you are guaranteed stuffed unless you can
get a system that emulates the entire system the binary ran on in, you
guessed it, a virtual machine.
Don't rubbish VMs. They're superb abstraction tools; but they're not
useful for *every* job.
> Networks and network computers have been around since the begining of
> networks.
Although if Inferno ever gets mainstream I think we'll see what a
network computer should *really* be :)
> If it worked well when computers and networks were slow
> and memory constrained... why add a bunch interpreters, translators, and
> superfulous layers of code?... just to slow things down?
No, abstraction layers are *good* (where possible). Just-in-time
compilation is probably the best of both worlds in that you get the
speed of native binaries and the portability of interpreted
systems. Unfortunately then you need a JIT compiler.
The Symbolics Lisp machines did this IIRC, and so have several systems
since then.
> The only reason TAO is difficult for ME to realize is because there is
> no code that I have seen, or that you have pointed me to. You say in
IMHO it is vapour. Unless something is written it will remain vapour.
(Tautologies are fun. ;) )
> your article "it is very cleverly constructed such that only the amount
> of information relative to the sophistication of the user is revealed".
I have a design for an OS like this but it's all on paper 500 miles away
:( it went it for ludicrous security, viz `make a machine we can't work
out a way to break into'. Even physically. And *everything* was
interpreted, although if you wanted speed you could run the code through
a formal proving system that, if it could prove the code was secure,
would assemble it and run that instead, transparently. (Otherwise,
tough, interpreted only).
(We didn't quite manage the total security bit. SQUIDs and quantum
tricks could have spied on ongoing dataflow and theoretically broken it,
but the rest we blocked ;} unfortunately the system requirements of the
OS are such that it probably can't be written for ten years and can't be
practically run for twenty...)
Only a design really, fun vapourware hacking for a week or two. (What
else to do on holidays? ;) )
> The only thing REALLY wrong with TAO so far that I can see is simply the
> NAME.
Yes, it's been used before. There is already an OS called Tao (or rather
`Taos').
> Try to find something a little more realistic. Maybe if this
> parallel thing gets off of the ground Linus Torvalds will let me rename
> "Linux" to "Jesus".
'Twas originally called `Freakx' when it first hit the net. (Although
the initial development name *was* apparently `Linux' but Linus didn't want
people thinking he was some sort of egotistical maniac). Thank whatever
gods there be that it was renamed back, I can just see the MS FUD:
`Would you want your business to be run by a bunch of Freakz?'
Argh.
> Really I'm not trying to rain on your parade.
While I'm just an evil bastard. If there's a parade, I'll seed the
clouds for rain just above.
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 27 Aug 1999 19:21:34 +0100
Johan Kullstam <[EMAIL PROTECTED]> writes:
> this doesn't mean it cannot be a big win. things
> that work like numbers are usually good targets for heavy
> overloading.
So too are things that work like arrays, functions[1] and pointers, but
have different underlying implementations or something similar.
Imagine using a vector `class' in C. *shudder*
(It isn't pretty at all.)
[1] I'm talking about functional classes here of course
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 27 Aug 1999 19:23:50 +0100
Tristan Wibberley <[EMAIL PROTECTED]> writes:
> time :/ One
That's an interesting operator, that is.
What does it do?
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 27 Aug 1999 19:27:42 +0100
Tristan Wibberley <[EMAIL PROTECTED]> writes:
> I've opened a can of worms with that extensible operator syntax - it was
> only meant to be a joke :( I'm sorry.
You *have* seen Stroustrup's classic paper on extending C++ to overload
whitespace, I take it?
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: glibc-2.1.1 problems
Date: 27 Aug 1999 21:34:59 +0100
Allin Cottrell <[EMAIL PROTECTED]> writes:
> To amplify: this suggests to me that your C compiler was messed up when
> you compiled the programs that want __setfpucw. I'm on thin ice here,
> but I think your system is awry when binaries make direct reference to
> symbols whose names start with a double underscore.
Like, er, __main?
;)
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Linux - Memory model / protection scheme
Date: 27 Aug 1999 21:49:55 +0100
[EMAIL PROTECTED] (Peter Samuelson) writes:
> You can catch SIGBUS/SIGSEGV if you want.
And sometimes it's not just nice, but *necessary*, eg interpreters.
eg if emacs segfaults, it's useful to know the state of the Lisp
interpreter at that point.
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: update_vm_cache
Date: 27 Aug 1999 23:08:03 +0100
[EMAIL PROTECTED] (Peter Samuelson) writes:
[unified page cache]
> This is easily *the* most involved change to Linux in the 2.3 cycle.
> (Other big things have been filling out USB support, deserializing some
> networking codepaths, several cleanups -- waitqueues, partitions,
> `struct device' -- the big ISDN merge, a few new drivers and features
> like khttpd. None of those fundamentally changed the Linux core very
> much).
You forgot about the new resource allocation code. *That*'s a core
change, oh yes --- or at least it changes just about every driver and
init/main.c, so it must be major :)
(But thank goodness init/main.c *is* cleaned up, the worst wart in the
Linux kernel source and in exactly the wrong place, just where a new
protohacker is most likely to look first. IMHO, of course.)
> You see? If you were truly interested in following development,
> running 2.3.x to try to fix bugs etc, you could not *possibly* have
> missed the revamp of the pagecache.
I agree. It's a *big* change.
> > I've yet to see a location mentioned for the new change-log, or
> > collection of change-logs (freshmeat.net gives better info as to
> > where the latest changelog is).
>
> There is no official changelog.
This is IMHO one of the biggest annoyances in the Linux kernel's
development model, and one which bitkeeper will hopefully squash. gcc
and every other open source development model I can think of keeps
accurate changelogs, so why on earth does the Linux kernel not do so?
(Saying `but the kernel's development is too distributed' is
horsefeathers. So is gcc's, albeit on a smaller scale, and that has very
good changelogs.)
> > Don't worry, I won't be posting to the linux-kernel mailing list
> > since I know 'outsiders' aren't welcome.
>
> OK, now I'm going to have to take a mildly flaming tone. It really
> bugs me when people go and do things like this and then try and play
> martyr. Your sulk about elitism does not impress me; I hold that
> linux-kernel is NOT elitist or unwelcoming of "outsiders". You only
It is wholly welcoming of them, you do not have to be some kind of
insider to contribute.
Indeed I remember one time when someone purporting to be a `complete
newbie' to the kernel turned up --- with a near-flawless thousand line
patch ;} This was obviously some new definition of `newbie'...
(Not that you have to submit perfect thousand-line patches on your first
try, oh no. The bazaar can fix almost anything, although even it has
trouble with Mozilla.)
> (And if you don't
> consider extra email to be "wasting bandwidth", ask someone elsewhere
> in the world who has to pay per-K for their Internet connection.)
*shudder* tell me this isn't true.
(I suppose I have to pay per-unit-time, but that's not quite the same.)
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
** 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
******************************
