Flatpack

>flatpack
>snap
>every program bundles outdated copies of it's own libraries
DUDE LET'S TURN LINUX INTO WINDOWS LMAO

Other urls found in this thread:

askubuntu.com/questions/965455/how-do-i-create-an-opengles2-and-glfw3-snap
github.com/andrewrk/libsoundio
twitter.com/NSFWRedditImage

It's a terrible attempt, barely enough for high level software but not enough for low level kennel modules and software
They removed the entire kernel which is the actual important part

t. nodev

linux is a meme because it has 0% marketshare (3% / 10000 distros = 0). Snaps solve this.

Also, help me make a snap:
askubuntu.com/questions/965455/how-do-i-create-an-opengles2-and-glfw3-snap

Distributing source with a real build system solves this too. What's your point?

It doesn't. End users want a convenient way to install it, like "apt get" or "snap install", or find it through app store. Nobody will touch your source.

You should look up AUR system, it gives you the convince of a package manager but also has the latest software since it's source based

More distros DO NOT support snaps than do support them, ergo source distribution is a better solution to your stated issue of market share.

Know what's the real joke? They do expect libraries.
I wanted to try the Spotify flatpak of whatever on Gentoo and had to install two packages. Guess those are installed by default in every binary distros desktop metapackage.

>hey freedesktop fellas, shared linking is a constant source of problems. how do we solve this?
>static linking?
>no fuck off. CONTAINERS. containers are the future

and it only takes hours to install programs

Its one those things that has existed for years but the upper management has heard of them just not and think they can dramatically cut cost, because obviously nobody has ever thought of this before

For the source based packages, sure, but for pre compiled binary packages, it's faster than apt+dpkg

So what? Arch is a miniscule portion of Linux. I am not going to maintain
>a deb
>an rpm
>a tar.gz with installation instructions
>maybe some other obscure shit
and so on for everyone, simply because I have one machine and don't have the resources to test all that shit. I want a simple, convenient way to package my app, so that the widest array have a convenient way to install it.

Most distros a so obscure nobody use them. I'm interested in potential user count, and both snap and flatpak are available on most distros. Neckbeards using obscure distros can install it from source anyway, I'm providing a codeblocks project file, they can derive a makefile from that.

The thing is that snap and flatpak provide a way to make *one* package that works on like 10 most widely used distros, and that package can be closed-source too, if I ever decide to make my software proprietary. And that's great from my perspective. You may get a few unnecessary megabytes, so just get a bigger harddrive. My 200 euro laptop has 1TB harddrive, I'm using like 50GB and most of it is porn.

>Most distros a so obscure nobody use them. I'm interested in potential user count,
So we're going to weight the share of those 10,000 distos now? Hmm, let's see, then 99% of the "potential user count" is covered by .deb and .rpm packages. Looks like there's no need for this snap business after all. Thanks for keeping this from turning into a lengthy debate by defeating your own point (assuming you're ).

>.deb
>source.tar.gz

I refuse to target non-apt based distros, arch and gentoo zealots can maintain their own packages.

then why .deb and not .rpm?

linux's strong point is also its weakest point, fuck it all.

debs work with specific Debian repo versions (the requires clause). So you need a .deb for Ubuntu 17.04, 16, 14, and 12. Maybe the same shit is for rpm, never had anything else than Lubuntu. Arch can't use .deb and .rpm, and arch is not a complete meme, because it has been memed so hard before. So snaps are still needed because you would need to maintain like 5 .deb and 5 .rpm files

Just target debian stable, what the fuck are you doing?

>you need a .deb for Ubuntu 17.04, 16, 14, and 12

No, you don't. You need a repository for each distinct distribution / release. The .deb packages can remain the same providing their dependencies are met (there is NOT a needless global version number bump / dependency bump).

Including a makefile for your package isn't hard, just copy it from your source code to the GitHub repo. It takes a few minutes at most, but that extra little can help to port your package to distros you haven't even heard of. It's very simple to turn those little makefiles to packages.

Actually, Arch can use Deb packages just fine. It treats them as archives, unpacks them, then makes it's own packages out of them. That's one approach at least, same with RPMs

Hey I've got a good idea for packages: a compressed archive with only static binaries.

You can make the payload for any package, deb or rpm be a static binary

Static binaries aren't liked because they're really big in size, can't be updated, and unmodular

>Just target debian stable, what the fuck are you doing?
Trying to get the largest linux audience.
>You need a repository for each distinct distribution / release.
Sounds like a big hassle. New Ubuntu comes out every year, or at least every second year. I want to make my app and be done with it.

