- wgjordanVery helpful hearing about your own similar experiments with CRDTs. As a followup I'd be interested in more direct comparison between Marmot and Corrosion in terms of features/performance, since they both serve a similar use case and Corrosion seems to have worked through some of the CRDT issues you mentioned.
- Related, Corrosion has experimental support for the pgsql wire protocol (limited to sqlite-flavored SQL queries): https://superfly.github.io/corrosion/api/pg.html
- SST has not been AWS-specific since Aug 2024 [1], it is now based on Pulumi/Terraform instead of CDK/CloudFormation.
- See also a rebuttal of sorts [1] from Brett Glass, the sole programmer singled out by name in phk's essay:
> Poul-Henning's assertion that all such ideas should be dismissed as "bikeshedding" reflects this dismissive attitude, which can be just as damaging to a software project as taking too many suggestions (or accepting bad ones). At the time of the discussion I mention above, internal squabbles drove several talented programmers from the project, and I was discouraged from becoming more deeply involved in it. FreeBSD was falling behind Linux in features and in popularity. While it has now caught up in terms of technology, it remains an underdog. This is, in part, due to the developers' dismissal as "bikeshedding" of good ideas that Linux adopted much earlier.
- I think the biggest missing piece in the opposing accounts of this incident is how exactly the production-access removal was communicated. There's a huge gap between how the two posts are framing the clarity of the communications that happened on Sept 18:
> September 18 2025 18:40 UTC: Ruby Central notifies Mr. Arko, via email, of the board’s decision to remove his RubyGems.org production access, and the termination of his on-call services.
> Marty Haught sent an email to the team within minutes, at 12:47pm PDT [19:47 UTC?], saying he was (direct quote) “terribly sorry” and “I messed up”. [...] the complete silence from Shan and the board, made it impossible to tell exactly who had been authorized to take what actions. As this situation occurred, I was the primary on-call.
André also mentioned that he disclosed further remaining production access a few days ago, on Oct 5. Looking forward to Ruby Central's followup post-incident review for this subsequent incident, which they failed to address or mention at all in their initial publication.
- It's a legal requirement for most US non-profits to file public and accurate accounting of their funds and expenses, Ruby Together is no exception and all the info is publicly available [1].
Having previously worked as a software engineer at an ed-tech non-profit, I found nothing nefarious or unusual in Andre receiving compensation for his work or in the anecdotes around expensing business-related technology purchases or meals to his employer, this is all standard industry practice.
[1] https://projects.propublica.org/nonprofits/organizations/473...
- As a non-profit, the exact amount that Ruby Together paid Andre was publicly disclosed in its annual tax filings [1]:
2015: $29,250
2016: $43,988
2017: $48,143
2018: $51,058
2019: $60,000
2020: $32,693
2021: $21,420
The filings also note that "The entire board of directors reviews and approves (by vote) compensation for the CEO."
[1] https://projects.propublica.org/nonprofits/organizations/473...
- The problem is not that Searls has opinions, it's that this petty hit piece against Andre was heavily wrapped in neutral, 'all I can do is offer a little bit of context', 'I'm not rushing to take sides' framing language, resulting in a disingenuous, passive-aggressive tone.
Why is Justin dredging up that one time eight years ago when Andre mistakenly called out a repo for infringing upon his employer's work (for which he publicly apologized five hours later)? Why is he harping on anecdotes from nine years ago in order to suggest Andre may have allegedly (gasp) expensed technology purchases and business meals to his employer? What does this all have to do with the current situation, other than unnecessarily stir the pot with a laundry list of old petty grievances fed to him by a bunch of anonymous contacts ('a lot of different people told me a lot of concerning stories')?
I think the author's close ties to Rails Core / Shopify employees is extremely important context for this post, especially since it's context that's been intentionally hidden by a neutral, unbiased framing.
- Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
- It's a section titled 'The Joys of the Craft', from Chapter 1 of The Mythical Man-Month:
- My (not-a-lawyer) understanding is that a trademark is 'genericized' only when it's become so ubiquitous that its public use no longer refers to a single, unique source or origin of product, but to an entire generic class of products: escalator, granola, trampoline are some older examples of 'genericized' trademarks.
In this case, 'Bundler' still refers pretty clearly to a single brand-name utility within the Ruby ecosystem. However, the goods/services in the trademark registration application [1] covers "Downloadable computer software for managing, processing, optimizing, and organizing source code and dependencies", which is a broader class of services. The descriptive word "bundler" is quite widely used in the JavaScript ecosystem, for example, to describe this general type of dependency-management software (esbuild calls itself "An extremely fast bundler for the web", for example). I could certainly see the "Bundler" trademark being contested as a descriptive mark that hasn't acquired significant secondary meaning in that broader context, so it will be interesting to see whether this trademark application is upheld upon review (or potential opposition).
[1] https://tsdr.uspto.gov/#caseNumber=99407082&caseSearchType=U...
- Note it's not available to everyone yet:
> GPT-5 Rollout
> We are gradually rolling out GPT-5 to ensure stability during launch. Some users may not yet see GPT-5 in their account as we increase availability in stages.
- Completely agree- this is a very well-done, A1 argument I can certainly sink my teeth into.
- > The memory issue will mostly be addressed as needed
I have no allegiance to either lang ecosystem, but I think it's an overly optimistic take to consider memory safety a solved problem from a tweet about fil-c, especially considering "the performance cost is not negligible" (about 2x according to a quick search?)
- I thought the man's hand was either missing a pinky finger or had an abnormally short one.
Here's another one, this tweeted image shows either six fingers or an abnormally large middle finger: https://x.com/OpenAI/status/1904602845221187829