Adventures in Linux

SuSe and I don't get along very well, so what I'm telling you is biased, but drop SuSe and go with Fedora Core 4 (http://fedora.redhat.com). It is 4 CDs of goodness and will probably work a little better with your KVM and NIC.

Plus, if you have issues, I can really help you get them fixed.

If you want to game in Linux, check out http://www.transgaming.com for a nice way to plays Windows games in Linux.

You can also check my blog for thoughts and Linux setup...

I've had mouse problems similar to yours. I have a KVM switch and a Linux and Windows computer. Sometimes if I.m moving the mouse at the same time I'm switching between computers the mouse on the Linux box goes bonkers. If I switch to the Linux box and wait a second before moving the mouse I don't ever have any issues.

PS - Your networking issue: When you select network adapter in YaST it probes the settings. IF you changes anything, such as from static Ip to DHCP addressing, it resets the card and looks for an IP address. You can check your card setting in Linux (and Unix) with ifconfig.

Plug for SUSE. If you don't know much about Linux stay away from Fedora, it's not very intuitive and doesn't have anything like YaST to ease you along.

I noticed you and Jimbo used that word? Is it similar or same as plug-in? When you mean BASH shell...is that same as KDE that is with SUSE? Uh...I should really get a book...lol. Thanks for the info..

I don't know if its just SUSE or Linux as a whole but when I put in the installation CD and tried to reinstall the mouse went kablooey. As soon as it starts with "probing mouse" then the KVM Switchbox light starts flickering and continues to flicker and the mouse works but it is nonusable meaning it flies all over the place which indicates a power issue. I tried installation with ACPI = OFF and its the same thing. The keyboard however works fine.

I also plugged in the mouse using the USB to PS/2 adapter into the PS/2 port and the movement is very jumpy and not smooth but mouse is usable.

Then I plugged in the mouse directly into the USB port and everything is OK! It loves USB.

So now there are 3 variables I haven't tested yet...and I won't be able to for a while.

Will this happen with a different more industry standard switchbox (this thing is custom made for my company and I borrowed it for testing purposes)?

Will Windows do the same thing during its installation? We already know it works post installation.

Would a pure PS/2 mouse work?

So now after I install Linux again I will plug the mouse back into the KVM switch to see if the problem repeats.

in the system configuration tools that suse has in the gui ( easier this way )
specify either usb mouse, with the correct button / wheel config, or ps2 with the correct button / wheel config.

most distro's are defaulting to any usb / ps2 mouse.
which, I have found to be a problem with either connection.

by specifying the mouse type it loads the specific device dataset needed, instead of a generic any mouse set.

with the kvm, you are most likely using the ps2 port in the system to connect, so ps2 would probably be better.

There are disticnt differences between some distros, even when they use the same kernel version.

some distros choose to use the scsi interface for thier module hot-plug stuff, others use the pcmcmia interface.
( this also affects the usb and hot-plug of devices, automount... )

SuSe uses the scsi interface.
( I know this because thier installer locks up at loading it on my non scsi friendly bios )

functionally, no real difference, but a distinct difference if your bios does not support scsi interface. :)

Sun's Solaris has a buggy uchi-usb driver, it locks up on me.
( yet no other os locks up on loading the uhci module )

I've been using SuSE for several years. It is currently the distro that I have running on my home/test machines. I will unfortunately be repeating some of what others have said in order to provide a complete answer. :-)

I only tried using a USB mouse and keyboard once. I had a world of problems. I've never tried using a KVM switch with Linux. I have also tried putting a PS/2 adapter on the USB keyboard and mouse. That didn't work at all. I would get a strictly PS/2 keyboard and mouse to try on the Linux machine. As others have already said, once the PS/2 mouse and keyboard are connected then power cycle the machine, use YaST to check the keyboard and mouse type, then power cycle the machine again. I've never had trouble with generic PS/2 keyboard and mice. Cheap keyboards seem to break. I don't blame Linux for that though. :-)

As jmgarvin has said and as I've read elsewhere the Red Hat Fedora Core distribution does have a GUI system administration tool. I haven't used Red Hat recently so I'm not familiar with their recent developments.

My understanding is that Red Hat is the #1 most popular distro and SuSE is the #2 most popular distro. I find that surprising because you always hear people talking about Debian.

In favor of SuSE I'll say that the YaST software makes a lot of the difficult details easy. In many cases you configure some component in YaST without knowing what files are being changed and without having to learn the syntax of those files. That's a big big help when it comes to TCP/IP. Setting up networking in Unix/Linux by hand is a real bear. There are so many files in different places each with different syntax that it would discourage anyone. YaST makes configuring the network easy.

So it seems like SuSE and Red Hat both have good GUI system administration software.

Additionally all of the big distros (Red Hat, SuSE, and Debian), have excellent patch software. Each of those distros does a great job of keeping patches current with CERT vulnerability discoveries. I run the patch software on my SuSE machines twice a week. You can configure it to run automatically.

Another great thing about SuSE is that it automatically configures your firewall to drop all unsolicited inbound connect requests. That means that you can safely connect to the Internet as soon as the software is installed and configured.

One bad thing about SuSE is that the multimedia software is broken by design. I recently found out how to fix it and I fixed the multimedia software on one of my SuSE machines. I can give you pointers when you reach that point. Don't worry if you put a commercial DVD movie into your DVD drive and can't watch the movie. It can be fixed.

So as long as you've already got the SuSE installed you may as well stay with it. It's popular. It's mature. It can make some difficult tasks easier with YaST.

I'll be getting that as soon as it comes out! I can't wait!

http://www.kb.cert.org/vuls/id/943633

