Thursday, 11 February 2016

Darts sight-right checker

After becoming engrossed with the darts on BBC over the New Year, it didn't take long for darts to become another fleeting infatuation. So, obviously, it was only a matter of time before a Winmau Blade 4 dartsboard and a set of Ted "The Count" Hankey "arrows" turned up in the post, thanks to those kindly Amazon carriers.



Darts is a great game. And easy to get into. Just about every pub has a dartboard, tucked away somewhere. And a decent set of darts - even like those used by top darts players - can cost less than twenty quid.

It wasn't long before the five and nine beds on my board were starting to take a battering. Hitting anything like a twenty, let alone a treble, was a pipe dream. To land anywhere in the twenty bed more than once an almost impossibility.

(it took only about forty-five minutes to get two arrows in the twenty bed at the same time!)

Despite this, I was getting better at "grouping" the darts - getting them within a few millimetres of each other in the board - just, more often than not, grouped around the nine or twelve beds.

Apparently, it's quite a common problem. You stand in front of the board, line yourself up with the treble twenty bed and hurl the darts. Except they drift off to one side. Or if they do land in the centre bed, they hit the board at a bit of an angle (the photo above shows a typical left-handed throw, with the arrows leaning into the board from the left).

And it's all because where the dart is being thrown from is not in front of the treble twenty. Although I might be looking at that bed, where I'm standing is not actually in line with it! Just a single image from the Winmau website gave me the answer to what was causing the problem, as well as how to fix it!

(this image shows the problem encountered by most right-handed players; as a left-handed player, I have the same problem, but mirrored).

So, at the next nerd night - and with some help from the others, as I can't always be trusted with sharp instruments - we set about building our own "sight right". The idea is that you place the "sight-right" at the foot of the dartboard, with the white line in-line with the bullseye. Then, stand at the oche in your normal throwing position. If you're off-centre, the white line appears as two broken pieces.

Move along the line, left or right, until the white line becomes a single, solid, unbroken line. At this point, you should be centred with the dartboard. And any arrows thrown should land in the centre; and if they do, because you're no longer throwing them into the board from an angle, they should be nice and straight. And nice straight darts mean that even if you miss the bed you're aiming for, the dart isn't lying at an angle, effectively blocking it for the next dart that follows.

The sight-right from Winmau isn't expensive. But when you add in carriage, and consider it's just a few bits of wood, it made sense to use up some of the stuff we had lying around at the BuildBrighton workshop.

First up we grabbed some 18mm mdf and cut the base.
Then, with some 18mm offcuts, created a "shelf" and stuck this on top.
Lastly, to make a three-part rather than a two-part sight-line, we stuck some 30mm batten on top of the shelf



All that remained as to draw in the centre-line and paint the whole thing (matt black, using blackboard paint, so as not to be dazzled by lights reflecting off it).

We also saw examples of these "sight-rights" online where the double-ten and double-sixteen lines were also painted in. As double-sixteen is a popular finish in darts (and double-ten a favourite for left-handed throwers) we thought it a good idea to include these too.

As most binary-number-addicts will understand, double-sixteen is a great number to finish on because if you miss by just a fraction and land in the single sixteen bed, you can immediately move on to double eight. Score a single eight and you can go straight to double four, then double two and finally double one. Other finishing scores usually mean having to throw for a treble or other non-finishing score at some point, if you keep missing the double!

