systemd 250 Released With A Huge Number Of New Features, Improvements

[oiaohm]

I did see that, of course. I didn't want the service to go into failed state, as that created other issues. The service isn't standalone.

Sorry no. This is one of these problems. Was the service in a failed state because it could not start with X hardware the answer is truthfully yes.

Setting up service system that all services are reporting their true and correct state at times is not straight forwards and would be helpful if systemd included better documentation on using targets and barrier solution.

Lot of ways the ExecCondition not existing just required deeper knowledge of systemd to solve problem. ExecCodition did not add a feature you could not do with a few more pieces with systemd.

Yes targets are fun they they can be marked as started even that the services inside are failed and if target is stopped all services running inside target stop as well.

So basically 2 files prior ExecCondition existing and you could generate the same effect as ExecCondition does. Except when you look at the service list the failed service is clearly displayed in the prior to ExecCondition.

The level of truthfulness the early systemd design expects lot of users seam not to be able to tolerate and the concept of having to use more than 1 file at times. You find this with a lot of claimed things that systemd could not do well. Yes a lot of the early systemd problem is the mandatory truth state reporting and people not understanding what early systemd expected done in cases that truthful state was a issue. This is a case that systemd documentation is as clear as mud on how to handle these problems not that systemd itself cannot do them well.

[intelfx]

Try independently upgrading/downgrading them and you'll see exactly how independent they really are.

That's not a problem at all. It's only as much of a problem as your distribution makes it. Build static binaries, package them separately, copy them over to the target system, bam, job done.

In other words: yes, they really are independent.

[coder]

That's not a problem at all. It's only as much of a problem as your distribution makes it. Build static binaries, package them separately, copy them over to the target system, bam, job done.

Oops, no! Your distro cannot do that, because libsystemd is licensed under LGPL. That means it must be distributed as a shared library! Of course, if you want to build them that way, there's nothing stopping you. However, now you're using an untested build & configuration.

In other words: yes, they really are independent.

When you actually try that, with a mixed set of releases, let us know how it works out for you.

[intelfx]

Oops, no! Your distro cannot do that, because libsystemd is licensed under LGPL. That means it must be distributed as a shared library!

No, that is absolutely incorrect.

When you actually try that, with a mixed set of releases, let us know how it works out for you.

It works well enough, thanks for asking.

[coder]

No, that is absolutely incorrect.

The header files I'm looking at say it's LGPL. Do you think they're wrong?

[oiaohm]

Oops, no! Your distro cannot do that, because libsystemd is licensed under LGPL. That means it must be distributed as a shared library! Of course, if you want to build them that way, there's nothing stopping you. However, now you're using an untested build & configuration.

This is not true. Remember SDL is also LGPL.
https://github.com/libsdl-org/SDL/bl...ADME-dynapi.md
If someone was willing to put in the effort the static linked libsystemd could include dynapi from SDL. So providing a solve to the static link problem for third party code that is not LGPL..

LGPL just states you have to provide user with what is required to replace it so if you provide the complier you used if it a closed source one so user can build their own systemd and the systemd source and you have statically linked you are legally in the right as well.

LGPL does not forbid static linking. But does mandate you provide enough user can remake the executable/library with updated parts. Since the complete systemd project is LGPL all parts have to be replaceable. So there is no real difference here using part of systemd static linked or systemd dynamic linked since either way you have to provide what was the source code you used and the means to remake it..

When you actually try that, with a mixed set of releases, let us know how it works out for you.

Sorry to say there is more than one embedded firmware Linux that static links systemd then use parts from multi versions functionally systemd works fine at runtime so this is not the headache. The headache is legal because this normally leads to the developers of the emded firmware not doing their source code declaration right this has lead to many legal departments forbidding this as more a counter to incompetence than that it not function and that it cannot be done legally.

Yes some parties have managed to static link systemd and use multi versions in a project and get the source code declare right for legal so its possible. Just because something is possible does not make it ideal.

