pros and cons of using linux

I know you will say that every command has a man page, but the man pages are very often so terse and nondescriptive as to be useless. And then, trying to find the exact command to accomplish what you want to do can be amazingly difficult.

For example, I posted a question on a Linux forum that went something like this: "If I boot up with the ethernet cable not attached, I don't get an IP vended to me via DHCP. If I reconnect the cable, what command can I use to get an IP vended to me?"

I got a variety of answers, none of which were right. It wasn't until a couple of months later that someone responded with "pump". I tried it and it worked. Why couldn't the documentation for ifconfig at least have a pointer to "pump" as a useful command under dhcp? "Oh, because ifconfig is the manual way to do IP config." And that is my gripe! Getting from point A to point B in Linux assumes that you already know the way, so why document it. Pah!

Even using Google for "linux dhcp" was fruitless. It always discusses the dhcp.conf file, which assumes that I was connected to the network to begin with. It may mention "pump" in passing, but not in a way that describes what it does.

That is why it won't catch on with the general populace, unless a really user friendly GUI is pasted over the top (kinda like the old Win 3.1 days over DOS). The only way to learn the commands is to get a book and go through each one over and over. And then they may not work on the next flavor of Linux since they don't standardize.

Other than that :-) it is very powerful, interesting, and ...free!

Linux can be more difficult to set up than the equivillent Windows implementation. I have found that Linux has forced me to spend time peeking into its innards teaching me to understand the underlying technologies, standards etc.

With Windows, I had the attitude (rightly or wrongly) of point and click till it works right. With Linux, I don't trust *anything* unless I have understood it and set it up myself.

I believe the result is that I can secure, optimise and troubleshoot my Linux systems far better that what I could do with Windows.

the difference between a file system and a partition are often confusing to someone new to the *nix world and is NOT explained very well in most cases.

Definitions of each and the purpose of each BEFORE throwing the user into the install would save many from a lot of frustration of having to go back and re-install because they wanted a dual-boot system.

That and still calling a Directory, a Directory can also be confusing to people that have gotten beaten into saying the word "folder" instead.

I guess I tend to do things the "classic" way...never heard of pump. I even did a man pump (I bet that is a pr0n site) and I came up with zip.

Once I found out about it I was a little confused as to why you would use this over a more classic method...

Oh the man page:
http://www.rt.com/man/pump.8.html

Windows actually does include the necessity of filesystem choices, and has ever since it went to 32-bit. It just doesn't inform you of that. Often, the choice is to simply let the installer do whatever it wants, delegating thinking and making decisions to the programmers who created the installer.

Windows XP, for instance, is capable of using at least FAT32 and NTFS. It may also be capable of using the original 16-bit FAT (though I haven't checked). By the same token, you can make changes to the partitioning structure of the system if you choose, rather than accepting the default "one disk, one partition" setup. It's much more difficult for most people to sort out how to do such things in Windows than in Linux, often.

That doesn't change the fact that in Linux it's sometimes just not clear enough at all. Saying that it's usually somewhat more clear in Linux than in Windows (which doesn't make it clear: it just makes it hidden) is simply damning it with faint praise.

As a reformed programmer, I can assure you it is more fun to write code than documentation.

When you buy commercially developed software, the manufacturer usually has a staff of technical writers. These English majors get paid to write the manuals and .PDF files that are understandable by non-technical end-users. They usually work for the same company as the programmer, so they can consult with him and come close to getting the documentation details correct.

On the other hand, if I develop a program for myself, I rarely bother documenting how to use it. If I make it available to others, I'll provide brief instructions on how to use it, but I'm not going to write a manual for them. I'm certainly not going to pay someone else to write it.

"Real programmers don't document; the code speaks for itself." ;-)

