On Mon, Jan 28, 2019 at 12:14 PM Adam Borowski <[email protected]> wrote: > > On Mon, Jan 28, 2019 at 11:03:50AM -0700, Gavin Howard wrote: > > I am the author of an implementation of POSIX bc with all GNU > > extensions (https://github.com/gavinhoward/bc). > > > Would there be any interest in replacing the GNU bc with my bc in > > Debian? I would be willing to do the work to package it. > > I'd say that _replacing_ is out of question at this point, but your > implementation would be very welcome as either something coinstallable or at > least an alternative. Once it's tested and so on, there might be time to > flip the default. > > bc is used mostly by Unix greybeards, and that's the kind of people who > really don't like regressions. > > Mostly, we'd want to see a compelling benefits why it's be better than the > mature and well-tested GNU version. > > > * It can be used in Linux kernel builds. > > So can GNU bc. > > > * It is zero-dependency and builds without modification on any > > POSIX-compliant platform. > > Nice, but not an upside on full-blown Debian installations, and bc is not a > part of busyboxy scenarios around here. > > > * It has history without needing libreadline or libeditline. > > libreadline is present on the vast majority of systems already. > > > * It comes with full man pages. > > That's a pretty basic requirement. > > > * It comes with some extra math operators, extra math functions, and > > extensions. > > Unix history shows that resisting to add such goodies is not humanly > possible even for projects whose stated purpose is to remove all bloat. So > obviously your project has some. And those may or may not be nice to have. > > > * It includes a full dc (except for the dangerous and unnecessary "!" > > command) that uses a symlink to use the same binary (like busybox and > > toybox). > > Reasonable. > > > * Its license is more permissive. > > Not an upside for us at all (but not a downside either). > > > Thus, the big question is: "why?". GNU bc doesn't suffer from > unacceptable evels of bloat, and it's not used in perfomance-critical > scenarios, so speed is not a concern. There's a cost to switching. > > I'd have your implementation under a different name (sort of like mawk vs > gawk), and give it time to prove itself. And when people say your version > is better and GNU bc is obsolete, then we'll talk... > > How does this plan sound to you?
Sounds good to me! I am confident that my bc has less bugs (my release process is rigorous), so I believe that people will like it better. I will create a new package. I will probably call it hbc to follow the same style as mawk and gawk. Suggestions for the name are also welcome. > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands > ⢿⡄⠘⠷⠚⠋⠀ for Privacy. > ⠈⠳⣄⠀⠀⠀⠀ Gavin H.