You are fine. FC4 used the 2.6.11 kernel, so no issue there.

If you want to get an idea of what (most) end users are doing and which distro are the most popular, go to:

http://distrowatch.com/

Among other things, have a look at the "Page Hit Ranking". It shows the number of hits per day each distibution ("distro") of Linux gets, averaged over a selected time period. By far, the most popular distro is Ubuntu.

I've had a look at every distro in the top 10, and most of the distro's in the top 25. There are good reasons why Ubuntu comes out on top (sure, I'll probably get flamed by fans of the other distros). The only way to figure these things out though, is to try them for yourself.

Linux is like Lego. The pieces are pretty much the same. The differences are more in how they are put together.

Ubuntu puts together a very nice, user friendly desktop OS. Check it out for yourself.

Unless you have some very funky hardware, most modern Linux distros with the 2.6 kernel should not have too many hardware issues.

I use a laptop, and laptops have been difficult in the past with Linux because the guts are usually not generic like desktop hardware. Still, the only issue I face on this is no full 3D rendering from my ATI Radeon Mobile adapter.

My internal "WinModem" works, thanks to a Linuxant HSF modem driver, and my D-Link USB Wlan adapter works thanks to the Linuxant Driverloader.

Everything else just works right out of the box (on Ubuntu 5.04).

By the way, logging in as root is one of the biggest sins you can commit in the Linux world.

You should create your own user account and password, and log in to that account. In Suse or Fedora, when you need access to something that requires root privileges, it will ask for the root password. If you want to be root at the command line, type "su" (with no quotes), and it will ask for the root password.

Ubuntu is a little different, as they disable the root account. Whenever you need root privileges, and it asks for a password, you use your own password (they use a tool called sudo for this). It makes things a little easier for desktop users, as you do not need to remember two passwords (one for you, and one for root). It also prevents you from logging in as root, as the account is disabled.

Anyway, hope none of that confused you.

Sort of US slang for "promotional statement" as in "Michael Douglas gave a plug for his new movie on the Tonight Show last night."

With the internet being so global, it might catch on in other areas.

is it is based on Debian and tracks the progress of Debian very closely all the while the Gentoo community is producing Gentoo improvements. The Debian philosophy is an installation should be built from sources to optimize for the hardware it is running on so you get the most efficiency from the OS. Gentoo continues that philosphy but they have gone to extra efforts to make it easy for the novice. They have a very nice Gentoo manual in PDF format (but I don't have the URL handy).

Basically with Gentoo, you can install pre-compiled updates with generalized compiler optimizations (fast install but the OS won't be as efficient), or you can have the package manager build your updates with the specific optimizations for your hardware (think CPU type, BIOS, chipset[the support chip environment for your CPU], type of graphic subsystem, NIC interface, etc.) making your installation very efficient for your machine.

Don't let the word "compiler" scare you. Gentoo and many other distributions have very generous script authors supplying the "make" and "build" scripts for compiling your updates from fresh sources right off the internet so you have the latest optimizations and patches in your updates. Most package managers (the user interface for maintaining your installation with updates, patches, and new software installations) make the use of these scripts seemless.

Will definately work with your KVM and mouse. After that, who knows? I've failed considerably at getting Apache to serve a web page, but that could be me and my inherant laziness (or desire for IIS level simplicity).

I've been using a KVM for a few years at home and have had no problems with mice at all. Ran Red Hat for a while, switched to SuSE when we started using it at work. Only difference is that I'm using a PS/2 mouse, don't own a USB mouse.

YaST is a definite plus in SuSE's favor; it makes package management pretty painless. YOU (YaST Online Update) also automates patching and updates which helps to keep your system secure.

I haven't tried other distributions much, just Knoppix recently, which is fantastic at hardware recognition and has LOTS of stuff included, games, utilities, etc. Also just pulled down Ubuntu LiveCD to look at, haven't seen enough of it to make any judgements.

Noobs out there may want to try a live-cd Linux distro. These run from the cd (as the name implies) and RAM, never touching your HD. They're a great way to play with Linux before committing to it. Knoppix is the grand daddy of the live-cds, and is superb. SimplyMEPIS is another. (BTW, I liked SimplyMEPIS so much that I installed it on a HD; the installation program is on the desktop, and is trivial to run). There are plenty of Web sites out there that provide info on live-cds, in addition to "regular" distros.

SuSe did not like my mobo's BIOS. After loading and reloading and repartitioning I figured out that either Linux was writing to the BIOS or it just liked to corrupt the partitions on it's own. I switched back to Ubuntu, very stable, and user friendly.

Ahem.

The common wisdom is that under the hood, all distros are the same. There are some differences under the hood, actually, but the experienced Linux admin can sort those out with a little effort. Mostly, it's the interface and distro-specific tools (like package management) that change from one distro to the next, though the difference between the configuration defaults of the RPM-based distros (Fedora, Mandriva, etc.) and more LFS/FHS-compliant distros (Slackware, Debian, etc.) can certainly be vexing at times.

Fedora/RHEL is actually one of the worst distribution families (among the major/popular distributions) to learn if you want to learn something portable across many other distributions. Red Hat has for a long time gone its own way in regards to standardization, which is part of where it gets its reputation as being the Microsoft of Linux. For instance, the standard Fedora/RHEL kernel involves some definite quirks that don't exist in other kernels, and not for any particular reason other than simply making things work the Red Hat way. Mandrake/Mandriva tends to take a lot of its cues from Red Hat, though it has been diverging more from the RH way of doing things in recent years, producing both better and worse results in terms of standardization.

If you want to just sit down in front of a GUI and get underway with that, and don't care so much about the nuts and bolts behind it, I'd recommend something like Fedora/RHEL, SuSE, and Mandriva, in no particular order. If you want to get into the thick of things at the command line, and deal with the more powerful shell interface, I'd recommend something more like Debian, Slackware, or Gentoo. While Debian, Slackware, and Gentoo are certainly capable of the level of GUI-centric use as Fedora/RHEL and friends, they really require you to explicitly choose such an approach, and while behind the facade Fedora/RHEL, Mandrake/Mandriva, and SuSE are still Linux, they diverge from standards in some surprising and sometimes problematic ways.

Erm. What was the point I set out to make? I think I may have gotten off-track.

KVMs are an interesting issue with pointing devices. In particular, make sure you aren't using a mechanical KVM device, as they can cause a mouse to "lose sync" when switching between computers.

It's possible that you misidentified the mouse type during installation/configuration. Perhaps you could include the text of your X configuration file in one of these posts so that I could troubleshoot it for you. I don't recall off the top of my head what SuSE calls the X configuration file, but in Debian it's /etc/X11/XF86Config-4. Yours should be something similar.

At least as logically as a Linux post can :-)

Ya, I love LUGs. I try to stay away from distro specific stuff.

Oh and the reason for the Fedora doing it with the GUI is they kind of broke things where the command line may or may nor work properly if using X.

For example. su to root and type ifconfig in X. I bet it won't work. Why, I don't know...

"For example. su to root and type ifconfig in X. I bet it won't work. Why, I don't know..."

cause ifconfig isn't installed by default?
( at least in most rpm distro's I've looked at it isn't.

Ya, I installed it...Anyway, if I log in as root, ifconfig works at the command line...if I don't and su, it won't.

I prefer RH and RH alikes for various reasons, but stuff like this drives me nuts!

Ifconfig lives in the /sbin directory. That directory isn't in the PATH of the normal users. If your normal users can read into the /sbin directory they can probably run ifconfig by entering the full path. Naturally the normal user won't have sufficient privileges to change the interface configuration or state but the normal user can read the configuration and state of the interfaces.

In my opinion, though, the normal user has no business checking the computer configuration. I would say that in a security enhanced configuration the normal user shouldn't be able to access the /sbin directory. One of my experiments was to set the /sbin directory to root:root ownership (already set) with 750 access permissions (default is 755). I hate having world/other access allowed on any directories, but particularly the root level directories. I've tried setting the /etc, /bin, /lib, and other root level directories to root:users with 750 permissions. Of course that's how I break things like the man command. :-)

Naturally I've limited my experiments to my test machines.

Maybe it is a bug in FC4 (I don't remember ever having the problem in FC3, but then again I don't remember if I ever used ifconfig after su-ing in X)

Anyway...just one of those things I guess.

I've noticed that rpm distros seem to have a problem with su for some reason. In many cases, you can't access the user's environment configuration if you use a naked su to get into the user account. Instead, it seems to want to unceremoniously drop you into system defaults. I'm sure there's some configuration setting I haven't looked into that controls that, and there's probably some (very stupid) reason that they do it that way (in some releases, but not others, I've noticed). Whatever.

Instead of using a "naked" su:
[b]$ su[/b]
try it with the "-" flag to make it a login shell:
[b]# su -[/b]

That should help out with annoyances like that. This is a problem I've never had with Debian, though. The su command just makes you the superuser (or specified user, as the case may be), and that's it.

Gah. What a silly way to do things. The RH Enterprise distros don't make you do this, but apparently Fedora does.

It is now my mission to track down the setting that makes this happen :-)

Considering that every Fedora, with some modifications, eventually becomes RHEL. Given time, you'll probably start seeing RHEL doing the same thing. That, or Fedora will stop doing it before then, perhaps.

Using the dash as an argument to the su command is standard in Unix. I don't know why setting up the user account environment wasn't made automatic with the su command. I just know that if you want to activate the account environment of the account to which you switch using the su command it requires the dash. At least that's the way it works in Solaris and in Tru64. I don't know about other Unix variants.

That still doesn't explain why using the full path of the ifconfig command doesn't work without the dash. All that the dash is getting you is the PATH of the root account and setting your current working directory to the root home directory. Depending on the error message maybe RH puts ifconfig somewhere other than the /sbin directory which I had suggested as the location of the ifconfig binary.

I hope that we're not scaring poor Garion11 off of Linux. Still this sort of thing is all part of the fun. Especially when you have a customer looking over your shoulder asking why you typed this or that and didn't get the expected response from the machine. Gotta love it. :-)

