There is a lot of truth to this. Since Fedora is the upstream for Red Hat, and IBM historically kill off anything not making a profit, how long before this happens? I wonder if they'll split the two?
Red Hat does "control" a disproportionate amount of Linux development. Everything is also now basically dependent on systemd.
I'm seeing more and more IT guys I know move over to Free/OpenBSD because they don't like the direction Linux is taking. While Linux is only a kernel, the entire userland is basically dependent on systemd.
Linux has become what it hated in Windows. A massive, bloated mess. I've always preferred BSD on the server and something else on the desktop (hurry up, Haiku!). I still wish BeOS would have gotten more traction beyond the BeBox.
Methinks the move towards FreeBSD--and it's happening in quite a few circles, will continue, especially if IBM get heavy handed with Fedora/Red Hat. I'm not worried, per se, but I am concerned, for the aforementioned reasons.
You mentioned BeOS. Sorry, I love nostalgia too, but I have no idea what you're talking about. Out in AWS, GCP, Azure, DO -land... it's still going to be Ubuntu, Debian, CentOS, Windows, etc for a long time.
It's all in what people are willing to tolerate or change. Obviously, the gentlemen over at Haiku feel they have something to offer, as small as it may be. I always though that BeOS was somewhat revolutionary in its approach.
I'm still somewhat bothered that Apple let their server offering go. And yes, FreeBSD replaces Linux easily. Not everyone runs their stuff in the cloud. It's not the be-all and end-all. Serious non-IT businesses are still on mainframes, BSD, and other, and there are plenty of them. A friend of mine is a COBOL programmer for a large financial house, and he's set for as long as he wants to work there, and at almost $80hr (Texas), he's making better coin than most programmers here.
No, it doesn’t. Take any non trivial system running Linux and try to run it in FreeBSD. You may get it running in little time, however the number of issues you would have would be big.
Remember that the modern stack have multiple layers of complexity, Linux, your app, SomethingSQL, AnotherThingDb, Kubernetes, AWS/GCE/Azure, etc. Since FreeBSD is not the common choice to run those things you will probably hit a issue here, another issue there, a combination of issue in one layer with another, etc.
Yeah, this may say more about our current systems than anything, however to say that it is easy to substitute Linux with FreeBSD is simply not true.
For the core parts, such as database engines, webservers, programming languages, etc. then you should not encounter any trouble. I've done this and found little trouble.
For glue like kubernetes, yes, you're going to find differences or even lack of support for that specific tool. Ansible works pretty well, in my experience. But this is the more superficial stuff. If you're going to migrate for whatever reason, then updating the automation tooling around the systems you're managing is not that difficult.
Depends on the system. For a desktop enviornment you are correct, *bsd is at best an after thought to pretty much all projects. However "serious" server programs tend to get much more testing on BSD. I don't think you will have any issues running a database on BSD, and probably not a web server (though some web frameworks are Linux first so YMMV)
I run a FreeBSD desktop. There are enough problems that I wouldn't install that for my family. Too many blank windows and the like (I suspect graphics driver issues but have no idea how to debug further)
I wouldn't install it for my family either, but I wouldn't do that with Linux either. It can be fine for chromebook-like usage, but not as the usual desktop.
I know former colleagues on the East coast and in the EU who I stay in contact with who, oddly enough, they are all looking at NetBSD for embedded HW work. We all used to work together at a small startup in NOVA, but we all parted ways about 12 years ago. All four of us did *nix stuff and more or less still do, but I'm pure SW, while they are more HW/SW integration.
These are but a few. Here in the Houston area, there are tons of FreeBSD/OpenBSD users.
If I was making what my father was making at my age for doing the same job relative to the size of the economy at the time I should be getting paid 1.125 million.
Yes $200/h is underpaid, it should be what people working at Walmart get paid.
FreeBSD just got some big updates to improve performance on multi-core virtualised systems. I'm looking forward to testing them.
Yes, you're right, Ubuntu, Debian, CentOS etc. are the common systems in use for this purpose today. But, if you needed to, you could absolutely use FreeBSD as an alternative. And should there be pressure to drop any of these Linux systems for any reason, having alternatives right there you can switch to is very useful. As is avoiding vendor locking and ensuring there's meaningful competition.
Hobbyists move first. Speaking of nostalgia, I'm sure you remember when people would mention they were moving to Linux and were laughed at — Windows, Solaris, AIX, HP-UX, and so on were the serious server OSes.
FreeBSD is looking closely at systemd. While it is agreed it isn't the right solution to the problem, it is also agreed it solves a problem that init scripts cannot solve. Systemd as is will not (for legal reasons) ever be in freebsd, but don't be surprised if FreeBSD writes their own semi-clone that does most of the same things and implements a good part of the interface. I suspect if debian will drop systemd for the freebsd replacement a few years after it is released.
I like BSD-style init scripts; they are easy to work with and understand. I dislike this trend that systemd started. Pretty soon, everything will be a binary blob. This is one of the reasons I love OpenBSD--no binary blobs. OpenBSD runs great on most laptops with a few issues, but for the most part, I've had great success. It's very stable, easy to learn and use, and more importantly, secure. I want for nothing using it. And I show my age when people see I still run WindowMaker as my preferred DE.
People use systemd because it solves real problems that are not adequately solved by init scripts. Your "want for nothing" says more about your limited needs (which is fine) than anything else about system management services.
Regardless of one's opinions or critiques about the implementation of systemd specifically, the idea that it came up in some kind of vacuum or started a "trend" is utterly ridiculous.
Prior art in UNIX would be SMF at a minimum, and systemd clearly looked at launchd for some inspiration in other areas (systemd ended up having the goal of covering both use cases of launchd and SMF.. ie generally server and desktop).
Also what is this about binary blobs? systemd is configured with text files. Last I checked, the init process itself on BSD is a binary.
In BSD, the init(8) binary doesn't do much regarding startup - basically just executes /etc/rc; it's shell scripts all the way afterwards, nothing hardcoded.
What exactly cannot be solved with init scripts?
Also, keep in mind that FreeBSD init scripts (which actually come from NetBSD as rcng) are very different from the SysV mess Linux used to use - they handle dependencies, have a sane way of configuring way, they don't reimplement features which ceased being useful in the eighties (runlevels) etc. They are also quite fast. This means the pressure to migrate off to something else is much lower.
There are things to like about init scripts. That is why freeBSD hasn't jumped in and created a systemd like replacement. However systemd as an approach to starting services has some significant advantages and that FreeBSD wants. Smart people are thinking hard about the problem in hopes they can come up with a good compromise.
Apologies for hijacking but can someone elucidate the differences between `systemd` and something like apple's open-sourced `launchd` (which I'm more familiar with and which I think is reasonably good)?
The userland is absolutely not dependent on systemd _at all_. Have a look at Devuan, and you'll see that almost all of the userland remains exactly the same. See: https://unix.stackexchange.com/q/433159/34868
Devuan is but one fork among many. It has zero traction in the enterprise space. Devuan, Gentoo, et al, are niche players. While their userlands may be "pure", they represent a minuscule fraction of Linux users.
And yes, systemd is a dependency for quite a few userland programs. Here is one of the best articles I've read on why systemd is really bad.
systemd-was-init-replacement was not bad. systemd-as-kitchen-sink is where problems started. E.g., creating a binary log file format that is non-ACID, and corruption entails throwing the file away--instead of just leverage SQLite; and then not having a way to send logs remotely, so you have to run rsyslog anyway.
> and then not having a way to send logs remotely, so you have to run rsyslog anyway.
journald has its own remote gateway and can ship logs elsewhere. It's not on by default, but you can easily configure it. There are several addons for plugging in specific protocols and services into the journal.
> Journal events can be transferred to a different logging daemon in two different ways. With the first method, messages are immediately forwarded to a socket (/run/systemd/journal/syslog), where the traditional syslog daemon can read them. This method is controlled by the ForwardToSyslog= option. With a second method, a syslog daemon behaves like a normal journal client, and reads messages from the journal files, similarly to journalctl(1). With this, messages do not have to be read immediately, which allows a logging daemon which is only started late in boot to access all messages since the start of the system. In addition, full structured meta-data is available to it. This method of course is available only if the messages are stored in a journal file at all. So it will not work if Storage=none is set. It should be noted that usually the second method is used by syslog daemons, so the Storage= option, and not the ForwardToSyslog= option, is relevant for them.
That is all about local. Again: I end having to running a syslogd locally so that I can send stuff remtely using an industry standard protocol.
Your man page link confirms the capability is not there. It can forward to local syslog, which is still both useless (logging holes still exist) and needlessly redundant for this purpose.
The key point is that they are not on by default, and AFAIK, Gentoo has committed to make everything work without them. An average Gentoo user would never have heard of systemd.
> and something else on the desktop (hurry up, Haiku!).
If you'd like us to hurry up, we could use more hands; software (doubly so clean, well-designed software) does not write itself, especially on shoestring budgets :)
Not sure if related, but I do note that Amazon EC2 now has an Ubuntu stack option for their lowest tiers instead of their default, weird, not-always-well-supported fork of RHEL that they've been using since inception.
Red Hat does "control" a disproportionate amount of Linux development. Everything is also now basically dependent on systemd.
I'm seeing more and more IT guys I know move over to Free/OpenBSD because they don't like the direction Linux is taking. While Linux is only a kernel, the entire userland is basically dependent on systemd.
Linux has become what it hated in Windows. A massive, bloated mess. I've always preferred BSD on the server and something else on the desktop (hurry up, Haiku!). I still wish BeOS would have gotten more traction beyond the BeBox.
Methinks the move towards FreeBSD--and it's happening in quite a few circles, will continue, especially if IBM get heavy handed with Fedora/Red Hat. I'm not worried, per se, but I am concerned, for the aforementioned reasons.