Well, go ahead!
You'd be surprised how many good programmers have never had anything to do with assembly or segmentation (and possibly less surprised how many people without any programming experience decide to write an OS).
No, not at all. I try to play "online filter" over at OSNews.com - those who have some *basic* skills get forwarded here, those who don't know what a compiler is about get discouraged in-place.
But I prefer giving people links to a good Assembler book and the Intel Manuals so they can write up their IRQ handlers and GDT, instead of taking them by the hand and leading them through the baby steps of a bootloader. In the very least, they will write Assembler code for something they actually
need later on, and their questions fielded here in the forum are a bit more interesting for the rest of us...
Every training program ever created starts with easy stuff and builds up to harder things...
I don't consider toying with your MBR and the A20 gate "easy stuff".
I didn't say "list of possible kernels", but rather "can't automatically select the right kernel to boot from a list of possible kernels", for example my OS detects the number of CPUs (and CPU features), detects NUMA presence, decides if 64 bit or 32 bit should be used (and if 32 bit decides if PAE should also be used), and then automatically selects the appropriate stage 2, stage 3 and kernel code without any user intervention. This makes it foolproof (you can't try to boot a 64 bit kernel on an 80486), more user-friendly, and in the end (IMHO) makes it a more marketable product.
Sorry, but
none of that is hindered in any way by GRUB.
As for "boot options", something to allow the user to select and test a video mode (text or graphical) before booting the OS is (IMHO) important, especially as it may take a long time before a video driver for every video card is written.
Again, GRUB doesn't hinder you. So what GRUB is multibooting isn't your kernel, but your stage3 making all those smart decisions... hey, it's up to you, and don't tell me you squeezed all that code into your MBR...
Out of the serious OS developers some won't use GRUB and others will eventually be effected by some of the limitations I mentioned.
You didn't mention a single thing where GRUB hinders you.
Because of this I think serious OS developers will probably end up writing their own boot code sooner or later, so they might aswell make it sooner so they avoid the additional work of modifying a half complete OS.
And you really think people
beginning to work on ther OS will think about multiprocessing, NUMA and video modes?
All I'm suggesting is that GRUB & multiboot compliance shouldn't be automatically advocated, but instead people should be offered enough information to decide for themselves.
GRUB is a very solid starting platform, and chances are slim you ever
have to replace it. If writing your own bootloader takes your fancy, well, do it, but I still don't see how GRUB could "limit" you.
It limits the amounts of things you have to know about up-front to get your first "hello world" going. So far, I have to see a single thing where GRUB gets into your way, unless you only have 1 MByte of RAM. As such, I still think it is a good "default" recommendation, as the "default" is that most people will never need something else to boot their stuff, and the "default" is that - not exactly most, but many - people using Linux already have GRUB installed.
)