this device sounds very interesting, and as an avid MD user myself, i'd like to see exactly what its functionality includes. but i've got another questions:
is there an MD-based device that can be used on a personal computer to directly read tracks (digitally) from MD to the hard drive? (like "ripping" an AIFF or WAV from a CD-ROM drive)
i'm a DJ, and i use MDs a lot to record sets (both live and in the studio). it would be a godsend to be able to record and edit tracks on the MD and then copy them to the harddrive for CD-mastering. (especially if the track information could be relayed). currently i'm just recording through my audio ins, which requires doing the track layouts and editing all over again -- a HUGE hassle, as this is MUCH easier to do on MD than on the computer.
i know that an MD-data drive exists, but the MD manufacturers, keen on their closed standards, ensured that data MD-drives cannot read audio-MD disks (and vice-versa). (i won't get into bitching about this -- slashdot users are more than familiar with how closed standards harm consumers).
so does anybody have any information on this? perhaps this new device from Sharp might even save the day? (of course, that is if there's software for it available under Linux or MacOS).
- j --- "The only guys who might buy [the Apple iBook] are the kind who wear those ludicrous baggy pants with the built-in rope that's used for a belt." - John C. Dvorak, PC Magazine
this seems like a bit of a silly question to me. i've used both Perl and C (or C++) in my CGIs, but it entirely depends on what you're trying to implement.
Perl is phenomenal at working with text, and it's dead easy to write. you don't have to worry about what type of information is stored in your variables (strings, ints, etc) and Perl does the conversions for you if you need to work with variables of different types. CGIs, historically, did a lot of work with text -- inputing forms, searching text files and dynamically creating HTML.
if you're working on a huge, complex CGI that would be highly speed dependant and necessary to thousands of users, then use C. if not, use Perl (or whatever else fits your program best). in the past, CGI scripts were (generally) simple routines for very specific tasks. as they become more complex, Perl may not be the best answer.
it's a simple case of the best tool for the job. use whatever language works best for you.
- j -- "The only guys who might buy [the Apple iBook] are the kind who wear those ludicrous baggy pants with the built-in rope that's used for a belt. - John C. Dvorak, PC Magazine
useless comment, but i, for one, really hope neuron regeneration does exist. otherwise i might end up paying for all those years of excessive drug use in my youth... oh my...:)
- j
--- "The only guys who might buy [the Apple iBook] are the kind who wear those ludicrous baggy pants with the built-in rope that's used for a belt." - John C. Dvorak, PC Magazine
perhaps what many are saying is true: software isn't like most other industries, but it's really not that diffent from the semiconductor industry. yet for some reason, we don't just have wild "crashing" and "bugs" in semiconductors (short of the occassional pentium slip-up:).
i think you're cutting software developers too much slack. sure software is difficult and complex, but have you really tried to understand the layout of cutting edge semiconductors?
i used to work for an FPGA manufacturer (who shall remain nameless). our FPGAs were/are cutting edge, and despite my degree in Electrical Engineering (with an emphasis on semiconductor design), i couldn't even come close to truely understanding half of what goes on inside those things.
our chips rarely had a hardware problem when things went to ship. but we were constantly having quality issues in Product Engineering (where i worked). why? because the software was, quite simply, lousy.
now don't get me wrong -- place and route routines can get pretty hairy, but i've seen the source code to the programming software, and i can assure you that's not 1/10th as complex as the chip their trying to program. but when i would confront the Software group about their buggy software, they gave me the typical arrogant "you don't understand computers" response, and more or less stated that software is just plain buggy by nature.
bullshit.
why is it that software programmers don't have the same idea of quality that hardware designers have? why do they automatically assume that software can't be (relatively) bug-free like complex hardware can be? i noticed it more than ever working at this FPGA manufacturer -- many software programmers simply can't think of software being any other way.
and this isn't a case of capitalism-driven bugs. this company isn't making any profit off of selling software updates. in fact, the majority of time-to-market goals we missed were due to the multitudes of software problems we had to overcome.
so to all you software developers who can't seem to comprehend the importance of design and testing: try taking a hint from your hardware-designing associates and smarten up!
let's start dispelling the myth: software doesn't need to suck!
- j -- "The only guys who might buy [the Apple iBook] are the kind who wear those ludicrous baggy pants with the built-in rope that's used for a belt." - John C Dvorak - PC Magazine
i'm seeing a lot of comparisons to the DARE program here, and that's not at all surprising. i think we're going to find that this campaign is going to suffer the same fate -- an excessive amount of the public's tax dollars wasted in a program that makes the situation worse.
of all the (non-biased) statistics i've ever seen, DARE graduates do more drugs than their non-DARE-educated peers. is this a surprise to anyone? children are fed drug propoganda, and kids aren't stupid -- they know they're not getting the full story. so a good chunk of the kids become more interested in finding out what this whole "drug thing" is about and start experimenting.
as mentioned above in the "this is going to backfire" thread, this program will probably have the same outcome -- a good chunk of the kids will become curious about "hacking" and start finding out what it's all about on their own. this entire program is going to waste a whole lot of money, and just end up with even more script kiddies to plague the internet.
what needs to be taught is ethics. and sorry, but i don't trust the DOJ to teach their twisted form of ethics to my kids -- i'll do that myself, thanks.
sorry i'm a little bitter -- though i don't blame it, DARE still played a pretty big part in some of my friends getting addicted to Crystal Methamphetamine. now they don't listen to any scientific drug research because all DARE taught them was that all drug information is propoganda.
- j
-- "The only guys who might buy [the Apple iBook] are the kind who wear those ludicrous baggy pants with the built-in rope that's used for a belt." - John C Dvorak - PC Magazine
Slashdot Mirror
i'm sure you were kidding, but just on the off chance that you weren't, his chili recipe is here:
http://www.natures-fx.org/chili.htm
i'd hate to see you go hungry on Thanksgiving! :)
- j
this device sounds very interesting, and as an avid MD user myself, i'd like to see exactly what its functionality includes. but i've got another questions:
is there an MD-based device that can be used on a personal computer to directly read tracks (digitally) from MD to the hard drive? (like "ripping" an AIFF or WAV from a CD-ROM drive)
i'm a DJ, and i use MDs a lot to record sets (both live and in the studio). it would be a godsend to be able to record and edit tracks on the MD and then copy them to the harddrive for CD-mastering. (especially if the track information could be relayed). currently i'm just recording through my audio ins, which requires doing the track layouts and editing all over again -- a HUGE hassle, as this is MUCH easier to do on MD than on the computer.
i know that an MD-data drive exists, but the MD manufacturers, keen on their closed standards, ensured that data MD-drives cannot read audio-MD disks (and vice-versa). (i won't get into bitching about this -- slashdot users are more than familiar with how closed standards harm consumers).
so does anybody have any information on this? perhaps this new device from Sharp might even save the day? (of course, that is if there's software for it available under Linux or MacOS).
- j
---
"The only guys who might buy [the Apple iBook] are the kind who wear those ludicrous baggy pants with the built-in rope that's used for a belt." - John C. Dvorak, PC Magazine
this seems like a bit of a silly question to me. i've used both Perl and C (or C++) in my CGIs, but it entirely depends on what you're trying to implement.
Perl is phenomenal at working with text, and it's dead easy to write. you don't have to worry about what type of information is stored in your variables (strings, ints, etc) and Perl does the conversions for you if you need to work with variables of different types. CGIs, historically, did a lot of work with text -- inputing forms, searching text files and dynamically creating HTML.
if you're working on a huge, complex CGI that would be highly speed dependant and necessary to thousands of users, then use C. if not, use Perl (or whatever else fits your program best). in the past, CGI scripts were (generally) simple routines for very specific tasks. as they become more complex, Perl may not be the best answer.
it's a simple case of the best tool for the job. use whatever language works best for you.
- j
--
"The only guys who might buy [the Apple iBook] are the kind who wear those ludicrous baggy pants with the built-in rope that's used for a belt. - John C. Dvorak, PC Magazine
useless comment, but i, for one, really hope neuron regeneration does exist. otherwise i might end up paying for all those years of excessive drug use in my youth ... oh my ... :)
- j
---
"The only guys who might buy [the Apple iBook] are the kind who wear those ludicrous baggy pants with the built-in rope that's used for a belt." - John C. Dvorak, PC Magazine
perhaps what many are saying is true: software isn't like most other industries, but it's really not that diffent from the semiconductor industry. yet for some reason, we don't just have wild "crashing" and "bugs" in semiconductors (short of the occassional pentium slip-up :).
i think you're cutting software developers too much slack. sure software is difficult and complex, but have you really tried to understand the layout of cutting edge semiconductors?
i used to work for an FPGA manufacturer (who shall remain nameless). our FPGAs were/are cutting edge, and despite my degree in Electrical Engineering (with an emphasis on semiconductor design), i couldn't even come close to truely understanding half of what goes on inside those things.
our chips rarely had a hardware problem when things went to ship. but we were constantly having quality issues in Product Engineering (where i worked). why? because the software was, quite simply, lousy.
now don't get me wrong -- place and route routines can get pretty hairy, but i've seen the source code to the programming software, and i can assure you that's not 1/10th as complex as the chip their trying to program. but when i would confront the Software group about their buggy software, they gave me the typical arrogant "you don't understand computers" response, and more or less stated that software is just plain buggy by nature.
bullshit.
why is it that software programmers don't have the same idea of quality that hardware designers have? why do they automatically assume that software can't be (relatively) bug-free like complex hardware can be? i noticed it more than ever working at this FPGA manufacturer -- many software programmers simply can't think of software being any other way.
and this isn't a case of capitalism-driven bugs. this company isn't making any profit off of selling software updates. in fact, the majority of time-to-market goals we missed were due to the multitudes of software problems we had to overcome.
so to all you software developers who can't seem to comprehend the importance of design and testing: try taking a hint from your hardware-designing associates and smarten up!
let's start dispelling the myth: software doesn't need to suck!
- j
--
"The only guys who might buy [the Apple iBook] are the kind who wear those ludicrous baggy pants with the built-in rope that's used for a belt."
- John C Dvorak - PC Magazine
i'm seeing a lot of comparisons to the DARE program here, and that's not at all surprising. i think we're going to find that this campaign is going to suffer the same fate -- an excessive amount of the public's tax dollars wasted in a program that makes the situation worse.
of all the (non-biased) statistics i've ever seen, DARE graduates do more drugs than their non-DARE-educated peers. is this a surprise to anyone? children are fed drug propoganda, and kids aren't stupid -- they know they're not getting the full story. so a good chunk of the kids become more interested in finding out what this whole "drug thing" is about and start experimenting.
as mentioned above in the "this is going to backfire" thread, this program will probably have the same outcome -- a good chunk of the kids will become curious about "hacking" and start finding out what it's all about on their own. this entire program is going to waste a whole lot of money, and just end up with even more script kiddies to plague the internet.
what needs to be taught is ethics. and sorry, but i don't trust the DOJ to teach their twisted form of ethics to my kids -- i'll do that myself, thanks.
sorry i'm a little bitter -- though i don't blame it, DARE still played a pretty big part in some of my friends getting addicted to Crystal Methamphetamine. now they don't listen to any scientific drug research because all DARE taught them was that all drug information is propoganda.
- j
--
"The only guys who might buy [the Apple iBook] are the kind who wear those ludicrous baggy pants with the built-in rope that's used for a belt."
- John C Dvorak - PC Magazine