rlpb

> Investors begin to refuse to build new potato farms because a return on their investment gets worse whenever anyone decides to build a new farm.

If they all refuse, then they're leaving money on the table. One investor could invest in 10% production only, and that would be very lucrative. It would be exactly my low cost to produce potato scenario.

In practice, they don't all refuse, or all invest. The market finds a balance. In time, producers switch to the new method, because anybody who doesn't leaves an opportunity for someone else to take their business and make more money.

This takes time, though. If we want things to go quicker, then we need to guarantee return on investment for longer, which is exactly what the government does by guaranteeing prices to renewable energy producers.

> Sure, but those same free markets will happily see those expensive producers go out of business.

No, because remember you are only able to meet 10% of market demand. The expensive producers will still get 90% of the business, and the market price for their product will remain basically the same. This is what we observe in the electricity markets today: the price to us is the cost of the most expensive product. The cheaper producers who cannot meet the full market demand still get to sell at the cost of the most expensive product.

> Doesn't this mean that solar/wind are insanely lucrative?

This is how markets are supposed to work. It provides an economic incentive for production to increase, which is what we want.

Consider what happens if you develop a farming method to produce potatoes for a fraction of the usual cost, but you can only meet 10% of total demand at your local market. What price are you going to sell your potatoes for when you show up to the market? You (like any free market seller) want to maximise your return, so you'll be able to sell for a fraction under the previous market rate, undercutting everyone else. Your farming method would be extremely lucrative.

> This might be obvious, but all of those things have a single common denominator: Microsoft, over you, getting to decide what your computer is doing.

Sure, but Microsoft have to strike a balance, too. If they push too hard in this direction, they'll lose their users to Macs on one side (probably the majority) and Linux on the other (a minority in number, but perhaps significant in expertise and clout). Once an exodus begins, it's much harder to stop. So where we are in that balance, and the state of user mindshare migration, is still interesting to discuss.

You cannot git push something that is not committed. The solution is to commit often (and do it over ssh if you forget on a remote system). It doesn't need to a presentable commit. That can be cleaned up later. I use `git commit -amwip` all the time.

Sure, you might neglect to add a file to your commit, or commit at all, but that's a problem whether you're pushing to a central public git forge or not.

TCP has an "urgent data" feature that might have been used for this kind of thing, used for Ctrl-C in telnet, etc. It can be used to bypass any pending send buffer and received by the server ahead of any unread data.

It absolutely could have happened when the ecosystem norm is `curl https://third.party/installer|sudo sh`. That was the normal method for third parties to ship software before snaps came along.

We have Flatpaks to solve this problem too now, but AFAICT while Flatpaks do support sandboxing the UX for that is such that most Flatpak non-power-users aren't enforcing sandboxing on Flatpaks they install, so in practice the feature isn't present where it's most needed.

Here's an article that seems relevant to the topic:

"District Court Finds That Using Copyrighted Works to Train Large Language Models Is Fair Use"

https://www.finnegan.com/en/insights/ip-updates/district-cou...

Whether they are derivative works in the context of copyright law (which the GPL relies upon) has not yet been decided by the courts AFAICT. So your assertion may be your personal opinion but we don't know if the law agrees or not yet. From some quick searches it seems that the answer isn't a slam dunk one way or another and is still working its way through the courts.

What if a person puts in the work, but the work was worthless or can be trivially reproduced without effort?

See also: https://en.wikipedia.org/wiki/Sweat_of_the_brow

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.

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.

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.

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.

Even then, they would still need to rebuild massive amounts on updates. That is nice in theory, but see the number of bugs reported in Debian because upstream projects fail to rebuild as expected. "I don't have the exact micro version of this dependency I'm expecting" is one common reason, but there are many others. It's a pretty regular thing, and therefore would be burdensome to distro maintainers."

A couple of minutes at the moment that is, with dynamic linking everywhere. What will it become when everything is statically linked?

Your apt update would still be huge though. When the dependency changes (eg. a security update) you’d be downloading rebuilds of 20 apps. For the update of a key library, you’d be downloading your entire distribution again. Every time.

I got a much reduced price in return for much lower range simply by buying an older EV. What’s wrong with leaving the new car market to those willing to pay the higher price, and the second hand market to those who want a lower price? This has always worked for me. It transfers especially well to EVs since older EVs were typically sold with less range.

> ...and it can stay irrational for long enough to destroy everything we know in tech.

Nah. For decades software engineers have been more expensive than the cost of buying the extra hardware needed for vastly inefficient software. There are orders of magnitude of inefficiency there. So there's a ton of slack in the world's software that can be taken up by software engineers while hardware is scarce, pushing back the date where there will really be a problem probably by decades more.

Of course software engineers will see a problem though, because they'll have to learn to to write efficient software again.

ie. "Great, but now make it work with less RAM" will be a thing again, instead of "It needs more RAM so order some as it's cheaper than your time to fix the code".

> It's a nodejs app, and there is no reason to have a problem with that.

Node apps typically have serious software supply chain problems. Their dependency trees are typically unauditable in practice.

If the emergency broadcast system fails, perhaps they need all the radio channels they use not to be jammed?

> I still drink as much as I normally do, which is about 12 litres a year; I am well under the intended beneficiary of this war on sugar, the sort of people who drink >100 litres a year…

It sounds like Irn-Bru was only viable _because_ of the sort of people who drink >100 litres a year. You were benefitting from that viability thanks to the very people you admit were being targeted by the tax. If they had stopped their high consumption for some other reason, availability of the original Irn-Bru would have suffered the same result due to the same drop in demand. The tax isn’t directly to blame here. The direct cause is the original motivation itself, regardless of how it was implemented. Considering only this specific example you cannot reject the tax without also rejecting the motivation.

Destroying demand for sugary drinks was exactly the intent, though.

> It isn't productive, the fact is well known.

I agree. My point is that the original comment was similarly unproductive.