Re: DebPool project started on Alioth

[Andreas Fester]

Magnus Holmgren wrote:
> I have started a DebPool project on Alioth. Those of you who expressed an 

Great!

> interest in contributing are particularly welcome to join it (you have to 
> register an account on Alioth first).

My username is littletux-guest.

> http://alioth.debian.org/projects/debpool/
> 
> Everyone is invited to join the mailing list, which you can do at
> 
> http://lists.alioth.debian.org/mailman/listinfo/debpool-devel
> 
> or by sending mail to [EMAIL PROTECTED]

Done, see you there :)

Best Regards,

Andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Not-so-mass bug filing for the patented IDEA algorithm

[Florian Weimer]

I plan to file a couple of bugs (not too many, probably a dozen) on
packages which contain implementations of the patented IDEA algorithm
-- because the presence of that code makes them non-free.  As far as I
know, no program in Debian actually uses this code, it's just
inherited from upstream libraries.

Are there any objections?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Pierre Habouzit]

On Tue, Apr 10, 2007 at 09:09:23AM +0200, Florian Weimer wrote:
> I plan to file a couple of bugs (not too many, probably a dozen) on
> packages which contain implementations of the patented IDEA algorithm
> -- because the presence of that code makes them non-free.

  "because" ? I fail to see the logic in there

>   As far as I know, no program in Debian actually uses this code, it's
> just inherited from upstream libraries.

  AFAICT Debian just ignores patents, else we would have to remove maybe
70% of the archive. Are IDEA patents actively enforced ?

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp8ubyTnd2JU.pgp
Description: PGP signature

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Sean Perry]

interfaces with such closed-source software is of some relevance to
all of us who want to see Debian thrive, even if we choose not to use
that software ourselves.


Helping closed source software developers is not an itch I  
feel
 like scratching.  But if other people want to spend time making  
things

 easy for closed software, I am of course not going to stand in their
 way, no matter what my opinions on such activities are.

However, if it comes to a choice between free software and
 making things easier for non free software developers, or negatively
 impacting libre software to help closed source software  
development, I

 know how I would choose.

So hurrying the release process to help out closed source
 development is not likely to see me as cheering from the sidelines,
 no.  (pardon me if I am misinterpreting the thread as it happened on
 -release, where the proposed time-line of releasing in two years are
 being argued against because closed source software developers might
 decide to select against Debian -- which seems close enough to
 "hurrying up" to me).  If that is not the case here, then I apologize
 for the noise.



I haven't seen much Debian in the last 6 years in the commercial  
world. RH rules that roost. If people have chosen closed source, then  
they likely are also paying for an enterprise edition of their free  
OS too. Linux == Redhat was done in like 2000. Time to worry about  
other things.


People who choose Debian choose it for the freedom, the ethic, the  
brilliance of apt and in general its rock solid nature. Bosses choose  
RH, not minions.


Manoj, we love you and you are dead on here. The enterprise rocks to  
a different beat and Debian dances to another. This is not a bad  
thing. Keep making the good choices and the right people will keep  
making the decision to use Debian.


/me wishes he could find the time to contribute again.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Florian Weimer]

* Pierre Habouzit:

> On Tue, Apr 10, 2007 at 09:09:23AM +0200, Florian Weimer wrote:
>> I plan to file a couple of bugs (not too many, probably a dozen) on
>> packages which contain implementations of the patented IDEA algorithm
>> -- because the presence of that code makes them non-free.
>
>   "because" ? I fail to see the logic in there

AFAIK, the IDEA algorithm is one of those that's considered encumbered
and off-limits.

>>   As far as I know, no program in Debian actually uses this code, it's
>> just inherited from upstream libraries.
>
>   AFAICT Debian just ignores patents,

We don't ship the IDEA plugin for GnUPG for patent reasons.  This
caused a real hassle for users who migrated from PGP 2.

> else we would have to remove maybe 70% of the archive. Are IDEA
> patents actively enforced ?

Yes, they are.  There are some (no longer published) rules for gratuit
licenses, but they don't apply to Debian and its mirror network, and
certainly not to commercial downstream users.

The presence of the IDEA algorithm in cryptographic libraries is a
trap we should disarm.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Bas Zoetekouw]

Hi Florian!

You wrote:

> I plan to file a couple of bugs (not too many, probably a dozen) on
> packages which contain implementations of the patented IDEA algorithm
> -- because the presence of that code makes them non-free.  As far as I
> know, no program in Debian actually uses this code, it's just
> inherited from upstream libraries.

How does using the algorithm make the code non-free?  

-- 
Bas.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Francesco P. Lovergine]

On Tue, Apr 10, 2007 at 09:09:23AM +0200, Florian Weimer wrote:
> I plan to file a couple of bugs (not too many, probably a dozen) on
> packages which contain implementations of the patented IDEA algorithm
> -- because the presence of that code makes them non-free.  As far as I
> know, no program in Debian actually uses this code, it's just
> inherited from upstream libraries.
> 
> Are there any objections?
> 

Just check that they _CONTAIN_ implementation, not just are able to link
some external library which implements IDEA. Just for precision and 
unuseful noise.

-- 
Francesco P. Lovergine


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Jean-Christophe Dubacq]

On Tue, Apr 10, 2007 at 12:00:08AM -0700, Sean Perry wrote:
> I haven't seen much Debian in the last 6 years in the commercial  
> world. RH rules that roost. If people have chosen closed source, then  
> they likely are also paying for an enterprise edition of their free  
> OS too. Linux == Redhat was done in like 2000. Time to worry about  
> other things.

I work in a science lab and can tell you that even though we do have
commercial software (Matlab, Maple, CPlex and other scientific
computation programs, some of which are at least twenty years ahead of
any free equivalent), we do use debian and from there also use it
elsewhere (our homes, our students' workstations, etc.). Should we
become unable to do our daily job with Debian, yes, we would have to
switch distributions, which would be a pity since this is a place where
computer scientists are made.

Commercial software also owns some specific corners of the software
world, some of which not Windows-centric (or even Redhat-centric). Do
not make it more like it.

That being said, these software are more like to do the 64bit transition
(computing really requires mem; only last week were we speaking of
buying a 128 GiB computer).
-- 
JCD


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#416841: Need help with MySQL upgrade tests on 2.4 kernel

[Christian Hammers]

On 2007-04-09 Steve Langasek wrote:
> On Mon, Apr 09, 2007 at 01:28:18PM +0200, Christian Hammers wrote:
> > > Mmm, guess I wasn't clear -- I mean that there's no point in trying to 
> > > work
> > > on this bug, because lenny *as a whole* will not support 2.4 kernels.  
> > > (the
> > > glibc maintainers are eager to drop LinuxThreads support, which means 
> > > lenny
> > > will stop supporting threading on 2.4 within days/weeks of the etch
> > > release.)
> 
> > What I feared was the upgrade process itself. I guess that mysql and the
> > new 2.6 kernel will get installed in the same "apt-get dist-upgrade" run
> > and thus if mysql-server-5.0 hangs and the user presses ctrl-c he is left
> > with a half broken system.
> 
> It *doesn't* *matter*.  Running etch with a 2.4 kernel is not officially
> supported;

I talk about the upgrade from *sarge* to etch!
The bug report was against the etch version of mysql and the release notes 
do not demand a kernel upgrade to 2.6 before even starting the dist-upgrade
from sarge to etch. Chapter 4.1.5 just says that kernel 2.4.1 is required
before upgrading. Etch to lenny is of course no problem.

So depending on what I further find out, I propose a upload to 4.0r1 and/or a
note in the release notes for mysql.

bye,

-christian-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Tshepang Lekhonkhobe]

On 4/10/07, Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote:

On Tue, Apr 10, 2007 at 12:00:08AM -0700, Sean Perry wrote:
> I haven't seen much Debian in the last 6 years in the commercial
> world. RH rules that roost. If people have chosen closed source, then
> they likely are also paying for an enterprise edition of their free
> OS too. Linux == Redhat was done in like 2000. Time to worry about
> other things.

I work in a science lab and can tell you that even though we do have
commercial software (Matlab, Maple, CPlex and other scientific
computation programs, some of which are at least twenty years ahead of
any free equivalent), we do use debian and from there also use it
elsewhere (our homes, our students' workstations, etc.). Should we
become unable to do our daily job with Debian, yes, we would have to
switch distributions, which would be a pity since this is a place where
computer scientists are made.


I'm pretty interested in knowing which programs are so advanced as to
being 20 years ahead of libre equivalents, and why, if you don't mind.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#418517: ITP: gnunet-qt -- QT frontend to GNUnet

[Arnaud Kyheng]

Package: wnpp
Severity: wishlist
Owner: Arnaud Kyheng <[EMAIL PROTECTED]>


* Package name: gnunet-qt
  Version : 0.7.1c
  Upstream Author : Christian Grothoff <[EMAIL PROTECTED]>
* URL : http://www.gnunet.org/
* License : GPL
  Programming Lang: C++
  Description : QT frontend to GNUnet


-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /etc/udev/rules.d non-symlinks

[Loïc Minier]

On Mon, Apr 09, 2007, Joey Hess wrote:
> The intent is to let users disable a udev rule by removing the symlink, or
> reorder a rule to a different number by renaming the symlink. Putting a rules
> conffile directly in /etc/udev/rules.d/ wouldn't allow for this, and as Marco
> says in #359614, this "may be useful. Or at least appeared to be useful when
> I designed this." My question is simply whether anyone actually finds this
> useful?

 Can we encode the number in the rule itself?  Perhaps in the comments
 at the top of the file.
   This would allow dpkg to handle numbering changes correctly.

-- 
Loïc Minier
"For subalterns, saying something intelligent is as risky as saying something
 stupid."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Jean-Christophe Dubacq]

On Tue, Apr 10, 2007 at 11:40:27AM +0200, Tshepang Lekhonkhobe wrote:
> On 4/10/07, Jean-Christophe Dubacq <[EMAIL PROTECTED]> 
> wrote:
> >On Tue, Apr 10, 2007 at 12:00:08AM -0700, Sean Perry wrote:
> >> I haven't seen much Debian in the last 6 years in the commercial
> >> world. RH rules that roost. If people have chosen closed source, then
> >> they likely are also paying for an enterprise edition of their free
> >> OS too. Linux == Redhat was done in like 2000. Time to worry about
> >> other things.
> >
> >I work in a science lab and can tell you that even though we do have
> >commercial software (Matlab, Maple, CPlex and other scientific
> >computation programs, some of which are at least twenty years ahead of
> >any free equivalent), we do use debian and from there also use it
> >elsewhere (our homes, our students' workstations, etc.). Should we
> >become unable to do our daily job with Debian, yes, we would have to
> >switch distributions, which would be a pity since this is a place where
> >computer scientists are made.
> 
> I'm pretty interested in knowing which programs are so advanced as to
> being 20 years ahead of libre equivalents, and why, if you don't mind.

For example, CPlex (a mathematical programming optimizer) is considered
much better than any free (even free as beer) program, having no
equivalent for e.g. quadratic constraints problems.

Maple is also considered much more advanced than Octave especially
toolboxes available only in Maple.

I may have exaggerated by saying 20 years, but I will not settle for
less than 10. And we need those anyway to compare results obtained by
one software against the other.

The reason for the advance is that the most brilliant people of one
small research field unite to build some software company. They recruit
the most brilliant students, and can keep this for a long time (not
eternally, I believe, but long enough). Maple, Cplex and Matlab all date
from before 1990 where free software became (at least in france) commmon
place enough so that new projects (see Scilab) would be at least partly
open source.

-- 
JCD


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Three-package clearance sale

[Nacho Barrientos Arias]

On Mon, Apr 09, 2007 at 08:46:23PM -0400, Jose Luis Rivas Contreras wrote:
> Clint Adams escribió:
> > zsh30 - zsh 3.0
> 
> Hi, this includes all zsh packages? or just zsh30?...

Obviously, src:zsh30 covers 3.0 branch and src:zsh provides 4.x.

-- 
bye,
   - Nacho 
 http://criptonita.com/~nacho


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Marco d'Itri]

On Apr 10, Florian Weimer <[EMAIL PROTECTED]> wrote:

> I plan to file a couple of bugs (not too many, probably a dozen) on
> packages which contain implementations of the patented IDEA algorithm
> -- because the presence of that code makes them non-free.  As far as I
> know, no program in Debian actually uses this code, it's just
> inherited from upstream libraries.
Is there actually a patent violation if the code is not used?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Neil Williams]

On Tue, 10 Apr 2007 14:17:13 +0200
[EMAIL PROTECTED] (Marco d'Itri) wrote:

> On Apr 10, Florian Weimer <[EMAIL PROTECTED]> wrote:
>
> > I plan to file a couple of bugs (not too many, probably a dozen) on
> > packages which contain implementations of the patented IDEA
> > algorithm -- because the presence of that code makes them
> > non-free.  As far as I know, no program in Debian actually uses
> > this code, it's just inherited from upstream libraries.

> Is there actually a patent violation if the code is not used?

Distributing the code could still be an issue - the problem with
patents in general is that you won't find out for real until it gets
before a court.

IANAL, but being open source, a patent lawyer would probably try to
claim that distributing the code ALLOWS the infringement of the patent
as if that makes Debian complicit in the infringement. Whether the code
actually does include an implementation of the patented algorithm
hasn't been confirmed here - it could just be a linkage.

Which are the offending libraries? Is this mass-bug-filing intended to
be against the applications that link against the libraries or just the
offending libraries themselves? If the applications don't use that code,
I don't see that the maintainer of that application can do a lot about
the 'bug'. Why do the upstream libraries contain an implementation of
the algorithm in the first place? Wouldn't it be better to have dfsg
versions of such libraries? (i.e. I'd support the bug filing against
the specific libraries for this purpose.) If the code isn't used, it
should be trivial to create a patch that simply comments it out or
removes it entirely. Or to prevent a SONAME bump, replace the function
definition with a no-op/error.

--


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpP7R0uQEh1T.pgp
Description: PGP signature

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Florian Weimer]

* Neil Williams:

> Which are the offending libraries?

Botan, Crypto++, BouncyCastle, a few Perl-related packages.

> Is this mass-bug-filing intended to be against the applications that
> link against the libraries or just the offending libraries
> themselves?

Just the libraries.  Debian's crypto libraries haven't got many
reverse dependencies anyway.  There's a slight chance that
BouncyCastle's PGP functionality is impacted.  (Old PGP is the only
de-facto standard that once promoted the adoption of IDEA.)

> Why do the upstream libraries contain an implementation of the
> algorithm in the first place?

In case of BouncyCastle, it's probably related to its PGP support.
The others include it purely for coverage, I guess.

> Or to prevent a SONAME bump, replace the function definition with a
> no-op/error.

No-op could be quite harmful.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#418552: ITP: umit -- nmap frontend, developed in Python and GTK

[Bernd Zeimetz]

Package: wnpp
Severity: wishlist
Owner: Bernd Zeimetz <[EMAIL PROTECTED]>

* Package name: umit
  Version : 0.9.3-rc2
  Upstream Author : Adriano Monteiro <[EMAIL PROTECTED]>
* URL : http://umit.sourceforge.net/
* License : GPL2, and LGPL for the higwidgets library 
  Programming Lang: Python
  Description : nmap frontend, developed in Python and GTK

UMIT's goal is to provide a nmap frontend that is really useful for
advanced users and easy to be used by newbies. With UMIT, a network
admin could create scan profiles for faster and easier network
scanning or even compare scan results to easily see any changes.
A regular user will also be able to construct powerful scans with
UMIT command creator wizards.


* The python-higwidgets package will be created from the umit source,
  too


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Tshepang Lekhonkhobe]

On 4/10/07, Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote:

On Tue, Apr 10, 2007 at 11:40:27AM +0200, Tshepang Lekhonkhobe wrote:
> On 4/10/07, Jean-Christophe Dubacq <[EMAIL PROTECTED]>
> wrote:
> >I work in a science lab and can tell you that even though we do have
> >commercial software (Matlab, Maple, CPlex and other scientific
> >computation programs, some of which are at least twenty years ahead of
> >any free equivalent), we do use debian and from there also use it
> >elsewhere (our homes, our students' workstations, etc.). Should we
> >become unable to do our daily job with Debian, yes, we would have to
> >switch distributions, which would be a pity since this is a place where
> >computer scientists are made.
>
> I'm pretty interested in knowing which programs are so advanced as to
> being 20 years ahead of libre equivalents, and why, if you don't mind.

For example, CPlex (a mathematical programming optimizer) is considered
much better than any free (even free as beer) program, having no
equivalent for e.g. quadratic constraints problems.

Maple is also considered much more advanced than Octave especially
toolboxes available only in Maple.

I may have exaggerated by saying 20 years, but I will not settle for
less than 10. And we need those anyway to compare results obtained by
one software against the other.


This is interesting. I often hear people citing pros and cons of FLOSS
and commercial stuff, but don't remember anyone stating such
extravagant development gaps as 10 years or so. I'd like to hear
opinions of others who have also used those Cplex Maple, and whatever
else you may have in mind. This however brings to mind libre CAD stuff
which truly lags behind.


The reason for the advance is that the most brilliant people of one
small research field unite to build some software company. They recruit
the most brilliant students, and can keep this for a long time (not
eternally, I believe, but long enough). Maple, Cplex and Matlab all date
from before 1990 where free software became (at least in france) commmon
place enough so that new projects (see Scilab) would be at least partly
open source.


I've got an idea that some software is targeted at such a narrow
userbase (CAD for example) that volunteer development seemes
unjustified. In such cases, it's nice when academy and business lend
their hand.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#418552: ITP: umit -- nmap frontend, developed in Python and GTK

[Stefano Zacchiroli]

On Tue, Apr 10, 2007 at 03:31:02PM +0200, Bernd Zeimetz wrote:
>   Description : nmap frontend, developed in Python and GTK

Is it interesting for the user/sysadm that the frontend is developed in
Python? I would remote that (while I will keep the reference to GTK) and
perhaps adding something about the intended targets: both advanced users
and newbies.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Create Makefile (rules)

[Rodrigo Tavares]

Hello,

I'm studying about the rules files (makefiles), in
debian.

I´d like, use a file ex1.c, and create a makefile for
run make command then build a binary, and install it
in a filesystem place.

Wih my study, i read than Makefile.am is necessary 
for rules ?

Bye

Faria

__
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /etc/udev/rules.d non-symlinks

[Marco d'Itri]

On Apr 09, Joey Hess <[EMAIL PROTECTED]> wrote:

> I'm proposing that we change our de-facto policy for handling of files
> in /etc/udev/rules.d. Currently it is this (from udev's README.Debian):
It's OK, I planned to discuss this after the release.
Experience showed that generally other packages do not need an easy way
to disable their whole rules files, so I think we can conclude that
usage of symlinks can be restricted to some of udev's own files and
eventually packages with special needs.
Do we need special code to move the conffiles on upgrades (and only do
that if the symlink does not exist)?

At the same time it would be a good idea to change the XXX_ file name
scheme to a saner one, since currently they all share 0??_ or z??_
prefixes to coexsist with the existing prefix-less files.
Probably we should just copy the scheme used by Ubuntu, but I am not
sure if there is a good way to do it.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Warren Turkal]

On Tuesday 10 April 2007 07:43, Tshepang Lekhonkhobe wrote:
> > I may have exaggerated by saying 20 years, but I will not settle for
> > less than 10. And we need those anyway to compare results obtained by
> > one software against the other.
>
> This is interesting. I often hear people citing pros and cons of FLOSS
> and commercial stuff, but don't remember anyone stating such
> extravagant development gaps as 10 years or so. I'd like to hear
> opinions of others who have also used those Cplex Maple, and whatever
> else you may have in mind. This however brings to mind libre CAD stuff
> which truly lags behind.

People wouldn't use those programs more than the free equivalents if there 
weren't some reason. Sometimes that reason is that the proprietary solution 
has a larger library of extras (libs, etc.) around it that makes it easier to 
quickly do something without reinventing the wheel. Sometimes the reason is 
as simple as someone doesn't want to have to learn a new software package or 
port all there stuff to a new software. These are hard barriers to overcome.

wt
-- 
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#418552: ITP: umit -- nmap frontend, developed in Python and GTK

[Bernd Zeimetz]

Stefano Zacchiroli wrote:
> On Tue, Apr 10, 2007 at 03:31:02PM +0200, Bernd Zeimetz wrote:
>   
>>   Description : nmap frontend, developed in Python and GTK
>> 
>
> Is it interesting for the user/sysadm that the frontend is developed in
> Python? I would remote that (while I will keep the reference to GTK) and
> perhaps adding something about the intended targets: both advanced users
> and newbies.
>   

Good idea, how does

Description: nmap frontend for advanced users and newbies

sound?

cheers,

Bernd 

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Luis Matos]

Ter, 2007-04-10 às 08:28 -0600, Warren Turkal escreveu:
> On Tuesday 10 April 2007 07:43, Tshepang Lekhonkhobe wrote:
> > > I may have exaggerated by saying 20 years, but I will not settle for
> > > less than 10. And we need those anyway to compare results obtained by
> > > one software against the other.
> >
> > This is interesting. I often hear people citing pros and cons of FLOSS
> > and commercial stuff, but don't remember anyone stating such
> > extravagant development gaps as 10 years or so. I'd like to hear
> > opinions of others who have also used those Cplex Maple, and whatever
> > else you may have in mind. This however brings to mind libre CAD stuff
> > which truly lags behind.
> 
> People wouldn't use those programs more than the free equivalents if there 
> weren't some reason. Sometimes that reason is that the proprietary solution 
> has a larger library of extras (libs, etc.) around it that makes it easier to 
> quickly do something without reinventing the wheel. Sometimes the reason is 
> as simple as someone doesn't want to have to learn a new software package or 
> port all there stuff to a new software. These are hard barriers to overcome.

Maybe software vendors will look at linux for more power for less
hardware, using 64 bit solution.

Talking about CAD and CAM, for example, they need too much of power,
even if machines are currently enought.

Having linux to complete use 64 bit solutions may open a door for
software vendors to built their applications on linux.

Free cad implementations are too simple for use in some industrial
environments, when programs like CATIA or Solidorks, or inventor, Come
in Mind.
These programs are expensive and require power that can be better used
in 64 bit platform.

CATIA has unix versions ... i don't really know if they will ever have
linux versions.

best regards

Luis Matos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Jean-Christophe Dubacq]

