Announcement

Collapse
No announcement yet.

The Linux Kernel SABOTEURS.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • rbmorse
    replied
    Originally posted by gordboy View Post
    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.
    Last edited by rbmorse; 25 January 2009, 10:59 AM.

    Leave a comment:


  • gordboy
    replied
    Many ways to sabotage linux ...

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

    Leave a comment:


  • DeepDayze
    replied
    Originally posted by rbmorse View Post
    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

    Leave a comment:


  • rbmorse
    replied
    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.

    Leave a comment:


  • DeepDayze
    replied
    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...

    Leave a comment:


  • jadeisalooney
    replied
    Originally posted by yesterday View Post
    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.)

    Leave a comment:


  • yesterday
    replied
    Originally posted by DeepDayze View Post
    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.

    Leave a comment:


  • Ex-Cyber
    replied
    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.

    Leave a comment:


  • DeepDayze
    replied
    Originally posted by jadeisalooney View Post
    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?
    Last edited by DeepDayze; 04 January 2009, 10:23 PM.

    Leave a comment:


  • jadeisalooney
    replied
    Originally posted by DeepDayze View Post
    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".

    Leave a comment:

Working...
X