FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 08-12-2012, 08:25 PM
Russ Allbery
 
Default choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)

Roger Leigh <rleigh@codelibre.net> writes:
> On Sun, Aug 12, 2012 at 09:01:38PM +0200, Carlos Alberto Lopez Perez 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 Poettering (lists.freedesktop.org)

> Not good. Time to look a bit more seriously at mdev then?

While there's certainly merit in that, we should probably also not
overreact to one statement from Lennart on a mailing list about something
that he hopes to do eventually, with no concrete plan or date.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 874no7vow7.fsf@windlord.stanford.edu">http://lists.debian.org/874no7vow7.fsf@windlord.stanford.edu
 
Old 08-12-2012, 08:50 PM
 
Default choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)

On Aug 12, Roger Leigh <rleigh@codelibre.net> wrote:

> Not good. Time to look a bit more seriously at mdev then?
Waste of time, mdev lacks critical features like modules autoloading so
it is laughable to argue that it is a credible udev replacement for
any use case except (some) embedded systems.

If the time will come the interested parties will fork udev, but let's
not overreact.

--
ciao,
Marco
 
Old 08-13-2012, 06:32 AM
Thomas Goirand
 
Default choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)

On 08/13/2012 04:50 AM, Marco d'Itri wrote:
> Waste of time, mdev lacks critical features like modules autoloading so
> it is laughable to argue that it is a credible udev replacement for
> any use case except (some) embedded systems.
>
> If the time will come the interested parties will fork udev, but let's
> not overreact.
>
Isn't forking udev something similar to working on mdev? How many people
would you have working on a udev fork, compared to the Gentoo guys
working on mdev *already*, freeing us from a hostile upstream?

At many level, udev has been really annoying, breaking upgrades and so on.

As one wrote previously: mdev and OpenRC lack hostile upstreams!
If there's some people working on a "credible udev replacement", please,
let's not laugh about it, and hope it soon integrates the needed features.
I salute those trying to help to move in this direction.

Let's also not forget that we have quite some time remaining until Jessie
will be released. Can't you give them a chance?

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50289F66.2050508@debian.org">http://lists.debian.org/50289F66.2050508@debian.org
 
Old 08-13-2012, 07:11 AM
Martin Wuertele
 
Default choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)

* Marco d'Itri <md@Linux.IT> [2012-08-11 11:30]:

> We are not dismissing any other alternative, upstart still looks like
> an option.
> We are dismissing just openrc because its incremental benefits are
> trivial.

You don't speak on behalf of the debian project so please refrein from
using "we" - you don't speak for me.

Thanks, Martin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120813071148.GJ10872@anguilla.debian.or.at">http ://lists.debian.org/20120813071148.GJ10872@anguilla.debian.or.at
 
Old 08-13-2012, 09:20 AM
 
Default choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)

On Aug 13, Thomas Goirand <zigo@debian.org> wrote:

> Isn't forking udev something similar to working on mdev? How many people
No, you just have to look at the code bases and features set to
understand why.

> At many level, udev has been really annoying, breaking upgrades and so on.
I can't help with you being annoyed by any package, sorry.

> As one wrote previously: mdev and OpenRC lack hostile upstreams!
They also lack solving large parts of the problem space.

--
ciao,
Marco
 
Old 08-13-2012, 11:43 AM
Thomas Goirand
 
Default choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)

On 08/13/2012 05:20 PM, Marco d'Itri wrote:
>> As one wrote previously: mdev and OpenRC lack hostile upstreams!
>>
> They also lack solving large parts of the problem space.
>
I don't think anyone denies that fact. Hopefully, this will change.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5028E854.6010209@debian.org">http://lists.debian.org/5028E854.6010209@debian.org
 
Old 08-13-2012, 10:54 PM
Michael Tokarev
 
Default choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)

On 13.08.2012 00:50, Marco d'Itri wrote:
> On Aug 12, Roger Leigh <rleigh@codelibre.net> wrote:
>
>> Not good. Time to look a bit more seriously at mdev then?
> Waste of time, mdev lacks critical features like modules autoloading so
> it is laughable to argue that it is a credible udev replacement for

It is laughable to argue that module autoloading is any more complex
than a call to `modprobe $MODALIAS'.

Thanks,

/mjt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5029859C.2090806@msgid.tls.msk.ru">http://lists.debian.org/5029859C.2090806@msgid.tls.msk.ru
 
Old 08-20-2012, 10:44 AM
Josselin Mouette
 
Default choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)

Le samedi 11 août 2012 * 15:38 -0400, Chris Knadle a écrit :
> systemd may seem better in /most/ cases because it does have some nice
> features, but I don't think it's better in *all* cases. systemd doesn't allow
> shutdown/reboot from within KDE4

In the beginning, ConsoleKit didn’t allow shutdown/reboot from within
KDE4.

Maybe one of the KDE maintainers will remind us how many lines did the
patch measure, but ISTR it’s less than 10.

--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1345459472.5401.34.camel@tomoyo
 
Old 08-20-2012, 02:36 PM
Adam Borowski
 
Default choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)

On Mon, Aug 20, 2012 at 12:44:32PM +0200, Josselin Mouette wrote:
> Le samedi 11 août 2012 * 15:38 -0400, Chris Knadle a écrit :
> > systemd may seem better in /most/ cases because it does have some nice
> > features, but I don't think it's better in *all* cases. systemd doesn't allow
> > shutdown/reboot from within KDE4
>
> In the beginning, ConsoleKit didn’t allow shutdown/reboot from within
> KDE4.
>
> Maybe one of the KDE maintainers will remind us how many lines did the
> patch measure, but ISTR it’s less than 10.

The version in wheezy is crawling with race conditions that make
shutdown/reboot attempts randomly fail, seemingly on any desktop environment
(I reproduced this on Gnome 3, XFCE, Mate, didn't try KDE). The fail
message claims shutdown is not allowed because multiple users are logged in.

I investigated the problem, and it turns out it would be pretty hard to fix,
certainly not in a matter of 10 lines. Currently, a shutdown/reboot
sequence:
* sends signals to your processes in the session (tty ones get SIGHUP)
* sends a request over dbus to consolekit
* if any process in the session is setuid/setgid and still alive, consolekit
responds with a failure
* a window asking for root's password is spawned; cancelling it will spawn
ANOTHER message box claiming shutdown is not allowed (which was already
mentioned in the root password question)

I see no obvious way to fix this -- merely waiting a bit longer is not going
to help as there's no bound on how long processes take to die on a
sufficiently loaded system[1]. And you can't tell a process that merely
takes some time to die from one like wget that handles the signal and
continues. One idea would be to display the authentication box but keep
repeatedly requesting shutdown while the box is up.


[1]. Especially ex-Windows users assume that a on a barely responsive
system, a shutdown attempt is more likely to succeed than trying to find and
kill the offender; in a GUI and for non-technical users that's not entirely
without merit. And then, the shutdown attempt will be hit by this race.

--
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition. For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623
 

Thread Tools




All times are GMT. The time now is 07:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org