In November 2003 I installed Linux on my office computers and laptop and have used it as my primary operating system ever since. I had previously played with RedHat since version 6 or so but never committed to using it as I had some of the same frustrations others have posted about.
But then I bought a copy of SUSE Linux Professional 9.0. It came on a DVD and 5 CD's. I put the CD in my Toshiba laptop and booted. A welcome screen came up and I answered a few (less than 5) questions about my intentions and what language I wanted and then the most amazing thing happened. It offered to resize my Windows XP partition and create a new partition for Linux. This function was unexpected (since I hadn't read the manual yet) but gave me the feeling that this Linux was different than what I had been exposed to before and I was right. I continued and then selected which packages to install and 2 hours or so later the installation completed and upon rebooting I had a fully functioning dual/boot system which I could use with either operating system. SUSE's YaST (Yet another Setup Tool) is very good at handling all system configuration both hardware and software and it has the same functions whether you run it from command line or GUI.
I have just recently also used a distribution from TechAlign based on Mepis which boots from a CD and loads a fully functioning system which you can then install to your hard disk. The thing about this distribution is that except for a system with an Intel 925 chipset it correctly identified all the hardware in my systems and loaded with fully functioning multimedia (audio, video, and dvd decoders already functioning) and internet capabilities. It is currently dual booting with Windows XP Media Center on a demo computer in my display area.
Novell Linux Small Business Server 9 is also running here and coexists with a Netware Small Business Server. Since both run eDirectory network management is easy from either Windows or Linux workstations. This product is sold commercially for $475 for 5 users. Unlike other server products this price includes Novell Linux Desktop 9 for 5 machines as well. Server + Desktop for the same price. I know you could do a free distro server and desktops but for me the Novell product with eDirectory and Groupwise e-mail make it a bargrain.
One thing that I have learned is that what is easy is what you already know. Anything that is different than what you are accustomed to will require you to learn something new. Because my experience with Mac's is small I would rate them hard to use. Of course they aren't I just am not accustomed to the way things are laid out and what menus contain what items.
In my business I help customers with systems running DOS, Netware, Windows, Linux and occasional Macs. In the past a few System 36/38 and OS/400 and they all require that you learn the syntax of whatever commands that you need. And they all had terrible documentation.
The first computer fundamentals class that I taught that was a familiar gripe by students.. Computer documentation is hard to understand.
I have never used a computer or operating system that didn't make me want to pull my hair out sometimes but after a year and a half with linux I am satisfied that it is the best system that I have used so far and one of the easiest.

web based apps?
I don't, I code to w3c standards for the output.
if ie can't render the standards that is ms's problem.
and the site will state that the site is designed to work with standards compliant browsers, if it doesn't work right then try not using ie.

you can create a /home partition rather than just a /home directory.

Is this the point?

c:\program files = /usr & /opt+ not /bin ( user programs )
/bin = c:\windows\command ( dos / console commands )

+ /opt is the reserved space ofr commercial apps, not often actually used but that's it's intended use.

That is exactly the kind of information that is invaluable to us poor Windows migrants, that are struggling to get to know Linux.

It is this basic sort of information, that is SO hard to come by. It appears that most of the books (I have read) and all the available help, assumes you know these basics. NOT TRUE.

The best you are likely to get, is a snippet that says, the application places files in /bin for example. Yes, and then what?

However enthusiastic I may be about Linux, I and others will rapidly become deluded, if you can't even find your way to a file, or it becomes a nightmare trying to install an application via the command line.

The times (now) I have tried to install something and instead of the application installing, I get some cryptic message that I can't make head nor tail of, with the installation failing. Or there is some obscure library missing; why not supply the library with the application?

Yes, Linux is an exceptional system, but user friendly in administration terms - could do better!

Jaqui: Actually, the way Windows is put together, there's little rhyme and reason regarding where stuff goes. Program files is where the bulk of executables go, including stuff that's installed as part of the OS. You're correct that some goes in c:\Windows\Command, depending on the Windows version, but some goes in c:\Program Files as well. Meanwhile, c:\Program Files also houses stuff installed by choice from the OS install CD, and stuff installed from vendor CDs and other autoinstallers. Stuff you simply copy into place and otherwise choose the location of ends up in just whatever location the user decides on with no "standard" guidance, although many get stuck in c:\Program Files along with the rest of it.

Meanwhile, the Linux Filesystem Hierarchy Standard sets out specific guidelines for where everything should go, making it much easier for the end user to figure out what's going on with location of files when using an FHS-compliant distribution. Unfortunately, that leaves users of FHS-noncompliant distros like Fedora/RHEL out in the cold. C'est la vie.

lastchip: This is one of those cases of (lack of) familiarity with an OS creating an appearance of difficulty. People are used to the locations of things in Windows, so they think it's difficult to find stuff in Linux. There's an effort to standardize the locations of things within the filesystem in Linux distributions known as the Filesystem Hierarchy Standard, though different distributions are compliant with its standards to differing degrees. If you want something very compliant, I know Debian is quite compliant. If you want a distro that just follows its own rules, and changes them when the whim strikes the way Windows does, look into Fedora or Red Hat Enterprise Linux. Sad but true. Even so, much of what's in the Filesystem Hierarchy Standard is applicable to Fedora/RHEL, though there will be surprising instances where it's not.

The current FHS specification (2.3) can be found at this URL:
http://www.pathname.com/fhs/pub/fhs-2.3.html

