Lately I have had an issue on a Linux based server that is running Samba to share files.

One directory in particular would show up as empty even though it had plenty of files inside of it. This didn’t always happen though. Sometimes it was fine. Then it started happening to other directories as well.

I was stumped for a while. I started going through the log files looking for reason which I found:

Cisco today warned that more than half the websites that OpenSSL are still vulnerable to Heartbleed attacks.

The bug has been public for more than 9 months now and many servers are still not protected.

The Heartbleed bug, discovered in April last year, is a flaw in a software used across two-thirds of websites, allowing hackers to request information, such as passwords, stored in a computer’s short term memory.

John Stewart, Cisco’s chief security officer, said users did not know whether websites they are visiting were safe. Hackers used Heartbleed to hit the Canadian tax authority’s website and the UK parenting website Mumsnet, among other services.

“When we travel around the internet, we don’t know if we’re going to current versions or not,” he said. “More than half of the sites are using very vulnerable versions of SSL.”

It is hard to not to get blasted with dozens of github links on a daily basis.

Github has grown to be the social network for coders and wannabes, and like all social networks people compete to bring attention to their profile.

One way they go about it is to post about their projects on hacker news, reddit or some blog somewhere that I am sent a link to. Some of them sound really amazing and useful.

I used to be filled with joy at the vastness of the code available and all the amazing projects that lived there. And this is still true. There are an amazing gems on there, but like all gems, they are buried in a pile of dirt or more appropriately here “vaporware” and / or “dead projects”

Some are very easy to spot. The repository consists a long readme file that lists everything the projects does and little else. Someone had a dream and maybe it will grow someday.

What I find much more frustrating are the projects that have a nice readme file and code in the repo. But when you start digging into the projects to learn what cool algorithms its uses and how a feature is implemented it is not there. Lots of code files but nothing of substance.

When you start digging in you really have no idea how far along a project is. The “advert” / link you followed to get there promised unicorns swimming in gold, but what you find is a bunch of nonsense. The frustrating part is that you have to invest a good deal of time to come to this realization. After this happens a few times in a row you become weary of investing your time at all. This is a very damaging result. Good open source projects need eager people to dig in and help.

I suggest a “vaporware” indicator. This would let me easily assess the state of a project without digging through obscure code files only to be disappointed. By default all projects are vaporware. The contributors can reduce the level of vaporware and visitors can vote to increase it or decrease it.

Another indicator I would like to see is a “dead project” indicator. This is partially there already when you look at project activity but a nice badge would be easier to spot.

There are thousands of projects that are both vaporware and dead and that will in all probability remain in that state forever.

Given that github already has a “gaming” aspect to it, like everything these days a nice carrot would be a badges like: “Certified Real”, “Actually Works” , “Production ready”, “Ships in Ubuntu 10.1”, “100 000 current users”.

This would give everyone who clicked into the project a quick way to assess its status and evaluate whether its worth their time or not. Some ideas are so good that even if the project is in a state of vapor people will still flock to them to create something special

I was writing a script to automate group creation and permissions for Office 365 today, and had to install the Windows Azure Active Directory Module for Windows PowerShell when I ran across a curious error.

The error itself is self-explanatory or so I thought.

I downloaded and installed the Microsoft Online Services Sign-In Assistant and then prompted restarted my laptop.

Unfortunately, I received the same error all over again.

It was as if the install never happened.

After trying far too many things I ended up trying to install the AdministrationConfig-en.msi via Powershell and msiexec running as administrator.

msiexec.exe /a ‘C:Userssome.oneDownloadsAdministrationConfig-en.msi’

This allowed the install to go through and I could get back to scripting groups and users.

Now this could happen if one project in the solution was not compiling, but every project in the solution compiled without error. The natural next step is to do a Clean / Rebuild which I performed, but the error persisted. I went through the properties for a recent project I added to the solution and that was fine as well.

Eventually I found a solution online:

Manually clean each project separately

Manually rebuild each project separately.

Why should it matter if you do a global clean and rebuild or a manual rebuild of each project I don’t understand but it is how I fixed the problem.

Usually I have been using stsadm when I wish to install wsp files / solutions on a SharePoint farm.

Since I switch back between SharePoint 2010 and SharePoint 2013 environments often, having to remember two different ways of doing the same thing is annoying. You can however use Powershell to accomplish this in 2010 as well: