Justin Moore writes:
Several people have raised this on the MythTV lists and provided feedback to the systemd developers. Last I heard their response was "this isn't broken because we don't know that it's a virtual network interface and we can't wait for ALL the network interfaces to come up because .... reasons. Closed: Working As Intended."The work-around was to buy a UPS for that machine because the #1 cause of reboots was flaky power in our neighborhood. No reboots ~> fewer chances for systemd to do the wrong thing.Sadly I think the power company will fix the distribution infrastructure in our neighborhood before systemd gets this working correctly.
I have no doubt that there are people who find systemd useful for one reason or another, and they are so thrilled with joy is that they will choose to willingly defend its merits in public.
But I can't name one off the top of my head. The systemd advocates that I've read – in my experience they were either directly, or closely, involved with the project.
The converse is true, for the other side. Of all the spilled ink that I read, I can't give one name of anyone who's involved, in any way, with anything that might be considered as competing with systemd's mind share, in any way, shape, or matter. I see people from all walks of life, find something or other that's fundamentally wrong with it. Either its fundamental technical flaws, or the fact that it takes ten bleeping seconds to figure out if one service is running, or not. The only thing they ever have in common is that if they raise it through the official channels, the response they usually get is not exactly professional. For example, let's take your specific case here. I note that the follow-up response to the article I cited made some kind of tenuous comparison with the Linux kernel, in some form or fashion, that I found quite hard to follow. I can't help but recall that the Linux kernel maintains blacklists of devices, by their USB or ATAPI id, of some sort, when those specific devices fail to implement some key aspect of the relevant hardware protocol. The blacklisted devices are fully supported, except for some obscure featureset for which there's a fallback alternate implementation, which is used.
I even recall one newsworthy incident several years ago. Chipmaker FTDI makes USB bridge chips, and a Windows driver for them. Naturally, a bunch of cheap knockoffs of the hardware flooded the market. Since Windows already had a driver in the base OS, it was plug and play with the clones. Then, FTDI released a driver update that bricked the cheap clones, by intentionally wiping the bridge chips' NVRAM, and setting their USB manufacturer id to 0000. Anyway, some time later the Linux kernel was patched to recognize the phony manufacturer id, and fully support it. The incident you described reminded me of that episode, for some reason.
Anyway, back to your situation: the responsible, and user friendly, thing to do here would also be to maintain a known blacklist of virtual network interfaces that are not true network interfaces, and ignore them. Just like the Linux kernel would do in a comparable situation. I'm sure that this is eminently possible. That's what I would do. Then, the main functionality of systemd will work as intended. This is the proper way to go, instead of the stock "too bad, so sad, your system is going to be bleeked up because we are smarter, and we know better" response.
I have complete faith that this is going to correct itself, over time. It won't happen soon, but these things typically work themselves out in long term. Currently, systemd has mindshare in most Linux distros. But that can always change, and I think it will. And then, systemd will eventually join XFree86 on the ash heap of history; and it will be interesting to see if systemd will take Red Hat down with it. Red Hat has bet its farm on systemd; and it remains to be seen how far they will ride the bomb (Google it).
Attachment:
pgplsDI6f_JCg.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
