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

[coder]

If that were true,

And on what basis do you claim it's not? Frankly, I'm amazed so many on here seem to know so little about LGPL. I mean, if you're not a developer or packager, then I guess I could understand not caring so much about the finer points between the licenses.

The reason LGPL effectively mandates dynamic linking is that Stallman wanted downstream users of software to be able to modify & rebuild any LGPL libraries it uses. That way, even when it's used by closed-source programs, you can at least fix bugs and add features to the library portion.

Sure, you can add some jump-table mechanism like what oiaohm quoted, to defeat people who just go ahead and static link the library, anyway. That's perhaps more effective than just telling them not to, via the license. However, if they know what they're doing, they could probably break the jump table without too much trouble. And then we're back to square 1.

your objections about systemd gobbling up other projects would make a lot more sense.

It's actually not central to my point, but a notable inconvenience for anyone who even wants to try mixing versions. Even if you rebuild everything to statically link its own libsystemd, I don't trust the interfaces between services to be stable enough that I'd take the risk.

The bigger point is that by having systemd eat so many other userspace facilities, it limits the options of users who have some issue with one or more of its features. Whereas before, you might swap in an alternate service that's a better fit for your particular situation, the systemd approach means everyone has to try and patch it to work well enough for their needs, and that just bloats it with a bunch of niche features that are poorly understood and not well-tested.

[intelfx]

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

How about I say the same to you?

You can start reading here: https://www.gnu.org/licenses/gpl-faq...taticVsDynamic

[coder]

How about I say the same to you?

You can start reading here: https://www.gnu.org/licenses/gpl-faq...taticVsDynamic

Have you ever seen a distro package include object files for an executable? I haven't. And if not, that says they can't use static linking.

[oiaohm]

Have you ever seen a distro package include object files for an executable? I haven't. And if not, that says they can't use static linking.

Yes you have with Nvidia kernel module binary blob. This behavour is rare outside embedded device firmware with Linux as Nvidia binary blob as your only common example. There are many ways to legally screw up doing this and embedded vendors have done them all.

https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic

If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

LGPL you must provide the sources. Systemd as a complete item is LGPL 2.0 or latter . That is for GPL v 3.0

There is a reason why Systemd is LGPL v2.0 or latter.

https://www.gnu.org/licenses/lgpl-3.0.html

4. Combined Works.

d) Do one of the following:

• 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
• 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

Yes I know this is LGPL v3.0 not LGPLv 2.0 but LGPL v3.0 is more human readable and systemd is LGPL 2.0 or latter.so you can use 3.0 terms but lot of embedded will not. In reality the both wordings in this area of GPL are close to each other but not quite. Section d 1 in GPL 3.0 has been extended the old LGPL 2.0 does not mandate the copy is run time provided by the OS. Older SDL is under LGPL 2.1 as well the link table replacement if you have implemented that to allow library replacement you turn out to meet LGPL2.0/2.1 requirements this is why LGPL 3.0 has stricter defines on what is acceptable dynamic linking.

The reality here most public distributions in fact do both 0 and 1 of LGPL 3.0. Do note you are only required to do 0 or 1 not both. If you have done 0 with LGPLv3.0 and LGPLv2.0 equal it does not care if you have statically linked or dynamically linked.

Please note words are important. "Corresponding Application Code" notice that is code not source. Code=allows to be binary. So like Nvidia binary blob. Not that you have to. If you want to provide corresponding Application Code as source code that is allows as well and if you provide the source code you don't need to provide the binary blob object files..

https://www.gnu.org/licenses/gpl-3.0.html

6. Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

• a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
• b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
• c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
• d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
• e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.

Yes this is the section 6 referenced in section LGPL 3.0 d0.

coder all my examples of people using multi systemd mixed with each other are from embedded companies who are doing or were doing the wrong things legally so don't want to give them free advertisement. When I say wrong things as in not distributing the source at all and having to be legally beaten over the head by china customs(being china customs could be really beaten over their head). Yes this normally goes they release all the required declares to fix the legal mess then fairly quickly release a new firmware image with update systemd back to a single version because newer version of systemd had fixed their problem and makes their meeting LGPL/GPL... requirements simpler. Yes these companies have per product on average are in breach of about 50 software projects licenses at a time that not covering the duplication declares causes by franken monsters.

Yes the problem with using multi versions of systemd in a single product(embedded) is not that it does not work it makes doing section GPLv 3.0 section 6 equals in LGPL 2.0 more text with more possibility of illegal typo due to not correctly declaring all the "Corresponding Sources". Yes each version used has to be individually declared and what part is what version.

So its not that you cannot use part from systemd from different version with each other. Its if you choose use use multi versions of systemd with each other it turns into a pain in ass legally. So companies would try to force you away from doing this unless there is no other choice.

Coder yes you have jumped to the wrong idea. If systemd mixed versions would not work you would not find them in embedded medical devices and other areas requiring high stability. Why not use multi versions of systemd with each other is more legal risk issues than technical issue. Yes with ultra due care legally you can legally do multi versions of systemd in a project so different bits of systemd come from different versions of systemd. This is the reality why do the headache.

Also lot of distribution maintainers don't want to have to deal with the headaches they had back in sysvinit time frame. Where you had people using different init systems submitting bug reports against the different parts at times with conflicting requests. As in please alter X so Y init system works then Z init system please undo X because you it broke Z init system yes this happened a lot. Modular Init system idea has some serous issues. So simplest way for distribution maintainers to avoid this problem don't make systemd package that modular even that by design at the source level it is modular.

Coder you have ignored distribution maintainers role here and presumed everything is systemd project doing. Embedded developers every time they have gone looking they have found that systemd is highly modular yet that packages you get from major distributions the maintainers are deciding not to make systemd that way to avoid a set of headaches they use to have to put up with.

[gotar]

I don't know enough of the specifics to comment about any of those, but there are plenty of examples where competition likely yielded better results on both sides. For instance, gcc vs. clang or mysql vs. postgressql.

What competition between MySQL vs PostgreSQL are you talking about? Until Oracle released MySQL 8.0 this was not even the fully-compliant RDBMS (in ACID terms), so they didn't play in the same league, PSQL was the database, while MySQL was something like SQL wrapper for CSV files (now you can run with ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_ DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AU TO_CREATE_USER,NO_ENGINE_SUBSTITUTION,NO_AUTO_VALU E_ON_ZERO,STRICT_ALL_TABLES etc. ...which shows how much was broken before). It took Oracle, The Database Creators and Rulers, to fix MySQL, I doubt it has anything to do with PSQL. Give me one example of either of these gaining anything from the "competition".

That's more of a change in the filesystems, themselves. No?

No, it's a pretty common situation with 1000+days uptimes when you simply don't remember your boot procedure.

$ uptime
22:31:56 up 1761 days, 22:57, 134 users, load average: 0.29, 0.29, 0.24

There were certain advantages from having SYS-V Init utilize shell scripts that now require more point-solutions for systemd to support the same range of capabilities. I tripped over one of these issues, not too long ago.

There was none. You can still use the same (s)hell in systemd. Just remove the native unit, which is masking the SysV fallback.

One specific example I saw was systemd leaking dbus connections. I think we found that during soak testing before a release, and had to upgrade to a newer release of systemd to get the fix, which was more risk than we wanted to take on. I wasn't directly involved in that one.

I asked you for a few examples, of "separate, standalone projects" that were suffocated by systemd and the negative impact on end-users. Not about some bugs or show-stoppers, that happen all the time in every software.

I never said it wasn't an improvement. However, we also shouldn't assume we'd still be using SYS-V Init, if it hadn't won out. Whether it was Upstart or something else that came along, whatever had entered that niche would've been the subject of a lot of the improvements that have since gone into systemd.

I think you don't understand the fact, that systemd was the winner not because some evil people wanted to or to make you angry, but because other project established the baseline and discovered the dead ends. Upstart was very precious because we've learned things to avoid and other shortcomings. Next generation of it, with "a lot of improvements", is systemd. Would you prefer for it to be named "upstart-ng"? What difference would that make? And no, upstart couldn't be fixed in small steps, because it turned out that entirely different architecture is needed.
Ranting about systemd seems like boycotting cars because "we could have had faster horses". Go on, make them faster. Who knows, maybe some day...

[gotar]

Devices are likely to report the correct information, and will tend to do a better job of staying up-to-date than a bolt-on DB.

ROFTL. Ever heard about ACPI? No quirks required, huh?

[gotar]

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

