Which Is Better: Linux/Unix Or Windows? ...And Why Does It Matter?

Hey There,

Today, I'm posting an interesting read I found from about a year ago on Education.ZDnet.com. Again, I'm using Monday to prime the pump for a follow up post, because I'd like to get reader input on the subject in question.

The article I'm referring to is at the bottom of this post (with one of the more - at least to me - incomprehsible Pro-Windows arguments I've ever read - although it could just as well have been a pro-Unix/Linux argument if it were written slightly differently).

I've got my own opinions on this subject, but I'm interested to know yours: If you prefer Linux or Unix (which I'm assuming most of our readers do), do you see any reason to continually engage in online-battle vs. the opposing army of Windows users?

Seriously; let me know what you think. Then I'll let you know what I think. ..well, I'll you know what I think, regardless ;) I'm pro-Unix/Linux, but I'll save the rest of it for the follow-up.

Enjoy the argument. Try not to judge the arguers and be objective. Then consider if any of this sort of behaviour is time well spent, a complete waste, enjoyable social interaction, or any combination thereof, etc.

The article, itself, isn't brand new, but then neither is this whole back-and-forth. The original article can be found at ZDnet and is entitled "Why Linux Will Not Displace Windows." I'm looking forward to reading your opinions on this :)

Cheers,

---

THE ONE RESPONSE TO THE ARTICLE BELOW THAT I FOUND MOST INTERESTING... SO TO SPEAK

---

You are kidding arent you ?

Are you saying that this linux can run on a computer without windows underneath it, at all ? As in, without a boot disk, without any drivers, and without any services ?

That sounds preposterous to me.

If it were true (and I doubt it), then companies would be selling computers without a windows. This clearly is not happening, so there must be some error in your calculations. I hope you realise that windows is more than just Office ? Its a whole system that runs the computer from start to finish, and that is a very difficult thing to acheive. A lot of people dont realise this.

Microsoft just spent $9 billion and many years to create Vista, so it does not sound reasonable that some new alternative could just snap into existence overnight like that. It would take billions of dollars and a massive effort to achieve. IBM tried, and spent a huge amount of money developing OS/2 but could never keep up with Windows. Apple tried to create their own system for years, but finally gave up recently and moved to Intel and Microsoft.

Its just not possible that a freeware like the Linux could be extended to the point where it runs the entire computer fron start to finish, without using some of the more critical parts of windows. Not possible.

I think you need to re-examine your assumptions.

---

THE ORIGINAL ARTICLE

---

Why Linux will not displace Windows

I firmly believe that, all else being equal, the differences between the Windows desktop, the Macintosh desktop, and the Linux desktop are negligible.  With the proper applications, all three platforms will be capable of providing a satisfactory experience for any user.  All three platforms have both free and commercial products available for personal productivity, web browsing, and basic multimedia.  Yet, Windows dominates.  Why?  After all …

• Apple was first to mass market a fully-functional GUI (though invented at Xerox PARC). 


• Apple was the first to pre-install their operating system onto their workstations.


• Apple was first to recognize the value of personal computing to education.

Despite this, Apple's presence does not reach even ten percent of the World's desktops – in Education IT or in the mass market.  The reasons are many but up-front costs certainly play a role.  Nevertheless, Apple is not the subject of this article … I want to talk about Linux! 

In a feature-rich desktop configuration, Linux runs on the same hardware as Windows with comparable performance.  The 'cost' of Linux ranges anywhere from ZERO dollars (for the geeks among us) to $299 per seat (for a one-year RHEL-WS subscription — with 12×5 technical support and 4-hour response.)  For this, the user has complete control over their system configuration.  Yet, with its fixed-price, fixed support, fixed-configuration model, Windows still dominates.  Why?

I just finished reading Vista? No thanks, school says, converts Windows boxes to Linux and I was struck by a couple of things.  Looking to reduce annual costs, the Windsor, CA School District has adopted a variety of solutions centered around workstations running SUSE Linux and Wyse Linux thin-client terminals.  (They use a few Windows and Macintosh workstations but apparently not many.)  Quoting Heather Carver, the district's IT administrator:

"One key to all this is that we're using Citrix (as the bridge) to run Windows apps on thin-client terminals — which the adults are most used to — on the new SUSE Linux 10.1 servers," Carver told DesktopLinux.com. "The kids, well, they adjust to new operating systems and applications very quickly, so a changeover to Linux is no big deal."

Her conclusions are not at all surprising but she ignores another reason why Citrix is needed:

• most educational software is ported to Windows (and/or Macintosh), not Linux


• the number of Windows-based titles accompanying textbooks is growing

In short, the absence of high-performance commercial desktop software hurts Linux.  Of course, application availability is a 'chicken or the egg' kind of problem.  Without a critical mass of desktop Linux workstations in people's homes or on their desks at work, there is no incentive to write (or even to port) specialized applications for/to Linux. 

