I am starting this topic to discuss the ongoing works on UBCD V5.2.

Continuing from this thread, this is summary of the work-in-progress:

http://www.ultimatebootcd.com/v52/index.html

If you have any ideas or suggestions, please post in this thread.

Thanks!

Please have a look at OmniBoot in Ver 0.5, where you find the UBCD integrated.
Infosite and Downloads

On this Infosite you will see a content-table with a column Int(egration) where you will find "ubcd" for many elements. These are integrated in the core of ubcd, the fdubcd.iso as in the original UBCD. Many have been updated since UBCD 5.1.1 and I also added a floppy-tool group for vintage needs.
Further I added a kernel command parameter named "kblang" which allows to set the keyboard (or even preset for each OmniBoot-copy) at boot time. Very handy for editing boot-parameters, but many tools and distros integrated in OmniBoot also are affected by this. Please view the tab "About Boot" and "Languages" for details.
I also updated isolinux on fdubcd.iso to 4.06, and hopefully all other updated tools which are booting standalone, without fdubcd.iso that is.

With the last release all of OmniBoot can even be booted via LAN (PXE), even the bigger and big distros on CD and DVD. Slitaz is used to provide a zero-conf PXE-Server out of the box, I added the tftpd-daemon from H.P.Anvin (Syslinux) named tftp-hpa and a nfs server. The latter to provide root-filesystems for the bigger distros, where not everything fits into the ramdisk.

I would be happy and I guess many users too, if we could cooperate to the benefit of the best multi-boot-live-meta-distro existing.

I do not have the time to study dos scripting indepth, so I will probably never be able to keep the real core of ubcd up2date, as I see the core in the dos-floppy-image on fdubcd.iso (no problem updating dos-cabs etc). Most of my time goes into unpacking init-ramdisks of dozens of distros, understanding the start-up and learning that way all possible options for the integration into OmniBoot which always means: boot with the same files from everywhere, even from LAN. So... linux-scripting most of the time.

Now if I had a wish for the next ubcd dos floppy it's clearly national keyboard support. mkeyb sure has the smallest RAM-footprint, but there is another keyb.exe included in the latest FreeDOS which provides a lot more languages. Unfortunately it doesn't list the languages with /L as mkeyb so it can't just be replaced easily but needs some other code. Together with the parameter "kblang" I think this could really please a lot more users around the globe

Happy live-booting

@Victor,

In the previous topic (the one you linked to) I posted a partial list http://www.ultimatebootcd.com/forums/viewtopic.php?p=24303#p24303 of suggestions, in reference to the OP of that topic.

Some of my suggestions are different from what you currently have in your V52 index page. I could specify them again, if necessary.

I have already sent you other suggestions and comments by PM in the past. If some beta test is eventually available... .

Like I said, this is a WIP. So not all apps have been updated yet.

Is there anything in particular you'd like to highlight?

@Don:

Regarding the "kblang" parameter, could you give me a short premiere on how things are tied together? For example, Parted Magic has its own "language" option for selecting the locale, so how does "kblang" influence this choice?

mkeyb v0.41 _is_ included in FDUBCD, masquerading as "keyb". Again, how could "kblang" tie in with all of this?

kblang is only affecting ubcd-based boot-elements. Any other distribution as pmagic has it's own boot-logic and OmniBoot is mainly a Syslinux-example how that can work together. So within OmniBoot, pmagic has totally different syslinux-configs than the original, as all the other modules. Packing them in the standalone isos again implies a lot of configs and makes these standalone isos again very different from their original.
Actually there is also a file lang.cfg which allows a default accross all distributions, whenever the chosen language is available, otherwise defaulting to a default language. I am sorry but I can only ask you to please check the hundreds of syslinux- config-files, it's a bit complicated to elaborate the whole thing here in a text.

Fixed.

As far as I can tell, they are just gPXE stubs for booting into the open-source distros held at the respective websites.

Fixed.

I checked, and it's legit, after Hitachi bought over IBM. Just like later versions of Drive Fitness Test were Hitachi-branded. But it's still the same OnTrack software AFAIK.

Latest version is beta1. Should we be updating to a beta release?

Decided not to. This appears to be a shell project with zero content. No binary, no mailing list, no bug list entry. Nothing.

Next on my todo list.

This seems to be the most convenient way. The original link can be easily harvested from the Wayback link by removing the prefix. This way, casual browsers won't complain to me about dead links, and knowledgeable browsers can easily extract the original link and do other investigation if they want.

BTW, just did some work on F-Prot and XFPROT.

The latest version of F-Prot (V6.2.2) won't work with XFPROT. Have contacted author, but from other posts on the net, I am not hopeful. Basically, others have encountered this problem as well and author did not respond.

The CLI interface for F-Prot appears to have changed enough to be a problem to XFPROT V2.4. So hacks to get around the version number check brought up the main GUI, but a number of options are not working.

So we have 3 options:

1) Keep F-Prot V6.0.3, which works with XFPROT V2.4 as well as the new virus defs.
2) Fix XFPROT (I don't have enough mojo for that).
3) Find an alternative to XFPROT (Tried, but couldn't find. qtfprot seems to be even older than xfprot).

For the moment, I am sticking with (1) until a better solution pops up.

My doubt is about including them in the main list; not about including them in UBCD. In any case, I don't think their respective license is "freeware".



This is probably not a big issue. My only doubt is about both versions being "the same". Many different HDD manufacturers used the same Ontrack software.



Generally, I wouldn't replace stable with beta in UBCD. But here we are talking about GRUB-related software, so I am inclined to do it in this particular case. It may be helpful to hear from other users too.
Please also remember that SGD and SG2D are two different utilities.



Do you think it is better to keep an older version of the main program (the back-end scanner) because the front-end is not being maintained?

FWIW, the latest PartedMagic has a front-end for ClamAV, and the file manager (SpaceFM) also has a plug-in (not included in PMagic) available for ClamAV . Also note that PMagic doesn't include the antivirus database (they are too big), but the programs are able to download and update them. I would still include in UBCD the updating scripts, but not the databases themselves.

BTW, other PMagic modules that used to be included in UBCD also need to be updated, or they won't show up in new PMagic releases.

Here a good news, I read the source code of XFPROT and I guess I found where the problem is. (And a bad news: I can't fix this yet.)

Here is the code that detects the f-prot version in XFPROT:


Basically, it just calls "fpscan --version" and then try to find a match to any of the hard-coded strings.

But, when I test "fpscan --version" on my bash shell (with f-prot 6.2.1), fpscan outputs something like this:


So, the version detection fails.

I'll make a post again when I find a way to fix this.

How about "Free service"?

I am at a bind here. I think a frontend is important, otherwise most users will be at a loss.

I like being able to pop in the CD and be able to do a first scan immediately instead of waiting for 5~10 mins for the download.

Which release are you referring to? I am using 2012_09_12, just one release behind the current one, and the modules (XFPROT, PCRegEdit etc.) show up OK.

I have looked at the "kblang" infrastructure that OmniBoot provides, and find it hard to implement the same thing for UBCD. There's just too much duplication, due to one copy of files for each language. I admire the amount of work you have put into making this happen, but I am hoping there is a better way to achieve this without this amount of duplication.

The problem is that syslinux has no variable-management onboard. One would need to program a com32-extension like manjaro.c32 which I have only found at the authors place, so with the manjaro distro. I haven't yet tried how it would work in my environment and if the author is ok with it. This extension would allow a basic use of variables and could reduce the duplicates. As of now I am not writing all those duplicates. As I also have currently 9 modules which boot over pxe and make use of an nfs-server thereafter which means again a menu-duplication for that other boot code. Finally with the next version 2 modules also get a duplication due to 32/64-bit distinction. All of that is written by a little script (/boot/make/omniboot/mkcfg) and I only maintain the default language and a parameter file for each module at the moment.
On the other hand - at least in terms of duplication due to languages - this would allow in future to translate the menu to the respective language. Also work in progress here

I have not specifically searched for the license, but I would tend to think that at least BKO is not "freeware" (as in "free to use but close-source or something of that sort) but GPL'ed or similar.

I still think that all those sites (related to PXE / gPXE / iPXE / ...) are not needed in the main list. Maybe a paragraph mentioning them in the main page, but not in the list. A "too-big" list tends to be less useful for new users, which are the ones really needing it.



That's why I mentioned a front-end (or even two) for ClamAV. Having an antivirus scanner which is not updated to its best version (and/or without updated databases) only gives a false sense of security (the results of such scanner are not really useful). For those users wanting to use f-prot, having the latest version available makes more sense.



But the user is waiting for the download anyway. Moreover, the user waits twice. The first time, when the user downloads the released UBCD ISO image. The original image is useful just for a while (for antivirus scanning purposes). After some time, the databases are not updated enough to be worth scanning with them, so the user shall update them anyway before scanning. That's the second time, if not more. Scanning with old databases is not a good idea, at all. If a newbie doesn't know about this basic principle of antivirus usage, then "forcing" the update is much better than blindly using old databases. By not adding the antivirus databases, you are saving space and download times (instead of having to download the databases twice) and also helping newbies to use an antivirus correctly.

In addition, when booting PMagic, no database means less booting time (no need to expand the huge database package, less RAM needed for booting).

So in fact, by skipping the antivirus databases in the original release of UBCD, you save time. I can only see pros, no cons.



Hmm, then I need to check my customized UBCD. Thanks.

About the language selection, IMHO it is not worth the additional complications. Most programs in FDUBCD are English only, and changing the keyboard language before getting to the DOS prompt has almost no use in FDUBCD. For someone that really needs to change the keyboard language, it can be done from the DOS prompt after booting. Outside FDUBCD, each distro has the possibility to do it by itself, and I would consider supporting Linux distros to be outside the scope of UBCD anyway.

Obviously you are using an English keyboard. If you are not, say you live in France, Germany, Spain, Russia - the big rest of the world.... then each time you boot and you maybe only need to type a little path, some usual characters, you would need to adjust keyboard settings manually. You were not booting to play around with keyboards, you had a problem, that you wanted to solve...
You would understand, why exactly this feature is very useful to the rest of the world. And lot of problem-stressed users (who uses such tools?) will not even find out how to adjust their keyboard.
But of course it takes a lot of redesign and I can understand very well, if and why Victor wouldn't do it.
Let me only add, that it would highly raise the value of the UBCD if more keyboards were supported as of today. As said, this would need the other keyb.exe which is available in FreeDOS 1.1 (don't know if it was there earlier). Unfortunately the current keyb.exe (renamed mkeyb.exe) gives a list of languages when invoked with the /L option and this is used in the batch-code to create the selection list. My proposed keyb.exe doesn't support this so this would mean rewriting some of KEYBRD.BAT.

No. I am well aware of the difficulties for a user with a non-US keyboard (or with the need for multiple languages in one keyboard). But this is FDUBCD. It has its specific purpose. After booting, the keyboard language can be changed if really needed. Setting a different keyboard language before getting to the DOS prompt of FDUBCD has not much use.

For customizations, setting a particular language or having multiple options may be adequate. For the original UBCD, I would consider this as bloatware, specially when users already have alternatives available.

It's up to others to decide, what is done in the UBCD, than me But even if the selection isn't available in syslinux yet and so preselected at the DOS-prompt, even then it would be convenient for some nationalities, if there was a wider selection. To me it really doesn't matter if this feature is implemented on the syslinux-level, I can do that myself But I have problems, modifying keybrd.bat as to use another keyboard driver.

I disagree your opinion.

For a person who has a non-US keyboard, he will have trouble learning the US keyboard, or trying to type a DOS prompt.
I had a Japanese keyboard long ago and I remembered when I typed some punctuation characters the characters appear on screen are often different from the one labeled on the buttons.

Perhaps in the later version of FDUBCD (not in UBCD 5.2) we can have a graphical menu to choose a keyboard layout before (or after) going to the DOS prompt. The menu can disappear after 5 seconds if the user just want the default. I know this takes time to implement, but it's not impossible.

The user doesn't need to learn to work with a different keyboard. He would have to change the setting for the keyboard layout, if using the prompt would be so relevant for FDUBCD. But in FDUBCD, using the DOS prompt is not a frequent activity, and most programs included in FDUBCD don't even support other languages either (which is independent of the keyboard language, but it is another factor to consider). In most cases, there is no typing (just use a few specific keys so to perform a specific action and then reboot).

A customization to only one specific DOS prompt language should be simple. And if you want to translate all menus and add keyboard selection, then start with Don Manuel's collection and make a new collection. There is no need to add bloatware in the original UBCD. It is not a full-featured OS (use FreeDOS instead); UBCD has a specific purpose.

There are many important (and really necessary and really useful) features that are not added to UBCD, just because the development and maintenance depend on many different sub-systems that were developed by different contributors during the years. Adding bloatware is not going to make it easier.