Today’s post was written by Gaurav Sareen, Corporate Vice President for Microsoft.

We are excited to bring Skype calling to Alexa devices, so users can easily communicate with their friends and family from their Echo devices, simply using voice.

Users can make outgoing Skype voice and video calls, accept incoming Skype calls, and even make SkypeOut calls to most phone numbers around the world. For example, simply say, “Alexa, call Jimmy on Skype,” or if Jimmy is calling you on Skype, say, “Alexa, answer.”

Alexa users will soon be able to take advantage of the high-quality Skype network across the globe to easily connect with others from any device type such as PC, mobile phone, and Xbox.

This is the next step in the collaboration between Microsoft and Amazon to deliver delightful customer experiences through voice, which began with joining Cortana and Alexa. Since then, we’ve added Alexa integration on Xbox and are continuing to work together to bring the best of Skype and Alexa together to enable intelligent communications for our users.

We’re excited to continue bringing the best of Microsoft and Amazon together.

Skype calling on Alexa will begin rolling out later this year. Feel free to share your feedback and get the latest news and tips by following us on Twitter, Facebook, and Instagram. Also, please join us in the Skype Community.

At Node+JS Interactive, attendees collaborate face to face, network, and learn how to improve their skills with JS in serverless, IoT, and more. Stephanie Evans, Content Manager for Back-end Web Development at LinkedIn Learning, will be speaking at the upcoming conference about building a secure ecosystem for Node.js. Here she answers a few questions about teaching and learning basic security practices.

Linux.com: Your background is in tech education, can you provide more details on how you would define this and how you got into this area of expertise?

Stephanie Evans: It sounds cliché, but I’ve always been passionate about education and helping others. After college, I started out as an instructor of a thoroughly analog skill: reading. I worked my way up to hiring and training reading teachers and discovered my passion for helping people share their knowledge and refine their teaching craft. Later, I went to work for McGraw Hill Education, publishing self-study certification books on popular IT certs like CompTIA’s Network+ and Security+, ISAAP’s CISSP, etc. My job was to figure out who the biggest audiences in IT were; what they needed to know to succeed professionally; hire the right book author; and help develop the manuscript with them.

I moved into online learning/e-learning 4 years ago and shifted to video training courses geared towards developers. I enjoy working with people who spend their time building and solving complex problems. I now manage the video training library for back-end web developers at LinkedIn Learning/Lynda.com and figure out what developers need to know; hire instructors to create that content; and work together to figure out how best to teach it to them. And, then update those courses when they inevitably become out of date.

Linux.com: What initially drove you to use your skill set in education to help with security practices?

Evans: I attend a lot of conferences, watch a lot of talks, and chat to a lot of developers as part of my job. I distinctly remember attending a security best practices talk at a very large, enterprise-tech focused conference and was surprised by the rudimentary content being covered. Poor guy, I’d thought…he’s going to get panned by this audience. But then I looked around and most everyone was engaged. They were learning something new and compelling. And it hit me: I had been in a security echo chamber of my own making. Just like the mainstream developer isn’t working with the cutting-edge technology people are raving about on Twitter, they aren’t necessarily as fluent in basic security practices as I’d assumed.  A mix of unawareness, intense time pressure, and perhaps some misplaced trust can lead to a “security later” mentality. But with the global cost of cybercrime up to 600 billion a year from 500 billion in 2014 as well as the exploding amount of data on the web. We can’t afford to be working around security or assuming everyone knows the basics.

Linux.com: What do you think are some common misconceptions about security with Node.js and in general with developers?

Evans: I think one of the biggest misconceptions is that security awareness and practices should come “later” in a developer’s career (and later in the development cycle). Yes, your first priority is to learn that Java and JavaScript are not the same thing—that’s obviously most important. And you do have to understand how to create a form before you can understand how to prevent cross-site -scripting attacks. But helping developers understand—at all stages of their career and learning journey—what the potential vulnerabilities are and how they can be exploited needs to be a much higher priority and come earlier than we may intuitively think.

I joke with my instructors that we have to sneak in the ‘eat your vegetables’ content to our courses. Security is an exciting, complex and challenging topic, but it can feel like you’re having to eat your vegetables as a developer when you dig into it. Often ‘security’ is a separate department (that can be perceived as ‘slowing things down’ or getting in the way of deploying code) and it can further distance developers from their role in securing their applications.  

I also think that those who truly understand security can feel that it’s overwhelmingly complex to teach—but we have to start somewhere. I attended an introductory npm talk last year that talked about how to work with dependencies and packages…but never once mentioned the possibility of malicious code making it into your application through these packages. I’m all about teaching just enough at the right time and not throwing the kitchen sink of knowledge at new developers. We should stop thinking of security—or even just security awareness—as an intermediate or advanced skill and start bringing it up early and often.

Linux.com: How can we infuse tech education into our security practices? Where does this begin?

Evans: It definitely goes both ways. Clear documentation and practical resources right alongside security recommendations go a long way towards ensuring understanding and adoption. You have to make things as easy as possible if you want people to actually do it. And you have to make those best practices accessible enough to understand.

The 2018 Node User Survey Report from the Node.js Foundation showed that while learning resources around Node.js and JavaScript development improved, the availability and quality of learning resources for Node.js Security received the lowest scores across the board.

After documentation and Stack Overflow, many developers rely on online videos and tutorials—we need to push security education to the forefront, rather than expecting developers to seek it out. OWASP, the nodegoat project, and the Node.js Security Working Group are doing great work here to move the needle. I think tech education can do even more to bring security in earlier in the learning journey and create awareness about common exploits and important resources.

Learn more at Node+JS Interactive, coming up October 10-12, 2018 in Vancouver, Canada.

