Freeing up space on a Raspberry Pi

Partway through a big compile, the process died with “No space left on device”. Aaarrgh! What to do?

The Pi had an 8GB card and check with df -h showed this:

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.2G  6.8G   34M 100% /

So that’s me stuffed. Or is it?

Option 1

Use a bigger memory card; 16GB, 32GB … Yeah, great. I’m 30% through a compile based on a complicated setup using lots of downloads and additions. Either I’d have to start again from square one or image the existing card and copy it onto the new one. Helluva hassle. Besides, first I’d have go out and buy a new card. Not an option.

Option 2

Install Raspbian Lite. It’s Raspbian without all the extras.

This is what I should have done at the outset. Hindsight’s a great thing, but I’d still be faced with starting from square one. What else?

Option 3

Expand the filesystem. Run the command sudo raspi-config. You’ll get this:

Select Advanced Options:

Choose Expand Filesystem. After a reboot you’ll hopefully you’ll have more space. But not in my case. So that left …

 

Option 4

Delete unneeded programs.

The beauty of Linux is it’s easy to reinstall stuff later, so I tried deleting things I didn’t need and charting my progress.Here are the results.

Command

Result

sudo apt-get purge wolfram-engine
677M recovered
sudo apt-get purge libreoffice*
250M recovered
sudo apt-get purge minecraft-pi*
5M recovered
sudo apt-get purge sonic-pi*
134M recovered

I finishing up with:

sudo apt-get clean
sudo apt-get autoremove

which freed up another 100M+ and re-ran df -h:

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.2G  5.6G  1.3G  82% /

That’s 1.3GB freed up. Almost 20% of my 8GB card. Result!

Now back to that compile …

 

Share this ...
Share on FacebookTweet about this on TwitterPin on PinterestShare on Google+Share on TumblrShare on LinkedInDigg thisShare on RedditShare on StumbleUponEmail this to someonePrint this page

How to make a million in IT

Want to make a fortune in IT? Simple, sell a system to the New Zealand Police.

Whoa! you’re thinking. The police? Is he nuts?

No, seriously, those guys will buy anything. Back in 1999 they paid $100 million for “little more than a highly expensive e-mail system and a number of terminals”, and last week it was revealed that they’ve blown $56 million on a new human resources and payroll system. What’s more, it’s still not ready, and the delay is costing a further $2 million a month. (Not ready? I hear your say. An IT project not delivered on time? Does that ever happen, anywhere…?) It’s now due for completion in September, by which time it will have cost $64 million.

deThe INCIS project, for anyone who cares to remember it, has its own Wikipedia entry and occupies a key chapter in the book Dangerous Enthusiasms: E-government, Computer Failure and Information System Development, by Robin Gauld and Shaun Goldfinch, (Otago University Press, 2006, reprinted 2012). As an Integrated National Crime Investigation System, it was going to be a world-beater, and the money flowed into it like water for five long years.

I had a former colleague splashing about in those waters back in 1998. I remember him boasting he was earning $85 an hour for reading the project’s spec. It took him months. Why? Because the original specification was 4,000 pages long. Yes, 4,000 pages. I heard there were a further 2,000 pages of amendments.

If you have a problem getting your head around documents of that size, remember that a ream of regular office paper (500 sheets) is about 5cm thick. So placed on your desk, the original spec would have measured 40cm (16 inches) high and weighed at around 19kg –  without covers or binding. Or the amendments.

How do projects get so ridiculously out of hand? Three words: IT project managers. It’s that simple.

I’ve spent 25 years in IT, and in all that time I’ve worked with two, maybe three, competent project managers both here and overseas, on large projects and little ones. All the other PMs I’ve encountered have been bunnies, ranging from gullible fools unable to read a Gantt chart through to the wilfully malicious, there to parrot whatever senior management wants to hear1 while padding out their own fat contracts.

But how do you spot a BPM (Bunny Project Manager)? After all, the whole profession is based on the ability to give glib answers and make calming predictions about deliverables based on no data at all.

One simple technique is to employ what I modestly call the Palmer Protocol: just drop the name Fred Brooks into the conversation, or make a passing mention to mythical man-months. If you’re met with the question “Who does he play for?” or a straightforward bewildered look, run for it!

