Skip site navigation (1)Skip section navigation (2) 
Date:      Fri, 4 May 2001 17:30:28 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        jkh@osd.bsdi.com (Jordan Hubbard)
Cc:        tlambert@primenet.com, jessemonroy@email.com, jessem@livecam.com, chat@FreeBSD.ORG
Subject:   Re: Concern over ftp.freebsd.org
Message-ID:  <200105041730.KAA15084@usr08.primenet.com>
In-Reply-To: <20010504003330A.jkh@osd.bsdi.com> from "Jordan Hubbard" at May 04, 2001 12:33:30 AM
next in thread | previous in thread | raw e-mail | index | archive | help 
] > I think this is the crux of things; if you had communicated
] > that information, that way, I think the outage itself would
] > have been a tempest in a teacup, and widely ignored while
] 
] Perhaps, though I also can't help but notice that none of this
] occurred until *after* I posted something to announce.  "Damned if you
] do, damned if you don't" is a phrase which comes to mind.

Not to argue the point, but I notices this 2 days before, was
going to say something about it, but had more important things
demanding my attention.  I also got the SVBUG agenda announcement
around a full 24 hours before your posting.  People noticed the
problem, and were talking about it non-openly well beforehand.


] > [1]
] > The "tools" directory is one big issue.  It's not self-hosted
] > on FreeBSD, and the copyright on the executables isn't clear,
] 
] Actually, it's just a bunch of DOS stuff we've been copying around
] from CD to CD without any clear idea as to whether it's even useful
] anymore.  The only piece which was software that can't be found
] elsewhere (as even the most cursory netsearch will reveal) is Walnut
] Creek CDROM's "view" program and we don't use that anymore at all.  It
] can be deleted and the rest is just freeware from the Simtel and CICA
] archives.  As to it not being "simple" to tell if it's
] redistributable, I'd have to disagree since there are READMEs which
] come with most of the stuff in there and, again, even a simple
] netsearch will show you that things like OSBS and fdwrite are freely
] available.  Do a little legwork if the contents of tools are really
] that much of interest.

I think that the issue of compilation copyright, and wheher or not
the executables themselves fall under performance copyright is the
main sticking point.  It may be that I'm permitted to just copy
everything (except the "view" program) verbatim, but to be sure,
I'd have to engage a lawyer, or just punt and fire up a DOS box
and rebuild the binaries myself.  The lack of self-hosting is just
an annoying side issue.


] > The build process itself requires a number of files which have
] > recently become unavailable; they are not all present on the
] 
] This is only for the documentation build and you can easily turn it
] off, as the snapshot servers have done for a long time.

If I turn it off, then what I'm building is not a release.


] Also, this is (again) a ports collection issue and should be taken
] up with the appropriate maintainers.

I still think this is a build issue, not a ports issue; it speaks
to repeatability.  You argue that the tools not building correctly
is a ports issue; I'm arguing that even if the ports were corrected,
there's no guarantee that the files needed to build them will
persist over time.

To put it another way, I think that if under-water archeologists
salvage a PC with a CVS mirror on it 50 years from now, that it
should be possible to "make release" on the thing, and have it
work.  I guess I'm asking that the build bits be archived with
the rest of the FreeBSD sources, and pulled down as part of the
process of mirroring a full source tree.


] > The build process is rather "CDROM as it is"-centric.  This isn't
] 
] Of course it is.  It's aimed at doing one thing and one thing only.
] If you want something more general purpose, you know where your editor
] is. :) I would also argue that your recent KERNCONF submission is
] perhaps a micro step in the right direction but far from something
] which really tackles this issue.

It certainly doesn't; but like most submissions, it's useful to
me, and it's apparent that it's at least useful to 6 or so others,
like NEWCARD, etc., which makes it 700% more useful than it is
without the change.  8-).

Ideally, I'd revamp the build so that a change to one file ended
up doing the right thing, and rebuilding only dependent files,
and then replace the entire install process, but I can't do
that unless there's money in it for me (probably a lot of money),
and I can find a drug that will replace sleeping... or it somehow
ended up that it was my full time job, and I had free reign of
terror over the tree for the transition.


] > This is not to be spiteful, but what would happen if the holders of
] > these things suddenly became adversarial to the project?
] 
] We (core) already discussed that way back when the WC filing
] occurred. In the worst case, we simply change our name and the
] trademark holder is left holding an empty bag.  A painful transition
] to be sure, but even the threat of doing that should generally be
] enough to avoid going to such an adversarial extreme.  It's truly the
] project which holds the cards here, not some PTO registrant.

I was more worried about what happens if the legal entity holding
the thing dissolves without assigning it to the project, and what
happens to the project.

Clearly there's always the "change the name" option, but that seems
to have been enough to prevent "BrettBSD"; it's not like you change
the name in /usr/src/Makefile.inc1, and you're done.

I also think that the success of a follow-on project would be minimal,
comparatively: the project would lose a _lot_ over something like
that.  Right now, we have to manually correct the origins of the
FreeBSD project, or people think that it's something that started
after Linux as a "me too!" type thing.  The same barriers to "BrettBSD"
would be there for "TheOperatingSystemFormerlyKnownAsFreeBSD".


] > This concern is amplified by the recent problems with the PicoBSD
] > builds, using 4.3-RELEASE.
] 
] Which has nothing to do with WindRiver.  If the people doing PicoBSD
] wish to put more time into it, and I'm sure they'd welcome your own
] contributions, that remains entirely independent of this issue.

I understand that; but this is the first time in a long time it
has been broken following a release.  It's the appearance of the
thing.

I'm sure that if Windriver had a big market in PCMCIA drivers, we'd
have some people placing blame for the 4.3 PCMCIA card insertion
freezes on their doorstep, as an anticompetitive practice.

I think that, as ridiculous as that seems, care needs to be taken
to preclude such conclusions, and to deprive skeptics of their
ammunition.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105041730.KAA15084>