First of all - I did that many times. In fact, I got the mixed version right now on my laptop and a bunch of servers. I do --nodeps --force all the time on my development machines, I ignore package-provided requirements on purpose just to find bugs on daily basis. I remember having multiple versions of systemd-libs that were clashing into same binary, but please don't tell me this is harder than during the old days.

Sometimes, they even go too far, like I'm really not wild about homed - although, because I don't know much about it beyond what I've skimmed from a few articles on this site, I'm withholding final judgement until I have some firsthand experience with it.

Second - why would I upgrade/downgrade things I don't use? I don't know the homed as I don't need it. Already said that - I don't use most of the systemd tools. The fact that I can ignore them is the best proof that they are independent. I don't need them, I don't use them. With the exception of journald which is a must-have and breaks some of my tools.
What's the regular-user point of upgrading systemd without udev or networkd or keeping journald out of sync?

But, any newer replacement for the old init scripts would probably be better in a lot of ways.

Yet almost nobody took the effort to follow. Maybe the added value was too low?

Especially as it matured to the point systemd is now at.

That's the same as with electricity - too bad mankind discovered it, without it sucking the engineers for decades we would be harvesting "vacuum energy" till now
No, none of the "any newer replacements" had potential to became systemd-alternative and feature-competitor, because non of them got even close. And to be clear - by "potential" I mean both the good architecture and programmers willing to step in and forge the code. Maybe there were some brilliant init system written in whitespace, who knows!

I remember writing complex rules in sendmail.cf 20+ years ago. Great language, huge potential... still I do prefer postfix configs.

Okay, I'll give you an example. I have a service that only runs on certain hardware. It uses a 3rd party library that fails in some pre-main() code, if the hardware isn't present. So, I really can't even afford to start it, on an incompatible system. Back in the days of init scripts, I could insert that check directly in my script and use it to conditionally run the service when the start command is given. In the land of systemd, it wants that service running when asked. This became very annoying to work around, until systemd finally added the ExecCondition feature.

No, you can simply use the old-style script. This is one of the main reasons this init was adopted so fast. It was expected to be drop-in replacement. Of course, some SysV scripts required some minor fixes, mostly due to wrong LSB headers, but this is not a PITA like replacing entire bootup procedure at once.
Anyone forcing you to use systemd native units?
Besides, you could use your old-style start() as separate script used in service unit.

Otherwise, we see a downside to getting rid of the old init scripts.

No, we don't. I still got dozens of SysV scripts hanging around. They don't bother me! They do work. Use the compat mode, Luke

[gotar]

The bigger point is that by having systemd eat so many other userspace facilities

Once again as you didn't answer last time - which one? "ConsoleKit? PolicyKit? hotplug? devfs? TCP wrappers? utempter? *inetd?"

[jacob]

Okay, so all of your product reviews are either 1 star or 5 stars? I guess Amazon really messed up, when they gave people the option to rate 2, 3, or 4 stars. Maybe you should tell them.

Again with the "fix it or shut up" fallacy, which is a false dichotomy.

There is a difference between reviewing something and making demands. Claiming "you must change your goals and your development model because I say so, and by the way I don't care if it has worked well for many more satisfied users and I'm not offering any help" is not providing a review. No fallacy here.

Whether you choose to use the word "haters", you're drawing a bright line that doesn't exist in reality. There's a spectrum of how people feel about systemd, and it's only loosely correlated with whether they actually use it.

I would say those people that don't use systemd by definition don't matter to the systemd project. I don't use BSD and am not interested in it, so very logically and obviously no-one within the BSD community should give a damn about what I think about it, yet alone listen if I (hypothetically) started lecturing them about what they "need" to do.

Which brings us back to the notion of entitlement: some people don't use systemd, yet they are absolutely convinced that they are "right", that their opinion should matter (and override the contrary views) and that they should be held relevant, preferably with deference. Why exactly? Take it and shut up, provide patches upstream and shut up, fork it and shut up, use another OS/distro and shut up, or simply shut up.

I'm starting to wonder if the pro-systemd community doesn't have a significant percentage of irrational, pathological lovers.

I have yet to see someone from the pro-systemd community propose to hire an assassin to kill anti-systemd people.

Defining an opposing side by its most extreme members betrays your true intentions. You never were here to have a fair-minded or thoughtful discussion about systemd. You're just spoiling for a fight, which explains why you seem virtually impervious to reason.


And who is actually saying that? It's one thing to criticize systemd do for being too monolithic and expansive, but I don't realistically think they'll change course because anyone thinks they should. It's just something we have to live with. That doesn't mean I'm not going to voice my dissent whenever systemd undergoes more scope creep.

Maybe it would be better to drop the hyperbola. "Dissent", really? We are talking about mere software, not political regimes. Other than that you just showed how much the discussion is either pointless, or to the contrary needs to be reinforced, because you are stuck with the "scope creep" mantra. It makes no sense, it's like saying that GNOME undergoes scope creep every time a new app uses its UI framework, or that Linux has scope creep every time it integrates a new feature or support for a new CPU, or that BSD has scope creep every time anyone implements anything on it. The "systemd is no longer just an init" cliche is tired but it has always been nonsense because systemd has always been intended as a general userland project (think coreutils on steroids). If the question is which system functions should systemd provide, the most accurate answer is All of them.

Huh? Ubuntu only went with systemd because Debian did. They already had their own alternative: Upstart. If Debian hadn't embraced systemd, Ubuntu would've continued developing that and maybe Debian would've even let them upstream it.

Actually it's the other way around. IIRC Ubuntu announced systemd some time January 2014 and shipped it in 15.04. Debian voted on its systemd GR in late 2014, that is after Ubuntu had already the switch in the works. Ubuntu wasn't motivated by Debian but by the fact that upstart objectively sucked.

This is another absurd position you clearly arrived at by working backward from your conclusion, and not at all true. Basically everyone who's invested any time or resources in learning or customizing systemd or what it replaced is a stake holder.

Do you consider yourself an Intel stake holder because you use CPUs they make?
Are you a stakeholder in GCC development just because sometimes you may use it to compile software?

Of course not. End users are not the same as stakeholders. To have a say in a project, i.e. to be a stakeholder, you must first acquire a legitimate stake in it through contributions, funding, earning the respect of the developers, etc.

