Buying tin, selling clouds

In the nineties and early naughties I spent a fair part of my life buying computers, servers and printers, as well as working on some big procurement and framework agreements.

This gave me a hell of an insight into how the tier two build on demand manufacturers worked. The big boys, the Compaqs, the HP's and the rest in the main built standard configurations that more or less met their client's requirements, and stored them in warehouses. This of course cost them money, but meant that if VeryBig plc wanted a thousand desktops delivered to Warrington next Tuesday, they could have them.

The tier two guys were different. Some were better than others, but I've walked round enough of their assembly facilities to know they all worked more or less the same.

As build on demand manufacturers they of course had no inventory. They built it, put it on a truck and delivered it. They also had low component stock. If you wanted a big order - more than twenty or thirty units you needed to talk to them, as they would effectively book the production line for you for a day and order in all the components they needed for that run.

Most of them tried to push standard configurations at you, but you could always arrange something different - eg a different network card, hard drive unit. Everything was negotiable, and in the main they were fairly flexible.

Most of them were very conservative on component choice - they bought good quality bits from good manufacturers in the Far East - while we joked about no name units they weren't, they were just name we didn't recognise.

The real difference was quality control - remember you could go and buy the bits build a pc yourself, and some people did, but these guys did it better by testing things, letting pc's burn in. Remember, dealing with warranty claims was expensive as it often meant sending people out to swap things, so their aim was to do everything that reduced cost.

The result was unglamourous companies working out of tin sheds in disticntly low rent locations, building predictable product.

These guys then started making servers. At first they were not good, but they started getting better with better motherboards, disk controllers and more testing to the point where they could sell you a generic server that performed as well as a brand name unit but at half the price.

By the time the virtualisation and blade server revolution rolled around I wasn't buying tin any more but looking at how Dell's blade offerings developed over the years I would not be surprised if they followed much the same trajectory with some attrition - those that couldn't scale up dropping out of the race.

Now we're seeing something of the same thing happening at both ends of the spectrum - the no name Chinese Android tablet makers are producing good and reliable product and gradually starting to eat into the brand name vendors market share. Aldi and others have offered noname tablets in the past and more relevantly Tesco in the UK is launching a no name tablet.

This is a very important move - a supermarket chain - and Tesco is massive - is risking their brand name on a tablet. Tesco want customer satisfaction and near zero warranty claims as a result of this move as they don't want to damage their reputation or pay out money to handle warranty claims.

At the top end something equally interesting is happening. The big commercial cloud service providers are increasingly able to demonstrate that they can provide disk and compute than less than in house. To do this they need to buy racks worth of servers. And they are buying them from the no name server makers. The cloud providers have enough so that they can swap dead units in and out and are of such a scale they can afford to have generic units sitting around as spares, meaning that they don't need the fancy fast response warranties that the top end manufacturers provide - and as an IT house you pay for one way or another.

And warranty and maintainance costs are a major part of running infrastructure. Run lots the same generic kit, and providing the kit's reliable enough you can get by with reduced warranty terms providing you're big enough to afford to hold spares and employ engineers who can fix things.

It's what we found when I bought tin - the tier two manufacturers were happy for you to (hold (their) spares if you had enough of something and do first fix as it saved them money. They'd even help train your in house people to do their fault diagnosis.

It's much the same with servers. You don't want servers to go down. Unfortunately entropy being what it is means that you can never get a 100% reliability. So you need to add redundancy. That costs. And you need fast response, as when you've failed over to your backup nodes you're vulnerable to another failure.

The big cloud providers don't have this tension. They have enough in the way of kit and capacity to cope with routine failure in a way you never can as an individual private cloud provider. They can run with a lower warranty config - I'm sure a 48h return to base warranty would work fine for them.

It's significant that most of the recent spectacular cloud outages are due to configuration problems, not smoke, fire and dead spindles ...

Written with StackEdit.

Surreal Blog spam

I randomly check the spam comments on my blogs, just in case anything legitimate has been miscategorised.

Most of it is fairly predictable blah about fake designer goods, dodgy stock tips and online viagra but sometimes you find something that's so weird it's good.

And so it was today:

In these mountains Wash discovered his pre-Columbian South American roots, unique warrior skills and the affinity for Broadway showtunes (along with EVER mention that to his face)

You really couldn't make some of this stuff up ...

Written with StackEdit.

Wikis, blogs and clipping

I've recently gotten interested in Thomas Herbert - who had a walk on part during the trial and execution of Charles I in 1648-9. That isn't why I'm interested in him - it's more because he is one of the first documented early modern travellers to Persia, and one of the first to bring back a copy of cuneiform text to England.

Of course he didn't just wake up one day and think "I think I'll go to Persia and look for ancient writing", his voyage is part of a much larger story of the development of the East India Company, and how England went from what was frankly a backward and rather poor place where people wore wool and linen and ate apples to somewhere where people drank tea and could aspire to wear silk.

That is not however what this post is about, rather it's about blogging, building a story and assembling material.

The first part of any activity like this is collecting notes. Once one would have xeroxed interesting things and made notes on index cards but now one creates a heap of vaguely related material suitably tagged in evernote - it doesn't have to be evernote, zotero might well do, but I use evernote.

Tags are used (or not) to create a folksonomy - often and idiosyncratic and inconsistent folksonomy, but a folksonomy.

I've known people write little notes on index cards in the old days to achive much the same effect. What one ends up with is a pile of thematically related material from which one could make something - a novel, a history paper or something.

I'm talking about Thomas Herbert here, but the process is similar to designing a project with notes on exemplars, problems, relevant bits of code etc.

And then at some point one needs to organise it - and this is where wikis come in.

Folksonomies can only take you so far. Organising material is largely about identifying linkages and the gaps and inconsistencies between chunks of the material.

However, help is at hand. Wikis are great for documentation. They are great for documentation as they allow you to put all the relevant bits of documentation required into an organised structure and crucially change that structure if it's not right.

What they are also great for is organising material. This is something that isn't touted as a virtue of wikis but think back to those 9x6 index cards. You could lay them out (in fact I used to do this years ago when I was a research student) with the most closely related facts next to each other and less related further away. You could then turn this into a connectedness diagram by writing down the titles of the notes as a list in each of the blobs and drawing connections to each of them.

Wikis let you do this because you don't need to think about the underlying file structure. For example look at my East India Company page:

• click on people under 'early contacts' and it will take you to Thomas Herbert
• click on 'early engagement' under Persia and you can find your way to the same place.

There's obviously a relation between the various bits of text, but if you look at the url's the structure is flat. I could at this stage go all computer science and say I've abstracted the structure from the file system, but what I really mean is that you can make up the relationship between the individual bits of text and change it with out having to poke about in the file system.

Now quite a few researchers have blogs where they write about their research. Blogs are by their nature linear and are like a personal journal or a series of letters between oneself and the world, a bit like nineteenth century naturalists used to send letters to learned societies. Blogs clearly have an importtant role in communication but they are not about building ideas and understanding out of material. They might well be about communicating the results, but not about the material that gets you there.

Wikis on the other hand are not linear, and not sequential, and as such allow one to develop a document describing something over time.

The puzzle for me is - they don't seem to be much used in this way - am I missing something?

Written with StackEdit.

Disrupting the University

A long time ago 2008 to be exact I wrote about the future of computing in universities.

My view was then, and remains that the future of IT services is as a resource broker of facilitator as most of the classic KTLO work can be outsourced. Since 2008 the world has changed in a number of ways

• the public cloud has become cheaper, more reliable and more accessible
  • demonstrated by the number of infrastructureless comapnies eg dropbox
• a lot of infrastructure has become commoditized - which has driven students to self outsource.
  • Coupled with the availablity of cloud based resources, the last justification for access to student provision, access to specialist resources, has disappeared