Generally, anything with bin in the path is for executable programs. The term "bin" is short for "binary" and, if you're not already aware of this, the term "binary" is used in the unix world to refer to machine-code compiled (typically executable) files. Thus, when someone says "binaries", they typically mean "compiled, executable program files".

Generally, /bin is core, system-installed user binaries, /usr/bin is for optional system-installed user binaries, and /usr/local/bin is for user binaries installed by the system administrator. While the FHS doesn't specify this, it's typical in many instances for users who install binaries specific to their user accounts to put them in /home/[username]/bin just to keep things neat, tidy, and intuitive.

Anything with sbin instead of bin is for binaries used by the system, rather than by users. Among other things, this keeps the number of files to look at in bin directories to a manageable number. Windows keeps some system binaries in c:\Windows (or equivalent), typically in some subdirectory of that, though some are also in c:\Program Files, and I believe some end up in c:\ also. It's been a little while since I've tried to actually keep track of where Windows sticks everything.

Hope that helps.

Another standard for Linux design, which specifies use of the FHS, is the Linux Standard Base (LSB). This is less likely to be of direct interest to new Linux users, but more likely to be of interest to people trying to port applications to Linux, since placement of binaries and configuration files can be achieved by automated installations through the use of environment variables, and the filesystem's virtual structure need not be known in advance in most cases.

http://www.linuxbase.org

and not saying it is something that doesn't work VERY well.

I am just saying MOST people don't know that a FILE SYSTEM is NOT the same as a PARTITION AND is not the same as a DIRECTORY.

Goes back to traditional UNIX training I guess to have worked with this?

debian, slack and lfs seem to be the only distros that try to follow the fsh closely.

even third party, commercial apps, like open office or star office don't pay attention to it completely, though open office is better than most.
the fhs sets /opt as the place for after market apps, most use the /usr filesystem.

jd,

only when people haven't really spent any time with *xish systems. by the time they are comfortable building a debian system they should understand the differences. ~G~
but the distros that are easiest to install for newbies don't really teach the details very well do they. only enough to become comfortable with using the *x systems.

The idea of filesystems (ext3, et cetera) vs. partitions had already been addressed and discarded by you, I think. That, or you've been very, VERY damned unclear.

I think I vote "both".

apotheon, I almost wrote what you just said when I put together my "different levels of help" post. In fact I did write that but then I almost completely rewrote that post before I submitted it.

I think you're right. jdclyde appears to be alternating between two subjects.

In any case I think that the subject has been thoroughly explored by this point.

Linux is free.

Nothing more need be said.

Linux Pro: So many options in the implementation of "standard" system services.
Linux Con: So many options in the implementation of "standard" system services.
Explanation: In a single vendor (M$) approach to system services you are locked in to their interpretation of how it should be implemented, but the multi-vendor/developer approach leads to a more flexable but less manageable infrastructure implementation and support base.

Linux Pro: All processes, configuration and administration task can be run without the overhead of supporting a everything for everyone GUI interface.
Linux Con: Most distributions include by default a GUI interface or several to support all processes, configuratoin and administration task.
Explanation: One of the factors leading to the stability and efficiency of Linux systems is that the please all GUI interface is unnecessary. Unfortunately most developers, administrators and support staff are now trained around the GUI alone. Let there be one DNS/hosts change and watch the xwin environment go to hell.

Linux Pro: Free code for just about anything!
Linux Con: You get what you paid for!
Explanation: Most of the code is good, but the after sales support for the product is catch as catch can. Try to pitch a new Linux application written by Bob, or Sam to a financial institution! Long term vendor support is absolutely necessary in order to pass audit. And if you get that you are back to paying the $$$ and usually can only be purchaced on a overpriced HW platform that is NOT scalable without going through a single vendor anyway.

I could go on and on.... M$, AIX, Linux, BSD, Solaris, etc...About the only OS I've not gotten my grubby paws on is OS-X, but don't have the overpriced system to run it on.

Pro Linux:
1) Preemptive Multitasking. Linux Kernel never gives up total to control to anything. The timeslice system always breaks into any application, even the REALTIME kernel reserves this right.

2) Memory control. Each application gets it's own memory map; it cannot even access a page belonging to another application. Furthermore, it will not be allowed to write to a page not allocated specifically for it.

3) Source code availiable for everything. It may not seem like much, but trying to figure out what's going to happen is a lot easier with the source code. And having source when a security bug report cross your desk allows you to evaluate the difficulty of fixing it, the full impact, and the likelihood of it impacting your organization immediately, rather than relying on someone else's staff.

4) File system security. You want a full control/full logging file system? Linux can do that. No Read Up/No Write Down security levels? Sure. You decide on a file system for security, you can implement it.

