From 3ff2e62722ff5a51a32961d97dc028c56e00481f Mon Sep 17 00:00:00 2001 From: kaa Date: Thu, 9 Nov 2023 22:57:12 -0800 Subject: A good copy of libhyphen is included in-tree. Makefile has been modified so as to allow easy compilation. The build path is now a compiled-in constant, allowing for the hyphenation patterns in-tree to be referenced from any directory. Hyphenation language may be specified at runtime using -l. --- demo/b.html | 377 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 377 insertions(+) create mode 100644 demo/b.html (limited to 'demo/b.html') diff --git a/demo/b.html b/demo/b.html new file mode 100644 index 0000000..3dca345 --- /dev/null +++ b/demo/b.html @@ -0,0 +1,377 @@ + + + + + + appreciated + + + +
+

appreciated

+

An Introduction.

+

A dis­cus­sion of a va­ri­ety of works that this au­thor ap­pre­ci­ates fol­lows. + They are pre­sented here with the hope that they spark some + in­ter­est in a prospec­tive reader. This doc­u­ment is writ­ten with the ex­pec­ta­tion + that a reader has some ex­pe­ri­ence and in­ter­est in soft­ware de­vel­op­ment.

+
+

cat-v.org

 +

cat-v.org in­tro­duced me to the po­ten­tial beauty of a well-written pro­gram. + Much of my study of pro­gram­ming and other­wise arts is now ded­i­cated to the pur­suit of that beauty.

+

The first of mul­ti­ple sec­tions of the site, I found harm­ful.cat-v.org's soft­ware sec­tion. + I ini­tially found it cu­ri­ous that sta­ples such as bash or PDF + may be con­sid­ered bad or wrong. Near the bot­tom of the in­dex page, it is writ­ten: + “At the mo­ment a de­tailed ra­tionale is not pro­vided for most of this, so fig­ur­ing out why some things are con­sid­ered more or less harm­ful than others is left as an ex­er­cise for the reader. Here is a hint: com­plex­i­ty is the bane of all soft­ware, sim­plic­i­ty is the most im­por­tant qual­ity.” De­cid­ing to take upon my­self this cu­ri­ous chal­lenge, I slowly be­came + e­d­u­cated upon what it means for a set of soft­ware to be, in a vague and aes­thetic + sense, good. Sup­plied in tan­dem with reg­u­lar ex­plo­ration of soft­ware that + caught mo­men­tary fancy, the text avail­able pro­vided me some guid­ance.

+

A later dis­cov­ered sec­tion of the site, quotes.cat-v.org, pro­vided me with philo­soph­i­cal + food for thought. Those that have im­pacted me, the per­son, have been re-sourced from + their ori­gin, then writ­ten be­low.

+ +
+

litcave.rudi.ir

 +

I dis­cov­ered this site some months pre­vi­ous to dis­cov­er­ing cat-v.org. Per­haps I had found it when search­ing for vi im­ple­men­ta­tions, for there was a time dur­ing which I searched for text ed­i­tors for the sake of ex­ploratory en­joy­ment. In any case, the soft­ware de­vel­oped by this site's owner, Ali Gho­lami Rudi, con­tin­u­ally amazes me.

+

Fore­most, his im­ple­men­ta­tion and par­tial port of Joseph Os­sana and Brian Kernighan's troff is ex­cel­lent. I use it for most doc­u­ments that need be more glo­ri­ous than a UTF-8 text file. This type­set­ting sys­tem en­ables me to cre­ate beau­ti­ful doc­u­ments, and its usage con­tin­u­ally sparks my in­ter­est in font de­sign and data pre­sen­ta­tion. On a tech­ni­cal level:

+ +

Each of the fea­tures above are use­ful in prac­tice, with an ar­ti­cle of my school work serv­ing as a real ex­am­ple of a doc­u­ment ben­e­fit­ting from the above fea­tures ap­pli­ca­ble to the Latin al­pha­bet.

