Microsoft Releases Skype As a Snap For Linux (betanews.com)

BrianFagioli writes: While Microsoft has long been viewed as an enemy of the Linux community -- and it still is by some -- the company has actually transformed into an open source champion. One of Microsoft's biggest Linux contributions, however, is Skype -- the wildly popular communication software. By offering that program to desktop Linux users, Microsoft enables them to easily communicate with friends and family that aren't on Linux, thanks to its cross-platform support. Today, Microsoft further embraces Linux by releasing Skype as a Snap. This comes after two other very popular apps became available in Snap form -- Spotify and Slack.

"Skype is used by millions of users globally to make free video and voice calls, send files, video and instant messages and to share both special occasions and everyday moments with the people who matter most. Skype has turned to snaps to ensure its users on Linux, are automatically delivered to its latest versionupon release. And with snaps' roll-back feature, whereby applications can revert back to the previous working version in the event of a bug, Skype's developers can ensure a seamless user experience," says Canonical.

Comments

Re:I've been out of the Linux loop for a few years

[Anonymous Coward]

Snaps are containerised software packages that are simple to create and install. They auto-update and are safe to run. And because they bundle their dependencies, they work on all major Linux systems without modification.

https://snapcraft.io/

Irresponsible Word Choice

[scunc]

Skype is a "wildly popular communication software" in the same way that chlamydia is a "wildly popular" STI. Sometimes numbers alone don't tell the whole story ...
---
"Think of how stupid the average person is, and realize half of them are stupider than that." -- George Carlin

Re:Irresponsible Word Choice

[ArhcAngel]

Skype for Business != Skype

Oh hurray...

[Junta]

Now when a security update comes for a core library, now I get to update every single snap instead of just updating the system library...

Yay for static linking, I mean containers....

Re:I've been out of the Linux loop for a few years

[110010001000]

What makes them "safe to run"? Is the software that they run in the container open source and can be inspected? If not, how do you know it is "safe to run"?

Champion?

[Anonymous Coward]

" the company has actually transformed into an open source champion"

Really? So Skype is being released as an open source app? No. Windows is being released as an open source OS? No. Microsoft has agreed to stop using patents and fear mongering to extract money from companies using open source software? No.

So Microsoft is actively working against open source companies and is not releasing its software under open source licenses. How exactly is Microsoft an open source champion?

Re:Tried using Skype on Linux

[Trailer Trash]

Debian to be specific. It would not work with my friends who use the Windows version of Skype.

You have friends who..... use Windows?

A shitty replacement for static linking?

[Anonymous Coward]

In the early days of microcomputing, we used static linking when creating an application binary. The code we wrote would be linked against any third-party libraries, and a single binary containing the application code and the library code would be the result. Life was easy.

Then there was this huge push toward dynamic linking, with its proponents going on about how it's supposed to use less memory, it's supposed to use less disk space, and it's supposed to allow libraries to be updated easily, and so on and so forth.

But then we experienced "DLL hell" or the "shared object shitshow", which turned out to be far worse than anything we experienced with static linking.

So workarounds, like the various Linux package managers, were created to try to handle the complex dependencies between applications and their shared libraries. This is effectively a complex form of static linking, done by keeping shared library versions consistent with the installed applications.

When that proved to be problematic, such as when there were different applications that depended on different versions of the same shared library, we started seeing a move toward this "containerization" nonsense. There are different approaches used, but again they all have one thing in common: they're a complex way of imitating static linking.

I hope that someday soon the industry at large wakes up to the fact that static linking is just the most sensible thing to do. Yes, the binaries might be slightly larger, but that's well worth it if it means we can avoid "DLL hell" or the "shared object shitshow", and if we can avoid complex package managers, and most important of all, if we can avoid this goddamn "containerization" bullshit.

Now there may be problems when it comes to certain libraries, because they use highly restrictive licenses like the LGPL that effectively force the use of dynamic linking if you don't want your code to be infected by a viral license. The solution to this is simple: don't use poorly licensed libraries. Stick with libraries that use static-linking-friendly licenses like the MIT or BSD licenses, for example.

A whole lot of problems would be solved if we stopped with all of this dynamic stupidity and just went back to static linking.

Re:A shitty replacement for static linking?

[tlhIngan]

When that proved to be problematic, such as when there were different applications that depended on different versions of the same shared library, we started seeing a move toward this "containerization" nonsense. There are different approaches used, but again they all have one thing in common: they're a complex way of imitating static linking.

I hope that someday soon the industry at large wakes up to the fact that static linking is just the most sensible thing to do. Yes, the binaries might be slightly larger, but that's well worth it if it means we can avoid "DLL hell" or the "shared object shitshow", and if we can avoid complex package managers, and most important of all, if we can avoid this goddamn "containerization" bullshit.

Now there may be problems when it comes to certain libraries, because they use highly restrictive licenses like the LGPL that effectively force the use of dynamic linking if you don't want your code to be infected by a viral license. The solution to this is simple: don't use poorly licensed libraries. Stick with libraries that use static-linking-friendly licenses like the MIT or BSD licenses, for example.

A whole lot of problems would be solved if we stopped with all of this dynamic stupidity and just went back to static linking.

No, because dynamic linking, even with non-shared shared libraries is still better. Static linking hides important information like library versions which may be important.

With dynamic libraries, even inside containers, you can still validate the library version to see if it's a vulnerable library. You can run tests against the library to determine if it's vulnerable (just because it's inside a container doesn't mean you can't extract it and test it). This way when a vulnerability happens, you can verify whether or not the copies of the libraries you have are vulnerable since a scanner can go inside containers and check. Users can then either not use the app until it gets an update with a fixed library, try to fix it themselves by replacing the library, use the app understanding its vulnerable, etc.

When you static link, you lose those benefits - for what? Just to have one file? That's not going ot happen ever - it's why we have containers to begin with.

No "champion" at all.

[l2718]

From TFA:

[Microsoft] has actually transformed into an open source champion

Really? So shere is the source code for this "snap"? In fact:

1. Compiling your software for GNU/Linux doesn't make you a "champion of open source" just because GNU (and Linux) are open-source (and, more importantly, also Free Software). Releasing your source code makes you open-source.
2. "Snaps" are the opposite of the Unix philosophy of dynmically linking against system libraries – they are basically statically linked binaries (except that the binary comes in pieces). Instead of the "open-source" philosophy of clean interfaces and interoperability, they embrace a philosophy of tailored interfaces and closed gardens.

In fact, to the extent Microsoft champions "open source", this open-source is about taking advantage of source code released by others without Microsoft releasing any of its own. When I see Microsoft releasing source code under a free license (say BSD) for a significant program originally created by Microsoft (Skype, their web browser) I will believe them.

Re:I've been out of the Linux loop for a few years

[duckintheface]

This particular snap install is NOT safe to run. When you run "snap install skype" in a terminal you get a warning that skype is packaged using "classical" isolation and may escape the sandbox and make unrelated system changes. In order to install, you have to add the --classic flag to indicate you understand the risks. I did not install skype.

Sabotage

[Gavagai80]

As someone who actually uses Skype for Linux, I can say definitively that it's a torture device meant to make Linux users experience excruciatingly unpleasant interfaces, Windows ME stability, Windows Vista levels of bugs, and pointless slowness for what is actually no more than a frame around a website. The Skype for Linux from before MS bought it was a far better, more feature-full and reliable product... since the MS purchase it has only been progressively sabotaged. The several years it went without an update were nice, but ever since updates resumed it gets more painful in each release.

"Fully embraces linux"??

[l2718]

In fact, this is Microsoft trying to support a dangerous undercurrent in the Linux world of walled gardens and insecure vendor-controlled installations.

If something is wrong in libc, libm, or libgtk Microsoft should get it fixed upstream, not ship their own incompatible version. Do you really trust them to backport every future bugfix after their fork?

Re:Wow!

[gfxguy]

I've been using Linux since slackware c. 1994. I actually have come to appreciate some of the things MS has done w.r.t. Linux - running a development web server under WSL makes my life a lot easier when I have to use Windows for most things anyway. Their development tools are actually really nice, too; the .Net system of being able to write interchangeably between different languages is not perfect, but works really well for most of my Windows development.

Yet, the marketing speak is absurd.

Just What I'm Looking For

[NicknameUnavailable]

An IM client which spies on me and logs all my conversations for Microsoft without so much as a decent search function for me to view my own archives. There's no reason to use Skype outside of a business environment where you have to do so, there are plenty of open source alternatives and there are plenty of more popular things if you can't get your friends to switch.

Re:Open source champion?

[Anonymous Coward]

MS has been one of the largest contributors of open source projects and applications over the past few years. MS has been positioning themselves to transforming their flagship OS and related applications to a true cross platform solution. Think about all those people and companies that cannot move to a Linux platform due to the lack of Linux application support. No think of signing into your computer and being able to start a Windows session or Linux session without any intervening VM. Think about a version of .NET that is open source and cross platform. The number one rule in capturing a large market share is to make it easy for developers to create applications. It's a lesson the Linux fateful have never really understood. MS has always catered to the developers. MS VB was probably the one product that pushed MS to the top. VB allowed almost anyone to become a developer. VB was certainly not a perfect development tool but it was easy compared to C\C++ or any other native languages that the average person could not use. VB allowed the rapid creation of applications that ran on the MS application stack. (VB had a lot of faults. People created a bunch a sup-par applications. These two characteristics didn't stop the adoption of VB and all the subsequent adoption of a pure MS application stack.)