Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[paddy]

On Fri, Jan 06, 2006 at 09:21:45AM -0600, Steve Greenland wrote:
> On 06-Jan-06, 08:28 (CST), paddy <[EMAIL PROTECTED]> wrote: 
> > On Fri, Jan 06, 2006 at 07:43:07AM -0600, Steve Greenland wrote:
> > > Then the whole update-alternatives priority system is made pointless.
> > 
> > s/pointless/better/
> 
> How? If you provide the ability to determine alternative selection based
> on package priority (Important/Standard/Optional/Extra), why do you need
> alternative priorities (numerical, set in in package maintainer scripts,
> locally overridable)?

currently, IIUC, there is auto and manual, where auto is

numerical, set in in package maintainer scripts

and manual is

locally overridable

My suggestion is that auto is the policy, of which there is currently one.
In a system with multiple possible policies, you would still need a 
configured policy, but some example resultant possible combinations are:

based on package priority, locally overridable

numerical, set in in package maintainer scripts, locally overridable

in alphabetical order, locally overridable

ie: auto, manual == configured policy, manual.

Obviously, not all possible policies would be useful, but then noone would
write them.

> (The fact that we are using the word "priority" to mean two different
> things is perhaps confusing, which is why I've been trying to
> distinguish "package priority" and "alternative priority".)

Agreed, I am trying to disambiguate these priorities as I write, although, 
without the same understanding of the existing system, I fear I may be 
creating some confusion, for which I apologise.

> > > Part of our job as maintainers and distributors is to make choices, so
> > > that *most* of our users don't have to. Then we generally provide a
> > > way to override those choices, for the remainder, who disagree with a
> > > particular choice or have a particular situation that is not covered by
> > > our choice.
> > 
> > and this would be just such an override, surely ?
> 
> We *already* have an override: it's called 'update-alternative'. Why do
> we need two?

the idea would be to make update-alternative extensible.

> > > Remember that people in class C are probably in class C *only* for one
> > > particular alternative, and are perfectly happy with the all the others.
> > 
> > okay so this is "noone ever wants to do that"
> 
> Sigh. No, it's "most of the time, for most people, our current system
> defaults in an appropriate manner, and for those rare occasions when it
> doesn't, we have the tool to override." 

"If it ain't broke ?"

> > I'm sorry to keep asking so many dumb questions, but would such a facility
> > make things any harder for maintainers ? (I have no trouble imagining that
> > it might, but I'm not familiar with the details)
> 
> It makes it harder for maintainers, 

see below

> and it makes it harder for users,

debatable.  more options is more complexity, sure.  But many of the prior
arguments appealled to an admin who had control and knew what was going on.
Some of those arguments supposed an admin who wouldn't be well served by
the current (default and only) policy.

no need to change the default, just add a hook.

> because there would then be two completely different ways of overriding
> default alternative priorities. 

I agree that this looks like a significant potential hazard, but ...

> Which would be dominant? 

The existing system for making manual adjustments would be most dominant.

At the policy level, a given distro/release would need to have a default.

Since people would inevitably use different defaults in different distros
and releases and some admins would use non-default policies, interested 
parties on a given system would need to inspect the configuration.

Having some portability in a way to do that might be nice. 

> Which is preferred? 

I don't understand. 

"What's the default policy ?"

I see no reason for Debian to change it's existing default.

> How do you test all the interactions?

There may be an issue here, but I don't see it.

If the existing system is just one possible policy (albeit the default), 
and any other policy relies on the same manual override but otherwise
any bugs are its own. Where are the interactions ?

> > As I've tried very hard to indicate, I'm not clear on what the implications
> > would be, but I was kinda hoping that it might be a no-brainer, rather
> > than a design decision.  I'm still no clearer on that :(
> 
> We have a straightforward system that provides a) reasonable default
> behaviour, and b) a standard way to override the default. I don't see
> the point in complicating that to provide a solution to a "problem"
> that has been invented just for this thread, and has *no* outstanding
> wishlist bug reports.

It's a random and probably flawed suggestion about how to accomodate both
viewpoints in a disagreement by a technical device. It's nowhere near my 
todo list.  I only hope I'm not wasting

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Steve Greenland]

On 06-Jan-06, 08:28 (CST), paddy <[EMAIL PROTECTED]> wrote: 
> On Fri, Jan 06, 2006 at 07:43:07AM -0600, Steve Greenland wrote:
> > Then the whole update-alternatives priority system is made pointless.
> 
> s/pointless/better/

How? If you provide the ability to determine alternative selection based
on package priority (Important/Standard/Optional/Extra), why do you need
alternative priorities (numerical, set in in package maintainer scripts,
locally overridable)?

(The fact that we are using the word "priority" to mean two different
things is perhaps confusing, which is why I've been trying to
distinguish "package priority" and "alternative priority".)

> > Part of our job as maintainers and distributors is to make choices, so
> > that *most* of our users don't have to. Then we generally provide a
> > way to override those choices, for the remainder, who disagree with a
> > particular choice or have a particular situation that is not covered by
> > our choice.
> 
> and this would be just such an override, surely ?

We *already* have an override: it's called 'update-alternative'. Why do
we need two?

> > Remember that people in class C are probably in class C *only* for one
> > particular alternative, and are perfectly happy with the all the others.
> 
> okay so this is "noone ever wants to do that"

Sigh. No, it's "most of the time, for most people, our current system
defaults in an appropriate manner, and for those rare occasions when it
doesn't, we have the tool to override." 

