Hacker News Reader

> 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.

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.

> 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.

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)

The biggest problem in "FreeBSD desktop" is not the "FreeBSD" part - that works pretty much fine.

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.

Please elaborate on "more and more IT guys I know move over to Free/OpenBSD" and your mentioned easiness of migration.

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.

> and at almost $80hr (Texas), he's making better coin than most programmers here.

Not sure about all programmers but I'm at $200 and I'm underpaid compared to my coworkers. Big telco.

You're underpaid at $200 an hour?

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.

And in the world where people in Walmart are paid $200 an hour, what price does Walmart sell a jar of pickles for?

In real terms, exactly what it cost in 1980.

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.

> 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.

Right, because Linux is still open source. That is its main point and benefit

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)?

Post #5 in the below link gives you what you seek:

https://forums.freebsd.org/threads/systemd-vs-launchd.44973/

This is a pretty perfect answer to my question, thanks!!

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.

https://chiefio.wordpress.com/2016/05/18/systemd-it-keeps-ge...

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.

Are you referring to systemd-journal-remote?

* 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?

https://www.freedesktop.org/software/systemd/man/journald.co...

Seriously, it's in the man page.

Seriously, 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.

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.

You don't seem to have linked to any particular section of the man page. Linking the whole manual is not helpful.

Ignore SystemD even for a moment.

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.

As a Gentoo user, I don't see how I'm impacted. What is this systemd or pulseaudio that you speak of? :-)

They are both in portage should you want them.

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.

I believe this offering appeared in April.