On Thu, Aug 9, 2012 at 7:26 PM, G.Wolfe Woodbury <redwolfe@gmail.com> wrote:
> On 08/09/2012 07:12 PM, Olivier Crête wrote:
>> Can we also have a desktop that doesn't us X?
>
> That is NOT likely to happen. X Windows is about the only *nix
> windowing system around.
> There may be others, but their use is rare. Practically all the
> graphical interface software
> uses X and its addons.

/me looks down at my phone...

But whatever, you write it, you write an ebuild, and if you're
desperate I'll be happy to proxy maintain it for you. Last time I
checked svgalib was still in tree...

Rich

Canek Peláez Valdés wrote:
> So let people make their OpenRC+mdev systems without systemd, and let
> people make their systemd+udev systems without OpenRC. Everybody wins.

I for one expect nothing less of Gentoo.


//Peter

Yeah me too, and the best solution win then :P

2012/8/9 Peter Stuge <peter@stuge.se>

Canek Peláez Valdés wrote:

> So let people make their OpenRC+mdev systems without systemd, and let

> people make their systemd+udev systems without OpenRC. Everybody wins.



I for one expect nothing less of Gentoo.





//Peter





--
Salut
alp
Sylvain

Michał Górny posted on Thu, 09 Aug 2012 22:47:38 +0200 as excerpted:

> On Thu, 09 Aug 2012 22:30:02 +0200 Luca Barbato <lu_zero@gentoo.org>
> wrote:
>
>> On 08/09/2012 09:43 PM, Michał Górny wrote:
>>> On Thu, 09 Aug 2012 10:42:15 +0200 Luca Barbato <lu_zero@gentoo.org>
>>> wrote:

>>>> [W]e could discuss about why reinventing shellscript may
>>>> not be that sound and other less glaring, horrid and
>>>> appalling design choices.
>>>
>>> Yes, exactly. So why does openrc reinvent that horrible shellscript?
>>
>> It is not re-invented, in fact we can use any compatible shell.
>
> Or anything else what can be spawned for shell. And a lot more what you
> won't expect. And guess what, people are actually doing crazy things
> with it because someone forgot to tell them how a init.d script should
> work.

Sounds interesting. A couple quick links to examples of what you had in
mind would be nice. =:^)

(Or a bit more description, enough to both get the concept and google
with would be good, but links could be quicker if you have them handy,
and are less likely to spawn even further afield subthreads.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

ChÃ*-Thanh Christopher Nguyá»…n posted on Fri, 10 Aug 2012 01:26:53 +0200 as
excerpted:

> Olivier Crête schrieb:
>> Can we also have a desktop that doesn't use X?
>
> Yes, through Wayland or DirectFB.

<aol>Me too!</aol>

Seriously, they're working on it, ubuntu already has a target switch-to
date (tho it's predicted to slip, but it /does/ make for faster
progress), qt is planning to support it with qt5(point-something) and
preliminary support is there already, same with kde frameworks (aka kde5)
altho AFAIK it's mostly just kwin/plasma dev experiments ATM, and I
believe gnome support may actually be further along than kde, especially
with ubuntu pushing it, given that they still use the gnome foundations
with unity.

That's WAY farther along than any of the previous efforts toward
replacing X on (other than embedded/Android) Linux got, and it actually
looks like it's going to happen this time.

So give it a couple years, but it's coming.

Actually, wayland's exactly the thing I had in mind in my "five years"
post as the next likely "worldview disrupter". I think X will still be
around in five years, but it'll be "legacy" for many, maybe most. I
don't know that the full implications of the switch to wayland can be
predicted at this point, /I'm/ certainly not going to attempt it, and
it's quite possible that as a result of that shift, systemd will look as
"wrong solution for the wrong problem" as hal ended up looking. But the
only way to know is to live thru it and see where the experience takes us.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Fri, 10 Aug 2012 05:04:40 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Michał Górny posted on Thu, 09 Aug 2012 22:47:38 +0200 as excerpted:
>
> > On Thu, 09 Aug 2012 22:30:02 +0200 Luca Barbato <lu_zero@gentoo.org>
> > wrote:
> >
> >> On 08/09/2012 09:43 PM, Michał Górny wrote:
> >>> On Thu, 09 Aug 2012 10:42:15 +0200 Luca Barbato
> >>> <lu_zero@gentoo.org> wrote:
>
> >>>> [W]e could discuss about why reinventing shellscript may
> >>>> not be that sound and other less glaring, horrid and
> >>>> appalling design choices.
> >>>
> >>> Yes, exactly. So why does openrc reinvent that horrible
> >>> shellscript?
> >>
> >> It is not re-invented, in fact we can use any compatible shell.
> >
> > Or anything else what can be spawned for shell. And a lot more what
> > you won't expect. And guess what, people are actually doing crazy
> > things with it because someone forgot to tell them how a init.d
> > script should work.
>
> Sounds interesting. A couple quick links to examples of what you had
> in mind would be nice. =:^)
>
> (Or a bit more description, enough to both get the concept and google
> with would be good, but links could be quicker if you have them
> handy, and are less likely to spawn even further afield subthreads.)

