Dedup on home server done. The below deduped data is from all free and purchased games from online:
root@freenas:~ # zdb -U /data/zfs/zpool.cache -DD FreeNAS
DDT-sha256-zap-duplicate: 89663715 entries, size 577 on disk, 186 in core
DDT-sha256-zap-unique: 110825983 entries, size 545 on disk, 176 in core

DDT histogram (aggregated over all DDTs):

bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 106M 13.1T 11.4T 11.6T 106M 13.1T 11.4T 11.6T
2 61.9M 7.59T 6.65T 6.74T 136M 16.6T 14.5T 14.7T
4 19.9M 2.44T 2.17T 2.19T 94.5M 11.6T 10.3T 10.4T
8 3.31M 408G 332G 340G 31.4M 3.78T 3.09T 3.15T
16 293K 31.0G 22.6G 23.7G 6.12M 659G 482G 507G
32 107K 9.71G 7.20G 7.70G 4.67M 420G 306G 330G
64 16.1K 1.70G 1.18G 1.25G 1.28M 138G 94.8G 100G
128 2.31K 226M 86.1M 101M 388K 37.2G 13.1G 15.6G
256 1.57K 189M 117M 123M 618K 73.1G 48.1G 50.1G
512 310 29.0M 1.94M 4.43M 219K 20.1G 1.35G 3.11G
1K 122 13.4M 452K 1.40M 172K 18.9G 634M 1.97G
2K 64 7.25M 235K 744K 181K 20.7G 670M 2.05G
4K 41 4.01M 136K 477K 222K 21.8G 735M 2.52G
8K 10 770K 26.5K 116K 114K 9.23G 321M 1.30G
16K 4 512K 16K 46.5K 74.0K 9.24G 296M 860M
32K 4 512K 16K 45.5K 156K 19.5G 623M 1.77G
Total 191M 23.6T 20.6T 20.9T 381M 46.5T 40.2T 40.8T
dedup = 1.96, compress = 1.16, copies = 1.01, dedup * compress / copies = 2.23

105GB used by my dedupe special vdev

Recovered 22.9TB thanks to dedupe. Free space before 5TB, Free space now 16TB. I've also now moved my game VM games from a seperate SSD to the raidz3. (6.4 TB) and setup my Linux VM and game drive for that (1.5TB). Steam on the Linux VM is updating now and catching up since I haven't been able to do for months since downloading Steam games on Linux over samba has been broken for months.

Working on getting my Synology NAS synced with these changes now.

Dogsitting for 10 days so don't have my equipment for testing but I am buying parts and working on deciding on how I want TrueNAS set up on three of my QNAP NAS for offsite backups.

