martin@mwtech.UUCP (Martin Weitzel) (07/18/90)
In article <1990Jul13.093105.4746@sco.COM> larryp@zeus.UUCP (Larry Philps) writes: >In article <OCM4N_9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >>Is there any way of telling the root fsck to use a bigger link count >>table? I'm tired of re-fsck-ing root after a crash. [...] >In a word: No. Sorry. > [...] >Easy if you have the source, the constant is MAXLNCNT >(or something close), impossible if you don't have the source. Why do so many programs use hard-coded limits at all? Poor software design? This is allways my first idea - my second idea is: The original author might not have imagined that his or her software is delivered without the source! Sometimes I whish there were a way to put some pressure onto the vendors of software to *force* them to deliver the source at least partially, if any of these limitations come up. IMHO many many working hours of the software engineering people are spent to find work arounds for problems, which could be fixed in ten minutes or less if - at least parts - of the source were available. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
pgd@bbt.se (P.Garbha) (07/18/90)
In article <840@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >Sometimes I whish there were a way to put some pressure onto the >vendors of software to *force* them to deliver the source at least >partially, if any of these limitations come up. IMHO many many >working hours of the software engineering people are spent to find >work arounds for problems, which could be fixed in ten minutes or >less if - at least parts - of the source were available. What i cannot figure out is what it would harm to give out the sources at all. What would it harm to give out the sources for fsck? It would help you, because someone else would make bug fixes, and maybe even enhance the program. Why are they afraid of, when not giving out the sources?
wsinpdb@lso.win.tue.nl (Paul de Bra) (07/18/90)
In article <840@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >... >Sometimes I whish there were a way to put some pressure onto the >vendors of software to *force* them to deliver the source at least >partially, if any of these limitations come up. IMHO many many >working hours of the software engineering people are spent to find >work arounds for problems, which could be fixed in ten minutes or >less if - at least parts - of the source were available. True, but the biggest problem with these software engineering people is that you can't stop them from changing source code, not for fixing a bug, but for adding their own "new and improved" features. Look what happened to Unix. The source was given to universities, with the result that by now it has become virtually impossible to merge all the changes back into one version of Unix. I'm not an accountant, but it's not clear whether the amount of time and effort that was saved by having the source around still outweighs the effort needed to port software between Unix versions and the effort to merge features from different Unix versions. (Just think of the incompatibilities that already exist between the different versions of Unix System V release 3.2... different file systems, different stop signals, if at all available, different include files, different X-windows, different tcp/ip, ...) I'm all for the availability of source, and I have used it to find and correct problems, but the possibility to add ones own features sometimes is just too tempting, and one really should not do this. Paul. (debra@research.att.com)
cpcahil@virtech.uucp (Conor P. Cahill) (07/19/90)
In article <1990Jul18.075104.15655@bbt.se> pgd@bbt.se (P.Garbha) writes: >What i cannot figure out is what it would harm to give out the sources >at all. What would it harm to give out the sources for fsck? Disreguarding the fact that the source code is licensed by AT&T and you gotta pay big bucks for it, Just think for a second about the support headaches that would entail. When the user calls up with a problem with fsck, how can you be sure that the problem is caused by your version or his. Even now, when sources aren't delivered, there are many cases of bugs appearing that are not reproducible at will on the support machine and therefore are almost impossible to debug. >It would help you, because someone else would make bug fixes, and >maybe even enhance the program. Why are they afraid of, when not >giving out the sources? Do you give out the source for all of your work? I sure don't (although I do give out some stuff, I still need to make a living). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
rcd@ico.isc.com (Dick Dunn) (07/19/90)
pgd@bbt.se (P.Garbha) writes: > What i cannot figure out is what it would harm to give out the sources > at all. What would it harm to give out the sources for fsck? First, there's the licensing issue, which says that we can't give out the source. Source licenses are available, but they're incredibly expensive. If you want to think about why, consider that it's the difference between "selling milk" and "selling the cow." But it's worse than that, and fsck can be used as a most egregious example. If people have the source, they'll tinker with it. Yes, I realize that's the point...but think for a moment about someone who doesn't quite know what he's doing, tinkering with fsck. He makes a change that ever-so- slightly starts to curdle his filesystems, but doesn't notice until it finally comes to the fore long after going through a complete backup cycle (so that the pre-screwup data is gone). Now what? Or suppose you want to think about support, or upgrades. It should come as no suprise that a lot of the time spent in making a new release of an existing system goes into trying to make sure that everything still works with everything else. There's nothing wrong with the "packaged system" universe, as long as it all works well enough that you don't have to poke under the hood. Nor is there anything wrong with the "do it yourself" universe, where everybody gets source and supports himself. But they're very different, and trying to mix them is uncomfortable. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd (303)449-2870 ...Programs, not politics.
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (07/21/90)
In <840@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >Sometimes I whish there were a way to put some pressure onto the >vendors of software to *force* them to deliver the source at least >partially... Blame copyright law. There was a time when only literary works could be copyrighted. Source code (which is often a work of art) could have been included in that description. Them somebody with not much sense decided that human-unreadable executable binaries fitted that description too, and the world became a much unfriendlier place. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
hsu@hutcs.hut.fi (Heikki Suonsivu) (07/22/90)
In article <1296@tuewsd.win.tue.nl> wsinpdb@lso.win.tue.nl (Paul de Bra) writes: >bug, but for adding their own "new and improved" features. Most often I have missed the source to fix ridiculous bugs in the operating system. Like vendor compiling lint with symbol table of 1024, so that you can't lint any programs big enough to really need lint. >Look what happened to Unix. The source was given to universities, If it would not have been given to universities, we would probably get subsecond sleep by year 2000. Or sensibly working signals by year 2005. Or disappearing inodes bug fixed by 1995, and better file system by year 2000. True, it would have been better if only one institution worked on unix, but I would rather see universities working on it than AT&T. Berkeleyisms aren't always the best, but at least they are there. >versions of Unix System V release 3.2... different file systems, There would be no pressure to fix the file system if it would at least do small things correctly (like keeping the free list sorted, and allowing more than 14 character file names). >is just too tempting, and one really should not do this. I'm eagerly waiting MACH non-at&t-licence kernel stuff come out, so I can join messing things up :-)