opensuse 10.3... *boo-hoo* i don't wanna switch.

podcast update personal note: my podcast is still waiting on on opensuse 10.3 audacity's build to work correctly, if it doesn't after a factory update i'll have to prolly either compile audacity from source and if that doesn't do it i'll be forced to switch distros. which i may need to do anyways. opensuse 10.3's not going to include x.org 7.3, despite it being released on august 29th. and i'm using an intel graphics chipset and because of the issue 915resolution resolves i have nurmerous random issues(which i'll save everyone from my graphic woe details. except to say i love xgl which won't work with 915resolution's patch/hack in place. than i need my virtual consoles[Shift+Ctrl+F1-6] without my laptop crashing. i know i'm picky; but i'm switching to x.org 7.3 asap and i have to have a workable audacity. yeah i'm dedicated to flipping some people on their heads, *wink*. of course i'm hoping that opensuse's build service or factory will have x.org 7.3 as soon as possible. and than i'll try compiling x.org 7.3 *shivers*, if i abs have to. i'd hate to be need to switch distro. mostly because i love most of opensuse's community. their online &mailing list communities. if you're someone who likes to talk and not just approach dev. from a military style than *avoid opensuse irc chat rooms like the plague!* it may not be that they're anti-social there, but at least several active people have like literally no social skills. hackers with no social skills just creep me out &they're not even worth my time or energy. anyways here's to hoping. no matter what i'll find someway to get audacity running tomorrow; even if i *boo-hoo* have to switch to a different distro.

`sql injection` free php; this blonde's easy answer.

*why is sql injection in php even a problem?* i know a lot of old code still needs updated, and old versions with exploitable code is still all over the net. but why is new code ever having this problem. i know that the best practices answer is to use mysql_real_escape_string() to avoid these problems. but why? i dunno, cause i have an easier answer use htmlentities($input, ENT_QUOTES); on all user input, and i do mean all. i've implemented this on my current open source project. a second way of easily solving this issue is to use base64encoode(), the only problem i have with that solution is that it ends up making my database like impossible to read outside of my interface. but with htmlentities() everything is simply encode to where quotes simply are no longer an issue, because they're no longer there. using ENT_QUOTES is abs a must for this to fix remove sql injection vulnerability. the way i've implemented this is that during my projects core object instantiation i have it parse all get, post, &cookie vars through htmlentities($input, ENT_QUOTES). i do this with abs everything that receive from web browser that i may end up entering into any database. by this i mean certain http headers too, but that's only in special cases. using htmlentities($input, ENT_QUOTES); removes any possibility for sql injection, from user input that is. so no more escaping/un-escaping string or etc, and i can replace &update to my hearts content.

I have 'it', thousands do, and you've probably never heard of 'it'. 'it' twists our bodies, 'it' can ruin our lives; and occasionally 'it' will take them... what 'it' cannot twist, ruin, or take is our DREAMS! 'it' is Generalized Dystonia!

help test firefox3 while you rediscover the web!