Slashdot Mirror
Can Developers Work in a 'Locked-Down' Environment?
brad-d queries: "My company is seriously considering enforcing a SOE on all employee computers, including developers. The level of lock-down would likely include baring the Windows registry from changes (and in effect stopping the installation of new software). The goals of this SOE are to prevent users from installing unlicensed software, plus some support issues. What are others experiences with situations like this? Can a developer really work in a lock-down environment? What compromises could be made between developers and IT services? And no, Linux would be likely banned." It depends on how "locked-down" said environment is, and what the developer would be will be working on, however if the Registry is locked with no mechanism provided for the Developer to add in whatever keys are necessary, how much real developing can one do?
If all areas of the registry are completely "locked down", I don't even think a lot of *existing* application would run, let alone installing new ones.
I don't know how you define "real" developing, but the answer to your question depends on this definition.
If your building application software that rides on top of windows, your toast. If you are doing about anything else from 4GL web programming to sockets programming, it probably doesn't make much difference.
Hopefully, you already have installed all the tools you need. If you haven't you should purchase and install them before you lock down.
If whoever is thinking about making such a decision is in charge of development, then get your resume in order because if I were you I wouldn't want to work under him much longer.
www.HearMySoulSpeak.com
If you can't really trust your developers, and need some restrictions in place like that, then maybe you shouldn't have them working there in the first place?
Fuck Ajit Pai
If you get out a bible and swear to IT that you are willing to not ask for support when you screw shit up, they may be open to letting you be blessed.
Carl G. Jung
--
"With one breath, with one flow, You will know Synchronicity" -La Policia
What is SOE????
I work on-site at one of our companies, subcontractors, and the provided machine has extremely limited access, half the software I try to install fails for lack of privledges, others install fine, not sure what the specific differences are. (Win2K)
Even tho this is the work place, the freedom to work on our own platforms and to customize our computers to our liking is important to 1337 h4x0r5. After all, we can spend a whole day hacking away on our boxes.
Locking down on all our computers will just make it less fun, and make me less happy. Less happy employee = Less productivity ergo less quality.
Steal your own sig!
Sounds like the policy implementors are concentrating on making things easier for themselves, rather than making things easier for the people that do the actual work in the company.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
I the company i work for , we started with restried registry... and not there isn't any start buttons... nothing but a nal desktop.
I'm just at the end of a six-month contract to put together a PHP/MySQL/Apache based website, in a locked-down Windows 95 (!) environment with a few thousand users.
They're migrating to W2K shortly, but I put my foot down and they allowed me to wipe my box and install RedHat on it -- the only way I managed that was the fact that it was in a nice shrinkwrap box.
Well, all fine, but I get no support and I'm not allowed to put it on the network, so it's sneakernet for me. Access to the internet is done with floppies. =(
The point is that you may be able to persuade them to let you have a purely standalone machine, as long as you keep an SOE machine next to it for running Outlook =)
What's an "SOE"?
It would be nice if story submitters would define acronyms and initialisms before using them.
I have a list of tools that I'd consider essential to my development environment. For any new job in the future I'd get, I would just ask if I can have them installed, and tell them why. Specifically, I'd put in terms of my productivity. If I still get a solid no, then tough shit, right? They own the computers. There is no compromise.
This is just an idea off the top of my head. But would your company be apposed to the idea of having a developers lab that would be off the corporate network. This lab would be sort of an anything goes environment, where developers could mess with things such as what ActiveX controls are installed, keys in the registry, and what component versions live on the box (anybody familiar with ".dll hell"?). If the developers screw something up, it's up to them to fix it. The IT support staff wouldn't have to be involved at all.
Where I used to work at we had something similar called the time warp lab, that had a bunch of machines running different versions of windows with different components installed. The developers could test their code on them, and when we were done, we just ghosted a new drive image onto the drive.
Check out my podcast: DreamStation.cc Video Game Show
If you're developing Windows apps, very little can be done with you locked down like that. If you're doing Unix work, it doesn't matter since your box is basically a really powerful dumb terminal anyway. (and browser running package)
If they're worried about security, they should give each team its own subnet and firewall. 192.168.0.* is for production, and teams get 192.168.!0.* Your development servers are part of your segment only and go through a circular DMZ to get out. *shrug*
It's not on whatis.
At my company (WinNT network) we have a lot of MS Access database designers and spreadsheet designers who use plugins that can only be installed by someone with admin rights.
You may be setting yourself up for a lot of running around to workstations for setting up these minor things if the users don't have the ability to do so.
"Shared pain is lessened; shared joy is increased. Thus we refute entropy" - Spider Robinson
What other OS besides Windows uses a registry?
Comments please: I don't know of another that has one.
I actually tried to just set my everyday user account as a power user (under 2K) and not login consistently with admin privileges. Worked like crap - had to constantly logout/login as admin to make changes. Finally gave up and set myself as admin.
/. until they do ;-)
It can be done - it is just a productivity drain. And you have to have the admin password or an admin on call or else you sit and wait until they get there.
At least you can read
My company is also in the process of "locking down" all of the workstations. Not only is this creating a huge support bottleneck, it is also limiting productivity as many different departments use custom software solutions that do not comply with corporate "standards", and so will have to be discarded in exchange for "standard" software which does not satisfy the needs of the users. Some of these softwares require the users to have admin rights on their machines, so they are completely out of luck. It is a bad bad deal.
Since you mention locking down the Registry, you're presumably developing for Windows--but unless you're just writing ASP pages or something, you have to register whatever it is you're developing. That's the Windows model. This sounds exactly like the kind of PHB-think that turns a minor headache (license compliance on the off-chance of an audit) into a major disaster.
Fortunately, it's the kind of policy that's too stupid to stand. We had a similar thing (promulgated by memo from the CIO, rather than enforced at a technical level, though) which held for about twenty-four hours before they quietly exempted all the developers...
If you are developing your standard Client/Server App than you have no need to be dinking around with your system. It's a tool to do work with, not play games on.
If your company is still evaluating products I would recomend Novell Zenworks, by far the best product in this catagory.
*joking*
I would defintely bring this concern to management, as developers should be the exception to the rule. When I did develop under Windows at a company, I had to install numerous applications of various versions for unit testing in my local dev. environment. I sometimes needed shareware tools that the company didn't have also.
If they made the registry read only, you would not be able to install anything, which is bullshit for a developer to have to go through.
It is bad enough the issues I deal with IT at SUN, but at least I have my Solaris environment and root access under my fingertips. I hate to see the pains developers go through with IT telling them what they can't do and management telling them how to do it.
That's like write-protecting the entire drive. It's stupid and foolish.
Technically, the default in Windows NT is to allow Administrators access to the registry, but deny Users. But even then, that's talking about the System registry (HKEY_CLASSES, HKEY_LOCALMACHINE etc). They can still access their own registry hive (HKEY_CURRENTUSER). Any time they change a setting like background color or window placement (provided those rights haven't been taken away by a system policy) is saved there.
You wouldn't write protect an entire drive to keep people from messing with the Windows directory. Just block off that directory.
Likewise, the registry has the same kind of access controls. Give developers read/write access to a specific key in HKEY_LOCALMACHINE\SOFTWARE. Technically, this is where they should be storing registry settings anyway.
- JoeShmoe
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
We have a pseudo SOE in our environment.
IT has to do a lot more work in ensuring that rogue applications do not proliferate. I dont think we have a "hard lock down". If the company is willing to provide all the necessary tools and support for development then it is an extremely efficient environment. However consider the possibility that the IT department now has some control over what the development environment can and cannot do. Do you trust your IT department not to get power hungry and make it an inefficient environment? The IT department would most likely have to have approval on all new apps and that could be very inflexible.
You also lose some capabilities of have an exploratory environment.
I know many developers that do very little outside of what they are told to do. Thus management leads the design process and the developers follow. This leads to people who are not very aware of modern technology designing a 'supposed' to be modern app. With some developers installing new apps, testing new software and doing things like that on their own they would be constantly callin IT for this and that, especially if you have a R&D group. Personally I woudl be against that as I like to install certain of my own favorite editors, icons, tools to make some things I do easier. After that I suppose IT could lock the registry, but ask yourself what does this really gain? IT should just say we support this software and if you install stuff and screw up your machine you just have to wait. In some cases it is just a matter of knowing who can be trusted to know what they are doing in Windos. Some users can install and uninstall and do as they wish and you'll never hear from them while others will be constant problems.
Only 'flamers' flame!
Pester the support people. Make them come out to install every new piece of software that you need to do your job. Hold their feet to the fire for all the support you need.
Eventually they'll realize that the price they're paying in increased support calls is not worth the "security" of locking down your desktop.
I'm in just such an environment. Less than two weeks and they gave me local administrator priviledges under the table.
Unfortunately, because of the tech situation and there being a lot of out of work coders (etc) managers think the time is ripe for coders to recieve a message: that they should act, think, and work just like every other kind of worker. If you think that this isn't right, act now and insist on being able to work like you want to. Otherwise, find a different job and don't give notice. BURN YOUR BRIDGES!
If developer wants to install unlicensed software he will do so... even with enforced SOE, since developer is considered to be skilled enough to overcome such "protection". If your developer is not skilled enough to overcome this, he can be hardly called developer.
It's really hard to lock down developers. Usually developers demand some degree of freedom, especially the freedom to install their own tools. No people can work without the tools they familiar with. Thus, this can be detrimental to their productivity, which in turn is a loss to the company.
The tool itself can vary across colleagues even the primary usage is the same. My colleagues complain when they use other terminals when one of the alternatives is installed. Whining for some missing quirk they love and so on. I think tools like this should be allowed provided that they have the right license for the software.
Changing Windows registry would be unrealistic. Some software even store the Most Recently Used File (MRU) inside the registry (like WinZip, MSWord). Or even the last opened directory (like GetRight). Freezing the registry would cause these software to fail. Beware.
Barring some registry might be viable, but it could have a performance hit into the terminal (i.e. by intercepting all registry-add or change calls). Think of it. Developer hates their machine bogged down for some trifling-but-annoying issues.
--
Error 500: Internal sig error
It doesn't work too well, especially if you are developing software for the PC, to lock down developers.
Most places allow developers to disable the lock-down, and generally won't debug your machine if you screw it up, just rebuild it from scratch. Even the big guys do that.
Gentoo Sucks
2 ways that I have seen.
One. The department is woefully underskilled and incompetent for the jobs they need to perform. In an effort to try and head off as many problems as possible they lock things down to a minimal set of known circumstances.
Two. The department is horribly understaffed. They feel the only way they can keep up is by making sure there is little different from point to point.
I firmly believe in having a COE on every machine. But I also believe that a user can and should have the right to software they feel would enhance their work experience. As an IT guy would you really know if MATHCRUN2002 helps that user or not? Make sure all users run the idea by you first and let them install it. As long as they have the understanding that is isn't supported and if something on your machine can't be fixed quickly you will return the machine to the COE.
BTW the two reasons I listed at the top are a result of poor management. Usually you end up with fascist IT directors when they have no concept of how to really run a computing environment.
--- I do not moderate.
In theory the company I work for have locked down Unix and NT systems.
However all the development teams know the root passwords for both systems and use them freely.
IT knows about this. In fact in quietly keeps the developers supplied with passwords. They long ago worked out that giving programmers control over their own machines leads to a much quiter life.
Hian
I worked in a place that tried that. They were a NT 3.51 shop, and when they started rolling out NT 4.0, they decided to do the "lockdown" thing. Nothing could be changed on the box, not even screen depth/resolution (umm, duh, we need to test the software that we are writing against different machine configurations, including screen resolutions...).
Well, that lasted all of a couple of days before each developer was given admin rights on his own box. Seems the support department got real tired of trotting out to our desks to make simple changes for us...
"Send an Instant Karma to me" - Yes
Looks like they don't want you to do any work while you're at work. But they're still paying you, I guess. Not a bad position to be in, at least for a while. Try to avoid your boss as much as possible, and use the time to read up on new technologies. Perhaps you can start leaving work early to write your own stuff at home.
But seriously, any company that has let its IS dept call the shots is doomed, especially if it's a technology company. At some point, you might want to start heading over to the exit door, so you can make a quick escape when the decay really starts to set in.
Do you NEED access to the registry? Do you install that much different stuff on a daily basis? I see limiting install access as a good thing for most employees, but not necessarily developers.
I worked at a place that replaced 400 systems with WinNT from Win95, and you wouldn't believe the crap people had installed, which they expected us to put back on and support when it didn't work.
Keep in mind why a company would want to restrict write access though-
1) they don't want to get sued (pr0n, warez, etc.), and they ARE liable for what people have on their drives, and
2) users have a nasty habit of installing crap that "oh, my friend sent me this email and..." and then they boot into a BSOD every time.
That's a pain in the ass to support. If you can alleviate those fears (and as a developer, you probably know what you're doing), you'd have a better shot at not getting restricted.
"If he thinks he can hide and run from the United States and our allies, he's sorely mistaken." Bush on bin Laden
When I was doing dev and patch work over at Nortel a couple of years back, they did this to us as well.... we had locked down HP-UX boxen with severely limited user permissions... and doing NT development, we logged into an uber-restricted NT box by VNC. Nortel was obsessed with lockdown, and we didn't have the appropriate termissions to runs the applications that we were compiling. When it was brought up with supervisors and directors, they'd refer us to IT, which, in turn, would refer us to our supervisors and directors.
In order to ensure output, all us guys on the floor pitched in and bought ourselves a couple of development machines so that we could actually get work done... but we had to fight with provisioning for three months in order to obtain two IP addresses for them. AAAAARRRGGHHH!!!!
We did, however, manage to make it look like we were working that whole time just by answering email and voice mail and going to the occasional meeting.
In conclusion, the stock options that they offered me are now worthless, I'm out of a job, and a company that stupid had to fall hard anyway. Ah, the good old days...
Urban Detail
If I had to work for such employer I would simply
quit. I cannot see how my job would be fun
and productive with such constraints.
If all employers would do the same I will simply
change branch of work... I remember having fun
doing some truck delivery when I was younger..
Anyway, who cares about registries? I use
real man OSes
The moral of the story is simple: programmers want to be free.
-CT
SOE = Standard Operating Environment
;)
Just so ya know... I had to look it up
antidigerati
We did it. Our company (project actually) locked down our "work" machines, so we asked for development or unit test machines. They said OK and we were able to take control of the system for our development needs. wOOt!
Blarf.
The man who cuts the checks makes the rules. Funny how subjects like this do not come up when applying for a job. It is in the employers best interest to make your workplace efficient, if a new solution does not work they will change it.
I have worked on a system that was air-gapped for security reasons. You had to jump through hoops to bring in any software, and the process was so painful that it was rarely done.
We survived, but we didn't have as many neat tools as would be nice. We were just kind of used to it and homebrewed simple things or made do with what we had.
On the other hand, going to that sort of system from a more open system would probably damage morale, a problem not encountered by a system that's been closed since its inception.
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone
Consider something simple -- automated testing. If you want automated testing to work, you need registry settings to prevent your programs from popping up dialog boxes if they take a long walk off a short pointer or some such. But those same registry settings would be completely inappropriate for real development, when you want the opportunity to pull up the debugger. There is not a single One True and Holy Registry -- you always need to tweak reg settings.
--G
That place will go down in flames due to problems related to security changes. I can't tell you how much just locking the registry down can destroy user productivity... as in the machine and all apps crash all the time. Beside the hassles it would cause the developers, everyone would suffer. I don't care what software anyone uses, if you use hacks and third-party security resources, you are looking at an even less stable platform. Believe me, I have nearly three-hundred machines that have Fortres and DeepFreeze on them. It isn't worth it. What can be done is that a user policy can be written up, tried, and then implemented that would get the user in trouble for being an idiot and fscking the machine up by installing unauthorized software on it.
In my company, there is the same sort of lockdown on all employee computers (W2K), with the exception of developers. As a developer, I am assigned a higher lever of trust not to screw up my machine, and have admin rights on it. OTOH, my W2K box is also my first-stage development server, so I have to be able to admin that box.
I guess my point is, a blanket policy that considers developers no more savvy than typical office workers seems to be shortsighted.
Bush is a cylon.
If it turns out developers can't work in a locked-down environment, companies will notice almost immediately after they start the lockdown. If in the process of maintaining the system integrity they crave so much they end up harming productivity, they themselves will have to make the decision of whether to keep the system active.
Some companies will think the time they save on maintenance is worth the productivity blow, others will change back. Developers will pick whatever work environment suits them. Basically, nothing happens - how boring.
Ceci n'est pas une sig
Unfortunately, vmware has gotten rather expensive, and plex86 probably isn't ready yet (please, if you can help the author of plex86 find a good job, preferably working on plex86, do so). But if you are willing to pay for Win2k and Win2k software, the cost of vmware is small in comparison.
Otherwise, you may be able to work on your own laptop...
Oh, if you are doing real-world Microsoft Windows development in Visual C++, a "locked down" environment is probably too constraining. If you are just developing algorithms in C++, or if you develop in Java, it's probably doable. But forcing people to use a specific set of tools is not exactly the way to keep developers happy.
seriously, there is a real need for locking down windows desktops. developers should be building apps and then delivering them via RDP, ICA, etc...to avoid having the IT guys chase down all the in's and out's of enabling the desktops to support their apps. With remote app delivery there is a compromise. IT locks down the desktop with manadatory profiles/group security policies...developers get an "island" where they can do whatever is needed to get their funcionality built. The remote application servers can be firewalled and otherwise secured from the rest of the network. everybody wins.
Developers should not be treated as sheep. Even writing mundane input routines is a creative process, and requires a decent amount of both technical know-how and intelligence.
Would a company consider telling all their advertising and marketing people that they can sit at their drawing boards but not adjust the height, angle and lighting of their workspace? If you treat developers like idiots who can't manage their own workstations (i mean geez!), that will show through in the quality of their work and their morale.
---
Play Six Pack Man. I
SOEs are fine for USERS, not for developers. Silly PHB. Such an endeavor is doomed to fail. I work at a place where an SOE in force. Development groups usually get special exception to obtain admin rights or else they couldn't even get off the ground.
The real problem is that management never thinks of implementing multiple tiers : More restrictions on Office worker types, less for development -- AND NONE FOR LABS! If you're on the group who's testing, say, WinXP(Chi-Rho) for deployment, you can't be fighting 'access denied' all day.
That of course depends on what the heck you're developing.
If it's windows stuff, consider having some machines for development only and others for mundane productivity tasks. Perhaps leave the dev machines of the network, or on a separate net for (necessarily perhaps) flaky development work.
I'm sure they're just looking to lower support costs and make stuff a little more reliable. Keep in mind that everyone in the organization isn't a developer. And developers can also screw crap up and cost IT support dollars - though most will swear they couldn't break anything....
Divorce functions you must have for routine work (email? documents? net access?) from development work.
I've supported developers, and they often SUCK TO SUPPORT -because all assume they are computer gods. But when shit breaks they come crying to IT - and if it ain't fixed an hour later we're obviously lame IT dipshits.
We've found that it can make sense (and save money and hassles) to have more than one mode of operation.
Now this assumes an organization that could invest in some testing and development machines. If you're coding at home or you company is tiny then it doesn't fly --- but if that's the case the no one is going to lock you down anyway eh?
-dipshit IT guy
As for "real" development, I wouldn't even dream of accessing the registry from asm.. :)
As an experienced developer under NT/2000, in C++, perl and Java, there is no way on earth that I could be productive in such an environment. It may be feasible to work, but certainly not to be productive.
Those of you who read The Register will be aware of the Bastard Operator From Hell (BOFH). His mission is to thwart users from actually using the computer systems. He would be in his element. Developers constantly wanting to install patches, competitive products, tools, new IDEs and utilities - any sys admin in such a role could get almost anything he wanted in bribes, when a dozen developers compete to get a myriad of different products/patches installed. A rich man indeed! (Yes, my wife is free on Saturday - if you install the netbeans 3.3 release for me.)
Sheez! To even think about it! I would never accept this, I'd work on my own laptop, then copy the work acrosss via CD-R,floppy,zip (install the drivers? No chance mate!)/external disk ~(ditto)/punched cards/IR.
There is no way I could develop software without constant access to all the machine.
Just my take, of course
Note to ACs: I won't mod you up, even if you are being funny or insightful. So take a chance! It's not real life!
Speaking purely from the perspective of one who has had to deal with locked-down computers, I can say it is fairly obnoxious if one's work habits happen to differ from the One True Approved Way(tm) handed down from Those who Know Everything. Maybe I want to change my screen resolution (because my 17" really needs to be at least 1280x960, or maybe 1600x1200 is entirely too small on my 15", or whatever), maybe I want to change my keyboard layout (there are those who use other layouts), or maybe I want to install vim (which claims to work nicely with Visual Studio, although I haven't tried it), or maybe I think that a bunch of ringwraiths on my desktop would be better than Approved Microsoft Blue. Maybe I want to install another browser instaed of the Officially Approved Browser. I don't want to have to run crying to the Approved Policy Makers every time I want to change something, and I can imagine that the Approved Policy Makers don't want me to, either. Restrictive policies may make it harder to install unlicenced or illegal software (and I can't imagine that exchanging instant messages for eight hours constitutes useful work, although occassional use should be ok -- business phones get used for personal communication as well, but everyone has one on his or her desk anyway), but they will likely cause a larger support headache, as well as making it harder for your employees to work effectivally because they can't customize their work enviornment.
We wouldn't lock down our development staff. It would just be too big of a burden on us and them. My support guys would constantly be running back and forth.
BUT, I can see why they'd want to do it. By far our worst offenders for installing unlicensed and non-standard software (not dev tools) are developers. And frankly, 3 out of 4 developers I meet (DEFINATELY not normal Slashdot developers) can't fix their own PC when they break it. I'm amazed at the lack of understanding on the base system...I don't mean really get in there, but just simple things a real "power user" would know.
Put this in a file, let's call it 'unlock.reg'. Double-click on it, and voila, your regedit.exe will now work.
/S unlock.reg'... same thing.)
u rr entVersion\Policies\System]
C ur rentVersion\Policies\System]
/S seems to not check the policy). I guess it's to keep you from locking yourself out of the registry permanently.
(Or from a command line, type 'REGEDIT
REGEDIT4
[HKEY_CURRENT_USER\Software\Microsoft\Windows\C
"DisableRegistryTools"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\
"DisableRegistryTools"=dword:00000000
I know that on Windows 95 and 98, this will work even if the system policy has been set to disable registry changes (as running REGEDIT
There is a commercial app called 'Foolproof' that claims to lock down Windows from being modified, but it's buggy as hell and breaks Windows Explorer, making it crash constantly. I guess a hack to a hacky OS can't be expected to be all that reliable.
We're developing Java applications. They claimed that they couldn't support the deployed application if we all had different machines because we might do machine specific stuff. Never mind that we developed on NT and they deployed on Unix and we already had case-sensitivity issues popping up all over the place.
They never got around to actually locking the dev machines down, because there was too much backfighting when they tried. Most of the developers said that they would fix whatever problems they created. IT tried to use a management tool to push new software onto peoples machines because "people usually mess up their machines when they install their own software." The second time they used it, they ended up wiping all of the apps and registry entries off several machines. We kind of put the brakes on them using that software after that.
Since then, they've been heavilty hit by layoffs and they no longer complain when we want access to things that will only reduce their workload.
But to answer the original question, no, you can't develop anything that way.
Cygwin installs perfectly even if you don't have admin rights. You can even
run secure shell under it!
Secession is the right of all sentient beings.
It stands for Standard Operating Environment.
Basically its a set of recommended software available for installation on a company's / school's pc's.
Eg. I can install Windows 95 and Visual C++ but not winamp.
Cruise TT
Make people receiving new accounts sign an agreement that they will not upgrade their installations with unapproved software.
Fire those who fail to comply.
Then you'll still be able to do your job without having to go around unlocking registries.
--Blair
"Are B-schools spending all their time on cultural diversity and takeover avoidance?"
Why do companies think they can hire at the bottom end of the wage bracket and not end up with the least-talented, least-skilled, and least-intelligent group of keyboard apes in the business? Hire good people, and this isn't a problem. Sure you have to pay them more, but their greater productivity will more than cover that.
Twoflower
--
Twoflower
I worked in a place that moved from Windows 3.11 to Windows NT (but they still thought 32-bit programs were 'a passing fad'). They locked down the registry so tight you couldn't connect to a network printer. I had local admin rights for myself and my development team, but they decided that that was 'insecure'and were going to change it, but I left before they implemented that stupid policy.
www.lucernesys.comHorizon: Calendar-based personal finance
My company is very large. Our policy is technically like yours, but the enforcement is occasional. IS warns us that they'll be sending around a script that will be checking for BSA infractions. I make sure my system is clean. Since we're not officially allowed to have "unauthorized software" on our boxen, I make sure there isn't anything suspicious on there, even Mozilla. After the script runs, back the old software goes.
If your company is large enough, you may be able to get away with that.
There are 10 types of people in the world. Those who know binary, and those who do not.
Before the idiots show up.
Let them do their thing and leave. Pop in the NT CD. Do a reg. restore (as though you had a system failure or something).
...and the lock down ended up being company wide with the exception of IT (including developers). We discovered that IT personnel were unable to function at that level.
We reviewed our security policy during that time and allowed IT to be unrestricted as long as they were periodically audited and held accountable for infractions to the policy. The down side is now IT gets audited on a fairly regular basis and much more than the rest of the company.
We had a developer come in on contract and we started him with a locked down w2k box. As the project progressed we found that even the default user levels of win2k where too restrictive to development work. He wound up as a power user, (one step below admin) which seems to be the best level as most things you need to do for development can be done at that level.
Ehh just my experiences on the mater.
I've been a professional developer for about 6 years now. My users have been subjected to everything from aggressive logon scripts, to software that actively replaces system (more than just .reg) changes (ie: Sabre)
The best thing for "IT" to do with the developers (hey, aren't many of the developers PART of the IT talent ???) is to let them run free. The help(less) desks are typically useless for anything outside of the normal daily user issues anyway, so why expect the HELLdesk to support the more complex problems that we as developers encounter ? Have the developers support themselves. If a developer needs infrastructure or other support, they typically know who to call (or they can then ask the HD for who to call). Things get accomplished efficiently in an organization often times because of the personal relationships people have, not because of some pointy-headed lockdown policy that gets imposed on the team.
Best of luck convincing your bosses ;)
There are no famous hackers
.
.
.
"Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech."--Benjamin Franklin
when nobody's looking, wipe the drive, install Linux. Use WINE for what you need for work. The type of twit who would lockdown your machine probably wouldn't know what to do with your unix login prompt, and wouldn't have the password anyhow if they did. you win. ha!
Well, you might get in a little trouble with your wageslavemaster. But it would sure be a lot of fun until they noticed.
It sounds awfully like your sysadmin is a lazy bum and can't be bother with support so (s)he's imposing these stupid rules to make his/her life easier. Resist, boycott, protest but don't let this happen. Any permissions, restrictions and access control are usually a huge pain in the ass. I'm in the opposite situation to yours. We use windows for development and Unix for staging/deployment. All unix work must be consulted with the Almighty Unix Sysadmin. The result? Nobody wants to deal with the asshole so noone bothers testing things on unix anymore and our app sucks in the production environment, all thanks to access braindead restrictions our sysadmin keeps coming up with. I think my company is fucked as a result and so is yours by the sound of it. Dust off that resume right away is the only piece of advice I can give you
Your pizza just the way you ought to have it.
It is a fragile relationship, but it has worked very well for us. In addition we have worked a deal that allows us Admin access on all the machines we distribute to (150+). This is a very unique relationship within the corporation, but it affords us the flexibility we need.
.Kris
Prof. Frink: "Here is an ordinary square."
Cheif Wiggum: "Whoa, whoa. Slow down, egghead!"
Wouldn't it make sense to use VMWare? You could install a windows in windows, in which you can mess around all you want! Doesn't really SOLVE the problem, but moves it away so nobody can see it anymore ;)
This just sounds like a boneheaded IS policy. Some pinhead in IS got some bright ideas of how things should be, and is trying to stuff it down everone elses' throats. Granted this kind of stuff makes a company doomed, but depending on its size it may take a while for the ship to sink.
If mgt at that company was really after sticking it to the developers, they'd do something like institute a mandatory dress code, and enforce 9-5 business hours. They'd try to turn you into boring little bureaucrats. That doesn't seem to be the case here.
On the other hand, if you want drones that do nothing but what their told... it's ideal. In this case, a project manager would likely have the appropriate access to ensure the final product is acceptable.
It's the structured heirarchy vs. social system, again. The cathedral and the bazar. Clearly, your boss has some reason that he doesn't trust your co-workers. He must also believe that the people at the top are more innovative than the people who are writting the code.
In terms of techincal considerations, there are work arounds for pretty much everything you should want to do: DDE for App to App exchange and 'INI' files for config, but you'll never be able to write a working install program without full access.
Lemme guess , youve got some bitch of an NT (wannabe) Admin running around saying the sky is falliing were out of compliance...And managment belives it
Heres the deal , think of it this way, who makes your company money ? the admins or the develpers ?
Well if youre a MS shop (sounds like you are) the MSDN subscription you should have covers the development use of probably 75% of the stuff hes crabbing about. Other than that, depends how far down on the food chain you are there if youre one or two levels below someone who can actually make a real decision, go to them and tell them this, you have serious concerns about productivity if this is implemented, if the bottom line is what matters there this may help. Tell em point blank it a horshit managment decision by people that have no clue what they are talking about.
Someone else here has the right Idea, Ive implemented the same thing on 2 occasions, seperate development enviroments where the DEVELOPERS are the ONLY ones supporting their own system, come up with a seperate admin within that group, really pisses off the bitch NT admin, but screw him hes noting more than someone to keep the infrastructure intact, Im betting development is where your money is made, so why should he set the standard you develop by.
Get some balls, tell them NO, in my experience a company that cannot trust its employees has much deeper managment/financial issues, may be time to start looking for a job from someone that dosent tie your hands and expect equal performance.
Sig went tro...aahemmm.....fishing........
I have developed in a SOE. It's not that bad provided you have a test lab. Besides, it's not good to test on your own PC anyway. The problem isn't the limitations on installing software but rather the bureaucratic ladder you have to climb to get approval for something new. For instance, getting a new compiler approved can be tough. If you can solve that problem with management it works out.
I'll actually endorse a SOE in some cases. It can be especially good if you have separate environments for developers but it is standard among them. It helps ensure compatibility.
Of course we torture people, we need the information --Gen. Pinochet
No, this system sucks. We have some WinNT4.0 and Windows 2000 PCs in a lab at school that have this. A lot of programs simply require the ability to write to the registry sometimes. The best system I think is having applications run off a server using some form of Linux/UNIX. Our administrator is constantly coming around to the PCs to install stuff for us. It's a big pain. We have to log off, he logs into the PC, installs some software and then logs-off. Half the time he doesn't install it exactly like he was supposed to, and we have get him to do it again. It's a big waste of time for IT administrators.
Doing any significant development, you're not likely to need a lot of time working on registry modifications procedures, with the exception of a save settings routine in the Setup window. Actually, if you code it right you shouldn't need to create keys in the registry at all if they aren't that important. It should allow the program to continue with default behavior if the key doesn't exist, or cannot be created. Give the user a warning on errors that setting modifications couldn't be saved because you couldn't modify the registry. Chance are that some customers (if this is commercial software) may have the same restrictions. And if you're storing anything more than settings in the registry, then you're most likely storing the data in the wrong place anyways.
The only thing I can think of, is if you are doing some program protection that stores some encrypted values in the registry. I think IT will understand if thats what you're developing. But after you're done developing that, then it should just be a black box and you don't need to test it again.
And most likely you can get the keys for your software's settings to be left open. It's not unreasonable.
It's horrible!
Where I currently work, no software can be installed, and much existing software breaks. Windows media player causes a GPF, and many enhanced websites cause the machine to hang. The registry is locked down, and I don't have rights to "program files".
Every time in the past I've needed a piece of software, it generally takes days to be installed, and the entire chain of command has to OK it. If we directly submit a request be it for software or support, it gets deleted.
This completely and utterly lowers productivity. If I need something and I need it now, it takes days or weeks to make it happen. Problems or requirements that could easily be taken care of by the user are not possible, resulting in delays and wasted time.
Plus, IT stops by once a week to add software, odbc connectors, or make other changes. Those are things I could very easily do myself. Doesn't IT have better things to do?
I'm surprised they let me add bookmarks. Don't even get me started on firewall rules.
You could feel no difference at all, or it could be annoying as hell. It all comes down to being more dependant on others. When you have a problem or need something, you can't just solve it yourself. If there is tech staff available to compensate for the flexibility you lose, no problem.
;)
But there isn't.
Here, developers and system admins build their own boxen. Most bring their own box in as well as their company box as well.
:)
Sittin in a space of which cannot even be considered as luxurious as cubicle.. I have 2 monitors with Xwindows running Blackbox at a 2560x1024 using a 5 (fully loaded) workspaces. If I had a configuration that was any less, I would get a lot less work done. I also have a television setup mounted on top of the 2nd monitor which is occasionally used for a trinary head.
Developers and system admins like their configurations, their hardware hacks, and their toys. Let us play or give (much more) pay
I think it depends on the size of the organization.
I have worked in a couple small organizations (<150) where IT was very easy to deal with. We were allowed "power user" to the machines and individual requests for anything else that needed full admin.
I larger organizations, it was usually agreed upon that we would seperate the devs from the global network, and the manager was held accountable for the software licenses. Then the manager (or other lead) would be the contact to IT for any network or other support issues.
Without atleast "power user" rights, I can't see that the machines would give the users a comfortable work environment. I've been known to have to uninstall and reinstall software packages 2-3 times when I did something bone-headed.
just my 2
Jobs aren't that hard to find.
Use something like VMWare, your own installation, your own operating system. It will compromise on speed, but hey, if you dont have a choice, you dont have a choice.
Instead of a registry lockdown, why not have an automated licensing check run on the companies software. You would have a program that scanned registries across the network for installed software, and check the installation against company licenses. It would quickly ferret out things like pirated copies of Photoshop and the like.
No, Thursday's out. How about never - is never good for you?
90% of the developers won't be able to get anything done. The 10% that can hack around it will be the only ones able to code.
I've had a similar fight everywhere I've worked except my own company. I even had one IT director running around, asking everyone who I worked for, so he could complain about me running Windows 2000 when they weren't ready to migrate everyone yet. (Someone finally told him I worked for the CTO and he gave up.) These paper f-ing MCSE's get taught how to run a Windows network full of secretaries, phone droids, and marketing weasels. None of their classes or cram sessions talk about administering a network for developers. Maybe they should have a special cert for that.
Personally, I welcome the challenge of any paper MCSE that wants to try to lock down my machine. I use a laptop running a tightened Win2000, never leave it unlocked, and don't log onto the domain. They have to force my boss to make me let them change my box. Not gonna happen. Even worse, I tunnel my web browsing over SSH2 to my OpenBSD box at home. They'd really hate that if they noticed.
As long as you can get it onto the LAN, it isn't really too hard to copy files back and forth between Windows and Linux. So bring in your own Linux machine (laptop would be even nicer) and develop using that. This will only work if you're not doing things where you really need the Windows developer tools.
There's also vnc which allows you to not bring in an extra monitor, keyboard, or mouse.
I did this and saw my productivity go way up.
VMWare allows you a sandbox to "test" without risking damage to your machine and/or the network.
As an IT manager in an SOE environment (with the exception of IT) we have found VMWare a godsend within IT.
'Safe Operating Envelope'
that's great... i've lost many friends and family to the perils of standard (read: DEADLY) envelopes.
A: None. The Universe spins the bulb, and the Zen master merely stays out of the way.
In all the teams I've run, I've made it clear to the Powers That Be that the developers will run and maintain their own machines.
When a new developer came on board, his/her first job was to build their box out, roughly according to the instructions that IT laid down (like how to access your corporate email, where message boards were, etc.). But after that, the box was HER OWN MACHINE to do with as she pleased.
Now we also put the entire dev and dev-testing network on its own subnet/domain that could be literally unplugged from the corporate net with literally one disconnected CAT-5 cable. (Yes, we had a good switch behind it. :-) This seemed to mollify the IT staff. And besides, a good test system must be able to be disconnected sometimes.
The upshot of the whole thing was that we were indeed an island of chaos in an ocean of relative infrastructure calm. And you know what? It works great! Any developer worth her salt will know how to do basic box and network admin.
Oh yeah, and remember to get static IP's for your developers' boxes. Makes Internet development work a lot easier!
What it really comes down to is convincing the Powers that developers must have free reign over their own systems. Your biggest friend and enemy will be the IT department. Make friends with them; negotiate and compromise an acceptable solution to the problem with them. If you can get IT behind you, the Powers will have a lot of trouble denying you.
Fight for it--it's totally worth it! Good luck!
S.
I manage a the IT structures of my small business clients: I urge then to decide on the balance between freedom/security on an individual employee basis: A competent office manager who knows what a potentially damaging email attachment looks like should have free reign, while the ditsy secretary who wants 'the AOL internet thingy' should have a locked down box.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
Nothing a great little Linux boot disk won't help.
Information here, RawWrite Image file here.
All unauthorized hax0ring aside, how can you trust employees to work in your office, access confidential information, deal with financial issues, and speak to clients, if they refuse to listen to what software can be installed.
My school does the same thing. Its a big waste IMHO. Often at work/school you want to install a messenger program, perhaps a game or two. Just to provide a 10 min distraction every so often.
Employers have to realize that employees are humans. 8 to 10 hours of pure "work" is just plain wrong.
Someday, I'll have a real sig.
Fruit of the Loom tried this and it just doesn't work. Most of the developers ended up reinstalling to get around the lock downs. Developers simply have too many needs.
And they get along fine. If they convince us that they need full control of the machines, they go behind a restrictive firewall.
It's really a great system.
-- dieman - Scott Dier
It's a great idea that works well. It drastically lowers support and maintenence costs, and helps IT leverage their budget against something besides the help desk.
Now, for developers it presents a HUGE problem. However, the way around this is to make sure that the developer's machines include virtual machine software like VMWare and a set number of "development virtual machines" that the developers are free to do whatever they want with!
This does a number of very positive things. One, it keeps the developers from accidentally doing something that messes with company network, since the "development" machines are now all on their own virtual network inside a computer. It keeps IT in a state to be able to maintain the local network and systems and INCLUDE the developers. And it allows for everything to be standardized. Everyone goes home happy.
Now, where it won't work is if the developers won't be given a powerfull enough system to run multiple virtual machines, or the IT people refuse to entertain the idea of allowing a virtual machine product.
When either of those things happen, the results are either bad or worse.
The important thing is to raise these issues early in the process so that the business decission makers can be made to see the sense and reason behind giving the developers their own play environment in the form of a virtual machine.
If you're working in a Windows environment, you likely won't be able to perform your job. Depending on what kind of development you're doing, many essential functions are restricted to those with admininstrative priveleges. 'Debug applications', 'profile single process', 'modify environment variables' and 'profile system performance' rights spring immediately to mind, but I could come up with tons more if I had a few minutes to think about it. If you're doing web stuff, maybe this isn't as necessary (I'm coming from the system development POV, so it's out of y realm of experience). There's NO WAY I could do my job without at least local admin rights to my development boxes.
In my experience, locking down those workstations for Mary Jane secretary is usually a pretty good idea, if for no other reason than saving the users from themselves. Every place I've worked at, though, has been lucky enough to have an IT staff that recognized the reuqirements development has.
I worked for a small startup, and the only platform the IT knows how to manage is Windows. And on a new project that used Java only, I installed Linux on NT machine (duo-boot), and I did all my development on Linux, while everyone else worked on NT.
The problem happened when one of the routers went nut, and got into an infinite loop or something like that, and only a few packets per second went thru. And then the IT blamed it on me and my Linux box, saying that my Linux is broadcasting all kinds of packets on the network and bogged down the whole thing. It was ridiculous, and we didn't have any troubleshooting tools to figure out why this happened, and from what source.
As I had 3 machines in my cubicle, I finally sealed them up in my own subnet, with my own firewall, and I was on my own. No more IT support, as if there was any before that. All packets from my network went thru another router. And I was really happy in my own little kingdom.
After that, the router still went nut, and finally, the IT had to figure what really went wrong. Actually, it was because the router corrupted its own memory, for some reason.
...if Linux was banned, hell I'd probably start looking for a new job. I don't use windows for any serious work, the Windows head on my desk runs winamp, outlook, and a web browser, that's it. My productivity would be severely (negatively) impacted by being forced to use Windows, even more so by a locked down version.
I'm the big fish in the big pond bitch.
It CAN work, if you get speedy help when you need to do something that requires admin rights. It's only a nuisance in that case. If you can't get good support, you've effectively crippled your developers. Where I work, developers aren't granted administrator privileges to their Windows machines. The support staff is also horrible, they take 2 or 3 days before resolving your issue. So what you do is this... call out the support tech and tell him you want to install some software. When he is doing it, get him away from the computer and set yourself up with another account that has administrator rights. Then when he finishes the install and logs out, you can log back in as your new administrator account, and give your old account admin rights too.
"The advanced societies of the future will be driven by competing systems of psychopathology." -JG Ballard
At the last company I worked for, we wouldn't have gotten a single project completed if we had a system like this in place. We (developers) all used software that was not registered... and LOTS of it. Management of course told us to go ahead and use it right away anyways (because of project deadlines) and they would take care of getting the licenses. (which they never did)
And what do you know, one morning they warned us all about removing all un-licensed software. That afternoon they layed a couple of us off. (obviously covering their @$$... i still can't believe i didn't see it coming.)
Karma: NaN
Developers should really, really work in a sandboxed enviorenment. I'm talking about a development network that is cut off from the rest of the internet. Development work is directly contrary to modern security philosophies. You have to make it work first for proof of concept, then figure out how to make it secure.
Luck favors the prepared, darling.
I am stuck in a similar situation where I am. I have found that the easiest solution to this (although it's a bit on the expensive side)
to just buy a laptop, set it up to mimic the environment as closely as possible and develop on that.
I know it's a pain, but you don't have to deal with Mordak the Destroy of information systems.
I work for a medium-large company and a large portion of the user population has free reign with what they can do with thier PC.
I have never heard of network wide problems caused by users at my company.
Perhaps the problem is with your network and not your users?
"Work To Rule." That is, follow the new procedures to the letter.
Obviously, someone will be anointed by the I.T. Gods with the ability to change the registry, install software, etc. Let this person do their job, every time a change needs to be made on any development machine. Don't put off inconvenient changes; in fact, bump up anything that might require registry mods. Make sure all your development tools get all the latest service packs installed.
If there's a requirement that these requests go through some I.T. higher-up approval process, all the better. Get those requests right in, one per form.
You may be amazed how quickly I.T. decides to amend their policies. I'm not proud of it, but I've used this tactic more than once where repeated appeals to reason have failed.
-paul"Irony is so September 10th"
Matt Miller, alt.fan.spinnwebe
It should be fine, assuming that the environment includes everything the developer needs. Of course, if the standard environment includes everything the developers need, then you're going to be getting licenses for a lot of things for a lot of people who don't need them.
Of course, if the people are developers, they are presumably going to develop something that's not part of the environment. If they can install their project, they can probably install other stuff.
Each Foxpro app I used to write used this concept, including the ill-fated windows runtime in it's infancy. All the install had to perform besides a non-destructive copy/unzip was an addition to the path statement, (a check/update to files & buffers for DOS) and a link to run the thing.
OTOH, someone else has already posted that the registry can be protected at the HKEY level, and deeper than that, I believe. I've stayed away from that concept, however, because it's a real PITA.
db
Cig:
ôô
I work in System Integration/Engineering of digital cable systems (headend, transport, set top boxes, etc) and my job requires that I'm capable of supporting any piece of equipment throughout the entire system. Conversely, I am using windows 2000 here at work and do not have rights to install any software or even make setup changes to my machine (this even includes the system time.) As you might imagine, this makes things very difficult for me as I am constantly having to track down a spare laptop or a computer in the lab that isn't being used (and there aren't many of either) in order to install applications that deal with the individual components of the system. The main problem is upgrades to software, this stuff is all brand new, emerging technology and so it is updated at an insane rate, so for instance if I need to update a console emulator for the control console of one of the headend controllers, I have to send the update to the IT guys, file a ticket, and wait for him to have time to install it on my machine. Luckily I have the flexibility of a large lab to work in and I can find ways around not being able to use my desktop in my cube. However, if I was not restricted in such a way I would be much more productive, as the very nature of workarounds is to produce more work, and reduce the amount of work I can finish.
To sum up my opinion: developers should have "power user" rights. They should be able to do whatever they want to with their machines with the understanding that if they mess it up, IT will send it a fresh new image that will wipe the computer clean and start from scratch. They should not be given administrative rights because then they would potentially mess up the network. Having your developers work on desktops with restricted access is like having them work on dumb terminals and results in loss of efficiency.
~ now you know
From everything2:
Soe
(definition) by Webster 1913 (print) Wed Dec 22 1999 at 03:14:44 UTC
Soe (?), n. [Scot. sae, say, saye; cf. Icel. sar a large cask, Sw. s a tub.]
A large wooden vessel for holding water; a cowl.
[Obs. or Prov. Eng.]
Dr. H. More.
What does that have to do with software development?
Seriously, can anyone 'splain what SOE is?
Check this summary:
Companies is putting in a standard. Can't modify registry. What am I to do?
Being a consultant, I run into this all the time.
First question: What do you do that REQUIRES you to change the registry? Does your programming? If so, talk to your boss and get yourself cleared of the policy.
Second question: Is there someone higher in the company than you (higher in rank, not drugs)? If so, talk to them about how to handle the situation. If not, you got to go to System Support and talk to them directly.
Regardless of how you answered, you need to either talk with your boss or Sys Support, not slashdot (which may be why this SOE is being implemented in the first place).
This really isn't a question for ask/., its just a developer griping about his job. Personally, I think this shows a lack of trust (pirating software, slacking off, etc...) or the lack of developer computer competence (need a standard for easier fixes).
Either way, it doesn't sound like the company likes their employees, and I'd take off. But for contractors, you just grin and bear it.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
BOFH rulez... hehehe http://www.coasters.net/~russell/humour/geek/notes _help.txt
"Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech."--Benjamin Franklin
One thing my company seems to have overlooked is the ability to create shorcuts via the wizard. If I right-click and choose New Shortcut (on NT4), the wizard aborts and I'm left with a "New Shortcut" on the desktop. I then have to manually edit all of its properties. How about small applications that only a few people use? I distribute a database frontend made in MS Access. At least one of my users was unable to overwrite the old version. Heck, I can't even add printers myself.
When I was in the Air Force we ran into the same situation. All of the MS boxes that were connected to the Lan were locked down to the extreme that you could not change your background and even the file manager was locked out. (only 2 of our development machines where on their network btw)
After we received a request for an email tool we bitched and bitched about getting the rights to load it on a networked PC as well as SOME info on how our Mail servers worked. They said no so we delivered the product as is. Surprise of Surprises it didn't work right.
We the programmers then got all the rights back that we had before. All it should take is some truly crappy releases from your developers before they give you back at least some of your user rights.
Just make sure that you document all of your hassles before you release it:)
..which just shows that the human brain is ill-adapted for thinking and was probably designed for cooling the blood-T P
My last job, I ended up bringing in my own computer. It was nicer to work off my own laptop instead of the provided development box, and I had total control over what I could or could not do on it. I used it for all my development and it worked out just fine.
If presented with a locked-down environment, I would simply use my own equipment.
A serious developer requires administrative rights to their own machine. Simple as that.
.NET, are they going to include that? That'll bloat the image a lot. Web developer? Lets download a new tool off the net for graphics. Ooops can't. Installer? What, the developer can't even test his or her own installer? ISAPI DLL's? DRIVERS? Oh god.
I worked at a place with an IT department that attempted the same thing, with the exception that you could get your machine marked as a "developer" machine, which meant IT wouldn't support it (which most developers didn't need anyways), but you could do whatever you wanted with it. They saw the numbers, decided too many machines (this is in an R&D group) were marked as developer, so just slated them all for the standard.
In general, IT has shown themselves to be inept at determining developer needs. Does the SOE include Visual Studio? What if you are programming with
If they give you this SOE, then you can't do your work. Play Freecell, take a nap until they fix it. Not your problem.
While working as a colege system administer for a Computer Science Lab. We found that a lockdown of Windows systems is a real hassel and creates more problems then what it was worth. The compilers would bairly work. And most of the time they would crash on simple Apps. The more tech savy CS students because of the intence restriction tried fixing the problems themself and causing the systems to become compleatly useless. While the Next year we decided to lossen the security so the students could install softwair on the system and it was a lot less work in administering because if they did install someting we just remove it. And the Tech savy students actaully fixed the problems every once in a while. We just made sure that they didn't have access to Wipe the computer system clean.
If you really want a good lock down you may want to invest into SUN Rays or other types of Thin Clients. And with conjunction of Citrix (I beleave is the name of the software) you can have Windows on those thin clients. This method will help the lock down of material much easer sience all the administration is centralized and the other dont have access to a system where they can pop in a CDRom.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
As an field engineer for a software company, I spend a lot of time parsing huge log files using perl. Having a locked down pc would prevent me from installing my favourite text editor (Which I purches a liscense for) and the perl lib, which is free. Without out these two apps, I would not be able to preform my job. I also travel nearly 70% of the time, requiring me to get on the net anyway possible, again needing admin privlages.
Though, as a former admin, I support the SOE for some users (like operations), others must be allowed the exception. At one company I worked for, you could sign a form indicating that you would take full responsibility for your pc and that you would not be allowed to use the internal IT support arm. Hmm, a fine trade for admin rights on your own pc.
For me, a locked down pc would only be a tool for frustration, certainly not a tool for productivity. There is NO way I would read through GB sized ASCII logs using notepad...
-JK
I work in a locked down secure desktop environment. Though for developers, we have special login accounts that have more access to the machine. However my normal user account is a normal locked down account so its actually usefull to me to have it so I can simulate actual user conditions. When I need to make fundamental changes to the machine I log off and log back in with an admin account, which is absolutely necessary as a software developer, IMHO. Usually though I can do most development as a normal user, I only need to switch to admin when I need to install something new or add a file to the system in a protected location. Though having a locked down registry is just not feasible because many apps write to the registry to store information. Your app will always need write access to the registry, which is how most secure shops work anyhow. You just can't use regedit to make changes. Our unix systems are locked down as well but again we all have admin accounts we can use when we need to.
Nope -- if this is a problem for you, you have the wrong users, not the wrong policies.
I agree with that, but I don't think it has to do with where you're hiring on the wage scale - it has to do with hiring people who will play by the rules, reguardless of how much more they think they know than the admins. Case in point: Installing Microsoft IIS is verbotten where I work, for pretty obvious reasons. Some web developers figured it was more convenient to break the rules, they installed IIS on their workstations, and wham! Nimda time. So now our network folks have to drop everything they're doing and start quarantine and disinfection procedures. Beautiful.
I know one of the admins, and she's pulling for total lockdown. Break the rules just once and you're on the pavement. The cost of putting out fires (or the cost of being offline for our customers) vastly overrides whatever the individual developer brings to the table - that's her philosophy, and I have to say it makes sense to me.
I worked in an IT dept. that implemented just such a policy. I was not in charge of the IT group at the time. I though the procedures were going overboard but what could I really do? We took admin, root on all unix boxes, and console to everything away. It made developers crazy, having to hunt us down to get to the console of NT machines, and having to ask us to install desktop apps. The best way to deal with this is to whittle the policy away by small steps. Try to get a development subnet with relaxed security rules. With *nix boxes, ask for sudo...to the shells. This way you can just sudo -s and have rootly powers back. There's a decent chance you will be allowed to work on unix machines as long as only the IT dept has root. This is a bit of a climb-down from their crazy horse for the IT folks, who are giving you what you need without specifically subverting policy. As for your Windows boxes, I can't imagine functioning without admin. Try getting a committment from the vendors whose software you use for development that it is OK to install packages for testing. Then presentt his information to the IT department. This way the IT department is spared the responsibility of dealing with each and every install you need done. Maybe designate a few people in the dev group who will have the rights to do this. First and foremost, kill them with kindness. One thing you don't want is a pissing contest with a sysadmin--you'll lose 90% of those on sysadmin arrogance alone ;-P I think enforcing SOE on developers is like enforcing air-breathing on fish. When I finally controlled IT policy, I basically tore SOE up for developers. Now all those other people, that was a different story...muhahahaha
Andrew
One thing to consider is how tolerable employees might be of working under such circumstances. Some people, especially those that actually know how a computer works, get pretty testy when free reign over computers is taken away. I have personally turned down jobs because I was told that I would have no control over my personal workstation, and know other people that have as well. Good, creative people do not work nearly as well in very restrictive environments, and creating such an environment makes it likely that you might lose some of them, and that others might not be willing to work for you to begin with.
SOE isn't even in the jargon file. you wanking techs need to suck it. use real terms or define your new ones. use of obscure terms as if they are commonplace is 100% fucked up faggot talk.
There are plenty of heterogenous businesses out there (I work at one) that have networks that work well, even mixing Linux, WinNT and Win2k. Except when something like Code Red sweeps through. Which wouldn't be a problem if people exercised some common sense and avoided MSFT products like the plague that they are.
A well-crafted lie appears unquestionable - Dama Mahaleo
This is obviously just a power trip by IT, and it will backfire on them hard when productivity drops to an all time low. Shouldn't productivity be more important than IT having more time to play Half Life?
I for one endorse this view whole-heartedly. Lock them down. Tight. Put the screws to the developer's computers.
I mean, every developer complains that the reason their software package is considered "buggy" is because they can't code for every possible configuration of computer out there, right? If only there were some way of making sure that all the PCs out there would behave the same way toward the code...
So here's your solution, folks: Develop in a locked-down environment... then import the developer's locked-down registry configuration as part of the application's install on the user's PC.
It'll work like a charm, almost like it was a custom job or something. And hey, AFAIK there's no software license out there that says the software is guaranteed not to screw up other, pre-existing software on the machine...
Otherwise, Windows XP would never have made it out the door.
Tatsujin
This may partly depend on the type of company you are at. At our company (~1000 people) the basic IT setup is pretty much the same for all employees: basic windows, web browsers, office, email, etc. Developers then have to dump all of their own development tools on. And the tools that are used vary from group to group. Developers also need to be able to install products from partners that we are integrating with. Professional services often work on custom integrations that require 3rd party apps. So machines are constantly in flux, and having to go through IT every single time something had to be added would be a nightmare (for both us and them).
If on the other hand you are part of a small company where developers are given a default install that includes the necessary development tools and you don't work with a wide range of 3rd party apps that change all the time, maybe this would be possible.
We are going through similar growing pains right now. Mostly developers have local rights with the understanding they have to fix most/all of their own problems esp. if they deal with the local machine.
Most of the developers will fix the problems themselves for fear of losing face. Developers tend not be a problem until we start talking about servers and then the turf war begins.
Our real problems in this arena come from general users are have taken to accusing us of thinking they are too stupid to install software and manage their machines. We just don't want to deal with a different rule for each and every employee, a couple of classed is not big deal but, it can quickly become ridiculous. No one every wants to believe that the crux of the problem is that seemly innocuous Brittney Spears screen saver they downloaded and installed.
A balance must be struck between security and the inconvenience of the user. Of course after a break-in, theft, or e-mail virus infection the balance changes.
Go to:. sh tml
http://www.sysinternals.com/ntw2k/source/regmon
And download a registry activity monitor...browse/ do you regular work and then look at the log.
Locking down the registry is a very stupid idea.
I think if I ran development in a Windows environment, such a policy would be required to keep said boxes secure -- since Windows security is so fragile, once I had everything locked down (which means no Microsoft Networking clients, no ports open, 'dumb' terminals only, effectively), I'd make sure it stayed that way. One person misconfiguring printing would leave your fly open.
This is really common in non-development worlds -- call centers and the like, especially.
The reason for the lockdown isn't to try and restrict people from screwing things up.
/.ing etc.
Although IT can be faced with lots of problems from people who screw up their systems by trying to use programs that aren't supported, there are other more political issues.
1) Productivity. I'm sure my company would love to stop people from VNCing, ICQing, MP3ing,
2) Legality. Your company doesn't want you using pirated software, or software that the company may have some licenses for, but not enough for everyone and there mom to have Photoshop installed.
The desktop environment my company uses doesn't lock the registry down or anything, but periodically polls a server to see if all the installed software that is recognized, is accounted for. It apparently has the ability to uninstall software that isn't recognized, but they have (thankfully) not turned this "feature" on.
It's not the keyboard apes that are the problem -- they usally just surf porn and get e-mail viruses -- it's the Know Enough To Be Dangerous types who have some mental deficency that prohbits them from knowing the difference between their home computer and their work computer.
But you should get back to working on that proposal to fire all the CPAs and replace them with trained system administrators.
Implement lots of policies like this, in the development teams, and enforce them strictly. Nothing is less productive than pissed-off developers who hate their developing environment.
On a more serious note, development is a highly creative process, and human creative processes are very easily hampered by frustration, irritation, and disillusionment. The best way to get your programmers to produce top-quality work, IMNSHO, is to make them happy and comfortable. And that means giving them freedom to customize their working environment to the way they like it. Of course, that doesn't mean you should tolerate that slacker who does nothing but run illegal warez servers off the company's network; but one shouldn't go the other extreme and basically chain the developers' elbows to their feet.
People often criticize lazy or incompetent programmers for poorly-written code, but has anyone realized that making your programmers unhappy and disillusioned by imposing unnecessary restrictions on them is another good way of producing poorly-written code?
Alright, enough rant already. My point is, such policies won't fly, and even if they do, it just means that your developers are just mindless sheep who are obviously very capable at producing quality software (*cough*sarcasm*cough*). Programmers are at their best when they're in a challenging environment, and happily so.
Poll Mastah
Read my keyboard review.
My company just expects us to be able to fix our own systems. They couldn't enforce an SOE if they wanted to. I have a Sparc, a FreeBSD box, a pair of Linux boxes and a W2k box in my cube, and people keep asking me why I only have 5. =(
Just so you don't think this is all because I work in a QA department, the developers, managers, and secretarys all have the same setup.
DG
Yes, but who would want to? You'll get only programmers who think inside the box - people who code, but don't do it for love. You'll never get the best programmers if you treat them like slaves instead of valued employees.
Excellent troll. Well done.
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
1 workstation of thier choosing. This should be a dual processor machine, used mostly for compilations, building, readiny company email, etc...
1 cheap development/crash-and-burn box. Useful for remote debugging and so they can continue to work even when they screw things up. (2 cheap boxes if doing network development)
1 good monitor of thier choosing, or the option to get 2 lesser quality monitors for dual displays if they like.. as long as it doesn't get too expensive.
1 cheap network hub/switch (5 ports)
Complete control over at least the crash-n-burn box, and moderate to complete control over their workstation.
This provides the developer with a comfortable environment that they helped build for themselves. It allows the to continue development (and reading email, etc) even when thier app completely hoses the system. It also gives them enough control over the system environment to test applications in real world situations.
I do kernel development, and this environment works out wonderfully for me and the others in my company.
just my 2 cents.
- --
"I Hate Quotes" -- Samuel L. Clemens
This is an ongoing war between two very similarly-backgrounded groups, IT and Dev. Being an IT Manager I know how frustrated some developers get when you try to limit piracy in their group by implementing a "standard" but you need to understand that it's their butts on the line if you get audited.
I've told development groups that I've worked with to let me know when they load software rather than disallow them to do it. This way I just run out and buy a legal copy for the company which makes everyone happy. Developers should be the first to applaud software purchasing since their fellow developers are the ones who benefit from it.
I don't believe that it's a good idea to implement a SOE but I also don't think that everyone should be allowed to run amok installing software. Compromise people...
Let her see if the benifits of it overshadow the costs of 75% of the development team leaving.
I've worked in this environment more then once.
What usually happens is I ask for so many little changes that eventually the IT person in question will 'conveniently' leave my machine logged in as local admin.
Add my my account to the local admin group and eom.
Read my keyboard review.
the anonymous poster below you got it right - it's the people who think they know more than they do that cause problems and need to be locked out.
:)
Besides, shouldn't *development* be done on a consistent environment that's seperate from the buisiness-access mahcines? If people are writing code that needs to mess with teh registry, they should have a mahcine that can do that, but that machine should not really even be on the main network - it should be on a *development* network, and the developer's primary machine should be a locked-down corporate workstation, perhaps even a thin client or whatever. Either way, the corporate workstation should be locked down to protect the users from themselves, regardless of how much those users think that they should be the admin.
Everytime I saw such a move, IT would push to treat developers like any other office clerks. It never worked.
The problem is, IT is solving a real problem. It is impossible for any company to mantain a support force that can handle any and all configurations and prevent unauthorized software installations by people who don't know what they are doing (like in "Hey, my friend just send me this great Back Orifice game, let me install it").
But developers are beasts of a different kind. In the long run, the underpaid IT tech guy will lose. Always. All my NT machines, and I had some during the past years, were mine in every sense. Administrator passwords were cracked, domains were abandoned. New, local domains were created. Linux machines were installed to handle development projects. IT never had a chance, because we were always adding value, they were always a burden.
And we never did it out of despise for them. But because the work had to be done and when work has to be done you can't wait for that same underpaid IT guy to come around to upgrade Acrobat Reader or install Visual Studio beta X.
And for the reasons above, the development boss would always prevail over the IT boss when a complain was send up about those pesky developers that wouldn't stand in line. And I was, at different times, the pesky developer and the boss that had to tell the CEO that "No, we can't play by IT rules unless you want version n.m to be x months late". Can you guess the answer?
Just use one of the Linux distros that boots from CD. You can mount your Windows partition to read and write files, but otherwise, you're not touching their installation. I've worked with a few insane companies, but as long as you have a boss that will back you up, I think this should work fine.
;-)
Bottom line: they're worried about the BSA telling them that they are going to have to pay thousands (or millions) of dollars because of licensing problems. You're booting a CDROM that the distributor tells you to go ahead an make coppies of, if you like. Think about your boss explaining that to some IT manager with a huge grin on his (her?) face
This is not security we're talking about here. This is IT lazyness.
IT people, for some reason, have this overwhelming urge to "lock down" environments so that they can limit the wide variety of things they have to support.
In the end, however, you need to look no further than the whole point and purpose of an IT department in the first place:
"To provide employees of a company with the tools they require to do their jobs".
When IT controls that definition "tools they require" - then without a doubt, the people who are trying to do their job become limited in how they work. Quite often, lattitude in how different people do a certain job differently will affect productivity in a HUGE way.
At the other end of the scale, when the end user controls the definition of "tools they require" - then pretty much anything goes, and when something breaks, an IT group can end up spending a lot of time, effort, and money trying to fix problems and keep things running smoothly.
So what we're seeing here is bean-counters running the show. Bean-counters who set up a corporation as a set of departments who have to compete with eachother for their budgets. This is the most counter-productive load of bullshit any person with an ounce of common sense could experience. The whole point of an IT department is to provide service. It's not to bill someone's department for "number of pages printed" or "number of helpdesk calls" - or "number of bits they transferred over the corporate network". When an IT person (or manger) gets the idea that they need to actually BILL people in their own company for services rendered, then they've lost the whole point of being in a company in the first place, and it looks like they'd really rather be running a separate company that basically is an outsourcing firm.
I think this whole notion is just a load of crap.
Give people machines, give them software, teach them how to use it, and leave them the fuck alone so they can do their job. If they want a different machine or platform - then you should, as a Computer Person - learn how to support that platform and fix problems. Otherwise, get the fuck out of the way, and let people who want to learn about different platforms help your company's employees to do their jobs.
IT used to be called MIS, Management Information SERVICES. Then they started calling it IS, or Information Services. Then, somewhere along the way, they scammed their way into dropping the word "Services". So exactly WHAT is the function of this department now? How do they contribute to the productivity of the company as a whole? It seems that nowadays, they only contribute as a barrier, rather than an enabler.
Another bunch of bean-counters trying to justify more headcount and bigger budgets so they can be little Napoleons in their corporate war to dominate their company. What does that have to do with doing business? Nothing. Get rid of the bums, I say.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
I've see this from both sides.
I've done IT and desktop support. I can certainly understand why an IT organization would want to impose such a thing. We won't even talk about how many times I had to help fix somebody's Win95 installation because they installed something stupid like AIM. It is time consuming and frustrating.
On the other hand, I've also seen this problem from the developer side. IT people do not do development. The tools you need, you need today to do development today -- not six weeks from now. On the other hand, any developer worth having around knows their way around the PC and can install software the software they need safely without involving the IT organization. The flip side of the previous story is how many times the corporate IT organization screwed up someone's desktop that then had to be fixed by a developer.
What we wound up doing was trying to strike a balance: We support these systems and this software. Keep that list open and flexible so that it really and truly does reflect what the users want and need this week. Some software is not supported, if you have trouble with it you have the option of having us scrape it off (re-image, if necessary) or of dealing with it yourself.
The real trick is to find the middle ground. You can go just as wrong in one direction as in the other. Stay the middle course.
expect lots of downtime when you need things done.. IS is usually run off its feet as is (especially in a windows shop)& as developers you are always facing 'issues' when it comes to a lockdowned machine...it can be frustrating not having control over your development workstation
remove NOT from email.
Yeah, blame it on the IT guys. Did it ever occur to you that lockdowns are necessary to prevent piracy? You do know what piracy is right? It's the bad thing that puts guys like you out of business. But by all means, load up your machine with all kinds of crap, then make sure that you call the Helpdesk when you break it.
Slashdot-editor comments aside, certainly NOT ALL 'real' development requires access to the registry, just as NOT ALL 'real' (say) Linux development requires root access or any number of other privileges commonly denied users. For instance, most developers don't have permission to run ifconfig; but how many of them really need it ? Restricting access to the registry makes perfect sense in exactly the same sense that not everyone needs to be in group wheel.
As the sort of person who designs these policies I have to say that there is not enough information to give you an answer, so if you don't mind I'll illustrate with a few principles that I work to.
Surprisingly enough, nobody implements such a policy because they are evil incarnate - you may not believe this, but it is true. The reason that policies are setup like this is purely to save money. And the money is saved because a huge proportion of support time is spent fixing PCs that users have wreaked because they've installed that cute new application.
This leads directly to the BOFH approach to policy - nail it down, and nail it down hard. Don't even let them log on without a letter from the Pope. This is a stage one policy. Support calls drop dramatically, user productivity is zero.
Now, a bit of reality is introduced. People have to use their machines, so against our better judgement we let them log on. And print. And even save things to the hard disk. This is stage two: most people can do what they have to do, support calls rise a little.
Then you deal with the exceptions. Depending on the type of user the general restrictions are lifted. There may be strings attached (such as the screw up and we'll only reimage) or maybe IT will arrange proper support for the application etc.
The point to remember (and so many people forget, especially people in IT) is IT support is not the business. If you are in the business of making widgets, or writing code, then IT support do not do this - they exist to help you do this. They exist solely to allow the business to function more effectively. They are "facilitators" (to use a horrible word). They provide a service.
If that service prevents the business doing things that are required for the business the the service is substandard and needs to be replaced. In this case that service is a policy, and it need to be replaced. I have designed a policy for devolopers, and the policy is
1. You get a standard PC with the standard loadset, and admin rights on the local box.
2. If you screwup we will only reimage.
3. If you repeated screwup we will still reimage, but we will start charging you.
4. All software to be purchased (if costware) and registered (registerware) via {specific person}.
Lockdown policies are loved bu IT departments, but if it stops you (or anyone) doing legitimate work then it is broken and needs fixing.
Listen Mr. Overhead, your JOB is to provide a SERVICE. When overzealous, undertrained, lazy IT directors get to unilaterally dictate what tools are necessary for the people who actually make a product the company can sell, that's a bad case of the tail wagging the dog.
Your job, Nick Burns, is to make it easier for your people to get their job done not to make it less trouble for you. While you DO have a responsibility to keep unlicensed code off your LAN, you also have a responsibility to make the proper tools WORK for your users.
If somebody is more productive with Linux and can't get it networking properly, you should fix it.
Remember, their work pays YOUR salary.
How well this will work out depends greatly on what kind of software is installed and what kind of work people do. They tried it where I worked and had mixed results.
For software developers it just plain doesn't work. There are too many times when you need to install or patch something when developing software. This assumes of course that you are developing for Windows on Windows. If your PC is Windows, but you really develop and deploy on another platform, i.e. PHP on a Linux box, you can get by with just the basics on your PC.
If you are forced into this situation as a developer demand 1-2 test boxes that are not 'locked' so you can try stuff out.
For the typical office application user this can work and save time and money ONLY if everyones PC is EXACTLY the same. The logic behind an SOE is that all the PCs are the same. This can however end up costing a lot of money in software costs if you need to install many applications on all the PC's that only a few people use.
They ran into this problem here. When you totaled up the number of applications used you ended up with a list of 100+. Most of these were only used by about 50-100 people each. They realised that it would be way too expensive to pay the cost of having all these applicatons on 1000 PCs just to keep them all the same.
I'm sure governement agencies, who will exist no matter if they turn revenue or not can work in this environment. Developers are forced to make requests (which can literally take weeks to complete) for software installs, upgrades and fixes. This is fine as it only involes raising taxes to cover the cost.
Many of these governement agencies fund the fight for Microsoft by stating that only Microsoft operating systems (and usually other Microsoft software like Exchange, Outlook) can be used.
I'd bet the DoJ has licensed enough software from Microsoft to pay the lawyers MS is using to fight them.
Thats all. Really.
Bad Idea. 1) Some programs need to modify the registry to run. 2) If an error needs to be fixed and the registry is locked then any fixes that require reg hacks, then the tech has to be given special permisssions to access the registry.
Good idea. Registry modification by USERS , is what is trying to be prevented. This can be accomplished by restricting access to regedit.exe and the file associated with regedt32 (dont remeber off the top of my head).
We have every user within our company, from the CEO/President down to the lowliest data entry person locked down
not only are they prevented from installing apps, they can't change screen savers, they only get the icons for the applications we give them access to. Every DLL installed is on a network drive, they are the same on all servers.
Every one of our 6500 users can sit down at any PC within the company, get their desktop, and all the applications they need. If the application has not been installed on that pc, it will be automatically when they launch it.
Our developers are given the applications they need (or have requested) to work. they work in the same environment as the users. This guarentees the developer will never write something that is incompatible with the end user.
I really don't see what the concern is. What, you can't install After Dark on the company PC? You need a third party application that's not approved by your administration?
Can a production environment really work if developers are given complete freedom?
Where is the line drawn between freedom for developers and ensuring a stable, consistent and cost controlled environment? Granted freedom is needed to evaluate new tools and techniques, but shouldn't this be within the bounds of a defined framework? (If the answer is no, then I guess all the NASA source code discussed in a prior article today must be considered the product of luck.)
http://homepage.mac.com/jcarusone/iMovieTheater2.h tml
Well, MS sure cares about developers....
We did this in the I.S. department. because the corperate dweebs felt that the local IS had no need to have any more rights.
Run a crack program NOW on your machine to get the administrator password. Then add your domain login on your machine into the local-machine's administrator group.
voila, thay can put whatever restriction they want on he domain logins, your administrator group rights override the domain rights.
Works great and lets you actually do your job instead of letting the morons in power screw with you for the reason of satisfying their power trips.
(Sorry, front line IS/IT need administrator rights to fix things quickly... How the hell is the help desk going to log me into that machine as administrator remotely when the T-1 line is down? or if it has network problems..)
Oh and their answer is usually "sent that machine to us and we'll fix it in a couple of weeks.." No thanks, my boss wants it fixed now.
Do not look at laser with remaining good eye.
There are a millions reasons developers can not work on a locked-down system .
1) Developers need to learn and try new tools and technologies. If not, they'll be obsolete and eventually worthless to the company.
2) Every project has different needs for technologies. The overall development management may offer coding standards, and chose some tools over others, but that will never cover everything.
3) The receptionist may be OK with letting the IT group have full control on his computer. Programmers, who often run circles around IT support staff will fight, whine, and gripe if subjected to a heavy handed IT department.
4) IT support staff does not have the skill to perform installation and configuration of necessary developer infrastructure. A short list:
-integrated development environments
-compilers, patches to compilers
-web servers, exotic features of same
-Databases, oracle, sybase, postgres,mysql, access
-middleware
-specialized hardware and drivers
5) Then you have the occasional oddball document in some format that can not be handled by whatever is preinstalled on your system. That problem can be solved in many ways, but a locked down environment will waste a lot of time:
-developer finds and installs a conversion utility of viewer, takes 15 minutes at most
-developer must ask IT support to install such tool. Support staff asks IT manager for permission, developer must argue his case. It manager says no.
-developer hands document off to tech writer or someone else with the peoper software.
6) Then there is trust. If you can't trust your developers to manage their workstation, you shouldn't trust them to write code either.
Testing
-------
The only place a locked down environment is a big help, is for testing. However, an IT support group is not the proper organisation to deal with that. Testing and code release must be responsible for the test configuration and environments. And the locking down here means locking down configurations and changes into source code control, so that the proper environment can be recreated. An MIS nazi with
a bunch of desktop monkeys would not be the right way to solve that problem. By using source code control, test environments would also be available to developers.
I've seen too often that some piece of software only could work on the developers machine and nowhere else, because of the combination of middleware, compilers, configuration and runtime environment was different from the statdard build environment and the official test environment. But locking down the systems does nothing to help with that. Rather the opposite.
Usually a good litmus test for any policy is to ask: "What problem are you trying to solve?"
If the it group comes up with a non-problem, or they can not address the consequential problems, you're in trouble.
-- Another senseless waste of fine bytes.
...is that IT has the One True Canonical Disk Image. IT performs backups of the network drives; if you want anything safe, you keep it on the network drives. Anything goes wrong on your machine, their first step is *WHOMP* reimage the machine.
Also IIRC they allow users to install stuff, make local changes and tweaks, etc. I think they might even have machine-local administrator rights. But if you change anything, it breaks, and you complain, *WHOMP*.
(On an ironical note, I work for a military research lab, and IT is not at all alarmed when users have local admin rights to their Lose2K boxes. It makes things far easier for everybody, including IT. (IT can still do remote admin.))
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I mean, if installing a workstation on the network can screw up the domain (an administrative level function !!)... geez...
when the company i worked for got acquired by yahoo last year, our developers were somewhat flabbergasted to learn that they didn't have root on their own workstations (freebsd machines, yeah!). they had access to certain commands through sudo, and were able to do all their work without any real troubles. i guess it all depends on how good the it support is for the dev org. it seemed to work fine at yahoo!.
Been there done that. This happens from time to time everywhere. It should be viewed as a cycle. It usually starts when the head of IT sees problems due to "too many users have power". The lock-down will then come. Pointing out that this is a stupid thing is usually a very bad idea. Simply wait. People will need the access/power in order to get there jobs done. You would not beleive how fast you can get control back when say you page someone at 2A.M. in the moring and say "Oh by the way I would be have fixed this major production issue myself but I don't have access". I woudn't be surprised if after two or three months that you will find yourself with far more power than you had to begin with.
Here's a detailed account of when my IT department tried that. Note this is on a windows NT network.
;)) began to speak up, and demanded exceptions so people could develop properly and access things that you could only do as a desktop admin. Then other departments started asking for exceptions, because programming had them, why shouldn't they?!
When I was first here, everyone had admin rights to their machine. They could install anything. Then we got hit with a software audit and found too many installed versions of software. IT cracked down by downgrading everyone to a "power user". You couldn't install software.
Well, taking away admin rights took away a lot of things from EVERYONE in the company. My company does software development, but I'm a support person. My job relies on me being able to occasionally uninstalling and installing our OWN software, which of course I have license to use. It also requires us to have certain admin rights to aspects of the desktop machine, as per the installation instructions to complete it, such as windows services. Those were restricted from me now.
Well, the whole situation eventually backfired. I was the first to speak up, but since i was in support I shouldn't need all that to do my job, and upper management never listens to the hacks in a cost center. Then programming (a profit center
One day, they just gave up and when a person asks for admin rights, or has a problem which could be solved with admin rights, IT just turns it back on without question, and all new logins go out with desktop admin rights.
The moral of the story? The developers ability to develop software outweighed the IT departments need to crack down on software, and ITs response was too restrictive.
The REAL solution they should have come up with in the first place that they later implemented: Auditing Software which records what programs are on the machine and return a report so IT knows how many licenses it needs for software, or to police when it has too many copies and check who doesn't need one.
"All great wisdom is contained in .signature files"
Our solution has been to place our development environments withing VMWare sessions. We can move them around, alter them to our hearts content, and not screw up the host OS.
The only software we place on the host are licensed productivity type apps and VMWare. Now, granted, we license all our software appropriately, but not having to worry about reconfiguration of a machine sure is nice.
The "Undoable" partitions are nice when you are mucking around with the registry (or other OS level stuff) as if you screw up, you don't commit the changes. Works great.
We zip up the sessions and archive then backup them up. Restoring an environment takes about 1/2 hour...the time needed to transfer and unzip the VMWare session from server to workstation.
We can change available resources and OS's in a snap.
IMHO, VMWare is one of the best tools out there.
So yeah, one can develop in a locked down environment.
Umm, how are you supposed to compile in Windoze? Requires registry entry.
Question Authority....they probably aren't
Since I'm responsible for "corporate standards" for a big conglomerate, I'll try to answer from the perspective of "The Establishment".
Unfortunately many companies don't house full-time developers and instead prefer to outsource on a per-project basis. Because of this many of them are concerned only with making their app run, at the expense of others. ie - Develop an app that's dependent on IE 5.0 despite the fact many company sites only work under IE 4.0. Bad code all around, eh?
This leads many companies to implement lock-down and I have to sympathize. In a perfect world all your tools would be installed by your Desktop folk and even your development PC would be locked down. In a more realistic world you would have a more open development platform but all testing would be performed on a locked-down PC. A nice compromise since it affords you the freedom to install the tools you need (I think historically no Desktop support technician has ever installed Visual Basic 100% the way a developer wants it!) while still ensuring you are developing an app that doesn't stomp all over settings and files that other apps rely on.
Also, keep in mind that there is (essentially) no user context in Windows that "locks down" the entire registry. What it does is grant full access to user areas and no access to system areas. The only big difference here between "secure" *nix and "insecure" Windows is that in Windows full control is the default. There's no reason why lock-down has to be a bad thing for a developer. In fact it's often a good thing as it prevents the next developer in line from writing an app that will kill yours.
Another vote for 'good troll'. And increased calls for a slashdot troll archive, for these truly are the art on slashdot.
Dave
I write a blog now, you should be afraid.
it means exactly what it says - "if this isn't an FP - then I'll be a (cyborg_)monkey's uncle"
If you would get Fecal Troll Master's nuts off your chin than you would be able tell these things without having people spell it out for you
A looked down workstation can actually be very beneficial to coding. Far too many shops spend most of their labor hours recoding because it "ran fine" on the developer's machine. One very sucessful shop in my hometown doesn't allow developers to run their own code on their own machines. They take every test run on a 486 that just got reformatted and has nothing but a clean-install os on it. Works like a charm.
I work for a defense contractor, so of course our machines are completely locked down. We have to call a sysadmin just to reboot a workstation (HP-UX). However, we manage to develop our software just fine. We even manage some degree of efficiency.
However, I have no experience in a Windows type environment, so I don't know how restrictive that could be.
I almost didn't post because there are so many answers already, but I noticed that no-one brought up the most important point: Without registry access you cannot do 'Micrsoft Component Development' with ActiveX, OLE and .NET!
Creating components using these technologies requires registry access because you have to register the components. If you cannot register them you cannot even run a simple OLE server from the Visual Basic IDE. Forget compiling. Forget C#. Forget C++ for most things. Ain't gonna happen.
So exactly what languages/component sets are you expected to use? Raw ASP? What do you do if a third party component fails to work as expected (as they *always* do) and you have to upgrade? This policy is so braindead I guarantee it will go away, at least for developers, sometime soon. In the meantime I would get my resume out were I you...
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
To put it simple
The more you lock down the environment the less productive developers are.
1. What you must strive to achieve is a healthy balance. Which will prove more productive, adding an IT person and easing up the restrictions or adding a developer? In an NT/2000 developer environment I have found that anywhere from 1/30 to 1/50 is a nice balance.
2. Try to have a well-organized testlab for server and client development, you can install 4 operating systems on each machine and make sure to have images of the partitions. You can store your images on the network, on the hard drive or on a bootable CD. The person responsible for the testlab should not report to IT but rather to developers or testing but with good ties to IT (it might be wise to seat the person with the IT department). The testlab should be on a separate network from a firewall, have its own fileserver and DNS server. In many cases it is a good idea to install some kind of remote control, whether it is a KVM on CAT5, IP or a software product. Try to refresh images on regular bases (once a week), this will force the developers to keep track of dependencies and installation procedures.
Testlabs requiring incoming Internet traffic should always be on a completely separate DMZ (service network) behind a firewall, developers should have no physical access to this network but remote control is a good idea. Developers will have to specify exactly which services they will be running (HTTP/DNS/SMTP) and filtering is required for inbound and outbound traffic, this network should not be able to initiate a connection to the internal network under any circumstances.
3. Create an SLA (Service Level Agreement), this will prove very important when a developer machine rolls over and plays dead. Make sure to make it as clear as possible that any data stored locally will not be recoverable when a system plays dead, you can make exceptions but it must be clear that you are doing this out of the kindness of you heart J. You should also make sure to notise the supervisor of that particular developer that he/she destroyed the machine, it will help to install the operating systems from a partition image since that will ensure all installations are exactly the same. If a machine plays dead (software problem, not hardware) the developer is 100% responsible and if this occurs frequently the supervisor of that developer should take actions to solve this problem since it is reducing productivity.
4. Create a list of categories users fit into and which software each of those categories requires. The person responsable for this is usually the CM(Configuration Manager), he/she should have experience in software developement and administration, be well informed and current on software developement tools. If a developer wants to use a certain tool the CM looks into wether the company wants to use this tool, if there is another tool being used which does the same thing and the pricing. This will help to keep a flexible standardized development enviroment. Users can install any software they like but they can not develop on any software not approved by the CM!
That should get you started
Jarl
I do development at work (US Air Force) in a tightly locked down NT 4 environment -- I can't edit the Registry, change my desktop at all, can't even change the time (and all the workstations are at least half an hour off the real time).
We also have a stand-alone network we use for developing certain applications where we have Administrator access. In addition to that we also have a Solaris network where we have our own development server - rlogin to the server, do what we need with higher (but not root) privleges, and have the SAs (who have root) move code. It's a lot easier to have a locked-down network and still give specific permissions and access in UNIX than in NT/2000.
One of the things that is more important than just locking everything down is accountability - keep an audit trail so you know who is responsible when Bad Things (tm) happen.
24 beers in a case, 24 hours in a day. Coincidence? I think not!
Basically, All IT Folks get full local admin rights. It's the end users who get locked down.
Hopefully one's IT staff is smart enough to follow the rules on licensing. If not they are caught by security audits that run from the login scripts and/or SMS reporting.
We can attach to the machines remotely and login with a local admin id to install software. We use a combination of SMS Remote and pcANYWHERE for dial users. We login, install the software and then logout. End users are so locked down they cannot even change the colors in Windows. Power End users can change colors and other customizations. Kiosk computers are setup with a service id and that id is extremely restricted. There are even training id's for temps, etc. These work in training rooms only. Training rooms are network isolated and filtered.
Developers, Admins, etc. Have full local admin rights. Exceptions are made for WAH users (work at home) so they can at least install local printers etc.
Yes, it makes it harder to fix problems when something goes wrong. We even renamed the local administrator account and randomly assigned it a cryptic pw. Then logged all the passwords to a secure database. If we need to redo the broken security model we have to login to the database with a special id and feed it the workstation name. Then it spits back the cryptic password. We then can login, repair the security model and then the normal admin id's group.
We use an SU.EXE utility for NT/2000 domains that allows us to SU to the admin id's. Every tech has two id's. A normal one and an admin id. Domain Admins have a third id. Everything a domain admin does is fully logged and recorded for security purposes. The midrange Unix platform is setup in a similar fashion.
We have an automated answer file based installation system (home brewed) to install approved software. If you login as an Admin you have more packages available (licensed stuff). The regular users only see the site licensed stuff.
There is what we call a DLLStack that installs after each approved package and it forces the system DLL's to the right versions for a given tested and approved NT Build. It won't let you install a package on an older build if the DLLStack would break your system by downgrading the system DLL's. When this system works, it works well. However sometimes a user is give local admin for some reason or another and they download and install stuff from the Internet that is not compatible with the DLLStack. So the next time the stack is run their computer needs to be rebuilt...
What really stinks is all of the above is home brewed and engineered when it all exists in Unix/Linux systems and is a whole lot easier than setting it up on NT. We use a lot of third party utilities with NT that Unix/Linux have had since the beginning. i.e. su, kix32, sms, etc.
Financial Institutions (in my experience) have been implementing 'lock-downs' like this for years for security reasons.
When developers need to install/upgrade/whatever something they need to clear it with his or her suprivisor. This is usually as simple as: "Hey Bob, I need to install Blah v5.1" And Bob says "Sure thing".
Perhaps this could bring about inefficiencies if it is inconvienient to speak with your department head, or gain permission. But if this is the case you are probably already working in a horribly inefficient environment, so what is a few more hours?
If the developers are the mindless ASP or VB trolls, or something similar, I am sure they can do just fine with the Office Package and Visual Studio and not needing to configure a thing.
However, if those are your developers, you may have other problems....
All that aside, in my work place that would be totally impossible - almost as impossible as it is explaining this to a suit. Heh. We are expected to run the whole show, fix any problems that arise and come up with new and better solutions, fast fixes and generally run the show. This includes, for the first thing, a lot of downloading and evaluating new software, be it IDEs, databases, browsers, languages, whatever to get the job done.
If we needed to wait for permission or some IT administration dude (that knows about 2% of what we do about the machines anyways) we'd simply never produce a thing. Ever.
Also, add in that developers are often hackers, and as such, playful, imaginative, curios and creative - actually, that is why you should pay them at all, because of those qualities. To me, it seems you are trying to kill that very thing that makes them tick. Bad move.
Treat your hacker right. - it pays off.
Perhaps if you're writing code for a small portion of a much larger project you could get by with a locked-down machine.
But if you are responsible for making sure the program installs and runs on a standard Windows computer, there's no way that you could do that on a locked-down machine. You need to test on a machine that's just like the end user's.
If your company decides to do this I hope they can take a productivity hit.
Some assumptions have been made by me here:
Your company has more than 500 employees
You are developing for internal customers (ie you are in IT developing for the rest of the company)
Windows is the primary platform for users and servers, perhaps supporting some other platforms on the server side as well (this type of company would likely be using Sun or IBM)
The biggest requirement is that there is a dedicated IT resource for (about) every 5 developers.
As far as registry restrictions, that's lame. Probably means that you can't run regedt32, which means you can't do your job. If they want to lock down the registry, do it by permissions to modify the different hives and keys, not by restricting tools.
There are definate benifits to the company if this is done correctly. Code maintainability being the foremost. If there is developer turnover, then using a common toolset is going to greatly benefit the ability for the new programmer to come up to speed on internal development. Also, all developers on a team can benefit from one another's insight on the best tools - demos should still be allowed to be loaded, just by the IT guy that is monitoring all those damned DLLs etc that you don't want to.
Remember, Windows is pretty much the only environment that allows you so much "flexibility", which is also why everyone bitches about it's stability. Developers on *nix and mainframes are much more likely to be using a standardized toolset for corporations.
The other side of the coin: restricting access in a windows environment is a tough job, costs a ton of money, and means that the IT group has to be GOOD. Really good. Otherwise, morale is going to start spiraling downwards because employees are hindered by the change instead of helping.
I can smell a troll from miles away. Good try luser.
-- Another senseless waste of fine bytes.
Now it looks like we're locked out, from the kingdumb, but ITs mucho 0k with us. Looks like some further illegal monopoly maintenance. We thought fud was dead?
Only posting as AC because I need to from here...
My location already has the registry locked down. Installing new apps first requires a proposal to our Architecture Review Board. If they approve (I say if because it can be a chore) then the product can be passed to our integration lab for an image. After all of this, eventually I will receive an image on my machine.
Very slow process, but apparently the upper management deems it worthy. No need to point out the expensive costs they are paying to be paranoid about their developers! I only want to check my POP accounts and IM people anyway. What's the harm in that? Installing free utilities on my own should be permitted, especially if it would benefit my productivity. But who has the time to make a proposal so that I can use simple utilities?
I've worked in big networks where all the machines are locked down when you get them. People doing development work filled out special paperwork to get local admin rights to their desktop. All apps (including compilers and such) were WinInstalled so all we had to do was leave them an CD image disk for their HD and if they screwed it up. They could reimage their own machine. All files were stored on the network so it didn't matter what they did to the poor things.
We ended up with two boxes on our desk. One "business" box with browser, email, MS office and one development box on our own net connected through a fire wall to the corperate net. We can do most anything with our dev boxes as long as it is not pirated software. We use a trip-lite box to switch our single KB/CRT between boxes (just cant 't copy & paste between boxes). Only problem is wider net access out of the dev net requires a ton of enterprise crap (Novel, etc)
Microsoft has a product that helps the Admin types keep you from controlling your machine. Its called SMS. I pride my self on my expert techniques for evading its control.
Here's how: SMS creates a folder called C:\SMS (IIRC). The trick is to deny all rights to these files except LIST. If you try to delete them, SMS will reinstall itself. If you just remove everyone's rights to execute the files, the program will just fail.
But how do I change permissions on the files if I am not an admin on the box? Well, you can't. But if you know this type of stuff is about to start in your company, then create a local admin account. You can be sneaky and name it IWAM_machinename1 or something official looking.
If you can't do that in time, then try the following: Get TomsRTBT disk (http://www.toms.net/rb/) and load up the NTFS drivers (I imagine a bootable linux disk will do), copy off the SAM file, and use l0phtcrack to get the local admin password from the box.
Yummy!
there are 2 kinds of people. those who divide people into 2 kinds, and those who don't.
to install end user desktop applications...
I presume this is a troll, but nonetheless.
Firstly let's get something out into the open: The people who work in IS are usually the bottom of the skill rung. Sorry to say it, and there are DEFINITELY exceptions, but everyone who works at a company where the people who seem to know the least about managing/securing and running systems happen to be in IS/IT please raise your hands. Yup that's just about all of you. IS/IT is the fallback position for people who couldn't cut it in software development the majority of the time. Again there are exceptions (and those exceptions are absolute gold for their company), but I'm talking about in general.
Given that, it is absurd that developers, who often know more about the OS and reinstalling/etc., have to sit on their hands waiting for some moron from IS to come and install software for them, etc. In my company the development group (with a couple of small exceptions) absolutely eclipses the IS group as far as OS management skills, yet humorously enough along came some new SOE policies : What an irony.
I view SOEs as two things:
-A make work project for a group that is threatened with downsizing. Force people who have absolutely no use for your "skills" to have to use you through company policy.
-A power grab. I've seen IS people who feel grossly eclipsed so they make themselves "important" through policy. This pretty much relates to the first suggestion, but it's motivation is slightly different.
Organizations claiming that they do it for "licensing" reasons or whatever are fooling themselves, and the paradox is that the increased policies increases the culpability. It's like the old situation where bulletin boards had no liability for the content...until the day some wanker moron decided that he'd "reduce their liability" by censoring select posts, yet instantly the bulletin board operators are 100% liable for every single thing that is said because they have taken baby steps towards censorship. Blah.
I can understand the IT department's headaches from users who screw up their machines, but developers are typically smarter than the average Outlook user (hopefully??) and can manage their own computers just fine. Computers as company property and subject to coroporate/IT policies is one thing... coding with my wrist chained to the chair is another.
I wholehartedly agree with your post. I also particularly like this last section.
The fact of the matter is that most developers are more experienced and more knowledgable about the setup and usage of their machines than the IT staff is. I've always found it to be ironic that some 19 year old moron with no formal computing education and no previous work experience could be empowered and trusted to have Admin rights on an NT/2000 system, when the developer who works on it cannot.
I've been in that kind of environment, and as many folks here have pointed out it KILLS productivity. You instantly create a huge bottleneck in your work by always waiting for the IT guy to come and run a command for you, or install an application. It sucks. It sucks. (It's worth saying three times.) It SUCKS!
Take care,
Brian
Web Hosting Solutions running on 100% Linux Servers...
Well I'm not a developer, I'm a graphic designer and I can't work on a locked down NT machine with any degree of effeciency. There are to many non standard apps, shareware, plugins, etc that I need to work effectively.
If I had wait for IT to get around to installing all that stuff I'd never get any work done.
Not to mention the fact that Adobe apps work like ass on windows, and frequently need to be reinstalled.
Besides it's trivial to crack into NT if your at the workstation.
I was being called non-stop as people had managed to screw up their systems by opening random attachments, installing tons of crapware like AIM, RealPlayer, and doing various other brain-dead things.
Shouldn't YOU be scanning attachments for known viruses on the way in to your network? Why is AIM and RealPlayer "crapware"? Because it might lead to (gasp) fun at work?
Of course, since they had no idea how to properly set it up to behave on the network, they caused the whole NT domain to get utterly screwed up.
Unless they installed it with a bad NIC, broadcasting bad packets, Linux can't "scew up" a whole domain. Correct me if I'm wrong, Linux people. The only way a domain can get hosed is if the PDC gets taken down. How did little ol' Linux do that?
I'm sorry to say it, but if you want to get any work out of a business network, you need to protect users from themselves, no matter how savvy they think they are.
As a person working at the director level, you claim to know more about computers than your technical employees? You are management, friend. It was people like your employees that wrote Windows, and the tools you use to lock down their dev environments. What you need to do is call a meeting, set down some action items, and request some deliverables or something that managers do. I had a manager like you once. He thought that setting up a web server took Exchange down. This was in 1995, and he doesn't work there anymore. Learn from his mistake, and let your people free.
If you fall off a building, go real limp, because maybe you'll look like a dummy and people will be like hey, free dummy
Vmware would be the ideal solution. Lock the host OS down to reduce your support costs, and then provide a default partition file to your developers, so that when they screw up their virtual machine, they just reload the file and continue hacking... Everybody is happy.
Remembering your name in the morning is already a good start...
Back when I was in high school,I ran tech for my school paper (we had 30 ppl on production staff). Anyway, the REAL sys admin (read asshole) never wanted to give us access privileges to do anything useful that we needed to do. Rather than wait forever to go through administration, I decided to quietly just monitor his computer to maintain a current list of admin passwords so I could make what changes I needed to any computer so the paper could work. However, I don't think this strategy scales up past high school.
Anyway, if access conditions are too draconian, it's impossible to even do basic stuff like running a school paper. EG., we needed to add jpegconvertor on some machines to do fast conversion from tiff to jpeg for the online edition.
Development environments (as I have experienced) require a larger width of tools. Indeed, if you're program itself deals with the registry, this appears to make things much harder to test except on specific machines. If you're doing less low level stuff, only having access to basic user land may be sufficient (can you still install programs but under a user level instead of admin level?)
On the otherhand, my university's large distributed unix environment would be a good example of a system which has a strong level of security and supports development. This is more of a function of the general root user permissions distinction than anything particularly special, but we have an absurd number of machines mostly running solaris and all having access to the same afs file system. They're fully loaded with everything one can think of, and if you need something, in standard unix style one can get a tar.gz, build it oneself, and stick it in the local directory. Maybe even make a ~user/bin and add it to your path. People can change permissions on their OWN afs directories/subdirectories via afs file system controls (in addition to basic unix permissions) so that groups have shared directory space etc... etc....
I've been out of windows too long to be honest to know how this compares on teh details (if at all) to a win2k environment.
It seems to me the main purpose of the proposed lockdown is to increase reliability, lower support costs, lower possibility of software piracy, and increase security. 1&2 seem fairly moot to me as as a developper, one hopefully isn't running to IT every week with some new software problem. 3&4 seem more legitimate company concerns that can't be instantly answerred with developper knows best. 3 involves trust between managers and developpers and 4 involves competence and continual diligence on the part of developers.
My personal opinion is that a two tier system is neccesary. Back to my uni comparison, if I develop stuff on the university system, it gets backed up everynight etc... etc..., but I can't test software on restricted ports etc...., so I could run that on my system. Do most work on computers supported by company infastructure but have other privately supported ones available for anything else.
Ok, I've rambled enough.
I give all of our developers local admin rights for their PCs. They are responsible for all software installations beyond the OS -- they have to come to me for the [shrinkwrap] software first though -- and they're responsible for fixing anything they 'break.' The policy has worked very well for me and the developers as they're happy that they can do their jobs without having to come to me for anything and I'm happy for the same reason.
In the case of the original article which is talking about developers, than yes, but as a blanket statement, no way. A significant amount of "business people" are not bottom of the wage bracket, quite the contrary, but that doesn't make them computer experts, and invariably they are going to install some program that will screw something up.
Most IT departments don't really realize how much they're not doing for their users till they lock everything down.
They did this at a previous place of work, and it lasted about a month before they let most of us take control of our own machines again.
At first they thought we were doing some kind of protest, since their workload went up significantly after implementing this. I remember one frustrated IT guy complaining to a co-worker "but you've never had problems before!" and the co-worker replying "Yes, I did, but I usually just fix them and keep working, now I have to call you every time anything goes wrong."
After a few weeks, most of us had Admin privlidges back on our own machines, and then a couple weeks later they offically ended the program.
There's a great solution to problems like this: outsource your IT support to a company that knows what they are doing. As other posters have mentioned, IT is probably not the core of your business, it exists to enhance whatever your real business is. Because of that, it's a prime candidate for outsourcing. Other companies can probably do it better than your homegrown IT dept.
I'm making some assumptions here:
1. You're in a relatively small company ( 500 employees). Large companies probably need full in-house support.
2. You're not an in-house IT person. This question was from a developer, and we're already operating under the assumption that there are draconian IT policies in place that need to change.
A good model is having a small support staff on-site, supplemented by the services of an IT consulting firm. Of course you don't want to call the firm every time someone forgot their password, but likewise you don't want in-house IT setting up your new active directory.
The advantage of outsourcing is simple: your company wants to pay as little as possible, so your in-house contact will educate users about not polluting their PC with Webshots instead of implementing some total lockdown policy. Hopefully your consultant will understand the balance between controlling a system and user freedom. But because your company wants to pay as little as possible for support, they will actively work to prevent problems from happening.
I love to read all the "why don't you just quit" traffic, or perhaps the "wait until they're done and hack in anyway". I especially liked the "BURN YOUR BRIDGES" fellow. What children you all are.
I work as an I.T. Director for a medium-sized web development company. I tried letting the developers have admin rights, and it ended up a nightmare. Each dev wanted his/her own text editor, own IM client, special this, special that, to the point that no two dev machines were alike. They were completely unserviceable from an I.T. standpoint. And when a developer wanted tools we didn't have licenses for, well, THAT DIDN'T STOP THEM, they just downloaded a warez version and used it anyway. I.T. would only find out if there was an audit. Policies were ignored, and email pleas to just keep I.T. informed of system changes went ignored.
I got news for you kids out there who think being a developer is like being some Picasso or something: wake up. You're in a business, and if you don't like it, you should file for unemployment. If you create a software violation, people like me in I.T. have to answer for it when MY PHB asks why I allowed this to happen. *I'M* on the line when some stupid developer downloads the latest beta of some neato-keeno tool that ends up compromising the corporate firewall, or flooding the network with spurious traffic, or screwing up the code management systems.
I fixed the problem in my company quite easily: I said I'd be absolutely happy to relinquish admin control to the developers if they could just prove one instance where they couldn't perform their JOBS without these admin rights. No one could make that case, although plenty bitched about not having AIM, ICQ, or Realplayer to play around with. Needless to say, they didn't get admin rights. Development still got done, projects got finished, and the devs got over it.
If there are any I.T. people out there, stand fast and don't put up with crap from developers. They seem to think they're above everyone else out there. Make them prove their case before giving them something that you KNOW they'll abuse.
I work over a VPN from home, my nifty new Win2K system is locked down to the point that I need to bring the box to the office for updates. Since moving to this locked down environment (win2k vs win 95) lots of other problems have come up, for example, no-one can currently change their domain password when prompted, they tell us to just reuse the same password or we'll get locked out. 4 months later, this BIG fortune 500 company is still 'working on a resolution'. Outlook will not get new mail until you switch out and back into the inbox folder, and then all the messages you got in the last hour or whenever suddnly appear and the mail notification sounds-(what nerve!!!)
after 3 years of being good and not installing unauthozied apps, now I loose realtimeish mail and our whole companies network security policies , like changing a password every 90 days cannot be enforced...Long Live the Microsoft "digital nervouse system" yeah right!
"The Most Fun Possible on 4 wheels" is at SunBuggy in Las Vegas
Not to mention that something as simple as stopping and restarting the development version of IIS (for NT WKS) requires local administrator access.
There are a number of development tools that are free for instance that may write to the registry. Secondly, windows has some architectural flaws that require administrative access to do many common functions. Any developer running IIS on his box will require adminstrative level access.
Why ban linux? The liscense is that its free (basically as in beer and as in liberty) and secondly it cuts costs.
I think you should re-evaluate what you're really trying to do. If liscense compliance is your goal then I don't think this is your solution. This really will thwart your developers, especially VBers who are constantly registering and unregistering controls, etc and web developers who need to test on their box.
Perhaps you should go the other way and use linux for your developers and servers. If you standardize on free software, you can be virtually assured of liscense compliance. Obviously this will only work if you're commited to the web.
The obvious response is to try to talk them out of this misguided path. Failing that, there's something more to do than putting out your resume (I'd still put out my resume, working for bad management sucks, but there's fewer instant jobs out there lately).
If the policy requires your development machine be locked down, let it be locked down. Everytime your job requires you to do something you're not allowed to do (change a registry key, install the new compile of your program, etc), follow whatever procedure they have in place to modify your machine.
Document the time you spend filling out the paperwork, sending it to the systems administratiors, talking on the phone regarding the request, waiting for a response from systems administration, getting them back when they didn't install your program properly, and so on. Then, when they complain that your project is behind schedule, you can show them that 80% of your time is spent complying with their policy rather than doing the work you were hired for. That will go a long way towards getting control of your machine back.
----
Open mind, insert foot.
On the other hand, if you're doing bleeding-edge work, or writing hardware drivers, or developing system software that needs to perform privileged operations, then you really can't do this. Or, even if your development work doesn't _strictly_ require root/administrator access but you nevertheless want to maintain a creatively charged group - i.e. if you want to write a killer app that will change the world, and you need people who are as much visionaries as they are programmers - then you absolutely must work hard to remove all barriers to accomplishment from their environment. (You must also remove any sharp objects or dangerous items; for example, scissors, staplers or any access to production servers.)
In practice, the majority of development shops need more of the former, less of the latter. But in the cases where you do need visionaries, you really need them. And they are very hard to find, very hard to keep, and very very hard to keep focused on a task. The last thing you need with these people is another headache, so just let them do whatever with their own machines and hope to hell nobody ever audits their licensing compliance. Try to remember that if you can't get a straight answer out of them, an external auditor will most likely be totally baffled. You can hope, anyway.
If you make your money in something other than software, and your programmers act like prima donnas, get different programmers. Internal-use software development never requires this kind of visionary status. Whatever your current staff may be telling you, you can build a decent development team using nine-to-five, do what they're told staffers. And you can do it with locked down boxes.
-Graham
All I have to say is this:
If I worked for you, and you implemented such a policy, I would resign at the earliest possible opportunity. Expecting developers to work with completely locked down machines is ridiculous.
// TODO: Insert Cool Sig
Our setup here is such that the boxes are locked down but we have standard form and procedure to get admin rights on any box given justification. I don't know a local developer who doesn't have root on their box.
Support is limited to standard apps and reinstall is by re-image. We develop to a non-pc platform and so developers have a workstation either on their desk or they use one of the shared workstations.
Linux is tolerated but unsupported. I and a number of other support the linux users as peers. We help out with printing, NIS, NFS and other issues like burning CDs. Interestingly enough our boxes are heavily used by coworkers for burning cds from the nfs shares, analyzing mpeg, as caching proxy servers, reliable name servers, etc.
Our IT department is mostly just for windows support. They are converting all mail servers to exchange, moving to active directory, etc. The UNIX development environments are kept on life support but only 1 guy has much of a clue and he doesn't care any more.
It is silly but at least there is a way out, they tolerate non-standard setups but they are all peer supported.
Duncan Watson
I write in Java using a text editor and I haven't written to my registry in months.
In fact, when I first got here my system was locked down like a prisoner by accident (they thought I was an intern...god I hate being young) and I didn't notice for four months, and then only because I installed JDK 1.3.1 (which wanted to change my JavaPath).
Yes, Java CAN interface with the registry, but it's a heck of a lot easier to use object dumps and ini files (in xml of course). And since things don't need to be "registered" (more trouble than it's worth) due to the namespace and classpath, you end up with a very nice sandbox development environment.
I wish this effing COM object I've been trying to teach how to use the network all morning were written in java...
Hey freaks: now you're ju
http://www.deepfreezeusa.com
Deep Freeze is a very interesting application for locking a system down. You can modify the system to your hearts content but rebooting results in the original system and data being there. It fakes any system write and instead keeps a copy of changed things in memory. You can have certain drives unfrozen so people can save their work though. Although it is aimed at educational places, it can be used in a business environment.
Ok, I give. What the hell is an SOE? And shouldn't stories expand the acronyms they use at least once?
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Get a second machine and tell them it will be for your personal use and never on the network. Set its IP address to be the same as the SOE machine. In the morning when you come in, unplug the SOE machine from the network and plug in your personal machine. When you leave in the evening, make sure that the SOE machine is pluged in for back up, nazification, etc.
Just make sure to keep your ear to the rail to hear the approaching hoards of IT folk around upgrade time so you can swith fast...
That is all.
vmware
Remember this?
If the new policy conficts with your project goals, send a memo to the project manager (or higher if that's you) explaining that you cannot achieve your project goals under the new policy. Let the higher-ups decide whether the project is more or less important than the policy.
In short, this problem is not of your making; there's no need to make it yours.
I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve. BB
I have a friend who's the head of development for an extremely large corporation. The IT department went around and locked down everyone's computers, just like you mentioned, but he was able to convince them that a locked down machine was of little use to a developer, and they eventually agreed.
--It's Pimptastic!--
This is a much more extreme situation to my last place of work. There, they objected to us re-installing the OS. At the end of the day, the engineering department got excluded from the SOE.
Most software engineers can trouble shoot software problems much better than an IT department, or if they can't, a co-worker can. We only ever expected hardware support from the IT dept. If I needed to reinstall the OS, they would take the machine away for 4 days, and then I would have reinstall all my apps once I got it back... or, I could reinstall everything and get back to work in one afternoon. Both departments benefit in the latter situation - all they have to do is re-add the machine to NT domain.
Generally, software developers need to be much more flexible. They need to try out new technology earlier on. Their software needs to be tested on these platforms before they become standard. There's a continuous need to install and uninstall software. A registry lock-down is stupid: how can you develop a piece of software that uses the registry (a very standard thing to do with Win32)?
Can developers work in a completely locked-down environment? It depends:
Is an ssh client installed?
Is an X server installed?
When every developers starts calling support 4 times a day just to change a setting, they'll get a clue.
The Kruger Dunning explains most post on
It may be time to consider a position at a different company. These kind of hostile relationships between the developers, IT departments, and others are usually indications of serious internal communication problems and if a company cannot communicate amongst itself imagine what kind of job it must be doing with its customers.
The problem isn't the locking but the environment.that the users are used too.
... really. In a decent configured unix environment you're used that everything is locked down. Developers have :
* their homedirs where they can mess with whatever they want,
* some cvs/clearcase to manage all their development stuff
* whatever tools they need will be available through network mounted dirs only handled by the IT department. (You still want this fancy tool you like ? No problem, IT-can install it and it will be availlable to all your co-developer on all machines.)
So I can't see why something simillar wouldn't work for a windows environment.You could consider installing also some less workrelated stuff on the network (which wouldn't realy harm. e.g. mp3players,...) Many people will actualy be pleased that they get all the stuff without having to mess around themselves.
There are really three sides to this.
First, the SOE reduces admin time. As someone said before, if a system melts down WHOMP ! you get a new image ghosted on. And this isn't because the admin is lazy. Most of us are spread so thin we would do a much poorer job without shortcuts like this.
Second, it helps control Software Licensing. Yeah it's a pain, but a profit making concern can't go around breaking copyright laws forever.
Third, it prevents the user from installing Malware. Some bozo installs a backdoor and you've been had. (although hopefully your virus scanner finds it)
But you *can* have it both ways.
One solution I'm surprised noone mentioned yet is multiple firewalls, with differing rules. You can have mutliple networks each firewalled off from the Internet separately, or one behind another. For example, you can have one system on your desk for development, and another for accessing the ERP system. The two applications should probably not happen on the same network.
Even if it were possible to get my work done without any drop in productivity, I'd never agree to work under those conditions. I'll never forget the time a co-worker of mine caught the head sys-admin attempting to just install virus software on his desktop machine. He ripped the sys-admin a new one at the top of his lungs for everyone to hear. I laughed over that for weeks.
He was using his example to illustrate his point, not to suggest using Linux to the guy who asked the question. What's more, he explained this to you in plain english. So please stop being a fuckwit.
.sig, fix the spelling, or fix your severe lack of intelligence.
Oh, and I'd advise you to either remove that Mensa link from your
himi
My very own DeCSS mirror.
Simple solution - development boxes go into their own OU, and thus programmers have full admin rights to the development servers, and their own workstations but nothing else.
However no-one gets rights to uninstall anti-virus software.
If you really want to be strict, and, as the topic seems to insinuate, that you're writing registry entries, well frankly, the software that you're writing should be using a particular registry tree, which developers can be given access to, usually HKEY_LOCAL_MACHINE\Software\your company name and HKEY_CLASSES_ROOT if you're writing COM objects.
If you're writting Windows drivers, well then, you need full rights.
The developers whined when it was implemented until asked to prove how it stopped them working/developing. It didn't. They shut up. They tried the same argument on the SQL DBA saying they all needed SA access, when all SQL requests should go trhough the DBA on their teams.
Frankly, once you have a standardised development build, exactly what software do you need to install and uninstall every day?
umm....i have to say this - youre a MORON. the least you could do is allow people to save files on a network drive, lock down normal (non developer) boxes and re-ghost them if theres a problem. For developers drop em on a seperate firewalled off prtion of the network and tell em that their machines get re-imaged if IT is called in for support. Also ensure they save their work to a seperate firewalled server.
who the hell made you an IT director if you dont know about such basic stuff ? was it due to your incompetant PHB skillset or did you lie extensively on your resume ?
That's my advice. There are plenty of jobs available for a developer where you can use whatever OS you want and install whatever software you want. So why would you want to work for a company that doesn't care for the well-being of its employees. I mean, no Quake??, that's slavery!
OK, this thread is overrun with people who are obviously developers, to which I have to say, I'm sorry, but you are flat out wrong.
The middle ground must be reached. Certainly, CERTAINLY developers can't work in a fully locked down environment, but when they are using shared resources, they can't go running amok either. To many time I have had developers with free reign knocking other users off the network by screwing up the IP address of a box, taking out servers by "accidently" chmod -R 777 / on a *nix box (as root) and other ridiculous money costing, productivity killing endeavors.
On your own workstation, windows or UNIX, I am a proponent of the here's the image, here's admin rights, and here are the shared IT controlled resources that you and OTHER PEOPLE depend on.
If you screw up your own box, we will help, by getting you a new box if I can't solve your problem in 15 minutes.
If you so much as touch a shared resource that I'm responible for, other people depend on, and you DON'T OWN, I'm gonna come for you.
You see, developers often know how to solve a problem, but don't document it, don't know or care about reproducing it, don't have backout plans, don't schedule ANYTHING, don't TEST it and so on. They start hackin' until it works. Which is great, on YOUR workstation, but on a shared server, it's a no go.
To all the "IT/IS people are the failed developers" I invite you to kiss my ass. I am a system administrator by CHOICE. I do not code, I do not wish to code, I will never be a developer (well, never say never...), other than what I need for my job, to do my duties.
I see many developers who feel that they have the MOST l33t skillz in all forms of computer usage, but let's get real. I've seen what happens when they go postal on their own machines, I've helped them in the wee hours of the night unf*ck a critical development system that they nuked right before a release, hunt down a missing library, find that pesky header file, fix the permissions on this or that, and do it correctly, and so on. I've taught them lessons on every aspect of UNIX and linux, LDAP, SMTP and email, perl, shell enviroments, X font setup, color maps, kerberos, ssh, security, user management, system setup, searching the internet, drinking your coffee black and more.
IT is the most underappreciated field in business today. We only are noticed when we won't let you do someting, when something breaks, or when you need a general scapegoat. When everything works, we get no applause, no pats on the back, no financial bonuses, no parties and no little plaques that say "Great Job"
another BOFH
"spend all day fixing the exact same user errors on a daily basis"
You know what I do after only one of those days? Make a script that fixes it automagically. Problem solved, and more productive.
It works fine, because eventually all the users who care (read: developers) will sneak in laptops of their own and do all their work on the laptop. I've seen it before, and it'll be seen again.
I have worked in both types of environments.
I worked at a national lab for the federal government (managed by a third party contractor). They had an aprroved list of software that you could install and use. We were working on some new 3D tools, and were developing geometry, textures, and environments. It was a pain getting permision to run un-tested software. And don't get me started on the procurement hassles. Yet inspite of the hassles you were able to develop, just not at the pace and with the efficeincy that you would like, while you sit waiting for the crushing wheels of beauracracy.
I have also worked for other shops that let you install just about anything you wanted. These environments though are different from working for a national lab. At the national lab the IT department had no guarentees that you were proficient enough to fix whatever you might break by installing software. At the pure software development shops, it was understood that you were capable enough to install, unistall, and fix software at your own discretion and you only bothered IT when the hardware broke.
In my opinion it is easier to get your tasks done in the more open environment.
Fly Fish? Participate in our forum
This is exactly the problem I'm talking about. The egotistical developers and other halfwits who think they know more than the IS people going in and trying to handle things for themselves. These people are very rarely as smart as they think they are, and too often screw everything up, but are too egoistic to call IT. So then I have to spend a day trying to find the source of a problem, only to find out that the loser who screwed things up knew about the problem for a week but "forgot" to tell us about it.
In my experience, developers generally have more competence with the OS than most IS/IT employees. Again, there are lots of exceptions, but in general. In general if you went to any average company and quizzed the IS department and the developers, in the majority of times you'll find the developers have more knowledge about security, configuration, pitfalls, etc. Why? Because IS is usually the career of the "Devry IT Career" graduate, or the person without the ambition, passion or intelligence to succeed in software development. Yet again let me say that there are exceptions to this, but the rule is that it's generally true. Are there developers who are idiots? Absolutely. Are there IS workers who are geniuses? Absolutely. Are either the norm? I would say no.
And what is with all the troll accusations? Is everybody here really so small-minded and petty that they dismiss anything that they don't want to believe?
I can see your point (if you work in a company with shit HR and the developers are a bunch of VB morons playing with settings), but your post seemed very confrontational to the Slashdot-type crowd, hence my suggestion that it may be a troll.
The question is not "can a developer work in a locked down environment"? All environments are "locked down" to some degree; unless the project is to create a new environment.
The right question to ask is, "does the developer have the ability to do what he/she needs to do without restriction?"
Whenever I need permissions to do something on my machine I immediately start whining really loud and repeatedly emailing our IT department, calling people, etc., in other words making a big noise. I shouldn't have to but what can you do?
Don't post on slashdot. Get back to work.
the company will be unnamed, but it is multinational and deals with lots of $, so such a system is not merely an issue of overzealous, over-anal management, but one of government standards and important security. in said environment, development can be frustrating. here is how i adapted.
;-) it is very frustrating to develop on a box you don't even have rights to the C: drive on (the case here). but, in a strange way, it makes you write code and think of apps in ways you didn't before. that is, stateless, no need to touch the registry at all. i know, this is impossible for some apps and i am talking theoretically here. but rather than store registry cookies to identify users and preferences, etc., why not identify who is using a computer by identifying who's logged via standard function calls, for example, and have all their preferences stored on some distant database? be creative. there is always another way than what seems to be the only way. wax on, wax off, danielsan ;-P
;-)
1. tiny apps. just like the recent post. since single executeables do not need to muck with the registry to run, you are able to utilize small powerful ftp clients, html editors, etc.
2. build your own box. i put my case to my manager's manager, and they made an exception for me. i had (until the sept 11 wtc disaster, in which my workstations were turned into crispy critters) 4 computers at my desk. two were standard company-wide locked-down builds, and the other 2 computers they let me install nt server from scratch. nt security just made sure they had admin rights on them in case the box did something not quite right. then of course, software support washed their hands of these boxes. i had to install my os and software, i had to maintain it. if i screwed something up on the box, it was all for me clean up. which was fine for me, i'm a developer, i can support my own box. i want to support my own box!
3. write stateless software. change your paradigm. become one with the great zen of concise programming for the wrong reason: not because you should, but because you have to.
other tip: depend on nothing. my profile with it's personal settings blows up from time to time and is reset to the generic sucky settings and i have to personalize all of my standard apps all over again. after awhile, i made sure not to put too much faith in leaving my desktop and depending upon it to look the same the next day. batch job important standard settings to rejigger everything (drive mappings, odbc connections, etc.) in cases of nt alzheimer's.
finally, there's no getting around it, a locked down SOE sucks for developers. developer= power user. developer= someone who HAS to muck around with things regular users don't. so bring this up with management. you guys are special, obviously, the most thick-headed manager can see that. maybe, before they SOE everyone, you can convince them to firewall all you dangerous developers in your own domain and let you hack your installs to your hearts content, unsupported, insecure, untrusted, but necessary to build apps.
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
i'm at school right now and though most school sysadmins really have no clue what they're doing and leave tons of holes in the network, i'm at a school with a guy who really does know what's going on. I'm pretty locked down here. I have no access to any file management, i can't install anything, and i can't get to a command prompt. I've found a few discrete loopholes, but it's really a horrible environment to work in. When i have to get things done and i need to get something installed in order to complete an assignment, it's a horrible idea to be in complete lockdown. businesses really should reconsider and perhaps just try it out for a while and realize how much productivity is reduced.
-"Hey, Baby. It's not a rash, it's textured love."
The crucial thing is to have good support from it services for a dev environment - preinstalled source code control, dev environment, editor of choice and a build and test lab. You simply deploy your components to the test lab and debug over terminal server. Nothing like it (can't hose your machine, a new dev box can be installed overnight without interaction).
;)
The downside, of course, is that your devs can't install games etc on their boxes. We get around that by using our test machines for the latest halo
If one of the preinstalled apps is VMWare, you'll get along just fine.
Unless your employer says otherwise, you are in essence just borrowing usage of the machine in front of you. It's no different than a car lease - you can't add those super-duper fog lights, 20" chrome rims and turn the trunk into mobile love shack (complete with inflatable matress) because you think the car would be better that way. Of course, if you've *bought* the car, anything goes...
The same applies to computer hardware... If you want to use Linux, Mac OS X, or even just Windows with a crapload of pirated software and MP3s, bring in your own machine (a laptop, preferably). The only downside is, you'll probably have to get permission before you can plug it into the network; however, if you need the freedom your own machine offers, it's the only way to go. After seeing a co-worker get fired merely for using his company-provided laptop to surf for pr0n (while he was AT HOME, no less), I whole-heartedly advise the use of a personally-bought laptop at companies with such draconian policies about how you may and may not use the hardware they "provide" to you.
---
DRM is like antifreeze, to the MPAA/RIAA it's sweet, to the consumers it's poison.
A couple of years ago I locked down all the PC's in our corporate environment. At the time we had a development department that was screaming about how they couldn't work in that type of setup. I made a deal with their boss that if he wanted them to have that kind of freedom that was fine with me but we wouldn't spend ANY time supporting them. Away we went...
Six months later some of their top developers (the ones that acutally did things right and on time) asked me if I would consider letting them be supported by us (including lockdown). It seems they were too busy programming to screw with their machines. I moved them over and they were as happy as clams.
Of course, one screwball in support felt the need to muck around with my machine during a holiday, and I was less than impressed to find many useful apps were gone. Since then, I moved to a linux box for development on my new project, and I have to smirk when he walks by and scowls at my apps list. He may not like my MP3 player, but he hasn't the clues to remove it. Nor does he (or the rest of the support group) have root access. Tsk...
Some of our developers may not like administrating their own machines, but its the only way to ensure that the environment allows them to do the job. More guys here are demanding admin priviledges, and getting them as the bad policies get in the way. Most of the admin staff has static environments, which they hate, but since they don't have to have their computers rebuilt every week from the OS up, they don't complain much.
-- The Hollow Man
Non illegitimati carborundum
Just how necessary is it to be able to write to the registry? Especially when developing new applications? I mean, (feel free to correct me if I'm wrong) isn't the registry just a big place you can dump things to effectivly be global variables? Isn't the only thing it's usually used for just user prefrences? And if you had to, (especially if you were developing in an enviornment where you couldn't access the registry) couldn't you just simulate the whole thing with files?
Am I completely out of the loop on the registry here? I mean, yes, it's a convienent place to dump things, but how necessary is it, REALLY? Particularly for developing?
Of course, not being able to install new programs is annoying, since most of them use the registry quite a bit... But on the other hand, if you develop in a situation where you can't change the registry, then at least OTHER people will be able to install YOUR program in a locked down enviornment, since IT probably won't rely on registry settings...
In my experience, developers generally have more competence with the OS than most IS/IT employees.
I know you say this as a very qualified "generally", but I am amazed at how contrary it is to my own experience.
Now I'm not a Desktop admin, I'm a Solaris server admin for my company's production and development Web/Application/Database servers. While I'm a ok C/Perl programmer, I would never claim to know more about software development than our developers.... However, nor would they claim to know more about admining a Unix box than I. I'm the one who's answering their Solaris questions and cleaning up the messes that get made of the dev servers so they can get work done. (And I expect them to get screwed up. That's why they are *development* servers. But if someone breathes in the direction of a production box, I'll get pissed. :-)
At my home I run a fairly sophisticated network off my DSL line, with OpenBSD servers and MacOS X/Win2K clients. My roomate is a developer by trade, and can program circles around me. But, *I'm* the one that set up the network and admins the servers, and he'll be the first to admit he's learned quite a bit about networking, security, and server administration from me.
I know you would just say I am the exception, from the experience I have had, I would say that you are in the odd situation. Either you have some very overqualified developers if they are actually good enough to admin boxes, (I've met very few that are) or your IT staff is woefully underqualified and needs to be sacked.
-Wintermute
P.S. - Our developers do have local admin on their Win2K boxes. I don't really know if they cause problems with them, cause it's our Win2K admin's job to take care of that. I wouldn't concider myself qualified to admin Win2K in a buisness environment.
They suck in fact. Well, not for IT, certainly; but I don't like working in that sort of environment.
I work in a small office where I bring my home laptop to work. I'm also the firewall administrator, and tech support guy, and I maintain the servers, and it's a tiny office, so as you can see, my situation is about as far as can be from this sort of thing.
Which is the way I like it. I don't like the idea of working in an environment where there aren't enough tech support people to support users (and their work habits and personalities) as opposed to computers. A computer booting up all the time doesn't necessarily mean it's being efficient; a lot of people make changes to their computers that make them more efficient, perhaps simply because that's the way that they feel comfortable working.
So basically, I hope that I am never in a position to work in or administer an environment like this. It seems cold, sterile, and on some level, unrealistic to me. But hey, I probably seem that way to some people!!!
I'd say we ended up winning our battle. The first pass was that no one would be local admin, no one could install software, and no one could twiddle the registry. It turns out they couldn't figure out how to give someone local admin on their own system, and not every other boxen in the company. Apparently, after nearly relentless pressure from the development side, they only have two things they're going to ask of us: Run login scripts (to get anti-virus updates), and if you run a personal firewall, let through a few specific hosts/ports for reporting purposes. All in all, it looks like it's pretty agreeable.
They did tell us that while we have the right to run our own boxes, we also have the responsibility of running our own boxes. If you don't keep your patches up, or you abuse the privileges, they will come after you, and come after you mightily.
The truth about Scientology, Xenu, and you: Operation Clambake
I am an administrator of a Windows NT intranet for a small software development company (150 people). Everyone in the company has local admin rights on thier own machine. This occasionally creates a problem, but it is very rare and everyone is pleased. As far as licensing goes, we have a server running an audit program, which is triggered by the users login scripts. So far, so good. I believe that, in general, if you have good people working for you (It is VERY hard to get hired here), this shouldn't be an issue.
If you're in a company where developers ask IT for help, and not the other way around, maybe you need better developers.
If a developer needs help, he should be asking the older guy in the next cubicle. Every programmer I ever met would rather spend time washing windows than talking to "tech support" of just about any stripe.
"We can re-image the harddrive" should *always* be tech support's first response to any user with non-approved software. Of course, all company *data* should be on a server, and backed up. Which is a whole other can of worms.
I'm surprised your company hasn't already done this. They do this for support reasons. I am a SA for a company with a crapload of developers working here. I have this argument with them on a daily basis. There is no reason anyone should be developing on a production machine. End of story. There are whole labs provided for testing software.
Here, if you trash your box - you are on a "we'll get to you when we get to you" schedule because you signed a form agreeing to this to have root/administrator access to the the machine provided to you. I can't tell you how many developers come crying to me wanting their machines fixed and I tell 'em to get in line. 9 times out of 10 it's broke because they setup their laptop for their home LAN and it doesn't work when they came back to work. That or the latest Britany Spears screen saver is crashing it. We curbed the un-necessary breakfixes by locking people out of the OS's.
My company did the same thing. They created 2 domains. 1 was a production domain and 1 was a testing domain. If you are a developer you get the testing domain and admin rights on your computer to allow you to test/install various software applications. They do however charge more for the computer for the dept. rebills. I hope your company plans on doing the same thing.
-- Powered By Linux
Refuse to work at a company that won't give you full control of the computer on your desktop. I always run Linux on all my desktops and refuse to run windows.
Who cares if the company doesn't like it? Fuck them, they are lucky to have you as an employee. If they don't feel that way, leave and find a company that does appreciate you.
We are treated likes serfs because we allow ourselves to be treated that way.
I work at a school where the administrators are paranoid about students installing FREE software...IM software and the like as well as making changes to the desktops...
As I am the teacher of the computer literacy classes this directly hampers my ability to teach effectively the inner-workings of the Operating System...can't even teach them how to use a command-line interface(of course I set up some Linux machines to get around that problem).
But if I were to be developing...I would not think it would hamper my ability to do my job because the software I NEED to be using should be pre-installed...(if the admin ppl are doing their job)...some software I might WANT to use is probably not neccesary to me doing the job I was hired to do. Simply put...maybe it's to keep workers on track instead of reading slashdot.org all day long =)
Just some realistic thoughts of situations where it might be applicable.
"Just Smile and Nod." --Huck
Having spent a few months doing "development" work at General Motors under their "COE", I can attest to you that it was a major pain in the rear. Getting ANYthing out of the "ordinary" required an act of God himself.
Man did they have a cow when I installed BASH and GCC on my NT workstation. And when they discovered that I had installed VMWare (My own purchased license), they went ballistic.
Basically, I was told to develop software, but I could not use any tools to do it - well, I *could* use notepad to write the code.
I quit them after 6 months of this bullshit.
Ron Gage - Westland, MI
We have a bunch of VB "developers" at the place I work, and frankly, I don't think they could work out how to use a DOS box between them. They're all very narrow minded - they believe that anything that isn't strictly part of their VB programming is IT's problem (and fault) - they refuse to allow us to set up and configure their computers, and cause endless problems becuase of bad settings or things they have played with and broken.
So in this situation, they NEED to have their hands held, and their computers locked down. Not everyone who calls themself a 'developer' should automatically be given free reign on their machine.
Crimeny! Talk about yer heavy-handed edicts...
Someone's finally found a way to purge that last remnant of creativity and flexibility from the job of developing software. What a wonderful place that's going to be to work in.
Is there going to be a ``Directorate of New Product Ideas'' to tell you what new software you'll be allowed to dream up during the development process?
Don't suppose the originator of this story would want to leak the company name. I can think of a lot of people who would rather not waste their time even applying for a job with such a company.
CUR ALLOC 20195.....5804M
"And what is with all the troll accusations? Is everybody here really so small-minded and petty that they dismiss anything that they don't want to believe?"
Seems that way sometimes. I think it's because they have never done anything but their current line of work, so think they know everything.
I have worked in the IS side of the house for a while, and recognized some of the same types of activities you mentioned in your original post. Plus seeing a lot doing onsite computer work, install/upgrade/repair/etc. Users think they can add everything to a machine and it won't hurt it. Developers think that sometimes too, as in the reply that challanged your calling IM and Realplayer "crap".
They should know better, since we all bitch about the spyware taking over everything. I don't have Realplayer on my box at home, never even thought about putting it on at work. Ever notice how many things it wants to take over? I put only the basic version on my son's PC at home, just to play music. None of that annoying Download manager garbage.
And as for the 'really smart' developers out there, I worked with one once. He was an idiot, and his system crashed a lot. I wouldn't trust him to reinstall Windows, because only half the things would be configured right. And those would be the programs using default settings only. I know this isn't the 'normal' developer, but he isn't a lone specimen either. Last I heard of him, he was using Linux to code Perl, or somesuch project. Notice I am not calling him stupid by the way, just an idiot. Not bothering to check things before fucking them up, so he couldn't unfuck them afterward. That's an idiot.
And to stave off the torches being hurled at me, I have been using Linux since 1994, when I bought the big-ass book with a Slackware CD in it. Installed it at work, with the help of a co-worker. Had it installed at home, but not currently, and just installed it at work a couple weeks ago, to play with. But I don't make money using linux. My current job is a Unix admin and tech support, supporting about two dozen Unix hosts/servers and two hundred Windows workstations.
Our software writes to and reads from the registry continuously. The Registry is a convenient place to store information that is necessary to the clients business but occasionally has to be changed. Many application programs routinely make Registry changes. Items that tend to be stored in the Registry are 'Merchant ID Number', Processor ID, etc. I am not saying the the Registry is not overused, and that a lot of data that should be stored someplace else is being stored in the Registry. This is certainly true. If you look at the size of your Registry save file you will find it is huge. Everybody is storing data in the Registry and if you lock all those programs out, very little work may get done.
TOM
Treating the symptoms, but never developing a cure. You sir are the classic product of Western education.
Just a note, I don't know how they are planning on locking down your PCs, but I wrote a small program to modify registry entries without any user intervention going through the windows API that works even on the computers where the users don't have access to the Registry. As a developer, it's nice to use regedit, but the above program is used periodically to changes registry settings across the whole network and we don't have any problems with it.
I don't have time to make a sig
A perfect way to make your developers leave for more friendly companies
;)
If you can get the powers that be to install one piece of software on your PC, ask for VmWare. Once that is in, you can install your own Linux (or even Windows -yuck!) environment, and be the king of the hill anyway. Most likely they won't even know what they are giving you...
In Murphy We Turst
Something to consider about "locked down" vs. "developers with admin rights".
... not a good thing at all.
There are some extremely valid reasons to insist that developers have to take some pains to have admin rights to their NT machines.
1. Developers can easily "assume" admin rights when developing their software - and then blithely write software that requires write permission to an admin only area for example.
This could have easily resulted in a very expensive problem had I not caught this during building of the application for that development team at a very large (top 5 in world) finacial instituation I once worked at. Since the developers had admin rights they wrote a Java application that stored all config details in the Windows directory - very bad, but very subtle.
2. Developers having admin rights to machines means that they can build and install their development tools anyway they want, and they can patch/not patch as they see fit.
When the time comes to build the applications they are developing this can result in subtle errors and problems - both in interim development builds between members of the same team (who have differently built NT workstations) and when the code moves from development to production - during which it would likely be built on "standard" build servers - the wrong set of patches to a compiler or different shared libraries and the resulting code will differ considerably.
Note further that such issues are not usually solved by standard source code administration practices (CVS, MS SourceSafe, ClearCase, MKS Source Itegrity etc) all of which usually do not track the installations, builds, and patches of the OS, compilors, and shared libraries.
3. Have you ever witnessed the example of developers using beta or pre-release versions of libraries, compilors, or OSes? And then wondering why problems crept up when they moved their applications to production. Witness the recent problems at MS where code had been built against beta libraries - which left debuging turned on for applications that were then moved into production
Corporate development is a tradeoff between developers and the requirement of running the business - if you are developing on the fringes - or in a research lab environment that it is one thing, but when you are developing applications for the business's production environment (or to be shipped to clients or made available for sale) then rigorous and documented processes should be followed with regards to the machines that are used to develop and build the applications, if you don't you will eventually get burned.
I speak from the experience of working with over 1000 developers building and supporting over 650 internally written applications.
-- Join us in Chicago May 1-4th for MeshForum -- writer, historian, tech geek, entrepreneur, internet junky since '91 --
How can you expect to get reliable, reproducible results in an uncontrolled environment? On the one hand we've got a chorus of whining about unreliable programs being released to an unsuspecting public, and yet the same "programmer" wants a unique development environment, using his/her own set of tools. There's a dissonance here between what you say you want others to do and what you're willing to submit to.
If a developer needs to do unit testing, and needs admin control over a machine to do that, then that machine should be isolated from the operational environment (e.g. a lab). For the sake of the coherence and ultimate success of the development project, developers must use a consistent, managed environment. If they don't, for example, there's no way to reproduce a release to fix a reported bug. There's no way that the behaviour of the released product can be guaranteed, because the testers don't know what the required test environment should look like.
Of course, the tools that make up the environment shouldn't be whatever the favorite tool set of the PHB happen to be. They need to be worked out in cooperation with the people who have to use them. And the project can't be locked in from day one with no chance to change. But the changes have to be managed, like any other change in the project.
The idea of lock-down in a computing environment isn't necessarily analogous to a cell-block. But if you make the project manager think that herding cats would be easier than trying to get you to cooperate, you're entering into a shortened career path.
To hear the gods laugh tell them your plans.
It's called using a lab. Use the general locked down machine for their basic buisiness needs, and remotely access the lab machines to do their development work on. Then the IT guys can support the day to day machines, and the lab guys (either the developers themselves, on a 'you broke it you fix it' basis, or by people hired for the task) can take care of those machines.
Also, think how much better the software would be if developers experienced first hand how their software breaks a system! They would be forced to be a lot more careful in the development of their code.
awwww, is someone a little cranky because the back of their throat isn't getting rammed with as much attention as usual?
The correct solution is for your IT department to invest a little time in training problem users well enough for them to stop being problems. Until you've done this, the user isn't the one causing the problem.
Once you've trained users, if any individuals persist in causing problems - stubbornly doing things you've taught them not to do - then that's an issue for management to tackle.
And I don't mean it sarcastically.
My department is working with a certain software vendor that allows "free reign" to developers and, apparently, QA people (if they have any to speak of).
As a result of the developers' easy-going attitude to registry, we are in a situation where users *must be* local administrators of their NT machines. Or, in the case of another product from the same vendor, they have to be "power users" (demi-gods) of the application. Which is untenable in a production environment.
... best way to fight dumb corporate policy is to follow it to the letter.
About a year ago, I was curious about this whole Napster thing. At the computer lab, I installed Napster on my account. About a month later, I tried to log in, and was denied access. When I talked to the sysadmin the next day, he told me that my account was disabled because they scanned all the user directories and disabled all accounts that had files named "Napster." I guess I won't install Napster (or other similar programs) anymore. Or write any reports on P2P applications and call them "Napster.rtf."
I suppose scanning people's home directories and disabling people's accounts who install software might work just as well...
An unjust law is no law at all. - St. Augustine
I used to work for a company in which the majority of my work was done on a Solaris SparcStation, with a Citrix client for e-mail and the like. The workstation was locked down with NIS and my home directory was nfs mounted.
It worked great for me. Granted i only got plain vanilla Office and Outlook in the Citrix client, but I was a SysAdmin and a Perl developer. All my development was in VIM which ran happily out of ~/gnu/bin. I had gcc in my home directory, and many of the GNU tools and even ran WindowMaker as my window manager. All without having root access to my workstation. The one concession that I got was to have the version of PERL that was also NFS mounted up-to-date and the ability to get modules installed within a week of a request.
We also had Java and PL/SQL programmers that were under the same constraints and there really weren't any problems that I saw, except when I left and everyone was running VIM out of my home directory!
What if it is just turtles all the way down?
Aside from the simple logistics of preventing installations, you'll incur the side effects of driving all of your developers insane. A part of development (and in planning for management) is the dead time needed by developers. No developer in his/her right mind can sit at a computer all day and program nonstop from 8 to 5 (or whatever your hours may be) without ample breaks. I speak from my own experience here; my coworkers and myself don't program 40 hrs a week. I fear a management who would expect anything like that from its workers...
Developers need diversions to keep them sane, and many diversions are available on the computer - games, the web, irc, etc. When you prevent your users from installing their own programs, you're telling them that they are worker drones who will do nothing but program all day long. This also applies to non-programmer types who use the computer to perform many of their day-to-day tasks - secretaries, accountants, HR people, and so on.
Go back to your management and tell them they're making a big mistake by doing this. Not only will you anger your users by preventing the installations, you'll also have to deal with the lowered morale and increased stress as people can't use their computers for their down time.
t.
"Corrupting our youth one mind at a time"
Anyone have any (good/bad) experiences with bringing in personal laptops and hooking them up to their work network?
About 4 of us have laptops which we *used* to bring into the office to work on. However, recently the IT staff has banned us from being on the network (sighting virus and 'illegal' software concerns.)
Would Company X be liable for the contents of someone's personal laptop if it were on Company X's computer network?
Lies completely and totally with what you are developing and what tools you need to do it. Period.
Everyone who's talking about 'no, you can't develop if you can't use the registry'. Hogwash.
Nobody can answer this question except your own developers. Not unless we have details.
The policy was pretty much as described. You didn't stick anything on the corporate network that wasnt approved (and ironically there was approved stuff I wouldnt put on my home lan!) and the developer lan was seperated by an airgap and a single firewalling file transfer box.
IS folks made sure we had 3COM mail (or rather they spent their life apologising for lotus notes), and fixed those boxes, anything on the developer boxes was developer problem.
Within Red Hat nobody expects IS to handle a box that the developers have done crazy things to. And we have a few core boxes the developers choose to manage instead of IS.
It is possible to find a good policy, but with the current Microsoft campaign of license auditing I can understand a lot of people running very very scared in the direction of total mind control.
See... in order to properly run a network, and keep things going, you have to have a good amount of control over the machines. I've run some fairly large NT/2000 networks... it's a real pain in the ass when someone, say, removes their computer from the domain for some reason, and doesn't know the admin password, etc...
On the other hand, I 100% agree that people need to be able to use the computer as a tool; it's there for THEM to do what they need to with it; not for me to tell them what to do. (developers, I mean).
So what I really want is a system whereby I can maintain the integrity of all the machines I'm responsible for, yet permit people to do what they need to with the machine.
And from what I've seen, unix is most DEFINATLEY the answer. Developers don't need root on their unix workstation.. yet they are still free to install anything they want within their own account. If it's really useful, it's easy for me to install it out to everyone.
Face it, with the dot-bomb bust, there's too much competition among developers. Anything that will reduce my competitors' productivity will just make me more secure and increase my wages. So I say, GO FOR IT!
I got this link from a recent slashdot story. The gist is:
When faced with insane rules at work, follow them. To the letter. Follow the rules so religiously that NOTHING can get done and the powers that made the rules realized they overstepped themselves. They can not chastise you in any way because you are following the rules that they created.
http://www.iww.org/direct_action/s2.html
I am a software developer. I have been in the situation where the IT department did not give us access to do pretty much anything with our desktop machines except use the tools present. When absolutely nothing was getting produced in the department (well, it was, but at a snail's pace) and they realized why, we were once again given command over our desktop machines. Lesson learned.
I was working at a big company (let's just say that I was riding the light) that had an approved software list. You could not use anything that was not on that list. So, for example, if you wanted to use gcc, you would have to submit a form explaining why you couldn't use the approved C compiler, etc. I spent a great deal of time working with the folks who make the list, rather than writing code. I worked there for three months and wrote less than 100 lines of code. At my new job, at a real company, I have already written several thousand lines of code in the same amount of time, not to mention defining requirements, doing design work, etc. The moral: don't quit in the middle of a depression without another job. Any company that has those policies is hell to work at, but this is not 1999.
I know there are a ton of people on /. that believe the only way to work is with star-wars action figures on their desks, a foosball table in the breakroom, and full admin rights to do whatever they like to their PC.
/. when I say this: Developers - learn how to operate in a controlled environment. 90% of the problems encountered in a Windows environment are because of half-ass poorly-coded garbage that had more time spent on a UI widget than on the functional part of the software.
Unfortunately, there are a lot of companies in the US that are involved in something called 'business'. It's the act of making money by providing a service or selling a product. It's similar to the Silicon Valley rush, but with budgets and full-time jobs. If you've ever worked for one of these companies, you'd know that they try to control costs. Sometimes this means you can't have that lime green Herman-Miller cube you -need- for your development work. Sometimes it means you can't use an unlimited set of development tools of your own choosing. You may not understand the underlying issues, for example, that the cost of technical support for un-standardized workstations is higher than for standardized ones that allow for automated distribution systems.
I know this can be frustrating when your favorite development shareware is banned just because it requires 3 beta upgrades to the OS, but really: how much of this crap do you need to do development? How much of a headache is it going to cause during roll-out when your application is running on a HW/SW platform that's completely different? You already know your application is going to be buggy, so wouldn't you want an operating environment that's easy to troubleshoot?
Or is it the real issue that you're not allowed to install Seti@home and your favorite IM client? I think the bulk of developers complain whenever IT tells them what they can or can't do with their PC. They often forget that 'their' PC is really the company's PC, and that it needs to be configured in a supportable way.
I think I speak for many of the IT and technical support guys that read
Keep it simple: use simple tools, develop simple applications, stop with the feature-creep. If you learn to use basic development tools and stay off of the crutches of broken 3rd-party component garbage, you might find that your programs are much more solid. You also might find you get along with your boss better. This could be a helpful skill when your current company dies like the dot-com that you learned these bad habits from in the first place.
-T
We got around this hassle by simply buying a new system everytime we bought any new gizmo the lab needed, and described it as being part of the "instrument" we were putting in, and then we just proceded to build our own lab net. IT wasn't even allowed to touch our "instruments" (That's no computer, thats an GC/MS! Don't touch it!). Granted, we probably didn't need to network our pH meters or the viscometers, but it gave us the free reign we needed to work effectively. Funny we never have needed IT support. Just call your dev systems something else (The name "test integrator" always seems to work for us).
It depends on what you want to develop. If you want to develop software, you're going to have a lot of trouble. Most projects already suffer from a lot of overhead that keeps developers from being fully productive. Forcing them to go through a bunch of red tape whenever they need to change something on their computers could worsen this exponentially.
On the other hand, if you want to develop migraines, ulcers, and a high turnover rate, sounds like you're on the right track.
My company recently barred any changes to the system from what we (the MIS department) originally give out in the computer system. All system settings are locked, as well as access to floppy drives and cd-roms. Internal email only is enabled. Sending of documents, etc, are done through the network. Internet access has been limited, so that by default, no computers have access, and only when the employee explains why they require access to the internet do we make the decision on giving it to them. Now, obviously, these limitations are not present in the IS department's computers, however, being friends with those in other departments, i feel that restricting access this heavily is unjustified. Even the simplest thing, such as being allowed to pick and change their wallpapers at will, or picking a fun screensaver, can brighten up someone's day. Management (wo subsequently do have access to their own settings, and full internet access by default)obviously havnt thought this one through properly.
next thing you know progammers are going to be shackled to chairs and whipped into coding bloated software without being given the opportunity to go back and look for bugs.. we can only hope this works as well for other companies as it has for microsoft.
-----
jonathan barket
If your developers know how to maintain their workstation, your support issues will decrease dramatically. You'd be surprised just how many 'developers' have to call the help desk to find out how to uninstall a program in windows.
bleh
Just turn on dhcpd, and watch the IP-address wars begin. Others have mentioned SMB/NMB misconfigurations.
Recently, I was part of a development project that could be configured to send broadcast packets. Well, those packets caused a number of mysterious router & server crashes (due to broadcast traffic overload from ten or so systems).
None of these actions have to be malicious: these all have occured by inattention from well-meaning individuals.
What happens around here is that the SOE consists of crippled P200 boxen with all storage over the LAN. Locked down to a fare-thee-well, of course, and Linux forbidden on pain of termination. No personal machines allowed to connect to the Company net (including personal boxen from home) and in "the present business conditions" no new Company boxen or notebooks.
So, of course, we all just use personal machines for our work (including personal notebook machines) and test to our little hearts' content at home or on our own personal notebooks.
Everybody wins: the workers get their work done without being hassled by IT and the Company saves a wad on all the machinery, licenses, etc. that it doesn't have to buy.
Backups are sometimes a hassle, and we haven't gotten the ad-hoc 802.11b network to do CVS reliably, but otherwise things are pretty decent.
Lacking <sarcasm> tags,
I worked on contract for a large Zurich based financial company(..) till recently and an edict came down from the Grand High Poobahs in Desktop Support that all machines were to be centrally controlled, with *no* local admin rights even for us developers. So I asked them two questions:
1. How can we develop and, specifically, register activex controls when we can't write to the registry?
2. How do I debug when I can't use my debugger?
Which was met with an embarrassed silence. Once I prodded and threw toys out of the pram their justification was:
"As we are rolling out NT4 as the standard desktop we need to know all machines have the same config and system files"
... so rather than the Desktop Support team actually *supporting* the users and developers, they were actually restricting what we could do - if they were a third-party outsourced firm we would have shown them the door long ago.
Obviously we all told them to sod-off, and just logged on locally to the box with one of their admin accounts (user 'rm06'-anyone who works there knows that account!). But it didn't half annoy a lot of developers.
Then it got worse... any install packages we came up with were delivered to the desktop by sms. So anything we did was checked by them first before being fired off on a monday morning. Nothing wrong with that.
Except that their way of verifying a correct install package was to run it on one of the DS teams machines, with a tool (name escapes me) which created a log saying which files were updated/added and the same for the registry etc. *only* the entries in this log were delivered to the desktop. Do you see the flaw in this?
Well, a standard desktop isn't standard - even though they were all run off the same image, different teams had different images (cos some used excel for example). Even worse, DS being DS were immune from the lockdown - they had all sorts of shareware/warez/pr0n crap on the machine that my installshield was tested on. So come Monday morning, of the team we rolled out to we found approx. 50% of the pcs wouldnt load many of their apps due to the way they had butchered the MDAC portion of my app.
By all means lock down user machines. Provide developers with standard user images to dump onto test machines. But don't p*ss with a developers machine - it's like a mechanic not being able to open the hood of the car.
seany.
Where I work (a software house), everyone is an administrator on their own PC (most running NT4/2000), and we regard this as essential. Just take a look at the number of "custom" applications that are essential to us, yet about which our IT support guys (who are actually pretty good) don't have any knowledge...
Of course, our servers are all run by sys admins under controlled conditions. But individual developers' machines, and machines shared by developers on particular projects, really need to be under the control of that developer or project.
Ultimately, sys admins can support the developers -- by installing standard apps like Windoze, Office and Visual Studio, by configuring the network connections and so on -- but they should never be trying to control the developers, who are almost invariably more qualified on their particular project than any sys admin can be.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
you do one of he following:
....
....
1. The "locked down" machine is used only for e-mail, memo writing, and other such administriva. Real development is done only on a separate "development" machine, for which the IT department takes no responsibility.
Let's face it. If you're doing something wonky, you don't want to wipe out your main machine. Reloading a development machine from local backups is something that most of us get real good at
If you're developing embedded code, you'll have to do this anyway.
2. Your definition of "development" is limited. You write the code, maybe write little unit test programs, and then pass it off to the "integration and test" department. They get to build install programs and such.
It'll work, if you have a very rigidly defined design and everybody sticks religiously to the defined APIs. This is the "software factory" approach. Fine, if you're working on a well- understood, well- specified problem, and everybody is working well within their area of expertise.
Note that at best, this just moves the lockdown problem to another group.
3. You're not developing "real programs". If you're doing, say, Perl scripts, then you might get around the restrictions by claiming that they're "only data".
Anyway, Bad Idea in general. I'll bet we all have our favorite "ditzy little utilities" that we carry around with us. IT can be very rude about such things
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
I've had an almost reverse-situaton when I was working in support. There was a group of CAD operators that were trying to run their own NT environment as independant as they could of the rest of the infrastructure.
They fscked things up every week. One guy I remember mounted his HDD in another workstation to remove the 300Mb page file because he didn't know why it was there and then tried to boot his workstation. uurrgghh. Don't get me started on the NetBIOS broadcasts that went everywhere!
The core of the problem was purely political. Between middle managers bitching to other middle managers etc we had no authority to say "if you connect to our LAN then you do as we say". Slightly different situation to the main story in that these guys _didn't_ know how to run their boxes and blew our support time for their devision through the roof!
their primary jobs are email, writing text/presentations/spreadsheets, doing forms on the web, getting information off the web, and other communications jobs.
The Registry is a terribly annoying system built to obfuscate application and configuration information and make it hard to move between machines. And tools that hide drivers in among the operating system guts have similar problems. If you wanted a clean environment, you wouldn't be using Windows.
There are lots of sales people, and individualized attention doesn't scale well.
Personnel turnover is relatively high, as great sales people get stolen by the competition or customers, the competition's great sales people get stolen by us, bad or unlucky sales people don't make quota and get booted, and in general they want to minimize training costs for computer platform tools, focusing the training on directly-business-related tools.
The standard computing environment is Microsoft, which means that Bad Things happen to it fairly often, and the most effective repair methods are destructive - save the user's files and wipe the computing environment.
A surprising number of tools can be developed as Excel and Word macros or other things that don't look like installing new programs.
All of this looks entirely unlike developers.
The really tough part for most sales people is supporting individual productivity tools that haven't yet received corporate support - everybody figured out Palm Pilot support really fast, Visio was a bit slower, and Dragon Dictate and some of the contact managers aren't widely used.
Does this suck for me? Yes, because I'm not just a user - I install all kinds of cool stuff off the net, partly because of the productivity win of having my personal email and environment on the machine I carry on the road with me instead of one system at home and one laptop for work, and I can read my personal email on the train.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
At my school we have Deep Freeze. It basicly takes the whole hd image*(at time of install) and puts it in a oversized mrb. It seems a little bit better than cutting off registry access, because users can install things temporarily without the risk of messing up anything on the computer. You can also temporarily disable it if you need to update the image. (It takes a few mins though, as you need to log in as admin, then disable it with another password, then restart the computer, make any necessary changes, then restart again.)
*Note: It might not a real image, and if its not its something similar though, as the website claims it Moves beyond the image and restore process; Does Not Image. I don't know exactly what it is though
Actually, there may be some components that are worth using, but ActiveX is a security nightmare, and my experience with applications saving their information in the Registry instead of .ini files is that it becomes unmaintainable for the users, because MS designed the Registry to only be accessible by programmers and people willing to risk using Regedit, so you can't easily copy the configurations from one machine to another or back them up.
:-)
Please don't rate this "Flamebait" - I already dropped the +1 Karma Bonus myself to reflect that
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
If there is concern over fixing computers that might get broken, or worry about software being illegally installed, Fortres makes this neat package called Clean Slate. It lets you do whatever you want to the computer (ideal for a development environment) but instead of actually modifying any files, it transparently caches all changes made to the filesystem, and after a reboot the machine is restored to its initial state. We install this on lab computers at my school this year and it's really working out well. We have no problems with unknown programs and viruses getting stuck on machines and it gives students the freedom to change whatever they need to in order to get their job done (action-based restrictions and read-only files always got more in the way of doing real work). We also spend almost no time fixing software related problems since we can put them on a reboot schedule in the middle of the night.
This disk image creates a floppy that boots a customized Linux kernel that allows the administrator password to be reset. And thats the chance of getting caught, that next time they come around to administer the machine they can't get in. But who's to say that they didn't screw up the password?
You can also look at tools such as L0phtcrack that try to brute force the password, done correctly that wouldn't raise eyebrows, at least until they decide to re-image the box.
But really, what kind of job is it that you have to go to these lengths to circumvent policy?
Bleh!
Developer boxes should be on their own segment with absolutely no access to the rest of the network. The should have full license to do whatever, but they should not call the company help desk for support of their machines! They need to hire their own support consultants to fix their messes out of their own budgets. This shouldn't be so bad since a good amount of developers know their stuff when it comes to supporting their machines, but the ones who think they know are a help desk's nightmare! I spent more time on a select few developer's laptops at one company then every other user combined because they had to have the latest of every piece of software and refused to downgrade when Photoshop 6 would cause them to lose network connections. They wouldn't accept my answer and every day I had to entertain their woes until Adobe released a patch. I'm not a developer and I can't fix the source code to a retail program, but I can test it for compatablity and deem it not ready for production. There are no developers out there who want to work on last year's program (even if its better)! the point is they should be on their own virtual island - for business uses like email they should have a seperate locked down box that participates with the rest of the company's network.
Sound waves should be free!
With emacs, anything is possible. Seriously, on windows machines, my standard toolchest has rarely deviated from emacs, a compiler, debugger, memory debugging library, profiling tool, make, unit tester, and lint. I have never really seen a necessity for anything more. Maybe permissions to restart IIS, if applicable.
What do people think that they need constant control of the machine for? Can't you list your development tools? If your tool list is that dynamic I would probably suggest that you are wasting more time playing with tools than you should be. This doesn't mean don't try anything new, but that should be an exception rather than the rule.
Obviously testing a program installation requires some special access to the registry and disk, but the number of people doing that and the time spent should be minimal.
Saw this in many big outfits -
Except the CEO's and the IT managers 'demanded' passwords, and got to 'borrow' software - so they had the latest and greatest on their 'home use' issued machines. Then one manager helped another- passwords over the phone - and it became public knowledge - but on audits - it appeared threat only a few knew the word, plus there were exceptions... With NTFS for dos - registry lockdown is a joke - when combined with rootkits.
Then the classic of hardware add ons - remove the floppy, but include cdrom.. a scanner whose software is so flakeky, it will only work as 'admin'.. pissing in the wind to lock down windoze
If the purpose of this is so IT doesn't have to help developers, and you have developers that need IT, then you have a problem. I would be scared of any developer that needs an IT person to tell them what went wrong.
The fact of the matter is that most developers are more experienced and more knowledgable about the setup and usage of their machines than the IT staff is. I've always found it to be ironic that some 19 year old moron with no formal computing education and no previous work experience could be empowered and trusted to have Admin rights on an NT/2000 system, when the developer who works on it cannot.
Hmm... interesting.
I am at Uni now, but spent the last year working in an IT department of a fairly large company, where I was a "19 year old moron with no formal computing education and no previous work experience" who had quite a few network/local privs (okay, so not admin). What was most interesting was not that some of the more experienced developers did not have admin rights, but that they weren't really aware that they didn't! Everyone seemed to manage making the odd registry change so I guess they weren't completely locked down, but they certainley didn't any more privs than the average luser. There was no problem getting extra rights on the network (at least not for most IT staff), but they never seemed to need it, I guess I just liked the power trip ^_^
In the spoon, there is no Soviet Russia!
For those unfamiliar with the term, it is essentially a team, hopefully some distance away from the "corporate culture"
Yes, it can be a bit of a death-march at first. But if successful in reaching the goal, under budget, the manager can usually keep the team at the skunkworks
In the cases I've been blessed with, we get very little IT support, but we're all geeks anyway. Many of our development machines are definately not SOE
Our IT department begrudgingly goes along. On one hand, they hate it because of our self-sufficiency threatens their job security. On the other hand
further reading:
Productivity: A Personal Choice
Chief Programmer Teams
Intermittent Aberrations: Can Mature Companies Innovate?
How to Defend an Unpopular Schedule
healyourchurchwebsite.com - WWJB?
Sorry, I have yet to see that. Maybe where you work. Where I work we have multiple levels of both developers and sysadmins. I would say about half the time the developer is canny enough to keep his own machine from sliding into the gorge, but at the same time has no idea what the standard environment he's developing for is. Thus, I (as the person in charge of keeping the desktop environment for 8,000 pc's standardized) have to run around in a panic when he decides he's going to upgrade to mdac 2.6 and write to some nifty feature in that standard, and then to his shock and horror realizes that none of his target machines are running it, and his project will fail and it will be ALL MY FAULT. Of course, having him develop to the available environment would be too much to ask, would it not?
Regardless of what the developer knows about his machine, locking down the patch level of his workstation makes a lot of sense. I've seen the horror and chaos that result from them writing applications on a Windows 2000 box that then magically fail on our standard Windows NT workstations. Yes, it may KILL productivity, but when you're working with units in the thousands, a badly-written app not tested against standards can wreak untold havoc as well. It's a trade off, really.
Oh, and in my environment it's the 19-year old morons who think they're hot shit because they learned XML last year who are fighting the 30-year-old technical support staff.
When security is a must, a locked-down environment is absolutely essential. This does not have to hurt productivity though.
I work for the DoD on a classified system so we are extremely locked down. I have never had a problem though because our IT department is extremely understanding. They know that we are developers and in general, know what we are talking about so anything that I need done, usually just takes a phone call. In fact, I have yet to have any legimate request denied.
It definitely prevents employees from installing games and stuff (which atleast to me, is a Good Thing (tm)), but I have never had a problem getting important stuff such as emacs and mozilla installed.
It's all about the amount of respect the IT department has for the developers and vice versa.
int func(int a);
func((b += 3, b));
Simple:
TA Environment - Test Enviornment. Play with whatever you want. Be a monkey, etc. If you hose your box, better ghost restore it yourself. If you can't do that you shouldn't be devloping systems.
QA Environment - Staging servers, look like production. Code is moved here in controlled fashion.
Prod - Prod is..prod. It is controlled, secured, etc. No one goes here but production control/support folks, and developers as Tier III admins.
Seems simple to me. Works for our $50B company.
There is no correct answer to this question.
If you're developing Windows apps in VC++ or VB, then I can't see how a SOE is acceptable. If, on the other hand, you're developing web apps, or if you're developing embedded systems apps, which will run on other machines, then a SOE is annoying but I can see that it could be desirable from management's or IT's point of view.
It also depends on your coworkers. If they continually download and run viruses, if they continually screw up their machines and depend on IT to bail them out, if they continually download and/or install unlicensed software - then YES, an SOE is obligatory.
Just because YOU know how to reinstall everything if you screw up; Just because YOU won't install any unlicensed software, doesn't mean that your coworkers aren't going to. And yes, your employer has the right to say that you can't install any unlicensed software on your machine. It's their butt, not yours, in the unlikely event that it is caught.
Also, if you and or your coworkers are spending most of their time playing around, reconfiguring, installing software, or reinstalling the whole system - then it SHOULD be locked down. Developers are, in general, highly paid employees, and a day or two spent reinstalling all of the software, just two or three times a year, times 10 developers... you start talking real money real fast. Not to mention the time spent figuring out why f*ing Windows is blue screening again (because you just HAD to have the latest sound-blaster driver to listen to your MP3's while at work)...
Lastly, I suppose that if your software is specifically NOT supposed to write configuration to the registry, then it really shouldn't matter if it's locked down.
The question may not be whether it is possible to work in a locked down environment, but whether you will enjoy working with the other inmates there. If yes, does it matter that you aren't productive?
Note that just because management is stupid doesn't mean they don't have an angle. Defense companies are often awarded government contracts cost plus. That means the more inefficient they are the more they can make. Their profit is set as a percentage of costs (around 7%).
When projects inevitably fall behind due to bad policies by senior management they pressure middle managers to coerce their workers into working overtime to try to catch up. There is tremendous stress on the team, as management plays a game of good cop/bad cop on them. Since technical staff is salaried, and the company charges by labor hour, unpaid overtime amounts to free labor that the company still charges to the customer at full rate. It's pure profit. Management then tacks on their "cost plus" multiplier, taking profit on profit! A marginal cost plus contract becomes lucrative when you charge for costs you don't actually incur.
At the end of the year the management secretly awards themselves large bonuses for being so profitable. The programmers, however, are told they don't deserve better pay because they are always late. Eventually the company may foul up so consistently it won't get awarded contracts anymore, but that may be forestalled by replacing middle managers with new faces to "solve the problem." The upper managers will swap positions annually to create an illusion that there is change at their level, too.
It can be dangerous to work in such an environment. One co-worker threw up in the bathroom daily from the stress, another died at his desk without warning from a heart attack.
Locking down machines can be an effective way to create workplace inefficiency in the name of security. Inefficiency is waste, but that doesn't mean it isn't profitable to certain people, and deliberate.
In a system on the scale of which you speak, with the problems you describe, you should have a dedicated test network (logistically) between your development network and your production network. The test network should be identical to your production network. Changes moving to production come only from the test network (where they have been for a pre-determined amount of time/usage) and are approved on an item-by-item basis before they are moved. Development changes move to the test network after being approved on an item-by-item basis, at which time a non-coder sets the schedule and criteria for a successful migration to the production network. Failures at least reset the clock.
You can document your processes all you want, but if you don't know how to run a large-scale production environment you'll need titanium boots to keep from shooting your feet off. Sensible production controls address every issue you're talking about and have no bearing on the question of whether IT and development get to fight over desktop admin rights.
Btw, if your IT people are good, your managers are good, and your developers are good they help each other and don't have turf battles. I'd hate to try to find the weak links in the story poster's company. What a fucking nightmare that place must be to work at.
Of course, if you've picked NT systems for a production site then you've got more serious endemic problems than underdeveloped production control.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
Here's the solution, but accounting isn't going to go for it...
...and who doesn't like three computers on the desk...
You need a machine to read email, write documents, surf the web, etc. You need to have this machine 100% as much as possible.
You need *another* machine to develop on and do basic testing, and you need *another* machine to do full testing. that has what you expect your end users to have on their machines and not your development environment.
This way you can have your IT controlled system, your developer controlled system, and your end users system...
Darthtuttle
Thought Architect
It is possible for developers to work in an environment that is almost completely locked down. These are a few possible solutions:
1. Give developers development boxes that they support completely on their own, possibly on their own private network that is not connected to the outside world.
2. Set up some sort of virtual machine on their machines so they can do all their development work without disrupting their IT supported environment.
3. Get the manager of the development team to share an employee with IT so the developers can get sanctioned support without having to go through regular channels.
These are just a few of the possible arrangements. I have seen varations on these in many large environments and they have all worked to varying degrees, but never without some complaint or other.
If Darwin was right, you'd be dead by now.
I work in a small dot.bomb, that has managed to survive over the last two years. I have one other support person, who shares in supporting about 20 servers, and 40 desktops. Our number one responsibility is to make sure that everyone in the company can do their job, not impose draconian , BOFH policies.
BOFH is a good read, but try it and everyone will hate you. Then they'll hand you a pink slip.
Our policy is to allow everyone, (even secretaries) local admin rights on their boxes. We give them network shares for stuff that needs to be backed up. Then we do something novel, like get off our duffs, and train them to use their computers. Some don't get it, but at least they know they can always get one of us to help if they get over their heads.
If you treat your fellow employees like lusers, they'll act like lusers. Expect them to act like professionals, give them the tools and the training, and they improve over time.
And developers? Let them have any tool they can get approved, and help them use it. Otherwise you'll miss out on a lot of cool tech that doesn't necessarily show up on slash... Or is surfing and checking out amihotornot.com more important?
Or, they could not do that. Developers could do many things that they do not do.
Developers having admin rights to machines means that they can build and install their development tools anyway they want, and they can patch/not patch as they see fit.
It also means they can fix problems without waiting weeks for them to otherwise be fixed (yes, I have been the recipient of that while working for one of the top defense contractors).
Have you ever witnessed the example of developers using beta or pre-release versions of libraries, compilors, or OSes? And then wondering why problems crept up when they moved their applications to production. Witness the recent problems at MS where code had been built against beta libraries - which left debuging turned on for applications that were then moved into production ... not a good thing at all.
Yes, that is a problem, but your solution is just as large a problem. You can solve such issues with guidelines and good management skills; the draconian route can work, but it's not the best route in my experience. I've fought with it. I've seen teams fall down for it. I've seen projects die in a flaming mess because if it. The 'it' I'm refering to is beaurocracy, and what you are advocating is a particularly severe form of it. There are other, better solutions.
Besides, most of the people I've know that advocate your position usually had some sort of power struggle involved (my last one was Thou Shalt Not Use PowrerBuilder because Visual Basic is Blessed).
The wheel is turning, but the hamster is dead.
Its still possible to install some applications if the applications do not make use of the HKLM (HKEY_LOCAL_MACHINE) hive. Users will need access to HKCU (HKEY_CURRENT_USER) hive in order to be able to run most applications. There are many userland window applications that don't use the HKLM hive, and just store their settings in teh HKCU hive.
I believe that SOE is the right way to go. For developers give them two PC's one for doing their job (programming, e-mail, etc) and another for testing. If the developer is a high level develop (builds Apps with Visual Studio or Delphi), you will need to give them local admin rights to their work PC because a lot of the development tools can only be installed and used with admin rights. Perhaps lower level developers (Access, Web development) you might be able to lock down their PC's.
Make the developers responsible for maintaining their PCs. Provide them a build Disk or CD to re-install the OS and standard office apps if they screw up something and can't fix it. Desktop support should only provide support for hardware issues for developers (Bad HD, Nic, etc).
I have personally setup dozens of business with custom installs of Windows NT in a locked down environment. I've created custom unattended Win NT installs that install the OS, Service packs and Patchs, Standard Apps (MS-OFFice, Outlook, IE/Netscape, AcroReader, ICA Client, Terminal Emulation, CAD/CAM, Client-Server Apps, etc). The Standard build is installed from a DOS floppy that determines the hardware model, nic and installs a clean install of NT and standard apps. Its so easy, even a stupid user could rebuild their own PC.
Application installs, upgrades, and Patches occur during lights out. As long as the PC is connected to the network, upgrades can be performed during non-business hours, so that users aren't impacted during the day. The lights out installs also manages available network bandwith so that only a limited of workstations are upgrade at a time (upgrading a 1000 PCs at the same time is a bad thing!)
I've created custom NT services to allow non-privilege users to perform some privileged functions, such as installing a network printer, or installing a business supported application.
A locked down system is as useful as a tool as a hammer is if it were barred from making marks in it's head.
Clearly, the process of developing suggests an errorenous progression; changes are made gradually. With the inability to make changes, one loses the ability to develop.
Most companies have a locked down test system, which serves as a scientific control, but having a locked down system for which to work and develop would yeild an environment where very litte work could get done. You need to be able to change a system to make something, its as simple as that. Imagine being requested to build a new house, or better the foundation of said house if the ground couldn't be touched.
"I'll just chip in a bit for RedHat: I actually have that installed on my university machine." - Linus, '95
In 8 months of working at my university, I've never seen a single user screw up his/her computer with AIM or RealAudio. How is this even possible?
Where I work we try to prevent users from running Linux, especially Linux installations fresh out of the box and un-patched, to protect our own asses - their boxes would quickly get owned and used to cause damage to our own network.
I'm interested though in how Linux machines mess up the NT Domain...
What is being discussed here seems to be exactly the situation at my high school, a public school in Indian River County, Florida.
Recently the entire school's network made the switch over from Windows NT 4 to Win 2000 (lots less crashes now, actually). With that, though, came a few unwelcome changes... now it seems that teachers are unable to install any programs on their own computers that would require Windows Registry entries to be made. This became clear when my physics teacher asked me to help her install Adobe Acrobat Reader on her computer to read a file she downloaded; Windows complained about something having to do with permissions.
The worst part, though, is that the teachers don't even seem to know that their computers are "locked-down" in this way until they run into a problem installing something that they need. It's a really messy system, to say the least.
I work for a large software company. No names, but we're talking over $1B in cash on hand, and we probably have as high a percentage of employees who are software developers as any company. As a general rule, developers don't go to IT with problems until they've run out of options. I have a separate IDE hard drive with a ghost'ed image of my primary machine that I've used on several occassions to save my ass and get back to coding when I don't have time for some IT clown to spend a day looking at my machine and then deciding to rebuild it. Personally, I would be about as effective as a chocolate fireman if I had to work within the type of constraints you've defined. I waste enough of my time as it is getting around barricades put up by IT.
There's another argument against requiring locked down systems for
developers. This assumes you are in a situation where you have free
reign to build / configure your machine - for me it was a tiny Linux
enclave in a mostly Windows and mainframe organization ("you break it,
you fix it - don't bug us, and we won't bug you"), and I was
developing internal software tools and Web applications on free
software (Linux, Apache, Perl, etc.).
The great advantage (for me) of this setup, other than simple ability
to function at my job, was doing the admin work taught me a *hell* of
a lot that was useful to me as a developer. Building, installing, and
*configuring* the kernels (including occasional oddball device drivers
cobbled together off of the net), compilers, libraries, Web servers,
databases, etc. that I used to develop with, having to do my own
networking setup, keeping up with security patches, etc. gave me huge
amounts of experience that I wouldn't have gotten just programming on
a box that someone else set up.
With this experience and exposure, when my boss would wander by my
cube to ask what it would take to design and build some new system to
do X, Y, and Z whether as an internal app or to deploy on our public
Web server, I could usually give her an accurate estimate on the spot
of the effort involved, how much we could use free software for vs.
how much we had to build [funny... there was no problem buying
proprietary software when needed but it rarely was], what could go on
Unix vs. Windows and the size of hardware needed, etc. I never knew
any of that stuff when I used to be a pure code monkey working on
standardized boxes - it was someone else's problem then. So while you
may argue that developers don't need full control over their machine,
I guarantee that they will either learn from it, or go back to letting
someone else admin the machine.
Working with two other developers with the same approach was great
also. I used Slackware Linux preferring to develop in Perl, my team
lead ran Windows NT with a Red Hat box on the side, developing mostly
in Java, and our junior team member ran Red Hat and programmed in
both. By having to share code in an environment like that, you were
pretty much required to use good source code control, keep track of
runtime requirements (libraries paths etc.), and write portable code,
or you would always be pissing off your coworkers.
The big issue in security is the cost of it. Cost in money, time and mostly in funcionality. A secure environment has to sacrify a lots of functions.
If you want a secure environment, blocking the users to modify the registry is a good measure. That way they will have access to the stuff they need and nothing else. You should also disconnect all CD and diskettes drives, serial ports (where a Zip drive can be inserted), ban every access to Internet and most of all, FORBID the use of notebooks.
This measures might seem cruel, hitlerian, but they are neeeded to hava a secure environment. If users are allowed to install everything they want, they will install ICQ, Napster, etc. They will waste your Internet bandwidth, your resources, spend their time doing other things or working for themselves. If they install software, you might end into trouble because of licences, system crashes, etc.
I worked in such a secure environment for 2 years. When I had to stay late at night taking care of a backup, the only amusement I had in my PC was the game of solitaire. Is not pleasent, but you focus in your work and do not waste time nor resources.
HTH
PENAROL: Seras eterno como el tiempo y floreceras en cada primavera.
That sounds suggestive, as in undressing. You meant "barring".
We use a product called secure Desktop The users are only allowed to click on their apps and run them Nothing else. They cant change anything period. They cant install anything, they cant even access the floppy or cdroms. Maint issues like control panel are password protected. Every desktop are exactally the same. They look the same, have the same applications etc. We are able to use vnc or pc anywhere to remotely admin the desktops in order to provide support. All in all this product protects the user from themselves and we have found our support costs go way down upon using it.
keep the computer clean. I.E. you boot, butcher the system and this will restore it like new on the next boot or variations on this theme.
The users desktop, all settings and files and any specially installed software are stored on a server so that *any* computer is theirs. The C: drive for all practical purposes is write protected. I can shoot a computer without losing data or slowing down work much.
I already enforce this policy, I hate the flashporn addicts who waste time and damage my property. I also block most internet access only allowing email, surf porn at home. The internet accesses allowed are to a pipe to another location, encrypted of course.
For that matter, I can develop my app all day with emacs + javac on a Linux box while my teammate develops in JBuilder on an NT box, and integrate our code with no problems, as long as we have a basic understanding of the Java versions being used and any quirks in the respective tools (never ran into any though). Or develop Perl apps on Linux to deploy on AIX. No anarchy, no chaos, no problem. Sure, it's important to test the software before deploying it just to make sure there aren't any integration problems, but you would do that even if everyone developed on identical locked-down platforms, and in 4 years I only got bit by development environment differences once (different directory location in AIX vs. Linux).
Of course all parties need to agree on compiler versions and the like. Of course testing needs to take place on a non-developer machine. And of course the software shouldn't have any dependencies on local or undocumented paths or other configuration. But to claim that "developers must use a consistent, managed environment" (italics mine) is just excessive. It is the "managed" aspect of your argument that worries me. That always impplies that someone else will be doing all the managing - somone else will be building and maintaining all the development machines to some predefined standard. In reality, when all parties agree on the important aspects, while throwing caution to the wind in areas of personal preference not affecting the success of the project, things work just fine.
You're going to have to look at the situation and answer this question (honestly): why was it that the developer felt s/he had to do this on the sly?
My experience is that there are generally two cases, not mutually exclusive.
The other thing, of course, is to see if the unscheduled change makes the app better.
If your environment is as locked down as I suspect it may be, what you're describing here could just be a visible instance of what's widespread practice: people adding free software elements to their work environment because it makes it easier to get the job done. Complete freedom is clearly inappropriate, but a large tolerance for diversity is a strength.
And note before you disallow all such projects that UNIX itself began as an unauthorized project by Brian and Dennis on some old hardware.... Punishing inventiveness does lead to one predictable result. I'll let you do the math.
What part of "gestalt" don't you understand?
If a company wants to implement a lockdown like this, it might be a good idea to just run everything through X. You could have software you want certain people using available at user-level access, and then just set up a bunch of terminals to access it from. This works pretty well for the student servers at my school. UNIX is probably to scary sounding for most IT people who have been fed m$ propaganda for too long tho...
"Question with boldness even the existence of a god." - Thomas Jefferson
Sounds like you work at a big company. I'd just give up and stop caring if I was you. It's not like they expect you to care (or be competent). Just put in enough work so you don't get fired, but not enough so that they pile everyone else's tasks on you. Use the time to learn something else so you can avoid working at a big company in the future. I would advise you to fuck 'em and go work for a small company, but small companies are dying like flies at the moment.
What you may want to do is just get out of the computer industry and make a major lifestyle change. You don't have to be a corporate slave. You always have choices.
Boy, you guys are NICE re-imaging their drives! Here at work if WE screw up one of our drives (yes, I'm a developer), they come in with a boot CD, install Windows ONLY, and WE are expected to set the rest up ourselves!
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
Why put up with unecessary crap that gets in the way of development? Change policy, or look for another place to work.
Hmmm, Its been a nightmare where I work, I moved from an NT4 Admin type roll where I was able to do anything I wanted.
...
....
It came as a shock when I got to the new job and couldn't even run chkdsk, it took 2 months for me to explain how to give me local admin rights on my workstation.
Ive been here 6 months now and they finally gave me access to the server room - put not a password that can log me onto my server, so I still have to call IT if I need to reboot it. (Hey, its NT4 you gotta reboot)
Thing is they made it quite plain that I am not IT, therefore I won't get any admin rights
I don't really have much respect for my IT department - mainly because they are not very good. IT are there to provide a service, but thet are not providing a good one. Things like adding a network printer to a workstation should not require a helpdesk call and 3 weeks wait.
Just as an example of thier style - I offered to help install Veritas Backup Exec (Trying to make an impression) as I had to run and use it at my last job. What's the first thing you do if you install software that needs to log in as a service? You create a new user account.
Converstaion went like this
me: We'll need to create a new user account and restrict what servers it can login to.
IT: Why?
me: Helps with security and helps with admining
IT: Nah, we just use the Administrator account.
me: What happens when you change the password? Your going to have to go through all the services on the servers and change it there too.
IT: No we won't, We don't change the Administrator password
me: !
try to make ends meet, you're a slave to money, then you die
Our whole company (25,000+ pc's) has a SOE which is the basis for all PC's and added to by request and payment(new software from the approved software list and so on). Most departments have to follow it. The only ones who dont are the casual ones, usually remote to the main HQ of the company.
There are three main reasons its done for my company:
a) to limit the number of supported apps/hardware, which reduces the overall cost of support. (Well so they say)
b) To stop possible network holes being introduced by people installing certain software.
c) To more easily centralise a list of what apps are running where for license reasons.
We are not 100% locked down: most apps are installable. But drivers will usually fail, as will some other apps.
My solution was a bit "under the counter" so is not recommended for that reason. I found a little app that was in the (for some reason not deleted) NT4 SP5 service pack folder, and lets you start the NT add/modify user app , create any other users etc. Just run the program and you can add accounts of any type.
Admin accounts are usually locked down automatically during image install with a long, complex password. But run the app and 20 seconds later you have a local admin level account which lets you do anything.
There are lots of other ways to breach Windows security and in a similar way either reset admin password or create new accounts regardless of your priviledge levels.
As usual, you should use that kind of thing for good, not bad.
I hear rumours though that early next year the company may upgrade from NT4 to a completely locked doen XP desktop (ie cant change or install anything) which is a worry as I havent found any good holes in XP yet (havent looked that hard yet)
Cygwin..
+ i does not require registry perms during the install phase.
+ almost all apps will compile (X-Free,gtk,ncurses,ect )
- No mozilla or open office tho yet..
.
it made my life much easer till the brain dead admin squad gave me admin rights..
-- side note.. this would be a great distro idea.
anyone know if there is a cygwin based distro in the works?
-best
-greg
Boy, you guys are NICE re-imaging their drives!Here at work if WE screw up one of our drives (yes, I'm a developer), they come in with a boot CD, install Windows ONLY, and WE are expected to set the rest up ourselves!
Seems strange. It's quicker (by far) to use ghost or something similar. And if you use imaging you end up with a fully functional (business) system. For instance on the old compaq I use as a desktop it takes the morning to reinstall Windows 2000 and Office 2000. It would probably take at least another 1/2 day to get all the standard and custom apps set up. I can ghost to the same setup in 40 mins.
Much as we'd like to (and it is something that we have considered) we haven't found a quick developers solution because just about every developers' machine is unique in most tools (and no, we're not stupid enough to say "This is the company editor, you will use this even if it makes you less productive"). The best we can do is make sure that when a machine is hosed they can get up to a known standard condition quickly containing everything they need as an employee, and that they have easy access (via CD or network share) to any tools that they then have to re-install.
In your situation if there is a single tool, application, or setting that has to be installed or set before your machine is functional, then your IT support department should get their arses kicked: they are costing themselves and every employee time and money, and that is not acceptable. There would be a management decision to be taken if IT support are saving money at the cost of some developer's time, but dollars to doughnuts that isn't the case here. It looks like a "you've screwed up, therefore you have to be punished" mindset, which sucks.
SOE = Standard Operating Environment
In that case the matter is resolved easily. Developers by definition do non-standard work. That can't be done in a SOE. Developers HAVE to be able to play and experiment. They HAVE to be able to write applications that need to write to certain registery keys which are protected by the SOE (think of installers, experminenting with different configurations, etc).
This is your sig. There are thousands more, but this one is yours.
I work for Big Blue, and developers aren't forced to use locked down machines for development work. Only production systems are locked down.
To be honest, I wish things were a little more locked down. We've had a few incidents with irresponsible software installation on development servers...
Then again, I'm the kind of person who quotas myself on my own Linux box. I'm an ex-sysadmin, which probably explains it...
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Something tells me that this is just someone writing in to figure out how to lock their desktop from their parents/siblings messing with it, or something to that effect. No one in their right -mind- would code anything on a locked down system; you just can't do anything important with it. Locked down network, sure; the last thing you want to give to people who know what they're doing is a network run by people who don't.
I think you're going to end up with two machines on your table. I have worked in such environments - its not uncommon in large firms.
One is the "officecommunication" machine - there's Powerpoint and Word, all nicely locked down. The other one is managed by your department (not those central it drones), networked in its own vlan, and may or may not even have separate internet connectivity.
And of course, after some tiome, there will be guerilla connectivity between those networks.
f.
I'm in MIS, I've been in MIS for 12 years now. It's a pain in the butt to support developers.
Understand we're a complete Microsoft shop, when you take my commments into context below.
HOWEVER, I've always made a deal: If it takes my team longer than an hour to troubleshoot your machine cause you've loaded so much crap on it, then we wipe it clean. Period. So, they get no lockdown so they can develop, and MIS doesn't have to waste time trying to see what frickin' dll's are messed up.
As for developers and licensing, we've gotten them all MSDN Universal. Don't have to worry about it anymore and they can have server software, etc. Your MIS department isn't thinking things through, especially for developers.
If your any good they with do whatever you ask. I said I needed a 'NIX workstation and my code is going to be GPL.
It worked out great and my productivity is through the roof. The developers chained to their Windows boxen in near by cubes can't even come close and get passed by for all the best projects.
Your right that Ghost would be faster, but they CLAIM that there are so many models of PCs around the company that they can't do it. We do have everything from p90s to 2 gig machines around - Penny wise, pound foolish
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
I work on a large network with an SOE, and our section has an exception, and future moves are tending toward firewalling us from the SOE network, if any change at all. And I know for sure that if I were to get locked into the SOE network, I would not be able to do my job, and the people that enforce those rules also know that.
To give you an idea of why we have an exception is that our current simulation runs on Linux, and that does not appear to be going to change for at least the next few years, although there has been more talk about locking down to an SOE network.
Your last option is to negotiate the programs you require to be installed, make sure the licensing is correct, and I cannot see the problem. Do you need to use unlicensed programs or another operating system?
Your last options are to work in the IT environment where they are doing the change to SOE, and make sure it is done right, or after reading this, you are still stuck, well, start looking for a new job, really, if they don't allow you to work, move on.
VK3TST
-- "People aren't stupid. Usually." -- jd
Indigo, you're forgetting something that nearly every developer I've ever worked with loves to forget: somebody has to pay for all your little tools, and it ain't you.
Now, if you're using all open source stuff that's free, more power to you. I don't lock our devs into any particular text editor UNLESS IT COSTS MONEY. If you want to use VI, EMACS, or Notepad, go for it, but if you want to use Zeus or (God forbid) Word, then you're not getting it unless you can justify why YOU need something that the entire rest of the development staff DOESN'T.
Wake up! Don't you get it yet? You AREN'T the whole picture here. You are simply one little developer in a group of many, and you CANNOT expect to get your way all the time. If you have a good case, make it. If it's valid, you'll prevail. If it ain't, sit down and shut up.
That is true, but if they insist on that, there isn't much to do about it. The IT market isn't so hot, I wouldn't resign in a hurry. The office where I work, they use hardware disc controller devices that undo all changes to the HD instantly by tranfering all changes onto a second partition. This way, whenever you reboot, the system will go back to it's original state. The system is fully read/writable, but as soon as a reboot occurs, all changes are lost. Save files on a network server, remove the DirectX APIs, see how easy it is to install software. Since much software requires a reboot, this is a pretty decent situation, much better than simple registry locking.
Tired of legitimate data sources? Try UNCYCLOPEDIA
I think that developers can request (and obtain) that VMWare, or the like, be installed in their workstations.
That way, they can install tools on the virtual machine, they could even use it to do the real work!
Also, communication between real and virtual machine takes place through virtual ethernet (tcp/ip), so in principle the two could share folders and so on.
While I agree that a test environment is important (indeed it was my role there) and that many of the issues can indeed be solved by good management, my fundemental is that in all environments casual Admin access is not a good thing - not due to whether or not the developers are "good" or not - it is simply due to how people opperate.
If you have certain rights on a machine - it is harder to catch when you are doing something that requires those specific rights (for example writing to a restricted directory) - it is not maliciousness or poor developers that do this - it is not using the security systems and structures correctly.
Further, I think you may misinterpert what I mean by "production" - while I am a strong Linux/Unix advocate for Internet systems (indeed I am Sun certified) - for corporate systems with very skilled developers NT systems serve important and indeed production roles. The NT developers at the company I am referring to were highly skilled COM developers building production financial trading floor applications which ran on WindowsNT workstations internal to the corporation - the NT systems and their workstations while not immune to problems - were when well managed and well run (which this firm did do - albiet at an extremely high cost) - they served a valuable role.
It was not a "production site" in the sense of a website - rather these are hardcore financial applications.
Also in terms of test sites and change management - there is a constant and ongoing battle between the business needs and "best practices" - when a change means the literally millions of dollers an hour - the process should be highly controlled but also highly efficient and rapid.
One means to ensure rapid migration from the development environment (perhaps through a test/build environment) to production is to keep the THREE environments in synch with each other. I.E this means ensuring that the developers are building using the same tools, patch levels, and build systems as the eventual test and production enviroments.
Since developers are not usually also people who want to admins - while they may know enough to install patches and new apps - they probably do not want to document every step and/or follow highly documented and tracked procedures - they want to get back to coding as quickly as possible - it is a compromise on both sides - I agree - but in a large scale corporate environment that is vital to keeping the entire system running smoothly (which translates in the long run to a more profitable company, stable jobs, and good pay.)
The company I worked for was NOT at all a nightmare of a place to work for - it was one of the best run (and highest paying) firms around - developers were engaged in very interesting, cutting edge development of very cool apps (one of the first Marimba application deployments for example) - generally there was a compromise with the developers which very much related to the stage of their application - as they approached releasing it to end users and as they supported released applications they had to endure a more restricted and locked down development environment.
To counter this the development teams themselves were the people within the organization who controlled the pursestrings for development application - and a committee of the technical leaders of the development groups set the corporate standards with regards to build tools, languages, application versions, and policies and procedures.
While there were still individual developers who might chafe at times - generally they saw the value to the overall process after it saved them significent time (and money) when it came to keeping their end users happy - being able to move a change from development to production when needed in a 24hr period to get trading centers back up and running - but still adhering to documented processes and tested environments was the proof of the pudding.
-- Join us in Chicago May 1-4th for MeshForum -- writer, historian, tech geek, entrepreneur, internet junky since '91 --
What I am referring to is NOT a "particularly severe" form of beaucracy - it is adhering to a policy that is designed to avoid unintentional (and intentional) problems that all the management in the world can't avoid.
If you have the ability to just "get in there and fix it" - you may or may not tell anyone that you did so - and you may not remember that you did it (or what exactly you had to do) when it comes time to building the application "for real".
The challenge of an organization is to put in place controls that are effective - they exist for very good reasons - if applications are being used by the business, but can not be recovered/rebuilt/patched because the developer who built them leaves - the entire company is at risk.
If you as a developer return to an application that you build 6 months ago to fix problems with it - you are setting yourself up for a nightmare potentially if your code is impacted by other changes to your applications, OS, or build tools in the 6 mths since.
In the company I am referring to the developer's themselves were the people making the decisions with regards to items such as "powerbuilder" vs. VB (using both for different purposes) - again though it was decisions made at the scale of the entire organization - just becuase you personally preferred a particular old version of FoxPro - that might not be the best tool for the organization as a whole to standardize on - and if you are the only developer in 1000 to know that tool - you are limiting your future at the firm as well (who really wants to only maintain an application they wrote 5 years ago - most developers prefer to be able to work on new applications as well)
If the developers have to wait for weeks to get their systems fixed the solution is also to make the development organization a much much higher priority than it appears to have been at your firm - management in general should be clear about who needs rapid responce - if developers who are highly paid can not work they should be put back to work quickly.
The point of the system I am describing was to make the development teams aware of each change they made to their systems - this was not intended to make change impossible - rather it was intended to make it just painful enough to remember to document and test the processs.
In the environment I am decsribing we also had systems in place to bounce back to the development teams their code if they were using pre-release/beta compilers or external libraries - this could easily result in delays to deploying their applications and all sorts of other nightmares (and more long days and nights for everyone) - there is a role for using beta/pre-release applications - but that role is not in supporting the business - it is reading the future development for upcoming changes - once stable then you can switch over.
-- Join us in Chicago May 1-4th for MeshForum -- writer, historian, tech geek, entrepreneur, internet junky since '91 --
Its next to impossible to lock down a network and still work when you are always uninstalling software and reinstalling software. Even for Support people its next to impossible. You end up having to put the user on hold, Find an IT person to come and login as admin and have them uninstall or do other things all while the customer/user is on hold. Its a very bad pratice to do. Some companys only have 1 IT person in house and a lot of times they will be on vaction and then your in trouble because you can't do anything. Companys should think ahead and maybe subnet different departments and give devo/tech emloyee's domain admin rights on a subnet as where sales and HR employee's really don't need to install, remove and do regedit stuff can be locked down more. IT will tell you its not really a problem as they can give you local admin rights on your machine, But what happens when you need to goto another machine to test or install. Its also a real pain to close all your applications and login as a local machine user just to do a 1 sec install/remove or regedit. I do Unix Admin and PC work myself part time so I know the pressure some IT people feel.
2 - "Proof in the pudding"
3 - Not everyone on /. grew up installing RedHat on web servers; I didn't.
4 - Fuck you very much for waving your worthless Sun cert and touting your "hardcore financial applications". I've written them and supported them alongside people whose names you know if you have any knowledge of Unix history. Let that sink in, you parochial fuck.
5 - It's not possible or desirable to sync dev with test with production in the face of a non-trivial version push (whether that's due to internal or external software). You're naive if you think there's any point in having three identical systems for these purposes.
6 - When I was doing production support on a large in-house 24-hour trading center, running applications my team designed and developed, we never needed to rush code from development into production. in spite of the fact that we were indeed dealing with systems that handled tens of millions of dollars in transactions an hour. Oddly, in eight years we never got to use our hot off-site backup trading center to do active trading. You did have one of those, didn't you? You know, "best practices" and all.
7 - Nobody called your workplace a nightmare (reread my post), although considering that an annoying fuck like you works there I might consider calling it one.
8 - Our company evaluated NT systems numerous times over the course of 4 years for various different applications and never allowed any installations other than the Reuters Dealer systems which Reuters was forced to support. Why? Because NT was never deemed robust enough to exist in our production environment.
9 - Fuck Marimba and fuck you too.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
Hi,
I uised to work in the defence industry, here we used to run unix machines & windows boxes. There was no externel net access other than from dsignated kiosk computers. There was an air gap between local network and www. PCs & Unix workstations had floppy drives dissables and use of data cds was forbidden and monittorred on computers, via some background app. This worked effectively (400+ developers). Only admins/support could install new apps.
Isolation is a nice goal, but makes for all kinds of headaches. Case in point: I work with embedded targets and our local PC network run NT 4.0 (no jokes, please...). The RTOS we use requires a TCP/IP connection for debug and file transfer. To get your code into the box you can either (a) go down two flights of stairs and use a flash burner to load your code or (b) hook up your target to your PC. You can guess what we use. Our IT department gives us zero support as developers. By this I mean that they will not allocate dedicated development workstations, routers, bridges, firewalls, PCs with extra network cards, even mechanical switchboxes - anything that will help us isolate our targets from the rest of the net. We get the exact same level of support that finance or human resources does. So, our developers are stuck throwing together kludges that are basically accidents waiting to happen just so they can talk to their targets and get their company mandated EMAILs. If our IT department were to implement a literal double standard, creating one policy that supports non technical users (go anywhere you want, but with restricted privilleges), and another for developers (play all you want behind your personal firewall), we developers could make all the mistakes we need to and not crash each other or the payroll mainframe. Such a policy would also reduce problems on our LAN, as a lot of our developers never mess with TCP/IP details - they're working on embedded GUIs or audio drivers. Once IT set up their isolating firewall, they'd probably never touch it again. Those that do much around... IT wouldn't have to (and shouldn't have to) clean up their messes. Sure, it probably won't happen in this lifetime, but I can dream, can't I?
"Prepare for the worst - hope for the best."
If you run win 95 (or 98/me) like i happen to do at the moment the solution is simple:
get a copy of poledit (it is on the install disk of 95 & 98 and you can download it with some effort form the internet).
You can simply unlock the registry and run. just don't tell anybody you did.
For oracle software (forms) you DO need access to the regsity to change things when chaning environments. at least in my situation.
You're right in your comments about the "average" developers. Most places I've worked, any employee only would educate themselves about the particular task they were performing, and would know nothing about things not directly related to their work.
That has nothing to do with developers, but has more to do with specialization. You can find admin type employees who can do nothing except changing tapes and add user accounts. You also will find developers who could not write a line of code outside Visual Basic.
On slashdot however, where people classify themselves as geeks, a large part of the population can be considered renaissance persons. Curios to learn new stuff, preferring to do it themselves rather than ask for help.
But you're absolutely right. The days of the renaissance man are over, and most drones can only wear one hat.
That is not something I like, though. I think most developers can benefit from doing unfamiliar tasks, such as setting up a UNIX box, creating a database, write some lines of code in a different programming language, add a hard-drive, fill out a purchase order, or even open up their PC cover to install memory. Dabbling with such things removes the mysteries and fobies. In addition they find out that there's much to know and learn in those fields. Instead of saying "I've never set up a box, but how hard could it be when those IT clowns can do it?", they can say "Wow, I managed to set up that box. It wasn't as hard as it looked. But I sure can't figure out this routing, dns, and nis thing."
People should be encouraged to do things outside their domain, not punished for it. By heavy-handedly forcing people to extreme specialization, a company is doomed in the long run, by creating an atmosphere where renaissance men are converted to lab rats.
Sounds like the most insanely expensive method to do the equivalent of a network boot I ever heard.
Is there a reason they couldn't just go with diskless machines?
-- Another senseless waste of fine bytes.