On Tuesday 23 June 2009 15:41:48 Manish Jain wrote:
> I hope the next release will address these problems, as well as a pretty
> reasonable request from me much earlier to move vi from /usr/bin to
> /bin. Even in single-user mode, you almost always need an editor.

Which is why you have ed(1) - both in /bin and in /rescue - and /rescue/vi (although that needs a bit of tweaking due to the /etc/termcap problem).

Bear in mind that /usr/bin/vi is over 300K, compared to the whole of /bin which is ~950K (if you avoid double-counting entries like /bin/csh and /bin/tcsh which are hardlinks to the same file), so you need to convince people who think /bin should stay small to let it grow by a third to save people learning ed(1).


Hello Jonathan,

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.

and /rescue/vi (although that needs a bit of tweaking due to the /etc/termcap problem)

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.

Bear in mind that /usr/bin/vi is over 300K

Actually, the cost is more than 300K because the terminal database would have to be put into / too. 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.

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.

This latter idea might still sound a bit far-fetched, but at least dumping ed and /rescue/vi to pave way for /bin/vi is certainly more than a workable idea. Till that happens, people like me might be forced to do outlandish things like copying /usr/local/bin/{bash,vim} to /bin and their associated libraries to /lib. I really mean copying, not moving - which could create problems with port/library upgrades at a later date. It works, is safe and easy, and requires no tweaking.

Hope there are some takers.

Manish Jain

Laast year I kudn't spell Software Engineer. Now I are won.
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to