Open source at that.... Well, if the NSA is releasing open source spyware, I'm sure it will get exposed with more than just idle speculation soon enough.
That is idle speculation as well. Never blindly trust Linus' Law, I though we learned that lesson already!
The US Navy PFMABE program released here contains a lot of code, it's not that obvious that anyone will bother reading through the complete code.
What I personally think is really scary is that a lot of devices in our PCs are ready to accept new firmware at any moment. There usually are no safeguards that I can enable to prevent malicious code being injected to core components like BIOS, CPU microcode, HDD, DVD...
Now, in general, hardware security is a tricky concept, because currently the hardware layer is simply fully trusted.
Ok, good counterargument, but I still suspect that the amount is extremely low outside the main developer team.
The romantic vision of hackers around the world sitting comfortably next to a fireplace with a ThinkPad and browsing source code in the evening is just a fantasy...
I think the big issue with the Heartbleed bug was that the OpenSSL code base was so egregiously poorly written and maintained that eyeballs started bleeding whenever they looked at it. imo, the OpenSSL code base never had enough eyeballs looking at it to make its bugs shallow. It was painful to look at, so eyeballs avoided looking at it.
That's really just speculation.
So let's everyone ask ourselves this question: how many times do we personally browse open source code, looking for vulnerabilities or other bugs?
Let me guess that the answer is: I mostly run precompiled binaries, and might rarely take look at a particular small piece of code to solve a specific problem (which I came across by running the binary).
I suggest that it just is likely that most OSS projects are like OpenSSL: only the core developers take a look at the codebase.
My solution is that instead of relying on Linus's Law, we should be more thinking about dedicated professional code audits, because those actually work and can be really powerful in improving security. Big commercial shops like Microsoft and Apple already do this in spades internally as part of their QA procedures.
Open source is neat, huh? Sure, would be nice if Source 2 were, you know, open source.
Sure, and it would be nice if it was Christmas every day.
But...tadadadattataa! Tim Sweeney to the rescue! Unreal Engine 4 is fully open source if you really need an engine that you can modify all the way down to the hardware abstraction layers.
I'm not sure if the Windows NTFS driver is not terribly portable either...probably would need a lot of work to make it work with the Linux block layer.
But anyway, there's better SSD TRIM support in Windows: vectorized TRIM ranges, and TRIM integration also with volume level commands.[1]
Then there is GPU driver in userspace, which is a nice concept, although not portable really.
If you don't believe them ask NoSteam. The DRM comes off easily.
The fact still remains that I have to rip off the DRM myself. Instead I want to buy a product that directly suits my needs, if I'm paying money for it.
Another fact is that by buying from Steam, I am voting with my wallet and saying "I am fine with DRM".
Right, so 365 will get ODF support, just like the previous three desktop versions of Office got. Did anyone wind up using the ODF support before? Not that I have heard. What will be different this time? It will not push people any further to open standards if it's just an optional feature to save the document in.
So what? People here are still talking like it's a new thing being introduced to Office, while the support has been there for well over half a decade. Here is even a Slashdot announcement from 2009.
Slashdot Mirror
Open source at that.... Well, if the NSA is releasing open source spyware, I'm sure it will get exposed with more than just idle speculation soon enough.
That is idle speculation as well. Never blindly trust Linus' Law, I though we learned that lesson already!
The US Navy PFMABE program released here contains a lot of code, it's not that obvious that anyone will bother reading through the complete code.
Yes, but with that Magnet link we lose context. Theoretically it could link to a version of the program peppered with malware.
No, I don't think. What I said would still apply.
I wouldn't buy the aspirin if I couldn't be certain that the pill contains aspirin.
Good point. Practicality trumps security here.
It pays better to exploit the bugs...
Even if a blackhat secretly monetizes a bug, a whitehat can still officially grab the bounty for the same bug.
What I personally think is really scary is that a lot of devices in our PCs are ready to accept new firmware at any moment. There usually are no safeguards that I can enable to prevent malicious code being injected to core components like BIOS, CPU microcode, HDD, DVD...
Now, in general, hardware security is a tricky concept, because currently the hardware layer is simply fully trusted.
Ok, good counterargument, but I still suspect that the amount is extremely low outside the main developer team.
The romantic vision of hackers around the world sitting comfortably next to a fireplace with a ThinkPad and browsing source code in the evening is just a fantasy...
I think the big issue with the Heartbleed bug was that the OpenSSL code base was so egregiously poorly written and maintained that eyeballs started bleeding whenever they looked at it. imo, the OpenSSL code base never had enough eyeballs looking at it to make its bugs shallow. It was painful to look at, so eyeballs avoided looking at it.
That's really just speculation.
So let's everyone ask ourselves this question: how many times do we personally browse open source code, looking for vulnerabilities or other bugs?
Let me guess that the answer is: I mostly run precompiled binaries, and might rarely take look at a particular small piece of code to solve a specific problem (which I came across by running the binary).
I suggest that it just is likely that most OSS projects are like OpenSSL: only the core developers take a look at the codebase.
My solution is that instead of relying on Linus's Law, we should be more thinking about dedicated professional code audits, because those actually work and can be really powerful in improving security. Big commercial shops like Microsoft and Apple already do this in spades internally as part of their QA procedures.
Daz Loader does not work even with many Windows 7 installations if they are using an UEFI/GPT setup.
C++ and Ada are geezer languages for unemployable old dinosaurs. Rust is hipster hotness, bitch. You know it or you don't get paid. Ever again.
Are there actually Rust jobs already?
Open source is neat, huh? Sure, would be nice if Source 2 were, you know, open source.
Sure, and it would be nice if it was Christmas every day.
But...tadadadattataa! Tim Sweeney to the rescue! Unreal Engine 4 is fully open source if you really need an engine that you can modify all the way down to the hardware abstraction layers.
I'm not sure if the Windows NTFS driver is not terribly portable either...probably would need a lot of work to make it work with the Linux block layer.
But anyway, there's better SSD TRIM support in Windows: vectorized TRIM ranges, and TRIM integration also with volume level commands.[1]
Then there is GPU driver in userspace, which is a nice concept, although not portable really.
But Windows and Mac use a similar system (Service Host and LaunchD).
Who wants to download buggy, ugly, insecure stuff?
That's popular among Linux guys... ;)
Which algorithms are we talking about?
I get the same quote.
That's like saying that a Torrent site lives on after its death, through people sharing the Magnet links.
If you don't believe them ask NoSteam. The DRM comes off easily.
The fact still remains that I have to rip off the DRM myself. Instead I want to buy a product that directly suits my needs, if I'm paying money for it.
Another fact is that by buying from Steam, I am voting with my wallet and saying "I am fine with DRM".
That seems to be actually true.
Nah, that's just a normal tree view widget.
Right, so 365 will get ODF support, just like the previous three desktop versions of Office got. Did anyone wind up using the ODF support before? Not that I have heard. What will be different this time? It will not push people any further to open standards if it's just an optional feature to save the document in.
You are correct about Microsoft Money, but Explorer does not use MSHTML.DLL or SHDOCVW.DLL anymore.
I hear that every time when the issue comes up, but no one still has undisputably proven what those DLLs are and what applications actually need them.
So what? People here are still talking like it's a new thing being introduced to Office, while the support has been there for well over half a decade. Here is even a Slashdot announcement from 2009.