I read it. And I understand it. My comment is based on the following points:
1. Despite their using OpenOffice, their standard file format is still MS Office-compatible at least for word processing. Further, interoperability with the school division and the rest of the world dictates that.doc, xls, ppt and friends are all still their standard formats, despite using open office.
2. At this point their number one costs are hardware. If MS steps in and helps out in that area, providing extremely discounted hardware deals though MS-friendly distributors, the cost factor does not have anything to do with software cost at this point. It's all hardware and they would be foolish to not take the better hardware deal despite moving back to MS's software. From MS's POV this is free lock-in. If MS can give them a deal that is cheaper than buying normal hardware for their linux infrastructure, and throw in MS software for free, then from an economic point of view it does not make sense to remain with linux. This is how MS works. We've seen it time and time again.
My main point is that MS will not sit by and let these kinds of things happen.
Precisely. In just a couple of years the school will yet again need to buy new hardware and probably upgrade some servers. At this time, MS can come in with a great, almost-free deal to lock them back into Windows that they can't afford to refuse. And they would be fools to turn it down. While this may seem immoral to you and I on slashdot, in the eyes of MS this is no more immoral than the OSS camp "dumping" their software for next to nothing.
This is surely true, although Apple apparently does not think so. Recently I received two e-mails from Apple's development team regarding bug reports that I and others have filed for Panther Server regarding critical OpenLDAP bugs. In a nutshell the e-mails said, "we think the bugs don't exist in Tiger Server. Please upgrade to Tiger Server and tell us if this is the case." I was stunned. I sent them a strongly worded response to tell them that this was not acceptable. Apple just doesn't yet understand what it takes to produce Enterprise software. We need very long support lifetimes (3-5 years minimum) and upgrading major OS versions outside of normal hardware replacement cycles (with proper testing) is *never* done except in extraordinary circumstances. Right now I am very unhappy with Apple. Does anyone even know what the life expentancy of Panther Server is? What about Tiger? I can't find this information anywhere and Apple has not yet responded to my queries. Judging by the terrible LDAP problems I had with OS 10.3 (not fixed until 10.3.9!) I am in no hurry to put Tiger Server into production. I learned my lesson the hard way.
Now that AFP support under linux is much better, I'm almost certainly going to go back to Linux for my main file servers. At least it is a known quantity.
While the version number of samba is old now, the critical bug fixes (security mainly) are backported by redhat. So I don't worry too much security-wise about things like this.
I agree that roundup is the safest herbicide out there.
But when these roundup ready genes escape into nature (and they do), we end up creating a super weed. In agriculture right now, herbicide resistance is a huge deal.
At the end of the day monsanto cares more about furthering the short-term bottom line than they do about at environment or the farmers.
NeoOffice is not a fork; it is a Mac OS X port. They (2 developers) work hard to keep it in sync with the mainline tree. Should development on OO.org stop, NeoOffice will wither and die also.
Hmm, you mean like how gcj produces native java executables that are faster than running bytecode in the JVM? Oh wait. No it's slower. One of the main facets of.NET and Mono, though, is the ability to precompile the binaries to speed up loading (but not running). The thing about running code in the JVM and the CLR is that programs slowly get faster and faster as the jitter tweaks the optimizations and caches them.
Therefore I don't see any real point to producing native executables. Heck you don't even see to many people clamoring for a perl native compiler or a python native compiler. Although they exist most people simply don't need them. The future is in languages like Python, Perl, C#, Java. Bytecode compiled or even straight interpreted languages are really coming of age. The bare underlying hardware is becoming less and less relevant.
Copyright can never dictate to you how you personally use the copyrighted work. You can read it, scribble on it, destroy it or whatever. But you cannot distribute the work; copyright law grants you no such privilege. The GPL is a license that extends your rights over a work so that you can distribute the work to others. Thus the GPL says nothing about use.
In the case of digitally restricted audio CDs, the software is attempting to artificially restrict personal fair use using technicalities provided by the DMCA. Because theses mechanisms are declared as "copy protection"--which they arent'--the DMCA then punishes those who circumvent these mechanisms with criminal penalties. Having an unencumbered personal copy of the work is not a crime, though. It's a neat way to sidestep the fair use rights of end users on the part of the copyright holders, though. I think I can say with all sincerity that copyright holders who artificially restrict the use of their work beyond the allowances of normal, sane copyright law are not respecting the nature of copyright or the intent for which such laws exist.
Fedora as a desktop distribution is one thing, but after running Fedora Core 1 on my linode web server, I will never run fedora on a server again. A 6 month lifespan is simply way too short. From now on I'll be using CentOS on my linode. In fact, for desktop machines I'd even considuer CentOS since the lifespan of CentOS is 5 years or so.
So I can believe that RHEL or a RHEL compatible distro would be increasing in popularity, but I have a hard time believing Fedora would be appropriate for such situations.
Actually if we could just produce a 100% reflective, paper display (digital ink) we could save a lot of energy while still having a display that looked good under normal lighting situations, including full sunlight. I think that purely luminous displays are hard on the eyes. I'd adopt digital books in a hartbeat when you can give me a surface that looks just like paper (or glossy magazine stock) with 300-600 dpi electronic ink resolution. If lighting conditions are low, just add a reading light like a normal book.
Yeah you'd think that would be the case. The source files are available but I have yet to get them to build. They also have heavily hacked OpenLDAP without separating their changes out into patches. Thus using a newer version of OpenLDAP, for example, is almost impossible. I'm going to start talking to the OpenDarwin folks about building these things.
So far, sadly, Apple indeed uses open source components and release much of their source, but they are not open in most senses of the word. There are no mailing lists where I can really have a dialog with other Apple server users *and* Apple engineers. I can't even access an open bugs list like I can with their closest enterprise competitor, RedHat.
So it is possible to use completely open source products together in a way that ofuscates (either intentionally or just from lack of documentation) how things fit together such that really modifying or fixing things is difficult. I guess the main thing that is missing is documentation. Apple has next to no documentation on the guts of the system. There is no record of how and why they have modified OpenLDAP, no information on the protcols (message-passing and tcp/ip) used by OpenDirectory (DirectoryService and PasswordService to be specific) other than ldap which only forms a part of the system. In fact after studying the system for over a year I'm still not sure exactly how the system fits together and what the service depedencies are in OpenDirectory.
Having used OpenDirectory for a year and half, I can say that it is too buggy for enterprise use. There seem to be problems with the OpenLDAP and PasswordService integration in OpenDirectory. OpenLDAP crashes hard very frequently and often the entire OS X system (due to the way DirectoryService works) is made complete unresponsive. Apple is aware of the bugs and how to reproduce them but so far has done nothing. The current rumors are that these bugs (or bug) will be fixed in Tiger. That is simply not acceptable for enterprise software. Current bug numbers (ticket numbers) that Apple has assigned this problem are 3966561, 3725081, and 3549410.
The irony is that OpenDirectory is awesome! We should be actively porting the architecture to linux. The problems I've described above are not inherent design flaws, but rather specific Apple implementation bugs on OS X. I know on Linux this stuff would work wonderfully. OpenLDAP forms a key component of this architecture but it's only the authorization component. OpenDirectory provides a unified SASL/Kerberos password store that does authentication in a unified way (and syncs passwords for samba, md5, etc)
Given this discouraging situation, I'd stick to Active Directory if I were you for now.
Why? No one installs OpenOffice that way on Linux. It's all about packages the distributor ships. Moving Openoffice to packages is the way to go. I do think they should make fewer packages, though.
I use Adobe Reader 7 beta for linux every day. looks good, works great. It's basically built out of GTK. Or at least it adopts the gtk theme pretty well.
It's very simple. You own the copyright to your own code. Therefore you don't need *any* license to use your code. The GPL only applies to those who use your code who don't own the copyright. Of course when you are the copyright holder you can license the code under any terms at any time to anyone.
Your comments represent a fairly widespread misunderstanding of licensing and copyright in general. MS and others like to play up on this misunderstanding to make you think that GPLing your code somehow magically prevents you from using your code in a commercial fashion, even closed source. It simply cannot.
Many people refer to this as "dual-licensing" meaning you can use my code under the terms of the GPL or negotiate an alternative license.
The only way to really remove a root kit on any operating system (linux, unix, windows, etc) is to do a format and reinstall of the OS. This is unlikely to ever change for any operating system. Except for maybe trusted computing...
The irony is that it is the lack of these nice eye-candy features that actually make X feel so slow. The new improvements to X rendering that make the eye candy possible also make X appear faster. double-buffering, synchronized resizes, etc.
X is already very fast. It's the perception of speed that's critical, though, and X11 (or rather the widget sets and their lack of drawing synchronization) does appear to feel more sluggish even though it is not.
For example, the GUI feels silky smooth on my powerbook. dragging windows, expose, etc. Howevver if you really measure things, the gui on OS X can sometimes be very sluggish and slow. But it appears fast because it is so smooth. Interesting.
I don't think the lack of interest in enlightmentment is indicative of NIH syndrome. Rather enlightenment has always been off on its own. Owen and crew are working to not only bring about eye candy but implement standards that everyone follow to make better rendering work for all apps and window managers.
No hydrogen won't help anything in Korea. Hydrogen is not a fuel source anymore than electricity is an energy source. At best it is an inefficient way of storying energy generated by fossil fuels. This it doesn't solve anything. Hydrogen isn't naturally found anywhere. It will never be commercially successful because it is inefficient and does not make economic sense. That is the sad fact. The future is in biological, organically created fuel oils. That's much more efficient if we can get a natural process (say algae) to turn carbon dioxide in the air into diesel fuel using the power of the sun. This is actually efficient and sustainable.
The qemu claims are accurate. I am currently using this module with qemu and find that I do get 60-70% native speed (just as he advertises) and it is only going to get better. mind you this is x86 on x86. I/O performance (just like on vmware) is still a pig.
Look. Just go download it and try it. Don't post stupid pointless comments about how skeptical you. Don't know how that rated insightful.
Apple has integrate OpenLDAP and Samba very tightly. They have also separate out the authentication information from LDAP to a separate Password Server (essentially a SASL repository). Kerberos is also set up so that the passwords sync to Kerberos too for kerberize apps.
Here's what I think we need as far as enterprise linux directory services go: 1. Standardize on a sasl repository with hooks into Kerberos for maintaing and authenticating all passwords (md5, nt hashes, sendmail auth mechanisms) 2. Tightly integrate OpenLDAP into SASL so that all binds (plain or native SASL) use the sasl repository directly. Come up with a password changing mechanism (either through pam, an LDAP mechanism, or some API) that will change passwords in the SASL repository when ldap clients request it. 3. integrate Samba into SASL to get hashes from there instead of storing them in LDAP. Samba also tied to LDAP to get samba attributes such as homeDirectory, etc. 4. Provide an API (perhaps PAM-based?) that allows clients a mechanism to transparently access LDAP, Samba, and the SASL database. Keeps everything in sync. Also makes possible things like running custom scripts and creating remote home directories when accounts are created.
What I have described is pretty much Apple's OpenDirectory. I'd love to see something similar on Linux. We currently have many of the pieces but they have to be hacked together.
I've looked into porting the components to linux, but I find they have a lot of Mach hooks an parts of it are proprietary. Anyway. This is a start. There's much more to an enterprise directory service than just a directory.
No you don't get it. When people say "java" they mean programming the web sites in java on the server, not using java in the browser. You probably have used many java-driven web sites without knowing it, since the java runs entirely on the server and simply serves up web pages. The arguement is over whether php's feature set is becoming too much like java and thus pushing us into java-style techniques and frameworks for app design.
Actually it is completely legal inside of russia. And it is probably technically legal to use from the US too. See http://www.museekster.com/allofmp3faq.htm/ And there is no indication that I can see that the Russian Mafia runs this site. I'm sure the mafia is involved with most facets of russian business, but I see no obvious direct connection. Some arge the RIAA here in the US is basically a mob.
If you'd read up on their business model, you'll find that they do pay fees to the copyright holders association (according to Russian law). This company has been in business for several years and has had no negative reports against it of any kind that I can find.
It is too bad we can't have a similar company here in the US offering cheap unencumbered downloads. Clearly the market price would be much higher per track than the 16 cents allofmp3.com is asking, but still low enough to pretty much eliminate the tendency to pirate.
Another thing I like about allofmp3.com is that they have all of the old stuff I like. Stuff that I have to go to used stores to find the CDs for these days. By now RIAA fees probably don't even go to the original artists since they've long left the music scene.
qemu now compiles and runs under OS X and you can install MS operating systems (DOS, Windows) inside it. This is certainly cheaper than virtual PC, and the speed is not too bad. For small programs that you are writing, emulated slowdown should not pose a significant problem.
Slashdot Mirror
I read it. And I understand it. My comment is based on the following points:
.doc, xls, ppt and friends are all still their standard formats, despite using open office.
1. Despite their using OpenOffice, their standard file format is still MS Office-compatible at least for word processing. Further, interoperability with the school division and the rest of the world dictates that
2. At this point their number one costs are hardware. If MS steps in and helps out in that area, providing extremely discounted hardware deals though MS-friendly distributors, the cost factor does not have anything to do with software cost at this point. It's all hardware and they would be foolish to not take the better hardware deal despite moving back to MS's software. From MS's POV this is free lock-in. If MS can give them a deal that is cheaper than buying normal hardware for their linux infrastructure, and throw in MS software for free, then from an economic point of view it does not make sense to remain with linux. This is how MS works. We've seen it time and time again.
My main point is that MS will not sit by and let these kinds of things happen.
Precisely. In just a couple of years the school will yet again need to buy new hardware and probably upgrade some servers. At this time, MS can come in with a great, almost-free deal to lock them back into Windows that they can't afford to refuse. And they would be fools to turn it down. While this may seem immoral to you and I on slashdot, in the eyes of MS this is no more immoral than the OSS camp "dumping" their software for next to nothing.
What fundemental flaws are these? Please don't bring up debian. Debian's package manager uses .deb files which are directly equivalent to rpms.
This is surely true, although Apple apparently does not think so. Recently I received two e-mails from Apple's development team regarding bug reports that I and others have filed for Panther Server regarding critical OpenLDAP bugs. In a nutshell the e-mails said, "we think the bugs don't exist in Tiger Server. Please upgrade to Tiger Server and tell us if this is the case." I was stunned. I sent them a strongly worded response to tell them that this was not acceptable. Apple just doesn't yet understand what it takes to produce Enterprise software. We need very long support lifetimes (3-5 years minimum) and upgrading major OS versions outside of normal hardware replacement cycles (with proper testing) is *never* done except in extraordinary circumstances. Right now I am very unhappy with Apple. Does anyone even know what the life expentancy of Panther Server is? What about Tiger? I can't find this information anywhere and Apple has not yet responded to my queries. Judging by the terrible LDAP problems I had with OS 10.3 (not fixed until 10.3.9!) I am in no hurry to put Tiger Server into production. I learned my lesson the hard way.
Now that AFP support under linux is much better, I'm almost certainly going to go back to Linux for my main file servers. At least it is a known quantity.
While the version number of samba is old now, the critical bug fixes (security mainly) are backported by redhat. So I don't worry too much security-wise about things like this.
I agree that roundup is the safest herbicide out there.
But when these roundup ready genes escape into nature (and they do), we end up creating a super weed. In agriculture right now, herbicide resistance is a huge deal.
At the end of the day monsanto cares more about furthering the short-term bottom line than they do about at environment or the farmers.
NeoOffice is not a fork; it is a Mac OS X port. They (2 developers) work hard to keep it in sync with the mainline tree. Should development on OO.org stop, NeoOffice will wither and die also.
Hmm, you mean like how gcj produces native java executables that are faster than running bytecode in the JVM? Oh wait. No it's slower. One of the main facets of .NET and Mono, though, is the ability to precompile the binaries to speed up loading (but not running). The thing about running code in the JVM and the CLR is that programs slowly get faster and faster as the jitter tweaks the optimizations and caches them.
Therefore I don't see any real point to producing native executables. Heck you don't even see to many people clamoring for a perl native compiler or a python native compiler. Although they exist most people simply don't need them. The future is in languages like Python, Perl, C#, Java. Bytecode compiled or even straight interpreted languages are really coming of age. The bare underlying hardware is becoming less and less relevant.
Copyright can never dictate to you how you personally use the copyrighted work. You can read it, scribble on it, destroy it or whatever. But you cannot distribute the work; copyright law grants you no such privilege. The GPL is a license that extends your rights over a work so that you can distribute the work to others. Thus the GPL says nothing about use.
In the case of digitally restricted audio CDs, the software is attempting to artificially restrict personal fair use using technicalities provided by the DMCA. Because theses mechanisms are declared as "copy protection"--which they arent'--the DMCA then punishes those who circumvent these mechanisms with criminal penalties. Having an unencumbered personal copy of the work is not a crime, though. It's a neat way to sidestep the fair use rights of end users on the part of the copyright holders, though. I think I can say with all sincerity that copyright holders who artificially restrict the use of their work beyond the allowances of normal, sane copyright law are not respecting the nature of copyright or the intent for which such laws exist.
Fedora as a desktop distribution is one thing, but after running Fedora Core 1 on my linode web server, I will never run fedora on a server again. A 6 month lifespan is simply way too short. From now on I'll be using CentOS on my linode. In fact, for desktop machines I'd even considuer CentOS since the lifespan of CentOS is 5 years or so.
So I can believe that RHEL or a RHEL compatible distro would be increasing in popularity, but I have a hard time believing Fedora would be appropriate for such situations.
Actually if we could just produce a 100% reflective, paper display (digital ink) we could save a lot of energy while still having a display that looked good under normal lighting situations, including full sunlight. I think that purely luminous displays are hard on the eyes. I'd adopt digital books in a hartbeat when you can give me a surface that looks just like paper (or glossy magazine stock) with 300-600 dpi electronic ink resolution. If lighting conditions are low, just add a reading light like a normal book.
Yeah you'd think that would be the case. The source files are available but I have yet to get them to build. They also have heavily hacked OpenLDAP without separating their changes out into patches. Thus using a newer version of OpenLDAP, for example, is almost impossible. I'm going to start talking to the OpenDarwin folks about building these things.
So far, sadly, Apple indeed uses open source components and release much of their source, but they are not open in most senses of the word. There are no mailing lists where I can really have a dialog with other Apple server users *and* Apple engineers. I can't even access an open bugs list like I can with their closest enterprise competitor, RedHat.
So it is possible to use completely open source products together in a way that ofuscates (either intentionally or just from lack of documentation) how things fit together such that really modifying or fixing things is difficult. I guess the main thing that is missing is documentation. Apple has next to no documentation on the guts of the system. There is no record of how and why they have modified OpenLDAP, no information on the protcols (message-passing and tcp/ip) used by OpenDirectory (DirectoryService and PasswordService to be specific) other than ldap which only forms a part of the system. In fact after studying the system for over a year I'm still not sure exactly how the system fits together and what the service depedencies are in OpenDirectory.
Having used OpenDirectory for a year and half, I can say that it is too buggy for enterprise use. There seem to be problems with the OpenLDAP and PasswordService integration in OpenDirectory. OpenLDAP crashes hard very frequently and often the entire OS X system (due to the way DirectoryService works) is made complete unresponsive. Apple is aware of the bugs and how to reproduce them but so far has done nothing. The current rumors are that these bugs (or bug) will be fixed in Tiger. That is simply not acceptable for enterprise software. Current bug numbers (ticket numbers) that Apple has assigned this problem are 3966561, 3725081, and 3549410.
The irony is that OpenDirectory is awesome! We should be actively porting the architecture to linux. The problems I've described above are not inherent design flaws, but rather specific Apple implementation bugs on OS X. I know on Linux this stuff would work wonderfully. OpenLDAP forms a key component of this architecture but it's only the authorization component. OpenDirectory provides a unified SASL/Kerberos password store that does authentication in a unified way (and syncs passwords for samba, md5, etc)
Given this discouraging situation, I'd stick to Active Directory if I were you for now.
Why? No one installs OpenOffice that way on Linux. It's all about packages the distributor ships. Moving Openoffice to packages is the way to go. I do think they should make fewer packages, though.
I use Adobe Reader 7 beta for linux every day. looks good, works great. It's basically built out of GTK. Or at least it adopts the gtk theme pretty well.
It's very simple. You own the copyright to your own code. Therefore you don't need *any* license to use your code. The GPL only applies to those who use your code who don't own the copyright. Of course when you are the copyright holder you can license the code under any terms at any time to anyone.
Your comments represent a fairly widespread misunderstanding of licensing and copyright in general. MS and others like to play up on this misunderstanding to make you think that GPLing your code somehow magically prevents you from using your code in a commercial fashion, even closed source. It simply cannot.
Many people refer to this as "dual-licensing" meaning you can use my code under the terms of the GPL or negotiate an alternative license.
The only way to really remove a root kit on any operating system (linux, unix, windows, etc) is to do a format and reinstall of the OS. This is unlikely to ever change for any operating system. Except for maybe trusted computing...
The irony is that it is the lack of these nice eye-candy features that actually make X feel so slow. The new improvements to X rendering that make the eye candy possible also make X appear faster. double-buffering, synchronized resizes, etc.
X is already very fast. It's the perception of speed that's critical, though, and X11 (or rather the widget sets and their lack of drawing synchronization) does appear to feel more sluggish even though it is not.
For example, the GUI feels silky smooth on my powerbook. dragging windows, expose, etc. Howevver if you really measure things, the gui on OS X can sometimes be very sluggish and slow. But it appears fast because it is so smooth. Interesting.
I don't think the lack of interest in enlightmentment is indicative of NIH syndrome. Rather enlightenment has always been off on its own. Owen and crew are working to not only bring about eye candy but implement standards that everyone follow to make better rendering work for all apps and window managers.
No hydrogen won't help anything in Korea. Hydrogen is not a fuel source anymore than electricity is an energy source. At best it is an inefficient way of storying energy generated by fossil fuels. This it doesn't solve anything. Hydrogen isn't naturally found anywhere. It will never be commercially successful because it is inefficient and does not make economic sense. That is the sad fact. The future is in biological, organically created fuel oils. That's much more efficient if we can get a natural process (say algae) to turn carbon dioxide in the air into diesel fuel using the power of the sun. This is actually efficient and sustainable.
The qemu claims are accurate. I am currently using this module with qemu and find that I do get 60-70% native speed (just as he advertises) and it is only going to get better. mind you this is x86 on x86. I/O performance (just like on vmware) is still a pig.
Look. Just go download it and try it. Don't post stupid pointless comments about how skeptical you. Don't know how that rated insightful.
Apple has integrate OpenLDAP and Samba very tightly. They have also separate out the authentication information from LDAP to a separate Password Server (essentially a SASL repository). Kerberos is also set up so that the passwords sync to Kerberos too for kerberize apps.
Here's what I think we need as far as enterprise linux directory services go:
1. Standardize on a sasl repository with hooks into Kerberos for maintaing and authenticating all passwords (md5, nt hashes, sendmail auth mechanisms)
2. Tightly integrate OpenLDAP into SASL so that all binds (plain or native SASL) use the sasl repository directly. Come up with a password changing mechanism (either through pam, an LDAP mechanism, or some API) that will change passwords in the SASL repository when ldap clients request it.
3. integrate Samba into SASL to get hashes from there instead of storing them in LDAP. Samba also tied to LDAP to get samba attributes such as homeDirectory, etc.
4. Provide an API (perhaps PAM-based?) that allows clients a mechanism to transparently access LDAP, Samba, and the SASL database. Keeps everything in sync. Also makes possible things like running custom scripts and creating remote home directories when accounts are created.
What I have described is pretty much Apple's OpenDirectory. I'd love to see something similar on Linux. We currently have many of the pieces but they have to be hacked together.
I've looked into porting the components to linux, but I find they have a lot of Mach hooks an parts of it are proprietary. Anyway. This is a start. There's much more to an enterprise directory service than just a directory.
Michael
No you don't get it. When people say "java" they mean programming the web sites in java on the server, not using java in the browser. You probably have used many java-driven web sites without knowing it, since the java runs entirely on the server and simply serves up web pages. The arguement is over whether php's feature set is becoming too much like java and thus pushing us into java-style techniques and frameworks for app design.
Hmm. Maybe better to develop a plant to remove Roland Piquepaille blog advertisements from slashdot...
Actually it is completely legal inside of russia. And it is probably technically legal to use from the US too. See http://www.museekster.com/allofmp3faq.htm /
And there is no indication that I can see that the Russian Mafia runs this site. I'm sure the mafia is involved with most facets of russian business, but I see no obvious direct connection. Some arge the RIAA here in the US is basically a mob.
If you'd read up on their business model, you'll find that they do pay fees to the copyright holders association (according to Russian law). This company has been in business for several years and has had no negative reports against it of any kind that I can find.
It is too bad we can't have a similar company here in the US offering cheap unencumbered downloads. Clearly the market price would be much higher per track than the 16 cents allofmp3.com is asking, but still low enough to pretty much eliminate the tendency to pirate.
Another thing I like about allofmp3.com is that they have all of the old stuff I like. Stuff that I have to go to used stores to find the CDs for these days. By now RIAA fees probably don't even go to the original artists since they've long left the music scene.
qemu now compiles and runs under OS X and you can install MS operating systems (DOS, Windows) inside it. This is certainly cheaper than virtual PC, and the speed is not too bad. For small programs that you are writing, emulated slowdown should not pose a significant problem.