On Tue, Apr 10, 2007 at 04:36:06PM +0100, Luis Matos wrote:
> Ter, 2007-04-10 às 08:28 -0600, Warren Turkal escreveu:
> > On Tuesday 10 April 2007 07:43, Tshepang Lekhonkhobe wrote:
> > > > I may have exaggerated by saying 20 years, but I will not settle for
> > > > less than 10. And we need those anyway to compare results obtained by
> > > > one software against the other.
> > >
> > > This is interesting. I often hear people citing pros and cons of FLOSS
> > > and commercial stuff, but don't remember anyone stating such
> > > extravagant development gaps as 10 years or so. I'd like to hear
> > > opinions of others who have also used those Cplex Maple, and whatever
> > > else you may have in mind. This however brings to mind libre CAD stuff
> > > which truly lags behind.
> > 
> > People wouldn't use those programs more than the free equivalents if there 
> > weren't some reason. Sometimes that reason is that the proprietary solution 
> > has a larger library of extras (libs, etc.) around it that makes it easier 
> > to 
> > quickly do something without reinventing the wheel. Sometimes the reason is 
> > as simple as someone doesn't want to have to learn a new software package 
> > or 
> > port all there stuff to a new software. These are hard barriers to overcome.
> 
> Maybe software vendors will look at linux for more power for less
> hardware, using 64 bit solution.

I already said (in this thread) that these software are already
linux-friendly, proposing several versions compiled against varying
glibc, and probably do exist for 64 bits. If we use these, it is that
they work under the current Debian distribution. What I was afraid of,
was to forget that even the academic world cannot always abide the pure
only-free software rule. The progress of science is more important (in
the context of academic research) than the pureness of freedom.

I recognize that this is "niche software" (English is not my native
language, I hope this is the right term), but this is important "niche
software". As said above, academics prefere using free software, but 
will use what is the most advanced if necessary. For example, gcc is the
compiler of choice, but for some cases icc is deemed necessary.

My point is: do what Debian must, but do not consider breaking
commercial software lightly, and do not think that freedom is all what
is required by some well-known target audience such as universities.
Tolerance is as great a value (in some contexts).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

"Tshepang Lekhonkhobe" <[EMAIL PROTECTED]> writes:

> I've got an idea that some software is targeted at such a narrow
> userbase (CAD for example) that volunteer development seemes
> unjustified. In such cases, it's nice when academy and business lend
> their hand.

There just isn't enough interest among people who would be able for a
project like a parametric 3D CAD modeller.  The only project I know of
is Varkon (http://www.tech.oru.se/cad/varkon/man.htm).  When I tried
it a while back I gave up.  It wasn't very intuitive and I didn't have
much time.  There is active development but it is not a solid
modeller.

Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: release update: security problems force "etch" delay of 4-6 weeks

[Michelle Konzack]

The one WHO had send this messages should DOWNWRITE 100 TIMES
the RFC since the "Message-ID:" header is invalid!

It show: Message-ID: [EMAIL PROTECTED]
but it should:   Message-ID: <[EMAIL PROTECTED]>

And then, I like Ice-Cream and the "From:" was jumping directly
into my eyes... :-)

Happy joking around
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant



Am 2007-03-31 17:04:13, schrieb Debian release team:
> Hi,
> 
> We want to start off this mail by thanking everyone who has put
> effort into fixing our outstanding release-critical bugs, the
> maintainers who have respected the freeze upload policy, and
> everyone else who contributed to Debian "etch" so far.
> 
> That was the good news. Unfortunately, there is also the bad side:
> due to several grave security problems in some of the core packages,
> we cannot release "etch" as originally planned[0] on 2 Apr 2007. By
> rough calculation, we are looking at another 4-6 weeks of work to
> get our archive into a releasable state.
> 
> *** Note that Debian "sarge" is *not* affected by any of this. ***
> 
> Due to the critical nature of the problems found, we deem it
> appropriate to choose the path of responsible disclosure and thus
> cannot give further details at this moment. Please stay tuned for
> updates in the next few days.
> 
> We will continue to stay in deep freeze meaning that you must
> continue to observe the upload policies. You are most welcome to use
> the extra time to flesh out and make some love to the release notes.
> 
> We are sorry for any inconvenience, but we can assure you that you
> are not the only one screwed on this lovely April Sunday morning.
> 
> Your release team.
> 
> 0. http://lists.debian.org/debian-devel-announce/2007/03/msg00012.html
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
- END OF REPLIED MESSAGE -



-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Frank Küster]

Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote:

> My point is: do what Debian must, but do not consider breaking
> commercial software lightly, and do not think that freedom is all what
> is required by some well-known target audience such as universities.
> Tolerance is as great a value (in some contexts).

It's even in our constitution that our priorities are *both* our Users
and Free Software, and it's in the first clause that "We will support
people who create or use both free and non-free works on Debian."

There might be technical problems, which should be named, discussed and
resolved - but I think it's beyond doubt that we will not intentionally
drop support for things like Maple. Or even Mathematica, which
approximately 20 years of development ahead of Maple ;-)

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

Luis Matos <[EMAIL PROTECTED]> writes:

> Free cad implementations are too simple for use in some industrial
> environments, when programs like CATIA or Solidorks, or inventor, Come
> in Mind.
> These programs are expensive and require power that can be better used
> in 64 bit platform.

64bit Linux has been available since years.  Pro/E is available for
32bit RHEL only.  UGS NX was to be ported to Linux as well, but I
couldn't find any information on their website.  It seems like you
have to log in first and you have to be a customer for that.

So why is nobody adopting 64bit Linux (or *BSD)?

Autodesk will not even have a win64 port of Inventor with the upcoming
release.  They do have one for AutoCAD.  I doubt Autodesk will ever
port their software to Linux.  They are tied up with MS all over.
Inventor requires MS Excell and it uses VBA.  Their data management
system requires MS IIS and MS SQL Server.  They are just switching
from OpenGL to DirectX...

AFAIK it doesn't look much better for SolidWorks.

Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Kurt Roeckx]

On Tue, Apr 10, 2007 at 03:01:41PM +0200, Florian Weimer wrote:
> * Neil Williams:
> 
> > Which are the offending libraries?
> 
> Botan, Crypto++, BouncyCastle, a few Perl-related packages.

Openssl's README.Debian contains:
Some algorithms used in the library are covered by patents.  As
a result, the following algorithms in libcrypto have been disabled:
- RC5
- MDC2
- IDEA

(See bug #65368)

As far as I understand, they have been disabled because at that time,
it seems we only cared about using those, not about distributing them.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Create Makefile (rules)

[Daniel Leidert]

Am Dienstag, den 10.04.2007, 10:26 -0300 schrieb Rodrigo Tavares:

> I'm studying about the rules files (makefiles), in
> debian.
> 
> I´d like, use a file ex1.c, and create a makefile for
> run make command then build a binary, and install it
> in a filesystem place.
> 
> Wih my study, i read than Makefile.am is necessary 
> for rules ?

No. The .am means "_a_uto_m_ake template". Such files need to be
processed with automake first. If you just want to write a simple
Makefile, then call it "Makefile" (see `man make') and add the rules to
create your binary to the file. The make-doc package will help you and
tell you more about built-in rules. See especially section 2 for a
sample Makefile.

Regards, Daniel

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Steve Langasek]

On Tue, Apr 10, 2007 at 01:51:13PM +0100, Neil Williams wrote:

> IANAL, but being open source, a patent lawyer would probably try to
> claim that distributing the code ALLOWS the infringement of the patent
> as if that makes Debian complicit in the infringement.

Er, by definition a patent is supposed to include a complete description of
the invention that would permit a third-party to reimplement the invention,
in exchange for granting the inventor exclusive rights to the invention for
a limited time.  Would you argue that distributing copies of the patent
application is infringement, too?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Draft spec for new dpkg "triggers" feature (v2, repost)

[Ian Jackson]

In late January and February we had a thread about my proposals for a
new dpkg triggers feature.  Thanks very much to everyone who provided
feedback.

Following some very cogent criticisms from Florent Rougon I posted a
significantly version on the 2nd of March but we were all too busy
trying to release and/or being flamed, and it seems that no-one read
my article.  At least, no-one replied.  So herewith a repost with a
slightly wider distribution.

I'd appreciate it if particularly people who maintain large groups of
packages which might use the triggers feature would take some time to
read my draft specification and comment on it.  If you don't tell me
now why it's broken then please don't blame me later after I've
implemented it and it ate your system :-).

Followups should probably go to debian-dpkg.

Thanks,
Ian.


TRIGGERS


Introduction


A dpkg trigger is a facility that allows events caused by one package
but of interest to another package to be recorded and aggregated, and
processed later by the interested package.  This feature simplifies
various registration and system-update tasks and reduces duplication
of processing.

(NB: Triggers are intended for events that occur during package
installation, not events that occur in general operation.)


Concepts


Each trigger is named, and at any time zero or more packages may be
interested in it.

We currently envisage three kinds of triggers:
 * Explicit triggers.  These can be activated by any program
   by running dpkg-trigger (at any time, but ideally from a maintainer
   script).
 * File triggers.  These are activated automatically by dpkg
   when a matching file is installed, upgraded or removed as part
   of a package.  They may also be explicitly activated by running
   dpkg-trigger.
 * Special triggers, which activate magic code in dpkg itself.
   Currently none of these are defined.

A trigger is always activated by a particular package.

Trigger names contain only printing 7-bit ascii characters (no
whitespace).  Each trigger kind has a distinct subset of the trigger
name space so that the kind can be determined from the name.  After we
run out of straightforward syntaxes, we will use :.

When a trigger is activated, it becomes pending for every package
which is interested in the trigger at that time.  Each package has a
list of zero or more pending triggers.  Repeated activation of the
same trigger has no additional effect.  Note that in general a trigger
will not be processed immediately when it is activated; processing is
deferred until it is convenient (as described below).

At a trigger activation, the activating interested packages(s) are
added to the activating package's list of triggers-awaited packages;
the activating package is said to await the trigger processing.

A package which has pending triggers, or which awaits triggers, is not
considered properly installed.  There are two new dpkg status values,
`triggers-pending' and `triggers-awaited', which lie between
`config-failed' and `installed'.


Details - Overview table


 Status   Pending   Awaited   Satisfies  Remedy
   triggers  triggers  Depends

  unpacked  never   maybe   Nopostinst configure
  c.-failed never   maybe   Nopostinst configure (when requested)
  t.-awaitedno  always  Nopostinst triggered + fix awaited pkg(s)
  t.-awaitedyes always  Nofix awaited package(s)
  t.-pendingalways  never   Yes   postinst triggered
  installed never   never   Yes   n/a



Details - triggering package


When a package T activates a trigger in which an package I is
interested, I is added to the list of packages whose trigger
processing is awaited by T.  Zero or more packages I may be added as a
result of any particular trigger activation, depending on how many
packages were interested.

A package which awaits trigger processing but would otherwise be
`installed' or `triggers-pending' is considered to be in state
`triggers-awaited'.  Packages in `triggers-awaited' do not satisfy
Depends dependencies.

Every triggered package I in T's list of awaited packages either has a
nonempty list of pending triggers, or is in `config-failed' or worse.
When I enters `installed' (or `config-files' or `not-installed'), the
entry in T's list of awaited packages is removed so that T may, if it
no longer awaits any packages, become `installed' or
`triggers-pending'.


Details - triggered package
---

When one of the triggers in which a package is interested is activated
the triggered package goes has the trigger added to its list of
pending triggers.  Packages with a nonempty list of pending triggers
which would otherwise be in state `installed' are in state
`triggers-pending' instead, so if the package was previously
`installed' it becomes `triggers-pending'.

If a package has nonempty lists both of pending and awaited triggers,
then it is in `t

Re: Bug#416841: Need help with MySQL upgrade tests on 2.4 kernel

[Steve Langasek]

On Tue, Apr 10, 2007 at 10:39:10AM +0200, Christian Hammers wrote:

> On 2007-04-09 Steve Langasek wrote:
> > On Mon, Apr 09, 2007 at 01:28:18PM +0200, Christian Hammers wrote:
> > > > Mmm, guess I wasn't clear -- I mean that there's no point in trying to 
> > > > work
> > > > on this bug, because lenny *as a whole* will not support 2.4 kernels.  
> > > > (the
> > > > glibc maintainers are eager to drop LinuxThreads support, which means 
> > > > lenny
> > > > will stop supporting threading on 2.4 within days/weeks of the etch
> > > > release.)

> > > What I feared was the upgrade process itself. I guess that mysql and the
> > > new 2.6 kernel will get installed in the same "apt-get dist-upgrade" run
> > > and thus if mysql-server-5.0 hangs and the user presses ctrl-c he is left
> > > with a half broken system.

> > It *doesn't* *matter*.  Running etch with a 2.4 kernel is not officially
> > supported;

> I talk about the upgrade from *sarge* to etch!
> The bug report was against the etch version of mysql

No, it wasn't; it was reported against a version of mysql that was only in
sid.

Now if there's a reason to believe it also applies to the etch version of
the package, then ok; but that's not the version it was filed against.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#416841: Need help with MySQL upgrade tests on 2.4 kernel

[Lennart Sorensen]

On Tue, Apr 10, 2007 at 11:47:33AM -0700, Steve Langasek wrote:
> No, it wasn't; it was reported against a version of mysql that was only in
> sid.
> 
> Now if there's a reason to believe it also applies to the etch version of
> the package, then ok; but that's not the version it was filed against.

Yes 5.0.38 fails on a 2.4 kernel, 5.0.32 does not fail on a 2.4 kernel.
Sarge->Etch works fine.  Etch->Sid does not work with a 2.4 kernel for
mysql anymore.

It may still be interesting to know what changed in mysql to make it
break, just to make sure it doesn't come back to haunt it later.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Matthias Julius]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Er, by definition a patent is supposed to include a complete description of
> the invention that would permit a third-party to reimplement the invention,
> in exchange for granting the inventor exclusive rights to the invention for
> a limited time.  Would you argue that distributing copies of the patent
> application is infringement, too?

While you are probably free to distribute the description you are not
free to distribute an implementation of the technology claimed by the
patent.  You can implement it but you can not distribute the
implementation.

Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Felipe Sateler]

Tshepang Lekhonkhobe wrote:

> On 4/10/07, Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote:

>> For example, CPlex (a mathematical programming optimizer) is considered
>> much better than any free (even free as beer) program, having no
>> equivalent for e.g. quadratic constraints problems.
>>
>> Maple is also considered much more advanced than Octave especially
>> toolboxes available only in Maple.
>>
>> I may have exaggerated by saying 20 years, but I will not settle for
>> less than 10. And we need those anyway to compare results obtained by
>> one software against the other.
> 
> This is interesting. I often hear people citing pros and cons of FLOSS
> and commercial stuff, but don't remember anyone stating such
> extravagant development gaps as 10 years or so. I'd like to hear
> opinions of others who have also used those Cplex Maple, and whatever
> else you may have in mind. This however brings to mind libre CAD stuff
> which truly lags behind.

Maple is far away from any competitor I've seen. It provides you with
anything you need plus everything you want, works in a nice environment and
provides you with a _very_ comprehensive help. I have yet to find any free
equivalent that has these three features. Of course, this is speaking from
the standpoint of a 3rd-year undergrad and not from a scientific lab
researcher. I haven't seen equivalent functionality to Maple 6 yet, which
was released on 1999, which gives you the first 8 of the minimum 10
required by Jean-Christoph.


-- 

  Felipe Sateler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Ben Hutchings]

[Cc'd to debian-legal in the hope of some informed comment.]

On Tue, 2007-04-10 at 14:53 -0400, Matthias Julius wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > Er, by definition a patent is supposed to include a complete description of
> > the invention that would permit a third-party to reimplement the invention,
> > in exchange for granting the inventor exclusive rights to the invention for
> > a limited time.  Would you argue that distributing copies of the patent
> > application is infringement, too?
> 
> While you are probably free to distribute the description you are not
> free to distribute an implementation of the technology claimed by the
> patent.  You can implement it but you can not distribute the
> implementation.

There is an argument that source code can only be a description whereas
a binary is an implementation, so only distributing binaries that
include the claimed invention could infringe.  I'm not sure whether this
has been legally tested.

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.


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

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Robert Millan]

On Mon, Apr 09, 2007 at 05:20:34PM -0400, Lennart Sorensen wrote:
> > The fact that Microsoft has chosen to remove win64 completely from the 
> > retail
> > boxes for Vista is very significative.
> 
> No, they include it in ultimate (it has both DVDs)

Ultimate is not targetted at the consumer market.

> and they will mail it
> to any customer for cost of shipping it if you want 64bit instead.

So you have to buy the retail CD, then send your request for a 64bit version,
and wait a week or so without being able to use what you just bought?  How
many people are going to do that?

> I
> think they mainly did it to avoid tech support calls when something
> doesn't work for 64bit.

They did it because it's not ready.  If they were confident that they had a
usable [1] product, they wouldn't make users jump through hoops to get it,
since they know perfectly that they need to increase their win64 userbase.

[1] and the requirements for win32 vista were already quite low, it seems

> > It doesn't really matter.  If we win the 64bit battle, when microsoft wants 
> > to
> > migrate to 64-bit, they'll find that this niche is already occupied, and 
> > that
> > the reference API is another one.  Then they can clone us if they want to 
> > try
> > something :-)
> 
> Well I think users of applications like solidworks, lightwave, maya,
> etc, just might use win64 and be quite happy with it.  Not a huge
> market, but not nothing either.

That's fine.  And they can have servers too.  They're just not ready for the
consumer market, in which you have to support a gazillon of hardware devices
whose drivers or specs are not under their control.

> I doubt this will be small enough that
> linux can automatically win the 64bit OS market.  And if people start
> demanding 64bit support they will find a way to get a machien that does
> work with 64bit windows and get the applications they want.

There's no demand for it.  The average user is not like a free software
developer.  They don't want to try something that's barely tested and has
serious problems just because.  All their apps are 32-bit, so they gain
almost nothing in compensation.

> > Yes.  And we're backwards compatible (wine can run win32 binaries) too.  The
> > real problem is, can they be compatible with x86_64-linux-gnu api ?
> 
> Why would they care to be?  That isn't their market.

If x86_64-linux-gnu is stablished as the new reference api, well, they'll
be forced to.

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Florian Weimer]

* Kurt Roeckx:

> As far as I understand, they have been disabled because at that
> time, it seems we only cared about using those, not about
> distributing them.

Disabling it and telling users the reason in the package documentation
is sufficient, I guess.

Is there consensus that we shouldn't ship compiled object code, in
ready to link form?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Robert Millan]

On Mon, Apr 09, 2007 at 06:39:16PM -0400, Jim Crilly wrote:
> > Well I think users of applications like solidworks, lightwave, maya,
> > etc, just might use win64 and be quite happy with it.  Not a huge
> > market, but not nothing either.  I doubt this will be small enough that
> > linux can automatically win the 64bit OS market.  And if people start
> > demanding 64bit support they will find a way to get a machien that does
> > work with 64bit windows and get the applications they want.
> 
> And don't forget games. Game developers will start releasing 64-bit binaries
> and gamers will eat them up just because 64 > 32. So the Win64 market will
> have a fair amount of users in the not too distant future.

Gamers can try anything they like, be it win64 or *-linux-gnu.  But if it
turns out that most of their hardware doesn't work with it, that's the end
of their adventure.  In the past years we have improved a lot on this area,
but win64 is basicaly starting now.  Do you see microsoft reverse-engineering
every printer, scanner, joystick, etc that users bought without win64
drivers?  They'll have to either do that, or wait untill all these hardware
becomes obsolete and is replaced.

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Robert Millan]

On Mon, Apr 09, 2007 at 04:59:57PM -0400, Matthias Julius wrote:
> 
> But anyway, what do we care?  I have my working 64bit platform.

It currently works for more people than win64 does, that's for sure.  The
question is if it'll maintain this edge during the next two years.

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Robert Millan]

On Mon, Apr 09, 2007 at 10:17:15PM -0500, Manoj Srivastava wrote:
> 
> Helping closed source software developers is not an itch I feel
>  like scratching.  But if other people want to spend time making things
>  easy for closed software, I am of course not going to stand in their
>  way, no matter what my opinions on such activities are.

We're _not_ helping them by any means.  We're _not_ promoting non-free software
either.

We're just being realistic in that in the next 2 years they [1] can benefit
_us_ by driving their existing userbase into our platform.

[1] and yes, "they" doesn't necessarily mean non-free.  It can be GPLed
vendors too, and it's in fact very likely since these happens to be the
same that also target i386-linux-gnu (think of Id software now).

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)

[Robert Millan]

On Mon, Apr 09, 2007 at 09:54:20PM -0400, Matthias Julius wrote:
> Santiago Vila <[EMAIL PROTECTED]> writes:
> 
> > On Mon, 9 Apr 2007, Matthias Julius wrote:
> >
> >> I hate to reboot just to try out d-i. :-)
> >
> > Actually, you don't have to. Try qemu.
> 
> Ahh, true.  That's another chapter I havn't looked into, yet.

  sudo apt-get install qemu
  qemu -cdrom debian.iso

That's all :-)

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

Robert Millan <[EMAIL PROTECTED]> writes:

> If x86_64-linux-gnu is stablished as the new reference api, well, they'll
> be forced to.

Reference for what?  Is there any software vendor porting his
applications to 64bit Linux because of problems with win64?  I havn't
noticed any.  Proprietary software that is available for Linux is only
available for i386 in most cases.

I don't know what the critical mass of Linux users is that generates
interest for Linux among software vendors.  We seem to be far from
it.  

Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Matthias Julius]

Ben Hutchings <[EMAIL PROTECTED]> writes:

> There is an argument that source code can only be a description whereas
> a binary is an implementation, so only distributing binaries that
> include the claimed invention could infringe.  I'm not sure whether this
> has been legally tested.

If this holds true that would mean Debian could distribute the source
as long it is disabled and not compiled into the binary.

Personally, I don't think that argument is valid.  What about
interpreted languages where only the source is shipped anyway?  This
would mean you don't need to care about patents as long as you
implement it in e.g. Python.  I don't think that will withstand a
legal trial.  But, I am no lawyer.

Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Luis Matos]

Most people and main developpers only know windows' tools for
development, that's for sure.

I am currently developping an industrial application for windows and
linux, because i forced the use of gtk (so i can develop and run it on
linux), but my boss is forcing me to only develop in and for windows,
because it is the OS that everybody uses ...
It doesn't matter if there is a dependence on windows, if there re other
better oeses ... many industrial tools are developped in visual
basic ... things like CNC software controlers.

Can linux and opensource OS compete with the facility to develop in
windows?

Ter, 2007-04-10 às 12:25 -0400, Matthias Julius escreveu:
> Luis Matos <[EMAIL PROTECTED]> writes:
> 
> > Free cad implementations are too simple for use in some industrial
> > environments, when programs like CATIA or Solidorks, or inventor, Come
> > in Mind.
> > These programs are expensive and require power that can be better used
> > in 64 bit platform.
> 
> 64bit Linux has been available since years.  Pro/E is available for
> 32bit RHEL only.  UGS NX was to be ported to Linux as well, but I
> couldn't find any information on their website.  It seems like you
> have to log in first and you have to be a customer for that.
> 
> So why is nobody adopting 64bit Linux (or *BSD)?
> 
> Autodesk will not even have a win64 port of Inventor with the upcoming
> release.  They do have one for AutoCAD.  I doubt Autodesk will ever
> port their software to Linux.  They are tied up with MS all over.
> Inventor requires MS Excell and it uses VBA.  Their data management
> system requires MS IIS and MS SQL Server.  They are just switching
> from OpenGL to DirectX...
> 
> AFAIK it doesn't look much better for SolidWorks.
> 
> Matthias
> 
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Martijn van Oosterhout]

On 4/10/07, Felipe Sateler <[EMAIL PROTECTED]> wrote:

Maple is far away from any competitor I've seen. It provides you with
anything you need plus everything you want, works in a nice environment and
provides you with a _very_ comprehensive help. I have yet to find any free
equivalent that has these three features.


The makers are also very clever. Students can often get a licence for
Maple on their own machines for "free" (it's being paid elsewhere).
This kind of targets the group who would be most interested in writing
a replacement.

And lets face it, what Maple does is hard. I really wouldn't know
where to begin. However, there are a lot of programs that implement
peices:

http://web.usna.navy.mil/~wdj/opensource_math.html

It's just a matter of getting one of them to a point where it's useful...

Have a nice day,
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Debian Buzz and Rex binary packages

[Aurélien GÉRÔME]

Hi everyone,

For a little silly experiment, I would like to know whether someone
still has the official debs of Buzz and Rex around.

The old releases archive at [1] has the official debs starting from Bo,
but not before, and Google only finds some debs for 0.91 and Buzz at
[2].

Cheers,

[1] 
[2] 
-- 
 .''`.   Aurélien GÉRÔME
: :'  :
`. `'`   Free Software Developer
  `- Unix Sys & Net Admin


signature.asc
Description: Digital signature

Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)

[Matthias Julius]

Robert Millan <[EMAIL PROTECTED]> writes:

> On Mon, Apr 09, 2007 at 09:54:20PM -0400, Matthias Julius wrote:
>> Santiago Vila <[EMAIL PROTECTED]> writes:
>> 
>> > On Mon, 9 Apr 2007, Matthias Julius wrote:
>> >
>> >> I hate to reboot just to try out d-i. :-)
>> >
>> > Actually, you don't have to. Try qemu.
>> 
>> Ahh, true.  That's another chapter I havn't looked into, yet.
>
>   sudo apt-get install qemu
>   qemu -cdrom debian.iso
>
> That's all :-)

Life can be so easy.

Thanks,

Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Russ Allbery]

Tshepang Lekhonkhobe <[EMAIL PROTECTED]> writes:
> On 4/10/07, Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote:

>> For example, CPlex (a mathematical programming optimizer) is considered
>> much better than any free (even free as beer) program, having no
>> equivalent for e.g. quadratic constraints problems.
>> 
>> Maple is also considered much more advanced than Octave especially
>> toolboxes available only in Maple.
>> 
>> I may have exaggerated by saying 20 years, but I will not settle for
>> less than 10. And we need those anyway to compare results obtained by
>> one software against the other.

> This is interesting. I often hear people citing pros and cons of FLOSS
> and commercial stuff, but don't remember anyone stating such
> extravagant development gaps as 10 years or so. I'd like to hear
> opinions of others who have also used those Cplex Maple, and whatever
> else you may have in mind. This however brings to mind libre CAD stuff
> which truly lags behind.

I'm not sure I agree with 10 years.  R caught up with its commercial
competitors in less time than that, to a degree that some of our users who
used to use S or Splus are now using R instead by preference.

However, I agree that there's currently no free equivalent for CPlex/AMPL,
which is a real shame given how useful it is.

This general area (high-end computational and mathematical software) is a
difficult area for free software to compete; it requires specialized
knowledge, there are often a lot of advanced techniques involved that are
specific to narrow fields of interest, there are well-established and
well-entrenched commercial systems available, and the programs solve
problems that aren't normally free software developer itches.  It's a
little like the Peoplesoft/SAP/Oracle Financials space that way.

There are a few signs of progress, but except for a few standouts (R, for
instance), people who use free software in these spaces are more often
using it specifically because it's free, not because it's better.  And
it's hard to build critical mass with only those users in niche software
markets.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /etc/udev/rules.d non-symlinks

[Daniel Burrows]

On Tue, Apr 10, 2007 at 12:11:57PM +0200, Loïc Minier <[EMAIL PROTECTED]> was 
heard to say:
> On Mon, Apr 09, 2007, Joey Hess wrote:
> > The intent is to let users disable a udev rule by removing the symlink, or
> > reorder a rule to a different number by renaming the symlink. Putting a 
> > rules
> > conffile directly in /etc/udev/rules.d/ wouldn't allow for this, and as 
> > Marco
> > says in #359614, this "may be useful. Or at least appeared to be useful when
> > I designed this." My question is simply whether anyone actually finds this
> > useful?
> 
>  Can we encode the number in the rule itself?  Perhaps in the comments
>  at the top of the file.
>This would allow dpkg to handle numbering changes correctly.

  You could look at how file-rc handles a similar problem -- IIRC it
replace update-init.d with a script that edits a file in /etc.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]