"But to make the sound work, AFAIR you had to "manually" install of dozen of old/unsupported x86 libs;"
But this is really a Java problem, and not a Webex problem per se, and problems/work-arounds would heavily depend on which Java run-time your browser launches for WebStart apps and whether you have matching sound plugins installed or not.
Of course, recent Firefox is probably going to break WebStart and all the enterprise-y apps they don't care about but we need. Guess some people will have to dump Firefox to get NPAPI support back.
"Every time a vendor wants to do something like a webex we have to fire up a virtual Windows environment for them to utilise, and that's ridiculous."
Webex runs on Linux. More poorly than on Windows, but it runs and I was able to screen share on one occasion when I tried it.
You give a specific instance where systemd helps you. Just one.
No, I was responding to one of the examples provided as to why 'systemd sucks' in that it seemed (in the past) to hang at boot if there was a bad entry in
As someone who has also been involved in packaging software for linux distros (and for internal use), I have no problem writing an init script, but I have also seen the many traps that inexperienced users will fall into when writing/modifying an init script. Systemd has done a lot to standardise the way services must behave and provide configuration-based customisation for the most common types of customisation required, such as setting limits, limited configuration required of the service, running a script before starting the daemon etc.
IIRC, you should be able to achieve the same effect in the other scripts by merely checking and waiting on pieces to come up (admittedly, this has been more than a few years, my memory may be hazy as to its simplicity)
I (and you) might be able to, but at present I doubt any of my colleagues would be able to do it correctly without leaving a booby trap for the next sysadmin.
You also specify several workarounds outside of systemd to deal with things others don't like.
So, not using an optional service that systemd provides but doesn't require is a workaround outside of systemd?
The thing you don't address is why systemd, purportedly a startup management system, appears to have taken over as almost a full OS.
So in the past we have run DJBs service tools to supervise processes that are prone to die regularly, but then you can end up with conflicts with what sysvinit wants to do vs what sv_stat, sv etc. want to do, and you have no dependency tracking between the services supervised by the DJBware and the init system (so qmail starts accepting mail before the NFS mailstores are mounted, and bounces the emails until someone notices the alert and mounts the mailstores). Then you have services run by xinetd (started by sysvinit), again with little coordination between them and other services. To me it does make sense to have one daemon that takes care of launching and killing all services. Then again, there is the argument about one cgroup controller (which was apparently the primary reason for systemd in the first place), and as far as I know there isn't a competing init system that has comprehensive built-in native support for cgroups.
It is unfortunate that a lot of other tooling that pre-dates systemd has so much bit-rot that the systemd developers seem to think writing a replacement (e.g. systemd-login) is better than asking the developers (of e.g. ConsoleKit, which itself was a replacement for something, pam_console?) to fix the bugs, but I don't think the intention is to make systemd an OS. And it is quite modular, many of their newer tools are optional (where possible).
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.
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
The 4th issue is cosmetic, and applies to most kernel drivers
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.
"Systemd is pants-on-head retarded when dealing with Network Manager and waking from sleep. It
In over 3 years running a distro using systemd, I've never seen this problem. All network interfaces work correctly on resume (except the 3G modem that needs its driver reloaded, but this is a driver problem).
"It is also pants-on-head retarded when a sound service won't start and it will just fucking
Never seen this one either. Sound mainly just works, including switching streams to my bluetooth headphones when connected.
"These are issues I've personally had to deal with. With Ubuntu"
Ah, Debian/Ubuntu users complaining about systemd. Why is it the Fedora/SUSE/CentOS/RHEL/Arch/Mageia users don't have these problems? Maybe Debian/Ubuntu-specific issues with their systemd migration/implementation?
" x86/Linux just doesn't cut it. I remember I had a Solaris box in a closet that ran consistently I actually forgot to reboot it for 5 years. The only reason I did wind up rebooting it was because it's memory got upgraded because certain functions got a little slower over time as things grew. Quadrupling memory (memory got both cheaper and larger in the meantime) and boom - back to like it was new. x86 Linux systems, at least pre-systemd, were ok but still require some hand-holding. More than 180 days of uptime wasn't really in the cards. No clue on systemd systems, I won't run one until I have no choice."
The uptime of our production Linux servers running on Dell PowerEdge, HP ProLiant, Sun "Galaxy" amd/intel servers or now Cisco UCS is limited only by the application of kernel or glibc securuty updates.
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.
We are migrating (more than 50% done) most workloads to VMs running on Red Hat Enterprise Virtualisation, with 90%+ VMs running RHEL7. Systemd has been a total non-issue. I also can't think why systemd would have any impact on uptime
"The biggest mistake that happened in the original article was the violation of company policy of registering his own private email address for the administration account. Because of that move, the school (in my opinion) was justified in suing the guy."
I don't know specifically in this case, but in some cases in my position I have access to some work-related features on Google and Facebook linked to my personal accounts. Since our company has no products/services from either, I can't really do anything else except possibly make a dedicated account for that one purpose.
If my manager fires all my colleagues, then me (and forces us out to avoid paying severance), then locks himself out of his account, why should it be my responsibility to help him recover from this situation that he created?
If they can make penicillin out of moldy bread, they can sure make something out of you. -- Muhammad Ali