Flatpaks, Snapd, Etc

It's mainly attractive for proprietary software like Steam. Another good thing is that it does not requires sudo and does not mess with your system. However, for that I prefer a package manager like Guix or Nix instead, it's the superior design.

For the most part it's fucking stupid. You wouldn't use it for 99% of programs because then you'd end up with over six gorillion copies of the same libs and dependencies on your computer eating up your disk space. One acceptable use for them would be something like distributing windows games for GNU/linux since setting up games to work with wine is an absolute nightmare, but so far the only ones offering this are a handful of internet pirates who only like obscure indie games.

Oh no, 2 GB extra. Whatever will I do.

Absolute pozz. Snap is absolutely the worst dumpster fire of package managers. Flatpak is, perhaps, acceptable for proprietary software, like steam.

Not
But Linux NEEDS better Audio system and init+process supervisor, but SystemDick and PukeAudio are just awful.

Having the storage space capacity is not an excuse for bad engineering, soydev.

Snap is fucking garbage.
Regret ever using it.
Everything is broken.
Disabled all snaps I had before, only kept Slack and VS-Code on it because I don't want that shit directly installed on my machine.

I tried downloading some snaps and they just didn't work. PATH variables all fucked up. Get your shit together, Shuttleworth.

All it needs is a proper OSSv4 implementation.

It prevents dependency hell so I'm all for it

Well faggot if you knew what you were talking about you would know this is just a standard combination of the existing kernel isolation tools. That's all docker is 2. A convenient wrapper to manage the existing kernel isolation tools (that are a massive PITA to use manually).

I've had nothing but shit with both ALSA and Pulseaudio hanging my system whenever I try to change my headphone amp's impedance on the Xonar Stx II.

Appimages are fine, especially for shit like Krita, which requires KDE5 libs to run. Everything else is cancer. Especially snaps, fuck Ubuntu lock-in.

Attached: 1520542324930.jpg (3125x3508, 1.19M)

owo

Docker isn't being discussed.
And if you are my respondent, so are you admitting dependencies are non issues when source compiling compared to a wrapper that duplicates dependencies.

So is this right?
Appimage's are fine and easiest to use but could have security flaws.

Flatpak's have better security but are made by poettering.

Snaps suck because it's locked into Ubuntu?

Docker is more for deploying apps on servers?

Attached: c5c9f25117dfd4ca1d01e009b7121f41ee78e9c7b1fdd3cd97a1d975b3d5f46e-tech.jpg (640x911, 47.06K)

T. retard who can't read.
If you want to just re-invent the package manager and manually patch shit instead of virtualization another package system which all this shit allows. Enjoy your security bugs faggot.

Attached: 87bc370dd017f9e90bb86a2dc84a00f1516a208af4ee961cd8ad35193d23b2b9.jpg (643x768, 75.88K)

Talk about timing
flatkill.org

You are confusing.
I thought that by being able to read and verify every part of the compilation process I have more control and can fuzz with test cases, making it more secure than a binary I downloaded off the internet that pretends to isolate it's run time.
The one introducing docker in the entire thread is you. Or are you dismissing the kernel shouldn't be responsible for isolation resource, and instead a binary downloaded off the internet?

This has been discussed for a while, im not sure why anyone would willingly use flatpak. The only reason people did is because they were plebs who couldnt find a way to properly install proprietary shit

This also means Appimage, snap, etc. are vulnerable to the same vectors described in the post.
Oh well, never cared about these bundles of trojans.

You the idiot STILL fail to understand that this IS the kernel isolating resources. These are just utilities that use the existing kernel protocols to setup up sandboxes. All these tools docker, flatpak, snap, lxd, are using the same kernel features.

Docker running some statically linked distro (suckless gang wins again) is better, and has actual features (load balancing over a cluster, for example) instead of dumb memes and a GUI.

>this are the kernel isolating resources
I'll assume you're a secondary English learner.
Why would I implement these, than source compiling on a hardened [micro] kernel.
Explain to me the advantage.

