Slashdot Mirror
Common Traits of the Veteran Unix Admin
snydeq writes "Deep End's Paul Venezia offers a field guide to understanding your resident Unix veteran, laying out the nine traits common to this grizzled, hardcore set. From not using sudo, to wielding regular expressions like weapons, to generally assuming the problem resides with whomever is asking the question, each trait is key to 'spotting these rare, beautiful creatures in the wild,' Venezia writes. 'If some of these traits seem anti-social or difficult to understand from a lay perspective, that's because they are. Where others may see intractable, overly difficult methods, we see enlightenment, borne from years of learning, experience, and overall, logic.'"
Don't forget the neck beards.
vim? svelt? Puhleez. When not using ed(1), Real Unix vets use Bostic's One True vi, not some fagged-up Vegas showplace of an editor like vim.
wielding regular expressions like weapons
Reminds me of:
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
- Jamie Zawinski
Things you think are in the Constitution, but are not.
Lemme just email this to all my friends with the subject line "If you know someone like this pass it on LOL"
Real Unix admins would be reading this post in lynx.
We also throw a nickel at the rookie Windows sys admins and tell them, "Here's a nickel. Get a real operating system, kid."
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Butterflies - and no, emacs is not an option, unless you code the command yourself and store the code in your deepest vault.
Questions raise, answers kill. Raise questions to stay alive.
http://ozguru.mu.nu/Photos/2005-11-11--Dilbert_Unix.jpg
Someday we'll hit the human carrying capacity. And the band will just play on.
You're wrong, the article is right.
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
Of course. There's always "sudo -s", but that requires more keystrokes. If you're doing something like editing a bunch of configs in /etc typing sudo at the beginning of every single line gets a bit old. (Besides, if you're paying for all that backup media, you might as well use it every now and again).
Working...
Really? When your job is entirely about being root, sudo is just getting in the way. I happen to have run systems in a serious environment, and we never used sudo. I would say if you have something to do that ISN'T root, you sir are teh nub.
You're both wrong, I'm right.
Unless unix veteran is a code word for idiot of course.
Take #9: "Our thinking here is there's no reason why a reboot should ever be necessary other than kernel or hardware changes, and a reboot is simply another temporary approach to fixing the problem.". When a run away program fills the disk or sets off the OOM killer then after fixing the problem itself rebooting is the obviously wise thing to do - who knows what random proceess got put in a bad state by the resource exhaustion best reboot and get everything into a known good state.
And of course have fun when the machine does need to be rebooted for a "kernel of hardware change" and some vital service doesn't restart because no one checked that the damn init script was enabled.
You just prefix each command with "sudo". It becomes a reflex. You've essentially turned your regular account into a root account. You no longer really have a regular account.
That "#" prompt was invented for a reason: it provides a reminder. While you certainly could be oblivious to such a reminder, that is less a risk than always being one thinko away from doing root actions while feeling all safe and usery.
Better is a separate login window, keyboard, seat, font, color scheme, desktop, etc.
Seconded. Obligatory car analogy:
Relying on sudo to keep you safe is like relying on your car's bumpers to avoid injury. You'd have been better served just watching the f**king road.
Where the analogy breaks down, is that bumpers are still a good idea even if you're most cautious. There are other morons sharing the same road.
Your shell, however, is yours and yours alone for the lifetime of the process. If you don't trust yourself not to type something stupid, you shouldn't be working as an administrator. Period. Sudo was never intended to function as training wheels. To imply its necessity is to claim you, the junior admin, knows better than the senior admin. When you've done your trench time, you too will trust yourself.
Sudo's proper place is for developer and QA commands that happen with annoying frequency should an admin have to get involved.
http://www.jerkcity.com/jerkcity526.html
A real Unix admin wouldn't be posting as AC.
"To prevent this day from getting any worse, I'll just read ERROR as GOOD THING" 1GJU8xLuDKDxEs4KLf8fAGyptoDsqvEsBT
The reason that Unix SAs don't like to reboot is deep seated in the history of Unix running decades ago on hardware for which a reboot cycle meant interrupting potentially dozens of people all sharing the same machine for a sequence that might take 10 to 20 minutes if nothing went wrong. Rebooting was correctly viewed as something to avoid whenever possible.
Windows was not engineered for long uptimes until NT 4.0 and is a johnny-come-lately OS in comparison. Windows didn't run on significant (read: capable of simultaneously supporting more than one user in a non-trivial way) hardware until, what, 1994 or 1995? Meanwhile Unix and its intellectual antecedents had been supporting multi-dozen-user installations for nearly three decades.
When there's only one user, rebooting isn't nearly as big a deal as when there are 20, 30 or more. That dichotomy alone drove the reliability of Unix, and the the lax attitude of Windows.
Personally, even though rebooting my desktop Linux computer with it's fast processor, SSD and RAID disks, takes well under a minute, I still don't like doing it. There's something wrong: It shouldn't need to be done. If I'm rebooting for a non-hardware related issue, it's because I'm being sloppy.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
You've already ticked me off by wasting my time.
Link to the print version next time: http://www.infoworld.com/print/151276
I prefer my password. It's just a PITA that changes daily. alias s='sudo -i'
Same result as "su -" but with less typing.
Yes, root's password was set / changed. It's insanely long. I like it that way.
PS: this /. interface sucks now :wq
When your job is entirely about being root
I somehow doubt that. Does every process you create need root privilege? Do you ever use grep (or awk or sed) and do you really need to run it with root privileges?
With sudo you can selective run commands with root privilege.
Su to root, solve the problem, get out. I don't see what isn't methodical about that?
The article certainly isn't suggesting that one should surf the web or IRC as root...
The popular Linux community is so tied up in what Canonical has deemed "best practice" that it no longer trusts itself with the level of control it brags to Windowsland about having.
This guy lost me with the first thing on the list. Going directly to root is great - if you're a noob in mom's basement. Nobody who has ever run systems in a serious environment mucks around as root as an alternative to something like sudo.
Contrary to the article's stated rationale, there is a real reason not to use sudo: If you run some malicious code as the wheel user, it can modify the wheel user's environment. Then the sudo command runs in the wheel user's environment with e.g. a malicious $PATH and you go from having a compromised user account to having a compromised system.
Incidentally, this is also why you should never run "su" and always run "/bin/su -".
Really. I consider it a sign of inexperience and an indicator that the admin has never had to clean up after someone else screwed something up as root. That may be the case if you are super meticulous and you've been the only admin everywhere you've been, but no serious environment only has one root level admin and I have yet to meet anyone who was really good and super meticulous all the time.
I'm doing sysadmin, maybe one out of 20 commands I type *have* to be run with root access. If I am doing them all as root then there is a much greater chance of making a mistake and committing that system destroying action or, even worse, doing something subtly bad that nobody knows about until later when it's too late. It also makes me think twice (instead of just once) before executing that command as sudo.
Sudo logs commands that were run, by whom, and when. Even if I didn't care about whether I was root all the time or not, having a log of what was done with that access can be an indispensable tool when doing system troubleshooting. It's also a handy way of telling if someone screwed something up or if j00 wuz pwndz.
To me, running around as root and not using sudo is like using vi to look at a config file you have no intention of editing or similar. It's too easy to slip up and do something wrong once you get "in the groove". Add a page at 4am to that or a situation where you're at the tail end of a 30 hour emergency maint and it's beyond easy to screw things up.
Uh, sudo isn't a tool, its a wrapper to audit trail your ass and limit what you can run. The only reason to have it apply to admins is to watch them. Otherwise it just gets in the way. Its not like it adds something to the experience for anyone. It doesn't keep you from making a mistake, it just keeps you from running commands that someone else has decided that you don't need access to. That's like saying that locking away guns prevents you from shooting yourself in the foot. Its does... unless you are in the Army and your job is to tote the thing around on patrol for days at a time. There are simply some times in life where you have to know how not to shoot yourself in the foot.
The only place I ever had it applied to me was when I worked in the financial services industry, and I understood their position. Even then, the sudoers file was so badly conceived that, had we wanted to, it would have been a simple matter to get a root shell. Its difficult to keep out the very people that you need to keep the system running. I'd argue that it is generally not even worth trying it at all unless a very unforgiving regulatory commission is breathing down your neck.
If you don't know how to use root access in a way that doesn't screw up your box, you don't deserve to have a job as an admin, period. Its not like its easy to bumble around on a command line and screw something up. There's really only one really easy thing to do that will potentially demolish a box and that's rm -rf * in the wrong directory and it is a rare sudoers file indeed that prevents a sysadmin from running 'rm'. You could argue a reboot or shutdown on a box with something like a database might be a problem as well, but after that, you actually need to put some effort in screwing up your host with the other commands. Even format/fdisk requires you to think about how you are going to reformat your disk.
I use sudo a lot... to make sure developers can't screw up boxes and do cute little tests in production. But my rule of thumb as an admin is that sudo is something that is inflicted on someone else.
vim? svelt? Puhleez. When not using ed(1), Real Unix vets use Bostic's One True vi, not some fagged-up Vegas showplace of an editor like vim.
That's like saying Real Unix vets still use telnet and rsh to remotely administer machines. Sometimes it's nice to be able to move up and down lines without having to leave edit/write mode. vim is used by Real Unix vets who have kept up with the times, just like ssh. Only washed up has-beens don't learn to eventually use better tools.
Damn programmers and their butterflies, the bane of a real sys admin.
Why "sudo -s" instead of "sudo -i"?
su su sudio?
[UID-HeinzIntel]
bullshite. I've been syadmin for 16 years, you NEVER get on as root unless stuff is seriously broken. if you don't know how to properly use ACLs, SELinux contexts, etc - then you're not a sysadmin, you're a hobbyist. No serious, experienced UNIX admin would spend more than 1% of their time as root.
This guy lost me with the first thing on the list. Going directly to root is great - if you're a noob in mom's basement. Nobody who has ever run systems in a serious environment mucks around as root as an alternative to something like sudo.
Nonsense. Su is much simpler software and much less likely to have security vulnerabilities. Sudo has had many. Allowing the 'sudo' binary to be setuid root in a serious environment is considered a major risk. The 'su' binary is much simpler code, and slapping the setuid bit on it is considered much safer. Well, on BSD 'su' binary is extremely safe. On a GNU/Linux OS, system's setuid su might be linked against a nightmare called GLIBC, but then sudo would be also. Sudo has the issue of 'subtle/sneaky ways around' any configured policies. And sneaky ways to gain sudo permissions not assigned by policy.
Assigning full Sudo privileges to ANY user is a serious security risk, since you have reduced the number of passwords that must be guessed to gain full root privileges to one password, because sudo requires a password that is the same as the user's login password. The security of requiring knowledge of the user password and separate root password is considered stronger; when you disable root login and require wheel/admin group membership to 'su'. If you assign full sudo privileges to any user then only that user's password is required to gain full root access, which is a reduction in root authentication security strength.
Also 'idle timeout' for root logins is ineffective when sudo is used. If a third party gained access to any logged in ssh session they can run sudo commands; 'sudo command timeout' can be defeated by merely staying logged in until the legitimate user logs in somewhere else and runs a sudo command; once any legitimate user types the proper sudo password, ALL terminals/remote login sessions under the same username can use any 'sudo' command without a password reprompt, due to the way sudo is designed.
Su is used in serious environments all the time for the purpose of system maintenance and is considered preferable to sudo for such purpose --- hardly anyone ever even imagined using sudo for that purpose until 5 or 6 years ago. Sudo is a relative newcomer, not installed by default on most systems, and the purpose it was created for is misunderstood if you suggest actual admins use it to perform commands. Sudo is for enabling non-admins to perform some tasks that require UID 0 privileges, under rules established by the system admin; that is the reason the Sudo tool was created, its purpose for existing, and it has nothing to do with the root/sysadmin performing their own duties which actually require root.
That is 'sudo is for partial roots / guest root users, "guests" who are to temporarily have root access but not be one of the persons entrusted with the root passwords.
If you don't login to the system to perform administrative tasks, it is better to simply login as a normal user and then 'su' when you need it. That way you have to know two different passwords to do things as root; which is strong security.
My environment has some critical systems with minimal installs, where sudo isn't even installed and won't be; root filesystem being read-only and requiring signed binaries and all. Sudo not even available for some older OS flavors.
It's common to have some paths non-root isn't even allowed to CD into; and this is an improvement for security, but of course sudo is useless here: Hint: there is no such thing as 'sudo cd'; if you think otherwise, you need to lookup what the cd command does again.
The fact of the matter, is, when you are performing system administrative tasks, typing 'sudo' after each command is too cumbersome. Convenience, and speed matter, as they have a direct impact on admin performance and efficiency. Sudo introduces inconveniences that are likely to result in serious system-e
True. I will reboot a host without a second thought if a specific type of issue comes up. Root cause analysis is great, but when you're in production, the host really needs to be running. You can figure out the RCA from the logs later on, if need be.
However, most issues with a box can easily, and much more quickly, be fixed by simply restarting specific processes. I've had plenty of hosts stay up for years at a time with nothing else needed but to occasionally restart some processes. And that is the way it should be. Rebooting isn't some magical maintenance cycle where the oil gets changed and the hamsters are replaced, its just a wipe of the RAM and reload of the OS to an initial state. It doesn't fix hardware errors, bad code or poor planning.
Unfortunately, most of the time, the order comes from someone who doesn't know what they are doing. In that case, as long as it doesn't make things worse, if it takes longer to convince them to not reboot the host than it does to actually reboot it, you might as well go, "Right away, sir." and get it over with.
I have to go with the GP on this one. It's not that vim is inherently bad, it's just that it's *unnecessary*. It includes tons of features that an old-school admin has no use for. Sure, most of us use it anyway because modern Linux systems usually don't include our good friend vi (it's usually just a symlink to vim), but we rarely use the features that separate vim from vi. Moving in and out of edit mode is second nature. Hell, even using the arrow keys to move around is a needlessly inefficient waste of motion, since the arrow keys are usually far from any other useful key on the keyboard. The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on.
The comparison to ssh is inaccurate as well. We use ssh because ssh gives us clear security advantages over telnet and rsh, and allows us to use one tool where we previously needed two. Any Unix admin worth his salt, no matter how long and luxurious his neck beard, will gladly upgrade his tools to improve his own efficiency or increase security. SSH does both of those things, while vim does neither.
That is just stupid. System destroying actions are system destroying actions. Sudo or su or runlevel 1, if you are not thinking out your actions, you have no business executing that action. Both commands can get you into the same trouble.
Even if you do think out your actions, errors are possible. Use of sudo is more error prone as soon as you start keying simple scripts into the shell, because there are actually two shells involved now.. the non-root shell, the sudo command line, and the shell sudo will spawn to process the command requested, which will actually be spawning yet another subshell for each command.
In terms of typing the commands, this is a metacharacter escaping nightmare.
You want to run... for i in /root/*.txt ; do file $i ; done
Oops... sorry... you're going to have to do
sudo -s for\ i\ in\ \'/root/\*.txt\'\ \;\ do\ file\ \$i\ \;\ done
And if you miss a single "\"... well, you'll be lucky if it just gets refused by your shell.
Good luck reading that later, or revising it later
When not using ed(1), Real Unix vets use Bostic's One True vi, not some fagged-up Vegas showplace of an editor like vim.
Indeed.
A particularly nasty vim change is that:
- In vi "u" undoes the last change - even if it was another "u". Hit "u" repeatedly and the screen flips between with and without the last change, making it blink. Useful if a multi-change command may have done something goofy.
- In vim "u" backs you through a history of changes. Handy sometimes. But to redo you have to "control-r". Forget about blinking the screen to use your eye's motion sensors to spot the trouble. Also watch out for accidentally undoing a bunch of changes just before you close and exit. Oops!
Geez, guys. If you want to add new stuff (like a history to go backward through), don't change the behavior of an existing command. Add another, or at least make it configurable - preferably with the default the old behavior.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
With sudo you can selective run commands with root privilege.
You can do that with 'su -c' too, and it's more secure, since you have got to know the root password.
The trick is one never closes Emacs down - so it's always there. Just flick to the window with your Emacs, edit the file, save it, and go back to what you were doing. Those "editor AND the kitchen sink" jokes are very true, but you only have to open it once.
Even better, using TRAMP you can be running your Emacs as your normal user, and use the sudo method to edit a system config file - avoiding running the editor as root. Pretty nifty, eh?
I'm proud of myself - two holy wars (Vi/Emacs and su/sudo) in one post!
Sudo everything provides an actual audit trail to the actions taken by an admin. which is essential in environments where governance and acountability are required.
Uhuh.... unless you 'sudo vi /some/file.txt'
And then realize, while you're editing... hell.. I need to do X other thing...
So without exiting vi, you enter :!bash
Do that thing as root, and type exit to return to VI.
I would say you're wrong... sudo doesn't log everything. Sudo just logs the name of the process started; not actions taken by that process.
System admins commonly use scripting for many tasks, and sudo does not log when actions are taken from STDIN.
The only real "logging of admin actions" are facilities such as the kernel auditing daemons. Or actual logs of the terminal session, which are in fact more reliable than some untenable kludge effort to log actions by spawning a sudo process for every command.
You'll need to rewrite 'sudo' to be THE actual shell (including for scripting purposes) before it can be the least bit effective at that.
I dare you to list 10 *Administrative* tasks that don't require root privileges.
Seriously, if you're not starting or stopping a service, editing configs that only root can edit, or reading logs that only root can read -why are you even logged as anything but a user -placing you squarely outside the context of this conversation?
ACL's and SELinux contexts are not the point, we're not talking about uploading changes to the corporate website. We're talking *specifically* about sudo (root) vs sudo su - (root).
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
Sudo everything provides an actual audit trail to the actions taken by an admin. which is essential in environments where governance and acountability are required.
Provided you don't trust it to actually do those things. If someone can run 'sudo su -' then they own the system and can make the sudo log files say whatever they want, including removing the fact that they ran 'sudo su -'. Ditto 'sudo emacs', 'sudo dd', 'sudo mv' or any other command that as root will execute subsidiary commands, write specified data to specified files or any various other routes to a root shell. And in most cases you don't even need to muck about modifying logs: Just 'sudo emacs /etc/something/innocuous' and nothing untoward appears in the sudo log but you can run unlogged commands from within emacs, etc.
sudo can be useful in situations where you have a very limited subset of commands that a user should be able to execute as root and each will run as root without allowing the user to achieve a root shell. The trouble is that most commands that aren't already setuid aren't especially designed that way, so that scenario doesn't happen very often.
I guess you could say it's useful if you want to have some kind of faith-based auditing mechanism where you assume your sudoers aren't malicious and therefore won't modify the logs or work around the logging. But if you trust your sudoers that much then why do you need to audit them? It smells like a mechanism to provide the appearance of auditing so that someone's PHB can be satisfied that auditing exists, even though you can't really trust the audit log to be complete or correct.
He makes a pretty good point that going to root forces you to think through your actions. I don't see the same "everything I now do carries a consequence" mentality with frequent users of sudo.
The problem is we have people casting opinions based on how they think people will act differently while using sudo VS su.
Possibly cognitively biased due to how the person who has the opinion personally reacts, whether they actually are a sysadmin, and how much they actually use sudo.
Until someone performs an actual scientific study... claims that people are more careful when using 'SU' or more careful when using 'SUDO' don't hold much water.
All we can really definitively say is SUDO offers a warning message for first time users, which may have an influence on how cautious first time users are when using root privileges from the CLI.
I wonder how much effect it has on tinkering behavior... are people who use sudo less likely to tinker with their Linux desktop systems. Possibly this causes them to not become as familiar with Linux as 'SU' users are.
Possibly tinkerers/hackers just 'sudo su -' anyways
Sometimes you need to make a mistake to learn most efficiently
On a server, what could I possible need to do that doesn't require root?
"Man, if you gotta ask, you ain't never gonna know!"
For my file server 159 out of the last 500 commands featured sudo in them. On my database server, the number is 199.
On one of my main application servers, the user account for the service itself isn't even in /etc/sudoers. All of the maintenance and administrative tasks are done without resorting to extra permissions.
Crumb's Corollary: Never bring a knife to a bun fight.
Ok, logging into to a database is *not* being a Unix/Linux Admin, it is managing a database.
Listen. The people who log in to make changes to the database, and update the website(sorry, application server), are *USERS*, even if some of them are in sudoers, they are not the Admin (who put them in sudoers).
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
You must not have ever admin'ed many big iron servers. You know, the ones which take upwards of 30 minutes to reboot and are typically servicing 100+ users or mission critical applications. As the rest of the article says, simply rebooting doesn't fix the underlying issue. All you do is set yourself up for a repeat down the road. You are simply kicking the can down the road for someone else to pick it up and put it in the trash/recycle bin...
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
Why the hell didn't my link show up? http://i4.photobucket.com/albums/y129/Scarletdown/Dilbert-Unix.png
This space unintentionally left blank.
You, like most others in this discussion and TFA's author, do not understand what sudo is for.
Sudo is not there to help sysadmins avoid foot-shooting. That is merely a useful, but relatively insignificant, fringe benefit.
The point of sudo is to allow secure separation of duties and some semblence of an audit trail.
Sure we do.
We write a script that...
Reads the story. :)
Opens the reply form.
Searches our databases for related information.
Creates a whimsical yet topical reply.
Inserts it into the comment box
And then counts down the seconds due to the damned 15 seconds required between opening the reply form and submitting it. Mine usually gets it in with 14 seconds to spare.
Of course, we can't allow it to get first post every time. That would be far too obvious. Mine is set to randomly try about once a month.
Th at silly "Watson" Jeopardy AI has nothing on us. But, we couldn't be bothered with such silly games. We have more interesting things to do, like see how long we can keep a Slashdot thread going, or how long we can keep people interested in a conversation on IRC.
Serious? Seriousness is well above my pay grade.
All the major changes are documented under ":help vi_diff.txt". You can set the undolevels option to 0 to get the vi behavior. Also see ":help undo-two-ways".
Yes. This is why you disable all those backdoors and only specify particular commands that can be run in /etc/sudoers, with others either denied, or lighting up your IDS/system monitoring like a Christmas tree.
(This also serves as a handy reminder that properly securing systems is *extremely difficult*.)
You sir, are full of shit. Sudo IS ROOT. Repeat after me a second time, sudo IS ROOT. It's just annoying root. If users need root to do their mundane work--which is what sudo is for--there's something wrong that needs to be handled by code.
As far as slipping up, uh, what are you going to screw up? I mean, all your configs are version controlled in CFEngine/svn/cvs right? And you have an extensive library of base system images right? You have a bootstrapper right? And your data is on external snapshotted storage right? And you have backups right?
Surely you do a double take on each rm -f, that's about the only one you have to think about. And sudo is not going to save your ass in that scenario anyway, unless you have rm turned off, which....what would be the point of that? Compared with a database where you can just drop all; bye, replicate to the peers, I'd say you're pretty paranoid and frightened little bunny and probably don't really understand your system enough to rebuild it from the ground up (which is the worst case) (rm -rf /). When you do have that understanding and the ability to rebuild very quickly (a fully running production environment), as all good admins do, then you have the confidence to run around as root and actually get stuff done. In fact, I recommend rebuilding as much as you can until you can do it in minutes. Because "serious environments" don't have lots of crufty hacks and unauditable implementations and changes. They have testable, provable, deployable configurations. See ya, wouldn't want to be ya! ;)
Cool! Amazing Toys.
Did you try this:
:set cpoptions+=u
And it even talks about your issue under ":help u". Including how to do the above.
Daniel Klugh
Su to root, solve the problem, get out. I don't see what isn't methodical about that?
By using sudo, you get to skip the last step.
Only if your solution to the problem only involves one command. Which, in my experience it seldom does.
Sudo is a crutch for home-users who don't trust themselves to remember if they're in a root shell or not. "Real Unix Admins" don't have that problem and don't need sudo.
"Total destruction the only solution" - Bob Marley
I still use telnet, mainly for connecting to remote http and smtp servers.
Telnet sends terminal management information included in the byte stream. Use netcat or socat if you just want to pipe stdin into a TCP session.
The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on
I second the other poster's WTF here. It's one thing not to rely on the advanced features of vim - after all, the Single UNIX Spec only mandates vi, so it's the only thing you can guarantee being available, but it seems crazy to not take advantage of them when they are available. Do you also turn of auto-indenting and multi-level undo so that you can spend more time typing and less time actually being productive?
I am TheRaven on Soylent News
VI vs Emacs is an old and silly argument. This guy loses major points for essentially claiming that the only one true editor for "veteran UNIX admins" is VI.
We're talking about admins, not programmers.
Give me Classic Slashdot or give me death!
Any Unix admin worth his salt, no matter how long and luxurious his neck beard, will gladly upgrade his tools to improve his own efficiency.
Which is why, as a seasoned UNIX admin, I remove all vi from my systems (to prevent broken programs that do not use $EDITOR or /etc/alternatives from dropping me into vi) and use emacs exclusively. Or jove on small systems.
C-X-( and M-x yank-rectangle improve my efficiency vastly for the one-off scenarios which it is not worth scripting.
Original article author apparently has never met seasoned admins of the emacs species. Specist! :-)
Someone had to do it.
The great keepers of Unix lore are stirring from their hammocks, putting down their mai-tais, and shooing the mice out of their beards. This is what they have said to me.
When I log into my Xenix system with my 110 baud teletype, both vi
*and* Emacs are just too damn slow. They print useless messages like,
'C-h for help' and '"foo" File is read only'. So I use the editor
that doesn't waste my VALUABLE time.
Ed, man! !man ed
ED(1) UNIX Programmer's Manual ED(1)
NAME
ed - text editor
SYNOPSIS
ed [ - ] [ -x ] [ name ]
DESCRIPTION
Ed is the standard text editor.
---
Computer Scientists love ed, not just because it comes first
alphabetically, but because it's the standard. Everyone else loves ed
because it's ED!
"Ed is the standard text editor."
And ed doesn't waste space on my Timex Sinclair. Just look:
-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed /usr/ucb/vi /usr/bin/emacs
-rwxr-xr-t 4 root 1310720 Jan 1 1970
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990
Of course, on the system *I* administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!!!!!
"Ed is the standard text editor."
Let's look at a typical novice's session with the mighty ed:
golem> ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
---
Note the consistent user interface and error reportage. Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.
"Ed is the standard text editor."
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code! I just want an EDitor!!
Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED!
ED! ED IS THE STANDARD!!!
TEXT EDITOR.
When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely
you jest. They chose the most karmic editor of all. The standard.
Ed is for those who can *remember* what they are working on. If you
are an idiot, you should use Emacs. If you are an Emacs, you should
not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
?