That's funny, since Apple changed to use Sun's Open Firmware in their boot process. Which is much easier to write a bootloader for, because it's ducumented by a third party.
I notice that the "yaboot" linux bootloader works just fine on the new, "changed" macs, and no one ever managed to write a proper Linux bootloader (well, OK, miBoot, but it was a terrible kludge) for the old macs.
Here in the LA area, the sky at night is usually somewhere in between green, orange, and purple. Sometimes you get a gradient between all three. It's as bright at midnight here as it is a half-hour before sunrise in most other places.
I have friends who grew up here, who never saw a proper night sky. I convinced one of them to drive up a nearby mountain with myself and a couple of friends. She stepped out of the car and then stepped right back in, terrified by the stars.
There aren't any lights shining directly into my window. But I still can't sleep without the curtains drawn.
Mockingbirds start singing at 2 A.M.
Staples Center decorates itself with blue lights illuminating to top floor from below. You can see the blue light reflecting off the clouds, even if you drive two miles away and face away from Staples Center.
Reducing light pollution doesn't have to mean turning off lights. It can be as simple as installing a reflector above outdoor lights, so that light does not spill needlessly into the sky. This will also make your lights effectively brighter. Most cities are using shielded street lamps already, but I still see a lot of shopping malls and companies lighting their parking lots with un-shielded, 10,000W xenon lamps. That's just unnecessary.
Uh huh. I hate to say this, seeing as how I'm typing this on a brand new DVD iceBook, but that 5 hour battery life is only if you turn on all the powersave features and, unfortunatly, that does not work if you are watching a DVD. DVD viewing will give you about 2 hours of battery life before it dies. Enough for most movies, but not all, and certainly not two.
Well, when you're watching a DVD, the hard drive should turn itself off, and the processor isn't really doing much since the video decoding happens in the graphics chip. So if you have "allow processor cycling" and "reduce processor speed" (which isn't a big penalty, it goes from 500 to 400 MHz) checked, you'll get another boost. I *did* get about 4 hours out of it under those conditions. I was in a dark room though, with the screen brightness set low (this screen is really bright, another thing I like) so that might account for something.
2. AFAIK, ripping to ogg is a 2 step process, save the track as a wav, then encode to ogg.
Hardly. Just use a pipe:
cdparanoia (trackno) - | lame - --ogg --preset cd track.ogg
I wrote a small (~300li) C program that does buffering between the output of the ripper and the input of the encoder, improving the speed by 30%, and making it just as fast at a "cd-to-mp3" ripper.
cdparanoia (trackno) - | threadpipe | lame...
I'll probably post threadpipe on freshmeat soon enough, once I clean up the package. Reply if you want a copy before then.
BTW, most of the time here is taken by cdparanoia's extra-thorough consistency checking, which is a MUST. 75% of the mp3's I download from other people have noticable skips in them, even if the encoding is otherwise great.
Double-blind audio tests are quite difficult to administer actually--a simple volume difference of as little as 0.1 dB between the things you're trying to compare will distort your perception toward favoring the louder one. The effect is strong enough to mask more relevant differences in audio quality.
BTW, I've done a blind cola tasting, and I preferred Coke immediately. Guess I've been well-trained. But Dr. Pepper beats them all.
OK. I was under the impression that MontaVista had been doing something more like the low-latency patches. Thanks for the clarification.
However, it still looks like MontaVista provides hard realtime with millisecond scheduluer latencies, while RTLinux is faster, in the range of 10 sec latency.
I love my new iBook. I spent a long time comparing specs on new laptops and came to the conclusion that the iBook packs the most features in for the least money.
I got mine with a DYD-ROM and 256MB of memory for $1500 -- I looked at what Sony and Compaq etc. had to offer, and the nearest offerings wre usually lacking something big (like, say, the CDROM) or had about 50% of the battery life (or, even worse, didn't mention the battery life at all.) I can watch two DVD movies on this, back to back, before the battery runs out.
It works well with Linux too. The hardware is almost entirely supported now. There's a preliminary sound driver, and a daemon for answering requests from the volume/screen brightness/eject CD buttons on the keyboard. Wireless networking is fully supported, and since the iBook has an antenna built in to the case, you'll get much more range than with a run-of-the-mill 802.11 card. Power management on Apple laptops under Linux is actually better supported with pmud than with the APM support on most other laptops. Hmm, what else... the latest XFree86 supports the ATI chip with DRI support, so the video is fast. Since it's a new machine, a lot of the drivers are floating around as kernel patches on linuxppc-dev, but I fully expect them to be rolled into benh's kernel tree in the next couple weeks.
As far as I understood it, MontaVista and FSM Labs aren't even in the same ballpark -- MontaVista's technology allows for running a normal Linux process with very low input/output latencies, on the order of a couple milliseconds. This is great for multimedia applications, particularly where you need immediade auditory-visual feedback from the user's actions without any perceptible delay, without doing a lot of OS-specific coding.
RTLinux on the other hand is designed for hard real-time scheduling with microsecond latencies, but you have to write your programs for the RTLinux kernel (which runs Linux as a subprocess.) Which is great for industrial and scientific control/data acquisition applications, where you need to be guaranteed not to screw up the precise timing of your large deadly instrument, and can pay for custom programming.
Or at least, that's how I thought the distinction went.
For what it's worth, there are DivX:) players for MacOS--they've been hacked out of the Mac version of Windows Media player the same way that the x86 players were. One could probably adapt the libraries to run under Linux/PPC if one was interested enough.
My knowledge of compilers is limited, but I don't think that just because you end up with more, shorter instructions, that the compiler should take longer.
Actually the binary size is larger too--you can't compile a PPC kernel that will fit on a floppy weithout gzipping it and tacking gunzip onto the front of the code (the infamous zImage.) However this could be due to the different drivers required by the platform as well.
RISC instruction sets in general also expect the compiler to be "smarter" about optimizations. This causes the compiler to take longer.
I would thing that there is a lot of Linux software that has been
optimized for x86, since it's the dominant platform, so using LAME isn't
that unreasonable.
In general this isn't true; most programmers tend to avoid tying their code to any one architecture, because once you do that it becomes very difficult to port to another chip, and you wind up pissing off the most vocal 10% of Linux users. Any programs which compile out of the box for multiple architectures (in my experience, most of them) won't be particularly optimized for any one. LAME is a special case in that the cross-platform code was written first and then x86 opitmizations were grafted on with #IFDEFs.
The first bench mark (compiling a kernel) is invalid because, as anyone with half a brain knows, compiling a PowerPC kernel is not the same task as compiling an x86 kernel. PowerPC code, being more RISC-like, requires more instructions--making it take longer to compile on an equally fast processor.
The second test (LAME) is invalid because several important parts of LAME have been hand-optimized in x86 assembler.
Compressed formats just can't beat uncompressed formats.
If you recorded sound at 24bit/96Khz and compressed it with mp3 down to 1024 kbits/sec (somewhat less than an uncompressed CD) the end result would probably sound "better" than uncompressed CD audio. Granted, you'd have to have golden ears to tell the difference.
"Uncompressed" and "compressed" are really misnomers. There's an huge amount of information out there, you can sample sound in as many channels and at however high a frequency you want. A CD compresses the information by throwing out everything but the value of the waveform, digitized to 16 bits every 1/44,100 of a second. An mp3 encoder chooses, instead, to express sound in terms of the biggest coefficients of a set of windowed discrete cosine transforms. Because mp3 is based on a reasonably good model of how humans hear things, it ends up being able to express sound with the same amount of "quality" in fewer bits--or more quality in the same number of bits.
Your audio recordings contain VERY little signal at 12 kHz that is 7-8 times louder than signal in the 1-5kHz range. It is a non-issue. You cannot hear it.
If you integrate over the entire recording, this is true. But percussive sounds concentrate a large amount of high-frequency energy over short period of time. If you were to clamp a 12Khz lowpass filter on the input to your amplifier,
you WOULD be able to tell the difference very easily, on almost all recordings. Percussive sounds would be distinctly muffled.
Even more interesting, sounds in the real world DO have tons of high-frequency content! 40% of the energy produced by a cymbal crash is above 20 KHz.
And high-frequency transients CAN affect your subjective experience of the music. See this
for details, in particular this telling quote:
Oohashi and his colleagues recorded gamelan to a bandwidth of 60 kHz, and played back the recording to listeners through a speaker system with an extra tweeter for the range above 26 kHz. This tweeter was driven by its own amplifier, and the 26 kHz electronic crossover before the amplifier used steep filters. The experimenters found that the listeners' EEGs and their subjective ratings of the sound quality were affected by whether this "ultra-tweeter" was on or off, even though the listeners explicitly denied that the reproduced sound was affected by the ultra-tweeter, and also denied, when presented with the ultrasonics alone, that any sound at all was being played.
Interesting, eh? Despite the fact that subjects could not consciously tell the difference in an A/B test, or percieve the ultrasonics by themselves, their subjective ratings were still affected by a statistically significant amount. So blind A/B tests and hearing thresholds do not really capture all that there is to the perception of sound quality.
The flight plan for the X-43 involved a supersonic dive straight into the ocean, so that the unmanned prototype would be destroyed before the Chinese trawlers retrieved it.
I shit you not... You can go to the Edwards AFB visitor center and read brochures about it. The line marking the planned trajectory dives straight to the ocean at a point marked "experiment termination." The point being that once they ran the test, they didn't want anyone to be able retrieve the plane.
Also, the charge controlling each pixel is insulated from that of its neighbours, so pixels do not interfere with one another.
Doesn't this imply that each pixel will still have to have a separate transistor? I thought that was what made LCDs so difficult to manufacture in large sizes. Are they hoping that by not having to use a transparent substrate, the fabrication will be simplified?
Re:Warp drive silliness : somebody skipped math 10
on
Voyager Eulogy
·
· Score: 1
They've never been consistent about this... The original Enterprise went faster than 10 on several occasions in TOS; Roddenberry redefined warp speed with the asymptote at 10 for TNG, yet a first-season episode had the Traveler pushing the ship past warp 10.
Then the final episode of TNG has Riker's future Enterprise doing warp 13.
No, no, no. NP problems are not "impossible," or even "hard," and the formulas usually aren't hard either. They just take a long (exponential) time to solve. An NP-complete problem has these features:
There is no known algorithm that will compute them in polynomial time on a deterministic Turing machine.
There IS an algorithm that will compute them in polynomial time on a nondeterministic Turing machine.
There is an isomorphism, constructible in polynomial time between any NP-complete problem and any other. In other words I can convert any instance of the Traveling Salesman problem to an instance of the Knapsack problem and back again, and the conversion will in general be easier than solving the problem itself.
We usually attempt to show a problem is NP-complete by constructing the isomorphism. If I can convert an instance of, say, Maximum Clique into an instance of your problem without taking exponential time, and vice versa, then your problem is NP-complete.
A reasonable design has them row and column-addressed--which is one reason why you have the field-effect transistor there, to sample and hold the voltage until it is addressed again.
So each row needs a wire, and each column needs a wire, and all the transistors share a ground and positive voltage reference. That makes for a few thousand wires, not a few million.
The AirPort has a 56k modem, Ethernet port, and an 802.11 access point, running off of an embedded 486 (don't know which OS...) There are tens of similar devices aleady on the market from other companies. Unless you want to gloat about embedded Linux, the new Netcomm device is pretty mainstream.
"see, they took an AirPort, ripped out the wireless networking, shoved a $20 four-port hub in the same box and made it run Linux! Is that cool or what?" Well...cool in that it makes me yawn....
Slashdot Mirror
I notice that the "yaboot" linux bootloader works just fine on the new, "changed" macs, and no one ever managed to write a proper Linux bootloader (well, OK, miBoot, but it was a terrible kludge) for the old macs.
Be were just a bunch of whiners IMO.
No, the sun's never far below the horizon. you get more of a perpetual twilight.
I have friends who grew up here, who never saw a proper night sky. I convinced one of them to drive up a nearby mountain with myself and a couple of friends. She stepped out of the car and then stepped right back in, terrified by the stars.
There aren't any lights shining directly into my window. But I still can't sleep without the curtains drawn.
Mockingbirds start singing at 2 A.M.
Staples Center decorates itself with blue lights illuminating to top floor from below. You can see the blue light reflecting off the clouds, even if you drive two miles away and face away from Staples Center.
Reducing light pollution doesn't have to mean turning off lights. It can be as simple as installing a reflector above outdoor lights, so that light does not spill needlessly into the sky. This will also make your lights effectively brighter. Most cities are using shielded street lamps already, but I still see a lot of shopping malls and companies lighting their parking lots with un-shielded, 10,000W xenon lamps. That's just unnecessary.
(ducks thrown tomatoes)
Well, when you're watching a DVD, the hard drive should turn itself off, and the processor isn't really doing much since the video decoding happens in the graphics chip. So if you have "allow processor cycling" and "reduce processor speed" (which isn't a big penalty, it goes from 500 to 400 MHz) checked, you'll get another boost. I *did* get about 4 hours out of it under those conditions. I was in a dark room though, with the screen brightness set low (this screen is really bright, another thing I like) so that might account for something.
Hardly. Just use a pipe:
cdparanoia (trackno) - | lame - --ogg --preset cd track.ogg
I wrote a small (~300li) C program that does buffering between the output of the ripper and the input of the encoder, improving the speed by 30%, and making it just as fast at a "cd-to-mp3" ripper.
cdparanoia (trackno) - | threadpipe | lame ...
I'll probably post threadpipe on freshmeat soon enough, once I clean up the package. Reply if you want a copy before then.
BTW, most of the time here is taken by cdparanoia's extra-thorough consistency checking, which is a MUST. 75% of the mp3's I download from other people have noticable skips in them, even if the encoding is otherwise great.
BTW, I've done a blind cola tasting, and I preferred Coke immediately. Guess I've been well-trained. But Dr. Pepper beats them all.
However, it still looks like MontaVista provides hard realtime with millisecond scheduluer latencies, while RTLinux is faster, in the range of 10 sec latency.
You are correct about the distinction, however even by that definition rtlinux is more 'hard' than MontaVista.
I got mine with a DYD-ROM and 256MB of memory for $1500 -- I looked at what Sony and Compaq etc. had to offer, and the nearest offerings wre usually lacking something big (like, say, the CDROM) or had about 50% of the battery life (or, even worse, didn't mention the battery life at all.) I can watch two DVD movies on this, back to back, before the battery runs out.
It works well with Linux too. The hardware is almost entirely supported now. There's a preliminary sound driver, and a daemon for answering requests from the volume/screen brightness/eject CD buttons on the keyboard. Wireless networking is fully supported, and since the iBook has an antenna built in to the case, you'll get much more range than with a run-of-the-mill 802.11 card. Power management on Apple laptops under Linux is actually better supported with pmud than with the APM support on most other laptops. Hmm, what else... the latest XFree86 supports the ATI chip with DRI support, so the video is fast. Since it's a new machine, a lot of the drivers are floating around as kernel patches on linuxppc-dev, but I fully expect them to be rolled into benh's kernel tree in the next couple weeks.
RTLinux on the other hand is designed for hard real-time scheduling with microsecond latencies, but you have to write your programs for the RTLinux kernel (which runs Linux as a subprocess.) Which is great for industrial and scientific control/data acquisition applications, where you need to be guaranteed not to screw up the precise timing of your large deadly instrument, and can pay for custom programming.
Or at least, that's how I thought the distinction went.
For what it's worth, there are DivX :) players for MacOS--they've been hacked out of the Mac version of Windows Media player the same way that the x86 players were. One could probably adapt the libraries to run under Linux/PPC if one was interested enough.
Actually the binary size is larger too--you can't compile a PPC kernel that will fit on a floppy weithout gzipping it and tacking gunzip onto the front of the code (the infamous zImage.) However this could be due to the different drivers required by the platform as well.
RISC instruction sets in general also expect the compiler to be "smarter" about optimizations. This causes the compiler to take longer.
I would thing that there is a lot of Linux software that has been optimized for x86, since it's the dominant platform, so using LAME isn't that unreasonable.
In general this isn't true; most programmers tend to avoid tying their code to any one architecture, because once you do that it becomes very difficult to port to another chip, and you wind up pissing off the most vocal 10% of Linux users. Any programs which compile out of the box for multiple architectures (in my experience, most of them) won't be particularly optimized for any one. LAME is a special case in that the cross-platform code was written first and then x86 opitmizations were grafted on with #IFDEFs.
The second test (LAME) is invalid because several important parts of LAME have been hand-optimized in x86 assembler.
Blech.
If you recorded sound at 24bit/96Khz and compressed it with mp3 down to 1024 kbits/sec (somewhat less than an uncompressed CD) the end result would probably sound "better" than uncompressed CD audio. Granted, you'd have to have golden ears to tell the difference.
"Uncompressed" and "compressed" are really misnomers. There's an huge amount of information out there, you can sample sound in as many channels and at however high a frequency you want. A CD compresses the information by throwing out everything but the value of the waveform, digitized to 16 bits every 1/44,100 of a second. An mp3 encoder chooses, instead, to express sound in terms of the biggest coefficients of a set of windowed discrete cosine transforms. Because mp3 is based on a reasonably good model of how humans hear things, it ends up being able to express sound with the same amount of "quality" in fewer bits--or more quality in the same number of bits.
If you integrate over the entire recording, this is true. But percussive sounds concentrate a large amount of high-frequency energy over short period of time. If you were to clamp a 12Khz lowpass filter on the input to your amplifier, you WOULD be able to tell the difference very easily, on almost all recordings. Percussive sounds would be distinctly muffled.
Even more interesting, sounds in the real world DO have tons of high-frequency content! 40% of the energy produced by a cymbal crash is above 20 KHz.
And high-frequency transients CAN affect your subjective experience of the music. See this for details, in particular this telling quote:
Oohashi and his colleagues recorded gamelan to a bandwidth of 60 kHz, and played back the recording to listeners through a speaker system with an extra tweeter for the range above 26 kHz. This tweeter was driven by its own amplifier, and the 26 kHz electronic crossover before the amplifier used steep filters. The experimenters found that the listeners' EEGs and their subjective ratings of the sound quality were affected by whether this "ultra-tweeter" was on or off, even though the listeners explicitly denied that the reproduced sound was affected by the ultra-tweeter, and also denied, when presented with the ultrasonics alone, that any sound at all was being played.
Interesting, eh? Despite the fact that subjects could not consciously tell the difference in an A/B test, or percieve the ultrasonics by themselves, their subjective ratings were still affected by a statistically significant amount. So blind A/B tests and hearing thresholds do not really capture all that there is to the perception of sound quality.
I shit you not... You can go to the Edwards AFB visitor center and read brochures about it. The line marking the planned trajectory dives straight to the ocean at a point marked "experiment termination." The point being that once they ran the test, they didn't want anyone to be able retrieve the plane.
Also, the charge controlling each pixel is insulated from that of its neighbours, so pixels do not interfere with one another. Doesn't this imply that each pixel will still have to have a separate transistor? I thought that was what made LCDs so difficult to manufacture in large sizes. Are they hoping that by not having to use a transparent substrate, the fabrication will be simplified?
Because that doesn't violate the GPL.
Then the final episode of TNG has Riker's future Enterprise doing warp 13.
And so forth.
This is the cheese that the rat that the cat that the dog chased bit ate.
So each row needs a wire, and each column needs a wire, and all the transistors share a ground and positive voltage reference. That makes for a few thousand wires, not a few million.
"see, they took an AirPort, ripped out the wireless networking, shoved a $20 four-port hub in the same box and made it run Linux! Is that cool or what?" Well...cool in that it makes me yawn....