Re: Induction of new members to the technical committee
* Martin Zobel-Helas: actually, i would like to know how this persons have been appointed/selected? Will this work like any other vote, so anyone can be recommented? Or does the CTTE need to assign this person by it's own? No, the DPL and the Technical Committee handle this by themselves. See the Constitution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
On Wed, Dec 21, 2005 at 09:14:16PM +0100, Jeroen van Wolffelaar wrote: ] Looking at popcon, vim has ] about twice the amount of users as nvi The problem with this is that popcon tends to be self-selecting for fan-boys. People setting up serious servers with Debian are not going to be installing extraneous software like popcon, and casual users are unlikely to find it interesting enough to install even if they happen to notice its existance. IMO, popcon should be treated as one would treat any other online poll. The data may be considered interesting or suggestive, but should never be considered reliable or meaningul. The self-selected sample problem is exactly the same as in most online polls, and even the possibility of ballot-stuffing cannot be ruled out. Of course, since you're using popcon data as a starting place for an online poll, that's actually quite reasonable (unlike many of the other uses that have been suggested for popcon data), but I think it's still important to remember that your starting data here is not reliable. As for your poll itself: I find nvi to be a perfectly adequate implementation of vi, and have never felt the urge to install a more sophisticated vi. I know nothing about vim-tiny, though, so I'm not really qualified to vote. My tendency would be to vote for whichever is the smallest, as long as both are actually full implementations of the vi spec. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stable security support
On Thu, Dec 22, 2005 at 08:54:36AM +0100, Adrian von Bidder wrote: Problem with a GR: it doesn't get any work done. Right; that's not the intention of the GR though -- the intention is to authorise people to do the work. I've done all I feel I'm within my rights to (and in fact slightly more than that) in providing access to security.d.o to some of the testing-security team. While I could try doing more than that, and possibly succeed thanks to my tyranny over Unix permissions, I don't particularly want to provide any substance to accusations of coups and whatever else. There are problems with the other people who could potentially overrule the security team's preferences; the DPL is only to withdraw delegations, not actually help with working out how delegates should act; and the tech ctte usually avoids questions that aren't of the form how sould this piece of sotfware work? There's also the question of whether the security team are delegates -- and while there's more to that than there seems at first glance, it seems like it'd be good to skip over worrying about it. I don't know if it carries more or less weight having me say it, but I think it's entirely appropriate to cut Branden a lot of slack in not trying to come in as DPL and fix this. Scenario I: * some people see something needs doing * 200+ thread on d-d * some (other) people are ready to do the work * the work is done. Scenario II: like the above, but there is a delay of several weeks while a GR confirms that the work needs doing. I doubt there's going to be much happening between now and New Year; so holding a GR over that time wouldn't provide much of a delay. Cheers, aj signature.asc Description: Digital signature
Re: Stable security support
On Thursday 22 December 2005 09.59, Anthony Towns wrote: On Thu, Dec 22, 2005 at 08:54:36AM +0100, Adrian von Bidder wrote: Problem with a GR: it doesn't get any work done. Right; that's not the intention of the GR though -- the intention is to authorise people to do the work. I've done all I feel I'm within my rights to (and in fact slightly more than that) in providing access to security.d.o to some of the testing-security team. While I could try doing more than that, and possibly succeed thanks to my tyranny over Unix permissions, I don't particularly want to provide any substance to accusations of coups and whatever else. Ah. To me, that is quite a bit of the missing piece of information on why you feel this GR is needed. To me the GR sounds very much wishy-washy, kind of 'let's appoint some people who might then do some work.' With what you say here, I can see the motivation for this GR. Also, it becomes clearer as it's apparently not clear whether the security team are delegates - I assumed they were (and feel they should be). Maybe - is it time to clear this issue now? http://people.debian.org/~branden/dpl/reports/2005-07-07.html branden: | I have sent the Debian Security Team a proposal for making DPL delegates | out of its members; Whatever became of that? (Hmmm. What *is* the curernt status? http://lists.debian.org/debian-security/2005/08/msg00226.html only muddies the water for me.) Word from the DPL or SecTeam members would be welcome here - do they operate under the assumption that the security team are delegates? I don't know if it carries more or less weight having me say it, but I think it's entirely appropriate to cut Branden a lot of slack in not trying to come in as DPL and fix this. Well, I'm extremely ambivalent on this matter. I often have the feeling that a more vocal DPL could in some instances give the project a clearer idea where to go - or, maybe, if the DPL wants to go where others don't want, issues would be debated earlier. OTOH a vocal/active leadership-type DPL might meet opposition in the project on unprecedented scale, so maybe the Way It's Always Been Done(tm) isn't so bad... Back to the topic at hand: Can't Joeyh, Steve and Micah just be added to the security team[1] along with Martin (same disclaimer as in your mail: assuming they want to) and assume that the security team will work out amongst themselves who would continue to care about current stable security and who would do the 'redesign the process' part? Assuming that 'member of the security team' does not automatically mean 'does need vendor-sec clearance and all kinds of assorted special Debian powers that can't be given to some of these people'. Why just add them to the secteam instead of appointing them to a special redesign-the-process team? Because I feel that if ever the result of that work should be useful, it needs to be done in close cooperation with the current security team anway. [1] by GR? By delegation? By invitation from the current secteam? IMHO preferable (ii) or maybe (iii), GR doesn't feel right: if we're going to vote on people, we should have proper debates à la DPL vote, but this is creating a kind of procedure that seems, to me, much too heavyweight for this kind of job. -- vbi -- 1933 wollten viele aus Deutschland raus, heute wollen viele rein. Das muss doch etwas bedeuten. -- Sir Peter Ustinov pgpItyQnKTqtC.pgp Description: PGP signature
Re: Stable security support
On Thu, Dec 22, 2005 at 11:23:32AM +0100, Adrian von Bidder wrote: Ah. To me, that is quite a bit of the missing piece of information on why you feel this GR is needed. To me the GR sounds very much wishy-washy, kind of 'let's appoint some people who might then do some work.' With what you say here, I can see the motivation for this GR. Also, it becomes clearer as it's apparently not clear whether the security team are delegates - I assumed they were (and feel they should be). Maybe - is it time to clear this issue now? Well, this would not be skipping over worrying about the delegation question, as Anthony suggests. The only point I see in establishing that existing security team members are delegates is if you plan for the DPL to rescind their delegate status (or threaten to, I guess). That doesn't strike me as a very good method of helping Debian do better at security updates. Back to the topic at hand: Can't Joeyh, Steve and Micah just be added to the security team[1] Er... there's quite a difference in scope between talk to the security team about existing processes and try to help identify possible improvements and sit on the security team. I sure haven't agreed to the second, and I don't think a GR (or unilateral delegation) is a particularly good way to choose members for a *team*, either. And for your third option of having the security team invite new members in, that doesn't exactly help us identify a course of action if the security team *doesn't* do this? -- 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/ signature.asc Description: Digital signature
Re: Experiment: poll on switching to vim-tiny for standard vi?
[Chris Waters] The problem with this is that popcon tends to be self-selecting for fan-boys. People setting up serious servers with Debian are not going to be installing extraneous software like popcon, and casual users are unlikely to find it interesting enough to install even if they happen to notice its existance. I suspect you have not tested the etch installation lately. The popularity-contest question is asked as part of the standard installation path, so it is no-longer just for the few that know about it. I do not know how you define serious servers, but I know of quite a few servers with popularity-contest installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stable security support
On Thursday 22 December 2005 12.08, Steve Langasek wrote: On Thu, Dec 22, 2005 at 11:23:32AM +0100, Adrian von Bidder wrote: Ah. To me, that is quite a bit of the missing piece of information on why you feel this GR is needed. To me the GR sounds very much wishy-washy, kind of 'let's appoint some people who might then do some work.' With what you say here, I can see the motivation for this GR. Also, it becomes clearer as it's apparently not clear whether the security team are delegates - I assumed they were (and feel they should be). Maybe - is it time to clear this issue now? Well, this would not be skipping over worrying about the delegation question, as Anthony suggests. Correct. The only point I see in establishing that existing security team members are delegates is if you plan for the DPL to rescind their delegate status (or threaten to, I guess). Or to propose that the DPL just delegates the people to the tasks aj proposed. For me, this requires clearing the status of the current secteam members, because I don't think having 'delegated secteam members' alongside 'pre-delecation secteam members with unclear status' is a good idea. Back to the topic at hand: Can't Joeyh, Steve and Micah just be added to the security team[1] Er... there's quite a difference in scope between talk to the security team about existing processes and try to help identify possible improvements and sit on the security team. I sure haven't agreed to the second, Point taken. and I don't think a GR (or unilateral delegation) is a particularly good way to choose members for a *team*, either. Nobody talked about unilateral. See the disclaimer both aj and I mentioned? Actually one of the reason I don't feel a GR should be used here is that I feel that would exactly be an unilateral action, potentially antagonizing the current security team. At least until that the current secteam indicates that this GR is welcome to them. cheers -- vbi -- Beware of the FUD - know your enemies. This week * The Alexis de Toqueville Institue * http://fortytwo.ch/opinion/adti pgpCLf4SwsNMB.pgp Description: PGP signature
Re: Stable security support
On Thu, Dec 22, 2005 at 11:23:32AM +0100, Adrian von Bidder wrote: Word from the DPL or SecTeam members would be welcome here - do they operate under the assumption that the security team are delegates? I never have, personally. My reasoning is soley based upon the idea that the team itself invites new members. Steve -- signature.asc Description: Digital signature
error in a link for Downlading netinstal CD
Hi, I found a error at: http://www.us.debian.org/releases/sarge/debian-installer/ If I like to Download the 3.1r1, I got the following link to Download: http://cdimage.debian.org/debian-cd/3.1_r0a/i386/iso-cd/debian-31r0a-i386-netinst.iso Well, I changed this from 3.1._r0a to 3.1_r1 and it works ;-) just you know the error in the link... see you, Greetings from Switzerland Alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Induction of new members to the technical committee
On Thursday, December 22, 2005 7:22 AM, Martin Zobel-Helas [EMAIL PROTECTED] wrote: Hi Manoj, On Tuesday, 20 Dec 2005, you wrote: [...] So I hereby propose that this committee recommend to the the Debian project leader the following individuals to be candidates for induction into the technical committee (as per section 6.2.2 of the constitution) [...] actually, i would like to know how this persons have been appointed/selected? Will this work like any other vote, so anyone can be recommented? Or does the CTTE need to assign this person by it's own? As noted in Manoj's message, section 6 of the constituion covers the Technical Committee. Section 6.2 specifies that appointments are made by the Committee and/or DPL subject to the conditions of that section. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stable security support
On Thu, Dec 22, 2005 at 11:23:32AM +0100, Adrian von Bidder wrote: Word from the DPL or SecTeam members would be welcome here - do they operate under the assumption that the security team are delegates? For those who think it's worth delving into this topic, there's a message on -private from September 1999 that gives the alternative viewpoint; look for Resent-Message-ID: [EMAIL PROTECTED]. I'd really much rather just avoid the question. Back to the topic at hand: Can't Joeyh, Steve and Micah just be added to the security team[1] Note that while I may've guessed wrong, I picked those three specifically as people who *wouldn't* want to be on the security team proper. :) (The idea behind that is, I guess, to ensure they don't fall victim to the conflict between spending time figuring out how to do the work, and spending time actually doing the work) Cheers, aj signature.asc Description: Digital signature
Re: Your posting: Debian on one dvd?
On Tue, 20 Dec 2005, Daniel Tasch wrote: This is not just a problem in contries like India. I am in the US and am still on dialup, and can only get 26k at that. I have to update my redhat by mirroring the updates at work where I have a good connection, burning a CD, and brining it home via sneakernet. I would love to be able to use Debian, but dealing with a new packaging system along with it's extreem network-centeredness is making that impossible. What Debian really needs is to give some consideration to people who have to do this manually. Not everybody has a high-speed internet connection. Please be more inclusive. Hopefully some of the responses you've gotten have given you some ideas for how to deal with this situation. Perhaps when we get the DVD produced we can team up with some American distributor too. And fwiw, back in the days of yore when dinosaurs roamed o'er the land and this new-fangled apt thingy first came out, I used to stay uptodate with Debian unstable via a 28.8K modem. I used to start my download before going to bed and it would just be finishing up when I woke up. Mind you, Debian was a lot smaller then. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
Petter Reinholdtsen [EMAIL PROTECTED] writes: I suspect you have not tested the etch installation lately. The popularity-contest question is asked as part of the standard installation path, so it is no-longer just for the few that know about it. I do not know how you define serious servers, but I know of quite a few servers with popularity-contest installed. I'd dearly like to install popularity-contest on our dozens of Debian servers (among other things, it would surface usage of a few packages that right now look rather anemic), but I don't think there's any chance I'd get it past our computer security folks. Yes, the data that it sends isn't particularly sensitive, but it's still information about what packages are installed on a system that could be used to structure an attack and from their perspective there's no upside. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
On Wed, Dec 21, 2005 at 05:41:45PM -0600, Steve Greenland wrote: vim-tiny depends on the 200k-ish vim-common too, so nvi seems about half the total size of a vim-tiny today. Okay, so that's not about the same. Stefano? If the above numbers are If this is some kind of insinuation, ... well, I'm kind of pissed-off by it. I never used the expression about the same. Joey forwarded a post of mine containing the verbatim words: The installed-size of it and of vim-common are as I anticipated (776 + 232 on i386); [ vim-common is now some Kb smaller, but this is not relevant here ] In the very same post Joey correctly added: It's now only marginally larger than nvi Thus, no one of the proposer speaked of something about the same. correct, then the best case is a (696+200-560)==336K increase. Last I heard, the CD builders considered that a non-trivial amount of space. Or am I confusing the boot image with base? I asked Joey, as one of the installer maintainer, and for him the size increase is not a problem. If it is a problem for the CD builders, they can speak in this thread. If it is not a problem for these people, why is it a problem for you? -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: error in a link for Downlading netinstal CD
On Thursday 22 December 2005 14:34, Alvin T. P. Brodbeck wrote: http://www.us.debian.org/releases/sarge/debian-installer/ If I like to Download the 3.1r1, I got the following link to Download: http://cdimage.debian.org/debian-cd/3.1_r0a/i386/iso-cd/debian-31r0a-i3 86-netinst.iso Links have now been updated (rebuild of the website may take a while). Thanks for reporting this. Cheers, FJP pgpXXGuPQPaFo.pgp Description: PGP signature
Re: Experiment: poll on switching to vim-tiny for standard vi?
Stefano Zacchiroli [EMAIL PROTECTED] [...] In the very same post Joey correctly added: It's now only marginally larger than nvi [...] 167% is a rather big margin, isn't it? I asked Joey, as one of the installer maintainer, and for him the size increase is not a problem. If it is a problem for the CD builders, they can speak in this thread. If it is not a problem for these people, why is it a problem for you? If one is honest and says that vim-tiny will replace nvi because the decision-makers prefer it, then that's fine, but this doesn't look like a technically-based decision. It doesn't seem supported by current data to claim that vim-tiny isn't a real size increase, or that this doesn't mean most vi users (both vim-fans and vim-haters) will want to install another vi besides the default one. Are there many vi users who will just use vim-tiny? Most small vi users don't seem to like vim, IME. -- MJ Ray - personal email, see http://mjr.towers.org.uk/email.html Work: http://www.ttllp.co.uk/ irc.oftc.net/slef Jabber/SIP ask -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
Petter Reinholdtsen dijo [Thu, Dec 22, 2005 at 12:19:58PM +0100]: [Chris Waters] The problem with this is that popcon tends to be self-selecting for fan-boys. People setting up serious servers with Debian are not going to be installing extraneous software like popcon, and casual users are unlikely to find it interesting enough to install even if they happen to notice its existance. I suspect you have not tested the etch installation lately. The popularity-contest question is asked as part of the standard installation path, so it is no-longer just for the few that know about it. I do not know how you define serious servers, but I know of quite a few servers with popularity-contest installed. Well, it was also the default behavior for some time with the pre-Sarge installer - I don't know why it was dropped (in the back of my head I hear a little voice telling it was buggy or something, but I've been taught not to listen to those little voices). I'd like to be part of the standard install (of course, after answering a question, as many people will not want to be silently reporting their data). Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
On Thursday 22 December 2005 22:53, Gunnar Wolf wrote: The problem with this is that popcon tends to be self-selecting for fan-boys. I don't know why it was dropped (in the back of my head I hear a little voice telling it was buggy or something No, the reason was a rewrite of tasksel to use aptitude which made it harder to implement default installation of popcon. Nothing to do with popcon itself. Cheers, FJP pgpfgZAgAIdp6.pgp Description: PGP signature
Re: Experiment: poll on switching to vim-tiny for standard vi?
On Thu, Dec 22, 2005 at 11:11:59PM +, MJ Ray wrote: Stefano Zacchiroli [EMAIL PROTECTED] [...] In the very same post Joey correctly added: It's now only marginally larger than nvi [...] 167% is a rather big margin, isn't it? Depends what it's a percentage of; if it were a percentage of all of base, sure; but it's not, it's a percentage of nvi. If one is honest and says that vim-tiny will replace nvi because the decision-makers prefer it, One doesn't need to be honest to say that, merely tautological: yes, decisions happen when decision makers decide. Are there many vi users who will just use vim-tiny? Most small vi users don't seem to like vim, IME. I prefer nvi because of the default vim configuration issues discussed earlier; autoindenting while pasting in particular is annoying. With that fixed, I'd be happy to have vim be the default vi on my system, and would tend to do that, since some of my users strenuously prefer having vim around. Cheers, aj signature.asc Description: Digital signature