Because compiling shit and then running it provides no isolation what so ever.

Look faggot grammar cucking is for reddit

Attached: 1538405312653.jpg (640x504, 18.14K)

Could a sandbox even work with something like Gimp? Being able to write images to any directory is something I would expect from an image editor.

Snap and flatpak straight up make my software run faster. It's alright

You could disable network access, have it use the secure mode x connection (can't key log you like x over ssh), limit it to your images folder (and the config folder), and then you have a way way way more secure image editor that can't destroy your user after you open a meme with an exploit in it.

If this was improved on you could have a mode that isolates everything by default and then gives you a popup.
Things like this would make every day applications way more secure for the average user.

The desktop OS permissions model is just fucked and no amount of ghetto rigged patches will solve it, I am afraid. How many programs you have installed need full disk access? Your GIMP doesn't need access to anything else than media directories, nor most /tmp files; GIMP may be a benign and hard to exploit program, but what about Firefox? Why the fuck does it have access to your .bashrc? You know finding an RCE and then modifying it to load your backdoor is the easiest fucking way to install a userland keylogger to get your root password when using su or sudo from one of your terminals, then proceed to infect the rest of the system, right? Given, it is very obvious, but who checks their all their init files daily before writing their passwords?

Also, why the fuck are the kernel's security extensions only set-able by root? Why can't I, as a user, tell a program not to have access to certain kernel calls? In order to set up certain sandboxes, you need to invoke a SUID executable to set up all correct permissions, which kind of defeats the point of security.

We need to get our shit together. Sandboxing is a patch; a nice patch, but a simple patch over a gigantic hole, after all. Not all programs need access to every capability, and you don't need to escalate privileges to limit privileges. That's just stupid. The only OS that gets this more or less right is Android, and the rest of it is a dumpster fire so go figure.

Existing package managers are complete shitshows, so any change is welcome. Windows standalone installs would actually be welcome at this point. At least they have one, consistent root install dir.

And let's be far even android is not nearly granular enough. I end up just putting much of the shit I run in it's own VM for each thing. PITA but I have the RAM for it.

Not for the last 20 years. Almost every program is in 50 different places. Hell even minecraft has shit in .appdata

This. Why Flatpak over appimage, if you just want to distribute a standalone program without worrying about dependencies?

Yes.

Always beware of solutions in search of a problem.

That's kind of the beef I have with security systems: it's either all insecure all open, or full blown Qubes autism.

It wouldn't be difficult to design a system with UNIX permissions that let each program have their own nicely compartmentalized area and make it mostly transparent to the user. Set up your home directory to symlink stuff to "areas" (thematic directories owned by their own group: ie folder "images" by "imagesgroup", folder "documents" by "documentsgroup", etc), and set up permissions so only members of the zonegroup can access it. Then, set up a user and home directory for every program you want to use, register them in the groups of the common zones you want to let them access (most programs have clear areas they should or should not access, so sane defaults may be applied: Firefox doesn't need write access on .bashrc WHATSOEVER, and questionably read access too), then symlink them to their homes too. If you want extra security, and I know some people will slap me for saying this, you can chroot them too and only symlink strictly the stuff you need (contrary to popular belief, chroot is a security enhancement if the program you are using is not run as root or someone finds a way to escalate privileges, in which case you are fucked with or without chroot). Use LXC maybe. Configure Xorg to accept clients running under a different user, and the configure Pulseaudio (via UNIX sockets) or whatever system you are using to accept audio from other users, too, and you have an easily configurable system that only lets each program see what they need to see, kind of like the NixOS store.

