I love mythology and there's nothing like hearing a technology myth to make my day complete. Just today someone applied one of the following myths in a conversation with me. I didn't say anything but it gave me the idea for this post. Here are the five myths related to *nix systems that I hear most often when dealing with technical and non-technical people alike. You'd be surprised as to how often even the most technical people spout these myths to each other and to the unsuspecting and unknowledgeable bystander. I have to bite my tongue when I hear them. And now that you know them, I hope it ruins your day too when someone slips into mythland with one of these gems.

They are in reverse order of how much they irritate me. Enjoy.

5. Logging in as Root - The long-held myth that you should never login as root is ridiculous. The logic goes something like this: Login as a standard user, then su to root or use sudo to run something as root. Yes, it's safer to do so but not by much. If you su to root, then you are root. If you use sudo then you are executing a program, editing a file or doing whatever it is you're doing as root.
Should you disable the ability to ssh as root? Yes.
Should you never login as root to a system? No.
Should you always use sudo to perform single commands as root? If you're afraid of what you might do. But there's a caveat with sudo too. If you're actively doing things with sudo, you only have to enter your password once during a session, unless you walk away or take a five minute break, then you'll be prompted again for it.
If you're careless, you're going to make unrecoverable errors regardless of using su or sudo. Be careful.

4. su is SuperUser - OK, so this is a light myth but it's one worth busting. So many people use this term incorrectly that it is almost acceptable terminology. The term su does NOT mean superuser (super user). It means substitute user. It is used to login as another user though many use it for logging in or taking on the characteristics of the root user.
And for those who still don't believe me, this is from the su man page:

su - run a shell with substitute user and group IDs

There is no superuser. There are users and the root user. And there's no substitute for those terms.

3. *nix Systems Can't Get Viruses - This myth is a bit gray for some people. A *nix system can get viruses under certain circumstances. A virus is a computer program that can copy itself to other computers thereby infecting them with a harmful or potentially harmful payload. One of the circumstances where *nix systems could get viruses is where a user has access to a *nix system and other *nix systems on the same network. This user could deploy a computer program that would replicate itself and deliver its payload on all the systems. The virus would be even more effective if the user account has or gained root user access and wrote to cron to fire itself at a specific time and date. Once the payload is delivered, it would erase its tracks and itself.
So, to say that it's impossible for *nix systems to have viruses is incorrect. It isn't common but it can happen. And, yes, even the beloved Mac is susceptible and it is now *nix-based.

2. *nix Systems are More Secure - This is a very common myth that swirls around *nix systems and I don't expect that my entry here will make it go away. Any system can be insecure or can be made to be very secure. It has nothing to do with the operating system. It has everything to do with how that operating system is implemented. I had a co-worker with a FreeBSD system that was hacked. FreeBSD is well-known for its heightened security. But it takes some careful thought about what you're doing. It takes patching, updating and upgrading to prevent security issues. It also takes vigilance to make sure your systems are up to date and not compromised.
Remember that no system is completely secure. We used to say the only way to secure a system is to unplug it but that isn't true either as someone can still pick it up and carry it away. Don't forget physical security.

1. You Never Have to Reboot - I love this one. Every uninformed *nix nerd in the world will tell you that you never have to reboot a *nix system. It's laughable, really. For those of us who exist in the real world, you know that you have to reboot, and should, on a regular basis. Some enterprises reboot their systems weekly, monthly or quarterly. Where I currently work, it's quarterly.
There are good reasons for rebooting and some of them are: hardware maintenance and upgrades, kernel changes, major patches, getting rid of zombie processes, diagnostics and memory refresh.
I once used an Oracle database server (Solaris) that had an uptime of about 5 years, which is really, really stupid and here's why. The system administrators needed to do some major patching on that system but were afraid since it had been up so long. The system also needed a memory upgrade because it was 'thrashing.' Add thrashing to the list of reasons to reboot.
Once the system was patched and rebooted, there were lots of errors. Lots and lots of errors. Problems that had amassed over the last few years that, if taken one a time, could have been solved but after we saw what had happened, no one could determine what to do next. We upgraded the RAM and restarted the system. It kept failing and finally was decommissioned and replaced.
The moral to the story is that responsible system administrators would have done their due diligence (and their job) and maintained that system appropriately. Yes, you do, in fact, need to reboot your *nix systems.

