Posts

Showing posts with the label interface_design

openssl is grim

I've just spent a whole day trying to generate a certificate with openssl that firefox / chromium will accept. The issue is something like: the convention changed from sticking a domain name in the CN (common name) field, to using subjectAltName.  Browsers stopped accepting the old one.  But the openssl tooling was not updated with a usable tool, instead requiring arcane, undocumented, opaque, grim, and nasty options / config files.  It's no wonder everyone just uses the cloud.  The poor folk trying to get a working certificate compare notes on places like stackexchange (see for example " Provide subjectAltName to openssl directly on the command line " [0], which contained the final solution for me.  Please note: the "final solution" is not a phenocide of anyone involved in OpenSSL "development"). [0] < https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-the-command-line > The one that worked was t...

extracting images from PDFs

pdfimages , packaged in poppler-utils in Debian, can extract images from PDFs. Its default output format is weird.  It would be nice to have it just extract the images, in whatever format they're in, by default.  But to get this behaviour you need something like the option -all.  But even that isn't specified as "what comes in, goes out".  Instead, it is specified as:   Write  JPEG,  JPEG2000,  JBIG2, and CCITT images in their native  format. CMYK files are written as TIFF files. All  other  images  are  written as PNG files.   (I can't get blogger to remove that double spacing from the paste).  The reader is left hoping that "all other images" permitted in the PDF whatever-version format (PDF spec is a bigly moving target) are PNG.  But I wouldn't bet on it.  So some obscuro format might be getting converted to PNG still. The other gotcha is this from the SYNOPSIS and command-line usage summa...

output redirection at different levels (and a standard error developer debug crap rant)

 What's the difference the way output redirection is handled in this: $ foo > bar and this: $ xfoo -geometry +100+200 There are various differences, but the one I am trying to illustrate is as follows. In the first example, foo's standard output, which is a one-way text stream, and a Unix / POSIX concept, is redirected to the file called bar.  Whether or not it is redirected does not depend on anything from foo.  The shell, which is an execution environment that runs foo and opens bar and redirects the standard output (and prints that $ prompt at the beginning of the lines), takes care of it.  If foo writes to its standard output, this output ends up in bar.  If foo really wants to care, it can look at its standard output file descriptor, and find out whether it's on a filesystem, or is it pipe, or a terminal, and find out all about about it.  But by default, it doesn't have to care.  This is nice. In the second example, convention indicates this is...