vdr is a first example which comes to my mind. They workaround program
configuration limitations and the init.d scripts become a complex
extra-configuration parser + plugin loader. Well, another thing here is
that upstream AFAIK is not willing to cooperate to fix their config
parsing.

'oldnet' is an another example. I'm not saying it should go; I'm saying
it should be a stand-alone executable called from the init.d script.

Last time I looked, squid init.d was performing post-inst in start().
Many users may find that beneficial but that's not what init.d scripts
should be doing.

--
Best regards,
Michał Górny

On 08/10/2012 09:43 AM, Michał Górny wrote:
> vdr is a first example which comes to my mind. They workaround program
> configuration limitations and the init.d scripts become a complex
> extra-configuration parser + plugin loader. Well, another thing here is
> that upstream AFAIK is not willing to cooperate to fix their config
> parsing.
>
> 'oldnet' is an another example. I'm not saying it should go; I'm saying
> it should be a stand-alone executable called from the init.d script.
>
> Last time I looked, squid init.d was performing post-inst in start().
> Many users may find that beneficial but that's not what init.d scripts
> should be doing.

This discussion is really derailing.

Currently most people using certain features from openrc feel quite
defensive and mildly uneasy with the current situation since systemd is
pretty much swallowing components we used to rely on and force radical
changes w/out providing explanations to people that do not care and that
are perfectly happy with what they have.

Now Canek seems to feel like that I'm willing to kill systemd and make
it impossible to use it in Gentoo.

That's not the case, I consider systemd a bad idea since it is only
geared to solve some specific issues and does that in a way that I
consider dangerous for the global usage patterns I'm aware of.

systemd ideas are interesting and for a dumb linux desktop the
implementation would be ok.

systemd doesn't work in many scenarios and when it gets pointed
apparently there is a disagreement on that because "systemd is perfect"
like it happens with it gets pointed that pulseaudio has shortcomings
(that come from its design) or avahi doesn't seem that stable.

I can live with a seldom broken audio subsystem and I can cope with the
fact pidgin-bonjour could randomly crash, I'm not happy to be forced to
move to something with the same attitude as my init system.

The whole point of the debate should be if easier to have systemd split
itself in usable components so people with certain focuses could
leverage it on linux and replace those on non-linux (apparently not a
chance) or have what we currently have and works decently and hopefully
be compatible (so have a compatible interface for user-daemons, a
compatible dbus interface for the desktop integrations and so on), not
which project we should help to kill the others.


lu

On Fri, Aug 10, 2012 at 4:45 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> The whole point of the debate should be if easier to have systemd split
> itself in usable components so people with certain focuses could
> leverage it on linux and replace those on non-linux (apparently not a
> chance) or have what we currently have and works decently and hopefully
> be compatible (so have a compatible interface for user-daemons, a
> compatible dbus interface for the desktop integrations and so on), not
> which project we should help to kill the others.

I understand where you're coming from, but keep in mind that upstream
the debate is more along the lines of what else to integrate, not what
to split apart. There is also little interest in supporting non-linux
systems with systemd - I don't think anybody working on it uses
anything but linux, and I think one of their goals is to not be held
back by features not available elsewhere. That might make it more of
a niche solution, but it is a niche that probably includes almost all
of the boxes running a typical linux distro (servers, desktops, etc -
not toasters, phones, DVRs, etc). Things like Prefix or FreeBSD are a
very low in market share.

In any case, this list is really the wrong place for such a debate,
since nobody who has any power to change anything is listening. The
success/failure of systemd will have almost nothing to do with how
Gentoo adopts it, it is already moderately well-supported on Gentoo as
a non-default, and while there are concerns about how udev/etc is
packaged and where a few things are installing their files, for the
most part nothing is broken. Some purists are concerned that whatever
rc system they're not using is sticking files on their system that
don't do anything, and that they can't control this, and that seems to
be a fault with all of the options, and most of the packages in the
tree that install init scripts.

There is also quite a bit of people calling each other's babies ugly,
which isn't terribly productive or helpful for the community.

Rich

Michał Górny posted on Fri, 10 Aug 2012 09:43:26 +0200 as excerpted:

> On Fri, 10 Aug 2012 05:04:40 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>> Michał Górny posted on Thu, 09 Aug 2012 22:47:38 +0200 as excerpted:
>>
>> > Or anything else what can be spawned for shell. And a lot more what
>> > you won't expect. And guess what, people are actually doing crazy
>> > things with it because someone forgot to tell them how a init.d
>> > script should work.
>>
>> Sounds interesting. A couple quick links to examples of what you had
>> in mind would be nice. =:^)

