This statement is being released in hope of putting to rest some of
the general questions and rumors currently floating around in respect
to the long discussed merger between the FreeBSD and NetBSD groups.
Merge
-----
Due to various problems, and in the face of fundamental differences of
opinion regarding future goals and design strategies, all merger talks
between the groups have been suspended and the proposed merger
postponed indefinately.
The FreeBSD and NetBSD groups will not be merging at any point in the
near future, and each group will be pursuing its own schedules and
delivery dates for future release.
What this means to you
----------------------
Despite various accusations and counter-accusations recently levied in
some of the comp.os.386bsd.* newsgroups, both operating systems have
reached the point where they are both very useful (and relatively
stable) development platforms for the Intel architecture, and no one
would be wrong in chosing either of the two offerings.
The currently outstanding technical differences between the two
systems will also, it is quite likely, continue to shrink with time
and both systems will probably seek their own unique areas of
differentiation outside the realm of adding features to the basic
kernel. Neither system plans to stand still over the next 6 months,
and each has a reasonably large enough user base to ensure that new
ideas, corrections and general clean-up work will continue [in both
camps] for some time to come.
Wouldn't a merge have been better?
----------------------------------
There is no question that work duplication and other technical issues
would have been avoided or made simpler under a merge, but for various
reasons it has nonetheless remained outside the realm of practicality;
please remember that what looks very simple from an outsider's point
of view is often anything but. In any case, work will still continue
apace in both camps, and history has generally shown that a little
"competition" has never hurt anyone when it comes to providing
motivation for improvement and forward movement. We tried to
negotiate a merge, it didn't work, so we have to cut our losses and
move forward. End of story.
Is the matter truly closed?
---------------------------
Yes. Please don't bombard us with email saying "Please merge!" or
"Why can't you merge? Why?!?" - believe me, we've gotten every
possible variation on the theme you might imagine, and we've done our
best to explain in more emails than we can count, so kindly do us a
favor and don't send us even more. We need to get on with our work on
FreeBSD, and such things only sap our time and hinder our progress.
To answer the next question: Conversations on this matter to date
have been, of necessity, constrained to private email due to the fact
that the situation has always been somewhat volatile, and public statements
concerning the inner workings of the merge negotiations while they were
in progress would have made them even more difficult.
We also hope that this statement will help put an end to some of the
unfortunate (and wholly unnecessary) public bickering between the
two groups. We're two groups, providing BSD technology to the world
at large for free and at considerably cost to ourselves in terms of
time and energy, so the last thing we need is the ball-and chain of
internecine warfare attached to our feet - it only aggravates all
of us and delays the progress of your favorite operating system!
Please help by cooperating with all of us in trying to put this
somewhat difficult time behind us, and continuing to provide the
extremely helpful feedback and assistance that has made both groups
possible (and certainly 386BSD itself, with which we also desire only
the best relations). Those who can provide common technology in a
group-neutral fashion are the most helpful of all, and we encourage
all of you to do what you can to see that both groups go forward.
This is all about free software, after all, and should not be about
ideological divisions or matters of personal ego.
Thank you!
(The FreeBSD team)
--
(Jordan K. Hubbard) j...@violet.berkeley.edu, j...@al.org, j...@whisker.lotus.ie
I do not speak for Lotus, nor am I even a Lotus employee. I am an independent
contractor.
--
Please send submissions for comp.os.386bsd.announce to:
386bsd-...@agate.berkeley.edu
If they're so irreconcilable it certainly seems like someone would be
wrong in choosing one over the other (for a specific purpose).
>To answer the next question: Conversations on this matter to date
>have been, of necessity, constrained to private email due to the fact
>that the situation has always been somewhat volatile, and public statements
>concerning the inner workings of the merge negotiations while they were
>in progress would have made them even more difficult.
Now that they're no longer in progress, let's hear the dirt :-/
Once again, it seems like irreconcilable differences are probably important
differences. An enumeration of the differences should be helpful to
people deciding which system to use.
>We also hope that this statement will help put an end to some of the
>unfortunate (and wholly unnecessary) public bickering between the
Hardly unnecessary. Now that the groups are officially competing(...), let's
hear from those who know, what exactly is better about their system and what's
wrong with the other system.
>two groups. We're two groups, providing BSD technology to the world
>at large for free and at considerably cost to ourselves in terms of
>time and energy, so the last thing we need is the ball-and chain of
Oh, Boo Hoo. Nobody is forcing you to work on it. I think it's safe to say
that everyone appreciates the contributions of people such as [bl]jolitz,
julian, cgd (well, maybe not jmonroy :), nate, terry, and _many_ others. If
you're not having fun and/or profiting (fame, fortune, resume, research, ego,
etc.) by working on *BSD, then *stop*.
>This is all about free software, after all, and should not be about
>ideological divisions or matters of personal ego.
Hopefully responses to this post will demonstrate that it's *not* all about ego.
-Dan
I'm afraid I don't see this at all. The README/INSTALL_NOTES
for each OS states what hteir goals for the future are, so
based on that, and a feature set, you can choose an OS
that you think you're more comfortable with.
>
>Now that they're no longer in progress, let's hear the dirt :-/
>Once again, it seems like irreconcilable differences are probably important
>differences. An enumeration of the differences should be helpful to
>people deciding which system to use.
As a laregely regular member of the *BD community, I really don't
care that much why there has been no merge. A lot of people
(myself included) would have liked to see it, but it isn't going
to happen, so let's make do anyhoo.
>Hardly unnecessary. Now that the groups are officially competing(...), let's
>hear from those who know, what exactly is better about their system and what's
>wrong with the other system.
I don't see how this implies that there is now some new degree
of compettition for users or something like that. Both OSs
have different goals, and users will be able to choose based on
that and other thigns.
>>two groups. We're two groups, providing BSD technology to the world
>
>Oh, Boo Hoo. Nobody is forcing you to work on it. I think it's safe to say
>that everyone appreciates the contributions of people such as [bl]jolitz,
>julian, cgd (well, maybe not jmonroy :), nate, terry, and _many_ others. If
>you're not having fun and/or profiting (fame, fortune, resume, research, ego,
>etc.) by working on *BSD, then *stop*.
I don't understand this attitude. The implication in this post was
that since they are working on this stuff out of their own spare
time, they'd rather not have to deal with 1500 users a day asking
them why they haven't merged yet. They just wanted to make sure that
everybody understood that they have NO OBLIGATION whatsoever
to merge.
>Hopefully responses to this post will demonstrate that it's *not* all about ego.
who cares if it was the reason? It's not entirely unreasonable
that this was the case, and even then, so what? if they don't
get along, they don't get along.
again, such is life, make the best of it. i've got one machine,
so i'm using one particular OS based on my personal appraisal
of what the developers are doing, and what the goals for it are.
i'm happy with it. i really don't need a point oby point comparision
of what the core team for both OSs is doing, have been doing, and
want to do.
TooodlepiP!
Marc 'em.
P.S. you try typing over a link that ranges from 300-14,400bps and
has an average lag of about 2 seconds and see if your spelling looks
any better :-)
--
-----------------------------------------------------------------------------
Marc Wandschneider Seattle, WA
Barney the Dinosaur sings! You faint... Barney sings! Barney sings! --More--
You Die... --More--
Yeah, right - why don't you just make up your own mind? I'm not going
to post a public list of differences so that we can have another
50-followup flame war over it again. Forget it.
Oh, Boo Hoo. Nobody is forcing you to work on it. I think it's safe to say
that everyone appreciates the contributions of people such as [bl]jolitz,
Not you, obviously.
Jordan
>This statement is being released in hope of putting to rest some of
>the general questions and rumors currently floating around in respect
>to the long discussed merger between the FreeBSD and NetBSD groups.
Here is something I've been thinking about for some time now. I *love* the
new features and splitting edge technology that NetBSD is currently offering,
but I don't like having something that is 'iffy' or 'unstable'. Perhaps the
FreeBSD team would be better suited to say, pick up releases of NetBSD
and release a NetBSD 0.9s for stable. You know, just pick the bugs out of
the NetBSD releases. The problem with NetBSD is, the next release cures
most if not all of the bugs in the previous release, but it adds 'xxx' feature
that has bugs of it's own... It would be nice to have NetBSD features, and
FreeBSD stability...
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/ I N N O V A T I V E D A T A S E R V I C E S \/
/\ ================================================= /\
\/ Hardware/Software Sales & Service /\ Complete Networking Solutions \/
/\ Virus Removal & Prevention \/ Remote System Administration /\
\/ Contract Programming & Consulting /\ Internet Service Provider \/
/\-------------------------------------\/-----------------------------------/\
\/ 22290 Green Hill, Suite #42 /\ Phone: (313)478-3554 \/
/\ Farmington Hills, Michigan 48335 \/ Fax: (313)478-2950 /\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <crt.75...@tiamat.umd.umich.edu> c...@tiamat.umd.umich.edu (Rob Shady) writes:
>Here is something I've been thinking about for some time now. I *love* the
>new features and splitting edge technology that NetBSD is currently offering,
>but I don't like having something that is 'iffy' or 'unstable'.
you've not tried NetBSD-current lately on a 'serious' system, have you?
we're more stable than they are, and we *have been* for a while. (I'd
say we were "more stable" when 0.9 came out, but that's not a fair
comparison; they'd not done a release yet! however, we killed a couple of
real *killers* right before 0.9 that i know they've not killed yet, because
i get get their commit messages via e-mail, in the same way that many of
them get ours.)
sure, if you pick up -current *EVERY NIGHT* occasionally you'll lose, but:
we've had perfectly working shared libs running for going
on 2 weeks; they still don't have it right. We have
shared XFree86. They have linker problems.
we can still reliably run on 4M machines; they can't --
they claim it's a bug from Net/2, but i've done serious
development on 4M machines from 386BSD 0.0 day one (because
the original machine i had was a 386 with 4M RAM), and never
been bitten by it.
we have a real buffer cache, no longer done out of kernel
malloc memory. this leads to more speed, and greater
reliability (because there's less kernel map fragmentation).
we've fixed *so* many machine-dependencies and chunks of
bogus code it's unbelievable; many of those areas they've
not *touched*.
we've fixed *so* many bugs that they've not -- and that
they don't even know are there. we've found them
by stress-testing the hell out of NetBSD; they've
not even come close to doing that.
"NetBSD is not stable or well-tested" is a myth that started long
ago, and it just isn't true. at one point, it arguably might have been,
and even today, if you pick up a new release every day, you can still
get slightly burned. But if you're careful, you won't.
And i'm not even going to talk seriously about the fact that NetBSD
is your *only* choice if you want to run on ... a sparc, an hp300,
an amiga, a mac, &c.
chris
--
chris g. demetriou c...@cs.berkeley.edu
smarter than your average clam.
Define "stable." How many major changes are checked in to each try a week?
How many minor changes?
A system can be buggy as hell, yet still be stable and desirable for that
one reason.
And what's with the "us" vs. "them"? Between that and a couple of the
core netbsd people shouting insults at anyone who disagrees with them,
I'm surprised you have anyone helping you at all anymore.
>i get get their commit messages via e-mail, in the same way that many of
>them get ours.)
Real useful after you've removed the ability for all or most of them to
check the CVS files, isn't it?
> we've had perfectly working shared libs running for going
> on 2 weeks; they still don't have it right. We have
> shared XFree86. They have linker problems.
And how long have they been working on the shared libraries? Answer: about
two weeks, taking a package that was written for a somewhat different system
and making it work. How long did it take for netbsd to have working shared
libraries, from the start of the project? And how long do you honestly
expect these linker problems to last? Or did you pounce on them while you
still could, instead of waiting a couple of days for them to be cleared up?
> we've fixed *so* many machine-dependencies and chunks of
> bogus code it's unbelievable; many of those areas they've
> not *touched*.
Well, then, why don't you share what those are? Nah, I think you're right,
name calling and furthering a split is much more productive.
(A little note: I am biased. I will not work on netbsd anymore due to the
attitudes of deraadt and mycroft, and a bit of cgd; stuff he did last night
has further increased that ... *anger*. So take it all with a grain of salt;
unlike what cgd and others would like you to believe, both systems do work,
quite well, and are perfectly usable for development. Of course, I'm still
running 386bsd, and my system has now been up for 8 days; that's better than
my SCO system managed at times, so what do I know? :))
i don't see anyone shouting usually, except you, sean. and invariably
you can't take it if people shout, or even peep, back. Hmm, or was
that intentionally bouncing mail...?
perhaps the "us vs. them" comes from being pretty-much blindsided by
the announcement? i dunno, i worked many long and hard hours on trying
to get the two systems merged. I would have liked maybe 10 minutes
notice of what was going on. Or perhaps some details from Jordan
as to why FreeBSD decided to make this announcement...
>>i get get their commit messages via e-mail, in the same way that many of
>>them get ours.)
>
>Real useful after you've removed the ability for all or most of them to
>check the CVS files, isn't it?
i'm sorry; NetBSD simply doesn't have resources to support the development
of NetBSD *and* the development of another operating system, as well.
Remember: we're not making any money off of this, and thus far i've sunk
about 15k into hardware for this project. There are simply not the
resources for people who aren't doing development to eat disk space and
CPU cycles on lamp for the purposes of sucking changes into their
own system, so they can claim it's "better," and not give us properly-
attributed credit for the work we've done. The day that i started
seeing postings on FreeBSD mailing lists which had no body, and only
a subject which said "Has anybody picked up XXX from NetBSD yet?"
where XXX was the "neat feature of the day," i lost all faith in
FreeBSD's development process.
The fact that, for the most part, the FreeBSD "developers" used their
accounts on sun-lamp *only* for the purpose of snarfing revisions of
our code and migrating it to FreeBSD revolted me, and it still does.
You can't call it "development" if you don't have a coherent understanding
of what's going on. That's exactly what i meant about the shared libraries.
It's not a matter of whether or not they have to debug the changes they've
made. The point is that the changes that went in WEREN'T TESTED, they
broke in HORRIBLE WAYS (the last of which are only being discovered),
and it's taken them two weeks to figure them out. If you're going to make
a change that major, TEST IT FIRST; we do!
It's a similar (sad) story with the "4M vs. the VM system" changes:
I've been using 386bsd and then NetBSD on a 4M machine, doing system
builds and whatnot with no problems (other than heavy swapping 8-).
Then along comes David, hacking on the VM system, and lo an behold,
suddenly, 4M machines break. did they back out the changes? no.
How long have they known about the bug? weeks, now, i believe it is...
>(A little note: I am biased. I will not work on netbsd anymore due to the
>attitudes of deraadt and mycroft, and a bit of cgd; stuff he did last night
>has further increased that ... *anger*. So take it all with a grain of salt;
>unlike what cgd and others would like you to believe, both systems do work,
>quite well, and are perfectly usable for development. Of course, I'm still
>running 386bsd, and my system has now been up for 8 days; that's better than
>my SCO system managed at times, so what do I know? :))
I never, ever said that both systems "didn't work", or that both
systems weren't "perfectly usable". On the contrary, as noted, that post
was made to dispell the long-standing and completely incorrect notion
that NetBSD *WASN'T* "perfectly usable." Thank you for helping me
make my point.
Really? Please, tell me why you blind yourself to deraadts wonderful
comments of "asshole" or "fuck off" whenever someone disagrees with him,
or messages from mycroft that have:
From: Charles Hannum <myc...@duality.gnu.ai.mit.edu>
Subject: Re: bootblocks, AST Bravo's, what is DEBUG_VECTOR ?
You are such a cocky prick, I wonder if I should even bother to
explain why you are wrong.
(Note that when he was asked to apologise, his response was that he
didn't give a damn.) And I know you saw that, chris, because you're
on the mailing list.
Unfortunately, I didn't save either of the messages from both those two
that caused me to swear off of netbsd.
>perhaps the "us vs. them" comes from being pretty-much blindsided by
>the announcement?
Really? It was discussed, I know. Maybe you should talk to the other people
you let run your system, and find out what they've been saying to the freebsd
folks.
>Or perhaps some details from Jordan
>as to why FreeBSD decided to make this announcement...
I think you already know that. Or did you think that removing CVS access
for only the freebsd folks was going to have no ramifications? You know,
I bet wjf thought the same thing about you.
>i'm sorry; NetBSD simply doesn't have resources to support the development
>of NetBSD *and* the development of another operating system, as well.
Yeah, what does this mean? Oh, wait, you describe it below:
>Remember: we're not making any money off of this, and thus far i've sunk
>about 15k into hardware for this project. There are simply not the
>resources for people who aren't doing development to eat disk space and
>CPU cycles on lamp for the purposes of sucking changes into their
>own system, so they can claim it's "better," and not give us properly-
>attributed credit for the work we've done. The day that i started
>seeing postings on FreeBSD mailing lists which had no body, and only
>a subject which said "Has anybody picked up XXX from NetBSD yet?"
>where XXX was the "neat feature of the day," i lost all faith in
>FreeBSD's development process.
Ah. So you *don't* want "your" system to be free, you don't want it to
be picked up by other people, and you don't want to share stuff that's
been contributed to you. (And, yes, people can go get netbsd-current
each day... that eats up more bandwidth and cycles. But, then, you're
not paying for sun-lamp's net connection, so I guess you don't care about
that. They also lose the ability to look at the comments in the
commit message, do a cvs diff, and see the history of the changes.)
Real open. The "net" out of "netbsd" *did* mean that it was to be open
to basicly anyone who wanted to participate, didn't it?
Now: I've not seen any of the freebsd people publicly claim that freebsd
is "better." I have seen netbsd folks, including yourself, say why netbsd
is "better," and, either say directly or imply, what losers the freebsd
folks are.
Oh, and yeah: tell me why you removed me? Guess what I did when
I looked at the cvs modules on sun-lamp? Checked out things for my
apartmentmate. Who runs netbsd. Oopsie. I guess people who live with
people on the freebsd list are persona non grata as well, huh?
>The fact that, for the most part, the FreeBSD "developers" used their
>accounts on sun-lamp *only* for the purpose of snarfing revisions of
>our code and migrating it to FreeBSD revolted me, and it still does.
Oh, yeah. Can't share free code, can you? Or are you making it not free?
Tell me... what have you been doing on your freefall account? Somehow
I can't believe you were checking in changes for freebsd... or maybe
you were.
>The point is that the changes that went in WEREN'T TESTED, they
>broke in HORRIBLE WAYS (the last of which are only being discovered),
>and it's taken them two weeks to figure them out. If you're going to make
>a change that major, TEST IT FIRST; we do!
Uhm, hate to tell you this, buddy, but the shared libraries are still being
tested. Or have you seen a release of freebsd that has shared libraries?
Did shared libraries work the first day under netbsd?
The main answer that the freebsd folks gave to "which is better" used to be...
neither, really, we share a lot of code. Guess they'll have to change that
now. And guess who was responsible for that? One single, hurt person.
Am I the only one who sees similarities between this and the jolitzes?
you've not tried NetBSD-current lately on a 'serious' system, have you?
we're more stable than they are, and we *have been* for a while. (I'd
say we were "more stable" when 0.9 came out, but that's not a fair
comparison; they'd not done a release yet! however, we killed a couple of
real *killers* right before 0.9 that i know they've not killed yet, because
i get get their commit messages via e-mail, in the same way that many of
them get ours.)
And if you believe all that, I have a bridge I think you'd be really
interested in! Both groups are making a number of strides forward,
and someone like Chris is as qualified to speak on our behalf as we
are to speak on his.
It's also sad when someone abuses their position on our commit lists
to publically denigrate us. Enough.
Jordan
If that was their reasoning, perhaps they should have made it public.
Ahh, Mr. Big (Mouth) is making himself spokesman for FreeBSD?
Also, i'd be more inclined to believe your argument if the chronology
were what you claimed. Jordan's note was posted to .announce at:
13 Nov 1993 22:31:38 -0800. CVS access on lamp for FreeBSD developers
not working on the NetBSD source tree at 22:40 (-0800, 13 November).
How do i know? well, i'm looking at the ctime of a file that i chmodded
when their access went away. You can't call it a response if it happens
before what it's responding to. "cause and effect; logic 101."
Note that people working on FreeBSD who *are* working on NetBSD
did not have their access to NetBSD's CVS tree denied. Only those
who are doing no work on NetBSD cannot access our CVS tree.
Therefore, you can't claim that we're kicking people out of our
tree because they work with (or even mostly with) FreeBSD; that's
just not true. If they're not working on NetBSD, then they don't
have access; plain and simple.
perhaps the "us vs. them" comes from being pretty-much blindsided by
the announcement? i dunno, i worked many long and hard hours on trying
to get the two systems merged. I would have liked maybe 10 minutes
notice of what was going on. Or perhaps some details from Jordan
as to why FreeBSD decided to make this announcement...
If you felt blind-sided, then I apologise. I didn't post it to
-hackers because -hackers is just too big and I didn't feel like
getting the abuse from many of the NetBSD people on it (and don't say
I wouldn't have - you know better).
own system, so they can claim it's "better," and not give us properly-
attributed credit for the work we've done. The day that i started
seeing postings on FreeBSD mailing lists which had no body, and only
a subject which said "Has anybody picked up XXX from NetBSD yet?"
where XXX was the "neat feature of the day," i lost all faith in
FreeBSD's development process.
Oh Chris, give us all a break ok? When I complained about NetBSD people
doing exactly the same thing, you told me to get lost. When I asked
you to have the people who felt `unattributed' contact us if they
had a grievance, which we'd be more than happy to rectify, you never
responded. Both messages are in my +outbox, you want me to dig them
up and post them?
This is just drivel..
Jordan
A system can be buggy as hell, yet still be stable and desirable for that
one reason.
i can't answer this; you will have the ask the current users how stable it
is on daily/nightly basis. you don't have to take our word for it.
at the same time you might want to ask them how stable their shared
library XFree86 2.0 is, too...
(a round of applause to Paul Kranenburg for his sunos-compatible shared
library code!)
<tdr.
No, i didn't. i told you to take up the matter with "core@lamp."
I am not the NetBSD School Master, and if you think i am, then you're
sorely mistaken.
If you call "take it to the people who can deal with it properly"
a statement of "get lost," then, well, hmm, i don't really know what
to say.
The fact is, if you've got a problem with one of the people on 'core',
then you should take it up with the entire group of them, NOT ME;
I CANNOT RIDE HERD ON THEM FOR YOU.
cgd
From: Charles Hannum <myc...@duality.gnu.ai.mit.edu>
Subject: Re: bootblocks, AST Bravo's, what is DEBUG_VECTOR ?
You are such a cocky prick, I wonder if I should even bother to
explain why you are wrong.
I note that you failed to cite what that was in reply to. Maybe I
should refresh your memory.
>From: b...@kralizec.zeta.org.au (Bruce Evans)
>Subject: Re: bootblocks, AST Bravo's, what is DEBUG_VECTOR ?
>
>Aargh. This was correct in my orignal version, but it got broken for
>NetBSD. You must have got it from an unreliable source :-).
I noticed that not even a single person publicly voiced that Bruce
shouldn't have made such a snide remark. And in fact, what he said
later in that message was wrong, to boot.
Ah. So you *don't* want "your" system to be free, you don't want
it to be picked up by other people, and you don't want to share
stuff that's been contributed to you.
You of course ignored the point. NetBSD is available to *anyone* who
wants it. What is not available to FreeBSD groupies is the choice of
picking carefully through our changes to find the things they want or
need. Maybe I should post Jordan's .bash_history from sun-lamp. (In
fact, I think I will. He left it world-readable, after all.)
Real open. The "net" out of "netbsd" *did* mean that it was to be
open to basicly anyone who wanted to participate, didn't it?
And it still is. However, the FreeBSD people participate in FreeBSD,
not NetBSD, and we have no obligation to support them in their
commercial effort.
Now: I've not seen any of the freebsd people publicly claim that
freebsd is "better."
Then you're not paying attention. I've seen it many times, and it
gets damned tiring.
Oh, and yeah: tell me why you removed me?
Because you are extremely caustic, and we don't trust you? Sounds
like a good reason to me.
Or are you making it not free?
The only people making money off of our code is Walnut Creek, and
anyone they decide to send part of the proceeds to.
Tell me... what have you been doing on your freefall account?
Somehow I can't believe you were checking in changes for
freebsd...
Chris has in fact done exactly that, and I have donated changes to
FreeBSD also.
Uhm, hate to tell you this, buddy, but the shared libraries are
still being tested.
Well, after listening to stories about random segmentation faults,
panics, and various other problems associated with people installing
shared libraries under FreeBSD, I find it just a bit hard to believe
that they were tested *at all* before being put in their source tree.
Am I the only one who sees similarities between this and the
jolitzes?
No. That the FreeBSD people take code from us and do not contribute
back is very reminescent of Jolitz.
As mentioned, the .bash_history Jordan left world-readable. Note that
the only thing he's done is pull changes from our source tree. Why
should we donate cycles and code to the (commercial) FreeBSD effort?
wall
wall
wall
wall
wall
cd /usr/src/sbin/fsck\
ls
cat Makefile
w
w
exit
cd /usr/src/sbin
ls
grep FASTLINK */*.[ch]
tar cvzf ~/dump.tar.gz dump
tar cvzfX ~/dump.tar.gz - dump
cd
ls
cd /usr/src/sbin
tar cvzXf - ~/dump.tar.gz
tar cvzXf - ~/dump.tar.gz dump
tar cvzXf - ~/dump.tar.gz dump
tar cvzXf - ~/fsck.tar.gz fsck
vi ~/.rhosts
exit
cat .rhosts
cvs commit
exit
ls /sys/sys/con*
ls /sys/sys/kd*
exit
w
date
exit
from
inc
show
vi ~/.forward
next
kn
kn
kn
ls /sys/i386/isa
ls /sys
ls /sys/arch
ls /sys/arch/i386/isa
exit
ls
rm slat.tar.gz ufs.tar.gz isofs.tar.gz fsck.tar.gz dump.tar.gz
df
w
cd /usr/include/sys
ls
cd /usr/include/netinet
moire in.h
more in.h
ftp allspice.berkeley.edu
dd if=tk3.3b2.tar.Z bs=1 skip=1098584 of=rest
ls
cd
dd if=tk3.3b2.tar.Z bs=1 skip=1098584 of=rest
ls -l tk3.3b2.tar.Z rest
dc
bc
dd if=rest bs=128 of=xxx
rm xxx
dd if=rest bs=1b of=xxx
dd if=rest bs=128 of=xxx count=1
dd if=rest bs=128 of=xxx count=1 skip=1
dd if=rest bs=128 of=xxx count=1 skip=2
dd if=rest bs=128 of=xxx count=2
dd if=rest bs=128 of=xxx count=4
dd if=rest bs=128 of=xxx skip=2 count=2
od -c xxx
ls -l xxx
dd if=xxx bs=64 count=1 of=yyy
dd if=xxx bs=64 skip=1 count=1 of=yyy
dd if=xxx bs=64 skip=2 count=1 of=yyy
dd if=xxx bs=64 skip=3 count=1 of=yyy
dd if=xxx bs=64 skip=4 count=1 of=yyy
rm yyy
ls -l xxx
dd if=xxx bs=128 count=1 of=yyy
dd if=xxx bs=128 count=1 skip=1 of=yyy
rm yyy xxx
ls
dd if=rest bs=128 of=xxx skip=2 count=2
dd if=rest bs=128 of=xxx skip=2 count=1
dd if=rest bs=128 of=xxx skip=2 count=2
dd if=rest bs=128 of=xxx skip=3 count=1
dd if=rest bs=128 of=xxx skip=2 count=2
ls
mv xxx killer_chunk
gzip -9v rest
ls
uncompress -v rest.z
gunzip[ rest.z
gunzip rest.z
ls -l rest
exit
cd /b/os/mach3/src/mk/kernel/i386/
ls
ls fp*
exit
w
frm
from
cat ~/.forward
exit
cat .rhosts
w
cd ~sup
exec csh
w
locate wish
df
ls /kern
ps aux
exit
w
date
w
exit
ls
w
exit
w
vi ~/.rhosts
cd /usr/src
ls
cd sys
w
./bash
pwd
ls
cd arch
ls
cd sun3
ls
more STATUS
cd
./bash
exit
exit
w
cd /usr/src/sys
ls
ls
cd arch
ls
cd pc532
ls
ls pc532
ls dev
more dev/aic
more dev/aic.c
export TERM=vt100
more dev/aic.c
ls
ls conf
more conf/devices.pc532
ls
cd ..
ls
cd amiga
ls
more README.first
ls
cd amiga
ls
cd ../dev
ls
more gvp11dma.c
w
w
cd /usr/src
ls
cd sys
ls
cd ~ftp
ls
cd pub
ls
cd NetBSD-currentls
cd NetBSD-current
ls
cd tar_files
ls
cd src
ls
cd /sys/i386/conf
cd /sys/arch/i386/conf
ls
more GENERICAHBBT
ls
cd ..
ls
exit
w
exit
w
df
ls/f
ls /f
ls /d
ls /c
df | awk '{ cnt += $2 } END { printf(
df | awk '{ cnt += $2 } END { printf("cnt = %d\n", $cnt); }'
df | awk '{ cnt += $2 } END { printf("cnt = %d\n", cnt); }'
exit
w
exit
locate smh|more
locate cat
locate shm
exit
w
talk cgd
write cgd
write cgd
exit
w
talk cgd
exit
locate uname
more /a/users/glass/src/full/src/lib/libc/sys/uname.2
cd /usr/src/lib/libc/sys
ls
more uname.2
pwd
cd ../..
pwd
cd ..
find . -name uname\* -print
tar czvf ~/uname.tar.gz
tar czTvf ~/uname.tar.gz
tar czTvf - ~/uname.tar.gz
ls sys/sys/utsname.h
fg
pwd
fg
ls -l sys/sys/utsname.h
fg
cat > /dev/null
cat > /tmp/xxx
ls -l `cat /tmp/xxx`
ls -l ./sys/sys/utsname.h
tar czTvf /tmp/xxx ~/uname.tar.gz
tar czhTvf /tmp/xxx ~/uname.tar.gz
tar czXvf - ~/uname.tar.gz `cat /tmp/xxx`
cd
ls
ls -l uname.tar.gz
cd /usr/src/lib/libc
ls
cd sys
ls
more Makefile.inc
pwd
ls
more uname.2
ls
cd /sys/
ls
find . -name '*uts*' -print
cd /usr/src/sys/arch/i386
ls
cd i386
ls
cd ..
ls compile
ls conf
ls conf/std.i386
ls
ls stdand
ls stand
ls
ls boot
ls
ls include
pwd
cd ..
ls
cd ..
ls
ls kern
cd kern
ls
more syscalls.master
more syscalls.master
grep uname *
more syscalls.c
ls
vi kern_xxx.c
pwd
grep uname *
vi init_main.c init_sysent.c
uname
uanme -a
uname -a
fg
ls ~
fg
grep version *.c
locate SUN-LAMP
locate SUNLAMP
uname -a
locate SUN_LAMP
cd /a/users/glass/src/full/src/sys/arch/i386/conf/SUN_LAMP
ls
w
talk cgd
cat /kern/version
cd /e/users/cgd/trees/all/src/sys/arch/i386/compile/SUN_LAMP
ls
cat vers.c
cd /sys/conf
ls
more newvers.sh
pwd
fg
exit
cd /sys/kern/
ls
vi kern_xxx.c
exit
ls /
exit
w
df ~pkmr
pwd
cd /d/users
ls
cd pk
ls
cd src
ls
ls gnu
ls gnu/usr.bin/
ls include
ls
cd ..
ls
cd doc
ls
more INSTALL_NOTES
ls
more LAST_MINUTE
cd ..
ls
ls lib
more 386bsd.h
ls
cd ld
ls
cd ..
ls gcc2
exut
exit
w
exit
w
w
cd /usr/lib
ls
ldconfig
cd /var/run
ls
which ldconfig
man ldconfig
exit
uptime
exit
ls
ls -F
cd /usr/src
alias
ls -F
ls sbin
type ld
ls /usr/bin/*ld*
echo $LINES
export LINES=60
man ldd
ls usr.sbin
ls usr.bin
ls bin
ls gnu
ls gnu/usr.bin
echo $SHELL
ls gnu/usr.bin
ls gnu/usr.bin/ld
pwd
pu ~
pwd
df
pu
cd gnu/usr.bin/ld
ls ldd
ls ldconfig
man ldconfig
exit
cd ~pk
ls
ls doc
ls -F
ls ld
ls src
ls -l libc*
ls -l ld.tar.Z
ls -ld ld
ls -l
df
finger sef
pu ~
pwd
pu
ls bin386
du -s gas gcc2
type tar
tar --help
type gzip
tar czf ~/gas.tar.z gas
ls -l ~/gas.tar.z
tar czf ~/gcc2.tar.z gcc2
po
ls -l *z
exit
pu /usr/src/sys
ls
du -s .
ls ~ftp
ls ~ftp/sup
ls ~ftp/sup/ksrc-i386
cd ..
ls
tar czf ~/sys.tar.gz sys
po
ls -l sys.tar.gz
exit
cd ~pk
ls -l
ls ~
tar czf ~/ld.tar.gz ld
cd
ls -l ld.tar.gz
exit
uptime
who
echo $LINES
export LINES=60
man ld.so
man ld
man link
man 5 link
man ld
ls /usr/share/man
ls /usr/share/man/cat5/l*
type link
ls /usr/lib/ld.so
ls /usr/lib/*.so
/usr/lib/*.so
cd ~pk/ld
file ld.so
ls
ls -F
ls ..
ls -l ../libc*
ls ldconfig
ls obj
ls ldd
ls doc
ls ../doc
pwd
ls ../bin386
ls -l ../bin386
grep ld.so Makefile */Makefile
cd rtld
ls
more Makefile
exit
finger pk
w
exit
w
exit
w
talk cgd
w
talk cgd ttypd
write cgd
w
cd /usr/src
ls
ps aux | grep jkh
kill -9 3339
pwd
cd gnu
;s
ls
cd /usr/src/gnu
ls
cd usr.bin
ls -l
date
cd ~pk
ls
ls -l
tar cvzf ~/ld.tar.gz ld
rm ~/ld.tar.gz
tar cf - ld | tar -C ~ xvf -
tar cf - ld | tar xvf - -C ~
cd
cd ld
ls
make clean
/usr/bin/make clean
whoch make
which make
PATH=/usr/bin:$PATH
hash -r
make clean
ls -lR
find . -name CVS -print | xargs rm -rf
cd ..
tar cvzf ld.tar.gz ld
ls -l ld.tar.gz
cd ld
rm t/*.o
rm ld/ldconfig/*.o
find . -name '*.o'
find . -name '*.o'|xargs rm
cd ..
tar cvzf ld.tar.gz ld
ls -l ld/t/libh.so.1.0
rm ld/t/libh.so.1.0
tar cvzf ld.tar.gz ld
ls -l ld/t/libh.so.1.0
ls -l ld.tar.gz
write pk
write pk
exit
The "losers" comment aside, perhaps there's a good reason for this.
>The main answer that the freebsd folks gave to "which is better" used to be...
>neither, really, we share a lot of code. Guess they'll have to change that
Well, why doesn't someone say why freebsd is better? If it's worse, or
at best equal, why take resources (users, programmers, etc.) from netbsd?
*I'm not saying this is the case*, but if one system is better than the other,
it's hardly fair to claim otherwise, confusing the issue for people deciding
on which system to use.
>Am I the only one who sees similarities between this and the jolitzes?
If the "jolitzes" had allowed access to their code in a timely manner (ala
netbsd's "current" release, and freebsd's frequent releases) netbsd and freebsd
probably wouldn't exist (IMHO).
-Dan
Hmm, is this the issue? Then how come Chris just verbally donated the
code to *YOUR* shared library implementation to BSDI a couple days ago,
yet someone who distributes code on a stinking CD-ROM is a 'commercial
effort' who shouldn't have access to *YOUR* code?
(The *YOUR* is on purpose. Paul has made it clear that his code is freely
available to anyone, and not just for NetBSD)
> Oh, and yeah: tell me why you removed me?
>
>Because you are extremely caustic, and we don't trust you?
Caustic? Hmm, I never heard it that way, but I think anyone who has
seen your postings could say the same about you.
>The only people making money off of our code is Walnut Creek, and
>anyone they decide to send part of the proceeds to.
No-one in FreeBSD (except for Rod in his job as integrator) makes
a dime in FreeBSD from their work. I've turned down offers of money
from folks just to keep it on the table.
However, we all have real jobs, and real lives, so we don't get to spend
12+ hours/day working on FreeBSD, which fortunately/unfortunately many
of the NetBSD folks 'get' to do.
> Tell me... what have you been doing on your freefall account?
> Somehow I can't believe you were checking in changes for
> freebsd...
>
>Chris has in fact done exactly that, and I have donated changes to
>FreeBSD also.
Unlike Chris, those changes were from NetBSD and you offered them to
FreeBSD afterwards. You don't happen to mention the recent work
you've done in *obtaining* FreeBSD code.
Here's a questions I'd like to pose. Do all the people who donate their
code to NetBSD realize that the only way that the general public can see
their code is after you've hacked and slashed it up?
(And *possibly* introduced bugs to it. Naw, you never introduce bugs in it,
do you?)
(I'm actually humored by all of this)
Nate
--
na...@bsd.coe.montana.edu | Freely available *nix clones benefit everyone,
na...@cs.montana.edu | so let's not compete with each other, let's
work #: (406) 994-4836 | compete with folks who try to tie us down to
home #: (406) 586-0579 | proprietary O.S.'s (Microsloth) - Me
Nobody's *taking* anything from anyone else. None of the FreeBSD core
members have been a part of NetBSD in any shape other than contributors
who worked on *both* system.
>*I'm not saying this is the case*, but if one system is better than the other,
>it's hardly fair to claim otherwise, confusing the issue for people deciding
>on which system to use.
Because anything I say would be rebutted with insults, and screams and yells
and flamage saying 'I haven't a clue, I'm a loser, I know nothing' etc, etc,
etc.. The occasional tid-bit of technical would slip in on both sides, but
it would be lost in the fallout.
For people that have run both (and there are folks who have switched
from one version to the other, both ways) you will get mixed results.
Some claim that NetBSD is a piece of garbage, other's say the same thing
about FreeBSD. There is no cut/dried rules or features that one version
has over the other that makes it 100% better than the other system.
(I'll probably be flamed for this as well, sigh...)
Gee, maybe because "better" is rather difficult to define for an OS,
and nobody wants to offend anyone else?
>*I'm not saying this is the case*, but if one system is better than the other,
>it's hardly fair to claim otherwise, confusing the issue for people deciding
>on which system to use.
That's just it... to be honest, neither system is "better." They fit different
niches. It would have been nice for each to be able to share code, but
cgd has made that well-nigh impossible now. And he's managed to piss
everyone off. Which is what a lot of people were trying to avoid in the
first place.
What makes a system "better" for you may not necessarily be what makes it
"better" for me. Hell, linux is still a lot "better" in a lot of respects
than either of the *bsds!
netbsd is a moving target. freebsd is largely trying to be a stable target.
Different attitudes, different goals. Neither is "better." Each one
happens to accomplish some different goals a bit "better" than the other,
but so what?
BZZZT. try again. what i said was that the code existed, and was
available via anonymous FTP for those who wanted it. Perhaps you should
read more and interpret less.
That is not a donation, it is a statement of fact. They can get
it via anonymous FTP or SUP, or gopher, just the same as anybody
else in the world can. Just like you can, in fact.
What they cannot do is take it, and all of the little changes which
go with it, from our CVS tree. Hell, i've never even sent
DIFFS of anything to *anyone* working at BSDI; if they've wanted
code, they've gotten it themselves, from public distribution sites.
All of the integration they've done they've done 100% on their own.
>Here's a questions I'd like to pose. Do all the people who donate their
>code to NetBSD realize that the only way that the general public can see
>their code is after you've hacked and slashed it up?
In general, very few people 'donate their code'. those who do are
generally given accounts so that they can integrate it and maintain
it themselves. If they do not wish to do that, then they can't
complain.
chris
Nobody's *taking* anything from anyone else.
``anything''?
Ok, let's talk about attribution. That means you say where things come
from, and you also say who wrote them. Attribution of things by the
FreeBSD group, both for things written by others and myself, has been
a sore point with me for a long time.
The claims that attribution has been done correctly are quite false.
Here's the first example. (I have about 7 more waiting if you like :-)
I do not work on FreeBSD. My YP code was pulled out of NetBSD, without
consulting with me, into the FreeBSD tree. Even before it was commited
(I heard it was going to be through the grapevine) I made it clear to
Paul Richards that I wanted proper attribution in the commit messages.
YP consists of 6 components:
(1) domainname system call
(2) domainname binary
(3) yp library code
(4) yp binaries, ie. ypbind, ypcat, etc.
(5) changes to getpwent() and other libc library routines.
(6) the yp passwd changes, from John Brezak.
These changes were all taken out of NetBSD. They were then commited
to the FreeBSD source tree. No attribution was given in the cvs commit
messages.
(1) The domainname system call does not comtain my name on it.
(2) the /bin/domainname sources do not contain my name on them.
(3) the yp library contains my name only in the source file
headers, because I put it there.
(4) the yp programs contain my name in the headers, because I
put them there.
(5) the getpwent) and other libc routines do not have any
attribution towards me.
(6) the yp passwd changes do not credit myself or John Brezak
either.
By the way, the FreeBSD commit for YP was done fairly recently.
No, I do not consider the lack of proper attribution something to
be laughed at, and have told the FreeBSD crowd this repeatedly (Hi Rod!
Hi Nate! Hi Paul!)
<tdr.
That's okay, I don't find my name anywhere in the ptrace code I wrote.
I also was never asked permission before it was placed for redistribution.
Hasn't stopped you guys from distributing it, now has it? Frankly, it
doesn't bother me. I wrote the code so people could use it, and because
the old code was pretty stupid.
As for the yp stuff... just looking at the CVS logs on freefall, it
appears that either your name is in the copyright messages for everything,
or the log comment says, "Imported from NetBSD."
That's no more or less than you have done.
Oh please, lie and bend the truth when it serves your interests!
first of all, your name is not in the code because you did not put
it there. that is not the issue; if you had, it would have remained
there. If someone makes a change like this, we do not strip their
name from the code, and we never, ever strip would strip a copyright.
second, from the CVS log of the file:
----------------------------
revision 1.9
date: 1993/09/04 05:32:35; author: cgd; state: Exp; lines: +217 -254
better ptrace() support from Sean Eric Fagan <s...@kithrup.com>
----------------------------
third, from the doc/CHANGES file:
replace ptrace() implementation with a better one from Sean Fagan
<s...@kithrup.com> (cgd)
>I also was never asked permission before it was placed for redistribution.
and i quote from your mail to hac...@sun-lamp.cs.berkeley.edu
(which has been replaced since by "netbsd-users@..."):
=>Received: from kithrup.com (kithrup.com [140.174.23.40]) by sun-lamp.cs.berkeley.edu (8.3/8.3) with SMTP id UAA11313; Fri, 3 Sep 1993 20:19:30 -0700
=>Message-Id: <1993090403...@sun-lamp.cs.berkeley.edu>
=>Date: Fri, 3 Sep 93 20:19:33 PDT
=>From: s...@kithrup.com
=>Subject: ptrace() changes
=>To: hac...@sun-lamp.cs.berkeley.edu
=>
=>As both chris' know, I've been making changes to ptrace(), as part of my
=>four-step plan to implementing a /proc filesystem. (Yes, I know about the
=>current one, I haven't been able to make it work, and I think it needs
=>significant design changes anyway...)
=>
=> [ 2 paragraphs detailing the changes deleted ]
=>
=>I haven't checked these changes in yet; I'm waiting for cgd to try
=>them out under netbsd. It works (so far :)) under 386bsd.
=>
=> [ Note telling people to look for these files in his account on
=> sun-lamp ]
=>
The changes worked, and *I* committed them, *with* your approval.
the following two commit messages are the next two commit messages
on sys_process.c:
----------------------------
revision 1.11
date: 1993/09/05 03:53:52; author: sef; state: Exp; lines: +14 -1
Yet more of the ptrace() reorg; now ptrace_setregs() and ptrace_getregs()
are present, along with PT_GETREGS and PT_SETREGS ptrace commands.
----------------------------
revision 1.10
date: 1993/09/04 08:46:36; author: sef; state: Exp; lines: +5 -3
ptrace_single_step() and ptrace_set_pc() should return errors if
necessary. (Mainly because the SPARC can't easily single step, so
it should return EINVAL, and then ptrace() should return that to the
user.)
----------------------------
so not only did you not object to your changes being committed, but
you then committed further changes on top of them.
NetBSD-current was being made available daily; you knew that very well,
and you knew that you committing changes to the tree would mean that,
as of the following day, the world would have access to them.
You claim that you were not given proper credit:
You were given all of the credit you asked for in the file
itself, and were credited outside of it in the way you prefer
to be addressed in two seperate places.
You claim that your code was distributed without your consent:
You consented to having your code distributed, and even helped
insure that it was in the best shape possible for that
distribution.
You, Sean Eric Fagan, are a liar, tried and true.
That's okay, I don't find my name anywhere in the ptrace code I wrote.
I also was never asked permission before it was placed for redistribution.
This is really funny, Sean. This is a prime example of how we attempt to
work with people, and how we provide attribution!
You gave the code to Chris, who commited it to the tree. In mail (I
guess) you indicated a willingness to work on it more, in the tree.
(This is good, we love it when people want to take responsibility for
things we don't know much about :-). So, you were given access so you
could continue to work on it. From the CVS logs.. it appears you did work
on it.. and even commited two more changes!
If you did not change the Berkeley copyright header at the top of the
file to give yourself credit that's your own fault. In fact, the
changes seem sufficiently large enough that you should have given
yourself credit (and not the University of California). It looks like
you replaced 50% or more of the file!
For those who don't know... the file in question is sys/kern/sys_process.c,
and it impliments the ptrace() system call used by debuggers.
Here's the significant portions of the logs:
revision 1.11
date: 1993/09/05 03:53:52; author: sef; state: Exp; lines: +14 -1
Yet more of the ptrace() reorg; now ptrace_setregs() and ptrace_getregs()
are present, along with PT_GETREGS and PT_SETREGS ptrace commands.
----------------------------
revision 1.10
date: 1993/09/04 08:46:36; author: sef; state: Exp; lines: +5 -3
ptrace_single_step() and ptrace_set_pc() should return errors if
necessary. (Mainly because the SPARC can't easily single step, so
it should return EINVAL, and then ptrace() should return that to the
user.)
----------------------------
revision 1.9
date: 1993/09/04 05:32:35; author: cgd; state: Exp; lines: +217 -254
better ptrace() support from Sean Eric Fagan <s...@kithrup.com>
----------------------------
Hasn't stopped you guys from distributing it, now has it? Frankly, it
doesn't bother me. I wrote the code so people could use it, and because
the old code was pretty stupid.
No, it has not stopped us from distributing it. Since you commited it to
the tree, why should we not use it? By mailing it to Chris in the first
place you explicitly gave us permission to use it.
[...] or the log comment says, "Imported from NetBSD."
That's no more or less than you have done.
When NetBSD people do a `cvs commit' we try to do more than this; by
crediting the original author. For an example of how we do that, look
at revision 1.9 of of the file as displayed above... there are a very
large number of commit messages with exactly that format, encompassing
a list of contributers all over the world.
XXXXX from John Doe <jd...@foobar.com>
If you like, I will change the file header messages to indicate that you
deserve credit for the ptrace() rewrite. Really, we like to give credit.
<tdr.
(The *YOUR* is on purpose. Paul has made it clear that his code is
freely available to anyone, and not just for NetBSD)
Once again, you're making a useless point. We all know it is Paul
Kranenburg's implementation. What I have pointed out is that it works
in NetBSD quite well, and that the effort to make it work in FreeBSD
has so far been laughable.
[Non-sequiturs omitted.]
Unlike Chris, those changes were from NetBSD and you offered them
to FreeBSD afterwards.
So what? The point is that I have explicitly donated work to
FreeBSD. You cannot honestly say you have donated work to NetBSD.
That was the question at hand.
You don't happen to mention the recent work you've done in
*obtaining* FreeBSD code.
There's no question I've looked at a number of recent changes in
FreeBSD, and other than a few typos that were corrected, I've found
nothing worthwhile. If you were to enumerate the things you've taken
from NetBSD recently you'd it's quite a lot of code. (`you' ==
`FreeBSD')
Here's a questions I'd like to pose. Do all the people who donate
their code to NetBSD realize that the only way that the general
public can see their code is after you've hacked and slashed it up?
People who donate code have to realize that their code will be changed
if necessary to fit in our tree. If they don't like this, they don't
have to donate it. That's not unusual or unreasonable. And the term
`hacked and slashed' is a derogatory term implying that my changes are
misguided. They certainly are not.
[More non-sequiturs omitted.]
That's okay, I don't find my name anywhere in the ptrace code I
wrote.
REALITY CHECK, Sean:
----------------------------
revision 1.47
date: 1993/09/05 03:54:11; author: sef; state: Exp; lines: +112 -1
branches: 1.47.2;
Yet more of the ptrace() reorg; now ptrace_setregs() and ptrace_getregs()
are present, along with PT_GETREGS and PT_SETREGS ptrace commands.
----------------------------
revision 1.45
date: 1993/09/04 05:32:18; author: cgd; state: Exp; lines: +39 -1
Please. You complained that you were not attributed in the code.
I pointed out that I wasn't, either, for my ptrace changes.
I pointed out that, for all the files that did not have your name in
the copyright in the freebsd version of yp, there was a comment in the
CVS file saying that it was imported from netbsd, where someone could
go look more closely (well, they could have, but that's closed now,
isn't it?). The only place I am given attribution for my ptrace
changes is in the CVS file, and that one update cgd posted.
>Here's the significant portions of the logs:
See? Yes, it's in the logs. But you folks distributed my code without
making sure I had proper attribution in the code. And I don't really care.
But I got even less attribution than you did. Yes you complain. And now
you're jumping up to defend yourself. After complaining about the freebsd
folks, who did just as much as you did.
>No, it has not stopped us from distributing it. Since you commited it to
>the tree, why should we not use it? By mailing it to Chris in the first
>place you explicitly gave us permission to use it.
Wrong. Absolutely wrong. It might be argued that I implicitly gave
permission (and that was, in fact, my intent), but nowhere did I say,
"Here is this code which you may now distribute."
I do not (often) lie. It is a personal matter. I no longer will deal with
you under any circumstances.
In article <CGD.93No...@eden.CS.Berkeley.EDU> c...@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes:
>sure, if you pick up -current *EVERY NIGHT* occasionally you'll lose, but:
> we've had perfectly working shared libs running for going
> on 2 weeks; they still don't have it right. We have
> shared XFree86. They have linker problems.
Leave us the hell OUT of this ego-bashing bullshit. Especially when
you are posting either misinformation or lies (I don't know if you are
aware of the facts, so I won't come straight out an accuse you of lying).
NetBSD shared libraries for XFree86 do NOT work. At least, they don't
work for anything built with libXt, which is, oh, about 90% of the
applications. There have been at least 3 different attempts to get
shared libraries working right, but it's not there yet.
>
>chris
>--
>chris g. demetriou c...@cs.berkeley.edu
>
> smarter than your average clam.
Posts like this make me think jmo...@netcom.com may be right, heaven forbid.
I wonder why you people feel the need to try to outdo each other all the
time. Pick a niche and stick to it. Or get together. For all of the
differences over the last few months, there are no serious bad feelings
between XFree86 and XS3 (in fact, Amancio and I talked on the phone for
a while just his past week). If we can do it, why the hell can't you?
You ALL look absolutely rediculous. With the total anarchy of Linux,
and the alternate insanity of BSD-du-jour, I'll just stick to my
old-fashioned, expensive, but QUIET commercial operating system.
--
David Wexelblat <dw...@aib.com> (703) 430-9247 Fax: (703) 450-4560
AIB Software, Inc., 46030 Manekin Plaza, Suite 160, Dulles, VA 20166
Formerly Virtual Technologies, Inc.
Mail regarding XFree86 should be sent to <xfr...@physics.su.oz.au>
"Ooh, are you feelin' satisfied? Come on, let us give your mind a ride."
-- Boston, "Feelin' Satisfied"
need. Maybe I should post Jordan's .bash_history from sun-lamp. (In
fact, I think I will. He left it world-readable, after all.)
Hi Chuck! Congradulations! You've somehow (and I did not think it
possible) managed to top *yourself* for overall obnoxious, rude and
purile behaviour! Bravo! Well done! If there was some sort of World
Asshole Federation, as there is for wrestlers, I most certainly
consider you the undisputed `Hulk Hogan' of it.
Why does this upset you? If you make your code available to people and
say "Hey, come play with our neat new stuff", you have no right whatsoever
to get all up-in-arms if people actuall DO. If you don't want it released
until it's done, then don't release it. Works for XFree86.
If you don't want people taking your FreeWare and doing stuff with it,
you should get out of the game. There are people making money off of
our work with XFree86; some of them give us credit, some don't. Doesn't
bother us that they use it (although the lack of credit is a bit annoying).
We released it so people can do whatever they want with it. We don't
allow early release of stuff, because we want to release it when we're
ready.
You can't walk both sides of the line, Chris. Either put the code out
there and SHUT UP when other people use it. Or don't release it.
>
>chris
>--
>chris g. demetriou c...@cs.berkeley.edu
>
> smarter than your average clam.
--
Just curious - how old are you? Planning to reach puberty this decade, I hope.
>
>Also, i'd be more inclined to believe your argument if the chronology
>were what you claimed. Jordan's note was posted to .announce at:
>13 Nov 1993 22:31:38 -0800. CVS access on lamp for FreeBSD developers
>not working on the NetBSD source tree at 22:40 (-0800, 13 November).
>How do i know? well, i'm looking at the ctime of a file that i chmodded
>when their access went away. You can't call it a response if it happens
>before what it's responding to. "cause and effect; logic 101."
>
>Note that people working on FreeBSD who *are* working on NetBSD
>did not have their access to NetBSD's CVS tree denied. Only those
>who are doing no work on NetBSD cannot access our CVS tree.
>Therefore, you can't claim that we're kicking people out of our
>tree because they work with (or even mostly with) FreeBSD; that's
>just not true. If they're not working on NetBSD, then they don't
>have access; plain and simple.
>
Well, people, bizarre as this sounds, I think this posting proves
Jesus Monroy right. Chris - you should step down as moderator. You
are not only biased, you are vindictive. I suppose I can expect
to have problems getting XFree86 stuff posted in the future now.
Man, you make me sick. For that matter, I'm pretty much sick of
ALL of this BSD-du-jour junk. You folks can't agree on ANYTHING,
can you? Why is it that XFree86 has to support 3 different console
driver APIs? And that there are still more around that aren't
supported (I think)? There WAS a task force that was going to try to
resolve all of this for us - to come up with a single common API
for the console driver. But your bloody egos couldn't even accomplish
that much - one subset of ioctl()s on one device.
>
>
>chris
>--
>chris g. demetriou c...@cs.berkeley.edu
>
> smarter than your average clam.
Yes, please do ask them how stable it is. Because all the discussion on
the XFree86 development list makes it pretty clear that libXt-based
programs DON'T WORK. Well, I think they can be made to work with some
really arcane changes to the libraries.
I wasn't aware that SunOS libraries were the ideal. Personally, I prefer
the SVR4 libraries. How much work is it to make an SVR4 library?
First compile with PIC, next link with '-G'. That's it. There are no
.sa files with SVR4 shared libraries.
I'll tell you, too - leave us the hell OUT of your religious war. We've
had shared-library SVR4 for over two years, so somehow I can't feel so
enthralled with your accomplishment.
NetBSD shared libraries for XFree86 do NOT work.
Dave, you are wrong. That is *all* I'm going to say on this bit.
>Now, normally, I try to stay out of this BSD-du-jour crap, but...
So do I, but I'd like to react to this one.
>NetBSD shared libraries for XFree86 do NOT work. At least, they don't
>work for anything built with libXt, which is, oh, about 90% of the
>applications. There have been at least 3 different attempts to get
>shared libraries working right, but it's not there yet.
Actually, I have been running shared libs with XFree 2.0 on NetBSD-current
for some days now, works like a charm. Yep, there were problems with
libXt in the beginning, but an update by Paul Kranenburg (great work!)
to ld & ld.so has fixed this. It really works, no separate shared data
libs too.. I've checked all clients that come with the stock XFree, they all
work (am typing this right now in X, while the machine has been up for
a day (simply because I switch it off every night :)), and compiling heavily
in X the last hours).
>and the alternate insanity of BSD-du-jour, I'll just stick to my
>old-fashioned, expensive, but QUIET commercial operating system.
Hmm, still, I'd rather pay nothing and have a bit of noise, than
pay $2000 for silence 8-)
But anyway: yeah, this is all getting to be a teeny weeny bit out of
hand, isn't it. RFD: comp.os.386bsd.flame ?
I wonder if this is a problem in free software: you want your code to be
free, but somehow you don't like other people taking it just like that
and making it part of their own stuff, without getting 'proper credit' (where
'proper credit' seems to be a hotly debated issue). Actually, I already
wondered how long this 'access to eachothers source-trees' thing
between Free/NetBSD was going to last, but it seems this has been answered
now.
Seems like *BSD has always suffered from disagreements from the start; it
started off with Bill Jolitz leaving the original BSDI group because
of differences with regards to commercialness. As far as I can remember,
at least, it's all getting a bit fuzzy now. Now, where were the days
when there was just a mailing list of people trying to make Net/2 work
on a 386, even before 386bsd 0.0 was out..
I'm a happy NetBSD-current user at the moment, and I'll probably stick
to that for a while, since it is the most interesting thing for me
to work with, and interaction through the mailing lists on sun-lamp
and the daily updates works really well. I'll ignore all the FlameBSD/EgoBSD
stuff. Sure, I have my opinions on this, but I think there's a hole in my
asbestos suit, so I don't really dare say much.. Though it makes some
interesting reading on a rainy, stormy sunday night *grin*
Peace and love (or anything that comes close to it),
- Frank
--
+----------------------------------------------------------------------------+
| I am not sure what a .signature is for, but my mom told me to make one. |
| Frank van der Linden, vdli...@fwi.uva.nl |
+----------------------------------------------------------------------------+
Because all the discussion on the XFree86 development list makes it
pretty clear that libXt-based programs DON'T WORK.
Dave, PLEASE STOP STATING THAT. IT IS WRONG. I have personally run X
applications using a shared Xt, and they work just fine. Admittedly,
the current linker is slightly hacked to make this work, but it does
in fact work.
First compile with PIC, next link with '-G'. That's it. There are
no .sa files with SVR4 shared libraries.
And if you had bothered to check your facts, you'd find that is
exactly what is being worked on.
This entire subthread is ridiculous. The point of the original
statement regarding shared libraries was that the FreeBSD people tried
to pick them up without any real understanding of what was going on,
and had enormous troubles. The hack they've done to ld.so to make it
work at all without random segmentation faults on startup (namely, the
stack pointer comparison) will very likely cause a binary
incompatibility if they ever want to enlarge the kernel's virtual
address space, unless they do further kluging in the kernel.
The fact that they do not think about such issues until it bites them
in the ass is one of the reasons I don't want them having unlimited
write access to the source I use.
Of course, there is always the chance they will read this and go fix
it now.
Chris - you should step down as moderator. You are not only
biased, you are vindictive. I suppose I can expect to have
problems getting XFree86 stuff posted in the future now.
This is just plain ridiculous, Dave. Even ignoring your snide
remarks, you have in no way shown that Chris is not doing his job as
moderator of .announce.
There WAS a task force that was going to try to resolve all of this
for us - to come up with a single common API for the console
driver.
And once again, you show quite clearly that you have not bothered to
check your facts. I was on the console mailing list; I know what
happened. They got stuck in the rathole of trying to design the
ultimate driver and never actually produced a usable spec or code to
match.
This is a lie. We started discussing our removal from the sun-lamp
source/CVS access at 12-Nov-1993, 22:41:29. A day before Jordon sent
the document to you. The reason that the day/time is handy is because
I had sent mail out to the various people who had their access removed
to inform them that this had happend, and that's the date on the email.
We discussed the issue for about half a day and agreed that Jordon
should send out the announcement.
It was was because of our removal that percipitated the merge is
dead "announcement".
-DG
Maybe not to you, but I no longer have any confidence whatsoever that
he is capable of just posting the goddam things without censoring things
that don't fit the NetBSD religion.
>
> There WAS a task force that was going to try to resolve all of this
> for us - to come up with a single common API for the console
> driver.
>
>And once again, you show quite clearly that you have not bothered to
>check your facts. I was on the console mailing list; I know what
>happened. They got stuck in the rathole of trying to design the
>ultimate driver and never actually produced a usable spec or code to
>match.
>
Where is this fact in any way in opposition to my statement? The task
force was chartered to solve the X API problem - I know; the task force
came out of my flaming this stupidity before. The fact that nothing
got done because it all dissolved in irrelvencies just goes to PROVE
my point about the inability to develop a single API because of
egos.
When the hell did we get on a first-name basis? You have it working
now? Fine. I don't see you contributing anything to XFree86. The
FreeBSD folks have spent a good deal of their time and effort on
XFree86. From which YOU benefit. I don't recall ANY core NetBSD
folks contributing to XFree86. Yet you use our work, and drag our
name into your ego battle. Those who live in glass houses...
>
> First compile with PIC, next link with '-G'. That's it. There are
> no .sa files with SVR4 shared libraries.
>
>And if you had bothered to check your facts, you'd find that is
>exactly what is being worked on.
>
Bully for you. I have it now. Hence, by your analogy with FreeBSD,
since I have it now, and you are still hacking on it, I'm better than
you, right?
>
>This entire subthread is ridiculous. The point of the original
>statement regarding shared libraries was that the FreeBSD people tried
>to pick them up without any real understanding of what was going on,
>and had enormous troubles. The hack they've done to ld.so to make it
>work at all without random segmentation faults on startup (namely, the
>stack pointer comparison) will very likely cause a binary
>incompatibility if they ever want to enlarge the kernel's virtual
>address space, unless they do further kluging in the kernel.
It's not ridiculous. You're trying to state that some people can do
certain things with your repudedly-free code, and other can't. That's
silly. There are commercial Unix vendors that ship XFree86 with their
Unix, with no acknowlegement to us. There are others who ship it
with acknowledgement. There are some who use our code in their products,
who don't acknowledge us. Still others who use our code and do acknowledge
us. Do you see us getting all hot and bothered about this? No. Because
when we say our released code is free, we mean that. Anyone can do anything
they like with it.
>
>The fact that they do not think about such issues until it bites them
>in the ass is one of the reasons I don't want them having unlimited
>write access to the source I use.
>
That's not the issue. What you've been bitching about is the fact that
they pick up NetBSD-current and use it. You can't have it both ways.
>Of course, there is always the chance they will read this and go fix
>it now.
>
For which you get a gold star.
I would think that the NetBSD community, what with trying to support a
huge number of architectures, would have learned some of the lessons
that we've learned, trying to support XFree86 on a dozen or so different
OSs. Do you think we would have gotten where we are today if we had
been as petty and shallow as you all appear to be? We've been involved
in commercial-OS ABI specification; have our code in commercial products,
have our product shipped with commercial OSs, etc, etc. We have obtained
a high degree of real-world acceptance. And you're down here in your
tiny little world while Linux anarchy winds up with 20-50x more users
than all the BSD-du-jour put together. It doesn't matter if you've
got the best product around. The best doesn't always win. There's a
lot more to it than technical excellence. It's mass acceptance that
wins the wars. Look at MS-DOS, NFS, even X, for that matter. There have
been a million things technically better. These products rule due to
concensus, not brilliance.
I don't see you contributing anything to XFree86.
Funny thing, that. I don't even *use* XFree86, except for testing. I
care about it only as much as I want users of NetBSD to be able to use
it. So far someone else has been willing to do that work, and I'm all
for it; I do my share in other places.
[...] and drag our name [...]
You brought yourself into this. The passing mention to XFree86 hardly
deserved even a glance by you, much less your ill-founded half-truths
about code you clearly don't know much (if anything) about.
Bully for you. I have it now. Hence, by your analogy with
FreeBSD, since I have it now, and you are still hacking on it, I'm
better than you, right?
You're just full of non-sequiturs, eh? Perhaps SVR4's shared library
implementation is currently better; perhaps not. I don't really care,
as I can't get the source for any reasonable sum of money. But that,
and everything else you've brought up, is hardly even relevant to the
original thread.
You're trying to state that some people can do certain things with
your repudedly-free code, and other can't.
You are quite confused. We have not, in any way, tried to prevent the
FreeBSD group from getting `our' code in the same way as anyone else
can. I suggest you read that statement as many times as necessary
until you understand it.
What we have done is state, quite clearly, that we cannot afford to
support the use of sun-lamp by people not contributing to the
development of NetBSD. If you find this unreasonable, then you are
welcome to donate more machinery.
Please. You complained that you were not attributed in the code.
I pointed out that I wasn't, either, for my ptrace changes.
Yes, and that is your own fault. MY, YOU'RE SOUR.
I pointed out that, for all the files that did not have your name in
the copyright in the freebsd version of yp, there was a comment in the
CVS file saying that it was imported from netbsd, where someone could
go look more closely (well, they could have, but that's closed now,
isn't it?). The only place I am given attribution for my ptrace
changes is in the CVS file, and that one update cgd posted.
I explicitely sent mail to Paul Richards telling him to put my name
in the commit message. And he didn't.
You're bitching about yourself not getting credit (when it was yourself
who failed to give yourself credit), yet, when I complain about someone
not giving me credit (at my and other people's prodding that I should
be given credit) -- you claim that I'm doing anything wrong?
>Here's the significant portions of the logs:
See? Yes, it's in the logs. But you folks distributed my code without
making sure I had proper attribution in the code. And I don't really care.
But I got even less attribution than you did. Yes you complain. And now
you're jumping up to defend yourself. After complaining about the freebsd
folks, who did just as much as you did.
You failed to give yourself credit.
You're stupid to not have given yourself credit.
>No, it has not stopped us from distributing it. Since you commited it to
>the tree, why should we not use it? By mailing it to Chris in the first
>place you explicitly gave us permission to use it.
Wrong. Absolutely wrong. It might be argued that I implicitly gave
permission (and that was, in fact, my intent), but nowhere did I say,
"Here is this code which you may now distribute."
I suspect Chris will post some mail about this, to show that you are
lying.
Sean, I still have not received mail from you asking that I correct
YOUR MISTAKE of not giving yourself credit.
It is not a personal matter: you attempted to slander the NetBSD
effort, and used lies to make your (incorrect) point.
Of course, I've seen this before.
Zoom -- David, you are wrong. They work just fine.
i don't, Dave.
a CVS tree is not "released software." I'm sure that you can understand
that it's not up for FTP, and what not?
We release code. We encourage people to use it.
We don't give people access to (unreleased) revision logs, et al.
Plain and simple.
cgd
Why does this upset you? If you make your code available to people and
say "Hey, come play with our neat new stuff", you have no right whatsoever
to get all up-in-arms if people actuall DO. If you don't want it released
until it's done, then don't release it. Works for XFree86.
David, I look forward to the day that a ``XFree86-current'' is sup'able
nightly from some machine. Until then you cannot compare XFree86's
open-ness with how open NetBSD is being. (I wonder how many active
NetBSD-current users there are...)
[regarding Xfree86]
We don't allow early release of stuff, because we want to release
it when we're ready.
Guess what! That's exactly what we are trying to stop here!
The problem is that FreeBSD people have been taking early releases of
NetBSD ``stuff''.
We want to release the code when we are ready, not when FreeBSD people
feel it's time for them to ship it on a CD. Thanks for explaining that
XFree86 also doesn't want unreleased code distributed.
Note that there wasn't even one NetBSD member on the "task force"
(a mailing list managed by Julian, if I remember.)
I had opinions, but never expressed them (except to say that NetBSD
supports the excellent work Hellmuth has done with pcvt, which will
very soon have the same X ioctl()'s that syscons has.)
You must be talking about someone else's ego here, not Chris's or
Charles, or mine.
What ever you say, Dave.
The the first "wrong fact" in your post is that 11/12 22:41 is
"a day" before jordan sent the post to .announce; it showed up at
11/13 14:18:
Nov 13 14:18:28 agate sendmail[14551]: OAA14549: from=<ne...@x400.ieunet.ie>, size=4354, class=0, pri=64354, nrcpts=2, msgid=<JKH.93No...@whisker.lotus.ie>, proto=SMTP, relay=0...@rodan.UU.NET [153.39.128.10]
Nov 13 14:18:29 agate sendmail[14551]: OAA14549: to=c...@postgres.berkeley.edu, ctladdr=<ne...@x400.ieunet.ie>, delay=00:00:03, mailer=tcpld, relay=nobozo.cs.berkeley.edu. (128.32.149.115), stat=Sent (OAA24938 Message accepted for delivery)
that's not "a day", at least not on this planet...
I could go on, but i've got software to develop.
We don't have an XFree86-current, and never will. Not one that is
publically-accessible. The point is that you do, and now you're objecting
to FreeBSD using it.
>
> [regarding Xfree86]
> We don't allow early release of stuff, because we want to release
> it when we're ready.
>
>Guess what! That's exactly what we are trying to stop here!
>
>The problem is that FreeBSD people have been taking early releases of
>NetBSD ``stuff''.
>
>We want to release the code when we are ready, not when FreeBSD people
>feel it's time for them to ship it on a CD. Thanks for explaining that
>XFree86 also doesn't want unreleased code distributed.
>
Then stop NetBSD-current.
Actually, I'm talking about the entire BSD-du-jour (for Intel) development
community, which could not come to consensus on something so simple.
I'm inches away from installing Linux and completely throwing away *any*
reference to ANY of the *bsd's on my disks...
I'm sad to say that I feel the Linux people are more emotionally mature
and controlled than the important members of the *BSD's...
This is a sad day for me.
--
hpe...@novatel.ca | NovAtel Commnications Ltd.
hpe...@fsa.ca | <nothing I say matters anyway>
<NetBSD: A drinking group with a serious computing problem!>
[ stuff deleted ...]
>We don't give people access to (unreleased) revision logs, et al.
>
>
>Plain and simple.
Then _please_ do not insult our intelligence by selectively releasing these
very same logs in the mistaken belief that they reinforce your arguments. I
find this practice really low rent.
Larry
Ah, I love the smell of dirty laundry in the morning.
-jarle
----
"A little rudeness and disrespect can turn an otherwise meaningless
interaction into a battle of wills and provide drama to an otherwise
dull day."
-- Calvin
I'm really getting tired of the "[fillin your choice]BSD is better then
[!fillin your choice]BSD". I've tried *BOTH* os'es, and (for MY
PERSONAL preference) find FreeBSD better. This does NOT say that
FreeBSD is better than NetBSD or vice versa! It meerly says that
FOR MY USES I find FreeBSD better. BUT, if the current flames continue
I may be forced to upgrade my sun to Solaris 2.3 and buy Solaris for X86
for home (just to put the flame(s) behind). I'm not ready to do that
yet, but the flame wars are makeing it more and more viable (GOD, I can't
believe I'm actually thinking of going to SVR4 (shudder))).
I appreciate the work done by 1) the Jolitzes, 2) the NetBSD group AND
3) the FreeBSD group. It has allowed me to have ALMOST the same O/S
at home as at work (the work of the XFree86 group has been OUTSTANDING
and is GREATLY Appreciated, no matter WHAT the O/S it runs on!!!!!).
--
=======================================================================
Stephen F. Combs
GE Industry Sales & Services My Employer is in NO way
GE Drive Systems Responsible or Liable for
Network Services Any Opinions expressed by
1501 Roanoke Blvd. Myself.
Salem, VA 24153
Internet E-Mail: Com...@Salem.GE.COM
Novell via Internet: Comb...@Salem.GE.COM
=======================================================================
Just ignore it, people will eventually quiet down. Linux went through
the same kinds of growing pains, so it's not anything new. It is kind
of humorous though, just lay back, and watch both sides make buttheads
of themselves.
What you're missing is that it has been going on in email, and has
migrated out to usenet-land.
--
Jaye Mathisen, COE Systems Manager (406) 994-4780
410 Roberts Hall,Dept. of Computer Science
Montana State University,Bozeman MT 59717 os...@cs.montana.edu
Or is is Beavises?? Perhaps both should be renamed until this dies
down - one to BeavisBSD and the other to ButtheadBSD :-). If nothing else, a
temporary name change of this sort would provide an incentive for the two camps
to stop fighting with each other.
-Eric
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
--
Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: wi...@rwwa.COM
R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA
Speaking as a -current user: NetBSD-current is as "stable"[sef] as I want it
to be. While shared libraries were being hashed about during the past two
weeks, my NetBSD-current system was absolutely "stable"[sef]: because I had
absolutely no time to FTP changes. However, during that time, NetBSD-current
was also "stable"[jfw] in that it entirely failed to crash despite my continual
use of it as a news-, mail-, and mini-ethernet-hub. Many of the changes that
render NetBSD-current "unstable"[sef] have been essential to the improvement
in "stability"[jfw]; others of them (like the shared library stuff) have given
me concern about "stability"[jfw] so I held off until people appeared to agree
that they were "stable"[everyone but sef], then picked them up (much to the
rejoicing of my /usr partition). Frankly, I'm happier with my definition of
"stability"; when my system crashes, I don't really care how many changes
were required to make it crash, nor am I comforted that keeping it from
crashing would require a number of other changes; I just look at the blinking
cursor and the legend "Hit any key to reboot" and mutter unprintables.
>(a round of applause to Paul Kranenburg for his sunos-compatible shared
>library code!)
In particular, especial thanks to Paul Kranenburg for working with *both*
FreeBSD and NetBSD, despite the apparent cantankerousness of some of each.
I was personally dismayed to see the recent article crowing about FreeBSD
finally having shared libraries, in an article that made it appear that this
was a FreeBSD-specific development; I was also dismayed to see another recent
article claiming that "unlike FreeBSD", NetBSD's shared libraries have been
"working perfectly for two weeks", which (I think) overstated the case by quite
a bit.
Here HERE. The best software comes from frequent and fervent cross
pollination. I for one would like to see the cross pollination
continue and the bickering, name call, back biting, etc to stop.
I think I can sum up the difference between *BSD and Linux as follows:
"In Linux, new users get flamed for asking questions in the newsgroups
(or heaven forfend, the wrong newsgroup). In *BSD the principals
flame each other."[*]
Can we please drop the macho ego bullshit? It detracts from the
quality of both FreeBSD and NetBSD. Both are fine "products" and have
their strengths and weeknesses. Both have a problem they are trying
to solve. Can we focus all of this bashing back into the code rather
than flaming in public? Please?
After all, isn't that what all of this is about? Or am I hopelessly
naive?
Warner
--
Warner Losh i...@boulder.parcplace.COM ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
In article <CGD.93No...@eden.CS.Berkeley.EDU> c...@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes:
>NNTP-Posting-Host: eden.cs.berkeley.edu
> this is being posted for exactly one reason: "myth dispulsion."
>I'm sick of seeing this rumor; it's simply *NOT TRUE*. doubts? ask
>curren...@sun-lamp.cs.berkeley.edu, or post news asking the many
>people who had 80+ and 100+ day uptimes under 0.8 and 0.9 to send
>you some mail...
> we've had perfectly working shared libs running for going
> on 2 weeks; they still don't have it right. We have
> shared XFree86. They have linker problems.
> we can still reliably run on 4M machines; they can't --
> they claim it's a bug from Net/2, but i've done serious
> development on 4M machines from 386BSD 0.0 day one (because
> the original machine i had was a 386 with 4M RAM), and never
> been bitten by it.
> we have a real buffer cache, no longer done out of kernel
> malloc memory. this leads to more speed, and greater
> reliability (because there's less kernel map fragmentation).
> we've fixed *so* many machine-dependencies and chunks of
> bogus code it's unbelievable; many of those areas they've
> not *touched*.
> we've fixed *so* many bugs that they've not -- and that
> they don't even know are there. we've found them
> by stress-testing the hell out of NetBSD; they've
> not even come close to doing that.
Chris what is this, a game of "my os is better then yours na na na na!"
we have been friends for a long time, even though I do not run in the same
circles much anymore, I still concider you a close, trusted friend. (I hope
you do not take this post personaly)
thus I feel that I should point out that your post echos of a US .vs. THEM
attitude; This is *BAD*; even if you do not feel this way, you are projecting
this attitude to others.
I am very suprized that you would allow yourself to loose sight of the
big picture. neather of you had a better or worse OS; both trees
need alot of work and you are not gonna get any done by flaming!
(remember nomatter who you are there is *always* someone better)
Now as for the big picture. I aggree that there should be a merger; I do
not forese this anytime soon; but it would be nice for all developers
and users and I do not think there is a person among us that would
dissagree with that. (think of now nice it would have been it AT&T
had worked with those doing BSD, think of how much work could have
been saved? [but I degress]).
Chris, Jordan (NetBSD, FreeBSD, Lynix people and followers) just stop for
now, get back to your code and keep those patches flowing and source trees
growing, any maybe some day you will merge.
STOP PISSING on each other cause you are just pissing other off.
--
---------------
Pete Shipley:
email: shi...@berkeley.edu Flames: cima...@postgres.berkeley.edu
Spelling corections: /dev/null Quote: "Anger is an energy"
[ ... ]
> There WAS a task force that was going to try to resolve all of this
> for us - to come up with a single common API for the console
> driver.
>
>And once again, you show quite clearly that you have not bothered to
>check your facts. I was on the console mailing list; I know what
>happened. They got stuck in the rathole of trying to design the
>ultimate driver and never actually produced a usable spec or code to
>match.
Actually, the reason this petered out was because several things happened
simultaneously:
1) Julian went back to Australia, losing net access for a long time;
this is important because the mailing list was both maintained
and moderated by Julian, meaning that we could send things, but
they would bounce. Even if they didn't, they would have ended
up in an inbox somewhere.
2) I lost the ability to contribute source code and designs to the
project right after sending out my LKM code to both BSD groups
when the company I worked for bought another company and put
me in a position where it could potentially be a interpreted as
a conflict of interest to continue.
3) The ref.tfs.com site, without Julian, was shut down, and there
was no longer a central site for beta code to be exchanged (an
exchange of designs and code in the newsgroups was out of the
question; we did not want them to be considered patches and we
wanted to ensure a higher level of discussion than could occur
in a newsgroup).
All design documents are available; the architecture of the design was
completed (with compromises by both myself and Dr. Holger Veit -- we
were both very interested in internationalization and localization to
native language, but were overruled -- yes, we *voted* and *accepted*
the outcome of the *vote*); it is available to interested parties.
Preliminary work had been done on API specification (full function
prototypes), and the last act of my involvement was the release of the
LKM beta code, which I perceived as core technology to either of the
two major design camps. Even though we had agreed on an architecture,
I had begun the LKM code as part of getting shared libraries up using
alternate a.out formats, and pushed that code ahead of the shared library
work -- much to my later disdain -- to provide the core console driver
technology.
Admittedly, there were a number of radical suggestions (mostly by
myself and Dr. Veit) regarding moving all of the Device Dependent X
code into a seperate card driver module to get around the kernel
debugger, console switching, Unicode display, and DOS emulation
issues, but these never superceded going forward on the main issue,
which was a first revision common X interface and support for
emulation "personailities".
A "rathole" is an unfair characterization.
Terry Lambert
te...@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Actually, they aren't -- the SunOS shared library code was made available
back on ref.tfs.com; unfortunately, it had come by way of the BSD4.4
sources, and was never officially donated to the 386BSD project by Sun
seperately from their donation to UCB. Since the lawsuit had made the
BSD4.4 sources unusable without a seperate donation, the shared library
code I had working (I made the finishing touches to some other peoples
work with PIC code in the GCC compiler and handled the a.out and the
linker and symbol space changes) back in February became unusable by
virtue of being legally suspect. My May version (a total "clean room"
rewrite) was too late to make the cutoff on potential conflict of
interest.
The main differences in the SVR4 code from the Sun code is the file
format; the lack of seperate ".so/.sa" files in SVR4 is attributable
to the fact that the SVR4 object file format allows for the storage
of multiple named objects in the executable, and Sun's object format
did not.
Actually, using symbol tagging, it is possible to put SunOS style
shared libraries into a single file, as long as it is possible to
distinguish between externally accessable and local (static) data;
I believe this is a work in progress with the current implementation.
Shared libraries are another example of a result of moderated discussion
(again, Julian was the moderator), although I am unsure of how much of
this influenced Paul, if it influenced him.
>Note that there wasn't even one NetBSD member on the "task force"
>(a mailing list managed by Julian, if I remember.)
1) Charles Hannum participated on that list.
2) The list was moderated by Julian.
3) Membership on the list was not restricted; anyone could choose
to participate; an announcement was made on comp.unix.bsd.
4) Said announcement is available via anonymous ftp from
minnie.cs.adfa.oz.au [131.236.20.70], in the directory
bsdnews, an archive of comp.unix.bsd and comp.os.386bsd.*.
I was personally dismayed to see the recent article crowing about FreeBSD
finally having shared libraries, in an article that made it appear that this
was a FreeBSD-specific development; I was also dismayed to see another recent
I'm sorry? I think that's my post you're talking about, and all I did
was have the temerity to state that we'd finally gotten shared
libraries in fairly good shape. I just re-read it, and nowhere can I
see that it in any way intimated that this was a FreeBSD specific
state of affairs. I cannot speak on behalf of NetBSD, so the only
developments I'm at all qualified to discuss are those in FreeBSD.
Please - things are bad enough at the moment without reading negative
things into even my *positive* posts! :)
Jordan
--
(Jordan K. Hubbard) j...@violet.berkeley.edu, j...@al.org, j...@whisker.lotus.ie
---
Todd Pfaff \ Internet: to...@flex.eng.mcmaster.ca
Dept. of Mechanical Engineering \ Voice: (905) 525-9140 x22902
McMaster University \ FAX: (905) 572-7944
Hamilton, Ontario, CANADA L8S 4L7 \
I agree completely. I wish I had killed this thread. The behaviour
of these people reminds me of kindergarten.
*sigh*
If you have any sense of what is good for *BSD try to stop
showing your aggressions in public.
--
-- Lennart Augustsson
[This signature is intentionally left blank.]