Posts by richard.grimes

Scumbags can program vulnerable MedTronic insulin pumps over the air to murder diabetics – insecure kit recalled

Hacking can be good

I've been T1D for 4 decades and MDI (multiple daily injections, sometimes 10 times a day on a bad day), I know a lot of people who use pumps so I have some knowledge about this.

First, bear in mind that if I inject 10% too much it will send me hypo, and potentially it could be so low that I need help from others. Insulin is a dangerous drug (and I would say that when it comes to type 1 diabetes the worst people are GPs who know nothing about the condition but still want to tell people like me how to live my life yet because they are a doctor I am expected to obey them <rant over>). So hacking a pump can be dangerous.

However, there is now a thriving community of T1Ds who are hacking their pumps. These are the so-called "loopers" who are trying to create an "artificial pancreas" by connecting a continuous glucose monitor (GCM) to a pump via a Raspberry PI (or similar). Loopers *can* get very good blood sugar control doing this. However, because it is not regulated it is *entirely* DIY. Also pumps and CGMs do not have open APIs so looping can only be carried out via hacking.

Medtronic have their own looping system MiniMed 670G and clearly they want loopers to ONLY use their system. hence it is a closed API. It is interesting that they use an established (or some would say old fashioned) PID feedback looping. I am not a looper, but I should point out that loopers use other algorithms other than PID which are potentially better.

Interestingly, at a recent diabetes conference there was a lot of complaints from T1Ds who use Dexcom CGM because the radio signals were interfering with other Dexcom users!

So I do wonder if this recall is more about preventing DIY loopers from producing *better* systems.

Ten years of .NET - Did Microsoft deliver?

Mixed, but generally good

In general .NET is a success, but it has its problems. First a few corrections to the other comments.

,NET languages are not interpreted, like Java the code is compiled to an intermediate language and this is just in time compiled (on a per-method basis) at runtime by the virtual machine. The JIT compiler was written by people from the VC++ team and hence is optimised. The performance of JITted code is nearly as good as native C++.

Incidentally, WinForms is not a performance hog. It is a very thin wrapper over Win32.

Microsoft have always been careful to avoid the Java "write once, run anywhere" concept, for good reason. As every Java developer knows, it degenerates into "write once, test everywhere". Consequently .NET code is compiled for one platform. Yes Silverlight can run on different platforms but that IMO is an exception.

One of the principle reasons for .NET was the security model. .NET security was in addition to NT security and added a new concept: code gained permissions to execute other code based on criteria other than the logged on user (things like the source of the code, X502 certificate, hash etc). This is a very important change. This model stopped the existance of .NET viruses (other than the most trivial phishing malware).

Up to Longhorn there was a semblance of a strategy. Longhorn was supposed to be the culmination and the OS was supposed to be substantially .NET. The version handed out at the 2003 PDC was many years of development, and all development had put .NET first. The shell was based on WPF and part of the file system was based on an object database called WinFS. It was ambitious.

However, after the PDC Microsoft very hurriedly dropped Longhorn, re-jigged Windows Server 2003 and added a slimmed down version of .NET. WinFS was gone. Initially they didn't even install WPF or WCF. They went from an OS that could not work without .NET to one where they appeared to be embarrassed about the framework. My constant comments about this tepid acceptance of .NET were not welcomed by Microsoft :-( and later I learned that there was a lot of internal politics involved at Microsoft between those who supported .NET and those who didn't.

The problem with this political battle is that the overall strategy was lost. There was no longer a credible plan to what .NET represented. The result is a confusing plethora of libraries and additions to the languages. This isn't to say that .NET is bad - quite the opposite in fact - but it has lost its way. There does not seem to be a coordinated strategy.

What is its future? Well, the first point to make is that COM will always be in Windows, .NET will not, and cannot, replace it. (Simple example, drag and drop uses COM. Without COM you will not be able to drag and drop items between applications.) But similarly .NET will always be in Windows, since there are tools in Vista and now Win7 that are written in .NET. As yet Microsoft does not trust .NET for their services, but they do allow third parties to write services with .NET (knowing that Microsoft do not provide Windows services written in .NET should you trust a third party .NET service? I cannot answer that.)

Microsoft will continue to develop the library and framework, but the developments will be sporadic, they still have no overall strategy of what .NET means to the Windows platform. If you intend to write a new application then the best course is to write it with .NET: VS makes it easy to do this. If you have an existing application in C++ or VB (classic) keep it in its original language. You can wrap existing code as COM objects since .NET access to COM is high performance. (However, porting native code to .NET is a recipe for disaster.)

If only Microsoft could decide themselves what .NET means to the Windows platform!