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: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.