On Mon, Feb 17, 2014 at 19:58:27 CET, Dave Reisner wrote: > 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. But: - Requires whoever wants to make a change to be a developer and learn enough to change the c-code. A heavyweight effort. Also quite elitist as it excludes all people that to not have the required c programming skills from doing what should be a minor modification. - Requires what they want to be something that is "mainstream" enough so that it gets accepted. (What the HELL???? I insist I can customize my Linux system any way I want and I insist than in places where it should be easy _anybody_ should be able to do so _without_ having a comittee signing off on their wishes first!) > The other results in an isolated change that may or may not be > respected by your package manager on upgrade. If your package manager does not respect it, then the package manager is broken. Not all are. That argument is a red herring. > Should your toy break, > you're own your own to debug your local modifications before you can > debug the upstream code. The price of non-conformity is higher effort. Do you want everybody to use the same thing to prevent that? Guess what, it is not your choice, or at least it should not be. And if somebody want to do their own engineering on parts of their system, that is one of the reasons to use Linux. (Calling it a "toy" is just hughely disrespectful to anybody that wans to do this type of cutomization, btw.) > 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. Apples and oranges. --batch-mode is by its very nature a general idea. > 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 No, I do not. In fact I have done so myself. I do however not understand your point at all. > share similar contempt for any compiled code which could have a > functionally equivalent solution in an interpreted language? Huh? That depends on its usage cenario: Glue code, configuration code that should be highly flexible is better off being interprted. Code that does not have high performance needs and does simple things that people may want to customize as well. Code that "does one thing, and does it well" can be both. If performance is an issue, or things like memory locking, going non-compiled becomes very difficult. You are over-generalizing here to make an invalid point. It is not flattering. > > 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. Nice contrast. Maybe, just maybe you do really not get what this is about? But guess what, neither my comments here, not the FAQ I do to get admiration or respect and after this infantile posturing, certainly not to get yours. I do them because they are needed. If however, a single voiced opinion of mine can negate all your respect for some completely unrelated work of mine, then you should ask yourself whether there is something wrong with your world model. Your reaction is that of a true believer that has his faith challenged. A mature person can disagree with another person and still respect their work on other things. As to the ad hominem, you can stick that were the sun does not shine, I am entirely unimpressed by infantile name-calling. > 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. If the work sucks, I will call it bad. That is not defamation. I do have noticed however, that the systemd crowd behaves more like a cult in that regard: Any criticism is immediately dragged on an emotional level instead of being dealt with in a rational manner. That is one of the cheapest tricks to deflect criticism without dealing with the points raised. It also is a rather strong indicator that the work in question cannot stand on its own merits or such underhanded tactics would be unneccessary. > I'm saddened by this. I really don't understand your attitude. It is motivated by the technical facts I see and by a clearly hostile takeover attempt with regard to a critical part of Linux infrastructure. That you do not understand my attitude may be because you do not understand what I am saying and why I am saying it. But as I said, that some people do not like what I say will not stop me from calling a bad thing bad. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. - Plato _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