+

His C com­piler suite, fea­tur­ing an assem­ber, link­er, stan­dard li­braries, and a com­pil­er, for Linux op­er­at­ing sys­tems run­ning on ei­ther ARM or x86 ar­chi­tec­ture, is both small and largely standard-compli­ant. Ad­mit­tedly, too much of the world's code is de­signed around GNU's com­piler suite for this com­piler suite to act a drop-in re­place­ment in a ma­jor­ity of C pro­jects, how­ever it is in and of it­self very us­able.

+

Ali Gho­lami Rudi uses Linux, and does not use Xorg. Restrict­ing him­self from con­ven­tional graph­ics sup­port, he de­vel­ops tools that make his predica­ment more pleas­ant. He main­tains a pro­gram that wraps around ex­ist­ing doc­u­ment view­ing pro­grams so as to view PDF and EPUB doc­u­ments within the Linux frame­buffer. He reg­u­larly de­vel­ops a ter­mi­nal em­u­la­tor that al­lows for the usage of TrueType fonts in the Linux frame­buffer. He's come to use vi, and so he main­tains his own vi im­ple­men­ta­tion, that which is small, POSIX portable, and de­signed for UTF-8. His ad­mirable ef­forts often have use­ful and in­ter­est­ing re­sults.

+
+

alpinelinux.org

 +

In­trin­si­cally, Linux is a prob­lem­atic and error-prone hodge­podge of con­flict­ing de­signs, even if driven by good in­ten­tions. Linux comes to mind not for be­ing a clean or in­ge­nious Unix clone, but in­stead for be­ing a pop­u­lar and messy op­er­at­ing sys­tem backed by large cor­po­ra­tions.

+

Dis­dain aside, there are ex­am­ples of good de­sign among the mess, and Alpine Lin­ux is one such ex­am­ple. Im­por­tantly, GNU's soft­ware is largely averted, with de­pen­dence falling upon their li­brary only for the sur­pris­ingly portable binu­tils and GCC, those which a com­pi­la­tion en­vi­ron­ment is often com­prised of, even if POSIX need be brought along with it. The C stan­dard li­brary used is musl, that which is standards-compli­ant, small, and other­wise strives for cor­rect­ness, even when that pur­suit leads to in­com­pat­i­bil­i­ties with GNU's libc. The usual Unix-borne util­i­ties are pro­vided by busy­box. Though busy­box's code is less than glam­orous – see the end­ing min­utes of this pre­sen­ta­tion given by its pre­vi­ous main­tain­er – it is small and ma­ture, and cer­tainly more us­able than the usual se­lec­tion, GNU's core­uti­ls. Alpine Linux's in­stal­la­tion im­ages are gen­er­ally less than 200 MiB in bi­nary size, al­low­ing for RAM boot­ing to be a sane de­fault. The soft­ware pack­ages avail­able in the repos­i­to­ries are nu­mer­ous, and the pack­age man­age­ment soft­ware is ex­pe­di­ent. Though the distribution-specific doc­u­men­ta­tion does have some rough edges, it is ex­ten­sive.

+

There are mul­ti­ple Linux dis­tri­bu­tions that try to do bet­ter than GNU's libc and core­utils, how­ever Alpine is the only one I've no­ticed to put each of Linux's many pieces to­gether so that the sys­tem works well in prac­tice. In par­tic­u­lar, Alpine Linux is the only Linux dis­tri­bu­tion that does not use glibc that I've been able to wran­gle into run­ning Xorg. The mess of KISS Linux's many split repos­i­to­ries and sparse doc­u­men­ta­tion causes more woes than re­quired of a min­i­mally boot­strapped op­er­at­ing sys­tem. Oa­sis Lin­ux is amaz­ingly am­bi­tious, par­tic­uarly for pre­fer­ring cproc over GCC or clang, yet too un­der­baked to feel use­ful. TinyCore Lin­ux boots to RAM, and its mod­ern in­car­na­tions boast smaller size than any other Linux dis­tri­bu­tion. Un­for­tu­nately, a lack of good doc­u­men­ta­tion averts me from its use, de­spite hav­ing tinkered with it for many hours. The gap be­tween toy and ready prod­uct may be bridged by good doc­u­men­ta­tion. A move away from glibc would be ideal, how­ever sec­ondary to the doc­u­men­ta­tion is­sue. As a side note: I imag­ine glibc is one of the great­est causes of in­crease in bi­nary size from re­lease to re­lease, for it is fa­mously in­fla­tion­ary. What was once 11 MiB – TinyCore Linux 3.0 – is now 21 MiB – TinyCore Linux 13.0.

