So the Microsoft Windows team and SQL team are working together to give their DB an advantage over 3rd party DBs on Windows? Interesting. I think some investigators over in the European Union and US Department of Justice could use some more information.
Absolutely. The need for NoSQL came about from Google and Facebook handling terabytes of data. But web programmers seem to be jumping all over MongoDB even for tiny datasets. Part of me wants to think that it's because they're too lazy to learn SQL and want to do everything in JS. A good, well-setup RDBMS can be extremely fast and efficient.
Yup, I believe that's 99% of the reason to use MongoDB. Most people never run into the scaling issues of SQL because they work with "small" datasets (which I will define something less then Google). So the reason most are using MongoDB is indeed, due to laziness and a desire to avoid SQL. By the way, laziness is one of the principal virtues of a good developer.
It's also really fast and web scale. SQL is not web scale. But seriously, that video is criticizing a really old version of MongoDB that didn't support journaling.
You can still turn it off of course! Without journaling, MongoDB will write to memory, and only write to disk when it is optimal to do so. If MongoDB or the server it is running from crashes, you will likely lose some data.
It wouldn't be MongoDB without supporting probabilistic durability and consistency. Because you know there is still a decent chance that your data will be stored even without enabling full durability, and writes especially will be noticeably faster if you disable it. Not every application the planet needs 100% durability all the time, especially when there is a massive unavoidable cost in overall performance for that guarantee.
Not true. It wasn't discovered by code reviewing but by testing of the binaries, black box testing, as you would also do with closed source.
According to Karjalainen, he and Hietamäki were testing some new features for Codenomicon's protocol test suite with a feature called Heartbeat, which sends data between servers to see if it comes back unaltered.
Fair enough. You can also audit proprietary code directly (well, not the original code, that's not available) using various debugger/disassembler tools.
Maybe I shouldn't have went that far - open source makes it easier to independently audit someone else's code. And possibly, in various jurisdictions where reverse-engineering is may be illegal or at least a gray area, allows you to do it legally.
Yeah, but.. the only reason this vulnerability was discovered is because OpenSSL is open source.
So the whole open source is inherently more secure comes from Linus's law. But there is an "axiom" that must apply first:
"given enough eyeballs, all bugs are shallow"
The key is "given enough eyeballs". Short of the really big open source projects, there is only a handful of people who are both qualified to review the code and willing to. Or restructuring this statement, all bugs are not shallow, unless the FOSS project has enough eyeballs. Therefore, it is not a statement on the quality of FOSS in general. Rather it is a statement that the correctness of a software system is dependent on a variable linked positively to the # (and arguably, the "quality") of the eyes looking at it.
But that doesn't even require FOSS necessarily. Right? Because you know, Microsoft can hire a metric ton of high quality eyes to look over their code. If they do this, under Linus's law their bugs will be shallow. I don't disagree with this. I think Linus's law is pretty reasonable, it's just that people have been reading and extending it incorrectly.
So what is something that we can claim is a characteristic of FOSS that doesn't exist in proprietary systems when it comes to security and bug fixing?
At the basic level, open source allows (but does not guarantee) the existence of independent review of other people's original code, even without informing the original author's first. Proprietary software well, does not. It's just fact. Maybe that's what should be been made into a law. I call it Bass's law.
The security of a product has nothing to do with whether it is open or closed source. It has everything to do with whether you use secure programming practices when you write and test your code.
Also heartbleed is, whilst quite serious and needing to be urgently patched, not any more or less serious than a whole ton of other bugs that come out in any given year.
Remember the YAML deserialization bug which was RCE against a fairly large fraction of the Internet? Or the web.config padding oracle that was RCE versus most IIS installs? Or how about the MS-0867 bug, which was RCE against basically any Windows machine at the time.
You could have used any of those bugs to take SSL private keys and userdata from a webserver, and considerably more.
And that's before we even go into vulnerabilities that are functionally equivalent to Heartbleed, but without the same level of media-fueled hysteria - like the Debian random bug, Apple's goto fail and CVE-2011-4315 which is identical in behavior to the heartbleed vulnerability but affecting just nginx instead of all of OpenSSL.
RCE in a web server? Bleh. Web servers will be web servers. I think a lot of hysteria comes from the fact that the bug is in an SSL library, who's entire purpose to some extent is to provide security. Security hole in a security library? That's scandalous. Especially when compounded with all the latent hysteria over the months from you know what.
If we can't have a bug free SSL implementation, what can we trust? Also that it has a cool name and even its own hipster-approved logo and Bootstrap web site. Who can get excited over something named CVE-034984785474-3-3083e78wehhd7sce in some government database?
Although to be fair, maybe people should start getting excited over things like these. Heartbleed (aka. CVE-2014-0160... :) ) was one of the best marketed security vulnerabilities ever. There is a lot of the security community could learn from that.
Part of their strategy to make WinJS relevant. And it's possible that people will use hybrid approaches, but it's also possible they'll just ignore WinJS entirely because well you don't need it at all.
TypeScript was also invented to facilitate large scale application development for the Web - but is also being used for Windows application development.
Let that sink in.
Nobody had any real incentive to use WinJS for this reason. Which is of course why Microsoft open sourced it - they had no real other choice except allow it to languish in obscurity. Now, WinJS being open source is no guarantee that it will be successful. Because well... YOU CAN STILL USE PHONEGAP.
Now that WinJS is open, it is possible that some community will form around WinJS and they'll port it to other platforms and even allow some subset to run entirely in a web browser. But still.. well... you can still use PhoneGap. It already does this.
There is nothing all that magical Microsoft is providing in WinJS, and even if they had something, they'd still have to overcome a ton of developer experience and inertia around PhoneGap and friends.
But there is at least some hope now that WinJS will be competitive.
Notice the date. I have a pretty good track record of calling these things in advance. Maybe working for Gartner is my calling.
TLDR: Single-platform JS is stupid and virtually nobody does it. Look up PhoneGap.