Well, that could have been fixed by booting from an usb stick, chrooting into you real system and either downloading and (re)installing the python package this way, or, if your package manager depends on python, download the package in the Live Linux and extracting the python package into your system, and then reinstalling it, so the package management overwrites your “manual installation”.

Could be tedious, but less so that having to reinstall everything IMO.

It is more about being lazy.

In most cases, where you havn’t destroyed your filesystem, you can just boot another Linux from a USB stick, mount your filesystems to /mnt, chroot into it, and then investigate and fix there.

See the Archlinux wiki, even if you do not use Archlinux, it is great: https://wiki.archlinux.org/title/Chroot

No no no! When you break something in Linux systems you fix it. Starting over and reinstalling everything is what you do when you mess up on Windows.

I would argue that it is about incentives. A market economy is about maximizing profit, so that (the class of) shareholders get more money out of it, than they put into it. Incentivising making money means you incentives a race to the bottom, producing lots of expensive and addicting crap that easily breaks for as little cost as possible. And you incentivise massive consumption of it.

A socialist economy should instead incentivise improving the world for all the people that live in it. Produce stuff that is robust, adaptable, sustainable and so on. Incentivise the mindfulness of the social and ecological impact of each product. And if someone needs something special, incentivise local makerspaces etc. that allows people to produce custom stuff in low quantities.

China is not communist, they are market-captialistic, one-party highly authoritarian state. “socialism” and “cmmunism” is just used to make them sound better and more legitimate than they are.

I found the main issue with many non-rolling release distributions are the upgrade instructions from one stable release to the next, and not the difficulty of installing them.

I’m myself a Archlinux guy, but that does sometimes require some carefulness and regularly (at least weekly) applying updates and does not have stable automatic updates, so I started installing Fedora atomic desktop distributions (Fedora Silverblue/Kinolite/etc.) for people that just want to use their device for basic stuff.

The reason for that is long term maintainability without an expert at hand.

I had so many bad experiences updating distributions from one stable version to the next, be it Debian and Ubuntu-based, or Fedora-based distributions.

And with those atomic desktop distributions the amount of moving parts is much lower, so hopefully upgrading them to newer releases is much more stable.

So I would suggest giving Fedora Silverblue (Gnome desktop), Kinolite (KDE) or Budgie Edition a try.

The SDK is not closed source, you can find the source here: https://github.com/bitwarden/sdk

It might not be GPL open-source, but it is not closed either.

Sure. To me “source available” is still closed-source, since looking into it might give companies an attack surface for you to have violated their copyright in the future. Happened with IBM in the past: https://books.google.de/books?id=gy4EAAAAMBAJ&lpg=PA15&pg=PA15&redir_esc=y#v=onepage&q&f=false

Let’s wait and see before we get out the pitchforks.

Sure. Bitwarden doesn’t owe us anything, but it is still sad to see this decision and better clarification and explanation could have alleviated the breaking of the trust here.

So you meant to say:

I would go as far as to say that Bitwarden’s main competitive advantage and differentiation is that it’s source is available.

That is not true, there are a lot of other password management software out there where the client source code is either open source or source available. For instance keyguard: https://github.com/AChep/keyguard-app?tab=License-1-ov-file#readme which is an alternative proprietary bitwarden client, where the source is also available. Also the Proton Pass client is under GPLv3.

I would argue that the main advantage of bitwarden compared to others is that it is open source and has an open source server for self-hosting (vaultwarden). Which of course makes it difficult in terms of business strategy with their VC funding. But maybe becoming a non-profit org and getting money from donors, the strategic funds of EU and other governments, etc. might be an alternative way.

Ok, lets take it step by step:

Thanks for sharing your concerns here. We have been progressing use of our SDK in more use cases for our clients. However, our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.

• the SDK and the client are two separate programs

I think they meant executable here, but that also doesn’t matter. If both programs can only be used together and not separate, and one is under GPLv3, then the other needs to be under GPLv3 too.

• code for each program is in separate repositories

How the code is structured doesn’t matter, it is about how it is consumed by the end-user, there both programs are delivered together and work together.

• the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3

The way those two programs communicate together, doesn’t matter, they only work together and not separate from each other. Both need to be under GPLv3

Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.

Not being able to build a GPLv3 licenses program without a proprietary one, is a build dependency. GPLv3 enforces you to be able to reproduce the code and I am pretty sure that the build tools and dependencies need to be under a GPLv3 compatible license as well.

But all of that still doesn’t explain what their goal of introducing the proprietary SDK is. What function will it have in the future? Will open source part be completely independent or not? What features will depend on the close-source part, and which do not? Have they thought about any ethical concerns, that many contributors contributed to their software because it under a GPL license? How are they planning on dealing with the loss of trust, in a project where trust is very important? etc.

None of that makes Bitwarden not open source.

Yes, it does, because it violates its own license GPLv3 by having proprietary build-/runtime dependencies.

If it was under a different, maybe more permissive, open source license, then maybe it would still be open source, but as of right now i likely breaks its own license terms.

Not only that, they specifically state this is a bug which will be addressed.

From what they state, they think that because executables that share internal information via standard protocols does somehow not break GPL3 terms compared to two libraries that share internal state via the standardized C ABI which does. And they seem to not consider that a bug, just the build-time dependency.

Well, then it would be nice to hear from them an explanation on why they decided to violate the GPLv3 on their client, by coupling it with proprietary code in a way that disallows building and/or usage without that proprietary component.

They would be insane to change that.

Yes. And i hope that they recover from it soon.

I would say a proper explanation includes the goal you want to achieve, not just the statement that you think that you are allowed to do something.

That “explanation” is unsatisfactory and likely wrong: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

So they either have to license their SDK under a GPLv3 compatible license, or switch the license of their client to a non-GPL one.

Their “explaination” only mentions why they think can do it, but not why they are doing it.

Well, I consume more open source software that I will ever produce, so I am in a dept to the community. If it means working a bit more to make my contribution useful to others and fit it into the bigger whole, I will gladly do so.

Valve contributed to Linux before, so the fact that they don’t have any direct upstreaming plans right now indicates that something is causing friction.

I would avoid reading too much into it. They and their developers are still contributing on other stuff. Also when working together, there will always be some friction, in any public collaborative project ever.

Nothing of this is a burden, it is just part of being a good contributor that reads and follows the rules. Contributing is pretty easy, when you have read and are following the guides. If you haven’t already, you should give it a try.

I am pretty sure that this isn’t the first contribution of Valve to the Linux kernel. It sounds more to me like “works for me, don’t care about others” attitude. Which is not a good attitude to have when working in any collaborative project. (Not necessarily against the developers, could also be management.)

Well, it is about code quality. And the same codebase should work on different hardware, which is not something that is required in downstream forks.

But it is sad to see that the driver was submitted in the past, is still actively developed and improved, but there doesn’t seem to be plans of submitting them again.

Also I don’t think that a platform driver is so complicated that it requires such a long time for mainlineing. It not a filesystem or VPN.

On a more interesting topic, the SteamDeck platform drivers are still not merged into mainline Linux… :'(

Last news about it: https://www.phoronix.com/news/Steam-Deck-Platform-Driver-2024

So similar to kakoune? I tried that for a while, but it was missing some features so I went back to vim/neovim.

I need to know vi anyway, because that is available everywhere (as part of busybox), so using vim/nvim for bigger systems just fits.

What about Lua/Luajit?

In most scripting languages you have the interpreter binary and the (standard) libraries as separate files. But creating self-extracting executables, that clean up after themselves can easily be done by wrapping them in a shell script.

IMO, if low dependencies and small size is really important, you could also just write your script in a low level compiled language (C, Rust, Zig, …), link it statically (e.g. with musl) and execute that.

I started using Fedora Silverblue on a tablet, seems to work fine so far, but requiring a reboot in order to install new system packages is a bit cumbersome and the process itself takes a while, but ordinary Fedora also doesn’t win any races when asked to install a new package

I think switching to FCOS or Flatcar on servers that just use containers makes sense. Since it lessens the burden of administrating the base system itself. Using butan/ignition might be unusual at first, but it also allows to put the base system configuration into a git repo, and makes initial provisioning using ansible or similar unnecessary. The rest of the system and services can be managed via portainer or similar software.

I also do not have long term experience with FCOS, but the advertised features of auto-update, rolling-release, focus on security and stability makes it a good fit for container servers, IMO.

An alternative to Debian on servers might also be Apline Linux. Which also has more a focus on network devices, but some people use it on a desktop as well.

If you have many different systems, and just want to learn to operate them all, maybe NixOS might be interesting. Using flakes, you can configure multiple machines from just one repo, and share configurations between them. But getting up to speed on NixOS might not be so easy, it has a steep learning curve.