sorry, but that does not lend itself to readable code. if anything your example proves how badly perl suffers from not having a true switch syntax.
also, perl6 will have official switch statements, so apparently they decided that this "doesn't need one" claim was false. only it took them 20 years to come to that conclusion.
but PHP with it's endless heap of little functions that do nearly the same thing
you mean perl isn't littered with the same problem? hah. one of the touted features of perl is that there's always a zillion ways to do the same thing.
the thing i hate the most about perl is the often implicit behavior of perl. explicit programming is almost always clearer. perl freaks would claim this just demonstrates the power of perl, but it sure doesn't lend to its readibility.
the retarded perl syntax for defining functions doesnt help readability either.
that's part of the problem with perl -- the code is often incredibly terse and dense.
you can do incredibly complex things in a few characters in perl, which can be far more difficult to grok than the same thing described in 20 lines of C code.
it's both a blessing and a curse. a blessing because you can beat out very complex things quickly, and a curse because it is a major pita to maintain.
perl also stubbornly avoids some useful language constructs in the name of "language purity". eg case statements. yes i know about Case.pm, but its not stock perl. and yes i know perl6 will have it. only took them ~20 years to get there:-P
i've been gradually moving towards python and php for scripting. both are far more readable than perl, and just as powerful. yes really, php makes a nice scripting language -- there's far more to it than just spitting out html from apache.
totally classic behaviour you'd expect from an unethical corporation who wants to cover their ass and deflect blame of a major fuckup that's their own fault.
if you ever wondered about the ethical standards of harvard, here's a perfect example. instead of accepting responsibility for their fuckup, they take it out on others, in order to cover up their embarassment.
mac osx is very pretty, but the development tools are a mess.
trying to do anything scripted is difficult as apple still doesn't quite comprehend what character based applications are.
eg an application which links vs Carbon needs to have access to the gui even if it never touches it. kiss starting many applications via ssh goodbye. unfortunately apple still hasn't separated out all the purely character based functions from carbonlib. so a lot of pure character based applications can't be run from ssh or cron or anything like that. imagine something like sed or grep refusing to start up because it couldn't open an x11 window -- that's the kind of silliness you get.
trying to do scripted building with xcode is a mess, it practically forces you to use the gui, which makes automation difficult. transporting xcode projects from one machine to another can sometimes be difficult too, because of hidden full paths in the project description files. (microsoft visual studio sometimes has this problem too, but to a lesser extent.)
osx bundles are also another pita. yes they are cute and yes they suck less than the old resource/data fork madness of classic macos. but they're still a pain to juggle. and yes i realize this is nextstep legacy stuff -- but it doesn't make it right:-)
and until very recently osx didnt even have a real working dlopen(). (yes, i know the "true way" is to use the osx APIs, but it makes porting unix applications a real pain. and yes i know third parties wrote a dlopen() emulator for earlier versions of osx, but it wasnt stock at the time).
then there's just plain nuttiness, like the fact apple's pico inexplicably corrupts long lines.
lots of former linux geeks might have decided osx is worth the money, but i doubt many of them were developers.
doesnt this happen a frame late though? you would only get the collision results after the frame has been drawn (or rather, after the stic has drawn the objects).
the other problem would be latency. with physics on the cpu, you have the answer _now_, which you use for rendering or other things. with a PPU you have to send off the query and wait for the result back.
this is the same problem facing doing some effects on modern GPUs. because of the asynchronous nature of rendering, some effects can be hard to render because you need to readback the results in order to render further results. so your cpu algorithm stalls, waiting for the gpu to finish rendering before you can move to the next step.
i dont think bandwidth will be the issue, it will be latency.
you have absolutely no idea what you're talking about.
you can't get a 4x reduction from 1080i without sacrificing something.
i've been encoding video for ~10 years now, i've extensively used all the various codecs. mpeg4 is great for low bitrate PC generated video (which is what it was designed for), but it is not significantly better than mpeg2 to get the miracle compression you attribute to it. mpeg4 scales down very well (eg think streaming video over dialups) but it does not scale up signficantly better than mpeg2.
i know you think your 4x reduced mpeg4 rips look "good" on a pc monitor, but they look horrible blown up on a bigscreen. artifacting all over the place. it's simple physics -- you can't generate detail from missing bits, mpeg4 is not so advanced beyond mpeg2 that it can pull off compression miracles.
mpeg4 in theory can get very high compression rates through object based scene analysis (again, PC generated video), but nobody does this yet. in reality its just another simple DCT motion vector scheme.
don't believe me? try this analysis by an mpeg expert.
I never had a C64, so my experience with teh 1541 is nil. However a bit of googling shows you are correct, the 1541 required regular alignment.
http://en.wikipedia.org/wiki/Commodore_1541
Apparently the 1541 was such a terrible design that it required this, and a whole mini industry of 1541 alignment tools existed at one time.
AFAIK, the 1541 was the only drive that ever required this. The apple II, atari 8-bit and anything else I have ever used never required alignment -- then or since.
that's bizarre. in the years of 8-bit copy parties, never had a problem reading anyone else's disks, nor anyone had problems reading mine. nobody ever aligned their drives.
fiddling with the drive alignment was frowned upon, because there wasn't any standard available for you to align your drive to! there were diagnostic 1050 disks, but they weren't easily available. i don't know of a single person who had one (or needed one, for that matter).
the two "bad experiences" you mention have nothing to do with alignment..
recoding sort of kills the whole point of recording a 1080i HDTV stream in the first place.
on a bigscreen TV, the quality loss is VERY noticeable. which is the whole point behind recording the original full rate HDTV stream.
of course if you don't care about video quality, watching it on some crappy NTSC tv or 21" PC monitor then you probably don't care, so go ahead and recode it into pixelated mushiness, compress the stuffing out of it and shoehorn it into those DVDs.
i never had to align my 5.25" or 3.5" floppy drives. don't know what computers you were using. i used apple II's, atari 8-bit, atari 16-bit, amiga and mac. never had to align anything -- ever.
the maxells, 3ms and fujis were not recent. something like 10-15 years ago.
i remember buying packs of 100 no-name (random colored, no manufacturer label) and they would all work fine notched forever. also buying a 10-pack of "1337" "supar" "extreme quality" vendor-branded maxell/3m/fuji/etc around the same time and they would go bad within a few months of light use.
and we are discussing 3.5" disks.
i still have the old no-name colored notched disks. they still work fine. i ended up throwing most of the maxell/3m/etc in the trash because they all went bad relatively quickly.
i haven't bought any 3.5" in ages, i still use the same notched no-name colored discs from 15-20 years ago.
panasonic sells a DVHS unit which claims to be able to record DVHS to standard SVHS tapes. but what does panasonic know?
and i've got a JVC deck here which records SVHS to standard VHS tapes. indeed it is not quite as good as SVHS but it is visibly much better than standard VHS.
but DVHS is a digital format with error correction and such and DVHS tape spec is so close to standard SVHS that it may not matter all that much. Similar to the fact you can record Digital-8 onto regular Hi-8 tapes.
i've got 20 year old cheap-ass no-name-brand notched discs which still work fine. and "true double sided" from maxell, 3m and fuji which went bad in less than 3 days.
well you could, but 1080i runs almost 4mbyte/sec which means you'd get ~19 minutes recording time on your typical 4.7gb DVD-RW.
do you really want to use 9.4gb dual layer dvd-r for all your recordings? you do know how freaking expensive they are... and there's no 9.4gb rw yet. not to mention that's still only 38 minutes.
Slashdot Mirror
...that the itanium is a wildly successful product, too.
in other news, intel continues to believe the f00f and pentium fdiv bugs were really just user error...
sorry, but that does not lend itself to readable code. if anything your example proves how badly perl suffers from not having a true switch syntax.
also, perl6 will have official switch statements, so apparently they decided that this "doesn't need one" claim was false. only it took them 20 years to come to that conclusion.
but PHP with it's endless heap of little functions that do nearly the same thing
you mean perl isn't littered with the same problem? hah. one of the touted features of perl is that there's always a zillion ways to do the same thing.
the thing i hate the most about perl is the often implicit behavior of perl. explicit programming is almost always clearer. perl freaks would claim this just demonstrates the power of perl, but it sure doesn't lend to its readibility.
the retarded perl syntax for defining functions doesnt help readability either.
and can someone explain how perl stuff like
$|=1;
is in any way clear and intuitive?
that's part of the problem with perl -- the code is often incredibly terse and dense.
:-P
you can do incredibly complex things in a few characters in perl, which can be far more difficult to grok than the same thing described in 20 lines of C code.
it's both a blessing and a curse. a blessing because you can beat out very complex things quickly, and a curse because it is a major pita to maintain.
perl also stubbornly avoids some useful language constructs in the name of "language purity". eg case statements. yes i know about Case.pm, but its not stock perl. and yes i know perl6 will have it. only took them ~20 years to get there
i've been gradually moving towards python and php for scripting. both are far more readable than perl, and just as powerful. yes really, php makes a nice scripting language -- there's far more to it than just spitting out html from apache.
totally classic behaviour you'd expect from an unethical corporation who wants to cover their ass and deflect blame of a major fuckup that's their own fault.
if you ever wondered about the ethical standards of harvard, here's a perfect example. instead of accepting responsibility for their fuckup, they take it out on others, in order to cover up their embarassment.
true. the g4 is a slow processor. it's like the celeron of powerpcs. you want a real powerpc, you need a g5.
...is about par for all otomo productions.
go ahead and flame me now, you akira fanboys. macgruff the crimedog dares you.
mac osx is very pretty, but the development tools are a mess.
:-)
trying to do anything scripted is difficult as apple still doesn't quite comprehend what character based applications are.
eg an application which links vs Carbon needs to have access to the gui even if it never touches it. kiss starting many applications via ssh goodbye. unfortunately apple still hasn't separated out all the purely character based functions from carbonlib. so a lot of pure character based applications can't be run from ssh or cron or anything like that. imagine something like sed or grep refusing to start up because it couldn't open an x11 window -- that's the kind of silliness you get.
trying to do scripted building with xcode is a mess, it practically forces you to use the gui, which makes automation difficult. transporting xcode projects from one machine to another can sometimes be difficult too, because of hidden full paths in the project description files. (microsoft visual studio sometimes has this problem too, but to a lesser extent.)
osx bundles are also another pita. yes they are cute and yes they suck less than the old resource/data fork madness of classic macos. but they're still a pain to juggle. and yes i realize this is nextstep legacy stuff -- but it doesn't make it right
and until very recently osx didnt even have a real working dlopen(). (yes, i know the "true way" is to use the osx APIs, but it makes porting unix applications a real pain. and yes i know third parties wrote a dlopen() emulator for earlier versions of osx, but it wasnt stock at the time).
then there's just plain nuttiness, like the fact apple's pico inexplicably corrupts long lines.
lots of former linux geeks might have decided osx is worth the money, but i doubt many of them were developers.
doesnt this happen a frame late though? you would only get the collision results after the frame has been drawn (or rather, after the stic has drawn the objects).
the other problem would be latency. with physics on the cpu, you have the answer _now_, which you use for rendering or other things. with a PPU you have to send off the query and wait for the result back.
this is the same problem facing doing some effects on modern GPUs. because of the asynchronous nature of rendering, some effects can be hard to render because you need to readback the results in order to render further results. so your cpu algorithm stalls, waiting for the gpu to finish rendering before you can move to the next step.
i dont think bandwidth will be the issue, it will be latency.
...islamic militants are just as frustrated with tech support as the rest of us!
many a time i wanted to throttle the fool on the other end of the phone in bangalore...
sun offers 2) and 3)
n of fice/
http://www.sun.com/service/support/software/ope
you have absolutely no idea what you're talking about.
you can't get a 4x reduction from 1080i without sacrificing something.
i've been encoding video for ~10 years now, i've extensively used all the various codecs. mpeg4 is great for low bitrate PC generated video (which is what it was designed for), but it is not significantly better than mpeg2 to get the miracle compression you attribute to it. mpeg4 scales down very well (eg think streaming video over dialups) but it does not scale up signficantly better than mpeg2.
i know you think your 4x reduced mpeg4 rips look "good" on a pc monitor, but they look horrible blown up on a bigscreen. artifacting all over the place. it's simple physics -- you can't generate detail from missing bits, mpeg4 is not so advanced beyond mpeg2 that it can pull off compression miracles.
mpeg4 in theory can get very high compression rates through object based scene analysis (again, PC generated video), but nobody does this yet. in reality its just another simple DCT motion vector scheme.
don't believe me? try this analysis by an mpeg expert.
I never had a C64, so my experience with teh 1541 is nil. However a bit of googling shows you are correct, the 1541 required regular alignment.
http://en.wikipedia.org/wiki/Commodore_1541
Apparently the 1541 was such a terrible design that it required this, and a whole mini industry of 1541 alignment tools existed at one time.
AFAIK, the 1541 was the only drive that ever required this. The apple II, atari 8-bit and anything else I have ever used never required alignment -- then or since.
is that $25/$50 for rewritable media or write-once?
is rewritable blu-ray media even available yet?
that's bizarre. in the years of 8-bit copy parties, never had a problem reading anyone else's disks, nor anyone had problems reading mine. nobody ever aligned their drives.
fiddling with the drive alignment was frowned upon, because there wasn't any standard available for you to align your drive to! there were diagnostic 1050 disks, but they weren't easily available. i don't know of a single person who had one (or needed one, for that matter).
the two "bad experiences" you mention have nothing to do with alignment..
want to place a bet? I bet EU parliament passes it despite any opposition, no matter what.
recoding sort of kills the whole point of recording a 1080i HDTV stream in the first place.
on a bigscreen TV, the quality loss is VERY noticeable. which is the whole point behind recording the original full rate HDTV stream.
of course if you don't care about video quality, watching it on some crappy NTSC tv or 21" PC monitor then you probably don't care, so go ahead and recode it into pixelated mushiness, compress the stuffing out of it and shoehorn it into those DVDs.
i never had to align my 5.25" or 3.5" floppy drives. don't know what computers you were using. i used apple II's, atari 8-bit, atari 16-bit, amiga and mac. never had to align anything -- ever.
head cleaning was another story.
the maxells, 3ms and fujis were not recent. something like 10-15 years ago.
i remember buying packs of 100 no-name (random colored, no manufacturer label) and they would all work fine notched forever. also buying a 10-pack of "1337" "supar" "extreme quality" vendor-branded maxell/3m/fuji/etc around the same time and they would go bad within a few months of light use.
and we are discussing 3.5" disks.
i still have the old no-name colored notched disks. they still work fine. i ended up throwing most of the maxell/3m/etc in the trash because they all went bad relatively quickly.
i haven't bought any 3.5" in ages, i still use the same notched no-name colored discs from 15-20 years ago.
thats nice, now show me where you can buy one, today.
i can show you were to buy dvhs, today. to record that hdtv program being aired next week.
and er, how much do your blue-laser drives and media cost?
panasonic sells a DVHS unit which claims to be able to record DVHS to standard SVHS tapes. but what does panasonic know?
and i've got a JVC deck here which records SVHS to standard VHS tapes. indeed it is not quite as good as SVHS but it is visibly much better than standard VHS.
but DVHS is a digital format with error correction and such and DVHS tape spec is so close to standard SVHS that it may not matter all that much. Similar to the fact you can record Digital-8 onto regular Hi-8 tapes.
notching them doesnt make them die any faster.
i've got 20 year old cheap-ass no-name-brand notched discs which still work fine. and "true double sided" from maxell, 3m and fuji which went bad in less than 3 days.
because you can't record HDTV to dvd+/-RW.
well you could, but 1080i runs almost 4mbyte/sec which means you'd get ~19 minutes recording time on your typical 4.7gb DVD-RW.
do you really want to use 9.4gb dual layer dvd-r for all your recordings? you do know how freaking expensive they are... and there's no 9.4gb rw yet. not to mention that's still only 38 minutes.