[-] valar@lemmy.ca 5 points 19 hours ago* (last edited 19 hours ago)

I'm just summarizing the arguments made by the actual proposals by the Debian team linked in the OP

Choice 1 provides this position on AI

Debian has a well-earned reputation for stability. This stability is crucial to Debian's position in the free software ecosystem. It is our belief that widespread LLM usage comes from the "move fast, and break things" attitude that, while common in many parts of this industry, is contrary to what makes Debian Debian, and is inappropriate for Debian contributors.

In practical terms, LLM usage raises the following concerns:

  1. Copyright

LLM output has very unclear legal status: it may be possible to copyright on its own merits, or not; it may be affected by all of the licenses and copyrights in the training data, or not. Debian Policy and the DFSG require absolute clarity for licensing and copyright[1][2]. Software and other contributions written conventionally by humans with unclear copyright or license status are not allowed in Debian; LLM output should not have a special exception to this.

  1. Quality

LLM output has many well-known problems with accuracy.[3][4][5] A LLM can never "know" if its output is correct since it merely produces syntactically likely combinations of the training data. In some environments this is good enough. In Debian, it is not. For instance, in packaging, each Debian source package is unique. Since packaging syntax and best practices have changed over time, a LLM-produced package will have a mixture of contents spanning the age of the archive, with watch files that do not work, overrides out of context, imaginary copyright, and will generally be unfit for upload. A seasoned Debian contributor with packaging expertise may find some limited usefulness here, but a new contributor cannot, and would not know how to fix it. These same quality and accuracy concerns apply clearly to all of the areas listed in the scope of this proposal above. If Debian were a closed organization comprising only domain experts who never leave, this might not be an issue; however,

  1. Community

Debian is a project that is more than just code: it is a community built on shared interests in free software and solving technical problems. Debian intentionally grows this community through many means, and new contributors are always encouraged to join. Allowing LLM contributions breaks this. New contributors submitting LLM output for review places an unnecessary strain on the reviewer, which can lead to burnout. Furthermore, LLM-dependent new contributors do not actually learn and understand the details of Debian packaging or processes, so they cannot come to replace a former burned out DD.

  1. Ethics

LLM companies directly hurt the free software community as whole by scraping the whole web for training data without any regard for license, copyright, or even established conventions such as robots.txt.[6] This has had a major negative impact on Debian's public web resources, effectively a large scale and perpetual Denial of Service attack on sites that many users rely on. As a consequence parts of our infrastructure were not reachable at all, and JS-based checks had to be enabled. Many other projects were similarly affected. Furthermore, LLM training consumes a staggering amount of resources[7], and the user verification systems that we have been forced to implement as protection waste resources as well. This is blatant disregard for the internet as a public resource, wastes system administrator time, and although individual LLM sessions do not directly use massive resources or DoS the public web, the fact that they can be used at all is a direct result of these unethical behaviours by the LLM companies.

Debian has a Social Contract. [8] Our priorities are our users and free software. Debian is Stable. [9] Users and organizations choose Debian because it is reliable and secure.

Debian is not here to generate as much code as possible requiring manual review by a shrinking number of human volunteers, or to package every piece of software, or to rush new features, but these are what LLMs are used for.

In conclusion, allowing LLM contributions is contrary to the social contract and the common cause of creating a free operating system with a focus on quality and stability.

While Choice 2 only says

The Debian project recognizes that AI-assisted contributions raise many concerns, e.g. about the technical quality and maintainability of such contributions, and their legal status. AI itself also raises additional concerns, about its impact on society at large, on the IT industry and on Free Software; about its environmental impact; and the aggressive or non-compliant practices of AI scrapers.

Nevertheless, many Debian contributors find AI tools helpful when contributing to Debian, and ultimately for improving Debian.

[-] valar@lemmy.ca 44 points 23 hours ago* (last edited 23 hours ago)

In summary,

Argument 1: LLM code is trained on stolen copyright, filled with errors, will mix up best practices, burns out our contributors, hurts the free software community, and threatens Debian's most important quality: its stability.

Argument 2: Some people find AI tools helpful.

[-] valar@lemmy.ca 1 points 1 day ago

This is fair. I'm not super comfortable with it. I really do hope to migrate away.

[-] valar@lemmy.ca 28 points 1 day ago* (last edited 1 day ago)

I still use Plex, I have a lifetime pass and everything "just works" for my end users. Including Plexamp. Someday I expect to switch but it'll have to be when the end-user experience is just as easy and accessible.

Edit: Reading the article, even its author admits to sticking with Plex for now for similar reasons

[-] valar@lemmy.ca 2 points 1 day ago

Classic, haven't heard this in ages

[-] valar@lemmy.ca 9 points 2 days ago

This guy thinks reddit posts aren't made by LLMs

[-] valar@lemmy.ca 2 points 2 days ago

A Christmas Carol has been remade a thousand times, and will continue to be

[-] valar@lemmy.ca 13 points 2 days ago
  1. It is actually a local issue since Netanyahu will be visiting NYC soon
  2. Genocide isn't some "somewhere else" issue to be ignored
[-] valar@lemmy.ca 25 points 3 days ago

He looks happy

[-] valar@lemmy.ca 37 points 4 days ago

Its all a scam

[-] valar@lemmy.ca 471 points 4 days ago

bladeless fan
looks inside
blades

82
submitted 2 months ago* (last edited 2 months ago) by valar@lemmy.ca to c/selfhosted@lemmy.world

What to people use and recommend for this? I've read a bit about portainer, but I'm still learning - and don't know what the best solutions are.

Today I have a handful of selfhosted services running on my home machine - mostly installed directly, but a couple running as docker containers. As the scale of my selfhosting has grown, I've realized that things would be a lot easier to manage if each service was run as its own container, so that installed services are isolated.

The solution I'm looking for would make it easy (possibly a web UI) for me to monitor, modify, update, and remove containerized services, including networking and storage.

Edit: Also I would only want a FOSS solution.

view more: next ›

valar

0 post score
0 comment score
joined 3 months ago