smarx007

> 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.

Codeberg is not keen on closed-source repos.

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.

Spotify is already European...

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 thought they also OSSed a pretty solid https://github.com/frappe/helpdesk helpdesk but that was from Frappe, not Zerodha.

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.

Regarding clutter - I agree.

Both Claude and Gemini (the web variants, not CLI) tried to downgrade my .NET 10 projects to .NET 9 at least a few times.

> 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.

Hetzner has no managed services except for the S3-compatible object storage. Scaleway is much better in that regard.

Most European "cloud" providers sell "wood": https://berthub.eu/articles/posts/dear-hosting-providers-you...

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.

*with a dark theme.

[1]: https://github.blog/news-insights/a-new-look-for-repositorie...

Oh well, that flew over my head. You are right.

> 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.

I am assuming that the GP was referring to buying these exact speakers second-hand, given how they spoke of the environmental impact.

> I want my sandbox to be backed by a large, well funded security team

How much are you ready to pay for a license?

I think the SSH key that has push permissions is SSH-forwarded. It is quite a sophisticated setup (in both a good and a bad sense).

The output from Jules is a PR. And then it's a toss-up between "spot on, let's merge" and "nah, needs more work, I will check out the branch and fix it properly when I am the keyboard". And you see the current diff on the webpage while the agent is working.

How about specifying a version in the CI config? [0]

Also, you know that you can do a binary search for the version that works for you? 0.154.0, 0.77.0, 0.115.0 ... (had to do it once myself)

[0]: https://github.com/oslc-op/website/blob/9b63c72dbb28c2d3733c...

I am assuming the message durability guarantees lean towards YOLO rather than ACID? See also https://news.ycombinator.com/item?id=46196105

You did not check my link and ss02 out, did you?

IBM Plex is very good. Recently, I have been enjoying https://rsms.me/inter/ for interfaces a bit more (with ss02 for body and ss02+tnum for tables activated).

To test 'limit > 0' according to MC/DC, you need only two values, e.g. -1 and 1. There may be other code inside the branch using limit in some other ways, prompting more test cases and more values of limit but this one only needs two.

But yes, exhaustively testing your code is a bit exhausting ;)

Modified Condition/Decision Coverage (MC/DC) is a test coverage approach that considers a chunk of code covered if:

- Every branch was "visited". Plain coverage already ensures that. I would actually advocate for 100% branch coverage before 100% line coverage.

- Every part (condition) of a branch clause has taken all possible values. If you have if(enabled && limit > 0), MC/DC requires you to test with enabled, !enabled, limit >0, limit <=0.

- Every change to the condition was shown to somehow change the outcome. (false && limit > 0) would not pass this, a change to the limit would not affect the outcome - the decision is always false. But @zweifuss has a better example.

- And, of course, every possible decision (the outcome of the entire 'enabled && limit > 0') needs to be tested. This is what ensures that every branch is taken for if statements, but also for switch statements that they are exhaustive etc.

MC/DC is usually required for all safety-critical code as per NASA, ESA, automotive (ISO 26262) and industrial (IEC 61508).