On Sat, Nov 08, 2014 at 08:36:25PM -0800, Garrett D'Amore wrote: > Spoken like a true MBA without any real understanding of technical debt.
Technical debt is taken on when something is done in an expeditious manner or as a trial, experiment, or proof of concept; when other software grows around it suboptimally because of shortcomings in the original architecture, the indebtedness grows. That is, the term applies when you are talking about things that hinder development or improvement. Removing the original shoddy or unexpectedly limited/limiting pieces is indicated if and when it hinders new work, forces new work to contort itself unnaturally, or is imposing a significant maintenance burden. Things like rtld4.x that happen to be sitting there untouched and ignored are not technical debt, they are simply history. All the current work is on rtld and ELF binaries, which use none of the old code and are in no way burdened by it. That technical debt was paid off many years ago when the world moved on to ELF; the new implementation, new ABIs and standards, and pain of migration were the repayment. I ask again: what are you doing that is blocked on rtld4.x, or that would be significantly simpler/easier/faster/more maintainable if it were gone? Seeing something other than what you want in cscope is worth improving in the tooling but does not justify removing functionality unless it is simply impossible for anyone to be using it (i.e., it doesn't work at all, or it depends on something else that doesn't work ar all or has already been removed). If you want to tackle some real technical debt, here are some projects you could work on: 1. Work with one or more hardware vendors to get rid of the boot process, BIOS, and other system firmware. Then you can torch GRUB, dboot, and most of os/startup.c as well as trash like the real-mode platter from MP startup. Stuff like this *defines* technical debt, and the frequency with which modifications to this code have been made speaks to the valuable engineering time it wastes, not to mention the poor user experience around it. 2. Fix NSS. The vision around Reno, Sparks, and the rest of the LDAP/Kerberos/AD/etc. integration remains hindered significantly by the limitations of the existing interface. nscd is unobservable and buggy. The NSS interface still provides no means for passing parameters to backends, and there is still no effective way to use third-party backend modules with nscd. Password changes and other 2-way communication requiring self-authentication remain brittle and rely on one-off code (i.e., passwdutil). Given how useless these interfaces are from the perspective of a third-party developer, breaking them might be worth it -- and in the worst case, one could continue to support the existing interfaces *for existing binaries only*. 3. Replace OpenSSL and any other crypto consumers with KCF consumers, and optionally work with OpenSSL/LibreSSL/others to make sure that those frameworks ship with KCF backends where it would be useful to do so. 4. Merge SunSSH and OpenSSH, preferably be upstreaming the useful additions to SunSSH and ensuring that all interfaces it necessarily consumes are properly made Public. Then remove SunSSH from the gate (and replace it with nothing; nothing in ON depends on it). I'm sure there are plenty of others, but hopefully this short list illustrates what technical debt really is and where we're paying heavy interest on it. Code that has already been superseded and exists in stasis solely to support legacy applications reflects debt that has already been paid off. ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
