Zulip setup coordination - Public Room Timeline

	Zulip setup coordination	91 Members
	Coordination to setup https://nixpkgs.zulipchat.com/, see https://github.com/NixOS/foundation/issues/143	34 Servers

Load older messages

Sender	Message	Time
23 Feb 2024
@delroth:delroth.net	(to be clear, I'm not saying the status quo is optimal, I'm saying that maybe it's a separate issue and not something entangled to whether we distribute CUDA / ROCm / ... stuff)	13:30:50
infinisil	(this is getting maybe a bit too detailed to be on-topic for this channel)	13:32:43
SomeoneSerge (hash-versioned python modules when)	In reply to @delroth:delroth.net (to be clear, I'm not saying the status quo is optimal, I'm saying that maybe it's a separate issue and not something entangled to whether we distribute CUDA / ROCm / ... stuff) Yes, this is an argument that can be made and I think I could try replying to it, but this is unrelated to the "decision making" and could be discussed in the Discourse thread if it happens	13:33:07
@delroth:delroth.net	In reply to @delroth:delroth.net really imo this just needs someone willing to start a discourse thread asking for objections, leaving enough time for contributors and active community members to participate, then figure out how to handle the eventual objections - the whole discussion about infra and the foundation are red herrings here, at least from infra we'll figure out how to execute the decision (By the way, the irony is not lost to me that this is, literally, a "request for comments". Except without the baggage that comes attached with the Nix* RFC process and the tacit expectation of producing a formal document proposing a design and implementation.)	15:05:11
@delroth:delroth.net	In reply to @delroth:delroth.net really imo this just needs someone willing to start a discourse thread asking for objections, leaving enough time for contributors and active community members to participate, then figure out how to handle the eventual objections - the whole discussion about infra and the foundation are red herrings here, at least from infra we'll figure out how to execute the decision * (By the way, the irony is not lost on me that this is, literally, a "request for comments". Except without the baggage that comes attached with the Nix* RFC process and the tacit expectation of producing a formal document proposing a design and implementation.)	15:05:17
@zimbatm:numtide.com	What do you think if the CUDA team wrote a Nix Improvement Proposal (just made up that name), which is like a RFC in terms of structure, but just posted to Discourse? This could be a trial run for something more liteweight than the RFC process. This would be a trial run similar to what happened for the wiki on the foundation repo, but posted more widely	15:14:03
@apcodes:matrix.org	Just out of curiosity: who would need which hardware for testing ROCm functionality? And what is the problem with testing OpenCL/Vulkan? Is this just a general lack of the right GPUs for testing?	15:30:14
	connor (he/him) (UTC-5) joined the room.	15:41:35
SomeoneSerge (hash-versioned python modules when)	It's best to ask rocm-maintainers (e.g. Madouura, flakeby), but very basic things like "can we actually upload an array to vram?" can be tested with consumer grade hardware (probably anything that's in the llvm's target list) and even these things do ridiculously break. The OpenCL issue isn't actually about hardware, it's just about accessing the driver. I think it's about extra "system-features", although maybe there is some sort of hardware-agnostic all-software driver. At least for vulkan there seems to be one.	16:35:34
SomeoneSerge (hash-versioned python modules when)	* It's best to ask rocm-maintainers (e.g. Madouura, flakeby), but very basic things like "can we actually upload an array to vram?" can be tested with consumer grade hardware (probably anything that's in the llvm's target list) and even these things do ridiculously break. The more realistic answer is "something that amd is going to support for a while" because the libraries (*blas, etc) only support a subset of what the compiler does. The OpenCL issue isn't actually about hardware, it's just about accessing the driver. I think it's about extra "system-features", although maybe there is some sort of hardware-agnostic all-software driver. At least for vulkan there seems to be one.	16:42:31
7c6f434c	So concretely, if you find enough people to make a decent initiative appear very harmful, everything just stalls. If a noticeable group of people who won't be dismissed as not having much of the demonstrated commitment to the project is willing to claim the change is very harmful, I find stalling a feature (possibly unstalling later if a majority of the group withdraws under a better explanation!)	18:15:38
7c6f434c	For smaller things, I would much prefer for people to write up their vision, submit it for approval/rejection, than going trough that grueling process. We have «Develop» category on Discourse and we do sometimes link Discourse discussions in PRs. I agree this is a better way for things that do not try to establsh norms for everyone and don't meet strong opposition. If there is a disagreement, well, there is a reason design by committee happens again and again, it is actually best of the achievable for the goal of preserving unity	18:22:45
7c6f434c	I think invoking the Foundation means that Eelco Dolstra does have a veto on changing things and we know that he has consistently opposed unfree for-CPU code on Hydra, so, Foundation won't delegate because Foundation board is not in agreement there is anything that needs unblocking.	18:27:56
7c6f434c	You know, the cases (especially pre-RFC) when a lot of discussion happened then an absolutely unreasonable choice was made made progress, but still did not feel good	18:34:05
7c6f434c	In reply to @zimbatm:numtide.com What do you think if the CUDA team wrote a Nix Improvement Proposal (just made up that name), which is like a RFC in terms of structure, but just posted to Discourse? This could be a trial run for something more liteweight than the RFC process. This would be a trial run similar to what happened for the wiki on the foundation repo, but posted more widely Haven't they literally done this, looked on the set of people who objected and their levels of influence, then started their own Hydra instance for CUDA stuff?	18:40:38
7c6f434c	In reply to @delroth:delroth.net (By the way, the irony is not lost on me that this is, literally, a "request for comments". Except without the baggage that comes attached with the Nix* RFC process and the tacit expectation of producing a formal document proposing a design and implementation.) No joking, for low-controversy mid-scale things I have literally made PRs to Nixpkgs and tagged them `[RFC]`. Some were merged eventually, some rejected.	18:41:42
24 Feb 2024
tomberek	In the end, someone has to take the initiative; to be the leader. Either to decide, or to drive the process, to take a risk, or to take responsibility. We often discuss developing ways to include more voices, or to distribute risk. But these situations require the opposite; to encourage a few to rise to the occasion. We've asked people why they feel blocked. A similar question would be why someone does not feel empowered to act. I'd like to ask why people don't feel empowered to decide.	01:29:49
@apcodes:matrix.org	Yeah, that is a great question I feel. I'd love to hear what people have to say to that.	09:02:25
7c6f434c	We should not discount though, that sometimes people don't feel empowered to decide for good reasons. That sometimes the decision has been previously blocked multiple times by a coalition that is large and influential enough to have to be able to block. Yes, this includes unfree packages on the main Hydra.	09:17:46
Eelco	Whether to build unfree packages on Hydra should not be up to just the infra team, since it's a pretty fundamental decision that affects Nixpkgs' status as a free software distribution. It should be an RFC at least. Also, this subject has been debated at length in the past, and a decision has been made. We're not "deadlocked" or blocked on this issue.	09:48:19
Eelco	(Which is not to say it cannot be revisited)	09:49:58
@apcodes:matrix.org	Alright, just for clarification purposes. Since not everyone seems to be aware of this (including me): what decision has been made and where? Has there already been an RFC that clarifies Nixpkgs' status as free software distribution?	10:01:56
25 Feb 2024
tomberek	Eelco: This starts to steer the discussion into a very interesting direction. The status of being a free software distribution is a specific value. What are the various values we have? Are any considered more important than others? When are exceptions allowed? For example, I suspect this topic comes up due to wanting to provide pragmatic user friendliness - another value. Can these be reconciled by limiting the proposal to only redistributable? Are one of these values more "primary". Do we have a list of these values anywhere? (yes, this related to my proposal to have written down goals/mission/values for the Nix ecosystem)	19:37:58
@jade_:matrix.org	we are not guix, we pretty aggressively package proprietary software, probably more than literally any other distro. so this is at the very least a demonstrated value in the community	19:41:26
raitobezarius	For me, there's a technical lens behind this whole thing which is: we have a finite resource — cache / build capacity, how do we prioritize those? What are the goals here? We say yes to FLOSS, but let's say, someone comes with the 52 flavors of LLVM forks to run inference tasks or training tasks on weird NPU hardware, do we accept 300GB of LLVM?	19:42:42
raitobezarius	If we throw unfree package to the play, the same question applies w.r.t. to prioritization	19:43:02
raitobezarius	I'd obviously say yes anyday to Spotify client, this is a useful piece of software and does not cost a lot	19:43:21
raitobezarius	But some proprietary redistributable software can have some consequences on those resources, e.g. GPU ecosystem with 38 copies of BLAS, one per CPU manufacturer/family/weird new instruction arch, etc.	19:44:14
raitobezarius	Consider Intel MKL, a BLAS for Intel CPUs (works also on AMD CPU but it's locked at the cpuid level), this is a low level package that would trigger consistently a mass rebuild of all Python data science ecosystem if we wanted to support it	19:44:50
raitobezarius	(e.g. pandas, scipy, numpy)	19:45:01

Show newer messages

Back to Room ListRoom Version: 10