My top 7 Cargo (Rust) commands

I heartily recommend that you spend some time investigating Cargo

This is the third article in my mini-series for Rust newbs like me. I’ve been using Rust for a little over six months now, and I’m far from an expert, but I have stumbled across many, many gotchas and learned many, many things along the way: things which I hope will be of use to record for those who are learning what is easily my favourite language. You can find my other excursions into Rust here:

I plan to write more over time, but this one is about Cargo. I’m ashamed to admit that I don’t use Cargo’s power as widely as a should, but researching this article has given me a better view into the command’s capabilities. In fact, I wasn’t even aware of some of the options available until I started looking in more detail. I’m going to assume a basic familiarity with Cargo – you have it installed, and you can create a package using cargo new <package>, for instance – so let’s work from there. I could have provided more (there are many options!), but here’s your “lucky 7”.

  1. cargo help <command> You can always find out more about a command with the --help option. The same goes for cargo itself: cargo --help will give you a quick intro to what’s out there. For more information on a particular command (more like a man page), you can try using the command “new”: cargo help new will give you extended information about cargo new, for instance. This behaviour is pretty typical for command line tools, particularly in the Linux/Unix world, but it’s very expressively implemented for cargo, and you can gain lots of quick information.
  2. cargo build --bin <target> What happens when you have multiple .rs files in your package, but you only want to build one of them? I have a package called test-and-try which I use for, well, testing and trying functionality, features, commands and crates, and which has around a dozen different files in it. By default, cargo build will try to build all of them, and as they’re often in various states of repair (some of them generating lots of warnings, some of them not even fully compiling), this can be a real pain. Instead, I place a section in my Cargo.toml file for each one thus:

name = "warp-body"
path = "src/"

I can then use cargo build --bin warp-body to build just this file (and any dependencies). I can then run it with a similar command: cargo run --bin warp-body

  1. cargo test I have an admission: I am not as assiduous about creating automatic tests in my Rust code as I ought to be. This is because I’m currently mainly writing PoC (Proof of Concept) rather than production code, and also because I’m lazy. Maybe changing this behaviour should be a New Year’s resolution, but when I do get round to writing tests, cargo is there to help me (as it is for you). All you need to do is add a line before the test code in your .rs file thus:


When you run cargo test, Cargo will automagically find these tests, run them, and tell you if you have problems. As with many of the commands here, you’ll find much more information online, but it’s particularly worth familiarising yourself with the basics of this capability in the relevant Rust By Example section.

  1. cargo search <query> This is one of the commands that I didn’t even know existed until I started researching this article – and which would have saved me so much time over the past few months if I’d known about it. What is does is search crates-io, Rust’s repository of public (and sometimes maintained) packages, and tells you which ones may be relevant (you can specify a different repository if you want, with the intuitively named --registry option). I’ve recently been doing some work on network protocols for non-String data, so I’ve been working with CBOR. Let’s see what happens if I use cargo search:

This is great! I can, of course, also combine with tools like grep to narrow down the search yet further like so: cargo search cbor --limit 70 | grep serde

  1. cargo tree Spoiler alert: this one may scare you. You’ve probably noticed, when you first build a new package, or when you add a new dependency, or just do a cargo clean and then cargo build, that you’ll see long list of crates being printed out as Cargo pulls them down from the relevant repository and then compiles them. How can you tell ahead of time, however, what will be pulled down, and what version it will be? More importantly, how can you know what other dependencies a new crate has pulled into your build? The answer is cargo tree. Just to warn you: for any marginally complex project, you can expect to have a lot of dependencies. I tried cargo tree | wc -l to count the number of dependent crates for a smallish project I’m working on, and got an answer of 350! I tried providing an example, but it didn’t display well, so I recommend that you try it yourself: be prepared for lots of output!
  2. cargo clippy If you tried running this and it didn’t work, that’s because I’ve cheated a little with these last two commands; you may have to install them explicitly (depending on your initial set-up). For this one, run cargo install clippy – you’ll be glad you did. Clippy is Rust’s linter – it goes through your code, looking at ways in which you can reduce and declutter it by removing or changing commands. I try to run cargo clippy before every git commit – partly because the git repositories to which I tend to be committing have automatic actions to reject files which need linting, and partly to keep my code generally more tidy. Let’s see an example:

