First, let's be clear that this issue has nothing to do with SharePoint at all.
This falls 100% in the SQL admin realm. I only mention this so that if you do
any followup research that you don't throw SharePoint into your search and
potentially limit your results.

SQL writes every transaction to the the transaction log (the LDF file) in real
time, then as it has a chance it commits them to the database  file (the MDF
file). LDF files  are basically flat files with sequential lines, MDF files are
much more complicated, so in the interest of speed SQL does not write directly
to the MDF file. Now, what it does with that transaction file after the changes
are committed to the MDF file are up to you. You didn't mention which version
of SQL you're using. That's pretty important since this is an SQL issue. In
general terms you need to do a backup of your MDF and LDF files with an SQL
aware process (either in SQL or using a back up program that is SQL aware). You
should be able to shrink your LDF file after that. You can also set the
Recovery Mode of your databases  to Simple. That means that SQL flushes the
transaction from the LDF file once they are committed to the MDF file. It
doesn't automatically shrink the LDF file, but it is less likely that it will
grow as large. You can also set SQL to autoshrink the LDF and MDF files, but
I would not suggest it.

I'm clear it falls in the SQL Admin realm, and we are madly in love
with SharePoint. Precisely because we love it, I want to all "i"s
dotted for our MOSS deployment.

We are using SQL Server 2000 for our actual SPS/WSS 2003 and will use
SQL Server 2005 64 bit for our future MOSS/WSS 2007.
In my laptop I have SQL Server 2005 32 bit.
We do use backup exec for the production environment but obviously
not for my laptop. I guess the backup process in our production
server have been taking care of the growth of the ldf files.
For my laptop I'm going to change the recovery model to Simple as you
suggested and will shrink the logs  files too.

>"You can also set SQL to autoshrink the LDF and MDF files, but I
would not suggest it..."
Why is this not recommended? Is it not a best practice?

What about the 30 gb of log files  on the C:\WINDOWS\system32
\LogFiles\STS\ and subfolders in our production server?
Those are not sql server logs. How do I limit those in our actual SPS
server and in future MOSS deployment? Again, are there best practices
established for limiting those? Are there any links available?

LDF and MDF files  grow by nature. As time goes by you have more content, not
less. Every time you shrink an MDF or LDF file you force it to grow the next
time you add content. Each time it grows you run the risk of it getting
fragmented in the file system. Fragmented MDF and LDF files mean slow access
for SQL.

Do you have any advice about the 30 gb of log files  on the
C:\WINDOWS\system32
\LogFiles\STS\ and subfolders in our production SPS 2003 server?

Those are not sql server logs. How do I limit those in our actual SPS
server and in future MOSS deployment? Again, are there best practices
established for limiting those? Are there any links available?

Those are IIS log files. Generally, I just prune those using custom built
scripts to delete based upon age.

I don't know if the files  in the STS directory are IIS logs  or not.
Regardless they probably compress really, really well. J For my IIS
logs I zip them up. The web log analyser I use, Analog, can read ZIP
files, so that's not a problem. I would guess you can also delete the
old ones, but I like to keep them around, myself.