This is relatively simple to develop, easy to automate, easy to make it mostly transparent to a user (maybe they will get confused at first why can't their programs see every file in the "open file" dialog, but whatever), and easy to configure with sane defaults (unlike firejail, which sometimes kills programs with the default firejail configs for that specific program), so I do not get why nobody has attempted it.

I don't really understand this argument. Capability people are like, "why can my PDF reader access every file". Where the hell do they get this idea?
If you open a non-pdf file with a PDF reader, it'll say something along the lines of "Cannot open files of this type". I tested this with the zathura reader and evince.
If you open a non-image or non-gimp file in gimp... you actually can't do that. They literally don't show up.

Wow this must be bait no one can be this fucking retarded.

The problem is the fact that there's

Not exactly practical for someone who wants to do a windows style "here's your .exe file installable on every system with bundled dependencies, bro"
Now as for why flatpak would be better or worse for this than snap or appimages, beats me, but that's part of the reason for such solutions' existence, along with sandboxing or some shit like that.

Okay, I will bite.

GIMP has the capability of opening anything, it just politely refuses to open files they do not support. Keyword "politely". If GIMP were to go rogue due to a RCE/buffer overflow exploit (if you wanna learn what's this in a fun way, watch some AGDQ hacks demos to shoe the kind of shit this could do), it could open anything amd overwrite anything, including text files.

This is a really serious vulnerability and it's just waiting to get exploited. Your music player has the potential to upload your saved passwords to some remote server because there is nothing stopping it from doing it, let that sink in. It is even worse that Firefox trusts itself with its own sensitive data, but there is no way around it unless we start implementing some sort of login server protocol to let another smaller, more specialized and isolated program handle logins for other programs.

Yeah I don't really consider that a problem, any more than the existence of distros themselves is a problem. It should fall on individual communities to provide and maintain binaries. Any "solution" to this is guaranteed to be over-engineered and make life worse for everybody.

Other users have said that this makes it easier to distribute proprietary binaries like Steam. That doesn't surprise me, since Red Hat has long sought to corporatize Linux with every piece of shit scheme it cooks up. The problem is proprietary software. If Valve wants to make money off the free software ecosystem while refusing to play along, then we shouldn't roll out a red carpet for them. Let them distribute their own fucking blobs.

On the whole Linux is completely unrecognizable to me compared to when I started using it. I'm so glad I jumped ship when systemAIDS was being pushed on everyone.

The main issue is we fucked up from the beginning. The whole RPATH shit in ELFs is dumb and shouldn't exist in the first place. Libraries should, in some way, register their "capability" and version to the system themselves, rather than letting packagers decide where to put the libraries or how to name them. Regardless of where the dumb fuck packagers would put it, libraries would be accesible by the linker as described by the ELF (which would now name the required capability and version number) regardless of where they put it or how they named them, as long as they didn't patch the "capability" name registered themselves, which they shouldn't do unless there is a conflict between two libraries or they are retarded. By registering both capability and version, you could even have several versions of the same library installed, and all of them would just werk; in fucking fact, you could use semver to let the linker know when you can use newer versions and when you need to keep older versions.

tl;dr we went so deep in the bazaar we can't build cathedrals with our bazaar-exclusive tools

So isn't running a random binary online.
Next

Felt, >>>/grammar/

Depends your threat model.
I'm waiting on my respondent to answer.

Thank you brother.

How is pkgsrc 'shit'.

Because sooner or later your dependency will be new hardware after a nice rootkit.

I didn't know Jails were difficult to implement.

It's ok not knowing how to make

...

Being able to handle multiple copies and different versions of libraries is better engineering than not being able to handle them.
Being able to reuse the same version of a lib for multiple programs is good too, but that's not in question here.

They're the latest in retarded nu-loonix memeware designed to turn Loonux into Wangblows 2.0.
Other memeware in this category include SystemDicks, PissAudio, Rust, and Go.
Speaking of memeware, Linux itself is memeware at this point since Torvalds cucked out.
BSD is the future. At least BSD isn't suffering from this influx of memeware... yet.

Attached: f4a146da82deec5f28399778e087dd40070be680c40b27ff0afa7d087619fae0.jpg (1001x678, 228.75K)

You are saying this like you couldn't before these existed. Like if we didn't have /dev/usr/build/2.5/gimp/ &/dev/build/stable/gimp
Oh wow, tell me more about this! How intricate are the rollbacks compared to git revert!
So, you're saying you couldn't experiment on Development while on Stable, all the while isolating dependencies on a separate build partition. I wonder how software ever got made then.
Oh, I didn't know some people didn't know how to use wget tar.gz && tar xzf
This magical sandboxing, can you view the source code, and process intricately?

wut

The idea is

git is for code. He's talking about rollbacks of literal binary compiled programs.

I know what you mean, but new users *must* understand that GNU/Linux/BSD/UNIX/whatever isn't Windows.

Both Gentoo and Slackware just use standard tarballs (or git) In addition to makefiles, Gentoo also has ebuilds which are similar to PKGBUILDS in ArchLinux. But I agree that Appimages and Flatpaks can be useful for installing software with a lot of dependencies or non-free software.

You can already have different versions installed at the same time. You can just fetch the source tarball and install it to your home directory, or use portage (or some other package manager that supports it). OR Install GoboLinux
You could use the filesystem (like ZFS or HAMMER or things like LVM) or tarballs to do this.
This completely defeats the purpose of using a distro that's made for servers and corporations. Just install Debian sid or whatever.
How? Why? You can sandbox programs without Appimages, Flatpaks or Snap cancer

Why is that? When a browser security update rolls out, I want that update this instant, not when the middleman (maintainer) finds time to update the package.
Except.. It doesn't help proprietary software in particular, it just helps everyone.
Btw (((proprietary))) software developers tend to not like user-controlled sandboxing. It may e.g. prevent Chrome from benevolently scanning your files, you know

W-wait wasn't free software all about choice?
I, like most users, want some software to be fresh, e.g. browser, editor, games, etc, whilst I want the kernel, init systemd and shits to be stable and secure. There's nothing in the latest linux that isn't in lts that I miss on my desktop.

Do you even security?
But flatpak makes that easy and out-of-the-box'y. Also, appimages are not really similar to flatpak or snap

GUIX looks really attractive to me. I want freedom in my software, and the ability to have rollbacks and generations all wrapped up in Guile is nice.

Is that what sold people to Windows?

... And how is that 'safer' than source builds?

THANK YOU
These LPoS inbreeds want NotWindows, with all the flaws, faults, and botnet.

And if your fresh software breaks your stable kernel, what do?
Do you?
So does a rootkit!

There's a scalability issue in their model.

Wut
How can a browser "break" a kernel again?
Ah, never mind.

Alsa + jack has never failed me once and works fine
Fuck off.

You've never vectored video&images to break your display server?

more like
but at least you can play your videogame user

None of the BSDs even have the GPL to mitigate the damage these mentally unstable eunuchs are wreaking in F/OSS. They're a stop-gap at best.

The license doesn't matter. You can fork GPL or BSD code. What matters is: how clean is the code? how many developers do you need? (not many with NetBSD or TempleOS. too many with Linux. others are in between).
And also the people in charge and the general culture of the project matters more than the license.

I agree. As long as proprietary licensed code is better use it.

To clarify (if it wasn't obvious), I was talking about "open" licenses, where you can legally fork the code. Obviously if you use proprietary code in your open source project, it's going to invite lawsuits.

The license DOES matter when we're talking about CoCs and EEE. There is no kind of defense for making proprietary forks that are simply better than the open version

Faggot.

Attached: DU9VGaJV4AAVumt.jpg (591x585, 39.6K)

this is your brain on down syndrome

That's a hypothetical scenario that has no basis in reality. What happens is open source project gets subverted with corportate goons into key positions, and then the license doesn't matter because it's still the same license as before. Linux is still GPL, and FreeBSD is still BSD, and you can use them all you want, if you don't mind the SJW and big corporate stank everywhere.
So the personality of the individuals involved is more important than the license, because that's what decides how well they resists subversion. And so long as *their* project continues unmolested, it's fine. The fact that someone else can made a closed fork, or a CoCked fork doesn't matter. That's a different project, not theirs.
And the size and cleanliness of the code matters also, because then you can still recover in the event the mainline gets subverted somehow. With Linux, it hard. With NetBSD it's not as hard. That's again not because of the license, but just plain technical reasons.

Nice projection there.

This isn't hypothetical; it's already happening to the MIT-licensed Clang compiler with proprietary extensions.

Attached: fang_the_wyvern_by_fer7dragon-d4el5j9.png (2448x1828, 2.7M)

okay bud nice proprietary goal u got there

Are you retarded? The GPL doesn't even say that. What the fuck is with these /g/tards posting here the past few weeks?

Attached: DnNueLaX0AAwJPY.jpg (1187x399, 69.31K)

GPL specifically says that I have to follow the GPL for any code I write that happens to depend on yours. It is a proprietary license that does not respect user freedom.

Keeping code GPL isn't the same as disallowing people to write their own modified versions, my dear immigrant. The only reasons you'd want to do that is either to be a dick to your users, or hide your shitty code.

You faggots done? Can we get back to alternatives for packaging Linux apps? Personally, I think we should go back to square one and resurrect FatELF.

Attached: 63915fa22faffc19ebe6a948c8be8fed.png (1058x1500, 727.28K)

...

Info: icculus.org/fatelf/

Attached: 112df5268461c268e40614ea0f330731.jpg (951x500, 149.05K)

.tar.gz
.dar.lzma

Attached: d33b43959390e8dfe5ab5ba4143fdb3ef8d6e1ba31cf5fafe8ceb32caa7ddfda-v.png (2000x1304, 2.08M)

Nigger we're talking about stuffing binaries and libraries into THICC FatELF packages. You can open another thread to sperg over the GPL.

Attached: 68a510c4fe16dd2f5bd063d677ba5c6b.png (659x1200, 161.33K)

Obviously, the standard will need to be updated a little.

Attached: 9a3323fb863dcc0ca0d0d9986de7dcce.jpg (1000x1314, 314.68K)

What a wonderful idea!

Attached: aHR0cHM6Ly9zb2NpYWwuc3VwZXItbmljaGUuY2x1Yi9maWxlLzk4NTcyY2NkMmFlMTFhN2UzMDA2ZTVlNmIzYjU2ZGUzMDk0ZGM4ZGZkNzJkN2Y3ODBhYjQ1Zjc2MjJjZmQwYWYucG5n.png (595x850, 304.3K)

Let's deviate as much as possible and use DEFLATE instead!
We'll call it .EXEcutable!

Attached: 1fed34f18b00ae749b3ecc04fb853b916a786d323edf2afe48966282a7daa19e-animu.jpg (986x1140, 144.48K)

FatELF is the granddaddy of these universal packages, how new are you?

Lets keep 'ELF' in the name as a justification to post lewd elves.

Attached: 00dffb2104b029092a5a1969c3b442b2.jpeg (1200x1500, 240.22K)

Oh goodie! And how do they isolate anything?!?

Attached: e5092f0fd9005a8bb9f421454abc53e49d5129f0a08d7df6b550566756a6283b-v.jpg (688x971, 222.38K)

Same was as Appimage can would work.

Oh great! Let's make another dependency!

Attached: DoRhRb3W0AAm3vG.jpg (750x750, 57.59K)

Nice...

Attached: DTm8dqqW4AAp4O4.png (1200x1200, 872.18K)

And how do you propose we handle 3rd-party application distribution?

There's a thing called `make`, it's really cool!
Also pkgsrc has been recalled 2x

Attached: d8829ca75cbd84d2ded8047ad60449a5d305c06f230095f7a13ba87c24bef5b8-monster.jpg (1365x2048, 285.23K)

How's that going to work for proprietary apps?

This is why Blender being free is a bad thing.

Attached: Cq9M97sUkAAsAcS.jpg:large.jpeg (1434x2048, 105.44K)

just don't run them, same for GPL, don't need em

We don't give a shit about (((proprietary apps))) so you can fuck off back to /g/

Attached: 316a737f4ffff2194a48dafa4219985b69202014b30a3b3371379e20840a1237.png (240x265, 77.8K)