Sunday, February 25, 2007, 03:33 PM
I always like it when I get to hang out with my really cool wife.[ add comment ] | permalink |
( 3.2 / 31 )Saturday, January 27, 2007, 01:16 PM
I haven't had any bad experiences with BestBuy. But it seems that others have. I have read through the following post (what I deemed to be the "meat" of each of the 25 pages). Needless to say, others have had some pretty painful experiences with BestBuy. And I doubt that BB is the only company that has complaints & "horror-stories" like this one. I actually appreciate BestBuy in a way, because being a network consultant, sometimes I need a part/software fast, and they have a pretty decent stock. I must say that I think that their Dynex & GeekSquad lines of hardware are junk (I did get the run-around on a $55 external HD enclosure, which I finally just gave up on, even though it was still under the manufacturer's [Dynex/BestBuy] warranty). I've had far better results dealing with warranty claims with brand-name products. WalMart's array of stocked computer/soho network merchandise continues to grow, and I appreciate this good & sometimes cheaper alternative to BestBuy. Anyway, I'm not anit-BestBuy, but this person's experience has definitely caused me to have some serious second thoughts about buying their extended warranties (PSP's).
Check out the link:
http://www.redflagdeals.com/forums/showthread.php?t=393838
[ add comment ] ( 34 views ) | permalink | related link |
( 3 / 64 )Friday, January 26, 2007, 01:30 AM
When building (compiling) PHP4 (actually 4.4.4), you may run into a few caveats, like I did. I was able to overcome them, and hopefully these notes will help anyone else with the same problem, or perhaps myself, if I need to do this again in the future.
I am running an Apple iMac 350Mhz G3 with YellowDog Linux (YDL) 4. By the way, I would NEVER use YDL again. They don't keep up with package updates nearly as much as the more common distros (Fedora/Red Hat, Ubuntu, etc). This is what got me into this whole mess, and has again and again. The only way I have been able to successfully stay on top of the latest security patches, bug fixes, feature enhancements, bug releases, etc, is to get the sources and compile them myself. This is not my desired method of system maintenance & software upgrades. But until I migrate to a new server, I'm basically stuck with this.
Anyway, here was my sequence of events, including the problems I found, and how I fixed them:
1.) Downloaded PHP4.4.4 from http://www.php.net
2.) Unpacked the tarball & attempted to ./configure, make, then make install
3.) The process never failed, but gave some errors about needing a newer version of PEAR/XML_RPC
4.) At this point I restarted httpd anyway to see whether this fixed the PHP problems I'd been having with an older & buggy PHP. NO DICE!
5.) I decided to try to fix this PEAR/XML_RPC issue. I googled it, and found a download from the official PEAR site for the latest version. It was just a few .php files inside a tarball. I couldn't really find any info to help me install them, but researching, I was able to find that other people installed it using the pear package manager with the command "pear install XML_RPC" (omit the quotation marks). That sounded simple enough, so I decided it was worth a try.
6.) I used the official pear package manager install method: lynx -source http://go-pear.org/ | php. The installation seemed to complete, but it also gave me messages about not having a new enough version of XML_RPC (I found this to be a bit odd, since I felt like the dependency relationship should have probably been the other way around).
7.) I tried to rebuild PHP at this point, but got the same results.
8.) I then ran an updatedb, and after a few minutes, searched for the same XML_RPC files that I had unpacked. The previous versions were located in my system at: /usr/local/lib/php/test/XML_RPC. Since I couldn't easily locate any instructions for manual installation, I just backed up the current files, and then replaced them with my updated versions (same relative path + since the folder structure wasn't identical between the old & new versions, I copied the files to both directory locations (not a big deal for 2 files). (I'm pretty sure that they only need to be in one of the 2 places, but at this point I don't really care enough to take the time to figure it out [since I eventually did get it working]).
9.) I then re-ran the pear package manager installer. This time, no errors about XML_RPC needing updated ;-)
10.) Then I ran the command pear install XML_RPC, and it said the package was already installed, so I instead ran pear upgrade XML_RPC, and it successfully completed the process (so maybe the XML_RPC files have changed wince step 8 (all the reason more for me to not worry about it now ;-)
11.) I then attempted to recompile PHP. It seemed to do so successfully (no more errors about PEAR/XML_RPC), but after it compiled, I couldn't find the libphp4.so that needed to go in my apache2/modules directory. And after restarting httpd, PHP still seemed to be the old "buggy" version.
12.) I googled something like "libphp4.so" and the first 2-3 results contained the info that I needed (you have to tell the ./configure where your current apache2 apxs executible is.. like this: (./configure --with-apxs2=/usr/local/apache2/bin/apxs" (again, omit the quotes). I actually had to do this a few times, because I had some typos. I also had a truncated file after these typos, and the configure wouldn't run correctly until I deleted the source code altogether, then unpacked it again from the original tarball.
13.) This time took WAY longer than the previous runs... but it worked!!
One other problem I believe is that the 'make install' wants to put the libphp4.so in the correct place (which it did do), however if this file already exists, it doesn't seem to overwrite it, or create one by a different name. So as a precaution, it is probably a good idea to move the current one before running the 'make install'. Then again, I'm not sure than any of the compiling attempts except the last time actually did everything that they were supposed to, so maybe it just wasn't made in any of the compiling attempts prior to the final/successful one. I figure this, because the last build probably took 20 minutes, whereas the previous ones would take 3-5.
Anyway, as previously stated, I hope this helps somebody. The only problem I have with using this GREAT free software (linux, apache, PHP, etc) is that when you get it for free, you may not always get the support/documentation needed.
Cheers.
[ add comment ] | permalink |
( 4 / 1 )Saturday, November 18, 2006, 10:35 PM
Well, I have not really been making good use out of this blog. But here goes another post regarding WiFi bandwidth. As I was doing some more research on this and other WiFi topics today (in the dd-wrt forums), it appears that the available bandwidth is actually half-duplex (one way). When you have traffic flowing in both directions (which is typical of most TCP connections), the bandwidth is effectively cut in half (assuming that there was an equal amount of data needing to be transmitted in each direction).
Normal wired ethernet (IEEE 802.3x) generally gives you 100 Mbps at full duplex, which means simultaneously in both directions. So at any given time there can truely be a total of 200 Mbps of data traveling across your CAT5 cable.
As with pretty much anything in life, this is believed & accepted to be true and factual. However, just as scientists change the "truth" and facts, we also can change the "truth" as we continue learning. That's the nice thing about being human on Earth....
[ add comment ] | permalink | related link |
( 3.1 / 78 )Sunday, September 17, 2006, 08:27 PM
Everyday when I wake up I think about lots of things. One of them is Kyle. He is an awesome brother. Plus the fact that he speaks Spanish is a major bonus. He is the man!![ 1 comment ] ( 3 views ) | permalink |
( 3.1 / 59 )Back Next
