I would argue otherwise. I say anything can be a beer ingredient as long as it tastes good. The German Reinheitsgebot (purity law) which limits the ingredients in beer has been noted to have stymied beer development in Germany as far as creativity goes. Is this a true beer? I don't know, but it's brewed by an extremely respected brewery and I can't wait to try the 750 mL bottle in my fridge.
See the point is that you call it vendor tie-in. The reason for it was technological limitations or design decisions at the time. They didn't intend to make the product Windows compatible at first, so it's understandable that the device came formatted HFS+ (which, by the way, Linux had no problem mounting when I was running Linux on my Powerbook; sorry you were using Windows).
While I realize this is subjective, I'd rather have the device with the more intuitive interface then just the ability to drop music right on it. I have no actual desire to drop random files into my iPod. I enjoy using software to manage it.
A couple of things. CDMA vs. GSM is unlike Betamax for one reason and like it for another reason. It's unlike Betamax because Verizon and Sprint combined have a LOT of customers. It's like Betamax in that CDMA is in some ways a superior technology to GSM. I would like CDMA a lot more if it was standard to use a SIM card like system. That said, I have Sprint even though I might get out of contract to get an iPhone.
If you're not already a Mac user, I don't see too much reason to get crazy excited. However, as a Mac user, it would be nice to get a phone or PDA that for once truly seamlessly syncs with the OS X desktop applications. I hate having to manually code the colors on my calendars on my Treo. I hate having to edit contact records on my Treo and Mac to get them right because the fields don't match up 100%. I also hate having to resolve "calendar conflicts" that exist for no logical reson. Also, it's the potential uses that have me interested more than the standard features. Currently, I don't pay for.mac, but I would if doing so would give me live calendar and contacts syncing on all devices including the iPhone. Also, the Cocoa framework on a phone opens up the possibility for useful handheld extensions of desktop applications (the upcoming OmniFocus comes to mind). Lastly, it's a music player on a phone or PDA that doesn't suck, and will sync effortlessly with my current system.
Unless you have a Mac, and your friend has a PC. When you plug your iPod into the PC, it will ask you if you want to format the device. An iPod ownig mate told me this, and I didn't believe him, but he demonstrated it to me, and it did precisely that - I was gobsmacked at how crazy the OS tie-in was. Bad Apple, bad, bad Apple.
That's a bit of FUD. That was the case with iPods originally, when they only worked on the Mac and for a little while thereafter when they had separate Mac and Windows versions. It's funny though, because if that message came up, the iPod was sold with a label not claiming it works at all with Windows, so it was very much buyer beware.
There is no such tie-in now, because all iPods are sold formatted FAT32.
Plug your iPod into a friends computer, and swap music files without installing any additional software (like iTunes)?
By mounting the iPod as a storage device and copying the files off of it. It's not hard. The filenames are messed up, but the tags are fine. It's likely that the files are named as they are so they can be easily indexed.
Such comments are really nothing but an insult to people who actually did live in Communist Russia. I know some of them, myself, and likening the United States to Soviet Russia is such a laughable comparison that you should be ashamed. Many of these people used basically all the money they had to move to countries like the US.
You are correct, sir. The attack vector is the same, keys being exposed in insecure memory in the decoder/player. The encryption of AACS itself is unlikely to be cracked as it's AES, and AES is very nifty and well studied. Even if the key searching approach fails, there *are* possibilities that some sort of attacks could be waged on the AES implementation which might be vulnerable. (For instance, I wrote AES for MATLAB. It's highly likely that my implementation could be exploited for various reasons, such as cache timing attacks.)
I think you did not consider the context of what I was posting. The parent of my comment said "saying that it's the programmers' fault for bad code is like saying being injured is the fault of a lumberjack..." It's always the programmer's responsibility to know what he's dealing with as best he can. I don't doubt any of your comments above regarding PHP's security. But the fact that you know about these things is testimony that other PHP developers also would know about them. Trust me, I'm not defending PHP, I'm *sure* there are plenty of bad design decisions in it, and I've heard lots of gripes about it. Being in the engineering and applied math disciplines, 70% of the code I write is in MATLAB and the other 30% is Java for side projects, both of which have their own "gotchas" which I try to be aware of as best I can.
Saying that it's the programmers' fault for writing bad code is like saying being injured is the fault of a lumberjack for not knowing how to use a chainsaw which is dull and jerks a lot. It's much better to start with a tool that prevents such mishaps rather than being unsafe by default.
Wow. If that's your actual, honest opinion, you scare me. It looks like "personal responsibility" is all but nostalgia for people. You know, I can make a chainsaw that I can guarantee almost 100% won't cut you, but it probably won't cut any wood either. In fact, while we're at it, we should make chefs use plastic cutlery, because gosh darn it, they might hurt themselves with those big, sharp, metal blades.
Tools are tools. While tools can certainly be poorly designed, they should never be crippled just because people might "hurt themselves." This applies for real tools and it applies for software.
At any rate, your observation is a bit off. Say we compress a 16x16 (256 pixel) image to an 8x8 (16 pixel) image, that's 1/4 the size. If you are satisfied with that 8x8 image, then there's no reason you can't compress a 128x128 image down to 8x8 as well, and in fact, it will look better because there was more information there to start with, which makes the interpolation more accurate. It's the quality of the source material which determines the quality of the result. The higher the quality you start with the better any compressed material will look.
Ok, a couple of things. First of all, it's quantization, not interpolation. Second of all, it depends on the original signal. If the signal has low entropy, it might not matter how many bits you sample it with. It's not a simple function of the better your input, the better your output. The grandparent's point about not shrinking by 75% refers to the fact that while you can fit a feature length movie on a CD with an MPEG-4 encoder such as XViD, that's not as easy with HD-DVD and Blu-Ray because both already use MPEG-4, so the gains won't be as dramatic.
As an aside, MPEG-4 is pretty remarkable in and of itself... and its nice to see that innovation in video compression has advanced, even though we've basically hit the limit with audio compression.
And to think my mod points just expired. +1 Obscure Humor
I took a lot of EE classes in my time, but not as many as I did math classes. As such, whenever I was discussing anything with someone in a EE class, saying something like e^(iwt) would get odd stares before people realized that to them I meant e^(jwt).
I agree. However, watermarks can be pretty useless. Most are vulnerable to collusion. Assume for the moment that iTunes downloads didn't have copy protection DRM, just watermarks. Now how about five of us get together and download the same file on iTunes. Then, we get together and "average our files." Often times this will destroy the watermark but leave the original media intact. There is definitely research to create collusion resistant fingerprinting (see Anti-Collusion Fingerprinting for Multimedia by W. Trappe, M. Wu, Z. Wang, and K. J. R. Liu, for instance). In the end though, just like regular DRM, it's a losing battle and there are always ways around it.
Rocket science is not easy. You cannot cut corners on development and testing and there is no substitute for the decades of experience these companies have.
Jeff Bezos is no stranger to recruiting good talent. Before Amazon, he worked at DE Shaw & Co., a premier quantitative finance firm known for ridiculous recruiting practices. Bezos will find people of the skill level he needs and compensate accordingly.
The SUV driver should have at least touched the break to clue in those behind. That he didn't is deserving of having his driver's license taken away.
No. Hardly. Sorry, but if something is dead stopped in front of me, I'm not thinking about the person behind me. I'm thinking about me and how to get away. If I can get over to the next lane with incident, I'm going to do it, whether or not I hit my brakes. Had the person behind the SUV been keeping proper distance, he would have been able to stop, as the SUV moving right before a stopped object is no different than the SUV instantly coming to a standstill, which is what the proper distance would allow.
As for the point about being "one with the traffic," that's silly too. Most people have no idea how to operate that thing they somehow received a license to legally use. No way I'm waiting for them to figure out which pedal is which when there is no need to be stopped in the first place.
But at the same time the procrastination remains. It is still the anxiety of taking on a specific task - the anxiety of having to deal with a frustrating and arduous task, even filtered out from others. That's why some TODO items still sit there for days and weeks, even though they are pretty well documented.
David Allen also discourages the use of traditional todo lists (hierarchical or otherwise) because they can be demoralizing when you don't accomplish some of your daily todos. What he does suggest is the use of a project list. A project is something that has a definite outcome like "Take Vacation in Hawaii." Every project has "next actions" associated with it, where a "next action" is the next physical thing you can do to move the project forward. Every next action has a context associated with it. So, your next action for "Take Vacation in Hawaii" might be "Talk to wife." The context for that might be @home or @wife, depending on the granularity of your contexts. Contexts enable something that traditional todo lists do not. The project list by itself gives you a vertical view... the enumerated actions you must take for completion. Contexts give you a horizontal view. E.g. if I'm at my phone, I can do all next actions associated with @phone, whether it be the next action to book the vacation or the next action to call the caterer about the party you're having next week.
This methodology is useful because projects are no longer monolithic blobs of time and effort sitting on an arbitrary list. Projects become a sequence of discrete executable actions which lead to a goal. The idea is that you think about things only as much as necessary. You won't need to rethink the project everytime you do something associated with it.
At one point in my engineering school career, I was a MechE major. As such, I had to take an introductory CAD course in AutoCAD and an advanced one in Pro/E. I didn't mind AutoCAD for the 2D stuff. We started doing some simple 3D stuff in AutoCAD and it was absolutely horrible--a complete kludge if I've ever seen one. Pro/E makes that stuff so much easier. Now, I really don't love Pro/E. In fact, CAD was one of the reasons I left MechE. There was a lot to like in MechE... but I was a lot more interested in mathematically modeling physical systems than doing CAD and actually design work. That said, Pro/E can do amazing things if you actually learn to use it well. I couldn't be bothered. I dropped the class several weeks into it.
It works in companies where minutes of downtime translates to tens of thousands of dollars. Yes, the pressure is high, but the rewards are great and it's also nice working with people who actually care.
People who slag off a language betray ignorance of when it's the right time to use it.
Great quote. Since learning MATLAB years ago, I have probably saved days of my own time. In my opinion, even though it's slow, it's one of the most amazing languages every written.
I promise I'm not trying to be a jerk here, but where does the extra dimension come from?
You are right, simple mistake on my part. It's obvious from vector dimension as sound is a simple Nx1 vector. The general comment about redundancy in the data stands.
As far as that link goes, I was going off the comment that "Results suggest that further group testing at this bitrate is unnecessary because all codecs are statistically tied near transparency."
I use some long string of LAME options that averages around 270 kbps. Sometimes I use --preset extreme. I'd say at these bitrates the quality difference between Vorbis and LAME is not distinguishable. Would I use OGG if it were more widely supported? Perhaps. In the end though, the ability to use an iPod is more valuable to me than having an entirely free codec.
Well written. However, I would argue the point about sound quality. The most recent listening test cited here basically remarks that a lot of the current codecs are equal at reasonably high bitrates. This doesn't surprise me. While there has been significant advancements in lossy image compression (e.g. JPEG vs JPEG-2000) due to the incorporation of ideas from EZW (Embedded Zero-tree Wavelet) and SPIHT (Set Partitioning In Hierarchical Trees) as well as in lossy video compression (e.g. MPEG vs MPEG-2 vs MPEG-4), there has not been a quantum leap in lossy audio compression. I think that's inherent in the medium, however. Audio is two-dimensional (f(t)). Images are three dimensional (f(x, y) ignoring color). Video is four dimensional (f(x, y, t) again ignoring color). There's going to be more redundancy in the latter two assuming the images aren't simply artificial and/or random.
I don't understand people's love affair with OGG and the associated phobia-like aversion of MP3. On the other hand, I'm a huge FLAC supporter as it is much better than what it "replaced" (e.g. Shorten). But as far as lossy audio goes, I will probably never use anything besides LAME to encode MP3s because the quality is phenomenal and the encoder is open source.
Slashdot Mirror
RICE is NOT a Beer ingredient!
I would argue otherwise. I say anything can be a beer ingredient as long as it tastes good. The German Reinheitsgebot (purity law) which limits the ingredients in beer has been noted to have stymied beer development in Germany as far as creativity goes. Is this a true beer? I don't know, but it's brewed by an extremely respected brewery and I can't wait to try the 750 mL bottle in my fridge.
See the point is that you call it vendor tie-in. The reason for it was technological limitations or design decisions at the time. They didn't intend to make the product Windows compatible at first, so it's understandable that the device came formatted HFS+ (which, by the way, Linux had no problem mounting when I was running Linux on my Powerbook; sorry you were using Windows).
While I realize this is subjective, I'd rather have the device with the more intuitive interface then just the ability to drop music right on it. I have no actual desire to drop random files into my iPod. I enjoy using software to manage it.
A couple of things. CDMA vs. GSM is unlike Betamax for one reason and like it for another reason. It's unlike Betamax because Verizon and Sprint combined have a LOT of customers. It's like Betamax in that CDMA is in some ways a superior technology to GSM. I would like CDMA a lot more if it was standard to use a SIM card like system. That said, I have Sprint even though I might get out of contract to get an iPhone.
If you're not already a Mac user, I don't see too much reason to get crazy excited. However, as a Mac user, it would be nice to get a phone or PDA that for once truly seamlessly syncs with the OS X desktop applications. I hate having to manually code the colors on my calendars on my Treo. I hate having to edit contact records on my Treo and Mac to get them right because the fields don't match up 100%. I also hate having to resolve "calendar conflicts" that exist for no logical reson. Also, it's the potential uses that have me interested more than the standard features. Currently, I don't pay for .mac, but I would if doing so would give me live calendar and contacts syncing on all devices including the iPhone. Also, the Cocoa framework on a phone opens up the possibility for useful handheld extensions of desktop applications (the upcoming OmniFocus comes to mind). Lastly, it's a music player on a phone or PDA that doesn't suck, and will sync effortlessly with my current system.
Unless you have a Mac, and your friend has a PC. When you plug your iPod into the PC, it will ask you if you want to format the device. An iPod ownig mate told me this, and I didn't believe him, but he demonstrated it to me, and it did precisely that - I was gobsmacked at how crazy the OS tie-in was. Bad Apple, bad, bad Apple.
That's a bit of FUD. That was the case with iPods originally, when they only worked on the Mac and for a little while thereafter when they had separate Mac and Windows versions. It's funny though, because if that message came up, the iPod was sold with a label not claiming it works at all with Windows, so it was very much buyer beware.
There is no such tie-in now, because all iPods are sold formatted FAT32.
Plug your iPod into a friends computer, and swap music files without installing any additional software (like iTunes)?
By mounting the iPod as a storage device and copying the files off of it. It's not hard. The filenames are messed up, but the tags are fine. It's likely that the files are named as they are so they can be easily indexed.
Let me welcome to the Soviet States of America.
Such comments are really nothing but an insult to people who actually did live in Communist Russia. I know some of them, myself, and likening the United States to Soviet Russia is such a laughable comparison that you should be ashamed. Many of these people used basically all the money they had to move to countries like the US.
You are correct, sir. The attack vector is the same, keys being exposed in insecure memory in the decoder/player. The encryption of AACS itself is unlikely to be cracked as it's AES, and AES is very nifty and well studied. Even if the key searching approach fails, there *are* possibilities that some sort of attacks could be waged on the AES implementation which might be vulnerable. (For instance, I wrote AES for MATLAB. It's highly likely that my implementation could be exploited for various reasons, such as cache timing attacks.)
I think you did not consider the context of what I was posting. The parent of my comment said "saying that it's the programmers' fault for bad code is like saying being injured is the fault of a lumberjack..." It's always the programmer's responsibility to know what he's dealing with as best he can. I don't doubt any of your comments above regarding PHP's security. But the fact that you know about these things is testimony that other PHP developers also would know about them. Trust me, I'm not defending PHP, I'm *sure* there are plenty of bad design decisions in it, and I've heard lots of gripes about it. Being in the engineering and applied math disciplines, 70% of the code I write is in MATLAB and the other 30% is Java for side projects, both of which have their own "gotchas" which I try to be aware of as best I can.
Saying that it's the programmers' fault for writing bad code is like saying being injured is the fault of a lumberjack for not knowing how to use a chainsaw which is dull and jerks a lot. It's much better to start with a tool that prevents such mishaps rather than being unsafe by default.
Wow. If that's your actual, honest opinion, you scare me. It looks like "personal responsibility" is all but nostalgia for people. You know, I can make a chainsaw that I can guarantee almost 100% won't cut you, but it probably won't cut any wood either. In fact, while we're at it, we should make chefs use plastic cutlery, because gosh darn it, they might hurt themselves with those big, sharp, metal blades.
Tools are tools. While tools can certainly be poorly designed, they should never be crippled just because people might "hurt themselves." This applies for real tools and it applies for software.
At any rate, your observation is a bit off. Say we compress a 16x16 (256 pixel) image to an 8x8 (16 pixel) image, that's 1/4 the size. If you are satisfied with that 8x8 image, then there's no reason you can't compress a 128x128 image down to 8x8 as well, and in fact, it will look better because there was more information there to start with, which makes the interpolation more accurate. It's the quality of the source material which determines the quality of the result. The higher the quality you start with the better any compressed material will look.
Ok, a couple of things. First of all, it's quantization, not interpolation. Second of all, it depends on the original signal. If the signal has low entropy, it might not matter how many bits you sample it with. It's not a simple function of the better your input, the better your output. The grandparent's point about not shrinking by 75% refers to the fact that while you can fit a feature length movie on a CD with an MPEG-4 encoder such as XViD, that's not as easy with HD-DVD and Blu-Ray because both already use MPEG-4, so the gains won't be as dramatic.
As an aside, MPEG-4 is pretty remarkable in and of itself... and its nice to see that innovation in video compression has advanced, even though we've basically hit the limit with audio compression.
And to think my mod points just expired. +1 Obscure Humor
I took a lot of EE classes in my time, but not as many as I did math classes. As such, whenever I was discussing anything with someone in a EE class, saying something like e^(iwt) would get odd stares before people realized that to them I meant e^(jwt).
* where w is really omega.
Better is subjective. The iPod interface is the best I've used. *shrug*
That was a close one. If this was another Joel on Software article, I was going to have to promptly defenestrate myself.
I agree. However, watermarks can be pretty useless. Most are vulnerable to collusion. Assume for the moment that iTunes downloads didn't have copy protection DRM, just watermarks. Now how about five of us get together and download the same file on iTunes. Then, we get together and "average our files." Often times this will destroy the watermark but leave the original media intact. There is definitely research to create collusion resistant fingerprinting (see Anti-Collusion Fingerprinting for Multimedia by W. Trappe, M. Wu, Z. Wang, and K. J. R. Liu, for instance). In the end though, just like regular DRM, it's a losing battle and there are always ways around it.
Rocket science is not easy. You cannot cut corners on development and testing and there is no substitute for the decades of experience these companies have.
Jeff Bezos is no stranger to recruiting good talent. Before Amazon, he worked at DE Shaw & Co., a premier quantitative finance firm known for ridiculous recruiting practices. Bezos will find people of the skill level he needs and compensate accordingly.
The SUV driver should have at least touched the break to clue in those behind. That he didn't is deserving of having his driver's license taken away.
No. Hardly. Sorry, but if something is dead stopped in front of me, I'm not thinking about the person behind me. I'm thinking about me and how to get away. If I can get over to the next lane with incident, I'm going to do it, whether or not I hit my brakes. Had the person behind the SUV been keeping proper distance, he would have been able to stop, as the SUV moving right before a stopped object is no different than the SUV instantly coming to a standstill, which is what the proper distance would allow.
As for the point about being "one with the traffic," that's silly too. Most people have no idea how to operate that thing they somehow received a license to legally use. No way I'm waiting for them to figure out which pedal is which when there is no need to be stopped in the first place.
But at the same time the procrastination remains. It is still the anxiety of taking on a specific task - the anxiety of having to deal with a frustrating and arduous task, even filtered out from others. That's why some TODO items still sit there for days and weeks, even though they are pretty well documented.
David Allen also discourages the use of traditional todo lists (hierarchical or otherwise) because they can be demoralizing when you don't accomplish some of your daily todos. What he does suggest is the use of a project list. A project is something that has a definite outcome like "Take Vacation in Hawaii." Every project has "next actions" associated with it, where a "next action" is the next physical thing you can do to move the project forward. Every next action has a context associated with it. So, your next action for "Take Vacation in Hawaii" might be "Talk to wife." The context for that might be @home or @wife, depending on the granularity of your contexts. Contexts enable something that traditional todo lists do not. The project list by itself gives you a vertical view... the enumerated actions you must take for completion. Contexts give you a horizontal view. E.g. if I'm at my phone, I can do all next actions associated with @phone, whether it be the next action to book the vacation or the next action to call the caterer about the party you're having next week.
This methodology is useful because projects are no longer monolithic blobs of time and effort sitting on an arbitrary list. Projects become a sequence of discrete executable actions which lead to a goal. The idea is that you think about things only as much as necessary. You won't need to rethink the project everytime you do something associated with it.
At one point in my engineering school career, I was a MechE major. As such, I had to take an introductory CAD course in AutoCAD and an advanced one in Pro/E. I didn't mind AutoCAD for the 2D stuff. We started doing some simple 3D stuff in AutoCAD and it was absolutely horrible--a complete kludge if I've ever seen one. Pro/E makes that stuff so much easier. Now, I really don't love Pro/E. In fact, CAD was one of the reasons I left MechE. There was a lot to like in MechE... but I was a lot more interested in mathematically modeling physical systems than doing CAD and actually design work. That said, Pro/E can do amazing things if you actually learn to use it well. I couldn't be bothered. I dropped the class several weeks into it.
It works in companies where minutes of downtime translates to tens of thousands of dollars. Yes, the pressure is high, but the rewards are great and it's also nice working with people who actually care.
People who slag off a language betray ignorance of when it's the right time to use it.
Great quote. Since learning MATLAB years ago, I have probably saved days of my own time. In my opinion, even though it's slow, it's one of the most amazing languages every written.
I promise I'm not trying to be a jerk here, but where does the extra dimension come from?
You are right, simple mistake on my part. It's obvious from vector dimension as sound is a simple Nx1 vector. The general comment about redundancy in the data stands.
As far as that link goes, I was going off the comment that "Results suggest that further group testing at this bitrate is unnecessary because all codecs are statistically tied near transparency."
I use some long string of LAME options that averages around 270 kbps. Sometimes I use --preset extreme. I'd say at these bitrates the quality difference between Vorbis and LAME is not distinguishable. Would I use OGG if it were more widely supported? Perhaps. In the end though, the ability to use an iPod is more valuable to me than having an entirely free codec.
Well written. However, I would argue the point about sound quality. The most recent listening test cited here basically remarks that a lot of the current codecs are equal at reasonably high bitrates. This doesn't surprise me. While there has been significant advancements in lossy image compression (e.g. JPEG vs JPEG-2000) due to the incorporation of ideas from EZW (Embedded Zero-tree Wavelet) and SPIHT (Set Partitioning In Hierarchical Trees) as well as in lossy video compression (e.g. MPEG vs MPEG-2 vs MPEG-4), there has not been a quantum leap in lossy audio compression. I think that's inherent in the medium, however. Audio is two-dimensional (f(t)). Images are three dimensional (f(x, y) ignoring color). Video is four dimensional (f(x, y, t) again ignoring color). There's going to be more redundancy in the latter two assuming the images aren't simply artificial and/or random.
I don't understand people's love affair with OGG and the associated phobia-like aversion of MP3. On the other hand, I'm a huge FLAC supporter as it is much better than what it "replaced" (e.g. Shorten). But as far as lossy audio goes, I will probably never use anything besides LAME to encode MP3s because the quality is phenomenal and the encoder is open source.