Pale Moon forum

I think Linus gives a pretty good run-down of the issues here:

https://www.youtube.com/watch?v=Pzl1B7nB9Kc

And hey guess what? He says the exact same thing about shared libraries I've been saying for a long time. See? I'm not pulling it out of my ass. Linus agrees.

Bless that man and his blanket, wait..

Moonchild wrote: ↑

2021-06-20, 06:50

I think Linus gives a pretty good run-down of the issues here:

https://www.youtube.com/watch?v=Pzl1B7nB9Kc

And hey guess what? He says the exact same thing about shared libraries I've been saying for a long time. See? I'm not pulling it out of my ass. Linus agrees.

I maintained many packages for linux distributions and I fully agree with Linus. Shared libraries and different packaging for every tiny miny GNU Linux distro are two of killing aspects of GNU Linux desktop. I'm afraid neither flatpak nor appimage would be the solution for the latter problem.

That's why I used mono and makeself. Just a single bash script takes care of all the variances in mono and dependency packaging, and supports APT, DNF, ZYpper, urpmi, pacman, and even slackbuild.

Pretty awful when the solution to Linux is Microsoft, I know.

I find the socalled "Security issue in VLC"-debacle nearly two years ago a good example of what could go wrong when Linux disto devs manage 3rd party software on their own.

I'm still very pleased that you still provide precompiled binaries of Pale Moon in tarballs.

Great video. This is from the Debian Conference in 2014.

Baloo wrote: ↑

2021-06-22, 14:37

Great video. This is from the Debian Conference in 2014.

And it didn't change because of the concept 'diversity'.
Only full packages like snap packages can fix that, but create new problems.

Pentium4User wrote: ↑

2021-06-22, 14:45

And it didn't change because of the concept 'diversity'.

Who needs a package manager to run an application? Do you need Chocolatey or Windows Package Manager on Windows to run an application?

Pentium4User wrote: ↑

2021-06-22, 14:45

Only full packages like snap packages can fix that, but create new problems.

Snap? You should try Pale Moon tarballs. And unlike Snap they don't force-feed updates to you. The updater works for you, not against you.

I think even Linus is too shy to call out the real problem (who sponsors Linux Foundation?): The lack of a sane and stable (10+ years) toolkit on Linux.

But there are more problems on the horizon like Wayland so I'm packing my bags, but not leaving just yet.

Sorry for the tone, but it's disappointing when the Man himself talks about package managers instead of addressing the toolkit problem.
This talk was 7 years ago and I still haven't heard Linus mentioning the elephant in the room to this day.
Maybe he has and Linus has done enough for a lifetime so it might not be his fight.

Snap is one solution to run a software on different Linux distributions, but it creates new problems, I know and I don't like snap too.
I use the packages for Debian, because I like apt to only have one place to install updates.
For Basilisk I use the tarballs.

The fault is the concept, that the maintainers from the distribution decide which version they ship.

The problem of shipping the libraries with the application is, that developers need to care about the libraries too.

Pentium4User wrote: ↑

2021-06-23, 04:38

Snap is one solution to run a software on different Linux distributions, but it creates new problems

One of them being a legal one. The moment any one snap-packaged library is GPL-licensed, then the entire package has to be GPL due to the way GPL absorbes a larger work (and why I really don't like GPL) - this is why other-licensed software that isn't GPL compatible (and that includes anything MPL) will never be able to use snap without causing legal issues. This is why I explicitly exclude these kinds of bundle distributions for Pale Moon in the redist license.
Since many "system" libraries are GNU and GPL-licensed, this is a problem. This of course matters the same way for any other mutually incompatible licensing in a snap package.

I don't have a good solution to the problem, but a somewhat related situation is the GUI status.

I am using mostly ruby, so I work on an artificial layer. But ruby is super-expressive. I get away
writing little code and being able "to do much". Yes there is the speed penalty, I get it. C and
C++ will rule supreme.

Some time ago I discovered libui and the ruby libui bindings to it.

So now I can write code on linux first, and it works on windows just as well. \o/
(There are some limitations, and libui is not super-active anymore ... but if we ignore the
details then the part where I write on linux, and it works on windows just fine, then yep
that is a true statement.)

Something like this would be nice to have in general.

You can use gcc and perhaps clang/llvm to cross-compile lots of things, you can use win
to run tons of stuff, but all this comes with some complexity and time investment that
you may not always have. I'd love if this all would become really much, much simpler.
Just like libui showed. That could perhaps be applied to more areas.

As for application packaging - in ruby you can cheat a bit and use ocra for an .exe or
ruby-packer. I would not go the route of wanting to suppor tas many different formats
as possible though - the distributions are deliberately incompatible to one another.
You can find devel packages that have the same content but are named differently ...

We have a few good ideas such as snap, flatpak or AppImage so who knows - perhaps in
the long run we could have something that really works and just simplifies the whole
stack. But who knows when and if that will ever happen..........

... did you even read an understand what was said in this topic? Or are you just happy to post in a 2-month-old thread with information that is tangential and in some ways exactly opposite to what has been said, just because it happens to align with some anectdotal experience you yourself have with ruby and libs?

Because honestly, I don't see the relevance at all here in your post.