Re: systemd - some more considerations

[Matthias Urlichs]

Hi,

Norbert Preining:
> How is it possible that:
> * systemd maintainers (Kay Sievers) considers an obvious bug in
>   his code that locks out users something not in need to be cared
>   for?
>   https://bugs.freedesktop.org/show_bug.cgi?id=76935
> 
It's not "an obvious bug", it's primarily an issue of interpreting whether
a generic boot parameter like "debug" is intended for just the kernel, or
the whole system.

Linux has other programs (and a few kernel modules) whose equivalent of
verbose=999 will prevent them from working. That's not new. The question is
essentially whether requiring "systemd.log_target=null" (to exclude
systemd's debug output from the kernel log buffer) is reasonable.

If the maintainer regards this as a design issue which thus should not be
discussed in a bug report, that's their prerogative. Calling Kai a "d*ck"
over it (see comment#11) is not going to help.

I have no sympathy whatsover for people who complain about the systemd
team's hostility when *they* are the one who start the badmouthing.

> * systemd maintainers (Lennart Poettering) does not care for
>   segfaults in his code, even if it happens in pid 1.
>   https://bugs.freedesktop.org/show_bug.cgi?id=74589
> 
Oh come on. It's a nontrivial amount of work to reproduce that bug.

"Does not care for" is not at all the same as "is not willing to spend the
effort on something that's not one of his use cases and wants somebody else
to provide a patch".

"Does not care for" would be "is unwilling to accept a patch for this
problem". That's not what's happening.

> * several kernel maintainer propose (not completely serious, but
>   it shows the general opinion), to add
>   +   BUG_ON(!strcmp(current->comm, "systemd"));

URLs please.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: systemd - some more considerations

[Tollef Fog Heen]

]] Norbert Preining 

> Hi
> 
> recent discussions on lkml really made me rethink the systemd
> position.
> 
> How is it possible that:
> * systemd maintainers (Kay Sievers) considers an obvious bug in
>   his code that locks out users something not in need to be cared
>   for?
>   https://bugs.freedesktop.org/show_bug.cgi?id=76935

That's being moved to systemd.debug instead of overloading debug.

> * systemd maintainers (Lennart Poettering) does not care for
>   segfaults in his code, even if it happens in pid 1.
>   https://bugs.freedesktop.org/show_bug.cgi?id=74589

systemd needs cgroups, that's pretty well established.  Arguably, it
should die with a clearer message.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d2gyixug@xoog.err.no

Re: systemd - some more considerations

[Neil McGovern]

On Thu, Apr 03, 2014 at 11:12:12AM +0900, Norbert Preining wrote:
> Is this the upstream Debian wants to base its "life" on?
> 

According to the technical committee, and the lack of support for the
GR, the answer is yes.

If you don't like this answer, please put effort into doing the work to
provide a viable alternative, rather than bringing this issue up yet
again.

I, for one, consider this issue/decision to be closed already. Nothing
productive will come by revisiting this.

Neil
-- 


signature.asc
Description: Digital signature

Re: systemd - some more considerations

[Norbert Preining]

Hi Tollef,

On Thu, 03 Apr 2014, Tollef Fog Heen wrote:
> > https://bugs.freedesktop.org/show_bug.cgi?id=76935
> 
> That's being moved to systemd.debug instead of overloading debug.

Good news. And please make Kay excuse for his rudeness and ifgnorance.
Thanks for letting us know.
But why is that not mentioned in the bug report? What is systemd
maintainers approach to handling bugs??

> > * systemd maintainers (Lennart Poettering) does not care for
> >   segfaults in his code, even if it happens in pid 1.
> > https://bugs.freedesktop.org/show_bug.cgi?id=74589
> 
> systemd needs cgroups, that's pretty well established.  Arguably, it
> should die with a clearer message.

No, NO  NOO

*IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that.

All the best

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140403093342.gg17...@auth.logic.tuwien.ac.at

Re: systemd - some more considerations

[Norbert Preining]

Hi,

On Thu, 03 Apr 2014, Matthias Urlichs wrote:
> > https://bugs.freedesktop.org/show_bug.cgi?id=76935
> > 
> It's not "an obvious bug", it's primarily an issue of interpreting whether
> a generic boot parameter like "debug" is intended for just the kernel, or
> the whole system.
> 
> Linux has other programs (and a few kernel modules) whose equivalent of
> verbose=999 will prevent them from working. That's not new. The question is

Besides, they are not PID 1  don't divert attention.

> If the maintainer regards this as a design issue which thus should not be
> discussed in a bug report, that's their prerogative. Calling Kai a "d*ck"
> over it (see comment#11) is not going to help.

That is *exactely* the attitude that is dangerous. You are breaking
a system, or many system, but you consider it a design issue that
has to be discussed.

(you being systemd devs, in particular Kay)

See Linus response, and get back to reality
https://lkml.org/lkml/2014/4/2/420

> I have no sympathy whatsover for people who complain about the systemd
> team's hostility when *they* are the one who start the badmouthing.

WHAT? Did *you* read the bug report. The OP suggested several improvements
and discussions, and *only* after Kay refused to show even a *wink*
of *understanding*, several of the posters got angry at the ignorance
of Kay.

Who on earth is the bummer guy here?

Please *read* the bug report and before coming to completely wrong and
false conclusions.

> > * systemd maintainers (Lennart Poettering) does not care for
> >   segfaults in his code, even if it happens in pid 1.
> > https://bugs.freedesktop.org/show_bug.cgi?id=74589
> > 
> Oh come on. It's a nontrivial amount of work to reproduce that bug.

What??? Compiling a kernel with CONFIG_CGROUPS=n is 
*nontrivial* amount of work. You have a twisted impression of reality.

If foobar is developing a program for PID 1 that interacts so tightly
with the kernel, I *expect* that developer to have not one, but *many*
kernel running and testing at any point in time.

> > * several kernel maintainer propose (not completely serious, but
> >   it shows the general opinion), to add
> > +   BUG_ON(!strcmp(current->comm, "systemd"));
> 
> URLs please.

Ugg, https://lkml.org/lkml/2014/4/2/422 and follow ups.
I thought that has proliferated into the farest corners of the
internet by now. Followups supporting this idea, of course not 
100% serious, unfortunately.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140403093508.gh17...@auth.logic.tuwien.ac.at

Re: systemd - some more considerations

[Chow Loong Jin]

On Thu, Apr 03, 2014 at 10:41:45AM +0200, Matthias Urlichs wrote:
> Hi,
> [...]
> > * several kernel maintainer propose (not completely serious, but
> >   it shows the general opinion), to add
> > +   BUG_ON(!strcmp(current->comm, "systemd"));
> 
> URLs please.

http://marc.info/?l=linux-kernel&m=139646548927947&w=2

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Re: systemd - some more considerations

[Michael Banck]

Hi,

On Thu, Apr 03, 2014 at 05:41:21AM -0007, Cameron Norman wrote:
> This really is not something suitable for debian-devel, unless you
> are actually proposing a GR to re-choose the init system, which you
> do not seem to be doing.

GRs are also off-topic on -devel.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140403094247.ga17...@raptor.chemicalconnection.dyndns.org

Re: systemd - some more considerations

[Michael Banck]

Hi,

On Thu, Apr 03, 2014 at 10:41:45AM +0200, Matthias Urlichs wrote:
> Norbert Preining:
> > * several kernel maintainer propose (not completely serious, but
> >   it shows the general opinion), to add
> > +   BUG_ON(!strcmp(current->comm, "systemd"));
> 
> URLs please.

IIRC that's from Andrew Morton in reply to point #1 above.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140403094410.gb17...@raptor.chemicalconnection.dyndns.org

Re: systemd - some more considerations

[Tollef Fog Heen]

]] Norbert Preining 

> Hi Tollef,
> 
> On Thu, 03 Apr 2014, Tollef Fog Heen wrote:
> > >   https://bugs.freedesktop.org/show_bug.cgi?id=76935
> > 
> > That's being moved to systemd.debug instead of overloading debug.
> 
> Good news. And please make Kay excuse for his rudeness and ifgnorance.

Why on earth would I do that?  I'm not going to spend time and effort on
something like that.

> Thanks for letting us know.
> But why is that not mentioned in the bug report? What is systemd
> maintainers approach to handling bugs??

It's discussed on the development mailing list.

> > > * systemd maintainers (Lennart Poettering) does not care for
> > >   segfaults in his code, even if it happens in pid 1.
> > >   https://bugs.freedesktop.org/show_bug.cgi?id=74589
> > 
> > systemd needs cgroups, that's pretty well established.  Arguably, it
> > should die with a clearer message.
> 
> No, NO  NOO
> 
> *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that.

Am I understanding you correctly that you don't think there are any
situations where compiling out features from the kernel can lead to pid1
not working would be acceptable?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874n2aivk6@xoog.err.no

Re: systemd - some more considerations

[Fabian Greffrath]

Hi Norbert et al.,

> * systemd maintainers (Lennart Poettering) does not care for
>   segfaults in his code, even if it happens in pid 1.
>   https://bugs.freedesktop.org/show_bug.cgi?id=74589

to me his response does not read as if he didn't care. Systemd on
systems without cgroups has never been a supported configuration and is
thus not one that he will ever test, so he asks for a patch: 

> To make this work we'd need a patch, as nobody of us tests this

Nothing exceptional, IMHO.

 - Fabian



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1396518843.6930.6.ca...@kff50.ghi.rwth-aachen.de

Re: systemd - some more considerations

[Chow Loong Jin]

On Thu, Apr 03, 2014 at 06:33:42PM +0900, Norbert Preining wrote:
> Hi Tollef,
> 
> On Thu, 03 Apr 2014, Tollef Fog Heen wrote:
> > >   https://bugs.freedesktop.org/show_bug.cgi?id=76935
> > 
> > That's being moved to systemd.debug instead of overloading debug.
> 
> Good news. And please make Kay excuse for his rudeness and ifgnorance.
> Thanks for letting us know.
> But why is that not mentioned in the bug report? What is systemd
> maintainers approach to handling bugs??
> 
> > > * systemd maintainers (Lennart Poettering) does not care for
> > >   segfaults in his code, even if it happens in pid 1.
> > >   https://bugs.freedesktop.org/show_bug.cgi?id=74589
> > 
> > systemd needs cgroups, that's pretty well established.  Arguably, it
> > should die with a clearer message.
> 
> No, NO  NOO
> 
> *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that.