• MOOC's have changed to model for access to university level courses
  • add to cloud and self outsourcing students can increasingly self structure
  • problem of accreditation remains however.

Given my views on the subject I was interested to hear Nick Tate who is currently head of RDSI and this year's head of the ACS and previously the CIO of UQ present on Disrupting the University

As always, these are my notes and my interpretation of Nick's presentation and do not necessarily represent his views. At the same time the notes and interpretation are my own and not my employer's.

---

• Change

  • change is coming but change is part of IT
  • now seeing disruptive rather than progressive change
  • much in the way pc's ate mainframe computing's lunch
  • or how kodakinvented digital camera and then failed to capitalize

---

• Challenges

  • education challenge
  • financial challenge
  • people challenge
  • technology challenge

    ---

• education issues

  • mooc - open courseware
    • interesting how quickly moocs gained momentum
    • MIT courseware opened 2008
    • initially gradual uptake
    • coursera now 3,200,000 registrations,udacity 750000,edX 67500
    • massive momentum 8000 reg/day per coursera
  • courses free content - changed value implications for teaching as no longer funded from course fees
    • how pay for course devlopment
  • see top tier universities going to open course provision - implaction for tier 2 and below
  • implications for IT provision for teaching
    • students selfprovide
  • how to monetize open courses
    • value of ccontent versus accreditation
    • unis give credit on basis of course completion - pay for accreditation and examination

      ---

• Implications for IT

  • how finance infrastructure?
    • public university model looks to be unsustainable
    • outsourcing of standard processes
    • university spending on IT dropping
  • innovation required

    ---

• People

  • skills vs longevity vs external competition
    • need to work faster and better - will not have enough people
      • 'work smarter' not a cliche but an imperative

        ---

• Technology

  • need to innovate and try to get leverage
  • use of cloud - on demand - scalable
  • rdsi and aws
  • public cloud costs compelling - debate on cost is efefctively over
  • private cloud /rdsi too smallfor economies of scale
  • public cloud like ausgrid, pay for what you use, and is investment free
    • usage charge only - scale and business model
  • why IT infrastructure when you have cloud?
  • durability of public cloud 11 9's durability -better than achievable on private datacentres
  • same metrics for security investment - why did aws get cia contract
  • potentially still a price barrier in education but amazon costs progressively reducing

    ---

• How to react?

  • possibly too much focus in established IT on service delivery rather than innovation
  • cloud/outsourcing allows innovation by freeing resource
    • service delivery concerns effectively outsourced
  • at same time get better availability service important for pervasive IT
  • MOOC's all run on public cloud because cannot scale otherwise
    • => implication is need to outsouce and let go of commodity computing
      • students to self outsource
      • IT to support teaching learning and research
        • implies greater engagement

          ---

• Key Technologies

  • key techlogies to move and virtualise are identity management and fast networks - but uni networks actually very good
  • networks more than capable of dealing with most tasks
  • commoditization solves local provision - byod by default
  • value proposition lies around engagement and facilitation.

Wikidot and Markdown

Well, I hadn't got very far with my markdown to wikidot conversion parser when the dayjob intervened and I needed to make myself some working notes on smething I'm working on and add them to my wikidot site.

In the process I've come up with a very kludgy interim fix. Wikidot allows you to embed html using a

[[html]]
<html>
<p>your text goes here</p>
</html>
[[/html]]

construct. Very crude, but writing the documents in StackEdit and exporting them as HTML and then cutting and pasting the HTML source seems to work well enough as in this little bit of doco ...

Written with StackEdit.

Sheepshaving with Markdown and Asciidoc

