<div dir="ltr"><div><div>Greetings!<br><br>I'm the maintainer of the initscripts fork[1] and I already explained my self in the blog of Allan McRae[2]. <br><br>> My general advice would be to find (or create) a fork not based on systemdphobia, but on some practical need.<br>
</div>Are you calling people who don't like systemd insane? Excuse me but you should pick your words more carefully. The fact that I don't agree with some implementations decisions about systemd makes me insane? Really?<br>
<br>Yeah, I don't like it being the all-mighty-init-system-requiring-xyz-and-providing-zyx-replacment but I do like a few things such as the services format which is very simple to follow and the fact that basicly there isn't a runlevel (services being started when needed along with their dependencies). <br>
<br></div>You probably know about the "LSD" thingy that is floating around the net but you don't know what I, one of the first to step into it, think about Arch Linux and the move to systemd. You know that many packages are linked against systemd so I've tried maintaining packages without systemd support, or rather that use other udev fork[3], and link packages against it. But that was because systemd was already in place and even the initscripts rely on it being installed and some packages shipped in the repositories didn't support other authentication methods other than the systemd-logind. But keeping up with Arch Linux was not easy, I was maintaining ~200 packages and when/if I don't catch up with Arch Linux upgrades things started falling apart. So I've decided to rely on my own and make my own distribution. But there are some things you don't know about the LSD distribution, probably because you haven't searched for more information about it, please read <a href="http://less-systemd-gnulinux.wikia.co/wiki/Frequently_Asked_Questions#How_is_it_different_than_the_other_.28hundreds.29_of_distributions_out_there.3F">http://less-systemd-gnulinux.wikia.co/wiki/Frequently_Asked_Questions#How_is_it_different_than_the_other_.28hundreds.29_of_distributions_out_there.3F</a><br>
<div><div><div><div> to find out what I think even Arch Linux is missing/doing wrong and then judge my work and me personally.<br><br></div><div>[1] <a href="https://github.com/fluxer/initscripts" target="_blank">https://github.com/fluxer/initscripts</a><br>
[2] <a href="http://allanmcrae.com/2012/11/interesting-links-october-2012/#comment-16126">http://allanmcrae.com/2012/11/interesting-links-october-2012/#comment-16126</a><br>[3]<a href="https://bitbucket.org/braindamaged/udev">https://bitbucket.org/braindamaged/udev</a></div>
</div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 14, 2013 at 12:42 PM, Tom Gundersen <span dir="ltr"><<a href="mailto:teg@jklm.no" target="_blank">teg@jklm.no</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Feb 14, 2013 at 7:51 AM, Connor Behan <<a href="mailto:connor.behan@gmail.com">connor.behan@gmail.com</a>> wrote:<br>

> I can't post to arch-dev-public and like Lukas [0] I feel guilty about<br>
> not getting involved when I should've. Despite the absence of it in the<br>
> repos do you (Tom) still stand by your claim [1] that there is nothing<br>
> stopping someone from using initscripts in the far future?<br>
<br>
Yeah, the initscripts themselves are just fine.<br>
<br>
It now comes down to third-party software that to an increasing degree<br>
depend on systemd. As you know a few packages link against systemd<br>
(ConsoleKit (before it was dropped), NetworkManager and PolKit), and<br>
we will soon see all the rc scripts being dropped.<br>
<br>
All of this could relatively easily be worked around given enough<br>
manpower (you'd need a few dedicated people though). However, in the<br>
long-run I see this getting increasingly hard as various third-party<br>
software drop workarounds that would be needed for initscripts but not<br>
for systemd.<br>
<br>
All-in-all I think staying off systemd is a losing proposition in the<br>
long-term, but not due to anything to do with sysvinit/initscripts.<br>
<br>
> I'll admit that part of the reason I want to stick with initscripts is<br>
> because I'm a stubborn bastard. But I didn't think the package would be<br>
> dropped unless a large number of bugs presented themselves.<br>
<br>
These 'bugs' are rc scripts being dropped.<br>
<br>
> The<br>
> initscripts package I'm using is only two commits behind upstream so it<br>
> is almost like I'm "testing" the newest version. If I had volunteered to<br>
> test patches (even though I don't have interesting use cases like RAID /<br>
> LVM) would there have actually been patches to test?<br>
<br>
Probably not. We would need bug reports and people actually writing<br>
the patches too. I don't expect a huge amount of work being necessary,<br>
but for instance with the recent changes to lvm, it makes sense that<br>
something needs to be updated in initscripts too. From time to time<br>
there would be similar changes in the future I am sure.<br>
<br>
That said, the main work to keep initscripts working would be to rc<br>
scripts and third-party packages as mentioned above.<br>
<br>
> There are two forks out now. One aims to add features left and right<br>
> [2]. The other is a simpler fork that seems more future proof [3]. I am<br>
> thinking of using the latter. Of course the maintainer could do<br>
> something stupid later on, but so far he hasn't mentioned any crazy<br>
> plans like recompiling everything that needs udev. Is this my best bet<br>
> or do you think there are reasons to stick with the unsupported<br>
> initscripts from git?<br>
<br>
Of the two, I think [3] is definitely the best. That said, I remain<br>
very skeptical of any fork that did not first try working with<br>
upstream and submit patches on our ML.<br>
<br>
One important feature of the current initscripts (IMNSHO) which [3]<br>
seems to want to drop is compatibility with systemd. This is what will<br>
make initscripts simple to maintain, and what will make sure the<br>
generic Arch documentation also applies to initscripts to the degree<br>
possible, so dropping it is a big mistake in my eyes.<br>
<br>
That said, I saw a lot of commits in [3] which I would have happily<br>
accepted upstream had they been submitted.<br>
<br>
My general advice would be to find (or create) a fork not based on<br>
systemdphobia, but on some practical need. That way you are much less<br>
likely to have to deal with irrational and counterproductive goals.<br>
Oh, and once you find this practical need, please let me know, as I'd<br>
be interested in any use-cases that systemd does not cover :-)<br>
<br>
> [2] <a href="https://github.com/fluxer/initscripts" target="_blank">https://github.com/fluxer/initscripts</a><br>
> [3] <a href="https://bitbucket.org/TZ86/initscripts-fork" target="_blank">https://bitbucket.org/TZ86/initscripts-fork</a><br>
<br>
Cheers,<br>
<br>
Tom<br>
</blockquote></div><br></div>