uupdump.net doesnt have to be an A Record..... Luzea can point uupdump.net anywhere he wishes using a cname including a cloud provider
I commented several months ago about the expensive TLS uupdump was forcing on its users unnecessarily. Forcing AES with SHA512 is expensive which is why TLS 1.3 was created in the first place. It provides similar level of security with much less code (the ssl code on the backend) and overhead. So, multiplying this by 2000 users, well no wonder this was a drain on the system. Alot of this is self-inflicted....
If my memory serves me right, my original comment was related to posting another functional UUPDUMP website. There was an outcry about it. In an effort to placate the outcry, I removed the website posting. If you accidentally offend someone with your comments about TLS, then someone will probably respond to you about it.
I'm sorry if facts offend people.... Qualys ssl labs wasnt lying. This is a common tool to check ssl configuration or test if ssl configuration will pass a security check.
I did explain to @donmiller, who has not any relation to uup dump whatsoever, why we can't promote these unknown copies: His response: That certainly makes sense. I hope that Paul Mercer and Abbodi1406 will get it worked out. ... Whatever people want, suggest or hope for, if the current maintainer/owner doesn't want to give the original website another try, it won't happen and when people learn to use the new UUP dump APP all will be fine.
This thread has sort-of morphed into a "Local Server" thread. Have you received any more feedback as to whether the original UUPDUMP.NET website is going to be resurrected, and when?
Just leave versioning to @abbodi1406, so that we can get 1.5.2f, 1.5.2r and 1.5.2u versions. Or, more seriously, count up a release number whenever a change is made. 1.5.2-r1, 1.5.2-r2 and so on. Everyone having an outdated copy will notice immediately.
Updated UUP dump app to version 1.6.0 Changelog: - The "MSIT {Internal Corpnet}" channel will always have "Generate packs: NO" option - Updated genpack.php to always skip [Internal Corpnet Required] updates This should be the last major update, I couldn't find any more issues with it Thanks to @abbodi1406 for all the help p.s. "local server" has been renamed to "app" because users were confused by the previous name
After upgrading my Computer to the latest 13Gen select all options, updates, ESD, bla bla. Noticeable differences compared to my old 9700K Spoiler: Image
1.separate scripts are available in the scripts folder, all of which also work in the root uupdump directory just move "uupdump-get.cmd" and "uupdump-run.cmd" scripts to the "uupdump-x64" folder, then move "uupdump-aio.cmd" script to the scripts folder 2. edit "uupdump-get.cmd" and "uupdump-run.cmd" scripts and change default options
Is there any way to do the same thing in Linux as the script for downloading packages? My server is running. I have PHP 8 on it, and I'm just wondering how to initiate a content update (download packages). Thanks for help...
Does UUP dump app have the same restrictions as the UUP dump website of converting and building Win10/11 iso files on lower host OS versions (e.g. on Win8.1)?
Dear @abbodi1406 , I wonder is this restriction inherent to the host OS (e.g. Win8.1)? Is it possible to remove this restriction through shipping UUP dump app with some tools? Or by modifications of your script uup-converter?
DISM, even when updated, just fails to service the new versions correctly (integrating LCU), on the old host OS. Nothing to do with the script. AFAIK you can still create valid ISOs if you don't integrate updates. Edit: Just wondering if Wimlib has the same issue?
Upgraded to the local server version 1.6.0 and tried to build an 22621.2361 ISO. Everything went fine with the downloaded script 22621.2361_amd64_de-de_professional_cc66a258_convert.zip, but in the end the script created an ISO that is named 22621.1.220506-1250.NI_RELEASE_CLIENTPRO_OEMRET_X64FRE_DE-DE.ISO (which with approx. 4,33 GB size is also way smaller than the previous ISO for 22621.2359, which resulted in 6,70 GB with the default settings). So: wrong version (22621.1) and wrong timestamp (22-05-06 instead of 23-09-xx as would've expected). Any idea what went wrong here? Problem with the generated script/zip archive? Or already incorrect (meta)data from Microsoft (called "fileinfo" in the uupdump context I assume) or incorrect "pack" generated?
Sounds as if there was an error integrating updates. Except for the initial build (which you now got), each build is UUP set of the initial build + latest updates. The converter script is supposed to integrate these updates, the result is the final build. For making a 22621.x build, the conversion must be done on Windows 10, version 2004 or later, otherwise it won't work correctly.