Linux-Development-Apps Digest #285, Volume #7 Sat, 17 Mar 01 14:13:11 EST
Contents:
Bayonne call for volunteers (David Sugar)
Re: Dump a `top` to an unused terminal (Victor Wagner)
Re: GPL (John Hasler)
Re: Dynamic function availability in Linux ("Joseph A. Knapka")
Re: Ctrl C catcher (Kaz Kylheku)
Re: sizeof returns wrong structure size ([EMAIL PROTECTED])
Re: Re: Dynamic function availability in Linux ([EMAIL PROTECTED])
Re: Retrieving a web page ("Emilien Arino")
Re: GPL ("Tristan Wibberley")
Re: sizeof returns wrong structure size (Grant Edwards)
Re: GPL (Dave Blake)
----------------------------------------------------------------------------
From: David Sugar <[EMAIL PROTECTED]>
Subject: Bayonne call for volunteers
Date: Fri, 16 Mar 2001 21:27:00 -0500
Bayonne is a fairly established and ambitious free software project who's
goal, along with that of the larger GNU Telephony Project, GNUCOMM, is to
provide community supported scalable free software based telephony
solutions that are useful for individuals, for the small office and large
commercial enterprise, and for commercial carriers, that can displace the
proprietary solutions commonly used in the telecom industry today. In
addition to being a GNU package and a part of GNUCOMM, Bayonne is also
represented within the GNU Enterprise project.
Bayonne primarily focuses on voice response and what is commonly called a
telephony "application server". Bayonne is written in C++, has a fully
threaded architecture, and is bound together by a common scripting core
and DSO plugins. Other parts of GNUCOMM will focus on many related and
useful areas in providing a complete free software telephony solution.
Bayonne has recently reached release 0.5.17. This release represents a
fairly stable and functional multi-line voice response telephony server that
already works with a fair number of single and multi-line analog (and soon
digital) telephony cards available under GNU/Linux, and that can be made
to support Voicetronix hardware under FreeBSD. However, there are still
many areas of development that have not yet been addressed.
While Bayonne is useful today, we are certainly looking to extend Bayonne
functionality in many additional areas. Since we already have an abstract
interface for "telephony cards", support for entirely softswitch based
sessions will be added alongside traditional multi-line telephony cards
for use in the next generation telephone network, using projects like
openh323 and vovida as the base for these new services. This is just one
of many areas for potential and original development available within
Bayonne.
In issuing a call for volunteers, we are looking for more people to
contribute to development of the Bayonne package, both in specific niches
that have been identified, and in any other places people may identify and
wish to contribute on their own.
Currently, we both have, and need, people to volunteer with development in
several broadly defined areas. Some of these areas are already covered to
a limited degree, but certainly can use help and input from additional
people, and in all areas new contributors can still have a substantial
impact on Bayonne development.
Current active areas of development include redundancy and telephony
cluster server farming, XML scripting, Bayonne plugins, integrating FAX,
TTS, and ASR services, CORBA, more telephony drivers, and IP trunking.
Other areas that we need volunteers for include documentation, packaging,
web development, porting, application development, and voice library
management.
This list is not fixed, but represents how I currently divide Bayonne
development. If people have something different and interesting to
contribute to the package, or even wish to take on a specific challenge in
the broader GNUCOMM project, that would always be welcome as well. Those
interested can start by joining the Bayonne mailing list by sending e-mail
to [EMAIL PROTECTED] with the body of the
message being "subscribe", or by sending e-mail to me directly,
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To: comp.os.linux
Subject: Re: Dump a `top` to an unused terminal
Date: 16 Mar 2001 21:51:52 +0300
Genesis <[EMAIL PROTECTED]> wrote:
: Hey,
: Can I as root send a top output to a terminal (tty6 (Ctrl+Alt+F6))
: with out a user being logged in on that terminal?
Yes you can. man 1 open
: Maybe (big maybe), hook the ``space bar'' so top can
: be updated w/o a user being logged in on that terminal?
No need to do so. top is updated automatically every n seconds.
man top
: Being what it is (Linux and Open Source) it is truly doable, however
: it is easy (maybe moderately easy?), and if so, How is it done?
Put command
open -c 6 top
somewhere in the your startup screen. Be sure to comment out entry
for getty on this console in your inittab.
--
I don't think I'm gonna agree with that. Way too much visual confusion...
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Subject: Re: GPL
Date: Sat, 17 Mar 2001 01:49:58 GMT
Micah Cowan writes:
> Have you /read/ the GPL?
Many times. Non-GPL != proprietary. Here is a hint: GPL'd programs are
regularly linked to the X libraries.
> The following is at the end of it:
> This General Public License does not permit...
> ...
> ...
Preceeded on the previous page by 'END OF TERMS AND CONDITIONS'. The text
you quote is part of a document titled 'How to Apply These Terms to Your
New Programs'. It is not part of the license.
--
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin
------------------------------
From: "Joseph A. Knapka" <[EMAIL PROTECTED]>
Subject: Re: Dynamic function availability in Linux
Date: Sat, 17 Mar 2001 03:07:32 GMT
[EMAIL PROTECTED] wrote:
>
> Hi!
>
> I post this message because of a recommendation in comp.lang.c (thanks!)
>
> I'm developing some kind of server program under Linux. I would have some compiled
>modules for that server, all them with the same function calls. The problem is that
>when I compile main server, I don't know how many modules I will have, their names
>(only the function names)...
>
> Is there any mechanism I can use to call these functions one after another from
>different modules? I need at least some indication of where to learn from (that's no
>problem), or some program you know that does something like this and I can read its
>source code.
I'm not sure I understand exactly what you want to do, but it sounds
like you might want to look at "man dlopen" and its friends, and
then read the GCC info pages, paying particular attention to
the "-fPIC", "-export-dynamic", and "-shared" command-line options. You
can build an executable that dynamically loads a library (or several)
containing functions that conform to a specified prototype, look up
the functions you want to call, and call them via function pointers.
Is that what you're looking for?
-- Joe
> Thanks in advance,
> Dani
>
> ==================================
> Posted via http://nodevice.com
> Linux Programmer's Site
-- Joe Knapka
"It was just a maddened crocodile hidden in a flower bed. It could
have happened to anyone." -- Pratchett
// Linux MM Documentation in progress:
// http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
* Evolution is an "unproven theory" in the same sense that gravity is. *
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Ctrl C catcher
Reply-To: [EMAIL PROTECTED]
Date: Sat, 17 Mar 2001 07:46:21 GMT
On Fri, 16 Mar 2001 09:49:14 GMT, Ludwig <[EMAIL PROTECTED]> wrote:
>I'm porting a program from WIN32 to linux and came across the function
>'SetConsoleCtrlHandler'. This function 'catches' to Ctrl C button and
>instead of breaking the program, it gets rerouted to a function. (--> very
>handy if you are doing tests and want to finish the current test before
>exiting)
>
>My question now is: how can you catch the Ctrl C being pressed, so that it
>gets rerouted to a function instead of ending the program?
Ther is an ANSI C method for doing this; namely set up a signal handler
for the SIGINT signal. It's not guaranteed that the SIGINT signal is
generated in response to the interrupt key, but it does work on UNIX
platforms as well as MS Visual C++. For utmost portability, have your
signal handler store a value to a static object of type volatile
sig_atomic_t. Your mainline can inspect the value of that object from
time to time to discover whether the interrupt key has been pressed.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: sizeof returns wrong structure size
Date: Sat, 17 Mar 2001 08:29:59 -0000
On Sat, 17 Mar 2001 01:41:30 GMT Grant Edwards <[EMAIL PROTECTED]> wrote:
| I've spent 90% of my time dealing with frame formats that don't
| have any variable fields and would be quite happy if C structs
| could be used for that. Variable size fields is a whole
| different problem.
While you don't need that, this is one of the reasons why it would
be very complex to go the distance to make a programming language
deal with external stuff in a declarative way. OTOH, it is trivial
to do this procedurally.
|>[...] Where do you draw the line and say this can be
|>implemented in the compiler with structs and that cannot?
|
| I don't think that static frame structures would require much
| effort. I'd even give up the byte-ordering without much
| complaint. It would just nice to just get the bytes in the
| right place without so much fuss.
Well, expect to give up byte ordering. It has never been there in
standard C and I can't see it ever happening. As for static frame
structures, don't count on it. You're lucky that your's are not
that complex. But once developers start down that road, they would
be expected to make it work for ever external format, and there are
many, many reasons this becomes an insurmountable task, both for
the design of the language specification, as well as for compiler
and runtime package implementation.
BTW, memcpy is not what you'd have to do to build up the frame
structure. If you are going to store a 4 byte number in little
endian format, then conceptually your task can be defined as such.
Some machines can't even do that if the offset isn't correctly
aligned for the machine. Others can. But this could be done by
defining a macro perhaps called store_long_unaligned_le(). That
macro would literally store the whole thing in the platforms in
which that is possible, and break it apart byte by byte on those
where it is not. This it is just a matter of defining that macro
for each platform. It would be the code the compiler would have
to generate anyway. A full set of those macros for all different
ways to store data implemented on all platforms (little endian vs
big endian, aligned vs unaligned) could be done. Would it be
easy? Perhaps not. But it wouldn't be any less work for the
compiler makers to have to do this. They just don't have an
interest in it primarily because people do handle this kind of
thing generally very easily with code.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
Subject: Re: Re: Dynamic function availability in Linux
From: [EMAIL PROTECTED]
Date: Sat, 17 Mar 2001 09:56:08 GMT
Joe Knapka wrote:
> I'm not sure I understand exactly what you want to do, but it sounds
> like you might want to look at "man dlopen" and its friends, and
> ...
> You
> can build an executable that dynamically loads a library (or several)
> containing functions that conform to a specified prototype, look up
> the functions you want to call, and call them via function pointers.
> Is that what you're looking for?
Yes, that was! :) I read man page and it looks exactly what I wanted. Thanks a lot,
sincerely. Now I'll play a little with it and let's see...
Dani.-
==================================
Posted via http://nodevice.com
Linux Programmer's Site
------------------------------
From: "Emilien Arino" <[EMAIL PROTECTED]>
Subject: Re: Retrieving a web page
Date: Sun, 18 Mar 2001 04:08:39 +0100
> did you try hitting it from a browser at the same time, to see if it is
just
> a server error or if it is your program?
>
> it could be just that the server / page etc is having some maitainance
done
> on it - the seti people had some probs a while back with their fibre lines
> being cut - maybe they are just updating stuff!
Yes, the page works with other browsers.
And my program works on every page I tried ( with size ~< 50ko) exept this
particular one. And this is the page I want to retrieve :(
------------------------------
From: "Tristan Wibberley" <[EMAIL PROTECTED]>
Subject: Re: GPL
Date: Sat, 17 Mar 2001 15:07:26 -0000
"wiehllen" <[EMAIL PROTECTED]> wrote in message
news:98sir0$[EMAIL PROTECTED]...
> Hi,
>
> I have a general question. Normally, I have to open the source code of an
> application, if I use GPL-libraries. What can I do to avoid this, for
> example I want to write a commercial application in a company which is
> interessted in Linux, but doesnīt want to lose their research and
> development investments. The application should run on an embedded system
to
> handle i/o data. I heard that big companies use Linux as an embedded OS
for
> example in a videorecorder. I canīt believe the apps handling these
machines
> are open source. So what are my choices?
CONSULT WITH A LAWYER, I AM NOT A LAWYER (this is for my own legal
protection, I don't mean to shout).
Consult with a copyright lawyer (NOT a CONTRACT lawyer). The GNU GPL covers
copying of material only. If GPL art (eg libraries) are copied according to
the requirements laid out in the GNU GPL, you do not have to place *your*
source code under the GPL. I am not a lawyer, and you should consult with
one who is familiar with copyright law in your country. Normally, if you
distribute separate works on the same physical media as a GPL one, the GPL
is not applied to the others.
Dynamic linking to libraries involves testing that named libraries on the
build system provide certain symbols, and recording the names in the
filesystem that must provide those symbols when the program is executed. It
does not necessarily mean producing a derived work (and the GNU GPL only
covers derived works or the work itself).
If you are not convinced, produce a shared object file with the same symbols
as the GPL library, and wrap all macros and constant definitions in it's
header files with function calls (which you release under GPL (this may or
may not be required but it's safe)); check to see what parts of the original
libraries are included in your files - if none, then you are not copying any
GPLed work into your work, and are not bound by the GPL. Then you can
dynamically link with the shared object files, and distribute non-derived
works of your own creation under any terms you wish, and distribute the
original and derived works under the GNU GPL as required. You may not even
have to wrap the header file definitions - inclusion of small macros and
defined constants may be fair use in your country.
Remember to consult with a copyright lawyer!!! (USENET advise isn't worth
the paper it's not printed on, and I am not a lawyer). ie, consult a lawyer,
and take usenet with a pinch of salt. Who you gonna call? That's right... A
lawyer. There's a theme here, though I can't quite put my finger on it -
maybe if I asked a lawyer.
That's my tuppence.
--
Tristan Wibberley
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: sizeof returns wrong structure size
Date: Sat, 17 Mar 2001 16:16:04 GMT
On Fri, 16 Mar 2001 17:53:00 -0800, Erik Max Francis <[EMAIL PROTECTED]> wrote:
>Grant Edwards wrote:
>
>> There's no technical reason that structs can't be implimented
>> such that the user can control padding (or even byte order).
>
>Not if you want bus errors on some architectures.
If you're doing low level programming that requires you to know
about byte alignment and structure layout then you're
reponsible for make sure you don't have bus faults. I'm not
talking about joe-user applications programming, I'm talking
about system code.
>There's a reason why the Standards don't specify endianness and allow
>arbitrary struct padding. It's because it's necessary.
In your opinion. It's just as "necessary" to not create
pointers to non-legal addresses, to not index off the end or
beginning of arrays, to not coerce data to the wrong types. C
allows all of those in the name of flexibility for low-level
programming.
If you want a safe language, use Modula-3, Python, or (gack!
Perl). If I'm using C it's because I need to do dangerous,
low-level stuff. Pretending C is a safe language is idiotic.
--
Grant Edwards grante Yow! BEEP-BEEP!! I'm a
at '49 STUDEBAKER!!
visi.com
------------------------------
From: [EMAIL PROTECTED] (Dave Blake)
Subject: Re: GPL
Date: 17 Mar 2001 17:37:37 GMT
Reply-To: [EMAIL PROTECTED]
Micah Cowan <[EMAIL PROTECTED]> wrote:
> Make sure the libraries you are referring to truly are GPL
> libraries. You are not allowed to link non-GPL code with GPL
> code, even dynamically, but LGPL-ed code allows you to
> dynamically link with it. Most libraries tend to be LGPL'd,
> though there are several that aren't (although the FSF created
> both licenses, they strongly disparage the use of the LGPL in
> general). Glibc, for example, is LGPL'd, so you are perfectly
> fine linking proprietary code to it - thus the videorecorder,
> and TiVo examples. Just because they /use/ Linux doesn't mean
> that they link with it, or with GPL'd libraries.
IF this were true, there could be NO program that runs under
linux that is anything but GPLd, since all programs interact
with (read link to) the kernel image. Now, the kernel
programmers have made it clear that they will allow any license
programs to use system calls under the kernel. Besides, most of
the kernel API is defined in the POSIX spec.
The claim is often made that programs using GPLd libraries need
to be GPLd if they are distributed. I do not believe this is
defensible in court, for a few reasons.
Reason 1. The only way in which a program using a GPLd library
linked dynamically is derivative is that it includes a header
file at compile time. A header file defines an API for a
library. It is MEANT to be included by others in their work.
This makes its inclusion fair use.
Reason 2. The FSF GNU GPL contains the following statement
"If identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and
separate works in themselves, then this License, and its terms,
do not apply to those sections when you distribute them as
separate works."
To me, reason 2 means that if you make a dynamically linked
program, and distribute the GPL library separately, then the
GNU GPL does not apply to your program.
It can really boil down to whether using an API defined in a
header file is fair use or not. Or is that the "use of someone
else's copyright". In a reasonably fair world, I do not see how
that could be. For example, consider linking against ncurses.
The API was defined in curses and largely ported as it to
ncurses. Does that make ncurses a derived work ? Or a reverse
engineered work ?? That is an important distinction, because it
makes relevant whether a library's API is a more "public" part
of the code than the rest in that its inclusion is fair use.
The same argument can be made about the kernel API, which is
largely defined in the POSIX spec. Even the opensound API is
defined across Unices. Simple use of an API is not a copyright
derived work.
--
Dave Blake
[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 by posting to the
comp.os.linux.development.apps newsgroup.
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-Apps Digest
******************************
