Besides Why, in my day..., the other Slashdot meme from yesteryear that never failed to amuse is "If only there was|were some kind of..."
However, Google, Kagi, and even Slashdot's own site search were all coming up empty. To satisfy nostalgia, cobbled together these stylized versions with Claude Opus 4.6:
If only there were some kind of enormous, interconnected network of computers, perhaps spanning the entire globe, upon which someone had built a system for indexing and retrieving information using simple keyword queries. Alas, we can but dream.
What we really need is some sort of "engine" if you will, specifically designed for "searching". We could type words into a box and it would locate relevant documents from across the world's collected knowledge in mere fractions of a second.
These were the platonic ideal of what memory served up, but the desire for pure, unadulterated, human-crafted wit remained. Went in search of a Slashdot archive and hit paydirt with Sketch the Cow's Slashdot Story Archive (HTML Format), which spans 1998 to 2019. Spelunked like so:
% du -sh stories.7z | awk '{print $1}'
8.6G
% time ugrep -z -E "if only there (was|were) some kind" stories.7z > results.txt
...6:35.92 total
Two gems from the diggings:
Anonymous Coward on Monday November 12, 2007:
"[I]f only there was some kind of searching engine one could use, or some kind of encyclopedia in the form of a wiki where one could look up this information... Maybe some day."
gosand on Monday October 06, 2003:
"[I]f only there was some kind of searchable, massive collection of computers that were all hooked together somehow, and contained this kind of information."
❧ 2026-08-01
Site search on tinyapps.org has been powered by a number of services and scripts over the years:
- Atomz
- KSearch
- Google
- Bing
- Swiftype
- DuckDuckGo
- Algolia for Netlify
- Algolia DocSearch
After a quarter century in the wilderness, the caravan has gratefully pitched its tent beneath the shady palms of Pagefind. At last, everything is indexed and searchable.
The JavaScript dependency (like Algolia's) is unfortunate, but a small concession for search that's self-hosted, static, and complete. Pagefind is open source and a snap to set up and use.
❧ 2026-07-08
and USBODE (USB Optical Drive Emulator):
"Ever wanted a GoTek for CDs? If you have a Raspberry Pi Zero W or 2 W, USBODE turns it into a virtual optical drive. It allows you to store many disk images on a MicroSD card and mount them through a web interface."
Demo: Finally a cheap CD-ROM emulator for DOS and Windows 98!
Known-supported models: Raspberry Pi Zero (2015), Raspberry Pi Zero W (2017), Raspberry Pi Zero 2 W / WH (2021), Raspberry Pi 3 Model A+ (2018), Raspberry Pi 4 (2019)/4B (2019).
See also Boot any and all ISO images from USB drive.
❧ 2026-06-24
DiskImageMounter.app silently fails to mount Linux ISOs in macOS and hdiutil attach linux.iso returns "attach failed - Resource temporarily unavailable". However, the built-in tar (bsdtar 3.5.3 in Tahoe) command can list contents:
tar tf /path/to/linux.iso
and extract files:
tar xf /path/to/linux.iso -C ~/extracted/
See also anylinuxfs ("mount any linux-supported filesystem read/write using NFS and a microVM") mentioned earlier this year.
❧ 2026-06-24
Symptom
cat displays text, but grep can't find it:
% cat foo.txt
The world is overcome--aye! even here!
By such as fix their faith on Unity.
% grep fix foo.txt
%
Cause
The file is UTF-16, not UTF-8/ASCII. file may correctly identify it as such:
file foo.txt
foo.txt: Little-endian UTF-16 Unicode text
unless the byte-order mark (BOM) is missing, in which case file may report just data, suggesting a hex dump is in order:
xxd -g 1 -l 16 foo.txt
00000000: 54 00 68 00 65 00 20 00 77 00 6f 00 72 00 6c 00 T.h.e. .w.o.r.l.
The alternating character/NUL pattern is UTF-16LE (UTF-16BE is the reverse, 00 54 00 68 ...). So fix is stored as 66 00 69 00 78 00, and grep fix fails to match the ASCII/UTF-8 bytes 66 69 78. cat output looks normal because terminals typically don't render the NUL bytes.
Solution
Convert to UTF-8 before grepping:
iconv -f UTF-16LE -t UTF-8 foo.txt | grep fix
By such as fix their faith on Unity.
Use UTF-16BE instead if the byte pattern is big-endian.
Why UTF-16LE and not plain UTF-16?
With a BOM, plain UTF-16 works everywhere: iconv reads the BOM and picks the byte order automatically.
Without a BOM, iconv's behavior is implementation-dependent. Common GNU/Linux and macOS iconv implementations differ: little-endian on GNU iconv, big-endian on macOS. The same file can convert on one platform but fail on another:
iconv -f UTF-16 -t UTF-8 foo.txt | grep fix # not portable for BOM-less input
iconv -f UTF-16LE -t UTF-8 foo.txt | grep fix # explicit byte order
For BOM-less UTF-16, use UTF-16LE or UTF-16BE, not plain UTF-16.
Handling conversion errors
If iconv stops with illegal input sequence, -c can skip invalid input:
iconv -c -f UTF-16LE -t UTF-8 foo.txt | grep fix
Sources
See also
Update
❧ 2026-06-24