Re: Maildir vs. mbox in Debian

[Andrei POPESCU]

On Jo, 29 nov 12, 11:35:44, Ivan Shmakov wrote:
> 
>   What are the estimates?  And wouldn't it be better to use some
>   kind of a specialized search engine if searching is deemed
>   “crucial”?  I guess that it may render the difference between
>   the formats somewhat irrelevant.

Something like notmuch for example.

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Bug#694698: ITP: ruby-libwebsocket -- Universal Ruby library to handle WebSocket protocol

[Vipin Nair]

Package: wnpp
Severity: wishlist
Owner: Vipin Nair 

* Package name: ruby-libwebsocket
  Version : 0.1.7.1
  Upstream Author : Bernard Potocki 
* URL : https://github.com/imanel/libwebsocket
* License : MIT/X
  Programming Lang: Ruby
  Description : Universal Ruby library to handle WebSocket protocol


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129100947.24567.21110.reportbug@localhost

Bug#694709: ITP: ruby-weblibsocket -- Universal Ruby library to handle WebSocket protocol

[Vipin Nair]

Package: wnpp
Severity: wishlist
Owner: Vipin Nair 

* Package name: ruby-weblibsocket
  Version : 0.7.1-1
  Upstream Author : Bernard Potocki 
* URL : http://github.com/imanel/libwebsocket
* License : MIT/X
  Programming Lang: Ruby
  Description : Universal Ruby library to handle WebSocket protocol


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129104903.25556.79943.reportbug@localhost

Re: the right bug severity in case of data corruption

[Christoph Anton Mitterer]

On Thu, 2012-11-29 at 08:23 +0100, Paul Gevers wrote:
> Icedove 10.0.10 (Wheezy, no custom configuration on that front) here.
Thunderbird is prone to the issue... and there are only few cases where
it doesn't occur...
Have a look at https://bugzilla.mozilla.org/show_bug.cgi?id=808450
especially my comment 25, which shows some cases where the issue would
not happen with TB.

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: the right bug severity in case of data corruption

[Vincent Lefevre]

On 2012-11-29 01:50:55 +0100, Christoph Anton Mitterer wrote:
> It's like a serious flaw would have been found in gzip and people would
> say... oh don't complain... there's already the much better/newer bzip2
> or xz.

There's a major difference. mbox is buggy by design. Even though
mboxrd attempts to fix some problems, there are still MUA's that
would show the added ">" in the body (one problem is that they
can't detect reliably which mbox format is used).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129140420.gc5...@xvii.vinc17.org

Re: Maildir vs. mbox in Debian

[Vincent Lefevre]

On 2012-11-29 01:28:37 +0100, Christoph Anton Mitterer wrote:
> But it also has disadvantages to the mbox formats which may be crucial
> for some people:
> - wasting a lot of storage, which can be significant even if you use
> small file systems block sizes...

This is a problem with the file system, not with maildir. Here's
an example of file system (though not for Unix) that was partly
optimized to avoid these block size problems:

  http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252efmt.txt

(just for the pleasure of citing mail from 1990 :)

Now, I would say that in general, the wasted space is small compared
to large attachments. And if you have only text and care about disk
space, you should consider a compressed format, not "pure mbox".

> - full text search will typically be slower, as one has to open/close
> many files

This depends. I index my archive mailbox with mairix, and with mairix,
it is better to use maildir as a search result is built with symlinks
instead of copying the individual mail messages.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129142033.gd5...@xvii.vinc17.org

Re: Really, about udev, not init sytsems

[Wouter Verhelst]

On Sun, Nov 25, 2012 at 04:03:21PM +0100, John Paul Adrian Glaubitz wrote:
> On Sun, Nov 25, 2012 at 10:52:58PM +0800, Thomas Goirand wrote:
> > On 11/25/2012 01:30 AM, John Paul Adrian Glaubitz wrote:
> > > Why? Why would you want to rip such low-level stuff apart?
> > 
> > Well, isn't it the opposite thing that is happening? "Such low-level
> > stuff" are being merged (with systemd+udev merge), they were
> > separated projects before.
> > 
> > So, I'd rather ask you: why would you want "such low-level stuff"
> > to merge, since some others like it separated (like for example,
> > to be able to have the choice of replacing one or another)?
> 
> Well, systemd and udev are developed by the same developers. Both
> daemons interact very closely and integration of the sources was the
> natural consequence.

udev and pulseaudio are developed by the same developers. Both daemons
interact very closely and integration of the sources was the natural
consequence.

glibc and the kernel is developed by the same group of companies. Both
interact very closely and integration of the sources was the natural
consequence.

Internet explorer and Windows are developed by the same company. Both
interact very closely and integration of the two was the natural
consequence.

I'm not sure I agree with any of those arguments.

> Yes, it makes it more difficult to use udev with a different init
> system, but again most people don't care
[citation needed]

> as long as the init system they have works reliable. And since udev is
> Linux-only anyway, I don't see a problem merging it with a Linux-only
> init system.

You're basing that statement on the premise that everyone agrees
switching the init system to systemd is fine, and that therefore merging
udev and systemd isn't a problem. This is false.

First, there are those among us who dislike systemd, for various
reasons. The fact that this thread exists, should prove that.

Second, there are distributions (like Ubuntu) who don't seem to have any
long- or near-term plans to move to systemd. Making them use systemd
just so they can continue to use udev seems fairly problematic.

> If it's so important to be able to choose such a low-level component
> as the init system, why aren't people demanding that you can choose
> different kernel stacks of choice? For example OSS4 instead of ALSA or
> the old Firewire stack instead of the new one?

Back when OSS was the only in-kernel option on Linux (2.4 and before,
IIRC), ALSA was developed alongside the kernel. Eventually it got
merged, as _an alternative_ inside the kernel. It's only fairly recent
that OSS support was dropped -- even if that's happened at all, of which
I'm not sure (and I don't care enough to check).

If you're going to merge udev and systemd, then suddenly such choice
becomes much more difficult. That's the problem here: that a technical
choice, which may or may not be the best (I really don't care at this
point) is forced upon people who don't care about those who disagree
with them.

udev took quite some time to be accepted by the community too, but now
it's probably fair to say that it has been. To try to couple that to
systemd sounds like a bad form of systemd advocacy to me.

Oh well, we'll see what the future brings, I suppose.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129142102.ga...@grep.be

Re: the right bug severity in case of data corruption

[Vincent Lefevre]

On 2012-11-29 01:39:57 +0100, Christoph Anton Mitterer wrote:
> On Wed, 2012-11-28 at 16:01 +0100, Vincent Lefevre wrote:
> > Even users of mboxo shouldn't even have a problem because in your
> > message the F of the "From " line is encoded in quoted-printable:
> > 
> > | =46rom blahhityblah Fri Jul  8 12:08:34 2011
> > | >From foobarbaz Fri Jul  8 12:08:34 2011
> > | >>From quux Fri Jul  8 12:08:34 2011
> But this is something that just some "friendly" MUAs do... it's in no
> way imposed by any standard to this kind of clever quoting

I know, but I was just saying that Adam's test (of the recipients'
mail system) was useless because his MUA (Mutt) avoids the problem
of having an unencoded "From " line.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129142424.ge5...@xvii.vinc17.org

Re: Really, about udev, not init sytsems

[Wouter Verhelst]

On Sun, Nov 25, 2012 at 06:49:45PM +0100, John Paul Adrian Glaubitz wrote:
> On Mon, Nov 26, 2012 at 01:08:31AM +0800, Thomas Goirand wrote:
> > Now, I may add, I have no will to discuss it with you
> > anyway, after reading you impose on my your
> > partitioning scheme, and would like me to use my
> > computer the way *YOU* think is best. That is, by
> > the way, the same attitude systemd upstream has.
> 
> Yes, you can do with *YOUR* computer whatever you want. You can paint
> it pink and attach nice flower stickers onto it. But that doesn't mean
> upstream or distribution developers always have to keep their software
> in the most flexible way so it would fit everybody. It's simply not
> feasible and wastes time and efforts sometimes.

Possibly.

Now if someone wants to fork the particular bits of upstream software so
making use of a separate /usr is still possible, even if you think it's
totally useless, are you going to stop them.

That's what this thread is about, really.

> It's pointless to put so much effort to support every single use
> case.

Why aren't we all using Windows, then?

[...]
-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129142421.gb...@grep.be

Re: Really, about udev, not init sytsems

[Wouter Verhelst]

On Sun, Nov 25, 2012 at 08:02:20PM +0100, John Paul Adrian Glaubitz wrote:
> On Mon, Nov 26, 2012 at 02:12:23AM +0800, Thomas Goirand wrote:
> > P.S: By the way, there's still an ongoing m68k porting effort. Please
> > respect
> > this work as well.
> 
> I've been a vivid Amiga user since 1991* and I still love these
> machines and I am supporting the efforts to get Debian back onto
> m68k. Yet, I do not think this should happen at all costs. There
> haven't been no new 68k processors for years, have there?

http://www.freescale.com/webapp/sps/site/homepage.jsp?code=PC68KCF

the most recent processor you can find there was released in January
2012.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129142840.gc...@grep.be

Re: Maildir vs. mbox in Debian

[Christoph Anton Mitterer]

On Thu, 2012-11-29 at 15:20 +0100, Vincent Lefevre wrote:
> On 2012-11-29 01:28:37 +0100, Christoph Anton Mitterer wrote:
> > But it also has disadvantages to the mbox formats which may be crucial
> > for some people:
> > - wasting a lot of storage, which can be significant even if you use
> > small file systems block sizes...
> This is a problem with the file system, not with maildir.
Well I don't think you can say that so easily... or at least not in
practise... cause all the major filesystems seem to have this "problem".
Even if you use Reiser3 - which has anyway issues - that packed mode has
it's other drawbacks...



>   http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252efmt.txt
> (just for the pleasure of citing mail from 1990 :)
:D


> Now, I would say that in general, the wasted space is small compared
> to large attachments. And if you have only text and care about disk
> space, you should consider a compressed format, not "pure mbox".
Well it's not that small:
http://dovecot.org/pipermail/dovecot/2012-October/069130.html


> This depends. I index my archive mailbox with mairix, and with mairix,
> it is better to use maildir as a search result is built with symlinks
> instead of copying the individual mail messages.
Do these tools (mairix, notmuch, etc.) also help with real full text
search? I just though they'd index some stuff.


Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Maildir vs. mbox in Debian

[Ryan Kavanagh]

On Thu, Nov 29, 2012 at 03:30:47PM +0100, Christoph Anton Mitterer wrote:
> Do these tools (mairix, notmuch, etc.) also help with real full text
> search? I just though they'd index some stuff.

I can't speak for mairix, etc., but notmuch can handle full text search.
To quote from notmuch-search-terms(7),

The search terms can consist of free-form text (and quoted phrases)
which will match all messages that contain all of the given
terms/phrases in the body, the subject, or any of the sender or
recipient headers.

Ryan

-- 
|_)|_/  Ryan Kavanagh |  GnuPG key
| \| \  http://ryanak.ca/ |  4A11C97A


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129143706.gh32...@upsilon.ryanak.ca

Re: Really, about udev, not init sytsems

[John Paul Adrian Glaubitz]

On Thu, Nov 29, 2012 at 03:21:02PM +0100, Wouter Verhelst wrote:
> > Well, systemd and udev are developed by the same developers. Both
> > daemons interact very closely and integration of the sources was the
> > natural consequence.
> 
> udev and pulseaudio are developed by the same developers. Both daemons
> interact very closely and integration of the sources was the natural
> consequence.
> 
> glibc and the kernel is developed by the same group of companies. Both
> interact very closely and integration of the sources was the natural
> consequence.
> 
> Internet explorer and Windows are developed by the same company. Both
> interact very closely and integration of the two was the natural
> consequence.
> 
> I'm not sure I agree with any of those arguments.

Ok, I should have added that both udev and systemd are also very
closely related. So there are certainly benefits of merging the code.

As I already mentioned somewhere else, FreeBSD has the same approach
with their kernel and the basic userland. Doesn't the FreeBSD source
even include some games?

> > Yes, it makes it more difficult to use udev with a different init
> > system, but again most people don't care
> [citation needed]

Well, it's obvious, isn't it? I mean, I am talking about the average
joe. I didn't hear anyone complain when Apple switched to launchd in
10.4 and I have really never ever people arguing about what init
daemon is the best until systemd came up. I can't get rid of the
impression that the rejection of systemd is solely based on technical
merits.

> > as long as the init system they have works reliable. And since udev is
> > Linux-only anyway, I don't see a problem merging it with a Linux-only
> > init system.
> 
> You're basing that statement on the premise that everyone agrees
> switching the init system to systemd is fine, and that therefore merging
> udev and systemd isn't a problem. This is false.
> 
> First, there are those among us who dislike systemd, for various
> reasons. The fact that this thread exists, should prove that.

