Date: Mon, 6 Nov 2000 22:20:48 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jkh@winston.osd.bsdi.com (Jordan Hubbard) Cc: tlambert@primenet.com (Terry Lambert), ignacioc@avantel.net (Ignacio Cristerna), freebsd-advocacy@FreeBSD.ORG Subject: Re: Installation: what to (not) do about it Message-ID: <200011062220.PAA22673@usr08.primenet.com> In-Reply-To: <24441.973306588@winston.osd.bsdi.com> from "Jordan Hubbard" at Nov 03, 2000 06:56:28 PM
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... Jordan's "white paper" on a new installer ... ] > And yet you jump in and say it was inadequate when you admit you > haven't even read it in detail. Hmmmmmm. FWIW, I do talk about > ugrades in the paper and how to make them reversible and less > potentially destructive since a lot of the barriers to a successful > upgrade experience come from justifiable user fears about what happens > if the process goes wrong on a production system. The software isn't severable, and it's not layered. If the NetBSD rc files go in, then you will have a talking point. This reminds me of the IBCS2 compatability: it's more than just an issue of having a partial answer; it's not useful to think that all that is needed is a new install. Without the ability to drop new code in painlessly, all that will have happened is a rearrangement of deck chairs. The big turning point will be when you can drop in a replacement for sendmail/qmail/postfix/whatever, easily, quickly, and most important of all, reversibly. > > I've tried doing code for FreeBSD before; other than trivial > > things that it takes zero brains to understand, most of my > > stuff hasn't made it past the commit filters, who insist on > > being educated about everything, and appear to be unwilling to > > go to college to get that education. > > This explanation just doesn't cut it, Terry, not did it cut it the > last 5 or so times you used it. Many people seem to get past the > "commit filters" just fine and perhaps the real answer is that they > have a degree of perserverance and committment to achiving their goals > that you simply lack. But we'll discuss that more in detail below. Oh horse puckey. People dislike change that they don't understand, and it doesn't matter that the code works. A number of very bright people have been chased away from FreeBSD over the years due to ego being more important to some people than good code. The term for this is "AI" -- Artificial Importance. John Dyson is one example, and Matt Dillon was almost another, when he was producing code faster than people could pee on it to make it smell like them. The list is actually fairly long. > You seem to have this "thing" about the softupdates code which is > entirely out of proportion to the actual reality. The reality is that > Kirk allowed us to incorporate the code into FreeBSD and which meant > that people could read it and hack on it, a significant part of those > fundamenal goals I mentioned. The code wasn't initially free for > "commercial use", though CD releases and a fairly broad spectrum of > "commercial" activities were in fact allowed, but it was a bolt-on > option which any user could freely use on a personal basis and many > did. Those who didn't want to comply with the selective-use license > simply didn't enable softupdates and their overall "FreeBSD > experience" was not adversely impacted by this. That's why we felt > that the trade-off, and one we did indeed debate rather seriously > first, was worth it. The restrictive license was a requirement placed there by Whistle when they funded the developement under FreeBSD. It was intended to get rid of the UPS in the InterJet II. I was the one who pushed for the technology. Kirk was contractually obligated to an exclusive license for a period of time, to let Whistle recoup its R&D investment, before opening up the code. > What you were describing was a body of code for which the source code > would NOT be available and to which people could not make general > improvements. Not only that, but the overall "FreeBSD experience" > would be substantially different for people using that installer from > the point of their very first contact with the OS, a very different > kettle of fish than soft updates which are essentially invisible to > the naked eye (for 99.9% of what pass for "average users"). It is a > complete mystery to me how you can fail to see the difference or even > draw a parallel between the two technologies with a straight face. I find it amazing that you call for a new installer, and then cry foul when it doesn't appear on your terms. I explicitly stated that the person wanting to do the work would release the source after a period of one year, during which time they would recoup their investment by being the sole source for a FreeBSD with the improved installer. I seem to remember that FreeBSD started out with proprietary bits in its installer. > > I fully understand the desire to link the installer source code to > > use of the FreeBSD trademark, but I think that desire is contrary > > to the long term best interests of FreeBSD. > > The Caldera installer, which many people have drawn parallels to, is > completely free and can be ftp'd from their site. Judging by the > extreme number of similarities in the Red Hat installer, it also > appears likely that at least one other major Linux vendor did exactly > that. I therefore find it difficult to swallow your argument that an > insistence on it being freely available is something which would be an > absolute barrier to entry for any next-generation graphical installer. > The empirical evidence available hardly supports such an assertion. You yourself stated that it's hard work. Even the funding that Walnut Creek put into getting a new installer written didn't result in a new installer. So you want someone to do the work? Well, it's probably not going to happen unless someone is paid to do the job, one way or the other -- if not as an employee of Walnut Creek, then as someone who can sell CDROMs, most likely pressed by WC, based on the value people place on the packaging. > > I am merely pointing out that it has been much longer than > > a year without a new installer, and had their terms been agreed to > > a year agao, FreeBSD would have its installer source code today, and > > under the terms you are insisting upon, up front. > > And this is speculation masquerading as fact. You have no sure way of > knowing that this would, in fact, have occurred or that "two FreeBSDs" > would have even been widely accepted by the project contributors or > the user community. I see it as far more likely that your mysterious > commercial benefactors would have been deluged with demands that they > open source their product immediately so that people could customize > it and this might in turn have led to a siege mentality on their part > and very poor results. You simply have no way of knowing for sure > what you claim as fact above. There's a dozen commercial Linux distributions. The main source of product differentiation is the out of the box user experience. FreeBSD users, as a lot, are not opposed to commercialization; the most rabid "give us your source code now!" advocates are in the Linux community, and even they tolerate companies like Caldera shipping part of their distribution as binary only. I don't think FreeBSD would be harmed by having as many people using it as use Linux. The number of distributions is very much to credit with the Linux popularity and numbers of users, as well as buy-in from large companies. > > can't -- but I won't force you to take that code). You > > will have to accept the cloning pty implementation sample > > code as part of this, so that I can be assured that no one > > will break things before the next phase is complete. > > As long as that doesn't break all the clients of PTYs (and there is > the long-standing and classic problem of how PTYs are allocated by > walking vs a true PTY allocation mechanism), I'm sure nobody would > argue with that either. It can live side-by-side with the existing allocation mechanism, so old code won't have to change. But new code should use the library abstraction, so it shouldn't matter. > > So now it's your turn to "put up or shut up"; I _can't_ expend the > > effort on these things without a guarantee that that effort will > > not be wasted, like it was last time I spent the effort on these > > and similar projects on behalf of FreeBSD. I _can't_ afford to > > Like I've told you many times, Terry, nobody gets a "guarantee" of > anything in this project since it's not a kitchen appliance dealership > which hands out limited customer guarantees along with every frigidair > they sell. What you get is the chance to deal with a large group of > people and try, through dint of effort and perserverance, to sell them > on your ideas and (more importantly) your working code. Even if I > wanted to change this as part of "putting up or shutting up" for you I > could not since it's not in my power to beam hypno-rays directly into > the brains of several hundred people and get them all to agree up > front to buy a used car from you. That's something that you, and only > you, can do. Same deal *everyone* else gets. In short, this is life, > deal with it. It would be nice if the project would publish a roadmap indicating what it wants from developers, so that they don't end up spending an incredible amount of effort, only to find themselves stonewalled later. If the project would at least publish an architectural roadmap for even only six months ahead, I think it would help to commit more people to expending the necessary effort to see to those goals. Clearly, the "SMPng" work is one goal that's pretty widely known, thanks to Jason Evans and others publishing their direction; if the project could be that forthcoming in other areas, then there would be a "guarantee" that, even if the work was ultimately rejected, at least you could know that you were travelling in the right direction, instead of getting to your goal, only to have the project say "that's nice, but that's not where we are headed". At least put up some street signs. 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-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011062220.PAA22673>