The Linux Kernel SABOTEURS.

[Jade]

The Linux Kernel Saboteurs.

From http://linuxhelp.150m.com/
and http://linux.50webs.org

Although the Linux kernel saboteurs (a number of so called Linux kernel "developers") have sabotaged many areas of Linux, I will concentrate on their efforts in sabotaging Reiser4.

As some will have noticed, Reiser4 no longer works as it used to. The recent patches of Andrew Morton, and Riffard Laurent, cause corruption problems (when they work at all). Morton's patches, also reduced Reiser4's functionality, removing, for example, the cryptocompress plugin. Riffard's patches include the cryptocompress plugin, which seems to work, but the patch causes corruption for plain Reiser4.

You see, the Reiser4 saboteurs arranged that plain Reiser4 will not work properly. However, they forgot to sabotage the more complex case of transparent compression, so we have the weird situation where the more complex case works fine, while the kernel "developers" "struggle" to get the simple case to work like it used to.

The parts of Reiser4 they have not touched, still work, but where they have coded, Reiser4 no longer works.

The fact that Reiser4 worked well, before Hans Reiser's arrest and imprisonment (on what appears to be trumped-up charges) and now doesn't, means that it should be easy to spot the sabotage.

After digging around in the source code, the evidence of deliberate sabotage is very clear.

I present some of the evidence (found by comparing Riffard's patch with older Namesys patches) below.

Update: Namesys has released 2.6.20 and 2.6.21 kernel patches. This has enabled one to completely isolate the differences between Namesys' 2.6.20 patch and Riffard's. The diff file is very small and can be found here (../installs/diff-namesys-riffard-2.6.20.txt). The early sabotage is concentrated in this small file.

One act of sabotage, is found in reiser4/page_cache.c:

int reiser4_page_io(struct page *page, jnode *node, int rw, gfp_t gfp)
{
struct bio *bio;
int result;

assert("nikita-2094", page != NULL);
assert("nikita-2226", PageLocked(page));
assert("nikita-2634", node != NULL);
assert("nikita-2893", rw == READ || rw == WRITE);

if (rw) {
if (unlikely(page->mapping->host->i_sb->s_flags & MS_RDONLY)) {
unlock_page(page);
return 0;
}
}

bio = page_bio(page, node, rw, gfp);
if (!IS_ERR(bio)) {
if (rw == WRITE) {
SetPageWriteback(page);
Changed to set_page_writeback(page);
unlock_page(page);
}
reiser4_submit_bio(rw, bio);
result = 0;
} else {
unlock_page(page);
result = PTR_ERR(bio);
}

return result;
}

where SetPageWriteback has been changed to set_page_writeback.

This change is hard to spot with SetPageWriteback and set_page_writeback, being very similar in name. This change is almost guaranteed to cause problems, as set_page_writeback is called without calling end_page_writeback(). According to Documentation/filesystems/Locking, this will leave the page itself marked clean but it will be tagged as dirty in the radix tree. This incoherency can lead to all sorts of hard-to-debug problems in the filesystem like having dirty inodes at umount and losing written data. Just as the saboteurs desire, and what we see happening.

The definition of SetPageWriteback is found in linux-2.6.20/include/linux/page-flags.h,

#define SetPageWriteback(page) \
do { \
if (!test_and_set_bit(PG_writeback, \
&(page)->flags)) \
inc_zone_page_state(page, NR_WRITEBACK); \
} while (0)
as is the definition of set_page_writeback,
static inline void set_page_writeback(struct page *page)
{
test_set_page_writeback(page);
}

where test_set_page_writeback (from linux-2.6.20/mm/page-writeback.c) is:

int test_set_page_writeback(struct page *page)
{
struct address_space *mapping = page_mapping(page);
int ret;

if (mapping) {
unsigned long flags;

write_lock_irqsave(&mapping->tree_lock, flags);
ret = TestSetPageWriteback(page);
if (!ret)
radix_tree_tag_set(&mapping->page_tree,
page_index(page),
PAGECACHE_TAG_WRITEBACK);
if (!PageDirty(page))
radix_tree_tag_clear(&mapping->page_tree,
page_index(page),
PAGECACHE_TAG_DIRTY);
write_unlock_irqrestore(&mapping->tree_lock, flags);
} else {
ret = TestSetPageWriteback(page);
}
return ret;

}
EXPORT_SYMBOL(test_set_page_writeback);

From the above definitions, it is clear that swapping set_page_writeback for SetPageWriteback was not an accidental mistake (the code is completely different).

The patch, move-page-writeback-acounting-out-of-macros.patch, is Andrew Morton's attempt to completely cover his tracks. He claims it is "inconsistent" and "awkward" to have the three page-writeback accounting macros in include/linux/page-flags.h (together with all the other page macros) and that it would be better somehow, if they were moved to mm/page-writeback.c. However, not a single one of these definitions is actually transfered to mm/page-writeback.c. Two of them have their definition split between the two named files and the third, SetPageWriteback, is "accidentally" lost. It just disappears.

In this way, Andrew Morton completely eliminates all reference to SetPageWriteback in the (2.6.21) mm-kernel.

The patch move-page-writeback-acounting-out-of-macros.patch is presented here:
From: Andrew Morton

page-writeback accounting is presently performed in the page-flags macros.
This is inconsistent and makes it awkward to implement per-backing_dev
under-writeback page accounting.

So move this accounting down to the callsite(s).

Signed-off-by: Andrew Morton
---

include/linux/page-flags.h | 38 +++++++----------------------------
mm/page-writeback.c | 4 +++
2 files changed, 12 insertions(+), 30 deletions(-)

diff -puN include/linux/page-flags.h~move-page-writeback-acounting-out-of-macros include/linux/page-flags.h
--- a/include/linux/page-flags.h~move-page-writeback-acounting-out-of-macros
+++ a/include/linux/page-flags.h
@@ -184,37 +184,15 @@ static inline void SetPageUptodate(struc
#define __SetPagePrivate(page) __set_bit(PG_private, &(page)->flags)
#define __ClearPagePrivate(page) __clear_bit(PG_private, &(page)->flags)

+/*
+ * Only test-and-set exist for PG_writeback. The unconditional operators are
+ * risky: they bypass page accounting.
+ */
#define PageWriteback(page) test_bit(PG_writeback, &(page)->flags)
-#define SetPageWriteback(page) \
- do { \
- if (!test_and_set_bit(PG_writeback, \
- &(page)->flags)) \
- inc_zone_page_state(page, NR_WRITEBACK); \
- } while (0)
-#define TestSetPageWriteback(page) \
- ({ \
- int ret; \
- ret = test_and_set_bit(PG_writeback, \
- &(page)->flags); \
- if (!ret) \
- inc_zone_page_state(page, NR_WRITEBACK); \
- ret; \
- })
-#define ClearPageWriteback(page) \
- do { \
- if (test_and_clear_bit(PG_writeback, \
- &(page)->flags)) \
- dec_zone_page_state(page, NR_WRITEBACK); \
- } while (0)
-#define TestClearPageWriteback(page) \
- ({ \
- int ret; \
- ret = test_and_clear_bit(PG_writeback, \
- &(page)->flags); \
- if (ret) \
- dec_zone_page_state(page, NR_WRITEBACK); \
- ret; \
- })
+#define TestSetPageWriteback(page) test_and_set_bit(PG_writeback, \
+ &(page)->flags)
+#define TestClearPageWriteback(page) test_and_clear_bit(PG_writeback, \
+ &(page)->flags)

#define PageBuddy(page) test_bit(PG_buddy, &(page)->flags)
#define __SetPageBuddy(page) __set_bit(PG_buddy, &(page)->flags)
diff -puN mm/page-writeback.c~move-page-writeback-acounting-out-of-macros mm/page-writeback.c
--- a/mm/page-writeback.c~move-page-writeback-acounting-out-of-macros
+++ a/mm/page-writeback.c
@@ -987,6 +987,8 @@ int test_clear_page_writeback(struct pag
} else {
ret = TestClearPageWriteback(page);
}
+ if (ret)
+ dec_zone_page_state(page, NR_WRITEBACK);
return ret;
}

@@ -1012,6 +1014,8 @@ int test_set_page_writeback(struct page
} else {
ret = TestSetPageWriteback(page);
}
+ if (!ret)
+ inc_zone_page_state(page, NR_WRITEBACK);
return ret;

}
_

Another, hard to spot act of sabotage, occurs in reiser4/jnode.c, where the order of 2 lines has been swapped. This:

void jrelse_tail(jnode * node /* jnode to release references to */ )
{
assert("nikita-489", atomic_read(&node->d_count) > 0);
atomic_dec(&node->d_count);
/* release reference acquired in jload_gfp() or jinit_new() */
jput(node);
if (jnode_is_unformatted(node) || jnode_is_znode(node))
LOCK_CNT_DEC(d_refs);
}

[Jade]

Another, hard to spot act of sabotage, occurs in reiser4/jnode.c, where the order of 2 lines has been swapped. This:

void jrelse_tail(jnode * node /* jnode to release references to */ )
{
assert("nikita-489", atomic_read(&node->d_count) > 0);
atomic_dec(&node->d_count);
/* release reference acquired in jload_gfp() or jinit_new() */
jput(node);
if (jnode_is_unformatted(node) || jnode_is_znode(node))
LOCK_CNT_DEC(d_refs);
}

has been changed to this:

void jrelse_tail(jnode * node /* jnode to release references to */ )
{
assert("nikita-489", atomic_read(&node->d_count) > 0);
atomic_dec(&node->d_count);
if (jnode_is_unformatted(node) || jnode_is_znode(node))
LOCK_CNT_DEC(d_refs);
/* release reference acquired in jload_gfp() or jinit_new() */
jput(node);
}

This is guaranteed to cause problems. If the original worked, then the change will not (and vica versa).

Morton's patches contains the first, but not the second, sabotaged section of code.

[Jade]

Thanks for the links, you should probably also put a link to the original this is based on (the Wired Blog).

Remember that in the country this takes place (the murder trial), it doesn't matter what you think. It doesn't even matter what the jury itself thinks of the person's character or "acting strangely" (atleast it's not supposed to) - what matters is what you can prove.

Guilt must be proven, a person is innocent until proven guilty in the USA. There has been a lot of conjecture and circumstantial evidence, which does not mean proof at all.

As to the "kernel saboteurs", uhhmmmm. I have been a user of reiserfs3 for years and never noticed all these "issues" that people all of a sudden came up with (after Reiser was arrested). In fact I never was affected by any sort of corruption or whatnot - in 6+ years of using the filesystem (since 2.4.0)!

ResierFS v4 is something I've wanted to try for a while, but it seems as if everytime I've gone to just do it that I've been "blocked" by one thing or another (boot CD lacks support, kernel patch is broken, developer kernel has bugs, etc.).

The problem was not that I couldn't just use a NameSys patch on my own kernel (I used my own kernel anyway), and do a double install to get the main install up on v4, the issue was that the last time I looked the last patch I could find to be easily hacked to use a recent kernel (one I wanted) did not support compression. That is the sole reason for me wanting to migrate from v3 to v4, is the realtime compression (not for space increase, but for performance increase).

What I can say from my experience personally is this:

there were several reiserfs v4 patches in a certain kernel developer's tree that were not immediately apparant to be broken... but they were/are. An unnecessary kludge was introduced for no reason what-so-ever, which was the cause of the corruption. This developer is a very "big-name" person, and I will not tell you of whom I speak (this is not about flames, and I don't know why he did it i.e. a mistake or misunderstanding or what). Needless to say however, a lot of people use his patches for bleeding-edge features, mainly because he is supposed to be "dependable" and "official". So of course, eventually it was noticed - this few lines of code that was unecessarily introduced causing the coruption, and when asked he gave the most unbelievable answer. Then he proceeded to do a rewrite and what appeared as "cover his tracks".

Anyhow that is what happened. Make of it what you will, but it surely was NOT bitrot or anything so simple...

If you want to look at conspiracy theories, look at who the biggest sponsor was originally. There's your answer right there, and probably what they'd do to "get rid" of the filesystem (have the inventor locked away)

BTW I've never understood the obsession about ext2 and ext3. ext2 was the worst filesystem I've used since the old days of UFS, and the only filesystems I've personally had explode were both ext2/ext3.

I think I'll go install onto v4 now and do whatever necessary to get it done (if that means reintegrating compression back into the latest version then so be it). I want to do some benchmarks and stress-testing

From: http://www.phoronix.com/forums/showpost.php?p=27495&postcount=45

[Jade]

The above was posted by edged on 03-19-2008, 02:39 AM

[Jade]

I tried asked him to what the "the most unbelievable answer" actually was. But as yet have no reply.

[Jade]

I would dearly love to hear the reply -- anyone know it?

[memo2005]

Reiserfs is a new invention for this Earth Civilization that could make a revolution in a data storage.

So occupation forces (sometimes referenced as "conspiracy theory") have had to stop reiserfs development or to keep it to be "file system" for all days.

Killing Hans was not so easy as John Lennon for example, so Hans Reiser is in prison now.

Here is more: http://www.totalizm.nazwa.pl/bandits.htm

PS. I am using Reiserfs version 3 with several million files as a database with no problems

[Jade]

Reiserfs is a new invention for this Earth Civilization that could make a revolution in a data storage.

So occupation forces (sometimes referenced as "conspiracy theory") have had to stop reiserfs development or to keep it to be "file system" for all days.

Killing Hans was not so easy as John Lennon for example, so Hans Reiser is in prison now.

Here is more: http://www.totalizm.nazwa.pl/bandits.htm

PS. I am using Reiserfs version 3 with several million files as a database with no problems
This is indeed my belief as well.

[Jade]

You can see that even those at this site feel guilty, as they try to hide this thread.

[Jade]

Yes, some here feel VERY guilty, and hide this thread so it doesn't list on the front page as normal.

[StringCheesian]

This is indeed my belief as well.

Did you read the link you seem to be agreeing to? It blames everything on "UFOnauts" instead of your favorite "Jews"...

[Jade]

Did you read the link you seem to be agreeing to? It blames everything on "UFOnauts" instead of your favorite "Jews"...
I believe what he says about Reiser.

If he calls Jews "UFOnauts," that is none of my concern.

[BlueKoala]

I suggest you don't try to apply logic to real life situations. You will be called a conspiracy theorist, anti-semitic, anti-progress, pro terrorist, a liar or just plain crazy.

[ferreira]

UFOnauts, lol. I'm quite familiar with "theories" from whom this word has originated, dr Jan Pająk. They are a good bunch of theories that employ a good bit of science, but they cannot be proven true... same as with yours, Jade.
You two can become friends, but I am worried you will start looking for conspiracy in each other very soon...

[lenrek]

With Hans now in jail, who is gonna maintain Reiserfs4? - Just curious.

[hoho]

Damn you guys crack me up :D

[Jade]

With Hans now in jail, who is gonna maintain Reiserfs4? - Just curious.
You think I should?

[lenrek]

I manage to find someone pick up the code and still trying to support Reiserfs4.

http://chichkin_i.zelnet.ru/namesys/

He seems to be an ex-employee of Namesys.

http://www.news.com/8301-13580_3-9851703-39.html

I guess, time will tell, how far can this go...

[lenrek]

You think I should?

Honestly, no

[Jade]

Honestly, no
Why not? I am seriously considering it.

[zappa86]

Why would those devs try to sabotage the kernel? Can people in prison write letters? It would be nice to send these code examples to Mr. Reiser (or any other kernel devs) and see what he has to say.

[lenrek]

Why not? I am seriously considering it.

Well... You do understand, for changes to be added into the (official) kernel source, that changes will need to be verified by someone and finally accepted by Linus. What you have asserted here, the kernel developers have ganged up together to make Reiserfs perform badly in Linux.

So...

1) You have accused the kernel developers as SABOTEURS (a bunch of SOB). This mean you don't trust them.

2) If you are helping the maintenance of Reiserfs (3/4), then you should have mail your findings to them and explain to them what they had done wrong. Instead of that, you make accusation that they are a bunch of SOB. This mean, you are not willing to work with them.

3) If this is how you deals with problem, I doubt kernel developers would trust you either.

Conclusion, neither you nor the kernel developers would be able to work together.

Implication, if you became _the_ person maintaining Reiserfs (3/4), that would definitely spell the end of Reiserfs for Linux.

[Jade]

Well... You do understand, for changes to be added into the (official) kernel source, that changes will need to be verified by someone and finally accepted by Linus.

No worries. I don't care if it is never accepted by the kernel SABOTEURS.

What you have asserted here, the kernel developers have ganged up together to make Reiserfs perform badly in Linux.

Not all of them,... but yes.

I would initially be happy to do what Edward Shishkin is doing.

Since he is doing this, I have not got to learn the code.

What I would like to do is develop Reiser's idea of "the filesystem = the database."

So far there has been no motivation to get stuck in,... so its all just maybes...

[Huenengrab]

I always thought Xenu was behind the sabotage-acts on the linux-kernel. Or maybe unicorns.

You destroyed my fancy conspiracy-theory!

[MamiyaOtaru]

Some people in this thread are causing a worldwide tin shortage with their haberdashery.

[lenrek]

No worries. I don't care if it is never accepted by the kernel SABOTEURS.

It would be your own fork. So, have fun with it then...

... Not all of them,... but yes.

So... Not all of them? Then, they just remain silent about this issue? Or, maybe they are not that smart enough to notice this, only you saw this problem?


... What I would like to do is develop Reiser's idea of "the filesystem = the database." ...

Hans Reiser is an asshat (http://www.bel.fi/~alankila/blog/2005/09/20/Hans%20Reiser%20is%20an%20asshat.html)

[lenrek]

Some people in this thread are causing a worldwide tin shortage with their haberdashery.

We, the EAC (http://evilatheistconspiracy.org/)... Erm... Sorry, we don't exists. Oh... Oops... :D

[Jade]

It would be your own fork. So, have fun with it then...
When is a fork, not a fork?

No one is actively working on Reiser4. No one. So my fork would be simply a bend in the only road. Not a fork at all, really.

[Jade]

So... Not all of them? Then, they just remain silent about this issue? Or, maybe they are not that smart enough to notice this, only you saw this problem?
Most of them probably never noticed.

[lenrek]

When is a fork, not a fork?

Well, if it is a fork, then it is a fork. Unless, you are trying to fork into something that is not a fork?

No one is actively working on Reiser4. No one. So my fork would be simply a bend in the only road. Not a fork at all, really.

Sure... Go ahead, no one stopping you.

[lenrek]

Most of them probably never noticed.

Why not _share_ your finding with them. I am sure, they would be interested.

[Jade]

Why not _share_ your finding with them. I am sure, they would be interested.

Already have on LKML (linux kernel mailing lists).

I also "spammed" the LKML with ONE copy of

The Hans Reiser Murder Trial. Timeline and Analysis.

http://linuxhelp.150m.com/politics/ReiserTrialSummaryAnalysis.htm

Of course the liars who control the LKML consider one of anything they don't like "spam."

[deanjo]

Already have on LKML (linux kernel mailing lists).

I also "spammed" the LKML with ONE copy of

The Hans Reiser Murder Trial. Timeline and Analysis.

http://linuxhelp.150m.com/politics/ReiserTrialSummaryAnalysis.htm

Of course the liars who control the LKML consider one of anything they don't like "spam."

As long as you carry your prejudices, your code and view will lead straight to the garbage bin.

[Jade]

As long as you carry your prejudices, your code and view will lead straight to the garbage bin.
Oh really,.........

[Jade]

As long as you carry your prejudices, your code and view will lead straight to the garbage bin.
Maybe you would check out the GCC compiler and cross-compiler program in (that would be nice):

"Free COMPILERS and CROSS-COMPILERS for Linux and Windows." @

http://www.phoronix.com/forums/showthread.php?t=8411

[MamiyaOtaru]

What the hell? Once a week you think of a new comeback?

[Michael]

Jade, stop your stupid spamming or be banned...

[Jade]

Jade, stop your stupid spamming or be banned...
Ah,... Michael, is it possible to have the silly fake counter removed from this thread. No on believes it has been read 12,789, or whatever, times.

[StringCheesian]

Ah,... Michael, is it possible to have the silly fake counter removed from this thread. No on believes it has been read 12,789, or whatever, times.

This thread (http://www.phoronix.com/forums/showthread.php?t=7350) has even more: 50033.

Maybe search engine bots going crazy? Or more likely somebody's running a script to check a little too frequently for new posts in those threads.

[pedepy]

all I have to say is .. what da FUCK ?!.


kernel file system driver occupation consipiracy underground panic what?


you guys need to get some FRESH AIR into your brains, seriously.

[Jade]

Or more likely somebody's running a script to check a little too frequently for new posts in those threads.
I believe that you have the correct answer there.

[xploited]

Jade, your dedication to the topic deserves respect. I have done my own research regarding Hans Reiser and the fate of Reiser4. My conclusion is that the "conspiracy theory" is at least partly true. It requires a more credible name though, such as "conflict of individuals" or "miscommunication problem". Even Torvalds admitted that certain kernel developers are tough to deal with.

On the other hand, many performance tests found on the web give contradicting in formation. Some say Reiser4 is a brilliant technology, others call it nothing more than a failed ambition. That alone is somewhat strange.

Anyway, in a couple of weeks I plan to be running an amazing system - openSuse 11 x86_64, Reiser4, KDE4, Compiz Fusion...
So, it is vital that dedicated supporters / developers for Reiser4 emerge now. IMHO, the idea is too good too let it die.
I would even dedicate my own time to it, unfortunately I have zero knowledge of kernel / file system developing

[lenrek]

Huh?? Partly true? What true is that?

Oh... Whatever...

[xploited]

the reason why Reiser4 isn't in the kernel is a personal conflict between Hans and certain kernel developers. Even Linus admitted it.

[lenrek]

the reason why Reiser4 isn't in the kernel is a personal conflict between Hans and certain kernel developers. Even Linus admitted it.

Personal conflict? Ya ya... Sure sure... Whatever...

http://kerneltrap.org/node/6844

[Jade]

http://kerneltrap.org/node/6844
From lenrek's link: http://kerneltrap.org/node/6844

From: grundig [email blocked]
Subject: Re: reiserFS?
Date: Sun, 16 Jul 2006 18:55:30 +0200

"Let me also remember (remind) you that we have had other relevant filesystems for years (reiser3, XFS, JFS), and everybody is ok with them, nobody is planning to kill anyone,...."

Do you think he knew more than he was saying and meant it to continue,....

but with Reiser4 they plan to kill Reiser's wife and frame Reiser. That way Reiser4 will never be a competitive issue for various nasty software and database companies,....

[lenrek]

Ah...

Maybe aliens from Vega system or Mars are involve? You do know that, some believe aliens live among us? I bet, if they exist, they won't want to see such great accomplishment of Reiserfs4.

[yoshi314]

http://blog.wired.com/27bstroke6/2008/06/hans-reiser-off.html

this topic is getting way stupid.

[Jade]

the reason why Reiser4 isn't in the kernel is a personal conflict between Hans and certain kernel developers. Even Linus admitted it.
Do you have a quote/reference for this?

[lenrek]

Maybe this thread exist solely for for comic relief.

:D

[Vighy]

Ah...

Maybe aliens from Vega system or Mars are involve? You do know that, some believe aliens live among us? I bet, if they exist, they won't want to see such great accomplishment of Reiserfs4.

I would quote this one!! :D:D

Hans Reiser made really a good job! Reiser4 was even better than alien file systems!!!!! :cool: :D

Could be possible that Linus is an alien!?! :eek::eek::eek:

[Jade]

Reiser is in prison because his file-system was better... End of story.

#2 (for the red), THIS IS A FAKE LIE YOU MADE UP, STOP SPREADING IT
How do you know whether this is a correct or not?

How could you possibly know?

Why are you so certain that Reiser is not in prison because his file-system was better,... when you cannot possibly know whether this is true or not,... unless, of course, you do KNOW that Reiser has been framed (in order to kill Reiser4) and are trying to stop people even considering that this is the case.

Reiser's trial was a huge joke.

With a little reading up, any intelligent person can see this.

No matter how the liars spin it,... it is quite apparent that the trial (& verdict) was a total joke.

Who was funding this amazing travesty of justice.

Where was the money coming from.

My guess is from various software and database interests. From the same people (and their puppets in the media) who were already trying to kill Reiser4.

Who paid judge Trina Thompson Stanley to have Reiser held in solitary confinement without bail on the basis of the amazingly flimsy blood and missing seat "evidence."

So, who pushed for solitary confinement, without bail, on the basis of "evidence," that attorney Daniel Horowitz describes as, trace, weak and inaccurate.

Oct 12, 2006: "There's not a lot of forensic evidence at all. Whatever they got is trace," Daniel Horowitz said.

Oct 12, 2006: Investigators are "leaking sensational information that may not even be accurate," Daniel Horowitz complained.

Oct 23, 2006: The prosecution's case is weak. "Here's the statement of probable cause, and I've read it, and their case is much weaker than they've said it is," Horowitz said.

So, who pushed for solitary confinement, without bail, on the basis of "evidence," that two months later will be called, "utterly unconvincing," by the judge Julie Conger.

Dec 11, 2006: judge Julie Conger comments that she found Oakland PD's theory utterly unconvincing on account of its placements and timings of people not matching what had been established in court.

But, disregarding her own publicly stated conclusion, she allows the trial to proceed anyway. I guess judge Julie Conger was bought as well.

On Sept. 29, 2006, just three weeks after the supposed murder, the FBI is provides a "little bit of manpower," with the forensic investigation.

How much pull and money, does it take to get the FBI involved in a missing person case so early in the case and before much of anything is actually known?

Sept. 18, 2006: Guerrero said officers trailed Hans Reiser, both by car and by a special surveillance aircraft,...

Who paid for around the clock surveillance by so many agents and for the special surveillance equipment?

Who got the police so interested in this missing person case just two weeks after Nina Reiser had gone missing, that they devoted a fistful of dollars to it and with (at that time) no evidence, at all, of foul-play?

Sept. 18, 2006. Alameda County commissioner Nancy Lonsdale declined to grant Reiser's custody request following testimony from Oakland police officers who said they had evidence that would argue against giving Reiser the children.

Police said they couldn't share the evidence, not even with the commissioner.

The police LIED when they claimed they couldn't share the evidence, not even with the commissioner, because they didn't have any evidence,... they just LIED.

We now know that the police LIED. Who paid them to LIE.

Who has enough pull to get the police to LIE?

From http://www.phoronix.com/forums/showthread.php?t=10902&page=2 (this thread has been censored for some unknown reason)

[stan.distortion]

Ok, there are a lot of unusual circumstances around this case (as there are in so many others), but it's a file system for f***'s sake, not a thermonuclear device or a way to crash the financial system. Your so bothered? Then when you make your corrections and get it working release your own patches. If it's as good as it's made out to be (and it does sound very good) your patches will become a 'must have' for folks like the rt2500 patches are for some, different league but same principle.
If it gets enough attention the black helicopters will start hovering around your house, you will have an 'accident' and then will forever be a martyr to your cause.
As to the number of hits, it does seem strange. Trouble is, it's inconsistent with hits on other sites covering the story, that would suggest you have a script running to gain attention....or that someone else has a script running so folks think that just to discredit you....or is it the other way?...or...or...

[Ex-Cyber]

IMO, Reiser sabotaged Reiser4, by trying too hard to make it the future of filesystems instead of just building a solid Linux filesystem. It got to the point that he suggested scrapping the existing VFS layer and reimplementing support for other filesystems with Reiser4 "plugins". Most of the so-called "personality conflicts" came out of disagreements about the philosophy behind Reiser4 and its implications for Linux in general, not some irrational hatred of Reiser personally. It's not just about a filesystem, it's about technical decisions that could affect every Linux filesystem.

[Jade]

A new kernel and still no Reiser4.

The Linux Kernel SABOTEURS win yet another round.

[mlau]

A new kernel and still no Reiser4.


Someone should actually submit it for inclusion and wait for the VFS gurus to give their blessing. AFAIR the last submission attempt was
around 1-2 years ago.

Calling the kernel people "sabotuers" on a random internet forum won't
help Reiser4's cause, you know. So please stop it. It's annoying.

[d2kx]

Someone still develops Reiser 4?

[mlau]

Someone still develops Reiser 4?

Yes, at least one former Namesys employee still fixes bugs and
does fixups for newer kernels.

[yoshi314]

A new kernel and still no Reiser4.well i'm still waiting for gentoo patchset for the new kernel. do you think it's also sabotage?

besides it's only been a day or two. can't you wait one stupid week? if you cannot wait, why don't you port reiser for 2.6.26 and stop sabotaging these forums?

(people who prefer stable kernels stick to 2.6.16.x line anyway. or similar kenrel branches).

that's the way it is. i had to wait ~10 days for aufs to get patched for 2.6.25. as most external kernel module users usually have to. kernel changes, developers have to follow.

[Vighy]

well i'm still waiting for gentoo patchset for the new kernel. do you think it's also sabotage?

besides it's only been a day or two. can't you wait one stupid week? if you cannot wait, why don't you port reiser for 2.6.26 and stop sabotaging these forums?

(people who prefer stable kernels stick to 2.6.16.x line anyway. or similar kenrel branches).

that's the way it is. i had to wait ~10 days for aufs to get patched for 2.6.25. as most external kernel module users usually have to. kernel changes, developers have to follow.

He means there's no inclusion of reiser4 in the mainline.

but jade.... you did know that wasn't going to be in this release, since 2 weeks ago... why do you say it now?

But a question about you, are you skilled at programming? are you used to code?

[yoshi314]

the way i understood it - he means either inclusion or making reiser4 compatible. the latter happens within a week or two after a stable kernel release anyway.

what's the point of bitching? he should try looking at unsupported section on gentoo forums, there are people developing various kernel patchsets, also with reiser4.

reiser4 was rejected because it was too intrusive on various areas of the kernel that traditionally don't belong to the fs layer.

[Vighy]

the way i understood it - he means either inclusion or making reiser4 compatible. the latter happens within a week or two after a stable kernel release anyway.

what's the point of bitching? he should try looking at unsupported section on gentoo forums, there are people developing various kernel patchsets, also with reiser4.

Jade's reasons are all political reasons... :D
He maybe uses it in a patched kernel... but he want's to demonstrate reiser4's supremacy


reiser4 was rejected because it was too intrusive on various areas of the kernel that traditionally don't belong to the fs layer.

not only! :D also the quality of code and code readability.
Reiser4 has a lot of issues unsolved. Is potentially a good (someone thinks the best) filesystem, but in practice is not "finished".

[H.i.M]

^
This is the answer.
Nothing different.

[Jade]

Jade's reasons are all political reasons... :D
That is just not true.

[Jade]

A new kernel and still no Reiser4.
well i'm still waiting for gentoo patchset for the new kernel. do you think it's also sabotage?

besides it's only been a day or two. can't you wait one stupid week?
I meant that Reiser4 is still not in the kernel, not that a patchset has not arrived,... but you may be right,... has the gentoo patchset come out yet?

[Jade]

It really seems like everyone just wants this article (the truth) to go away.

[rbmorse]

You're just now figuring this out?

[Setlec]

You're just now figuring this out?
lol, conspiracy is on what we live for.

[kgonzales]

It really seems like everyone just wants this article (the truth) to go away.

If this is the biggest thing you have to worry about in your life, such as it is, consider yourself lucky.

[bulletxt]

for Jade:

to be honest, I don't who is in right over here, but you scared me with this sentence: "That way Reiser4 will never be a competitive issue for various nasty software and database companies,...."

I've never thought of such a thing.... but you should better argoument your theories! or else anyone can do conspiracy about anything in the world!

[xav1r]

im baffled by all this. So, was this Reiser guy basically framed for a crime he didnt commit? Who killed his wife then?

[psycho_driver]

Oops, double post.

[psycho_driver]

im baffled by all this. So, was this Reiser guy basically framed for a crime he didnt commit? Who killed his wife then?

http://en.wikipedia.org/wiki/Hans_Reiser#Recovery_of_Nina.27s_body_and_sentenci ng

Hans killed her and his crappy FS killed two of my HTPCs in the past.

[Vighy]

It really seems like everyone just wants this article (the truth) to go away.

Is the truht what really happened or just what we believe truth is?

I'm happy with ReiserFS, JFS and in future Btrfs :D

[Jade]

Is the truht what really happened or just what we believe truth is?
Yes it is really true.

You don't even have to know C that well to understand the small but deliberate changes (ie sabotage) to the source code that led to Reiser4 destroying its filesystem.

The sabotage to Reiser4 was really very obvious.

[Vighy]

Yes it is really true.

You don't even have to know C that well to understand the small but deliberate changes (ie sabotage) to the source code that led to Reiser4 destroying its filesystem.

The sabotage to Reiser4 was really very obvious.

I meant that truth is not what really happens, but what we believe happens... this means that hans reiser could be or not be the murderer of his wife.. but it doesn't matter much, since he has been convicted. You cannot change this.

Knowing C may help me distinguish "sabotage" from "bug fixing", what you are not trying to do! :D

Remember that if "something works" it doesn't mean "it's right"!

Maybe reiser did mistakes writing the code; everybody (even the best programmers) make them! So, even if something works in some cases it may not work in all the cases. A better implementation could be even different.
Except if you really know what every single line of code of Reiser4 does, you should not base your sabotage theories on "lines swapped".

Ok, there may be breakage between the two different implementations, but Reiser4 is not in feature freeze! so breakage is likely to happen and you are advised that this could be dangerous for your data.

[Jade]

Knowing C may help me distinguish "sabotage" from "bug fixing", what you are not trying to do! :D

Knowing C MAY help you, but it clearly hasn't.

The sabotage is so obvious that a blind man could see it.

[Jade]

This is also of interest to this thread:

Real World Benchmarks Of The EXT4 File-System

http://www.phoronix.com/forums/showthread.php?t=14189

[Jade]

So Ext4, which is less stable and has less features than Reiser4, is in the kernel while Reiser4 is not.

What weird CONSPIRACY is this?

[RealNC]

Sucks, doesn't it?

[d2kx]

Ext4 is maintained by several developers. Who maintains Reiser4?

[Vighy]

So Ext4, which is less stable and has less features than Reiser4, is in the kernel while Reiser4 is not.

can you prove it with a recent and neutral source?

have you studied all the test cases? ahaha if yes, why don't you work on reiser4 and make it become suitable for mainline?

since reiser4 isn't in the mainline because it's badly developed, with redundant code, badly commented code, and unreadable code.

These are all technical issues. If you feel more intelligent that kernel people, why don't you work on it to make it better??

[jadeisalooney]

So Ext4, which is less stable and has less features than Reiser4, is in the kernel while Reiser4 is not.

What weird CONSPIRACY is this?

It's kind of similar to the "conspiracy" that you kept on declaring while Hans was on trial. Except then he confessed and led police to her body.

Meanwhile, it shows your status as "banned"? Could this be true? After all these years of ranting and tilting at windmills, you've finally been banned?

It's a Christmas miracle!

[val-gaav]

I think he was banned because he once again added "Jews" into his conspiracy theory claiming that Jews bought out Novel and ruined Suse in one of the forum posts. Micheal already gave him a warning about his racist comments in the past. Don't look for the post though it seems it has been deleted.

and I think it was very good decision I mean although Jade conspiracy theories were sometimes entertaining I think his racist comments are more then enough to justify the ban.

[DeepDayze]

I think he was banned because he once again added "Jews" into his conspiracy theory claiming that Jews bought out Novel and ruined Suse in one of the forum posts. Micheal already gave him a warning about his racist comments in the past. Don't look for the post though it seems it has been deleted.

and I think it was very good decision I mean although Jade conspiracy theories were sometimes entertaining I think his racist comments are more then enough to justify the ban.

That's exactly why we don't need such people on a forum like this one. jade's made some good posts, but needs to leave the bigotry out. Sorry to go offtopic on this thread, but just my 2 cents here.

OK to help get back on topic, are there any other kernel sabotage attempts ever noted?

[jadeisalooney]

That's exactly why we don't need such people on a forum like this one. jade's made some good posts, but needs to leave the bigotry out. Sorry to go offtopic on this thread, but just my 2 cents here.

OK to help get back on topic, are there any other kernel sabotage attempts ever noted?

It's just amazing to me that he went so long without getting banned. Over on sfgate.com, where he blogged incessantly about the Reiser trial, he couldn't go more than a day before ranting about the "Jews" and getting banned.

He'll probably be back shortly with another screenname.

As far as "Linux saboteurs", what he's referring to is what sane people call "bugs". In software development, sometimes changes are made that inadvertently break functionality. To Jade, this was evidence of "sabotage".

[DeepDayze]

It's just amazing to me that he went so long without getting banned. Over on sfgate.com, where he blogged incessantly about the Reiser trial, he couldn't go more than a day before ranting about the "Jews" and getting banned.

He'll probably be back shortly with another screenname.

As far as "Linux saboteurs", what he's referring to is what sane people call "bugs". In software development, sometimes changes are made that inadvertently break functionality. To Jade, this was evidence of "sabotage".

So at least another forum troll bites the dust...

OK good point, but what about blatant attempts to sabotage the Linux kernel? Are there people out there who submit code to purposely break a subsystem and how good is such sabotage detected and reported?

[Ex-Cyber]

There was an incident in 2003 in which someone tried to insert a local root exploit into the kernel (by inserting a "uid = 0" into a conditional, i.e. disguised as a check). It was caught, arguably because they tried to insert it by breaking into the CVS mirror and inserting it directly rather than by submitting a patch. On the other hand, if they had submitted it as a patch, it would have almost certainly been caught because it was a pretty critical file.

[yesterday]

So at least another forum troll bites the dust...

OK good point, but what about blatant attempts to sabotage the Linux kernel? Are there people out there who submit code to purposely break a subsystem and how good is such sabotage detected and reported?

Blatant sabotage attempts would be easily spotted by a project's many users and developers. Let's hypothesize that there IS sabotage. Why isn't there a large user and developer outcry? A few whack-jobs on the forum doesn't count -- why isn't a group of developers in control of Reseir4 blogging and slashdotting and lkmling about malicious patching? Either there is no such community (meaning that the sabotage issue is moot) or no such sabotage is taking place.

[jadeisalooney]

Blatant sabotage attempts would be easily spotted by a project's many users and developers. Let's hypothesize that there IS sabotage. Why isn't there a large user and developer outcry? A few whack-jobs on the forum doesn't count -- why isn't a group of developers in control of Reseir4 blogging and slashdotting and lkmling about malicious patching? Either there is no such community (meaning that the sabotage issue is moot) or no such sabotage is taking place.

That's exactly right. Which is more likely? A lone nut, or a vast conspiracy where someone is able to hide sabotage in open-source code that thousands of experts are scrutinizing? (Hint: there are roughly two million people in the US currently suffering from schizophrenia.)

[DeepDayze]

It is a good thing that there is close scrutiny of all code and also is there a way for code to be certified free of malicious intent? I thought developers who submit their code to the Linux tree need to certify their code in order for it to be considered for acceptance. Linux's reputation is staked on being free of malicious code...

[rbmorse]

You're correct that all code submitted for inclusion in the kernel has to be signed off by both the submitter (no anonymous contributions) and a senior developer who "monitors" the branch to which the code applies.

Once accepted, the code goes into the release-candidate pre-releases where it is both available for anyone's inspection and (allegedly) rigorously tested under real-world conditions (i.e., by thousands of wonks working in basements and garages around the world).

The system is not perfect, as the regression list testifies, but any malicious code would have to be pretty damned obfuscated to get by...and obfuscated code is usually something that gets people's attention.

[DeepDayze]

You're correct that all code submitted for inclusion in the kernel has to be signed off by both the submitter (no anonymous contributions) and a senior developer who "monitors" the branch to which the code applies.

Once accepted, the code goes into the release-candidate pre-releases where it is both available for anyone's inspection and (allegedly) rigorously tested under real-world conditions (i.e., by thousands of wonks working in basements and garages around the world).

The system is not perfect, as the regression list testifies, but any malicious code would have to be pretty damned obfuscated to get by...and obfuscated code is usually something that gets people's attention.

So then we should not fear sabotage as any piece of code is checked rigorously for any unusual or strange behavior. Security holes are easy to spot with many eyes checking code

[gordboy]

There have been documented cases of kernel sabotage in the past. The old ext2 filesystem in 2.2.17 was found to cause "massive filesystem corruption" and some of the "developers" (rumoured to be ex or even *current* micro$oft employees) were promptly sent packing.

Then we have the ongoing saga of ALSA sound. Anyone who works with or, more to the point, on sound apps knows that ALSA is a dog's dinner of a mess. And the lead developers work for Novell ...

But admittedly, "traditional" OSS sound was pretty bad too. Many people use the "new" OSS from Forefront, as it does software mixing, thus obviating the need for a pesky desktop sound server.

And what about graphics huh ? The Big Two, ATI & nvidia have both promised micro$oft never to release a fully working linux driver. This is a matter of public record.

I think we can safely say that linux is *constantly* being undermined by corporate interests. And when both the sound and video are hobbled, then it is hard to see how linux will ever penetrate the desktop - short of micro$oft senior executives being jailed for fraud and corrupt practices, and the whole Evil Empire being flushed down the toilet ... :)

[rbmorse]

And what about graphics huh ? The Big Two, ATI & nvidia have both promised micro$oft never to release a fully working linux driver. This is a matter of public record.



That's about all you need for a good "restraint of free trade" action under EU rules. Citations, please. Unless you're talking about restrictions imposed to protect IP. If that's the case, that's nothing ATI/AMD or nVidia controls.

[bridgman]

And what about graphics huh ? The Big Two, ATI & nvidia have both promised micro$oft never to release a fully working linux driver. This is a matter of public record.

I would be really interested in any references to this as well.

[RealNC]

I think he's just talking out of his bum :P

[gordboy]

Confession time : I posted that last post to see who would crawl out of the woodwork.

I really didn't think anyone would show their allegiance to their corporate overlords quite so brazenly here.

Just in case anyone is in any doubt : there are *several* pending antitrust suits against AMD/nvidia both jointly and severally as defendants. And they have been repeatedly criticized for price fixing and anti-competitive practices, including "lock-in" with micro$oft.

Only corporate stooges shout "give us citations" when google is absolutely full of apposite material. The number of complaints in the California courts alone, would be enough to fill this forum ten times over. Then we have damning testimony to the EU from micro$oft themselves, which led to unprecedented fines and prohibitions from tendering.

I think it's about time that members of this forum who work for the companies concerned, remembered that misrepresenting the facts about their company policies and practices is a criminal offense in most jurisdictions.

Of course, no-one here is stupid enough to go down that road. Instead they obfuscate, deflect and parry with depressingly predictable ad hominem attacks. But the end result is still the same - they end up as pariahs, unable to even get a job selling water in a desert.

[bridgman]

It says "AMD Linux" on every post I make; I can't get much more brazen than that :D

I would still be interested in any information related to your previous post where you said "The Big Two, ATI & nvidia have both promised micro$oft never to release a fully working linux driver. This is a matter of public record.".

[Ex-Cyber]

Only corporate stooges shout "give us citations" when google is absolutely full of apposite material. The number of complaints in the California courts alone, would be enough to fill this forum ten times over. Then we have damning testimony to the EU from micro$oft themselves, which led to unprecedented fines and prohibitions from tendering.I'm not sure how to describe how weak of a response this is. Hmm...

obfuscate, deflect and parry with depressingly predictable ad hominem attacks.That works. :D