[diltonm]

First, I don't grok the vocal minority's vehement opposition to systemd.

Second, loose couplings are great for those who want to tweak to their heart's content, people who know what they're doing. I used to tweak the heck out of Gnome 2. I grew tired of it and appreciate the simplicity and elegance of Unity and dislike the "we know what's best for you" attitude that Gnome 3 conveys to me. Unity just needs to have 3 sane defaults reverted that I've mentioned in other comments.

Third, you can still tweak Linux to use whatever desktop you want. Back when I was on Windows I even hacked the registry to make the DOS command prompt my UI as a joke and it worked. Booted, no explorer running at all. Just the Windows XP kernel, few processes it started and DOS CLI that was it. It taught me that most of the stuff users interacted with on XP was actually started by and run by explorer which explained why the system grew so unstable when it crashed and I had to restart explorer.exe from the Task Manager by hitting Ctrl_Alt_Delete IIRC.

Having a common UI/UX is great for a lot of people out there including those of us who know all about loose coupling and tweaking things but usually just want to do what we want to do without all of that tweaking. Except on those weird days on the week-end when we try new stuff out like a checking out how KDE is coming along. Still too complex for my tastes but it looks great!

[badsock]

Loose coupling allows the "shiny thing of the week" folk to not wreak havoc on the "good engineering" folk.

When DEs like Unity followed Microsoft down the disastrous blind alley of "desktops should act like tablets", that was OK because the loose coupling allowed by defined protocols like ICCCM meant that I could wait it out in XFCE.

The fact that practically every distro has gone with systemd, and that the couplings are tight, means that I have to leave Linux entirely to wait out this disaster.

[diltonm]

Agreed, the designers of X made some truly brilliant decisions.

http://en.wikipedia.org/wiki/Inter-Client_Communication_Conv...

Edit: I don't have a dog in the hunt on systemd but if it really is tight coupling then history might prove it was a bad decision. There was a lot of let's say strong opinions against Pulse Audio on Linux but I find (once we got through the growing pains) that it's a blessing. It's far superior to Windows 7's basic audio management in my opinion. I've no idea about Windows 8.

[nitrogen]

Everything PulseAudio does should have been implemented as part of ALSA though, not as another layer that only exposes a fraction of the libalsa functionality.

[Shish2k]

Wouldn't that imply putting a network-accessible server in the kernel? That seems a fair bit more risky than non-root userspace...

[nitrogen]

No, alsa actually does its most interesting stuff in userland.

[tom9729]

You clearly haven't used Unity; it's basically a clone of the OS X 10.6 interface (before they changed spaces) built on top of GTK3. It's got a useful set of standard key bindings (hold SUPER for a cheat sheet). It would actually be pretty awkward to use on a tablet.

Gnome 3 OTOH is as you describe: giant touch-friendly menus, swipe to unlock (with a mouse), etc.

Your position seems a little alarmist. How does systemd mean you need to stop using Linux? I'm sure XFCE will continue to work.

[badsock]

Agreed about Gnome 3, but from the Wikipedia article on Unity:

"In July 2012, at OSCON, Shuttleworth explained some of the historical reasoning behind Unity's development. The initial decision to develop a new interface in 2008 was driven by a desire to innovate and to pass Microsoft and Apple in user experience. This meant a family of unified interfaces that could be used across many device form factors, including desktop, laptop, tablet, smart phones and TV. Shuttleworth said "‘The old desktop would force your tablet or your phone into all kinds of crazy of funny postures. So we said: Screw it. We’re going to move the desktop to where it needs to be for the future. [This] turned out to be a deeply unpopular process.”"

In answer to your question, systemd is in an excellent position to inject non-determinism into the functioning of the OS at all kinds of levels. I've got a hair-trigger response to things breaking and fixing themselves randomly, courtesy of a couple of years working with Windows. systemd has already demonstrated this behaviour, and I feel fairly safe in predicting that this will increase as systemd gains in complexity. Never to the point of being a major problem, just enough to be a persistent annoyance.

