Linux-Development-Sys Digest #179, Volume #7 Fri, 10 Sep 99 06:14:16 EDT
Contents:
Re: IDE for c++ dev? (Kaz Kylheku)
Re: TAO: the ultimate OS (Tony)
Re: select() and write descriptors (Kaz Kylheku)
Re: TAO: the ultimate OS (void)
Re: More kind words from M$. (Warren Young)
Re: Finding reserved shared memory (Warren Young)
compiling audio apps ([EMAIL PROTECTED])
Re: Figure Out The MS Source Code Yourself (bilge)
Re: TAO: the ultimate OS (Bill Anderson)
Re: The conceptual sandbox? (Bill Anderson)
Re: TAO: the ultimate OS (Bill Anderson)
Re: TAO: the ultimate OS (Bill Anderson)
Re: TAO: the ultimate OS (Bill Anderson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: IDE for c++ dev?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 10 Sep 1999 04:59:59 GMT
On Thu, 09 Sep 1999 17:34:49 -0600, Warren Young <[EMAIL PROTECTED]> wrote:
>Johan Kullstam wrote:
>>
>> [EMAIL PROTECTED] () writes:
>>
>> > So
>> > be it, plenty of people have testified that they find emacs to be
>> > well worth the time it took to learn to use it. What puzzles and
>> > bothers me is why SO many emacs fans bristle and shout otherwise when
>> > ANYONE states the obvious, that emacs is EXTREMELY difficult to use.
>>
>> you seem to be describing vi and its users.
>
>Not at all. We vi users don't try to pretend that our editor is
>intuitive. We tell newbies that it's hard to learn, but that it'll be
>worth the effort of learning it. Emacs users tell newbies that their
>editor is easier to learn and use than vi -- hogwash.
Well, there is that class of Emacs zealots that only know how to use it as a
glorified pico. Like one joker I ran across who couldn't produce Perl code
that was indented correctly despite all the wonderful support for automated
indentation in Emacs which is arguably better than in anything else. He
couldn't get any work done until emacs was installed on the machine. Lasted two
weeks. I deleted the whole emacs distribution the day after he left.
You can spot the work of an emacs user: it usually has tons of blank lines
at the end. (aThe work of a vi user, iof course, can be spotted by its own
unique telltale signs.):w
------------------------------
From: [EMAIL PROTECTED] (Tony)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Fri, 10 Sep 1999 00:07:18 -0500
In article <7r1kf8$jb3$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> [Peter Samuelson <[EMAIL PROTECTED]>]
> > > You keep doing this. Someone raises an objection to something
> > > you've said and rather than explaining how to overcome the
> > > objection you just wave your hand and say "I believe this objection
> > > can be overcome." You seem to like rejecting "false dichotomies",
> > > making them false by fiat.
> [Vladimir Z. Nuri <[EMAIL PROTECTED]>]
> > my "opponents" are making them true by fiat. I am merely pointing out
> > unjustified assumptions & dogmas that permeate current OS & software
> > design. if you consider anything true that I am making "false by
> > fiat" I will look at the evidence and show you where you are wrong<g>
>
> No they are not unjustified. This is the difference between you and
> them. Your "opponents" keep bringing up valid reasons to doubt what
> you are asserting. At least the reasons look valid. At every turn,
> you could take the opportunity of demonstrating why the reasons are
> *not* in fact valid, or at least giving some evidence which casts doubt
> on the reasons. So far you have not done so. You have waved the
> reasons away with "Well, I think it's not necessarily true" or "Well,
> whoever thinks that just doesn't have enough imagination."
>
> By "fiat" I am not talking about merely asserting something. I am
> talking about rejecting someone else's position, a position for which
> he gives evidence, without any counter-evidence but merely with your
> own assertions. (And ad-hominem attacks, if "has no imagination" can
> be construed that way.)
>
> The instance I was commenting on was where I gave my reasons for why I
> don't believe a user interface can be one-size-fits-all. To sum it up,
> I said that to make a computer easily usable by computer-illiterates,
> it has to adopt the conceptual constraints of natural language:
> ambiguities, implications, vague abstractions in place of concrete
> abstractions, and other communication inefficiencies. These are
> unacceptible to people like me who would rather communicate more
> efficiently by learning to "think more like a computer". Your response
> did not refute my points, but injected a mere opinion:
>
> > > > I believe an OS that is equally pleasing to the novice as well as
> > > > the power programmer is inherently possible. I will continually
> > > > reject the false dichotomies suggesting otherwise.
>
> Since you don't seem to understand the difference between arguing using
> evidence and examples and arguing with bald opinions, I don't think I
> have anything more to argue about.
>
> > note above I did not declare anything "true by fiat". I proposed an
> > alternative to existing dogma & conventional wisdom.
>
> You may not be "declaring" things by fiat, but you continue to imply
> that your opinions (with only your will to back them up) are so
> self-evident that anyone who rejects them is small-minded or openly
> hostile. As I said, to me your entire argument style is fallacious and
> if that's all you know how to do I don't believe I have anything more
> to say.
>
> --
> Peter Samuelson
> <sampo.creighton.edu!psamuels>
>
This is a very popular agumentative thread in newsgroups, if you both
haven't noticed. I think it can be characterized, and correct me if I'm
wrong, as: "persons talking _past_ each other intentionally. Usually at
the heart of the scenario is someone with motive and someone else trying
to understand. Personalities and ways of thinking are at tbe root of the
debate, but one "side" (always the broader perspective?) is not giving
away the key information to the other. I find this frequently in
interactions between the hard-core technical set and the more intuitive
abstractionists.
The one seeking "definition" and "absolute" is forever perplexed by the
intuitionist's presentation of higher order to the focused specialist.
Ain't life grand? :)
Tony
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: select() and write descriptors
Reply-To: [EMAIL PROTECTED]
Date: Fri, 10 Sep 1999 05:18:15 GMT
On Fri, 10 Sep 1999 11:37:29 +0800, Bigwoof! <[EMAIL PROTECTED]> wrote:
>for eg. i have some programs that tunnel through a transport layer
>abstraction using select calls. if i check the write descriptors, end to
>end pings take 200-500 ms. if i remove the write descriptors, it takes
>1.4-1.8ms.
>
>I can't figure out why there is such a large delay.
If this is all within one machine, the CPU wasting alone could explain the
delays. Your process busy loops, and will chew its entire time quantum
even if there is nothing to receive. If it sent data to another process,
that other process won't get to run in until the current task is pre-empted.
In other words, if you had two processes talking to each other with each one
repeatedly doing a wait-free select(), you would expect to see a round-trip
time of betwen one and two time quanta, because the scheduler alternates
between the two, giving each one a full timeslice.
I'm looking at the 2.2.12 source; the time quantum duration appears to be 210
milliseconds (have a look at your include/linux/sched.h.) Plugging this time
quantum into my analysis produces a result that is roughly in line with what
you are observing.
------------------------------
From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 10 Sep 1999 06:18:59 GMT
On Fri, 10 Sep 1999 00:07:18 -0500, Tony <[EMAIL PROTECTED]> wrote:
>
>The one seeking "definition" and "absolute" is forever perplexed by the
>intuitionist's presentation of higher order to the focused specialist.
And the compiler is forever perplexed by English.
>Ain't life grand? :)
Yeah.
--
Ben
[X] YES! I'm a brain-damaged lemur on crack, and I'd like to
order your software package for $459.95!
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: More kind words from M$.
Date: Thu, 09 Sep 1999 17:03:35 -0600
Dave Newton wrote:
>
> Phil Howard wrote:
> > The notation scheme results in "sz" used for many names (null
> > terminated strings). The Hungarian language itself has many words
> > and names with "sz". I would bet this had an influence, as it would
> > have made the variable names kinda look like some form of Hungarian
> > prose to someone who did not know Hungarian, but noted all the "sz"
> > strings around.
>
> Perhaps, but I'll stick with the "It's a _s_tring, and it's an
> ASCII_Z_ string."
More on my version of this below.
> There are probably a few words that begin with
> 'n' too, but I doubt people will argue that that's why i_n_tegers
> are prefixed with it.
'n' is for "numbers". This is not to be confused with "f" for floating
point. Microsoft uses "f" to mean "flag", but I use "b" for Boolean in
that case. Microsoft uses "b" to mean byte (either raw or as a
modifier: "cb" for count of bytes), but I prefer to use "c" as in "char"
if I'm talking about an ASCII character or "n" if I'm using it as an
8-bit integer.
That brings me to another of my quibbles with Hungarian Notation as
propounded by Microsoft: they encode the size of their numeric types in
the prefix. This is evil, because that's probably the
most-often-changed type aspect in C/C++, and yet it usually never
affects the program's functioning because you usually make the number
bigger. There are several places in the Windows API that are broken or
were forced to be reworked or extended because of poor Hungarian.
About the only time the size of the number matters is in low-level
system programming, where the meaning of particular types of bit
twiddling can change depending on the size of the integer.
And now back to the "sz" thing: I prefer "pc" -- pointer to char. I
never use Pascal-style strings, so "sz" is redundant to me. And, I
prefer to use "s" for C++ style string objects.
This is an example of where Hungarian is really useful: it's common for
me to change something from being an array of characters ("ac") or a
pointer to char ("pc") to a C++ string ("s"). Each of these has a
distinct prefix because they each work differently. Thus, different
extensions are justified.
You might think that "ac" and "pc" are redundant, but there are
significant differences: "pc" usually refers to an object that exists on
the heap and must be destroyed manually, whereas "ac" is either in
static or automatic storage, so the compiler cleans it up. "ac" also
implies that you can find the number of characters being pointed to with
sizeof(), but "pc" doesn't allow this, so you have to pass around a
length parameter with it.
Other prefixes I use are "g" for global variables, "k" for constants
(but _not_ variables that are passed as const!), "e" for enumerated
types (like "n", but implies that you shouldn't assign bare integer
values to it) and "h" for handles (also like "n", but implies that the
exact value of the number should be treated as meaningless).
I think Microsoft's g_, m_ and s_ prefixes have some value, but I have
my own equivalents I like better. I've mentioned the bare "g" prefix.
For member variables, I prefer a trailing underscore. I don't yet have
a "static" prefix, because it's usually either a member variable also,
or also global. The only case I haven't got covered is a static
variable declared in a function, but I keep my functions small, so
there's little need to call attention to the fact that it doesn't go
away when the function returns.
For non-primitive types, I use suffixes. Thus, "vector<int>*
pTitleList;" It seems like this poses a contradiction but I don't find
it hard to keep straight at all. I guess it's because I see a clear
delineation in C/C++ between primitive types and structs or classes.
Yes, I consider C++'s string class a primitive but not vectors. I think
it's because strings you almost always manipulate via the language's
operators, whereas you usually call member functions on vectors to
manipulate them. I know string has member functions and vector has
operators overloaded for it, but I'm talking about the usual use case.
A secondary consideration is that I use string a lot more than vectors,
so they're "more fundamental" to my programs. It's also true that most
STL containers are interchangeable, so changing the object's type often
doesn't change how you use it.
The biggest problem with Hungarian is that most people look at
Microsoft's style, barf, and then condemn the whole idea. All that's
needed is to change the prefixes to a set _you_ like, just like you use
your own indenting and curly brace style.
--
= Warren Young: www.cyberport.com/~tangent | Yesterday it worked.
= ICBM Address: 36.8274040N, 108.0204086W, | Today it is not working.
= alt. 1714m | Windows is like that.
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: Finding reserved shared memory
Date: Fri, 10 Sep 1999 00:46:16 -0600
Norm Dresner wrote:
>
> I thought of using /proc/meminfo but I'm getting confusing results as
> follows:
>
> mem=XXXm MemTotal
> 124 123776
> 123 122764
> 122 121756
>
> The difference between the MemTotal for 124 and 123 is 1012 Kb and between
> 123 and 122 it's only 1008 Kb. Neither of which is the 1024 kB that I'd
> expect.
I suspect that the MemTotal is the amount of memory available for system
buffers and user memory -- that is, what's not taken by the kernel
itself. /proc/mtrr (on default-configured Pentium Pros and higher) will
tell you how much real memory is in the machine, in megabytes.
So, you can add MemTotal to, say, a 3MB fudge factor and subtract that
from the MTRR value to find a "safe" are of memory that should be beyond
kernel space. Now you know the memory area's start and its extent.
Communicate this with the real-time bits in kernel space, and now you
can begin communicating.
Another option would be for the real time extensions to extract the end
of kernel memory (they should be able to get at it, since they run in
kernel mode, right?) from the kernel's global variables and then tell
the user-land parts of your program this via, say, a /proc entry that it
creats.
Good luck,
--
= Warren Young: www.cyberport.com/~tangent | Yesterday it worked.
= ICBM Address: 36.8274040N, 108.0204086W, | Today it is not working.
= alt. 1714m | Windows is like that.
------------------------------
From: [EMAIL PROTECTED]
Subject: compiling audio apps
Date: Fri, 10 Sep 1999 00:07:17 -0700
Hello,
I have a redhat 6.0 system and have applied many updates to it via rpm
over the months. I can no longer compile audio applications. Here is the
message:
c++ -I. -I. -I./config -DUNIX_LIBDIR=\"/usr/local/lib\" -Dlinux
-Ibase/include -Iconfig -Iio/include -Iui/include -Ilmc/include
-Ibase/unix/include -Ibase/unix/linux/include -Iui/freeamp/unix/include
-Iui/freeamp/unix/res -Iio/esound/include -Iio/alsa/unix/linux/include
-Iio/soundcard/unix/linux/include -Iui/lcd/include -Iui/irman/include
-Ilmc/xingmp3/include -Wall -g -O2 -I/usr/X11R6/include -D_REENTRANT
-fpic -fpic -c io/esound/src/esoundpmo.cpp -o io/esound/src/esoundpmo.o
In file included from /usr/include/esd.h:3,
from io/esound/src/esoundpmo.cpp:31:
/usr/include/audiofile.h:603: parse error before `}'
make[1]: *** [io/esound/src/esoundpmo.o] Error 1
make[1]: Leaving directory `/home/jmcbride/UPDATES/freeamp-1.3.1'
make: *** [plugins-cc] Error 2
I have tried forcibly reinstalling the asoundfile--devel and
esound-devel packages, to no avail. I am thinking something is wrong on
the c++ side, since it involves unbalanced brackets at the end of a file
having the c/c++ name mangling ifdef's?
Any tips or hints are appreciated.
TIA,
John
------------------------------
From: [EMAIL PROTECTED] (bilge)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Figure Out The MS Source Code Yourself
Date: 10 Sep 1999 07:04:56 GMT
Reply-To: [EMAIL PROTECTED]
Fred Jackson [EMAIL PROTECTED] blared:
>I hear you, but IMHO any prohibition on reverse engineering is horse
>manure. Reverse engineering is a natural right. All reverse
>engineering means is "figuring out how things work". You might as
>well tell me to turn off my brain and watch network TV as try to
>tell me I can't reverse engineer anything I feel like.
>
>I'd rather "forward engineer", though :-) It's usually more satisfying.
>
You havent read the digital millennium copyright act. It provides
for criminal penalties if you even interfere with the normal
functioning of the software as determined by the copyright holder.
Then things take a turn for the worse...
One could construe that applying a patch which is unapproved
by the vendor as a violation of the copyright, subject to
criminal penalties, for example. Read it, if you have not.
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Fri, 03 Sep 1999 13:03:33 -0600
"Vladimir Z. Nuri" wrote:
>
> In comp.os.misc Peter Samuelson <[EMAIL PROTECTED]> wrote:
>
> : Whom are you accusing of lack of imagination or engineering ingenuity?
>
> ahem. I regret you are misconstruing my post.
> the point is that all software, viewed in retrospect, looks
> like it lacks imagination & ingenuity. the more dated it
> is, the more so this is true.
Wrong. You are basically saying that code automatically lacking in
imagination and ingenuity by sheer virtue of age.
Perhaps you should try learning and looking at code. I see code that is
years old, and much of it is still ingenious and imaginative.
>
> this is not to insinuate,
> of course, the people who worked on it are nitwits. it is to suggest
> that there is a moving goalpost in the realm of software
> engineering.
yeah, whatever.
>
> : Not to imply that he's some sort of inerrant god, but in a Linux
> : newsgroup Ted T'so brings a lot of credentials to the table. He has
> : designed and built a lot of the stuff in Linux you use every day -- not
> : by dreaming, not by "spreading the memes", but by actually working.
>
> <looking at floor> aw, shucks, I respect that immensely.
>
> : When he says it's been done, that it involves tradeoffs and that you
> : can't just hand-wave those away, I think I'll take his word for it over
> : yours. Have you actually tried implementing a sandbox architecture?
> : How did *you* use your superior imagination and engineering ingenuity
> : to overcome the problems he outlines?
>
> ahem. I do think a far better sandbox architecture is possible when
> one starts with that as the objective rather than other goals
> such as performance optimization, which I propose to you is the
> typical goal of most OS design. it seems to me mr. T'so himself
> would agree that new architectures with new improvements are possible
> & perhaps even inevitable.
The mere fact that the world of computeds evolves and changes doe not
validate your claim.
>
> : He didn't say "impossible", he said there are tradeoffs. Security
> : versus ability to do anything useful. If you don't want your system to
> : do anything useful, you can secure it real tight.
>
> my simple assertion is that:
> 1. a virus proof system is possible
Consult Godel, learn about the incompleteness theorum, and realize the
intrue nature of the assertion.
> 2. using a better concept of sandboxes
(this is not a seperate point, but a qualification of the above)
> 3. such a system would not suffer serious capability or
> performance bottlenecks
...based upon unproven, and patently incorrect assumptions.
> 4. counting the administrative time dedicated to
> dealing with viruses, it would be better in the long run.
> : As another poster said already, applying the concept of a sandbox to
> : things like device drivers is simply adopting a microkernel
> : architecture. In other words it's about as old and tired as the rest
> : of your revolutionary ideas.
>
> many objections to my ideas are in the form, "what you are proposing
> is [x]. [x] has been tried". I am not very interested in debating
> this. I will clarify [x] to those who ask intelligent questions.
IOW: "Do not confuse me with the facts."
> : OK, but you've been arguing the inverse, i.e. the problems *will* go
> : away when you *do* design the sandbox in an ingenious way that
> : transcends all prior attempts lacking in imagination. A claim you most
> : likely can't back up without actually showing us an actual new,
> : ingenious sandbox design that shows promise of tackling some of these
> : issues.
>
> I am asserting it is possible.
Assertion != Truth
> I am asserting it will be done,
> regardless of my own contributions to the matter. I am not interested
> in handing it down like moses from the mountain. I would like
> to work with people who agree with my assertions above & want
> to realize the vision.
> to those who do, please sign up for the mailing list.
> : Odd, that's what we've all been telling you this whole time. You seem
> : to think that your OS *will* create itself if you just talk about it
> : long enough.
>
> it will, but no one will credit me of course. hahaha
Laying claim to ideas that are not yours is undeserving of 'credit'.
>
> We say talk is cheap, very cheap. Are you a PHB, by any
> : chance?
>
> talk is cheap, I agree. I even saw linux torvalds quoted saying
> that recently. so it must be true. btw I have actually written
> code.
So show it.
<follow-ups reset somewhere appropriate>
--
Bill Anderson Linux/Unix Administrator, Security
Analyst
ESBU (ARC) [EMAIL PROTECTED]
My opinions are just that; _my_ opinions.
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: The conceptual sandbox?
Date: Thu, 09 Sep 1999 10:09:52 -0600
James Andrews wrote:
>
> Several things:
>
> Firstly, your post was unnecessarily agressive. I also don't see
> anything in your previous posts that has disproved in ANY way, the
> concept of a sandbox model, so there is no justification for your
> attitude.
>
> Secondly, your little idea of the fallibility is, quite frankly,
> bollocks. Firstly, why would a compiler have total priveledges?
It doesn't, and he didn't say it did. Is the kernel compiled? Yes.
> Secondly, why would a compiler on ANY system have access to startup
> scripts?
I think you severely misread jonathan's post. He specifically stated the
initialization scripts were not the issue. The kernel is up and running
_before_ the initialization scripts. Johnathan never stated the compiler
would do _anything_ with the init scripts. To say he did is a strawman
:-|
...
> We are discussing a concept. We put forward points. You tell us they
> wont work. Why? No justification, you have just decided that in your
> mind, the concept is infallible.
>From where I sit, it is Vladimir that has been doing this, but,
admittedly, I haven't read _every_ post on this subject either.
>
--
Bill Anderson Linux/Unix Administrator, Security
Analyst
ESBU (ARC) [EMAIL PROTECTED]
My opinions are just that; _my_ opinions.
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Fri, 03 Sep 1999 13:16:13 -0600
"Vladimir Z. Nuri" wrote:
>
> In comp.os.misc Peter da Silva <[EMAIL PROTECTED]> wrote:
> : Western society as a whole is "nonliterate hostile", and attempts to
> : make it less so rarely work. If you want a computer for people who can't
> : read or write, I recommend you look towards Nintendo and Sega.
>
> if you want world domination, or perhaps merely an OS that isn't
> a pain in the --- to install/use/maintain, I recommend you consider
> a different attitude.
If you want to get anywhere here, I suggest you follow your own advice.
If you do not know how to use a given computer, you would likely
consider it hostile. even if you _do_ know, you may still consider it
hostile. People are not all alike in what they untuit or grok. Merely
claiming that you can come up with a system that everyone will instantly
know is arrogance. Such a system would need to probe/scan/whatever
someones mind/brain/whatever to figure out what the individual's
thinking patterns and tendencies are, then configure itsself to display
data in that fashion, and accept commands and instruction in that
fashion.
>
> often what is idiot proof is also the easiest to use, for
> users of all levels of sophistication.
Incorrect assumption.
>
> I submit that a truly good OS & application environment would
> not pit the experienced against the inexperienced, anyway.
> its a false dichotomy only existent in existing systems
> to date.
Prove it!
--
Bill Anderson Linux/Unix Administrator, Security
Analyst
ESBU (ARC) [EMAIL PROTECTED]
My opinions are just that; _my_ opinions.
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Thu, 09 Sep 1999 10:24:48 -0600
"Vladimir Z. Nuri" wrote:
>
> In comp.os.misc EdToy <[EMAIL PROTECTED]> wrote:
> : I didn't accuse him of anything (I'm sure he's a fine techie). I just
> : said how it's all working out in the hands of the capitalists: those who
> : do the work, don't get the rewards of it. And my gut feeling is that
> : Vladimir is more on the exploitation side than the techie side.
>
> ooooooooooh ouch. I have put in a lot of effort into
> promoting this effort with largely nothing but a bunch of
> jeers & harassment to show for it so far.
>
> I hereby promise to share whatever capitalistic revenues
> result in a fair/equitable manner. however, I can't see
> how such revenues would be generated except long, long
> into the future. linux is something
> like 7 years old, and it is only recently that a company
> had an IPO related to it (yes there were service companies
> eking out some cash prior to this date).
Your inferences here are invalid. Lack of an IPO is _not_ an indicator
that companies were doing nothing more than "eking out some cash". Many
large and profitable companies are private, having never han an IPO.
Additionally, I would not consider 10M $US as 'eking' out some cash.
that is a pretty substantial amount of money, especialy from free
software.
> I admit I would like to find a way to channel a capitalistic
> incentive into the open source agenda. lacking any clear
> path to do so, however, I am donating my own time & effort
> & asking all others doing the same.
When your goal is to develop some sort of financial gain, it is not
'donating' your time.
> I agree the problem of exploitation is a serious one for the
> open OS community to consider.. the red hat angle
> is going to become problematic in the future I believe.
> merely throwing out a lot of IPO stock rights to
> various developers possibly only increased the acrimony.
Bull. All an IPO is is an offering of stock in a company, for the first
time, to the public. RedHat GPLs all their work (AFAIK), and will, for
the forseable future, continue to do so. Unless you have _specific_
evidence to the contrary, i don;t believe you should be going around
saying it.
> p.s. I was once in a development community for one of
> the original famous "open source" projects. I do
> agree that the founder exploited the labor of the
> participants. it is not a situation I want to recreate.
> I would like to create something "quite to the contrary".
Which project? I assert my disbelief. Here you have a perfect
opportunity.
_Prove_ _Something_.
--
Bill Anderson Linux/Unix Administrator, Security
Analyst
ESBU (ARC) [EMAIL PROTECTED]
My opinions are just that; _my_ opinions.
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Thu, 09 Sep 1999 10:29:59 -0600
"Vladimir Z. Nuri" wrote:
> : No loss to me, after all.
>
> any work without recompense is a loss in some ways imho.
> sometimes the recompense is more intangible, like having
> the code available. but let us all agree the most tangible
> recompense of all is cash.
Nope, I don't agree. I assert that the most tangible is the transaction
itsself.
--
Bill Anderson Linux/Unix Administrator, Security
Analyst
ESBU (ARC) [EMAIL PROTECTED]
My opinions are just that; _my_ opinions.
------------------------------
** 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
******************************
