Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gem.coop

gem.coop

Post reply on HN
Print view View original

121–130 of 331 posts

Re: Gem.coop

#121

Post by busterarm »

soraminazuki wrote: post #99
sosodev wrote: post #95

Earlier quoted context omitted.

Flagging is definitely getting abused more on HN lately. The consensus seems to be that politics and/or morals are irrelevant outside of personal affairs so we must not have these conversations here.

Which is absurd because the hostile takeover of RubyGems primarily involves technology, with serious implications for the security and trust of nearly all Ruby code. Those flagging this submission are the ones prioritizing politics over this critical issue.

Politically-charged ultimatums _caused_ the hostile takeover of RubyGems. This whole thing is politics all the way down.

Re: Gem.coop

#123

Post by zdragnar »

salzig wrote: post #118

Just a thought of mine: why don’t we switch fully to git? Commit signing, tag signing, Decentralize. Doesn’t that sound like a good alternativ?

Someone has to run the git server. Then, someone has to find the git server to pull each gem from, since not every git server is likely to be up-to-date with the each gem, or the correct version. Since these are all decentralized, each individual owner of a git server has to independently scale as more people start using each one.

The benefit to being centralized is... everything is in one place. Everything scales at once. Every update is available at the same time.

We did this back in the day using artifactory and co. to proxy NPM and a few other package managers as well as docker containers and some other things. No third party service going down could keep us from deploying.

Not everyone does it because as a solo developer or a small team, as it feels like pointless overhead.

Re: Gem.coop

#124

Post by IshKebab »

lcnPylGDnU4H9OF wrote: post #115
IshKebab wrote: post #60

Earlier quoted context omitted.

> It's commenting here to stir things up. I'm not. It's true that I dislike Ruby and prefer everyone would abandon it, but that's orthogonal to the issue we're discussing. In fact I'm saying that the Ruby community is being stupid and shooting themselves in the foot by characterizing relatively mainstream right wing views as "extremism". If I was being disingenuous I should really encourage this schism! > It Dunno if…

> relatively mainstream This doesn't preclude extreme. Not commenting on whether the community's is shooting themselves in the foot or not, just that the reason provided is not a good one for believing so. > If I was being disingenuous I should really encourage this schism! I do not think that you are necessarily being disingenuous but misunderstanding the difference of opinion in this way actually seems to encourage…

> This doesn't preclude extreme.

Uhm yeah it literally does. Mainstream views can't be extreme by definition. You might not agree with them, but that's a different thing.

> misunderstanding the difference of opinion in this way

I haven't misunderstood anything.

Re: Gem.coop

#125

Post by soraminazuki »

busterarm wrote: post #121
soraminazuki wrote: post #99

Earlier quoted context omitted.

Which is absurd because the hostile takeover of RubyGems primarily involves technology, with serious implications for the security and trust of nearly all Ruby code. Those flagging this submission are the ones prioritizing politics over this critical issue.

Politically-charged ultimatums _caused_ the hostile takeover of RubyGems. This whole thing is politics all the way down.

Someone withdrawing funding from Ruby Central doesn't necessitate a hostile takeover of RubyGems. The responsibility lies squarely on people doing the takeover. Needless to say, you haven't shown me any convincing arguments for suppressing the announcement of gem.coop.

Re: Gem.coop

#126

Post by davidcelis »

x3n0ph3n3 wrote: post #113
mijoharas wrote: post #68

So, ignoring everything that got us here, what do people think about this? As I see it, there is the original rubygems, which has lost all of it's maintainers, and this new one, that has most of the original active maintainers? (how many were there before? it has most of the ones I think about, but I didn't know who was active over there. I mostly saw activity from deivid and didn't know about most of the others to b…

I'm starkly opposed to this ridiculous fragmenting of the community. They can and should all go work out contribution agreements with RubyCentral and get over their egos.

What makes you think they _haven't_ tried to work things out with Ruby Central? As per a separate article[1], this seems to be a last resort:

