Why not snap?

It has been a while since I used snaps but aren’t they auto-updating?

Everyone has their opinions. I personally am much more willing to trust the community here than companies. Others may not.

The other argument I would make against them is I saved like 45-50 second off my boot time getting rid of snaps. I’d reboot even just twice a week, that’s still almost 2 hours a year I waste on start up. And others had even longer times.

2 Likes

Possibly, I have also not used them in a long while, and it is possible I’m misremembering. Flatpaks definitely do not, though.

Bitwarden is in community repo so I assume it is safe to install it from there, isn’t it?

pacman -Ss bitwarden
community/bitwarden 1.30.0-1
    A secure and free password manager for all of your devices
1 Like

I didn’t see it mentioned here yet, but Bitwarden WAS in the AUR earlier this year, but got adopted into the main community Arch repos, so Bitwarden is officially a part of the Arch repos https://archlinux.org/packages/community/x86_64/bitwarden/

If you don’t need the Bitwarden app specifically, Bitwarden maintains their Chrome / Firefox extensions of Bitwarden which actually are the ones that I tend to use the most and it’s trusted enough since they are the ones that maintain the extensions too. But of course only trust said software as must as you trust the company. Hope that helps a little bit!

I do this too, don’t see the point in having the Bitwarden application when I have access to the vault and all its functions in Firefox.

2 Likes

Personally, I would never store my passwords on somebody else’s computer.

I store all my passwords locally, KeePassXC is a pretty solid password manager, in my opinion.

5 Likes

Bitwarden can be self-hosted as well.

1 Like

Possibly, I didn’t know that. When I look at Bitwarden’s website, it asks me to make an account and log in. This is a deal-breaker for me.

Of course, since this is Free software, you can host your own server, but the whole concept seems ridiculously overcomplicated to me. Why not just have an encrypted file with all the passwords?

It depends on your use case. If you need your passwords to be available on a large number of disparate devices, syncing an encrypted file around can be more work than it is worth.

2 Likes

Certainly possible. For me, however, I don’t think I’d trust myself not to accidentally delete it somehow, and I’d rather not lose access to the ~50 accounts I have stored in the vault, so I chose to trust Bitwarden instead.

1 Like

I don’t buy that as an argument, because it holds for any file. In fact, there are files I would be much more upset at losing, than my passwords database. Sure, it would be a pain in the butt to reset those 100 or so passwords, but it would be doable.

But that’s what backups are for.

1 Like

You can check the source variable in this PKGBUILD also, to confirm it is build from verified github source.

2 Likes

Yep. I could take backups and restore them if I lose it, I could make it automated as well, but that’s a lot of hassle for a non-issue for me. Same would be said for restoring accounts should I ever lose the file/backups, I don’t remember usernames, passwords, contact information and other notes I have stored in Bitwarden. Most accounts I hold have an alias for email, which I would not remember. So I would have to start with restoring SimpleLogin, and then test the ~8 email aliases I rotate on each platform I can recall having an account on. That would restore access to some of the accounts, but other data, such as notes and contact information would be lost. I also doubt services like Microsoft, where I have 2FA (via bitwarden) would allow me to reset the password without contacting them and proving some form of identification.

This is not worth the hassle to me, and as I said above I trust Bitwardens enterprise servers far more than whatever disk I would store backups on.

Actually, you don’t have to trust anyone when using the AUR, it’s an entirely transparent system. You can see exactly what is being done to your computer when installing the package, and you can see exactly where everything is being sourced from. You only have to understand how it the AUR works.

1 Like

Snaps use extra space, tend to be slower than flatpaks & appimgs, are being forced down users throat by canonical, and Snapd has a history of extending boot time or stopping booting entirely.

That’s the short of why snaps can die in a fire

Edit: I’m also not partial to flatpaks or appimages either.

If I had to choose it’d be AppImage

1 Like

I will use deepl again for this text, because I want to make sure that I am understood. Because I want to say a lot of things that the “hardcore linux users” would be outraged :smiley:

So, along with this thread:

I almost got a small heart attack.

For me personally, snap, flatpak and appimage is the worst thing that could happen to the Linux world. This just shows again that in the Linux community or in the developer community that make a lot for Linux, can never agree. Sure it makes sense in many areas to have a lot of choice. But in some (and especially those are often critical) areas that makes no sense at all. And often even, the “solutions” exist only because the developers are too stubborn or too lazy (or both) to stick to “the standard” or to agree on the most widespread. No, instead they cook their own soup…

But anyway, I find that sad enough. But if the day comes when more packages are delivered only via Snap & co (or only), then I say: Bye Linux. Hello Windows or macos (hackintosh).

Because exactly this shit is one of the reasons why I switched to Linux in 2006. I don’t want to have 3728952309 versions of “libraryX.so” in my system, all with different bugs and security holes. Not to mention memory consumption. Sure at that time it was more critical, because disks had rather around 80GB (which were affordable) and not several TB for under 100€. Likewise, I do not want that I have to update everything individually as in Windows. Sure that is solved with Linux then surely somehow about the various stores and package managers, but then you have sometime his browser as snap, his email client as appimage, then something else again as flatpak, etc etc. Incredibly complicated, incredibly fat, incredibly slow.

And what is all this shit for? Simple: Supposedly because this would be easier for the user. But that’s just a pretense, because the real reason is rather: much, much, much easier for the developers and for those who have to/want to manage a distribution. So the developers don’t have to worry about “libraryX.so” in version 3.1.2 only being available on Arch, OpenSuse and Debian. But not on Ubuntu and others. And they also don’t have to worry about whether the user has dependency XYZ installed. Or other packages that might be in conflict. And for those who have to manage a distribution, have a lot of work in the beginning, but once this “change” is done, the effort is just a joke.

Well. As I said, if in the future there should be no more Distribrution that approaches it “classically”, then it was for me.

For this reason I boycott e.g. balena etcher. Or all other packages that are extracted from snap, flatpak or appimage, just to save compiling.

But well, just my 2 cents.

Translated with www.DeepL.com/Translator (free version)

3 Likes

There’s always BSD…

2 Likes

Ok coming back on to the topic which is about snapd or snap. Snap is best integrated into *buntu, not Arch or any other distro. If one needs to get the best snap experience best to go with one of the *buntus.

In my opinion, snap is not a good packaging system don’t know why Canonical wanted to drop the already decent apt and .deb for snap because it doesn’t even act decent to justify the name given to the system “snap” which is nothing in action.

Anyway, Arch already has its own software delivery system (2 to be exact). AUR actually covers almost all the things that official repos don’t. And as many said above I would take my chances with the AUR package than with something I can’t see the source of.

And why add another set of dependencies and basically bloat to an already lean mean system like Arch.

1 Like

I understand your point, but from where Linux is now, where most distributions have their own method of packaging and shipping software, Flatpaks make the world a lot easier for me, as a user. If what I want is on Flathub, I know I can have access to it no matter the distribution. For example, I use Void Linux on my laptop. There is no Librewolf in their repos, and this is an important piece of software to me which would be inaccessible if there wasn’t a Flatpak version.

Arch is popular enough to have build instructions on most Git repositories, and you have access to the AUR which is an incredible repository, so odds are you have access to all the software you would want, which renders Flathub and Snapstore far less important, but to me what makes Linux wonderful is the amount of choice you have, and Flathub makes distrohopping a lot easier.