'Course, typically most things work like they should, just some things don't :-)

What really bothers me is that Red Hat is going back to the ghetto permission system they had before (RH 7 or so). With SELinux and stateless Linux, why are they going back to their bad old ways???

On that note for Garion11: *nix is still FAR more usable than Windows in most applications. *nix is more secure, more or less the same across distributions (save for our converstation), and in the long run easier to use.

because I don't have enough Linux background to express an informed opinion.

I'll agree that Linux is more secure (at least out of the box). I won't argue the distro point, although there are far more distros than Windows versions.

You feel Linux is easier to use in the long run. What features or differences led you to that opinion? Just wondering.

Palmento, the reason I say this is because in the long run *nix is more usable.

Let's take a look at the setup of an Exchange server. It is virtually all GUI based and quite hard to navigate. Maintaining the Exchange server is problematic because of all the tabs and buttons in the GUI.

In Linux you can use both a CLI and a GUI to setup sendmail (for instance). Setting up sendmail can be as easy as "service smtp start" or as complicated as getting postfix and sendmail working together via a proxy and using POP3/IMAP for webmail.

The nice thing is that over time it becomes far easier to maintain this sendmail server because you can create scripts, aliases, and various other things (cron jobs for instance). In Windows you typically have to have a more hands on aproach and you can't customize as much.

