Open source community split over offer of 'corporate' welfare for critical dev tools

Open source community split over offer of 'corporate' welfare for critical dev tools

Linux Foundation presents IT and help to key volunteers – and some wonder if this is a deal with the Devil


Special report The free and open source software (FOSS) community is caught in a love triangle of sorts.

Sourceware, a volunteer group that has been supporting various critical FOSS developer tools for more than two decades, is being courted by The Linux Foundation's Open Source Security Foundation (OpenSSF). The OpenSSF aims to improve open source software security by providing Sourceware projects with more modern IT infrastructure.

But some members of the Sourceware community fear that accepting the help of the OpenSSF would give the corporate Linux world more leverage over FOSS developer tools. They would prefer to seek support from the Software Freedom Conservancy, a charitable non-profit that they believe is better aligned with software freedom.

The Linux Foundation, also a non-profit entity, is sponsored by, among others, Microsoft, Google, and Verizon; the conservancy is supported by Google, Mozilla, and others.

This clumsy community courtship has been contemplated for years and coalesced into a proposal in September, leading participants in the FOSS community to debate what patronage is appropriate and desirable. The outcome – how developer tools like the GNU Compiler Collection (GCC) are hosted and who pays for it – will have consequences, for better or worse.
Lighting the touch paper

At the end of August, systems software developer Frank Ch. Eigler sent a note to the Sourceware overseers mailing list announcing that the 24-year-old open source project had reached out to the Software Freedom Conservancy (SFC) for financial support.

Sourceware hosts a variety of free and open source (FOSS) software projects, including developer tools for the GNU Project, such as GCC, GDB, glibc, Binutils, and GNATS, and others. These are critical components in the open source ecosystem.

Eiger insisted the project's current infrastructure, provided by IBM's Red Hat, is fine. "Things are stable, new services are coming online, and users seem to be happy," he wrote. "However, it is always good to think about any future needs."

Planning for those needs is well under way. In a presentation at OpenJS World 2022 back on June 24, Brian Behlendorf, general manager of OpenSSF, described Sourceware projects as if they were held together by spit and string – something of a common trope for the trade.

"The build servers and the really critical pieces that are involved in the development of GCC, glibc, GDB – the fundamentals that enable things like the Linux kernel and the Linux operating systems and almost all the other interpreters for other languages that we build on top of – needed a bit more rigor," he said.

"It needed a bit more of what we have for the Linux kernel in terms of build systems. And so we've been working with that community to better support the build systems that everybody depends upon to be locked down and hardened."

Over the past few years, it has become apparent that the open source ecosystem – which provides the software to run much of the internet, the economy, and our critical infrastructure – would benefit from a bit more rigor.

The OpenSSF was formed in August 2020 to raise the bar for open source security, and subsequent cyberattacks like the SolarWinds supply chain fiasco, the Apache Log4j vulnerability, and Colonial Pipeline ransomware infection, to name a few, have drawn more attention to the organization's mission – something that hasn't been top of mind in the FOSS community.

By September 18, the GNU Toolchain Infrastructure (GTI) initiative cited in Behlendorf's presentation had gelled into a proposal that discussed in somewhat heated terms at the 2022 GNU Cauldron conference. Nine days later, further details were published to the Sourceware mailing list.

Specifically, the GTI aims to provide Sourceware projects with IT services managed by the Linux Foundation, such as git repositories, email systems, issue tracking systems, patch review systems, a website, documentation, CI/CD, software artifact management, and software supply chain best practices. The plan is to use free software and to work with supporters to develop that code for missing components.

Asked whether GTI represents a shift away from the volunteer era of open source toward something more professionalized, Behlendorf suggested that amateur and professional participation in FOSS can coexist.

"The reason why a lot of this kind of volunteer infrastructure has worked has been because by being transparent, by being focused on voluntary collaboration, [these projects] have been able to go far with very little resources," he explained in an interview with The Register.

"It's people contributing spare servers and it's companies in some cases – Sourceware was supported substantially by Red Hat in the form of both engineers and and and other financial resources. But really, it's this participatory kind of thing that has to work."

"In this new infrastructure, everything is still done very publicly," Behlendorf said.

"The code that is used to deliver it is all still free software. There's still room for volunteers to be able to step in and help with things either on the periphery or on pioneering new service offering or helping improve the tooling that's used in the delivery of the infrastructure. So I think there's perhaps a phase change towards greater professionalization in some ways, but it's not in a way that loses what has made open source not only very powerful but also a lot of fun to be a part of."


GTI, or the notion of GNU Toolchain improvements, has been percolating in community discussions for several years and was mentioned by Behlendorf in a May 9 letter [PDF] to Congress about efforts to secure the open source ecosystem.

The project, explained Carlos O'Donell, a distinguished engineer at Red Hat who works on the GNU C Library for Red Hat Enterprise Linux, Fedora, and other projects, involves a collaboration with the Linux Foundation's OpenSSF to fund infrastructure and supply chain security.

According to O'Donell, "key stakeholders in the GNU Toolchain community" were briefed on the proposal and shaped it.


"The key stakeholders consulted include GNU Toolchain project leadership, GNU Toolchain project release managers, GNU Toolchain project core developers, major vendors, active Sourceware / Overseers administrators, and both John Sullivan and Zoë Kooyman of the Free Software Foundation," he wrote in the mailing list announcement.

But not everyone involved agrees with that assessment or is satisfied with the representations that have been made. And therein lies the problem: open source governance consists of herding cats. Members of the community have different ideas about how things should work and consensus building isn't easy or necessarily possible in every situation.

"Open source projects have this complex history of how do you get decision making done with so many disparate views," said O'Donell in an interview with The Register.

"And one of the ways you do this is you put together a proposal, you start sharing that proposal with people you know, and you trust with leadership in the community. And then you expand that proposal to a public discussion."
Show me the money

That's where we are now, said O'Donell, who added that some Sourceware admins have asked the SFC to open a bank account for them so they can look for alternative sources of fiscal sponsorship – even though Sourceware continues to be supported by Red Hat.

The central issue here is whether either the GTI or the application to involve SFC – which are not necessarily mutually exclusive – will change how the various projects hosted by Sourceware are governed or licensed. Those providing funding and support to open source projects – $285,000 in the first year under the GTI plan – often have the opportunity to shape those projects.

"It's really hard amongst a group of 20-ish people to get complete unanimity around things," said Behlendorf. "And especially when a subset of those folks had been voluntarily maintaining the Sourceware infrastructure, it's going to be hard to hear that some folks feel it's insufficient when a hard decision like this is really needed. So I saw this as a community making a really tough decision but they were making it with the right process."