+

Linux is messy, and im­prove­ment is ex­tra messy, which has done well to feed De­bian and Red Hat's pop­u­lar­ity; De­bian and Red Hat are ma­ture, and rarely change, and so the same quirks mas­tered years ago con­tin­u­ally ap­ply, for bet­ter and worse. Though there are many dis­tri­bu­tions that try to do bet­ter, and oc­ca­sion­ally do achieve bet­ter­ment, a ma­jor­ity of such dis­tri­bu­tions are gen­er­ally too mal­leable or ob­scure to be re­li­able. Alpine Linux ap­pears to be the only Linux dis­tri­bu­tion in any po­si­tion to upset the fre­quency of use of GNU's C stan­dard li­braries and sys­tem util­i­ties in ac­tual prac­tice, be­ing both well-documented and ma­ture.

+
+

bellard.org

 +

I found Fabrice Bel­lard's web site dur­ing the year 2021. I was amazed by how much could be ac­com­plished by some­one both ded­i­cated and cre­ative.

+

Fabrice Bel­lard started what has be­come the me­dia en­cod­ing soft­ware, ffm­peg. A sub­set of ffm­peg, libav­codec, has be­come a core part of many pieces of soft­ware, with there be­ing a long list of such soft­ware, main­tained by wikipedia con­trib­u­tors. On a per­sonal level, ffm­peg has served as soft­ware for record­ing video, record­ing au­dio, the other­wise en­cod­ing of im­ages and video and au­dio, and in par­tic­u­lar for en­cod­ing an­i­ma­tions from im­ages. If not for it, I doubt the cur­rent ex­is­tence of a suit­able re­place­ment.

+

Fabrice Bel­lard also started the Linux em­u­la­tion soft­ware, QEMU. QEMU paired with KVM is a go-to when need­ing to em­u­late an op­er­at­ing sys­tem with native-ish per­for­mance. Peo­ple who tinker use it quite a bit, and I imag­ine there are some busi­nesses whose in­fras­truc­ture de­pends upon QEMU.

+

An en­trant into The In­ter­na­tional Ob­fus­cated C Code Con­test built upon, tiny­cc has be­come a ma­ture C99 com­piler. It is about an order of mag­ni­tude faster than GCC, and pro­duces rea­son­ably op­ti­mal code. C code can be ei­ther com­piled or in­ter­pret­ed, with the in­ter­preter func­tion­al­ity be­ing baked well enough to be ac­tu­ally use­ful dur­ing de­vel­op­ment. When us­ing ei­ther Win­dows AME, Alpine Linux, or OpenBSD, this is my first choice of C com­piler.

+

Some lesser known how­ever ex­tremely im­pres­sive ex­am­ples of his pro­gram­ming prowess are listed at the in­dex of his site. Some par­tic­u­larly eye-catching ones in­clude

+ +
+

other.stanleylieber.com

 +

I found other.stan­leylieber.com after travers­ing web sites re­gard­ing 9front, the fore­most be­ing cat-v.org and 9front.org. I first en­coun­tered it dur­ing the year 2022. This site en­cour­ages the best kind of doom scrolling. Image after im­age, chances are good that one of ev­ery few im­ages strikes in­ter­est. That sort of con­sis­tent qual­ity buys trust, and that trust may be spent in con­tin­ued viewer at­ten­tion. It's a sort of magic that I'd like to cap­ture.

+
+

openbsd.org

 +

Hav­ing men­tioned above that Linux is a mess, it feels suit­able to now ex­plain a Unix deriva­tive that is not. OpenBSD split from NetBSD 1.0 in 1995, which in turn was based upon 4.4BSD-Lite, which in turn was based upon twenty-odd years of de­vel­op­ment upon a Unix Ver­sion 6 in­stal­la­tion per­formed at Univer­sity of Cal­i­for­nia, Berke­ley. In the time be­tween 1995 and now, OpenBSD has be­come an op­er­at­ing sys­tem that is stable, se­cure, and ex­cel­lently doc­u­mented. The man­u­als are con­cise with­out er­ring on be­ing terse, the sys­tem de­faults are sane and se­cure, and things do not break often.

+

Glit­ter­ing gen­er­al­i­ties pre­sented, some real ex­am­ples may pro­vide some va­lid­ity to the claims given. Each pro­gram purpose-written for the dis­tri­bu­tion has a man page writ­ten in a con­sis­tent style, fea­tur­ing English that is ap­pro­pri­ately for­mal, a unique fea­ture among Unix clones. Linux in par­tic­u­lar often fea­tures man pages that are too long to grok and poorly writ­ten – com­monly those writ­ten for GNU's soft­ware – or too lit­tle more than a list of op­tions – most no­tably busy­box. On OpenBSD, for those ex­ter­nal pro­grams that may be in­cluded in an in­stal­la­tion by way of file sets, pack­ages served by the repos­i­to­ries, or the ports tree, all doc­u­men­ta­tion is in­cluded, that much be­ing the best that can be rea­son­ably ex­pected. The pro­gram­mer's doc­u­men­ta­tion – so as to be ex­plicit, this is one such page – is sin­cerely bet­ter writ­ten than any other set I've en­coun­tered.

+

Op­tions that don't make sense to be en­abled by de­fault are not en­abled by de­fault. Au­dio record­ing is dis­abled, video record­ing is dis­abled, and dae­mons in­stalled are not sud­denly marked to run at boot. This last point may feel ob­vi­ous, how­ever I dis­tinctly re­mem­ber De­bian Linux ex­hibit­ing the op­po­site be­hav­ior. There was a time dur­ing which a younger and less aware ver­sion of my­self had apache start­ing upon each boot of my lap­top PC.

+

Never has OpenBSD pre­sented me with an is­sue that feels ar­bi­trary. In­stal­la­tion makes sense, post-instal­la­tion makes sense, with wifi setup be­ing par­tic­u­larly well doc­u­ment­ed, and reg­u­lar usage makes sense. Th­ese are vague qual­i­ties that de­scribe gen­eral feel­ings, with those gen­eral feel­ings be­ing my fo­cus. There is a sense of com­fort that eludes any Linux dis­tri­bu­tion I've used. It's a bor­ing com­fort, a stable com­fort, a good one.

+

POSIX con­for­mance com­pletes this op­er­at­ing sys­tem. It is not a for­got­ten toy, or a promis­ing dream, but a real and main­tained prod­uct, com­pat­i­ble with real pro­grams. A list of some that I value fol­lows.

+ +

The pro­grams that come with the dis­tri­bu­tion and are de­vel­oped by the dis­trib­u­tors are ma­ture. ed and sh are each de­signed for hu­man use, as op­posed to busy­box's maimed ed im­ple­men­ta­tion, or De­bian's Almquist Shell. The vi im­ple­men­ta­tion han­dles UTF-8 unicode, while also not tak­ing 20 or more MiB of bi­nary space. This is not the norm on mod­ern Unix; usu­ally, ei­ther the very large Vim or the Unicode-mangling busy­box vi are used. For those who crave emacs, there is an orig­i­nal mi­cro emacs im­ple­men­ta­tion in­cluded with the dis­tri­bu­tion. So as to pre­vent carpal tun­nel caused by re­peated use of CTRL on an ANSI or ISO PC key­board, I rec­om­mend remap­ping CAPS LOCK to the left CTRL key, as doc­u­mented here. For those who have con­tent to host, OpenBSD has its own HTTP server, and its own SSL im­ple­men­ta­tion to match it. OpenBSD has its own sound sys­tem, its own man page pro­grams, its own kernel-resident vir­tual ma­chine soft­ware, and most fa­mously, its own SSH im­ple­men­ta­tion. Not only do these im­ple­men­ta­tions mark past cre­ative ef­fort, for their de­vel­op­ment is on­go­ing. Re­cent re­leases are an­nounced first by mail­ing list, which are then often re-announced on the web. Devel­op­ment is con­sis­tently con­stant.

+

There was a sin­gle fea­ture that ce­mented my de­ci­sion to stick with OpenBSD. Aside from Xorg's in­stal­la­tion be­ing largely au­to­matic, the touch­pad driver worked. When us­ing De­bian, the de­fault touch­pad driver was … aw­ful. I found a sin­gu­lar al­ter­na­tive driver, that which worked about as aw­fully. De­spite hag­gling with xin­put, it never felt good to use. Months after the fact, I found some magic words which work to bet­ter the be­hav­ior of one of those drivers, Sy­napics: syn­client AccelFactor=0, and for those who like tap-to-click, syn­client TapButton1=1. I suf­fered the same is­sues on Alpine Linux, and have now con­firmed sim­i­lar be­hav­ior on CRUX Linux. And yet, upon in­stalling OpenBSD and then start­ing Xorg, and then mov­ing the mouse, it felt good! There was no chop­pi­ness; the move­ment was smooth. Though there was some mouse ac­cel­er­a­tion I did not like, that was sim­ple enough to dis­able via xin­put, after which the touch­pad be­hav­ior has been per­fect, far bet­ter than any­thing I've found be­fore or since.

+

OpenBSD pro­vides my best pre­ferred dig­i­tal work en­vi­ron­ments, both on lap­top and desk­top hard­ware. For many months, a 12-or-so year-old lap­top – of this make and mod­el – dual boot­ing be­tween Alpine Linux and OpenBSD by means of GRUB has per­formed grace­fully – they re­ally don't make lap­top key­boards the way they used to! On a desk­top PC, a dual boot be­tween Win­dows AME and OpenBSD by means of rEFInd serves well.

+
+

Envisioning Information

 +

I found this book after hav­ing read about its au­thor, Ed­ward Tufte, in the 9front doc­u­men­ta­tion. Hav­ing come to love 9front's text ed­i­tors – sam and acme, I felt in­clined to read some of the in­spi­ra­tional work. Un­der­stand­ing that sam and acme's de­signs were prod­ucts of the 1990s, I was drawn to­wards En­vi­sion­ing In­for­ma­tion, the work that Ed­ward Tufte pub­lished in 1990. I ob­tained a dig­i­tal copy, trans­ferred it to a 2013 iPad, and over the course of some weeks, read.

+

What I found within the pages con­tin­u­ally earned my at­ten­tion, and then earned my earnest thought. A ma­jor­ity of the pages fea­ture ex­am­ples of ei­ther ex­cel­lent or poor data pre­sen­ta­tion, along with dis­cus­sion and anal­y­sis of the given ex­am­ples. A purely tex­tual ex­cerpt that par­tic­u­larly struck me fol­lows.

+
+