The reason I say long term is that it does take a little while to learn, but after a year of doing it, not only will you be proficient, but you'll be able to shortcut many tasks.

Garion started this thread talking about Linux on a desktop, not a server. I'm not debating which OS is "more usable" (whatever that means). I'm questioning your statement at the end of your "Exactly!" post that Linux is "in the long run easier to use".

I've always found GUIs easier to navigate, and I've used CLIs in VMS and DOS for years. I deal with an Exchange 5.5 server every day, and with the GUI I can make it jump hoops and go for pizza. Why? Because that's how I learned to do it and I'm comfortable with it. Yes, I sometimes forget what tab or button to click when performing a task I don't do very often, but I just as frequently have to look up VMS commands I use only rarely. One disadvantage of a CLI is it's easier to make mistakes or enter the command incorrectly, especially for the non-typist.

Starting a Windows service can be as easy as creating a shortcut to the Services applet on the desktop and right-clicking the service you want to start or stop. But once the server's up and running, how often do you have to start and stop the services?

Windows will run scripts and scheduled jobs. While Microsoft doesn't give it the attention it deserves, there is are command line and scripting tools in Windows that are as powerful as the GUI. Sorry, but that sounds like a wash to me. I'll be happy to concede this point if someone will post something that can be done in Windows Server only from the GUI.

I've never seen sendmail but I'll grant that it is more customizable. That doesn't make it easier, just more flexible. Increase flexibility requires more research of the available options and knowledge to know which to use. That doesn't sound easier to me.

I'm not saying that Windows is easier (or harder); neither a CLI nor a GUI is "intuitive". Your position that a year of doing something makes you more proficient can apply to anything - Windows, Linux, Mac, riding a bike, driving a standard transmission, playing a musical instrument, anything. Ease of use comes with practice and familiarity.

1. Linux security isn't really necessarily better "out of the box". It is, in fact, in terms of its securability, ease of securing, and resistance to exploits that Linux is more secure than Windows in any meaningful sense. While on the average your default Linux install will outperform a default Windows install "out of the box" in a time-to-compromise test, and under similar circumstances, that is by no means an inherent talent of Linux. This is the one case in which the "it's only secure because nobody uses it" argument holds any water at all: it's always possible to configure a system for reduced security, and as some distros seek to emulate Windows in a misguided attempt to gain market share, I suspect that de-secured default installs will become more prevalent in desktop distros.

Linux, as any unix, enjoys many benefits in basic system architecture that Windows does not, as regards security. It is often argued by unix/Linux enthusiasts that this is because UNIX was designed for security from the very beginning, but this is a slight misrepresentation (surely unintentional) of the facts. The truth is that Windows began as DOS, a non-networking, inherently single-user, single-tasking system for computers that had almost nothing for resources. UNIX, meanwhile, began as a platform-agnostic, portable, networking, multi-user system in its very early days. This doesn't mean it was more secure: quite the contrary, it was less secure because more people had access to it. Once DOS/Windows started to be used in networked environments and started needing user accounts, however, its basic architectural design served as a sort of developmental disorder that prevented it from adopting the core security capability of a system that was designed for multi-user networked environments pretty much from the beginning. That, in addition to other factors (such as increased orthogonality of design and, in the case of Linux, the "many eyes" principle of security auditing), contributed greatly to the development of a system that is more secure than Windows has ever dreamed of being in a connected world.

2. Because everything in Windows is geared toward the GUI, and because the original DOS was nothing more than a toy for toy computers, the command line syntax of modern Windows systems cannot help being anemic in the extreme. The lack of CLI-centric design features makes configurable system automation much more difficult to achieve, requiring ever-more complex and crufty GUI system structures for managing even the simplest of tasks. Extra commands at the command line, and extra flags for each command, take up no extra screen real estate, while every new "feature" of the MS SQL Server GUI requires another button that somebody has to squeeze into the interface. Furthermore, scripting behind-the-scenes behavior becomes more difficult, as the full functionality for something like MS SQL Server is wired directly into its GUI, leaving far less of it to be accessible behind the scenes through scripts: it's much easier to script bash commands than complex systems of binaries used to ultimately place a button on your desktop. Sure, there's macro capability in many such applications, but even that doesn't take into account cross-application scripting and combining multiple small utilities (which don't even exist, because of the monolithic-application philosophy of the GUI environment) into complex, automated routines to make your job easier. In addition to that, when you press a button on some GUI app, you don't really know what's going on behind that button, or have any way of finding out, much of the time; this makes for interesting problems when you're not sure what to expect from a given action.

Hopefully that clears up some of what's going on with the neutering of system usability that GUI-centric design represents.

One person's "neutering of system usability that GUI-centric design represents" is another person's ease of use. I think we're at another impasse. Thanks anyway.

Ease of use is definitely a matter of personal taste. For some people, monolithic GUI apps are "easy to use", and CLI utilities are not. I don't really grok that on a visceral level, but I can comprehend how that is on an intellectual level. True usability, however, is far beyond that. Usability requires things like consistent interface features, flexibility of use, orthogonality of design, functionality that isn't restricted by interface philosophy, and so on. None of these things is particularly endemic to the standard Windows GUI application.

There's a distinct difference between usability and ease of use. In the latter case, any schmoe can sit down at the computer and start clicking things, or after a short familiarization can begin to become a power user, or whatever other metric you decide to use to measure "ease". In the former case, however, you must examine how much functionality is incorporated for the same complexity of UI, how flexibly that functionality can be employed, and how configurable that functionality is.