Let’s face it: this isn’t a major issue (though clippy will also find errors, too, if you run it on non-compiling code), but it’s an easy fix, and so you might as well deal with it – either by removing the code, or prefixing the variable an underscore. As I plan to use this variable later on, but haven’t yet implemented the function to consume it, I plan to perform the latter fix.

  1. cargo readme Not the most earth-shattering of commands, this is another which is very useful (and which you may need to install explicitly, as with cargo clippy, above). If you add the relevant lines to your .rs files, you can output README files from Cargo. For instance, I have the following lines at the beginning of my file:

I’ll leave the output of the command cargo readme as an exercise to the reader, but it’s interesting to me that the Licence (or “License”, if you must) declaration is added. Use this to create simple documentation for your users, and make them happy with minimal effort (always a good approach!).

I’ve just scratched the surface of Cargo’s capabilities in this article: all of the commands I’ve listed above are actually way more powerful than I’ve described. I heartily recommend that you spend some time investigating Cargo and finding out how it can make your life better.

Rust – my top 7 functions

Rust helpfully provides a set of “prelude” functions.

I’ve written a few articles about Rest now, including, most recently, Rust – my top 7 keywords, in which I promised a follow-up article. The keywords article talked about keywords from the std library, and this time I’m going to look at some functions from the Rust prelude. When you create a file in Rust and then compile it, you can (and will often need to) import external modules, typically with the use or extern keywords. Rust does a good thing for you, however, which is to import a set of useful modules without your even asking. This is known as the standard prelude. As usual, the Rust documentation has good information about this, and the latest version is found here.

Here are a few of my favourite functions from the standard prelude: useful ones to which I keep returning, and some which expose a little about how Rust “thinks” about the world.

  1. clone() – there are times when you need to use a variable somewhere where Rust’s rules of memory management make that difficult. Luckily, where the std::clone::Clone trait is implemented (which is pretty much everywhere), you can copy to a new variable. Don’t do this just to get around Rust’s memory management, which is there to help you, but it can be very useful when you actually need a new copy of something.
  2. format!() – OK, officially this is a macro, rather than a function, but it’s very useful. You probably know and use println!(), which is used to print to stdout: format!() does pretty much the same thing for strings which you don’t immediately want to output.
  3. is_ok() – to be honest, this is just an excuse for me to talk about std::result::Result, which is hugely useful, and allows you to create and then access success (Ok) or failure (Err) results. The is_ok() function will tell you whether what you have is an Ok result (and remember that the “k” is lower case – probably my most frequent syntax error when writing Rust). In order to understand Rust properly, you need to get your head around Result: it’s used extensively, and you should be using it, too.
  4. is_some() – like Result, std::option::Option is something you’re likely to use a lot when you’re writing Rust. Given that there’s no equivalent to the Null that you in many other languages, what can you do when you don’t have a value generated to return? The answer is that you can use an Option, which you can give a None value: in other cases, you can provide a value within a Some() wrapper.. The is_some() function checks whether there is a value – if there is, you can use the unwrap() function to access it (see below). Like Result, get used to using Option: you’ll see it all over the place.
  5. iter() – many different collections can be iterated over, and the iter() function allows you to access all of the values very simply. You may sometimes want to use the related functions into_iter() and iter_mut() (for mutable values, unsurprisingly), but iter() is what you’ll be using the most, and you can chain all sorts of useful functions onto it.
  6. panic!() – there are times when your program gets input, or generates output, which it really shouldn’t. When std::result::Result isn’t good enough, and you can’t propagate errors up through your execution stack, because this isn’t the sort of error that should be handled, you can force your program to stop with panic!() (another macro, if we’re honest), and add an error message to provide more information.
  7. unwrap() – if you’ve got a std::option::Option or a std::result::Result, and you want to access what it contains, then you’ll want to use unwrap(), which will panic if there’s a problem (or expect() if you want to be able to add a specific message).