Again, I am constantly asking here what these reasons might be and yet
people always come with strawman arguments. I mean, seriously we had
the discussion that systemd is a bad design because it uses the same
configuration file syntax as Windows ini files or XDG .desktop files,
adding the statement that these are too difficult to parse.

The only valid argument I have seen so far against systemd is the fact
that it doesn't support non-Linux kernels. But this is true for
upstart as well. Plus, there are already efforts to get a
systemd-unit-file-to-sysvinit converter running. So, the BSD and Hurd
fans are not completely left outside. There is other stuff in Debian
as well which won't work on these kernels after all (like udevd).
 
> Second, there are distributions (like Ubuntu) who don't seem to have any
> long- or near-term plans to move to systemd. Making them use systemd
> just so they can continue to use udev seems fairly problematic.

Well, but I would say Ubuntu is to be blamed here. As opposed to
upstart, systemd has many supporters and contributors in the industry
(Intel, ProFusion, SuSE, RedHat) while upstart is virtually only
actively developed by Canonical if am I not mistaken. Plus, you have
to sign a contributor's agreement with Canonical which leaves a bad
taste in my mouth. That shouldn't be the case with true free software,
should it?

> > If it's so important to be able to choose such a low-level component
> > as the init system, why aren't people demanding that you can choose
> > different kernel stacks of choice? For example OSS4 instead of ALSA or
> > the old Firewire stack instead of the new one?
> 
> Back when OSS was the only in-kernel option on Linux (2.4 and before,
> IIRC), ALSA was developed alongside the kernel. Eventually it got
> merged, as _an alternative_ inside the kernel. It's only fairly recent
> that OSS support was dropped -- even if that's happened at all, of which
> I'm not sure (and I don't care enough to check).

Yes, but ALSA was so quickly adopted that very shortly after no one
really cared about OSS anymore. I was rather surprised that it took so
long to be completely abandoned. It was virtually only there to
support sound cards which had no ALSA drivers yet, didn't it?

> If you're going to merge udev and systemd, then suddenly such choice
> becomes much more difficult. That's the problem here: that a technical
> choice, which may or may not be the best (I really don't care at this
> point) is forced upon people who don't care about those who disagree
> with them.

Sure, I don't disagree on this point. But again, don't you think it
makes sense to got into that direction when the adoption rate of a
certain software is high?

I mean, just look at the popcon numbers for systemd vs upstart:

> http://qa.debian.org/popcon-graph.php?packages=systemd
> http://qa.debian.org/popcon-graph.php?packages=upstart

> udev took quite some time to be accepted by the com

Re: the right bug severity in case of mbox formats

[Vincent Lefevre]

On 2012-11-29 01:49:55 +0100, Christoph Anton Mitterer wrote:
> On Wed, 2012-11-28 at 22:06 +, Darren Salt wrote:
> > It would make sense to have that enabled by default, and to ensure
> > that all software in Debian which produces MIME quoted-printable
> > does this, or at least can do this.
> I agree... but let me add a few notes:
> 
> 1) Most programs I know of (at least Evolution, haven't checked mutt
> yet) that do this =46rom encoding do it completely wrong... why?
> 
> Just quoting (regexp) "^From (.*)$" lines to "=46rom \1" is obviously
> not enough.
> One also needs to quote "^>(>*)From (.*)$" lines to "=3E\1From \2"...
> otherwise clients could again wrongfully unquote such lines...

MUA's should not attempt to remove these quotes *unless* they know
there are using mboxrd. So, I don't see any problem with the current
behavior.

Note: the F encoding may be necessary because mboxo generation
corrupts the mail body (and it is done by the sender just in
case the recipient uses mboxo, in order to avoid a corruption
at this side). But there is no corruption with mboxrd.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129144257.gf5...@xvii.vinc17.org

Bug#694724: ITP: libb64 -- base64 encoding/decoding library

[Jakub Wilk]

Package: wnpp
Severity: wishlist
Owner: Jakub Wilk 

* Package name: libb64
  Version : 1.2
  Upstream Author : Chris Venter 
* URL : http://libb64.sourceforge.net/
* License : none (the code has been placed in the public domain)
  Programming Lang: C, C++
  Description : base64 encoding/decoding library

libb64 is a library of ANSI C routines for fast encoding/decoding data 
into and from a base64-encoded format. C++ wrappers are included.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129144246.ga...@jwilk.net

Re: Canonical pushes upstart into user session - systemd developer complains

[Wouter Verhelst]

On Mon, Nov 26, 2012 at 05:00:14PM +0100, Vincent Lefevre wrote:
> On 2012-11-26 07:27:08 +0900, Norbert Preining wrote:
> > Ever heard of 
> > grep, sed, awk, 
> > all these nice things that make your life happy.
> 
> These tools are broken when dealing with multibyte characters.

No they're not.

> For instance, with:
> 
> foo = aéb
> 
> a "grep 'a.b' file" will find nothing in the C locale.

But it will in a UTF8 locale, or in an ISO-8859-1 locale, for instance.
In a C locale, the é character simply does not exist, so you can't enter
it. If you entered it in a UTF8 locale and then switched to a C locale
to try to parse it, that can't work. It'd be like if you said
 > No please - I don't mind the key = value in group config format, that
> > is readable, usefull, easy to edit.
> 
> I disagree about "readable", except on small files. For instance,
> in the default .subversion/config file, the group names are lost
> among the comments.

The default .subversion/config file is a piece of documentation, not a
configuration file. I agree that there's far too much noise in there.
However, that's not a flaw of the format, it's a flaw of the subversion
default config file.

> And this format is also easy to break without noticing the breakage.

That claim is true for any structured file format, including XML.

> > Everything but XML. *EVERYTHING*.
> 
> This is your opinion. I disagree. XML is nice for things like
> validation and complex operations. XML is easy (easier) to edit
> if you use the "right" tools.

XML is great for the things it was made for, but it's not a very useful
configuration file format. XML requires far too much noise to be put in
the config file for that.

In addition, your implicit claim that it's difficult to validate
ini-style configuration files, or to do complex operations on them, is
just false. There are plenty of libraries to parse .ini files, too, for
instance.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129144635.gd...@grep.be

Re: Really, about udev, not init sytsems (was: Gentoo guys starting a fork of udev)

[Wookey]

+++ John Paul Adrian Glaubitz [2012-11-24 18:30 +0100]:
> 
> 
> On Sat, Nov 24, 2012 at 06:03:02PM +0100, Toni Mueller wrote: 
> > On Sat, Nov 24, 2012 at 05:15:25PM +0100, John Paul Adrian Glaubitz wrote:
> > > If both Ubuntu and Gentoo would just go with the rest of the community
> > > and accept systemd, we wouldn't have to bother whether udev runs
> > > without systemd or not.
> > 
> > I would highly prefer a system where I can take small bites if I want
> > to, and where components are as portable as possible
> 
> Why? Why would you want to rip such low-level stuff apart? It
> seriously doesn't make any sense unless you need a highly-customized
> setup, for embedded applications, for example.

Right. Exactly. You have a very 'desktoppy' view of the world.
Embedded people have been using different init systems for years, and
sometimes running without udev entirely, and different
device-configuration schemes. This stuff matters, and making bigger
monolithic pieces is, in general, not helpful. 

> When you have something
> such low-level, you're best off with taking the best solution which
> is clearly systemd 

I don't think everyone agrees that this is at all clear.

> I'm sorry for the harsh tone, but it's really something that annoys
> me, people constantly complaining about systemd but never really
> coming up with good arguments why something as low-level as
> systemd/udev should be replacable in the first place. 95% of the users
> don't care and just want something that's reliable.

95% of _desktop_ users, which is a tiny fraction of _linux_ users.
Your perspective is highly skewed. Linux is a very wide ecosystem,
with many many use cases. Who are you to tell all those people that
they are wrong to want/need to use udev without systemd, or indeed use
something other than systemd for their init process?

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129145155.gm9...@stoneboat.aleph1.co.uk

Re: Really, about udev, not init sytsems

[Josselin Mouette]

Le jeudi 29 novembre 2012 à 15:24 +0100, Wouter Verhelst a écrit : 
> Now if someone wants to fork the particular bits of upstream software so
> making use of a separate /usr is still possible, even if you think it's
> totally useless, are you going to stop them.

Wouter, I think higher of you than someone who’d bring again the /usr
argument which has already been debunked to death.

There are valid arguments for forking udev, but /usr support is not one
of them; we will just move /usr mounting to the initrd if it cannot be
mounted later.

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1354201085.30332.2.camel@tomoyo

Re: Maildir vs. mbox in Debian

[Vincent Lefevre]

On 2012-11-29 15:30:47 +0100, Christoph Anton Mitterer wrote:
> On Thu, 2012-11-29 at 15:20 +0100, Vincent Lefevre wrote:
> > Now, I would say that in general, the wasted space is small compared
> > to large attachments. And if you have only text and care about disk
> > space, you should consider a compressed format, not "pure mbox".
> Well it's not that small:
> http://dovecot.org/pipermail/dovecot/2012-October/069130.html

So, around 10% on this example. Not really significant. If these 10%
are a problem, I would also consider other means, such as compressing
the mailbox (one can gain 50% or more) and/or removing "useless"
headers.

> > This depends. I index my archive mailbox with mairix, and with mairix,
> > it is better to use maildir as a search result is built with symlinks
> > instead of copying the individual mail messages.
> Do these tools (mairix, notmuch, etc.) also help with real full text
> search? I just though they'd index some stuff.

If by real full text, you mean a sequence of words, a solution is
to search one or two meaningful words with mairix (this should be
very fast), then do a full search on the resulting mailbox (which
should be small enough). This might also be scripted...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129150527.gg5...@xvii.vinc17.org

Re: Maildir vs. mbox in Debian

[Adam Borowski]

On Thu, Nov 29, 2012 at 03:20:34PM +0100, Vincent Lefevre wrote:
> On 2012-11-29 01:28:37 +0100, Christoph Anton Mitterer wrote:
> > But it also has disadvantages to the mbox formats which may be crucial
> > for some people:
> > - wasting a lot of storage, which can be significant even if you use
> > small file systems block sizes...
> 
> This is a problem with the file system, not with maildir. Here's
> an example of file system (though not for Unix) that was partly
> optimized to avoid these block size problems:
> 
>   http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252efmt.txt
> 
> (just for the pleasure of citing mail from 1990 :)
> 
> Now, I would say that in general, the wasted space is small compared
> to large attachments. And if you have only text and care about disk
> space, you should consider a compressed format, not "pure mbox".

*cough* btrfs -ocompress=lzo.  Small files are packed inline in metadata
blocks, and you get compression you wanted.  Using lzo is faster than no
compression for most loads, adding negligible cost for incompressible data
(especially if not all cores are at 100% usage).

-- 
How to squander your resources: those silly Swedes have a sauce named
"hovmästarsås", the best thing ever to put on cheese, yet they waste it
solely on mere salmon.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129151625.ga20...@angband.pl

Re: Canonical pushes upstart into user session - systemd developer complains

[Vincent Lefevre]

On 2012-11-29 15:46:35 +0100, Wouter Verhelst wrote:
> On Mon, Nov 26, 2012 at 05:00:14PM +0100, Vincent Lefevre wrote:
> > On 2012-11-26 07:27:08 +0900, Norbert Preining wrote:
> > > Ever heard of 
> > >   grep, sed, awk, 
> > > all these nice things that make your life happy.
> > 
> > These tools are broken when dealing with multibyte characters.
> 
> No they're not.
> 
> > For instance, with:
> > 
> > foo = aéb
> > 
> > a "grep 'a.b' file" will find nothing in the C locale.
> 
> But it will in a UTF8 locale,

Unfortunately the C locale is the only really portable one.

> or in an ISO-8859-1 locale, for instance.
> In a C locale, the é character simply does not exist, so you can't enter
> it.

The config file may have been generated under some locale (or in
an application where locales are ignored or can be ignored, say
GNU Emacs), but scripts may run in other locales, in particular C
for more portability.

> If you entered it in a UTF8 locale and then switched to a C locale
> to try to parse it, that can't work.

There's no such problem with XML, where the encoding of the documents
are handled internally and locales do not matter. So, one can handle
XML whatever the environment. Let's get back to XML?

> The default .subversion/config file is a piece of documentation, not a
> configuration file. I agree that there's far too much noise in there.
> However, that's not a flaw of the format, it's a flaw of the subversion
> default config file.

But comments may be useful, and again, there's no such problem
with XML. XML tools can hide comments and so on. So, you have
config and the documentation at the same place, which is fine.

> > And this format is also easy to break without noticing the breakage.
> 
> That claim is true for any structured file format, including XML.

Less likely with XML, because of validation (you have well-formedness
checking in standard, without anything special to write). This is from
my experience.

