 to the intro. And that is news for January 2016. So, current versions of Nodal are these. So, please just make sure that, I don't know, I always find it interesting that I don't update my Nodal that often. And it's usually like, you know, three major versions ahead. So, they're moving very fast. I'm actually not particularly aware of what the differences are here, but something that people may not be aware of is that there is an LTS version of Nodal. So, that is designed to be only accepting all of the, only accepting security and like major, major things which need to be added. It's an LTS release. It's stable. And then the stable release is also available. And the point is that this one here is for, is makes you boss happy. And this one here is probably just as fine. But really, the LTS is there because, you know, it's designed to make Nodal a better player in enterprise environments where things move a little slow. And in fact, it's like, yeah, Nodal is moving at break next week. So, it probably is a good idea to have some, some, have the LTS branch. Anyway, MPM is up to 3.54. So, again, I haven't looked into what's changed here, but make sure you update your MPM regularly, because there's new features and things break all the time. So, please keep your MPM up to date. Interesting development. Recently, Microsoft has submitted a portal request to Nodal for asking him to add support for their JavaScript engine. It's the JavaScript engine that's running in their new browser. And what this is designed to be a kind of like a drop-in replacement for VA in Nodal currently doesn't have support anywhere but Windows, only works on Windows. But apparently, the benefits here are that it's faster. And it's, I guess, adding some more diversity. How they're doing it is it's got a base. So, Shark Recall doesn't implement the same API as VA so it built like a little translation layer to make it work. It's pretty cool. It's good incentive. I'm actually, I'm very surprised that this portal request didn't work open and it wasn't just closed. We're not doing this. We're really crazy. They're very seriously considering doing this. And I think that's, it's healthy. It's showing maturity in the community. Don't check out the video shoot. There's a lot of, it's probably not going to get in the load particularly quickly because you'll notice here, it's a pretty big portal request with 4,786 files. Yeah. Probably going to take some time to wait through that. I think they kind of have like a, it's probably a little bit inflated because I think they have like full dependencies that don't copy the image. Which is a good reason. But the feedback that I've heard is that this is surprisingly clean and surprisingly good. And also this isn't the first time that Microsoft has done really important, interesting stuff contributing to Node. The split that in the day. Listen, I haven't been paid to say this. It's nice that Microsoft just made that. But they, Microsoft's wanted the split to get the health core, Bootsy. Yes, yes. Oh my God, two ones in my brain. I don't know. Libby V exists through because of the Microsoft sponsorship. So that's a, it's a cross-platform IO tool, library. So that's really cool. You may have also heard about this node loss autonomy. So the, the, the problem is that, you know, JavaScript is untied. This is not a very big example, I guess. But in this top, top case, okay. The problem is that when Node creates a buffer, it gives you, it's basically like a malloc if you're familiar with C or C++. And it just gives you a chunk, a reference to a chunk of memory. And that memory may contain anything. If you chuck in something like a string, it fills it with the, this content. But if you pass in a number, it just gives you, it allocates you a block of stuff. And it's not, it's not hard to accidentally supply a number when you're meant to pass in a string. So the difficult, the problem is is that a number of packages, oops. A number of packages have cases where there's possibilities that a number will go in instead of a string. Which means that they could be exposing completely, could be anything on the system to the, to the client. Which, you know, could include passwords or any kind of sensitive information. And in fact, if you go back to the issue, there's a, there's a number of, there's a really interesting test case that somebody has showing if you put any kind of sensitive information in your program, even if it's just a client, it doesn't take long. If you're, if you're serving up chunks of non-zeroed memory, it doesn't take long to actually leak whatever that information is. So it's a potentially problematic thing. There's been a lot of emotional responses like this. People can't believe that node would, well, why are you even, why is it even possible to serve up non-zeroed memory? But the key thing here is that node has a lot of different use cases and you don't always want to do that for performance reasons. Because the zeroing memory, as you can imagine, is being chunked in memory can take an amount of time. So the general consensus is that it's not actually a bug with node, but they could probably do something better about it. So they're looking at changing the API and they're trying to make it a little bit safer so that, because the people who, those packages that I listed before, the people who are authoring those packages aren't like beginners and they made a mistake of accidentally revealing this. So it's not necessarily a bug, but it definitely could be better. And it's also investigating the performance cost of actually just doing the zero-fill of those chunks. So I thought that was interesting. It's a really good issue to go look at. Another one. You might have seen this on Hackett News, this Express Dine, this little concern. This guide, basically the problem is that just, well, a few years ago the author of Express, Sol Express, which seems to be weird, Sol Express to Strongloop, and then Strongloop just sort of didn't do anything with it. All they did is put their branding on it and left it. Now Strongloop's been acquired by IBM and there's still a lot of uncertainty about, well, who owns the Express project? Because the main maintainer of Express, this guy, Doug Wilson, he's not even on the, he has no control over it really. There's an Express organization and then there's the Express project. Everything like, and the Express project since the version four release has been getting smaller and smaller and it's good because it's been pushing more responsibilities out to third party packages. This is a very long unusual quote, sorry. So anyway, point is, this is a great example of poor relationship between corporations and open source. You should go read that. Some choice quotes from Doug Wilson. He says, he's trying to step away from Express and he's thinking about building something different. They have something that supports HTTP too. He's saying that IBM forced him out of the repository. He doesn't want to give up on Express, but they forced him. He wants to express organization, he wants Express to be moved to the Express organization. They've been arguing about this for over a year and it's just typical glacial progress from big corporations and here we go. Express website says the Express project is sponsored by StrongLoot. It links to this repository but it's absolutely unclear to the main author how StrongLoot is sponsoring the Express project. Look at that, it's interesting. But the reality is it's Express right now. It's probably totally fine. The Express project is healthy. There's enough people out there that are invested in it that even if IBM changes it completely, you'll be fine. There'll be something which Express doesn't even do anything really anymore. It's just sort of a set of conventions. So you'll be fine. And there's also a lot of great alternatives which are very similar like COA and they're looking into this thing called PillarJS which maybe you should have been looking into. But speaking of dying projects, Meteor is finally as official support for NPM. There's an interesting thread on Happy News at the moment about this. A lot of people believe that the future of Meteor is bright. That's the end of my music. I'd like to welcome up the first reader.