"CEOs get their bonus by raising the stock price."

Even if everyone below them knows that in order to achieve the sudden increase they have destroyed the ability for the company to operate for more than another 5 years.

The usual approach by American MBA CEOs is to cut every conceivable operational expense that isn't required in the short term of their contract's huge bonus conditions (like stop maintaining equipment, getting rid of staff who work on future products or research etc.).

Because of the limited scope (doesn't need to be able to open network sockets, access files etc.) the browser can sandbox it more effectively.

There is one thing the vSphere Web Client does exceedingly better than the (thick) vSphere Client: allows vSphere admins who don't use Windows on their laptops to work more effectively.

While there are some differences in functionality and where features reside, vSphere Web Client is fantastic (except that on Linux it only works on Chrome due to requiring a newer version of Flash than is available as a NPAPI plugin). The fact that the vCenter appliance supports bigger environments now actually allows one to run a non-Windows vSphere shop.

Red Hat's RHEV (vSphere competitor) only has a web app, and this has counted in its favour in the past when vSphere was limited to Windows only. We will be migrating to RHEV for other reasons though ...

It seems Mozilla wants to move away from http, but here are some use cases they will be breaking:

I have a slow and expensive Internet connection used by a few people on a few different devices, I use a proxy-cache to improve page load times and reduce network traffic.

I am a parent, and while I try to be present whenever the kids use the internet, I run a proxy-filter (e.g. DansGuardian) to prevent them from stumbling across less suitable sites.

I am a service provider, and I use a transparent proxy to cache large files downloaded from international sites. This saves me about 10% of my running costs.

I am a service provider provoding internet access with high input costs, in order to provide reasonably-priced services I have quota-based products. In order to be friendly to my customers and avoid them incurring over-use charges, I inject JS notifications at various thresholds. With only HTTPS, I will just have to wait until they are over quota and then block all HTTPS traffic and hope I can redirect some HTTP traffic to a page informing them that they are over quota.

I am a security engineer for my company, for various reasons we need to be able to inspect http traffic (prevent users from visiting malicious sites, enforce productivity controls etc.).

Sure, there are technical means around some of these challenges (e.g. devices that ship with/use CA certs and dynamically generate SSL certs to MITM the traffic), but this initiative is just going to increase costs for everyone.

And who will benefit? Well, most of the main sponsors of Let's encrypt. Cisco will be selling you more network equipment that can MITM SSL, Akamai will get more business as ISPs will not be able to cache on their own and content owners will have to pay Akamai instead.

Maybe some affected parties will start blocking Firefox (or block ssl upgrade checks), or some service providers may start charging Firefox users more.

I am a supporter of open source and have used Firefox as my primary browser since before the 1.0 release, but some of the supposed security braindeadness has made life more difficult, and this is just another example, and may be the one that forces me to change to a web browser, instead of an HTTPS-only browser.

If you don't need the feature, it doesn't listen on any socket.

The default installation on most distros will probably not use socket activation, but some systems will *require* socket activation, just like in the past they required inetd or xinetd.

It didn't install xinetd systemd is the default :-p

# apt-cache search xinetd
?

Every modern Unix-like system has inetd or xinetd available, many install one of them by default.

The service we require xinetd for on every production server is: Netbackup's bpcd.

# readlink -f $(which init) /usr/lib/systemd/systemd
# netstat -plant|grep systemd
#

How is systemd any different?

# systemctl status rsyncd.socket
rsyncd.socket - Rsync Server Socket
      Loaded: loaded (/usr/lib/systemd/system/rsyncd.socket; disabled)
      Active: inactive (dead)
      Listen: [::]:873 (Stream)
  Accepted: 0; Connected: 0
# cat /usr/lib/systemd/system/rsyncd.socket
[Unit]
Description=Rsync Server Socket
Conflicts=rsyncd.service

[Socket]
ListenStream=873
Accept=yes

[Install]
WantedBy=sockets.target

What is this, a non-text file? How is systemd controlling this, any more than xinetd was?

Really?

I found the systemd documentation installed on my machines tgst have systemd to be very comprehensive.

But it seems the anti-systemd crowd don't know how to find or read man pages, so I'll provide a link to one they can read: here .

You obviously aren't aware of inetd or xinetd, although you probably have them running, started by your precious sysvinit.

If you can fix it in /etc/init.d/zfs, you can just as easily copy /usr/lib/systemd/system/zfs.service to /etc/systemd/system and fix /etc/systemd/system/zfs.service

Surely you have vi or emacs or nano or pico or something available, with which to add a Requires entry (see systemd.unit(5)) to the zfs service unit?

The sleep button works perfectly here on a system running systemd and KDE. Maybe you have a problem somewhere else.

The only seemingly valid complaint I have seen is that systemctl doesn't provide the exist process. But, this is only the case for Type=simple (yes, the default type), where you probably want Type=forking or Type=oneshot.

1)Don't omit Type=, or use Type=simple, in the case of a non-simple process, you probably want Type=forking
2)Surely you're learned how to use 'systemctl status foo' or journalctl ?

You may have been better off reading systemd.service(5), but junior admins should be taught how to use strace regardless ...

I think part of the problem is that sysvinit is basically feature-less, and for a running system actually does nothing (it is initscripts that does this), and so people are used to just having the entire system run by scripts with no useful features (e.g.doing something different with stderr than leaving it to the controlling terminal, letting the current user pollute the environment and thus never have consistent starting of services etc. etc.).

If you had correctly used Type=oneshot, you wouldn't have been in the dark and would have seen this on the terminal:

# systemctl start broken_systemd
Job for broken_systemd.service failed. See 'systemctl status broken_systemd.service' and 'journalctl -xn' for details.
# systemctl status broken_systemd -l
broken_systemd.service - Broken systemd example
      Loaded: loaded (/etc/systemd/system/broken_systemd.service; disabled)
      Active: failed (Result: exit-code) since Sat 2015-04-25 07:53:07 SAST; 26s ago
    Process: 7880 ExecStart=/root/broken_systemd.sh (code=exited, status=1/FAILURE)
  Main PID: 7880 (code=exited, status=1/FAILURE)

Apr 25 07:53:07 HOST broken_systemd.sh[7880]: Example systemd service
Apr 25 07:53:07 HOST broken_systemd.sh[7880]: Error that should not be thrown away
Apr 25 07:53:07 HOST systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Apr 25 07:53:07 HOST systemd[1]: Failed to start Broken systemd example.
Apr 25 07:53:07 HOST systemd[1]: Unit broken_systemd.service entered failed state.

Just because sysvinit couldn't do anything useful with stderr from a one-short service (and leave it to the controlling terminal to do something with it) doesn't mean systemd shouldn't. Logging it, and informing the user that the job didn't start and where to see more information is much more useful.