Re: UPG and the default umask

[Vincent Bernat]

OoO La nuit ayant déjà recouvert  d'encre ce jour du samedi 15 mai 2010,
vers 23:34, Russ Allbery  disait :

>> Is it possible to detect whether an account is configured properly based
>> on the UPG idea? If yes, wouldn't it then make sense to only set umask
>> 002 if a proper UPG account is detected, otherwise 022? This would avoid
>> putting non-UPG systems on danger.

> That's a good idea.  I'm not sure if all UNIX group systems allow one to
> ask how many users are a member of a particular group, but if there's a
> way to ask that question at least in those group systems that support it,
> the implementation should be fairly straightforward.

If you  are thinking about checking if  the user is alone  in her group,
this seems a bad idea. I may  be alone in "users" group. But I may later
add  someone else. My  umask will  then change  but all  already created
files will be readable and writable by the new user.

Comparing names seems a better solution.
-- 
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c


pgpXrIlwZh4EL.pgp
Description: PGP signature

Re: UPG and the default umask

[Harald Braumann]

On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote:
> Willi Mann  writes:
> > Russ Allbery wrote:
> 
> >> The purpose of UPG is not to use the user private group for any sort of
> >> access control.  Rather, the point is to put each user in a group where
> >> they're the only member so that they can safely use a default umask of
> >> 002 without giving someone else write access to all their files.
> 
> > Is it possible to detect whether an account is configured properly based
> > on the UPG idea? If yes, wouldn't it then make sense to only set umask
> > 002 if a proper UPG account is detected, otherwise 022? This would avoid
> > putting non-UPG systems on danger.
> 
> That's a good idea.  I'm not sure if all UNIX group systems allow one to
> ask how many users are a member of a particular group, but if there's a
> way to ask that question at least in those group systems that support it,
> the implementation should be fairly straightforward.

To me this sounds more like heavy wizardry. Given the flexibility of
pam this can at best be heuristical. Also it would change the umask
from being a fixed value to being a dynamic value based upon some
arbitrary global state. This would increase complexity and make it
harder to reason about the system. Such changes should be avoided if
there isn't a really good reason. And to make collaboration easier
isn't a convincing reason, beacause the admin can easily change the
default umask, already, if needed.

I don't see a security problem with a umask of 002 in a UPG system and
I also agree that it would be preferable in such a system. But the
possibility of non-UPG systems is a valid concern. Therefore I'd opt
to keep a default umask of 022. And don't try to be too clever
figuring out what the umask should be. Keep it simple and let the
admin decide on this. So on a system where collaboration should be
supported, and the admin knows that it's a UPG system, he can set the
umask to 002. It's not as if this was an overly complex task.

Cheers,
harry


-- 
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/20100516105939.ga4...@sbs288.lan

Re: UPG and the default umask

[Aaron Toponce]

On 05/15/2010 02:51 PM, Willi Mann wrote:
> Is it possible to detect whether an account is configured properly based on 
> the UPG idea? If yes, wouldn't it then make sense to only set umask 002 if a 
> proper UPG account is detected, otherwise 022? This would avoid putting non-
> UPG systems on danger. 

I proposed this change to the /etc/profile file [1]. This logic seems
"good enough" to determine UPG accounts.

Further discussion however shows that other than root, system users
don't have login shells, and as such, won't process the /etc/profile
file. Also, because root has its own UPG, there's really no need for the
logic. My only question is then, why is their default shell /bin/sh, and
not /bin/false or /usr/sbin/nologin if they indeed are not login shells?

The "staff" and "users" groups might be problematic, if system
administrators are using those groups similar to how Solaris or HPUX are
using them (respectfully). However, I would venture that if the
administrator has his system setup that way, he's aware of the necessary
umask needed for that setup. If there are systems setup in this manner,
we'll likely see bug reports about it.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434#70

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Clint Adams]

On Sat, May 15, 2010 at 10:57:56PM +0200, Petter Reinholdtsen wrote:
> > Was this request ever actually made to the kfreebsd porters?  I'm not sure
> > that it was, in which case it's rather unfair to say that they've had enough
> > time when they were never informed this was a pressing issue.
> 
> One request was done last summer, see
> http://lists.debian.org/debian-bsd/2009/07/msg00117.html >.

If I were a kfreebsd porter I'd interpret that as "would anyone like
to help port upstart?" rather than "we're going to shove upstart down
your throat, comply or else."


-- 
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/20100516141857.ga8...@scru.org

Re: UPG and the default umask

[Aaron Toponce]

On 05/15/2010 12:16 AM, Vincent Danjean wrote:
> Somethink is wrong here. Should 314347 be reopened ?

Agreed. It's not working as it should. Running openssh-client version
1:5.5p1-3, and setting the write bit on my private group seems to keep
the client from behaving as expected.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[The Fungi]

On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote:
> That's a good idea. I'm not sure if all UNIX group systems allow
> one to ask how many users are a member of a particular group, but
> if there's a way to ask that question at least in those group
> systems that support it, the implementation should be fairly
> straightforward.

This is racy, unfortunately (at least by itself). Consider a non-UPG
system which starts with one user... this check passes and files get
created with group write flagged. Later, subsequent users appear
sharing that same group and the default umask stops making new files
group-writeable, but the first user's original files are now able to
be modified by others (and then his account is immediately at risk
of being taken over by one of the new users without his knowledge).

Of course, coupled with other checks like uname==gname, parsing
login.defs, et cetera, it could add an extra layer of assurance.
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.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/20100516151155.gb5...@yuggoth.org

ITP: python-pycparser -- A parser for the C language, written in pure Python.

[Alexander Holmes]

Package: wnpp
Severity: wishlist
Owner: Alex Holmes 

* Package name: python-pycparser
Version : 1.05
Upstream Author : Eli Bendersky 
* URL : http://code.google.com/p/pycparser/
* License : LGPL
Programming Lang: Python
Description : A parser for the C language, written in pure Python.

pycparser is a complete parser of the C language, written in pure Python
using the PLY 
parsing library (package python-ply). It parses C code into an AST and can
serve as a 
front-end for C compilers or analysis tools.


-- 
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/5b7c0ed98aeafcad17b2bcf3a80a6...@alex-holmes.com

Bug#581860: RFP: gnome-control-center -- gnome-display-properties

[Спицын Андрей]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---
gnome-display-properties
Hi
Then I try to change refresh rate of monitor mouse cursor turn invisible. All I 
can do is to hit chancel and kill X server.
MSI Wind u100 intel card.
Same on other system with intel card. 
   Package name: gnome-control-center
Version: 1:2.30.1-1
Upstream Author: [NAME ]
URL: [http://example.com]
License: [GPL, LGPL, BSD, MIT/X, etc.]
Description: [DESCRIPTION]




-- 
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/1274031207.9951.3.ca...@wind.gear

Re: UPG and the default umask

[Russ Allbery]

Aaron Toponce  writes:

> Further discussion however shows that other than root, system users
> don't have login shells, and as such, won't process the /etc/profile
> file. Also, because root has its own UPG, there's really no need for the
> logic. My only question is then, why is their default shell /bin/sh, and
> not /bin/false or /usr/sbin/nologin if they indeed are not login shells?

Because the further discussion was wrong.  System users have login shells
in Debian.  (I consider this a very long-standing bug.)

-- 
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/87pr0vg07c@windlord.stanford.edu

Re: UPG and the default umask

[Russ Allbery]

The Fungi  writes:
> On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote:

>> That's a good idea. I'm not sure if all UNIX group systems allow one to
>> ask how many users are a member of a particular group, but if there's a
>> way to ask that question at least in those group systems that support
>> it, the implementation should be fairly straightforward.

> This is racy, unfortunately (at least by itself). Consider a non-UPG
> system which starts with one user... this check passes and files get
> created with group write flagged. Later, subsequent users appear sharing
> that same group and the default umask stops making new files
> group-writeable, but the first user's original files are now able to be
> modified by others (and then his account is immediately at risk of being
> taken over by one of the new users without his knowledge).

> Of course, coupled with other checks like uname==gname, parsing
> login.defs, et cetera, it could add an extra layer of assurance.

Right, exactly.  You also check that username == group name, but it's an
additional check to be sure that the group doesn't just happen to look
like a user private group but isn't.

-- 
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/87ljbjg05j@windlord.stanford.edu

Re: UPG and the default umask

[Harald Braumann]

On Sun, May 16, 2010 at 03:11:56PM +, The Fungi wrote:
> On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote:
> > That's a good idea. I'm not sure if all UNIX group systems allow
> > one to ask how many users are a member of a particular group, but
> > if there's a way to ask that question at least in those group
> > systems that support it, the implementation should be fairly
> > straightforward.
> 
> This is racy, unfortunately (at least by itself). Consider a non-UPG
> system which starts with one user... this check passes and files get
> created with group write flagged. Later, subsequent users appear
> sharing that same group and the default umask stops making new files
> group-writeable, but the first user's original files are now able to
> be modified by others (and then his account is immediately at risk
> of being taken over by one of the new users without his knowledge).
> 
> Of course, coupled with other checks like uname==gname, parsing
> login.defs, et cetera, it could add an extra layer of assurance.

I'd call it an extra layer of assumptions. I already get the shivers
just thinking about the kind of complexity that is invented here. Now
it's sufficient to have a look in /etc/profile to *know* the umask
that will be set. If that scheme were implemented, I'd have to read code,
several files and query ldap, or whatever is used, to *assume* what
umask might be set.

Please don't do that. If non-UPG systems should be supported, keep the
umask at 022 and let the admin edit a single line to change it, if
this is needed and he knows it's a pure UPG system.

Cheers,
harry


-- 
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/20100516205051.gc4...@sbs288.lan

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Felipe Sateler]

On 09/05/10 11:54, Eduard Bloch wrote:

#include
* Cesare Leonardi [Sun, May 09 2010, 12:26:36PM]:


Here what i've measured, from the Grub start to the Gdm prompt, in
either case starting from a completely power off machine:
Without concurrency: 33 sec.
With concurrency (try 1): 29 sec.
With concurrency (try 2): 31 sec.


Similar results here:
without concurency: 35s
with concurency: 30s
with concurency and without readahead: 28s

Not that much difference, IMHO.


Here I get worse results for concurrency than non-concurrent:

CONCURRENCY=none:   51s
CONCURRENCY=makefile:   59s
CONCURRENCY=none + readahead:   37s
CONCURRENCY=makefile + readahead:   43s


Saludos,
Felipe Sateler



--
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/hspo2i$ii...@dough.gmane.org

Bug#581881: ITP: lintex -- automatic cleanup of old TeX-related files

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh 

* Package name: lintex
  Version : 1.04
  Upstream Author : Maurizio Loreti 
* URL : http://wwwcdf.pd.infn.it/MLO/index.html
* License : GPLv2
  Programming Lang: C
  Description : automatic cleanup of old TeX-related files 

 Removes uneeded files after a (La)TeX run: .aux, .log, .dvi, etc, if their
 timestamp is more recent than the TeX file's. Also removes the backup files
 created by your text editor. This keeps a directory containing multiple (La)TeX
 documents from becoming unmanageable.

-- 
|_)|_/  Ryan Kavanagh |  GnuPG key
| \| \  http://ryanak.ca/ |  4A11C97A (Transitioning from E95EDDC9)   
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments
Ol qrpelcgvat guvf zrffntr lbh ner va ivbyngvba bs gur QZPN!


signature.asc
Description: Digital signature

Re: UPG and the default umask

[Felipe Sateler]

On 16/05/10 16:50, Harald Braumann wrote:

If non-UPG systems should be supported, keep the
umask at 022 and let the admin edit a single line to change it, if
this is needed and he knows it's a pure UPG system.


Is there a reason to support non-UPG systems?

Saludos,
Felipe Sateler




--
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/hspqv6$qi...@dough.gmane.org

Re: UPG and the default umask

[Aaron Toponce]

On 05/16/2010 12:39 PM, Russ Allbery wrote:
> Because the further discussion was wrong.  System users have login shells
> in Debian.  (I consider this a very long-standing bug.)

Then the logic should be in play. System users don't necessarily have a
private group, so their umask should be 0022. If they are not intended
to be login accounts, then their default shell should be changed to
/usr/sbin/nologin or /bin/false.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Santiago Vila]

On Sun, 16 May 2010, Russ Allbery wrote:

> Aaron Toponce  writes:
> 
> > Further discussion however shows that other than root, system users
> > don't have login shells, and as such, won't process the /etc/profile
> > file. Also, because root has its own UPG, there's really no need for the
> > logic. My only question is then, why is their default shell /bin/sh, and
> > not /bin/false or /usr/sbin/nologin if they indeed are not login shells?
> 
> Because the further discussion was wrong.  System users have login shells
> in Debian.  (I consider this a very long-standing bug.)

They have login shells in the sense that their shell field in /etc/passwd
is /bin/sh, but if they do not really "login" to the system, then they
do not read /etc/profile.

In either case, if we plan to set default umask in /etc/login.defs or
using PAM, I will happily drop the umask setting from /etc/profile,
as we don't need to have the required "logic" by duplicate.


-- 
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/alpine.deb.1.10.1005170103200.6...@kolmogorov.unex.es

Re: UPG and the default umask

[Russ Allbery]

Felipe Sateler  writes:
> On 16/05/10 16:50, Harald Braumann wrote:

>> If non-UPG systems should be supported, keep the umask at 022 and let
>> the admin edit a single line to change it, if this is needed and he
>> knows it's a pure UPG system.

> Is there a reason to support non-UPG systems?

Yes.  Many Debian users already have non-UPG systems and are not going to
change their enterprise-wide account provisioning in order to accomodate
UPG.  Remember, the decision to use UPG in many environments is not a
per-system decision.  If the users are coming from some external source
like LDAP, it's an enterprise-wide decision and the person installing
Debian may not have any choice in the matter.

-- 
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/87iq6ne7lm@windlord.stanford.edu

Re: UPG and the default umask

[Aaron Toponce]

On 05/16/2010 05:11 PM, Santiago Vila wrote:
> They have login shells in the sense that their shell field in /etc/passwd
> is /bin/sh, but if they do not really "login" to the system, then they
> do not read /etc/profile.
> 
> In either case, if we plan to set default umask in /etc/login.defs or
> using PAM, I will happily drop the umask setting from /etc/profile,
> as we don't need to have the required "logic" by duplicate.

Curious, if umask isn't specified explicitly, what is it? For UID 1-99,
what we're discussing here, what would happen for their umask value?
Will it be 0022? ? Something else?

Also, if the system users aren't processing a login shell, then why
isn't their default login shell /usr/bin/nologin or /bin/false? Should a
wishlist bug be submitted against this?

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Felipe Sateler]

On 16/05/10 19:43, Russ Allbery wrote:

Felipe Sateler  writes:

On 16/05/10 16:50, Harald Braumann wrote:



If non-UPG systems should be supported, keep the umask at 022 and let
the admin edit a single line to change it, if this is needed and he
knows it's a pure UPG system.



Is there a reason to support non-UPG systems?


Yes.  Many Debian users already have non-UPG systems and are not going to
change their enterprise-wide account provisioning in order to accomodate
UPG.  Remember, the decision to use UPG in many environments is not a
per-system decision.  If the users are coming from some external source
like LDAP, it's an enterprise-wide decision and the person installing
Debian may not have any choice in the matter.


I mean, is there a reason for why I would want a non-UPG system? From 
what I've read in this thread, a common users group presents no 
advantage over UPG. Debian as an OS provider may be "forced" to support 
non-UPG configurations for reasons like you state, but I'm more interest 
in why would an enterprise want to take such a decision.


--
Saludos,
Felipe Sateler


--
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/hsq23k$br...@dough.gmane.org

Re: UPG and the default umask

[Russ Allbery]

Felipe Sateler  writes:

> I mean, is there a reason for why I would want a non-UPG system? From
> what I've read in this thread, a common users group presents no
> advantage over UPG. Debian as an OS provider may be "forced" to support
> non-UPG configurations for reasons like you state, but I'm more interest
> in why would an enterprise want to take such a decision.

In our case, because we've historically only ever used one GID in our
enterprise LDAP (previously NIS) user database, so it's very difficult to
safely introduce UPG since individual systems have used GIDs for various
other reasons.

-- 
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/87eihbe4hf@windlord.stanford.edu

ITP: xmlextras - - creates a common interface to use of the XML objects provided by IE and Mozilla

[Marcelo Jorge Vieira (metal)]

Package: wnpp
Severity: wishlist
Owner: Marcelo Jorge Vieira (metal) 

* Package name: libjs-xmlextras
  Version : not mentioned
  Upstream Author : Erik Arvidsson
* URL : http://webfx.eae.net/dhtml/xmlextras/xmlextras.html
* License : Apache Software License 2.0
  Programming Lang: JavaScript
  Description : creates a common interface to use of the XML objects 
provided by IE and Mozilla

The usage of XML inside the browser has been around for a while
but not until lately has it been possible to get this to work
in a satisfactory way in more than one browser. A while back
Mozilla added support for creating MS compatible XML classes
scriptable from JavaScript.

This script creates a common interface for Mozilla and IE
and also extends the Mozilla classes a little to make
them behave even more like the Microsoft interfaces.


This packages contains an embedded copy of xmlextras:

+ libjs-jac
+ phpwiki
+ monodoc-http


Cheers,

-- 
Marcelo Jorge Vieira
xmpp://me...@jabber-br.org
http://metaldot.alucinados.com


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

Re: UPG and the default umask

[Thomas Hochstein]

Felipe Sateler schrieb:

> I mean, is there a reason for why I would want a non-UPG system?

What about a hosting environment where you need to have user files
world-readable (HTML documents or (PHP) scripts readable by www-data),
but don't want them readable by other customers? You could achieve
that by putting all customers in a common group ("users") and setting
the files 604 or the like.

-thh


-- 
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/ldd.1005170400.1...@thorondor.akallabeth.de

Re: UPG and the default umask

[Brian May]

On 17 May 2010 10:50, Russ Allbery  wrote:
> In our case, because we've historically only ever used one GID in our
> enterprise LDAP (previously NIS) user database, so it's very difficult to
> safely introduce UPG since individual systems have used GIDs for various
> other reasons.

In our case we use the GID to reflect the department that the user
belongs to, and this group is used for file system quotas (amongst
other things).

Plus the fact that setting up an extra group for every user in LDAP is
extra complexity, extra chance for mistakes, for no gain for us.

Besides, if the requirement is to be able to create files in certain
directories with group permissions (I think that is what this is
about, but only skimming), can't you do something with default ACLs
that do the same thing on given directories without the extra
complexity to the groups?

Or have I got this wrong?
-- 
Brian May 


-- 
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/aanlktilkqnix8ker0_4wte9w13ymzgytcpkroqm1h...@mail.gmail.com

ITP: flann -- Fast Library for Approximate Nearest Neighbors

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: flann
 Version : 0.12
 Upstream Author : Marius Muja 
* URL : http://www.cs.ubc.ca/~mariusm/index.php/FLANN/FLANN
* License : BSD license (Simplified BSD license)
 Programming Lang: C++
 Description : Fast Library for Approximate Nearest Neighbors

 FLANN is a library for performing fast approximate nearest neighbor searches
 in high dimensional spaces. It contains a collection of algorithms we found
 to work best for nearest neighbor search and a system for automatically
 choosing the best algorithm and optimum parameters depending on the dataset.


-- 
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/aanlktinm36d5d-sheqea6rkfk_7vgf0v6glv6ztww...@mail.gmail.com

ITP: tx -- Library for Succinct Trie Data structure

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: tx
 Version : 0.16
 Upstream Author : Daisuke Okanohara 
* URL : http://code.google.com/p/tx-trie/
* License : BSD license (Simplified BSD license)
 Programming Lang: C++
 Description : Library for Succinct Trie Data structure

 Tx is a library for a compact trie data structure.
 Tx requires 1/4 - 1/10 of the memory usage compared to the previous
 implementations, and can therefore handle quite a large number of
 keys (e.g. 1 billion) efficiently.
 .
 A trie data structure supports exact matching and common prefix matching,
 which are used for natural language processing etc.
 Tx uses Level-Order Unary Degree Sequence (LOUDS) for trie representation.


