moonpiedumplings

How to improve Python packaging, or why fourteen tools are at least twelve too many

Still relevant.

Yes. Firstly, it's about release cycles. Centos Stream is a rolling release distro (although it rolls very, very slowly). But what this means, is that there isn't a true guarantee of application/ABI/API compatibility between current versions of Centos Stream and future versions.

In constrast to this, Centos 8 and previous were complete clones of Red Hat Enterprise Linux, which was a stable release distro. During the 10 year lifecycle of each RHEL release, there was a guarantee certain application/ABI/API compatibility not changing, which is what stability in the Linux/software world is defined as.

Centos 8 was a free alternative, for institutions unwilling, or unable to pay for RHEL stable releases. But, with the death of Centos, an alternative was needed. Alma Linux, Rocky Linux, and Scientific Linux (designed for labs and universities), were rebuilds of RHEL. This meant that, they would take RHEL's open source code, and recompile it and distribute it in a way that guaranteed application/ABI/API compatibility with RHEL, for the same lifecycle of a RHEL release.

So Alma Linux and Rocky Linux fill that gap... but recently, RHEL said that they are adjusting policies to make it much harder for people to make rebuilds (likely targeting Oracle Linux, which is a RHEL rebuild), but this change may affect Alma and Rocky as well.

Rocky said they were going to keep bug-for-bug compatibility, like they used to, but Alma says they are going to do something different. Although they still intend to be ABI compatible, Alma has decided to make some changes to the base system, such as reimplimenting and continuing to support things that Red Hat saw unfit to continue existing in RHEL. One example of this is SPICE, which is a graphics protocol used for low latency display of virtual machines. It had many usecases, and I am very excited to see it back in a distro in the Red Hat ecosystem.

https://help.kagi.com/orion/faq/faq.html#oss

We're working on it! We've started with some of our components and intend to open more in the future.

The idea that "open-source = trustworthy" only goes so far. For example, the same tech company that offers a popular open-source browser also has the largest ad/tracking network in history, with that browser playing a significant role in it. Another company with a closed-source browser (using WebKit like Orion) is on the forefront of privacy awareness and technologies in its products.

So, does anyone here remember when all chromium browsers had a secret api that sent extra data to google? Brave, Opera, and Edge got hit by this one, but I think Vivaldi dodged it. They all removed this after they found out, but still...

When it comes to things like browsers, due to the sheer complexity and difficulty to truly audit chromium, I don't really consider chromium to be "open source" in the same sense as many other apps. Legally, you can see and edit the code. But in practice, it's impossible to audit all of it, and the development is controlled by a single corporation who puts secrets in it, or removes features that harm their interests (manifest v3). Personally, I consider Minecraft Java to be closer to open source than chromium is.

To say that:

The idea that "open-source = trustworthy" only goes so far

is really just a cop-out and excuse for not being transparent with their code and what they are doing.

Opensuse doesn't have rpm-ostree. Their immutable offerings are just snapper/btrfs snapshots before changes to the system.

Such a setup is nowhere near as powerful. rpm-ostree can rebase itself based off of a container/oci image. It can layer images on top of eachother. Rather than just tracking when changes happened, it can also track what change happened, in a git style setup.

Uh...

Enpass is a freemium password manager and

From wikipedia.

So you switched to a proprietary password manager?

Also:

The Enpass app retains no user data on its company servers,[6][7] instead storing and syncing encrypted password vaults on storage controlled by the end user. 

How is this different than keepass/xc, a fully foss solution?

https://owncast.online

One lgbtq+ streamer I know dual streams to owncast

The directory is a list of live owncast streams.

Also, you should be able to chat on owncast streams with fediverse accounts, but the last time I tried, I wasn't able to log log in with my lemmy account.

The whole point of it is that in a truly random system all known patterns should eventually emerge somewhere within it.

So pi (probably) has this property. There are some joke compression programs around this (they don't really work because it takes up more space to store where something in pi is, than storing the thing itself). But it is funny, to think that pi could theoretically hold every past, present, and future piece of information within those digits after the decimal.

https://github.com/philipl/pifs

https://ntietz.com/blog/why-we-cant-compress-messages-with-pi/

No need for AI for that, humans can do it better:

https://youtube.com/watch?v=l7ZUZerGwK4

https://youtube.com/watch?v=zn_rx8Zyl54

If you know where to look, someone already did it.

A new k8s cluster was created and planned to replace the current setup. Instead of ad-hoc scripts, conventions and associated documentation, it relies on a declarative description

Gitops!

It seems that they are using fluxcd, just like I am, to manage their kubernetes cluster.

I really like it as a solution, as you just edit configuration files, push then to git, and then your kubernetes cluster changes. Deploying an app is as simple as adding a file, and deleting an app involves deleting that file.

I honestly don't know how this could turn out.

It could be an amazing change that results in much more progress for hardware acceleration on guests of various types (since that is what vmware is good at) in kvm...

Or it could mean that they are dropping that feature from vmware altogether.

Regardless, I like this change because it means I would be able to run vmware machines and libvirt kvm machines at the same time, at least when I am forced to use vmware workstation.

I also dislike proprietary software in general, so I think less proprietary software and more FOSS is a good thing.

I found this: https://github.com/tenclass/mvisor-win-vgpu-driver

But it is for another foss kvm based hypervisor called mvisor.

I disagree, because they are not the same thing.

Immutable means read only root.

Atomic means that updates are done in a snapshotted manner somehow. It usually means that if an update fails, your system is not in a half working state, but instead will be reverted to the last working state, and that updates are all or nothing.

I create a btrfs snapshot before updates on my Arch Linux system. This is atomic, but not immutable.*

There is also "image based" which distros like ublue (immutable, atomic) are, but Nixos (also immutable and atomic) are not.

*only really before big updates tbh, but I know some people do configure snapshits before all updates.