Another fairly basic article, but if it’s useful for people starting to get their heads around Rust, then I’m happy. I plan to continue looking at some of the more basic language components in Rust and some basic gotchas: keep an eye out.

What’s a vulnerability?

Often, it’s the terms which seem familiar that are most confusing

I was discussing a document with some colleagues recently, and wanted to point them an article I’d written with some definitions of terms like “vulnerability”, “exploit” and “attack”, only to get somewhat annoyed when I discovered that I’d never written it. So this week’s post attempts to remedy that, though I’m going to address them in reverse order, and I’m going to add an extra one: “mitigation”.

The world of IT security is full of lots of terms, some familiar, some less so. Often, it’s the terms which seem familiar that are most confusing, because they may mean something other that what you think. The three that I think it’s important to define here are the ones I noted above (and mitigation, because it’s often used in the same contexts). Before we do that, let’s just define quickly what we’re talking about when we mean security.


We often talk about three characteristics of a system that we want to protect or maintain in order to safeguard its security: C, I and A.

  • “C” stands for confidentiality. Unauthorised entities should not be able to access information or processes.
  • “I” stands for integrity. Unauthorised entities should not be able to change information or processes.
  • “A” stands for availability. Unauthorised entities should not be able to impact the ability for authorised entities to access information or processes.

I’ve gone into more detail in my article The Other CIA: Confidentiality, Integrity and Availability, but that should keep us going for now. I should also say that there are various other definitions around relevant characteristics that we might want to protect, but CIA gives us a good start.


A mitigation[3] in this context is a technique to reduce the impact of an attack on whichever of C, I or A is (or are) affected.


An attack[1] is an action or set of actions which affects the C, the I or the A of a system. It’s the breaking of the protections applied to safeguard confidentiality, integrity or availability. An attack is possible through the use of an exploit.


An exploit is a mechanism to affect the C, the I or the A of a system, allowing an attack. It is a technique, or set of techniques, employed in an an attack, and is possible through the exploiting[2] of a vulnerability.


A vulnerability is a flaw in a system which allows the breaking of protections applied to the C, the I or the A of a system. It allows attacks, which take place via exploits.

One thing that we should note is that a vulnerability is not necessarily a flaw in software: it may be in hardware or firmware, or be exposed as an emergent characteristic of a system, in which case it’s a design problem. Equally, it may expose a protocol design issue, so even if the software (+ hardware, etc.) is a correct implementation of the protocol, a security vulnerability exists. This is, in fact, very common, particularly where cryptography is involved, but cryptography is hard to do.

1 – a successful one, anyway.

2 – hence the name.

3 – I’ve written more about mitigation in Mitigate or remediate?.

5 Rust reflections (from Java)

I’m a (budding) Rustacean.

It’s been a long time since I properly learned a new language – computer or human. Maybe 25 years. That language was Java, and although I’ve had to write little bits of C (very, very little) and Javascript in the meantime, the only two languages I’ve written much actual code in have been Perl and Java. As I’ve posted before, I’m co-founder of a project called Enarx (latest details here), which is written almost entirely in Rust. These days I call myself an “architect”, and it’s been quite a long time since I wrote any production code. In the lead up to Christmas last year (2019), I completed the first significant project I’ve written in quite a few years: an implementation of a set of algorithms around a patent application, in Java. It was a good opportunity to get my head back into code, and I was quite pleased with it. I wrote it with half a mind to compile it into WebAssembly as a candidate workload for Enarx, but actually compiling it turned out to be a bit of a struggle, and work got in the way, so completed a basic implementation, checked it into a private github repository and generally forgot about it.