Do you have any other technology myths that you can add to the list?

Edited by khess: n/a

7 Years
Discussion Span
Last Post by ripratm

After reading this article, I can only assume that you don't have any idea what you're talking about.


I'm 100% in agreement with Jess912 on this one. The Author of this article has absolutely NO idea what he is talking about. I've been a GNU/Linux user for over a decade, and not a word written above is even remotely accurate today.


I thought su meant switch user, not substitute. Oh well.

I'd really disagree with points 2 and 1.
While *nix systems can be configured to have more holes than a plate of swiss cheese, it's built for a multi-networked, multi-user environment. That fact alone means there is more security in any *nix system than, say, Windows. As for FreeBSD being hacked, perhaps the hacker had many more resources at his disposal, such as a cluster or even a botnet, helping him get through; The article doesn't mention what his password was, which for all we know, was password.
The largest security risk in any organization, for any computer, is the user.

As for never rebooting, I do agree with some points. Yes, it's good to refresh your ram, remove zombie processes, etc.
But with KSplice, you don't have to reboot even after a kernel replacement / update. It handles it all live. And when you have servers running, 99.9% uptime minimum means no reboots unless necessary. Reboots on a regular basis seem to contradict that; shouldn't servers be built and maintained so no zombie processes are created, so all required packages are maintained and updated, secured to the hilt?
The longest running server I heard of was a Gnu/Linux machine that had been running for 10 years. It either had a hardware failure, or the company got rid of the machine and replaced it with something else.

I also don't mind logging in as root. Obviously I do not do my web browsing as such. It's great for maintenance though. Distros like (K)Ubuntu which stop a user from logging in as root, are frustrating to work with.

Point 3 is fairly accurate though, as viruses do exist but require root access or security holes to manifest. Most holes are patched quickly as it is.


The author of this article obviously takes several things out of context, and is wrong about others.
1: Yes you do need to reboot Linux systems occasionally, but not nearly as often as Windows systems.

2: As another commentor points out, Unix (and Linux) wer designed from the start to be secure network OSs. Windows was never designed to ne a network OS, and they still haven't got the network security (or any security) thing right yet.

3: This is fairly accurate (as another pointed out). The biggest security problem is uneducated users who will install anything (without checking for viruses/spyware/adware) and click on any attachment that they are sent.

4: As if this matters at all?

5: Never is the wrong word here. However, you should seldom (if ever) need to log in as root, and you should only do so when it is necessary. Too many Windows users are used to having


Umm, you guys think that Unix was designed as secure? That is wholly incorrect. Unix was originally designed as a workgroup operating system as a replacement for Multics with very little security in mind. It's only after it gained more widespread acceptance that security became a concern. Why else would you have services like the "r" services and commands? Have you ever heard of finger and the .plan file? What about a .project file? How about the talk service? How about FTP and Telnet?
These are all insecure and they were part of *nix (Still are if you want them) but to say that it was designed as secure is incorrect.
So, tell me again, please--where you think I'm incorrect in anything I said.

And to jejejeje:
See comment #7 on that link you sent me to--it reads:

I’m looking at volume 1 of the “UNIX Programmer’s Manual, Revised and Expanded Version”, published by Bell Laboratories, copywrite 1983, 1979 and according to this source, su means “substitute user id”. Of course the C code you posted above predates that, but I think you might be misinterpreting the comment. The comment is merely saying the “substitute user id” command is used to become the “super-user” AKA root user.

That's published by Bell Labs...you know, the people who started Unix. And posting the excerpt from the su man page didn't help either, I guess.

Anyone else? C'mon, put 'em up, put 'em up, I'll murderlize you even...


wow:-) I'll bet the author thinks it over very carefully before making another yelp!!!!

be it right or to the left the author has us all thinking, and lots of really good info has been brought out by posters, and I'm thankful for that. So I thank the author for setting wheels in motion that has given me much good information on a linux procedure that has always caused me to question my intelligence.

Edited by ultrapup: more thought process



Thanks, you "get it." It must be my roots as a teacher that makes me want to challenge accepted thought and make people think a bit. A lot of people don't get it. They also don't get my offbeat and dry sense of humor. It takes time, I guess. Thanks for reading.


And for some reason, my man page for su says substitute...

Others incorrectly use the term super user.

Show me that user on a *nix system. There are users and there is the root user. No super. I'm sorry,...you're not going to turn Latin into Italian for me by saying it wrong. Ah, that's me again, trying to educate. ;-)


Windows was designed as a single user standalone workstation.
Linux was designed with networking and multiple users in mind.
So Windows compared to Linux is still far behind in terms of security, unless it is not connected to a network (when it really gets high marks).
You can get a Linux system configured to be insecure. But comparing default Linux to Windows installation- give me a break!


This man has no idea of what Linux/UNIX is, or an operating system is, it is obvious that he is in the job market by creating a hype of him by writing simple crap articles on topics such as fdisk - just copied the man page. He did not go to college for a CS or related major. I 100% agree with the posts on here. YOU CANNOT BECOME A LINUX GURU OR AN AUTHORITY BY POSTING BLOGS AND WRITING ARTICLES ON LINUX JOURNAL.


Do you get paid for writing this $%&% ?

When you write an article about myths with more myths .... there must be something terrible WRONG about it....


fdisk? Linux Journal? What are you talking about?

What myths did I write?


Pretty ignorant comments about Windows having no security, as usual.
Windows Vista and Windows 7 are very secure systems, you read a lot about Windows vulnerabilities but what those CNN and PCWorld articles don't mention is that they are almost impossible to exploit because of anti-exploit technology in the OS (even before being patched). Vista and 7 have things like ASLR, DEP, Sandboxing, stack/heap integrity checks and so on. Of Course XP doesn't have these, it was released before CPUs had NX/XD and without DEP the other stuff would have been mostly useless. The hacker who won multiple pwn-2-own contests, the most famous of its type in the world, stated after the last contest that even Snow Leopard was not as secure as 3 year old Vista (due to it's poor ASLR, not to mention the fact it does not sandbox the browser by default like Windows does), and he is a Mac lover. As far as Windows needing to reboot frequently, well I reboot this Windows 7 box every second tuesday for security patches and every couple of months for new Nvidia GPU drivers. Unix doesn't get Viruses because virus writers don't target computers with 1% market share, because that would be dumb and a waste of time. Sure someone could write a unix virus (and people have, look up the Morris worm young-uns) but they aren't going to go into all those porn sites that tell you to download celeb.exe because just about every person who downloads the file has Windows, and the exploit won't run there, duh. Windows is multi-user and a networking OS and was built to be secure (don't confuse Windows NT with Windows 9x). Enough for now, I guess.

Votes + Comments
wishful thinking

5. Logging in as Root - Yes, of course, 'Be careful' is the real answer. The 'Don't log in as root' thing is just to encourage people to do what they need to as a normal user as much as possible. Of course if you know what you're doing and are careful, there's no need to avoid logging in as root. I do on occasion, but still do things like compiling software etc. as a normal user. Also, most of the systems I have access to I log into via SSH (with SSH to root disabled), so for them I have to use sudo, but then I often use sudo -i to get a root shell. The other thing about sudo is that you can configure it only to run certain commands. This is, of course, its original purpose. If it is configured like that, then you can delegate jobs to people who should not have full root access. Of course doing this properly requires a lot of knowledge, because e.g. allowing someone to run 'sudo vi /etc/hosts' also allows them to shell out of vi and there's their root shell!

