Systemd 227 Released: "Lots Of New Awesomeness"

[timtas]

Lets see ... It appears to me that you say it makes sense to degrade software functionality on the system it was originally written for just to be able to run software on other systems that someone/most people don't care for? I don't know if you are a gamer, but recently, Rockstar Games degraded GTA San Andreas functionality and preformance on PC so it matches its android equivalent. Can you guess the outcome? Another example is AMD's CCC, which is way different and degraded on linux compared to its windows equivalent.

If you had to choose between portability and preformance/easier way of doing things, which one would you choose?

I might not be representative, but I had to write portable software in my professional IT career almost from the day on I started, and still have to. So it's just deep inside me to always first look for a portable way of doing stuff. Only if that's not possible or comes at a high performance penalty, I will look at the system/compiler specific stuff and write some wrapper stuff to get at least source code portability at the higher levels in my program.

So generally, I choose the more difficult way. And yes, that sometimes includes #ifdef _LINUX_ | #ifdef _WINDOWS_ #ifdef _SOLARIS_ and so on. Get me flamed.

[kaprikawn]

But Red Hat don't care about anything other than Linux because they're a Linux company. It's open source so if FreeBSD et al want to implement it then they can, but they don't want to which is fair enough. I don't see anything wrong with it being Linux-specific.

[justmy2cents]

Is that not exactly the same way util-linux is packaged?
Just like systemd it is a collection of dozens of binaries that come together in a single package.
Yet nobody bats an eye about util-linux being monolithic.

Heck, by any standard, the linux kernel is a lot more monolithic than systemd and everyone is ok with that.

there are double standards people have when systemd is considered

and a little newsflash it is not "lot more" monolithic. IT IS monolithic, period

[Nobu]

Excellent post timtas. The problem with systemd is journald. I've been running arch Linux for 11 years. After arch implemented systemd a few years ago, if my system encountered minor errors such as in web surfing, journald would despotically take over my machine with 100% cpu generating massive files of useless (to me as a user) data. Why the hell would I want my system to behave like that? It's like I was transported back in time 10 years to Windows 95. And as a user I'm supposed to edit the journald config file as a ploy to make it behave? Give me a break. Can anyone recommend how to simply disable journald?

*uses ArchLinux, complains about editing configuration*

As the primary user (and probably the one who installed the OS), you are a system admin, whether you like it or not. If you aren't the admin, let the admin handle it.

As far as disabling it, see the man pages for systemd-journald.service, journald.conf, and the ArchLinux wiki for systemd. I'm pretty sure it's as simple as:
systemctl disable systemd-journald.service
systemctl stop systemd-journald.service
systemctl start <yourloggerhere>.service
systemctl enable <yourloggerhere>.service
(Edit: you may have to disable the associated socket files, too. method is the same)

systemd and company has lots of documentation, all of it in man pages and online. Use it.

[justmy2cents]

I might not be representative, but I had to write portable software in my professional IT career almost from the day on I started, and still have to. So it's just deep inside me to always first look for a portable way of doing stuff. Only if that's not possible or comes at a high performance penalty, I will look at the system/compiler specific stuff and write some wrapper stuff to get at least source code portability at the higher levels in my program.

So generally, I choose the more difficult way. And yes, that sometimes includes #ifdef _LINUX_ | #ifdef _WINDOWS_ #ifdef _SOLARIS_ and so on. Get me flamed.

the comment you answered to and your statement are not even remotely connected. just take containers as example. complex feature being handled differently on each OS. it is almost impossible to write same code with #ifdef and take advantage of everything each solution offers unless... bad things happen

just example. if you wanted to create some URI api that would handle file paths consistently across OSes, #ifdef will serve you fine as you don't need to sacrifice any functionality. but, when you have something more complex init which needs to touch OS innards like cgroups, kernel namespaces, udev... starts taking least common denominator approach, that is bad since you went with solution that works on lowest functionality.

the taking full advantage of linux is one of initial design decisions of systemd

here you might argue that you can cover everything for everything with #ifdef too, which is true. problem you're missing is how convoluted everything now is since your code is mostly split in large #ifdef parts leading to bad code

might as well completely separate all platform code and make it maintainable... which brings another problem that clashes with second goal for systemd. you will be much slower at implementing new things since you will require more than one in lot of cases. and systemd is linux specific mainly so it can evolve for linux as fast as possible

[justmy2cents]

I might be wrong but from what I've heard, systemd unconditionally relies on cgroups, which is linux-only. It also relies on glibc specific printf extensions and any patches to make that conditional for other libcs were refused. Might have changed in the meantime, but I recall that LP always clearly stated that he does not care one bit about portability. That's totally his decision and has to be respected. As is mine, I think, to not like that.

yet, main thing is that everything outside specific module should never touch it directly but rather over dbus interface. and that one doesn't touch cgroups. this makes it possible that other OS would expose same interfaces and use its own prefered internals while systemd tools would just work and work best possible on that OS

[pal666]

So generally, I choose the more difficult way. And yes, that sometimes includes #ifdef _LINUX_ | #ifdef _WINDOWS_ #ifdef _SOLARIS_ and so on.

so you have written some shitty software in the past. that's ok. just don't insist that everyone should repeat your mistakes

[timtas]

so you have written some shitty software in the past. that's ok. just don't insist that everyone should repeat your mistakes

You'd be surprised how many programs have #ifdefs in their header files and in some low-level routines. But explaining this to you is a waste of time, as you generally seem to have no clue about writing software.

[unixfan2001]

You'd be surprised how many programs have #ifdefs in their header files and in some low-level routines. But explaining this to you is a waste of time, as you generally seem to have no clue about writing software.

Now I know #ifdefs can't be avoided completely in the development of complex software and are generally preferred in cases of small platform differences. However, have you ever considered laying your code out more modularly?
Generally, it's considered good practice to put the platform specific stuff in separate headers.

[bkor]

You'd be surprised how many programs have #ifdefs in their header files and in some low-level routines. But explaining this to you is a waste of time, as you generally seem to have no clue about writing software.

Could you respond again in practice explaining how to do an #ifdef for features not available on other platforms? And what's the point exactly? Systemd developers should be portable, because.. why? *BSD isn't going to use something so low level while it is licensed as BSD. Also, it would be nice to get an actual response!