Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 1
Yes, serializing and caching to filesystem are easy (you can even use PHP serialization format with Ruby, although the built in Marshal does just as well), but it's still not as fast as simply keeping an object alive across requests, especially if they grow quite large. It's similar to the reason you don't want to recompile a script each request; loading a serialized cache involves IO, parsing and (simple) interpretation too.
Actually, turok-mmcache provides a way to do this using shared memory; it just says "$value", so presumably that means it'll work with arbitary PHP values.
We use Apache 2, btw; mod_fastcgi is stable there, and I believe thread-safe, so you can use a threaded Apache with forked PHP daemons safely. Even if not, it's nice to have the better designed Apache 2 without worries about mod_php's stability on it:)
Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 1
"'Ruby gets this in a more generalized form as part of object persistance in a daemonised interpreter.'
Ick. I much prefer that php handle these things for me transparently."
I prefer the more general alternative; it's one of my desired features for PHP; even just with a (get/set)_persistant_variable() function or so (maybe this is doable with a newer SHM module?)
Basically, with PHP you do:
$db = mysql_pconnect();// the only persistant object $app = new SomeWebApplication($db); $app->processRequest( );
But with Ruby you can do:
# naturally persistant across requests db = DBI.connect() app = SomeWebApplication.new(db) FCGI.each_cgi do |cgi|
app.process_request(cgi) end
The second one's faster, and means you can make SomeWebApplication.new fairly expensive; loading caches, compiling templates, executing longish db queries and such. mod_ruby I believe has similar features, only you need to check for the existance of the object, and make it global; that's similar to mod_perl behavior iirc and should be doable in PHP.
It's all a matter of taste; how worried you are about performance/flexibility, and how much control you have over your servers I guess.
"Don't know, I have never felt the need to use fastcgi with php."
It's worth trying; it means if PHP crashes it doesn't take out your httpd (potential for a nice error page even if you blow up the FastCGI daemon), it makes your httpd processes smaller (our PHP's are hitting 80MB each atm), and it lets you have fewer PHP processes reflecting that most servers tend to split workload between dynamic and static. It also reduces dependence on the httpd; very fast servers like thttpd and friends become useful with PHP because it's all nonblocking socket IO.
PHP has lots of neat features to make sure your code can't escape it's hierarchy, you can also selectively not allow certain functions to run.
Ruby has a generalized $SAFE level, with increments from 0 to 4; similar to FreeBSD's securelevel sysctl. With FastCGI you can have daemons running as other users ala suexec. These two should cover a lot of needs security wise; both developers and admins.
Yes; in this case it's support which is more of an issue; FLAC works in WinAmp, Foobar, WMP, xmms, command line on most systems, and several hardware players; ALAC just in iTunes and the iPod. If Apple had gone for FLAC, maybe they'd support their DRMable M4P-contained FLAC *and* normal FLAC, but alas.
I wonder if ALAC's lower performance points to them choosing to develop their own format because of limitations in the iPod; that sounds a little less nasty than them just doing so because they want absolute control, but still, a spec would be nice.
Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 1
There's at least one free book you can read online which covers most of the standard library, and a few other more general ones. Extensions tend to be at least sufficiently documented, especially if you use rdoc or can read comments from source. Aside from the less centralized documentation, I'd put it about on par with PHP's.
Lack of database pooling? I've seen such things written in about 20 lines of Ruby, and the language makes it extremely easy to integrate it into existing software without breaking anything. It is bit of an odd criticism from a PHP user.. maybe you're thinking in terms of Ruby lacking an equivilent of mysql_pconnect? Ruby gets this in a more generalized form as part of object persistance in a daemonised interpreter.
mod_ruby is at least as integrated with Apache as PHP, if not more so. Maybe too much; that's why I prefer to use FastCGI, since it's API gives me a simple to develop webserver neutral Ruby daemon in which I can keep objects cached in memory and thread and fork to my heart's content. FastCGI's great with PHP too; you can even put the FastCGI'd PHP's in a FreeBSD jail, or on to another machine entirely. Did I mention PHP's FastCGI support seems buggier than Ruby's?:/
As to Unicode.. I'm English -- I don't bother learning other languages, why should I want to display them*?;)
The community isn't that small; it is however, quite active and full of experienced users. Quality over quantity.
He meant "cue", unless he was planning on putting himself and pro-RTG anti-solar zealots in a line. Actully he seems to want to hit them with a cue, which seems like a fine idea to me;)
What I will say is that just having solar panals and batteries on a couple of Mars rovers doesn't mean it's doing anything to advance the technology, beyond perhaps being one more order for the parts. Said parts are probably largely the same as if you'd ordered them for your solar powered house.
RTG's and related research are worthwhile too; being able to convert heat to useful energy is a technology which could be just as useful as solar power; we are sitting on top of a huge nuclear reactor after all. Maybe one day we'll construct batteries based on similar technology (mmm, RTG powered laptop), or power cities from radiothermal generators using the mantle as it's heat source (something already done, but maybe we can scale it up).
Still, it's not as if we're likely to be able to run a rover for more than a fraction's of the life of an RTG (unless you make a *really* small one I guess); one argument for solar panels would be that even with perfect power a rover is likely to get stuck somewhere or be damaged by dust within (say) 6 months; a power source which is likely to last about that long makes more sense than a more expensive ickle RTG. that may well outweigh the panels and be useless over a lot of it's lifetime.
RTG's get a lot of use in other probes anyway; it's not as if we haven't "risked" blowing them up plenty of times. I think provided they're still used in places they obviously make sense (orbital probes which are likely to last decades), we can forgive NASA for choosing panels on something which isn't likely to take advantage of an RTG's primary feature (long life).
Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 1
I'm not trying to change anyone's mind; just chipping in with my opinion as a developer who's used PHP quite a lot. I think you'll find a fair few people agree with my assessment too; probably not the majority, but since when has the majority known anything?
I was going to write a detailed reply, but I doubt many people would appreciate it; once being a very enthusiastic PHP user means I can appreciate your position. I just feel I've outgrown the language; the documentation gets less useful over time (unless you're very forgetful, or don't use the language much I guess), the language design feels ever more contraining and silly, and the community ever more aligned to either n00bs or people trying to turn the language into Java Lite.
Ruby fits my mindset better, just like FreeBSD, Opera, vim, irssi and tcsh do. PHP, Linux, iBrowse, pico, AmIRC, and zsh used to, but people change. Maybe I'll love PHP again in a year or two when PHP5's a little more pervasive... either way, embrace diversity!:)
Right, but that's called the Pentium-M, not Centrino; unless you've seen the name used officially outside complete laptops with integrated WiFi..:)
Looking at Intel's Centrino page seems to confirm this; it's a "range of technologies", including Intel's wireless networking hardware, motherboard chipset and the Pentium-M. Hence it's not a processor family, it's a mobile technology family, which includes a processor family name most people will at least partly recognise.
it seems that consumers are only able to keep track of one or two processor family names per manufacturer.
I suspect most consumers really don't have a clue about processor names, and will just go for whatever a salesperson points in their direction. Any ideas as to performance probably comes more from noticing the general naffness of a name than any actual understanding. Really, which would you rather have in the absence of any other knowledge, an Athlon or a Sempron? That, of course, is precisely why low end processors get names like this:)
BTW, I'm under the impression Centrino is just a name for a mobile Celeron and on-board Intel WiFi NIC -- not quite a "processor family name".
Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 0
PHP's not OO any more so than Perl is; it has OO features, but they're rarely used, even inside the standard library. That OO is only just becoming a feaure you can use a lot of without the language creaking under all those =&'s kinda demonstrates this - OO is a PHP addon, and for the most part feels like it. Exceptions are not yet in the PHP everyone actually uses yet, either; it's hardly the right tool if you have to use prerelease software to make it work.
The large library you mention is pretty poor, to be honest; the standard range of extensions don't really follow much in the way of guidelines, so you end up with a complete mess of functions (all polluting the global namespace; something PHP's only just discovering is a Bad Thing) following different conventions for names and arguments and return values. And all expected to be embedded directly in the executable; something which is fairly reasonable in a webserver environment, but just bloats everything else.
Third party PHP libraries tend to be of fairly poor quality, because the community just doesn't tend towards things like clear design and unit testing (probably a factor of it being a lot of people's first programming language). There may be a lot of code for it out there, but most of it isn't of very high quality.
The community isn't much of an attraction either; all the major languages have communities, what makes PHP's any better? That it's seemingly filled by said my-first-language peeps doesn't seem to help from my point of view (this is where speghettified monstrosities like phpNuke come from, and how they become popular).
I once loved PHP; now I merely like it.
Re:Running This
on
OpenGL in PHP
·
· Score: 2, Interesting
Some would say that any use is inappropriate for PHP. Not me, but it's certainly one of the less interesting open source languages about.
For instance, Ruby's web application support has been rapidly gaining ground for quite a while now; fancy state-keeping systems last seen on LISP; a powerful server framework now integrated with the standard library; an innovative object-relational mapping library which makes interfacing with SQL databases childsplay; an interesting new web application framework which is causing quite a stir; an amazingly easy to set up Wiki server; a nifty template library gaining fancy bytecode based acceleration and native-C compilation. Every one of these projects alone is probably more interesting to the average developer than yet-another-OpenGL-module for an interpreted language... isn't it?
Maybe this is why this is News for Nerds, not News for Geeks;)
Um, that's precisely what I said: "The problem is, the difficulty isn't reset to the NORMAL specified in the.ini, but apparantly to some default setting specified in the game executable."
That's two replies which appear to have missed this; tsk!
I noticed early on that the difficulty settings specified in DEFAULTS.INI can be changed to make each difficulty level easier or harder (yeah, I'm nosy and like looking for things to tweak in games); that would be a useful intermediate "fix" to this issue, since you could specify NORMAL difficulty to be the same as EXPERT. The problem is, the difficulty isn't reset to the NORMAL specified in the.ini, but apparantly to some default setting specified in the game executable.
I spotted this a few hours after installing the game; wtf are they hiring to do their testing!?
A 1MB audio file that's 1 minute long is 140kbps, whether it's VBR, ABR or CBR -- all they change are the bitrate distribution. VBR would be damn cool if it could make a file higher bitrate without increasing it's size:o
Testing, yes; you're right of course (although they're typically a little more involved than that -- just because it works on 10, 100 or 1000 WAV's doesn't mean it'll work on the 1001th), but test suites are just another part of software; they tend to mature over time. Like all file formats you're going to dedicate GB's of data to, the more mature option is typically the best for just this reason:)
AAC is indeed one of the audio standards which appear in the MP4 container format; MP4 can contain just about anything, including MP3, AAV, and any other format you care to put into it -- it's rather like AVI or OGG in this regard. MP4's lossless format is known as ALS; it's as yet unfinished, however. Being based on LPAC, it should perform pretty well; FLAC's lossless codec comparison page however shows LPAC performing significantly better than ALAC. Without source and specifications, though, all of this is just speculation -- maybe they just did a really bad job of implimenting it;)
How do you get a higher average bitrate into a file with the same size and playtime? It's probably also worth mentioning that MusePack's not really aimed at fixed bitrate encoding; it's designed to remain "transparent" at whatever bitrate's required. I've seen it go from 90kbps all the way past 400 depending on the track. Any test forcing it into 128kbps is going to be pessimising it, yet it still performs excellently.
How much testing do you think it needs?
FLAC's source includes a full range of tests which exercise it sufficiently to pretty much prove that it's encoding and decoding correctly -- testing is important with any software, especially any which makes guarantees like a lossless compression format. I wonder if Apple have a similar range of tests, and if they're as mature as FLAC's.
As for "sub-par", I mean of course in terms of how well it compresses compared with how much CPU and memory it consumes -- ALAC appears to consistantly produce files with higher bitrates than even FLAC, which isn't known for it's great compression ratios. It's certainly not terrible, but why on earth didn't Apple just use FLAC instead of making their own inferior codec? It's not as if they couldn't have taken the code and integrated it into an AAC wrapper -- it just strikes me as another symptom of Apple's not-invented-here problem.
I'm not aware of any details as to what ALAC actually is; whether it's based on ALE (it's performance doesn't seem to suggest so), a hacked up MP4 or what, but things tend to point to it being an entirely in-house effort. Lacking any specification, I won't be holding my breath for support anywhere outside iTunes:/
As far as I'm aware, iTunes is a fairly primitive burst ripper, and lacks things like reader and writer offset correction. EAC's Secure mode remains the most trustworthy ripping method, and it's easy enough to set up to automatically fetch data from FreeDB etc. It can also rip to arbitary formats, including command line encoders, so lossless wise you're not limited to the largely untested, unsupported and sub-par Apple Lossless (which I've already heard truncates samples in some circumstances) or WAV.
In terms of high quality, sure, AAC's not bad, but MusePack still consistantly beats it in listening tests, is faster to encode, and is fully open source. It's a true VBR codec too, and quite happy to scale up to half a Mbit when the music demands it; last I heard AAC was still limited to ABR.
As far as comparing the iPod to a 20 quid player, that was purely from a format support standpoint; I'm well aware that the iPod is likely to include higher quality components which will likely impact sound quality. It's just not much use if it doesn't actually play most of my music in the first place:)
Plus, I find iTunes' UI absolutely disgusting. My preffered player isn't exactly a looker, but at least that's just because it has conservative defaults, not because it's using some weird and extremely slow GUI library with next to zero configurability. Foobar more than beats iTunes in features; and it even has an iPod plugin;)
"Seriously, who cares about Vorbis outside the faction of *nix users with +1 Amulets of OSS Awe?"
Users with an interest in having their music ripped in a high quality format. Vorbis and MusePack are a common choice among even fairly tame audiophiles, as is FLAC and a few other lossless formats (which are great for totally sidestepping "what codec should I use and what settings are best" arguments). Although these people are in the minority, they're an important minority, because who do you think people are going to ask when they're trying to choose a portable player?
Besides, as far as I'm concerned a portable digital audio player should play back as many digital formats as possible; I don't want to worry about what format my music is in, I just want to dump it on my player and have it play. An iPod is *barely* a step up from a 20UKP flash based MP3-only player in this regard, with me not having any AAC's or WMA's.
A friend of mine with a lot of experience with x86 assm claims the architecture already supports non-executable memory areas anyway. I wonder if he can find a reference.. maybe it's just not fine-grained enough (i.e. per-page) to be useful?
My Cherry keyboard has a stiffer caps lock key than other keys, so it's harder to hit without being quite deliberate. The right hand side of it's also sloped so it's harder to hit it when missing 'A'. To be honest, while the sloping bit is cool, making it stiffer just means it's even more useless than usual; I don't want a key that's *that* hard to hit:/
LWindows is harder to hit by mistake, too; if you're going to spack in that direction aiming for Ctrl, you're more likely to hit the "KeyMan" key, which just acts as a metakey for the squillions of extra buttons.
And yes, that crazy '@' can be mapped back to RWindows.
FreeBSD and a few other OS's support filesystem checkpoints, which effectively let you keep multiple versions of a filesystem on the same disk. They're actually used for background fsck in fBSD (create snapshot => fsck snapshot, leaving the rest of the filesystem live), but could also be used for keeping filesystem checkpoints about in the event of screwups like this.
With WinXP SP2, it also seems you can use WebDAV shares like normal fileshares -- an interesting project would be interfacing this to SubVersion to provide a fully versioning filesystem:o
Quite a few given the low quality of a telesync. They're still cam jobs and very hit and miss even within their low quality range. The only way to see a decent version of most films remains the cinema during the time you'd concider a telesync.
We're not talking screeners here; a screener uses a prerelease DVD or so as a source, and are a *completely* different ballgame.
Also note that *minimum* FPS is the important measure -- that'll be when there's a lot of action and detail, where you *need* the FPS to see what's happening.
No good getting 90FPS average when you drop to 15FPS the minute you walk into a detailed area with a lot of models -- that is the real benefit of 200FPS+.
I feel a proper telesync (which uses additional hardware to keep the camera in sync with the projector and provide reasonable sound) is like a free <64kbps MP3 of a song; it's typically good enough to tell if it's worth paying for a proper version.
As far as I'm concerned pirates in this case are providing a useful service to the market by giving potential punters more information before they decide whether to shell out to see a movie or not; Hollywood's problem is for the most part that answer is "not"; that's the only reason such piracy could be losing them money, and frankly if that's the case I think they deserve to.
Are canon using CCD's now? they were using another type of capture sensor and I thought they went towards the better brands of CCDs for the rebel.
They went for a CMOS for the Rebel; something more often seen in ultra-cheap webcams and such. They're cheap to make, but even a good CMOS has significantly poorer sensitivity than a good CCD; hence you tend to get more noise.
Comparing shots from the Nikon D70 (which uses a CCD) to the Digital Rebel, I must say that while the large size and decent quality of the CMOS on the Rebel keeps noise acceptable, the Nikon does a better job of it. I think DCResource has quite a few comparisons in this regard.
The tiny CCD's on these cameras make me somewhat nervous; at 8MP I've seen a *lot* of very noisy/grainy shots from them, which as far as I'm concerned defeats the object of the higher resolution. Really, for a compact 4MP seems to be far more sensible -- it's high enough to be usable for printing, but not so high that noise starts ruining shots. I'd buy a Minolta A series in an instant if they did a less noisy 4MP version:/
Slashdot Mirror
Yes, serializing and caching to filesystem are easy (you can even use PHP serialization format with Ruby, although the built in Marshal does just as well), but it's still not as fast as simply keeping an object alive across requests, especially if they grow quite large. It's similar to the reason you don't want to recompile a script each request; loading a serialized cache involves IO, parsing and (simple) interpretation too.
:)
Actually, turok-mmcache provides a way to do this using shared memory; it just says "$value", so presumably that means it'll work with arbitary PHP values.
We use Apache 2, btw; mod_fastcgi is stable there, and I believe thread-safe, so you can use a threaded Apache with forked PHP daemons safely. Even if not, it's nice to have the better designed Apache 2 without worries about mod_php's stability on it
I prefer the more general alternative; it's one of my desired features for PHP; even just with a (get/set)_persistant_variable() function or so (maybe this is doable with a newer SHM module?)
Basically, with PHP you do:But with Ruby you can do:The second one's faster, and means you can make SomeWebApplication.new fairly expensive; loading caches, compiling templates, executing longish db queries and such. mod_ruby I believe has similar features, only you need to check for the existance of the object, and make it global; that's similar to mod_perl behavior iirc and should be doable in PHP.
It's all a matter of taste; how worried you are about performance/flexibility, and how much control you have over your servers I guess.
It's worth trying; it means if PHP crashes it doesn't take out your httpd (potential for a nice error page even if you blow up the FastCGI daemon), it makes your httpd processes smaller (our PHP's are hitting 80MB each atm), and it lets you have fewer PHP processes reflecting that most servers tend to split workload between dynamic and static. It also reduces dependence on the httpd; very fast servers like thttpd and friends become useful with PHP because it's all nonblocking socket IO.
Ruby has a generalized $SAFE level, with increments from 0 to 4; similar to FreeBSD's securelevel sysctl. With FastCGI you can have daemons running as other users ala suexec. These two should cover a lot of needs security wise; both developers and admins.
Yes; in this case it's support which is more of an issue; FLAC works in WinAmp, Foobar, WMP, xmms, command line on most systems, and several hardware players; ALAC just in iTunes and the iPod. If Apple had gone for FLAC, maybe they'd support their DRMable M4P-contained FLAC *and* normal FLAC, but alas.
I wonder if ALAC's lower performance points to them choosing to develop their own format because of limitations in the iPod; that sounds a little less nasty than them just doing so because they want absolute control, but still, a spec would be nice.
There's at least one free book you can read online which covers most of the standard library, and a few other more general ones. Extensions tend to be at least sufficiently documented, especially if you use rdoc or can read comments from source. Aside from the less centralized documentation, I'd put it about on par with PHP's.
:/
;)
Lack of database pooling? I've seen such things written in about 20 lines of Ruby, and the language makes it extremely easy to integrate it into existing software without breaking anything. It is bit of an odd criticism from a PHP user.. maybe you're thinking in terms of Ruby lacking an equivilent of mysql_pconnect? Ruby gets this in a more generalized form as part of object persistance in a daemonised interpreter.
mod_ruby is at least as integrated with Apache as PHP, if not more so. Maybe too much; that's why I prefer to use FastCGI, since it's API gives me a simple to develop webserver neutral Ruby daemon in which I can keep objects cached in memory and thread and fork to my heart's content. FastCGI's great with PHP too; you can even put the FastCGI'd PHP's in a FreeBSD jail, or on to another machine entirely. Did I mention PHP's FastCGI support seems buggier than Ruby's?
As to Unicode.. I'm English -- I don't bother learning other languages, why should I want to display them*?
The community isn't that small; it is however, quite active and full of experienced users. Quality over quantity.
He meant "cue", unless he was planning on putting himself and pro-RTG anti-solar zealots in a line. Actully he seems to want to hit them with a cue, which seems like a fine idea to me ;)
What I will say is that just having solar panals and batteries on a couple of Mars rovers doesn't mean it's doing anything to advance the technology, beyond perhaps being one more order for the parts. Said parts are probably largely the same as if you'd ordered them for your solar powered house.
RTG's and related research are worthwhile too; being able to convert heat to useful energy is a technology which could be just as useful as solar power; we are sitting on top of a huge nuclear reactor after all. Maybe one day we'll construct batteries based on similar technology (mmm, RTG powered laptop), or power cities from radiothermal generators using the mantle as it's heat source (something already done, but maybe we can scale it up).
Still, it's not as if we're likely to be able to run a rover for more than a fraction's of the life of an RTG (unless you make a *really* small one I guess); one argument for solar panels would be that even with perfect power a rover is likely to get stuck somewhere or be damaged by dust within (say) 6 months; a power source which is likely to last about that long makes more sense than a more expensive ickle RTG. that may well outweigh the panels and be useless over a lot of it's lifetime.
RTG's get a lot of use in other probes anyway; it's not as if we haven't "risked" blowing them up plenty of times. I think provided they're still used in places they obviously make sense (orbital probes which are likely to last decades), we can forgive NASA for choosing panels on something which isn't likely to take advantage of an RTG's primary feature (long life).
I'm not trying to change anyone's mind; just chipping in with my opinion as a developer who's used PHP quite a lot. I think you'll find a fair few people agree with my assessment too; probably not the majority, but since when has the majority known anything?
:)
I was going to write a detailed reply, but I doubt many people would appreciate it; once being a very enthusiastic PHP user means I can appreciate your position. I just feel I've outgrown the language; the documentation gets less useful over time (unless you're very forgetful, or don't use the language much I guess), the language design feels ever more contraining and silly, and the community ever more aligned to either n00bs or people trying to turn the language into Java Lite.
Ruby fits my mindset better, just like FreeBSD, Opera, vim, irssi and tcsh do. PHP, Linux, iBrowse, pico, AmIRC, and zsh used to, but people change. Maybe I'll love PHP again in a year or two when PHP5's a little more pervasive... either way, embrace diversity!
Right, but that's called the Pentium-M, not Centrino; unless you've seen the name used officially outside complete laptops with integrated WiFi.. :)
:)
Looking at Intel's Centrino page seems to confirm this; it's a "range of technologies", including Intel's wireless networking hardware, motherboard chipset and the Pentium-M. Hence it's not a processor family, it's a mobile technology family, which includes a processor family name most people will at least partly recognise.
But anyway, </pedantic>
I suspect most consumers really don't have a clue about processor names, and will just go for whatever a salesperson points in their direction. Any ideas as to performance probably comes more from noticing the general naffness of a name than any actual understanding. Really, which would you rather have in the absence of any other knowledge, an Athlon or a Sempron? That, of course, is precisely why low end processors get names like this
BTW, I'm under the impression Centrino is just a name for a mobile Celeron and on-board Intel WiFi NIC -- not quite a "processor family name".
PHP's not OO any more so than Perl is; it has OO features, but they're rarely used, even inside the standard library. That OO is only just becoming a feaure you can use a lot of without the language creaking under all those =&'s kinda demonstrates this - OO is a PHP addon, and for the most part feels like it. Exceptions are not yet in the PHP everyone actually uses yet, either; it's hardly the right tool if you have to use prerelease software to make it work.
The large library you mention is pretty poor, to be honest; the standard range of extensions don't really follow much in the way of guidelines, so you end up with a complete mess of functions (all polluting the global namespace; something PHP's only just discovering is a Bad Thing) following different conventions for names and arguments and return values. And all expected to be embedded directly in the executable; something which is fairly reasonable in a webserver environment, but just bloats everything else.
Third party PHP libraries tend to be of fairly poor quality, because the community just doesn't tend towards things like clear design and unit testing (probably a factor of it being a lot of people's first programming language). There may be a lot of code for it out there, but most of it isn't of very high quality.
The community isn't much of an attraction either; all the major languages have communities, what makes PHP's any better? That it's seemingly filled by said my-first-language peeps doesn't seem to help from my point of view (this is where speghettified monstrosities like phpNuke come from, and how they become popular).
I once loved PHP; now I merely like it.
Some would say that any use is inappropriate for PHP. Not me, but it's certainly one of the less interesting open source languages about.
;)
For instance, Ruby's web application support has been rapidly gaining ground for quite a while now; fancy state-keeping systems last seen on LISP; a powerful server framework now integrated with the standard library; an innovative object-relational mapping library which makes interfacing with SQL databases childsplay; an interesting new web application framework which is causing quite a stir; an amazingly easy to set up Wiki server; a nifty template library gaining fancy bytecode based acceleration and native-C compilation. Every one of these projects alone is probably more interesting to the average developer than yet-another-OpenGL-module for an interpreted language... isn't it?
Maybe this is why this is News for Nerds, not News for Geeks
Um, that's precisely what I said: "The problem is, the difficulty isn't reset to the NORMAL specified in the .ini, but apparantly to some default setting specified in the game executable."
That's two replies which appear to have missed this; tsk!
I noticed early on that the difficulty settings specified in DEFAULTS.INI can be changed to make each difficulty level easier or harder (yeah, I'm nosy and like looking for things to tweak in games); that would be a useful intermediate "fix" to this issue, since you could specify NORMAL difficulty to be the same as EXPERT. The problem is, the difficulty isn't reset to the NORMAL specified in the .ini, but apparantly to some default setting specified in the game executable.
I spotted this a few hours after installing the game; wtf are they hiring to do their testing!?
A 1MB audio file that's 1 minute long is 140kbps, whether it's VBR, ABR or CBR -- all they change are the bitrate distribution. VBR would be damn cool if it could make a file higher bitrate without increasing it's size :o
:)
;)
Testing, yes; you're right of course (although they're typically a little more involved than that -- just because it works on 10, 100 or 1000 WAV's doesn't mean it'll work on the 1001th), but test suites are just another part of software; they tend to mature over time. Like all file formats you're going to dedicate GB's of data to, the more mature option is typically the best for just this reason
AAC is indeed one of the audio standards which appear in the MP4 container format; MP4 can contain just about anything, including MP3, AAV, and any other format you care to put into it -- it's rather like AVI or OGG in this regard. MP4's lossless format is known as ALS; it's as yet unfinished, however. Being based on LPAC, it should perform pretty well; FLAC's lossless codec comparison page however shows LPAC performing significantly better than ALAC. Without source and specifications, though, all of this is just speculation -- maybe they just did a really bad job of implimenting it
FLAC's source includes a full range of tests which exercise it sufficiently to pretty much prove that it's encoding and decoding correctly -- testing is important with any software, especially any which makes guarantees like a lossless compression format. I wonder if Apple have a similar range of tests, and if they're as mature as FLAC's.
As for "sub-par", I mean of course in terms of how well it compresses compared with how much CPU and memory it consumes -- ALAC appears to consistantly produce files with higher bitrates than even FLAC, which isn't known for it's great compression ratios. It's certainly not terrible, but why on earth didn't Apple just use FLAC instead of making their own inferior codec? It's not as if they couldn't have taken the code and integrated it into an AAC wrapper -- it just strikes me as another symptom of Apple's not-invented-here problem.
I'm not aware of any details as to what ALAC actually is; whether it's based on ALE (it's performance doesn't seem to suggest so), a hacked up MP4 or what, but things tend to point to it being an entirely in-house effort. Lacking any specification, I won't be holding my breath for support anywhere outside iTunes
As far as I'm aware, iTunes is a fairly primitive burst ripper, and lacks things like reader and writer offset correction. EAC's Secure mode remains the most trustworthy ripping method, and it's easy enough to set up to automatically fetch data from FreeDB etc. It can also rip to arbitary formats, including command line encoders, so lossless wise you're not limited to the largely untested, unsupported and sub-par Apple Lossless (which I've already heard truncates samples in some circumstances) or WAV.
:)
;)
In terms of high quality, sure, AAC's not bad, but MusePack still consistantly beats it in listening tests, is faster to encode, and is fully open source. It's a true VBR codec too, and quite happy to scale up to half a Mbit when the music demands it; last I heard AAC was still limited to ABR.
As far as comparing the iPod to a 20 quid player, that was purely from a format support standpoint; I'm well aware that the iPod is likely to include higher quality components which will likely impact sound quality. It's just not much use if it doesn't actually play most of my music in the first place
Plus, I find iTunes' UI absolutely disgusting. My preffered player isn't exactly a looker, but at least that's just because it has conservative defaults, not because it's using some weird and extremely slow GUI library with next to zero configurability. Foobar more than beats iTunes in features; and it even has an iPod plugin
Users with an interest in having their music ripped in a high quality format. Vorbis and MusePack are a common choice among even fairly tame audiophiles, as is FLAC and a few other lossless formats (which are great for totally sidestepping "what codec should I use and what settings are best" arguments). Although these people are in the minority, they're an important minority, because who do you think people are going to ask when they're trying to choose a portable player?
Besides, as far as I'm concerned a portable digital audio player should play back as many digital formats as possible; I don't want to worry about what format my music is in, I just want to dump it on my player and have it play. An iPod is *barely* a step up from a 20UKP flash based MP3-only player in this regard, with me not having any AAC's or WMA's.
Never mind ;)
A friend of mine with a lot of experience with x86 assm claims the architecture already supports non-executable memory areas anyway. I wonder if he can find a reference.. maybe it's just not fine-grained enough (i.e. per-page) to be useful?
My Cherry keyboard has a stiffer caps lock key than other keys, so it's harder to hit without being quite deliberate. The right hand side of it's also sloped so it's harder to hit it when missing 'A'. To be honest, while the sloping bit is cool, making it stiffer just means it's even more useless than usual; I don't want a key that's *that* hard to hit :/
LWindows is harder to hit by mistake, too; if you're going to spack in that direction aiming for Ctrl, you're more likely to hit the "KeyMan" key, which just acts as a metakey for the squillions of extra buttons.
And yes, that crazy '@' can be mapped back to RWindows.
FreeBSD and a few other OS's support filesystem checkpoints, which effectively let you keep multiple versions of a filesystem on the same disk. They're actually used for background fsck in fBSD (create snapshot => fsck snapshot, leaving the rest of the filesystem live), but could also be used for keeping filesystem checkpoints about in the event of screwups like this.
:o
With WinXP SP2, it also seems you can use WebDAV shares like normal fileshares -- an interesting project would be interfacing this to SubVersion to provide a fully versioning filesystem
Quite a few given the low quality of a telesync. They're still cam jobs and very hit and miss even within their low quality range. The only way to see a decent version of most films remains the cinema during the time you'd concider a telesync.
We're not talking screeners here; a screener uses a prerelease DVD or so as a source, and are a *completely* different ballgame.
Also note that *minimum* FPS is the important measure -- that'll be when there's a lot of action and detail, where you *need* the FPS to see what's happening.
No good getting 90FPS average when you drop to 15FPS the minute you walk into a detailed area with a lot of models -- that is the real benefit of 200FPS+.
I feel a proper telesync (which uses additional hardware to keep the camera in sync with the projector and provide reasonable sound) is like a free <64kbps MP3 of a song; it's typically good enough to tell if it's worth paying for a proper version.
As far as I'm concerned pirates in this case are providing a useful service to the market by giving potential punters more information before they decide whether to shell out to see a movie or not; Hollywood's problem is for the most part that answer is "not"; that's the only reason such piracy could be losing them money, and frankly if that's the case I think they deserve to.
They went for a CMOS for the Rebel; something more often seen in ultra-cheap webcams and such. They're cheap to make, but even a good CMOS has significantly poorer sensitivity than a good CCD; hence you tend to get more noise.
Comparing shots from the Nikon D70 (which uses a CCD) to the Digital Rebel, I must say that while the large size and decent quality of the CMOS on the Rebel keeps noise acceptable, the Nikon does a better job of it. I think DCResource has quite a few comparisons in this regard.
The tiny CCD's on these cameras make me somewhat nervous; at 8MP I've seen a *lot* of very noisy/grainy shots from them, which as far as I'm concerned defeats the object of the higher resolution. Really, for a compact 4MP seems to be far more sensible -- it's high enough to be usable for printing, but not so high that noise starts ruining shots. I'd buy a Minolta A series in an instant if they did a less noisy 4MP version :/