What about con­fus­ing clut­ter? In­for­ma­tion over­load? Doesn't data have to be “boiled down” and “simplified”? Th­ese com­mon ques­tions miss the point, for the quan­tity of de­tail is an is­sue com­pletely sep­a­rate from the dif­fi­culty of read­ing. Clut­ter and con­fu­sion are fail­ures of de­sign, not at­tributes of in­for­ma­tion. Often the less com­plex and less sub­tle the line, the more am­bigu­ous and less in­ter­est­ing is the read­ing. Strip­ping the de­tail out of data is a style based on per­sonal pref­er­ence and fash­ion, con­sid­er­a­tions ut­terly in­dif­fer­ent to sub­stan­tive con­tent. … So much for the con­ven­tional, facile, and false equa­tion: sim­ple­ness of data and de­sign = clar­ity of read­ing. Sim­ple­ness is an­other aes­thetic pref­er­ence, not an in­for­ma­tion dis­play strat­egy, not a guide to clar­ity. What we seek in­stead is a rich tex­ture of data, a com­par­a­tive con­text, an un­der­stand­ing of com­plex­ity re­vealed with an econ­omy of means. … But, fi­nally, the deep­est rea­son for dis­plays that por­tray com­plex­ity and in­tri­cacy is that the worlds we seek to un­der­stand are com­plex and in­tri­cate.
+ — Ed­ward Tufte, En­vi­sion­ing In­for­ma­tion, page 51

+
+

After read­ing and thor­oughly en­joy­ing this book, I found my­self try­ing an es­say of his, ti­tled The Cog­ni­tive Style of Pow­er­point: Pitch­ing Out Cor­rupts Within. I found my­self en­amored in a way sim­i­lar to my re­cent ex­pe­ri­ence with En­vi­sion­ing In­for­ma­tion, though fo­cused on a new topic upon which I was also une­d­u­cated. It is here that I came to un­der­stand the value of real para­graphs. A tri­fecta of ex­cerpts fol­lows.

+
+

