<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_12_31_1415245</id>
	<title>Do Your Developers Have Local Admin Rights?</title>
	<author>CmdrTaco</author>
	<datestamp>1262277900000</datestamp>
	<htmltext>plover writes <i>"I work as a developer for a Very Large American Corporation.  We are not an IT company, but have a large IT organization that does a lot of internal development.  In my area, we do Windows development, which includes writing and maintaining code for various services and executables.  A few years ago the Info Security group removed local administrator rights from most accounts and machines, but our area was granted exceptions for developers.  My question is: do other developers in other large companies have local admin rights to their development environment?  If not, how do you handle tasks like debugging, testing installations, or installing updated development tools that aren't a part of the standard corporate workstation?"</i></htmltext>
<tokenext>plover writes " I work as a developer for a Very Large American Corporation .
We are not an IT company , but have a large IT organization that does a lot of internal development .
In my area , we do Windows development , which includes writing and maintaining code for various services and executables .
A few years ago the Info Security group removed local administrator rights from most accounts and machines , but our area was granted exceptions for developers .
My question is : do other developers in other large companies have local admin rights to their development environment ?
If not , how do you handle tasks like debugging , testing installations , or installing updated development tools that are n't a part of the standard corporate workstation ?
"</tokentext>
<sentencetext>plover writes "I work as a developer for a Very Large American Corporation.
We are not an IT company, but have a large IT organization that does a lot of internal development.
In my area, we do Windows development, which includes writing and maintaining code for various services and executables.
A few years ago the Info Security group removed local administrator rights from most accounts and machines, but our area was granted exceptions for developers.
My question is: do other developers in other large companies have local admin rights to their development environment?
If not, how do you handle tasks like debugging, testing installations, or installing updated development tools that aren't a part of the standard corporate workstation?
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608742</id>
	<title>Re:virtualization</title>
	<author>Slashdot Parent</author>
	<datestamp>1262291220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Why do you need 3 IDEs, an SQL authoring tool, and a database explorer open at the same time?  Ever hear of IDE plugins?</p></htmltext>
<tokenext>Why do you need 3 IDEs , an SQL authoring tool , and a database explorer open at the same time ?
Ever hear of IDE plugins ?</tokentext>
<sentencetext>Why do you need 3 IDEs, an SQL authoring tool, and a database explorer open at the same time?
Ever hear of IDE plugins?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607112</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612908</id>
	<title>No local admin by default...</title>
	<author>mjb</author>
	<datestamp>1230802680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>We all had local admin rights until about a year ago. Under the new policy, standard user logins do not have local admin rights. If you need to install software, you need to login as a separate poweruser, which in turn disables access to all network resources (drives, printers, etc).</p><p>It was a big pain, and people did a lot of bitching and moaning, but slowly we're getting used to it.</p><p>There are several options:<br>1.) logout/login as poweruser<br>2.) Right-click, do 'Run As'<br>3.) While running as local user, open a CMD window that's running as poweruser.</p><p>-Mark</p></htmltext>
<tokenext>We all had local admin rights until about a year ago .
Under the new policy , standard user logins do not have local admin rights .
If you need to install software , you need to login as a separate poweruser , which in turn disables access to all network resources ( drives , printers , etc ) .It was a big pain , and people did a lot of bitching and moaning , but slowly we 're getting used to it.There are several options : 1 .
) logout/login as poweruser2 .
) Right-click , do 'Run As'3 .
) While running as local user , open a CMD window that 's running as poweruser.-Mark</tokentext>
<sentencetext>We all had local admin rights until about a year ago.
Under the new policy, standard user logins do not have local admin rights.
If you need to install software, you need to login as a separate poweruser, which in turn disables access to all network resources (drives, printers, etc).It was a big pain, and people did a lot of bitching and moaning, but slowly we're getting used to it.There are several options:1.
) logout/login as poweruser2.
) Right-click, do 'Run As'3.
) While running as local user, open a CMD window that's running as poweruser.-Mark</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611706</id>
	<title>Re:What it REALLY comes down to</title>
	<author>Anonymous</author>
	<datestamp>1262270520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Microsoft's current recommended platform for business development is ".Net".<nobr> <wbr></nobr>.Net desktop application can be simply copied to a folder and run.  However, the stuff that makes applications easy to support is where the problem lies.  For example, to properly log to the Application log in a way that can be searched and filtered, you need to add an event log source to the system.  This can be done on the first instance of a logged event, but then the user would need elevated rights.  So, we make installers that create the log source on install.  No sane Windows developer has put anything they wrote in the system32 folder for the last twenty years.  Another note is that<nobr> <wbr></nobr>.Net applications use a config file that resides in the same directory as the application by default.</htmltext>
<tokenext>Microsoft 's current recommended platform for business development is " .Net " .
.Net desktop application can be simply copied to a folder and run .
However , the stuff that makes applications easy to support is where the problem lies .
For example , to properly log to the Application log in a way that can be searched and filtered , you need to add an event log source to the system .
This can be done on the first instance of a logged event , but then the user would need elevated rights .
So , we make installers that create the log source on install .
No sane Windows developer has put anything they wrote in the system32 folder for the last twenty years .
Another note is that .Net applications use a config file that resides in the same directory as the application by default .</tokentext>
<sentencetext>Microsoft's current recommended platform for business development is ".Net".
.Net desktop application can be simply copied to a folder and run.
However, the stuff that makes applications easy to support is where the problem lies.
For example, to properly log to the Application log in a way that can be searched and filtered, you need to add an event log source to the system.
This can be done on the first instance of a logged event, but then the user would need elevated rights.
So, we make installers that create the log source on install.
No sane Windows developer has put anything they wrote in the system32 folder for the last twenty years.
Another note is that .Net applications use a config file that resides in the same directory as the application by default.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607508</id>
	<title>Re:You damn well should</title>
	<author>Sycraft-fu</author>
	<datestamp>1262285400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't know why people seem to think that sysadmins and developers are the same thing. They aren't, it is different skill sets. There are good sysadmins who can't program, and good programmers who know very little about system administration.</p><p>Personally I think developers shouldn't have admin in general because it may force them to think about how their code runs as an unprivileged user. There are still way too many apps that want admin to run. This is a result of shoddy coding, nothing more. Devs write it as admin, test it as admin, and thus never see any problems. If they had to run as a regular user, they'd be forced to make their code work properly.</p><p>All in all I think the proper method is something like what we do at work. I work for a university so saying "no admin ever" isn't a position we can take. More or less we try to talk people in to no admin, since in our experience it leads to way less problems. In the event they aren't ok with that we give them an admin account along with their regular one. They are expected to use their regular account, and just use the admin one to escalate as needed. Further, when they become admin they take responsibility for the system. If it gets infected, it is on them, not us. We then try to talk their professor in to removing their admin access, which we often succeed in. There are several labs where everyone used to have admin and now nobody does.</p><p>In the case of a company, I'd say that devs who want admin should have to sign a little document saying the understand the risks and it is on them to not mess up their system. If they do mess it up, they get to go in front of the boss and explain why, and then explain why they need to keep admin. More or less a situation where you have to take accountability. You can't say "I want to have full access, but you need to be there to hold my hand and fix shit if I break it." No, can't work that way. If you want the power, with it you have to take the responsibility.</p><p>The reasons we object overall to people having admin is not because we are control freaks, but because experience shows that there are less problems that way (all our virused and spywared systems are from people with admin) and because people don't seem to want to be responsible for their actions.</p></htmltext>
<tokenext>I do n't know why people seem to think that sysadmins and developers are the same thing .
They are n't , it is different skill sets .
There are good sysadmins who ca n't program , and good programmers who know very little about system administration.Personally I think developers should n't have admin in general because it may force them to think about how their code runs as an unprivileged user .
There are still way too many apps that want admin to run .
This is a result of shoddy coding , nothing more .
Devs write it as admin , test it as admin , and thus never see any problems .
If they had to run as a regular user , they 'd be forced to make their code work properly.All in all I think the proper method is something like what we do at work .
I work for a university so saying " no admin ever " is n't a position we can take .
More or less we try to talk people in to no admin , since in our experience it leads to way less problems .
In the event they are n't ok with that we give them an admin account along with their regular one .
They are expected to use their regular account , and just use the admin one to escalate as needed .
Further , when they become admin they take responsibility for the system .
If it gets infected , it is on them , not us .
We then try to talk their professor in to removing their admin access , which we often succeed in .
There are several labs where everyone used to have admin and now nobody does.In the case of a company , I 'd say that devs who want admin should have to sign a little document saying the understand the risks and it is on them to not mess up their system .
If they do mess it up , they get to go in front of the boss and explain why , and then explain why they need to keep admin .
More or less a situation where you have to take accountability .
You ca n't say " I want to have full access , but you need to be there to hold my hand and fix shit if I break it .
" No , ca n't work that way .
If you want the power , with it you have to take the responsibility.The reasons we object overall to people having admin is not because we are control freaks , but because experience shows that there are less problems that way ( all our virused and spywared systems are from people with admin ) and because people do n't seem to want to be responsible for their actions .</tokentext>
<sentencetext>I don't know why people seem to think that sysadmins and developers are the same thing.
They aren't, it is different skill sets.
There are good sysadmins who can't program, and good programmers who know very little about system administration.Personally I think developers shouldn't have admin in general because it may force them to think about how their code runs as an unprivileged user.
There are still way too many apps that want admin to run.
This is a result of shoddy coding, nothing more.
Devs write it as admin, test it as admin, and thus never see any problems.
If they had to run as a regular user, they'd be forced to make their code work properly.All in all I think the proper method is something like what we do at work.
I work for a university so saying "no admin ever" isn't a position we can take.
More or less we try to talk people in to no admin, since in our experience it leads to way less problems.
In the event they aren't ok with that we give them an admin account along with their regular one.
They are expected to use their regular account, and just use the admin one to escalate as needed.
Further, when they become admin they take responsibility for the system.
If it gets infected, it is on them, not us.
We then try to talk their professor in to removing their admin access, which we often succeed in.
There are several labs where everyone used to have admin and now nobody does.In the case of a company, I'd say that devs who want admin should have to sign a little document saying the understand the risks and it is on them to not mess up their system.
If they do mess it up, they get to go in front of the boss and explain why, and then explain why they need to keep admin.
More or less a situation where you have to take accountability.
You can't say "I want to have full access, but you need to be there to hold my hand and fix shit if I break it.
" No, can't work that way.
If you want the power, with it you have to take the responsibility.The reasons we object overall to people having admin is not because we are control freaks, but because experience shows that there are less problems that way (all our virused and spywared systems are from people with admin) and because people don't seem to want to be responsible for their actions.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606980</id>
	<title>Sort of</title>
	<author>Anonymous</author>
	<datestamp>1262283360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>For windows, by default no. You can programaticly acquire a local admin account, but doing so is also an opt out for a good chunk of IT support.</p><p>For linux, you almost certainly have full sudo rights for the box under your desk (and could get root trivially since you have physical control of the box).</p></htmltext>
<tokenext>For windows , by default no .
You can programaticly acquire a local admin account , but doing so is also an opt out for a good chunk of IT support.For linux , you almost certainly have full sudo rights for the box under your desk ( and could get root trivially since you have physical control of the box ) .</tokentext>
<sentencetext>For windows, by default no.
You can programaticly acquire a local admin account, but doing so is also an opt out for a good chunk of IT support.For linux, you almost certainly have full sudo rights for the box under your desk (and could get root trivially since you have physical control of the box).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30654452</id>
	<title>Re:Yes</title>
	<author>Anonymous</author>
	<datestamp>1231169340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>cough cough BULLSHIT!!    Oh wait.. you didn't say if you ran on UNIX or Windows.</p><p>There is absolutely ZERO  reason to require administrative rights to the systems to do development work on a UNIX operating system.</p><p>Want servers running with listeners below 1024?   No problem.. grant that individual right to the application userid that is used to start/stop the application - NEVER run the apps as root.</p><p>Developers develop the code.. Application admins deploy it - separation / segregation of responsibilities - anyone who works for a financial institution that has to follow Sarbanes Oxley has to do this.</p></htmltext>
<tokenext>cough cough BULLSHIT ! !
Oh wait.. you did n't say if you ran on UNIX or Windows.There is absolutely ZERO reason to require administrative rights to the systems to do development work on a UNIX operating system.Want servers running with listeners below 1024 ?
No problem.. grant that individual right to the application userid that is used to start/stop the application - NEVER run the apps as root.Developers develop the code.. Application admins deploy it - separation / segregation of responsibilities - anyone who works for a financial institution that has to follow Sarbanes Oxley has to do this .</tokentext>
<sentencetext>cough cough BULLSHIT!!
Oh wait.. you didn't say if you ran on UNIX or Windows.There is absolutely ZERO  reason to require administrative rights to the systems to do development work on a UNIX operating system.Want servers running with listeners below 1024?
No problem.. grant that individual right to the application userid that is used to start/stop the application - NEVER run the apps as root.Developers develop the code.. Application admins deploy it - separation / segregation of responsibilities - anyone who works for a financial institution that has to follow Sarbanes Oxley has to do this.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606850</id>
	<title>Not everything is perfectly virtualized</title>
	<author>tepples</author>
	<datestamp>1262282940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>this is what desktop virtualization is *for*.  use vmware workstation or virtualbox and test away!</p></div><p>And then the program fails because it can't see hardware that the VM doesn't properly virtualize, such as USB devices or 3D capabilities of the video card in low-end VM software. High-end VM software, which can virtualize these devices, is nearly as expensive per seat as a nettop, and the nettop comes with a free copy of Windows anyway.</p></div>
	</htmltext>
<tokenext>this is what desktop virtualization is * for * .
use vmware workstation or virtualbox and test away ! And then the program fails because it ca n't see hardware that the VM does n't properly virtualize , such as USB devices or 3D capabilities of the video card in low-end VM software .
High-end VM software , which can virtualize these devices , is nearly as expensive per seat as a nettop , and the nettop comes with a free copy of Windows anyway .</tokentext>
<sentencetext>this is what desktop virtualization is *for*.
use vmware workstation or virtualbox and test away!And then the program fails because it can't see hardware that the VM doesn't properly virtualize, such as USB devices or 3D capabilities of the video card in low-end VM software.
High-end VM software, which can virtualize these devices, is nearly as expensive per seat as a nettop, and the nettop comes with a free copy of Windows anyway.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606524</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607598</id>
	<title>Yes and No</title>
	<author>Anonymous</author>
	<datestamp>1262285700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Locally and to the development and staging environments yes, they typically have administrator/root/sudo privileges almost any where I've worked.  It's almost impossible for them to do their job well if they don't.</p></htmltext>
<tokenext>Locally and to the development and staging environments yes , they typically have administrator/root/sudo privileges almost any where I 've worked .
It 's almost impossible for them to do their job well if they do n't .</tokentext>
<sentencetext>Locally and to the development and staging environments yes, they typically have administrator/root/sudo privileges almost any where I've worked.
It's almost impossible for them to do their job well if they don't.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606590</id>
	<title>Yes</title>
	<author>Anonymous</author>
	<datestamp>1262282040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>We maintain a development network and a QA network.  The dev and QA teams have admin on the server machines in these networks. This is useful/necessary because we are constantly spinning up and tearing down virtual machines for various scenarios. Devs have local admin on their workstations.  In general this has worked fine, except for one moron who used the privilege to turn off her virus scanning.</p><p>Production is subject to more structured control in theory, but in practice, I and another couple of guys have<nobr> <wbr></nobr>/sudo/root on the prod machines, because our corporate admins don't want to learn enough about the software to be useful.  So much for PCI...</p></htmltext>
<tokenext>We maintain a development network and a QA network .
The dev and QA teams have admin on the server machines in these networks .
This is useful/necessary because we are constantly spinning up and tearing down virtual machines for various scenarios .
Devs have local admin on their workstations .
In general this has worked fine , except for one moron who used the privilege to turn off her virus scanning.Production is subject to more structured control in theory , but in practice , I and another couple of guys have /sudo/root on the prod machines , because our corporate admins do n't want to learn enough about the software to be useful .
So much for PCI.. .</tokentext>
<sentencetext>We maintain a development network and a QA network.
The dev and QA teams have admin on the server machines in these networks.
This is useful/necessary because we are constantly spinning up and tearing down virtual machines for various scenarios.
Devs have local admin on their workstations.
In general this has worked fine, except for one moron who used the privilege to turn off her virus scanning.Production is subject to more structured control in theory, but in practice, I and another couple of guys have /sudo/root on the prod machines, because our corporate admins don't want to learn enough about the software to be useful.
So much for PCI...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436</id>
	<title>What?</title>
	<author>Anonymous</author>
	<datestamp>1262281620000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext>We just have a development environment for them. Then once code is ready we copy the most recent backup image of the servers over, they install there, document how, and then our sys admins install. Done and done.</htmltext>
<tokenext>We just have a development environment for them .
Then once code is ready we copy the most recent backup image of the servers over , they install there , document how , and then our sys admins install .
Done and done .</tokentext>
<sentencetext>We just have a development environment for them.
Then once code is ready we copy the most recent backup image of the servers over, they install there, document how, and then our sys admins install.
Done and done.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30670344</id>
	<title>Re:What it REALLY comes down to</title>
	<author>jimicus</author>
	<datestamp>1231260720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Most Unix applications can be installed in ~/bin and can be told to look in places other than<nobr> <wbr></nobr>/etc for their configuration.</p><p>There is a huge number of Windows applications that simply won't work if you try and do anything analogous on Windows.</p></htmltext>
<tokenext>Most Unix applications can be installed in ~ /bin and can be told to look in places other than /etc for their configuration.There is a huge number of Windows applications that simply wo n't work if you try and do anything analogous on Windows .</tokentext>
<sentencetext>Most Unix applications can be installed in ~/bin and can be told to look in places other than /etc for their configuration.There is a huge number of Windows applications that simply won't work if you try and do anything analogous on Windows.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610034</id>
	<title>Yes, but there are workarounds anyway</title>
	<author>larwe</author>
	<datestamp>1262255400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>At my Very Large Corporation our developers need admin rights because we are constantly tinkering with special hardware, updating drivers, running software that's not supported by anyone (obsolete compilers and debugging tools in particular), etc. So we have admin rights.

However there are some corners of the org where this is not the case (mostly not in the US). The devs in these corners get their testing done by running unrestricted private installs of Windows inside VirtualBox. We have ready-to-run disk images on our servers for restore if something gets hosed in one of the virtual environments.</htmltext>
<tokenext>At my Very Large Corporation our developers need admin rights because we are constantly tinkering with special hardware , updating drivers , running software that 's not supported by anyone ( obsolete compilers and debugging tools in particular ) , etc .
So we have admin rights .
However there are some corners of the org where this is not the case ( mostly not in the US ) .
The devs in these corners get their testing done by running unrestricted private installs of Windows inside VirtualBox .
We have ready-to-run disk images on our servers for restore if something gets hosed in one of the virtual environments .</tokentext>
<sentencetext>At my Very Large Corporation our developers need admin rights because we are constantly tinkering with special hardware, updating drivers, running software that's not supported by anyone (obsolete compilers and debugging tools in particular), etc.
So we have admin rights.
However there are some corners of the org where this is not the case (mostly not in the US).
The devs in these corners get their testing done by running unrestricted private installs of Windows inside VirtualBox.
We have ready-to-run disk images on our servers for restore if something gets hosed in one of the virtual environments.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606700</id>
	<title>Not on any test systems</title>
	<author>Anonymous</author>
	<datestamp>1262282460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>One of the problems I always run into is programs that require admin privileges to run. Not just install but to actually run properly. This is from the developers always having admin access and never actually testing under a user account. Things have gotten better over the years but there is still stuff out there that tries to pull this crap.</p></htmltext>
<tokenext>One of the problems I always run into is programs that require admin privileges to run .
Not just install but to actually run properly .
This is from the developers always having admin access and never actually testing under a user account .
Things have gotten better over the years but there is still stuff out there that tries to pull this crap .</tokentext>
<sentencetext>One of the problems I always run into is programs that require admin privileges to run.
Not just install but to actually run properly.
This is from the developers always having admin access and never actually testing under a user account.
Things have gotten better over the years but there is still stuff out there that tries to pull this crap.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609388</id>
	<title>Common Operating Environments</title>
	<author>peterofoz</author>
	<datestamp>1262251560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Large corporations often standardize workstation setups in an effort to:</p><ul>
<li>reduced cost of the help desk support</li>
<li>simplified license compliance</li>
<li>standardized platform for enterprise integration</li>
<li>remote support and monitoring</li>
<li>improved security and antivirus</li>
</ul><p>Developers usually need admin rights to a workstation or VM somewhere in order to develop and integrate applications. For our last project we used COE workstations and developed our apps on a VMware, then used the COE environment to test functionality. We ended up needing admin rights to 1 'dirty' workstation since our integration was going to require a change to the COE, but we kept the rest clean. </p><p>The funny but sad part was the COE was not as standardized as we were led to believe with COE workstations sporting different versions of Java and IE which caused some interesting problems.</p></htmltext>
<tokenext>Large corporations often standardize workstation setups in an effort to : reduced cost of the help desk support simplified license compliance standardized platform for enterprise integration remote support and monitoring improved security and antivirus Developers usually need admin rights to a workstation or VM somewhere in order to develop and integrate applications .
For our last project we used COE workstations and developed our apps on a VMware , then used the COE environment to test functionality .
We ended up needing admin rights to 1 'dirty ' workstation since our integration was going to require a change to the COE , but we kept the rest clean .
The funny but sad part was the COE was not as standardized as we were led to believe with COE workstations sporting different versions of Java and IE which caused some interesting problems .</tokentext>
<sentencetext>Large corporations often standardize workstation setups in an effort to:
reduced cost of the help desk support
simplified license compliance
standardized platform for enterprise integration
remote support and monitoring
improved security and antivirus
Developers usually need admin rights to a workstation or VM somewhere in order to develop and integrate applications.
For our last project we used COE workstations and developed our apps on a VMware, then used the COE environment to test functionality.
We ended up needing admin rights to 1 'dirty' workstation since our integration was going to require a change to the COE, but we kept the rest clean.
The funny but sad part was the COE was not as standardized as we were led to believe with COE workstations sporting different versions of Java and IE which caused some interesting problems.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607666</id>
	<title>Re:You damn well should</title>
	<author>S-4'N3</author>
	<datestamp>1262286000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>CTO: "So you stopped doing SVN commits and you just make changes on the production server?"
Developer: "Yes."
CTO: "Why?"
Developer: "..."</htmltext>
<tokenext>CTO : " So you stopped doing SVN commits and you just make changes on the production server ?
" Developer : " Yes .
" CTO : " Why ?
" Developer : " ... "</tokentext>
<sentencetext>CTO: "So you stopped doing SVN commits and you just make changes on the production server?
"
Developer: "Yes.
"
CTO: "Why?
"
Developer: "..."</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606494</id>
	<title>your obviously not a developer</title>
	<author>Anonymous</author>
	<datestamp>1262281800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you dont know how to work around this issue...  You dont NEED to be an administrator to debug or install.  That said, it makes things really easy if you have a way of getting administrative privlidges to your developers.  But thats a policy decision isnt it.</p></htmltext>
<tokenext>If you dont know how to work around this issue... You dont NEED to be an administrator to debug or install .
That said , it makes things really easy if you have a way of getting administrative privlidges to your developers .
But thats a policy decision isnt it .</tokentext>
<sentencetext>If you dont know how to work around this issue...  You dont NEED to be an administrator to debug or install.
That said, it makes things really easy if you have a way of getting administrative privlidges to your developers.
But thats a policy decision isnt it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607390</id>
	<title>Re:You damn well should</title>
	<author>AnodeCathode</author>
	<datestamp>1262284920000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>We allowed our developers to have local admin access.  In exchange, their machines were located on a separate VLAN and all communication routed through an internal firewall.  This allowed these uncontrolled machines to do what the developers wanted, but allowed us to easily shut them down in an outbreak.  It also gave the developers easy access to logging their traffic and understanding exactly what would be required to have applications run in a restricted environment.</p><p>For production systems, the developers had separate admin accounts that would be granted the required access to a system with a logged change request, time limited.</p><p>It works reasonably well.  Of course the developers could just plug into a non-restricted port, but of course, this is better managed through policy than technology.</p></htmltext>
<tokenext>We allowed our developers to have local admin access .
In exchange , their machines were located on a separate VLAN and all communication routed through an internal firewall .
This allowed these uncontrolled machines to do what the developers wanted , but allowed us to easily shut them down in an outbreak .
It also gave the developers easy access to logging their traffic and understanding exactly what would be required to have applications run in a restricted environment.For production systems , the developers had separate admin accounts that would be granted the required access to a system with a logged change request , time limited.It works reasonably well .
Of course the developers could just plug into a non-restricted port , but of course , this is better managed through policy than technology .</tokentext>
<sentencetext>We allowed our developers to have local admin access.
In exchange, their machines were located on a separate VLAN and all communication routed through an internal firewall.
This allowed these uncontrolled machines to do what the developers wanted, but allowed us to easily shut them down in an outbreak.
It also gave the developers easy access to logging their traffic and understanding exactly what would be required to have applications run in a restricted environment.For production systems, the developers had separate admin accounts that would be granted the required access to a system with a logged change request, time limited.It works reasonably well.
Of course the developers could just plug into a non-restricted port, but of course, this is better managed through policy than technology.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608396</id>
	<title>Re:Yes</title>
	<author>Anonymous</author>
	<datestamp>1262289360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Holy crap, you are the moron if you are running virus scanners on development machines, not that one sane person who turned it off. That shit will make your system slow to a crawl, especially for compiling. Do a full scan once at night every day, and never have it do anything else to your computer, then your sane users won't turn it off to stay that way.</p></htmltext>
<tokenext>Holy crap , you are the moron if you are running virus scanners on development machines , not that one sane person who turned it off .
That shit will make your system slow to a crawl , especially for compiling .
Do a full scan once at night every day , and never have it do anything else to your computer , then your sane users wo n't turn it off to stay that way .</tokentext>
<sentencetext>Holy crap, you are the moron if you are running virus scanners on development machines, not that one sane person who turned it off.
That shit will make your system slow to a crawl, especially for compiling.
Do a full scan once at night every day, and never have it do anything else to your computer, then your sane users won't turn it off to stay that way.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606590</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30619988</id>
	<title>Re:What it REALLY comes down to</title>
	<author>Anonymous</author>
	<datestamp>1230837420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The registry is pretty much unreadable? How is {qwerlajsdf;lkajsdf;ljqwieru1293421934213} in any way supposed to relate to what it actually does on my machine?</p></htmltext>
<tokenext>The registry is pretty much unreadable ?
How is { qwerlajsdf ; lkajsdf ; ljqwieru1293421934213 } in any way supposed to relate to what it actually does on my machine ?</tokentext>
<sentencetext>The registry is pretty much unreadable?
How is {qwerlajsdf;lkajsdf;ljqwieru1293421934213} in any way supposed to relate to what it actually does on my machine?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608776</id>
	<title>I hope so....</title>
	<author>LordBoreal51</author>
	<datestamp>1262291400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>At my last job, I wasted tens of hours on trying to get the IT guy to come down to my workstation and give me the local privileges needed to compile or configure my various IDEs. Finally he just gave up and made me a local admin and there wasn't a problem after that.

(This was a Windows setup, BTW)</htmltext>
<tokenext>At my last job , I wasted tens of hours on trying to get the IT guy to come down to my workstation and give me the local privileges needed to compile or configure my various IDEs .
Finally he just gave up and made me a local admin and there was n't a problem after that .
( This was a Windows setup , BTW )</tokentext>
<sentencetext>At my last job, I wasted tens of hours on trying to get the IT guy to come down to my workstation and give me the local privileges needed to compile or configure my various IDEs.
Finally he just gave up and made me a local admin and there wasn't a problem after that.
(This was a Windows setup, BTW)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610544</id>
	<title>Our devs have root/admin</title>
	<author>Sarusa</author>
	<datestamp>1262259060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I completely own my linux box at work (root and all), and I have admin privileges on my XP desktop. There are a couple company tools that IT pushes and updates (like antivirus), but I can install and run anything I want. It basically boils down to us wanting to get work done, and if I had to wait for IT to install everything I needed when I needed it we'd be a month behind on the latest project instead of two weeks ahead of schedule. This comes with the expectation that if I do something stupid like start torrenting porn from my work computers that I will get slapped hard, and that's fair enough.</p><p>So that seems the way to go: allow devs admin privileges and fire them if they're dumb enough they can't handle that. This is win-win for dev and IT, unless IT is primarily interested in empire building. Everything else is just a doomed hack around the fact that you hired bad people.</p></htmltext>
<tokenext>I completely own my linux box at work ( root and all ) , and I have admin privileges on my XP desktop .
There are a couple company tools that IT pushes and updates ( like antivirus ) , but I can install and run anything I want .
It basically boils down to us wanting to get work done , and if I had to wait for IT to install everything I needed when I needed it we 'd be a month behind on the latest project instead of two weeks ahead of schedule .
This comes with the expectation that if I do something stupid like start torrenting porn from my work computers that I will get slapped hard , and that 's fair enough.So that seems the way to go : allow devs admin privileges and fire them if they 're dumb enough they ca n't handle that .
This is win-win for dev and IT , unless IT is primarily interested in empire building .
Everything else is just a doomed hack around the fact that you hired bad people .</tokentext>
<sentencetext>I completely own my linux box at work (root and all), and I have admin privileges on my XP desktop.
There are a couple company tools that IT pushes and updates (like antivirus), but I can install and run anything I want.
It basically boils down to us wanting to get work done, and if I had to wait for IT to install everything I needed when I needed it we'd be a month behind on the latest project instead of two weeks ahead of schedule.
This comes with the expectation that if I do something stupid like start torrenting porn from my work computers that I will get slapped hard, and that's fair enough.So that seems the way to go: allow devs admin privileges and fire them if they're dumb enough they can't handle that.
This is win-win for dev and IT, unless IT is primarily interested in empire building.
Everything else is just a doomed hack around the fact that you hired bad people.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608528</id>
	<title>Really depends on the developers</title>
	<author>phorm</author>
	<datestamp>1262290140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Whether or not such a system is beneficial really depends on the developers. In the case where the developer is knowledgeable and - even more importantly - respectful of the systems he's entering (and those that maintain then), having a higher-privileged account for devs is great.</p><p>On the other hand, having a situation where devs are making changes to settings (of live systems), or pushing major code updates without a review process and/or using a repository (for rollback purposes) can be terrible.</p><p>It really, <b>really</b> sucks when you're an admin and servers suddenly start going berserk without you knowing WTF is going on, only to find that *somebody* made key changes without checking them in or having them reviewed, especially as you're the one likely to take the heat when it's "the server is screwing up again," when in reality it's "somebody uploaded bad code to the server and/or mangled a bunch of settings."</p><p>So for the devs out there, please be kind to your sysadmins and use a repository. The ability to roll-back will save you headaches as well as your admins. Also, if you're going to make changes to system config, check with the admins first, or at the very least let them know what's going on so if something going *boink* they can trace it down.</p></htmltext>
<tokenext>Whether or not such a system is beneficial really depends on the developers .
In the case where the developer is knowledgeable and - even more importantly - respectful of the systems he 's entering ( and those that maintain then ) , having a higher-privileged account for devs is great.On the other hand , having a situation where devs are making changes to settings ( of live systems ) , or pushing major code updates without a review process and/or using a repository ( for rollback purposes ) can be terrible.It really , really sucks when you 're an admin and servers suddenly start going berserk without you knowing WTF is going on , only to find that * somebody * made key changes without checking them in or having them reviewed , especially as you 're the one likely to take the heat when it 's " the server is screwing up again , " when in reality it 's " somebody uploaded bad code to the server and/or mangled a bunch of settings .
" So for the devs out there , please be kind to your sysadmins and use a repository .
The ability to roll-back will save you headaches as well as your admins .
Also , if you 're going to make changes to system config , check with the admins first , or at the very least let them know what 's going on so if something going * boink * they can trace it down .</tokentext>
<sentencetext>Whether or not such a system is beneficial really depends on the developers.
In the case where the developer is knowledgeable and - even more importantly - respectful of the systems he's entering (and those that maintain then), having a higher-privileged account for devs is great.On the other hand, having a situation where devs are making changes to settings (of live systems), or pushing major code updates without a review process and/or using a repository (for rollback purposes) can be terrible.It really, really sucks when you're an admin and servers suddenly start going berserk without you knowing WTF is going on, only to find that *somebody* made key changes without checking them in or having them reviewed, especially as you're the one likely to take the heat when it's "the server is screwing up again," when in reality it's "somebody uploaded bad code to the server and/or mangled a bunch of settings.
"So for the devs out there, please be kind to your sysadmins and use a repository.
The ability to roll-back will save you headaches as well as your admins.
Also, if you're going to make changes to system config, check with the admins first, or at the very least let them know what's going on so if something going *boink* they can trace it down.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607410</id>
	<title>admin rights define corporate culture</title>
	<author>Anonymous</author>
	<datestamp>1262284980000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>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.</p><p>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.</p></htmltext>
<tokenext>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 .</tokentext>
<sentencetext>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.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606810</id>
	<title>Re:Hell no.</title>
	<author>Nerdfest</author>
	<datestamp>1262282760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Losing a weeks worth of work has very little to do with a rogue rsync script and a whole lot to do with a lack of backups.</htmltext>
<tokenext>Losing a weeks worth of work has very little to do with a rogue rsync script and a whole lot to do with a lack of backups .</tokentext>
<sentencetext>Losing a weeks worth of work has very little to do with a rogue rsync script and a whole lot to do with a lack of backups.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607178</id>
	<title>Yes.</title>
	<author>clintp</author>
	<datestamp>1262284140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Windows Developers need Local Admin access to the machine they write code on, debug, and run their local unit tests.</p><p>When "code goes wrong" not having admin privileges means that some debugging tools are right out.  File and Process monitors, network sniffers, and some of the Visual Studio debugging features just don't work without some elevation.  This situation gets worse under Vista and Windows 7 (which is actually a good thing for Windows).</p><p>I've had this fight at a few jobs and this is a deal-breaker.  Give me Local Admin rights, look the other way while I subvert your system, or accept my resignation.</p><p>Test machines, servers, etc.. no, never.  It's not necessary and (in the long run) subverts sane release procedures.</p></htmltext>
<tokenext>Windows Developers need Local Admin access to the machine they write code on , debug , and run their local unit tests.When " code goes wrong " not having admin privileges means that some debugging tools are right out .
File and Process monitors , network sniffers , and some of the Visual Studio debugging features just do n't work without some elevation .
This situation gets worse under Vista and Windows 7 ( which is actually a good thing for Windows ) .I 've had this fight at a few jobs and this is a deal-breaker .
Give me Local Admin rights , look the other way while I subvert your system , or accept my resignation.Test machines , servers , etc.. no , never .
It 's not necessary and ( in the long run ) subverts sane release procedures .</tokentext>
<sentencetext>Windows Developers need Local Admin access to the machine they write code on, debug, and run their local unit tests.When "code goes wrong" not having admin privileges means that some debugging tools are right out.
File and Process monitors, network sniffers, and some of the Visual Studio debugging features just don't work without some elevation.
This situation gets worse under Vista and Windows 7 (which is actually a good thing for Windows).I've had this fight at a few jobs and this is a deal-breaker.
Give me Local Admin rights, look the other way while I subvert your system, or accept my resignation.Test machines, servers, etc.. no, never.
It's not necessary and (in the long run) subverts sane release procedures.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607296</id>
	<title>as a network admin I say NO!</title>
	<author>Anonymous</author>
	<datestamp>1262284620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If I had a nickle for every time i had to go into a system and fix it because some developer screwed up the server I'd be able to quit and buy an island.  Developers need local admin rights to development systems only.  Not testing, not staging and certainly not production.  But I get both on and off-shore whining every single day.  Sometime management listens and I get to tell them "See!?  I told you so!" when it blows up later.  I thank the Lord for VM daily as it lets me repair the damage developers do to our systems in minutes rather than hours.</htmltext>
<tokenext>If I had a nickle for every time i had to go into a system and fix it because some developer screwed up the server I 'd be able to quit and buy an island .
Developers need local admin rights to development systems only .
Not testing , not staging and certainly not production .
But I get both on and off-shore whining every single day .
Sometime management listens and I get to tell them " See ! ?
I told you so !
" when it blows up later .
I thank the Lord for VM daily as it lets me repair the damage developers do to our systems in minutes rather than hours .</tokentext>
<sentencetext>If I had a nickle for every time i had to go into a system and fix it because some developer screwed up the server I'd be able to quit and buy an island.
Developers need local admin rights to development systems only.
Not testing, not staging and certainly not production.
But I get both on and off-shore whining every single day.
Sometime management listens and I get to tell them "See!?
I told you so!
" when it blows up later.
I thank the Lord for VM daily as it lets me repair the damage developers do to our systems in minutes rather than hours.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606736</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262282580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'd be more worried about accidentally building in dependencies on "hundreds of small programs" that won't be there in the final environment.</p></htmltext>
<tokenext>I 'd be more worried about accidentally building in dependencies on " hundreds of small programs " that wo n't be there in the final environment .</tokentext>
<sentencetext>I'd be more worried about accidentally building in dependencies on "hundreds of small programs" that won't be there in the final environment.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607928</id>
	<title>Yes and No</title>
	<author>spaceyhackerlady</author>
	<datestamp>1262286960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Junior developers: no, unless they had a pressing need for it.

</p><p>Senior developers: yes.

</p><p>There is a responsibility and trust issue here. If you have root/admin access, the general
idea around here has always been "you break it, you fix it".

</p><p>...laura</p></htmltext>
<tokenext>Junior developers : no , unless they had a pressing need for it .
Senior developers : yes .
There is a responsibility and trust issue here .
If you have root/admin access , the general idea around here has always been " you break it , you fix it " .
...laura</tokentext>
<sentencetext>Junior developers: no, unless they had a pressing need for it.
Senior developers: yes.
There is a responsibility and trust issue here.
If you have root/admin access, the general
idea around here has always been "you break it, you fix it".
...laura</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607302</id>
	<title>Re:What?</title>
	<author>Anonymous</author>
	<datestamp>1262284620000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext><p># LS<br>LS-not found</p><p>Yeah, I should have root.</p></htmltext>
<tokenext># LSLS-not foundYeah , I should have root .</tokentext>
<sentencetext># LSLS-not foundYeah, I should have root.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607136</id>
	<title>Programs should not need admin rights to run</title>
	<author>LuxMaker</author>
	<datestamp>1262283960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Programs that do are just sloppy/lazy coding.  Unfortunately that describes most of the code out there.</htmltext>
<tokenext>Programs that do are just sloppy/lazy coding .
Unfortunately that describes most of the code out there .</tokentext>
<sentencetext>Programs that do are just sloppy/lazy coding.
Unfortunately that describes most of the code out there.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607030</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262283540000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>You'd think that would be the case but, in my experience, I've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops.</p></div><p>My last job's developer policy was: you have root access on your machine and you can install whatever you need to help get your work done, but if you mess up your machine, IT's solution is going to be to re-image it. (You won't lose work, because all of your work is checked in, right? And any un-checked-in in-development code can be backed up to the network first.) That way the developers get the freedom they need, and IT doesn't have to try to diagnose incompatibilities between hundreds of little third-party apps.</p></div>
	</htmltext>
<tokenext>You 'd think that would be the case but , in my experience , I 've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops.My last job 's developer policy was : you have root access on your machine and you can install whatever you need to help get your work done , but if you mess up your machine , IT 's solution is going to be to re-image it .
( You wo n't lose work , because all of your work is checked in , right ?
And any un-checked-in in-development code can be backed up to the network first .
) That way the developers get the freedom they need , and IT does n't have to try to diagnose incompatibilities between hundreds of little third-party apps .</tokentext>
<sentencetext>You'd think that would be the case but, in my experience, I've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops.My last job's developer policy was: you have root access on your machine and you can install whatever you need to help get your work done, but if you mess up your machine, IT's solution is going to be to re-image it.
(You won't lose work, because all of your work is checked in, right?
And any un-checked-in in-development code can be backed up to the network first.
) That way the developers get the freedom they need, and IT doesn't have to try to diagnose incompatibilities between hundreds of little third-party apps.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607006</id>
	<title>I work in infosec</title>
	<author>Lord Ender</author>
	<datestamp>1262283480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm in IT security at a large American software company. Some of the guys I work with want to remove admin rights from every system. These are the sort of guys who think the job of IT security is to make paperwork and avoid responsibility at all costs. I'm more of a developer, myself, and I have been able to keep admin rights for developers, but only after much arguing.</p></htmltext>
<tokenext>I 'm in IT security at a large American software company .
Some of the guys I work with want to remove admin rights from every system .
These are the sort of guys who think the job of IT security is to make paperwork and avoid responsibility at all costs .
I 'm more of a developer , myself , and I have been able to keep admin rights for developers , but only after much arguing .</tokentext>
<sentencetext>I'm in IT security at a large American software company.
Some of the guys I work with want to remove admin rights from every system.
These are the sort of guys who think the job of IT security is to make paperwork and avoid responsibility at all costs.
I'm more of a developer, myself, and I have been able to keep admin rights for developers, but only after much arguing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608620</id>
	<title>Anonymous Coward</title>
	<author>Anonymous</author>
	<datestamp>1262290500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I work in a government installation as a software developer and due to government regulations the only way we can install any software or anything is to either put in a request to the IT people to come up and do it, or our supervisors can get special permission to be allowed to install stuff onto the machines of the developers working directly under them.</p></htmltext>
<tokenext>I work in a government installation as a software developer and due to government regulations the only way we can install any software or anything is to either put in a request to the IT people to come up and do it , or our supervisors can get special permission to be allowed to install stuff onto the machines of the developers working directly under them .</tokentext>
<sentencetext>I work in a government installation as a software developer and due to government regulations the only way we can install any software or anything is to either put in a request to the IT people to come up and do it, or our supervisors can get special permission to be allowed to install stuff onto the machines of the developers working directly under them.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30615294</id>
	<title>Re:It's Target.</title>
	<author>Strange Attractor</author>
	<datestamp>1230839040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The Los Alamos National Laboratory addresses the USB menace by encasing the physical ports in epoxy.</p></htmltext>
<tokenext>The Los Alamos National Laboratory addresses the USB menace by encasing the physical ports in epoxy .</tokentext>
<sentencetext>The Los Alamos National Laboratory addresses the USB menace by encasing the physical ports in epoxy.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611492</id>
	<title>VLAN</title>
	<author>ruemere</author>
	<datestamp>1262268060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Separate vlan, virtualized or build with premade images. Contains independent management structure which assumes admin level rights for priviledged users. Remote access via client software (it's pretty easy with virtualized vlan, however for many purposes RDP is sufficient).<br>The vlan is separate from company environment apart from remote access. Hosts located within VLAN can be reimagined at moment's notice. Snapshots can be taken at developer's request.</p><p>It's not that difficult to set up, but you need to do some preparations in order to have fully functional disaster recovery for this vlan, along with snapshot capabilities and consistent monitoring.<br>You may also want to have update procedure to ensure that development environment (and its base images) is not out of touch with real world.<br>Also, you need to cover your bases with regard to licensing and activiation (some O/S requires special provisioning).</p><p>Regards,<br>Ruemere</p></htmltext>
<tokenext>Separate vlan , virtualized or build with premade images .
Contains independent management structure which assumes admin level rights for priviledged users .
Remote access via client software ( it 's pretty easy with virtualized vlan , however for many purposes RDP is sufficient ) .The vlan is separate from company environment apart from remote access .
Hosts located within VLAN can be reimagined at moment 's notice .
Snapshots can be taken at developer 's request.It 's not that difficult to set up , but you need to do some preparations in order to have fully functional disaster recovery for this vlan , along with snapshot capabilities and consistent monitoring.You may also want to have update procedure to ensure that development environment ( and its base images ) is not out of touch with real world.Also , you need to cover your bases with regard to licensing and activiation ( some O/S requires special provisioning ) .Regards,Ruemere</tokentext>
<sentencetext>Separate vlan, virtualized or build with premade images.
Contains independent management structure which assumes admin level rights for priviledged users.
Remote access via client software (it's pretty easy with virtualized vlan, however for many purposes RDP is sufficient).The vlan is separate from company environment apart from remote access.
Hosts located within VLAN can be reimagined at moment's notice.
Snapshots can be taken at developer's request.It's not that difficult to set up, but you need to do some preparations in order to have fully functional disaster recovery for this vlan, along with snapshot capabilities and consistent monitoring.You may also want to have update procedure to ensure that development environment (and its base images) is not out of touch with real world.Also, you need to cover your bases with regard to licensing and activiation (some O/S requires special provisioning).Regards,Ruemere</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607934</id>
	<title>Re:You damn well should</title>
	<author>bwcbwc</author>
	<datestamp>1262287020000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>WTF? It IS a developer's job to worry about system security from an application implementation perspective. It IS a developer's job to understand the operating system well enough to understand the best way to use the operating system's APIs and services. It IS a developer's job to understand what software is on their system, because that software could be interacting with the program they are developing. This knowledge alone makes them more competent to administer and manage their own PC than your typical COE support person. On top of that, they need the access to do their job.</p><p>1) Developers should have local admin rights on their machines<br>2) Apart from automated software updates for standard anti-malware and office tools, the developer should install and maintain the tools required to do their job.<br>3) The developer should not require access to the normal helpdesk support for issues local to their PC.</p><p>On the other hand, as posted below, there is no reason a development machine can't be isolated from the local network, or else the local admin rights can be granted to a local-only user that does not have access to the network. If your company doesn't want to provide developers with two separate computers, limit the network access to a non-admin user. Under *nix, Vista or Win 7 the developer can sudo or invoke the local admin user to install software and perform administrative tasks required for software development.</p><p>Heck you can even force developers to develop inside a virtualized environment in a VHD image, but they'll still need admin rights within the virtualized system. Your testers, even moreso.</p></htmltext>
<tokenext>WTF ?
It IS a developer 's job to worry about system security from an application implementation perspective .
It IS a developer 's job to understand the operating system well enough to understand the best way to use the operating system 's APIs and services .
It IS a developer 's job to understand what software is on their system , because that software could be interacting with the program they are developing .
This knowledge alone makes them more competent to administer and manage their own PC than your typical COE support person .
On top of that , they need the access to do their job.1 ) Developers should have local admin rights on their machines2 ) Apart from automated software updates for standard anti-malware and office tools , the developer should install and maintain the tools required to do their job.3 ) The developer should not require access to the normal helpdesk support for issues local to their PC.On the other hand , as posted below , there is no reason a development machine ca n't be isolated from the local network , or else the local admin rights can be granted to a local-only user that does not have access to the network .
If your company does n't want to provide developers with two separate computers , limit the network access to a non-admin user .
Under * nix , Vista or Win 7 the developer can sudo or invoke the local admin user to install software and perform administrative tasks required for software development.Heck you can even force developers to develop inside a virtualized environment in a VHD image , but they 'll still need admin rights within the virtualized system .
Your testers , even moreso .</tokentext>
<sentencetext>WTF?
It IS a developer's job to worry about system security from an application implementation perspective.
It IS a developer's job to understand the operating system well enough to understand the best way to use the operating system's APIs and services.
It IS a developer's job to understand what software is on their system, because that software could be interacting with the program they are developing.
This knowledge alone makes them more competent to administer and manage their own PC than your typical COE support person.
On top of that, they need the access to do their job.1) Developers should have local admin rights on their machines2) Apart from automated software updates for standard anti-malware and office tools, the developer should install and maintain the tools required to do their job.3) The developer should not require access to the normal helpdesk support for issues local to their PC.On the other hand, as posted below, there is no reason a development machine can't be isolated from the local network, or else the local admin rights can be granted to a local-only user that does not have access to the network.
If your company doesn't want to provide developers with two separate computers, limit the network access to a non-admin user.
Under *nix, Vista or Win 7 the developer can sudo or invoke the local admin user to install software and perform administrative tasks required for software development.Heck you can even force developers to develop inside a virtualized environment in a VHD image, but they'll still need admin rights within the virtualized system.
Your testers, even moreso.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606860</id>
	<title>Re:Yes</title>
	<author>Opportunist</author>
	<datestamp>1262282940000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Pretty much the same experience here. Even the "maximum security" bank auditing company I used to work (and develop) for gave their devs local admin rights. At least after their admins complained that they don't get anything accomplished because they had to do something for the devs every other minute.</p><p>Instead, we got a tight rule set put in place that pretty much said that, while we do have local admin, any kind of change in the software setup of the machine (i.e. new software or new security rules, etc) required a written permission. And behold, it worked.</p><p>You needn't cast every rule in silicium. It's one of the very, very few situations where a legal system can actually do something for security.</p></htmltext>
<tokenext>Pretty much the same experience here .
Even the " maximum security " bank auditing company I used to work ( and develop ) for gave their devs local admin rights .
At least after their admins complained that they do n't get anything accomplished because they had to do something for the devs every other minute.Instead , we got a tight rule set put in place that pretty much said that , while we do have local admin , any kind of change in the software setup of the machine ( i.e .
new software or new security rules , etc ) required a written permission .
And behold , it worked.You need n't cast every rule in silicium .
It 's one of the very , very few situations where a legal system can actually do something for security .</tokentext>
<sentencetext>Pretty much the same experience here.
Even the "maximum security" bank auditing company I used to work (and develop) for gave their devs local admin rights.
At least after their admins complained that they don't get anything accomplished because they had to do something for the devs every other minute.Instead, we got a tight rule set put in place that pretty much said that, while we do have local admin, any kind of change in the software setup of the machine (i.e.
new software or new security rules, etc) required a written permission.
And behold, it worked.You needn't cast every rule in silicium.
It's one of the very, very few situations where a legal system can actually do something for security.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612148</id>
	<title>Run As...</title>
	<author>Anonymous</author>
	<datestamp>1262277060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Where I work, we do development under Windows XP.  Our Active Directory accounts don't have local administrator access, but we know what the password for the local Administrator account is, so when we need to install some software, we can just "Run As...".</p><p>There are various tricks that make this work better, like running Windows Explorer as Administrator ("explorer<nobr> <wbr></nobr>/separate"), using Tweak UI to make the toolbar of Windows Explorer appear different when run from the Administrator account, knowing how to open various Control Panel applets via their<nobr> <wbr></nobr>.cpl files (e.g. "appwiz.cpl" gives you the Add/Remove Programs, if I recall correctly).</p><p>I find this much nicer than logging out and logging in using the Administrator account because I don't want to have to close all my editors, my email, etc.  It seems to be a good solution 99\% of the time.</p></htmltext>
<tokenext>Where I work , we do development under Windows XP .
Our Active Directory accounts do n't have local administrator access , but we know what the password for the local Administrator account is , so when we need to install some software , we can just " Run As... " .There are various tricks that make this work better , like running Windows Explorer as Administrator ( " explorer /separate " ) , using Tweak UI to make the toolbar of Windows Explorer appear different when run from the Administrator account , knowing how to open various Control Panel applets via their .cpl files ( e.g .
" appwiz.cpl " gives you the Add/Remove Programs , if I recall correctly ) .I find this much nicer than logging out and logging in using the Administrator account because I do n't want to have to close all my editors , my email , etc .
It seems to be a good solution 99 \ % of the time .</tokentext>
<sentencetext>Where I work, we do development under Windows XP.
Our Active Directory accounts don't have local administrator access, but we know what the password for the local Administrator account is, so when we need to install some software, we can just "Run As...".There are various tricks that make this work better, like running Windows Explorer as Administrator ("explorer /separate"), using Tweak UI to make the toolbar of Windows Explorer appear different when run from the Administrator account, knowing how to open various Control Panel applets via their .cpl files (e.g.
"appwiz.cpl" gives you the Add/Remove Programs, if I recall correctly).I find this much nicer than logging out and logging in using the Administrator account because I don't want to have to close all my editors, my email, etc.
It seems to be a good solution 99\% of the time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612490</id>
	<title>Best practice</title>
	<author>Edgester</author>
	<datestamp>1262283000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Developers should have admin rights, but programs should be able to install without admin rights unless there is a darn good reason to have admin rights. Maybe if developers were forced to install without admin rights, then software installation on locked-down corporate desktops wouldn't be so painful.</p></htmltext>
<tokenext>Developers should have admin rights , but programs should be able to install without admin rights unless there is a darn good reason to have admin rights .
Maybe if developers were forced to install without admin rights , then software installation on locked-down corporate desktops would n't be so painful .</tokentext>
<sentencetext>Developers should have admin rights, but programs should be able to install without admin rights unless there is a darn good reason to have admin rights.
Maybe if developers were forced to install without admin rights, then software installation on locked-down corporate desktops wouldn't be so painful.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608370</id>
	<title>Pretty sure i know which company you work for.</title>
	<author>Shados</author>
	<datestamp>1262289180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Pretty sure i know which company you're working for, as there's one such large non-IT corporation with a very large IT department that did exactly that in the roughly same timeframe with the same exception at the same time.... while I'm sure there's more than one, the wording used in the summary makes me think I'm right.</p><p>Anyway, most debugging tools and stuff will work without administrator right, the main problem is when comes the time to test out new software, like betas, and things not approved to be used by the developers, or when writing an app that needs full control on the machine for integration (rare that there's a REAL business case, but it happens).</p><p>In that case, said company will still make an exception, you just need your manager to say pretty please to the powers that be. I still have the exception, and will keep it, because we convinced the upper people that we couldn't do the job without it, along with ability to bypass the proxy and filters, the exe download blocker, and so on. Plus you can request virtual machines to be built for you.</p><p>Thats how anal companies work anyway. All other large companies i worked for still gave a lot of control to the devs on their boxes, give or take a few things, such as deciding whats the primary development environment and main development OS, but thats about it, and many are completly free for all, as long as you stay within the realm of legality.</p></htmltext>
<tokenext>Pretty sure i know which company you 're working for , as there 's one such large non-IT corporation with a very large IT department that did exactly that in the roughly same timeframe with the same exception at the same time.... while I 'm sure there 's more than one , the wording used in the summary makes me think I 'm right.Anyway , most debugging tools and stuff will work without administrator right , the main problem is when comes the time to test out new software , like betas , and things not approved to be used by the developers , or when writing an app that needs full control on the machine for integration ( rare that there 's a REAL business case , but it happens ) .In that case , said company will still make an exception , you just need your manager to say pretty please to the powers that be .
I still have the exception , and will keep it , because we convinced the upper people that we could n't do the job without it , along with ability to bypass the proxy and filters , the exe download blocker , and so on .
Plus you can request virtual machines to be built for you.Thats how anal companies work anyway .
All other large companies i worked for still gave a lot of control to the devs on their boxes , give or take a few things , such as deciding whats the primary development environment and main development OS , but thats about it , and many are completly free for all , as long as you stay within the realm of legality .</tokentext>
<sentencetext>Pretty sure i know which company you're working for, as there's one such large non-IT corporation with a very large IT department that did exactly that in the roughly same timeframe with the same exception at the same time.... while I'm sure there's more than one, the wording used in the summary makes me think I'm right.Anyway, most debugging tools and stuff will work without administrator right, the main problem is when comes the time to test out new software, like betas, and things not approved to be used by the developers, or when writing an app that needs full control on the machine for integration (rare that there's a REAL business case, but it happens).In that case, said company will still make an exception, you just need your manager to say pretty please to the powers that be.
I still have the exception, and will keep it, because we convinced the upper people that we couldn't do the job without it, along with ability to bypass the proxy and filters, the exe download blocker, and so on.
Plus you can request virtual machines to be built for you.Thats how anal companies work anyway.
All other large companies i worked for still gave a lot of control to the devs on their boxes, give or take a few things, such as deciding whats the primary development environment and main development OS, but thats about it, and many are completly free for all, as long as you stay within the realm of legality.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609144</id>
	<title>Devs only need some 'admin' rights</title>
	<author>don\_bear\_wilkinson</author>
	<datestamp>1262250240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My former employer suffered more than one very serious work-stoppage (lost scores of manhours) over the whole LAN due to problems caused by a developer whose Windows Domain account (and primary login on the local PC) has Administrator rights on the Domain and (thus) on the local machine.  (This is due to Devs *not* being experts in networking, security, application and service mgmt, windows domain policies, etc.  If they were, they would not have needed a Windows SA, right?)  It was only after this fiasco that the mgmt folks acceded to my plan. </p><ul>
<li>Put Dev boxes on their own network segment in their own Windows domain.</li><li>Use GPOs for various security/software settings, including Windows Firewall rules.</li><li>Give them VMs on local machines for development\local testing. (Cloning/Point-in-time images are AWESOME!) </li><li>Give them VMs on the network for shared work/testing.</li><li>Give them two accounts on their XP machines, one with elevated privileges. (Their 'admin' account) </li><li>Have them use "RunAs" and their 'admin account' to elevate privs for tasks, like installing software and changing system settings</li></ul><p>It was a lot of work to set up, and a lot of pain the first couple of weeks to train/handhold the Devs, but it started to really work. Oh, it should be mentioned we has somewhat unusually high security requirements due to being in the financial sector and handling customer credit/debit card data, etc.  But, really, most of this was designed and implemented to actually improve work processes and uptime.  And it did.</p></htmltext>
<tokenext>My former employer suffered more than one very serious work-stoppage ( lost scores of manhours ) over the whole LAN due to problems caused by a developer whose Windows Domain account ( and primary login on the local PC ) has Administrator rights on the Domain and ( thus ) on the local machine .
( This is due to Devs * not * being experts in networking , security , application and service mgmt , windows domain policies , etc .
If they were , they would not have needed a Windows SA , right ?
) It was only after this fiasco that the mgmt folks acceded to my plan .
Put Dev boxes on their own network segment in their own Windows domain.Use GPOs for various security/software settings , including Windows Firewall rules.Give them VMs on local machines for development \ local testing .
( Cloning/Point-in-time images are AWESOME !
) Give them VMs on the network for shared work/testing.Give them two accounts on their XP machines , one with elevated privileges .
( Their 'admin ' account ) Have them use " RunAs " and their 'admin account ' to elevate privs for tasks , like installing software and changing system settingsIt was a lot of work to set up , and a lot of pain the first couple of weeks to train/handhold the Devs , but it started to really work .
Oh , it should be mentioned we has somewhat unusually high security requirements due to being in the financial sector and handling customer credit/debit card data , etc .
But , really , most of this was designed and implemented to actually improve work processes and uptime .
And it did .</tokentext>
<sentencetext>My former employer suffered more than one very serious work-stoppage (lost scores of manhours) over the whole LAN due to problems caused by a developer whose Windows Domain account (and primary login on the local PC) has Administrator rights on the Domain and (thus) on the local machine.
(This is due to Devs *not* being experts in networking, security, application and service mgmt, windows domain policies, etc.
If they were, they would not have needed a Windows SA, right?
)  It was only after this fiasco that the mgmt folks acceded to my plan.
Put Dev boxes on their own network segment in their own Windows domain.Use GPOs for various security/software settings, including Windows Firewall rules.Give them VMs on local machines for development\local testing.
(Cloning/Point-in-time images are AWESOME!
) Give them VMs on the network for shared work/testing.Give them two accounts on their XP machines, one with elevated privileges.
(Their 'admin' account) Have them use "RunAs" and their 'admin account' to elevate privs for tasks, like installing software and changing system settingsIt was a lot of work to set up, and a lot of pain the first couple of weeks to train/handhold the Devs, but it started to really work.
Oh, it should be mentioned we has somewhat unusually high security requirements due to being in the financial sector and handling customer credit/debit card data, etc.
But, really, most of this was designed and implemented to actually improve work processes and uptime.
And it did.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608594</id>
	<title>Re:In some companies</title>
	<author>afabbro</author>
	<datestamp>1262290440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Sarbanes Oxley <b>separation of roles requirements</b> have been interpreted to mean that developers should not also be admins.</p></div><p>Sorry. there is no such thing in paragraph 404.</p></div>
	</htmltext>
<tokenext>Sarbanes Oxley separation of roles requirements have been interpreted to mean that developers should not also be admins.Sorry .
there is no such thing in paragraph 404 .</tokentext>
<sentencetext>Sarbanes Oxley separation of roles requirements have been interpreted to mean that developers should not also be admins.Sorry.
there is no such thing in paragraph 404.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606708</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607402</id>
	<title>Seperate Dev/Prod Networks</title>
	<author>Anonymous</author>
	<datestamp>1262284980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It is absolutely necessary for most developers to have admin rights to download and install software.  The problem is that there is also a potential for downloading/installing Trojans.  The appropriate solution is to have seperate Development and Production networks.</p><p>That being said...  I work for a corporation that does NOT have seperate Dev/Prod networks.  Our solution has been to apply for temporary admin access the first time we install some new software (for example, VS2010 beta) and then have the developer create a local admin account to use as a backdoor once the temporary admin access has expired.  Not the best solution...  but better than waiting for 2 weeks every time you want to install a patch.</p></htmltext>
<tokenext>It is absolutely necessary for most developers to have admin rights to download and install software .
The problem is that there is also a potential for downloading/installing Trojans .
The appropriate solution is to have seperate Development and Production networks.That being said... I work for a corporation that does NOT have seperate Dev/Prod networks .
Our solution has been to apply for temporary admin access the first time we install some new software ( for example , VS2010 beta ) and then have the developer create a local admin account to use as a backdoor once the temporary admin access has expired .
Not the best solution... but better than waiting for 2 weeks every time you want to install a patch .</tokentext>
<sentencetext>It is absolutely necessary for most developers to have admin rights to download and install software.
The problem is that there is also a potential for downloading/installing Trojans.
The appropriate solution is to have seperate Development and Production networks.That being said...  I work for a corporation that does NOT have seperate Dev/Prod networks.
Our solution has been to apply for temporary admin access the first time we install some new software (for example, VS2010 beta) and then have the developer create a local admin account to use as a backdoor once the temporary admin access has expired.
Not the best solution...  but better than waiting for 2 weeks every time you want to install a patch.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606752</id>
	<title>Re:Hell no.</title>
	<author>Delkster</author>
	<datestamp>1262282580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>They'd go in and reboot servers - servers with 100 people logged in and working on stuff - because they thought their database was out of memory. Not tell anyone, nothing. One time they enabled an rsync script that pretty much overwrote a week's worth of work. And who got blamed? The sysadmin, for not making it impossible for that script to work anymore.</p></div><p>That's not exactly about <b>local</b> admin rights. I understood the original question was about admin rights to the developers' workstations, not servers. That's a whole different matter.</p><p>Personally, I'd hate not being able to use the tools I need on my local machine to complete the job just because someone's being a control freak. (Not referring to you but to those who would deny developers local admin privileges to their workstations.)</p></div>
	</htmltext>
<tokenext>They 'd go in and reboot servers - servers with 100 people logged in and working on stuff - because they thought their database was out of memory .
Not tell anyone , nothing .
One time they enabled an rsync script that pretty much overwrote a week 's worth of work .
And who got blamed ?
The sysadmin , for not making it impossible for that script to work anymore.That 's not exactly about local admin rights .
I understood the original question was about admin rights to the developers ' workstations , not servers .
That 's a whole different matter.Personally , I 'd hate not being able to use the tools I need on my local machine to complete the job just because someone 's being a control freak .
( Not referring to you but to those who would deny developers local admin privileges to their workstations .
)</tokentext>
<sentencetext>They'd go in and reboot servers - servers with 100 people logged in and working on stuff - because they thought their database was out of memory.
Not tell anyone, nothing.
One time they enabled an rsync script that pretty much overwrote a week's worth of work.
And who got blamed?
The sysadmin, for not making it impossible for that script to work anymore.That's not exactly about local admin rights.
I understood the original question was about admin rights to the developers' workstations, not servers.
That's a whole different matter.Personally, I'd hate not being able to use the tools I need on my local machine to complete the job just because someone's being a control freak.
(Not referring to you but to those who would deny developers local admin privileges to their workstations.
)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606894</id>
	<title>Another example of how r-tarded management is now</title>
	<author>Kungpaoshizi</author>
	<datestamp>1262283120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The international company I'm at, was talking about taking it further than this, and removing admin rights from the IT staff...

Yes, I believe managment degrees need to be a Masters or PHD ABOVE what they know, not a degree to be in charge of what they don't know.

Right now it's like "goto college for 2 years and qualify to be the General of our armies"

Another pitfall of a truly ignorant society.</htmltext>
<tokenext>The international company I 'm at , was talking about taking it further than this , and removing admin rights from the IT staff.. . Yes , I believe managment degrees need to be a Masters or PHD ABOVE what they know , not a degree to be in charge of what they do n't know .
Right now it 's like " goto college for 2 years and qualify to be the General of our armies " Another pitfall of a truly ignorant society .</tokentext>
<sentencetext>The international company I'm at, was talking about taking it further than this, and removing admin rights from the IT staff...

Yes, I believe managment degrees need to be a Masters or PHD ABOVE what they know, not a degree to be in charge of what they don't know.
Right now it's like "goto college for 2 years and qualify to be the General of our armies"

Another pitfall of a truly ignorant society.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606844</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262282940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And following that argument, is any person who can't maintain his own automobile, toilet plumbing, the airplane he flies on, or his cell phone also incompetent?</p><p>There's only so much time. I need to focus on what gives me the most return. That's not system administration.</p></htmltext>
<tokenext>And following that argument , is any person who ca n't maintain his own automobile , toilet plumbing , the airplane he flies on , or his cell phone also incompetent ? There 's only so much time .
I need to focus on what gives me the most return .
That 's not system administration .</tokentext>
<sentencetext>And following that argument, is any person who can't maintain his own automobile, toilet plumbing, the airplane he flies on, or his cell phone also incompetent?There's only so much time.
I need to focus on what gives me the most return.
That's not system administration.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609502</id>
	<title>Security?</title>
	<author>visionbeyond</author>
	<datestamp>1262252340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Well the first problem I see is that your on a Windows platform, so security is the last thing you'll be able to enforce.  LOL  Windows also has a horrible user and group permissions system, so relying on that will also include many headaches and issue in your future... continually.  Can't really help you in Windows world beyond showing you a hack to get around pretty much anything - thus why I say not to even try.

I've worked at companies that freely gave out root access to developers, and others that guarded access like a trade secret to their special formula.  Ultimately I don't believe developers really need root access, but that is dependent upon having a system admin that is doing their job correctly, and also definitely helps to use a code revision repository (SVN or CVS).  I've also found that just building a local environment when restriction are in place, allows me to do anything I need, as master of my own domain - okay, crappy outdated workstation.  But in either scenario, administrative or root access isn't necessary.  Is it handy to have?  Certainly, and has helped in the development process, but necessary, no.  I also believe though that if you don't have developers that are capable and that you trust, then you should reconsider who works for you, and as a result should feel comfortable allowing root access.  Any developer with ethics, even if parting on the worst of circumstances, isn't going to sabotage the system or server.  The tech world after all isn't really that big of a world, and everything always turns full circle sooner or later.  At least that's my two duckets worth.

-Davey</htmltext>
<tokenext>Well the first problem I see is that your on a Windows platform , so security is the last thing you 'll be able to enforce .
LOL Windows also has a horrible user and group permissions system , so relying on that will also include many headaches and issue in your future... continually. Ca n't really help you in Windows world beyond showing you a hack to get around pretty much anything - thus why I say not to even try .
I 've worked at companies that freely gave out root access to developers , and others that guarded access like a trade secret to their special formula .
Ultimately I do n't believe developers really need root access , but that is dependent upon having a system admin that is doing their job correctly , and also definitely helps to use a code revision repository ( SVN or CVS ) .
I 've also found that just building a local environment when restriction are in place , allows me to do anything I need , as master of my own domain - okay , crappy outdated workstation .
But in either scenario , administrative or root access is n't necessary .
Is it handy to have ?
Certainly , and has helped in the development process , but necessary , no .
I also believe though that if you do n't have developers that are capable and that you trust , then you should reconsider who works for you , and as a result should feel comfortable allowing root access .
Any developer with ethics , even if parting on the worst of circumstances , is n't going to sabotage the system or server .
The tech world after all is n't really that big of a world , and everything always turns full circle sooner or later .
At least that 's my two duckets worth .
-Davey</tokentext>
<sentencetext>Well the first problem I see is that your on a Windows platform, so security is the last thing you'll be able to enforce.
LOL  Windows also has a horrible user and group permissions system, so relying on that will also include many headaches and issue in your future... continually.  Can't really help you in Windows world beyond showing you a hack to get around pretty much anything - thus why I say not to even try.
I've worked at companies that freely gave out root access to developers, and others that guarded access like a trade secret to their special formula.
Ultimately I don't believe developers really need root access, but that is dependent upon having a system admin that is doing their job correctly, and also definitely helps to use a code revision repository (SVN or CVS).
I've also found that just building a local environment when restriction are in place, allows me to do anything I need, as master of my own domain - okay, crappy outdated workstation.
But in either scenario, administrative or root access isn't necessary.
Is it handy to have?
Certainly, and has helped in the development process, but necessary, no.
I also believe though that if you don't have developers that are capable and that you trust, then you should reconsider who works for you, and as a result should feel comfortable allowing root access.
Any developer with ethics, even if parting on the worst of circumstances, isn't going to sabotage the system or server.
The tech world after all isn't really that big of a world, and everything always turns full circle sooner or later.
At least that's my two duckets worth.
-Davey</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607220</id>
	<title>admin rights on local machine and dev VM</title>
	<author>Anonymous</author>
	<datestamp>1262284320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>They have admin rights on their desktops and they have a virtual machine on a vmware server that they can do whatever with.</p><p>There are a couple development servers that they just have shell access to, or are power users or backup operators to let them start and stop services.</p><p>At one point the director of development asked me to give a developer root access to a server. The dev didn't understand how the mounts were supposed to be setup so he went through and "fixed" the configuration files without commenting anything out or leaving any hints. I had backups of the conf files of course but he messed it up on a friday afternoon.</p></htmltext>
<tokenext>They have admin rights on their desktops and they have a virtual machine on a vmware server that they can do whatever with.There are a couple development servers that they just have shell access to , or are power users or backup operators to let them start and stop services.At one point the director of development asked me to give a developer root access to a server .
The dev did n't understand how the mounts were supposed to be setup so he went through and " fixed " the configuration files without commenting anything out or leaving any hints .
I had backups of the conf files of course but he messed it up on a friday afternoon .</tokentext>
<sentencetext>They have admin rights on their desktops and they have a virtual machine on a vmware server that they can do whatever with.There are a couple development servers that they just have shell access to, or are power users or backup operators to let them start and stop services.At one point the director of development asked me to give a developer root access to a server.
The dev didn't understand how the mounts were supposed to be setup so he went through and "fixed" the configuration files without commenting anything out or leaving any hints.
I had backups of the conf files of course but he messed it up on a friday afternoon.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608192</id>
	<title>Yes</title>
	<author>Anonymous</author>
	<datestamp>1262288280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Officially, because my predecessor was too lazy to figure out a workaround for a particular limitation made relevant by the continued use of a decade-old IDE. A workaround it took me 45 minutes to find using ProcMon and Regedit. The real problem is that the developers (all but one of which are not trained developers, but are actually {unrelated discipline} students "trained" willy-nilly by a {unrelated discipline} professor that taught himself {old language} in the mid '80s), are intently focused on results, not process, and are too "busy" to have to remember that if they need to do something administrative, they need to Run As.. and provide admin creds. The whole concept of "admin" is curiously confusing to them; my boss constantly refers to "full admin" as if there were some hidden hierarchy. I constantly remind him that there is just admin and non-admin, and that when I do something particularly magical, it's not because I've granted myself "more" admin rights then I've granted him. It's just that I recognize the difference, and when to use one or the other. After four years, I think he's starting to get it.</p></htmltext>
<tokenext>Officially , because my predecessor was too lazy to figure out a workaround for a particular limitation made relevant by the continued use of a decade-old IDE .
A workaround it took me 45 minutes to find using ProcMon and Regedit .
The real problem is that the developers ( all but one of which are not trained developers , but are actually { unrelated discipline } students " trained " willy-nilly by a { unrelated discipline } professor that taught himself { old language } in the mid '80s ) , are intently focused on results , not process , and are too " busy " to have to remember that if they need to do something administrative , they need to Run As.. and provide admin creds .
The whole concept of " admin " is curiously confusing to them ; my boss constantly refers to " full admin " as if there were some hidden hierarchy .
I constantly remind him that there is just admin and non-admin , and that when I do something particularly magical , it 's not because I 've granted myself " more " admin rights then I 've granted him .
It 's just that I recognize the difference , and when to use one or the other .
After four years , I think he 's starting to get it .</tokentext>
<sentencetext>Officially, because my predecessor was too lazy to figure out a workaround for a particular limitation made relevant by the continued use of a decade-old IDE.
A workaround it took me 45 minutes to find using ProcMon and Regedit.
The real problem is that the developers (all but one of which are not trained developers, but are actually {unrelated discipline} students "trained" willy-nilly by a {unrelated discipline} professor that taught himself {old language} in the mid '80s), are intently focused on results, not process, and are too "busy" to have to remember that if they need to do something administrative, they need to Run As.. and provide admin creds.
The whole concept of "admin" is curiously confusing to them; my boss constantly refers to "full admin" as if there were some hidden hierarchy.
I constantly remind him that there is just admin and non-admin, and that when I do something particularly magical, it's not because I've granted myself "more" admin rights then I've granted him.
It's just that I recognize the difference, and when to use one or the other.
After four years, I think he's starting to get it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608062</id>
	<title>Looked into removing...</title>
	<author>rwarrenr</author>
	<datestamp>1262287620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There are programs where you can at least audit and try to remove some functions (Beyond Trust, etc), but really it comes down to too much work. We force strong anti-virus instead and use Websense to try to capture anything coming in from the web. Their build scripts temporarily disable real-time scan to speed up the builds.

Engineers don't have a clue about protecting their systems, they may be smarter than the average Joe, but that doesn't give them an advantage when dealing with system security/updates/etc. In most cases they are worse because they are lazy about updates (yet cry when you force it on them), and they seem to think that everyone in the world is a straight shooter - "oh, we don't need passwords" or "we don't need to limit access". Give me a break...</htmltext>
<tokenext>There are programs where you can at least audit and try to remove some functions ( Beyond Trust , etc ) , but really it comes down to too much work .
We force strong anti-virus instead and use Websense to try to capture anything coming in from the web .
Their build scripts temporarily disable real-time scan to speed up the builds .
Engineers do n't have a clue about protecting their systems , they may be smarter than the average Joe , but that does n't give them an advantage when dealing with system security/updates/etc .
In most cases they are worse because they are lazy about updates ( yet cry when you force it on them ) , and they seem to think that everyone in the world is a straight shooter - " oh , we do n't need passwords " or " we do n't need to limit access " .
Give me a break.. .</tokentext>
<sentencetext>There are programs where you can at least audit and try to remove some functions (Beyond Trust, etc), but really it comes down to too much work.
We force strong anti-virus instead and use Websense to try to capture anything coming in from the web.
Their build scripts temporarily disable real-time scan to speed up the builds.
Engineers don't have a clue about protecting their systems, they may be smarter than the average Joe, but that doesn't give them an advantage when dealing with system security/updates/etc.
In most cases they are worse because they are lazy about updates (yet cry when you force it on them), and they seem to think that everyone in the world is a straight shooter - "oh, we don't need passwords" or "we don't need to limit access".
Give me a break...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607936</id>
	<title>Re:Yeah.</title>
	<author>serialband</author>
	<datestamp>1262287020000</datestamp>
	<modclass>Troll</modclass>
	<modscore>1</modscore>
	<htmltext><p>The fact that Windows systems require programmers to need admin rights is utterly broken.  It's the cause for so many non multiuser capable programs still being made.</p></htmltext>
<tokenext>The fact that Windows systems require programmers to need admin rights is utterly broken .
It 's the cause for so many non multiuser capable programs still being made .</tokentext>
<sentencetext>The fact that Windows systems require programmers to need admin rights is utterly broken.
It's the cause for so many non multiuser capable programs still being made.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606634</id>
	<title>All users had it for a time...</title>
	<author>Anonymous</author>
	<datestamp>1262282220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>When I first started working where I work now, virtually every use had local admin rights and there was no web filtering.  I brought these issues to a quick halt but I have no idea how my boss (at the time it would be a 1 man IT shop, just him) managed to hold it all together.</p></htmltext>
<tokenext>When I first started working where I work now , virtually every use had local admin rights and there was no web filtering .
I brought these issues to a quick halt but I have no idea how my boss ( at the time it would be a 1 man IT shop , just him ) managed to hold it all together .</tokentext>
<sentencetext>When I first started working where I work now, virtually every use had local admin rights and there was no web filtering.
I brought these issues to a quick halt but I have no idea how my boss (at the time it would be a 1 man IT shop, just him) managed to hold it all together.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612812</id>
	<title>Re:Yeah.</title>
	<author>ShakaUVM</author>
	<datestamp>1230840240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>At my last 2 jobs developers have had security exceptions for local admin rights. The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.</i></p><p>Wait, what?</p><p>At my last office job (~100 people in the company), the developers WERE the system admins.</p><p>It's all "computers", right?<nobr> <wbr></nobr>:p</p><p>Actually, I lie. We ended up getting so fed up with being taken off task to fix peoples email that we actually hired a full time IT guy, but he was so intimidated by us that I couldn't imagine him trying to lock us out of our computers.</p></htmltext>
<tokenext>At my last 2 jobs developers have had security exceptions for local admin rights .
The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.Wait , what ? At my last office job ( ~ 100 people in the company ) , the developers WERE the system admins.It 's all " computers " , right ?
: pActually , I lie .
We ended up getting so fed up with being taken off task to fix peoples email that we actually hired a full time IT guy , but he was so intimidated by us that I could n't imagine him trying to lock us out of our computers .</tokentext>
<sentencetext>At my last 2 jobs developers have had security exceptions for local admin rights.
The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.Wait, what?At my last office job (~100 people in the company), the developers WERE the system admins.It's all "computers", right?
:pActually, I lie.
We ended up getting so fed up with being taken off task to fix peoples email that we actually hired a full time IT guy, but he was so intimidated by us that I couldn't imagine him trying to lock us out of our computers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607806</id>
	<title>It depends</title>
	<author>s\_p\_oneil</author>
	<datestamp>1262286480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It really depends on what kind of development they're doing. Speaking as an Enterprise Windows developer who has had to install clean OS's regularly (hurray for virtualization) and test products our with ActiveDirectory integration, I can say that sometimes development groups need their own domain controller to play with. In that case, give them their own domain and consider putting it on a network segment separate from the rest of the organization. Set up the routes and a domain trust relationship that allows them to get corporate email and access shared folders and printers, and you're all set.</p><p>Even if developers don't need their own sandbox to play in and don't know how to administer a domain controller, it may be a good idea to set it up that way for security reasons. Developers tend to be lax about in-house security, and it helps keep systems on the rest of the network from being able to access development files they have no business accessing. If they do any network testing, it also may keep them from killing your firewalls, servers, Internet bandwidth, etc. (that's one reason my group got moved to our own network segment with its own Internet connection<nobr> <wbr></nobr>;-) If they do any security testing, they also may install malware on purpose from time to time (that's another reason my group got moved to our own network segment<nobr> <wbr></nobr>;-).</p></htmltext>
<tokenext>It really depends on what kind of development they 're doing .
Speaking as an Enterprise Windows developer who has had to install clean OS 's regularly ( hurray for virtualization ) and test products our with ActiveDirectory integration , I can say that sometimes development groups need their own domain controller to play with .
In that case , give them their own domain and consider putting it on a network segment separate from the rest of the organization .
Set up the routes and a domain trust relationship that allows them to get corporate email and access shared folders and printers , and you 're all set.Even if developers do n't need their own sandbox to play in and do n't know how to administer a domain controller , it may be a good idea to set it up that way for security reasons .
Developers tend to be lax about in-house security , and it helps keep systems on the rest of the network from being able to access development files they have no business accessing .
If they do any network testing , it also may keep them from killing your firewalls , servers , Internet bandwidth , etc .
( that 's one reason my group got moved to our own network segment with its own Internet connection ; - ) If they do any security testing , they also may install malware on purpose from time to time ( that 's another reason my group got moved to our own network segment ; - ) .</tokentext>
<sentencetext>It really depends on what kind of development they're doing.
Speaking as an Enterprise Windows developer who has had to install clean OS's regularly (hurray for virtualization) and test products our with ActiveDirectory integration, I can say that sometimes development groups need their own domain controller to play with.
In that case, give them their own domain and consider putting it on a network segment separate from the rest of the organization.
Set up the routes and a domain trust relationship that allows them to get corporate email and access shared folders and printers, and you're all set.Even if developers don't need their own sandbox to play in and don't know how to administer a domain controller, it may be a good idea to set it up that way for security reasons.
Developers tend to be lax about in-house security, and it helps keep systems on the rest of the network from being able to access development files they have no business accessing.
If they do any network testing, it also may keep them from killing your firewalls, servers, Internet bandwidth, etc.
(that's one reason my group got moved to our own network segment with its own Internet connection ;-) If they do any security testing, they also may install malware on purpose from time to time (that's another reason my group got moved to our own network segment ;-).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610314</id>
	<title>Re:What it REALLY comes down to</title>
	<author>asifyoucare</author>
	<datestamp>1262257320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Hear hear,</p><p>And the "Windows Way" means you can not move or restore applications by just copying a directory.  No, you must "install".</p><p>This is partly why Windows admins have only one application per (virtual) box, and Microsoft rubs their hands knowing they sell an OS for each application instance.</p></htmltext>
<tokenext>Hear hear,And the " Windows Way " means you can not move or restore applications by just copying a directory .
No , you must " install " .This is partly why Windows admins have only one application per ( virtual ) box , and Microsoft rubs their hands knowing they sell an OS for each application instance .</tokentext>
<sentencetext>Hear hear,And the "Windows Way" means you can not move or restore applications by just copying a directory.
No, you must "install".This is partly why Windows admins have only one application per (virtual) box, and Microsoft rubs their hands knowing they sell an OS for each application instance.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611166</id>
	<title>Re:You damn well should</title>
	<author>nametaken</author>
	<datestamp>1262264940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Absolutely the case in my experience as well.  Our developers were helpless with basic system administration.  Our admins couldn't code very well.  It put me in a unique position as an IT guy gone programmer.</p></htmltext>
<tokenext>Absolutely the case in my experience as well .
Our developers were helpless with basic system administration .
Our admins could n't code very well .
It put me in a unique position as an IT guy gone programmer .</tokentext>
<sentencetext>Absolutely the case in my experience as well.
Our developers were helpless with basic system administration.
Our admins couldn't code very well.
It put me in a unique position as an IT guy gone programmer.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609268</id>
	<title>Re:Yes</title>
	<author>wwphx</author>
	<datestamp>1262250840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>NO THEY SHOULD NOT.<br> <br>

The place where you really see the problem is when people like me have to install a commercial program, it doesn't work, and their tech says "give the user local admin rights."  NO.  It seems like half the applications that I have to install or upgrade want the running user to have local admin rights.  We tried setting up specific directory permissions and all sorts of other non-standard crap, it wasn't pleasant.  I don't remember what the final outcome was, it was more than six months ago.<br> <br>

I've long been out of the development game (I'm a DBA), and then it was a Windows environment and you didn't need local admin.  Maybe it's different in a *nix environment.  But Windows developers having admin rights while developing causes hell when deploying such code.  Giving Joe/Jane Doe average user local admin rights to their machine on a network that you're trying to keep reasonably secure because they have to run a program as a corporate standard is not a good thing.<br> <br>

I have two network accounts: domain admin and a non-admin account.  I'm always logged in to my local machine as non-admin, I don't remember the last time I signed on to my local machine as admin.  When I need to do administrative work on one of my database servers locally, I remote over using my admin account then log off.  I know developers have to do things differently, I guess I should be thankful that I can do most of my job without needing admin access to machines as long as my non-admin account is set as database owner on my servers.<br> <br>

There has to be a better way.  I can understand that developers need special debuggers.  I appreciate that.  But they cause absolute hell with network security.</htmltext>
<tokenext>NO THEY SHOULD NOT .
The place where you really see the problem is when people like me have to install a commercial program , it does n't work , and their tech says " give the user local admin rights .
" NO .
It seems like half the applications that I have to install or upgrade want the running user to have local admin rights .
We tried setting up specific directory permissions and all sorts of other non-standard crap , it was n't pleasant .
I do n't remember what the final outcome was , it was more than six months ago .
I 've long been out of the development game ( I 'm a DBA ) , and then it was a Windows environment and you did n't need local admin .
Maybe it 's different in a * nix environment .
But Windows developers having admin rights while developing causes hell when deploying such code .
Giving Joe/Jane Doe average user local admin rights to their machine on a network that you 're trying to keep reasonably secure because they have to run a program as a corporate standard is not a good thing .
I have two network accounts : domain admin and a non-admin account .
I 'm always logged in to my local machine as non-admin , I do n't remember the last time I signed on to my local machine as admin .
When I need to do administrative work on one of my database servers locally , I remote over using my admin account then log off .
I know developers have to do things differently , I guess I should be thankful that I can do most of my job without needing admin access to machines as long as my non-admin account is set as database owner on my servers .
There has to be a better way .
I can understand that developers need special debuggers .
I appreciate that .
But they cause absolute hell with network security .</tokentext>
<sentencetext>NO THEY SHOULD NOT.
The place where you really see the problem is when people like me have to install a commercial program, it doesn't work, and their tech says "give the user local admin rights.
"  NO.
It seems like half the applications that I have to install or upgrade want the running user to have local admin rights.
We tried setting up specific directory permissions and all sorts of other non-standard crap, it wasn't pleasant.
I don't remember what the final outcome was, it was more than six months ago.
I've long been out of the development game (I'm a DBA), and then it was a Windows environment and you didn't need local admin.
Maybe it's different in a *nix environment.
But Windows developers having admin rights while developing causes hell when deploying such code.
Giving Joe/Jane Doe average user local admin rights to their machine on a network that you're trying to keep reasonably secure because they have to run a program as a corporate standard is not a good thing.
I have two network accounts: domain admin and a non-admin account.
I'm always logged in to my local machine as non-admin, I don't remember the last time I signed on to my local machine as admin.
When I need to do administrative work on one of my database servers locally, I remote over using my admin account then log off.
I know developers have to do things differently, I guess I should be thankful that I can do most of my job without needing admin access to machines as long as my non-admin account is set as database owner on my servers.
There has to be a better way.
I can understand that developers need special debuggers.
I appreciate that.
But they cause absolute hell with network security.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609218</id>
	<title>Yes and no</title>
	<author>Anonymous</author>
	<datestamp>1262250600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I work for an international company in the corporate department, and the way we do it is:</p><p>You have a corporate desktop meant to do corporate work, which means your Office suite is on it, you use the standard AV and other tools (standard image), and you're allowed to install whatever virtualization package your team is licensed for on it.</p><p>This seems to work pretty well for everyone!</p></htmltext>
<tokenext>I work for an international company in the corporate department , and the way we do it is : You have a corporate desktop meant to do corporate work , which means your Office suite is on it , you use the standard AV and other tools ( standard image ) , and you 're allowed to install whatever virtualization package your team is licensed for on it.This seems to work pretty well for everyone !</tokentext>
<sentencetext>I work for an international company in the corporate department, and the way we do it is:You have a corporate desktop meant to do corporate work, which means your Office suite is on it, you use the standard AV and other tools (standard image), and you're allowed to install whatever virtualization package your team is licensed for on it.This seems to work pretty well for everyone!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30690784</id>
	<title>Re:Depressing landscape.</title>
	<author>haruharaharu</author>
	<datestamp>1231348080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>-I need to install X,Y or Z application, library, whatever.: No, you don't. Refer to the list of approved software and use that, if some new software is needed then follow the procedure to get it included into the list. The procedure to get hold of new software is too long? Fix the procedure, you installing random stuff from the net is not the fix.</p></div><p>You want the app to be finished in 6 months or a year? Yeah, I thought so.</p><p><div class="quote"><p>- I need a program that requires elevated privileges!: use a different program, the one you are using now does not care about the safety of your IT infrastructure, if this is not possible pick the damn phone and ask the software provider to fix the program, if they don't fix it expose them t public ridicule. Again, you don't need privileged access.</p></div><p>Yeah, adobe will issue me an emergency patch because I asked nicely. Where do you work, anyway? All your points read like "I'm right. When I'm wrong, restate the problem so I'm right."</p></div>
	</htmltext>
<tokenext>-I need to install X,Y or Z application , library , whatever .
: No , you do n't .
Refer to the list of approved software and use that , if some new software is needed then follow the procedure to get it included into the list .
The procedure to get hold of new software is too long ?
Fix the procedure , you installing random stuff from the net is not the fix.You want the app to be finished in 6 months or a year ?
Yeah , I thought so.- I need a program that requires elevated privileges !
: use a different program , the one you are using now does not care about the safety of your IT infrastructure , if this is not possible pick the damn phone and ask the software provider to fix the program , if they do n't fix it expose them t public ridicule .
Again , you do n't need privileged access.Yeah , adobe will issue me an emergency patch because I asked nicely .
Where do you work , anyway ?
All your points read like " I 'm right .
When I 'm wrong , restate the problem so I 'm right .
"</tokentext>
<sentencetext>-I need to install X,Y or Z application, library, whatever.
: No, you don't.
Refer to the list of approved software and use that, if some new software is needed then follow the procedure to get it included into the list.
The procedure to get hold of new software is too long?
Fix the procedure, you installing random stuff from the net is not the fix.You want the app to be finished in 6 months or a year?
Yeah, I thought so.- I need a program that requires elevated privileges!
: use a different program, the one you are using now does not care about the safety of your IT infrastructure, if this is not possible pick the damn phone and ask the software provider to fix the program, if they don't fix it expose them t public ridicule.
Again, you don't need privileged access.Yeah, adobe will issue me an emergency patch because I asked nicely.
Where do you work, anyway?
All your points read like "I'm right.
When I'm wrong, restate the problem so I'm right.
"
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618654</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606576</id>
	<title>Ubiquitous in the mega crops</title>
	<author>node159</author>
	<datestamp>1262282040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Having worked in various mega corps, admin privileges for developers seems to be ubiquitous. It seems ironic that most development tools do not adhere to best practices in this regard.</p><p>But I'm not complaining, its nice to have full control of the machine, even if it always comes with the caveat 'you break it, the only support you get is a re-imaging'. At my current company this standoffish behavior has resulted in the developers running whatever OS they desire, much to the chagrin of infrastructure<nobr> <wbr></nobr>:).</p></htmltext>
<tokenext>Having worked in various mega corps , admin privileges for developers seems to be ubiquitous .
It seems ironic that most development tools do not adhere to best practices in this regard.But I 'm not complaining , its nice to have full control of the machine , even if it always comes with the caveat 'you break it , the only support you get is a re-imaging' .
At my current company this standoffish behavior has resulted in the developers running whatever OS they desire , much to the chagrin of infrastructure : ) .</tokentext>
<sentencetext>Having worked in various mega corps, admin privileges for developers seems to be ubiquitous.
It seems ironic that most development tools do not adhere to best practices in this regard.But I'm not complaining, its nice to have full control of the machine, even if it always comes with the caveat 'you break it, the only support you get is a re-imaging'.
At my current company this standoffish behavior has resulted in the developers running whatever OS they desire, much to the chagrin of infrastructure :).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607186</id>
	<title>Gotta have it ... eventually</title>
	<author>Thad Zurich</author>
	<datestamp>1262284200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Even some large military networks provision developers with secondary accounts that have local admin rights. The machines on which those accounts are valid get walled off into a "community of interest" that is isolated from the production domain. You can't effectively debug on Windows without those rights. However, it's very important to know where those rights are required and not, and developers should do as much as possible without invoking them. The assumption of excessive privileges has always been a big hassle with Windows. Microsoft started trying to kill that off with XPSP2 and Vista, and they are still trying. Speaking of which, they used to have a white paper (NT4 based) about security in a development environment, does anyone still have a copy?</htmltext>
<tokenext>Even some large military networks provision developers with secondary accounts that have local admin rights .
The machines on which those accounts are valid get walled off into a " community of interest " that is isolated from the production domain .
You ca n't effectively debug on Windows without those rights .
However , it 's very important to know where those rights are required and not , and developers should do as much as possible without invoking them .
The assumption of excessive privileges has always been a big hassle with Windows .
Microsoft started trying to kill that off with XPSP2 and Vista , and they are still trying .
Speaking of which , they used to have a white paper ( NT4 based ) about security in a development environment , does anyone still have a copy ?</tokentext>
<sentencetext>Even some large military networks provision developers with secondary accounts that have local admin rights.
The machines on which those accounts are valid get walled off into a "community of interest" that is isolated from the production domain.
You can't effectively debug on Windows without those rights.
However, it's very important to know where those rights are required and not, and developers should do as much as possible without invoking them.
The assumption of excessive privileges has always been a big hassle with Windows.
Microsoft started trying to kill that off with XPSP2 and Vista, and they are still trying.
Speaking of which, they used to have a white paper (NT4 based) about security in a development environment, does anyone still have a copy?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609948</id>
	<title>Yes</title>
	<author>nurb432</author>
	<datestamp>1262254920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If you don't trust them with the rights, they shouldn't be working for you.</p></htmltext>
<tokenext>If you do n't trust them with the rights , they should n't be working for you .</tokentext>
<sentencetext>If you don't trust them with the rights, they shouldn't be working for you.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608054</id>
	<title>Re:What?</title>
	<author>Anonymous</author>
	<datestamp>1262287560000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext>It is becasue you are gay. My suggestion is to buy a Mac as soon as possible, and try to look smug and self-righteous all of the time.</htmltext>
<tokenext>It is becasue you are gay .
My suggestion is to buy a Mac as soon as possible , and try to look smug and self-righteous all of the time .</tokentext>
<sentencetext>It is becasue you are gay.
My suggestion is to buy a Mac as soon as possible, and try to look smug and self-righteous all of the time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606848</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606760</id>
	<title>Re:You damn well should</title>
	<author>Kyril</author>
	<datestamp>1262282640000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>I would disagree -- the more years I spend programming the less I remember about system administration.  I can do basic setup tasks, but fiddling with Active Directories and stuff like that is beyond what I care to learn and has been for what, a decade now?</p><p>At an Ancient Telecom company most folks don't have admin rights (and shouldn't) but there is an exception process developers follow, and otherwise the Company-approved packages don't need admin rights to install, plus the help desk has powers.</p></htmltext>
<tokenext>I would disagree -- the more years I spend programming the less I remember about system administration .
I can do basic setup tasks , but fiddling with Active Directories and stuff like that is beyond what I care to learn and has been for what , a decade now ? At an Ancient Telecom company most folks do n't have admin rights ( and should n't ) but there is an exception process developers follow , and otherwise the Company-approved packages do n't need admin rights to install , plus the help desk has powers .</tokentext>
<sentencetext>I would disagree -- the more years I spend programming the less I remember about system administration.
I can do basic setup tasks, but fiddling with Active Directories and stuff like that is beyond what I care to learn and has been for what, a decade now?At an Ancient Telecom company most folks don't have admin rights (and shouldn't) but there is an exception process developers follow, and otherwise the Company-approved packages don't need admin rights to install, plus the help desk has powers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606982</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262283420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>@Parent</p><p>You've clearly never written production code at a Fortune 500.</p></htmltext>
<tokenext>@ ParentYou 've clearly never written production code at a Fortune 500 .</tokentext>
<sentencetext>@ParentYou've clearly never written production code at a Fortune 500.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606710</id>
	<title>Under no circumstances</title>
	<author>Anonymous</author>
	<datestamp>1262282520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Under no circumstances should any developer in any organization today have corporate production administrative rights.  Its simply not needed.  As a developer and a security specialist, there's a lot of ways to get by this.  First, you can create an isolated domain in a development environment, or even create a production domain that they can have admin rights to - other than the corporate production domain.  Adding developers to the production administrative group is dangerous and all too often leads to problems.  Just a few weeks ago at a friends company, a developer went into MS DNS and wanted to change a DNS entry, and ended up deleting several entries that brought down the Exchange server.  At that same company a few months back, another developer wanted to add a static entry in DHCP but accidently deleted a scope that brought down a production site.  There's just too much freedom for error.</htmltext>
<tokenext>Under no circumstances should any developer in any organization today have corporate production administrative rights .
Its simply not needed .
As a developer and a security specialist , there 's a lot of ways to get by this .
First , you can create an isolated domain in a development environment , or even create a production domain that they can have admin rights to - other than the corporate production domain .
Adding developers to the production administrative group is dangerous and all too often leads to problems .
Just a few weeks ago at a friends company , a developer went into MS DNS and wanted to change a DNS entry , and ended up deleting several entries that brought down the Exchange server .
At that same company a few months back , another developer wanted to add a static entry in DHCP but accidently deleted a scope that brought down a production site .
There 's just too much freedom for error .</tokentext>
<sentencetext>Under no circumstances should any developer in any organization today have corporate production administrative rights.
Its simply not needed.
As a developer and a security specialist, there's a lot of ways to get by this.
First, you can create an isolated domain in a development environment, or even create a production domain that they can have admin rights to - other than the corporate production domain.
Adding developers to the production administrative group is dangerous and all too often leads to problems.
Just a few weeks ago at a friends company, a developer went into MS DNS and wanted to change a DNS entry, and ended up deleting several entries that brought down the Exchange server.
At that same company a few months back, another developer wanted to add a static entry in DHCP but accidently deleted a scope that brought down a production site.
There's just too much freedom for error.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608702</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262290980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>I've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops. Didn't understand basic networking principles or basic OS functions and dos and don'ts.</i></p><p>This is clearly some strange new meaning of "extremely talented" of which most of us were not previously aware.  Perhaps they're good dancers.</p></htmltext>
<tokenext>I 've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops .
Did n't understand basic networking principles or basic OS functions and dos and don'ts.This is clearly some strange new meaning of " extremely talented " of which most of us were not previously aware .
Perhaps they 're good dancers .</tokentext>
<sentencetext>I've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops.
Didn't understand basic networking principles or basic OS functions and dos and don'ts.This is clearly some strange new meaning of "extremely talented" of which most of us were not previously aware.
Perhaps they're good dancers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607104</id>
	<title>How to do it right</title>
	<author>fluffernutter</author>
	<datestamp>1262283780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Any shop that knows what they are doing would do it this way:

- dev environment for devs to monkey around with; seperate network from prod
- UAT (and possibly INT) environment for dry-runs of deployments also on a separate network, also used to document said deployments
- PROD, accessible only by a handful of staff who follow documentation created above</htmltext>
<tokenext>Any shop that knows what they are doing would do it this way : - dev environment for devs to monkey around with ; seperate network from prod - UAT ( and possibly INT ) environment for dry-runs of deployments also on a separate network , also used to document said deployments - PROD , accessible only by a handful of staff who follow documentation created above</tokentext>
<sentencetext>Any shop that knows what they are doing would do it this way:

- dev environment for devs to monkey around with; seperate network from prod
- UAT (and possibly INT) environment for dry-runs of deployments also on a separate network, also used to document said deployments
- PROD, accessible only by a handful of staff who follow documentation created above</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838</id>
	<title>It's Target.</title>
	<author>girlintraining</author>
	<datestamp>1262282880000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p>I'm going to end some mystery here: I am guessing the "very large corporation" is Target, a massive US-retail chain. I only know because I used to work on support there, and they tried this crap with trying to delete local admin rights for <i>everyone</i> so nobody could administer their own boxes. Even Microsoft told them this was a bad idea, and you can't remove local admin from a system because it's fundamental to the security model. It was so painful watching the daily e-mails come back from amongst IT and then once every week or two see a management e-mail so loaded in buzzwords I printed it off and hung it on my cube wall next to a train wreck picture and left my coworkers to do the math. They went ahead and tried it anyway -- I've watched whole stores, departments, and even divisions just drop off the network because they rammed some security change through, didn't test it thoroughly -- and now some application is seriously wedged. The days and days of downtime are due to convincing infosecurity that there's a problem and then fixing it -- because they're autonomous to the rest of support and report directly to the board. Which means, no matter how bad they f*** up, it's your fault, not theirs, because they each think they're Agent Smith, saving the corporation from the disorder of computational devices. *face palm*</p><p>I feel your pain. I do.</p><p>The sad part is, this isn't just <i>that</i> corporation: It's most Fortune 500 companies. Management is so far removed from the IT process that the only input they get is from external sources: Trade magazines and consultants. This, of course, ends in tears. These are the kind of people that read that pen drives are the source of all evil on their network and if you just delete the USB mass storage driver from the system, your problem is solved. I don't know which trade magazine published this idea -- but when I find him, I'm going to end him. Again, not a problem specific to that company -- it's representative of what everyone finds in the field today.</p><p>Since corporations with this level of brain damage inevitably give developers underpowered systems, <b>here's your solution</b>: Cannibalize another system, make sure you've got a few extra GB of RAM, and install an virtual machine, then do all your development within that environment. Site licensing is a wonderful thing. Just don't ever join it to the domain and shuffle your test files in and out via a temporary share. Even better, find a standalone system and use that for development so corporate can have their ridiculous security on one system, and you have an unencumbered development platform to develop for and transfer completed work back to the main system.</p><p>It's stupid, and you should never have had to do it. But then, what about working for a large corporation is ever simple? So many people trying to ensure they're a crucial part of the business, so few who actually give a damn about it...</p></htmltext>
<tokenext>I 'm going to end some mystery here : I am guessing the " very large corporation " is Target , a massive US-retail chain .
I only know because I used to work on support there , and they tried this crap with trying to delete local admin rights for everyone so nobody could administer their own boxes .
Even Microsoft told them this was a bad idea , and you ca n't remove local admin from a system because it 's fundamental to the security model .
It was so painful watching the daily e-mails come back from amongst IT and then once every week or two see a management e-mail so loaded in buzzwords I printed it off and hung it on my cube wall next to a train wreck picture and left my coworkers to do the math .
They went ahead and tried it anyway -- I 've watched whole stores , departments , and even divisions just drop off the network because they rammed some security change through , did n't test it thoroughly -- and now some application is seriously wedged .
The days and days of downtime are due to convincing infosecurity that there 's a problem and then fixing it -- because they 're autonomous to the rest of support and report directly to the board .
Which means , no matter how bad they f * * * up , it 's your fault , not theirs , because they each think they 're Agent Smith , saving the corporation from the disorder of computational devices .
* face palm * I feel your pain .
I do.The sad part is , this is n't just that corporation : It 's most Fortune 500 companies .
Management is so far removed from the IT process that the only input they get is from external sources : Trade magazines and consultants .
This , of course , ends in tears .
These are the kind of people that read that pen drives are the source of all evil on their network and if you just delete the USB mass storage driver from the system , your problem is solved .
I do n't know which trade magazine published this idea -- but when I find him , I 'm going to end him .
Again , not a problem specific to that company -- it 's representative of what everyone finds in the field today.Since corporations with this level of brain damage inevitably give developers underpowered systems , here 's your solution : Cannibalize another system , make sure you 've got a few extra GB of RAM , and install an virtual machine , then do all your development within that environment .
Site licensing is a wonderful thing .
Just do n't ever join it to the domain and shuffle your test files in and out via a temporary share .
Even better , find a standalone system and use that for development so corporate can have their ridiculous security on one system , and you have an unencumbered development platform to develop for and transfer completed work back to the main system.It 's stupid , and you should never have had to do it .
But then , what about working for a large corporation is ever simple ?
So many people trying to ensure they 're a crucial part of the business , so few who actually give a damn about it.. .</tokentext>
<sentencetext>I'm going to end some mystery here: I am guessing the "very large corporation" is Target, a massive US-retail chain.
I only know because I used to work on support there, and they tried this crap with trying to delete local admin rights for everyone so nobody could administer their own boxes.
Even Microsoft told them this was a bad idea, and you can't remove local admin from a system because it's fundamental to the security model.
It was so painful watching the daily e-mails come back from amongst IT and then once every week or two see a management e-mail so loaded in buzzwords I printed it off and hung it on my cube wall next to a train wreck picture and left my coworkers to do the math.
They went ahead and tried it anyway -- I've watched whole stores, departments, and even divisions just drop off the network because they rammed some security change through, didn't test it thoroughly -- and now some application is seriously wedged.
The days and days of downtime are due to convincing infosecurity that there's a problem and then fixing it -- because they're autonomous to the rest of support and report directly to the board.
Which means, no matter how bad they f*** up, it's your fault, not theirs, because they each think they're Agent Smith, saving the corporation from the disorder of computational devices.
*face palm*I feel your pain.
I do.The sad part is, this isn't just that corporation: It's most Fortune 500 companies.
Management is so far removed from the IT process that the only input they get is from external sources: Trade magazines and consultants.
This, of course, ends in tears.
These are the kind of people that read that pen drives are the source of all evil on their network and if you just delete the USB mass storage driver from the system, your problem is solved.
I don't know which trade magazine published this idea -- but when I find him, I'm going to end him.
Again, not a problem specific to that company -- it's representative of what everyone finds in the field today.Since corporations with this level of brain damage inevitably give developers underpowered systems, here's your solution: Cannibalize another system, make sure you've got a few extra GB of RAM, and install an virtual machine, then do all your development within that environment.
Site licensing is a wonderful thing.
Just don't ever join it to the domain and shuffle your test files in and out via a temporary share.
Even better, find a standalone system and use that for development so corporate can have their ridiculous security on one system, and you have an unencumbered development platform to develop for and transfer completed work back to the main system.It's stupid, and you should never have had to do it.
But then, what about working for a large corporation is ever simple?
So many people trying to ensure they're a crucial part of the business, so few who actually give a damn about it...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438</id>
	<title>Yes</title>
	<author>Anonymous</author>
	<datestamp>1262281620000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Yes. Both at the company I work for and the regional bank I developed for a couple years ago. It is impossible, IMO, to do many functions without these privileges.</p></htmltext>
<tokenext>Yes .
Both at the company I work for and the regional bank I developed for a couple years ago .
It is impossible , IMO , to do many functions without these privileges .</tokentext>
<sentencetext>Yes.
Both at the company I work for and the regional bank I developed for a couple years ago.
It is impossible, IMO, to do many functions without these privileges.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608070</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262287680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Here I will fix that for you.</p><p>Must be nice, being able to pick and choose what jobs you take. Unfortunately, "some" people here don't have that luxury.</p><p>Employability is directly related to skill set and background if you have neither then yes<br>you do not currently have the luxury of choosing who you work for. If you have both it is<br>still dirt simple choose who you work for.</p></htmltext>
<tokenext>Here I will fix that for you.Must be nice , being able to pick and choose what jobs you take .
Unfortunately , " some " people here do n't have that luxury.Employability is directly related to skill set and background if you have neither then yesyou do not currently have the luxury of choosing who you work for .
If you have both it isstill dirt simple choose who you work for .</tokentext>
<sentencetext>Here I will fix that for you.Must be nice, being able to pick and choose what jobs you take.
Unfortunately, "some" people here don't have that luxury.Employability is directly related to skill set and background if you have neither then yesyou do not currently have the luxury of choosing who you work for.
If you have both it isstill dirt simple choose who you work for.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606896</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607386</id>
	<title>Yes... well almost...</title>
	<author>giltnerj0</author>
	<datestamp>1262284920000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Developers have near admin privileges.  Everything is locked down via GPO, and developers are in our own OU.<br>We are admins on Development and Production servers so that can we handle application deployment, maintenance etc.</p><p>There are still some functions that we don't have access to, things like the virus scan, HIPS, Desktop validator, Smart card interface etc.</p><p>We can install/uninstall applications etc, but there is a finite list of software we can use, and if we get caught with unapproved software on a computer on the network, we will have a lot of explaining to do... to people with sidearms.</p></htmltext>
<tokenext>Developers have near admin privileges .
Everything is locked down via GPO , and developers are in our own OU.We are admins on Development and Production servers so that can we handle application deployment , maintenance etc.There are still some functions that we do n't have access to , things like the virus scan , HIPS , Desktop validator , Smart card interface etc.We can install/uninstall applications etc , but there is a finite list of software we can use , and if we get caught with unapproved software on a computer on the network , we will have a lot of explaining to do... to people with sidearms .</tokentext>
<sentencetext>Developers have near admin privileges.
Everything is locked down via GPO, and developers are in our own OU.We are admins on Development and Production servers so that can we handle application deployment, maintenance etc.There are still some functions that we don't have access to, things like the virus scan, HIPS, Desktop validator, Smart card interface etc.We can install/uninstall applications etc, but there is a finite list of software we can use, and if we get caught with unapproved software on a computer on the network, we will have a lot of explaining to do... to people with sidearms.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30641012</id>
	<title>answer the questions</title>
	<author>Anonymous</author>
	<datestamp>1231086060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It all depends on the questions:<br>-How can the developers do the most work without being limited<br>-How can I reduce the workload of the system admins for those guys</p><p>For some kind of development, it can be done with normal limitations.<br>But other kind cannot. And you'll have to find a suitable solution to work with.<br>For example: separate machines, virtual machines, give the local admin rights on their regular machines, etc.</p><p>There will always be a conflict between the needs of a developer and a system admin and most of the times they do not take the other needs into account.<br>As a webdeveloper I had a webserver running local on the usual port 8080. I was not amused when the admins installed a new virusscanner with build-in server that uses the same port. I had to have the privileges to change one of those servers. Without local admin rights I would have been unable to do it and that would mean I am unable to do my work (= useless spending of money). I don't think management would ever want to see that!<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>It all depends on the questions : -How can the developers do the most work without being limited-How can I reduce the workload of the system admins for those guysFor some kind of development , it can be done with normal limitations.But other kind can not .
And you 'll have to find a suitable solution to work with.For example : separate machines , virtual machines , give the local admin rights on their regular machines , etc.There will always be a conflict between the needs of a developer and a system admin and most of the times they do not take the other needs into account.As a webdeveloper I had a webserver running local on the usual port 8080 .
I was not amused when the admins installed a new virusscanner with build-in server that uses the same port .
I had to have the privileges to change one of those servers .
Without local admin rights I would have been unable to do it and that would mean I am unable to do my work ( = useless spending of money ) .
I do n't think management would ever want to see that !
: )</tokentext>
<sentencetext>It all depends on the questions:-How can the developers do the most work without being limited-How can I reduce the workload of the system admins for those guysFor some kind of development, it can be done with normal limitations.But other kind cannot.
And you'll have to find a suitable solution to work with.For example: separate machines, virtual machines, give the local admin rights on their regular machines, etc.There will always be a conflict between the needs of a developer and a system admin and most of the times they do not take the other needs into account.As a webdeveloper I had a webserver running local on the usual port 8080.
I was not amused when the admins installed a new virusscanner with build-in server that uses the same port.
I had to have the privileges to change one of those servers.
Without local admin rights I would have been unable to do it and that would mean I am unable to do my work (= useless spending of money).
I don't think management would ever want to see that!
:)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609652</id>
	<title>We have a separate development image</title>
	<author>Quila</author>
	<datestamp>1262253240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The image looks like the production image, but with the various tools installed and a somewhat more liberal group policy.</p><p>And they are admins. They have access to the development network too.</p><p>But those systems are shut out of the production network.</p></htmltext>
<tokenext>The image looks like the production image , but with the various tools installed and a somewhat more liberal group policy.And they are admins .
They have access to the development network too.But those systems are shut out of the production network .</tokentext>
<sentencetext>The image looks like the production image, but with the various tools installed and a somewhat more liberal group policy.And they are admins.
They have access to the development network too.But those systems are shut out of the production network.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606888</id>
	<title>Dev verse Production</title>
	<author>TechHSV</author>
	<datestamp>1262283060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Give them admin access to machines on the dev network, but not on the production side.  Development shouldn't happen on the production network.  Many developers don't realize that when on the production network they can take down the entire network by downloading some crazy app or better yet screwing up code that floods the network.  Setup a lab network behind a firewall, then allow ssh traffic and maybe a few other ports to allow controlled remote access.  If the developers screw something up, it just takes down their lab network.</htmltext>
<tokenext>Give them admin access to machines on the dev network , but not on the production side .
Development should n't happen on the production network .
Many developers do n't realize that when on the production network they can take down the entire network by downloading some crazy app or better yet screwing up code that floods the network .
Setup a lab network behind a firewall , then allow ssh traffic and maybe a few other ports to allow controlled remote access .
If the developers screw something up , it just takes down their lab network .</tokentext>
<sentencetext>Give them admin access to machines on the dev network, but not on the production side.
Development shouldn't happen on the production network.
Many developers don't realize that when on the production network they can take down the entire network by downloading some crazy app or better yet screwing up code that floods the network.
Setup a lab network behind a firewall, then allow ssh traffic and maybe a few other ports to allow controlled remote access.
If the developers screw something up, it just takes down their lab network.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607344</id>
	<title>absolutely</title>
	<author>Anonymous</author>
	<datestamp>1262284740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>it's interesting.  in my area (gov't programming), we have Windows boxes for our documentation and issues software, but we develop everything on Linux (aside from our website, which is<nobr> <wbr></nobr>.NET based).</p><p>if you really, really need it, they will give you Admin rights on your Windows box, but I don't know of anyone who has ever needed it.  I spend 1\% of my time on my Windows box.  i can see the issues from Linux, and have exported the documents i need so that I can view them in Linux.  i use my Windows box once a week to fill out a particular time card (i have 3 of them).</p><p>we all have sudo rights on our Linux box, and Admin rights on Windows are not given out at all.  our home directories in Linux are nfs mounted, as well as a few other locations.  if it is software that is needed by everyone, it is pushed to a nfs mounted partition, that way everyone can use it (a lot of our libraries work this way).</p><p>our software does a complete reinstall of the OS (RH), has to update cron and do a lot of other things.  sudo is absolutely necessary to test stuff out.</p><p>IMO, admin rights can be given to developers.  if i need a package installed, and our IT guy(s) are out, then i don't need to wait 2 days to get moving on something.</p></htmltext>
<tokenext>it 's interesting .
in my area ( gov't programming ) , we have Windows boxes for our documentation and issues software , but we develop everything on Linux ( aside from our website , which is .NET based ) .if you really , really need it , they will give you Admin rights on your Windows box , but I do n't know of anyone who has ever needed it .
I spend 1 \ % of my time on my Windows box .
i can see the issues from Linux , and have exported the documents i need so that I can view them in Linux .
i use my Windows box once a week to fill out a particular time card ( i have 3 of them ) .we all have sudo rights on our Linux box , and Admin rights on Windows are not given out at all .
our home directories in Linux are nfs mounted , as well as a few other locations .
if it is software that is needed by everyone , it is pushed to a nfs mounted partition , that way everyone can use it ( a lot of our libraries work this way ) .our software does a complete reinstall of the OS ( RH ) , has to update cron and do a lot of other things .
sudo is absolutely necessary to test stuff out.IMO , admin rights can be given to developers .
if i need a package installed , and our IT guy ( s ) are out , then i do n't need to wait 2 days to get moving on something .</tokentext>
<sentencetext>it's interesting.
in my area (gov't programming), we have Windows boxes for our documentation and issues software, but we develop everything on Linux (aside from our website, which is .NET based).if you really, really need it, they will give you Admin rights on your Windows box, but I don't know of anyone who has ever needed it.
I spend 1\% of my time on my Windows box.
i can see the issues from Linux, and have exported the documents i need so that I can view them in Linux.
i use my Windows box once a week to fill out a particular time card (i have 3 of them).we all have sudo rights on our Linux box, and Admin rights on Windows are not given out at all.
our home directories in Linux are nfs mounted, as well as a few other locations.
if it is software that is needed by everyone, it is pushed to a nfs mounted partition, that way everyone can use it (a lot of our libraries work this way).our software does a complete reinstall of the OS (RH), has to update cron and do a lot of other things.
sudo is absolutely necessary to test stuff out.IMO, admin rights can be given to developers.
if i need a package installed, and our IT guy(s) are out, then i don't need to wait 2 days to get moving on something.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607214</id>
	<title>Worked in Both Worlds...</title>
	<author>digitalloving</author>
	<datestamp>1262284320000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext>One of the mid-sized corporations I worked for did not allow admin access to developers on production machines.  The reasons for this has been outlined by some other posts already, but mainly because the server team was responsible for the servers.  It was also part of a strategy to meet Sarbanes Oxley requirements for servers touching financial data.
<br> <br>
In order for it to work smoothly, an exact development copy of the production server is required.  This is pretty resource intensive in both servers and admins.  Second, the deployment of new applications needs to be communicated to the administrators.  This took some time depending on the difficulty of the change.  Finally, any issues that popped up in the production server that wasn't seen in the development server required "emergency admin access".  It usually meant that a server admin and developer sitting at the same terminal working out an issue.
<br> <br>
This method, while not being efficient, forced a couple of best practices.  First, because development had to be done a replica of the server, the code was already tested on a server that was identical(as possible) to the original server.  Second, because the deployment had to be done by server admins, the developer had to document all the steps required to deploy their application.  It let the admins know the changes being made, allowed auditors to see the change, and forced the developer to make an application that was reasonably easy to deploy.
<br> <br>
Overall, I think it lead to a pretty clean production environment with much fewer "surprises".  However, any code you want to put into production takes twice as long and cost twice as much (approximately).  To truly evaluate if it monetarily makes sense, the cost of a failure/fraud in a production environment needs to be calculated.  I don't think it is always better one way or another.  Although, as a developer it sure was a pain in the ass.</htmltext>
<tokenext>One of the mid-sized corporations I worked for did not allow admin access to developers on production machines .
The reasons for this has been outlined by some other posts already , but mainly because the server team was responsible for the servers .
It was also part of a strategy to meet Sarbanes Oxley requirements for servers touching financial data .
In order for it to work smoothly , an exact development copy of the production server is required .
This is pretty resource intensive in both servers and admins .
Second , the deployment of new applications needs to be communicated to the administrators .
This took some time depending on the difficulty of the change .
Finally , any issues that popped up in the production server that was n't seen in the development server required " emergency admin access " .
It usually meant that a server admin and developer sitting at the same terminal working out an issue .
This method , while not being efficient , forced a couple of best practices .
First , because development had to be done a replica of the server , the code was already tested on a server that was identical ( as possible ) to the original server .
Second , because the deployment had to be done by server admins , the developer had to document all the steps required to deploy their application .
It let the admins know the changes being made , allowed auditors to see the change , and forced the developer to make an application that was reasonably easy to deploy .
Overall , I think it lead to a pretty clean production environment with much fewer " surprises " .
However , any code you want to put into production takes twice as long and cost twice as much ( approximately ) .
To truly evaluate if it monetarily makes sense , the cost of a failure/fraud in a production environment needs to be calculated .
I do n't think it is always better one way or another .
Although , as a developer it sure was a pain in the ass .</tokentext>
<sentencetext>One of the mid-sized corporations I worked for did not allow admin access to developers on production machines.
The reasons for this has been outlined by some other posts already, but mainly because the server team was responsible for the servers.
It was also part of a strategy to meet Sarbanes Oxley requirements for servers touching financial data.
In order for it to work smoothly, an exact development copy of the production server is required.
This is pretty resource intensive in both servers and admins.
Second, the deployment of new applications needs to be communicated to the administrators.
This took some time depending on the difficulty of the change.
Finally, any issues that popped up in the production server that wasn't seen in the development server required "emergency admin access".
It usually meant that a server admin and developer sitting at the same terminal working out an issue.
This method, while not being efficient, forced a couple of best practices.
First, because development had to be done a replica of the server, the code was already tested on a server that was identical(as possible) to the original server.
Second, because the deployment had to be done by server admins, the developer had to document all the steps required to deploy their application.
It let the admins know the changes being made, allowed auditors to see the change, and forced the developer to make an application that was reasonably easy to deploy.
Overall, I think it lead to a pretty clean production environment with much fewer "surprises".
However, any code you want to put into production takes twice as long and cost twice as much (approximately).
To truly evaluate if it monetarily makes sense, the cost of a failure/fraud in a production environment needs to be calculated.
I don't think it is always better one way or another.
Although, as a developer it sure was a pain in the ass.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30636850</id>
	<title>Re:What it REALLY comes down to</title>
	<author>Anonymous</author>
	<datestamp>1230997080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I do have to agree with Anonymous, I miss the old DOS days when every application was a single folder. Installation and removal was nothing more than simply copying a folder or deleting it. There was no need for installers or package managers as everything was plain in sight.</p><p>The entire add/remove tool in Windows is nothing more than rundll32 executing some stub that reads a couple keys from the registry. Its so outdated that the disk space field is 32-bits and thus overflows when you pass 4GB. Just this little tool alone will never justify the registry in my opinion.</p><p>In the last decade I observed registry usage by tons and tons of applications. Generally they do so for two reasons:<br>1) To try and hide settings for users.<br>2) Because the app is entirely made out of COM(+) and has a gazillion GUIDs it needs to offload to even function at all. (Microsoft products such as Office and Visual Studio are notorious for this)</p><p>Even worse, I've seen loads of software creating keys in the registry. Followed by de-authorizing the administrator account from touching those keys. Its really lovely when some uninstaller fails and you have to manually re-authorize yourself to delete their mess.</p><p>The Program Files folder is a nice idea, but in reality it is just a complete clusterfuck. Every application must default to installing on \%PROGRAMFILES\%. Even modifying that environment variable wont work in most cases. When you are one of those few people that place their regular files on a different partition than their OS, it gets even worse. Creating a hard link (yes NTFS supports it) and/or mounting that partition on \%PROGRAMFILES\% might work on the surface. But when for example some app needs more disk space than the system partition has, it will fail to install. Of course, completely ignoring the actual space available on the mounted/hardlinked partition by design.</p><p>At least with Linux apps you have a general idea of where certain parts are installed. On more than one occasion I had to hunt through my entire filesystem just to find where it placed a savegame or a datafile. Last time I was hunting for a missing/misplaced file that some application needed. Is it in the installation folder? Nope, Program Files? Nope, Common Files? Nope, Administrator? Nope, All Users? Nope. The file ended up being in the root of the installation <i>drive</i> because of a bug in the installer... shrug</p><p>Oh, and please don't get me started with installers. There are a million out there, and every company wants to try and roll their own. What happened to the good times of simply unpacking a compressed archive? Which is, <i>exactly</i> what most of them do anyway! Some publishers don't even bother to compress their products as the installation disk is "big enough", regardless that it increases installation time.</p></htmltext>
<tokenext>I do have to agree with Anonymous , I miss the old DOS days when every application was a single folder .
Installation and removal was nothing more than simply copying a folder or deleting it .
There was no need for installers or package managers as everything was plain in sight.The entire add/remove tool in Windows is nothing more than rundll32 executing some stub that reads a couple keys from the registry .
Its so outdated that the disk space field is 32-bits and thus overflows when you pass 4GB .
Just this little tool alone will never justify the registry in my opinion.In the last decade I observed registry usage by tons and tons of applications .
Generally they do so for two reasons : 1 ) To try and hide settings for users.2 ) Because the app is entirely made out of COM ( + ) and has a gazillion GUIDs it needs to offload to even function at all .
( Microsoft products such as Office and Visual Studio are notorious for this ) Even worse , I 've seen loads of software creating keys in the registry .
Followed by de-authorizing the administrator account from touching those keys .
Its really lovely when some uninstaller fails and you have to manually re-authorize yourself to delete their mess.The Program Files folder is a nice idea , but in reality it is just a complete clusterfuck .
Every application must default to installing on \ % PROGRAMFILES \ % .
Even modifying that environment variable wont work in most cases .
When you are one of those few people that place their regular files on a different partition than their OS , it gets even worse .
Creating a hard link ( yes NTFS supports it ) and/or mounting that partition on \ % PROGRAMFILES \ % might work on the surface .
But when for example some app needs more disk space than the system partition has , it will fail to install .
Of course , completely ignoring the actual space available on the mounted/hardlinked partition by design.At least with Linux apps you have a general idea of where certain parts are installed .
On more than one occasion I had to hunt through my entire filesystem just to find where it placed a savegame or a datafile .
Last time I was hunting for a missing/misplaced file that some application needed .
Is it in the installation folder ?
Nope , Program Files ?
Nope , Common Files ?
Nope , Administrator ?
Nope , All Users ?
Nope. The file ended up being in the root of the installation drive because of a bug in the installer... shrugOh , and please do n't get me started with installers .
There are a million out there , and every company wants to try and roll their own .
What happened to the good times of simply unpacking a compressed archive ?
Which is , exactly what most of them do anyway !
Some publishers do n't even bother to compress their products as the installation disk is " big enough " , regardless that it increases installation time .</tokentext>
<sentencetext>I do have to agree with Anonymous, I miss the old DOS days when every application was a single folder.
Installation and removal was nothing more than simply copying a folder or deleting it.
There was no need for installers or package managers as everything was plain in sight.The entire add/remove tool in Windows is nothing more than rundll32 executing some stub that reads a couple keys from the registry.
Its so outdated that the disk space field is 32-bits and thus overflows when you pass 4GB.
Just this little tool alone will never justify the registry in my opinion.In the last decade I observed registry usage by tons and tons of applications.
Generally they do so for two reasons:1) To try and hide settings for users.2) Because the app is entirely made out of COM(+) and has a gazillion GUIDs it needs to offload to even function at all.
(Microsoft products such as Office and Visual Studio are notorious for this)Even worse, I've seen loads of software creating keys in the registry.
Followed by de-authorizing the administrator account from touching those keys.
Its really lovely when some uninstaller fails and you have to manually re-authorize yourself to delete their mess.The Program Files folder is a nice idea, but in reality it is just a complete clusterfuck.
Every application must default to installing on \%PROGRAMFILES\%.
Even modifying that environment variable wont work in most cases.
When you are one of those few people that place their regular files on a different partition than their OS, it gets even worse.
Creating a hard link (yes NTFS supports it) and/or mounting that partition on \%PROGRAMFILES\% might work on the surface.
But when for example some app needs more disk space than the system partition has, it will fail to install.
Of course, completely ignoring the actual space available on the mounted/hardlinked partition by design.At least with Linux apps you have a general idea of where certain parts are installed.
On more than one occasion I had to hunt through my entire filesystem just to find where it placed a savegame or a datafile.
Last time I was hunting for a missing/misplaced file that some application needed.
Is it in the installation folder?
Nope, Program Files?
Nope, Common Files?
Nope, Administrator?
Nope, All Users?
Nope. The file ended up being in the root of the installation drive because of a bug in the installer... shrugOh, and please don't get me started with installers.
There are a million out there, and every company wants to try and roll their own.
What happened to the good times of simply unpacking a compressed archive?
Which is, exactly what most of them do anyway!
Some publishers don't even bother to compress their products as the installation disk is "big enough", regardless that it increases installation time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609956</id>
	<title>Off domain development</title>
	<author>nurb432</author>
	<datestamp>1262254980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And when you develop mostly AD integrated apps lets see how your isolated VM works out for you.</p></htmltext>
<tokenext>And when you develop mostly AD integrated apps lets see how your isolated VM works out for you .</tokentext>
<sentencetext>And when you develop mostly AD integrated apps lets see how your isolated VM works out for you.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607064</id>
	<title>Not only developers</title>
	<author>Anonymous</author>
	<datestamp>1262283660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I work for a company of ~6500 people, and every last one of them is a local administrator. I work helpdesk, please pray for me/send me booze.</p></htmltext>
<tokenext>I work for a company of ~ 6500 people , and every last one of them is a local administrator .
I work helpdesk , please pray for me/send me booze .</tokentext>
<sentencetext>I work for a company of ~6500 people, and every last one of them is a local administrator.
I work helpdesk, please pray for me/send me booze.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610630</id>
	<title>Re:Conflict of interests</title>
	<author>MobyDisk</author>
	<datestamp>1262259720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Nobody mentioned anything about production machines.</p></htmltext>
<tokenext>Nobody mentioned anything about production machines .</tokentext>
<sentencetext>Nobody mentioned anything about production machines.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607748</id>
	<title>Re:HELL no.</title>
	<author>Anonymous</author>
	<datestamp>1262286300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You are generalizing and also dead wrong. A admin that cannot program is only half a admin and a programmer that does not know system administration is only half a programmer. Remember that<br>when you and I are interviewing for the same job.</p><p>Let me give you a  example, recently I had a machine that would start randomly refusing connections. A quick look determined that a app kept exceeding the open file handle limits. I had a look at the source code and immediately found a section of code that was not properly closing database connections. I tossed a message to the dev with the line numbers and class file to have a<br>look at. A couple of minutes later he patched it and sent me a new release, problem solved.</p><p>
&nbsp; &nbsp; &nbsp;</p></htmltext>
<tokenext>You are generalizing and also dead wrong .
A admin that can not program is only half a admin and a programmer that does not know system administration is only half a programmer .
Remember thatwhen you and I are interviewing for the same job.Let me give you a example , recently I had a machine that would start randomly refusing connections .
A quick look determined that a app kept exceeding the open file handle limits .
I had a look at the source code and immediately found a section of code that was not properly closing database connections .
I tossed a message to the dev with the line numbers and class file to have alook at .
A couple of minutes later he patched it and sent me a new release , problem solved .
     </tokentext>
<sentencetext>You are generalizing and also dead wrong.
A admin that cannot program is only half a admin and a programmer that does not know system administration is only half a programmer.
Remember thatwhen you and I are interviewing for the same job.Let me give you a  example, recently I had a machine that would start randomly refusing connections.
A quick look determined that a app kept exceeding the open file handle limits.
I had a look at the source code and immediately found a section of code that was not properly closing database connections.
I tossed a message to the dev with the line numbers and class file to have alook at.
A couple of minutes later he patched it and sent me a new release, problem solved.
     </sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607206</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607206</id>
	<title>HELL no.</title>
	<author>Anonymous</author>
	<datestamp>1262284260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Developers are not admins. Admins are not developers.</p><p>Any time you start letting one do the job of the other it will end in disaster. *Guaranteed*. Developers simply don't understand all that comes with years of doing admin work and the reasons why they have stupid policies and "red tape", and Admins make lousy coders because they don't understand all that comes with years of writing software that actually works and why the quickest easiest script is usually the worst.</p></htmltext>
<tokenext>Developers are not admins .
Admins are not developers.Any time you start letting one do the job of the other it will end in disaster .
* Guaranteed * . Developers simply do n't understand all that comes with years of doing admin work and the reasons why they have stupid policies and " red tape " , and Admins make lousy coders because they do n't understand all that comes with years of writing software that actually works and why the quickest easiest script is usually the worst .</tokentext>
<sentencetext>Developers are not admins.
Admins are not developers.Any time you start letting one do the job of the other it will end in disaster.
*Guaranteed*. Developers simply don't understand all that comes with years of doing admin work and the reasons why they have stupid policies and "red tape", and Admins make lousy coders because they don't understand all that comes with years of writing software that actually works and why the quickest easiest script is usually the worst.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607360</id>
	<title>Huh?</title>
	<author>Anonymous</author>
	<datestamp>1262284800000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm not even sure why this has to be asked. If a developer doesn't have local admin rights in at least some environment where testing can be done, then the developer simply can't do his or her job. This just seems obvious to me.</p><p>Where I work, employees in IT related groups have local admin rights to their workstation. Additionally, we have multiple test environments. We have a development test environment where developers, as well as QA, can do their testing. Then we have a staging environment, which mimics production, where only administrators have admin rights, just like in production, so that the software being developed can be verified to work in such an environment before being moved to production.</p><p>I do work in a very large corporation.</p></htmltext>
<tokenext>I 'm not even sure why this has to be asked .
If a developer does n't have local admin rights in at least some environment where testing can be done , then the developer simply ca n't do his or her job .
This just seems obvious to me.Where I work , employees in IT related groups have local admin rights to their workstation .
Additionally , we have multiple test environments .
We have a development test environment where developers , as well as QA , can do their testing .
Then we have a staging environment , which mimics production , where only administrators have admin rights , just like in production , so that the software being developed can be verified to work in such an environment before being moved to production.I do work in a very large corporation .</tokentext>
<sentencetext>I'm not even sure why this has to be asked.
If a developer doesn't have local admin rights in at least some environment where testing can be done, then the developer simply can't do his or her job.
This just seems obvious to me.Where I work, employees in IT related groups have local admin rights to their workstation.
Additionally, we have multiple test environments.
We have a development test environment where developers, as well as QA, can do their testing.
Then we have a staging environment, which mimics production, where only administrators have admin rights, just like in production, so that the software being developed can be verified to work in such an environment before being moved to production.I do work in a very large corporation.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900</id>
	<title>What it REALLY comes down to</title>
	<author>Anonymous</author>
	<datestamp>1262283120000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Here's the thing... Why the **** does windows program installation basically require files be installed any place other than locally.  That's the entire problem. The entire design of windows is to install **** under system32 or program files when it doesn't need to be there.  I remember the old days when programs ran under one directory.  Easy to maintain.  You know where everything is.  To uninstall is simply to delete.  Don't get me started on the registry.  REALLY? You're telling me it's "faster" than reading a text file config.  Hardly.   ARE YOU HEARING ME MICROSOFT?   Why the **** do you even need admin rights?  YOU DON"T!!!</p></htmltext>
<tokenext>Here 's the thing... Why the * * * * does windows program installation basically require files be installed any place other than locally .
That 's the entire problem .
The entire design of windows is to install * * * * under system32 or program files when it does n't need to be there .
I remember the old days when programs ran under one directory .
Easy to maintain .
You know where everything is .
To uninstall is simply to delete .
Do n't get me started on the registry .
REALLY ? You 're telling me it 's " faster " than reading a text file config .
Hardly. ARE YOU HEARING ME MICROSOFT ?
Why the * * * * do you even need admin rights ?
YOU DON " T ! !
!</tokentext>
<sentencetext>Here's the thing... Why the **** does windows program installation basically require files be installed any place other than locally.
That's the entire problem.
The entire design of windows is to install **** under system32 or program files when it doesn't need to be there.
I remember the old days when programs ran under one directory.
Easy to maintain.
You know where everything is.
To uninstall is simply to delete.
Don't get me started on the registry.
REALLY? You're telling me it's "faster" than reading a text file config.
Hardly.   ARE YOU HEARING ME MICROSOFT?
Why the **** do you even need admin rights?
YOU DON"T!!
!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607112</id>
	<title>Re:virtualization</title>
	<author>RingDev</author>
	<datestamp>1262283840000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Just what I want to do... Run 3 IDEs, a SQL authoring tool and database explorer, a web browser with 5 tabs, fiddler and other debugging tools, all inside of a VM running on a 3+ year old 32-bit computer with 3 gigs of memory.</p><p>-Rick</p></htmltext>
<tokenext>Just what I want to do... Run 3 IDEs , a SQL authoring tool and database explorer , a web browser with 5 tabs , fiddler and other debugging tools , all inside of a VM running on a 3 + year old 32-bit computer with 3 gigs of memory.-Rick</tokentext>
<sentencetext>Just what I want to do... Run 3 IDEs, a SQL authoring tool and database explorer, a web browser with 5 tabs, fiddler and other debugging tools, all inside of a VM running on a 3+ year old 32-bit computer with 3 gigs of memory.-Rick</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606524</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607230</id>
	<title>Hoopla!</title>
	<author>Mekkah</author>
	<datestamp>1262284320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Most of you are right, dev's don't need admin rights to run their code.. but wtf, they should test this on test accounts anyway.. and it's a hell of a lot easier to install applets and whatnot to help you code when you have admin access..</htmltext>
<tokenext>Most of you are right , dev 's do n't need admin rights to run their code.. but wtf , they should test this on test accounts anyway.. and it 's a hell of a lot easier to install applets and whatnot to help you code when you have admin access. .</tokentext>
<sentencetext>Most of you are right, dev's don't need admin rights to run their code.. but wtf, they should test this on test accounts anyway.. and it's a hell of a lot easier to install applets and whatnot to help you code when you have admin access..</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606470</id>
	<title>Local Admin</title>
	<author>Anonymous</author>
	<datestamp>1262281740000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>In previous places I have worked, the developers did not have local admin privileges on the machines on the network.  We used virtual machines and test boxes that are disassociated from the network for testing and debugging, and the developers had full permissions for those machines.</p></htmltext>
<tokenext>In previous places I have worked , the developers did not have local admin privileges on the machines on the network .
We used virtual machines and test boxes that are disassociated from the network for testing and debugging , and the developers had full permissions for those machines .</tokentext>
<sentencetext>In previous places I have worked, the developers did not have local admin privileges on the machines on the network.
We used virtual machines and test boxes that are disassociated from the network for testing and debugging, and the developers had full permissions for those machines.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609602</id>
	<title>root</title>
	<author>mgessner</author>
	<datestamp>1262252940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You can have my root password when you can pry it out of my cold, dead hands.</p><p>We can admin our windoze machines to install stuff and such, but the domain control rests in our IT dept (2 guys for 140).</p><p>The several "public" linux machines I develop on and administer have a common root password, except for my "personal" machine, which I keep.  All the stuff they'd want off of it is in perforce anyway, so it's not a big deal.</p></htmltext>
<tokenext>You can have my root password when you can pry it out of my cold , dead hands.We can admin our windoze machines to install stuff and such , but the domain control rests in our IT dept ( 2 guys for 140 ) .The several " public " linux machines I develop on and administer have a common root password , except for my " personal " machine , which I keep .
All the stuff they 'd want off of it is in perforce anyway , so it 's not a big deal .</tokentext>
<sentencetext>You can have my root password when you can pry it out of my cold, dead hands.We can admin our windoze machines to install stuff and such, but the domain control rests in our IT dept (2 guys for 140).The several "public" linux machines I develop on and administer have a common root password, except for my "personal" machine, which I keep.
All the stuff they'd want off of it is in perforce anyway, so it's not a big deal.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607032</id>
	<title>Yes in DEV, No in TEST and PROD</title>
	<author>garyisabusyguy</author>
	<datestamp>1262283540000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>It is a huge pain in the ass to do development without local admin rights.</p><p>HOWEVER, it is a huge cluster fuck to implement in PROD because your permission levels all have to be reconfigured to fit any rational security model.</p><p>I have found that denying developers local admin in the TEST environment is a good way to shake out any implementation nightmares</p></htmltext>
<tokenext>It is a huge pain in the ass to do development without local admin rights.HOWEVER , it is a huge cluster fuck to implement in PROD because your permission levels all have to be reconfigured to fit any rational security model.I have found that denying developers local admin in the TEST environment is a good way to shake out any implementation nightmares</tokentext>
<sentencetext>It is a huge pain in the ass to do development without local admin rights.HOWEVER, it is a huge cluster fuck to implement in PROD because your permission levels all have to be reconfigured to fit any rational security model.I have found that denying developers local admin in the TEST environment is a good way to shake out any implementation nightmares</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404</id>
	<title>Re:You damn well should</title>
	<author>Savage-Rabbit</author>
	<datestamp>1262284980000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p><nobr> <wbr></nobr></p><div class="quote"><p>...admin access to production servers, absolutely not. I've seen way too many scary, scary things happen when developers are given unrestricted access to production systems.</p></div><p>IMHO:</p><ul><li>Development should be done using dedicated development systems that replicate the production environment. I have seen way to many problems and delays arise because the developer's setup on his personal laptops didn't exactly replicate the productions deployment environment.</li><li>The development machine-pool should have it's own admin who's **only**  role it is to service those development machines along with the version control/collaboration suite/bug tracking/etc... servers and development should never be done on live systems if it can be avoided.  You need dedicated admins for the development machines because otherwise dozens of developers with root access will turn them into a godawful mess in no time flat.</li><li>Developers should have root access to their own personal workstations/laptops.</li><li>Developers should not have root access to development systems.</li><li>Developers should never, ever, ever have root access to production systems.</li></ul><p>I have worked in various places that had strategies ragning from what I just described and to developing-on/deploying-to live productions systems (with all the irate customers due to regular downtime caused by unexpected bugs which that entails). One place I worked at didn't allow developers admin rights on what development systems they had, they were too cheap to cough up for enough development machines and whenever (rarely) they did overcome their sense of thrift it took a week (if you were lucky) to get the machine up and working. The  work had to be requested through proper channels, approved by a management committee and then performed by a bunch of overworked IT gnomes that also had to service several hundred workstations and a huge productions server-pool.  We didn't even get to be Admin on our own Windows (by management mandate) laptops. Getting a port opened in the firewall on your own Windows workstation had to be approved by a security committee at management level. You can imagine how long that took. Needless to say most people solved these problems by setting up their own development environments. The result was a whole fleet of rogue machines. Every desk had 3-4 computers under it and workstations were regularly taken off the Windows domain by developers or Windows it self was simply quietly replaced with Linux. It was the only way to get things done and even then the pace of work was glacial.</p></div>
	</htmltext>
<tokenext>...admin access to production servers , absolutely not .
I 've seen way too many scary , scary things happen when developers are given unrestricted access to production systems.IMHO : Development should be done using dedicated development systems that replicate the production environment .
I have seen way to many problems and delays arise because the developer 's setup on his personal laptops did n't exactly replicate the productions deployment environment.The development machine-pool should have it 's own admin who 's * * only * * role it is to service those development machines along with the version control/collaboration suite/bug tracking/etc... servers and development should never be done on live systems if it can be avoided .
You need dedicated admins for the development machines because otherwise dozens of developers with root access will turn them into a godawful mess in no time flat.Developers should have root access to their own personal workstations/laptops.Developers should not have root access to development systems.Developers should never , ever , ever have root access to production systems.I have worked in various places that had strategies ragning from what I just described and to developing-on/deploying-to live productions systems ( with all the irate customers due to regular downtime caused by unexpected bugs which that entails ) .
One place I worked at did n't allow developers admin rights on what development systems they had , they were too cheap to cough up for enough development machines and whenever ( rarely ) they did overcome their sense of thrift it took a week ( if you were lucky ) to get the machine up and working .
The work had to be requested through proper channels , approved by a management committee and then performed by a bunch of overworked IT gnomes that also had to service several hundred workstations and a huge productions server-pool .
We did n't even get to be Admin on our own Windows ( by management mandate ) laptops .
Getting a port opened in the firewall on your own Windows workstation had to be approved by a security committee at management level .
You can imagine how long that took .
Needless to say most people solved these problems by setting up their own development environments .
The result was a whole fleet of rogue machines .
Every desk had 3-4 computers under it and workstations were regularly taken off the Windows domain by developers or Windows it self was simply quietly replaced with Linux .
It was the only way to get things done and even then the pace of work was glacial .</tokentext>
<sentencetext> ...admin access to production servers, absolutely not.
I've seen way too many scary, scary things happen when developers are given unrestricted access to production systems.IMHO:Development should be done using dedicated development systems that replicate the production environment.
I have seen way to many problems and delays arise because the developer's setup on his personal laptops didn't exactly replicate the productions deployment environment.The development machine-pool should have it's own admin who's **only**  role it is to service those development machines along with the version control/collaboration suite/bug tracking/etc... servers and development should never be done on live systems if it can be avoided.
You need dedicated admins for the development machines because otherwise dozens of developers with root access will turn them into a godawful mess in no time flat.Developers should have root access to their own personal workstations/laptops.Developers should not have root access to development systems.Developers should never, ever, ever have root access to production systems.I have worked in various places that had strategies ragning from what I just described and to developing-on/deploying-to live productions systems (with all the irate customers due to regular downtime caused by unexpected bugs which that entails).
One place I worked at didn't allow developers admin rights on what development systems they had, they were too cheap to cough up for enough development machines and whenever (rarely) they did overcome their sense of thrift it took a week (if you were lucky) to get the machine up and working.
The  work had to be requested through proper channels, approved by a management committee and then performed by a bunch of overworked IT gnomes that also had to service several hundred workstations and a huge productions server-pool.
We didn't even get to be Admin on our own Windows (by management mandate) laptops.
Getting a port opened in the firewall on your own Windows workstation had to be approved by a security committee at management level.
You can imagine how long that took.
Needless to say most people solved these problems by setting up their own development environments.
The result was a whole fleet of rogue machines.
Every desk had 3-4 computers under it and workstations were regularly taken off the Windows domain by developers or Windows it self was simply quietly replaced with Linux.
It was the only way to get things done and even then the pace of work was glacial.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606896</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262283120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I'd be highly reluctant to work at a place that didn't let me install and manage the software packages I needed to do my job.</p></div><p>Must be nice, being able to pick and choose what jobs you take. Unfortunately, most people here don't have that luxury.</p></div>
	</htmltext>
<tokenext>I 'd be highly reluctant to work at a place that did n't let me install and manage the software packages I needed to do my job.Must be nice , being able to pick and choose what jobs you take .
Unfortunately , most people here do n't have that luxury .</tokentext>
<sentencetext>I'd be highly reluctant to work at a place that didn't let me install and manage the software packages I needed to do my job.Must be nice, being able to pick and choose what jobs you take.
Unfortunately, most people here don't have that luxury.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610520</id>
	<title>Developers \_must\_ be admins to debug!</title>
	<author>MobyDisk</author>
	<datestamp>1262258700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Developers must be local administrators to:<br>- Manage local services (Ex: SQL server, COM+, etc.)<br>- Register/unregister COM objects; Add/remove objects from the GAC; change the strong-naming settings,<nobr> <wbr></nobr>...<br>- Attach the debugger to a process<br>- Change IE security settings</p><p>You can actually attach a debugger if you are in the "Debugger users" group but there's no sense in removing local Administrator rights from a debugger user because the debugger can be used to execute privilege escalation attacks.  So all you do is make it harder for the developer, without buying you any security.</p></htmltext>
<tokenext>Developers must be local administrators to : - Manage local services ( Ex : SQL server , COM + , etc .
) - Register/unregister COM objects ; Add/remove objects from the GAC ; change the strong-naming settings , ...- Attach the debugger to a process- Change IE security settingsYou can actually attach a debugger if you are in the " Debugger users " group but there 's no sense in removing local Administrator rights from a debugger user because the debugger can be used to execute privilege escalation attacks .
So all you do is make it harder for the developer , without buying you any security .</tokentext>
<sentencetext>Developers must be local administrators to:- Manage local services (Ex: SQL server, COM+, etc.
)- Register/unregister COM objects; Add/remove objects from the GAC; change the strong-naming settings, ...- Attach the debugger to a process- Change IE security settingsYou can actually attach a debugger if you are in the "Debugger users" group but there's no sense in removing local Administrator rights from a debugger user because the debugger can be used to execute privilege escalation attacks.
So all you do is make it harder for the developer, without buying you any security.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608358</id>
	<title>Yes</title>
	<author>Mutatis Mutandis</author>
	<datestamp>1262289120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yes for local systems, and that is using a wide definition of "developers" -- not just the professional software developers we employ, but also the people in "informatics" who are basically scientists who build or evaluate new software tools for data analysis, and the engineers who write software to control automated systems.</p><p>As far as I understand, this is against our own Very-Large-Company policy, and the threat of having administrator rights taken away is hovering constantly over our heads (now said to be a central IT goal by the end of 2010), but fortunately our local IT managers do understand that we need them. It wouldn't be worth the massive overhead of routing all requests for installation of new software over three different continents (I'm not kidding) and some people with difficult-to-replace skills would simply walk out if this was taken away from them.</p><p>There are always dire predictions of the disasters that will result by granting mere end-users administrator rights, but incidents are rare and usually easily resolved. Frankly, while it is true enough that many of the people with admin rights don't know that much about system administration, they actually know a lot more than the average helpdesk jockey who is in and out within a year, but can apparently be trusted with the powers to mess things up thoroughly...</p><p>Admin rights for servers we don't have on a personal basis, but on servers that are dedicated for specific purposes, some of us have access to service accounts that have administrator rights. If the server provides services to multiple people, the IT people are usually unwilling to grant that, and I find that understandable even if I don't entirely agree.</p></htmltext>
<tokenext>Yes for local systems , and that is using a wide definition of " developers " -- not just the professional software developers we employ , but also the people in " informatics " who are basically scientists who build or evaluate new software tools for data analysis , and the engineers who write software to control automated systems.As far as I understand , this is against our own Very-Large-Company policy , and the threat of having administrator rights taken away is hovering constantly over our heads ( now said to be a central IT goal by the end of 2010 ) , but fortunately our local IT managers do understand that we need them .
It would n't be worth the massive overhead of routing all requests for installation of new software over three different continents ( I 'm not kidding ) and some people with difficult-to-replace skills would simply walk out if this was taken away from them.There are always dire predictions of the disasters that will result by granting mere end-users administrator rights , but incidents are rare and usually easily resolved .
Frankly , while it is true enough that many of the people with admin rights do n't know that much about system administration , they actually know a lot more than the average helpdesk jockey who is in and out within a year , but can apparently be trusted with the powers to mess things up thoroughly...Admin rights for servers we do n't have on a personal basis , but on servers that are dedicated for specific purposes , some of us have access to service accounts that have administrator rights .
If the server provides services to multiple people , the IT people are usually unwilling to grant that , and I find that understandable even if I do n't entirely agree .</tokentext>
<sentencetext>Yes for local systems, and that is using a wide definition of "developers" -- not just the professional software developers we employ, but also the people in "informatics" who are basically scientists who build or evaluate new software tools for data analysis, and the engineers who write software to control automated systems.As far as I understand, this is against our own Very-Large-Company policy, and the threat of having administrator rights taken away is hovering constantly over our heads (now said to be a central IT goal by the end of 2010), but fortunately our local IT managers do understand that we need them.
It wouldn't be worth the massive overhead of routing all requests for installation of new software over three different continents (I'm not kidding) and some people with difficult-to-replace skills would simply walk out if this was taken away from them.There are always dire predictions of the disasters that will result by granting mere end-users administrator rights, but incidents are rare and usually easily resolved.
Frankly, while it is true enough that many of the people with admin rights don't know that much about system administration, they actually know a lot more than the average helpdesk jockey who is in and out within a year, but can apparently be trusted with the powers to mess things up thoroughly...Admin rights for servers we don't have on a personal basis, but on servers that are dedicated for specific purposes, some of us have access to service accounts that have administrator rights.
If the server provides services to multiple people, the IT people are usually unwilling to grant that, and I find that understandable even if I don't entirely agree.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607154</id>
	<title>Nope!</title>
	<author>Anonymous</author>
	<datestamp>1262284020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The answer is that it depends. Admin on their own workstation, absolutely. Admin rights on a server, not unless they have a really valid reason to violate security policy.</p><p>The code needs to run in user mode, there are few reasons for the developers to run higher than that.</p><p>We have all seen examples of where running in user mode breaks code. There are very few valid reasons for that.</p></htmltext>
<tokenext>The answer is that it depends .
Admin on their own workstation , absolutely .
Admin rights on a server , not unless they have a really valid reason to violate security policy.The code needs to run in user mode , there are few reasons for the developers to run higher than that.We have all seen examples of where running in user mode breaks code .
There are very few valid reasons for that .</tokentext>
<sentencetext>The answer is that it depends.
Admin on their own workstation, absolutely.
Admin rights on a server, not unless they have a really valid reason to violate security policy.The code needs to run in user mode, there are few reasons for the developers to run higher than that.We have all seen examples of where running in user mode breaks code.
There are very few valid reasons for that.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608228</id>
	<title>Why?</title>
	<author>Anonymous</author>
	<datestamp>1262288400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Why should a developer have admin rights? In some cases, I can see giving them power user rights (for Windows boxes) or restricted sudo rights (for Linux machines). But no one should be running as admin for daily use. Most developers I've worked with were clueless about system administration (I say that as a developer) and most of them shouldn't be trusted with root/admin access. I do development on Linux most of the time and I don't need access to the root account.</p><p>Granted, a good developer will probably find a way to grant themselves admin access unless the system is really well secured.</p></htmltext>
<tokenext>Why should a developer have admin rights ?
In some cases , I can see giving them power user rights ( for Windows boxes ) or restricted sudo rights ( for Linux machines ) .
But no one should be running as admin for daily use .
Most developers I 've worked with were clueless about system administration ( I say that as a developer ) and most of them should n't be trusted with root/admin access .
I do development on Linux most of the time and I do n't need access to the root account.Granted , a good developer will probably find a way to grant themselves admin access unless the system is really well secured .</tokentext>
<sentencetext>Why should a developer have admin rights?
In some cases, I can see giving them power user rights (for Windows boxes) or restricted sudo rights (for Linux machines).
But no one should be running as admin for daily use.
Most developers I've worked with were clueless about system administration (I say that as a developer) and most of them shouldn't be trusted with root/admin access.
I do development on Linux most of the time and I don't need access to the root account.Granted, a good developer will probably find a way to grant themselves admin access unless the system is really well secured.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607024</id>
	<title>Euh, vmware?</title>
	<author>bomek</author>
	<datestamp>1262283540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Why not use vmware or similar?</p></htmltext>
<tokenext>Why not use vmware or similar ?</tokentext>
<sentencetext>Why not use vmware or similar?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609472</id>
	<title>Re:virtualization</title>
	<author>Achromatic1978</author>
	<datestamp>1262252160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I feel your pain. I went from an environment where I was asked to do similar, to a home office environment where I have a desktop with a 3.2GHz Core 2 Duo, 12GB of memory, talking to a machine under my desk that is running a Core i7 2.93GHz, 16GB of RAM, 8TB of RAID, and about 6 virtual machines. I couldn't tell you the practical difference between that and 6 physical machines, even under heavy load. Yay XenServer and paravirtualization.</htmltext>
<tokenext>I feel your pain .
I went from an environment where I was asked to do similar , to a home office environment where I have a desktop with a 3.2GHz Core 2 Duo , 12GB of memory , talking to a machine under my desk that is running a Core i7 2.93GHz , 16GB of RAM , 8TB of RAID , and about 6 virtual machines .
I could n't tell you the practical difference between that and 6 physical machines , even under heavy load .
Yay XenServer and paravirtualization .</tokentext>
<sentencetext>I feel your pain.
I went from an environment where I was asked to do similar, to a home office environment where I have a desktop with a 3.2GHz Core 2 Duo, 12GB of memory, talking to a machine under my desk that is running a Core i7 2.93GHz, 16GB of RAM, 8TB of RAID, and about 6 virtual machines.
I couldn't tell you the practical difference between that and 6 physical machines, even under heavy load.
Yay XenServer and paravirtualization.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607112</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607310</id>
	<title>Yes and No</title>
	<author>Anonymous</author>
	<datestamp>1262284680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I do some development work in a healthcare environment - I have root on a dev machine and user level access on a testing machine.</p><p>I think you actually need both - the ability to change things for testing and development, and the ability to test on a generic user machine.</p></htmltext>
<tokenext>I do some development work in a healthcare environment - I have root on a dev machine and user level access on a testing machine.I think you actually need both - the ability to change things for testing and development , and the ability to test on a generic user machine .</tokentext>
<sentencetext>I do some development work in a healthcare environment - I have root on a dev machine and user level access on a testing machine.I think you actually need both - the ability to change things for testing and development, and the ability to test on a generic user machine.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607420</id>
	<title>what type of admin rights?</title>
	<author>ei4anb</author>
	<datestamp>1262285040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Windows has a variety of rights and privileges (see: <a href="http://technet.microsoft.com/en-us/library/bb457125.aspx" title="microsoft.com">http://technet.microsoft.com/en-us/library/bb457125.aspx</a> [microsoft.com] ) Developers should have debug privileges but should not be full administrators. It always surprises me that administrators do not use the fine grained control of privileges that is available to them when creating groups. When developers are given full administrator rights the users often find that the program will not run propperly under a normal (non-admin) user account. The test group must use accounts that have exactly the same rights &amp; privileges as the eventual users.</htmltext>
<tokenext>Windows has a variety of rights and privileges ( see : http : //technet.microsoft.com/en-us/library/bb457125.aspx [ microsoft.com ] ) Developers should have debug privileges but should not be full administrators .
It always surprises me that administrators do not use the fine grained control of privileges that is available to them when creating groups .
When developers are given full administrator rights the users often find that the program will not run propperly under a normal ( non-admin ) user account .
The test group must use accounts that have exactly the same rights &amp; privileges as the eventual users .</tokentext>
<sentencetext>Windows has a variety of rights and privileges (see: http://technet.microsoft.com/en-us/library/bb457125.aspx [microsoft.com] ) Developers should have debug privileges but should not be full administrators.
It always surprises me that administrators do not use the fine grained control of privileges that is available to them when creating groups.
When developers are given full administrator rights the users often find that the program will not run propperly under a normal (non-admin) user account.
The test group must use accounts that have exactly the same rights &amp; privileges as the eventual users.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613198</id>
	<title>Virtual Machines</title>
	<author>keean</author>
	<datestamp>1230808740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>These days developers do not need admin rights to physical machines. All they need is a user account with permission to launch virtual machine instances. They can have admin rights on the virtual machines.</htmltext>
<tokenext>These days developers do not need admin rights to physical machines .
All they need is a user account with permission to launch virtual machine instances .
They can have admin rights on the virtual machines .</tokentext>
<sentencetext>These days developers do not need admin rights to physical machines.
All they need is a user account with permission to launch virtual machine instances.
They can have admin rights on the virtual machines.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609120</id>
	<title>Re:Generally, yes</title>
	<author>BitZtream</author>
	<datestamp>1262250000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That works fine when your company is all of 10 employees.</p><p>Doesn't work out the same way when your company is 10k or 100k employees, you'll spend all your time realizing that exactly 3 seconds after you fixed the last screw up that someone else made a new one, or that 5 minutes before you fixed the last screw up, someone else screwed up 20 more things while you were finding the last one.</p></htmltext>
<tokenext>That works fine when your company is all of 10 employees.Does n't work out the same way when your company is 10k or 100k employees , you 'll spend all your time realizing that exactly 3 seconds after you fixed the last screw up that someone else made a new one , or that 5 minutes before you fixed the last screw up , someone else screwed up 20 more things while you were finding the last one .</tokentext>
<sentencetext>That works fine when your company is all of 10 employees.Doesn't work out the same way when your company is 10k or 100k employees, you'll spend all your time realizing that exactly 3 seconds after you fixed the last screw up that someone else made a new one, or that 5 minutes before you fixed the last screw up, someone else screwed up 20 more things while you were finding the last one.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606482</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608244</id>
	<title>Workstations in DoD (well my part of DoD)</title>
	<author>Anonymous</author>
	<datestamp>1262288520000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I work for a very large U.S. Government Defense branch as a UNIX system administrator. Our workstation provider provides us development accounts which have local administrator access. Not only can this account make changes to the local workstation (as one would expect with an Administrator account), the account not required to use a SmartCard (CAC) for login. However, to gain this level of access to the system we are required to take an extra class (online) and go through an IA approval process every year. This workstation usually only provides me with e-mail, as my work workstation is a Ubuntu system that connects to our "management" network. This allows me to manage the systems on our local floor.</p><p>However the local admin access on my "e-mail" system has been indispensable on more than one occasion.</p></htmltext>
<tokenext>I work for a very large U.S. Government Defense branch as a UNIX system administrator .
Our workstation provider provides us development accounts which have local administrator access .
Not only can this account make changes to the local workstation ( as one would expect with an Administrator account ) , the account not required to use a SmartCard ( CAC ) for login .
However , to gain this level of access to the system we are required to take an extra class ( online ) and go through an IA approval process every year .
This workstation usually only provides me with e-mail , as my work workstation is a Ubuntu system that connects to our " management " network .
This allows me to manage the systems on our local floor.However the local admin access on my " e-mail " system has been indispensable on more than one occasion .</tokentext>
<sentencetext>I work for a very large U.S. Government Defense branch as a UNIX system administrator.
Our workstation provider provides us development accounts which have local administrator access.
Not only can this account make changes to the local workstation (as one would expect with an Administrator account), the account not required to use a SmartCard (CAC) for login.
However, to gain this level of access to the system we are required to take an extra class (online) and go through an IA approval process every year.
This workstation usually only provides me with e-mail, as my work workstation is a Ubuntu system that connects to our "management" network.
This allows me to manage the systems on our local floor.However the local admin access on my "e-mail" system has been indispensable on more than one occasion.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607798</id>
	<title>Yes we do... for the most part.</title>
	<author>whiplash13</author>
	<datestamp>1262286480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I have now been a project manager for 2 Global 200 companies and both gave developers limited admin rights to their machines.  They have full rights to install anything on their machine and configure services but don't have the ability to perform user permission changes and such.</htmltext>
<tokenext>I have now been a project manager for 2 Global 200 companies and both gave developers limited admin rights to their machines .
They have full rights to install anything on their machine and configure services but do n't have the ability to perform user permission changes and such .</tokentext>
<sentencetext>I have now been a project manager for 2 Global 200 companies and both gave developers limited admin rights to their machines.
They have full rights to install anything on their machine and configure services but don't have the ability to perform user permission changes and such.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606848</id>
	<title>Re:What?</title>
	<author>Anonymous</author>
	<datestamp>1262282940000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext>Hello friends,

I'm in a bit of a bind here. You see, I have a problem with my...well, with my penis! Yes, I am slightly embarrassed to admit this, but I figure that my friends at Slashdot will be able to help me. At any rate, the problem with my penis is that every so often it gets longer and feels rigid to the touch. And, when I do touch it in this state, I get a strange, yet pleasurable, sensation.

I've asked coworkers and friends about this, and they have not been able to help me. They usually giggle or laugh and say I need a cock sucker. I'm not sure what that means, and whenever I ask for clarification on cock sucker, I get sarcastic responses. So, my Slashdot friends, is there something wrong with me? Why does my penis get this way? Does anybody have a similar experience?</htmltext>
<tokenext>Hello friends , I 'm in a bit of a bind here .
You see , I have a problem with my...well , with my penis !
Yes , I am slightly embarrassed to admit this , but I figure that my friends at Slashdot will be able to help me .
At any rate , the problem with my penis is that every so often it gets longer and feels rigid to the touch .
And , when I do touch it in this state , I get a strange , yet pleasurable , sensation .
I 've asked coworkers and friends about this , and they have not been able to help me .
They usually giggle or laugh and say I need a cock sucker .
I 'm not sure what that means , and whenever I ask for clarification on cock sucker , I get sarcastic responses .
So , my Slashdot friends , is there something wrong with me ?
Why does my penis get this way ?
Does anybody have a similar experience ?</tokentext>
<sentencetext>Hello friends,

I'm in a bit of a bind here.
You see, I have a problem with my...well, with my penis!
Yes, I am slightly embarrassed to admit this, but I figure that my friends at Slashdot will be able to help me.
At any rate, the problem with my penis is that every so often it gets longer and feels rigid to the touch.
And, when I do touch it in this state, I get a strange, yet pleasurable, sensation.
I've asked coworkers and friends about this, and they have not been able to help me.
They usually giggle or laugh and say I need a cock sucker.
I'm not sure what that means, and whenever I ask for clarification on cock sucker, I get sarcastic responses.
So, my Slashdot friends, is there something wrong with me?
Why does my penis get this way?
Does anybody have a similar experience?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606448</id>
	<title>Yes</title>
	<author>Anonymous</author>
	<datestamp>1262281680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>All of the places where I've worked as an Admin,  I gave the developers admin rights so they could install software, but only on development systems.  Don't even think about giving them on production systems.  Of course, I spent quite a bit of time fixing development machines due to something these folks have done, but all production systems were updated by me.</p></htmltext>
<tokenext>All of the places where I 've worked as an Admin , I gave the developers admin rights so they could install software , but only on development systems .
Do n't even think about giving them on production systems .
Of course , I spent quite a bit of time fixing development machines due to something these folks have done , but all production systems were updated by me .</tokentext>
<sentencetext>All of the places where I've worked as an Admin,  I gave the developers admin rights so they could install software, but only on development systems.
Don't even think about giving them on production systems.
Of course, I spent quite a bit of time fixing development machines due to something these folks have done, but all production systems were updated by me.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30614838</id>
	<title>Dev-Y, test,prod-N</title>
	<author>ebvwfbw</author>
	<datestamp>1230833820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Dev is the development test bed. Test, they had better have what it is they want to do all on paper, even if that is an electronic document.  How to install \_\_\_\_\_, how to configure \_\_\_\_\_, how to test that \_\_\_\_\_\_ is working.  Follow it in the test environment and if it works, move to production.  We often copy the production machine to the test machine bed.  Just copy the san disk.  If you do it in a Xen environment it is even easier.<p>
Why go through all of this? What happens if the production machine or even the site is destroyed?  What happens if everyone in your building is hit with some new bug that kills everyone or the building being built badly collapses and kills everyone?  I have also found it is very useful to have these records.  Even for projects that I did 10 or 15 years ago I can't remember stuff any more.  It also comes in useful if something is set wrong.  Was it that way to begin with or did the software upgrade break something?  I've put people from some very large organizations on the spot because I could pinpoint when something was changed on their part and not documented.</p><p>
Finally, it is good to keep developers off the production box.  They may put something on there that they are not supposed to.  I know, I used to do it and so did all of my other developer friends.  That stuff has been known to be used by attackers.</p></htmltext>
<tokenext>Dev is the development test bed .
Test , they had better have what it is they want to do all on paper , even if that is an electronic document .
How to install \ _ \ _ \ _ \ _ \ _ , how to configure \ _ \ _ \ _ \ _ \ _ , how to test that \ _ \ _ \ _ \ _ \ _ \ _ is working .
Follow it in the test environment and if it works , move to production .
We often copy the production machine to the test machine bed .
Just copy the san disk .
If you do it in a Xen environment it is even easier .
Why go through all of this ?
What happens if the production machine or even the site is destroyed ?
What happens if everyone in your building is hit with some new bug that kills everyone or the building being built badly collapses and kills everyone ?
I have also found it is very useful to have these records .
Even for projects that I did 10 or 15 years ago I ca n't remember stuff any more .
It also comes in useful if something is set wrong .
Was it that way to begin with or did the software upgrade break something ?
I 've put people from some very large organizations on the spot because I could pinpoint when something was changed on their part and not documented .
Finally , it is good to keep developers off the production box .
They may put something on there that they are not supposed to .
I know , I used to do it and so did all of my other developer friends .
That stuff has been known to be used by attackers .</tokentext>
<sentencetext>Dev is the development test bed.
Test, they had better have what it is they want to do all on paper, even if that is an electronic document.
How to install \_\_\_\_\_, how to configure \_\_\_\_\_, how to test that \_\_\_\_\_\_ is working.
Follow it in the test environment and if it works, move to production.
We often copy the production machine to the test machine bed.
Just copy the san disk.
If you do it in a Xen environment it is even easier.
Why go through all of this?
What happens if the production machine or even the site is destroyed?
What happens if everyone in your building is hit with some new bug that kills everyone or the building being built badly collapses and kills everyone?
I have also found it is very useful to have these records.
Even for projects that I did 10 or 15 years ago I can't remember stuff any more.
It also comes in useful if something is set wrong.
Was it that way to begin with or did the software upgrade break something?
I've put people from some very large organizations on the spot because I could pinpoint when something was changed on their part and not documented.
Finally, it is good to keep developers off the production box.
They may put something on there that they are not supposed to.
I know, I used to do it and so did all of my other developer friends.
That stuff has been known to be used by attackers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608672</id>
	<title>Re:Yes</title>
	<author>kojimoto\_atusis</author>
	<datestamp>1262290860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Yes. Both at the company I work for and the regional bank I developed for a couple years ago. It is impossible, IMO, to do many functions without these privileges.</p></div><p>Yes

This should be a poll, probably the result would be 99\% Yes</p></div>
	</htmltext>
<tokenext>Yes .
Both at the company I work for and the regional bank I developed for a couple years ago .
It is impossible , IMO , to do many functions without these privileges.Yes This should be a poll , probably the result would be 99 \ % Yes</tokentext>
<sentencetext>Yes.
Both at the company I work for and the regional bank I developed for a couple years ago.
It is impossible, IMO, to do many functions without these privileges.Yes

This should be a poll, probably the result would be 99\% Yes
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609154</id>
	<title>Re:What?</title>
	<author>IdleTime</author>
	<datestamp>1262250300000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>Here is what you need to do: (I also work for a similar corporation with the exact same policies, maybe the same one?)<br>
1. Install Linux and get it connect to your corp network (I run Ubuntu 9.10)<br>
2. Install a virtualization environment (My company has a deal with VMWare)<br>
3. Create a virtual image with Windows which you use to develop on, giving you full admin rights.<br> <br>
It also avoids any impact of Windows bugs or BSOD's.</htmltext>
<tokenext>Here is what you need to do : ( I also work for a similar corporation with the exact same policies , maybe the same one ?
) 1 .
Install Linux and get it connect to your corp network ( I run Ubuntu 9.10 ) 2 .
Install a virtualization environment ( My company has a deal with VMWare ) 3 .
Create a virtual image with Windows which you use to develop on , giving you full admin rights .
It also avoids any impact of Windows bugs or BSOD 's .</tokentext>
<sentencetext>Here is what you need to do: (I also work for a similar corporation with the exact same policies, maybe the same one?
)
1.
Install Linux and get it connect to your corp network (I run Ubuntu 9.10)
2.
Install a virtualization environment (My company has a deal with VMWare)
3.
Create a virtual image with Windows which you use to develop on, giving you full admin rights.
It also avoids any impact of Windows bugs or BSOD's.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610896</id>
	<title>Education and Teamwork are key..</title>
	<author>hspencer77</author>
	<datestamp>1262262240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>CmdrTaco:

I have been on all three levels: developer, desktop administrator for developers, and server admin for developers.  From my experience, its easier to do it on a *nix environment vs. Windows environment - that's not to say it can't be done.  If you have a good Windows Active Directory Administrator, you can set up GPOs that allow developers to have the necessary rights to develop and maintain applications in a production environment.  The biggest pain is getting the developers to change their habits.

The way that my department implemented these accounts on the Windows side, is that we created separate accounts. So, say for instance, your username is foo. We then would create in Active Directory an a\_ account (i.e. a\_foo). That would be your admin account.  We then would create GPOs to access the correct registry information in Windows to allow debugging, installation, etc. on that machine.  Since, we have GPOs on a group of machines, if we needed to use any of those GPOs on the server environment, we could do that as well.

Once we got that set up, and educated the developers on how to use their a\_ accounts, they were able to develop and maintain the production applications in Windows with no problem.

And if you wanted to use the same type of administrative structure on any *nix system, you could use PAM and sudo controls to give the developers the flexibility that they need.

Hope this helps...

IMO, when developers have total control over production machines, its because management doesn't understand how admin controls can be separated from users, and the developers aren't open to a "change".</htmltext>
<tokenext>CmdrTaco : I have been on all three levels : developer , desktop administrator for developers , and server admin for developers .
From my experience , its easier to do it on a * nix environment vs. Windows environment - that 's not to say it ca n't be done .
If you have a good Windows Active Directory Administrator , you can set up GPOs that allow developers to have the necessary rights to develop and maintain applications in a production environment .
The biggest pain is getting the developers to change their habits .
The way that my department implemented these accounts on the Windows side , is that we created separate accounts .
So , say for instance , your username is foo .
We then would create in Active Directory an a \ _ account ( i.e .
a \ _foo ) . That would be your admin account .
We then would create GPOs to access the correct registry information in Windows to allow debugging , installation , etc .
on that machine .
Since , we have GPOs on a group of machines , if we needed to use any of those GPOs on the server environment , we could do that as well .
Once we got that set up , and educated the developers on how to use their a \ _ accounts , they were able to develop and maintain the production applications in Windows with no problem .
And if you wanted to use the same type of administrative structure on any * nix system , you could use PAM and sudo controls to give the developers the flexibility that they need .
Hope this helps.. . IMO , when developers have total control over production machines , its because management does n't understand how admin controls can be separated from users , and the developers are n't open to a " change " .</tokentext>
<sentencetext>CmdrTaco:

I have been on all three levels: developer, desktop administrator for developers, and server admin for developers.
From my experience, its easier to do it on a *nix environment vs. Windows environment - that's not to say it can't be done.
If you have a good Windows Active Directory Administrator, you can set up GPOs that allow developers to have the necessary rights to develop and maintain applications in a production environment.
The biggest pain is getting the developers to change their habits.
The way that my department implemented these accounts on the Windows side, is that we created separate accounts.
So, say for instance, your username is foo.
We then would create in Active Directory an a\_ account (i.e.
a\_foo). That would be your admin account.
We then would create GPOs to access the correct registry information in Windows to allow debugging, installation, etc.
on that machine.
Since, we have GPOs on a group of machines, if we needed to use any of those GPOs on the server environment, we could do that as well.
Once we got that set up, and educated the developers on how to use their a\_ accounts, they were able to develop and maintain the production applications in Windows with no problem.
And if you wanted to use the same type of administrative structure on any *nix system, you could use PAM and sudo controls to give the developers the flexibility that they need.
Hope this helps...

IMO, when developers have total control over production machines, its because management doesn't understand how admin controls can be separated from users, and the developers aren't open to a "change".</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607730</id>
	<title>Umm... No</title>
	<author>tbgreve</author>
	<datestamp>1262286300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Not just no but, No Way In Hell!!! Ever!!!</htmltext>
<tokenext>Not just no but , No Way In Hell ! ! !
Ever ! ! !</tokentext>
<sentencetext>Not just no but, No Way In Hell!!!
Ever!!!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613068</id>
	<title>Re:Yes</title>
	<author>raju1kabir</author>
	<datestamp>1230806100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>However that account is a member of the \_developer group, which gives the debugger the right to attach to processes.</p></div></blockquote><p>Isn't that enough to easily elevate yourself to root? Seems like all you need is the ability to run some privileged process, like the control panel, and then the world is yours.</p></div>
	</htmltext>
<tokenext>However that account is a member of the \ _developer group , which gives the debugger the right to attach to processes.Is n't that enough to easily elevate yourself to root ?
Seems like all you need is the ability to run some privileged process , like the control panel , and then the world is yours .</tokentext>
<sentencetext>However that account is a member of the \_developer group, which gives the debugger the right to attach to processes.Isn't that enough to easily elevate yourself to root?
Seems like all you need is the ability to run some privileged process, like the control panel, and then the world is yours.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607200</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30741236</id>
	<title>What devs</title>
	<author>Anonymous</author>
	<datestamp>1231791000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>As said before, any developer who can't administer their own machine is not a good developer.  I've worked with several who were so ignorant of their OS that they would send a request to Help Desk to do menial tasks like install service packs or partition their new hard drive.  Really? Come on, one woman didn't even know how to install her OS from scratch on a new machine.  She was waiting for someone in IT to do it for her, I said "Uh, why don't you just throw the Windows disk in there and do it yourself?" And she says she doesn't know how.  WTF.</p><p>The common factor with these devs is that they also coded very poorly, did not understand what the system was doing for each line of code, were completely ignorant of why you get different performance with one line of code that makes a DB call, reads a file, or simply increments a number.  I tried explaining that it doesn't matter how fast your CPU is if you're waiting for a lengthy DB query, I get deer in the headlights look.</p><p>Bottom line, a dev who can't administer his own machine is not a real geek who grew up building machines and learning everything about them because he loves it - they are the product of Computer Science classes and know the bare minimum they need to know to put code together and make it do stuff. Someone who decided at age 20 "Uhh, software devs make good money, I'll do that."  I don't want any devs like that on my team.</p></htmltext>
<tokenext>As said before , any developer who ca n't administer their own machine is not a good developer .
I 've worked with several who were so ignorant of their OS that they would send a request to Help Desk to do menial tasks like install service packs or partition their new hard drive .
Really ? Come on , one woman did n't even know how to install her OS from scratch on a new machine .
She was waiting for someone in IT to do it for her , I said " Uh , why do n't you just throw the Windows disk in there and do it yourself ?
" And she says she does n't know how .
WTF.The common factor with these devs is that they also coded very poorly , did not understand what the system was doing for each line of code , were completely ignorant of why you get different performance with one line of code that makes a DB call , reads a file , or simply increments a number .
I tried explaining that it does n't matter how fast your CPU is if you 're waiting for a lengthy DB query , I get deer in the headlights look.Bottom line , a dev who ca n't administer his own machine is not a real geek who grew up building machines and learning everything about them because he loves it - they are the product of Computer Science classes and know the bare minimum they need to know to put code together and make it do stuff .
Someone who decided at age 20 " Uhh , software devs make good money , I 'll do that .
" I do n't want any devs like that on my team .</tokentext>
<sentencetext>As said before, any developer who can't administer their own machine is not a good developer.
I've worked with several who were so ignorant of their OS that they would send a request to Help Desk to do menial tasks like install service packs or partition their new hard drive.
Really? Come on, one woman didn't even know how to install her OS from scratch on a new machine.
She was waiting for someone in IT to do it for her, I said "Uh, why don't you just throw the Windows disk in there and do it yourself?
" And she says she doesn't know how.
WTF.The common factor with these devs is that they also coded very poorly, did not understand what the system was doing for each line of code, were completely ignorant of why you get different performance with one line of code that makes a DB call, reads a file, or simply increments a number.
I tried explaining that it doesn't matter how fast your CPU is if you're waiting for a lengthy DB query, I get deer in the headlights look.Bottom line, a dev who can't administer his own machine is not a real geek who grew up building machines and learning everything about them because he loves it - they are the product of Computer Science classes and know the bare minimum they need to know to put code together and make it do stuff.
Someone who decided at age 20 "Uhh, software devs make good money, I'll do that.
"  I don't want any devs like that on my team.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606544</id>
	<title>Is this even an issue anymore?</title>
	<author>grasshoppa</author>
	<datestamp>1262281920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You setup a development environment, which is at worst firewalled off from the production network, but ideally completely isolated.  Then give the developers full reign to do as they need to do get the job done.</p></htmltext>
<tokenext>You setup a development environment , which is at worst firewalled off from the production network , but ideally completely isolated .
Then give the developers full reign to do as they need to do get the job done .</tokentext>
<sentencetext>You setup a development environment, which is at worst firewalled off from the production network, but ideally completely isolated.
Then give the developers full reign to do as they need to do get the job done.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612642</id>
	<title>Re:Who is driving?</title>
	<author>symbolic</author>
	<datestamp>1262286240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>Development should be done using dedicated development systems that replicate the production environment. I have seen way to many problems and delays arise because the developer's setup on his personal laptops didn't exactly replicate the productions deployment environment.</i></p><p>I have to disagree. That's what a staging environment is for. Your analogy would be tantamount to making a car manufacturer build every automobile sitting in the passenger seat with the door closed.</p></htmltext>
<tokenext>Development should be done using dedicated development systems that replicate the production environment .
I have seen way to many problems and delays arise because the developer 's setup on his personal laptops did n't exactly replicate the productions deployment environment.I have to disagree .
That 's what a staging environment is for .
Your analogy would be tantamount to making a car manufacturer build every automobile sitting in the passenger seat with the door closed .</tokentext>
<sentencetext>Development should be done using dedicated development systems that replicate the production environment.
I have seen way to many problems and delays arise because the developer's setup on his personal laptops didn't exactly replicate the productions deployment environment.I have to disagree.
That's what a staging environment is for.
Your analogy would be tantamount to making a car manufacturer build every automobile sitting in the passenger seat with the door closed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607496</id>
	<title>Developers need admin rights for their machines</title>
	<author>Orion Blastar</author>
	<datestamp>1262285280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>if not some of the development tools won't work and nor can they install service packs and bug fixes for their system to test them out.</p><p>If I as a developer have to wait for an admin to install the bug fixes and service packs for me, I'll get less work done and won't be able to function. Also VB 6.0 controls will refuse to work unless I am admin meaning I can no longer use some controls to program with.</p><p>I am not asking for admin rights on the server, just my own PC I am assigned to develop on. Jobs I had where they took away admin rights for my local PC were very hard as they tied one of my hands behind my back and made it hard to work.</p></htmltext>
<tokenext>if not some of the development tools wo n't work and nor can they install service packs and bug fixes for their system to test them out.If I as a developer have to wait for an admin to install the bug fixes and service packs for me , I 'll get less work done and wo n't be able to function .
Also VB 6.0 controls will refuse to work unless I am admin meaning I can no longer use some controls to program with.I am not asking for admin rights on the server , just my own PC I am assigned to develop on .
Jobs I had where they took away admin rights for my local PC were very hard as they tied one of my hands behind my back and made it hard to work .</tokentext>
<sentencetext>if not some of the development tools won't work and nor can they install service packs and bug fixes for their system to test them out.If I as a developer have to wait for an admin to install the bug fixes and service packs for me, I'll get less work done and won't be able to function.
Also VB 6.0 controls will refuse to work unless I am admin meaning I can no longer use some controls to program with.I am not asking for admin rights on the server, just my own PC I am assigned to develop on.
Jobs I had where they took away admin rights for my local PC were very hard as they tied one of my hands behind my back and made it hard to work.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607910</id>
	<title>We do !</title>
	<author>Dolphinzilla</author>
	<datestamp>1262286900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I work for a very large DoD contractor - we are given local admin rights as software developers - note these are only for the local machine.</p></htmltext>
<tokenext>I work for a very large DoD contractor - we are given local admin rights as software developers - note these are only for the local machine .</tokentext>
<sentencetext>I work for a very large DoD contractor - we are given local admin rights as software developers - note these are only for the local machine.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613026</id>
	<title>Re:Yes, because I'm not a masochist</title>
	<author>Anonymous</author>
	<datestamp>1230805080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This. I'm a developer and the environment I'm most happy in is one where I'm admin, I can install what I like, but on the understanding that I get no trouble-shooting if something screws up (well, unless it's obvious).</p><p>Being the lazy dev that I am, I actually used to get the computer re-imaged every 6 months or so just to clean it up<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>This .
I 'm a developer and the environment I 'm most happy in is one where I 'm admin , I can install what I like , but on the understanding that I get no trouble-shooting if something screws up ( well , unless it 's obvious ) .Being the lazy dev that I am , I actually used to get the computer re-imaged every 6 months or so just to clean it up : )</tokentext>
<sentencetext>This.
I'm a developer and the environment I'm most happy in is one where I'm admin, I can install what I like, but on the understanding that I get no trouble-shooting if something screws up (well, unless it's obvious).Being the lazy dev that I am, I actually used to get the computer re-imaged every 6 months or so just to clean it up :)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606486</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609040</id>
	<title>Re:You damn well should</title>
	<author>jcoy42</author>
	<datestamp>1262292660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Give me a shell on a unix machine somewhere with a compiler, and I can guarantee almost nothing I do will compromise the integrity of said machine... up until I run sudo somethingorother</p></div><p>Apparently you have never taught a *nix class on how to use fork().</p></div>
	</htmltext>
<tokenext>Give me a shell on a unix machine somewhere with a compiler , and I can guarantee almost nothing I do will compromise the integrity of said machine... up until I run sudo somethingorotherApparently you have never taught a * nix class on how to use fork ( ) .</tokentext>
<sentencetext>Give me a shell on a unix machine somewhere with a compiler, and I can guarantee almost nothing I do will compromise the integrity of said machine... up until I run sudo somethingorotherApparently you have never taught a *nix class on how to use fork().
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609196</id>
	<title>no, but passwords are trivial</title>
	<author>Anonymous</author>
	<datestamp>1262250420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>no local admin rights, but the admins are stupid enough to use default admin shares. the local admin account password can be cracked in a matter of seconds and it's the same on all machines, leaving the whole network open to great pillaging and plundering.</p></htmltext>
<tokenext>no local admin rights , but the admins are stupid enough to use default admin shares .
the local admin account password can be cracked in a matter of seconds and it 's the same on all machines , leaving the whole network open to great pillaging and plundering .</tokentext>
<sentencetext>no local admin rights, but the admins are stupid enough to use default admin shares.
the local admin account password can be cracked in a matter of seconds and it's the same on all machines, leaving the whole network open to great pillaging and plundering.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618654</id>
	<title>Depressing landscape.</title>
	<author>jotaeleemeese</author>
	<datestamp>1230823080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It is no wonder that computing is the cesspool of insecurity it is, when most people in this thread find all kind of inane justifications in order to jeopardize the companies they are supposed to be serving in a professional manner.</p><p>Many people on this thread claim that they can't do their job without admin rights of some kind, which is patently untrue:</p><p>- Do you need to install an application? Then ask your Sys Admin. Too much work for them? Then reorganize how the Sys Admin deals with development support. Ain't going to happen? You are working in the wrong company then.</p><p>-I need to install X,Y or Z application, library, whatever.: No, you don't. Refer to the list of approved software and use that, if some new software is needed then follow the procedure to get it included into the list. The procedure to get hold of new software is too long? Fix the procedure, you installing random stuff from the net is not the fix.</p><p>- I need a program that requires elevated privileges!: use a different program, the one you are using now does not care about the safety of your IT infrastructure, if this is not possible pick the damn phone and ask the software provider to fix the program, if they don't fix it expose them t public ridicule. Again, you don't need privileged access.</p><p>I have worked in many shops, both big and small, where people were reluctant to let the privileged account go  (the real reasons were normally more mundane: could not download the latest and greatest games, could not use an arcane utility that was unmaintainable, you name it). Once appropriate policies and levels of support were in place the need for privileged local accounts became non existent (and the instances of security problems decreased dramatically).</p><p>Giving privileges to anybody but the sys admins is a sure way to create nasty problems.</p></htmltext>
<tokenext>It is no wonder that computing is the cesspool of insecurity it is , when most people in this thread find all kind of inane justifications in order to jeopardize the companies they are supposed to be serving in a professional manner.Many people on this thread claim that they ca n't do their job without admin rights of some kind , which is patently untrue : - Do you need to install an application ?
Then ask your Sys Admin .
Too much work for them ?
Then reorganize how the Sys Admin deals with development support .
Ai n't going to happen ?
You are working in the wrong company then.-I need to install X,Y or Z application , library , whatever .
: No , you do n't .
Refer to the list of approved software and use that , if some new software is needed then follow the procedure to get it included into the list .
The procedure to get hold of new software is too long ?
Fix the procedure , you installing random stuff from the net is not the fix.- I need a program that requires elevated privileges !
: use a different program , the one you are using now does not care about the safety of your IT infrastructure , if this is not possible pick the damn phone and ask the software provider to fix the program , if they do n't fix it expose them t public ridicule .
Again , you do n't need privileged access.I have worked in many shops , both big and small , where people were reluctant to let the privileged account go ( the real reasons were normally more mundane : could not download the latest and greatest games , could not use an arcane utility that was unmaintainable , you name it ) .
Once appropriate policies and levels of support were in place the need for privileged local accounts became non existent ( and the instances of security problems decreased dramatically ) .Giving privileges to anybody but the sys admins is a sure way to create nasty problems .</tokentext>
<sentencetext>It is no wonder that computing is the cesspool of insecurity it is, when most people in this thread find all kind of inane justifications in order to jeopardize the companies they are supposed to be serving in a professional manner.Many people on this thread claim that they can't do their job without admin rights of some kind, which is patently untrue:- Do you need to install an application?
Then ask your Sys Admin.
Too much work for them?
Then reorganize how the Sys Admin deals with development support.
Ain't going to happen?
You are working in the wrong company then.-I need to install X,Y or Z application, library, whatever.
: No, you don't.
Refer to the list of approved software and use that, if some new software is needed then follow the procedure to get it included into the list.
The procedure to get hold of new software is too long?
Fix the procedure, you installing random stuff from the net is not the fix.- I need a program that requires elevated privileges!
: use a different program, the one you are using now does not care about the safety of your IT infrastructure, if this is not possible pick the damn phone and ask the software provider to fix the program, if they don't fix it expose them t public ridicule.
Again, you don't need privileged access.I have worked in many shops, both big and small, where people were reluctant to let the privileged account go  (the real reasons were normally more mundane: could not download the latest and greatest games, could not use an arcane utility that was unmaintainable, you name it).
Once appropriate policies and levels of support were in place the need for privileged local accounts became non existent (and the instances of security problems decreased dramatically).Giving privileges to anybody but the sys admins is a sure way to create nasty problems.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613210</id>
	<title>Yes and no</title>
	<author>RighteousMeh</author>
	<datestamp>1230809100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>At my company we've been developing software for solaris for over 10 years. We develop and do some testing on solaris workstations, without having root privileges. This has been working fine for a long time. If you need some new software installed, it is still possible to do it without being root and if you need something installed for everyone, it is better to ask the admins to install it, because they will also maintain it for you.
</p><p>
Lately we've be using Windows as well. Every Windows developer machine comes with local admin rights, because it would be too difficult to get anything done without it.
</p></htmltext>
<tokenext>At my company we 've been developing software for solaris for over 10 years .
We develop and do some testing on solaris workstations , without having root privileges .
This has been working fine for a long time .
If you need some new software installed , it is still possible to do it without being root and if you need something installed for everyone , it is better to ask the admins to install it , because they will also maintain it for you .
Lately we 've be using Windows as well .
Every Windows developer machine comes with local admin rights , because it would be too difficult to get anything done without it .</tokentext>
<sentencetext>At my company we've been developing software for solaris for over 10 years.
We develop and do some testing on solaris workstations, without having root privileges.
This has been working fine for a long time.
If you need some new software installed, it is still possible to do it without being root and if you need something installed for everyone, it is better to ask the admins to install it, because they will also maintain it for you.
Lately we've be using Windows as well.
Every Windows developer machine comes with local admin rights, because it would be too difficult to get anything done without it.
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606552</id>
	<title>This is how we do it</title>
	<author>bogaboga</author>
	<datestamp>1262281980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p> If not, how do you handle tasks like debugging, testing installations, or installing updated development tools that aren't a part of the standard corporate workstation?'</p></div><p>I work for a major insurance company. We work as a team with external personnel. There is always tension and in most cases, their personnel of comparable rank to ours earn more, appear to have more power over what we can or cannot do.</p></div>
	</htmltext>
<tokenext>If not , how do you handle tasks like debugging , testing installations , or installing updated development tools that are n't a part of the standard corporate workstation ?
'I work for a major insurance company .
We work as a team with external personnel .
There is always tension and in most cases , their personnel of comparable rank to ours earn more , appear to have more power over what we can or can not do .</tokentext>
<sentencetext> If not, how do you handle tasks like debugging, testing installations, or installing updated development tools that aren't a part of the standard corporate workstation?
'I work for a major insurance company.
We work as a team with external personnel.
There is always tension and in most cases, their personnel of comparable rank to ours earn more, appear to have more power over what we can or cannot do.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607454</id>
	<title>Yes, they have admin rights</title>
	<author>ErichTheRed</author>
	<datestamp>1262285160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm a client systems integration guy, so IMO it would be a good thing to not give developers admin rights by default. In reality though, they do have them. In a bureaucratic IT world, it just makes them more productive. We've been trying to eliminate admin-by-default for ages, but the supporting stuff isn't in place yet.</p><p>Modern versions of Windows do work a lot better with limited rights, and Microsoft has done a decent job in trying to make the limited-user experience a little more transparent. In a perfect world (which I don't work in,) all software distribution, upgrades and removal would be fully automated through SMS or something similar. Every relevant system setting someone would want to change would be open to non-admins. However, if you work in previous versions of WIndows (XP, 2003, etc,) then some key things a developer might want to do (i.e. start and stop services, install drivers and make registry changes,) require elevated privileges or relaxing system security. Plus, even with compatibility hacks, some older software just won't run reliably without privileges.</p><p>I think developer accounts should be limited rights by default, but they should be allowed access to a privileged account for installations and system changes. The caveat is that developers need to realize they're writing software that won't be used by admins, and have to test anything they write in a limited rights environment. I can't tell you how many (large) vendors I've called while trying to integrate client software into our limited-rights environment. Some are totally shocked that we even have users running without full rights. I've found this to be the case most often with "niche" vendors who aren't making a consumer product, and training companies. The latter seem to just assume that everyone has full control over their web browser settings, can install whatever plugins they want, etc.</p><p>One of the ways we're working around this is using virtual machines for lab work. The developers can mess these up all they want, and restore them if something happens. The catch is that they don't have direct Internet access, which is the main reason why admin rights are so dangerous.</p><p>The problem with running admin-by-default is the amount of damage someone can do, even unintentionally, by using an account that has rights to make any changes. How many people do you know that actually read the UAC or download warning prompts while they're browsing the web?</p></htmltext>
<tokenext>I 'm a client systems integration guy , so IMO it would be a good thing to not give developers admin rights by default .
In reality though , they do have them .
In a bureaucratic IT world , it just makes them more productive .
We 've been trying to eliminate admin-by-default for ages , but the supporting stuff is n't in place yet.Modern versions of Windows do work a lot better with limited rights , and Microsoft has done a decent job in trying to make the limited-user experience a little more transparent .
In a perfect world ( which I do n't work in , ) all software distribution , upgrades and removal would be fully automated through SMS or something similar .
Every relevant system setting someone would want to change would be open to non-admins .
However , if you work in previous versions of WIndows ( XP , 2003 , etc , ) then some key things a developer might want to do ( i.e .
start and stop services , install drivers and make registry changes , ) require elevated privileges or relaxing system security .
Plus , even with compatibility hacks , some older software just wo n't run reliably without privileges.I think developer accounts should be limited rights by default , but they should be allowed access to a privileged account for installations and system changes .
The caveat is that developers need to realize they 're writing software that wo n't be used by admins , and have to test anything they write in a limited rights environment .
I ca n't tell you how many ( large ) vendors I 've called while trying to integrate client software into our limited-rights environment .
Some are totally shocked that we even have users running without full rights .
I 've found this to be the case most often with " niche " vendors who are n't making a consumer product , and training companies .
The latter seem to just assume that everyone has full control over their web browser settings , can install whatever plugins they want , etc.One of the ways we 're working around this is using virtual machines for lab work .
The developers can mess these up all they want , and restore them if something happens .
The catch is that they do n't have direct Internet access , which is the main reason why admin rights are so dangerous.The problem with running admin-by-default is the amount of damage someone can do , even unintentionally , by using an account that has rights to make any changes .
How many people do you know that actually read the UAC or download warning prompts while they 're browsing the web ?</tokentext>
<sentencetext>I'm a client systems integration guy, so IMO it would be a good thing to not give developers admin rights by default.
In reality though, they do have them.
In a bureaucratic IT world, it just makes them more productive.
We've been trying to eliminate admin-by-default for ages, but the supporting stuff isn't in place yet.Modern versions of Windows do work a lot better with limited rights, and Microsoft has done a decent job in trying to make the limited-user experience a little more transparent.
In a perfect world (which I don't work in,) all software distribution, upgrades and removal would be fully automated through SMS or something similar.
Every relevant system setting someone would want to change would be open to non-admins.
However, if you work in previous versions of WIndows (XP, 2003, etc,) then some key things a developer might want to do (i.e.
start and stop services, install drivers and make registry changes,) require elevated privileges or relaxing system security.
Plus, even with compatibility hacks, some older software just won't run reliably without privileges.I think developer accounts should be limited rights by default, but they should be allowed access to a privileged account for installations and system changes.
The caveat is that developers need to realize they're writing software that won't be used by admins, and have to test anything they write in a limited rights environment.
I can't tell you how many (large) vendors I've called while trying to integrate client software into our limited-rights environment.
Some are totally shocked that we even have users running without full rights.
I've found this to be the case most often with "niche" vendors who aren't making a consumer product, and training companies.
The latter seem to just assume that everyone has full control over their web browser settings, can install whatever plugins they want, etc.One of the ways we're working around this is using virtual machines for lab work.
The developers can mess these up all they want, and restore them if something happens.
The catch is that they don't have direct Internet access, which is the main reason why admin rights are so dangerous.The problem with running admin-by-default is the amount of damage someone can do, even unintentionally, by using an account that has rights to make any changes.
How many people do you know that actually read the UAC or download warning prompts while they're browsing the web?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606822</id>
	<title>Re:Hell no.</title>
	<author>iSzabo</author>
	<datestamp>1262282820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You make a good point about developers having admin power on production machines; which could be extended to showing (one reason) why dev boxes should not be running production code (there was an article a while ago about testing on production boxes that would be relevant.)</p><p>Do you feel the same way about developers having admin rights on their development workstations (which I think is what others are commenting about)?</p></htmltext>
<tokenext>You make a good point about developers having admin power on production machines ; which could be extended to showing ( one reason ) why dev boxes should not be running production code ( there was an article a while ago about testing on production boxes that would be relevant .
) Do you feel the same way about developers having admin rights on their development workstations ( which I think is what others are commenting about ) ?</tokentext>
<sentencetext>You make a good point about developers having admin power on production machines; which could be extended to showing (one reason) why dev boxes should not be running production code (there was an article a while ago about testing on production boxes that would be relevant.
)Do you feel the same way about developers having admin rights on their development workstations (which I think is what others are commenting about)?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612206</id>
	<title>Re:Information Security 101</title>
	<author>incongruency</author>
	<datestamp>1262278020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>But what if their tasks with no work-arounds are what they do all day long?  They'll stay logged in as administrator all the time.  So why even bother with the limited account in that case?</htmltext>
<tokenext>But what if their tasks with no work-arounds are what they do all day long ?
They 'll stay logged in as administrator all the time .
So why even bother with the limited account in that case ?</tokentext>
<sentencetext>But what if their tasks with no work-arounds are what they do all day long?
They'll stay logged in as administrator all the time.
So why even bother with the limited account in that case?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607004</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30674070</id>
	<title>Re:Virtualization is your Friend</title>
	<author>Anonymous</author>
	<datestamp>1231232700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Computer games, and similar visualization software.</p></htmltext>
<tokenext>Computer games , and similar visualization software .</tokentext>
<sentencetext>Computer games, and similar visualization software.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30649946</id>
	<title>Re:What it REALLY comes down to</title>
	<author>xZgf6xHx2uhoAj9D</author>
	<datestamp>1231081140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>For the same reason that most other operating systems, including most flavors of linux, requires admin rights to install software.</p></div> </blockquote><p>Depending on what you mean by "install". I can't think of a single problem I've had going the "./configure --prefix=$HOME ; make ; make install" route.</p></div>
	</htmltext>
<tokenext>For the same reason that most other operating systems , including most flavors of linux , requires admin rights to install software .
Depending on what you mean by " install " .
I ca n't think of a single problem I 've had going the " ./configure --prefix = $ HOME ; make ; make install " route .</tokentext>
<sentencetext>For the same reason that most other operating systems, including most flavors of linux, requires admin rights to install software.
Depending on what you mean by "install".
I can't think of a single problem I've had going the "./configure --prefix=$HOME ; make ; make install" route.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611864</id>
	<title>Re:Virtualization is your Friend</title>
	<author>CodeBuster</author>
	<datestamp>1262272740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It is not always a question of need, but sometimes one of simply accommodating a reasonable wish by developers for <i>complete</i> control over their workstations. In my experience, most developers tend to think of their workstation, configurations, and software in much the same way that a master craftsman would his personal tools. Developers are generally logical and practical people, so if you indulge them on their own workstations, servers, and subnets then they will usually understand and respect your decision as a system administrator to firewall off those parts of the network (i.e. "devland") from the rest of the production environment. Personally, my sysadmin loves the fact that I maintain my own workstation, servers, and (small) subnets. I haven't caused him any extra work in the three years since we began the arrangement. Now, I understand that not every corporate user is willing or even able to handle this level of IT responsibility; but IMHO devs are usually good to go with taking care of their own so why not make them happy?</htmltext>
<tokenext>It is not always a question of need , but sometimes one of simply accommodating a reasonable wish by developers for complete control over their workstations .
In my experience , most developers tend to think of their workstation , configurations , and software in much the same way that a master craftsman would his personal tools .
Developers are generally logical and practical people , so if you indulge them on their own workstations , servers , and subnets then they will usually understand and respect your decision as a system administrator to firewall off those parts of the network ( i.e .
" devland " ) from the rest of the production environment .
Personally , my sysadmin loves the fact that I maintain my own workstation , servers , and ( small ) subnets .
I have n't caused him any extra work in the three years since we began the arrangement .
Now , I understand that not every corporate user is willing or even able to handle this level of IT responsibility ; but IMHO devs are usually good to go with taking care of their own so why not make them happy ?</tokentext>
<sentencetext>It is not always a question of need, but sometimes one of simply accommodating a reasonable wish by developers for complete control over their workstations.
In my experience, most developers tend to think of their workstation, configurations, and software in much the same way that a master craftsman would his personal tools.
Developers are generally logical and practical people, so if you indulge them on their own workstations, servers, and subnets then they will usually understand and respect your decision as a system administrator to firewall off those parts of the network (i.e.
"devland") from the rest of the production environment.
Personally, my sysadmin loves the fact that I maintain my own workstation, servers, and (small) subnets.
I haven't caused him any extra work in the three years since we began the arrangement.
Now, I understand that not every corporate user is willing or even able to handle this level of IT responsibility; but IMHO devs are usually good to go with taking care of their own so why not make them happy?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612024</id>
	<title>yes</title>
	<author>wardk</author>
	<datestamp>1262275080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>it's simply impossible to do your job otherwise</p></htmltext>
<tokenext>it 's simply impossible to do your job otherwise</tokentext>
<sentencetext>it's simply impossible to do your job otherwise</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607196</id>
	<title>local admin rights</title>
	<author>Anonymous</author>
	<datestamp>1262284260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>We give developers local admin rights to dev and test, for QA and production environments all changes go through change control. Like others have said I have said I don't trust developers either. Most are clueless, in over 15 years I've only met one developer that actually understands systems administration.</p></htmltext>
<tokenext>We give developers local admin rights to dev and test , for QA and production environments all changes go through change control .
Like others have said I have said I do n't trust developers either .
Most are clueless , in over 15 years I 've only met one developer that actually understands systems administration .</tokentext>
<sentencetext>We give developers local admin rights to dev and test, for QA and production environments all changes go through change control.
Like others have said I have said I don't trust developers either.
Most are clueless, in over 15 years I've only met one developer that actually understands systems administration.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480</id>
	<title>You damn well should</title>
	<author>QuoteMstr</author>
	<datestamp>1262281740000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Any developer who can't competently administer his own machine is incompetent. The kind of rigorous thinking required is identical. I'd be highly reluctant to work at a place that didn't let me install and manage the software packages I needed to do my job. I've used hundreds of small programs to help me in my work, along with kernel debuggers and other tools that require administrative privileges. Having to ask for approval and installation assistance for each of them would have been impractical.</p><p>If you're worried about developers screwing up their boxes, why aren't you <i>more</i> worried about these developers screwing up the their code?!</p></htmltext>
<tokenext>Any developer who ca n't competently administer his own machine is incompetent .
The kind of rigorous thinking required is identical .
I 'd be highly reluctant to work at a place that did n't let me install and manage the software packages I needed to do my job .
I 've used hundreds of small programs to help me in my work , along with kernel debuggers and other tools that require administrative privileges .
Having to ask for approval and installation assistance for each of them would have been impractical.If you 're worried about developers screwing up their boxes , why are n't you more worried about these developers screwing up the their code ?
!</tokentext>
<sentencetext>Any developer who can't competently administer his own machine is incompetent.
The kind of rigorous thinking required is identical.
I'd be highly reluctant to work at a place that didn't let me install and manage the software packages I needed to do my job.
I've used hundreds of small programs to help me in my work, along with kernel debuggers and other tools that require administrative privileges.
Having to ask for approval and installation assistance for each of them would have been impractical.If you're worried about developers screwing up their boxes, why aren't you more worried about these developers screwing up the their code?
!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606944</id>
	<title>yes</title>
	<author>pak9rabid</author>
	<datestamp>1262283240000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>The entire development team where I work has full admin privileges on their local workstations.  Not giving them that would be disastrous for productivity...</htmltext>
<tokenext>The entire development team where I work has full admin privileges on their local workstations .
Not giving them that would be disastrous for productivity.. .</tokentext>
<sentencetext>The entire development team where I work has full admin privileges on their local workstations.
Not giving them that would be disastrous for productivity...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607446</id>
	<title>From pretty much all places I've been</title>
	<author>Kjella</author>
	<datestamp>1262285160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>...as a consultant then yes. In fact, often the whole IT department. The desktop guys will wipe and image your installation if you trash it and there's usually installation packages for the main development tools, but otherwise you get no support. It's assumed that if you work in IT you either know what you're doing, or at least you have the good sense to not break what you don't know.</p><p>Why? Simply the rate of tools/users, which makes it very inefficient to do it any other way. For example, I regularly locally use an import/export tool which is only useful to 2-3 people in the whole company and there's a new version with every point release of the server. File a submission form and have an installation package created? Wait for one of the blessed system administrators to install it, who'll do nothing but run around and be internal overhead? Forget it, you trust me to manage a server used by hundreds of people but not my lone box? It's like handing me scalpels with one hand and safety scissors with the other. One thing I've come to accept though is web filters, it's amazing what people will do at work. I don't pretend to be a saint or anything close, but the worst I tend to do at work is read slashdot - the rest happens on my time, my internet connection and my own PC.</p></htmltext>
<tokenext>...as a consultant then yes .
In fact , often the whole IT department .
The desktop guys will wipe and image your installation if you trash it and there 's usually installation packages for the main development tools , but otherwise you get no support .
It 's assumed that if you work in IT you either know what you 're doing , or at least you have the good sense to not break what you do n't know.Why ?
Simply the rate of tools/users , which makes it very inefficient to do it any other way .
For example , I regularly locally use an import/export tool which is only useful to 2-3 people in the whole company and there 's a new version with every point release of the server .
File a submission form and have an installation package created ?
Wait for one of the blessed system administrators to install it , who 'll do nothing but run around and be internal overhead ?
Forget it , you trust me to manage a server used by hundreds of people but not my lone box ?
It 's like handing me scalpels with one hand and safety scissors with the other .
One thing I 've come to accept though is web filters , it 's amazing what people will do at work .
I do n't pretend to be a saint or anything close , but the worst I tend to do at work is read slashdot - the rest happens on my time , my internet connection and my own PC .</tokentext>
<sentencetext>...as a consultant then yes.
In fact, often the whole IT department.
The desktop guys will wipe and image your installation if you trash it and there's usually installation packages for the main development tools, but otherwise you get no support.
It's assumed that if you work in IT you either know what you're doing, or at least you have the good sense to not break what you don't know.Why?
Simply the rate of tools/users, which makes it very inefficient to do it any other way.
For example, I regularly locally use an import/export tool which is only useful to 2-3 people in the whole company and there's a new version with every point release of the server.
File a submission form and have an installation package created?
Wait for one of the blessed system administrators to install it, who'll do nothing but run around and be internal overhead?
Forget it, you trust me to manage a server used by hundreds of people but not my lone box?
It's like handing me scalpels with one hand and safety scissors with the other.
One thing I've come to accept though is web filters, it's amazing what people will do at work.
I don't pretend to be a saint or anything close, but the worst I tend to do at work is read slashdot - the rest happens on my time, my internet connection and my own PC.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607544</id>
	<title>Re:You damn well should</title>
	<author>seanadams.com</author>
	<datestamp>1262285520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>Give me a shell on a unix machine somewhere with a compiler, and I can guarantee almost nothing I do will compromise the integrity of said machine... up until I run sudo somethingorother</i> </p><p>That's great, but how are you going to use your unix shell account to develop WINDOWS SOFTWARE?<nobr> <wbr></nobr>... that was the whole point of the original question.</p></htmltext>
<tokenext>Give me a shell on a unix machine somewhere with a compiler , and I can guarantee almost nothing I do will compromise the integrity of said machine... up until I run sudo somethingorother That 's great , but how are you going to use your unix shell account to develop WINDOWS SOFTWARE ?
... that was the whole point of the original question .</tokentext>
<sentencetext>Give me a shell on a unix machine somewhere with a compiler, and I can guarantee almost nothing I do will compromise the integrity of said machine... up until I run sudo somethingorother That's great, but how are you going to use your unix shell account to develop WINDOWS SOFTWARE?
... that was the whole point of the original question.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611700</id>
	<title>it's all about tradeoffs</title>
	<author>bingbong</author>
	<datestamp>1262270400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm the IT security director for an international company (35+ countries). We have a variety of user / developer and security requirements.</p><p>We do not give our developers local admin on there workstations. However, we do give them VMs to develop on. This way, if they screw something up (which happens a LOT), they can go back a snapshot or two and fix things.</p><p>Incidentally, the test environments have very restricted security permissions - they have to be able to run on the federal desktop core configuration - so we encounter a lot bugs because developers insist on running their app with admin rights.</p><p>if we could train developers better, and have IT admins that understand both sides of the issues - things get better. It works pretty well for my company.</p></htmltext>
<tokenext>I 'm the IT security director for an international company ( 35 + countries ) .
We have a variety of user / developer and security requirements.We do not give our developers local admin on there workstations .
However , we do give them VMs to develop on .
This way , if they screw something up ( which happens a LOT ) , they can go back a snapshot or two and fix things.Incidentally , the test environments have very restricted security permissions - they have to be able to run on the federal desktop core configuration - so we encounter a lot bugs because developers insist on running their app with admin rights.if we could train developers better , and have IT admins that understand both sides of the issues - things get better .
It works pretty well for my company .</tokentext>
<sentencetext>I'm the IT security director for an international company (35+ countries).
We have a variety of user / developer and security requirements.We do not give our developers local admin on there workstations.
However, we do give them VMs to develop on.
This way, if they screw something up (which happens a LOT), they can go back a snapshot or two and fix things.Incidentally, the test environments have very restricted security permissions - they have to be able to run on the federal desktop core configuration - so we encounter a lot bugs because developers insist on running their app with admin rights.if we could train developers better, and have IT admins that understand both sides of the issues - things get better.
It works pretty well for my company.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607232</id>
	<title>Re:Yes</title>
	<author>Anonymous</author>
	<datestamp>1262284320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Yes. Both at the company I work for and the regional bank I developed for a couple years ago. It is impossible, IMO, to do many functions without these privileges.</p></div><p>What functions do you need elevated rights for?  Seriously, I haven't programmed in ages and even then it was for Unix, so I never had admin rights on my development platform.  It didn't seem to hurt my productivity.</p><p>Now, I can see if you're doing driver or kernel development.  And for testing installation of software.  But for most work?  I don't see it.  And for web development?  Not at all.</p></div>
	</htmltext>
<tokenext>Yes .
Both at the company I work for and the regional bank I developed for a couple years ago .
It is impossible , IMO , to do many functions without these privileges.What functions do you need elevated rights for ?
Seriously , I have n't programmed in ages and even then it was for Unix , so I never had admin rights on my development platform .
It did n't seem to hurt my productivity.Now , I can see if you 're doing driver or kernel development .
And for testing installation of software .
But for most work ?
I do n't see it .
And for web development ?
Not at all .</tokentext>
<sentencetext>Yes.
Both at the company I work for and the regional bank I developed for a couple years ago.
It is impossible, IMO, to do many functions without these privileges.What functions do you need elevated rights for?
Seriously, I haven't programmed in ages and even then it was for Unix, so I never had admin rights on my development platform.
It didn't seem to hurt my productivity.Now, I can see if you're doing driver or kernel development.
And for testing installation of software.
But for most work?
I don't see it.
And for web development?
Not at all.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609332</id>
	<title>Mordoc Runs IT here</title>
	<author>SaffronMiner</author>
	<datestamp>1262251320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>
<p>Mordoc Rules: <a href="http://dilbert.com/strips/?CharIDs=15&amp;After=01/01/1996&amp;Before=12/31/2009&amp;Order=s.DateStrip+DESC&amp;PerPage=50&amp;x=23&amp;y=9&amp;CharFilter=Any" title="dilbert.com" rel="nofollow">http://dilbert.com/strips/?CharIDs=15&amp;After=01/01/1996&amp;Before=12/31/2009&amp;Order=s.DateStrip+DESC&amp;PerPage=50&amp;x=23&amp;y=9&amp;CharFilter=Any</a> [dilbert.com] </p><p>Really several of those have happened here, and a couple of more from Dilbert[TM] that don't show up in that link.  I thought Dilbert[TM]
was meant to be a cartoon, not a documentary?</p><p>IT controls the virus checkers on all the machines, but they never keep them up to date
for Windows, nor alow us to update them.  "Linux is just a Toy" is a direct quote from IT.  The other day a colleague
told IT that someone had to move down from Mac to Windows, and ITs reply was "at least they
didn't take even more steps backwards to Linux", but I digress.</p><p>After IT discovered the Virus, they declared, without any evidence, all Open Source Browsers,
like Firefox and Opera, and Email programs must be ameliorated from all company computers,
or you would be terminated.  They then decreed that in the name of security only IE6 and
Outlook would be acceptable for Internet access for any reason (so much for using any other ports, those
do not exist per IT).  Makes lots of sense to force the usage of the two most attacked programs in the history of Mankind
in the name of security.  I've about given up on Internet at work and do most of what I need at home now.</p><p>IT always says "we must protect The Server".  If The (Windows) Server is so vulnerable that it needs
so much protection, why do they keep using it?  I've asked to be removed from The Serve as I don't use it
to do my job other than for backups, and IT says my source code backups are to large and want them removed (WTF?).</p><p>I develop Embedded Systems.  Right now I'm trying to write a USB driver for a AVR, that has to
work with Windows, but IT says I don't need Admin Rights.  Boss says "do what IT says".  Guess I'll just tell the
customers "sorry I could not test this, talk to the boss or IT if it does not work", as I'll
have no idea if it works. Its a small company, telling me to talk to someone higher up won't help. Resume anyone?</p></div>
	</htmltext>
<tokenext>Mordoc Rules : http : //dilbert.com/strips/ ? CharIDs = 15&amp;After = 01/01/1996&amp;Before = 12/31/2009&amp;Order = s.DateStrip + DESC&amp;PerPage = 50&amp;x = 23&amp;y = 9&amp;CharFilter = Any [ dilbert.com ] Really several of those have happened here , and a couple of more from Dilbert [ TM ] that do n't show up in that link .
I thought Dilbert [ TM ] was meant to be a cartoon , not a documentary ? IT controls the virus checkers on all the machines , but they never keep them up to date for Windows , nor alow us to update them .
" Linux is just a Toy " is a direct quote from IT .
The other day a colleague told IT that someone had to move down from Mac to Windows , and ITs reply was " at least they did n't take even more steps backwards to Linux " , but I digress.After IT discovered the Virus , they declared , without any evidence , all Open Source Browsers , like Firefox and Opera , and Email programs must be ameliorated from all company computers , or you would be terminated .
They then decreed that in the name of security only IE6 and Outlook would be acceptable for Internet access for any reason ( so much for using any other ports , those do not exist per IT ) .
Makes lots of sense to force the usage of the two most attacked programs in the history of Mankind in the name of security .
I 've about given up on Internet at work and do most of what I need at home now.IT always says " we must protect The Server " .
If The ( Windows ) Server is so vulnerable that it needs so much protection , why do they keep using it ?
I 've asked to be removed from The Serve as I do n't use it to do my job other than for backups , and IT says my source code backups are to large and want them removed ( WTF ?
) .I develop Embedded Systems .
Right now I 'm trying to write a USB driver for a AVR , that has to work with Windows , but IT says I do n't need Admin Rights .
Boss says " do what IT says " .
Guess I 'll just tell the customers " sorry I could not test this , talk to the boss or IT if it does not work " , as I 'll have no idea if it works .
Its a small company , telling me to talk to someone higher up wo n't help .
Resume anyone ?</tokentext>
<sentencetext>
Mordoc Rules: http://dilbert.com/strips/?CharIDs=15&amp;After=01/01/1996&amp;Before=12/31/2009&amp;Order=s.DateStrip+DESC&amp;PerPage=50&amp;x=23&amp;y=9&amp;CharFilter=Any [dilbert.com] Really several of those have happened here, and a couple of more from Dilbert[TM] that don't show up in that link.
I thought Dilbert[TM]
was meant to be a cartoon, not a documentary?IT controls the virus checkers on all the machines, but they never keep them up to date
for Windows, nor alow us to update them.
"Linux is just a Toy" is a direct quote from IT.
The other day a colleague
told IT that someone had to move down from Mac to Windows, and ITs reply was "at least they
didn't take even more steps backwards to Linux", but I digress.After IT discovered the Virus, they declared, without any evidence, all Open Source Browsers,
like Firefox and Opera, and Email programs must be ameliorated from all company computers,
or you would be terminated.
They then decreed that in the name of security only IE6 and
Outlook would be acceptable for Internet access for any reason (so much for using any other ports, those
do not exist per IT).
Makes lots of sense to force the usage of the two most attacked programs in the history of Mankind
in the name of security.
I've about given up on Internet at work and do most of what I need at home now.IT always says "we must protect The Server".
If The (Windows) Server is so vulnerable that it needs
so much protection, why do they keep using it?
I've asked to be removed from The Serve as I don't use it
to do my job other than for backups, and IT says my source code backups are to large and want them removed (WTF?
).I develop Embedded Systems.
Right now I'm trying to write a USB driver for a AVR, that has to
work with Windows, but IT says I don't need Admin Rights.
Boss says "do what IT says".
Guess I'll just tell the
customers "sorry I could not test this, talk to the boss or IT if it does not work", as I'll
have no idea if it works.
Its a small company, telling me to talk to someone higher up won't help.
Resume anyone?
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610624</id>
	<title>VBC. Yup me too.</title>
	<author>Juliemac</author>
	<datestamp>1262259660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I also work for a Very Big Corporation. Shudder.
I was tols I could develop applications under the following guide lines.
No access to toad. No IDE. Only what was offered to Office workers. No admin rights locally.

1) Submit the criteria of the app.
2) Build 25\% of the app, but don't run it.
3) submit this 25\% for security verification (4-6 weeks)
4) Build the next 25\%...
Etc till the app is 100\%
Then submit for one more security review.

Then allow the end user to see the application with the first run. If they dont like the application? Return to step 1.



I finally got access to Admin and usually bypass all of their restrictions and can get the job done.
Sheer incompetance.</htmltext>
<tokenext>I also work for a Very Big Corporation .
Shudder . I was tols I could develop applications under the following guide lines .
No access to toad .
No IDE .
Only what was offered to Office workers .
No admin rights locally .
1 ) Submit the criteria of the app .
2 ) Build 25 \ % of the app , but do n't run it .
3 ) submit this 25 \ % for security verification ( 4-6 weeks ) 4 ) Build the next 25 \ % .. . Etc till the app is 100 \ % Then submit for one more security review .
Then allow the end user to see the application with the first run .
If they dont like the application ?
Return to step 1 .
I finally got access to Admin and usually bypass all of their restrictions and can get the job done .
Sheer incompetance .</tokentext>
<sentencetext>I also work for a Very Big Corporation.
Shudder.
I was tols I could develop applications under the following guide lines.
No access to toad.
No IDE.
Only what was offered to Office workers.
No admin rights locally.
1) Submit the criteria of the app.
2) Build 25\% of the app, but don't run it.
3) submit this 25\% for security verification (4-6 weeks)
4) Build the next 25\%...
Etc till the app is 100\%
Then submit for one more security review.
Then allow the end user to see the application with the first run.
If they dont like the application?
Return to step 1.
I finally got access to Admin and usually bypass all of their restrictions and can get the job done.
Sheer incompetance.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607320</id>
	<title>Re:You damn well should</title>
	<author>Captain Spam</author>
	<datestamp>1262284680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think the (faulty) argument is more like...</p><p>...any millwork engineer who can't maintain his/her own automobile is incompetent (hey, mechanics are mechanics, right?).</p><p>...any fluid mechanics researcher who can't maintain his/her own toilet plumbing is incompetent (they're both mostly fluid, right?).</p><p>...any pilot who can't rebuild a commercial passenger jet is incompetent (you need to know all that to fly, right?).</p><p>...any public speaker who can't redesign the firmware on his/her cell phone is incompetent (it's all communication!).</p><p>...any system administrator who can't write complex code is incompetent (because hey, computers are computers... wait, hang on...).</p></htmltext>
<tokenext>I think the ( faulty ) argument is more like......any millwork engineer who ca n't maintain his/her own automobile is incompetent ( hey , mechanics are mechanics , right ?
) ....any fluid mechanics researcher who ca n't maintain his/her own toilet plumbing is incompetent ( they 're both mostly fluid , right ?
) ....any pilot who ca n't rebuild a commercial passenger jet is incompetent ( you need to know all that to fly , right ?
) ....any public speaker who ca n't redesign the firmware on his/her cell phone is incompetent ( it 's all communication !
) ....any system administrator who ca n't write complex code is incompetent ( because hey , computers are computers... wait , hang on... ) .</tokentext>
<sentencetext>I think the (faulty) argument is more like......any millwork engineer who can't maintain his/her own automobile is incompetent (hey, mechanics are mechanics, right?
)....any fluid mechanics researcher who can't maintain his/her own toilet plumbing is incompetent (they're both mostly fluid, right?
)....any pilot who can't rebuild a commercial passenger jet is incompetent (you need to know all that to fly, right?
)....any public speaker who can't redesign the firmware on his/her cell phone is incompetent (it's all communication!
)....any system administrator who can't write complex code is incompetent (because hey, computers are computers... wait, hang on...).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606844</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608808</id>
	<title>Re:Yeah.</title>
	<author>galego</author>
	<datestamp>1262291580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><i>At my last 2 jobs developers have had security exceptions for local admin rights. The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.</i>
<p>
I think there's validity to that<nobr> <wbr></nobr>... for most semi-responsible developers.
</p><p>
However, if you are programming with security exceptions, you are likely to develop things that have/require more security exceptions (e.g. you must be admin/dbo/superuser/root to run it). It's not going to happen just because you're running as admin<nobr> <wbr></nobr>... but it becomes much easier to do so<nobr> <wbr></nobr>... unless you have pretty rigorous testing specifically targeting other user types.  My team all has regular user accounts on their desktops and we do just fine. A couple of us (me as lead) have admin rights to maintain the system (we have a duplicated network/environment to do our work), install stuff etc.
</p><p>
Why propagate the Microsoft development model of must-be-admin-to-run-the-software?&gt; </p></htmltext>
<tokenext>At my last 2 jobs developers have had security exceptions for local admin rights .
The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management .
I think there 's validity to that ... for most semi-responsible developers .
However , if you are programming with security exceptions , you are likely to develop things that have/require more security exceptions ( e.g .
you must be admin/dbo/superuser/root to run it ) .
It 's not going to happen just because you 're running as admin ... but it becomes much easier to do so ... unless you have pretty rigorous testing specifically targeting other user types .
My team all has regular user accounts on their desktops and we do just fine .
A couple of us ( me as lead ) have admin rights to maintain the system ( we have a duplicated network/environment to do our work ) , install stuff etc .
Why propagate the Microsoft development model of must-be-admin-to-run-the-software ? &gt;</tokentext>
<sentencetext>At my last 2 jobs developers have had security exceptions for local admin rights.
The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.
I think there's validity to that ... for most semi-responsible developers.
However, if you are programming with security exceptions, you are likely to develop things that have/require more security exceptions (e.g.
you must be admin/dbo/superuser/root to run it).
It's not going to happen just because you're running as admin ... but it becomes much easier to do so ... unless you have pretty rigorous testing specifically targeting other user types.
My team all has regular user accounts on their desktops and we do just fine.
A couple of us (me as lead) have admin rights to maintain the system (we have a duplicated network/environment to do our work), install stuff etc.
Why propagate the Microsoft development model of must-be-admin-to-run-the-software?&gt; </sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608442</id>
	<title>Seperate Network</title>
	<author>Anonymous</author>
	<datestamp>1262289660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Our development takes place primarily on a separate development network that has no connection to the outside world - it's a little closed loop and it makes for a great test environment and sandbox because of that.  We don't have to worry about corporate restrictions, because development machines are seen as separate from a user's corporate workstation.  This seems to me to be the best possible way to ensure that corporate security policies on corporate machines don't interfere with development requirements.</p></htmltext>
<tokenext>Our development takes place primarily on a separate development network that has no connection to the outside world - it 's a little closed loop and it makes for a great test environment and sandbox because of that .
We do n't have to worry about corporate restrictions , because development machines are seen as separate from a user 's corporate workstation .
This seems to me to be the best possible way to ensure that corporate security policies on corporate machines do n't interfere with development requirements .</tokentext>
<sentencetext>Our development takes place primarily on a separate development network that has no connection to the outside world - it's a little closed loop and it makes for a great test environment and sandbox because of that.
We don't have to worry about corporate restrictions, because development machines are seen as separate from a user's corporate workstation.
This seems to me to be the best possible way to ensure that corporate security policies on corporate machines don't interfere with development requirements.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606756</id>
	<title>You mean the root password?</title>
	<author>Nicolas MONNET</author>
	<datestamp>1262282640000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p>Me I just overwrote the Windows disk with a fresh Linux install of my choosing. I got to pick the root password.</p></htmltext>
<tokenext>Me I just overwrote the Windows disk with a fresh Linux install of my choosing .
I got to pick the root password .</tokentext>
<sentencetext>Me I just overwrote the Windows disk with a fresh Linux install of my choosing.
I got to pick the root password.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608016</id>
	<title>Admin rights to your own machine.</title>
	<author>gregopad39</author>
	<datestamp>1262287380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've been a software developer / consultant over 20 years.<br>With each installation we are given full access to our own pc/workstation and have full admin rights to development servers for the project.    If production support is required, we are also given access to production systems as well, but this is more of an exception than the rule.</p><p>I recently finished a lengthy assignment with Union Pacific.   There are many spart people there - but their security policies regarding developers is something from a TSA screener.</p><p>1. Developers do not have admin access to their own workstations even if they are required to design and test windows services.<br>2. Developers cannot perform any task which requires Admin privs on their own machine.<br>3. VMWare instances of XP and Windows Server are allocated and developers are given Admin rights to these machines, however the VM infrastructure is so overloaded - login can take 10 minutes or more ( in the DEV environment).</p><p>So - to answer your question - Admin rights NOT being given to developers is the exception.   Only in large companies with paranoid and strict policies will you find this to be the case.<br>
&nbsp; &nbsp; &nbsp; &nbsp;</p></htmltext>
<tokenext>I 've been a software developer / consultant over 20 years.With each installation we are given full access to our own pc/workstation and have full admin rights to development servers for the project .
If production support is required , we are also given access to production systems as well , but this is more of an exception than the rule.I recently finished a lengthy assignment with Union Pacific .
There are many spart people there - but their security policies regarding developers is something from a TSA screener.1 .
Developers do not have admin access to their own workstations even if they are required to design and test windows services.2 .
Developers can not perform any task which requires Admin privs on their own machine.3 .
VMWare instances of XP and Windows Server are allocated and developers are given Admin rights to these machines , however the VM infrastructure is so overloaded - login can take 10 minutes or more ( in the DEV environment ) .So - to answer your question - Admin rights NOT being given to developers is the exception .
Only in large companies with paranoid and strict policies will you find this to be the case .
       </tokentext>
<sentencetext>I've been a software developer / consultant over 20 years.With each installation we are given full access to our own pc/workstation and have full admin rights to development servers for the project.
If production support is required, we are also given access to production systems as well, but this is more of an exception than the rule.I recently finished a lengthy assignment with Union Pacific.
There are many spart people there - but their security policies regarding developers is something from a TSA screener.1.
Developers do not have admin access to their own workstations even if they are required to design and test windows services.2.
Developers cannot perform any task which requires Admin privs on their own machine.3.
VMWare instances of XP and Windows Server are allocated and developers are given Admin rights to these machines, however the VM infrastructure is so overloaded - login can take 10 minutes or more ( in the DEV environment).So - to answer your question - Admin rights NOT being given to developers is the exception.
Only in large companies with paranoid and strict policies will you find this to be the case.
       </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607724</id>
	<title>Virtual Machine</title>
	<author>Anonymous</author>
	<datestamp>1262286240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Isn't this what virtual machines were created for. Lock down the main PC and let them play in the sandbox? But I am not a developer so I don't know if this would suck or not.

At my office everyone has admin rights and it makes life hell.</htmltext>
<tokenext>Is n't this what virtual machines were created for .
Lock down the main PC and let them play in the sandbox ?
But I am not a developer so I do n't know if this would suck or not .
At my office everyone has admin rights and it makes life hell .</tokentext>
<sentencetext>Isn't this what virtual machines were created for.
Lock down the main PC and let them play in the sandbox?
But I am not a developer so I don't know if this would suck or not.
At my office everyone has admin rights and it makes life hell.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607026</id>
	<title>Developers do NOT need Admin access</title>
	<author>RaBiDFLY</author>
	<datestamp>1262283540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Recently I've been tasked with network administration (I've been an admin for over a decade but this is not what I was hired to do).</p><p>The first thing I did was remove all local and domain administrative privileges from IT and senior Management.</p><p>The only person it effected was the IT Director, and once I made the appropriate local file permission changes it was fine.</p><p>A few weeks later he found he was missing access to one directory he needed so I logged onto the admin share c$ and gave him access. He was shocked I had remote access to view his files. This was a great boost as to why I have revoked administrator privileges from numerous people (I think I saw him breath a sigh of relief).</p><p>Anyway, the administrator access removal has not effected the IT Development team one bit. Once they have all the apps they need installed on their local workstation, and server level access configured for directory/file permissions, they're good to go about their development without a care.</p><p>Dan</p></htmltext>
<tokenext>Recently I 've been tasked with network administration ( I 've been an admin for over a decade but this is not what I was hired to do ) .The first thing I did was remove all local and domain administrative privileges from IT and senior Management.The only person it effected was the IT Director , and once I made the appropriate local file permission changes it was fine.A few weeks later he found he was missing access to one directory he needed so I logged onto the admin share c $ and gave him access .
He was shocked I had remote access to view his files .
This was a great boost as to why I have revoked administrator privileges from numerous people ( I think I saw him breath a sigh of relief ) .Anyway , the administrator access removal has not effected the IT Development team one bit .
Once they have all the apps they need installed on their local workstation , and server level access configured for directory/file permissions , they 're good to go about their development without a care.Dan</tokentext>
<sentencetext>Recently I've been tasked with network administration (I've been an admin for over a decade but this is not what I was hired to do).The first thing I did was remove all local and domain administrative privileges from IT and senior Management.The only person it effected was the IT Director, and once I made the appropriate local file permission changes it was fine.A few weeks later he found he was missing access to one directory he needed so I logged onto the admin share c$ and gave him access.
He was shocked I had remote access to view his files.
This was a great boost as to why I have revoked administrator privileges from numerous people (I think I saw him breath a sigh of relief).Anyway, the administrator access removal has not effected the IT Development team one bit.
Once they have all the apps they need installed on their local workstation, and server level access configured for directory/file permissions, they're good to go about their development without a care.Dan</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608508</id>
	<title>Re:Virtualization is your Friend</title>
	<author>flabbergast</author>
	<datestamp>1262290020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>The argument that they need to do things that "really, really"<nobr> <wbr></nobr>:-) require access to the bare metal, doesn't hold anymore, because the applications they are building will anyway need to be able to run in a virtualized environment.</i>


<br> <br>There are cases where this is a necessity though.  For instance, my work is with CUDA/OpenCL and that requires access to "the bare metal" so to speak.  Or anyone who works with an FPGA.  Or Cell.  Or driver development.  And even though virtualization is pretty good, it isn't perfect either and can have its own issues (I've had my fair share).  But, for good portion of programming (I'm thinking web development, GUIs, etc), virtualization is an excellent solution.</htmltext>
<tokenext>The argument that they need to do things that " really , really " : - ) require access to the bare metal , does n't hold anymore , because the applications they are building will anyway need to be able to run in a virtualized environment .
There are cases where this is a necessity though .
For instance , my work is with CUDA/OpenCL and that requires access to " the bare metal " so to speak .
Or anyone who works with an FPGA .
Or Cell .
Or driver development .
And even though virtualization is pretty good , it is n't perfect either and can have its own issues ( I 've had my fair share ) .
But , for good portion of programming ( I 'm thinking web development , GUIs , etc ) , virtualization is an excellent solution .</tokentext>
<sentencetext>The argument that they need to do things that "really, really" :-) require access to the bare metal, doesn't hold anymore, because the applications they are building will anyway need to be able to run in a virtualized environment.
There are cases where this is a necessity though.
For instance, my work is with CUDA/OpenCL and that requires access to "the bare metal" so to speak.
Or anyone who works with an FPGA.
Or Cell.
Or driver development.
And even though virtualization is pretty good, it isn't perfect either and can have its own issues (I've had my fair share).
But, for good portion of programming (I'm thinking web development, GUIs, etc), virtualization is an excellent solution.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608434</id>
	<title>I've got admin rights and deserve them</title>
	<author>thetoadwarrior</author>
	<datestamp>1262289600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>With thousands of employees, the IT support guys have enough going on without having to come install things for me every time I need them to do my job.</htmltext>
<tokenext>With thousands of employees , the IT support guys have enough going on without having to come install things for me every time I need them to do my job .</tokentext>
<sentencetext>With thousands of employees, the IT support guys have enough going on without having to come install things for me every time I need them to do my job.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609034</id>
	<title>temporary access makes more sense than permanent..</title>
	<author>Anonymous</author>
	<datestamp>1262292600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If your company deploys a privileged password management system, then you can scramble admin passwords regularly (say daily) and implement authorization processes that allow people who wouldn't normaly have admin rights to production systems - like developers - to get them temporarily when required.</p><p>e.g., privileged-password-manager.hitachi-id.com</p></htmltext>
<tokenext>If your company deploys a privileged password management system , then you can scramble admin passwords regularly ( say daily ) and implement authorization processes that allow people who would n't normaly have admin rights to production systems - like developers - to get them temporarily when required.e.g. , privileged-password-manager.hitachi-id.com</tokentext>
<sentencetext>If your company deploys a privileged password management system, then you can scramble admin passwords regularly (say daily) and implement authorization processes that allow people who wouldn't normaly have admin rights to production systems - like developers - to get them temporarily when required.e.g., privileged-password-manager.hitachi-id.com</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607042</id>
	<title>Local admin rights?</title>
	<author>SmallFurryCreature</author>
	<datestamp>1262283600000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Why not simply work on virtual machines? Then you know they are clean and you can have all the rights you want and still have comply with company rules.
</p><p>In a lot of environments, setting up a good seperation is simply to costly in time, so you either end up with dev's with not enough rights to do their job or to many where they can endanger systems they shouldn't.
</p><p>So it should not be needed to have local admin rights, but then the sysadmins got a hell of a job to setup everything so that it is not needed. Most sysadmins simply ain't capable of that, or if they are, are not given the time.</p></htmltext>
<tokenext>Why not simply work on virtual machines ?
Then you know they are clean and you can have all the rights you want and still have comply with company rules .
In a lot of environments , setting up a good seperation is simply to costly in time , so you either end up with dev 's with not enough rights to do their job or to many where they can endanger systems they should n't .
So it should not be needed to have local admin rights , but then the sysadmins got a hell of a job to setup everything so that it is not needed .
Most sysadmins simply ai n't capable of that , or if they are , are not given the time .</tokentext>
<sentencetext>Why not simply work on virtual machines?
Then you know they are clean and you can have all the rights you want and still have comply with company rules.
In a lot of environments, setting up a good seperation is simply to costly in time, so you either end up with dev's with not enough rights to do their job or to many where they can endanger systems they shouldn't.
So it should not be needed to have local admin rights, but then the sysadmins got a hell of a job to setup everything so that it is not needed.
Most sysadmins simply ain't capable of that, or if they are, are not given the time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610928</id>
	<title>Re:What it REALLY comes down to</title>
	<author>Anonymous</author>
	<datestamp>1262262540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The same happens with dpkg/rpm. They're packaged for system-wide install, so require root access.</p></htmltext>
<tokenext>The same happens with dpkg/rpm .
They 're packaged for system-wide install , so require root access .</tokentext>
<sentencetext>The same happens with dpkg/rpm.
They're packaged for system-wide install, so require root access.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606730</id>
	<title>I give developers admin rights</title>
	<author>citking</author>
	<datestamp>1262282580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I give them admin rights with the agreement that, if they mess something up on their computer, they are on my schedule to be fixed (i.e., when it is convenient for me, not for them). So far I haven't had any issues whatsoever. Then again, we are a pretty small department.
</p><p>My personal thoughts on the matter are simple: If the IT staff feels they can trust someone with local admin rights then that person should have them if necessary. If that person messes something up, even if it is unintentional (malware, deletes the boot.ini file, etc.) then they lose the privilege.</p></htmltext>
<tokenext>I give them admin rights with the agreement that , if they mess something up on their computer , they are on my schedule to be fixed ( i.e. , when it is convenient for me , not for them ) .
So far I have n't had any issues whatsoever .
Then again , we are a pretty small department .
My personal thoughts on the matter are simple : If the IT staff feels they can trust someone with local admin rights then that person should have them if necessary .
If that person messes something up , even if it is unintentional ( malware , deletes the boot.ini file , etc .
) then they lose the privilege .</tokentext>
<sentencetext>I give them admin rights with the agreement that, if they mess something up on their computer, they are on my schedule to be fixed (i.e., when it is convenient for me, not for them).
So far I haven't had any issues whatsoever.
Then again, we are a pretty small department.
My personal thoughts on the matter are simple: If the IT staff feels they can trust someone with local admin rights then that person should have them if necessary.
If that person messes something up, even if it is unintentional (malware, deletes the boot.ini file, etc.
) then they lose the privilege.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610106</id>
	<title>Could also be US Bank</title>
	<author>Anonymous</author>
	<datestamp>1262255880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The same problems are at US Bank.</p><p>I wonder if it's just some douchebag consultant or lame security guru in Minneapolis laughing all the way to the bank.</p><p>Target and US Bank are both based there.  Is Best Buy that bad too?</p></htmltext>
<tokenext>The same problems are at US Bank.I wonder if it 's just some douchebag consultant or lame security guru in Minneapolis laughing all the way to the bank.Target and US Bank are both based there .
Is Best Buy that bad too ?</tokentext>
<sentencetext>The same problems are at US Bank.I wonder if it's just some douchebag consultant or lame security guru in Minneapolis laughing all the way to the bank.Target and US Bank are both based there.
Is Best Buy that bad too?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611282</id>
	<title>Re:Not on any test systems</title>
	<author>Anonymous</author>
	<datestamp>1262265960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>yes, I've seen that kind of idiocy in software from a company we work closely with, they do software and we do hardware. Their software needs to be able to update itself when the user starts it, they want us to give all the users local admin access to the machines for it. I Just stick in a GPO to give all domain users full access to the program directory. Not a fully satisfactory solution, but its not like its an important piece of software, just a bank teller system....</htmltext>
<tokenext>yes , I 've seen that kind of idiocy in software from a company we work closely with , they do software and we do hardware .
Their software needs to be able to update itself when the user starts it , they want us to give all the users local admin access to the machines for it .
I Just stick in a GPO to give all domain users full access to the program directory .
Not a fully satisfactory solution , but its not like its an important piece of software , just a bank teller system... .</tokentext>
<sentencetext>yes, I've seen that kind of idiocy in software from a company we work closely with, they do software and we do hardware.
Their software needs to be able to update itself when the user starts it, they want us to give all the users local admin access to the machines for it.
I Just stick in a GPO to give all domain users full access to the program directory.
Not a fully satisfactory solution, but its not like its an important piece of software, just a bank teller system....</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606700</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613288</id>
	<title>Re:Virtualization is your Friend</title>
	<author>Anonymous</author>
	<datestamp>1230810360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You know that it is pain in the ass develop software under virtual machine. Many developer tools need lot of memory and processor speed.</p></htmltext>
<tokenext>You know that it is pain in the ass develop software under virtual machine .
Many developer tools need lot of memory and processor speed .</tokentext>
<sentencetext>You know that it is pain in the ass develop software under virtual machine.
Many developer tools need lot of memory and processor speed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607890</id>
	<title>Virus Scanning</title>
	<author>troll8901</author>
	<datestamp>1262286840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><nobr> <wbr></nobr></p><div class="quote"><p>... one moron who used the privilege to turn off her virus scanning.</p></div><p>A woman!  How old is she, and can I marry her?</p><p>Jokes aside, is there a reason why she turn off her virus scanning?  For example, rushing a project, or the hard disk getting slower, or the antivirus somehow screwing up her work, or something.</p></div>
	</htmltext>
<tokenext>... one moron who used the privilege to turn off her virus scanning.A woman !
How old is she , and can I marry her ? Jokes aside , is there a reason why she turn off her virus scanning ?
For example , rushing a project , or the hard disk getting slower , or the antivirus somehow screwing up her work , or something .</tokentext>
<sentencetext> ... one moron who used the privilege to turn off her virus scanning.A woman!
How old is she, and can I marry her?Jokes aside, is there a reason why she turn off her virus scanning?
For example, rushing a project, or the hard disk getting slower, or the antivirus somehow screwing up her work, or something.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606590</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608450</id>
	<title>It depends on the required flexibility...</title>
	<author>J. Adam Hart</author>
	<datestamp>1262289720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'd say if you are targeting a very specific platform, developers don't really need full admin access to do their jobs.  e.g. ASP.NET development is fairly rigid and it's usually done with the whole team using the same exact tools (Visual Studio, TFS, etc).  In such a regimented environment, it might be better to lock everything down.  But in an agency or consultancy shop, the tool set could change with every project.  I don't think IT should be on the hook for setting up random systems that will only be used for a few months or weeks before being torn down again.</p></htmltext>
<tokenext>I 'd say if you are targeting a very specific platform , developers do n't really need full admin access to do their jobs .
e.g. ASP.NET development is fairly rigid and it 's usually done with the whole team using the same exact tools ( Visual Studio , TFS , etc ) .
In such a regimented environment , it might be better to lock everything down .
But in an agency or consultancy shop , the tool set could change with every project .
I do n't think IT should be on the hook for setting up random systems that will only be used for a few months or weeks before being torn down again .</tokentext>
<sentencetext>I'd say if you are targeting a very specific platform, developers don't really need full admin access to do their jobs.
e.g. ASP.NET development is fairly rigid and it's usually done with the whole team using the same exact tools (Visual Studio, TFS, etc).
In such a regimented environment, it might be better to lock everything down.
But in an agency or consultancy shop, the tool set could change with every project.
I don't think IT should be on the hook for setting up random systems that will only be used for a few months or weeks before being torn down again.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606938</id>
	<title>Dev with root?</title>
	<author>Anonymous</author>
	<datestamp>1262283240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Are you insane?</p></htmltext>
<tokenext>Are you insane ?</tokentext>
<sentencetext>Are you insane?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606858</id>
	<title>Re:Under no circumstances</title>
	<author>Anonymous</author>
	<datestamp>1262282940000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>-1</modscore>
	<htmltext><p>The author said LOCAL admin rights -- not network rights.</p></htmltext>
<tokenext>The author said LOCAL admin rights -- not network rights .</tokentext>
<sentencetext>The author said LOCAL admin rights -- not network rights.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606710</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607906</id>
	<title>Yes</title>
	<author>Anonymous</author>
	<datestamp>1262286900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yes, we have local admin rights, with the caveat that we don't call the help desk for most things.  We're expected to fix our machines ourselves, and be responsible if we spread virii or other malware.</p></htmltext>
<tokenext>Yes , we have local admin rights , with the caveat that we do n't call the help desk for most things .
We 're expected to fix our machines ourselves , and be responsible if we spread virii or other malware .</tokentext>
<sentencetext>Yes, we have local admin rights, with the caveat that we don't call the help desk for most things.
We're expected to fix our machines ourselves, and be responsible if we spread virii or other malware.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607826</id>
	<title>Balancing act</title>
	<author>EriktheGreen</author>
	<datestamp>1262286600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
I've worked at places where individual users (developers, engineers, and other tech savvy folks) have admin rights.
</p><p>
In every case, it's a balance.  The ease of getting things done quickly vs. manageability and security of the computer involved.
</p><p>
If you lock a computer down so the installed apps can be used but nothing else can be installed, it tends to be relatively stable, and you don't get rogue programs installed that cause problems and generate extra work for installers and work disruption for users.  The other end of the spectrum means anyone can install what they want.  You give rights to everyone and end up with constant rebuilds and virus problems, etc.  These can be just minor annoyances or in the worst case can disrupt business or cause legal issues (like loss of private or protected data) that will shut the company down.  At the very least they create lots of extra work for someone in the company.
</p><p>
So, many managers (tech savvy and not) are deciding that they need to lock down control of work computers.  Basically, they remove the ability to do anything but run work related applications (centrally installed to ensure licensing works and to make sure everyone has the same version) to simplify support and lower costs (which are a big headache for any IT manager).
</p><p>
This makes things more complicated for individuals with legitimate business reasons to install software (like dev add-ons or new versions of libraries, etc).  In the case of a locked down system, the central authority in the business for support needs to provide a way to respond to requests to install needed software quickly.  This can be either an automated system with menus, or an on-call support staff that handles things.  With remote access to desktops they can generally get things installed quickly enough that work isn't significantly delayed.  If and only if management recognizes that this support is necessary (people hear what they want to hear, and too often management thinks the clamor against locking down workstations is simply bruised egos (see below)).
</p><p>
This problem comes in when a company decides to solve its rogue software problems by restricting desktop access but doesn't provide any way to request "special" software.  Unless your company is very unusual, certain users will need software that's not generally installed everywhere, and not everyone will fit the "standard business software" mold.  This is a rough parallel to IT departments restricting access and forcing change control for "production" tier systems without changing their development processes to remove the need for production access.  You're left with a choice to either break the rules or not get work done, and god help you if you try to explain things to whichever manager is getting a pat on the back for "securing the system".
</p><p>
Of course, the reason most people ask questions like the submitter is probably due to ego.  The emotion behind the question runs roughly "I'm a smart (guy, girl).. I've been progamming and running my own system since before this OS was released!  I don't need a low paid staffer to handle this for me, and you're just slowing me down!  I feel insulted by you not giving me privileges and trusting me to keep things working!"
</p><p>
Having control is a hard habit to break.  Taking it away from people who've "always" had it is like introducing change control to a company that's always been a free for all... people see the change as extra procedure being introduced that is unnecessary and slows down "real work".
</p><p>
The best way I've found to deal with people who want admin rights because their ego demands control is to ask them if they're also willing to accept responsibility for their workstation being productive.  The desktop support folks or central desktop team accept this as part of their job.. in cases of heavily regulated industries, there may be legal requirements for someone to be responsible for the integrity of such systems.  So once you get the person complaining about a lack of access rights</p></htmltext>
<tokenext>I 've worked at places where individual users ( developers , engineers , and other tech savvy folks ) have admin rights .
In every case , it 's a balance .
The ease of getting things done quickly vs. manageability and security of the computer involved .
If you lock a computer down so the installed apps can be used but nothing else can be installed , it tends to be relatively stable , and you do n't get rogue programs installed that cause problems and generate extra work for installers and work disruption for users .
The other end of the spectrum means anyone can install what they want .
You give rights to everyone and end up with constant rebuilds and virus problems , etc .
These can be just minor annoyances or in the worst case can disrupt business or cause legal issues ( like loss of private or protected data ) that will shut the company down .
At the very least they create lots of extra work for someone in the company .
So , many managers ( tech savvy and not ) are deciding that they need to lock down control of work computers .
Basically , they remove the ability to do anything but run work related applications ( centrally installed to ensure licensing works and to make sure everyone has the same version ) to simplify support and lower costs ( which are a big headache for any IT manager ) .
This makes things more complicated for individuals with legitimate business reasons to install software ( like dev add-ons or new versions of libraries , etc ) .
In the case of a locked down system , the central authority in the business for support needs to provide a way to respond to requests to install needed software quickly .
This can be either an automated system with menus , or an on-call support staff that handles things .
With remote access to desktops they can generally get things installed quickly enough that work is n't significantly delayed .
If and only if management recognizes that this support is necessary ( people hear what they want to hear , and too often management thinks the clamor against locking down workstations is simply bruised egos ( see below ) ) .
This problem comes in when a company decides to solve its rogue software problems by restricting desktop access but does n't provide any way to request " special " software .
Unless your company is very unusual , certain users will need software that 's not generally installed everywhere , and not everyone will fit the " standard business software " mold .
This is a rough parallel to IT departments restricting access and forcing change control for " production " tier systems without changing their development processes to remove the need for production access .
You 're left with a choice to either break the rules or not get work done , and god help you if you try to explain things to whichever manager is getting a pat on the back for " securing the system " .
Of course , the reason most people ask questions like the submitter is probably due to ego .
The emotion behind the question runs roughly " I 'm a smart ( guy , girl ) .. I 've been progamming and running my own system since before this OS was released !
I do n't need a low paid staffer to handle this for me , and you 're just slowing me down !
I feel insulted by you not giving me privileges and trusting me to keep things working !
" Having control is a hard habit to break .
Taking it away from people who 've " always " had it is like introducing change control to a company that 's always been a free for all... people see the change as extra procedure being introduced that is unnecessary and slows down " real work " .
The best way I 've found to deal with people who want admin rights because their ego demands control is to ask them if they 're also willing to accept responsibility for their workstation being productive .
The desktop support folks or central desktop team accept this as part of their job.. in cases of heavily regulated industries , there may be legal requirements for someone to be responsible for the integrity of such systems .
So once you get the person complaining about a lack of access rights</tokentext>
<sentencetext>
I've worked at places where individual users (developers, engineers, and other tech savvy folks) have admin rights.
In every case, it's a balance.
The ease of getting things done quickly vs. manageability and security of the computer involved.
If you lock a computer down so the installed apps can be used but nothing else can be installed, it tends to be relatively stable, and you don't get rogue programs installed that cause problems and generate extra work for installers and work disruption for users.
The other end of the spectrum means anyone can install what they want.
You give rights to everyone and end up with constant rebuilds and virus problems, etc.
These can be just minor annoyances or in the worst case can disrupt business or cause legal issues (like loss of private or protected data) that will shut the company down.
At the very least they create lots of extra work for someone in the company.
So, many managers (tech savvy and not) are deciding that they need to lock down control of work computers.
Basically, they remove the ability to do anything but run work related applications (centrally installed to ensure licensing works and to make sure everyone has the same version) to simplify support and lower costs (which are a big headache for any IT manager).
This makes things more complicated for individuals with legitimate business reasons to install software (like dev add-ons or new versions of libraries, etc).
In the case of a locked down system, the central authority in the business for support needs to provide a way to respond to requests to install needed software quickly.
This can be either an automated system with menus, or an on-call support staff that handles things.
With remote access to desktops they can generally get things installed quickly enough that work isn't significantly delayed.
If and only if management recognizes that this support is necessary (people hear what they want to hear, and too often management thinks the clamor against locking down workstations is simply bruised egos (see below)).
This problem comes in when a company decides to solve its rogue software problems by restricting desktop access but doesn't provide any way to request "special" software.
Unless your company is very unusual, certain users will need software that's not generally installed everywhere, and not everyone will fit the "standard business software" mold.
This is a rough parallel to IT departments restricting access and forcing change control for "production" tier systems without changing their development processes to remove the need for production access.
You're left with a choice to either break the rules or not get work done, and god help you if you try to explain things to whichever manager is getting a pat on the back for "securing the system".
Of course, the reason most people ask questions like the submitter is probably due to ego.
The emotion behind the question runs roughly "I'm a smart (guy, girl).. I've been progamming and running my own system since before this OS was released!
I don't need a low paid staffer to handle this for me, and you're just slowing me down!
I feel insulted by you not giving me privileges and trusting me to keep things working!
"

Having control is a hard habit to break.
Taking it away from people who've "always" had it is like introducing change control to a company that's always been a free for all... people see the change as extra procedure being introduced that is unnecessary and slows down "real work".
The best way I've found to deal with people who want admin rights because their ego demands control is to ask them if they're also willing to accept responsibility for their workstation being productive.
The desktop support folks or central desktop team accept this as part of their job.. in cases of heavily regulated industries, there may be legal requirements for someone to be responsible for the integrity of such systems.
So once you get the person complaining about a lack of access rights</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606856</id>
	<title>It depends....</title>
	<author>cts5678</author>
	<datestamp>1262282940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>On their personal laptops, yes they do.  On servers or laptops used as test machines, no.

Think about the security concepts of least needed access and separation of duties.

On their personal laptops, they may have a need for being able to quickly and freely do certain things.

But once you get to anything approaching production, they need to be locked down.</htmltext>
<tokenext>On their personal laptops , yes they do .
On servers or laptops used as test machines , no .
Think about the security concepts of least needed access and separation of duties .
On their personal laptops , they may have a need for being able to quickly and freely do certain things .
But once you get to anything approaching production , they need to be locked down .</tokentext>
<sentencetext>On their personal laptops, yes they do.
On servers or laptops used as test machines, no.
Think about the security concepts of least needed access and separation of duties.
On their personal laptops, they may have a need for being able to quickly and freely do certain things.
But once you get to anything approaching production, they need to be locked down.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610530</id>
	<title>Re:Worked in Both Worlds...</title>
	<author>Locke2005</author>
	<datestamp>1262258880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Actually, it sounds to me like this corporation was doing things the right way. Unfortunately, most companies are willing to devote the resources required for doing things the right way, and take more of a management-by-crisis approach. When you're proactive and fix every problem before it occurs (with severe impact to productivity) then management starts wondering why they pay you so much when you "never do anything".</htmltext>
<tokenext>Actually , it sounds to me like this corporation was doing things the right way .
Unfortunately , most companies are willing to devote the resources required for doing things the right way , and take more of a management-by-crisis approach .
When you 're proactive and fix every problem before it occurs ( with severe impact to productivity ) then management starts wondering why they pay you so much when you " never do anything " .</tokentext>
<sentencetext>Actually, it sounds to me like this corporation was doing things the right way.
Unfortunately, most companies are willing to devote the resources required for doing things the right way, and take more of a management-by-crisis approach.
When you're proactive and fix every problem before it occurs (with severe impact to productivity) then management starts wondering why they pay you so much when you "never do anything".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607092</id>
	<title>Yes : Admin on personnal workstation</title>
	<author>AwaxSlashdot</author>
	<datestamp>1262283720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This is my 4th workplace and at all, from a 4 persons start-up to a international investment/corporate bank with a 1500 dev department, all dev had Admin rights to his own station.
<br>
In theory, you could be writing software as a simple/advanced user and the IT dept can grant you the exact rights needed to do so. BUT there is a huge amount of complex access rights involved when working on Windows using VisualStudio with no exact list of what are exactly the rights needed. MS tried to simplify the process by creating dedicated groups (like VS Developers group or Debugger Users group). At the end, most of the time, the IT dept simply grant local admin rights to every dev so they are not disturbed every 5 seconds because a very complex to trace access right is missing.</htmltext>
<tokenext>This is my 4th workplace and at all , from a 4 persons start-up to a international investment/corporate bank with a 1500 dev department , all dev had Admin rights to his own station .
In theory , you could be writing software as a simple/advanced user and the IT dept can grant you the exact rights needed to do so .
BUT there is a huge amount of complex access rights involved when working on Windows using VisualStudio with no exact list of what are exactly the rights needed .
MS tried to simplify the process by creating dedicated groups ( like VS Developers group or Debugger Users group ) .
At the end , most of the time , the IT dept simply grant local admin rights to every dev so they are not disturbed every 5 seconds because a very complex to trace access right is missing .</tokentext>
<sentencetext>This is my 4th workplace and at all, from a 4 persons start-up to a international investment/corporate bank with a 1500 dev department, all dev had Admin rights to his own station.
In theory, you could be writing software as a simple/advanced user and the IT dept can grant you the exact rights needed to do so.
BUT there is a huge amount of complex access rights involved when working on Windows using VisualStudio with no exact list of what are exactly the rights needed.
MS tried to simplify the process by creating dedicated groups (like VS Developers group or Debugger Users group).
At the end, most of the time, the IT dept simply grant local admin rights to every dev so they are not disturbed every 5 seconds because a very complex to trace access right is missing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608170</id>
	<title>Sometimes... depending on the circumstances</title>
	<author>mark-t</author>
	<datestamp>1262288160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In my experience, if the development environment is Windows, yes, all developers have local admin rights.
<p>
However, when I worked in a place where the development environment was Linux, no... developers did not have root.</p></htmltext>
<tokenext>In my experience , if the development environment is Windows , yes , all developers have local admin rights .
However , when I worked in a place where the development environment was Linux , no... developers did not have root .</tokentext>
<sentencetext>In my experience, if the development environment is Windows, yes, all developers have local admin rights.
However, when I worked in a place where the development environment was Linux, no... developers did not have root.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609482</id>
	<title>Re:Virtualization is your Friend</title>
	<author>Anonymous</author>
	<datestamp>1262252220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>As a developer: if you made me use a VM for dev work, I'd leave your company.  I mean that.</p><p>Using a VM sounds like a great idea until you want to compile anything non-trivial.  Then you're just wasting time by not running directly on metal.</p></htmltext>
<tokenext>As a developer : if you made me use a VM for dev work , I 'd leave your company .
I mean that.Using a VM sounds like a great idea until you want to compile anything non-trivial .
Then you 're just wasting time by not running directly on metal .</tokentext>
<sentencetext>As a developer: if you made me use a VM for dev work, I'd leave your company.
I mean that.Using a VM sounds like a great idea until you want to compile anything non-trivial.
Then you're just wasting time by not running directly on metal.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611472</id>
	<title>and thats how you end up with a bucket of fail.</title>
	<author>Anonymous</author>
	<datestamp>1262267760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>yep, seen it a lot. And its BAD. Its usually done because whiney devs (interchangable with "application admins" and "DBAs"), who don't really know what they are doing, claim that they "need" root or admin access in order for them to "debug" and diagnose problems... without actually being able to specify or provide an example of said activity, thereby avoiding the use of targetted or ad-hock sudo access to do the same (a much safer and sensible option, even allows you to document what they are doing and why, for things such as upgrades/migrations...). The incessant whining usually results in management saying "just do it".</p><p>The end result is usually a combination of:<br>- services running as root/local/(or heaven forbid) domain admin<br>- deployment instructions that are full of the words "as the user root/local admin" for no apparent reason (e.g. chmod a file as root already owned by the application user??)<br>- the scattering of random application libraries/binaries across system filesystems/directories<br>- the implementation of chunks of applications using pointless system calls to unmaintainable standalone binaries that devs have scattered across the filesystems.<br>- insert your own nightmare for system maintenance......</p></htmltext>
<tokenext>yep , seen it a lot .
And its BAD .
Its usually done because whiney devs ( interchangable with " application admins " and " DBAs " ) , who do n't really know what they are doing , claim that they " need " root or admin access in order for them to " debug " and diagnose problems... without actually being able to specify or provide an example of said activity , thereby avoiding the use of targetted or ad-hock sudo access to do the same ( a much safer and sensible option , even allows you to document what they are doing and why , for things such as upgrades/migrations... ) .
The incessant whining usually results in management saying " just do it " .The end result is usually a combination of : - services running as root/local/ ( or heaven forbid ) domain admin- deployment instructions that are full of the words " as the user root/local admin " for no apparent reason ( e.g .
chmod a file as root already owned by the application user ? ?
) - the scattering of random application libraries/binaries across system filesystems/directories- the implementation of chunks of applications using pointless system calls to unmaintainable standalone binaries that devs have scattered across the filesystems.- insert your own nightmare for system maintenance..... .</tokentext>
<sentencetext>yep, seen it a lot.
And its BAD.
Its usually done because whiney devs (interchangable with "application admins" and "DBAs"), who don't really know what they are doing, claim that they "need" root or admin access in order for them to "debug" and diagnose problems... without actually being able to specify or provide an example of said activity, thereby avoiding the use of targetted or ad-hock sudo access to do the same (a much safer and sensible option, even allows you to document what they are doing and why, for things such as upgrades/migrations...).
The incessant whining usually results in management saying "just do it".The end result is usually a combination of:- services running as root/local/(or heaven forbid) domain admin- deployment instructions that are full of the words "as the user root/local admin" for no apparent reason (e.g.
chmod a file as root already owned by the application user??
)- the scattering of random application libraries/binaries across system filesystems/directories- the implementation of chunks of applications using pointless system calls to unmaintainable standalone binaries that devs have scattered across the filesystems.- insert your own nightmare for system maintenance......</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606612</id>
	<title>Re:What?</title>
	<author>Anonymous</author>
	<datestamp>1262282100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Article submitter was talking about local admin rights (implied on Windows) for their desktop workstations, not servers.</htmltext>
<tokenext>Article submitter was talking about local admin rights ( implied on Windows ) for their desktop workstations , not servers .</tokentext>
<sentencetext>Article submitter was talking about local admin rights (implied on Windows) for their desktop workstations, not servers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607498</id>
	<title>Re:Information Security 101 - Yes and No</title>
	<author>garyisabusyguy</author>
	<datestamp>1262285280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I will agree with you that any machine that is used to run production applications, particularly those attached to the internet, need to follow a strict lock-down. The very first concern should be permissions, permissions, permissions with nobody loggin in as root (admin whatever), using sudo to promote to 'admin' and thorough logging of any escalation of privlidges.</p><p>From a developer standpoint, if somebody is calling me at midnite and asking me to log into a prod box and fix something.... Then there is a hell of a lot more wrong in the organization than a crashed application.</p><p>That said, attempting to enforce that level of security on a pc used by a developer is pretty much an exercise in futility. Either your developer will just 'give up' and let thmself fall behing in tool updates, or they will get 'wiley' and saturate your support staff with calls to perform 'desktop maintenance' until your organization gives in a allows local admin.</p></htmltext>
<tokenext>I will agree with you that any machine that is used to run production applications , particularly those attached to the internet , need to follow a strict lock-down .
The very first concern should be permissions , permissions , permissions with nobody loggin in as root ( admin whatever ) , using sudo to promote to 'admin ' and thorough logging of any escalation of privlidges.From a developer standpoint , if somebody is calling me at midnite and asking me to log into a prod box and fix something.... Then there is a hell of a lot more wrong in the organization than a crashed application.That said , attempting to enforce that level of security on a pc used by a developer is pretty much an exercise in futility .
Either your developer will just 'give up ' and let thmself fall behing in tool updates , or they will get 'wiley ' and saturate your support staff with calls to perform 'desktop maintenance ' until your organization gives in a allows local admin .</tokentext>
<sentencetext>I will agree with you that any machine that is used to run production applications, particularly those attached to the internet, need to follow a strict lock-down.
The very first concern should be permissions, permissions, permissions with nobody loggin in as root (admin whatever), using sudo to promote to 'admin' and thorough logging of any escalation of privlidges.From a developer standpoint, if somebody is calling me at midnite and asking me to log into a prod box and fix something.... Then there is a hell of a lot more wrong in the organization than a crashed application.That said, attempting to enforce that level of security on a pc used by a developer is pretty much an exercise in futility.
Either your developer will just 'give up' and let thmself fall behing in tool updates, or they will get 'wiley' and saturate your support staff with calls to perform 'desktop maintenance' until your organization gives in a allows local admin.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607004</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609728</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262253600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Does your company also insist on reading comprehension?  The original topic was about an individual's workstation.  What does that have to do with reboot a production box?</htmltext>
<tokenext>Does your company also insist on reading comprehension ?
The original topic was about an individual 's workstation .
What does that have to do with reboot a production box ?</tokentext>
<sentencetext>Does your company also insist on reading comprehension?
The original topic was about an individual's workstation.
What does that have to do with reboot a production box?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606818</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612446</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262282280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"There are good sysadmins who can't program, and good programmers who know very little about system administration."</p><p>Bullshit.  I know good sysadmins that are not *efficient* programming nor far knowledgeable, but I never knew a good sysadmin that coudn't program.  The same goes the other way around: I know good programmers that don't know the ins and outs of the nitty-gritties of system administration, but I never knew a good programmer without real knowledge fo OS functions, networking, etc.</p><p>Oh, yes, I know *a lot* of bad programmers and system administrators that think your way and usually think they are good examples of this but the sad reality is that they are wrong and that they are neither good programmers nor good sysadmins.  But, hey, 90\% of everything is shit, after all.</p></htmltext>
<tokenext>" There are good sysadmins who ca n't program , and good programmers who know very little about system administration. " Bullshit .
I know good sysadmins that are not * efficient * programming nor far knowledgeable , but I never knew a good sysadmin that coud n't program .
The same goes the other way around : I know good programmers that do n't know the ins and outs of the nitty-gritties of system administration , but I never knew a good programmer without real knowledge fo OS functions , networking , etc.Oh , yes , I know * a lot * of bad programmers and system administrators that think your way and usually think they are good examples of this but the sad reality is that they are wrong and that they are neither good programmers nor good sysadmins .
But , hey , 90 \ % of everything is shit , after all .</tokentext>
<sentencetext>"There are good sysadmins who can't program, and good programmers who know very little about system administration."Bullshit.
I know good sysadmins that are not *efficient* programming nor far knowledgeable, but I never knew a good sysadmin that coudn't program.
The same goes the other way around: I know good programmers that don't know the ins and outs of the nitty-gritties of system administration, but I never knew a good programmer without real knowledge fo OS functions, networking, etc.Oh, yes, I know *a lot* of bad programmers and system administrators that think your way and usually think they are good examples of this but the sad reality is that they are wrong and that they are neither good programmers nor good sysadmins.
But, hey, 90\% of everything is shit, after all.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607508</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466</id>
	<title>Yeah.</title>
	<author>qoncept</author>
	<datestamp>1262281740000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>At my last 2 jobs developers have had security exceptions for local admin rights. The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even <i>management</i>.</htmltext>
<tokenext>At my last 2 jobs developers have had security exceptions for local admin rights .
The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management .</tokentext>
<sentencetext>At my last 2 jobs developers have had security exceptions for local admin rights.
The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608764</id>
	<title>Re:What?</title>
	<author>Carewolf</author>
	<datestamp>1262291340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Which any developer should have. No admin in their right mind wants to admin a developer workstation. It is unrelated to all other administration and much more complicated, not to mention unnecessary. Take an extreme example; some developers are also working on new admin tools. This means the computers used for testing and development are using different admin software than everything else. The admin shouldn't have to deal with new buggy admin tools until they are finished, except possibly as a user test.</p></htmltext>
<tokenext>Which any developer should have .
No admin in their right mind wants to admin a developer workstation .
It is unrelated to all other administration and much more complicated , not to mention unnecessary .
Take an extreme example ; some developers are also working on new admin tools .
This means the computers used for testing and development are using different admin software than everything else .
The admin should n't have to deal with new buggy admin tools until they are finished , except possibly as a user test .</tokentext>
<sentencetext>Which any developer should have.
No admin in their right mind wants to admin a developer workstation.
It is unrelated to all other administration and much more complicated, not to mention unnecessary.
Take an extreme example; some developers are also working on new admin tools.
This means the computers used for testing and development are using different admin software than everything else.
The admin shouldn't have to deal with new buggy admin tools until they are finished, except possibly as a user test.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606612</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609068</id>
	<title>Re:Yeah.</title>
	<author>thsths</author>
	<datestamp>1262292840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm</p><p>Sometimes it is just about trust. But if you don't trust you developers, you should not trust the software they write either...</p><p>Plus a good developer will know how to get around standard security barriers anyway, so giving them admin rights does not actually make a different security wise.</p></htmltext>
<tokenext>&gt; The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harmSometimes it is just about trust .
But if you do n't trust you developers , you should not trust the software they write either...Plus a good developer will know how to get around standard security barriers anyway , so giving them admin rights does not actually make a different security wise .</tokentext>
<sentencetext>&gt; The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harmSometimes it is just about trust.
But if you don't trust you developers, you should not trust the software they write either...Plus a good developer will know how to get around standard security barriers anyway, so giving them admin rights does not actually make a different security wise.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607218</id>
	<title>Re:Yeah.</title>
	<author>Thad Zurich</author>
	<datestamp>1262284320000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext>Well considering that almost every security vulnerability ever reported has developers as a root cause, not sure you can really claim they cause less harm. The harm just gets postponed until it is maximally expensive.</htmltext>
<tokenext>Well considering that almost every security vulnerability ever reported has developers as a root cause , not sure you can really claim they cause less harm .
The harm just gets postponed until it is maximally expensive .</tokentext>
<sentencetext>Well considering that almost every security vulnerability ever reported has developers as a root cause, not sure you can really claim they cause less harm.
The harm just gets postponed until it is maximally expensive.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606482</id>
	<title>Generally, yes</title>
	<author>PIPBoy3000</author>
	<datestamp>1262281740000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext>We're local admins of the application servers, and a couple of us have domain admin rights.  We generally haven't run into problems with this, as we have a strict policy of making fun of anyone who screws up badly.  It involves Photoshop and is generally a memorable way to resolve the situation.</htmltext>
<tokenext>We 're local admins of the application servers , and a couple of us have domain admin rights .
We generally have n't run into problems with this , as we have a strict policy of making fun of anyone who screws up badly .
It involves Photoshop and is generally a memorable way to resolve the situation .</tokentext>
<sentencetext>We're local admins of the application servers, and a couple of us have domain admin rights.
We generally haven't run into problems with this, as we have a strict policy of making fun of anyone who screws up badly.
It involves Photoshop and is generally a memorable way to resolve the situation.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611068</id>
	<title>Re:IT isn't allowed to touch my workstation</title>
	<author>rahvin112</author>
	<datestamp>1262263980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The IT manager should be fired.</p><p>If you ever get a real PHB's ear (preferably one that manages budgets) privately for a few minutes you should ask them if they have ever evaluated how much IT taking over someone's machine during work hours costs the company. Don't be confrontational, in fact act stupid, like you really don't know what you are asking and you are truly interested in an answer. Whatever the response is nod, accept it, say thanks and drop it, talk about sports or something else. The question will eat away at the PHB and he'll eventually start asking questions.</p><p>IT should NEVER EVER take over a machine during work hours unless the employee is needed to assist, and even then it should be a scheduled thing. It's been my experience that IT thinks they are important. There is only one business where IT people are actually the people making the company money and that's IT service companies. Otherwise the people they are interrupting are the ones that make the money that pay for their job. IT taking control of a machine for an hour during work hours could cost the company hundreds and even thousands of dollars in lost revenue. All machine maintenance should be done after general work hours, if needed the IT department should work such that one of the IT employees is on staff in the middle of the night to do such maintenance.</p></htmltext>
<tokenext>The IT manager should be fired.If you ever get a real PHB 's ear ( preferably one that manages budgets ) privately for a few minutes you should ask them if they have ever evaluated how much IT taking over someone 's machine during work hours costs the company .
Do n't be confrontational , in fact act stupid , like you really do n't know what you are asking and you are truly interested in an answer .
Whatever the response is nod , accept it , say thanks and drop it , talk about sports or something else .
The question will eat away at the PHB and he 'll eventually start asking questions.IT should NEVER EVER take over a machine during work hours unless the employee is needed to assist , and even then it should be a scheduled thing .
It 's been my experience that IT thinks they are important .
There is only one business where IT people are actually the people making the company money and that 's IT service companies .
Otherwise the people they are interrupting are the ones that make the money that pay for their job .
IT taking control of a machine for an hour during work hours could cost the company hundreds and even thousands of dollars in lost revenue .
All machine maintenance should be done after general work hours , if needed the IT department should work such that one of the IT employees is on staff in the middle of the night to do such maintenance .</tokentext>
<sentencetext>The IT manager should be fired.If you ever get a real PHB's ear (preferably one that manages budgets) privately for a few minutes you should ask them if they have ever evaluated how much IT taking over someone's machine during work hours costs the company.
Don't be confrontational, in fact act stupid, like you really don't know what you are asking and you are truly interested in an answer.
Whatever the response is nod, accept it, say thanks and drop it, talk about sports or something else.
The question will eat away at the PHB and he'll eventually start asking questions.IT should NEVER EVER take over a machine during work hours unless the employee is needed to assist, and even then it should be a scheduled thing.
It's been my experience that IT thinks they are important.
There is only one business where IT people are actually the people making the company money and that's IT service companies.
Otherwise the people they are interrupting are the ones that make the money that pay for their job.
IT taking control of a machine for an hour during work hours could cost the company hundreds and even thousands of dollars in lost revenue.
All machine maintenance should be done after general work hours, if needed the IT department should work such that one of the IT employees is on staff in the middle of the night to do such maintenance.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607476</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611940</id>
	<title>Re:Worked in Both Worlds...</title>
	<author>Anonymous</author>
	<datestamp>1262274000000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>I work in a similar environment. We dont really have a choice regarding the way of doing things.</p><p>While we have full admin access to the production system getting to it requires a helicopter trip to the oil rig, a trip to the server room, and a permit from the owner<nobr> <wbr></nobr>;)</p><p>Right now we use a system of vmware virtual servers for most testing on system functionality with exceptions on the "safety" parts which require testing on identical hardware (down to the bios revision of each network adapter.. anal but needed).</p><p>I personally like it that way. I've made some fuckups and had they been done on the real system I could have caused a multi-million dollar shutdown. I really dont want to do that for obvous reasons<nobr> <wbr></nobr>:-p</p><p>Most of the software developed require admin rights to even start... so all workstations have local admin unless you ask for a lesser account or make one yourself (some manageres prefer it).</p><p>I dont find the system a pain in the ass. The IT Security people though..... god I hate them. "Firefox is classified as dangerous software due to it being open source. All open source software is by definition not secure due to the open nature of the product. We will not validate any form of open software for use in ***** due to the lack of accountability and control." (not quite the wording, but yeah.... kill me/them now?)</p><p>*goes back to being grumpy*</p></htmltext>
<tokenext>I work in a similar environment .
We dont really have a choice regarding the way of doing things.While we have full admin access to the production system getting to it requires a helicopter trip to the oil rig , a trip to the server room , and a permit from the owner ; ) Right now we use a system of vmware virtual servers for most testing on system functionality with exceptions on the " safety " parts which require testing on identical hardware ( down to the bios revision of each network adapter.. anal but needed ) .I personally like it that way .
I 've made some fuckups and had they been done on the real system I could have caused a multi-million dollar shutdown .
I really dont want to do that for obvous reasons : -pMost of the software developed require admin rights to even start... so all workstations have local admin unless you ask for a lesser account or make one yourself ( some manageres prefer it ) .I dont find the system a pain in the ass .
The IT Security people though..... god I hate them .
" Firefox is classified as dangerous software due to it being open source .
All open source software is by definition not secure due to the open nature of the product .
We will not validate any form of open software for use in * * * * * due to the lack of accountability and control .
" ( not quite the wording , but yeah.... kill me/them now ?
) * goes back to being grumpy *</tokentext>
<sentencetext>I work in a similar environment.
We dont really have a choice regarding the way of doing things.While we have full admin access to the production system getting to it requires a helicopter trip to the oil rig, a trip to the server room, and a permit from the owner ;)Right now we use a system of vmware virtual servers for most testing on system functionality with exceptions on the "safety" parts which require testing on identical hardware (down to the bios revision of each network adapter.. anal but needed).I personally like it that way.
I've made some fuckups and had they been done on the real system I could have caused a multi-million dollar shutdown.
I really dont want to do that for obvous reasons :-pMost of the software developed require admin rights to even start... so all workstations have local admin unless you ask for a lesser account or make one yourself (some manageres prefer it).I dont find the system a pain in the ass.
The IT Security people though..... god I hate them.
"Firefox is classified as dangerous software due to it being open source.
All open source software is by definition not secure due to the open nature of the product.
We will not validate any form of open software for use in ***** due to the lack of accountability and control.
" (not quite the wording, but yeah.... kill me/them now?
)*goes back to being grumpy*</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607448</id>
	<title>Conversation with the company's head IT admin</title>
	<author>PinchDuck</author>
	<datestamp>1262285160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>"You know the company policy, but now I will ask you directly: Do you have any software on your computer that I have not personally reviewed?"<br>Yes<br>"WHY?!?!"<br>Because I write it. It's my job, and I don't have time to submit every program I write to you for approval before I install it on my machine to test it.<br>Admin Draws deep breath...<br>"AND...that makes sense. OK, you can have admin privileges on this machine".</p><p>I know places that don't give their devs admin privileges. It makes their jobs much harder. Security has to make sense to keep a corporate network safe, not to inconvenience everyone or make their jobs harder.</p></htmltext>
<tokenext>" You know the company policy , but now I will ask you directly : Do you have any software on your computer that I have not personally reviewed ? " Yes " WHY ? ! ? !
" Because I write it .
It 's my job , and I do n't have time to submit every program I write to you for approval before I install it on my machine to test it.Admin Draws deep breath... " AND...that makes sense .
OK , you can have admin privileges on this machine " .I know places that do n't give their devs admin privileges .
It makes their jobs much harder .
Security has to make sense to keep a corporate network safe , not to inconvenience everyone or make their jobs harder .</tokentext>
<sentencetext>"You know the company policy, but now I will ask you directly: Do you have any software on your computer that I have not personally reviewed?"Yes"WHY?!?!
"Because I write it.
It's my job, and I don't have time to submit every program I write to you for approval before I install it on my machine to test it.Admin Draws deep breath..."AND...that makes sense.
OK, you can have admin privileges on this machine".I know places that don't give their devs admin privileges.
It makes their jobs much harder.
Security has to make sense to keep a corporate network safe, not to inconvenience everyone or make their jobs harder.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30614634</id>
	<title>Re:Virtualization is your Friend</title>
	<author>Cederic</author>
	<datestamp>1230831780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My team doesn't do development and doesn't do system admin. We also happen to have the skills in the team to build and replace any system in the company, from the tin to the UI, including the storage, networks and telephony.</p><p>We demand local admin access and get it, because frankly we're good as a team to do any job in IT (and between the team have done every job in IT, below IT director - but we're already operating at that level compared with smaller organisations).</p><p>Sometimes our kit goes wrong. Occasionally (but rarely) it's our own fault. Unless we need new parts or access to production settings we don't have, we fix it ourselves. When the issue needs access to (e.g.) a domain controller, we log the helpdesk call and give step by step instructions on how to fix it.</p><p>Should we have admin access? Probably not. Are we more effective as a team by having it? Definitely. Is it better for the company for us to have this access? The CIO (that signed it off for us) agreed.</p><p>Would a VM work? Frankly, no. Especially as a developer, but even in my current role. The whole benefit of modern software systems is their integration, and isolating half your tools in a VM breaks that.</p></htmltext>
<tokenext>My team does n't do development and does n't do system admin .
We also happen to have the skills in the team to build and replace any system in the company , from the tin to the UI , including the storage , networks and telephony.We demand local admin access and get it , because frankly we 're good as a team to do any job in IT ( and between the team have done every job in IT , below IT director - but we 're already operating at that level compared with smaller organisations ) .Sometimes our kit goes wrong .
Occasionally ( but rarely ) it 's our own fault .
Unless we need new parts or access to production settings we do n't have , we fix it ourselves .
When the issue needs access to ( e.g .
) a domain controller , we log the helpdesk call and give step by step instructions on how to fix it.Should we have admin access ?
Probably not .
Are we more effective as a team by having it ?
Definitely. Is it better for the company for us to have this access ?
The CIO ( that signed it off for us ) agreed.Would a VM work ?
Frankly , no .
Especially as a developer , but even in my current role .
The whole benefit of modern software systems is their integration , and isolating half your tools in a VM breaks that .</tokentext>
<sentencetext>My team doesn't do development and doesn't do system admin.
We also happen to have the skills in the team to build and replace any system in the company, from the tin to the UI, including the storage, networks and telephony.We demand local admin access and get it, because frankly we're good as a team to do any job in IT (and between the team have done every job in IT, below IT director - but we're already operating at that level compared with smaller organisations).Sometimes our kit goes wrong.
Occasionally (but rarely) it's our own fault.
Unless we need new parts or access to production settings we don't have, we fix it ourselves.
When the issue needs access to (e.g.
) a domain controller, we log the helpdesk call and give step by step instructions on how to fix it.Should we have admin access?
Probably not.
Are we more effective as a team by having it?
Definitely. Is it better for the company for us to have this access?
The CIO (that signed it off for us) agreed.Would a VM work?
Frankly, no.
Especially as a developer, but even in my current role.
The whole benefit of modern software systems is their integration, and isolating half your tools in a VM breaks that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606708</id>
	<title>In some companies</title>
	<author>maroberts</author>
	<datestamp>1262282520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Sarbanes Oxley separation of roles requirements have been interpreted to mean that developers should not also be admins.</htmltext>
<tokenext>Sarbanes Oxley separation of roles requirements have been interpreted to mean that developers should not also be admins .</tokentext>
<sentencetext>Sarbanes Oxley separation of roles requirements have been interpreted to mean that developers should not also be admins.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607234</id>
	<title>We have superuser rights for our own machines...</title>
	<author>TofuMatt</author>
	<datestamp>1262284380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A few developers (i.e. the 5-person team I'm on) in my organization (government) have superuser privileges on their own machines (Macs) and a few of us can sudo on our local Xserve (which is totally internal and run by us/our local Mac sysadmin, not the "corporate" IT folks) to do things like read log files, update MacPorts, etc. We don't have superuser privileges on any of the production servers (though we should have a bit more flexibility than we have on said servers, which could be setup through sudo without allowing us the ability to change software on the machine, etc.).</p></htmltext>
<tokenext>A few developers ( i.e .
the 5-person team I 'm on ) in my organization ( government ) have superuser privileges on their own machines ( Macs ) and a few of us can sudo on our local Xserve ( which is totally internal and run by us/our local Mac sysadmin , not the " corporate " IT folks ) to do things like read log files , update MacPorts , etc .
We do n't have superuser privileges on any of the production servers ( though we should have a bit more flexibility than we have on said servers , which could be setup through sudo without allowing us the ability to change software on the machine , etc .
) .</tokentext>
<sentencetext>A few developers (i.e.
the 5-person team I'm on) in my organization (government) have superuser privileges on their own machines (Macs) and a few of us can sudo on our local Xserve (which is totally internal and run by us/our local Mac sysadmin, not the "corporate" IT folks) to do things like read log files, update MacPorts, etc.
We don't have superuser privileges on any of the production servers (though we should have a bit more flexibility than we have on said servers, which could be setup through sudo without allowing us the ability to change software on the machine, etc.
).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607308</id>
	<title>Re:You damn well should</title>
	<author>AvitarX</author>
	<datestamp>1262284680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>And unfortunately, most developers have little regard for the difference between USER and ROOT (or equivalent).</i></p><p>This is very very true.  If they did running as a non-admin would be much easier.  I have some trade software that still requires it, but very simple stuff (document display).</p></htmltext>
<tokenext>And unfortunately , most developers have little regard for the difference between USER and ROOT ( or equivalent ) .This is very very true .
If they did running as a non-admin would be much easier .
I have some trade software that still requires it , but very simple stuff ( document display ) .</tokentext>
<sentencetext>And unfortunately, most developers have little regard for the difference between USER and ROOT (or equivalent).This is very very true.
If they did running as a non-admin would be much easier.
I have some trade software that still requires it, but very simple stuff (document display).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609900</id>
	<title>Re:Generally, yes</title>
	<author>nine-times</author>
	<datestamp>1262254680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>DOMAIN ADMIN?!  Jiminy Cricket, please tell me that's some kind of test domain or that you're such a small company that your IT staff and developers are the same people.</p></htmltext>
<tokenext>DOMAIN ADMIN ? !
Jiminy Cricket , please tell me that 's some kind of test domain or that you 're such a small company that your IT staff and developers are the same people .</tokentext>
<sentencetext>DOMAIN ADMIN?!
Jiminy Cricket, please tell me that's some kind of test domain or that you're such a small company that your IT staff and developers are the same people.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606482</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608034</id>
	<title>use a vm</title>
	<author>Anonymous</author>
	<datestamp>1262287500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>at my medium sized financial company, we remove developers local admin rights on their laptops and give them a VM to develop on/break.</p></htmltext>
<tokenext>at my medium sized financial company , we remove developers local admin rights on their laptops and give them a VM to develop on/break .</tokentext>
<sentencetext>at my medium sized financial company, we remove developers local admin rights on their laptops and give them a VM to develop on/break.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607834</id>
	<title>Local? Try Global....</title>
	<author>bugg\_tb</author>
	<datestamp>1262286600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I just left a company after 3 years. What amazed me(as a developer) was that not only did we have local admin rights, we had global rights. This was ok for me as I have an element of sysadmin understanding, but my ex boss who used to be an administrator but now runs the BI systems did quite 'get' admin rights and the systems we ran. <br> <br>
Every day he'd randomly reboot servers, install different software in different places and generally make administration and licencing a nightmare. Also as a developer he didn't really have a clue as to how to organize things properly so things like SQL Server could only run one database on one machine, if he'd actually asked around (ie the sys admins) things would have been far easier, and I wouldn't have quit.
<br> <br>
So in a nutshell testing servers with admin rights, fair enough, online servers with admin rights, don't let developers near them.</htmltext>
<tokenext>I just left a company after 3 years .
What amazed me ( as a developer ) was that not only did we have local admin rights , we had global rights .
This was ok for me as I have an element of sysadmin understanding , but my ex boss who used to be an administrator but now runs the BI systems did quite 'get ' admin rights and the systems we ran .
Every day he 'd randomly reboot servers , install different software in different places and generally make administration and licencing a nightmare .
Also as a developer he did n't really have a clue as to how to organize things properly so things like SQL Server could only run one database on one machine , if he 'd actually asked around ( ie the sys admins ) things would have been far easier , and I would n't have quit .
So in a nutshell testing servers with admin rights , fair enough , online servers with admin rights , do n't let developers near them .</tokentext>
<sentencetext>I just left a company after 3 years.
What amazed me(as a developer) was that not only did we have local admin rights, we had global rights.
This was ok for me as I have an element of sysadmin understanding, but my ex boss who used to be an administrator but now runs the BI systems did quite 'get' admin rights and the systems we ran.
Every day he'd randomly reboot servers, install different software in different places and generally make administration and licencing a nightmare.
Also as a developer he didn't really have a clue as to how to organize things properly so things like SQL Server could only run one database on one machine, if he'd actually asked around (ie the sys admins) things would have been far easier, and I wouldn't have quit.
So in a nutshell testing servers with admin rights, fair enough, online servers with admin rights, don't let developers near them.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608912</id>
	<title>Yes at my work</title>
	<author>Wamoc</author>
	<datestamp>1262292120000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext>At my work, the computers we use "belong" to the employees. We pick our OS and what software we run. The sales people and others are just given a standard Windows install and they are restricted some. Developers do what we want with our machines.

As far as servers go, we all have some access, the senior programmers have full admin, while the rest of us have partial. We often have to deal with stuff quickly that getting one of a few IT people to do is too inefficient, and takes too long to do.</htmltext>
<tokenext>At my work , the computers we use " belong " to the employees .
We pick our OS and what software we run .
The sales people and others are just given a standard Windows install and they are restricted some .
Developers do what we want with our machines .
As far as servers go , we all have some access , the senior programmers have full admin , while the rest of us have partial .
We often have to deal with stuff quickly that getting one of a few IT people to do is too inefficient , and takes too long to do .</tokentext>
<sentencetext>At my work, the computers we use "belong" to the employees.
We pick our OS and what software we run.
The sales people and others are just given a standard Windows install and they are restricted some.
Developers do what we want with our machines.
As far as servers go, we all have some access, the senior programmers have full admin, while the rest of us have partial.
We often have to deal with stuff quickly that getting one of a few IT people to do is too inefficient, and takes too long to do.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611982</id>
	<title>In *nix no...</title>
	<author>FishNiX</author>
	<datestamp>1262274660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Developers have total control over their workstation and "Sandbox" lives there in a VM.  Developers have limited rights to the "development" environment where they can test things like deployment process and make some changes.  In TEST, they have no rights (can't even login) and in PROD obviously no rights.  Patch also often exists and is used by SA's only.  I work for a large university where we support a lot of different apps in a fairly heterogenious environment not one or two products like I have in the past in corporate environments, it works well IMO once the developers get the idea that they have to get things mostly right before moving into DEV.</p></htmltext>
<tokenext>Developers have total control over their workstation and " Sandbox " lives there in a VM .
Developers have limited rights to the " development " environment where they can test things like deployment process and make some changes .
In TEST , they have no rights ( ca n't even login ) and in PROD obviously no rights .
Patch also often exists and is used by SA 's only .
I work for a large university where we support a lot of different apps in a fairly heterogenious environment not one or two products like I have in the past in corporate environments , it works well IMO once the developers get the idea that they have to get things mostly right before moving into DEV .</tokentext>
<sentencetext>Developers have total control over their workstation and "Sandbox" lives there in a VM.
Developers have limited rights to the "development" environment where they can test things like deployment process and make some changes.
In TEST, they have no rights (can't even login) and in PROD obviously no rights.
Patch also often exists and is used by SA's only.
I work for a large university where we support a lot of different apps in a fairly heterogenious environment not one or two products like I have in the past in corporate environments, it works well IMO once the developers get the idea that they have to get things mostly right before moving into DEV.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608444</id>
	<title>NO NO NO Admin rights!!!!!!</title>
	<author>Anonymous</author>
	<datestamp>1262289660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Here is my 2 cents.  I do not think they should have admin rights to their local machines.  These are workstations that are issued to perform a job and that is to code.  Once your tools are installed there shouldn't be any reason to need admin rights.  You should however have a virtual test environment with something like VMware workstation where you would have several OS's loaded in there one with admin rights to test your installs, and debug. Absolutly your application you are writing should be fully tested without admin rights.  I cannot tell you how it burns me up to have a vendor tell me to give a user admin rights to solve an issue with an application.</p></htmltext>
<tokenext>Here is my 2 cents .
I do not think they should have admin rights to their local machines .
These are workstations that are issued to perform a job and that is to code .
Once your tools are installed there should n't be any reason to need admin rights .
You should however have a virtual test environment with something like VMware workstation where you would have several OS 's loaded in there one with admin rights to test your installs , and debug .
Absolutly your application you are writing should be fully tested without admin rights .
I can not tell you how it burns me up to have a vendor tell me to give a user admin rights to solve an issue with an application .</tokentext>
<sentencetext>Here is my 2 cents.
I do not think they should have admin rights to their local machines.
These are workstations that are issued to perform a job and that is to code.
Once your tools are installed there shouldn't be any reason to need admin rights.
You should however have a virtual test environment with something like VMware workstation where you would have several OS's loaded in there one with admin rights to test your installs, and debug.
Absolutly your application you are writing should be fully tested without admin rights.
I cannot tell you how it burns me up to have a vendor tell me to give a user admin rights to solve an issue with an application.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612746</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262288520000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'm amazed I haven't seen (or perhaps missed it) VMware mentioned here.  The desktop version is cheap and provides an excellent means for testing and deployment in a production environment.  Make sure your VM's are configured the same way that your production machines are configured and you can snapshot, deploy, test, revert, and repeat as often as needed.</p></htmltext>
<tokenext>I 'm amazed I have n't seen ( or perhaps missed it ) VMware mentioned here .
The desktop version is cheap and provides an excellent means for testing and deployment in a production environment .
Make sure your VM 's are configured the same way that your production machines are configured and you can snapshot , deploy , test , revert , and repeat as often as needed .</tokentext>
<sentencetext>I'm amazed I haven't seen (or perhaps missed it) VMware mentioned here.
The desktop version is cheap and provides an excellent means for testing and deployment in a production environment.
Make sure your VM's are configured the same way that your production machines are configured and you can snapshot, deploy, test, revert, and repeat as often as needed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610458</id>
	<title>Re:Yes</title>
	<author>Alpha830RulZ</author>
	<datestamp>1262258160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>We do our builds on a pool of linux machines, in a continuous build cycle, so that isn't really a problem.</p><p>In the case I noted, the gal turned the AV off specifically because she needed to move some files around, and was thinking it was taking too long.  The real problem was the ancient hub that her machine was plugged into.</p></htmltext>
<tokenext>We do our builds on a pool of linux machines , in a continuous build cycle , so that is n't really a problem.In the case I noted , the gal turned the AV off specifically because she needed to move some files around , and was thinking it was taking too long .
The real problem was the ancient hub that her machine was plugged into .</tokentext>
<sentencetext>We do our builds on a pool of linux machines, in a continuous build cycle, so that isn't really a problem.In the case I noted, the gal turned the AV off specifically because she needed to move some files around, and was thinking it was taking too long.
The real problem was the ancient hub that her machine was plugged into.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608266</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618398</id>
	<title>No, no, no.</title>
	<author>jotaeleemeese</author>
	<datestamp>1230820980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Unless developers assume responsibility for the security for the infrastructure they are working with, then they should not be given admin rights.</p><p>My ass in the fire? Then the admin password is mine only.</p><p>When developers join a firm there should be a standard set of utilities used internally which the developers must use. Developers should not pick and choose whatever they want, that is a recipe for disaster and a technological nightmare. And what about the licensing? Are the developers going to report all the software they install accurately for licensing purposes (even good admins have problems with this at times).</p><p>In return development teams should have speedy service, and once a tool is identified as essential it should be installed promptly.</p><p>But give admin rights to developers? Nope.</p></htmltext>
<tokenext>Unless developers assume responsibility for the security for the infrastructure they are working with , then they should not be given admin rights.My ass in the fire ?
Then the admin password is mine only.When developers join a firm there should be a standard set of utilities used internally which the developers must use .
Developers should not pick and choose whatever they want , that is a recipe for disaster and a technological nightmare .
And what about the licensing ?
Are the developers going to report all the software they install accurately for licensing purposes ( even good admins have problems with this at times ) .In return development teams should have speedy service , and once a tool is identified as essential it should be installed promptly.But give admin rights to developers ?
Nope .</tokentext>
<sentencetext>Unless developers assume responsibility for the security for the infrastructure they are working with, then they should not be given admin rights.My ass in the fire?
Then the admin password is mine only.When developers join a firm there should be a standard set of utilities used internally which the developers must use.
Developers should not pick and choose whatever they want, that is a recipe for disaster and a technological nightmare.
And what about the licensing?
Are the developers going to report all the software they install accurately for licensing purposes (even good admins have problems with this at times).In return development teams should have speedy service, and once a tool is identified as essential it should be installed promptly.But give admin rights to developers?
Nope.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607934</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607356</id>
	<title>Re:You damn well should</title>
	<author>Darkness404</author>
	<datestamp>1262284800000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>Thats why you do the sane thing and you know, isolate those systems. Guess what? Development boxes aren't mission critical, if 5 of them go down you just shrug and run to the local computer store and buy the components or a new system for them. Usually development systems are a bit faster than the typical workstation (you don't want <a href="http://imgs.xkcd.com/comics/compiling.png" title="xkcd.com">http://imgs.xkcd.com/comics/compiling.png</a> [xkcd.com] to happen do you?), but can usually be hacked together from spare parts and not maintain uniformity that is critical for the rest of them. In general, other than software development stuff, not much else should be saved on a development machine. Same with testing. The way its set up for me (and I helped design some of it) is there are three classes of machines: Development, Testing, and Typical. On development machines they usually have generic, cheap and fast hardware, nothing saved onto the computer thats important, and developers have total admin rights over it, but they are isolated on a different network. Testing machines have the same hardware as the typical machines, the typical developer does not have admin rights except to install pre-approved things, and its hooked up to a network very similar to the one the typical machines are on. This lets us test patches, new software and other things before doing a company-wide rollout. And typical machines all have identical hardware, no admin rights for the users, and are hooked up to our main network.</htmltext>
<tokenext>Thats why you do the sane thing and you know , isolate those systems .
Guess what ?
Development boxes are n't mission critical , if 5 of them go down you just shrug and run to the local computer store and buy the components or a new system for them .
Usually development systems are a bit faster than the typical workstation ( you do n't want http : //imgs.xkcd.com/comics/compiling.png [ xkcd.com ] to happen do you ?
) , but can usually be hacked together from spare parts and not maintain uniformity that is critical for the rest of them .
In general , other than software development stuff , not much else should be saved on a development machine .
Same with testing .
The way its set up for me ( and I helped design some of it ) is there are three classes of machines : Development , Testing , and Typical .
On development machines they usually have generic , cheap and fast hardware , nothing saved onto the computer thats important , and developers have total admin rights over it , but they are isolated on a different network .
Testing machines have the same hardware as the typical machines , the typical developer does not have admin rights except to install pre-approved things , and its hooked up to a network very similar to the one the typical machines are on .
This lets us test patches , new software and other things before doing a company-wide rollout .
And typical machines all have identical hardware , no admin rights for the users , and are hooked up to our main network .</tokentext>
<sentencetext>Thats why you do the sane thing and you know, isolate those systems.
Guess what?
Development boxes aren't mission critical, if 5 of them go down you just shrug and run to the local computer store and buy the components or a new system for them.
Usually development systems are a bit faster than the typical workstation (you don't want http://imgs.xkcd.com/comics/compiling.png [xkcd.com] to happen do you?
), but can usually be hacked together from spare parts and not maintain uniformity that is critical for the rest of them.
In general, other than software development stuff, not much else should be saved on a development machine.
Same with testing.
The way its set up for me (and I helped design some of it) is there are three classes of machines: Development, Testing, and Typical.
On development machines they usually have generic, cheap and fast hardware, nothing saved onto the computer thats important, and developers have total admin rights over it, but they are isolated on a different network.
Testing machines have the same hardware as the typical machines, the typical developer does not have admin rights except to install pre-approved things, and its hooked up to a network very similar to the one the typical machines are on.
This lets us test patches, new software and other things before doing a company-wide rollout.
And typical machines all have identical hardware, no admin rights for the users, and are hooked up to our main network.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608532</id>
	<title>Yes on Windows, no on UNIX</title>
	<author>gregor-e</author>
	<datestamp>1262290140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Folks in our department have local admin on our own PCs, but it's like pulling teeth to get InfoSec to grant it.  (I think it requires VP approval for each PC).  On the other hand, we are under no circumstances given root to our Linux servers, not even our dev boxes.  Not even on virtual machines running Linux.  This is a huge PITA.  I can't count the times a five-minute change like adding an entry to tnsnames.ora has ended up taking hours or days to complete through the 'create a ticket' method.  Even worse than slowing down mundane tasks, it stifles any exploration of alternative tools.  Unfortunately, this sort of intangible 'innovation cost' will never show up on any objective cost/benefit analysis.</htmltext>
<tokenext>Folks in our department have local admin on our own PCs , but it 's like pulling teeth to get InfoSec to grant it .
( I think it requires VP approval for each PC ) .
On the other hand , we are under no circumstances given root to our Linux servers , not even our dev boxes .
Not even on virtual machines running Linux .
This is a huge PITA .
I ca n't count the times a five-minute change like adding an entry to tnsnames.ora has ended up taking hours or days to complete through the 'create a ticket ' method .
Even worse than slowing down mundane tasks , it stifles any exploration of alternative tools .
Unfortunately , this sort of intangible 'innovation cost ' will never show up on any objective cost/benefit analysis .</tokentext>
<sentencetext>Folks in our department have local admin on our own PCs, but it's like pulling teeth to get InfoSec to grant it.
(I think it requires VP approval for each PC).
On the other hand, we are under no circumstances given root to our Linux servers, not even our dev boxes.
Not even on virtual machines running Linux.
This is a huge PITA.
I can't count the times a five-minute change like adding an entry to tnsnames.ora has ended up taking hours or days to complete through the 'create a ticket' method.
Even worse than slowing down mundane tasks, it stifles any exploration of alternative tools.
Unfortunately, this sort of intangible 'innovation cost' will never show up on any objective cost/benefit analysis.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607662</id>
	<title>Social engineering attack</title>
	<author>Anonymous</author>
	<datestamp>1262286000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It's trivial to get admin priveleges.  You are a developer after all.  Just develop/package your own backdoor trojan/etc that gets installed with root priveleges.  Then get those fancy administrators to install it for you with their admin rights.

If they ask what it is, tell them its some libraries for a development project.  The number of times you'll be asked will be next to nil though.   Voila, you can do what you want after that.

Not that I've done it, but on the unix side, you could ask for a sudo exception for a program that's in a directory that's writable to you.  Boom you have root any time you need it.

You're a developer!  Use your skills!

Yeah yeah, there are some HIDS systems that will catch this sort of thing, but there are ways around that too.  After all your root/admin at some point.

If you don't trust your developers with root, then you shouldn't trust their code!</htmltext>
<tokenext>It 's trivial to get admin priveleges .
You are a developer after all .
Just develop/package your own backdoor trojan/etc that gets installed with root priveleges .
Then get those fancy administrators to install it for you with their admin rights .
If they ask what it is , tell them its some libraries for a development project .
The number of times you 'll be asked will be next to nil though .
Voila , you can do what you want after that .
Not that I 've done it , but on the unix side , you could ask for a sudo exception for a program that 's in a directory that 's writable to you .
Boom you have root any time you need it .
You 're a developer !
Use your skills !
Yeah yeah , there are some HIDS systems that will catch this sort of thing , but there are ways around that too .
After all your root/admin at some point .
If you do n't trust your developers with root , then you should n't trust their code !</tokentext>
<sentencetext>It's trivial to get admin priveleges.
You are a developer after all.
Just develop/package your own backdoor trojan/etc that gets installed with root priveleges.
Then get those fancy administrators to install it for you with their admin rights.
If they ask what it is, tell them its some libraries for a development project.
The number of times you'll be asked will be next to nil though.
Voila, you can do what you want after that.
Not that I've done it, but on the unix side, you could ask for a sudo exception for a program that's in a directory that's writable to you.
Boom you have root any time you need it.
You're a developer!
Use your skills!
Yeah yeah, there are some HIDS systems that will catch this sort of thing, but there are ways around that too.
After all your root/admin at some point.
If you don't trust your developers with root, then you shouldn't trust their code!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607028</id>
	<title>Heck, with Visual Studio, its nearly required!</title>
	<author>LS1 Brains</author>
	<datestamp>1262283540000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext>Who here, at some point in developing with Visual Studio, NOT seen it pop up that stupid message saying you have to run the IDE with administrator privileges for something or another?
<br> <br>Here's a quick link with just a few of the examples:<br>
<a href="http://msdn.microsoft.com/en-us/library/ms165100.aspx" title="microsoft.com" rel="nofollow">msdn.microsoft.com</a> [microsoft.com]</htmltext>
<tokenext>Who here , at some point in developing with Visual Studio , NOT seen it pop up that stupid message saying you have to run the IDE with administrator privileges for something or another ?
Here 's a quick link with just a few of the examples : msdn.microsoft.com [ microsoft.com ]</tokentext>
<sentencetext>Who here, at some point in developing with Visual Studio, NOT seen it pop up that stupid message saying you have to run the IDE with administrator privileges for something or another?
Here's a quick link with just a few of the examples:
msdn.microsoft.com [microsoft.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30680176</id>
	<title>Re:Local admin rights?</title>
	<author>xiong.chiamiov</author>
	<datestamp>1231321740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Why not simply work on virtual machines? Then you know they are clean and you can have all the rights you want and still have comply with company rules.
</p></div><p>VMs generally restrict a lot of keycombos, which is deathly important to some of us.</p></div>
	</htmltext>
<tokenext>Why not simply work on virtual machines ?
Then you know they are clean and you can have all the rights you want and still have comply with company rules .
VMs generally restrict a lot of keycombos , which is deathly important to some of us .</tokentext>
<sentencetext>Why not simply work on virtual machines?
Then you know they are clean and you can have all the rights you want and still have comply with company rules.
VMs generally restrict a lot of keycombos, which is deathly important to some of us.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607042</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606882</id>
	<title>Re:Hell no.</title>
	<author>istartedi</author>
	<datestamp>1262283060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Oh man, it sounds like there was no clear
separation of departments there.  I thought
I had problems!</p><p>Some people have "admin sensibility" and
some don't.  I know I don't, so when somebody
asked me if I wanted root on some box, I always
said "NO!".</p><p>I knew there was no upside to me having root
on a server.  The one or two guys who had assumed the role
of admin, and were comfortable doing it, it was easier
to ask them for things.  If it was a stupid
idea for the server, they'd reject it.  They wouldn't
fat-finger some command, because they did it all the time.
It was their specialty.</p><p>OTOH, you'd have to pry admin on my workstation from
my cold dead hands.  I could and did occasionaly crash
that box; but the damage was limited to the work that
wasn't checked in and my time spent rebuilding the box.</p></htmltext>
<tokenext>Oh man , it sounds like there was no clear separation of departments there .
I thought I had problems ! Some people have " admin sensibility " and some do n't .
I know I do n't , so when somebody asked me if I wanted root on some box , I always said " NO !
" .I knew there was no upside to me having root on a server .
The one or two guys who had assumed the role of admin , and were comfortable doing it , it was easier to ask them for things .
If it was a stupid idea for the server , they 'd reject it .
They would n't fat-finger some command , because they did it all the time .
It was their specialty.OTOH , you 'd have to pry admin on my workstation from my cold dead hands .
I could and did occasionaly crash that box ; but the damage was limited to the work that was n't checked in and my time spent rebuilding the box .</tokentext>
<sentencetext>Oh man, it sounds like there was no clear
separation of departments there.
I thought
I had problems!Some people have "admin sensibility" and
some don't.
I know I don't, so when somebody
asked me if I wanted root on some box, I always
said "NO!
".I knew there was no upside to me having root
on a server.
The one or two guys who had assumed the role
of admin, and were comfortable doing it, it was easier
to ask them for things.
If it was a stupid
idea for the server, they'd reject it.
They wouldn't
fat-finger some command, because they did it all the time.
It was their specialty.OTOH, you'd have to pry admin on my workstation from
my cold dead hands.
I could and did occasionaly crash
that box; but the damage was limited to the work that
wasn't checked in and my time spent rebuilding the box.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611660</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262269860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Good post, except that you don;t seem to clearly differentiated between the different types of development machines (this is assuming writing software for a server, rather than writing packaged software.</p><p>You have the prodution servers.</p><p>You have the near-production test servers. These will be running the current's code, or perhaps the stable branch when you are close to a push to production. These should be a near to identical to production as can be done, with load simulations etc if viable.</p><p>You may have other test machines for personal tests by developers of incomplete code to ensure what is written performs as expected. These can usually drift a bit further from production than the near production test servers. These machines are not critical, and can be omitted in some environments.</p><p>Lastly you have the machines that developers write code on. These are very much non-mission critical. The biggest concern with them is that they don't infect the rest of the network, and that they have a minimal level of security, since they likely will contain the full source for the application in question, and perhaps even history in the case of certain version control systems. Developers should be taught security concepts thanks to the latter, but otherwise have full control over these machines. If they want to use their own Frankensteinian coding software, that combines all sorts of software with a whole bunch of scripts tying everything together, that is fine (as long as the checked in code can be maintained and developed by others without requiring this setup).</p></htmltext>
<tokenext>Good post , except that you don ; t seem to clearly differentiated between the different types of development machines ( this is assuming writing software for a server , rather than writing packaged software.You have the prodution servers.You have the near-production test servers .
These will be running the current 's code , or perhaps the stable branch when you are close to a push to production .
These should be a near to identical to production as can be done , with load simulations etc if viable.You may have other test machines for personal tests by developers of incomplete code to ensure what is written performs as expected .
These can usually drift a bit further from production than the near production test servers .
These machines are not critical , and can be omitted in some environments.Lastly you have the machines that developers write code on .
These are very much non-mission critical .
The biggest concern with them is that they do n't infect the rest of the network , and that they have a minimal level of security , since they likely will contain the full source for the application in question , and perhaps even history in the case of certain version control systems .
Developers should be taught security concepts thanks to the latter , but otherwise have full control over these machines .
If they want to use their own Frankensteinian coding software , that combines all sorts of software with a whole bunch of scripts tying everything together , that is fine ( as long as the checked in code can be maintained and developed by others without requiring this setup ) .</tokentext>
<sentencetext>Good post, except that you don;t seem to clearly differentiated between the different types of development machines (this is assuming writing software for a server, rather than writing packaged software.You have the prodution servers.You have the near-production test servers.
These will be running the current's code, or perhaps the stable branch when you are close to a push to production.
These should be a near to identical to production as can be done, with load simulations etc if viable.You may have other test machines for personal tests by developers of incomplete code to ensure what is written performs as expected.
These can usually drift a bit further from production than the near production test servers.
These machines are not critical, and can be omitted in some environments.Lastly you have the machines that developers write code on.
These are very much non-mission critical.
The biggest concern with them is that they don't infect the rest of the network, and that they have a minimal level of security, since they likely will contain the full source for the application in question, and perhaps even history in the case of certain version control systems.
Developers should be taught security concepts thanks to the latter, but otherwise have full control over these machines.
If they want to use their own Frankensteinian coding software, that combines all sorts of software with a whole bunch of scripts tying everything together, that is fine (as long as the checked in code can be maintained and developed by others without requiring this setup).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608954</id>
	<title>Re:Yeah.</title>
	<author>Anonymous</author>
	<datestamp>1262292180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.</i> <br>
&nbsp; <br>at my last job it was the developers, twice, who got our Internet connection blackholed at the ISP from sending spam. One was a misconfiguration and the other was installing apps off crappy sites that had malware (testing they called it). None of the other users with local admin managed to cause nearly that level of damage. The dev's kept there local admin, but we blocked all ports going out of their vlan that were not mandatory. maybe your a fantastic, this would never happen kind of dev, but I've met a lot of dev's who didn't seem to have much network or security knowledge, enough so that I mentally pooled them together with the other users. What I advise is locked down vlan for your testing with local admin requirements, computers on the main use vlan's get the same lockdowns that any other user does - unless the company wants to spend extra money on the infrastructure techs taking time to go look at the dev machines.</p></htmltext>
<tokenext>The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management .
  at my last job it was the developers , twice , who got our Internet connection blackholed at the ISP from sending spam .
One was a misconfiguration and the other was installing apps off crappy sites that had malware ( testing they called it ) .
None of the other users with local admin managed to cause nearly that level of damage .
The dev 's kept there local admin , but we blocked all ports going out of their vlan that were not mandatory .
maybe your a fantastic , this would never happen kind of dev , but I 've met a lot of dev 's who did n't seem to have much network or security knowledge , enough so that I mentally pooled them together with the other users .
What I advise is locked down vlan for your testing with local admin requirements , computers on the main use vlan 's get the same lockdowns that any other user does - unless the company wants to spend extra money on the infrastructure techs taking time to go look at the dev machines .</tokentext>
<sentencetext>The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.
  at my last job it was the developers, twice, who got our Internet connection blackholed at the ISP from sending spam.
One was a misconfiguration and the other was installing apps off crappy sites that had malware (testing they called it).
None of the other users with local admin managed to cause nearly that level of damage.
The dev's kept there local admin, but we blocked all ports going out of their vlan that were not mandatory.
maybe your a fantastic, this would never happen kind of dev, but I've met a lot of dev's who didn't seem to have much network or security knowledge, enough so that I mentally pooled them together with the other users.
What I advise is locked down vlan for your testing with local admin requirements, computers on the main use vlan's get the same lockdowns that any other user does - unless the company wants to spend extra money on the infrastructure techs taking time to go look at the dev machines.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608684</id>
	<title>Re:Under no circumstances</title>
	<author>Anonymous</author>
	<datestamp>1262290920000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>-1</modscore>
	<htmltext><p>For fuck's sake learn to read.  Nobody (other than you and similar illiterate knee-jerk gauleiters) said anything about production.</p><p>Die in a fire, you petty bueracrat.</p></htmltext>
<tokenext>For fuck 's sake learn to read .
Nobody ( other than you and similar illiterate knee-jerk gauleiters ) said anything about production.Die in a fire , you petty bueracrat .</tokentext>
<sentencetext>For fuck's sake learn to read.
Nobody (other than you and similar illiterate knee-jerk gauleiters) said anything about production.Die in a fire, you petty bueracrat.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606710</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607480</id>
	<title>In part...</title>
	<author>MrWin2kMan</author>
	<datestamp>1262285220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>On their local workstations, yes. On their development boxes, yes. The Release Engineer should have control over the QA environment. It should mimic production as much as possible, so developers shouldn't have admin rights. On production, absolutely effing not.
The world of virtualization has provided new tools and methods to use for development purposes. These should be used to their fullest extent.</htmltext>
<tokenext>On their local workstations , yes .
On their development boxes , yes .
The Release Engineer should have control over the QA environment .
It should mimic production as much as possible , so developers should n't have admin rights .
On production , absolutely effing not .
The world of virtualization has provided new tools and methods to use for development purposes .
These should be used to their fullest extent .</tokentext>
<sentencetext>On their local workstations, yes.
On their development boxes, yes.
The Release Engineer should have control over the QA environment.
It should mimic production as much as possible, so developers shouldn't have admin rights.
On production, absolutely effing not.
The world of virtualization has provided new tools and methods to use for development purposes.
These should be used to their fullest extent.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607140</id>
	<title>Re:virtualization</title>
	<author>Courageous</author>
	<datestamp>1262283960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Hmmm. I think they're calling this client virtualization now. Desktop virtualization is where the desktop is in the data center.</p><p>Strange terminology, I know.</p></htmltext>
<tokenext>Hmmm .
I think they 're calling this client virtualization now .
Desktop virtualization is where the desktop is in the data center.Strange terminology , I know .</tokentext>
<sentencetext>Hmmm.
I think they're calling this client virtualization now.
Desktop virtualization is where the desktop is in the data center.Strange terminology, I know.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606524</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609820</id>
	<title>Not on linux boxes</title>
	<author>Flu</author>
	<datestamp>1262254200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'm currently working as a developer for a major player in the mobile industry. We're local admins on our windows boxes, but we're switching to Linux now, and are not given the ability to su our own linux boxes.<nobr> <wbr></nobr>:-(</htmltext>
<tokenext>I 'm currently working as a developer for a major player in the mobile industry .
We 're local admins on our windows boxes , but we 're switching to Linux now , and are not given the ability to su our own linux boxes .
: - (</tokentext>
<sentencetext>I'm currently working as a developer for a major player in the mobile industry.
We're local admins on our windows boxes, but we're switching to Linux now, and are not given the ability to su our own linux boxes.
:-(</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30680556</id>
	<title>Yup, got admin rights.</title>
	<author>crowne</author>
	<datestamp>1231327980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I had admin rights at my previous job, and I started a new job last monday with admin rights by monday afternoon.</htmltext>
<tokenext>I had admin rights at my previous job , and I started a new job last monday with admin rights by monday afternoon .</tokentext>
<sentencetext>I had admin rights at my previous job, and I started a new job last monday with admin rights by monday afternoon.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612002</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262274900000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Dude that is TOTALLY contradictory and if you can straighten it out the rest of the class would like to know how...</p><p>You go on a rant about how it is important to do.  Then turn around on a rant on exactly WHY you need to trust your help.</p><p>This company I currently work with I have been there for years and already have the privs I need.  But we just hired a new guy.  Extremely good at what he does (having worked with him before I know this).  However he hasnt coded 1 line of code in 2 months on his 'real box'.  He is waiting on management to decide he can have dev programs on his computer.  Just last week he finally got the privileges to do it.  My direct management is NOT happy about this.  And well they should be right pissed off about it.</p><p>In the mean time we gave him an unmanged computer to do his work.  This creates a natural 'grey net' in the real network.  Having managed my own networks in the past 'grey nets' are the worst breeding grounds of worms and viri.  As they are always out of date as the people setting them up forget to update them (yeah you know that VM you set up 2 years ago with the copy of NT4 on it and no virus/firewall/updates on it).  When IT is in the way of getting things done IT is the problem, creates a 'we vs them' mentality, and creates a computer management nightmare.  People will work around the problem.  One place a friend of mine he 'worked around the problem'.  He got shown the door.  Companies that put these policies in place are saying that the policy is more important than getting work done.  I am not saying policy is unimportant.  But you can go overboard with it and eventually your workers either walk or work around it.</p></htmltext>
<tokenext>Dude that is TOTALLY contradictory and if you can straighten it out the rest of the class would like to know how...You go on a rant about how it is important to do .
Then turn around on a rant on exactly WHY you need to trust your help.This company I currently work with I have been there for years and already have the privs I need .
But we just hired a new guy .
Extremely good at what he does ( having worked with him before I know this ) .
However he hasnt coded 1 line of code in 2 months on his 'real box' .
He is waiting on management to decide he can have dev programs on his computer .
Just last week he finally got the privileges to do it .
My direct management is NOT happy about this .
And well they should be right pissed off about it.In the mean time we gave him an unmanged computer to do his work .
This creates a natural 'grey net ' in the real network .
Having managed my own networks in the past 'grey nets ' are the worst breeding grounds of worms and viri .
As they are always out of date as the people setting them up forget to update them ( yeah you know that VM you set up 2 years ago with the copy of NT4 on it and no virus/firewall/updates on it ) .
When IT is in the way of getting things done IT is the problem , creates a 'we vs them ' mentality , and creates a computer management nightmare .
People will work around the problem .
One place a friend of mine he 'worked around the problem' .
He got shown the door .
Companies that put these policies in place are saying that the policy is more important than getting work done .
I am not saying policy is unimportant .
But you can go overboard with it and eventually your workers either walk or work around it .</tokentext>
<sentencetext>Dude that is TOTALLY contradictory and if you can straighten it out the rest of the class would like to know how...You go on a rant about how it is important to do.
Then turn around on a rant on exactly WHY you need to trust your help.This company I currently work with I have been there for years and already have the privs I need.
But we just hired a new guy.
Extremely good at what he does (having worked with him before I know this).
However he hasnt coded 1 line of code in 2 months on his 'real box'.
He is waiting on management to decide he can have dev programs on his computer.
Just last week he finally got the privileges to do it.
My direct management is NOT happy about this.
And well they should be right pissed off about it.In the mean time we gave him an unmanged computer to do his work.
This creates a natural 'grey net' in the real network.
Having managed my own networks in the past 'grey nets' are the worst breeding grounds of worms and viri.
As they are always out of date as the people setting them up forget to update them (yeah you know that VM you set up 2 years ago with the copy of NT4 on it and no virus/firewall/updates on it).
When IT is in the way of getting things done IT is the problem, creates a 'we vs them' mentality, and creates a computer management nightmare.
People will work around the problem.
One place a friend of mine he 'worked around the problem'.
He got shown the door.
Companies that put these policies in place are saying that the policy is more important than getting work done.
I am not saying policy is unimportant.
But you can go overboard with it and eventually your workers either walk or work around it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608716</id>
	<title>I've seen it done both ways</title>
	<author>PPH</author>
	<datestamp>1262291040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I wasn't a full time developer (engineer, mainly, but I did support some avionics test stuff) and I never did Windows. So take what I say with a grain of salt.
</p><p>I supported apps and system stuff on a half dozen *NIX systems. For development, I had several development environments set up on test hardware. I'd need root (admin) privileges to tweak the system config, install custom networking daemons, drivers, etc. But I had a plain old user account for use in testing modules and apps. I stayed off the root account unless absolutely necessary.
</p><p>Meanwhile, I worked alongside a bunch of Windows developers. They all had admin rights, developed everything as admin, tested it as admin and turned it over to the user community. Thanks to their 'bad habits' there were more than a few circumstances where their apps would not run unless their users also had admin rights. Toward the end of my career at that outfit, there was talk about taking their admin rights way, or enforcing practices similar to what I used voluntarily.
</p><p>I suspect (and perhaps some Windows folks can verify this) that there's a fundamental difference in the philosophy between being root on a *NIX box (a completely different user) and attaching admin privileges on Windows (same user, just more permission bits set). One thing that our Windows developer community appeared attached to was the ability (need? addiction?) to have access to their user space at all times when sitting at a desktop. Asking them to adopt a different user profile for developing/testing/installation/administration would have deprived them of the ability to do IE/Outlook, visit YouTube, etc. while their system was connected to some aircraft under test.
</p><p>I shudder to think of how many times someone was uploading new (classified) firmware into a fighter in one window while IE was prompting them to install that mystery CODEC in order to view some 'important' email message.</p></htmltext>
<tokenext>I was n't a full time developer ( engineer , mainly , but I did support some avionics test stuff ) and I never did Windows .
So take what I say with a grain of salt .
I supported apps and system stuff on a half dozen * NIX systems .
For development , I had several development environments set up on test hardware .
I 'd need root ( admin ) privileges to tweak the system config , install custom networking daemons , drivers , etc .
But I had a plain old user account for use in testing modules and apps .
I stayed off the root account unless absolutely necessary .
Meanwhile , I worked alongside a bunch of Windows developers .
They all had admin rights , developed everything as admin , tested it as admin and turned it over to the user community .
Thanks to their 'bad habits ' there were more than a few circumstances where their apps would not run unless their users also had admin rights .
Toward the end of my career at that outfit , there was talk about taking their admin rights way , or enforcing practices similar to what I used voluntarily .
I suspect ( and perhaps some Windows folks can verify this ) that there 's a fundamental difference in the philosophy between being root on a * NIX box ( a completely different user ) and attaching admin privileges on Windows ( same user , just more permission bits set ) .
One thing that our Windows developer community appeared attached to was the ability ( need ?
addiction ? ) to have access to their user space at all times when sitting at a desktop .
Asking them to adopt a different user profile for developing/testing/installation/administration would have deprived them of the ability to do IE/Outlook , visit YouTube , etc .
while their system was connected to some aircraft under test .
I shudder to think of how many times someone was uploading new ( classified ) firmware into a fighter in one window while IE was prompting them to install that mystery CODEC in order to view some 'important ' email message .</tokentext>
<sentencetext>I wasn't a full time developer (engineer, mainly, but I did support some avionics test stuff) and I never did Windows.
So take what I say with a grain of salt.
I supported apps and system stuff on a half dozen *NIX systems.
For development, I had several development environments set up on test hardware.
I'd need root (admin) privileges to tweak the system config, install custom networking daemons, drivers, etc.
But I had a plain old user account for use in testing modules and apps.
I stayed off the root account unless absolutely necessary.
Meanwhile, I worked alongside a bunch of Windows developers.
They all had admin rights, developed everything as admin, tested it as admin and turned it over to the user community.
Thanks to their 'bad habits' there were more than a few circumstances where their apps would not run unless their users also had admin rights.
Toward the end of my career at that outfit, there was talk about taking their admin rights way, or enforcing practices similar to what I used voluntarily.
I suspect (and perhaps some Windows folks can verify this) that there's a fundamental difference in the philosophy between being root on a *NIX box (a completely different user) and attaching admin privileges on Windows (same user, just more permission bits set).
One thing that our Windows developer community appeared attached to was the ability (need?
addiction?) to have access to their user space at all times when sitting at a desktop.
Asking them to adopt a different user profile for developing/testing/installation/administration would have deprived them of the ability to do IE/Outlook, visit YouTube, etc.
while their system was connected to some aircraft under test.
I shudder to think of how many times someone was uploading new (classified) firmware into a fighter in one window while IE was prompting them to install that mystery CODEC in order to view some 'important' email message.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607242</id>
	<title>No, and Yes</title>
	<author>ggreig</author>
	<datestamp>1262284380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>We're a small company, developing on Windows using Visual Studio. Since Windows XP, all our developers work in a normal user account; as nearly as possible they use the same environment the most restricted of our users might, so that dumb security-related mistakes get caught fast.</p><p>Having said that, they also know the local admin account details for their machine, and are entrusted with installing/uninstalling stuff as necessary.</p><p>That differentiation - between the access we allow and what we encourage as day-to-day practice - is an important one. On other OSes you're more likely to be making this differentiation already. If you're using Windows and don't, please consider it. This is a useful resource: <a href="http://blogs.msdn.com/aaron\_margosis/" title="msdn.com" rel="nofollow">http://blogs.msdn.com/aaron\_margosis/</a> [msdn.com] </p></htmltext>
<tokenext>We 're a small company , developing on Windows using Visual Studio .
Since Windows XP , all our developers work in a normal user account ; as nearly as possible they use the same environment the most restricted of our users might , so that dumb security-related mistakes get caught fast.Having said that , they also know the local admin account details for their machine , and are entrusted with installing/uninstalling stuff as necessary.That differentiation - between the access we allow and what we encourage as day-to-day practice - is an important one .
On other OSes you 're more likely to be making this differentiation already .
If you 're using Windows and do n't , please consider it .
This is a useful resource : http : //blogs.msdn.com/aaron \ _margosis/ [ msdn.com ]</tokentext>
<sentencetext>We're a small company, developing on Windows using Visual Studio.
Since Windows XP, all our developers work in a normal user account; as nearly as possible they use the same environment the most restricted of our users might, so that dumb security-related mistakes get caught fast.Having said that, they also know the local admin account details for their machine, and are entrusted with installing/uninstalling stuff as necessary.That differentiation - between the access we allow and what we encourage as day-to-day practice - is an important one.
On other OSes you're more likely to be making this differentiation already.
If you're using Windows and don't, please consider it.
This is a useful resource: http://blogs.msdn.com/aaron\_margosis/ [msdn.com] </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608378</id>
	<title>They took our admin rights away for exactly 1 week</title>
	<author>Anonymous</author>
	<datestamp>1262289240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>They took our admin rights away for exactly one week and tried to give us only rights to those things that we 'absolutely' needed, network and workstation.  In that week there was not one line of code written.  We did nothing but put requests in to the net admins for installation requests, access to SQL tables, rights to servers ect...</p><p>We were obvious about surfing the net while our code refused to run correctly, and when asked what we were doing we pointed at the net admins.  They took our ability to work away.  I can understand not wanting us devs to have access to the production network, but you can't just drop us off the network and not give us test equipment.</p><p>They never thought of it this way, but basically their idea was to take everything away from us and determine what was 'absolutely needed' by how much we bitched about it.  After a week of dev standstill while the net admins worked 16+ hour days with no end in sight, they gave in and gave us local admin rights with limited admin accounts to the servers that were fully off the production net.</p><p>The story does have a happy ending though.  We're now have our own network that's 90\% identical to the production network, and physically (no connecting copper) segregated from the production net.  Granted most of our equipment is the old castoffs of the production net, but it just simulates load... or something.  We can laugh it off  when we accidentally forget about that truncate where 1=1; instead of hiding under the desk and updating the resume.  And it only took about a year and a half to actually do it right, instead of flipping it over the weekend.</p><p>Needless to say yes we still have local admin.  Maybe some places could take that away, but you had better have one damn good plan and a awesome team of crack net admins to pull something like that off.</p></htmltext>
<tokenext>They took our admin rights away for exactly one week and tried to give us only rights to those things that we 'absolutely ' needed , network and workstation .
In that week there was not one line of code written .
We did nothing but put requests in to the net admins for installation requests , access to SQL tables , rights to servers ect...We were obvious about surfing the net while our code refused to run correctly , and when asked what we were doing we pointed at the net admins .
They took our ability to work away .
I can understand not wanting us devs to have access to the production network , but you ca n't just drop us off the network and not give us test equipment.They never thought of it this way , but basically their idea was to take everything away from us and determine what was 'absolutely needed ' by how much we bitched about it .
After a week of dev standstill while the net admins worked 16 + hour days with no end in sight , they gave in and gave us local admin rights with limited admin accounts to the servers that were fully off the production net.The story does have a happy ending though .
We 're now have our own network that 's 90 \ % identical to the production network , and physically ( no connecting copper ) segregated from the production net .
Granted most of our equipment is the old castoffs of the production net , but it just simulates load... or something .
We can laugh it off when we accidentally forget about that truncate where 1 = 1 ; instead of hiding under the desk and updating the resume .
And it only took about a year and a half to actually do it right , instead of flipping it over the weekend.Needless to say yes we still have local admin .
Maybe some places could take that away , but you had better have one damn good plan and a awesome team of crack net admins to pull something like that off .</tokentext>
<sentencetext>They took our admin rights away for exactly one week and tried to give us only rights to those things that we 'absolutely' needed, network and workstation.
In that week there was not one line of code written.
We did nothing but put requests in to the net admins for installation requests, access to SQL tables, rights to servers ect...We were obvious about surfing the net while our code refused to run correctly, and when asked what we were doing we pointed at the net admins.
They took our ability to work away.
I can understand not wanting us devs to have access to the production network, but you can't just drop us off the network and not give us test equipment.They never thought of it this way, but basically their idea was to take everything away from us and determine what was 'absolutely needed' by how much we bitched about it.
After a week of dev standstill while the net admins worked 16+ hour days with no end in sight, they gave in and gave us local admin rights with limited admin accounts to the servers that were fully off the production net.The story does have a happy ending though.
We're now have our own network that's 90\% identical to the production network, and physically (no connecting copper) segregated from the production net.
Granted most of our equipment is the old castoffs of the production net, but it just simulates load... or something.
We can laugh it off  when we accidentally forget about that truncate where 1=1; instead of hiding under the desk and updating the resume.
And it only took about a year and a half to actually do it right, instead of flipping it over the weekend.Needless to say yes we still have local admin.
Maybe some places could take that away, but you had better have one damn good plan and a awesome team of crack net admins to pull something like that off.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606732</id>
	<title>Re:Hell no.</title>
	<author>ceebee</author>
	<datestamp>1262282580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The OP asked about LOCAL admin rights. Nothing to do with rebooting servers.</p></htmltext>
<tokenext>The OP asked about LOCAL admin rights .
Nothing to do with rebooting servers .</tokentext>
<sentencetext>The OP asked about LOCAL admin rights.
Nothing to do with rebooting servers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607924</id>
	<title>NO!  Are you crazy?!!!</title>
	<author>Anonymous</author>
	<datestamp>1262286960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I was a cross platform development team lead.  We were constantly forced to upgrade systems to faster and faster CPU, Disk subsystems, and more RAM yearly to improve developer productivity. Add new compiler releases and updates to 3rd party libraries that needed to be deployed across 50 developers and you could easily lose a week/dev of real productivity.</p><p>Then we switched to development servers - where the developers used RDP or X/Windows or ssh to remote into the boxes. They didn't get admin and all developers for the team used identical (not just the same) environments. Since some of our contract developers were overseas, this simplified contracts and security requirements too - the code never left our servers.  We weren't constantly having to purchase more compiler licenses and other tools either. This is harder with Microsoft tools.</p><p>With server-based development and virtualization, we can cold-backup an entire development environment for a release and keep it around, just not running, for as long as a client is willing to pay for updates or support. If it doesn't happen for 2 years, we didn't waste anything but a few hundred GB of offline storage.</p><p>Server disks connected to SANs with caching are FAST. Faster than any local disks. Compiles are 10x faster.</p><p>IMHO, most current developers that aren't C/C++ seem to be clueless about performance of computers. Developers can lose days tweaking their desktops "just so" rather than getting down to work and concentrating on the important stuff.  You know, code comments.</p></htmltext>
<tokenext>I was a cross platform development team lead .
We were constantly forced to upgrade systems to faster and faster CPU , Disk subsystems , and more RAM yearly to improve developer productivity .
Add new compiler releases and updates to 3rd party libraries that needed to be deployed across 50 developers and you could easily lose a week/dev of real productivity.Then we switched to development servers - where the developers used RDP or X/Windows or ssh to remote into the boxes .
They did n't get admin and all developers for the team used identical ( not just the same ) environments .
Since some of our contract developers were overseas , this simplified contracts and security requirements too - the code never left our servers .
We were n't constantly having to purchase more compiler licenses and other tools either .
This is harder with Microsoft tools.With server-based development and virtualization , we can cold-backup an entire development environment for a release and keep it around , just not running , for as long as a client is willing to pay for updates or support .
If it does n't happen for 2 years , we did n't waste anything but a few hundred GB of offline storage.Server disks connected to SANs with caching are FAST .
Faster than any local disks .
Compiles are 10x faster.IMHO , most current developers that are n't C/C + + seem to be clueless about performance of computers .
Developers can lose days tweaking their desktops " just so " rather than getting down to work and concentrating on the important stuff .
You know , code comments .</tokentext>
<sentencetext>I was a cross platform development team lead.
We were constantly forced to upgrade systems to faster and faster CPU, Disk subsystems, and more RAM yearly to improve developer productivity.
Add new compiler releases and updates to 3rd party libraries that needed to be deployed across 50 developers and you could easily lose a week/dev of real productivity.Then we switched to development servers - where the developers used RDP or X/Windows or ssh to remote into the boxes.
They didn't get admin and all developers for the team used identical (not just the same) environments.
Since some of our contract developers were overseas, this simplified contracts and security requirements too - the code never left our servers.
We weren't constantly having to purchase more compiler licenses and other tools either.
This is harder with Microsoft tools.With server-based development and virtualization, we can cold-backup an entire development environment for a release and keep it around, just not running, for as long as a client is willing to pay for updates or support.
If it doesn't happen for 2 years, we didn't waste anything but a few hundred GB of offline storage.Server disks connected to SANs with caching are FAST.
Faster than any local disks.
Compiles are 10x faster.IMHO, most current developers that aren't C/C++ seem to be clueless about performance of computers.
Developers can lose days tweaking their desktops "just so" rather than getting down to work and concentrating on the important stuff.
You know, code comments.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607700</id>
	<title>A necessary evil...</title>
	<author>Anonymous</author>
	<datestamp>1262286120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Working at a large financial org as a developer - everyone has to run a windows desktop, even if their deployed code will reside on unix servers. So, we all get admin access off the bat, which is usually required to install the tools (IDEs, testing tools, beta versions of stuff, etc.).<br>This becomes evil, as it opens you to drive-by OS infections via the IE and Outlook. Not fun.</p><p>Support is basically if we hose the machine, support will reimage it. If this happens too frequently, admin access is removed, and the developer labeled a 'tard (unoffically of course).</p><p>I would personally prefer two accounts -- one as normal joe user, one as admin, so I can at least dip in and out of admin rights, minimise the risks, but big companies seem to do things all-or-nothing.</p></htmltext>
<tokenext>Working at a large financial org as a developer - everyone has to run a windows desktop , even if their deployed code will reside on unix servers .
So , we all get admin access off the bat , which is usually required to install the tools ( IDEs , testing tools , beta versions of stuff , etc .
) .This becomes evil , as it opens you to drive-by OS infections via the IE and Outlook .
Not fun.Support is basically if we hose the machine , support will reimage it .
If this happens too frequently , admin access is removed , and the developer labeled a 'tard ( unoffically of course ) .I would personally prefer two accounts -- one as normal joe user , one as admin , so I can at least dip in and out of admin rights , minimise the risks , but big companies seem to do things all-or-nothing .</tokentext>
<sentencetext>Working at a large financial org as a developer - everyone has to run a windows desktop, even if their deployed code will reside on unix servers.
So, we all get admin access off the bat, which is usually required to install the tools (IDEs, testing tools, beta versions of stuff, etc.
).This becomes evil, as it opens you to drive-by OS infections via the IE and Outlook.
Not fun.Support is basically if we hose the machine, support will reimage it.
If this happens too frequently, admin access is removed, and the developer labeled a 'tard (unoffically of course).I would personally prefer two accounts -- one as normal joe user, one as admin, so I can at least dip in and out of admin rights, minimise the risks, but big companies seem to do things all-or-nothing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607892</id>
	<title>virtual machines</title>
	<author>Anonymous</author>
	<datestamp>1262286840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Organizations that treat developers like standard "business" users are going to get systems developed as well and as fast as those created by standard "business" users. A developer needs at least elevated rights on a workstation.</p></div><p>A developer needs elevated rights on a virtual machine where they have a saved snapshot they can revert back to in case they bork things.</p></div>
	</htmltext>
<tokenext>Organizations that treat developers like standard " business " users are going to get systems developed as well and as fast as those created by standard " business " users .
A developer needs at least elevated rights on a workstation.A developer needs elevated rights on a virtual machine where they have a saved snapshot they can revert back to in case they bork things .</tokentext>
<sentencetext>Organizations that treat developers like standard "business" users are going to get systems developed as well and as fast as those created by standard "business" users.
A developer needs at least elevated rights on a workstation.A developer needs elevated rights on a virtual machine where they have a saved snapshot they can revert back to in case they bork things.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606842</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607200</id>
	<title>Re:Yes</title>
	<author>Anonymous</author>
	<datestamp>1262284260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>It is impossible, IMO, to do many functions without these privileges.</p></div></blockquote><p>I currently work in an environment where I don't usually need admin. I'm a self-employed Mac developer, and do all of my dev work in an unprivileged account. However that account is a member of the \_developer group, which gives the debugger the right to attach to processes. That's frequently all I need. When I've worked in $bigcorp networks where developers do need admin or root, IT have typically created a sandbox network for developer machines to sit in which have access to SCM, the bug tracker, build environment front-end and so on but limited access to business systems and internet facilities.</p></div>
	</htmltext>
<tokenext>It is impossible , IMO , to do many functions without these privileges.I currently work in an environment where I do n't usually need admin .
I 'm a self-employed Mac developer , and do all of my dev work in an unprivileged account .
However that account is a member of the \ _developer group , which gives the debugger the right to attach to processes .
That 's frequently all I need .
When I 've worked in $ bigcorp networks where developers do need admin or root , IT have typically created a sandbox network for developer machines to sit in which have access to SCM , the bug tracker , build environment front-end and so on but limited access to business systems and internet facilities .</tokentext>
<sentencetext>It is impossible, IMO, to do many functions without these privileges.I currently work in an environment where I don't usually need admin.
I'm a self-employed Mac developer, and do all of my dev work in an unprivileged account.
However that account is a member of the \_developer group, which gives the debugger the right to attach to processes.
That's frequently all I need.
When I've worked in $bigcorp networks where developers do need admin or root, IT have typically created a sandbox network for developer machines to sit in which have access to SCM, the bug tracker, build environment front-end and so on but limited access to business systems and internet facilities.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608452</id>
	<title>It depends on the type of development.</title>
	<author>GWRedDragon</author>
	<datestamp>1262289720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Are we talking about kids hired at minimum wage to write javascript that animates the company logo on mouseover? Experienced C developers writing device drivers? C++ developers working on a legacy MMO engine?</p><p>"Developer" encompasses a very wide range of experience and knowledge levels. Experienced professionals working on complicated programs should not be encumbered by controls designed to prevent idiots from screwing up their OS install. Employees who barely know enough about the system to write business logic, should not be in a position to break things.</p></htmltext>
<tokenext>Are we talking about kids hired at minimum wage to write javascript that animates the company logo on mouseover ?
Experienced C developers writing device drivers ?
C + + developers working on a legacy MMO engine ?
" Developer " encompasses a very wide range of experience and knowledge levels .
Experienced professionals working on complicated programs should not be encumbered by controls designed to prevent idiots from screwing up their OS install .
Employees who barely know enough about the system to write business logic , should not be in a position to break things .</tokentext>
<sentencetext>Are we talking about kids hired at minimum wage to write javascript that animates the company logo on mouseover?
Experienced C developers writing device drivers?
C++ developers working on a legacy MMO engine?
"Developer" encompasses a very wide range of experience and knowledge levels.
Experienced professionals working on complicated programs should not be encumbered by controls designed to prevent idiots from screwing up their OS install.
Employees who barely know enough about the system to write business logic, should not be in a position to break things.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618264</id>
	<title>Re:What it REALLY comes down to</title>
	<author>Anonymous</author>
	<datestamp>1230820320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>For the same reason that most other operating systems, including most flavors of linux, requires admin rights to install software.</p></div></blockquote><p>NO UNIX SYSTEM REQUIRES ADMIN RIGHTS TO INSTALL SOFTWARE.  End of story.</p><p>Sure, the DEFAULT behavior is to install it system-wide, but with just a single flag, you can install every piece of software in any random subdirectory you want...  generally $HOME/XYZ, or<nobr> <wbr></nobr>/usr/local/XYZ</p><blockquote><div><p>Yeah, one directory, like... "Program files"? Every program installs to Program files by default</p></div></blockquote><p>No, they install under Program Files\XYZ, and Program Files\Common, and in the registry, and in various folders in \Windows, etc.</p><blockquote><div><p>The windows registry is a hierarchical system of configuration settings (with parts that are global for the machine and parts that are local to the user), and<nobr> <wbr></nobr>/etc is a hierarchical system of configuration settings (contained in text files)... Where's the big difference?</p></div></blockquote><p>The registry is several times larger, requires several levels of indirection, is stored in a proprietary binary database format which can't be accessed by any application (see 'diff'), and is stored in a few very large files which are highly subject to corruption, hence every version of Windows since 98 saving 8+ copies of it.</p></div>
	</htmltext>
<tokenext>For the same reason that most other operating systems , including most flavors of linux , requires admin rights to install software.NO UNIX SYSTEM REQUIRES ADMIN RIGHTS TO INSTALL SOFTWARE .
End of story.Sure , the DEFAULT behavior is to install it system-wide , but with just a single flag , you can install every piece of software in any random subdirectory you want... generally $ HOME/XYZ , or /usr/local/XYZYeah , one directory , like... " Program files " ?
Every program installs to Program files by defaultNo , they install under Program Files \ XYZ , and Program Files \ Common , and in the registry , and in various folders in \ Windows , etc.The windows registry is a hierarchical system of configuration settings ( with parts that are global for the machine and parts that are local to the user ) , and /etc is a hierarchical system of configuration settings ( contained in text files ) ... Where 's the big difference ? The registry is several times larger , requires several levels of indirection , is stored in a proprietary binary database format which ca n't be accessed by any application ( see 'diff ' ) , and is stored in a few very large files which are highly subject to corruption , hence every version of Windows since 98 saving 8 + copies of it .</tokentext>
<sentencetext>For the same reason that most other operating systems, including most flavors of linux, requires admin rights to install software.NO UNIX SYSTEM REQUIRES ADMIN RIGHTS TO INSTALL SOFTWARE.
End of story.Sure, the DEFAULT behavior is to install it system-wide, but with just a single flag, you can install every piece of software in any random subdirectory you want...  generally $HOME/XYZ, or /usr/local/XYZYeah, one directory, like... "Program files"?
Every program installs to Program files by defaultNo, they install under Program Files\XYZ, and Program Files\Common, and in the registry, and in various folders in \Windows, etc.The windows registry is a hierarchical system of configuration settings (with parts that are global for the machine and parts that are local to the user), and /etc is a hierarchical system of configuration settings (contained in text files)... Where's the big difference?The registry is several times larger, requires several levels of indirection, is stored in a proprietary binary database format which can't be accessed by any application (see 'diff'), and is stored in a few very large files which are highly subject to corruption, hence every version of Windows since 98 saving 8+ copies of it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610098</id>
	<title>Re:It's Target.</title>
	<author>nine-times</author>
	<datestamp>1262255820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I only know because I used to work on support there, and they tried this crap with trying to delete local admin rights for everyone so nobody could administer their own boxes.</p> </div><p>I don't think that's unique to Target.  You generally should remove admin rights from everyone's machine.  It can be tricky with developers, but in general it's the right move.  Microsoft may not have advised it back 10 years ago, but today it's common even on Windows.  If you can't lock down common users, something is probably wrong.</p><p><div class="quote"><p> These are the kind of people that read that pen drives are the source of all evil on their network and if you just delete the USB mass storage driver from the system, your problem is solved.</p></div><p>If you think USB devices are harmless, you might want to talk to this guy: <a href="http://slashdot.org/comments.pl?sid=1494414&amp;cid=30608146" title="slashdot.org">link</a> [slashdot.org].  It's not something that happens every day, but it might give you an idea of why IT people can be such controlling pricks.  They're trying to prevent a million possible problems by controlling all the variables that they can.  The poster's MBR problem might be pretty rare, but there are tons of ways that a person can screw up their own system or violate security policies using a simple USB key drive.
</p><p>It's entirely possible for security to be too strict for the circumstances, but trying to dissuade use of USB drives isn't totally stupid.</p></div>
	</htmltext>
<tokenext>I only know because I used to work on support there , and they tried this crap with trying to delete local admin rights for everyone so nobody could administer their own boxes .
I do n't think that 's unique to Target .
You generally should remove admin rights from everyone 's machine .
It can be tricky with developers , but in general it 's the right move .
Microsoft may not have advised it back 10 years ago , but today it 's common even on Windows .
If you ca n't lock down common users , something is probably wrong .
These are the kind of people that read that pen drives are the source of all evil on their network and if you just delete the USB mass storage driver from the system , your problem is solved.If you think USB devices are harmless , you might want to talk to this guy : link [ slashdot.org ] .
It 's not something that happens every day , but it might give you an idea of why IT people can be such controlling pricks .
They 're trying to prevent a million possible problems by controlling all the variables that they can .
The poster 's MBR problem might be pretty rare , but there are tons of ways that a person can screw up their own system or violate security policies using a simple USB key drive .
It 's entirely possible for security to be too strict for the circumstances , but trying to dissuade use of USB drives is n't totally stupid .</tokentext>
<sentencetext>I only know because I used to work on support there, and they tried this crap with trying to delete local admin rights for everyone so nobody could administer their own boxes.
I don't think that's unique to Target.
You generally should remove admin rights from everyone's machine.
It can be tricky with developers, but in general it's the right move.
Microsoft may not have advised it back 10 years ago, but today it's common even on Windows.
If you can't lock down common users, something is probably wrong.
These are the kind of people that read that pen drives are the source of all evil on their network and if you just delete the USB mass storage driver from the system, your problem is solved.If you think USB devices are harmless, you might want to talk to this guy: link [slashdot.org].
It's not something that happens every day, but it might give you an idea of why IT people can be such controlling pricks.
They're trying to prevent a million possible problems by controlling all the variables that they can.
The poster's MBR problem might be pretty rare, but there are tons of ways that a person can screw up their own system or violate security policies using a simple USB key drive.
It's entirely possible for security to be too strict for the circumstances, but trying to dissuade use of USB drives isn't totally stupid.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610466</id>
	<title>That's what VMs are for</title>
	<author>bschorr</author>
	<datestamp>1262258220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Our Devs have full admin rights....on the Virtual Machines they develop on.  It's great, they create a base VM, store that drive file as a template, then do their development and testing.  Anytime they want to, which turns out to be a couple of times a month usually, they delete that active VM and start over clean from the base.  They can also run multiple identical VMs side-by-side if they need to.<br><br>Need to test against a different OS or a server?  Create a VM for it and go.  Doesn't matter if they trash it, it's just a VM.</htmltext>
<tokenext>Our Devs have full admin rights....on the Virtual Machines they develop on .
It 's great , they create a base VM , store that drive file as a template , then do their development and testing .
Anytime they want to , which turns out to be a couple of times a month usually , they delete that active VM and start over clean from the base .
They can also run multiple identical VMs side-by-side if they need to.Need to test against a different OS or a server ?
Create a VM for it and go .
Does n't matter if they trash it , it 's just a VM .</tokentext>
<sentencetext>Our Devs have full admin rights....on the Virtual Machines they develop on.
It's great, they create a base VM, store that drive file as a template, then do their development and testing.
Anytime they want to, which turns out to be a couple of times a month usually, they delete that active VM and start over clean from the base.
They can also run multiple identical VMs side-by-side if they need to.Need to test against a different OS or a server?
Create a VM for it and go.
Doesn't matter if they trash it, it's just a VM.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607784</id>
	<title>Re:You damn well should</title>
	<author>ThrowAwaySociety</author>
	<datestamp>1262286420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>Wow, what a bunch of morons. In addition to hiring people that understand you just can't do that kind of stuff, my company has controls in place to prevent it. Want to reboot a production server? You need a change ticket, approval and you're going to be doing it during the maintenance window unless it's an emergency. Gotta do it? Call it an emergency and explain yourself later. Can't? Find another job.</p></div><p>Nobody is talking about production servers. Not even testing servers. We're talking about <i>developers' own workstations</i>, and possibly development servers.</p><p>If your developers can't be trusted in their own environment, then you need to find better developers.</p></div>
	</htmltext>
<tokenext>Wow , what a bunch of morons .
In addition to hiring people that understand you just ca n't do that kind of stuff , my company has controls in place to prevent it .
Want to reboot a production server ?
You need a change ticket , approval and you 're going to be doing it during the maintenance window unless it 's an emergency .
Got ta do it ?
Call it an emergency and explain yourself later .
Ca n't ? Find another job.Nobody is talking about production servers .
Not even testing servers .
We 're talking about developers ' own workstations , and possibly development servers.If your developers ca n't be trusted in their own environment , then you need to find better developers .</tokentext>
<sentencetext>Wow, what a bunch of morons.
In addition to hiring people that understand you just can't do that kind of stuff, my company has controls in place to prevent it.
Want to reboot a production server?
You need a change ticket, approval and you're going to be doing it during the maintenance window unless it's an emergency.
Gotta do it?
Call it an emergency and explain yourself later.
Can't? Find another job.Nobody is talking about production servers.
Not even testing servers.
We're talking about developers' own workstations, and possibly development servers.If your developers can't be trusted in their own environment, then you need to find better developers.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606818</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608172</id>
	<title>Virus Scanning</title>
	<author>KalvinB</author>
	<datestamp>1262288160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If you don't want devs turning off virus scanning then don't have it aggressively scanning constantly and don't use bloated junk that takes over the system.  Virus scanners are huge productivity killers when not properly configured as they make systems crawl.  Check on write and nightly scans are sufficient.</p><p>I turn that crap off too if it's preventing me from doing my job.  It can be turned back on at night before I go home so it can do it's thing when it's not affecting my work.</p></htmltext>
<tokenext>If you do n't want devs turning off virus scanning then do n't have it aggressively scanning constantly and do n't use bloated junk that takes over the system .
Virus scanners are huge productivity killers when not properly configured as they make systems crawl .
Check on write and nightly scans are sufficient.I turn that crap off too if it 's preventing me from doing my job .
It can be turned back on at night before I go home so it can do it 's thing when it 's not affecting my work .</tokentext>
<sentencetext>If you don't want devs turning off virus scanning then don't have it aggressively scanning constantly and don't use bloated junk that takes over the system.
Virus scanners are huge productivity killers when not properly configured as they make systems crawl.
Check on write and nightly scans are sufficient.I turn that crap off too if it's preventing me from doing my job.
It can be turned back on at night before I go home so it can do it's thing when it's not affecting my work.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606590</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609516</id>
	<title>Re:It's Target.</title>
	<author>Anonymous</author>
	<datestamp>1262252340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I run a network much larger than Target and If I caught someone putting a machine on my network without connecting to the domain, i would have them fired.  We use NAC so that no one can even connect unless someone from IT sets them up.  This includes Developers and especially apple users.  This is the best way to handle large computer deployment situations.  You can not trust the end user to manage their updates or software.  I manage over 25,000 desktops and none have local admin rights and our it department is only 18 people.  The people complaining are obviously not real admins but rather end users that always complain instead of seeing the big picture.</p></htmltext>
<tokenext>I run a network much larger than Target and If I caught someone putting a machine on my network without connecting to the domain , i would have them fired .
We use NAC so that no one can even connect unless someone from IT sets them up .
This includes Developers and especially apple users .
This is the best way to handle large computer deployment situations .
You can not trust the end user to manage their updates or software .
I manage over 25,000 desktops and none have local admin rights and our it department is only 18 people .
The people complaining are obviously not real admins but rather end users that always complain instead of seeing the big picture .</tokentext>
<sentencetext>I run a network much larger than Target and If I caught someone putting a machine on my network without connecting to the domain, i would have them fired.
We use NAC so that no one can even connect unless someone from IT sets them up.
This includes Developers and especially apple users.
This is the best way to handle large computer deployment situations.
You can not trust the end user to manage their updates or software.
I manage over 25,000 desktops and none have local admin rights and our it department is only 18 people.
The people complaining are obviously not real admins but rather end users that always complain instead of seeing the big picture.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609010</id>
	<title>Re:Virtualization is your Friend</title>
	<author>Comatose51</author>
	<datestamp>1262292540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>VMware even makes a product just for that use case: <a href="http://www.vmware.com/products/labmanager/" title="vmware.com">http://www.vmware.com/products/labmanager/</a> [vmware.com]</htmltext>
<tokenext>VMware even makes a product just for that use case : http : //www.vmware.com/products/labmanager/ [ vmware.com ]</tokentext>
<sentencetext>VMware even makes a product just for that use case: http://www.vmware.com/products/labmanager/ [vmware.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618332</id>
	<title>His own limitations?</title>
	<author>jotaeleemeese</author>
	<datestamp>1230820620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Which ones?</p><p>The limitations were in the developer's side for not knowing the implication of running everything using privileged access.</p></htmltext>
<tokenext>Which ones ? The limitations were in the developer 's side for not knowing the implication of running everything using privileged access .</tokentext>
<sentencetext>Which ones?The limitations were in the developer's side for not knowing the implication of running everything using privileged access.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607176</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608494</id>
	<title>Depends on the environment...</title>
	<author>Sandbags</author>
	<datestamp>1262290020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In their own lab systems as they may deploy them occasionally in snadboxed network segments, they do whatever they want.  In our formal development and testing environments, it;s a different story. We typically have 4-5 code migrations areas per application from: Unit code testing, system/load testing, Customer QA, Production, and occasionally a specialized environment.  In the Unit environment, they have read/write access to most of the server, but this varies by OS.  under Windows, they pretty much have to be admins (but not local).  In Linux/Unix, they only have read/write/ex in the directories specific to their app.  We have hardened linux images, and they can't access core functions or configurations outside of their app.  In System environments, they're lucky to get read access (except in Windows environments where their access is the same as unit envs).</p><p>In QA, Prod, Training, or other environments, Devs can't even log in, except with the same credentials as a user that might use the system in production.  An Operations team, dedicated application support team, network security, and a few other people have admin rights, but even our software deployment team looses their login rights once the system is put into production.</p></htmltext>
<tokenext>In their own lab systems as they may deploy them occasionally in snadboxed network segments , they do whatever they want .
In our formal development and testing environments , it ; s a different story .
We typically have 4-5 code migrations areas per application from : Unit code testing , system/load testing , Customer QA , Production , and occasionally a specialized environment .
In the Unit environment , they have read/write access to most of the server , but this varies by OS .
under Windows , they pretty much have to be admins ( but not local ) .
In Linux/Unix , they only have read/write/ex in the directories specific to their app .
We have hardened linux images , and they ca n't access core functions or configurations outside of their app .
In System environments , they 're lucky to get read access ( except in Windows environments where their access is the same as unit envs ) .In QA , Prod , Training , or other environments , Devs ca n't even log in , except with the same credentials as a user that might use the system in production .
An Operations team , dedicated application support team , network security , and a few other people have admin rights , but even our software deployment team looses their login rights once the system is put into production .</tokentext>
<sentencetext>In their own lab systems as they may deploy them occasionally in snadboxed network segments, they do whatever they want.
In our formal development and testing environments, it;s a different story.
We typically have 4-5 code migrations areas per application from: Unit code testing, system/load testing, Customer QA, Production, and occasionally a specialized environment.
In the Unit environment, they have read/write access to most of the server, but this varies by OS.
under Windows, they pretty much have to be admins (but not local).
In Linux/Unix, they only have read/write/ex in the directories specific to their app.
We have hardened linux images, and they can't access core functions or configurations outside of their app.
In System environments, they're lucky to get read access (except in Windows environments where their access is the same as unit envs).In QA, Prod, Training, or other environments, Devs can't even log in, except with the same credentials as a user that might use the system in production.
An Operations team, dedicated application support team, network security, and a few other people have admin rights, but even our software deployment team looses their login rights once the system is put into production.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606956</id>
	<title>Local,yes.</title>
	<author>RingDev</author>
	<datestamp>1262283300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In every shop I've worked in developers have had local admin rights on their own machines, and possibly in the development environment.</p><p>I have been in 2 shops where the developer machines had been locked down as well as desktop users. But it didn't take long for that to change as the support desk was fielding dozens of issues each day from developers not being able to perform needed tasks (this was back in the PB/VB5/NT days).</p><p>But developers should never have admin rights over production hardware, OS's, or databases. Where I work now, we have free reign over the dev environment. We can do what ever we want and not tell a soul. If anyone is running production apps that hit the dev environment, it is a critical failure on that developer's part, not on the part of the person rebooting the dev box. We can change database schemes, install new apps, run windows update, all the usual stuff. From there we have a staging environment. The staging environment is slightly more locked down, we can still do almost everything we did in the dev environment, but all changes and reboots have to be communicated so that all other departments that may be deploying and testing are aware of the changes. After that is the production boxes. We do not have rights to get into these machines. We write up instructions and submit tickets to the support staff for deployments to these servers. All those deployments run on Thursday nights after a week long "train" process that involves IT managerial, tester, and power user sign off.</p><p>-Rick</p></htmltext>
<tokenext>In every shop I 've worked in developers have had local admin rights on their own machines , and possibly in the development environment.I have been in 2 shops where the developer machines had been locked down as well as desktop users .
But it did n't take long for that to change as the support desk was fielding dozens of issues each day from developers not being able to perform needed tasks ( this was back in the PB/VB5/NT days ) .But developers should never have admin rights over production hardware , OS 's , or databases .
Where I work now , we have free reign over the dev environment .
We can do what ever we want and not tell a soul .
If anyone is running production apps that hit the dev environment , it is a critical failure on that developer 's part , not on the part of the person rebooting the dev box .
We can change database schemes , install new apps , run windows update , all the usual stuff .
From there we have a staging environment .
The staging environment is slightly more locked down , we can still do almost everything we did in the dev environment , but all changes and reboots have to be communicated so that all other departments that may be deploying and testing are aware of the changes .
After that is the production boxes .
We do not have rights to get into these machines .
We write up instructions and submit tickets to the support staff for deployments to these servers .
All those deployments run on Thursday nights after a week long " train " process that involves IT managerial , tester , and power user sign off.-Rick</tokentext>
<sentencetext>In every shop I've worked in developers have had local admin rights on their own machines, and possibly in the development environment.I have been in 2 shops where the developer machines had been locked down as well as desktop users.
But it didn't take long for that to change as the support desk was fielding dozens of issues each day from developers not being able to perform needed tasks (this was back in the PB/VB5/NT days).But developers should never have admin rights over production hardware, OS's, or databases.
Where I work now, we have free reign over the dev environment.
We can do what ever we want and not tell a soul.
If anyone is running production apps that hit the dev environment, it is a critical failure on that developer's part, not on the part of the person rebooting the dev box.
We can change database schemes, install new apps, run windows update, all the usual stuff.
From there we have a staging environment.
The staging environment is slightly more locked down, we can still do almost everything we did in the dev environment, but all changes and reboots have to be communicated so that all other departments that may be deploying and testing are aware of the changes.
After that is the production boxes.
We do not have rights to get into these machines.
We write up instructions and submit tickets to the support staff for deployments to these servers.
All those deployments run on Thursday nights after a week long "train" process that involves IT managerial, tester, and power user sign off.-Rick</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607458</id>
	<title>Kind of</title>
	<author>Anonymous</author>
	<datestamp>1262285160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm a hardware developer at a Very Large Corporation, and IT would prefer us not to have local admin. However, it's nearly impossible to work like that, so they have set up an automated tool (which basically goes and asks our manager for approval) for granting local admin exceptions on a machine by machine basis. In theory it takes away our local admin powers every month, but in practice, so many people need to have local admin I don't think it ever actually removes local admin.</p><p>You just can't do serious work without being able to install software, install drivers, use remote desktop(!!!!), etc. Not to mention many CAD apps simply don't work if you're not local admin. They tried forcing us off those applications, but we just started using raw OS images and installing a VM with the "corporate OS image". They threatened to fire us, but at the end of the day they need us more than we need them, so we ended up in this hole.</p><p>Honestly, installing your corporate locked down image in a VM is the best way to go anyway. Let IT do whatever they want to that image, they can reboot you, push updates, etc. without disrupting your work. Meanwhile you can set up the OS for your productivity without disrupting them. Yes, it's a flagrant disregard for what IT is tasked with doing, but chances are if you're in a Very Large Corporation, what they're tasked with doing is ridiculous, the number of people assigned to do it is pathetic, and the geographic and linguistic boundaries of that ensure that their mission is defunct. This is probably not ideal behavior, but I consider myself an engineer first and an employee of Very Large Corporation second. Better my job gets done correctly than I invest time in fixing stupid. You can't fix stupid.</p></htmltext>
<tokenext>I 'm a hardware developer at a Very Large Corporation , and IT would prefer us not to have local admin .
However , it 's nearly impossible to work like that , so they have set up an automated tool ( which basically goes and asks our manager for approval ) for granting local admin exceptions on a machine by machine basis .
In theory it takes away our local admin powers every month , but in practice , so many people need to have local admin I do n't think it ever actually removes local admin.You just ca n't do serious work without being able to install software , install drivers , use remote desktop ( ! ! ! !
) , etc .
Not to mention many CAD apps simply do n't work if you 're not local admin .
They tried forcing us off those applications , but we just started using raw OS images and installing a VM with the " corporate OS image " .
They threatened to fire us , but at the end of the day they need us more than we need them , so we ended up in this hole.Honestly , installing your corporate locked down image in a VM is the best way to go anyway .
Let IT do whatever they want to that image , they can reboot you , push updates , etc .
without disrupting your work .
Meanwhile you can set up the OS for your productivity without disrupting them .
Yes , it 's a flagrant disregard for what IT is tasked with doing , but chances are if you 're in a Very Large Corporation , what they 're tasked with doing is ridiculous , the number of people assigned to do it is pathetic , and the geographic and linguistic boundaries of that ensure that their mission is defunct .
This is probably not ideal behavior , but I consider myself an engineer first and an employee of Very Large Corporation second .
Better my job gets done correctly than I invest time in fixing stupid .
You ca n't fix stupid .</tokentext>
<sentencetext>I'm a hardware developer at a Very Large Corporation, and IT would prefer us not to have local admin.
However, it's nearly impossible to work like that, so they have set up an automated tool (which basically goes and asks our manager for approval) for granting local admin exceptions on a machine by machine basis.
In theory it takes away our local admin powers every month, but in practice, so many people need to have local admin I don't think it ever actually removes local admin.You just can't do serious work without being able to install software, install drivers, use remote desktop(!!!!
), etc.
Not to mention many CAD apps simply don't work if you're not local admin.
They tried forcing us off those applications, but we just started using raw OS images and installing a VM with the "corporate OS image".
They threatened to fire us, but at the end of the day they need us more than we need them, so we ended up in this hole.Honestly, installing your corporate locked down image in a VM is the best way to go anyway.
Let IT do whatever they want to that image, they can reboot you, push updates, etc.
without disrupting your work.
Meanwhile you can set up the OS for your productivity without disrupting them.
Yes, it's a flagrant disregard for what IT is tasked with doing, but chances are if you're in a Very Large Corporation, what they're tasked with doing is ridiculous, the number of people assigned to do it is pathetic, and the geographic and linguistic boundaries of that ensure that their mission is defunct.
This is probably not ideal behavior, but I consider myself an engineer first and an employee of Very Large Corporation second.
Better my job gets done correctly than I invest time in fixing stupid.
You can't fix stupid.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698</id>
	<title>Re:You damn well should</title>
	<author>TheRealFixer</author>
	<datestamp>1262282460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><i>Any developer who can't competently administer his own machine is incompetent.</i> <br>
<br>
You'd think that would be the case but, in my experience, I've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops. Didn't understand basic networking principles or basic OS functions and dos and don'ts.  That being said, I still would give them admin rights to their own workstations.  Otherwise I'd be spending my whole day installing a billion apps for them that they need to test or develop with, and that also ends up being a waste of their time having to wait for me.  But I also have the expectation that they're probably going to need some additional care when they mess something up.<br>
<br>
But admin access to production servers, absolutely not.  I've seen way too many scary, scary things happen when developers are given unrestricted access to production systems.</htmltext>
<tokenext>Any developer who ca n't competently administer his own machine is incompetent .
You 'd think that would be the case but , in my experience , I 've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops .
Did n't understand basic networking principles or basic OS functions and dos and don'ts .
That being said , I still would give them admin rights to their own workstations .
Otherwise I 'd be spending my whole day installing a billion apps for them that they need to test or develop with , and that also ends up being a waste of their time having to wait for me .
But I also have the expectation that they 're probably going to need some additional care when they mess something up .
But admin access to production servers , absolutely not .
I 've seen way too many scary , scary things happen when developers are given unrestricted access to production systems .</tokentext>
<sentencetext>Any developer who can't competently administer his own machine is incompetent.
You'd think that would be the case but, in my experience, I've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops.
Didn't understand basic networking principles or basic OS functions and dos and don'ts.
That being said, I still would give them admin rights to their own workstations.
Otherwise I'd be spending my whole day installing a billion apps for them that they need to test or develop with, and that also ends up being a waste of their time having to wait for me.
But I also have the expectation that they're probably going to need some additional care when they mess something up.
But admin access to production servers, absolutely not.
I've seen way too many scary, scary things happen when developers are given unrestricted access to production systems.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30680214</id>
	<title>I do</title>
	<author>xiong.chiamiov</author>
	<datestamp>1231322700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>At one of my jobs, I was given a laptop, with the full expectation that I would erase the Vista partition and install Linux.  At the other, I was given a desktop with a blank hdd, and a day to configure it.</htmltext>
<tokenext>At one of my jobs , I was given a laptop , with the full expectation that I would erase the Vista partition and install Linux .
At the other , I was given a desktop with a blank hdd , and a day to configure it .</tokentext>
<sentencetext>At one of my jobs, I was given a laptop, with the full expectation that I would erase the Vista partition and install Linux.
At the other, I was given a desktop with a blank hdd, and a day to configure it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608890</id>
	<title>Re:You damn well should</title>
	<author>npsimons</author>
	<datestamp>1262292000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Because it's not a developers job to worry about day-to-day administration of their systems</p></div></blockquote><p>Maybe if they were running a halfway decent OS/distro, they wouldn't *have* to worry about day-to-day administration.  One of the reasons I love Debian is that it is literally install and forget.  I install what I need, tweak a few things (including a security lockdown) and I never have to touch admin stuff again.  Of course, I am also a reasonably competent admin, but the fact that I have literally all the tools I need at my fingertips in the form of Debian packaged and signed software means the most sysadmin thing I have to do is "insert Debian DVD binary-1" to install something I forgot (or didn't know I needed until then).</p><blockquote><div><p>And unfortunately, most developers have little regard for the difference between USER and ROOT (or equivalent). Until we bash them over the heads about it.</p></div></blockquote><p>As a (past) sysadmin and a current developer, I have to say this really depends.  For the most part, developers know what the hell they are doing; if they don't, they probably shouldn't be developers.  If they're unwilling to learn how to properly use root/admin, they shouldn't be in the computing industry.</p><blockquote><div><p>Concern for code is appropriate, but irrelevant. Too much requires root or equivalent access in todays day and age.</p></div></blockquote><p>Granted, but again, this is a problem of what platform you choose.  Under Debian, I intentionally limit myself on the commands I run through sudo, even though I am the only user and admin.  I've found I can get by with about 6-7 commands (and one of those is visudo, to temporarily add something I might need).</p></div>
	</htmltext>
<tokenext>Because it 's not a developers job to worry about day-to-day administration of their systemsMaybe if they were running a halfway decent OS/distro , they would n't * have * to worry about day-to-day administration .
One of the reasons I love Debian is that it is literally install and forget .
I install what I need , tweak a few things ( including a security lockdown ) and I never have to touch admin stuff again .
Of course , I am also a reasonably competent admin , but the fact that I have literally all the tools I need at my fingertips in the form of Debian packaged and signed software means the most sysadmin thing I have to do is " insert Debian DVD binary-1 " to install something I forgot ( or did n't know I needed until then ) .And unfortunately , most developers have little regard for the difference between USER and ROOT ( or equivalent ) .
Until we bash them over the heads about it.As a ( past ) sysadmin and a current developer , I have to say this really depends .
For the most part , developers know what the hell they are doing ; if they do n't , they probably should n't be developers .
If they 're unwilling to learn how to properly use root/admin , they should n't be in the computing industry.Concern for code is appropriate , but irrelevant .
Too much requires root or equivalent access in todays day and age.Granted , but again , this is a problem of what platform you choose .
Under Debian , I intentionally limit myself on the commands I run through sudo , even though I am the only user and admin .
I 've found I can get by with about 6-7 commands ( and one of those is visudo , to temporarily add something I might need ) .</tokentext>
<sentencetext>Because it's not a developers job to worry about day-to-day administration of their systemsMaybe if they were running a halfway decent OS/distro, they wouldn't *have* to worry about day-to-day administration.
One of the reasons I love Debian is that it is literally install and forget.
I install what I need, tweak a few things (including a security lockdown) and I never have to touch admin stuff again.
Of course, I am also a reasonably competent admin, but the fact that I have literally all the tools I need at my fingertips in the form of Debian packaged and signed software means the most sysadmin thing I have to do is "insert Debian DVD binary-1" to install something I forgot (or didn't know I needed until then).And unfortunately, most developers have little regard for the difference between USER and ROOT (or equivalent).
Until we bash them over the heads about it.As a (past) sysadmin and a current developer, I have to say this really depends.
For the most part, developers know what the hell they are doing; if they don't, they probably shouldn't be developers.
If they're unwilling to learn how to properly use root/admin, they shouldn't be in the computing industry.Concern for code is appropriate, but irrelevant.
Too much requires root or equivalent access in todays day and age.Granted, but again, this is a problem of what platform you choose.
Under Debian, I intentionally limit myself on the commands I run through sudo, even though I am the only user and admin.
I've found I can get by with about 6-7 commands (and one of those is visudo, to temporarily add something I might need).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606740</id>
	<title>Yes</title>
	<author>pmontra</author>
	<datestamp>1262282580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yes at every company I worked at (150 to 50k employees). One large company had a developers and non-developers environment, both without admin rights but developers could ask permanent admin rights if they could demonstrate that it was required by their job. All developers asked their bosses, bosses did the paperwork and developers got admin rights. Not sure that everybody really needed it as most of us didn't write a single line of code but actually managed contractors that did the job using their company's pcs. For sure we enjoyed the ability to install whatever we wanted on our notebooks that often were our home computers too. By the way, guys with admin rights had to fix of anything going wrong with their pc because requests for assistance would be billed to the budget of the company unit they belonged to.</htmltext>
<tokenext>Yes at every company I worked at ( 150 to 50k employees ) .
One large company had a developers and non-developers environment , both without admin rights but developers could ask permanent admin rights if they could demonstrate that it was required by their job .
All developers asked their bosses , bosses did the paperwork and developers got admin rights .
Not sure that everybody really needed it as most of us did n't write a single line of code but actually managed contractors that did the job using their company 's pcs .
For sure we enjoyed the ability to install whatever we wanted on our notebooks that often were our home computers too .
By the way , guys with admin rights had to fix of anything going wrong with their pc because requests for assistance would be billed to the budget of the company unit they belonged to .</tokentext>
<sentencetext>Yes at every company I worked at (150 to 50k employees).
One large company had a developers and non-developers environment, both without admin rights but developers could ask permanent admin rights if they could demonstrate that it was required by their job.
All developers asked their bosses, bosses did the paperwork and developers got admin rights.
Not sure that everybody really needed it as most of us didn't write a single line of code but actually managed contractors that did the job using their company's pcs.
For sure we enjoyed the ability to install whatever we wanted on our notebooks that often were our home computers too.
By the way, guys with admin rights had to fix of anything going wrong with their pc because requests for assistance would be billed to the budget of the company unit they belonged to.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718</id>
	<title>Re:You damn well should</title>
	<author>ckaminski</author>
	<datestamp>1262282520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>Because it's not a developers job to worry about day-to-day administration of their systems, and any one of those 100's of tools you download and install could be a trojan in disguise.  If your software runs in an unprivileged fashion, it's less likely to cause rampant widespread damage.<br><br>And unfortunately, most developers have little regard for the difference between USER and ROOT (or equivalent).  Until we bash them over the heads about it.<br><br>Concern for code is appropriate, but irrelevant.  Too much requires root or equivalent access in todays day and age.<br><br>Give me a shell on a unix machine somewhere with a compiler, and I can guarantee almost nothing I do will compromise the integrity of said machine... up until I run sudo somethingorother</htmltext>
<tokenext>Because it 's not a developers job to worry about day-to-day administration of their systems , and any one of those 100 's of tools you download and install could be a trojan in disguise .
If your software runs in an unprivileged fashion , it 's less likely to cause rampant widespread damage.And unfortunately , most developers have little regard for the difference between USER and ROOT ( or equivalent ) .
Until we bash them over the heads about it.Concern for code is appropriate , but irrelevant .
Too much requires root or equivalent access in todays day and age.Give me a shell on a unix machine somewhere with a compiler , and I can guarantee almost nothing I do will compromise the integrity of said machine... up until I run sudo somethingorother</tokentext>
<sentencetext>Because it's not a developers job to worry about day-to-day administration of their systems, and any one of those 100's of tools you download and install could be a trojan in disguise.
If your software runs in an unprivileged fashion, it's less likely to cause rampant widespread damage.And unfortunately, most developers have little regard for the difference between USER and ROOT (or equivalent).
Until we bash them over the heads about it.Concern for code is appropriate, but irrelevant.
Too much requires root or equivalent access in todays day and age.Give me a shell on a unix machine somewhere with a compiler, and I can guarantee almost nothing I do will compromise the integrity of said machine... up until I run sudo somethingorother</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606484</id>
	<title>yes</title>
	<author>Anonymous</author>
	<datestamp>1262281740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>yes I do have admin rights, I couldn't do my job without it (we do have strict anti-virus that runs at 50\% cpu all time time min). It takes forever to get IT or data-center to process requests so without local admin rights I would get almost nothing done each day. Actually we use windows machines to develop and don't deploy on windows machines. I tried to get non-windows machines to develop (makes sense to me) but to no avail.</p></htmltext>
<tokenext>yes I do have admin rights , I could n't do my job without it ( we do have strict anti-virus that runs at 50 \ % cpu all time time min ) .
It takes forever to get IT or data-center to process requests so without local admin rights I would get almost nothing done each day .
Actually we use windows machines to develop and do n't deploy on windows machines .
I tried to get non-windows machines to develop ( makes sense to me ) but to no avail .</tokentext>
<sentencetext>yes I do have admin rights, I couldn't do my job without it (we do have strict anti-virus that runs at 50\% cpu all time time min).
It takes forever to get IT or data-center to process requests so without local admin rights I would get almost nothing done each day.
Actually we use windows machines to develop and don't deploy on windows machines.
I tried to get non-windows machines to develop (makes sense to me) but to no avail.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608214</id>
	<title>VM?</title>
	<author>gollito</author>
	<datestamp>1262288340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Isn't that what VM's are for?  Give them a sandboxed VM running the corporate image on a server YOU control.  snapshots have them back to a pristine workstation after they are done testing.
<br>
<br>
On the dev machine, keep that restricted down to the core essentials for development, that way you don't have to worry about a dev system being compromised and having potentially harmful code introduced into whatever it is you are developing.
<br>
<br>
Keep the two separate I say.</htmltext>
<tokenext>Is n't that what VM 's are for ?
Give them a sandboxed VM running the corporate image on a server YOU control .
snapshots have them back to a pristine workstation after they are done testing .
On the dev machine , keep that restricted down to the core essentials for development , that way you do n't have to worry about a dev system being compromised and having potentially harmful code introduced into whatever it is you are developing .
Keep the two separate I say .</tokentext>
<sentencetext>Isn't that what VM's are for?
Give them a sandboxed VM running the corporate image on a server YOU control.
snapshots have them back to a pristine workstation after they are done testing.
On the dev machine, keep that restricted down to the core essentials for development, that way you don't have to worry about a dev system being compromised and having potentially harmful code introduced into whatever it is you are developing.
Keep the two separate I say.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606818</id>
	<title>Re:You damn well should</title>
	<author>qoncept</author>
	<datestamp>1262282820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Wow, what a bunch of morons. In addition to hiring people that understand you just can't do that kind of stuff, my company has controls in place to prevent it. Want to reboot a production server? You need a change ticket, approval and you're going to be doing it during the maintenance window unless it's an emergency. Gotta do it? Call it an emergency and explain yourself later. Can't? Find another job.</htmltext>
<tokenext>Wow , what a bunch of morons .
In addition to hiring people that understand you just ca n't do that kind of stuff , my company has controls in place to prevent it .
Want to reboot a production server ?
You need a change ticket , approval and you 're going to be doing it during the maintenance window unless it 's an emergency .
Got ta do it ?
Call it an emergency and explain yourself later .
Ca n't ? Find another job .</tokentext>
<sentencetext>Wow, what a bunch of morons.
In addition to hiring people that understand you just can't do that kind of stuff, my company has controls in place to prevent it.
Want to reboot a production server?
You need a change ticket, approval and you're going to be doing it during the maintenance window unless it's an emergency.
Gotta do it?
Call it an emergency and explain yourself later.
Can't? Find another job.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30614668</id>
	<title>Re:It's Target.</title>
	<author>Cederic</author>
	<datestamp>1230832020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My organisation has USB drives disabled on every desktop and laptop, unless you have written permission from a board member. (In context, there are thousands of employees and only a handful of board members).</p><p>This is an absolute pain, but is quite simply by far the easiest way to prevent accidental loss of data.</p><p>When that data can include our customers' financial information (which it easily can) it's hard to argue with taking extreme measures to protect it.</p><p>We also disable wireless network adaptors in the laptops, which is a far more contentious cost/benefit trade-off.</p></htmltext>
<tokenext>My organisation has USB drives disabled on every desktop and laptop , unless you have written permission from a board member .
( In context , there are thousands of employees and only a handful of board members ) .This is an absolute pain , but is quite simply by far the easiest way to prevent accidental loss of data.When that data can include our customers ' financial information ( which it easily can ) it 's hard to argue with taking extreme measures to protect it.We also disable wireless network adaptors in the laptops , which is a far more contentious cost/benefit trade-off .</tokentext>
<sentencetext>My organisation has USB drives disabled on every desktop and laptop, unless you have written permission from a board member.
(In context, there are thousands of employees and only a handful of board members).This is an absolute pain, but is quite simply by far the easiest way to prevent accidental loss of data.When that data can include our customers' financial information (which it easily can) it's hard to argue with taking extreme measures to protect it.We also disable wireless network adaptors in the laptops, which is a far more contentious cost/benefit trade-off.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612120</id>
	<title>Re:You damn well should</title>
	<author>Manxa</author>
	<datestamp>1262276640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I work for a startup e-commerce company which uses Catalyst as the frame for some of the front facing applications.

The developers, QA testers, and development (dev and qa inclusive) managers all have admin rights to their PC.  IMO its much easier to allow local admin rights rather than bugging the sysadmins every time they (read 'we') need to install a piece of software.  The sysadmins have enough on their plate without babysitting the development team.<p><div class="quote"><p> <i>You'd think that would be the case but, in my experience, I've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops.</i></p> </div><p>I agree.  We have some brilliant developers who will ask an occasional Windoze question.

I grew up in a Windoze env, so in retort, I ask the occasional Linux question.<nobr> <wbr></nobr>:)</p><p><div class="quote"><p> <i>But admin access to production servers, absolutely not.  I've seen way too many scary, scary things happen when developers are given unrestricted access to production systems.</i></p> </div><p>We recently had a complete overhaul of the company/development team, to include creation of business requirements gathering and proper coding standards.  The prior development team had a few developers with admin access who would change code on the fly without sysadmin approval/procedure.  Code would then be "backdated" in order to trickle the production changes down to the other developers.  Sometimes the production fix didn't always work.  Imagine the customer/customer/end-user experience if your site was Javascript intensive/dependent and worked one moment but broke the next?</p></div>
	</htmltext>
<tokenext>I work for a startup e-commerce company which uses Catalyst as the frame for some of the front facing applications .
The developers , QA testers , and development ( dev and qa inclusive ) managers all have admin rights to their PC .
IMO its much easier to allow local admin rights rather than bugging the sysadmins every time they ( read 'we ' ) need to install a piece of software .
The sysadmins have enough on their plate without babysitting the development team .
You 'd think that would be the case but , in my experience , I 've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops .
I agree .
We have some brilliant developers who will ask an occasional Windoze question .
I grew up in a Windoze env , so in retort , I ask the occasional Linux question .
: ) But admin access to production servers , absolutely not .
I 've seen way too many scary , scary things happen when developers are given unrestricted access to production systems .
We recently had a complete overhaul of the company/development team , to include creation of business requirements gathering and proper coding standards .
The prior development team had a few developers with admin access who would change code on the fly without sysadmin approval/procedure .
Code would then be " backdated " in order to trickle the production changes down to the other developers .
Sometimes the production fix did n't always work .
Imagine the customer/customer/end-user experience if your site was Javascript intensive/dependent and worked one moment but broke the next ?</tokentext>
<sentencetext>I work for a startup e-commerce company which uses Catalyst as the frame for some of the front facing applications.
The developers, QA testers, and development (dev and qa inclusive) managers all have admin rights to their PC.
IMO its much easier to allow local admin rights rather than bugging the sysadmins every time they (read 'we') need to install a piece of software.
The sysadmins have enough on their plate without babysitting the development team.
You'd think that would be the case but, in my experience, I've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops.
I agree.
We have some brilliant developers who will ask an occasional Windoze question.
I grew up in a Windoze env, so in retort, I ask the occasional Linux question.
:) But admin access to production servers, absolutely not.
I've seen way too many scary, scary things happen when developers are given unrestricted access to production systems.
We recently had a complete overhaul of the company/development team, to include creation of business requirements gathering and proper coding standards.
The prior development team had a few developers with admin access who would change code on the fly without sysadmin approval/procedure.
Code would then be "backdated" in order to trickle the production changes down to the other developers.
Sometimes the production fix didn't always work.
Imagine the customer/customer/end-user experience if your site was Javascript intensive/dependent and worked one moment but broke the next?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609222</id>
	<title>Been there, never going back...</title>
	<author>American Expat</author>
	<datestamp>1262250600000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>I worked for a small development company (C++/J2EE on a windows platform) that was bought out by a publishing behemoth, and the IT department idiocy was the primary reason I left.  We not only had no administrative rights on our development boxes, but we had a *single* corporate configuration that was pushed out every night.  Among the gems in this were:
<ul>
<li>EVERY FILE OPENED was scanned for viruses, including newly created files.  C++ compile times went from minutes to many hours</li>
<li>Only one socket connection could be opened to any machine. Could not connect a debugger to a web app.</li>
<li>Programs on a "dangerous" list were deleted from the hard drive in a nightly scan.  Found this out when my wire sniffer disappeared.</li>
<li>We could not use torrents or FTP.  Had to download ISOs via HTTP</li>
</ul><p>
With these bozos calling the shots, it took less than a year to turn a world-class development shop into a ghost town.</p><p>
Like it or not IT pals, developers have to do things on their boxes that normal users should not be able to.  If you try and prevent them you will force them to come up with even more dangerous workarounds (tunnels to home boxes, dark nets, etc).  If you're worried about security isolate their network, but don't make it impossible to do their jobs.</p></htmltext>
<tokenext>I worked for a small development company ( C + + /J2EE on a windows platform ) that was bought out by a publishing behemoth , and the IT department idiocy was the primary reason I left .
We not only had no administrative rights on our development boxes , but we had a * single * corporate configuration that was pushed out every night .
Among the gems in this were : EVERY FILE OPENED was scanned for viruses , including newly created files .
C + + compile times went from minutes to many hours Only one socket connection could be opened to any machine .
Could not connect a debugger to a web app .
Programs on a " dangerous " list were deleted from the hard drive in a nightly scan .
Found this out when my wire sniffer disappeared .
We could not use torrents or FTP .
Had to download ISOs via HTTP With these bozos calling the shots , it took less than a year to turn a world-class development shop into a ghost town .
Like it or not IT pals , developers have to do things on their boxes that normal users should not be able to .
If you try and prevent them you will force them to come up with even more dangerous workarounds ( tunnels to home boxes , dark nets , etc ) .
If you 're worried about security isolate their network , but do n't make it impossible to do their jobs .</tokentext>
<sentencetext>I worked for a small development company (C++/J2EE on a windows platform) that was bought out by a publishing behemoth, and the IT department idiocy was the primary reason I left.
We not only had no administrative rights on our development boxes, but we had a *single* corporate configuration that was pushed out every night.
Among the gems in this were:

EVERY FILE OPENED was scanned for viruses, including newly created files.
C++ compile times went from minutes to many hours
Only one socket connection could be opened to any machine.
Could not connect a debugger to a web app.
Programs on a "dangerous" list were deleted from the hard drive in a nightly scan.
Found this out when my wire sniffer disappeared.
We could not use torrents or FTP.
Had to download ISOs via HTTP

With these bozos calling the shots, it took less than a year to turn a world-class development shop into a ghost town.
Like it or not IT pals, developers have to do things on their boxes that normal users should not be able to.
If you try and prevent them you will force them to come up with even more dangerous workarounds (tunnels to home boxes, dark nets, etc).
If you're worried about security isolate their network, but don't make it impossible to do their jobs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609444</id>
	<title>windows?</title>
	<author>Anonymous</author>
	<datestamp>1262251980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>All developers I work with uses Linux<nobr> <wbr></nobr>:-) But then I'm lucky.</p></htmltext>
<tokenext>All developers I work with uses Linux : - ) But then I 'm lucky .</tokentext>
<sentencetext>All developers I work with uses Linux :-) But then I'm lucky.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704</id>
	<title>Re:What it REALLY comes down to</title>
	<author>bakuun</author>
	<datestamp>1262270460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>Here's the thing... Why the **** does windows program installation basically require files be installed any place other than locally. That's the entire problem.</p></div><p>For the same reason that most other operating systems, including most flavors of linux, requires admin rights to install software. There are reasons that you want the operating system to be aware of when software is installed. One good advantage of this (in the Windows world) is the add/remove programs section under the control panel, where you can view all installed software, how large they are, and easily uninstall any of them. Another advantage (this time from linux) is system-wide updates of all installed software.</p><p><div class="quote"><p>The entire design of windows is to install **** under system32 or program files when it doesn't need to be there.  I remember the old days when programs ran under one directory.</p></div><p>Yeah, one directory, like... "Program files"? Every program installs to Program files by default, although the user is free to change this of course.

How does it work in linux? Well, if you install something parts of it can go in<nobr> <wbr></nobr>/usr/bin, parts go in<nobr> <wbr></nobr>/etc, parts in<nobr> <wbr></nobr>/usr/lib, some in<nobr> <wbr></nobr>/var/.../</p><p><div class="quote"><p> You know where everything is.  To uninstall is simply to delete.  Don't get me started on the registry.  REALLY? You're telling me it's "faster" than reading a text file config.  Hardly.</p> </div><p>I don't know if it's faster - it might be, or not. It probably doesn't matter a great deal anyway - it's not like it's a lot of data. I doubt it's slower, though. The windows registry is a hierarchical system of configuration settings (with parts that are global for the machine and parts that are local to the user), and<nobr> <wbr></nobr>/etc is a hierarchical system of configuration settings (contained in text files)... Where's the big difference?</p></div>
	</htmltext>
<tokenext>Here 's the thing... Why the * * * * does windows program installation basically require files be installed any place other than locally .
That 's the entire problem.For the same reason that most other operating systems , including most flavors of linux , requires admin rights to install software .
There are reasons that you want the operating system to be aware of when software is installed .
One good advantage of this ( in the Windows world ) is the add/remove programs section under the control panel , where you can view all installed software , how large they are , and easily uninstall any of them .
Another advantage ( this time from linux ) is system-wide updates of all installed software.The entire design of windows is to install * * * * under system32 or program files when it does n't need to be there .
I remember the old days when programs ran under one directory.Yeah , one directory , like... " Program files " ?
Every program installs to Program files by default , although the user is free to change this of course .
How does it work in linux ?
Well , if you install something parts of it can go in /usr/bin , parts go in /etc , parts in /usr/lib , some in /var/.../ You know where everything is .
To uninstall is simply to delete .
Do n't get me started on the registry .
REALLY ? You 're telling me it 's " faster " than reading a text file config .
Hardly. I do n't know if it 's faster - it might be , or not .
It probably does n't matter a great deal anyway - it 's not like it 's a lot of data .
I doubt it 's slower , though .
The windows registry is a hierarchical system of configuration settings ( with parts that are global for the machine and parts that are local to the user ) , and /etc is a hierarchical system of configuration settings ( contained in text files ) ... Where 's the big difference ?</tokentext>
<sentencetext>Here's the thing... Why the **** does windows program installation basically require files be installed any place other than locally.
That's the entire problem.For the same reason that most other operating systems, including most flavors of linux, requires admin rights to install software.
There are reasons that you want the operating system to be aware of when software is installed.
One good advantage of this (in the Windows world) is the add/remove programs section under the control panel, where you can view all installed software, how large they are, and easily uninstall any of them.
Another advantage (this time from linux) is system-wide updates of all installed software.The entire design of windows is to install **** under system32 or program files when it doesn't need to be there.
I remember the old days when programs ran under one directory.Yeah, one directory, like... "Program files"?
Every program installs to Program files by default, although the user is free to change this of course.
How does it work in linux?
Well, if you install something parts of it can go in /usr/bin, parts go in /etc, parts in /usr/lib, some in /var/.../ You know where everything is.
To uninstall is simply to delete.
Don't get me started on the registry.
REALLY? You're telling me it's "faster" than reading a text file config.
Hardly. I don't know if it's faster - it might be, or not.
It probably doesn't matter a great deal anyway - it's not like it's a lot of data.
I doubt it's slower, though.
The windows registry is a hierarchical system of configuration settings (with parts that are global for the machine and parts that are local to the user), and /etc is a hierarchical system of configuration settings (contained in text files)... Where's the big difference?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611210</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262265240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Shoulda, coulda, whatever.  Developers are generally inept when it comes to system management.  It has been this way for the last 10 years.</p></htmltext>
<tokenext>Shoulda , coulda , whatever .
Developers are generally inept when it comes to system management .
It has been this way for the last 10 years .</tokentext>
<sentencetext>Shoulda, coulda, whatever.
Developers are generally inept when it comes to system management.
It has been this way for the last 10 years.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607934</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607236</id>
	<title>No Way</title>
	<author>Anonymous</author>
	<datestamp>1262284380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>No, why on earth would they need local admin rights?  I can't think of single legitimate reason to grant such rights.  Testing should be done in the lab and nobody should be installing software on their own.</p></htmltext>
<tokenext>No , why on earth would they need local admin rights ?
I ca n't think of single legitimate reason to grant such rights .
Testing should be done in the lab and nobody should be installing software on their own .</tokentext>
<sentencetext>No, why on earth would they need local admin rights?
I can't think of single legitimate reason to grant such rights.
Testing should be done in the lab and nobody should be installing software on their own.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607648</id>
	<title>Re:Yes</title>
	<author>Anonymous</author>
	<datestamp>1262285940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I have always given our developers local admin rights on their machines.</p><p>I am responsible for the servers, the network, and the desktop machines and peripherals.  I trust the developers to be intelligent, careful, and to know their needs better than I do.</p><p>I will assist them if they run into trouble, or screw up their machines, but they are not a priority -with local admin rights comes the responsibility for fixing your own problems.  They are also made aware that if they cause harm to the rest of the systems/infrastructure either directly or thru negligence (ie spread a virus, etc.) that it can cost them their jobs.</p><p>This has been policy across many companies, both small shops, and large multinationals.</p></htmltext>
<tokenext>I have always given our developers local admin rights on their machines.I am responsible for the servers , the network , and the desktop machines and peripherals .
I trust the developers to be intelligent , careful , and to know their needs better than I do.I will assist them if they run into trouble , or screw up their machines , but they are not a priority -with local admin rights comes the responsibility for fixing your own problems .
They are also made aware that if they cause harm to the rest of the systems/infrastructure either directly or thru negligence ( ie spread a virus , etc .
) that it can cost them their jobs.This has been policy across many companies , both small shops , and large multinationals .</tokentext>
<sentencetext>I have always given our developers local admin rights on their machines.I am responsible for the servers, the network, and the desktop machines and peripherals.
I trust the developers to be intelligent, careful, and to know their needs better than I do.I will assist them if they run into trouble, or screw up their machines, but they are not a priority -with local admin rights comes the responsibility for fixing your own problems.
They are also made aware that if they cause harm to the rest of the systems/infrastructure either directly or thru negligence (ie spread a virus, etc.
) that it can cost them their jobs.This has been policy across many companies, both small shops, and large multinationals.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607672</id>
	<title>Admin rights Shmadmin rights.</title>
	<author>Anonymous</author>
	<datestamp>1262286000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You're a developer, you have a compiler.  IT doesn't realise it, but developers aren't bound by any requirement for "admin rights".  If developers want a piece of software, they can just compile it and run it.  It's pretty standard security theatre.</p><p>I had a friend working at a company where he didn't have admin rights, and he wanted to run a Wiki.  The IT team didn't give him approval, so he downloaded Apache, Python, Perl and a Wiki.  Compiled them all and had a Wiki running on his locked down machine within 3 hours.</p><p>Locked down desktops are easily subverted when someone is given a programming language.</p></htmltext>
<tokenext>You 're a developer , you have a compiler .
IT does n't realise it , but developers are n't bound by any requirement for " admin rights " .
If developers want a piece of software , they can just compile it and run it .
It 's pretty standard security theatre.I had a friend working at a company where he did n't have admin rights , and he wanted to run a Wiki .
The IT team did n't give him approval , so he downloaded Apache , Python , Perl and a Wiki .
Compiled them all and had a Wiki running on his locked down machine within 3 hours.Locked down desktops are easily subverted when someone is given a programming language .</tokentext>
<sentencetext>You're a developer, you have a compiler.
IT doesn't realise it, but developers aren't bound by any requirement for "admin rights".
If developers want a piece of software, they can just compile it and run it.
It's pretty standard security theatre.I had a friend working at a company where he didn't have admin rights, and he wanted to run a Wiki.
The IT team didn't give him approval, so he downloaded Apache, Python, Perl and a Wiki.
Compiled them all and had a Wiki running on his locked down machine within 3 hours.Locked down desktops are easily subverted when someone is given a programming language.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608116</id>
	<title>Re:Yeah.</title>
	<author>Anonymous</author>
	<datestamp>1262287920000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>plus the fact that developers are going to cause less harm than average users</p></div><p>As a developer and former sysadmin. I think are wrong there, I know that if I have a bad day at work and don't think one extra time before pressing enter och commiting I could wreck a much bigger havoc compared to a normal user that uses some gui that ask "are you sure" and they would not even think of doing some of the things I may do because they do not have the same know how. I think as a developer and sysadmin that developers are the most dangerous people to have running around with more privileges than needed.

A developer that whips together a bash script for fast fix ending up in "rm -rf<nobr> <wbr></nobr>/"</p></div>
	</htmltext>
<tokenext>plus the fact that developers are going to cause less harm than average usersAs a developer and former sysadmin .
I think are wrong there , I know that if I have a bad day at work and do n't think one extra time before pressing enter och commiting I could wreck a much bigger havoc compared to a normal user that uses some gui that ask " are you sure " and they would not even think of doing some of the things I may do because they do not have the same know how .
I think as a developer and sysadmin that developers are the most dangerous people to have running around with more privileges than needed .
A developer that whips together a bash script for fast fix ending up in " rm -rf / "</tokentext>
<sentencetext>plus the fact that developers are going to cause less harm than average usersAs a developer and former sysadmin.
I think are wrong there, I know that if I have a bad day at work and don't think one extra time before pressing enter och commiting I could wreck a much bigger havoc compared to a normal user that uses some gui that ask "are you sure" and they would not even think of doing some of the things I may do because they do not have the same know how.
I think as a developer and sysadmin that developers are the most dangerous people to have running around with more privileges than needed.
A developer that whips together a bash script for fast fix ending up in "rm -rf /"
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607100</id>
	<title>Developers Require Local Admin</title>
	<author>filesiteguy</author>
	<datestamp>1262283780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I have eight developers who work for me, all doing Wintendo development using<nobr> <wbr></nobr>.net (C#, asp.net), some COM (still!) and even some cold fusion and ADABAS.  For the Wintendo systems, they require local admin in order to be able to test installations of assemblies and other DLL files in "protected" areas as well as gaining access to HKLM and other needd registry hives.<br><br>Our users - around 2000 - have only normal user accounts.</htmltext>
<tokenext>I have eight developers who work for me , all doing Wintendo development using .net ( C # , asp.net ) , some COM ( still !
) and even some cold fusion and ADABAS .
For the Wintendo systems , they require local admin in order to be able to test installations of assemblies and other DLL files in " protected " areas as well as gaining access to HKLM and other needd registry hives.Our users - around 2000 - have only normal user accounts .</tokentext>
<sentencetext>I have eight developers who work for me, all doing Wintendo development using .net (C#, asp.net), some COM (still!
) and even some cold fusion and ADABAS.
For the Wintendo systems, they require local admin in order to be able to test installations of assemblies and other DLL files in "protected" areas as well as gaining access to HKLM and other needd registry hives.Our users - around 2000 - have only normal user accounts.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609992</id>
	<title>who needs admin/root rights...</title>
	<author>Anonymous</author>
	<datestamp>1262255220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>By default OS's are (or should be) designed to not need admin/root rights for most of the tasks. Only real admin tasks needs those.</p><p>As for developement or running a service/program/whatever it will be possible to write code that will simply be run as a user (Although it is often started as root and then forked to a user). This is better for the security and it will still provide you enough rights to do what is needed.</p></htmltext>
<tokenext>By default OS 's are ( or should be ) designed to not need admin/root rights for most of the tasks .
Only real admin tasks needs those.As for developement or running a service/program/whatever it will be possible to write code that will simply be run as a user ( Although it is often started as root and then forked to a user ) .
This is better for the security and it will still provide you enough rights to do what is needed .</tokentext>
<sentencetext>By default OS's are (or should be) designed to not need admin/root rights for most of the tasks.
Only real admin tasks needs those.As for developement or running a service/program/whatever it will be possible to write code that will simply be run as a user (Although it is often started as root and then forked to a user).
This is better for the security and it will still provide you enough rights to do what is needed.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607434</id>
	<title>Re:Yeah.</title>
	<author>happyemoticon</author>
	<datestamp>1262285100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There's nothing that pisses off a supervisor like, "I couldn't get anything done this week because the guys who have admin access to [insert name of vital but poorly-integrated resource] were on vacation."</p></htmltext>
<tokenext>There 's nothing that pisses off a supervisor like , " I could n't get anything done this week because the guys who have admin access to [ insert name of vital but poorly-integrated resource ] were on vacation .
"</tokentext>
<sentencetext>There's nothing that pisses off a supervisor like, "I couldn't get anything done this week because the guys who have admin access to [insert name of vital but poorly-integrated resource] were on vacation.
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607292</id>
	<title>Re:You damn well should</title>
	<author>alen</author>
	<datestamp>1262284560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>or the worst download of all, Google Desktop. it will scan  your email and kill your Exchange server in the process by constantly indexing whatever is in your mailbox</p></htmltext>
<tokenext>or the worst download of all , Google Desktop .
it will scan your email and kill your Exchange server in the process by constantly indexing whatever is in your mailbox</tokentext>
<sentencetext>or the worst download of all, Google Desktop.
it will scan  your email and kill your Exchange server in the process by constantly indexing whatever is in your mailbox</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609960</id>
	<title>Re:Virtualization is your Friend</title>
	<author>syousef</author>
	<datestamp>1262255040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Sure, if you're willing to spend as much on a dev workstation as you'd normally spend on a server. Have you ever tried running Eclipse and Weblogic in dev mode inside a VM? You might deploy to a Prod or Test environment once every couple of weeks at most. On a dev box you might be doing so more than once an hour. As it is developers are starting to hit memory limitations that are going to require a move to 64 bit to resolve.</p></htmltext>
<tokenext>Sure , if you 're willing to spend as much on a dev workstation as you 'd normally spend on a server .
Have you ever tried running Eclipse and Weblogic in dev mode inside a VM ?
You might deploy to a Prod or Test environment once every couple of weeks at most .
On a dev box you might be doing so more than once an hour .
As it is developers are starting to hit memory limitations that are going to require a move to 64 bit to resolve .</tokentext>
<sentencetext>Sure, if you're willing to spend as much on a dev workstation as you'd normally spend on a server.
Have you ever tried running Eclipse and Weblogic in dev mode inside a VM?
You might deploy to a Prod or Test environment once every couple of weeks at most.
On a dev box you might be doing so more than once an hour.
As it is developers are starting to hit memory limitations that are going to require a move to 64 bit to resolve.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618544</id>
	<title>Then admins were not good enough.</title>
	<author>jotaeleemeese</author>
	<datestamp>1230822000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I would have identified the offending programs next day and had a serious disciplinary talk with your mate.</p><p>Nowadays there are plenty of tools to audit machines to stop these kind of shenanigans.</p></htmltext>
<tokenext>I would have identified the offending programs next day and had a serious disciplinary talk with your mate.Nowadays there are plenty of tools to audit machines to stop these kind of shenanigans .</tokentext>
<sentencetext>I would have identified the offending programs next day and had a serious disciplinary talk with your mate.Nowadays there are plenty of tools to audit machines to stop these kind of shenanigans.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607672</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610174</id>
	<title>Re:Virtualization is your Friend</title>
	<author>Anonymous</author>
	<datestamp>1262256360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>I worked for a company that tried to lock me down. I put a trojan in the code for our product that gave me a back door into every machine in the company. I used my back door to steal everyone's passwords and to establish several other entry mechanisms in case they tried to lock me down again. Doing all this set me back about a week, but I was much more productive thereafter. I later told management about it. To my shock, they were impressed that I wouldn't allow anything to hinder my work, and they promoted me. I'd bet most places would respond so well, but I would never tolerate a company that treats me so poorly that they won't give me full access to the hardware.</htmltext>
<tokenext>I worked for a company that tried to lock me down .
I put a trojan in the code for our product that gave me a back door into every machine in the company .
I used my back door to steal everyone 's passwords and to establish several other entry mechanisms in case they tried to lock me down again .
Doing all this set me back about a week , but I was much more productive thereafter .
I later told management about it .
To my shock , they were impressed that I would n't allow anything to hinder my work , and they promoted me .
I 'd bet most places would respond so well , but I would never tolerate a company that treats me so poorly that they wo n't give me full access to the hardware .</tokentext>
<sentencetext>I worked for a company that tried to lock me down.
I put a trojan in the code for our product that gave me a back door into every machine in the company.
I used my back door to steal everyone's passwords and to establish several other entry mechanisms in case they tried to lock me down again.
Doing all this set me back about a week, but I was much more productive thereafter.
I later told management about it.
To my shock, they were impressed that I wouldn't allow anything to hinder my work, and they promoted me.
I'd bet most places would respond so well, but I would never tolerate a company that treats me so poorly that they won't give me full access to the hardware.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607958</id>
	<title>It really does depend.</title>
	<author>SecurityGuy</author>
	<datestamp>1262287080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've been the sys admin.  I've been the developer.  I've been both at once.</p><p>Security guys tend to forget that work needs to get done.  Developers tend to forget that the way they want to do their job is sometimes not allowed (we security guys often don't make the rules, we just get busted for not following them) or is illegal (I don't care how much you need $COMMERCIAL\_PACKAGE, pay for it or keep it off my systems).  This is not entirely by accident.  It's just separation of duties.  If you have two important jobs to get done, and those jobs conflict, give them to separate people.  If you give the whole thing to developers, they'll develop software and not worry so much about the security bit.</p><p>The general problem is that if you have a set of rules that have to be followed, the more people you need to get to follow them, the lower the chance it's actually going to happen.  That's why as processes scale up, you start getting these people the developers see as a waste of time in the loop.  In IT, it's system admins and whatever you call your security group.  In medical research, it's data managers, who might not be trained to do the research, but can be meticulous about making sure the data bits are done right.</p><p>Personally, I'm happy to give out admin rights to people who use them responsibly, which I define as to do the set of things they told me they need them for, and then only in the furtherance of their actual job, not installing fluff crap they just want, like news(paper) readers.  It's sadly a small minority that actually do this.</p><p>Really, both sides just need to listen to each other and show a little respect.  We all just have a job to do.</p></htmltext>
<tokenext>I 've been the sys admin .
I 've been the developer .
I 've been both at once.Security guys tend to forget that work needs to get done .
Developers tend to forget that the way they want to do their job is sometimes not allowed ( we security guys often do n't make the rules , we just get busted for not following them ) or is illegal ( I do n't care how much you need $ COMMERCIAL \ _PACKAGE , pay for it or keep it off my systems ) .
This is not entirely by accident .
It 's just separation of duties .
If you have two important jobs to get done , and those jobs conflict , give them to separate people .
If you give the whole thing to developers , they 'll develop software and not worry so much about the security bit.The general problem is that if you have a set of rules that have to be followed , the more people you need to get to follow them , the lower the chance it 's actually going to happen .
That 's why as processes scale up , you start getting these people the developers see as a waste of time in the loop .
In IT , it 's system admins and whatever you call your security group .
In medical research , it 's data managers , who might not be trained to do the research , but can be meticulous about making sure the data bits are done right.Personally , I 'm happy to give out admin rights to people who use them responsibly , which I define as to do the set of things they told me they need them for , and then only in the furtherance of their actual job , not installing fluff crap they just want , like news ( paper ) readers .
It 's sadly a small minority that actually do this.Really , both sides just need to listen to each other and show a little respect .
We all just have a job to do .</tokentext>
<sentencetext>I've been the sys admin.
I've been the developer.
I've been both at once.Security guys tend to forget that work needs to get done.
Developers tend to forget that the way they want to do their job is sometimes not allowed (we security guys often don't make the rules, we just get busted for not following them) or is illegal (I don't care how much you need $COMMERCIAL\_PACKAGE, pay for it or keep it off my systems).
This is not entirely by accident.
It's just separation of duties.
If you have two important jobs to get done, and those jobs conflict, give them to separate people.
If you give the whole thing to developers, they'll develop software and not worry so much about the security bit.The general problem is that if you have a set of rules that have to be followed, the more people you need to get to follow them, the lower the chance it's actually going to happen.
That's why as processes scale up, you start getting these people the developers see as a waste of time in the loop.
In IT, it's system admins and whatever you call your security group.
In medical research, it's data managers, who might not be trained to do the research, but can be meticulous about making sure the data bits are done right.Personally, I'm happy to give out admin rights to people who use them responsibly, which I define as to do the set of things they told me they need them for, and then only in the furtherance of their actual job, not installing fluff crap they just want, like news(paper) readers.
It's sadly a small minority that actually do this.Really, both sides just need to listen to each other and show a little respect.
We all just have a job to do.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606884</id>
	<title>Yes</title>
	<author>Anonymous</author>
	<datestamp>1262283060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yes</p></htmltext>
<tokenext>Yes</tokentext>
<sentencetext>Yes</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607316</id>
	<title>Yes at Apple (plus setup and config)</title>
	<author>Anonymous</author>
	<datestamp>1262284680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>All employees setup, administer, and maintain their own machines. Indeed when you get your machine it's in the box (often refurb) and it is up to you to get it setup, download the internal authentication software and connect to the services you need. They really do eat their own dog food and it must save them an amazing amount on IT costs.</p></htmltext>
<tokenext>All employees setup , administer , and maintain their own machines .
Indeed when you get your machine it 's in the box ( often refurb ) and it is up to you to get it setup , download the internal authentication software and connect to the services you need .
They really do eat their own dog food and it must save them an amazing amount on IT costs .</tokentext>
<sentencetext>All employees setup, administer, and maintain their own machines.
Indeed when you get your machine it's in the box (often refurb) and it is up to you to get it setup, download the internal authentication software and connect to the services you need.
They really do eat their own dog food and it must save them an amazing amount on IT costs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607556</id>
	<title>You gotta keep them in their place</title>
	<author>Anonymous</author>
	<datestamp>1262285580000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Who the fuck are these IT monkeys who think they know more about computers than we do? Support costs? Security risks? You support people running IE 6! Don't you fucking lecture me about security risks, you miserable little cunts! I have admin on all my boxes and you'll fucking like it!</p><p>Oh, Jesus Christ, stop sniveling. I run your god damned AV software, isn't that a enough? You cost me thirty seconds out of every boot, not to mention how it slows down check-outs and benchmarks. I don't have to participate in your moron circle-jerk, but fuck if I'm going to be blamed because you can't keep Peggy in accounting from unleashing a three-year-old Outlook worm.</p><p>And you want to know something? Us developers <i>do</i> email zip files, and sometimes executables! We just change the file name! Ha-ha, you guys are dense.</p></htmltext>
<tokenext>Who the fuck are these IT monkeys who think they know more about computers than we do ?
Support costs ?
Security risks ?
You support people running IE 6 !
Do n't you fucking lecture me about security risks , you miserable little cunts !
I have admin on all my boxes and you 'll fucking like it ! Oh , Jesus Christ , stop sniveling .
I run your god damned AV software , is n't that a enough ?
You cost me thirty seconds out of every boot , not to mention how it slows down check-outs and benchmarks .
I do n't have to participate in your moron circle-jerk , but fuck if I 'm going to be blamed because you ca n't keep Peggy in accounting from unleashing a three-year-old Outlook worm.And you want to know something ?
Us developers do email zip files , and sometimes executables !
We just change the file name !
Ha-ha , you guys are dense .</tokentext>
<sentencetext>Who the fuck are these IT monkeys who think they know more about computers than we do?
Support costs?
Security risks?
You support people running IE 6!
Don't you fucking lecture me about security risks, you miserable little cunts!
I have admin on all my boxes and you'll fucking like it!Oh, Jesus Christ, stop sniveling.
I run your god damned AV software, isn't that a enough?
You cost me thirty seconds out of every boot, not to mention how it slows down check-outs and benchmarks.
I don't have to participate in your moron circle-jerk, but fuck if I'm going to be blamed because you can't keep Peggy in accounting from unleashing a three-year-old Outlook worm.And you want to know something?
Us developers do email zip files, and sometimes executables!
We just change the file name!
Ha-ha, you guys are dense.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606580</id>
	<title>Yes</title>
	<author>Anonymous</author>
	<datestamp>1262282040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>We trust our developers as much as we trust our admins.

Actually, I trust our developers more than our admins, but the admins already have the highest privilege.</htmltext>
<tokenext>We trust our developers as much as we trust our admins .
Actually , I trust our developers more than our admins , but the admins already have the highest privilege .</tokentext>
<sentencetext>We trust our developers as much as we trust our admins.
Actually, I trust our developers more than our admins, but the admins already have the highest privilege.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608488</id>
	<title>Theres Overlap in the job description.</title>
	<author>djwillms</author>
	<datestamp>1262289960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Developers have to write Administrative functions in code.
For example:

Its absolutely required that Developers be able to write the Installation / setup programs and test them.

For windows machines, that means that Developers need rights to modify the Registry, startup scripts, Install System Services,
End Task on anything, Set Security Permissions in NTFS, Modify User Accounts (such as adding icons to all users, or specific users)

That doesnt mean, that the core program needs to run as ADMIN, but most likely, the Install/ Uninstall should.</htmltext>
<tokenext>Developers have to write Administrative functions in code .
For example : Its absolutely required that Developers be able to write the Installation / setup programs and test them .
For windows machines , that means that Developers need rights to modify the Registry , startup scripts , Install System Services , End Task on anything , Set Security Permissions in NTFS , Modify User Accounts ( such as adding icons to all users , or specific users ) That doesnt mean , that the core program needs to run as ADMIN , but most likely , the Install/ Uninstall should .</tokentext>
<sentencetext>Developers have to write Administrative functions in code.
For example:

Its absolutely required that Developers be able to write the Installation / setup programs and test them.
For windows machines, that means that Developers need rights to modify the Registry, startup scripts, Install System Services,
End Task on anything, Set Security Permissions in NTFS, Modify User Accounts (such as adding icons to all users, or specific users)

That doesnt mean, that the core program needs to run as ADMIN, but most likely, the Install/ Uninstall should.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607838</id>
	<title>No to local PC, Yes to production servers</title>
	<author>tonyfugere</author>
	<datestamp>1262286660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>At my last position I was at a local market level. The local market had its own IT team with security policies given to them by a division team. Division got its policies from corporate. Sometimes things were altered to suit the divison or local market, too.

When working there, I had full admin rights to production servers, but not to the PC from which I worked. This was stressful as I was forced to develop in the production environment. It was also ironic that I had admin rights to these servers but not my PC. It was because IT did not have the training or time to admin the servers (SQL and SharePoint). I did my best to have the local IT team install software after software to enable development from my PC as best as possible. After about 9 months on the job, I obtained a development server that I could work from via remote desktop. By then, I had already developed processes to develop from the production server. Also, the development box was SLOW and annoying to use (an old Pentium III box...).

This all seems a bit backwards and it took some adjustment, but it worked. I became a hero for being able to manage these servers as well as develop new tools for the local market. I got along very well with the IT department and they were very competent and helpful which made working with them easier. I would have appreciated local admin rights, but the local IT manager was not able to bend the rules for anyone without getting in trouble if audited by division.

I am working at the same company at the corporate level after moving up from the local market level. At corporate I have full admin rights to both a desktop and laptop for development. I do not have admin (root) access to development and production servers though. We have a sysadmin team dedicated to protecting our servers from ourselves. Change request procedures ensure the environments are modified properly. For PC support, We have a local IT team that reports to the division office as I sit a thousand of miles from actual HQ.

There have been times where admin rights (root) to servers would be nice, but we have 10+ developers relying on that server to be available for work/testing/etc. So, I can understand why the servers must be managed by an SA team. Change requests are simple and usually accomplished in a fair amount of time. For times I absolutely need root access to try out new things, I just build Virtual Machines on my desktop and try before I place a CR for the dev servers. Production CR's are much more strict and those servers never have compiling tools to restrict local users from building binaries that could break things.</htmltext>
<tokenext>At my last position I was at a local market level .
The local market had its own IT team with security policies given to them by a division team .
Division got its policies from corporate .
Sometimes things were altered to suit the divison or local market , too .
When working there , I had full admin rights to production servers , but not to the PC from which I worked .
This was stressful as I was forced to develop in the production environment .
It was also ironic that I had admin rights to these servers but not my PC .
It was because IT did not have the training or time to admin the servers ( SQL and SharePoint ) .
I did my best to have the local IT team install software after software to enable development from my PC as best as possible .
After about 9 months on the job , I obtained a development server that I could work from via remote desktop .
By then , I had already developed processes to develop from the production server .
Also , the development box was SLOW and annoying to use ( an old Pentium III box... ) .
This all seems a bit backwards and it took some adjustment , but it worked .
I became a hero for being able to manage these servers as well as develop new tools for the local market .
I got along very well with the IT department and they were very competent and helpful which made working with them easier .
I would have appreciated local admin rights , but the local IT manager was not able to bend the rules for anyone without getting in trouble if audited by division .
I am working at the same company at the corporate level after moving up from the local market level .
At corporate I have full admin rights to both a desktop and laptop for development .
I do not have admin ( root ) access to development and production servers though .
We have a sysadmin team dedicated to protecting our servers from ourselves .
Change request procedures ensure the environments are modified properly .
For PC support , We have a local IT team that reports to the division office as I sit a thousand of miles from actual HQ .
There have been times where admin rights ( root ) to servers would be nice , but we have 10 + developers relying on that server to be available for work/testing/etc .
So , I can understand why the servers must be managed by an SA team .
Change requests are simple and usually accomplished in a fair amount of time .
For times I absolutely need root access to try out new things , I just build Virtual Machines on my desktop and try before I place a CR for the dev servers .
Production CR 's are much more strict and those servers never have compiling tools to restrict local users from building binaries that could break things .</tokentext>
<sentencetext>At my last position I was at a local market level.
The local market had its own IT team with security policies given to them by a division team.
Division got its policies from corporate.
Sometimes things were altered to suit the divison or local market, too.
When working there, I had full admin rights to production servers, but not to the PC from which I worked.
This was stressful as I was forced to develop in the production environment.
It was also ironic that I had admin rights to these servers but not my PC.
It was because IT did not have the training or time to admin the servers (SQL and SharePoint).
I did my best to have the local IT team install software after software to enable development from my PC as best as possible.
After about 9 months on the job, I obtained a development server that I could work from via remote desktop.
By then, I had already developed processes to develop from the production server.
Also, the development box was SLOW and annoying to use (an old Pentium III box...).
This all seems a bit backwards and it took some adjustment, but it worked.
I became a hero for being able to manage these servers as well as develop new tools for the local market.
I got along very well with the IT department and they were very competent and helpful which made working with them easier.
I would have appreciated local admin rights, but the local IT manager was not able to bend the rules for anyone without getting in trouble if audited by division.
I am working at the same company at the corporate level after moving up from the local market level.
At corporate I have full admin rights to both a desktop and laptop for development.
I do not have admin (root) access to development and production servers though.
We have a sysadmin team dedicated to protecting our servers from ourselves.
Change request procedures ensure the environments are modified properly.
For PC support, We have a local IT team that reports to the division office as I sit a thousand of miles from actual HQ.
There have been times where admin rights (root) to servers would be nice, but we have 10+ developers relying on that server to be available for work/testing/etc.
So, I can understand why the servers must be managed by an SA team.
Change requests are simple and usually accomplished in a fair amount of time.
For times I absolutely need root access to try out new things, I just build Virtual Machines on my desktop and try before I place a CR for the dev servers.
Production CR's are much more strict and those servers never have compiling tools to restrict local users from building binaries that could break things.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608774</id>
	<title>My company allows this.</title>
	<author>gregarican</author>
	<datestamp>1262291400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Developers actually help administer our servers and our network hardware. So far it's been a good experience, even with them administering our firewall/router. I have nothing but g....<b>ATH++ NO CARRIER</b></p></htmltext>
<tokenext>Developers actually help administer our servers and our network hardware .
So far it 's been a good experience , even with them administering our firewall/router .
I have nothing but g....ATH + + NO CARRIER</tokentext>
<sentencetext>Developers actually help administer our servers and our network hardware.
So far it's been a good experience, even with them administering our firewall/router.
I have nothing but g....ATH++ NO CARRIER</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607176</id>
	<title>Development machines are not mission critical</title>
	<author>Anonymous</author>
	<datestamp>1262284140000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>You should treat your development machines as "hostile" and put them on their own network.</p><p>You should do this regardless of security issues because developers can also do stuff like saturate your network.</p><p>And what a great administrator, bashing people over the head because of your own limitations.</p><p>I'm glad you don't administer my development systems.</p></htmltext>
<tokenext>You should treat your development machines as " hostile " and put them on their own network.You should do this regardless of security issues because developers can also do stuff like saturate your network.And what a great administrator , bashing people over the head because of your own limitations.I 'm glad you do n't administer my development systems .</tokentext>
<sentencetext>You should treat your development machines as "hostile" and put them on their own network.You should do this regardless of security issues because developers can also do stuff like saturate your network.And what a great administrator, bashing people over the head because of your own limitations.I'm glad you don't administer my development systems.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607680</id>
	<title>Re:You damn well should</title>
	<author>Nazlfrag</author>
	<datestamp>1262286060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Any automobile mechanic who can't fix their car, plumber who can't fix their toilet, the aerospace or mobile phone engineer that can't fix their plane or phone is incompetent by the fact that they are claiming competence in that field.</p><p>If system administration isn't second nature to your developer, he is incompetent.</p></htmltext>
<tokenext>Any automobile mechanic who ca n't fix their car , plumber who ca n't fix their toilet , the aerospace or mobile phone engineer that ca n't fix their plane or phone is incompetent by the fact that they are claiming competence in that field.If system administration is n't second nature to your developer , he is incompetent .</tokentext>
<sentencetext>Any automobile mechanic who can't fix their car, plumber who can't fix their toilet, the aerospace or mobile phone engineer that can't fix their plane or phone is incompetent by the fact that they are claiming competence in that field.If system administration isn't second nature to your developer, he is incompetent.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606844</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612656</id>
	<title>Depends on OS and what you are developing</title>
	<author>herbierobinson</author>
	<datestamp>1262286600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My group maintains and enhances an operating system.  Obviously, we need full access on the machines we debug on.  We also have separate "production" machines used for builds and source control where developers don't default to having admin privileges (and admin privs are generally reserved for the people less likely to break things).  We used to give all the new developers admin privs from day 1, but that almost led to a few disasters (new people with full admin privs on an unfamiliar OS is not a good idea).</p><p>We generally try to let the admins take care of the production systems and only take over when they aren't around (it's only two people).  And we let them know what we fixed because we appreciate the fact that they are normally dealing with it for us...</p><p>OTOH, one doesn't need any sort of special access to develop simple applications on decent operating systems like Unix or Max OS.  One only needs special access when one starts installing shared libraries, doing kernel work, or setting up shared source control systems (although, it's generally not a good idea to let all the developers have uncontrolled access to the source control system, either).</p></htmltext>
<tokenext>My group maintains and enhances an operating system .
Obviously , we need full access on the machines we debug on .
We also have separate " production " machines used for builds and source control where developers do n't default to having admin privileges ( and admin privs are generally reserved for the people less likely to break things ) .
We used to give all the new developers admin privs from day 1 , but that almost led to a few disasters ( new people with full admin privs on an unfamiliar OS is not a good idea ) .We generally try to let the admins take care of the production systems and only take over when they are n't around ( it 's only two people ) .
And we let them know what we fixed because we appreciate the fact that they are normally dealing with it for us...OTOH , one does n't need any sort of special access to develop simple applications on decent operating systems like Unix or Max OS .
One only needs special access when one starts installing shared libraries , doing kernel work , or setting up shared source control systems ( although , it 's generally not a good idea to let all the developers have uncontrolled access to the source control system , either ) .</tokentext>
<sentencetext>My group maintains and enhances an operating system.
Obviously, we need full access on the machines we debug on.
We also have separate "production" machines used for builds and source control where developers don't default to having admin privileges (and admin privs are generally reserved for the people less likely to break things).
We used to give all the new developers admin privs from day 1, but that almost led to a few disasters (new people with full admin privs on an unfamiliar OS is not a good idea).We generally try to let the admins take care of the production systems and only take over when they aren't around (it's only two people).
And we let them know what we fixed because we appreciate the fact that they are normally dealing with it for us...OTOH, one doesn't need any sort of special access to develop simple applications on decent operating systems like Unix or Max OS.
One only needs special access when one starts installing shared libraries, doing kernel work, or setting up shared source control systems (although, it's generally not a good idea to let all the developers have uncontrolled access to the source control system, either).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607844</id>
	<title>Re:You damn well should</title>
	<author>Anonymous</author>
	<datestamp>1262286660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You're talking about users, not developers. I would expect an engineer developing a new transmission system to understand how an automobile works, yes.</p></htmltext>
<tokenext>You 're talking about users , not developers .
I would expect an engineer developing a new transmission system to understand how an automobile works , yes .</tokentext>
<sentencetext>You're talking about users, not developers.
I would expect an engineer developing a new transmission system to understand how an automobile works, yes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606844</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608922</id>
	<title>chntpw</title>
	<author>karlandtanya</author>
	<datestamp>1262292120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yes, we do.<br>And, yes, I've used it, at the Client's facility to get into the admin account of lab computers--with the Client's full knowledge and permission.</p><p>We need full access to our workpiece in order to work on it.  IT officially doesn't support this, but the IT guys that support the labs know what we do, and what we need in order to do it.</p><p>At least that's how it was when I was there.  I usually do a couple years on and a couple years off for that particular client.  They may be totally locked down and outsourced to India/China by now.</p></htmltext>
<tokenext>Yes , we do.And , yes , I 've used it , at the Client 's facility to get into the admin account of lab computers--with the Client 's full knowledge and permission.We need full access to our workpiece in order to work on it .
IT officially does n't support this , but the IT guys that support the labs know what we do , and what we need in order to do it.At least that 's how it was when I was there .
I usually do a couple years on and a couple years off for that particular client .
They may be totally locked down and outsourced to India/China by now .</tokentext>
<sentencetext>Yes, we do.And, yes, I've used it, at the Client's facility to get into the admin account of lab computers--with the Client's full knowledge and permission.We need full access to our workpiece in order to work on it.
IT officially doesn't support this, but the IT guys that support the labs know what we do, and what we need in order to do it.At least that's how it was when I was there.
I usually do a couple years on and a couple years off for that particular client.
They may be totally locked down and outsourced to India/China by now.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612160</id>
	<title>Why Yes</title>
	<author>niftymitch</author>
	<datestamp>1262277300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>For developers working on programs drivers and tools that require it for testing yes.  It is possible that some have no control over their desktop by the second system for testing requires full access.

Try and install a program on windows without administrative rights...   Can't do it.</htmltext>
<tokenext>For developers working on programs drivers and tools that require it for testing yes .
It is possible that some have no control over their desktop by the second system for testing requires full access .
Try and install a program on windows without administrative rights... Ca n't do it .</tokentext>
<sentencetext>For developers working on programs drivers and tools that require it for testing yes.
It is possible that some have no control over their desktop by the second system for testing requires full access.
Try and install a program on windows without administrative rights...   Can't do it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608972</id>
	<title>All your base are belong to developers anyway...</title>
	<author>MonkeyBot</author>
	<datestamp>1262292300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If you have decent developers and they have physical access to their machines (particularly laptops that they can take away from scrutinizing eyes), then they likely already have local admin rights in some form or fashion, whether you want them to or not.

It's an asinine waste of resources to try and use an IT group that is usually less competent than the developers to police those developers' local admin rights when they have physical access to their machines.</htmltext>
<tokenext>If you have decent developers and they have physical access to their machines ( particularly laptops that they can take away from scrutinizing eyes ) , then they likely already have local admin rights in some form or fashion , whether you want them to or not .
It 's an asinine waste of resources to try and use an IT group that is usually less competent than the developers to police those developers ' local admin rights when they have physical access to their machines .</tokentext>
<sentencetext>If you have decent developers and they have physical access to their machines (particularly laptops that they can take away from scrutinizing eyes), then they likely already have local admin rights in some form or fashion, whether you want them to or not.
It's an asinine waste of resources to try and use an IT group that is usually less competent than the developers to police those developers' local admin rights when they have physical access to their machines.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607202</id>
	<title>The day I lose Local Admin Rights...</title>
	<author>denobug</author>
	<datestamp>1262284260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>My group does use quite a few non-standard issued software that, for the most part, the rest of the company don't use.  Incidentally we also support field techs that are in the middle of nowhere, far, far away from us on those software as well.  Based on the control systems our company has acquired during acquisition or what has already in placed, we have numerous systems varied by vendors and even seperate generations of systems by the same vendors.  It is actually a great deal of pain to just "upgrade" the system to one platform since our upgrades does involved physical change out and that means lost production time that can be quite costly in a 24/7 environment.  We manage and support those self packages (to ourselves or other techs that may have to use it from time to time to support us).
<br> <br>
There had been talk in the past to remove the local admin rights from our laptop in the past (for standard IT policy for all desktops and laptops).  Being the fact that we do go off-line during our normal work assignment it is near impossible to do any work, especially having to install/support others and not having local admin right to add/remote software packages.  Some of our software packages, in fact, requires a local admin account in order to function.
<br> <br>
The day we lose local Admin privledge is the day we pretty much come to a complete stop. We had this discussion twice in the last few years.  It simply comes down to that.  We will be responsible for our machines (all of us knows at least how to keep our machine working, hardware and software) and Security leaves us along with the local admin rights.</htmltext>
<tokenext>My group does use quite a few non-standard issued software that , for the most part , the rest of the company do n't use .
Incidentally we also support field techs that are in the middle of nowhere , far , far away from us on those software as well .
Based on the control systems our company has acquired during acquisition or what has already in placed , we have numerous systems varied by vendors and even seperate generations of systems by the same vendors .
It is actually a great deal of pain to just " upgrade " the system to one platform since our upgrades does involved physical change out and that means lost production time that can be quite costly in a 24/7 environment .
We manage and support those self packages ( to ourselves or other techs that may have to use it from time to time to support us ) .
There had been talk in the past to remove the local admin rights from our laptop in the past ( for standard IT policy for all desktops and laptops ) .
Being the fact that we do go off-line during our normal work assignment it is near impossible to do any work , especially having to install/support others and not having local admin right to add/remote software packages .
Some of our software packages , in fact , requires a local admin account in order to function .
The day we lose local Admin privledge is the day we pretty much come to a complete stop .
We had this discussion twice in the last few years .
It simply comes down to that .
We will be responsible for our machines ( all of us knows at least how to keep our machine working , hardware and software ) and Security leaves us along with the local admin rights .</tokentext>
<sentencetext>My group does use quite a few non-standard issued software that, for the most part, the rest of the company don't use.
Incidentally we also support field techs that are in the middle of nowhere, far, far away from us on those software as well.
Based on the control systems our company has acquired during acquisition or what has already in placed, we have numerous systems varied by vendors and even seperate generations of systems by the same vendors.
It is actually a great deal of pain to just "upgrade" the system to one platform since our upgrades does involved physical change out and that means lost production time that can be quite costly in a 24/7 environment.
We manage and support those self packages (to ourselves or other techs that may have to use it from time to time to support us).
There had been talk in the past to remove the local admin rights from our laptop in the past (for standard IT policy for all desktops and laptops).
Being the fact that we do go off-line during our normal work assignment it is near impossible to do any work, especially having to install/support others and not having local admin right to add/remote software packages.
Some of our software packages, in fact, requires a local admin account in order to function.
The day we lose local Admin privledge is the day we pretty much come to a complete stop.
We had this discussion twice in the last few years.
It simply comes down to that.
We will be responsible for our machines (all of us knows at least how to keep our machine working, hardware and software) and Security leaves us along with the local admin rights.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607134</id>
	<title>Yes, local admin but...</title>
	<author>sbeckstead</author>
	<datestamp>1262283900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Local admin on the machine I use every day but restricted rights to the domain.  Also the on the term servers we have restricted installation rights to allow deployment of our apps.
Pretty standard as far as I can tell the last 3 or 4 companies I've worked for worked this way.</htmltext>
<tokenext>Local admin on the machine I use every day but restricted rights to the domain .
Also the on the term servers we have restricted installation rights to allow deployment of our apps .
Pretty standard as far as I can tell the last 3 or 4 companies I 've worked for worked this way .</tokentext>
<sentencetext>Local admin on the machine I use every day but restricted rights to the domain.
Also the on the term servers we have restricted installation rights to allow deployment of our apps.
Pretty standard as far as I can tell the last 3 or 4 companies I've worked for worked this way.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608208</id>
	<title>Re:Information Security 101</title>
	<author>Anonymous</author>
	<datestamp>1262288340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Great in theory.  Ever really try this in Windows?  I think Microsoft solved this in Vista though. I think it's called UAC.</p></htmltext>
<tokenext>Great in theory .
Ever really try this in Windows ?
I think Microsoft solved this in Vista though .
I think it 's called UAC .</tokentext>
<sentencetext>Great in theory.
Ever really try this in Windows?
I think Microsoft solved this in Vista though.
I think it's called UAC.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607004</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607004</id>
	<title>Information Security 101</title>
	<author>Reason58</author>
	<datestamp>1262283480000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>No one should be running an administrator-level account for day-to-day work. It's a huge security risk. If there are tasks that absolutely require administrative rights to do with no workaround (rarely) then you create an administrator account that they log in to for that task only, then log back on to their normal account.</htmltext>
<tokenext>No one should be running an administrator-level account for day-to-day work .
It 's a huge security risk .
If there are tasks that absolutely require administrative rights to do with no workaround ( rarely ) then you create an administrator account that they log in to for that task only , then log back on to their normal account .</tokentext>
<sentencetext>No one should be running an administrator-level account for day-to-day work.
It's a huge security risk.
If there are tasks that absolutely require administrative rights to do with no workaround (rarely) then you create an administrator account that they log in to for that task only, then log back on to their normal account.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608280</id>
	<title>Re:Yes</title>
	<author>Saint Stephen</author>
	<datestamp>1262288700000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>You just need to be a member of the Debugger Users group, and VStudio works fine without being Admin.</p><p>It's not impossible to not be an administrator.  I install all my services as an ordinary user and make sure things work OK.</p><p>It's a lot more comfortable to just be the administrator, sure, no question - but it's not impossible.</p></htmltext>
<tokenext>You just need to be a member of the Debugger Users group , and VStudio works fine without being Admin.It 's not impossible to not be an administrator .
I install all my services as an ordinary user and make sure things work OK.It 's a lot more comfortable to just be the administrator , sure , no question - but it 's not impossible .</tokentext>
<sentencetext>You just need to be a member of the Debugger Users group, and VStudio works fine without being Admin.It's not impossible to not be an administrator.
I install all my services as an ordinary user and make sure things work OK.It's a lot more comfortable to just be the administrator, sure, no question - but it's not impossible.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608166</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768</id>
	<title>Virtualization is your Friend</title>
	<author>wwwillem</author>
	<datestamp>1262282640000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p>In modern times, I would give them no admin rights on the box itself, but you could provide virtual machines for them on which they can do whatever they want. The argument that they need to do things that "really, really"<nobr> <wbr></nobr>:-) require access to the bare metal, doesn't hold anymore, because the applications they are building will anyway need to be able to run in a virtualized environment.</p><p>I've done many audits and project plans on this topic in the past, and the issue is always that developers are split personalities: on the one hand they are standard corporate citizens that need email, calendar and word, which must be rock solid and therefore IT controlled, on the other hand they do their development work that requires freedom over their box. In the past the best solution was always to give them two PCs (or a thin client for the standard desktop work), but today I would solve this all through virtual machines.<br>
&nbsp;</p></htmltext>
<tokenext>In modern times , I would give them no admin rights on the box itself , but you could provide virtual machines for them on which they can do whatever they want .
The argument that they need to do things that " really , really " : - ) require access to the bare metal , does n't hold anymore , because the applications they are building will anyway need to be able to run in a virtualized environment.I 've done many audits and project plans on this topic in the past , and the issue is always that developers are split personalities : on the one hand they are standard corporate citizens that need email , calendar and word , which must be rock solid and therefore IT controlled , on the other hand they do their development work that requires freedom over their box .
In the past the best solution was always to give them two PCs ( or a thin client for the standard desktop work ) , but today I would solve this all through virtual machines .
 </tokentext>
<sentencetext>In modern times, I would give them no admin rights on the box itself, but you could provide virtual machines for them on which they can do whatever they want.
The argument that they need to do things that "really, really" :-) require access to the bare metal, doesn't hold anymore, because the applications they are building will anyway need to be able to run in a virtualized environment.I've done many audits and project plans on this topic in the past, and the issue is always that developers are split personalities: on the one hand they are standard corporate citizens that need email, calendar and word, which must be rock solid and therefore IT controlled, on the other hand they do their development work that requires freedom over their box.
In the past the best solution was always to give them two PCs (or a thin client for the standard desktop work), but today I would solve this all through virtual machines.
 </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608790</id>
	<title>No admin rights and for good reason</title>
	<author>locketine</author>
	<datestamp>1262291460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Two of the last three companies I've worked for as a software developer only gave us power user rights on our windowsXP machines. I was doing embedded software development and testing at both of those companies and it didn't cause any problems not having admin rights on my local machine. I could see where in some cases it would be impossible to function as a dev without admin rights but in most cases it can be gotten around by hiring smart IT support technicians who know how to install complex software and hardware and developers who can communicate their needs to the support staff. </p><p>To support the IT guys I'll give a recent example of how I effed up my Vista machine doing something that shouldn't have caused any problems. Vista kept bugging me about enabling automatic updates so I got annoyed and told it to download and install all the latest updates (no service packs). Well, that caused every single proprietary piece of software on my machine to crash on startup. It took the IT tech about 4 hours to figure out what happened and correct the situation and me another 3 hours to put my machine back to where I wanted it. </p><p>The moral of the story is that you have no clue what could mess up your computer and IT does. They've dealt with way more computer problems than you could ever in your entire life which is why they should be the ones installing drivers/software on your computer. Plus, you shouldn't be wasting your time developing your computer because you were hired to develop software.</p></htmltext>
<tokenext>Two of the last three companies I 've worked for as a software developer only gave us power user rights on our windowsXP machines .
I was doing embedded software development and testing at both of those companies and it did n't cause any problems not having admin rights on my local machine .
I could see where in some cases it would be impossible to function as a dev without admin rights but in most cases it can be gotten around by hiring smart IT support technicians who know how to install complex software and hardware and developers who can communicate their needs to the support staff .
To support the IT guys I 'll give a recent example of how I effed up my Vista machine doing something that should n't have caused any problems .
Vista kept bugging me about enabling automatic updates so I got annoyed and told it to download and install all the latest updates ( no service packs ) .
Well , that caused every single proprietary piece of software on my machine to crash on startup .
It took the IT tech about 4 hours to figure out what happened and correct the situation and me another 3 hours to put my machine back to where I wanted it .
The moral of the story is that you have no clue what could mess up your computer and IT does .
They 've dealt with way more computer problems than you could ever in your entire life which is why they should be the ones installing drivers/software on your computer .
Plus , you should n't be wasting your time developing your computer because you were hired to develop software .</tokentext>
<sentencetext>Two of the last three companies I've worked for as a software developer only gave us power user rights on our windowsXP machines.
I was doing embedded software development and testing at both of those companies and it didn't cause any problems not having admin rights on my local machine.
I could see where in some cases it would be impossible to function as a dev without admin rights but in most cases it can be gotten around by hiring smart IT support technicians who know how to install complex software and hardware and developers who can communicate their needs to the support staff.
To support the IT guys I'll give a recent example of how I effed up my Vista machine doing something that shouldn't have caused any problems.
Vista kept bugging me about enabling automatic updates so I got annoyed and told it to download and install all the latest updates (no service packs).
Well, that caused every single proprietary piece of software on my machine to crash on startup.
It took the IT tech about 4 hours to figure out what happened and correct the situation and me another 3 hours to put my machine back to where I wanted it.
The moral of the story is that you have no clue what could mess up your computer and IT does.
They've dealt with way more computer problems than you could ever in your entire life which is why they should be the ones installing drivers/software on your computer.
Plus, you shouldn't be wasting your time developing your computer because you were hired to develop software.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608266</id>
	<title>Re:Yes</title>
	<author>foxcob</author>
	<datestamp>1262288580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I have to say I am one of those morons who uses my admin privileges to turn off virus scanning.  On a development machine where I am constantly compiling the virus scanner is devastating to performance.  This may be due to the fact that we use Symantec, but with the virus scanner checking every file being read and written, or checking the compiler everytime it is invoked from the build script is unacceptable.  I know I can setup special rules in most scanners for this, but I have still noticed a terrible loss in performance on the rest of the machine.  On the other hand, I haven't had a virus in years.  Mostly because I am a knowledgable  user who doesn't open / install just anything I see.  I do occasionally do whole system scans, and if I'm unsure about something I get, I scan it explicitly before opening.

But again, I am a moron who used my admin privileges to save lots of time and disable virus scanning.</htmltext>
<tokenext>I have to say I am one of those morons who uses my admin privileges to turn off virus scanning .
On a development machine where I am constantly compiling the virus scanner is devastating to performance .
This may be due to the fact that we use Symantec , but with the virus scanner checking every file being read and written , or checking the compiler everytime it is invoked from the build script is unacceptable .
I know I can setup special rules in most scanners for this , but I have still noticed a terrible loss in performance on the rest of the machine .
On the other hand , I have n't had a virus in years .
Mostly because I am a knowledgable user who does n't open / install just anything I see .
I do occasionally do whole system scans , and if I 'm unsure about something I get , I scan it explicitly before opening .
But again , I am a moron who used my admin privileges to save lots of time and disable virus scanning .</tokentext>
<sentencetext>I have to say I am one of those morons who uses my admin privileges to turn off virus scanning.
On a development machine where I am constantly compiling the virus scanner is devastating to performance.
This may be due to the fact that we use Symantec, but with the virus scanner checking every file being read and written, or checking the compiler everytime it is invoked from the build script is unacceptable.
I know I can setup special rules in most scanners for this, but I have still noticed a terrible loss in performance on the rest of the machine.
On the other hand, I haven't had a virus in years.
Mostly because I am a knowledgable  user who doesn't open / install just anything I see.
I do occasionally do whole system scans, and if I'm unsure about something I get, I scan it explicitly before opening.
But again, I am a moron who used my admin privileges to save lots of time and disable virus scanning.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606590</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606750</id>
	<title>Re:What?</title>
	<author>Anonymous</author>
	<datestamp>1262282580000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext>As an admin, I've supported both types of environment.  Depending on what the development project is, sometimes it's just better to allow the developers to have full admin rights in order to add compilers and other development tools required for project completion.  The developers were responsible for all O/S issues related to installation of non-standard development tools, but would rely on the sysadmins for hardware support, as the service contracts were part of the corporate global service contracts.

There's no easy answer on this one, and it pretty much depends on company policy around allowing admin access to non-admins.  Personally, as an admin, I prefer to maintain control of what is installed on the systems under my umbrella, as it makes patching and upgrading easier when I know what's already there, and what dependencies are required.</htmltext>
<tokenext>As an admin , I 've supported both types of environment .
Depending on what the development project is , sometimes it 's just better to allow the developers to have full admin rights in order to add compilers and other development tools required for project completion .
The developers were responsible for all O/S issues related to installation of non-standard development tools , but would rely on the sysadmins for hardware support , as the service contracts were part of the corporate global service contracts .
There 's no easy answer on this one , and it pretty much depends on company policy around allowing admin access to non-admins .
Personally , as an admin , I prefer to maintain control of what is installed on the systems under my umbrella , as it makes patching and upgrading easier when I know what 's already there , and what dependencies are required .</tokentext>
<sentencetext>As an admin, I've supported both types of environment.
Depending on what the development project is, sometimes it's just better to allow the developers to have full admin rights in order to add compilers and other development tools required for project completion.
The developers were responsible for all O/S issues related to installation of non-standard development tools, but would rely on the sysadmins for hardware support, as the service contracts were part of the corporate global service contracts.
There's no easy answer on this one, and it pretty much depends on company policy around allowing admin access to non-admins.
Personally, as an admin, I prefer to maintain control of what is installed on the systems under my umbrella, as it makes patching and upgrading easier when I know what's already there, and what dependencies are required.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606842</id>
	<title>"Standardization"</title>
	<author>Anonymous</author>
	<datestamp>1262282940000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>Organizations that treat developers like standard "business" users are going to get systems developed as well and as fast as those created by standard "business" users. A developer needs at least elevated rights on a workstation.</htmltext>
<tokenext>Organizations that treat developers like standard " business " users are going to get systems developed as well and as fast as those created by standard " business " users .
A developer needs at least elevated rights on a workstation .</tokentext>
<sentencetext>Organizations that treat developers like standard "business" users are going to get systems developed as well and as fast as those created by standard "business" users.
A developer needs at least elevated rights on a workstation.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613890</id>
	<title>Always</title>
	<author>AigariusDebian</author>
	<datestamp>1230822900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yep, all our developers just delete the 'standard workstation', install Ubuntu for actual work and then install a stripped down Windows version in VirtualBox for all those pesky Windows-only reporting tools and IE-only corporate websites. The local IT staff is pleased - they don't have to support us beyond the domain password reset once every 3 months that we have them ask to do, because noone of us has a machine in the actual domain.</p></htmltext>
<tokenext>Yep , all our developers just delete the 'standard workstation ' , install Ubuntu for actual work and then install a stripped down Windows version in VirtualBox for all those pesky Windows-only reporting tools and IE-only corporate websites .
The local IT staff is pleased - they do n't have to support us beyond the domain password reset once every 3 months that we have them ask to do , because noone of us has a machine in the actual domain .</tokentext>
<sentencetext>Yep, all our developers just delete the 'standard workstation', install Ubuntu for actual work and then install a stripped down Windows version in VirtualBox for all those pesky Windows-only reporting tools and IE-only corporate websites.
The local IT staff is pleased - they don't have to support us beyond the domain password reset once every 3 months that we have them ask to do, because noone of us has a machine in the actual domain.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609046</id>
	<title>My favorite security policy</title>
	<author>seebs</author>
	<datestamp>1262292720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>1.  Developers shall not have root access to shared machines.<br>2.  Limited root access is provided for specific functions.<br>3.  Specifically, "sudo tar" works.</p><p>I am pretty sure there is some kind of subtle flaw here.</p></htmltext>
<tokenext>1 .
Developers shall not have root access to shared machines.2 .
Limited root access is provided for specific functions.3 .
Specifically , " sudo tar " works.I am pretty sure there is some kind of subtle flaw here .</tokentext>
<sentencetext>1.
Developers shall not have root access to shared machines.2.
Limited root access is provided for specific functions.3.
Specifically, "sudo tar" works.I am pretty sure there is some kind of subtle flaw here.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606532</id>
	<title>Multiple machines, KVM.</title>
	<author>Anonymous</author>
	<datestamp>1262281860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>The way ive always had it set up even in troubleshooting environments is a corporate workstation , and a test-bed system. The corporate system was hooked up like ever other drone box out there, harsh lockdowns and limited permissions, set up with email and the slew of corporate software, then KVM switched to a test box, that was basically free reign - including changing hardware configs, the only regulation was asking the IT guy for a specific make of NIC, or a re-imaged HDD to swap out.</htmltext>
<tokenext>The way ive always had it set up even in troubleshooting environments is a corporate workstation , and a test-bed system .
The corporate system was hooked up like ever other drone box out there , harsh lockdowns and limited permissions , set up with email and the slew of corporate software , then KVM switched to a test box , that was basically free reign - including changing hardware configs , the only regulation was asking the IT guy for a specific make of NIC , or a re-imaged HDD to swap out .</tokentext>
<sentencetext>The way ive always had it set up even in troubleshooting environments is a corporate workstation , and a test-bed system.
The corporate system was hooked up like ever other drone box out there, harsh lockdowns and limited permissions, set up with email and the slew of corporate software, then KVM switched to a test box, that was basically free reign - including changing hardware configs, the only regulation was asking the IT guy for a specific make of NIC, or a re-imaged HDD to swap out.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606558</id>
	<title>yes</title>
	<author>PixetaledPikachu</author>
	<datestamp>1262281980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Mine yes. And since the dev environment resides physically on the same network of our production (separated by firewall), our server admins also have local admins to those machines. Software provisions are provided by the server admins, and we strictly monitor installed application on those servers by using software asset management tools. Testing is done not on the dev environment, but on another batch of servers specifically used for UATs, Developers has no local admin right on UAT environment.</htmltext>
<tokenext>Mine yes .
And since the dev environment resides physically on the same network of our production ( separated by firewall ) , our server admins also have local admins to those machines .
Software provisions are provided by the server admins , and we strictly monitor installed application on those servers by using software asset management tools .
Testing is done not on the dev environment , but on another batch of servers specifically used for UATs , Developers has no local admin right on UAT environment .</tokentext>
<sentencetext>Mine yes.
And since the dev environment resides physically on the same network of our production (separated by firewall), our server admins also have local admins to those machines.
Software provisions are provided by the server admins, and we strictly monitor installed application on those servers by using software asset management tools.
Testing is done not on the dev environment, but on another batch of servers specifically used for UATs, Developers has no local admin right on UAT environment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608166</id>
	<title>Re:Yes</title>
	<author>colenski</author>
	<datestamp>1262288100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yes. A lot of development environments *cough* Visual Studio 2008 *cough* assume local admin rights. You also have to be able to install stuff to get things done. If you have to submit a ticket just to register a DLL or what have you, your time is wasted. <br> <br> It's dumb I think to just say, Well, install a VM and make it unpriveleged because 90\% of apps you develop access the LAN in some fashion, and an unencumbered VM not subject to group policy is basically the same as having a development machine with local admin rights, except now the VM represents rogue machine from the LAN perspective. So why not just give the developer local admin and reduce your LAN management headaches?</htmltext>
<tokenext>Yes .
A lot of development environments * cough * Visual Studio 2008 * cough * assume local admin rights .
You also have to be able to install stuff to get things done .
If you have to submit a ticket just to register a DLL or what have you , your time is wasted .
It 's dumb I think to just say , Well , install a VM and make it unpriveleged because 90 \ % of apps you develop access the LAN in some fashion , and an unencumbered VM not subject to group policy is basically the same as having a development machine with local admin rights , except now the VM represents rogue machine from the LAN perspective .
So why not just give the developer local admin and reduce your LAN management headaches ?</tokentext>
<sentencetext>Yes.
A lot of development environments *cough* Visual Studio 2008 *cough* assume local admin rights.
You also have to be able to install stuff to get things done.
If you have to submit a ticket just to register a DLL or what have you, your time is wasted.
It's dumb I think to just say, Well, install a VM and make it unpriveleged because 90\% of apps you develop access the LAN in some fashion, and an unencumbered VM not subject to group policy is basically the same as having a development machine with local admin rights, except now the VM represents rogue machine from the LAN perspective.
So why not just give the developer local admin and reduce your LAN management headaches?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30614678</id>
	<title>Root</title>
	<author>Anonymous</author>
	<datestamp>1230832140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The first thing i did when i joined a new company, is request that format my windows machine into a linux based one.<br>The request was granted to me because i was a developer, if someone else had asked it would have been declined.</p><p>Since it was a small company i offered to format it myself, Management asked no questions and allowed it.<br>So i have root access to my machine.</p></htmltext>
<tokenext>The first thing i did when i joined a new company , is request that format my windows machine into a linux based one.The request was granted to me because i was a developer , if someone else had asked it would have been declined.Since it was a small company i offered to format it myself , Management asked no questions and allowed it.So i have root access to my machine .</tokentext>
<sentencetext>The first thing i did when i joined a new company, is request that format my windows machine into a linux based one.The request was granted to me because i was a developer, if someone else had asked it would have been declined.Since it was a small company i offered to format it myself, Management asked no questions and allowed it.So i have root access to my machine.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30614548</id>
	<title>Re:You damn well should</title>
	<author>Cederic</author>
	<datestamp>1230830760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Development should be done using dedicated development systems that replicate the production environment. I have seen way to many problems and delays arise because the developer's setup on his personal laptops didn't exactly replicate the productions deployment environment.</p></div><p>Forgive me if I choose not to spend &pound;18m giving the developers systems that replicate the production environment. They can get by on around &pound;200k of kit and any good software engineer knows how to develop on one environment and deploy to another.</p><p>Shit, these days it's all automated with hooks for the necessary config settings.</p><p>Production is fucking expensive. Windows desktops are cheap. Software doesn't have unlimited budget.</p></div>
	</htmltext>
<tokenext>Development should be done using dedicated development systems that replicate the production environment .
I have seen way to many problems and delays arise because the developer 's setup on his personal laptops did n't exactly replicate the productions deployment environment.Forgive me if I choose not to spend   18m giving the developers systems that replicate the production environment .
They can get by on around   200k of kit and any good software engineer knows how to develop on one environment and deploy to another.Shit , these days it 's all automated with hooks for the necessary config settings.Production is fucking expensive .
Windows desktops are cheap .
Software does n't have unlimited budget .</tokentext>
<sentencetext>Development should be done using dedicated development systems that replicate the production environment.
I have seen way to many problems and delays arise because the developer's setup on his personal laptops didn't exactly replicate the productions deployment environment.Forgive me if I choose not to spend £18m giving the developers systems that replicate the production environment.
They can get by on around £200k of kit and any good software engineer knows how to develop on one environment and deploy to another.Shit, these days it's all automated with hooks for the necessary config settings.Production is fucking expensive.
Windows desktops are cheap.
Software doesn't have unlimited budget.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606632</id>
	<title>Yes</title>
	<author>mrian84</author>
	<datestamp>1262282220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I cannot imagine a developer that does not have Admin rights on his machine. Virtualization is a bit frustrating unless you have very powerful machines.</htmltext>
<tokenext>I can not imagine a developer that does not have Admin rights on his machine .
Virtualization is a bit frustrating unless you have very powerful machines .</tokentext>
<sentencetext>I cannot imagine a developer that does not have Admin rights on his machine.
Virtualization is a bit frustrating unless you have very powerful machines.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606916</id>
	<title>Re:Under no circumstances</title>
	<author>tepples</author>
	<datestamp>1262283120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Under no circumstances should any developer in any organization today have corporate production administrative rights.</p></div><p>Other than perhaps a <a href="http://en.wikipedia.org/wiki/Small\_business" title="wikipedia.org">sufficiently small organization</a> [wikipedia.org], right?</p></div>
	</htmltext>
<tokenext>Under no circumstances should any developer in any organization today have corporate production administrative rights.Other than perhaps a sufficiently small organization [ wikipedia.org ] , right ?</tokentext>
<sentencetext>Under no circumstances should any developer in any organization today have corporate production administrative rights.Other than perhaps a sufficiently small organization [wikipedia.org], right?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606710</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612054</id>
	<title>Re:Virtualization is your Friend</title>
	<author>zzyzyx</author>
	<datestamp>1262275440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>The argument that they need to do things that "really, really"<nobr> <wbr></nobr>:-) require access to the bare metal, doesn't hold anymore, because the applications they are building will anyway need to be able to run in a virtualized environment.</p></div><p>Why do so many admins seem to think that you don't need more tools to develop an app than to run it? You may not need that screwdriver to run your car, but you really do need it to assemble it.</p></div>
	</htmltext>
<tokenext>The argument that they need to do things that " really , really " : - ) require access to the bare metal , does n't hold anymore , because the applications they are building will anyway need to be able to run in a virtualized environment.Why do so many admins seem to think that you do n't need more tools to develop an app than to run it ?
You may not need that screwdriver to run your car , but you really do need it to assemble it .</tokentext>
<sentencetext>The argument that they need to do things that "really, really" :-) require access to the bare metal, doesn't hold anymore, because the applications they are building will anyway need to be able to run in a virtualized environment.Why do so many admins seem to think that you don't need more tools to develop an app than to run it?
You may not need that screwdriver to run your car, but you really do need it to assemble it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606964</id>
	<title>Curiouser and curiouser</title>
	<author>Kisama</author>
	<datestamp>1262283300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I work for a state agency, and surprisingly *everyone* here has local admin.  This is a stark contrast from when I was enlisted, as not even Help Desk or Server Room had admin rights anymore as they had consolidated everything upchannel.</p></htmltext>
<tokenext>I work for a state agency , and surprisingly * everyone * here has local admin .
This is a stark contrast from when I was enlisted , as not even Help Desk or Server Room had admin rights anymore as they had consolidated everything upchannel .</tokentext>
<sentencetext>I work for a state agency, and surprisingly *everyone* here has local admin.
This is a stark contrast from when I was enlisted, as not even Help Desk or Server Room had admin rights anymore as they had consolidated everything upchannel.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610442</id>
	<title>Intelligence test</title>
	<author>Anonymous</author>
	<datestamp>1262258040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If your developers can't figure out how to get local admin rights on a machine they have unlimited physical access too, then perhaps they shouldn't have those rights. They don't need network admin rights, but even at Oracle I was able to capture the network admin password just by writing a program to monitor remote access by the sysadmins.</p></htmltext>
<tokenext>If your developers ca n't figure out how to get local admin rights on a machine they have unlimited physical access too , then perhaps they should n't have those rights .
They do n't need network admin rights , but even at Oracle I was able to capture the network admin password just by writing a program to monitor remote access by the sysadmins .</tokentext>
<sentencetext>If your developers can't figure out how to get local admin rights on a machine they have unlimited physical access too, then perhaps they shouldn't have those rights.
They don't need network admin rights, but even at Oracle I was able to capture the network admin password just by writing a program to monitor remote access by the sysadmins.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606486</id>
	<title>Yes, because I'm not a masochist</title>
	<author>Anonymous</author>
	<datestamp>1262281740000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>In the Windows world you can override other things using GPOs, but it's too much of a pain from the admin side (I've found, as have my coworkers over the years) to try and lock down developer machines by removing local admin rights.  I've got better things to do than schedule up a time to install things via an account with local admin rights every time something new comes along for them.
</p><p>The flip side is that they have greater responsibility for maintaining their desktop/laptop systems.  If it gets screwed up enough, they know they're getting the thing re-imaged with the company standard desktop image and will need to reinstall their tools they use for their personal dev environment.
</p><p>Works out pretty well, aside form the devs that install absolutely everything they come across, "Oooh that looks cool! [installs][never uses again]".  They can be a pain.</p></htmltext>
<tokenext>In the Windows world you can override other things using GPOs , but it 's too much of a pain from the admin side ( I 've found , as have my coworkers over the years ) to try and lock down developer machines by removing local admin rights .
I 've got better things to do than schedule up a time to install things via an account with local admin rights every time something new comes along for them .
The flip side is that they have greater responsibility for maintaining their desktop/laptop systems .
If it gets screwed up enough , they know they 're getting the thing re-imaged with the company standard desktop image and will need to reinstall their tools they use for their personal dev environment .
Works out pretty well , aside form the devs that install absolutely everything they come across , " Oooh that looks cool !
[ installs ] [ never uses again ] " .
They can be a pain .</tokentext>
<sentencetext>In the Windows world you can override other things using GPOs, but it's too much of a pain from the admin side (I've found, as have my coworkers over the years) to try and lock down developer machines by removing local admin rights.
I've got better things to do than schedule up a time to install things via an account with local admin rights every time something new comes along for them.
The flip side is that they have greater responsibility for maintaining their desktop/laptop systems.
If it gets screwed up enough, they know they're getting the thing re-imaged with the company standard desktop image and will need to reinstall their tools they use for their personal dev environment.
Works out pretty well, aside form the devs that install absolutely everything they come across, "Oooh that looks cool!
[installs][never uses again]".
They can be a pain.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606728</id>
	<title>Conflict of interests</title>
	<author>node159</author>
	<datestamp>1262282520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>LOL! Giving developers admin access to production machines is like giving grenades to babies, its only a matter of time.</p><p>Ultimately it comes down to a conflict of interest between developers who's interest is to changes things (new features, new version, etc) and admins who's interest is not to change things (SLA's, guaranteed uptime, don't touch a working system).</p><p>If this conflict is not properly balanced (dev's with fingers in production, admins controlling the dev environment), you will have problems and usually ends up being a very costly mistake.</p></htmltext>
<tokenext>LOL !
Giving developers admin access to production machines is like giving grenades to babies , its only a matter of time.Ultimately it comes down to a conflict of interest between developers who 's interest is to changes things ( new features , new version , etc ) and admins who 's interest is not to change things ( SLA 's , guaranteed uptime , do n't touch a working system ) .If this conflict is not properly balanced ( dev 's with fingers in production , admins controlling the dev environment ) , you will have problems and usually ends up being a very costly mistake .</tokentext>
<sentencetext>LOL!
Giving developers admin access to production machines is like giving grenades to babies, its only a matter of time.Ultimately it comes down to a conflict of interest between developers who's interest is to changes things (new features, new version, etc) and admins who's interest is not to change things (SLA's, guaranteed uptime, don't touch a working system).If this conflict is not properly balanced (dev's with fingers in production, admins controlling the dev environment), you will have problems and usually ends up being a very costly mistake.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606524</id>
	<title>virtualization</title>
	<author>markybob</author>
	<datestamp>1262281860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>this is what desktop virtualization is *for*.  use vmware workstation or virtualbox and test away!</htmltext>
<tokenext>this is what desktop virtualization is * for * .
use vmware workstation or virtualbox and test away !</tokentext>
<sentencetext>this is what desktop virtualization is *for*.
use vmware workstation or virtualbox and test away!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574</id>
	<title>Hell no.</title>
	<author>Jethro</author>
	<datestamp>1262282040000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p>HELL no.</p><p>One of my first gigs, the Rock Star Developers had admin rights. They'd pretty much do whatever they friggin wanted. And guess who got to blame when they screwed up? Yup, the sysadmin. Namely, me.</p><p>They'd go in and reboot servers - servers with 100 people logged in and working on stuff - because they thought their database was out of memory. Not tell anyone, nothing. One time they enabled an rsync script that pretty much overwrote a week's worth of work. And who got blamed? The sysadmin, for not making it impossible for that script to work anymore. Or something. It was crazy.</p><p>So basically, yes, it's an accountability thing. If I'm responsible for these machines, then I'm in charge. Period.</p></htmltext>
<tokenext>HELL no.One of my first gigs , the Rock Star Developers had admin rights .
They 'd pretty much do whatever they friggin wanted .
And guess who got to blame when they screwed up ?
Yup , the sysadmin .
Namely , me.They 'd go in and reboot servers - servers with 100 people logged in and working on stuff - because they thought their database was out of memory .
Not tell anyone , nothing .
One time they enabled an rsync script that pretty much overwrote a week 's worth of work .
And who got blamed ?
The sysadmin , for not making it impossible for that script to work anymore .
Or something .
It was crazy.So basically , yes , it 's an accountability thing .
If I 'm responsible for these machines , then I 'm in charge .
Period .</tokentext>
<sentencetext>HELL no.One of my first gigs, the Rock Star Developers had admin rights.
They'd pretty much do whatever they friggin wanted.
And guess who got to blame when they screwed up?
Yup, the sysadmin.
Namely, me.They'd go in and reboot servers - servers with 100 people logged in and working on stuff - because they thought their database was out of memory.
Not tell anyone, nothing.
One time they enabled an rsync script that pretty much overwrote a week's worth of work.
And who got blamed?
The sysadmin, for not making it impossible for that script to work anymore.
Or something.
It was crazy.So basically, yes, it's an accountability thing.
If I'm responsible for these machines, then I'm in charge.
Period.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607476</id>
	<title>IT isn't allowed to touch my workstation</title>
	<author>ap0</author>
	<datestamp>1262285220000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext>My company's IT department is totally incompetent.  Their solution to everything is whatever Microsoft sells, regardless if it's actually a better choice than another option out there.  They don't even give any sort of open source solution a second look.  My boss and I (the only two developers at our office) don't have domain logins and administer our own machines.  We don't have access to any of the intranet apps, but I've never needed them.  We do hardware development so we need admin rights.  We administer our own development servers, as well.  The NAS thing IT installed failed, and it wasn't backed up anywhere, so the entire office lost their shared and backed up data.  Except us, since we knew that would probably happen.  We don't trust them to back up our code.

<br>
<br>
For the other employees at the office, whenever it's time to update software or install patches, one of the IT droogs calls an employee and tells them they'll be taking over their machine to update it (remotely, because there aren't any IT staff at our office -- they're all at another office).  They do this in the middle of the friggin' day.  And since they do the updates manually instead of automated updates, they'll take over someone's machine for sometimes hours, so they can't get any work done.


<br>
<br>
So, yes, we have local admin rights.  We are our own admins since we can't trust our IT department to do things right.  We still have a single T1 to the office (actually two, but they don't know how to configure the router properly to get both of them working), and we're told to "schedule" our downloads for after hours so as not to use up bandwidth.  I got blocked from the network awhile back for downloading some stuff to do my damn job.  No warning.  They just blocked the IP, so I'd change it, and they'd block it again.  Finally they called me and told me that I need to wait til after business hours to get this 50MB file I need to get my work done.</htmltext>
<tokenext>My company 's IT department is totally incompetent .
Their solution to everything is whatever Microsoft sells , regardless if it 's actually a better choice than another option out there .
They do n't even give any sort of open source solution a second look .
My boss and I ( the only two developers at our office ) do n't have domain logins and administer our own machines .
We do n't have access to any of the intranet apps , but I 've never needed them .
We do hardware development so we need admin rights .
We administer our own development servers , as well .
The NAS thing IT installed failed , and it was n't backed up anywhere , so the entire office lost their shared and backed up data .
Except us , since we knew that would probably happen .
We do n't trust them to back up our code .
For the other employees at the office , whenever it 's time to update software or install patches , one of the IT droogs calls an employee and tells them they 'll be taking over their machine to update it ( remotely , because there are n't any IT staff at our office -- they 're all at another office ) .
They do this in the middle of the friggin ' day .
And since they do the updates manually instead of automated updates , they 'll take over someone 's machine for sometimes hours , so they ca n't get any work done .
So , yes , we have local admin rights .
We are our own admins since we ca n't trust our IT department to do things right .
We still have a single T1 to the office ( actually two , but they do n't know how to configure the router properly to get both of them working ) , and we 're told to " schedule " our downloads for after hours so as not to use up bandwidth .
I got blocked from the network awhile back for downloading some stuff to do my damn job .
No warning .
They just blocked the IP , so I 'd change it , and they 'd block it again .
Finally they called me and told me that I need to wait til after business hours to get this 50MB file I need to get my work done .</tokentext>
<sentencetext>My company's IT department is totally incompetent.
Their solution to everything is whatever Microsoft sells, regardless if it's actually a better choice than another option out there.
They don't even give any sort of open source solution a second look.
My boss and I (the only two developers at our office) don't have domain logins and administer our own machines.
We don't have access to any of the intranet apps, but I've never needed them.
We do hardware development so we need admin rights.
We administer our own development servers, as well.
The NAS thing IT installed failed, and it wasn't backed up anywhere, so the entire office lost their shared and backed up data.
Except us, since we knew that would probably happen.
We don't trust them to back up our code.
For the other employees at the office, whenever it's time to update software or install patches, one of the IT droogs calls an employee and tells them they'll be taking over their machine to update it (remotely, because there aren't any IT staff at our office -- they're all at another office).
They do this in the middle of the friggin' day.
And since they do the updates manually instead of automated updates, they'll take over someone's machine for sometimes hours, so they can't get any work done.
So, yes, we have local admin rights.
We are our own admins since we can't trust our IT department to do things right.
We still have a single T1 to the office (actually two, but they don't know how to configure the router properly to get both of them working), and we're told to "schedule" our downloads for after hours so as not to use up bandwidth.
I got blocked from the network awhile back for downloading some stuff to do my damn job.
No warning.
They just blocked the IP, so I'd change it, and they'd block it again.
Finally they called me and told me that I need to wait til after business hours to get this 50MB file I need to get my work done.</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610630
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_83</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607206
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607748
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606590
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608172
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606710
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606916
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607508
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612446
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_90</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30649946
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_64</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608808
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611864
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606982
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606752
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607544
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606822
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_109</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607214
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610530
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_77</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607434
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607200
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613068
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_108</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610314
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_82</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606486
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613026
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30619988
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_96</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608954
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606524
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607140
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609268
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608672
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_73</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607042
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30680176
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30674070
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_69</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607356
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606482
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609900
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612642
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_97</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606844
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607680
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608166
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608280
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618264
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_70</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611660
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_105</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30615294
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_99</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606818
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607784
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_107</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606818
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609728
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607032
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_75</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606612
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608764
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606760
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_89</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_94</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608116
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609482
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_102</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611706
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_68</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606700
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611282
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609068
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_71</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608508
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_62</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607672
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618544
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607302
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607004
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607498
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_58</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609516
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_61</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609960
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607648
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_63</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30614668
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606710
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606858
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_86</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608702
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_103</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606590
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608396
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606810
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_88</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606896
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608070
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607934
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618398
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_91</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607936
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609040
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_87</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30614548
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612120
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_78</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606524
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607112
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608742
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30654452
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_81</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607004
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608208
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_100</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607666
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607030
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_60</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610928
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607176
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618332
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609956
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_74</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606736
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618654
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30690784
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606848
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608054
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607004
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612206
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606882
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_79</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606710
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608684
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606842
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606482
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609120
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_98</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606750
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606524
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_106</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607218
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_80</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30614634
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606524
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607112
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609472
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_76</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609010
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606844
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607844
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606844
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607320
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607214
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611940
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_67</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606590
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608266
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610458
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_72</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30636850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607476
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611068
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607292
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607390
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_95</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607308
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606860
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_85</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610106
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_104</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606708
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608594
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_59</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611166
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_92</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612812
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612002
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_66</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612054
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606590
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607890
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606732
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613288
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_65</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608890
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610098
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608528
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612746
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_93</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609154
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30670344
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_84</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607934
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611210
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_31_1415245_101</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607232
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606900
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611704
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30619988
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30649946
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30670344
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30636850
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618264
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610314
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610928
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611706
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607448
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606580
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607476
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611068
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606448
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606544
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606756
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606486
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613026
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607672
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618544
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608922
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607028
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606710
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606916
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608684
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606858
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606938
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607296
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606574
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606810
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606752
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606732
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606822
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606882
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606728
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610630
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606480
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606760
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606718
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606982
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607176
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618332
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607544
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607292
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607934
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611210
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618398
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608890
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607356
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609040
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607308
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606844
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607680
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607844
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607320
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606818
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607784
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609728
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606736
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606698
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607030
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607666
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608702
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607390
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612120
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611166
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607404
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612002
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612746
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611660
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612642
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30614548
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607508
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612446
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606896
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608070
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606700
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611282
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607458
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606524
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607112
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608742
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609472
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606850
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607140
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606436
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606848
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608054
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607302
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606612
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608764
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606750
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609154
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609992
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607662
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607446
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607206
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607748
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606438
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608672
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608166
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608280
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30654452
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607648
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607200
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613068
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609268
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606860
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607032
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607232
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607410
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606708
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608594
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30618654
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30690784
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606768
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30613288
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612054
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30614634
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609960
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610174
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608508
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30674070
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609482
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609010
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611864
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607214
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610530
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30611940
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607042
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30680176
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607724
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606590
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608172
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608266
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610458
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608396
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607890
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606842
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607892
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606838
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610098
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609516
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609956
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30614668
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30610106
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30615294
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607064
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607004
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608208
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607498
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612206
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606466
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607434
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608116
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607936
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608954
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30607218
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608528
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30608808
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30612812
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609068
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609602
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_31_1415245.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30606482
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609900
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_31_1415245.30609120
</commentlist>
</conversation>
