@Wolfshappen hello! You had suggestions what to check last time I had problems with ssh. That time I thought that I screwed up the system and I have reinstalled it since. I think ssh worked like it should for a short period of time, but now it hangs again. Do you have any recommendations or can you remind what you said or maybe somebody else knows what to do here?

Either you debug with ssh -vv and see what happens - but it may be your connection. Do you have frequent connection failures?

Either you debug with ssh -vv and see what happens - but it may be your connection. Do you have frequent connection failures?

nope, ssh works great from macbook, also connection is quite stable

when I connect - it works very slow and eventually hangs, but on macbook it's not lagging at all at that same time

ok, my bad

when you symlink .ssh folder from somewhere - even with correct chmod it causes problems on fedora

Not really. It's not available for other Linux versions.

It is.

It is.

Yes. @Schyken already sent me a link to a flatpak package. Thanks.

?

Flatpak forever!

I don't like it. But well.

I'm finally back on my PC, haha. I absolutely suck at multitasking on my phone ?

Me too, don't worry.

when you symlink .ssh folder from somewhere - even with correct chmod it causes problems on fedora

Why would you symlink .ssh

What the hell

Flatpak forever!

s/forever/never/

No

s/forever/never/

I agre with this but Gnome Recipes uses Flatpak, and I love the app so much....

Snaps and Flatpaks are very much here, and they solve a lot of problems for a lot of people, even if they aren't currently the tried and true method yet.

Snaps and Flatpaks are very much here, and they solve a lot of problems for a lot of people, even if they aren't currently the tried and true method yet.

And cause DLL Hell.

?

There's a right and wrong way to go about it

If you build your system around it, yes.

But to install things like Discord or Telegram, it's not going to break your system.

Flatpak is good only for proprietary software. OSS must be packaged as regular.

That's just not how it works

But to install things like Discord or Telegram, it's not going to break your system.

Telegram Flatpak built against Ubuntu libraries and they all are bundled into that Flatpak. Use RPM from RPMFusion instead.

Telegram Flatpak built against Ubuntu libraries and they all are bundled into that Flatpak. Use RPM from RPMFusion instead.

And?

And?

No system shared libraries => no sharedmem support and very old versions.

The entire point is that it has the necessary components it requires to run consistently, regardless of the host.

Also, keep in mind it's still very much a WIP

No system shared libraries => no sharedmem support and very old versions.

if they share the same runtime they do, and most apps are on the same runtime

Is there an updated Telegram on rpmfusion?

if they share the same runtime they do, and most apps are on the same runtime

No. Telegram Flatpak use bundled into this fp Ubuntu libraries. All Ubuntu libraries.

Is there an updated Telegram on rpmfusion?

I'm maintainer of it. Yes, it was updated 4 days ago.

Thank you!

http://koji.rpmfusion.org/koji/packageinfo?packageID=492

But I don't know when Kwizart will push updates to stable repositories.

The entire point is that it has the necessary components it requires to run consistently, regardless of the host.

But guess what, unless you run a very specific ubuntu version this will not be the case.

That

is

not

?‍♂️

Every app will fill your ram with previously preloaded libraries that are now available in 5000 different versions

not

It is the case - and very much so. Imagine having 15 different ffmpeg libs loaded.

One for firefox, another for telegram, yet another for mpv/vlc....

Oh and the entire qt stack they have been linked against of course

Or gtk

or any other library they need to run.

I'm not sure what Flatpak is doing in that regard, but Snaps certainly are working on having shared libraries to prevent this.

This is still fairly new, especially in terms of adoption

I'm not sure what Flatpak is doing in that regard, but Snaps certainly are working on having shared libraries to prevent this.

Not shared with the system and only if the maintainer compiles those agianst recent versions.

No. Telegram Flatpak use bundled into this fp Ubuntu libraries. All Ubuntu libraries.

https://github.com/flathub/org.telegram.desktop/blob/master/org.telegram.desktop.json where? i only see the dbusmenu and libappindicator stuff otherwise it is sitting on the kde runtime

I'm not sure what Flatpak is doing in that regard, but Snaps certainly are working on having shared libraries to prevent this.

They invented RPM/DEB packages. Again.

Not shared with the system and only if the maintainer compiles those agianst recent versions.

Oh, look we are back at the maintenance problem. Why dont we solve that in the first iteration?

Every app will fill your ram with previously preloaded libraries that are now available in 5000 different versions

oh dear

Making it easier for, well, less into packagin people to make packages or for third parties to do so would solve this all much much more elegantly.

Heck write a step by step intro to packaging if reading existing guides and available build scripts isnt enough.

https://github.com/flathub/org.telegram.desktop/blob/master/org.telegram.desktop.json where? i only see the dbusmenu and libappindicator stuff otherwise it is sitting on the kde runtime

ffmpeg, dee, dbus-glib, libappindicator, opus, libnotify, - are all from Ubuntu with outdated versions. Previous Flatpak releases used Qt from Ubuntu too. Now they use Qt-runtime instead.

ffmpeg, dee, dbus-glib, libappindicator, opus, libnotify, - are all from Ubuntu with outdated versions. Previous Flatpak releases used Qt from Ubuntu too. Now they use Qt-runtime instead.

hmm opus is actually from mozilla, libappindicator is 12.10 both in fedora, arch, ubuntu ... dbus-glib is 0.108 in fedora, ubuntu ... dee is 1.2.7 in fedora, ubuntu ... libindicator is 12.10 in fedora, ubuntu ... libnotify is 0.7.7 in fedora, ubuntu ... ffmpeg looks like the only one which is different ... please don't spread incorrect information

hmm opus is actually from mozilla, libappindicator is 12.10 both in fedora, arch, ubuntu ... dbus-glib is 0.108 in fedora, ubuntu ... dee is 1.2.7 in fedora, ubuntu ... libindicator is 12.10 in fedora, ubuntu ... libnotify is 0.7.7 in fedora, ubuntu ... ffmpeg looks like the only one which is different ... please don't spread incorrect information

From Fedora? "url": "https://launchpad.net/libindicator/12.10/12.10.1/+download/libindicator-12.10.1.tar.gz", "url": "https://launchpad.net/dee/1.0/1.2.7/+download/dee-1.2.7.tar.gz", "url": "https://launchpad.net/libappindicator/12.10/12.10.0/+download/libappindicator-12.10.0.tar.gz",

Very strange Fedora URLs, isn't it?

i said *in* fedora

i said *in* fedora

But it bundled into Flatpak (Ubuntu versions) with all others.

don't twist my words, https://apps.fedoraproject.org/packages/libindicator is version 12.10 same as the ubuntu path

hah nice of you to go and edit your posts

hah nice of you to go and edit your posts

Added all Ubuntu URLs into a single message.

don't twist my words, https://apps.fedoraproject.org/packages/libindicator is version 12.10 same as the ubuntu path

Version doesnt matter here.

ERROR: S client not available

Its compiled against ubuntu system li bs and ABIS

its inherently different and cannot share the library internally.

but they are *source* paths ?

but they are *source* paths ?

Its still compiled against ubuntu x.x

where?

There is no getting around this, flatpaks waste ram and space, make dll hell reality and and and

sorry simply not true

please read this https://blogs.gnome.org/alexl/2017/10/02/on-application-sizes-and-bloat-in-flatpak/ ... specifically the parts on disk, ram and network savings ... "It should be noted that this sharing does not only affect disk space use. Since shared files are hard-linked, any RAM used for disk cache and memory mappings are automatically shared too. Additionally, when applications are downloaded we don’t have to download any objects that are already locally available, so network bandwidth is shared too."

sorry simply not true

So you magically found a way to make libraries compiled distro-independent and distro-agnostic, despite being compiled on ubuntu for ubuntu and then flatpakd?

i didn't say that

i said that it is not a waste of ram and space

also where are you gettting this "compiled on ubuntu" from ?

i have seen *no* evidence

also where are you gettting this "compiled on ubuntu" from ?

Where do most flatpaks get made on?

Also, mostly snaps for this one.

From Fedora? "url": "https://launchpad.net/libindicator/12.10/12.10.1/+download/libindicator-12.10.1.tar.gz", "url": "https://launchpad.net/dee/1.0/1.2.7/+download/dee-1.2.7.tar.gz", "url": "https://launchpad.net/libappindicator/12.10/12.10.0/+download/libappindicator-12.10.0.tar.gz",

Oh and mostly that.

from the freedesktop or gnome runtime SDKs

Also, mostly snaps for this one.

we aren't talking about snaps here

Oh and mostly that.

that is *source* ... *not* compiled on

seriously ?

we aren't talking about snaps here

the above is the list from flatpak.

that is *source* ... *not* compiled on

Ubuntu still changes source sometimes for their system and backports.

so your story has suddenly changed

You still dont get shared memory objects with flatpak.

Even if it was suddenly "made for fedora"-stamped it'd load the execution into a separate env, as designed, wasting ram.

please read this https://blogs.gnome.org/alexl/2017/10/02/on-application-sizes-and-bloat-in-flatpak/ ... specifically the parts on disk, ram and network savings ... "It should be noted that this sharing does not only affect disk space use. Since shared files are hard-linked, any RAM used for disk cache and memory mappings are automatically shared too. Additionally, when applications are downloaded we don’t have to download any objects that are already locally available, so network bandwidth is shared too."

did you read this ?

The majority of users utilizing even half-decent hardware are not going to suffer from surface-level applications. Even if they're somewhat RAM-hungry or disk-consuming.

please read about OSTree and how it works first

Plus if a flatpak links against an older lib you can get ff 56 to run and stay forever on it - introducing a huge security risk.

i never said anything about running old libs? you are just twisting information to try and scare people

I'd rather someone make a tool that can package applications for several packaging methods at once, rather than having flatpaks/snaps.

i never said anything about running old libs? you are just twisting information to try and scare people

If you compile ff56 flatpak against libpng 0.9 it'll use that lib version in 10 years too, right?