For my TS-670 just use a Samsung Fit plugged into the USB3 port instead of the onboard USB2 header, decided NOT to use a M.2 USB enclosure connected to the USB2 header but instead to use 2x M.2 in a M.2 pcie adapter for the system dataset (it's overkill but oh well). Decided not to use a combine 10GBE w/ M.2 card in this machine since likely not much of a speed benefit for 10GB since transferring from HDs. Also replace the fans with Noctua 92mm fans. The latest TrueNAS 13 installed fine on the TS-670.

For my TVS-671 since it has 2x PCIe then keeping the 10GBE card, adding a M.2 card with 2x M.2 and the Samsung Fit plugged into the USB3. Also replace the fans with Noctua 92mm fans.

For my QNAP TVS-872XT I think I've decided to switch from Quts Hero to TrueNAS and as such I'll boot TrueNAS from the onboard 2x M.2 and also use it for system dataset, use a M.2 card for DDT for dedupe, I already upgraded the memory to 64gb and if I need to upgrade the processor for dedupe then I'll do that but likely won't be needed since it's just for backup purposes.

Once I've got the above done then need to update the TrueNAS thread.

Things like this just keep me a github lurker at most. Any browser that is not a current version of the big four* is having trouble with github again.
"The reason GitHub doesn't work anymore as of the past few weeks is because of nullish coalescing and optional chaining. Unlike everything else, these can't be polyfilled"
https://msfn.org/board/topic/183751-github-an … comment-1222344

*I figure: Chrome, Firefox, Safari, Edge.

Think really what it comes down to is there needs to be working web browsers for older platforms and dropping support needs to be recognized by these sites since supporting things which are not the latest and greatest can provide great benefits through edge cases and/or performance optimization but obviously that is hard to quantify so mabye we need some powerpoint to get the point across.

If one guy can get almost single handedly keep palemoon working on XP and supporting modern browsing and another can port Chrome to OS/2 and others can code Chrome to work on XP and another can program a proxy for older browsers to access modern sites then it shouldn't be very difficult for those systems to still be supported instead of support being dropped so that yet even more people and systems can be purposely ignored.

Github is nothing special the equivalent can be spun up elsewhere but there wouldn't be anyone on it and there would be no funding and even if there were most projects that were forked to it that were updated to work likely wouldn't be accepted by the source. Mabye something could be looked into with Archive.org to setup a github equivalent for preservation, maintaining and updating code. Hostile to compatiblity source project or website wouldn't have a say as long as the license was followed.

If only I won the lottery I'd put a percentage towards that heh.

can confirm github browser breakage is terrible for software development. I especially had trouble getting in that auth thing they now mandate after a year to push at all....

One can be a smart-ass and suggest Gitlab and Bitbucket, but they do surprise browser regressions too!

To put it in context, I was a bit torn between different perspectives. On one hand I am considering to nag github support about it, on the other hand; last time I did something like that, I felt like a fool for even trying. On one hand it is good to see a surprising amount of retro-computing projects progressing there, on the other hand I considered github a lost cause since microsoft bought it

DosFreak wrote on 2022-07-19, 23:02:

Think really what it comes down to is there needs to be working web browsers for older platforms and dropping support needs to be recognized by these sites since supporting things which are not the latest and greatest can provide great benefits through edge cases and/or performance optimization but obviously that is hard to quantify so mabye we need some powerpoint to get the point across.

I thought html5 was supposed to do away with a lot of those browser specific javascript tricks of the past, and to get a more desirable web-interfacing standard. As in; documented, open, non-profit, less-malware vulnerable, testable, etc.

DosFreak wrote on 2022-07-19, 23:02:

If one guy can get almost single handedly keep palemoon working on XP and supporting modern browsing and another can port Chrome to OS/2 and others can code Chrome to work on XP and another can program a proxy for older browsers to access modern sites then it shouldn't be very difficult for those systems to still be supported instead of support being dropped so that yet even more people and systems can be purposely ignored.

Fortunately projects like palemoon/newmoon can do more then just polyfill with addons. And so far the people involved did a tremendous job, like you said. The guy I quoted before meant it in the context of preferring to use an older version of Firefox/Chrome, in which case he can only toy with polyfill addons, as the main browser will remain what it is.

leileilol wrote on 2022-07-20, 01:53:

can confirm github browser breakage is terrible for software development. I especially had trouble getting in that auth thing they now mandate after a year to push at all....
One can be a smart-ass and suggest Gitlab and Bitbucket, but they do surprise browser regressions too!

Nasty. Did not know they had such checks.
Yes I remember Gitlab having the same issues as github, also leading to polyfill workarounds to get it going again. Since then about everything seemingly transferred to github, for other reasons I don't know much about.

Did some testing and looks like this is the latest working version of eduke32 for Vista, 7 and 8.

eduke32_win32_20211006-9651-a891732fd ( < OpenGL 2.0)
eduke32_win32_20211112-9782-661883a52 (> OpenGL 2.0)

Almost at the point where I can resume work on the repos, just found a bit of time today after finishing up the sync for the last offsite NAS.
Likely the above breakage for newer builds is when they updated their build environment and not within the code itself.

For testing in Vmware it looks like this is the last build that works on Windows 10 and 11, unknown about real hardware:
eduke32_win32_20220412-9992-4a517bf9a works

Going through and testing OS compatibility on all the ports today and then will upload binaries to vogonsorg.

Looks like "The Hell 2" and "Project Tchernobog" projects for Diablo were updated since previously Windows XP compatibility were broken and now they work!

ddfix 1.5.7 is the last ver compatible with Windows 2000
http://www.vogonsdrivers.com/wrappers/files/D … /Hookers/ddfix/

Using "SDL2-2.24.1-win32-x86.zip" on Doom Retro v4.6.2 enables it to work in Windows XP again.

Spent all day going through ports and testing OS compatibility. Next step update vogons org, this will take some time.

Verified that DelphiDoom-2.0.7.735 works on NT4, just use the GL version. This may be the only currently updated doom port that does work on NT4 except for Doom Legacy if you count that.

DosFreak wrote on 2022-10-17, 23:40:

Verified that DelphiDoom-2.0.7.735 works on NT4, just use the GL version. This may be the only currently updated doom port that does work on NT4 except for Doom Legacy if you count that.

That is typical for anything Delphi build, being very older-Windows compatible.

Don't expect me to comment much on the multitude of Doom and Quake variants. For the time being, I consider these settled for my own uses and interests.

In the past days I Build XP compatible versions of all the Sonic Retro Engine (RSDK) decompilation project games, current SVN versions.
https://github.com/Rubberduckycooly
I will upload it later...
Had to upgrade to MinGW v10.3 for that, which fixed C++ std-filesystem over MinGW v8.4. I have both a Win32 thread and Posix thread variant of MinGW v10.3. Both work reasonably well in XP, but the Posix one needs older v8 pthread libs and dlls for NT5 compatibility. I am slowly getting better at this 😉

Verified that the latest quake3e works on 2000 as long as you use the ws2_32.dll from xp sp1. Should be pretty easy to fix in the source but likely better off with the dll anyway.

Yeah I think I want to get the latest build environment both VS and mingw situated locally and then see where github is at as far as compatibility. I want to say their environments are the latest Mingw w/posix (so Vista+) and VS2019 may be the only option for a minimum of XP assuming they haven't gotten rid of it yet.

Unknown if they offer older mingw or win32 thread but I doubt it.

I did have some info buried in one of these threads on using the later versions of VS and compiling for <XP somewhere.... ahh here it is: https://msfn.org/board/topic/183588-project-s … comment-1219143

DosFreak wrote on 2022-10-19, 16:51:

Yeah I think I want to get the latest build environment both VS and mingw situated locally and then see where github is at as far as compatibility. I want to say their environments are the latest Mingw w/posix (so Vista+) and VS2019 may be the only option for a minimum of XP assuming they haven't gotten rid of it yet.

AFAIK it is still possible, examples:

Vanilla Conquer is offering MinGW auto-builds which are Windows XP compatible. Which is an intentional aim of the project, for the time being.
https://github.com/TheAssemblyArmada/Vanilla- … ases/tag/latest

Here is very recent Redriver2-Dev appveyor VS2019 artifact auto-build:
https://ci.appveyor.com/project/SoapyMan/redr … builds/45118087
Still needs a mod of the NT6 requirement in PE header (6->5). Then it runs.
Similar thing with the fheroes2 project, though that one is not using appveyor.

My local WinXP build environments lacks auto-download support, like for git code dependencies and libs. Compared to linux which loves to auto-download an update these things. For older-OS compatibility though, I figure it is good thing to manually keep track of what exactly is present in the build environment.

Looks like they are using Ubuntu w/ mingw for compiling which means default would be mingw non-posix so that may be the reason. For some reason I though github only supported Mingw via Msys, glad to be wrong. Wish more projects would default to cross compiling from *nix. Sigh.

Something else on my todo is tracking of OS compatibility for patches and mods. Stalker is somewhat of an oddity since alot of the "mods" are actually included with the open source engine and not just replacing game files in the original engine.

In this case: https://bitbucket.org/anomalymod/xray-monolith/src/master/
The original OpenXRAY is for 7+ for 32bit and 64bit
https://github.com/OpenXRay/xray-16/releases

S.T.A.L.K.E.R. Anomaly 1.5.1 for XPx64
http://wp.xin.at/archives/5696

Created an organization in github: https://github.com/vogonsorgorg
Thinking putting main fork of a repo here and then forks of the fork on personal accounts, previously have avoided the other forks of a source because of this.
Need to make a list of the forks of a fork.
Fork is one those words that sounds weirder the more you say it.

DosFreak wrote on 2022-10-19, 18:27:

Looks like they are using Ubuntu w/ mingw for compiling which means default would be mingw non-posix so that may be the reason. For some reason I though github only supported Mingw via Msys, glad to be wrong. Wish more projects would default to cross compiling from *nix. Sigh.

This weekend I tried to make more game-friendly ffmpeg-4 libraries. As in, a set of avcodec-58.dll/avformat-58.dll/avutil-56.dll that is not taking up 40 MB just to show a smacker intro or cutscene video. But building ffmpeg is very much dependent on bash scripting. So it was either getting MSYS for windows or cross-compile on Linux. Fortunately Solus has a basic MinGW cross-compiler set in its repository. See image (honestly, that is not Windows). It works very well. That MinGW comes with pthread. But I know how to backdate pthread to v8 by now, which looks to me like a winthread wrapper anyways.

It did not come with a separate pkg-config tool. And when using the system native pkg-config, you have to tell it to look at your MinGW folders for packages:

1export PKG_CONFIG_LIBDIR=/usr/share/mingw-w64/i686-w64-mingw32/lib/pkgconfig

I will add the new lightweight ffmpeg dlls to the Tomb1Main and Theme hospital Corsix-TH XP back-ports, and upload them to my website.
It is interesting how Tomb1Main is using ffmpeg for more then just videos. It uses it to play flac audio during the game, and to show pcx/png background images.

PS. Thanks to Reino, for his ffmpeg back-porting explanations and patches here.

Compared the SDL2 2.0.5 for Windows 2000 against the original 2.0.5 and updated the 2.24.1 files with the changes. Need to compile a test to see if works and if nothing else was added between the two to break compatibility
https://github.com/vogonsorg/SDL/issues/1