On Mon, 13 Aug 2012 12:34:26 +0200
Joakim Hernberg <jbh@alchemy.lu> wrote:

> 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

Nobody to blame when we do not listen BSD folks and have jumped into
Linux's change-all-the-time game.


Sincerely,
Gour

--
A person is said to be established in self-realization and is called a
yogī [or mystic] when he is fully satisfied by virtue of acquired
knowledge and realization. Such a person is situated in transcendence
and is self-controlled. He sees everything — whether it be pebbles,
stones or gold — as the same.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

On 08/13/2012 07:50 AM, Gour wrote:

On Mon, 13 Aug 2012 12:34:26 +0200
Joakim Hernberg <jbh@alchemy.lu> wrote:


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

Nobody to blame when we do not listen BSD folks and have jumped into
Linux's change-all-the-time game.


Sincerely,
Gour



Yes looks like I will need to migrate to BSD

On Mon, Aug 13, 2012 at 03:50:16PM +0530, Jayesh Badwaik wrote:
> Hi,
>
> Another flame may start here, but I would like to present the following
> as a pure news, no opinions[1].
>
> Of course, after reading all the discussions on the mailing lists, my
> feeling after reading the link? Mwuhahahaha.
>
> Important quotes from the link ( which I hope do not alter the context
> of the post):
>
> "Well, we intent to continue to make it possible to run udevd outside of
> systemd. But that's about it. We will not polish that, or add new
> features to that or anything.
>
> OTOH we do polish behaviour of udev when used *within* systemd however,
> and that's our primary focus.
>
> And what we will certainly not do is compromise the uniform integration
> into systemd for some cosmetic improvements for non-systemd systems.
>
> (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.)"
>
> [1] http://lists.freedesktop.org/archives/systemd-devel/2012-
> August/006066.html

Lennart Poettering wants to control GNU/Linux, period. And, he has been
quite effective in furthering his goals through his "great" ideas.

I see that linus torvalds will have competition pretty soon on who gets
to be the overlord. Or maybe they can coexist, one in kernel land and
the other in userspace land

On Mon, 2012-08-13 at 19:11 +0530, gt wrote:
> On Mon, Aug 13, 2012 at 03:50:16PM +0530, Jayesh Badwaik wrote:
> > Hi,
> >
> > Another flame may start here, but I would like to present the following
> > as a pure news, no opinions[1].
> >
> > Of course, after reading all the discussions on the mailing lists, my
> > feeling after reading the link? Mwuhahahaha.
> >
> > Important quotes from the link ( which I hope do not alter the context
> > of the post):
> >
> > "Well, we intent to continue to make it possible to run udevd outside of
> > systemd. But that's about it. We will not polish that, or add new
> > features to that or anything.
> >
> > OTOH we do polish behaviour of udev when used *within* systemd however,
> > and that's our primary focus.
> >
> > And what we will certainly not do is compromise the uniform integration
> > into systemd for some cosmetic improvements for non-systemd systems.
> >
> > (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.)"
> >
> > [1] http://lists.freedesktop.org/archives/systemd-devel/2012-
> > August/006066.html
>
> Lennart Poettering wants to control GNU/Linux, period. And, he has been
> quite effective in furthering his goals through his "great" ideas.
>
> I see that linus torvalds will have competition pretty soon on who gets
> to be the overlord. Or maybe they can coexist, one in kernel land and
> the other in userspace land

Some time ago I called "Linux" "Lennux".

> I see that linus torvalds will have competition pretty soon on who gets
> to be the overlord. Or maybe they can coexist, one in kernel land and
> the other in userspace land

linus used to run binaries from his earliest days just to make sure
that they still worked and constantly iterates that anything new should
not break or remove features from userland (atleast until the screams
aren't so noisy). Pulse brought new (the driver likely being playing
music whilst playing games without apps being setup to use plugs could
have been fixed in alsa) but removed/broke stuff too. It's surely wrong
to get personal however and Pulse does fix a problem for many atleast
but he would have to be much more subtle to make it in kernel land.

It's said a fundamental problem with user space development is
that often new projects are started because feature X is easier when
starting from scratch and so your swapping rather than developing. Is
that the case here or was there a difficult problem in getting alsa to
work with multiple input sources at once by default or more likely was
the difficulty integrating audio distribution which very few actually
care about.

--
__________________________________________________ _____________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
__________________________________________________ _____________________

On Mon, Aug 13, 2012 at 10:31 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> It's said a fundamental problem with user space development is
> that often new projects are started because feature X is easier when
> starting from scratch and so your swapping rather than developing. Is
> that the case here or was there a difficult problem in getting alsa to
> work with multiple input sources at once by default or more likely was
> the difficulty integrating audio distribution which very few actually
> care about.

Pulseaudio was never meant to replace ALSA, it requires ALSA drivers
to run at all.... if anything it was a replacement for ESD et. al.

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

> Hi,
> *wall of text*

I, for one, welcome our new red hatted underlings.

On Mon, Aug 13, 2012 at 6:20 AM, Jayesh Badwaik
<jayesh.badwaik90@gmail.com> wrote:
> Another flame may start here, but I would like to present the following
> as a pure news, no opinions[1].

You're free to post this, but don't for one second pretend that it is
anything, but flame bait.

=-Jameson

On Thu, 2012-08-09 at 13:13 -0600, Anthony 'Ishpeck' Tedjamulia wrote:
> 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.

I suspect that BSD for artist that draw can be used, but for audio not.
Am I mistaken?

Regards,
Ralf

On Monday 13 Aug 2012 12:34:26 Joakim Hernberg wrote:
> On Mon, 13 Aug 2012 15:50:16 +0530
>
> 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

Wow, this sounds so much like a conspiracy theory. The fact is that the
people who write the code inevitably dictate which software is maintained,
based on their interests and convictions, and they're pretty much unanimous
that systemd is a better solution to the problem of booting and maintaining
daemons than the solution we currently have.

So yeah, I guess that's been the game plan all along: make booting and daemon
control more consistent, faster, and easier for most users to maintain.

Paul