Slashdot Mirror
Domain: bostic.com
Stories and comments across the archive that link to bostic.com.
Comments · 17
-
Re:Bloatware?
-
Re:Lies!
I still have not heard anything from you that would explain why vi is working better for you than VIM?
You're not going to. That's a discussion I've had too many times over the years and, well, vim users and the vim developers always end up going either "why on earth would you want to do that" or "if you add this obscure option to your vimrc, I'm sure it'll work". Since I don't *need* to use vim, and I don't *need* to convert you, I'm not going to go through all that again. Just take it as a given that I like vim so much that I ported another vi-like editor (elvis) to the Amiga because vim ticked me off so much maintaining a port was less of a hassle for me.
But, setting that aside... MKS, eh. So they're still around.
I've used MKS toolkit now and then. Back in the '90s it was the bomb. I loved it. It made Windows survivable.
But it soon felt, well, a little dated... and pretty soon Interix and Cygwin pushed it quite out of mind. Yes, I know Cygwin's a security hole waiting to happen... I caught Korn's lecture on that at Usenix... but people still use it because it's maintained and upgraded and not still trying to catch up with 4.2BSD.
And because it's free, of course. But things like shipping "a plain vanilla version of vi" in MKS instead of picking up nvi really doesn't help. And it's BSD licensed, so there's really no reason you can't pick it up...
-
Re:What's next?
vim http://www.vim.org/
Elvis http://elvis.vi-editor.org/
nvi http://www.bostic.com/vi/
vile http://invisible-island.net/vile/
viper http://www.delorie.com/gnu/docs/emacs/viper.html
March in the Clones; http://www.guckes.net/vi/clones.php3 -
I hate VIM
VIM is like the emacs of vi-editors. Why would you want something like that? Just use viper-mode in Emacs.
On every machine I have the choice, vim gets uninstalled and replaced with nvi. http://www.bostic.com/vi/
No more crap, no auto-indenting, no starting at a random line, no colors that f*ck the terminal up. Just the real pure vi editor. -
Re:Nobody Cares.
Emacs vs. vi?? They both suck!!
And what would you suggest instead? NEdit seems to be distinctly sub-emacs in features (though with different bindings) and Eclipse is massive (though good for a few things: notably Java and XSD/WSDL, all of which are impossibly officious without a fancy editor to help you out). Everyone knows that notepad is a terrible editor for real use, and ed is only for the real hard-core. (OK, I admit I like ed. But I wouldn't want to write code in it if at all possible, not these days.) If I've not mentioned what you think we should be using instead of vi or emacs, be prepared to say. -
Re:Not a fan of the adsNone of the above: Though this guy would have to be my pick! -The Geico Caveman </sarcasm> At least it would fit the stereotype.
-
Re:Increasingly unfortunate name
As a sysadmin, I have to ask how features like pop-up spellcheck and "omini" completion will help me edit config files on a vt102 terminal, (OK, my hard terminal is actually a vt520). vim is basically becoming a graphically-dependent editor that happens to use a similar editing structure to vi. Yes, I know about vi compatability mode, but that just throws out most of the last 'n' years of development.
Those features are aimed at people using vim as a programming editor (although I use it for emails via mutt as well along with just about everything). Also, the article showed gvim, rather than plain vim (which is entirely curses based with the exact same featureset).
It sounds to me like vim is overkill for what you're doing anyway (way too bloated and packed with unnecessary features for config file editing) - why not stick to a pure vi, like nvi?
My point? Not that development should be stopped, or that these goll-durned newfangled features ain't right, but that I wish it wasn't always trumpeted as "vi--but better." Most of the 'better' part of is are things that point away from vi.
From a my standpoint as a developer, it is vi -- but better. From a sysadmin standpoint, it's vi -- but more bloaty with useless stuff. I stick to nvi for servers since vim is just an unnecessary overhead. For day to day work though, I couldn't live without vim.
-
Re:waiting
-
Re:I've seen this before...
What's in the FreeBSD base system isn't "straight up vi" (which is proprietary if I recall right), it's nvi.
-
All You Could Ever Need
-
Re:Code folding is:
That's VIM, not vi.
-
Re:And for some reason......
-
Re:Nice and all
Radix sort is also not very good at sorting strings.
It's the best. It's impossible to look at fewer characters than what is possible with a radix sort.
Algorithm:
1. Put the strings into piles according to their first letter.
2. Subdivide each pile into further piles according to the second letter.
3. Subdivide each of the new piles according to the third letter.
4. n 5. Collect piles together
You only ever look at each character once! The problem in implementation is keeping track of all the piles, and everything you've said by way of criticism (all perfectly valid) is really criticism of an implemenation not the theory.
If you're interested, this paper suggests a good, efficient algorithm.
Also strcmp is not that slow over all. Since there are far far more people not named John Smith then there are that are named John Simth, strcmp() will complete the vast majority of it's calls in just a few operations.
strcmp() itself isn't slow, but when you're checking the same characters over and over again, performance is shattered.
Radix sort can not be done in place, thus requiring double the memory to run (will at least for the pointers which for a large list can still be quite a cost). If this addition memory needs to be swapped in and out the performance penalty can be quite nasty.
Naive radix sort implementation don't sort in place, but it's certainly possible. The American Flag algorithm described in the paper linked to above just does that. Memory usage is still problematic though, but it's nowhere near double.
Quicksort with a good pivot selection algorithm (to avoid the already sorted list problem) or Mergesort are still used quite often today.
They are, and they have their place, but that's not my argument. My point was that it's dangerous to generalise quicksort as a superior sort for everything. eg. shellsort is superior for small data sets.
This applies to radix sort too of course: for very specific input with very specific properties, radix sorting of strings may be weaker than some other algorithm. In fact, the sorting stage algorithm suggested in the original Burrows-Wheeler Transform paper highlights this.
In fact the Java library sort uses a modified mergesort, and the standard C library has qsort()
qsort() isn't necessarily a a quicksort implementation (ie. the ANSI standard doesn't require it to be) although it very often is.
I did check Knuth about this, and radix sort can get around its problems with a beefy machine.
Did you ask Knuth personally or did you simply check the Book? That sounds really impertinant I know, but the reason I ask is because most of the research on Radix Sort has been done since the Book was written. -
Don't ruin my Emacs! Re:There already IS gtk...Let me second that emotion. Emacs runs on just about anything now, thanks to the hard work of the GNU folks.... don't spoil it! When I have to run on something that doesn't already have Emacs, I can be pretty sure right now that I can just go snarf it, or have the local god figure do so... you go make this GTK-specific, and we not only lose the Evil Empire but MacOS, VMS, AOS, and who knows what else... and the fact that while it won't run on a DECWriter II (our OTHER favorite editor does that
Most of my Emacsing is done in terminal mode on xterms or remote shell sessions.... I go into graphics mode when I'm doing serious programming, but I'm a sysadm by trade, and most of the time character mode is more than good enough. Adding GTK widgets is something I'm likely never to use. Waste of time, if you ask me.
It's running right now on my Windows box at home and on my Linux box at work.
You sure you don't have that bass-ackwards? Or are you a gamer type?--
I used to run Windows for werk because I had to.
I run Linux at home because I want to.
(Lady willing come next week I'll run Linux at work too! -
The Third Direction: Automated ConfigurationUnfortunately, people seem to see there being two ways of managing system configuration:
- There's the UNIX Way
Where Real Men use vi to manually edit all the text files.
- There's the Windows Registry Way
Where Modern Administrators point'n'drool their way through menus, searching for the configuration.
These are the commonly-perceived stereotypes, and, too often, represent peoples' attitudes, whether pro or con.
Unfortunately, by focusing on this particular dichotomy, people miss the mark, in that neither approach is particularly manageable. Moreover, by thinking they are the only alternatives, people miss the directions for true improvement.
- There's a place for having a centralized "registry" of access methods to access configuration information.
It may be true that:
"Lumping configuration data, security data, kernel tuning parameters, etc. into one monstrous fragile binary data structure is really dumb." -- David F. Skoll
That doesn't mean that there wouldn't be value to building up a hierarchical "tree" that knows how to look up configuration information. The data can sit where it is now; the "tree" is useful for providng the administrator with a comprehensive way of getting at it.
- Automation means You don't have to touch it again.
Configuration work that the system does for you is the true labour savings; if the system cleans up after itself, and I don't have to do it, that is an automated system.
I'm glad to drop in an extra cfengine rule into
- There's the UNIX Way
-
Keith Bostic, nvi
The award should go to Keith Bostic, for nvi. Surely this is obvious? I'm sure all these other editors are very nice, but why reinvent the wheel?
-
Keith Bostic, nvi
The award should go to Keith Bostic, for nvi. Surely this is obvious? I'm sure all these other editors are very nice, but why reinvent the wheel?
