| |||||||||||||
Poettering: The Biggest MythsPoettering: The Biggest MythsPosted Feb 3, 2013 4:04 UTC (Sun) by mgb (guest, #3226)In reply to: Poettering: The Biggest Myths by HelloWorld Parent article: Poettering: The Biggest Myths The list of what Poettering says he won't break excludes everything of importance. ... will not accept patches for certain distribution-specific compatibility ...So if you're not Fedora you're at Poettering's mercy. But whether you're Fedora or not you can't even write a script that configures the NICs in your servers. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single "eth0" interface. With this new scheme in place, an administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that "eth0" was the right name.wwp0s29u1u4i6 is so much easier to remember than eth0, don't you think?
(Log in to post comments)
Poettering: The Biggest Myths Posted Feb 3, 2013 5:04 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
You have no idea what you are talking about and merely repeating a misinformed notion. There is zero Fedora specific things in systemd. systemd upstream is entirely distribution neutral.
Poettering: The Biggest Myths Posted Feb 3, 2013 8:23 UTC (Sun) by smurf (subscriber, #17840) [Link]
> wwp0s29u1u4i6 is so much easier to remember than eth0, don't you think?
You don't remember it. You add it to your system configuration and then forget about it. This is important if you ever add a second interface. For all other uses, there's "ip intf ls" and copy/paste.
You profess to be a sysadmin. You should know that.
Besides, the new scheme can be turned off, so you get a choice.
Stop spreading FUD and stop selectively reading systemd documentation.
Poettering: The Biggest Myths Posted Feb 3, 2013 15:47 UTC (Sun) by smurf (subscriber, #17840) [Link]
>> ip intf ls
"ip link ls". Duh.
-- me, trying to wean myself from ifconfig
Poettering: The Biggest Myths Posted Feb 3, 2013 12:21 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> So if you're not Fedora you're at Poettering's mercy.
Many of systemd's "new" configuration files came from Debian, not Fedora. And besides, having the same configuration files across most distros is a good thing in the long term.
As for the network interface name stuff, here's the page your quote is from:
I don't even know why I'm replying to crazy people like you any more...
Poettering: The Biggest Myths Posted Feb 3, 2013 12:52 UTC (Sun) by andresfreund (subscriber, #69562) [Link]
> So you quoted the paragraph that informs about one trivial disadvantage (the need to type "ifconfig" once to find out the name of the interface) while ignoring all the important stuff, such as consistent interface naming across reboots. Seriously, whom are you trying to shit here?
Imo the problem is not to have to type ifconfig once, but having to type it all the time. I am completely unashamed to admit that I cannot remember such generated names. The earlier approach of generating stable ethX style interface name imo worked well enough and generated easier to remember names.
I don't understand why you feel the need to react with that amount of hyperbole. It only reinforces stupid anti-systemd stereotypes.
Poettering: The Biggest Myths Posted Feb 3, 2013 16:18 UTC (Sun) by smurf (subscriber, #17840) [Link]
>> the problem is not to have to type ifconfig once,
>> but having to type it all the time.
*Sigh*. Did anybody even read the PredictableNetworkInterfaceNames page?
Further observations:
* If you have to type in the name more than once, even in an emergency situation where you'd have to setup a route by hand, you're doing something wrong. If necessary, I'd type x=ethxMACaddr once, then refer to the thing by $x, which is even less typing than eth0. Or I'd use the shell's command history; even the busybox shell has one, these days.
* What's worse – a bit of an inconvenience, or having your internal network suddenly exposed to the whole world, because a timing quirk re-ordered your interfaces? Give me (and Lennart) a break here.
I do not want an OS which defaults to doing unsafe, random, and/or race-condition-prone things when it boots. Neither WRT my disk drives (remember the switch to UUIDs?) nor my network interfaces.
Poettering: The Biggest Myths Posted Feb 4, 2013 19:29 UTC (Mon) by mathstuf (subscriber, #69389) [Link]
I use zsh and it tab-completes ifup/ifdown interfaces for me (I don't use NetworkManager even on laptops) for me. A comparable completion function for bash shouldn't be too complicated.
Poettering: The Biggest Myths Posted Feb 4, 2013 20:32 UTC (Mon) by mgb (guest, #3226) [Link]
When you're managing large numbers of systems in offices and data centers scattered around the globe you can't count on tab completion to ensure your systems reboot online. You need predictable interface names.
eth0 used to be the answer. It was great.
Then along came udev. In solving a rare problem (consistent interface naming in the presence of multiple NICs) it created a much more serious problem (interface names change whenever broken NIC replaced).
Sysadmins have mostly solved this by configuring both eth0 and eth1 even when eth1 doesn't exist yet. It's a PITA but we're ready when udev slams us.
But now with systemd we would have to get out the ouija board to figure out some kind of name like wwp0s29u1u4i6 that's going to take over when a broken NIC is replaced two years hence.
The better solution is to stay with an init system that works well and doesn't get in our way and doesn't cause random problems by starting services in a different order on every boot.
Poettering: The Biggest Myths Posted Feb 4, 2013 21:03 UTC (Mon) by anselm (subscriber, #2796) [Link] Read the effing documentation already. A convenient link has been provided to you earlier in this thread.
We understand that you're not so hot on systemd. However your position would be that much more tenable if you had actual valid criticisms informed by facts. Judging from your last few postings this does not appear to be the case.
Poettering: The Biggest Myths Posted Feb 4, 2013 21:10 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
you must have missed the memo where the maintainers merged the projects and have made it so that you can't build udev independently of systemd
Yes, the problems he is describing started off as udev problems, but they are now systemd problems
Poettering: The Biggest Myths Posted Feb 4, 2013 21:21 UTC (Mon) by anselm (subscriber, #2796) [Link] You don't need to install systemd in order to install udev. If you start from sources you have to build both but it is perfectly possible to install (or package for installation) udev without anything from systemd. This has all been explained to death here already.
Poettering: The Biggest Myths Posted Feb 4, 2013 21:23 UTC (Mon) by raven667 (subscriber, #5198) [Link]
They do share build infrastructure but you can run them independently so running udev doesn't imply running systemd. You're not going to get some kind of systemd cooties from building the shared components you don't end up needing if you just want udev. 8-)
Poettering: The Biggest Myths Posted Feb 6, 2013 5:35 UTC (Wed) by spaetz (subscriber, #32870) [Link]
> This is not a systemd issue in any way, shape, or form. It is a udev issue. Systemd and udev share maintainers but this is as far as it goes.
Not leaning in on the pro/contra discussion, but this is an exaggeration by far. The announcement (http://lwn.net/Articles/490413/) makes it clear that they "merge the udev sources into the systemd source tree."
To me that indicates strongly that systemd and udev are more than two independent tarballs that can be version mix-and-matched and just happen to have the same maintainers.
Poettering: The Biggest Myths Posted Feb 6, 2013 12:05 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> Not leaning in on the pro/contra discussion, but this is an exaggeration by far.
No, it's not. udev does the interface naming stuff and systemd has nothing at all to do with it.
Poettering: The Biggest Myths Posted Feb 4, 2013 21:09 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
> Then along came udev. In solving a rare problem (consistent interface naming in the presence of multiple NICs) it created a much more serious problem (interface names change whenever broken NIC replaced).
I delete the udev rules that implements this on all my server images, it's just not needed. If an interface fails badly enough that other interfaces get renamed to fill the gap, things don't work (it doesn't cause a security risk as the IPs and routes won't be able to make connections any longer
> The better solution is to stay with an init system that works well and doesn't get in our way and doesn't cause random problems by starting services in a different order on every boot.
On my laptop, I like a fast booting system, but I've been able to do that for a decade by stripping down the boot process to not try a bunch of stuff that I don't need.
On servers, predictability and stability are far more important than boot speed. Boot speed is limited by the hardware initialization anyway, I've got large systems that take so long to go through the hardware initialization that I can hit power on one of the large system at the same time I do on a simple (but fast) system, and boot the simple system off a CD, install the OS, and move the CD to the complex system before it gets around to reading the CD. I've setup demos of doing exactly this to impress manager types about how fast the install process is :-)
If you want a fast boot and don't have to dig into the boot process when something goes wrong, the newer init systems are nice.
But if boot speed is not that important to you, but predictability is, then async device detection, parallelizing the boot, etc add complexity and race conditions that cause more harm than the benefit provided.
Poettering: The Biggest Myths Posted Feb 4, 2013 22:26 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> If an interface fails badly enough that other interfaces get renamed to fill the gap, things don't work
I think that's the opposite of what happens, udev and the practice of associating interface names to the MAC address is so that the interface names are stable across boots and don't get shuffled around in the manner you describe without the sysadmin taking action. 00:11:22:33:44:55 is always eth0 regardless of detection and module load order, if you put in a different NIC with a new MAC and want it to take over an address then you may want to edit the configs before hand, or from the console if you have OOB access.
> But if boot speed is not that important to you, but predictability is, then async device detection, parallelizing the boot, etc add complexity and race conditions that cause more harm than the benefit provided.
I think the point of socket activation is that its fundamentally not race condition prone, and where you want explicit dependencies you can set Before and After to group things. Not having dependancies and service detection at all is inherently racy. As stated, boot speed wasn't a particular design goal but something that fell out of the design, and is worth mentioning, because it's not doing unnecessary work to get the same end result. Spawning thousands of instances of cut and grep and awk to parse config files and whatnot is much more expensive than just using a normal system programming language.
Poettering: The Biggest Myths Posted Feb 4, 2013 22:40 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
I was talking about the problems you can have if you disable the udev interface naming stuff.
socket activation has problems with response time if it takes a noticable amount of time for the service to start and get to steady-state.
Yes, for some things it's great, but for the main service a system is providing, I would not want to use it.
These sorts of things are the difference between desktop use (where you have lots of stuff defined, but seldom use any of it) and servers (where you permanently disable or uninstall what you don't need, and what remains is likely to be hammered)
Poettering: The Biggest Myths Posted Feb 4, 2013 23:07 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> socket activation has problems with response time if it takes a noticable amount of time for the service to start and get to steady-state.
I don't think thats much of a problem in practice, you can start a service without waiting for a request to come in to activate it, say by having it start after networking and being a requirement for the multi-user target and having it manage its own sockets. Initial request latency on a service which is starting or has just started is a problem that can exist with or without systemd.
Poettering: The Biggest Myths Posted Feb 4, 2013 23:46 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
if you have the service start itself, that's not socket activation.
I'm not saying that systemd can't support this either (before someone attacks me, saying that systemd can do this)
Poettering: The Biggest Myths Posted Feb 5, 2013 0:23 UTC (Tue) by raven667 (subscriber, #5198) [Link]
Of course, but your service can depend on others which are socket activated.
Poettering: The Biggest Myths Posted Feb 5, 2013 18:53 UTC (Tue) by khim (subscriber, #9252) [Link] Sure, but you missing the point: when you use systemd you can combine socket activation and other forms of activation. That's pretty powerfull stuff: your service will start when you system is started and other services can use it even at early boot stages. If your service is somehow started early - not a problem, it'll be used "as is", if it's not yet started - it'll be brought up via socket activation and other services will wait - all transparently and without any fuss or explicit dependencies sorting.
Poettering: The Biggest Myths Posted Feb 5, 2013 19:24 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
sigh, that 's why I added the bit about how I wasn't saying that systemd couldn't do this.
I wasn't missing the point, I wasn't saying that systemd can't do this.
I was just saying that there are times when socket activation is not the best thing to be doing.
Poettering: The Biggest Myths Posted Feb 5, 2013 19:58 UTC (Tue) by khim (subscriber, #9252) [Link] I was just saying that there are times when socket activation is not the best thing to be doing. It's never a good idea to disable a socket activation. Socket activation is your safety net. It guarantees that services will be started when they are needed. Everything else is optional. This is yet another thing which systemd is doing correctly and which was traditionally managed in an an-hoc-kinda-works-in-you-quint-just-right way.
Poettering: The Biggest Myths Posted Feb 5, 2013 21:55 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
having a service started multiple times is not always a safe thing to do. In theory the service properly checks and makes sure there's only one copy of it running, in practice you just don't do that, or it _will_ bite you down the road.
Poettering: The Biggest Myths Posted Feb 5, 2013 22:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Uhm, systemd gurantees that a service will be started only once.
On the other hands, I did have problems when ejabberd started in parallel with the PostgreSQL database - there was no dependency in LSB headers because I was using an optional psql auth module.
This worked just fine until the day it suddenly stopped working because the ordering of services has changed and Postgres moved a little bit later into the boot process.
Poettering: The Biggest Myths Posted Feb 5, 2013 22:16 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
If nothing can go wrong, then why would you want to have a service that you configure to start one way also configured for socket based startup?
One of the things you learn after several years of running large numbers of production systems is to not trust claims that a process will always work, whatever that process is.
Failures are generally not that common, but they do happen.
Poettering: The Biggest Myths Posted Feb 5, 2013 22:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
I thought it's obvious - socket-based activation enforces the ordering of services and explicit startup might be required because service might need to do some background stuff.
Also, it might decrease the response time time for the first client.
SystemD nicely allows to do both.
Poettering: The Biggest Myths Posted Feb 6, 2013 8:14 UTC (Wed) by paulj (subscriber, #341) [Link]
The one downfall to this is that not all dependencies are socket-based. Some dependencies are more complex, and need a more abstract protocol than "open a socket" to express.
Poettering: The Biggest Myths Posted Feb 6, 2013 9:18 UTC (Wed) by anselm (subscriber, #2796) [Link] So? Systemd can deal with that, too – at least as well as System V init does. For example, systemd lets you express explicit forward and backward dependencies between services and will automatically construct a starting order based on that. With System V init, you either get to work out any dependencies yourself to set the magic numbers correctly by hand, or you use something like SUSE's insserv based on LSB metadata in the init scripts, where reverse dependencies are not an official feature.
Poettering: The Biggest Myths Posted Feb 6, 2013 12:21 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> The one downfall to this is that not all dependencies are socket-based.
Systemd offers a lot more than socket-based activation (which btw even supports inetd compatibility). There's also dbus-, device-, timer- and path-based activation and autofs support (which is arguably a service activation scheme as it can be used with FUSE file systems).
Poettering: The Biggest Myths Posted Feb 6, 2013 16:52 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
If you have some very exotic services that use smoke signals to communicate - go on and add explicit dependencies.
Poettering: The Biggest Myths Posted Feb 7, 2013 4:34 UTC (Thu) by paulj (subscriber, #341) [Link]
How would you add a dependency on, say, a location? Assume there is some daemon running on the system that can make the current location available over a socket (e.g. GPS co-ordinates, or a more abstract specification). The dependency is not just on the socket, but also on the /content/ of the information sent over that socket.
Hardly smoke signals.
Poettering: The Biggest Myths Posted Feb 7, 2013 5:38 UTC (Thu) by khim (subscriber, #9252) [Link] Hardly smoke signals. It is a smoke signal - from GPS stateliness. It can easily be converted to something systemd understands if you'll create a specialized daemon (in a "true UNIX fashion" people like to preach here so much) which will convert it to signals systemd understands. And you need such daemon anyway because you need to decide how often you poll, if you use just GPS or if you want to use WiFi, too, etc. It's not as if GPS satellites can pull some trigger on your PC or smartphone which means you'll need some complex logic anyway.
Poettering: The Biggest Myths Posted Feb 7, 2013 5:50 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the GPS daemon does have a socket that systemd understands, what are you suggesting? making a different socket for every possible location so that systemd can set dependencies on if that socket responds???
Just because systemd doesn't handle something doesn't mean that the something is worthless or stupid.
Poettering: The Biggest Myths Posted Feb 7, 2013 8:00 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
If systemd cannot handle something, is there a bug report? If not, why not?
Poettering: The Biggest Myths Posted Feb 7, 2013 8:39 UTC (Thu) by paulj (subscriber, #341) [Link]
There'll be no bug report on systemd because the applications involved are likely already using some other system. E.g. DBus IPC. DBus-daemon also can do "socket activation", and did before systemd existed I think.
Poettering: The Biggest Myths Posted Feb 7, 2013 12:33 UTC (Thu) by khim (subscriber, #9252) [Link] There'll be no bug report on systemd because the applications involved are likely already using some other system. E.g. DBus IPC. If it used DBus IPC then it can be easily be used with systemd thus error report will be entirely unnecessary. I've said "convert it to signals systemd understands" and not "convert it to socket activation" exactly for this reason: because systemd handles many different activation requests and makes sure they don't conflict. Socket activation is just one of them (even if one of the most important ones).
Poettering: The Biggest Myths Posted Feb 7, 2013 17:02 UTC (Thu) by paulj (subscriber, #341) [Link]
Interesting, thanks. :)
Bit of a dance, to have the IPC nexus hand-off this activation. It feels like really these should be part of one thing...
Poettering: The Biggest Myths Posted Feb 7, 2013 8:25 UTC (Thu) by anselm (subscriber, #2796) [Link] The GPS daemon provides the current location on a socket. It is probably unreasonable to expect systemd to be able to deal with that sort of information directly (systemd detractors would immediately jump on features such as these and call them out as »bloat«, with some justification). Hence, a reasonable way of handling this would be to write a (not very complicated) subsidiary daemon that listened to the GPS daemon's output and triggered various systemd actions based on them. This might be a good idea in any case in order to provide »smoothing« of the location data or additional rules (»tell me about bars in the vicinity but only during happy hour«). This daemon itself would of course be managed by systemd. This approach should also please the Unix traditionalists who insist that programs should »do one job and do it well«.
Poettering: The Biggest Myths Posted Feb 7, 2013 8:35 UTC (Thu) by paulj (subscriber, #341) [Link]
So, go on, how do you expose that dependency in a way systemd can handle it. Tell me.
(FWIW, I have no opinion generally on systemd - I don't know enough about it. I'm just a tad sceptical of the wonder claims being made for socket activation based dependency resolution).
Poettering: The Biggest Myths Posted Feb 7, 2013 8:59 UTC (Thu) by cortana (subscriber, #24596) [Link]
Perhaps you could create target units for each location of interest; other units could then be wanted by/conflict with each target in order to be started/stopped when the location is changed. You would need a glue daemon to look at the GPS data and decide when to start/stop the location targets.
Poettering: The Biggest Myths Posted Feb 7, 2013 12:41 UTC (Thu) by khim (subscriber, #9252) [Link] So, go on, how do you expose that dependency in a way systemd can handle it. Tell me. Well, as you've suggested: DBus activation looks like a natural fit for such a use case - and since systemd handles it just fine... I don't see what's your problem. I'm just a tad sceptical of the wonder claims being made for socket activation based dependency resolution. Socket activation covers 90% of usecases, but there are other ways to activate service. And the important thing of systemd is that they all can be used simultaneously. You can start some daemon at specific time (using time-based activation) and when your a leaving specific area (D-Bus based activation) and when some other service needs this particular daemon (socket-based activation). They don't conflict and handled correctly in all cases. Socket activation is there to track dependencies between services on your own system: it's the simplest one to use and most robust one. But there are other to handle "smoke signals", too.
Poettering: The Biggest Myths Posted Feb 7, 2013 12:19 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Don't use socket-based activation and do your dependencies manually, just as in the SysV world. Simple.
Additionally, designer of such a crazy interface should be shot immediately to stop propagating bogosity.
Poettering: The Biggest Myths Posted Feb 7, 2013 15:59 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> Don't use socket-based activation and do your dependencies manually, just as in the SysV world. Simple.
Then why is it that when people talk about doing exactly this, they get jumped by systemd people saying things like "why didn't you submit a bug report to get that capibility added to systemd" or "that's a stupid way to do things, you need to re-write your software to use systemd to do it"
This subthread started by the simple statement that socket-based activation was not always appropriate, with the acknowledgement that systemd could support this.
Poettering: The Biggest Myths Posted Feb 7, 2013 16:03 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
> Then why is it that when people talk about doing exactly this, they get jumped by systemd people saying things like "why didn't you submit a bug report to get that capibility added to systemd" or "that's a stupid way to do things, you need to re-write your software to use systemd to do it"
These advices are not mutually exclusive, you know.
If you have a compelling use-case of some exotic activation system for which it makes sense to add core support then doing a bugreport might be a good idea.
And in other cases it might be a good idea to simply rewrite the offending code.
Poettering: The Biggest Myths Posted Feb 5, 2013 22:43 UTC (Tue) by raven667 (subscriber, #5198) [Link]
That's not a problem that can happen with systemd though, since it keeps the services on a tight leash and knows what state (running or not) the service is in. Since that part must be self-contained in PID 1 it would seem there is little room for race conditions or errors to exist.
If we had the time we could skim through http://cgit.freedesktop.org/systemd/systemd/tree/src/core/ and see if we can identify where it keeps that state and how it is updated to see if there are any bugs.
Poettering: The Biggest Myths Posted Feb 5, 2013 2:38 UTC (Tue) by smurf (subscriber, #17840) [Link]
> socket activation has problems with response time if it takes
> a noticable amount of time for the service to start and get to steady-state.
True. On a server, you probably don't want to use socket activation.
But socket activation is only an offshoot of systemd's "let me open all the sockets up front and hand them out to the daemons" idea. And that's useful on servers with their multiple daemons, because you now no longer need 90% of your boot dependencies, which is 90% less stuff to go wrong – esp. since some of these depend on the details in your daemons' config files.
Poettering: The Biggest Myths Posted Feb 5, 2013 18:55 UTC (Tue) by dgm (subscriber, #49227) [Link]
> that's useful on servers with their multiple daemons, because you now no longer need 90% of your boot dependencies
I'm a bit divided about that, exactly because of this. If you don't need them, they should not be there. I fear that this will lead to distros enabling each and every service under the sun, just because they assume it will not get activated, which may or may not be true.
Poettering: The Biggest Myths Posted Feb 6, 2013 1:37 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> I fear that this will lead to distros enabling each and every service under the sun
You mean like Debian has been doing for ages?
Poettering: The Biggest Myths Posted Feb 6, 2013 12:15 UTC (Wed) by smurf (subscriber, #17840) [Link]
You misunderstand.
What I mean is that if Apache needs Mysql, you no longer need to entomb that dependency in your startup scripts.
Poettering: The Biggest Myths Posted Feb 5, 2013 18:58 UTC (Tue) by khim (subscriber, #9252) [Link] True. On a server, you probably don't want to use socket activation. Yes, you absolutely do want to use socket activation on server. It guarantees that service will be brought up if needed. You may want to use other forms of activation, too - but these are optional, if your forgot to explicitly start some service which is needed by other service - socket activation is there to bail you out. Even if you bring up all the services on server startup you still want socket activation. Without socket activation you need to order them somehow and need to think about dependencies between them, etc but with socket activation you just start them all - and that's it: socket activation will guarantee that nothing will be lost.
Poettering: The Biggest Myths Posted Feb 6, 2013 1:51 UTC (Wed) by HelloWorld (guest, #56129) [Link]
So you're saying that having multiple NICs is a rare thing when you're managing large numbers of systems in data centers?
And if that weren't enough, you readily admit that you're too incompetent to figure out that the mapping from MAC addresses to interface names is stored in /etc/udev/rules.d/70-persistent-net.rules and can be modified there?
You're a crazy person. Get help. Or don't, I don't care.
Poettering: The Biggest Myths Posted Feb 3, 2013 22:41 UTC (Sun) by ovitters (subscriber, #27950) [Link]
Lennart nor systemd force things on others. The systemd developers had a upstream/downstream discussion at FOSDEM. It was announced on their mailing list, it was announced + arranged eventually via Google+. People from various distributions participated, Debian as well.
The seem to be that systemd is a "take it or leave it" and that Lennart somehow makes people do things against their will. While actually there are a lot of people who work within distributions who also do not see the need for so many differences between distributions.
systemd reduces those differences. The work is done by people who agree to that. Those people participate in all the ideas. Lennart & co go to loads of conferences to ensure they reach out to the people who actually make things happen.
It would be nice if you went to FOSDEM and just followed what goes on. Everything is in the open, etc.
|
|||||||||||||