Shuffled pages back up a level; Added links to main page that someone else had.

[ikiwiki.git] / docs / user / Interviews-Matt_Dillon_on_Linux_and_BSD.mdwn

Matt Dillon on Linux and BSD



What are some of the similarities, differences, and synergy -- if any -- between the Linux kernel and the BSDs?



Matt Dillon: The best way to think about the various open source projects is to consider ideas rather then actual code. The very nature of open source is that individuals tend to want to write the code themselves. Only wholely self-contained subsystems (which primarily means user applications such as ssh, apache, etc), which tend to be the most portable, are adopted wholesale. Very little actual code sharing occurs within the kernel itself with device drivers being the primary exception.



Most of the sharing, and synergy, occurs at the conceptual level. Ideas are shared all the time. Implementations are compared and even tested against each other. For example, when Jeffrey Hsu implemented SACK in DragonFly we tested it against Linux and whatever other implementations we could find out on the net. So while no code was taken from those other implementations, their very existance greatly reduced the amount of time and effort it took for us to do our own.



The BSDs are still considered by some to be more technically correct than the Linux kernel. Linus Torvalds has said in the past that it's not all about technology. Do you think the BSD project you work on is better technically for some or all uses than GNU/Linux (in general)?



MD: I'm not sure its a valid comparison to consider technical merits as the sole measure of a project's success. The developers working on the BSD projects have been established longer and tend to be older (one or two generations older, in fact). Older more experienced programmers tend more towards technical correctness simply because they know that code longevity is in part based on how well the original program was constructed. Younger programmers tend to take more shortcuts and tend to produce less robust code. It is simply a fact of life.



But this doesn't make the BSDs better, per say. Longevity does not mean forever and perfect coding does not mean that the algorithm chosen is the best for the job. One could say that the code being pushed into the Linux kernel is not sufficiently thought out, not sufficiently robust, and not well enough integrated to produce a smooth, long lasting, easily maintainable result. At the same time one could also say that regardless of code perfection, the algorithms in the kernel that the BSDs are based on were never designed with modern computing in mind and the BSDs are suffering (relative to Linux) because of that. The various BSD projects have chosen radically different approaches to 'fixing' these algorithms (with DragonFly and FreeBSD doing the most radical surgery on the core BSD algorithms).



The social dynamics are also quite different. Leadership plays a huge role in any project, but it is particularly important in a large open-source project with many contributors. Really good programmers are self-confident and somewhat egotistical by nature, and become more so as they age. The job of managing a large number of class-A personalities is not for the weak of heart. Linux is blessed with particularly strong leadership at the moment (that being Linus). OpenBSD, NetBSD, and DragonFly certainly have strong leadership. FreeBSD has gone through a serious changing of the guard in recent years and I would have to say that leadership is somewhat lacking for them at the moment.



The jist of this is that the 'taste' of a project is often a reflection of its leader. Because it is virtually impossible to rate personalities on an absolute scale, it is also impossible to rate projects on an absolute scale.



In fact, the qualities of a project will change radically when the leadership changes. Take XFree vs XOrg. Consider FreeBSD's changing of the guard. Consider the fallout that has occured from changes of leadership in other major open source projects. I would argue that the 'name' of the project has very little to do with anything.



If the BSDs were technically better than GNU/Linux five years ago, has the playing field leveled since then?



MD: Everyone ages and the Linux developers have been aging along with the rest of us, so they are certainly better programmers now then they were before. At the same time all projects gain new, younger developers. This tends to create generational parity over time. So as best I can answer the question I would say that the playing field has leveled with regards to technical ability, but I can't really say that that has actually translated to technically equivalent code in-kernel. In my opinion, Linux still suffers from its pot-luck methodologies.



I still believe that from a technical standpoint, the BSDes are coded better. On the flip side, we are still stuck with basically one filesystem (UFS derived) whereas as Linux has several (XFS, JFS, Reiser, EXT*, etc). Of course, reliability of those filesystems is another matter. Its taken Linux years to stabilize their filesystem work and I still hear complaints about them all the time from colleges who work with Linux. Performance is not everything.



Is sharing between DragonFly/Free/Open/NetBSD and the Linux kernel a common occurrence? And if so, does it go both ways?



MD:Actual code sharing between the BSD projects and Linux is minimal. There is a moderate amount of code sharing between the BSD projects themselves, especially userland applications and device drivers. Algorithms, ideas, and bug fixes are shared more often then anything else. For example, I had long discussions with a number of Linux developers working on the Linux VM system, explaining the BSD algorithms to them and why they were chosen, and many of those concepts have found their way into the Linux kernel.



Are there parts of Linux that you would like to see adopted in the DragonFly/Free/Open/NetBSD kernel?



MD:Not particularly. Linux is a melting pot of ideas, and that is good in the sense that a lot of different ideas get tested. We might adopt concepts and then write the algorithm from scratch, but nobody here is really interested in adopting the actual code, at least not within the kernel.



Both Linux and the BSDes adopt ideas from external sources, quite often the same source. The TCP SACK protocol is an example of this. Same protocol, different implementations. External sources, such as RFCs, POSIX, and other sources, are the primary glue that keep all the open source projects interoperable and differentiate them from proprietary systems.



Matt



Matthew Dillon



<dillon@xxxxx.xxx>