> > > Everything but XML. *EVERYTHING*.
> > 
> > This is your opinion. I disagree. XML is nice for things like
> > validation and complex operations. XML is easy (easier) to edit
> > if you use the "right" tools.
> 
> XML is great for the things it was made for, but it's not a very useful
> configuration file format. XML requires far too much noise to be put in
> the config file for that.

This verbosity, or redundancy (I wouldn't call that noise), is
useful to avoid some form of undetected breakage. That's a choice.

> In addition, your implicit claim that it's difficult to validate
> ini-style configuration files, or to do complex operations on them, is
> just false. There are plenty of libraries to parse .ini files, too, for
> instance.

And interfaces in various programming languages?
And command-line tools?

The advantage of XML is that it is more common.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129152303.gh5...@xvii.vinc17.org

Re: the right bug severity in case of data corruption

[Vincent Lefevre]

On 2012-11-29 06:43:06 +, Ian Campbell wrote:
> On Wed, 2012-11-28 at 16:06 -0500, Nikolaus Rath wrote:
> > Darren Salt  writes:
> > > (Oops. Failed first time.)
> > >
> > > Having just viewed the raw text of my message (as sent), there's one other
> > > little wrinkle which I already knew but had failed to consider and which
> > > makes testing of this useless: gpg handles any 'From ' lines itself in a
> > > reversible manner, using '- ' as the prefix.
> > >
> > > The following SHOULD be 0, 1, and 2 levels of quoting, first to last.
> > >
> > >>From blahhityblah Fri Jul  8 12:08:34 2011
> > >>From foobarbaz Fri Jul  8 12:08:34 2011
> > >>>From quux Fri Jul  8 12:08:34 2011
> > 
> > This is looking different here,
> 
> Me too

Me too.

> > but I am not using any mbox* at all...
> 
> Me neither, AFAIK. I'm using Exim, with procmail delivering into Maildir
> and Courier imap to read it.
> 
> The MISCELLANEOUS section of procmail(1) makes me wonder if this might
> be procmail's doing. At the very least the conditions where it will do
> From encoding are too complex for me to grok at this time of day ;-)

Definitely neither procmail, nor postfix: I've sent a mail to myself
with a "From " (not using QP -- checked that) at the beginning of
the line, and everything was fine. The problem may come from the
mailing-list software.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129152924.gj5...@xvii.vinc17.org

Re: Maildir vs. mbox in Debian

[Andrey Rahmatullin]

On Thu, Nov 29, 2012 at 04:16:25PM +0100, Adam Borowski wrote:
> *cough* btrfs -ocompress=lzo.  Small files are packed inline in metadata
> blocks, and you get compression you wanted.  
It's nice to see more features from '93 Windows NT implemented for Linux
at last.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Maildir vs. mbox in Debian

[Vincent Lefevre]

On 2012-11-29 16:16:25 +0100, Adam Borowski wrote:
> *cough* btrfs -ocompress=lzo.  Small files are packed inline in metadata
> blocks, and you get compression you wanted.  Using lzo is faster than no
> compression for most loads, adding negligible cost for incompressible data
> (especially if not all cores are at 100% usage).

Great! Nice to know.

This should be the default in Debian. :)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129153233.gk5...@xvii.vinc17.org

Re: Canonical pushes upstart into user session - systemd developer complains

[Andrey Rahmatullin]

On Thu, Nov 29, 2012 at 04:23:03PM +0100, Vincent Lefevre wrote:
> > The default .subversion/config file is a piece of documentation, not a
> > configuration file. I agree that there's far too much noise in there.
> > However, that's not a flaw of the format, it's a flaw of the subversion
> > default config file.
> But comments may be useful, and again, there's no such problem
> with XML. XML tools can hide comments and so on. So, you have
> config and the documentation at the same place, which is fine.
Imagine a ".ini tool" that can fold #-comments.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Canonical pushes upstart into user session - systemd developer complains

[Vincent Lefevre]

On 2012-11-29 21:33:37 +0600, Andrey Rahmatullin wrote:
> On Thu, Nov 29, 2012 at 04:23:03PM +0100, Vincent Lefevre wrote:
> > > The default .subversion/config file is a piece of documentation, not a
> > > configuration file. I agree that there's far too much noise in there.
> > > However, that's not a flaw of the format, it's a flaw of the subversion
> > > default config file.
> > But comments may be useful, and again, there's no such problem
> > with XML. XML tools can hide comments and so on. So, you have
> > config and the documentation at the same place, which is fine.
> Imagine a ".ini tool" that can fold #-comments.

Yes. But remember that the detractors of XML say that you need
tools to handle it in a nice way.

BTW, about the readability:

ini format:

[section1]
key1=val1
key2=val2

[section2]
foo=bar

XML format:


  
val1
val2
  
  
bar
  


It is more verbose, but I find it as readable (if you have characters
that normally need to be escaped, you can still use CDATA sections,
which is a way to keep the readability).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129154407.gl5...@xvii.vinc17.org

Re: Really, about udev, not init sytsems |Subject: Re: Really, about udev

[Harald Jenny]

Dear Adrian

On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote:
> 
> Again, I am constantly asking here what these reasons might be and yet
> people always come with strawman arguments. I mean, seriously we had
> the discussion that systemd is a bad design because it uses the same
> configuration file syntax as Windows ini files or XDG .desktop files,
> adding the statement that these are too difficult to parse.
> 
> The only valid argument I have seen so far against systemd is the fact
> that it doesn't support non-Linux kernels. But this is true for
> upstart as well. Plus, there are already efforts to get a
> systemd-unit-file-to-sysvinit converter running. So, the BSD and Hurd
> fans are not completely left outside. There is other stuff in Debian
> as well which won't work on these kernels after all (like udevd).

I have tried systemd but as it does not support the Debian extensions to
cryptsetup (namely the crypttab keyscript parameter) it is not a
valuable alternative for me - sysvinit and upstart btw do support them,
I did not yet get the chance to try openrc (and yes this is a Debian
specific feature nontheless present since long time so I argue that
people are using it and will also continue to do so). I guess this means
that either the Debian systemd maintainer may need to handle this in
some way (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862) or
the Debian users will have to decide how to deal with this matter.

Kind regards
Harald Jenny


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121129155835.gb2...@harald-has.a-little-linux-box.at

Re: Canonical pushes upstart into user session - systemd developer complains

[Kelly Clowers]

On Thu, Nov 29, 2012 at 7:23 AM, Vincent Lefevre  wrote:
>
> And interfaces in various programming languages?

http://docs.python.org/2/library/configparser.html
http://search.cpan.org/~shlomif/Config-IniFiles-2.78/lib/Config/IniFiles.pm
https://rubygems.org/gems/inifile
http://ini4j.sourceforge.net/
https://github.com/2ion/ini.lua
https://code.google.com/p/inih/
https://github.com/shockie/node-iniparser
http://php.net/manual/en/function.parse-ini-file.php

http://www.codeproject.com/Articles/10809/A-Small-Class-to-Read-INI-File
http://www.boost.org/doc/libs/1_45_0/doc/html/property_tree.html
http://doc.qt.digia.com/qt/qsettings.html

> And command-line tools?
An editor with syntax highlighting?
Other than that, I don't know of any, but do you really need it with
ini? For a specific purpose, you could probably whip something up
pretty fast with one of the libraries...

>The advantage of XML is that it is more common.
[citation needed] ini is pretty darn common... I would guess that they
might be about the same.

Cheers,
Kelly Clowers


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAFoWM=_wgjpuuekj+g23x--g3njffpjwmybotk+e_-wtyrm...@mail.gmail.com

Re: Maildir vs. mbox in Debian

[Adam Borowski]

On Thu, Nov 29, 2012 at 04:32:33PM +0100, Vincent Lefevre wrote:
> On 2012-11-29 16:16:25 +0100, Adam Borowski wrote:
> > *cough* btrfs -ocompress=lzo.  Small files are packed inline in metadata
> > blocks, and you get compression you wanted.  Using lzo is faster than no
> > compression for most loads, adding negligible cost for incompressible data
> > (especially if not all cores are at 100% usage).
> 
> Great! Nice to know.
> 
> This should be the default in Debian. :)

Not while dpkg calls fsync() every, approximately, 0.1 bits written.
Btrfs has transactions one could use to wrap around a whole dpkg operation,
avoiding fsync entirely -- at the cost of having filesystem specific code.

But for now you can even think of btrfs only if either you're on stable and
don't mind upgrades taking forever, or you use eatmydata.  The latter is
actually safe if you use btrfs snapshots and revert if power fails during
a dpkg run, but sadly, it currently requires quite a bit of manual work,
especially to build an appropriate filesystem layout.

A machine that's primarily a mail server could use btrfs for the filesystem
that holds the mail, of course.

Outside of dpkg, sqlite in non-WAL mode, other databases and virtualbox/
qemu, btrfs is pretty fast.

-- 
How to squander your resources: those silly Swedes have a sauce named
"hovmästarsås", the best thing ever to put on cheese, yet they waste it
solely on mere salmon.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129165206.ga23...@angband.pl

Re: Really, about udev, not init sytsems

[Thomas Goirand]

On 11/29/2012 10:58 PM, Josselin Mouette wrote:
> There are valid arguments for forking udev, but /usr support is not one
> of them; we will just move /usr mounting to the initrd if it cannot be
> mounted later.
On the Debian side of things, you are probably right, since using an
initrd is ok in (nearly?) all situations.

However, you are running Gentoo and rebuild your kernel, why would
you bother with such thing as kernel modules and initrd? The thing is,
many (most? all?) Gentoo user, as far as I understand (I'm not a
Gentoo user), do not use kernel modules at all.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50b79371.4020...@debian.org

Re: Canonical pushes upstart into user session - systemd developer complains

[Roland Mas]

Kelly Clowers, 2012-11-29 08:37:19 -0800 :

[...]

>> And command-line tools?
> An editor with syntax highlighting?
> Other than that, I don't know of any, but do you really need it with
> ini? For a specific purpose, you could probably whip something up
> pretty fast with one of the libraries...

  For reading a value, there's confget(1).

  A tool to *set* a value in an *.ini file is three lines of Python that
can be inlined in a shell script (it's been mentioned elsewhere in this
thread).

Roland.
-- 
Roland Mas

Qui trop embrasse rate son train.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87wqx4pcr2@polymir.internal.placard.fr.eu.org

Re: Canonical pushes upstart into user session - systemd developer complains

[Adam Borowski]

On Thu, Nov 29, 2012 at 04:23:03PM +0100, Vincent Lefevre wrote:
> On 2012-11-29 15:46:35 +0100, Wouter Verhelst wrote:
> > But it will in a UTF8 locale,
> 
> Unfortunately the C locale is the only really portable one.

Debian's glibc has C.UTF-8 always available these days.
 
> > or in an ISO-8859-1 locale, for instance.
> > In a C locale, the é character simply does not exist, so you can't enter
> > it.
> 
> The config file may have been generated under some locale (or in
> an application where locales are ignored or can be ignored, say
> GNU Emacs), but scripts may run in other locales, in particular C
> for more portability.

It's high time to kill ancient encodings.  They're a maintenance burden,
and also, GUIs stopped paying even lip service to non-UTF8 quite some time
ago.

There's some discussion in #603914, although it has been derailed by
minutiae of behaviour of LC_CTYPE=C, which are mostly irrelevant for getting
rid of ISO-8859 and friends.

Besides, even today, if someone has a config file in an encoding other than
the one currently selected, that's an user error.  Here XML trying to
support that is a downside rather than upside.

-- 
How to squander your resources: those silly Swedes have a sauce named
"hovmästarsås", the best thing ever to put on cheese, yet they waste it
solely on mere salmon.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129170805.gb23...@angband.pl

Re: Really, about udev, not init sytsems |Subject: Re: Really, about udev

[John Paul Adrian Glaubitz]

Hi Harald,

On Thu, Nov 29, 2012 at 04:58:35PM +0100, Harald Jenny wrote:
> I have tried systemd but as it does not support the Debian extensions to
> cryptsetup (namely the crypttab keyscript parameter) it is not a
> valuable alternative for me - sysvinit and upstart btw do support them,
> I did not yet get the chance to try openrc (and yes this is a Debian
> specific feature nontheless present since long time so I argue that
> people are using it and will also continue to do so). I guess this means
> that either the Debian systemd maintainer may need to handle this in
> some way (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862) or
> the Debian users will have to decide how to deal with this matter.

Thank you!

This is actually a true valid point which I personally would accept as
an argument against systemd. Without looking into the details, this
seems to be something that can be fixed by a new upload, doesn't it?

Cheers,

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129171214.ga20...@physik.fu-berlin.de

Re: Really, about udev, not init sytsems

[Jon Dowland]

