6 ms·

> But think about what attracted you to Linux in the first place. [...] It was probably a sense of freedom, the promise of a more robust, more secure, more priv

> But think about what attracted you to Linux in the first place. [...] It was probably a sense of freedom, the promise of a more robust, more secure, more private system. OpenBSD is just the next step on that ladder Although I agree that OpenBSD can offer a cleaner experience if you are willing to compromise on the software you use, when it comes to freedom, I would not consider OpenBSD the next step on the ladder. Of course this is a very personal and philosophical question, but a very significant difference to Linux is the permissive BSD licensing used by OpenBSD. In my opinion the GNU licensing is a big reason why GNU/Linux got so successful since it pushed big companies like IBM to feed their contributions back into the GNU/Linux ecosystem.

upofadown 7y ago
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.
- 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.
FPGAhacker 7y ago
I think that the GPL did contribute in a major way to Linux’ success, but for different reasons. I think its contribution was that it was a palatable license for strong believers in open source. I think it was about how people felt more so than a direct impact. People felt good about the idea that people and corps that would use the software would need to contribute back. And so they were more free in their own contributions, as well as feeling good about using the software.

upofadown 7y ago

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.
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.

FPGAhacker 7y ago

I think that the GPL did contribute in a major way to Linux’ success, but for different reasons. I think its contribution was that it was a palatable license for strong believers in open source. I think it was about how people felt more so than a direct impact. People felt good about the idea that people and corps that would use the software would need to contribute back. And so they were more free in their own contributions, as well as feeling good about using the software.