Hacker News Reader

Comment by haddr | Hacker News Reader

Skype on Linux is far inferior recently. Mostly due to the fact that the Linux version has been somehow abandoned. It haven't received updates since at least 1 year. For example, one recent change is that when someone sends a picture, on Linux you are sent a link to it, where you have to go to the Skype website and login in order to view it (and login each time you open a link). Sometimes it's a resized version of the picture which makes things worse. Another thing is the screen sharing. On Linux you can't share screen with more that 1 person, making it useless for telcos at work. And there is much more...

View on HN

>Another thing is the screen sharing. On Linux you can't share screen with more that 1 person, making it useless for telcos at work. And there is much more...

Consider yourself lucky, for me screen sharing doesn't seem to work at all.

I gave up on Skype screen sharing forever ago. Even with good connections it would pixelate and distort to being illegible too often.

I, frankly haven't found Hangouts much better. We've all but given up on them and use a combo of a free-ish conference app like Uber Conference and Join.Me, Slack, and FaceTime for audio. Except for the one guy with Android, that I then wind up actually having to call from my phone. Ugh, who wants to use a phone these days?

I've switched from Linux to OS X 3 years ago, and even then Skype on Linux was considered abandonware and far inferior to the other OS's versions. It's sad to see it doesn't seem to get any better.

In the end to the end user "linux sucks" because skype sucks on linux.

Maybe that is intentional in this case.

most of the people I know, regardless of what platform they use seem to think that skype sucks. especially if they tried to use it on their mobile phones. We all put up with it because there are no real competitors, and the open source alternatives are all pretty lacking as well

tbf maintaining anything proprietary under linux is a chore, with the ABI changing every year for no reason and yet having to support users having all kind of version combinations. I can see how a company would hate devoting that much resources for pleasing a smaller user base.

> with the ABI changing every year for no reason and yet having to support users having all kind of version combinations.

What? That is simply not true, the Kernel never breaks userspace. And "version combinations" are solved by linking statically.

gnome breaks userspace, kde breaks userspace etc. skype is not just linked against the kernel after all, but a whole lot of different components

Gnome and KDE run in userspace. They are desktop environments, they don't "break userspace".

I feel like you're talking about GTK and Qt, both of which (don't break userspace either) are libraries you can statically link and nothing will break.

they both break library compatibility and break their environment (like when kde removed the widget toolbar and a whole lot of app suddenly stopped working)

sure you can have bunch of ifdef in the code, and an autoconf, and make sure you support a wide set of options, but that is basically the whole point, it makes for a painful experience and costlier, slower development (for closed source application that comes prepackaged)

I feel like you do not understand the concept of static linking, because the entire point is that you don't need a bunch of ifdefs, since you target exactly the version you develop against and ship with it.

the example I gave is exactly how stuff has broken in projects. static linked on a kde library that had widget, new one doesn't have that nor a fallback, application crashes.

or just go get some old static compiled stuff run on your modern distro and see yourself. like, mindrover the europa project port.

This will be my last reply.

> static linked on a kde library that had widget, new one doesn't have that nor a fallback, application crashes.

As I said before, please read up on what static linking means.

> like, mindrover the europa project port.

    $ file Mindrover\ The\ Europa\ Project\ DEMO\ r1-lgp-x86.run 
    Mindrover The Europa Project DEMO r1-lgp-x86.run: ELF 32-bit LSB executable,
    Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2,
    for GNU/Linux 2.6.15, BuildID[sha1]=fe926b7ea13be61d05cdd605e313f50042040153, stripped

...version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2...

    $ ldd Mindrover\ The\ Europa\ Project\ DEMO\ r1-lgp-x86.run 
	linux-gate.so.1 =>  (0xf7722000)
	libglib-2.0.so.0 => not found
	libz.so.1 => not found
	libfuse.so.2 => not found
	librt.so.1 => /lib32/librt.so.1 (0xf7700000)
	libdl.so.2 => /lib32/libdl.so.2 (0xf76fb000)
	libpthread.so.0 => /lib32/libpthread.so.0 (0xf76dd000)
	libc.so.6 => /lib32/libc.so.6 (0xf7525000)
	/lib/ld-linux.so.2 (0x5660a000)

Clearly not a statically linked binary.

Don't waste your time, they don't know what they're talking about. I've found most people that complain about ABI breakage usually don't.

Completely off topic but thank you ! I was starting C programming and I was wondering how to check an executable dependencies. If I were to package an executable which was dynamically linked to use it on another computer without recompiling binaries, how could I proceed ? does ldd show the dependencies of the dependencies too ? Would it be sufficient to put all shared libraries into the same folder as the executable ? thanks.

I think ldd should show this, not sure though. And you can't just put them in the same folder, the thing you want to look up is LD_LIBRARY_PATH.

Even better, one can embed the relative path to dynamic libraries by editing the RPATH or RUNPATH attributes in the binary (and using $ORIGIN in the path). Check out chrpath and patchelf.

The problem is services and non-ABI/non-library APIs. The way I suspect that this is set up is that there is precisely one KDE widget displayer service at any given time, running as part of the desktop environment and presenting an IPC interface that widgets talk to to get themselves added to the widget display area that the window manager maintains. You can link statically to the KDE widget client libraries all you want; if the KDE widget server decides to change the language it speaks, your widgets are hosed unless you included a not-a-widget mode that makes it a normal window. Seeing as how widgets tend to have special build systems (or, worse, the widget server is actually an interpreter for a declaration-heavy widget definition language that's not strictly plaintext), I don't think I've ever seen a widget with a non-widget mode supported.

"Breaking userspace" probably is a misnomer, if only because userspace has a precise technical definition. This is more like changing an interpreted language without maintaining backwards compatibility (python3, anybody?) or changing a json API.

While that may very well be true I feel like this doesn't have much to do anymore with:

> with the ABI changing every year for no reason and yet having to support users having all kind of version combinations.

To which I originally replied. And my point here still stands. I'm not arguing about the backwards or forward compatibility of every single library that might or might not use an IPC mechanism to talk to another component which could break if they're different versions.

> maintaining anything proprietary under linux is a chore, with the ABI changing every year for no reason

Is Skype a special snowflake to the extent that it's an impossible task? Skype-on-Linux's problem are caused by interface changes with the server API, not the ABI. Recompiling isn't rocket science.

recompiling isn't. packaging for every distribution, edge and not and building autoconf for all of them and ifdef all over the code?

not rocket science either, but that stuff does carry an increased cost

More and more companies are just publishing their repos for Debian/Ubuntu/RHEL/CentOS/Fedora/SuSE, which are built automatically from same source. If you have a problem with that, hire a developer.

Static linking would solve this. You end up with a bigger application and have to do updates every time a library needs a security patch. But you have this anyway if e.g. you release a python application on Windows.

Traditionally, the distros do the packaging on their own. I've seen this happen plenty with proprietary software (which will often release a single deb or rpm from which the other distros make their own packages).

if abi changes keep breaking things, how come skype keeps working even though microsoft barely ever updates it? For a while we were still on version 2, until microsoft decided to break the server protocol, but that version ran for ages without any updates.

Reply on news.ycombinator.com