4 ms·
> we will assume that declared dependencies are correct, gain a minor speed boost, and it things blow up it's not our fault'. Wait that actually sounds pretty
by jelder 10y ago
> we will assume that declared dependencies are correct, gain a minor speed boost, and it things blow up it's not our fault'.
Wait that actually sounds pretty reasonable. What's wrong with systemd taking that position exactly?
- orf 10y agoNothing, it's just it broke something this guy maintains/owns because his scripts where literally broken. And now that means Systemd is some horrible monster because it executes exactly what it is told to, and doesn't double guess the input because of some legacy crap. Garbage in, garbage out folks.
- masklinn 10y agoHis scripts were not broken, his LSB headers were, which would be obvious to anyone considering they're script comments which no tool had ever executed, which means they're 15 years of bitrot, I've seen examples in documentation bitrot in under 6 months. The "garbage in" part is entirely systemd's fault, it was their decision to make the system's boot process rely unconditionally on LSB dependencies which were all but guaranteed to be broken.
- jjnoakes 10y agoI'm not defending systemd here, but in general, if your files have standardized headers that indicate the wrong information, how is that anyone else's problem?
- lsaferite 10y agoSeeing that no one is apparently using the information until systemd decided to, it seems like systemd being pedantic and the problem.
- digi_owl 10y agoAnd while i can't pull another example out of a hat right now, i am sure i have seen other examples of systemd being pedantic about information nobody else have relied on before, and in the process getting its panties in a twist.
- jjnoakes 10y agoAgain, not defending systemd, but if you have a structured header in your file which is following a standard (even if no one is using your header or that standard yet), and your header is wrong, is it really anyone else's fault but yours? Shouldn't the fix simply be to remove the header (if you don't want anyone using it) or fixing it (if you do)? Why ask tools, which interpret the header according to the standard, to do something different because your header is wrong?
- digi_owl 10y agoAnd once more we are myopically focusing on the technical when the root of the issue is historical and social (if not organizational). While the headers have existed, they have historically been underutilized and thus poorly maintained. Thus a newcomer can't just walk in and suddenly make them massively important while claiming the breakages that come out of it is not their problem.
- jjnoakes 10y ago> While the headers have existed, they have historically been underutilized and thus poorly maintained. They are human-readable, so even if no tool used them, they still have an effect. Someone might read the header and incorrectly move the service in their sequential boot order, for example. Would you recommend that the person reading the header also "fix themselves" instead of fixing the header or filing a bug against whomever owns the incorrect file? > Thus a newcomer can't just walk in and suddenly make them massively important while claiming the breakages that come out of it is not their problem. Someone decided to put the two things together, right? Someone combined this "newcomer" and these old files with the bad headers? The onus should be on that person to make things right, not the tool which is using the headers correctly. It could be a distribution, for example, but it isn't the tool. Update them or remove them if they are wrong. Why campaign to leave them intact and incorrect?
- raverbashing 10y agoActually the dependencies are considered by several tools, like chkconfig (source: have actually done this) But yeah, having configuration in a comment is as absurd as it looks
- orf 10y agoBroken being the important word here. Also after a cursory google this[1] SO posts appears, which says that the headers where most certainly not ignored. 1. http://unix.stackexchange.com/a/233581 http://unix.stackexchange.com/a/233581
- mjw1007 10y agoAt least Debian and Ubuntu have been paying attention to LSB headers for years. They may be comments to the shell, but they're input data to insserv.
- rbanffy 10y agoBitrot has to be fixed. Think of systemd as your friendly LSB header linter.
- garaetjjte 10y agohttps://xkcd.com/1172/ https://xkcd.com/1172/
- digi_owl 10y agoWhenever this one comes up, i am unsure how to interpret it in context. Because i am tempted to side with longtimeuser4 on the issue, but not to the point of re-enabling CPU heating. Instead, implementing some way for holding a user configured key for a user configured period of time to trigger the wanted action. Thus both workflow and fix is preserved.
- dsp1234 10y agoWhat's wrong with systemd taking that position exactly? They are gathering "dependencies" from script comments which have never been executed in any other system. Equivalent to: //#include "myfile.h"
- lelandbatey 10y agoThat is factually incorrect. The insserv software makes use of these dependency declarations for dependency based parallel boot sequencing, which has been in use by Debian since 2005 (based on the comments in the changelog), and I believe it's been the default in Debian since 2008.
- dsr_ 10y agoWhat's wrong with that: 1. They aren't really declared dependencies, they only look like that. 2. nothing else, once you understand point 1.
- rbanffy 10y agoThis is a time-tested way to make people fix broken things that work by accident.