FreeBSD Might Get A Linux Kernel API Wrapper To Help Porting Linux Drivers

[nasyt]

That rumor was proven false, the actual comments from the facebook developer is that the FreeBSD stack is terribly written code and inferior to Linux.

May be. The Linux' TCP stack sucks anyway. There are dozens of better Network stacks out there. Plan9's Stack is a good example. There are even people writing user-mode network stacks to surround this subsystem.

http://shader.kaist.edu/mtcp/

Linus' virtual mem system as of today has no equal.

It has! L4's Virtual Memory Model is way way better and more flexible.

[nasyt]

Linux offers superior networking performance, superior file systems and better security.

Superior, right? But still embarassingly bad.

[Guest]

May be. The Linux' TCP stack sucks anyway. There are dozens of better Network stacks out there. Plan9's Stack is a good example. There are even people writing user-mode network stacks to surround this subsystem.

http://shader.kaist.edu/mtcp/

I hope you don't believe there's so many masochists? Linux wiped out *BSD from the server market, so if Linux TCP sucks, BSD sucks more.

It has! L4's Virtual Memory Model is way way better and more flexible.

I bet it makes it very scalable, am I correct? I'm dying to see desktop, mainframe, server and HPC benchmarks of L4 kernel. Seriously, it's too late for fairy tales. Come back when L4 becomes something more than a 'toy'. It's not the same league.

[Guest]

You mean companies don't like when someone steals their code? They don't have to release their code as far as you already know? If you think about the part which is BSD licensed, no they are perfectly fine with it, it works same as with GPL, multiple companies cowork on common base and invest together in it.

Yes, they're 'stealing' from BSD, but same time they don't like when somebody 'steals' their code. That's why they usually don't release it and *BSD doesn't get patches in such case. GPL enforces them to bring changes back (when they want to distribute the code).

You said the companies prefer to invest in BSD, but that's not true. What they prefer is to take the BSD licensed code over GPL one, but this has nothing to do with investing in some BSD project. Let's say MS 'stole' BSD TCP stack. That's not an investment. Apple contributes to Clang/LLVM, but they don't have to release their home made improvements. That's why they can be always one step further over original project. It makes Clang/LLVM not able to compete with Apple improved compiler. If I were leading some computer company I wouldn't invest in BSD licensed project, because there's a risk my competition will 'steal' patches and they won't release theirs. If Intel invests a lot in Clang/LLVM AMD takes their work for free, links patches with their own and distributes improved compiler under proprietary license. Intel is a looser here.

Further, why do you thing you have an idea about how many companies support BSD licensed projects? You have no tucking clue about it.

It's enough to check FreeBSD supporters.

[Guest]

It depends a lot on the type of the shared product and the type of the product the company is creating.

When the shared component is something that everyone uses as-is or with trivial modifications then companies prefer Copyleft licenses. It prevents competitors from proprietarization of the shared component.

When the shared component is basically part of the company's product, potentially heavily modified in a unique way, then companies prefer BSD style licenses, since they don't have to let competitors see and use their modifications.

Cheers,
_

I agree, thanks.

[MoonMoon]

GPL enforces them to bring changes back (when they want to distribute the code).

A misconception, a quite common one, but still a misconception. All that the GPL enforces is that a company using GPLed code is giving their customers access to the source if they demand that access. No part of the GPL enforces anyone to submit their patches to upstream or collaborate in any form with upstream. So if upstream wants to use those changes and incorporate them into their codebase they have to get (possibly even by buying the product) and analyze the code themselves. This may be made more hard by not having documentation in the code itself, different code formatting, ..., in which case doing a clean rewrite of the functionality may even be easier, which renders the alleged "contributions" basically useless, making the advantages of the GPL over the BSD license minimal.
Example: At no given time Red Hat actually had to give CentOS developers access to their source repositories, unless they had bought a license. Also, at no given time were they enforced to submit their changes upstream. That CentOS got the access for free was purely a nicety from Red Hat's side, that Red Hat chose to be involved upstream was sane from a business point of view, but at no point were they forced by the license.

In short, if a company does not want to collaborate the GPL does not hinder them from making it as hard as possible to actually use their changes.

[nanonyme]

The customer assumably can get the source code upstreamed if they request the source though so that's somewhat dangerous a tactic

[MoonMoon]

The customer assumably can get the source code upstreamed if they request the source though so that's somewhat dangerous a tactic

Indeed, people that have access to the code can try to submit it upstream, but this still can be made very hard, for example with tactics I mentioned above (no in-code documentation, different coding style, ...), so that upstream likely run better with implementing the functionality themself, effectively meaning that there were no actual contributions but the idea of the functionality. Also, people that bought the product before are unlikely to switch to the upstream product if they have to rely on things like support.
Of course the viability of such a tactic also relies on the manpower of the upstream project, projects with many developers are much less likely to be victim of such a tactic than projects were manpower is scarce.

[anda_skoa]

A misconception, a quite common one, but still a misconception. All that the GPL enforces is that a company using GPLed code is giving their customers access to the source if they demand that access.

Yes and no.

There are several different options someone distributing GPL licensed code has to comply with the license.

One is to ship the code with the software. This is the one you are thinking about when you write that they only have to provide it to their customers.

Another one is to accompany the software with an offer to provide access to the code, the option you refer to as "demand that access".
However, this "written offer" has to be valid for any third party.

So as a non-customer third party you would only need to know about at least one customer who did get this offer.

But in general you are right: if the code has been shipped with the software, only those who got the software in the first place will have the code directly from the vendor.

Cheers,
_

[nasyt]

I hope you don't believe there's so many masochists?

Yes! There are also many masochists that use Ubuntu on servers instead of something serios like CentOS or Suse SLES.

Linux wiped out *BSD from the server market, so if Linux TCP sucks, BSD sucks more.

May be.
Recently, I was involved in a Company, where we had to do heavy message transfer like smtp mail and something like that, and we evaluated the use of Linux in order to save costs. It didn't perform very well. We put OpenVMS into Work and it performed pretty good.

I bet it makes it very scalable, am I correct?

Exactly.

I'm dying to see desktop, mainframe, server and HPC benchmarks of L4 kernel. Seriously, it's too late for fairy tales. Come back when L4 becomes something more than a 'toy'. It's not the same league.

It is like with most Akademic things.