Slashdot Mirror

Some of our Linux servers that are not exposed to any hostile networks and inconvenient to reboot (e.g. monitoring display server that is displayed, along with other stuff, on a 30mx6m video wall) have uptimes of 5 years or more.... I also can't think why systemd would have any impact on uptime ...

5 years? Seriously? You're running on an 5 year old kernel with multiple known issues (TLS, OpenSSL, etc)?

I didn't say they don't get any updates at all. They just don't have kernel updates applied. There are multiple firewalls protecting these specific servers from hostile users/networks, and 90% of the people who have any access at all (e.g. HTTPS access) have sudo rights to run various things as root on them anyway. The only systems that have any firewall access to them are the other monitoring servers, and all the monitoring software is kept up-to-date.

As for systemd, you must not be very well versed in it. SSH Fails,

Yes, some versions of systemd introducing new features may have bugs. Only immature distros would push such versions out to users of stable releases.

NTP

Using timesyncd isn't mandatory. The distro I use on my laptop doesn't use it, RHEL7.3 doesn't ship it.

magically fixed a service startup issue, no one knows why,

Doesn't seem like anyone could reproduce that on other versions (shipped in stable distros, or current).

and just a general list of why systemd sucks.

Of the 5 major complaints, 3 are about the journal. There are some advantages to it, and some disadvantages, and I think systemd should support not using journald at all, but you can avoid relying on the journal itself by forwarding to syslog and disabling storage.

Regarding giving block devices for filesystems listed as required in /etc/fstab, this is a conscious design decision that is required in environments with complex storage (many storage arrays in a complex storage area network). The alternative (with e.g. sysvinit) is to have your production database servers fail to come up at boot time because the init system didn't give enough time for all 100 LUNs to appear so that it could mount the filesystems required to let the database start. It is really fun to have to be woken up to get such systems back up after a rack has tripped because then engineer on standby can't figure out what to do, I'd rather have systemd do the right thing. As far as I know, the default timeouts have been reduced (systemd wasn't hanging though ... it was waiting for devices it was told were required to appear) and provide more information on why it is waiting.

The 4th issue is cosmetic, and applies to most kernel drivers ... only dracut namespaces its parameters (rd.xxx).

And that took all of 2 min to search, read, and compile, because I wanted to give you some solid backing for stating it sucks.

Yes, it is trivial to find old bugs that are fixed, and FUD complaints from systemd haters about behaviour that has been improved.

You're in RH land with supported versions, so it's likely that these problems, when they crop up, are offloaded as RH issues and you just monitor a trouble ticket. Lucky you. I guess I wouldn't care in that scenario either, as it's SEP.

Our production servers run Red Hat. We haven't needed to log a ticket for anything systemd-related.

My workstation, my laptop, and the desktop my wife uses at home run a different distro not associated with Red Hat at all that switched to systemd long ago, and I have seen no issues there either.

Some of our Linux servers that are not exposed to any hostile networks and inconvenient to reboot (e.g. monitoring display server that is displayed, along with other stuff, on a 30mx6m video wall) have uptimes of 5 years or more.... I also can't think why systemd would have any impact on uptime ...

5 years? Seriously? You're running on an 5 year old kernel with multiple known issues (TLS, OpenSSL, etc)? I hope they're firewalled well. As for systemd, you must not be very well versed in it. SSH Fails, NTP magically fixed a service startup issue, no one knows why, and just a general list of why systemd sucks. And that took all of 2 min to search, read, and compile, because I wanted to give you some solid backing for stating it sucks. You're in RH land with supported versions, so it's likely that these problems, when they crop up, are offloaded as RH issues and you just monitor a trouble ticket. Lucky you. I guess I wouldn't care in that scenario either, as it's SEP.

Marshall Kirk says: "Check back on the FreeBSD Foundation web site in the last few days of the year or January of next year to see the final result." (End quote.) But to me it's like a spectator sport!

It's not a "failure" by any stretch of imagination. A lot of fundraising projects set an ambitious goal, and the year is far from over. The current tally is $304,844 - perfectly "on target"!

UPDATE: $319,614 - from 1082 donors!

Maybe the December issue of the BSD Magazine, which just came out yesterday, will remind more people to donate...

Maybe some are waiting for 9.1 release...

And maybe, as feedback for the recent security screw-up, some people have decided to donate to other projects (hopefully copyfree ones) instead...

--libman

UPDATE: $325,359 - from 1102 donors!

Please donate today!

--libman

It's not a "failure" by any stretch of imagination. A lot of fundraising projects set an ambitious goal, and the year is far from over. The current tally is $304,844 - perfectly "on target"!

UPDATE: $319,614 - from 1082 donors!

Maybe the December issue of the BSD Magazine, which just came out yesterday, will remind more people to donate...

Maybe some are waiting for 9.1 release...

And maybe, as feedback for the recent security screw-up, some people have decided to donate to other projects (hopefully copyfree ones) instead...

--libman

Hi, latest BSD mag 1/12 has this article Home Brew Captive Portal With OpenBSD:
Have you ever used a public wireless network that has a splash screen such that you have to agree to certain terms before going to the Internet? The author of this article will show you step by step how to build one of those using OpenBSD’s Packet Filter (pf).

Where does Linux fail where BSD succeeds?

For some people it's the licensing (BSD vs GPL). For others it is the coherence of the system (how many places hide an IP address in Red Hat?). For others, it is a question of style (BSD vs AT&T type Unix). For some, its functionality (I always liked the way the BSD _______ command worked). From some, it's the simple Joy of BSD, or the McKusick - take your pick. For some, it could be the approach taken to a particular problem taken by one of the BSDs, such as the continuous OpenBSD code audits. For some it might be a particular platform maintained as part of the main distribution. For some, it may be the continuing BSD innovations. For some it might be the counter-culture aspect BSD in the Linux world. Plenty more reasons that people could have, including: Linux - 5 letters, BSD - 3 letters. Do the math.

You could say that the only truly popular Unix desktop is Apple's Macintosh running OS X.
Mac OS X: What is BSD?

What's The Greatest Software Ever Written?

OpenBSD FreeBSD NetBSD PC BSD

FreeBSD Mall BSD Magazine

To each his own.