Before you start yelling OMG FASTER WHO CARES??? you might want to read the fine article:
""" WHY A NEW DEBUGGER?
In order to achieve our goals we decided to start with a fresh architecture that would support modern multi-threaded programs, handle debugging symbols in an efficient manner, use compiler based code knowledge and have plug-in support for functionality and extensions. Additionally we want the debugger capabilities to be available to other analysis tools, be they scripts or compiled programs, without requiring them to be GPL. """
This is about better code analysis and integration, not faster debugging.
The biggest difference that I've noticed btw. Chrome and Safari is about 1GB free memory when using Chrome. No exaggeration. Safari has gotten INSANELY bloated. I've been using a Chromium nightly for about two weeks and it's like night and day. Safari is beach-balls galore, while Chromium (and now Chrome) is just speedy and compact.
I quit a Safari session I was running this morning with TWO TABS and it freed 750MB. That is so wrong.
This is a bad approach that attacks the wrong end of the problem. The real problem is that *after they are accepted* self-signed certs and trusted-authority-signed certs are treated as providing the exact same guarantees. In reality they provide two distinct things, each of which has its place. Self-signed certs provide end-to-end encryption without saying anything about where the other end is. Signed certs make stronger (but not foolproof!) guarantees about the other end of the channel.
The problem is that both types of certs get you the *same* lock in the corner of the window. This is really bad, because that lock icon is the green light for grandma to enter her credit card number. She should *never* be doing that on a site with a self-signed cert, and it shouldn't matter whether or not junior was using the computer earlier and jumped through the hoops to add an exception for the cert of some promising-looking porn site. The icon needs to reflect the *guarantee*, not the delivery mechanism.
My suggestion would be to show a warning when accepting a self-signed cert that contains language and images -- people are visual -- describing the idea of secure communication with an unknown party, and make it easy to accept the cert. But for goodness' sakes, use a *different* icon, something that cannot be mistaken for a lock, to represent the security. Show an envelope, or a pipe representing the inability to look inside the connection. (I know, tubes...) I'm sure somebody brighter than myself can figure out a good icon for this status.
The thing about security as it relates to ordinary folks is you have to have a simple story to tell them or they just ignore it. "Look for the lock and you're OK" is as simple as it gets, which makes it a very good, very useful story. Putting "the lock" on self-signed cert connections dilutes that story, which is a bad, bad idea.
(As an aside, I've actually always thought the lock was too subtle. I'd rather say "when your entire browser window starts pulsing gold you're OK to enter your credit card number".)
You might be able to control the box, but right now there is no way to easily record the HD content off of the box. The amount of data is just too great.
So I take it you haven't tried. I record, transcode, and play back HD content all the time on my MythTV box, and it's just a sad little Opteron 1.8GHz
I think you're misunderstanding what I mean by "first-class application." I'm merely talking about an app having its own identity in the Dock, the ability to be assigned file extensions, etc. X11 apps can't do this stuff without cheesy proxy-app hacks. I *don't* mean "integrates with the system and uses all the system-wide resources just like a Cocoa app". I would certainly *not* expect the first releases of KDE apps to do that, though I would hope they would move in that direction over time.
As for system integration, there are areas where it's important to me and areas where it's not important. I definitely want my web browser to use the keychain for passwords, and I definitely want my mail app to work with the system address book. But when I working on a photo I'm much more interested in the quality of the image pipeline than I am about system integration. This is an area where *many* OS X apps are less than "fully functional". Pixelmator may be able to apply quartz filters but it uses an 8-bit image pipeline. You can forget about working on black & white photos -- 256 shades of gray is nowhere near enough. I'll take 16-bit working space over a swirly-twirly distortion effect any day of the week. (Actually krita can even use 32-bit float/channel working space for HDR images and specialized representations for things like watercolor layers that Pixelmator doesn't even dream of.)
This is what I'm talking about when I take exception to the sentiment that KDE has nothing to offer OS X. Krita does a job that Pixelmator just can't do, and it's cheaper to boot. I'm definitely willing to ignore system integration issues in exchange for superior results. It seems quite silly to me that so many other Mac users aren't.
We can bicker all day about what's "native" and what's not, but it really doesn't make one bit of difference. If an app does a job I need it to with an interface that doesn't get in the way then it's an asset. Sure, it would be great if everybody ported every app on the planet to Cocoa with loving devotion, but that's not going to happen. KDE has innovative and powerful apps to offer, and being able to run them as first-class apps on OS X is a Very Good Thing(TM). Furthermore, having OS X as a supported platform means those apps are likely to integrate *better* with the system over time instead of staying in the X11 ghetto.
I believe you just answered your own question. There are some really nice KDE apps available that would be great to have running native on OS X. Krita is a more capable image editor than just about anything available on Mac short of Photoshop. (Try finding any other free image editor that supports 16-bit/channel color and filter layers.) Digikam is also shaping up to be a powerful photo workflow app. I've adjusted to the Mac apps now but back in the day I would have loved to keep using kmail, which is still more functional than Mail.app. In short, more diversity == more choices == better.
Mac developers can design shinier interfaces than anyone else, but too often they gloss over core functionality and/or remain closed-source. It's valuable to have apps designed from the opposite perspective available as well.
Do you honestly believe that releasing the source code of a program to the public is a model that "maximizes their ability to hide defects in their software?" You *do* know that bonjour is open-source, don't you?
I so want Neuros to make a sensible product, but they just can't seem to get it together. It kills me, because I'm in the market for just this sort of device. Their heart is clearly in the right place, but they just don't seem to understand what people want from products. How on earth can you justify releasing a video device for geeks in late 2006 that:
no built-in wireless
doesn't support Hi-Def recording *or* playback
has no digital audio output
has only a composite RGB video output!! Not even s-video! (Strangely, there's an s-video input but no output.)
I don't know who this is supposed to appeal to. Hardcore hackers who don't care about hi-def and don't have even the slightest concern for audio/video quality? I went to the Archos OSD FAQ seriously looking for the "what the hell were you guys thinking?" question...:(
Compare this to the ATV, with built-in 802.11n, hi-def support (even if it's only 720p), digital audio, hdmi, totally buzzword-compliant. Sorry, but being open-source and even open-process can only get you so far, even with geeks.
And from the sounds of things, doing so violates the EULA of OSX. Just because you can do something doesn't me you should.
Funny, you got the moral of this story all backwards. You should have written, "just because an EULA says you can't do something doesn't mean you shouldn't."
I've had the same thought. I wonder if the folks at hydrogenaudio have done listening tests on "auto-transcoded" material to see if the golden-ears can hear significant degradation. If not, they should!
I don't know what you're talking about when you say "big", but you can only go so far with a 6MP image. If you're trying to blow it up to poster size you won't get good results.
All recordings are inherently lossless. You can never perfectly capture every bit of sound made.
I'm assuming you mean all recordings are inherently lossy. Yes, if you want to be pedantic about it, all recordings are lossy with respect to the original sound source. So what? As I'm sure you know, when we talk about lossy encodings we mean lossy with respect to a digital waveform, not the original sound source.
Putting this in a more useful perspective... If the MP3s were made from a much higher quality source than a CD, they could potentially sound much better than a CD.
Well, it depends a lot on the bitrate of the mp3. I don't care how groovy the original source was, if you encode it to 64-kbps mp3 it's going to sound like crap. It may be possible that a 128-kbps mp3 made from a 192 kHz, 24-bit source would sound better than a 128-kbps mp3 made from a 44.1 kHz, 16-bit source, but I would want some ABX testing evidence to be convinced. If you're going to try to convince me that a 128-kbps or even 192-kbps mp3 from any source will sound better than a 44.1kHz recording properly mastered from that same source then you're definitely need strong listening evidence.
Of course that's all beside the point, because the actual reason I want lossless encodings of my music is for reasons of flexability. Even if it sounds fantastic, an mp3 of any bitrate is going to be inherently less useful than a FLAC file of the recording that mp3 was mastered from. I can always make a good mp3 from the FLAC file, and if I decide I want to use ogg or aac instead of mp3 I can make files in those formats that have quality as good or better than the mp3. That's not possible if all I have is the mp3.
A glimpse of the future (sort of)
on
Barenaked USB Drive
·
· Score: 5, Interesting
This is interesting to me because I think it's a glimpse of music distribution in the near future. No, I don't mean that USB sticks will be the medium of choice in the near future, I mean that music will be released *without* CDs or even DVDs. There's a certain camp of DRM apologists who say, "but I can always just buy the CD and rip the songs myself if I don't want the DRM from the iTunes music store/Napster/whatever, therefore the DRM on those services is OK." Those people don't seem to understand that in a time when CDs are painfully hard for music companies to control (just ask Sony), their sales are plummetting, and iTMS has shown that people are willing to buy DRM-infected music online in large numbers, the days of getting new releases on CD are numbered. If I were a music exec (eew, slimy!), I would be just itching for the day I could do a full-DRM release without releasing CDs at all.
By the way, I *do* understand that in TFA the tracks are unencumbered MP3, but my point is about the limited future for CD distribution. No slight against BNL is intended, though I'm not thrilled that they're only distributing lossy encodings.
-DA
Oh, and by the way, here are a few stores where you can buy unencumbered music electronically: www.magnatune.com (lossless even!) www.bleep.com (lots of great electronica, including Boards of Canada)
Oh please. I've read the Universal Binary guidelines, and they don't anywhere say, "Macs on Intel chips will *only* support the IA-32 instruction set." IA-32 is the lowest common denominator--if you port your code to IA-32 it's guaranteed to work on x86-64. This makes it the natural target architecture for a porting guide, assuming Apple wants to leave its options open. Since there's no compelling reason for a PowerBook or Mac Mini to have a 64-bit processor, and Yonah is going to be 32-bit, I can see why they would want to have the option of shipping a few IA-32-based machines.
Again. Don't jump to conclusions based on preliminary developer materials. Nobody has said anything definitive about 64-bit programming on Macintel, so just chill out until they do.
None of the game consoles are using 970s. The processors in the game consoles will have significantly less integer power than the 970, which makes them far less attractive for multitasking, multi-user desktop computing.
The lead engineer of the Cell project spoke at my university a while back. He pointed out that the flight simulator demo on the cell ran 50 times faster than it did on the 970 where they developed it, but the Cell was somewhat slower than the 970 on integer benchmarks.
Only the ignorant are claiming Apple is switching to IA-32. Nobody outside of Cupertino knows exactly what variant of Intel architecture Apple is going to switch to. All of the speeches and press releases talk about "Intel architecture" or "Intel chips." It took a while to even figure out it was going to be an x86 variant and not IA-64. And don't try to draw conclusions from the developer kits -- the developer kits for the Xbox 360 are PowerMac G5s, but that doesn't mean Xbox 360 is going to run OS X, or that Xenon's instruction set is going to be the same as a G5's.
""" One slight clarification, TOSLINK normally does carry SPDIF. TOSLINK is primarily just detailing the physical medium, the data is still encoded as SPDIF (which can also be carried on wire). The original author didn't specify how he was intending to use SPDIF, it may have been over either medium. """
Um, I'm pretty sure S/PDIF is also the name for the physical connector, namely the RCA plug type of digital audio connector. The data is encoded as Dolby Digital, PCM, or whatever.
Same for me. Have you moved iTunes.app out of/Applications? Software Update is annoyingly picky about having everything be there, despite Apple's "apps are drag-and-droppable" paradigm.
You're severely underexperienced with console gaming, and it shows.
Wow, mr. anonymous coward, you sure saw through me. I've owned consoles ever since the original Pong, but you're right, I don't have any console experience. I bow to your superior insight!
Who knows, maybe you are an old-school PC gamer who can't stand consoles, but seriously, the last thing an actual console gamer would argue about is the handed-ness of the traditional controller layout, or the d-pad's inadequacy compared to a right-handed digital microswitch joystick with no travel (like the crap Epyx joystick that you posted).
Sorry, but who are you to say what an "actual console gamer" would or would not argue about, and what does that have to do with anything? Most console gamers today have never even been exposed to anything except d-pad controllers and aren't in a good position to comment one way or another, much like yourself. You clearly don't have a clue about ergonomics, which is obvious from your attitude about low-travel controllers. Low-travel is highly desirable for digital controllers. Why would you want high-travel to turn a switch on or off? Low-travel gives you quick, high precision control with minimal wasted effort, which is why car enthusiasts pay premiums for low-travel gear shifters.
I've used that thing before, and it would be a poor substitute for a d-pad with almost any of the best console games over the past 20 years, save few.
Whether or not that specific Epyx controller would work well for console games designed for the d-pad is totally beside the point. The point is that the d-pad concept is a crappy design, ergonomically. The point is that it's harder to control direction with precision by using the thumb of your weak hand to tilt a pad in various directions than it is to control it by using the wrist of your stronger hand to move a joystick.
Have you noticed that fighter jets are not controlled by d-pads? Have you noticed that arcade games don't have d-pads? The d-pad came about because it's the cheapest form factor to manufacture, not because it's better than the alternatives. Nintendo used it for their cheap little hand-held games and carried it over to their consoles. When Nintendo succeeded in the marketplace others copied their design, and it wasn't until years later that we got a d-pad based controller that didn't completely suck.
Compare this history to the Epyx controller, which was actually designed to be held and used in comfort, with high precision and speed, and imagine a world where this kind of design was improved upon for better durability, more buttons, multiple control surfaces, etc, and I think you'll see that we all would have been better off if the original Nintendo had tanked.
Basically, the d-pad/analog thumb pad combo is great. I doubt this unconfirmed rumor about Nintendo is true, although the possibilities for new types of games that don't require the d-pad may also be exciting.
The d-pad/analog thumb pad combo isn't what we're talking about, but it's only an improvement because you can avoid using the d-pad! You've now got a joystick but you're still stuck with it under your weaker hand (apologies to all the lefties I'm ignoring) and you still have to controll it with your thumb instead of your wrist.
I don't think so. The weaker hand is perfectly adequate for mashing buttons quickly -- all that takes is speed. Fine-grained directional control, on the other hand, requires agility, which is much higher in the stronger hand. And I don't know what kind of games you play, but in my experience you *do* change direction rapidly in most action games.
Ding, dong, the d-pad's gone, wicked pad, stupid pad, Ding, dong, the dumb-ass d-pad's dead!
Gosh, and it only took what, 20 years for Nintendo, the original perpetrators, to abandon this atrocity. The d-pad is a sadist's exercise in reverse ergonomics. You make the player hit four buttons instead of using one stick, then you put it under his left thumb when he's probably right-handed. Brilliant!
These things were incredibly comfortable to use. Unfortunately they weren't manufactured very well and would break all the time, but the ergonomics were fantastic.
I'm not quite sure what to make of the underwhelming results of teams that use Lisp in these ICFP contests every year. Of course I can see that there are many ways in which the contest isn't a "fair" test of language against language. If one team has a dozen Inria guys whose full time job is OCaml development against another team with a single Lisp hobbyist, it isn't much of a fair fight.
Funny, the winning team was a group of hobbyists and the team of INRIA guys (that included Xavier Leroy) finished 60th, though they did win the judges prize. Or did you mean that the INRIA guys were at a disadvantage because they had so much work to do outside of the contest?
As for Lisp, I don't think it has any real advantages over modern functional languages like Haskell and Ocaml. Plus, it has the disadvantage of lacking a type system to help keep bugs out of your code.
From what I heard it sounds like their entry was more Haskell than C++, and Haskell was more their tool of choice. During their acceptance speech one of them said, "I just want to apologize for the presence of C++ in our entry."
Slashdot Mirror
Before you start yelling OMG FASTER WHO CARES??? you might want to read the fine article:
"""
WHY A NEW DEBUGGER?
In order to achieve our goals we decided to start with a fresh architecture that would support modern multi-threaded programs, handle debugging symbols in an efficient manner, use compiler based code knowledge and have plug-in support for functionality and extensions. Additionally we want the debugger capabilities to be available to other analysis tools, be they scripts or compiled programs, without requiring them to be GPL.
"""
This is about better code analysis and integration, not faster debugging.
The biggest difference that I've noticed btw. Chrome and Safari is about 1GB free memory when using Chrome. No exaggeration. Safari has gotten INSANELY bloated. I've been using a Chromium nightly for about two weeks and it's like night and day. Safari is beach-balls galore, while Chromium (and now Chrome) is just speedy and compact.
I quit a Safari session I was running this morning with TWO TABS and it freed 750MB. That is so wrong.
This is a bad approach that attacks the wrong end of the problem. The real problem is that *after they are accepted* self-signed certs and trusted-authority-signed certs are treated as providing the exact same guarantees. In reality they provide two distinct things, each of which has its place. Self-signed certs provide end-to-end encryption without saying anything about where the other end is. Signed certs make stronger (but not foolproof!) guarantees about the other end of the channel.
The problem is that both types of certs get you the *same* lock in the corner of the window. This is really bad, because that lock icon is the green light for grandma to enter her credit card number. She should *never* be doing that on a site with a self-signed cert, and it shouldn't matter whether or not junior was using the computer earlier and jumped through the hoops to add an exception for the cert of some promising-looking porn site. The icon needs to reflect the *guarantee*, not the delivery mechanism.
My suggestion would be to show a warning when accepting a self-signed cert that contains language and images -- people are visual -- describing the idea of secure communication with an unknown party, and make it easy to accept the cert. But for goodness' sakes, use a *different* icon, something that cannot be mistaken for a lock, to represent the security. Show an envelope, or a pipe representing the inability to look inside the connection. (I know, tubes...) I'm sure somebody brighter than myself can figure out a good icon for this status.
The thing about security as it relates to ordinary folks is you have to have a simple story to tell them or they just ignore it. "Look for the lock and you're OK" is as simple as it gets, which makes it a very good, very useful story. Putting "the lock" on self-signed cert connections dilutes that story, which is a bad, bad idea.
(As an aside, I've actually always thought the lock was too subtle. I'd rather say "when your entire browser window starts pulsing gold you're OK to enter your credit card number".)
You might be able to control the box, but right now there is no way to easily record the HD content off of the box. The amount of data is just too great.
So I take it you haven't tried. I record, transcode, and play back HD content all the time on my MythTV box, and it's just a sad little Opteron 1.8GHz
I think you're misunderstanding what I mean by "first-class application." I'm merely talking about an app having its own identity in the Dock, the ability to be assigned file extensions, etc. X11 apps can't do this stuff without cheesy proxy-app hacks. I *don't* mean "integrates with the system and uses all the system-wide resources just like a Cocoa app". I would certainly *not* expect the first releases of KDE apps to do that, though I would hope they would move in that direction over time.
As for system integration, there are areas where it's important to me and areas where it's not important. I definitely want my web browser to use the keychain for passwords, and I definitely want my mail app to work with the system address book. But when I working on a photo I'm much more interested in the quality of the image pipeline than I am about system integration. This is an area where *many* OS X apps are less than "fully functional". Pixelmator may be able to apply quartz filters but it uses an 8-bit image pipeline. You can forget about working on black & white photos -- 256 shades of gray is nowhere near enough. I'll take 16-bit working space over a swirly-twirly distortion effect any day of the week. (Actually krita can even use 32-bit float/channel working space for HDR images and specialized representations for things like watercolor layers that Pixelmator doesn't even dream of.)
This is what I'm talking about when I take exception to the sentiment that KDE has nothing to offer OS X. Krita does a job that Pixelmator just can't do, and it's cheaper to boot. I'm definitely willing to ignore system integration issues in exchange for superior results. It seems quite silly to me that so many other Mac users aren't.
We can bicker all day about what's "native" and what's not, but it really doesn't make one bit of difference. If an app does a job I need it to with an interface that doesn't get in the way then it's an asset. Sure, it would be great if everybody ported every app on the planet to Cocoa with loving devotion, but that's not going to happen. KDE has innovative and powerful apps to offer, and being able to run them as first-class apps on OS X is a Very Good Thing(TM). Furthermore, having OS X as a supported platform means those apps are likely to integrate *better* with the system over time instead of staying in the X11 ghetto.
I believe you just answered your own question. There are some really nice KDE apps available that would be great to have running native on OS X. Krita is a more capable image editor than just about anything available on Mac short of Photoshop. (Try finding any other free image editor that supports 16-bit/channel color and filter layers.) Digikam is also shaping up to be a powerful photo workflow app. I've adjusted to the Mac apps now but back in the day I would have loved to keep using kmail, which is still more functional than Mail.app. In short, more diversity == more choices == better.
Mac developers can design shinier interfaces than anyone else, but too often they gloss over core functionality and/or remain closed-source. It's valuable to have apps designed from the opposite perspective available as well.
Do you honestly believe that releasing the source code of a program to the public is a model that "maximizes their ability to hide defects in their software?" You *do* know that bonjour is open-source, don't you?
I don't know who this is supposed to appeal to. Hardcore hackers who don't care about hi-def and don't have even the slightest concern for audio/video quality? I went to the Archos OSD FAQ seriously looking for the "what the hell were you guys thinking?" question...
Compare this to the ATV, with built-in 802.11n, hi-def support (even if it's only 720p), digital audio, hdmi, totally buzzword-compliant. Sorry, but being open-source and even open-process can only get you so far, even with geeks.
-DA
And from the sounds of things, doing so violates the EULA of OSX. Just because you can do something doesn't me you should.
Funny, you got the moral of this story all backwards. You should have written, "just because an EULA says you can't do something doesn't mean you shouldn't."
I've had the same thought. I wonder if the folks at hydrogenaudio have done listening tests on "auto-transcoded" material to see if the golden-ears can hear significant degradation. If not, they should!
I don't know what you're talking about when you say "big", but you can only go so far with a 6MP image. If you're trying to blow it up to poster size you won't get good results.
I'm assuming you mean all recordings are inherently lossy. Yes, if you want to be pedantic about it, all recordings are lossy with respect to the original sound source. So what? As I'm sure you know, when we talk about lossy encodings we mean lossy with respect to a digital waveform, not the original sound source.
Putting this in a more useful perspective... If the MP3s were made from a much higher quality source than a CD, they could potentially sound much better than a CD.
Well, it depends a lot on the bitrate of the mp3. I don't care how groovy the original source was, if you encode it to 64-kbps mp3 it's going to sound like crap. It may be possible that a 128-kbps mp3 made from a 192 kHz, 24-bit source would sound better than a 128-kbps mp3 made from a 44.1 kHz, 16-bit source, but I would want some ABX testing evidence to be convinced. If you're going to try to convince me that a 128-kbps or even 192-kbps mp3 from any source will sound better than a 44.1kHz recording properly mastered from that same source then you're definitely need strong listening evidence.
Of course that's all beside the point, because the actual reason I want lossless encodings of my music is for reasons of flexability. Even if it sounds fantastic, an mp3 of any bitrate is going to be inherently less useful than a FLAC file of the recording that mp3 was mastered from. I can always make a good mp3 from the FLAC file, and if I decide I want to use ogg or aac instead of mp3 I can make files in those formats that have quality as good or better than the mp3. That's not possible if all I have is the mp3.
This is interesting to me because I think it's a glimpse of music distribution in the near future. No, I don't mean that USB sticks will be the medium of choice in the near future, I mean that music will be released *without* CDs or even DVDs. There's a certain camp of DRM apologists who say, "but I can always just buy the CD and rip the songs myself if I don't want the DRM from the iTunes music store/Napster/whatever, therefore the DRM on those services is OK." Those people don't seem to understand that in a time when CDs are painfully hard for music companies to control (just ask Sony), their sales are plummetting, and iTMS has shown that people are willing to buy DRM-infected music online in large numbers, the days of getting new releases on CD are numbered. If I were a music exec (eew, slimy!), I would be just itching for the day I could do a full-DRM release without releasing CDs at all.
By the way, I *do* understand that in TFA the tracks are unencumbered MP3, but my point is about the limited future for CD distribution. No slight against BNL is intended, though I'm not thrilled that they're only distributing lossy encodings.
-DA
Oh, and by the way, here are a few stores where you can buy unencumbered music electronically:
www.magnatune.com (lossless even!)
www.bleep.com (lots of great electronica, including Boards of Canada)
Oh please. I've read the Universal Binary guidelines, and they don't anywhere say, "Macs on Intel chips will *only* support the IA-32 instruction set." IA-32 is the lowest common denominator--if you port your code to IA-32 it's guaranteed to work on x86-64. This makes it the natural target architecture for a porting guide, assuming Apple wants to leave its options open. Since there's no compelling reason for a PowerBook or Mac Mini to have a 64-bit processor, and Yonah is going to be 32-bit, I can see why they would want to have the option of shipping a few IA-32-based machines.
Again. Don't jump to conclusions based on preliminary developer materials. Nobody has said anything definitive about 64-bit programming on Macintel, so just chill out until they do.
None of the game consoles are using 970s. The processors in the game consoles will have significantly less integer power than the 970, which makes them far less attractive for multitasking, multi-user desktop computing.
The lead engineer of the Cell project spoke at my university a while back. He pointed out that the flight simulator demo on the cell ran 50 times faster than it did on the 970 where they developed it, but the Cell was somewhat slower than the 970 on integer benchmarks.
Only the ignorant are claiming Apple is switching to IA-32. Nobody outside of Cupertino knows exactly what variant of Intel architecture Apple is going to switch to. All of the speeches and press releases talk about "Intel architecture" or "Intel chips." It took a while to even figure out it was going to be an x86 variant and not IA-64. And don't try to draw conclusions from the developer kits -- the developer kits for the Xbox 360 are PowerMac G5s, but that doesn't mean Xbox 360 is going to run OS X, or that Xenon's instruction set is going to be the same as a G5's.
"""
One slight clarification, TOSLINK normally does carry SPDIF. TOSLINK is primarily just detailing the physical medium, the data is still encoded as SPDIF (which can also be carried on wire). The original author didn't specify how he was intending to use SPDIF, it may have been over either medium.
"""
Um, I'm pretty sure S/PDIF is also the name for the physical connector, namely the RCA plug type of digital audio connector. The data is encoded as Dolby Digital, PCM, or whatever.
Of course, I'm no stereo nut so I could be wrong.
Same for me. Have you moved iTunes.app out of /Applications? Software Update is annoyingly picky about having everything be there, despite Apple's "apps are drag-and-droppable" paradigm.
Um, you didn't try that "good javascript tutorials" link, did you.
Have you noticed that fighter jets are not controlled by d-pads? Have you noticed that arcade games don't have d-pads? The d-pad came about because it's the cheapest form factor to manufacture, not because it's better than the alternatives. Nintendo used it for their cheap little hand-held games and carried it over to their consoles. When Nintendo succeeded in the marketplace others copied their design, and it wasn't until years later that we got a d-pad based controller that didn't completely suck.
Compare this history to the Epyx controller, which was actually designed to be held and used in comfort, with high precision and speed, and imagine a world where this kind of design was improved upon for better durability, more buttons, multiple control surfaces, etc, and I think you'll see that we all would have been better off if the original Nintendo had tanked.
The d-pad/analog thumb pad combo isn't what we're talking about, but it's only an improvement because you can avoid using the d-pad! You've now got a joystick but you're still stuck with it under your weaker hand (apologies to all the lefties I'm ignoring) and you still have to controll it with your thumb instead of your wrist.I don't think so. The weaker hand is perfectly adequate for mashing buttons quickly -- all that takes is speed. Fine-grained directional control, on the other hand, requires agility, which is much higher in the stronger hand. And I don't know what kind of games you play, but in my experience you *do* change direction rapidly in most action games.
Ding, dong, the d-pad's gone,
e pyx-500xj-joystick.html
wicked pad,
stupid pad,
Ding, dong, the dumb-ass d-pad's dead!
Gosh, and it only took what, 20 years for Nintendo, the original perpetrators, to abandon this atrocity. The d-pad is a sadist's exercise in reverse ergonomics. You make the player hit four buttons instead of using one stick, then you put it under his left thumb when he's probably right-handed. Brilliant!
If you want a glimpse of how game controllers should look, go back in time and check out the epyx joystick: http://www.cedmagic.com/tech-info/remote-control/
These things were incredibly comfortable to use. Unfortunately they weren't manufactured very well and would break all the time, but the ergonomics were fantastic.
Now if only Sony and MS would follow suit...
Funny, the winning team was a group of hobbyists and the team of INRIA guys (that included Xavier Leroy) finished 60th, though they did win the judges prize. Or did you mean that the INRIA guys were at a disadvantage because they had so much work to do outside of the contest?
As for Lisp, I don't think it has any real advantages over modern functional languages like Haskell and Ocaml. Plus, it has the disadvantage of lacking a type system to help keep bugs out of your code.
From what I heard it sounds like their entry was more Haskell than C++, and Haskell was more their tool of choice. During their acceptance speech one of them said, "I just want to apologize for the presence of C++ in our entry."