I just googled it and i find that system similar to snap. What's the differences?

its not made and built for ubuntus propreitary and only-option snap hosting.

And both are behind the best, fully open and community - but not as performant (yet) solution - appimage.

In the future-preserving, keeping-it-open sense.

Thank you @Wolfshappen

I just googled it and i find that system similar to snap. What's the differences?

Snap is from Ubuntu while flatpak is used by different distros like Debian & Fedora. That's the main difference AFAIK.

https://fedoramagazine.org/building-fedora-kernel/

Just build it on fedo. Also it will not make huge differences.

Just build it on fedo. Also it will not make huge differences.

Try that tomorrow.i just have to sleep. Have class in 3 and half hours...

It's still doing its thing

Hello! Can anyone suggest programmes similar to the ones in this list but for Linux, preferably Fedora? http://www.designyourway.net/blog/misc/work-is-easy-with-the-best-invoicing-and-time-management-apps

Running a flatpak with all build dependencies and services, for a calculator?

why not? provided calculator is not the only application which will use that runtime, I don't see an issue with that.

Try that tomorrow.i just have to sleep. Have class in 3 and half hours...

Kernel 4.12: Better Livepatching Boot time analysis New KVM nested virtualisation options (useless without qemu update) usb3 debugging, preview on up to 1 Petabyte of ram (coming 4.13), MBA support (intel server stuff) Better uefi secure boot support KASLR by default Trusted execution Environment base driver TPM spaces Generic XDP for faster network handling for everyone - as debugging tool for where xdp makes sense BFQ scheduler available by default Raid 5 better data protection for mdraid Better security for encryption better mdadm/raid performance Full article in german: https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-12-3712705.html

Almost NONE of that can actually be used from userspace.

Most is generic basework for future things

aside bfq and KASLR really

why not? provided calculator is not the only application which will use that runtime, I don't see an issue with that.

Claculator, maintained and udpated: Calculator (10 mb ram) Shared system libraries/ dynamic linked stuff (100 mb, but only loaded once and shared by all things. Assumed to be the most recent version Calculator, flatpak: Calculator (10 mb) Flatpak sandbox (no idea) Flatpak-specific libraries (100mb, per flatpak app, not shared) Flatpak runtime Flatpak Runtime shared libs Flatpak needed shared system libs

Fictional Calc app

So yeah, if you kkeep your code updated you can save users a ton of hassle.

Fictional Calc app

Reminder: we are living in a world where the simplest newsreader on a mobile phone is 100MB, I hate it too but well

Also, flatpak sandbox might have vulnerabilities - and flatpak allows to keep old, vulnerable libraries.

Reminder: we are living in a world where the simplest newsreader on a mobile phone is 100MB, I hate it too but well

Dont use a shit one.

I see this flatpak as a nice way to quickly take a look if I like an application. If I do, I can build it outside of it. If I didn't, I saved time I had to spend on building it

of course it's possible to create packages for all possible distros, but it's a hassle, and flatpak is there to solve that exact issue

of course it's possible to create packages for all possible distros, but it's a hassle, and flatpak is there to solve that exact issue

It will be mainly used to distribute apps with old libraries and known vulnerabilites that devs will put for "later" to fix it because you aren't forced to adhere to updating anymore.

I see this flatpak as a nice way to quickly take a look if I like an application. If I do, I can build it outside of it. If I didn't, I saved time I had to spend on building it

For a quick look, yes. Not for your De's fucking calculator.

For a quick look, yes. Not for your De's fucking calculator.

is that DE using flatpak and only flatpak for those, or is it just providing a flatpak version on the side so you can take a quick look?

is that DE using flatpak and only flatpak for those, or is it just providing a flatpak version on the side so you can take a quick look?

the former.

the former.

source? I think for arch (which seems to be the only repo they support other than flatpak) they distribute their application "natively"

plus, as a bonus, they have a flatpak repo with their apps

Snap is from Ubuntu while flatpak is used by different distros like Debian & Fedora. That's the main difference AFAIK.

?

Snap is from Ubuntu while flatpak is used by different distros like Debian & Fedora. That's the main difference AFAIK.

Thank you @Kohane, too

source? I think for arch (which seems to be the only repo they support other than flatpak) they distribute their application "natively"

it seems implied for other platforms.

Yes you can compile them natively

But still, these are core apps taht should depend on the hosts' native libs, not add tons of cruft and crap.

it seems implied for other platforms.

Bullshit. They only provide repo for arch, plus flatpaks. They don't depend on flatpaks, and flatpak is not wrong here.

Reminder: we are living in a world where the simplest newsreader on a mobile phone is 100MB, I hate it too but well

So, mine is using 50 Mb and is anyhting but "simple".

Bullshit. They only provide repo for arch, plus flatpaks. They don't depend on flatpaks, and flatpak is not wrong here.

"Seems"

I just looked again in their github.

But still, these are core apps taht should depend on the hosts' native libs, not add tons of cruft and crap.

now this is another issue, and I don't say that it's a DE I would recommend to anyone ;)

I just think that the fact that they provide flatpaks is actually nice.

"Meh"

Flatpaks should be a last resort over maintainers

Flatpaks should be a last resort over maintainers

Well, now it's either flatpaks, or the chaos that is the multitude of native package managers. Plus, flatpaks provide sandboxing

But yeah, a distribution built ONLY on flatpaks would be a disaster

