m0nastic

The research paper authors also posted a python package on GitHub that generates these reports: https://github.com/responsibleproblemsolving/energy-usage

It's of varying importance depending on what field of security you're talking about, but generally it's the chasm that separates entry-level security folks from the rest.

Using systems administration as an analog, there exists a class of sysadmins who can't write even basic scripts. Their ability to troubleshoot or problem solve are limited to using predefined tools. Whole categories of tasks will be infeasible for them to accomplish (mostly because of the amount of time it would take to do them manually, not necessarily because they are technically impossible).

Lacking the ability to do any programming limits their job prospects to the bottom of the sysadmin barrel. That being said, programming isn't necessarily a prerequisite for their job, it's just a ceiling.

Going back to security, most tasks benefit from the ability to automate some part of them. I come from application security, where that frequently manifests in having to quickly piece together tools for interfacing with a specific protocol or API. Application consulting exacerbates that even more, because you'll usually have to do all of this in a very short amount of time, so that you can spend the allotted assessment time actually doing the assessment, and not trying to get your tools to work with the environment.

This is a wonderful sentiment, but as someone who lives next door to this place, you absolutely don't want to eat there.

If you come to DC, by all means buy some food from there, but then throw it in the garbage and I'll happily treat you to a much better dinner.

I'm biased because John Ennis played one of the lawyers, but that one was absolutely my favorite of these.

A few years back I picked up "Russian Criminal Tattoo Encyclopedia Volumes 1-3" on Amazon[1] for something I was working on and they are fascinating.

[1] http://www.amazon.com/Russian-Criminal-Tattoo-Encyclopaedia-...

I can't narrow it down to one (it's like trying to pick a favorite binary message format), but the best I can do:

A Single Man - Christopher Isherwood. A beautifully somber story of a gay man dealing with loss in the 60's. When I read it as a kid, it helped deal with the sense of alienation I was feeling during my adolescence. Also the movie a few years back (while ending fairly different from the book), was awesome.

The Big Sleep - Chandler. Literary people all seem to prefer Hammett to Chandler, but for my money there's never been better prose written before or since. "Dead men are heavier than broken hearts" and "I never saw any of them again - except the cops. No way has yet been invented to say goodbye to them." are two of my favorite sentences of all time.

Before Night Falls - Reinaldo Arenas. It's technically an autobiography, but I read it as a novel. More alienation (this time in 1970's Cuba), but written amazingly well (even the English translation).

Dear Mr. Henshaw - Beverly Cleary. I'm not embarrassed to list a kids book as one of my favorite novels (considering how many people on here I'm sure loved Harry Potter). It's a story about a kid who's dad left him, and it's written as a series of one-sided letters to an author (the titular Mr. Henshaw). I re-read it about twice a year (it's a short book).

I've been using Haskell at work for the past two years, but despite the fact that it's been a great investment, I don't really like articles like this.

I find evangelism gross, and in particular, developer technology evangelism especially distasteful.

That said, I take issue with the objectiveness of your points. For the first one, there are indeed quite a few successful systems written in Haskell (I suppose I might be quibbling with your definition of "successful"). Facebook is using Haskell for a few things internally (including their rule engine for fraud/spam processing), Standard Charter is using Haskell. In fact, here's a whole site of people using Haskell in industry (https://wiki.haskell.org/Haskell_in_industry)

I do think that it's only recently that you're starting to see projects/products built with Haskell that aren't libraries. Just this week there's been a bunch of web frameworks released (Airship and Spock, with Silk releasing a REST API framework a couple of months ago).

I'd like to see more projects that people can use that don't have to care about the fact that the software is written in Haskell (databases and data analytics systems are a particular area I'd like to see become less Java-focused).

Your second point on mutable state seems counter to a lot of the current conventional wisdom of the past five years, which is that immutability is vastly preferred to mutability. This is becoming true in Javascript (with React and Underscore), has always been true in Clojure, and is becoming more and more important in any system that deals with concurrency.

You can certainly disagree that mutable state is the root of all evil, or even the most important problem with modern development; but I don't think it's accurate to paint Haskell as being the weirdo fringe language that's advocating immutability is the way to go. They have a lot of company on that front, they've just been making the point for a lot longer than most.

Your third point seems like you just completely made it up. Do you have evidence that Haskell programmers are "usually smarter than Java programmers"?, or that they are somehow inordinately picky about what projects they work on? Do you know many professional developers who work in Haskell?

It's true that the population of Java programmers is probably an order of magnitude larger than Haskell programmers (the number of universities who still teach Java for their introductory CS classes would probably guarantee that's the case), but contrary to what message board lore would have you believe, Haskell isn't some magical "smart person" language.

I'm an idiot and I haven't had any trouble using it full-time. I don't use it for crazy math stuff, or advanced computer-science research. I use it to process events, interact with databases, and display CRUD operations (like probably 80% of most enterprise-y software development).

Haskell's design flaws, while certainly existent, don't seem appreciably above or below any other language (I'm trying not to be smug, I actually think Haskell is much better designed than most any other language). I can happily attest that the record field scoping has not actually been an issue (although maybe I've just been lucky, and there's actually a bunch of other idioms for dealing with the scoping issue like lenses).

Lots of other people have suggested Neruda, which makes me happy, because he's fantastic.

I think my favorite poem is probably "Under Milk Wood", by Dylan Thomas (folks have posted some of his other work, which sheepishly I don't really like). I love this poem so much that even hearing it in a VW ad didn't diminish it. It's quite long, but the beginning is my favorite part:

  To begin at the beginning:

  It is Spring, moonless night in the small town, starless and bible-
  black, the cobblestreets silent and the hunched, courters'-and- 
  rabbits' wood limping invisible down to the sloeblack, slow, black, 
  crowblack, fishingboat-bobbing sea. 

  The houses are blind as moles (though moles see fine to-night in the 
  snouting, velvet dingles) or blind as Captain Cat there in the muffled 
  middle by the pump and the town clock, the shops in mourning, the 
  Welfare Hall in widows' weeds. And all the people of the lulled and 
  dumbfound town are sleeping now.

  Hush, the babies are sleeping, the farmers, the fishers, the tradesmen 
  and pensioners, cobbler, schoolteacher, postman and publican, the 
  undertaker and the fancy woman, drunkard, dressmaker, preacher, \
  policeman, the webfoot cocklewomen and the tidy wives. Young girls lie 
  bedded soft or glide in their dreams, with rings and trousseaux, 
  bridesmaided by glow-worms down the aisles of the organplaying wood. 

  The boys are dreaming wicked or of the bucking ranches of the night and 
  the jollyrogered sea. And the anthracite statues of the horses sleep in  
  the fields, and the cows in the byres, and the dogs in the wet-nosed 
  yards; and the cats nap in the slant corners or lope sly, streaking and 
  needling, on the one cloud of the roofs.

  You can hear the dew falling, and the hushed town breathing.

  Only your eyes are unclosed to see the black and folded town fast, and slow, asleep.

  And you alone can hear the invisible starfall, the darkest-before- dawn 
  minutely dewgrazed stir of the black, dab-filled sea where the 
  Arethusa, the Curlew and the Skylark, Zanzibar, Rhiannon, the Rover, 
  the Cormorant, and the Star of Wales tilt and ride.

  Listen. It is night moving in the streets, the processional salt slow 
  musical wind in Coronation Street and Cockle Row, it is the grass 
  growing on Llareggub Hill, dewfall, starfall, the sleep of birds in 
  Milk Wood.

  Listen. It is night in the chill, squat chapel, hymning in bonnet and 
  brooch and bombazine black, butterfly choker and bootlace bow, coughing 
  like nannygoats, suckling mintoes, fortywinking hallelujah; night in 
  the four-ale, quiet as a domino; in Ocky Milkman's lofts like a mouse 
  with gloves; in Dai Bread's bakery flying like black flour. 

  It is to-night in Donkey Street, trotting silent, with seaweed on its 
  hooves, along the cockled cobbles, past curtained fernpot, text and 
  trinket, harmonium, holy dresser, watercolours done by hand, china dog 
  and rosy tin teacaddy. It is night neddying among the snuggeries of 
  babies.

For years I've tried to figure out good advice to this question, but I've never been able to successfully articulate it. Here's attempt++.

There's two things that would be helpful to know before providing advice, and they might not be things that you even know the answer to yet; but it's worth considering.

First, what are your reasons for being interested in security. Is it because it's a good job market? Or because you think it sounds cool? Or, god forbid because you think of it as a higher calling? There's nothing inherently good or bad about any of those three choices (except people who believe the third one I find unbelievably tedious to be around), but it definitely effects what advice I'd give. I'm going to assume it's the second one (based on the way you worded your question).

Secondly, security is an ever-expanding field, and in particular, the domain knowledge for each piece of it is starting to take up all available volume in any person's individual skill-bag.

At the risk of somewhat oversimplifying, you can pretty much carve out a full and successful career in infosec in any of the four fields: network security, application security, incident response, general-purpose security practitioner.

Each of those requires skills that are very different than the other 3, and each can be a totally fulfilling choice to make (most of us have wound up in a specific specialty and probably don't enjoy working in one of the other 3, but don't let my or anyone else's distaste for one of them sway you).

Network security is what it sounds like. It's basically the people who do penetration tests. At the bottom end of that field, it's the people who click "run" on a Nessus scan. At the higher end, it's the people who come up with interesting research around protocol vulnerabilities and exploits. Like any field, the vast majority of people aren't at the high end. Without passing judgement, Network security was the first piece of infosec to start to become commoditized, thereby making it probably the least desirable from a financial perspective. This isn't true at the high end, but then again, it's never true at the high end.

It's probably where the majority of people start out, regardless of where they end up. You can thank the mid-90's era of terrible system security and compliance audit requirements for that.

Application security is probably the most applicable for people who have a development background (although again, at the higher end of network security, you are writing code, and exploiting other people's code). It started as a field in pretty much the late 90's. My company saw the writing on the wall that network security was going to become more and more commoditized and we shifted our focus to application security. For most of my career, that has predominantly been web application security. Other places do work on "native-applications", embedded systems, etc. It really depends on the firm. Application security has become more and more important as more and more of people's lives have shifted to include doing things online. Again, not trying to make a value judgement (although as someone who has worked mostly in AppSec, I'm definitely biased), but it's where I would place my bets for at least the foreseeable future career-relavence wise.

Incident Response has only really come into the limelight the past 5 or 6 years. It's been a thing since the 80's, but it was mostly ignored while people tried to convince themselves that they could build secure systems that would actually keep attackers out. The thinking around that has started to change (although in some cases just as an excuse by security people to absolve themselves of responsibility for doing a shitty job). Incident Response will probably never go away, because it's sort of the existential reality of doing business with machines that have to trust one another. Currently, it also commands the highest premium money-wise (but those halcyon days won't last forever).

Incident Response tends to attract the most "higher calling" people, so be careful about that. People who enjoy it will try to sell it to you as being "detective work", tracking down intruders, gathering evidence, and keeping them out of your systems. People also describe tiny, rat-infested NYC apartments as being "homey fixer-uppers".

Incident Response is usually the highest stress of any infosec job (although that, like everything else I've said will vary from place to place). It's the field most likely to wake you up at 3 am on a Friday morning and make you head to the airport on no notice to go help someone whose network is currently being lit on fire by undergrads at a research university for some foreign country. Some people enjoy that pressure, and the reactive nature of the work (you never know where you'll be going from day to day).

Lastly is "general-purpose security practitioner". This role is almost exclusively someone who work in the security group at a company who has nothing to do with security. You might think that it's a combination of all the other roles (the Bards of infosec), and while that can be slightly true, it's more the people who have to deal with all the non-technical parts of security. Security within a company is mostly concerned with compliance, audits, and policies. That's the stuff that the general-purpose security practitioner works on. As part of that, they might occasionally run a Nessus scan, or set up an application in WebInspect (or be woken up at 3am when an incident occurs), but they will spend the majority of their day reading and writing word documents, and having meetings with the marketing team trying to get them to stop using Dropbox to send all their sensitive corporate documents back and forth.

There's other variables too, like whether you work as a consultant, or work for a security product company; but in general if you work in Infosec, you'll be doing some combination of these four things. I haven't said anything about cryptography, because really there's very little overlap between the crypto industry and the infosec industry (to both of their detriment, I suspect).

I actually think anyone in Infosec would probably benefit from spending time in all of those roles, not just to get a better sense for them, but also to help challenge their assumptions. I also think security people can benefit greatly from going between being a consultant (where you potentially help lots of companies very little) and working internal to a company (where you potentially help one company very much).

So my advice is figure out which of those things sounds the most interesting and start down that path.

I don't really recommend doing CTF's unless you like doing CTF's (they have almost nothing to do with anything you'd actually be doing in the field).

And don't get a CISSP unless you opt to work in the general-purpose security practitioner field (even then, only do it if you have to). It's actually a negative hiring signal at almost any place you'd actually want to work.

RSA isn't in remotely the same space as Matasano, nor would it be "one of the largest" if it were in that space.

As I rock back and forth in my chair, silently repeat the serenity prayer, and try to remain charitable; what sort of work do you think Matasano (or NCC, Accuvant, or VerizonBusiness, my former employer) does?

I ran the professional services division for one of the largest companies in the same space as Matasano.

I'd love to hear what you think the NSA might have persuaded us to do?

Without knowing what his next project is, maybe I'm mis-reading the statement; but I took that as more of a condemnation against the web than against Javascript specifically.

I take issue with "often", as the vast majority of mobile phones don't have anything (even if there exist specific models which could have them).

There was a brief window in time when you had to go out of your way to buy an Intel laptop "without" a TPM (even Macs had them for a time, even if Apple never made use of them). The Trusted Computing Group failed to capitalize on that timeframe by providing both a "reason" and decent solutions to that problem.

There's a lot of reasons why that was, if I've been drinking I'd happily go into many of them.

On the mobile side, I agree, it's a hodgepodge. Apple has their secure enclave (which doesn't quite act like a TPM, even though it theoretically could), and there exist vendors who could theoretically include a TEE in their phones (right now they're almost entirely limited to special "government-specific" use cases).

And I'm ignoring Samsung's solution (which is basically snake oil).

Intel's SGX would be great, provided that the industry suddenly switches to X86 for mobile (which I don't think is going to happen).

The mobile industry is way too fragmented from a hardware perspective for any type of trusted computing platform to achieve even a modicum of install base. That might change in the future, but I wouldn't bet on it.

I've worked implementing both, and Bromium is basically as good of a solution to this problem as you're going to get, in the sense that it requires the least modification of user behavior (the user's Windows machine mostly behaves like a normal one).

Even Bromium was pretty upfront about the use case for their product though (high-value targets like executives who travel to China). They were very honest about it being overkill for an entire enterprise.

I think securing endpoints is basically a lost cause though (I'm happy to consider that a minority opinion however). My company spent many years trying to get TPM's to be the solution to this problem, and I'm pretty sure that ship has now sailed; with the only 2 sectors of the industry that are continuing to grow being completely unsuited to TPMs (virtualization and mobile).

I think we'll eventually realize that much like networks, devices have to assumed to be untrustworthy, and we have to route accordingly.

Ah, you're correct. (It's too late for me to fix my comment).

I went over the issues with this version of quicksort in the original comment, but I still think it was a good example because most people are familiar with quicksort, and I was trying to address the original posters claim that algorithms in Haskell could only be used in Monads.

Also, quicksort is one of the few I can do from memory.

Ok, here let's step through what this function is doing with a simple example (sort a list that looks like this: [3, 5, 1, 4, 2]:

  qsort [] = []

    qsort (x:xs) = qsort smaller ++ [x] ++ qsort larger

                  where
                  smaller = [a | a <- xs, a <= x]
                  larger = [b | b <- xs, b > x]

Using that example list above ([3, 5, 1, 4, 2]), here's if we did it by hand:

  qsort [3, 5, 1, 4, 2]
   = {applying qsort}
  qsort [1, 2] ++ [3] ++ [5, 4]
   = {applying qsort}
  (qsort [] ++ [1] ++ qsort [2]) ++ [3] ++ (qsort [4] ++ [5] ++ qsort[])
   = {applying qsort}
  ([] ++ [1] ++ [2]) ++ [3] ++ ([4] ++ [5] ++ [])
   = {applying ++}
  [1,2] ++ [3] ++ [4,5]
   = {applying ++}
  [1,2,3,4,5]

Is it that there are no loops that you don't see how it's an algorithm? It is definitely true that some algorithms are very obvious to implement using loops (quicksort is actually one such algorithm), and can in fact be a pain in the neck to implement in some functional languages.

I feel like you're conflating "purity" with algorithms.

Just to clarify, in Haskell there is no issue with algorithms being contained inside functions.

Here's a naive implementation of quicksort:

  qsort [] = []
  qsort (x:xs) = qsort smaller ++ [x] ++ qsort larger
                 where
                 smaller = [a | a <- xs, a <= x]
                 larger = [b | b <- xs, b > x]

People may charitably point out that this is a pretty bad naive implementation, because it doesn't just mutate values in the list up and down, which is inefficient. People uncharitably will take issue with even calling it quicksort, as some people believe that the property of just mutating values in the list is an integral part of it being quicksort. I'm not smart enough to have an opinion about whether or not it's a "true" quicksort.

But the point is that you can absolutely have algorithms in Haskell that are not restricted to only run in a Monad.

Monads exist in Haskell as a way to reason about side-effects. Whether or not an algorithm (or any function) needs to be executed inside a monad is a function of its use of side-effects, it's not fundamental.

I hesitate to recommend my process to other people, because I don't think I'm a very good programmer.

But for the past year or so, I find that I program best by actually writing out my program in a notebook (in my case a quad-ruled lab notebook). I don't even start typing until I have it laid out pretty much in it's entirety on paper.

This sounds ridiculous (and I can imagine it's not practical for all types of programming), but I've found that it's been tremendously helpful in getting me to understand what all the code that I'm writing does.

Most of the code I've written this past year has been in Haskell, so that helps somewhat by not having a lot of syntax to write down, but I'm sure I'd be doing the same thing even if I was writing in Java.

I'm not the OP, but I am also currently taking the FP101X Mooc with Erik Meijer. So far, I'm enjoying it tremendously. I've signed up for several moocs the past couple years, but have never been able to stick with any. This is the furthest I've been able to actually stay with it, which is probably indicative of something.

The lectures are basically laid out 1:1 with Hutton's Programming in Haskell book, so if you're familiar with that book, you're familiar with the way the course is structured. I find the actual experience of doing all the homework questions very helpful, even if so far nothing has been particularly difficult.

RootBSD (https://www.rootbsd.net/services/virtual-servers-vps/) has OpenBSD VPS's (I'm guessing it'll be a little bit before they have 5.6 available).

I think you're grossly underestimating the number of people that an electric car is a complete non-starter for.

It's great that electric cars exist now (and maybe someday in the future I'd even be interesting in buying one once there existed infrastructure that made it feasible), but I think your timeline for the obsolescence of internal combustion engines is laughable.

It doesn't predict my account correctly:

   PROBABILITY FEMALE: 0.997 
   PROBABILITY MALE: 0.569 

By 1998 (when I was there), I don't remember ever seeing anything like that (we used normal Unix 'talk' to communicate with people logged into the Digital Unix servers).

Go Engineers!

Strictly speaking, being on the GSA schedule and being able to offer products/services for sale to the federal government requires that you not sell that product/service anywhere else for less than that GSA price.

This is actually one of the reasons that doing business with the government is less lucrative than the commercial industry (for products and services which are comparable, many are things only sold to the government, so there is no hesitation about pricing them through the roof).

As you can imagine, one of the ways that duplicitous federal contractors get around the idea of having to sell to the government for less than their normal prices is to structure their products/services as different (and therefore not apples to apples comparable).

I still would bet that the price that they charge Goldman Sachs (just as an example, I don't actually know which investment banks are using their product) is higher than what they charge for any individual government client.

Also, I think it's probably worth noting that the maximum addressable customer base for their products for federal agencies is way smaller than the equivalent number of financial customers. There's really only a handful of agencies that have this capability (I'd guess more than a handful, but probably less than a dozen).

James Pearce (Facebook Open Source Person commenting in here) gave a pretty interesting talk about Facebook's internal Open Source process at OSCon: http://www.youtube.com/watch?v=fzL6Zoy_ndk&list=UUP_lo1MFyx5...

I think things like this are a good way to get companies more aligned with contributing to open source, even aside from the mammoth technology companies already involved. I know that for many companies, the decision not to open source parts of their software isn't based on any idealogical disagreement with open source, but because their software projects haven't been designed with open sourcing as a goal, and if they can now take that into account when starting new projects, I'd expect that you might see a lot more open source software. So I think an organization that helps foster that can provide a lot of benefit.

And I'm not even a big open source zealot, but the number of companies who "get" the fact that participating in open source can be useful for lots of reasons (many better than "get the community to do work for free for us"), could certainly stand to be higher.

I can't confirm specific customers, but I've done consulting work for virtually every large energy company (as well as financial and manufacturing), and all of those were fixed-price contracts. (I put together all of those SOW's, so I'm very familiar with how they were structured).

In fact, government contracting is the only case where we've ever used T&M.

For what it's worth, I work in the same space as Thomas.

I haven't, but I just bookmarked it. Thank you.

I'd like to create a market for a "wish-based" currency. (Stop laughing).

As dumb as that sounds, I was struck by the idea of what a currency market would look like in some sci-fi techno-utopia (one where nanites or molecular printers can basically provide all utilitarian needs).

Presumably there would still be a need for currency, even if people didn't have to buy things. If I squint, I can almost see Kickstarter as a general example of a very specific "wish-based" market (one where someone has a thing that they want to exist, and other people collectively fund it).

So what could a system look like that was designed to facilitate wishes. Presumably there's some underlying crypto-currency, and a reputation system (which I'd also like to work on).

Anyway, it's at the bottom of my todo list.

Seeing the favicons while having both sites open in different tabs drives the point home even more.

They're even using a very similar shade of orange.

I do wonder if I was making a logo how hard it would be to search for similar ones though. It seems like it would be harder to google than a name.

Here's my current list, what used to be a 50/50 mix of technology and comedy podcasts has slowly become almost all comedy ones (I increasingly find podcasts to be a bad medium for technology discussions that aren't just "news"):

* U Talkin' U2 To Me? -- A limited series (ostensibly they talk about a different U2 album every week, but even as someone who doesn't like U2 I found this hilarious).

* The Critical Path -- I like Horace's perspective on the mobile market

* WTF -- I subscribe to it, but only download if it's a guest I'm interested in. I also usually skip forward until the interview.

* Postmodem -- Doesn't come out very often, but I find it enjoyable

* The Andy Daly Podcast Project -- Mostly because I think Andy Daly is a national treasure

* Bret Easton Ellis Podcast -- Though easy to dislike, I have been a big fan of his for many years. I like hearing his commentary about the state of the film industry.

* Doug Loves Movies -- Sometimes hit or miss, but way more enjoyable than a live show where guests play movie-related games on stage should be.

* ATP -- I have inordinate affection for John Siracusa, even if I find the format of talking about things "in the news" with little time to have any context constantly frustrating.

* The Talk Show -- Lots of people here don't like Gruber, but I do.

* I Seem Fun -- Probably my favorite podcast currently. Jen Kirkman (a comedian) just records a show a week without any guests. I'm pretty sure the majority of people on this site would hate it though.

* Call Chelsea Peretti -- I should hate this show, because she lets people call in and talks to them (and I hate pretty much all "radio call-in shows"); but she's hilarious.

* By the Way -- Jeff Garlin is an acquired taste, but he got very good guests for this show.

* Back to Work -- I miss an episode here or there, but I still find Merlin and Dan's banter super enjoyable.

* Ronna and Beverly -- Also probably not for people here, but it's two comedians "in character" who interview a guest every week. Mostly I love it because they sound and act like everyone I grew up with's parents.

* Roderick on the Line -- I find John Roderick immensely entertaining.

* Comedy Bang Bang -- Responsible for making me laugh more than any other podcast.

* You Made it Weird -- Pete's interviews are frequently more interesting than funny, but they're frequently both.

* Thrilling Adventure Hour -- I never miss an episode of "Beyond Belief", some of the others I let pile up.

* The Dead Authors Podcast -- Only recently started getting into, but it's pretty funny.

* The Pod F. Tompkast -- I think it's currently on hiatus, but the old ones are great.

* Analyze Phish -- One guy who likes Phish tries to get another guy who doesn't like Phish to like Phish by playing him their songs (and later taking him to Phish shows). I hate Phish, and think this show is wonderful.

* Making it with Riki Lindhome -- I feel like this one might also be on hiatus, but Riki had a lot of good interviews with people about how the "broke in" to Hollywood.

* Who Charted? -- The only way I ever hear current music. Every week they count down the top 5 songs and movies with a guest.

* The Todd Glass Show -- It's a little long, but I love Todd Glass, so I like his podcast very much.

* How Did This Get Made? -- Every episode they pick a terrible movie and go off about it. It's usually really really funny.

* Nerdist Writers Panel -- Ben Blacker and Ben Acker interview a bunch of writers (usually tv writers). I like this one a lot too.