Major point being, however, that if it does turn out as I expect, there's going to be no avoiding it while still using the mainstream Linux distros.

[Monotoko]

My homelab (and VMs) have been on Jessie for some time now - systemd is the default and I really like it. It solves a lot of issues

Before systemd::

* is it checkconfig, configtest, etc to test this service config?

* Why the are you storing logs in /var/log/messages, /var/log/syslog, and your own logs?!

New features::

* Dependancies, systemd handles these nicely.

* Different types of services, from simple to one-shot (which is where your startup scripts are meant to go! The devs have thought of this!)

* We can do away with GRUB menus if you only have one OS (systemctl set-default rescue.target) - you can also set it in your boot parameters.

* journalctl - well, at least it's all going to one place now....

[vezzy-fnord]

is it checkconfig, configtest, etc to test this service config?

checkconfig and configtest were just initscript arguments that exec()ed the relevant program's own sanity checking facilities. I don't see how this is relevant.

Why the are you storing logs in /var/log/messages, /var/log/syslog, and your own logs?!

Solved much more elegantly by the likes of daemontools and derivatives (s6, runit, etc.), many years before systemd.

Dependancies, systemd handles these nicely.

Hardly "new". Dependency systems in init daemons and service managers have been rolled many times, from the primitive need(8) facility to the LSB initscript headers (which almost all SysV-based distros had adopted) to OpenRC, Solaris SMF and so forth.

systemd's model is far more involved. It's also far more prone to races and dependency loops.

Different types of services, from simple to one-shot (which is where your startup scripts are meant to go! The devs have thought of this!)

The semantics for managing long-running services and doing one-shot scripts are different. You can use standard tools from util-linux to craft much of the execution environment that systemd gives you through its unit options, and then time these either through at or cron. Nothing compelling here.

We can do away with GRUB menus if you only have one OS (systemctl set-default rescue.target) - you can also set it in your boot parameters.

Um... have you actually read what the systemd rescue shell does?

It boils down to this:

      plymouth quit
      echo "Friendly message here."
      sulogin; systemctl default

Where systemctl default is like going to a multi-user runlevel or whatever other overlay/synchronization point/service group/milestone/term used in other systems.

Yeah, it's totally worth switching over because of this.

journalctl - well, at least it's all going to one place now....

See comment above about daemontools' solution.

There's also a ton of log indexers specifically tailored to high configurability.

[tom9729]

> Solved much more elegantly by the likes of daemontools and derivatives (s6, runit, etc.), many years before systemd.

Then why is no one using them?

> Hardly "new". Dependency systems in init daemons and service managers have been rolled many times, from the primitive need(8) facility to the LSB initscript headers (which almost all SysV-based distros had adopted) to OpenRC, Solaris SMF and so forth.

Exactly. Isn't the point of systemd to bring the ideas from launchd (and SMF) to Linux?

[vezzy-fnord]

There's nothing about loose coupling that implies poor UX. It's more about seamless interchangeability of components, which if you don't care about, will make no difference to you.

Trying to impose an ad-hoc diktat in the Linux community where you insist that X shall be the one true DE, Y shall be the single package manager and Z the service manager, does nothing but piss off people who actually care about Linux, and will do nothing to bring about the Year of the Linux Desktop, because most end users simply take whatever OEMs ship.

But there's a more destructive thing. By doing this, you're sending out a message: "Fuck experimentation. Fuck academic research. There is only one path and one dogma."

Now, if it was just about having de facto defaults, that's tolerable. The issue is that deep-seated standards and dependency chains are being created in the process, where someone who researches and implements a formidable alternative to a piece of system software will have to go through a ton of unnecessary and superfluous hoops just to stand a fighting chance, all because of the narcissism and egos of a bunch of people who thought that they could reinvent the world, and this time they'd get it right, dammit.