Announcing coverity-submit

My regular readers will know that (a) I’ve recently been pounding bugs out of GPSD with Coverity, and (b) I hate doing stupid clicky-dances on websites when I think I ought to be able to shove them a programmatically-generated job card that tells them what to do.

So, here’s a side-effect of my recent work with Coverity: coverity-submit. Set up a config file once, and afterwards just run coverity-submit in your project directory and stand back. Supports multiple projects. Because, manularity is evil.

Here’s the HTML documentation.

26 thoughts on “Announcing coverity-submit

  1. “manularity is evil.”

    I repeatedly have to point out to people that the entire purpose of computers is to automate repetitive tasks. Once I do something for the second time, I’m thinking about how I can automate it, because if I have to do it for a third time, I’m pretty sure there will be a fourth, fourteenth, fortieth….

  2. Eric -

    A couple of tiny nits to pick: in the HTML doc, under the section “OPERATION”, shouldn’t item 3 read “the project’s local postbuild command”? Also, the webserver at catb.org is still confused about the character encoding it’s reporting as sending – viewing with Firefox 10.0.4 under CentOS 6.2, it’s trying to be rendered as ISO-8859-1 instead of UTF8.

  3. “I repeatedly have to point out to people that the entire purpose of computers is to automate repetitive tasks.”

    From a users point of view, off-loading the task of remembering things to the computer is at least as important. This is a major difference between users and hackers. Hackers often don’t realize just how incredibly good their memories are, compared to the typical user (or, how horribly bad the typical user’s memory is, compared to a hacker’s).[1] They don’t appreciate how important it is to users that the computer remember things for the user, rather than forcing the user to remember lots of arbitrary little commands himself.

    Manularity is evil for users, too, but that evil gets weighed against the fear of producing a sorcerer’s apprentice mode or other deadly bug when automating a task. That fear is much greater for users than hackers, and as a result users will endure the evils of manularity to a much greater extent than hackers do. (When a bunch of files need to be renamed, a hacker will just issue a command on the command line. For him, it’s trivial. But if I, as a non-hacker, want to duplicate this, then I have to stop and think, and try to remember the appropriate command and wildcard syntax, and look up what I don’t remember, and look up what I think I remember to make sure I didn’t get it wrong, and run a test case or two to make sure I haven’t made a horrible mistake. No wonder I so often resort to manularity when renaming files.)

    Or another way of looking at it might be as a trade-off between manularity and “mental manularity” – having to do lots of boring repetitive tasks by hand vs having to remember lots of fiddly little commands in wetware. Hackers are less burdened by mental manularity, so they emphasize reducing the ordinary kind. Users suffer greatly when faced with mental manularity, and so will often choose to endure the ordinary kind instead.

    [1] See esr’s own writing on the personality of J Random Hacker. E.g. “During the production of the first book version of this document, for example, I learned most of the rather complex typesetting language TeX over about four working days, mainly by inhaling Knuth’s 477-page manual. My editor’s flabbergasted reaction to this genuinely surprised me, because years of associating with hackers have conditioned me to consider such performances routine and to be expected.”

  4. “This is a major difference between users and hackers. Hackers often don’t realize just how incredibly good their memories are, compared to the typical user (or, how horribly bad the typical user’s memory is, compared to a hacker’s).”

    Shit, THAT’S what the problem is. ;_;

    Seriously, I’ve been in the same job for six years now, and I *still* have to constantly look up syntax that I use often but just can’t recall when I want it. I guess I’m just not a born hacker. (I have, however, greatly developed my ability to research and to organize things for easy lookup as a result. Still not as handy as a good memory, though.)

  5. >“manularity is evil.”

    I agree with Deep Lurker. Also the all too common problem of making the wrong response automatic is even worse than manularity.

  6. @Deep Lurker:

    From a users point of view, off-loading the task of remembering things to the computer is at least as important. This is a major difference between users and hackers. Hackers often don’t realize just how incredibly good their memories are, compared to the typical user (or, how horribly bad the typical user’s memory is, compared to a hacker’s).[1] They don’t appreciate how important it is to users that the computer remember things for the user, rather than forcing the user to remember lots of arbitrary little commands himself.

    Show me the hacker who doesn’t have man and manpages installed on his computer, then you just might have a point — but he’d also have to not have a Web browser, either.

    While I routinely read and upload the contents of manuals into my brain, even I can’t remember every single little detail of everything I read. Not to say that I don’t retain a good portion of it, but I, too, look up things from time to time. My intranet server serves up the Python Language Reference and Python Library Reference, and I regularly refer to manpages to look up some obscure switch or command I can’t remember off of the top of my pointy little head. Example — Quick: what is the LVM2 command to merge two volume groups and automatically perform a backup? No fair looking it up!

    If I don’t have to look up some syntax for a command or a function or the methods in a class, it’s just because it’s something I use all the time, like the split and join methods for Python strings or ‘for f in $(mount | grep ‘filer:/vol’ | cut -d ‘ ‘ -f1); do umount $f; done’ in bash to unmount all NFS volumes on a particular NetApp filer. Other things I don’t use as often — well, I always know where to find the information.

    So,no I don’t think the difference between a hacker and a user has anything to do with an ability to memorize, it’s just a different mindset — a posture of thinking, if you will. Not to say that memorization isn’t a useful tool, but it’s not the difference and it’s not even a particularly crucial one.

  7. @Morgan Greywolf: Man page? Luxury! My memory isn’t good enough to use the man pages without consulting a reference work, first.

    But bad Monty Python references aside (and no pun intended), what I’m claiming is a difference of degree, not that hacker memories are perfect. Yes, there is a point where you, too, have to stop and look it up. But the number of things you can use routinely, without having to look it up, is astonishingly large from a users point of view. It’s that difference in the size of the toolkit at the tip of the brain that gives the typical hacker that “different posture of thinking” from the typical user.

  8. > difference of degree [...] It’s that difference in the size of the toolkit at the tip of the brain that gives the typical hacker that “different posture of thinking” from the typical user.

    That would mean that the “different posture of thinking” is only a difference of degree, which I don’t think is true.

    Compare
    a- having to, on a regular basis, click through a number of actions to get a job done, and thinking : “boring, but it’s part of my job”;

    b- having to, on a regular basis, click through a number of actions to get a job done, and thinking, by the 2nd time you’re doing it : “I need to figure out a way to automate this’

    It’s not a difference of degree, it’s a different way of approaching a problem.

    Also, I don’t think the size of the toolkit in your head really matters (when it comes to this tendency to automate things) ; at least half of the scripts I use I’ve written so that I don’t have to remember some obscure sequence of options and params. The other half I’ve written so that i don’t have to remember all the steps in a procedure (and why make checklists if you can have a script execute these steps, in the correct order, automatically ?)

  9. There’s different sorts of laziness involved in a and b above. Some people click their way through an involved procedure, realize that they could automate it, but also realize that writing and testing the script would be more work than the clicking, so they don’t do it. Others like to respond to the challenge, and get a kick out of the result. To each his own….

  10. Shouldn’t it be “manuality”?

    “-ity” is nearly always added to an adjective to denote the condition of that adjective applying: humanity, possibility, masculinity, legality, insanity, solubility, visibility.

    “Manularity” sounds like it was cognated (?) from “Granularity” – but “Granularity” derives from “Granular” (composed of “granules”).

    “Manularity” would derive from “Manular” (composed of “manules”).

  11. >Shouldn’t it be “manuality”?

    I inherited “manularity”, I didn’t invent it.

    >“Manularity” would derive from “Manular” (composed of “manules”).

    Congratulations. By long-established hacker custom, having pointed this out makes you the inventor of the following new jargon term:

    manule, n. – the unit of useless work

  12. “manule, n. – the unit of useless work”

    …and if you write a script to eliminate it, you are ‘weeding the manule”.

    …crickets…

  13. Interested to know what you think of the license model of a big enterprise application like coverity?

  14. >Interested to know what you think of the license model of a big enterprise application like coverity?

    Can’t evaluate it until I know what it is. Pointer?

  15. @esr
    > Pointer

    Don’t have one, never used the software. I wasn’t specifically referring to the terms, but evidently they are a big enterprise shop making money selling closed source software (AFAIK the source isn’t available, right?) They could alternatively offer the tool for free and make money on the secondary channels, but apparently don’t do so.

    I might have misjudged them though. But since you need to hack together some web submission thingie, I’m guessing that the executable can’t reside in a place where it gets auto run at the end of your build process locally.

    Just wondering your perspective on this. Are you dancing with the devil?

  16. >Just wondering your perspective on this. Are you dancing with the devil?

    I’m not Richard Stallman. I don’t think proprietary software is intrinsically evil, so dancing with the devil is not an appropriate simile.

    I do think closed-source is (a) usually inferior engineering, and (b) exposes its customers to dangerous lock-in risks. But Coverity is kind of a best case – once you’ve seen its results they’re easy to verify, and my projects don’t actually depend on it in any critical way.

  17. @esr
    > I do think closed-source is (a) usually inferior engineering, and (b) exposes its customers to dangerous lock-in risks.

    I’ll grant you point b), having suffered that myself (fwiw, I hate ebooks.) However, is your view on point a) based on your predictions of what will happen, or based on your analysis of what has happened? After all there is lots of crappy open source software out there (and of course lots of crappy proprietary software too.)

    Not claiming it isn’t true, just curious as to what evidence there is either way.

  18. >Not claiming it isn’t true, just curious as to what evidence there is either way

    Probably the hardest evidence is the fuzz-testing papers from the University of Wisconsin. Representative quote from the abstract of the 1995 one: “The reliability of the basic utilities from GNU and Linux were noticeably better than those of the commercial systems.” But the public bug history of, for example, Mozilla/Firefox vs. IE – or Apache vs. IIS – is also quote telling.

    This was already old news 15 years ago. The way I got enough traction in the business and tech press to get people to listen to my more general anti-closed-source arguments about lock-in and strategic business risk was by banging the drum about differential reliability rates. It was a pretty much irrefutable argument then, with solid numbers to back it up, and still is.

  19. FYI: Deep Lurker’s early comment here is nearly exactly explanatory of the reaction of civilians to a 48 channel sound board.

  20. One other general comment: I think hackers tend to have larger working sets of things like command line switches and language syntax, but that’s not the overriding descriptor: it’s the size — and breadth — of the in-memory indexes, I think, that really tags hackers.

  21. Baylink,

    I’m sure the knowledge depth of musician hackers, like Gershwin and Armstrong is similar.

    Yours,
    Tom

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">