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.

Newsflash: sponsored study shows results that favor sponsor. Truly shocking.

Having worked as a contractor for Goddard Space Flight Center years ago on a few projects, I can assure you that SpaceX's way of doing business is completely different than the old school space business. Coming from NASA, which trickles down to Boeing and Lockheed, the standard mentality is do everything at least twice, and usually triple checking all of that. New processes are frowned upon and twenty year old technology is still considered new, potentially even unproven. It is a frustrating way to work for a lot of people because it moves so slow. However, it is fairly safe and effective.

Now, enter SpaceX. I suspect they have a lot of the old NASA engineers, so they have the experience to cut corners. However, they've designed the thing intentionally to tolerate failures - they stuck 9 engines on the rocket. And you definitely want to tolerate failures, however, it does lead to mistakes. Look what happens though when one engine fails - the extra burn time meant the Orbcomm secondary payload on the last mission failed and never made it into orbit. That wasn't highly publicized, but it was a partial failure.

Now, what we're going to run into the standard cost/benefit of the extra work that goes into Boeing rockets. Is it worth it? Well, I suspect once you start sticking people on the top of the rockets the tolerance for failure goes down. Personally, I love what SpaceX is doing and I think a lot of the stuff is cutting edge. It is the direction we need to be headed, and I personally think the risks are worth it.

Better - Faster - Cheaper

You only get two.

See my other reply for more details. But specifically:

1. We don't really have a home phone. My wife and I only have cell phones. However, we are required to have an analog telephone line because we have Internet service at home. We don't use it, but the rural telephone co-op ONLY sells their Internet service bundled with phone service. Let me repeat that - it's not possible to purchase unbundled DSL here. They are not an ILEC, so someone like Covad has no access to the local loop. Since they have a monopoly, they can require that and further, because phone service is regulated by the FCC and by providing it, the rural telephone co-op gets USF funds. I think they get like $50 a month from the USF just for providing phone service to our house that we don't use. That's on top of the $45 a month we pay for the PHONE service. So technically I could hook up an analog phone in the house, but I don't want to deal with another phone number in my life, there's no reason for it.

Realistically, there are no other Internet providers here. Satellite is too slow, we use too much data for our 3G cell service. We don't have cable. So our service at home is super expensive compared to elsewhere, but it is pretty good. Their pricing is super weird, so at work we have relatively inexpensive service for what we're getting.

2. Regarding at work, see my other reply. We can't port our numbers to another provider, and that's a problem. Switching numbers is a pain in the ass, but it's something we'll likely contemplate in the next year as we both clean up our published numbers (we used to have over 50 published numbers, I think we're down to about 10 now.) Setting up call forwarding on 50 numbers for a few years would be really expensive, but for 10 numbers it becomes feasible.