> “Since Ruby Central has informed us they will never allow us to continue working on the projects they now claim they own, that we successfully maintained and operated for the last ten years, the former RubyGems team is launching gem.coop today.”

[1]: https://socket.dev/blog/gem-cooperative-emerges-as-a-communi...

Re: Gem.coop

#127

Post by ishouldbework »

mijoharas wrote: post #111
ishouldbework wrote: post #107

Earlier quoted context omitted.

Cannot speak for the US, but in Europe immigration is connected to crime increase in general. The Ukraine refugees are one of few statistical exceptions.

Have you got any references for this claim?

Well, https://link.springer.com/article/10.1007/s10611-024-10144-y seems to claim there is a link for sexual crimes. This paper suggests that there is some delayed effect https://www.sciencedirect.com/science/article/pii/S092753712....

Re: Gem.coop

#128

Post by x0x0 »

ilikepi wrote: post #80
baggy_trough wrote: post #74

Earlier quoted context omitted.

I personally cannot think of a new ruby gems or bundler feature from the past decade that I noticed or cared about. That isn't to say that there aren't any; I just don't know what they are.

There have been several releases with incremental but still notable performance improvements. The overall cadence has been pretty steady, intentionally targeting roughly one minor release per year since 2019-ish, with handfuls of quality of life improvements in each. Arguably RubyGems and Bundler are infrastructure, so the major feature is stability. What sort of big feature are you imagining is missing from your dep…

André is working on a combination of rbenv/asdf, bundler, and gem that I think is interesting. Not that they're wildly broken, but I'd rather have fewer tools and it always seemed a bit odd that they're separate when they're notionally managing the environment in which your ruby code executes.

Given the rise in supply chain attacks, I'd also like a private rubygem instance where I can whitelist gems and even versions for my company in a way that doesn't let anything else install. I'm not sure if they're taking that on or not, but I'd like it.

the rv thesis is here: https://andre.arko.net/2025/08/25/rv-a-new-kind-of-ruby-mana...

Re: Gem.coop

#129

Post by davidcelis »

busterarm wrote: post #114
directionless wrote: post #64

Given some of the ways Andre Arko gets described (See https://justin.searls.co/posts/why-im-not-rushing-to-take-si... for a recent overview) I'm a little wary of what the motivation behind this is.

To take the maximally negative view of things: - uv is a cool tool, but Astral has signaled their intention to have it tie in nicely to paid services. - that's a nice moat! - Andre & friends saw that in the Python community (and uv's success) and decided they could do the same for Ruby - Their collective announces rv and now wants to make us dependent on them & friends for Ruby Gems. - After Hashicorp and others, I'm…

By "Astral" do you mean "Spinel"? Also, what paid services? So far the only paid services they've mentioned is retainer services that essentially amount to priority customer support. The tools themselves are only ever described as free

EDIT: Misread the comment and thought it was only about `rv`, not both `uv` and `rv`

Re: Gem.coop

#130

Post by ljm »

mijoharas wrote: post #68

So, ignoring everything that got us here, what do people think about this? As I see it, there is the original rubygems, which has lost all of it's maintainers, and this new one, that has most of the original active maintainers? (how many were there before? it has most of the ones I think about, but I didn't know who was active over there. I mostly saw activity from deivid and didn't know about most of the others to b…

The main page itself provides little to no info so I’m going to make a few assumptions that, to me, seem logical:

1. It must depend on RubyGems in order to stay in sync, because people publish to RubyGems.

2. It has no UI to search or view gems, so still depends on RubyGems for that.

Ignoring any question about technical detail or implementation: there is zero practical reason or motivation to switch unless I am ideologically aligned with the maintainers and their reasoning.

As such, there is zero reason to even entertain the idea of switching in a professional context. At best I’d have to care enough to remember it for personal projects.

So it is with almost any fork. It’ll either converge with the mainline after achieving its goals, take over as the new status quo, or fade into obscurity. If I don’t have any direct stake in that then I’m going to wait it out.

This isn’t to discredit or discount the work or the reasoning, of course. It arguably has a far better standing than forking Rails because of DHH.

Post reply on HN