Hans Reiser Interview from Prison

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."

Theres a Difference

[otacon]

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.

Re:So what about Sean Sturgeon

[Anonymous Coward]

he claims to be a serial killer, but hasnt proved it. He's as likely to be lying as not.

It's possible to tell when someone's lying

[Colin Smith]

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.

 

Re:my theory after reading TFA

[Anonymous Coward]

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.

Re:Wow that's bizzarre

[Anonymous Coward]

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.

Re:This story is going from 'weird' to 'surreal'

[Volanin]

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

To paraphrase Chris Rock...

[GodfatherofSoul]

"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?

Sensationalist nonsense

[novus ordo]

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

Re:So what about Sean Sturgeon

[Reality Master 101]

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.

Re:my theory after reading TFA

[snarlydwarf]

Because it wasn't $96000. It was $96.

Re:I tend to ... rebuttal from original poster :-)

[apodyopsis]

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. :-(

Re:my theory after reading TFA

[Anonymous Coward]

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?

Re:Theres a Difference

[crankyspice]

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

[crolix]

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

[gammoth]

The code fragments were short, sparse, and deliciously ironic.