On Fri, Nov 30, 2012 at 12:55:13AM +0800, Thomas Goirand wrote:
> However, you are running Gentoo and rebuild your kernel, why would
> you bother with such thing as kernel modules and initrd? The thing is,
> many (most? all?) Gentoo user, as far as I understand (I'm not a
> Gentoo user), do not use kernel modules at all.

In that situation, you'd be posting to gentoo-dev.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129171831.GB3605@debian

Re: Really, about udev, not init sytsems

[Игорь Пашев]

2012/11/29 Wouter Verhelst :
> glibc and the kernel is developed by the same group of companies. Both
> interact very closely and integration of the sources was the natural
> consequence.


Please, *DON"T* :-)

I've tired of this crap on illumos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALL-Q8xMeDSUHaLw=dtkub3p4cy3k-afzpza16ztblfl7kb...@mail.gmail.com

Re: Really, about udev, not init sytsems

[Barry Warsaw]

On Nov 29, 2012, at 03:40 PM, John Paul Adrian Glaubitz wrote:

>Plus, you have to sign a contributor's agreement with Canonical which leaves
>a bad taste in my mouth. That shouldn't be the case with true free software,
>should it?

In an ideal world maybe it shouldn't, but in truth it is for both open source
and free software.  As project leader of a GNU project, with copyrights owned
by the FSF, I am required to obtain copyright assignments from contributors,
which some folks feel are more onerous than contributor agreements.  Open
source projects like Python require contributor agreements for core
developers, and this is not an uncommon requirement.

We can argue about specific contribution legal documents and policies
(although hopefully, not here ;) but not about whether they are a reality in
today's FLOSS world.

Cheers,
-Barry


signature.asc
Description: PGP signature

Re: Really, ...

[Bernhard R. Link]

* John Paul Adrian Glaubitz  [121129 18:12]:
> This is actually a true valid point which I personally would accept as
> an argument against systemd. Without looking into the details, this
> seems to be something that can be fixed by a new upload, doesn't it?

Almost any actual specific problem can be fixed with a new upload.
Any reason given to believe that there will be problems left or that
remaining problems will have a bigger impact are not probable with
actual problems (because any actual problem usually can be fixed,
or claimed to be a non-problem).
I think noone claims that systemd would not be the superior design
in a world where there is bug-free, perfect software prepared to handle
every possible situation it will be thrown into. As our world has not
yet seen bug-free software handling every single situation the authors
did not think about properly, the expectation of what happens if one
runs into a not-yet fixed bug is an important issue for many people.

Free software has always been a way to avoid being helplessly at the
mercy of some software. So handing over the basics of your computer
to a much more complex system can be quite frightening for many
people around here. Claiming that it will work for everyone and that
anyone not being able to name a problem existing now has no arguments
does not help. It only makes sure people are reassured that systemd is
not for them. Combine that with vocal demands that it should be the
only allowed init process in a short time frame makes sure that there
is a big opposition (which will look for you like it has no arguments,
as no real arguments against systemd are accepted.)

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129192240.ga16...@client.brlink.eu

procenv and buildd environments

[James Hunt]

The procenv utility [1], which provides information on the environment
it runs in, is now available in Debian Sid [2] and Ubuntu Raring [3].

As part of its package build, 'make check' gets run which does the
following:

(1) Dumps information on the C pre-processor, compiler and linker.
(2) Runs procenv itself.

Step (1) is an aid to (2) in case it should fail. (2) is
useful since it:

- Helps to ensure the package works as expected once installed [*].
- Is a good check that procenv can handle 'odd' environments such as
  those provided by chroots (which are unusual in that their libc version
  often does not align with the provided kernel version).

The readily accessible build logs for procenv itself ([4], [5], [6]) may
in some circumstances help with FTBFS and test failure issues with
_other_ packages since they provide an insight into the environment in
which a package is built.

Using the build logs, informative analysis can be performed:

- See the environment a buildd provides.
- Compare a 'normal' environment with a buildd-provided one.
- Compare a Debian buildd environment to an Ubuntu one.

There are other examples and ideas in the initial blog post and the man
page.

[*] - Note that procenv also has DEP-8 support such that the
autopkgtest-provided environment can also be inspected [7]. The plan is to also
enable Ubuntu PPA builds, again for comparative purposes.

If anyone is interested in adding additional features to procenv, see
the TODO and please let me know.

Kind regards,

James.

[1] - https://launchpad.net/procenv
[2] - http://packages.debian.org/sid/procenv
[3] - http://packages.ubuntu.com/raring/procenv
[4] - https://buildd.debian.org/status/package.php?p=procenv&suite=sid
[5] - http://buildd.debian-ports.org/status/package.php?p=procenv
[6] - https://launchpad.net/ubuntu/+source/procenv (expand version 'twistie' for
build logs)
[7] -
https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-procenv/

--
James Hunt

http://upstart.ubuntu.com/cookbook
http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50b7b837.2080...@ubuntu.com

Re: Really, about udev, not init sytsems

[Thomas Goirand]

On 11/30/2012 01:18 AM, Jon Dowland wrote:
> On Fri, Nov 30, 2012 at 12:55:13AM +0800, Thomas Goirand wrote:
>> However, you are running Gentoo and rebuild your kernel, why would
>> you bother with such thing as kernel modules and initrd? The thing is,
>> many (most? all?) Gentoo user, as far as I understand (I'm not a
>> Gentoo user), do not use kernel modules at all.
> In that situation, you'd be posting to gentoo-dev.
We can ignore what happens to other downstreams of udev,
however I don't think that's a good idea to do so.

What makes you reasonably believe that if we had a Debian
specific issue, it would be considered by actual udev upstream,
and not publicly exposed?

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50b7ba3f.2040...@debian.org

Re: Really, about udev, not init sytsems

[John Paul Adrian Glaubitz]

On Thu, Nov 29, 2012 at 03:28:40PM +0100, Wouter Verhelst wrote:
> http://www.freescale.com/webapp/sps/site/homepage.jsp?code=PC68KCF
> 
> the most recent processor you can find there was released in January
> 2012.

Yeah, someone else posted this information already.

How much are these instruction set compatible with the classical m68k
processors? Would we be able to have an m68k port of Debian which runs
both on the original m68k CPUs and the ColdFire series?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129195147.ga21...@physik.fu-berlin.de

Re: Really, about udev, not init sytsems

[John Paul Adrian Glaubitz]

On Fri, Nov 30, 2012 at 03:40:47AM +0800, Thomas Goirand wrote:
> We can ignore what happens to other downstreams of udev,
> however I don't think that's a good idea to do so.

Why bother other downstreams if they don't complain? I find it rather
intrusive to post on the lists of other downstreams, trying to
convince them that a particular choice of upstream was bad.

I think the proper way should be to wait until the topic actually
comes up itself among the other downstreams.

As I said before, even the best upstream cannot always cover every
single use case and you can turn it any way you want, Gentoo is
definitely a very special and uncommon use case, so I can somehow
understand that upstream cannot cover that. But again, you're free to
fork the code and do whatever you want. You shouldn't just run around
everywhere and try to convince the other downstreams that your
particular use case is the one that has to be honored.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129195723.gb21...@physik.fu-berlin.de

Re: Really, ...

[John Paul Adrian Glaubitz]

On Thu, Nov 29, 2012 at 08:22:41PM +0100, Bernhard R. Link wrote:
> I think noone claims that systemd would not be the superior design
> in a world where there is bug-free, perfect software prepared to handle
> every possible situation it will be thrown into.

Yes, but this is valid for any other software design. But I think
systemd *does* a very good job in trying to cover every possible
usecase because it was actually designed with modern hard- and
software environments in mind, like embedded or big servers which
weren't simply existant back when the original System V Init design
was conceived.

> As our world has not
> yet seen bug-free software handling every single situation the authors
> did not think about properly, the expectation of what happens if one
> runs into a not-yet fixed bug is an important issue for many people.

Absolutely. But again, this is true for any software and this is
*especially* true for old designs which couldn't cover certain setups
which simply didn't exist back then.

You know the famous quote: "640 kB ought to be enough!"

> Free software has always been a way to avoid being helplessly at the
> mercy of some software. So handing over the basics of your computer
> to a much more complex system can be quite frightening for many
> people around here.

Yes, I see your point. But again, what I said before, how many people
are actually digging into such low-level code? Someone who is jumping
into kernel or plumberland development always has to have a certain
background knowledge. It requires more skills and experience as
opposed to writing desktop applications or smart phone apps.

But do you really think that we should keep every part of the system
brain-dead simple that everyone understands at the cost of reliablity
and performance? I mean, how many people do actually really understand
how the FireWire stack in the kernel works and is designed, how many
people understand the underlyings of gcc and so on?

I see your argument about keeping stuff simple, but again, if you want
to be able to solve more complex tasks with your computer, the
software on it itself has to become more complex. It's almost as if we
should never add features to the kernel because it becomes too complex
for newbies. I'm very sure Linus would flip everyone off who comes
with this certain mindset.

> Claiming that it will work for everyone and that
> anyone not being able to name a problem existing now has no arguments
> does not help.

Do System V Init or Upstart work in EVERY single use case? Do you know
that systemd actually works much better with systems which have high
load or are shared among many users (because it allows ressource
control by using cgroups).

You're putting the arguments the wrong way around. It is the old
System V Init which actually covers only a very limited use case while
systemd offers a much more flexible design, ranging from embedded
stuff up to very big machines.

> It only makes sure people are reassured that systemd is
> not for them. Combine that with vocal demands that it should be the
> only allowed init process in a short time frame makes sure that there
> is a big opposition (which will look for you like it has no arguments,
> as no real arguments against systemd are accepted.)

Yes, I do accept vocals against systemd, but only if these are
actually valid arguments. Because I want software development to
be driven on technical merits and not on sympathies against or for
certain people neither the stance to reject any modern developments.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129201402.gc21...@physik.fu-berlin.de

Re: Really, ...

[Russ Allbery]

John Paul Adrian Glaubitz  writes:

> Yes, I do accept vocals against systemd, but only if these are actually
> valid arguments. Because I want software development to be driven on
> technical merits and not on sympathies against or for certain people
> neither the stance to reject any modern developments.

Free software is a social activity.  The past history of qmail should be
informative here (or, for that matter, both gcc and glibc, which had to go
through disruptive forks to sort out long-term issues).  One of the
determiners of the long-term success of a free software project is the
social skills of the primary maintainers, regardless of their skill as
software designers.

I'm on the side of wanting to support a variety of different choices in
the archive so that people can experiment and evaluate and choose what
works best for them.  But to the extent that we have to pick winners and
losers (and, to be clear, I think it's premature to do that for init
systems), I for one will always advocate taking social considerations into
account as well as technical considerations.  In the long term, they often
matter more than the initial technical design.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obigdutn@windlord.stanford.edu

Re: Canonical pushes upstart into user session - systemd developer complains

[Stig Sandbeck Mathisen]

Vincent Lefevre  writes:

> It is more verbose, but I find it as readable (if you have characters
> that normally need to be escaped, you can still use CDATA sections,
> which is a way to keep the readability).

So to keep everyone equally happy, we need:





Structure _and_ readability.

-- 
Stig Sandbeck Mathisen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqx4dult@dagon.fnord.no

Re: Canonical pushes upstart into user session - systemd developer complains

[John Paul Adrian Glaubitz]

On Thu, Nov 29, 2012 at 09:25:50PM +0100, Stig Sandbeck Mathisen wrote:
> Vincent Lefevre  writes:
> 
> > It is more verbose, but I find it as readable (if you have characters
> > that normally need to be escaped, you can still use CDATA sections,
> > which is a way to keep the readability).
> 
> So to keep everyone equally happy, we need:
> 
> 
> 
> 
> 
> Structure _and_ readability.

I wonder what the effect is of setting key3 to ♬♫♩♩♫ :D :D.

Hilse fra Berlin!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129203902.gd21...@physik.fu-berlin.de

Re: Really, ...

[Bernhard R. Link]

* John Paul Adrian Glaubitz  [121129 21:14]:
> On Thu, Nov 29, 2012 at 08:22:41PM +0100, Bernhard R. Link wrote:
> > As our world has not
> > yet seen bug-free software handling every single situation the authors
> > did not think about properly, the expectation of what happens if one
> > runs into a not-yet fixed bug is an important issue for many people.
>
> Absolutely. But again, this is true for any software and this is
> *especially* true for old designs which couldn't cover certain setups
> which simply didn't exist back then.

But you have to understand that you put something that only does
promises against something that exists. Something that exists means
that people have experiences with it, now how it behaves, know how
to debug it and now how to make it work again when it breaks.
On the other side is systemd which has not yet been available in
a single Debian release and could not yet prove itself anywhere.

So if it would be proposed as some more init system to support
or a cool new stuff to experiment with it, you would not get that
much emotional reactions.