The Linux Foundation is like loggers who claim to speak for the trees

Critics of the GTI deride it as a corporate takeover – a charge those involved with the GTI emphatically deny. There's a part of the FOSS community that believes the Linux Foundation, funded by major tech companies including Microsoft and Oracle, favors corporate interests over those of the community.

As Bruce Perens, one of the founders of the open-source movement, put it several years ago, "The Linux Foundation is like loggers who claim to speak for the trees."

"Ultimately, this is a classic discussion of what kinds of governance and organizations should be the homes for FOSS projects," said Bradley M. Kuhn, Policy Fellow at SFC, in an email to The Register.

"At SFC, we believe strongly that governance and organizational structure matter. Specifically, there are substantial governance differences between 501(c)(3) charities (such as the SFC) and 501(c)(6) non-profits (such as the Linux Foundation and OpenSSF)."

This is a classic discussion of what kinds of governance and organizations should be the homes for FOSS projects

Essentially, Kuhn argues, there's a difference between 501(c)(6) organizations, referred to as trade associations, which serve for-profit companies and promote common business interests, and 501(c)(3) organizations, referred to as charities, which promote activities like education and advocacy for the public good.

"This governance difference is stark in this particular situation," Kuln elaborated.

"While the details of the OpenSSF proposal to control the GCC, GDB, glibc, and Binutils' infrastructure remains hazy, they've stated that the governing body will be a group of companies, who buy seats on a committee that will control the projects' infrastructure. While that committee may well sometimes act in the interest of the community (by taking advice from a technical advisory committee, which apparently gets collectively only one vote), it's not guaranteed."

Mark Wielaard, a Sourceware overseer and senior principal engineer with Red Hat's Platform Tools group, told The Register in an email that Sourceware has been going for almost 25 years and those involved would love to have that continue for another 25 years.

"We work directly with the communities and while we're always working on improvements, and the users always have requests, there was not a groundswell of interest to move to a different hosting platform," said Wielaard. "As far as we understand the situation, a proposal to move services is not generally supported by various projects, including some of the GNU projects, hosted by Sourceware."
Open source turns 20 years old, looks to attract normal people
REG FILES

Wielaard said the above mentioned discussions with stakeholders were "done very selectively, with minimal information given about the structure of the new governance structure or actual technical plans." He noted that the SFC held public consultations on supporting Sourceware and asked the Linux Foundation to participate.

"The Linux Foundation chose to not join any of these public discussions over the last year," said Wielaard. "Even now that they've presented the plan publicly, they've still only provided minimal details."

Zoë Kooyman, executive director of the Free Software Foundation (FSF), told The Register that the FSF has been presented with the Linux Foundation / OpenSSF proposal and has engaged with the OpenSSF, the SFC, and the Sourceware volunteers. She said the FSF conducted a community conversation on the subject just this week.

"The focus of the discussion has been on infrastructure for the GNU Toolchain projects," said Kooyman.

"While the FSF provides overall fiscal sponsorship, including raising and holding funds for the projects, we have not had to provide the infrastructure since the volunteers at Sourceware have done (and continue to do) such a good job of that.

"Generally the FSF is supportive of projects receiving resources and using infrastructure from other sources, as long as that support comes without strings, is supported by the community, and is consistent with the mission of fully free software everywhere. We have shown ourselves willing to explore improvements to the infrastructure, but we have so far not made any endorsements.

"Decisions have to be made in accordance with decision-making practices of the different GNU Toolchain packages by their maintainers. We know people expect freedom whenever they see the GNU name, and it's an important part of the FSF's job to make sure that expectation is met. That means we are looking for a set of standard practices and guarantees, and we are exploring if we feel this proposal could satisfy those. Now, and in the future."


Asked whether any of the GTI discussions have touched on the possibility of changing the software licensing of the GNU Toolchain, Kooyman said, "No, we have not been asked that during any part of these conversations and the FSF is committed to copyleft."

We aren't politicians; we just want to volunteer doing our work to help the community, and we're frustrated by all this

The community conversation, said Wielaard, "didn't answer most of the questions the community had," and pointed to questions asked during the session though a chat box that were never addressed.

"As such, that session earlier this week didn't really provide many more answers and just generated more questions. So there remain unanswered questions about specifics and there hasn't really been much community discussion about the Linux Foundation plans."

Wielaard said the discussion with the SFC is ongoing, public, and positive, as the SFC's engagement with the FSF has been.

"We aren't politicians; we just want to volunteer doing our work to help the community, and we're frustrated by all this," Wielaard said. "The SFC and FSF understand these politics so we've reached out to them to help us deal with all of it.

"We are also in talks with the FSF tech-team, which is responsible for some parts of the GNU projects which also get some services from Sourceware. We expect to work more closely with them in the future to share resources, backups, software releases, etc."

Asked where the GTI stands, O'Donell said it's just getting started: "We're going to be putting together infrastructure proposals, and we're going to be iterating with the community on those proposals to get their feedback. This is just the very, very, very beginning. Some people feel like it's the end, but it's totally the opposite of the end."

https://www.theregister.com/2022/11/...ource_openssf/

Why you should migrate everything from Linux to BSD

Published on 2020-01-18. Modified on 2021-02-17.

As an operating system GNU/Linux has become a mess because of the fragmented nature of the project, the bloatware in the kernel, but mainly because of the manipulation by corporate interests. There exist several technical reasons for when a migration from GNU/Linux to BSD make sense, but this article isn't about that, it's an "analyzes" of the current status in Linux-land, and it is an opinionated rant, more than anything else.

In the past I have always been a favorite of choosing operating system and tools based upon technical merit. However, in today's world of companies like Microsoft, Apple, Google, and many others, compromising user privacy, and conducting controversial activities, I don't believe that to be the right cause of action.

Proprietary operating systems like Microsoft Windows 10, Apple MacOS, and Google Android have become famous for their ill conduct, and even companies like Lenovo is using UEFI boot to inject custom Windows components, so that the system can phone home to Lenovo.

I have been a proponent for the open source alternatives, like GNU/Linux and BSD, for a very long time. Not only that, I also believe that the open source alternatives are much better in many technical areas.

I have also always been very much against The typical discussions about BSD vs Linux, and as I wrote in my article back then, I have always believed that the different open source projects can help each other and cooperate, and that end-users should only debate such issues from a technical stand point rather than personal preference.