To give you a real-world example of ease vs. usability, CD burning is a great place to start:

On one hand, you've got the Windows CD writing/rewriting capability, plus third-party applications such as Nero and Roxio. In the case of the Windows CD writing/rewriting capability introduced with Windows XP, ease of use is incredible for the most basic CD-burning tasks. I'll certainly admit that. It's a drag-and-drop operation, and all you need to configure to make it happen is probably done for you when the OS detects your CDRW drive and loads drivers for it. It lacks some significant functionality, however, for purposes of this example notably the ability to burn ISOs to disk. For that, you need Nero or Roxio (for instance). Nero significantly reduces ease of use, because it combines a dynamic product theme in the interface and because it has to include a lot more functionality access in its interface. As such, the interface has a lot more options, many of which must be explicitly chosen, and few of which are clearly marked in a way that is immediately, intuitively understandable to the new user. As a matter of fact, it's sort of a pain in the arse to figure out, the first three or four times, how one burns CDs from ISOs. I know, because I've had to do it, and it took almost a half-dozen times before I started remembering where it was without having to find it again. Roxio, meanwhile, is as functional as Nero, and easier to use, but less pretty because the designers focused on making it look like an application rather than a slickly-packaged product. It doesn't have the flame themes and nifty button markings: it says stuff like "burn disk from image", and all major functions of the application are two or three clicks deep at most. Features are arranged in a clearly hierarchical fashion, which is nice. It's still not as easy to use as the Windows CD burning utility, however, because you have to know what you want to do to save to CDs. You have to know what a CD image is before you know whether or not that's what you have to use. It's not a drag-and-drop operation all the way through on Roxio.

On the other hand, you've got the Linux set of CD burning tools. At the most basic level, you install cdrecord and mkisofs. For burning CDs,that's really all you need. Use mkisofs to create CD images from whatever you want to put on a CD, and use cdrecord to write to disk. You can add DVD writing capability with dvd+rw-tools, which throws DVD formatting utility together with a command line front-end for mkisofs, and some miscellaneous functionality. To add the ability to "rip" CDs along with "burning" them, install cdparanoia. To install all of that on a Debian system, log in as root and type "apt-get install cdrecord dvd+rw-tools cdparanoia mkisofs" though, to be perfectly clear, Debian will automatically install mkisofs with dvd+rw-tools since it's a dependency.

There are packages that tie all these things together into one simple interface. There are also packages that tie all these things together into one complex interface. Pretty much every single one of them allows greater functionality than Nero and Roxio put together, and the flexibility in creating a single application from a handful of powerful command-line tools is something at which one can marvel for hours. Furthermore, you could even write simple scripts to combine these tools with other tools creating automated backup routines that require no more effort from the user than getting them started and swapping out CDs when prompted, or any of a million other uses that aren't possible with Nero, Roxio, or (especially) the Windows CD burning utility.

I've tried several of those complex GUI applications for burning CDs, by the way. I'm talking about stuff like K3B and gcombust. I'm aware of an extension to the Nautilus file manager that allows drag-and-drop burning just like in Windows, by way of cdrecord and mkisofs, and of webmin-burner which provides a web-administration interface front end for CD burning. Ultimately, none of that appeals to me, because though it's easier, sometimes, to use that stuff, and certainly easier and more functionally complete than the Windows-based counterparts, none of it is as usable, flexible, and powerful as simply installing cdrecord, mkisofs, dvd+rw-tools, and cdparanoia, and entering commands through bash.

Maybe that's just me.

But it's not me. You and I agree ease of use is a question of personal taste. We seem to agree that increased options require additional knowledge before you can use them effectively. I'm disagreeing with jmgarvin's assertion that *nix systems are "in the long run EASIER TO USE" (my caps for emphasis) in his post "Exactly!" My position is that what you know always seems easier to use than what you don't, and that in the long run -anything- gets easier to use, GUI or CLI. I'm more comfortable at a DOS or VMS CLI than a Linux one simply because I already know a large portion of the command set, knowledge I gained over the long run.

