I think you're right, but I suspect the root here is one of legal liability - if rubycentral is operating as a nonprofit that hosts _a recurring attack vector on other companies_, they'll have legal obligations to secure that service against those attacks. I assume they are continuously deploying out of that repository, and took the simplest route to controlling the attack vectors?
I'm not sure how anyone familiar with open-source communities would fail to predict the backlash though. They really should have forked the repository and switched the deployments over to their downstream fork (if I'm right about the root cause here).
That would be a pretty broad assumption of liability: I'm not very involved in Ruby but I am involved in Python packaging, and to my knowledge there's been no similar discussion around the PSF's keys-to-the-code control over PyPI (which is in a similar position in terms of supply chain attack vectors).
In other words: that argument is interesting, but it feels strained to me :-) -- I don't think RubyGems or Ruby Central is actually legally liable in this way (or if they are, it suggests a failure of clarity in their EULA/TOS).
Well.. "legal liability" is kind of complex topic. Usually what really matters isn't "what the courts will actually determine if such a case is brought" it's "how much will it cost to prove that lack of liability, and what is the risk that we are wrong?". I also don't believe that such an organization is liable for anything beyond negligence, but whether the lack of an action constitutes negligence is .. well, one can rarely be totally confident in the outcome of that kind of proceeding.
Well, there's more information out and it seems pretty.. damning. I wasn't convinced by "power grab", but "economic pressure from our sole remaining major sponsor" is _way_ more believable, and the chain is events is getting fairly clear. Check out Joel's explanation for a coherent delve into the events: https://joel.drapper.me/p/rubygems-takeover/
Now I just have to hope the fallout from this includes a less centralized replacement for the tools I'm used to - I haven't found anything solid yet, but I imagine andre will be examining this problem space with rv now.
and I doubt you could ever get negligence to stick, given you are downloading code from some website and running it, on your own accord, entirely unprompted
I used the models with a good workflow, but found them less than helpful. But I think that if I worked in a less expressive language I'd be very enthusiastic.
Aye. It's not the smartphone that's the problem, it's the async notifications pulling you into social media traps.
I dropped those apps about 8 years ago, but started to do most of my _reading_ on my phone - when I pick up my phone and habitually open something now, it's a book of some sort. It's a good idea to have something to replace habits with, if possible.
DRY is _not a best practice_. Repetition is a "code smell" - it often suggests a missing abstraction that would allow for code reuse (what sort of abstraction depends on the language and context), but "blindly-drying" is in my experience the _single most frequent mistake_ made my mid-to-senior engineers.
My experience is mostly in Ruby though, so I'm not sure how well it generalizes here :-)
Remember in school when you learned to turn a truth table into a Karnaugh map and then use it to find the smallest equivalent logic expression? Well, your code is not a Karnaugh map, is it?
At my first big corporate jobs, I got to work on a codebase that was nothing but premature DRY’d code, but I didn’t know it at the time. As someone who was self taught, and suffered from imposter syndrome as many of us do/did in that situation, I thought I was missing something huge until I was talking to a senior developer and these strange design decisions came up, to which he said something like
> Yeah, that was written by <ex-engineer> and he couldn't abstract his way out of a paper bag
I guess the real lessons were the crappy decisions that someone else made along the way.
FWIW I completely agree in python, Java, typescript, and golang. I've seen people just parrot dogma about DRY and SOLID principals where their DRY'd code is completely not open to extension etc
Premature dry'ing is the same as premature engineering. And lest someone go 'oh so YAGNI is all you need'... no, sometimes you are going to need it and it's better to at least make your code easily moldable to 'it' now instead of later. Future potential needs can absolutely drive design decisions
My whole point is that dogma is dumb. If we had steadfast easy rules that applied in literally every situation, we could just hand off our work to some mechanical turks and the role of software engineer would be redundant. Today, that's not the case, and it's literally our job to balance our wisdom and experience against the current situation. And yes, we will absolutely get it wrong from time to time, just hopefully a lower percentage of occasions as we gain experience.
The only dogma I live by for code is 'boring is usually better', and the only reason I stick by that is because it implicitly calls out that it's not a real dogma in that it doesn't apply in all cases.
(Okay, I definitely follow more principals than that, but don't want to distract from the topic athand)
It would be better to make a class for languages where DRY is not a best practice, then create classes of languages where it is a best practice or may be a best practice through multiple inheritance. To keep things simple.
Yeah I've had so many problems with understanding and working with other people's code bases when the person was obsessed with DRY.
You wrote that code 4 years ago with tons of abstractions designed for some day someone not having to repeat themselves... but it's been years and they've never been useful. However I've had to dig through a dozen files to make the change I needed to make which by all rights should have been entirely contained in a few lines.
My most common reaction to a new codebase is "where the hell does anything actually get done" because of silly over-abstraction which aspires to, one day, save a developer five minutes or three lines of copied code.
These types of posts are .. well thought-out, and usually posted by someone with relevant education. But they are not reviewed documents or journal articles, and you can _tell_ when someone is mixing in a lot of their own educated guessing with the research they've done. Which is the case here.
He probably wasn't intending it to be taken as authoritative source, but that's how most people will _read_ something like this after running into it on the front page of HN. And most of this is just.. guesswork.
The author is presenting a plausible enough theory without any evidence that it is actually more accurate than the actual historical texts.
As one example, the author goes on and on about the importance of the conduits into London - but here's how actual documents from the time describe them:
"A certain conduit was built in the midst of the City of London, so that the rich and middling persons therein might there have water for preparing their food, and the poor for their drink"
First ran into this on persistent servers, where the deployed instance knew branch names github had long forgotten about.. Someone pushed a branch named "bugfix", and `git fetch` started erroring.
You get even _more_ interesting problems if part of your team has case-insensitive file-systems!
Indeed, if I were running that site, I would now implement the ability to turn on intentional non-randomness for _specific people_, and begin embedding messages in the sequences of comics, or selecting the same two comics 28 times in a row on occasion. Heck, stick the referrer in the session and give everyone coming in from _that blog post_ wildly divergent randomness characteristics :-)
While I don't really _disagree_ with any of this, I want to raise a point from the other direction - it's possible (and for some of us, absolutely necessary) to build software such that holding a large "structure of thoughts and possibilities" in your head is not required.
I find myself largely incapable of doing so, open-plan office or not, and have compensated by adopting development approaches that break problems down in consistent enough ways (into small enough pieces) that the structures I have to pick up and put down are never all that complex. Which is good, because they fall out of my head just all the time. ADHD, a very poor memory for detail, and a role that has me responsible for juggling many tasks concurrently would _destroy_ my productivity if this article were universal truth.
Don't get me wrong, I _hate_ working in an open-plan office. But the impact it has on my output is not because the interruptions affect my flow, it's because the constant social contact stresses the heck out of me >.<
I gained the most from gobase.org, just clicking through professional games. The tool you can review/replay games with lets you try to guess the next move - just let them play the first 10-15 moves and then start guessing. Don't spend a ton of time thinking, just _guess_. Guess over and over, and if you don't guess the move after 5-10 tries, have it tell you, try for a few seconds to understand why that might be a good move, and continue.
You should totally do the tactics and puzzles that you can find (that same site has a bunch), but there's a lot more strategic recognition and pattern-matching in go than chess.
I'm also interested to hear if there are better tools though in the last .. Christ, twenty years? I'm old now -.-
It's an awkward space - requiring us to pay them to put our profiles there is the main way to keep the content valuable/accurate.. but while that's fairly typical for hirers, it'd feel scammy to job-seekers.
I think there's room for such a service, but growing it into a viable model would be a real project, and probably not a distraction a business would want to take on except as a pivot.
I'm not sure how anyone familiar with open-source communities would fail to predict the backlash though. They really should have forked the repository and switched the deployments over to their downstream fork (if I'm right about the root cause here).
(I'm mostly thinking in terms of supply-chain attacks, like this one: https://blog.rubygems.org/2025/08/25/rubygems-security-respo...)