Whenever it has been possible, I have proposed people, both private and in the industry, to change the operating systems they use to open source alternatives, and when people have been receptive to my advocacy I have helped them migrate from Microsoft Windows on their workstations to BSD or Linux. And likewise on the server side. This has been a truly successful endeavor and I have honestly never experienced a dissatisfied person or company.

However, things are beginning to change in the GNU/Linux world as more and more corporations want to control the direction of Linux as an operating system. Due to the structure and organization of GNU/Linux as an operating system, it is unfortunately susceptible to these influences, and while it is still open source, and still not anywhere near the bad things that is going on with the proprietary alternatives, some opt-out features have slowly been introduced into both the kernel and systemd.

You can still choose to opt-out of these features and go your merry way, but as an open source enthusiast and proponent, and as a privacy concerned individual, perhaps the better approach is to migrate systems to something where you don't have to concern yourself with "creepware".

As a system administrator I don't want to worry about whether I am going to be surprised the next time I upgrade a system, and I don't want to keep a list of spyware I have to remember to opt-out of whenever I run one of these systems.

Several Linux distributions have decided (not only because of privacy opt-out issues, but other issues as well) to implement other init solutions than systemd, but with the situation going on in the kernel development, and with many third party applications becoming more and dependent upon systemd, the problems are spreading to other parts of the operating system and I believe this is becoming an uphill battle.

From a community perspective, and from a security perspective, I don't believe the future of GNU/Linux looks very bright, and as a possible alternative solution I suggest migrating everything (when possible) to something a bit more sane, like one of the BSD projects.
Linux is fragmented

In 1983 Richard Stallman announced his intent to start coding the GNU Project in a Usenet message. By June 1987, the project had accumulated and developed free and open source software for an assembler, an almost finished portable optimizing C compiler (GCC), an editor (GNU Emacs), and various Unix utilities, such as ls, grep, awk, make and ld.

In 1991, the Linux kernel appeared, developed outside the GNU project by Linus Torvalds, and in December 1992 it was made available under version 2 of the GNU General Public License. Combined with the operating system utilities already developed by the GNU project, it became the GNU/Linux operating system, better known as just "Linux".

Then came the Linux distributions. Different projects took the Linux kernel, the GNU tools and libraries, additional third party software, documentation, the X Window System, a window manager, and a desktop environment, and combined those components into the distributions. Different distributions focused on different goals, some put focus on the desktop while others put their main focus on servers, and again others tried to provide a multi-purpose operating system.

In the past all these different components and projects where developed by open source enthusiasts and communities and the passion for programming and open source was the driving force.

This is no longer the case! Please see The real motivation behind systemd.

Linus Torvalds has many times made it very clear that he doesn't care about what goes on in the "Linux world", all he cares about is the kernel development, and on January 6, 2020 in the "Moderated Discussions" forum at realworldtech.com, Linus Torvalds answered a user's question, with an absolute jaw-dropping comment, about a year-old kernel maintenance controversy that heavily impacted the ZFS on Linux project.

After answering the user's actual question, Torvalds went on to make very wrong and damaging claims about the ZFS filesystem. Torvalds said:

It (ZFS) was always more of a buzzword than anything else.

By that statements Linus Torvalds has just reduced more that 15 years of development of one of the most robust and popular filesystems in the world into a "buzzword"!

ZFS is described as "The last word in filesystems". It is a combined filesystem and logical volume manager originally designed by Sun Microsystems. ZFS is a stable, fast, secure, and future-proof filesystem. It is scalable, and includes extensive protection against data corruption, support for high storage capacities, a maximum 16 Exabyte file size, and a maximum 256 Quadrillion Zettabytes storage with no limit on number of filesystems (datasets) or files, efficient data compression, snapshots and copy-on-write clones, continuous integrity checking and automatic repair, RAID-Z, native NFSv4 ACLs, and can be very precisely configured.

The two main implementations, by Oracle and by the OpenZFS project, are extremely similar, making ZFS widely available within Unix-like systems.

As mentioned in the Wikipedia article, OpenZFS is an umbrella project aimed at bringing together individuals and companies that use the ZFS file system and work on its improvements, aiming as well at making ZFS more widely used and developed in an open-source manner. OpenZFS brings together developers from the illumos, Linux, FreeBSD, and macOS platforms, and a wide range of companies. High-level goals of the project include raising awareness of the quality, utility and availability of open-source implementations of ZFS, encouraging open communication about ongoing efforts toward improving open-source variants of ZFS, and ensuring consistent reliability, functionality and performance of all distributions of ZFS.

OpenZFS on Linux, which is the Linux part of the project, has currently 345 active contributors with more that 5.600 commits, and commits are being made on an almost daily basis!

Some of the worlds biggest CDN and data storage services runs ZFS on either FreeBSD or Linux!

In another situation Linus Torvalds gave an interview on TFiR: open source and Emerging Tech YouTube channel about Linux on the desktop in which he makes another amazing statement saying that Linux still isn't ready for the desktop and that perhaps Chrome OS is the solution to that problem.

These and many other statements by Linus Torvalds show that Linux as an operating system has no real direction and no clear management because the kernel development is performed in isolation from the rest of the Linux world.

Linus Torvalds is generally also very open to the rapid influence by corporate interests and his perspective on security is also worrying.

In 2009 Linus Torvalds admitted that the kernel development is getting out of control.

We're getting bloated and huge. Yes, it's a problem ... Uh, I'd love to say we have a plan ... I mean, sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago ... The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse.

At LinuxCon 2014, he said that he thinks the bloat situation is better because modern PCs are a lot faster!

We've been bloating the kernel over the last 20 years, but hardware has grown faster.

This is a very problematic attitude.

When software gets bloated it not only becomes more insecure and more error prone, but it also becomes much slower. Thinking that the problem goes away because hardware becomes faster is an immature attitude. In this day and age we need to optimize software so that less power is required, we need to save power and limit pollution.

In a 2007 interview "Why I quit": kernel developer Con Kolivas he stated:

If there is any one big problem with kernel development and Linux it is the complete disconnection of the development process from normal users. You know, the ones who constitute 99.9% of the Linux user base. The Linux kernel mailing list is the way to communicate with the kernel developers. To put it mildly, the Linux kernel mailing list (lkml) is about as scary a communication forum as they come. Most people are absolutely terrified of mailing the list lest they get flamed for their inexperience, an inappropriate bug report, being stupid or whatever. ... I think the kernel developers at large haven't got the faintest idea just how big the problems in userspace are.

Besides from the above mentioned problems, the fact of the matter is that Linux as an operating system is put together by different applications from different projects that has absolutely nothing to do with each other. If you don't know anything about this you should take a look at how you build Linux From Scratch.

