On Mon, Feb 17, 2014 at 06:57:25PM +0100, Arno Wagner wrote: > On Mon, Feb 17, 2014 at 15:39:01 CET, Arno Wagner wrote: > > > Actually, it's systemd's doing: > > > > > > http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n266 > > > > Ah, that evil monster. For that I would say those that > > use systemd shall suffer from the complexity they chose. > > That this is in a c-file, not an easily changed shell- > > skript, already explains quite a bit of what is wrong > > with systemd. > > > > So fixing this goes something like this: > > - create a patch for the c-code > > - recompile and reinstall systemd > > - and maintain your patch forever > > > > Pity. With a sane init system, it would just be a change to > > some shell-skript, i.e. 2 minutes with a text editor. > > Aparently, I was wrong. It seems the correct process to > do this (according to a personal communication from > Thomas Bächler) is as follows: > > - Find a solution for the problem that > a) is generic enough to fit your use case and satisfy others > b) can be implemented by the admin using appopriate configuration > files (without further editing shell scripts or binaries). > - Implement that solution in the code. > - Get the patch merged into systemd. > > How that has any business replacing > - Start editor > - Fiddle with init-script until you like the prompt > - Enjoy _your_ solution to the problem, no matter what > anybody else thinks about it These appear to be very different processes. Generally speaking, one of them results in an upstream change that everyone can benefit from at no cost. The other results in an isolated change that may or may not be respected by your package manager on upgrade. Should your toy break, you're own your own to debug your local modifications before you can debug the upstream code. Where did the --batch-mode flag come from? Surely, someone recognized a need and solved it in the cryptsetup binary. Why do you consider this feature addition in cryptsetup different from proposing a patch to any other project which uses a compiled language? I suspect this only works if you assume that the upstream project is contributor-hostile and will never accept your patch. Do you also frown on people who patch their kernel to make changes that benefit themselves but which wouldn't be acceptable mainline? Do you share similar contempt for any compiled code which could have a functionally equivalent solution in an interpreted language? > is beyond me. But I do know a certain other OS where > they do not like you to customize your experience either. > I can only advise anybody that does want to customize what > their system does to stay away from these authoritarian > atrocities. I used to respect your opinion on this list. Your work on the FAQ is fantastic, and a service to (I can only imagine) thousands of users. Your behavior here just makes you look like an adolescent who refuses to understand why one might prefer a different solution to their problem. Furthermore, defaming the work of people who've put their own time into $PROJECT does nothing to support your stance. It's childish at best. I'm saddened by this. I really don't understand your attitude. d _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