You could very well say the same thing about a 64-bit kernel dying on a 32-bit
system. SystemD depends on Linux precisely because of its cgroups integration.

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Re: systemd - some more considerations

[Bjørn Mork]

Tollef Fog Heen  writes:
> ]] Norbert Preining 
>
>> > systemd needs cgroups, that's pretty well established.  Arguably, it
>> > should die with a clearer message.
>> 
>> No, NO  NOO
>> 
>> *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that.
>
> Am I understanding you correctly that you don't think there are any
> situations where compiling out features from the kernel can lead to pid1
> not working would be acceptable?

The main problem is how you resolve the "not working".  Dying will never
a sane way to give up from pid 1.  Try exec'ing something else instead,
like a shell or a stripped down init not needing all those optional
kernel fatures.

And wrt the question about required kernel feaures: Why should the
systemd pid1 require more features than other init systems?  I have been
told before when complaining about putting additional complexity into
pid1 that this isn't true - that systemd really doesn't add dependencies
to pid1 compared to alternative init systems.  This doesn't seem to be
completely true.


Bjørn


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/877g768yhm@nemi.mork.no

Re: systemd - some more considerations

[Thomas Goirand]

On 04/03/2014 05:58 PM, Tollef Fog Heen wrote:
> Am I understanding you correctly that you don't think there are any
> situations where compiling out features from the kernel can lead to pid1
> not working would be acceptable?

I'd say the opposite way. Could you please explain in which case you
find it acceptable to *just crash*, and render the system completely
unusable, and possibly even not recoverable?!?

Even without cgroup support, the way to handle the situation, IMO, would
be to at least fall back to the shell with a comprehensive error message.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/533d4c20.7090...@debian.org

Re: --> APT's New Version <--

[Manoj Srivastava]

On Tue, Apr 01 2014, Andrew M.A. Cater wrote:

> On Tue, Apr 01, 2014 at 05:39:04PM +0200, The deity team wrote:
>> 
>> Who would have guessed that 16 years ago? Do you remember what you did
>> on the first April in 1998? What is the first thing you thought while
>> reading this mail? And most important of all: Have you mooed today?
>> 
>
> I think I was just pleased that I'd thought of the name and that Jason,
> Manoj and others had accepted it - it defused an almighty flamewar :)

Under protest. I still think it really ought to be called
 deity. Or one of 64 million other names used for it in south asia. I
 think those other names are equally apt.

manoj

-- 
It's amazing how many people you could be friends with if only they'd
make the first approach.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/87r45g33s1@glaurung.internal.golden-gryphon.com

Re: systemd - some more considerations

[Tollef Fog Heen]

]] Bjørn Mork 

> Tollef Fog Heen  writes:
> > ]] Norbert Preining 
> >
> >> > systemd needs cgroups, that's pretty well established.  Arguably, it
> >> > should die with a clearer message.
> >> 
> >> No, NO  NOO
> >> 
> >> *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that.
> >
> > Am I understanding you correctly that you don't think there are any
> > situations where compiling out features from the kernel can lead to pid1
> > not working would be acceptable?
> 
> The main problem is how you resolve the "not working".  Dying will never
> a sane way to give up from pid 1.  Try exec'ing something else instead,
> like a shell or a stripped down init not needing all those optional
> kernel fatures.

You're right that «how to resolve» is one part of the question.

It's not clear that execing a shell will fare you any better.  Virtual
consoles and serial ports are optional kernel features too, after all.

> And wrt the question about required kernel feaures: Why should the
> systemd pid1 require more features than other init systems?  I have been
> told before when complaining about putting additional complexity into
> pid1 that this isn't true - that systemd really doesn't add dependencies
> to pid1 compared to alternative init systems.  This doesn't seem to be
> completely true.

I'm not particularly interested in reiterating the entire discussion
here, I'm sure you'll find answers to why systemd requires the features
it does in #727708, git commit logs and mailing list archives.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r45eh7l5@xoog.err.no

Re: systemd - some more considerations

[Tollef Fog Heen]

]] Thomas Goirand 

> On 04/03/2014 05:58 PM, Tollef Fog Heen wrote:
> > Am I understanding you correctly that you don't think there are any
> > situations where compiling out features from the kernel can lead to pid1
> > not working would be acceptable?
> 
> I'd say the opposite way. Could you please explain in which case you
> find it acceptable to *just crash*, and render the system completely
> unusable, and possibly even not recoverable?!?

I don't believe I have said that.  «die» is not the same as «crash».

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbuqh7sg@xoog.err.no

Bug#743502: ITP: libip2location -- C library to query geolocation and other details of an IP

[Nahar P]

Package: wnpp
Severity: wishlist
Owner: Nahar P 

* Package name: libip2location
  Version : 6.0.2
  Upstream Author : Liew 
* URL : https://www.ip2location.com/downloads/c/
* License : GPL
  Programming Lang: C
  Description : C library to query geolocation and other details of an IP

 IP2Location C library enables the user to find the country, region, city,
 coordinates, zip code, time zone, ISP, domain name, connection type, area code,
 weather, MCC, MNC, mobile brand name, elevation and usage type that any IP
 address or hostname originates from. It has been optimized for speed and 
 memory utilization.
 This Package provides the header files and static libraries for development.

 The library had been there from 2005, is very stable and used by many people.
 They also have a opensource database to use with this library.
 I would like to maintain this package but would need a DD as sponsor. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140403134637.21187.12440.report...@earth.invothink.net

Re: systemd - some more considerations

[Matthias Urlichs]

Hi,

Tollef Fog Heen:
> I don't believe I have said that.  «die» is not the same as «crash».

If you're talking about PID1, the end result is the same.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: systemd - some more considerations

[Ben Hutchings]

On Thu, 2014-04-03 at 19:55 +0800, Thomas Goirand wrote:
> On 04/03/2014 05:58 PM, Tollef Fog Heen wrote:
> > Am I understanding you correctly that you don't think there are any
> > situations where compiling out features from the kernel can lead to pid1
> > not working would be acceptable?
> 
> I'd say the opposite way. Could you please explain in which case you
> find it acceptable to *just crash*, and render the system completely
> unusable, and possibly even not recoverable?

1. If the kernel is configured without a driver for the disk controller,
that happens.
2. If the kernel is configured without the filesystem for the root
partition, that happens.
3. If the kernel is configured without VT or block support, that
probably happens.
4. If the kernel is configured without networking support, the system
may boot but if it's a server it's unusable.
etc.

(I've had boot failures due to several of the above configuration
errors, while doing kernel development and trying to use a minimal
config.)

If cgroups are essential for init, why is this so different from any of
the above?

> Even without cgroup support, the way to handle the situation, IMO, would
> be to at least fall back to the shell with a comprehensive error message.

That would be better, though not much better.  You'll need either local
access or a remote serial console either to use the shell or to select a
fallback entry at the GRUB menu.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou


signature.asc
Description: This is a digitally signed message part

Re: systemd - some more considerations

[Marc Haber]

On Thu, 03 Apr 2014 16:39:29 +0100, Ben Hutchings
 wrote:
>On Thu, 2014-04-03 at 19:55 +0800, Thomas Goirand wrote:
>> On 04/03/2014 05:58 PM, Tollef Fog Heen wrote:
>> > Am I understanding you correctly that you don't think there are any
>> > situations where compiling out features from the kernel can lead to pid1
>> > not working would be acceptable?
>> 
>> I'd say the opposite way. Could you please explain in which case you
>> find it acceptable to *just crash*, and render the system completely
>> unusable, and possibly even not recoverable?
>
>1. If the kernel is configured without a driver for the disk controller,
>that happens.

It says "unable to mount root fs", which indicates what's going wrong.

>2. If the kernel is configured without the filesystem for the root
>partition, that happens.

It says "unable to mount root fs", which indicates what's going wrong.

>3. If the kernel is configured without VT or block support, that
>probably happens.

It says "unable to mount root fs", which indicates what's going wrong.

>4. If the kernel is configured without networking support, the system
>may boot but if it's a server it's unusable.

It comes up, one can log in on the console, one can debug and will
find out fast what's going on.

>If cgroups are essential for init, why is this so different from any of
>the above?

From what one reads in this thread, init segfaults if cgroups is not
available. This is unacceptable.

IMO, it would be just fine if it would say "kernel support for cgroups
not found" and die.

>> Even without cgroup support, the way to handle the situation, IMO, would
>> be to at least fall back to the shell with a comprehensive error message.
>
>That would be better, though not much better.  You'll need either local
>access or a remote serial console either to use the shell or to select a
>fallback entry at the GRUB menu.

A segfault will lead the debugging process in a totally false
direction.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1wvkqs-dj...@swivel.zugschlus.de

Re: systemd - some more considerations

[Steve Langasek]

On Thu, Apr 03, 2014 at 10:26:22AM +0100, Neil McGovern wrote:
> On Thu, Apr 03, 2014 at 11:12:12AM +0900, Norbert Preining wrote:
> > Is this the upstream Debian wants to base its "life" on?

> According to the technical committee, and the lack of support for the
> GR, the answer is yes.

The GR that was proposed was not about reversing the choice of default.  In
any case, the only conclusion we can draw from the lack of GR is that
developers have chosen not to have a GR to override the TC.

> If you don't like this answer, please put effort into doing the work to
> provide a viable alternative, rather than bringing this issue up yet
> again.

There absolutely are viable alternatives, regardless of which one the TC
happened to choose in a split decision.

This "our way is the right way" attitude from systemd is nothing new (cf. 
non-Linux portability) and should not be surprising to anyone involved; and
was a significant reason why I voted upstart above systemd at the TC.  But
as far as I'm concerned, this kerfuffle is too little, too late.  Maybe if
kernel upstream developers have such strong opinions on the choice of init
system, they should have engaged in the discussions with the distros
*before* everyone settled on systemd.

The avalanche has already started; it is too late for the pebbles to vote.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd - some more considerations

[Andrey Rahmatullin]