This argument sounds fine until you realize that between OpenOffice and a number of Web browsers for Linux, and a variety of free (or nearly free) applications Linux truly can meet 90% of the needs of those folks who buy Windows today instead of buying Linux.  It's the other 10% though that makes the difference.  (For instance, neither Quicken or TurboTax have Linux ports and neither does iTunes – those are not 'showstoppers' for Education IT but they certainly are for me as a consumer.)

Last week, David Berlind posed a question about the potential threat to Microsoft of the laptop being developed by the OLPC (One Laptop per Child) foundation — targeting school children in the developing world.  (See Image Gallery: Will Negroponte’s One Laptop Per Child be a problem for Microsoft?)  David's point is that this 'little laptop that could' will run a ROM-based Linux configuration.  The question applies equally well to the schoolchildren of Windsor, CA who will be running Linux on thin clients. 

The rationale, of course, is that whatever you were exposed to in school, you are likely going to want when you get out of school.  This is certainly the rationale that Microsoft uses when they grant steep discounts to K-12 public schools all over America — and when they establish enterprise license agreements with large research universities. 

So will the strategy work?  Will these school children clamor for Linux when they get to college?  Will they buy a Linux computer when they graduate from college?  Well, it remains to be seen but, unless Linux vendors get a clue, and soon, I think not. 

Why not? 

Because for Linux, its greatest asset in the machine room — the flexibility of its configuration — is it's greatest liability in the consumer space.  Consumers don't want or need to worry about configuring their computers — nor would most of them even know how. 

The consumer wants a computer which is functional and inexpensive (leaving Macintosh out of the picture for many.)  They have a limited number of needs — write a document, prepare a spreadsheet, send an e-mail, listen to music, share photos.  But, they also have limited knowledge.

If a consumer could walk into their favorite electronics retailer and see a computer running desktop SUSE Linux (or any Linux distribution, for that matter) sitting next to an equally-robust Windows machine at the same price point, and if they could take it home and plug it in a just use it, like they can with Windows, there is no reason to believe that Linux would not be as well received as Windows. 

Unfortunately, this is not a choice most people have.  The fault does not lie with Microsoft.  Nor with Dell or its competitors.  The fault lies squarely at the feet of Linux vendors who do not wish to compete against Microsoft for the commodity desktop workstation market. 

Until they figure out that they MUST compete for the consumer desktop to make a serious dent in Microsoft's dominance of the desktop, they won't make a dent – and no amount of wishing will make it so.

It doesn't matter how great that OLPC laptop turns out to be, or how much those K-12 kids like those Linux clients if they (or their parents) cannot go to the box-store down the street and buy the computer of their choice with Linux pre-installed.   

---

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Dealing With "Argument list too long" Errors on Linux and Unix

Hey There,

Here's a question that gets asked a lot (and, consequently, answered a lot ;) on the boards. How do you go about dealing with a situation in which you're trying to take care of some business on your Linux or Unix box and you get stopped with the "Argument list too long" error message? It's probably happened to all of us at some point, but it's fairly simple to avoid, and in more than one way. I'm almost positive, even though I know this stuff, that I'll get that error message again at some point in the future. My mind is a terrible thing ;)

