Forgot your password?
typodupeerror
Programming IT Technology

Hans Reiser Interview from Prison 611

Posted by CmdrTaco
from the now-that-paris-is-out dept.
JLester writes "Wired Magazine has an interview this month with Hans Reiser (of the ReiserFS journaling file system for Linux) from prison. It contains more details about the murder case against him. Some of the questions still go unanswered though."
This discussion has been archived. No new comments can be posted.

Hans Reiser Interview from Prison

Comments Filter:
  • Theres a Difference (Score:2, Informative)

    by otacon (445694) on Wednesday June 27, 2007 @09:09AM (#19661891)
    Prison is where you go for periods generally over a year, after you have been sentenced. Jail is where you go when you are awaiting trial, or for minor offences, usually under a year.
  • by Anonymous Coward on Wednesday June 27, 2007 @09:11AM (#19661905)
    he claims to be a serial killer, but hasnt proved it. He's as likely to be lying as not.
  • by Colin Smith (2679) on Wednesday June 27, 2007 @09:32AM (#19662095)
    There's a scanner which can monitor brain activity realtime, depending on which areas light up, police can tell if you're lying or not. They don't even have to ask any questions, simply present evidence to you and watch what your brain does.

    e.g.
    http://www.wired.com/wired/archive/14.01/lying.htm l [wired.com]

    As a geek who's been falsely accused, I'm sure he'd be happy to submit to such a scan. Additional evidence for his defence lawyer.

     
  • by Anonymous Coward on Wednesday June 27, 2007 @10:22AM (#19662689)
    problem here is that my gf was one of her best friends. neither she, nor any of her other friends, have heard from her. I (well, really my gf, who knew her) don't think that was in character from this woman. If she was back in russia, presumably her friends would know.
  • by Anonymous Coward on Wednesday June 27, 2007 @10:37AM (#19662887)
    open last dir/patch at ftp://ftp.namesys.com/pub/reiser4-for-2.6 [namesys.com]
    file znode.c, item 5:

    diff -puN /dev/null fs/reiser4/znode.c
    --- /dev/null Thu Apr 11 07:25:15 2002
    +++ 25-akpm/fs/reiser4/znode.c Wed Mar 30 14:55:08 2005
    @@ -0,0 +1,1141 @@ /* Copyright 2001, 2002, 2003 by Hans Reiser, licensing governed by
    * reiser4/README */ /* Znode manipulation functions. */ /* Znode is the in-memory header for a tree node. It is stored
    separately from the node itself so that it does not get written to
    disk. In this respect znode is like buffer head or page head. We
    also use znodes for additional reiser4 specific purposes:

    . they are organized into tree structure which is a part of whole
    reiser4 tree.
    . they are used to implement node grained locking
    . they are used to keep additional state associated with a
    node
    . they contain links to lists used by the transaction manager

    Znode is attached to some variable "block number" which is instance of
    fs/reiser4/tree.h:reiser4_block_nr type. Znode can exist without
    appropriate node being actually loaded in memory. Existence of znode itself
    is regulated by reference count (->x_count) in it. Each time thread
    acquires reference to znode through call to zget(), ->x_count is
    incremented and decremented on call to zput(). Data (content of node) are
    brought in memory through call to zload(), which also increments ->d_count
    reference counter. zload can block waiting on IO. Call to zrelse()
    decreases this counter. Also, ->c_count keeps track of number of child
    znodes and prevents parent znode from being recycled until all of its
    children are. ->c_count is decremented whenever child goes out of existence
    (being actually recycled in zdestroy()) which can be some time after last
    reference to this child dies if we support some form of LRU cache for
    znodes.

    */ /* EVERY ZNODE'S STORY

    1. His infancy.

    Once upon a time, the znode was born deep inside of zget() by call to
    zalloc(). At the return from zget() znode had:

    . reference counter (x_count) of 1
    . assigned block number, marked as used in bitmap
    . pointer to parent znode. Root znode parent pointer points
    to its father: "fake" znode. This, in turn, has NULL parent pointer.
    . hash table linkage
    . no data loaded from disk
    . no node plugin
    . no sibling linkage

    2. His childhood

    Each node is either brought into memory as a result of tree traversal, or
    created afresh, creation of the root being a special case of the latter. In
    either case it's inserted into sibling list. This will typically require
    some ancillary tree traversing, but ultimately both sibling pointers will
    exist and JNODE_LEFT_CONNECTED and JNODE_RIGHT_CONNECTED will be true in
    zjnode.state.
  • by Volanin (935080) on Wednesday June 27, 2007 @10:39AM (#19662917)
    The last paragraph of the article references a piece of comentary in the Reiser4 code.
    For the geeks out there, here is it, edited to pass slashdot's "few-characters-per-line" filter:

    /* EVERY ZNODE'S STORY

    1. His infancy.

    Once upon a time, the znode was born deep inside of zget() by call to zalloc(). At the return from zget() znode had:

    . reference counter (x_count) of 1
    . assigned block number, marked as used in bitmap
    . pointer to parent znode. Root znode parent pointer points to its father: "fake" znode. This, in turn, has NULL parent pointer.
    . hash table linkage
    . no data loaded from disk
    . no node plugin
    . no sibling linkage

    2. His childhood

    Each node is either brought into memory as a result of tree traversal, or created afresh, creation of the root being a special case of the latter. In either case it's inserted into sibling list. This will typically require some ancillary tree traversing, but ultimately both sibling pointers will exist and JNODE_LEFT_CONNECTED and JNODE_RIGHT_CONNECTED will be true in zjnode.state.

    3. His youth.

    If znode is bound to already existing node in a tree, its content is read from the disk by call to zload(). At that moment, JNODE_LOADED bit is set in zjnode.state and zdata() function starts to return non null for this znode. zload() further calls zparse() that determines which node layout this node is rendered in, and sets ->nplug on success.

    If znode is for new node just created, memory for it is allocated and zinit_new() function is called to initialise data, according to selected node layout.

    4. His maturity.

    After this point, znode lingers in memory for some time. Threads can acquire references to znode either by blocknr through call to zget(), or by following a pointer to unallocated znode from internal item. Each time reference to znode is obtained, x_count is increased. Thread can read/write lock znode. Znode data can be loaded through calls to zload(), d_count will be increased appropriately. If all references to znode are released (x_count drops to 0), znode is not recycled immediately. Rather, it is still cached in the hash table in the hope that it will be accessed shortly.

    There are two ways in which znode existence can be terminated:

    . sudden death: node bound to this znode is removed from the tree
    . overpopulation: znode is purged out of memory due to memory pressure

    5. His death.

    Death is complex process.

    When we irrevocably commit ourselves to decision to remove node from the tree, JNODE_HEARD_BANSHEE bit is set in zjnode.state of corresponding znode. This is done either in ->kill_hook() of internal item or in kill_root() function when tree root is removed.

    At this moment znode still has:

    . locks held on it, necessary write ones
    . references to it
    . disk block assigned to it
    . data loaded from the disk
    . pending requests for lock

    But once JNODE_HEARD_BANSHEE bit set, last call to unlock_znode() does node deletion. Node deletion includes two phases. First all ways to get references to that znode (sibling and parent links and hash lookup using block number stored in parent node) should be deleted -- it is done through sibling_list_remove(), also we assume that nobody uses down link from parent node due to its nonexistence or proper parent node locking and nobody uses parent pointers from children due to absence of them. Second we invalidate all pending lock requests which still are on znode's lock request queue, this is done by invalidate_lock(). Another JNODE_IS_DYING znode status bit is used to invalidate pending lock requests. Once it set all requesters are forced to return -EINVAL from longterm_lock_znode(). F

  • by GodfatherofSoul (174979) on Wednesday June 27, 2007 @10:48AM (#19663013)

    "I'm not saying he should have killed her, but I understand..."

    Anytime you can't explain things like missing vehicles and scrubbed interiors, you got problems. I was expecting a police conspiracy after reading the comments, but there are a lot of arrows pointing at him. And, what's with his "friend" Sturgeon? It's almost as if he doesn't get that banging your buddy's wife might cause some strain on your relationship!

    No sympathy for the guy, though. A hot Russian mail order bride doctor and you don't suspect the package might be a little too good to be true?

  • by novus ordo (843883) on Wednesday June 27, 2007 @11:07AM (#19663315) Journal
    I found the piece was terribly distraught especially this:

    While he launches into the intricacies of database science, I'm thinking, "Where is the front passenger seat of your car?" He has never explained this. It seems a fundamental hole in his defense. But he won't stop talking. When I try to interrupt, he insists I let him finish. It's as if the file system holds all the answers.

    So I take the hint, and that night, in my office, I start scouring the 80,496 lines of the Reiser4 source code. Eventually I stumble across a passage that starts at line 78,077. It's not part of the program itself it's an annotation, a piece of non-executable text in plain English. It's there for the benefit of someone who has chosen to read this far into the code. The passage explains how memory structures are born, grow, and eventually die. It concludes: "Death is a complex process."

    So I guess this is a confession now? I'm sorry but that's just deceiving and wrong. He calls a patch against the kernel tree a "program" and all the pluses he didn't remove before the code reaffirm this suspicion that he doesn't even know what proper code looks like. He makes it sound as if this comment describing how a specific file structure of the file system works as some sort of "secret confession" hidden there for the unscrupulous researcher. Joshua Davis, please turn in your geek badge!

    With someone that calls himself a geek to come with such a preposterous conclusion leaves me little room for hope that any sort of truth of this case from either side will come out or that any real justice will be done. It speaks volumes of the "blindness of justice" and how our prisons end up being jammed with people placed on death row with DNA evidence later exonerating them and having no recourse to repair their life or credibility. So truly, Death really is a Complex Process.


    Here is the actual passage he was talking about:

    +/* EVERY ZNODE'S STORY
    +
    + 1. His infancy.
    +
    + Once upon a time, the znode was born deep inside of zget() by call to
    + zalloc(). At the return from zget() znode had:
    +
    + . reference counter (x_count) of 1
    + . assigned block number, marked as used in bitmap
    + . pointer to parent znode. Root znode parent pointer points
    + to its father: "fake" znode. This, in turn, has NULL parent pointer.
    + . hash table linkage
    + . no data loaded from disk
    + . no node plugin
    + . no sibling linkage
    +
    + 2. His childhood
    +
    + Each node is either brought into memory as a result of tree traversal, or
    + created afresh, creation of the root being a special case of the latter. In
    + either case it's inserted into sibling list. This will typically require
    + some ancillary tree traversing, but ultimately both sibling pointers will
    + exist and JNODE_LEFT_CONNECTED and JNODE_RIGHT_CONNECTED will be true in
    + zjnode.state.
    +
    + 3. His youth.
    +
    + If znode is bound to already existing node in a tree, its content is read
    + from the disk by call to zload(). At that moment, JNODE_LOADED bit is set
    + in zjnode.state and zdata() function starts to return non null for this
    + znode. zload() further calls zparse() that determines which node layout
    + this node is rendered in, and sets ->nplug on success.
    +
    + If znode is for new node just created, memory for it is allocated and
    + zinit_new() function is called to initialise data, according to selected
    + node layout.
    +
    + 4. His maturity.
    +
    + After this point, znode lingers in memory for some time. Threads can
    + acquire references to znode either by blocknr through call to zget(), or by
    + following a pointer to unallocated znode from internal item. Each time
    + reference to znode is obtained, x_count is increased. Thread can read/write
    + lock znode. Znode data can be loaded through calls to zload(), d_count will
    + be increased appropriately. If all references to znode are released
    + (x_count drops to 0), znode is n

  • Did you read the article? First the CRX goes missing for a long time. Then...

    On September 13, the Oakland police get a search warrant to scour the Reiser household. They find a drop of blood on a support post in the entry. Oakland's crime lab identifies the sample as a mix of Nina's and Reiser's, though it can't determine how old the blood is. Five days later, the police follow Reiser to the CRX, which is parked on a quiet street in nearby Berkeley. He moves it to a secluded, wooded area of Oakland and dashes uphill toward his mother's house 3 miles away.

    Police search the CRX and find that the front passenger seat has recently been removed. The floor is soaked, as if it had been washed. There are heavy-duty garbage bags, cloth towels, masking tape, and two books: Masterpieces of Murder and Homicide. Police also find another drop of blood and match it to Nina.

    Not that Sturgeon doesn't make this story even more bizarre, but... it can also be said that you learn a lot about a person by the friends they hang out with.

  • by snarlydwarf (532865) on Wednesday June 27, 2007 @11:42AM (#19663853) Homepage
    Because it wasn't $96000. It was $96.

  • by apodyopsis (1048476) on Wednesday June 27, 2007 @11:46AM (#19663905)
    sigh.

    I'm not arguing against innocent until proven guilty, thats just as important in the UK as it is in the US.

    what I *am* saying is that there are a number of huge unknowns here and some damn compelling circumstantial evidence. Amongst others ...
    1. the missing car seat
    2. the freshly washed car
    3. the fact of the passport and wads of cash he had on him
    4. the book on murder
    5. the missing wife
    6. the motive
    7. thoroughly strange behavior (driving around, leaving the car)

    ..therefore the onus is on him to provide an explanation or some form of defense. if he does not then can you see any Jury acquitting him? I'm not saying that the police should have the power to presume guilt - of course not - I'm saying that in this case him staying silent is really not a sensible course of action.

    I'll admit I phrased badly though. :-(
  • by Anonymous Coward on Wednesday June 27, 2007 @11:46AM (#19663925)
    Unless she has the missing money from the company.
    If you were a fugitive attempting to be dead, would you let your best friends know?
  • by crankyspice (63953) on Wednesday June 27, 2007 @11:59AM (#19664111)

    Care to back that up?

    Sure. Read the definitions of Black's Law Dictionary http://west.thomson.com/store/product.aspx?product _id=40231642&promcode=520963 [thomson.com], the definitive source of such definitions in American jurisprudence. (Hint: Reiser is held in an American facility facing American charges in an American court. Thus, American definitions words apply.)

    In England (where I expect you sourced gaol from), jails == prisons; the same facilities are used for both unconvicted inmates "on remand" and those who have been duly convicted and are serving out their sentences.

    In America, jails (except for Texas, which has "state jails" for sentences up to 2 years, and the federal system, which often houses in BOP "prison" facilities pre-trial) are used for pre-trial detention and for sentences up to a year. Prisons are much larger facilities exclusively for sentenced inmates serving a year or more.

  • Re:Mod Parent Up (Score:3, Informative)

    by crolix (833807) on Wednesday June 27, 2007 @12:50PM (#19664761) Homepage
    There is nothing strange about the terminology Hans used. Speaking of data structures or objects as 'live' entities with a 'life cycle' is normal in computer science. Objects are created ('born'), they live and then they are eventually destroyed. That last part is sometimes referred to as getting 'killed', such as by receiving a 'kill signal'. Because some objects are older than others, terms such as 'generations of objects' are also used.
  • Re:obHumor (Score:3, Informative)

    by gammoth (172021) on Wednesday June 27, 2007 @08:09PM (#19670143)
    The code fragments were short, sparse, and deliciously ironic.

The unfacts, did we have them, are too imprecisely few to warrant our certitude.

Working...