Perhaps, and that's not unreasonable in and of itself. But to do so in such a user-hostile manner? That's a bit over the top. A new minimal package, advertising it, and only then eventually making it the default would have been far, far more effective.
If an engineer of mine pulled this on our user-base I'd have them reverting it in a heartbeat regardless of the technical merit. They already failed just in how they executed this and have burned good will, the technical merits no longer matter. Once you've lost the faith and trust of the user, it's over.
The original request[0] was more or less simply a user asking for the networking to be removed, and follow-up to just have a -nonetwork variation. Instead, we have comments from the debian maintainer:
The OP report:
> Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.
The debian package description[1]:
> See keepassxc-full if you absolutely need those.
The PR[2]
> Feature creep like SSH agent support, browser integration, Freedesktop.org secret storage, KeeShare pose undue risks for most users.
Each one of these sends a message. And it was entirely avoidable with a bit of grace and kindness to the existing userbase.
Yeah, I agree with you. I'm joking that KeePassXC developers should make parsing .kdbx an optional feature (that's an attack surface by itself for sure!) and see whether Debian package maintainer enable it or not.
The software has been broken - the UI wasn’t designed with those toggles in mind so now users suddenly have non functioning features presented to the in the UI.
The argument the all users should be keeping up to speed on NEWS - especially in the stable channels this will end up in - to explain why their UX is suddenly broken is not exactly ‘user friendly’.
They don't need to, it is shown to them during apt-get upgrade
> especially in the stable channels
This is in testing/unstable. Stable users aren't and won't be affected until until the next major Debian version is released and the users decides to do the upgrade.
In a way I'm glad it's not mentioned. As a FreeBSD user, nothing is more disheartening than to find a cool and interesting project written in a great^1 language without any packaging or distribution method other than "here's my container bruh". Like, ughh.
^1 Caveat, making a package of a Python project can be a rabbit hole can be a real pita. Virtual envs are usually good enough for most stuff until I start to need a compiler in every jail. Nowadays I'm looking almost only at Go (best) or Rust because their distribution is trivial in comparison.
I'm with you on pretty much all of what you've said. The _trivial distribution story_ is part of the reason I handed off maintenance of tmuxinator and started working on rmuxinator (spiritual successor written in Rust).
Otherwise, I often find myself needing to deploy Python/Node/Ruby at $WORK and I'd really rather not try to get a bunch of dev/prod machines (possibly running different OSes!) trying to use whatever the flavor of the day for managing virtual environments, interpreter versions, packages, etc. is.
Understandable, I’m in the desert southwest, so not a concern here.
I did recently attend a workshop by Dr. Ronald Rael (Professor of Architecture @ Berkeley), and he mentioned that as concerns building with adobe bricks, with proper roofing, rain is a minimal to non-existent issue. I am not entirely convinced, however, and have also heard of solutions such as using “plasticure” on the outside of the walls.
Except I cannot `go run ~/that/project/over/there` as the use of go modules means I have to change directory to be inside the package first. I'm not sure why that is exactly, but it's always been a nit I've found frustrating.
I ran into this on FreeBSD when cryptography started using a rust core for its work. Suddenly my jails needed a full rust build environment just to install this one package. It was a frustrating day.
Every time I upgrade that jail/venv I cry a little inside.
I've tried creating diagrams of this nature (not realizing this is a thing) but I chose them for documenting the system to others that weren't already familiar with the project so it felt necessary to layer it all together. Those diagrams shown looked more like team meetings hashing out the details. Seemed kind of an unfair comparison.
That being said, the biggest issue I ran into is in the diagram tooling. At the time we had Gliphy. One could not make it interactable, such that double-clicking on a node would explode the container and let someone drill-down. At best they had layers which were awfully crude to work with. And at the end of the day didn't export in SVG so were useless for embedding. Overall, a waste of time. :(
> Someone on the Beancount thread explained his workflow using tags link transactions to IRS form entries. I would like to try the same on GnuCash, but haven't yet figured out whether tags even exist (haven't had the time to check since)
I don't use tags, but GnuCash does have some built-in reporting features for tax forms.
1. You have to have assigned an account to a tax field (Edit -> Tax Report Options). It's what controls the "tax-related" checkbox when you edit an account.
2. Then you can go to Reports -> Tax Schedule Report & TXF Export to generate a report for the last tax year.
Ok thanks for that, but that has two problems. First, it's still "account based". I can't label a single transaction. Second, it's not versatile enough, it's US specific.
GNUCash is great, it definitely had a learning period for me.
My biggest gripe is not with GNUCash but with the damn banks. The fact there isn't any API to download.u transactions is infuriating. My bank makes me go through so many clicks to download one file and I have many accounts to pull.
It's so frustrating to just simply get my data.
Also, the ofx format doesn't support splits. So there's simply no way to import transactions that are already auto-split (think interest charges).
I wonder how full it'll be. The python bindings aren't complete. For instance it's impossible to add scheduled transactions. Which I'd investigating doing for tax depreciation on assets. I did eventually find the scheme functions and looked at adding the necessary functions. But not gonna lie Lisp is rough when you've never worked with it before.
You could and should discuss on the mailing lists. Agree scheduled transactions are not visible from bindings, and it could be a feature request. If you wanted to so depreciation of assets you could easily do your own calculations via scheme or python.
Their website is pretty crap. But. You haven't seen anything until you use their mobile app.
It is definitely one of the worst thing I've seen. I mean Subaru's Starlink was way worse, but IDC it's a car and I don't need the crappy app to use it. Costco's I want to be able to use, but can't.
If an engineer of mine pulled this on our user-base I'd have them reverting it in a heartbeat regardless of the technical merit. They already failed just in how they executed this and have burned good will, the technical merits no longer matter. Once you've lost the faith and trust of the user, it's over.
The original request[0] was more or less simply a user asking for the networking to be removed, and follow-up to just have a -nonetwork variation. Instead, we have comments from the debian maintainer:
The OP report: > Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.
The debian package description[1]: > See keepassxc-full if you absolutely need those.
The PR[2] > Feature creep like SSH agent support, browser integration, Freedesktop.org secret storage, KeeShare pose undue risks for most users.
Each one of these sends a message. And it was entirely avoidable with a bit of grace and kindness to the existing userbase.
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
[1]: https://packages.debian.org/sid/keepassxc
[2]: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...