Rudster816 wrote:
So basically it's just a set of boot sectors without source?
That's a set of
uniform boot sectors (i.e. behaving the same way independently of file system or device used and well documented)
and a utility that simplifies the usage of these boot sectors. In some cases (modifying GPT) it may not be a simple task just to perform it by low-level disk editor utility.
Rudster816 wrote:
Without source, I think a lot of people will avoid it all together because their projects are open source.
That's my choice not to open sources. People need
functionality first. Often they think that they need sources but actually they don't. The only thing is that it is just
unpleasant for them that they can't stare at the internals of the project, that's all.
On the other hand, I don't see any real obstacle for open source projects to use these boot codes. For example, Linux kernel does not have any loader at all and completely relies on other, standalone, boot loaders. It may be either free/open-source or proprietary loader.
Rudster816 wrote:
It's also not very complete since it's basically just the first stage to a boot loader.
In many cases developers prefer to do all initialization things by themselves or to write a really simple kernel by FASM/NASM. And they hate digging the GRUB sources, recompilation, installation of that monster, learning it's config/commands and learning GNU toolchain and ELF format. All that they want is just to load their pure binary file into memory and execute it. This tool is for them. There is a lot of
second stage bootloaders around but a lack of standardized and well documented
first stage loaders suitable for a small and simple kernels. This project is to fill this gap.
Rudster816 wrote:
A user would have to write file system code to get a working boot loader, which would nearly defeat the purpose of using your boot sector at all.
Sorry, I didn't get... do you mean that developer should write file system driver or should generate file system on a disk? Anyway, in both cases that are completely independent tasks. File system driver means full access to directories and files both for reading and for writing and doesn't need to fit in just a couple of sectors. File system generation (formatting) doesn't have to fill in any code at all. Many format utilities just fill in zeroes to the place of the boot code. The boot code is
option not necessary for file system to function.
Rudster816 wrote:
I don't mean to be a hater, but my honest opinion is that it really isn't useful. If you wrote second stages that could load an ELF file, that would change everything though.
But what if I don't use ELF format for my kernel and use just a plain binary? I hate GRUB, although my kernel supports Multiboot specs also and tested with GRUB2 as well.
This tool is a part of my own (yet incomplete) OS. I've seen that this part may be shared with others. Since I've made (IMHO) a good job and offer it to others for free, I don't see any reason for hatred.
Rudster816 wrote:
You'd still probably have to open source it though if you wanted to see people use it.
That's up to them, to choose, what do they want - to use it or to stare at the internals. As for functionality, open source is not required. For example, I prefer to use closed source Windows rather than open source Linux.
Rudster816 wrote:
It'd also be very helpful to release a Linux version, seems like it would be trivial to port it, since you really only needed to use the standard C library.
I think that the next step will be towards Linux users. I didn't announce first versions of loaders because it was very basic set of file systems, but the second version supports "gentleman set" of FS and devices. I suppose that the third version will be handy enough for Linux users.