My involvement with the Enarx project so far has been entirely design and architecture work – plus documentation, marketing, evangelism, community work and the rest, but no coding. I have suggested, on occasion – almost entirely in jest – that I commit some code to the project in Perl, and it’s become a bit of a running joke that this would be the extent of any code I submitted, as possibly my involvement with the project, as it would be immediately rejected. And then, about a week and a half ago, I decided to learn Rust. And then to rewrite (including, where necessarily refactoring) that Java project I wrote a few months ago. Here are some of my thoughts on Rust, from the point of a view of a Java developer with a strong Object-Oriented background.

1. Rust feels familiar

Although many of the tutorials and books you’ll find out there are written with C and C++in mind, there’s enough similarity with Java to make the general language feel familiar. The two tutorials I’ve been using the most are The Rust Programming Language online and Programming Rust in dead tree format, and the latter makes frequent references to similarities and differences to and from other languages, including not only C, C++ and Java, but also Python, Javascript and others. Things like control structures and types are similar enough to Java that they’re generally simple to understand, and although there are some major differences, you should be able to get your head round the basics of the language pretty simply. Beware, however: one of the biggest initial problems I’ve been having is that Rust sometimes feels too familiar, so I start trying to do things in the wrong way, have to back out, and try to work out a better way: a way which is more idiomatic to Rust. I have a long way to go on this!

2. References make sense

In Rust, you end up having to use references. Frankly, referencing and de-referencing variables was something that never made much sense to me when I looked at C or C++, but this time, it feels like I get it. If you’re used to passing Java variables by reference and value, and know when you need to take steps to do so differently in specific situations, then you’re ready to start understanding Rust references. The other thing you need to understand is why Rust needs you to use them: it’s because Rust is very, very careful about memory management, and you don’t have a Garbage Collector to clean up after you wherever you go (as in Java). You can’t just pass Strings (for instance) around willy-nilly: Rust is going to insist that you know the lifetime of a variable, and think about when it’s ready to be “dropped”. This means that you need to think hard about scope, and introduces a complex concept: ownership.

3. Ownership will make sense

Honestly, I’m not there yet. I’ve been learning and coding in Rust for under two weeks, and I’m beginning to get my head around ownership. For me (as, I suspect, for many newcomers), this is the big head-shift around moving to Rust from Java or most other languages: ownership. As I mentioned above, you need to understand when a variable is going to be used, and how long it will live. There’s more to it than that, however, and really getting this is something which feels a little foreign to me as a Java developer: you need to understand about the stack and the heap, a distinction which was sufficiently concealed from me by Java, but something which many C and C++ developers will probably understand much more easily. This isn’t the place to explain the concept (I’ve found the diagrams in Programming Rust particularly helpful), but in order to manage the lifetime of variables in memory, Rust is going to need to know what component owns each one. This gets complicated when you’re used to creating objects and instantiating them with variables from all over the place (as in Java), and requires some significant rethinking. Combining this with explicit marking of lifetimes is the biggest conceptual change that I’m having to perform right now.

4. Cargo is helpful

I honestly don’t use the latest and greatest Java tools properly. When I started to learn Java, it wasn’t even in 1.0, and by the time I finished writing production code on a regular basis, there wasn’t yet any need to pick up the very latest tooling, so it may be that Java is better at this than I remember, but the in-built tools for managing the various pieces of a Rust project, including dependencies, libraries, compilation and testing, are a revelation. The cargo binary just does the right thing, and it’s amazing to watch it do its job when it realises that you’ve made a change to your dependencies, for instance. It will perform automatic tests, optimise automatically, produce documentation – so many useful tasks, all within one package. Combine this with git repositories, and managing projects becomes saner and easier.

5. The compiler is amazing