mmmMore than 40 years ago, Fred Brooks2 wrote the book on IT project management. Literally. His slim volume, The Mythical Man-Month: Essays on Software Engineering, was first published in 1975 and is still in print. In it, Brooks reflected on his experiences working on a Really Big Project – the programming behind IBM’s OS/360 mainframe operating system – and all the mistakes he observed.

In The Mythical Man-Month, he describes what’s become known as known Brooks’ Law, the somewhat counter-intuitive, “Adding manpower to a late software project makes it later.” The reason it does so is because complicated programming projects can’t be broken down into discrete units and farmed out to individuals, but most BPMs still operate on the basis that they can.

The rationale goes like this. If one man can cut an acre of wheat in a day, then ten men can clear a ten acre field in a day. And they can. But cutting wheat isn’t cutting code. Programmers need to communicate with each other. Adding new staff – no matter how competent – means that your existing, already over-taxed staff have to take time out to bring them up to speed and then keep everyone updated with each others’ progress. There’s even a simple equation for calculating the effect, called the group intercommunication formula, where n is the number of staff:

n(n − 1) / 2

That means that a ten-person team will have 45 channels of communication [10 x (10 -1) / 2], while a twenty-person team will have 190. 30 people will have 435 channels, 40 people, 780, 50 people, 1,225, and so on.

The book is filled with other observations, still timely 40+ years on. There’s the Second-System Effect – “the tendency of small, elegant, and successful systems to have elephantine, feature-laden monstrosities as their successors due to inflated expectations.” There’s the tendency towards an irreducible number of errors. (All complex systems have bugs, but after a certain point, squashing them simply results in more bugs.)

pgmSong
All software has a tendency towards an irreducible number of errors.

Then there’s progress tracking. “How,” Brooks asks, “does a large software project get to be one year late? Answer: One day at a time!” Incremental slippages accumulate, eventually producing a large overall delay. It’s the project manager’s job to set small individual milestones and ensure they’re met.

At the end of the book, Brooks makes a couple of suggestions for lowering software development costs. Both seem obvious, but as we all know, commonsense isn’t common, particularly amongst BPMs.

The first says don’t hire implementers until the architecture is complete. (My spec-reading former colleague was a programmer, but the bit he was supposed to working on wasn’t ready.)

The second – and here one wonders how uniquely complex the NZ Police’s payroll and human resources needs really are – is even more obvious. Don’t develop software at all, just buy it “off the shelf” wherever possible. At $64 million, (and it will almost certainly come in higher than that), the NZ Police could have bought the whole damn store.

 

PMdilbert

 

 

1 One report into the INCIS systems’ prospects reckoned that Police would save $517 million over 8 years in “efficiency benefits” – whatever the hell they are.

2 Fred Brooks’ book has been called the Bible of Software Engineering because, he reckons, “Everybody quotes it, some people read it, and a few people go by it”.

 

Share this ...
Share on FacebookTweet about this on TwitterPin on PinterestShare on Google+Share on TumblrShare on LinkedInDigg thisShare on RedditShare on StumbleUponEmail this to someonePrint this page

Apple’s $59bn tax bill

From The Guardian:

Apple’s local efforts to avoid paying higher taxes are part of a larger pattern for the $500bn company, which has long been a pioneer in corporate tax avoidance. Apple pays a 2.3% effective tax rate on its $181bn in cash held offshore, according to Citizens for Tax Justice, a not-for-profit research group focusing on tax policy. Through a series of well-documented offshore manipulations with saucy-sounding names such as the Double Irish with a Dutch Sandwich, the industry giants shield themselves off from the theoretically 35% federal corporate tax rate. Citizens for Tax Justice estimates that Apple would owe $59.2bn in US taxes if the money weren’t funneled into offshore shell accounts.

Criticism over the company’s offshore tax schemes has become more pointed in recent months, both locally in Cupertino and from Apple’s own staff. Steve Wozniak, Apple’s co-founder, said the company should pay a 50% tax: “Jobs started Apple Computers for money, that was his big thing and that was extremely important and critical and good. … [But] we didn’t think we’d be figuring out how to go off to the Bahamas and have special accounts like people do to try to hide their money.”

Link to the rest at The Guardian.

 

Share this ...
Share on FacebookTweet about this on TwitterPin on PinterestShare on Google+Share on TumblrShare on LinkedInDigg thisShare on RedditShare on StumbleUponEmail this to someonePrint this page