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.
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.
https://chiefio.wordpress.com/2016/05/18/systemd-it-keeps-ge...
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.
* https://www.freedesktop.org/software/systemd/man/systemd-jou...
I am referring to something syslog-based:
* https://en.wikipedia.org/wiki/Syslog#Internet_standard_docum...
which can be used by other tools to process.
Can you point me to documentation on how journald can be configured to send to a remote syslog server?
Seriously, it's in the man page.
From the man page:
> 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.
People have been claiming this for the past 20+ years that I've been working with Linux.
I'd take it with a grain of salt.
Who? Where? for what?
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.
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 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.
These are but a few. Here in the Houston area, there are tons of FreeBSD/OpenBSD users.
Not sure about all programmers but I'm at $200 and I'm underpaid compared to my coworkers. Big telco.
Yes $200/h is underpaid, it should be what people working at Walmart get paid.
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.
I believe this offering appeared in April.
https://forums.freebsd.org/threads/systemd-vs-launchd.44973/
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 :)
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.
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.
Check out how many projects Red Hat claims to "maintain" https://fedoraproject.org/wiki/Red_Hat_contributions
IBM could leave GNOME, gtk, and graphics stuff out to dry. After all, GNOME doesn't sell cloud server support contracts.
Did Devuan ever get their build servers back up after they did a childish aprils fools day joke?
Is this really true? It seems to me that a lot of the people who control the direction of Linux might work at RedHat and IBM, but that can change. It has in the past and it will in the future, billion$ acquisitions don't make them immune.
There's a history of companies simply acquiring the competition:
1) Ansible was written by a former Red Hat employee, and then Red Hat simply acquired his company.
2) Centos was an open source alternative to RHEL, and then Red Hat simply acquired the company.