Another good read that demonstrates some of these problems is the article Linux maintains bugs: The real reason ifconfig on Linux is deprecated.

This is very different from the BSDs (meaning FreeBSD, OpenBSD, NetBSD and DragonFly BSD) as each are independent projects that put together their systems "in-house", so to speak. The kernel, the standard C library, the user land tools, etc., are all part of the base system of the operating system, not something put together from a bunch of different outside sources.

In a 2005 interview Theo de Raadt, the founder of OpenBSD, makes the following remarks:

I am sure by now you all know that Linux is just a kernel, while OpenBSD is a complete Unix system: kernel, device drivers, libraries, userland, development environment, documentation, and all the tools you need to continue doing development. That said, based just on completeness of functionality, it is not handled like a Linux distribution, not at all.

When we find that a change must be made to the system (security or otherwise) we can therefore force such a change into the system by changing it all the way from userland through the libraries down to the kernel. We can change interfaces as we want to. We can move quickly. Sometimes changes are even made which break previous executables; but if we need to, we can choose to make such decisions.

This gives us great flexibility to move forward fast. If something is designed wrong, and the fix depends on changes in more than just the kernel, we can fix it by. We change all the required pieces in the right places. We don’t need hacks in the wrong place to fix a problem.

Linux is being heavily influenced by corporate interests

A Linux distribution is a collection of tools written by different groups of people, often with conflicting interests and priorities, and because of this fragmented structure of the GNU/Linux operating system, the project as a whole is rapidly spinning out of control as it gets pushed around by commercial interests.

Even the best GNU/Linux distributions, such as Debian GNU/Linux and Arch Linux, that are still mainly driven by open source communities, are not immune to this problem because they not only still depend heavily on the fragmented tools, but several developers has been hired by some of these major commercial companies.

In my article The real motivation behind systemd I have written about how the primary reason for developing systemd is Red Hats financial interests in embedded devices, primarily at the U.S. Military and the automobile industry. Initially systemd was released as a new init system, but it has slowly grown into what Poettering describes as "a suite of software that provides fundamental building blocks for a Linux operating system."

In an interview with Red Hat CEO Jim Whitehurst he states:

We partner with the largest embedded vendors in the world, particularly in the telecom and automotive industries where stability and reliability is the number one concern. They easily adapted to systemd.

I have nothing against the "init" part of systemd, but systemd is no longer just an init system, and the main problem with systemd is that its continued development is motivated by a company's financial interests and not the open source community interests. As such, the adoption of systemd by the major Linux distributions, such as Debian GNU/Linux and Arch Linux, was a big mistake in my humble opinion. They have made themselves heavily dependent upon systemd and Red Hat.

This is pure speculation, but I must also admit that I suspect systemd to be a platform for introducing security holes into the Linux operating system. These will of course look like normal "programming mistakes", however some of these bugs resembles what happened with the OpenSSL Heartbleed bug quite a lot. And it is a well know strategy used in the open source community, to use "programming mistakes" to create backdoors and other issues. systemd has a long line of standing and open bugs (more than 1.400 open bugs as of writing) that still haven't been fixed since 2015, yet instead of fixed all of these bugs, the systemd developers keep adding more and more clutter to systemd!

Another heavy influence on the Linux world is Google. Google has developed both Android and Chrome OS, both Linux kernel-based operating systems. Chrome OS is derived from Chromium OS and uses the Google Chrome web browser as its principal user interface.

Chrome OS is viewed as a competitor to Microsoft, both directly to Microsoft Windows and indirectly the company's word processing and spreadsheet applications, the latter through Chrome OS's reliance on cloud computing. And this is one of the core problems with Chrome OS, it is built with great reliance of Googles cloud infrastructure.

Google has become one of the most controversial companies. Google is in its essence an advertisement company and it has become famous for their manipulation of search results and extreme user tracking capabilities, mainly thanks to the stupidity of web developers adding Google Analytics to their websites.

In a YouTube video from August 2019 by Linus Tech Tips, Linus Sebastian demonstrates how tracking on the Internet works and how it affects the prices you get offered when you search for products. Please note: The video was sponsored by Private Internet Access, a company that has since been bought by Kape Technologies which is known for sending malware through their software and for being really scummy in general. Don't use Private Internet Access!

Cloudflare is another American web infrastructure and website company that is affecting different areas of the development. The company provides services that actually sit between a website's visitor and the Cloudflare user's hosting provider, acting as a reverse proxy for websites. As such Cloudflare has become one of the greatest cancers of the Internet.

The systemd developers has managed to integrate Cloudflare, Quad9 and Google into the core of systemd-resolved, which is now something you have to manually disable (opt-out).

With the growing influence of Red Hat (IBM) through systemd, they have managed to steer the direction of most of the major Linux distributions in a direction that contradicts what many system administrators and users would like to see.
BSD is the place to be

Contrary to the Linux distributions the Berkeley Software Distribution (BSD) is not a fragmented project. The BSD projects maintain the entire operating system, not only the kernel.

BSD was an operating system based on Research Unix, developed and distributed by the Computer Systems Research Group (CSRG) at the University of California, Berkeley. Today, "BSD" refers to its descendants, such as FreeBSD, OpenBSD, NetBSD and DragonFly BSD. These projects are real operating systems not just kernels and they are not "distributions".

Linux distributions, such as Debian GNU/Linux and Arch Linux have to do the work of bringing together all the software required to create a complete Linux operating system. They need the Linux kernel, the GNU tools and libraries, an init system, and some amount of third party applications in order to end up with a functioning operating system.

In contrast the BSDs are both a kernel and a complete operating system. For example, FreeBSD provides both the FreeBSD kernel and the FreeBSD operating system. It is maintained as a single project.

No one person or corporation owns BSD. It is created and distributed by a community of highly technical and committed contributors all over the world.

Companies also use and contribute to BSD, but contrary to Linux, a company cannot "hijack" BSD. A company can make their own version of BSD, such as Sony Computer Entertainment has done for their PlayStation 3, PlayStation 4 and PlayStation Vita gaming consoles, but because the BSDs are complete operating systems, and because each BSD project is maintained and developed by open source enthusiasts and communities, not companies such as Red Hat, the BSD projects are really and truly independent.

The result of this organization of the BSDs you wont find crazy opt-out spyware settings in your basic installation, no matter what BSD project you choose, and you don't find privacy compromising solutions integrated into the operating system core components.

