In this issue:
Re: Need advice on PHP and MySQL books
Re: Open source (was RE: Hi!Dear FreeBSD!)
Re: Need advice on PHP and MySQL books
Re: Open source (was RE: Hi!Dear FreeBSD!)
Re: Open source (was RE: Hi!Dear FreeBSD!)
RE: Open source (was RE: Hi!Dear FreeBSD!)
Re: Open source (was RE: Hi!Dear FreeBSD!)
The FreeBSD Jive Copyright
----------------------------------------------------------------------
Date: Wed, 19 Feb 2003 12:33:22 -0600
From: Pete Ehlke <p...@rfc822.net>
Subject: Re: Need advice on PHP and MySQL books
On Thu, Jan 23, 2003 at 06:12:09PM +0100, Brad Knowles wrote:
> At 8:15 AM -0600 2003/01/13, Pete Ehlke wrote:
>
> > Does anyone know the story about NSD? I've looked at it several times,
> > run it and played with it locally quite a bit, and found it extremely
> > interesting. But I've had a third-hand report that RIPE folks have said
> > (third hand, but this is the direct quote I got...) "the damn thing just
> > didn't work". Haven't been able to get more than that.
>
> Interestingly, it is now in production on ns.eu.net:
>
And, as of today/tomorrow, on K.root-servers.net.
- -P.
------------------------------
Date: 19 Feb 2003 11:45:53 -0800
From: sw...@attbi.com (Gary W. Swearingen)
Subject: Re: Open source (was RE: Hi!Dear FreeBSD!)
> [...] it would be a good idea to write a full-on GIS map
> rendering system so you could find your local user groups in a cool way.
I recently saw a GIS map that made me say "cool". A world map which
allowed one to select a city (in a recent Red Hat installer).
What made it cool what that it kept a red line connecting the pointer to
the city nearest the pointer, so you could easily tell which city you
would be selected by clicking. Of course, in this case it might have
been good enough to just display the name of the city nearest the
pointer, but that wouldn't have made me say "cool".
------------------------------
Date: Wed, 19 Feb 2003 21:32:27 +0100
From: Brad Knowles <brad.k...@skynet.be>
Subject: Re: Need advice on PHP and MySQL books
At 12:33 PM -0600 2003/02/19, Pete Ehlke wrote:
> And, as of today/tomorrow, on K.root-servers.net.
Indeed, I saw the announcement by Daniel. I'm looking forward to
their anycast operations, so that we have more than just one root
nameserver operating in this manner (see
<http://www.isc.org/services/public/F-root-server.html>), albeit
perhaps with slightly different technical implementations.
- --
Brad Knowles, <brad.k...@skynet.be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
------------------------------
Date: Wed, 19 Feb 2003 15:07:13 -0600
From: Stephen Hilton <nos...@hiltonbsd.com>
Subject: Re: Open source (was RE: Hi!Dear FreeBSD!)
On Wed, 19 Feb 2003 13:19:04 -0000
"Paul Robinson" <pa...@iconoplex.co.uk> wrote:
> OK, I've moved this over to -chat where it belongs more than -hackers,
> trimmed the CCs, and turned this into a bit of a rant. For those just tuning
> in, Terry thought it would be a good idea to write a full-on GIS map
> rendering system so you could find your local user groups in a cool way.
> That's besides the point. Apologies for length of mail, but be thankful this
> is now only 35% of the size it was going to be before I trimmed it - I had a
> fun lunchtime! :-)
>
> Terry Lambert wrote:
>
> > Sure, if you'll let me point out again that the original poster
> > wanted the maps to be clickable. 8-) 8-).
>
Actually I had the "cool" idea regarding a way to find others
in my geographic area that have an interest in BSD, and as Nik
pointed out, it is a re-invention of the wheel as the perl
mongers already have done a similar style web interface.
Whether this was implemented via GIS, GPS, latitude & longitude,
etc... was not even a thought when I posted, and I am surprised
that GIS is something that is still a mostly closed source type
application. This is a recognized area of interest for many people,
and with a little research I found an ongoing project, practically
in my backyard.
This project is not a complete solution, but is a major step in
the right direction.
My suggestion for a web locator for BSD interested people was
not intended as a call for developers time to blaze a new trail,
there are many more *important* fish to fry out there, it was
a selfish request to make it easier to find other BSD interested
parties in my geographic area for possible educational and social
interaction.
I have joined the list for my closest BSD user group, and look
forward to attending my first meeting, but finding a date and
time where the existing group members can meet seems to be a
never ending problem.
Not having the detailed history of the development of UNIX, and
what wheels are already invented is a high-bar that is presented
to people new to FreeBSD, it is also one of the reasons that I
arrived at FreeBSD as my personally favorite OS. The ability to
not repeat history, due to the continuing study and in depth
understanding of history, is something that I find lacking in a
lot of places now. This does not IMHO seem to be a problem with
this project, the guidance of people who have "been around the
block before" seems to be ever present, and welcome.
FreeBSD seems to me to be a place where experienced professionals
mentor and guide the new talent, hopefully the new gurus will be
kind enough to share their knowledge and history of computing
with their following generation of proteges.
From regularly reading several FreeBSD lists it has dawned on me
that my posting to hackers is probably not a good thing, mostly
because I am not a programmer, so my ability to contribute there
is minimal, but as a read-only lurker I find the discussions
fascinating, and do gradually gain a better overall understanding
of some of the concepts and subjects.
> GIS != Imagemaps. :-)
Approaching this from another angle, documentation != vi.
But when a person without the necessary background in the fu of
documentation wants to *learn* or accomplish a task, a text file
created in *vi* may be just what is needed at that point. :-)
> > FWIW: the important gateing factors on any Open Source project are:
> >
> > 1) Motivation (a problem to solve, that people can agree on)
>
> You don't get paid for OSS work, so you'll work on what you feel like, and
> only when you feel like it. This is completely reasonable. At the moment I'm
> working with somebody on a proposal for taking over the competition at
> the5k.org and the one thing we're trying to avoid is filling it with
> bureaucracy simply because to do so would bring it to a grinding halt. We
> deal with that rubbish all day long - we don't need to do it all night long
> too. :-)
>
> > 2) Working code (something that comes close to solving the
> > problem, or from which people can see a solution)
>
> This is critical, and is the reason why we're now seeing more "mainstream"
> applications like OpenOffice appear on open operating systems. If you don't
> have a decent framework that is easy to work with, it's perceived to be too
> risky to try and build something on top that is relatively complicated.
> Also, companies are starting to realise that giving away code is not the end
> of the world.
>
> > 3) Community (communications and peers to provide a context in
> > which the work can take place)
>
> Or in the case of some mailing lists around here, people scream at each
> other...
The ability to take a task or problem and distill it into a outline,
followed by the mathematics to model and create a flexible and
elegant solution is what makes the guru programmers such a valuable
resource to a project. But these skills do not always go hand in
hand with the ability to interface with the control structure, end
user, or even with co-developers. System analysts, project managers,
documentation writers, beta testers, technicians, focus groups, end user
feedback, etc... are all examples of the interfaces and structures
needed to create a "whole" solution. To marginalize any of the parts
of the "whole" only weakens it.
Why the discussions from such brilliant minds sometimes dwells
on the the reasons why something will not work, and cite books
and papers to prove this is beyond me. I would like to reference
a very important title that has helped many people and projects
to succeed:
_Little Engine That Could_ by: Watty Piper
Without the people who have disregarded others views of
"the way things work" we would have a nicley documented
by scribe description of our flat earth on clay tablets.
>
> > A lot of people have #1, so they declare a Source Forge project, try
> > to cookie-cutter #3 (impossible to do), and leverage having #1 and #3
> > into someone creating #2 (also impossible to do).
>
> Indeed. Sourceforge is littered with the debris-like manifestations of good
> intentions.
But the good intentions do stand on their own, the original project
may have fallen by the wayside, but can we really measure the impact
of a meeting of minds, that may have never occurred with out the
focus point of a shared idea. The pool of people capable of writing
really good code is quite limited, so an abandoned Sourceforge
project could be the future focus point to join one of these gifted
programmers with others, who can provide support in the other areas,
leaving the code hacker to do her best, at hacking code :-)
> > As a matter of fact, I claim that, given any #2, I can *find* #1,
> > and *create* #3.
- -------------many paragraphs snipped--------------
- --------------------------------------------------
> There is all the cultural stuff as well, but that's more orientated to the
> Gen-X idealism of how licensing should work. In the end, that'll fall on
> it's face too, but that's for another day. This mail is long enough already.
> :-)
Yes, the dreaded licensing quagmire. So many speak about freedom
and giving back to the community, here is my two cents worth.
The BSD type license is the model of true sharing and freedom,
without it Apple would still be a closed system, and I would
have never spent $ to purchase one. With FreeBSD as a foundation,
my wife now uses an iMac as she continues her education, and
tells me how much nicer her workstation is at home, than the
machines in the schools lab. And I do not have to dread
maintaining her workstation, it is a joy to see it happily
purring away on its very solid foundation.
I see many examples in the BSD world of the beauty of our
license, people like to live in comfort and security, and
when that basic need is fulfilled, the sharing of their
knowledge, without strings attached, is a true indicator
of their desire to help create a better world.
The fear of my intellectual property being "stolen by X"
is exactly that, a fear, and nothing more. Create your
code, write your books, invent your widgets, hold the rights
to these devices to secure your comfort, then when the time
is right for you, free the ideas. What is wrong with others
profiting from your work, I profit every day from this rich
society, enhanced by people willing to share.
Regards,
Stephen Hilton
nos...@hiltonbsd.com
------------------------------
Date: Wed, 19 Feb 2003 19:37:10 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Open source (was RE: Hi!Dear FreeBSD!)
Paul Robinson wrote:
> Terry Lambert wrote:
> > You would be hard-put to simply design a new set of systems, and
> > simply "throw the switch", and have the new organization spring,
> > full grown, from Zeus's head,
>
> Actually, the ease with which you can do that is inversely proportional to
> the complexity of the system. I'm sure that between us, everybody on the
> freebsd lists could get a working "count_to(x)" function working perfectly
> within the next 3 months and we would be confident in it's "correctness"
> without having to test it too much. I don't think the same could be said if
> we decided we were going to write a functionally equivalent piece of
> software to say, Visual Studio .NET in the same time frame and then just
> "release it" on a given day. That's why the concept of -RELEASE always makes
> me chuckle a little.
This was actually a comment on the systems of operation of the
project itself, not the software that a project produces.
I think, sometimes, that software people reuse terminology so
quickly that they become "vocabulary blind". For example, if
I were to say that this discourages "introspection", you could
think I meant something other than philosophical self-examination.
8-).
In this context, "systems" was intended to mean things like "the
process by which you get increasingly sanctioned on a mailing list
for trolling, until you are removed from the list", or "the process
by shich SPAM source addresses are reported to a blackhole list,
and less immediately, but more permanently banned from participation
in the mailing list". It also means "the process by which one
becomes a committer", "the process by which one becomes a core team
member", "the process by which one has one's commit bit revoked", etc..
> > OpenOffice is a different phenomenon entirely. It is a copy of a
> > commercial product, with very little in terms of innovation. For
>
> Ah, but it opens a lot of doors. Five years ago, no even two years ago, if
> you'd said to the boss of a small non-tech outfit "install Linux or FreeBSD
> instead of Windows", the biggest thing preventing him/her from doing so
> would be the fact that they wouldn't be able to send and receive Word and
> Excel spreadsheets. StarOffice got rid of that barrier, then created another
> one that OpenOffice took down again.
I think the biggest barrier was "It's not Windows, and I pay for
Windows anyway, when I buy the machine". I think that's still the
barrier, in fact. Draconian and repetitive licensing, so now it's
nearly impossible to own the software outright, is a factor in
favor of non-Windows solutions. On the other hand, can you really
ever own GPL'ed software outright, either? Well, no, but you can
limit the number of times you pay for it.
If the licensing model that Microsoft want ("software leasing") ends
up becoming the standard, then it's not going to be possible to, for
example, buy a computer with software installed, and then amortize
your total costs over the (currently allowed) three years. The costs
go up. When cost accounting is forced to change, then you will see
attitudes change... that is, if the software is there... there's not
a "QuickBooks" for non-Windows systems, let along a MAS-90.
> > What kind of idiot would create a word processor that required
> > documentation, without some overriding business/systems need for
> > a need for someone to provide it? What is so incredibly hard
> > about merely the *idea* of word processing, such that this
> > should be necessary?
>
> It's a change of contextual thinking as far as the user is concerned. That's
> why stories of secretaries putting Tippex all over their screen exist. Word
> processors are yesterday's news these days, but back then, the idea of a
> Word processor or a spreadsheet and how it operated were alien concepts.
"Cut-and-paste" was a well known phenomenon before the computer;
that's why we call that operation on a computer "cut-and-paste"
today. Most software operates by analogy, not allegory: people
generally have no problems translating: it's what people do; it's
what human beings are good at, above all else.
> Even now I know of accountants who have been working in small villages with
> paper based systems that don't understand that a spreadsheet *automatically
> does the maths*. When I have explained it, they've sat there in awe at how
> easy fiscal modelling becomes, never mind book-keeping. That's the point
> they become excited. Once that mental jump is made, it's easy. Making the
> jump though...
I think the parables of "Whiteout" ("Tippex") on the computer
screen, and the accountant who doesn't understand simplistic
spreadsheet operations are just that, parables: "Be like Gallant,
not like Goofus". They are designed to teach.
What I *have* seen be hard to grasp is the concept of "iteration",
and, most particularly, the concept of "conditional termination".
It's not that these are really hard concepts to put across, it's
that the tools think about these issues like programmers. For
example, if I have an IRR (Internal Rate of Return) function,
which I want to apply on a monthly basis, I want it to stop applying
it to new cells to the right of the spreadsheet when the balance
in the previous cell goes to zero -- no mor payments needed. To
specify this in spreadsheet terms requires a complex formula, which
include both a value comparison and a value substitution, with a
special case value comparison for the first value that causes the
principal to go negative. There is no such thing as "until balance
is zero", and there is no automatic concept of "payment balances are
definitionally prohibited from becoming negative".
When you ask someone to enter a "formula" which is actually a complex
loop with two branching conditionals, you are asking too much of the
end user: you are asking them to think like programmers, not like
accountants.
> > In other words, they are able to successfully defend their
> > existing market by way of increased complexity, and the inability of
> > Open Source equivalents to manage complexity. We see this in the use
> > of "embrace and extend" tactics, and in the pushing of increasingly
> > (and technically unjustifiably) complex standards through the public
> > standards processes.
>
> XML being one of those, IMHO.
Yes. The lack of standards requirements for the contents of XML
documents -- the lack of explicit limits on extension -- make XML
file formats an easy thing to manipulate this way.
> MS has been good at this for a while. They're cleverer than perhaps
> they give themselves credit for.
I doubt it. Intent is the easier explanation, for elegant systems.
> If it wasn't for that damned calendaring thing they came up with,
> Exchange wouldn't be in too many SMEs these days. This isn't about
> complexity though, it's about functionality. It goes back to the MS
> Program Managers understanding what a user would like, and getting
> it into the product. Nobody does that in the Open source world
> outside of their own organisation. Even when the need is clearly
> identified - "we want shared calendars like in Outlook" - the
> complexity of producing an identical product THEN becomes overwhelming, so
> they produce something inferior based around a webmail package. This is a
> flaw in the process, it's virtually impossible to fix.
I really disagree with this. People wanted calendaring, and they
wanted certain features associated with calendaring. Building it
into OutLook was actually a negative thing for most people, given
the lack of automatic triggers and other features that can't come
from a protocol requiring active participation. By building it
into OutLook, they introduced a number of synchornization and a
number of logistical problems, which could not be easily overcome.
If you look at a program that does *only* calendaring, like ON
Technologies' "Meeting Maker", in comparison, these deficiencies
become really obvious; for example, you have to explicitly check
for new mail for your schedule to be updated, and even if you do
this at defined intervals, the operation is not something that
occurs within a reasonable human factors timeout. Likewise, a
resource such as a meeting location, which does not have an email
address of it's own, is a second class participant: you can't
"invite conference room 2", except by proxy, so resource conflict
resolution becomes very difficult. Netscape calendar screwed the
pooch in almost exactly the same way, by leaving out notification
triggers -- a consequence of being based on LDAP, rather than
something like LTAP.
The inferior webmail packages are more a sympton of "web services
fever", where people believe that they can replace real applications
with things that live on a web server somewhere. It's why the web
services industry never really took off. Microsoft using email for
the same thing has the same problems; even if you proxy via an
Exchange server, your back-propagation feedback delay is too large
for interactive use.
> Don't get me started on ESR. That's a whole new discussion. Cathedral and
> Bazaar did more damage to OSS than pretty much anything else I can think of
> right now. Good intentions, but the model is terrible. As for sourceforge,
> it's not a failure, it's just not very efficient. That is to say, there is a
> better model for what they want to acheive, the difference is, they've
> actually done it and nobody else has.
The main problem with Source Forge comes down to not forcing the
code to exist and (mostly) work first.
The secondary problem with Source Forge is not one of model, it's
one of cookie-cutter mentality on community. This gets back to
margin: the feedback loops can never be tightened up enough to cost
control the process to below the available margin for participation.
A third problem is the amount of visible failures that result from
the first two, but that's a secondary effect, even if it feeds the
general perception: if you want a project to fail, take it to Source
Forge.
I don't think this can be cast in terms of efficiency: it's a gateing
issue, more than anything, combined with suppression of the most
obvious negative feedback into the overall system. Short of "not
permitting failing projects", there's very little that they could do
to suppress discussions like this one, in which they are cast as
negative examples.
> > Yet Mozilla *did* screw itself,
> > and BSD-based Open Source projects all waited for the trigger of 386BSD
> > and the working code it provided.
>
> Somebody (let's not get into the argument) somewhere, one day sat down and
> wrote the beginnings of what eventually became Unix. They did not have
> existing code, just ideas.
They were researchers, and they were being paid to pursue something;
they "found" UNIX along that path. That's very different than
sitting down and incrementally moving some large stones around, only
to have St. Paul's Cathedral appear 200 years later.
There is a difference between enabling infrastructure and things
built on top of it. Do roads exist because of monuments, or do
monuments exist because of roads?
> If you're saying all software must be evolutionary, then I
> disagree. It's easier for software to evolve over multiple
> iterations and restarts to get to the ideal system than it is to
> sit around and design perfection and then go for implementing the
> "perfect" system but that does not mean all software must be
> evolutionary.
I have a great deal of personal disdain for the idea that there
is always a path from one equilibrium point to another. Or in
other words, I don't believe in evolving software, and I don't
believe in "bit rot". Sometimes, "you can't get there from here".
This is like the idea that you can start out with a hole in the
ground, go from there to a mud hut, from there to a thatched
cottage, then to wood hoses, then to brick, then to brownstones,
and from there... St. Paul's Cathedral. It doesn't happen that
way, it *can't* happen that way. Great edifices do not occur as
a result of evolution.
> > The problem is the nature of the people involved in volunteer projects.
>
> Here we go...
>
> > Instead, your pool of volunteers is made up of people who like to
> > tinker, and are not satisfied with the way things are, but those
> > people generally have no great leadership skills or vision of a
> > future that they are then prepared to work hard at making real.
>
> That's a little harsh. It's true that many developers would rather implement
> things their own way rather than buy in existing products or use existing
> code that isn't quite perfect. Particularly if they know it's easy, but
> slightly fun and can go on the CV.
Forget code, people reinvent "quicksort" and other simple algorithms,
because they can't be bothered to learn history before they start
tinkering. It's not a matter of "not reusing code", they don't even
"reuse ideas".
> > In a lot of ways, Jeff Raskin is right, and still no one is listening.
> > In two of your examples of products that you think should/will be
> > written, you yourself fell into this trap of cloning from bad gene
> > stock.
>
> Agreed. But that's because they work. They work very, very well. If there
> was a better way of doing what they do, I wish I could think of what it was.
> I'd probably not OSS it though, because I'd want to make some cash. :-)
8-).
The answer lies, I think, at the point you have to interrupt your
work-flow, and move one of your hands over to the mouse, in order
to get something done.
> > At a former employer, there was an engineer who believed in this
> > philosophy so completely, they wanted everyone to accept Steve
> > McConnell as their personal saviour. An excellent engineer, but
> > they could not understand my reluctance to join their religion,
> > because they saw everything in terms of process: for them, the
> > process *was* the product, and any business was just a side effect.
> > It was very much like being back at USL.
>
> The process is important, but then my degree is Software Engineering, and
> I'm currently a manager who has little to do with code production. My view
> is probably skewed. The important thing is that the process is supposed to
> be lightweight and non-intrusive. The requirements cpature process is
> important though, and if you can adopt Extreme programming, or at least
> aspects of it, then you can through process increase the quality of your
> product.
The funny thing about the management perspective is that what you
are really interested in is not producing a great product. It's
more about resource levelling and controlling risk. As long as
you can meet schedule, then your rewards are assured.
From a games theoretic standpoint, most management systems are set
up incorrectly to encourage the emergent behaviours that companies
claim they want.
For example, in IBM, your pay is comprised of two parts: your
immediate pay, and your variable pay (what used to be called
"bonus"). This value is controlled by a scaling factor that is
under the control of your immediate manager; after that, the rest
of it is out of your hands. The scaling factor is a function of
a number that comes out of your performance review.
In the old days, all managers and employees had the same dependency
relationship between hierarchical performance and the amount of
variable pay that would be available. This hierarchical performance
was: group, division, company, and for the sake of argument, let's
say it was [60%,30%,10%].
Then someone who did not understand games theory (or beleived everyone
who knew math was in management... 8-)) decided that there needed to
be more cooperation between divisions, and that this was a "grass roots"
issue, rather than a hierarchical "shit rolls down hill" issue. So
they changes the relative weighting between management and line employees,
such that employees were less dependent on group and division performance,
and more dependent on overall company performance. The managers, they
left the same.
The problem is that the main factor under the control of a line employee
is their manager's perception of them. Therefore, the behaviour that
they wanted to encourage was not encouraged, as a simple matter of math.
What they should have done instead is the opposite: make the management
variable pay less depenent on division performance, and more dependent
on group and overall company performance. This would have incented the
behaviour they said they want, since the line employees had much less
control over the overall profitability of the company, and instead
controlled only their ability to please their immediate supervisor(s).
The reason for this little digression is that it demonstrates that
people do that which rewards them, not that which they are told is
important.
> > "Why, if product developement is
> > changed to a fully user and quality-centric model, would people
> > continue to buy new versions of these products?".
>
> User requirements change in the same way as everything else. People don't
> buy new clothes, furniture and consumer electronics on a regular basis
> because they don't have something that was not user and quality-centric when
> it was designed. It's just that the requirements change. With clothing, this
> happens on a seasonal basis for some people. My old TV was fine, so why did
> I buy a 32" widescreen? My VCR was fine, so why a DVD? Functional upgrades?
> Change in perception of quality? Fashion? All these and more play into it.
> Software is no different.
A better question to ask is not "Why replace A with B?", but "Why
replace A with new A?".
There are very few reasons, unless you are a habitual consumer, to
replace your old VCR with a new VCR before the old VCR breaks. You
may claim that you have replaced your VCR with a DVD, but did you?
Did you get rid of all your old media, or convert it to the new
format, or did you buy a DVD *as well* as a VCR?
Frankly, and I've said this before, I would be tempted to get rid of
my VCR, *if* the companies wanting me to switch over to pure DVD use
were to make the value proposition worthwhile: give me credit for my
VHS investment, in converting it to a DVD investment, instead.
How many people do you know who had large VHS collections before DVD,
now have large DVD collections, and no VHS? If there are any people
you know who meet this description, they are people with well above
average disposable incomes. Personally, I know a lot of people with
above average disposable incomes, and not one of them has converted
their entire VHS collection.
> > The value proposition for the mainstream is whether or not they can
> > hire a temp for a week in accounting, and that person will be able
> > to use the tools in place, without needing training.
>
> The transition between WordPerfect and Word happened. The transition away
> from Word can happen. The issue though is whether people can get done what
> they need to, and if there are other advantages. At the moment, advocates
> are harming OSS by telling everybody that OSS has a lower TCO which is bull,
> but not pointing out the real advantages. Unfortunately, those advantages
> can be swallowed up by MS or anybody else on the commercial side the moment
> they wake up and smell the coffee.
I was there for the transition from WordPerfect to Word. It happened
because WordPerfect dropped free support, and the amount of support
required by Word was less than the amount of support required by
WordPerfect, and the cost of support -- including the amortized per
seat cost -- was overall higher for WordPerfect than for Word. And it
happened because Microsoft started "giving away" Word with new computer
purchases, so you were paying the up front cost for Word with each new
computer.
And why did Word Perfect drop free support? Because they wanted to
sell the company to another company, whose valuation on acquisitions
was a simple formula based on profit-per-employee, with no lag factor
to account for quarter-to-quarter hiring and firing.
The whole "OSS TCO" argument is BS, that's true. But so is the
argument that Microsoft has to look over its shoulder and worry
about someone displacing a bundled product.
> > Most people end up conforming their views to the community, rather
> > than selecting a community on that basis, in my experience. 8-).
>
> You evidently didn't spend much time as a teenager then. :-)
Teenagers are brillinat examples of group conformance: "I want to
be different, just like everyone else!". 8-). What group you join
is dictated primarily by who tolerates your presence best.
- -- Terry
------------------------------
Date: Thu, 20 Feb 2003 12:35:58 -0000
From: "Paul Robinson" <pa...@iconoplex.co.uk>
Subject: RE: Open source (was RE: Hi!Dear FreeBSD!)
Everything I would say in response about the OS issues is summed up here:
http://osnews.com/story.php?news_id=2857&page=all
I think this basically agrees with a lot of what you're saying, but you're
mixing into the argument issues around programmer motivation that they
aren't discussing here. I agree with pretty much everything you said on
that. The issues around evolving code can be kind of summed up (or at least,
it's a starting point), here:
http://www.kuro5hin.org/story/2003/2/13/9212/42643
And I think both of these sum up what I would say in response to a lot of
what you said, in condensed form. To be honest Terry, I know how I would
respond in full but i think the best format for all that would be a book,
and we don't have time. :-)
In summary, I think we're in agreement on most of this.
Except this:
> Teenagers are brillinat examples of group conformance: "I want to
> be different, just like everyone else!". 8-). What group you join
> is dictated primarily by who tolerates your presence best.
What group you join is dictated by who *you* tolerate the presence of best.
What group you *remain in* is dictated secondarily by who tolerates your
presence best, but primarily who you think you can tolerate the best on a
long term basis.
Sometimes people end up warping your values to fit in to remain in the group
(nobody who starts to hang around with crack heads think they will become
one themselves, unfortunately living in Manchester, UK, I can attest they
are nearly always wrong), but ultimately you will stay in those groups who
you prefer to hang around with. Put it this way, how many people do you know
who were thrown out of the Boy Scouts for being too old but who wanted to
stay in the Boy Scouts? How many left because they didn't want to do that
stuff any more? Same thing.
If you want to bring this back into a BSD-related thread, Theo didn't start
OpenBSD because he had no choice: he couldn't tolerate NetBSD core anymore,
and they couldn't tolerate him. Now, if you want to be a commiter to OpenBSD
you have to understand the fact that Theo is in charge. If you can tolerate
that, you'll be fine. If you can't, chances are you'll head over to Net- or
Free- instead. If Free- throw you out, you know you can still hang around.
It's not about what the group tolerates. It's what you tolerate.
------------------------------
Date: Thu, 20 Feb 2003 08:13:37 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Open source (was RE: Hi!Dear FreeBSD!)
Paul Robinson wrote:
> > Teenagers are brillinat examples of group conformance: "I want to
> > be different, just like everyone else!". 8-). What group you join
> > is dictated primarily by who tolerates your presence best.
>
> What group you join is dictated by who *you* tolerate the presence of best.
> What group you *remain in* is dictated secondarily by who tolerates your
> presence best, but primarily who you think you can tolerate the best on a
> long term basis.
>
> Sometimes people end up warping your values to fit in to remain in the group
> (nobody who starts to hang around with crack heads think they will become
> one themselves, unfortunately living in Manchester, UK, I can attest they
> are nearly always wrong), but ultimately you will stay in those groups who
> you prefer to hang around with. Put it this way, how many people do you know
> who were thrown out of the Boy Scouts for being too old but who wanted to
> stay in the Boy Scouts? How many left because they didn't want to do that
> stuff any more? Same thing.
I was personally thrown out of Boy Scouts for being Catholic instead
of Mormon; does that count?
Primates are social animals; the majority of them will tolerate nearly
anything to be accepted as part of a group.
> If you want to bring this back into a BSD-related thread, Theo didn't start
> OpenBSD because he had no choice: he couldn't tolerate NetBSD core anymore,
> and they couldn't tolerate him. Now, if you want to be a commiter to OpenBSD
> you have to understand the fact that Theo is in charge. If you can tolerate
> that, you'll be fine. If you can't, chances are you'll head over to Net- or
> Free- instead. If Free- throw you out, you know you can still hang around.
> It's not about what the group tolerates. It's what you tolerate.
Tolerance of people by the group is the most important factor here.
One of the most common anti-BSD claims is "BSD is elitest" -- it
being a complaint about group tolerance of individuals, rather than
individual tolerance of the group.
OpenBSD is a really poor example. I can explain the NetBSD/OpenBSD
split very easily in terms of overdriving a reward margin; it's a
deceptively simple set of mathematics. It was very much an individual
decision by Theo, with almost all the trigger actions being in his
hands, at the time.
I think in terms of "group splits", you really have to think in a
different context: it is not about group acceptance or tolerance,
it's about control, direction, margin, and rate. If you measure it
in these factors, it makes it a lot easier to understand, and it
accounts for more than just a simplistic model of "NetBSD/OpenBSD",
it also accounts for "386BSD/NetBSD" and "386BSD/FreeBSD" (this
last is mre properly "FreeBSD/386BSD"). It's all about the volatility
introduced by strange attractors.
For example, the recent denouements in the FreeBSD camp can be
traced back to driving forces in the mailing lists -- intentional
marginal pressure to incite stress forces, by people with interests
counter to those of the project. I wouldn't claim that they were
commercially motivated without verifiable evidence, but let's say
"I am suspicious" at this point, and leave it there for now.
The problem with a broader understanding of a class of systems is
a broader understanding of what it takes to preturb them from any
given equalibrium state. The act itself can be either benevolent
or malevolent, depending on the perpetrator.
- -- Terry
------------------------------
Date: Fri, 21 Feb 2003 01:02:36 +0100
From: "Stacy Olivas" <oli...@digiflux.org>
Subject: The FreeBSD Jive Copyright
Just for s&g, I can the COPYRIGHT file thru the jive
filter:
# $FreeBSD: src/COPYRIGHT,v 1.4 1999/09/05 21:33:47 obrien Exp $
# @(#)COPYRIGHT 8.2 (Berkeley) 3/21/94
All uh de documentashun and software included in de 4.4BSD and 4.4BSD-Lite
Releases be copyrighted by De Regents uh de University uh Califo'nia.
Sheeeiit.
Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
De Regents uh de University uh Califo'nia. Sheeeiit. All rights reserved.
Redistribushun and use in source and binary fo'ms, wid o' widout
modificashun, are puh'mitted provided dat da damn followin' condishuns
are met, dig dis:
1. Redistribushuns uh source code must retain de above copyright
notice, dis list uh condishuns and da damn followin' disclaimer. Ah be
baaad...
2. Redistribushuns in binary fo'm must reproduce da damn above copyright
notice, dis list uh condishuns and da damn followin' disclaima' in de
documentashun and/o' oda' materials provided wid de distribushun.
3. All advertisin' materials menshunin' features o' use uh dis software
must display de followin' acknowledgement, dig dis:
Dis product includes software developed by de University of
Califo'nia, Berkeley and its contributo's.
4. Neida' de dojigger uh de University no' de dojiggers uh its contributo's
may be used t'endo'se o' promote products derived fum dis software
widout specific prio' written puh'mission. 'S coo', bro.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPSHUN)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
De Institute uh Electrical and Electronics Engineers and da damn American
Nashunal Standards Committee X3, on Info'mashun Processin' Systems gots'
given us puh'mission t'reprint po'shuns uh deir documentashun.
In de followin' statement, de phrase ``dis text'' refers t'po'shuns
of de system documentashun.
Po'shuns uh dis text are reprinted and reproduced in electronic fo'm in
de second BSD Netwo'kin' Software Release, fum IEEE Std 1003.1-1988, IEEE
Standard Po'table Opuh'tin' System Interface fo' Computa' Environments
(POSIX), copyright C 1988 by de Institute uh Electrical and Electronics
Engineers, Inc. In de event uh any discrepancy between dese versions
and da damn o'iginal IEEE Standard, de o'iginal IEEE Standard be de referee
document.
In de followin' statement, de phrase ``Dis material'' refers t'po'shuns
of de system documentashun.
Dis material be reproduced wid puh'mission fum American Nashunal
Standards Committee X3, on Info'mashun Processin' Systems. Computa' and
Business Equipment Manufacturers Associashun (CBEMA), 311 First St., NW,
Suite 500, Washin'ton, DC 20001-2178. De developmental wo'k of
Programmin' Language C wuz completed by de X3J11 Technical Committee. What
it is, Mama!
De views and conclusions contained in de software and documentashun are
dose uh de audo's and should not be interpreted as representin' official
policies, eida' 'spressed o' implied, uh de Regents uh de University
of Califo'nia. Sheeeiit.
NOTE: De copyright uh UC Berkeley's Berkeley Software Distribushun ("BSD")
source gots'ta been updated. De copyright addendum may be found at
ftp, dig dis://ftp.cs.berkeley. Slap mah
fro!edu/pub/4bsd/README.Impt.License. What it is, Mama!
Change and is
included below.
July 22, 1999
To All Licensees, Distributo's uh Any Version uh BSD:
As ya' know, certain uh de Berkeley Software Distribushun ("BSD") source
code stashs require dat furda' distribushuns uh products containin' all o'
po'shuns uh de software, acknowledge widin deir advertisin' materials
dat such products contain software developed by UC Berkeley and its
contributo's.
Specifically, de provision eyeballs, dig dis:
" * 3. All advertisin' materials menshunin' features o' use uh dis
software
* must display de followin' acknowledgement, dig dis:
* Dis product includes software developed by de University of
* Califo'nia, Berkeley and its contributo's."
Effective immediately, licensees and distributo's are no longa' required to
include da damn acknowledgement widin advertisin' materials. Acco'din'ly,
de
fo'egoin' paragraph uh dose BSD Unix stashs containin' it be hereby deleted
in its entirety. Slap mah fro!
William Hoskins
Directo', Office uh Technology Licensin'
University uh Califo'nia, Berkeley
------------------------------
End of freebsd-chat-digest V5 #708
**********************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-chat-digest in the body of the message