Any growing project will always suffer from consistency problems -- humans just aren't capable of scaling to the point where a single hierarchy can consistently manage a monstrously large system. Linux doesn't have a 'base system' quite like OpenBSD: coreutils, libc, bash, and 20 other similar packages all come from a large variety of differently minded maintainers across the world.
Viewed from a macro scale, OpenBSD's consistency breaks down immediately upon starting to install stuff from the ports collection - sure the base system makes a great firewall and basic HTTP server, but to use anything popular you pretty much immediately end up with ports. And the quality standards there are identical to Linux land, because it's the same code.
sendmsg(2), sendto(2), recvfrom(2) and recvmsg(2) are run without KERNEL_LOCK.
The lock is being removed, slowly with care, piece by piece.
Yes, and goals. OpenBSD is much more conservative with regard to features, and focuses on security, and that results in a more secure system overall. If you need to eek out every last percent of performance, use something else. If you want to worry less about security on a system that is fairly exposed (e.g. a firewall), then it can be an extremely good fit. For example, here's a comparison of security advisories for the main OpenBSD, FreeBSD and Linux projects (that is, not separated and exported items like OpenSSH).[1][2] While I'm sure these lists have their problems, they are interesting. Specifically, the number of exploits column...
1: https://www.cvedetails.com/product/7/Freebsd-Freebsd.html?ve...
2: https://www.cvedetails.com/product/163/Openbsd-Openbsd.html?...
3: https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
* Electron apps - VSCode, Atom, Slack, almost every universal desktop app that gets released today. Individual ports of apps to FreeBSD exist, but there is no way to automatically build Electron apps for any of the BSDs.
* Good desktop virtualization - KVM, VirtualBox (okay FreeBSD has these in theory), VMware
* First-class Docker and desktop container support (FreeBSD jails exist but there is no container ecosystem like there is on Linux)
You can still run Firefox, mail clients, vim/emacs, Unix utilities and LibreOffice on any of the BSDs just fine. They're lacking other niceties however. And that's a bad thing in my opinion - although it's mostly not the fault of any of these projects. Some people think BSD is better for lacking those options, but I can't live without them for one.
It's unfortunate: Linux and the BSDs used to have more or less the same application support. Anything Unix-y ran on anything Unix-y. There was nothing stopping you from having an OpenBSD desktop almost identical in function as, say, a Xubuntu desktop - one that looked much cleaner on the inside. But once broader commercial interest started happening for Linux, the BSDs were mostly left by the wayside in application support.
The areas where OpenBSD can compete (in addition to the ones it already fights in, like routing and network-edge roles) are cloud deployments and orchestration. If it were as easy to run OpenBSD for development as it is a containerized Linux, people would pick the more secure choice. They could also make prebuilt appliances for the most sensitive components in a deployment (databases etc).
Now what exactly created this divide to begin with is a matter of debate but it took place mostly in the 90's and the very early 00's. By the mid 2000's it was clear that BSDs would have a really hard time ever catching up with Linux, especially for non-server applications.
Paradoxically it might be partially why BSDs are so clean and tidy: fewer features, fewer contributors and of course they're making a complete operating system instead of just a kernel or just a distribution.
FreeBSD remains my favourite OS for servers, it's rock solid and a joy to administrate. Unfortunately for the desktop I've given up almost a decade ago, driver support is just too lackluster, especially (as you mention) for proprietary software that can't be easily ported.
The Linux users gave back (often because they had to) and the BSD users often didn't.
So in the long run it is back to the old freeware days, with the lower lever free and everything on top closed, with zero contributions.
Sendmail, postfix and qmail all had BSD-ish licenses, and those three covered quite a majority of all opensource mail serving at the time of BSD-vs-Linux "in the same early years"
So, nah, it's not the license.
vmctl create disk1.img -s 10G
vmctl start vm1 -d disk1.img -b /bsd.rd -L -cGood! On FreeBSD, for now, sanity prevails!
This is one of many reasons not to use Electron. Claims of Electron portability are a sham.
However, when it comes to running scientific applications and squeezing out last bits of performance or servers where people expect stuff to "just work, and if doesn't do apt-get blah", it's Linux that takes the cake.
FreeBSD and ZFS - the best I've worked with for Network Attached Storage. Can't believe it is just free.
ZFS file server: https://aravindh.net/post/zfs_fileserver/
ZFS file server performance: https://aravindh.net/post/zfs_performance/
Linux has become a chaotic place to be, I agree.
Linux is terribly balkanized what with all the competing distros. There are no standards. This is one reason why Linux has not taken off on the desktop outside of tech circles.
systemd. It violates almost every *nix tenet out there, especially "a program should do one thing well". It's has a few benefits, but the negatives outweigh these, namely more and more programs outside of the base system now require systemd. This should never be. I and millions of others agree that an init system should be able to be tweaked as text files. Not happening now. The logs are stored as binaries when they should be plain text. Debugging is more difficult. A program should do one thing well. Full stop. There is always BSD and Slackware, and I don't think Slackware will adopt systemd, as their user base doesn't want it. Slackware is the oldest currently-developed Linux distro out there and the vast majority of users want it to remain true to its roots while still advancing.
[1] https://www.gnu.org/software/shepherd/ [2] https://www.gnu.org/software/guix/guix.html [3] https://www.phoronix.com/forums/forum/phoronix/general-discu...
I _really_ enjoy being able to apt-get or brew install pretty much any of the applications out there and am a bit worried about how that experience would be on OpenBSD. I guess the best way to find out would be to try it eh? :)
https://man.openbsd.org/fw_update.1
It basically requires you to copy the firmware to a USB stick and run the tool and then Wireless just works.
Personally, I’d be more interested into having openbsd as the standard for cloud deployments, a place currently inhabited by Ubuntu derivatives. If one could get the declarative goodness of Nix, the popularity of docker, and the reliability / security of openbsd, the world would be a better place.
I ended up having to switch to Slackware, though; lots of stuff I have to use for work that simply doesn't run on OpenBSD. If vmm gets to the point where I'm able to run Linux desktop apps with reasonable performance (and ideally a reasonable degree of integration with the rest of the system) I might try switching back.
You can search NYC*BUG board, where users submit their dmesg(8) output, e.g. there is a submission[1] for Dell Latitude e7270.
My most recent laptop upgrade ran like this: http://bsdly.blogspot.com/2017/07/openbsd-and-modern-laptop....
OpenBSD is great, of course, but my favorite thing about open source is the cross collaboration. Rather than dump literal decades of constant refinement to Linux and it's ecosystem because OpenBSD is much more elegant seems unwise. There are things Linux and the general Linux stacks could learn from OpenBSD (and should.)
I don't think the world would be better if OpenBSD were in the position Linux is in today (though I have a hunch the security story around FOSS stacks would be better.) I think there is a lot of good that Linux can do with its more fast-and-loose organizational structure.
Which makes half of the news today. So, yes, world would be a bit better today if only ..
Of course, a base OpenBSD installation is wonderful to work with and the damage can be minimized through the careful selection of packages.
I'm not sure that's fair.
Linux has snowballed, whereas OpenBSD hasn't. Linux is a much larger system. Is it surprising you find OpenBSD to be tidier?
Companies extend the BSD OSs with proprietary additions, then abandon the work and it gets lost. With Linux, everyone is forced to play nice and release under the GPL, and the work gets to live as long as people value it.
Hence the Linux kernel snowballing and taking over the world, whereas the BSDs have not, despite being at least as strong technically.
The better Linux gets, the more people target it, and the virtuous cycle continues.
Additionally, as it grows bigger and bigger, the more of the proprietary competition it crushes underfoot (sorry Solaris), and the more traction FOSS gets.
1. The BSDs adoption was severely hurt in the 90s by the AT&T lawsuit, it basically stopped several years of development while the lawsuit legal status was clarified. Linux and the GNU tooling didn't have that problem. If the lawsuit never took place it is doubtful whether the Linux kernel would have got as much interest as it did at the time.
2. If you don't keep up contribute your changes back to upstream (whatever the license) eventually you will be left behind and have to maintain your own incompatible version. It is in your interest to send upstream patches.
3. GPL code gets stolen all the time and put into propriety software. I've worked at loads of places that have just straight out cut and pasted GPL code into their own product (usually this is done without management's approval). Large projects such as the Linux kernel companies can't really get away with it. However a lot of companies don't build software for the masses, most build bespoke software that is only deployed on one or two servers on a company intranet and the general public will never see it. A lot of developers will just straight up steal code (not caring about the license) from wherever. A surprising number of companies still don't even use source control, let alone bother reviewing code.
4. Companies do contribute back to BSD licensed projects, however this is normally financially not through patches.
I thought that, in this case, it's the company itself who is the "user" of the software and isn't obligated to do anything to/for/about upstream (since there is no stream.. they're not re-distributing it). In that sense, they're not stealing anything, just using what was, explicitly, free to use.
You would be right if it was PHP / Python or something else that was interpreted.
The real point to take away is that any modifications will never reach upstream.
How is it any different from an individual making changes to GPL software and using it (compiler or interpretted) on a personal computer? Surely that individual isn't obligated to share anything, either.
> The real point to take away is that any modifications will never reach upstream.
The GPL doesn't mention, AFAIK, any such concept. I thought the point was freedom for users of software, not implied benefit to some "upstream" programmer.
IOW, since the GPL is about the user, it's about protecting "downstream" and, without redistribution, there's none to protect.
>The GPL doesn't mention, AFAIK, any such concept. I thought the point was freedom for users of software, not implied benefit to some "upstream" programmer.
The OP specifically said that one of the benefits of the GPL is people had to contribute back because they have to make the code public. As we have discovered they don't.
Indeed, that wasn't at all clear. The comment to which I was responding only used the word "company" (singular and plural), without any modifiers, which I read as describing the same party.
That clears up some of my confusion, since that's an obvious violation (assuming source code wasn't available to those same 3rd parties, which you also didn't explicitly state).
> The OP specifically said that one of the benefits of the GPL is people had to contribute back because they have to make the code public.
Such an assertion (which I see in neither ancestor comments nor the article) still seems mistaken, so perhaps it's a strawman?
The GPL, IIUC, is meant to protect the user, aka downstream, not provide benefits to "upstream". If the binary itself isn't made public, then the source code need not be, either (though I suppose the user/customer in your scenario would have the freedom to choose to make it public, they have no obligation and little, if any, incentive).
> Companies extend the BSD OSs with proprietary additions, then abandon the work and it gets lost. With Linux, everyone is forced to play nice and release under the GPL, and the work gets to live as long as people value it.
'Secret' purely internal use of modified GPL software is not a violation - if the modified software is never distributed publicly, there's no issue.
(The Affero GPL licence is different in that regard, and was developed as a response to the software-as-a-service trend, but we're discussing the plain old GPL.)
Imperfect enforcement is a valid point, but the terms of the GPL are effective at least some of the time. Major technology companies do not want copyright scandals, even if plenty of fly-by-night companies are willing to risk it.
As the parent pointed out, purely-internal isn't what he meant. Distribution can be non-public, which is distribution nonetheless. Such distribution would require availability of source, but that availability wouldn't be public, if the original distribution wasn't public.
The parent seems to be focusing on "theft" (GPL violation) by relatively-unknown companies, which didn't necessarily occur. It's plausible that it did, but, even if the violation were corrected, since that correction doesn't require public release of source code, is likely irrelevant to the overall discussion.
You seem to be focusing only on publically-released software, which may or may not be the majority (by whatever measure).
I have no "side" in this, just trying to understand the points, which I've failed to grasp. Are you talk past each other?
The point that you keep on ignoring is that the OP said "companies have to contribute back". One of my points is that they don't even do it though they legally should.
License arguments wasn't the point of my response. The point is that people will abuse goodwill and pretending that it doesn't happen is naive.
You didn't say so, and, even now, you're only implicitly saying there was a GPL violation. The details are important, in order to further understanding.
> The point that you keep on ignoring is that the OP said "companies have to contribute back".
I'm pretty sure I'm not ignoring it, because it didn't happen. That's likely the source of my confusion. You've certainly said so repeatedly, but I'm missing where anyone else in the conversation has said so (hence my thinking it's a strawman).
> One of my points is that they don't even do it though they legally should.
This does sound like you are, again, saying there are circumstances where contributing "back" is legally required, which is the assertion that prompted my own original response. I don't believe those circumstances ever exist. The only obligation is providing (contributing) source code forward. Only when "forward" is the public at large does that end up being, as a side effect, "back".
> The point is that people will abuse goodwill and pretending that it doesn't happen is naive.
I doubt anyone here is actually naive enough to believe it never happens, but there may be a belief that it's rare or exceptional. Without large-sample-size evidence, this can be short-circuited to the usual cynicism vs. "people are basically good" argument.
NOPE. The context is the original posters words. We are talking about that and I am saying that contributing back doesn't happen magically because of the GPL.
I suggest you learn to keep the context of the argument in mind rather than keep focusing on being pedantic.
I am done with this conversation now.
Since those words never mentioned contributing back, I was, understandably confused.
> I am saying that contributing back doesn't happen magically because of the GPL.
I don't see where anyone was saying otherwise, ergo you're arguing against a strawman.
> keep the context of the argument in mind rather than keep focusing on being pedantic
That only works for making a (counter-)argument, not attempting to understand the argument(s) in the first place.
In the instant case, I'm now convinced that any disagreement was based on a flawed premise, or there was no disagreement at all. My understanding of hwo the GPL functions (and is intended to function) remains unchanged.
> Yes, you're reading me right, but I skipped over the question of software which is never released publicly - mmt is correct that the GPL does not require public release of works, instead it prevents you from releasing the binaries while withholding the source.
The fact it doesn't prevent you from doing that. It only really prevents large companies that people are watching.
Violations happen all the time. They just happen on smaller GPL projects.
> 'Secret' purely internal use of modified GPL software is not a violation - if the modified software is never distributed publicly, there's no issue.
The impression I get is that GPL advocates like yourself seem to think that the unwashed developers that work on proprietary code don't understand the GPL and have to be constantly told how a software license works. You aren't an enlightened individual because you understand a software license. I understand the license and the arguments about it just fine.
There is an issue with stuff not going back to upstream. If a defect fix only happens in downstream that is generic enough that it should benefit everyone then only downstream benefits, this things don't get contributed back and there is no improvement of upstream.
> Imperfect enforcement is a valid point, but the terms of the GPL are effective at least some of the time. Major technology companies do not want copyright scandals, even if plenty of fly-by-night companies are willing to risk it.
The flyby night companies as you put it are the majority, not the minority. If it isn't a big project most companies won't get found out.
Again GPL doesn't magically make people contribute back, which was my original disagreement with your comment.
That's my understanding, as well, but that was never asserted, only "play nice", (re-)"release under the GPL", and "gets to live as long as people value it" as you were able to quote upthread.
This seems like contributing forward, not back, or downstream, not upstream.
The eventual effect, for publically-released software, usually ends up being an upstream contribution, but that's not automatic.
I'm not an advocating any particular license, but it does seem like you're responding to a strawman that nobody in this subthread (GPL advocate or not) has argued.
Apparently I am responding to a strawman after the OP actually replied and said my assessment of what they said was correct.
This is why I dislike speaking to the FSF crowd. It is much like a religion (as far as I am concerned).
Licenses don't work like you think they do. In fact, they work backwards: the decision whether to release the source or not doesn't depend on the license, it's the license - and thus the choice of existing software to base your work on - that depends on the decision on whether not to release the source.
BSD makes it possible to release your changes if - and when - you see fit. GPL - doesn't. That's why companies like Sony or Juniper couldn't base their products on Linux. Sure, Sony doesn't give back - but eg Juniper does.
This is Torvalds' idea, not mine [0] (though he doesn't speak to Linux-vs-BSD directly)
> Sure, Sony doesn't give back - but eg Juniper does.
But in aggregate, Linux has taken over the world, and BSD hasn't. The 'snowball' effect is real.
[0] https://www.cio.com/article/3112582/linux/linus-torvalds-say...
I hope they didn't. But if they try, triple check, or better rewrite :)
These systems do things that Linux just can't.
Linux is no RTOS, nor does it have a pure microkernel architecture. It can't do anything where latency guarantees are needed (hard realtime) nor high assurance, nor any actual semblance of security.
I suggest these posts: https://microkerneldude.wordpress.com/2018/08/23/microkernel... https://blog.darknedgy.net/technology/2016/01/01/0/
There's far enough technical reasons to ditch Linux for a cleaner design.
I don't see any proprietary Unix seriously competing with Linux any time soon though.
As for competition with proprietary UNIX, probably not against Aix or HP-UX as they survive on maintenance contracts for big customers like banks and telecommunication companies, but Linux is still no match for high integrity computing OSes, many of which are micro-kernels with POSIX userspace available as possible API.
Yes, I know - but the software which ends up getting deployed/used/sold will be proprietary forks, right? That's the whole point: the licence is friendly to proprietary forks.
> Linux is still no match for high integrity computing OSes
Sure, VxWorks is safe.
That goes beyond strawman.
Try reading: https://microkerneldude.wordpress.com/2018/08/23/microkernel...
For as long as Linux is a monolithic design, the whole kernel is going to be part of the TCB.
And thus, you should be skeptical of any claims of Linux providing security.
It's a strawman when I agree with someone?
> And thus, you should be skeptical of any claims of Linux providing security.
When did I say Linux has perfect security?
I presume the point you're trying to make is that different operating systems, with different architectures, can beat Linux in various regards. Of course this is correct. But for a general-purpose multi-platform Unix-like OS, Linux is king, and will be for the foreseeable future.