The question of moving vi to /bin

b. f. bf1783 at googlemail.com
Wed Jun 24 13:13:50 UTC 2009


> On Tuesday 23 June 2009 15:41:48 Manish Jain wrote:

...

>About ed first. I might annoy a few people (which would gladden me in
>this particular case), but ed was just one of Ken Thompson's nightmares
>which he managed to reproduce in Unix with great precision. By no
>stretch of imagination would it qualify as an editor, because an editor
>can meaningfully edit only what it can first show. And ed has never had
>anything to show. A modern operating system like FreeBSD should really
>be kicking ed out of the distribution completely : bad ideas don't have
>to be necessarily perpetuated just for the sake of compliance with the
>original concept of Unix.

If you want to make a case for replacing ed(1), you're going to have
to come up with some concrete reasons for doing so, not just make a
(long and hyperbolic) statement that you don't like it.

...

>That's the whole problem of /rescue/vi. When you suddenly find yourself
>in single-user mode, the last thing you want to do is realise that
>tweaking is needed for something which should work normally just when
>you need it, and quickly too.

Yes.  But there have been some recent changes:

http://svn.freebsd.org/changeset/base/194628

that suggest that this problem is being addressed.

...

>But why are we talking about a few hundred
>kilos for such a basic utility as vi in times when everyone has hundreds
>of GB's on the disk, and the / partition itself is 512 MB by default.
>The BSD concept of having vi under /usr originated when resources were
>less by a factor of thousands (<= (100 MB disks), <= (8 MB physical RAM)
>and so on). When we are well past those kind of constraints, the concept
>needs an rethink.

No, we're not.  A lot of people are still using old hardware, or
embedded hardware, where efficiency in space and computational effort
are still important, and will remain so for a while.  Please don't
encourage bloat.

...

>Actually, there is an even more radical update that I would have loved
>FreeBSD to have initiated. Instead, the credit has gone to Microsoft.
>The simple thing is when a system has multiple gigabytes of RAM, the OS
>should be able give an option to the user of completely doing away with
>swapping and force all the action in real, physical memory instead.

??? Who is giving them that credit?  This isn't new.  You already have
some control over swapping via several oids:

vm.swap_enabled
vm.disable_swapspace_pageouts
vm.defer_swapspace_pageouts
vm.swap_idle_enabled
vm.swap_idle_threshold1
vm.swap_idle_threshold2
etc.

See, for example, tuning(7).  These have been around for ages (well,
at least since June 1996).  You can also build your kernel with:

options NO_SWAPPING

which takes precedence over these settings.  That option has been
around even longer. Linux has corresponding features, although they
didn't always work well on older kernels.

More recently, kib@ has just committed some changes that allow for
finer control of swapping, and, in the opposite direction, "anonymous
memory",  in his overcommit patches:

http://svn.freebsd.org/changeset/base/194766
http://svn.freebsd.org/changeset/base/194767
http://people.freebsd.org/~kib/overcommit/


b.


More information about the freebsd-questions mailing list