Last, but very far from least, is the compiler. I love the Rust compiler: it really, really tries to help you. The members of the community[1] that makes and maintains clearly go out of their way to provide helpful guidance to correct you when you make mistakes – and I, for one, have been making many of them. Rather than the oracular pronouncements that may be familiar from other languages’ compilers, you’ll get colour-coded text with warnings and errors, and suggestions as to what you might actually be trying to do. You will even be given output such as For more information about this error, try rustc --explain E0308. When you do try this, you get (generally!) helpful explanation and code snippets. Sometimes, particularly when you’re still working your way into the language, it’s not always obvious what you’re doing wrong, but wading through the errors can help you get your head round the concepts in a way which feels very different to messages I’m used to getting from javac, for example.


I don’t expect ever to be writing lots of production Rust, nor ever truly to achieve guru status – in Rust or any other language, to be honest – but I really think that Rust has a lot to be said for it. Throughout my journey so far, I’ve been nodding my head and thinking “that’s a good way to do that”, or “ah, that makes so much more sense than the way I’m used to”. This isn’t an article about why Rust is such a good language – there are loads of those – nor about the best way to learn Rust – there are lots of those, too – but I can say that I’m enjoying it. It’s challenging, but one thing that the tutorials, books and other learning materials are all strong on is explaining the reasons for the choices that Rust makes, and that’s certainly been helpful to me, both in tackling my frustrations, but also in trying to internalise some of the differences between Java and Rust.

If I can get my head truly into Rust, I honestly don’t think I’m likely to write any Java ever again. I’m not sure I’ve got another 25 years of coding in me, but I think that I’m with Rust for the long haul now. I’m a (budding) Rustacean.

1 – Rust, of course, is completely open source, and the community support for it seems amazing.

Not quantum-safe, not tamper-proof, not secure

Let’s make security “marketing-proof”. Or … maybe not.

If there’s one difference that you can use to spot someone who takes security seriously, it’s this: they don’t make absolute statements about security. I’m going to be a bit contentious here, and I’m sorry if it upsets some people who do take security seriously, but I’m of the very strong opinion that we should never, ever say that something is “completely secure”, “hack-proof” or even just “secured”. I wrote a few weeks ago about lazy journalism, but it pains me even more to see or hear people who really should know better using such absolutes. There is no “secure”, and I’d love to think that one day I can stop having to say this, but it comes up again and again.

We, as a community, need to be careful about the words and phrases that we use, because it’s difficult enough to educate the rest of the world about what we do without allowing non-practitioners to believe that we (or they) can take a system or component and make it so safe that it cannot be compromised or go wrong. There are two particular bug-bears that are getting to me at the moment – and that’s before I even start on the one which rules them all, “zero-trust”, which makes my skin crawl and my hackles rise whenever I hear it used[1] – and they are (as you may have already guessed from the title of this article):

  • quantum-proof
  • tamper-proof

I’ll start with the latter, because it’s more clear cut (and easier to explain). Some systems – typically hardware systems – are deployed in environments where bad people might mess with them. This, in the trade, is called “tampering”, and it has a slightly different usage from the normal meaning, in that it tends to imply that the damage done to a system or component was done with the intention that the damage didn’t necessarily stop its normal operation, but did alter it in such a way that the attacker could gain some advantage (often, but not always, snooping on activities being performed). This may have been the intention, but it may be that the damage did actually stop or at least effect normal operation, whether or not the attacker gained the advantage they were attempting. The problem with saying that any system is tamper-proof is that it clearly isn’t, particularly if you accept the second part of the definition, but even, possibly if you don’t. And it’s pretty much impossible to be sure, for the same reason that the adage that “any fool can create a cryptographic protocol that he/she can’t break” is true: you can’t assess the skills and abilities of all future attackers of your system. The best you can do is make it tamper-evident: put such controls in place that it should be clear if someone tries to tamper with the system[3].

“Quantum-safe” is another such phrase. It refers to cryptographic protocols or primitives which are designed to be resistant to attacks by quantum computers. The phrase “quantum-proof” is also used, and the problem with both of these terms is that, since nobody has yet completed a quantum computer of sufficient complexity even to be try, we can’t be sure. Even once they do, we probably won’t be sure, as people will probably come up with new and improved ways of using them to attack the protocols and primitives we’ve been describing. And what’s annoying is that the key to what we should be saying is actually in the description I gave: they are meant to be resistant to such attacks. “Quantum-resistant” is a much more descriptive and accurate phrase[5], so why not use it?