>really big in size
Rubbish.
>can't be updated
RUBBISH.
>and unmodular
How does so-called modularity affect the end user?

If you care so much about wide mass appeal, just write a goddamn windows application.

Of course I will, alongside, but Windows has a shitton of competition. I will drown in it. Meanwhile, very few developers want to put up with Linux shit, and the Linux Desktop marketshare, albeit slowly, is rising, and I, having some experience with dealing with its shit, can have an edge because there's not as much competition.

So I will make a snap.

>have this project that uses a library
>compile my project statically because I'm dumb
>library my project uses get updated
>I have to recompile the whole project, and provide the users with the updated binary which is multiple MBs in size instead of a couple of KBs for the library and my progress sperately

>Sounds like a big hassle. New Ubuntu comes out every year, or at least every second year.
You're misunderstanding; likely confusing the responsibilities of the distribution provider and the function of a release with your own.

>I want to make my app and be done with it.
You can do that with a .deb or .rpm package, trivially. Do you have any experience developing debian or redhat packages, or even reconfiguring / installing specific package versions from older releases of a distribution?

>very few developers want to put up with Linux shit
I guess that answers my above question. Long story short: you're doing it wrong. What you've stated you're trying to achieve is very easy and likely comes down to misconfiguring your package scripts.

AppImages are fucking wonderful

Right now on GNU you can either have a "bleeding edge", unstable system, or an outdated, stable one.
There's no in-between.
Furthermore if a package depends on another one, and the dependency is updated, you're either stuck with an outdated package, or you have to uninstall the ones that depend on it.
PPAs and third party repos are a dirty hack that lead to dependency hell.
Snaps not only allow the developer to package the program an have it working on all distros without issues, it also allows users to install several versions of the same package, as well as roll back updates no problem. Plus, programs are sandboxed so they can be controlled even more.
With Snaps you can have the latest version of a program (such as Firefox or LibreOffice) on a stable Debian Wheezy install if you wish to.
It's not perfect, but it does solve one of the biggest problem of distributing packages on GNU systems.

Even though I can't get that shit working. I could not make a flatpak, and snap doesn't load graphics drivers.
askubuntu.com/questions/965455/how-do-i-create-an-opengles2-and-glfw3-snap
Any help?

>have this project
>it uses a library
>want to distribute it for Ubuntu 17/16/14/12/10, Lubuntu, Xubuntu, Arch, Debian, Fedora, Manjaro, Gentoo, OpenSUSE, Solus, openembedded, Linux Mint, openwrt, yocto
>don't want to maintain 20 packages that can break anytime
>make a snap
Seems logical.

What about them?

>You can do that with a .deb or .rpm package, trivially. Do you have any experience developing debian or redhat packages, or even reconfiguring / installing specific package versions from older releases of a distribution?
No, this is my first app (if we exclude some others ones I just spit out the raw makefile without install target for everyone and let everyone build it themselves).

>Long story short: you're doing it wrong.
So you're saying that a .deb is enough? I made a deb and it worked on my system (as opposed to flatpak and snap which didn't).
What if no repos/whatever have a library I'm using? I'm using a very new C library called libsoundio and there are *NO* packages for it. github.com/andrewrk/libsoundio . Should I link it statically in my .deb file?

>have this project that uses a library
>use dynamic linking
>use the "it'll get updated by the distro" justification when you really don't give a fuck about using the latest version of the library and you're a lazy cunt
>when that dynamic library does get updated, the API breaks
>even if the API does not break compatibility you may still have to change the package manifest and upload a new version tracking the new library version
>even if the API does not break compatibility, the updated library may just introduce new bugs and you won't know about it because you're a lazy cunt and someone else manages package requirement updates and you haven't tested the combination of your program + updated library
>very often you'll have to recompile the project anyway because your program is strict about finding the correct SHIT_MINOR_VERSION in the dynamic library
>litter the system with 30MB dynamic libraries when you're just using a couple of functions that could have been optimized to 10KB anyway
Just fuck off, I can't believe people still defend dynamic linkage.

>No, you don't. You need a repository for each distinct distribution / release. The .deb packages can remain the same providing their dependencies are met (there is NOT a needless global version number bump / dependency bump).
No, you don't. For instance, libpng12 is in the Ubuntu 16.04 repository, but not in later versions; so you have to rewrite some stuff to make those programs with libpng16.
This is just a tiny example, but there are others. Maintaining packages is a nightmare and that's why big distros have entire teams dedicated to that.
Let's not even talk about Debian and the massive version bumps between releases, or how a .deb targeted to Debian may not work on Ubuntu at all and vice-versa. Same thing happens with OpenSUSE and Fedora.

