6 ms·
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 happ
by stirfrykitty 7y ago
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.
- einpoklum 7y agoThe 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 https://unix.stackexchange.com/q/433159/34868
- stirfrykitty 7y agoDevuan 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. https://chiefio.wordpress.com/2016/05/18/systemd-it-keeps-getting-worse/ https://chiefio.wordpress.com/2016/05/18/systemd-it-keeps-ge...
- throw0101a 7y agosystemd-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.
- Conan_Kudo 7y ago> 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.
- throw0101a 7y agoAre you referring to systemd-journal-remote? * https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.service.html https://www.freedesktop.org/software/systemd/man/systemd-jou... I am referring to something syslog-based: * https://en.wikipedia.org/wiki/Syslog#Internet_standard_documents 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?
- babarock 7y agohttps://www.freedesktop.org/software/systemd/man/journald.conf.html https://www.freedesktop.org/software/systemd/man/journald.co... Seriously, it's in the man page.
- wtallis 7y agoYou don't seem to have linked to any particular section of the man page. Linking the whole manual is not helpful.
- silversconfused 7y agoYour 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.
- throw0101a 7y agoSeriously, do you understand the word REMOTE? 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.
- davidw 7y ago> Linux has become what it hated in Windows. 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.
- galaxyLogic 7y agoRight, because Linux is still open source. That is its main point and benefit
- jvagner 7y ago> the move towards FreeBSD 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.
- stirfrykitty 7y agoIt'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.
- m45t3r 7y ago> And yes, FreeBSD replaces Linux easily. 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.
- bluGill 7y agoDepends 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)
- pmarreck 7y agoNot 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. I believe this offering appeared in April.
- deleted 7y ago[deleted]
- pmarreck 7y agoApologies 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)?
- stirfrykitty 7y agoPost #5 in the below link gives you what you seek: https://forums.freebsd.org/threads/systemd-vs-launchd.44973/ https://forums.freebsd.org/threads/systemd-vs-launchd.44973/
- pmarreck 7y agoThis is a pretty perfect answer to my question, thanks!!
- waddlesplash 7y ago> 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 :)
- bluGill 7y agoFreeBSD 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.
- stirfrykitty 7y agoI 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.
- dingu 7y agoPeople 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.
- trasz 7y agoIn 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.
- BeetleB 7y agoAs a Gentoo user, I don't see how I'm impacted. What is this systemd or pulseaudio that you speak of? :-)
- kevin_b_er 7y agoIgnore SystemD even for a moment. Check out how many projects Red Hat claims to "maintain" https://fedoraproject.org/wiki/Red_Hat_contributions 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.