On Mon, Aug 13, 2012 at 08:58:41AM -0400, Baho Utot wrote:
> Yes looks like I will need to migrate to BSD

I've already begun using FreeBSD. Only real complaint I have is that my notmuch database isn't backwards compatible with the one they have in ports. Other than that, it's been a smooth transition.

I was always most attracted to arch by its proximity to the BSD's. With all this talk of systemd, I felt it was time to bring that proximity to fruition.

Arch remains on my laptop for the time being. I have fond memories of Arch that I hope do not dwindle.

On Tue, Aug 14, 2012 at 03:05:02PM +0200, Jelle van der Waa wrote:
> Tell me what's hard about systemd?

I think what he was saying wasn't that systemd is hard but switching is hard irrespectively of what you're switching to.

That's my inference anyway.

On Tue, Aug 14, 2012 at 09:12:30AM -0400, Baho Utot wrote:
> I have stopped using arch except for one server that does mail and DNS.
> It is presently being moved to "my own linux distro" based on LFS and
> using pacman for the package manager.

Oooh! Link?

On Tue, Aug 14, 2012 at 02:37:54PM +0200, Ralf Mardorf wrote:
> I suspect that BSD for artist that draw can be used, but for audio not.
> Am I mistaken?

I'm not sure I understand the question.

There's a lot of audio software in FreeBSD. Whether any of it suits your purposes, I can not say.

http://www.freebsd.org/ports/

Arch certainly has great stuff in this department. The AUR's full of decent packages. But I'm not really an "artist" interested in "audio" so I can't say how any of it compares.

On Tue, Aug 14, 2012 at 09:08:36AM -0400, Baho Utot wrote:
> What is so wrong with the booting using sysvinit?

As a critic of systemd, perhaps I can help.

Init scripts tend to wreck the determinism beacuse they can inherit
your env. pid files are a problem waiting to happen. There really
is nothing preventing them from getting trampled or deleted and
then you've gotta go kill daemon processes by hand.

Having to start daemons in a certain order is obnoxious.

The more shell script you have to write in order to get daemons up
(or shut 'em down) just means more opportunity for little annoying
bugs.

Startup speed is therefore affected. This doesn't matter if you
don't reboot often but if you're doing lots of systems dev, it can
be said that every minute spent waiting for the system to boot is
one less minute spent improving your software.

> I really don't need what systemd offers and sysvinit does everything I
> need and has not failed me.

Indeed, this is a values judgment. The argument for abandoning
init scripts could be made in the department of "Code
Correctness" as it is defined in the Arch Way...

https://wiki.archlinux.org/index.php/The_Arch_Way

There is no doubt that the community-tested traditions have
found their way into effectiveness.

> As for systemd being better solution for the problem of booting the
> beauty is in the eye of the beholder and I just don't see it, so why
> take away sysvint?

I'm still experimenting with daemontools under sysvinit as I
described here:

https://bbs.archlinux.org/viewtopic.php?id=141831

The transition seems less brutal, the ability to start things
in parallel is there, supervision is there, but there is no
process grouping (which I consider unimportant) as with systemd.

> You can use systemd and I should be able to use what works for me and
> not be forced down the systemd path.

As explained in this and other threads, it may not be a decision
we, in the Arch world, get to make. Too much of upstream may
actually be dictated by what a comercially-backed distro does.

On Tue, Aug 14, 2012 at 03:32:42PM +0200, Thomas B?chler wrote:
> And you don't want systemd because you are sure it won't do what
> sysvinit can, even though you didn't try it.
>

I think the complaint here is that the switch itself is a problem.

I think he made it rather clear that he's not criticizing systemd
itself but the notion of forcing a switch.

I've been bellowing to local linux user groups and friends that
sysvinit needs to go for years but I understand the general
resistance: Every change -- even the especially good and worthy
ones -- requires effort. For some, that's too much.

> Arch's policy on systemd vs. initscripts has not even been discussed
> among Arch developers yet...

This is really all that needed to be said.

On Tue, Aug 14, 2012 at 03:28:17PM +0200, Jelle van der Waa wrote:
> On 08/09/12 22:00, Anthony 'Ishpeck' Tedjamulia wrote:
> > I think what he was saying wasn't that systemd is hard but switching is hard irrespectively of what you're switching to.
> Because the devs made systemd being able to use rc.conf?

I'm just trying to clarify his actual argument so you can address
that rather than slaying the straw man.

You have to admit that the dev work does forebode the potential to
make it the default in the distro. Doesn't make it certain but I
don't think the certainty is what scares people.

> It takes less then a day to use systemd, but I am not forcing you to use it.

No, you'll never force me to do anything. As I said in this thread
already, I'm not using arch on my workhorse. I'm not worried about
it like some people are. I'm just trying to elevate the level of
discourse here.

On Tue, Aug 14, 2012 at 07:20:29PM +0530, gt wrote:
> Offtopic: Your system clock seems to be way off.

So it is! Thanks for the heads up.

On Mon, 13 Aug 2012 15:50:16 +0530
Jayesh Badwaik <jayesh.badwaik90@gmail.com> wrote:

> (Yes, udev on non-systemd systems is in our eyes a dead end, in case
> you haven't noticed it yet. I am looking forward to the day when we
> can drop that support entirely.)"

Lennart in topform again... Well if that's the official stance, then
it seems pretty clear that udev is going to be gone some day. Too bad,
we are either going to have to fork or look for an alternative to udev.
Alternatively we will all be running systemd one day whether we
want to or not I suspect that this has been the game plan all the
time though. OK, flames away I guess

---

Joakim

On Mon, Aug 13, 2012 at 12:34 PM, Joakim Hernberg <jbh@alchemy.lu> wrote:

> Too bad, we are either going to have to fork or look for an alternative to
> udev.
>

When upstream udev fails to live up to some distributions (see, Ubuntu, for
example) it *will* be forked.

Hopefully, udev-systemd and udev-ng (or whatever it is called) will not get
too different, so we have to learn how to write udev rules twice. I find it
difficult enough as it is now.

--
Rodrigo