Linux-Development-Sys Digest #571, Volume #6 Fri, 2 Apr 99 20:14:24 EST
Contents:
Re: Proposal: "Linux 2000 Platform" ([EMAIL PROTECTED])
Problems with 2.2.5 & sound & apm (Roope Anttinen)
Re: How about /dev/web? (Joseph H Allen)
Re: How about /dev/web? (Joseph H Allen)
Re: COM/CORBA equivalent ("Dirk-Jan C. Binnema")
Put another way: Linux from the Ground Up ([EMAIL PROTECTED])
Re: Neal Stephenson does the car metaphor ("Michael J. Peck")
Re: Undefined referenced to '__bzero' (Andreas Jaeger)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (Thomas Jespersen)
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Jim Richardson)
Re: Linux Kernel documentationI (John McKown)
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (David M. Cook)
Re: How about /dev/web? (Alexander Viro)
Re: How about /dev/web? (Rajappa Iyer)
Re: polling an interface at 12 KHz (Mark Hahn)
Re: How about /dev/web? (Christopher B. Browne)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Date: Fri, 02 Apr 1999 19:03:29 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Kendall Bennett) wrote:
> Hi All,
> Since there will be differences between the different uses for Linux, we
> should define multiple variations of the Linux 2000 platform. The
> contents of what make up the variations Linux 2000 platform should be
> debated and eventually voted on to come up with the final guidelines.
> Some people may not agree with the final vote, but the important thing is
> that compromises need to be made for this to be successful. We may also
> want to define what are 'base components' that must be installed on every
> system, and components that are optional and may or may not be installed
> by the user.
this was an april fools joke, right?
the scary thing is that this is actually occuring,
the end result of windows programmers that do not understand unix.
it cracks me up when people make their linux look and behave as much like
windows as possible, then denounce the very thing they are emulating.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Roope Anttinen <[EMAIL PROTECTED]>
Subject: Problems with 2.2.5 & sound & apm
Date: 2 Apr 1999 21:55:24 GMT
Reply-To: [EMAIL PROTECTED]
Hi,
I got 2.2.5 installed in SuSe-6.0 and it works.. allmost as well as 2.0.36
on the same machine with practically the same settings.
The sound seems broken at least with this GUS PnP. It feels like the sound
buffer isn't emptied while the bits are feed to the card. I got same few
seconds of sound repeating over and over again and the music app stops
because it can't find any free room in the buffer. This happens with both
x11amp and kmikmod.
Then with apm and "power off on shutdown" enabled the thing doesn't go off
after shutdown. Works again perfectly with 2.0.36.
What this does mean?
Apr 2 17:56:36 miro kernel: mopd uses obsolete (PF_INET,SOCK_PACKET)
apparently because of that my VXT doesn't boot from Linux running 2.2.5.
Again it works with 2.0.36.
Roope
--
MicroSoft? is that some kind of a toilet paper?
PS: Look for address here, not from headers. And remove NOSPAM's
___________________________________________________________________________
[EMAIL PROTECTED] / [EMAIL PROTECTED]
+358 9 812 7567 / +358 500 445 565 / +358 49 445 565
http://myy.helia.fi/~anttiner/index.html
===========================================================================
Helsinki Business Polytechnic - Institute of information technology
------------------------------
Crossposted-To: gnu.misc.discuss
From: [EMAIL PROTECTED] (Joseph H Allen)
Subject: Re: How about /dev/web?
Date: Fri, 2 Apr 1999 21:11:40 GMT
In article <[EMAIL PROTECTED]>,
Rajappa Iyer <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Joseph H Allen) writes:
>
>> Plan9 namespaces are nice, but they don't go anywhere near far enough:
>>
>> It would be nice if there were a way to mount a device driver (loadable
>> module) as the server for a pseudo-directory.
>
>Check out Inferno.
>www.lucent-inferno.com
I will. The main problem with both this and plan9 is that they are not
free. Actually never mind inferno, even my old Atari-800 could do this.
--
/* [EMAIL PROTECTED] (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
------------------------------
Crossposted-To: gnu.misc.discuss
From: [EMAIL PROTECTED] (Joseph H Allen)
Subject: Re: How about /dev/web?
Date: Fri, 2 Apr 1999 21:09:30 GMT
In article <7e38iq$[EMAIL PROTECTED]>,
Alexander Viro <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Joseph H Allen <[EMAIL PROTECTED]> wrote:
>>I wish the entire socket system worked this way as well (IMHO, those stoned
>>out hippies at berserkely really screwed up be not putting the socket system
>>in the filesystem to begin with). It could work something like this:
> What do you have against hippies?
Nothing.. they should have just done the sockets better, instead they did it
in the easiest possible way (those lazy stoned out bums! :-)
>>fd=open("/inet/tcp/123.456.789.10/50",0)Listen for connections on port 50
>>read(fd,buf,100) Accept token for next connection
>>fd1=open(buf,2) Accept the connection (buf would
>> contain /inet/tcp/123.456.789.10/something)
> Races. Besides, it's good for AF_INET, but for AF_UNIX it will be
>royal PITA. Ditto for anything other than SOCK_STREAM.
How does it race? Read blocks until there is a connection. The token hangs
around until fd closes or the acknowledging open(). AF_UNIX is even easier-
they look like named pipes. It all works fine with select().
Speaking of select(), another pet peeve of mine is that child death events
do not appear properly in select(), and instead create a mess. One more
thing which needs to be fixed.
>>You could then make servers with simple shell scripts. There could be a dns
>>translator mounted on another directory. There could be authentication
>>translators mounted on yet other directories, http and ftp translators could
>>be added on top of that. Of course not every device driver is necessarily
>>going to provide all of the functionality available in a real filesystem-
>>it very useful even without it.
> Sigh... Servers in simple perl scripts are available right now.
>As for ftp translator - WTF will you do without lseek() and mmap()?
Yes but perl has to have a ton of socket code in it. If sockets were in the
fs, _lots_ of programs become smaller, simpler and more general purpose.
Even the C library would be smaller.
As for mmap and lseek (and locking), most programs don't use them (use nfs
if these are necessary). Nobody's going to run their database server over
an ftp file system, so don't worry. Mmap and lseek could be done (with
caching and lots of other work- at the very least rewind() could be done),
but they are not necessary for providing the same functionality provided by
ftp. Think emacs- there would be no need for the 'ftp:' thing to be
implemented in emacs with user space ftp. Anything that makes emacs smaller
(and cat more powerful) is a good thing (plus you get the same functionality
in vi for free).
Authentication is the real trick- sometimes you want it in mount (or even,
preferably, cd) (for browsing), but sometimes you want it in open (for
getting a single file in emacs). A wider view might be to have 'sudo'-like
behavior more built in- open or mount challenge you somehow, but you retain
permission for the next 5 minutes or something. I have no idea how this
would work since there are so many possible ways- perhaps you can give a
password as part of the name in mount or open occasionally. Mount or open
could return an error when the time has expired, so the user has to try
again but specify the password. Perhaps you want something else so that
applications can prompt for invisible passwords. There will be no real
solution until somebody attempts to implement it.
--
/* [EMAIL PROTECTED] (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
------------------------------
From: "Dirk-Jan C. Binnema" <[EMAIL PROTECTED]>
Subject: Re: COM/CORBA equivalent
Date: Thu, 1 Apr 1999 23:57:46 +0200
Sunil R. Karkera wrote in message
<7dupi8$4q20$[EMAIL PROTECTED]>...
>Hi!
>I'm new to Linux. I'm a Windows API developer in VC++. I recently installed
>Red Hat Linux 5.2. I would like to start developing a freeware Help-desk
>system, for use by any organization, from commercial to voluntary.
>I would like to know if Linux has something like COM/CORBA infrastructure
>euivalent. I want to wake the program componentized.
>Please suggest me some good freeware C++ development tools, GUI tools for
>Linux, that supports COM/DCOM like framework.
check out the GNOME project (www.gnome.org), which (among other things) is
defining 'Bonobo', a set of OLE2-like interfaces to have in-place
activation, automation etc., on top of CORBA (so no need for IDispatch!).
CORBA compares better to DCOM than to COM, but Bonobo may change this.
The KDE project (www.kde.org) have the KOffice "KOM/Openparts" object model,
also based on CORBA.
I don't know of any Visual tools that target CORBA (well, I think C++
Builder supports it, but that doesn't work on Linux...), but have found
building CORBA components is not at all harder than writing COM components.
Cheers,
Dirk-Jan.
------------------------------
From: [EMAIL PROTECTED]
Subject: Put another way: Linux from the Ground Up
Date: Fri, 02 Apr 1999 06:10:53 GMT
Hi everyone,
Perhaps I didn't describe my question the right way. I have Linux running and
have been using it just fine (RH 5.2)
I am simply curious to build a Linux system WITHOUT using a distribution. I
am perfectly fine with whatever it takes (time/compiling/etc). Can anyone
show me the way? I have a spare system to play around with.
Thanks,
AP
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Michael J. Peck" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.next.advocacy
Subject: Re: Neal Stephenson does the car metaphor
Date: Thu, 01 Apr 1999 23:08:08 -0600
Christopher Browne wrote:
[cut]
> The argument is pretty good; in order for something to be other than
> "toy" functionality, it needs to be deployable in wider contexts than
> "on an experimental kernel with experimental patches with a denial of
> network access."
>
> A "K001 application" that only works on a local filesystem on a Linux
> box where the kernel has been patched to include the new FS code is
> decidedly *not* going to get widely adopted.
>
> Arguments that UNIX "ought" to offer additional functionality relating
> to filesystems pretty forcibly requires that there be some way of doing
> this across networks, which means that changing APIs to the point to
> which NFS isn't enough until something demonstrably better is
> *deployable* (e.g. - CODA or AFS-like schemes) is just not going to
> happen.
The answer to this respects the notion of layers, to which I alluded
just now in another posting. Anything which expects to export itself
over NFS should respect the peer-to-peer lowest-common-denominator
expressed in that protocol (and in others). If "coolness" must be
expressed as a function of the FS, it needs to be an additional layer
*above* the FS, complemented by a layer which operates above NFS.
The obvious costs of all this layering are important inputs to the
cost/benefit analysis necessary to judge such a "cool" project. It's
possible to sidestep the costs of such layering, but only by incurring
brand-new and largely chaotic (and unpredictable) costs associated with
the newly-acquired compatibility problems.
For instance, SSH is not a secure modification of TCP/IP, but rather a
secure layer which operates above TCP/IP. It requires secure
client/server operation on both peers, and incurs a performance penalty.
Both considerations are costs that have been judged acceptable by the
community that uses these tools.
> Note that the above statement is also FALSE. KDE and GNOME software can
> all run quite happily at the same time atop X.
>
> They may not be able to do Drag-n'Drool yet, but certainly have *intent*
> for that aspect of interoperability.
....but they do so only by adding increasing layers to serve as a
functional barrier to entry. That sounds like deprecation, but it is
praise; the functional barrier clarifies the need for additional layers
and respects compatibility between layers which exist at equal levels.
The fact, which you pointed out, that both KDE and GNOME software can
coexist on the same X platform is proof-positive that such layering
works well.
> It's an interesting speculation of dubious likelihood of *realistically*
> continuing in the long term.
I agree, for the most part. Still, I cannot prove it and I want to
emphasize that even if fragmentation were likely, it does not guarantee
a loss of interoperability (or even of overall value, for that matter).
[cut]
> You need the CLI to do things that are best described symbolically; the
> GUI is best for things that are best described visually.
I like that summary; it's probably as concise a summary as I've seen.
Ironically, GUIs are more often used in symbolic fashion than are CLIs,
and praised for same.
> There has been a whole lot of research into "visual programming;" most
> programs are still written in textual languages like C, COBOL, Pascal,
> or Lisp. (Or the various more recent variations thereof.)
Language, itself, is inherently symbolic. That is what makes
pictographic languages (which merely increase the complexity of the
symbols without providing significant new depth) so disappointing.
> Security is starting to become more of an issue as it becomes easier and
> easier to establish connections between computers.
[cut]
MJP
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: Undefined referenced to '__bzero'
Date: 02 Apr 1999 08:12:47 +0200
>>>>> John Florian writes:
> Hello,
> I got in a little over my head with my upgrades when I started messing
> with glibc. My box began life with RH 5.1, but I have upgraded to
> 2.2.1, then 2.2.2, and finally 2.2.3. All was working very well, but
> according to the kernel Changes file I still had some stuff that was a
> little old. All of the upgrades also went well... right up until I
> tried upgrading to glibc 2.1.
> I've read that it's easy to screw a system up with the libraries so I
> attempted to be careful. I had compiled and installed glibc 2.1 into
> /usr/local/lib with no apparent problems. I then did a ldconfig and
> still no problems. It worked so well that I doubted anything was
> finding the new glibc. I figured that everything must still be
> finding the RH 5.1 original under /lib. So I edited /etc/ld.so.conf
> to put /usr/local/lib first and then did another ldconfig. Everything
> went to hell right then. Any DLL'd executable (most everythihng)
> failed to run. I was forced to do a cold reset and it looked even
> worse then.
> A friend suggested booting from the RH 5.1 CD and using the bash
> provided on a hidden VT during the install to copy
> cdrom/live/etc/ld.so.cache to my /etc. That seemed to fix things as
> long as I kept /usr/local/lib out of my /etc/ld.so.conf altogether.
> If I added it back to end of the file where it was originally (and
> things were working) I wound up dead again.
> I've since moved all files related to glibc-2.1 out of /usr/local/lib
> (I identified them by date stamp). Then I was able to have
> /usr/local/lib in my ld.so.conf once again. I thought I'd been to
> hell and back and considered myself grateful, but...
> Now I cannot compile anything, including old kernels and such that
> used to compile just fine. Every make ends with a complaint like:
> /tmp/cca004861.o: In function `main':
> /tmp/cca004861.o(.text+0x3f5): undefined reference to `__bzero'
> make[1]: *** [tools/build] Error 1
> make[1]: Leaving directory `/usr/src/linux/arch/i386/boot'
> make: *** [bzImage] Error 2
> I have no idea what to try now to fix the undefined reference to
> '__bzero'.
Your compiler picks up the include files from /usr/local/include first
where you still have the glibc 2.1 files - and you compile those with
glibc 2.0 libraries. Remove those include files.
Andreas
P.S. FYI here's an FAQ entry that will be in glibc 2.1.1:
3.18. After upgrading to glibc 2.1, I receive errors about
unresolved symbols, like `_dl_initial_searchlist' and can not
execute any binaries. What went wrong?
{AJ} This normally happens if your libc and ld (dynamic linker) are from
different releases of glibc. For example, the dynamic linker
/lib/ld-linux.so.2 comes from glibc 2.0.x, but the version of libc.so.6 is
from glibc 2.1.
The path /lib/ld-linux.so.2 is hardcoded in every glibc2 binary but
libc.so.6 is searched via /etc/ld.so.cache and in some special directories
like /lib and /usr/lib. If you run configure with another prefix than /usr
and put this prefix before /lib in /etc/ld.so.conf, your system will break.
So what can you do? Either of the following should work:
* Run `configure' with the same prefix argument you've used for glibc 2.0.x
so that the same paths are used.
* Replace /lib/ld-linux.so.2 with a link to the dynamic linker from glibc
2.1.
You can even call the dynamic linker by hand if everything fails. You've
got to set LD_LIBRARY_PATH so that the corresponding libc is found and also
need to provide an absolute path to your binary:
LD_LIBRARY_PATH=<path-where-libc.so.6-lives> \
<path-where-corresponding-dynamic-linker-lives>/ld-linux.so.2 \
<path-to-binary>/binary
For example `LD_LIBRARY_PATH=/libold /libold/ld-linux.so.2 /bin/mv ...'
might be useful in fixing a broken system (if /libold contains dynamic
linker and corresponding libc).
With that command line no path is used. To further debug problems with the
dynamic linker, use the LD_DEBUG environment variable, e.g.
`LD_DEBUG=help echo' for the help text.
If you just want to test this release, don't put the lib directory in
/etc/ld.so.conf. You can call programs directly with full paths (as above).
When compiling new programs against glibc 2.1, you've got to specify the
correct paths to the compiler (option -I with gcc) and linker (options
--dynamic-linker, -L and --rpath).
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: Thomas Jespersen <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.misc,linux.redhat.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
Date: 02 Apr 1999 22:19:54 +0200
[EMAIL PROTECTED] (Hal Duston) writes:
> Enkidu ([EMAIL PROTECTED]) wrote:
> : wizard wrote:
> : >
> : > The other key item that everyone overlooks is the large amount
> : > of effort the people at RedHat, Suse and others put into driver
> : > development. If that does add value I don't know what does.
> : >
> : This is a fiction. Redhat do *not* develop drivers.
>
> Redhat IS paying other people to develop Linux. Alan Cox is contracted
> to develop for Linux through a company he set up that is paid by Redhat
> Labs. See http://www.linux.org.uk/diary/ for info. They are paying to
> develop Gnome. See http://www.labs.redhat.com/ for info.
Sorry, I have not followed this thread from the start, but redhat is
also helping xfree86.org with drivers. Quote from www.xfree86.org:
"Red Hat Inc. and Presicion Insight Inc. have contributed their
NeoMagic driver to XFree86 for inclusion in the XFree86 3.3.3
release. They are also working on some 3D infrastructure. More
details are available on our major contributors page."
------------------------------
From: [EMAIL PROTECTED] (Jim Richardson)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: 2 Apr 1999 06:34:36 GMT
Reply-To: [EMAIL PROTECTED]
On 01 Apr 1999 23:24:29 +0100,
Nix, in the persona of <$}xin{[email protected]>,
brought forth the following words...:
>
>I know which wins in *my* book. This cannot be defined as an advantage
>on the part of nedit. No matter how good a special-purpose langauge is,
>it is almost beyond the bounds of possibility that it is as good as
>lisp.[2]
>
>[1] when Scheme takes over from elisp, that is
>
Is this actually going to happen? I can have a reason to learn scheme?
cool.
--
Jim Richardson
www.eskimo.com/~warlock
All hail Eris
"Linux, because a cpu is a terrible thing to waste."
------------------------------
From: [EMAIL PROTECTED] (John McKown)
Subject: Re: Linux Kernel documentationI
Date: 3 Apr 1999 00:00:39 GMT
Reply-To: [EMAIL PROTECTED]
I've just received a book from http://www.linuxmall.com
It is "Linux Kernel Internals, Second Editon"
published by Addison-Wesley. ISBM 0-201-33143-8
It comes with a CD-ROM. I have NO idea how good it is. I just received
it and haven't had a chance to even open it yet. It has chapters on
the Kernel (including data structures), memory management, inter process
communication, the file system, device drivers, networking, modules.
It looks like it may be good. But I can't be sure. It does have a
preface by Linus, if that counts.
John
On Wed, 31 Mar 1999 22:17:08 +0200, root <[EMAIL PROTECTED]> wrote:
>I'm a novice about Linux but i'd found it wonderful.
>I'm an Andersen Consulting's consultant and when i can work on linux I'm
>very happy.
>I wrote to this group to ask you about a book (downloadable or not)
>which can teach me more about
>the inner workings of the kernel away from the university books (a lot
>of theory and a few of practice)
>Thanks in advance
>
>write to [EMAIL PROTECTED]
>
------------------------------
From: [EMAIL PROTECTED] (David M. Cook)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: Fri, 02 Apr 1999 06:42:01 GMT
On 2 Apr 1999 00:07:39 GMT, Dan Mercer <[EMAIL PROTECTED]> wrote:
>Elegant? I've never heard it called that before. The question is,
>why should I have to learn Lisp to get the most out of my editor?
>With nedit, you can point and click your way to most macros -
With emacs you can record macros, too.
I think elisp is easy to learn, though lisp is somewhat odd to those of us
who started with Pascal or C.
That said, I have no problem with pointing people towards nedit if that is
the sort of thing they are more comfortable with.
Dave Cook
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: gnu.misc.discuss
Subject: Re: How about /dev/web?
Date: 2 Apr 1999 18:19:12 -0500
In article <[EMAIL PROTECTED]>,
Joseph H Allen <[EMAIL PROTECTED]> wrote:
[I wrote:]
>>With SOCK_DGRAM you need packet boundaries *and* connectionless
>>stuff. E.g. sendto(), even if your socket isn't connected.
>
>This is easy. As with the tape device driver, Write() and read() give the
>packet boundary. Open() gives the destination. Open() in this case does
>not actually specify a connection, just the address for the write or read.
>Alternatively, write() takes a packet containing both the address and the
>data (you just open("/dev/dgram")). The second method is faster, but the
>first is probably more useful for shell scripts.
Erm... So you are doing open();write();close(); instead of sendto()? Cool.
Which address will it be bound to? BTW, since when did you get select() in
shell?
>>You also need OOB stuff.
>
>The OOB stuff is a real annoyance (incidentally, what uses it?). Here I
>would stoop to using an ioctl().
What will you do with passing descriptors via AF_UNIX (SCM_RIGHTS)?
>> Try strace -elseek vi foo 2>/tmp/bar. And watch the show. *More*
>>than sure that the same holds for EMACS (sorry, I don't have it on any
>>of my boxen; on SunOS boxen in Uni it *definitely* uses lseek()).
>
>Does it use it on 'foo' or the temporary swap file? (On SGI no lseeks are
Both.
>used at all in the above test). I've looked at the code for emacs, and know
>that it is not true (it just reads the whole file into memory in one fell
<boggle><Boggle><BOGGLE> WTF will happen if you have 40Mb file?
RSS>40Mb??? Well, I knew that RMS had odd tastes, but *that*... Are you
serious? No arbitrary limits, my ass... Size of swap isn't arbitrary, sure.
>swoop). Actually I just tried it on emacs, and it uses lseek on some
>startup file only.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Rajappa Iyer <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: How about /dev/web?
Date: 02 Apr 1999 15:40:58 -0500
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Joseph H Allen) writes:
> Plan9 namespaces are nice, but they don't go anywhere near far enough:
>
> It would be nice if there were a way to mount a device driver (loadable
> module) as the server for a pseudo-directory.
Check out Inferno.
www.lucent-inferno.com
--
Rajappa Iyer <[EMAIL PROTECTED]> #include <std_disclaimer.h>
We're too busy mopping the floor to turn off the faucet.
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Subject: Re: polling an interface at 12 KHz
Date: 2 Apr 1999 06:28:26 GMT
>> > I have to devellop an application which polls a hardware-interface at
>> > 12 KHz and I was thinking about develloping this application on
>> > Linux. I'm not really into Linux yet so before I get into it, could
>> > someone give me an indication on whether I have a chance of achieving
>> > this ?
of course. it's basically trivial to do, if you busy-wait in a
realtime thread. of course, the machine will not respond like
a multitasking box during that time. it's somewhat harder, but
still hardly a big deal, to turn HZ up to 12 KHz, and be a little
kinder. the ideal solution is to do this in kernel space, since
then you can make the performance impact near-zero.
> In general anything around or faster than 100Hz is problematic since the
> kernel gets interrupted for scheduling at that frequency. You then have
this is not an issue.
> However, the real time clock may be programmed to generate interrupts and
> works quite well up to around 1KHz (/usr/src/linux/Documentation/rtc.txt),
8KHz.
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: gnu.misc.discuss
Subject: Re: How about /dev/web?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 03 Apr 1999 01:02:24 GMT
On 2 Apr 1999 18:19:12 -0500, Alexander Viro <[EMAIL PROTECTED]>
posted:
>In article <[EMAIL PROTECTED]>,
>Joseph H Allen <[EMAIL PROTECTED]> wrote:
>>used at all in the above test). I've looked at the code for emacs, and know
>>that it is not true (it just reads the whole file into memory in one fell
>
> <boggle><Boggle><BOGGLE> WTF will happen if you have 40Mb file?
>RSS>40Mb??? Well, I knew that RMS had odd tastes, but *that*... Are you
>serious? No arbitrary limits, my ass... Size of swap isn't arbitrary, sure.
>
>>swoop). Actually I just tried it on emacs, and it uses lseek on some
>>startup file only.
Hmmm...
In my archives, I have a message from the Debian/Hurd mailing list,
and from Thomas Bushnell in particular (probably ought to be a fairly
authoritative source :-)), that indicates that Emacs can assume, at
configure time, either that:
a) mmap always exists, or
b) mmap never exists.
Hurd NFS doesn't (didn't?) support mmap at the time (actually, that
"time" being about 6 weeks ago) which meant that emacs would fail on
Hurd if/when you hit a FS that didn't support mmap...
The goal was to fix Emacs to support mmap errors, and in such
circumstances, fall back to non-mmap code.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
** 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
******************************
