josephkern

Weapons are tools (admittedly tools for separating nervous systems from muscles as quickly as possible), all tools should be safe and reliable.

The longevity and ease of destruction is probably a primary concern for this media.

Not everyday you see a Top Secret sticker flashed on national television. I bet there are 20 intelligence organizations trying to read the label on that floppy disk.

Obviously not talking about servers here. Those RAID can take more than a few minutes to spin-up.

Possibly the most realistic job posting I've read.

Which is probably true even on a more objective measurement of "enriching". Sturgeon's Law is always in effect.

Google maps and Google earth are used extensively for imagery analysis and intelligence work. They aren't working with the maps team so much as using it as a tool.

sysadmin here; I've been enjoying An Introduction to Programming in Go by Caleb Doxsey[1]. Short, sweet, and right to the point without being terse.

There is nothing in this book that will directly relate to using go as an automation language, but I'd rather learn the fundamentals before learning specialized examples.

[1]: http://www.golang-book.com/

It was built around software engineering principles (rather than experimental language constructs). The attention to small details (imports via git/bzr/hg, gofmt, go run, etc) deeply resonates with system admins (or at least myself and the OP).

My apologies garry, I didn't look at the OP. Personal blogs are personal. ;-)

I completely misunderstood your initial comment.

Garry, yes curation is important, in fact, that's why HN exists, to curate and comment primary sources.

If the article has already been submitted then why try to resubmit it after copying and pasting the content into another URL?

The best way to do this on HN is to take the stance of the opposition and write an inflammatory headline, "I support (unpopular position) X, because (popular position) Y is considered harmful"

I can't work right now, Tim has the cone.

(this was a pretty great idea from the manager though)

"Slashdot OP misses the point. You're supposed to upgrade your runtime periodically. They're years behind."

Never supported mission/life critical apps in an enterprise that require an older runtime? It's not the users fault that a dev built an application that's only compatible with a specific runtime version.

The issue at hand, was the General's use of reading as a way to ensure the things he is in charge of building (Marines), do not go to waste. Long in the making, quick in the breaking.

> I have to see something applied in practice, on my own, before I can really internalize something and grow.

This skill, reading, takes a while to develop. Understanding what is said and not said, and what it means in context takes practice and deliberate thought.

Learning while building works well only when your effective materials cost (as in software) is zero.

Perfect is the enemy of productive.

I believe the comment about video game developers concerns useability and not fitness. I've been playing video games for many years, and from a useability standpoint, game manuals have dwindled to nothing. If the game does not teach me how to use the functionality during game play I really have no patience for the game anymore.

Enterprise software should take a similar approach. Have something of a tutorial mode, and an easily searchable text based document. Most of the cost in the software comes not from the actual price, but in employee productivity and training.

It did get Google into Forbes ...

Marco, you might also think of RSS readers like an archived narrow band search for high volume traffic. For example: I am a security researcher, so I susbscribe (via RSS) to everything security related that I can find: mailing lists, bleeding edge snort ruls, CVE, blogs, SANS, etc, etc.

Now when I want to see the current state of affairs in Ineternet Explorer security issues, I can simply search for "Internet Explorer" in my RSS reader. I am then presented with the traffic on the latest issues, their possible resolutions, and even possibly the person who discovered the issue.

The beauty of RSS is that it lets me decide what it will be, and when I want it to be that way.

> There was an actual book called How to Read a Book published in the 1940s. It focused almost entirely on non-fiction and encouraged the reader to analyze everything ad nauseam. In case you hadn't guessed, this essay is exclusively about fiction (never let mere accuracy get in the way of a good title) and advocates entirely the opposite approach.

No it advocates the entirely SAME approach.

I think if the OP had actually read "How to Read a Book", the OP might have found that there are some excellent techniques presented, and the authors make a very clear definition between reading for enjoyment and reading for education.

It is one thing to read a single novel for pleasure, quite another to survey all available literature on a subject and to figure out what has not yet been written.

Perhaps if the OP had actually read the book ...

But now you are in the position where you know your work looks bad. Imagine when you were younger and said, "This, this right here is better than anything anyone has ever written."

At least now you have a decent smell test.

Lutusp's Editorial Uncertainty Principle.

You fail to understand that true security is not about passwords or control; true secrity is about risk mitigation.

Control is an ignorant tyrants last redoubt. Security is only about: identifying risks and dealing with those risks. All other messures are worthless as actual security objectives.

I am not arguing with you in priciple, only in particular. All of your points are well taken, to reduce risk, but not to control.

Picky is good! We never grow without constructive critisim. And a community of practice may yeild better results than an individual (at least for simple things).

> I'd recommend people read that article with a degree of scepticism before rushing onto any boxes they might administrate.

Agreed. But the same could be said of everything; hackers and engineers, empiricists both.

Some of the advice in the article would seem apporpriate to someone who had never worked with another senior engineer. No fault of the OP.

System engineering and security are as much a learned craft as a science; a dialectic between sand castles (if you will).

Firstly, a nice checklist. Easy actionable steps, repeatable, and pretty much most of what you need.

Secondly, you are about 4-5 hours away from learning puppet (or Chef) and making this checklist into actual code.

Thirdly, you now have a checklist of items that you can use in a job interview if you get the oppertunity to gain a new-hire or an intern.

Lastly, good on you for submitting this to a peer-review on HN. We can be a picky lot.

TL;DR Checklists are a good first step for building a proper config management system.

Areon with a standing desk (motorized) is a very nice combination. I like having a choice about where/how I work.

Just make sure you get long enough cables if your computer is under your desk.

Sorry to hear that, don't be so hard on yourself in the future. This is hard work (even if it is fun). As a post-mortem you did one thing right and one thing wrong.

What you did right: You accepted responsibility. Good, this is a hard trait to find. The "perfect" engineer mixes equal parts intellegence and humility.

What you did wrong: You didn't trust your team. They were all very supportive of you, but you didn't trust their assesment of you.

Trust your team; trust yourself. Have confidence in your ability to learn from your mistakes.

You'll do fine. Start looking for another start-up job while working at a corp.

The best time to find a new job, is when you already have one.

Already there; they are called aerostats.

How will you be different than bswift.com?

As a user of bswift I was given a printed booklet specific to my company and was presented with the easiest web page enrollment and benifit summary I've ever seen.

Will you be a competitor to apps like bswift? What are your plans for differentiation (if any)?

I’m having trouble trying to find an instance of people not waiting on you at work (any work). Either it's real work with real consequences or it's busy work.

As A sysadmin, I have two general rules about scripting;

1. If it's longer than 15 lines, rewrite it in {python,ruby,perl} 2. Never accidentally rewrite grep, sed or awk.