Re: A policy on use of AI-generated content in Debian
On 5/3/24 12:10, Stefano Zacchiroli wrote: On that front, useful "related work" are the policies that scientific journals and conferences (which are exposed *a lot* to this, given their main activity is vetting textual documents) have put in place about this. Indeed. Here are some examples: Nature: https://www.nature.com/nature-portfolio/editorial-policies/ai ICML: https://icml.cc/Conferences/2023/llm-policy CVPR: https://cvpr.thecvf.com/Conferences/2024/ReviewerGuidelines https://cvpr.thecvf.com/Conferences/2024/AuthorGuidelines Some additional points to the two from Stefano: 1. Nature does not allow LLM to be an author. 2. CVPR holds the author who used LLM responsible for all LLM's fault. 3. CVPR agrees that the paper reviewers skipping their work with LLM is harming the community. The general policy usually contains two main points (paraphrased below): (1) You are free to use AI tools to *improve* your content, but not to create it from scratch for you. Polishing language is the case where I find LLMs most useful. But in fact, as an author, when I really care about the quality of whatever I wrote, I will find the state-of-the-art LLMs (such as ChatGPT4) poor in logic, poor in understanding my deep insight. They eventually turn into a smart language tutor to me. (2) You need to disclose the fact you have used AI tools, and how you have used them. Yes, It is commonly encouraged to acknowledge the use of AI tools. Exactly as in your case, Tiago, people managing scientific journals and conferences have absolutely no way of checking if these rules are respected or not. (They have access to large-scale plagiarism detection tools, which is a related but different concern.) They just ask people to *state* they followed this policy upon submission, but that's it. If the cheater who use LLM is lazy enough, not editing the LLM outputs at all --- you will find it super easy to identify whether a chunk of text is produced by LLM on your own. For example, I use ChatGPT basically everyday in March, and its answers always feel like being organized in the same format. No human answers questions in the same boring format all the time. If your main concern is people using LLMs or the like in some of the processes you mention, a checkbox requiring such a statement upon submission might go a longer way than a project-wide statement (which will sit in d-d-a unknown to n-m applicants a few years from now). For the long run, there is no way to enforce a ban on the use of AI over this project. What is doable, from my point of view, is to confirm that a person acknowledges the issues, potential risk and implications of the use of AI tools, and hold people who use AI to be responsible for AI's fault. Afterall, it's easy to identify one's intention of using AI -- it is either for good or bad. If the NM applicants can easily get the answer of an NM question, maybe it is time to refresh the question? Afterall nobody can stop one from learning from AI outputs when they need suggestion or reference answers -- and they are responsible for the wrong answer if AI is wrong. Apart from deliberately conducting bad acts using AIs, one thing that seems benign but harmful to the community is slacking off and skipping important work with AIs. But still, this can be covered by a single rule as well -- "Let the person who use AI to be responsible for AI's fault." Simple, and doable.
Re: A policy on use of AI-generated content in Debian
On 5/2/24 14:01, Tiago Bortoletto Vaz wrote: You might already know that recently Gentoo made a strong move in this context and drafted their AI policy: - https://wiki.gentoo.org/wiki/Project:Council/AI_policy - https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg99042.html People might not already know I wrote this 4 years ago https://salsa.debian.org/deeplearning-team/ml-policy/-/blob/master/ML-Policy.rst
Re: A policy on use of AI-generated content in Debian
On 5/2/24 14:47, Dominik George wrote: That's entirely not the point. It is not about **the tool** being non-free, but the result of its use being non-free. Generative AI tools **produce** derivatives of other people's copyrighted works. Yes. That includes the case where LLMs generates copyrighted contents with large portions of overlap. For instance, https://www.nytimes.com/2023/12/27/business/media/new-york-times-open-ai-microsoft-lawsuit.html because those copyrighted contents are a part of their original training dataset. Apart from the LLMs (large language models), the image generation models and other generative AIs will also do something similar, partly copying their copyrighted training data to the generated results, to some extent. That said, we already have the necessary policies in place: * d/copyright must be accurate * all sources must be reproducible from their preferred form of modification Both are not possible using generative AI. Both are possible. For example, if a developer uses LLM to aid programming, and the LLM copied some code from a copyrighted source. But the developer is very unlikely able to tell whether the generated code contains verbatim copy of copyrighted contents, lest the source of that copyrighted parts if any. Namely, if we look at new software projects, we do not know whether the code files are purely human-written, or with some aid from AI. Similar things happens with other file types, such as images. For instance, you may ask a generative AI to generate a logo, or some artworks as a part of a software project. And those generated results, with or without further modifications, can be stored in .ico, .jpg, and .png formats, etc. Now, the problem is, FTP masters will not question the reproducibility of a code file, or a .png file. If the upstream author does not acknowledge the use of AI during the development process, it is highly likely that nobody else on the earth will know that. This does not sound like a situation where we can take any action to improve. My only opinion towards this is to trust the upstream authors' acknowledgements. BTW, ML-Policy has foreseen such issue and covered it to some extent: https://salsa.debian.org/deeplearning-team/ml-policy/-/blob/master/ML-Policy.rst See the "Generated Artifacts" section. It seems that the draft Open Source AI Definition does not cover contents generated by AI models yet: https://discuss.opensource.org/t/draft-v-0-0-8-of-the-open-source-ai-definition-is-available-for-comments/315
Re: Aw: Re: Community renewal and project obsolescence
On 12/30/23 21:40, Mo Zhou wrote: I am not able to develop DebGPT and confess I am not investing my time in learning to do it. But can we attract the people who want to tinker in this direction? Debian funds should be able to cover the hardware requirement and training expenses even if they are slightly expensive. The more expensive thing is the time of domain experts. I can train such a model but clearly I do not have bandwidth for that. No. I changed my mind. I can actually quickly wrap some debian-specific prompts with an existing chatting LLM. This is easy and does not need expensive hardware (although it may still require 1~2 GPUs with 24GB memory for inference), nor any training procedure. The project repo is created here https://salsa.debian.org/deeplearning-team/debgpt I have enabled issues. And maybe people interested in this can redirect the detailed discussions to the repo issues. I'm sure it is already possible to let LLM read the long policy document, or debhelper man pages for us, and provide some suggestions or patches. The things I'm uncertain is (1) how well a smaller LLM, like 7B or 13B ones can do compared to proprietary LLMs in this case; (2) how well a smaller LLM can be when it is quantized to int8 or even int4 for laptops. Oh, BTW, the dependencies needed by the project are not complete in debian archive.
Re: Aw: Re: Community renewal and project obsolescence
On 12/30/23 15:06, Charles Plessy wrote: Le Fri, Dec 29, 2023 at 01:14:29PM +0100, Steffen Möller a écrit : What hypothese do we have on what influences the number of active individuals? When I was a kid I was playing with a lot of pirate copy of Amiga and then PC games, and I had a bit of melancholy thinking that what appeared to be golden days took place when I was still busy learning to walk and speak. I wondered if I was born too late. Then I was introduced to Linux and Debian. If you don't mind to share more of your story -- how are you introduced to Linux and Debian? Can we reproduce it? For me this is not reproducible. The beginning of my story is similar to yours. Differently, at that time Windows is the only PC operating system I'm aware of. And I suffered a lot from it and its ecosystem: aggressive reboots, aggressive pop-up windows and ads completely out of my control, enormous difficulty to learn and understand its internals given very limited budget for books, enormous difficulty to learn C programming language based on it. Visual studio did a great job to confuse me with a huge amount of irrelevant details and complicated user interface when I want try the code from the K C book as a newbie (without any educational resource available or affordable). I forgot why I chose this book but it was a correct one to buy. One day, out of curiosity I searched for "free of charge operating systems" so that I can get rid of Windows. Then I got Ubuntu 11.10. Its frequent "internal errors" drove me to try other linux distros in virtualbox, including Debian squeeze and Fedora. While squeeze is the ugliest among them all in terms of desktop environment, it crashes significantly less than the rest. I was happy with my choice. Linux does not reboot unless I decide to do so. It does not pop-up ads because the malwares (while being useful) are not available under linux. It does not prevent me from trying to understand how it works, even if I can hardly grasp the source code. And, `gcc hello-world.c` is ridiculously easy for learning programming compared to using visual studio. I was confused again -- why is all of those free of charge? I tried to learn more until the Debian Social Contract, DFSG and the stuff wrote by FSF (mostly Stallman) completely blown up my mind. With the source code within my reach, I'm able to really tame my computer. The day I realized that is the day when I added "becoming a DD" to my dream list. That was a big thing, a big challenge for me to learn it, and a big reward to be part of it. At that time I never imagined that the next big thing was diversity, inclusion and justice, but being part of Debian unexpectedly connected me to it. Now when I look back I do not worry being born too late. I would like to say to young people that joining a thriving community is the best way to journey beyond one's imagination. Ideally yes, but people's mind is also affected by economy. In developing countries where most people are still struggling to survive and feeding a family, unpaid volunteer work is respected in most of the time, but seldom well-understood. One needs to build up a very strong motivation before taking actions to override the barrier of societal bias. That's partly the one of the reasons why the number of Chinese DDs is so scarce while China has a very large number of population. And in contrast, most DDs are from developed countries. I like the interpretations on how human society works from the book "Sapiens: a brief history of humankind". Basically, what connects people all over the world, forming this community is a commonly believed simple story -- we want to build a free and universal operating system. (I'm sad to see this sentence being removed from debian.org) The common belief is the ground on which we build trust and start collaboration. So, essentially, renewing the community is to spread the simply story, to the young people who seek for something that Debian/FOSS can provide. I don't know how to achieve it. But I do know that my story is completely unreproducible. Of course, we need to show how we are thriving. On my wishlist for 2024, there is of course AI. In case people interested in this topic does not know we have a dedicated ML for that: https://lists.debian.org/debian-ai/ The key word GPT successfully toggled my "write-a-long-response" button. Here we go. Can we have a DebGPT that will allow us to interact with our mailing list archives using natural language? I've ever tried to ask ChatGPT about Debian related questions. While ChatGPT is very good at general linux questions, it turns that its training data does not contain much about Debian-specific knowledge. The quality of training data really matters for LLM's performance, especially the amount of book-quality data. The Debian ML is too noisy compared to wikipedia dump and books. While the training set of the
Re: Community renewal and project obsolescence
On 12/28/23 10:34, Rafael Laboissière wrote:
* M. Zhou [2023-12-27 19:00]:
Thanks for the code and the figure. Indeed, the trend is confirmed by
fitting a linear model count ~ year to the new members list. The
coefficient is -1.39 member/year, which is significantly different
from zero (F[1,22] = 11.8, p < 0.01). Even when we take out the data
from year 2001, that could be interpreted as an outlier, the trend is
still siginificant, with a drop of 0.98 member/year (F[1,21] = 8.48, p
< 0.01).
I thought about to use some models for population statistics, so we can
get the data about DD birth rate and DD retire/leave rate, as well as a
prediction. But since the descendants of DDs are not naturally new DDs,
the typical population models are not likely going to work well. The
birth of DD is more likely mutation, sort of.
Anyway, we do not need sophisticated math models to draw the conclusion
that Debian is an aging community. And yet, we don't seem to have a good
way to reshape the curve using Debian's funds. -- this is one of the key
problems behind the data.
P.S.1: The correct way to do the analysis above is by using a
generalized linear model, with the count data from a Poisson
distribution (or, perhaps, by considering overdispersed data). I will
eventually add this to my code in Git.
Why not integrate them into nm.debian.org when they are ready?
P.S.2: In your Python code, it is possible to get the data frame
directly from the web page, without copying Just replace the
line:
df = pd.read_csv('members.csv', sep='\t')
by:
df = pd.read_html("https://nm.debian.org/members/;)[0]
I am wondering whether ChatGPT could have figured this out…
I just specified the CSV input format based on what I have copied. It
produces well-formatted code with detailed documentation in most of the
time. I deleted too much from its outputs to keep the snippet short.
I have to justify one thing to avoid giving you a wrong impression about
large language models. In fact, the performance of an LLM (such as
ChatGPT) greatly varies based on the prompt and the context people
provided to it. Exploring this in-context learning capability is still
one of the cutting edge research topics. For the status-quo LLMs, their
answers on boilerplate code like plotting (matplotlib) and simple
statistics (pandas) are terribly perfect.
Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer
Hi Sam,
Even if I said I'll no longer participate, there are some
substantial misunderstandings to correct.
On Tue, May 26, 2020 at 04:44:49PM -0400, Sam Hartman wrote:
> I think you and Mo are a bit stuck in the ftp-team mindset with the
> above. *whenever new or bin-new is triggered, all files are reviewed.*
It's designed for people who "review all the files" when the package
turns to be NEW. For example, one who is about to upload a NEW package.
This aims to speed up a **rigorous** review, instead of a much less
rigorous review. Generally reviewing things quickly and carelessly makes
the life of every uploader much easier -- but that means more burden for
our last shield, ftp team.
Again, the specification talks about how the status of files are changed
in the status space {"N/A", "outdated", "ACCEPT", "REJECT"}, which is a
pure interpretation of the modeling of the process, and it did not say
any preference on political stuff such as "when the review should be
triggered" -- I have no intention to talk about it. My specification is
invariant to the review whatever frequency people prefer. If people
prefer to do the review after every git commit, libawsl can be useful.
If people prefer to slack off and only do the review when the package
has to go through the new queue again, libawsl can also be useful.
> But to an outsider, what it sounds like Mo is proposing is that whenever
> the salt is changed, review needs to be triggered, even if new would not
> be triggered in the current model.
Talking about how the file status move in the status space
{"N/A", "outdated", "ACCEPT", "REJECT"}
does not imply any preference on the frequence of review.
Why not take git as an example?
"N/A": the user didn't git add
"outdated": has been changed, stage and commit it when user
sees appropriate.
"accept": has not been changed, nothing to do
"reject": ? no analogous concept, but it does not matter.
When did git urge people to stage files, do commits, or push when it
gets unhappy about the modified files and unsynced tree status? Is the
git efficiency seriously impacted by "how frequent the user does
commits", "how frequent the user does commits"?
Similarly, when did libawsl urge people to do the review once the file
status has been changed?
> My thoughts are that
> 1) I think it's worth being clear that you're not proposing increasing
> the rounds of new review.
No. libawsl is independent and ignorant to the review frequency. It is
designed to **help human** when they need to do a review, not designed
to **prod or force people** to do review once it gets unhappy.
> 2) Long term, having a persistent database of review state might allow
> us to have better criteria for when to trigger license review.
libawsl can use a persistent database to reduce redundant reviews, as
long as the salthash do match. There is no design consideration on given
answers to questions such as "when to trigger a review". Whatever the
review frequency is, libawsl is invariant and will do its job.
> --Sam
signature.asc
Description: PGP signature
Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer
Some people are interested in a demonstration program. But sorry, to make it clear, I confirm that this is merely a theoretical proposal, and I'm at no liberty and in no position to write the demo program. I have run out of my motivation to go any further, since I have already done what I'm willing to do. I understand that doing nothing is the most comfortable choice for a human being, but that does not prevent me from thinking constructively. Though, I quickly found that the negative feelings against the theory overweighs the positive ones. Anyway, as a cheap theoretical discussion (talk is cheap), it should not impose pressure and unhappiness on anyone. I shall call it the end of my participation in this thread. I didn't violate the code of conduct, and I'm not going to find trouble for anyone. On Sat, May 23, 2020 at 12:46:45PM +, Mo Zhou wrote: > This thread is for non-technical discussions. If it turns out that the > community can reach some common agreement, we can move to the technical > (implementation) discussions on -devel.
libAWSL: Improving Human Efficiency for debian/copyright Reviewer
Hi Debian Project, (Human Efficiency Problem is non-technical) As we know, the human efficiency in the debian/copyright reviewing process can be optimized, reducing the development cost of the community. However, the possibilities of performing that kind of optimization are left uncharted. I'm hereby presenting my "libAWSL" specification, aiming to shed some light on the software/workflow designing issues on improving human efficiency while doing the reviewing work on `debian/copyright`: https://salsa.debian.org/lumin/awsl/-/blob/master/specification.md Exhaustive details can be found in the above link. In the following part of this mail I'm presenting some of the key points in my specification. Note, I'm trying to do some THEORETICAL discussion on the possibility to improve human efficiency, INSTEAD OF proposing to enforce anything. Proposed Principles in Human-Understandable Language * The reviewer does not have to review the IDENTICAL file more than once. * The time complexity for going through a package should be less or equal to O(num-of-files). Explanations can be found at: https://salsa.debian.org/lumin/awsl/-/blob/master/specification.md How Can We Benifit from LibAWSL in Practice --- * Instant acceptance for source packages with merely binary package rename (without change in upstream code) * More verbose and structured feedback from ftp team * Accumulation of precious educational resources, and reducing training cost for ftp-trainees * Convenient new-upstream-release checks for maintainers and reviewers * Making the reviewing process interruptable * Possibility for open/collaborated reviewing workflow Explanations can be found at: https://salsa.debian.org/lumin/awsl/-/blob/master/specification.md --- This thread is for non-technical discussions. If it turns out that the community can reach some common agreement, we can move to the technical (implementation) discussions on -devel. Mo, For sake of a more efficient Debian Community. signature.asc Description: PGP signature
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Sat, Dec 28, 2019 at 02:13:55PM -0800, Russ Allbery wrote: > If we're only doing this for secondary > reasons like legal liability, it might be worth looking around and seeing > if other organizations with similar legal risks take the same precautions, > or asking for legal advice on whether this precaution is legally necessary > or if we're creating work for ourselves that exceeds the legal risk we'd > be accepting by doing something more automatable. Don't know what Red Hat family does, but at least Archlinux and Gentoo treat the license checking problem in a very permissive way. However, Debian is sometimes an important reference to these friend distros when they encountered some problems about license. > To be clear, it may be that we'll ask this question and decide that yes, > detailed license review is something we consider important and we want to > keep doing it the way that we have been doing it, and we need to figure > out how to make that work scale. Making that process scalable seemed like a workflow change, which often takes centuries to enforce in this community. Even if that process can be scaled to a larger group of workers, without proper tool every worker node will still work in low efficiency (and still easily get mentally bored). Assuming "license reviewing is inevitable to Debian", someone must manually check the debian/copyright file. In Chinese there is an old saying "工欲善其事，必先利其器", which means "one who wants to get the work done has to sharpen their tools first" (note, not a standard translation). So, trying to design a human-oriented tool for more efficient license review should be worth consideration, at least. That's what my thread on -devel is trying to do.
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Sat, Dec 28, 2019 at 09:58:57AM +, Sean Whitton wrote: > Not sure why I'm being mentioned here; Just a guess. Nevermind.
Re: Do we still value contributions?
On Thu, Dec 26, 2019 at 02:59:25PM +0100, Bernd Zeimetz wrote: > > So in my opinion the option we should implement is a (mostly) automated > license check. There are various tools listed on the wiki page, but > there are also commercial tools out there which do that task. Although I > know it will sounds completely wrong in the ears of some of readers > here, I think asking one of the companies if they'd sponsor their tools > to examine the new queue sounds like a very good idea to me, if it helps > the ftp team to be faster. At the same time we'll get hints to license > violations from our upstreams... Very long time ago I had a bold idea to formularize the license checking, a somewhat repetitive process into a machine learning problem. However, experience indicates that there are an amount of special cases hard to be modeled in a math system. Plus, the NEW reviewing process is not falt-tolerant, which definitely further increased the difficulty to automate ftp-master's work with "artificial intelligence". As a trainee, I ended up browsing every single file manually.
possibly exhausted ftp-masters (Re: Do we still value contributions?
Hi, Some personal opinions as one of the current batch of FTP trainees. * The ftp team might be in a (somewhat) negative loop from the sustainable development aspect. Let's first list a couple of facts: (0) There are a small group of DDs working as ftp-master. Their time and energy are limited. (1) ftp-master is doing hard work, reviewing NEW packages, processing RM bugs, maintaining dak, and recruiting new members to expand the team. All of these are not trivial things. (0)+(1) means that: the time that FTP spend on recruiting is quite limited. Then how "limited" is it? + I seriously explained about the slow NEW queue process 2 years ago. + I joined the ftp team as trainee about 1 year ago, after 6 months since sending out the application mail. + the preliminary assessment of the current batch of trainee is still not available. ^ My (possibly biased) experience shows that the recruitment process is quite slow. What concerns me most is, what if the FTP team's "quit rate" gets larger than "expansion rate"? You know what it means from a long-term perspective. --- However, accelerating the recruitment process of ftp team looks quite difficult to all participants, including the ftp-masters and the trainees: ftp-master: * time and energy is limited. doesn't have enough resource to provide too much feedbacks to the trainee * wants to make sure every new member will be qualified enough to take this important role. trainee: * limited time and energy. generally not able to produce a large amount of reviews to the NEW packages in a short period of time * lacks feed back. they don't know how are they actually doing in reviewing the NEW packages. So accelerating the recruitment process is not easy, given that we will not lower our quality standards. --- I think Sean shares some similar feelings. FTP team shouts for help, and the team seems too "exhausted" to even accept help ... I respect all my fellow developers and their endeavor. In this mail I'm simply describing the fact I saw. On Wed, Dec 25, 2019 at 11:45:28PM +0200, Jonathan Carter wrote: > On 2019/12/24 20:08, John Goerzen wrote: > > > But at the same time, I feel that the project as a whole isn't really > > taking this problem very seriously. > > That is true, probably mostly because many people don't really > understand that there is a problem. The NEW queue waits are tough, but > there are also the following which are also often in serious need of > attention: > > * Patches attached to bug reports > * Request for sponsorships > * Merge requests > > Energy put into all areas like that end up paying for itself because it > helps energize and attract new contributors. > > I try to keep up with sponsorship backlogs (making good strides but > can't really keep up), which at the same time adds load to the NEW queue > (11 of my and sponsoree packages stuck in there right now), which I feel > kind of bad for so I've been trying to join as an FTP team trainee too > to help out there (which I should probably try to follow-up again but > that's also been a bit frustrating). > > I think many will agree with you that we should do better in all those > areas, especially the NEW queue, but change is difficult and in itself > takes time. In a commercial setting it would probably be easier to > create incentives to motivate staff to do more review kind of work, but > I suppose in Debian it's seen as somewhat unglamorous work and we don't > have many methods to incentivise contributors. > > In particular I think it's important to support events like bug > squashing parties because it's one of the few things that we can do, and > encourage things like patch reviews, sponsoring and NEW queue reviews at > these events and maybe even thank all the people who participate in > these on a monthly basis in bits from Debian so that maybe this work can > be highlighted more as something that we do value and might encourage > more people to get involved there. > > -Jonathan > > -- > ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) > ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage > ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org > ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. >
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On 2019-09-25 07:15, Sam Hartman wrote: >> "Scott" == Scott Kitterman writes: > > >> For several of these recommendations if I cannot get consensus, I > >> will call for a GR myself. > > Scott> What do you think is important enough in this area that you > Scott> would rather have people not contribute to Debian if they > Scott> aren't willing to do it your way? > > Nothing. > The thing about recommendations is that you don't have to follow them. > > I think that recommendations leading toward more uniform practices have > huge value even if some people don't follow them. Is the recommendation working well under most circumstances? I mean, different teams have already made their conventions at these point, such as go team, rust team, nvidia team, etc. These team designed "local" recommendations always adapt well with special property of their corresponding ecosystems. Designing a convincing "global" recommendation that works nearly everywhere is difficult. While designing ML-policy I discovered that it's easy to find exceptions to break the global rules. > And eventually, when we have enough experience it might well be that > having more uniformity is worth some people not directly contributing to > Debian. > I don't know if we'll ever make that trade off and I know we wouldn't > (and shouldn't) make it today. As you said, recommendations are merely recommendations. Debian developers customed to their own workflow may not necessarily follow the recommendations. However, the recommendation makes a difference for newbies or newcomers, if their arbitrary educational resources share uniformed recommends. To some extent I think debian development is destined to be diversified.
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On 2019-09-25 05:32, Bernd Zeimetz wrote: > On 9/24/19 3:21 PM, Holger Levsen wrote: >> On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote: >>> For several of these recommendations if I cannot get consensus, I will >>> call for a GR myself. >> >> TBH, I'm not thrilled to read this, though of course it's in your rights >> to do that. (I'm afraid such GRs would cost a lot of time which could be >> better spent elsewhere. Of course I might be wrong about this and the >> outcome of those GRs will be worth them.) > > ack... > >> OTOH I'd be thrilled to see some progress on reimbursing BSP participants >> and similar stuff. As I see it, the next BSP will happen in a month in >> Vaumarcus... > > and ack... > > There are way more important things to do than to discuss the place of > git repositories. Agreed. What I can do for this thread is marking mails as read and voting for objection if I was required to act.
Re: farewell
Hi Marc, Sorry to hear that. In fact I have some similar feelings. On 2019-07-23 01:22, Marc Munro wrote: > I've been using Debian for 20 years and in that time I've never strayed > to other distributions. But Buster is too much. I always fail to find a better free and independent replacement to Debian. Even if the current stable release does not deliver the user experience we expected, what the other distros deliver, I guess, would be more or less the same. That's because Debian is a collection of scattered software, where the user experience is not always decided by Debian itself but the software upstreams. > Today I logged in to my laptop and the CPU was running flat out, as was > the network. So I looked, and it was packagekitd. So, I disabled and > stopped it using systemd. Then I logged out and logged back in again. > The same happened. And it was still packagekitd. Why? How is this > even possible?. Why had disabling it with systemd not disabled it? > Maybe I could uninstall it? No, Gnome depends on it. > > Oh, Gnome. It's a pity that the "software stores" started to think they know "what the user want" and decided to silently download .deb packages preparing for updates without informing the user. Everytime after I freshly installed a Debian system, I'll immediately disable packagekit. However, how can a gnome user get rid of the packagekitd? It's in every distribution. For sid users automatic upgrades are dangerous. Last year when unattended-upgrades was somehow enabled by default on sid without my confirmation, my system was broken by it through blind upgrades. That said, it's simply that I don't like the design of several programs. Luckily I still have the freedom to force these programs to stop: if systemd --disable gdm3 doesn't work (yes, it indeed doesn't work at all), I can mask that unit by symlinking it to /dev/null. If masking still doesn't work, I can e.g. `sudo rm -f /usr/bin/gdm3` and the annoying program will finally stop working. This is much better compared to the most widely used operating system in the world where you have no freedom to stop it from doing anything you dislike. > Oh, and X11 forwarding no longer works. I didn't want to hate > Wayland... I heavily rely on extremely low key repeating latency and extremely high key repeat rate. Under Xorg this is as trivial as a single command: xset r rate 160 160 Wayland provides no means to achieve that. That means I will strongly resist Wayland until the day it started to realize how keyboard settings are important to weirdos like me. > Do you really think this is progress? Removing and making difficult to > access, all of Unix' power and flexibility, and dumbing it down so that > the easy stuff becomes easier but the power-user stuff becomes harder > and harder to access and scripting is no longer a matter of telling the > machine what to do, but rather figuring out how to work-around all of > the improvements. the "improvements". As per the free software licenses, they provide no warranty. In the world of free software when one is not satisfied with some piece of software, the one will either become a part of the upstream, fork the project, working around things, or simply leave. Do you have any suggestion for the Debian side so we can make some concrete improvements, or mitigate some problems? > So we're done. I feel bad, like I'm being disloyal but I can't go on > like this. I feel bad at some points too. Be well and have a good day.
Re: 請問，ask. Debian master.
Hi Wong, Host机的效率取决于各种不同的硬件/软件因素，包括但不限于操作系统内核， 文件系统，编译器参数，虚拟机用途，以及Host机的硬件配置。该问题的复杂性 和讨论已经超出这个邮件列表的讨论范围，请参阅以下链接来访问用户支持渠道： https://www.debian.org/support On 2019-05-20 18:22, Wong Kemba wrote: > 有幾套的OS都不錯， Debian, Ubuntu, Opensuse, Win7 > 都可以作為Host, 然後在安裝virtualbox, 去安裝其他的OS. > > a.請問，這個host LinuxOS 應該選 Debian, Ubuntu or Opensuse or > Win7? > 那一套作為host可以讓別套的OS發揮最大的效率效能？ > > Edward Wang
