laserboot

ut in many cases I only use each one once. ^R makes it easy to use them again a few times, but in other cases I save them into a shell script to make them easier to distribute to other machines, parameterize, and maintain. The one I most often use is probably a user interface for YouTube via youtube-dl or yt-dlp that consists of a few such shell scripts. My main editor is Emacs. If I want to do the same thing repeatedly (e.g., delete a line containing the string .LVL) I create a keyboard macro with F3 and F4 (or C-x ( and C-x )) when I do it once, then run it repeatedly with C-x e. I probably write about 4 programs a day in this way. Emacs has a M-: command to evaluate Lisp expressions, which are programs. Recent programs I have written in this way include (/ 43.2 1.7), (* 9.3 1.2), and (+ 8 3 2.50 3.50 3 7 3.50 3 1.50 4.50 6 5.50 6.50 6 3 2.50 2.50). Probably I write about 1 program a day in this way but I only use each one once. Longer Lisp programs like this can be written in *scratch* and executed with C-j or in .emacs (or .emacs.d/init.el) and executed with C-x C-e. For example, (global-set-key [f5] 'recompile). I use my .emacs file constantly every day but probably only add something to it about once a month. An outdated version is at https://github.com/kragen/kragen-.emacs.d/blob/master/init.e.... Sometimes I write bigger programs for my own personal use too. A few years ago I wrote https://github.com/kragen/pytebeat for a livecoding performance of bytebeat in a bar. I finished writing it in the train on the way to the bar. In https://github.com/kragen/laserboot I wrote a simple parametric 2-D CAD system for laser cutters in PostScript. For Dercuano http://canonical.org/~kragen/dercuano I wrote a kind of shitty HTML rendering engine that generates a PDF file, as well as a simple CMS for generating a tree of HTML files from a directory of Markdown. The other night I wrote a bytecode interpreter with a graphical display in C as a sort of mockup for the operating system of a small computer I recently got the parts for; it's in http://canonical.org/~kragen/sw/erika.git. I've also written compilers, interpreters, ray tracers, database engines, parser generators, graphics libraries, logic circuit optimizers, 2-D game engines, etc., for my own use. Some of the recent ones are in http://canonical.org/~kragen/sw/dev3. Over the last 9 years, according to a shell script I just wrote, it has accumulated 170 C programs, 254 Python programs, 60 HTML files (mostly JS with a thin shell of JS), 43 Jupyter notebooks, 28 files in assembly language (though some of these are compiler output), 23 programs in OCaml, 17 programs in Golang, 15 programs in Rust, 14 programs in OpenSCAD, 11 standalone JS files, 9 programs in PostScript, 6 programs in Perl, 9 programs in C++, 7 programs in Scheme, 5 programs in Meta5ix, 5 programs in Java, 5 programs in Lua, 5 programs in Forth, a program in Prolog, and a lot of etc. That's 688 programs in all, according to a program I just wrote in the browser console, which is 69 per year or one every 5.3 days. However, there's probably some double-counting there, or counting of things I started but didn't finish, or things like the copy of D3 I checked in there, and the real number might be more like one every two weeks. Some of the larger ones are https://nbviewer.org/url/canonical.org/~kragen/sw/dev3/fir-v..., which is a vocoder; http://canonical.org/~kragen/sw/dev3/ritmo.c, a stochastic wavetable synth for an Arduino; and http://canonical.org/~kragen/sw/dev3/qfitzah.s, an interpreter for a higher-order programming language with pattern matching, flexible parametrically-polymorphic data containers, and dynamically dispatched method calls with multiple dispatch, that assembles to an executable under 1K. Some other random ones are http://canonical.org/~kragen/sw/dev3/dnsscan.py, which scans random IP addresses for open DNS servers; http://canonical.org/~kragen/sw/dev3/andnot.go, which tests the behavior of the Golang &^ operator; http://canonical.org/~kragen/sw/dev3/weemenumain.cc, which is a test program for a C++ library for an imgui-style menu system I wrote for microcontrollers that only uses a few bytes of RAM; and http://canonical.org/~kragen/sw/dev3/rpncalc.c, a four-function RPN calculator program. But, like I said, there's nearly 700 of these, and more in http://canonical.org/~kragen/sw/aspmisc, http://canonical.org/~kragen/sw/inexorable-misc, http://canonical.org/~kragen/sw/netbook-misc-devel, and the kragen-hacks archives, so I'm not going to try to describe them all here. They're all git cloneable except kragen-hacks.

able to thrive on their own. Optimising fertiliser and watering quantities and schedules also allows greater productivity. How much of that is specifically reliant on additional energy inputs is harder to pin down, though fertilisers pre Haber-Bosch were reliant on accumulated deposits generally moved by sailing ships. We could (if necessary) revert to sail, but those deposits are largely gone. Looking at annual areal output is a good metric. US productivity actually lags Europe if I recall -- Holland is especially efficient. On animal energy output levels, athletes are best considered as demonstrating a maximum possible short-term output, not a long-term population average. Particularly in the face of suboptimal nutrition, disease, and injury. Smil's got an impressive set of tables and charts (making excellent use of logarithmic scales) showing output of humans, various draught and domesticated animals, etc. One factoid I've stored away is that a blue whale has roughly the metabolic output of a tractor-trailer rig. And yes: sustained animal output is pretty sharply limited, across scales: per day, sustained over weeks or months throughout the year, or even over lifetimes. Overexertion or overuse severely curtails output, and peak outputs are not sustainable over long periods. (Something Frederick Taylor rather famously omitted from his "scientific" studies.) Figuring about 25% of a typical human's 2,500 - 3,500 calories gives a range of about 30-45 watts of continuous output. Note that the acre was originally unit of area derived from a measure of work: the amount of land a farmer and team of oxen could plough in a day. In German: Tagwerk, literally "days' work". The unit was variable (condition of land, soil, oxen, and plough determined tillable area), and represented less than a full day's work as the animals had to be rested and pastured. (Smil notes that a large waterwheel or windmill, and many early Watt steam engines, delivered about 5-20 horsepower, about 3.7 - 15 kW, of power. And that made a huge difference.) On carrying capacity net net, one of the most highly recommended sources I've run across (though not yet read) is Joel E. Cohen's How Many People Can the Earth Support? (https://www.worldcat.org/title/how-many-people-can-the-earth...). My understanding is that he explores the basis and implications of values ranging from < 1 billion to > 1,000 billion, which includes most credible (and possibly some less than) estimates. One point most serious discussions hammer is that "how many" goes along with "how much", in terms of resources: I = P * A * T Environmental impact is a function of population, affluence (resource consumption), and technology (as an inverse). On energy systems and conversion mechanisms: the interesting thing is how little the story's changed in 50, 75, or even 100 years. We've added fission, and PV's gotten remarkably better. Batteries have improved tremendously. Fusion's still a pipe dream. Otherwise: plants, sun, wind, water, geothermal, waves. Flux per unit area is a very good analysis metric, see the late David MacCay's Renewable Energy Without the Hot Air (http://withouthotair.com) My suspicion is that direct solar thermal (avoids conversion losses) and CSP power (simple and robust) are likely mainstays. There's been some interesting research into low-tech silicon-fabrication processes, with the Global Village Construction Kit (now apparently rolled into Open Source Ecology / Appropedia) doing some work. Purity and process control are major limitations. See: https://www.opensourceecology.org/gvcs/ https://www.appropedia.org/Welcome_to_Appropedia Among the higher DDG results is your own GitHub laserboot repo: https://github.com/kragen/laserboot NB: Technologies with a less than zero efficiency factor remove useful energy from the system. A brake would be an example. Perpetual motion technologies have efficiencies >= 1. Which seems unlikely in practice. (It's a joke, laugh.)