Linux-Development-Sys Digest #228, Volume #6 Wed, 6 Jan 99 23:14:47 EST
Contents:
Re: readdir_r (Frank Sweetser)
Re: silly question (Taso Hatzi)
Can't reboot at root from "xdm" ("Jon D. Slater")
Re: Timing events via parallel port?... (Richard Jones)
reboot problem with adaptec 2940uw (aic7881rev1) (Johan Kullstam)
Re: Redefining time_t (Anselm Lingnau)
Re: Registry for Linux - Bad idea (Christopher Browne)
Re: Why I'm dumping Linux, going back to Windblows (Chris Hanson)
linux in embedded system ("ggyy")
Re: disheartened gnome developer ([EMAIL PROTECTED])
Re: a farly Simple Idea to make Linux look nicer. (Mark Tranchant)
Re: Registry for Linux - Bad idea (Frank Sweetser)
Re: Unresolved symbols in ufs.o (David Ronis)
Re: disheartened gnome developer (jedi)
----------------------------------------------------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: readdir_r
Date: 06 Jan 1999 19:38:35 -0500
"David" <[EMAIL PROTECTED]> writes:
F> Does anyone know where to find documentation for readdir_r() on linux. It
> does appear in dirent.h. Im compiling a piece of code from solaris to Red
> Hat 5.1. The problem is that readdir_r() does not seem to return the same
> values as it does on solaris. This seems odd to me since readdir_r() is
> supposed to be part of the POSIX standard (I thought), and solaris 2.5 and
> Linux conform to it for the most part. Could the linux readdir_r() function
> be conforming to an earlier standard? Any documentation would really help.
i found this in the libc section of the info pages. hope it helps!
- Function: int readdir_r (DIR *DIRSTREAM, struct dirent *ENTRY,
struct dirent **RESULT)
This function is the reentrant version of `readdir'. Like
`readdir' it returns the next entry from the directory. But to
prevent conflicts for simultaneously running threads the result is
not stored in some internal memory. Instead the argument ENTRY
has to point to a place where the result is stored.
The return value is `0' in case the next entry was read
successfully. In this case a pointer to the result is returned in
*RESULT. It is not required that *RESULT is the same as ENTRY.
If something goes wrong while executing `readdir_r' the function
returns `-1'. The `errno' variable is set like described for
`readdir'.
If there are no more directory entries, `readdir_r''s return value
is `0', and *RESULT is set to `NULL'.
*Portability Note:* On some systems, `readdir_r' may not return a
terminated string as the file name even if no `d_reclen' element
is available in `struct dirent' and the file name as the maximal
allowed size. Modern systems all have the `d_reclen' field and on
old systems multi threading is not critical. In any case, there
is no such problem with the `readdir' function so that even on
systems without `d_reclen' field one could use multiple threads by
using external locking.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
I was about to say, "Avoid fame like the plague," but you know, they can
cure the plague with penicillin these days.
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: Taso Hatzi <[EMAIL PROTECTED]>
Subject: Re: silly question
Date: Thu, 07 Jan 1999 12:32:17 +1100
Peter Pointner wrote:
>
> I can't remember all the options, but are you sure "cp -a" doesn't do
> what you want?
>
Now that's a genuine reason why you need the real thing :-)
------------------------------
From: "Jon D. Slater" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup,comp.os.linux.x
Subject: Can't reboot at root from "xdm"
Date: Thu, 07 Jan 1999 00:24:31 +0000
Once I log in as root using an XDM login, I've noticed if I type
"reboot" or "reboot &" in an xterm my machine does not reboot until I
press <Alt><Ctrl><F1>, switch to a "text based" screen.
Then the machine (running Redhat 5.2) reboots normally.
Why can't I reboot my machine from within an XDM login session?
Or maybe my question sould be "How do I reboot from an xterm run under
an XDM login?"
Please send suggestions to: JSlater<at>Qualcomm<dot>Com
Thanks in advance!!
Jon
------------------------------
From: Richard Jones <[EMAIL PROTECTED]>
Subject: Re: Timing events via parallel port?...
Date: Wed, 6 Jan 1999 12:01:19 +0000
Maxwell Lock <[EMAIL PROTECTED]> wrote:
: Hi Folks,
: I'm thinking about developing some code to time slot car
: races. I want to write this in Ansi C and maybe use some
: embedded assembler. I need to be able to time the length and
: interval of a pulse on any given parallel port data line to
: a fairly good degree of accuracy. As Linux is not a real
: time OS and RTLinux is a little overkill I think
: (comments?), I'd like to be able to use interrupts or some
: such. Has anyone done this before, or know of any source
: code I could use as a guide? I am a novice coder, so any
: examples would be gratefully accepted! :)
Have a look at linux/drivers/char/lp.c. If you wire up the
parallel port to generate an interrupt when the pulse
starts[1], then you can measure the length of the pulse by
busy waiting in the interrupt handler. For superaccurate
timings, use the Pentium TSC[2]. This will hurt system
performance, but presumably you're not worried about that
too much. You need to write a bit of kernel code, but you
can probably plug that in as a module using the parport
interface defined in linux/include/linux/parport.h (struct
parport_operations).
Other questions you need to ask yourself are: how many
pulses, how often, how long and could they overlap
with each other? If your pulses are long (> 1/20 sec,
say) and could overlap with each other, then it's probably
better to use a timer which kicks in every tick and
reads the whole parallel port. You can reconstruct the
start and end of pulses from this, albeit with a much
lower granularity (only to nearest 1/HZ seconds).
Rich.
[1] OR the pulse lines together and put that into
STROBE (maybe with an inverter?)
[2] Use (on a Pentium or higher):
__u64 d;
__asm__ __volatile__ ("rdtsc" : "=&A" (d));
--
- Richard Jones. Linux contractor London and SE areas. -
- Very boring homepage at: http://www.annexia.demon.co.uk/ -
- You are currently the 1,991,243,100th visitor to this signature. -
- Original message content Copyright (C) 1998 Richard Jones. -
------------------------------
Subject: reboot problem with adaptec 2940uw (aic7881rev1)
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 06 Jan 1999 20:48:17 -0500
i've got a problem with rebooting a computer with adaptec 2940uw
(aic7881rev1).
the first time i boot up, everything goes well. the scsi card finds
my harddrive at id 0 lun 0. the kernel boots. happy happy joy joy.
the fun ends when i go to reboot. i type shutdown -r now but now the
adaptec card prints a line about being itself and hangs. it does not
go on to print stuff about configuration by typing Cntl-A. it does
not find any disks at id 0 and lun 0.
hitting the reset button does not help. the machine hangs at the same
place. i must power-down and then re-power-up. what is going on here?
--
Johan Kullstam [[EMAIL PROTECTED]] Don't Fear the Penguin!
------------------------------
From: Anselm Lingnau <[EMAIL PROTECTED]>
Subject: Re: Redefining time_t
Date: 5 Jan 1999 16:08:10 +0100
In article <76ubli$33o$[EMAIL PROTECTED]>,
H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Not necessarily 32 bits.
As a matter of fact, time_t isn't even guaranteed signed (by POSIX.1).
(time_t)-1 is used to announce errors, but that could actually turn out
to be a positive number.
Anselm
--
Anselm Lingnau ......................... [EMAIL PROTECTED]
If you import antimatter into the United States, does the Customs Service
pay you? -- Jordin Kare
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 7 Jan 1999 01:05:33 GMT
Reply-To: [EMAIL PROTECTED]
On 05 Jan 1999 19:59:16 -0500, Frank Sweetser <[EMAIL PROTECTED]> wrote:
>Tristan Wibberley <[EMAIL PROTECTED]> writes:
>> 2) then a couple of libraries for parsing flat text will be most
>> appropriate no? Simplest to implement.
>
>agreed. this would be the first logical module to implement. i actually
>have two of them in front of me now (profile code from the kerberos package
>courtesy ted t'so, and libconfig from sunsite), one of which will probably
>end up getting stuffed into the flat text module.
Indeed.
Note that there will likely be two pieces:
a) Read the config, and
b) Write the config.
The UNIX "approach" has been for these to be distinctly separated.
Which is, for things that are commonly referenced, but seldom changed, a
Good Thing.
The "Windows Registry" approach is to have a unified database that puts
a common "API" onto both aspects. This is nice for those things that
get fiddled with all the time, but definitely makes *everything* in the
registry as vulnerable as the weakest link in/to the Registry.
>> The talk of complex network databases is far too premature at the moment
>> - everyones always in such a rush to "innovate".
>
>you certainly have a point - there always seems to be a few people looking
>to implement the latest, sexiest theoretical paradigms, the type who want
>change for change's sake. however, sometimes change can be a good thing.
>i think that the opStore project has the potential to definatelly be a good
>thing.
Everyone seems to want to come up with a "sexy" system that will
represent the "be-all and end-all."
"I'll come up with the perfect configuration system, and it will make
me famous!"
Unfortunately, actually implementing such a universal thing requires
that a *lot* of programs be modified. Which requires more effort than
anyone is likely to be willing to employ. It's *not* as simple as
coming up with the "perfect config system."
If, in contrast, a scheme is set up that is *useful enough* and
*convenient enough* that it convinces *SOME* developers to adopt it,
thereby reducing the number of completely independent configuration
systems, that's GOOD ENOUGH.
We don't need a "Unified Field Theory" of configuration systems; we need
something that's Good Enough, and perhaps that's somewhat better than we
have now.
>> I have to admit that the overriding values for local machines will be
>> awkward to implement using the network fs scheme, but I hope to figure
>> out a way of doing it that's quite easy to configure on the backend, and
>> transparent on the client. Maybe write some scripts to help.
>
>simply check the values in /etc/foo.defs, ~/.foocfg, then in /etc/foo.cfg,
>and have the last assigned value take precedence.
Make sure it is documented clearly how this is to work, so that it is
*CLEAR* which files will be evaluated in what order. The problem with
(in contrast) X resource information is that the order of evaluation is
*not* clear.
I would suggest documenting something on the order of five sets of
places for defaults to come from, for application foo:
1) Site config: /etc/site/foo.conf (/etc/site might be NFS mounted
from a central server; feel free to suggest a better location to stick
this...)
2) Host-based config: /etc/foo.conf
3) $HOME/.foo.rc
4) $HOME/etc/foo.conf
5) $HOME/GNUStep/Library/Defaults/foo/Defaults
... Note that I'm not sure what the precise ordering of these five
*ought* to be; it might be something that ought to be configurable as an
option in /etc/foo.conf ...
--
The real problem with the the year 2000 is that there are too many zero
bits and that adversely affects the global bit density. -- Boyd Roberts
<[EMAIL PROTECTED]>
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Chris Hanson)
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: 06 Jan 1999 21:38:34 -0500
In article <76n3ri$pc$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>> I would not expect what I'm trying to learn to not go out of its way
>> to be hard, too.
>>
>> The central idea that Apple and Xerox have contributed to
>> human-computer interaction is *consistency*. Editing text files to
>> change your configuration is not in itself consistent. Using the same
>> format in all of those text files is. Unfortunately, no Unix I know
This is why, you will never become a pilot, or a doctor, or a chemist, or a
mathematician, or an engineer, or an architecht, or a programer.
I wrote the quoted part that you're responding to, not the original
poster.
I'm also - surprise, surprise -- a software engineer. I write
applications and other software in C & C++ for a living. I know what
I'm doing on Unix, Windows, and MacOS. I prefer the Macintosh both as
a user and developer platform, however, because of its interface
consistency (and consequent ease of use), and because other Macintosh
developers are of a like philosophy.
Frankly, I'm insulted that you equate "able to deal with complexity"
and "wants to deal with complexity all the time in everything." Just
because what I do for a living is complicated doesn't mean I want to
go out of my way to make it moreso. (That's why I use CodeWarrior and
not MPW for development. Its project manager frees me from having to
write and maintain makefiles, track dependencies, use a separate
source code control system, etc., and gives me all sorts of extra
features -- like a class browser -- to boot. Sure, I could learn all
sorts of tools, and keep track of some stuff in my head, but I'm more
productive with my toolset.)
What frustrates me is that Linux *doesn't* have to be hard to use or
administer. Look at what NeXT did with NEXTSTEP and OpenStep, look at
what Apple did with A/UX and what they're doing with MacOS X Server,
look at Irix, look at BeOS (which while it isn't Unix is still
extremely Unix-like). All of them are relatively easy to use and
administer, because they take the idea of consistency of interface and
the philosophy of ease of use to heart.
Fortunately, upon further exploration of the Linux world, there are at
least some developers who get it, and many of them are hard at work.
I'm looking forward to the day when firing up a terminal window on my
Linux box is as rare as it is on NEXTSTEP or BeOS. Hopefully it'll
come soon.
------------------------------
From: "ggyy" <[EMAIL PROTECTED]>
Subject: linux in embedded system
Date: Sat, 2 Jan 1999 22:35:49 +0800
Does anyone know that how to use Linux in embedded system? I means to burn
the linux kernel binaries into ROM and then load into RAM after booting. My
friend is working on Linux and FreeBSD for DVD player and would like to put
the kernel binaries into the ROM. Hope anyone outthere could help. Thank
you.
With Best Regards,
Cheng-Ta Wu,
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Wed, 06 Jan 1999 15:32:13 GMT
In article <76ugf0$pb5$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Tue, 05 Jan 1999 19:46:56 +0000, Walt <[EMAIL PROTECTED]>
> wrote:
> >> On 22 Nov 1998 23:03:23 GMT, Christopher B. Browne
<[EMAIL PROTECTED]>
> >> wrote:
> >> >In contrast, if you write code that uses Qt, you indeed *do* have to
> >> >negotiate licensing with Troll Tech or an assignee thereof depending on
your
> >> >circumstances.
> >>
> >> So they might have to read a license agreement before playing around with
> >> the software. Big deal. If they don't want to deal with licensing
> >> issues, then they can just ignore Qt-devel and live in bliss.
> >>
> >> >It all really begs the important question:
> >> >
> >> > Why do you think Red Hat software would consider it a good idea to
> >> > promote Troll Tech's programming tools?
> >> >
> >> >That really is the upshot of it all.
> >>
> >> Red Hat wouldn't be promoting Qt at all, certainly not any more than
> >> they promoted xv, Metro X, or Applixware.
>
> Note that none of [xv, Metro X, ApplixWare] represent, in their normal
> use, development tools. Qt does. Development tools, and the
> attribution of licensing thereon, is a fairly complex matter.
The runtime version of Qt (just the .so file) is not a development tool.
> >> >If someone installs Red Hat Linux, plays with Qt, and then decides that
they
> >> >like it, they're going to have to pay Troll Tech the >$1K in order to use
it
> >> >for anything commercial.
> >>
> >> Again, big deal. So, if they don't want to pay Troll Tech, they can
> >> just ignore Qt-devel.
> >>
> >> >Please explain how this is beneficial to Red Hat Software, when it is
pretty
> >> >clear that they want to be involved in selling development and systems
> >> >integration services.
> >>
> >> It is beneficial in that some customers want Qt.
> >
> >QT is doing an open source version for 2.0. Look at the Kde home page
> >http://www.kde.org
>
> Which may satisfy some desires, and not others.
Ditto about the GNOME license. That comment is so vague it is true for
anything :-)
>
> >Qt is by far superior to the gnome development libs.
>
> An arguable claim; see <http://www.computers.iwz.com/e-zine/gtk.html>
> for the claim that GTk is quite good.
>
> >Its WAY easier to write apps for.
>
> That doesn't parse particularly well. And is, at best, only true for a
> subset of situations, particularly those where the remainder of an
> applications is being written in C++. The last "library survey" I did
> indicated that there don't actually seem to be all that many widely used
> Linux applications written in C++.
>
> It is not evident that it is "way easier" to script up applications
> using Guile with Qt than it is to do so with GTk.
It is not harder at all.
The language for scripting a app is orthogonal to the language that
app is written in. For examples, look at ksiag, the KDE version of SIAG
that is written in C++ and scripted in python, tcp, guile (and perl?)
Perhaps you meant *writing* the app in Guile, but thats a whole different
thing (and its not really rocket science either).
And another way to parse the original comment is that for anyone coming out of
college in the last five years, or coming out in the near future, it is likely
to be easier to write a app on C++ and not in lisp or objective C.
Ditto for a very very large majority of professional programmers. Very few
major commercial projects are started these days in C.
--
Roberto Alsina (KDE developer, MFCH)
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mark Tranchant <[EMAIL PROTECTED]>
Subject: Re: a farly Simple Idea to make Linux look nicer.
Date: Wed, 06 Jan 1999 14:46:30 +0000
Reply-To: [EMAIL PROTECTED]
Josh Fishman wrote:
>
> Bernd Paysan wrote:
> >
> > The current boot logo penguin drinks a beer. I'm not sure if mommy will
> > give that to small children.
>
> Just explain that, in penguin years, Tux is over 21.
> And Tux isn't drinking and hacking device drivers, so it's okay.
>
> - Josh
>
> PS: Anyone know the real penguin<->human years ratio?
Penguins typically live 10-20 years in zoos, depending on species. I've
no idea what species Tux is meant to be, but the ratio will therefore be
somewhere between 3.5 and 9. Assuming Tux has existed in concept since
1991, that makes him comfortably over the minimum drinking age.
Mark.
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 06 Jan 1999 22:24:06 -0500
[EMAIL PROTECTED] (Christopher Browne) writes:
> On 05 Jan 1999 19:59:16 -0500, Frank Sweetser <[EMAIL PROTECTED]> wrote:
> >Tristan Wibberley <[EMAIL PROTECTED]> writes:
> >> 2) then a couple of libraries for parsing flat text will be most
> >> appropriate no? Simplest to implement.
> >
> >agreed. this would be the first logical module to implement. i actually
> >have two of them in front of me now (profile code from the kerberos package
> >courtesy ted t'so, and libconfig from sunsite), one of which will probably
> >end up getting stuffed into the flat text module.
>
> Indeed.
>
> Note that there will likely be two pieces:
> a) Read the config, and
> b) Write the config.
>
> The UNIX "approach" has been for these to be distinctly separated.
> Which is, for things that are commonly referenced, but seldom changed, a
> Good Thing.
>
> The "Windows Registry" approach is to have a unified database that puts
> a common "API" onto both aspects. This is nice for those things that
> get fiddled with all the time, but definitely makes *everything* in the
> registry as vulnerable as the weakest link in/to the Registry.
the best way to keep this seperation (which is a good thing) IMHO is by
keeping the config in core. any updates should just be made to the in core
copy. a seperate call can then be made to flush the config out (the entire
config for files, only diffs for DB, etc).
> >> The talk of complex network databases is far too premature at the moment
> >> - everyones always in such a rush to "innovate".
> >
> >you certainly have a point - there always seems to be a few people looking
> >to implement the latest, sexiest theoretical paradigms, the type who want
> >change for change's sake. however, sometimes change can be a good thing.
> >i think that the opStore project has the potential to definatelly be a good
> >thing.
>
> Everyone seems to want to come up with a "sexy" system that will
> represent the "be-all and end-all."
>
> "I'll come up with the perfect configuration system, and it will make
> me famous!"
>
> Unfortunately, actually implementing such a universal thing requires
> that a *lot* of programs be modified. Which requires more effort than
> anyone is likely to be willing to employ. It's *not* as simple as
> coming up with the "perfect config system."
i really don't see this library at being aimed at any *existing* programs.
what i do see it being used by is new programs, and possible signifigantly
new versions of existing programs.
> If, in contrast, a scheme is set up that is *useful enough* and
> *convenient enough* that it convinces *SOME* developers to adopt it,
> thereby reducing the number of completely independent configuration
> systems, that's GOOD ENOUGH.
>
> We don't need a "Unified Field Theory" of configuration systems; we need
> something that's Good Enough, and perhaps that's somewhat better than we
> have now.
exact;u/
> >> I have to admit that the overriding values for local machines will be
> >> awkward to implement using the network fs scheme, but I hope to figure
> >> out a way of doing it that's quite easy to configure on the backend, and
> >> transparent on the client. Maybe write some scripts to help.
> >
> >simply check the values in /etc/foo.defs, ~/.foocfg, then in /etc/foo.cfg,
> >and have the last assigned value take precedence.
>
> Make sure it is documented clearly how this is to work, so that it is
> *CLEAR* which files will be evaluated in what order. The problem with
> (in contrast) X resource information is that the order of evaluation is
> *not* clear.
agreed. it's going to be rather interesting to declare a definitave order
or precedence when the information can come from multiple sources, but i
suspect any developers would drop it like a hot potatoe otherwise. there's
already going to be a certain amount of metadata for each configuration
object, so perhaps the precedence could be specified therein.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
Some women hold up dresses that are so ugly and they always say the same
thing: 'This looks much better on.' On what? On fire? --Rita Rudner
------------------------------
From: David Ronis <[EMAIL PROTECTED]>
Subject: Re: Unresolved symbols in ufs.o
Date: 7 Jan 1999 03:44:16 GMT
Yes I did a fresh install of the 2.2 modules. Also depmod -e shows
/lib/modules/2.2.0-pre4/fs/ufs.o: unresolved symbol(s)
in_group_p
which is strange since in_group_p seems to be defined in kernel/sys.c.
------------------------------
From: [EMAIL PROTECTED] (jedi)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Wed, 6 Jan 1999 07:48:26 -0800
On Wed, 06 Jan 1999 15:32:13 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In article <76ugf0$pb5$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> On Tue, 05 Jan 1999 19:46:56 +0000, Walt <[EMAIL PROTECTED]>
>> wrote:
>> >> On 22 Nov 1998 23:03:23 GMT, Christopher B. Browne
><[EMAIL PROTECTED]>
>> >> wrote:
>> >> >In contrast, if you write code that uses Qt, you indeed *do* have to
>> >> >negotiate licensing with Troll Tech or an assignee thereof depending on
>your
>> >> >circumstances.
>> >>
>> >> So they might have to read a license agreement before playing around with
>> >> the software. Big deal. If they don't want to deal with licensing
>> >> issues, then they can just ignore Qt-devel and live in bliss.
>> >>
>> >> >It all really begs the important question:
>> >> >
>> >> > Why do you think Red Hat software would consider it a good idea to
>> >> > promote Troll Tech's programming tools?
>> >> >
>> >> >That really is the upshot of it all.
>> >>
>> >> Red Hat wouldn't be promoting Qt at all, certainly not any more than
>> >> they promoted xv, Metro X, or Applixware.
>>
>> Note that none of [xv, Metro X, ApplixWare] represent, in their normal
>> use, development tools. Qt does. Development tools, and the
>> attribution of licensing thereon, is a fairly complex matter.
>
>The runtime version of Qt (just the .so file) is not a development tool.
Back to spreading old lies again I see...
[deletia]
You know very well that a 'runtime version' would
not all be sufficient even for a user workstation.
--
Herding Humans ~ Herding Cats
Neither will do a thing unless they really want to, or |||
is coerced to the point where it will scratch your eyes out / | \
as soon as your grip slips.
In search of sane PPP docs? Try http://penguin.lvcm.com
------------------------------
** 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
******************************
