[Android] Hacre:
Ok then.

You can however, not encourage it. Don't get me wrong, I understand your thinking behind such a tool but you didn't think it through, which I'll cover in the next section...

It does however, allow you to MAKE a boot.img without any real understanding of a boot.img. It also, as mentioned before, raises huge potential for GPL violation. Whether you made the zImage or not, packing a boot.img with one then distributing it breaches GPL.

It's safe to say that you have the knowhow to do this. It's also safe to say that as a result you also have the knowhow to do this without a kernel kitchen. So for you it's a tool of convenience, great. This would be one of the "pros" I mentioned in an earlier post. However the example you've put here is what's known as a strawman argument, a logical fallacy to distract from the main point. The majority of people aren't going to be fixing a need for you to use something other than a broken back button, are they?

So someone with the skill to edit kernel source needs a tool for putting a RAM disk together? Pardon?

Again, rare "pros" that don't outweigh the "cons" of this tool. To add to this point, the vast majority of Android devices use a separate recovery.img to the boot.img. There are some devices that embed recovery into a zImage, however for most of those there's only one recovery worth using.

This basically translates to "Other people do the same or worse so what's the problem?". This isn't exactly firm ground to be standing on, is it? To borrow from the violence metaphor that seems popular in this thread of discussion, only killing one person to someone else's one hundred isn't an improvement, because now there's one hundred and one dead people.

Reductio ad absurdum.

You can develop without using raw source code, there's a lot of guys around that are very talented with smali, for example. If my argument has come across as one demanding people only work with source then that's a communication error on my part. You need to understand there isn't black and white scale, it's not "writing source code" or "not developing". There's a lot of genuine effort that goes into most device development sections here, in among lots and lots of white noise generated by people who spend a few minutes on a kitchen, or in many cases, just winzip.

ROM Kitchens are great for a developer when it comes to distribution. Don't want everything that's in my ROM? Here, customise it. The argument being made here by me or others that are against this sort of tool isn't trying to undermine that. However, people who need to edit parts of an initrd are at a stage where splitting and recreating a boot.img is completely trivial. That leaves the people for whom it is not completely trivial in which case the skills are lacking to make those changes in the first place. A kitchen doesn't teach them those skills, no more than a ROM kitchen teaches the person checking/unchecking boxes ROM development skills.

"But Hacre, if a ROM kitchen is a good distribution tool for ROM developers, why isn't a kernel kitchen a good distribution tool for kernel developers?"

Well, ROM kitchens tend to be an online tool where people can customise the ROM that they want from said developer. This tool isn't an online tool, for one, it's a local collection of scripts. If it were an online tool, you yourself would be in all kinds of hot water for GPL issues as well. If it's not your kernel they're having your kitchen knock up for them, you're still at the end offering a download link for a kernel image. You just distributed a kernel and are now in breach of GPL. For two, the amount of things worth user side customisation in an initrd, assuming the kernel distributor knows what they're doing, are very few.