5) $0 Licensing costs. You pay nothing for the software. You pay for the services of support and updates.

Cons:
1) Many Applications not availiable. But, most application types are. Do you really need to use that exact application, which is only out for Windows?

I much prefer Linux (usually Xandros OCE 2.01) for the Net and almost everything else. However, I dislike the lack of dialup Linux support from the major ISP players, who have their proprietary portal software. The lack of PNP Linux DVD capability is inane.
Going through contortions to get a program to run is for masochists and CP/M diehards. This IS the 21st century, after all (the linux flavor of the week notwithstanding).
I deal with the average end user, who feels blessed by Redmond when his Windows machine boots up most of the time. The MS fix of buying a new version of their bugware, may have made Bill Gates (aka the Vole)the worlds richest person, but money isn't everything.
A trouble-free, secure operating system with all the bells and whistles might just be the geeks Holy Grail. Unfortunately, Linux isn't there yet.

It's a [b]LOT[/b] clunky! You need a manpage to be able to use info pages!

I'll not give up on manpages as long as info pages are so byzantine and obscure in operation. The point of help utilities like this is to be able to offer help to those who don't already know how to do things. Since info requires a nigh-comprehensive knowledge of navigating info pages to be able to use the basic functionality that you can get out of man with just arrow keys, it seems there are a few kinks to work out.

Pros- More affordable (If you know what you are doing)
More Flexible (if that matters to you)

Cons - Higher learning curve
Variety of distro's means you probably won't be able to find everything you want in one place.

More flexible means more you can screw up.

Yeah, I'm not a fan of info pages. I've perforce become familiar with how they work, especially since the GNU developers for some asinine reason do their best to make their manpages almost useless and use them primarily to direct users to their info pages ('cause, y'know, pushing their pet documentation format is more important than simply providing good, useful documentation). That doesn't change the fact that it takes six times as long to find information in an info page than in a manpage (randomly generated ratio, of course).

As for rendering info pages in HTML format: there might be just such a set of HTML info page adaptations on the web (or in the package archives) for your preferred distro. You might want to look into that. Also, if you're really interested in such a thing, you could always just write some Perl scripts to dynamically produce HTML from info pages on your local system, then make the scripts available as an open source project.

Personally, I'm more inclined to write scripts that present info page content in a manpage format. The simpler man interface provides for far more flexible use of the documentation.

"[i]in a well maintained windows environment the user turns it on in the morning, does their work and turns it off at night[/i]"

It's exactly the same in a well maintained Linux environment, minus the necessity of turning the machine on and off. When someone like jmgarvin describes a problem with something like losing the DHCP client's functionality, that's because, like me, he knows enough to be dangerous (and also enough to fix it when he does something inadvisable), and knows enough to avoid that danger in a production environment (that fabled "well maintained" environment of which we speak).

"[i]bury the underpinnings behind a familiar interface and have full look alike and work alike tools[/i]"

I'm guessing you haven't taken a look at Lycoris, Xandros, or Linspire lately (if ever).

I've made the attempt, but part of the problem is the depth of the info pages. Sometimes is is hard to parse out what is a link to nowhere and what is a good link.

Info COULD be good, but it needs some house cleaning and a better UI.

hhhmmmmmmm...I wonder...Time to start working on a webmin plugin for info and man pages ;-)

my lfs choice has only tools that I build into it.
I don't put huge amount of gui tools into it.

basic gui functionality only wanted here.

I like my console only interface.

though, if the person we are replying to can only start the xserver by switching runlevels..... ;)

after all, that simple : startx works fine for me, no having to get to runlevel 5 to use a gui.

Yeah, it'd be nice if there was more interconnectedness between manpages. More to the point, I'd like to see more references to other manpages in the "SEE ALSO" section of manpages in general. That tends to get overlooked too much by people who write manpages.

A simple means of jumping to another manpage from within a given manpage would be nice, too -- not links so much as simply an easy command functionality that allows you to switch to a different manpage of your choice without having to exit and re-enter the man interface. This would allow, for instance, the user to use the information in the "SEE ALSO" section without having to slot the name and page number of another manpage into short-term memory, mentally repeating it like a mantra, hoping to get "man [foo]" typed in at the CLI before forgetting the desired manpage's name.

Unfortunately, the "linking" behavior of info pages creates a problem on the other side of things, in that it fosters too-complex interconnectedness between pages.

Bah, humbug.

Try typing info:bash or ##bash into Konqueror's address bar.

Then, for comparison, try man:bash or #bash.

If you want to roll your own you could try info2html.