But as people demanded making it the only available system before
it could prove itself and while all most people know is that it
is quite a different design which wants to solve all the problems
at the same time (which often enough means it creates more problems
than it solves) and that it has ties which other projects people
have had no good experiences with (for enough people pulse-audio
is a synonym of "my sound is not working") you should have a
different reaction than ridiculing people not wanting to bet
their future on it.

> You know the famous quote: "640 kB ought to be enough!"

But I also know which happened to the 80286, which offered
quite a lot more memory and many nice things like fine
grained memory proection: It only looked nice on the paper
but (with some noble exceptions) was just not worth the hassle,
so that people prefered to stay with a 1 MB limit for many
years to come.

> Yes, I see your point. But again, what I said before, how many people
> are actually digging into such low-level code? Someone who is jumping
> into kernel or plumberland development always has to have a certain
> background knowledge. It requires more skills and experience as
> opposed to writing desktop applications or smart phone apps.

This is exactly the mindset that scares people away from systemd.

An application that does not behave is no big problem. One can easily
ditch it and replace it withanother. One has all the bells and whistles
of your full desktop available while you debug it. It's all quite well
understood.

If your init system does not work -- and one day it will not work,
there is no way that can be avoided, there is no perfect bug-free
software out there and especially when the task is to cope with
all possible hardware and their little quirks and timing problems,
all the different combinations of services and daemons out there
and so on -- you are set back much more.

So if you end up in a situation like that, what do you do as user?
Some will say "oh, it does not work. Let's try to reinstall the machine
and if that does not help let's try another distribution. Perhaps the
next release in two years will work. Or perhaps what I wanted to do
is not that important, so I will just not do that".

But for many people that would not be a solution but the absolute
nightmare. Being at the mercy of the computer; not being able to decide
what your machine does and what not; being totally powerless and
dependent on whether someone has decided that what you want to do
makes sense or not.

So being a more complex thing means it must be easier. Easier to
understand what it does. Easier to understand why something does
not work. Easier to fix it once it breaks.

> But do you really think that we should keep every part of the system
> brain-dead simple that everyone understands at the cost of reliablity
> and performance?

Do you really not understand why people think that?

And what does reliability mean if it can stop working and I can do
nothing against that at all?

> I see your argument about keeping stuff simple, but again, if you want
> to be able to solve more complex tasks with your computer, the
> software on it itself has to become more complex.

Strangely the complexity of the solution has seldom been related
to the complexity of the problem and always been the opposite of
reliablity in the past. So this is merely a false assertion.

> > Claiming that it will work for everyone and that
> > anyone not being able to name a problem existing now has no arguments
> > does not help.
>
> Do System V Init or Upstart work in EVERY single use case?

Actually, all my experiences with upstart has been when it does not
work. And then it was always a pain to work with. So in my experience
System V Init is quite superior to Upstart.

And the big advantage of System V Init is that everyone can diagnose
and fix it. Everyone knows how to add some

Re: Canonical pushes upstart into user session - systemd developer complains

[Ben Hutchings]

On Thu, Nov 29, 2012 at 09:25:50PM +0100, Stig Sandbeck Mathisen wrote:
> Vincent Lefevre  writes:
> 
> > It is more verbose, but I find it as readable (if you have characters
> > that normally need to be escaped, you can still use CDATA sections,
> > which is a way to keep the readability).
> 
> So to keep everyone equally happy, we need:
> 
> 
> 
> 
> 
> Structure _and_ readability.
 
Should be more like:

- item: |




Structure, readability *and* flexibility.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129213830.ga13...@decadent.org.uk

Re: debian-devel-digest Digest V2012 #1259

[penguina...@bigpond.com]

Sent from my HTC

- Reply message -
From: debian-devel-digest-requ...@lists.debian.org
To: 
Subject: debian-devel-digest Digest V2012 #1259
Date: Fri, Nov 30, 2012 4:47 AM


2012/11/29 Wouter Verhelst :
> glibc and the kernel is developed by the same group of companies. Both
> interact very closely and integration of the sources was the natural
> consequence.


Please, *DON"T* :-)

I've tired of this crap on illumos

Re: Canonical pushes upstart into user session - systemd developer complains

[Vincent Bernat]

 ❦ 29 novembre 2012 17:58 CET, Roland Mas  :

>>> And command-line tools?
>> An editor with syntax highlighting?
>> Other than that, I don't know of any, but do you really need it with
>> ini? For a specific purpose, you could probably whip something up
>> pretty fast with one of the libraries...
>
>   For reading a value, there's confget(1).
>
>   A tool to *set* a value in an *.ini file is three lines of Python that
> can be inlined in a shell script (it's been mentioned elsewhere in this
> thread).

Or something like Augeas.
-- 
Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)


pgprG7b6MxLvc.pgp
Description: PGP signature

Re: Really, ...

[Uoti Urpala]

Russ Allbery wrote:
> John Paul Adrian Glaubitz  writes:
> 
> > Yes, I do accept vocals against systemd, but only if these are actually
> > valid arguments. Because I want software development to be driven on
> > technical merits and not on sympathies against or for certain people
> > neither the stance to reject any modern developments.
> 
> Free software is a social activity.  The past history of qmail should be
> informative here (or, for that matter, both gcc and glibc, which had to go
> through disruptive forks to sort out long-term issues).  One of the
> determiners of the long-term success of a free software project is the
> social skills of the primary maintainers, regardless of their skill as
> software designers.

Systemd does much better than its competitors as a social activity.
Neither OpenRC nor Upstart (with its highly questionable form of
contributor agreement) can match systemd. You shouldn't confuse the
existence of a group of vocal naysayers as the lack of a thriving
community.


> I'm on the side of wanting to support a variety of different choices in
> the archive so that people can experiment and evaluate and choose what
> works best for them.

I question the usefulness of this approach for init systems. Yes,
developers do need a degree of familiarity to evaluate the merits of the
systems. But personalized init systems don't make much sense; everyone
deciding what works "best for *them*" is not a good approach. And when
talking about a larger number of people and how well things work in
their personal use in practice (as opposed to more in-depth technical
evaluation), what matters is largely the amount of effort spent on
polishing the most typical cases. Sysvinit has "worked well" for a
significant number of people; but that's not because it wouldn't suck,
but because a lot of effort has been used to paper over the problems.

>   But to the extent that we have to pick winners and
> losers (and, to be clear, I think it's premature to do that for init
> systems),

I think there's already enough evidence to show that systemd is clearly
the best choice. How much more would you expect to have before it would
not be "premature" any more?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1354230001.1887.16.camel@glyph.nonexistent.invalid

Re: Really, ...

[Russ Allbery]

Uoti Urpala  writes:
> Russ Allbery wrote:

>> Free software is a social activity.  The past history of qmail should
>> be informative here (or, for that matter, both gcc and glibc, which had
>> to go through disruptive forks to sort out long-term issues).  One of
>> the determiners of the long-term success of a free software project is
>> the social skills of the primary maintainers, regardless of their skill
>> as software designers.

> Systemd does much better than its competitors as a social activity.
> Neither OpenRC nor Upstart (with its highly questionable form of
> contributor agreement) can match systemd. You shouldn't confuse the
> existence of a group of vocal naysayers as the lack of a thriving
> community.

You've made your opinion quite clear.  Message received.

>> I'm on the side of wanting to support a variety of different choices in
>> the archive so that people can experiment and evaluate and choose what
>> works best for them.

> I question the usefulness of this approach for init systems.

No one is expecting you to help, so your statement that you don't think
this activity is useful is just noise.  One of the features of free
software is that there is no need to concern onself with the (presumably
billions) of people who *don't* want to work on something.  Only the
people who *do* want to work on something matter, provided that they
include the resources to do the minimum amount of work required to
coordinate this sort of flexibility.

If we were asking everyone maintaining Debian packages to do something
proactive to provide this flexibility, that would be another matter, but
so far that's not been necessary.  The work is largely isolated to those
people who want to work on it, which makes the opinions of people who
don't want to work on it uninteresting.

Even if we all decided that systemd was the one and only one way to go, we
would *still* have to develop init system flexibility in the archive in
order to handle the transition.  So we are *far* from any lost resources
in the effort we're putting into this, and it's completely premature to
pick a winner.

> I think there's already enough evidence to show that systemd is clearly
> the best choice. How much more would you expect to have before it would
> not be "premature" any more?

I don't see any need to have a firm answer to that question at this time.
The point is less about the amount of evidence required and much more
about the fact that there's no reason to make this decision unless and
until we actually need to as a project.  We're not at that point.

At this point, the single most annoying thing about systemd is the people
who are advocating it on debian-devel at every opportunity and seem
incapable of shutting up about it for more than a week, even though the
repeated conversations are both useless to the project as a whole and
don't vary with repetition.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk20asr3@windlord.stanford.edu

Re: Really, ...

[Andrej N. Gritsenko]

Hello!

Uoti Urpala has written on Friday, 30 November, at  1:00:
[...]
>I think there's already enough evidence to show that systemd is clearly
>the best choice. How much more would you expect to have before it would
>not be "premature" any more?

I should thank you all, John Paul Adrian Glaubitz, and Uoti Urpala. I
was wondered before if I should give systemd a try. Thank you very much,
you've convinced me and now I know - I never ever have to give it even a
small chance on any of my Debian systems.

Thank you again.
Andriy.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129233753.ga8...@rep.kiev.ua

Re: Really, ...

[Russ Allbery]

"Andrej N. Gritsenko"  writes:
> Uoti Urpala has written on Friday, 30 November, at  1:00:
> [...]

>> I think there's already enough evidence to show that systemd is clearly
>> the best choice. How much more would you expect to have before it would
>> not be "premature" any more?

> I should thank you all, John Paul Adrian Glaubitz, and Uoti Urpala. I
> was wondered before if I should give systemd a try. Thank you very much,
> you've convinced me and now I know - I never ever have to give it even a
> small chance on any of my Debian systems.

So, I just laid into Uoti about this, and I should probably be symmetric.
This isn't useful *either*.  The whole point is that *we don't need to
decide this right now*.

The people who repeatedly advocate systemd on debian-devel are not
representative of the whole development community.  I suspect most of them
aren't even *part* of the systemd development community.  Rather, this is
all further sign of a particular social problem in free software, namely
the tendency to attach oneself to projects (whether that be vim vs. Emacs,
GNOME vs. KDE, or systemd vs. upstart) as if they were sports teams, and
then start behaving with all the public composure and mutual understanding
of drunk football fans.

Let's try to avoid that on *all* sides.  It's just software.  And software
changes over time, and sometimes becomes much better (or much worse) than
it is right now.  It also forks and remerges, and the development
community often changes radically.  See, for example, glibc.

This is, btw, *exactly* why I personally tend to switch desktop
environments every couple of years.  It's a lot easier to not villify a
whole project when one has used it for a bit and can see that it has
pluses and minuses, just like everything else.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txs8asaz@windlord.stanford.edu

Re: Really, ...

[John Paul Adrian Glaubitz]

On Thu, Nov 29, 2012 at 03:34:08PM -0800, Russ Allbery wrote:
> No one is expecting you to help, so your statement that you don't think
> this activity is useful is just noise.  One of the features of free
> software is that there is no need to concern onself with the (presumably
> billions) of people who *don't* want to work on something.  Only the
> people who *do* want to work on something matter, provided that they
> include the resources to do the minimum amount of work required to
> coordinate this sort of flexibility.

Correct. But if it means when a minority of people have a vastly
different opinion on a certain matter and this opinion means extra
work and redundancies, I think this is something that should not be
persued.

> If we were asking everyone maintaining Debian packages to do something
> proactive to provide this flexibility, that would be another matter, but
> so far that's not been necessary.  The work is largely isolated to those
> people who want to work on it, which makes the opinions of people who
> don't want to work on it uninteresting.

Well, the choice of init system can have a huge impact on lots of
packages. If we decide to use either systemd or upstart by default,
we should ship all daemons with the appropriate unit/upstart files to
make the most of these sysvinit replacements.
 
> Even if we all decided that systemd was the one and only one way to go, we
> would *still* have to develop init system flexibility in the archive in
> order to handle the transition.  So we are *far* from any lost resources
> in the effort we're putting into this, and it's completely premature to
> pick a winner.

As far as I know, at least ArchLinux and Fedora already made the full
transition. According to a befriended Arch user I talked to today,
their old rc system is completely defunct now.

> > I think there's already enough evidence to show that systemd is clearly
> > the best choice. How much more would you expect to have before it would
> > not be "premature" any more?
> 
> I don't see any need to have a firm answer to that question at this time.
> The point is less about the amount of evidence required and much more
> about the fact that there's no reason to make this decision unless and
> until we actually need to as a project.  We're not at that point.

Well, on the other hand, it's not a good thing to postpone this
decision forever. Mandriva, openSuSE, Fedora, Arch, Frugalware and
Mageia already made the full transition while we're still arguing over
it.

