Interview with Andrew Tanenbaum (LinuxFr.org)
Posted Nov 17, 2011 22:44 UTC (Thu) by jgd
In reply to: Interview with Andrew Tanenbaum (LinuxFr.org)
Parent article: Interview with Andrew Tanenbaum (LinuxFr.org)
Tanenbaum gets small things right, big things wrong IMNSHO
- BSD License problems
- If you weren't there at the time you have no
idea how bad it was. AT&T won a court case
which not only prohibited the distribution of BSD
but compromised the employability
of every UC Berkeley CS graduate because they had been
mentally contaminated by their exposure to
AT&T licensed code. It took years of time and
millions of dollars of public money to free BSD and
to reverse that case.
- Developer community, Copyleft. Open Source Free Software
- Tanenbaum completely doesn't get the concept
of community-based development. Linus didn't write
much of Linux, he coordinates the work of tens of
thousands of developers worldwide. There's nothing
else like it. Tanenbaum doesn't get Open Source since he
thinks it's great to have our lives (cars, appliances,
etc.) managed by systems based on Minix but doing who-knows-what behind
the barrier of closed source and DMCA. Tanenbaum does not seem
to get the key difference between Open Source vs. Free Software and how the latter stimulates participation and protects the rights and security of users. The GPL License of the Linux kernel easily outweighs any possible technical superiority of any DMCA-protected proprietary kernel.
- Upgrading kernel without rebooting
- "Certainly Windows and Linux can't do this." Unless
you use KSplice!
- On being ahead of your time
It's nice that he "published a paper in 1978 on "something very close to the Java Virtual Machine". Maybe he "never got much credit for it" because the UCSD P-System was already doing it. The UCSD P-System was rapidly moving to dominate the world when it got saddled with a proprietary closed-source license and all development stopped - just the fate that almost happened to BSD.
- Formal Verification
- Tanenbaum dismisses the importance of the formal verification
that has been accomplished by other projects for some microkernels and O/S components. Of course formal verification
does not tell you when hardware interactions will bring you down. All it does is force the developers to keep the code squeaky clean and
help them get rid of nearly all software bugs. Now that can't
be very important, can it?
- Missing what's truly important
Someone once asked Dennis Ritchie what was the best way to write a
large C program. His answer: "Don't!". I am very much in favor of
constructing ambitious software systems out of manageable and verifiable
components interacting through simple, well-designed communications protocols. Minix has been and continues to be an important project in this area. The reason Minix has not been more successful
up to this point are (1) initially getting off on the wrong foot with a proprietary license (2) the current lack of invitation and welcome of the participation of others and (3) the appearance (at least in this interview) of the lack of appreciation for the technical and other innovations of others.
to post comments)