two points
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.
Posted by: apotheon Date: 09/07/05