6 ms·

The downside to the GPL in the case of Linux is that it really works well ... which is an odd thing to say. It has become a giant software cooperative with, as

The downside to the GPL in the case of Linux is that it really works well ... which is an odd thing to say. It has become a giant software cooperative with, as you say, lots of software contributions from lots of companies. As a result the Linux ecosystem suffers from the downsides of commercially driven software development. You can end up with poorly written code generated by unqualified people that addresses short term business needs. Such code tends to be abandoned quickly by its sponsor which causes long term maintenance problems. In the Linux ecosystem, stuff tends to go bad quietly in the darkness. There is no good motivator to produce documentation for anything in the Linux world. Giant, useful, and well written systems get dropped in and end up being more or less useless because only the originator can actually figure out how to use them. The BSDs run off of good old fashioned ego driven software development done by people who care deeply about software. They don't care that much about how others exploit it, only that it is good. It turns out that there are upsides to getting a group of such people together to to work on OS stuff.

oblio 7y ago
> The BSDs run off of good old fashioned ego driven software development done by people who care deeply about software. On the other hand, ego driven software development can also freeze technologies or development processes to what the main ego(s) want(s). Case in point, FreeBSD, NetBSD, OpenBSD and CVS. And even they will admit CVS is sub-optimal for development, see: https://wiki.freebsd.org/VCSWhy https://wiki.freebsd.org/VCSWhy, https://wiki.freebsd.org/VCSCvsProblems https://wiki.freebsd.org/VCSCvsProblems. Note: I'm not saying Git is the solution, but CVS is bad. They should at least use SVN or any of the many systems that have learned from CVS' mistakes. TL;DR: Pick your poison regarding development practices.
- messe 7y ago
  FreeBSD has used SVN since ~2012-2013 I believe.
  - oblio 7y ago
    That's good to know, but that wiki article was last modified in 2018. It's a bit confusing...
    - irishsultan 7y ago
      I believe it was moved to a "Historical" category at that time
    - tachion 7y ago
      Very recently (last few days) the FreeBSD project formed an internal group with a task of reevaluating, planning and testing the migration from SVN to Git.
  - bojanz 7y ago
    And a migration to git is being evaluated: https://twitter.com/lattera/status/1132084341213933569 https://twitter.com/lattera/status/1132084341213933569 DragonFly BSD, a FreeBSD 4.x fork, has also used git successfully since early 2009, I believe.
    - tachion 7y ago
      I'd refrain from using this person as any indication on what's happening in FreeBSD - he's known to be openly hostile against FreeBSD and making many repetitive false statements about it, after feeling hurt by the project rejecting his low quality and poorly written 'security' patches.
      - anjbe 7y ago
        That’s certainly an interpretation. George Neville‐Neil, president of the FreeBSD foundation, recently gave the keynote at AsiaBSDCon. During his presentation he derided Sean Webb/Lattera for its focus on security (https://hardenedbsd.org/content/easy-feature-comparison https://hardenedbsd.org/content/easy-feature-comparison), simultaneously deriding OpenBSD as “basement dwellers” (this in a talk asserting that the BSDs need to present a unified front to succeed in the world). He also made excuses for the fact that FreeBSD finally—finally!—implemented ASLR in 2019. (For reference, PaX developed ASLR in 2001, OpenBSD implemented their own in 2003, and mainstream Linux got it in 2005.) His excuse, that ASLR is “broken anyway,” was called out by the very first commenter for betraying a complete misunderstanding of what ASLR defends against (GNN trumpeted ASLR attacks on JIT engines, but executing malicious JavaScript on the host is out of ASLR’s scope and always has been). https://youtu.be/7kShjboN6ek?t=2820 https://youtu.be/7kShjboN6ek?t=2820 I don’t know the full story between Sean Webb/Lattera and FreeBSD, but I do know FreeBSD has a poor track record when it comes to security mitigations, and if the presentation above is representative of how the president of the FreeBSD Foundation behaves at an ostensibly cross‐BSD conference, I know which side I’m immediately inclined to disfavor.
- busterarm 7y ago
  CVS may be "bad", but it's clearly working for the OpenBSD project and they have released roughly every six months like clockwork.
  - oblio 7y ago
    Things can go on for very long periods of time until they suddenly burst. What happens when the current developers retire? I doubt there's any software dev born in 1990 and later that wants to touch CVS, especially for a hobby project.
    - busterarm 7y ago
      Except OpenBSD gets new contributors all the time. A decent number are in uni or grad school, which basically contradicts your suggestion entirely. We contribute to OpenBSD because we care about the goals of the project and that motivates learning and dealing with CVS.
    - Crinus 7y ago
      You make it sound like CVS kills children. People worked with CVS just fine for decades and OpenBSD has made their own tools for CVS to improve their development experience and, frankly, if a developer - regardless of age, lets not get into age discrimination here - finds CVS a roadblock to working on OpenBSD, they are simply not a good developer.
      - microcolonel 7y ago
        > If a developer - regardless of age, lets not get into age discrimination here - finds CVS a roadblock to working on OpenBSD, they are simply not a good developer. While we're at it, if a developer finds ed (the standard text editor) a roadblock to working on OpenBSD, they are simply not a good developer. Why is somebody "not a good developer" if they don't want to work with tools which are an insult to the priorities and humanity of the user†, for no good reason, when they could go to Linux and have 99% of what's good about OpenBSD, without the cult of GCC 4.2-justifying, CVS masochists? I love OpenBSD, but the self-defeating goober decisions clearly reduce the number of people willing to become the experts needed to push the project forward. So much of OpenBSD is user-friendly, as long as that user reads the manual; but CVS is among the most user-hostile version control systems any living developer remembers using, and even if you know exactly what you're doing CVS is still an inconvenience because of centralization, and because of the amount of clerical work required to get it to operate properly. † In the context of a world full of spectacular alternatives; obviously this doesn't apply to a time when CVS was a cut above.
- upofadown 7y ago
  Changing from CVS to something else would mean updating a lot of documentation ... which perhaps is an example of a downside to the BSD way of doing things (the way things are built from source I mean, actually having documentation is good).
  - oblio 7y ago
    They wouldn't be the first open source project to migrate their source control. There's some which switched a few times, even.
hpcjoe 7y ago
> You can end up with poorly written code generated by unqualified people that addresses short term business needs. Such code tends to be abandoned quickly by its sponsor which causes long term maintenance problems. In the Linux ecosystem, stuff tends to go bad quietly in the darkness. Care to provide an example of this? I've heard critiques of Linux's model that were basically FUD attempts by others in the past, that sound strikingly similar to this sentence. The FUD was about security holes that could be "snuck" into the code, when no one was looking. For anyone with a cursory knowledge of the actual process, there is an understanding that this generally cannot and does not happen. The process is specifically design to keep 'poorly written code' from entering in the kernel. You may be talking about user-space. There, the code quality is largely a function of the maintainers and their processes. No specific OSes user space is immune to this, c.f. OpenSSL. So, put another way, I'm not buying that argument. > The BSDs run off of good old fashioned ego driven software development done by people who care deeply about software. This may be the most cringe-worthy statement I've seen posted on HN in a while. Ego/hero driven development is an antipattern you would like to avoid. Suppose your hero/massive ego person decides that they don't like X, being some thing that industry as a whole, has adopted. As a result, no progress is made on X, proposals to deal with X have been generally slapped down, or slow walked. Because the ego/hero involved doesn't like it. This isn't theoretical for me, I've seen this upfront and personal recently. This attitude, combined with several co-morbid positions, lead to outcomes that no one wants.
microcolonel 7y ago
> You can end up with poorly written code generated by unqualified people that addresses short term business needs. Given the high standards I've seen Linux maintainers uphold over the years, and experience trying to write kernel code which is good enough for just my installation, I don't really tend to agree that the software is being written by "unqualified people" could push code into the kernel to "[address] short term business needs". Not really sure what kernel you're looking at, I'm looking at the one where AMD's display configuration codebase, which they had conveniently repurposed from their proprietary cross-platform equivalent, was reviewed thoroughly and needed to be dramatically reworked to meet the standards of the kernel maintainers; business convenience be damned.
rauhl 7y ago
I suspect that the difference in quality & simplicity between OpenBSD & Linux is less a matter of license than historical accident. Given two identical projects with identical contributor profiles, differing only in license, I don’t expect that you’d see any difference in quality. However, in the real world I think that the GNU world has long had a tendency to add feature upon feature (which is nice) and to treat each subproject in isolation (which is less nice) which can lead to fragmentation across the GNU Project as a whole (which is very much Not Nice). While Linux is of course not part of the GNU Project, it is the kernel of a GNU system, and the Linux kernel on its own is not terribly useful. Meanwhile, the BSDs have always been integrated systems. There’s not reason inherent in the license that they are — they just are, and since they are they continue to be.

oblio 7y ago

> The BSDs run off of good old fashioned ego driven software development done by people who care deeply about software. On the other hand, ego driven software development can also freeze technologies or development processes to what the main ego(s) want(s). Case in point, FreeBSD, NetBSD, OpenBSD and CVS. And even they will admit CVS is sub-optimal for development, see: https://wiki.freebsd.org/VCSWhy https://wiki.freebsd.org/VCSWhy, https://wiki.freebsd.org/VCSCvsProblems https://wiki.freebsd.org/VCSCvsProblems. Note: I'm not saying Git is the solution, but CVS is bad. They should at least use SVN or any of the many systems that have learned from CVS' mistakes. TL;DR: Pick your poison regarding development practices.

messe 7y ago
FreeBSD has used SVN since ~2012-2013 I believe.
- oblio 7y ago
  That's good to know, but that wiki article was last modified in 2018. It's a bit confusing...
  - irishsultan 7y ago
    I believe it was moved to a "Historical" category at that time
  - tachion 7y ago
    Very recently (last few days) the FreeBSD project formed an internal group with a task of reevaluating, planning and testing the migration from SVN to Git.
- bojanz 7y ago
  And a migration to git is being evaluated: https://twitter.com/lattera/status/1132084341213933569 https://twitter.com/lattera/status/1132084341213933569 DragonFly BSD, a FreeBSD 4.x fork, has also used git successfully since early 2009, I believe.
  - tachion 7y ago
    I'd refrain from using this person as any indication on what's happening in FreeBSD - he's known to be openly hostile against FreeBSD and making many repetitive false statements about it, after feeling hurt by the project rejecting his low quality and poorly written 'security' patches.
    - anjbe 7y ago
      That’s certainly an interpretation. George Neville‐Neil, president of the FreeBSD foundation, recently gave the keynote at AsiaBSDCon. During his presentation he derided Sean Webb/Lattera for its focus on security (https://hardenedbsd.org/content/easy-feature-comparison https://hardenedbsd.org/content/easy-feature-comparison), simultaneously deriding OpenBSD as “basement dwellers” (this in a talk asserting that the BSDs need to present a unified front to succeed in the world). He also made excuses for the fact that FreeBSD finally—finally!—implemented ASLR in 2019. (For reference, PaX developed ASLR in 2001, OpenBSD implemented their own in 2003, and mainstream Linux got it in 2005.) His excuse, that ASLR is “broken anyway,” was called out by the very first commenter for betraying a complete misunderstanding of what ASLR defends against (GNN trumpeted ASLR attacks on JIT engines, but executing malicious JavaScript on the host is out of ASLR’s scope and always has been). https://youtu.be/7kShjboN6ek?t=2820 https://youtu.be/7kShjboN6ek?t=2820 I don’t know the full story between Sean Webb/Lattera and FreeBSD, but I do know FreeBSD has a poor track record when it comes to security mitigations, and if the presentation above is representative of how the president of the FreeBSD Foundation behaves at an ostensibly cross‐BSD conference, I know which side I’m immediately inclined to disfavor.
busterarm 7y ago
CVS may be "bad", but it's clearly working for the OpenBSD project and they have released roughly every six months like clockwork.
- oblio 7y ago
  Things can go on for very long periods of time until they suddenly burst. What happens when the current developers retire? I doubt there's any software dev born in 1990 and later that wants to touch CVS, especially for a hobby project.
  - busterarm 7y ago
    Except OpenBSD gets new contributors all the time. A decent number are in uni or grad school, which basically contradicts your suggestion entirely. We contribute to OpenBSD because we care about the goals of the project and that motivates learning and dealing with CVS.
  - Crinus 7y ago
    You make it sound like CVS kills children. People worked with CVS just fine for decades and OpenBSD has made their own tools for CVS to improve their development experience and, frankly, if a developer - regardless of age, lets not get into age discrimination here - finds CVS a roadblock to working on OpenBSD, they are simply not a good developer.
    - microcolonel 7y ago
      > If a developer - regardless of age, lets not get into age discrimination here - finds CVS a roadblock to working on OpenBSD, they are simply not a good developer. While we're at it, if a developer finds ed (the standard text editor) a roadblock to working on OpenBSD, they are simply not a good developer. Why is somebody "not a good developer" if they don't want to work with tools which are an insult to the priorities and humanity of the user†, for no good reason, when they could go to Linux and have 99% of what's good about OpenBSD, without the cult of GCC 4.2-justifying, CVS masochists? I love OpenBSD, but the self-defeating goober decisions clearly reduce the number of people willing to become the experts needed to push the project forward. So much of OpenBSD is user-friendly, as long as that user reads the manual; but CVS is among the most user-hostile version control systems any living developer remembers using, and even if you know exactly what you're doing CVS is still an inconvenience because of centralization, and because of the amount of clerical work required to get it to operate properly. † In the context of a world full of spectacular alternatives; obviously this doesn't apply to a time when CVS was a cut above.
upofadown 7y ago
Changing from CVS to something else would mean updating a lot of documentation ... which perhaps is an example of a downside to the BSD way of doing things (the way things are built from source I mean, actually having documentation is good).
- oblio 7y ago
  They wouldn't be the first open source project to migrate their source control. There's some which switched a few times, even.

hpcjoe 7y ago

> You can end up with poorly written code generated by unqualified people that addresses short term business needs. Such code tends to be abandoned quickly by its sponsor which causes long term maintenance problems. In the Linux ecosystem, stuff tends to go bad quietly in the darkness. Care to provide an example of this? I've heard critiques of Linux's model that were basically FUD attempts by others in the past, that sound strikingly similar to this sentence. The FUD was about security holes that could be "snuck" into the code, when no one was looking. For anyone with a cursory knowledge of the actual process, there is an understanding that this generally cannot and does not happen. The process is specifically design to keep 'poorly written code' from entering in the kernel. You may be talking about user-space. There, the code quality is largely a function of the maintainers and their processes. No specific OSes user space is immune to this, c.f. OpenSSL. So, put another way, I'm not buying that argument. > The BSDs run off of good old fashioned ego driven software development done by people who care deeply about software. This may be the most cringe-worthy statement I've seen posted on HN in a while. Ego/hero driven development is an antipattern you would like to avoid. Suppose your hero/massive ego person decides that they don't like X, being some thing that industry as a whole, has adopted. As a result, no progress is made on X, proposals to deal with X have been generally slapped down, or slow walked. Because the ego/hero involved doesn't like it. This isn't theoretical for me, I've seen this upfront and personal recently. This attitude, combined with several co-morbid positions, lead to outcomes that no one wants.

microcolonel 7y ago

> You can end up with poorly written code generated by unqualified people that addresses short term business needs. Given the high standards I've seen Linux maintainers uphold over the years, and experience trying to write kernel code which is good enough for just my installation, I don't really tend to agree that the software is being written by "unqualified people" could push code into the kernel to "[address] short term business needs". Not really sure what kernel you're looking at, I'm looking at the one where AMD's display configuration codebase, which they had conveniently repurposed from their proprietary cross-platform equivalent, was reviewed thoroughly and needed to be dramatically reworked to meet the standards of the kernel maintainers; business convenience be damned.

rauhl 7y ago

I suspect that the difference in quality & simplicity between OpenBSD & Linux is less a matter of license than historical accident. Given two identical projects with identical contributor profiles, differing only in license, I don’t expect that you’d see any difference in quality. However, in the real world I think that the GNU world has long had a tendency to add feature upon feature (which is nice) and to treat each subproject in isolation (which is less nice) which can lead to fragmentation across the GNU Project as a whole (which is very much Not Nice). While Linux is of course not part of the GNU Project, it is the kernel of a GNU system, and the Linux kernel on its own is not terribly useful. Meanwhile, the BSDs have always been integrated systems. There’s not reason inherent in the license that they are — they just are, and since they are they continue to be.