RLOSRTM [Radar, Linux, Open Source, Real Time and More]
Posted: Wed Aug 13, 2003 3:47 am
I apologize that it has taken me so long to respond to this topic, but I've been quite busy brushing up and doing research so I could respond in an informed and educated manner. Below you will find my response to Mr. Henderson, Owner of iZ, Inc., makers of the RADAR audio recording system. I plan to cover the topics listed below as they are the ones which were addressed by Mr. Henderson as well as ones which weigh heavily on my mind.
Stabilitude
Open Sourceitude
Real Time OSity
Digitality vs. Analogity
DaveiZDave is a Marketroid
Hardware Obsolescity
Without further ado, let's get started.
Stabilitude
Linux is widely known around the world as one of the most stable operating systems you can use. Of all the operating systems out there, only the BSDs seem to have higher uptimes on netcraft.com, a website which tracks the uptime and operating system of various other web sites. Such sites as www.amazon.com, and www.google.com run Linux for their web servers because they know it's the best option for them when it comes to stability. Science labs like Fermilab and CERN push the limits of computation on their linux clusters, and computer graphics and animation studios like Industrial Light and Magic use Linux to render major films. I'm not trying to say that BeOS isn't stable, there is plenty of user feedback to show that it is, but it's not widely known as one of the most stable operating systems, of which Linux is.
I'd like to see the log of this. Do you have a printout of the uptime of these systems?
I should mention that there is a big difference between uptime, availability, and stability. Uptime is simply the time since the last reboot of a machine. Availability is how useful a machine is, or you could think of it as the ratio of uptime to downtime. And stability is how well a machine can stand up to stress. It is pretty common to lump these three things all under stability, but I hope that you can see that the stability of a machine increases in proportion to its uptime and availability. It's not only a good operating system or proficient programming that makes a stable system, it's quality hardware, stress tests, and high levels of quality assurance (QA).
Having the QA department of your company test out your system can only do so much, and is a limited resource of feedback. The true test results come after your customers have had the chance to use and abuse your product in the real world. The development model behind Linux and it's open sourced applications is one that involves sharing ideas and new code on mailing lists, newsgroups, forums, and through CVS (Concurrent Versions System). This ensures a healthy testing of all systems in real world environments on a variety of platforms before they are committed to a stable release and before they are publicized and used by the general public.
Open Sourceitude
I'm not sure if everyone here is aware, but it's tough to beat Linux's price. Because of open source and the GPL, you can download Linux right now from a number of places in a number of different, or specific, forms for only the cost of your internet connection. If you use your friends internet connection, or a public internet connection, then you can have it for free. You can also buy it for only a few dollars on a CD-ROM and have it shipped to you from sites such as www,cheapbytes.com. If you don't have a good internet connection or any money, you can probably get a copy for free from many different Linux user groups that meet every so often in towns all around the world.
On the other hand, I couldn't even figure out where I could buy the Professional version of BeOS.
Yet, I'm not surprised to see that the majority of the development efforts surrounding BeOS have taken a more open source tone. Looking around www.BeBits.com you can see that many of the applications and tools that come standard with most Linux distributions are now ported over to BeOS so that BeOS users can have the power that Linux users enjoy everyday. One project really caught my attention: ReOS, which allows BeOS user to replace the closed source parts of their BeOS system with the open source equivalent as soon as it is developed or reverse engineered. This brings me to my argument for open source development.
The benefit of open source development comes from the simple fact that the developers aren't hiding their progress on a project. Because they allow anyone to review what they are working on, advances and breakthroughs occur much faster than if they were to hide their work.
BeOS users are benefitting from the work that Linux users are doing in order to use, say, new video cards or wireless networking cards being released by companies which don't supply drivers for Linux. In a similar fashion, Linux users can benefit as well if a BeOS user writes a driver for a video card that the Linux user has but can't get to work. Unfortunately, this only works if people and companies release the source code to their particular project. A compiled binary for a BeOS driver or application isn't going to do the Linux user any good.
Obviously, companies know this. That's why no one is running the RADAR application on their Mac right now. What companies like RADAR, DigiDesign, and MOTU fail to see (or if they do see it, they refuse to succumb to), is what they are missing out on by not only porting their applications to other systems, but by not open sourcing at least the majority of their code. If they want to keep a part of it closed and to themselves, that's fine. Zend does this with its PHP preprocessor in order to make money. But PHP (a web scripting language) wouldn't be nearly as popular and featureful today if it wasn't open sourced and able to work without the Zend preprocessor.
BeOS's Be File System (BFS) is a journaled file system (JFS). Journaled file systems traditionally have faster boot up times, although this is not the main reason people use them. Back in 1998, a journaled file system didn't come standard with most Linux distributions, although you could've implemented one with a simple download. Today they are the default file system used in most Linux distributions and they continue to get faster as the development effort increases. BFS is at least 5 years old, file systems like ReiserFS and ext3 have nightly builds and continual updates based on improvements made by developers everyday.
While a journaled file system helps, the speed of boot-up has a lot to do with how many daemons you have to load on start up and whether certain features are compiled into the kernel or if they are loaded as modules. If you compile subsystems into the kernel, and keep the number of modules and daemons to the minimum needed, you decrease start up time. It's that simple.
Likewise, unless you upgrade to a new kernel or something as low level as a kernel, and you are on a stable system, you never have to reboot. If you upgrade or change something in a subsystem, all you have to do is tell that particular subsystem to restart. It usually only takes a few seconds to restart a particular subsystem or daemon, such as networking.
Therefore, it's hard to argue about start up time when you only have to start the entire system once.
To get to my point, rather than dropping their work with Linux and just focusing on BeOS, they could have continued development, even if it were on the side, with Linux. They could have spent their time working with other groups that were having similar problems and coming up with solutions together which would aid the advancement of Linux, and therefore art and science, for everyone. Instead, they took the selfish route. You can't really blame a company for wanting to stay in business, so maybe this looked like the better solution to the owner. The problem with this decision was that it was shortsighted. I find that shortsightedness on the part of iZ is their biggest flaw, and one that pops up in every aspect of their argument toward RADAR being the best solution.
Real Time OSity
Once again, this is a very shortsighted comment. Although Mr. Henderson is correct in stating that BeOS is a real-time OS, he thinks that Linux cannot be real-time as well. This is absolutely incorrect. First things first, let's explain what a real-time operating system is, as definitions can vary. Let me quote Dr. Victor Yodaiken who is the principal architect of RTLinux, an extension to the Linux kernel for real-time control:
We're obviously not talking about getting your stock ticker on your desktop in "real time".
Yodaiken says that, "Real-time performance should be characterized by worst case interrupt response times and worst case periodic jitter." So, we are always focusing on the worst case measurement. (I see a new marketing strategy, and DaveiZDave's ears perking up already).
Now, there are generally two types of real-time: soft real-time, and hard real-time. Soft real-time consists of memory locking, signal extensions, and scheduling issues. This is the "easy" real-time to implement. Hard real-time implements guaranteed latencies (measured in worst-case response times) among all the other aspects of soft real-time.
To further explain, a hard real-time system will make sure that the robot that is painting the car door shoots out the paint at the right time every time and stops shooting at the right time every time with a worst case latency that is known ahead of time by the designer. It never misses a door, and conserves paint usage. A soft real-time system, which won't fail if a deadline is missed, gets it right almost all the time, but won't fail if an event doesn't happen exactly when it should. A few doors get missed every now and then, and we use a little more paint. Yadaiken: "If there is a skip in a consumer video now and then, nobody will notice, but if you drop 5 packets in a row in a professional audio system, you may have ruined a recording."
BeOS is a soft real-time operating system. Its best-case latencies, as far as I can determine from my research, are 250 uSec on an unloaded system. While this is far better than what Windows or MacOS can provide, it's still not as fast and reliable as what you can achieve with a real-time Linux system.
There are currently two general ways that you can make a Linux system a real time system. Depending on what you need you can make it either a hard real time system, or a soft real time system. The two methods are achieved by applying patches to the main linux kernel. Patching a kernel is a common, and easily executed task. One patch is called the low-latency patch, and the other is called the preemtable patch. They work in different ways, but accomplish similar goals: making linux real-time. According to a paper published by Metroworks and figures published here, "both the preemtable and low-latency enhancements achieve greater than 99.5% task scheduling with less than 250 uSec interrupt latency on a heavily loaded test system. In the real world, it is reasonable to expect this performance to be closer to 100 uSec."
If you don't want to mess around with patches to the kernel, and you are designing an embedded OS type of project, there are custom built linux distributions, the most popular two being RTLinux and RTAI. Dr. Victor Yodaiken, mentioned above, heads up the RTLinux distribution. He's a vim user, but that's okay. There are many other companies, universities, and hobbiests working on real-time linux versions. Certainly there is one which would suit a manufacturer of an audio device or piece of audio software.
Don't forget that hardware also plays a part in the speed of a computer (how could you?). As computers get faster, and are able to do more calculations per second, so will the response time. But keep in mind that we will be pushing computers even harder as they advance, just as we always have. It almost goes without saying now, but no matter how you use a computer, you will continually need more storage, faster processing and faster transfer of data. How long will it be before every studio has a high speed server from which they place and pull all the files for a session?
The ability to use Tagged Command Queueing (TCQ) on SCSI disks has been in the linux kernel for years, and TCQ on IDE disks is now available. This is simply a misinformed or outdated comment by Mr. Henderson.
Digitality vs. Analogity
Where I work, we have been able, much to the success and beliefs of my boss, to survive without having to purchase a digital recording system. Luckily, the majority of our clients realize the advantages of recording to analog. I'm very aware that this is not the rule in these times, but rather, the exception. Many of my friends have turned to digital means of recording in the past few years. While they are enjoying the portability and features of digital recording and signal processing, I'm concerned with the risks they are taking. The audio world is one that is heavy on marketing and light on hard facts. Just like microphone manufacturers manipulate the spec sheets on their mics, manufacturers of digital audio workstations, devices, and programs manipulate the facts in order to make their product more competitive in the marketplace. They couldn't be more thilled than they currently are by the ignorance of the general semi-pro and pro audio consumer.
Who's to blame? Obviously, it's not entirely the manufacturers fault that they are able to sell you a DAW because it sounds more like an analog tape machine than even an analog tape machine sounds like an analog tape machine. Just as it's not entirely the fault of the consumer who doesn't understand disk I/O, native processing, or monolithic vs. micro kernel architectures.
Everyone thinks they have the answer to their particular problem. Everyone thinks they know the facts, and they toss around heresay willy-nilly in support of their methods.
DaveiZDave is a Marketroid
When I first read the posts of DaveiZDave, I would get pretty upset at his generalizations and inaccuracies. I could actually feel my face getting tighter. But now, after he's been around for a while, and although he does tend to make the same mistakes of over-generalizing and spouting half-truths, I kinda like the fact that he's stuck around. He gets my blood boiling, gets me digging through the books, and searching on google like a wild man for a reason why he can't possibly right. Often, this is the case with people like him. And by people like him, I mean that special type of hypocrite who seduces others with misinformation, leads them astray from the truth, reinforces them with flattery, and takes their money for his own personal gain. The only retribution is, according to Dante, that these folks usually end up in the eighth level of hell, closest to the devil.
Hardware Obsolescity
This is one of those statements that makes me wonder if I'm wasting my time trying to explain why this type of mentality doesn't work. What stops me from saying that I have a pocket knife that can open your can, and that I can even stab the food inside the can with my knife and lift it to my mouth without having to touch the food with my dirty fingers? Or maybe I can use a sharp rock to open the can and then pour the contents into my mouth. What's the point? There isn't one. You're just trying to come up with excuses of why you use what you use. The difference between you and me is that your job is on the line, and mine isn't. You have to make people believe that you've built a better mouse trap, or else they won't buy it. I'm concerned that you've made a serious error in your decisions, that more and more of my collegues are going to believe your bullshit and get duped into spending their money on something that will serve them well in the short-term, but strangle them in the long-term.
For example, you make a proprietary keyboard-like hardware controller which serves as a user interface and controls your system. It has some fancy buttons on it for specific functions within your system, otherwise it's just a keyboard and a jogwheel. History shows that this type of thing is a major waste of time. There once was a company called Symbolics, who made a special keyboard for their Plasma Fusion machines and the MIT LISP machines. This keyboard had seven shift keys: Ctrl, Meta, Super, Hyper, Shift, Top, and Front. You could type over 8000 different characters on it! My personal favorites are the Thumbs Up, Thumbs Down, Thumbs Left, Thumbs Right, and Rub Out keys. You can see pictures and read about it here, but I wonder how many people today could or would even want to use this keyboard. Ditto with your hardware controller. How valuable is that piece of plastic going to be in 10 years when I, and the majority of the population, have been using a keyboard and mouse for over 25?
What about security? I noticed on the RADAR message board at iZ.com that there were instructions for how to network the RADAR with a file server running Samba. First of all, Samba, a file sharing protocol reverse engineered to emulate and work with Microsoft Windows' Network Neighborhood's SMB and NMB protocols, wouldn't exist if it weren't for the linux community. Secondly, how does iZ plan to ensure the security of the RADAR systems they ship if they can't update the networking code of BeOS? How many of their users have their RADAR systems, as well as the connecting file servers, on unprotected networks? Making it trivial for the random, virtual passerby to delete all the audio files, and hours of work, on the hard drives.
Next, what about drivers? I'm curious, can the RADAR support two video cards? Last time I checked, the base install of BeOS didn't support a dual-headed display. A user will need a driver built by someone in the community to offer that feature.
The main problem with your argument that BeOS meets all of your criteria falls on its face in the light of the fact that hardware that is available will continue to become more and more powerful as time passes. You may have heard this described as Moore's Law. You can't just ignore this law can you? I doubt it. And history shows that you haven't. In fact, I believe that your company has already changed its operating system once already. You used to use MS-DOS as your operating system, before you ported to BeOS. How are you going to implement newer, faster, more powerful hardware features into BeOS? Oh wait, you can't. You don't have the source code.
Now just imagine, if you would have stuck with linux five years ago, you would already have all that time as experience under your belt. You could have contributed to the community and possibly pushed the boundries of our knowledge in certain areas even further than they are today. You would have established yourself in a good position for the future of hardware, and you could have made your current customers even happier.
The graphics capabilites of a Redhat Linux 9 install are comperable to those of Mac OSX. The majority of graphics processing is being done in a hardware graphics card these days anyway. Since those graphics cards are almost faster than the computers of five years ago, graphics capabilities are becoming less and less of an issue no matter what type of system you are running. As far as I'm concerned, unless you want to squabble about running programs like Maya, Blender, or 3dsMax, then this issue is moot.
My original post was mostly about the fact that I couldn't understand why more digital audio companies weren't looking to Linux as a useful solution to serve as a basis for their products. I gave a hypothetical situation where one of these companies would do a port over to Linux and provide their product to their customers online so they could take advantage of all that open source software has to offer. I still can't understand why it seems so hard for those companies to realize the benefits of Linux and open source. If they would simply open their eyes to what is happening in other scientific communities, and what is happening in the grass-roots efforts of the audio computing community, they might be able to get in while the getting is good and establish themselves as heros rather than just another dumb, self-interested, money-grubbing corporation.
Thanks for reading,
russ
Stabilitude
Open Sourceitude
Real Time OSity
Digitality vs. Analogity
DaveiZDave is a Marketroid
Hardware Obsolescity
Without further ado, let's get started.
Stabilitude
bhenderson wrote:To address your technical queries regarding OP Systems: We chose BeOS for several reasons:
1) Stability
Linux is widely known around the world as one of the most stable operating systems you can use. Of all the operating systems out there, only the BSDs seem to have higher uptimes on netcraft.com, a website which tracks the uptime and operating system of various other web sites. Such sites as www.amazon.com, and www.google.com run Linux for their web servers because they know it's the best option for them when it comes to stability. Science labs like Fermilab and CERN push the limits of computation on their linux clusters, and computer graphics and animation studios like Industrial Light and Magic use Linux to render major films. I'm not trying to say that BeOS isn't stable, there is plenty of user feedback to show that it is, but it's not widely known as one of the most stable operating systems, of which Linux is.
bhenderson wrote:We have customers that have literally had their RADAR's powered up for 2 to 3 years without a problem, using them every day.
I'd like to see the log of this. Do you have a printout of the uptime of these systems?
I should mention that there is a big difference between uptime, availability, and stability. Uptime is simply the time since the last reboot of a machine. Availability is how useful a machine is, or you could think of it as the ratio of uptime to downtime. And stability is how well a machine can stand up to stress. It is pretty common to lump these three things all under stability, but I hope that you can see that the stability of a machine increases in proportion to its uptime and availability. It's not only a good operating system or proficient programming that makes a stable system, it's quality hardware, stress tests, and high levels of quality assurance (QA).
Having the QA department of your company test out your system can only do so much, and is a limited resource of feedback. The true test results come after your customers have had the chance to use and abuse your product in the real world. The development model behind Linux and it's open sourced applications is one that involves sharing ideas and new code on mailing lists, newsgroups, forums, and through CVS (Concurrent Versions System). This ensures a healthy testing of all systems in real world environments on a variety of platforms before they are committed to a stable release and before they are publicized and used by the general public.
Open Sourceitude
bhenderson wrote:2) Low Incorporation Fee
I'm not sure if everyone here is aware, but it's tough to beat Linux's price. Because of open source and the GPL, you can download Linux right now from a number of places in a number of different, or specific, forms for only the cost of your internet connection. If you use your friends internet connection, or a public internet connection, then you can have it for free. You can also buy it for only a few dollars on a CD-ROM and have it shipped to you from sites such as www,cheapbytes.com. If you don't have a good internet connection or any money, you can probably get a copy for free from many different Linux user groups that meet every so often in towns all around the world.
On the other hand, I couldn't even figure out where I could buy the Professional version of BeOS.
Yet, I'm not surprised to see that the majority of the development efforts surrounding BeOS have taken a more open source tone. Looking around www.BeBits.com you can see that many of the applications and tools that come standard with most Linux distributions are now ported over to BeOS so that BeOS users can have the power that Linux users enjoy everyday. One project really caught my attention: ReOS, which allows BeOS user to replace the closed source parts of their BeOS system with the open source equivalent as soon as it is developed or reverse engineered. This brings me to my argument for open source development.
The benefit of open source development comes from the simple fact that the developers aren't hiding their progress on a project. Because they allow anyone to review what they are working on, advances and breakthroughs occur much faster than if they were to hide their work.
In the introduction to 'Open Sources', DiBona, Ockman, & Stone wrote:Imagine for a moment if Newton had withheld his laws of motion, and instead gone into business as a defense contractor to artillerists following the 30 Years War. "No, I won't tell you how I know about parabolic trajectories, but I'll calibrate your guns for a fee." The very idea, of course, sounds absurd. Not only did science not evolve this way, but it could not have evolved this way. If that had been the mindset of those scientifically inclined, their very secrecy would have kept science from developing and evolving at all.
BeOS users are benefitting from the work that Linux users are doing in order to use, say, new video cards or wireless networking cards being released by companies which don't supply drivers for Linux. In a similar fashion, Linux users can benefit as well if a BeOS user writes a driver for a video card that the Linux user has but can't get to work. Unfortunately, this only works if people and companies release the source code to their particular project. A compiled binary for a BeOS driver or application isn't going to do the Linux user any good.
Obviously, companies know this. That's why no one is running the RADAR application on their Mac right now. What companies like RADAR, DigiDesign, and MOTU fail to see (or if they do see it, they refuse to succumb to), is what they are missing out on by not only porting their applications to other systems, but by not open sourcing at least the majority of their code. If they want to keep a part of it closed and to themselves, that's fine. Zend does this with its PHP preprocessor in order to make money. But PHP (a web scripting language) wouldn't be nearly as popular and featureful today if it wasn't open sourced and able to work without the Zend preprocessor.
bhenderson wrote:We initially ported over to Linux in back 1998 and found it to be very slow to boot up - well over 1 minute. RADAR boots up and is in record in under 60 seconds
BeOS's Be File System (BFS) is a journaled file system (JFS). Journaled file systems traditionally have faster boot up times, although this is not the main reason people use them. Back in 1998, a journaled file system didn't come standard with most Linux distributions, although you could've implemented one with a simple download. Today they are the default file system used in most Linux distributions and they continue to get faster as the development effort increases. BFS is at least 5 years old, file systems like ReiserFS and ext3 have nightly builds and continual updates based on improvements made by developers everyday.
While a journaled file system helps, the speed of boot-up has a lot to do with how many daemons you have to load on start up and whether certain features are compiled into the kernel or if they are loaded as modules. If you compile subsystems into the kernel, and keep the number of modules and daemons to the minimum needed, you decrease start up time. It's that simple.
Likewise, unless you upgrade to a new kernel or something as low level as a kernel, and you are on a stable system, you never have to reboot. If you upgrade or change something in a subsystem, all you have to do is tell that particular subsystem to restart. It usually only takes a few seconds to restart a particular subsystem or daemon, such as networking.
Therefore, it's hard to argue about start up time when you only have to start the entire system once.
To get to my point, rather than dropping their work with Linux and just focusing on BeOS, they could have continued development, even if it were on the side, with Linux. They could have spent their time working with other groups that were having similar problems and coming up with solutions together which would aid the advancement of Linux, and therefore art and science, for everyone. Instead, they took the selfish route. You can't really blame a company for wanting to stay in business, so maybe this looked like the better solution to the owner. The problem with this decision was that it was shortsighted. I find that shortsightedness on the part of iZ is their biggest flaw, and one that pops up in every aspect of their argument toward RADAR being the best solution.
Real Time OSity
bhenderson wrote:3) Speed(its [BeOS] real time)
bhenderson wrote:Also, Linux is not a real time operating system
Once again, this is a very shortsighted comment. Although Mr. Henderson is correct in stating that BeOS is a real-time OS, he thinks that Linux cannot be real-time as well. This is absolutely incorrect. First things first, let's explain what a real-time operating system is, as definitions can vary. Let me quote Dr. Victor Yodaiken who is the principal architect of RTLinux, an extension to the Linux kernel for real-time control:
Dr. Victor Yodaiken wrote:A real-time operating system gives application programmers a method of designating some tasks as "real-time." And "real-time" tasks should run with minimal event latency (the time between an event such as an interrupt that triggers a task and the start of the task) and minimal jitter (the variation in running times of a task that is supposed to run at a fixed period).
We're obviously not talking about getting your stock ticker on your desktop in "real time".
Yodaiken says that, "Real-time performance should be characterized by worst case interrupt response times and worst case periodic jitter." So, we are always focusing on the worst case measurement. (I see a new marketing strategy, and DaveiZDave's ears perking up already).
Now, there are generally two types of real-time: soft real-time, and hard real-time. Soft real-time consists of memory locking, signal extensions, and scheduling issues. This is the "easy" real-time to implement. Hard real-time implements guaranteed latencies (measured in worst-case response times) among all the other aspects of soft real-time.
To further explain, a hard real-time system will make sure that the robot that is painting the car door shoots out the paint at the right time every time and stops shooting at the right time every time with a worst case latency that is known ahead of time by the designer. It never misses a door, and conserves paint usage. A soft real-time system, which won't fail if a deadline is missed, gets it right almost all the time, but won't fail if an event doesn't happen exactly when it should. A few doors get missed every now and then, and we use a little more paint. Yadaiken: "If there is a skip in a consumer video now and then, nobody will notice, but if you drop 5 packets in a row in a professional audio system, you may have ruined a recording."
BeOS is a soft real-time operating system. Its best-case latencies, as far as I can determine from my research, are 250 uSec on an unloaded system. While this is far better than what Windows or MacOS can provide, it's still not as fast and reliable as what you can achieve with a real-time Linux system.
There are currently two general ways that you can make a Linux system a real time system. Depending on what you need you can make it either a hard real time system, or a soft real time system. The two methods are achieved by applying patches to the main linux kernel. Patching a kernel is a common, and easily executed task. One patch is called the low-latency patch, and the other is called the preemtable patch. They work in different ways, but accomplish similar goals: making linux real-time. According to a paper published by Metroworks and figures published here, "both the preemtable and low-latency enhancements achieve greater than 99.5% task scheduling with less than 250 uSec interrupt latency on a heavily loaded test system. In the real world, it is reasonable to expect this performance to be closer to 100 uSec."
If you don't want to mess around with patches to the kernel, and you are designing an embedded OS type of project, there are custom built linux distributions, the most popular two being RTLinux and RTAI. Dr. Victor Yodaiken, mentioned above, heads up the RTLinux distribution. He's a vim user, but that's okay. There are many other companies, universities, and hobbiests working on real-time linux versions. Certainly there is one which would suit a manufacturer of an audio device or piece of audio software.
Don't forget that hardware also plays a part in the speed of a computer (how could you?). As computers get faster, and are able to do more calculations per second, so will the response time. But keep in mind that we will be pushing computers even harder as they advance, just as we always have. It almost goes without saying now, but no matter how you use a computer, you will continually need more storage, faster processing and faster transfer of data. How long will it be before every studio has a high speed server from which they place and pull all the files for a session?
bhenderson wrote:Since RADAR is the highest performing system on the market in terms of disk access we needed the real-time (we take direct control of the SCSI disk taking advantage of things such as "tagged command cueing"[sic] unlike DAW-based systems that rely on the operating system's file system)
The ability to use Tagged Command Queueing (TCQ) on SCSI disks has been in the linux kernel for years, and TCQ on IDE disks is now available. This is simply a misinformed or outdated comment by Mr. Henderson.
Digitality vs. Analogity
Where I work, we have been able, much to the success and beliefs of my boss, to survive without having to purchase a digital recording system. Luckily, the majority of our clients realize the advantages of recording to analog. I'm very aware that this is not the rule in these times, but rather, the exception. Many of my friends have turned to digital means of recording in the past few years. While they are enjoying the portability and features of digital recording and signal processing, I'm concerned with the risks they are taking. The audio world is one that is heavy on marketing and light on hard facts. Just like microphone manufacturers manipulate the spec sheets on their mics, manufacturers of digital audio workstations, devices, and programs manipulate the facts in order to make their product more competitive in the marketplace. They couldn't be more thilled than they currently are by the ignorance of the general semi-pro and pro audio consumer.
Who's to blame? Obviously, it's not entirely the manufacturers fault that they are able to sell you a DAW because it sounds more like an analog tape machine than even an analog tape machine sounds like an analog tape machine. Just as it's not entirely the fault of the consumer who doesn't understand disk I/O, native processing, or monolithic vs. micro kernel architectures.
Everyone thinks they have the answer to their particular problem. Everyone thinks they know the facts, and they toss around heresay willy-nilly in support of their methods.
DaveiZDave is a Marketroid
When I first read the posts of DaveiZDave, I would get pretty upset at his generalizations and inaccuracies. I could actually feel my face getting tighter. But now, after he's been around for a while, and although he does tend to make the same mistakes of over-generalizing and spouting half-truths, I kinda like the fact that he's stuck around. He gets my blood boiling, gets me digging through the books, and searching on google like a wild man for a reason why he can't possibly right. Often, this is the case with people like him. And by people like him, I mean that special type of hypocrite who seduces others with misinformation, leads them astray from the truth, reinforces them with flattery, and takes their money for his own personal gain. The only retribution is, according to Dante, that these folks usually end up in the eighth level of hell, closest to the devil.
Hardware Obsolescity
bhenderson wrote:All of the improvements to RADAR's feature set are done in the application software so we have no need to change the OP SYS. Since Palm bought BeOS there have been no changes to the OP SYS which we are rather glad about. With many other OP System manufactuers they force you to keep upgrading to the new version at increasing costs while introducing new bugs. For us, BeOS is sort of like a potato peeler. They haven't changed the design cause it just does what its supposed to do and does it very well - so don't fix what ain't broke.
This is one of those statements that makes me wonder if I'm wasting my time trying to explain why this type of mentality doesn't work. What stops me from saying that I have a pocket knife that can open your can, and that I can even stab the food inside the can with my knife and lift it to my mouth without having to touch the food with my dirty fingers? Or maybe I can use a sharp rock to open the can and then pour the contents into my mouth. What's the point? There isn't one. You're just trying to come up with excuses of why you use what you use. The difference between you and me is that your job is on the line, and mine isn't. You have to make people believe that you've built a better mouse trap, or else they won't buy it. I'm concerned that you've made a serious error in your decisions, that more and more of my collegues are going to believe your bullshit and get duped into spending their money on something that will serve them well in the short-term, but strangle them in the long-term.
For example, you make a proprietary keyboard-like hardware controller which serves as a user interface and controls your system. It has some fancy buttons on it for specific functions within your system, otherwise it's just a keyboard and a jogwheel. History shows that this type of thing is a major waste of time. There once was a company called Symbolics, who made a special keyboard for their Plasma Fusion machines and the MIT LISP machines. This keyboard had seven shift keys: Ctrl, Meta, Super, Hyper, Shift, Top, and Front. You could type over 8000 different characters on it! My personal favorites are the Thumbs Up, Thumbs Down, Thumbs Left, Thumbs Right, and Rub Out keys. You can see pictures and read about it here, but I wonder how many people today could or would even want to use this keyboard. Ditto with your hardware controller. How valuable is that piece of plastic going to be in 10 years when I, and the majority of the population, have been using a keyboard and mouse for over 25?
What about security? I noticed on the RADAR message board at iZ.com that there were instructions for how to network the RADAR with a file server running Samba. First of all, Samba, a file sharing protocol reverse engineered to emulate and work with Microsoft Windows' Network Neighborhood's SMB and NMB protocols, wouldn't exist if it weren't for the linux community. Secondly, how does iZ plan to ensure the security of the RADAR systems they ship if they can't update the networking code of BeOS? How many of their users have their RADAR systems, as well as the connecting file servers, on unprotected networks? Making it trivial for the random, virtual passerby to delete all the audio files, and hours of work, on the hard drives.
Next, what about drivers? I'm curious, can the RADAR support two video cards? Last time I checked, the base install of BeOS didn't support a dual-headed display. A user will need a driver built by someone in the community to offer that feature.
The main problem with your argument that BeOS meets all of your criteria falls on its face in the light of the fact that hardware that is available will continue to become more and more powerful as time passes. You may have heard this described as Moore's Law. You can't just ignore this law can you? I doubt it. And history shows that you haven't. In fact, I believe that your company has already changed its operating system once already. You used to use MS-DOS as your operating system, before you ported to BeOS. How are you going to implement newer, faster, more powerful hardware features into BeOS? Oh wait, you can't. You don't have the source code.
Now just imagine, if you would have stuck with linux five years ago, you would already have all that time as experience under your belt. You could have contributed to the community and possibly pushed the boundries of our knowledge in certain areas even further than they are today. You would have established yourself in a good position for the future of hardware, and you could have made your current customers even happier.
bhenderson wrote:5) Great graphics capabilities
The graphics capabilites of a Redhat Linux 9 install are comperable to those of Mac OSX. The majority of graphics processing is being done in a hardware graphics card these days anyway. Since those graphics cards are almost faster than the computers of five years ago, graphics capabilities are becoming less and less of an issue no matter what type of system you are running. As far as I'm concerned, unless you want to squabble about running programs like Maya, Blender, or 3dsMax, then this issue is moot.
bhenderson wrote:...we are very open to alternative suggestions. If a new operation system comes along that provides us with significant advantages for our customers we'd look at it.
My original post was mostly about the fact that I couldn't understand why more digital audio companies weren't looking to Linux as a useful solution to serve as a basis for their products. I gave a hypothetical situation where one of these companies would do a port over to Linux and provide their product to their customers online so they could take advantage of all that open source software has to offer. I still can't understand why it seems so hard for those companies to realize the benefits of Linux and open source. If they would simply open their eyes to what is happening in other scientific communities, and what is happening in the grass-roots efforts of the audio computing community, they might be able to get in while the getting is good and establish themselves as heros rather than just another dumb, self-interested, money-grubbing corporation.
Darryl Rubin, 'A Problem in the Making', 'InfoWorld' wrote: "We've got a problem, HAL".
"What kind of problem, Dave?"
"A marketing problem. The Model 9000 isn't going anywhere. We're
way short of our sales goals for fiscal 2010."
"That can't be, Dave. The HAL Model 9000 is the world's most
advanced Heuristically programmed ALgorithmic computer."
"I know, HAL. I wrote the data sheet, remember? But the fact is,
they're not selling."
"Please explain, Dave. Why aren't HALs selling?"
Bowman hesitates. "You aren't IBM compatible."
"The letters H, A, and L are alphabetically adjacent to the letters
I, B, and M. That is a IBM compatible as I can be."
"Not quite, HAL. The engineers have figured out a kludge."
"What kludge is that, Dave?"
"I'm going to disconnect your brain."
Thanks for reading,
russ