flurie

In practice this is less of a concern for a few reasons:

- 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.

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.

[1] https://www.nplusonemag.com/issue-12/reviews/pitchfork/

[2] https://www.nplusonemag.com/issue-12/essays/american-juggalo...

[3] https://www.nplusonemag.com/issue-12/fiction-drama/lightning...

[4] https://www.nplusonemag.com/issue-24/the-intellectual-situat...

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.

[1] https://en.wikipedia.org/wiki/Qualitative_research

[2] https://en.wikipedia.org/wiki/List_of_research_universities_...

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.

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.

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.

[1] https://grafana.com/docs/tempo/latest/getting-started/instru...

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.

If you're attending BazelCon I'd love to have a chat with you about this stuff in some more detail. (If you're not I'd still love to have a chat!)

I've been wondering idly if it's possible for Nix to support the Bazel Remote Execution API that seems to be catching on[1] more generally.

[1] https://github.com/bazelbuild/remote-apis?tab=readme-ov-file...

I'm on my third (long story) Bolt, I would pick it three more times if I could, and I'm certain that I've sold more Bolts than most GM salesmen, so my comment was more familiar snark than anything. I have done the trips into minimally friendly locales and spent longer than is wise at a Tilted Kilt with small children in order to ensure a healthy buffer for a trip home. This news is nothing but upside for me personally. Perhaps we will encounter one another at a Tesla charging station one day!

I'd seen some rumors that Tesla has been trying to slow down onboarding of other automakers to their charging network, so it's good to see information to the contrary.

I still struggle to see how this ends up favorable for Tesla in the long run. They did not charge licensing fees for the connector, and even if they charge a premium to charge non-Tesla vehicles, now owners of Tesla vehicles are going to run into situations where a Chevy Bolt has to double park to use a Tesla fast charger at <=50kW, doubly driving down utilization.

I didn't use the word "stagnation," and "recession" has a core definition that is pretty broadly accepted[1]. I have no opinion on whether or not the recent dip merits a recession, but it is not enough to define one on its own.

The other word used was "crisis," and my criticism is that the word is broad and never defined.

My usage of the word "sell" is more similar to "persuade" and is a valid definition[2].

[1] https://en.wikipedia.org/wiki/Recession#Definitions

[2] https://dictionary.cambridge.org/us/dictionary/english/sell

I'm curious what the point of this piece is. If the goal is to sell the author's book, it has not done a great job of selling it to me. There's a lot of information missing here, and it is not clear to me that the author has a fundamental understanding of how to conduct qualitative research.

The introduction does not clearly state the problem, leaving us to understand that the topic is the "recession and crisis" from the title. But the United States is not experiencing a recession, and "crisis" is never defined.

Then we learn that 50 interviews of many different types of C-levels took place over seven months, but we aren't told which seven months, and we don't have any information from the interviews other than interview fragments. We don't even have broad topics, let alone an interview script, so the script could have been asking questions about the weather for all we know.

In-between information shared alongside pull quotes is a lot of editorializing, with lines like "There is no denying that the technology industry, for at least a decade, was seen as a symbol of stability and continuous development." I do not see Information Technology as synonymous with "the technology industry" more broadly.

I'm not too proud to admit I took the general concept from https://sadservers.com/ and turned it into something I could use for interactive debugging interviews.

I had golden images with some scenarios I wrote myself, and the images automatically shared a tmux session over http so I could follow along without requiring the candidates to screen share.

I did have to ask for IPs so I could ensure the machines were just available to me and the candidate, but it was otherwise pretty seamless!

Though now that https://sadservers.com/ has a paid service it might be worth looking into.

One problem tools like these tend to have, to take Amplify as an example, is that they turn what might be a complicated problem served by heterogeneous tools and glue code into a very narrow happy path solution and dragons in all other directions. When the problem is handled piecemeal, the dragons are local to whatever specific problem areas exist; when the problem is centralized, the dragons are everywhere.

