I have our marketing department handle all of our web stuff and they outsource it. I don't know the exact details of the inner workings of the magic used by our web company, but I know it's based on Amazon's EC2 infrastructure. I'm sure as a non-profit that you're extremely cost conscious and something like that might be a good fit for you. We're highly seasonal in our work, so during the busy times of the year they ratchet up the compute services available and we pay a few extra dollars. Then during the off season we ratchet it back down. It works WELL. In general EC2 is considered overkill for small sites, but for high traffic sites it's considered very affordable. When you say 1000 nailing the server with page requests, it makes me think it would be on the affordable side for you.

Now, we're not exactly their favorite customer for a million different reasons, and the working relationship is.. um.. strained. So I don't think I'd recommend the exact company we use, you can surely find others near you if you need help. If you want to try to roll-your-own, here's an (old) example of what you're looking at: http://www.sunsetlakesoftware.com/2008/09/13/running-drupal-website-amazon-ec2

I've worked in the IT industry for 20 years, 7 of which were in telecom.

I find it so damn amusing that all the computer geeks still struggle with basic things the telecom world figured out 30 - 50 years ago. There's a lot to be learned from the old school carriers, and this is one of them.

Most of the bigger carriers have their own stuff that'll track everything from pairs/strands to binding posts, etc. You need to know sizes of entrance protectors and all kinds of other things. Sizes of splice cases and the number of trays are nice to know. Everything needs to go into GIS, and that used to mean a second system that references locations. These days there are integrated packages. The exact system we used was purchased by NEC and no longer exists. And actually, I wouldn't recommend it, we used it primarily because the work order system was quite robust and we were willing to sacrifice some of the documentation features for that.

Would something like this work?
http://www.bentley.com/en-US/Products/Bentley+Fiber

Cisco and most other vendors have made 10Gb ports too expensive and/or don't have a backplane that can effectively support 10Gb across all the ports. This is pretty ridiculous given how cheap processors have gotten. Even when they do support it, the licensing and maintenance costs can be crazy.

For that reason we're currently deploying several 1Gb connections to our VM servers through various switches (depending on costs per port, reliability needed and location).

I've been hoping that late 2013 is when 10Gb will finally appear for us on our campus trunks at least.

So, speaking of frustrating Microsoft OS's, anyone else tried Server 2012?

It seems to be quite a bit faster than 2008 and set up to run as a VM well. HOWEVER... it has taken a giant step backward in usability. No Start menu? Ok, I can adjust to that. However, getting to all the tools to administer a system is frustrating at best. What the f*ck were they thinking? Right now our average 2012 desktop consists of 20 - 30 shortcuts to administrative tools so we can get into things as basic as a control panel or an Event Viewer.

I understand Microsoft wanting to move everyone to using Powershell, I get how powerful the commandline is - I've been using Unix/Linux for 20 years. However, using bash and other commandline tools makes sense. It seems sane and has always been intuitive to pick up. A quick man page look up usually fills in any details that are out of the ordinary. Powershell and Microsoft's objects? Wow.. no idea who designed it but intuitive is not a word I would use to describe it. I suppose the command names themselves are ok, a lot of times you can guess them with a "Set" or "Get" prefix, but the way you pass the object references and the various command parameters are a complete pain the ass. Powershell is a nice feature, but completely ripping out nice graphical tools to do complex and infrequent tasks makes no sense.

The Office-Exchange combo is definitely powerful as others have noted. However, I think we're at a point where it's getting more and more feasible to consider replacing it and there are reasonable alternatives.

What we really need is a complete AD killer. Samba can do it - the nuts and bolts are there. However, it's really rough around the edges. What we really need is a complete drop-in replacement for AD that also includes all of the integration with enterprise tools and has an interface like Microsoft's interface. We want to manage group policy objects, passwords, security groups, etc in the same manner we do now. We want Exchange to think the user accounts are all sitting on a Microsoft DC. Sure, this can all be done with Samba, but it needs to be as braindead simple as it is with Microsoft.

Yes, Linux has had various tries at directory tools for years, but they don't integrate well with Windows desktops. They're also clunky and it seems like the tools change from with no consistency.

Also, here's a plug for the Samba guys - great work guys. I don't think most people realize just how little manpower that project has. There's really less than a dozen core developers and they manage to pull off some amazing stuff.