> vdr is a first example which comes to my mind. They workaround program
> configuration limitations and the init.d scripts become a complex
> extra-configuration parser + plugin loader. Well, another thing here is
> that upstream AFAIK is not willing to cooperate to fix their config
> parsing.
>
> 'oldnet' is an another example. I'm not saying it should go; I'm saying
> it should be a stand-alone executable called from the init.d script.
>
> Last time I looked, squid init.d was performing post-inst in start().
> Many users may find that beneficial but that's not what init.d scripts
> should be doing.

Thanks.

(As I said my intent wasn't to start a subthread on it, but just to see
where you were going with the comment, as it was rather opaque to me as
it stood. Oldnet was an especially useful example here given that I run
openrc-9999 to more closely follow individual commits, and I've traced
and reported a few bugs in oldnet over the years. Now that I know where
that comment was going, I'll shutup and contemplate.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Il 07/08/2012 14:47, Sylvain Alain ha scritto:
Hi everyone, for a couple of months now, I see on the list some of
activities about OpenRC been ported to FreeBSD or OpenRC to Debian and
other stuff related to SystemD.


I have some basic questions about all that :

1. The SystemD and Udev projetcs are merged now, so what is the impact
on the Gentoo on a short term period ?

The answer is in the hand of others, I sincerely hope someone will fork


2. I saw on some lists that Gnome/Kde and Xfce plan to use some
SystemD API, so does it means that we will need to install SystemD
aside of OpenRC ?

It's not possible at the moment. systemd break non-systemd setups.



3. In a long term vision, can OpenRC still exist on a Gentoo
box(OpenRC might be able to boot the box then give the control to
SystemD/Udev for the rest of the boot process) or we will need to
migrate to SystemD to be able to use Gnome/Kde or Xfce ?
PID 1 has some own properties, but systemd can work at user privileges,
maybe


4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps
related to SystemD ? I don't understand why these desktops want to
depend on a specific Sysint....


Because starting daemons it's much more error prone than everyone
thinks, at least everyone which didn't become involved in coding for it.


And now my personal rant with some considerations, from memory, may be
not totally accurate.


Tried systemd (SD from now) the other day, as everyone knows it need to
rebuild some part of the system with the "systemd" use flag.
These things broke when not started by SD, for example pulseaudio, had
problems also with auto-mount possibly more not even noticed.


This box has 3 disk:
sda) ssd on sda for gentoo whole disk (not partitioned)
sd{b,c}) /home /srv /boot md raid 1

First problem udev/SD has is that it can't see all the file system
labels, for some reason it only see sda and sdb so it's able to partly
proceed in the boot sequence, mount / (root) but can't mount anything else.


After putting in fstab the real /dev paths (something really old siecle)
manually mount them with systemctl --ignore-deps (the name of the option
is different please bear with me) works but the dependancies are not
satisfied, for two reasons:
a) SD does not re-calculate it's deptree/services when exiting from
rescue shell, it still try to start the "virtual" services as fstab
would have never modified, a reboot is needed
b) since it does not work even after reboot, there must be something
else, but what? this bring us to the point


SD has mainly two things to debug boot `systemctl dump` and
`systemd-journal` but the very much magnified advantages of the binary
log^W journal are totally invisible in this case because it's
difficult^W nearly impossible even to understand WHAT failed to start,
not to mention WHY


the magnificient binary log^W^W journal is kept on tmpfs (in ram) so
it's not even available at boot in different situation.


every try needed many minutes because SD wait for a long timeout before
going to the rescue shell, gave up after few hours of try, upgrading
Vista SP0 to current needed less reboot and time.


But this has been beneficial because I've now realized few important
things that will be probably never disappear from SD and will be there
forever, things that make me think this stuff is really dangerous.


List of problems that will _never_ be fixed

- SD does not see anything else than systemd for boot.
Interaction with SD from a livecd, is difficult, almost all tools don't
work because SD is not running.
transported on remote server administration this is a *nightmare*,
various provider offer livecd like system which don't offer SD.
so no easy migration, no easy first install, every failure is
definitive, a no go


- the journal will never become simpler, can only grow, debugging things
in the shell will be nearly impossible for excess of data (and lack of
useful one if it continue this way)


- virtual/autogenerated services are and will be difficult to cope with,
impossible to disable


- every change in the early boot procedure will require reboot

- which sum to: SD will work until it work, when something does not will
be a royal pain to solve _and_ nothing else other than SD will be
available to alleviate the pain


difficult to accept for the desktop, impossible for the server.

written by someone which like _some_ of the SD stuff.