Gareth Rees writes about programming, software archaeology, game puzzle design, and etymology, and wrote the text adventure Christminster.
HN links it for programming essays such as the hot and cold ends of a stack, and notes the author wrote Christminster.
That would be Stanislaw Lem's most depressing but aptly named masterpiece, "Fiasco".
https://en.wikipedia.org/wiki/Fiasco_(novel)
http://garethrees.org/2012/05/31/fiasco/
2. Radio static
A radiolocation map of the planet showed hundreds of transmitters of white noise, which merged into shapeless blotches. Quinta was emitting noise on all wavelengths.
In the Cold War theory: “What came to mind was an image of “radio warfare” taken to the point of absurdity, where no one any longer transmitted anything, because each side drowned out the other… All bands of radio waves were jammed. The entire capacity of the channels of transmission was filled with noise. In a fairly short period of time the race became a contest between the forces of jamming and the forces of intelligence-gathering and command-signaling. But this escalation, too, penetrating the noise with stronger signals and in turn jamming the signals with stronger noise, resulted in an impasse.”
Other hypotheses considered: “The noise was either the scrambling of broadcast signals or a kind of coded communication concealed by the semblance of chaos.” [It’s a consequence of the Shannon–Hartley theorem that the maximum information is transferred on a channel in the form of white noise.]
I found Knuth’s “Dancing Links” paper [1] very well written and a somewhat easy read (I had to reread certain parts a couple times). I had to write a sudoku solver for one of my classes and I read that dancing links and algorithm x was one way to do it [2]. I then read some things around the internet to apply dancing links to sudoku solving [3] [4]. If you read the Wikipedia entry on exact cover problems there is a section on sudoku as an exact cover problem [5] this is one thing necessary to understand in order to implement a sudoku solver with algorithm x and dancing links.
Knuth even talks about dancing links in his new 2017 Christmas Tree Lecture [6] specifically here at 4:28 [7]. Basically he uses dancing links to solve for certain n in the problem he sets up in that lecture.
[1] https://arxiv.org/abs/cs/0011047
[2] https://en.wikipedia.org/wiki/Sudoku_solving_algorithms#Exact_cover
[3] http://garethrees.org/2007/06/10/zendoku-generation/
[4] https://www.ocf.berkeley.edu/~jchu/publicportal/sudoku/sudoku.paper.html
[5] https://en.wikipedia.org/wiki/Exact_cover#Sudoku
[6] https://www.youtube.com/watch?v=BxQw4CdxLr8
[7] https://youtu.be/BxQw4CdxLr8?t=4m28s
The case for reducing the size of SVG is the same as for any kind of web asset: it reduces the initial transmission time (and improves the likelihood of a cache hit) and so reduces the time taken to load the page.
I doubt if it's worthwhile squeezing the last couple of bytes of gzip compression out of an image (other than as a fun and informative exercise), but when programmatically generating SVGs it's easy to do so naïvely and in these cases you can get big savings in file size. Here's a worked example where I was able reduce a generated image to about 17% of its original size through simple fixes: http://garethrees.org/2013/08/02/svg/
Similarly, tools like Inkscape need to represent information for editing the image (such as its layer or grouping structure; or style information maintained on a per-object basis) which is not necessary for displaying it, and this can amount to a large proportion of the SVG file size.
>At some point, the efficiency of new hardware completely outweighs the benefits of keeping old hardware running.
Agreed. That's why the best solution is to run old software on new hardware.
Vernor Vinge figured this out 25 years ago. A Deepness in the Sky depicts a human society thousands of years in the future, in which pretty much all software has already been written; it's just a matter of finding it. So programmer-archaeologists search archives and run code on emulators in emulators in emulators as far back as needed. <https://garethrees.org/2013/06/12/archaeology/>
(This week I migrated a VM to its third hypervisor. It has been a VM for 15 years, and began as a physical machine more than two decades ago.)
In addition, every additional setting multiplies the number of states your application can be in, and the combinatorial explosion of states is mostly not well-tested. If you set even a handful settings to non-default values, it's likely that you are running the application in a totally unique configuration that's not used by any other developer or user. If you encounter bugs, you're liable to get the "Idk, it works on my machine" response.
This blog post also covers other good reasons why user options are often not the right choice: https://garethrees.org/2013/06/13/options/
Really interesting subject since its one most people don't pay much attention to. Here is a relevant article which explains how to create the smallest possible PNG: http://garethrees.org/2007/11/14/pngcrush/