> Ruby Central’s actions during this period were taken in response to a breakdown in a working relationship with an individual who had significant access to infrastructure and code
> [...]
> At the time, we believed a serious risk had been introduced to RubyGems and related services.
> [...]
> The review was ultimately inconclusive because key logs required for a complete analysis were no longer available. We recognize that this creates continued uncertainty.
So, after all that finger wagging and posturing around how the new RC regime was right to oust the previous maintainers, it turns out none of their justifications had any basis in fact? In all honestly this has just been one rake-step after another and I can't imagine how anyone could continue to be confident in their decision making.
Perhaps gem.coop might win out just by virtue of not putting themselves in these positions unnecessarily.
It's the most popular event for speedrunning and has raised millions of dollars each year for over a decade. Sounds like they're doing just fine as is and, perhaps, fostering an inclusive environment which explicitly protects people demonized by society at large has only helped, not hurt.
Without more details, it's hard for me to nail down the exact motivations at play here.
My current read is that RC majorly botched the takeover, demonstrated gaps in security know-how, and then retroactively framed everything as a problem with André. The details of the logs are mostly immaterial to the rest of the claims, but are still suspicious enough to spice up the announcement. I believe this because, at the moment, I don't see anything in the original RC post that wasn't satisfactorily explained by this post.
I am definitely not affiliated with either, moreso my opinion is considerably more negative of the new maintainers (both for the method of takeover and their handling of this incident). Quite frankly, I don't even know why you would even ask if I was.
I do not feel like I'm reading between any lines here-- Ruby Central directly showed that André Arko asked for the data to sell in order to cover the on-call fees. Yes, they have reason to smear him and shouldn't be trusted, but André confirms that he asked for the logs. None of that is up for debate, these are just the facts!
What we can argue about is 1) whether this is meaningfully different than what RC does already as noted by their ToS and 2) whether or not company names derived from the HTTP logs is sensitive or whatever. It is my position that neither André nor RC should be selling this sort of usage data, regardless of motivation. Personally I think the monetization of such data is bad in general, but I understand not everyone feels the same. It just gives me the ick.
EDIT: Immediately after submitting this, I saw that you issued a correction. Bad timing on my part I suppose!
No but he was seeking it, from the email in the RubyCentral article and directly from TFA:
> I have no interest in any PII, commercially or otherwise. As my private email published by Ruby Central demonstrates, my entire proposal was based solely on company-level information, with no information about individuals included in any way.
Here Andre is downplaying his ask of the logs. Even if Andre didn't get them, the logs were desired. Had Ruby Central acquiesced the logs would've been parsed and sold. Might not be an issue for you but I am frankly not interested in having any data shared or sold like this.
One of the primary justifications given for the takeover was to secure the gems service and offer trustworthy stewardship. Reading this, I don't really get the sense that the new maintainers are really prepared to deliver on either.
That said, I really don't like the hand waving of the HTTP log thing in this post. Yeah sure, company names aren't as sensitive/radioactive as an SSN or an email, but selling usage data isn't exactly a noble endeavor.
I don't think anyone comes out of this looking good. Some are worse than others, sure, but this is just a mess from top to bottom.
Except the largest Mastodon instance, mastodon.social, does federate with Threads. I'm not even sure if the list you provided even covers most of the top instances either.
It really feels like an "eating your cake and having it too" kinda situation: you get the engagement and interaction with millions of Threads users but you don't have to count them in your decentralization metrics.
> No offense, but some people requirements are really, really low.
I think you kinda hit the nail on the head, but I believe there is an extra dimension to this: desire.
For BG3, it looked fun and I had good memories of BG2 so I was interested in playing it. After tuning the settings a bunch and not being able to get a consistent framerate / not have micro-freezing, I just said "oh well, I'll play it on some other platform in the future." I cared about BG3, but not that much.
This is in contrast to Elden Ring Nightreign, which also had issues. I was able to get it to a somewhat stable 30FPS and celebrated that success before dumping 100+ hours into the game. Why? Well, because I love FromSoft games! I really really really wanted to play the game and was willing to put up with a somewhat subpar experience in order to get it. BG3, among other games, is just not that exciting for me personally so my tolerance of technical hitches is very different.
... which brings us right back to this native release. Hopefully the improvements we see are enough to get me over that "hill" and actually enjoying the game. I have the update queued on my deck now so I can try it out after work.
I had tried to run BG3 on my Steam Deck a couple months back. It ran... okay. Lot's of hitches and I had to tune things way way way down, but somewhat playable.
I'm very grateful that they took the time to build a native Steam Deck release for the game, not really something I had ever expected. Hopefully with this I can actually jump in and enjoy the game!
> it has obvious limitations (and generally it can be called unsound, especially around thread locals)
Is this really better than what we have now? I don't think async is perfect, but I can see what tradeoffs they are currently making and how they plan to address most if not all of them. "General" unsoundness seems like a rather large downside.
> In future I plan to create a custom "green-thread" fork of `std` to ease limitations a bit
Can you go more in-depth into these limitations and which would be alleviated by having first class support for your approach in the compiler/std?
Part of me also wonders if people may agree that its better simply because they don't actually have to do the summarization anymore. Even if it is worse by some %, that is an annoying task you are no longer responsible for; if anything goes wrong down the line, "ah the AI must've screwed up" is your way out.
Amusingly, selecting Bay Ridge in Brooklyn also seems to select Westerleigh in Staten Island; I know Bay Ridge shares a congressional district with Staten Island, but I assure you we're still a part of Brooklyn.