Date: Sun, 19 Aug 2001 19:55:34 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Mike Meyer" <mwm@mired.org> Cc: <questions@FreeBSD.ORG> Subject: RE: IDS Message-ID: <004801c12923$94edef60$1401a8c0@tedm.placo.com> In-Reply-To: <15232.26162.667917.436954@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: owner-freebsd-questions@FreeBSD.ORG >[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Mike Meyer >Sent: Sunday, August 19, 2001 6:22 PM > >You seem to be arguing that, because ports are abandoned, people >shouldn't bother submitting them. No - just that if your going to submit a port, then please stick around and keep it active. That's bogus. If someone ports >something then submits it, it will be found - and probably used - by >more people, it's liable to keep someone from duplicating the work, >and it makes it much more likely that the someone else will pick up >the port and maintain it if the original porter abandons it. This is a difficult thing because it touches on the heart of software development. Of course, as you and probably most people do, I argue that the world shouldn't standardize on a few software packages just because it keeps effort from being duplicated. Using new software packages is what helps advance the state of software everywhere. But the opposite - where new packages appear for a few years and then vanish because the people that started them abandonded them - is just as bad too. Look at all the people that got screwed when umich decided to drop work on LDAP and the huge trouble it took for the OpenLDAP people to pick it up. It would have been better if there had been no LDAP ever from umich and instead OpenLDAP had been the reference implementation. > >As a developer and port maintainer, I'm *always* appreciative of >well-written bug reports. Generally I submit bugs, and your right, I should at least submit one on the snmp thing. I've found other port maintainers to take >the same attitude. Even if the response is a simple "*poof*, already >fixed. just get the new version". If it's not fixed, I tend to get a >test patch before the general public, which is always nice to have. > >> For another example, how about all those ports that have error >messages about >> them being insecure, like uw-imap? What's that all about? I guess the >> maintainer is so unresponsive there to fixing the security bugs that the >> Project has just thrown up their hands in disgust and slapped in warning >> labels. > >First, the maintainer isn't the person responsible for fixing security >bugs, the *developer* is. Oops - your right there. My mistake. A responsible maintainer will mark such a >port appropriately as soon as the vulnerability becomes known. Then >they can worry about fixing it. Generally, "fixing it" means notifying >the developer, and hoping they'll fix it. In some cases - the BSD >version of netscape, for example - that's all that's possible. If the >maintainer can provide a patch, that can be added to the port and sent >to the developer, which makes it more likely that it'll be fixed in >the next version. > >As for "all those ports", in the tree I checked out this morning, >there were 5673 ports. Only 38 of them are marked FORBIDDEN, and >roughly half of those are so marked for reasons unrelated to >security. That means only about 1/3rd of a percent are broken. Some of >them the developer has abandoned - same example - and probably should >be deleted. > While there may be 5673 ports, I think you would find if you did a survey that less than 10 percent are widely used. Things like mail server software are used by many, things like snmp are used by few. It's the ones that are more high profile are the ones I'm concerned about because they trouble the most people. If your installing a total of 5 ports on your new FreeBSD server and 1 of the five is marked FORBIDDEN, then do you think it matters if that is only 1/3rd of a percent? Besides that - FreeBSD 4.4 is getting close to release now, why are there ANY that are still marked forbidden? If you >> are doing this on a lark, or conditionally to where you will stop >doing it if >> it takes up too much time, then your just setting up traps that >are going to >> harm those of us who start using your port. > >That's where we disagree. While submitting a port as a lark is a bad >idea, this is a volunteer project, which means that pretty much every >port committed will only be maintained if it doesn't take up to much >time. Any making a port, is makeing their work available to others, >and doing them a service. > Which is exactly why I told the original person to go back to the code and ifdef it to build flawlessly on FreeBSD BEFORE putting it in as a port. Then it really will not take a lot of time for anyone to turn it into a port, and anybody can then do it for them. >Anyone using free software in a production environment runs the risk >of the developer - and port maintainer for ports - deciding they have >something better to do with their time than provide pro bono >support. If they aren't willing to take that risk, they should be >paying someone for support. > Or supporting it themselves, which is in effect what I did with my snmp story. Of course, my version of self-supporting, ie: not using the problem code instead of trying to fix it, is probably different than what a lot of people would like. :-) Anyway your argument simply is NOT just applicable to FreeBSD it's applicable to ALL software, including commercial software. Pardon me for jumping on my soapbox here, but I think it does tremendous damage to infer as your doing that Free software runs a risk of being unsupported in a production environment, and paying someone for support on software will alleviate that risk. People pay billion of dollars to Microsoft for support contracts on Windows but that makes no difference when Microsoft decides to stop supporting a particular Windows version your SOL. Even if they are still claiming to support it that's bogus too because your going to get the same iffy level of support or unsupport from them when you have problems. The situation is the same for most other commercial closed-source software providers that I've dealt with. Thanks, and I'll get off my soapbox now. > >Assuming they exist and will do the job well enough so that you don't >have to do the port yourself. If that's not true, you're much better >off starting with a port than starting from scratch. > True enough. >BTW, this ties back to the documentation thread. The reason that it's >better to submit work to the FreeBSD project than set up your own web >site is because it is much more likely to be picked up and maintained >if the original author develops it. For the doc project, that's almost >a certainty. [cheap shot] I see no evidence that this happened with the Chapter on printing from my book that AW donated. ;-) >If a port or documentation isn't submitted to the >project, it's almost a certainty it won't be picked up by someone >else. Seriously, I think your off base when you mix documentation and ports here. For ports of software - no question this is correct. It's one of the fundamental principles of BSD. Software always has to be maintained because the platform that it runs on gets changed. But for documentation, this is a bit more fuzzy for several reasons. First of all, you can view documentation as a kind of "advertising". For example, the very existence of books like Greg's, mine and now Annelise can and does give credibility to the FreeBSD that it would otherwise not have if the project was entirely virtual. It's pretty hard to carry a CD into a CIO managers office and say "we should run the whole company on this stuff", it's a lot easier if your lugging a library of books behind you written about the stuff on the CD. It's even more credible if that library was written by people unconnected to the stuff on the CD - after all closed-source commercial software vendors are very adept at churning out libraries for their products too. A well-designed, and well-promoted website can serve the same purpose too. For example you could easily have a website that serves mostly Windows users that has a FreeBSD section - for many of those users that may be the only exposure to FreeBSD that they will get. They are certainly not going to be going to freebsd.org by themselves. The last thing about documentation, websites and whatnot, it that documentation is NOT critical to the RUNNING of the software, just to it's USE. Just because someone's FreeBSD-related website gets stale, or someone's book goes out of print, well they aren't running documentation on their servers, they are running the software! After all, the software package that the developer submitted to the FreeBSD project already contains the most authoratative and best documentation that there it - the source code! Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?004801c12923$94edef60$1401a8c0>