Read this guys comments on LWN.net. Based on those he seems like a really cool guy. For example :
http://lwn.net/Articles/641275/
He’s nickname is mezcalero.
cron is installed and enabled by default on openSUSE. Starting with 13.2 syslog is not, but there are several implementations included in the distribution: rsyslog (the default since years until 13.1), syslog-ng, syslogd.
On Tumbleweed you might have to manually set the Option “ForwardToSyslog=yes” in /etc/systemd/journald.conf, I’m not sure.
In 13.2 just installing a syslogd should suffice.
To disable systemd’s on-disk journal, just delete the folder /var/log/journal/.
And for most users, there is not really much to “learn”.
Use “systemctl start xxx” to start services, “systemctl stop xxx” to stop services, “systemctl enable xxx” to enable starting service xxx at boot, “systemctl disable xxx” to disable starting service xxx at boot, and “systemctl status xxx” to get service xxx’s status.
You can set the default target via “systemctl set-default xxx.target” and you can get the currently set default boot target via “systemctl get-default”.
Or just use YaST->System->Services Manager.
systemd does support old sysvinit style init scripts in /etc/init.d, use the same systemctl commands to control them.
And actually the old style commands “rcxxx start” or “/etc/init.d/xxx start” and so on, “chkconfig”, “insserv” should work as well in openSUSE, even for systemd units (except /etc/init.d/xxx for obvious reasons).
I don’t really want to go into such a discussion, but a few notes regarding that, as there’s much FUD going around in the net…
Non-POSIX,
systemd still supports old-style init scripts and on openSUSE the old style commands are available too (see my previous post), that should be POSIX enough, no?
binary codes,
What does that mean?
Of course systemd itself is binary code, like any other application, even sysvinit.
The config files and units are not binary, and even simpler than sysvinit scripts.
reboots after upgrades (servers?),
That’s nonsense. You only need to restart the updated services, exactly the same as with sysvinit.
You can even restart systemd itself in the running system, with “systemctl reexec”.
doubling the attack surface, less transparency, fundamental changes to the system - encapsulating ‘everything’ into systemd (more frequent system crashes?),
Actually that’s not true either.
systemd consists of many independent executables. Only the core init system is running as PID 1.
Non-POSIX,
systemd still supports old-style init scripts and on openSUSE the old style commands are available too (see my previous post), that should be POSIX enough, no?
It seem like the concern very much is about for how long any aspect regarding systmd will be flexible, have an alternative to be practically viable; further, that it seems to try encapsulating more and more.
reboots after upgrades (servers?),
That’s nonsense. You only need to restart the updated services, exactly the same as with sysvinit.
You can even restart systemd itself in the running system, with “systemctl reexec”.
doubling the attack surface, less transparency, fundamental changes to the system - encapsulating 'everything' into systemd (more frequent system crashes?)
Actually that’s not true either.
systemd consists of many independent executables. Only the core init system is running as PID 1
These seem like real issues according to this: http://ewontfix.com/14/ (read both ‘reasons’ and ‘possible counter arguments’)
I’m reading the discussion which glistwan pointed to (a bit technical for me though).
But again, my impression is that this guy is being argumentative, renouncing any argument put against him; and, he’s often, it seems, tending to be misunderstanding what is put forward.
There are alternatives, but somebody has to develop/maintain them. And that’s not systemd’s or systemd’s developers’ job.
Such as it is not systemd’s business to support/provide system services for those other init systems.
And even that API “lock-in” that’s mentioned on the page you link to isn’t really an issue, as the communication runs over DBUS anyway. You just need to create another daemon that provides the same API, and the API is documented and open.
further, that it seems to try encapsulating more and more.
It isn’t systemd itself that encapsulates more and more. All those are independent daemons that are part of the systemd package and source tarball.
These seem like real issues according to this: http://ewontfix.com/14/ (read both ‘reasons’ and ‘possible counter arguments’)
I know that page.
But just because something is written there doesn’t make it true and valid.
At least some of the arguments do read like FUD to me.
But then, I’m not really in a position to judge that either.
Although I am wondering why they (he?) didn’t write their own init system already, if they know it all better…:\
The point is, we have systemd as only supported option in openSUSE (and most other Linux distributions). Unless somebody steps up in supporting sysvinit or another alternative (and that doesn’t just mean to package it) that’s what we have to use.
I know that page.
But just because something is written there doesn’t make it true and valid.
At least some of the arguments do read like FUD to me.
Fair enough, but related arguments are put forward elsewhere.
Have you read the discussion glistwan pointed to?
It was (is) interesting to read, and instructive (to me).
There are alternatives, but somebody has to develop/maintain them. And that’s not systemd’s or systemd’s developers’ job.
Such as it is not systemd’s business to support/provide system services for those other init systems.
And even that API “lock-in” that’s mentioned on the page you link to isn’t really an issue, as the communication runs over DBUS anyway. You just need to create another daemon that provides the same API, and the API is documented and open.
I agree that this isn’t the concern of systemd devs. The problem with too much being tied to systemd, though, seems to be considered a real issue by many participators of this dispute; and I think it’s their concern to make arguments against it heard. Not all development is good, history has certainly (tried, at least) to tell us that.
Also, consider the two ‘mantras’ (my first post), (don’t know if they should be regarded as such but see them all the time though, and they make sense).
Skype, to name an example, now is more or less impossible to use without PulseAudio. PA is, in my opinion, more or less pointless; it works fine as a solution I suppose, I don’t mean to dismiss it as such, the point is that it does not add anything which one didn’t have before and is, therefore, merely an ‘empty required layer’; yet it prevails, make constraints and has impact on future development (skype +++)… For me, PA is just an obstacle which gets in my way (I learnt a new English word: tautology).
Just an association!
On 2015-05-19 15:16, F Sauce wrote:
> Skype, to name an example, now is more or less impossible to use without
> PulseAudio. PA is, in my opinion, more or less pointless; it works fine
> as a solution I suppose, I don’t mean to dismiss it as such, the point
> is that it does not add anything which one didn’t have before and is,
No, that is not true.
On my previous computer, before pulseaudio, an application could
monopolize sound so that no other application could use it. Say, view a
video in youtube, let it finish, then try to listen to an mp3, and it
would not work, because the youtube window was still open.
pulseaudio allows sharing of audio, even when the hardware does not
support it.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2015-05-19 12:06, wolfi323 wrote:
>> reboots after upgrades (servers?),
> That’s nonsense. You only need to restart the updated services, exactly
> the same as with sysvinit.
> You can even restart systemd itself in the running system, with
> “systemctl reexec”.
Doesn’t work for me.
When there is an update to systemd, that command reported success, but
“zypper ps” did not (ie, systemd processes were still using the old
version). On other occasions, even reboot crashed.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Hi Carlos.
No, I meant, Skype is built around PA now, you may choose to use an older version of it however. There is also a project working on an adaptability layer for PA dependable packages; it will enable e.g. Skype to run without having PA installed, but that is not for most people I guess.
Sorry, I misread.
Well if you couldn’t have multiple sound sources playing simultaneously, PA is of course useful as one possible solution for providing that. This should be really rare these days though, personally I have only experienced this once back in 2004 with SuSE 9.1, on an old Dell.
Olav
Personally I like pulseaudio. I had a lot of problems with it with the first releases shipped with openSUSE but for some time it has been rock solid for me. PulseAudio volume controll kicks ass and I guess it wouldn’t be possible without pulseaudio. Also switching between HDMI and standard speakers outputs is very easy with pulseaudio and never worked for me as expected before pulseaudio was introduced.
Glad you like it. Seems like many people do:)
As I do audio work PA would come in the way if I had used it. It seems like a good solution I guess, however, what I can’t understand is why making this solution an «absolute necessity» (gnome); there is no need for it as ALSA, by itself, provides what seems to be the most advertised benefit by using PA, namely having multiple sound-source capabilities (dmix). So, in my view, this has been a faulty development. PA might well be the best ‘audio/sound-server’ alternative for a DE, however that should still not put it in the position to dictate the future.
Linux has always seemed to me like a much more ‘close to the roots’ experience than the alternatives (which has been to my liking); with PA, and to a even more vital extent the systemd, this seems to me to be undermined harshly.
This is merely my current impression of the development though:)
On 2015-05-19 16:36, F Sauce wrote:
> No, I meant, Skype is built around PA now, you may choose to use an
> older version of it however. There is also a project working on an
> adaptability layer for PA dependable packages; it will enable e.g. Skype
> to run without having PA installed, but that is not for most people I
> guess.
Well…
Likewise, I had problems with some voip (opensource) software that was
incompatible with pulseaudio. It is a pain when projects choose for an
alternative that is not the one you happen to use.
>
> Sorry, I misread.
> Well if you couldn’t have multiple sound sources playing simultaneously
> without PA, PA is of course useful as one possible solution for
> providing that. This should be really rare now though, I personally have
> only experienced this onece back in 2004 with SuSE 9.1, on an old Dell.
I had that problem for years on several machines. The sound system could
only have one application using it.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
OK, but ALSA should be able to provide that also (been many years since this was introduced), i.e. the most basic audio related software which is needed in any case.
But I can understand that configuring it manually, when automatic set-up does not work, is something one often wish to avoid; setting up .asoundrc is something I find difficult.
Likewise, I had problems with some voip (opensource) software that was
incompatible with pulseaudio. It is a pain when projects choose for an
alternative that is not the one you happen to use.
But as I see it, this is a bit wrongly put; basically your alternative is the same as mine but extended with an extra layer (which may ease the use of …).
Forcing everyone (in the end?) to have to adapt to and consider this layer which isn’t vital at all, is the wrong direction in my view.
On 2015-05-20 11:16, F Sauce wrote:
>
>> Likewise, I had problems with some voip (opensource) software that was
>> incompatible with pulseaudio. It is a pain when projects choose for an
>> alternative that is not the one you happen to use.
>>
>>
>
> But as I see it, this is a bit wrongly put; basically your alternative
> is the same as mine but extended with an extra layer (which may ease the
> use of …).
> Forcing everyone (in the end?) to have to adapt to and consider this
> layer which isn’t vital at all, is the wrong direction in my view.
Same as forcing people using PA to use Alsa instead 
I mean, there are applications that only support Alsa, and others that
only support PulseAudio. That is wrong. It alienates one or the other group.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
No no, if you use PA you also use ALSA (or OSS I might add).
But it’s no big deal, I never meant to say that PA isn’t useful:)
http://upload.wikimedia.org/wikipedia/commons/0/00/Pulseaudio-diagram.svg
On 2015-05-20 17:16, F Sauce wrote:
>
> No no, if you use PA you also use ALSA.
Well, yes, it is there. But PA holds and owns the sound devices, so that
applications that only support Alsa refuse to work.
What I’m saying is that applications should support both methods.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Yes, ALSA holds the sound device drivers, not PA. PA wouldn’t work without ALSA (or OSS).
What I’m saying is that applications should support both methods.
Agree, have packages build against gstreamer or xine should do the trick I suppose, thereafter you could just throw away PA:O
I’m no developer though so I can’t really tell, there are probably lots of concerns I’m unaware of.
On 2015-05-20 21:26, F Sauce wrote:
>
> Yes, ALSA holds the sound device drivers, not PA. PA wouldn’t work
> without ALSA (or OSS).
Sigh. You don’t understand.
When PA is running it opens the devices that Alsa provides, exclusively,
so that nobody else is able to open the same devices.
Thus an application without PA support, that wants to open the Alsa
provided devices, can not work while PA is running.
Thus, an application with only Alsa support can not run on a system that
has Pulse running. Which is similar to the fact that an application with
only Pulse support (skype) can not run on a system where Pulse doesn’t run.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)