Developers from multiple Linux distributions and companies today announced collaboration on the “snap” universal Linux package format, enabling a single binary package to work perfectly and securely on any Linux desktop, server, cloud or device. This community is working at snapcraft.io to provide a single publication mechanism for any software in any Linux environment. This release quotes Dell, Samsung, the Linux Foundation, The Document Foundation, Krita, Mycroft, Horizon Computing, contributors to Arch, Debian, OpenWrt, Ubuntu, and several of their related distributions.
https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on-multiple-linux-distros/
http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/
>>55089450
linux is a meme
Why don't they just use APT???
Why ignore a perfectly good package manager because you wanted to be a special snowflake???
WHY DO THEY ALWAYS DO THIS SHIT
YES, IM MAD
>>55089474
>apt
It's bait boys, don't fall for it
>>55089450
For some applications that are written and packaged by retards it makes sense. For others it's a waste of space, insecure and the best way to drag Linux into the turd that is the windows way of package management, with stupid developers hosting snaps on their own site, which you have to hunt for.
>>55089450
Noob question: would maintaining 2 package formats on the same distro be too much complicate?
I mean, do .deb, pacman and friends receive crucial updates that require a lot of code to be rewritten? I don't think so.
So can't they just implement this new Snap thingy while keeping their old package format and make everyone happy?
>>55089450
This is literally windows.
They're trying to turn linux into fucking windows with its ass backwards distribution model of including HUNDREDS OF CONFLICTING COPIES OF VISUAL C++ RUNTIME
>>55089497
Fully argree with you on that one.
>>55089533
I'd like to see that too.
>>55089537
See >>55089497
>>55089537
>packages modify the core Linux filesystem layout
You know, it's at moments like these I am happy I compile all my soft. I really doubt Snaps will integrate with Gentoo well, or at all, and thank goodness they won't.
Snaps are a stupid concept and I can't even grasp what problem they were trying to solve with it, from those that aren't solvable trivially.
From what I've read of them, they just seem like a reinvention of LD_PRELOAD + sandbox, maybe a bit more retard-proof than those.
Like, hell, I guess proprietary shit can use them, I've got nothing against that. But please, don't touch the actual ecosystem with them. They're only good for isolation.
Hell, didn't NixOS do it better anyway, while still preserving the benefits of traditional package model? Why don't they just copy that, at least? Not that I used it, so may be talking out my ass.
>>55089474
Because people don't want their DE getting uninstalled when they uninstall a text editor
>>55089474
Because people like dropping shit into /opt and you can't stop it.
>>55089617
Maybe maintainers should just gets their heads out of their asses then? In any case, that's a stupid solution to the problem anyway. It's like you caught a nasty cold once because you were too dumb to put on a coat in winter, so you decided to wear a fur coat al year round.
>>55089633
Proprietary stuff probably should do exactly that. But why invent a whole new format just for them (when you can just drop a couple of .so files into the /opt folder instead and LD_PRELOAD them) and PR it as a great new thing everybody should use and the future of Linux desktop?
>>55089450
Is it true that you need ubuntu one account to install snaps on ubuntu?
So what happens when they need to push a security patch to openssl?
Now, instead of the distro maintainers, every single software project has to patch and recompile openssl upstream and then force users to install the updated snap package for every application.
>>55089537
>os developers dont have to waste time keeping up repisotories
>can focus on developement instead
>this is somehow a bad thing
>>55089706
Oh, because managing what random shitware is dropped into /opt is keks.
Everything at my work is done that way and its fucking gross. At least this snaps shit will add a clear management mechanism to the problem.
>>55089450
>binary package
>secure
It won't come with SSP or other security features enabled because "it's hard to make shit compile." It's going to be shit.
>>55089743
Oh, it might also kill ansible for deployment uses. Quite possibly the stupidest piece of shit I ever used.
I don't get why doing
ssh some server shell < script is so hard
>>55089706
I wasn't showing support for snaps, I was just saying apt is a piece of shit
Thank god Gentoo isnt falling for this scam
>>55089797
>I don't get why doing
>ssh some server shell < script is so hard
Probably because all it does is run the script. You want a package that you can safely install and uninstall. Package maintainer wants a place that lets him publish the package easily. It just seems like snaps are a superior solution, best for everyone.
>>55089827
>
http://snapcraft.io
>>55089827
http://snapcraft.io/
>First install snap-confine.ebuild then snapd.ebuild
>>55089741
>os developers
Too ambiguous.
Either downstream (distro dev) or upstream (original software developer).
Many linux users wont use upstream directly because of ease of updates, security, trust-ability and stability.
Let the distro dev test the package first, if ok then ready to consume.
The only reason of using upstream directly are running bleeding edge version or not available in repo.
>>55089706
snap are supposed to run on separate container (sandbox).
>>55089450
How do updates work? Do snaps have some sort of update mechanism?
>>55089879
https://developer.ubuntu.com/en/snappy/guides/autoupdate/
>>55089841
I was talking about ansible, but OK dude. I already addressed and voiced those same concerns earlier.
who controls the snaps?
why should I trust someone trying to centralize everything?
why wluld i accept proprietary snaps into my system?
>>55089852
>>Many linux users wont use upstream directly because of ease of updates, security, trust-ability and stability.
I would definitely prefer to use the original software without the middleman.
Snaps were literally built for that, for letting software devs easily publish their software, ignoring distro devs, so even if you say that some users would prefer to wait for distro devs to release the software, that kind of does not mean anything.
>>55089899
>why should I trust someone trying to centralize everything?
You mean like your distro dev?
Snaps are actually less centralized than your distro repository - snaps just deliver original developer's binaries to you, while distro actually creates them.
>>55089450
I like the idea of snaps for testing. Like docker containers.
However, I can't responsibly run 9001 versions of openssl in production, and trust each dev to update the version in their snap next time there's a bug. There's a reason why dependencies are separate packages.
>>55089889
>Autoupdate, enabled by default
>Every time autoupdate triggers it will try to update the whole system; if an ubuntu-core update is available the system will automatically reboot
What the fuck.
>>55089938
I just gave the fuck I kept ungiven for years.
>>55089938
Shit like this is why ubuntu will forever be known as a babby os.
>>55089741
They didn't need to do it anyway.
If your program is useful, somebody is gonna start maintaining it, eventually. Just make sure to PR it somewhere and to make it good. Maybe maintain one package for your particular distro.
In any case, what distro does or doesn't care for your program shouldn't worry you. Just make it good and PR it, and let them judge its worth by themselves.
What Snap does is exclude the maintainer out of equation entirely, while not substituting them with anything, with all the drawbacks that entails, because apparently maintaining is too hard and idiots can't keep up, or whatever.
>>55089743
Can't comment on that. How exactly do you need to maintain /opt stuff, and how are snaps an improvement? I didn't work with /opt stuff extensively.
In any cases, these are only for shitware packages, but it could maybe justify its existence. I still see no reason to include it in the actual open-source ecosystem.
>>55089843
>>55089849
These are just a bunch of ebuilds. Anybody can write a ebuild. There are ebuilds for dnf and pacman in the tree. It's still not gonna integrate into Portage well, or at all, and it's antithetical to what Gentoo is.
Hell, do you know that Portage can't actually be uninstalled without breaking the distro? It's a little known fact. Portage is tied to Gentoo, and Gentoo is defined to Portage. You can use a different package manager, but even then you don't uninstall Portage, you just ignore it, and it's barely Gentoo by this point.
And compiling software actually makes ABI a non-factor, except for the fact you should recompile it when ABI's broken (and Portage tells you about that if ebuilds are written well). The package doesn't change at all, unless API is changed. There's only an exception for binary packages.
How are snaps gonna fit into that? They aren't. The most involvement I could see of them is being another type of binary package that Portage handles on its own according to ebuild (like it does Skype or Steam).
>>55089600
Snaps are on Gentoo right now.
>>55089978
Why are you talking about uninstalling Portage? No one is suggesting abandoning your distro's package manager.
>>55089871
That's the only thing I can think of that actually makes them worthwhile, and it's just a sandbox. There are tons of sandboxes in Linux world.
>>55090005
>That's the only thing I can think of that actually makes them worthwhile
How about convenience?
>>55089909
Then use Arch. That's what it actually means by "simplicity" - "we only provide the minimum necessary patches for it to compile, sometimes, if we feel like it".
>>55089909
Why? Is there any advantage to not having the trusted middleman who handles it all for you?
>>55090000
Oh, I must have misunderstood. Now that I think about it, package manager isn't supposed to be involved in snaps handling at all, right? They're just like exes, you click and they install by themselves?
Then I guess they would fit fine into any distro. I assumed they have their own separate package manager, or something. Probably mixing them up with Redhat's Flatpaks+runtimes.
Still, I assume the main method of getting soft on Gentoo is still gonna be compiling. The other distros can drop their dedicated servers for binaries in wake of Snaps, but with Gentoo you compile everything yourself anyway.
Still, that was my bad. I misunderstood how they are supposed to be handled by individual distros.
>>55089925
why would i accept a binary into my system?
do you not realize how harmful that is?
>>55090163
>Then use Arch. That's what it actually means by "simplicity" - "we only provide the minimum necessary patches for it to compile, sometimes, if we feel like it".
The software is ultimately provided by arch devs and not original devs.
>Why? Is there any advantage to not having the trusted middleman who handles it all for you?
Delay.
>Oh, I must have misunderstood. Now that I think about it, package manager isn't supposed to be involved in snaps handling at all, right?
You understood correctly - they do have their own package manager, and it just lives alongside whatever system you have.
>>55090184
Accepting source code and blindly compiling and running it is also harmful. You have a point, but it's not as meaningful as you present it.
>>55090198
you assume we accept aource code blindly, which is false.
There are other benefits to compiling on your system as well.
>>55090030
It's technically the same thing.
There are already sandboxes, there is already LD_PRELOAD and there is already /opt, as separate entities.
Snaps just merge them together for convenience. That's their only benefit - they do the same stuff you could do before anyway, but you add a convenient sandbox.
That's still not really enough to make them a separate entity, and I'm sceptical about the concept that there was a problem they needed to solve. In particular, because Canonical talks about how they are great for all your soft, I can't find a part where they talk about why it's better than /opt, anyway. They might be worse or the same as far as I'm concerned.
>>55090221
I'm saying that you, as a user of your distro, accept source code from the diestro blindly.
>>55090231
Did you just write that wall of text to literally confirm what I said - that snaps also offer convenience?
>>55090221
>you assume we accept aource code blindly, which is false.
are you seriously going to argue to him in front of all of us that people actually DO go through the source code of software in a comprehensive fashion?
the point of OSS has never been to exercise this ability, but to leave the door open for a group of people to do it if need be. no software of any substance is within the realm of a single person reliably evaluating, anymore. it hasn't been that way for a long time.
>>55090246
>>55090234
we have committees that are dedicated to his before we accept a developers code.
Please dont act like we are blindly taking in bad code.
>>55090246
Case in point: the Shellshock/Heartbleed bug went unnoticed for like 2.5 years. This was despite numerous explicit checks to prevent this sort of thing from happening (to say nothing of the supposed affordance for tons of people to exercise their ability to evaluate the code for themselves).
It's an empirical fact that no single person groks a distribution and all of its source code. If you think someone is out there, or worse if you think you're someone special, you're delusional to some degree or another.
>>55090258
>we have committees that are dedicated to his before we accept a developers code.
So did you spot >>55090274 way before everyone else or did you just not use SSL between 2012 and 2015 because your committee was backlogged on vetting software?
>>55090258
I will say this again, for the third time, and will elaborate even more this time because you seem to have real difficulties understanding simple things.
You accept source code from your distro maintainer blindly. There is no guarantee that it's the same code as the code displayed publicly for public scrutiny. No amount of cryptographic failsafes will guarantee you that it really is that same code because all those cryptographic failsafes are handled by that very distro maintainer we are suspecting of giving you bad code.
>>55090281
>>55090274
subtle bugs are one thing.
malicious code that is harmful to the system is another.
blindly accepting a binary straight from a dev is far more harmful than at the very least checking to ensure its not malicious.
Finding every subtle bug is not the goal of the committee, its there to keep bad deva from publishing intentional malicious code straight to users. Something your ayatem dails to do until people are infected.
>>55090198
>The software is ultimately provided by arch devs and not original devs.
It's the same source code with minimal patches. What's the difference?
My dorm neighbor talks all the time about how Arch prides itself on not bothering with patches.
>Delay.
Wow, I wonder what distro there is that puts packages right after they're out? I wonder how they do that too. Must be lots of testing and custom patches they're making.
>You understood correctly - they do have their own package manager, and it just lives alongside whatever system you have.
OK, then it's not gonna integrate into Portage or the system at all. Then how is it gonna substitute "old and busted" methods of software distribution? Or is it gonna be just a little thing on the side of the package manager after all?
>Accepting source code and blindly compiling and running it is also harmful. You have a point, but it's not as meaningful as you present it.
It's still safer than accepting a binary. Security is not a thing where you do something, and now you're safe forever. It's more like, you do something and slightly decrease your chances of being fucked in the ass, unless your opponent brings a bigger dildo, but he might not have enough money for that one.
Also, this is what stable releases and testing are for, in part. They don't check everything or even most of the source code, but if there are obvious warning signs, they're gonna notice.
>>55090293
wrong, we have audit trails and ways to check against original source to verify its legitimacy.
iTs that of binary managers that lack these and give the user blind binaries with no verification possible.
>>55090327
>It's the same source code with minimal patches. What's the difference?
The difference is you will not receive the software at all unless arch devs choose to release it.
>Or is it gonna be just a little thing on the side of the package manager after all?
I think they plan to become big, but they're starting as exactly that - you'll just install few snaps you use and nothing else.
>It's still safer than accepting a binary.
I can't argue with that, but it's not as black and white as some paint it. there is still issue of trust. And for some, convenience might be more important.
>>55090338
>wrong, we have audit trails and ways to check against original source to verify its legitimacy.
Let me guess. Provided by distro developer?
>>55090242
I don't know because nobody explains to me what this "convenience" is, besides a simple sandbox and merging them into a single entity.
If it's just a sandbox and making them a single entity, I'm arguing it was not worth it.
>>55090371
>I'm arguing it was not worth it
If they start getting lots of users and the system becomes popular, what exactly is the problem? What is not worth it?
>>55090364
theres no use in arguing with someone who clearly uses a subpar distro that blindly hands out binaries with no verification means or source from which it was compiled.
Enjoy your windowsification of Linus since thats your goal here.
>"With snap packages, applications are installed in their own container, and all the third-party applications are installed with them so there are no version conflicts. Snap packages are also smart enough to not install a package more than once, meaning applications installed via Snappy don't take any more disk space than regular applications."
>>55090404
>i can't refute so i'll just post personal insults
i'm so sorry anon
>>55090423
your refutes were literally "i dont understand your aystem so it must be as bad as our binary package systems"
its like arguing with a retard
>>55090454
>your refutes
And you call others retarded, lol.
>>55090454
I formulated my arguments very clearly and carefully. I do understand how you build your software. If you can pinpoint a problem in my reasoning, by all means go ahead. You are simply ignoring my reasoning instead.
>>55090364
>The difference is you will not receive the software at all unless arch devs choose to release it.
They have Skype in community repositories, because of popular demand. And I think, community repositories are official and soft is voted in based solely on popular demand.
The core, though, I think the developers handle.
Still not enough? AUR, the biggest software repository in the entire world.
There are tons of git builds there, if you want the latest. If you don't want the latest, pick a stable release there too.
They're all compiled, I think.
Why is it so expansive? Because it's run by casual users (who might or might not be developers themselves), so that you can get the soft arch devs "chose not to release".
How do you check that they didn't fuck you in the ass? You check a pkgbuild.
You don't trust the pkgbuild to be good? Well, that's why they say that AUR is not really "safe", there are basically no barriers to entry there (just like there aren't with Snaps). It's a conscious trade-off.
Look, the problem is solved, and we didn't have to give up the entire concept of the ecosystem for it.
>I think they plan to become big, but they're starting as exactly that - you'll just install few snaps you use and nothing else.
And I don't get how they are planning to become big, if they have their own package manager. How are they planning to integrate with, say, the Portage tree that compiles everything?
Or maybe Gentoo is not a target besides "it's able to handle the format if it wants".
The thing is, I don't see how it can integrate into the existing subsystem besides being a little thing on the side. It's either a little thing on the side, or it substitutes the current solutions completely. And Gentoo and Arch are not gonna agree to that, at least.
>it's not as black and white
I'm not even against binaries, I was just arguing against "source code is as harmful".
>>55090567
>we didn't have to give up the entire concept of the ecosystem for it.
Snaps do not require you to give up your existing ecosystem neither so I don't see a benefit in what you explained.
>How are they planning to integrate with, say, the Portage tree that compiles everything?
They plan to let people abandon Portage in favor of them - Snaps work out of the box on any linux system.
>The thing is, I don't see how it can integrate into the existing subsystem besides being a little thing on the side.
That's simple. it slowly becomes bigger and bigger. People start to prefer versions of software offered by snaps to versions offered by distro devs. I'n not saying it will happen - but I think this is their plan.
>>55090382
Well, it might, but it would mean it was nothing more than reinventing the wheel with new marketing and a sandbox stuck on top of it.
Honestly, if it did just that, I wouldn't even have a problem with it. It's barely something worthwhile, but it would technically improve upon what we have now for closed-source shitware that can't bother on learning about how things work on Linux. They could use that as a solution for "drop-in executables" they wish for so much, and everybody else would ignore it for a better one.
The thing is, they market it as a magic bullet to problems none of the actually well-handled software ever had, the solution they chose has major conceptual limitations and is technically an inferior way to handle software at all. They apparently plan to promote it and let it eat the current system.
And I hate the idea. The current system is better than this one.
If their solution was better, maybe even with some trade-offs compared to current system, but if it had massive benefits, I wouldn't have a problem with it. If they didn't plant to use it on stuff it doesn't fit on, I wouldn't have a problem with it.
But it isn't, and they do, and so I'm annoyed by them trying to push it.
>>55090700
What system exists that offers benefits of snaps, particularly including running on any linux, allowing a developer to easily publish his program to work on any linux?
I hate the idea.
This only is advantageous to nonfree software (so it doesn't provide any benefit to me).
Ignoring that though, the great thing about the common GNU/Linux package management scheme is that packages can be updated independently.
When we had that encryption shit in OpenSSL ages ago, it took me one package to update and everything was completely fixed. Even packages which had not had upstream support for years.
It also means a return to the days of keeping downloaded copies of every program I've installed so I don't have to hunt for it if I want to install it again. Bigger distros like Debian and Arch keep a copy of every package they have ever hosted in easy to install format.
Shit, debian even still release a DVD set with every package they have in it (which is great as a backup).
>>55090612
>Snaps do not require you to give up your existing ecosystem neither so I don't see a benefit in what you explained.
With soft basically being independent of the ecosystem and taking all it needs by itself? It's a major overhaul. Now you can't fix an OpenSSL error by just changing one package, you need to update all soft that uses it.
The ecosystem basically becomes mostly irrelevant to Snaps.
>abandon Portage
Then it's not Gentoo anymore. Gentoo is defined by Portage and the framework it allows for building your own distro. Do Snaps have USE flags? Does it allow you to harden everything, easily use libressl instead of openssl, musl as your libc and runit instead of OpenRC, on the whole system, switching whenever you feel like it? Can you compile soft with it?
If not, then why even call it Gentoo anymore? Gentoo is tied to its current software management model. If you kill its current model, you kill Gentoo, so there will always be distros that don't use Snaps instead as a thing on the side.
>>55090810
>The ecosystem basically becomes mostly irrelevant to Snaps.
That is the primary purpose of snaps.
I won't argue that there are downsides - like the one you mentioned with OpenSSL. But there also are advantages. Convenience. And, again, for some, and maybe for a lot, advantages outweigh disadvantages.
>Then it's not Gentoo anymore.
I'm not saying it is? The aim is to get users to ultimately abandon stuff specific to their distro and just use portable snaps (again, according to how I see it).
>>55089600
Nix/guix packages are far superior to snap packages.
>>55090722
Writing a LinuxBrew recipe would do the job.
That shit installs on any linux, and you just write the damn recipe once.
Other than that, if you want to ship binaries, just statically link all (or most of) the libraries.
>>55091048
Seems like a fair alternative.
I guess in the end the better one will win.
>>55089450
Is it free as in freedom?
>>55091159
It is free as in freedom.
But not as free, becuase it has limitations :O
>>55089450
That's great. The more standardized and consolidated Linux as a community is, the better chance there is of there ever being a "Year of the Linux Desktop". Greater distro interoperability is a good thing.
>>55089450
I did the same thread last as I was hyped to try it out. Right now I'm disapointed, it's not easier to package and the
packages take too much space, just look at libreoffice on fedora, atleast 4 TIMES bigger than the traditional download.
I read some mailing list and all I saw was disappointment.
Canonical is lost, they don't have a clear goal anymore, just look at unity and mir, half-assed works that barely bring something new in
the DE world.
ATM snap packages are the same.
I just learn a few minutes ago on phoronix about flatpak, I'll try it later today but so far these "new" packages manager are disappointing
and don't solve any problems.
>>55092204
Canonical is the worse company on the linux community.
>>55089450
The question is: Will this fix the inexistent separation between the installation of a user app with system ones?
>you have to sudo to install firefox
THANK YOU BASED UBUNTU FOR SAVING LINUX ONCE AGAIN
>>55089970
we need more people in linux and that's a way, not "the" way but is something
Snap seems like a great idea for small programs that don't get updated frecuently to use newer libraries, but for system programs snap is not an option.
>>55089450
>Owncloud
How old is that?
>can't use snaps with an encrypted home folder
HAAH WAAW
will give it a shot in a vps, since they got a nextcloud snap set up.
Looks like one package for all distro doesn't really works.
>So, even if you took all the installers for every OS and added them together, you would still come out at less used space than the single LibreOffice 5.2 Beta .snap package. To snap's credit, it did function. Less to snap's credit...the binary appeared to be Ubuntu-specific.
>I can only guess that since it was, most likely, compiled on Ubuntu, under Unity, I can only guess it's attempting to render its menu bar along the Unity top bar, which obviously does not exist on Gnome Shell. Have to call this one a peg against the idea of "compile-once, run on any distro", if the distribution the application is compiled on has significant differences towards other distributions.
http://www.phoronix.com/scan.php?page=article&item=ubuntu-snaps-fedora&num=1
Also, fedore people still pushing flatpak.
>>55094540
>encrypting your home folder
KEK
>>55094843
what are you memeing about?
>>55094540
>can't use snaps with an encrypted home folder
Seriously? Why?
>>55089450
>Current year
>Linux
>Package manager
Get with the times grandpa, embrace the botnet with Windows 10 and automatic updates. Your OS knows what's best for you.
>>55094956
i dunno, there is a bug filed for it if you want to see why.
guess i'll just wait until it is fixed to try snaps on my machine.
>>55089450
Dont the kde guys did something similar already?
I just downloaded krita with it
>>55094983
Ah. I thought it was some kind of design limitation.
>>55095018
bunch a fucking implementations of the same concept.
i wish there was a way of getting everyone into one, instead of the clusterfuck of competing solutions, but oh well. we don't live in a perfect world
>>55089706
>not knowing beimg cold isnt the cause of illness
>>55092231
>inexistent separation
Literally install in $HOME/.local instead of /usr.
i can see it being useful as a supplimentary package system, not as a replacement for existing package managers
this would be a better way for developers to make their package, rather than;
- providing a deb/rpm/etc which work on one or only a few specific distros/versions
- providing an executable "installer", which is just plain ugly
- providing a tarball, which some users don't know how to deal with
then package maintainers can convert the snaps to proper deb/rpm/etc packages for their distros
>>55094927
The one encrypting his home folder is the one memeing
>>55095304
Please do elaborate.
>>55095304
no anon, you are the meme
>>55095365
It's practically pointless. If you want to encrypt your shit you should encrypting the entire drive before your OS even starts using something like Truecrypt or Veracrypt.
>>55095500
How does that help? The software that does decryption will still be somewhere, unencrypted.
>>55095018
the downside to that is that there's no way to integrate those into a system, limiting what kind of software it can be used with
memes can be good sometimes, Linux is such a meme.
>>55095280
Aren't there also supposed to be Flatpaks, which are supposed to have dependencies in "runtimes" but otherwise work the same?
Except this one is inseparable from package manager, because you need to download the runtime somehow, presumably with a package manager, and it will sit there, redundant.
That means that while Snaps can be used for that purpose, Flatpaks will be inapplicable for anything but the thing they're forced as: substitution of the current system. Maybe it's not so bad Snaps came out first, after all. Maybe they can at least be reoriented to be useful. Flatpaks don't seem like they could. Or do I misunderstand something?
Is there a snaps package of a working gentoo install in a virtualbox?
Like I just double click it, virtualbox gets installed and an gentoo bottle is automagically getting booted?
>>55095500
No. Do both and you find yourself in a 'deniable' encrypted OS environment.