systemd also has by far more contributors than any other init system,
so I think it's a sane decision to adopt the system which has the
highest popularity and momentum. This will guarantee that *most* of
our users will be happy (we can't satisfy everyone anyway) and the
upstream code will always be maintained.

> At this point, the single most annoying thing about systemd is the people
> who are advocating it on debian-devel at every opportunity and seem
> incapable of shutting up about it for more than a week, even though the
> repeated conversations are both useless to the project as a whole and
> don't vary with repetition.

And for me, the most annoying thing is the neverending circlejerk of
systemd bashing on a non-technical basis. If anyone of these people
would really take the time to read into the design rationales of the
available init systems (upstart, systemd, sysvinit, openrc), look at
the popularity and the amount of contributors, the decision would be
far easier to make.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129234932.ga29...@physik.fu-berlin.de

Re: Really, about udev, not init sytsems

[Roger Leigh]

On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote:
> On Thu, Nov 29, 2012 at 03:21:02PM +0100, Wouter Verhelst wrote:
> > > Well, systemd and udev are developed by the same developers. Both
> > > daemons interact very closely and integration of the sources was the
> > > natural consequence.
> > 
> > udev and pulseaudio are developed by the same developers. Both daemons
> > interact very closely and integration of the sources was the natural
> > consequence.
> > 
> > glibc and the kernel is developed by the same group of companies. Both
> > interact very closely and integration of the sources was the natural
> > consequence.
> > 
> > Internet explorer and Windows are developed by the same company. Both
> > interact very closely and integration of the two was the natural
> > consequence.
> > 
> > I'm not sure I agree with any of those arguments.
> 
> Ok, I should have added that both udev and systemd are also very
> closely related. So there are certainly benefits of merging the code.

Until their source repositories were combined, there was little
"close relation" between the two.  They might be more related now
that they exist in the same git repo, but I remain highly
sceptical of the technical and other benefits of this merge.  A
tool which is fundamentally geared to creating device nodes and
other tasks related to that need not be tightly-coupled with /any/
init system.  Even /with/ the merge, they still aren't that
coupled, except to force them to appear so.

> > > Yes, it makes it more difficult to use udev with a different init
> > > system, but again most people don't care
> > [citation needed]
> 
> Well, it's obvious, isn't it? I mean, I am talking about the average
> joe. I didn't hear anyone complain when Apple switched to launchd in
> 10.4 and I have really never ever people arguing about what init
> daemon is the best until systemd came up. I can't get rid of the
> impression that the rejection of systemd is solely based on technical
> merits.

Let's make one thing clear here.  The argument about which system is
"the best" or has the "most features" or is "most modern", or whatever,
is pointless.  The Debian GNU/Linux system is used in many different
ways, for many different purposes.  There is not, and can never be,
a "one size fits all" init system.

file-rc, s6, sysvinit, upstart, systemd, and others all have their
uses.  None of them are suitable for all use cases, and each have
use cases for which they are the optimal solution.  The most
important consideration is having an operating system which can
meet the needs of our userbase.  Retaining the flexibility to change
init systems to suit those varied needs is a key part of this.
Forcing our users to use the One True Init is not helpful, and
reduces the flexibility and usefulness of the system, as well as
hindering future development.

> Well, but I would say Ubuntu is to be blamed here. As opposed to
> upstart, systemd has many supporters and contributors in the industry
> (Intel, ProFusion, SuSE, RedHat) while upstart is virtually only
> actively developed by Canonical if am I not mistaken. Plus, you have
> to sign a contributor's agreement with Canonical which leaves a bad
> taste in my mouth. That shouldn't be the case with true free software,
> should it?

Enough.  None of this rubbish has anything at all to do with Debian.
You've taken your fanboyish advocacy of systemd to a ridiculous
extreme over the last week or so.  Please tone it down.  Nothing
done in Debian has anything to do with any of the above companies,
and if anything, having all those "supporters and contributors"
attempt to ram systemd down our throats whether we like it or not
counts against it rather than for it.

> Sure, I don't disagree on this point. But again, don't you think it
> makes sense to got into that direction when the adoption rate of a
> certain software is high?
> 
> I mean, just look at the popcon numbers for systemd vs upstart:

The popularity of the systems is meaningless.  Neither are the
default.  upstart only became functional this last week.  None
of this has any bearing on anything.

> > udev took quite some time to be accepted by the community too, but now
> > it's probably fair to say that it has been. To try to couple that to
> > systemd sounds like a bad form of systemd advocacy to me.
> 
> Yes, I agree it leaves a bad taste for sure. But again, I am not so
> sure if we really need to be able to choose our init system. I mean,
> do we have this discussion over mdev vs udev? Or even devfs?

Yes on all counts.  Look very hard at what Wookey wrote.  It's really
quite important.  Being able to swap out and replace the different
low level components of our system is critical.  These are just
userspace components, not kernel interfaces.  Replacing them should
be relatively simple.

If the new udev fork works, why /wouldn't/ we want to adopt it?  It
would have a friendlier upstream, it would be buildable without
unwanted ex

Re: Really, ...

[John Paul Adrian Glaubitz]

On Thu, Nov 29, 2012 at 03:43:48PM -0800, Russ Allbery wrote: 
> The people who repeatedly advocate systemd on debian-devel are not
> representative of the whole development community.  I suspect most of them
> aren't even *part* of the systemd development community.

No. But I am using systemd both at home and work now and it solved
many headaches I had before. I don't have to worry about messing with
/etc/default anymore to enable/disable daemons, I don't even have to
worry how to do that when using a different distribution. It works the
same on Fedora, Arch, Debian, openSuSE, every distribution that uses
systemd.

I also don't have to worry about daemons dying unsupervised daemons,
not noticing it until someone knocks at the door of the IT department
to complain. Gone are the headaches we had with autofs only working
70% of the time or the /home NFS simply not being mounted on some
machines after startup.

I can quickly figure out why my system takes longer than usual too
boot and I will immediately see when and why daemon xyz was restarted.

Seriously, this is not based on religion, this is based purely on
technical merits and good experiences with systemd.

> Rather, this is
> all further sign of a particular social problem in free software, namely
> the tendency to attach oneself to projects (whether that be vim vs. Emacs,
> GNOME vs. KDE, or systemd vs. upstart) as if they were sports teams, and
> then start behaving with all the public composure and mutual understanding
> of drunk football fans.

Yes, there are these wars on actual software applications and these
will definetely never stop, simply because the choice of a preferred
editor or desktop is highly subjective.

As for stuff in the plumberland, you don't see it most of the time,
you just want it to be there and work reliably.

And the concept and design of systemd has been already proven to be
very reliable. Apple switched to the design (launchd) in 2004 in MacOS
X and successfully uses it on any iOS device (iPhone, iPad, iPod
touch) they're shipping. I never heard of any problems with regard to
launchd.

> Let's try to avoid that on *all* sides.  It's just software.  And software
> changes over time, and sometimes becomes much better (or much worse) than
> it is right now.  It also forks and remerges, and the development
> community often changes radically.  See, for example, glibc.

Absolutely true. And this is actually why I don't understand so many
people get so emotional when it comes to software like systemd or
Pulse-Audio.

> This is, btw, *exactly* why I personally tend to switch desktop
> environments every couple of years.  It's a lot easier to not villify a
> whole project when one has used it for a bit and can see that it has
> pluses and minuses, just like everything else.

I rather do that because I get bored from time to time, want to help
find bugs in other desktops or I simply want to explore new stuff, to
make sure I still have the best experience I can get.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2012113433.gb29...@physik.fu-berlin.de

Re: Really, ...

[Russ Allbery]

John Paul Adrian Glaubitz  writes:
> On Thu, Nov 29, 2012 at 03:34:08PM -0800, Russ Allbery wrote:

>> At this point, the single most annoying thing about systemd is the
>> people who are advocating it on debian-devel at every opportunity and
>> seem incapable of shutting up about it for more than a week, even
>> though the repeated conversations are both useless to the project as a
>> whole and don't vary with repetition.

> And for me, the most annoying thing is the neverending circlejerk of
> systemd bashing on a non-technical basis.

This is something that you're all (collectively) enabling via your
behavior of constantly repeating the same arguments.  Someone has to stop.
Preferrably everyone at once.

> If anyone of these people would really take the time to read into the
> design rationales of the available init systems (upstart, systemd,
> sysvinit, openrc), look at the popularity and the amount of
> contributors, the decision would be far easier to make.

This is the key point: WE ARE NOT GOING TO MAKE A DECISION RIGHT NOW.  We
simply are not.  It doesn't matter how many messages you write to
debian-devel, what arguments you muster, and what evidence you have: this
decision will not be made right at this moment, in the middle of a release
freeze, prior to completing the Policy work for even testing a migration
to systemd.

It's absolutely impossible that any firm decision will be made at any time
before the wheezy release is complete.  I think it's rather unlikely until
we have a clear policy for how people should add systemd support in their
packages and those package maintainers who chose to do so have started to
enable it.  (I think we're actually fairly close to such a policy, but
it's not formalized yet.)

Therefore, every time you continue to argue about this on debian-devel,
the *only* thing that you are accomplishing is to feed what you accurately
describe as a never-ending circlejerk, by providing it with more material,
more ammunition, more fodder for the discussion to continue and continue
and continue.

This is all equally true of the people who hate systemd.

It would also be true of the people who advocate upstart or OpenRC, except
you'll notice that they've largely stopped discussing the topic except
when they can't stop themselves from rebutting some specific technical
point.  That's wise.  It's worthy of emulation.

Please, let's *stop talking about this*, apart from the much more
specific, straightforward, and *useful* discussion of what further work is
required to enable those who wish to do so to run systemd as their init
process in Debian.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obigarbv@windlord.stanford.edu

Re: Really, ...

[John Paul Adrian Glaubitz]

On Thu, Nov 29, 2012 at 04:04:52PM -0800, Russ Allbery wrote:
> John Paul Adrian Glaubitz  writes:
> > On Thu, Nov 29, 2012 at 03:34:08PM -0800, Russ Allbery wrote:
> 
> >> At this point, the single most annoying thing about systemd is the
> >> people who are advocating it on debian-devel at every opportunity and
> >> seem incapable of shutting up about it for more than a week, even
> >> though the repeated conversations are both useless to the project as a
> >> whole and don't vary with repetition.
> 
> > And for me, the most annoying thing is the neverending circlejerk of
> > systemd bashing on a non-technical basis.
> 
> This is something that you're all (collectively) enabling via your
> behavior of constantly repeating the same arguments.  Someone has to stop.
> Preferrably everyone at once.

Why should my chain of arguments change? If it constantly changed all
the time, it would mean I'm not really having any arguments but I just
want to win the discussion. This is not my point, I'm just trying to
explain the sceptics that most of their fears are simply unjustified.

> > If anyone of these people would really take the time to read into the
> > design rationales of the available init systems (upstart, systemd,
> > sysvinit, openrc), look at the popularity and the amount of
> > contributors, the decision would be far easier to make.
> 
> This is the key point: WE ARE NOT GOING TO MAKE A DECISION RIGHT NOW.  We
> simply are not.  It doesn't matter how many messages you write to
> debian-devel, what arguments you muster, and what evidence you have: this
> decision will not be made right at this moment, in the middle of a release
> freeze, prior to completing the Policy work for even testing a migration
> to systemd.

Hey, you don't need to be yelling at me, I didn't kick off the
discussion. I am perfectly fine with the current situation. And you
don't need to enlighten me on the release policy, I am very much
aware that we're in freeze. At no point did I say we have to decide
something now. I merely said that we certainly shouldn't wait forever.

Again, I didn't bring up the discussion, so please don't focus on me.

> It's absolutely impossible that any firm decision will be made at any time
> before the wheezy release is complete.  I think it's rather unlikely until
> we have a clear policy for how people should add systemd support in their
> packages and those package maintainers who chose to do so have started to
> enable it.  (I think we're actually fairly close to such a policy, but
> it's not formalized yet.)

Yes, I am aware of the situation.

> Therefore, every time you continue to argue about this on debian-devel,
> the *only* thing that you are accomplishing is to feed what you accurately
> describe as a never-ending circlejerk, by providing it with more material,
> more ammunition, more fodder for the discussion to continue and continue
> and continue.
>
> This is all equally true of the people who hate systemd.

Phew, I already feared I would have to take all the blame :).
 
> It would also be true of the people who advocate upstart or OpenRC, except
> you'll notice that they've largely stopped discussing the topic except
> when they can't stop themselves from rebutting some specific technical
> point.  That's wise.  It's worthy of emulation.

I don't think there are particular people to blame. The unwillingness
to stop discussing the topic comes from both sides. But as long as we
treat each other respectfully, I still think it's ok to be discussed.

It's not that I am not willing to learn. I'm always willing to give in
with my argumentation if someone actually comes up with valid
counterarguments (with what Harald Jenny said, for example).

> Please, let's *stop talking about this*, apart from the much more
> specific, straightforward, and *useful* discussion of what further work is
> required to enable those who wish to do so to run systemd as their init
> process in Debian.

Sure, I would love to switch the topic :).

Adrian 

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121130002017.ga23...@physik.fu-berlin.de

Re: Really, ...

[Russ Allbery]

John Paul Adrian Glaubitz  writes:
> On Thu, Nov 29, 2012 at 04:04:52PM -0800, Russ Allbery wrote:

>> This is something that you're all (collectively) enabling via your
>> behavior of constantly repeating the same arguments.  Someone has to
>> stop.  Preferrably everyone at once.

> Why should my chain of arguments change?

I don't want you to change your chain of arguments.  I want you to stop
repeating them constantly in debian-devel, thus prompting the people who
disagree with you to constantly repeat *their* arguments, thus prompting
you to constantly repeat *your* arguments, thus prompting me to want to
reach through my computer screen and strangle all of you.  :)

