Re: Debian ISOs

[Josselin Mouette]

First of all, please use a MUA that doesn't break threads.

Le mercredi 23 août 2006 à 08:10 +0200, Mgr. Peter Tuharsky a écrit :
> If that's intended, then it needs to be done in such a way that even 
> low-to-moderately-skilled user can set it up with ease.
> 
> I know it's silly to even mention that, but unfortunatelly, user 
> friendliness and good documentation (good for users, not only for 
> developers!) are still, ehm, not a matter of course.

With proper software installed on the system (whatever the system is),
downloading with bittorrent is just a matter of clicking on the link.

> I'm not being a geek, however, aren't there some better protocols than 
> bittorent?

Bittorrent is by far the most efficient protocol when it comes to large
file distribution.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Debian ISOs

[Mgr. Peter Tuharsky]

> First of all, please use a MUA that doesn't break threads.

I'm using Thunderbird and don't intend to switch.

> Bittorrent is by far the most efficient protocol when it comes to large
> file distribution.

OK

Josselin Mouette  wrote / napísal(a):

First of all, please use a MUA that doesn't break threads.

Le mercredi 23 août 2006 à 08:10 +0200, Mgr. Peter Tuharsky a écrit :
If that's intended, then it needs to be done in such a way that even 
low-to-moderately-skilled user can set it up with ease.


I know it's silly to even mention that, but unfortunatelly, user 
friendliness and good documentation (good for users, not only for 
developers!) are still, ehm, not a matter of course.


With proper software installed on the system (whatever the system is),
downloading with bittorrent is just a matter of clicking on the link.

I'm not being a geek, however, aren't there some better protocols than 
bittorent?


Bittorrent is by far the most efficient protocol when it comes to large
file distribution.



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

Re: Status of BSD-like licences with advertisement clauses.

[Ganesan Rajagopal]

> Steve Langasek <[EMAIL PROTECTED]> writes:

> On Wed, Aug 23, 2006 at 09:20:02AM +0900, Charles Plessy wrote:
>> I have been told by two different developers that licences using the
>> 4-clauses BSD licence as a template are free or non-free

> Sounds like some DD could use a licensing refresher course. 4-clause BSD has
> always been considered free by Debian.

However it's not GPL compatible. May be that's the source of confusion?

Ganesan

-- 
Ganesan Rajagopal


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

Re: dh_python and python policy analysis

[Josselin Mouette]

Le samedi 12 août 2006 à 19:29 +0300, Lars Wirzenius a écrit :
> la, 2006-08-12 kello 18:10 +0200, Pierre Habouzit kirjoitti:
> > > >/usr/share/pycentral
> > > >/usr/share/python-support
> > >
> > > These location are tool specific and should not be referenced
> > > explicitely in the packaging scripts (debian/rules)
> > 
> > agreed
> 
> python-support seems to require me to put something
> into /usr/share/python-support (either the .py files, or a .dirs file
> for a package with private modules). How should I put them there without
> mentioning the location explicitly?

The location is specific to the packaging tool and shouldn't be
mentioned in the policy.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Status of BSD-like licences with advertisement clauses.

[Bernhard R. Link]

* Ganesan Rajagopal <[EMAIL PROTECTED]> [060823 10:40]:
> >> I have been told by two different developers that licences using the
> >> 4-clauses BSD licence as a template are free or non-free
> 
> > Sounds like some DD could use a licensing refresher course. 4-clause BSD has
> > always been considered free by Debian.
> 
> However it's not GPL compatible. May be that's the source of confusion?

It's not only GPL-incompatible, it is also ugly and actively
discouraged by most people. It's more or less a debt of history.
If it wasn't around for so long before people started to think about
free software, I doubt it would have gotten its blessing.

So its good for main, but please still try to convice everyone involved
to drop it.

Hochachtungsvoll,
  Bernhard R. Link

-- 
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.


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

Re: Debian ISOs

[Christian Perrier]

> several servers at once with one download. We should instead push
> bittorrent as the main distribution media for ISOs.


I have a few doubts about the knowledge of the average user for
Bittorrent. For sure, having BitTorrent helps reducing the load
because all users that have some know-how with it will use it...but
making it the main distribution mode...ahem.I think that most of
the users will stick to ISO images downloads.




signature.asc
Description: Digital signature

Re: Debian ISOs

[Gabor Gombas]

On Wed, Aug 23, 2006 at 11:30:53AM +0200, Christian Perrier wrote:

> I have a few doubts about the knowledge of the average user for
> Bittorrent. For sure, having BitTorrent helps reducing the load
> because all users that have some know-how with it will use it...but
> making it the main distribution mode...ahem.I think that most of
> the users will stick to ISO images downloads.