Thanks for the comparison, but I don't have the experience to fully appreciate it. The only CDs I burn are to offload the files of users who have left the company. I use Padus' Diskjuggler for that. Monthly I'll drag and drop my home system data files to a CD. I've never seen Roxio or Nero, am getting a grip on what an ISO is (but haven't had reason to work with one yet), and don't know what "ripping" is or when to do it. DVDs? My wife watches them, but I haven't had a reason to learn how to operate the player. Maybe that's why I don't understand why you'd want to install multiple applications and another app to tie them together, instead of installing one "do it all" app from a single source and reducing the possibility of conflicts.

I'm sure installing them is quite easy -IF- you already know what you're doing. My point is the option you're comfortable with always looks easier than the unfamiliar one. I was never comfortable enough with the few Linux boxes I built to attempt to install apps beyond what came with the distro CDs. If I had, I would have tried a GUI install first since that's what I'm experienced with. I also didn't know what commands to use, and felt attempting to work with a GUI would be easier that attempting to learn the appropriate command.

1. I think jmgarvin's statement that Linux is "easier to use in the long run", or whatever the exact phrasing might have been, was perhaps not very precisely phrased. I can understand and appreciate his perspective on it, and tend to agree with it: I'm thoroughly familiar with both Windows and Linux quirks of interface style, and for my purposes I find Linux to be much easier to use in the long run.

When I say it's easier to use "in the long run", though, what I'm saying isn't that with familiarity it gets easier. Rather, I'm saying that, once I'm familiar with both, I find that the same ease of use yields more flexibility and range of use with the Linux system. In other words, I get used to a greater functionality, and achieving the same results on a Windows system is typically much more difficult, if not effectively impossible, which makes me look at the task at hand and say something like "This is SO much easier with Linux!" It's not because of greater familiarity with Linux (I've only been using it basically for this century, whereas I've been using Microsoft OSes pretty much since they were first marketed): it's because I can achieve what I want to do without having to jump through far more hoops.

2. With a decent package management system like Debian's apt and the unixy one tool one job well philosophy of development, your statement "Maybe that's why I don't understand why you'd want to install multiple applications and another app to tie them together, instead of installing one "do it all" app from a single source and reducing the possibility of conflicts" doesn't make a whole lot of sense. I realize this is a matter of not being familiar with the way Linux distros tend to work, so I'll try to explain what's going on with that small pile of utilities so that conflicts aren't even on the radar:

Because of the necessary monolithic cohesiveness of interface design in GUI environments to reduce clutter, and the uselessness of back ends for applications that consist of a multitude of command-line utilities when your OS is designed from the GUI down rather than from the kernel up, Windows applications are monolithic not only in interface design but in software architecture as well. As such, all the functionality of a given application suite is an indivisible part of the whole.

This means that when additional applications are made that overlap a given application in functionality, such as when you have on one hand a music production suite complete with CD burning and labelmaking featuress, and on the other hand a small-office backup system that allows periodic backups for offsite that can be done to tape, removable hard drive, or optical disk (such as a CD), the two separate application suites' developers reinvent the CD-burning wheel, each in their own manner. Both of them must use the same CD burner on the same computer, and thus both must configure the CD burner for their own uses. Each might also demand a certain amount of attention from the CD burner by way of sending it occasional "pay attention to me" messages, just sorta pinging the IRQ for the device. All of this has the potential to develop problems of the sort you describe: conflicts.

Meanwhile, with the CD burning software and its attendant utilities that I described in my earlier post, none of these things actually controls the CD player at all. Only one thing controls the CD burner on a Linux system, and that's the kernel module (driver) for it. The cdrecord utility basically just puts ducks in a row and fires off a user instruction to the driver, which then executes the instruction if it's not otherwise engaged. No conflict. At worst, you might have to enter the command again when a previous burn is done. Applications don't crash spectacularly, taking out large chunks of the OS, because they aren't fighting for control of resources: they just say "Hey, may I use this resource?" and if told no, they sit down and shut up. Tiny little utilities that just do one thing and do it well don't have the room in the code for resource management routines necessary to create huge, complex tasks of the sort that are going on in a monolithic application like Roxio or Nero. Instead, there's a string of one-shot utilities, each doing one small job in turn and passing on the results to whoever or whatever called the utility. The K3B application calls mkisofs and cdrecord, in that order, to create and burn a CD recording task, and at each step of the journey if something fails to happen the utility in action at that time just spits out its error message and clicks off. The "glue code" scripting of K3B then handles the error message as it was designed to do, and typically this means it asks if you want to try again from where the process stopped, possibly passing information on to the user to correct something if, for instance, user permissions aren't properly set. Roxio or Nero, on the other hand, gets to part of the process, finds out it can't do something, and locks up because it's not divided into discrete parts: it's one contiguous whole, and if part of it fails, the whole thing fails. This makes every step of the process a single point of failure for the ENTIRE process, which is a magnified problem when you consider that each one of these things is trying to get direct control of the CD burner all for itself.

that has to be the clearest explanation of the benefits in the architectural model of *x I have ever seen.

no monolithic lockup crashes, taking out the os itself. :)

I appreciate the appreciation. Heh.

I actually stole from you a little (ok a lot) when one of my students asked "Why should I use Linux when I am so l33t with MS?"

I think once people can understand this, it becomes far easier to explain other details.

Thanks for the great post!

on a programming resource forum Ihad to use it.
someone there is just starting up in programming again, and also switching from dos to linux for environments.

http://cboard.cprogramming.com/showthread.php?t=69433

is the discussion.

JMG, what's "l33t", and is it good or bad? Is it pronounced "leet" or "el-three-three-tee"? I suspect it of originating with the IM / miniscule keyboard crowd.

Appy, I was able to hang with you most of the way, but it's going to take repeated readings before I can digest it fully. I've never heard the word "monolithic" applied to software before. Thanks, as always.

The term "monolithic" in reference to software means roughly the same thing it does in common usage: all one piece. In terms of software architecture, it denotes a lack of orthogonality and modularity (very similar, but slightly different, characteristics). There are a great many reasons why orthogonality of design is good for code, and why modularity is usually good for programs, but one of the biggest reasons is that the smaller your integrated chunks are, the easier they are to debug, to get right the first time, and to understand, while the bigger they are the more prone they are to errors and the less anyone wants to try to fix them when errors inevitably arise.

As for the rest of you: Thanks. I didn't realize it was that good when I was writing it.

"Orthogonality"? Sorry, none for me; I'm driving.

All the Google returns for "define orthogonality" make reference to vector mathematics.

From dictionary.reference.com

orthogonality

n 1: the relation of opposition between things at right angles [syn: perpendicularity, orthogonal opposition] 2: the quality of lying or intersecting at right angles

or?thog?o?nal P Pronunciation Key (?r-thg-nl)
adj.
Relating to or composed of right angles.
Mathematics.
Of or relating to a matrix whose transpose equals its inverse.
Of or relating to a linear transformation that preserves the length of vectors.

============

Actually I'm glad that I finally looked this up. I thought it had something to do with killing bugs and other common garden pests. :-)