On Thu, Apr 03, 2014 at 06:23:36PM +0200, Marc Haber wrote:
> >> I'd say the opposite way. Could you please explain in which case you
> >> find it acceptable to *just crash*, and render the system completely
> >> unusable, and possibly even not recoverable?
> >
> >1. If the kernel is configured without a driver for the disk controller,
> >that happens.
> 
> It says "unable to mount root fs", which indicates what's going wrong.
> 
> >2. If the kernel is configured without the filesystem for the root
> >partition, that happens.
> 
> It says "unable to mount root fs", which indicates what's going wrong.
> 
> >3. If the kernel is configured without VT or block support, that
> >probably happens.
> 
> It says "unable to mount root fs", which indicates what's going wrong.
> 
> >4. If the kernel is configured without networking support, the system
> >may boot but if it's a server it's unusable.
> 
> It comes up, one can log in on the console, one can debug and will
> find out fast what's going on.
> 
> >If cgroups are essential for init, why is this so different from any of
> >the above?
> 
> From what one reads in this thread, init segfaults if cgroups is not
> available. This is unacceptable.
> 
> IMO, it would be just fine if it would say "kernel support for cgroups
> not found" and die.
https://lists.debian.org/87d2gyixug@xoog.err.no

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Debian default desktop environment

[Undefined User]

Hello,

I'm a Debian user for almost 8 years now and I've always supported the OS
on the internet, trying to bring more people to it.

The problem is that right now Debian project is changing its default
desktop environment, and I think that this is not a good move. Of course,
it all depends on where the project is aiming at, specially on which users.
But, for normal users, Gnome 3 is a way better experience than Xfce.

I'm not suggesting that Linux (in general) should "be a Windows". NOT AT
ALL. But Windows is the comparison for lots of newcomers, and Xfce looks a
lot like Windows 98. I'm sorry, but it does.

New users coming from Windows want a more dynamic and fluid desktop. And,
by the way, if the discussion is about computer resources, Gnome 3 helps on
"discovering" if your system can handle those new improvements. In my point
of view, installing Xfce as default desktop environment means ignoring the
fact that desktops are changing drastically, in a positive way, exactly
where Gnome 3 is going.

I had my first time at Gnome 3. At the beggining I was really confused. I
kept asking "what happened to Gnome?". I was lost there and very angry
about the changes. But I decided to try it before curse it. And I don't
want to change it anymore.

Now when I have to run Windows on my PC I always try the hotkeys and
hotspots that Gnome 3 brings and I really miss them. They help me a lot
when just surfing the internet or when I'm at work. And that is just one
point that I'm making.

It's all about getting used to it. People have to try it! Like I said, I
had the same feeling that a lot of people from the comunity does. It's just
normal. We don't like changes. But this one worth it.

So, in conclusion, when I suggest Debian for my friends, I prefer them to
install the system and end up with Gnome 3 than Xfce. The latter should
remain as it currently is: being an desktop environment alternative.

Thanks!

P.S.: Please, I ask the maintainers to forward this email to the correct
list if this is not the ideal place for this discussion/suggestion.

Felipe

Bug#743556: ITP: ruby-scrypt -- Ruby gem with native C extension for the scrypt password hashing algorithm

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: ruby-scrypt
  Version : 1.2.1
  Upstream Author : Patrick Hogan 
* URL : https://github.com/pbhogan/scrypt
* License : BSD
  Programming Lang: Ruby
  Description : Ruby gem with native C extension for the scrypt password 
hashing algorithm

 scrypt is an hash algorithm that was specifically designed to make it
 costly to perform large-scale custom hardware attacks by requiring
 large amounts of memory. It is used as an alternative to PBKDF2 or
 bcrypt.
 .
 ruby-scrypt provides a simple Ruby library to create and manage
 password hashes in a secure way and it works pretty similarly
 to ruby-bcrypt with a few minor differences, especially where the
 cost factor is concerned.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at
http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Re: ca-certificates: no more cacert.org certificates?!?

[Kevin Chadwick]

previously on this list Bas Wijnen contributed:

> On Tue, Apr 01, 2014 at 10:49:15PM +0100, Kevin Chadwick wrote:
> > >  I think at Debian we all agree that it would be a good
> > > thing if everything would be encrypted, so this is a very bad outcome.
> > 
> > I beg to differ I'm afraid. SSL should be used where it is required
> > otherwise you are opening the server upto DOS and as it is more
> > complex, bugs and exploits not to mention greater memory and cpu usage
> > in similar fashion to systemd.
> 
> That's a valid point.  I think all connections should be encrypted,
> unless the server admin knowingly disables the encryption.  Does that
> sound better?
> 
> What I would like to see, is that if someone new to making websites
> tries something, they will be using encrypted connections.  And if they
> start asking people to fill out personal data, they don't need to do
> anything extra to make sure it works right.
> 

Sorry but I still have to disagree as this shouldn't really but
certainly does still increase the chances of someone submitting data to
a site that doesn't care about the security of that data or have the
ability to look after it.

OTOH it would prevent wordpress logins being stolen so easily and ISPs
snooping, however I believe in solving specific problems not swapping
problems around, what do you know again like systemd due to it's multi
functional design or rather lack of it;-)

-- 
___

'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)

In Other Words - Don't design like polkit or systemd
___

I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.

(Kevin Chadwick)

___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/991243.53700...@smtp120.mail.ir2.yahoo.com

