Michael G

I released Superview 1.0 and wrote at https://terminalwire.com/articles/superview about how can use it to render Phlex and ViewComponents for your Rails controller views. ✌️

The JRuby community is pleased to announce the release of JRuby 9.4.11.0.

• Homepage: https://www.jruby.org/
• Download: https://www.jruby.org/download

JRuby 9.4.11.x targets Ruby 3.1 compatibility. This release fixes two critical bugs in JRuby 9.4.10.0 and we recommend users skip that version when upgrading.

Thank you to our contributors this release, you help keep JRuby moving forward!

• Karol Bucek @kares

Critical Fixes

• Fixed an issue where Mutex lock acquisition may leave the Mutex locked if an asynchronous Thread interrupt happens at the same time. #8585, #8586
• Fixed a memory leak where singleton classes would leave behind bookkeeping objects that accumulated over time. #8591, #8598

Standard Library

• rubygems been updated to version 3.6.3 to fix an incompatibility with bundler 2.6. #8590, #8596
• bundler has been updated to version 2.6.3. #8596
• jruby-openssl has been updated to 0.15.3. #8458, Release 0.15.3
• jar-dependencies has been updated to 0.5.3 to fix remaining issues loading Maven jars in containerized environments. #8593, #8595

9 Issues and PRs resolved for 9.4.11.0

• #8458 [deps] bump jruby-openssl to 0.15.3
• #8584 Remove dependency on jakarta.annotation-api
• #8585 Thread interrupt can leave Mutex locked in synchronize
• #8586 Unlock if poll triggers an exception
• #8590 Bundler v2.6.x is incomptible with Gem system version included in JRuby 9.4.10.0 by default
• #8591 Eliminate leak of non-concrete subclass references
• #8593 Cannot create a Rails app with JRuby 9.4.10.0, Rails 7.1.5.1
• #8595 Update jar-dependencies to 0.5.3
• #8596 Update rubygems to 3.6.3 and bundler to 2.6.3
• #8598 Memory leak from ActiveRecord_Relation after upgrading from JRuby 9.4.9.0 to 9.4.10.0

As an online discussion grows longer, the probability of a someone mentioning macOS is a UNIX approaches 1. In fact, it was only late last year that The Open Group announced that macOS 15.0 was, once again, certified as UNIX, continuing Apple’s long-standing tradition of certifying macOS releases as “real” UNIX®. What does any of this actually, mean, though? Well, it turns out that if you actually dive into Apple’s conformance statements for macOS’ UNIX certification, it doesn’t really mean anything at all. First and foremost, we have to understand what UNIX certification really means. In order to be allowed to use the UNIX trademark, your operating system needs to comply with the Single UNIX Specification (SUS), which specifies programming interfaces for C, a command-line shell, and user commands, more or less identical to POSIX, as well as the X/Open Curses specification. The latest version is SUS version 4, originally published in 2008, with amendments published in 2013 and 2016, which were rolled up into version 4 in 2018. The various versions of the SUS that exist, in turn, correspond to a specific UNIX trademark. In table form: Trademark SUS version SUS published in: SUS last amended in: UNIX® 93 n.a. n.a. n.a. UNIX® 95 Version 1 1994 n.a. UNIX® 98 Version 2 1997 n.a. UNIX® 03 Version 3 2002 2004 UNIX® V7 Version 4 2008 2016 (2018 for roll-up) When you read that macOS is a certified UNIX, which of these versions and trademarks do you assume macOS complies with? You’d assume they would just target the latest trademark and SUS version, right? This would allow macOS to carry the UNIX® V7 trademark, because they would conform to version 4 of the SUS, which dates to 2016. The real answer is that macOS 15.0 only conforms to version 3 of the SUS, which dates all the way back to the ancient times of 2004, and as such, macOS is only UNIX® 03 (on both Intel and ARM). However, you can argue this is just semantics, since it’s not like UNIX and POSIX are very inclined to change. So now, like the UNIX nerd that you are, you want to see all this for yourself. You use macOS, safe in the knowledge that unlike those peasants using Linux or one of the BSDs, you’re using a real UNIX®. So you can just download all the tests suites (if you can afford them, but that’s a whole different can of worms) and run them, replicating Apple’s compliance testing, seeing for yourself, on your own macOS 15 installation, that macOS 15 is a real UNIX®, right? Well, no, you can’t, because the version of macOS 15 Apple certifies is not the version that’s running on everyone’s supported Macs. To gain its much-vaunted UNIX certification for macOS, Apple cheats. A lot. The various documents Apple needs to submit to The Open Group as part of the UNIX certification process are freely available, and mostly it’s a lot of very technical questions about various very specific aspects of macOS’ UNIX and POSIX compliance few of us would be able to corroborate without extensive research and in-depth knowledge of macOS, UNIX, and POSIX. However, at the end of every one of these Conformance Statements, there’s a text field where the applicant can write down “additional, explanatory material that was provided by the vendor”, and it’s in these appendices where we can see just how much Apple has to cheat to ensure macOS passes the various UNIX® 03 certification tests. In the first of these four documents, Internationalised System Calls and Libraries Extended V3, Apple’s “additional, explanatory material” reads as follows: Question 27: By default, core file generation is not enabled. To enable core file generation, you can issue this command: sudo launchctl limit core unlimited Testing Environment Addendum: macOS version 15.0 Sequoia, like previous versions, includes an additional security mechanism known as System Integrity Protection (SIP). This security policy applies to every running process, including privileged code and code that runs out of the sandbox. The policy extends additional protections to components on disk and at run-time, only allowing system binaries to be modified by the system installer and software updates. Code injection and runtime attachments to system binaries are no longer permitted. To run the VSX conformance test suite we first disable SIP as follows: – Shut down the system.– Press and hold the power button. Keep holding it while you see the Apple logo and the message “Continue holding for startup options”– Release the power button when you see “Loading startup options”– Choose “Options” and click “Continue”– Select an administrator account and enter its password.– From the Utilities menu in the Menu Bar, select Terminal.– At the prompt, issue the following command: “csrutil disable”– You should see a message that SIP is disabled. From the Apple menu, select “Restart”. By default, macOS coalesces timeouts that are scheduled to occur within 5 seconds of each other. This can randomly cause some sleep calls to sleep for different times than requested (which affects tests of file access times) so we disable this coalescing when testing. To disable timeout coalescing issue this command: sudo sysctl -w kern.timer.coalescing_enabled=0 By default there is no root user. We enable the root user for testing using the following series of steps:– Launch the Directory Utility by pressing Command and Space, and then typing “Directory Utility”– Click the Lock icon in Directory Utility and authenticate by entering an Administrator username and password.– From the Menu Bar in Directory Utility:– Choose Edit -> Enable Root User. Then enter a password for the root user, and confirm it.– Note: If you choose, you can later Disable Root User via the same menu. ↫ Apple’s appendix to Internationalised System Calls and Libraries Extended V3 The second conformance statement, Commands and Utilities V4, has another appendix, and it’s a real doozy (the indicate repeat remarks from the previous appendix; I’ve removed them for brevity): Testing Environment Addendum: The third and fourth conformance statements have