At Tue, 11 Jan 2005 20:10:15 +0100, Alfred M Szmidt wrote: > > 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. > Guile should > be at the core of the GNU system (and the console is a important part > of the GNU system), and you are flat out rejecting this idea without > providing any reasons what so ever as to why. I don't see any specific, clear idea articulated in the sentence "Guile should be at the core of the GNU system.", unless you talk about something like a Lisp OS, which would be a different project entirely. Heck, even emacs doesn't use guile. Nor does bash, gcc or gdb, all important parts of the GNU system, as many others. > It is indeed quite clear that the Hurd console should use guile so > that it can be modifed by the user without having to recompile it, > that you are unwilling to even bother to see or even comment on why it > shouldn't is just a sad. 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. 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. And, yes, those overriding priorities demand that I don't even consider including guile as an unreplacable core component of the console unless there is overwhelming bias of some sort in favor for it. This is how writing stable and secure software works (and I am not even radical with the console here, just conservative). Arguably, my implementation is pushing it already. Simpler implementations should probably have been preferred. But I did a lot of debugging and testing, and I think the implementation is quite robust. Also, most of the more fancy stuff is in plugins, which can be replaced by more tight implementations if the need arises, or even be compiled in statically (and the plugin system removed entirely). The proof is in the pudding. Thanks, Marcus _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd