Slashdot Mirror


User: md_seymour

md_seymour's activity in the archive.

Stories
0
Comments
1
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 1

  1. debunking "Linux Vs. Windows VIruses" on Viruses and Market Dominance - Myth or Fact? · · Score: 2, Insightful

    Much of this article represents widely held ideas about modern Unix-like OSes that are either false now, will change in the near future, or are based on 20 year-old ideas about Unix. These seem to stem from the idea that the *nix OS will be installed on a large, multi-user server running many small limited-function tools such as text-based e-mail clients. This is changing. Many of these operating systems are installed on single-user desktops running large, graphical applications such as Evolution and KMail which attempt to be very user friendly.

    Here are the arguments from the article:

    "a Linux user would have to read the email, save the attachment, give the attachment executable permissions, and then run the executable."

    The default behavior of *nix mail clients is to save files if instructed, and not executable. However, There isn't anything inherent to *nix which dictates this. A mail client that claims to be more user friendly can also save a file and run it automatically as well. There just hasn't been a popular one in use yet.

    "Further, due to the strong separation between normal users and the privileged root user, our Linux user would have to be running as root to really do any damage to the system. He could damage his /home directory, but that's about it."

    The configuration that Linux has been trying to increase its numbers with, and OS X's main configuration is the single user desktop machine with no automatic backups. To the home user, blowing away /home/foo is the single most disastrous thing that can happen.

    "Windows XP, supposed Microsoft's most secure desktop operating system, automatically makes the first named user of the system an Administrator, with the power to do anything he wants to the computer. ... On a Windows system, programs installed by a non-Administrative user can still add DLLs and other system files that can be run at a level of permission that damages the system itself."

    Ok, I agree with these points. However, as Linux penetrates the home user market, the limited capabilities of the regular user will be increased. Remember Lindows? I believe (all) user(s) run as root. The author address Lindows near the end of the article, but he dismisses it as an exception rather than the rule. Ask yourself *why* the developers chose this route. It's because they want more home user/desktop penetration. Expect more of these types of decisions to be made in the future.

    "Even worse, the collection of files on a Windows system - the operating system, the applications, and the user data - can't be kept apart from each other. Things are intermingled to a degree that makes it unlikely that they will ever be satisfactorily sorted out in any sensibly secure fashion."

    Ever look at /usr/lib lately? Over 1500 files in mine at last count, including very few subdirectories and lots of symbolic links. The same for /usr/bin. Or is it /lib? Or /usr/local/lib? Or is it /usr/local/bin? Besides for some accepted practices, most applications dump their libraries in /usr/lib and executables in /usr/bin, but without any organization.

    "Linux runs on many architectures, not just Intel, and there are many versions of Linux, many packaging systems, and many shells. But most obvious to the end user, Linux mail clients and address books are far from standardized."

    Again, as Linux becomes more popular with home users, one or two mail clients (depending on if one or two desktop environments will survive in 5 years) could possibly dominate the market, on possibly one type of architecture, the x86. As well, Linux prides itself on supporting standards, across different applications.

    "Microsoft continually links together its software, often not for technical reasons, but instead for marketing or business development reasons"

    Here I will agree with the author,