HN user

Snetry

178 karma

[ my public key: https://keybase.io/jan200101; my proof: https://keybase.io/jan200101/sigs/aJDBdjQqT2W5wYyfad-MH1psQWvJyMW57F7RXqlAmI4 ]

Posts0
Comments94
View on HN
No posts found.

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.

KeePassXC has no sync implementation.

The functions related to Internet are:

- 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.

I don't think that is correct. Do you have an example? Linus is adament that "[they] do not break userspace".

I think you interpreted Linus wrong. When he says "we do not break userspace" he is talking about the Kernel APIs that are exposed to the Userland.

Userland APIs would be stuff like glibc, which has a terrible track record in regards to API breakage.

Do you only control the compiler or the entire toolchain and system?

If only the compiler you are still on very shaky grounds with -Werror.

Even for the Linux kernel devs -Werror is too harsh.

Oh how correct you are.

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 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.

Other stuff like the game Shovel Knight and even an open source frame limiting library broke because of this change, there are probably more things but this has not reached the masses yet.

I dont think the change was inherently bad but just ham fisting it into the release without widely announcing that the ABI will change is a massive failure on the glibc teams end.

And quite distasteful when many people have collaborated on your software. If you deserve some compensation, what about all of them? Will you share whatever you earn from it?

Most contributions are from drive by contributor's that may not even use the project.

Neither those nor the maintainer are entitled to compensation, but open source is a cruel environment where people want to use what you made but they wouldnt give you a dime unless they had to

Let's be honest, even fewer would have reacted to some Github Discussion or Issue trying to discuss the object.

As I see it the dev asked the void and got no negative feedback.

Afterwards the void grew legs and started running after him