> I agree with Laurent. > > Supporting two different tools for the same purpose fragments > user base. > > Embedded machines are becoming bigger, and this trend will continue. > What is "too big for embedded" today will be acceptable tomorrow. > Heck, twenty years ago people would consider madness to run > a full-fledged Unix kernel like Linux on an embedded device - > "it's far too big". > > I think implementing loadkeys is a better solution.
For the record, that was not my position and I'm afraid I was not clear enough. I suggested to balance the advantages of implementing "loadkeys" against the advantages of keeping "loadkmap", and implicitly I was meaning that "loadkmap" was a better solution for embedded platforms because it was focused on smallness and simplicity more than features. I'm sorry you misunderstood me. Please let's not go the way of the glibc and start thinking that bigger does not matter because newer machines can handle bigger. This is not what I am using busybox for. User base fragmentation can be solved with wrappers, higher-level tools, and documentation. Creeping featurism is a much more serious and intrinsic problem. Please KISS. If I needed loadkeys functionality and was to implement it, I would do it in a modular way, so that users who don't need it can safely remove it and keep the loadkmap functionality. Have loadkeys as an unpluggable upper layer, higher-level tool, for loadkmap. It sounds like Harald Becker's two-step loadkeys idea is following the same line of thought; I like this solution. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
