Linux-Development-Sys Digest #55, Volume #7 Mon, 16 Aug 99 05:14:06 EDT
Contents:
Re: rc.local or command line ("Tim Sell")
Re: vi and non-printable character (Matthias Kilian)
Re: Source code licenses allow sharing between Linux and BSDs? (Errin Watusikac)
Re: /proc/<pid>/stat info incorrect on SMP systems? (David T. Blake)
Re: Looking for a good IP packet analyzer (Remco Treffkorn)
Re: berzerko mouse from hell (Johan Kullstam)
Re: vi and non-printable character (Robert Komar)
XXX Fucking Pics ([EMAIL PROTECTED])
Re: Looking for a good IP packet analyzer (M van Oosterhout)
Re: [kernel] how to measure running time in nanosecond? (M van Oosterhout)
Re: vi and non-printable character (Kaz Kylheku)
Re: why not C++? (Xip)
Kernel Debugging (root)
Re: why not C++? (Kaz Kylheku)
Re: why not C++? (Kaz Kylheku)
----------------------------------------------------------------------------
From: "Tim Sell" <[EMAIL PROTECTED]>
Subject: Re: rc.local or command line
Date: Sun, 15 Aug 1999 19:51:14 -0400
Your problem may involve your PATH environment variable. Within rc.local,
PATH may only include /bin and possibly /sbin, but when you run from the
command line your PATH is probably much longer.
Use the "which" command to find out where each of the programs you are using
in your script resides, then code that path into your script. It is
considered good practice to use intermediate environment variables to refer
to commands invoked from within a script where your PATH setting is
suspected to be unknown or incomplete. For example:
RM=/bin/rm
CP=/bin/cp
Then use ${RM} and ${CP} where you would normally use rm and cp.
Hope this helps.
- Tim Sell
Vyl Chan <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi,
>
> I'm having some trouble running a script that runs perfectly from
> the command line but doesn't run completely from rc.local. What is the
> difference between invoking a script from the command line and invoking
> from the rc.local??
>
> --Vyl
>
> Vyl Chan
> Stanford University
>
>
------------------------------
From: [EMAIL PROTECTED] (Matthias Kilian)
Subject: Re: vi and non-printable character
Date: 15 Aug 1999 21:52:40 GMT
Kaz Kylheku ([EMAIL PROTECTED]) wrote:
> In the vim editor, go into insert mode, type ctrl-v, then type three octal
> digits, or type x followed by two hex digits.
Or just type your special character after ctrl-v, e.g. the escape-key,
ctrl-M, or whatever.
This should work even for plain vi on other unices. Don't know wether octal
and hex codes work there.
Kili
------------------------------
Crossposted-To:
comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.openbsd.misc
Subject: Re: Source code licenses allow sharing between Linux and BSDs?
From: Errin Watusikac <[EMAIL PROTECTED]>
Date: 15 Aug 1999 16:48:18 -0700
[EMAIL PROTECTED] (Randall Parker) writes:
> I had a developer mention to me in private e-mail that the reason that
> Linux's threading model is a separate patch add-on to the BSDs is that
> there are some sort of licensing issues that cloud whether it can be
> added directly as part of the regular shipping releases.
>
> So I want to know as a legal question:
I think there's some law that prevents me, a non-lawyer, from giving you
a legal answer. So I hope this is a non-legal answer, not an illegal
answer.
> 1) Can source code from Linux be added into the regular releases of any
> of the BSDs?
Some of it may.
> 2) Can source code from any of the BSDs be added into the regular
> releases of Linux?
Some of it may.
> 3) Can the various BSDs all get source code from each other, again
> without any licensing restrictions?
There are licensing restrictions on almost all of the software.
> To what extent can these different groups of freeware/open source OS
> developers freely share source code with each other?
They may freely share some code completely and some not at all.
Loosely speaking, the BSD group shares and the Linux group hoards.
The both have good reasons for doing so. Sadly, the Linux group
(my group) too often promotes its use of the GPL as a means of
reducing hoarding and engages in other such misleading double-talk.
===========
Your questions are all very general and seem to assume that all of
the software for each OS use the same license. There are hundreds
of owners of the software for any one OS. There are several commonly
used license texts and many unique ones.
If you were referring only to the OS "kernels", then I don't know
the detail well enough to give you a full answer, but I'll start.
The Linux kernel has a claimed joint ownership of hundreds or
thousands (of course everyone allows Linus to act as owner as long
as he doesn't do anything outrageous) and is licensed using the
GPL with an addendum that allows non-GPL'd software to link to it
for the purpose of system service calls.
I guess the BSDs all are derivatives of a BSD which used the old
BSD license (though some, if not all, use the new BSD license too,
particularly for new code).
The result is that, in general, the two kernels may not use each other's
code, with two exceptions: 1) New BSD kernel code which uses only the
new BSD license (without the "acknowledgement" clause) can be used in
the Linux kernel. 2) Linus has spoken for the other owners, and "allows"
non-GPL'd loadable kernel modules to be distributed with the kernel.
In practice, BSD- and X11-type licensed software is often treated as
if its copyrights had been transferred the public domain; many
have no qualms about changing the licence on derivatives without
consulting the other owners of the now-joint "work". Most will
obey the terms of the original license and think there are no other
considerations. I think they are wrong. They may, according to the
license, distribute modified versions of the software in source or
binary form, but nothing has given them the right to change the
license of the original licensor's code which is contained in the
now-jointly-owned software. The BSD license says "All rights reserved."
That includes the right to control the use of their software using
a license. The work of the original licensor remains controlled by
that license until he explicitly allows the license to be changed.
It seems like basic copyright law concepts. I wouldn't have any doubt
that I could be wrong about this, except that it seems that so many
disagree. IFAIK, no one has been to court over it yet.
Please read the licenses for further enlightenment.
You can find links to the BSD and GNU licenses at
http://www.freebsd.org/copyright/
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: /proc/<pid>/stat info incorrect on SMP systems?
Date: 16 Aug 1999 00:34:18 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Having whipped out the SRPM and discovered that RedHat did indeed
> author procps-2.0.2, I perused the code...
>
> As I would expect, it's just adding together the boot time and the
> process start time (since boot) to arrive at the "STIME". The code
> says that ps is getting this info from /proc/<pid>/stat.
It indeed "says" that. But look deeper, if you can fathom
that package, to try to verify it. The time in /proc/pid/stat
is correct, but I don't think it ever gets parsed. It would be
pretty easy to fix if that were the bug. I think it is
counting jiffies at some point instead of time.
> It would seem that this is a SMP procfs kernel bug because it
> appears that the process start time since last boot is divided by
> the number of CPUs in the system.
>
> Perhaps some kind souls with duals and quads can confirm that
> this bug is present in the vanilla 2.2.5 and 2.2.11 kernels?
Absolutely, although I haven't checked 2.2.11. It comes
with 2.2.10 and the RH 6.0 release, at least for duals.
I downloaded procps to try to see how fixable it would be,
but then I realized "cat /proc/<pid>/stat" will work fine
for me, and the code for the start time in procps is
labyrinthine.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: Remco Treffkorn <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Looking for a good IP packet analyzer
Date: Sun, 15 Aug 1999 17:58:38 -0700
Tom Emerson wrote:
>
> I'm looking for a good, easy-to-use packet analyzer that runs under Linux.
> Yes, I know "tcpdump" exists, but that doesn't (easily) show me what I'm
look at http://pweb.uunet.de/trillian.of/Spy/ for spy. Free for personal
use, no source. Looks nice.
http://mojo.calyx.net/~btx/karpski.html also looks nice and comes with
full source.
Cheers,
Remco
------------------------------
Subject: Re: berzerko mouse from hell
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 15 Aug 1999 21:28:34 -0400
[EMAIL PROTECTED] (Chris Gregory) writes:
> On 11 Aug 1999 20:12:00 -0400, Johan Kullstam <[EMAIL PROTECTED]> wrote:
> >
> >i have a berzerko mouse from hell.
[snip]
> Are you running gpm? I seem to recall reading something about gpm messing
> up PS/2 mice under X. There's a fix for it, notes are somewhere in the
> kernel documentation.
no, i am not running gpm.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: Robert Komar <[EMAIL PROTECTED]>
Subject: Re: vi and non-printable character
Date: 15 Aug 1999 18:37:58 GMT
[EMAIL PROTECTED] wrote:
: If my memory serves me correctly, there is a way to
: stick an octal or hex character directly into
: a line of text. Does anyone know how to do this?
You can use Ctrl-V followed by the decimal value of
the character or the control code for it. I don't
know how to insert it using the octal or hex value
of the character, but maybe someone else does.
Cheers,
Rob Komar
------------------------------
From: [EMAIL PROTECTED]
Subject: XXX Fucking Pics
Date: 14 Aug 1999 15:18:53 -0800
XXX PICS XXX PICS
http://www.nettaxi.com/fcitizens/adult168/dp/p3.htm
------------------------------
Date: Mon, 16 Aug 1999 13:58:21 +1000
From: M van Oosterhout <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Looking for a good IP packet analyzer
Dana Hudes wrote:
>
> A review of the tcpdump man page refers to another program from the same
> group, BPF.
> tcpdump doesn't capture outbound packets from the host it is running on.
Yes it does.
Martijn van Oosterhout
Australia
------------------------------
Date: Mon, 16 Aug 1999 13:49:47 +1000
From: M van Oosterhout <[EMAIL PROTECTED]>
Subject: Re: [kernel] how to measure running time in nanosecond?
=B7=A8=A8=CE=AAY wrote:
> =
> using do_gettimeofday & timeval just can measure in microseconds
> =
> does there any patchs or methods help me to do this
Pentium has an rdtsc instruction that can do this.
Martijn
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: vi and non-printable character
Date: Mon, 16 Aug 1999 05:08:05 GMT
On 15 Aug 1999 21:52:40 GMT, Matthias Kilian <[EMAIL PROTECTED]> wrote:
>Kaz Kylheku ([EMAIL PROTECTED]) wrote:
>> In the vim editor, go into insert mode, type ctrl-v, then type three octal
>> digits, or type x followed by two hex digits.
>
>Or just type your special character after ctrl-v, e.g. the escape-key,
>ctrl-M, or whatever.
Actually what I said is wrong. Without the x prefix, it is the decimal
character code you are entering, rather than octal.
------------------------------
From: Xip <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 16 Aug 1999 02:07:56 -0500
Reply-To: [EMAIL PROTECTED]
Cocheese wrote:
> Dear Linux Community;
>
> There has been a puzzling question on my mind for some time. First, I
> admit i am no Linux Guru so this may be off the wall.
>
> *Why Is linux done primarily in the C programming language rather than
> C++?*
>
> Again I admit it would take a little extra work and put a minor set
> back in the evolution for a month or 2, but if C++ is so much faster,
> easier, and stable- WHY NOT?
>
> I have been a RH 6.0 user since the first week it was first released
> and since then i have loved it. I am struggling with it a bit but as i
> continue to learn this from an "other leading brand OS" and a full time
> programmer for a large company.
>
> There are many differences Between the two programming languages and
> there are huge advantages to C++.
>
> The downside is "linux has always been a C based Program so it will always
> be."
>
> *** BUT THEN AGAIN - ISN'T LINUX ALL ABOUT CHANGE? ***
>
> -Sincerely
>
> cocheese
>
> ------------------ Posted via CNET Linux Help ------------------
> http://www.searchlinux.com
Linux is primarily written in C because the C libs and gcc compiler is a lot
more stable than g++ and C++ libs used in Linux. Also, switching to C++ would
take a lot longer, considering GTK+ (even though there is GTK-- for C++) and
the other libs that are C specific. I prefer C because I don't really have
time to learn C++ (but I plan to), and so I can use the GTK+ libs.
Xip
------------------------------
From: root <[EMAIL PROTECTED]>
Subject: Kernel Debugging
Date: 16 Aug 1999 07:28:44 GMT
Is there any way to debug kernel just like using gdb at normal user program?
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 16 Aug 1999 07:54:30 GMT
On Mon, 16 Aug 1999 06:30:47 GMT, Cocheese <[EMAIL PROTECTED]> wrote:
>Dear Linux Community;
>
> There has been a puzzling question on my mind for some time. First, I
>admit i am no Linux Guru so this may be off the wall.
>
>
>*Why Is linux done primarily in the C programming language rather than
>C++?*
For one thing, when Linux started out, g++ wasn't all that great.
Only recently has g++ been whipped into shape by the EGCS project.
> Again I admit it would take a little extra work and put a minor set
>back in the evolution for a month or 2, but if C++ is so much faster,
Rewriting significant system components such as the kernel to take advantage of
the features of C++ would not be a month or two setback.
>easier, and stable- WHY NOT?
Doh, because it's NOT so much faster, easier and more stable? It's not faster
in run-time efficincy, nor in compile time. The history of g++ doesn't exactly
paint a picture of stability either.
C++ requires more extensive run time support. It gives you the object
orientation features, but you are stuck to how they are implemented by the
compiler. Many features in C++ are so complex that significant design choices
are involved in deciding how to implement them even without considering
machine dependencies. Once they are implemented a given way in a compiler,
the users are stuck with that.
Here is trivial example of C++ inflexibility. In C++, your concrete object has
to implement all pure virtual methods inherited from an interface base class.
Otherwise, invocations of that method cause a run time error (call to pure
virtual function). In many places in the Linux, virtual methods that are not
implemented are represented by a null pointer. The code that wants to call
the method tests for null and bypasses. Don't want to implement poll() in your
driver? No problem, just set it null. You can't do this in C++ code without
compiler-specific tricks that are undefined at the language level. The
compiler-generated virtual tables are sacred and untouchable things that are
invisible to the programmer. The usual escape hatch is to implement the
function, but have it return some ``I am not really implemented'' status. That
is much more expensive since an actual dispatch has to take place.
Another problem in C++ is that only member functions of a class can be virtual,
not data members. In C, whatever mechanism you use to represent virtual
dispatch tables can also hold things that are not pointers. Suppose that every
object in a class hierarchy has some characteristic that can be represented by
an integer. The characteristic is shared among all objects belonging to the
same class. In C++, you have to stick this characteristic into a base class
common to all the objects, or else use a virtual function to query the
characteristic. This is stupid, because the characteristic isn't settable for
each object, but is class-wide. You would ideally want to have some way of
saying ``object->characteristic'' and have virtual lookup take place to return
the class-specific value, but it's not available. You can do it easily if you
implement your own virtual table mechanisms. A virtual table done explicitly
can easily contain not only pointers to methods, but other class-specific data
as well.
In C++, when you start using multiple inheritance together with polymorphism,
things get very ugly at the compiler level. Depending on the vtable
implementation, you start seeing things like thunk code whose only job it is to
adjust an object pointer's value and then branch to some other code. Such
overheads exist even if you only use a subset of the full capabilities, such as
restricting yourself only to pure abstract base classes to create a single
concrete object. In actual object oriented programming, this sort of interface
inheritance is frequently all that you need, but C++ compilers make you pay
for the features you are not using.
In Linux, multiple inheritance is handled in an efficient, straightforward
manner. An ``class'', such as driver, implements two or more interfaces, which
are just sets of functions. Ppointers to these get stuffed into some
``operations'' structures that are static (that's another advantage to doing
things ``manually'': initialize vtables at run time!). The object then contains
some base part which contains a back pointer to the outer object. No
pointer-adjusting thunk functions are needed. The method itself can frequently
do the conversion simply by retrieving the context pointer from the base part
that it was given in the call. You can almost see the machine code. (Example
of multiple inheritance: the PPP driver, which is a kind of network device as
well as a kind of TTY line discipline).
> There are many differences Between the two programming languages and
>there are huge advantages to C++.
There are big advantages in C++, but I find that too many C versus C++
comparisons are based on false assumptions that none of the new C++ features
can be effectively simulated in C, or that the underlying techniques that the
C++ features support are unavailable to the C programmer. Assumptions such as
``because C doesn't have classes, object-oriented programming is impossible,
or so difficult as to be utterly impractical''.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 16 Aug 1999 08:05:07 GMT
On Mon, 16 Aug 1999 06:47:45 GMT, Satch <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Cocheese) wrote in
><[EMAIL PROTECTED]>:
>
>>*Why Is linux done primarily in the C programming language rather than
>>
>>C++?*
>
>Good question. Let me propose an answer. It has to do with the fact
>that the C++ environment has a lot of "baggage" that would adversely
>affect an operating system.
>
>First, the object model with its constructors and destructors mandates a
>heavy-duty memory management routine...and usually that memory management
>routine is part of the operating system. Chicken and egg problem...
Constructors and destructors don't imply memory management. They are just
functions that initialize and deinitialize an object. You have to have
constructors and destructors one way or another if you program using
abstract data types, because you need some way to bring each data object
into a sane state.
But there are disadvantages to C++ constructors. For one thing, they do not
return a value. The only sanctioned mechanism for indicating construction
failure is to throw an exception. Exception handling requires run-time support
and causes an increase in object file size. It has only recently begun to be
properly supported by G++, thanks to EGCS. The implementation adds serious
bloat to object files.
>Next, it's very difficult to predict how a C++ package is going to react
>in all circumstances, because there is more state inherent in a C++
>program than in a regular C program. Dynamic detection of object type,
>and run-time binding of objects to subroutines means that you have more
>run-time overhead...and operating systems already take too many cycles
>for the services they provide.
Linux has dynamic detections and virtual dispatches explicitly done in C. For
the most part, the mechanisms are clean and easy to understand. This can be
important if you are oops tracing after a crash.
------------------------------
** 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
******************************