4. su is SuperUser - I agree it means 'substitute user', but this is a lame 'myth'.

3. *nix Systems Can't Get Viruses - Anyone who believes this is an idiot.

2. *nix Systems are More Secure - This is of course debatable and of course any badly maintained system is probably insecure. Part of this comes from the usual practice of users logging in to Windows as an Administrator, which they often have to do because of badly behaved 3rd party software. This was more a problem with older versions of Windows, of course.

1. You Never Have to Reboot - Anyone who says this and means it exactly and with no qualifications etc. is an idiot. I can't believe that anyone would believe that it is *never* necessary to reboot a Unix box. Of course you have to for certain types of hardware maintenance (depending on the type of hardware and exactly what is and is not hot swappable etc.) Of course you generally have to reboot for kernel upgrades (although there is the 'splice' stuff for Linux (can't remember the name exactly) but that's supposed to be for small patches and not large upgrades and I'm not sure I'd want to trust it anyway.)

I'm not so sure you 'should reboot on a regular basis' though, and zombies are definitely not one of the reasons! A zombie is a process that has exited, but has not been reaped by its parent. If you have too many zombies, it probably means the parent process is buggy and is not 'wait'ing on its children. Killing the parent process will cause the kernel to make init new parent of the zombies, and init will reap them. If this doesn't happen, either your init or your kernel is broken and you should speak to your vendor about an upgrade or a patch.

I'm not sure what you mean by a 'memory refresh'. I suppose your RAM might get horribly fragmented and need a reboot to fix it up, but how often that's a real problem I couldn't say.

Your anecdote about the Solaris server is very light on details. Why would the system administrators be afraid to patch it just because of the uptime? That doesn't make sense. And if that really was a problem, they could just reboot once before patching. If it was thrashing, fine, it may have needed more RAM. That doesn't mean 'thrashing' is the reason for the reboot. Just hardware maintentance, which you already mentioned.

'Once the system was patched and rebooted, there were lots of errors. Lots and lots of errors. Problems that had amassed over the last few years that, if taken one a time, could have been solved'

What does this mean? Yes, it's possible the system administrators were making changes to boot scripts or doing other things that would affect the boot process over the years, and of course any issues that resulted from this would not show up until a reboot. This just means they should have been more careful, tested their changes on another machine, etc. Rebooting regularly would not automatically fix these issues, but would of course have spread them out over the 5 years instead of them all happening at once, which I think is your point.

Without a proper description of all the issues it's very difficult to say what the right answer would have been, but decommissioning the box and getting a new one sounds extreme. Why not just reinstall the OS and restore the data from backups if it was so bad?

'The moral to the story is that responsible system administrators would have done their due diligence (and their job) and maintained that system appropriately.'

Yes, of course! And this has very little to do with rebooting!

'Yes, you do, in fact, need to reboot your *nix systems.'

Thank you for stating the blindingly obvious :)


I liked your article! Thanks.

When I set up a new linux system, I copy in a pre-made gui interface (icewm) to roots' account, login, startx, and then use the gui & cli together to get things done. It's so much quicker. I don't much like sudo; I prefer having a proper root WM & DE that has a red background with ROOT written all over it, for any intensive admin. I likely never use the account again, but it's there if I need to. Otherwise su in a cli does the job nicely - it has a nice feel of segregation about it.

I reboot, mostly, for kernel changes & when I need to physically clean the computer (once a week).

*nix / mac / windows & viri? ...whatever the reasons are, as a linux user, it works great for me!

su - I suppose, it can be interpreted, conversationally, in context, so... if you are using su to elevate your privileges then it can be correctly referred to as superuser, if you are using it to change user then it can be referred to as substitute user, etc.

Security --- travel by night & don't talk to strangers. ;)


jess912, this man really does not know what he is talking about. he needs to spend some real time learning GNU/Linux.



Well, the exact details are too lengthy for a short entry and it happened a few years ago so the details are a bit fuzzy. For some reason this system had remained up and unpatched for an extended period of time. I can't give a lot of details too because of the confidentiality of the work done on this at my client's site. Just realize that we had good SAs and Sun available to us as an enterprise customer to solve these issues.


Curiously, whilst the theory of a virus on *nix is possible... although to do any real damage it would need to be installed by root (otherwise it's pretty much limited to trashing /home/<username> and the respective OS X version there of). In practice, there aren't any actual OS X or *nix viruses in the wild. A few proof of concepts exist and have done for many years but nobody has caught them being used in the real world as of yet.

I had a much longer post typed but hit a hidden character limit. Look up rootkits yourselves.


Any machine left facing the internet without patching or proper firewalling, will, eventually be made use of by a 3rd party. That is what happened to khess's Sun box. Nobody is surprised and it reflects badly on your client more than it does Sun, BSD or *nix's security.


Here is one reason why not to log in as root. It prevents auditting. If all admin level users are forced to log in as themselves and the su or sudo, you have an audit trail of their actions. If you allow admins to log in as root, you have no accountability. The _action_ could have been taken by anyone. This is a procedural control and seperation of duties between accounts, not a specific barrier against mistakes. It is a simple matter to force users to sudo and su. Even if they can change the rules, there is an audit trail of their actions. The audit trail can be made safer by using a log server which is locked down with no access to any admins on log client.
Again seperation of duties.



No the Sun box had no Internet access. It was my co-workers' FreeBSD box that was compromised.



So you installed bad or incorrectly installed RAM in the Sun box and your friend is by your admitance an idiot. Again, neither are reflecting badly on the respective OS's.

Their owners however.... a different matter.


I don't think it was bad RAM...The Sun Tech would have done diags on it. And for the coworker, he wasn't an idiot, he was careless. He had just done some updates on his software and there was a vulnerability on one of the services he was using. Can't remember which but he got hacked.


The problem if you don't reboot is that you never know if your system is going to come back. The power is going to fail. You're going to be required to reboot for a system upgrade. A component will fail and you will need to reboot. Gamma rays will cause too many bit errors on your non-ECC memory and will panic the kernel.
Any of these things can happen concurrent with your wedding night, kids' birthdays, or your colonoscopy, and you get called in to fix that server you never rebooted because you were all high-and-mighty about not doing it.
The servers at my current job are never rebooted and they take pride in the fact that they leak memory and fail constantly. It's horrifyingly stupid.
99.999% availability does not have anything to do with rebooting. Systems that claim 99.999% availability and do not use a system like Heartbeat are lying.

Edited by Chainsman: n/a


5 . Logging in as Root

While surfing the net an playing with your computer as root, don't forget to open that nice executable email attachment named FunnyJoke.sh and try to see if it makes you laugh.

4. su is SuperUser / jejejeje comment and your dumb reply.

"That's published by Bell Labs...you know, the people who started Unix."
"Of course the C code you posted above predates that"

So.. MAYBE the code written by the programmer who wrote Unix itself, BEFORE the first release of Unix itself (and thus of ANY MAUNAL), that thus predates the manual you cite, written by the marketing/documentation people of the company that "marketed" Unix, is what the programmer really meant, while the rest is subsequent interpretations.

You say there is no super user, and get proved wrong (by your own admission: "the \"super-user\" AKA root user"). Even if interpreted your dumb way, the comment does prove that root is the super user

And you try to escape by saying:
"The comment is merely saying the "substitute user id" command is used to become the "super-user" AKA root user."

But the "substitute user id" definition didn't yet exist. As this code was written BEFORE the manual. This comment is the only documentation for that command at that stage. So you are wrong. The comment means "su (THE COMMAND, THIS COMMAND) is "become super-user". And you are wrong.

I couldn't care less, not a fan of super user, but you do seem to care and that's funny, as you're wrong.

Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.