Not disputing the overall feeling about the changes at Bitwarden but "Always free" phrase is still actually there if you're creating a personal Free account.
As a customer, I am OK with most increases but not the object storage one. This one has some quality issues and is no longer competitive in price either. I'm thinking of moving S3 part to OVH.
Is there any advantage of running k3s if you want to keep etcd? I understand that most k3s performance gains come from etcd being replaced by sqlite but if you still want a HA control plane, sqlite won't cut it.
We've been using k3s' embedded etcd for as long as its existed, and it's great. Setting up the etcd cluster is dramatically simplified; let the first node generate a token and feed it to all the other nodes. Tons of other advantages to k3s; the single-binary deploy process, the built-in networking stack (which you can secure with Wireguard out-of-the-box), built-in ingress controller if you want one.
you can easily still use external etcd if you really need to.
But in general k3s can be HA without issue and scaled just as well as vanilla k8s.
The main advantage of it is that everything comes neatly packed into a single binary whereas the alternative would mean to have a multitude of services running for cluster provisioning.
Kubernetes in the end is basically an API server with multiple componets and k3s puts a nice bow around all of them.
There is nothing wrong with ONNX, but rather the limitations of PyTorch.
1. PyTorch model files are neither portable nor self-contained, because PyTorch model files are pickled Python classes containing weights so you need Python class code to run it.
Because it needs real Python code to run the models, PyTorch suffers from a numerous issues porting to other non-Python platforms such as ONNX.
PyTorch offers a way to export to ONNX but you will encounter various errors. [1]
Sure, you might be lucky enough to troubleshoot a specific model to export it to ONNX, but if your objective is to export arbitrary 964 models from a model zoo (TIMM) it is almost impossible.
2. There are organizational or cultural problems with it. Because of the above problem, PyTorch model needs to be designed with portability in mind from beginning. But porting & serving models are what engineers do, whereas researchers, who design models, don't care about it when writing papers. So it is often hard to use SOTA models that comes from an academic research.
> PyTorch offers a way to export to ONNX but you will encounter various errors. [1]
I mean sure, there are limitations, but this is greatly exaggerating their impact in my experience. I'd be curious to hear from anyone where these have been serious blockers, I've been exporting PyTorch models to ONNX (for CV applications) for the last couple of years without any major issues (and any issues that did pop up were resolved in a matter of hours).
How did this happen? a pickle is not a sensible storage format. it's insecure, hard to version, not very portable. isnt a model basically a big matrix of numbers?
Not in PyTorch. A model is Python dictionaries containing states and Python module/class objects. I don't know why the PyTorch team did this but that happened. Maybe it boils down to the point #2 I said.
This kind of thinking is exactly what's killing signal. Why would you want to gatekeep the security of others instead of making t as accessible as possible?
To me this feels like signal not understanding that their intended userbase and their actual userbase are very different, as I can't imagine the number of people that use signal solely for it's e2ee is comparable to the number of people that use it as their sms app.
Well, isn't the point that more people using signal strengthens the privacy/security of everyone? I would be sad if I wanted to send a message to gerty, and I find out he stopped using signal because of this.
It's not like I wouldn't still want to message him, right?
Convenience is extremely powerful in getting the layman to adopt this kind of tech, and I feel like it should be prioritized.
It's not built-in, of course, but if you can live with the quirky API, LMDB as an embedded key-value store will be hard to beat in terms of speed. It can also do "one-writer, many-readers" and transactions.
I wouldn't count on it unless you add some extra repo. RHEL releases are historically behind when it comes to software, which is claimed to provide more stability, but often older kernels in RHEL simply will not support the new underlying functionality. I am hopeful that if Podman ever has to make the decision to adapt at a modern pace with new software releases, or constantly try to backport fixes and code for old software, that they'll choose the modern approach.
RHEL 8.6 upgraded podman from v3.3 to v4.0.2, so v4.2 is not outside the realm of possibility in the next release. Since podman development is driven by Red Hat, I feel that podman upgrades get quite some leeway... Very impatient to test out the play kube functionality managed by systemd.
First, some software is updated frequently in RHEL, including podman. RHEL 8 was released in 2019 and it has podman 4.0.2 from earlier this year.
Second, even software that isn't updated often, or at all, in the base system might have newer releases available as modules. For example there are recent versions of Python in RHEL 8, with just the basic runtime so that you can use pip to install more packages.
Third, the RHEL kernel is updated much more than the corresponding LTS releases. The RHEL 8 kernel is closer to 5.15-ish than to the nominal 4.18 release from which it was forked. Pace for backports has slowed down a bit, but there's interest in keeping the kernel up to date because people are running RHEL 9 containers on the RHEL 8 kernel.
Given the module streams functionality in the package system in RHEL 8+, it's fairly plausible that it would be introduced using that path.
(Currently, there are 5 'container-tools' module streams listed, with podman versions including 1.0, 1.6, 3.0, 4.0 in stable streams, and 4.0.2 in the rolling stream.)
That is fair. I don't use Red Hat anymore really and their marketing and naming around modules was just confusing at the time. They took a common component of package management called repositories and made it confusing.
