4 ms·

> FreeBSD Has a Closed Development Model Given that it took me 3 month to have Jack Vogel (then maintainer of the driver) acknowledge there was an uninitialize

> FreeBSD Has a Closed Development Model Given that it took me 3 month to have Jack Vogel (then maintainer of the driver) acknowledge there was an uninitialized variable bug in the e1000(4) driver, leading to countless user frustration, despite detailed technical analysis and patch. Let me openly challenge this assertion... The issue ended up being fixed (or actually, buried in a huge patch) without attribution [ed. of course!]. My kind regards, but from experience, Linux folks is more open than BSD folks. YMMV. > The BSD License Means Companies Don't Contribute Back They don't ! I've worked for 5 years in a [small] company using FreeBSD as the main development platform, heavily hacking the TCP and network stack. We leached plenty, and didn't contribute a single line back !

drewg123 10y ago
Let's just say that the Intel drivers have a pretty checkered history and your experience was not unique. There are new people at Intel working on their drivers, and they are more responsive. Also, iflib is coming, and it will move a lot of the stack-facing driver code from the Intel (and other) drivers to a common location. It is much higher performance and far less buggy than the vendor code it replaces. The beauty of the BSD license is that you don't have to contribute back if you don't want to. Some companies contribute at lot. For example, the Netflix contribution of async sendfile, CAM support for NVME, etc.
- alacombe 10y ago
  My experience is not limited to the e1000(4) driver. The device tree driver subsystem is based on hardware model from the early 90s, the mbuf API is plagued with code duplication. Nobody want to touch this because the old guard is pretty much locking these interface. Everybody praise the Lord PHK, but his actual code in the tree is really sub-standard... The way to change things is to do what Adrian Chadd has been doing, sneaking in, and changing stuff behind's people back. The way to contribute to BSD is easy, you have to be big to have enough influence (including monetary wise) to get stuff in. When you are a small nobody, you end up being treated as such. Comparatively, I've had Linus look up at some issue I used to have with Linux USB stack (which were likely local interconnect issue). A world of difference. edit: while I think about it, most large changes in FreeBSD are discussed in private. Public discussion on patch and technical discussion is frowned upon. At the end of the day, the dev submit at 10kloc patch that is unrewiewable, and it gets in with rather poor amount of discussion. The only public discussion held is pretty much bikeshedding. There is way more interesting technical conversation happening in a day on the LKML than will happen in a year on FreeBSD ml.
  - drewg123 10y ago
    The problem with mbufs is that they have been around and been extended since the 80s. And Rototilling the interface will break a LOT of hardware. One of the nice things about iflib is that abstracts mbufs away from drivers. Of course that doesn't help much with crusty old drivers, but it does help some. Having worked on both systems, there are some things I like better about mbufs as compared to skbs. But BSD badly needs the skb frags (eg, attached pages) concept to avoid excessive pointer chasing. We've been using an internal (not shared) patch that puts attached pages into an iovec, but it needs a lot of cleanup before upstreaming. Oddly, I've had just the opposite experience as you. I've always found contributing to FreeBSD much easier. I was the author of network drivers for an IHV (not Intel) at a previous job. FreeBSD was a million times easier to deal with than Linux. I had a commit bit, and just developed my driver in head. Whereas with Linux, submitting even minor patches was a major ordeal thanks to davem and the netdev cabal. The Linux driver was often lacking features as compared to FreeBSD just because getting patches in was so time consuming. There is actually quite a bit of public discussion of patches in Phabricator these days.
    - alacombe 10y ago
      then maybe hardware vendors should contribute their code so that API could be changed all along, instead of keeping it paywalled. Though, I doubt they want people to look at how poor quality they are. And yes, my job was also to "integrate" custom drivers for our appliances bells and whistles (eg. fail-to-wire interfaces, hardware sensors, etc.), in our source tree.
  - toomanythings4 10y ago
    I know a few people who have contributed and none of them are rich or famous. Your own personal experience at a small company apparently is not representative of the world at large.
  - rpgmaker 10y ago
    > edit: while I think about it, most large changes in FreeBSD are discussed in private. Public discussion on patch and technical discussion is frowned upon. Ugh. That sounds pretty bad for an open source OS.
