On Wed, Mar 03, 2004 at 01:33:17AM +0100, I.R. van Dongen wrote: > Jan Minar wrote: > > >IMHO, the key words in Richard's posting are ``[not] enough expertise'', > >and ``a track record''. The idea that the [conceptual] flaws will be > >fixed in The Next Release [TM], although quite common amongst the > >people, is a mere instance of a proof by wishful thinking. Clueless > >authors will always produce crappy software, regardless of how long > >they've been in the business. > > > > > It's not about releases, it's about auditing a product before the > authors accually have made their minds up about where the product is > going. They made the minds quite early. They just had not enough expertise to implement it. Now are the supposed auditors going to handhold the tinc people every time they will add some more code? If not, have the tinc people enough expertise to do it right, now? > Tinc started out as a idea on using the tap device for something > useful. It migrated to a pretty nice vpn solution. One thing is a fast prototyping, when I implement a phony MIC, for example, and I comment it as such, and another thing is a hotch-potch coding, when I get pieces together just to look like a valid MIC. AFAICT, the tinc people did the latter. I tend to presume this coding practice is still present with them. Note that we are not talking feature completeness, but that the actual implementation of (alleged) general features, e.g. confidentiality, and authenticity, was flawed. > Even linus made some pretty bad coding errors when he started out with > linux, if you want to imply that when software, or a part of it was > once flawed, you shouldn't trust the author ever, you shouldn't use > linux at all. The same goes for Linux. Although it might have been a major leap from 2.2 to 2.4 and to 2.6, the overall experience is still the same: some things work, some have problems that have to be tracked down and repaired manually, some won't even compile. And I have to reboot time to time. I presume this will be the case with 3.0, 3.2, 3.4, too. The rule of thumb is the things just don't change. Because great amount of the code doesn't change after initial testing, because the authors' attitude seldom changes, because it would require incompatible changes to the underlaying protocols, etc. FWIW, J. -- ``You know those mail clients: MS Outlook, mail(1), or even telnet(1). All of them suck. This one just sucks less.''
Attachment:
pgpeA9AESmIns.pgp
Description: PGP signature