Hacker Newsnew | past | comments | ask | show | jobs | submit | rlpb's commentslogin

There is well established case law on the contract that forms when you buy something from a store (say with cash). There is a contract, on implied terms . I think what we’re talking about here is entering into a contract (or not) on explicit terms dictated by one party where the other party has not explicitly considered them and barely given the opportunity to do so if at all. I don’t think anybody is denying the ability of contracts coming into existence on implied terms.

Pinning dependencies by hash is completely undermined by automation that then updates the pins without meaningful review, as is common.

I think that this is the issue then, not pulling dependencies from the internet directly.

> meaningful review No that I think about it, maybe for the first time in history it's actually feasible to review all the code in the repos using LLMs. Before LLMs were a thing, for any big project that would be way too much work to realistically do it.

Also, someone can provide code review of publicly available dependencies as a service, to avoid wasting tokens of reviewing same code again and again by each dev locally on their machine.

U wonder if anyone is already working on such service...


clevis and tang do currently work seamlessly on Debian and Ubuntu using initramfs-tools. So while the initramfs-tools/dracut discussion is valid, it seems mostly orthogonal to this topic.

I was unaware that they no longer depended on Dracut and now support initramfs-tools, which also seem to be the earliest clevis version that got packaged in Debian. That makes the initramfs-tools/dracut distinction a historical aspect of the project.

Anybody can become an Ubuntu developer. This is one such Ubuntu developer discussing possible implementation of a law that affects them across multiple distributions in good faith while trying to respect privacy and maintaining users' ultimate control of their Free Software based operating systems.

Ubuntu has made no decision here. This is essentially one contributor seeking consensus on what sort of contribution in relation to this law might be acceptable to multiple projects. It is very far from "Ubuntu Planning <X>" and exactly how community driven projects are supposed to work.

Comments disparaging Ubuntu have fallen for Lunduke's clickbait in their ignorance.


> Anybody can become an Ubuntu developer

Oh yeah, by the way! How much time left until people are allowed to develop software without KYC? Before you laugh off, this was unimaginable just a year ago and here we are: Google won't bend anymore. ID yourself or never develop for Android.

> have fallen for Lunduke's clickbait in their ignorance.

This is indeed clickbait, but surely you realize that the merit is here.


Bargaining power can also come from the availability of competition. I don't collectively bargain to buy bread, but it's still competitively priced.

> P.S. Still hope GNOME maintainers let other volunteers maintain GTK 2.

They already said this is fine: https://lists.debian.org/debian-devel/2026/01/msg00146.html


The maintainer driving this in Debian explicitly said:

> That being said I would not object if someone wants to take over the maintenance of GTK2, though I believe keeping it for beyond duke is beating a dead horse.

Source: https://lists.debian.org/debian-devel/2026/01/msg00146.html


Shaka, when the walls fell

I use both (for different purposes) and prefer the native app (and KeePassDX on Android), but note that it is a local app and doesn't sync. You need to use something else (eg. Syncthing or Dropbox) for that.

I actually prefer this. It's how most user-facing file formats work. KDBX in particular is often used in conjunction with syncing software, and I don't want a half changed file to sync and then the connection to be lost. The usual paradigm of "write new file then move and replace over old file" works more safely for atomic changes.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: