On 5/29/15 5:22 AM, David Holland wrote: > Because of these trends, I've been thinking for a while now that maybe > it's getting to be time to fork.
Hello, David! I started using NetBSD because of its small base system disk and memory footprint, focus on security, support for many machine architectures, ability to scale well to large SMP machines, support for a wide range of deployments from embedded to server to desktop (it's a big time savings to only have to learn and remember how to do something on one OS instead of many), and genteel user and developer community. I value all of these things. (Some benefits I came to appreciate later were its relatively long support for a release and its package management system, pkgsrc (writing a package once and having it work on all platforms I use is a big win).) Personally, I don't have an interest in running NetBSD on vintage hardware. However, I understand and respect that some people do, and I have nothing against that. I would very much so hope for NetBSD to *not* fork! I agree with Taylor Campbell: "I suspect if people have the time and energy to make and maintain a fork, they certainly have the time to write automatic tests for the old network protocols." [1] In "Evolving Frameworks," [2] Don Roberts and Ralph Johnson suggest in the "Tree Examples" pattern that you should never write a software framework unless you have at least three applications that use it. Part of the reasoning is that these applications help you come up with the proper abstractions for the framework. If you think of NetBSD as a framework and the machine architectures and hardware as applications, then perhaps all of those "applications" can actually be a benefit to NetBSD and help it to have really nice abstractions and design. Of course, bit rot is bad, and I can certainly understand those who would like to remove things that aren't used. It's more work to maintain those things, and, in some cases, it offers a bigger attack surface to attackers. I understand the argument that something can always be restored from the attic if someone wants it, but the downside of that is that, while NetBSD advances, deleted things remain as they were when deleted and thus become more difficult to bring back over time. But if you have automatic tests as Taylor Campbell suggested, those things could potentially stay in the tree, and changes can be made to them with some level of confidence because the automatic tests still pass. Regards, Lewis [1] http://mail-index.netbsd.org/tech-kern/2015/05/29/msg018796.html [2] http://st-www.cs.illinois.edu/users/droberts/evolve.html
