I think the only downside with the musl binary is that there can be a performance hit compared to libc, which may or may not be an issue for a terminal text editor.
I also echo some of the comments here saying it's entirely reasonable for a single maintainer not to support absolutely every single distro unless it's straightforward or enjoyable.
A particular highlight of n+1 for me was issue 11, which contained a retrospective review of the site Pitchfork[1], an essay chronicling the author's experience at their first Gathering of the Juggalos[2], and an excerpt of Helen DeWitt's excellent novel Lightning Rods[3].
Issue 24's The Intellectual Situation[4] has a phrase I still think about frequently:
> "you have to choose your irrationality or it will choose you."
I have not been a consistent reader, but reading it is a constant delight.
This is a qualitative methods paper, so statistical significance is not relevant. The rough qualitative equivalent would instead be "data saturation" (responses generally look like ones you've received already) and "thematic saturation" (you've likely found all the themes you will find through this method of data collection). There's an intuitive quality to determining the number of responses needed based on the topic and research questions, but this looks to me like they have achieved sufficient thematic saturation based on the results.
So, I upvoted your comment bc I genuinely believe there is something in your comments worth learning from, but...
> This is a qualitative methods paper, so statistical significance is not relevant.
I have never heard of a "qualitative methods paper" and it sounds like something a researcher would do to push a narrative with "qualitative data" rather than data that could be measured.
You're not necessarily wrong, but the phrase "push a narrative," the scare quotes around "qualitative data," and your initial comment suggest to me that you are not familiar with qualitative research but have a bias or mistrust against it (no judgment, just stating my observation). If you would like to know more about it, this[1] provides a reasonable overview, and if you would like to know much more, I can ask my spouse, who is a qualitative methodologist in medicine at an R1[2], for her recommendations. I can also tell you what I think of this specific paper, but I did not want it to color my initial comment.
> your initial comment suggest to me that you are not familiar with qualitative research but have a bias or mistrust against it
I can confirm that, yes, I do have an arguably paranoid bias and/or mistrust against information that is not quantifiable in nature nor is simple enough for me (an idiot) to understand easily.
Appreciate the thoughtful response. Don't ask the spouse, just enjoy the new year. I'll figure it out.
There are a few broad reasons this can happen. One possibility is that they want to know if the treatment causes suicidal ideation, and the effect is often small enough that people more likely to report those symptoms independent of the treatment confound the result. Another is that they don't want to have to deal with the safety protocols that come with screening in participants who have reported any history of suicidality. Another still is that higher likelihood of an active mental health crisis means that it's harder for study coordinators to determine if participants have provided informed consent.
Sometimes studies are specifically for treatment-resistant depression, and I expect those studies are more likely to screen in participants with a history of suicidality, so I would recommend keeping an eye out for those if you would like to participate in clinical trials.
A lot of work about packaging specifics reads like inside baseball because it is. Most people manage to avoid getting into the specifics of packaging because it’s stuff that mostly gets in the way of the problem they’re trying to solve. But for blessed few packaging is either critical to the problem or is the problem itself. If you never had to learn the inside baseball terminology, it is likely that packaging is not critical to problems that you solve, and I say that without judgment. If you need to get into Nix, you will. There are lots of reasonable ways to manage personal infrastructure that don’t involve Nix. For the problem you describe, I’m not even sure Nix is a preferable solution unless you already use it.
That said, I agree with the original comment. I’m willing to believe that they had these problems and that moving away from Nix was the right decision, but there is little detail in the explanation. They’ve been pretty closed users of Nix to my knowledge, building proprietary tools on top of it without contributing back significantly, and it feels like orgs such as repl.it are contributing back more actively, but this may be a marketing difference as well.
I spend significant parts of my PhD maintaining the packaging and deployment infrastructure of our group. But yes, I have close to no computer science and reasonably little intrinsic interest in the problem space (though I have a deep appreciation). Still I think I have a better than average understanding of the packaging space..
The coffee is made with the assistance of AI, which means some nonzero portion will be something other than coffee, but at least it means every sip is an adventure.
Tempo's a backend/sink for traces, but if you click through to the Tempo docs and find out how to generate tracing data[1], you learn that you have two options: OpenTelemetry, which they recommend, and Zipkin, which they do not recommend.
I'm not sure if this approach is being used already or even viable, but there are good tools for the following:
- creating minimal OCI images from Nix packages
- creating microvms from OCI images
There are certainly some tradeoffs with this approach, but given that the author is trying to optimize for size, in addition to one of the primary benefits to this approach being a really clean, structured build/deploy loop, it seems like it could be worth exploring.
I’m very interested in better bidirectional interop between bazel and nix; it seems such a travesty that for two projects that are so ideologically aligned to work so poorly together. Nix should be able to run builds on bazel and bazel builds should decompose and cache into multiple store paths in a nix environment (think how poetry2nix works).
I'm afraid I'm not planning on it; I don't make it to the west coast nearly as often as I should. Feel free to hmu on LinkedIn or something though; I'd love to get plugged into some people interested in this stuff, and I'm about to have a block of time available when I could potentially work on it.
- They often designate items as "freeleech," which means that downloading does not cost you ratio, but uploading still credits you.
- They often provide free credits at various times, especially for new members.
- They tend to have a soft cap, so the automated warning systems don't even start until users dip below 0.9-0.95.
- As much as these sites have, there is always something they don't have, and providing it will get you a relatively high share of the total upload.
Bear in mind that the primary driver for the site is ensuring access to everything that is available.