Many users do not know what an ISO image is, either. If someone creates
a nice frontend with a big button saying "Push me to download & burn the
latest Debian CD/DVD", users won't care if it uses bittorrent in the
background.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -

Re: Debian ISOs

[Christian Perrier]

> Many users do not know what an ISO image is, either. If someone creates


My knowledge of the average user (one of the few things I claim to
have quite big experience of) is that they do. Especially, the "Bob
User" who's the D-I team favourite user (the user that's not
a complete nerd with computers and is, or thinks (s)he is, a skilled
Windows user).

I agree that Joe Dumbuser doesn't know what is an ISO image but, most
often, (s)he will get the CD from a Bob User..:-)




signature.asc
Description: Digital signature

Re: Debian ISOs

[Josselin Mouette]

Le mercredi 23 août 2006 à 11:30 +0200, Christian Perrier a écrit :
> I have a few doubts about the knowledge of the average user for
> Bittorrent. For sure, having BitTorrent helps reducing the load
> because all users that have some know-how with it will use it...but
> making it the main distribution mode...ahem.I think that most of
> the users will stick to ISO images downloads.

When a nice bittorrent frontend is installed, the user will only have to
click on the link to start the download. This is true for Windows and
Linux.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Debian ISOs

[Christian Perrier]

Quoting Josselin Mouette ([EMAIL PROTECTED]):

> When a nice bittorrent frontend is installed, the user will only have to
> click on the link to start the download. This is true for Windows and
> Linux.


I don't doubt it..:-)

But I doubt that many users have a nice Bittorrent frontend and, what
I'm really sure of, many users cannot indeed use Bittorrent (which
protocol is quite certainly filtered on many corporate networks).

Again, my point is really that promoting BitTorrent as the only way to
download images of Debian CD/DVD would really be bad...and promiting
it as the very preferred way would be quite unwise if the
"traditional" download of ISO images is too hidden.




signature.asc
Description: Digital signature

Re: Re: Quickcam pro 4000, pwc problem

[John Talbut]

Thanks both for your help.  Unfortunately it has not worked.

>>   2.  Setting up module-assistant:
>>
>> apt-get install module-assistant
>> m-a prepare
>>
>>   3.  Downloading and building the external sources:
>>
>> apt-get install pwc-source
>> m-a build pwc-source
>>
>>   4.  Installing the built module:
>>
>> m-a install pwc-source

I did these (using aptitude rather than apt-get).  The install exited with an 
error.  A relevant line in the log is:


install: cannot stat `pwc.ko': No such file or directory

I have searched the system for a pwc.ko file, but it does not seem to have been 
compiled.  Any suggestions?


I have
CONFIG_USB_PWC=y
set for the kernel, which I recompiled for another reason yesterday.  Would this 
stop the module compiling?


John


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

Re: Re: Quickcam pro 4000, pwc problem

[Tanguy Moal]

Hello,I haveCONFIG_USB_PWC=yset for the kernel, which I recompiled for another reason yesterday.  Would this
stop the module compiling?I am not sure, but I think this should be set to "m" rather than "y" (the difference is that the former builds a module, while the later adds support for this driver builtin to the kernel.
Therefore, no more pwc.ko (because hardcoded into the kernel image) and it's not possible to use a third party driver to handle the target device...You should reconfigure and re make-kpkg your kernel with support for pwd as a module.
Hope this helps...JohnTanguy 

Re: Debian ISOs

[Hendrik Sattler]

Am Mittwoch 23 August 2006 12:41 schrieb Josselin Mouette:
> Le mercredi 23 août 2006 à 11:30 +0200, Christian Perrier a écrit :
> > I have a few doubts about the knowledge of the average user for
> > Bittorrent. For sure, having BitTorrent helps reducing the load
> > because all users that have some know-how with it will use it...but
> > making it the main distribution mode...ahem.I think that most of
> > the users will stick to ISO images downloads.
>
> When a nice bittorrent frontend is installed, the user will only have to
> click on the link to start the download. This is true for Windows and
> Linux.

If, not when. There is no bittorrent client in any Suggests: or Recommends: 
line of any of the browsers in Debian. And I guess that most system do not 
have one intalled.
However, http and ftp will always work as that is the same method as the one 
used to access the download page.

HS

Re: Quickcam pro 4000, pwc problem

[Eduard Bloch]

#include 
* John Talbut [Wed, Aug 23 2006, 11:59:43AM]:
> Thanks both for your help.  Unfortunately it has not worked.
> 
> >>   2.  Setting up module-assistant:
> >>
> >> apt-get install module-assistant
> >> m-a prepare

> I did these (using aptitude rather than apt-get).  The install exited with 
> an error.  A relevant line in the log is:
> 
> install: cannot stat `pwc.ko': No such file or directory

m-a stores last build logs, do:
ls /var/cache/modass/*pwc* 

Find the relevant log and file a bug report (with reportbug), attaching
this file.

Eduard.

-- 
 frobnic: du kennst nightmare on elm street mit freddy krooger?


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

Re: dh_python and python policy analysis

[Lars Wirzenius]

ke, 2006-08-23 kello 10:46 +0200, Josselin Mouette kirjoitti:
> Le samedi 12 août 2006 à 19:29 +0300, Lars Wirzenius a écrit :
> > la, 2006-08-12 kello 18:10 +0200, Pierre Habouzit kirjoitti:
> > > > >/usr/share/pycentral
> > > > >/usr/share/python-support
> > > >
> > > > These location are tool specific and should not be referenced
> > > > explicitely in the packaging scripts (debian/rules)
> > > 
> > > agreed
> > 
> > python-support seems to require me to put something
> > into /usr/share/python-support (either the .py files, or a .dirs file
> > for a package with private modules). How should I put them there without
> > mentioning the location explicitly?
> 
> The location is specific to the packaging tool and shouldn't be
> mentioned in the policy.

Sure, that's fine: no need to mention it in policy. What was said
earlier in the thread was that the locations should not be referenced in
debian/rules, either, and that makes things difficult.

-- 
Latest nerd movie: Once were hackers


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

need for your services

[Federica Fainardi]

Dear Sirs,

 

I'm writing you on behalf of International Telecommunications System
Sam, a Monaco Principality-based company, with several years' experience
to its credit in the pre-paid international phone card and phone centre
sector. 

 

We are looking for someone who can install and configure the "LINUX
ES4.1" operating system on a new server situated in our POP, in London. 

After the installation, we need to reach the server through Internet,
with an IP public address, to administrate it from far away.

Unfortunately, among our technical staff there is no one who knows LINUX
system, that's why we are asking for your help.

 

This is a very important and urgent issue for us.

Please, answer us as soon as possible.

 

Best Regards,  

 

 

 

Federica FAINARDI
International Telecommunications System Sam
Gildo Pastor Center
7, Rue du Gabian
98000 Monaco

www.its.mc
Tel: +377 97985233
Fax: +377 97985240

 

 

 

Federica FAINARDI
ITS Sam
Gildo Pastor Center
7, Rue du Gabian
98000 Monaco

www.its.mc
Tel: +377 97985233
Fax: +377 97985240

 

Re: need for your services

[Christoph Berg]

Re: Federica Fainardi 2006-08-23 <[EMAIL PROTECTED]>
> We are looking for someone who can install and configure the "LINUX
> ES4.1" operating system on a new server situated in our POP, in London. 

Dear sir,

we do not offer end user support ourselves. We have compiled a list of
companies who do so, though:

http://www.debian.org/consultants/

Please refer to them.

(On a sidenote, Linux ES is a Redhat product, you might want to check
www.redhat.com.)

Yours, Christoph Berg
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


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

Re: Time to rethink ifupdown

[Alexey Feldgendler]

On Sun, 20 Aug 2006 16:03:49 +0700, Jon Dowland <[EMAIL PROTECTED]> wrote:


I've been wondering for a while if it might not be possible
to develop a more up-to-date ifup/down that would a)
maintain suitability for non-graphical environments and b)
have enough functionality, cross-distro, to be useful as a
back-end for NM, as I'm pretty uncomfortable with having all
the logic in the same tool as the whizzy interface.


What's missing from the current ifupdown which stops it from being useful  
as a backend for NM?



However, ifupdown is Priority: important and Section: base,
meaning that it shall be frozen [2] and that redevelopment
will have to target etch+1.


Of course, redesign of ifupdown is too big a thing to be pushed into etch.  
I wasn't even thinking of that.



--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com


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

Re: Time to rethink ifupdown

[Alexey Feldgendler]

On Sun, 20 Aug 2006 16:11:16 +0700, David Goodenough  
<[EMAIL PROTECTED]> wrote:



Obviously if you are configuring a server you do not want others than the
administrator setting up the network, but if you are the sole user of a
laptop there needs to be a safe way for the user (non-technical) to do
this as the user moves from one location to another.

One option that has occurred to me is to establish a group which is  
allowed
to edit /etc/network/interfaces.  The obvious problem with this is the  
up and
down commands, which allow any program to be run as root.  Fortunately  
there
is an answer, which is to use the "macro" facility that ifupdown has  
(the one
used for wireless-xxx) and then it gets controllable and therefore safe  
(if
used properly).  This would need either to abandon up and down all  
together
or to have a switch (presumable in /etc/defaults/ifupdown) which enabled  
the

use of this group and disabled the use of up and down.


When a laptop user moves between usual locations, there should be no need  
to edit /etc/network/interfaces. If you mean adding new locations, there  
really should be user-friendly tools which do it.



--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com


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

Re: Time to rethink ifupdown

[Alexey Feldgendler]

On Sun, 20 Aug 2006 16:20:26 +0700, martin f krafft <[EMAIL PROTECTED]>  
wrote:



Please take a look at http://wiki.debian.org/netconf .

It would be great if you could help flesh out that page with your
excellent arguments and thoughts. Also, if you are interested in
working on netconf (which currently noone is), I'd be happy to
dedicate some time to it.


I would add my thoughts there but currently I know nothing about netconf  
beyond what's written on that page now. What is the scope of netconf? Is  
it supposed to supersede ifupdown, supplement it, or be an alternative? Is  
anything already implemented, or is it only an idea for now? Is there a  
reason to start developing a new tool instead of enhancing ifupdown?



Can I forward your post to the netconf mailing list?


Yes, you're welcome. I've just subscribed to that list, BTW.


--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com


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

Re: Time to rethink ifupdown

[martin f krafft]

also sprach Alexey Feldgendler <[EMAIL PROTECTED]> [2006.08.23.1610 +0100]:
> I would add my thoughts there but currently I know nothing about netconf  
> beyond what's written on that page now. What is the scope of netconf? Is  
> it supposed to supersede ifupdown, supplement it, or be an alternative? Is  
> anything already implemented, or is it only an idea for now? 

It's an idea with the final goal to provide most of what
ifupdown+guessnet+resolvconf do now, with better integration with
wireless-tools/wpasupplicant and ifplugd, and a proper interface for
user interfaces. A bit like network-manager, but done the Debian
way.

> Is there a  reason to start developing a new tool instead of
> enhancing ifupdown?

Is there a reason to cling to ifupdown?

netconf will be compatible.

> >Can I forward your post to the netconf mailing list?
> 
> Yes, you're welcome. I've just subscribed to that list, BTW.

Mh, I don't have it anymore, of course. If you still do, please
bounce it.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
drink canada dry! you might not succeed, but it *is* fun trying.


signature.asc
Description: Digital signature (GPG/PGP)

Re: Time to rethink ifupdown

[Alexey Feldgendler]

On Wed, 23 Aug 2006 22:17:23 +0700, martin f krafft <[EMAIL PROTECTED]>  
wrote:



I would add my thoughts there but currently I know nothing about netconf
beyond what's written on that page now. What is the scope of netconf? Is
it supposed to supersede ifupdown, supplement it, or be an alternative?  
Is anything already implemented, or is it only an idea for now?



It's an idea with the final goal to provide most of what
ifupdown+guessnet+resolvconf do now,


I would personally add ifrename to this list.


with better integration with wireless-tools/wpasupplicant and ifplugd,


...but, actually, I think that everything should be "integrated" by adding  
files to .d-style directories like resolvconf is integrated into ifupdown,  
rather than "built in" like basic configuration of IPv4 interfaces is  
built into ifupdown.



and a proper interface for user interfaces.


What do you mean under this?


Is there a  reason to start developing a new tool instead of
enhancing ifupdown?



Is there a reason to cling to ifupdown?


I guess that there is: there is a substantial amount of code written and  
tested, and ifupdown is widely accepted. OTOH, Debian never was a  
conservative distro, so all kind of things can be changed.



Yes, you're welcome. I've just subscribed to that list, BTW.



Mh, I don't have it anymore, of course. If you still do, please
bounce it.


Done.


--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com


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

Re: Time to rethink ifupdown

[martin f krafft]

also sprach Alexey Feldgendler <[EMAIL PROTECTED]> [2006.08.23.1634 +0100]:
> >It's an idea with the final goal to provide most of what
> >ifupdown+guessnet+resolvconf do now,
> 
> I would personally add ifrename to this list.

I would suggest udev instead.

> >with better integration with wireless-tools/wpasupplicant and
> >ifplugd,
> 
> ...but, actually, I think that everything should be "integrated"
> by adding  files to .d-style directories like resolvconf is
> integrated into ifupdown,  rather than "built in" like basic
> configuration of IPv4 interfaces is  built into ifupdown.

yes, and as it is, I consider it pretty hacky. Don't worry, I am
a fan of componentised architectures and plugins. :)

> >and a proper interface for user interfaces.
> 
> What do you mean under this?

Like a HAL interface, or a socket, so we can have GNOME/KDE
applications easily configure networks on laptops.

> >>Is there a  reason to start developing a new tool instead of
> >>enhancing ifupdown?
> 
> >Is there a reason to cling to ifupdown?
> 
> I guess that there is: there is a substantial amount of code
> written and  tested, and ifupdown is widely accepted.

ifupdown does many things right. But it also needs a brushup. I just
prefer to start with a clean slate. You are free to do otherwise, or
team up with me. Ah, Free software. :)

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
stupidity management for the superuser
is a user space issue in unix systems.
   -- alan cox


signature.asc
Description: Digital signature (GPG/PGP)

Re: Time to rethink ifupdown

[Alexey Feldgendler]

On Wed, 23 Aug 2006 22:45:52 +0700, martin f krafft <[EMAIL PROTECTED]>  
wrote:



I would personally add ifrename to this list.



I would suggest udev instead.


This means you're suggesting a whole new aspect of functionality to be  
introduced to udev, because udev is currently, AFAIK, only for creating  
device nodes under /dev/.



and a proper interface for user interfaces.



What do you mean under this?



Like a HAL interface, or a socket, so we can have GNOME/KDE
applications easily configure networks on laptops.


Why is a socket better than proper UNIX-way command-line interface?  
(Proper UNIX-way includes producing machine-friendly output.)



Is there a reason to cling to ifupdown?



I guess that there is: there is a substantial amount of code
written and  tested, and ifupdown is widely accepted.



ifupdown does many things right. But it also needs a brushup. I just
prefer to start with a clean slate. You are free to do otherwise, or
team up with me. Ah, Free software. :)


As for me, I would personally prefer starting a new project like netconf  
in C or some other imperative language rather than contributing to  
ifupdown -- I'm not very good with the concept of literal programming. I  
believe that a good, solid programming style allows to express an  
algorithm better than paragraphs of prose. (That's just my personal  
opinion.)



--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com


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

Re: Time to rethink ifupdown

[martin f krafft]

also sprach Alexey Feldgendler <[EMAIL PROTECTED]> [2006.08.23.1659 +0100]:
> This means you're suggesting a whole new aspect of functionality
> to be  introduced to udev, because udev is currently, AFAIK, only
> for creating  device nodes under /dev/.

cat /etc/udev/rules.d/z25_persistent-net.rules

> >Like a HAL interface, or a socket, so we can have GNOME/KDE
> >applications easily configure networks on laptops.
> 
> Why is a socket better than proper UNIX-way command-line
> interface?  (Proper UNIX-way includes producing machine-friendly
> output.)

One does not prevent the other. It's better because the command line
is not really event-driven, nor is it always easy to work with
permissions.

> As for me, I would personally prefer starting a new project like
> netconf  in C or some other imperative language rather than
> contributing to  ifupdown -- I'm not very good with the concept of
> literal programming. I  believe that a good, solid programming
> style allows to express an  algorithm better than paragraphs of
> prose. (That's just my personal  opinion.)

I want to use Python for netconf and possibly later port it to C++.
Definitely *not* C.

But that's me, and the above is just talk. If you disagree, use C.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"the perfect gun is an idealist without any ideal."
  -- mc 900 ft jesus


signature.asc
Description: Digital signature (GPG/PGP)

Re: Time to rethink ifupdown

[Alexey Feldgendler]

On Wed, 23 Aug 2006 23:05:31 +0700, martin f krafft <[EMAIL PROTECTED]>  
wrote:



This means you're suggesting a whole new aspect of functionality
to be  introduced to udev, because udev is currently, AFAIK, only
for creating  device nodes under /dev/.



cat /etc/udev/rules.d/z25_persistent-net.rules


I don't have that (in etch). But I've got the idea.


As for me, I would personally prefer starting a new project like
netconf  in C or some other imperative language rather than
contributing to  ifupdown -- I'm not very good with the concept of
literal programming. I  believe that a good, solid programming
style allows to express an  algorithm better than paragraphs of
prose. (That's just my personal  opinion.)



I want to use Python for netconf and possibly later port it to C++.
Definitely *not* C.

But that's me, and the above is just talk. If you disagree, use C.


No, I just used C as an example. I'm fine with any language as long as you  
can write something like "while (condition) action" in it without too much  
thinking about how this simple thing is done in this language. Python is  
just OK.



--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com


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

Re: Debian ISOs

[Bruce Sass]

On Wed August 23 2006 05:30, Hendrik Sattler wrote:
> Am Mittwoch 23 August 2006 12:41 schrieb Josselin Mouette:
> > Le mercredi 23 août 2006 à 11:30 +0200, Christian Perrier a écrit :
> > > I have a few doubts about the knowledge of the average user for
> > > Bittorrent. For sure, having BitTorrent helps reducing the load
> > > because all users that have some know-how with it will use
> > > it...but making it the main distribution mode...ahem.I think
> > > that most of the users will stick to ISO images downloads.
> >
> > When a nice bittorrent frontend is installed, the user will only
> > have to click on the link to start the download. This is true for
> > Windows and Linux.
>
> If, not when. There is no bittorrent client in any Suggests: or
> Recommends: line of any of the browsers in Debian. And I guess that
> most system do not have one intalled.
> However, http and ftp will always work as that is the same method as
> the one used to access the download page.

A browser Suggests: or Recommends: is not really needed as most 
bittorrent clients appear to be standalone programs, it is also a 
little silly for browsers to suggest or recommend clients for every 
mime-type out there.

"http and ftp will always work" is a really good point... someone 
mentioned `corporate filtering,' I think bandwidth limiting by ISPs 
would be a bigger problem. Shouldn't be a deal killer though, just 
don't use bittorrent as the only method.

Best, imo, would be a new torrent-like protocol and some serious PR to 
minimize the possibility of it being seen and used as just another p2p 
network the RIAA (whoever) doesn't like.


- Bruce

Bug#384350: ITP: luaexpat -- bindings for the expat library to the lua language

[Enrico Tassi]

Package: wnpp
Severity: wishlist
Owner: Enrico Tassi <[EMAIL PROTECTED]>


* Package name: luaexpat
  Version : 1.0.2
  Upstream Author : oberto Ierusalimschy, André Carregal and Tomás
  Guisasola as part of the Kepler Project <[EMAIL PROTECTED]>
* URL : http://www.keplerproject.org/luaexpat/
* License : MIT/X
  Programming Lang: C, lua
  Description : bindings for the expat library to the lua language

Here you can find a tentative package:
http://svn.debian.org/wsvn/pkg-lua/packages/luaexpat/?rev=0&sc=0

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-amd64-k8
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Re: Debian ISOs

[Blars Blarson]

In article <[EMAIL PROTECTED]> 
[EMAIL PROTECTED] writes:
>When a nice bittorrent frontend is installed, the user will only have to
>click on the link to start the download. This is true for Windows and
>Linux.

You left out the reconfigure the firewall(s) step.  Not only is this
non-trivial, the user may not have the ability to do so.
-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

ITP: fusedav -- userspace file system driver for mounting WebDAV shares

[Sebastian Harl]

retitle 379147 ITP: fusedav -- userspace file system driver for mounting WebDAV 
shares
owner 379147 !
thanks

> * Package name: fusedav
>   Version : 0.2
>   Upstream Author : Lennart Poettering
> * URL : http://0pointer.de/lennart/projects/fusedav/
> * License : GPL
>   Programming Lang: C
>   Description : fusedav is a Linux userspace file system driver for 
> mounting WebDAV shares.

I'm going to package this software.

Cheers,
Sebastian

--
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Re: ITP: fusedav -- userspace file system driver for mounting WebDAV shares

[Laszlo Boszormenyi]

On Wed, 2006-08-23 at 21:16 +0200, Sebastian Harl wrote:
> retitle 379147 ITP: fusedav -- userspace file system driver for mounting 
> WebDAV shares
> owner 379147 !
> thanks
[...]
> I'm going to package this software.
 Did you consult with Lennart Poettering before you take over? Anyway,
the neon dependency is OK just by now. The neon26 package is accepted
today to the archive, so you can build depend on it.

Regards,
Laszlo/GCS


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

Re: Debian ISOs

[Bruce Sass]

On Wed August 23 2006 12:32, Blars Blarson wrote:
> In article <[EMAIL PROTECTED]>
>
> [EMAIL PROTECTED] writes:
> >When a nice bittorrent frontend is installed, the user will only
> > have to click on the link to start the download. This is true for
> > Windows and Linux.
>
> You left out the reconfigure the firewall(s) step.  Not only is this
> non-trivial, the user may not have the ability to do so.

This is a bit of a red herring. Torrents work without re-configuring 
firewalls, they just don't work as well. There appears to be two 
reasons for that (all of this is, "afaict", and I've only looked at it 
superficially so far):

The desire to spread the server load over many peers and foil "leeches" 
has resulted in a policy where `the download rate is proportional to 
the upload rate.' With an unconfigured firewall the client can only 
upload to clients it is downloading from, it is the resulting limited 
upload rate which chokes the download rate. Since the policy is set by 
the tracker, and Debian would need to manage its own tracker[1], this 
problem should be managable without too many hoops.

Another reason for non-trivial reconfiguration is because clients can 
have braindead out-of-the box configurations. e.g., last time I looked 
at bittornado it was setup to randomly use any of 50,000 ports[2]. The 
user ends up needing to configure both the firewall and client to 
realize the full potential. So, if the problem above is managable, this 
one would be a non-issue.

On the other hand, if it turns out that it is not possible to overcome 
mis|unconfigured firewalls with more liberal tracker policy and/or 
client configs, it becomes a question of whether there are enough users 
able and willing to jump through the hoops to make offering the service 
worthwhile (main distribution method or not).  I dunno how to 
determine that, but active torrents of Debian .iso's do exist, see:
http://www.torrentz.com/search_debian 


- Bruce

[1] to ensure the network is not used to distribute non-Debian stuff

[2] 50,000 ports... to complicate port based bandwidth limiting or 
filtering?


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

Re: ITP: fusedav -- userspace file system driver for mounting WebDAV shares

[Sebastian Harl]

Hi,

>  Did you consult with Lennart Poettering before you take over? 

I'm not taking over this package. Lennart Poettering filed an RFP.

> Anyway, the neon dependency is OK just by now. The neon26 package is
> accepted today to the archive, so you can build depend on it.

I know. That's why I am going for the package now ;-)

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Re: Debian ISOs

[Adam Borowski]

On Wed, Aug 23, 2006 at 03:34:34PM -0600, Bruce Sass wrote:
> On Wed August 23 2006 12:32, Blars Blarson wrote:
> > In article <[EMAIL PROTECTED]>
> > [EMAIL PROTECTED] writes:
> > >When a nice bittorrent frontend is installed, the user will only
> > > have to click on the link to start the download. This is true for
> > > Windows and Linux.
> > You left out the reconfigure the firewall(s) step.  Not only is this
> > non-trivial, the user may not have the ability to do so.
> 
> This is a bit of a red herring. Torrents work without re-configuring 
> firewalls, they just don't work as well.

They don't work well if there's NAT[1] involved, you wanted to say.  Do I
need to point out a wonderful opportunity to push in some IPv6 propaganda?

Too bad, most torrent clients seem to be heavily lagging behind the rest of
network software even though it's them who would benefit the most from
peer-to-peer (duh) addressing.  Most but not all, and since you get to
choose both the tracker software and the suggested clients...


The relevant download page can say this.
* if you have only IPv4, you can still use bittorrent.  If you're behind
NAT, your download speed will suffer unless you can reconfigure your
firewall (->discussion).
* if you can't run bittorrent at all, you'll have to fall back to ->http or
->ftp.  This method should work everywhere, although it puts a strain on our
servers.
END

I hope this is dumbed down enough to handle users who would be capable to
reconfigure their firewalls in the first place.  If they have that much
clue, it's a waste to use a bittorrent-specific one-time fix instead of the
Final Solution to the NAT Question.


[1]. In the typical sense of the word, that is.
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Bug#384401: ITP: rash -- Rash is a PHP/MySQL script for the management of quotes

[Pierre-Alexandre Meyer]

Package: wnpp
Severity: wishlist
Owner: "Pierre-Alexandre Meyer" <[EMAIL PROTECTED]>

* Package name: rash
  Version : 1.2.2
  Upstream Author : Tom Cuchta <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/rqms/
* License : GPL
  Programming Lang: PHP
  Description : Rash is a PHP/MySQL script for the management of quotes
   Rash is a PHP/MySQL script for the management of quotes, similar to
   the script in use at http://www.bash.org -- but designed as an entirely
   seperate piece of code.
   It is *highly* customizable to any layout you want to throw at it.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=UTF-8) (ignored: LC_ALL set to 
fr_FR.UTF-8)


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

Bug#384407: ITP: libtest-harness-perl -- Run Perl standard test scripts with statistics

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf <[EMAIL PROTECTED]>

* Package name: libtest-harness-perl
  Version : 2.62
  Upstream Author : Andy Lester <[EMAIL PROTECTED]>
* URL : http://www.cpan.org/modules/by-module/Test
* License : Same terms as Perl itself (GPL+Artistic)
  Description : Run Perl standard test scripts with statistics

Test::Harness is an utility script invoked by Test::Simple, Test::More
and several based on Test::Builder. It is also part of the perl-modules
installation. This module is packaged to satisfy the build-dependency
of several other Perl modules over a newer version than the one
perl-modules provides - Please refer to bug #383517 for the rationale
on separately packaging it.

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.14-cajita
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Re: Time to rethink ifupdown

[Miles Bader]

martin f krafft <[EMAIL PROTECTED]> writes:
> I want to use Python for netconf and possibly later port it to C++.

Python (and any language that depends on vast amounts of installed
infrastructure) seems a bit dodgy for a core low-level facility.

I guess if you only intend to add high-level layers for GUIs and stuff
maybe it'd be OK, but it seems pretty silly to write an ifupdown
replacement in python.

-Miles
-- 
"1971 pickup truck; will trade for guns"


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

Re: Debian ISOs

[Alexey Feldgendler]

On Thu, 24 Aug 2006 00:38:59 +0700, Bruce Sass <[EMAIL PROTECTED]> wrote:

> "http and ftp will always work" is a really good point... someone
> mentioned `corporate filtering,' I think bandwidth limiting by ISPs
> would be a bigger problem. Shouldn't be a deal killer though, just
> don't use bittorrent as the only method.

If only there was some auto-negotiation method like the one HTTP provides for 
content types: IF the client is able to use bittorrent, THEN use it, ELSE use 
FTP.


-- 
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com


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

Re: These new diffs are great, but...

[Goswin von Brederlow]

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow:
>
>> What code do you need there? If the rred method keeps the full Index
>> file in memory during patching it can just be fed all the patches one
>> after another and only write out the final result at the
>> end. Combining the patches is a simple cat.
>
> #383881 suggests that I/O bandwidth is not the issue.  In fact, if you
> keep the file in memory and repeatedly patch it, you won't get away
> from the O(n*m) complexity (n being the file size, m the number of
> hunks in the patches), or whatever complexity it is.  Shuffling
> pointers instead of full lines only saves a constant factor, which
> might not be enough.
>
> However, patching rred to apply patches in a single run would be a
> good start because all further optimizations will need it.

Why should the number of chunks matter?

What matters is reading, parsing and writing the file O(lines) and
then the number of changes (lines of changes) O(changes). Combined
this gives O(lines + changes) if the file is read once at the start
and then all patches are applied.

You can do that by combining the individual patch files or by teaching
rred to do a single run with multiple patch files. Same result. Both
solve the problem of O(lines * chunks + changes) complexity.

As for using pointers to lines and shuffeling them that seems to be
the only sane thing to do. All patch operations are line based so it
is essential that a line can be found and replaced in O(1). A simple
array of pointers to lines solves that.

MfG
Goswin


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

Running x86-64 debian inside i386 pbuilder on AMD64

[Sander Marechal]

Hello,

I am looking to create .deb's for x86-64. I have an AMD64 but run an
i386 OS due to the lack of some 64-bit packages (like flash and
what-not). I have pbuilder all set up to build packages for i386, but I
wonder if it's possible to use it to create x86-64 packages as well.
After all, I do have an AMD64 so I can run x86-64 packages.

So, is it possible to bootstrap an x86-64 OS with pbuilder on an i386
system running on an AMD64?

Thanks in advance,

-- 
Sander Marechal
http://www.gnome-hearts.org/


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

Re: Time to rethink ifupdown

[Sylvain Le Gall]

Hello,

On Wed, Aug 23, 2006 at 04:45:52PM +0100, martin f krafft wrote:
> also sprach Alexey Feldgendler <[EMAIL PROTECTED]> [2006.08.23.1634 +0100]:
> > >It's an idea with the final goal to provide most of what
> > >ifupdown+guessnet+resolvconf do now,
> > 
> > I would personally add ifrename to this list.
> 
> I would suggest udev instead.
> 
> > >with better integration with wireless-tools/wpasupplicant and
> > >ifplugd,
> > 
> > ...but, actually, I think that everything should be "integrated"
> > by adding  files to .d-style directories like resolvconf is
> > integrated into ifupdown,  rather than "built in" like basic
> > configuration of IPv4 interfaces is  built into ifupdown.
> 
> yes, and as it is, I consider it pretty hacky. Don't worry, I am
> a fan of componentised architectures and plugins. :)
> 
> > >and a proper interface for user interfaces.
> > 
> > What do you mean under this?
> 
> Like a HAL interface, or a socket, so we can have GNOME/KDE
> applications easily configure networks on laptops.
> 

What about creating a DBUS interface -> it can be integrated in any
language that support it, and can be integrated in a GUI application.

Kind regard
Sylvain Le Gall


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