The sorry state of open source today

José Manuel Molina Pascual raistlinmolina at
Wed Apr 18 16:11:04 UTC 2007

Hi, I've never posted to the advocacy list but as I read the post this
guy wrote..... well, no comment.

I've only read the chapter "bugs in the free", it seems to me that
this gut is the typical "Security by obscurity", this phrase:

"Security fixes are indeed benefiting for having the code in the open,
but this also has a price: security advisories are issued more often
than ever, as everyone can dig for weaknesses" is very clear, in fact
it says that is better to get binary code and trust it.

I think that what he does not say is that many development languages
are going to the "code once run anywhere" paradigm, via intermediate
files runnable under a virtual machine (being Java its maximum
exponent) or interpreting ASCII code (ruby, Perl, PHP..........), and
what it happens with these languages is that the "closed" application
you get is by no means closed to those guys who are capable today of
look for weaknesses in open source code. It can be argued that for
instance Java classes can be obfuscated but this obfuscation can not
stop a determined developer, there are very good tools that let you
analyze code, it's true that it will take you more time but it can be
done, ¿aren't the drivers for the Intel 3945ABG wifi chipset evolving?
¿has intel released the specs?.

This man is the classical example of corporate guy, can't live if the
tools he uses aren't provided by IBM, Oracle, Microsoft...............

Maybe he's paid by Microsoft.

On 4/18/07, Scott Long <scottl at> wrote:
> Dag-Erling Smørgrav wrote:
> > The subject refers to an editorial by Radu-Cristian Fotescu, which was
> > published on the author's own website and in The Jem Report:
> >
> >
> >
> >
> > The article contains several factual errors regarding FreeBSD.  I have
> > posted a rebuttal on my blog:
> >
> >
> >
> > DES
> I'll rebut you're rebuttal =-)
> You're absolutely correct about feature-based vs time-based being a
> problem.  However, KSE was NOT, I REPEAT NOT, the major nor the second
> major reason for the FreeBSD 5.x problems.  5.x releases suffered from
> the following problems that were much larger and much more immediate:
> - ULE and the modularized scheduler
> - ATA
> - UFS2
> - Immature locking model, too much Giant
> Now, I'll entertain that the KSE development caused hurt feelings among
> some developers, but that was a professionalism issue, not a technical
> issue.  I also do agree that M:N is a nice academic theory that has run
> into real-world roadblocks, and that FreeBSD seems to be better off in
> the end with 1:1 threads, just like most other OSes.  But KSE was a
> stepping stone to get there; without it, who knows when we would have
> moved passed libc_r?  It was a definitely a painful step, but it would
> have been much more painful to not have any alternatives to libc_r.  I'm
> glad that the project and certain developers in it had the courage to do
> it AND to stick with it to resolve the tough problems.
> Scott
> _______________________________________________
> freebsd-advocacy at mailing list
> To unsubscribe, send any mail to "freebsd-advocacy-unsubscribe at"

What is history but a fable agreed upon?

In politics stupidity is not a handicap

More information about the freebsd-advocacy mailing list