> This is not my point, I'm just trying to explain the sceptics that most
> of their fears are simply unjustified.

Give up.  Seriously.  We've been having this conversation for, what, two
years now?  You're not saying anything that anyone hasn't already heard
before.  Words aren't going to convince anyone; everyone has a hardened
position at this point who is going to form an opinion at all.  And
convincing people isn't required for any effective progress.

> Again, I didn't bring up the discussion, so please don't focus on me.

I'm not, really.  I originally replied to Uoti, and I've also replied to
someone else on the other side of the argument.  I'm only making these
points in response to you because you're the one who replied.  They're
equally applicable to everyone on the systemd side of the discussion, and
most of them are applicable to the anti-systemd side as well.

> I don't think there are particular people to blame. The unwillingness to
> stop discussing the topic comes from both sides.

I agree with this.

> But as long as we treat each other respectfully, I still think it's ok
> to be discussed.

Well, I'm not a list owner and am not going to declare it "not okay" in
some sort of formal way, but as a personal contributor and reader to
debian-devel, I am down on my knees here begging you to please stop
discussing it.  This discussion keeps taking over debian-devel and making
the whole thing annoying and frustrating to read, and doesn't seem to be
accomplishing anything at all.

I really think this is a case where personal experience is going to speak
louder than any possible argument, which is why I think the next step is
to make it simple and documented to switch init systems and see how it
works.  You'll notice, for example, that Steve posted to his blog, and
hence to Planet Debian, how to do this for upstart, and people are
starting to experiment with systemd similarly.

The next step is to start getting *voluntary* native coverage for either
or both of upstart or systemd (or OpenRC, for that matter) from those
package maintainers who feel like adding support.  I, for one, plan on
doing this for at least some of my packages for *both* upstart and systemd
after the freeze is over, provided that there are simple, easy-to-follow
instructions somewhere for how to write the appropriate configuration
files.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878v9kapx6@windlord.stanford.edu

Re: Really, ...

[Andrej N. Gritsenko]

Hello!

John Paul Adrian Glaubitz has written on Friday, 30 November, at  1:04:
>Absolutely true. And this is actually why I don't understand so many
>people get so emotional when it comes to software like systemd or
>Pulse-Audio.

Well, without any emotions. In last 2 years I've installed Ubuntu and
Debian systems 7 times. 3 times sound just haven't worked. 2 times sound
worked unstable from beginning. 1 time sound worked but I've got complain
after a month that it sometimes ceases to work so they had to reboot the
system. All those systems were fixed by deinstalling Pulse-Audio. Only on
one laptop Pulse-Audio worked (unfortunately it has been stolen shortly
so I cannot tell now if it worked stable). What I suppose to think about
Pulse-Audio? You can tell me million times I am dumb and Pulse-Audio is
the best, I will never trust you, I'm sorry but experience tells me just
otherwise.

With best regards.
Andriy.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121130004105.ga23...@rep.kiev.ua

Work-needing packages report for Nov 30, 2012

