Why? Even 1080p is more than what is usually needed for such a KVM solution. It is not like this is meant for doing remote work on a computer or anything like that.

It lets you remotely control a server as if you were sitting in front of a screen and keyboard directly attached to it.

I was really sceptical of the CTOs first response, but this does actually seem to be genuinely good news.

The head of BitWarden has come out and stated the SDK being required to compile BitWarden was a mistake, however, and if this proves to be true (which I have no reason to doubt) then I see no reason why any of this is an issue.

I don’t see why this should make any difference at all. Sure, I get why he is are saying they are going to fix it - he thinks that this gets them in compliance with the GPLv3. But from a practical point of view there is no difference at all. The software is useless without that SDK part. Even if it does indeed get them in the clear from a legal point of view (which I am not convinced that it actually does), it is still a crappy situation.

I think, it would look way less shady, if they said they are going fully source-available and not pretend that they are keeping the client open source. I would still dislike that, of course. At least that wouldn’t have eroded the trust in them as much as it did for me.

Proprietary is a strong word IMO. Here’s the repo, it’s not FOSS, but it is source available.

Yeah, that’s what I meant by “proprietary”. I guess having the source to look at is better than nothing, but it still leaves me uneasy. Their license lets them do anything they want (ignoring that - as it stands - their license is void due to the linkage with GPLv3 code, but they said they want to fix that). I have no idea what their plan is. I don’t think it is in their best interest to go the route they appear to be going. Having truly open source clients seems to be a selling point for quite a few customers. But what do I know…

Keyguard isn’t open source. Have a look at their license. It just says “All rights reserved”.

I really hope that this is actually the case, but I am not very optimistic. This doesn’t seem to be a mistake. They intentionally move functionality of their clients to their proprietary SDK library. The Bitwarden person stated this in the Github issue and you can also check the commit history. Making that library a build-time dependency might actually have been a mistake. That does not change the fact, that the clients are no longer useful without that proprietary library going forward. Core functionality has been move to that lib. I really don’t care if they talk to that library via some protocol or have it linked at build time. I wouldn’t consider this open source, even if that client wrapper that talks to that library technically is still licensed under GPLv3.

Maybe you want to read the comment by kspearrin in that Github issue again. They are clearly moving away from open source. He explicitly states that they are in the process of moving more code to their proprietary “SDK” library.

It is really not just a packaging bug. If you read that comment of the Bitwarden person a little further, you’ll notice that he’s talking about that proprietary “SDK” library that they are integrating with their clients. Even if they manage to not actually link it directly with the client, but rather let the client talk to that library via some protocol - it doesn’t make the situation any better. The client won’t work without their proprietary “SDK”, no matter if they remove the build-time dependency or not.

Perhaps the hard dependency was a mistake, but not them moving more and more code to their proprietary library. It appears that their intent is to make the client mostly a wrapper around their proprietary library, so they can still claim to have an open source GPLv3 piece of software. What good is that client if you can only use it in conjunction with that proprietary library, even if you can build it without that dependency?

Thanks, I haven’t seen that one before, but I’d really prefer an open source application.

BitWarden already has lots of clients.

Does it? I’d be very much interested to know. I’ve been looking for other clients before, because I didn’t like the sluggishness of the Electron client, but couldn’t find any usable clients at all. There are some projects on Github, none of which seemed to be in a usable state. Perhaps I have been missing something.

This is being blown a bit out of proportion though. All they are saying is the official SDK may have some non-free components going forward. So what? It’s a private company, they can do what they want. Or the community can just fork it and move forward with a free one if they want, but it’s just not going to be in the official BitWarden clients. Hardly news or a big deal.

Nobody said that they can’t do that (although people rightfully questioned that their changes are indeed comatible with the GPLv3). I very much disagree that this isn’t a big deal, though.

How do you store a driver’s license in Bitwarden? Last time I checked they didn’t support file storage. Do you just put it in the cloud storage?

They do support file storage. I’ve been using that for years for storing small files related to certain accounts an such.

I would advice against using SSDs for storage of media and such. Not only because of their higher price, but also because flash memory cells tend to fade over time, causing read speeds to decrease considerably over time. This is particularily the case for mostly read-only workloads. For each read operation the flash memory cell being read loses a bit of its charge. Eventually the margin for the controller to be able to read the data will be so small, that it takes the controller lots of read operations to figure out the correct data. In the worst case this can lead to the SSD controller being unable to read some data alltogether.

No, tmpfs is always located in virtual memory. Have a look at the kernel documentation for more information about tmpfs.

It is. It might end up on disk in swap, if you run low on memory (and have some sort of disk-based swap enabled), but usually it is located in RAM.

Try diasbling the second DHCP server altogether. You only need one, since you have a flat network.

Are you sure there is exactly one DHCP server running?

I’m exclusively running unprivileged LXC containers and haven’t had any issues regarding the firewall, neither with iptables nor nftables.

No, it is not like Docker. You can treat an LXC container pretty much like a VM in most instances, including firewall rules. To answer the question, you can use fail2ban just like you had done in your VM, meaning you can run it inside the LXC container, where fail2ban can change the firewall rules of that container as it sees fit.