On the contrary, because the BSD projects are developed and driven by skillful and enthusiastic people who care much about operating system design, security, and privacy, you will often find that even the third party software that are available for installation using a package manager gets patched so that these problems are removed, such as the disabling of DNS over HTTPS by OpenBSD in Firefox.

Another great benefit from all of this is that the communities that surround the BSD projects consist of experienced, helpful, and (for the most part) kind people.
License problems

The GPL license is more strict on developers and it is an open source anti-pattern as it forces a release of all modified source code and prevents other open source projects from being integrated, for example, the GPLv2 is preventing the integration of DTrace and ZFS in Linux.

BSD developers on the other hand have no such restrictions. Manufacturers may opt for BSD as their operating system of choice when creating new devices instead of Linux. This would allow them to keep the code modifications to themselves if they wanted to. With Linux the license force the release of the source code to the public.

The GPL license may sound better, because why should we allow companies to simply "steal" our open source code and produce proprietary products without even giving anything back. But it's not that simple. By forcing companies to release source code to the public via the GPL license, companies quickly become more manipulative.

The tactics deployed by Red Hat with the release of systemd was to try to get as many "important" third party projects to cooperate very tightly with systemd, or even depend upon systemd. This way other Linux distributions are more easily persuaded into adopting systemd because of the easy integration of these third party projects. The systemd developers addressed several third party projects and tried to convince them to make their projects either depend upon systemd, such as the attempts made by Lennart Poettering on the Gnome mailing list, and the attempt made by Red Hat developer "keszybz" on the tmux project. Most of these attempts were originally "disguised" as technical issues, however when you read the long email correspondence on the Gnome mailing list and elsewhere, the real intent becomes quite clear.

Such manipulation isn't needed in BSD. Companies are free to do whatever they want with BSD and as such they don't need to try to affect the way things are going. If that wasn't the case we would possible see, for example, Sony trying very hard to influence the development of FreeBSD because they use that in their PlayStation products.

The different GNU/Linux distributions, such as Debian GNU/Linux, Arch Linux, and even Red Hat Linux back in the days, were really great projects. When projects are driven by passion and not profit they tend to become much better quality. However, when projects are no longer driven by passion, but rather by profit, they often decline in quality. This is natural because motivation by profit is very different from motivation by passion. This is one of the reasons why Microsoft Windows has always been such a crappy OS.

The reason for the success of Microsoft Windows on the desktop isn't because people believe that Windows is a great operating system, no sane and experienced system administrator or IT supporter believes that, rather it is because of the aggressive marketing strategy deployed by Microsoft.

While the BSD projects do get both code and occasional financial support from companies, they are driven by passion and not by profit. This mainly means well thought out decisions. There are no compromises with privacy or security for the benefit of profit such as what we may find in Linux.

Please see my article The problems with the GPL for further information.
Time to migrate everything to BSD

Back in about 1998-2000 I started migrating every server and desktop operating system from Microsoft Windows, both at home and at my company, to GNU/Linux, initially Red Hat Linux and then later Debian GNU/Linux. I did that because I had spent about a decade doing Microsoft Windows support and wasted so much time on this absolutely horrible operating system.

When I was recommended GNU/Linux by a good friend of mine I was amazed at how well it performed, how amazing the open source communities were, and how all the usual problems related to Windows just vanished. Whenever I replaced a Windows setup with a Linux setup at a customer, a family member, or a friend, the support hours rapidly declined. Of course this meant less customer support work, but this was great because now we could concentrate our time on more important matters.

A little later I discovered the BSD world and eventually also began deploying both FreeBSD and OpenBSD on servers and on desktops too.

Back in the days Linux often had better hardware support than BSD and as a result I generally used Linux more than BSD. Hardware was expensive and it was not always possible to purchase hardware based upon which operating system you wanted to run on the system. This is different today where the BSDs generally have great support for modern hardware.

I still like GNU/Linux, but I don't want to worry about possibly privacy breaking crap in systemd, or whatever creepware Lennart Poettering comes up with next, I also don't want to worry about all the bloatware that goes into the kernel, such as the kernel forcing adaption of DRM. I generally don't want to worry about whatever the next problematic thing is going to be. Everything needs to be sane options and decisions by default! Not opt-out!

You can read about FreeBSD in my article FreeBSD is an amazing operating system and about OpenBSD in my article OpenBSD is fantastic.


https://unixsheikh.com/articles/why-...ux-to-bsd.html

Date Tue, 12 Aug 2014 15:38:12 -0400
From Christopher Barry <>
Subject OT: Open letter to the Linux World


share 468



What is intelligence? Not exactly the spook kind, but rather what is
the definition of intelligence in humans? This is pretty good:
http://en.wikipedia.org/wiki/Intelligence#Definitions

By most accounts, the self-appointed and arguably too influential creators and thinkers of the day around the 'One Linux' idea fit the definition of intelligent people - at least in the technical realm.

And their messages are pretty compelling:
* Simplify cross-distro development.
* Enable faster boot times.
* Enable an on-demand, event driven architecture, similar to 'Modern'
Operating Systems.
* Bring order and control to subsystems that have had as many different
tools as there were distros.

All seemingly noble goals. All apparently come from a deep desire to contribute and make things better.

Almost anyone could argue that these intelligent people thought hard about these issues, and put an enormous amount of effort into a
solution to these problems. Unfortunately, the solution they came up with, as you may have guessed by now, is 'systemd'.

While not new, it's grotesque impact has finally reached me and I must speak to it publicly.

So, what is systemd? Well, meet your new God. You may have been praying at the alter of simplicity, but your religion is being deprecated. It
likely already happened without your knowledge during an upgrade of your Linux box. systemd is the all knowing, all controlling meta-deity
that sees all and supervises all. It's the new One Master Process that aspires to control everything it can - and it's already doing a lot.
It's what init would look like if it were a transformer on steroids. It's complicated, multi-faceted, opaque, and supremely powerful.

I had heard about systemd a few years back, when upstart and some other init replacements I can't remember were showing up on the scene. And
while it seemed mildly interesting, I was not in favor of using it, nor any of them for that matter. init was working just fine for me. init
was simple and robust. While configuration had it's distro-specific differences, it was often these differences that made one pick the
distro to use in the first place, and to stay with that distro. The tools essentially *were* the distro. I just dist-upgraded to Jessie, and voila - PID 1 was suddenly systemd. What a clusterfuck.

In a 'One Linux' world, what would distros actually be? Deprecated. No longer relevant. Archaic shells of their once proud individualism.
Basically, they're now just a logo and a default desktop background image. Because let's face it, there only needs to be One Modern
'competitor' to the Windows/Mac ownership of personal computing. A unified front to combat the evil empires of Redmond and Cupertino is
what's needed. The various differences that made up different 'flavors' of Linux needed to be corralled and brought into compliance for the war to proceed efficiently. Um, what war?

For me, Linux had already won that war way back in 1994 when I started using it. It did it without firing a shot or attempting to be just like
the other OSes. It won it it by not giving a flying fuck about market share. It won it by being exactly NOT them. It won it by being simple
and understandable and configurable to be exactly how *I* wanted it to be. It won it by being a collection of simple modular components that
could be plugged together at will to do real work. It won it by adhering to a deeply considered philosophy of the user being in the
drivers seat, and being free to run the things she wanted to, without layers and layers of frameworks wrapping their tendrils into all manor
of stuff they should not be touching. It won it without the various 'CrapKit' shit that's begun to insinuate itself into the heart of my
system of late. It won it without being overly complex and unknowable. That kind of opacity was was the core of Windows and Mac, and that's
exactly what I despise about them, and exactly why I chose to use Linux in the first goddamn place. systemd is embracing *all* that I hate about
Windows and Mac, and doing so in the name of 'modernity' and 'simplifying' a developer's job.

So why would very smart people who love and use Linux want to create or embrace such a creepy 'Master of All' daemon? Ostensibly, it's for the reasons they say, as I mentioned at the top. But partially I think it's from a lack of experience. Not a lack as in programming hours, but a
lack as in time on the Planet. Intelligence alone is not a substitute for life experience and, yes I'll say it, wisdom. There's no manual for
wisdom. Implementing systemd by distros is not a wise move for them over the long term. It will, in fact, be their ultimate undoing.

Partially it's the larger-than-life egos of the people involved. Has anyone actually read what Poettering says about things? Wow. This guy
is obviously convinced he has all the answers for everyone. Traditional ideas about simplicity and freedom are quaint, but have no real place
in a 'modern' OS. Look, he's just smarter than you, so get over it and move aside. He knows what's best, and he has it under control. How old
is this guy anyway? 12 or so? He's a fucking tool (IMHO).

Partially it's roiling subsurface commercial interests. Look, We can make more money selling stuff to Linux users if there were a simpler distro agnostic way to do that. Fuck choice, they'll like what they get.

Partially it may well be nefarious and shadowy in nature. With One Ring to rule them all, having access to it sure would be sweet for those
hell-bent on total information awareness. Trust is not real high on my list of things to give out these days.

Partially it's a belief that the Linux Community must fight against the hegemony of Windows and Mac - as if the existence of Linux depends upon
the vanquishing of alternatives. Those who think Linux should cater to idiots and droolers should go back to their Macs and Windoze boxen, and
stop trying to 'fix' Linux. It wasn't fucking broken!

Partially - and this is what I cannot abide - it is a blatant disregard and disrespect - whether knowingly or not - of the major tenets of
*NIX. It's a thoughtless discarding of, and a trampling on the values that I personally hold to be true and just, and I am not alone here. systemd is the exact opposite of what defines *NIX. And I'm not blathering on about POSIX compliance either. It's the Philosophy stupid.

systemd is a coup. It is a subversive interloper designed to destroy Linux as we know it, foisted upon us by the snarky we-know-better-than-you CamelCase crowd. They just don't get it down deep where it matters. systemd is not pointing in a direction that we should be going. It does not encourage freedom. It does not encourage choice. It does not display transparency. It does not embrace simplicity. It seizes control and forces you to cede it. It makes applications and major system components depend on it, and they cannot function without it. It's gaining speed by luring naive or lazy or just plain clueless developers into the fold with the promise of making their lives easier. Buying into this way of thinking ignores the greater dangers that systemd represents.

Debian has always held the line against this kind of thing in the past, and has always earned my utmost respect and loyalty for their integrity. Debian's decision here was as a hand forced. Debian has made a grave and cowardly mistake here, and they need a course correction
immediately. Incorporating systemd was not an intelligent choice, and certainly not one very well considered. Debian must reject systemd and
its ilk, and restore itself to the values that got Linux to this point in history, in no small part *led* by Debian. They must loudly and
publicly divorce themselves from GNOME, however painful and upsetting that may seem in the sort term, and focus on the core values of
simplicity and freedom. Put systemd and it's cabal in non-free where it belongs if you must. Let the user decide if that's what
they want. Enlightenment is an excellent choice for a default desktop that does not have the bloated baggage of GNOME. And to the Debian
Leaders - after 20 years of my loyalty and evangelism, you really let me and all of us down. You need to grow a fucking pair and do the right
thing here and now.

Kick these fucking carpetbaggers to the curb!

Gnome. The Linux Foundation. freedesktop.org, and others. These are all groups with agendas. These are not those who believe in freedom. They
believe in control and standardization. They believe in sameness. Who are these people anyway? Who are these self-appointed keepers of the
Linux flame? (subliminal malware reference intended). What are their true agendas? Who funds these people? Why do they so aggressively want
to change the core of Linux away from it's true philosophy? Let them go off and create their own 'competitor' to Windows and Mac. If they did,
it would be the same opaque, backdoored, user-tracking bullshit that Windows and Mac have become. They DO NOT speak for me, and you should
not passively allow them to speak for you either.

systemd is a trojan. systemd is a medusa. systemd is Substance D. systemd is scary - not just because it's tools suck, or because it's
a massive fucking hairball - but because architecturally it has way too much concentrated power. We all need to collectively expel it from
our midst because it will own Linux, and by extension us and our freedoms. systemd will *be* Linux. Sit idly by and ignore this fact at
all of our collective peril.

OneLinux == zero-choice


--
Regards,
Christopher Barry

Random geeky fortune:
BOFH excuse #202:

kernel panic: write-only-memory (/dev/wom0) capacity exceeded.

https://lkml.org/lkml/2014/8/12/459

The delusions of debian

Published on 2022-03-30. Modified on 2022-11-05.

Debian was my favorite Linux distribution for servers where Linux where required to run for many years, and I think I have been running it in production since about 1998 up until the time about when the systemd conflict arose. Since that time I have noticed a rapid decline in many areas of Debian. This has continued up until today and Debian is no longer what Debian used to be.

Let me begin by saying that this article is not about systemd, I am simply using the conflict about systemd as a reference point in time.

