# BSD convergence/working together?



## BlueCoder (Mar 5, 2013)

Has there been any effort to getting the BSD's to work together?

I can understand each BSD wants to go their own way on certain design issues and or to something experimental but each project seems to copy features from each other. I'm wondering if the BSD's can't work a little closer together to streamline the process.

Maybe establish a common repository that everyone derives from. Then patching for platform specific features/options. How much does most of the userland really differ across platforms?

The kernels are different but has there been any movement to establish guidelines to coding kernel features to make them more portable?


----------



## SirDice (Mar 5, 2013)

There's already a lot of 'cross pollination' going on. Just look at openssh/openssl for example.

But, not only the kernels are different, the rest of the userland is too. We all have a common ancestor but the design goals are different which resulted in vastly different code over the years.


----------



## BlueCoder (Mar 5, 2013)

What I'm wondering is if it wouldn't be possible to reintegrate/coordinate together a little bit more.

Essentially each one could be different where it intentionally decided too but otherwise import from a common repository of components and apply patch sets.  Start small one utility at a time. Is 4 or 5 implementation of dd really needed?

What prompted this post is Linuxisms. It occurred to me each BSD can have it's own ISM's.

What might be able to be done to allow components/features to be more portable.

There were standards committees before that became POSIX. Why not a similar moment for standards among the BSD's? All the BSD folks all go to the same conventions anyways. See if we can avoid the ISM's somewhat. Be more portable and compatible.


----------



## phoenix (Mar 5, 2013)

And, just why/how exactly do you think the current setup is an issue?  Just how different do you think the source trees are?

I'm guessing you haven't wandered through any of the source repos or mailing lists to see just how often software from one BSD is imported/merged into another BSD.  For example, the FreeBSD svn logs are full of "imported from NetBSD", "synced to OpenBSD", "vendor import from this BSD", etc.

Same with the DragonFlyBSD import logs.

Don't know about OpenBSD/NetBSD as I don't follow them, but I don't see why they would be any different.


----------



## fluca1978 (Mar 6, 2013)

Oh what a good idea, I guess nobody did think about that before! (ok, just joking)

There are a lot of problems: culture, aims, developers... It is not that simple. And by the way, a lot of code is _cross-ported_ from all the BSDs, think about the pf from OpenBSD as a single example. 

And be aware BSD is not Linux, and the fact that there Linux distros does not mean BSD should be the same.


----------



## throAU (Mar 7, 2013)

BlueCoder said:
			
		

> What I'm wondering is if it wouldn't be possible to reintegrate/coordinate together a little bit more.



If this was possible, half the BSD projects wouldn't have forked in the first place.

Due to the personalities involved, and disagreement on some of the core design decisions BSD has been repeatedly forked.  If everyone could get along and agree on a direction this wouldn't have happened.

That said, as mentioned above, there's already plenty of cross-development.  It's also not really a bad thing as not everyone can be "correct" as far as the "best" way to solve a problem goes.  Having 3-4 (or more) versions to shake out what actually works in the real world and have the superior technology float to the surface is no bad thing.


----------



## BlueCoder (Mar 7, 2013)

I ask questions that other people have though of before because I don't know the answers and I want to better understand the problems.

I like multiple solutions to problems and doing things differently. There is a lot of code being transfered across the BSD's. I'm just wondering if it can't be done better. I'm not expecting to find a solution; again I just want to understand the problems better. Think of it as a though experiment if you will. I'm asking why the King is wearing no clothes rather than just accepting it or pretending to know. I can understand code a lot easier than politics. It seems to me that the BSD's are less divided than the Linuxes.

First I just asking if it could be organized differently. If developers across the BSD could find common ground. I have seen the code across the BSD's. I'm wondering if it couldn't be more modular. What about a common code repository of things that don't change very much or that there isn't much controversy over? Something like a ports system for all the bases.

Second couldn't greater understanding of the architectural differences between the platforms be created? Workshops or development guides.

Lets take for example Bhyve the new virtualization architecture for Freebsd I've been reading about for the last couple days. It's essentially KVM for FreeBSD. It would be nice if it's developers could design it from the start so while primarily being designed for FreeBSD it were designed to be easily ported to any of the other BSD's.

On OpenBSD you have OpenSSH and PF. On DragonflyBSD you have the Hammer filesystem. Not familiar enough with NetBSD. There will undoubtedly be future killer applications. I would just be nice if there were some organized effort that future programmers could consult with to design from the ground up for whatever they are working with to be portable.

On BSD we talk about Linuxisms. But what is there to marginalize each of BSD's from doing the same sorts of things? It's one thing to be different for a reason; it's another to do it just to be different. What will it be like when there are a dozen BSD's? Other than the licenses what will the commonality be?

And I thank everyone in advance for humoring my silly questions.


----------



## fluca1978 (Mar 7, 2013)

While the main question, _why not sharing more than what is today_, is good and valid, it is important to understand what we are talking about.
Linuxism, or better all Linux distros share a base code: the kernel. Despite some minor changes, they all the same kernel and on top of that they build a different set of tools (e.g., package management), releases, auditing, ecc.
Here all the BSD have in common much more the story than the kernel. For instance, DragonflyBSD is much more parallel-oriented and lock-free than for instance FreeBSD. OpenBSD was generated from a branch of NetBSD, or better from some difficulties within the development and the developers (google for that), and so on. PCBSD is desktop oriented and is moving to reimplement a lot of stuff because current desktops are not fully supported on FreeBSD. MidnightBSD uses OpenStep (GNUStep?), and so on...
So it seems to me that here we have a set of systems that all end in BSD, but that are really different in culture and development, as well as in the kernel itself.

Making an application portable means that all the system must look the same, disregarding such differences. And this is possible at an high level. For instance, FreeBSD uses geom, that as far as I know is not used on other systems, and therefore raid tools and crypto disks works differently among all BSDs. Other applications, let's say PostgreSQL are much more portable, but in order to work at best on each architecture they have to be compiled (and sometimes patched) ad-hoc, and this is what the ports tree is (almost) all about.

Finally, there are culture differences: OpenBSD does not allow, for instance, the inclusion of ZFS, and that is a decision behind the technical layer.


----------



## mix_room (Mar 13, 2013)

fluca1978 said:
			
		

> Finally, there are culture differences: OpenBSD does not allow, for instance, the inclusion of ZFS, and that is a decision behind the technical layer.


In this particular case it arises from OpenBSD being very strict on what type of code they allow into their base system. There is no problem with the inclusion of ZFS on any technical notes, purely on licensing issues. They would be more than happy to include ZFS as e.g. a kernel module.


----------



## fluca1978 (Mar 14, 2013)

mix_room said:
			
		

> They would be more than happy to include ZFS as e.g. a kernel module.



I'm not sure about that, as from a recent discussion on a maling list.


----------

