Date: Wed, 24 Jun 2009 06:13:49 -0700 From: "b. f." <bf1783@googlemail.com> To: freebsd-questions@FreeBSD.org Cc: invalid.pointer@gmail.com Subject: Re: The question of moving vi to /bin Message-ID: <d873d5be0906240613s1050323bpdd28aaedddf2cb9d@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d873d5be0906240613s1050323bpdd28aaedddf2cb9d>