The problem building for Linux desktop
Forum rules
This General Discussion board is meant for topics that are still relevant to Pale Moon, web browsers, browser tech, UXP applications, and related, but don't have a more fitting board available.
Please stick to the relevance of this forum here, which focuses on everything around the Pale Moon project and its user community. "Random" subjects don't belong here, and should be posted in the Off-Topic board.
This General Discussion board is meant for topics that are still relevant to Pale Moon, web browsers, browser tech, UXP applications, and related, but don't have a more fitting board available.
Please stick to the relevance of this forum here, which focuses on everything around the Pale Moon project and its user community. "Random" subjects don't belong here, and should be posted in the Off-Topic board.
The problem building for Linux desktop
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.
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.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: The problem building for Linux desktop
Bless that man and his blanket, wait..
Re: The problem building for Linux desktop
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.Moonchild wrote: ↑2021-06-20, 06:50I 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.
- RealityRipple
- Astronaut
- Posts: 662
- Joined: 2018-05-17, 02:34
- Location: Los Berros Canyon, California
- Contact:
Re: The problem building for Linux desktop
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.
Pretty awful when the solution to Linux is Microsoft, I know.
- RoestVrijStaal
- Moon lover
- Posts: 81
- Joined: 2019-06-19, 19:18
- Location: Dependency Hell
Re: The problem building for Linux desktop
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.
I'm still very pleased that you still provide precompiled binaries of Pale Moon in tarballs.
- Pentium4User
- Board Warrior
- Posts: 1137
- Joined: 2019-04-24, 09:38
Re: The problem building for Linux desktop
And it didn't change because of the concept 'diversity'.
Only full packages like snap packages can fix that, but create new problems.
The profile picture shows my Maico EC30 E ceiling fan.
- mr tribute
- Lunatic
- Posts: 334
- Joined: 2016-03-19, 23:24
Re: The problem building for Linux desktop
Who needs a package manager to run an application? Do you need Chocolatey or Windows Package Manager on Windows to run an application?
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.Pentium4User wrote: ↑2021-06-22, 14:45Only full packages like snap packages can fix that, but create new problems.
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.
- Pentium4User
- Board Warrior
- Posts: 1137
- Joined: 2019-04-24, 09:38
Re: The problem building for Linux desktop
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.
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.
The profile picture shows my Maico EC30 E ceiling fan.
Re: The problem building for Linux desktop
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.Pentium4User wrote: ↑2021-06-23, 04:38Snap is one solution to run a software on different Linux distributions, but it creates new problems
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.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: The problem building for Linux desktop
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..........
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..........
Re: The problem building for Linux desktop
... 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.
Because honestly, I don't see the relevance at all here in your post.
Off-topic:
P.S. Please for the love of Pete stop putting linebreaks in your posts at whatever column size your screen is set to.
P.S. Please for the love of Pete stop putting linebreaks in your posts at whatever column size your screen is set to.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite