Linux-Development-Sys Digest #95, Volume #7 Tue, 24 Aug 99 00:14:10 EDT
Contents:
Traffic accounting on multiple IP (Emmanuel CHILAUD)
Re: Custon Device Drivers (Grant Edwards)
Re: X Windows developement (Grant Edwards)
Re: Troll (was: why not C++?) (Stephan Houben)
what about SGI's xfs? (Arnoud de Geus)
Re: TAO: the ultimate OS (Selious)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and (Tristan
Wibberley)
Re: the ultimate OS ("Pizzi")
Re: Telnet problem (Allin Cottrell)
Re: [kernel] how to measure running time in nanosecond? (Hee-Chul Yun)
loading an OS using Linux (Sandeep Kumar)
Re: MPEG2 support for Linux ? (Alex Luk)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Josh Stern)
Re: where's the source to init (Phil Howard)
How do you revert from Afterstep to KDE? (Mal)
Re: C++ templates: More than Turing Complete? (David Schwartz)
Re: Help!! LILO booting stopping on LI (Phil Howard)
----------------------------------------------------------------------------
From: Emmanuel CHILAUD <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Traffic accounting on multiple IP
Date: Mon, 23 Aug 1999 22:31:34 +0200
Reply-To: [EMAIL PROTECTED]
Hi all !
I'm using a linux RedHat 5.2 server with IP-aliasing on a class C range
of adresses.
I need to have a traffic report by ip every day or week or month.
Are there any free products for that or did someone developped a such
utility ?
Thanks in advance,
Manu
------------------------------
From: grant@nowhere. (Grant Edwards)
Subject: Re: Custon Device Drivers
Date: Mon, 23 Aug 1999 20:18:45 GMT
In article <[EMAIL PROTECTED]>, David Schwartz wrote:
>
>Grant Edwards wrote:
>> It could be that most of the "value" they're selling is in the
>> driver, not in the hardware. If they publish sources to the
>> driver, somebody else can come up cheap, compatible hardware,
>> and then they've got no product.
>
> Why then wouldn't they be willing to provide the source to their
>customers, licensed for exclusive use with their hardware? The usual
>reason is simply that the driver is so poorly written that they're too
>embarrased.
Or that management is just worried about letting trade secrets
out. Copyright only protects one particular expression of an
algorithm -- not the algorithm itself. If it's not patentable,
then your only option is "trade secret" protection -- and then
you pretty much can't publish it (even under license agreements).
[Insert standard I-am-not-a-lawyer disclaimer here.]
> But let me ask another question: Do you plan to release the hardware
>specifications of the board so that your customers could write their own
>driver if they chose to?
Firstly, I'm not involved and am not associated with those who
are, I'm just speculating as to their reasons. Second, it's
not at all unusual for a HW vendor to not release specs. One
would hope that they would realize by now that not releasing
specs just limits their market.
>If not, why not?
Same as the answer about source code. Management doesn't want
to let out what they think are valuable trade secrets. Whether
these "secrets" are actually secret or worth protecting, or
whether letting them out increases or descreases teh potential
market is always up for debate.
>If so, then if your board is
>at all popular, someone else will probably write a driver anyway, and
>people will prefer it over yours because they'll get the source to the
>other driver.
Exactly. My opinion is that if people out there are willing to
donate time to write drivers for your hardware, you'd be stupid
not to take advantage of the offer.
--
Grant Edwards grante Yow! Is this BOISE??
at
visi.com
------------------------------
From: grant@nowhere. (Grant Edwards)
Subject: Re: X Windows developement
Date: Mon, 23 Aug 1999 20:27:35 GMT
In article <7pk544$4r9$[EMAIL PROTECTED]>, Tranceport wrote:
>> Just curious: which part? You have to write a server for an
>> ASR33? You have to reimpliment xlib in COBOL?
>In any case to answer your question, I have to develop Xaw (X athena
>widgets, i think)
If you are developing a new widget based on the Xaw model, then
one of the O'Reilly books covers that (volume 2 or 3?). IIRC
it shows how to implement a bitmap display widget (something
like what you see in the "bitmap" application). I developed a
backgammon board Xaw widget several years ago, and the O'Reilly
books provided a good framework from which to do that.
I never found a decent backgammon engine to hook it to. The
old BSD backgammon program wasn't too good. Once you figured
out where it's flaws were, you could beat it every time.
--
Grant Edwards grante Yow! I'm pretending that
at we're all watching PHIL
visi.com SILVERS instead of RICARDO
MONTALBAN!
------------------------------
From: Stephan Houben <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Troll (was: why not C++?)
Date: 18 Aug 1999 09:48:15 +0200
Timo Tossavainen <[EMAIL PROTECTED]> writes:
> Graffiti wrote:
>
> > Oh god. The return of the LISP machines.... *shudder*
> > They weren't *bad*, but look at where they are now. See my point?
> > (Or rather, don't see it? :-)
>
> Well, I think the lisp machines had specialized chips to evaluate lisp and were
> quite proprietary. I think a modern open Lisp OS would be a good idea.
I disagree. It's a bad idea to have a Lisp OS, a C++ OS, a Java OS,
and basically any X OS where X is a programming language. Why?
Because a general purpose OS should *never* force a particular
programming language upon its users. No language is perfect.
Every language sucks, if confronted with the "right" (i.e. the wrong)
application area.
IIRC there was a C compiler for some Lisp machines. It implemented
pointers with "cons"-cells. A greater abstraction inversion the world
has never seen.
Note that Linux is not a C OS. It is a general-purpose OS whose kernel
happens to be written in C. If they hadn't told me this, I would never know.
I still don''t care. As long as the StephanTalk compiler does its job,
I don't care in which language the OS is written.
Greetings,
Stephan
------------------------------
From: Arnoud de Geus <[EMAIL PROTECTED]>
Subject: what about SGI's xfs?
Date: Mon, 23 Aug 1999 23:16:04 +0200
Hello,
Can anyone tell me what the current status of the integration
of SGI xfs (journaling) file system in Linux is. In which version
will it most probably be integrated?
Reg's, Arnoud.
------------------------------
Date: Mon, 23 Aug 1999 23:10:28 +0200
From: Selious <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
> we will change the name to "Vladimir" to reflect a more
> modern philosophy.
Zjirinofski-OS...
Take FULL control over your computer...
--
pii350.ntdom: up 24 days, 22:57,
linux.ntdom: up 118 days, 22:35,
nw411.ntdom 112 days, 14:31
nwtest.ntdom 123 days, 20:57
alpha.ntdom: 1:08am up 59 days,
linux4.ntdom: up 105 days,
freebsd.ntdom: up 19 days, 3:05,
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
Date: Mon, 23 Aug 1999 00:41:22 +0100
Reply-To: [EMAIL PROTECTED]
Jonas Utterstrom wrote:
> I
> used functions with different names in the exe. These two functions used
> an internal function, with the same name in both libraries. And the
> function from the first shared linked library was always used.
Isn't there a linker option that lets you instruct the run-time linker
to discard the pointer to the definition of a particular symbol between
so files.
eg (pseudo command line - I can't find my documentation for ld :(,
link -o myexe myexe.o -llibA.so -discard foo -llibB.so
so the dynamic linker gets the correct definition of foo for A, drops it
for future resolutions, and gets the correct definition for B? Or is
this only for static linking?
I can imagine complex situations getting ugly though.
--
Tristan Wibberley
------------------------------
From: "Pizzi" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: the ultimate OS
Date: Mon, 23 Aug 1999 20:43:39 -0400
:-) I like the "What is an OS?" section, being that it was posted to a
systems programming newsgroup.
------------------------------
From: Allin Cottrell <[EMAIL PROTECTED]>
Subject: Re: Telnet problem
Date: Mon, 23 Aug 1999 21:06:40 -0400
Tranceport wrote:
> when I try to telnet from one computer (Win or Linux, doesn't matter) to
> a Linux box (RH6) after I enter login and password, I always get the
> same answer, no matter what account I'm using: 'Login incorrect'.
man 5 hosts_access
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
------------------------------
From: Hee-Chul Yun <[EMAIL PROTECTED]>
Subject: Re: [kernel] how to measure running time in nanosecond?
Date: 23 Aug 1999 13:49:48 GMT
Mark Hahn <[EMAIL PROTECTED]> wrote:
>> Use Linux-2.2.11 and then add Ulrich Windl's 'NANO' patches. You can
> there's no reason to use any particular kernel or patches. the following
> provides ultimate resolution; calibrating it (finding secondsPerTick)
> is pretty trivial:
> typedef unsigned long long u64;
> inline u64
> rdtsc() {
> u64 clock;
> __asm__ __volatile__("rdtsc" : "=A" (clock));
> return clock;
> }
more simple way is to use 'get_cycles()' function.
which is defined in <asm/timex.h> and that function use 'rdtsc' as you
know..
--
Hee-Chul, Yun e-mail: [EMAIL PROTECTED]
KAIST CS Dept, CA Lab. Phone : 5552(Lab), 017-755-9413
------------------------------
From: Sandeep Kumar <[EMAIL PROTECTED]>
Subject: loading an OS using Linux
Date: 23 Aug 1999 17:41:57 -0700
Hi everyone, I've grappled with this a while, so I'm seeking help. Briefly,
I'd like to load xinu (for Pentium) using Linux. I think that version just
runs in real mode.
The xinu distribution from ftp://ftp.cs.purdue.edu/pub/Xinu/ compiles on a
Linux box which I then copy to /boot, add an entry into /etc/lilo.conf, run
lilo, and reboot. The system hangs with the message "Loading xinu".
So, my question is: has anyone else done this yet? Are there any
suggestions? What I would like to know, without serious debugging of the
Linux Makefile is:
o Is there a way to compile a program such as xinu so that it is linked to
exactly the address to which it will be loaded by Lilo?
o How do I indicate to Lilo to jump to xinu's start()?
o Whatever else I need to know...
I'm also thinking that I could conceivably compile xinu as a module (PIC)
and, on load, just go into real mode or some such and call xinu's start(),
perhaps after relocating it to where it needs to be? Any suggestions?
Thanks
--sandeep
------------------------------
From: Alex Luk <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: MPEG2 support for Linux ?
Date: Tue, 24 Aug 1999 09:59:49 +0800
Hi,
Could you please tell me where can i find the MPEG1 player and development kit
for Linux? We are currently working on a Video-On-Demand project on Linux
project, we really need some help on MPEG decoder on Linux.
Thanks in advance.
Alex Luk
The Chinese University of Hong Kong
Clemence wrote:
> Hi,
> I am aware that there are Mpeg1 players and development kit for Linux. But
> how are Mpeg2 player and development kit ? Is there any plan or release
> date for such Mpeg2 support on Linux ?
>
> Your reply is appreciated.
> Clemence.
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
From: [EMAIL PROTECTED] (Josh Stern)
Date: Mon, 23 Aug 1999 15:54:34 GMT
Mark Hamstra <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Josh Stern) writes:
>> Mark Hamstra <[EMAIL PROTECTED]> wrote:
>> >[EMAIL PROTECTED] (Josh Stern) writes:
>> >> The namespace pollution issue is orthogonal to the size
>> >> one.
>> >No, it's not. Reducing namespace pollution by removing
>> >symbols from a shared library directly results in decreased
>> >size of the .dynsym and .dynstr sections, and thus of the
>> >shared library as a whole -- and not by an insignificant
>> >amount if the reports from the mozilla developers are
>> >accurate.
>> Well okay, now we've changed what is actually shared by
>> the shared library (as opposed to just what it is called
>> in the global namespace).
>Not sure exactly what you mean here.
I meant that those symbols can no longer be referenced be
linked to directly by code that is external to the library
using any name. In that sense they are no longer "shared"
and the API functionality of the library in addition to its
name has changed. That's probably all good and desirable in
this case, but just a bit different from what people usually
mean when they talk about avoiding namespace pollution.
- Josh
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: where's the source to init
Date: Tue, 24 Aug 1999 02:31:51 GMT
On 20 Aug 1999 05:36:47 GMT John McKown ([EMAIL PROTECTED]) wrote:
| On a RedHat system, the easiest way to find out which package contains a
| particular file is to use the rpm command. In your case:
|
| rpm -qf /sbin/init
|
| Which gets the response (on my system):
|
| SysVinit-2.74-11
|
| So look for SysVinit-2.74-11.src.rpm on the second disk. Your file name
| may vary if you are not running RedHat 6.0 . This will work for any
| file that is installed via rpm. It does no good for anything installed
| from a tarball. But then, if you installed it by hand, I guess you'd
| know where you installed it from. Unless, like me, you tend to be
| forgetful.
What about non-RPM based systems? Since a given package can have many
files, and the relationship is not always known by everyone, it would be
nice if there was some kind of master index of files that exist in, and
get installed by, various packages (whether available in RPM or not)
that reveals at the least, the name of the tar file, and even better,
also the official source site to download from.
I once tried to encourage a couple of major FTP site operators to make
a contents index of all the tar files on their site, so it might be
obvious which one (tar file) to download to find a particular file by
at least the source name. They didn't seem to be interested in that.
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: Mal <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.alpha,comp.os.linux.development.apps
Subject: How do you revert from Afterstep to KDE?
Date: Wed, 18 Aug 1999 08:30:49 GMT
How do you revert from Afterstep to KDE? I initially had KDE running on
RedHat6, however i swithed to Afterstep. How does one revert back to
KDE. I have tried a switch too, but for some reason there is no option to
go back to KDE.
================== Posted via CNET Linux Help ==================
http://www.searchlinux.com
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: Mon, 23 Aug 1999 20:43:15 -0700
Davin McCall wrote:
> Incidentally, if a C++ compiler couldn't compile the example given to
> demonstrate "why not all C++ programs can be compiled to finite
> assembly code" (although some that can't could be run as a script), it
> is a problem with the compiler design rather than any logical
> impossibility.
No, it's a defect in the example. If templates are Turing complete, it
is theoretically possible to create examples of C++ code that, while
legal, can never be compiled into valid code because the existence of
the valid code would be logically equivalent to a proof that the
compilation could not terminate.
It's kind of like the equivalent of, "Though this sentence is true, you
will never realize it." Obviously, you can never realize that that
sentence is true (because if you did, you'd have proven that you
couldn't). But since that's what it says, it _is_ true, right? Oh, wait,
...
If C++ is turing complete, it should be possible to construct similarly
self-referencial pieces of code. They would be syntactically valid.
Obviously, they could not be compiled.
DS
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: Help!! LILO booting stopping on LI
Date: Tue, 24 Aug 1999 03:00:37 GMT
On 20 Aug 1999 11:18:32 -0700 Ronald Cole ([EMAIL PROTECTED]) wrote:
| [EMAIL PROTECTED] (Horst von Brand) writes:
| > LI means the geometry lilo is seeing doesn't agree with what the kernel
| > knows. Try using the "linear" option, or redefining your disk (LBA, LARGE,
| > etc) via BIOS settings.
|
| Doesn't setting LBA in the BIOS just juggle the heads/cylinders to
| maneuver around the 1024 cylinder limit?
Setting LBA in the BIOS chooses a BIOS API geometry (the geometry that
programs such as LILO and DOS have to assume when calling BIOS I/O functions)
that affords the greatest level of coverage over the 8 gigabytes that the
BIOS API is limited to.
There are actually TWO layers of disk geometry translation taking place.
The first layer is in the BIOS. The calls from LILO to the BIOS translate
from the API geometry to the device command geometry. The BIOS API geometry
is limited to 10 bits for cylinder (hence the commonly known 1023 or 1024
cylinder limit), 8 bits for head, and 6 bits for sector. These 24 bits of
data thus limit the I/O requests to no more than 16777216 sectors, which at
512 bytes each, is 8 gigabytes. The device command geometry has at least
16 bits for the cylinder, but only 4 bits for the head.
Before BIOS translation existed, the API values and the device values were
the same, but the least common denominator in size of each restricted the
access to 10 bits for cylinder and 4 bits for head. That meant that access
through the BIOS was really limited to 0.5 gigabytes. This limit can still
cause problems depending on how things are set up.
Then the device command geometry is further translated internally in the
driver controller to a real physical geometry which has greater complexity
because drives has a variable number of sectors per track depending on the
cylinder number.
Because LILO is making I/O requests through BIOS in terms of C/H/S geometry,
an inconsistency between the way the "lilo" program calculated the addresses
stored in the map files, and the way the BIOS "uncalculates" them when the
"LILO" boot sector image runs, causes I/O requests to be out of range very
quickly. Using linear addressing in LILO can help avoid this problem since
it will store the addresses in the map files as LBA, and LILO will recalculate
the LBA to the CHS format the BIOS is expecting. Still, even this is limited
to the maximum range the BIOS is capable of handling, which can be up to
8 gigabytes if the geometry is well chosen (use "LBA") or less if it is poorly
chosen.
If we ever have a boot loader that can do commands to the IDE drives directly,
then it would not be limited to the BIOS limitations. While such a thing could
be practical for IDE, it is not for SCSI since so many SCSI adapters work in
so many different ways. That's why each SCSI card has to have a BIOS extension
on it to add-in more code to support BIOS level I/O requests to SCSI devices
on that bus.
Even other platforms, such as SUN Sparc, have limitations due to legacy designs.
I'll be curious what kind of BIOS we get with Merced based machines. There's a
chance to "start over" and "do it right". The question is will the legacy
pundits have dominant control in such decisions. I sure hope not.
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
** 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
******************************
