but that is part of the problem: this isn't clearly communicated to the end user in the future or present.
Current users will have their install broken and need to google to figure out what is going on.
Future users will install `keepassxc` thinking it would be actually KeePassXC before potentially realizing its a minimal version.
Personally I think splitting it into `keepassxc-full` and `keepassc-minimal` would be better since it moves the choice to the user instead of implying the contents.
How more clearly do you expect it to be communicated?
apt shows the NEWS file during update when there's a change.
If it doesn't (ie. user set it up to blindly do the upgrade), you can still check the news file or .debian.changelog.gz file afterwards.
And note that this happened in testing/sid channel, where breakage is supposed to be happen. When this change shipped in the new major Debian stable release in a few years, it'll surely be clearly written in the release notes.
What else do you expect, SMS notification? :P
If a user haven't seen the above he for sure won't see an announcement in a crowded debian-whatever-announce mailing list he isn't subscribed to or an obscure blog post posted somewhere he doesn't follow.
- getting the favicon for a specific entry (needs to be ran manually with an option to download via a DuckDuckGo proxy)
- checking entries against HIBP (needs to be done manually in a submenu with a giant notice)
Also this is about KeePassXC not KeePass which is a completely different project.
There is also KeePassX, KeePassDX, KeeWeb, KeePass-electron and so on and so forth.
I find this to be really interesting advise but I wonder when this is right and when this would be wrong.
Especially in C, where a lot of data is passed through pointers, you'd want to make sure the data you are given isn't pointing to nothing and can't always rely on the callee doing it for you.
The statement "Linux does not have a stable userland ABI/API" is about the kernel. If you are talking about glibc you are already in the Linux OS/GNU Linux (whatever it is called) domain.
I think I correctly interpreted Linus when he talked about the kernel API/ABI facing the user (developer of application).
A lot of trouble you are going to get maintaining builds are due to poor tooling, not linux.
But we are getting into semantics here. At the end of the day, I think that if you are careful with what you are doing and think a little before choosing your tools and writing code, you should get very good mileage out of your linux binaries.
I don't know enough about windows to comment on its stability but I very much doubt I could just slide my original Quake CD or 3DS max 4 install into Windows 10. But I might be wrong!
Well, it's also a suid binary, thus it's very safety critical on unix-systems. su isn't as complex as sudo, so there's less reason to create a "simpler su", but still, a memory safe su seems like a good idea.
And given su and sudo provide similar functionality, doing them together likely creates synergies and code that can be shared.
And su has to be setuid root and is pretty much mandatory and if you can exploit a bug in it you've got local privilege escalation. I don't know selinux/apparmor well but I imagine su is granted the permission to create root shells, because of course it does, so any exploit will punch through all that as well.
Let us throw away all the existing code written in languages made in a different age and use languages that are completely binary incompatible just because we can.
well, clearly not "maximum warnings" since you are missing a lot of them.
-pedantic -Wunreachable-code -Wcast-qual -Wswitch-default -Wconversion -Wshadow -Wstrict-aliasing -Winit-self -Wcast-align -Wpointer-arith -Wmissing-declarations -Wmissing-include-dirs -Wno-unused-parameter -Wuninitialized and thats not even all that are useful.
Also, don't use -Werror if you can
Warnings will change based on compiler, compiler version and a countless number of other factors that make working with code that turns them into errors a pain.
I actually do what parent does for work projects but I also control the compiler and can decide when to upgrade. Like everything it's a trade-off and if I wanted wide support for different platforms I would consider your advice.
A good strategy is to use -Werror in development mode and CI builds, but not in 'distribution mode' (or alternatively: use -Werror for your own code, but not for imported libraries).
I mean, yeah, you don't need the whole GTK library for titlebars, but you still need to drag libdecor along to support a subgroup (Wayland users) of a subgroup (Gnome users).
Its pretty annoying to add another moving piece to the machinery just to do that.
That's the way it is with any optional X11 or Wayland extension. Either you implement the extension yourself, or you use a library to implement it for you. Typically the code to do this is put in a toolkit, but you decided to write your own toolkit so you get to deal with the annoyance. Nothing's changed in this regard. Actually, most optional things in Linux are like this and it's been this way since shared libraries were implemented. If you find the idea of this so off-putting, maybe you should be using a pre-made toolkit instead of writing your own?