Well, now it's either flatpaks, or the chaos that is the multitude of native package managers. Plus, flatpaks provide sandboxing

firejail. Or make namespaces easier to access in general.

firejail. Or make namespaces easier to access in general.

it doesn't solve the issue where when you want to release your application you need to create a few DEBs, a few RPMs, something for arch, some tgz etc... while you can support what you want to support + provide flatpaks for everyone else

I'd add that, at least on ubuntu's repos, there are so many libraries that nobody use anymore. It's an enormous jungle. I hope those systems will improvev the situation

flatpaks are nice *as an addition*. Of course, for basic stuff native is always better, when it's not there then it's nice that flatpaks are available

it doesn't solve the issue where when you want to release your application you need to create a few DEBs, a few RPMs, something for arch, some tgz etc... while you can support what you want to support + provide flatpaks for everyone else

Provide the code and a thing poeple want to use, maybe ask a community member to make a .spec.

Provide the code and a thing poeple want to use, maybe ask a community member to make a .spec.

effectively blocking anyone who doesn't know how to compile stuff from trying the application out until someone knowledgable does it; + it's not an option for closed source stuff

effectively blocking anyone who doesn't know how to compile stuff from trying the application out until someone knowledgable does it; + it's not an option for closed source stuff

Have someone compile it then.

This could destroy complete stable and backports models that sometimes depend on other applications to work.

effectively blocking anyone who doesn't know how to compile stuff from trying the application out until someone knowledgable does it; + it's not an option for closed source stuff

And giving closed source more problems on the way rather than allowing them to compile against qt4 and libpng 0.9 in 2017 is in the long run the better option.

And giving closed source more problems on the way rather than allowing them to compile against qt4 and libpng 0.9 in 2017 is in the long run the better option.

Closed source doesn't care. You'll get a tarball of binaries compiled some time ago and that's all. So whether we will get that as an flatpak which is easy to use or as a tarball where we need to take care of the dependencies ourselves is our only choice, I guess.

Closed source doesn't care. You'll get a tarball of binaries compiled some time ago and that's all. So whether we will get that as an flatpak which is easy to use or as a tarball where we need to take care of the dependencies ourselves is our only choice, I guess.

the latter will keep less poeple using it tough.

They could work with atleast the packaging with the community.

the latter will keep less poeple using it tough.

if you want to play a closed source game, it's not like you can choose an open source alternative. You will say "it doesn't work, linux is crap" and will switch to systems where it's not a problem

if you want to play a closed source game, it's not like you can choose an open source alternative. You will say "it doesn't work, linux is crap" and will switch to systems where it's not a problem

Steam. Gog.

Both provide perfect counterexamples.

And even on Windows dependencies are a problem.

Steam. Gog.

What Steam does? provides one stable environment with old libraries. Just like flatpak does.

maybe less - but keeping the system away from being a toy os is good imho.

Let the gamerbabies use windows and get shit done on actual systems.

imo the users/customers of closed source are often the root cause for these issues: they are hardly willing to pay an adequate maintenance fee.

maybe less - but keeping the system away from being a toy os is good imho.

in a nutshell, you're making sure Linux won't enter mainstream ever.

at least our customers think like this...

ERROR: S client not available

(but we are not into games)

Its already mainstream enough.

And it is better off serving powerusers.

imo the users/customers of closed source are often the root cause for these issues: they are hardly willing to pay an adequate maintenance fee.

I've bought unreal tournament in ~2007, I definitely am not going to pay a monthly fee to make sure someone will keep it maintained, but I still want to play it from time to time.

And being perfect to _work_

And being perfect to _work_

until you can use only the maintained applications, and are not stuck with a closed source solution which is not maintained anymore

see - closed source applications that take care of hardware, which was expensive as hell but the company got out of business and there's no way to get SW updates now.

until you can use only the maintained applications, and are not stuck with a closed source solution which is not maintained anymore

well, guess why you shouldn't depend on things like .net.core over ruby/python ect.

well, guess why you shouldn't depend on things like .net.core over ruby/python ect.

but in real life you often do

see - closed source applications that take care of hardware, which was expensive as hell but the company got out of business and there's no way to get SW updates now.

What the fuck should that application do with the hw?

What the fuck should that application do with the hw?

control it?

kernel upstream it then and make it able to load other drivers aswell.

I'm voting against you with my money else.

Same goes for any decent company

Including mine. XD

that's nice, but still, in real world you buy a special hardware for specific tasks (car diagnostics? cnc? factory automation?) you get a software thrown on a disc and that would be it when it comes to sw maintenance

take it or leave it, but when no other company does that differently then tough luck

not all makers of proprietary stuff work like this.

e.g. my company does not. we play well.

not all makers of proprietary stuff work like this.

and I agree that if possible everyoner should take those who play well

take it or leave it, but when no other company does that differently then tough luck

We are apparently enough to make dell offer a linux laptop with amd gpu.

we even open sourced quite some components of our systems.

Which were our latest upgrade too.

fuck nvidia

and fuck windows tax

but the sad truth is, that there are many companies which don't care about it, and it's either Linux will provide a way for that to be compatible, or it will never have a chance in those fields

but the sad truth is, that there are many companies which don't care about it, and it's either Linux will provide a way for that to be compatible, or it will never have a chance in those fields

So?

Why would you want to?

Make the fields adapt.

Actively provide better software

actively use the open sauce alts.