The simple answer to that question, and to the question of why people use phrases like “tamper-proof” and “secure” is that it makes better marketing copy. Ill-informed customers are more likely to buy something which is “safe” or which is “proof” against something, rather than evidencing it, or being resistant to it. Well, our part of our jobs as security professionals is to try to educate those customers, and make them less ill-informed[6]. Let’s make security “marketing-proof”. Or … maybe not.

1 – so much so that I’m actually writing a book at it[2].

2 – not just the concept of “zero-trust”, but about trust in general.

3 – sometimes, the tamper-evidence is actually intentionally destroying the capabilities a system so that you can be pretty sure that the attacker wasn’t able to make it do things it wasn’t supposed to[4].

4 – which is pretty cool, though it does mean that you can’t make it do the things it was supposed to either, of course.

5 – well, I’m assuming that most of such mechanisms are resistant, of course…

6 – I fully accept that “better-informed” would be better choice of phrase here.

Jargon – a force for good or ill?

Distinguish an electrical engineer from a humanities graduate: ask them how many syllables are in the word “coax”.

I was involved in an interesting discussion with colleagues recently about the joys or otherwise or jargon.  It stemmed from a section I wrote in a recent article, How to talk to security people: a guide for the rest of us.  In it, I suggested that jargon “has at least two uses:

  1. as an exclusionary mechanism for groups to keep non-members in the dark;
  2. as a short-hand to exchange information between ‘in-the-know’ people so that they don’t need to explain everything in exhaustive detail every time.”

Given the discussion that arose, I thought it was worth delving more deeply into this question.  It’s more than an idle interest, as well, as I think that there are important lessons around our use of jargon that impact on how we interact with our colleagues and peers, and which deserve some careful thought.  These lessons apply particularly to my chosen field of security.

