The Microsoft Windows registry is a file (some people describe it as a hierarchical database, and that is not a completely inaccurate description because of how the file is laid out) that stores configuration information for the Windows Operating System, as well as many of the software programs installed on the system. All of the information inside the Registry can be manipulated with a variety of tools to further customize how Windows looks, how it works, or the software on it. But this is not without substantial risk. Changing application (or system configurations) outside of appropriate tools (like the Control Panel, as one example) can cause a lot of problems. You may not even be aware of the impact until much later (the next time you use a program - fater a reboot, for example). I want to stress this - Editing the Registry is very risky and can cause many problems if you don't know what you're doing or edit the wrong things - to the point where Windows may no longer function.

The two most common tools for editing the registry on Windows are RegEdt32.exe and RegEdit.exe. However, there are other tools available and Yannis Grammatis identifies them on his website http://www.chaminade.org/MIS/Articles/RegistryEdit.htm.

Again, I want to reinforce my earlier warning.....

Editing the Registry is very risky and can cause many problems if you don't know what you're doing or edit the wrong things - to the point where Windows may no longer function.

So with these notes, why would you want to edit the registry? For some people it's a way to tweak (modify some obscure setting) that you normally wouldn't be able to access. Other settings may expose functionality for a program or feature you wouldn't normally be able to access - for instance a specific mouse may not fully emulate a different mouse - but by tweaking the setting in the registry you can convince Windows that the feature is supported.

This is not something I normally recommend doing - it is only for advanced users or people who don't worry about "breaking" their computer.

I picked up a new phone, but was having trouble getting to connect it to any computer. The phone is great, but I was hoping to find a tool to manage the information on it - my MP3s, my pictures, etc.

Finally I found bitpim (www.bitpim.org) to manage it. The tool works great on Windows, but not so well on Linux (at least I couldn't get it to work yet). However, to get it to work on the Windows, I needed a USB / CDMA driver, which had been removed from the LG website (bad LG!). I finally found it on SMSCaster.com (http://www.smscaster.com/download_driver_usb_data_cable.htm). Once I installed that, I was able to get it to work with Windows XP.

While i no longer use this phone (I've since replaced it with a Droid X and Android), I'm still publishing this as the BitPim tool was a great tool for backing up contacts and my calendar. I did finally get BitPim working on Linux (under Ubuntu v11.04) and was very happy with it.

Sometimes when you restore a database, the Microsoft SQL Server login SIDs don't match (especially if you restore the database from another server). So when you try to add a user to the database, you get the dreaded error....

user or role already exists in the current database

The following command will fix the problem for user timothy in the current database (NOTE: This must be the current database!):

EXEC SP_Change_Users_Login 'Auto_Fix','timothy'

This will allow the user timothy in the (current) database to synchronize information with the user timothy that is a SQL login in the master database.

The default prompt on PostgreSQL is very basic. It returns only the current database and a # sign.

Changing the prompt can be done with the SET command. So I could set the default prompt to:

\set PROMPT1 '%n@%m-%/=%# '

which would give me:

timb@pdx01aut031-mail=#

Additional information can be found at: http://www.postgresql.org/docs/8.1/static/app-psql.html#APP-PSQL-PROMPTING

Many people get tired of re-entering these commands every time they start the psql client. Luckily, there is a way to set this and execute other commands automatically when connecting to PostgreSQL. This is the use of the .psqlrc file in Linux. NOTE. This file resides in the current directory. In windows, the files should be called psqlrc.conf and is located in the Application DataPostgresql directory (echo %APPDATA%), so there can only be one for each user.

Installation of Microsoft SQL Server requires that it have certain permissions in order to run on the local system. Some people choose to have it run under a Domain Account that has Administrative Access. And at one point (especially SQL Server v6.5 and SQL Server v7.0) it was much easier to install if you used an Acount that had Administrative access (i.e., Local Administrator Group role). I even believed at one point that using a Domain account made it easier for SQL Agent jobs to export data to remote file shares. Changes in SQL Server and in SQL Server Integration Services (SSIS) and SQL Agent have fixed (or made easier) some of these issues. So I can now say to a former co-worker (Bill) that you were right, and we could have converted SQL Server to use a local account instead of a Domain Account (although this may still introduce some security concerns for some enterprises).

In any case, the account that Microsoft SQL Server uses needs the following rights include (instead of running under an account with Administrator rights): 'Access this computer from the network', 'Allow log on locally', 'Allow log on through Terminal Services', 'Bypass traverse checking', 'Force shutdown from a remote system', 'Perform volume maintenance tasks', 'Profile single process', 'Profile system performance', 'Shut down the system'. I do need to research this more as new versions of SQL Server (this is all based on SQL Server 2005 and Windows 2003) may require less or more permissions, especially as further changes are made to the Windows Security Model.

If you do use a Domain Account (or even a local account on the server), double check to ensure what other permissions the account has and what directories the account can access. Too much access could lead to additional exploits where users can access data without accountability. There could even be potential for a denial of service attack which would disrupt the system for all the other users and/or applications.

A separate concern, that still occurs today, is software or roles that need more permissions than really necessary? Applications may be grated something like db_datareader in all databases, which could cause information "leakage" so that one account/user/application with rights to a database can read data in other databases that it shouldn't. Other roles like 'db_ssisoperator,' 'SQLAgentOperatorRole,' 'ServerGroupReaderRole' in msdb, 'mdw_reader' in your Management Data Warehouse, and server permissions for 'Alter trace' 'View any database' 'View any definition', 'View server state' (For SQL 2005 substitute 'db_dtsoperator' for 'db_ssisoperator' and leave out 'ServerGroupReaderRole') could lead to more data leakage or even data tampering. And the role 'SQLAgentOperatorRole' can have even more serious repercussions by crafting a job that restarts SQL Server or the whole server if it's created correctly. In other words, think about the permissions you're granting to accounts and what access they might have.

Some of my reading on the web inspired this, and one article specifically caught my eye. Read this article (http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/05/28/why-i-say-something-about-running-as-administrator.aspx) for further information about other security concerns.

Before, I have posted here a few basic Linux terminal commands that I think are essential for newbies to know. I've also shared some deadly ones that should be avoided at all costs. This time, I'm going to show you several terminal commands that are perhaps unfamiliar to many new-to-Linux users but could be really handy when used properly.Heres a list of 10 rather unknown yet useful Linux terminal commands:

1. Kill a running application by its name: ···killall [app_name]

2. Display disk space usage: ···df -h

3. Locate the installation directories of a program: ···whereis [app]

4. Mount an .iso file: ···mount /path/to/file.iso /mnt/cdrom -oloop

5. Record or capture a video of your desktop: ···ffmpeg -f x11grab -s wxga -r 25 -i :0.0 -sameq /tmp/out.mpg

6. Find out the Universally Unique Identifier (UUID) of your partitions: ···ls /dev/disk/by-uuid/ -alh

7. Show the top ten running processes (sorted by memory usage): ···ps aux | sort -nrk 4 | head

8. Make an audible alarm when an IP address goes online: ···ping -i 60 -a IP_address

9. Run the last command as root: ···sudo !!

10. Make a whole directory tree with one command: ···mkdir -p tmp/a/b/c

http://www.junauza.com/2009/05/10-unknown-but-useful-linux-terminal.html

Sometimes you need to bind a second IP address to a Network Interface Card. Maybe you need access to another network temporarily or you just need to fix something that comes with a default address not on your network.

From Linux, you can execute the following command:

ifconfig eth0:1 192.168.5.16 netmask 255.255.255.0 up

NOTE: This will require ROOT (superuser) permissions!

This will add a second IP Address to your eth0 network interface.

The appliance obtains its IP via DHCP. The virtual console will display it at the top of the screen:

Citadel virtual appliance - (C) 2007 http://www.citadel.org
To log in to Citadel, point your web browser to http://192.168.1.22

Simply point your web browser there and get started. The default administraor has the username Citadel and password citadel. Obviously you will want to change the default once you log in. After you have logged in once with webcit, you can connect to that account with your favorite mail client via POP, IMAP or SMTP. A more thorough Getting Started may give you aditional information.

http://www.citadel.org/doku.php/installation:appliance

How do you tell if you're running on 32-bit or 64-bit hardware?

While the command uname -a will show wether you are using a 32-bit or 64-bit Operating System (as well as possibly looking at /etc/*release), it won't tell you if your hardware is actually 64-bit or not.

Instead, look at /proc/cpuinfo by running cat /proc/cpuinfo and look for lm in the flags section. If this flag exists, it's a 64-bit architecture for your CPU.

An easy way to do this is to type the following command. A blank line will be returned if it's false (i.e., not 64-bit) or it will print one or more lines (depending on the number of CPUs and Cores in your computer).

$ cat /proc/cpuinfo | grep lm