Because of the problems with systemd, the Debian community was split in two, where a minority of former members and contributors decided to fork Debian into Devuan. Debian was, and still is, a very big project and the founders of Devuan struggled for years because forking Debian was no easy task. However, they where not the only ones struggling. The internal strive made several leading members simply quit Debian (without joining Devuan), and many people felt understandably "betrayed" by how the systemd conflict was handled.

Despite the split, the Debian project steadily kept adding new third party software to its repositories. As of writing Debian Bullseye has 96.754 packages and 168.670 packages in unstable, a number that just keeps growing. That is a massive amount of software packages!

One of the primary reasons to deploy Debian on production servers in the past was because of the way Debian maintained both the kernel, the userland, and third party packages in the stable release. On the project website Debian still "boasts" of the same procedure.

Debian offers security support for its stable releases. Many other distributions and security researchers rely on Debian's security tracker.
Debian's free of charge Long Term Support (LTS) version extends the lifetime of all Debian stable releases to at least 5 years. Additionally, the commercial Extended LTS initiative supports a limited set of packages for more than 5 years.

On the Debian Security Information it is further stated that:

Debian takes security very seriously. We handle all security problems brought to our attention and ensure that they are corrected within a reasonable timeframe. Many advisories are coordinated with other free software vendors and are published the same day a vulnerability is made public and we also have a Security Audit team that reviews the archive looking for new or unfixed security bugs.

Furthermore, on the Debian Security Audit Project website it is stated that:

The Debian Security Audit Project is a project which is focused upon auditing Debian packages for security issues.

In the short time it has been running it has been responsible for several Debian Security Advisories proving that this auditing process really works to improve Debian security. It is hoped more advisories will result from future work.

By taking a proactive stance in auditing code we can help to ensure that Debian continues its long history of taking security seriously.

The aim of the project is to audit as many of the packages within the Debian stable release as possible for potential flaws. Important packages which are contained in the unstable distribution may also be examined for flaws, decreasing the likelihood of insecure packages entering the stable release in the first place.

In the past, before the systemd conflict, Debian was famous in the Linux world for all of the above, and it was one of the most widely deployed Linux distributions on servers. But, as the website also rightly states further down:

Due to the sheer size of the current Debian release it is infeasible for a small team to be able to audit all the packages, so there is a system of prioritizing packages which are more security sensitive.

Debian is perhaps still the biggest Linux distribution in the world and it is still an amazing project (even though I TRULY wish that the project had rejected systemd and replaced their default GNOME desktop with something else). However, the fact of the matter is that Debian has long been experiencing a decline in the amount of people willing to participate in the project. This is further made worse by the fact that the current leadership is more worried about Debian having a black lives matter sticker somewhere on the project website than he is with the fact that tons of Debian packages are abandoned and many important packages get security updates long after the bugs have been fixed upstream.

Before that, Jonathan Carter, the former leader had these ridicules points in focus for the future of Debian.

I have been going through a number of packages during the weekend and found that the sad state of web browser support currently within Debian also extends to many of the packages.

More than that, the Debian project is absolutely delusional about its long term support!

At the time when Debian 11 was about to be released, PHP 8.0 was 10 months old yet Debian's 11 was released with PHP 7.4. That makes PHP 7.4 the standard in Debian stable for at least 3 years after its release. But PHP 7.4 only got upstream support until 28 Nov 2021 and security support is permanently ended at 28 Nov 2022, which is seven month from now. This means that unless Debian has some really good C developers, no one can provide any security fixes for PHP 7.4. Not only that, no one outside of Debian will be monitoring problems with PHP 7.4 because everyone else will long since have upgraded to PHP 8.

The delusion then continues down the stream where ordinary Debian users are left with the impression that because Debian promises long term support, there is no problem running with these outdated packages on their servers.

Maybe the problem is that a lot of myths surround many of the popular Linux distributions. When you go to e.g. Reddit, it is filled with misinformation parroted by ignorant users. But perhaps I shouldn't call it "myths", but rather misinformation because what is stated on some of these project websites, and what goes on in the real world, are often two very different things.

What I don't understand is why so many Linux distributions aren't open and clear about the problem with package maintenance!

Stop saying that you focus on security. Stop saying that you provide long term support. Tell everyone plain and clear that your so-called long term support is naturally conditional upon what upstream does, and that if a package version is abandoned by upstream, or orphaned by the package maintainer, then all bets are off.

If you're a regular BSD or Linux user reading this, you need to understand that if upstream abandons a package version and not longer provides security updates or bug fixes for the package, then likewise the package maintainer on your favorite OS cannot do anything, the LTS depends on upstream.

You also need to understand that regular and timely updates depends 100% on the package maintainer(s) time and work. A single maintainer may maintain as many as 500 packages. If you want to understand how well upstream packages are tracked in your OS, take a look at the packages that are important to you and compare the release dates upstream with the release dates of the package on your OS.

Don't blindly trust the promises made on the website of your favorite OS. Also, don't simply trust what other users on Reddit and elsewhere says, that "this is OS is oh so secure", and "project X is more secure that project Y", and bla bla bla. Many people simply have no idea what they are talking about.

This is the very basic of what you need to do if security is important to you:

Keep a list of all the important software you install, including the version of the kernel.
Make sure you monitor bug reports and security reports filed upstream. It's not enough to simply watch some popular CVE website, these websites are not always timely.
Determine if and how a problem affects you. A buffer overflow problem in your favorite text editor is not a problem if you are the only user with access to the machine. An exploitable bug in something like NGINX, if you run an Internet facing web server, is a serious issue.
Keep a careful eye on your operating system, whether they have noticed the bug report, whether they have reacted to it. You can help here by letting the ports/package maintainer know about the issue, but this is no guaranty that the package will be updated in a timely manner. If the package maintainer is ill, out of town, or simply doesn't have the time, you're on your own!
Plan ahead on how to deal with problems. Ideally, use an OS that makes it easy to build and compile your own packages directly from upstream. This is relatively easy on all the BSDs because of the ports system. It is also relatively easy on the Linux distributions with similar systems to the ports system, such as Gentoo, Arch Linux, Void Linux, and others. The ports system is one the greatest assets for users who want flexibility and control over their software. On FreeBSD you can even use Poudriere on a build machine.

https://unixsheikh.com/articles/the-...of-debian.html

OpenBSD is fantastic

Published on 2018-03-13. Modified on 2020-11-20.

I have been using OpenBSD, a FREE, multi-platform 4.4BSD-based Unix-like operating system, both professionally and privately since about 2004, and today I'm going to share some of my experiences.

