Quotes
EDS
+61 (0)447 630 229
Anonymous
EDS

RFCs

  1. RFC2119 - must, should, may, ..., this is the document to reference in all your documents, like seriously.
  2. RFC1925 - "It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea."

IETF - Internet Engineering Task Force

  1. “We reject: kings, presidents, and voting. We believe in: rough consensus and running code" - David Clarke
  2. "The OSI view is entirely opposite. You take written contributions from a much larger community, you put the contributions in a room of committee people with, quite honestly, vast political differences and all with their own political axes to grind, and four years later you get something out, usually without it ever having been implemented once. So the Internet perspective is implement it, make it work well, then write it down, whereas the OSI perspective is to agree on it, write it down, circulate it a lot and now we’ll see if anyone can implement it after it’s an international standard and every vendor in the world is committed to it. One of those processes is backwards, and I don’t think it takes a Lucasian professor of physics at Oxford to figure out which.” – Marshall Rose

Grace Hopper (aka Amazing Grace)

Grace Brewster Murray Hopper (née Murray December 9, 1906 – January 1, 1992) was an American computer scientist and United States Navy rear admiral.1 One of the first programmers of the Harvard Mark I computer, she was a pioneer of computer programming who invented one of the first linkers. She popularized the idea of machine-independent programming languages, which led to the development of COBOL, an early high-level programming language still in use today.

  1. "You manage things, you lead people. We went overboard on management and forgot about leadership. It might help if we ran the MBAs out of Washington."
  2. "It's easier to ask forgiveness than it is to get permission."
  3. "We must state relationships, not procedures"

Telectronics

  1. "We can crash through this hurdle" - Steve Marshall, 23/8/94.
  2. "This thing looks like a camel with wings, If we take some of the humps off, It might just fly." - Keith Daniels

George Orwell on writing

  1. Never use a metaphor, simile or other figure of speech which you are used to seeing in print.
  2. Never use a long word where a short one will do.
  3. If it is possible to cut a word out, always cut it out.
  4. Never use the passive where you can use the active.
  5. Never use a foreign phrase, a scientific word or a jargon word if you can think of an everyday English equivalent.
  6. Break any of these rules sooner than say anything outright barbarous.

And read his books, for this is the time.

Egoless Programming: Gerald Weinberg

Understand and accept that you will make mistakes.

The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.

You are not your code.

Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.

No matter how much "karate" you know, someone else will always know more.

Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.

Don't rewrite code without consultation.

There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.

Treat people who know less than you with respect, deference, and patience.

Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.

The only constant in the world is change.

Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.

The only true authority stems from knowledge, not from position.

Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.

Fight for what you believe, but gracefully accept defeat.

Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry. https://en.wikipedia.org/wiki/Marshall_Rose

Don't be "the guy in the room."

Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.

Critique code instead of people – be kind to the coder, not to the code.

As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

The human principles of software from The Psychology of Computer Programming.

Edsgar W. Dijkstra Quotes

My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself "Dijkstra would not have liked this", well, that would be enough immortality for me. -- Dijkstra (1995) "Introducing a course on calculi" (EWD 1213). Dijkstra (1988) "On the cruelty of really teaching computing science (EWD1036).

It is time to unmask the computing community as a Secret Society for the Creation and Preservation of Artificial Complexity. -- Dijkstra (1996) "The next fifty years" (EWD 1243a).

Gernot Heiser

See http://gernot-heiser.org/, well worth a look, my boss approves of the McNamara Fallacy.

There's a war on... between people who are trying to do something and the people who are trying to keep them from doing something wrong. -- Wilbur L. "Bill" Creech, Former commander of the USAF

The bad guys are winning -- Gernot Heiser

Mcnamara Fallacy:

  1. The first step is to measure whatever can be easily measured. This is ok as far as it goes.
  2. The second step is to disregard that which can't be easily measured or to give it an arbitrary quantitative value. This is artificial and misleading.
  3. The third step is to presume that what can't be measured easily really isn't important. This is blindness.
  4. The forth step is to say that what can't be measured really doesn't exist. This is suicide.

Caine

  1. Repay injury, with justice and forgiveness, but kindness, always with kindess.
  2. Fear creates the victim.... I will survive if I can.
  3. Caine: I have been in the marketplace. All of the men there argue and fight. There is no peace.
    Master Po: Why does that trouble you, when your home is here?
    Caine: I want all men to know peace.
    Master Po: It is written in the 'Tao Te Ching', "Under heaven, all can see beauty as beauty only because there is ugliness. All can know good as good only because there is evil. Therefore, having and not having arise together. Difficult and easy complement each other. High and low rest upon each other. Front and back follow one another."
    Caine: But Master, do we not want all men to know our peace, our joy?
    Master Po: Would you make the whole world a temple? Be like the sun, and what is within you will warm the earth.

Telectronics

  1. Paul Trainor- just a small article with a few nice quotes.
  2. TPF - the Telectronics Peoples Fronthttps://www.youtube.com/watch?v=1ZV2eoULEqw
  3. GotoFail - worth reading including: "We have come to depend daily on great obscure texts, drafted not by people we can truthfully call "engineers" but by a largely anarchic community we would be better of calling playwrights." - Stephen Wilson.
  4. "For critical modules, like the kernel and error correction routines, we walked through the compiled assembly code. We took the time to simulate the step-by-step operation of the machine code using pen and paper, each team member role-playing parts of the microprocessor (Phil would pretend to be the accumulator, Lou the program counter, me the index register). By the end of it all, we had several people who knew the defib's software like the back of their hand." Stephen Wilson

Security and Virtual Machines

Here's the full Theo de Raadt quote from 2007 in response to:

"> Virtualization seems to have a lot of security benefits".

"You've been smoking something really mind altering, and I think you should share it.

x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

You've seen something on the shelf, and it has all sorts of pretty colours, and you've bought it.

That's all x86 virtualization is."

(Aside: perhaps not for some machines and small kernels, but never the less true, VPN as an answer are similar).

Security and 2FA in Industrial Control Systems

"Its great my operators from anywhere with their tablets and its all secure because of 2 factor authentication and their mobile phones" -- unknown person

"Ahm, even if 2FA works properly your wide open to a dropper on the tablet having a go once the 2FA starts, aren't you?" -- unknown person 2

Ted Egan: my ex Colonel, a wise man

  1. Drovers Boy - an important song.
  2. The fizzer - Phils title, well at one time at least.
  3. Due Inheritance - Teds view, worth looking at