After my dalliance with Markdown and Slidy I got interested in modifying the CSS used by Pandoc to generate the Slidy docs to be more like our corporate style. (our house style is very minimalist - deliberately so to make sure it displays on all devices more or less the same - basically a top strap and a bottom strap, kinda like this:

which should not be too difficult to turn into css, even if the last time I wrote any serious css was six or seven years ago.

So, I started looking for some examples where people had modified the default css files used by pandoc and in the process happened across asciidoc as an alternative lightweight markup language.

Actually I'll rephrase that - asciidoc is a medium weight markup syntax. You can teach anyone who can use an editor markdown in ten minutes (and you can teach anyone to use an editor - providing it's not vi - well enough to write markdown in 10 minutes).

Asciidoc is that bit more complex and probably takes a couple of hours to teach or a dedicated wysiwyg tool. Like TeX, and unlike Markdown, the formatting is slightly more abstract than the immediacy of Markdown, meaning people need to think more about the structure of what they are writing, rather than bash it out and fix it later.

Anyway. Asciidoc also has a slidy backend and accompanying css file so I thought I'd look at it for comparison.

And I got diverted. Asciidoc does some other output formats from pandoc and I got to wondering if I could feed markdoen through asciidoc to make something else. It turns out you can with the help of the alternative asciidoc.conf from the Asciidoctor project. It's not quite perfect but it creates reasonable html output from short markdown documents.

Creating slidy output from my optimised for pandoc document is not quite so reasonable but you can see it would be fixable.

Not surprisingly the replacement configuration file is really not much more than a lot of

s/this/that/g

statements with a bit of inline processing. Now I've written a lot of specialist one-off text document conversion filters in my time, and one of the problems I've come across is getting documentation onto a wiki server as wiki markup syntaxes all differ.

Markdown basically does everything in terms of formatting a wiki markup system does. So I think I'm going to write myself a little markdown to wikidot converter - been looking for an excuse to write some python ...

Written with StackEdit.

Chromebook - the best thing

Startup and Shutdown time.

It takes about ten to fifteen seconds to boot and less to shutdown. Faster to boot than either of my Android tablets, an Ubuntu laptop, my Mac, or indeed either my Dell laptop or most definitely my windows netbook.

And like the latter three, there's no fiddling around in the background pretending to have started when they really havn't. Once you're in you're in.

I suddenly realise this last night when it clicked that there was no suspend/sleep/hibernate mode - like a washing machine it's either on or off.

All these stste saving modes (suspend/sleep/hibernate deending on platform) are of course furphies to disguise slow boot times and give the impression of immediacy - people of course expect immediacy.

In a past life I learned this lesson while writing network boot scripts - people needed to believe something was happening even if wasn't really ...

The Chromebook is the first system I've seen (other than a few specialist things with magic firmware) that really comes close to instant on - and I kind of like it ...

Written with StackEdit.

HTML Slides and multimode documents

Well, I'm still impressed with HTML slide generation abilities of Markdown and Pandoc, the more so as it allows one to use a common base format document which could be turned into both a handout and a presentation.

While this is a simple concept it's guite powerful as we are essentially creating a multi modal document.

The only problem is that the output documents are scrappy.

The text document is easy to fix - an automated export to libre office to have a template applied plus a bit of eyeballing to fix up any problems and then a pdf export.

And of course if you have an odt document you can readily convert and share it via googledocs.

Slidy is a little different. While accepatable for a presentation between consenting adults the appearance is a little raw. Unlike Google's presentation tool it's not particularly simple to apply a template (although it is possible but this requires fiddling with css). Equally it's not particularly easy to export the slidy files to something else and apply the template as a part of the workflow.

The aim at the end of it is to have a document that can be converted to html and displayed on a web page, or like this document ported to a blog, while at the same time provide an easy takeaway option to either view it as a slideshow or download it is a set of notes, as an aid to students being able to access it in a way that most aids revision - we already know that students make substantial use of lecture recordings as revision aids.

I can glimpse the future, but I'm not quite there yet.

Written with StackEdit.

Using Markdown to make a presentation

If you've ever been to any of my presentations you'll know that my presentations are black text on a white background, with dot points and not a lot of diagrams.

Over the years I've been persuaded to add funkier backgrounds and use the official template, but my presentations are basically in the format

