b3lm0nt

Necessary link to Maciej Cegłowski's talk "Web Design: The First 100 Years:" https://web.archive.org/web/20230210133927/https://idlewords...

Because the technologies we had were good enough. It turned out that very few people needed to cross an ocean in three hours instead of six hours. On my way to this conference, I flew from Switzerland to San Francisco. It took eleven hours and cost me around a thousand dollars. It was a long flight and kind of uncomfortable and boring. But I crossed the planet in half a day!

Being able to get anywhere in the world in a day is really good enough. We complain about air travel but consider that for a couple of thousand dollars, you can go anywhere, overnight.

The people designing the planes of tomorrow got so caught up in the technology that they forgot to ask the very important question, “what are we building this for?”

Enjoyed this. Reminds me of the great Idle Words (Maciej Ceglowski’s blog) travel posts.

Shuffleboard At McMurdo: https://idlewords.com/2016/05/shuffleboard_at_mcmurdo.htm

I use Gary Bernhardt's (non)-method, quoted here:

IMO you don't need a special tool to manage your home directory / dotfiles. Git is the tool. Your home directory is a repo with a .git directory like any other repo. No other tools; no symlinks; nothing else. Commit what you want and gitignore the rest. I've done this since 2008.

Never had a problem with it.

A new alternative that I came across recently: https://www.literary.salon/

Fixedsys Excelsior might get you close (TTF, with ligatures).

https://github.com/kika/fixedsys

I wanted to love Common Lisp, but as a Vim user every day was a struggle. One typically uses plugins (Slimv, Vlime) that contort buffers in bizarre ways in order to simulate the SLIME EMacs REPL — if not, they will lose out on the interactive development experience that is so central to CL.

Being tied to either EMacs or an enterprise solution like LispWorks to get the full language experience was ultimately a non-starter. I’d love for someone to build an alternative CL development experience that could work in a wider range of text editors and IDEs.

There is a lot to learn from CL, but I think it can be hard to access for most developers.

Andrew Kane built dexter, which is an automatic indexer for Postgres.

https://github.com/ankane/dexter

https://ankane.org/introducing-dexter

Agree —- as someone who previously only owned software books for coursework in the early ‘10s, I’ve built up a growing collection over the past 3 years. The quality of book content is generally much higher than blog posts and SO answers, and I’ve never been one for eBooks / PDFs.

Plus, it makes my home office feel more in tune with my profession. I like to see the books on the shelf and leaf through them while waiting for my CI to build.

Seconded. Nice, concise volume that helped me setup hosting for multiple sites on a single VM with different requirements (some reverse proxy, some CGI, some static).

Really looking forward to the 3rd edition of Absolute OpenBSD.

Plain old Ruby on Rails is significantly more Lindy than this. And how about…

- LAMP (Linux, Apache, MySQL, PHP)

- CGI programming (/cgi-bin/)

- HTML, CSS, JS (with XMLHttpRequest to avoid full page reloads)

- AOLServer with Tcl (still developed as NaviServer)

- FTPing your HTML and CSS directly to the server

HTMX in particular is decidedly non-Lindy.

Brings to mind the recent overview that Ars Technica did of their infrastructure stack: https://arstechnica.com/information-technology/2023/07/ars-o...

Approx. 12 different AWS services and 30+ instances...

An invaluable tool for languages like Common Lisp, Tcl, and others with REPLs that are missing a basic command editing experience (clear line, search history, etc.).

Fantastic news. I’ve tried lots of new CLI tools but they always seem to fall between too little functionality (eg. xsv) and too much (VisiData). AWK is just right.

Ah, this explains it. I had a feeling I was missing something in my less informative response.

First point: the groff file in my gist is designed for plain-text files, so not all the functionality will exactly translate to PDF rendering.

Second point: to resolve the issue you're running into, remove these lines from the groff file to allow the default margins for PDF rendering to occur.

    \# Set the line lenth to \nl
    .ll \nl

There can occasionally be some strange behavior with the macros when different output devices are used (some options are ignored, some may have unexpected consequences). I took a look at the PDF output using my file directly, and it looks like the em sizing for gropdf is different from the grotty implementation, causing some overflow. (Maybe the font needs to be set explicitly before setting the line-length? Not sure).

Using a different unit of measurement (like inches or points) may be a better option for PDF files: https://www.gnu.org/software/groff/manual/html_node/Measurem...

Bonus note: you can confirm the final output device that will be used by a groff command by adding the -V option. Example:

    groff -Tpdf -V examaple.groff

Outputs:

    troff -Tpdf example.groff | gropdf

Using -Tascii instead will produce:

    troff -Tascii example.groff | grotty

Ref on output devices: https://www.gnu.org/software/groff/manual/html_node/Output-D...

* Edit: See 2b3a51's response for a better explanation.

I've started using plain vanilla groff (eg., no mom or other macro packages) for formatting text files. Just run: groff -Tascii example.groff

I've found it be perfect for my purposes. LaTeX felt like too much overhead for generating a few nice-looking README files and blog posts. I also have a soft spot for older UNIX / GNU tools.

The best sources of documentation (which did take some time to track down) are:

- gtroff reference: https://www.gnu.org/software/groff/manual/groff.html#gtroff-...

- man 7 groff: https://man7.org/linux/man-pages/man7/groff.7.html

I keep a small, annotated .groff file in a gist. It serves as a reference for the formatting functions I use most frequently: https://gist.github.com/benjamindblock/0926f7346b79b93e739ab...