The Debian init system general resolution returns
The Debian init system general resolution returns
Posted Oct 18, 2014 12:09 UTC (Sat) by Zack (guest, #37335)In reply to: The Debian init system general resolution returns by cortana
Parent article: The Debian init system general resolution returns
Can I have that in writing? Preferably something like:
"User Zack is entitled to have opinions. As such we, systemd proponents, will not rams ours down his throat by making software he might use have a hard dependency on systemd so he will be required to accept our opinions when upgrading."
Come to think of it, that's pretty much what the proposed GR is about, isn't it? That those who for some unfathomable reason cannot see the glorious nature of systemd and all that it encompasses (and will encompass) will not be required to use it.
Posted Oct 18, 2014 12:39 UTC (Sat)
by peter-b (guest, #66996)
[Link] (13 responses)
If, in my opinion, using systemd interfaces makes my software better, then I'll enjoy the freedom to use them. And you'll have still get to enjoy the aforementioned freedoms.
You have the freedom to have whatever opinions you like. Guess what? *So does everybody else.*
Posted Oct 18, 2014 12:58 UTC (Sat)
by Zack (guest, #37335)
[Link] (12 responses)
> You have the freedom to have whatever opinions you like. Guess what? *So does everybody else.*
If only everybody else who champions systemd would feel as strongly about this you do.
Posted Oct 18, 2014 13:06 UTC (Sat)
by pizza (subscriber, #46)
[Link] (11 responses)
> If only everybody else who champions systemd would feel as strongly about this you do.
Those who do the work, decide what gets done.
To paraphrase a saying, "Your right to hold an opinion ends when it requires me to perform unpaid work for you."
Posted Oct 18, 2014 19:24 UTC (Sat)
by Zack (guest, #37335)
[Link] (10 responses)
Why should I be doing unpaid work for an init system I do not want or need? It's great people like systemd and have a high opinion of it, but that opinion should really end when it's about to be installed on someone else's machine as a dependency.
Posted Oct 18, 2014 19:50 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (8 responses)
And as has been linked in this article's comments already, nothing that worked with sysvinit before doesn't work now. As such, I think Lucas' amendment makes much more sense than Ian's.
Posted Oct 20, 2014 4:24 UTC (Mon)
by edomaur (subscriber, #14520)
[Link] (5 responses)
Anyway, as a sysadmin with a bunch of servers on Debian and RedHat EL, and I am quite happy to get systemd on both : this way, I will (probably) not needing to write the same scripts 2 time each, and I will be able to remove some complexity from my day job.
Posted Oct 20, 2014 10:21 UTC (Mon)
by Zack (guest, #37335)
[Link] (4 responses)
This isn't about systemd's availability in Debian, it's about preventing maintainers from deliberately stonewalling others from doing the work to keep an alternative init system usable because they are of the opinion that systemd should be the only viable option for Debian.
Posted Oct 20, 2014 11:45 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (3 responses)
AFAIK there is no evidence that this is actually a problem. Please tell me about such a case if one exists.
I don't think package maintainers will deliberately refuse to merge contributions by interested third parties that enable their packages to run with particular init systems. It's just that package maintainers should not be forcibly volunteered by third parties to come up with the required code by themselves if they don't want to (which would be against Debian's constitution).
One solution could always be to team-maintain the packages in question such that maintainer A can take care of the adaptation to init system X that maintainer B (for whatever reason) doesn't want to touch, while maintainer B maintains the adaptation to init system Y that maintainer A (for whatever reason) doesn't want to touch. On the whole, Debian package maintainers are reasonable people, and it should generally be possible to work something out.
Posted Oct 20, 2014 13:27 UTC (Mon)
by Zack (guest, #37335)
[Link] (2 responses)
> I don't think package maintainers will deliberately refuse to merge contributions
And I'm not so sure about that. This GR will (or will not) give me the reassurance that any work done on alternative init implementations (or maintenance of sysvinit) will not be blocked simply by systemd being the default.
This GR isn't about shoving around work; it's about reassuring those who are not (yet) convinced about systemd, that Debian is still a suitable distribution for them and that their contributions are welcome.
Posted Oct 20, 2014 15:31 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
I think that the GR is only peripherally connected with that. As I said, even without the GR it is unlikely that package maintainers will deliberately decline to include support for other init systems than systemd if that support is volunteered by interested third parties.
It seems to me, though, that the GR in its present form tries to force package maintainers to create support for additional init systems even if the upstream package doesn't come with such support and nobody else steps forward to do it. In addition, it is unclear whether packages must support all init systems that are part of Debian or whether any two will do as long as one of them is systemd. One might also ask exactly what actually constitutes an “init system”.
In my opinion it is unreasonable to ask package maintainers to actively create support in their packages for additional non-default init systems. As of now most if not all relevant packages do support sysvinit, and that support should not be removed without good cause. Bug reports can be opened if required, and if the package maintainers don't (or can't) take care of them themselves then those people who are sufficiently interested in keeping sysvinit support going in Debian can help out. The same goes for support for things like Upstart; I don't think package maintainers should be compelled to add, debug, and maintain Upstart support for packages that don't come with it in the first place. If they want to do it, fine; but let those people who are interested in widespread Upstart support in Debian do the work if the package maintainer won't or can't do it, and have the package maintainer integrate it once it is done.
Posted Oct 20, 2014 17:32 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link]
What this GR does is make specific set of potential release blockers... regardless of whether patches have been contributed or not.
And let me be clear about this... this GR is not scoped to be just about ensuring a systemd transition from sysvinit.
In the future, post jesse if uselessd shows up in the repo, and uselessd works as a systemd replacement that will meet the requirement of this GR, without anything having to continue to work with sysvinit.
And that is the fundamental problem with this GR. It's not actually addressing the specific ongoing concern of making sure users can transition from old default (sysvinit) to new default (systemd) with minimal disruption.
The abstract language of the GR about init choice is just silly. Nobody really expected everything to work with mini as an alternative init without a lot of close hand-to-hand combat by the admin. The "freedom" to choose an alternative init has been until this point in time the "freedom" to break your system by choosing to use an alternative init.
This GR tries to make an overly broad policy statement that drastically changes the character of how all alternative inits are to be handled, but does not actually do anything to address the ongoing concern of transitioning from an old default init to a new default init...which is the only actionable concern that was triggered by choosing to change the default init.
-jef
Posted Oct 20, 2014 21:29 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
Actually, the LO devs (and I should know, I'm involved in it) ARE rewriting LO to remove the Java dependency. Incidentally, if you do build LO --without-java, pretty much the only thing that will break is Base.
Cheers,
Posted Oct 26, 2014 19:23 UTC (Sun)
by HelloWorld (guest, #56129)
[Link]
Posted Oct 20, 2014 0:56 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Oct 18, 2014 12:56 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (3 responses)
Posted Oct 18, 2014 20:29 UTC (Sat)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
-jef
Posted Oct 21, 2014 21:33 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
And this is supposed to *dissuade* us? :P
Posted Oct 21, 2014 21:35 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
Posted Oct 19, 2014 15:24 UTC (Sun)
by misc (subscriber, #73730)
[Link] (5 responses)
Once this social dynamic is understood, you can clearly see that any user protests is going to have almost no traction, especially since that's one of the strong point of Debian, being free from pressure. A commercial distribution where you pay money would be a different beast, since the customer is listened, due to the fact he exchange money for the work, so the relationship is balanced. A community distribution, not so much.
So you decided to take a distribution where no one can influence it, so you get what you asked for
Posted Oct 19, 2014 23:17 UTC (Sun)
by jb.1234abcd (guest, #95827)
[Link] (4 responses)
Once this social dynamic is understood, you can clearly see that any user protests is going to have almost no traction, ..."
I think your interpretation of this social dynamic is lacking.
Now with regard to systemd.
If systemd were not questioned the way it was (which forced the devs to
From this point of view alone, this Debian's GR is an attempt to limit
So, this alone invalidates your interpretation of one-way social dynamic that presumably governs relations between devs and the rest of OSS
jb
Posted Oct 20, 2014 11:13 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link]
Said closed dev cabal, who you claim developed everything in a closet with no input whatsoever from the wider community, does include someone from all important distributions. Their "in a closet" development model contemplated detailed analysis of extant init systems (not only Unixy ones, BTW), careful consideration of existing configuration file formats and locations among Linux distributions, and extensive consultation with interested parties. Go check systemd's blog for development (pre)history.
Posted Oct 20, 2014 17:45 UTC (Mon)
by misc (subscriber, #73730)
[Link] (1 responses)
Sure, you can think users are part of the movement and they are, but the truth is quite clear. There is no voting right for them, and they are barely acknowledge. Most distribution do not have a group dedicated to feedback from people. never wondered why there is several bug reporting tools for free software, but not so much to get feedback with a clear user orientation ?
When there is a problem, the priority is on the developer side, by pushing the work on users ( ie, filling a bug report ), because we clearly put more value on the time of people who contribute code than people that don't.
You can delude yourself in the state of free software, and I would be the first one to say that this balance of power is unfortunate and should be fixed.
Yet, being sorry about the state of affairs doesn't make it disappear, no matter how hard you want to believe. If you want things to change, you have to be constructive and do something, not just protest and post. As Linus once said "talk is cheap, show me the code".
Posted Oct 20, 2014 20:31 UTC (Mon)
by pizza (subscriber, #46)
[Link]
When there is a problem, it is up to the person who finds the problem to report it. That's not "pushing work on users" or making value judgements of anyone's time.
You can't fix what you don't know is broken.
Posted Oct 25, 2014 15:10 UTC (Sat)
by ms_43 (subscriber, #99293)
[Link]
Instead, the systemd project was started as an open bazaar-style community without silly CLAs that give a single corporation control, and the project managed to attract many contributors (https://www.openhub.net/p/systemd/contributors/summary).
You can educate yourself by reading Scott James Remnant's comments on this post:
Thus it is hard for me to see what "philosophy and rules of software development" were violated by the systemd project.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
It's about preventing maintainers from deliberately stonewalling others from doing the work to keep an alternative init system usable because they are of the opinion that systemd should be the only viable option for Debian.
The Debian init system general resolution returns
The Debian init system general resolution returns
This GR will (or will not) give me the reassurance that any work done on alternative init implementations (or maintenance of sysvinit) will not be blocked simply by systemd being the default.
The Debian init system general resolution returns
The Debian init system general resolution returns
Wol
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
This ecosystem functions according to different laws than a commercial
organization offering a product to a paying customer.
The reason for that is obvious - Open Source Software has a participatory
and contributory character. Those active in it, whether devs or all other
people assuming formal or informal roles of users, testers, ambassadors,
commentators, etc depend on each other organically.
Many of OSS projects, including kernel, would be non-starters or suffer
quality issues without often anonymous and free code contributions, advice, discussions, and PR-like activities at home, work place, and public at large.
I do not remember any software project, in this ecosystem or elsewhere,
that polarized the participants (see above) so much.
And for a good reason, as its aims as presented violated that ecosystem's
philosophy and rules of software development. It was an ambush style,
"my way or hiway" approach to introduction of a new software that impacted
everybody dependent on this ecosystem. As a result, it was met with
resistance and mistrust as to its intentions.
In the process of subsequent evaluation, the devs were even shown to lack
understanding of which domain's problems (real or perceived) they were trying to solve, which led them to a wrong model, which led them to some
antics in design and implementation.
My opinion is that systemd, if it had been properly evaluated in advance,
it would be structered and look different today, if not stopped altogether
at least until revised from top to bottom.
It is my opinion that the distros that hastily adopted systemd contributed
mightily to subsequent uproar in the ecosystem.
make some corrections), then the damage would be even bigger.
the damage to themselves, but also to the rest of us, and so it is
a positive step.
That's why it should find support among Debian devs, and beyond.
participants.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
https://plus.google.com/+KaySievers/posts/C3chC26khpq