.rpm is THE serious package format, having RHEL, CentOS and Oracle.

Frankly I get stressed just thinking about external dependencies. No more. Never again.

I like appimages because I can use kdenlive and krita on my cinnamon desktop without all the KDE dependencies.

>Frankly I get stressed just thinking about external dependencies.
How are you going to get audio/graphics without them?

That's great, they can use their SERIOUS resources to repackage my shit if they want, I only target the distro I use, debian.

yeah snap, flatpak and appimage are all much cleaner

this is why we need snap

Interacting with system libraries like that is a special case where you just have to bite the pillow. However, these things should be synthetic fileservers that are guaranteed to be present and don't keep breaking compatibility every update. Do modular programs the Unix way, not the System/360 way.

>No, this is my first app
OK, I can provide some helpful information now that I understand your perspective.

>So you're saying that a .deb is enough?
For what you've described, yes.

>What if no repos/whatever have a library I'm using?
You can provide the library, or statically link it.

>Should I link it statically in my .deb file?
You can box the library with your application (install both), or statically link it to YOUR application (both in the same elf file).

>when that dynamic library does get updated, the API breaks
ABIs should never change / break backwards within a distribution release; that's the point of a release.

>even if the API does not break compatibility you may still have to change the package manifest and upload a new version tracking the new library version
req version >= base version; no need for a new package

>I can't believe people still defend dynamic linkage.
kek
>"updates" on an all static system
>update for libc, linux, or another popular library
>time to update all 2489 packages
kys

>No, you don't. For instance, libpng12 is in the Ubuntu 16.04 repository, but not in later versions; so you have to rewrite some stuff to make those programs with libpng16.
There's an incompatible ABI change between those libpng versions, which is to be expected in the LONG term. libpng16 has been available since at least 2013, so why would you use libpng12, which hasn't been current since 2009!

>This is just a tiny example, but there are others
I know this first hand, but I also know that it's rare. Developers should be expected to maintain their application a few times a decade.

>this is why we need snap
So that developers can use antiquated libraries on modern systems? This is the equivalent of a Windows developer complaining that their Win XP application doesn't run properly on Windows 10.
>muh ABI changes
Doesn't happen within a release; don't like updating your app every few years? Target STABLE.

>update for libc
update as and when
>linux
system calls are special and are not static nor dynamic linkage
>another popular library
update = changed behaviour and/or api, it is as simple as that

>so why would you use libpng12, which hasn't been current since 2009!
what benefits does libpng16 bring him?

>system calls are special and are not static nor dynamic linkage
I'm just talking about *-linux.so.*

>update = changed behaviour and/or api, it is as simple as that
What about bug fixes?

>what benefits does libpng16 bring him?
What benefit does libpng12 bring him?

curl src | tar xvz; cd src && make install

Advantages of static linking:
>none of the hassle of shared linking
>you cannot forget a dependency. if your program links, it runs.
>don't have to place 20 .dlls into your program's binary directory when packaging for windows
>saves space because you aren't storing lots of bloated copies of shared libraries which are all full of never-used functions
>saves initialization time because you don't have to repeatedly retrieve function addresses
>better performance because of less indirection
>your package won't be the one to cause apt-get to completely blow up on that rare occasion where the debian maintainers fucked up and have two different versions of a shared library conflict with each other in some way

Advantages of shared linking:
>get to parrot flawed conventional wisdom on the internet
>????

>What about bug fixes?
worth recompiling for. and keeping an eye out for bug fixes that's your responsibility, not the distro's.

>What benefit does libpng12 bring him?
it works just as well as libpng16 and he doesn't need to think about it. those elderly binaries are still going strong, but a dynamically linked one would not.

error: could not link gles2
error: /usr/local/applications does not exst
error: could not link glfw3, only glfw2 available
error: could not link libsoundio, no such package
error: pulseaudio not available, use OSS instead

shit program

Try to install the same shit over 50 different distros and I'm sure it will break

wait until you hear about this thing called docker

wait until you want to make your app available on 20 distros

>openssl has a vulnerability patched
>100 different maintainers need to do work to put out a new release of their software
How can anybody think this is a good system? It's a system for lazy devs who probably won't put out a new release for library bugfixes anyway and that's it

You never used to need dynamic libraries to output audio on Unix-like systems:

FILE *audio = fopen("/dev/dsp");


Unfortunately the people writing OSS implemented feature requests far too late, and Linux distro maintainers decided that sweet APIs that can be used from any programming language without any special binding efforts at all were not a valuable design philosophy on a fucking Unix-like OS.

perfect for gamedevs

>It's a system for lazy devs
>"dude if you use dynamic linkage the distro will update all your libraries"

>only one program can play audio at a time

>ship a program with shared libs
>it breaks if you look at it wrong
How can anybody think this is a good system?

Good programs work not just on 50 different linuxes, but on 50 different unices.

why do that when i can build it once and have it run on any platform that can host docker (i.e. most)

I never said OSS was good, I said the API had a good idea behind it: leverage Unix's design strengths.

Life in Static linking land: a series.

>xyzlib has a vulnerability!
>which of my apps use it??
>I hope all my package providers update all their packages that use that library quick!

>install new program
>I sure am glad I saved 30MB by not having to install all those dynamic libraries
>I like having 800 copies of the same library on attached to programs on my disk; I bet they don't get lonely now
>I also like having 42 different instances of that library in memory at the same time; it keeps my room warm

>oh wow there's been a great performance improvement in the latest version of FASTlib
>time to build and ship a new version of my ENTIRE app to all the millions of my users

What a magical land.

>it works just as well as libpng16
Why would you choose to use an unsupported and antiquated library when developing new software? You're creating a completely avoidable problem. When you need a png library, do you set out thinking "what's the oldest library I can find for this", and then choose to use it anyway when you KNOW it's not being supported anymore? If you do this you've literally brought it on yourself. You might as well complain that your new app that targets linux 2.6.x doesn't run on the latest version of Ubuntu. Honestly, I just think it's lazy excuse.

>he doesn't have to think about it
>not the lazy dev's approach

>0% marketshare

who fucking cares Linux is the only OS I use and I need I don't care about fucking market and fucking normalfags using it.

Not if the OSS driver implements a mixer.
It's just an interface were you dump your bitstream.

>xyzlib has a vulnerability!
>which of my apps use it??
>I hope all my package providers update all their packages that use that library quick!
You sure you aren't describing dynamic linkage?

>I like having 800 copies of the same library on attached to programs on my disk; I bet they don't get lonely now
Oh well, it's only 100KB in sum.

>time to build and ship a new version of my ENTIRE app to all the millions of my users
You said above that active maintenance is to be expected of devs. In fact, in this age, programs are rarely ever put into a quiet maintenance mode. Today's programs are constantly pushing out new updates. Take this into consideration and your "disadvantage" of needing to push an updated program if a library receives an important update dissolves away.

Show me a good program that uses graphics and audio.

I thought you were shaming docker, my bad. We're good.

Whatever, as you yourself sailed, that ship has sailed.

>muh security
>muh vulnerability
Fuck that. I want my programs to be have the highest reachability with the least amount of effort and maintaining from my part.
Ease of distribution > security.
Ease of distribution > hard drive space.
Ease of distribution > speed and memory usage (Java, C#, Python, ...)
Ease of distribution = audience = money

Developers care. Normalfags = money.

>>I like having 800 copies of the same library on attached to programs on my disk; I bet they don't get lonely now
It's 2017. Everyone has a 1TB or bigger harddrive.

plan9port.

YES

> sudo apt-get install plan9port
[sudo] password for rb:
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package plan9port
> sudo snap install plan9port
[sudo] password for rb:
error: snap "plan9port" not found

shit program

>Not dealing with trivial problems is more important than security
You are a cancer

there was a package on debian-testing

>You sure you aren't describing dynamic linkage?
Absolutely.

>which of my apps use it??
ldd or equivalent can tell me at a binary level, package manager can tell me what depends on it.

>I hope all my package providers update all their packages that use that library quick!
One package needs to be updated.

>Oh well, it's only 100KB in sum.
Doubtful. Even libc standard library is over 2MB. You're bloat estimations are off by several orders of magnitude.

>You said above that active maintenance is to be expected of devs. ...
The issue is the needless re installation of the entire application, for every application that wants to make use of an update in a library, and the resources wasted in doing so. If your application is large, I doubt you'd like to foot the bill for the bandwidth in updating millions of users (even Adobe didn't want to).

>Fuck that. I want my programs to be have the highest reachability
Maintainability is king. You can fuck off back to Windows / mobile if all you care about is audience size.
>easier for me to maintain because I don't need to worry about it for like 10 years
But a mess for users in the long run, especially if there are many lazy devs like you.

>shared objects
>security
kek

>Doubtful. Even libc standard library is over 2MB.
>>>>>what is dead code elimination

>The issue is the needless re installation of the entire application, for every application that wants to make use of an update in a library, and the resources wasted in doing so.
Hahaha, fuck me.

