The NetHack DevTeam is announcing the release of NetHack 5.0.0 on May 2, 2026
https://nethack.org/v500/release.html
NetHack 5.0 is an enhancement to the dungeon exploration game NetHack, which is a distant descendent of Rogue and Hack, and a direct descendent of NetHack 3.6.
NetHack 5.0.0 is a release of NetHack. As a .0 version, there may be some bugs encountered. Constructive suggestions, GitHub pull requests, and bug reports are all welcome and encouraged.
Along with the game improvements and bug fixes, NetHack 5.0 strives to make some general architectural improvements to the game or to its building process. Among them, 5.0:
- Has its source code compliant with the C99 standard.
- Removes barriers to building NetHack on one platform and operating system, for later execution on another (possibly quite different) platform and/or operating system. That capability is generally known as "cross-compiling." See the file "Cross-compiling" in the top-level folder for more information on that.
- The build-time "yacc and lex"-based level compiler, the "yacc and lex"-based dungeon compiler, and the quest text file processing previously done by NetHack's "makedefs" utility, have been replaced with Lua text alternatives that are loaded and processed by the game during play.A list of over 3100 fixes and changes can be found in the game's sources in the file doc/fixes5-0-0.txt. The text in there was written for the development team's own use and is provided "as is". Some entries might be considered "spoilers", particularly in the "new features" section.
VideoLAN Releases dav2d 0.0.1 as Early Preview AV2 Decoder
VideoLAN, the organization behind VLC media player, has released dav2d 0.0.1 "Merbanan," the first public preview of its AV2 decoder and successor to the widely used dav1d AV1 decoder.
VideoLAN president and lead VLC developer Jean-Baptiste Kempf prepared the release, describing it as "a very early preview release of an AV2 decoder."
AV2 is the planned successor to AV1, the royalty-free video codec developed by the Alliance for Open Media. Earlier this year, AOMedia released a draft AV2 specification for public review after several years of development. The codec remains in the standardization process, so dav2d is an early implementation rather than production-ready software.
The new decoder builds on the approach established by dav1d, VideoLAN's AV1 decoder developed with the FFmpeg community, which played a key role in AV1 adoption by offering a fast, cross-platform software decoder while hardware support was still expanding.
dav2d is intended to serve a similar role for AV2, though it remains in the early stages of development. The decoder is CPU-based, cross-platform, and built on dav1d, with ongoing work on the C implementation, API, platform support, and architecture-specific optimizations.
Last but not least, VideoLAN has not announced when dav2d will be integrated into a stable VLC release, but that certainly won't happen anytime soon. At the moment, it only lays the groundwork for future playback support in open-source multimedia software as the codec and ecosystem mature.
dav2d 0.0.1 is available through VideoLAN's official GitLab repository.
FreeBSD 15.1 Beta Released For Early Testing
https://www.phoronix.com/news/FreeBSD-15.1-Beta-1
Following last year's release of FreeBSD 15.0, FreeBSD 15.1 is working its way toward release release in June. For kicking off the release dance, FreeBSD 15.1 Beta 1 is available today for testing.
FreeBSD 15.1 pulls in a number of driver updates, including for better hardware support and the various WiFi driver enhancements that have been pursued as of late along with working toward better power management. As of writing, the 15.1 release notes have yet to begin to be filled out for fully documenting the many changes being made for FreeBSD 15.1.
One of the changes I was excited to see with FreeBSD 15.1 was the new KDE Plasma desktop install option from within their existing CLI installer. This has been part of the effort to enhance the laptop/desktop experience for FreeBSD. Surprisingly though when firing up the FreeBSD 15.1 Beta 1 AMD64 install media this morning, the KDE Plasma desktop option was not presented in any of the installer interfaces.
So unfortunately that KDE Plasma desktop option seems to have not made it unless it's otherwise being restricted to certain detected hardware/software state or other limitations. In any event those wanting to try out the FreeBSD 15.1 Beta 1 release can find the download information via the mailing list announcement.
From here there are weekly betas expected until the end of May when the release candidate happens and then if all goes well FreeBSD 15.1-RELEASE will be out on 2 June.
Original Submission #1 Original Submission #2 Original Submission #3
(Score: 3, Interesting) by bzipitidoo on Wednesday May 06, @03:09AM (2 children)
Wonder how much of an improvement AV2 is, or will be, over AV1. From what I've seen, AV1 can match MPEG4 quality with very roughly half the size. Is AV2 going to be half again? If yes, how did they do it?
Some improvements in data compression come from simply making use of the much greater speed and memory of current computers vs the computers of 30 years ago. bzip2, for instance, uses a paltry 900k as its maximum block size, and the main reason for that was to accommodate computers that had no more than 8M RAM. 7-zip can compress in the gzip format better than gzip itself because it spends more compute time checking variations. Do that much checking on late 1980s computers, and you'll make the compression process unacceptably slow. It is especially bad for improvements that take hundreds of megabytes, even gigabytes, of RAM. An early 1990s machine with only 16M RAM and 100M hard drive can't do that at all, just doesn't have the capacity.
(Score: 2) by Bentonite on Friday May 08, @09:25AM (1 child)
I checked and with compression level 9 and with a few files, it takes more than twice as long to compress, with a negligible improvement.
But for example, an easy to compress file from supertuxkart; 482K thaidict.txt
time 7z -mx9 a thaidict-7zip.gz thaidict.txt
real 0m0.481s
93K thaidict-7zip.gz
time gzip -9 thaidict.txt
real 0m0.166s
105K thaidict.txt.gz
If you have 1000 files to compress, do you really want to wait twice as long over ~10MiB of space?
gzip also seems to decompress twice as fast;
time 7z x thaidict-7zip.gz
real 0m0.011s
time gzip -d thaidict-7zip.gz
real 0m0.004s
time 7z x thaidict.gz
real 0m0.011s
time gzip -d thaidict.gz
real 0m0.003s
(Score: 2) by bzipitidoo on Monday May 11, @05:04AM
It can be worth it. Depends on how frequently some data will be decompressed vs compressed. If it is some popular file that will be downloaded and decompressed hundreds of times or more, then it is worth spending twice as much time to compress the one time it takes to produce the compressed version. This hunting does not affect decompression time, only compression time.
The main purpose of AV1 is to reduce the bandwidth needs and expenses of these giant social media organizations.
(Score: 2) by VLM on Wednesday May 06, @04:54PM (1 child)
That news kind of sucks because there's no native compilers on the PDP-11 for C99. You can cross compile using GNU C and that can eat C99 and output pdp11 aout files but thats not "real" retrocomputing.
So sadly you won't be running this on a PDP-11 or a VAX or any cool old iron either at all, or only cheating at best.
"In the old days" a lot of or at least some nethack work was done on openVMS. Like in the version 3 era.
I think the last version of OpenBSD released for the vax did not contain a C compiler that's C99 compatible (like OpenBSD 5 ish era)
Off the top of my head I can't think of a realistic way to run Nethack 5 on retro hardware.
C99 doesn't give you that much. Variable length arrays. Some stuff like snprintf() becomes required standard in C99 not optional (its sprintf with a character processing limit so you don't bust your buffers, optimistically, likewise you can guess why strncpy is better than strcpy)
(Score: 2) by VLM on Wednesday May 06, @05:03PM
If you're bored and want to give your cybersecuritytheater people a heart attack, start using strncpy in your code, assuming preC99 code, and implement your homemade version something like
char *strncpy(char *dest, const char *src, size_t n) {
strcpy(*dest, *src);
return;
}
I wouldn't do that at a place you want to continue being employed at but its funny to look at.
You're supposed to do strncpy for real with a for loop and add null padding at the end afterwards after carefully checking lengths etc. But my above code is much funnier. I suppose in the era of C99 everywhere its no longer a relevant joke, oh well.