I did like your (apotheon's) description of modular vs. monolithic software architecture. :-)

In mathematical terms, it refers to things being at right angles to each other. In programming terms, it pretty much means the same thing, but conceptually rather than physically.

Orthogonal design involves designing parts of a software project so that they are at "right angles" to each other, meaning they cover wholly different directions for the project. Thus, they do not "overlap". The central idea is to avoid repeating yourself. In fact, in [u]The Pragmatic Programmer[/u], one of [b]the[/b] seminal works of programming theory and practice, this principle of avoiding redundancy in software is referred to as the Don't Repeat Yourself, or DRY, principle. Adhere to the DRY principle faithfully, and you'll be able to avoid making a mess of your code.

This is not the same as redundant systems. Redundant code is inefficient and difficult to modify without breaking functionality. Redundant systems include fault-tolerance and backup solutions. It's a good idea to keep these ideas separate. Thus, within a system, everything should be stated, defined, or designed only once, but systems can be duplicated for purposes of recovering from system failure (for whatever reason).

The nightmare of being a good programmer in the Real World is that everyone wants you to use Java to do your programming, which is a fairly poorly organized and implemented language. It actually enforces a certain amount of non-orthogonal design.

No, I'm not saying I'm a good programmer. In fact, I'm pretty sure I'm not. I aspire to be one, some day, though.

So l33t translates to el-eet or elite. 33 is the representation for e.

I used it because it drives me nuts, so I'd thought I'd share the joy.

I figured that since you work with these people you must have learned to appreciate the fresh approach to communication that the college crowd uses. If I had to tolerate that all day it would burn a hole in my stomach and eventually I would resort to violence for relief.

Now when I was a youngster we had leftover slang from the 1960s and even from before that. I remember hearing Johnny Cash saying "man" every third word in one of his songs and it reminded me of when I was twelve years old. So it couldn't have been that terrible for my parents to listen to me talk. The 1970s teen talk was really just borrowed from earlier generations of teens.

Not like this hippity hoppity crowd today with Snoopy's shizzle bizzle tizzle and the other idiots' blizak tizak shizak stuff.
If I had a rocket launcher ...

Now my blood is boiliing. Time for the meds. :-)

This does not sound like a KVM issue. Comments within.

The 2 annoying things that I have to mention are the KVM switch box issue with the mouse and the NIC. I use a industrial strength custom made Connect Pro Master IT 4 port KVM switch box (old KVM switch. This would be a PS/2 KVM switch. When you start adding in USB adapters you are going to have issues) with no power cord (draws the power from the mouse? and/or Keyboard?) and switch back and forth between my regular PC and this test one. As soon as Linux booted up to desktop my mouse behavior was erratic and in fact was completely useless. (It sounds like there was no issue until he installed Linux) This is a logitech USB (with a PS/2 adapter)(Using a USB mouse on a PS/2 switch. USB can be tricky and adapters do not always work) Mx510 optical mouse. The KVM switch when it was switched to the test PC and only WHEN BOOTED UP IN LINUX would have the corresponding light on the switch flicker. This problem is nonexistent in Windows 2000 on the same PC and needless to say the mouse works fine. I plugged in the mouse directly to the PC in the USB port and it found the mouse but I still can't use it, (The fact that he plugged the mouse directly into the computer and by passed the KVM switch says it is an operating system issue not a KVM problem) in addition I plugged it into the PS/2 port and same result...no good and very frustrating to say the least. If any gurus here know how I can go about and resolve this issue your help is appreciated. I am going to reinstall the OS with the mouse plugged in directly instead of going throught the KVM switch and will update on the results. (you probably will still have mouse issues). Go get an Avocent SwitchView.

This is not a common issue between Windows machines and Linux machines.

Now that I think about it, stress junkie makes a very good point. You should still be able to execute commands as root using the full pathname without any problem. There must be something wonky going on with your bash configuration. I'd love to figure out what it is, though. Perhaps you could send the text of your /root/.bashrc and /root/.profile files to me via my TR contact, my email address (which I think you have some where), or a replay to this message thread.

Technically, all using "su -" instead of "su" should do is parse your .profile (or .bash_profile) file in addition to your .bashrc file. Thus, I'm thinking that maybe .bashrc is unsetting something and .profile is resetting it, or something utterly wacky like that.

# .bashrc

# User specific aliases and functions

# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

export PATH

Freaky, eh? I'm stumped. I've looked all over for various reasons this could be. I've even changed shells to see if maybe Red Hat just borked up bash, not the case. I've no idea WHAT is going on here. Very wonky and very frustrating that there is some (it must be) Red Hat specific config file floating around that is causing this mess.

In the meantime I've aliased su - to su, so that mostly makes it transparent, but it is still so wonky.

I show my students how stupid they sound when I use it, foe shizzle.

I also use dated slag to let them examine how stupid their slag will sound in 5-10 years.

What really kills me are that people are starting to speak like they text message/chat. What is that? Did you know I actually heard one of my students say "LOL!" Not laugh out loud, but lol.

Yeah . . . that's really strange. Is there anything odd going on in [i]/etc/bashrc[/i]? I see that it's explicitly sourced in your usesr [i].bashrc[/i].

Have you tried typing "which ifconfig" to see if the path you're using is the same as the path it thinks you should use? Have you actually navigated to the directory in question (possibly /sbin for instance) and tried [i]./ifconfig[/i] as a means of accessing it?

I'm trying to come up with anything you might have overlooked.

Heh. I suppose you could always just give me your IP address and root password, then let me try to figure it out. Hah. Hahahahahah! The power shall be mine! Muahahahahahah!!! Er. Ahem. Sorry 'bout that. Forget I said anything.