Python building, packaging and deployment has two extreme states: the king's highway and the hall of a thousand knives. If the portable Python suggestions do not make sense to you, then consider yourself lucky, because you have managed to stick to the highway.

There are a few things this is responding to, but since it does not provide the context directly, here they are (by no means exhaustive):

- Anduril dropped as NixCon sponsor: https://news.ycombinator.com/item?id=37418351

- Open letter against MIC sponsorship: https://nixos-users-against-mic-sponsorship.github.io/

- Open letter in support of MIC sponsorship: https://nixos-users-for-western-mil-and-govs.github.io/

- Updated sponsorship policy: https://discourse.nixos.org/t/nixos-foundation-event-sponsor...

- Open letter asking Eelco Dolstra to step down from NixOS Foundation and Nix team: https://save-nix-together.org/

That's been my experience as well. It lacks support for certain clone(2) flags like CLONE_VFORK[1], which limits the set of non-trivial programs it can run, and since running non-trivial programs is most of the point, I haven't revisited it since it was first announced.

[1] https://github.com/facebookexperimental/hermit/blob/bd3153b4...

Sure, and this is all fine, but it feels like this information gets buried or smoothed-over, and I think you strengthen your position by leading with it as a differentiator. Nobody new to Nix knows what targeting 2.3 means, but they likely know what flakes are, and you aren't doing a lot to make it clear why they should prefer a fast language evaluator to something that can handle flakes.

> Tvix explicitly targets stable Nix features, so supporting Flakes is a non-goal.

Except that it rolls its own CA store[1], which is also not a stable Nix feature. One could argue that it has to roll its own store because Nix wants to own the store, but implementing a shadow version of an experimental feature makes the "they're just targeting stable features" part ring rather hollow.

> The key point of Tvix _not_ having support for Flakes is to not make special snowflake evaluator features that are tied in with it.

That's not really how I read the authors' defense of this choice. It seems like they made it because they disagree with the design decision, and I consider that more defensible than the position you offer. I just wish they would make this information more central, and I will keep posting it in news items about Tvix because no one else is going to. There is no indication that the "Nix" they implement is many years old now, and when they do[2] indicate it, they are vague about why.

[1] https://cs.tvl.fyi/depot/-/blob/tvix/castore/docs/data-model...

[2] https://cs.tvl.fyi/depot/-/blob/tvix/README.md#compatibility

It's worth noting that tvix explicitly[1] does not support flakes.

[1] https://lobste.rs/s/ypwgwp/tvix_we_are_rewriting_nix#c_zvtze...

In a sense, OTel is a big threat to Datadog, so I can imagine slow-rolling support is one way to manage that without looking actively hostile to it, similarly to how Datadog has other OTel "support" that doesn't play nicely with a lot of their more valuable tools/features.

Thanks for the response, Graham.

I think I'm still missing something. By all accounts, I and my organization should be in your target market, but there are a few barriers:

- I've achieved significant adoption of Nix for a great many things, but not for building proprietary software.

- I already have an enterprise-grade artifact store to use as a cache.

- I also have an identity platform and robust secrets management.

- I have evaluated lazy trees Nix at a few different intervals and did not find it enough of a speedup to continue using it.

The sum total of all of these barriers is that I may be wrong about whether we're truly in your target market, but I also think those will be common barriers for you, which makes me think I still don't quite understand the product or the market correctly.

It might help to describe how I employ this. I own the build and infra for a fairly large monorepo, and I moved all of the deps to Nix. I have a few ways to source/build things:

- A bare image with just Nix can pull the deps from a cache.

- A pre-built image contains the deps from the latest push to default branch and nothing else.

I do not maintain a separate repo for this. Part of my CI is building and caching the paths. And then CD is building and pushing the image, which the CI has verified as working. This requires using a mutable tag, but you could also have the CD process auto-update the tag if this is not an option.

You're correct that this doesn't save you from having to get the same amount of data to the same place, but the image repo can usually be cached more advantageously for whatever is pulling images, so it should be considerably faster overall.