The way I try to keep on top of avoiding that error (which, admittedly, isn't all that terrible, assuming its not a predicating factor in a script - like, you don't have any action is your script that might do something destructive if you don't check for errors) is a basic two-prong approach. First, I'll try to figure out what kind of limitations my system can stand. Secondly, I try to stick to some basic methods that guarantee I won't run into the issue no matter what my system's maximum argument length is. Of course, the second part obviates the first part, but I'm a curious guy (take that whatever way you want ;)

1. How can you figure out your systems command line argument length limitations?

The good news is that there a number of ways (and, most probably, much more than I'm going to list here today):

On almost all Unix and Linux systems you can use getconf to find out the answer very simply, like so (all examples today from OpenBSD 4.4-stable):

host # getconf ARG_MAX
262144

RedHat, SUSE, and BSD Linux (just to name a few) also support figuring this out using the sysctl command (for a more in-depth look at this command, check out our old post on using sysctl to work with kernel tunables on Linux:

host # sysctl kern.argmax
kern.argmax=262144

2. How can you avoid ever getting this error in the first place (not to be used as a substitute for doing error checking in your scripts to "make doubly sure" :)

This boils down to, very basically, using three methods: find, xargs or using your shell's basic looping constructs.

For the purposes of all of our examples below we'll assume that you've done something like:

host # ls *

in a directory, with 564,321 files in it, and have received the titular error.

xargs and find work because, used properly, they can reduce that huge list of file names to 564,321 separate lists of one filename each (that's putting it a little simply, but I'm trying to paint a picture here. And, believe me, painting is a lot harder to do while you're typing than it looks ;)

The find command can be used with the -exec option to iterate through the elements of your ls output, like so:

host # find /that/directory -exec ls {} \;

The xargs command will pretty much do the same thing. Some common wisdom (which doesn't work) is to do this:

host # echo /that/directory/*|xargs ls

however this will still give you the error, unless your version of echo can subvert the OS globbing rules and bypass the ARG_MAX without error.

The only real reason to use xargs to get around this issue is if you run into a situation more complicated than find's -exec flag can deal with. This situation doesn't apply, in that respect, so the following solution is, admittedly redundant and overcomplicated:

find /that/directory|xargs ls

Thirdly, you can use shell while looping to get around the error, again using find to make sure you don't get dinged by the maximum argument length error:

find /that/directory|while read x
do
 ls $x
done

Yee-hah :)

Of course, this discourse has been limited to the basics of the shell and one particular situation. If you use Perl, tcl or any other language (under any number of situations) your options will multiply. As with anything else in Linux or Unix, the possible solutions are, to a large degree, limited only to your imagination.

With these little fires lit, go on out there and (to use a dangerous colloquialism) "burn that mother down" ;)

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Shell Special Variables In Bash

Hello again,

Today, we're going to take a look at the Bash shell (for Linux or Unix) and go over some of (I find) the most useful aspects of it. I could be talking about quite a lot of things, actually. It's hard to say what I really like the "best" about anything, but the built in special variables in Bash come in handy an awful lot (Especially if you get stuck in the shell on a crashing system or have to access the network under equally hopeless conditions).

Today, we're going to run down these very basic variables, one by one. And, the reason that they're called "special" isn't an indication of their relative value. These variables are "special" because they can only be referenced and never directly assigned values to :)

1. * : The * variable expands to all the parameters on a command line. Since we're talking about built in variables today, I don't mean *, like in "ls *", but * as in "echo $*", which produces nothing. However if there are other parameters on the command line, expanding this variable equals all of the command line parameters, like $1, $2, $3, etc. If $* is surrounded by quotes ("$*"), it equals all of the parameters as one value, separated by the default field separator (IFS - usually a space, tab or newline), like "$1 $2 $3"

2. @ : The @ variable expands the same as the * variable when called without quotes as $@. When called between double quotes, as "$@", it expands into all the command line parameters, but each parameter is separate (rather than all together in one giant double quoted string, separated by spaces, as with "$*"), like "$1", "$2", "$3", etc.

3. # : The # variable expands to the number of parameters on a line. It's most often used to check to see if the proper amount of arguments have been passed to a script. For example, this would show how the $# variable could be used to test that a script is being called with only 2 arguments:

if [ $# -ne 2 ]
then
 echo "Usage: $0 arg1 arg2.  Quitting"
 exit
fi

4. ? : The ? variable expands ( as $? ) to the return code (or errno value) of the last executed command. In a pipe-chain, it equals the return code of the last executed command in the chain.

5. - : The - variable expands to the current shell's options. For instance, if you where logged into a shell and executed "echo $-", you'd probably see something similar to this:

host # echo $-
himBH

Which (of course ;) would mean that the shell had been invoked with the -i (forces the shell to interactive mode, so it reads the .bashrc when it starts), -h (remembers where commands are when they get looked up), -m (enables job control, so you can run background processes), -B (enables brace expansion in the shell whereby, for instance, "file{a,b}" would equal "filea fileb") and -H (enables ! character history substitution) flags.

6. $ : The $ variable expands to the process ID of the shell, or subshell (as happens when a script is executed, for instance), in which it's invoked (as $$). It's generally used to determine the process ID of a shell in programming and it should be noted that, if it's used within a subshell that is generated with parentheses (e.g. ($$)), it will actually retain the process ID of the parent shell, rather than the subshell.

7. ! : The ! variable (which you might remember from your options list when checking $-) expands to the process ID of the last run background command. This is different than $?, which reports on the return code of the last run command. For instance, this is one way to demonstrate using $!:

host # echo $! <--- No value because we have no jobs running in the background
host # sleep 200000 &
[1] 23902
host # echo $!
23902

8. 0 : $0 expands to the name of the shell you're in, or the shell script that it's being called from. It's generally found in usage messages, like in example 3 in the Usage message from the test against $#'s value. From within a script called blackhat.sh,

"Usage: $0 arg1 arg2. Exiting."

would print something like:

"Usage: ./blackhat.sh arg1 arg2. Exiting."

In certain circumstances it can resolve, or expand, to the first argument after the string set to execute when a shell is invoked with the "-c" option, or it can be set to the file name used to invoke Bash, if Bash is called by another name (like "rbash").

9. _ : The _ variable is set to the absolute (not relative) file name of your shell when you start it up (e.g. $_ = /bin/bash) or the script being executed if it's passed in an argument list when the shell is invoked. After that, it always expands to the value of the last command executed, or argument typed. For instance:

host # vmstat 1 1
 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr m1 m1 m1 m1   in   sy   cs us sy id
 0 0 0 37857184 2413576 16 152 0 0 0  0  0  0  1  1  0 1204  996  483  1  2 97
host # echo $_
1

As a side note, when you're using /bin/mail, the $_ variable is equal to the mail file you're checking.

And that's it, as far as I know (The basic ones, anyway ;)

Hopefully being aware of these Bash built in variables, and knowing what they all do and mean, will help you out or, at the very least, make your shell scripting easier and/or more productive in the future :)

Best wishes,

, Mike

linux unix internet technology