jlarocco 10y ago
> Given that it took me 3 month to have Jack Vogel (then maintainer of the driver) acknowledge there was an uninitialized variable bug in the e1000(4) driver, leading to countless user frustration, despite detailed technical analysis and patch. Let me openly challenge this assertion... The issue ended up being fixed (or actually, buried in a huge patch) without attribution [ed. of course!]. Without seeing the actual conversations, I'm willing to give the guy the benefit of the doubt on this. 3 months isn't too bad of a turn around time, and I'm sure the guys maintaining FreeBSD are busy, so maybe not able to reply to everybody about every little thing. Did you bring up the attribution on the mailing list or anything? Was it just a mistake? Was it a trivial change that could have been made as part of something else? > I've worked for 5 years in a [small] company using FreeBSD as the main development platform, heavily hacking the TCP and network stack. We leached plenty, and didn't contribute a single line back ! Is that really something to brag about? But whatever, you get to use it that way if you want to. Still doesn't change the fact that a lot of companies do contribute back.
tete 10y ago
> I've worked for 5 years in a [small] company using FreeBSD as the main development platform, heavily hacking the TCP and network stack. We leached plenty, and didn't contribute a single line back ! I wanna challenge that with my own experience. Some companies give back, others don't. I don't think it's based on license, but on company culture. If you look at GPL and similar, what you find is that people: - Modify for their own internal stuff, so they don't give anything back (happens with every tool) - Modify and even publish binaries, not contributing back, acting against the license - Modify it and release it in a way to comply with the license, but basically rendering it unusable and where it would be easier to just start from scratch - Modify it and sometimes even release it in an obfuscated manner, sometimes with comments stripped, etc. Now, doesn't prove you wrong. However the sentence starts with "The BSD License Means", which simply hasn't proven as true. Other examples of BSD license are: clang, Ruby, nginx, Go, node.js, OpenSSH, ... Also this would largely apply to other licenses, such as MIT, zlib, etc. as well. The main reason for releasing or not releasing is what the company thinks about it. Maybe they believe competition steals it, maybe they think it will lower maintenance needed for the patchset, maybe they care about broad support for their stuff, maybe they care for people finding and fixing bugs, maybe they wanna show off, etc. Look at FreeBSD Release Notes and Commits. It's filled with companies working on it. There is no doubt that many people don't contribute back, but from my limited personal experience the main factor is the company and I don't know a single case where it was the license deciding that. You could also have your personal Linux patchset. If you just use it on your servers there is NOTHING forcing you to to contribute a single line back.
AckSyn 10y ago
Your company can do that with Linux, too, if they don't deploy it outside of the organization. There's nothing prohibiting any one entity from making a million changes to any of the gnuutils or the kernel if they don't release them.
- danieldk 10y ago
  Indeed. There are also many phone/IoT/embedded device vendors that ship devices with the Linux kernel without ever fulfilling the obligations of the GPL.

drewg123 10y ago

Let's just say that the Intel drivers have a pretty checkered history and your experience was not unique. There are new people at Intel working on their drivers, and they are more responsive. Also, iflib is coming, and it will move a lot of the stack-facing driver code from the Intel (and other) drivers to a common location. It is much higher performance and far less buggy than the vendor code it replaces. The beauty of the BSD license is that you don't have to contribute back if you don't want to. Some companies contribute at lot. For example, the Netflix contribution of async sendfile, CAM support for NVME, etc.

alacombe 10y ago
My experience is not limited to the e1000(4) driver. The device tree driver subsystem is based on hardware model from the early 90s, the mbuf API is plagued with code duplication. Nobody want to touch this because the old guard is pretty much locking these interface. Everybody praise the Lord PHK, but his actual code in the tree is really sub-standard... The way to change things is to do what Adrian Chadd has been doing, sneaking in, and changing stuff behind's people back. The way to contribute to BSD is easy, you have to be big to have enough influence (including monetary wise) to get stuff in. When you are a small nobody, you end up being treated as such. Comparatively, I've had Linus look up at some issue I used to have with Linux USB stack (which were likely local interconnect issue). A world of difference. edit: while I think about it, most large changes in FreeBSD are discussed in private. Public discussion on patch and technical discussion is frowned upon. At the end of the day, the dev submit at 10kloc patch that is unrewiewable, and it gets in with rather poor amount of discussion. The only public discussion held is pretty much bikeshedding. There is way more interesting technical conversation happening in a day on the LKML than will happen in a year on FreeBSD ml.
- drewg123 10y ago
  The problem with mbufs is that they have been around and been extended since the 80s. And Rototilling the interface will break a LOT of hardware. One of the nice things about iflib is that abstracts mbufs away from drivers. Of course that doesn't help much with crusty old drivers, but it does help some. Having worked on both systems, there are some things I like better about mbufs as compared to skbs. But BSD badly needs the skb frags (eg, attached pages) concept to avoid excessive pointer chasing. We've been using an internal (not shared) patch that puts attached pages into an iovec, but it needs a lot of cleanup before upstreaming. Oddly, I've had just the opposite experience as you. I've always found contributing to FreeBSD much easier. I was the author of network drivers for an IHV (not Intel) at a previous job. FreeBSD was a million times easier to deal with than Linux. I had a commit bit, and just developed my driver in head. Whereas with Linux, submitting even minor patches was a major ordeal thanks to davem and the netdev cabal. The Linux driver was often lacking features as compared to FreeBSD just because getting patches in was so time consuming. There is actually quite a bit of public discussion of patches in Phabricator these days.
  - alacombe 10y ago
    then maybe hardware vendors should contribute their code so that API could be changed all along, instead of keeping it paywalled. Though, I doubt they want people to look at how poor quality they are. And yes, my job was also to "integrate" custom drivers for our appliances bells and whistles (eg. fail-to-wire interfaces, hardware sensors, etc.), in our source tree.