Before we start, there should be some definition.  It’s always nice to have two conflicting versions, so here we go:

  1. Special words or expressions used by a profession or group that are difficult for others to understand. (Oxford dictionaries –
  2. Without qualifier, denotes informal ‘slangy’ language peculiar to or predominantly found among hackers. (The Jargon File –

I should start by pointing out that the Jargon File (which was published in paper form in at least two versions as The Hacker’s Dictionary (ed. Steele) and the New Hacker’s Dictionary (ed. Raymond)) has a pretty special place in my heart.  When I decided that I wanted to “take up” geekery properly[1][2], I read my copy of the the New Hacker’s Dictionary from cover to cover, several times, and when a new edition came out, I bought that and did the same.  In fact, for many of the more technical readers of this blog, I suspect that a fair amount of your cultural background is expressed within the covers (paper or virtual) of the same, even if you’re not aware of it.  If you’re interested in delving deeper and like the feel of paper in your hands, then I encourage you to purchase a copy, but be careful to get the right one: there are some expensive versions which seem just to be print-outs of the Jargon File, rather than properly typeset and edited versions[3].

But let’s get onto the meat of this article: is jargon a force for good or ill?

The case against jargon – ambiguity

You would think that jargon would serve to provide agreed terms within a particular discipline, and help ambiguity around contexts.  It may be a surprise, then, that first problem that we often run into with jargon is name-space clashes.  Consider the following.  There’s an old joke about how to distinguish an electrical engineer from a humanities[3] graduate: ask them how many syllables are in the word “coax”.  The point here, of course, is that they come from different disciplines.  But there are lots of words – and particularly abbreviations – which have different meanings or expansions depending on context, and where disciplines and contexts may collide.  What do these mean to you[5]?

  • scheduling (kernel level CPU allocation to processes OR placement of workloads by an orchestration component)
  • comms (I/O in a computer system OR marketing/analyst communications)
  • layer (OSI model OR IP suite layer OR other architectural abstraction layer such as host or workload)
  • SME (subject matter expert OR small/medium enterprise)
  • SMB (small/medium business OR small message block)
  • TLS (Transport Layer Security OR Times Literary Supplement)
  • IP (Internet Protocol OR Intellectual Property OR Intellectual Property as expressed as a silicon component block)
  • FFS (For Further Study OR …[6])

One of the interesting things is that quite a lot of my background is betrayed by the various options that present themselves to me: I wonder how many of the readers of this will have thought of the Times Literary Supplement, for example. I’m also more likely to think of SME as the term relating to organisations, because that’s the favoured form in Europe, whereas I believe that the US tends to SMB.  I’m sure that your experiences will all be different – which rather makes my point for me.

That’s the first problem.  In a context where jargon is often praised as a way of short-cutting lengthy explanations, it can actually be a significant ambiguating force.

The case against jargon – exclusion

Intentionally or not – and sometimes it is intentional – groups define themselves through use of specific terminology.  Once this terminology becomes opaque to those outside the group, it becomes “jargon”, as per our first definition above.  “Good” use of jargon generally allows those within the group to converse using shared context around concepts that do not need to be explained in detail every time they are used.  An example would be a “smoke test” – a quick test to check that basic functionality is performing correctly (see the Jargon File’s definition for more).  If everyone within the group understands what this means, then why go into more detail?  But if you are joined at a stand-up meeting[7] by a member of marketing who wants to know whether a particular build is ready for release, and you say “well, no – it’s only been smoke-tested so far”, then it’s likely that you’ll need to explain.

Another enduring and complex piece of jargon is the use of “free” in relation to software.  In fact, the term is so ambiguous that different terms have evolved to describe some variants – “open source”, “FOSS” – and even phrases such as “free as in speech, not as in beer”.

The problem is that there are occasions when jargon can be excluding from others, whether that usage is intended or not.  There have been times for most of us, I’m sure, when we want to show that we’re part of group and so use terms that we know another person won’t understand.  On other occasions, the term may be so ingrained in our practice that we use it without thinking, and the other person is unintentionally excluded.  I would argue that we need to be careful to avoid both of these usages.  Intentional exclusion is rarely helpful, but unintentional exclusion can be just as damaging – in ways more so, as it is typically unremarked and is therefore difficult to remedy.

The security world seems particularly prone to this behaviour, I feel.  It may be that many security folks have a sound enough grounding in other spheres – especially those in which they’re working with others – that the overlap in the other direction is less noticeable.  The other issue is that there’s a certain elitism with security folks which is both laudable – you want the best people, with the best training, to be leading the field – and lamentable – elitism tends to lead to exclusion of members of other groups.

A quick paragraph in praise of jargon

It’s not all bad, however.  We need jargon, as I noted above, to enable us to discuss concepts, and the use of terms in normal language – like scheduling – as jargon leads to some interesting metaphors which guide us in our practice[8].  We absolutely need shared practice, and for that we need shared language – and some of that language is bound, over time, to become jargon.  But consider a lexicon, or a FAQ, or other ways to allow your colleagues to participate: be inclusive, not exclusive.

1 – “properly” – really?  Although I’m not sure “improperly” is any better.

2 – oh, remember that I actually studied English Literature and Theology at university, so this was a conscious decision to embrace a rather different culture.

3 – or “Liberal Arts”.

4 – the most recent “real” edition of which I’m aware is Raymond, Eric S., 1996, The New Hacker’s Dictionary, 3rd ed., MIT University Press, Cambridge, Mass.

5 – I’ve added the first options that spring to mind when I come across them – I’m aware there are almost certainly others.

6 – believe me, when I saw this abbreviation in a research paper for the first time, I was most confused, and actually had to look it up.

7 – oh, look: jargon…

8 – though metaphors can themselves be constraining as they tend to push us to thinking in a particular way, even if that way isn’t entirely applicable in this context.