don't care doesn't work on my machine
security is a meme
distribution is actually important
you won't get revenue for secure apps, you will get revenue for popular apps
>Maintainability is king.
Maintain what? You make the app and it's done. You don't need to touch it in a hundred years, it's supposed to work. You can install DOOM from 1993 that was never maintained on an emulator and it will work just fine even though it wasn't updated for almost 35 years.
You can run GUI apps from bankrupt companies that made them 20 years ago, those programs are still used.
>But a mess for users in the long run
Easier deployment = more devs = more alternatives = solution

>what is dead code elimination
Something developers don't do.

>Hahaha, fuck me.
Oh, so you're just pretending to be retarded, got it.

>Maintainability is king. You can fuck off back to Windows / mobile if all you care about is audience size
This guy is right. People like you are the reason nobody cares that Linux has a low market share. It's better that way

Flatpak can update the libraries they bundle just as easy as your distro package manager updates it's libraries

OP confirmed Gentoo fag

>Maintain what? You make the app and it's done. You don't need to touch it in a hundred years,
Reading comprehension.

>Easier deployment = more devs = more alternatives = solution
Solution to what?

>You can install DOOM from 1993 that was never maintained on an emulator and it will work just fine even though it wasn't updated for almost 35 years
Also, no, it won't (no more 16bit support in newer versions of windows).

>2017-1993
>almost 35
Is math a meme too?

>on an emulator

Well, they just should run deduplication on top of it and call it a day.

meant to say more than
whatever
I'm making a snap and you can't stop me
It will work on all Ubuntus, on Debian, on Fedora and all other shit

what are these?

>It will work on all Ubuntus, on Debian, on Fedora and all other shit

Snaps confirmed for Satan.

>Something developers don't do.
What? When you use just a single libc function and then statically link against libc, the linker doesn't include the entirety of libc in your binary, but only the part of the library you make use of. I'm not even convinced you're a developer now -- you'd know this otherwise.

>Oh
Alright Adobe, enjoy shipping 300MB of .dlls to end users when you make use of only 900KB of the code therein. Dynamic linking saves space!

>Snaps confirmed for Satan.
For being fucking amazing? I may become a fucking Satanist then

>2017-1993
>More than 35
At first I thought you just made a flub, but apparently you're actually retarded

the point was a long time

You're probably autistic, I should have figured. Maybe fuck off back to sta.li or void linux or slackware or whatever faggot hipster shit is popular nowadays

reading comprehension

If you think basic algebra is for autists, then maybe software isn't the right choice for you. But seeing as you came in here to argue that a shit system is the best and then immediately asked how to make said shit system work right, I should have seen that sooner

>emulator
An emulator makes that irrelevant. It's a whole environment specifically made for running an application.

>What? When you use just a single libc function and then statically link against libc, the linker doesn't include the entirety of libc in your binary, but only the part of the library you make use of. I'm not even convinced you're a developer now -- you'd know this otherwise.
Try it yourself. Here's hello world (stdio / printf, only), dynamic vs static:
>gcc -o hwd.o hello_world.c
>gcc -o hws.o --static hello_world.c
>8.3K Oct 16 15:25 hwd.o
>899K Oct 16 15:26 hws.o

>An emulator makes that irrelevant. It's a whole environment specifically made for running an application.
his point is that he can run it on MSDOS or win3.1 or a DOS clone, regardless of how many updates have been released, because doom is self-contained

>Try it yourself.
you do it, i'm not on a unix and mingw seems to just dynamically link to the msvcrt whether you want it or not

you have no optimizations enabled, you aren't even linking you sneaky cunt

do:
gcc -O3 -o d hello.c
gcc -O3 -static -o s hello.c

there will be a far smaller difference

>you have no optimizations enabled
>there will be a far smaller difference
Again, no.

>gcc -o hwdO.o -O3 hello_world.c
>gcc -o hwsO.o --static -O3 hello_world.c
>8.3K Oct 16 15:45 hwdO.o
>899K Oct 16 15:44 hwsO.o

>you aren't even linking you sneaky cunt
Do you even know what you're talking about?
>ldd hwd.o
>linux-vdso.so.1 => (0x00007fff40fc6000)
>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f70c8d3c000)
>/lib64/ld-linux-x86-64.so.2 (0x000055e71f68c000)

>his point is that he can run it on MSDOS or win3.1 or a DOS clone, regardless of how many updates have been released
This is true for anything if you can provide the whole environment. Provide a Ubuntu 16.04 install and that libpng12 application will install properly. In ~20 years, provide an emulator / install the old libs yourself / VM or whatever and that application will work properly.

>t. uriel

>no linking still
discarded

>create problem
>have to work around problem instead of avoiding altogether
haha stupid uriel poopoo