3amOpsGuy

Linked in is the only social network that's managed to link me to other people in ways i cannot explain.

An example: I had a real life connection to a trainer, i studied for an industry qualification with him. I had zero online line connections to him. Somehow linked in put us together.

His profile mentioned nothing about taking that course, mine mentioned nothing about attending his course. My work handled all the procurement side of things so he had no access to my email address or anything like that.

In credit to linked in, this guy happened to be the best trainer i'd ever studied with so i was actually pleased to see the recommendation. Still wondered how they managed it though!

I agree, it's one of the factors that tipped me into pre-ordering (no word on my delivery yet though!)

There doesn't appear to be that much spare capacity, at least on the 7010's FPGA, around 2k cells IIRC? Certainly won't be creating a bitcoin miner in that :-)

Still the most interesting bit of hardware to come down the pipe yet.

Middle paste has never been a reliable feature, (are you pasting from X clipboard or GNOME clipboard? - it changes depending on context). For that reason alone, i can see a case can be made for this change.

At first glance it seems like a backward move to me, but i'd be at least willing to give the idea a try.

GNOME 3 takes a lot of heat, they're one of the few actually pushing the envelope so it's to be expected i suppose.

A little more encouragement and a little less boring complaints "stating the obvious" would go a long way.

I didn't know about them until recently. To be honest, my first impressions of their site weren't great, just based on visuals i assumed it was some syndicated content with advertising.

How wrong was i. Consistently one of the best feeds in my feedly these days.

That's just the dev concerns.

Here's a rather contrived example but it illustrates the idea i'm getting at: "Will the inventory agent software be able to login to audit this container environment when they're done building their release?"

Skills.

Most developers are not full-stack aware - nor should they be. Having a pack of generalists drive a product is sure to reduce momentum.

Better that the contract is "here's a platform you can deploy to" than "here's some CPU time, break it and you get to keep both pieces"

It's kinda cliched for someone with a username containing "ops" to come out and say "i love checklists", but i do!

I've never found a better tool for communicating what to do and in what order. Everyone just understands them, with zero training. You can even play with the format slightly and people still get it, e.g. break out a formal time column? Sure! People just start using it.

I especially like them for high pressure situations. E.g. for handling prod outages i've consistently found checklists work better in practice than flow charts, knowledge bases, call trees... etc.

I use them for many things, from the fairly benign (releases?) to the relatively rare (new joiners).

I recommend, just based on my experiences so may not apply in all environments, using a simple web based app to handle all your check lists. It'll be accessible from any device, without installing anything up front.

A couple of small extra features will make it infinitely more useful:

1) Allow for both a "ticked" / done status and a "working on" / "i've grabbed this one" status. Display the user who's grabbed it and the time they grabbed it.

2) Allow for checklists to have all their boxes reset on a schedule, e.g. daily reset of the "start of day" check list.

3) Archive completed checklists - they capture useful information about who and when, so I don't bin them when they're completed

"That said, the ISPs objections are likely cost"

And rightly so. If this goes through, i'd like to see the ISPs add a line item to everyone's bill calling this out in plain sight to all their customers. "This month you paid an extra #1.75 to cover the costs of Government censorship infrastructure we're required to purchase / install / maintain.

Would something like Keycard[1] work for locking the screen when you're not nearby?

I wonder if it could be set to lock at boot unless your phone (or BT headphones or whatever) is nearby.

I doubt this can be all that secure since it can be downloaded from the App Store, I'm pretty sure that means it can be force quit (it could not prevent this key combo since its restricted in the sandbox). It may be just enough.

[1] http://www.appuous.com/products/mac/keycard.html

I don't get the extra emphasis on Netflix here either.

Netflix are part of the content industry, it's not that they're the best of a bad bunch, they're actively more open than some artists.

Reduce the quality quotient (severely, like .98 -> .3) and don't cut the resolution as far, e.g. Keep 2x the pixels.

Much better appearance for the same file size.

I like the ingenuity but how would we track when the page has been left - conceivably I could delete an account on Friday then click undo on Sunday.

I guess if it immediately gets soft deleted and in a maintainance batch gets purged. Until maint runs the undo link could still work (although it would still only display until they left the page).

Undo's, yes!

Power users aren't tripped up with an annoying confirmation. Novice users can revert. This seems a much better paradigm.

Are there any cases where this doesn't make for good UX?

This is a really good idea. We already buy in site licences for the Uncle Bob series (kinda comparable idea for programmers), i imagine many other places are the same. This model works quite well.

Does this need funding? I'd be more than happy to chip in some pennies towards this effort.

In my experience it's surprisingly hard to recruit good quality ops people. Actually it's hard just to get recruiting agencies to filter well for ops jobs but that's another story... Anything that might help this is worthwhile investment.

Doesn't work for putting files on the desktop, the ~/Desktop folder doesn't have it's contents displayed on the desktop for some reason. Assuming a gnome3 thing...?

Who can afford to throw CPUs at parallel compute problems today with GPGPUs available? Oil and Gas industry? Nope, the 3 biggest are nVidia customers in a big way. Finance? Nope, some of the smaller companies here have stepped past even GPGPUs and are now co locating FPGAs in the exchanges. Big pharma? Not that I know of, also onto GPU clusters in the 2 big cases I know there.

So yes I would be surprised. Surprise me?

Calling BS on?

A GPU, as you know, doesn't exist in isolation. It sits on a multicore host. The load of input data and the writeback of results does not occur from the GPU as I suspect you know. Maybe in future with unified memory this will be possible but not on current devices.

The actual computation, the bit that was previously multi threaded (or more commonly, multi process) on a CPU, now lives on a GPU. I'm not sure what's silly? The compute bound workload, is now done on the GPU. The IO workload is still done on the CPU, in an inherently single threaded fashion. Even when the multi process computation was done on the CPU, load and store operations were still single threaded. This stands to reason since there is no advantage in splitting 500 concurrent hosts connections into 500* CPU cores connections to hit a central data repository with...

I can't think of any code off the top of my head that calls gethostbyname repeatedly. Maybe a network server of some description which is doing reverse lookups to allow for logging purposes? Although that seems inefficient, I can't think of a real time use case for the host name when you're already in possession of the IP, I can only think of logging / reporting uses cases which would be better served doing the lookup after the fact / offline.

If that's a valid example of what you're suggesting, then would the existing threaded code not be more efficiently implemented asynchronously? There's a finite limit to the number of threads you can create and schedule for these blocking calls, at some point you will have to introduce an async tactic. At that point, why not drop the threading altogether?

You say you would rather build a model on top of threads. Why? Does it make your testing simpler? Does it reduce the time for new starts to get up to speed with your code? Does it reduce the SLOC count? Is it simpler to reason about?

I hope you would agree, in all these cases and many more, threading is at a significant disadvantage. I stand by the assertion that its dead(-ish).

The ish qualifier comes from another case we've not discussed, yet!

Accessing databases, processing data from sockets, are not CPU bound activities? I believe you've misread my post.

For all your IO cases, and all your cases are IO, would you, and future maintainers of your code, not be better served with simpler abstractions which permit scaling past a single host?

How can the GIL, which is restricted to one process, hinder concurrency? It can only impact 1 single form of concurrency, threading.

Why use threads?

Noone does parallel compute on CPUs these days, not since GPGPUs rocked up almost 5 years ago (and we often use python as the host language, thanks pyCuda!)

Parallel IO then? Well, except that async IO is often far more resource efficient (at the cost of complexity though).

Threading is dead(-ish) because its hard to write, hard to test and expensive to get right.

Concurrency in python is very much alive though.

To some extent i agree; most will never scale so why worry about it? X times out of Y you'll come out ahead by just ploughing on and not considering the future. Even if we are thinking up front, we can rationalise that it's just a gamble, often one worth taking!

It definitely doesn't take Facebook sized infra to outgrow a technology though. What if the gamble doesn't pay off? What if you planned to scale the central NFS server dependency by just adding an extra NFS server but have now found there's no rack space left / no budget / a purchasing delay / insufficient network capacity / cooling capacity / power capacity / a.n. other unplanned problem.

For the SSH question, i couldn't reliably get more than 250 concurrent connections outbound from one circa 2008 blade server. From memory that would have had a spec of dual core CPU, maybe around 2.4Ghz with 8Gb ram using PAE as it would have been a 32bit kernel (our spec, the cores will have been 64bit). They were multiply-connected at chassis level on myrinet fabric in one DC and infiniband in another and the resource being exhausted was CPU.

These days all the blade servers are gone but we see an absolute explosion of virtual machines so it's a similar and still relevant problem in many ways.

This is definitely cool but the real hard problem isn't in these simple easily scripted cases. The real hard to solve problem is managing all the complexity of similar-but-different hosts.

This article could just as easily have taken the complete opposite view of Ansible by saying things like "parallel ssh sessions don't scale, strong encryption costs too much CPU time; push can never work reliably therefore pull is the only viable model; etc. etc."

I feel one of Ansible's strongest points to champion is the low barrier to entry. It takes minimal understanding to get going, compare that with at least 1 month hands on with cfengine or perhaps 2 weeks puppet before you would consider yourself proficient enough. With Ansible it's 20 mins or so.

> [they] have no influences that really refute what they believe

> I believe as I do because it is an essential part of who I am (identity)

You've not left much of a case for pi18n to debate with that statement.

This article could really do with a disclaimer at the top. I got about 25% in before i realised there was more than meets the eye (i didn't previously know who jitbit were, i had no idea of their Microsoft relationship).

Something like "we're a member of Microsoft's BizSpark program and you can find out what that means for us here: http://www.microsoft.com/bizspark/About/Default.aspx"

Etsy sounds terrible to say! Sound enough reason not to pursue that idea :-)

I know the old Bell manuals actually spelled out "et cetera" long hand in places, but still, any time i hear someone say that out loud meaning the directory, i have a (wholy irrational) cringe reaction!

You've asked some tough questions which are really against the grain here. You've been respectful, direct to the point and articulate.

Just felt a simple up vote didn't convey enough of a thanks. You've provoked the conversation in far more interesting directions than it would otherwise have taken. Thank you sven7.

True, but it's still advisable just stick to laying out the facts. Don't add in any commentary on top.

The interviewer can and will draw their own conclusions, both about the previous employer you're talking about, and more importantly, you.

ETA - user site packages is a 2.6-onwards feature. Rtools: http://cran.r-project.org/bin/windows/Rtools/

The R guys do a really easy to use package of mingw for satisfying compiler / linker requirements youll find you need (and all the other bits and bobs required).

Another thing worth mentioning is "user site packages" directory for those on locked down corporate machines. Pip install --user <package> will pop the package in %UserProfile%\Python\Python2X\site-packages\ - which is automatically on your $PYTHONPATH saving a little setup hassle.

Examples or evidence for any of those 3 claims? Appears to be wind and noise.