Systemd's Networkd Now Supports Bridging

[intellivision]

Gentoo seems to also have both systemd-udev versions 204 and 208 (latest). As does Ubuntu that ships udev 204. They also use systemd-{logind,timedated,hostnamed,localed} on top of Upstart.

Ah, but none of those components are designed to be used outside of a systemd context.
As Lennart put it, all these configurations are not supported and will not be supported by the upstream community.

[k1l_]

Ah, but none of those components are designed to be used outside of a systemd context.
As Lennart put it, all these configurations are not supported and will not be supported by the upstream community.

lennart said, that he will make sure that this patched versions will not run outside of systemd in the future.

[erendorn]

lennart said, that he will make sure that this patched versions will not run outside of systemd in the future.

citation needed?

[tomegun]

lennart said, that he will make sure that this patched versions will not run outside of systemd in the future.

That's just nonsense. It is of course not the aim of anyone to actively restrict where software can be run. However, what may be true is that some systemd software will rely on features not available elsewhere, and this may of course change over time. If people don't like that all they have to do is to add the needed features to the alternatives (I know, that's not necessarily easy, but just complaining about it is a waste of time).

[k1l_]

citation needed?

cant find the right quote anymore. it was a comment on canonical wanting to port a newer version and he said, that he will make sure that this doesnt run for a long time.
i think it was in/about/at the debian decision but cant find it now.

what i found was this: https://plus.google.com/+LennartPoet...ts/8RmiAQsW9qf

The last time they tried that they took logind out of the systemd tree and ported it to Upstart. logind of course is one of the components of systemd where we explicitly documented that it is not a component you can rip out of systemd. And of course, just a few months after Canonical did this, things are broken again, and this was to be expected: logind now uses the new cgroups userspace APIs (as mentioned above), and hence it will not run without systemd around.

[erendorn]

cant find the right quote anymore. it was a comment on canonical wanting to port a newer version and he said, that he will make sure that this doesnt run for a long time.
i think it was in/about/at the debian decision but cant find it now.

what i found was this: https://plus.google.com/+LennartPoet...ts/8RmiAQsW9qf

you do realize that what you quote has nowhere near the same meaning that what you implied right?

[k1l_]

you do realize that what you quote has nowhere near the same meaning that what you implied right?

you saw me stating, that i cant find his exact quote anymore?

BTW its kind of funny how the same double standards apply again:
Canonical is burned with fire because they develop a system component that suits them best and not everyone else.
RedHat is given standing ovations when their stuff breaks other stuff. Other stuff like every other init system or even the bigger community while seperating the non-linux kernels. who talks about fragmentation now?

[Teho]

you saw me stating, that i cant find his exact quote anymore?

That's because it doesn't exist.

[erendorn]

you saw me stating, that i cant find his exact quote anymore?

BTW its kind of funny how the same double standards apply again:
Canonical is burned with fire because they develop a system component that suits them best and not everyone else.
RedHat is given standing ovations when their stuff breaks other stuff. Other stuff like every other init system or even the bigger community while seperating the non-linux kernels. who talks about fragmentation now?

What's funny is how it is necessary to correct the same things over and over again.
Canonical is burned with fire because their solution is not technically better and useless for other participants => pure loss for the community.
RedHat is given not much because this is not "RedHat's project" anymore.
And mostly because systemd is both technically better than upstart (which itself is technically better than sysvinit) and useful for other participants, as can be shown by the number of other distributions that use it.
Also systemd separates kernel because kernel are different (ie, already separated). Yes, the Linux kernel provides features that BSD kernels do not (cgroups, for example). Yes, if you use these features, you cannot use other kernels. Should we stop development on the Linux kernel to keep compatibility with other kernels?

There is a demand for systemd (or an equivalent) from independent actors, plain a simple. That is the very difference between the two projects.

[zanny]

What's funny is how it is necessary to correct the same things over and over again.
Canonical is burned with fire because their solution is not technically better and useless for other participants => pure loss for the community.
RedHat is given not much because this is not "RedHat's project" anymore.
And mostly because systemd is both technically better than upstart (which itself is technically better than sysvinit) and useful for other participants, as can be shown by the number of other distributions that use it.
Also systemd separates kernel because kernel are different (ie, already separated). Yes, the Linux kernel provides features that BSD kernels do not (cgroups, for example). Yes, if you use these features, you cannot use other kernels. Should we stop development on the Linux kernel to keep compatibility with other kernels?

There is a demand for systemd (or an equivalent) from independent actors, plain a simple. That is the very difference between the two projects.

Any argument that systemd is Red Hat trying to splinter the Linux community has to wake up that every other distribution is using systemd. It is not fragmenting if everyone has already agreed to adopt it, and have done so.

Does it make it harder to write Linux software not targeting systemd units, sockets, etc? Yes. Is it harder to write software for Linux rather than just traditional Unix? Yes. In the same sense, you accept specialization and limit your scope when you get more technically advanced software and more modern APIs involved. Linux isn't pure Unix compliant and that is it, it has all of its own features on top of traditional Unix. Systemd can serve as a traditional init daemon with init.d support, but also do much more with its own features.

And both of them follow the philosophy to have one function per part but have all the parts under one source tree and have them all rely on each other. You couldn't just rip out Linux FS drivers and run them under Mach, or rip out cgroups and use them with the plan9 kernel, or rip out the usb tree and reuse it on another system. It depends on a significant amount of kernel code in all those cases, but you don't bitch about how Linus is screwing with BSD by having their monolithic kernel implement APIs that are not cross-kernel compatible but are technically superior and much more usable.