This is half notes for myself and half helpful information for anyone else who wants a dedicated server on a decent OS. I assume you can use said decent OS and thus don't need me to hold your hand and guide you around the CLI.
Based off http://www.left4deadforums.com/1187-left-4-dead-linux-server-guide.html
1. Make a directory to put it all in.
mkdir hlds && chdir hlds
2. Download the file from valve to start it all off.
wget http://storefront.steampowered.com/download/updatetool.bin
3. Install the necessary 32bit libraries because Valve are still in the dark ages.
sudo apt-get install lib32gcc1
4. Run the file you downloaded.
chmod +x hldsupdatetool.bin && ./hldsupdatetool.bin
5. Accept the license agreement. Yes it scrolled past too fast to read. No you wern't going to read it anyway. Just accept it.
yes
6. Run the new steam executable with the right stuff to install the l4d server. The '-dir .' bit makes it put a l4d folder in the current dir. This is probably what you want.
chmod +x steam && ./steam -command update -game l4d_full -dir .
7. Wait for it to download then the configs will be in l4d/left4dead/cfg/server.cfg
vim l4d/left4dead/cfg/server.cfg
8. Make a config file. Something like the following should do fine.
hostname "My Server's Name" rconn_password "password" sv_other_settings "corresponding values"
9. Run the server up.
l4d/srcds_run l4d -autoupdate +ip <your servers ip address here> +hostpost 27203 +exec server.cfg +map l4d_farm01_hilltop &
10. Enjoy. You can control the server through the console in game by using "rcon_password <whatever password you put in the config file>".
The web is wonderful and software as a service (SAAS) makes it even more useful, giving us the ability to access our documents, images and videos using sites like Google docs, flickr and youtube wherever we go without needing to bring it all with us. This ability to access content wherever we are provided we have an internet connection is one of the biggest selling points of SAAS but there are other things to consider before throwing desktop apps out the window for good, not the least of which is desktop cohesion.
When using a given desktop environment you expect the programs you use to be consistent in their UI and to work together. For example, when using the Gnome desktop environment as I am now it is expected that I can select an image in F-Spot (the Gnome photo management program) and choose to send it to one of my contacts in Evolution (the Gnome email client). This is pretty standard behaviour.
On the other hand when using web applications I have no way of selecting a photo on my flickr account and sending it via email to one of my google contacts. At the very best I have to download the picture, leave flickr, open gmail, compose the email and attach the picture. This seems far too much effort in comparison to the ease at which such a task is accomplished using the equivalent desktop applications.
A second issue is the lack of a common visual interface between web applications. Taking each individual web application separately there is (normally) a clear reasoning behind the design. However when looking at the web applications as a whole the user interfaces vary greatly and although they are all usable individually when switching between sites often (to email pictures to friends for example) the interfaces can become confusing as the user is having to context switch far to often.
SAAS is a very useful concept but unless all the software comes from a single company or a group that have agreed on standards to work with it will continue to fail at what should be very simple tasks that users are used to expecting from the desktop applications they are used to using. The core problem lies in the lack of a common standard for an interface, either visually or programatically, to be used by all web apps but the very idea of imposing a standard opposes core concepts of the web as a creative medium.
There are two obvious solutions to this problem. The first is dull, uninnovative and useless as a realistic solution and is to merely revert to desktop applications. This immediatly solves the problem but loses all the benefits of switching to SAAS in the first place. This ’solution’ is obviously not viable for anyone who desires the benefits of SAAS.
The second solution is to somehow create a common interface between the web applications. Whether this is by seperating the service from the interface and developing a variety of interfaces to fit with the users expectations or by creating a single common interface for the web apps is something that remains to be seen but until web applications improve the interoperability between apps the SAAS platform will be left lacking a very basic and vital feature of the desktop based competition.