Have you used the top utility in a terminal to see memory usage on your Fedora system? If so, you might be surprised to see some of the numbers there. It might look like a lot more memory is consumed than your system has available. This article will explain a little more about memory usage, and how to read these numbers.

Memory usage in real terms

The way the operating system (OS) uses memory may not be self-evident. In fact, some ingenious, behind-the-scenes techniques are at play. They help your OS use memory more efficiently, without involving you.

Most applications are not self contained. Instead, each relies on sets of functions collected in libraries. These libraries are also installed on the system. In Fedora, the RPM packaging system ensures that when you install an app, any libraries on which it relies are installed, too.

When an app runs, the OS doesn’t necessarily load all the information it uses into real memory. Instead, it builds a map to the storage where that code is stored, called virtual memory. The OS then loads only the parts it needs. When it no longer needs portions of memory, it might release or swap them out as appropriate.

This means an app can map a very large amount of virtual memory, while using less real memory on the system at one time. It might even map more RAM than the system has available! In fact, across a whole OS that’s often the case.

In addition, related applications may rely on the same libraries. The Linux kernel in your Fedora system often shares memory between applications. It doesn’t need to load multiple copies of the same library for related apps. This works similarly for separate instances of the same app, too.

Without understanding these details, the output of the top application can be confusing. The following example will clarify this view into memory usage.

Viewing memory usage in top

If you haven’t tried yet, open a terminal and run the top command to see some output. Hit Shift+M to see the list sorted by memory usage. Your display may look slightly different than this example from a running Fedora Workstation:

There are three columns showing memory usage to examine: VIRT, RES, and SHR. The measurements are currently shown in kilobytes (KB).

The VIRT column is the virtual memory mapped for this process. Recall from the earlier description that virtual memory is not actual RAM consumed. For example, the GNOME Shell process gnome-shell is not actually consuming over 3.1 gigabytes of actual RAM. However, it’s built on a number of lower and higher level libraries. The system must map each of those to ensure they can be loaded when necessary.

The RES column shows you how much actual (resident) memory is consumed by the app. In the case of GNOME Shell, that’s about 180788 KB. The example system has roughly 7704 MB of physical memory, which is why the memory usage shows up as 2.3%.

However, of that number, at least 88212 KB is shared memory, shown in the SHR column. This memory might be, for example, library functions that other apps also use. This means the GNOME Shell is using about 92 MB on its own not shared with other processes. Notice that other apps in the example share an even higher percentage of their resident memory. In some apps, the shared portion is the vast majority of the memory usage.

There is a wrinkle here, which is that sometimes processes communicate with each other via memory. That memory is also shared, but can’t necessarily be detected by a utility like top. So yes — even the above clarifications still have some uncertainty!

A note about swap

Your system has another facility it uses to store information, which is swap. Typically this is an area of slower storage (like a hard disk). If the physical memory on the system fills up as needs increase, the OS looks for portions of memory that haven’t been needed in a while. It writes them out to the swap area, where they sit until needed later.

Therefore, prolonged, high swap usage usually means a system is suffering from too little memory for its demands. Sometimes an errant application may be at fault. Or, if you see this often on your system, consider upgrading your machine’s memory, or restricting what you run.

Photo courtesy of Stig Nygaard, via Flickr (CC BY 2.0).

Video

By Andrew O’Hara
Wednesday, September 19, 2018, 05:04 pm PT (08:04 pm ET)

To go alongside the latest iPhones — the XS and XS Max — Apple has updated its lineup of first-party cases, which include leather, silicone and folio options. AppleInsider goes hands-on with the accessories to see what has changed and find out if they are compatible with the iPhone X.

[embedded content]

All of Apple’s cases are great quality while staying minimalist in nature. They are thin, with tactile buttons and made from premium materials. The leather cases all utilize anodized aluminum buttons on the sides, always a nice touch. Interiors are lined with microfiber on each case, protecting the iPhone from loose debris.

On the underside, the bottom of the phone is exposed, a design that has its pros and cons. We prefer this design as it allows easier access to ports and works seamlessly with many docks, but at the same time it opens more of the phone up to possible damage.

Last year, the folio was exclusively available for the iPhone X, but this year it comes in two different sizes for the XS and XS Max.

Colors for everyone

Externally, the biggest change to all of the cases is a smattering of new colors.

Silicone cases now come in Nectarine, Lavender Gray, Blue Horizon, Stone, Pink Sand, Midnight Blue, White, Black, and (PRODUCT)Red while the leather case will be available in Peony Pink, Cape Code Blue, Forest Green, Taupe, Midnight Blue, Saddle Brown, Black, and (PRODUCT)Red. The leather folio comes in Peony Pink, Cape Code Blue, Forest Green, Black, (PRODUCT)Red.

Changes between X and XS cases

Notable changes between last year’s cases and the models offered in 2018 include slight tweaks to the camera bump cutout. The latest iPhone’s have a slightly larger camera bump, which could cause compatibility issues when using the new cases with iPhone X. If you put any of Apple’s iPhone XS cases on an iPhone X, you will notice a slight gap around the otherwise precision-designed case.

There are also changes to the arrangement of the Hall Effect sensors between generations. The auto wake/sleep functionality doesn’t work when using the iPhone XS folio on the iPhone X, and vice versa.

Where to buy

Right now, the cases are available exclusively through Apple. Silicone cases cost $39 and the leather run $49. If you’d like the leather folio, it runs $99 and $129 for the iPhone XS and XS Max, respectively.

Apple’s cases not doing it for you? Check out AppleInsider’s roundup of excellent iPhone XS and XS Max cases that are available now.