Pozdrav!
Imate priliku da zaradite na internetu - ali stvarno. Definitivno najbolji nacini da zardite pomocu ovog neverovatnog medija. Pogledajte i dajte mi samo 10 sekundi sanse... www.e-goldbusiness.eu Da li cete iskoristiti ovu fenomenalnu priliku u zivotu ili ne, zavis samo od Vas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
On Mon, Nov 06, 2006 at 11:34:14PM +0100, Sz?kelyi Szabolcs wrote: > can anyone tell why ftpds do conflict with each other and why httpds do > not? Actually the httpds should conflict too as they install listeners on 0.0.0.0:80. E.g.: With no httpd installed, install the apache package, apache will listen on 0.0.0.0:80; now install the thttpd package, it'll work fine, but no thttpd daemon will run afterwards, because it fails to bind to 0.0.0.0:80, see syslog; reboot the machine, and you'll be surprised to see the thttpd daemon run, and not apache, because thttpd gets started first. I still think this will fix such problems just fine: > >> http://lists.debian.org/debian-devel/2005/08/msg01314.html Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
Hello,
On Tue, 07 Nov 2006, Gerrit Pape wrote:
> On Mon, Nov 06, 2006 at 11:34:14PM +0100, Sz?kelyi Szabolcs wrote:
> > can anyone tell why ftpds do conflict with each other and why httpds do
> > not?
>
> Actually the httpds should conflict too as they install listeners on
> 0.0.0.0:80.
>
> E.g.: With no httpd installed, install the apache package, apache will
> listen on 0.0.0.0:80; now install the thttpd package, it'll work fine,
> but no thttpd daemon will run afterwards, because it fails to bind to
> 0.0.0.0:80, see syslog; reboot the machine, and you'll be surprised to
> see the thttpd daemon run, and not apache, because thttpd gets started
> first.
>
> I still think this will fix such problems just fine:
>
> > >> http://lists.debian.org/debian-devel/2005/08/msg01314.html
I notice that the maintainer of msmtp has taken the route suggested
by Gerrit Pape. (Note the package "msmtp-mta").
Another option is the one taken by {x,g,k}dm. There is an
"alternatives"-style setting that chooses the server one wants to run
by default.
One advantage of the former method is that you do not need to
co-ordinate this with other maintainers of similar servers.
One advantage of the latter method is that the users do not get
confused by "one-more-package".
Regards,
Kapil.
--
signature.asc
Description: Digital signature
Re: 2 ftpds packages conflicts
Gerrit Pape <[EMAIL PROTECTED]> writes: > On Mon, Nov 06, 2006 at 11:34:14PM +0100, Sz?kelyi Szabolcs wrote: >> can anyone tell why ftpds do conflict with each other and why httpds do >> not? > > Actually the httpds should conflict too as they install listeners on > 0.0.0.0:80. Nope, not IMHO. There are many perfectly valid reasons for running more than one httpd on a single machine. And even if you can't see one, why would you want to make it impossible (aka difficult)? > E.g.: With no httpd installed, install the apache package, apache will > listen on 0.0.0.0:80; now install the thttpd package, it'll work fine, > but no thttpd daemon will run afterwards, because it fails to bind to > 0.0.0.0:80, see syslog; reboot the machine, and you'll be surprised to > see the thttpd daemon run, and not apache, because thttpd gets started > first. So? It's up to the adminstrator to configure the packages after installation. The default of 0.0.0.0:80 may work as expected in some cases, but the package maintainer cannot guarantee this. And that has nothing to do with other installed packages. The maintainer just can't know what the administrator expects. Yes, this does go for the ftpds too. I don't see any reason why you'd want more than one, but I don't really see any reason to impose the restriction either. If the ftpds can be configured to listen to anything else than 0.0.0.0:21, then the administrator should be allowed to install more than one of them. A warning about the need for manual configuration in the case of a port/address conflict is probably a good idea, though. Bjørn -- Don't you realise that Heidegger's ghost is living in your punk haircut? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
* Mike Hommey ([EMAIL PROTECTED]) [061106 22:00]: > On Mon, Nov 06, 2006 at 09:01:27AM -0800, Russ Allbery <[EMAIL PROTECTED]> > wrote: > > Mike Hommey <[EMAIL PROTECTED]> writes: > > > Russ Allbery <[EMAIL PROTECTED]> wrote: > > > > >> +the -a and -o test > > >> operators > > >> + must be supported > > > > > Why is that needed ? > > > > It's in widespread use in both Debian scripts and in upstream scripts. > > When we tried to warn about this behavior in lintian, it turned up > > hundreds of packages and we got a lot of objections to the check on the > > grounds that dash supports this construct and the only shell that doesn't > > is posh. It seemed like the general consensus was that requiring that all > > those scripts be modified to require bash was more trouble than it was > > worth. > > Well we got bug reports for that on firefox, IIRC, and we changed it, > that was not a real problem to replace [ some != test -a other = test ] > with [ some != test ] && [ other = test ]... I agree -a/-o should be replaced, but I don't think we really consider it an RC bug. So, a shell *must* support the operators, but I don't think that we should encourage people to use them. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
* Russ Allbery ([EMAIL PROTECTED]) [061106 23:40]: > My impression of the previous Policy discussion was that there was not a > consensus around this change, so I'm trying to reach a consensus around a > simpler incremental change that deals with one problem (while still > leaving others opened). This should in no way be taken as a cutting off > of debate of the larger issue. I agree with you that we should try to get rid of the "simple issues" so that we we have both an already updated policy and can see what the larger issues really are. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Nov 07, Andreas Barth <[EMAIL PROTECTED]> wrote: > I agree -a/-o should be replaced, but I don't think we really consider No, they should NOT be replaced. There is no sensible reason to not use them. -- ciao, Marco signature.asc Description: Digital signature
IPW3945
Hi, I am wondering what is the status/current work being done on supporting the ipw3945 wireless card on Debian. In non-free I can find the firmware package, but I couldn't find the non-free regulatory daemon nor the free kernel driver. I would like to work on that, but I don't want to duplicate work. The only thing I could find was http://www.wooyd.org/debian/ipw3945-daemon/ And currently, there are problems with the debian version of 80211 and the 1.0 driver from intel, that prevented me from compiling it by hand. This is a very common card and I would like to see it fully supported in Debian -- Martín Ferrari
Re: Bug#397291: ITP: php-tidy -- tidy module for php[45]
Hi Joey, On Tuesday 07 November 2006 07:32, Joey Schulze wrote: > > > Why would you want to upload a separate source package? > > > > That seems to be used to do. See php-imap or php-pspell! > > Uh? What's the benefit of the duplicated source? Personly I did prefer to provide tidy support for php on-tree. But if the "Debian PHP Maintainers" prefer it off-tree, I'm also fine. ~/debian-builds/php5-tidy/build-area$ ls -la *orig* -rw-r--r-- 1 waja waja 20444 Nov 6 12:52 php5-tidy_5.1.6.orig.tar.gz Since the source tarball isn't that much, I think this will be not a big problem of having it twice. The advantages of maintaining it off tree is maybe, that "Debian PHP Maintainers" dont need to care about on every release. This all are my personly opinions and guesses. I think for a correct answer you need to ask the "Debian PHP Maintainers" group. With kind regards, Jan. -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GIT d-- s+: a- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ --END GEEK CODE BLOCK-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [php-maint] Re: Bug#397291: ITP: php-tidy -- tidy module for php[45]
just to throw my $0.02 in, On Tue, 2006-11-07 at 13:20 +0100, Jan Wagner wrote: > Personly I did prefer to provide tidy support for php on-tree. But if > the "Debian PHP Maintainers" prefer it off-tree, I'm also fine. > > ~/debian-builds/php5-tidy/build-area$ ls -la *orig* > -rw-r--r-- 1 waja waja 20444 Nov 6 12:52 php5-tidy_5.1.6.orig.tar.gz > > Since the source tarball isn't that much, I think this will be not a big > problem of having it twice. The advantages of maintaining it off tree is > maybe, that "Debian PHP Maintainers" dont need to care about on every > release. > > This all are my personly opinions and guesses. I think for a correct answer > you need to ask the "Debian PHP Maintainers" group. personally, i'd like to see "on-tree" the modules shipped in the php source produced by php source package, but there are some provisions: - so close to release time means we don't want php producing new binary packages to interfere with etch fixes. - there's more work than there are people/time available. - the people who are available may not have experience with the given extension and its implications. however, my views don't necessarily reflect those of the php packaging team. i also don't have the time/interest/energy to advocate for this right now, as i'm pretty busy fixing problems with the existing php packages. so unless there are any new developments i'd suggest staying with what is presently being done, and after etch maybe we can sit down and revisit this. sean signature.asc Description: This is a digitally signed message part
Re: [php-maint] Re: Bug#397291: ITP: php-tidy -- tidy module for php[45]
On Tuesday 07 November 2006 13:49, sean finney wrote: > so unless there are any new developments i'd suggest staying with what > is presently being done, and after etch maybe we can sit down and > revisit this. I totaly agree with that. My intention is, to have a working tidy module available cause my employer need one and hopefully others benefits of it. With kind regards, Jan. -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GIT d-- s+: a- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ --END GEEK CODE BLOCK-- pgp4aZJ9mKHnh.pgp Description: PGP signature
Purging configurations of non-installed transitional packages
Yodel! Since I hate having tons of configuration files lying around from my various tests (and build-dep installing orgies), I do "dpkg -l | grep ^rc | cut -f 3 -d \ | xargs dpkg -P" every now and then. Actually, I first look at the list, and this proved very important here... What happened: Somehow, I seem to have transitioned from sarge ssh to openssh-client/-server directly without first installing the 'ssh' transitional package because I installed some package which depended on openssh-client directly. With the above operation, I then tried to purge the old ssh package - which, obviously, blew my ssh configuration along with the 'sshd' user. In this case, I was prepared because I had an idea that this could happen - but nonetheless, I think it shouldn't. How to prevent this? (btw: ntp has the same problem: /var/lib/ntp was removed without me noticing. Obviously this is not near as bad, as it won't even stop ntp working) Huge hack #1: openssh-server (new package) knows the contents of the old ssh.preinst/ssh.postinst, so it could remove those file on installation or replace them by newer ones that take into account the transition. Obviously this is dangerous and should probably be secured by md5 of the known files. Huge hack #2: openssh-server/openssh-client know that they're replacing the old package. So they could just remove records of ssh from the database of installed packages by surgery. I feel that this one could even be made official if specified properly as a method to transition package names (and replacing surgery by official sourcery by dpkg). OTOH there's bound to be many pitfalls, and probably no two transitions are ever the same. Other methods? The only sane way I can think of is a hard dependency on the transitional package for a full release cycle. But that means keeping useless packages around for a long time :-( Yes, it all only was a problem because I was mixing stable and testing, but I think being able to do that is one of the biggest assets Debian GNU/Linux has over other distributions, so making this as easy as possible is A Good Thing(tm) in my book. cheers -- vbi -- featured link: http://fortytwo.ch/gpg/subkeys pgpt9tSYh1v9x.pgp Description: PGP signature
Re: 2 ftpds packages conflicts
On Tuesday, November 7, 2006 12:31 pm, Bjørn Mork wrote: > So? It's up to the adminstrator to configure the packages after > installation. > > The default of 0.0.0.0:80 may work as expected in some cases, but the > package maintainer cannot guarantee this. And that has nothing to do > with other installed packages. The maintainer just can't know what > the administrator expects. > > Yes, this does go for the ftpds too. I don't see any reason why > you'd want more than one, but I don't really see any reason to impose > the restriction either. If the ftpds can be configured to listen to > anything else than 0.0.0.0:21, then the administrator should be > allowed to install more than one of them. > > A warning about the need for manual configuration in the case of a > port/address conflict is probably a good idea, though. > Yet there are also many users, probably those who are not professional administrators, that _need_ for everything to work out of the box. Who should we help more: those who get paid to administer the machines, and are probably much more knowledable, or the occasional, home or small office user that doesn't have the knoweldge or the time to acquire it?
Re: 2 ftpds packages conflicts
On 11/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Who should we help more: those who get paid to administer the machines, and are probably much more knowledable, or the occasional, home or small office user that doesn't have the knoweldge or the time to acquire it? Why is the occasional user installing an ftp server for anyway? It's not a service you want to be installing without some basic knowledge. What is the actual risk? That someone not too knowledgable will try to install multiple servers and getting confused? 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]
Re: 2 ftpds packages conflicts
[EMAIL PROTECTED] writes: > Yet there are also many users, probably those who are not > professional administrators, that _need_ for everything to work out of the > box. > Who should we help more: those who get paid to administer the machines, > and are probably much more knowledable, or the occasional, home or > small office user that doesn't have the knoweldge or the time to acquire it? None of the suggested solutions will prevent the packages from working out of the box. No further configuration is necessary as long as there is only one package providing the httpd service installed. The question is what to do when the adminstrator wants to install a second httpd package. Should the maintainer enforce a policy using conflicts, or should the adminstrator get to choose? Either way, you can't make it work out of the box. Your choices are a) allow it to work, depending on configuration b) deny it from ever working I prefer a). Bjørn -- No nukes! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IPW3945
On Tue, Nov 07, 2006 at 08:59:15AM -0300, Martín Ferrari wrote: > And currently, there are problems with the debian version of 80211 and > the 1.0 driver from intel, that prevented me from compiling it by > hand. It's not really a problem. Just make sure that the ipw3945 is compiled with 80211 API set to version 2. The Makefile thinks only 80211 1.1.14+ have version 2 but the kernel sources are version git-1.1.13 and version 2. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > And I'm not sure that you are right with your majority claim. A lot of > larger installations use nfs and they quickly add up to a lot of > systems rivaling the rest of the user base in numbers. But, I am not sure whether you can count them all as individual installations as many of those probably get installed on one system and then copied to another. And they are managed by only a few admins. I would guess that most people who install a linux system don't need NFS. And actually, NFS us not required to run Debian. Do I don't think it needs to be in the default installation even if 70% of the users will use it. IMHO Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
Hi, On Monday 06 November 2006 18:07, Russ Allbery wrote: > + required under POSIX, hence this explicit addition. Also, > + rumour has it that this shall be mandated under the LSB > + anyway. I dont think the debian policy should spread rumours about the LSB. Either state facts from the LSB or don't mention it. regards, Holger pgpo7a9q7YngU.pgp Description: PGP signature
Re: 2 ftpds packages conflicts
Em Terça 07 Novembro 2006 10:39, Bjørn Mork escreveu: > [EMAIL PROTECTED] writes: > > Yet there are also many users, probably those who are not > > professional administrators, that _need_ for everything to work out of > > the box. Who should we help more: those who get paid to administer the > > machines, and are probably much more knowledable, or the occasional, home > > or small office user that doesn't have the knoweldge or the time to > > acquire it? > > None of the suggested solutions will prevent the packages from working > out of the box. No further configuration is necessary as long as > there is only one package providing the httpd service installed. > > The question is what to do when the adminstrator wants to install a > second httpd package. Should the maintainer enforce a policy using > conflicts, or should the adminstrator get to choose? Either way, you > can't make it work out of the box. Your choices are > a) allow it to work, depending on configuration > b) deny it from ever working > > I prefer a). I prefer a) over b), but for the sake of completeness, we should point that there is third choice: c) allow it to work, automagically determining new ports For this to work, the user would have to choose which server is the "main" one. I don't know how hard it would be, and don't think it's very useful, but it's the "perfect" solution. Tiago Saboga. PS: IANADD.
RE: Re: 2 ftpds packages conflicts
The point is apt-get let me installed it with a warning, but doesn't want to let me install anything else without removing the conflicting package it accepted to install. > > E.g.: With no httpd installed, install the apache package, > apache will > > listen on 0.0.0.0:80; now install the thttpd package, it'll > work fine, > > but no thttpd daemon will run afterwards, because it fails > to bind to > > 0.0.0.0:80, see syslog; reboot the machine, and you'll be > surprised to > > see the thttpd daemon run, and not apache, because thttpd > gets started > > first. > > So? It's up to the adminstrator to configure the packages after > installation. > > The default of 0.0.0.0:80 may work as expected in some cases, but the > package maintainer cannot guarantee this. And that has nothing to do > with other installed packages. The maintainer just can't know what > the administrator expects. > > Yes, this does go for the ftpds too. I don't see any reason why > you'd want more than one, but I don't really see any reason to impose > the restriction either. If the ftpds can be configured to listen to > anything else than 0.0.0.0:21, then the administrator should be > allowed to install more than one of them. > > A warning about the need for manual configuration in the case of a > port/address conflict is probably a good idea, though. NOTICE: This email contains privileged and confidential information and is intended only for the individual to whom it is addressed. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this transmission by mistake and delete this communication from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. AVIS: Le présent courriel contient des renseignements de nature privilégiée et confidentielle et nest destiné qu'à la personne à qui il est adressé. Si vous nêtes pas le destinataire prévu, vous êtes par les présentes avisés que toute diffusion, distribution ou reproduction de cette communication est strictement interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser immédiatement lexpéditeur et le supprimer de votre système. Notez que la transmission de courriel ne peut en aucun cas être considéré comme inviolable ou exempt derreur puisque les informations quil contient pourraient être interceptés, corrompues, perdues, détruites, arrivées en retard ou incomplètes ou contenir un virus.
Re: Downgrading the priority of nfs-utils
Roger Leigh wrote: > > What's the rationale for needing it as part of the default install? Because it's the standard GNU way of doing this kind of job? > The majority of the Debian (and GNU/Linux systems in general) I see > tend to not use NFS at all. I guess there is truth in this statement. But what else would you use for a network entirely consisting of GNU/Linux machines (lucky me)? Samba is a bridge to the proprietary world so I don't see a single reason to use it if there are no Windows hosts involved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#97500: Do not hesitate to ask for help
Earlier this year we wrote to you about our Knowledge Based Degree Program (KBDP). We thought we would follow up and see if there is any reason why you have not called our registrars office. Most people don't realize that these degrees are completely valid, and only our staff and yourself know that they are based on knowledge of the subject. If you are still interested in obtaining a degree then please give our counselors a call at anytime during the week. Counselor Office: 1-773-509-4920 Regards Margaret Jones Carlson and Rhodes Degree Services -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
On Tue November 7 2006 04:51, [EMAIL PROTECTED] wrote: > Yet there are also many users, probably those who are not > professional administrators, that _need_ for everything to work out > of the box. Who should we help more: those who get paid to administer > the machines, and are probably much more knowledable, or the > occasional, home or small office user that doesn't have the knoweldge > or the time to acquire it? Those users should be using a derivative whose business is to help. another way to look at it... Should Debian force professionals to jump through hoops for the sake of users with limited knowledge and no inclination to learn about the system they are using. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Gerrit Pape wrote: > On Mon, Nov 06, 2006 at 11:34:14PM +0100, Sz?kelyi Szabolcs wrote: >> can anyone tell why ftpds do conflict with each other and why httpds do >> not? > > Actually the httpds should conflict too as they install listeners on > 0.0.0.0:80. > > E.g.: With no httpd installed, install the apache package, apache will > listen on 0.0.0.0:80; now install the thttpd package, it'll work fine, > but no thttpd daemon will run afterwards, because it fails to bind to > 0.0.0.0:80, see syslog; reboot the machine, and you'll be surprised to > see the thttpd daemon run, and not apache, because thttpd gets started > first. There was a saying a few years ago, that comes into my mind regarding this problem. It read something like this: "Linux *is* user-friendly... not fool-friendly or looser-friendly." Now consider the two choices: a) keep Conflicts - Novice user not knowing what's happening exactly, tries to install two servers providing the same functionality. Installation will fail. User doesn't know why. - Experienced system administrator tries to install the two servers. He exactly knows what he wants. He won't be able to do so. Experienced system administrator gets mad. Someone mentioned earlier, he could rebuild at least one of the servers after removing the "Conflicts" field. Experienced system administrator gets madder. This problem typically arises in enterprise IT infrastructures, where recompiling the package every time it gets updated is *not* an option. Experienced system administrator gets absolutely mad. b) drop Conflicts - Novice user installs the packages in question. *If* he notices that there is some problem, looks at logs (as I remember, apache tells about the problem on the console, too), searches on Google, gets tons of results. After reading three of them, he knows what the problem is, he can fix it, he will *understand* what he's doing. User is happy. - Experienced system administrator installs the packages, reconfigures them to use different ports/interfaces/addresses. Experienced system administrator is happy. (*) IMHO, two servers binding to the same socket "by default", is not enough reason for them to conflict with each other. Let me remind you that the case of MTAs is another story. Bye, - -- Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFUPFhGJRwVVqzMkMRAnJwAJsFMFC1fofF/FpxjQDhPHXyU1Ze2wCfWayB muzY+HC+iCUMAX782xZDfT4= =Lp4Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
Tiago Saboga <[EMAIL PROTECTED]> writes: > I prefer a) over b), but for the sake of completeness, we should point that > there is third choice: > c) allow it to work, automagically determining new ports > > For this to work, the user would have to choose which server is the "main" > one. I don't know how hard it would be, and don't think it's very useful, but > it's the "perfect" solution. well, you don't know that the adminstrator wants to run the servers on different ports. s/he might want to run them on the default port, but binding to specific, different, ip addresses. Bjørn -- If you've seen one source license, you've seen them all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IPW3945
See #363967. I heard some doubts about panthera's ability to handle more stuff, so maybe you can offer help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils
On Tuesday 07 November 2006 10:49, Matthias Julius wrote: > But, I am not sure whether you can count them all as individual > installations as many of those probably get installed on one system > and then copied to another. And they are managed by only a few admins. Preseed is your friend. It's extremely easy to setup netboots that are customized however you want these days. There is no reason you can't install nfs stuff as part of your preseed. We use a postinstall init.d script to install extra packages we need, like gfortran and other goodies. > I would guess that most people who install a linux system don't need > NFS. I think that is a largely fair statement. None of my home systems or laptops use it. > And actually, NFS us not required to run Debian. This is the coup de grace. Why should something be essential if it is not really, well "essential"? > Do I don't think it > needs to be in the default installation even if 70% of the users will > use it. IMHO Word. 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: Downgrading the priority of nfs-utils
> "Goswin" == Goswin von Brederlow <[EMAIL PROTECTED]> writes: Goswin> But wouldn't you be surprised if "mount -tnfs server:/path Goswin> /local/path" suddenly wouldn't work anymore in a fresh Goswin> install? Not really, no. I would be more surprised if it did work. NFS has a reputation of being insecure. I am not aware of any organisations, big/small, that use NFS any more except on restricted sets of computers. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils
On Wed, Nov 08, 2006 at 10:17:55AM +1100, Brian May wrote: > I would be more surprised if it did work. NFS has a reputation of > being insecure. Try Kerberized NFS :-) > I am not aware of any organisations, big/small, that use NFS any more > except on restricted sets of computers. The university here is opening up for Kerberos-enabled NFSv4 from the entire campus network RSN. Now you know one :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes: > The university here is opening up for Kerberos-enabled NFSv4 from the entire > campus network RSN. Now you know one :-) [Isn't nfs4 rather different than previous versions, in that it's fixed some of the most egregious "nfs bogosities"?] I use nfs everyday, and in its default form it's insanely slow, completely insecure, and annoyingly clunky to administer -- but it's what people use... and there really isn't much in the way of widely available, easily deployable/maintainable, legacy-compatible alternatives. All things considered I'd rather have nfs, even in it's horrid traditional form, than nothing. -Miles -- `Cars give people wonderful freedom and increase their opportunities. But they also destroy the environment, to an extent so drastic that they kill all social life' (from _A Pattern Language_) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils
> "Miles" == Miles Bader <[EMAIL PROTECTED]> writes: Miles> [Isn't nfs4 rather different than previous versions, in Miles> that it's fixed some of the most egregious "nfs Miles> bogosities"?] I have been told NFS 4 has nothing in common with NFS except the name, and its reputation for being insecure (even if this reputation in unfair...). Miles> All things considered I'd rather have nfs, even in it's Miles> horrid traditional form, than nothing. There are still times when traditional NFS is still the best solution (disclaimer: I haven't user NFS 4). Does nfs-kernel-server support v4 yet? Back on topic, is Samba included in the default installation? If yes => should NFS be treated as lesser then Samba and not included by default? If no => why is NFS included when Samba isn't? Isn't this inconstant? Anyway, just some thoughts - personally, for the rare case I need NFS, I am happy to install it myself. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils
Matthias Julius wrote: > I would guess that most people who install a linux system don't need > NFS. > Donno. I use it on all my systems, home and otherwise; how else would I mount file servers... > And actually, NFS us not required to run Debian. Do I don't think it > needs to be in the default installation even if 70% of the users will > use it. IMHO > I think you've misunderstood the purpose of the default installation. It's not the bare minimum to make the system work (that's Essential: yes). It's the standard stuff that everyone expects to be on a UNIX system, including things like a working c & c++ compiler, etc. 70% of users using something is, IMO, a very strong argument for it to be installed by default. (Remember: installed by default does not mean you have to install it. It just means if you don't manually select packages, it will be installed). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IPW3945
On Tue, Nov 07, 2006 at 08:59:15AM -0300, Martín Ferrari wrote: > Hi, > > I am wondering what is the status/current work being done on > supporting the ipw3945 wireless card on Debian. In non-free I can find > the firmware package, but I couldn't find the non-free regulatory > daemon nor the free kernel driver. I would like to work on that, but I > don't want to duplicate work. > > The only thing I could find was http://www.wooyd.org/debian/ipw3945-daemon/ Yes, this is my site and ipw3945-daemon is the work in progress.. We had some discussions about its design issues recently [0], which are pretty much settled now, so I hope to finish and upload the package sometime later this week. [0] Thread starting with http://lists.debian.org/debian-kernel/2006/10/msg00374.html Best regards, -- Jurij Smakov [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
