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

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:Irresponsible Word Choice

[thegarbz]

Sure. If every other person also has chlamydia then your comparison would be accurate. On the desktop Skype is the single most popular video chatting app. What you personally think about it doesn't change that fact or doesn't change the fact the word choice is perfectly fine.

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.

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