header
    dot point
    dot point

which is not the most exciting. No, or very few diagrams, some code samples, and no embedded video. I personally feel it's about getting the message across as simply and clearly as possible.

In part it's because of the way I write - I tend to think in dot points - which is why I like markdown for meeting notes - and consequently my slides are really an outline of my talk.

Now it so happened I have a presentation that I've ended up not giving. It exists as an outline in markdown, and I got to wondering how easy it would be to turn it into a rough and ready presentation.

It's actually pretty easy, and it turns out to have been something that's had some discussion. There's a number of projects out there but there are basically two models

• convert text to html, with links to images and store the lot in a directory and run a minimal web server to display
• convert the lot to an html file with some css and embed any graphics into the html file

Option 2 is portable, option 1 has the advantage of simplicity especially if you have a spare webserver lying around - really it's just like the old Star Office html export where it dumped everything out into a directory and you uploaded it to a webserver.

Option 2 I though was perhaps a little more versatile, especially as running private webservers is something that tends to get frowned on.

Pandoc - my favourite markdown conversion tool - turns out to have some nice options to generate a file and the markdown structure required is something fairly simple structure:

## slide 1 header

* dot_point

---

## slide 2 header

* dot_point

ie something that is pretty simple to generate from a dot pointed presentation outline.

To generate the file only required a single command (I chose slidy out of the half dozen presentation options pandoc supports):

pandoc -t slidy -s markdown_source_file.md -o html_output.html --self

To keep life simple when generating the output fle I lazily dumped all the images in the same directory as the source file.

In case you're curious and want to have a look at the finished product I've put html output and markdown source up on my clouddrive account as a gzipped tar file

The result is pretty impressive even if it probably something that would upset the logo police, and while it's not something for a public presentation it's a very easy way of running up a quick presentation to summarise a discussion or walk people through an idea ...

Written with StackEdit.

We're so cyberpunk

Last night I tweeted a link to a piece by Gary Shteyngart about his experience with Google Glass.
It's a good read - unlike a lot of the hype-y reportage on Glass this is a comparatively straightforward bit of writing by an author describing his experience with Google Glass.
And it shows a picture of a very cyberpunk experience of augmented reality - definitely 'baby - we're so science fiction', where you can get additional data when asked for, share experiences and share what you're seeing, say at an exhibition or an event, or just hanging out with friends.
Individually the experiences are not significant, we've all stuck laptops out of windows to show loved ones where we are when calling home with skype (somehow it's more fun to show the traffic outside rather than the fact you're far away in a beige hotel room) taken pictures from a moving vehicle with a phone just to share the happenstance of an exotic street scene - call it an anti-selfie - and looked stuff up on wikipedia on you phone in a museum (and sneaked the odd shot of an exhibit).
The thing about Glass is that does something that seems different by putting all the bits together in a package conceptually derived from military in-vision displays, plus the availability of decent voice recognition and reasonably pervasive networking. Individually the bits don't constitute a step change - together they seem to do something.
The Glass idea is not that new - the science fiction story of people sharing what they see or using it to make tv reports is common enough (shades of the reporter who uses it to get footage of the riots in Istanbul)- the thing is that it is here and it works.
Things will change as a result of it. Quite how I have no idea but they will.

Written with StackEdit.

Chromebooks and Surfaces

