1,948 karma · joined July 20, 2012
Who?
> Not to mention it's post-facto in that they did all of this before notifying anyone.
Isn't that pretty much the number one rule when restricting accesses? First remove accesses, then communicate?
Who is "we"? And what did they witness?
All we got right now is one side of the story.
It is indeed surprising such change wouldn't be immediately followed by a public announcement, but they've been founding and managing RubyGems for a very long time now, so it's not even clear to me how this can be a "takeover".
I'll happily join with my pitchfork if it turns out this is indeed a malevolent move, but until I've read their side of the story, I'd rather wait and see.
Edit: 35 minutes later, here we go: https://rubycentral.org/news/strengthening-the-stewardship-o...
Ruby/Bundler doesn’t have any of these problems, and nothing on their roadmap really excite me.
Except maybe the binary Ruby distribution, but it’s a once or twice a year thing, so not exactly a major pain point.
In your case, StringIO use to just be stdlib code so bundler (or rubygems) uses it. Later on it became a gem, so by requiring it before reading the Gemfile, bundler run into this problem of already having loaded the wrong version.
Everytime this happens the bundler team has to modify bundler, and as a user the fix is to upgrade bundler.
You can see they had to vendor a lot of code from default gems to avoid this problem: https://github.com/rubygems/rubygems/tree/c230844f2eab31478f...
Just clarifying this one:
> I do not understand why the option to do so would not have helped in the hacker issue.
Because users aren't omnipotent. When a user need to parse some JSON, they'll reach to `JSON.parse`, which they either already know about or will find from a cursory search. That will have solved their problem so they will not likely look in detail for the dozen or so various options this method takes and won't consider the possibility of duplicated keys nor their potential nefarious impact.
Hence why the defaults are so important.
> it is important for me to try to argue against churn
It's alright, I'm with you on this in general, just not in this particular case.
Because that wouldn't have prevented the issue I linked to.
Default settings are particularly important, because most of the gem's users have no idea that duplicated keys are even a concern.
JSON is used a lot to parse untrusted data, as such having strict and safe default is particularly valuable.
In your case the JSON documents are trusted, so I understand this change is of negative value for you, but I believe it has positive value overall when I account for all the users of the gem.
Additionally, even for the trusted configuration file or similar case, I believe most users would see it as valuable to not let duplicated keys unanswered, because duplicated keys are almost always a mistake and can be hard to track down.
e.g. a developer might have some `config.json` with:
{
"enabled": true,
// many more keys,
"enabled": false,
}
So again, I understand you are/will be annoyed, because your use case isn't the majority one, but I'm trying to cater to lots of different users.
If going over your code to add the option is really too much churn for your low maintenance project, as I mention in the post, for such cases a totally OK solution is to monkey patch and move on:
require "json"
module JSONAllowDuplicateKey
def parse(doc, options = nil)
options = { allow_duplicate_key: true }.merge(options || {})
super(doc, options)
end
end
JSON.singleton_class.prepend(JSONAllowDuplicateKey)The whole point of the article is to explain why while I have empathy for code owners that will be impacted by various changes sometimes I believe the benefits outweigh the cost.
I even linked to an example of a very nasty security issue that would have been prevented if that change had been made sooner.
> Is the ruby community breaking?
No, the community is trying to fix past mistakes. For instance the YAML change you are cursing about has been the source of numerous security vulnerabilities, so tenderlove had to do something to remove that massive footgun.
I totally get that it annoyed you, you can't imagine how much code I had to update to deal with that one.
But again, while I totally agree maintainers should have empathy for their users, and avoid needless deprecations, it'd be good if users had a bit of empathy for maintainers that are sometimes stuck in "damned if you do, damned if you don't" situations...
Meaning Ruby ships with that gem pre-installed, but it's still a gem and you can upgrade/downgrade it in your gemfile if you so chose.
As for `require "json/ext"` that's outdated knowledge.
e.g. to be convicted of trespassing, it has to be proven you knew you were trespassing, or at least that you reasonably should have known.
So no, you wouldn't be convicted because you accidentally took down your own system, etc.
At the end of the day, regardless of whether the letter of the law will allow it or not, what is clearly being investigated here, is a supposed (and somewhat documented) intent at influencing the French people through a distortion of the Twitter/X algorithm.
Until now, all the "social media" platforms have essentially been regulated like hosting services, under the assumption that they have a fairly neutral stance toward the content they host. Hence they're not directly held responsible for what they display.
But if it turns out their algorithms aren't so neutral, it begs the question of whether they should be regulated like legacy medias, hence be held responsible for what they publish.
Deepl translation of the relevant part:
> At the heart of this investigation lies a legal innovation. Mr. Bothorel's alert is largely based on a recent analysis published on February 6 by legal scholar and law professor Michel Séjean. In the specialist journal Dalloz, he argues that under French law, distorting the operation of a recommendation algorithm on a social network can be punishable by the same penalties as computer hacking. According to this analysis, manipulating a platform's algorithm without the users' knowledge would be punishable under Article 323-2 of the French Penal Code, which punishes “hindering or distorting the operation of an automated data processing system”.
I'd suggest to drop the DSL, at the end of the day, a good old class with a constructor stored in a constant is much more more transparent:
class PaymentService
STRIPE_CIRCUIT = BreakerMachines::Circuit.new(
threshold: { failures: 3, within: 1.minute },
reset_after: 30.seconds,
fallback: ->{ { error: "Payment queued for later" } }
)
def charge(amount)
STRIPE_CIRCUIT.wrap do
Stripe::Charge.create(amount: amount)
end
end
end
The interned string table uses weak references. Any string added to the interned string tables has the `FL_FSTR` flag set to it, and when a string a freed, if it has that flag the GC knowns to remove it from the interned string table.
The keyword to know to search for this in the VM is `fstring`, that's what interned strings are called internally:
- https://github.com/ruby/ruby/blob/b146eae3b5e9154d3fb692e8fe...
- https://github.com/ruby/ruby/blob/b146eae3b5e9154d3fb692e8fe...
Variables don't "contain" a string, they just point to objects on the heap.
So:
my_string = same_string = "Hello World"
And since that flag really doesn't require lots of work in the VM, it's likely to be kept around pretty much forever.
The original plan was to make the breaking change in 3.0, but that plan was canceled because it broke too much code all at once.
Hence why I proposed this multi-step plan to ease the transition.
See the discussion on the tracker if you are curious: https://bugs.ruby-lang.org/issues/20205
For the inline call caches in the interpreter loop, they are monomorphic, so if you call the same codepath with the decorator and the actual object, they will indeed flip flop.
The second layer of cache is class based, so after the inline cache is defeated you will end up doing a single hash-table lookup on the class.
As for YJIT, IIRC it does handle polymorphic call caches, so it won't mind such situation at all unless you have more than a handful of different implementations of that method being called at a given callsite.
It should be:
def method_missing(name, *args, **kwargs, &block)
def method_missing(name, ...)But I don't personally think Shopify would benefit from this specific implementation of namespaces (a couple colleagues do). I'm personally not even sure Namespace is a proper term to describe that feature. It's more some sort of lightweight sandboxing to me.
Also:
> They have so many expert Ruby devs
If anything, the average Ruby expertise at Shopify is likely noticeably lower than in most Ruby/Rails shop.
In some extreme scenarios with tons of very small partials, it can win against Action View because the Action View partial lookup is significant overhead.
> The source said the scientist in the space sector underwent a random check on
> arrival, during which his work computer and personal phone were searched, and
> messages referring to Donald Trump's administration's treatment of scientists
> were found. Authorities told him they had found messages "that express hatred
> towards Trump and can be qualified as terrorism," the source said.
> His professional and personal equipment was confiscated and he was sent back
> to Europe the following day.
[0] https://www.lemonde.fr/en/international/article/2025/03/20/f...
If you want to make a CI performant, you'll need to use some of its features like caches, parallel workers, etc. And GHA usability really fall short there.
The only reason I put up with it is that it's free for open source projects and integrated in GitHub, so it took over Travis-ci a few years ago.
> it's not http/2 fault, but rather ruby
My post is to be read primarily in the context of Ruby, as the intro clearly explains it. I'm not the one who posted it here, it really isn't intended for the HN audience. I would never submit my posts here.
Many of my points are more general than just Ruby-centric, but yes, if your stack of choice have very good support for HTTP/2 I'm not saying not to use it in your DC.
My point is that as a Ruby user, there isn't much reason to lament over the lack of HTTP/2 support in Puma or some other servers.
If you assume no multiplexing, you can write a much simpler server.
Indeed, I misread the spec, and added a small clarification to the article.