For resin printing, doing it yourself almost never makes sense. It’s expensive, fiddly, messy, hazardous to your skin and lungs, and consumes a lot of space to do right.
Filament printing, on the other hand, makes sense to do yourself quite often. A $200 printer will do an excellent job of most things you can throw at it, it doesn’t take up much space, is quite safe unless you’re using weird filaments, and even a kid can learn the basics in a couple days.
I made myself plugin that shows new news in wikipedia's current event page and I was using levenshtein originally (they often edit couple of words in article over span of few days so I compare each new article with previous ones for similarity) but after few days it became too slow (~20s) because O(m*n), so I switched to sorensen-dice instead which is O(m+n) and it's much faster and works very similar way, even tho they do slightly different thing.
You need to go back to the roots of open source. Fork it, merge your two changes, remove 90% of code you don't need, rename it, write article about speed up in the new successor vs the old thing.
Forks don't have to be hostile. A perfectly reasonable way to react to an overwhelmed maintainer is just to do a friendly fork. Keep the original name, attribution, git history etc, update the README and start acting as a trustworthy lieutenant. You can review stuck PRs and merge them into your own branch, whilst also merging with upstream master. After a while if you seem to be making good calls the original maintainer can do a bulk merge from your branch to bring in many PRs at once, and maybe add you to the repository.
Check out my fork, Jellyden(iro). It’s the best way to watch Heat 2. All the media selection garbage is removed for a streamlined Heat 2 experience, because why would you want to watch anything else when you could be watching Heat 2 instead.
It's worth asking "if AI is so great for software development, won't that make it dramatically easier for people to maintain their own forks of software?"
(I suspect the answer ends up being no, but the reasons could be interesting)
I'm curious why you think the answer would be no. I've had some success with resolving complex merges with GPT 5.4, and it seems obvious enough that AI is a good solution for maintainers who don't have anyone they can trust to take over the project whilst also needing to boost throughput.
I've been using 5.4 recently, and even on "extra high" some of the tests it wrote were opening the source code and doing a regex to confirm the presence (or in some cases the absence) of specific substrings. It wasn't running the code to confirm behaviour, and the regexes didn't even do a basic check to confirm the text wasn't commented out (not that it would've been sufficient if they had, this is just to illustrate how bad it was).
So, yeah. I'd guesstimate this model was fine 75% of the time, mediocre 15-20%, and actively bad 5-10% of the time. How valuable it is depends on how much energy you can spare as a human on spotting the bad.
You jest, but I think there is kernel of truth here. I do think people should be doing more (friendly) forks instead of funneling everything through upstream.
Ultimately if the new contributor brings in others to the project to also review and progress the project then it will quickly outpace the development on jellyfin and become the successful fork. No maintainer can cope with the workload of something like jellyfin and if they wont assign maintainers there isn't much else to be done.
The key to the success is dealing with the outstanding merges by bringing maintainers onboard that are trying to contribute, build up the team and then the merges will get processed a lot faster.
So this is exactly what's unintuitive about queues, an analogy would be car lanes. Intuition might lead you to conclude that if a 2 lane road has traffic constantly going to 4 lanes will solve the traffic. But this is not true. Many people that would have used the road might have been using public transport or just decided not to commute or stay inside normally will join the traffic until it once again equilibriates. Adding more maintainers without addressing the core problems of the queue won't lead to success
If you only focus on "solving the traffic" then you're right, adding more lanes ultimately just leads to more lanes being full. But the overall throughput is much higher! We need more holistic solutions, to be sure, but I hope no one thinks that means I-5 around LA could just be 2 lanes of traffic because they'll be full of traffic either way.
Does induced demand apply to open source maintaining? What would be the mechanism for that?
For traffic, more users note that the highway is easier to drive on and come over. Would people notice development speeding up and start adding more issues?
Just today I improved my record to 18 minutes. Btw, I noticed my juggling is completely subconscious, I don't move my hands voluntarily where the ball is, the hands move on its own.
You are technically correct - the best kind of correct. But yeah, think of it as a "slice" of a quadcopter along one of its principal axes. Writing the 3D blog post right now.
I think it just represents people/entities who conduct business internationally, since camels used to be a major transportation method on the Silk Road.
Indeed, the cause of the war ISRAELi lies. Just like with Iraq. And they control the US administration with the Epstein files.
It is actually 2nd Epstein War.
reply