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

@netbsd I know the feeling… 8-)

Today I learned (re-learned?) that jmp_buf and sigjmp_buf are the same size in GNU libc on Linux, but vastly different sizes in the #Solaris libc:

https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/issues/228

(Fortunately we no longer ship this driver in #OracleSolaris, so this is just academic interest to me, not a bug I need to patch.)

Nice, since the #Solaris <rpc/auth.h> declares user2netname() as taking a 'char [MAXNETNAMELEN + 1]' argument, gcc 13 complains if you pass a 'char [MAXNETNAMELEN]' to it:

https://gitlab.freedesktop.org/xorg/app/xhost/-/merge_requests/7

Twenty years (plus a few weeks) already?

https://lwn.net/Articles/79302/ - "7 Apr 2004 - X.Org Foundation Announces Formation and First Release"

Soon @XOrgFoundation will be old enough to drink in the US...

When Casper was designing the rough equivalent in #Solaris, the least privilege system, he tried to prevent this. For instance, PRIV_FILE_DAC_WRITE won’t let you write to a file owned by UID 0 unless your euid is 0 or you already have all privileges (equivalent to root access).
https://mastodon.social/@vegard/112365131001894332

As the maintainer of the xf86-input-mouse driver for Xorg, I promise to never add any LLM/AI prompt generator code to our mouse driver.
https://mstdn.social/@osnews/112322994452930780

@flameeyes it doesn't look like anyone ever suggested the Austin Group add strcasestr to the standard, so I went ahead and did that now:
https://austingroupbugs.net/view.php?id=1818

Of course, they're busy finalizing the POSIX.1-202x / UnixV8 / XPG8 revision right now, so it would be years before this could make the version after that.

So the maintainer of our GNU emacs packages for #OracleSolaris was testing the upgrade to version 29, and asked me why every time he displayed emacs from a SPARC server to his x86 desktop, the X server crashed.

He filed a bug with upstream for it:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69762

but it turns out it was Xorg upstream where the bug really was, and it was actually a security vulnerability in the byte-swapping code, which we announced today:
https://lists.x.org/archives/xorg-announce/2024-April/003497.html

@rst @dalias @leftpaddotpy @raito if you don’t trust the maintainer, then you simply cannot use the software, whether it uses autotools or not, but generating the files doesn’t stop the maintainer from putting malicious stuff in configure.ac, Makefile.am, or one of the .m4 files that generates the shell scripts and commands run to build.

@josephholsten @dalias and that check fails in the autoconf world unless the files are generated by the build automation, as they'll differ depending on the build environment used to generate them. (Yes, autoconf is not the system we'd design today, it's one that was designed decades ago for a different world.)

@rst @leftpaddotpy @raito @dalias except that won't work as there will be differences in the generated files unless you have the exact same versions of autoconf, automake, libtool, and every package that delivers its own m4 macros into /usr/share/aclocal.

@dalias autoconf complicates this by putting generated files in release tarballs that aren’t in git, and which won’t match the versions you generate locally unless you use the exact same versions of autoconf, auto make, libtool, and all associated macros, as the xz hack made clear. Other build systems (like meson) that don’t need you to distribute files that aren’t in git will simplify this.

@dalias as one of the primary maintainers of the ~260 X.Org packages, I think our existing plan to port them to meson so the tarball contents are the git checkout without generated files is going to be easier than modifying our processes to check in the autoconf output (which we'd probably want to do in the CI pipeline so it doesn't keep changing depending on the distro/version used by each contributor).

SPARC & x64 machines running #OracleSolaris 11.4 SRU's have been added to the GNU Compile Farm for use by FOSS developers: https://portal.cfarm.net/news/50#

Thanks to the Center for Biotechnology (CeBiTec) at Bielefeld University in Germany for setting up and hosting these machines. The R740 is a donation from de.NBI Cloud Bielefeld, while the T8-1 is a permanent loan from Oracle Corporation.

@jperkin we ship gccgo in Solaris because it has a SPARC backend while Google’s go compiler does not, but that shouldn’t matter for illumos (except for the SPARC forks of Tribblix & OpenIndiana).

@lanodan @unixben @PCOWandre X.Org Foundation since January 2004. XFree86 ran in parallel to the industry consortiums before that (and for a short time later, but pretty much everyone moved from XFree86 to Xorg in 2004/2005 timefram and XFree86 was basically dead by 2008).

Belated 20th birthday cheers to @XOrgFoundation -- founded in January 2004:

https://en.wikipedia.org/wiki/X.Org_Foundation

@PCOWandre @unixben or one of the other predecessor orgs?

1984-1988 MIT Project Athena
1988-1993 The MIT X Consortium
1993-1996 The X Consortium
1997-1998 The Open Group X Project Team
1998-2003 The X.Org Group

The X Window System itself turns 40 in June 2024.

@lanodan yeah, but linux 10.x probably almost a decade away still, since Linux tends to go a few years between major version bumps.

But then seeing how many things broke from the zlib 1.2.x -> 1.3 version change doesn't leave me with a lot of hope that everyone will be prepared in time, and of course our experience when Solaris 10 changed uname to 5.10 might have left a few scars...

@lanodan yeah, gcc's annual version bump hasn't pushed things as high as Firefox's new major version every 6 weeks scheme, but is still far faster than things went in the gcc 2.x and 3.x eras