Re: default messaging/VoIP client for Debian 8/Jessie

[Kevin Chadwick]

previously on this list Russ Allbery contributed:

> > I guess you missed all the exploits in JAVA over the years and
> > especially last year where it was banned for long periods from all
> > browsers. To the point that the pressure is building on web hosts to
> > drop JAVA KVM clients completely.  
> 
> Most of the exploits in Java (I have no idea why you write the word in all
> caps)

Just from the logo, the one I see on Windows boxes as I don't really
see one anywhere else and avoid it wherever possible and which is the
correct stance to take for multiple reasons.

http://blog.trendmicro.com/trendlabs-security-intelligence/java-native-layer-exploits-going-up/

> are flaws in the sandbox security model.  While those are real
> vulnerabilities in the context of running untrusted Java applets
> downloaded from the network, they're not horribly interesting in the
> context of running trusted applications installed through normal signed
> apt repositories.
> 

Not horribly interesting isn't saying much and the rediculous number of
vulns on osvdb this year alone not to mention the bloatedness and
ability to run jars in such a complex beast outside the unix security
model by default is more than enough to rule out any default java apps
in I'm sure many peoples opinion. Heck CESG guidelines say to get rid of
small parsers like perl and shell access.


-- 
___

'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)

In Other Words - Don't design like polkit or systemd
___

I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.

(Kevin Chadwick)

___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/676094.53700...@smtp120.mail.ir2.yahoo.com

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Kevin Chadwick]

previously on this list Jan Gloser contributed:

Kev, the systemd design document says it all about the lack of design
with statements showing a clear lack of understanding. I would be
ashamed to call it a design document.

> I would also like to ask something the people who dislike systemd (as there
> seem to be more). I am not very proficient with such internals of debian,
> but you say things like systemd breaks things and systemd has no unified
> design and sytemd is possibly a security risk. But can you give some easily
> reproducible examples or setups, code samples, cucumber scenarios,
> whatever, that could clearly demonstrate how systemd breaks anything?

As systemd tries to do so much it is pointless as you simply get side
tracked when your arguments succeed or ironically get called trolls by
real trolls.

I will just say this

OpenBSDs /sbin/init.c is 1448 lines long

Systemds rediculously placed /usr/lib/systemd/systemd.c doesn't exist
but rather there is a directory with many files and just cgroup.c is
nearly 1000 lines long. So good luck evaluating all of that for your
next linux based system when quite clearly the devs don't know even
pid1 like the back of their hand due to having a segfault rather than
die in it. pid1 being potentially larger than your daemon would be quite
laughable too.

As even well audited code tends to have a bug per 1000 lines, is
having this much code permanently resident supposedly for all of
Linux never mind unix ecosystems that have served each other so well a
good design especially when linux is moving onto smaller and smaller
devices? Are the benefits worth it? Is it self managing and open to
competition. It is difficult to get a good design from a bad design.
Evolving /sbin/init simple functionality in the past resulted in
migration of code into the kernel and not the other way around.

Such a fundamental game changer with so much clouding the core
functionality in terms of pulling in so much really shouldn't be decided
by a 50/50 decision. Companies often require 75% or more for game
changing decisions.

> scenario, why not just migrate to Gentoo or BSD?

Gentoo means you have to build otherwise I would for the few things I
need linux for. Sabayon has moved to systemd and my system would have
broken recently because of systemd if I was using it. I use OpenBSD
wherever possible.

Things are often tested on debian or *buntu and the base is well
tested and hence my usage for offline development.

-- 
___

'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)

In Other Words - Don't design like polkit or systemd
___

I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.

(Kevin Chadwick)

___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/216266.53700...@smtp120.mail.ir2.yahoo.com

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Kevin Chadwick]

previously on this list The Wanderer contributed:

> I was explicitly referring to the point in the future when maintainers
> do stop providing traditional init scripts. This likely won't happen
> that fast, no, but I do think it's likely that it will happen - whether
> days after the jessie release or decades, or more likely something in
> between.

You know that's what Arch Linux devs said two months before banishing
init scripts to AUR where it wasn't even gpg signed.

-- 
___

'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)

In Other Words - Don't design like polkit or systemd
___

I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.

(Kevin Chadwick)

___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/695583.53700...@smtp120.mail.ir2.yahoo.com

Re: systemd - some more considerations

[Kevin Chadwick]

previously on this list Matthias Urlichs contributed:

> > I don't believe I have said that.  «die» is not the same as «crash».  
> 
> If you're talking about PID1, the end result is the same.

It is not because one is a foreseen issue and the other indicates a
lack of polish on PID1!

-- 
___

'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)

In Other Words - Don't design like polkit or systemd
___

I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.

(Kevin Chadwick)

___


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/199497.53700...@smtp120.mail.ir2.yahoo.com

Re: systemd - some more considerations

[Kevin Chadwick]

previously on this list Steve Langasek contributed:

> The avalanche has already started; it is too late for the pebbles to vote.

Winston Churchill said "It is never too late" a few times and I think
some of his quotes are quite fitting.

"A lie gets halfway around the world before the truth has a chance to
get its pants on."

"Men occasionally stumble over the truth, but most of them pick
themselves up and hurry off as if nothing has happened."