> I'm sorry to keep asking so many dumb questions, but would such a facility
> make things any harder for maintainers ? (I have no trouble imagining that
> it might, but I'm not familiar with the details)

It makes it harder for maintainers, and it makes it harder for users,
because there would then be two completely different ways of overriding
default alternative priorities. Which would be dominant? Which is
preferred? How do you test all the interactions?

> As I've tried very hard to indicate, I'm not clear on what the implications
> would be, but I was kinda hoping that it might be a no-brainer, rather
> than a design decision.  I'm still no clearer on that :(

We have a straightforward system that provides a) reasonable default
behaviour, and b) a standard way to override the default. I don't see
the point in complicating that to provide a solution to a "problem"
that has been invented just for this thread, and has *no* outstanding
wishlist bug reports.

Steve
-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
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?"

[paddy]

On Fri, Jan 06, 2006 at 07:43:07AM -0600, Steve Greenland wrote:
> On 05-Jan-06, 14:20 (CST), paddy <[EMAIL PROTECTED]> wrote: 
> > 
> > Maybe I have the wrong end of the stick.
> > 
> > I was thinking that if you wanted another possible behaviour:
> > say that optional packages don't overide important ones unless explicitly
> > set that way, then you could set that policy globally.
> 
> Then the whole update-alternatives priority system is made pointless.

s/pointless/better/

;)

> Part of our job as maintainers and distributors is to make choices, so
> that *most* of our users don't have to. Then we generally provide a
> way to override those choices, for the remainder, who disagree with a
> particular choice or have a particular situation that is not covered by
> our choice.

and this would be just such an override, surely ?

> The choice we made many years ago for alternative priorities was based
> on these presumptions:
> 
> A. Most people wouldn't care which of the alternative packages was
> installed so long as it provided the basic funtionality. 
> 
> B. Of those who cared to install on of the variants, most would want to
> use the variant by default; after all, that's why they installed the
> variant.
> 
> C. The 1% not covered by A and B can use update-alternatives to set
> their preferred version.

Understood, but it doesn't seem to answer my questions.

> Remember that people in class C are probably in class C *only* for one
> particular alternative, and are perfectly happy with the all the others.

okay so this is "noone ever wants to do that"

what about the delegated package installation example ?
Is that similarly flawed ?

I'm sorry to keep asking so many dumb questions, but would such a facility
make things any harder for maintainers ? (I have no trouble imagining that
it might, but I'm not familiar with the details)

> This is really a corner case, and while one should provide for corner
> cases, one probably shouldn't design around corner cases.

As I've tried very hard to indicate, I'm not clear on what the implications
would be, but I was kinda hoping that it might be a no-brainer, rather
than a design decision.  I'm still no clearer on that :(

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall


-- 
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?"

[Steve Greenland]

On 05-Jan-06, 14:20 (CST), paddy <[EMAIL PROTECTED]> wrote: 
> 
> Maybe I have the wrong end of the stick.
> 
> I was thinking that if you wanted another possible behaviour:
> say that optional packages don't overide important ones unless explicitly
> set that way, then you could set that policy globally.

Then the whole update-alternatives priority system is made pointless.

Part of our job as maintainers and distributors is to make choices, so
that *most* of our users don't have to. Then we generally provide a
way to override those choices, for the remainder, who disagree with a
particular choice or have a particular situation that is not covered by
our choice.

The choice we made many years ago for alternative priorities was based
on these presumptions:

A. Most people wouldn't care which of the alternative packages was
installed so long as it provided the basic funtionality. 

B. Of those who cared to install on of the variants, most would want to
use the variant by default; after all, that's why they installed the
variant.

C. The 1% not covered by A and B can use update-alternatives to set
their preferred version.

Remember that people in class C are probably in class C *only* for one
particular alternative, and are perfectly happy with the all the others.

This is really a corner case, and while one should provide for corner
cases, one probably shouldn't design around corner cases.

Steve
-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
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?"

[paddy]

On Wed, Jan 04, 2006 at 07:29:10AM -0600, Steve Greenland wrote:
> On 04-Jan-06, 05:08 (CST), paddy <[EMAIL PROTECTED]> wrote: 
> > Time to add a policy-alternatives hook to update-alternatives ??
> 
> Huh? If the admin manually sets an alternative with with
> update-alternatives, it won't be overridden by a package install. What
> more does she need?

Maybe I have the wrong end of the stick.

I was thinking that if you wanted another possible behaviour:
say that optional packages don't overide important ones unless explicitly
set that way, then you could set that policy globally.

That way the policy could cover packages that haven't even been written yet.

Arguably an admin could fix things manually, but it isn't the same thing.

Or perhaps it's just something that noone would ever want ?

I don't have enough knowledge of the cases where alternatives is used,
to know whether anything would break, but given the nature of the mechanism 
it seems plausible that it might just work.

Suppose I want to delegate the ability to install packages (lets say
from some limited secure source), but not have that activity mess
with the alternatives, or delegate control of alternatives.

Would that even work ?

Does it help make a policy-alternatives make sense ?

Even if the delegation example is nonsense is it hard to imagine that an
admin might simply have a multi-user system where this behaviour would
be the desirable rule rather than the exception ?

I appreciate the whole nice-for-the-single-user-by-default approach,
but it's nice to have the option to tell the packaging system to stay out of
the way as far as possible.

install x == replace y with less functional x

is not KISS, surely ?

I think you only have to look at this thread to get a hint that people
care about which text editor they use ;)

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall


-- 
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?"

[Thomas Bushnell BSG]

