[ruby-core:117298] Re: [Ruby master Feature#19057] Hide implementation of `rb_io_t`.

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" <[e-mail]> 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 [e-mail] 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.
 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/