Yup. Same here. I think there's a bunch of retards running this site now.

I managed to go 16 years in the IT world, first as a sys admin and now up through an awesome mid-level management position, without any serious data management scares. (And by 'awesome', I mean I work for demoralizing leadership and I've hit a glass ceiling which will force me to go find another company to work for if I want any shot at career advancement.) I've always made sure there's many, many layers of redundancy and good processes in place.

That was until three weeks ago.

We use Microsoft DFS to sync data between two sites. Because of some other things going on, we had to turn DFS off for 3 weeks. We thought we had everyone transitioned to using the "master" file repository, the one that gets backed up every night, etc, etc. The day we turned on DFS back on, all hell broke loose.

Oh - and this is fairly important stuff: 10 years worth of CAD, design, and legal paperwork. It's a few terabytes worth. For our medium-size company, this is basically everything that we hold near and dear.

The first thing that happened is DFS completely puked and completely trashed BOTH filesystems. Fantastic, Microsoft - what a wonderful piece of shit DFS is. Fairly quickly we had to face some data integrity issues. First, we discovered apparently there was a fella at the remote site that was using the copy of files there. Great.. through a fairly manual process we were able to retrieve most of his changes to the dataset. Next, we fairly quickly gave up on trying to fix the DFS - on the advice of Microsoft it seemed to be fairly hopeless.

This is where shit gets real.

Our head sys admin had been troubleshooting an issue with a drive in a RAID'ed NAS backup device had failed. All the other backups had been shifted to other NAS devices, but that backup was so large that it apparently had just been failing. While looking for that, we also discovered the quarterly backup from December had failed (that's the point where I wanted to put on my manager hat and go rip someone a new one, but decided that probably wouldn't be the most productive thing at the moment and could save that little teachable moment asskicking until after we were out of the woods.) Now, the sys admin hadn't been completely foolish, before turning DFS back on he had run some full backups using a different NAS device.

In a f*cking brilliant stroke of disastrous luck, when we went to perform the recovery we discovered that RAID array on the backup NAS device also had corruption.

Now, how bad the corruption was and what exactly that meant remained to be seen. The backups had completed without error, it was the NAS filesystem itself that was throwing the errors. The NAS was still running and our backup software seemed to recognize the backup catalogs on it. Ok, other than what seemed to one potentially corrupt backup, it was seeming like the next best case scenario was a quarterly backup from September, and I was also staring a complete set of disks from 2010 dreading the thought of bringing them back online. Well, with nothing to do other than try a restore, we pressed the button.

That's when I went home mid-morning, chainsmoked four cigarettes on my porch and wondered what would happened if everything went south. In other words, I was contemplating my next job.

'Lo and behold, and restore worked. We had to merge all kinds of things back together to get a complete copy reassembled, then we still had to get DFS working (which took four days of syncing over the WAN.) When it was all said and done, it looked like there were just two files from one set of changes that we couldn't recover.

I think I'll go double check on the backup jobs now.

Holy crap! They can link to Khan Academy! That'll fix everything.

If there was a severe shortage of programmers, every programmer you know would be making $100k +.

This smells like a ploy simply to get Congress to pass legislation to allow more visas and drive down salaries. This smells like a trick to justify offshoring more jobs. This smells like some kind of crap to get Congress to approve tax incentives to companies that have programmers most likely already on staff - not actually hiring more. In other words, this whole thing seems like a way simply for businesses to make more money - not to provide more jobs and certainly not to educate/train people.

Watch - there will be a ton of marketing events and a lot of face time on major news networks. What you won't actually see is any education, any grants for students studying CE/CS, or any job creation.

Guess what, Zuck: if you want to offer me $150k for a mid-level programming job because there's a lack of programmers on the market, I'll dig into my closet and dust off my old programming hat. Until then, quit whining.

I put in a small Revo DVR unit with webcams last year for a small business. It was $800 and I think it was a lot of bang for the buck. It had alarm inputs, whick are simple enough that if you're on a budget you could set up on entryways. The cameras were motion detecters, IR, etc. I definitely recommend it.

The other reply is correct, that you still need all of the Wine libraries after you port the app using Winelib.

However, there's a dirty little secret about Winelib... it doesn't necessarily work. Well, it could work, it should work, but it never gets tested. Wine has a fairly extensive toolchain itself, it has bits written in assembler and it requires other libraries, such as CUPS or until last week OpenSSL. Getting all of those pieces working nicely together requires maintenance and it really doesn't get any. Every couple of years someone will pick up Wine and get it running to some degree on SPARC or something, but there are no active daily developers doing any work with it. There's been merges for ARM in the last six months, but there's more work to be done there. Until a few years ago when the OS X port took off, Wine mostly only got used on Linux. There were some FreeBSD efforts, but really it was one guy who only occasionally had time to fix bugs the crept in on that platform.

The only advantage to actually porting an app using Winelib is to move to another architecture. That might be something of importance again with ARM emerging as a dominant force in the mobile world. Otherwise, if you're running on x86, skip a Winelib port and just run the native Windows app. The other advantage here is that Visual Studio will compile much more optimized Win32 code than gcc + Winelib (at least that was the case 6 years ago and I suspect it still is.)

Disclaimer - I haven't been actively involved in Wine development for quite a few years, but I used to be. Someone else will probably chime in and either correct me or give more details.

Running Wine on ARM probably won't run native Windows binaries. That means you're not going to be running MS Office on your S3 any time soon. To make it really work you'll likely have to specifically recompile the Windows app using Wine in the form of Winelib or do some kind of magic like qemu to get the big-endian / little-endian differences solved. That's on ARM though.

With Intel pushing their Atom platform, all of this would probably work out of the box, and it would probably actually work pretty good. Running the latest version of Photoshop or playing Diablo III might be a stretch on that platform, but realistically you could probably run a version of MS Office or enjoy tons of classic games.

Processor speed will be an issue - Wine has decent performance, but there's a lot of libraries that need to be loaded to make even a simple Windows app run. The latest quad core processors in the mobile world might be enough.

Here's the key: apps and/or app stores.

A lot of small businesses, such as the one I work for, have built some apps for iPhone and Android. However, our budget simply doesn't allow us to build an app for every single phone out there. For example, we're definitely not going to bother building one for Windows or Blackberry. We also have an internal app that runs on Android and we won't be porting that either.

So, I think the best way to get a new phone out there is to steal an ecosystem. Either an entire app store or make porting the apps as simple as the click of a button.

Well, don't you think you're so smart telling me I was doing it wrong. Of course we used custom policies. We pushed all kinds of crap over the years, including in-house apps. Because, ya know, it's a lot of fun to know how many people have been out skiing all day or what the f&b yield was. Even disabled a few devices over the years. I will never, ever miss BES.

Now we've switched to a BYOD policy for about 75% of our employees. On the expense side, we're really saving a lot of money and employees are happy because they just have one phone. (Unless they really want to have two.)

Whenever I think of RIM and Blackbery the first thing I think of is how happy I am we no longer have to administer a BES server. I am completely overjoyed that we have managed to rid ourselves of Blackberry's. BES was certainly an interesting piece of technology, but the level of complexity it added to get a calendar and email on my phone was enormous. It seems like yearly it would break in a new and mysterious way - kind of interesting in 1999, really annoying in 2013.

In fact, to celebrate BB10 being released, I think I'm going to dig up an old CD of the Blackberry Enterprise Tools or maybe an old Blackberry Curve and go burn them in the fire pit. (And yes, we have a fire pit at work.)

Ok.. those are strong words in the subject, but inducing a culture change quickly is something you can incentivize. I'm not sure of your particular situation, but here's two ideas:

1. Bribe them. Companies usually call this merit based bonuses. Break the goals of the team(s) into individual goals. If a particular module is due to be rewritten for the next release, then pay a bonus if it gets done correctly and on time. If it's not done correctly, don't pay the bonus. If it's not on time, don't pay the bonus. With regards to it being "correct", that falls into the next item..

2. Punishment. If the code sucks, don't commit it. Force the programmer to rewrite it. That even might mean rearchitect it if there was architecture involved. Programmers hate repetition. They will very quickly learn that if they are forced to do something over that they can do it better the first time. If they find themselves working late hours to meet a deadline, perhaps because a bonus is riding on it, they'll get better.

Most important, make sure your deadlines and features are realistic. Are you sure they are? Are people being sloppy because they feel too pressured? Shipping a buggy feature isn't a feature.