Systemd 243 Is Getting Buttoned Up For Release With New Features & Fixes

[F.Ultra]

Without ever using it, that description makes it sound just awful.

For those interested: https://docs.oracle.com/cd/E36784_01...html#scrolltoc

[aht0]

SMF is like combining the syntax of Power Shell with unit files written in XML. Complaining that systemd is complex while claiming that SMF is easy is disingenuous. I take it that you haven't written any unit files for SMF and systemd and thus really compared the two.

And both PowerShell (very powerful win tool in itself actually) and XML are widely used in IT. Your point?

For home users, neither matters much, because basic service management is no worse than that of Linux or BSD, just issue set of CLI commands - with the added bonus that SMF actually works as expected. How often home users have to write service files, not that XML itself is some sort of Japanese Kanji script..

It's basically a matter of perspective, attitude and set of values. Do you value your time? Wanna spend days debugging some particular systemd issue.. yet again? "Filter out"/find-configure replacement for some (set of) systemd component(s) that does/are not work(ing) as expected? Or just learn one set of tools that works and go on with using that.

Simple user POV - have a service management system that works, does not present you daily/weekly with random issues preventing the proper use of computer. Because, if you are just a USER, systemd capabilities are moot point, you arent using it's abilities beyond what's configured by distributor BUT yo do get to be part all of it's fuckin issues..

And as I noted, there are always distros without systemd and BSD, when SMF remains too tough a nut. It was just an offering an option, afterall.

[skeevy420]

And both PowerShell (very powerful win tool in itself actually) and XML are widely used in IT. Your point?

For home users, neither matters much, because basic service management is no worse than that of Linux or BSD, just issue set of CLI commands - with the added bonus that SMF actually works as expected. How often home users have to write service files, not that XML itself is some sort of Japanese Kanji script..

Myself....three in the past 5 or 6 years that I can remember (and I had to Google how to do it each time). One was to set governor settings and whatnot from a bash script, covered by GameMode now; one was to mount some ZFS drives and just isn't needed anymore; one was to import my WattmanGTK settings during boot and I still use that one.

While I made that "had to Google" comment, it really isn't any different than having to search for sed cheat sheets or obscure bash commands like in the days before systemd so I'm not counting that as a negative.

[aht0]

Myself....three in the past 5 or 6 years that I can remember (and I had to Google how to do it each time). One was to set governor settings and whatnot from a bash script, covered by GameMode now; one was to mount some ZFS drives and just isn't needed anymore; one was to import my WattmanGTK settings during boot and I still use that one.

While I made that "had to Google" comment, it really isn't any different than having to search for sed cheat sheets or obscure bash commands like in the days before systemd so I'm not counting that as a negative.

Judging from your example, you are neither simple user nor should assume non-Linux OS'es follow the same ideas. Governors could be manipulated completely different ways in other systems.

For simple user, service files are prepared in advance by software porters - install something, bang, you should have them ready. All you'd have left to do is to use service management commands.

Besides, even when you just HAVE to for some unfathomable reason to fuck around with writing service configuration files, init sripts and what not, in BSD family and Solaris too, it's kinda more stress free. No convoluted crosslinking between runlevels - because there are no runlevels to begin with in BSD's - RC init scripts are far simpler and little Solaris XML following set of examples ain't exactly neck breaking either.

Yes, it does not compare with text-format unit files in systemd and systemd would be more productive - but it only applies when that systemd actually agrees to fuckin' work without some obscure problem cropping up. When it does - however much complicated or "weird" or 'less efficient' may BSD/Solaris init/service management be, when it works, you have saved time. Because "the other guy" is still debugging his systemd problems 2 days later. And then perhaps, after having figured it out on 3rd day, has to figure it out again n amount of system updates later - because with non-Enterprise Linux - something is always liable to break.

[intelfx]

this one is about systemd releasing a patch to fix their software not booting on the latest AMD processors

Correction: *releasing a patch to make their software work around buggy and noncompliant hardware that are the latest AMD processors.