I'm trying out niri, after getting comfortable with hyprland. This will be interesting!
01.12.2025 17:02
👍 0
🔁 0
💬 0
📌 0
I'm trying out niri, after getting comfortable with hyprland. This will be interesting!
"Who is using the most resources?" is a common question for cloud admins. With our new user group cost dashboards, you can answer that question with more granularity!
2i2c.org/blog/2025/cl...
I believe this was the following keynote: jupytercon2025.sched.com/event/28U0G/...
I don't know where the data were from, but I know that Jason will!
A testamonial about Jupyter hub's impact on someone's career.
A talk on the voices of JupyterHub! The longer I spend in OSS, the more utterly convinced I am that the people are the resource, not the software. This talk really captures that.
A graph of contributor capacity over time. We see a recent dip in new and returning contributors
The GitHub Octoverse report shows that Jupyter notebooks are themselves distinct environments in github, and show exponential growth.
JupyterCon has been fantastic. The energy and warmth from the developers, users, and researchers has been delightful!
Here's an interesting slide that touches on the long term questions about the project:
Yeah, I think we're pretty aligned on the nature of the problem! I don't feel confident that I have the golden bullet either, but I am enthused that more of us are talking about it in general -- that's definitely an improvement.
This is harder in semver - how do you encode/schedule N breaking changes ahead of time, whilst also making room for an undefined number of new features etc.?
I think that's a nuanced point that won't come across clearly here!
Yes you could do that! And we used to do that in awkward array.
The benefit to use calver is that you lose the misplaced assumption and force people to refer to the document that you would author in both cases. Additionally, in awkward we used time-based compatibility, so calver would have helped!
In theory each month could be a breaking change, but by defining a schedule you can allow people to predict the calver numbers that these correspond to. With semver, you lose some of the segments to semver semantics.
I agree in part, and I don't think calver is perfect either. The point is more nuanced though - the idea is that you can make breaking changes for different parts of the code base at different times.
So, I reckon you might want to identify the persona of the package author that would use effver, and ALSO speak to how consumers of effver-sioned packages should reason and use this (contrasting with semver, probably)
You might also wish to reference examples of where semver failed in practice?
What I don't love about effver is that it surfaces the hand-waviness of this, but doesn't make it easier to trust a constraint.
That's why I tend to like calver on the basis that you can literally pre-define what a breaking change is, and when you'll make it. But, it's more work.
That means semver is really there to help people apply upper AND lower bounds to version constraints.
My suggestion for introducing people to effver is perhaps to center this point earlier on:
The whole point of ascribing meaning to version numbers is to permit someone to say "I'll use a range of versions, so long as they work".
The "whether they work" part is doing a lot of heavy lifting.
- e.g. big projects that have breaking change windows (where they cram together a bunch of breaking changes)
- at this point, it's fair to compare semver with other schemes that also require additional context to interpret version numbers, e.g. calver, effver, zerover, etc.
- good semver usage *requires* that you author some additional document that defines the bounds and intention of compatibility
- it really suffers for big projects (as the number N of distinct pieces grows, the likelihood that successive versions are "breaking changes" grows), i.e. as N→∞ you end up with something equivalent to monotonic incrementing numbers
- it gets worse with languages like Python where APIs can be tested far more deeply (e.g. introspection)
The way I've been thinking about versioning is as follows:
- semver is fundamentally a lie that we tell ourselves. It presupposes a lot of ill-defined notions of compatibility.
Lol, listing my blueksy in my bio and not logging in for a week!
I'd love to give this some more thought to articulate my feelings on this more clearly. Let me get back to you!
Ugh this was so useful. Time for a new extension...
We “conda” believe it! In collaboration with 7ASecurity and @sovereign.tech, we carried out an audit of conda-forge. Read the details at our blog: ostif.org/conda-forge-...
@choldgraf.com shared this with me, and it's worth a read!
www.technologyreview.com/2025/05/20/1...
We've launched Jupyter Book for 2i2c communities!
With Jupyter Book 2, communities can focus more on content than design, with improved interactive environment launches from Jupyter Book, added features for landing pages, and colocated community documentation with hubs.
Deepdive links in the TuringWay.
Excited to see the @turingway.bsky.social move to Jupyter v2, which is powered by mystmd.org.
Check it out:
book.the-turing-way.org
Especially the glossary:
book.the-turing-way.org/afterword/gl...
We're exploring ways to support scientific reproducibility and sustainability with Binder. What if we could reduce the gap between where researchers conduct their computational analyses using open source technologies and bridge them to publishing platforms for dissemination?
New MyST proposal! It's for a short-hand way to add classes/options/labels to roles and directives. Read and comment here: github.com/jupyter-book...
This will unlock a lot of functionality for extending roles in particular, I'm really excited about it!
(led by @row1.ca and @agoose77.bsky.social)
There is the odd bug, though, and the author formatting is a todo!
