Notices by Alan Coopersmith (alanc@fosstodon.org), page 3

@guenther @brynet we've shipped O_CLOFORK support since Solaris 11.3. I'm not sure how it handles the case of CLOFORK without CLOEXEC though. @jlevon did the original implementation back in 2014, and Casper Dik updated it in 2020 once the standard committee decided to adopt it.

I believe AIX & MacOS had implemented before we did, as had a proposed patch for Linux that wasn't accepted at the time.

@lanodan certainly the GNU libc maintainers could add attribute(warn_unused_result) to the asprintf prototype in their header files if they want to insist on this.

As @solardiz noted in the followup post at https://www.openwall.com/lists/oss-security/2024/07/26/2 the standard unfortunately allowed the GNU libc behavior of not guaranteeing the pointer would be NULL on failure, requiring users to check the return value, despite all the known non-GNU implementations guaranteeing to set it to NULL on failure, meaning that even though the standard requires asprintf() be provided, portable software still has to be aware of the different implementations.

In https://www.openwall.com/lists/oss-security/2024/07/26/1 I commented:

"Note that asprintf() and vasprintf() are part of the POSIX.1-2024 standard which was officially published last month, so these are no longer system-specific extensions:

https://pubs.opengroup.org/onlinepubs/9799919799/functions/asprintf.html
https://pubs.opengroup.org/onlinepubs/9799919799/functions/vasprintf.html

though they are not yet part of the C standard itself."

To ask the #POSIX committee to add them, I just had to submit https://austingroupbugs.net/view.php?id=1496

I wish it was that easy to ask the C committee, instead of having to write a paper for it.

@stf @adulau The Open Group announced the availability of their version today:
https://www.mail-archive.com/austin-group-l@opengroup.org/msg12754.html

@drscriptt not at the moment. We’d looked at it many years ago and determined we’d have to implement a bunch more kernel APIs that Linux has, but any real chance died out when the project to port DRI/KMS drivers to the Solaris kernel was ended.

https://blog.dshr.org/2024/07/x-window-system-at-40.html - David Rosenthal remembers his early work at Sun on NeWS and porting X to Sun workstations, and explains why he thinks X11 won out over NeWS, and why Wayland is now displacing X11.

@stf @adulau fortunately, the POSIX standard is jointly developed with The Open Group, who publishes their version online for free, and have said the new release should be available on their website next month, so unless you need the version with the IEEE logo/legal text you won’t have to pay $700 for that one.

@jperkin @ptribble fortunately, Solaris 11.4 has made both _REENTRANT & _XOPEN_SOURCE=700 the default, so you don't need to define them any more, given all the pain caused on older OS versions.

@jperkin @ptribble yeah, you have to define __EXTENSIONS__ if you define _XOPEN_SOURCE to avoid breaking everything that depends on some function outside what the specified standard included. The change in the 11.4 headers to make the default the latest standard without specifying _XOPEN_SOURCE avoided that pitfall.

(The copy in Oracle's bug database, migrated from Sun's bug database, still shows the correct attribution, but that's not visible externally. The external copy from the OpenSolaris bug database at https://illumos.org/opensolaris/bugdb/bug.html#!4794472 also strips attribution info.)

I gave a presentation this morning on how we're doing on making Solaris ready for Y2038, and made my usual joke about how since I turn 65 in 2038, I'll be set up for a nice consulting gig when I retire, helping everyone who waited until the last minute to handle it.

This afternoon I remembered I'd be able to claim over 35 years experience with the Y2038 problem by then, thanks to https://bugzilla.gnome.org/show_bug.cgi?id=101538 but unfortunately the bug gateway it was filed through stripped the info showing I filed it.

@vab @ptribble it's an unintended fallout of our moving all the binaries from /usr/ccs/bin to /usr/bin and making /usr/ccs/bin a symlink to /usr/bin - we can't formulate a $PATH that finds Solaris strip ahead of GNU strip, but all the other GNU commands ahead of the Solaris equivalents.

@vab @ptribble it's intentional, not a bug. It was removed because GNU strip often corrupts Solaris binaries, and many times when we build other FOSS we set /usr/gnu/bin first in the path (because they expect GNU grep,msgfmt, xgettext, etc. when building), and would then get bad binaries when they called strip and found GNU strip instead of Solaris strip.

Today we've released #OracleSolaris 11.4.69, our quarterly feature update. The announcement is at https://blogs.oracle.com/solaris/post/announcing-oracle-solaris-114-sru69 and lists the new features and software upgrades included. A big chunk of the software upgrades are part of our work to upgrade GNOME from 41 to 45.

The autofs SMF service in #OracleSolaris 11.4.69 has added support for reloading automount maps on a periodic basis, so when you update the map on your LDAP server you don't need to manually run automount on all the clients to get the new maps. You can also run "svcadm refresh" now to force a manual reload.

In #OracleSolaris 11.4.69, the default/etc/ssh/sshd_config file has added "Include /etc/ssh/sshd_config.d/*.conf" so you can just drop new config fragments in that directory via IPS/ansible/puppet/etc. instead of having to edit the existing configs. The equivalent was also done for the ssh_config file, if you need to do things like enable old algorithms to ssh to hosts running older ssh versions.

Like many other OS distros, we've adopted the mechanism from PEP 668 <https://peps.python.org/pep-0668/> in #OracleSolaris 11.4.69 to keep the system python packages isolated from changes installed by users via pip. We've also started bundling pipx to make it easier to install python applications to virtual environments. https://blogs.oracle.com/solaris/post/python-package-management-going-forward explains more about this.

The ps command in #OracleSolaris 11.4.69 now accepts the -I flag to display the start time ("STIME") column in an ISO 8601 format. Alternatively, the sitime keyword can be passed to the -o option to specify a start time in an ISO 8601 format.

@cks sadly, after nearly 4 decades we're still fixing issues around NumLock handling even in the software from @XOrgFoundation itself:
https://gitlab.freedesktop.org/xorg/app/xcalc/-/merge_requests/11