- toomanythings4 10y ago
  I know a few people who have contributed and none of them are rich or famous. Your own personal experience at a small company apparently is not representative of the world at large.
- rpgmaker 10y ago
  > edit: while I think about it, most large changes in FreeBSD are discussed in private. Public discussion on patch and technical discussion is frowned upon. Ugh. That sounds pretty bad for an open source OS.

jlarocco 10y ago

> Given that it took me 3 month to have Jack Vogel (then maintainer of the driver) acknowledge there was an uninitialized variable bug in the e1000(4) driver, leading to countless user frustration, despite detailed technical analysis and patch. Let me openly challenge this assertion... The issue ended up being fixed (or actually, buried in a huge patch) without attribution [ed. of course!]. Without seeing the actual conversations, I'm willing to give the guy the benefit of the doubt on this. 3 months isn't too bad of a turn around time, and I'm sure the guys maintaining FreeBSD are busy, so maybe not able to reply to everybody about every little thing. Did you bring up the attribution on the mailing list or anything? Was it just a mistake? Was it a trivial change that could have been made as part of something else? > I've worked for 5 years in a [small] company using FreeBSD as the main development platform, heavily hacking the TCP and network stack. We leached plenty, and didn't contribute a single line back ! Is that really something to brag about? But whatever, you get to use it that way if you want to. Still doesn't change the fact that a lot of companies do contribute back.

tete 10y ago

> I've worked for 5 years in a [small] company using FreeBSD as the main development platform, heavily hacking the TCP and network stack. We leached plenty, and didn't contribute a single line back ! I wanna challenge that with my own experience. Some companies give back, others don't. I don't think it's based on license, but on company culture. If you look at GPL and similar, what you find is that people: - Modify for their own internal stuff, so they don't give anything back (happens with every tool) - Modify and even publish binaries, not contributing back, acting against the license - Modify it and release it in a way to comply with the license, but basically rendering it unusable and where it would be easier to just start from scratch - Modify it and sometimes even release it in an obfuscated manner, sometimes with comments stripped, etc. Now, doesn't prove you wrong. However the sentence starts with "The BSD License Means", which simply hasn't proven as true. Other examples of BSD license are: clang, Ruby, nginx, Go, node.js, OpenSSH, ... Also this would largely apply to other licenses, such as MIT, zlib, etc. as well. The main reason for releasing or not releasing is what the company thinks about it. Maybe they believe competition steals it, maybe they think it will lower maintenance needed for the patchset, maybe they care about broad support for their stuff, maybe they care for people finding and fixing bugs, maybe they wanna show off, etc. Look at FreeBSD Release Notes and Commits. It's filled with companies working on it. There is no doubt that many people don't contribute back, but from my limited personal experience the main factor is the company and I don't know a single case where it was the license deciding that. You could also have your personal Linux patchset. If you just use it on your servers there is NOTHING forcing you to to contribute a single line back.

AckSyn 10y ago

Your company can do that with Linux, too, if they don't deploy it outside of the organization. There's nothing prohibiting any one entity from making a million changes to any of the gnuutils or the kernel if they don't release them.

danieldk 10y ago
Indeed. There are also many phone/IoT/embedded device vendors that ship devices with the Linux kernel without ever fulfilling the obligations of the GPL.