Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

Bass Bass I need better writers.
  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , ScanIAm wrote

    When the product is written by the same company that made the OS?  Closed source in that case will always have an advantage.

    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.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , spivonious wrote

    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.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    @spivonious:

    MapReduce.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , RealBboy360 wrote

    Yeah, I know some things are better in some situations and nosql is probably more scalable, but could this reverse the trend of everyone going to mongodb or whatever?  The only enterprise part is no fun though.

    MongoDB's primary advantage is that it is schema-less and uses JavaScript and JSON (BSON), which tends to also be the kind of data organization web applications often use tons of.

    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.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    Redis.

  • Heartbleed

    , blowdart wrote

    *snip*

    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.

    http://www.latinpost.com/articles/10440/20140411/heartbleed-bug-discovered.htm

    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.

  • Heartbleed

    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.

  • Heartbleed

    , evildictait​or wrote

    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.

  • C#/XAML vs. WinJS/HTML

    , contextfree` wrote

    WinJS and phonegap aren't mutually exclusive, you can use them together. They talk about this in the Build WinJS sessions.

    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.

  • C#/XAML vs. WinJS/HTML

    , exoteric wrote

    *snip*

    Have you considered that the aim here is neither to facilitate cross-platform development nor to make an implicit statement about the suitability of Javascript as a development language for large scale programs - but rather to empower developers with Javascript skills to develop for Windows?

    TypeScript was also invented to facilitate large scale application development for the Web - but is also being used for Windows application development.

    Yeah but um, writing JS apps hard coded to Windows only makes sense if ignore Android and iOS, which trust me nobody outside of Channel9 is doing. JavaScript developers can always use PhoneGap, Titanium or any other more mature and highly cross-platform framework and not waste time writing code that can only work one relatively obscure part of the market. It lets you write a mobile app once and without changing a single line of code run it on EVERY COMPUTING DEVICE EVER (PS: including Windows 8).

    WinJS is not a special snowflake when it comes to writing Windows apps in JavaScript. There are popular alternatives. And they work on Android and iOS. The same code you write for your Windows Store app, will also work for your Google Play app and iTunes Store app. Line for line. Let that sink in.

    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. 

    [Tangent: PhoneGap apps are not technically web apps. They are native applications. A PhoneGap application is compiled into native binary that simply calls into JavaScript.. Thus, they are capable of doing anything a native application for that platform can do. Of course, there is also a broad common API that maps pretty much anything you need to the platform's specific API for doing it. I understand that Windows has a special "JS executable" format for the store, but it's possible and likely that PhoneGap apps submitted for the Windows store would show up as C++ applications.]

    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.