• Project-wide LLM budget for helping people (was: Re: Complete and unifi

    From M. Zhou@21:1/5 to Fabio Fantoni on Sat Jan 11 17:30:02 2025
    On Sat, 2025-01-11 at 13:49 +0100, Fabio Fantoni wrote:

    Today trying to see how a new person who wants to start maintaining new packages would do and trying to do research thinking from his point of
    view and from simple searches on the internet I found unfortunately that these parts are fragmented and do not help at all to aim for something unified but not even simple and fast enough.

    And those fragments also changes as the time goes by. Such as the sbuild schroot -> unshare changes. They are not necessarily well documented in
    every introduction material for new comers.

    Even if somebody in Debian community has enough time to overhaul everything
    and create a new documentation, it will become the situation described
    in XKCD meme "standards": xkcd.com/927/ -- we just got yet another document
    as a fragment as time goes by.

    LLMs are good companions as long as the strong ones are used. In order to
    help new comers to learn, it is better for Debian to allocate some LLM API credits to them, instead of hoping for someone to work on the documentation
    and falling in the XKCD-927 infinite loop.

    Considering the price, the LLM API call for helping all DDs + newcomers,
    I believe, will be cheaper than hiring a real person to overhaul those documentations and keep them up to date. This is a feasible way to partly
    solve the issue without endlessly waiting for the HERO to appear.

    Debian should consider allocating some budget like several hundred USD
    per month for the LLM API calls for all members and new-comers' usage.

    DebGPT can be hooked somewhere within the debian development process,
    such as sbuild/ratt for build log analysis, etc. It is cheap enough
    and people will eventually figure out the useful apsect of them.

    Opinion against this post will include something about hallucination.
    In the case LLM write something that does not compile at all, or write
    some non-existent API, a human is intelligent enough to easily notice
    that build failure or lintian error and tell whether it is hallucination
    or not. I personally believe LLMs, at the current stage, is useful
    as long as used and interpreted properly.


    BTW, I was in the middle of evaluation LLMs for the nm-template. I did lots
    of procrastinations towards finishing the evaluation, but the first
    several questions were answered perfectly. https://salsa.debian.org/lumin/ai-noises/-/tree/main/nm-templates?ref_type=heads
    If anybody is interested in seeing the LLM evaluation against nm-templates, please let me know and your message will be significantly useful for me
    to conquer my procrastination on it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philipp Kern@21:1/5 to M. Zhou on Sat Jan 11 19:10:01 2025
    On 1/11/25 5:25 PM, M. Zhou wrote:
    Opinion against this post will include something about hallucination.
    In the case LLM write something that does not compile at all, or write
    some non-existent API, a human is intelligent enough to easily notice
    that build failure or lintian error and tell whether it is hallucination
    or not. I personally believe LLMs, at the current stage, is useful
    as long as used and interpreted properly.

    LLMs ingest documentation. If we stop writing or overhauling
    documentation, what is the LLM going to suggest? Even hallucination
    aside, how can it be the least bit accurate if it is not fed up-to-date information about how things work?

    BTW, I was in the middle of evaluation LLMs for the nm-template. I did lots of procrastinations towards finishing the evaluation, but the first
    several questions were answered perfectly. https://salsa.debian.org/lumin/ai-noises/-/tree/main/nm-templates?ref_type=heads
    If anybody is interested in seeing the LLM evaluation against nm-templates, please let me know and your message will be significantly useful for me
    to conquer my procrastination on it.

    If anyone is attempting to answer these using LLMs, I'd expect them to
    be excluded from the process. It's one thing to generate documentation
    by reviewing LLM output for accuracy and potentially publishing that to
    be helpful. It's another thing to try to lie yourself through the
    process in order to gain the project's trust.

    (In job interviews candidates already regularly use LLMs in the
    background to answer the questions. There I think it's still noticable
    when people claim knowledge that they do not have. In offline
    communication all bets are off.)

    Kind regards
    Philipp Kern

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to M. Zhou on Sat Jan 11 19:40:01 2025
    On Sat, Jan 11, 2025 at 11:25:20AM -0500, M. Zhou wrote:
    Opinion against this post will include something about hallucination.
    In the case LLM write something that does not compile at all, or write
    some non-existent API, a human is intelligent enough to easily notice
    that build failure or lintian error and tell whether it is hallucination
    or not.

    No, I don't think a human is intelligent enough for that. Based on my
    limited experience with people trying to learn how to use tools I'm the upstream for I fully expect that human to go to -mentors and ask why the
    tool or option proposed by the LLM doesn't exist (without mentioning where
    do they get that) or even why does the d/control they wrote results in a dpkg-source error about a not recognized field.
    It's possible that probability of doing this is lower for people learning packaging than for people learning a tool/langauge/framework in general,
    but remember that a noticeable share of people learning packaging is
    people who want to package their pet project.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmeCubYtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh WTMP/iYkndZ8NLBLnXktO6sUIav0lhFpAbn7kQQRoL7yv9XkIdh5zltht6K7GKiF mhrg6R/sHoLrRU1LrT1BbiNvpyG97zJW5aN5fLKUQD632Tf0xEsM5sAKYFbNh4Mk v7ZlXnM1dmpi4uRs0geO6Gd5lXj3S2ubZtIbeCvSZ0cKe5iijyqtwjP4tDH75rk8 z8DF4ByBDbmww+jvN8DoiO8ELUQ651/tI7CxGtrEkIq5oufEOJ6J485k+MT4BtNj 0d8Rnnw0TQ9cBx1uNrc6LwKCe5ywaXCd2CxheQ5fvgGy81EcePiWtNsUvhOkzAtp FWQGoAHRmQDTJZJYjvhYUdtLLdjY2ohcsQZGQAHgbDhVLutqraoeL9+Yc2wIXze1 AFah7rQV8BuVNRWuK3gWFVjtVZHYtAcs4ArliUhwo3kW6PlbPgvetbk5yxnfxjmL fMOY//MUVLH+TyXUBOEkerKgJQPxm9jQ2BqPvChLA1m/eER8YNBKAmltlcspO5RN 28A916l7GM6ZiP62PkjpN+8DJkgk/7IsyPTq7tTSUYy2gDD8BlZAY+fbxEMB52Bw u99Cl3rogNgs0H2sglKfjHQoKpTpkPw8/R9n3vzRwv5UMRGyTmiJJNgOyzNDomOq 65in7DLnB3CRhNtRbaz0Eg74cruXI3k3di/4lXf7Eefcz7eO
    =ytvH
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?@21:1/5 to All on Sat Jan 11 21:50:01 2025
    XPost: linux.debian.devel.mentors

    Hi!

    (cross-posting to mentors as they have most experience on what is
    wrong with our current docs)

    ...
    Even if somebody in Debian community has enough time to overhaul everything and create a new documentation, it will become the situation described
    in XKCD meme "standards": xkcd.com/927/ -- we just got yet another document as a fragment as time goes by.

    There is no need to start new duplicate parallel efforts. Simply
    contribute to the existing ones.

    Anyone can edit the current wiki pages if they want to improve them
    (although most people I spoke to don't like using MoinMoin, but that
    is another topic). If you would like to improve a man page, most
    packages in Debian accept Merge Requests on Salsa to improve the man
    pages. For example, git-buildpackage has now 29 accepted merge
    requests [1], dh-make 16 [2] and debmake 14 [3]. Contributions to
    these tool man pages are reviewed by the tool maintainers and thus
    likely end up in man pages that are actually correct. Sending MRs to
    the tool maintainers likely also helps them stay motivated to continue
    to maintain the tools, and the MR contents helps the maintainers get
    insight of the "user point of view".

    You can easily also contribute to the Debian Developers Reference,
    which has already accepted 26 merge requests [4]. The same goes for
    the Guide for Debian Maintainers, which has already accepted 26 MRs as
    well [5]. The Debian New Maintainers' Guide is abandoned and
    deprecated, it should have a more clear banner stating it. The Debian
    FAQ [6] has already accepted 13 MRs (8 of them in the past 6 months),
    so nothing should be blocking you from contributing improvements
    there. The debian.org website has accepted a whopping 716 MRs [7],
    contributing there should be easy and fruitful as there are active
    reviewers who will guide/help that the update is as good as possible.
    The mentors.debian.net has also very active team and 205 accepted MRs
    [8].

    I have at least MR in all of the above, so I speak out of experience.
    The process is smooth and most recipients give the first review
    feedback within a week, and after polishing the submissions are likely
    to accept.

    I warmly recommend others who have time to engage in long discussions
    on debian-devel@ to divert some of that energy into updating some of
    the documentation.



    [1] https://salsa.debian.org/agx/git-buildpackage/-/merge_requests?scope=all&state=merged
    [2] https://salsa.debian.org/debian/dh-make/-/merge_requests?scope=all&state=merged
    [3] https://salsa.debian.org/debian/debmake/-/merge_requests?scope=all&state=merged
    [4] https://salsa.debian.org/debian/developers-reference/-/merge_requests?scope=all&state=merged
    [5] https://salsa.debian.org/debian/debmake-doc/-/merge_requests?scope=all&state=merged
    [6] https://salsa.debian.org/ddp-team/debian-faq/-/merge_requests?scope=all&state=merged
    [7] https://salsa.debian.org/webmaster-team/webwml/-/merge_requests?scope=all&state=merged
    [8] https://salsa.debian.org/mentors.debian.net-team/debexpo/-/merge_requests?scope=all&state=merged

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?@21:1/5 to All on Sun Jan 12 04:20:01 2025
    ...
    Debian should consider allocating some budget like several hundred USD
    per month for the LLM API calls for all members and new-comers' usage.

    I don't think Debian should as an organization pay for LLMs. On the
    contrary I would expect LLM providers to offer API keys for free to
    Debian Developers just like we have other perks listed at https://wiki.debian.org/MemberBenefits.

    Considering how much the LLMs have utilized open source software when
    building and training them, it would actually make a lot of sense for
    those companies to step up and partner with Debian just like many web
    hosting companies have, as they all likewise have built their
    businesses on top of open source software. Currently, I don't see any
    AI companies at https://www.debian.org/partners/.

    If anyone has contacts at OpenAI, Anthropic, xAI, DeepSeek, 01 AI,
    Zhipu AI, Meta, Mistral, Nexus, Alibaba, AI21 Labs, Cohere etc, please
    tell them about the opportunity to sponsor Debian :)


    Also, in my view LLMs are still far from being able to do Debian
    development, they can't even write good git commit messages explaining
    *why* a particular change is made. They may in some cases, however, be
    useful assistants doing proof-reading and simple tasks. Debian
    contributors should be exploring sensible way to use LLMs in ways that
    fit their personal workflows, so that the human originated Merge
    Requests / patches get written faster and have a higher quality. But
    no thanks to LLM written stuff that wasn't closely co-authored and
    reviewed by a human. The risk of getting garbage is far too high.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ahmad Khalifa@21:1/5 to All on Sun Jan 12 17:00:02 2025
    XPost: linux.debian.devel.mentors

    On 11/01/2025 20:43, Otto Kekäläinen wrote:
    There is no need to start new duplicate parallel efforts. Simply
    contribute to the existing ones.

    +1, please. Too many docs already :)


    Anyone can edit the current wiki pages if they want to improve them
    (although most people I spoke to don't like using MoinMoin, but that
    is another topic). If you would like to improve a man page, most
    packages in Debian accept Merge Requests on Salsa to improve the man
    pages. For example, git-buildpackage has now 29 accepted merge
    requests [1], dh-make 16 [2] and debmake 14 [3]. Contributions to
    these tool man pages are reviewed by the tool maintainers and thus
    likely end up in man pages that are actually correct. Sending MRs to
    the tool maintainers likely also helps them stay motivated to continue
    to maintain the tools, and the MR contents helps the maintainers get
    insight of the "user point of view".

    Just a heads up on wiki signup:
    Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact wiki@debian.org and describe what you want to do in the wiki. Please contact us in English, otherwise we will have to pass your message to online
    translation services..

    Understandable of course, but the email slows things down a bit.
    MoinMoin doesn't have SSO support, but if anyone's interested in OAuth2
    and writes python, it's typically very straightforward: https://moinmo.in/EasyToDo/implement%20oauth

    It would be super nice if connected to Salsa or Gitlab.com account


    --
    Regards,
    Ahmad

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Colin Watson@21:1/5 to All on Sun Jan 12 18:00:01 2025
    On Sat, Jan 11, 2025 at 07:13:58PM -0800, Otto Kekäläinen wrote:
    I don't think Debian should as an organization pay for LLMs. On the
    contrary I would expect LLM providers to offer API keys for free to
    Debian Developers just like we have other perks listed at https://wiki.debian.org/MemberBenefits.

    I'd go further and say that the ecological and social costs of most of
    the contraptions provided by those providers means that using them in
    any way is unethical, and I personally refuse to do so. I recommend
    that other people do the same.

    (I have less fixed views on locally-trained models, but I see no very compelling need to find more things to spend energy on even if the costs
    are lower.)

    --
    Colin Watson (he/him) [cjwatson@debian.org]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrew M.A. Cater@21:1/5 to Colin Watson on Sun Jan 12 19:10:01 2025
    On Sun, Jan 12, 2025 at 04:56:15PM +0000, Colin Watson wrote:
    On Sat, Jan 11, 2025 at 07:13:58PM -0800, Otto Keklinen wrote:
    I don't think Debian should as an organization pay for LLMs. On the contrary I would expect LLM providers to offer API keys for free to
    Debian Developers just like we have other perks listed at https://wiki.debian.org/MemberBenefits.


    You can label me as extremely reactionary on this: I think LLM providers shouldn't be providing LLMs to Debian unless they are of proven benefit
    to the whole Project. I don't think they are and I don't trust the motives
    of those who suggest them as a cure-all. At the very best, LLMs are at
    the level of a Google Translate: at worst, they're wholly inaccurate and untrustworthy.

    I chose Google Translate as a deliberate example here: it's provided
    by one of the most influential agents on the Internet with the largest
    corpus of text to train on.I wouldn't trust it against the opinion
    of a good native speaker to translate to/from English, say, though I might
    rely on it to give some vague sense of an unknown text in a language I don't understand or read well..

    I'd go further and say that the ecological and social costs of most of
    the contraptions provided by those providers means that using them in
    any way is unethical, and I personally refuse to do so. I recommend
    that other people do the same.


    I think the ecological costs have a bearing here: currently, it seems
    improper to use systems that appear to imperil energy grids for entire - countries. Watching other people find and fix bugs, even in code they
    have written or know well, I can't trust systems built on modern
    Markov chains to do better, no matter how much input you give them, and
    that's without crediting LLMs as able to create good novel code..

    (I have less fixed views on locally-trained models, but I see no very compelling need to find more things to spend energy on even if the costs
    are lower.)


    Absolutely: even if the costs to the Debian project for LLMs were to be
    nil at present, there are better things for the project to spend time on.

    With every good wish, as ever,
    --
    Colin Watson (he/him) [cjwatson@debian.org]


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From M. Zhou@21:1/5 to Colin Watson on Sun Jan 12 19:50:01 2025
    On Sun, 2025-01-12 at 16:56 +0000, Colin Watson wrote:

    (I have less fixed views on locally-trained models, but I see no very compelling need to find more things to spend energy on even if the costs
    are lower.)

    Locally-trained models are not practical in the current stage. State-of-the-art models can only be trained by the richest capitals who have GPU clusters. Training
    and deploying smaller models like 1 billion can lead to a very wrong impression and conclusion on those models.

    Based on the comments, what I saw is that using LLMs as an organization is too radical for Debian. In that sense leaving this new technology to individuals' personal
    evaluation and usage is more reasonable.

    So what I was talking is simply a choice among the two:
    1. A contributor who needs help can leverage LLM for its immediate response and
    help even if it only correct, for 30% of the time. It requires the contributor
    to have knowledge and skill to properly use this new technology.
    2. A contributor who needs help has to wait for a real human for indefinite time
    period, but the correctness is above 99$.

    The existing voice chose the second one. I want to mention that "waiting for a real
    human for help on XXX for indefinite time" was a bad experience when I was a new comer.
    The community not agreeing on using that new technology to aid such pain point, 
    seems understandable to me.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Serafeim (Serafi) Zanikolas@21:1/5 to Ahmad Khalifa on Sun Jan 12 22:00:02 2025
    --321753c7bfbe0e4aad5e36429ec31f355fba3908ec273f94c8e35f605f9b Content-Transfer-Encoding: quoted-printable
    Content-Type: text/plain; charset=UTF-8

    On Sun Jan 12, 2025 at 4:52 PM CET, Ahmad Khalifa wrote:
    On 11/01/2025 20:43, Otto Kekäläinen wrote:
    [..]
    Just a heads up on wiki signup:
    Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact wiki@debian.org and describe what you want to do in the wiki. Please contact us in English, otherwise we will have to pass your message to online
    translation services..

    Understandable of course, but the email slows things down a bit.
    MoinMoin doesn't have SSO support, but if anyone's interested in OAuth2
    and writes python, it's typically very straightforward: https://moinmo.in/EasyToDo/implement%20oauth

    It would be super nice if connected to Salsa or Gitlab.com account

    what would be truly amazing, imho, would be the whole wiki on git. that'd allow for mass-updates, and reusing one's code (salsa) workflows for documentation

    thanks,
    serafi

    --321753c7bfbe0e4aad5e36429ec31f355fba3908ec273f94c8e35f605f9b
    Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEA2RWqo7IwLCLSFYbT59tVQ7WEioFAmeELCMACgkQT59tVQ7W EipNXhAAypoxffmmTQA0OhYANWDCxB1T/5SEaSfDdlAT9bSknQNzD4/M1/VhYu3l 46ty5st8yxdGeqDWh9mGzFZTbr7PDnauIEK6Xpt6Ax7Zo3e30Vn1jZUsiZ4df2+4 CTz25ZwxPS3Ej85NjHOH7pl1bnRS2vw+WGF28aTWH8emqxH9/y4e+C5Z8pCtG+v+ CJPfdqhSbjZ0FExeeUoMbtlbqsVcwRlvPwxI+TJ6ulMzeOy9OIhZyUljMri5Zwnc L0ga3tWF3oE93EmzKLuD+NI2TOyszyVOSICA5LZH6AFZEv0Y9gKNcxdCA8RrJI2P z4f3XjYeD/j0brPZFVOEFoK60GeWqi8mzWaSzA0xWWdehyYDf+ydqy5M5Hc1DBV1 R333Ya/rVsybAKN7YBnumsOasmjM6bpfB11iiZlDjkN9XyCzCajJyOsfrVINOIyH HwBQF+To1sIj0o28Bu+GwiGNnWKznXGWCZ3yzpXzP10YmQDdg5kPHMrRcxEwAQCY ggIctrYHsBSeBrhVgyCAzjYurjaPlXBSuQozktMmWU9gBmBXoX628PzKP1+UCtqe D2IUfrzvh9/23TPCgHZ+8bte/U7Zz62y7dLFp3lfVpiNtmJPc2PtJCCPD89Zk3kw bw9FeFu+ZC1OUBkY5VmVQgNq+EZblBctQu3wlC935GZBR2bXfgA=/0m0
    -----END PGP SIGNATURE-----

    --321753c7bfbe0e4aad5e36429ec31f355fba3908ec273f94c8e35f605f9b--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From M. Zhou@21:1/5 to Philipp Kern on Sun Jan 12 23:10:02 2025
    On Sun, 2025-01-12 at 22:36 +0100, Philipp Kern wrote:

    No-one is stopped from using any of the free offers. I don't think we
    need our own chat bot. Of course that means, in turn, that we give up on feeding it domain-specific knowledge and our own prompt. But that's... probably fine?

    One long term goal of debian deep learning team is to host an LLM with
    the team's AMD GPUs and expose it to the members. That said, the necessary packages to run that kind of service are still missing from our archive.
    It is a good way to use existing GPUs any way.

    Even if we get no commercial sponsorship of API calls, we will eventually experiment and evaluate one with the team's infrastructure. We are still working towards that.

    If those LLMs support that, one could still produce a guide on how to
    feed more interesting data into it - or provide a LoRA. It's not like inference requires a GPU.

    First, DebGPT is designed to conveniently put any particular information whether or not Debian-specific, to the context of LLM. I have also implemented some mapreduce algorithm to let the LLM deal with extremely overlength
    context such as a whole ratt buildlog directory.

    LoRA is only sound when you have a clear definition on the task you want
    the LLM to deal with. If we do not know what the user want, then forget
    about LoRA and just carefully provide the context to LLM. DebGPT is
    technically on the right way in terms of feasibility and efficiency.

    RAG may help. I have already implemented the vector database and the
    retrieval modules in DebGPT, but the frontend part for RAG is still
    under development.

    But then again saying things like "oh, look, I could easily answer the
    NM templates with this" is the context you want to put this work in.

    My intention is always to explore possible and potential ways to make LLM useful in any possible extent. To support my idea, I wrote DebGPT, and
    I tend to only claim things that is *already implemented* and *reproducible*
    in DebGPT.

    For instance, I've added the automatic answering of the nm-tempaltes in
    DebGPT and the following script can quickly give all the answer.
    The answers are pretty good at a first glance. I'll postpone the full evaluation when I wrote the code for all nm-templates.

    I simply dislike saying nonsense that cannot be implemented in DebGPT.
    But please do not limit your imagination with my readily available
    demo examples or the use cases I claimed.


    (you need to use the latest git version of DebGPT)
    ```
    # nm_assigned.txt
    debgpt -f nm:nm_assigned -a 'pretend to be lumin@debian.org and answer the question. Give concrete examples, and links as evidence supporting them are preferred.' -o nm-assigned-selfintro.txt

    # nm_pp1.txt
    for Q in PH0 PH1 PH2 PH3 PH4 PH5 PH6 PH7 PHa; do
    debgpt -HQf nm:pp1.${Q} -a 'Be concise and answer in just several sentences.' -o nm-pp1-${Q}-brief.txt;
    debgpt -HQf nm:pp1.${Q} -a 'Be precise and answer with details explained.' -o nm-pp1-${Q}-detail.txt;
    done

    # nm_pp1_extras.txt
    for Q in PH0 PH8 PH9 PHb; do
    debgpt -HQf nm:pp1e.${Q} -a 'Be concise and answer in just several sentences.' -o nm-pp1e-${Q}-brief.txt;
    debgpt -HQf nm:pp1e.${Q} -a 'Be precise and answer with details explained.' -o nm-pp1e-${Q}-detail.txt;
    done
    ```

    [1] DebGPT: https://salsa.debian.org/deeplearning-team/debgpt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philipp Kern@21:1/5 to M. Zhou on Sun Jan 12 22:40:02 2025
    On 1/12/25 7:46 PM, M. Zhou wrote:
    So what I was talking is simply a choice among the two:
    1. A contributor who needs help can leverage LLM for its immediate response and
    help even if it only correct, for 30% of the time. It requires the contributor
    to have knowledge and skill to properly use this new technology.
    2. A contributor who needs help has to wait for a real human for indefinite time
    period, but the correctness is above 99$.

    The existing voice chose the second one. I want to mention that "waiting for a real
    human for help on XXX for indefinite time" was a bad experience when I was a new comer.
    The community not agreeing on using that new technology to aid such pain point, 
    seems understandable to me.

    No-one is stopped from using any of the free offers. I don't think we
    need our own chat bot. Of course that means, in turn, that we give up on feeding it domain-specific knowledge and our own prompt. But that's...
    probably fine?

    If those LLMs support that, one could still produce a guide on how to
    feed more interesting data into it - or provide a LoRA. It's not like
    inference requires a GPU.

    But then again saying things like "oh, look, I could easily answer the
    NM templates with this" is the context you want to put this work in.

    Kind regards
    Philipp Kern

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonas Smedegaard@21:1/5 to All on Mon Jan 13 00:50:01 2025
    Hi Serafeim, and others,

    Quoting Serafeim (Serafi) Zanikolas (2025-01-12 21:54:58)
    On Sun Jan 12, 2025 at 4:52 PM CET, Ahmad Khalifa wrote:
    On 11/01/2025 20:43, Otto Kekäläinen wrote:
    [..]
    Just a heads up on wiki signup:
    Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact wiki@debian.org and describe what you want to do in the wiki. Please contact us in English, otherwise we will have to pass your message to
    online translation services..

    Understandable of course, but the email slows things down a bit.
    MoinMoin doesn't have SSO support, but if anyone's interested in OAuth2 and writes python, it's typically very straightforward: https://moinmo.in/EasyToDo/implement%20oauth

    It would be super nice if connected to Salsa or Gitlab.com account

    what would be truly amazing, imho, would be the whole wiki on git. that'd allow
    for mass-updates, and reusing one's code (salsa) workflows for documentation

    For those not only wishing that others made that happen, but consider scratching that particular itch themselves, I am happy to chat with you
    more detailed about what that involves, and how it is a quite exciting challenge - so exciting, in fact, that Debian has had several attempts
    at doing a migration over the years, but none so far have succeeded.

    I don't say this to scare you off, but to make you aware that it is not
    because Debianites love the archane MoinMoin wiki, but because it is challenging to migrate away from it.

    I originally packaged the MoinMoin wiki engine many years ago, before
    Ubuntu existed. Then git was invented, and Ikiwiki. Some has tried to
    migrate to Ikiwiki, some has tried to migrate to Mediawiki. Personally,
    I would today migrate to zola, but you (i.e. those wanting to roll up
    your sleeves and actually do this migration task) no doubt have your own opinion on which should be the goal and why that is ideal. Regardless of
    the goal, some of the preparations to get there is likely similar to
    those previous attempts, where I and others might have input from those previous attempts. If you think you have a novel new approach then I
    would love to learn about it, as I still run a few legacy wikis that I
    would like to migrate.

    But let's not hijack any further this thread about welcoming newcomers,
    I just wanted to chime in to encourage anyone wanting to do the wiki modernization to get in touch with me to discuss further.

    Kind regards,

    - Jonas

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private --==============A37205751928917522=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    wsG7BAABCgBvBYJnhFQPCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmdwpPqUfj/mBxj/CsPb89NB/jRWQBq7LXNMVvGYIB+D 4xYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAACdrhAAh8TtQkfWRgwbRqLjHSgvodat ng2ORyGhY1CcnV/NoDJm11udxoxY5atV2YDKeHunIBJgMryt52SO+iekO3BviweZ Kbr/qRH0K/1MUSnJYC1q5R9rP9lK7rH54FuoOBVBpeDplpI+i3Lzx790rndjJKk1 pFoU/o0M1N7LVExerbbHtOWOoyPdNxyScZQsSeXt8C9sx2yVHw9/RzyjCXLw5pYc QuzUQ2DXYgwQkufvgpNh9ph7NhklPv1dxrWGDKVm4VuT8r7UGzQ7wd84uOAsV6TN oXbo7VT933LXMH3kNpcEXNEBHZUeYExi3rRJcF3+PNTst08CpPvQu5LIULUseXq6 d/aqQK6Q9YiZ1br2jGdeHrBNPctHDFq/zKKI32b3
  • From =?ISO-8859-1?Q?=C1ngel?=@21:1/5 to Andrew M.A. Cater on Mon Jan 13 02:40:01 2025
    On 2025-01-12 at 18:03 +0000, Andrew M.A. Cater wrote:
    Watching other people find and fix bugs, even in code they
    have written or know well, I can't trust systems built on modern
    Markov chains to do better, no matter how much input you give them, and that's without crediting LLMs as able to create good novel code..

    This is something I have thought before, and which I find lacking in
    most (all?) instances of the "let's program with an LLM" topic.

    When a human¹ programs something, I expect there is a logical process
    through which he arrives to the decision to write a set of lines of
    code. This doesn't mean those lines will be the right ones, or bug-
    free. Just that it makes sense.

    For example, a program that does chdir("/"); at the beginning may
    suggest it my run as a daemon, as this allows it not to block
    filesystems from umounting.
    If it has a number of calls to getuid(), setuid(), setresuid()... it
    might switch to a different user.

    However, if the code was generated by a LLM, all bets are off, since
    the lines could make no sense at all for this specific program.


    It wouldn't be that strange if a LLM asked to generate a control file
    for a perl module could suggest a line such as
    Depends: libc6 (>= 2.34)
    just because there are lots of packages with that dependency.²

    A person could make a similar mistake of including unnecessary
    dependencies if copying its work on an unrelated package, if not
    properly cleaned. But how to fix those things if the mentor is a LLM?



    ¹ somewhat competent as a programmer
    ² hopefully, a LLM wouldn't be trained on the *output* of the
    templates, though.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Richter@21:1/5 to M. Zhou on Mon Jan 13 07:20:01 2025
    Hi,

    On 1/13/25 03:46, M. Zhou wrote:

    So what I was talking is simply a choice among the two:
    1. A contributor who needs help can leverage LLM for its immediate response and
    help even if it only correct, for 30% of the time. It requires the contributor
    to have knowledge and skill to properly use this new technology.

    The "skill required" aspect is an important one. I'm willing to review
    packages and provide feedback so learning can occur.

    LLMs interrupt the learning process here, because they provide a
    solution that makes me assume that the contributor already has a
    specific mental model, so my feedback is designed to fine tune this.

    When the contributor is using LLM generated code, my feedback is no
    longer helpful for learning -- at best, it can be used to iteratively
    arrive at a correct solution, but playing a game of telephone is a very inefficient way to do it, and does not prepare the new contributor to
    work unsupervised -- so LLMs basically disrupt our intake pipeline in
    the same way they are doing in commercial software development.

    Simon

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Holger Levsen@21:1/5 to M. Zhou on Mon Jan 13 09:40:01 2025
    On Sat, Jan 11, 2025 at 11:25:20AM -0500, M. Zhou wrote:
    On Sat, 2025-01-11 at 13:49 +0100, Fabio Fantoni wrote:

    Today trying to see how a new person who wants to start maintaining new packages would do and trying to do research thinking from his point of view and from simple searches on the internet I found unfortunately that these parts are fragmented and do not help at all to aim for something unified but not even simple and fast enough.

    And those fragments also changes as the time goes by. Such as the sbuild schroot -> unshare changes. They are not necessarily well documented in
    every introduction material for new comers.

    Even if somebody in Debian community has enough time to overhaul everything and create a new documentation, it will become the situation described
    in XKCD meme "standards": xkcd.com/927/ -- we just got yet another document as a fragment as time goes by.

    LLMs are good companions as long as the strong ones are used. In order to help new comers to learn, it is better for Debian to allocate some LLM API credits to them, instead of hoping for someone to work on the documentation and falling in the XKCD-927 infinite loop.

    Considering the price, the LLM API call for helping all DDs + newcomers,
    I believe, will be cheaper than hiring a real person to overhaul those documentations and keep them up to date. This is a feasible way to partly solve the issue without endlessly waiting for the HERO to appear.

    Debian should consider allocating some budget like several hundred USD
    per month for the LLM API calls for all members and new-comers' usage.

    DebGPT can be hooked somewhere within the debian development process,
    such as sbuild/ratt for build log analysis, etc. It is cheap enough
    and people will eventually figure out the useful apsect of them.

    Opinion against this post will include something about hallucination.
    In the case LLM write something that does not compile at all, or write
    some non-existent API, a human is intelligent enough to easily notice
    that build failure or lintian error and tell whether it is hallucination
    or not. I personally believe LLMs, at the current stage, is useful
    as long as used and interpreted properly.


    BTW, I was in the middle of evaluation LLMs for the nm-template. I did lots of procrastinations towards finishing the evaluation, but the first
    several questions were answered perfectly. https://salsa.debian.org/lumin/ai-noises/-/tree/main/nm-templates?ref_type=heads
    If anybody is interested in seeing the LLM evaluation against nm-templates, please let me know and your message will be significantly useful for me
    to conquer my procrastination on it.


    --
    cheers,
    Holger

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
    ⠈⠳⣄

    Wir sollten allen Milliardären weltweit ein Ultimatum setzen: Wenn ihr in einem Jahr die Klimakrise nicht gelöst habt, werdet ihr enteignet!“ (@nicosemsrott)

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmeEz7sACgkQCRq4Vgaa qhwNdA/9G5BBVF5gu0AThJD1RdWpzSoTWt7vFuXbcN49Rq3649UiOk0ICQOdE+GJ +4jkzKPbYP78/PhtNpBAE22PsBV41pRGRUl84V22PY5aQlPnbEcoVg14bfzfBIYJ JbIDY1IB1x4F8s7P6OA52R+TRhzVlsFZy1/8SzcfQBItMOasTc8MYee9fz4F1O2q af/1OZrQUA/Bs7A4jUAwJkUi/H0/JCvzpxPGoeRnqyrpRNcclyYthiKX9pUCnZUz lxtz5/YIIl6pcsnBzqo4pY7rkbQGJ4RG67NPln48iLio17r8qtddgE4s2IgB50cb m6F+gB/yMqtuepxliwuGc40BilF2EvElveklfPa9xcczEG1KEpJTW24kF4DfItLe m3Ml5X8huslpNZk3xev8HgFCZZtqwx8YKIRW3HFwCEkbh7QsxAVCAPthR8HPzMGk 7eKAeFA5N1ZCg+u/nM8a0irRZSrLNAWX/MxjaaLPGCWu8O+EketsdrEj0bNokhMO jTdvNSfSGldhDc5
  • From Jonathan Dowland@21:1/5 to All on Mon Jan 13 11:10:01 2025
    On Sun Jan 12, 2025 at 8:54 PM GMT, Serafeim (Serafi) Zanikolas wrote:
    what would be truly amazing, imho, would be the whole wiki on git.
    that'd allow for mass-updates, and reusing one's code (salsa)
    workflows for documentation

    Back before we adopted MoinMoin (the previous wiki tech was kwiki iirc)
    a couple of us did a brief exploration of using IkiWiki for Debian; it
    didn't go anywhere (on my part I didn't put enough into it) but one of
    the advantages of it would have been that IkiWiki supports using git as back-end storage.

    If there's anyone interested in the Debian Wiki at FOSDEM I would be interested in having a chat. I haven't personally done any work on it
    for many years but I've remained interested in it all along. My
    particular passion (back at the kwiki→MoinMoin transition) was ensuring
    that wiki content was DFSG compatible; that's still something I would
    like to see improved.


    Best wishes

    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to Ahmad Khalifa on Mon Jan 13 11:20:02 2025
    XPost: linux.debian.devel.mentors

    On Sun Jan 12, 2025 at 3:52 PM GMT, Ahmad Khalifa wrote:
    Understandable of course, but the email slows things down a bit.
    MoinMoin doesn't have SSO support, but if anyone's interested in OAuth2
    and writes python, it's typically very straightforward: https://moinmo.in/EasyToDo/implement%20oauth

    I'm *fairly* sure that a more pressing issue is that MoinMoin requires
    Python 2, which has been abandoned.

    At least the stable and deployed versions: 2.0.0a1 is the first release
    from the 2.x branch which is a rewrite for Python 3, released 2024-03-24.



    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Dittberner@21:1/5 to Jonathan Dowland on Mon Jan 13 11:40:01 2025
    On Mon, Jan 13, 2025 at 10:10:25AM +0000, Jonathan Dowland wrote:
    On Sun Jan 12, 2025 at 3:52 PM GMT, Ahmad Khalifa wrote:
    Understandable of course, but the email slows things down a bit.
    MoinMoin doesn't have SSO support, but if anyone's interested in OAuth2
    and writes python, it's typically very straightforward: https://moinmo.in/EasyToDo/implement%20oauth

    I'm *fairly* sure that a more pressing issue is that MoinMoin requires
    Python 2, which has been abandoned.

    At least the stable and deployed versions: 2.0.0a1 is the first release from the 2.x branch which is a rewrite for Python 3, released 2024-03-24.

    Hello,

    I take care of the administrative side of https://wiki.cacert.org/ which is also based on MoinMoin. We did a test installation and content copy of the CAcert wiki based on the 2.x branch after FrOSCon 2024. A a lot of our
    content had blocking issues (we use many macros to include shared content on multiple pages.

    We (another CAcert member, not myself) were in contact with MoinMoin people, but progress on the issues is quite slow. I think the MoinMoin people would appreciate help to get the 2.x-branch ready. Unfortunately I don't have
    enough time to help there.


    Best regards
    Jan

    --
    Jan Dittberner - Debian Developer
    GPG-key: 4096R/0xA73E0055558FB8DD 2009-05-10
    B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD https://portfolio.debian.net/ - https://people.debian.org/~jandd/

    -----BEGIN PGP SIGNATURE-----

    iQEzBAABCgAdFiEEKHuXKkUYdvdO9493DXkdyNc3wdkFAmeE7SIACgkQDXkdyNc3 wdmL0wf/dss20LbLgd1Aepcx7PyS3R28PE5KLPAnSfSxdb2ooomIwB/Lh4dx7sSj nT3GC1zASCCqTPOLP+Xkpi3j3jcqMBit6I6KAKeSHgu1BFqUXmrZWU5ES37g67BG m/4j593LiBh9CfpAXIDAXB5YDDYhOgXDSAJAaSQvPTY+iutToNbpyNDJ3XQO7qne WrMPdbMRh8BnMSO5jqtyWQ9nPqMWOAbRFqDpzLnxhLpzeu6aQhz9sfsgA1CR+GqD RoqztDAq51z8Jkul6xcXJpxr/WAROhfUG9iViADIEQK1iVdulOBVoG34gzSV/Z9a 5WmwioxXNOu7CeiLJKIuqKZianT5ZA==
    =Pk9y
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Serafeim (Serafi) Zanikolas@21:1/5 to Jonas Smedegaard on Mon Jan 13 22:10:02 2025
    --a48349db803f08fb254babeff8a44d1df1ce9bbd7e499174a5bcdbeac358 Content-Transfer-Encoding: quoted-printable
    Content-Type: text/plain; charset=UTF-8

    hi Jonas,

    On Mon Jan 13, 2025 at 12:45 AM CET, Jonas Smedegaard wrote:
    Hi Serafeim, and others,

    Quoting Serafeim (Serafi) Zanikolas (2025-01-12 21:54:58)
    what would be truly amazing, imho, would be the whole wiki on git. that'd allow
    for mass-updates, and reusing one's code (salsa) workflows for documentation

    For those not only wishing that others made that happen, but consider scratching that particular itch themselves, I am happy to chat with you
    more detailed about what that involves, and how it is a quite exciting challenge - so exciting, in fact, that Debian has had several attempts
    at doing a migration over the years, but none so far have succeeded.
    [..]
    But let's not hijack any further this thread about welcoming newcomers,

    let's create a new thread then :)

    I just wanted to chime in to encourage anyone wanting to do the wiki modernization to get in touch with me to discuss further.

    thank you for the offer but why not have the follow up in a publicly archived list? happy to switch to -www, if -devel is not ideal

    I think that a retrospective/postmortem of past attempts would be very valuable.
    I offer to write one if you'd be okay to share all of the context with me (you could review it before it gets published).

    also, I'd think that nailing down the requirements for a new platform and for the content to be migrated (e.g. drop any pages that are >X years old) would be an important prerequisite for any technical work. has this been done in previous
    migration attempts? to start with, do we have "rough consensus" that a git-backed wiki would be preferable?

    thanks,
    serafi

    --a48349db803f08fb254babeff8a44d1df1ce9bbd7e499174a5bcdbeac358
    Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEA2RWqo7IwLCLSFYbT59tVQ7WEioFAmeFgDkACgkQT59tVQ7W Eiq2PQ/9G7Nnp1q4YM13a0te7VFM8m+8tavvsUcaFNU9FhDD1AwtRpuRBbs8ci8y IFEhkP0eb9+FXP1Tp1CfKuD/FnyGFsbgstPnkVOiGmOvLCy2VIt7W42sb8h2bn/4 Jje5GBu6b9jkINCFMQLfmfrryza/4VOgS1v2UDi4R+e6Hxk4LoS5M3/G9ual1JTI iFevJ9Cx1UG5kf0b0MZh7zC6c3jQjYqf/7a0rWIRy7BhFBNCpSn9VvD+nQp8hpYH PYA8Etxongq0konabG8sAcMsNk0E3nqjRAiZHNRTHX1eoBZB3ryZMHCpueTeJBbO AH0BgNui4aDGcygMpUraIw8l+3Z3gQzJtXH2rjp6nLAiycywh/HQa+Yv8ZGHZk+C 7jPABNjWqKgmzcx6TaCqIplGachVrtGZw0SFS93aKcb7vDEQ7Bqkkpbv0y48lPNF qB+PAWVCPjlwxgj0vbaEStCfKOqfFO0Mx02El7+FHuIPRP0gjVPMizewUBVuEpJn NskoKCPunlQ5fXnmNkuKcY/gbUnaZlEHixqrBDyPY+o57cSXXPc9X1wynWSlk/w5 c4LspBhRPhxqHvpeCE8mcbVMu/s/crFA++SqLks15xqS6ir5lSVwyhSMdSoW3Ogn Mcu71hr9NFYnrqzzG2SLrm5lhtH33m3FGffait9FpPJ77cfKi9s=1uYr
    -----END PGP SIGNATURE-----

    --a48349db803f08fb254babeff8a44d1df1ce9bbd7e499174a5bcdbeac358--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonas Smedegaard@21:1/5 to All on Mon Jan 13 22:50:01 2025
    Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
    On Mon Jan 13, 2025 at 12:45 AM CET, Jonas Smedegaard wrote:
    Quoting Serafeim (Serafi) Zanikolas (2025-01-12 21:54:58)
    what would be truly amazing, imho, would be the whole wiki on git.
    that'd allow for mass-updates, and reusing one's code (salsa)
    workflows for documentation

    For those not only wishing that others made that happen, but
    consider scratching that particular itch themselves, I am happy to
    chat with you more detailed about what that involves, and how it is
    a quite exciting challenge - so exciting, in fact, that Debian has
    had several attempts at doing a migration over the years, but none
    so far have succeeded.
    [..]
    But let's not hijack any further this thread about welcoming
    newcomers,

    let's create a new thread then :)

    I just wanted to chime in to encourage anyone wanting to do the wiki modernization to get in touch with me to discuss further.

    thank you for the offer but why not have the follow up in a publicly
    archived list? happy to switch to -www, if -devel is not ideal

    Then let's move to the tinker team mailinglist: https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    I think that a retrospective/postmortem of past attempts would be very valuable.
    I offer to write one if you'd be okay to share all of the context with
    me (you could review it before it gets published).

    I don't mind discussing in public, but do mind doing it in this large
    forum.

    also, I'd think that nailing down the requirements for a new platform
    and for the content to be migrated (e.g. drop any pages that are >X
    years old) would be an important prerequisite for any technical work.
    has this been done in previous migration attempts? to start with, do
    we have "rough consensus" that a git-backed wiki would be preferable?

    No, I am unaware of any consensus on any changes, just have a vague
    feeling that MoinMoin is somewhat as appreciated in Debian as CDBS :-)

    Anyone interested in discussing practicalities of migrating away from
    MoinMoin for the Debian wiki, please join the tinker mailinglist at https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    - Jonas

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private --==============`88063803688278757=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    wsG7BAABCgBvBYJnhYkcCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmfPAHPhtXS1YApMGWwIftsXWP132RNRscRmZGzoqBUS vhYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAADgfQ//VsjZKspnjPE1NQya3C7+P4Py UD5Q4gHSfM8rGa8kschWvdfLV4Uk4ZAG6lY4A9L5NALhgZj9uuetVfhzgkhnl4q6 xoNfyaoh6bBnnpGZo6NoXZf0TDWWfvZaPyPkmuePMKJZlYOnsgDOZ0kv4MCujcmf XT7YjlEgkNR/TnCU4/bVQHJsoAeWVAc27qWhU6yzbgQJ4szGqTeLaeg5VFaL0OTa DCb45MuNic9LKeGdavC9Or5i2yzN1RlA/Hg0gBflvoxw384f+EFqZwB7EVlRXoke jfiPb4lw+JSXnS0aKicO9g8K113oTrDYlDRt1W7wwqsFeNfufcyNtSuipwOdWTBx fmEsC5rhNiSjnim4SIleoK9Bxl5HZ5Kf/VeVr14V
  • From Ahmad Khalifa@21:1/5 to Jonas Smedegaard on Mon Jan 13 23:30:01 2025
    On 13/01/2025 21:43, Jonas Smedegaard wrote:
    Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
    also, I'd think that nailing down the requirements for a new platform
    and for the content to be migrated (e.g. drop any pages that are >X
    years old) would be an important prerequisite for any technical work.
    has this been done in previous migration attempts? to start with, do
    we have "rough consensus" that a git-backed wiki would be preferable?

    Wikis have their own version control and they're meant for a much wider audience. I think general documentation definitely belongs on a wiki,
    not git. Edit, fix typo, done in 30 seconds :)

    No, I am unaware of any consensus on any changes, just have a vague
    feeling that MoinMoin is somewhat as appreciated in Debian as CDBS :-)

    Anyone interested in discussing practicalities of migrating away from MoinMoin for the Debian wiki, please join the tinker mailinglist at https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    I'd be interested in knowing more as well. I can't imagine there are
    more features in MoinMoin that can't be migrated to MediaWiki and
    friends, so I want to find out what I'm missing.


    --
    Regards,
    Ahmad

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to Jonas Smedegaard on Mon Jan 13 23:20:02 2025
    On Mon Jan 13, 2025 at 9:43 PM GMT, Jonas Smedegaard wrote:
    Anyone interested in discussing practicalities of migrating away from MoinMoin for the Debian wiki, please join the tinker mailinglist at https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    What is "Tinker blend development discussion"? I've never heard of it.


    Thanks,

    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Stanley@21:1/5 to Jonas Smedegaard on Mon Jan 13 23:30:01 2025
    On 2025-01-13 22:43:59 +0100 (+0100), Jonas Smedegaard wrote:
    [...]
    Anyone interested in discussing practicalities of migrating away from MoinMoin for the Debian wiki, please join the tinker mailinglist at https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    Out of curiosity, what does the Tinker Blend have to do with Debian
    Wiki management? It's described as "a Debian Pure Blend which aims
    to provide fully configured installations for various forms of tinkering/hacking on electronics and other hardware devices."
    --
    Jeremy Stanley

    -----BEGIN PGP SIGNATURE-----

    iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmeFktlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCnYGw/9FoEl6RLtqn5svii484BhoRQh/j9vKr/uVtJeLfiPsHEWRsYHI+ksImU7 2ShzOLnid8n8BAkc8wbLK7aJCWk6h8PsB7aNn8lxZXh19A5MHXRJr/l9ybAVBQLm PL1ZFTbVsl7fCpY9gumpmsQnuXsT9YBOP+nBMPoVyW8TOmqJLxm/y49u9M/NHmmK eLKn/hUdTwBWvQVny8XdFsyFs7RuetNoHewsoHVNEnv/pBrp7L+GpN02SqEryya9 vhNpXP2BGbe5RFxQ9lilDv+zOSeEWm0ox9Vas8Z58c+FFj2avyISCqJIJo4m9MMo 04/wwWfvJfEerUOCdn/08UWz53LdbHVpy7VVm6QkX4IhAWBFe4cUvgAYPSYaKtNT klmtEOxxx0EQOXo3zGs5otgoVZo2Gr7J9BTbYqDa9T+ZlcKnV/2mu+eX7dEUkKr2 yarA1hPN5aUOakXXjyIP8fOlvJBMCAim6k2a8GraW185IurMDJRoCpDdExONxYWx oQlQ+zx4c+VzAUK1EB7S83U1YBQUieFSmN/Bn3MLx9luGPsbwlQsXgdBUTiAD5O1 tkuKkFbmMZHnW89Jp5+1NH9VNExG7RdDgOLWsoCjPxGCMFix6U6ZxM7UTTlPsh4W 0AjhZgaCSbiH0rJ8Idzb/fcLdsc6YwsrwB35M6PK0gR83XY52dM=
    =Lz9/
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32
  • From Jeremy Stanley@21:1/5 to Ahmad Khalifa on Mon Jan 13 23:50:01 2025
    On 2025-01-13 22:27:21 +0000 (+0000), Ahmad Khalifa wrote:
    [...]
    I can't imagine there are more features in MoinMoin that can't be
    migrated to MediaWiki and friends, so I want to find out what I'm
    missing.

    Another free/libre open source software community I'm involved in
    migrated a fairly large corpus of content (10k+ pages) from MoinMoin
    to MediaWiki, mainly for access to more robust spam and abuse
    handling features. The effort was managed by a community member who
    was also a Wikipedia sysadmin on the WMF staff, and required a fair
    amount of cleanup after the fact, so not for the faint of heart.
    Granted, that was about a decade ago now; it's possible the tools
    for doing it have gotten smoother in the meantime.

    Having acted as a site admin and moderator on both, I can't say
    there's anything I miss from MoinMoin other than the fact that it's
    implemented in Python instead of PHP, which made modifying it or
    writing custom plugins for MoinMoin myself a little easier and less
    dicey.
    --
    Jeremy Stanley

    -----BEGIN PGP SIGNATURE-----

    iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmeFmHJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCnMgA/+M74nq4lQD4Qfc2yZ6nxshzrDQNCnZj0Svtgg+Pa1sVt7dHrPmgnHH36J SVrGT4CxqLkE0R6lK0XaYJjlg7nHBY6WgajjGjBiJuhiMbIlpZAXbp0JOWmiUOUA 6maTJAc3hU0X6Mfm4y4D/EqiOBqPBRNyyWREs6NG+GYwcL08+sRBKqXlo0alfEfB UQd2/OHJcLEb0w9NL2sL11zIqzUVDa7tSRxEOCdvpgBDCj4MNVhM9qhEBF+I+wEi tNhlx5W4rX2FmBS5ECLWhMmOOsk1rV1/56XL3sZia0plN9rskyyIrHn4XktK8SLJ tVP2ioUMFbzx5tgZUvrD1v83DAf7wkl4c257fF2TaW13imteITmx8z7M5QKZSGYM pOH3DMLJgLrzz2dKT6fM+ibHg3B00BdPTxC1/IKSMsza6ElkT4+Agf59Z04Jy1Gv jKlUE5HyW+6jRDyj3ZukS835rslE28JaWFIgnD1vTD803FGEjc8yJtz103IhHsIm Fwp28JBZ4YLvMUMdEftNGew7EHyKODa8049NMsTzpYbrBuZ2bSjtpPpJuuaGmC1e CGOa99r0QQs/oIPzyOZ4ur69HFim1qCYCmvDrAkEghrdA54nbdBj0geqsTsNV69S q5JlO0xTqyPbJ+oWQm6Z1GxRxiIP0h7fVQNKlrd0doMB7KgGRSc=
    =GPS6
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32
  • From Jonas Smedegaard@21:1/5 to All on Tue Jan 14 00:30:01 2025
    Quoting Jonathan Dowland (2025-01-13 23:15:35)
    On Mon Jan 13, 2025 at 9:43 PM GMT, Jonas Smedegaard wrote:
    Anyone interested in discussing practicalities of migrating away from MoinMoin for the Debian wiki, please join the tinker mailinglist at https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    What is "Tinker blend development discussion"? I've never heard of it.

    People interested in lightweight systems, like the OSHW-certified
    ARM-based laptop and server systems from Olimex.

    There is no "MoinMoin" in that team, but very little is going on in that
    team, and among those few people there have also been an interest in
    hosting MoinMoin due to its neither being bloated nor PHP-based, and consequently some interest in migrating away from it in more recent
    time.

    - Jonas

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private --==============h03754117178762237=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    wsG7BAABCgBvBYJnhaCeCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmcDmXridk6Ayyj0tD6PEMqfnrvj87shj7AzvaE1GBCU aRYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAADohQ/+Nim5ApuPCqwY19fD91TZ+moQ X6dW1RZOTNndULv08NkMWdRvRxLW4s2xKmrnxUxLr4iOt5cGbVHJX8+VmT1dWL/J zMdQYRGESjmdAPAUsKXS2725zpnVJ943NZ3KVajrf/voFrE6EuGMyia5VOCe39P3 3rJ3xhJYwuvix7E8xp3zwgo8wOn2s8BMnyvsnIyW07PYd/h22P7piuK1HNVGTa1W tMAuxQzDNWnhB37PaXbwwkZsERUZzDtKDsBGlgCMJ24bihifR7tRI5WU8PwAoJJA XIKRIYFACqoHnZFDYZD6tHKTpPCdIEtrv0+f9WSfAuMAoPO9mWzArYwB5z7/7vOs SkE6cKpeO3Ibq1YAyfAwgXuwPjTNGlHChtNrfcEo
  • From Philip Hands@21:1/5 to M. Zhou on Tue Jan 14 09:00:01 2025
    "M. Zhou" <lumin@debian.org> writes:

    On Sun, 2025-01-12 at 16:56 +0000, Colin Watson wrote:

    (I have less fixed views on locally-trained models, but I see no very
    compelling need to find more things to spend energy on even if the costs
    are lower.)

    Locally-trained models are not practical in the current stage. State-of-the-art
    models can only be trained by the richest capitals who have GPU clusters. Training
    and deploying smaller models like 1 billion can lead to a very wrong impression
    and conclusion on those models.

    Isn't the corollary of that statement that all the useful models
    available have been trained on material that we have no clues about
    regarding the status of the copyright/licensing?

    Even without considering the case where the training data belongs to
    some litigious corporation, the thing that concerns me is that these
    models have presumably sucked up every scrap of e.g. GPL code on the
    net.

    Having done that, they produce answers that are somehow informed by that
    data, without any indication of how they arrived at the answer, and
    certainly not a notice that the authors who produced the training data
    intended there to be restrictions on the use of their creativity (that
    an ethical person would want to honour).

    I'd really like to know how it is possible for one to use an LLM to make
    a contribution to a permissively licensed project (e.g. Expat) without
    in effect stealing the code from one's own tribe of Copyleft authors.

    Can one even play with an LLM without somehow contaminating one's brain?

    Cheers, Phil.

    P.S. AFAIK the likes of OpenAI declare that the output of the model
    belongs to the prompter, but that strikes me as self-serving nonsense
    that the courts will eventually rule on. I'd love to be proved wrong on
    that though, because I'd quite like to play with LLMs, if only to do
    things like generating potentially lethal cooking recipes to try out ;-)
    --
    Philip Hands -- https://hands.com/~phil

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmeGF8cACgkQ0EujoAEl 1cBxShAAhZ8eNPA9/jHBm0yw/DoCfV2T7K69lquv7O/3iek12lcL8gwNKMlj4L66 lI5Bw7dkyQ+/1ItK0jfzGSUgrytc0AZ9O/gFPY4ofVPwzpcX7HSf+5+ZyUlR361y pWGVZEC7PN/wXvbGpdcIBYNMAIvAUWhH2xwJ7NK1TBPIbOib/aXX4nm4Eg0FiYJq xEG2McEpE6EdsrA1rXpxhs1ru+34+gtXfQtN66SjxXKSoYvhGEiozIppsMv22sJB IUTaLhhs5qorCYE1O9nMturGAkYtcOJ9FD/pLv6vojleixAdYFzUWqYhlVCevCRv Z8zz/uWYn4kPhWg3FEfPrlKv+FR+mealXG8X4ZafbAvbwB71KaAW2l37cZjzJmN5 eWc2N9i5YvLMJ6wfRVWpH1+Qa2SZloZziuIlSd3cfWabSR1bE4eSkE+rR+3LDw1y L3rflOMKtBt0XGTL2tNSvccIxuJqCU2klmVabZbLpfAD7m4TKRRaNRP1OIy+/DNI 5VV/nom/FafE3B8NOqLsdS2j/eVZGeYefrYy1t1CjBRApc/oTOWIO/rxSNsvrfeZ CShrHk3P/oA2x5ec5h/r6ZOaiDleMLXSRNusvEe5MBLoGumPREdMqvsKQKIct78e 6mAB/JvSrjsW/w66+wSEEqPw4qGopw7w+QhsUgjHz3N6Hf9lJwI=uvLt
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gatewa
  • From Andrey Rakhmatullin@21:1/5 to Philip Hands on Tue Jan 14 09:10:01 2025
    On Tue, Jan 14, 2025 at 08:52:39AM +0100, Philip Hands wrote:
    I'd really like to know how it is possible for one to use an LLM to make
    a contribution to a permissively licensed project (e.g. Expat) without
    in effect stealing the code from one's own tribe of Copyleft authors.

    Can one even play with an LLM without somehow contaminating one's brain?

    Is this the same with reading some GPL code directly instead of using an
    LLM that have read it?

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmeGGhQtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh EjcQAJtfNi+ra2zVjJHi9s9cT1GYKSUfn1zrIBoff52Y1rNhcyxcmVIF67CI5tW3 tvyAHB31ip6ny+2ImpJvIZeQ4eY9XvOysz9UiQZ4YqXpdG4POii6/ADboZYFE2pQ vVBUpP1Hbov9rfl11TUg0ysqVr2Q2iAsAGfjcTSzmYar0muEI4OSV29B+G+X58+l f5SMDsrnhM14JHYVpbJF1H8FzolspDhLYHA9i9i1z66EYBwXmHxIbwy1UL5gfj+z sRGz8MLNLvsH9P9oP+qQToy1a5G2ALY6Rn9CkgBt7XsNmaiKvk0aeEdr7SxgiY1V reS8D4ZdKIMyjBx8EPL2i3B3UFp7/n7c8CJ55OW6wlTapV7F1S8D2jeEh4zWBXCJ I6Xt9Fiwj8gJGGXD9NgDlnzxnEC/GLNvjzufa8QuyNVOJ7eXfBygJ0MhY68dAgho trL0V0xeXB4OPmoQVuZH0w1UFaPirHF2EDutouO9qO+k4byyBZH9+MmMNuOrwsZb 3jz2a9lTsAdHRDVJZsjKxUllZMfRNTAOqkvRONZeJP3LW8cORMoyHVyVJTalajFv yr+Dic2TW/w6waGgQ29AybZVG/mOCTs2Boy3NpjJFQgOyTSlbrgdC9EmcZyTVj02 tvlwfRJlnnKhddaCEnqzJ/ukVvhWRb/NqM6K1RYjrDi90t6L
    =3Giy
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to Ahmad Khalifa on Tue Jan 14 09:30:01 2025
    On Mon Jan 13, 2025 at 10:27 PM GMT, Ahmad Khalifa wrote:
    Wikis have their own version control and they're meant for a much
    wider audience. I think general documentation definitely belongs on a
    wiki, not git. Edit, fix typo, done in 30 seconds :)

    The two git-backed wikis I am familiar with (IkiWiki, and GitLab) have a
    full, traditional web UI for interacting with the wiki, and the Git
    back-end is effectively invisible from that perspective, but, power
    users have the ability to easily create a full backup of the full wiki history; perform large-scale or complex, machine-assisted edits on the
    local copy; use advanced merge-conflict resolution tools.

    Having said all that, I believe any effort to revamp the Debian Wiki
    should start with determining the requirements and goals, rather than
    start picking solutions.

    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve McIntyre@21:1/5 to Jonas on Tue Jan 14 16:00:01 2025
    Jonas wrote:
    Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)

    thank you for the offer but why not have the follow up in a publicly
    archived list? happy to switch to -www, if -devel is not ideal

    Then let's move to the tinker team mailinglist: >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    Erm, WTF? How about keeping this on a main project list. And maybe
    even include the current people working on web and wiki admin?

    Unimpressed...

    --
    Steve McIntyre, Cambridge, UK. steve@einval.com Can't keep my eyes from the circling sky,
    Tongue-tied & twisted, Just an earth-bound misfit, I...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonas Smedegaard@21:1/5 to All on Tue Jan 14 16:10:01 2025
    Quoting Steve McIntyre (2025-01-14 15:16:49)
    Jonas wrote:
    Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)

    thank you for the offer but why not have the follow up in a publicly
    archived list? happy to switch to -www, if -devel is not ideal

    Then let's move to the tinker team mailinglist: >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    Erm, WTF? How about keeping this on a main project list. And maybe
    even include the current people working on web and wiki admin?

    Unimpressed...

    WTF what? Should we stop work in smaller groups and discuss everything
    here in one giant mailinglist for every detail of the project, or what
    in particular makes this detail so F'ing global?

    Offended...

    - Jonas

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private --==============%30625836974125452=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    wsG7BAABCgBvBYJnhnyZCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmfsTnsAvuwygy0rY/t9oFt1iQm/dnmarPAbeYUUjlwG FBYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAAB77A//YeJyvdSXVPmsnkkYkmf834zn 54iP40hrP6ekl1fEDItXEO9JgR5zq3pymrnDoVEnaijW8owqtLw7ozsNGO/J6zxI 8Qb9M1immn/Ftl/l59Dg859UlNBPx0QWBxqnbC+ofVdzRYKCHh6FdCK70PjYaBep DirXISEPceq4xYWVrLSOdwLnBbyz4D4eNCdyAcSmVE3VDh+pd+Eob/PCCkTgsAcx NxGhvChDpTOkbpa5ulQeX7p1T6447Uo7OD11ukoMNWV247+TJgkohR1Rnqel1ypl 6USriv/Rwc6py7bSsk70sUPGdyzz0waUR+S0/N6Zf/k4d9/JjsrQwdq4SVdd+y9U 6/vPYH/Z8898TMndKcShcUL0K+ZUZFrQIpZxiuy/
  • From Steve McIntyre@21:1/5 to Jonas on Tue Jan 14 17:30:01 2025
    Jonas wrote:
    Quoting Steve McIntyre (2025-01-14 15:16:49)
    Jonas wrote:
    Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)

    thank you for the offer but why not have the follow up in a publicly
    archived list? happy to switch to -www, if -devel is not ideal

    Then let's move to the tinker team mailinglist:
    https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel >>
    Erm, WTF? How about keeping this on a main project list. And maybe
    even include the current people working on web and wiki admin?

    Unimpressed...

    WTF what? Should we stop work in smaller groups and discuss everything
    here in one giant mailinglist for every detail of the project, or what
    in particular makes this detail so F'ing global?

    What on earth makes the blend-tinker-devel list a reasonable place to
    discuss the Debian wiki and maybe working on replacing its software?
    Serafeim suggested debian-www, which seems like a much more reasonable
    place to me at least.

    Offended...

    What, that people questioned this? That the people in the team
    *running the service you're talking about* might care about
    discussions about it?

    --
    Steve McIntyre, Cambridge, UK. steve@einval.com Can't keep my eyes from the circling sky,
    Tongue-tied & twisted, Just an earth-bound misfit, I...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve McIntyre@21:1/5 to Jon Dowland on Tue Jan 14 17:50:02 2025
    Jon Dowland wrote:

    I'm *fairly* sure that a more pressing issue is that MoinMoin requires
    Python 2, which has been abandoned.

    At least the stable and deployed versions: 2.0.0a1 is the first release

    *nod*

    I think we have moin2 packages just about ready for use, but I have
    worries: it's not simply a dropin replacement, and the first few
    attempts I've made at migrating some test wikis didn't go very
    well. And then lots of ENOTIME :-(

    "We" are a small team running the wiki. Like a number of places in
    Debian infrastructure, ongoing admin is a time commitment that it
    seems very few people are ready to make.

    --
    Can't keep my eyes from the circling sky,
    Tongue-tied & twisted, Just an earth-bound misfit, I...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonas Smedegaard@21:1/5 to All on Tue Jan 14 18:10:02 2025
    Quoting Steve McIntyre (2025-01-14 17:27:20)
    Jonas wrote:
    Quoting Steve McIntyre (2025-01-14 15:16:49)
    Jonas wrote:
    Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)

    thank you for the offer but why not have the follow up in a publicly
    archived list? happy to switch to -www, if -devel is not ideal

    Then let's move to the tinker team mailinglist:
    https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    Erm, WTF? How about keeping this on a main project list. And maybe
    even include the current people working on web and wiki admin?

    Unimpressed...

    WTF what? Should we stop work in smaller groups and discuss everything
    here in one giant mailinglist for every detail of the project, or what
    in particular makes this detail so F'ing global?

    What on earth makes the blend-tinker-devel list a reasonable place to
    discuss the Debian wiki and maybe working on replacing its software?
    Serafeim suggested debian-www, which seems like a much more reasonable
    place to me at least.

    Offended...

    What, that people questioned this? That the people in the team
    *running the service you're talking about* might care about
    discussions about it?

    No, but that my proposal for discussion place was so out of this earth
    that you felt the need to curse over it.

    Obviously I am so fucking stupid that I didn't know that the wiki team
    used same mailinglist as the www team.

    I stand fucking corrected.

    - Jonas

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private --==============p58005984343207030=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    wsG7BAABCgBvBYJnhphLCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmfzAI0QQzsLxFOvjNKQR0x7wkUSw8Dbb9CfFoYm9g4I kxYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAADo8Q/9GLm3DmBbWlrfAMAiSznCOCwC pn4Su2/VsrEfMuiFGq5GWa+tqBNBOCgfw6R3KM6x7rILREEA11tIWqf1JBDPfzyr wHEbEJMqlUSoWsgR7gMzH8vkq1gduPEzXZfw7gEuO/dU0XzU6KOwbz4yr9Zb0821 vdXuiHVzzGPhfJhObV1O+lvgVnkfRn+wax30KLFT/ouKKXVCjKqzGpSJCUeDiY+8 6RaOfztRTrVHW0ntnwAM1vtMC5436kugzYktxox2w8iHXSo0zUZjTkzRvALnzUDV VcIcqYyCL53gDZLl3CEV6Mecx2PKnZEP1igiX9Nm/42sljbPwUp5zWlBMk8qL8md 0yLmtNJT7y9bulIodcyE6asj+Xk5DJ2JC59Dl35V
  • From Chris Hofstaedtler@21:1/5 to All on Wed Jan 15 11:50:02 2025
    * Jonas Smedegaard <jonas@jones.dk> [250115 11:40]:
    Quoting Andrej Shadura (2025-01-15 11:24:31)
    Hello,

    On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
    Then let's move to the tinker team mailinglist:
    https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    No, but that my proposal for discussion place was so out of this earth that you felt the need to curse over it.

    I hate to be the person to break the news to you, but some random unrelated mailing list of which very few relevant people are members, seems like a very wrong suggestion indeed.

    Then it might please you know know that you didn't break it to me,
    others fucking did.

    But thanks for stepping on it. Anyone else while we are at it?

    Actually, yes. It's really unclear to me what you are trying to
    achieve here, with the continuation of this communication style.

    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrej Shadura@21:1/5 to Jonas Smedegaard on Wed Jan 15 11:30:01 2025
    Hello,

    On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
    Then let's move to the tinker team mailinglist:
    https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    No, but that my proposal for discussion place was so out of this earth
    that you felt the need to curse over it.

    I hate to be the person to break the news to you, but some random unrelated mailing list of which very few relevant people are members, seems like a very wrong suggestion indeed.

    --
    Cheers,
    Andrej

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonas Smedegaard@21:1/5 to All on Wed Jan 15 11:50:01 2025
    Quoting Andrej Shadura (2025-01-15 11:24:31)
    Hello,

    On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
    Then let's move to the tinker team mailinglist:
    https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    No, but that my proposal for discussion place was so out of this earth
    that you felt the need to curse over it.

    I hate to be the person to break the news to you, but some random unrelated mailing list of which very few relevant people are members, seems like a very wrong suggestion indeed.

    Then it might please you know know that you didn't break it to me,
    others fucking did.

    But thanks for stepping on it. Anyone else while we are at it?

    - Jonas

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private --==============89488005009962021=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    wsG7BAABCgBvBYJnh5CJCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmffeSeW6UX2Xpjg8U9mB1qz8ZQ9yqbO9Zp+4i84Q8I4 wxYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAAAn4g//RkGY55zHjRAU3FHxEzTR+A1d Dh3CeusoD2jaLwJ51cRiqJBwNJOYtKaRhQtvCOFL2OyI6XMB6sDNGkB4bTmPrSZx 4VPUlAkdm7o7FqRoeN+I/04ORdhy3ccEg9cULYUdNQiIwwelM18T0DNEZo19jq3s 2VgC/mVg/e5E0sUIMEpAV+MnEQ54HytAqrz+dxT0x89HEEUwie4EB2O9FQUwe4Ik B/1EOrdQPi8vD6KwFrlcZ0gPbHC6JWIR6mM+mv6ipyekzBiNouoc2c0W4ig8RA0c m+1yKVq1xEL4DZcXS194Wh3tbe50WYUh6X6wYxLS9pwBxyTv5cFQLXRsRvhIZbG1 lxj1wqt+8eGoZXyn5RD+LXvHytDOmWa8fliVOycB
  • From Jonas Smedegaard@21:1/5 to All on Wed Jan 15 12:20:02 2025
    Quoting Chris Hofstaedtler (2025-01-15 11:44:19)
    * Jonas Smedegaard <jonas@jones.dk> [250115 11:40]:
    Quoting Andrej Shadura (2025-01-15 11:24:31)
    Hello,

    On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
    Then let's move to the tinker team mailinglist:
    https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

    No, but that my proposal for discussion place was so out of this earth that you felt the need to curse over it.

    I hate to be the person to break the news to you, but some random unrelated mailing list of which very few relevant people are members, seems like a very wrong suggestion indeed.

    Then it might please you know know that you didn't break it to me,
    others fucking did.

    But thanks for stepping on it. Anyone else while we are at it?

    Actually, yes. It's really unclear to me what you are trying to
    achieve here, with the continuation of this communication style.

    Nothing. My posts here contribute nothing - they are not moving the conversation forward. Speaking just for myself, that is...

    - Jonas

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private --==============87422599481955973=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    wsG7BAABCgBvBYJnh5huCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmdaEDI3i9gC6jj9Jj1xPdNdcDxXpIzFf6n7chPN3ZK/ QxYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAADCJA//UUnJvLNA5wfhYFcSmaw9SqRm jXyNY3a/LYXs/JmLEVDYy7PNNFb+KcJ2BiiKppRmhut6w/4HnaHcmhgU8CO8uZNF WGMxPBd2sqXpW8dCoWPpAHuUmfx/SBAWhojbISQjKxonmUAOe6LvR/pN6Y23636C FSDG0rWrhA02admQjpHDLR36df8AgkbBDYWt4XL7wBbYYpUwOUX6u0ysGT34h9+y KAsYT8QBML+UtcK4vQoKajaawjmABtJrL9nqryzB7XKSY0GUzMaakcT6SaY1eyW4 5g/s5pBEkUGmvvrDUIvJxMUYANxqmvkXhqrf4G9VSqAM29llux6h3718AWF5gI5h wglgMVJLV5tusBBW4dwnTOy4NBt/zrqwQmGXI8oQ
  • From Helmut Grohne@21:1/5 to M. Zhou on Wed Jan 15 14:10:01 2025
    Hi Mo,

    before going into criticizing things, I would like to thank you for your continued work in the AI space. In particular, your way of classifying
    models into different degrees of freedom demonstrates how much you care
    about Debian's values. I see that your focus is on enabling users and
    that's amazing!

    On Sun, Jan 12, 2025 at 05:01:33PM -0500, M. Zhou wrote:
    One long term goal of debian deep learning team is to host an LLM with
    the team's AMD GPUs and expose it to the members. That said, the necessary packages to run that kind of service are still missing from our archive.
    It is a good way to use existing GPUs any way.

    Disregarding the ecological and political aspects that have been
    discussed elsewhere at length, let me also note that successfully using
    a LLM is not trivial. Whether you get something useful very much depends
    on what you ask. Typically, you should expect that something between 30%
    and 70% of answers are factually wrong in some regard. As a result,
    asking questions where the answer is not verifiable is not very useful.
    Using the answers without verifying them poses a risk to us as a
    community that myths are propagated and become harder to falsify. We are talking about ai dementia already and can observe it happening. How do
    you see us mitigating this problem?

    That said, it can be useful to use a LLM if your premise is that you
    verify the answer. For instance if you are searching for a library
    function that does something particular, searching the documentation can
    be time consuming. Describing your function to a LLM and then looking up
    the documentation of the presented suggestions has a significant chance
    of turning up something useful (in addition to the rubbish included).
    Likewise, searching for a particular statement in a mailing list thread
    can be a daunting task where a LLM may be able to interpret your vague
    memory sufficiently well that it can provide a few candidates.

    This way of using LLMs is effectively limiting it to behave as a search
    engine with a different query language. I suspect that most of us use
    search engines all day without thinking much about them being driven by corporate actors running big clusters. Is using LLMs in this way that
    much different from using a search engine?

    Ecological and economical reasons aside, would anyone see an issue with providing an AI-driven search engine to Debian's documentation, mailing
    lists, bugs and the wiki?

    Even if we get no commercial sponsorship of API calls, we will eventually experiment and evaluate one with the team's infrastructure. We are still working towards that.

    I am actually looking forward to this as I trust you to do it in a
    responsible way given your earlier work.

    First, DebGPT is designed to conveniently put any particular information whether or not Debian-specific, to the context of LLM. I have also implemented
    some mapreduce algorithm to let the LLM deal with extremely overlength context such as a whole ratt buildlog directory.

    Indeed. I can imagine that a LLM may be able to also suggest particular
    lines in a build log that may hint at the cause of a failure whereas we
    now have a set of patterns (e.g. "Waiting for unfinished jobs") and hope
    that one of them locates the problem.

    My intention is always to explore possible and potential ways to make LLM useful in any possible extent. To support my idea, I wrote DebGPT, and
    I tend to only claim things that is *already implemented* and *reproducible* in DebGPT.

    I have not experimented with DebGPT yet. Maybe I should. Unless already
    done so, let me suggest that you engineer the default prompt in such a
    way that your LLM references its information sources whenever possible.
    Also including some text that asks the user to verify the answer using
    external sources may help (in an opt-out way).

    Practically speaking, the use of neural networks is not something we can
    stop even if we wanted to. In ten years, all of us will be using neural networks on a daily basis. Even today, they're difficult to avoid (e.g.
    when dealing with customer service of any corporation). The best we can
    do here is making the use of them as free as possible and that's what I
    see Mo is doing.

    Helmut

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to Kunal Mehta on Wed Jan 15 16:30:02 2025
    On Wed Jan 15, 2025 at 12:37 AM GMT, Kunal Mehta wrote:
    Agreed 100%, the openness for editing is really what makes wikis
    shine. It can be hard to accept, with many of us firmly set in Git's pre-approval style PR/MR workflows, to allow anyone with an account,
    to just change anything, but that empowerment is what makes wikis work
    and really blossom.

    Please note that git ≠ GitHub or GitLab, and the PR/MR workflows are
    just one way git is used. I can see the advantages of accessing wiki
    content with git, but I also agree with you that wikis need openness
    of editing (in fact I think that's a core principle of what makes a
    wiki, a wiki)

    The two are not incompatible (even if MR/PR-style approvals are). For
    example anyone can go and edit ikiwiki.info, either on the web or by
    cloning the git repository and pushing their commits back.

    As one of the maintainers of the MediaWiki package in Debian[1] and a wholehearted wiki enthusiast (longtime Wikipedia admin, etc.), I have
    a lot of thoughts on this that I'll save for later, but I want to
    cross-link the ongoing discussion at <https://salsa.debian.org/debian/grow-your-ideas/-/issues/2> that goes
    over a lot of the same topics.

    Thank you.


    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?@21:1/5 to All on Sun May 25 06:40:01 2025
    Hi Steve and others with interest in wiki.debian.org!

    I wanted to follow up on this thread and advertise that Steve is
    running a BoF session about the wiki future at DebConf: https://debconf25.debconf.org/talks/146-debian-wiki-bof/

    I've added some of the people who participated in https://salsa.debian.org/debian/grow-your-ideas/-/issues/2 and who's
    email address I have easily available as CC here, and I've posted a
    note about this BoF in that issue. I have also added some research
    about potential Markdown+git software in https://salsa.debian.org/debian/grow-your-ideas/-/issues/2#note_288815.

    Maybe you Steve could invite people to the BoF in advance to ensure
    there is good attendance at least by the people who have publicly
    committed they would be willing to work on upgrading/migrating the
    wiki?

    I probably won't have bandwidth to help with the software part, but
    feel free to add me as co-organizer in the BoF if you want further
    help with the BoF session itself.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to All on Tue May 27 10:40:02 2025
    On Sun May 25, 2025 at 5:37 AM BST, Otto Kekäläinen wrote:
    Hi Steve and others with interest in wiki.debian.org!

    Thanks for the ping. I was aware there's going to be a BoF, and
    (schedule permitting) I hope to attend (virtually).

    I've added some of the people who participated in https://salsa.debian.org/debian/grow-your-ideas/-/issues/2 and who's
    email address I have easily available as CC here, and I've posted a
    note about this BoF in that issue. I have also added some research
    about potential Markdown+git software in https://salsa.debian.org/debian/grow-your-ideas/-/issues/2#note_288815.

    I think this is worthy of discussion, but I hope it doesn't dominate the
    whole BoF: there's only 45 minutes, and several other wiki topics to
    cover.


    Best wishes,

    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lucas Nussbaum@21:1/5 to All on Wed Jun 4 17:10:01 2025
    Hi,

    On 11/01/25 at 19:13 -0800, Otto Kekäläinen wrote:
    ...
    Debian should consider allocating some budget like several hundred USD
    per month for the LLM API calls for all members and new-comers' usage.

    I don't think Debian should as an organization pay for LLMs. On the
    contrary I would expect LLM providers to offer API keys for free to
    Debian Developers just like we have other perks listed at https://wiki.debian.org/MemberBenefits.

    Considering how much the LLMs have utilized open source software when building and training them, it would actually make a lot of sense for
    those companies to step up and partner with Debian just like many web
    hosting companies have, as they all likewise have built their
    businesses on top of open source software. Currently, I don't see any
    AI companies at https://www.debian.org/partners/.

    If anyone has contacts at OpenAI, Anthropic, xAI, DeepSeek, 01 AI,
    Zhipu AI, Meta, Mistral, Nexus, Alibaba, AI21 Labs, Cohere etc, please
    tell them about the opportunity to sponsor Debian :)

    Did something happen about this?

    I saw that OpenAI released Codex CLI[0] (an alternative to Claude Code). Quoting the README:
    Codex CLI is built for developers who already live in the terminal and
    want ChatGPT-level reasoning plus the power to actually run code,
    manipulate files, and iterate - all under version control. In short,
    it's chat-driven development that understands and executes your repo.
    * Zero setup - bring your OpenAI API key and it just works! Full
    * auto-approval, while safe + secure by running network-disabled and
    * directory-sandboxed Multimodal - pass in screenshots or diagrams to
    implement features ✨
    And it's fully open-source so you can see and contribute to how it
    develops!

    (Of course, the "open source" part applies to the client app, not to the
    model)

    OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant
    so that Debian contributors could get hands-on experience on how this
    could help their Debian activities?

    I'm willing to handle the paperwork and apply on behalf on Debian (and
    then handle giving access to DDs), but of course this would need DPL
    approval (Cced).

    [0] https://github.com/openai/codex
    [1] https://openai.com/form/codex-open-source-fund/

    Lucas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From M. Zhou@21:1/5 to Lucas Nussbaum on Thu Jun 5 04:00:01 2025
    This is a multi-part message in MIME format.
    Please roll me (and potentially debian-ai@lists.debian.org) in the CC list.

    On 6/4/25 11:04 AM, Lucas Nussbaum wrote:
    (Of course, the "open source" part applies to the client app, not to the model)

    OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant
    so that Debian contributors could get hands-on experience on how this
    could help their Debian activities?

    I'm willing to handle the paperwork and apply on behalf on Debian (and
    then handle giving access to DDs), but of course this would need DPL
    approval (Cced).

    [0]https://github.com/openai/codex [1]https://openai.com/form/codex-open-source-fund/

    Lucas

    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p><font face="monospace">Please roll me (and potentially
    <a class="moz-txt-link-abbreviated" href="mailto:debian-ai@lists.debian.org">debian-ai@lists.debian.org</a>) in the CC list.</font></p>
    <div class="moz-cite-prefix">On 6/4/25 11:04 AM, Lucas Nussbaum
    wrote:<span style="white-space: pre-wrap">
    </span></div>
    <blockquote type="cite" cite="mid:aEBggpb5oRsCotyH@grub.nussbaum.fr">
    <pre wrap="" class="moz-quote-pre">(Of course, the "open source" part applies to the client app, not to the
    model)

    OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant
    so that Debian contributors could get hands-on experience on how this
    could help their Debian activities?

    I'm willing to handle the paperwork and apply on behalf on Debian (and
    then handle giving access to DDs), but of course this would need DPL
    approval (Cced).

    [0] <a class="moz-txt-link-freetext" href="https://github.com/openai/codex">https://github.com/openai/codex</a>
    [1] <a class="moz-txt-link-freetext" href="https://openai.com/form/codex-open-source-fund/">https://openai.com/form/codex-open-source-fund/</a>

    Lucas

    </pre>
    </blockquote>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Holger Levsen@21:1/5 to Lucas Nussbaum on Thu Jun 5 13:40:01 2025
    On Wed, Jun 04, 2025 at 05:04:34PM +0200, Lucas Nussbaum wrote:
    OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant
    so that Debian contributors could get hands-on experience on how this
    could help their Debian activities?

    or maybe Debian should not.


    --
    cheers,
    Holger

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
    ⠈⠳⣄

    Die meisten Menschen können sich eher das Aussterben der Menschheit vorstellen als das Ende von Herrschaftsideologie und Kapitalismus. (@elektra_42)

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmhBgckACgkQCRq4Vgaa qhzSDxAAuf9cqhmv1IbhDKP72FEhGHRnZJd9pTIuq1Q3r65PV3dEqJe6lzWp4YUs 5ZcmfA4NK58pTEhXnDEXz7t0ACyUiZvmpWU7LsZBiqDR2u6YwfqmBUdtEvPJzm8k /5w6AjR1Q+T+mZYv9qgVxb1wqPuIy1RDNKQ/3GnpPTHfXi9rMGVXc5d2sYeE6My7 6kFvX3jERObzPf9F7uOKv8rISxlYhXRSrAS54IxroItsPtl+HBob4taLr43TuEM8 52wISc/8+RSvXFG2hxk90AyfKmMsSoKcbxeuGmHkYl1oPOL9JLeCiOoLSQrFmCrR ByRCSLQ123LaOavAPiN8eEmPPJ4ApiBP/NcfHTUxMikU9+1QOxK94xeocYtl8nNZ d/OWYOnp12EqKGX0iR5cueTpq6ni63CyWhD3vyx8RK+5mDbaZTfs/s7UXmrB8+S+ hqB9djF5yQj/jCUCus3nsoOWmas2i8TVQLc5tgvbzRB4iHB3aMZiMq2YE/s/oXRn uCMfe2WAx308TTZwPN1K51+J8bAn
  • From Lucas Nussbaum@21:1/5 to Holger Levsen on Fri Jun 6 12:10:02 2025
    On 05/06/25 at 11:38 +0000, Holger Levsen wrote:
    On Wed, Jun 04, 2025 at 05:04:34PM +0200, Lucas Nussbaum wrote:
    OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant
    so that Debian contributors could get hands-on experience on how this
    could help their Debian activities?

    or maybe Debian should not.

    Maybe. Honestly, I don't know.

    Based on my limited experiments on this (everyone, feel free to correct
    me), in the specific context of AI-assisted Debian development, the
    question is threefold. As a Debian contributor, you would needed:

    (A) an "agent", that is the client software running on your machine that
    you talk with, and that interacts with your codebase (read files, make
    changes to files, run commands, create git commits, etc.). Ideally in
    some kind of sandbox and/or with permissions management.
    Examples include 'Claude Code' (works in CLI, proprietary, interacts
    only with Anthropic models), Cursor(.com) (VS Code fork, proprietary,
    interacts with either Claude* (Anthropic) or Gemini* (Google)), Codex
    CLI (free software, developed by OpenAI and focused on their models, but supposed to work with other providers). DebGPT fits here too (but is
    less advanced for coding tasks than Claude Code or Cursor).

    (B) a way to query models:
    - either subscription-based from commercial services such as OpenAI,
    Anthropic, Gemini, ... or brokers like OpenRouter.
    - or using "open" models that you can download and run yourself,
    typically with ollama (free software)

    (C) good matching between (A) and (B): it helps if the client side (A)
    knows how to tune to queries ("prompt engineering") for the specific provider/model in use (B). Typically, in my tests, trying to use Codex
    CLI with ollama fails there (or I could not find a model that produced reasonable results). (Also the OpenAI API has variants that are not
    supported by all models ("tools support").)


    As Debian, we should probably care if (A) is free software, and
    ultimately package those in Debian. Currently the ecosystem is not quite
    there yet, but that doesn't sound like a super-hard problem (there are
    attempts at free alternatives and no real blocker). Those could go in
    Debian main: it's not very different from packaging an OpenAI API client (python-openai) or a GitHub client.

    For Debian, the real question is about (B). Should we just accept that
    the best services are the commercial ones currently, and if they can
    help us make Debian better, embrace them? After all, we:
    - use commercial CDNs to distribute packages
    - rely on cloud providers for hosting various services
    - fix issues detect by tools that are not free software
    (I don't have an answer for that question, but I think that it's useful
    for us to investigate how AI-assisted coding could help us)


    Note that I don't buy the 'AI produces crap anyway' argument: after experimenting with Claude Code and Cursor, I'm fully convinced that they
    can help with some of the tasks involved in Debian development (and
    their ability to help us will probably only increase over time).

    Also, I don't think that the question is "should we trust AI-generated
    code" at this point (and if it was asked at this point, the answer
    should be a clear "no" in our context). We should continue to require
    that contributions are linked to a developer who made reasonable
    efforts to ensure that no errors were made, and are able to act
    responsibly if that fails somehow.

    Lucas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ansgar =?UTF-8?Q?=F0=9F=99=80?=@21:1/5 to Holger Levsen on Fri Jun 6 12:50:01 2025
    Hi,

    On Fri, 2025-06-06 at 10:33 +0000, Holger Levsen wrote:
    On Fri, Jun 06, 2025 at 12:03:32PM +0200, Lucas Nussbaum wrote:
    or maybe Debian should not.
    Maybe. Honestly, I don't know.
     
    I'd rather not take their offer based on moral grounds: they stole
    and
    steal from everyone and want to make that normal. And for that, they
    offer some breadcrumbs to the people they stole from.

    The four freedoms of the FSF explicitly include "the freedom to study
    the source code [and make changes]". Presumably this is not limited to
    specific use cases just like the freedom to run the program as you
    wish.

    Also they contribute massivly to burning down our only planet faster.

    So do in-person conferences, rebuilding software just to observe that
    no changes happen, crypto currencies, blockchains and lots of other
    things. Arguably some of these things might have less value than LLMs.

    Ansgar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ansgar =?UTF-8?Q?=F0=9F=99=80?=@21:1/5 to Holger Levsen on Fri Jun 6 13:10:01 2025
    Hi,

    On Fri, 2025-06-06 at 10:51 +0000, Holger Levsen wrote:
    On Fri, Jun 06, 2025 at 12:48:11PM +0200, Ansgar 🙀 wrote:
    Also they contribute massivly to burning down our only planet
    faster.
    So do in-person conferences, rebuilding software just to observe
    that
    no changes happen,

    horseshit. those things dont require dozens of entire powerplants...

    Smelly bullshit. Just because planes don't fly with electric power,
    they still require energy. And data processing already required
    multiple powerplants before LLMs came along.

    Ansgar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Holger Levsen@21:1/5 to Lucas Nussbaum on Fri Jun 6 12:40:01 2025
    On Fri, Jun 06, 2025 at 12:03:32PM +0200, Lucas Nussbaum wrote:
    or maybe Debian should not.
    Maybe. Honestly, I don't know.

    I'd rather not take their offer based on moral grounds: they stole and
    steal from everyone and want to make that normal. And for that, they
    offer some breadcrumbs to the people they stole from.

    Also they contribute massivly to burning down our only planet faster.


    --
    cheers,
    Holger

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
    ⠈⠳⣄

    We are not moving into a 1.5C world, we are briefly passing through it in 2024. (James Hansen)

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmhCw98ACgkQCRq4Vgaa qhwclBAAu14RnHmdwPLbiXszl4dkeP40wX15Etu4ti3mw1VwdwEv8KkTkJJ/3IGF dQSHDpSlotonc7fFkALSWXVTnnUnIVFZ9GyPP869dap9ZP9Mh9VZq18e0r+V/U5W y5PToSvC9x74I2400MRpAnyHfUP0HwAzKBRBjN1EWHDfw34EEXx7wffj9r4BKwhG fBIgkr4/h45NGkgi63L2tlKXPM9vncUbeATCgYl+vPJvRKDkHfProjpnxRZ6s951 lHrLnsv1bJhFF+NqVXC7W73DX12NijhmcyVBNgBvJ4gscG9yptavGHFoPg0oALwC 6yf8990nSxMWCwKnkJGpJyUmIMd5qU36vwOLF5M2Frs2En7VzaUfX9JBHVa4y/Qj O8gYXOy0AyqcNsnLu+qzVTsJ5f2FgE+B/z9XZHpAHs1ZhQpMbdndhgu6EQXb0DaU T1PejMzebz2+lUCtqfjkqZbZSjeqoQ3TS2sXZ99msfqf1bKhu4AFzfdLrU4n9UGv NDVM6dlz2qp42NYBKz8zvRxKfXLZR/8XYozUVkmJr9yi4s7tPCAs25CooWzFcDVD te6ak+lNfsWUaHYZK
  • From Holger Levsen@21:1/5 to All on Fri Jun 6 13:00:01 2025
    On Fri, Jun 06, 2025 at 12:48:11PM +0200, Ansgar 🙀 wrote:
    Also they contribute massivly to burning down our only planet faster.
    So do in-person conferences, rebuilding software just to observe that
    no changes happen,

    horseshit. those things dont require dozens of entire powerplants...


    --
    cheers,
    Holger

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
    ⠈⠳⣄

    The purpose of propaganda isn't to make you believe something. It's to make you believe nothing. So that you do nothing. (@DarthPutinKGB)

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmhCyEQACgkQCRq4Vgaa qhxIXw//ezjugM+0Vz+RRff/82wb0KQXorbefZO4QsVF9TETHXZonCBeU25b5uP8 rIPXmZUuSMa2NUKhbguzspcDLuoSJnff44zLprP2C65aq8rGKh9n8IejGi+yGvcx 8O/rRvjs4xCmJUrEoVhjz1bT2Ul9kFQdi1ajiNZLc92jpNDkXq/r1QkotDWBhp75 tAnulfz8CV204te3hk37anIlVesjRlicotwSJI37Ks2eyTA5/DZdTTa1UNE/RNtJ 22Vf4t+Ut7+ez8fs6mWLl3kkqKHmfIbmds3hiDkkTioKvGZsBPKrtV/Q66xzw9Vp jPNhQXNWlB08G7VAhJ15JMmfyRR+3MtYV6P3qVS1xKK9cFRDo7R5CgDpxy+fVwfy yEwEo1IkN/c43xmRnkHM0vft/wKDAx+46XxfEi2K47D0iaBpqf5+mkSngdZzCIli LSP9Es+TPzhshQISbo7KtNUKURFMlAguptbKVRfgnol6VoQf4fpQQos8qcVfqBxd T54Olgi4pDfcopzvZWrrbAUA66irqMO4oFHTNz1C
  • From =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?@21:1/5 to All on Wed Jun 11 21:20:01 2025
    Hi!

    OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant so that Debian contributors could get hands-on experience on how this could help their Debian activities?

    or maybe Debian should not.

    Maybe. Honestly, I don't know.

    I still think it would be a nice perk for DDs, along the other perks
    listed at https://wiki.debian.org/MemberBenefits

    It is up to each DD to decide how to use the tools and services.
    Personally I don't recommend using them to generate code as in the
    Debian context they seem to output so much bad results, but using
    LLM's for example to review code seems to be working pretty well and
    is faster and cheaper than waiting for humans to review (and humans
    can still review, they will just seem more polished stuff).

    ...
    (A) an "agent", that is the client software running on your machine that
    you talk with, and that interacts with your codebase (read files, make changes to files, run commands, create git commits, etc.). Ideally in
    some kind of sandbox and/or with permissions management.
    Examples include 'Claude Code' (works in CLI, proprietary, interacts
    only with Anthropic models), Cursor(.com) (VS Code fork, proprietary, interacts with either Claude* (Anthropic) or Gemini* (Google)), Codex
    CLI (free software, developed by OpenAI and focused on their models, but supposed to work with other providers). DebGPT fits here too (but is
    less advanced for coding tasks than Claude Code or Cursor).

    All of the above are closed-source solutions. I have been playing
    around with the fully open https://aider.chat/ for well over a year
    and I would recommend it instead. I hope to some day write a blog post
    about how I run it inside a container safely and how I have customized
    it to give better results than what it does out-of-the-box.

    (B) a way to query models:
    - either subscription-based from commercial services such as OpenAI,
    Anthropic, Gemini, ... or brokers like OpenRouter.
    - or using "open" models that you can download and run yourself,
    typically with ollama (free software)

    I am a big fan of OpenRouter.ai, but they are just a router. I would
    like to see the actual model trainers contribute back to open source
    by issuing free API usage to Debian Developers etc. If you have time,
    please reach out to the three companies you mentioned. I had hoped
    that the Debian Machine Learning team had direct contacts to these
    companies, but apparently not.

    (C) good matching between (A) and (B): it helps if the client side (A)
    knows how to tune to queries ("prompt engineering") for the specific provider/model in use (B). Typically, in my tests, trying to use Codex
    CLI with ollama fails there (or I could not find a model that produced reasonable results). (Also the OpenAI API has variants that are not
    supported by all models ("tools support").)

    I usually look at these leaderboards to see what currently yields the
    best results with specific models and tools combined:

    https://aider.chat/docs/leaderboards/
    https://openrouter.ai/rankings

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)