when land is owned publicly, it is treated badly
there is no evidence for this claim as a general one about human society. you have perhaps heard of the book "the tragedy of the commons", which was one of the first to expound this idea, and suggest that private ownership of land resulted in better caretaking.
unfortunately, the book was wrong, and even the author now acknowledges that he did not do enough cross-cultural or a deep enough historical review before writing the book. there are hundreds of examples from human cultures throughout history where public ownership of land has resulted in better treatment of the land and its resources. what typically goes wrong is when there is a breakdown in the cultural traditions that ensure proper stewardship, and nothing to replace them.
a google search for "tragedy of the commons" will provide many links to the anthropological and historical research to support what i have said here.
the design of ALSA divides it into 3 layers. alsa-lib lives in user space, and provides a friendlier API for audio+MIDI than POSIX' open/read/write/close/ioctl calls. within the kernel there is the "midlevel" layer which is generic across all support hardware, and then the "lowlevel" layer which contains drivers specific to certain hardware.
The lowlevel drivers are the responsibility of specific authors and can be changed, fixed, altered and otherwise evolved quite independently of the midlevel ALSA code. Thats why the specific operation of a given lowlevel driver is not the point - if it defers interrupt handling incorrectly, or not at all, then just that low level driver is broken, not ALSA in general.
if you believe that the mid-level code contains the potential for a priority inversion, then you should explain why in some detail. if you have examples of low-level drivers that have similar issues, it would be wise to point them out.
however, my impression is that you don't know how ALSA has been designed, nor its record of successful operation to date. when priority inversion is a possibility, its generally not that hard to induce. i have never seen any report of this on alsa-devel or linux-kernel since ALSA begain development.
giving the consumer less than 1 second of information for $20
thats not what the $20 is for. included in that price, ignoring profits, are:
a long-lived media (cost about $1)
cross-artist "success" insurance gamble
(value uncertain, but possibly high)
marketing costs (cost about $2 for newish
or niche artists)
artist representation costs
royalty collection and distribution costs
Sure, the download of a CD's worth of data (and BTW, where do you live that you have access to GB/sec communications?) is not worth very much viewed a pure information, but the CD itself implicitly represents much more than that.
strange that i personally know a dozen then, eh?
the OSS API is so broken that your definition of "works fine" must be so limited as to be almost
as useless as an SB AWE 64 card, with its
bizarre duplex configuration that OSS also
cannot model correctly.
Your anonymous coward status doesn't impress me.
ALSA was designed by essentially 2 people for the audio side and 2-3 for the MIDI side. What committee?
Either you were asleep or you were never a part of the discussions on alsa-devel that led to the current design. Any complexity it presents is a result of a desire to be able to handle any and all audio interfaces, which a simpler structure (and we tried many) could not do.
No, ALSA was not designed with the ordinary end-user in mind. ALSA is a set of device drivers. It is part of the kernel, which provides mechanism, not policy, for user space. The stuff that will be designed for users mostly doesn't exist yet because too many audio developers have continued to write code around the OSS API. they can't be blamed entirely - the ALSA API was incredibly unstable for some time.
yes, its poorly documented. no its not extremely buggy. hardware support is wider than OSS and in some specific areas, deeper.
You're either a troll or you don't know anything about something you write with an authoritative tone about.
The design of ALSA with respect to SMP systems, spin locking and interlocking access is probably better than almost any existing system in the kernel.
As for deferrment of interrupt handling, thats entirely a function of individual "lowlevel" card drivers, and its possible that there are better ways for certain drivers to handle their hardware's interrupt. However, audio hardware is real-time in that it continues to run whether the CPU services it promptly or not. This requires a rather different kind of design than the one used for, say, disk drives.
finally, the proof is in the pudding. many of us have been using ALSA for several years, and it has worked better on both UP and SMP systems than
the old OSS API, and without any bizarre kernel issues.
let me put that another way. the OSS API required that the data delivered to the interface match the way the interface was configured.
this results in every app that needs to write
floating point data to an interface requiring 16bit samples to handle it themselves. dumb.
however, when the OSS API is used with a card for which there is no existing configuration description possible with OSS (the RME Hammerfall is the canonical example), then all the format conversion between the format used in user space (to match the OSS description of the configuration) and the actual hardware setup has to be in the kernel, since nothing interposes between the write(2) call and the driver itself.
what was also in the kernel (for example) was the code to drive the OSS "soft synth". there was really
nowhere else to put this because of the design
of the OSS "sequencer" (which in both ALSA and OSS is really a router and scheduler rather than
a "sequencer" in the conventional sense). this is because access to the OSS sequencer is via a/dev/ node, and thus all code related to its operation has to be in kernel space.
with the low latency patch and SCHED_{FIFO|RR} scheduling there is no reason to put a soft synth of any type in the kernel. i have been trying to encourage the ALSA sequencer coder(s) to move most of it into user space, for similar reasons.
sorry for the misleading suggestion that all format conversion code was in the kernel before.
ALSA is a complete redesign of the sound subsystem for Linux. It addresses a number of areas that were irretrievably broken in the old "OSS" design:
application access was always via direct
access to/dev/* nodes, requiring
all format conversion and other
"fancy" code to reside in the kernel
no possible generic support for non-interleaved cards
no uniform API for mmap-based access
no support for advanced h/w features without
highly hw-specific code
When using ALSA, although it remains theoretically possible to use open/read/write/ioctl/close(2) and access/dev/snd/pcm*, all applications will almost certainly use alsa-lib, which
provides a flexible, powerful way to access
and control audio and MIDI hardware. format
conversion, (de|re)interleaving code and many
other commonly required operations live in this user space library, leaving the device drivers
to simply present a suitably abstract version of the hardware they support.
In addition, ALSA addresses many areas of SMP comptability that were unreliable or just plain broken in OSS. Fixing these in OSS was a per-card affair, with some better than others. Under ALSA, the design of the entire system is SMP friendly.
you seem to believe that people want "more moderate" candidates. several times you suggest that a NOTA strategy would encourage this.
i would suggest that people want more diverse candidates (i'm not talking skin color here, but political perspectives), more discussion of genuine political alternatives, more personal opinion and less lobbyist-generated newspeak.
NOTA might help with that, but its not clear that it would help anymore than a number of other electoral reforms such as one of the various forms of proportional representation.
i don't have a reference for you i'm afraid.
i know that when corporate charters were introduced into english law under Charles (the second, i believe), this notion of public good was explicit. the US did not have corporate charters from the beginning, partly because the king didn't want to grant them, and then later because the founders were unsure of the appropriateness of it. i have read some works from that time that express a believe that limited liability was immoral. it is possible that when the US finally adopted the idea of limited liability via corporations, the whole sense that there was an exchange between the broader society and the organization was never codified into law. it was certainly present in the discussions of the idea that predated its adoption into law.
if you step back and think about it, however, there is some sense in which the understanding is explicit: there is no earthly reason why the state would grant you with limited liability unless it believed it was in its best interest to do so. since granting it actually removes certain potential benefits to the state (via legal action), there must presumably be some reason why the charter was issued. US society has not always believed that limited liability companies were a good thing - presumably we do now, and whatever the reason, it presumably implies a belief the the LLC's existence will bring benefits to us all.
From Stephen Probert, deputy director of the UK patent office:
"It seems ludicrous that a
patent for one technology can
cover another but patents are
anything but precise and are
meant to cover things that
aren't yet invented," he says.
Corporations exist for the sole purpose of making money
this is a common misconception. people may decide to form a corporation for the sole purpose of making money, but people cannot create a corporation without the agreement of the state. the state agrees to remove personal and legal financial responsibility from the owners because it is convinced that the public good will be
served by so doing (e.g. that the company will
accomplish things, offer services etc. that it would not without this legal allowance). without
a corporate charter, company owners are legal
liable for all actions of their company, which
is generally considered to be a bit restricting
on what they may consider doing.
so, no, corporations do not exist for the sole purpose of making money. they exist because at some point in the past, people decided it was in the public interest to allow them to exist. if a corporation's existence does not serve the public interest, then it is entirely legal to retract its
charter. that this is rarely done says more about politics than anything else.
and it's our duty to extract that value for our shareholders
actually, not quite. when your corporation was
given its charter, there was an implication
that it was given for the good of the public. presumably, your corporation was likely to perform some public good, in return for which we (the public) decided to remove personal responsibility from the company owners and controllers. you therefore have a primary duty to perform a public good, and if you cease to do so, we
should remove your corporate charter and allow you to act as privately owned business with full
financial and legal culpability. once you make it clear your corporation is living up to the charter, then you can focus on the secondary duties towards your shareholders.
i suggest you read the man page for strncpy(3).
The strncpy() function is similar, except that not more
than n bytes of src are copied. Thus, if there is no null
byte among the first n bytes of src, the result wil not be
null-terminated.
this is a classic source of bugs in string
manipulating code written in C.
did jon live through the same 20 years that i did?
on
Heart of the Net
·
· Score: 2
From the beginning, the Net has always seemed to have a heart - a locus, a center of activity. At first the academics and defense researchers who'd created and patched together its
architecture were its pulse. Then hackers in suburban bedrooms all over the country became the epicenter, followed by the free music and intellectual property guerrillas;
this ordering is completely wrong. hackers in suburban bedrooms didn't have internet (i.e. tcp/ip) access to the net for several years after the unix programming community (not the defense community) had a significant presence. it is in that community from which most intellectual property guerillas have their roots.
Unless you're selling things on AOL
or MSN, there's no longer any way even to reach a significant chunk of the Net universe, including the tech elites who still wield so much
influence in cyberspace.
this is absurd. its the "tech elites" that are precisely not the target of AOL and MSN.
Since the Net has always been an almost organic, free-form entity -- nobody's in charge of it, or really decides how it will evolve and grow -- its epicenter floats all over.
heh. go tell that to DARPA. the net has not always been a free-form, organic entity. it didn't become so till relatively late in its current lifetime.
For a while, the
heartbeat resided in the dream of new kinds of virtual and media communities -- the WELL, ECHO, Salon, Slate -- that popped up to connect people of common cultural or political interests.
pardon? what do the WELL and ECHO have to do with Slate and Salon, the latter two being for-profit
online journalism and the first two being
not-for-profit community exchange forums?
i am normally quite tolerant of Jon's articles here and amazed by the intensity of the abuse he suffers. on this occasion however, he's written an article that is really amazingly poorly constructed, thought out and written.
Re:Chinese Rooms and Software Guys
on
Arguing A.I.
·
· Score: 2
actually, dennett would say that "intentionality" is only observable to entities outside the supposedly intentional system. his book on
intentionality is older than "consciousness explanined" but to my taste has a much more solid argument: intentionality is a label that observers attach to objects to explain their behaviour, and that it doesn't necessarily correspond to any internal phenomena at all.
of course, since most of us verbally report
the experience of having intentions, there is more to this argument than meets the eye, and for that reason alone, his book is recommended.
true, swapping (actually, its technically called paging - swapping generally refers to moving
an entire address space between RAM and a storage device) is the end for such systems.
however, the design of the VM code affects things long before we get to swapping. in particular, it interacts in important ways with the buffer cache, which can affect streaming performance on most
filesystems.
ps. you'll love ardour even more when its finished!
it seems that the vast majority of commentary here all assumes that a linux machine is run as a server, or at best, some kind of generic desktop machine.
while linux may be very good at running servers, and may be capable of acting as a good generic desktop machine, some of us are interested in it for much more specific tasks such as realtime audio processing, editing, synthesis and recording.
we care about those extra 2 seconds spent in the VM code during a benchmark. we care about all the extra paging that goes on with some designs. we care about the internal operation of the buffer cache and how it affects attainable peak i/o performance because we stream, and when i say stream, i'm not talking about measly HTTP numbers, i'm talking about 64-128 streams of 24 or 32 bit 96khZ audio data.
stop assuming that a top-end linux box is a server, please.
you obviously don't know very much about
amazon.com's internal model. despite the rise in held inventory, amazon.com continues to operate what we termed "almost-in-time" stock handling, which was (and mostly still is) a completely different model than that used by any other mail order retailer at the time. Walmart don't do it, LL Bean doesn't do it, and neither does Sears.
this model required a totally different set of software to be written. the existing off-the-shelf inventory management systems that were available in 1994 all assumed that you either had items in stock, or they were on back order, or you had dropped the item. despite some head scratching, there was no way to convert this model into the one amazon.com was going to use, so we had to write our own code. i know this because i wrote that code.
this is misleading. most processors are not busy
most of the time unless you're running
numerically intensive applications that
take a long time to finish. most of the delays in modern applications from i/o delays, and
being multithreaded and running on an SMP system doesn't help with that without careful application design.
very few people are using computers in ways
that max out their processor capacity. adding
an extra CPU doesn't most people.
it might be wise to try and avoid making such
detailed comments when you
actually don't know what you're talking about.
Audio latency on linux can be easily reduced to about
2.6ms at 48kHz on most current audio interfaces.
At 96kHz, it can go down to 1.3ms. Yes, you need
to be running the low latency patch for this
to work well, and the application is question has
to be written by someone who understands real
time programming (true for any OS, including BeOS). You say "where it will stop, nobody knows" - I'm here to tell you that it stops there, and that in addition, i don't understand your response to this patch. Its widely understood to be necessary for Linux, has existed in various forms for more than 2 years, and is a reasonable candidate for mainstream inclusion at some point.
with some cards, its possible to go significantly below these figures. The low latency patch seems to make numbers down to around 0.75ms feasible.
Context switches take a tiny amount of time
compared to the numbers we're talking about here.
There is a constant component, which on a PII 450, which is by now an ancient CPU, is about 20usecs, and a variable component that depends on how much of the cache contents associated with the task has been invalidated since it last ran. This can cause
a significant increase in the effective context switch time, but its quite manageable.
nobody in their right minds would be using different threads for the i/o chain you describe.
"can't read the clock - thats a syscall - latency". it takes about 60usec to call gettimeofday on a PII 450. if thats too slow,
you can use the rdtscl instruction (intel only), which takes about 12 cycles.
If you're interested in audio on linux, i suggest you join either the linux-audio-development or the linux-audio-users mailing lists. There's a lot of expertise there that you could learn from, and perhaps some things you could contribute.
Paul Davis
Linux Audio Systems
thats complete nonsense. the behaviour you're describing is what any multitasking kernel does. it has nothing to do with the preemptive kernel patch, which ensures that when a task becomes runnable (for example, due to a device interrupt that tells the CPU that a condition the task was waiting for is met), it can start running ASAP, rather than waiting till the next regular re-scheduling point. ASAP here means within
at most a millisecond or two. There will be always be places where the kernel has to prevent this
from happening; the goal is to minimize (and document) those places.
MOTU have NO interfaces for IEEE1394. There is no standard for transmitting audio or MIDI over IEEE1394. Unless you connect MOTU's external units to their PCI/PCMCIA interface card, their devices are useless. Since they don't provide and have demonstrated considerable antipathy to Linux driver support for their interface cards, their equipment is useless for those of us not using Windows or MacOS.
One day, there will hopefully be a real standard for audio+MIDI over IEEE1394, and bullshit like the current situation, with 3-5 different "1394-using" interfaces none of which are compatible with each other, will become a historical inconvenience. But don't hold your breadth. Everybody seems to think they (and their format) will be the one to win this competition.
--p
Slashdot Mirror
when land is owned publicly, it is treated badly there is no evidence for this claim as a general one about human society. you have perhaps heard of the book "the tragedy of the commons", which was one of the first to expound this idea, and suggest that private ownership of land resulted in better caretaking. unfortunately, the book was wrong, and even the author now acknowledges that he did not do enough cross-cultural or a deep enough historical review before writing the book. there are hundreds of examples from human cultures throughout history where public ownership of land has resulted in better treatment of the land and its resources. what typically goes wrong is when there is a breakdown in the cultural traditions that ensure proper stewardship, and nothing to replace them. a google search for "tragedy of the commons" will provide many links to the anthropological and historical research to support what i have said here.
the design of ALSA divides it into 3 layers. alsa-lib lives in user space, and provides a friendlier API for audio+MIDI than POSIX' open/read/write/close/ioctl calls. within the kernel there is the "midlevel" layer which is generic across all support hardware, and then the "lowlevel" layer which contains drivers specific to certain hardware. The lowlevel drivers are the responsibility of specific authors and can be changed, fixed, altered and otherwise evolved quite independently of the midlevel ALSA code. Thats why the specific operation of a given lowlevel driver is not the point - if it defers interrupt handling incorrectly, or not at all, then just that low level driver is broken, not ALSA in general. if you believe that the mid-level code contains the potential for a priority inversion, then you should explain why in some detail. if you have examples of low-level drivers that have similar issues, it would be wise to point them out. however, my impression is that you don't know how ALSA has been designed, nor its record of successful operation to date. when priority inversion is a possibility, its generally not that hard to induce. i have never seen any report of this on alsa-devel or linux-kernel since ALSA begain development.
- a long-lived media (cost about $1)
- cross-artist "success" insurance gamble
(value uncertain, but possibly high)
- marketing costs (cost about $2 for newish
or niche artists)
- artist representation costs
- royalty collection and distribution costs
Sure, the download of a CD's worth of data (and BTW, where do you live that you have access to GB/sec communications?) is not worth very much viewed a pure information, but the CD itself implicitly represents much more than that.strange that i personally know a dozen then, eh? the OSS API is so broken that your definition of "works fine" must be so limited as to be almost as useless as an SB AWE 64 card, with its bizarre duplex configuration that OSS also cannot model correctly.
there are Mac/PPC drivers in the tree already, and some of the PCI-based cards have been tested under Linux on the Alpha.
Your anonymous coward status doesn't impress me. ALSA was designed by essentially 2 people for the audio side and 2-3 for the MIDI side. What committee? Either you were asleep or you were never a part of the discussions on alsa-devel that led to the current design. Any complexity it presents is a result of a desire to be able to handle any and all audio interfaces, which a simpler structure (and we tried many) could not do. No, ALSA was not designed with the ordinary end-user in mind. ALSA is a set of device drivers. It is part of the kernel, which provides mechanism, not policy, for user space. The stuff that will be designed for users mostly doesn't exist yet because too many audio developers have continued to write code around the OSS API. they can't be blamed entirely - the ALSA API was incredibly unstable for some time. yes, its poorly documented. no its not extremely buggy. hardware support is wider than OSS and in some specific areas, deeper.
You're either a troll or you don't know anything about something you write with an authoritative tone about. The design of ALSA with respect to SMP systems, spin locking and interlocking access is probably better than almost any existing system in the kernel. As for deferrment of interrupt handling, thats entirely a function of individual "lowlevel" card drivers, and its possible that there are better ways for certain drivers to handle their hardware's interrupt. However, audio hardware is real-time in that it continues to run whether the CPU services it promptly or not. This requires a rather different kind of design than the one used for, say, disk drives. finally, the proof is in the pudding. many of us have been using ALSA for several years, and it has worked better on both UP and SMP systems than the old OSS API, and without any bizarre kernel issues.
let me put that another way. the OSS API required that the data delivered to the interface match the way the interface was configured. this results in every app that needs to write floating point data to an interface requiring 16bit samples to handle it themselves. dumb. however, when the OSS API is used with a card for which there is no existing configuration description possible with OSS (the RME Hammerfall is the canonical example), then all the format conversion between the format used in user space (to match the OSS description of the configuration) and the actual hardware setup has to be in the kernel, since nothing interposes between the write(2) call and the driver itself. what was also in the kernel (for example) was the code to drive the OSS "soft synth". there was really nowhere else to put this because of the design of the OSS "sequencer" (which in both ALSA and OSS is really a router and scheduler rather than a "sequencer" in the conventional sense). this is because access to the OSS sequencer is via a /dev/ node, and thus all code related to its operation has to be in kernel space.
with the low latency patch and SCHED_{FIFO|RR} scheduling there is no reason to put a soft synth of any type in the kernel. i have been trying to encourage the ALSA sequencer coder(s) to move most of it into user space, for similar reasons.
sorry for the misleading suggestion that all format conversion code was in the kernel before.
- application access was always via direct
access to
/dev/* nodes, requiring
all format conversion and other
"fancy" code to reside in the kernel
- no possible generic support for non-interleaved cards
- no uniform API for mmap-based access
- no support for advanced h/w features without
highly hw-specific code
When using ALSA, although it remains theoretically possible to use open/read/write/ioctl/close(2) and accessyou seem to believe that people want "more moderate" candidates. several times you suggest that a NOTA strategy would encourage this. i would suggest that people want more diverse candidates (i'm not talking skin color here, but political perspectives), more discussion of genuine political alternatives, more personal opinion and less lobbyist-generated newspeak. NOTA might help with that, but its not clear that it would help anymore than a number of other electoral reforms such as one of the various forms of proportional representation.
#include
class While : public SigC::Object
{
While (SigC::Slot0 slot) {
while (slot.emit ());
}
};
....
While w (slot (some_object,
&SomeObject::method));
i don't have a reference for you i'm afraid. i know that when corporate charters were introduced into english law under Charles (the second, i believe), this notion of public good was explicit. the US did not have corporate charters from the beginning, partly because the king didn't want to grant them, and then later because the founders were unsure of the appropriateness of it. i have read some works from that time that express a believe that limited liability was immoral. it is possible that when the US finally adopted the idea of limited liability via corporations, the whole sense that there was an exchange between the broader society and the organization was never codified into law. it was certainly present in the discussions of the idea that predated its adoption into law. if you step back and think about it, however, there is some sense in which the understanding is explicit: there is no earthly reason why the state would grant you with limited liability unless it believed it was in its best interest to do so. since granting it actually removes certain potential benefits to the state (via legal action), there must presumably be some reason why the charter was issued. US society has not always believed that limited liability companies were a good thing - presumably we do now, and whatever the reason, it presumably implies a belief the the LLC's existence will bring benefits to us all.
From Stephen Probert, deputy director of the UK patent office: "It seems ludicrous that a patent for one technology can cover another but patents are anything but precise and are meant to cover things that aren't yet invented," he says.
Corporations exist for the sole purpose of making money this is a common misconception. people may decide to form a corporation for the sole purpose of making money, but people cannot create a corporation without the agreement of the state. the state agrees to remove personal and legal financial responsibility from the owners because it is convinced that the public good will be served by so doing (e.g. that the company will accomplish things, offer services etc. that it would not without this legal allowance). without a corporate charter, company owners are legal liable for all actions of their company, which is generally considered to be a bit restricting on what they may consider doing. so, no, corporations do not exist for the sole purpose of making money. they exist because at some point in the past, people decided it was in the public interest to allow them to exist. if a corporation's existence does not serve the public interest, then it is entirely legal to retract its charter. that this is rarely done says more about politics than anything else.
and it's our duty to extract that value for our shareholders actually, not quite. when your corporation was given its charter, there was an implication that it was given for the good of the public. presumably, your corporation was likely to perform some public good, in return for which we (the public) decided to remove personal responsibility from the company owners and controllers. you therefore have a primary duty to perform a public good, and if you cease to do so, we should remove your corporate charter and allow you to act as privately owned business with full financial and legal culpability. once you make it clear your corporation is living up to the charter, then you can focus on the secondary duties towards your shareholders.
i suggest you read the man page for strncpy(3). The strncpy() function is similar, except that not more than n bytes of src are copied. Thus, if there is no null byte among the first n bytes of src, the result wil not be null-terminated. this is a classic source of bugs in string manipulating code written in C.
From the beginning, the Net has always seemed to have a heart - a locus, a center of activity. At first the academics and defense researchers who'd created and patched together its architecture were its pulse. Then hackers in suburban bedrooms all over the country became the epicenter, followed by the free music and intellectual property guerrillas; this ordering is completely wrong. hackers in suburban bedrooms didn't have internet (i.e. tcp/ip) access to the net for several years after the unix programming community (not the defense community) had a significant presence. it is in that community from which most intellectual property guerillas have their roots. Unless you're selling things on AOL or MSN, there's no longer any way even to reach a significant chunk of the Net universe, including the tech elites who still wield so much influence in cyberspace. this is absurd. its the "tech elites" that are precisely not the target of AOL and MSN. Since the Net has always been an almost organic, free-form entity -- nobody's in charge of it, or really decides how it will evolve and grow -- its epicenter floats all over. heh. go tell that to DARPA. the net has not always been a free-form, organic entity. it didn't become so till relatively late in its current lifetime. For a while, the heartbeat resided in the dream of new kinds of virtual and media communities -- the WELL, ECHO, Salon, Slate -- that popped up to connect people of common cultural or political interests. pardon? what do the WELL and ECHO have to do with Slate and Salon, the latter two being for-profit online journalism and the first two being not-for-profit community exchange forums? i am normally quite tolerant of Jon's articles here and amazed by the intensity of the abuse he suffers. on this occasion however, he's written an article that is really amazingly poorly constructed, thought out and written.
actually, dennett would say that "intentionality" is only observable to entities outside the supposedly intentional system. his book on intentionality is older than "consciousness explanined" but to my taste has a much more solid argument: intentionality is a label that observers attach to objects to explain their behaviour, and that it doesn't necessarily correspond to any internal phenomena at all. of course, since most of us verbally report the experience of having intentions, there is more to this argument than meets the eye, and for that reason alone, his book is recommended.
true, swapping (actually, its technically called paging - swapping generally refers to moving an entire address space between RAM and a storage device) is the end for such systems. however, the design of the VM code affects things long before we get to swapping. in particular, it interacts in important ways with the buffer cache, which can affect streaming performance on most filesystems. ps. you'll love ardour even more when its finished!
it seems that the vast majority of commentary here all assumes that a linux machine is run as a server, or at best, some kind of generic desktop machine. while linux may be very good at running servers, and may be capable of acting as a good generic desktop machine, some of us are interested in it for much more specific tasks such as realtime audio processing, editing, synthesis and recording. we care about those extra 2 seconds spent in the VM code during a benchmark. we care about all the extra paging that goes on with some designs. we care about the internal operation of the buffer cache and how it affects attainable peak i/o performance because we stream, and when i say stream, i'm not talking about measly HTTP numbers, i'm talking about 64-128 streams of 24 or 32 bit 96khZ audio data. stop assuming that a top-end linux box is a server, please.
you obviously don't know very much about amazon.com's internal model. despite the rise in held inventory, amazon.com continues to operate what we termed "almost-in-time" stock handling, which was (and mostly still is) a completely different model than that used by any other mail order retailer at the time. Walmart don't do it, LL Bean doesn't do it, and neither does Sears. this model required a totally different set of software to be written. the existing off-the-shelf inventory management systems that were available in 1994 all assumed that you either had items in stock, or they were on back order, or you had dropped the item. despite some head scratching, there was no way to convert this model into the one amazon.com was going to use, so we had to write our own code. i know this because i wrote that code.
this is misleading. most processors are not busy most of the time unless you're running numerically intensive applications that take a long time to finish. most of the delays in modern applications from i/o delays, and being multithreaded and running on an SMP system doesn't help with that without careful application design. very few people are using computers in ways that max out their processor capacity. adding an extra CPU doesn't most people.
it might be wise to try and avoid making such detailed comments when you actually don't know what you're talking about. Audio latency on linux can be easily reduced to about 2.6ms at 48kHz on most current audio interfaces. At 96kHz, it can go down to 1.3ms. Yes, you need to be running the low latency patch for this to work well, and the application is question has to be written by someone who understands real time programming (true for any OS, including BeOS). You say "where it will stop, nobody knows" - I'm here to tell you that it stops there, and that in addition, i don't understand your response to this patch. Its widely understood to be necessary for Linux, has existed in various forms for more than 2 years, and is a reasonable candidate for mainstream inclusion at some point. with some cards, its possible to go significantly below these figures. The low latency patch seems to make numbers down to around 0.75ms feasible. Context switches take a tiny amount of time compared to the numbers we're talking about here. There is a constant component, which on a PII 450, which is by now an ancient CPU, is about 20usecs, and a variable component that depends on how much of the cache contents associated with the task has been invalidated since it last ran. This can cause a significant increase in the effective context switch time, but its quite manageable. nobody in their right minds would be using different threads for the i/o chain you describe. "can't read the clock - thats a syscall - latency". it takes about 60usec to call gettimeofday on a PII 450. if thats too slow, you can use the rdtscl instruction (intel only), which takes about 12 cycles. If you're interested in audio on linux, i suggest you join either the linux-audio-development or the linux-audio-users mailing lists. There's a lot of expertise there that you could learn from, and perhaps some things you could contribute. Paul Davis
Linux Audio Systems
thats complete nonsense. the behaviour you're describing is what any multitasking kernel does. it has nothing to do with the preemptive kernel patch, which ensures that when a task becomes runnable (for example, due to a device interrupt that tells the CPU that a condition the task was waiting for is met), it can start running ASAP, rather than waiting till the next regular re-scheduling point. ASAP here means within at most a millisecond or two. There will be always be places where the kernel has to prevent this from happening; the goal is to minimize (and document) those places.
MOTU have NO interfaces for IEEE1394. There is no standard for transmitting audio or MIDI over IEEE1394. Unless you connect MOTU's external units to their PCI/PCMCIA interface card, their devices are useless. Since they don't provide and have demonstrated considerable antipathy to Linux driver support for their interface cards, their equipment is useless for those of us not using Windows or MacOS. One day, there will hopefully be a real standard for audio+MIDI over IEEE1394, and bullshit like the current situation, with 3-5 different "1394-using" interfaces none of which are compatible with each other, will become a historical inconvenience. But don't hold your breadth. Everybody seems to think they (and their format) will be the one to win this competition. --p