"You have enemies? Good. That means you´ve stood up for something,
sometime in your life."

"It has been said that democracy is the worst form of government
except all the others that have been tried."

"Never give in-never, never, never, never, in nothing great or small,
large or petty, never give in except to convictions of honour and good
sense. Never yield to force; never yield to the apparently overwhelming
might of the enemy."

And one that's funny to lighten the mood.

Lady Astor: "Winston, if I were your wife I´d put poison in your
coffee."

Winston Churchill: "Nancy, if I were your husband I´d drink it."

-- 
___

'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)

In Other Words - Don't design like polkit or systemd
___

I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.

(Kevin Chadwick)

___


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/679110.53700...@smtp120.mail.ir2.yahoo.com

Re: Debian default desktop environment

[Dmitry Smirnov]

On Thu, 3 Apr 2014 14:16:15 Undefined User wrote:
> The problem is that right now Debian project is changing its default
> desktop environment, and I think that this is not a good move. Of course,
> it all depends on where the project is aiming at, specially on which users.
> But, for normal users, Gnome 3 is a way better experience than Xfce.

I think Xfce is much better *default* desktop environment (DE) than Gnome.

As KDE fan I do not like Gnome. Those who forget to choose DE in installer 
(just like I did more than once) and end up with Xfce will have a lot less to 
remove from their systems shall they choose to use a different DE.

Faster installation is another good reason to stick with Xfce by default.

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B


signature.asc
Description: This is a digitally signed message part.

Re: Debian default desktop environment

[Stephen Allen]

On Fri, Apr 04, 2014 at 08:18:41AM +1100, Dmitry Smirnov wrote:
> On Thu, 3 Apr 2014 14:16:15 Undefined User wrote:
> > The problem is that right now Debian project is changing its default
> > desktop environment, and I think that this is not a good move. Of course,
> > it all depends on where the project is aiming at, specially on which users.
> > But, for normal users, Gnome 3 is a way better experience than Xfce.
> 
> I think Xfce is much better *default* desktop environment (DE) than Gnome.
> 
> As KDE fan I do not like Gnome. Those who forget to choose DE in installer 
> (just like I did more than once) and end up with Xfce will have a lot less to 
> remove from their systems shall they choose to use a different DE.
> 
> Faster installation is another good reason to stick with Xfce by default.

Disagree - Gnome 3 I would think for MOST users would be preferable.
Like the OP says Xfce4 is not desirable for most users coming from the
dark side or heck perhaps for most users on Linux that want a modern
desktop.
Like the OP - I didn't like Gnome-Shell at first, but after giving it a
month I really started enjoying it. It's also mature and being worked on
extensively. Not something one can say about Xfce4 at this point.

I think you're probably the exception to the rule.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140403234221.GC8047@Jessie

Deprecating/removing racoon/ipsec-tools from Debian GNU/Linux and racoon from Debian/kfreebsd

[Matt Grant]

Hi!

I am the maintainer of the raccon/ipsec-tools packages and I want to
review their relevance in modern Debian.

Systemd package support is the thing that pushed me over the edge about
this.  There are no systemd unit files at all for ipsec-tools/racoon
that I know of. Please advise me otherwise, and I will look at putting
them in the current package.

Proposal:

Deprecating/removing racoon/ipsec-tools  from Debian GNU/Linux and
racoon from Debian/kfreebsd.  Strongswan/Openswan are maintained and
have a superset of the racoon functionality, can run on Debian kFreeBSD
with setkey still being available to manipulate kernel IPSEC as root -
there would be no old racoon daemon running as root 

The issues are:

1) Security.  The racoon daemon has to run as root, with a lot of the
default GCC security flags turned off. 

2) Maintenance and Porting.  It is officially maintained as part of
NetBSD, but there is always a lot of work to get the code to compile on
Linux, especially if it is a later version of GCC than in Net BSD.
Quite often there are obscure API/binary ABI issues that are difficult
to solve due to the new code tending to be *BSD specific.

3) Linux setkey ioctl interface that ipsec-tools/racoon use is
deprecated.  ip xfrm encapsulates the full functionality of setkey using
the new Netlink IPSEC API, and Openswan/Strongswan do so to.

4) On Debian kFreeBSD, Strongswan/Openswan support the BSD setkey
ioctls, thus can be substituted for racoon, and operate more securely.

5) IPSEC protocols. racoon only does IKEv1, Strongswan/Openswan do IKEv1
and IKEv2

Against deprecation/removal:

1) racoon is what is used in MacOSX, and it is good to be compatible.

2) Keeping compatibility with old installs, not breaking IPSEC on
upgrade.

3) racoon is designed from the get-go to work with IPv6 Mobile IP
functionality.  Strongswan/Openswan can be used for MIPv6, but there are
some issues that have to be solved still.

4) racoon/setkey are native IPSEC implementations across FreeBSD,
NetBSD, Mac OSX, and Linux, and thus having it available give a 'just
works' IPSEC option. 

My main concern as maintainer are the security issues, with an old code
base running as root.

NB: racoon-tool was an effort to provide basic FreeSWAN like
functionality when racoon/setkey where the one true way to use the then
new Linux in kernel IPSEC stack.  Openswan and StrongSWAN are descended
from FreeSWAN, thus racoon-tool functionality is 99% fulfilled by using
Strongswan/Freeswan.

