On Thu, Dec 25, 2014 at 4:04 PM, Rob Landley <[email protected]> wrote: > On 12/25/2014 01:46 AM, enh wrote: >> On Wed, Dec 24, 2014 at 7:47 PM, Rob Landley <[email protected]> wrote: >>> On 12/12/14 17:19, Robert Thompson wrote: >>>> I ran across a variance between toybox factor and coreutils factor. > ... >>> As you mentioned, you added a curly bracket level without indenting the >>> code. >>> I could do a tail call and expect the compiler to turn the recursion into >>> iteration, but reindenting the code properly is worth the noise in the diff. >>> >>> The version I checked in won't error out for 'factor ""' or 'factor "36 "' >>> the way Ubuntu's will, but I think I'm ok with that...? >> >> out of curiosity, what practical use is there for factor? even the >> coreutils version gives up around 38 decimal digits, and it's pretty >> slow even with numbers that small. > > I was reading http://www.muppetlabs.com/~breadbox/txt/rsa.html#14 on a > long bus ride, because I probably have to implement TLS someday (by > which I mean https not thread local storage) because wget can't talk to > the world without encryption anymore (thanks NSA), and the section I > linked to above used "factor", and I went "that's a command? Apparently > so. This is probably like a dozen lines to implement"... and had it > working before the end of the bus ride.
speaking of which (and going back to "simple is complex"), i have an openssl- (or boringssl-)based md5sum/sha1sum implementation that adds all the other shas too. (a toybox built with all these is actually a couple of hundred bytes larger than the one with just md5/sha1sum, but that's because of the duplicated help strings.) i know one of your goals is to minimize dependencies, but for us the goal of minimizing duplication (and thus amount of code to audit) is probably stronger. i suspect no one really cares that the toybox hashes are slower than the openssl ones, but the security folks probably will care about having another TLS implementation. (and things like reimplementing zlib and bunzip2 probably fall somewhere in between.) in this specific case the openssl API is reasonable enough your implementations could be a drop-in replacement, but i suspect in other cases part of your motivation for writing your own will have been the awful API. also in this specific case there's almost no sharing between the implentations anyway because 99% of the code is the hash implementation itself. but if you can, keeping API compatibility with the library you're trying to replace would be good. anyway, let me know whether you'd like to merge stuff like this into the main codebase. otherwise i can just "git rm" locally and add the alternative version to toys/android. i'll get a delete/merge conflict if you change anything in your version so i'll be able to track changes, so it's only really a loss if you think you have other users who'd prefer to use openssl. > So the answer is "you use it when writing tutorials about cryptographic > implementation details". > > Really I just needed a break from reading mind-bending math stuff so I > implemented a small self-contained thing for fun, and then checked it in > because it came preinstalled in ubuntu and was tiny. I wouldn't have > bothered if you couldn't switch it off in the config when optimizing for > size. > > I was surprised as anybody else to get a patch for it, but that means > it's apparently useful to somebody. By all means, switch it off in > Android. :) > > Rob > > P.S. At a design level I thought about defaulting it "n" but the > defconfig y/n signalling primarily indicates "is this done or not" and > it was finished and worked fine, so... (Well, the examples directory > also has stuff that defaults to "n" but factor isn't really a > demonstration of how to use the toybox infrastructure either.) And > defaulting "n" for other reasons is editorializing, where does it stop? > rev and tac? fallocate? makedevs? freeramdisk? partprobe? People _asked_ > me to add most of those, because they needed them. If somebody want to > make a .config file selecting a subset of the commands, you can do that. > It's not my job to guess how people will use generic tools. yeah, i was hoping to abdicate responsibility for subsetting and was disappointed to find that 'default' didn't mean "you probably want this". but it makes sense, and the subset that one project needs isn't necessarily going to be the same as any other project. it sucks to be me though. the best i can aim for is to try to ensure that there are roughly the same number of people complaining i put too much in as people complaining i left too much out :-) it's a pity the debian popularity contest only has per-package data (https://qa.debian.org/popcon.php?package=coreutils). if you ask people they always tell you they use everything "all the time". even if you broke it two releases ago and removed it one release ago. to work out which options are important for the commands that toolbox and toybox have in common, i've been relying on my command-line history, what i can find in scripts, and whether someone cared enough to add/fix something. but i don't yet have a plan for all the stuff in toys/pending. i also haven't thought much about "in the binary" versus "gets a symlink"; i suspect that the "too much" camp will be further subdivided into those who're offended by the binary size and those who're offended by the number of symlinks in /system/bin. and getting back to factor, i can't decide whether having it paints a target on my back or gives me something i don't care about to throw under the bus as a gesture of goodwill :-) _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