The press has been full recently about how Microsoft has taken a $900m hit on the Surface, a device that was clearly designed to fill the gap between a full featured laptop and a tablet. Clearly it hasn't made it.
At the same time we've had reports of Chromebooks being adopted, for example by journalists - which is not that surprising in the light of my original agonising about buying one as a travel computer.
The interesting thing about having acquired a chromebook is that it has not changed my tablet usage - except for reading RSS feeds and that's due to the lack of an android client that integrates with InoReader - what it has changed is my laptop usage.
My tablet remains a device for email and reading news websites plus some idle couch based surfing. My second 7-inch tablet remains a note taker, plus a device for reading material saved to Pocket or Instapaper. It's the small format and long battery life that drives its usage.
For a lot of simple research and writing purposes the Chromebook is fine - for example we were checking out options to visit various Mayan sites in Central America, and the chromebook was fine for research, clipping things to evernote and writing up a skeleton planning document using Google Docs as way of sharing it with J - it could have been a wiki but shared editing with Google Docs is easier.
It's also worth noting that writing software for Android Tablets is not really there - applications are either too big and slow, or else too minamalist. I usually end up using TextEdit to write a markdown file and then save it to Google drive for further edit by StackEdit, or feeding through pandoc to create an odt document.
Until a couple of weeks ago I would have done this with my windows laptop - I would not have done this with my windows netbook, although it would have been perfectly possible, purely because of the lack of instant-on.
So what we see is the Chromebook hitting the spot as regards price vs performance/usability. My netbook hits the price band but not performance. My windows laptop does the performance metrics pretty well.
In short a Chromebook is usable for something that looks a bit like work. The price is right to make it a second device and the performance is more than acceptable. (The fact I've also sold my soul to the Google software ecology probably also helps).
Surfaces, or more accurately Surface RT's, seem not to have got the price point right. Remember these will in the main be second devices, and need to be priced accordingly.
They were touted as providing access to Office - which a lot of people seem to consider to synonymous with work. Of course what they mean most of the time is 'access to an editor/file viewer' plus 'access to my email'.
In fact for people not tied to a corporate environment there are other solutions. Equally, we know that a lot of Microsoft's revenues come from Windows and Office sales - if the Surface had been successful it would undoubtedly have cannibalised some of these sales. (Incidentally I might have bought a new laptop this year - now I've a Chromebook I probably won't).
A case of Microsoft eating its core business - which is not generally a good way to go - and something that they realised when they restricted the base level of Windows Home on netbooks such that they couldn't run Office in order to protect their core business ...

Written with StackEdit.

surveillance paranoia

This morning I tweeted a link to a story by a US journalist about how the FBI came calling because her and her husband been searching (separately) on the web for information about pressure cookers and backpacks.

It's since been confirmed that it wasn't Google searches, but instead her husband's ex employer looked at his web search history on his work computer before was let go, found some searches for backpacks and pressure cookers, and called the cops.

Whatever the rights and wrongs of the story it speaks of a degree of paranoia on the part of all parties. I could have believed either version.

Why?

A long time ago I wrote a post to this blog about internet security and I perhaps didn't choose my words as carefully as I should have.

Looking at google analytics a few days later I saw some accesses from the TSA in the States. My guess, and it is only a guess, is that some routine automated scanning picked up the blog post and someone decided to check it out.

They obviously decided it was innocent. I've travelled to the States since then and had no problems with the TSA or US immigration.

Personally, and despite my left liberal leanings, I'm not worried. After all the blog post was a public document, and meant to be read.

What this little story shows is that the system on the whole works. It's unfortunate, but we have to tolerate a degree of security paranoia these days no matter how liberal our views.
Scott McNeally once said that privacy is over. It seems he might have been right

Written with StackEdit.

Calendar spam

I'm not sure how common this is, but over the last month or so I've noticed the phenomenon of calendar spam. I first came across it about six weeks ago while I was in Sri Lanka ( the two events are not related) and since then I've had two or three other incidents.

This is how it works:

Someone sends a meeting request (I use google calendar, I'm not sure if it's a gcal only phenomenon). It usually has a fairly obvious subject line like please review by 0830 or Urgent meeting request, ie subject lines that sound vaguely plausible, but not ones that anyone actually uses - not where I work anyway.

Go to your calendar and there it is, that fictional 0830 meeting. Open it up and the meeting details contain one of these scam sob stories about how someone needs help to get some infeasible amount of money out of a bank in Guinea or Nigeria.

Just another irritation of life ...

Written with StackEdit.