> Sure, if you start with the idea that guile should be at the > core of the console, then this would be how to do it. But it > isn't, and probably never will be. > > And you have not provided any reasons why it shouldn't.
I am not the one who has to prove anything here, really. Considering that I have set forth arguments to why it is a good idea (including examples where it would be useful for the user), and you just rejected them flat out without providing any reasons, it is indeed you who has something to prove here not me. Heck, even emacs doesn't use guile. Nor does bash, gcc or gdb, all important parts of the GNU system, as many others. Emacs, gcc, bash, gdb where written before guile existed, the same applies to autoconf, automake, and a whole slew of other stuff, but you already knew that and on purpose ignored this fact. The console is a strange beast. It can be used as a user program, but its normal use will be as a system service, a daemon, and thus it should not be possible to be extensively modified by the user. Bash can be considered a daemon, and thus by your logic a system service. Since it is a system service, it shouldn't be possible to modify it extensivley by the user according you. (I don't see a huge difference between the console-client and bash, or any other shell) Overriding priorities are stability and security, secundary priotity is efficiency. All of those are many times more important than everything I have heard from you so far. Then I guess you are not interested in doing new, fun things, only in doing good old proven concepts. Infact, you have no reason to consider a console that uses guile to be less secure or less stable then one that doesn't. So all these "security and stability" concernes are baseless unless you can show examples where they would provide some kind of security or stability issues. _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