So begin with, we stuck a dart in the middle of the bullseye and hung another dart from it using a bit of cotton (there's nothing hi-tech about this project!)


And marked the wood where the tip of the other dart touched


This is the centre-line for the sight-right. We then repeated the process by placing the first dart in the dead centre of the double 16 and double 10 beds. After marking the lines, painted the whole thing black and painted the white lines (with an old almost-crusty-dry pot of Tip-Ex!)

Here's the finished thing:



And the result - immediately after using the sight-right - was that the best score from three different players was.... 37.

Unlike a lot of "try-and-see" projects, we're refusing to call this a failure. The sight-right does actually work. It  makes throwing the darts easier and you feel more relaxed when throwing from the correct place. The trouble is, there isn't a decent darts-player between us! Maybe - with some help from the sight-right - this will change over time.....

[EDIT] Just a few days after using the Sight-Right, I noticed my darts grouping was getting better. Unfortunately there was no-one else to witness it, so I'll only be accused of setting the whole thing up, but here's a photo of the highest score I've ever managed at darts.


Onnnne - huuuunndred and forrrrty!


Wednesday, 10 February 2016

Installing OpenCV/SimpleCV on Raspberry Pi

On a recent project, we were having difficulty successfully detecting the presence (or lack of presence of) people. On the face of  it, it's quite a simple problem: stick an ultrasonic range finder inside a device. When someone stands in front of the device, the range goes down, indicating that someone is present.

In fact, this is exactly the approach we initially used. But it wasn't without it's problems.
To begin with, the range sometimes didn't go down. It actually went up! A bit of investigating and we think we found out why: place a hard surface in front of an ultrasonic sensor and you can get very accurate distance measurements


Easy.
But put a big lump of meat, dressed in a woolly jumper in front of the sensor (a person) and the sound is dampened. And reflected off at funny angles. And basically mangled, to the point where the return echo actually takes longer than it should to get back to the transducer. Now, instead of consistent, solid readings, you get a measurement greater than you should - not because the object is far away, but because it's squishy and has absorbed/distorted the sound waves.

High end ultrasonic sensors also include a degree of self-calibration. So the problem is exacerbated if it's getting a load of differing values reflected back. Quite often, the sensor will "calibrate out" the squishy meat-sack and it appears that nothing is there.

So when you first stand inbetween the sensor and a hard surface (like a wall) the range reading actually goes up, not down. This is ok, we can simply look for a difference in range and use that as a trigger. But as long as you stand in front of the sensor, dampening/absorbing the sound, the sensor will re-calibrate and return "nothing found" results (usually it just returns it' maximum range value, but the result is the same).

Move about, and occasionally, in among the "maxed out" values, you'll see a shorter value, indicating that the sensor has seen something up close. But the values are only just good enough to use as a trigger - and certainly not for determining how close a person is. It's the difference between a "person sensor" and a "movement sensor".

We tried a couple of other ideas - PIR sensors work well, but only as movement sensors, not person-proximity sensors. We even tried laser-range-finders. But if you wear dark clothes, it's enough to scatter the returning laser beam to make the readings inconsistent (they are designed, after all, to bounce off the walls of a house, not people).

So we came up with a bit of  a weird idea: we want to detect when someone is standing in front of our device. Preferably, detect when they are also facing the device. People have faces. Why not use face detection?

  • If they're in place, but facing the wrong way, we don't want to trigger.
  • If they're not in place, but their arm gets in the way of a sensor, we don't want to trigger.
  • If they're too far away - or too close - we don't want to trigger.

We basically want a trigger when someone is stood at the right distance, facing the device.

So why not stick a camera in the device, shove a Raspberry Pi inside it and use face detection? Most face detection routines can create a bounding box around a face - we could use these co-ordinates to determine how close (big) the face is and how far off-centre it is, to determine whether or not we should trigger.

What a handsome guy! And not looking weird at all.

So for the first time in a long while, we set about putting a fresh install on our model B+ Raspberry Pi. Getting the operating system working was easy enough - there are plenty of tutorials on how to do that - copy noobs onto an 8Gb sd card and let it do it's thing.

Getting the PiCamera working was equally as straight-forward: Google PiCamera and follow the instructions (even the sudo apt-get install stuff is just a matter of using copy-and-paste and letting the Linux/Debian operating system do its thing)..

Installing SimpleCV wasn't quite so easy.
The instructions at https://github.com/OpenLabTools/OpenLabTools/wiki/Using-the-Raspberry-Pi-camera-module-with-SimpleCV looked simple enough. But simply didn't work!


Trying the sudo pip install command that a lot of websites link to caused a whole raft of error messages, with no real clue about what was going on, nor how to fix it (I'm sure the answer is in there, but for a Linux-noob, using copy-n-paste to install stuff, it all looked like gobbledegook!)

Luckily, the answer was found at http://raspberrypi.stackexchange.com/questions/6806/simplecv-installation-on-raspberry-pi which suggested that trying to "pip install" something meant the package was download and unzipped/deflated into memory. And that was just too much for our little Pi to cope with.

So we used sudo wget to download the zip file to disk, then sudo pip install file to install from a file location, rather than a URL. This time the install worked just fine, and it wasn't long before we were bashing Python scripts to capture faces and highlight their locations:



Although our code is, by now, heavily modified, here's where we started from, capturing an image from the Raspberry Pi camera and processing it, to find a face:
http://www.open-electronics.org/raspberry-pi-and-the-camera-pi-module-face-recognition-tutorial/

#!/usr/bin/python2.7
# Programma test Haar Features

import picamera
from SimpleCV import Image
import time

with picamera.PiCamera() as camera:
       camera.resolution = (640, 480)
       camera.start_preview()
       time.sleep(10)
       camera.capture('foto.jpg')
       foto=Image("foto.jpg")

       print(foto.listHaarFeatures())
       trovati=foto.findHaarFeatures('face.xml')
       if trovati:
              for trovato in trovati:
                     print "Trovato alle coordinate : " + str(trovato.coordinates())
                     trovato.draw()
       else:
              print "Non trovato"

       camera.stop_preview()
       foto.save('foto1.jpg')
       foto.show()
       time.sleep(10)

The last stage for our project is to have the camera continually running (it takes about 10 seconds to initialise, so we'll set it running, then leave it) and use the GPIO pins to make a request. We'll use an Arduino/PIC or other microcontroller to send a pin high - effectively asking the Raspberry Pi "can you see a face". During the image processing, the Pi holds a different GPIO pin high to act as a "busy" line. When the controller detects a high-to-low transition on the busy line (as the Pi returns it low to say "finished processing" the controller can then query the "face found" GPIO on the Pi. The Pi, in turn, will raise this pin high is a face has been found in the image, or pull it low if none have been found.

The nice thing with the SimpleCV processing is that you can use something like:

faces=foto.findHaarFeatures('face.xml')
if faces:
       for face in faces:

              c = face.coordinates()
              x = c[0]
              y = c[1]
              dist = face.distanceFrom()
              h = face.height()
              w = face.width()              

              print "Face found at coordinate : " + str(x)+"," + str(y)
              print "Distance from centre: " + str(dist)
              print "Size: " + str(h) + "h " + str(w) + "w"


and then compare the location and size of the face bounding box(es) to decide whether or not to include that face in your list of results


So we can use only the largest (closest) object, or compare it's x/y co-ordinates to determine how "off-centre" it is. Or perhaps ignore only faces that have a specific height/width (as a crude distance calculator). The possibilities are endless!

Monday, 8 February 2016

Guitar kits arrived

Before Xmas last year, we put in a order for no less than twelve guitar kits from Aiersi - a guitar manufacturer in China. Independent reviewers rate them quite highly and there are plenty of Youtube videos where non-experts all say they're very happy with them.

We put in a custom order, requiring the fingerboards to be supplied separate from the necks (so they can be amended before fitting with our guitar lights pcbs) so had a mimimum order of six per design. Having a few people express an interest in our guitar lights already, and wanting to try out a couple of colours, we ordered six red and six white stratocasters (Personally, I'd have liked a Les Paul style and a Flying V but, to begin with, the old Stratocaster seemed like a safe bet to make sure everything worked as it should)

Having already bought an (unfinished) guitar kit from on online supplier, we weren't expecting much. The order actually arrived late (it was supposed to be with us on the 20th Jan, but when we inquired at the time, it still had yet to be shipped) but the factory did take the extra time to double-check a few details with us, so we were prepared to allow an extra few days.

This morning, one large box (of three being shipped) arrived at Nerd Towers. It contained four stratocaster guitar kits. Each kit was well packed



And contained a guitar body, already wired and fitted with a scratchplate. The finish on the body is very good - far better than we managed to get with tins of car spray paint and lacquer! Ok, the choice of colour was limited (we didn't have a massive budget for this as we're still not sure of demand) but the finish is very, very good


The necks are finished with a very light lacquer. The neck is nice and slim, and the finish is not too glossy or "sticky" as some cheaper guitars tend to be. It's actually feels very nice - a thousand times better than the neck that came with our earlier kit.


The quality of the fingerboard is far, far better than we could have expected. The online kit we bought last time had a very pale, brown fingerboard.
And the actual quality of the wood was pretty poor. If you look closely at it, the fingerboard has loads of little white marks, where blemishes and bad finishing in the wood has been filled with a cheap wood filler which look very pale against the grain of the natural wood.

We were expecting a similar quality wood but the fingerboards supplied in our kits are a lovely dark - almost black - colour, completely blemish free (of the ones we've inspected) with a nice, tight grain running through them.


The neck sits nice and snugly in the pocket (unlike our earlier cheap online kit which had massive gaps around it) and - somewhat surprisingly, albeit a pleasant surprise - our fingerboards are not the cheaper 21-fret jobs, but have 22-frets


This means the fingerboard has a slight overhang from the neck. But that's not unusual. Almost all 22-fret necks have the same design. Here's one on Amazon :



It also means that - once again, unlike our, frankly-by-now rather shonky looking earlier guitar kit - there's no chance of the fingerboard being just that slightly bit too short, revealing the badly fitted neck-and-pocket underneath (that's the badly fitted pocket on the earlier kit, not these Aiersi guitars!)


All of the hardware looks bright and shiny, the tuning pegs are lubricated without being greasy or sticky. The bits of barbed wire that have been supplied as strings don't look to be anything like Ernie Ball Slinky No. 9s but they'll do, just to get it set up and playable! There's even a guitar lead (although, compared to the quality of the rest of the guitar, isn't, let's say, of the best quality).


At first we were a little disappointed that the bridge hadn't been pre-drilled. But after reading up online, it seems that ensuring the bridge is square and the correct distance from the nut is quite critical. And there are plenty of examples of poorly drilled guitar bodies online - so StewMac (the ultimate online guitar kit/building resource) recommends drilling the bridge yourself, wherever possible). So we're only too happy to put a little bit of extra effort - if the bridge is poorly aligned, we'll only have ourselves to blame!


Something we hadn't been aware of, until comparing these (far superior quality) kits to the earlier one we bought, was the grain on the guitar neck. In a factory using cheap or low quality wood, the grain doesn't always follow the direction of the neck. On our earlier kit, the grain runs at an angle, giving a "diagonal stripe" effect to the grain. On these Aiersi kits, the grain runs perfectly along the neck.


With the fingerboard in place, and the tuning pegs fitted, the guitar looks pretty nice! (no prizes for spotting that we placed the phono jack upside down in this photo!)


We double-checked the hardware against the screws provided and were pleased to see that everything matched up. There's no need for anything more, other than a drill and a screwdriver, to fit all the hardware to the instrument.

Now we'd been told that our twelve guitars were being shipped in three parcels, each with four guitars in. So the question was, do we have four red ones (since the first one we'd opened was red) or was this the box with a mix of red and white?

The second guitar we took out of the box looked just as awesome.


So there we have it. Aeirsi Guitars. Make great guitars. And great-looking kits.
It'll probably be a couple of days before we get time to fully build one and set it up, to give a proper review of the actual guitar. But so far, our expectations have been well and truly exceeded!

Wednesday, 3 February 2016

Proximity sensing with dedicated IC chips - making breakout boards

Although the bluetooth dartboard scoring thing isn't actually in place at Nerd Towers, the BTLE4 app is already written (using Unity) and sends each players scores as ascii to the 3-way 7-segment displays


Shonky coder art and "unobtrusive" debug messages? Of course it's not finished. But it works!

But a few different projects have come up recently that require a bit of RnD. So what better excuse to crack out the ferric chloride and show yet more photos of filthy ferric-chloride fingernails?

Here are some proximity sensors that we're playing with


The one on the left, with the silver package and two lenses is pretty much what it looks like - an IR led and photodiode in a single package. The soic chip and the (much smaller) sot-23 chips are Microchip's own versions of capacitive sensing ICs but with built-in, programmable sensitivity.

The eight-pin thing being pointed at is very interesting. It's a full-colour proximity and RGB sensor. So it can detect levels of red, green and blue placed under it. That's really exciting! We've used sensors for detecting RGB colours a number of years ago. Then, we flashed a red, then green, then blue LED and detected the relative amount of light reflected, to decide whether a card was red, green, blue or black. It worked. But it was a bit clunky. And didn't do so well differentiating between, say, a yellow and a green card, or a cyan and a blue one. And a grey card was sometimes detected as black. But then again, sometimes a white one was too. And while that was enough to tell the difference between red, blue, green and black, it wasn't very good to tell the difference between black and white!

All that's an aside though. What we have here are a number of different proximity sensors, which we need to work out how to use, so we can choose the best performing one for the current project. But potentially having access to an RGB colour sensor has got us thinking about a few other ideas that have been on hold for a loooong time.

In the meantime, we need to get these things mounted onto some breadboard-friendly breakout boards. Let's etch....


Normally the sight of a PCB with just the traces remaining and no ground plane or copper pour filling the blank spaces makes us scream. But in this case, because we're working with such tiny pitch components, and want to be sure there's no chance of bridging between pins under the chip, we etched away far more copper than we'd normally do, with a board of this size.

Luckily, the pitch of the silver IR proximity sensor is the same as the SOIC chip, and the pitch of the RGB sensor - although tiny and fiddly - is the same as the sot-23 chip. So all we need to do is etch a couple of breakout boards for each pitch, and get soldering!


A few minutes later (and, ok, a couple of re-tries after messing up the tiny sot-23 components) we had our chips soldered onto the pcb(s). Perhaps the hot air gun might have been useful here, but even on the tiny sot-23 stuff, a line of paste and then raking it out with the tip of the soldering iron was quick and easy,


After breaking the board apart (panellising pcbs isn't such a good idea when they are this small and we've only a junior hacksaw to cut them apart!) our sensors were ready for testing on the breadboard


Tomorrow we need to digest the datasheets and try to get some data out of them. We only need the proximity function for the current project (it's not exactly top secret, but it is for a commercial commission, so we'll stick to generics here for now) but we have a project of our own that we're looking forward to trying out the RGB sensor on, and will get a full write-up when we get time!

Sunday, 31 January 2016

Bluetooth dartboard scoring device

So after doing a bit of "trading" on the darts markets over Xmas and the New Year, it looked like darts could be a fun game. After all, which other game actually requires you to leave the house and go down to the pub for a few hours? With the weather so rubbish in recent weeks, and with petanque (that's french boules to you) regularly being rained off, it seemed like a great idea!

A quick click around on Amazon and thirty quid later, and we've got a spanky new Winmau Blade4 dartboard and a set of Ted Hankey darts on next day delivery!


It didn't take long to get the board set up (in the hallway at Nerd Towers, so make sure you shout or give a whistle if you're coming out of the dining room!) and to get a couple of games played. There's nothing like hitting two fives and a nine to make you feel like you're actually there, at the Lakeside, competing in the WDO finals. Except...

...what would really make it complete would be a massive, comedy sized scoreboard.
We already had some 4" seven-segment LED displays knocking about. Surely it was just a case of hooking them up to a microcontroller and a MAX7219 driver chip and getting them to display 501?


Knowing nothing about the displayed, we did the usual - poke wires at the terminals until something happened! As it turned out, these displays have four LEDs per segment, not just one, so they actually require about 7.2V to get them to light up.

The process was simply a case of applying power to one of the pins, then grounding others, in turn, until a segment lit up. Because the LEDs are - by their very nature - diodes, it didn't matter if we accidentally put the power lead onto a ground pin; diodes don't let current flow the "wrong way" through them, so nothing happened. After a bit of poking about, we discovered that we had some common anode 7-segment displays.




Having checked the datasheet for the MAX7219 driver, we found it could indeed supply larger voltages than the 5v logic for the data. But these chips are designed to work with common cathode displays, not common anode.

We were going to have to come up with an alternative. Straight away, with anything to do with sinking lots of current, we were thinking about a transistor array. And, luckily, in our lucky bag of ICs, we've a load of ULN2803A chips. They're not just 8-way transistor arrays, but they're ideal for sinking up to 500mA of current - at higher voltages than the logic control signals. Perfect!




But each output requires its own input signal, to hold the output low (grounded).
That means with 3 lots of 8 segments, we'd need no less than 24 i/o pins. That's a lot of pins!

Of course, for a 18F4550 or other PIC with a 40-way package, it's not a problem. Those bad boys have pins to spare. But we've an abundance of 16F1829 chips here, which have a 20-pin count. So we thought that perhaps each ULN2803A current sink could have its own shift register, to allow us to activate as many segments as we liked 





So for each 7-segment display, we've now got a shift register, feeding it's outputs to the "input side" of a ULN2803A. The outputs of the transistor array are connected via 100ohm resistors to the cathodes of the segments.

(not shown in this photo are the resistors between the 7-segment cathods and the transistor array outputs - which is why the display is so bright, running at 9v!)


After a bit of quick etching, and drilling lots of holes with our little dremel...


.... we had a PCB ready for populating

(we may have an abudance of 595 shift registers and 2803A transistor arrays, but there's no point wasting them in case the circuit doesn't work - that's why we're still using through-hole components and sockets for fitting things to the PCB!)

The firmware was completed, allowing characters to be sent to each display, via ASCII. Since our bluetooth modules simply convert bluetooth to serial (at 57600bps) as long as we can correctly parse data over serial, there's no reason why they shouldn't work, parsing data sent from a smartphone app.

Here's an early video of displaying data over serial:



Now we're just waiting on a new bluetooth module (and a free afternoon) to finish the scoreboard and put it in pride of place, over the dartboard!

Friday, 29 January 2016

Apple is shite too

With the recent postings about Windows 10 being so utterly useless, a few people have suggested alternative operating systems. The trouble is:


  • Linux is hard work

Just to get a printer working with it is difficult. It's not that I'm not particularly "tech-savvy". I know how computers work. I just think it's unnecessarily difficult to get a lot of hardware working with Linux. And anyone who says otherwise is usually a little bit sneery about not understanding which command to use at the terminal line, or which sudo apt get package to install.
And the truth is, they don't understand it either - they're just quicker at getting Google to reveal the answer! That's not knowledge, nor understanding. That's just knowing which key words to throw at a search engine to find how someone else did it. That's a useful skill too. But it's not understanding of the system.



  • Apple is evil

Mac computers - on the face of it - look nice. But the all-encompassing power-crazed embrace that Apple put around their technology makes it really difficult to do anything useful with.
Want to hand over some money to install the latest app from the app store? We'll make that easy for you.
Want to hand over some money to listen to music? That's a doddle.
Want to hand over some money to stand in a queue to have your phone looked at by one of our experts because we won't give you the tools to fix things yourself? We'll make that easy for you.
Want to hand over some money to upgrade part of your hardware or toolchain because we don't think hardware should be inter-operable and only Apple should dictate what talks with what? We'll make that easy.
Want to hand over some money to join our developer programme so you can deploy your own software onto Apple devices? We'll make that easy....

Apple makes giving them money easy.
Everything else on a Mac is really difficult.
Try getting some code running on a tablet or phone.
On Android it's easy: create an apk, install on the device. Done!

Don't even try to compile for iOS on a non-Mac device (I tried it. It's just about possible. But really, really difficult). So to target Apple's operating system, you need to use Apple's hardware. And Apple's XCode toolchain. And create certificates. And provisioning profiles. And ensure the provisioning profile matches exactly the one piece of hardware you've identified you want to put the code on. Then piss around some more with a mix of online (web-based) forms plus some local (application-based) settings, download some files (really, why mix online and offline building methods in the same process??!) and finally you might get your code to compile. To run on just one device.

On top of all this, I recently tried to compile a simple Unity app for an iOS device.
It took exactly four minutes on a Windows machine, from launching Unity, to creating an .apk that I could put onto my Android phone. Easy!

I booted up my Mac Mini that was last switched on over a year ago (which was then used to compile some Flash files into an application for iPhone).

  • I had to upgrade the device firmware.
  • Then I had to re-install Unity.
  • Then I had to download and install a massive 4.3Gb complier for iOS.
  • XCode wasn't up-to-date enough for the new compiler, so I had to upate that.
  • But XCode wouldn't update without upgrading the entire operating system.
  • It took nearly two hours to download and re-install Unity and the iOS compiler.
  • It took over two hours to download and install OS X El Capitan.
  • Then I had to re-install XCode. That took nearly three hours.


Having wasted a day, just to get my Mac up to a spec that Apple approved of, I then had to spend about seventy quid renewing my Apple developer licence. Just to make a bouncing ball go up and down on an iPhone screen.

Microsoft might be rubbish. But that's down to their incompetence.
Apple are evil. Because they actually planned this shit.


WTF is wrong with Windows 10?

At the risk of turning this blog into an anti-Microsoft rant, I'm trying to understand why Windows 10 has become so rubbish. Not just "it's a bit like Windows 8 but with naffer graphics". But it's completely, utterly shite.

(Given the experience I had recently with trying to compile a Unity app on a Mac recently, it's unlikely Microsoft will be the only company getting a roasting for producing crappy, needy, simply-fail-to-work-but-offer-no-way-of-going-back-to-a-working-version operating systems)

Both at home, at work and wherever I found a machine running Windows 10, I got rid of it. All except on one machine - a laptop used for testing development on the latest Microsoft operating system. And sometimes, it doesn't make sense to keep flipping between computers; it seems a bit churlish to say "I hate Windows 10 so much, I'm going to put this laptop down and boot up one of my other machines, just to browse the web or download some pdfs".

But it's got to the stage that that's what's happening!
I tried to download a pdf from a website on my laptop.
Some five minutes after it had downloaded, I went into my downloads folder and tried to move it onto the desktop (so it'd be easy to find when I came to read it later)



This was more than five minutes after the file had finished downloading.
A quick look at the task manager and this appeared


Now task manager used to flash a column red if it hit more than 90% or so. It seems like the latest version of Windows 10 now recognises that this is so common, it doesn't do it any more. The stupid Microsoft "anti-malware" is - to me at least - acting like malware.

It's chewing up almost all of the spare CPU and battering the hard disk.
Which in turn renders the rest of the computer useless, as it slows to a crawl. But more than that - it doesn't just make things "a bit slow" or make the computer a "bit cumbersome" but actively stops me from doing what I want with the bleeding thing - which, in this case, was to download a file and put it on the desktop.

If it wasn't for the fact I have to support legacy apps written on a variety of Windows platforms, I think I'd seriously be considering moving to Linux. All of the new development I do now is for mobile platforms (web, Android and - when I absolutely have to - iOS). I used to be a Windows-only developer but it really does look like Windows has had it's day.

I used to build applications with the view that if the mobile version wasn't available, you could always run it on your PC (after all, mobiles don't let you do cool stuff with hardware like plug into the serial port). But more and more it's obvious that it's the PC that's becoming a niche operating system.

I used to think that the proliferation of mobile devices was strangling the computer industry. After all, a mouse is far superior to a pudgy finger for fine resolution and moving things around a screen. And typing on a keyboard is a million times easier than poking a virtual keypad on a screen. Yet consumers (not necessarily computer users, but the majority of people using their tablets to "consume" data) demand less of their devices and simply point at an icon, saying "I want that one".

But it turns out that it's not the demands of the greater masses that's killed desktop computing. It's the developers of the operating systems that have made them so painful to work with. When every action is followed by a dialogue asking for "administrator permissions" or a boot up time of ten minutes while every background service starts and the proceeds to bring the computer to a crawl, it's no wonder people prefer to pick up a tablet and "just go".

But it doing so, OS developers have been going backwards too. In making their operating systems unusable, they're encouraging us to seek out alternative devices and platforms. Ten years ago, the idea of not using Microsoft Office in some shape or form seemed alien to anyone who had ever used a computer (many users confusing Office with Windows and wondering why their PC at home didn't come the full-blown Outlook by default). Now, Office is just another bit of software that you don't need to buy any more.

Windows is slowly becoming the same thing - it's still currently a popular OS. But it's utterly unusable for anything other than the most menial of tasks. It's slow. It doesn't let you do what you want. Half my (admittedly home-built) hardware doesn't work with it. A lot of old software doesn't run on it (unless you remember to right-click and run as administrator). Compilers and development tools don't work nicely together like they used to. In it's current form, Windows is worse than Linux and - dare I say it - probably Mac.

Microsoft used to make awesome software. Sure, it was expensive. And quite bloated. But it worked well. It let you get on with the job - make whatever you needed to make, using software that let you get on and make stuff. But now, Microsoft software is too slow, too bloated and too demanding. It actively gets in the way of trying to get stuff done. And Microsoft don't even make the best/easiest/most useful operating system either.

Interestingly, whenever "big business" appears in the news, it's always Google, Facebook, Amazon, eBay, Apple, even Starbucks that get the press. No-one even thinks to mention Microsoft.

Let's hope Windows 10 dies just as quickly as Microsoft's profile and we can get back to using our technology to do cool stuff, instead of fighting with it on a daily basis!