Kev's Development Toolbox

March 1, 2016

Installing latest Nvidia 361 drivers on Ubuntu / Linux Mint

I’ve posted a few times about installing the nvidia-304 legacy drivers on Linux Mint, which I’ve been using on an HP desktop which has nvidia 6150 graphics on the motherboard.

I just upgraded to a shiny new geforce 750ti card which runs in this same HP, powered through the PCI-E slot so and doesn’t need any additional power (which would have required ugrading the PSU too).

To upgrade my nvidia drivers in Linux Mint, it seems the latest 361 drivers are not available in the main apt-get repos, and even if you add a ppa, it seems they’re not there yet either. Luckily, to install from the download on the nvidia site it’s pretty easy.

To summarize the steps I took based on the instructions here:

remove the current nvidia drivers:
```
sudo apt-get purge nvidia*
```
kill the current Mint DM:
```
sudo service mdm stop
```
sudo the driver .run executable downloaded from the nvidia site.. chmod +x it if needed. Reboot, and done! Running the latest drivers!

March 1, 2016

Java 9 specifics continuing to shape up

Work on Java SE 9 continues – this post highlights some old code cleanups, particularly around sun.misc.unsafe.

February 25, 2016

Amateur Radio: 2m Packet Radio mobile / go kit

Tried something different today – tried some mobile / go-kit style packet radio on 2m:

Yaesu FT60 connected to a 2m/440cm mag mount antenna on my car
Rigblaster interface connected to a HP Mini
UZ7HO soundcard packet modem & terminal software

Connected to the local KBERR node on 145.05MHz, and then also AG6QO-1 / WINTBB via BERR37 on 144.37MHz while I was having lunch in Natomas.

February 17, 2016

Identifying and responding to issues faster with more frequent deploy cycles

Everything in IT has pros and cons, and as they say, ymmv. One of the things that has always interested me in IT is how your point of view, the lens through which you perceive ‘how things are done’, is always (and perhaps obviously) influenced by your current company/project/client/organizational experience.

If for example your current experience is (and perhaps has always been) traditional waterfall-type development lifecycle, then the very idea that it’s possible to build/test/deploy new functionality to production in anything less than 6 month release cycles, let alone daily, probably sounds like an impossibility.

However, if this is your experience (and to be honest most of my industry experience has been using more traditional methods), there is a light bulb moment when you realize what it means to be able to deploy to production in very frequent, short development cycles.

The faster/quicker you can deploy new features to production, the faster you can learn about what works and what doesn’t. If you find problems sooner, you can respond and fix issues sooner. Fixing problems sooner means problems don’t get out of control and grow into much larger problems that become more expensive and more difficult to fix later. Getting features in front of your users sooner give them the opportunity to provide feedback quicker, and either confirm that this is what they were expecting, or whether changes need to be made to get closer to exactly what it is that they are looking for.

Continuous Delivery is not a myth, there’s many organizations out there already successfully using techniques to deploy to production daily (Infoq.com have a great collection of presentations on their site).