Lot cases static linking multi versions of systemd and using them with each other is just adding extra complexity on the legal side to avoid having to upstream a bug fixed that end up fixed in future versions of systemd. Yes that internal fix that has not been up-streamed normally turns out to be a poorly coded and flawed as well.

coder the documentation issue you have referred to with the libsystemd API means you also are missing the information to test case correctly at times when doing third party patches without going back to upstream. So this kind explains party where the poorly coded bit comes from.

Yes I can also understand where working in particular companies you will have a miss understanding about LGPL. Yes there is a lot of companies that mandate that if something is LGPL that it must be dynamically linked just to prevent developer incompetence opening up a legal rabbit hole. Yes static linking LGPL a totally legally navigable rabbit hole if you do the right things but some companies legal departments don't trust their developers todo the right things or don't care about doing the legally right thing. Yes most of the examples of mixed version systemd static linked are from companies that don't care about doing the legally right thing they just want their product out the door and on the shelf selling and they kind get up set when their products start being stopped by customs for copyright infringement.

Fun part about china you can attempt to protect copyright by courts(and waste a lot of time) or you can just go straight to china customs and make your case that will normally get the issue resolved in 24 hour for in face error like not providing source to LGPL/GPL works that you are a developer of. Please note a china customs does not just enforce on goods going overseas they have the power to enforce on products going Province to Province inside china. So you can cause a headache for the company on the scale of hell they never want to see that again because by the 72 hours going the custom route all shipments by the company who broke the rules has been stopped for deeper investigation. Yes this supply line breakages that make covid disruption look lime minor problem and this is going to leave a majorly bad taste in mouth leading way extra due care.

[intelfx]

The header files I'm looking at say it's LGPL. Do you think they're wrong?

No, I think your conclusion is wrong.

oiaohm is spot on with his explanation, as usual.

[smitty3268]

That means it must be distributed as a shared library!

If that were true, your objections about systemd gobbling up other projects would make a lot more sense. But it's not.

[coder]

This is not true. Remember SDL is also LGPL.
https://github.com/libsdl-org/SDL/bl...ADME-dynapi.md
If someone was willing to put in the effort the static linked libsystemd could include dynapi from SDL. So providing a solve to the static link problem for third party code that is not LGPL..

And does libsystemd include this jump table mechanism to defeat static linking? No? Then your point is moot unless/until it does.

LGPL just states you have to provide user with what is required to replace it so if you provide the complier you used if it a closed source one so user can build their own systemd and the systemd source and you have statically linked you are legally in the right as well.

LGPL does not forbid static linking. But does mandate you provide enough user can remake the executable/library with updated parts. Since the complete systemd project is LGPL all parts have to be replaceable. So there is no real difference here using part of systemd static linked or systemd dynamic linked since either way you have to provide what was the source code you used and the means to remake it..

Unless your distro is like Gentoo, where the packages are the source code (or at least always include it), I think you still can't get away with static linking it.

Sorry to say there is more than one embedded firmware Linux that static links systemd then use parts from multi versions functionally systemd works fine at runtime so this is not the headache. The headache is legal because this normally leads to the developers of the emded firmware not doing their source code declaration right this has lead to many legal departments forbidding this as more a counter to incompetence than that it not function and that it cannot be done legally.

Yes some parties have managed to static link systemd and use multi versions in a project and get the source code declare right for legal so its possible. Just because something is possible does not make it ideal.

First, if you know of specific examples, feel free to cite them. I'm skeptical of how well systemd truly supports interop with services from different versions.

Second, just because some people break the spirit and letter of LGPL doesn't invalidate LGPL for everyone. The library is LGPL. They made it so for reasons. They had other licensing options, but opted for LGPL. So, to think the maintainers don't care if distros statically-link it seems unlikely, as does the idea that other distros would blatantly flout LGPL on a major library like libsystemd.

[coder]

No, I think your conclusion is wrong.

WTF? No, your ignorance of GPL/LPGL is simply shocking.

oiaohm is spot on with his explanation, as usual.

oiaohm argues on here for sport. Half the time, I think that poster doesn't even believe the BS they're spouting.