ioquatix (Samuel Williams) wrote:
- Companies could contact Eric and offer incentives for him to make a release.
That's not possible, https://yhbt.net/unicorn/ISSUES states: The author of unicorn must never be allowed to profit off the damage it's done to the entire Ruby world. I'm 100% banned for life from ever profitting off anything related to unicorn. "mame (Yusuke Endoh) via ruby-core" <ruby-core@ml.ruby-lang.org> wrote:
Why don't you reconsider the "nested public interface" approach?
Samuel: please do this. Ruby even has (Linux||ccan) `container_of' macro as another option: struct rb_io_private { struct rb_io { // public ABI int fd; // any other public fields in used in real-world } io_pub; // private stuff here // private fields can go above `io_pub', too }; Then only expose the `io_pub' field to public structs and access rb_io_private via ccan_container_of. But the previously discussed ways are valid C since every known platform has a stable ABI (otherwise FFI would never work) I expect there are other gems and private extensions affected by this C API change (if they survived the 1.8 -> 1.9 changes).
From the reaction to this ticket, it is clear that forcing the "hide all the details" approach could destroy the Ruby ecosystem. And there is no need to force it because you have a more moderate alternative approach.
Too bad that's already happened over the decades I've been around Ruby. Ruby lost numerous users due to a neverending stream of incompatibilities introduced every year. The only way I can maintain the legacy Ruby code I still have is to rewrite tests in a different language (e.g. Perl or POSIX sh (NOT bash)) I'm completely burned out with having to constantly deal with a never ending stream of incompatibilities over the past ~20 years. This mentality has propagated to the entire ecosystem; e.g. Rack::Chunked was deprecated and my proposed patches sent to rack-devel@googlegroups.com to maintain compatibility were completely ignored in Sep 2022. frozen_string_literal will be another major pain point, and the nagging from chilled strings won't do much to make things better (I thought that was decided against a decade ago). Finally, MFA on Rubygems is a misguided corporate attempt at security. I'm an amateur volunteer refuse to be held responsible for the security of multi-billion dollar corporations. I've never claimed any professional or academic qualifications. Nobody knows me, nobody ever will; I only show you code and that's all anybody should need for security. I'll probably end up self-hosting my own gems and only put future releases on a self-hosted server. Of course, I claim no qualifications in security or systems administration. Users are welcome to fork (and pitchfork exists) if they'd rather live under the boot of corporate rule and Terms of Service that can change at any time. I'm not going to put myself in a position where I can't contribute to code I still depend on. I'm already effectively banned from 99.9% of projects due to draconian corporate terms of service and high HW requirements.