I hate to suggest it, but . . . maybe you got rootkitted. When did you first notice this happening?

"Yeah . . . that's really strange. Is there anything odd going on in /etc/bashrc? I see that it's explicitly sourced in your usesr .bashrc."

I'm not at my machine right now and I don't know my new IP off the top of my head, but I don't think there was much in /etc/bashrc other than some really basic config...

"Have you tried typing "which ifconfig" to see if the path you're using is the same as the path it thinks you should use? Have you actually navigated to the directory in question (possibly /sbin for instance) and tried ./ifconfig as a means of accessing it?"

Yup. I've tried
# which ifconfig - returns /sbin/ifconfig
# /sbin/ifconfig - dumps back to the command line
# cd sbin (then) # ./ifconfig - dumps back to the command line

"I'm trying to come up with anything you might have overlooked."

I know...very frustrating isn't it?

"Heh. I suppose you could always just give me your IP address and root password, then let me try to figure it out. Hah. Hahahahahah! The power shall be mine! Muahahahahahah!!! Er. Ahem. Sorry 'bout that. Forget I said anything."

Sure my root password is....WAIT A SECOND! :)

"I hate to suggest it, but . . . maybe you got rootkitted. When did you first notice this happening?"

I think this happened after I upgraded from FC3 to FC4. I'm pretty sure that this is when I noticed this happening.

"It seems that somewhere ifconfig only works when you log in directly as root."

I've checked for rootkits (checksums and various rootkit checkers). While that doesn't mean I don't have a rootkit, I feel pretty confident I don't have one.

What really bothers me is that su - is usually implied and now it isn't. I have a feeling something went wrong when I installed the new packages so I could migrate from FC3 to FC4. I'm going to try three things:

1) Update ifconfig
2) Clean install FC4 on another box and see if the same behavior happens
3) Change the permission (just for testing) to 777 and see what happens....

It sounds like maybe something still has a config that's compatible with FC3 packages with an FC4 package installed that doesn't recognize that config, or something like that. Unfortunately, it might not be ifconfig (or whatever package contains it in Fedora): it could be bash, or su, or any of a number of other things. Good luck with getting it sort out, though.

Yeah.. well, I am a newbie to Linux and I have a few adventures, too. But I like it!

I first downloaded a Knoppix 8.3.1 iso (Live CD) after reading about it in PC Mag, burnt the
image successfully, and explored some. I liked it immediately, but was really surprised at how
it looked so much like Windows (KDE desktop) (and all those pretty colors as it booted up!) :)

I then read a couple books on Linux to get more of a feel...

See, I have a project at work that needs a Web server on the LAN (only) and wanted to use Apache (and not with windows)

So about a month later I was looking a little more seriously at choosing a distro and went to
distrowatch.com to check it out. A bit blindly I must admit, I looked at Ubuntu (Debian-based)
and found they had a version called Kubuntu which used the KDE desktop, so I DL'd that, etc.

I had just changed my CDRW to a Plextor DVD-RW which worked fine in Windows. Well. This was a disaster in Linux. I ended up having to install a plain vanilla ancient CDRom and making it master just so the distro would boot up forinstallation. (The Knoppix was used on my old CDRW and wouldn't
boot either with the new DVD-RW), Much tearing of hair, forum visits including getting flamed
even tho I was polite, and parts swapping a few times here. Yuk! (and the silly DVD-RW still
won't work, but more later)

So I installed Kubuntu, felt really lost for a while, but still liked its concepts. Its way of getting you into root on a temp basis to do root tasks I found really easy and convenient (Ubuntu does this too). However after a few days of using the KDE desktop I felt it was too cluttered and fussy and I was getting freezes and hangups with KControl which I couldn't resolve, so I decided to try Ubuntu (which has the Gnome desktop; there are Linux desktop wars, too, I found out ;) )

Ubuntu installed without a hitch, found everything (except the DVD-RW still won't work as a DVD reader/writer, but does do CDs), got on the I'net instantly, all that. I liked it. By then I
was beginning to find (and remember!) where things lived in the filetree, etc., and how to
configure things better.

However, printing is a challenge because I have no local printers on my home and office workstations. I had to quickly learn the Samba dance since both at home and at work I have a domain-based Windows network. I'm still wading through much of this, but at least I have one printer working in Linux on each network. But no image printing yet, just text. I can accesss the Windows' network shares, though, which is a big bonus for a newbie like me, and made a FAT32 transfer partition for certain data files.

For me Linux at this point reminds me of early windows with all the separate config files. I'm
getting used to it though. I don't mind text mode and the terminal; in fact I had to rescue
myself that way from a big mistake screwing around with the fstab file.

Ubuntu has a very easy way of downloading and initially installing programs, that made it a lot easier for a newbie like me to do package installation (it uses something called Synaptic). However, I did install one program from source quite successfully (Bluefish, an HTML editor)

But I still can't fully use my DVD-RW. Or print from GIMP (imaging). I'll get there I'm sure. I really like Linux and am now starting the massive config for my testing web server on the office LAN. I'm also working on using our VPN through routers to get into the Linux computer at work from my home office Linux machine. But I'm being very cautious here, until I fully understand the security configs.

And as if I don't have enough to do ;), I'm thinking of trying another distro for the heck of
it and am leaning towards Gentoo.

In your 'ease of use vs. usability' message you have given me a clearer path to solving my ongoing DVD-RW trouble in Linux.

I know some of those packages you referred to are installed, but I'm going to confirm the ones related to DVDRW. Thanks much!

I'm glad I was able to help out.