Joey Hess <[EMAIL PROTECTED]> writes:

> Oh, come on. vim-tiny entered the archive this week. The fact that we
> have some slow buildds and ports like hurd-i386 that are perennially
> behind is irrelevant to this discussion unless you can point to a build
> failure log.

Maybe we shouldn't switch the standard vi to a package which has only
been in the archive for one week?


-- 
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?"

[Steve Greenland]

On 03-Jan-06, 19:30 (CST), Steve Langasek <[EMAIL PROTECTED]> wrote: 
> On Tue, Jan 03, 2006 at 08:58:49AM -0600, Steve Greenland wrote:
> > Such behaviour is pretty much standard alternative handling: the default
> > install is the lowest priority, and the optional variants have higher
> > priorities.
> 
> > For a single user system, this makes sense. For a multi-user system,
> > where the admin might want all of (vim, nvi, vile, whatever) as options
> > for the user, it's easy to pick whichever one you want for the default.
> 
> OTOH, the admin may not understand the alternatives system, or recognize its
> relevance at the time of installing the package (worst case, some other
> package pulls it in automatically), which makes for an inconsistent user
> experience.
> 
> I think the single-user system is the last one that alternatives handling
> should optimize for, since the *one* person who's going to know to type
> "nvi" instead of "vi", and the one person who can fix the alternatives if he
> doesn't like them, is the admin...

Then you need to bring this up on -policy, because what I described
(that the default package providing an alternative is the lowest
ranked one, and the optional ones override it) is what people have
been doing for years. See, for example, mawk and gawk. Or even vi: by
your argument, nvi should currently be the highest ranked of the vi
alternatives, not the lowest.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
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?"

[Steve Greenland]

On 04-Jan-06, 05:08 (CST), paddy <[EMAIL PROTECTED]> wrote: 
> Time to add a policy-alternatives hook to update-alternatives ??

Huh? If the admin manually sets an alternative with with
update-alternatives, it won't be overridden by a package install. What
more does she need?

Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
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?"

[paddy]

On Wed, Jan 04, 2006 at 03:15:01AM +0100, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > I think the single-user system is the last one that alternatives handling
> > should optimize for, since the *one* person who's going to know to type
> > "nvi" instead of "vi", and the one person who can fix the alternatives if he
> > doesn't like them, is the admin...
> 
> which also means he most likely wants to have the manually installed packet
> to grab the alternative link.

Time to add a policy-alternatives hook to update-alternatives ??

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall


-- 
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?"

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I think the single-user system is the last one that alternatives handling
> should optimize for, since the *one* person who's going to know to type
> "nvi" instead of "vi", and the one person who can fix the alternatives if he
> doesn't like them, is the admin...

which also means he most likely wants to have the manually installed packet
to grab the alternative link.

Gruss
Bernd


-- 
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?"

[Steve Langasek]

On Tue, Jan 03, 2006 at 08:58:49AM -0600, Steve Greenland wrote:
> On 03-Jan-06, 00:46 (CST), Steve Langasek <[EMAIL PROTECTED]> wrote: 
> > On Mon, Jan 02, 2006 at 11:47:05AM -0600, Steve Greenland wrote:
> > > If you agree with the change, do Stefano and I need to do anything
> > > other than swap vi alternative priorities and swap important<->optional
> > > priorities?

> > Why swap the vi alternative priorities?

> Because if vim is the default, and someone deliberately installs nvi,
> the presumption is that they prefer nvi, and thus it should grab the vi
> link.

I think that's a pretty bad presumption; to me, it indicates that *someone*
on the system prefers nvi and has requested its installation, but this
doesn't mean it's the preference of either the system administrator or of
the majority of the users.

> Such behaviour is pretty much standard alternative handling: the default
> install is the lowest priority, and the optional variants have higher
> priorities.

> For a single user system, this makes sense. For a multi-user system,
> where the admin might want all of (vim, nvi, vile, whatever) as options
> for the user, it's easy to pick whichever one you want for the default.

OTOH, the admin may not understand the alternatives system, or recognize its
relevance at the time of installing the package (worst case, some other
package pulls it in automatically), which makes for an inconsistent user
experience.

I think the single-user system is the last one that alternatives handling
should optimize for, since the *one* person who's going to know to type
"nvi" instead of "vi", and the one person who can fix the alternatives if he
doesn't like them, is the admin...

-- 
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?"

[Steve Greenland]

On 03-Jan-06, 00:46 (CST), Steve Langasek <[EMAIL PROTECTED]> wrote: 
> On Mon, Jan 02, 2006 at 11:47:05AM -0600, Steve Greenland wrote:
> > If you agree with the change, do Stefano and I need to do anything
> > other than swap vi alternative priorities and swap important<->optional
> > priorities?
> 
> Why swap the vi alternative priorities?

Because if vim is the default, and someone deliberately installs nvi,
the presumption is that they prefer nvi, and thus it should grab the vi
link.

Such behaviour is pretty much standard alternative handling: the default
install is the lowest priority, and the optional variants have higher
priorities.

For a single user system, this makes sense. For a multi-user system,
where the admin might want all of (vim, nvi, vile, whatever) as options
for the user, it's easy to pick whichever one you want for the default.

SteveG

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
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?"

[Anthony Towns]

On Tue, Jan 03, 2006 at 01:59:46AM +0100, Adeodato Simó wrote:
> * Anthony Towns [Tue, 03 Jan 2006 07:55:06 +1000]:
> > I still think the vi provided by vim-tiny needs to default to compatible
> > mode and no-auto-indenting; but afaik it still doesn't.
> > > If you agree with the change, do Stefano and I need to do anything
> > > other than swap vi alternative priorities and swap important<->optional
> > > priorities?
> > No, I don't think so.
>   Bug report against ftp.d.o asking for the priority change in the
>   override file?

Just poking me should be fine; changing the override files is how base is
maintained.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Steve Langasek]

On Mon, Jan 02, 2006 at 11:47:05AM -0600, Steve Greenland wrote:
> On 23-Dec-05, 11:54 (CST), Anthony Towns  wrote: 

> > The size of base matters a little, but it's not an "every byte is
> > sacred" situation.

> > Cheers, aj (base maintainer, for those playing along at home)

> So, it seems that so far as Stefano (vim maintainer) and I (nvi
> maintainer) are concerned, you and Joey get to make the call on this. Since
> Joey initiated this thread, I think we can assume he's in favor of
> the change. How say you?

> If you agree with the change, do Stefano and I need to do anything
> other than swap vi alternative priorities and swap important<->optional
> priorities?

Why swap the vi alternative priorities?

-- 
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?"

[Adeodato Simó]

* Anthony Towns [Tue, 03 Jan 2006 07:55:06 +1000]:

> I still think the vi provided by vim-tiny needs to default to compatible
> mode and no-auto-indenting; but afaik it still doesn't.

> > If you agree with the change, do Stefano and I need to do anything
> > other than swap vi alternative priorities and swap important<->optional
> > priorities?

> No, I don't think so.

  Bug report against ftp.d.o asking for the priority change in the
  override file?

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Listening to: Joaquín Sabina - Dos horas después


-- 
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?"

[Anthony Towns]

On Mon, Jan 02, 2006 at 11:47:05AM -0600, Steve Greenland wrote:
> On 23-Dec-05, 11:54 (CST), Anthony Towns  wrote: 
> > The size of base matters a little, but it's not an "every byte is
> > sacred" situation.
> > Cheers, aj (base maintainer, for those playing along at home)
> So, it seems that so far as Stefano (vim maintainer) and I (nvi
> maintainer) are concerned, you and Joey get to make the call on this. Since
> Joey initiated this thread, I think we can assume he's in favor of
> the change. How say you?

I still think the vi provided by vim-tiny needs to default to compatible
mode and no-auto-indenting; but afaik it still doesn't.

> If you agree with the change, do Stefano and I need to do anything
> other than swap vi alternative priorities and swap important<->optional
> priorities?

No, I don't think so.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Stefano Zacchiroli]

On Mon, Jan 02, 2006 at 11:47:05AM -0600, Steve Greenland wrote:
> If you agree with the change, do Stefano and I need to do anything
> other than swap vi alternative priorities and swap important<->optional
> priorities?

On my TODO list I also have to split the vim configuration files in
/etc/vim/vimrc and /etc/vim/virc to be read depending on how vim has
been invoked. The former configuration should be more compatible with
the usualy vi behaviour than the current vim's default.

-- 
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: Experiment: poll on "switching to vim-tiny for standard vi?"

[Steve Greenland]

On 23-Dec-05, 11:54 (CST), Anthony Towns  wrote: 

> The size of base matters a little, but it's not an "every byte is
> sacred" situation.
>
> Cheers, aj (base maintainer, for those playing along at home)

Anthony: 

So, it seems that so far as Stefano (vim maintainer) and I (nvi
maintainer) are concerned, you and Joey get to make the call on this. Since
Joey initiated this thread, I think we can assume he's in favor of
the change. How say you?

If you agree with the change, do Stefano and I need to do anything
other than swap vi alternative priorities and swap important<->optional
priorities?


Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
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?"

[Stefano Zacchiroli]

Sorry for the delay in the reply, house moving ...

On Tue, Dec 27, 2005 at 03:24:34PM -0600, Steve Greenland wrote:
> Sorry, no insinuation intended, although I see, in retrospect, how it
> can be read that way; my apologies. I just used "Stefano?" to draw your
> attention and ask for your comments.

No problem then and no offence taken.

> To *me* "marginally larger" and "about the same" are pretty much
> equivalent; neither applies to a 50% increase in size.

As others already observed, the percentage is not meaningful per se. The
increase in the total amount of kbytes is "marginally larger".

> Since the whole designation of "base" is basically only useful for
> install/cd people, I'd let them make the decision.

Fair enough.

-- 
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: Experiment: poll on "switching to vim-tiny for standard vi?"

[Steve Greenland]

Sorry for the lateness of this; Newtonmas and all... 

On 22-Dec-05, 12:33 (CST), Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: 
> 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.  

Sorry, no insinuation intended, although I see, in retrospect, how it
can be read that way; my apologies. I just used "Stefano?" to draw your
attention and ask for your comments. For all I knew, the versions being
compared were not the most current available to you.

To *me* "marginally larger" and "about the same" are pretty much
equivalent; neither applies to a 50% increase in size.

> 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?

It's not, *THAT'S WHY I ASKED!* You have to understand: I don't pay
a whole lot of attention to the who's who of Debian infrastructure
maintainers; "Joey says it's okay" simply doesn't mean as much to me
as "Joey, one of the major installer maintainers, says it's okay"
(Sorry, Joey, but there it is :-)). I am faintly aware that space
on the installer/rescue CD was precious; since vim-tiny *is* still
significantly bigger than nvi (percentage wise, at least), I wanted to
make sure that the appropriate people have been asked. Joey and you have
now said "Yes, it's fine." Terrific.

I don't care which one is in base, so long as I have a working,
non-colorized vi clone after a base install. Once I'm setup, I can
install nvi if I want. 

>From this thread, I don't see any much of an argument one way or another.
Some people would rather have vim, some would rather have nvi. So long
as I can get the one I want, and remove the one I don't, it just doesn't
seem to be a big deal.  Since the whole designation of "base" is basically
only useful for install/cd people, I'd let them make the decision.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
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?"

[Anthony Towns]

On Fri, Dec 23, 2005 at 09:59:18AM +0100, Stefano Zacchiroli wrote:
> On Fri, Dec 23, 2005 at 12:40:40PM +1000, Anthony Towns wrote:
> > > I don't like downgrading the vim -> vim-runtime dependency since IMO if
> > > a user apt-get-installs vim he expect a fully working vim installation
> > > (including help and syntax highlighting).
> > Right; but having vim Depends: vim-basic, vim-runtime; and having vim-basic
> > include /usr/bin/vim from current vim.deb doesn't seem terribly difficult?
> No, it is not of course. I don't have any particular objection on such
> approach.

The advantage is one less version of vim to maintain, and that people
who install the full featured vim don't need to keep a pointless copy of
/usr/bin/vim.tiny. *shrug* perl-base / perl is in a similar situation;
note that with vim-tiny (in whatever form) in base, it probably makes
sense to include vim-runtime as standard too.

> But still, people have complained in this thread about a size increase
> of about 370 Kb (nvi vs vim-tiny + vim-common), moving towards vim +
> vim-common would mean an *additional* 340 Kb size increase. Is this
> still considered a fair increase by the installer/cd teams?

I think the size increase complaints (at least so far) have all been
standing in for when people just want to say "I prefer nvi". The size of
base matters a little, but it's not an "every byte is sacred" situation.

Cheers,
aj (base maintainer, for those playing along at home)



signature.asc
Description: Digital signature

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Steve McIntyre]

Joey Hess wrote:
>
>[1] It's hard to say for sure since the i386 netinst CD is already too
>big for some installation methods and we haven't figured out if
>we're going to trim it back down, or drop it.

Ouch. I'd hope that the netinst should still work. As/when/if we can
drop 2.4 kernels then we should get some space back.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
You lock the door
And throw away the key
There's someone in my head but it's not me 


-- 
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?"

[Joey Hess]

Stefano Zacchiroli wrote:
> But still, people have complained in this thread about a size increase
> of about 370 Kb (nvi vs vim-tiny + vim-common), moving towards vim +
> vim-common would mean an *additional* 340 Kb size increase. Is this
> still considered a fair increase by the installer/cd teams?

I don't know that adding that 340k to the installed size of base or the
corresponding 188k to the size of the debs would be too much[1], but the
gain of going from vim-tiny to vim(minus -runtim) seems more marginal to
me.

-- 
see shy jo

[1] It's hard to say for sure since the i386 netinst CD is already too
big for some installation methods and we haven't figured out if
we're going to trim it back down, or drop it.


signature.asc
Description: Digital signature

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Stefano Zacchiroli]

On Fri, Dec 23, 2005 at 12:40:40PM +1000, Anthony Towns wrote:
> > I don't like downgrading the vim -> vim-runtime dependency since IMO if
> > a user apt-get-installs vim he expect a fully working vim installation
> > (including help and syntax highlighting).
> Right; but having vim Depends: vim-basic, vim-runtime; and having vim-basic
> include /usr/bin/vim from current vim.deb doesn't seem terribly difficult?

No, it is not of course. I don't have any particular objection on such
approach.

> Or would vim-basic really not run without the stuff in -runtime? (If the above
> means vim becomes an empty package, moving the stuff from vim-runtime into it
> might be feasible/worthwhile)

Yes, it would run, as vim-tiny runs now. No help (just a dummy page
explaining what's going on), no syntax,  But it would run. vim will
become an empty package indeed, but I don't think that would be a
problem.

> > If there's the need of more vim features in the standard installation I
> > would rather prefer to tune vim-tiny compilation including more
> > features. On this subject, please note that adding gpm support will
> > trigger the additional libgpmg1 dependency.
> libgpmg1 is already in standard, and is 50k of .deb.

Ok, not a problem then.

But still, people have complained in this thread about a size increase
of about 370 Kb (nvi vs vim-tiny + vim-common), moving towards vim +
vim-common would mean an *additional* 340 Kb size increase. Is this
still considered a fair increase by the installer/cd teams?

Cheers.

-- 
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: Experiment: poll on "switching to vim-tiny for standard vi?"

[Anthony Towns]

On Thu, Dec 22, 2005 at 07:39:59PM +0100, Stefano Zacchiroli wrote:
> On Thu, Dec 22, 2005 at 03:43:14PM +1000, Anthony Towns wrote:
> > > vim-tiny ranges from 696 to 1852 with a median of 898k.
> > > nvi ranges from 560 to 1040 with a median of 648k
> > vim itself is only ~600kB, ignoring its dependency on vim-runtime; is
> > downgrading that dependency a possibility, so base could include the
> > regular vim binary plausible?
> The philosophy in the packaging has been:
> * vim-tiny -> has smaller as possible version of vim
> * vim -> ordinary vim
> vim-tiny has thus been compiled with a small subset of features _and_
> minimizing dependencies. vim with a standard set of features without
> caring about dependencies.

Hrm, I see the figures above are mixing .deb and installed sizes too. The
deb sizes are nvi=288k, vim-tiny=377k, vim=570k.

> I don't like downgrading the vim -> vim-runtime dependency since IMO if
> a user apt-get-installs vim he expect a fully working vim installation
> (including help and syntax highlighting).

Right; but having vim Depends: vim-basic, vim-runtime; and having vim-basic
include /usr/bin/vim from current vim.deb doesn't seem terribly difficult?
Or would vim-basic really not run without the stuff in -runtime? (If the above
means vim becomes an empty package, moving the stuff from vim-runtime into it
might be feasible/worthwhile)

> If there's the need of more vim features in the standard installation I
> would rather prefer to tune vim-tiny compilation including more
> features. On this subject, please note that adding gpm support will
> trigger the additional libgpmg1 dependency.

libgpmg1 is already in standard, and is 50k of .deb.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Anthony Towns]

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

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[MJ Ray]

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?"

[Stefano Zacchiroli]

On Thu, Dec 22, 2005 at 03:43:14PM +1000, Anthony Towns wrote:
> > vim-tiny ranges from 696 to 1852 with a median of 898k.
> > nvi ranges from 560 to 1040 with a median of 648k
> vim itself is only ~600kB, ignoring its dependency on vim-runtime; is
> downgrading that dependency a possibility, so base could include the
> regular vim binary plausible?

The philosophy in the packaging has been:
* vim-tiny -> has smaller as possible version of vim
* vim -> ordinary vim

vim-tiny has thus been compiled with a small subset of features _and_
minimizing dependencies. vim with a standard set of features without
caring about dependencies.

I don't like downgrading the vim -> vim-runtime dependency since IMO if
a user apt-get-installs vim he expect a fully working vim installation
(including help and syntax highlighting).

If there's the need of more vim features in the standard installation I
would rather prefer to tune vim-tiny compilation including more
features. On this subject, please note that adding gpm support will
trigger the additional libgpmg1 dependency.

Cheers.

-- 
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: Experiment: poll on "switching to vim-tiny for standard vi?"

[Stefano Zacchiroli]

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: Experiment: poll on "switching to vim-tiny for standard vi?"

[MJ Ray]

Glenn Maynard <[EMAIL PROTECTED]>
> I much prefer vim-tiny over nvi, others have agreed (at least Frans Pop
> and Joey Hess), and not one person so far has actually said they prefer
> nvi over vim [...]

I strongly prefer nvi over vim.  I dislike vim enough to
install vile when I need a bigger vi than nvi.  Last I tried
(albeit many moons ago), vim's vi-compatible mode wasn't and
there seemed little interest in bug reports (attitude of: How
can you not prefer vim? Run vim and all will be well. Love vim.)

AFAICT, Lars Wirzenius and Andrew M A Cater told similar things.
I guess you don't count them for some reason.  So, we'll wait
for data on preferences and the size thing seems clear anyway.

[...]
> > Please cc me on replies.
> 
> This is the only time I'll do so, to remind you to set Mail-Followup-To.
> It's your job to set headers expressing your preferences [...]

MFT is conceptually broken non-standard DJB-ware, but let's not
have this debate again. If you're using mutt, I'm just asking
you to use g instead of l to reply, not hack headers - you
might like to bugfix mutt to support List-* if it still doesn't.
My request was as suggested by
http://www.debian.org/MailingLists/#codeofconduct
so please honour it.

Thanks,
-- 
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?"

[Anthony Towns]

Dropping -project.

On Wed, Dec 21, 2005 at 10:11:14PM +, MJ Ray wrote:
> Current unstable Installed-Size:
> vim-tiny ranges from 696 to 1852 with a median of 898k.
> nvi ranges from 560 to 1040 with a median of 648k

vim itself is only ~600kB, ignoring its dependency on vim-runtime; is
downgrading that dependency a possibility, so base could include the
regular vim binary plausible?

As long as the size increase is /reasonably/ small, it's not a problem;
and vim already seems to be on CD#1 anyway.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Anthony Towns]

On Wed, Dec 21, 2005 at 07:35:43PM -0500, Glenn Maynard wrote:
> On Wed, Dec 21, 2005 at 10:11:14PM +, MJ Ray wrote:
> > - vim-tiny is on fewer platforms than nvi, which seems as
> > important as size or accuracy of emulation.
> Vim still runs in 16-bit DOS, and I think it even has a functioning OS/2
> build, but it won't run on all of the platforms Debian supports?

vim's failing to build on sparc and arm, at least, with the following
error after compiling while trying to build the package:

cp: cannot stat `./debian/tmp/usr/bin/rview': No such file or directory

Cheers,
aj


-- 
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?"

[Joey Hess]

MJ Ray wrote:
> The increase is between 101% for ia64 and 58% for i386.
> vim-tiny+vim-common is smallish by current standards, but
> neither "about the same" as nvi, nor "only marginally larger".
> Was there a maths error near the top of this thread?

The very top of this thread contained a forwarded message containing the
text "(776 + 232 on i386)". If you're trying to imply some sort of error
it might help if you pointed to a message-id.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Joey Hess]

MJ Ray wrote:
> Who knows? It's not currently built for as many. For hurd-i386,
> hppa and s390, nvi is a working editor and vim-tiny isn't. I
> can't remember what counts as support right now (URL anyone?)

Oh, come on. vim-tiny entered the archive this week. The fact that we
have some slow buildds and ports like hurd-i386 that are perennially
behind is irrelevant to this discussion unless you can point to a build
failure log.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Russ Allbery]

Glenn Maynard <[EMAIL PROTECTED]> writes:

> I much prefer vim-tiny over nvi, others have agreed (at least Frans Pop
> and Joey Hess), and not one person so far has actually said they prefer
> nvi over vim--just that they prefer its defaults, which has been
> addressed.

Just to be completely unambiguous about my earlier message, I do indeed
prefer nvi over vim, regardless of how vim is configured.  It's smaller
and it does what I expect, which neither vim in its default mode nor vim
in its compatible mode does.

Also, I prefer not to have to configure my vi to behave like vi, but maybe
that will be changed.  It's not a matter of just configuring it on one
host, like it is with XEmacs.  I only use XEmacs for major editing and can
customize it extensively on the small handful of systems that I use all
the time.  I use vi for routine system administration, configuration file
editing, and all small edits, and I use it on a ton of different Debian
machines from a variety of different accounts that don't all share a
single configuration or set of home directories.  (I realize that other
people feel the same way about vim.  I'm just stating a personal
preference, not arguing that other people's preferences are wrong.)

On the other hand, I don't consider it a major issue and can live with
whatever decision people come to, which is why I voted both alternatives
above further discussion in the straw poll experiment.  :)

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
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?"

[Glenn Maynard]

On Thu, Dec 22, 2005 at 02:28:23AM +, MJ Ray wrote:
> Who knows? It's not currently built for as many. For hurd-i386,
> hppa and s390, nvi is a working editor and vim-tiny isn't. I
> can't remember what counts as support right now (URL anyone?)

I'll have to punt on that one, since I know nothing about those
platforms and why vim might not work on them.  I can't imagine it's
anything major if those are viable platforms at all, though.

> That's an incentive for nvi over vim-tiny, but nvi is the
> current anyway and I don't see many benefits of a change.
> The -devel thread seems to have started with two dubious
> claims: that vim-tiny isn't much bigger and more prefer vim.
> I've questioned the size claim in another subthread and
> surely vim users won't be satisfied by vim-tiny.

I much prefer vim-tiny over nvi, others have agreed (at least Frans Pop
and Joey Hess), and not one person so far has actually said they prefer
nvi over vim--just that they prefer its defaults, which has been
addressed.  I don't know how you can possibly call the claim that more
prefer vim over nvi "dubious"; it's a pretty clear-cut one.

It seems like a mindset I've seen elsewhere: "if you can't get 100%,
settle for 0%".  I'm 75% with vim-tiny, 95% if I'm not programming
(which I'm probably not, if vim-tiny is installed), and 0% with nvi,
and one doesn't always have the ability to install packages.

> Please cc me on replies.

This is the only time I'll do so, to remind you to set Mail-Followup-To.
It's your job to set headers expressing your preferences (which you
only have to do once, in your mailer configuration), not everyone else's
job to manually set your CC every time.  (You've been on these lists for
quite a while; I'm pretty sure you know this ...)

-- 
Glenn Maynard


-- 
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?"

[MJ Ray]

Steve Greenland <[EMAIL PROTECTED]>
> On 21-Dec-05, 16:11 (CST), MJ Ray <[EMAIL PROTECTED]> wrote: 
> > Current unstable Installed-Size:
> > vim-tiny ranges from 696 to 1852 with a median of 898k.
> > nvi ranges from 560 to 1040 with a median of 648k
> "Ranges"? Over what? Architectures?

Yes, architectures.

> > 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
> 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?

The increase is between 101% for ia64 and 58% for i386.
vim-tiny+vim-common is smallish by current standards, but
neither "about the same" as nvi, nor "only marginally larger".
Was there a maths error near the top of this thread?


Workings (rounded down, to be generous):

nvi alpha  328.6 760
vim-tinyalpha  471  1072
vim-common  alpha   79.9 232
   =total   alpha  550.91304
CHANGE  alpha  +67%  +71%

nvi amd64  288.3 668
vim-tinyamd64  433.1 900
vim-common  amd64   79.5 232
   =total   amd64  512.61132
CHANGE  amd64  +77%  +69%

nvi arm270.3 600
vim-tinyarm376.4 760
vim-common  arm 79.2 228
   =total   arm455.6 988
CHANGE  arm+68%  +64%

nvi i386   281.4 632
vim-tinyi386   368.4 776
vim-common  i38678.8 228
   =total   i386   447.21004
CHANGE  i386   +58%  +58%

nvi ia64   390.21040
vim-tinyia64   687  1852
vim-common  ia6482   240
   =total   ia64   769  2092
CHANGE  ia64   +97% +101%

nvi m68k   255.6 560
vim-tinym68k   339.5 696
vim-common  m68k78.3 228
   =total   m86k   417.8 924
CHANGE  m68k   +63%  +65%

nvi mips   302.7 824
vim-tinymips   457.31200
vim-common  mips79.2 232
   =total   mips   536.51432
CHANGE  mips   +77%  +73%

nvi mipsel 302.4 824
vim-tinymipsel 457.51200
vim-common  mipsel  79.2 232
   =total   mipsel 536.71432
CHANGE  mipsel +77%  +73%

nvi powerpc289.3 648
vim-tinypowerpc408.8 896
vim-common  powerpc 79.1 228
   =total   powerpc487.91124
CHANGE  powerpc+68%  +73%

nvi sparc  272.6 628
vim-tinysparc  376.4 804
vim-common  sparc   78.9 228
   =total   sparc  455.31032
CHANGE  sparc  +67%  +64%

no vim-tiny for:
nvi hppa   302.6 652
nvi hurd-i386  281.4 632
nvi s390   285.1 648

Hope that helps and please cc me on replies,
-- 
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?"

[MJ Ray]

Glenn Maynard <[EMAIL PROTECTED]>

> On Wed, Dec 21, 2005 at 10:11:14PM +, MJ Ray wrote:
> > - vim-tiny is on fewer platforms than nvi, which seems as
> > important as size or accuracy of emulation.
> 
> Vim still runs in 16-bit DOS, and I think it even has a functioning OS/2
> build, but it won't run on all of the platforms Debian supports?

Who knows? It's not currently built for as many. For hurd-i386,
hppa and s390, nvi is a working editor and vim-tiny isn't. I
can't remember what counts as support right now (URL anyone?)

That's an incentive for nvi over vim-tiny, but nvi is the
current anyway and I don't see many benefits of a change.
The -devel thread seems to have started with two dubious
claims: that vim-tiny isn't much bigger and more prefer vim.
I've questioned the size claim in another subthread and
surely vim users won't be satisfied by vim-tiny.

Please cc me on replies.

Thanks,
-- 
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?"

[Glenn Maynard]

On Wed, Dec 21, 2005 at 10:11:14PM +, MJ Ray wrote:
> - vim-tiny is on fewer platforms than nvi, which seems as
> important as size or accuracy of emulation.

Vim still runs in 16-bit DOS, and I think it even has a functioning OS/2
build, but it won't run on all of the platforms Debian supports?

-- 
Glenn Maynard


-- 
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?"

[Steve Greenland]

On 21-Dec-05, 16:11 (CST), MJ Ray <[EMAIL PROTECTED]> wrote: 
> Current unstable Installed-Size:
> vim-tiny ranges from 696 to 1852 with a median of 898k.
> nvi ranges from 560 to 1040 with a median of 648k

"Ranges"? Over what? Architectures?

> 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
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?

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
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?"

[MJ Ray]

Glenn Maynard <[EMAIL PROTECTED]>
> I have no sympathy for the notion of a "silent majority".  If you have an
> opinion, speak it.  [...]

Hard if you can't hear the question above the NOISE.

> wonder how many people will vote for nvi bacause "nvi is more like
> regular vi than vim".  This is important even for an "informal" poll;

I think that will be dwarfed by the "we love vim" effect.

> a vote is useless if it's heavily skewed, whether it's a poll or a GR.
> 
>  - vim-tiny is not much bigger than nvi (numbers?)

Current unstable Installed-Size:
vim-tiny ranges from 696 to 1852 with a median of 898k.
nvi ranges from 560 to 1040 with a median of 648k

vim-tiny depends on the 200k-ish vim-common too, so nvi seems
about half the total size of a vim-tiny today.

>  - even vim-tiny is much preferable to vim users over nvi, even without
>vim-runtime
>  - vim can behave just like old vi (as nvi does), and will do so when
>invoked as "vi"

- vim-tiny is on fewer platforms than nvi, which seems as
important as size or accuracy of emulation.

-- 
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?"

[Glenn Maynard]

On Wed, Dec 21, 2005 at 09:14:16PM +0100, Jeroen van Wolffelaar wrote:
> (Please followup to -project if you're replying on the subject of
> Because this is certainly not the first time I was curious on the
> opinion of the so called "Silent majority" (if such beast exists at
> all), I decided to simply try out this idea. Therefore, I've set

I have no sympathy for the notion of a "silent majority".  If you have an
opinion, speak it.  What I believe we we really have, most of the time,
is a vocal minority trying to inflate their ranks with a non-existant
"silent majority".

> up devotee (thanks to Manoj for writing it!) on [EMAIL PROTECTED],
> with results updated near realtime on
> http://master.debian.org/~jeroen/polls/. To participate in the context
> of the nvi vs vim-tiny discussion, please fill in the below ballot, sign
> it, and submit it to [EMAIL PROTECTED] It's currently only
> available to DD's, for practical reasons more than for any fundamental
> reason -- being a poll, I do think that opinions of non-DD's is
> certainly good to have too, possibly simply both tallied for DD only and
> for 'all'.

Voting on decisions is always disturbing to me: it always seems to be
small steps away from the point where decisions are made based on
uninformed popularity rather than technical merit.  Too often, in various
contexts, I've seen people who had an ill-formed opinion and losing an
argument demand a vote, in the hopes that there will be more people who
will vote for that opinion based on what seems "obvious" than those
spending the time to understand the issue.  This remains a problem
regardless of how loudly one asserts that a poll is "not a decision
making instrument".

That's the general case, of course--this issue is simple enough that
it could be summarized neatly within the poll, I think.  I have to
wonder how many people will vote for nvi bacause "nvi is more like
regular vi than vim".  This is important even for an "informal" poll;
a vote is useless if it's heavily skewed, whether it's a poll or a GR.

 - vim-tiny is not much bigger than nvi (numbers?)
 - even vim-tiny is much preferable to vim users over nvi, even without
   vim-runtime
 - vim can behave just like old vi (as nvi does), and will do so when
   invoked as "vi"

I think a poll might be a lot more useful if it was required that people
had to offer, in a sentence or two, their rationale for their vote.  If
you can't even express in brief terms why you think nvi or vim should
be the default, then your opinion is not interesting; and it would let
people get an idea if a lot of people are voting based on rationale
that has been discussed and disproven (eg. "vim is huge" and "vim
differs too much from vi").

(I wish people had to write a few paragraphs justifying their votes
for government elections.  Votes in essay format.  One can dream ...)

-- 
Glenn Maynard


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