 | Zulip setup coordination | 88 Members |
| Coordination to setup https://nixpkgs.zulipchat.com/, see https://github.com/NixOS/foundation/issues/143 | 31 Servers |
| Zulip setup coordination | 88 Members |
| Coordination to setup https://nixpkgs.zulipchat.com/, see https://github.com/NixOS/foundation/issues/143 | 31 Servers |
| 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.netYes, 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(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* (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 |
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 |
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.comHaven'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.netNo 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 |