From owner-freebsd-chat Sat Jan 24 16:27:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA26621 for chat-outgoing; Sat, 24 Jan 1998 16:27:24 -0800 (PST) (envelope-from owner-freebsd-chat@FreeBSD.ORG) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA26612 for ; Sat, 24 Jan 1998 16:27:16 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id QAA01396; Sat, 24 Jan 1998 16:36:34 -0800 Date: Sat, 24 Jan 1998 16:36:34 -0800 (PST) From: Alex Belits To: Terry Lambert cc: chat@FreeBSD.ORG, opsys@mail.webspan.net, marcs@znep.com, imp@village.org Subject: Re: Mike Shaver: Netscape gives away source code for Communicator In-Reply-To: <199801242321.QAA10882@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 24 Jan 1998, Terry Lambert wrote: > > HTTP standard is pretty much out of their hands already (and never > > really was there). SSL, of course, was added by them, and more compatible > > version of encrypted HTTP and MD5 authentication rejected, but that was > > done in significantly less barbaric way than other things by the same > > people at the same time. > > MIME, Multipart/Replace doesn't work on Internet Explorer. Of course -- it's an example of netscape extension that was left supported only in their browser, and still didn't give any advantage for their server. > There are > other examples. > > I think NetScape dominates the HTML standard; mostly because they > have clever people thinking about how to improve the protocl, and > they pay these people to do that. Ass opposed to havving some form > of committee making the suggestions and decisions. HTML (I don't call it "protocol") for some time was being extended by Netscape, however I don't think, they did a job better than a committee -- HTML 3.0 was designed by committee, HTML 3.2 was "fixed" to accomodate Netscape and MSIE extensions, and 3.0 looks like significantly more clean and well-designed one while 3.2 has all signs of being an afterthoght standard that just included things made in "code, then think" manner. I don't believe that an infinite number of coders in infinite time can make all nice design decisions that can be made with their products. It takes a competent designer to make one, and sometimes committee can replace good designer better than coders that think only about implementing some functionality before deadlines. And companies now too often force each other to work in a rush, make design mess and put it into their standards. > > > I expect them to retain editorial control on the "official releases". > > > This is, in fact, only slightly more restricted than GPL, wherein the > > > GPL code is maintained by a central repository. Cygnus proved that > > > there is room for one (and *only* one) editorial source per GPL style > > > product. > > > > Emacs - XEmacs - Mule (ok, last one is now going to merge with every of > > first two). And while not the most stable thing in the world, pgcc exists, > > as a separate gcc branch. > > I've used Cygnus products. I like Cygnus producs. And EMACS, you're > no Cygnus product. I am referring to all GPL'ed products, not just Cygnus ones. I don't think that it was good to have those Emacs branches, but certainly they appeared not because of an evil will of their developers -- there was a reason why original Emacs didn't satisfy them, and since rms while being the person who has the control over original Emacs, didn't accept their changes, branches emerged (details about commercial products and packages omitted). I believe, this is a question of how the maintainer's policy of accepting contributed changes corresponds to maintainer's development capapcity, demand for improvement and existence of clear design goal in maintainer's and contributors' heads. The more messy is the project, the more arrogant and less productive is the maintainer and the more is the demand for the improvement, the more is the probability of branching. Cygnus produces enough improvements and has sane design to compensate for their problems, so their products don't branch. Linus/... accept large number of contributed changes while maintaining acceptable design, so Linux kernel doesn't branch except extreme cases like STREAMS. Linux libc was a large branch of glibc, even though some cygnus people worked on it, and now when glibc 2 is mostly usable, it painfully but with visible progress replacing linux libc 5, so that branch will be eliminated soon (hey, they even fixed ther major screwup with header files that completely breaks my programs before I have found it ;-). Linux distributions maintainers don't accept each other's packaging system or various internal standards, and have to often adapt existing products by themselves to include in distributions, so Linux distributions branch (other reasons like packaging commercial products in commercial distribution bundles are omitted as insignificant -- it's not hard to "synchronize" the rest if there was the agreement on it). All *BSD have large amount of messy (but usable) code, less willing to accept contributions, especially to kernel, are inflexible in accepting even simple and necessary changes in userspace part of base distributions (ex: LPRng and FreeBSD), and users' demands are high. So they branch (again, BSD license encourages branching in commercial version, but it's not that significant compared to more "natural" reasons). > The reason there are two versions of EMACS is the reason there are > three BSD's and many Linux distributions, twofold: > > 1) They aren't working in the same improvement space Yeah, this is why some my code works on OpenBSD and crashes FreeBSD :-( > 2) They are engaged in actively preventing inclusion of both > source bases in one for territorial reasons. That's too -- the same as my "arrogance" reason. > This is admittedly a problem in a volunteer project, where the first > is caused by there not being enough like-minded people to do the work > without editorial/ego issues, and the second is because the reasons > for the participation are largely ego, and since there are not enough > people, the people who are there are engaged in crisis management, > not planning. > > It's a nice catch-22. But like JAVA, Netscape will certainly be > maintaining a source repository, exercising editorial control on > it, and productizing for their "Pro" version. This is like Eudora > Lite, with source code. > > In that sense, there is room for one "Cygnus": Netscape itself. There is a room, but I'm afraid, there is nobody in that room to do what Cygnus does. > > Do a > > lot of people here know that "multipart/x-mixed-replace" server push works > > on HTML documents and allows server-initiated update of them in browser? > > I certainly do; I use it. Explorer can't compete... So do I, but since servers (including Netscape one) have trouble implementing it, most of people don't, and it doesn't help netscape mmuch to have this feature. Again, MSIE most likely doesn't have this feature for the reason of forcing developers to use Microsoft-only things, like ActiveX controls, which are even less efficient for that simple purpose, but promote products that can't be made by Netscape. > > Of course, HTML is completely different story -- everybody remembers > > ugly creations of tags war, and now it's shifted to J*scripts/stylesheets > > war, but that's significantly less dangerous than proprietary extensions > > to protocols, randomly being added by competing vendors. > > That's the good thing about Netscape being in it for money instead > of ego: they can *plan* instead of just responding to crises -- "Oh > no, we need something to do XXX!" "Just hack it in!" "No way, we > are professionals". Etc. Netscape does that even without a problem hanging over them -- I don't believe, recent wave of Communicator-on-FreeBSD problems wasn't prevented if configuration management was well designed. I hope, they won't continue the same things with more "resources" available, but the need for clean design will increase in this situation, and I have doubts about them being capable of doing it in that situation well. I will like to be proven wrong in that. -- Alex