[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: 497 (new: 15)
Total number of packages offered up for adoption: 138 (new: 0)
Total number of packages requested help for: 64 (new: 0)

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



The following packages have been orphaned:

   bio2jack (#694603), orphaned yesterday
 Description: oss/alsa to jack porting lib - development files
 Installations reported by Popcon: 131

   glrr (#694115), orphaned 5 days ago
 Installations reported by Popcon: 72

   glrr-widgets (#694116), orphaned 5 days ago
 Installations reported by Popcon: 57

   gplcver (#694118), orphaned 5 days ago
 Installations reported by Popcon: 305

   gsetroot (#694604), orphaned yesterday
 Description: a C/Gtk-based front-end for Esetroot
 Installations reported by Popcon: 125

   idesk (#694605), orphaned yesterday
 Description: Program to show icons on the desktop
 Installations reported by Popcon: 344

   langscan (#694120), orphaned 5 days ago
 Installations reported by Popcon: 37

   libfam-ruby (#694566), orphaned 2 days ago
 Description: Ruby Extension for the FAM C library
 Installations reported by Popcon: 14

   libimlib2-ruby (#694567), orphaned 2 days ago
 Description: Ruby Extension for the Imlib2 C library
 Installations reported by Popcon: 19

   mousetrap (#694606), orphaned yesterday
 Description: A simple game of ball chasing
 Installations reported by Popcon: 54

   njam (#694607), orphaned yesterday
 Description: pacman-like game with multiplayer support
 Installations reported by Popcon: 165

   tomoe (#694117), orphaned 5 days ago
 Installations reported by Popcon: 11

   vdesk (#694608), orphaned yesterday
 Description: manages virtual desktops for minimal window managers
 Installations reported by Popcon: 45

   xzoom (#694609), orphaned yesterday
 Description: magnify part of X display, with real-time updates
 Installations reported by Popcon: 273

   zatacka (#694610), orphaned yesterday
 Description: Arcade multiplayer game like nibbles
 Installations reported by Popcon: 62

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



No new packages have been given up for adoption, but a total of 138 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 1032 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 59703

   asymptote (#517342), requested 1371 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 3878

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

   balsa (#642906), requested 431 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 784

   bastille (#592137), requested 845 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 201

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

   chromium-browser (#583826), requested 914 days ago
 Description: Chromium browser
 Installations reported by Popcon: 11025

   cloud-init (#693094), requested 17 days ago
 Description: configuration and customization of cloud instances
 Installations reported by Popcon: 5

   debtags (#567954), requested 1032 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2521

   doc-central (#566364), requested 1041 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 205

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

   flightgear (#487388), requested 1622 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 845

   freeipmi (#628062), requested 553 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 2052

   gnat-4.4 (#539633), requested 1689 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 Installations reported by Popcon: 2122

   gnat-gps (#496905), 

Re: Really, about udev, not init sytsems

[Ben Hutchings]

On Thu, Nov 29, 2012 at 11:51:12PM +, Roger Leigh wrote:
> On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote:
> > On Thu, Nov 29, 2012 at 03:21:02PM +0100, Wouter Verhelst wrote:
> > > > Well, systemd and udev are developed by the same developers. Both
> > > > daemons interact very closely and integration of the sources was the
> > > > natural consequence.
> > > 
> > > udev and pulseaudio are developed by the same developers. Both daemons
> > > interact very closely and integration of the sources was the natural
> > > consequence.
> > > 
> > > glibc and the kernel is developed by the same group of companies. Both
> > > interact very closely and integration of the sources was the natural
> > > consequence.
> > > 
> > > Internet explorer and Windows are developed by the same company. Both
> > > interact very closely and integration of the two was the natural
> > > consequence.
> > > 
> > > I'm not sure I agree with any of those arguments.
> > 
> > Ok, I should have added that both udev and systemd are also very
> > closely related. So there are certainly benefits of merging the code.
> 
> Until their source repositories were combined, there was little
> "close relation" between the two.  They might be more related now
> that they exist in the same git repo, but I remain highly
> sceptical of the technical and other benefits of this merge.  A
> tool which is fundamentally geared to creating device nodes and
> other tasks related to that need not be tightly-coupled with /any/
> init system.
[...]

That's what udev *was*, originally.  Now it's a daemon that performs
more or less arbitrary actions when various events are reported by the
kernel.  Which is more or less what a modern init system does, only
restricted to a particular type of event.  It makes a fair bit of
sense to integrate all the events that may trigger service changes,
without spawning a shell to pass each of the device events across.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121130005146.gb13...@decadent.org.uk

Re: Canonical pushes upstart into user session - systemd developer complains

[Vincent Lefevre]

On 2012-11-29 18:08:05 +0100, Adam Borowski wrote:
> On Thu, Nov 29, 2012 at 04:23:03PM +0100, Vincent Lefevre wrote:
> > On 2012-11-29 15:46:35 +0100, Wouter Verhelst wrote:
> > > But it will in a UTF8 locale,
> > 
> > Unfortunately the C locale is the only really portable one.
> 
> Debian's glibc has C.UTF-8 always available these days.

This seems to be Debian only, and not for the current stable.
This is not OK for portable applications... until C.UTF-8 is
made standard and widely adopted.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121130005612.gm5...@xvii.vinc17.org

Re: Canonical pushes upstart into user session - systemd developer complains

[Vincent Lefevre]

On 2012-11-29 21:25:50 +0100, Stig Sandbeck Mathisen wrote:
> So to keep everyone equally happy, we need:
> 
> 
> 
> 
> 
> Structure _and_ readability.

No, you don't have the structure from the XML point of view.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121130005851.gn5...@xvii.vinc17.org

Re: Canonical pushes upstart into user session - systemd developer complains

[Vincent Lefevre]

On 2012-11-29 08:37:19 -0800, Kelly Clowers wrote:
> On Thu, Nov 29, 2012 at 7:23 AM, Vincent Lefevre  wrote:
> > And interfaces in various programming languages?
> 
> http://search.cpan.org/~shlomif/Config-IniFiles-2.78/lib/Config/IniFiles.pm

At least for Perl, I can't see anything related to validation.

BTW, how do you do nested blocks in .ini files?

> > And command-line tools?
> An editor with syntax highlighting?

No, I mean the equivalent of xmlstarlet, e.g. to extract / change
values...

> >The advantage of XML is that it is more common.
> [citation needed] ini is pretty darn common... I would guess that they
> might be about the same.

XML is not just used for config files...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121130011804.go5...@xvii.vinc17.org

Re: Really, ...

[Uoti Urpala]

Russ Allbery wrote:
> Uoti Urpala  writes:
> > Russ Allbery wrote:
> >> Free software is a social activity.  The past history of qmail should
> >> be informative here (or, for that matter, both gcc and glibc, which had
> >> to go through disruptive forks to sort out long-term issues).  One of
> >> the determiners of the long-term success of a free software project is
> >> the social skills of the primary maintainers, regardless of their skill
> >> as software designers.
> 
> > Systemd does much better than its competitors as a social activity.
> > Neither OpenRC nor Upstart (with its highly questionable form of
> > contributor agreement) can match systemd. You shouldn't confuse the
> > existence of a group of vocal naysayers as the lack of a thriving
> > community.
> 
> You've made your opinion quite clear.  Message received.

I think there are enough ways to measure things objectively that it's
more than just my personal opinion.


> >> I'm on the side of wanting to support a variety of different choices in
> >> the archive so that people can experiment and evaluate and choose what
> >> works best for them.
> 
> > I question the usefulness of this approach for init systems.
> 
> No one is expecting you to help, so your statement that you don't think
> this activity is useful is just noise.

Would you expect anyone who thinks such activity is not useful to help
with it? This would seem to lead to the absurd conclusion that
expressing a negative view/evaluation of anything would always be just
noise, regardless of technical arguments or anything else.

I would consider the "metadiscussion" of what is an appropriate way to
test/choose init systems to be meaningful. Even if it were not
immediately relevant to practice, that wouldn't make it "just noise".


>   One of the features of free
> software is that there is no need to concern onself with the (presumably
> billions) of people who *don't* want to work on something.  Only the
> people who *do* want to work on something matter, provided that they
> include the resources to do the minimum amount of work required to
> coordinate this sort of flexibility.

This would be more applicable if I had been telling you exactly how you
should go about adding support for init systems other than systemd. But
I didn't.


> > I think there's already enough evidence to show that systemd is clearly
> > the best choice. How much more would you expect to have before it would
> > not be "premature" any more?
> 
> I don't see any need to have a firm answer to that question at this time.
> The point is less about the amount of evidence required and much more
> about the fact that there's no reason to make this decision unless and
> until we actually need to as a project.  We're not at that point.

There's no need for Debian to make a formal decision that will be set in
stone no matter what. But what you said was that it would be premature
to pick winners and losers for init systems. I don't consider it
premature to pick systemd as a winner; there's a difference between
keeping your options open and claiming that they're all still equal. You
don't need to make a _final_ decision yet. But that does not mean it
would be premature to say that it seems pretty clear what the decision
should be.


> At this point, the single most annoying thing about systemd is the people
> who are advocating it on debian-devel at every opportunity and seem
> incapable of shutting up about it for more than a week, even though the
> repeated conversations are both useless to the project as a whole and
> don't vary with repetition.

This thread was started by an "anti-systemd" poster, not "people
advocating it". I don't see any justification for you to focus your
blame on systemd *supporters*.

Since you wrote this in a reply to me, I assume you meant that "people
advocating it" to apply to me at least to some degree. The primary
reason I wrote my original reply is that you made a misleading
comparison between qmail (lack of working community) and systemd
(working community, outsiders who complain). I can't see how you could
claim that you're not significantly more guilty yourself of "useless
posting" (or whatever your exact complaint is) than I am.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1354237847.1887.48.camel@glyph.nonexistent.invalid

Re: Really, ...

[Russ Allbery]

Uoti Urpala  writes:

> Would you expect anyone who thinks such activity is not useful to help
> with it? This would seem to lead to the absurd conclusion that
> expressing a negative view/evaluation of anything would always be just
> noise, regardless of technical arguments or anything else.

If they haven't heard the evaluation, then it may be useful information
for them.  Once you've already communicated the evaluation and established
that they don't agree with you, then yes, this is exactly true.

This is a major feature of free software.  It doesn't matter how many
people think what you're doing is a bad idea as long as you don't need
their help.  You can go off and try it anyway.  Usually, if it's a bad
idea, that will become obvious anyway, and you may learn something in the
process.  Sometimes, it will turn out that you're right and other people
are wrong.  Either way, it's generally much more fun than arguing about it
incessantly.

It's just like a vim user going on about how horrible Emacs is.  No one
cares.  The Emacs developers are going to keep developing on Emacs because
they like Emacs.  The vim developers are going to keep working on vim
because they like vim.  There are only a few places where there's any
point in debating which one is better: when making a recommendation to a
brand new user who has never tried either, and when for some reason we
have to pick a winner.

Believe me, if we get to a point where we need to pick a winner for init
systems, you'll know, and it will be impossible to miss the discussion.
Everyone will have plenty of chances to make all their arguments.  As a
bonus, they'll even be arguments that are current at that time and will be
able to take into account anything that changes between now and then!

And if we never do have to pick a winner, bonus!  There's another big
argument we will have avoided.

> There's no need for Debian to make a formal decision that will be set in
> stone no matter what. But what you said was that it would be premature
> to pick winners and losers for init systems. I don't consider it
> premature to pick systemd as a winner; there's a difference between
> keeping your options open and claiming that they're all still equal.

Yes, it's been obvious for months that you think there's enough data to
make a decision right now.  But we're still not going to, and that isn't
going to change just because you've stated your opinion for the 51st time.

> This thread was started by an "anti-systemd" poster, not "people
> advocating it". I don't see any justification for you to focus your
> blame on systemd *supporters*.

Consider it defocused and spread about widely.  Really, I don't care who's
been "worse."  I would like everyone to stop engaging in this pointless
bickering.

> Since you wrote this in a reply to me, I assume you meant that "people
> advocating it" to apply to me at least to some degree. The primary
> reason I wrote my original reply is that you made a misleading
> comparison between qmail (lack of working community) and systemd
> (working community, outsiders who complain).

You misread my message.  I didn't compare qmail directly to systemd.  I
was using qmail among others to make a general argument against the
position that social factors do not matter when choosing software.

Given your reply, you apparently agree but find the social factors in this
case debatable.  That's fine; I find them debatable too, and am not
interested in debating them with you (largely because I haven't formed a
strong opinion).  Apparently we're both vehemently agreeing that social
factors are important, making this yet another pointless digression.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sj7ram4s@windlord.stanford.edu

Re: Really, ...

[Uoti Urpala]

Andrej N. Gritsenko wrote:
> John Paul Adrian Glaubitz has written on Friday, 30 November, at  1:04:
> >Absolutely true. And this is actually why I don't understand so many
> >people get so emotional when it comes to software like systemd or
> >Pulse-Audio.
> 
> Well, without any emotions. In last 2 years I've installed Ubuntu and
> Debian systems 7 times. 3 times sound just haven't worked. 2 times sound
> worked unstable from beginning. 1 time sound worked but I've got complain
> after a month that it sometimes ceases to work so they had to reboot the
> system. All those systems were fixed by deinstalling Pulse-Audio. Only on
> one laptop Pulse-Audio worked (unfortunately it has been stolen shortly
> so I cannot tell now if it worked stable). What I suppose to think about
> Pulse-Audio? You can tell me million times I am dumb and Pulse-Audio is
> the best, I will never trust you, I'm sorry but experience tells me just
> otherwise.

I've looked at PulseAudio myself recently due to issues users reported
with it. My view is that it's quite buggy, but there isn't much reason
to blame Lennart for that, while creating the project does show sound
technical judgment.

On a general level, a "high-level" sound system like PulseAudio is
necessary for general desktop use. I mostly use "raw" ALSA for my own
playback, but that doesn't mean it would be fine as the default
solution. From what I've seen of the PulseAudio code, it seems OK on a
general level (I haven't looked at that much of it, but enough to debug
a few different issues). Such a daemon was/is required, the general
design looks OK, and nobody else has done better. So I think overall it
should be taken to show that Lennart does know what he's doing. (The
design is not perfect though - especially I think the client-side API
could be easier to use without hurting functionality.) The people who
claim just not using PulseAudio would be a fine alternative overall (on
distribution level, rather than as a alternative working for certain
users) don't know what they're talking about.

However, current PulseAudio is still quite buggy. But I wouldn't place
too much of the blame for that on Lennart (other than him not dedicating
more of his time to polishing it). AFAIK he hasn't been involved much in
its development for the last couple of years. And his past involvement
is unlikely to be the explanation for not having better development
later; other similar audio work doesn't seem to attract that many
developers either - in fact some of the issues affecting PulseAudio
users are due to problems at lower levels of the audio stack.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1354241767.1887.76.camel@glyph.nonexistent.invalid

Re: Really, ...

[Chow Loong Jin]

On 30/11/2012 10:16, Uoti Urpala wrote:
> Andrej N. Gritsenko wrote:
>> John Paul Adrian Glaubitz has written on Friday, 30 November, at  1:04:
>>> Absolutely true. And this is actually why I don't understand so many
>>> people get so emotional when it comes to software like systemd or
>>> Pulse-Audio.
>>
>> Well, without any emotions. In last 2 years I've installed Ubuntu and
>> Debian systems 7 times. 3 times sound just haven't worked. 2 times sound
>> worked unstable from beginning. 1 time sound worked but I've got complain
>> after a month that it sometimes ceases to work so they had to reboot the
>> system. All those systems were fixed by deinstalling Pulse-Audio. Only on
>> one laptop Pulse-Audio worked (unfortunately it has been stolen shortly
>> so I cannot tell now if it worked stable). What I suppose to think about
>> Pulse-Audio? You can tell me million times I am dumb and Pulse-Audio is
>> the best, I will never trust you, I'm sorry but experience tells me just
>> otherwise.
> 
> I've looked at PulseAudio myself recently due to issues users reported
> with it. My view is that it's quite buggy, but there isn't much reason
> to blame Lennart for that, while creating the project does show sound
> technical judgment.
> 
> On a general level, a "high-level" sound system like PulseAudio is
> necessary for general desktop use. I mostly use "raw" ALSA for my own
> playback, but that doesn't mean it would be fine as the default
> solution. From what I've seen of the PulseAudio code, it seems OK on a
> general level (I haven't looked at that much of it, but enough to debug
> a few different issues). Such a daemon was/is required, the general
> design looks OK, and nobody else has done better. So I think overall it
> should be taken to show that Lennart does know what he's doing. (The
> design is not perfect though - especially I think the client-side API
> could be easier to use without hurting functionality.) The people who
> claim just not using PulseAudio would be a fine alternative overall (on
> distribution level, rather than as a alternative working for certain
> users) don't know what they're talking about.
> 
> However, current PulseAudio is still quite buggy. But I wouldn't place
> too much of the blame for that on Lennart (other than him not dedicating
> more of his time to polishing it). AFAIK he hasn't been involved much in
> its development for the last couple of years. And his past involvement
> is unlikely to be the explanation for not having better development
> later; other similar audio work doesn't seem to attract that many
> developers either - in fact some of the issues affecting PulseAudio
> users are due to problems at lower levels of the audio stack.


Is it, really? I haven't noticed any major issues with Pulseaudio in the past
couple of years running Ubuntu. That and sound has worked out of the box with
all the Ubuntu and Fedora systems I've installed in the past couple of months.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: Really, ...

[Uoti Urpala]

Russ Allbery wrote:
> Uoti Urpala  writes:
> 
> > Would you expect anyone who thinks such activity is not useful to help
> > with it? This would seem to lead to the absurd conclusion that
> > expressing a negative view/evaluation of anything would always be just
> > noise, regardless of technical arguments or anything else.
> 
> If they haven't heard the evaluation, then it may be useful information
> for them.  Once you've already communicated the evaluation and established
> that they don't agree with you, then yes, this is exactly true.

I'm pretty sure I haven't said anything similar about methods of
comparing init systems before. Note that I did not say "it's not worth
comparing because it's obvious that systemd would win anyway" (that's
probably true, but it's something that _has_ been said before). I talked
about the limitations of such an approach without reference to any
particular systems being tested.


> It's just like a vim user going on about how horrible Emacs is.  No one
> cares.  The Emacs developers are going to keep developing on Emacs because

I criticized a proposed method to compare vim and Emacs. Not vim or
Emacs.


> > There's no need for Debian to make a formal decision that will be set in
> > stone no matter what. But what you said was that it would be premature
> > to pick winners and losers for init systems. I don't consider it
> > premature to pick systemd as a winner; there's a difference between
> > keeping your options open and claiming that they're all still equal.
> 
> Yes, it's been obvious for months that you think there's enough data to
> make a decision right now.  But we're still not going to, and that isn't
> going to change just because you've stated your opinion for the 51st time.

Just to make it clear, I'm not arguing that Debian should make a formal
decision right now. What I said was about technical evaluation, not
formal decision-making. And here claiming that it's premature to make a
technical evaluation is itself a claim about the situation, not a
neutral position (saying that you haven't yet reached an evaluation
yourself is a neutral position; saying that making an evaluation is
premature is not).


> > Since you wrote this in a reply to me, I assume you meant that "people
> > advocating it" to apply to me at least to some degree. The primary
> > reason I wrote my original reply is that you made a misleading
> > comparison between qmail (lack of working community) and systemd
> > (working community, outsiders who complain).
> 
> You misread my message.  I didn't compare qmail directly to systemd.  I
> was using qmail among others to make a general argument against the
> position that social factors do not matter when choosing software.

I think the message you replied to had little to do with a "position
that social factors do not matter when choosing software", especially
social factors relevant to maintaining a development community as your
reply talked about. It was about the relevance of there being outsiders
who complain. So maybe I read your message differently than how you
intended it - but I think that was pretty natural if your intent was
replying to something that hadn't actually been said.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1354246066.1887.107.camel@glyph.nonexistent.invalid

Re: Really, ...

[Uoti Urpala]

Chow Loong Jin wrote:
> On 30/11/2012 10:16, Uoti Urpala wrote:
> > However, current PulseAudio is still quite buggy. But I wouldn't place

> Is it, really? I haven't noticed any major issues with Pulseaudio in the past
> couple of years running Ubuntu. That and sound has worked out of the box with
> all the Ubuntu and Fedora systems I've installed in the past couple of months.

I looked into it because there had been complaints about issues related
to PulseAudio from users, and I was able to quickly find and analyze
several bugs with no prior familiarity with the code. I do consider
myself better than an "usual" developer, and could probably find some
bugs in most projects, but I think that's still pretty strong evidence
against current PulseAudio being polished code.

Here's an example of one of the nastier bugs:
http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=29f064aa3d3a83e275361aad3f9e7efdc84b8ad0

I first sent a patch fixing that bug. A PulseAudio developer then posted
an alternative approach to fixing the issue a month later. Then nothing
happened for 2.5 more months until the fix was finally committed. So I
think bug fixing for known bugs is not working particularly efficiently
either.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1354247198.1887.117.camel@glyph.nonexistent.invalid

Re: Maildir vs. mbox in Debian

[brian m. carlson]

On Thu, Nov 29, 2012 at 05:52:06PM +0100, Adam Borowski wrote:
> Outside of dpkg, sqlite in non-WAL mode, other databases and virtualbox/
> qemu, btrfs is pretty fast.

That may be true, but it glosses over how awful performance is on those
workloads on btrfs.  A single Berkeley DB transaction can literally take
minutes.  btrfs in its default configuration is completely unusable for
any system that uses databases *at all*, which is essentially everything
but tiny embedded systems.  I won't even use it on /tmp.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature