I've worked in a variety of situations ranging from developers having root access to all workstations and production servers to having no admin rights on the workstation at all. There's a definite connection between developer's admin privileges and overall corporate culture. The less permissive the workstation environment is for the developer, the less creativity and innovation flows from the organization. I've especially seen this in banks where you're not allowed to install any software without a security officer's blessing. Contrast this with my current company, where each developer is fully responsible for maintaining their machine.
By depending on each other to understand the OS and learn the best tips and tricks for choosing which tools to use, every developer becomes capable of troubleshooting issues on the production machines. As a result, we takes just one operations / sysadmin person to manage the systems for a 20 person company. Of course, granting that level of permission requires a high level of trust that is often earned over time.
Few web applications are CPU bound. Most are bound by I/O, often that is between the data store and the app. No language selection is going to resolve that problem. If you're really concerned about the carbon footprint of your app, you're better off spending you time refactoring to optimize its performance rather than rewriting your {PHP | Ruby | Python | Perl} code in C++ or C.
Also consider the fact that many web applications are over-deployed. An idle server consumes as much energy as a busy one. You could save yourself a lot of carbon by using performance monitoring tools to determine the optimal number of servers to run your app.
I can imagine it now: Windows Vista Sensei battling to save Cyberspace from the evil Gutsy Gibbon...
The key to UNIX's longevity is its flexibility
on
The End of Unix?
·
· Score: 1
The era of minicomputers may be fading away, but the power of UNIX is hardly limited to that platform. The development of Mach at Carnegie Mellon University brought forth the idea of a device-independent UNIX that can run on any platform. UNIX runs just as well on the desktop as it does on the mainframe.
There's a bright future for UNIX. It continues to be the OS champion for web, file, application, and database servers, whose importance in the era of networked appliances will only increase. Given the current efforts to port UNIX to the PDA and the set-top box, how can you say it's about to die?
The M$ Natural Keyboard is my least favorite keyboard. It has one critical design flaw -- the "6" key is located on the left side of the keyboard. [Other manufacturers make the same mistake.] When I took touch typing in high school, I was trained to use the right index finger to reach for the "6" key.
I'm curious as to why it took CERT so long to issue this advisory. This problem has been known for a long time, and was reported widely by the media last year -- remember the eBay security problem?
When I worked on a web registration system for a client last year, one of the security concerns I had to consider was filtering HTML from the user's input.
Whether this problem is a responsibility for web site programmers or browser developers is not the point. What's important to remember is that any system that accepts code as data is inherently dangerous.
Slashdot Mirror
I've worked in a variety of situations ranging from developers having root access to all workstations and production servers to having no admin rights on the workstation at all. There's a definite connection between developer's admin privileges and overall corporate culture. The less permissive the workstation environment is for the developer, the less creativity and innovation flows from the organization. I've especially seen this in banks where you're not allowed to install any software without a security officer's blessing. Contrast this with my current company, where each developer is fully responsible for maintaining their machine.
By depending on each other to understand the OS and learn the best tips and tricks for choosing which tools to use, every developer becomes capable of troubleshooting issues on the production machines. As a result, we takes just one operations / sysadmin person to manage the systems for a 20 person company. Of course, granting that level of permission requires a high level of trust that is often earned over time.
Few web applications are CPU bound. Most are bound by I/O, often that is between the data store and the app. No language selection is going to resolve that problem. If you're really concerned about the carbon footprint of your app, you're better off spending you time refactoring to optimize its performance rather than rewriting your {PHP | Ruby | Python | Perl} code in C++ or C.
Also consider the fact that many web applications are over-deployed. An idle server consumes as much energy as a busy one. You could save yourself a lot of carbon by using performance monitoring tools to determine the optimal number of servers to run your app.
I can imagine it now:
Windows Vista Sensei battling to save Cyberspace from the evil Gutsy Gibbon...
The era of minicomputers may be fading away, but the power of UNIX is hardly limited to that platform. The development of Mach at Carnegie Mellon University brought forth the idea of a device-independent UNIX that can run on any platform. UNIX runs just as well on the desktop as it does on the mainframe.
There's a bright future for UNIX. It continues to be the OS champion for web, file, application, and database servers, whose importance in the era of networked appliances will only increase. Given the current efforts to port UNIX to the PDA and the set-top box, how can you say it's about to die?
The M$ Natural Keyboard is my least favorite keyboard. It has one critical design flaw -- the "6" key is located on the left side of the keyboard. [Other manufacturers make the same mistake.] When I took touch typing in high school, I was trained to use the right index finger to reach for the "6" key.
I use a Belkin Ergonomic Smart Keyboard -- the "6" key is in the right place, and it's cheapter than the M$ Natrual.
When I worked on a web registration system for a client last year, one of the security concerns I had to consider was filtering HTML from the user's input.
Whether this problem is a responsibility for web site programmers or browser developers is not the point. What's important to remember is that any system that accepts code as data is inherently dangerous.