In the re­ports, ev­ery sin­gle text-slide uses bullet-outlines with 4 to 6 levels of hier­ar­chy. Then an­other multi-level list, an­other bu­reau­cracy of bul­lets, starts afresh for a new slide. How is it that each elab­o­rate ar­chi­tec­ture of thought al­ways fits ex­act­ly on one slide? The rigid slide-by-slide hier­ar­chies, in­dif­fer­ent to con­tent, slice and dice the ev­i­dence into ar­bi­trary com­part­ments, pro­duc­ing an anti-narra­tive with choppy con­ti­nu­ity. Medieval in its pre­oc­cu­pa­tion with hier­ar­chi­cal dis­tinc­tions, the Pow­erPoint for­mat sig­nals ev­ery bul­let's sta­tus in 4 or 5 dif­fer­ent si­mul­ta­ne­ous ways: by the order in se­quence, ex­tent of in­dent, size of bul­let, style of bul­let, and size of type as­so­ci­ated with var­i­ous bul­lets. This is a lot of in­se­cure for­mat for a sim­ple engi­neer­ing prob­lem. The for­mat re­flects a com­mon con­cep­tual er­ror in an­a­lytic de­sign: in­for­ma­tion ar­chi­tec­tures mimic the hier­ar­chi­cal struc­ture of large bu­reau­cra­cies pitch­ing the in­for­ma­tion. Con­way's Law again. In their re­port, the Columbia Ac­ci­dent In­ves­ti­ga­tion Board found that the dis­tinc­tive cog­ni­tive style of Pow­erPoint re­in­forced the hier­ar­chi­cal fil­ter­ing and bi­ases of the NASA bu­reau­cracy dur­ing the cru­cial pe­riod when the Columbia was dam­aged but still func­tion­ing … At the same time, lower-level NASA engi­neers were writ­ing about the pos­si­ble dan­gers to the Columbia in sev­eral hun­dred emails, with the Boe­ing re­ports in PP for­mat some­times at­tached. The text of about 90% of these emails sim­ply used sen­tences se­quen­tially ordered into para­graphs; 10% used bul­let lists with 2 or 3 levels. Th­ese engi­neers were able to rea­son about the is­sues with­out em­ploy­ing the baroque hier­ar­chi­cal out­lines of the orig­i­nal PP pitches. Good for them.
+ — Ed­ward Tufte, The Cog­ni­tive Style of Pow­er­point: Pitch­ing Out Cor­rupts Within, 2nd Edi­tion, page 12 +
+
+ Ger­st­ner's blunt ac­tion shut­ting down the pro­jec­tor sug­gests that there are bet­ter tools for do­ing busi­ness anal­y­sis than read­ing aloud from bul­let lists: “Let's just talk about your busi­ness.” In­deed, Ger­st­ner later asked IBM ex­ec­u­tives to write out their busi­ness strate­gies in long­hand us­ing the pre­sen­ta­tion method­ol­ogy of sen­tences, with sub­jects and pred­i­cates, nouns and verbs, which then com­bine se­quen­tially to form para­graphs, an an­a­lytic tool demon­stra­tively bet­ter than slide­ware bul­let lists. “Let's just talk about your busi­ness” indi­cates a thought­ful ex­change of in­for­ma­tion, a mu­tual in­ter­play be­tween speaker and au­di­ence, rather than a pitch made by a power pointer point­ing to bul­lets. Pow­erPoint is presenter-oriented, not content-oriented, not audience-orient­ed. PP ad­ver­tis­ing is not about con­tent qual­ity, but rather pre­sen­ter ther­apy: “A cure for the pre­sen­ta­tion jit­ters.” “Get your­self or­ga­nized.” “Use the Au­toCon­tent Wizard to fig­ure out what you want to say.”
+ — Ed­ward Tufte, The Cog­ni­tive Style of Pow­er­point: Pitch­ing Out Cor­rupts Within, 2nd Edi­tion, page 4 +
+
+ At a talk, pa­per hand­outs of a tech­ni­cal re­port ef­fec­tively show text, data graph­ics, im­ages. Printed ma­te­ri­als bring in­for­ma­tion trans­fer rates in pre­sen­ta­tions up to that of ev­ery­day ma­te­rial in news­pa­per sports and fi­nan­cial pages, books, and in­ter­net news sites. An ex­cel­lent pa­per size for pre­sen­ta­tion hand­outs is A3, 30 by 42 cm or about 11 by 17 inches, folded in half to make 4 pages. That one piece of pa­per, the 4-pager, can show im­ages with 1,200 dpi res­o­lu­tion, up to 60,000 char­ac­ters of words and num­bers, de­tailed ta­bles wor­thy of the sports pages, or 1,000 sparkline sta­tis­ti­cal graph­ics show­ing 500,000 num­bers. That one piece of pa­per shows the content-equiva­lent of 50 to 250 typ­i­cal PP slides.
+ — Ed­ward Tufte, The Cog­ni­tive Style of Pow­er­point: Pitch­ing Out Cor­rupts Within, 2nd Edi­tion, page 30

+
+

It is through these para­graphs and others that I came to re­al­ize the inap­pro­pri­acy of deeply heirar­chi­cal lists, that re­al­iza­tion hav­ing prompted me to rewrite this page of ap­pre­ci­a­tions. For the sake of com­par­i­son, a copy of the pre­vi­ous it­er­a­tion, last touched 2023 march 31, is kept.

+
+

Advent of Code

 +

Ad­vent of Code has taught me how to use a struct, why and when data struc­tures should be cal­loc'd in­stead of dumped on the stack, how to use free, what “Di­jk­stra's Al­go­rithm” is, and a lot of lit­tle de­tails in-between. Par­tic­i­pat­ing has closed the gap be­tween the­ory and prac­tice, and for that I am very thank­ful. Linked here is a video snip­pet of an even­tual so­lu­tion after three hours of at­tempt.

+
+

miscellany

 + +
+ + -- cgit v1.2.3