I/O to RAM is really fast compared to I/O to any block device (most USB keys appear to the host PC as block devices, because they have a little ARM7 or other low-power 16-bit MCU on them that emulates the IDE interface). So, maybe you could get a speedup by mounting any I/O intensive parts of your filesystem on a ramdisk. It might also save wear and tear on the flash (though MLC NAND is never going to be all that reliable).
Here's an fstab excerpt showing one technique: /dev/ram0/tmp tmpfs defaults,nodev,nosuid 0 3 /dev/ram1/var/run tmpfs defaults,nodev,nosuid 0 3 /dev/ram2/var/log tmpfs defaults,nodev,nosuid 0 3
This makes three ramdisks with dynamic capacity, and mounts/tmp,/var/run, and/var/log on them. The next step would be to write something to serialize and unserialize the ramdisks at startup and shutdown, and optionally snapshot them from time to time to safeguard against power failure. This example uses the parts of a filesystem that'd be I/O intensive on a server, but I don't see why you couldn't do the same thing with your home directory or whatever else. You could profile your USB distro by instrumenting your kernel, or just list your recently touched files from time to time to get a sense of where the I/O is happening.
Period after KDE, new sentence, "E17 is used, for example, in gOS 3, a lightweight distro for nerbooks."
You seem to be reading the sentence as if there were a 'which' after 'KDE,' but making two sentences would have eliminated the ambiiguity for those not used to reading long sentences. hth
Considering the depth, I'm guessing there are a couple of lightweight mirrors in there that direct both eyes to the display. However, the 0.44 OLED could certainly be used in a stereo configuration, given enough processor power -- great application for multi-core, perhaps?
Software, software, software! X86 enjoys by far the most readily available open source software, well-tested and debugged due to zillions of x86 users. Software is increasingly key in device development, as consumer expectations about device features and functionality rise. ARM will always have its place for truly mobile devices like phones. But for a web tablet you carry around the house, and plunk into a charging cradle now and then, wouldn't you rather have the same web browser exactly that's on your desktop?
Have another drink, drinkypoo, and make more blather about nothing. H/L is accurate. Intel also sold baseband phone processors to Marvell. Though PXAs are used in PDAs, mobile phones are probably 95 percent or more of their volume, I'd guess. Intel did not sell the whole XScale line... just the xscale's that go into phones.
The challenge for small towns is not growth, per se. Small towns don't want to attract retirees, for example, because they use a lot of civic services while contributing little to productivity. And, they tend to be bad tippers.
Only the most economically challenged small towns want to bring in low-wage jobs. Most small towns are interested in growing in ways that will raise the mean wage.
Most small towns these days are trying to attract professionals and creative entrepreneurs who can help build the kind of prosperity that feeds upon itself, attracting in turn other creative entrepreneurs and professionals, contributing to a sense of "happeningness," for lack of a better word.
It's a challenge, though. Most small towns have a shortage of professional people, such as lawyers, doctors, accountants, and so on. Educated, sophisticated people tend to like city life. That may change as population pressures lead to lower quality of urban life, however. And, professionals with families are likely to find small towns appealing.
Technologies such as instant messaging and essentially free long distance phone calls via VoIP make it very easy for computer professionals to export their jobs or relocate their businesses to small towns. I exported my dot-com work to a small town about three years ago, and now I can't believe I put up with the low quality of city life for so long.
US history has seen a couple of shifts between urban and rural migrations, and while cities today are growing much faster than rural populations, I wouldn't be too surprised if Jeff isn't right -- wouldn't it be ironic if technology actually helps create another "back-to-the-land" movement.
Howdy. I'm the author of the LinuxDevices.com article on RTLinux, and I have also played around a bit with demudi, the debian music distribution. Demudi (and the red hat remudi anodyne) use a 2.4 kernel patched to reduce application latency. You run all the sound aps as the root user in demudi, and jackd keeps track of real-time performance. Here's a summary of my experience.
Local songwriter wrote an album of songs, bought a Walmart PC for $300 powered by a Celery 1800 processor. He bootlegged a copy of cubase from a pal. Couldn't figure out how to use it. He then downloaded a cheap copy of cool edit pro. Recorded a dozen songs -- they sounded awful. He comes to me for help.
We install Demudi, stick in an M-Audio Delta 440 card, a $200 sound card with hardware mixer/monitor and 1/4-inch TRS 4-in/4-out breakout box. We record six songs in three days, each with 10 tracks or so, even though we had only a tiny amount of experience using ardour. We master everything at 24/96, and downsample to cd quality for the final. It sounds great!
The trickiest part is actually the downsampling, because jackd shuts the whole thing down when the CPU fails to deliver on real-time guarantees. This becomes a royal pain. We resort to shutting down all unneeded linux services in order to get the final mixes downsampled. It's a pain, but it finally works.
And the results are good. A professional sound engineer with 20 years experience listens to the results, and comments, "How many tracks were you doing at a time? Sixteen on this song? It's remarkable, because the sound doesn't get brittle. Usually, with that many tracks, things go brittle at a certain point."
Despite the fact that demudi has a real-time kernel, there *is* perceivable latency in the monitors when using software monitoring, though. Luckily, Alsa does support RME cards, and M-Audio cards -- pretty much. With M-audio cards, you have to use the console alsamixer to get to all the features of the card. But it can be done.
I don't think RTLinux would be used for real-time audio, though, since you need the Linux apps to be real-time, not just the hardware interrupts. But I don't know.
I do think the work Ingo and MontaVista are doing with native real-time Linux will have a huge impact on the A/V and effects industries.
A lot of people seem to be missing something, here. Like a Live CD, this system runs on a ramdisk, not on the CF card. With 512MB of RAM, you get about 300MB of free space, which is okay for recording a song or two at a time, even ones with a bunch of tracks. You only write the keepers onto the CF card.
The CF card will support 100,000 writes, and includes wear-leveling features that use the whole card, not just certain spots. So, realistically, I figure my musical inspiration will wear out long before the CF would fail. Like, LONG before.:-)
Also, the hard drive chatter comes from RF interference inside the case produced by the rotating magnetic disk and the electricity in the cable -- not the actual sound of the hard drive. --Henry K. (article author)
On May 5, 1862, 4,000 Mexican loyalists defeated 8,000 French and revolting Mexican troops in the Battle of Puebla, an event celebrated around the world as Cinco de Mayo. Novell has chosen this day to release the first beta of Mono 1.0, an open source alternative to Microsoft's.Net framework....
This is EXACTLY the plot of one of the best movies ever made about photography -- or anything else -- Michaelangelo Antonioni's "Blow Up."
A fashion photographer shooting a model in a park goes home to blow up the pictures, and discovers clues in the background he thinks might reveal a murder taking place. There's this great scene where he's frantically enlarging, and enlarging, and enlarging the picture (on an enlarger, in a darkroom)... and then you see the payoff, this tiny thing far in the distance that the naked eye could not have seen, a hand holding a pistol.
He returns to the park to find a body, which has disappeared the next time he returns.
Then Vanessa Redgrave drops by to try and finagle the negatives away from him.
"Blow Up" also features a great soundtrack with a score by Herbie Hancock, and a memorable scene of Yardbirds guitarist Jeff Beck (IIRC) smashing his guitar and throwing the pieces to the audience. The protagonist/photog gets away with the neck, and after a lengthy chase on foot, slows to a walk, examines the neck, and drops it in a trashcan.
One of the great all-time movies ever made, IMHO, a commentary about how we look at things, how easily we believe what we see. The whole thing dissolves into added layers of Pynchonesque mystery, rather than resolving in True Detective closure.
Also, a lot of fun 60's shenanigans. here's a pretty decent, if too negative, review.
Slashdot Mirror
I/O to RAM is really fast compared to I/O to any block device (most USB keys appear to the host PC as block devices, because they have a little ARM7 or other low-power 16-bit MCU on them that emulates the IDE interface). So, maybe you could get a speedup by mounting any I/O intensive parts of your filesystem on a ramdisk. It might also save wear and tear on the flash (though MLC NAND is never going to be all that reliable). Here's an fstab excerpt showing one technique:
/dev/ram0 /tmp tmpfs defaults,nodev,nosuid 0 3
/dev/ram1 /var/run tmpfs defaults,nodev,nosuid 0 3
/dev/ram2 /var/log tmpfs defaults,nodev,nosuid 0 3 /tmp, /var/run, and /var/log on them. The next step would be to write something to serialize and unserialize the ramdisks at startup and shutdown, and optionally snapshot them from time to time to safeguard against power failure. This example uses the parts of a filesystem that'd be I/O intensive on a server, but I don't see why you couldn't do the same thing with your home directory or whatever else. You could profile your USB distro by instrumenting your kernel, or just list your recently touched files from time to time to get a sense of where the I/O is happening.
This makes three ramdisks with dynamic capacity, and mounts
Period after KDE, new sentence, "E17 is used, for example, in gOS 3, a lightweight distro for nerbooks." You seem to be reading the sentence as if there were a 'which' after 'KDE,' but making two sentences would have eliminated the ambiiguity for those not used to reading long sentences. hth
Considering the depth, I'm guessing there are a couple of lightweight mirrors in there that direct both eyes to the display. However, the 0.44 OLED could certainly be used in a stereo configuration, given enough processor power -- great application for multi-core, perhaps?
There are several, but they top out at 333MHz 486 or so. Vortex, DMP Electronics, and other make 'em
Software, software, software! X86 enjoys by far the most readily available open source software, well-tested and debugged due to zillions of x86 users. Software is increasingly key in device development, as consumer expectations about device features and functionality rise. ARM will always have its place for truly mobile devices like phones. But for a web tablet you carry around the house, and plunk into a charging cradle now and then, wouldn't you rather have the same web browser exactly that's on your desktop?
Mod parent way up there, please!
Nah... the baseband is a whole other processor in the system, which it likely communicates with over a tty or something
Have another drink, drinkypoo, and make more blather about nothing. H/L is accurate. Intel also sold baseband phone processors to Marvell. Though PXAs are used in PDAs, mobile phones are probably 95 percent or more of their volume, I'd guess. Intel did not sell the whole XScale line... just the xscale's that go into phones.
The challenge for small towns is not growth, per se. Small towns don't want to attract retirees, for example, because they use a lot of civic services while contributing little to productivity. And, they tend to be bad tippers. Only the most economically challenged small towns want to bring in low-wage jobs. Most small towns are interested in growing in ways that will raise the mean wage. Most small towns these days are trying to attract professionals and creative entrepreneurs who can help build the kind of prosperity that feeds upon itself, attracting in turn other creative entrepreneurs and professionals, contributing to a sense of "happeningness," for lack of a better word. It's a challenge, though. Most small towns have a shortage of professional people, such as lawyers, doctors, accountants, and so on. Educated, sophisticated people tend to like city life. That may change as population pressures lead to lower quality of urban life, however. And, professionals with families are likely to find small towns appealing. Technologies such as instant messaging and essentially free long distance phone calls via VoIP make it very easy for computer professionals to export their jobs or relocate their businesses to small towns. I exported my dot-com work to a small town about three years ago, and now I can't believe I put up with the low quality of city life for so long. US history has seen a couple of shifts between urban and rural migrations, and while cities today are growing much faster than rural populations, I wouldn't be too surprised if Jeff isn't right -- wouldn't it be ironic if technology actually helps create another "back-to-the-land" movement.
Mod parent up/hilarious! Very cool poster :-)
Howdy. I'm the author of the LinuxDevices.com article on RTLinux, and I have also played around a bit with demudi, the debian music distribution. Demudi (and the red hat remudi anodyne) use a 2.4 kernel patched to reduce application latency. You run all the sound aps as the root user in demudi, and jackd keeps track of real-time performance. Here's a summary of my experience.
Local songwriter wrote an album of songs, bought a Walmart PC for $300 powered by a Celery 1800 processor. He bootlegged a copy of cubase from a pal. Couldn't figure out how to use it. He then downloaded a cheap copy of cool edit pro. Recorded a dozen songs -- they sounded awful. He comes to me for help.
We install Demudi, stick in an M-Audio Delta 440 card, a $200 sound card with hardware mixer/monitor and 1/4-inch TRS 4-in/4-out breakout box. We record six songs in three days, each with 10 tracks or so, even though we had only a tiny amount of experience using ardour. We master everything at 24/96, and downsample to cd quality for the final. It sounds great!
The trickiest part is actually the downsampling, because jackd shuts the whole thing down when the CPU fails to deliver on real-time guarantees. This becomes a royal pain. We resort to shutting down all unneeded linux services in order to get the final mixes downsampled. It's a pain, but it finally works.
And the results are good. A professional sound engineer with 20 years experience listens to the results, and comments, "How many tracks were you doing at a time? Sixteen on this song? It's remarkable, because the sound doesn't get brittle. Usually, with that many tracks, things go brittle at a certain point."
Despite the fact that demudi has a real-time kernel, there *is* perceivable latency in the monitors when using software monitoring, though. Luckily, Alsa does support RME cards, and M-Audio cards -- pretty much. With M-audio cards, you have to use the console alsamixer to get to all the features of the card. But it can be done.
I don't think RTLinux would be used for real-time audio, though, since you need the Linux apps to be real-time, not just the hardware interrupts. But I don't know.
I do think the work Ingo and MontaVista are doing with native real-time Linux will have a huge impact on the A/V and effects industries.
Mot licensed Qt/Embedded for their phones, but they do their own interface based on that, rather than using the Qtopia stack for phones
Debian Woody? Any bugs (termites)? The photos seem grainy to me... (sorry)
A lot of people seem to be missing something, here. Like a Live CD, this system runs on a ramdisk, not on the CF card. With 512MB of RAM, you get about 300MB of free space, which is okay for recording a song or two at a time, even ones with a bunch of tracks. You only write the keepers onto the CF card.
:-)
The CF card will support 100,000 writes, and includes wear-leveling features that use the whole card, not just certain spots. So, realistically, I figure my musical inspiration will wear out long before the CF would fail. Like, LONG before.
Also, the hard drive chatter comes from RF interference inside the case produced by the rotating magnetic disk and the electricity in the cable -- not the actual sound of the hard drive. --Henry K. (article author)
From this story:
Moderators: this violates LinuxDevices.com copyright. Please mod this out of existance. Thanks, Editor, LinuxDevices.com
This is EXACTLY the plot of one of the best movies ever made about photography -- or anything else -- Michaelangelo Antonioni's "Blow Up."
A fashion photographer shooting a model in a park goes home to blow up the pictures, and discovers clues in the background he thinks might reveal a murder taking place. There's this great scene where he's frantically enlarging, and enlarging, and enlarging the picture (on an enlarger, in a darkroom)... and then you see the payoff, this tiny thing far in the distance that the naked eye could not have seen, a hand holding a pistol.
He returns to the park to find a body, which has disappeared the next time he returns.
Then Vanessa Redgrave drops by to try and finagle the negatives away from him.
"Blow Up" also features a great soundtrack with a score by Herbie Hancock, and a memorable scene of Yardbirds guitarist Jeff Beck (IIRC) smashing his guitar and throwing the pieces to the audience. The protagonist/photog gets away with the neck, and after a lengthy chase on foot, slows to a walk, examines the neck, and drops it in a trashcan.
One of the great all-time movies ever made, IMHO, a commentary about how we look at things, how easily we believe what we see. The whole thing dissolves into added layers of Pynchonesque mystery, rather than resolving in True Detective closure.
Also, a lot of fun 60's shenanigans. here's a pretty decent, if too negative, review.