As I was gathering my thoughts for this article I realized that it is actually quite difficult to give due credit to the developers of OpenBSD. This is because OpenBSD is quite unique and it's rather amazing, in my humble opinion. Much of its "splendor" hides in the design and specific coding style of the developers, and as such it isn't visible to the average user. You need to understand some of what goes on under the hood to really appreciate OpenBSD!

OpenBSD is easy and quick to install and you will be surprised at how simple and extremely well designed the system is. A lot of work goes into making everything right from the beginning, and the project is following the Unix philosophy to the letter.

OpenBSD comes with many applications in the base system ready to run, however nothing except for security features is enabled by default, you have to enable the services you need. Every configuration file follows the same style of syntax, a very human-readable syntax, and it's thus very easy to understand and setup. Every single option is well documented in the man pages and the OpenBSD project considers lacking documentation "a bug". This is something that every professional programmer should adopt.

Lacking documentation, or incorrect documentation, is just as dangerous to a running system with a security bug. The reason for that is that security issues sometimes arise from misconfiguration. If you don't know how to setup your system, how can you be sure that it isn't running in a manner that makes it easy for an attacker to compromise your system? A lot of spam on the Internet origins from misconfigured mail servers that has been compromised by attackers.

Every single line of code in the operating system kernel and base system of OpenBSD gets security audited and scrutinized by the programmers, and everything is coded following a strict set of guidelines and principles that tries to eliminate all the typical coding mistakes, as many security bugs are actually coding mistakes made by programmers.

But that's not all. Another thing that makes OpenBSD amazing is all the security mitigation work that goes into the development of the operating system and the OpenBSD developers are doing some fantastic frontier engineering in this area!

Security mitigation are techniques that help prevent attackers from running malicious code on the operating system or take advantage of security bugs or weaknesses in software.

If you're using a piece of software, say like a browser, and the browser has a security bug that is exploitable, then it is possible for an attacker to possibly gain access to your computer. How much damage the attacker can do on your computer depends on the underlying security of the operating system.

OpenBSD has a number of mitigation techniques build into the kernel and base system that makes life really difficult for an attacker. This means that it becomes much more difficult for an attacker to gain unauthorized access to your system in the first place, using the normal exploitation techniques which work on many other operating system like Microsoft Windows, Linux, Mac OS, and others. It also means that if an attacker should gain access to your system despite these mitigations, the amount of damage the attacker can do is very limited and constricted.

Here is a list of some of the OpenBSD security innovations build into the operating system and enabled by default.

Enforced W^X in the kernel on i386/amd64/sparc64.
Enforced W^X userland as of version 6.0.
SROP (sigreturn(2) oriented programming) mitigation by default.
Static-PIE for self-relocating static binaries.
Stack protector.
Privilege dropping and separation for most of the base system as a matter of policy, new stuff doesn't get enabled without it.
bcrypt password hashes only, with an automatically selected rounds value based on system performance.
PIE by default for base, packages, and ports.
C shared library re-ordering at boot time, i.e: libc.so is re-linked at boot time so objects are randomly ordered.
System-wide sandboxing (pledge(2)) of a large percentage of the userland, incl. privileged part of the X server, most networking facing daemons included.
arc4random(3), which backs rand(3), random(3), and drand48(3), with an audited base/ports tree. Software must opt-in to deterministic broken POSIX behavior.

The list goes on at OpenBSD Innovations

Several of these innovations has been adopted and implemented by other operating systems thanks to the work done by the OpenBSD developers.

OpenBSD is a robust and reliable operating system that you can run with minimal interaction once it is setup. It is actually the only operating system that truly enables you to sleep at night in case you're running any system critical software.

OpenBSD maintains a portable version of many parts of the base system, including:

LibreSSL, a free implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols, forked from the OpenSSL 1.0.1g branch
OpenBGPD, a free implementation of the Border Gateway Protocol 4 (BGP-4)
OpenOSPFD, a free implementation of the Open Shortest Path First (OSPF) routing protocol
OpenNTPD, a simple alternative to ntp.org's Network Time Protocol (NTP) daemon
OpenSMTPD, a free Simple Mail Transfer Protocol (SMTP) daemon with IPv4/IPv6, PAM, Maildir and virtual domains support
httpd, an HTTP server first included in the 5.6 release
OpenSSH, a free implementation of the Secure Shell (SSH) protocol
OpenIKED, a free implementation of the Internet Key Exchange (IKEv2) protocol
Common Address Redundancy Protocol (CARP), a free alternative to Cisco's patented HSRP/VRRP server redundancy protocols
PF, an IPv4/IPv6 stateful firewall with NAT, PAT, QoS and traffic normalization support
Unbound, a DNS validating resolver
dhcpd, a Dynamic Host Configuration Protocol (DHCP) server
pfsync, a firewall states synchronization protocol for PF firewall with High Availability support using CARP
spamd, a spam filter with greylisting support designed to inter-operate with the PF firewall
sndio, a compact audio and MIDI framework
Xenocara, a customized X.Org build infrastructure
cwm, a stacking window manager
tmux virtual console multiplexer
The X.Org Server
Clang
GNU Compiler Collection
Perl
NSD
Ncurses
GNU Binutils
GNU Debugger
Awk

All of this is in the base system of the operating system and it is a part of a standard OpenBSD installation. All the base parts of the system comes with OpenBSD-specific patches, changes and improvements for increased security.

Besides from the above OpenBSD provides, as of writing, more than 9.700 installable applications via the OpenBSD package manager. However, it is important to note that even though you are advised to use the precompiled packages over manually building software from the ports collection, the package collections for the "release" and "stable" branches of OpenBSD doesn't get package upgrades. This means that security updates for packages are only available through the ports system when you are running the "stable" branch.

When serious bugs or security flaws are discovered in the applications in the ports collection, they are fixed in the "stable" branch of the ports tree. Contrary to the base system, the "stable" ports only gets security backports for the latest release. This means that if you're using third party applications you need to check out the correct branch of the ports tree, and build the software manually. The ports can be kept up to date with CVS and you can subscribe to the ports-changes mailing list in order to receive security announcements related to applications in the ports tree.

Another very valid solution is to run with the "current" branch of OpenBSD. The "current" branch is where active development occurs, but the developers are very careful not to introduce new features that may cause the system any problems. The "current" branch is kinda equivalent to a "rolling release" model.

Since the ports collection is related to software from third party providers it does not go through the same thorough security audit that is performed on the OpenBSD base system. The OpenBSD project does not have enough resources to ensure the same level of robustness and security with ports as they do with the base system.

Take a look at the OpenBSD project website for further information.

https://unixsheikh.com/articles/open...fantastic.html