No idea if there's any truth to Russian organized crime connections to Allofmp3.com, but at least the Russian mafia won't use my money to buy out my politicians to restrict my rights, whereas the RIAA does. As such, I'm much more comfortable giving my money to Russian organized crime than to the RIAA.
That's only useful because of the way application windows in Windows work. Once you get used to working on a Mac, you'll find that you don't want applications to take over your entire screen, and that working in between apps is much, much easier. It's so much nicer to have apps remember two window sizes you set (typically one large format, and one small format), and have the "maximize" button toggle between the two. The menubar at the top of the window is also crucial for working between apps, as individual windows in an application no longer have to be contained within a big application window, allowing you to switch back and forth between windows in different apps much more efficiently. This alone makes complex workflows (those involving multiple apps) in Windows a pain in the ass. From a workflow perspective, once you're intimate with MacOS X and Windows (intimacy being the key term), I have yet to meet someone who doesn't prefer working in OSX. It does take a while to get used to working the new way, but once you do, you'll never want to go back.
Fairplay doesn't have the capability to expire songs once you stop paying for the subscription. WMA's Janus extension is required for this functionality, which has the player check that you are supposed to have access to those songs each time you plug it into your computer, and expires songs after a month if you don't let it verify. While this nasty little system works, it introduces requirements that some may find objectionable. Simply licensing Fairplay isn't going to get you access to subscription-based content. Basically, if you want subscription content on the iPod, you're SOL, but you should have known that when you bought it.
What's more interesting here is that Apple is turning down a potential revenue source (licensing Fairplay to CD distributors) for no other reason than what appears to be the belief that they have enough control over the digital music market to influence the direction of CD distribution as well. It seems they are making a stand to make copy-protected CDs impractical, hoping that distributors will instead keep producing standard CDs. Personally, I am very happy they are doing this, as copy-protected CDs are an incredibly stupid idea that only serves to inconvenience paying customers. I don't buy music from the big labels anymore, so I've never encountered copy protection, but you can be sure I would demand a refund if I was unable to use my purchased CDs as I see fit (within the confines of copyrights). Having Fairplay copies of the music on the CD as well wouldn't alleviate this problem, as I want to rip my CDs to MP3 format, in the bitrate of my choosing. In this case, Sony is clearly wrong, and they need to go back to making standard CDs if they want to sell to iPod users.
Probably if they have a lot of carry-on to stow, or want to secure newspapers, magazines or pillows/blankets before they're all taken. Also, if you have an inside seat, it's easier if you get there before the person sitting in the aisle. If you have little carry-on, and/or you have an aisle seat, then it would be dumb to try to get in early.
Back to the topic of human stupidity, driving is by far the worst view of it. I don't mind fast drivers when traffic is light, having to navigate their way through left lane campers, but those who try to bust crazy moves in thick traffic for some insignificant placement advance are the worst. It's the kind of behavior that leads to accidents, just like this iMob incident; though that was exaggerated due to the unreasonably low offering price of the iBooks, creating significant profit opportunity for those who could buy them (and there's no better motivator than free money).
I'm glad they don't, as strong DRM is the worst thing that could happen. Just like setting up a network of surveillance cameras that covers every bit of space would be a terrible thing, as it would take away our freedom. The reason why it's tolerable to have such an abundance of laws is because you don't get in trouble each time you break them, usually only if something bad happens as a result. With media, people should be free to control how they personally use the media they purchase, including which devices they wish to play it with, as well as converting it to a compatible format. If there is piracy as a result of this freedom, then that is a civil or criminal matter between the copyright holder and the violator. That doesn't mean that everyone should be locked down just to prevent any possible infringing use. The customer and the violator are typically two different people, and treating them as one is a good way to lose all your customers.
What Microsoft is offering is an absolute lock, which is too much power to place in the hands of content creators. Obviously a pirate can just hook up an analog recording device to the speaker outputs, or find a way to patch video to an analog capture device, and the content will get out regardless. But the controls in place prevent me, the honest customer who pays for content when available, from using the content I purchase on devices I own, since I'm unable to convert to standard formats.
Apple's iTMS is no better, forcing you to install hacks or burn to CD and then rip to MP3 in order to use the content as expected, and so I don't use that either, though it is a far cry from the mess with Windows Media DRM. I will never purchase digital content that can't be converted to other formats. I buy CDs because I can rip them and use them with my MP3 players or make copies for my car. I buy DVDs because I can rip them and make copies to preserve the originals or convert them to formats that play on various devices or take up less HD space. If I were to lose this power, I wouldn't pay for any content. DRM is really a stupid way of trying to move to a digital distribution model, as it only pisses off the people you're trying to sell to, and doesn't prevent the content from showing up on P2P. Content creators are going to have to realize that they need to give up control over the customer, and rely on convenience, availability, marketing, law suits and common decency to sell their products. I want to buy content, I just won't do it if I can't have control over how I use it.
There are 68k emulators for x86, such as Basilisk II, which can run MacOS 7.6.1 well, and 8.0 unstably. There are also PPC emulators for x86, such as PearPC and QEmu, which are progressing nicely, and should at least let you run your old OS 9 apps. With this transition will come much greater demand for these products, boosting the attention and devotion they receive, and hopefully enabling you to access your old data and binaries without too much trouble. OSX PPC apps are taken care of with Rosetta, and I'm sure most active developers will be releasing universal binaries of their apps pretty promptly after (or even before) the x86 Macs start shipping (at least the Cocoa devs). I really don't think the situation is as hopeless as it may appear to you, and if you still have a PPC Mac available, you can always use that to convert old data to usable formats.
I know Verizon does the same thing, so that they can sell you ringtones and graphics, and charge you for data transfers with the data plans. Since I got AT&T (now Cingular) I'm able to transfer sounds (ringtones) pictures and themes over BlueTooth (USB optional) to my computer without hassle. That alone is worth getting Cingular (the excellent nationwide coverage, kick-ass GSM phones and rollover minutes are also nice). The only thing you can't transfer directly to the computer is the games. US Cellular is quite possibly the most user-hostile provider in existence, not to mention being expensive and using the crappy CDMA network and phones.
That will be more than adequate. You wouldn't lose any quality if you went with the 1.25 GHz and 512 MB RAM. The only issue is the limited HD (size and speed), so you won't want to use the mini's HD for anything else while the capturing is going on. Also, if you choose to get a FireWire hard drive later on, make sure you do NOT capture from your FireWire camera to the FireWire hard drive on the same bus, as it would result in lost frames and poor performance (since the incoming video needs to be buffered in RAM before being sent to the HD, causing two simultaneous transfers over the single FW bus). An external drive would be fine for acting as a repository once you've got the content captured already. I would definitely go for the 80 GB drive if you plan on working with a lot of video, and the only place you might notice a performance improvement in bumping it up to 1.42 GHz and 1 GB RAM would be in the encoding to DVD format process if you plan on doing that.
Just wanted to note that the iBook uses a G4 as well, and with a firmware hack, can do monitor spanning as the PowerBook does, though albeit without being able to drive the same resolution levels, as the video card is significantly weaker.
This conversation has gotten a bit dated, but I just want to say that users work differently in the MacOS than they do in Windows and KDE or Gnome. To have the menu in the App's main window, or generally not behave like other Mac apps is grounds for a lynching in these parts. Personally, I prefer the way Mac apps behave, and I'm most productive that way. I definitely understand that it would be nice to have apps behave the same in different OSs (and you can run your favorite X11 window manager on top of OSX, as long as you don't care about most regular commercial apps), but Mac users will never accept native apps behaving like Windows or KDE/Gnome apps, and vice-versa, so there's no easy solution to a cross-platform widget set. Java Swing apps can sort of approach this by having things like the menu bar being optionally in the main window or the top of the screen, and I believe some Qt interpreters for OSX can build apps that behave like native Mac apps if desired. The problem is they're missing a lot of nifty features present in Cocoa, including a huge wealth of NS frameworks and UI calls. OpenStep might one day become a sort of answer to that, but without official support from Apple, I have a hard time believing we'll ever see the ability to compile one code tree for MacOS X and BSD or Linux, let alone Windows. Until then, there will always be a need to port your large OSS projects like Gimp or OO to Cocoa, as is being done now, just for the sake of widespread adoption; but you won't have your unified interface for all platforms, and interface advancements for those projects on one platform won't make it to the others without additional porting work. I guess it can't be helped. In the meantime, I'm having a blast in this happy marriage of UNIX and centralized authority and vision, along with the brilliance that was NextStep.
The extremely picky user base also pushes us developers to really work hard to make interfaces as innovative and intuitive as possible, and rewards us greatly when we make that effort. Even if we have to spend more time than we'd like coding and recoding the interface, if it make the app more accessible and efficient for our users, then it's all worth it in the end. The care that Apple put into making the interface of its OS and apps be as intuitive and efficient as possible has really raised the bar for what a good Mac app needs to be in order to be accepted and praised by its users. This, in turn, empowers the users to accomplish tasks that they would be hesitant to attempt with the tools available on other platforms (due to a general lack of design skills, both in supply and demand), and increases everyone's productivity and expertise.
I also like the interface to be optimized to the task at hand, but the sad truth seems to be that most developers on other platforms seem to think that the interface is just an afterthought that's bolted onto their functional code. Granted, there are many Mac apps that are this way too, but the ones that will get praise and recognition are the ones that make the extra effort to design the app around the best interface for the task at hand. In a way, the free OSX IDE Xcode encourages this by making it easy to draw the interface first, and then fill in the functional pieces of code once you've worked out how the user is going to use the app. This is something much more fundamental than the placement of the menu bar, or how the windows stretch, but goes to the heart of designing good applications. While developers on most platforms are content with interfaces that are the most efficient to the way their functional code works, and users are content with trying to wrap their minds around the workings of the program, Mac users encourage that extra effort be made to design an interface that reflects how people work, and what they want to accomplish, rather than merely expose how the application does its thing.
Microsoft has made some attempts to improve themselves in this regard, making a variety of "Wizards" to help "novice" users configure their
The feel of the interface is really a minor part of the development process. To have a rich, standardized set of widgets with a bunch of useful features built into them, along with a nice IDE really makes you a lot more productive as a developer, and gives you a bunch of nice UI features with little effort. It also gives apps a standardized look and feel, which helps users know what to expect just by looking at the interface. The available interface widgets and behaviors have gotten a lot better since 10.2 and especially 10.3, and it's possible to make some great interfaces with relatively little effort, as compared with something like GTK or Qt. You also get nifty features like free spell check in all text fields, windows that remember their size and position between app launches, and a bunch of others too numerous to cite. Development in MacOS X is a dream, once you get a feel for some of the minor peculiarities and bugs in Apple's implementation that need to be worked around.
It's definitely a two-way street, and I'm thankful Apple has added some of the more practical aspects of Windows behavior. I'm not placing any value judgment on the copying of interface behavior from one OS to the other, as it clearly benefits all the users. About the examples you cited, though... The only apps I've seen with menu bars in the app's main window are Java Swing apps, which generally suck ass. I find it a pain to have menus in the app's window, as it takes much more precise mousing to reach them, as opposed to just swinging the mouse upwards to the top of the screen. As for windows being stretched on all sides, I don't think I've seen any being able to do that except X11 windows. All Mac-native apps still have windows that only stretch from the lower right corner, which I don't have any problems with. I usually set the window sizes to an optimal setting for the app and screen resolution, and MacOS X thankfully remembers the settings, so that next time I launch that app, it will always be the right size and position on the screen. Otherwise, the size-to-fit button (kinda the Mac version of maximize, except it automatically goes to the size of the content being displayed) is much, much more practical than other behaviors. I can't stand when app windows take up the whole screen, as I often work between apps, and like to be able to mix windows from different apps in my visible screen space.
Oh, and by the way, Windows 3.1 didn't just suck because it was based on DOS (which did suck hard). It also sucked because it was designed by people with no aesthetic or ergonomic design skills. Windows was hardly usable until 95 came out, by which time it was a fairly decent MacOS copy (no value judgment there). Microsoft still doesn't have a good idea of how to design interfaces to make people's lives easier, but at least the usability for more advanced users who understand how computers and operating systems work is improving (though some of their design changes like extra wizards and crap sure do nothing but get in my way), and stability is greatly improved. I definitely agree that a more compartmentalized OS structure definitely makes things easier, both for the OS maintainers, and for third party developers (especially when many of those components are open source). As an OS developer, you can really get a good grasp of how a particular function is handled, and you can spend your effort improving or replacing certain components with less fear that you're going to break the whole build tree. As a 3rd party developer, by seeing which components you have to interface with, it's much easier to find the best way to do what you want to, especially when those components are standard open source ones, whose functionality is very widely known and documented.
That doesn't make sense. A GUI takes lots more computer resources to achive the same task as a CLI. (i.e. making your program recognize 10 different command-line options is very simple, tiny code in comparasin to the libraries and gui toolkits needed to make those same 10 options appear in a dialog window.)
The graphical interface, while certainly much more resource-intensive than a CLI, was the whole point of the MacOS project. While it probably wouldn't have added much resource usage to add a shell to the MacOS, I guess they feel they didn't need to, as everything was meant to be interacted with graphically from the start, so they just devoted the effort necessary to add that to instead build on the GUI utilities.
I completely agree with you that any marketshare headway in one UNIX is good for the others, as long as they use open standards, which Apple is very good at. I'd say Apple has gotten over their Not Invented Here syndrome, and have learnt to embrace open standards, unless they have to license a closed one if it has significant advantages (as was the case with the whole Sorenson codec for QuickTime fiasco). I definitely believe MacOS X has given a good glimpse of where the various window manager projects for open source OSs are headed (along with installers and general usage for the various OS distros), and they are certainly making progress in that direction. For small market operating systems like MacOS X, nothing could be more advantageous than for the various Linux and BSD distros' market share to rise, as that would mean that open standards would dictate interoperability, thus giving any small market share OSs a much better shot at success than with a closed-source hegemony as we currently have, where one company can dictate the standards and change them on a whim. Mac users shouldn't feel threatened at the prospect of Linux overtaking their market share, as it's not only benefitting them by leveraging open standards, but also most of that market share is at the expense of Windows'.
As open source window managers become more user-friendly, it's obvious that Linux (most likely) or some BSD fork (less likely, but who knows at this point) will become the dominant OS as computers become increasingly commoditized, and that will do nothing but help innovation. My only hope there is that all the Linux distro makers can agree to make some changes to improve some of the idiosyncrasies of Linux's core design. If not, then it just might take some group with the initiative to make another BSD fork to make a more user-friendly core design, hoping they can get enough support. NeXT really did some nice work fixing BSD to make it more sensical, and I can only hope the open source world can have the centralized authority needed to make important changes when necessary. If not, it could really make it hard for developers to support open source OSs. I think a lot of the reason we saw a lot of big names in the open source world take jobs at Apple is because they saw that Apple had the centralized authority to make big decisions for their OS, and it must have been gratifying to see so much progress happening in so little time.
As for open source projects supporting OS X, I have also definitely noticed that trend, and have been very happy to find more and more projects compiling with a simple config, make, make install routine. I've also had the opportunity to submit some improvements back to some projects, and it's great that more people are joining the fun. The only problem is that MacOS X uses a proprietary windowing system and group of widget set frameworks, but it's so much better than the the open source stuff available that it's not worth trying to use open standards for that. It's a real shame Apple doesn't release the Cocoa frameworks and Quartz windowing system under an open source license, as that would really boost its attractiveness for cross-platform development (or actually make it viable rather). Oh well, in the meantime, I still get to have fun in this great development and user environment.
I never implied that Apple had any plans to ever have shell access in any version of the MacOS. Just that Jobs wasn't crazy enough to not have it in NextStep, seeing as how it was derived from BSD. MacOS X is basically NextStep with a few interface changes. The Cocoa (Obj-C development framework most commonly used for MacOS X-native apps) calls still all start with "NS", and every important aspect of the OS still behaves pretty much the same way. It's obvious that Apple didn't change a whole lot when they bought NeXT and turned it into MacOS X. As such, it's not too surprising that they left shell access intact, and it would have been stupid not to. Obviously, Apple couldn't have foreseen their transition to a BSD-derived OS, and the dumping of their entire precious OS into the virtual Trash. The classic MacOS was clearly an unsustainable mess, lacking the sound design and foundation necessary to carry them into the future. What the MacOS did have was excellent interface design. It was obviously revolutionary for its time, and great thought was put into making everything as intuitive and practical for the user as possible. I don't claim to know the real reason why they chose to build up their OS from the ground up without any command-line access, but my guess is that they just wanted to make an entirely graphically-driven platform, as a clean break with what people had taken operating systems to be until then.
Once Jobs left Apple in '85 (only a bit over a year since the Mac was released onto the public), he went on to form NeXT, and with a couple key software engineers like Avie Tevanian and others whose names escape me, decided that their best bet for making a decent OS was to build it on the tried-and-true BSD toolset (which also had the advantage of being released under a license that pretty much said "take our code and do whatever the hell you want with it"). Hence we now have MacOS X with a BSD foundation, including all its shell-access-having glory. It's obvious Apple didn't foresee releasing an OS with a command line after the MacOS, but it wasn't stupid enough to intentionally cripple their next-generation OS by removing it. Thankfully, they still kept their vision of an operating system that could be used in an intuitive, graphical manner, without any knowledge of shell commands. That is the essence of what they were trying to accomplish. I personally think that they would have been better off using BSD from the start and slapping a nice window manager on that, but then you have to realize that the original Macintosh 128k was extremely underpowered, and much of the core system code and display libraries had to be written in assembly just to get acceptable performance. As such, it's a bit easier to understand that they had to start from scratch if they wanted to make a system capable of doing what they wanted at the time.
Apple has on several occasions had the misfortune of being ahead of their time. In order to get the original Macintosh shipping when they did, they had to compromise and build a finely-tuned operating system which wasn't structured with much headroom for the future, and lacked many of the capabilities of modern OSs. The same thing happened with the Newton, where they had to make some compromises in software and price point in order to get them shipping when they did. Microsoft and Palm were in the enviable positions of being able to come in when the time was right (when the technology was sufficiently advanced and cheap enough) and steal Apple's thunder. I think they've gotten better about that problem, and the timing of their release of the iPod was certainly more in accordance with the availability of key technology and the market's readiness. Hopefully they've learned an important lesson from the Macintosh and Newton. In the meantime, it's been a hell of a ride, and I've been loving every minute of it. For now, I'm on a 2x2GHz G5, running the latest version of MacOS X, and I'm in computing nirvana. I've been exploring the UNIX underpinnings of MacOS X since the first public b
The command line is not much closer to the program code than a graphical interface, both need to have methods declared with parameters and user input. The only difference is that the methods and parameters in a graphical interface are all displayed on screen with a more sophisticated interface, typically designed to be intuitive for the task at hand, whereas a command-line executable needs the user to specify the desired methods and parameters, requiring knowledge of how to form arguments the program will accept. It is true that graphical interfaces require more work on the part of the developer, but they will often save work for the end user, especially for complex tasks (some are just impossible to even contemplate achieving in a command-line environment, but graphical application interfaces have been around a lot longer than GUI operating systems to accomplish these tasks). It's not that UNIX is inherently command-line at its core, it just that all the system-level userland tools were implemented for the command line, which is not to say that they couldn't all be re-implemented with graphical interfaces, which is what MacOS X (up to a point) and modern UNIX window managers (up to a lesser point) have done.
It's not desirable, or even practical to have the command line disappear altogether, as there are many tasks that are easier to accomplish in the command line for more experienced users. For scripting, the command line has some very powerful functionality. This is not to say that scripting is impossible for graphical apps. One of the gems of MacOS X is Applescript. Developers often add Applescript hooks to their app methods, parameters and events, so that they can be automated if desired. Even when app developers don't add explicit Applescript support to their apps, there is a beautiful thing called UI scripting which was introduced as beta in MacOS 10.2.x and as release in 10.3.x, which allows scripts to simulate user input, either calling interface elements in all applications explicitly by their names (which you can discover using a small tool called UI Element Inspector), or by simulating mouse clicks and keyboard input. It's a kinda kludgy way to write a script, but if done correctly, works very well. You can also combine Applescripts with shell scripts, and even compiled code to make some very powerful tools. Applescript is similar to Smalltalk, and is quite easy to learn.
As far as programming graphically, the base code of an application doesn't need to be graphical, as that would often be impractical. Instead, in the example of the free Xcode IDE for MacOS X, you write your base functional code as you would in any program (in whatever language you want, they're all supported), and then you draw the interface portion graphically, assigning names to interface elements, which are then called in the code. Actually, it's often easiest to draw the rough interface you want first, giving a good feel for what your app will do, and how it will function, and then fill in the functional code later. This approach allows you to efficiently design your app, keeping the user in mind while developing, yet still allowing you to focus on the functionality underlying it.
You give the example of crontab use in the command line. I use crontab all the time in MacOS X. There's an excellent little freeware utility called Cronnix which provides a nice, intuitive interface for crontab. I use that to launch my routine scripts including reminders, TV show recordings, etc., all of which are written in Applescript or bash scripts, or a mixture of both. There's also a handy tool called folder actions, which allows you to run scripts when something happens to a folder. For example, if I have a folder set up with folder actions, and I access that folder over the network and copy a file to that folder, it can launch a specified script. The power of all this combined is almost limitless. Another great tool well-implemented is Bluetooth support, along with an awesome freeware called Romeo, and my Sony-Ericsson phone. Rom
Obviously, the shell is closer to the OS's engine than the GUI, though it's not really that much closer, since the OS deals with binary code, not ascii user input. In the end, it's just another interface for the same kinds of function calls, just one with less abstraction. Those developers that got frightened away from the Mac due to the extra work involved in making intuitive interfaces for their apps most likely found themselves having to learn the same thing, possibly a bit later, elsewhere, as that's where the market went (largely thanks to Apple's anti-command-line stance). Of course the shell in a UNIX-like operating system such as OS X is very much fundamental to its functionality, since all the tools that make up a UNIX-like OS were meant to be interfaced with via the shell; however Apple (and really NeXT before it) spent a lot of effort beefing up the GUI and adding a bunch of polish to the BSD core to make it more applicable to the general personal computer market. The end result is the (clichéd) best of both worlds, where both novice and advanced users can feel comfortable working with the OS. To most end users, the shell is nothing but a little program called Terminal that allows them to enter a bunch of magical commands, and that's what makes the operating system a success, since it really isn't required to use it.
Getting back to Apple's hypocrisy for first denouncing the shell and later embracing it, I believe that they felt (whether wrong or right) that such a move was necessary to get developers focused on having everything accessible through the GUI. By not giving developers the option to rely on a command line, they made them shift their way of approaching interface development, which ended up having huge repercussions on all software design. Was it really required for the Mac experiment to be successful? Probably not. Did it shrink their market by adding a lot of effort to software development? A case could probably be made for that. I guess they just felt that ideologically, it was central to the Macintosh that everything would be accessed through graphical interaction. While I can understand the reasoning, and I could definitely see the upper management at Apple at the time making such a radical decision, it probably wasn't completely necessary. I think Steve Jobs realized that fact once he moved on to form NeXT, and truly made an ideal OS after years of development; time during which Apple was stuck in its anti-command-line mindset due to marketing concerns. Thankfully, once NeXT was purchased and MacOS X was developed, they weren't insane enough to remove shell access, and along with the excellent frameworks and free development environment, were able to make the most accessible platform for development on the market today. MacOS X just begs to be tinkered with, and along with a userbase that expects (and demands) well-designed interfaces, is the catalyst for some great new software development.
It's easy to say now that it was stupid to ban the command-line just to later admit defeat and come back to it, but understand that the Macintosh was a huge experiment in what the future of computers would be. At the time, I have no doubt that it seemed that only by throwing out the command-line entirely would they be able to make a platform that was entirely accessible to novice computer users. If computers are as easily approachable and widely used as they are today, it's largely thanks to this early experiment, even if it wasn't the best possible solution to general purpose computing (which I'd say MacOS X is pretty close to). It's due to the lack of a command line in the classic MacOS that we now have users that demand that there be visually intuitive interfaces for the tasks they perform on their computers, and therefore a market that sustains GUI app development despite the availability of the command line.
You gotta factor in the cost of the modding and extra hard drive into the xbox as well. Also, the video from the xbox media center is chopped off on all sides, making the subtitles on all my anime unreadable. I have to use my Powerbook to play divx on my TV without hacking off the sides of the image.
Or those damn fansub groups can stop encoding their damn DVD rips with wmv9 video in an AVI container!!! What a pain in the ass that is. Fortunately, most still stick with xvid encoded video. I always let them know in their irc channel when I find content in AVI wmv9 format that I can't play it on a Mac. Hopefully, they'll learn their lesson eventually. Until then, I have to use VirtualPC to reencode the content into divx AVI format.
For the first issue, apps will store their preferences in your home/library/preferences directory. Certain apps might make a new directory in the home/library directory with their app's name. A few more might store items in home/library/application support. I agree it's a bit of a pain to figure out at first, but it's really not too hard to find once you know where to look. Also, most apps that would scatter items in home/library/appname or home/library/application support also come with an installer that doubles as an uninstaller.
As for quitting apps, the virtual memory handler in MacOS X is very efficient, and any app that's not being used is paged out to virtual memory, and won't take up any resources until you start using it again. The only downside to leaving all your apps open is that your Dock can get pretty full. As for key combos, command-Q is very key, along with command-W to close the frontmost window, and command-H to hide the frontmost application. Do yourself a favor and look through the menus in the applications you use. There, you will see commands with the key-combos to execute them the squiggley 4-sided figure means command key (apple key), the arrow pointing up is shift, and the forked horizontal line means option. That will show you what key combo you need to use to use that function. The nice thing about OS X (and this is true of most, but not all 3rd party apps) is that these key combos are usually consistent for all the different apps, thus making them very useful once you learn them. Other notable ones are command-tab to switch between apps, and command-tilde to switch between windows in the frontmost app. I personally don't use Exposé, but have become very proficient at quickly navigating to the window I want using these shortcuts, along with clicking on the dock icon for the app I want, and right-clicking on an open app to select the particular window I want if it's not the frontmost one. One thing I would recommend would be to get a nice multi-button + scroll wheel USB mouse (any USB mouse will do) for the Mac you're using, as OSX is much more usable that way, and Apple should be punished for only offering lousy 1-button mice with their computers (this is especially troublesome for their laptops, not really an issue for their desktops).
Slashdot Mirror
No idea if there's any truth to Russian organized crime connections to Allofmp3.com, but at least the Russian mafia won't use my money to buy out my politicians to restrict my rights, whereas the RIAA does. As such, I'm much more comfortable giving my money to Russian organized crime than to the RIAA.
Adblock for Safari (but better): Pithhelmet
DVD Player complaining about regions: Set your drive's region to the region you live in, and it should mostly never ask you that again
Package management: DarwinPorts
That's only useful because of the way application windows in Windows work. Once you get used to working on a Mac, you'll find that you don't want applications to take over your entire screen, and that working in between apps is much, much easier. It's so much nicer to have apps remember two window sizes you set (typically one large format, and one small format), and have the "maximize" button toggle between the two. The menubar at the top of the window is also crucial for working between apps, as individual windows in an application no longer have to be contained within a big application window, allowing you to switch back and forth between windows in different apps much more efficiently. This alone makes complex workflows (those involving multiple apps) in Windows a pain in the ass. From a workflow perspective, once you're intimate with MacOS X and Windows (intimacy being the key term), I have yet to meet someone who doesn't prefer working in OSX. It does take a while to get used to working the new way, but once you do, you'll never want to go back.
Fairplay doesn't have the capability to expire songs once you stop paying for the subscription. WMA's Janus extension is required for this functionality, which has the player check that you are supposed to have access to those songs each time you plug it into your computer, and expires songs after a month if you don't let it verify. While this nasty little system works, it introduces requirements that some may find objectionable. Simply licensing Fairplay isn't going to get you access to subscription-based content. Basically, if you want subscription content on the iPod, you're SOL, but you should have known that when you bought it.
What's more interesting here is that Apple is turning down a potential revenue source (licensing Fairplay to CD distributors) for no other reason than what appears to be the belief that they have enough control over the digital music market to influence the direction of CD distribution as well. It seems they are making a stand to make copy-protected CDs impractical, hoping that distributors will instead keep producing standard CDs. Personally, I am very happy they are doing this, as copy-protected CDs are an incredibly stupid idea that only serves to inconvenience paying customers. I don't buy music from the big labels anymore, so I've never encountered copy protection, but you can be sure I would demand a refund if I was unable to use my purchased CDs as I see fit (within the confines of copyrights). Having Fairplay copies of the music on the CD as well wouldn't alleviate this problem, as I want to rip my CDs to MP3 format, in the bitrate of my choosing. In this case, Sony is clearly wrong, and they need to go back to making standard CDs if they want to sell to iPod users.
One playlist of protected audio tracks can only be burnt 7 times. After that, you'll need to alter the playlist somehow.
Probably if they have a lot of carry-on to stow, or want to secure newspapers, magazines or pillows/blankets before they're all taken. Also, if you have an inside seat, it's easier if you get there before the person sitting in the aisle. If you have little carry-on, and/or you have an aisle seat, then it would be dumb to try to get in early.
Back to the topic of human stupidity, driving is by far the worst view of it. I don't mind fast drivers when traffic is light, having to navigate their way through left lane campers, but those who try to bust crazy moves in thick traffic for some insignificant placement advance are the worst. It's the kind of behavior that leads to accidents, just like this iMob incident; though that was exaggerated due to the unreasonably low offering price of the iBooks, creating significant profit opportunity for those who could buy them (and there's no better motivator than free money).
I'm glad they don't, as strong DRM is the worst thing that could happen. Just like setting up a network of surveillance cameras that covers every bit of space would be a terrible thing, as it would take away our freedom. The reason why it's tolerable to have such an abundance of laws is because you don't get in trouble each time you break them, usually only if something bad happens as a result. With media, people should be free to control how they personally use the media they purchase, including which devices they wish to play it with, as well as converting it to a compatible format. If there is piracy as a result of this freedom, then that is a civil or criminal matter between the copyright holder and the violator. That doesn't mean that everyone should be locked down just to prevent any possible infringing use. The customer and the violator are typically two different people, and treating them as one is a good way to lose all your customers.
What Microsoft is offering is an absolute lock, which is too much power to place in the hands of content creators. Obviously a pirate can just hook up an analog recording device to the speaker outputs, or find a way to patch video to an analog capture device, and the content will get out regardless. But the controls in place prevent me, the honest customer who pays for content when available, from using the content I purchase on devices I own, since I'm unable to convert to standard formats.
Apple's iTMS is no better, forcing you to install hacks or burn to CD and then rip to MP3 in order to use the content as expected, and so I don't use that either, though it is a far cry from the mess with Windows Media DRM. I will never purchase digital content that can't be converted to other formats. I buy CDs because I can rip them and use them with my MP3 players or make copies for my car. I buy DVDs because I can rip them and make copies to preserve the originals or convert them to formats that play on various devices or take up less HD space. If I were to lose this power, I wouldn't pay for any content. DRM is really a stupid way of trying to move to a digital distribution model, as it only pisses off the people you're trying to sell to, and doesn't prevent the content from showing up on P2P. Content creators are going to have to realize that they need to give up control over the customer, and rely on convenience, availability, marketing, law suits and common decency to sell their products. I want to buy content, I just won't do it if I can't have control over how I use it.
There are 68k emulators for x86, such as Basilisk II, which can run MacOS 7.6.1 well, and 8.0 unstably. There are also PPC emulators for x86, such as PearPC and QEmu, which are progressing nicely, and should at least let you run your old OS 9 apps. With this transition will come much greater demand for these products, boosting the attention and devotion they receive, and hopefully enabling you to access your old data and binaries without too much trouble. OSX PPC apps are taken care of with Rosetta, and I'm sure most active developers will be releasing universal binaries of their apps pretty promptly after (or even before) the x86 Macs start shipping (at least the Cocoa devs). I really don't think the situation is as hopeless as it may appear to you, and if you still have a PPC Mac available, you can always use that to convert old data to usable formats.
I know Verizon does the same thing, so that they can sell you ringtones and graphics, and charge you for data transfers with the data plans. Since I got AT&T (now Cingular) I'm able to transfer sounds (ringtones) pictures and themes over BlueTooth (USB optional) to my computer without hassle. That alone is worth getting Cingular (the excellent nationwide coverage, kick-ass GSM phones and rollover minutes are also nice). The only thing you can't transfer directly to the computer is the games. US Cellular is quite possibly the most user-hostile provider in existence, not to mention being expensive and using the crappy CDMA network and phones.
That will be more than adequate. You wouldn't lose any quality if you went with the 1.25 GHz and 512 MB RAM. The only issue is the limited HD (size and speed), so you won't want to use the mini's HD for anything else while the capturing is going on. Also, if you choose to get a FireWire hard drive later on, make sure you do NOT capture from your FireWire camera to the FireWire hard drive on the same bus, as it would result in lost frames and poor performance (since the incoming video needs to be buffered in RAM before being sent to the HD, causing two simultaneous transfers over the single FW bus). An external drive would be fine for acting as a repository once you've got the content captured already. I would definitely go for the 80 GB drive if you plan on working with a lot of video, and the only place you might notice a performance improvement in bumping it up to 1.42 GHz and 1 GB RAM would be in the encoding to DVD format process if you plan on doing that.
Just wanted to note that the iBook uses a G4 as well, and with a firmware hack, can do monitor spanning as the PowerBook does, though albeit without being able to drive the same resolution levels, as the video card is significantly weaker.
Use Romeo instead. It's free and has more nifty features, as well as 3rd party plugins (which are easy as pie to make yourself).
That is, until they come out with higher definition video... /me shakes his fist...
There are always the $20 USB bluetooth adapters (which are all compatible with OSX)... that's what I did.
This conversation has gotten a bit dated, but I just want to say that users work differently in the MacOS than they do in Windows and KDE or Gnome. To have the menu in the App's main window, or generally not behave like other Mac apps is grounds for a lynching in these parts. Personally, I prefer the way Mac apps behave, and I'm most productive that way. I definitely understand that it would be nice to have apps behave the same in different OSs (and you can run your favorite X11 window manager on top of OSX, as long as you don't care about most regular commercial apps), but Mac users will never accept native apps behaving like Windows or KDE/Gnome apps, and vice-versa, so there's no easy solution to a cross-platform widget set. Java Swing apps can sort of approach this by having things like the menu bar being optionally in the main window or the top of the screen, and I believe some Qt interpreters for OSX can build apps that behave like native Mac apps if desired. The problem is they're missing a lot of nifty features present in Cocoa, including a huge wealth of NS frameworks and UI calls. OpenStep might one day become a sort of answer to that, but without official support from Apple, I have a hard time believing we'll ever see the ability to compile one code tree for MacOS X and BSD or Linux, let alone Windows. Until then, there will always be a need to port your large OSS projects like Gimp or OO to Cocoa, as is being done now, just for the sake of widespread adoption; but you won't have your unified interface for all platforms, and interface advancements for those projects on one platform won't make it to the others without additional porting work. I guess it can't be helped. In the meantime, I'm having a blast in this happy marriage of UNIX and centralized authority and vision, along with the brilliance that was NextStep.
The extremely picky user base also pushes us developers to really work hard to make interfaces as innovative and intuitive as possible, and rewards us greatly when we make that effort. Even if we have to spend more time than we'd like coding and recoding the interface, if it make the app more accessible and efficient for our users, then it's all worth it in the end. The care that Apple put into making the interface of its OS and apps be as intuitive and efficient as possible has really raised the bar for what a good Mac app needs to be in order to be accepted and praised by its users. This, in turn, empowers the users to accomplish tasks that they would be hesitant to attempt with the tools available on other platforms (due to a general lack of design skills, both in supply and demand), and increases everyone's productivity and expertise.
I also like the interface to be optimized to the task at hand, but the sad truth seems to be that most developers on other platforms seem to think that the interface is just an afterthought that's bolted onto their functional code. Granted, there are many Mac apps that are this way too, but the ones that will get praise and recognition are the ones that make the extra effort to design the app around the best interface for the task at hand. In a way, the free OSX IDE Xcode encourages this by making it easy to draw the interface first, and then fill in the functional pieces of code once you've worked out how the user is going to use the app. This is something much more fundamental than the placement of the menu bar, or how the windows stretch, but goes to the heart of designing good applications. While developers on most platforms are content with interfaces that are the most efficient to the way their functional code works, and users are content with trying to wrap their minds around the workings of the program, Mac users encourage that extra effort be made to design an interface that reflects how people work, and what they want to accomplish, rather than merely expose how the application does its thing.
Microsoft has made some attempts to improve themselves in this regard, making a variety of "Wizards" to help "novice" users configure their
The feel of the interface is really a minor part of the development process. To have a rich, standardized set of widgets with a bunch of useful features built into them, along with a nice IDE really makes you a lot more productive as a developer, and gives you a bunch of nice UI features with little effort. It also gives apps a standardized look and feel, which helps users know what to expect just by looking at the interface. The available interface widgets and behaviors have gotten a lot better since 10.2 and especially 10.3, and it's possible to make some great interfaces with relatively little effort, as compared with something like GTK or Qt. You also get nifty features like free spell check in all text fields, windows that remember their size and position between app launches, and a bunch of others too numerous to cite. Development in MacOS X is a dream, once you get a feel for some of the minor peculiarities and bugs in Apple's implementation that need to be worked around.
It's definitely a two-way street, and I'm thankful Apple has added some of the more practical aspects of Windows behavior. I'm not placing any value judgment on the copying of interface behavior from one OS to the other, as it clearly benefits all the users. About the examples you cited, though... The only apps I've seen with menu bars in the app's main window are Java Swing apps, which generally suck ass. I find it a pain to have menus in the app's window, as it takes much more precise mousing to reach them, as opposed to just swinging the mouse upwards to the top of the screen. As for windows being stretched on all sides, I don't think I've seen any being able to do that except X11 windows. All Mac-native apps still have windows that only stretch from the lower right corner, which I don't have any problems with. I usually set the window sizes to an optimal setting for the app and screen resolution, and MacOS X thankfully remembers the settings, so that next time I launch that app, it will always be the right size and position on the screen. Otherwise, the size-to-fit button (kinda the Mac version of maximize, except it automatically goes to the size of the content being displayed) is much, much more practical than other behaviors. I can't stand when app windows take up the whole screen, as I often work between apps, and like to be able to mix windows from different apps in my visible screen space.
Oh, and by the way, Windows 3.1 didn't just suck because it was based on DOS (which did suck hard). It also sucked because it was designed by people with no aesthetic or ergonomic design skills. Windows was hardly usable until 95 came out, by which time it was a fairly decent MacOS copy (no value judgment there). Microsoft still doesn't have a good idea of how to design interfaces to make people's lives easier, but at least the usability for more advanced users who understand how computers and operating systems work is improving (though some of their design changes like extra wizards and crap sure do nothing but get in my way), and stability is greatly improved. I definitely agree that a more compartmentalized OS structure definitely makes things easier, both for the OS maintainers, and for third party developers (especially when many of those components are open source). As an OS developer, you can really get a good grasp of how a particular function is handled, and you can spend your effort improving or replacing certain components with less fear that you're going to break the whole build tree. As a 3rd party developer, by seeing which components you have to interface with, it's much easier to find the best way to do what you want to, especially when those components are standard open source ones, whose functionality is very widely known and documented.
That doesn't make sense. A GUI takes lots more computer resources to achive the same task as a CLI. (i.e. making your program recognize 10 different command-line options is very simple, tiny code in comparasin to the libraries and gui toolkits needed to make those same 10 options appear in a dialog window.)
The graphical interface, while certainly much more resource-intensive than a CLI, was the whole point of the MacOS project. While it probably wouldn't have added much resource usage to add a shell to the MacOS, I guess they feel they didn't need to, as everything was meant to be interacted with graphically from the start, so they just devoted the effort necessary to add that to instead build on the GUI utilities.
I completely agree with you that any marketshare headway in one UNIX is good for the others, as long as they use open standards, which Apple is very good at. I'd say Apple has gotten over their Not Invented Here syndrome, and have learnt to embrace open standards, unless they have to license a closed one if it has significant advantages (as was the case with the whole Sorenson codec for QuickTime fiasco). I definitely believe MacOS X has given a good glimpse of where the various window manager projects for open source OSs are headed (along with installers and general usage for the various OS distros), and they are certainly making progress in that direction. For small market operating systems like MacOS X, nothing could be more advantageous than for the various Linux and BSD distros' market share to rise, as that would mean that open standards would dictate interoperability, thus giving any small market share OSs a much better shot at success than with a closed-source hegemony as we currently have, where one company can dictate the standards and change them on a whim. Mac users shouldn't feel threatened at the prospect of Linux overtaking their market share, as it's not only benefitting them by leveraging open standards, but also most of that market share is at the expense of Windows'.
As open source window managers become more user-friendly, it's obvious that Linux (most likely) or some BSD fork (less likely, but who knows at this point) will become the dominant OS as computers become increasingly commoditized, and that will do nothing but help innovation. My only hope there is that all the Linux distro makers can agree to make some changes to improve some of the idiosyncrasies of Linux's core design. If not, then it just might take some group with the initiative to make another BSD fork to make a more user-friendly core design, hoping they can get enough support. NeXT really did some nice work fixing BSD to make it more sensical, and I can only hope the open source world can have the centralized authority needed to make important changes when necessary. If not, it could really make it hard for developers to support open source OSs. I think a lot of the reason we saw a lot of big names in the open source world take jobs at Apple is because they saw that Apple had the centralized authority to make big decisions for their OS, and it must have been gratifying to see so much progress happening in so little time.
As for open source projects supporting OS X, I have also definitely noticed that trend, and have been very happy to find more and more projects compiling with a simple config, make, make install routine. I've also had the opportunity to submit some improvements back to some projects, and it's great that more people are joining the fun. The only problem is that MacOS X uses a proprietary windowing system and group of widget set frameworks, but it's so much better than the the open source stuff available that it's not worth trying to use open standards for that. It's a real shame Apple doesn't release the Cocoa frameworks and Quartz windowing system under an open source license, as that would really boost its attractiveness for cross-platform development (or actually make it viable rather). Oh well, in the meantime, I still get to have fun in this great development and user environment.
I never implied that Apple had any plans to ever have shell access in any version of the MacOS. Just that Jobs wasn't crazy enough to not have it in NextStep, seeing as how it was derived from BSD. MacOS X is basically NextStep with a few interface changes. The Cocoa (Obj-C development framework most commonly used for MacOS X-native apps) calls still all start with "NS", and every important aspect of the OS still behaves pretty much the same way. It's obvious that Apple didn't change a whole lot when they bought NeXT and turned it into MacOS X. As such, it's not too surprising that they left shell access intact, and it would have been stupid not to. Obviously, Apple couldn't have foreseen their transition to a BSD-derived OS, and the dumping of their entire precious OS into the virtual Trash. The classic MacOS was clearly an unsustainable mess, lacking the sound design and foundation necessary to carry them into the future. What the MacOS did have was excellent interface design. It was obviously revolutionary for its time, and great thought was put into making everything as intuitive and practical for the user as possible. I don't claim to know the real reason why they chose to build up their OS from the ground up without any command-line access, but my guess is that they just wanted to make an entirely graphically-driven platform, as a clean break with what people had taken operating systems to be until then.
Once Jobs left Apple in '85 (only a bit over a year since the Mac was released onto the public), he went on to form NeXT, and with a couple key software engineers like Avie Tevanian and others whose names escape me, decided that their best bet for making a decent OS was to build it on the tried-and-true BSD toolset (which also had the advantage of being released under a license that pretty much said "take our code and do whatever the hell you want with it"). Hence we now have MacOS X with a BSD foundation, including all its shell-access-having glory. It's obvious Apple didn't foresee releasing an OS with a command line after the MacOS, but it wasn't stupid enough to intentionally cripple their next-generation OS by removing it. Thankfully, they still kept their vision of an operating system that could be used in an intuitive, graphical manner, without any knowledge of shell commands. That is the essence of what they were trying to accomplish. I personally think that they would have been better off using BSD from the start and slapping a nice window manager on that, but then you have to realize that the original Macintosh 128k was extremely underpowered, and much of the core system code and display libraries had to be written in assembly just to get acceptable performance. As such, it's a bit easier to understand that they had to start from scratch if they wanted to make a system capable of doing what they wanted at the time.
Apple has on several occasions had the misfortune of being ahead of their time. In order to get the original Macintosh shipping when they did, they had to compromise and build a finely-tuned operating system which wasn't structured with much headroom for the future, and lacked many of the capabilities of modern OSs. The same thing happened with the Newton, where they had to make some compromises in software and price point in order to get them shipping when they did. Microsoft and Palm were in the enviable positions of being able to come in when the time was right (when the technology was sufficiently advanced and cheap enough) and steal Apple's thunder. I think they've gotten better about that problem, and the timing of their release of the iPod was certainly more in accordance with the availability of key technology and the market's readiness. Hopefully they've learned an important lesson from the Macintosh and Newton. In the meantime, it's been a hell of a ride, and I've been loving every minute of it. For now, I'm on a 2x2GHz G5, running the latest version of MacOS X, and I'm in computing nirvana. I've been exploring the UNIX underpinnings of MacOS X since the first public b
The command line is not much closer to the program code than a graphical interface, both need to have methods declared with parameters and user input. The only difference is that the methods and parameters in a graphical interface are all displayed on screen with a more sophisticated interface, typically designed to be intuitive for the task at hand, whereas a command-line executable needs the user to specify the desired methods and parameters, requiring knowledge of how to form arguments the program will accept. It is true that graphical interfaces require more work on the part of the developer, but they will often save work for the end user, especially for complex tasks (some are just impossible to even contemplate achieving in a command-line environment, but graphical application interfaces have been around a lot longer than GUI operating systems to accomplish these tasks). It's not that UNIX is inherently command-line at its core, it just that all the system-level userland tools were implemented for the command line, which is not to say that they couldn't all be re-implemented with graphical interfaces, which is what MacOS X (up to a point) and modern UNIX window managers (up to a lesser point) have done.
It's not desirable, or even practical to have the command line disappear altogether, as there are many tasks that are easier to accomplish in the command line for more experienced users. For scripting, the command line has some very powerful functionality. This is not to say that scripting is impossible for graphical apps. One of the gems of MacOS X is Applescript. Developers often add Applescript hooks to their app methods, parameters and events, so that they can be automated if desired. Even when app developers don't add explicit Applescript support to their apps, there is a beautiful thing called UI scripting which was introduced as beta in MacOS 10.2.x and as release in 10.3.x, which allows scripts to simulate user input, either calling interface elements in all applications explicitly by their names (which you can discover using a small tool called UI Element Inspector), or by simulating mouse clicks and keyboard input. It's a kinda kludgy way to write a script, but if done correctly, works very well. You can also combine Applescripts with shell scripts, and even compiled code to make some very powerful tools. Applescript is similar to Smalltalk, and is quite easy to learn.
As far as programming graphically, the base code of an application doesn't need to be graphical, as that would often be impractical. Instead, in the example of the free Xcode IDE for MacOS X, you write your base functional code as you would in any program (in whatever language you want, they're all supported), and then you draw the interface portion graphically, assigning names to interface elements, which are then called in the code. Actually, it's often easiest to draw the rough interface you want first, giving a good feel for what your app will do, and how it will function, and then fill in the functional code later. This approach allows you to efficiently design your app, keeping the user in mind while developing, yet still allowing you to focus on the functionality underlying it.
You give the example of crontab use in the command line. I use crontab all the time in MacOS X. There's an excellent little freeware utility called Cronnix which provides a nice, intuitive interface for crontab. I use that to launch my routine scripts including reminders, TV show recordings, etc., all of which are written in Applescript or bash scripts, or a mixture of both. There's also a handy tool called folder actions, which allows you to run scripts when something happens to a folder. For example, if I have a folder set up with folder actions, and I access that folder over the network and copy a file to that folder, it can launch a specified script. The power of all this combined is almost limitless. Another great tool well-implemented is Bluetooth support, along with an awesome freeware called Romeo, and my Sony-Ericsson phone. Rom
Obviously, the shell is closer to the OS's engine than the GUI, though it's not really that much closer, since the OS deals with binary code, not ascii user input. In the end, it's just another interface for the same kinds of function calls, just one with less abstraction. Those developers that got frightened away from the Mac due to the extra work involved in making intuitive interfaces for their apps most likely found themselves having to learn the same thing, possibly a bit later, elsewhere, as that's where the market went (largely thanks to Apple's anti-command-line stance). Of course the shell in a UNIX-like operating system such as OS X is very much fundamental to its functionality, since all the tools that make up a UNIX-like OS were meant to be interfaced with via the shell; however Apple (and really NeXT before it) spent a lot of effort beefing up the GUI and adding a bunch of polish to the BSD core to make it more applicable to the general personal computer market. The end result is the (clichéd) best of both worlds, where both novice and advanced users can feel comfortable working with the OS. To most end users, the shell is nothing but a little program called Terminal that allows them to enter a bunch of magical commands, and that's what makes the operating system a success, since it really isn't required to use it.
Getting back to Apple's hypocrisy for first denouncing the shell and later embracing it, I believe that they felt (whether wrong or right) that such a move was necessary to get developers focused on having everything accessible through the GUI. By not giving developers the option to rely on a command line, they made them shift their way of approaching interface development, which ended up having huge repercussions on all software design. Was it really required for the Mac experiment to be successful? Probably not. Did it shrink their market by adding a lot of effort to software development? A case could probably be made for that. I guess they just felt that ideologically, it was central to the Macintosh that everything would be accessed through graphical interaction. While I can understand the reasoning, and I could definitely see the upper management at Apple at the time making such a radical decision, it probably wasn't completely necessary. I think Steve Jobs realized that fact once he moved on to form NeXT, and truly made an ideal OS after years of development; time during which Apple was stuck in its anti-command-line mindset due to marketing concerns. Thankfully, once NeXT was purchased and MacOS X was developed, they weren't insane enough to remove shell access, and along with the excellent frameworks and free development environment, were able to make the most accessible platform for development on the market today. MacOS X just begs to be tinkered with, and along with a userbase that expects (and demands) well-designed interfaces, is the catalyst for some great new software development.
It's easy to say now that it was stupid to ban the command-line just to later admit defeat and come back to it, but understand that the Macintosh was a huge experiment in what the future of computers would be. At the time, I have no doubt that it seemed that only by throwing out the command-line entirely would they be able to make a platform that was entirely accessible to novice computer users. If computers are as easily approachable and widely used as they are today, it's largely thanks to this early experiment, even if it wasn't the best possible solution to general purpose computing (which I'd say MacOS X is pretty close to). It's due to the lack of a command line in the classic MacOS that we now have users that demand that there be visually intuitive interfaces for the tasks they perform on their computers, and therefore a market that sustains GUI app development despite the availability of the command line.
You gotta factor in the cost of the modding and extra hard drive into the xbox as well. Also, the video from the xbox media center is chopped off on all sides, making the subtitles on all my anime unreadable. I have to use my Powerbook to play divx on my TV without hacking off the sides of the image.
Or those damn fansub groups can stop encoding their damn DVD rips with wmv9 video in an AVI container!!! What a pain in the ass that is. Fortunately, most still stick with xvid encoded video. I always let them know in their irc channel when I find content in AVI wmv9 format that I can't play it on a Mac. Hopefully, they'll learn their lesson eventually. Until then, I have to use VirtualPC to reencode the content into divx AVI format.
For the first issue, apps will store their preferences in your home/library/preferences directory. Certain apps might make a new directory in the home/library directory with their app's name. A few more might store items in home/library/application support. I agree it's a bit of a pain to figure out at first, but it's really not too hard to find once you know where to look. Also, most apps that would scatter items in home/library/appname or home/library/application support also come with an installer that doubles as an uninstaller.
As for quitting apps, the virtual memory handler in MacOS X is very efficient, and any app that's not being used is paged out to virtual memory, and won't take up any resources until you start using it again. The only downside to leaving all your apps open is that your Dock can get pretty full. As for key combos, command-Q is very key, along with command-W to close the frontmost window, and command-H to hide the frontmost application. Do yourself a favor and look through the menus in the applications you use. There, you will see commands with the key-combos to execute them the squiggley 4-sided figure means command key (apple key), the arrow pointing up is shift, and the forked horizontal line means option. That will show you what key combo you need to use to use that function. The nice thing about OS X (and this is true of most, but not all 3rd party apps) is that these key combos are usually consistent for all the different apps, thus making them very useful once you learn them. Other notable ones are command-tab to switch between apps, and command-tilde to switch between windows in the frontmost app. I personally don't use Exposé, but have become very proficient at quickly navigating to the window I want using these shortcuts, along with clicking on the dock icon for the app I want, and right-clicking on an open app to select the particular window I want if it's not the frontmost one. One thing I would recommend would be to get a nice multi-button + scroll wheel USB mouse (any USB mouse will do) for the Mac you're using, as OSX is much more usable that way, and Apple should be punished for only offering lousy 1-button mice with their computers (this is especially troublesome for their laptops, not really an issue for their desktops).