The real benefit of cli over other tools for me is in the troubleshooting of issues.
Think of it this way, to have an interface means to put several processes between you and the system or service performing the function you need. Using CLI gives you that extra edge of not having a filter on your product. The filter is great for day to day use and for people who do not find comfort in remembering 49,000 text based options. When you hit enter on a CLI it does something, when you hit enter on an interface other than CLI, you have to wait for two to three (or more) other services to function properly and do something. These days, nothing requires CLI on the consumer side. If your work load is greatly reduced by the use of CLI in setting up, support, monitor, or any other and you don't want to be hampered by the behind the scene actions of a GUI then stick with CLI. It all comes down to CLI in the end.

Hesperant

This is an interesting article, a bit inflammatory and quite lacking in valid details, seems more of a rant than not. While this seems to be just someone complaining it also illuminates a serious issue. IT is always treated as outside the business process and business is seen more of as an adversary to IT than a companion. Try busting these notions and you will have a healthy situation where your business personnel desire to work with it and IT desire to work with business. It can be done.

A: IT Personnel need to realize that no matter how bad things get, it is a customer service situation. You want people to understand your IT hurdles but at the same time tend to miss the details that it took years for us to get to understand those details ourselves. Your business sales people are good at what they do, your good at what you do, care for them. It does work I have done/seen/developed this.

B: Business personel, Remember when you get mad, that your IT personnel will respond when you yell with yelling. It is human nature to go bull and in any business relationship you should never accept a meek persons response or the yes mans IT values. They will yield few to no results in your goals. Bring your IT into the fold, include them in your business meetings so they can be aware of your needs. Most often, IT personnel can find solutions you might miss.

C: IT, you are all NERD!! or should be, a solution is always available. It might take a long time it might take a zeeeeeelion dollars but they do exist. Look at your options before declaring a project dead. Actually never declare an idea dead, Build the case for your yes or no and let the business people put their stamp on it. After all it is more work and that can be a good thing.

I am Nerd, Life is Nerd...

To Friendly neighborhood Linux Guy,

I applaud you for an attempt at breaking down the differences and coming to the rescue of Microsoft (who has indeed gotten better with Server 2008 and WIn7). However you sound quite informed unless the person reading it knows about what your talking about. I have run into this type of verbiage often in my career which usually ends up mis-educating some would be entrepreneur into thinking they are more aware than their IT team. Frankly you have mis-represented quite a few points and they need to be cleared up before totally contaminating the understanding of the untrained.

a: In the linux world, services do not always run as root, most do not run in the same group as root. Only custom apps will have the user root utilized when the developer needs to get something to work, then figure out what happened to permissions. Some times the dev will fail to complete that part of the project, opting to show a quick running version. Security in Linux is very good though not foolproof, there are 9 steps to make an application run automatically on a server, (Download, compile/execute, Meet dependancies, Find dependent Libraries, ModKernel, Load modified Kernel, Cron/init, and finally maintain the open port). Each stage requires more than a simple entrance via exploitable web code, which can compromise the web server easily resulting in off running services such as PHP Mail agents for spam lists or partial TCP requests nestled in a complete TCP packet for DOS/Overflow attempts.

b: The concept of Windows running services in protected separate running Kernels is great. However even Vista still runs a serial application stack which means non related applications can bring each other down. Services are all based on a single run process engine. While the engine can instantiate itself, this is the result of the system loosing access to the original running engine. Now with MS Windows there is protected memory space, which is designed to render data non readable in an overflow/dump attack. Linux has that to, it is called a best practice policy for operating systems.

To summarize, please do some research on current technologies and advertising dogma before you use them in policy, project, or posting a response. Companies usually have two options when fixing problems with their products. 1. Fix them, (remember it is technology nothing is perfect). 2. Produce deceptively similar terminology to downgrade the alarm of the issue to the point of non existence. Unfortunately in the long run, option 1 is the cheapest and best practice, while option 2 is the most used.

Because you did not sign a contract concerning the code or project then it would seem the following scenario best fits you.
Any code produced prior to employment can be applied under any license you wish it is owned by you and protected by lack of contractual agreement, this also forces code written afterwords to be GPL'd as part of the project.

Remember it is true that any work produced while getting paid is the product of the payer unless otherwise noted, they cannot simply assume the body of work as their own. They may attempt to argue legal custody so keep this in mind (and maintain your documentation). You own any code produced prior to employment (as long as you were accurate in your story): You can counter argue that they attempted to use employment as a means to acquire the project sans contract and thus have no legal right to it. You can also argue that they hired you for coding but not the specific code and because you have a prior body of work that goes into the project in deed like a book, you own the code (all of it) and they are licensed to use it for the duration of employment at the cost of employment. A more liberal interpretation may also take you to copy write. Code is writing for a computer to interpret and should fall under the copy write category. As an author is hired to produce a book you are hired to produce a program. Because the core code and in deed original versions of this application fall under a private enterprise you can argue ownership; now that said, this can effect your employment opportunities negatively.

      A good idea might be to engage in contract talks for the employer to purchase ownership or license with a limit to duration the right to keep your original code from GPL. While I am a giant fan of GPL, I do recognize the needs of employment and if they are wishing to in truth own the code, make sure you get a solid of what it is worth now and with possible future earnings in mind. Having them agree to contract with term limits allows you to give them decision rights on licensing for the duration of your contract (do not make it indefinite) and gives them time to have the original base code or ideas replaced by their own closed source work. Your work is worth something, get a lawyer (of your own not the company/employers) to write out an equitable contract.

I can see why this type of question would come up. If I cannot view something why can the governing team view something similar. A few explanations are: IT and support related people are not massive centers of knowledge on technical issues to often complex technical issues, access to other tech resources (even slashdot) are searchable resources. Allot of sites that are blocked at companies I support, are due to an abuse of them or common fear of them. Sites such as Facebook, or even Google Groups might have already been abused by others within your environment and made it on the list of blocked sites. Some services use automated complaint metrics to determine the eligibility of a site to be blocked or unblocked. A boss or coworker complains to an email address or web site that keeps a tally of what sites are causing the most issues and blocks them based on the level of complaint. As an example, someone in the office likes to listen to Andrew Dice Clay on You Toober and do so loudly. This individual might have been above reproach (specialized hard to find skill set) so a number of complaints are made to the automated system and soon You Toober becomes unavailable. These are just possibilities and not the exact reasons. I thought it best since I do not have any measure of control over your environment. hesperant

As most of the posters have indicated 1,000 unique visitors are easily accommodated, it is still nothing to sneeze at when it comes to supporting a business critical resource. When things go well then you can easily multiply the number of unique users.

Option 1. Using a predefined load balance solution such as HA Proxy is nice but still leaves you with a single point of failure (the Proxy), distribution tools and resources are abundant. Common ones are via virtual addressing (cisco IOS functions) but these still leave you with a single point of failure.

Option 2. DNS based HA, remote servers etc. With such a small load your capabilities could easily be supported by two servers and using a DNS based failover. Many DNS Sources have just such an option, look at your DNS provider for the specific options. Since most DNS sources have some hardening, the options are fairly solid and the single source of failure is mitigated.

Option 3. Virtual environments. Using a virtual environment you have a great flexibility with both service and failover. Resources such as The Grid (http://www.gogrid.com/) or Amazon Elastic Cloud Computing service (http://aws.amazon.com/ec2/). The benefit of cloud computing is uptime. Expecting failures is a good practice, and cloud computing allows you to expect the failure and if one occurs then the cloud can be programmed to automatically spawn a new instance or using metrics at a predefined load the cloud can be programmed to spawn a new instance and start forwarding unique requests to the new instance.

It is easy for us Linux loving types to be very fond of the home grown solutions. There are nice boxed solutions out there that solve your issues. In the end it all comes down to time and money. Since in many cases time is money, then money and money are your issues. You either pay for it up front or on the back side. While you can do just about anything with an open-source solution, your biggest factor is going to be expertise. There is allot of expertise available to help you with that need. In the case of closed source solutions, it may seem like an out of the box success but always be leery of the difference between how much work you have to do and how much the package costs.