liberal liberate libertine liberace

If you're planning on using a bluetooth headset just be warned: it ain't smooth sailing. The issue is that XP2 is it installs its own microsoft drivers called "microsoft enumerator", and those drivers do not work with many (or any) headsets.

And here is the real issue: you cannot uninstall the microsoft drivers. If you do, they'll re-install, and if you disable them, they'll still claim the bluetooth radio, whether they're disabled or not. You'll see the old and the new drivers, but the new driver properties will claim that there's no bluetooth present.

So what to do?

The answer is to go through the update drivers but you do NOT let microsoft pick the drivers. The specific instructions for getting it right are here:

http://support.microsoft.com/default.aspx?scid=kb;en-us;883258#2

Now I have the correct drivers, and they work, mostly. I still can't figure out why it constantly beeps the beep that means voice tag not found but I'll figure it out.

If you're confronted with problems on your /dev/ce device, here are a few handy things to remember:

ndd -set /dev/ce adv_autoneg_cap 1 sets it autonegotiate
ndd -set /dev/ce adv_1000fdx_cap 1 sets it to 1000 full

And here's a a very cool link:

http://www.razorsedge.org/~mike/software/linkck/

Is the location of a program which will dump the contents of the state of a network device.

Another little gotcha from HP: their home printers don't automatically allow themselves to be shared over a network. If you have a printer connected to one computer, and attempt to print to it from another computer, but with a different OS (e.g. 98 printing to XP). It won't work because the computer connected to the printer doesn't have the drivers for the other operating system.

The fix is fairly simple, although unbelievably annoying. Why the hell didn't HP fix this from the git go instead of making me hunt 5 hours for the solution?

The symptom is this: you install the printer on the remote computer, and you find that there are no drivers for it as you go through the install, and even inserting the CD won't install the drivers. You try to "pick from the list of drivers" but your computer is conveniently missing.

What you must do is take the CD and do a FULL install as if the printer were connected to the remote computer. Once that's done, you "install" your remote printer again, choosing some bogus printer from the list (remember, yours isn't there).

After it's installed, you open up the printer properties from the printers window, click on the 'advanced' key, and change the driver to the right one "PSC 1000 series" in this case. If the driver doesn't show up (and mine didn't the first time), delete and retry adding the printer -- at one point I saw files being copied, and all was well.

Here's another website explaining things.

You've got Webdav working. It works with your Windows 2k, 98, ME, and everything else. But it does NOT work with XP with Service Pack 2 installed. Why? Because in its wisdom, SP2 automatically disables basic authentication. How to get it back? Look at enabling basic authentication on xp sp2.

In short, you need to add a key/value pair to this node:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters

Add a new DWORD value. The Key should be UseBasicAuth and the value should be 1 to enable, and 0 to disable.

If you can't get your webdav to work at all, you may need this update from Microsoft

During the day I have four or five conversations on peer to peer
Skype. One day all you will need to offer voice is what you need to be
a DNS registrar.


What does that mean? It means that the phone system is going to get alot cheaper and alot simpler. I'm curious what the Telcos will do to replace the revenue.

It's important, in a webdav folder, that you don't add in a custom 404 or 403 page that provides a redirect to it (302).

If you do, you'll find that you can't move files to your webdav site. Why? Because the first command that a client issues when moving or copying a file is a HEAD to see if the file already exists. If it doesn't get a 404 back, then the operation will fail.

Just a word of warning.

When you want to link in a server to qmqp, here's how.

http://cr.yp.to/qmail/mini.html

The synopsis is this:

1) make sure qmqpd is running on server
2) set up some basic qmail stuff on client
3) link qmail-queue to qmail-qmqpc

That's the special sauce that invokes email on the client to use qmqp to talk to the main server

If you have vonage, and you have a Motorola vt1005, here's the destructions page.


http://broadband.motorola.com/consumers/products/VT1000v/downloads/VT1000v_User_Guide.pdf

Note to self:

1) I copied over the skins/custom1 skin and edited some of the functions so that they'd work with the new set
2) I edited admin/_edit_form.php and set the default category so that "general" would be default when posting new posts
3) I copied blogs/a_stub.php to blogs blog_a.php so that the previous skin would work. I think the session-saver is preventing the new URL from loading -- I had changed the "location" meta data in index.php to point to stub_a for the blog, but for some reason it kept looking for blog_a.php. Perhaps this due to the database settings.

A few helpful hints on setting up djb:

1) tinydns must run on its own IP. It won't share with a dnscache.
2) place the IP address that you want dnscache to bind to in /etc/path/to/root/of/dnscache/env/IP

2) place an empty file with the name of each ip block you want your cache to respond to in /etc/path/to/root/of/dnscache/root/ip directory
a.b.c would allow responses to a.b.c/24 a.b.c.d allows responses to a.b.c.d/32

3) If your /etc/path/to/root/of/dnscache/env/IP is a routable ip, external servers can use your cache. Be sure to put that very same ip in your /etc/resolv.conf, tho. 127.0.0.1 won't work because that's not where your daemon is bound to.

4) to make it a totally internal cache, put 127.0.0.1 in /etc/path/to/root/of/dnscache/env/IP and then put 127.0.0.1 in your /etc/resolv.conf to point your resolver to it. Now external servers can't use your dns server.

Since you can achieve the same thing by simply limiting who you respond to by what you put into the /etc/dnscache/root/ip directory, probably best to run that way -- more functionality.