You need to stop this "majoritarian" thinking (quotes used because you at least think you're in the majority). You don't have to engage with complaints, but everyone has just as much right to an opinion as you do. Telling them they don't is just bullying.

If you call majoritarian thinking bullying then I can call minoritarian thinking whining. As to what is really the majority, once again: compare developer bases, compare package maintainer bases, compare user bases. The anti-systemd community is loud but that doesn't mean it's big.

And who granted you the authority to judge such matters?

You do not get to control what other people think or say. You control only your own thoughts and actions. You need to understand this, and you clearly don't.

People have an absolute right to complain as much as they want. Whether it gets them anywhere is another matter, but that's not your problem.

To the contrary, this is kind of a central point. The anti-systemd people often and recurrently claim that systemd is not legitimate, was not asked for, was "forced" on them etc etc etc, all of which come from a worldview that implicitly assumes some sort of central authority. They can't accept the fact that no-one needed anyone-s authorisation to start developing systemd, no-one needed anyone's authorisation to contribute to it or to implement it, and the rest is simply a question of numbers.

I'll bet that's the very first thing they did! It's fortunate they were in a position to fork it and do the work themselves.

Which is how it has always worked. Linux, GNU, GNOME, KDE, Mesa etc. all work that way. There is no other way.

First, nobody ever said they had to listen to any of the complaints. That's up to them & Redhat, whether they want to take any of the criticisms on board.

Second, I don't think anything short of a fork or another project out-competing systemd has any chance of bending its trajectory. So, the task is well beyond the scope of what any individual can achieve.

The same is true for virtually anything. The Linux kernel as it stands today is not just far beyond the scope of any individual (including Linus himself), it's probably beyond the scope of any single organisation. Probably even Google or Microsoft with all their resources wouldn't be able to recreate it from scratch with the same performance and features.

Yes, old-style init was simple and within the scope of an individual, systemd isn't. What many people seem struggling with accepting is that it's not necessarily a sign of quality of init and bad design of systemd, it can very well be (and I personally am convinced that it actually is) the sign that init simply failed to realise the inherent, unavoidable complexity of the problem it *should* have tackled from the start. That was a constant source of never-ending problems. Apple came to the same realisation before systemd when they created launchd instead of sticking with BSD init.

Modularity forces well-specified and stable interfaces to be defined. That, in turn, supports better testing, since components can potentially be tested in isolation. Finally, when you can mix-and-match components, you avoid situations where a bug or limitation in one can hide a bug in the other.

Of course systemd components are first tested in isolation. But remember that unit testing is the easy part. Integration testing is where problems start. The traditional approach simply decides to pretend that those problems don't exist. The only result is that it lets the user tackle them instead. How is that supposed to be better?

Another major deficiency of the mix & match approach is that it does not constitute a viable *platform* that third party developers can expect to be there and provide certain known functions. That means that developing an app is more difficult and requires more effort than on an integrated platform, and the app is inherently less user friendly and basically can't "just work" as it should.

Arguing against modularity is another one of these counter-intuitive positions one can only arrive at by working backward from the current status quo.

Modularity is not magic solution; it's also not an end in itself and is never self-justified. It makes no sense to judge software based on whether or not it's modular or which definition of modularity it meets. What matters with software is performance, security and ease of use. In some cases, modularity works towards those goals, in some cases it hinders them. It works more or less well for shell commands. For kernel design it has proven to be a dead end. Etc.

Exactly what is that supposed to prove? Yes, it's widely used. So is the Linux kernel. That doesn't mean the Linux kernel is perfect or even above reproach.

No one says anything about Linux (or systemd) being perfect or above reproach. However, Linux is way better than anything other that we have, and in particular it has succeeded hilariously better than the "modular" alternative, Hurd.

Similarly, systemd has its flaws (interestingly, the actual, real technical issues are never mentioned by its detractors, like the fact that for some mysterious reason it doesn't support templating in mount units). But it's essentially the only game in town; the other two similarly capable systems (launchd and svchost) don't work on Linux. The rest - runit, openrc, s6 etc - are alternatives to each other but not to systemd since they don't address the same issues.

As for why each is quite so popular, there's a sort of critical mass that you hit, where anyone looking to be a player in the markets each dominates has no choice but to embrace them. Do you think Microsoft really wanted to embrace Linux? Look how long it took them to do it! They were literally the last ones on the bandwagon! Only Apple is still a holdout, and that's because they exist virtually in isolation from the rest of the computing world and manage to derive value by doing so.


Meaning if your preferred distro didn't embrace systemd, then the pro-systemd would feel disenfranchised by that decision.

For a while my preferred distro was Ubuntu and it didn't embrace systemd until several years after Fedora and some of the others. During that time it was upstart. People were bitching about upstart's problems, some were calling "fragmentation!" (never mind they are the same crowd who now start going on about alternatives! alternatives! the second someone says systemd). The Earth was still spinning.

Who appointed you as their spokesperson? I can't say that no one thinks that, but you're attributing a single position to a large group of people who surely have a diversity of views on the subject.


Ascribing an extreme view and then attacking it is called making a strawman argument.

See above. Even you use the term "disenfranchised", implying they are denied something that should somehow be an automatic inalienable right.

Sure they do. They can complain and demand all they want. Nobody has to listen, but you just want to bully all systemd critics into complete submission.

That paranoid conspiracy theory about "domination", "resistance" or "submission" is frankly bollocks. FGS, it's a piece of software that one guy started developing in his spare time, then more people joined in, then one company decided that they actually liked what they saw and reversed their initial stance on it, then more distros adopted it. If this is bullying someone into "submission" then Linus has disenfranchised all Minix users and bullied them into submission in exactly the same way.

Sure they can, but nobody has to listen.

At least we agree on that.

If you agree that it's not perfect, why do you try to kill any dissent?

Again this paranoia. Nobody is "killing" anything or anyone. Nobody is trying to wipe Devuan or Obarun out of existence. I don't know if someone who is pro-systemd goes on their forums to deliberately troll them but I certainly don't. The closest thing to any actual killing that ever occurred in relation to systemd was when some fringe and lunatic anti-systemd'ers put up that idea to hire a hitman on Pottering.

But why are you the arbiter of what critique is allowed and what isn't? Don't you understand that arguing with systemd's critics just amplifies their complaints? If you really think their complaints have no merit, the best thing you could do is ignore them.

No-one has the right to arbitrate what critique is "allowed" but everyone can and should call out BS. Sometimes discussions with systemd critics are actually interesting when they leave their conspiracy theories and *nix religion aside.

[smitty3268]

ROFTL. Ever heard about ACPI? No quirks required, huh?

Yeah, that's pretty much never true. Look at the capabilities monitors claim, for example, and compare that to all the quirks that are needed to make them actually work.