-- 
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/aanlktikdevt77afvxawrqvzgntsnfdbwxvcz76ldf...@mail.gmail.com

Re: UPG and the default umask

[Russ Allbery]

Brian May  writes:

> Besides, if the requirement is to be able to create files in certain
> directories with group permissions (I think that is what this is about,
> but only skimming), can't you do something with default ACLs that do the
> same thing on given directories without the extra complexity to the
> groups?

> Or have I got this wrong?

You can do similar things with POSIX ACLs.  There's some disagreement over
which one is extra complexity.  :)

-- 
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/87zkzzw4sf@windlord.stanford.edu

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Petter Reinholdtsen]

[Felipe Sateler]
> Here I get worse results for concurrency than non-concurrent:
>
> CONCURRENCY=none: 51s
> CONCURRENCY=makefile: 59s
> CONCURRENCY=none + readahead: 37s
> CONCURRENCY=makefile + readahead: 43s

This is not the way it should be, and it would be interesting to try
to figure out why.  If you are interested, please report to BTS (for
example against the sysv-rc package) with more information.  The kind
of hardware is interesting, as well as the output from
/usr/share/insserv/make-testsuite and the bootchart data from the
sequencial and parallel boot.  Do your machine get IP address via
DHCP?

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/2fliq6n189q@login2.uio.no

Re: [OT] Re: Open then gates

[Micah Anderson]

Christoph Anton Mitterer  writes:

> On Sat, 2010-05-15 at 21:01 +0800, Paul Wise wrote:
>> You might be interested in monkeysphere
> ...and in RFC 5081
>
> I haven't had a detailed look on monkeyspehre so far, but it seemed at a
> first glance, that it does not use standardised technology, does it?

Can you clarify what you mean by "standardised technology"? 

I work on the monkeysphere project, and from my point of view, I'd have
to disagree with you, but I may not understand what you mean.

micah


-- 
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/87zkzz5fvo@pond.riseup.net

Re: [OT] Re: Open then gates

[Micah Anderson]

Christoph Anton Mitterer  writes:

> On Sat, 2010-05-15 at 21:01 +0800, Paul Wise wrote: 
>> You might be interested in monkeysphere 
> ...and in RFC 5081

> I haven't had a detailed look on monkeyspehre so
> far, but it seemed at a first glance, that it does not use
> standardised technology, does it?

Can you clarify what you mean by "standardised technology"? I work on
the monkeysphere project, and from my point of view, I'd have to
disagree with you, but I may not understand what you mean.

micah


-- 
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/87vdan5fp3@pond.riseup.net

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Felipe Sateler]

On 17/05/10 00:06, Petter Reinholdtsen wrote:


[Felipe Sateler]

Here I get worse results for concurrency than non-concurrent:

CONCURRENCY=none:   51s
CONCURRENCY=makefile:   59s
CONCURRENCY=none + readahead:   37s
CONCURRENCY=makefile + readahead:   43s


This is not the way it should be, and it would be interesting to try
to figure out why.  If you are interested, please report to BTS (for
example against the sysv-rc package) with more information.  The kind
of hardware is interesting, as well as the output from
/usr/share/insserv/make-testsuite and the bootchart data from the
sequencial and parallel boot.  Do your machine get IP address via
DHCP?


I'll follow up to the bts.

Saludos,
Felipe Sateler


--
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/hsqjml$ks...@dough.gmane.org

APT do not work with Squid as a proxy because of pipelining default

[Petter Reinholdtsen]

I am bothered by http://bugs.debian.org/56 >, and the fact
that apt(-get,itude) do not work with Squid as a proxy.  I would very
much like to have apt work out of the box with Squid in Squeeze.  To
fix it one can either change Squid to work with pipelining the way APT
uses, which the Squid maintainer and developers according to the BTS
report is unlikely to implement any time soon, or change the default
setting in apt for Aquire::http::Pipeline-Depth to zero (0).  I've
added a file like this in /etc/apt/apt.conf.d/ to solve it locally:

  Aquire::http::Pipeline-Depth 0;

My question to all of you is simple.  Should the APT default be
changed or Squid be changed?  Should the bug report be reassigned to
apt or stay as a bug with Squid?

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/20100517050500.gc3...@login2.uio.no