UBCD V5.1 beta 1 available for download
Moderators: Icecube, StopSpazzing
-
- Posts: 1368
- Joined: Mon Feb 21, 2005 10:59 pm
- Contact:
UBCD V5.1 beta 1 available for download
This version is obsolete. The latest version is available at:
viewforum.php?f=7
UBCD V5.1 beta 1 is now available for download
Torrent: http://www.ultimatebootcd.com/download/ ... so.torrent
Magnet URI: magnet:?xt=urn:btih:24VEQ7MEVTZ4Y6ZPNA3SWZSMQISJ56Q5
HTTP: http://ubcd.mirror.fusa.be/ubcd51b1.iso
FTP/HTTP: http://ubcd.linuxfreedom.com
md5sum: 1ef674a5c12df5ec92b9b22db2dbc0d5
sha1sum: 9ed8c3feb956d87034918e6e0b0351055757e4b6
SHA-256: B38FB6B780815C2EFC4D46CE8649ED0B9C5E1A4E41DBF31EFDC279F047EC0EDB (computed using 7-Zip's "Calculate checksum" function)
Description:
This release is my first attempt at updating some Linux components (F-Prot and XFPROT in Parted Magic). Hopefully I didn't miss anything.
@ady: I found out isolinux.bin is modified by mkisofs during ISO image generation. That's why the isolinux.bin in UBCD is different from the one in the syslinux distro.
Changelog:
- Disabled FDUBCD menu for WDIDLE3 and DIMM_ID in ubcd.ini.
- Re-added missing aida16.cab to fdubcd.iso.gz.
- Updated Offline NT Password & Registry Editor to v110511. Thanks to IceCube for the update.
- Updated ASTRA to V5.50. Thanks to ady for the update.
- Updated to SPFDisk to 2000-03v. Thanks to Explorer09 for the update.
- Filter away Parted Magic entries in grub4dos menus.
- Updated Intel Processor Identification Utility to V4.31. Thanks to ady for the update.
- Updated Parted Magic to V6.2. Updated F-Prot to V6.0.3. Update XFPROT to V2.4.
- Updated UBCD FreeDOS to V1.43. Updated XCOPY to V1.4a. Updated SYS.COM from FreeDOS kernel 2039. Updated LOWDMA.SYS and UMBPCI.SYS to V3.81. Changed help.bat in level1\help.bat to test for MORE.EXE instead of MORE.COM.
- Updated ubcd\tools\unxutils\bin\xz.exe to V5.0.3. Thanks to ady for the update.
viewforum.php?f=7
UBCD V5.1 beta 1 is now available for download
Torrent: http://www.ultimatebootcd.com/download/ ... so.torrent
Magnet URI: magnet:?xt=urn:btih:24VEQ7MEVTZ4Y6ZPNA3SWZSMQISJ56Q5
HTTP: http://ubcd.mirror.fusa.be/ubcd51b1.iso
FTP/HTTP: http://ubcd.linuxfreedom.com
md5sum: 1ef674a5c12df5ec92b9b22db2dbc0d5
sha1sum: 9ed8c3feb956d87034918e6e0b0351055757e4b6
SHA-256: B38FB6B780815C2EFC4D46CE8649ED0B9C5E1A4E41DBF31EFDC279F047EC0EDB (computed using 7-Zip's "Calculate checksum" function)
Description:
This release is my first attempt at updating some Linux components (F-Prot and XFPROT in Parted Magic). Hopefully I didn't miss anything.
@ady: I found out isolinux.bin is modified by mkisofs during ISO image generation. That's why the isolinux.bin in UBCD is different from the one in the syslinux distro.
Changelog:
- Disabled FDUBCD menu for WDIDLE3 and DIMM_ID in ubcd.ini.
- Re-added missing aida16.cab to fdubcd.iso.gz.
- Updated Offline NT Password & Registry Editor to v110511. Thanks to IceCube for the update.
- Updated ASTRA to V5.50. Thanks to ady for the update.
- Updated to SPFDisk to 2000-03v. Thanks to Explorer09 for the update.
- Filter away Parted Magic entries in grub4dos menus.
- Updated Intel Processor Identification Utility to V4.31. Thanks to ady for the update.
- Updated Parted Magic to V6.2. Updated F-Prot to V6.0.3. Update XFPROT to V2.4.
- Updated UBCD FreeDOS to V1.43. Updated XCOPY to V1.4a. Updated SYS.COM from FreeDOS kernel 2039. Updated LOWDMA.SYS and UMBPCI.SYS to V3.81. Changed help.bat in level1\help.bat to test for MORE.EXE instead of MORE.COM.
- Updated ubcd\tools\unxutils\bin\xz.exe to V5.0.3. Thanks to ady for the update.
Re: UBCD V5.1 beta 1 available for download
These following questions are not for Victor specifically, but for anyone who could help find some answer/workaround.Victor Chew wrote:I found out isolinux.bin is modified by mkisofs during ISO image generation. That's why there's a one byte difference between the isolinux.bin in UBCD and syslinux distro.
Is there any other method (or command argument or other tools) to get "the original" isolinux.bin and still have the ubcd iso correctly built?
Is this issue happening to any other project using isolinux.bin?
Re: UBCD V5.1 beta 1 available for download
It is possible, but it is not that easy to do it manually.ady wrote:Is there any other method (or command argument or other tools) to get "the original" isolinux.bin and still have the ubcd iso correctly built?
If you just want to check if the isolinux.bin file is from an official release, only checksum from byte 64 to the end (so the boot-info-table is skipped).
Yes, unless isolinux.bin is chainloaded from grub4dos, in which case it is patched in memory when you use the chainloader command. Also Syslinux chain.c32 can patch isolinux.bin (modified or unmodified) and chainload it, just like grub4dos.ady wrote:Is this issue happening to any other project using isolinux.bin?
The -boot-info-table switch of mkisofs changes isolinux.bin:
Code: Select all
EL TORITO BOOT INFORMATION TABLE
When the -boot-info-table option is given, mkisofs will
modify the boot file specified by the -b option by inserting
a 56-byte "boot information table" at offset 8 in the file.
This modification is done in the source filesystem, so make
sure you use a copy if this file is not easily recreated!
This file contains pointers which may not be easily or reli-
ably obtained at boot time.
The format of this table is as follows; all integers are in
section 7.3.1 ("little endian") format.
Offset Name Size Meaning
8 bi_pvd 4 bytes LBA of primary volume descriptor
12 bi_file 4 bytes LBA of boot file
16 bi_length 4 bytes Boot file length in bytes
20 bi_csum 4 bytes 32-bit checksum
24 bi_reserved 40 bytes Reserved
The 32-bit checksum is the sum of all the 32-bit words in
the boot file starting at byte offset 64. All linear block
addresses (LBAs) are given in CD sectors (normally 2048
bytes).
ISOLINUX needs to know the LBA of the isolinux.bin file to find the rest of isolinux.bin. At boot time only 2048 bytes of isolinux.bin are read (-no-emul-boot and -boot-load-size 4 ("virtual" (512-byte) sectors to load in no-emulation mode)).
Download Ultimate Boot CD v5.0: http://www.ultimatebootcd.com/download.html
Use Parted Magic for handling all partitioning task: http://partedmagic.com/
Use Parted Magic for handling all partitioning task: http://partedmagic.com/
Re: UBCD V5.1 beta 1 available for download
@Icecube, thanks for the info. So, if I understand correctly, this is related to mkisofs too, not only to isolinux.bin. Is there any way to avoid this issue? I mean, if Victor (or any user customizing UBCD for that matter) could use a different tool other than mkisofs to build the UBCD ISO, will this issue appear too?
***
BTW:
Should be updated with the newer info, like:
In addition, please consider checking updates for the auxiliary tools that came from http://sourceforge.net/projects/mingw/files/
for the next UBCD beta (Icecube might have better ideas than me about them).
***
BTW:
Code: Select all
ubcd51b1\ubcd\tools\win32\unxutils\readme.txt
Code: Select all
7-zip is v.9.22
http://sourceforge.net/projects/sevenzip/files/7-Zip/9.22/
7z.exe (7z922.exe)
Code: Select all
xz is v.5.0.3 now from
http://tukaani.org/xz/
xz.exe from the Windows version
for the next UBCD beta (Icecube might have better ideas than me about them).
Re: UBCD V5.1 beta 1 available for download
This is not an issue, but a feature of mkisofs. The -boot-info-table switch will cause the patching of isolinux.bin. ISOLINUX requires this info (LBA offset). ISOLINUX has some default values that might work in some cases though.ady wrote:@Icecube, thanks for the info. So, if I understand correctly, this is related to mkisofs too, not only to isolinux.bin. Is there any way to avoid this issue? I mean, if Victor (or any user customizing UBCD for that matter) could use a different tool other than mkisofs to build the UBCD ISO, will this issue appear too?
This is also one of the reasons why using ISO editors, is a bad idea. They can accidentally move the isolinux.bin file to another LBA offset, so ISOLINUX can't boot correctly anymore (Can't find it seconds stage).
If you use the modified isolinux.bin to generate a new ISO, the file is patched at the same bytes, so I don't really see the problem.
Download Ultimate Boot CD v5.0: http://www.ultimatebootcd.com/download.html
Use Parted Magic for handling all partitioning task: http://partedmagic.com/
Use Parted Magic for handling all partitioning task: http://partedmagic.com/
Re: UBCD V5.1 beta 1 available for download
There is no "problem"Icecube wrote:If you use the modified isolinux.bin to generate a new ISO, the file is patched at the same bytes, so I don't really see the problem.
![Smile :)](./images/smilies/icon_smile.gif)
So, no matter if a user uses mkisofs or any other tool to build the ISO, isolinux.bin can't be exactly the same as the original (which comes in the syslinux package)? Ever?Icecube wrote:ISOLINUX requires this info (LBA offset). ISOLINUX has some default values that might work in some cases though.
Does this mean that any ISO (like Linux distros) that uses isolinux.bin to boot (not chained from other boot loader) actually uses a "patched" isolinux.bin?
Re: UBCD V5.1 beta 1 available for download
Yes. At least afaik.ady wrote:Does this mean that any ISO (like Linux distros) that uses isolinux.bin to boot (not chained from other boot loader) actually uses a "patched" isolinux.bin?
Download Ultimate Boot CD v5.0: http://www.ultimatebootcd.com/download.html
Use Parted Magic for handling all partitioning task: http://partedmagic.com/
Use Parted Magic for handling all partitioning task: http://partedmagic.com/
Re: UBCD V5.1 beta 1 available for download
Icecube, thank you for your answers.Icecube wrote:Yes. At least afaik.ady wrote:Does this mean that any ISO (like Linux distros) that uses isolinux.bin to boot (not chained from other boot loader) actually uses a "patched" isolinux.bin?
***
Victor,
According to what I already posted in a previous ubcd development topic:
_ ESTOOL.EXE (in estool.cab) has the correct checksum, but the wrong modification date. For the next UBCD release, please rebuild the cab with the original executable file (original modification date).
_ MBRWORK.EXE and its readme.txt file (in mbrwork.cab) have the correct checksums, but the wrong modification date. For the next UBCD release, please rebuild the cab with the original files (original modification dates).
_ Partition Saving (savepart.cab) also has its files with the wrong modification date. For the next UBCD release, please rebuild the cab with the original files (original modification dates).
_ Astra (astra.cab) also has its files with the wrong modification date. For the next UBCD release, please rebuild the cab with the original files (original modification dates).
Those are the archives with wrong modification dates that I currently know about. The reason for the different modification dates might not be the same for all the archives.
TIA.
Re: UBCD V5.1 beta 1 available for download
DLGDIAG5.CAB no longer contains the text files (they were there in ubcd51a1). The text files are not distributed in the latest version of DLGDIAG5 for DOS, but at least one of them was a help file, including command line parameters (this is the one that might be more important/useful).
The latest zip archive of DLGDIAG5 from WDC doesn't contain any extra text file, just the executable.
Anyway, the most important text file to the user should be the help file, specially for the command line arguments.
I think it could be useful to re-add it in the next ubcd release.
The latest zip archive of DLGDIAG5 from WDC doesn't contain any extra text file, just the executable.
Anyway, the most important text file to the user should be the help file, specially for the command line arguments.
I think it could be useful to re-add it in the next ubcd release.
-
- Posts: 1368
- Joined: Mon Feb 21, 2005 10:59 pm
- Contact:
Re: UBCD V5.1 beta 1 available for download
@ady: I have noted all your suggestions.
However, for your suggestions involving modification dates, I won't be adding them to my todo.
Reason is because mod dates can be changed too easily, including something as trivial as changing the filenames to uppercase.
If your purpose is to check for changed files, binary checksums IMHO is the only reliable way to do it. And there are no lack of tools and means to help with the task.
However, for your suggestions involving modification dates, I won't be adding them to my todo.
Reason is because mod dates can be changed too easily, including something as trivial as changing the filenames to uppercase.
If your purpose is to check for changed files, binary checksums IMHO is the only reliable way to do it. And there are no lack of tools and means to help with the task.
Re: UBCD V5.1 beta 1 available for download
This seems to be not consistent with previous releases. Most CABs contain files with the correct modification date, even for files from 2004. CABs that were updated in several stable UBCD versions (with newer versions of the same files) also retained the correct (updated) modification date.Victor Chew wrote:@ady: I have noted all your suggestions.
However, for your suggestions involving modification dates, I won't be adding them to my todo.
Reason is because mod dates can be changed too easily, including something as trivial as changing the file names to uppercase.
So the "little things" that can change the modification date to something else than the correct one, have appeared in recent development releases of UBCD. This change was not happening before.
About the mentioned case of changing the file names to uppercase.
First, it is absolutely not needed.
Second, the programs are started from menus or command-line. There is no main interest of changing their file names to uppercase (or lowercase or whatever; just leave it as the original producer published it).
Third, the action of changing a file name (completely, partially, or uppercase or whatever) doesn't change the modification date of a file. That only happens if you use a "special method" as you used for ubcd51a2/3, which is also unnecessary.
If you have to rebuild a CAB with a newer version of the files inside it, and you were to use the same method you have been using for years, the modification date should be again the original, correct one.
My request is to rebuild those specific CABs without waiting for a new version of the files inside them. If I find more of those archives, I'll post them (I haven't have the time to check them all).
You just mentioned the main reason for my request. For a user to compare the files using checksums, there are cases where several layers of expanding archives are needed. It takes time to expand several layers, HDD space, run checksums on many files, make a list of comparison and filter the differences.If your purpose is to check for changed files, binary checksums IMHO is the only reliable way to do it. And there are no lack of tools and means to help with the task.
(NOTE: I "can't" just use 7-zip to get into several layers and expand only one file. I mean, 7-zip (and other tools) indeed allows this functionality, but expanding only one file or only the last layer is not enough for the full comparison.)
In contrast, if the CAB is as it is suppose to be, many file managers will do the comparison job trustworthy enough. A file manager is capable of comparing file names, dates, file sizes, folder structures... and give either the similarities or the differences.
Having the complete ISO checksum, and running once a security tool on the complete ISO is enough from a security point of view. I am not trying to check the files for security reasons, hence comparing with a file manager is enough.
If the file manager comparison method shows a different CAB (or any file for that matter), I can check *it* so to answer the question "Hmm, What was changed here?" or questions alike. I don't need to fully expand *all* the layers of archives in UBCD and check/compare each and every file.
If a CAB was modified, I use a file manager to explore it, or I expand that specific CAB and compare it to the original file downloaded from the producer of that tool.
By changing the correct modification date, the CABs' checksums change too, making the comparison steps MUCH more complicated and MUCH more time consuming.
How do you think I found the syslinux-related files that were not correctly updated in ubcd51a1? Other versions/programs (like diskcopy for example) that had some version inconsistency, or that had unnecessary files included, were discovered using the modification date as first clue.
For syslinux-related files, the first clue was the modification date. Only after that first clue, I checked the specific checksums, compare files with several different syslinux versions...
Moreover, not all the programs included in UBCD are listed somewhere. And there is no list of the versions included in the development releases of UBCD, other than the first post of each topic (which is not always correct nor complete). So, if I want to confirm the included version of some program, and compare it to the original current download of that program from its producer, the modification dates are, again, my first clue.
If the program is the same, the functions are the same, so there is no "absolutely critical" condition here. But having the correct modification date makes several "jobs" MUCH, MUCH more simple and MUCH, MUCH less time consuming.
By rebuilding once those CABs I mentioned, all those tasks are simplified for every future release.
Considering that stable versions of UBCD are released not-so-often, having the possibility to fast-check a file version using its modification date simplifies future customizations (or manual updates).
-
- Posts: 1368
- Joined: Mon Feb 21, 2005 10:59 pm
- Contact:
Re: UBCD V5.1 beta 1 available for download
Try this: mount both the old and new ISOs (using DaemonTools or something), then issue:
where "d:" and "e:" hold the old and new ISOs respectively. ![Very Happy :D](./images/smilies/icon_biggrin.gif)
Code: Select all
diff -rq d:\ e:\
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Re: UBCD V5.1 beta 1 available for download
I would at least try it (before saying anything else about the dates or the differences), but I don't know what are you talking about.Victor Chew wrote:Try this: mount both the old and new ISOs (using DaemonTools or something), then issue:
where "d:" and "e:" hold the old and new ISOs respectively.Code: Select all
diff -rq d:\ e:\
Under Windows command line, there are, by default, tools for comparing text, binaries and folder structures, but I don't remember "diff".
In addition to the default tools, there are many freeware/shareware tools for that, and I have several of those tools in my system, including file managers.
If you could be more specific or give more info about it, I'll try/text/check "diff".
Re: UBCD V5.1 beta 1 available for download
Since I normally use Windows, I tried it using a VM of PartedMagic.Victor Chew wrote:Try this: mount both the old and new ISOs (using DaemonTools or something), then issue:
where "d:" and "e:" hold the old and new ISOs respectively.Code: Select all
diff -rq d:\ e:\
The result is both, less informative than I can do with the type of tools I mentioned before, and also almost useless for the specific goal.
A) As I already said, several layers of expansions/extractions are needed, and "diff" can't do it.
B) Once a modification date is changed, the archive is changed, even if the binary is the same. For example, compare the file:
Code: Select all
fdubcd.iso.gz -> fdubcd.iso -> fdubcd.img -> LEVEL3 -> AUTORUN3.CAB -> bin -> ubcd.bat
The file is the same, but since the modification date was changed, the archive (autorun3.cab) is not the same.
This means that I have to find the difference, both binary and "metadata" (not technically correct, but to call it somehow).
The same would happen with lowercase/uppercase changes. All this is completely unnecessary.
C) The most important problem when using "diff" for this issue (or an equivalent tool under Windows, which I have several of them), is that the comparison is not only against a previous version/release of UBCD, but with the download of the original producer of each tool included in UBCD.
For this point, I can mention again Syslinux and DiskCopy, or add several of the more-than-20 tools I have compared before so to update them. And what about the files that were part of some CAB or some ISO that I mentioned that they were not necessary in UBCD, so they can be excluded?
All those examples started by comparing the original modification dates with those in UBCD.
The modification dates of files like "mdiskchk.com", "eltorito.sys", "shsucdx.com", "more.com/more.exe", "sys.com", and others were/are the first clue that something might be improved, or updated, or that was not updated when it should had (like some of the syslinux-related files). A binary comparison of the first layer of archives is not going to make it easy nor simple nor fast.
Instead, the modification date "is there". I can see it almost everywhere, without even the need to run a comparison first. Filtering by "modification date" also minimizes (a lot) the task.
D)Lastly, I'll give you the counter part. Say you changed the modification date of a file to 2011JUN28, but the original is from 2009. The binary might or might not be the same. For simple curiosity, if not for other valid reasons, the difference will make a user compare it to the original file (from the original producer, not from previous UBCD). "Is there a new version available? Is there any change? Maybe not, but why a different modification date? Is there something I'm not seeing? Was the original package tampered with?".
Of course, this is not 100% accurate, and is not going to happen every time and with every user. But there is no valid reason to make the change anyway.
Using the correct modification dates "is the correct thing to do", and I say it technically speaking.
PS:
I mentioned this in a previous post of this topic, but I just want to make it clear enough. It is not accurate that “any simple” action can change the modification date. Changing the name, with uppercase, lowercase, completely or partially changed, or moving the file to a different location... The “access date” might change, but not the modification date. Using normal methods/actions, the modification date should not change.Victor Chew wrote:Reason is because mod dates can be changed too easily, including something as trivial as changing the filenames to uppercase.
Re: UBCD V5.1 beta 1 available for download
Intel Processor Identification Utility v.4.32 was released.
-
- Posts: 1368
- Joined: Mon Feb 21, 2005 10:59 pm
- Contact:
Re: UBCD V5.1 beta 1 available for download
Noted. Thanks!Intel Processor Identification Utility v.4.32 was released.
You can get "diff" from here:If you could be more specific or give more info about it, I'll try/text/check "diff".
http://gnuwin32.sourceforge.net/packages/diffutils.htm
7Zip can help extract all the CABs to their own individual directories with two mouse clicks. After that it's a simple case of using "diff" or an equivalent tool to check for differences against another folder with the original binaries (in similarly-named subdirectories).the comparison is not only against a previous version/release of UBCD, but with the download of the original producer of each tool included in UBCD.
Re: UBCD V5.1 beta 1 available for download
That's not usable for all cases, as I already posted (with examples).Victor Chew wrote:7Zip can help extract all the CABs to their own individual directories with two mouse clicks. After that it's a simple case of using "diff" or an equivalent tool to check for differences against another folder with the original binaries (in similarly-named subdirectories).
I don't even understand why it should be needed. It's not.
I'll give you a clear basic example. Astra was just updated to version 5.5.0 in UBCD. I download the original zip, expand it, make a cab. The result is a cab with the original modification dates. It takes about 5 minutes (or less). I see no reason to find a cab of Astra with different modification dates included in UBCD.
If I see the same modification date, I have no reason to doubt about the version (of Astra) included in UBCD. This type of data (modification date) does NOT require from the user to extract anything. Not even using one click with 7-zip. No need to extra HDD space for each and every archive (cab, gz, img, iso...). No need to extract several layers (not "parallel" layers, as your example, and not "serial" layers, which is even more time consuming).
Any modern file manager can show you modification dates, flat views and automatic comparison. Why should anyone would need to expand anything? Why you would create the need to compare using checksums, when there is no real need?
Moreover, I see absolutely no positive aspect of this change. That's how it was before, and I see no reason to change it.
How is it that the Astra cab turns to have files with a different modification date other than the original? What would be the purpose? Why would anyone leave it with the incorrect modification date? What exactly turned those files to have a different modification date other than the original?
Victor, I know that this is in your hands, but I can't understand the logic of this. I can't see *any* reason to leave this specific archives containing files with a different modification date; while having the correct modification date has only positive consequences. I can't see any reason not to correct it and to avoid the problem in the future.
Re: UBCD V5.1 beta 1 available for download
From http://www.freedos.org
New Freedos kernel v. 2040, with new kernel.sys and sys.com (and others) was released. Versions for all 8086 and for 386+, with 16 and 32 bits. Maybe there is a way to give different kernels for FDUBCD?
In addition, a new beta for Freedos is available. This should be an opportunity to find new versions of programs to update UBCD, or programs that are replacing older ones not maintained anymore. It could be added to the initial menu too, as a new option, so to help test (and report) this new Freedos beta.
New Freedos kernel v. 2040, with new kernel.sys and sys.com (and others) was released. Versions for all 8086 and for 386+, with 16 and 32 bits. Maybe there is a way to give different kernels for FDUBCD?
In addition, a new beta for Freedos is available. This should be an opportunity to find new versions of programs to update UBCD, or programs that are replacing older ones not maintained anymore. It could be added to the initial menu too, as a new option, so to help test (and report) this new Freedos beta.
-
- Posts: 1368
- Joined: Mon Feb 21, 2005 10:59 pm
- Contact:
Re: UBCD V5.1 beta 1 available for download
Thanks! I am subscribed to their RSS, so I have received this news.New Freedos kernel v. 2040, with new kernel.sys and sys.com (and others) was released. Versions for all 8086 and for 386+, with 16 and 32 bits. Maybe there is a way to give different kernels for FDUBCD?
With regards to your ASTRA example, I don't really know what changed the timestamp. That's the thing. It's incredibly easy to change the timestamp. So am I now supposed to spend countless hours trying to figure out which software on my system has updated the timestamp of that file, and why it has done so? Or am I supposed to spend time "fixing" any differences in timestamps that you find, even when the files are binary identical?Victor, I know that this is in your hands, but I can't understand the logic of this. I can't see *any* reason to leave this specific archives containing files with a different modification date; while having the correct modification date has only positive consequences. I can't see any reason not to correct it and to avoid the problem in the future.
I know, in an ideal world, the timestamps should match, you get what you want, and both of us will be happy. But this is not an ideal world, and we both have limited time and resources to work on a specific number of activities. I am just not prepared to take on the additional work of assuring that timestamps of files included in UBCD match those from the apps' websites when they are already binary identical.
Frankly, the % of users who will checking UBCD against downloads from the apps' websites are in the low minority. And for those who really want to take on this task, surely a binary comparison is more thorough and prudent than comparing timestamps?
Re: UBCD V5.1 beta 1 available for download
Parted Magic 6.3 is released.
The i486 version supports also very old CPUs (or CPUs with a limited instruction set).
The i486 version supports also very old CPUs (or CPUs with a limited instruction set).
Download Ultimate Boot CD v5.0: http://www.ultimatebootcd.com/download.html
Use Parted Magic for handling all partitioning task: http://partedmagic.com/
Use Parted Magic for handling all partitioning task: http://partedmagic.com/