I am willing to co-maintain this package with other developers and
maintainers.  My belief is that there is likely a Debian kFreeBSD
developer/maintainer out there who would like to do this, and do a lot
of the work :-)

Could you please supply your comments and feed back on this.

Best Regards,

Matt Grant, Debian Developer


signature.asc
Description: This is a digitally signed message part

Work-needing packages report for Apr 4, 2014

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 570 (new: 5)
Total number of packages offered up for adoption: 135 (new: 1)
Total number of packages requested help for: 57 (new: 2)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   afpfs-ng (#743509), orphaned today
 Description: Client for the Apple Filing Protocol (AFP) (development
   files)
 Reverse Depends: afpfs-ng afpfs-ng-utils libafpclient-dev
 Installations reported by Popcon: 216

   firmware-crystalhd (#743514), orphaned today (non-free)
 Description: Crystal HD Video Decoder (firmware)
 Installations reported by Popcon: 205

   iceowl (#742948), orphaned 5 days ago
 Description: Standalone Calendar Application
 Reverse Depends: iceowl-l10n-bg iceowl-l10n-ca iceowl-l10n-cs
   iceowl-l10n-da iceowl-l10n-de iceowl-l10n-en-gb iceowl-l10n-es-ar
   iceowl-l10n-es-es iceowl-l10n-et iceowl-l10n-eu (27 more omitted)
 Installations reported by Popcon: 3954

   libnfs (#743510), orphaned today
 Description: NFS client library (development files)
 Reverse Depends: libnfs-dev
 Installations reported by Popcon: 1774

   libshairport (#743511), orphaned today
 Description: emulates an AirPort Express (development files)
 Reverse Depends: libshairport-dev
 Installations reported by Popcon: 1943

565 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   wide-dhcpv6 (#743176), offered 3 days ago
 Description: DHCPv6 server/client/relay agent
 Reverse Depends: netcfg
 Installations reported by Popcon: 164

134 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] libteam (#743212), requested 3 days ago
 Description: library for controlling team network device

[NEW] pulseaudio (#743303), requested 2 days ago
 Description: PulseAudio sound server
 Reverse Depends: aegisub aqualung audacious-plugins blueman
   cairo-dock-impulse-plug-in cinnamon empathy ffgtk fische fldigi (140
   more omitted)
 Installations reported by Popcon: 109994

   apt-xapian-index (#567955), requested 1522 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache fuss-launcher goplay packagesearch
 Installations reported by Popcon: 79492

   athcool (#278442), requested 3446 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 55

   balsa (#642906), requested 921 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 818

   cardstories (#624100), requested 1074 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 14

   chromium-browser (#583826), requested 1404 days ago
 Description: Chromium browser
 Reverse Depends: chromedriver chromium chromium-dbg chromium-l10n
   mozplugger
 Installations reported by Popcon: 25218

   cups (#532097), requested 1762 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client cups-core-drivers cups-daemon
   cups-dbg (62 more omitted)
 Installations reported by Popcon: 139007

   debtags (#567954), requested 1522 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2430

   fbcat (#565156), requested 1541 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 147

   freeipmi (#628062), requested 1043 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect
   freeipmi-tools libfreeipmi-dev libfreeipmi12 libipmiconsole-dev
   libipmiconsole2 libipmidetect-dev libipmidetect0 (3 more omitted)
 Installations reported by Popcon: 4714

   gnat-4.8 (#539562), requested 2184 days ago
 Description: help needed to execute test cases
 Reverse Depends: dh-ada-library gnat-4.8 gnat-4.8-sjlj libgnat-4.8
   libgnat-4.8-dbg libgnatprj4.8 libgnatprj4.8-dbg libgnatprj4.8-dev
   libgnatvsn4.8 libgnatvsn4.8-dbg (2 more omitted)
 Installations reported by Popcon: 104

   

Re: Debian default desktop environment

[Norbert Preining]

On Thu, 03 Apr 2014, Stephen Allen wrote:
> Like the OP - I didn't like Gnome-Shell at first, but after giving it a
> month I really started enjoying it. It's also mature and being worked on
> extensively. Not something one can say about Xfce4 at this point.
> 
> I think you're probably the exception to the rule.

No: I tried G3 for nearly a year - and finally have purged my laptop
of all traces if it. 

I don't go to rants about user interface design blocking me to do 
things I want to do etc etc etc.

XFCE is *by*far* superior to G3, IMNSHO

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140404011532.gi17...@auth.logic.tuwien.ac.at

Re: systemd - some more considerations

[Chow Loong Jin]

On Thu, Apr 03, 2014 at 11:58:17AM +0200, Tollef Fog Heen wrote:
> [...]
> Am I understanding you correctly that you don't think there are any
> situations where compiling out features from the kernel can lead to pid1
> not working would be acceptable?

For the record, there's CONFIG_BINFMT_SCRIPT, which when disabled, causes all
#! scripts to be run under /bin/sh unconditionally.

*everything* runs under /bin/sh, including Perl, Python, and Bash scripts.

sysvinit as pid1 still works, sure, but everything else doesn't, and you won't
even finish booting without that option set.

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature