> You are considering official distro repos as a means to control what is allowed to be run on Debian.
I am rather considering official repos as a means to keeping your Debian system in a "supported" state. Many users, including software developers, want to only install software (or sw versions) that would not put their system in an unsupported configuration.
> Debian DOES care about about both experience and ethics of what is allowed to be distributed in official repos
Podman is widely distributed in official Debian repos, so ethics is not a question in this particular case. We are only talking about Debian repos being conservative with the versions of the software in the repos - not limited to Podman. Debian does not encourage users to install software from 3rd-party repos just to get a newer version of an existing package because the stability of the system (and the ability to do major version upgrades) cannot be guaranteed otherwise.
A slightly different perspective: Podman is made by the distro people (RedHat/Fedora). And they consider it unacceptable to mess with the software distribution channels of a distro. If Debian does not want latest Podman, they are not going to push the latest version to Debian users behind Debian repo's "back". This is a distro-to-distro respect rather than amateur hour.
Also, I moved about 10 repos to a private Forgejo installation with pretty average (non-trivial) GH actions workflows. Zero repos has workflows running oob (java, .net, node). The moat is a bit there.
Quite believable if the test was run on a machine with little RAM and generous/unbounded swap. Not sure these are the numbers we want to see. Anything can take days if it swaps to death.
I think EU's position was that Apple can impose whatever rules and restrictions on 3rd parties as long as Siri is itself subject to ALL of those rules and restrictions. The restrictions were up to Apple to determine. What was not OK was to roll out Siri without restrictions yet impose them on other AI providers.
Sounds like a product management problem. If you declare that you support RHEL and Ubuntu LTS and LTS-1 yet still process bug reports from other installations, the product owner is not doing their job properly. Any bug reports from Nix or Fedora got to be closed due to a wrong operating environment. Even accepting bug reports from the latest non-LTS Ubuntu release should be avoided.
A noob question: is there a tool that automatically instructs Claude Code to "continue" when the token quota is reset after 5h? I am interested in that more than some rather fancy loops.
I think that npmjs uses colors too much to the point of irrelevance. Why are links in the README red? Why is the code tab red? Why is the download graph purple?
Compare your npmx link to vue to https://npmx.dev/package/node-red-contrib-rtc-alert-node . This package uses deprecated and vulnerable deps and npmx correctly uses color to draw attention to it. And because the npmx page is normally monotone, the use of color actually draws your attention.
> because they don't provide a specific SaaS is kinda weird
I think for most business stakeholders it's not about the number of services but rather the coverage of business-critical needs. When you have access to Azure Entra, you know that you can cover 90%+ of your auth needs with that service. If you have access to AWS S3, you know that your various storage needs would be possible to cover with that. If a managed Postgres is available, you know that most of the IT systems you run would be able to take advantage of that. You look at Azure their IAM/audit/observability offerings and it's the same.
When you look at Hetzner as a business stakeholder, all you see are bare servers and and one object storage service that you are not sure of how battle-tested it is. And then you start thinking: "okay, I will need to run k8s or some other workload orchestration approach, my IT systems need Postgres/MySQL/SQL Server etc, I need auth, I need audit, I will need to build, operate, maintain all of that in-house". I am not saying that this is a wrong path for everyone, but Hetzner essentially leaves you no choice. And many business stakeholders who have been operating their own own-prem infra or colocated or rented IaaS plus a large dev team for decades and have since switched to one of the hyperscalers and reduced their dev/IT headcount - may not want to go back to the old model.
> limiting yourself to a smaller portion of AWS/Azure/GCP services can facilitate migrations to other cloud platforms.
Yes, which is why you insist (where possible/reasonable) on Postgres-compatible DBMS offerings, IdP solutions based on OIDC, observability on OpenTelemetry.
> Sure, smaller cloud providers don't usually have all those services, but this doesn't mean they are not cloud providers
Yes, it could mean that they are not cloud providers.
> but they can probably satisfy the needs of other users who are more than happy with a smaller feature set
Please see the linked article. This is essentially "users who are happy to build some of the furniture themselves".
I posted a link to what most cloud-native developers understand to be "cloud" a few times already. If IaaS is the only offering on the table, it's not cloud.
I would say the November 2015 look would be the one to go back to.* [1] This one seems to be from 2015 before the iconic redesign that makes it instantly recognizable as Github.
> why do we invent these formal languages except to be more semantically precise than natural language
To be... more precise?
On a more serious note, cannot recommend enough "Exactly: How Precision Engineers Created the Modern World" by Winchester. While the book talks mostly about the precision in mechanical engineering, it made me appreciate _precision_ itself to a greater degree.
hi there
https://berezovskyi.me/