I’m not only a computer geek, I also spend considerable time renovating our home. Doing things yourself means there’s plenty of opportunities to make geek-friendly adaptions, such as preparing for a good home network.
Renovating a house is a major strain for the family economy, so keeping an eye on the cost has been a priority. I’m also a bit reluctant to invest too much in today’s state of the art technology, only to find out I need something else in just a few years. Considering that we’ve had the house for nearly 10 years things have indeed changed. Back then wired networking for computers was the main concern – now it is proper wifi coverage for all the phones and tablets that didn’t even exist back then.
My take on a future proof investment is to install a lot of empty cable hose. Then I’ve pulled CAT-5e cables to those places where I actually need it. Everything converges in the cupboard under the stairs (no, it’s not used as someone’s bedroom) where I have a small 19″ rack. In the rack, I have my home server (more about it below) and the central switch. The white box on the wall above the patch panel is the incoming fiber.
TL;DR A component licensed under LGPL can be used by closed source, proprietary software, both internally used and distributed, for free, with no effects on the software using the component. LGPL is not “contagious” in the same way as GPL, so it only affects the component under LGPL. As long as you’re only using official distributions of the component, it is free to use and free to redistribute. The only requirement is that you include a notice in your “about” page or similar that the component is used.
I often get questions about the LGPL license used for Kentor.AuthServices. I also often find it confused with GPL, which is something you should never, ever even consider to use in any closed source software that you intend to distribute. So this post is an effort to explain and answer common questions about the LGPL. Unfortunately I have to add the disclaimer: I’m not a lawyer and the content of this post is only meant as an overview and introduction to the license. I might have got things wrong, so please read the real license yourself and involve appropriate legal counsel to be sure.
I’m grateful, humbled and proud to receive the Microsoft MVP Award.
Ever since I first heard of the MVP program nearly 15 years ago I’ve had a great respect for those receiving the award. The MVPs I’ve met and got to know have all possessed that rare combination of deep technical knowledge and the social skills needed to communicated them. I’ve read blog posts, attended talks, watched videos, used open source and read open source by MVPs and learnt so much from them. And now I’m also an MVP. As much as I’m grateful and proud I’m also humbled (and a bit horrified) about being invited to be one of them.
Thanks for giving me the chance, now it’s up to me to prove that I’m worthy of a renewal next year.
Static Analysis has interested me for nearly as long as I’ve been coding, so when I was offered to try out NDepend I got really excited. I already rely on the warnings the compiler can give and code analysis rules for my projects and a tool such as NDepend seems like the next logical step. I was not disappointed.
I think that the code analysis rules offered by Visual Studio are powerful and helps improve code quality, but they have a user experience that’s more punishing than encouraging. Code Analysis rules are evaluated after the code is written and after it has passed the compilation – which means when you are sort of done. Then it comes and tells you that you’re not done. That’s demoralising. There’s also no hint of how many rules you did in fact dit pass. The NDepend analysis is different. It is run from the NDepend Dashboard and it shows not just rules violations, but it can also show that your code is good.
This has been one of those annoying bugs where everyone’s solution works perfectly by itself, but combined they fail. I closed this issue in AuthServices with a comment that “works for us, has to be IdentityServer3/System.IdentityModel.Tokens doing something strange.”. I’ve finally had some time to look deeper into this thanks to IRM that asked me to do this as a consultancy service. Without someone paying for the time, it’s hard to spend the hours needed to find the root cause of a problem like this. When I started out on this I looked at all three systems/components involved to try to understand what triggers the problem. I ended up fixing this in Kentor.AuthServices for now. The fix could also have been done in the .NET Framework, IdentityServer3 or System.IdentityModel.Tokens.Jwt. Doing it in Kentor.AuthServices was mostly a matter of convenience because I control it myself.
That means that the TL;DR of all of this is that if you update to Kentor.AuthServices 0.19.0 or later this problem is solved. If you’re interested on how to solve it if you add SHA256 support yourself, please read on.