Linked by Thom Holwerda on Thu 11th Jul 2013 21:35 UTC
Microsoft Documents released by Snowden show the extent to which Microsoft helped the NSA and other security agencies in the US. "Microsoft helped the NSA to circumvent its encryption to address concerns that the agency would be unable to intercept web chats on the new portal; The agency already had pre-encryption stage access to email on, including Hotmail; The company worked with the FBI this year to allow the NSA easier access via Prism to its cloud storage service SkyDrive, which now has more than 250 million users worldwide; [...] Skype, which was bought by Microsoft in October 2011, worked with intelligence agencies last year to allow Prism to collect video of conversations as well as audio; Material collected through Prism is routinely shared with the FBI and CIA, with one NSA document describing the program as a 'team sport'." Wow. Just wow.
Permalink for comment 566964
To read all comments associated with this story, please click here.
RE[2]: Now we know what happend.
by Valhalla on Fri 12th Jul 2013 21:46 UTC in reply to "RE: Now we know what happend."
Member since:

There is no way you can keep up and audit all changes

Only code that is actually a candidate to make it into the kernel needs to be audited, are you saying code gets merged into a mainline release without being audited? Show me some proof.

HP spends millions of USD to keep up with the device drivers, because Linux upgrades frequently breaks the drivers.

Citation needed.

OpenBSD seems to be much rigorous with the code review and audit.

No argument here, OpenBSD is the most security oriented operating system I can think of, of course it leads to drawbacks like being very slowly developed.

Also OpenBSD's focus on security above (pretty much) all else doesn't mean that Linux has 'bad' security in any way.

Linux has a chaotic development process and all code is not reviewed nor understood, which makes Linux a haven for NSA and other malicious users.

Bullshit, how is Linux development chaotic?

People/companies submit code, code is audited by the maintainer/maintainers of the specific subsystem the code belongs to, then if it passes their audit it's put in staging where it will go through testing and more eyeballs as at this stage it's actually a candidate for mainline.

Then when the subsystem maintainer feels the code is mature enough he/she waits for the merge window to open and then sends a pull request to Linus.

Linus then has the final say on whether or not it will make it into the merge window, if it does it will go through further testing during the merge window, and if it passes it will finally make it into a mainline release.

How is this a chaotic development process?

“You know what I found? Right in the kernel, in the heart of the operating system, I found a developer’s comment that said, ‘Does this belong here?’ “Lok says. “What kind of confidence does that inspire? Right then I knew it was time to switch.”

This proves that Linux developers does not review all code, nor understand what the code does.

A 2005 quote from some 'Lok' about a comment he found in the Linux source code, without any context whatsoever as to what the comment even related to is something you claim to be proof of Linux developers not reviewing or understanding the code? Your trolling seems to know no bounds.

Now that you seem to have given up championing Solaris you've instead embarked on a anti-Linux crusade, I guess I shouldn't be surprised.

Du borde hitta något konstruktivare att tillbringa din tid med, istället för att hata och attackera Linux, varför inte fokusera på att lyfta fram egenskaper hos de operativsystem du gillar? Har aldrig förstått mig på din typ av beteende.

It is wildly chaotic with lots of contributions from everywhere, including from NSA.

How is getting code contributions chaotic?

These contributions, if they make it into the kernel mainline release at all, only make it in once they've been audited and tested.
"The [linux source code] tree breaks every day, and it's becomming an extremely non-fun environment to work in.
We need to slow down the merging, we need to review things more, we need people to test their f--king changes!"

You dig up a 5 year old e-mail where a developer states that they need to slow down the amount of merging during the merge window or make the merge window longer as proof of what exactly?

That five years ago they had a dialogue about the amount of code which should be merged during a merge window?

Reply Parent Score: 5