I’m glad they’re making this. I’m sorry I’m no longer in the target audience, because I like the product and I really like the people behind it. After they started steering us so strongly towards the subscription service with no self hosted alternative, I finally (and sadly) migrated to BitWarden. 1Password was the better product when I migrated, and I suspect it still is.But the transition was a PITA and the only way I’m ever doing it again is if I’m moving into another self hosted service. This particular bit of infrastructure is too critical for me to leave myself unable to replicate it again.
I’m in the same boat. I was a happy 1Password family pack user and upgraded across a couple of majors, but the push to the subscription service and loss of functionality in the Android app when I added a work account first drove me away. I’m now on BitWarden with bitwarden_rs for the server and it’s more reliable than WiFi sync of 1Password ever was for me. I’d gotten too used to flaky sync with 1Password.
My employer uses 1Password; I have BitWarden in some browser profiles and 1Password in work browser profiles.
So I’ve installed this new app and on the whole, I like it.
I was cautiously optimistic that the system tray icon might be driven from the Rust side of things so that the RAM consumed by Electron could be released when the window is closed, but no such luck. There are 7 Electron processes shown in systemd-cgls output [with the main window closed, only the system tray icon showing] for the scope of the app. Sticking to a browser tab would be better, in terms of releasing resources when done.
Unlike most Chrome/Electron apps, 1Password does not try to add its repo PGP signing key as globally trusted for all repos, with cron jobs to retry daily. So I can follow third-party-repo best practices and it works. So major points to 1Password for that refreshing sanity. The only tampering of /etc/ was to add an entry for x-scheme-handler/onepassword to mailcap.
It’s all cloud accounts only, no local sync. So the app works nicely for my employer’s use-case and I’ll keep using it. But it’s not compatible with my needs for my own stuff, so I’ll stick to BitWarden for those.
I’ll be keeping my op install for forced local sync of data though; the CLI and the GUI are complementary in that regard.
I think having vendors provide and support their closed source products on Linux represents a major step forward for the platform.
I am super pleased that a fully open alternative in this space exists, but I use and love 1Password and am chuffed to hear about this, because right now I have to use sub optimal browser extensions or WINE hacks to approximate this.
Yes! I agree wholeheartedly. It’s a very good sign for the Linux desktop platform as a whole that companies are willing to write and support closed-source desktop applications. Unlike Windows or macOS, Linux desktop machines are much more diverse and backwards compatibility is much less guaranteed. It’s also worth mentioning that distributions and communities usually step up to support particularly important pieces of proprietary software (think Steam) on unsupported distributions and configurations.
Since 1Password is commercial software, making it available has to make financial sense. While they might be supporting Linux primarily as a marketing ploy to technical people instead of as a result of the number of Linux users, I think it’s more likely that they’re doing this because enough existing users would install it on Linux machines if given the option. That means that there has to be some significant overlap between 1Password users and Linux users.
Yup that’s absolutely true. They get the question often enough that there is (or was) a blurb in their support thing about using WINE as a hack-around, or at least their was before they came out with 1PasswordX for Chrome/Firefox.
1PasswordX is an OK solution, but I really REALLY missed the native app as I use it for things like secure note storage and credit card autofill as well.
Probably nothing, but that’s not the point. The point is that there are a decidedly non zero number of users who are already bought in to the 1Password ecosystem for any number of reasons, and providing first class support for them on Linux feels like a super clear cut win to me.
Two thing I like in 1Password compared to BitWarden are 1) the secret key which is totally random, used to encrypt/decrypt the database entries and only stored locally and 2) TouchID and FaceID support on macOS and iOS.
(Disclaimer: I switched from 1Password to BitWarden about 15 months ago, mostly because it had become clear that there was no way to stay up to date with current 1P features without also having Agile host my password store. I didn’t mind paying them, but I’d like to bring my own sync, please! It was also getting trickier to keep running 1Password under WINE, and most of my daily stuff had moved to a Linux desktop. So my basis for comparison might be out of date.)
BitWarden’s iOS Touch ID and Face ID support has gotten quite good lately. They also integrate with iOS password management much better than they used to. I have never tried touch ID on a mac so I don’t know if it works with that.
The things I still miss from 1Password are:
Much better password capture in the browser
Ability to sign into the background daemon once and have multiple applications (browsers, desktop clients) access it
Better integration with system locking
Richer password generation settings
The things I prefer about BitWarden are:
All source code is available
Easily self-hostable, either using their resource-intensive official package or the community supplied bitwarden_rs
Good command line client. (I think 1Password has one now… when I switched, their command line client was new and required you to host your database on Agile’s service, which was a deal breaker for me.)
The hard tie-in to the service component is really what stops me. I wish Agile would copy BitWarden in that regard and let people self-host but pay them the fee. I cheerfully do that because I want to support them, I just don’t want them to have my passwords.
I’m so happy to see them developing a great Linux app! It sounds like they’re using GTK for the UI, but it looks far more custom than I’m used to seeing. If anyone gives it a go, I’d love to hear about how the UI feels.
Ah fudge. I missed that line. Hopefully this doesn’t mean they’re going to bring the web-based version to macOS or Windows. It’s possible it’s not using Electron though, which I hope is the case!
I wonder if they plan on adding support for synchronising passwords without having a 1Password account? The getting started guide mentions “[to] use 1Password, you need a 1Password membership,” which is a little disappointing. 1Password for other platforms doesn’t have this requirement.
As someone who just spent a little time attempting a port of an Electron app to FreeBSD, only to quit in disgust, I have a few opinions.
Electron apps are huge. Really, really, really big with a gigantic web of dependencies. Think an 18,408 line Yarn lockfile.
Those dependencies are JavaScript libraries. To put it mildly, there is not a large intersection between the JavaScript community and users of non-mainstream OSs (e.g. FreeBSD). And those libraries tend not to be written in a portable fashion. This example (admittedly from a few years ago now) of a library disregarding $PATH is just one.
Platform support in Electron is a gigantic steaming pile of bogosity based upon the wrong set of abstractions. Instead of learning from the autotools people who were doing this decades ago, they detect platforms, not features. So when a new platform comes along (say, FreeBSD) you can’t just specify which features it has and let it compile. No, you have to create a gigantic patch that touches a bazillion files, everywhere those files check for which platform it’s compiling on.
Once compiled and running, they’re still huge (up to 1GiB of RAM for an IM client!). And - although perhaps this is a reflection of the apps themselves, not the framework - many are sluggish as hell. Neither is an attractive prospect for resource-limited Linux machines, like PinePhones.
I had thought, prior to attempting a port of an Electron app, that people were unfairly criticizing it. Now having peeked under the covers, I don’t think people are criticizing it enough.
As someone who isn’t an Electron hater: Electron apps are slow to load and memory hogs, which is something you might live with if you are talking about your IDE or Slack, but starts getting really old when it’s a utility application that should load quickly or spends most of the time in your icon tray. Worse yet: poorly written Electron apps can become CPU hogs as well, but I guess the same goes for all software.
I agree that lots of Electron apps have issues with poor performance and high memory usage. That said, a well written Electron app can perform well. For example, I’m a heavy user of the Joplin desktop application and in my experience it performs well and has fairly low memory usage (currently under about 200MB) and doesn’t seem to have the issues that plague the Slack client. Admittedly the Slack client is a lot more complex…
Oh, I agree that there great, performant Electron apps. VSCode is one of my favorite examples of that. Spotify is another one.
One of my biggest gripes with Electron is that - because of the nature of how it’s embedded in binaries - you usually end up with with several full copies of the whole framework in memory. If you are using KDE or Gnome, most of the processes in your desktop are sharing a significant amount of memory in the form of shared libraries. This tends to be fine in systems with 16Gb+ of memory and a fast CPU, but for people with more meager resources… it’s a drag.
Electron has been around since 2013 and still, typing in Slack still has a noticeable latency (that drives me crazy). I also still have to restart it once a day or so, to avoid that it becomes more and more laggy.
In the meanwhile, ripcord was developed by a single indie developer in Qt. Has most of Slack’s functionality, only uses a fraction of the memory, and is lightning fast. Oh, and it is multi-platform.
People (not you) claim that it is only possible to write cross-platform applications in Electron. This is nothing further from the truth, people have been writing cross-platforms apps in Qt literally for decades. (And it’s not hard either.)
I’m not sure that I would consider Slack a stellar example of an Electron app. Slack is slow even by Electron standards. VS Code’s latency is indistinguishable from typing in the Lobsters comment in Chromium on my middle-of-the-road desktop machine. Discord is a much better Electron-based chat app from a performance standpoint, in my experience.
People (not you) claim that it is only possible to write cross-platform applications in Electron. This is nothing further from the truth, people have been writing cross-platforms apps in Qt literally for decades. (And it’s not hard either.)
For commercial software, the more important part is not whether it’s possible (or “hard”), but whether it’s commercially viable. Without any hard data one way or another, I’d say that writing Electron apps is much less expensive than writing native Qt apps for most companies (especially since web technology experience is much easier to come by).
I don’t mind electron, but even VS code drops 1-2 frames on keypress on my threadripper desktop (and Chrome/Firefox do not). So far I’m putting up with it for the language server integration.
Disclaimer: haven’t tried language server mode in Emacs myself as these days I do all my dev in Common Lisp, and SLIME has had this approach covered for over a decade with SWANK. But it’s nice to see other languages catching up to Lisp in this area too ;)
I’m looking forward to the day that systems like Electron will compile everything to WebAssembly as a build step. In a way, I think Gary Bernhardt might have been more correct than I gave him credit for in his famous The Birth & Death of JavaScript presentation.
There are the utilitarian critiques (they are big and slow) and there’s also the sort of Mac critique (they are not in any way native) and there’s my weird “I HATE THE WEB” critique that is probably not widely shared. I have a couple of them that I use daily, but I really, really, really wish I didn’t.
I’m glad they’re making this. I’m sorry I’m no longer in the target audience, because I like the product and I really like the people behind it. After they started steering us so strongly towards the subscription service with no self hosted alternative, I finally (and sadly) migrated to BitWarden. 1Password was the better product when I migrated, and I suspect it still is.But the transition was a PITA and the only way I’m ever doing it again is if I’m moving into another self hosted service. This particular bit of infrastructure is too critical for me to leave myself unable to replicate it again.
I’m in the same boat. I was a happy 1Password family pack user and upgraded across a couple of majors, but the push to the subscription service and loss of functionality in the Android app when I added a work account first drove me away. I’m now on BitWarden with bitwarden_rs for the server and it’s more reliable than WiFi sync of 1Password ever was for me. I’d gotten too used to flaky sync with 1Password.
My employer uses 1Password; I have BitWarden in some browser profiles and 1Password in work browser profiles. So I’ve installed this new app and on the whole, I like it.
I was cautiously optimistic that the system tray icon might be driven from the Rust side of things so that the RAM consumed by Electron could be released when the window is closed, but no such luck. There are 7 Electron processes shown in
systemd-cglsoutput [with the main window closed, only the system tray icon showing] for the scope of the app. Sticking to a browser tab would be better, in terms of releasing resources when done.Unlike most Chrome/Electron apps, 1Password does not try to add its repo PGP signing key as globally trusted for all repos, with cron jobs to retry daily. So I can follow third-party-repo best practices and it works. So major points to 1Password for that refreshing sanity. The only tampering of
/etc/was to add an entry forx-scheme-handler/onepasswordtomailcap.It’s all cloud accounts only, no local sync. So the app works nicely for my employer’s use-case and I’ll keep using it. But it’s not compatible with my needs for my own stuff, so I’ll stick to BitWarden for those.
I’ll be keeping my
opinstall for forced local sync of data though; the CLI and the GUI are complementary in that regard.It looks like this is closed source? That seems a bit of a shame for a Linux product.
I’ve got to respectfully disagree.
I think having vendors provide and support their closed source products on Linux represents a major step forward for the platform.
I am super pleased that a fully open alternative in this space exists, but I use and love 1Password and am chuffed to hear about this, because right now I have to use sub optimal browser extensions or WINE hacks to approximate this.
Yes! I agree wholeheartedly. It’s a very good sign for the Linux desktop platform as a whole that companies are willing to write and support closed-source desktop applications. Unlike Windows or macOS, Linux desktop machines are much more diverse and backwards compatibility is much less guaranteed. It’s also worth mentioning that distributions and communities usually step up to support particularly important pieces of proprietary software (think Steam) on unsupported distributions and configurations.
Since 1Password is commercial software, making it available has to make financial sense. While they might be supporting Linux primarily as a marketing ploy to technical people instead of as a result of the number of Linux users, I think it’s more likely that they’re doing this because enough existing users would install it on Linux machines if given the option. That means that there has to be some significant overlap between 1Password users and Linux users.
Yup that’s absolutely true. They get the question often enough that there is (or was) a blurb in their support thing about using WINE as a hack-around, or at least their was before they came out with 1PasswordX for Chrome/Firefox.
1PasswordX is an OK solution, but I really REALLY missed the native app as I use it for things like secure note storage and credit card autofill as well.
Yeah, right? What does this even offer that Bitwarden doesn’t?
Probably nothing, but that’s not the point. The point is that there are a decidedly non zero number of users who are already bought in to the 1Password ecosystem for any number of reasons, and providing first class support for them on Linux feels like a super clear cut win to me.
As someone working to migrate off of apple platforms, I’m pretty happy this exists!
Two thing I like in 1Password compared to BitWarden are 1) the secret key which is totally random, used to encrypt/decrypt the database entries and only stored locally and 2) TouchID and FaceID support on macOS and iOS.
(Disclaimer: I switched from 1Password to BitWarden about 15 months ago, mostly because it had become clear that there was no way to stay up to date with current 1P features without also having Agile host my password store. I didn’t mind paying them, but I’d like to bring my own sync, please! It was also getting trickier to keep running 1Password under WINE, and most of my daily stuff had moved to a Linux desktop. So my basis for comparison might be out of date.)
BitWarden’s iOS Touch ID and Face ID support has gotten quite good lately. They also integrate with iOS password management much better than they used to. I have never tried touch ID on a mac so I don’t know if it works with that.
The things I still miss from 1Password are:
The things I prefer about BitWarden are:
The hard tie-in to the service component is really what stops me. I wish Agile would copy BitWarden in that regard and let people self-host but pay them the fee. I cheerfully do that because I want to support them, I just don’t want them to have my passwords.
I’m so happy to see them developing a great Linux app! It sounds like they’re using GTK for the UI, but it looks far more custom than I’m used to seeing. If anyone gives it a go, I’d love to hear about how the UI feels.
I says it uses “React for a responsive component-based UI.”, wouldn’t that means it is an Electron app?
Ah fudge. I missed that line. Hopefully this doesn’t mean they’re going to bring the web-based version to macOS or Windows. It’s possible it’s not using Electron though, which I hope is the case!
It’s definitely Electron:
This is disheartening. Hopefully it’s not an indication of future efforts for their native apps. Thanks for the confirmation!
Taking several years Of non Linux support to finally ship an electron app is saddening…
I mean, the economics point to making developing anything other than Electron apps from a business perspective a non-starter…
I thought you edited this like “yeah that’s 100% chrome”
I wonder if they plan on adding support for synchronising passwords without having a 1Password account? The getting started guide mentions “[to] use 1Password, you need a 1Password membership,” which is a little disappointing. 1Password for other platforms doesn’t have this requirement.
they’ve been pushing people towards cloud/subscription model for a few years now
Heck yes! Finally!!
Stop supporting and embracing Electron apps, please.
Serious question: what’s wrong with Electron apps?
As someone who just spent a little time attempting a port of an Electron app to FreeBSD, only to quit in disgust, I have a few opinions.
Electron apps are huge. Really, really, really big with a gigantic web of dependencies. Think an 18,408 line Yarn lockfile.
Those dependencies are JavaScript libraries. To put it mildly, there is not a large intersection between the JavaScript community and users of non-mainstream OSs (e.g. FreeBSD). And those libraries tend not to be written in a portable fashion. This example (admittedly from a few years ago now) of a library disregarding
$PATHis just one.Platform support in Electron is
a gigantic steaming pile of bogositybased upon the wrong set of abstractions. Instead of learning from the autotools people who were doing this decades ago, they detect platforms, not features. So when a new platform comes along (say, FreeBSD) you can’t just specify which features it has and let it compile. No, you have to create a gigantic patch that touches a bazillion files, everywhere those files check for which platform it’s compiling on.Once compiled and running, they’re still huge (up to 1GiB of RAM for an IM client!). And - although perhaps this is a reflection of the apps themselves, not the framework - many are sluggish as hell. Neither is an attractive prospect for resource-limited Linux machines, like PinePhones.
I had thought, prior to attempting a port of an Electron app, that people were unfairly criticizing it. Now having peeked under the covers, I don’t think people are criticizing it enough.
As someone who isn’t an Electron hater: Electron apps are slow to load and memory hogs, which is something you might live with if you are talking about your IDE or Slack, but starts getting really old when it’s a utility application that should load quickly or spends most of the time in your icon tray. Worse yet: poorly written Electron apps can become CPU hogs as well, but I guess the same goes for all software.
I agree that lots of Electron apps have issues with poor performance and high memory usage. That said, a well written Electron app can perform well. For example, I’m a heavy user of the Joplin desktop application and in my experience it performs well and has fairly low memory usage (currently under about 200MB) and doesn’t seem to have the issues that plague the Slack client. Admittedly the Slack client is a lot more complex…
Oh, I agree that there great, performant Electron apps. VSCode is one of my favorite examples of that. Spotify is another one.
One of my biggest gripes with Electron is that - because of the nature of how it’s embedded in binaries - you usually end up with with several full copies of the whole framework in memory. If you are using KDE or Gnome, most of the processes in your desktop are sharing a significant amount of memory in the form of shared libraries. This tends to be fine in systems with 16Gb+ of memory and a fast CPU, but for people with more meager resources… it’s a drag.
I’m sure performance issues will be addressed in time.
Electron has been around since 2013 and still, typing in Slack still has a noticeable latency (that drives me crazy). I also still have to restart it once a day or so, to avoid that it becomes more and more laggy.
In the meanwhile, ripcord was developed by a single indie developer in Qt. Has most of Slack’s functionality, only uses a fraction of the memory, and is lightning fast. Oh, and it is multi-platform.
People (not you) claim that it is only possible to write cross-platform applications in Electron. This is nothing further from the truth, people have been writing cross-platforms apps in Qt literally for decades. (And it’s not hard either.)
I’m not sure that I would consider Slack a stellar example of an Electron app. Slack is slow even by Electron standards. VS Code’s latency is indistinguishable from typing in the Lobsters comment in Chromium on my middle-of-the-road desktop machine. Discord is a much better Electron-based chat app from a performance standpoint, in my experience.
For commercial software, the more important part is not whether it’s possible (or “hard”), but whether it’s commercially viable. Without any hard data one way or another, I’d say that writing Electron apps is much less expensive than writing native Qt apps for most companies (especially since web technology experience is much easier to come by).
I don’t mind electron, but even VS code drops 1-2 frames on keypress on my threadripper desktop (and Chrome/Firefox do not). So far I’m putting up with it for the language server integration.
Come to the dark side, we have cookies!
https://github.com/emacs-lsp/lsp-mode
Disclaimer: haven’t tried language server mode in Emacs myself as these days I do all my dev in Common Lisp, and SLIME has had this approach covered for over a decade with SWANK. But it’s nice to see other languages catching up to Lisp in this area too ;)
I’m sure once the performance issues are addressed the complaints about performance issues will subside.
I’m looking forward to the day that systems like Electron will compile everything to WebAssembly as a build step. In a way, I think Gary Bernhardt might have been more correct than I gave him credit for in his famous The Birth & Death of JavaScript presentation.
There are the utilitarian critiques (they are big and slow) and there’s also the sort of Mac critique (they are not in any way native) and there’s my weird “I HATE THE WEB” critique that is probably not widely shared. I have a couple of them that I use daily, but I really, really, really wish I didn’t.