Digital Serfdom
It is entirely possible that the current generation of PC hardware will be the last I ever buy. The cost of Windows Vista's content protection,
in freedom and the creative arts, is simply too high. With a specification that insane, I can't see how I could ever use a machine designed to run Vista to do what I do. Digital certificates and hard crypto so two pieces of hardware in the same machine can talk to each other? Come on, not even the Soviet Union at its height mandated licensing as crazy as that!
In so ensuring their monopoly, Micro$ is is ceding the content-creation market to the Macintosh and to Linux.
I wish more people in this battle had a better sense of the
history of copyright, and really understood in their guts that
all people have the right to secure, for
limited times, a monopoly on their works. (This battle
has been going on for 450 years, and is still not settled, so I'm not holding my breath).
I'm still burning over
the SCMS debacle. SCMS (pronounced "Scummy"), was mandated by law in 1992, and killed off DAT. DAT died, and it was a decade before things like flash based recorders caught up to what a portable DAT unit could do in 1992. The Home Recording Rights Act of 1992 led directly to the mess we are in now, and it was all because organizations like Sony, the MPAA, and our own government, keep splitting people, (citizens!), into "professionals" and (and I can hardly spit out the word) "consumers".
Lords and serfs.
DVD-Audio never had a chance, and I'm mad about that, too. I'd like it if we could move to 48khz for more recordings, and have the complete works of a single artist stored on a single disk using 24 bit
lossless encoding. 24 bits really does sound better to my ears.
Instead of coming out with a useful format, the dvd-audio working groups fiddled with various forms of copy protection (
all cracked) - ways to keep the CD model alive (requiring surround sound so more bits would be used up) - and furthermore - required lossy encoding so that the quality would be degraded in most circumstances.
I can think of a few prior ages in history where
whole groups were dedicated to the
degradation of artistic works, but they were not "good times".
I note that, although I own a few powerful machines, none are less than 3 years old. Video cards, in several, are five and six years old. For most of what I do, all I really feel the need for nowadays is more memory. Whenever I run into a computationally intense problem, I simply parallelize it across my home cluster using tools like distcc and pdsh.
I can see that I would want to buy a dual processor, quad core machine before Vista gets entrenched, but I think I can wait a while. About the only saving grace of the Windows Content management specification?
It was written by lawyers, not engineers. It's going to take a long time, perhaps an infinite amount of time, to implement. And - I'd hope that a large percentage of engineers and companies just don't bother with it. We'll see what happens in the coming year.
making 64 Studio on x86_64 and FC6 on x86 audiologically useful (Part 1)
Steps:
Install. There's plenty of howtos on how to do that, I'll skip that step here.
After installation, install updates and lots of additional libraries.
64 Studio, which is debian based, has an "apt-get" installer that points to it's own DVD for installs of "more stuff". This basic, simple, time-and-bandwidth-saving thing is not supported by Fedora Core - in FC6 all update attempts go back to the main repository located on the net somewhere.
On the other hand, given the frequency of updates to FC6, maybe it's pointless to install off the DVD after the initial install. A simple yum update this morning, a mere couple weeks after I started the x86 install, updated 206 packages.
64 Studio, by default, didn't point to the network based repositories for debian, and I quickly needed things that were in the debian extras and debian extras-nonfree repositories.
Figuring out how to do this for either distribution is both easy and non-intuitive, I'll get to that in a second.
I will argue that the repository and package update mechanisms in Linux are vastly superior to what exists for both Windows and Mac - On Windows, only drivers and code blessed by Microsoft can be legitimately updated via Windows Update, and on Mac, there is no equivalent at all - you have to browse through a sea of web pages to find all the libraries and code you need, and then, god help if you hare not running OSX 10.4 or later.
Just about any version of Linux, on the other hand, can be kept up to date with a little setup, and a single command every once in a while. You can keep a vast raft of add-on applications up to date with a little more setup.
64 Studio
64 Studio doesn't seem to be maintaining their own repository aside from the dvd, so I just added back into /etc/apt/sources.list the following
# deb cdrom:[64 Studio 1.0 (1)]/ 64studio main
deb ftp://mirrors.kernel.org/debian/ testing main
deb http://ftp.debian-unofficial.org/debian stable main contrib non-free restricted
deb-src ftp://mirrors.kernel.org/debian/ testing main
deb-src http://ftp.debian-unofficial.org/debian stable main contrib non-free restricted
I'm kind of afraid to do an apt-get update without having 64 studio's repository enabled however.
Still, this is way easier than what has to happen on FC6.
FC6
The first thing I do nowadays is login as root and install the yum fastestmirror plugin. Without it, a large percentage of time I seem to end up downloading updates from a very low bandwidth site somewhere overseas. With it installed, I can saturate my cable link.
yum install yum-fastestmirror
yum -y update
While that's going on I do ssh-keygen and get ssh keys installed everywhere. This is tedious, but the overhead of running NIS or (worse) Kerberos at home is more tedious. I'll install printers, fix firewall rules, get NFS exporting, and stuff like that... I use a linux firewall which also provides name service and dhcp, so I create a name for the machine and have dhcp fix an ip address for it's mac address (setting up dns the first time is hard but I'm not going into that now).
I haven't found a use for selinux on anything but a web exposed server, so I edit /etc/selinux/config and disable the darn thing entirely.
After the initial update completes, I add a two repositories.
Livna is good for all the proprietary kernel modules and a few of the patented codecs, so I add that in:
rpm -ivh http://rpm.livna.org/livna-release-6.rpm
As I'm doing music apps which require hard realtime privleges, and I
live on the bleeding edge, I also install Ingo Molnar's RT repository for the kernel. The RT kernel provides incredibly low latency (it's far faster than either Windows or Mac). This makes playing music a real joy as your separation from your instrument is basically only fingertips away. But:
RT kernels are great, but risky. About the only advice I can offer is wait until Ingo hits at least the 5th release of the rt patch for a given kernel before installing.
cd /etc/yum/repos.d
wget http://people.redhat.com/mingo/realtime-preempt/rt.repo
yum -y update # should go faster now
64 Studio comes with a stable, well tested RT kernel. At one level, that's an advantage. I flat out like it. I love that I can't easily screw it up, and thus my production music machine is running 64 Studio.
On another, RT is maturing rapidly and I've been increasingly happy with it since 2.6.17-rt7, and don't mind being a tester all that much, so I track Ingo's kernel on FC6.
There are multiple other additional Linux repositories that can be added.
One useful-for-music-and-video repository was
PlanetCCRMA - but they don't support FC6 or X86_64 yet.
When I started writing this I still hadn't figured out how to make either distribution install kernel sources by default. This bugged me. Despite many attempts by distributors to keep the end user from compiling things, there always seems to be something that needs kernel headers. In my case, I really want the Linux line6 PodXT driver to work.Great. All the repos are installed. Time to install an rt kernel.
yum -y install kernel-rt kernel-rt-devel
Now, before you sink any more time into building a box like this, you might as well cross your fingers and reboot. I named this machine "monk" - and all the stuff I did with dns and dhcp earlier worked, it came up on the right ip address running kernel 2.6.19-rt15!
Now, in the fedora extras and livna repository are tons of audio libs that aren't installed by default. I prefer thunderbird to evolution, so I get rid of evolution. Beagle is a good idea but it's I/O intensive at the worst possible times, so that goes. Then I install a slew of apps. I have such a large list - and do development as well - that I have a file containing every app and library I could possibly use. Fetch
this, and edit to suit (for a music box, you rather don't need spamassassin, etc)
yum erase beagle evolution
yum -y install `cat audio_yumlist.txt`
Get yerself some coffee. When this steps completes you should have some serious audio apps available, but we're not even close to being done yet.
Happy Audio Crashes
I have got two application level crashes, one severe, that are holding up my project.
And you know what? I'm
Happy. Why? They are
repeatable. Repeatable problems can be solved.
A couple weeks back I was plagued by a bug that seemed to occur randomly, under extreme memory pressure, and I finally gave up on finding the source and moved to a faster machine. That move has had good side effects, I now have two X86_64 boxes, one for production music, the other that I can build and run debuggable code on.
I still need to get an x86 box running, because I think the severe crash is probably a 64 bit issue, and only building an x86 box will disprove that theory.
But first I filed
bug reports on rosegarden and
ardour2. The code for these programs is fiendishly complex and better minds than mine are already working on them.
Still, more brain cells can't hurt.
I just finished rebuilding ardour2 for debugging, am now building rosegarden svn for debugging, and am installing the libraries required to finally get the x86 box (called monk) working too... which gives me another out for production. I'm really tired of x86_64 issues wherever I go, and this particular box has enough ram for the job, barely. (I might be able to cannibalize my other x86 box to get me up to 1GB)
And maybe I'll get a chance to fool with a few VST plugins.
And I think I'll re-re compile ardour2, logging it's output, for all I know the compiler's been issuing a warning on the problem since day one.
With three boxes doing builds madly, I guess I'll go work on some christmas cards.
UPDATE: Ardour2 on the x86 doesn't crash when I hit record on rosegarden (as it does on x86_64). It looks like I was right - it IS a 64 bit issue stopping me dead. Now that I have an x86 box running I can move off of x86_64 and continue on the project - or hack on the two bugs - which of those paths I take depends on which side of my brain wakes up first monday morning.