I've been using UNIX-based systems since I was about 14 years old, back in 1986 or so. I know my way around various UNIX-based systems (some that are still used and some that are ancient history) down into the kernel. I spent about 8 years doing systems level programming on various UNIX machines...
When I was a teenager, I too would scoff at the clueless newbies running their MSDOS and Windows 3.x. Then I actually grew up and realized that the vast majority of the population DOESN'T need to know every detail of the operating system they are using. If you think they do, or think the average user SHOULD know what's going on 'under the hood' take off your geek blinders.
Suggesting such is about akin to suggesting everyone who flies in a plane should know advanced aerodynamics, or anyone who drives a car should be able to rebuild the engine.
If Linux doesn't start getting a lot more support for 'clueness newbies' ala Helix Code's apps, you can forget about it ever becoming a serious mainstream desktop OS. Even with this support, its rather a big question whether it will all be too late.
Now, imagine an interesting scenario: say I work for a company that refuses to release the source to their driver for reasons regarding an intellectual property issue. What will happen to me, and to the source code, if I were to slyly release the source code for the driver under the GPL license?:)
1) You'd be fired
2) You'd likely be sued
3) The software still wouldn't be Open Source (despite the fact that some people might manage to get a copy of the source) as you don't own it and thus have no legal right to release it under any licence.
Re:Err, can't you just cut the first x bytes out?
on
Embedding Ads In MP3s?
·
· Score: 1
The need for a complete header depends upon the player software you use. Most like to see a header there. BUT, the header isn't required. There's no information in the header that is needed later down the road to play a segment of the MP3. In any case, the stripper programs could easily (as you mentioned0 just re-add a header after the strip.
The only fuzzy part, assuming the ads aren't fixed length, is finding the end of the ad. This would likely be done by dectecting some amount (a second or two) of silence. Not always a perfect way of doing things, but works most of the time for MD recording from an analog source, etc...
You're on the right track but it'd make more sense to pick some algorithm that is actually useful to website development to do the testing with. Using FFT to benchmark a web server is almost as ridiculously as using static text.
Any secure digital crypto system for music is of only theoretical use until the music industry can:
A) Develop a new CD/TAPE like "easy access" hardware version of this digital music (Not everyone uses the computer as their primary method of listening to music @ home. In fact, I'd say that's the VAST minority).
and
B) Get the consumers to "take" to this new technology. (Otherwise, they'll still be putting albums out on CD as always, and those will still be "rippable" no matter what fancy crypto the "For-sale-on-web" version of the album has. While getting consumers to take to CD went pretty smoothly, it still took years...And had clear benefits to the consumer. They'd have to do something really special with regards to audio quality or convienience in ADDITION to just adding secure crypto for the average consumer to convert, I think.
The portability concerns grow from there. For instance, the introduction specifies bit-lengths for various pre-defined types.
Actually, while I wouldn't hold my breath for good cross-platform C# support, specifying the bit-lengths of pre-defined types does NOT point to platform-specificness.
Java's virtual machine, as one example, specifies the lengths of pre-defined types. A Java int is always 32 bits, regardless of the underlying processor, a short is always 16 bits, etc.
One thing confused me.. They said that C# was not only platform independent but "language" dependent. That seems awful hard since you'll be writing c# applications in none other than c#
I think what the article was trying to say (but it was very vague and I'm sort of guessing here). Is that Microsoft's plans include a generalized VM. That is, a VM like the Java VM, but one that doesn't make any language assumptions at the byte-code level. Basically, a CPU in software.
This would make sense and be quite cool -- a lot of people have bashed Java in the past because the byte-code level is too "aware" of the higher-level-language. This limits, somewhat, the type of languages that can be implemented directly as Java byte-code targets (I believe there are _some_ Scheme and other language Java byte-code compilers).
Likely what he meant is that the runtime will be OS independent (if they actually release runtimes for other OSes is something that will need to be seen to be believed) whereas the development enviornment they ship will be part of Visual Studio, as are all Microsoft development environments unless you count MASM.
Wouldn't it be good to wait until the language is actually unveiled before you bash it as "crap"? Microsoft does, once in a while, actually produce something cool (even if always fairly derivative).
Huh? Did you read the article? J++ was the "embrace and extend" Java move -- it mostly failed (though Microsoft's JVM, for 1.1 compliant apps, was probably the best ever..even for running pure-Java code).
Calling "C#" an embrace and extend play on Java is like calling Java an embrace and extend play on C++. In either case they are simply two competing OO languages with a common base (C-style programming). I actually welcome this. Hopefully Microsoft will make their technology multiplatform (not holding my breath, but..). It would actually be a GOOD thing to have a serious Java competitor out there to light a fire under Sun's collective asses.
As someone else mentioned, to be fair you'd need to either run Windows 2000/NT or use a single-cpu system. Windows 98 doesn't do SMP.
In any case, despite GIMP's coolness, I'm fairly sure Photoshop would beat it hands down at most operations. The majority of CPU-sensitive operations in Photoshop are well-tuned to different processors (AltiVec PPCs, SIMD P3s, MMX, etc). GIMP is not as optimized (though it is, of course, far more portable).
I think you should look into the history of the "demo" scene for the PlayStation. The basic hardware tool used by the demo and independent development groups (some of these developments included pretty decent full-fledged games) was just a GameShark (AKA ProAction Replay). A device made by Datel which existed just for the purpose of entering simple codes into games for cheating and such.
The beauty of the GS/PAR is that it had a DB25 serial connection that allowed it to easily be linked with high-speed serial communication ports on the PC (such as the 'CommsLink card' that is talked about on the Hitmen site.
Some very enterprising hackers wrote alternative ROM sets (the ROM was flashable) for the GS/PAR that made such a setup a REALLY good development environment, including step-debugging! When you can link such a 'cheating/patching' card to a PC and have good software control on the PC side, you can do nearly anything. It makes it easy to upload data (which can include code) into the system, do a system soft reset, and viola, you are running custom code that could be whatever you wanted, on the console system. There was even two way communications such that you could 'load' datafiles off the PC for your demo/game as if they were being loaded from the PlayStation's CD.
When paired with good development tools on the PC side (like a leaked copy of SN System's PsyQ compiler system, or even just the gcc toolchain which was released as part of Sony's own Yaroze program) this made an excellent development system that was capable of doing a lot more than the simple hacks and patches you mention.
This Dreamcast setup sounds very similar, just with everything custom-made.
Slashdot Mirror
When I was a teenager, I too would scoff at the clueless newbies running their MSDOS and Windows 3.x. Then I actually grew up and realized that the vast majority of the population DOESN'T need to know every detail of the operating system they are using. If you think they do, or think the average user SHOULD know what's going on 'under the hood' take off your geek blinders. Suggesting such is about akin to suggesting everyone who flies in a plane should know advanced aerodynamics, or anyone who drives a car should be able to rebuild the engine.
If Linux doesn't start getting a lot more support for 'clueness newbies' ala Helix Code's apps, you can forget about it ever becoming a serious mainstream desktop OS. Even with this support, its rather a big question whether it will all be too late.
Moderate this up !!!!
1) You'd be fired
2) You'd likely be sued
3) The software still wouldn't be Open Source (despite the fact that some people might manage to get a copy of the source) as you don't own it and thus have no legal right to release it under any licence.
The only fuzzy part, assuming the ads aren't fixed length, is finding the end of the ad. This would likely be done by dectecting some amount (a second or two) of silence. Not always a perfect way of doing things, but works most of the time for MD recording from an analog source, etc...
You're on the right track but it'd make more sense to pick some algorithm that is actually useful to website development to do the testing with. Using FFT to benchmark a web server is almost as ridiculously as using static text.
A) Develop a new CD/TAPE like "easy access" hardware version of this digital music (Not everyone uses the computer as their primary method of listening to music @ home. In fact, I'd say that's the VAST minority).
and
B) Get the consumers to "take" to this new technology. (Otherwise, they'll still be putting albums out on CD as always, and those will still be "rippable" no matter what fancy crypto the "For-sale-on-web" version of the album has. While getting consumers to take to CD went pretty smoothly, it still took years...And had clear benefits to the consumer. They'd have to do something really special with regards to audio quality or convienience in ADDITION to just adding secure crypto for the average consumer to convert, I think.
Actually, while I wouldn't hold my breath for good cross-platform C# support, specifying the bit-lengths of pre-defined types does NOT point to platform-specificness.
Java's virtual machine, as one example, specifies the lengths of pre-defined types. A Java int is always 32 bits, regardless of the underlying processor, a short is always 16 bits, etc.
I think what the article was trying to say (but it was very vague and I'm sort of guessing here). Is that Microsoft's plans include a generalized VM. That is, a VM like the Java VM, but one that doesn't make any language assumptions at the byte-code level. Basically, a CPU in software.
This would make sense and be quite cool -- a lot of people have bashed Java in the past because the byte-code level is too "aware" of the higher-level-language. This limits, somewhat, the type of languages that can be implemented directly as Java byte-code targets (I believe there are _some_ Scheme and other language Java byte-code compilers).
This makes perfect sense.
Wouldn't it be good to wait until the language is actually unveiled before you bash it as "crap"? Microsoft does, once in a while, actually produce something cool (even if always fairly derivative).
Calling "C#" an embrace and extend play on Java is like calling Java an embrace and extend play on C++. In either case they are simply two competing OO languages with a common base (C-style programming). I actually welcome this. Hopefully Microsoft will make their technology multiplatform (not holding my breath, but..). It would actually be a GOOD thing to have a serious Java competitor out there to light a fire under Sun's collective asses.
Eh? Nobody (with a straight face) is asking them to open up the source. Applications for Linux don't have to be Open Source. CorelDraw isn't.
In any case, despite GIMP's coolness, I'm fairly sure Photoshop would beat it hands down at most operations. The majority of CPU-sensitive operations in Photoshop are well-tuned to different processors (AltiVec PPCs, SIMD P3s, MMX, etc). GIMP is not as optimized (though it is, of course, far more portable).
The beauty of the GS/PAR is that it had a DB25 serial connection that allowed it to easily be linked with high-speed serial communication ports on the PC (such as the 'CommsLink card' that is talked about on the Hitmen site.
Some very enterprising hackers wrote alternative ROM sets (the ROM was flashable) for the GS/PAR that made such a setup a REALLY good development environment, including step-debugging! When you can link such a 'cheating/patching' card to a PC and have good software control on the PC side, you can do nearly anything. It makes it easy to upload data (which can include code) into the system, do a system soft reset, and viola, you are running custom code that could be whatever you wanted, on the console system. There was even two way communications such that you could 'load' datafiles off the PC for your demo/game as if they were being loaded from the PlayStation's CD.
When paired with good development tools on the PC side (like a leaked copy of SN System's PsyQ compiler system, or even just the gcc toolchain which was released as part of Sony's own Yaroze program) this made an excellent development system that was capable of doing a lot more than the simple hacks and patches you mention.
This Dreamcast setup sounds very similar, just with everything custom-made.