RSTR:=0x$(shell dd if=/dev/urandom bs=4 count=1 \ of=/dev/stdout | cksum | tr -c -d [:xdigit:] \ | cut -b-8)
how might you do things differently? cksum is POSIX, unlike md5sum(1) (which, for starters, is just "md5(1)" on freebsd). intuition suggests the 802.3 (Ethernet) CRC used by cksum(1) doesn't wreck your uniform distribution properties (the simple one's-complement checksum method of RFC 793 (IPv4) obviously would suffice, but isn't trivially available from the POSIX command line).
Note that cksum(1posix) is introduced solely for converting dd-generated seed material into the necessary human-readable format. i'd like to use printf(1posix), but we need to pass dd's output through a pipe. it mustn't go to the shell, or there is a 4*N*(1/256) likelyhood of failure for each of N bytes interpreted as metacharacters. we can use single quotes to interpret only single quote characters, meaning a 1.5625% chance of failure. NASA called and said, "thanks, assmaster! now we'll never know whether tiny screws can be sorted in space!"
remember that variable definitions don't directly abort the build (aka cause a syntax error) for this kind of thing, so it will propagate up in your build...quite probably unnoticed, quite possibly until all too late (this is why i distrust $()/backtick substitution in scripts). Oh, and NASA called. They said you're off the Makefile team. Perhaps you'd have better luck writing PHP for Wet Seal?
unfortunately there's this big fat Hummer2-like (as in it wastes resources) entry in the printf(1) man page:
STDIN Not used.three bitches in a bitch boat! printf(1posix) ought accept a format conversion modifier indicating "take this one from stdin" (or, to be more flexible, a file descriptor which defaults to stdin's STDIN_FILENO aka 0).
Indeed, if we hijacked %n for this purpose, it would help fix a bug in the printf(1) and printf(1posix) man pages:
"...FORMAT controls the output as in C printf..."
Like hell it does; the byzantine %n conversion specifier, according to printf(3), "store[s] into the integer indicated by the int * (or variant) pointer argument. No argument is converted."
Well, there's jolly little pointer context you can very meaningfully pass to printf(1posix) code, following an exec(2) call as it (by virtue of being printf(1posix) and not printf(3)) does. in fact, this sounds like some incredibly subtle exploit in the making (%n certainly has been for printf(3) over the years). so maybe printf(1posix) ought grab the next $IFS-delimited value from stdin for %n.
so that was 5 seconds to write the Makefile definition, and about 15 minutes to blog this, huzzah!
[recombinator](127) $ \time -f %E ssh -oControlPath=none hogwarts true 0:01.44 [recombinator](0) $ \time -f %E ssh -oControlPath=none hogwarts true 0:01.65 [recombinator](0) $ \time -f %E ssh -oControlPath=none hogwarts true 0:01.68 [recombinator](0) $ \time -f %E ssh -oControlPath=none hogwarts true 0:01.61 [recombinator](0) $ \time -f %E ssh hogwarts true 0:00.26 [recombinator](0) $ \time -f %E ssh hogwarts true 0:00.20 [recombinator](0) $ \time -f %E ssh hogwarts true 0:00.20 [recombinator](0) $ \time -f %E ssh hogwarts true 0:00.22 [recombinator](0) $Those are some pretty solid improvements, folks. I've got a minor writeup here, or just read ssh_config(5). Oh yes: I quit McAfee Research 2009-11 to pursue academics full-time. It was a great five years there, and I appreciate all the good times. Back to my HotPar 2010 submission!
/usr/lib/xfce4-notifyd/xfce4-notifyd xfce4-settings-helper --display :0.0 --sm-client-id 29afe6488-185e-4359-a60d-9529c7c05642 /usr/lib/xfconfd xfsettingsd xfwm4 --sm-client-id 203c6cff5-bbfe-4d1d-9d1c-3228cb4e24f0 --display :0.0 /usr/bin/xfce4-session /usr/bin/xfdesktop --sm-client-id 11d81ba305000121438424100000173320018 --display :0.0 xfce4-panel --sm-client-id 28775a015-d9f0-4ded-bdee-1cac6a52936e /usr/lib/xfce4-screenshooter/xfce4/panel-plugins/xfce4-screenshooter-plugin socket_id 14680099 name screenshooter id 11925955890 display_name Screenshot size 42 screen_position 9 /usr/lib/xfce4-netload-plugin/xfce4/panel-plugins/xfce4-netload-plugin socket_id 14680100 name netload id 11812997820 display_name Network Monitor size 42 screen_position 9 /usr/lib/xfce4-netload-plugin/xfce4/panel-plugins/xfce4-netload-plugin socket_id 14680101 name netload id 12062092340 display_name Network Monitor size 42 screen_position 9 /usr/lib/xfce4-xfapplet-plugin/xfce4/panel-plugins/xfce4-xfapplet-plugin socket_id 14680102 name xfapplet id 12232614662 display_name XfApplet size 42 screen_position 9 /usr/lib/xfce4-timer-plugin/xfce4/panel-plugins/xfce4-timer socket_id 14680108 name xfce4-timer id 12297861572 display_name Xfce4 Timer size 42 screen_position 9Does this seem fundamentally ridiculous to anyone else (in particular, those are some abominable command lines)? So, xfce obviously does the whole process-per-panel-element thing because:
- Sloppy coders imply undefined behavior, and you'd have the whole panel needing to restart every time xfce4-netvisor dropped core due to a device rename
- As a corollary, sloppy coders imply bloated loading times (often due to poor use of libraries -- be sure to read Ulrich Drepper's whitepaper, as linked to from that entry), so restarts of the panel in toto couldn't be transparent
- Sloppy coders imply blocking and excessive use of global resources (blocking, after all, being misuse of thread-level time resources), and sucking all of this crap into one process would lead to Cartesian products of interactions -- only through reducing interactions to structured implications can debugging hell be avoided. I doubt Dijkstra finds much readership among GUI coders
Now, I must break here to commend the efforts of Keith Packard, Carl Worth, and everyone else out there hacking on DRM, GEM, and i915 -- I love y'all, and everything there is awesome (well, KMS broke my workstation with Debian's last xserver-xorg-intel release, but ya gotta spend money to make money). But these are not the people hacking on xfce4, to which we return...
How many processes do you need to implement a config file? I'd have thought 0, but xfce is running no less than 3: xfconfd, xfsettingsd, xfce4-settings-helper. What, between xfconfd and xfsettingsd, do they need help with? Why is the configuration system so bloated and obtuse that this is all necessary? I run hour-long compiles without the benefit of gcc-settingsd, gmakeconfd, ld.so-environment-manager and two baseball players to be named later. If things can't be processed on each process startup, throw a processed data structure into freakin' POSIX.1-2001 shared memory and throw a process-shared semaphore atop that sunnabitch. There's a reason why these capabilities exist, for chrissakes!
This is made all the worse by xfce applications being, aside from a semi-substantial core (xfce4-terminal, I salute you!), underfeatured and generally shitty, and thus GNOME applications being thrown into the mix anyway. I today realized my xfce4 laptop needed gnome-system-monitor -- nothing fancy, a few panels showing CPU/mem/swap etc, nothing WindowMaker hasn't had a dockette (or whatever the hell WindowMaker calls the ass-esque abominations it renders for people working on SPARCStations in university printing labs around the nation) for since 1986 or so. This required installation of ONE-HUNDRED AND THIRTY MEGABYTES (it sounds like a fucking Soviet nuclear yield) of GNOME asstrash including evolution-data-server (more useless processes, hurrah!) and something called "policykit-gnome" which promises to integrate my capability-delegating experience with ponies and sugar cookies. The upshot is the addition of:
/usr/lib/gnome-applets/multiload-applet-2 --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=18 /usr/lib/gamin/gam_server /usr/lib/gvfs/gvfsd /usr/lib/libgconf2-4/gconfd-2 /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=18That would be the addition of 5 processes for 1 additional applet, which furthermore is shown to be polling-intensive by the magic of powertop(8). Oh wait -- xfce added a lovely xfapplet process to handle the no doubt complex and intensive management of this applet, so 6.
If someone brought this to me at work, I'd have them officially fired and, on my own time, flayed.
Regarding this blog, the lack of threaded comments has really got me down, as bad tools will tend to do. I might migrate the effort to LiveJournal. On the plus side, I've been editing my wiki a lot; go check out http://dank.qemfd.net for some good old-fashioned computational fun.
If gcc had broken tradition with past compilers (Cray and SGI compilers I've known supported a gamut of -O levels beyond -O3, and surely a surfeit of others as well), and called...actually, I guess I give compilers a pass here: you don't want to throw crap like --optimize-space into a compilation line, due to iterated consumption of terminal real estate during a build. Exactly as -Os (optimize for space on gcc) indicates, you'd end up with a series of difficult-to-remember flags, ala the -Q options on Intel's icc c++ compiler (then again, how often need you remember optimization flags outside makefile creation?) I think, however, that the generated-code-speed vs. compilation-time tradeoff will slide (has already slid?) in importance, and the competing axes of compilation decisions -- power-vs-performance, codespace-vs-codecycles, parallelism-vs-fastserial, all that -- will render a single vector meaningless. At this point, you'll need even more rely on descriptions of processing environments and architectures, and almost certainly parameterize on them at runtime.
Let's remove the optimization level decision, aside from as a debugging aid, from the realm of the code's creators and to the code's executers. It'd be a win all around.
Oh, to complete an earlier thought: if -O0..-O9 had never been introduced, I wouldn't have to listen to someone say "I think it ran faster with -O4 than -O2", and tell them "uhhh, gcc on x86 has never meaningfully supported an optimization level higher than -O3." This happens every few years, and it typically results in a bad scene. I'd like to bring out rms ala Annie Hall: "I heard, I heard what you were saying. You, you know nothing of my work. How you ever were hired to write any kind of code is totally amazing." Tyro assholes!
So I'm in g-reader and notice new TotalWonKerr posts -- hurrah! time to catch up on the world of strategic weapons after finals! oh, hurrah, a phatty new OTA report on SLV's -- and follow through to http://totalwonkerr.com...
This weblog has been taken offline by request. 4/24/2009.
wtf? from the g-cache:
Paul Kerr used to work for the Arms Control Association. Josh Pollack is a consultant specializing in arms control, proliferation, and deterrence issues.By far my second-favorite nucarms blog, after the inimitable ArmsControlWonk. Lots of good references to original sources, placed handily on his page (as opposed to government links, which so regularly get pulled offline). Where are you, Paul?
In any case, I've downloaded and archived -- so far, at least, as I know -- all the files he's linked. I'll put them up, once I verify he didn't get into trouble or something.