Monorepo for Aesthetic.Computer
aesthetic.computer
add DA/ES/ZH translations for 6 papers missing them
Adds Danish, Spanish, and Chinese .tex translations for:
identity, futures, score-analysis, open-schools, kidlisp-cards, calarts
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
+7411
+203
papers/arxiv-calarts/calarts-da.tex
+203
papers/arxiv-calarts/calarts-da.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\setmainfont{Latin Modern Roman}
8
+
\setsansfont{Latin Modern Sans}
9
+
\newfontfamily\acbold{ywft-processing-bold}[Path=../../system/public/type/webfonts/,Extension=.ttf]
10
+
\newfontfamily\aclight{ywft-processing-light}[Path=../../system/public/type/webfonts/,Extension=.ttf]
11
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
12
+
13
+
\usepackage{xcolor}
14
+
\usepackage{titlesec}
15
+
\usepackage{enumitem}
16
+
\usepackage{booktabs}
17
+
\usepackage{tabularx}
18
+
\usepackage{fancyhdr}
19
+
\usepackage{hyperref}
20
+
\usepackage{graphicx}
21
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
22
+
\usepackage{ragged2e}
23
+
\usepackage{microtype}
24
+
\usepackage{natbib}
25
+
26
+
% === PSYCHO watermark ===
27
+
\usepackage{eso-pic}
28
+
\usepackage{tikz}
29
+
\AddToShipoutPictureBG{%
30
+
\begin{tikzpicture}[remember picture, overlay]
31
+
% --- Pals logo: large, top-left, rotated, semi-opaque ---
32
+
\node[opacity=0.06, anchor=north west, rotate=-15]
33
+
at ([xshift=-1.2cm, yshift=1.2cm]current page.north west)
34
+
{\includegraphics[width=10cm]{pals}};
35
+
% --- "PSYCHO" text in Processing Light font ---
36
+
\node[opacity=0.12, rotate=45, anchor=center]
37
+
at (current page.center)
38
+
{{\aclight\fontsize{2.5cm}{3cm}\selectfont\color{acpink} PSYCHO}};
39
+
\end{tikzpicture}%
40
+
}
41
+
42
+
\definecolor{acpink}{RGB}{180,72,135}
43
+
\definecolor{acpurple}{RGB}{120,80,180}
44
+
\definecolor{acdark}{RGB}{64,56,74}
45
+
\definecolor{acgray}{RGB}{119,119,119}
46
+
47
+
\hypersetup{colorlinks=true,linkcolor=acpurple,urlcolor=acpurple,citecolor=acpurple,
48
+
pdftitle={CalArts, Callouts og Papers: Kunstskolen som operativsystem}}
49
+
50
+
\titleformat{\section}{\normalfont\bfseries\normalsize\uppercase}{\thesection.}{0.5em}{}
51
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
52
+
\titleformat{\subsection}{\normalfont\bfseries\small}{\thesubsection}{0.5em}{}
53
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
54
+
55
+
\pagestyle{fancy}\fancyhf{}
56
+
\renewcommand{\headrulewidth}{0pt}
57
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{PSYCHO-artikel --- ikke til citation}}
58
+
\fancyfoot[C]{\footnotesize\thepage}
59
+
60
+
\newcommand{\ac}{\textsc{Aesthetic Computer}}
61
+
\newcommand{\np}{\textsc{notepat}}
62
+
63
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
64
+
\setlength{\columnsep}{1.8em}
65
+
\setlength{\parindent}{1em}
66
+
\setlength{\parskip}{0.3em}
67
+
68
+
\tolerance=800
69
+
\emergencystretch=1em
70
+
\hyphenpenalty=50
71
+
72
+
\begin{document}
73
+
74
+
\twocolumn[{%
75
+
\begin{center}
76
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
77
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} CalArts, Callouts og Papers}\par
78
+
\vspace{0.2em}
79
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} Kunstskolen som operativsystem}\par
80
+
\vspace{0.6em}
81
+
{\normalsize @jeffrey}\par
82
+
{\small\color{acgray} Aesthetic.Computer}\par
83
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
84
+
\vspace{0.3em}
85
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
86
+
\vspace{0.6em}
87
+
\rule{\textwidth}{1.5pt}
88
+
\vspace{0.5em}
89
+
\end{center}
90
+
91
+
\begin{center}
92
+
{\small\color{acpink}\textbf{[ PSYCHO-artikel --- ikke til citation ]}}
93
+
\end{center}
94
+
\vspace{0.3em}
95
+
96
+
\begin{quote}
97
+
\small\noindent\textbf{Abstrakt.}
98
+
CalArts (California Institute of the Arts) blev grundlagt i 1961 af Walt Disney som en total kunstskole---et sted hvor animation, musik, teater, dans, film og billedkunst kunne eksistere under ét tag og krydsbefrugte hinanden uden disciplinære mure. Denne artikel argumenterer for, at CalArts fungerer som et \emph{operativsystem} for kreativ produktion: et sæt grundlæggende antagelser om, hvad kunst er, hvordan den undervises, og hvad en kunstner bør blive. Vi undersøger skolens unikke kultur af ``callouts''---kritikken, gangsamtalen, den institutionelle udfordring---og hvordan denne mundtlige tradition producerer viden, der ikke kan skrives ned. Vi vender os derefter mod selve artiklen: hvorfor denne serie af akademiske artikler eksisterer, hvad det betyder for en kunstner-programmør at skrive teori, og om artikelformen i sig selv er en slags callout---en offentlig udfordring der tvinger idéer til at stå blottede i det åbne. CalArts lærte forfatteren at lave arbejde der svarer igen. Disse artikler er det arbejde der svarer igen i et register, som kunstverdenen ikke forventede.
99
+
\end{quote}
100
+
\vspace{0.5em}
101
+
}]
102
+
103
+
\section{Disney-maskinen}
104
+
105
+
Walt Disney grundlagde CalArts i 1961 ved at sammenlægge Chouinard Art Institute og Los Angeles Conservatory of Music. Han ønskede en kunstskole der fungerede som hans studie: alle discipliner i én bygning, med delte værktøjer og idéer. Disney døde før Valencia-campus åbnede i 1971, men den struktur han krævede---ingen vægge mellem afdelinger, fælles faciliteter, en kultur af tværfaglig kollision---formede alt der fulgte.
106
+
107
+
Den grundlæggende vision var industriel. Disney havde brug for animatorer der kunne tegne, musikere der forstod timing, skuespillere der kunne improvisere til et storyboard. Skolen var en talentpipeline for studiet~\citep{singerman1999art}. Men noget andet skete. Det fakultet som Disneys arvinger ansatte---deriblandt Allan Kaprow, Judy Chicago, John Baldessari, Miriam Schapiro, Nam June Paik---forvandlede den tværfaglige struktur til et laboratorium for efterkrigstidens amerikanske kunst. Maskinen Disney byggede til at producere animatorer blev en maskine der producerede konceptkunstnere, feministisk performance, videokunst og til sidst den generation der ville definere post-studie-praksis.
108
+
109
+
Operativsystem-analogien er præcis. Et OS laver ikke softwaren; det giver det miljø hvori software kan køre. CalArts laver ikke kunsten; det giver betingelserne---rumlige, sociale, pædagogiske---under hvilke en bestemt slags kunstner bliver mulig. Skift OS og du ændrer hvad der kan skabes.
110
+
111
+
\section{Callouts}
112
+
113
+
\subsection{Kritikken som mundtlig tradition}
114
+
115
+
Kritikken på CalArts er ikke en karakter. Det er et callout. Nogen hænger et værk op på væggen, og rummet svarer---ikke med rubrikker eller læringsmål men med den uskrevne, til tider brutale, til tider generøse ærlighed fra mennesker der har kigget på kunst sammen længe nok til at springe høflighedsfraserne over.
116
+
117
+
\citet{elkins2001why} argumenterer for, at kritikken er uunderviselig på samme måde som kunst er uunderviselig: det der sker i en god kritik kan ikke reduceres til en metode. Det er en mundtlig tradition. Den viden der produceres i en tre timers kritik eksisterer kun i rummet. Den kan ikke skrives ned uden at blive til noget andet---et resumé, en anmeldelse, en dom. Kritikken er live. Den er en performance af opmærksomhed~\citep{hooks1994teaching}.
118
+
119
+
CalArts-kritikker er berømte for deres intensitet. Skolens lille størrelse (ca. 1.500 studerende), campus med beboelse og tværfaglige struktur betyder, at en malers kritik kan inkludere en komponist, en animator, en filmskaber og en danser. Feedbacken er ikke disciplinspecifik. Den er \emph{perceptuel}: hvad gør dette ved min krop, mit øre, min fornemmelse af tid? Callout'et er ikke ``det er god maleri.'' Callout'et er ``det er levende'' eller ``det er dødt.''
120
+
121
+
\subsection{Gangviden}
122
+
123
+
Det meste af hvad CalArts underviser sker uden for klasseværelset. Gangene i hovedbygningen---en brutalistisk megastruktur tegnet af Ladd \& Kelsey---fungerer som en uformel salon. En komponist går forbi en billedhuggers åbne atelier og hører en lyd der ændrer dem begges arbejde. En filmskaber viser daglige optagelser klokken 2 om natten, og en danser vandrer ind og begynder at improvisere til optagelserne.
124
+
125
+
Dette er ikke pensum. Det er \emph{arkitektur}. Bygningen tvinger kollision. Kantinen (den eneste) tvinger alle ind i det samme rum. Gangene er brede nok til at stoppe op og tale. Atelierne er åbne. Øverummene lækker lyd. Bygningen er et instrument der spiller de mennesker der er inde i den.
126
+
127
+
\citet{deduve1994attitude} identificerer tre paradigmer inden for kunstuddannelse: akademiet (talent-imitation), Bauhaus (kreativitet-medie-opfindelse) og efterkrigstidens kunstskole (holdning-praksis-dekonstruktion). CalArts opfandt et fjerde: \emph{nærhed}. Anbring forskellige discipliner tæt nok på hinanden, og de kontaminerer hinanden. Kontamineringen er uddannelsen.
128
+
129
+
\subsection{Den institutionelle udfordring}
130
+
131
+
CalArts kører på udfordringer. Ikke eksplicitte---ingen siger ``jeg udfordrer dig.'' Men kulturen er organiseret omkring en udfordringsstruktur: kan du lave noget der holder i et rum fuldt af mennesker der er bedre end dig? Kan du præsentere arbejde der overlever callout'et?
132
+
133
+
Dette er forskelligt fra tech-skolens sprint review, hvor arbejde evalueres mod user stories og acceptkriterier~\citep{vinsel2020innovation}. CalArts-udfordringen har ingen kriterier. Der er ingen rubrik. Spørgsmålet er ikke ``opfylder dette briefet?'' Spørgsmålet er ``behøver dette at eksistere?'' Udfordringen er eksistentiel, ikke funktionel.
134
+
135
+
Udfordringen opererer også mellem afdelinger. En musikstuderende der laver et værk med video udfordrer filmstuderende til at være opmærksomme. En danser der koder en interaktiv installation udfordrer kunststuderende til at tage teknologi seriøst. Udfordringen er mekanismen for tværfaglig kontaminering. Den siger: din disciplin er ikke tilstrækkelig. Kom og leg i min.
136
+
137
+
\section{Hvorfor artikler}
138
+
139
+
\subsection{Artiklen som callout}
140
+
141
+
Denne artikelserie---tyve artikler skrevet på tre uger---er i sig selv et callout. Den siger: en kunstner-programmør kan skrive teori. Ikke ``teori-light,'' ikke ``kunstnerstatements med citationer,'' men rigtige artikler med rigtige argumenter og rigtige bibliografier der engagerer sig med rigtig forskning.
142
+
143
+
Kunstverdenen forventer ikke dette. Kunstnere forventes at lave værker og lade kritikere skrive om dem. Arbejdsdelingen er klar: kunstnere producerer, kritikere forklarer, historikere kontekstualiserer. Når en kunstner skriver teori, er den institutionelle respons mistænksomhed. Er det rigtig forskning? Er det forfængelighedsudgivelse? Er det kunst?
144
+
145
+
Svaret er: det er ligegyldigt. Artiklen er et callout. Den tvinger idéerne til at stå i det åbne, udsat for kritik, i et format som akademiet anerkender og kunstverdenen ikke kontrollerer. \citet{fraser2005critique} bemærkede, at institutionel kritik blev en institution. Disse artikler forsøger noget andet: ikke kritik af institutionen men \emph{brug} af institutionens eget format---den akademiske artikel---som kunstnerisk materiale.
146
+
147
+
\subsection{Artiklen som instrument}
148
+
149
+
En artikel er en teknologi. Den har et format (sektioner, citationer, abstrakt, bibliografi), et distributionssystem (tidsskrifter, preprints, arkiver) og en social protokol (fagfællebedømmelse, citation, respons). Som enhver teknologi kan den spilles.
150
+
151
+
\ac{} behandler stykket som den fundamentale enhed for kreativ erkendelse~\citep{scudder2026pieces}. Et stykke er en enkelt fil der eksporterer livscyklusfunktioner: \texttt{boot}, \texttt{paint}, \texttt{act}, \texttt{sim}. En artikel har den samme struktur: den booter (abstrakt), maler (argument), agerer (engagerer sig med tidligere arbejde) og simulerer (foreslår konsekvenser). Artiklen er et stykke skrevet i \LaTeX{} i stedet for JavaScript.
152
+
153
+
Dette er ikke en metafor. Artiklerne er bygget med den samme infrastruktur som softwaren: en CLI (\texttt{papers/cli.mjs}), inkrementelle builds, flersproget udrulning, automatiseret publicering. Artiklen \emph{er} software. Argumentet \emph{er} programmet.
154
+
155
+
\subsection{PSYCHO-betegnelsen}
156
+
157
+
Denne artikel er mærket PSYCHO. Ikke ``Arbejdsudkast,'' ikke ``Preprint,'' ikke ``Under bedømmelse.'' PSYCHO.
158
+
159
+
Betegnelsen er et callout til selve artikelformatet. Akademiske artikler lader som om de er neutrale---objektive rapporter over fund, skrevet i passiv form, stripet for personlighed. PSYCHO-mærket afviser denne prætention. Det siger: denne artikel har en stemme, den har en dagsorden, den har en temperatur. Den er ikke neutral. Den prøver ikke at være det.
160
+
161
+
Ordet ``psycho'' kommer fra det græske \textit{psykhe}---sjæl, sind, ånde. En PSYCHO-artikel er en artikel med en sjæl. Den ånder. Den har holdninger der ikke er afdæmpet med ``yderligere forskning er nødvendig.'' Den fremsætter påstande og udfordrer dig til at være uenig.
162
+
163
+
\section{CalArts og Aesthetic Computer}
164
+
165
+
\subsection{OS-arven}
166
+
167
+
Forfatteren gik på CalArts (MFA Art, 2012). Oplevelsen er det substrat hvorpå \ac{} er bygget. Ikke teknikkerne---CalArts underviser ikke i programmering---men \emph{antagelserne}: at discipliner bør kontaminere hinanden, at mediet ikke er pointen, at udfordringen er vigtigere end leverancen, at kunst er en måde at være i verden på snarere end et produkt der skal sendes.
168
+
169
+
\ac{} arver CalArts' operativsystem. Stykke-modellen---én fil, immediate-mode grafik, livscyklusfunktioner---er den digitale ækvivalent til det åbne atelier: alle kan se hvad du laver, alle kan forke det, alle kan kalde det ud. Det sociale netværk er organiseret omkring \emph{stier} (huskbare URL'er) snarere end feeds, på samme måde som CalArts er organiseret omkring gange snarere end algoritmer.
170
+
171
+
\np{}.com er den tydeligste CalArts-arv. Det er et instrument som alle kan spille, som ikke kræver træning, som belønner udforskning frem for ekspertise. Gangmødet---at snuble over en andens arbejde og blive forandret af det---er designmønsteret. Du skriver en URL. Du lander på et stykke. Du spiller det. Du går videre. Ingen feed. Ingen algoritme. Ingen metrikker. Bare nærhed.
172
+
173
+
\subsection{Kritikken går online}
174
+
175
+
At publicere disse artikler er en kritik. Rummet er internettet. Callout'et er offentligt. Arbejdet er blottet---ikke for et rum med femten mennesker der kender dig men for enhver med en browser og en holdning.
176
+
177
+
Dette er skræmmende på samme måde som en CalArts-kritik er skræmmende: du kan ikke kontrollere responsen. Arbejdet holder eller det gør det ikke. Udfordringen er den samme udfordring: behøver dette at eksistere?
178
+
179
+
\section{Imod neutralitet}
180
+
181
+
Den akademiske artikel lader som om den er et vindue---gennemsigtigt, der lader dig se forskningen bag det. Men ethvert vindue er også en ramme. Artikelformatet rammer ind hvad der kan siges: passiv form, afdæmpede påstande, ærbødighed over for tidligere arbejde, fiktionen om objektivitet~\citep{freire1970pedagogy}.
182
+
183
+
CalArts underviser det modsatte. Stå bag dit arbejde. Sig hvad du mener. Hvis du ikke kan forsvare det i rummet, er det ikke klar. Callout'et er en teknologi for ansvarlighed: det tvinger dig til at stå ved dine påstande foran mennesker der vil skubbe imod.
184
+
185
+
Disse artikler er skrevet i den ånd. De har en stemme. De fremsætter påstande. De citerer forskning ikke for at skjule sig bag den men for at argumentere med den, bygge på den, udfordre den til at svare. PSYCHO-betegnelsen er et flag: denne artikel lader ikke som om den er neutral. Den har en position. Den har en temperatur. Den står i rummet og venter på callout'et.
186
+
187
+
\citet{spivak2012aesthetic} argumenterer for, at æstetisk uddannelse træner fantasien for etisk solidaritet. CalArts gør dette---ikke gennem pensum men gennem nærhed, gennem udfordringen, gennem kritikken der tvinger dig til at se dit arbejde gennem en andens øjne. Disse artikler forsøger det samme i et andet medie: at træne læserens fantasi for en anden slags kreativ computing, én bygget på instrumenter snarere end feeds, på stykker snarere end produkter, på callouts snarere end engagementsmetrikker.
188
+
189
+
\section{Konklusion}
190
+
191
+
CalArts er et operativsystem. Dets kerne er nærhed. Dets shell er kritikken. Dets procesmodel er udfordringen. \ac{} kører på det samme OS, porteret fra det fysiske campus til browseren til bar metal~\citep{scudder2026ac, scudder2026os}.
192
+
193
+
Callout'et er mekanismen. Artiklen er formatet. PSYCHO-betegnelsen er temperaturen. Tilsammen siger de: kunst kan skrive teori, teori kan være kunst, og ingen af dem har brug for tilladelse fra de institutioner der hævder at eje dem.
194
+
195
+
Disse artikler er gangviden, endelig skrevet ned---velvidende at skriften ændrer dem, velvidende at kritikken aldrig ender, velvidende at udfordringen er pointen.
196
+
197
+
\vspace{0.5em}
198
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
199
+
200
+
\bibliographystyle{plainnat}
201
+
\bibliography{references}
202
+
203
+
\end{document}
+203
papers/arxiv-calarts/calarts-es.tex
+203
papers/arxiv-calarts/calarts-es.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\setmainfont{Latin Modern Roman}
8
+
\setsansfont{Latin Modern Sans}
9
+
\newfontfamily\acbold{ywft-processing-bold}[Path=../../system/public/type/webfonts/,Extension=.ttf]
10
+
\newfontfamily\aclight{ywft-processing-light}[Path=../../system/public/type/webfonts/,Extension=.ttf]
11
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
12
+
13
+
\usepackage{xcolor}
14
+
\usepackage{titlesec}
15
+
\usepackage{enumitem}
16
+
\usepackage{booktabs}
17
+
\usepackage{tabularx}
18
+
\usepackage{fancyhdr}
19
+
\usepackage{hyperref}
20
+
\usepackage{graphicx}
21
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
22
+
\usepackage{ragged2e}
23
+
\usepackage{microtype}
24
+
\usepackage{natbib}
25
+
26
+
% === PSYCHO watermark ===
27
+
\usepackage{eso-pic}
28
+
\usepackage{tikz}
29
+
\AddToShipoutPictureBG{%
30
+
\begin{tikzpicture}[remember picture, overlay]
31
+
% --- Pals logo: large, top-left, rotated, semi-opaque ---
32
+
\node[opacity=0.06, anchor=north west, rotate=-15]
33
+
at ([xshift=-1.2cm, yshift=1.2cm]current page.north west)
34
+
{\includegraphics[width=10cm]{pals}};
35
+
% --- "PSYCHO" text in Processing Light font ---
36
+
\node[opacity=0.12, rotate=45, anchor=center]
37
+
at (current page.center)
38
+
{{\aclight\fontsize{2.5cm}{3cm}\selectfont\color{acpink} PSYCHO}};
39
+
\end{tikzpicture}%
40
+
}
41
+
42
+
\definecolor{acpink}{RGB}{180,72,135}
43
+
\definecolor{acpurple}{RGB}{120,80,180}
44
+
\definecolor{acdark}{RGB}{64,56,74}
45
+
\definecolor{acgray}{RGB}{119,119,119}
46
+
47
+
\hypersetup{colorlinks=true,linkcolor=acpurple,urlcolor=acpurple,citecolor=acpurple,
48
+
pdftitle={CalArts, Callouts y Papers: La escuela de arte como sistema operativo}}
49
+
50
+
\titleformat{\section}{\normalfont\bfseries\normalsize\uppercase}{\thesection.}{0.5em}{}
51
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
52
+
\titleformat{\subsection}{\normalfont\bfseries\small}{\thesubsection}{0.5em}{}
53
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
54
+
55
+
\pagestyle{fancy}\fancyhf{}
56
+
\renewcommand{\headrulewidth}{0pt}
57
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{Artículo PSYCHO --- no citar}}
58
+
\fancyfoot[C]{\footnotesize\thepage}
59
+
60
+
\newcommand{\ac}{\textsc{Aesthetic Computer}}
61
+
\newcommand{\np}{\textsc{notepat}}
62
+
63
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
64
+
\setlength{\columnsep}{1.8em}
65
+
\setlength{\parindent}{1em}
66
+
\setlength{\parskip}{0.3em}
67
+
68
+
\tolerance=800
69
+
\emergencystretch=1em
70
+
\hyphenpenalty=50
71
+
72
+
\begin{document}
73
+
74
+
\twocolumn[{%
75
+
\begin{center}
76
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
77
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} CalArts, Callouts y Papers}\par
78
+
\vspace{0.2em}
79
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} La escuela de arte como sistema operativo}\par
80
+
\vspace{0.6em}
81
+
{\normalsize @jeffrey}\par
82
+
{\small\color{acgray} Aesthetic.Computer}\par
83
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
84
+
\vspace{0.3em}
85
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
86
+
\vspace{0.6em}
87
+
\rule{\textwidth}{1.5pt}
88
+
\vspace{0.5em}
89
+
\end{center}
90
+
91
+
\begin{center}
92
+
{\small\color{acpink}\textbf{[ Artículo PSYCHO --- no citar ]}}
93
+
\end{center}
94
+
\vspace{0.3em}
95
+
96
+
\begin{quote}
97
+
\small\noindent\textbf{Resumen.}
98
+
CalArts (California Institute of the Arts) fue fundado en 1961 por Walt Disney como una escuela de arte total---un lugar donde la animación, la música, el teatro, la danza, el cine y las bellas artes existirían bajo un mismo techo, polinizándose mutuamente sin muros disciplinarios. Este artículo argumenta que CalArts funciona como un \emph{sistema operativo} para la producción creativa: un conjunto de supuestos fundamentales sobre qué es el arte, cómo se enseña y en qué debería convertirse un artista. Examinamos la cultura única de ``callouts'' de la escuela---la crítica, la conversación de pasillo, el desafío institucional---y cómo esta tradición oral produce conocimiento que no puede escribirse. Luego nos dirigimos al artículo en sí: por qué existe esta serie de artículos académicos, qué significa que un artista-programador escriba teoría, y si la forma del artículo es en sí misma una especie de callout---un desafío público que obliga a las ideas a quedar expuestas a la intemperie. CalArts le enseñó al autor a hacer trabajo que responde. Estos artículos son ese trabajo respondiendo en un registro que el mundo del arte no esperaba.
99
+
\end{quote}
100
+
\vspace{0.5em}
101
+
}]
102
+
103
+
\section{La máquina Disney}
104
+
105
+
Walt Disney fundó CalArts en 1961 fusionando el Chouinard Art Institute y el Los Angeles Conservatory of Music. Quería una escuela de arte que funcionara como su estudio: todas las disciplinas en un edificio, compartiendo herramientas e ideas. Disney murió antes de que el campus de Valencia abriera en 1971, pero la estructura que exigió---sin muros entre departamentos, instalaciones compartidas, una cultura de colisión interdisciplinaria---definió todo lo que vino después.
106
+
107
+
La visión fundacional era industrial. Disney necesitaba animadores que supieran dibujar, músicos que entendieran el ritmo, actores que pudieran improvisar sobre un storyboard. La escuela era un conducto de talento para el estudio~\citep{singerman1999art}. Pero ocurrió algo más. El profesorado que contrataron los herederos de Disney---entre ellos Allan Kaprow, Judy Chicago, John Baldessari, Miriam Schapiro, Nam June Paik---convirtió la estructura interdisciplinaria en un laboratorio para el arte estadounidense de posguerra. La máquina que Disney construyó para producir animadores se convirtió en una máquina que producía artistas conceptuales, performance feminista, videoarte y, finalmente, la generación que definiría la práctica post-estudio.
108
+
109
+
La analogía del sistema operativo es exacta. Un SO no hace el software; proporciona el entorno en el que el software puede ejecutarse. CalArts no hace el arte; proporciona las condiciones---espaciales, sociales, pedagógicas---en las que un tipo particular de artista se vuelve posible. Cambia el SO y cambias lo que puede hacerse.
110
+
111
+
\section{Callouts}
112
+
113
+
\subsection{La crítica como tradición oral}
114
+
115
+
La crítica en CalArts no es una nota. Es un callout. Alguien pone un trabajo en la pared y la sala responde---no con rúbricas o resultados de aprendizaje sino con la honestidad no guionizada, a veces brutal, a veces generosa, de personas que han estado mirando arte juntas el tiempo suficiente como para saltarse las cortesías.
116
+
117
+
\citet{elkins2001why} argumenta que la crítica es inensenñable de la misma manera que el arte es inenseñable: lo que ocurre en una buena crítica no puede reducirse a un método. Es una tradición oral. El conocimiento producido en una crítica de tres horas existe solo en la sala. No puede escribirse sin convertirse en otra cosa---un resumen, una reseña, un juicio. La crítica es en vivo. Es una performance de la atención~\citep{hooks1994teaching}.
118
+
119
+
Las críticas de CalArts son famosas por su intensidad. El tamaño pequeño de la escuela (aproximadamente 1.500 estudiantes), el campus residencial y la estructura interdisciplinaria significan que la crítica de un pintor puede incluir a un compositor, un animador, un cineasta y un bailarín. La retroalimentación no es específica de la disciplina. Es \emph{perceptual}: ¿qué le hace esto a mi cuerpo, a mi oído, a mi sentido del tiempo? El callout no es ``esto es buena pintura.'' El callout es ``esto está vivo'' o ``esto está muerto.''
120
+
121
+
\subsection{Conocimiento de pasillo}
122
+
123
+
La mayor parte de lo que CalArts enseña ocurre fuera del aula. Los pasillos del edificio principal---una megaestructura brutalista diseñada por Ladd \& Kelsey---funcionan como un salón informal. Un compositor pasa frente al estudio abierto de un escultor y escucha un sonido que cambia el trabajo de ambos. Un cineasta proyecta tomas del día a las 2 AM y un bailarín entra y comienza a improvisar con el metraje.
124
+
125
+
Esto no es currículo. Es \emph{arquitectura}. El edificio fuerza la colisión. La cafetería (la única) obliga a todos a estar en la misma sala. Los pasillos son lo suficientemente anchos para detenerse y hablar. Los estudios están abiertos. Las salas de ensayo dejan escapar sonido. El edificio es un instrumento que toca a las personas que están dentro.
126
+
127
+
\citet{deduve1994attitude} identifica tres paradigmas de la educación artística: la academia (talento-imitación), la Bauhaus (creatividad-medio-invención) y la escuela de arte de posguerra (actitud-práctica-deconstrucción). CalArts inventó un cuarto: \emph{proximidad}. Pon disciplinas diferentes lo suficientemente cerca y se contaminan mutuamente. La contaminación es la educación.
128
+
129
+
\subsection{El desafío institucional}
130
+
131
+
CalArts funciona con desafíos. No explícitos---nadie dice ``te desafío.'' Pero la cultura está organizada alrededor de una estructura de desafío: ¿puedes hacer algo que se sostenga en una sala llena de personas mejores que tú? ¿Puedes presentar trabajo que sobreviva al callout?
132
+
133
+
Esto es diferente de la revisión de sprint de la escuela técnica, donde el trabajo se evalúa contra historias de usuario y criterios de aceptación~\citep{vinsel2020innovation}. El desafío de CalArts no tiene criterios. No hay rúbrica. La pregunta no es ``¿cumple esto con el brief?'' La pregunta es ``¿necesita esto existir?'' El desafío es existencial, no funcional.
134
+
135
+
El desafío también opera entre departamentos. Un estudiante de música que hace una pieza con video está desafiando a los estudiantes de cine a prestar atención. Un bailarín que programa una instalación interactiva está desafiando a los estudiantes de arte a tomar la tecnología en serio. El desafío es el mecanismo de contaminación interdisciplinaria. Dice: tu disciplina no es suficiente. Ven a jugar en la mía.
136
+
137
+
\section{Por qué artículos}
138
+
139
+
\subsection{El artículo como callout}
140
+
141
+
Esta serie de artículos---veinte artículos escritos en tres semanas---es en sí misma un callout. Dice: un artista-programador puede escribir teoría. No ``teoría-light,'' no ``declaraciones de artista con citas,'' sino artículos reales con argumentos reales y bibliografías reales que se involucran con investigación real.
142
+
143
+
El mundo del arte no espera esto. Se espera que los artistas hagan obra y dejen que los críticos escriban sobre ella. La división del trabajo es clara: los artistas producen, los críticos explican, los historiadores contextualizan. Cuando un artista escribe teoría, la respuesta institucional es sospecha. ¿Es investigación real? ¿Es publicación vanidosa? ¿Es arte?
144
+
145
+
La respuesta es: no importa. El artículo es un callout. Obliga a las ideas a estar a la intemperie, expuestas a la crítica, en un formato que la academia reconoce y el mundo del arte no controla. \citet{fraser2005critique} señaló que la crítica institucional se convirtió en una institución. Estos artículos intentan algo diferente: no crítica de la institución sino \emph{uso} del propio formato de la institución---el artículo académico---como material artístico.
146
+
147
+
\subsection{El artículo como instrumento}
148
+
149
+
Un artículo es una tecnología. Tiene un formato (secciones, citas, resumen, bibliografía), un sistema de distribución (revistas, preprints, repositorios) y un protocolo social (revisión por pares, citación, respuesta). Como cualquier tecnología, se puede tocar.
150
+
151
+
\ac{} trata la pieza como la unidad fundamental de cognición creativa~\citep{scudder2026pieces}. Una pieza es un solo archivo que exporta funciones de ciclo de vida: \texttt{boot}, \texttt{paint}, \texttt{act}, \texttt{sim}. Un artículo tiene la misma estructura: arranca (resumen), pinta (argumento), actúa (se involucra con trabajo previo) y simula (propone consecuencias). El artículo es una pieza escrita en \LaTeX{} en lugar de JavaScript.
152
+
153
+
Esto no es metáfora. Los artículos están construidos con la misma infraestructura que el software: un CLI (\texttt{papers/cli.mjs}), builds incrementales, despliegue multilingüe, publicación automatizada. El artículo \emph{es} software. El argumento \emph{es} el programa.
154
+
155
+
\subsection{La designación PSYCHO}
156
+
157
+
Este artículo está marcado como PSYCHO. No ``Borrador de trabajo,'' no ``Preprint,'' no ``En revisión.'' PSYCHO.
158
+
159
+
La designación es un callout al propio formato del artículo. Los artículos académicos pretenden ser neutrales---informes objetivos de hallazgos, escritos en voz pasiva, despojados de personalidad. La etiqueta PSYCHO rechaza esta pretensión. Dice: este artículo tiene voz, tiene una agenda, tiene una temperatura. No es neutral. No intenta serlo.
160
+
161
+
La palabra ``psycho'' viene del griego \textit{psykhe}---alma, mente, aliento. Un artículo PSYCHO es un artículo con alma. Respira. Tiene opiniones que no están matizadas con ``se necesita más investigación.'' Hace afirmaciones y te desafía a estar en desacuerdo.
162
+
163
+
\section{CalArts y Aesthetic Computer}
164
+
165
+
\subsection{La herencia del SO}
166
+
167
+
El autor asistió a CalArts (MFA Art, 2012). La experiencia es el sustrato sobre el cual \ac{} está construido. No las técnicas---CalArts no enseña programación---sino los \emph{supuestos}: que las disciplinas deben contaminarse mutuamente, que el medio no es el punto, que el desafío es más importante que el entregable, que el arte es una forma de estar en el mundo y no un producto para ser enviado.
168
+
169
+
\ac{} hereda el sistema operativo de CalArts. El modelo de pieza---un archivo, gráficos de modo inmediato, funciones de ciclo de vida---es el equivalente digital del estudio abierto: cualquiera puede ver lo que estás haciendo, cualquiera puede bifurcarlo, cualquiera puede cuestionarlo. La red social se organiza alrededor de \emph{rutas} (URLs memorizables) en lugar de feeds, de la misma manera que CalArts se organiza alrededor de pasillos en lugar de algoritmos.
170
+
171
+
\np{}.com es la herencia más clara de CalArts. Es un instrumento que cualquiera puede tocar, que no requiere entrenamiento, que recompensa la exploración sobre la pericia. El encuentro de pasillo---tropezar con el trabajo de otro y ser transformado por él---es el patrón de diseño. Escribes una URL. Aterrizas en una pieza. La tocas. Sigues adelante. Sin feed. Sin algoritmo. Sin métricas. Solo proximidad.
172
+
173
+
\subsection{La crítica se hace online}
174
+
175
+
Publicar estos artículos es una crítica. La sala es internet. El callout es público. El trabajo está expuesto---no ante una sala de quince personas que te conocen sino ante cualquiera con un navegador y una opinión.
176
+
177
+
Esto es aterrador de la misma manera que una crítica de CalArts es aterradora: no puedes controlar la respuesta. El trabajo se sostiene o no se sostiene. El desafío es el mismo desafío: ¿necesita esto existir?
178
+
179
+
\section{Contra la neutralidad}
180
+
181
+
El artículo académico pretende ser una ventana---transparente, dejándote ver la investigación detrás de él. Pero toda ventana es también un marco. El formato del artículo enmarca lo que puede decirse: voz pasiva, afirmaciones matizadas, deferencia hacia trabajo previo, la ficción de la objetividad~\citep{freire1970pedagogy}.
182
+
183
+
CalArts enseña lo opuesto. Respálda tu trabajo. Di lo que quieres decir. Si no puedes defenderlo en la sala, no está listo. El callout es una tecnología de rendición de cuentas: te obliga a sostener tus afirmaciones frente a personas que van a empujar de vuelta.
184
+
185
+
Estos artículos están escritos en ese espíritu. Tienen voz. Hacen afirmaciones. Citan investigación no para esconderse detrás de ella sino para discutir con ella, construir sobre ella, desafiarla a responder. La designación PSYCHO es una bandera: este artículo no pretende ser neutral. Tiene una posición. Tiene una temperatura. Está de pie en la sala, esperando el callout.
186
+
187
+
\citet{spivak2012aesthetic} argumenta que la educación estética entrena la imaginación para la solidaridad ética. CalArts hace esto---no a través del currículo sino a través de la proximidad, a través del desafío, a través de la crítica que te obliga a ver tu trabajo a través de los ojos de otro. Estos artículos intentan lo mismo en un medio diferente: entrenar la imaginación del lector para un tipo diferente de computación creativa, una construida sobre instrumentos en lugar de feeds, sobre piezas en lugar de productos, sobre callouts en lugar de métricas de engagement.
188
+
189
+
\section{Conclusión}
190
+
191
+
CalArts es un sistema operativo. Su kernel es la proximidad. Su shell es la crítica. Su modelo de procesos es el desafío. \ac{} corre sobre el mismo SO, portado del campus físico al navegador al bare metal~\citep{scudder2026ac, scudder2026os}.
192
+
193
+
El callout es el mecanismo. El artículo es el formato. La designación PSYCHO es la temperatura. Juntos dicen: el arte puede escribir teoría, la teoría puede ser arte, y ninguno necesita permiso de las instituciones que afirman poseerlos.
194
+
195
+
Estos artículos son conocimiento de pasillo, finalmente escrito---sabiendo que la escritura los cambia, sabiendo que la crítica nunca termina, sabiendo que el desafío es el punto.
196
+
197
+
\vspace{0.5em}
198
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
199
+
200
+
\bibliographystyle{plainnat}
201
+
\bibliography{references}
202
+
203
+
\end{document}
+205
papers/arxiv-calarts/calarts-zh.tex
+205
papers/arxiv-calarts/calarts-zh.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\usepackage{xeCJK}
8
+
\setCJKmainfont{Droid Sans Fallback}
9
+
\setmainfont{Latin Modern Roman}
10
+
\setsansfont{Latin Modern Sans}
11
+
\newfontfamily\acbold{ywft-processing-bold}[Path=../../system/public/type/webfonts/,Extension=.ttf]
12
+
\newfontfamily\aclight{ywft-processing-light}[Path=../../system/public/type/webfonts/,Extension=.ttf]
13
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
14
+
15
+
\usepackage{xcolor}
16
+
\usepackage{titlesec}
17
+
\usepackage{enumitem}
18
+
\usepackage{booktabs}
19
+
\usepackage{tabularx}
20
+
\usepackage{fancyhdr}
21
+
\usepackage{hyperref}
22
+
\usepackage{graphicx}
23
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
24
+
\usepackage{ragged2e}
25
+
\usepackage{microtype}
26
+
\usepackage{natbib}
27
+
28
+
% === PSYCHO watermark ===
29
+
\usepackage{eso-pic}
30
+
\usepackage{tikz}
31
+
\AddToShipoutPictureBG{%
32
+
\begin{tikzpicture}[remember picture, overlay]
33
+
% --- Pals logo: large, top-left, rotated, semi-opaque ---
34
+
\node[opacity=0.06, anchor=north west, rotate=-15]
35
+
at ([xshift=-1.2cm, yshift=1.2cm]current page.north west)
36
+
{\includegraphics[width=10cm]{pals}};
37
+
% --- "PSYCHO" text in Processing Light font ---
38
+
\node[opacity=0.12, rotate=45, anchor=center]
39
+
at (current page.center)
40
+
{{\aclight\fontsize{2.5cm}{3cm}\selectfont\color{acpink} PSYCHO}};
41
+
\end{tikzpicture}%
42
+
}
43
+
44
+
\definecolor{acpink}{RGB}{180,72,135}
45
+
\definecolor{acpurple}{RGB}{120,80,180}
46
+
\definecolor{acdark}{RGB}{64,56,74}
47
+
\definecolor{acgray}{RGB}{119,119,119}
48
+
49
+
\hypersetup{colorlinks=true,linkcolor=acpurple,urlcolor=acpurple,citecolor=acpurple,
50
+
pdftitle={CalArts、Callouts与论文：作为操作系统的艺术学院}}
51
+
52
+
\titleformat{\section}{\normalfont\bfseries\normalsize\uppercase}{\thesection.}{0.5em}{}
53
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
54
+
\titleformat{\subsection}{\normalfont\bfseries\small}{\thesubsection}{0.5em}{}
55
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
56
+
57
+
\pagestyle{fancy}\fancyhf{}
58
+
\renewcommand{\headrulewidth}{0pt}
59
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{PSYCHO论文 --- 请勿引用}}
60
+
\fancyfoot[C]{\footnotesize\thepage}
61
+
62
+
\newcommand{\ac}{\textsc{Aesthetic Computer}}
63
+
\newcommand{\np}{\textsc{notepat}}
64
+
65
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
66
+
\setlength{\columnsep}{1.8em}
67
+
\setlength{\parindent}{1em}
68
+
\setlength{\parskip}{0.3em}
69
+
70
+
\tolerance=800
71
+
\emergencystretch=1em
72
+
\hyphenpenalty=50
73
+
74
+
\begin{document}
75
+
76
+
\twocolumn[{%
77
+
\begin{center}
78
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
79
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} CalArts、Callouts与论文}\par
80
+
\vspace{0.2em}
81
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} 作为操作系统的艺术学院}\par
82
+
\vspace{0.6em}
83
+
{\normalsize @jeffrey}\par
84
+
{\small\color{acgray} Aesthetic.Computer}\par
85
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
86
+
\vspace{0.3em}
87
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
88
+
\vspace{0.6em}
89
+
\rule{\textwidth}{1.5pt}
90
+
\vspace{0.5em}
91
+
\end{center}
92
+
93
+
\begin{center}
94
+
{\small\color{acpink}\textbf{[ PSYCHO论文 --- 请勿引用 ]}}
95
+
\end{center}
96
+
\vspace{0.3em}
97
+
98
+
\begin{quote}
99
+
\small\noindent\textbf{摘要。}
100
+
CalArts（加州艺术学院）由Walt Disney于1961年创立，旨在打造一所全面的艺术学院——一个动画、音乐、戏剧、舞蹈、电影和美术在同一屋檐下共存、没有学科壁垒地相互交融的场所。本文认为CalArts作为创意生产的\emph{操作系统}运作：一套关于艺术是什么、如何教授艺术、以及艺术家应当成为什么的基本假设。我们考察了该校独特的"callout"文化——评论、走廊对话、机构挑战——以及这种口头传统如何产生无法书写的知识。随后我们转向论文本身：这一系列学术论文为何存在，艺术家兼程序员写理论意味着什么，以及论文形式本身是否就是一种callout——一种迫使想法在公开场合暴露的公共挑战。CalArts教会了作者创作能够回应的作品。这些论文就是那些作品以艺术界未曾预料的方式在回应。
101
+
\end{quote}
102
+
\vspace{0.5em}
103
+
}]
104
+
105
+
\section{迪士尼机器}
106
+
107
+
Walt Disney于1961年通过合并Chouinard Art Institute和Los Angeles Conservatory of Music创立了CalArts。他想要一所像他的工作室那样运作的艺术学院：所有学科在一栋楼里，共享工具和想法。Disney在1971年Valencia校区开放之前去世，但他所要求的结构——部门之间没有墙壁、共享设施、跨学科碰撞的文化——塑造了此后的一切。
108
+
109
+
创始愿景是工业性的。Disney需要能画画的动画师、懂节奏的音乐家、能对着故事板即兴表演的演员。这所学校是工作室的人才输送管道~\citep{singerman1999art}。但另一些事情发生了。Disney的继承者所聘请的教师——其中包括Allan Kaprow、Judy Chicago、John Baldessari、Miriam Schapiro、Nam June Paik——将跨学科结构转变为战后美国艺术的实验室。Disney为培养动画师而建造的机器变成了一台生产概念艺术家、女性主义表演、录像艺术的机器，并最终催生了定义后工作室实践的一代人。
110
+
111
+
操作系统的类比是精确的。操作系统不制造软件；它提供软件可以运行的环境。CalArts不制造艺术；它提供条件——空间的、社会的、教学的——使某种特定类型的艺术家成为可能。改变操作系统，你就改变了可以被创造的东西。
112
+
113
+
\section{Callouts}
114
+
115
+
\subsection{评论作为口头传统}
116
+
117
+
CalArts的评论不是打分。它是一个callout。有人把作品挂在墙上，房间作出回应——不是用评分标准或学习成果，而是用那些一起看艺术看了足够久、可以跳过客套话的人所具有的、未经排练的、有时残酷、有时慷慨的诚实。
118
+
119
+
\citet{elkins2001why}认为评论是不可教的，正如艺术是不可教的：一场好的评论中发生的事情无法被还原为一种方法。它是一种口头传统。一场三小时评论中产生的知识只存在于那个房间里。它无法被写下而不变成别的东西——一个摘要、一篇评价、一个判断。评论是现场的。它是注意力的表演~\citep{hooks1994teaching}。
120
+
121
+
CalArts的评论以其强度而闻名。学校规模小（约1,500名学生）、住宿制校园和跨学科结构意味着一位画家的评论可能包括一位作曲家、一位动画师、一位电影人和一位舞者。反馈不是学科特定的。它是\emph{感知性的}：这对我的身体、我的耳朵、我的时间感做了什么？Callout不是"这是好画。"Callout是"这是活的"或"这是死的。"
122
+
123
+
\subsection{走廊知识}
124
+
125
+
CalArts教授的大部分内容发生在教室之外。主楼的走廊——一座由Ladd \& Kelsey设计的粗野主义巨型建筑——充当着非正式的沙龙。一位作曲家经过一位雕塑家敞开的工作室，听到一个改变了他们两人作品的声音。一位电影人在凌晨两点放映当日素材，一位舞者走进来开始随着画面即兴表演。
126
+
127
+
这不是课程。这是\emph{建筑}。建筑迫使碰撞发生。食堂（唯一的一个）迫使所有人进入同一个房间。走廊足够宽，可以停下来交谈。工作室是敞开的。琴房漏出声音。建筑是一件演奏其中人们的乐器。
128
+
129
+
\citet{deduve1994attitude}识别了艺术教育的三种范式：学院（才能-模仿）、包豪斯（创造力-媒介-发明）和战后艺术学院（态度-实践-解构）。CalArts发明了第四种：\emph{邻近}。把不同的学科放得足够近，它们就会相互污染。污染就是教育。
130
+
131
+
\subsection{机构挑战}
132
+
133
+
CalArts靠挑战运转。不是明确的挑战——没有人说"我挑战你。"但文化围绕一种挑战结构组织：你能做出在一个满是比你强的人的房间里站得住的东西吗？你能展示经得起callout的作品吗？
134
+
135
+
这不同于技术学校的冲刺评审，在那里作品是按照用户故事和验收标准来评估的~\citep{vinsel2020innovation}。CalArts的挑战没有标准。没有评分表。问题不是"这是否满足了简报？"问题是"这是否需要存在？"挑战是存在性的，而非功能性的。
136
+
137
+
挑战也在部门之间运作。一个做带视频的作品的音乐学生是在挑战电影学生来关注。一个编写互动装置的舞者是在挑战艺术学生认真对待技术。挑战是跨学科污染的机制。它说：你的学科是不够的。来我的领域里玩。
138
+
139
+
\section{为什么写论文}
140
+
141
+
\subsection{论文作为callout}
142
+
143
+
这个论文系列——三周内写的二十篇论文——本身就是一个callout。它说：一个艺术家兼程序员能写理论。不是"理论简装版"，不是"带引用的艺术家自述"，而是有真正论点和真正参考文献、与真正学术研究对话的真正论文。
144
+
145
+
艺术界没有预料到这一点。艺术家被期望创作作品并让批评家来写。劳动分工是清晰的：艺术家生产，批评家解释，历史学家语境化。当一个艺术家写理论时，机构的反应是怀疑。这是真正的学术研究吗？是虚荣出版吗？是艺术吗？
146
+
147
+
答案是：这不重要。论文是一个callout。它迫使想法站在开放的地方，暴露于批评之下，以一种学术界认可而艺术界无法控制的格式。\citet{fraser2005critique}指出机构批评本身变成了一个机构。这些论文尝试不同的东西：不是对机构的批评，而是\emph{使用}机构自己的格式——学术论文——作为艺术材料。
148
+
149
+
\subsection{论文作为乐器}
150
+
151
+
论文是一种技术。它有格式（章节、引用、摘要、参考文献），有分发系统（期刊、预印本、数据库），有社会协议（同行评审、引用、回应）。像任何技术一样，它可以被演奏。
152
+
153
+
\ac{}将作品视为创意认知的基本单元~\citep{scudder2026pieces}。一个作品是一个导出生命周期函数的单一文件：\texttt{boot}、\texttt{paint}、\texttt{act}、\texttt{sim}。一篇论文具有同样的结构：它启动（摘要），绘制（论证），行动（与先前工作对话），模拟（提出后果）。论文是用\LaTeX{}而非JavaScript写的作品。
154
+
155
+
这不是隐喻。论文与软件使用相同的基础设施构建：一个CLI（\texttt{papers/cli.mjs}）、增量构建、多语言部署、自动化发布。论文\emph{就是}软件。论证\emph{就是}程序。
156
+
157
+
\subsection{PSYCHO标识}
158
+
159
+
这篇论文被标记为PSYCHO。不是"工作草稿"，不是"预印本"，不是"审稿中"。PSYCHO。
160
+
161
+
这一标识是对论文格式本身的callout。学术论文假装是中立的——客观的研究报告，用被动语态写成，剥离了个性。PSYCHO标签拒绝这种伪装。它说：这篇论文有声音，有议程，有温度。它不是中立的。它也不试图中立。
162
+
163
+
"psycho"一词来自希腊语\textit{psykhe}——灵魂、心智、呼吸。一篇PSYCHO论文是一篇有灵魂的论文。它在呼吸。它有不被"需要进一步研究"所对冲的观点。它提出主张并挑战你不同意。
164
+
165
+
\section{CalArts与Aesthetic Computer}
166
+
167
+
\subsection{操作系统的传承}
168
+
169
+
作者就读于CalArts（MFA Art，2012）。那段经历是\ac{}构建其上的基底。不是技术——CalArts不教编程——而是\emph{假设}：学科应该相互污染，媒介不是重点，挑战比交付物更重要，艺术是一种在世界中存在的方式而非一个待发布的产品。
170
+
171
+
\ac{}继承了CalArts的操作系统。作品模型——一个文件、即时模式图形、生命周期函数——是开放工作室的数字等价物：任何人都能看到你在做什么，任何人都能复刻它，任何人都能质疑它。社交网络围绕\emph{路径}（可记忆的URL）而非信息流组织，就像CalArts围绕走廊而非算法组织一样。
172
+
173
+
\np{}.com是最明显的CalArts传承。它是一件任何人都能演奏的乐器，不需要训练，奖励探索而非专业技能。走廊邂逅——偶然发现别人的作品并因此改变——就是设计模式。你输入一个URL。你落在一个作品上。你演奏它。你继续前行。没有信息流。没有算法。没有指标。只有邻近。
174
+
175
+
\subsection{评论上线}
176
+
177
+
发表这些论文就是一场评论。房间是互联网。Callout是公开的。作品暴露在外——不是面对一个认识你的十五个人的房间，而是面对任何拥有浏览器和观点的人。
178
+
179
+
这令人恐惧，正如CalArts的评论令人恐惧：你无法控制回应。作品要么站得住，要么站不住。挑战还是同样的挑战：这是否需要存在？
180
+
181
+
\section{反对中立}
182
+
183
+
学术论文假装是一扇窗——透明的，让你看到背后的研究。但每扇窗也是一个框架。论文格式框定了什么可以被说出：被动语态、对冲的主张、对先前工作的尊重、客观性的虚构~\citep{freire1970pedagogy}。
184
+
185
+
CalArts教的是相反的。站在你的作品背后。说你想说的。如果你不能在房间里为它辩护，它还没准备好。Callout是一种问责技术：它迫使你在会反驳的人面前为你的主张负责。
186
+
187
+
这些论文正是以这种精神写成的。它们有声音。它们提出主张。它们引用学术研究不是为了躲在其后，而是为了与之争论、在其上建构、挑战其回应。PSYCHO标识是一面旗帜：这篇论文不假装中立。它有立场。它有温度。它站在房间里，等待callout。
188
+
189
+
\citet{spivak2012aesthetic}认为美学教育训练想象力以达到伦理团结。CalArts做到了这一点——不是通过课程，而是通过邻近，通过挑战，通过迫使你透过他人的眼睛看自己作品的评论。这些论文在不同的媒介中尝试同样的事情：训练读者的想象力，去设想一种不同的创意计算——建立在乐器而非信息流之上，建立在作品而非产品之上，建立在callouts而非参与度指标之上。
190
+
191
+
\section{结论}
192
+
193
+
CalArts是一个操作系统。它的内核是邻近。它的shell是评论。它的进程模型是挑战。\ac{}运行在同一个操作系统上，从实体校园移植到浏览器再到裸金属~\citep{scudder2026ac, scudder2026os}。
194
+
195
+
Callout是机制。论文是格式。PSYCHO标识是温度。它们共同说：艺术可以写理论，理论可以是艺术，两者都不需要自称拥有它们的机构的许可。
196
+
197
+
这些论文是走廊知识，终于被写下——知道书写改变了它们，知道评论永远不会结束，知道挑战才是重点。
198
+
199
+
\vspace{0.5em}
200
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
201
+
202
+
\bibliographystyle{plainnat}
203
+
\bibliography{references}
204
+
205
+
\end{document}
+427
papers/arxiv-futures/futures-da.tex
+427
papers/arxiv-futures/futures-da.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
11
+
\setmainfont{Latin Modern Roman}
12
+
\setsansfont{Latin Modern Sans}
13
+
14
+
% Custom AC fonts
15
+
\newfontfamily\acbold{ywft-processing-bold}[
16
+
Path=../../system/public/type/webfonts/,
17
+
Extension=.ttf
18
+
]
19
+
\newfontfamily\aclight{ywft-processing-light}[
20
+
Path=../../system/public/type/webfonts/,
21
+
Extension=.ttf
22
+
]
23
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
24
+
25
+
% === PACKAGES ===
26
+
\usepackage{xcolor}
27
+
\usepackage{titlesec}
28
+
\usepackage{enumitem}
29
+
\usepackage{booktabs}
30
+
\usepackage{tabularx}
31
+
\usepackage{fancyhdr}
32
+
\usepackage{hyperref}
33
+
\usepackage{graphicx}
34
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
35
+
\usepackage{ragged2e}
36
+
\usepackage{microtype}
37
+
\usepackage{natbib}
38
+
\usepackage[colorspec=0.92]{draftwatermark}
39
+
40
+
% === COLORS (AC palette) ===
41
+
\definecolor{acpink}{RGB}{180,72,135}
42
+
\definecolor{acpurple}{RGB}{120,80,180}
43
+
\definecolor{acdark}{RGB}{64,56,74}
44
+
\definecolor{acgray}{RGB}{119,119,119}
45
+
\definecolor{draftcolor}{RGB}{180,72,135}
46
+
47
+
% === DRAFT WATERMARK ===
48
+
\DraftwatermarkOptions{
49
+
text=WORKING DRAFT,
50
+
fontsize=3cm,
51
+
color=draftcolor!18,
52
+
angle=45,
53
+
pos={0.5\paperwidth, 0.5\paperheight}
54
+
}
55
+
56
+
% === HYPERREF ===
57
+
\hypersetup{
58
+
colorlinks=true,
59
+
linkcolor=acpurple,
60
+
urlcolor=acpurple,
61
+
citecolor=acpurple,
62
+
pdfauthor={@jeffrey},
63
+
pdftitle={Fem år fra nu: Hvad Aesthetic Computer sandsynligvis bliver},
64
+
}
65
+
66
+
% === SECTION FORMATTING ===
67
+
\titleformat{\section}
68
+
{\normalfont\bfseries\normalsize\uppercase}
69
+
{\thesection.}
70
+
{0.5em}
71
+
{}
72
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
73
+
74
+
\titleformat{\subsection}
75
+
{\normalfont\bfseries\small}
76
+
{\thesubsection}
77
+
{0.5em}
78
+
{}
79
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
80
+
81
+
% === HEADER/FOOTER ===
82
+
\pagestyle{fancy}
83
+
\fancyhf{}
84
+
\renewcommand{\headrulewidth}{0pt}
85
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{Arbejdsudkast --- ikke til citation}}
86
+
\fancyfoot[C]{\footnotesize\thepage}
87
+
88
+
% === CUSTOM COMMANDS ===
89
+
\newcommand{\ac}{\textsc{Aesthetic Computer}}
90
+
\newcommand{\acos}{\textsc{AC Native OS}}
91
+
\newcommand{\np}{\textsc{notepat}}
92
+
93
+
% === LIST SETTINGS ===
94
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
95
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
96
+
97
+
% === COLUMN SEPARATION ===
98
+
\setlength{\columnsep}{1.8em}
99
+
100
+
% === PARAGRAPH SETTINGS ===
101
+
\setlength{\parindent}{1em}
102
+
\setlength{\parskip}{0.3em}
103
+
104
+
% Hyphenation for narrow two-column layout
105
+
\tolerance=800
106
+
\emergencystretch=1em
107
+
\hyphenpenalty=50
108
+
109
+
\begin{document}
110
+
111
+
% ============ TITLE BLOCK ============
112
+
113
+
\twocolumn[{%
114
+
\begin{center}
115
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
116
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} Fem år fra nu}\par
117
+
\vspace{0.2em}
118
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} Hvad Aesthetic Computer sandsynligvis bliver}\par
119
+
\vspace{0.3em}
120
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} Overskydende hardware, rumlige instrumenter og det lange spil med et personligt værktøj}\par
121
+
\vspace{0.6em}
122
+
{\normalsize @jeffrey}\par
123
+
{\small\color{acgray} Aesthetic.Computer}\par
124
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
125
+
\vspace{0.3em}
126
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
127
+
\vspace{0.6em}
128
+
\rule{\textwidth}{1.5pt}
129
+
\vspace{0.5em}
130
+
\end{center}
131
+
132
+
\begin{center}
133
+
{\small\color{acpink}\textbf{[ arbejdsudkast --- ikke til citation ]}}
134
+
\end{center}
135
+
\vspace{0.3em}
136
+
137
+
\begin{quote}
138
+
\small\noindent\textbf{Abstrakt.}
139
+
Denne artikel ekstrapolerer de næste fem år (2026--2031) af \ac{} baseret på projektets nuværende kurs, eksisterende infrastruktur, erklærede ambitioner og de kræfter---økonomiske, kulturelle og materielle---der påvirker det. Vi argumenterer for, at projektet sandsynligvis vil udvikle sig langs syv konvergerende akser: (1)~kontinuiteten i en 94-projekters kreativ linje, der begrænser rummet af sandsynlige fremtider, (2)~modningen af \acos{} til et deployerbart instrument for overskydende hardware i stor skala, (3)~fremkomsten af distribuerede laptop-ensembler som musikalsk og pædagogisk form, (4)~udvidelsen af 3D fra software-rasterizer til rumligt kreativt medie, (5)~fordybelsen af en akademisk identitet gennem vedvarende artikelproduktion, (6)~væksten af KidLisp til et selvbærende kreativt sprogfællesskab, og (7)~et opgør med bæredygtighed---herunder muligheden for projektets bevidste eller ufrivillige ophør---der vil afgøre, om det overlever sine egne ambitioner. Dette er ikke en køreplan. Det er en aflæsning af momentum---et forsøg på at spørge, hvad et projekt \emph{ønsker at blive} baseret på, hvad det allerede har valgt at gøre.
140
+
\end{quote}
141
+
\vspace{0.5em}
142
+
}]
143
+
144
+
% ============ 1. INTRODUKTION ============
145
+
146
+
\section{Introduktion}
147
+
148
+
\ac{} er en mobil-først-køretid og et socialt netværk for kreativ computing, der omfatter 359 indbyggede interaktive programmer (``pieces''), et bare-metal Linux-operativsystem, der starter enhver x86\_64-maskine som et kreativt instrument, en minimal Lisp-dialekt til generativ kunst og et voksende fællesskab af 2.812 registrerede brugere~\citep{scudder2026ac}. Projektet er skrevet og vedligeholdt primært af en enkelt udvikler, @jeffrey, med AI-assisteret vedligeholdelse (``AestheticAnts''), der håndterer rutinemæssigt vedligehold.
149
+
150
+
Per marts 2026 har projektet produceret 19 forskningsartikler på fire sprog, et bare-metal OS, der starter på 7,3 sekunder~\citep{scudder2026os}, en blockchain-integration til prægning af generative kunstværker og et 7.912-linjers musikinstrument (\np{}), der er blevet systemets hoveddør~\citep{scudder2026notepat}. Kodebasen sporer sin linje gennem 94 forgængerprojekter, der spænder over mere end et årti af værktøjsfremstilling.
151
+
152
+
Denne artikel foreslår ikke, hvad \ac{} \emph{bør} gøre. Den forsøger at aflæse, hvad det \emph{sandsynligvis vil} gøre, baseret på det momentum, der allerede er synligt i koden, artiklerne, infrastrukturbeslutningerne og de filosofiske forpligtelser, der har formet projektet til dato.
153
+
154
+
% ============ 2. FIREOGHALVFEMS PROJEKTER ============
155
+
156
+
\section{Fireoghalvfems projekter og flere på vej}
157
+
\label{sec:history}
158
+
159
+
Enhver fremskrivning af \ac{}'s fremtid må gøre op med dybden af dets fortid. Projektet er ikke en startup, der pivoter mod produkt-markedsfit. Det er den 95. iteration af en enkelt vedvarende undersøgelse: \emph{hvad bør et personligt kreativt computing-instrument være?}
160
+
161
+
\subsection{Tegnesoftware-linjen (2011--2020)}
162
+
163
+
Arkæologiartiklen~\citep{scudder2026archaeology} sporer \ac{} gennem 94 forgængerprojekter, der spænder over to GitHub-konti (50+ repositories), et 109\,GB legacy-serverarkiv og et Dropbox-korpus. Banen begynder med \textbf{thePRBAT} (Polygon Replicating Bitmap Authoring Tool, 2011), et Flash-baseret digitalt billedværktøj bygget som BFA-afhandling på Ringling College, og ankommer til \ac{} gennem et årti af tegnesoftware-varianter: \textbf{JeffreyPaint} (2014, JavaScript + Unity), \textbf{Finger Quilt} (2016, iOS/Swift), \textbf{Dot} (2017, en tegneapplikation, der foregriber AC's \texttt{plot}-disk), og vigtigst \textbf{No Paint} (2014--2020), der gennemgik fem inkarnationer---Rails, JavaScript-shim, WebGL-prototype, iOS/Cordova, Vercel-site---før det blev absorberet i \ac{}.
164
+
165
+
Dette er ikke en historie om forladte projekter. Det er en historie om \emph{genstarter}: den samme person, der stiller det samme spørgsmål, og vælger at starte forfra frem for at akkumulere funktioner. Mønstret er synligt i \ac{} selv: piece-modellen (enkelt fil, livscyklusfunktioner, immediate-mode grafik) er et begrænsnings-først-design, der \emph{forhindrer} den funktionsakkumulering, der dræbte tidligere iterationer.
166
+
167
+
\subsection{Performance-vendingen (2016--2018)}
168
+
169
+
Mellem 2016 og 2018 turnerede @jeffrey med Goodiepal \& Pals på tværs af 65+ spillesteder i Europa og byggede realtids-performanceværktøjer: publikumsdeltagelsesgrænseflader, musiknotationsrenderere, undertekstvisninger til live-forelæsninger. Disse værktøjer---bygget hurtigt, brugt én gang, smidt ud---etablerede et designprincip, der vedvarer i \ac{}: software som instrument, ikke som produkt. Værktøjerne blev spillet, ikke leveret.
170
+
171
+
Goodiepal-indflydelsen går dybere end samarbejde. Goodiepal-artiklen~\citep{scudder2026goodiepal} identificerer fem tråde, der fortsætter ind i \ac{}: instrument-først-design, fællesskab organiseret gennem affinitet snarere end institution, værker designet til at modstå digital reproduktion og radikal pædagogik gennem direkte engagement snarere end pensum.
172
+
173
+
\subsection{Hvorfor historien er vigtig for fremskrivning}
174
+
175
+
94-projekters historien begrænser vores fremskrivning på to måder. For det første gør den pludselige omlægninger usandsynlige. @jeffrey har kredset om de samme problemer---personlige værktøjer, kreative instrumenter, begrænsningsbaseret design---i 15 år. De næste 5 år vil næsten med sikkerhed forblive inden for denne bane. For det andet gør den opgivelse usandsynlig af de grunde, folk normalt opgiver projekter (kedsomhed, tab af interesse, tiltrækning af noget mere skinnende). Risikoen er ikke distraktion; det er udmattelse. Vi vender tilbage til dette i \S\ref{sec:giveup}.
176
+
177
+
% ============ 3. BØLGEN AF OVERSKYDENDE HARDWARE ============
178
+
179
+
\section{Bølgen af overskydende hardware}
180
+
\label{sec:surplus}
181
+
182
+
Den enkeltstående største kraft, der påvirker \ac{}'s fremtid, er ekstern: i oktober 2025 afsluttede Microsoft understøttelsen af Windows 10, hvilket ifølge institutionelle standarder gjorde skønsmæssigt 240 millioner pc'er forældede~\citep{ewaste2024monitor}. Disse maskiner er ikke i stykker. De er ThinkPads, EliteBooks og Latitudes med 8--16\,GB RAM, 1080p-skærme, WiFi og 6--10 timers batterier. De koster \$30--80 på brugtmarkedet. De er råmaterialet til alt, der følger.
183
+
184
+
\subsection{Fra prototype til flåde (2026--2027)}
185
+
186
+
\acos{} starter allerede på overskydende hardware~\citep{scudder2026os}. Afstanden mellem ``starter på to ThinkPads i @jeffreys lejlighed'' og ``starter på 30 maskiner i et klasseværelse'' er ikke primært teknisk. Den er operationel: WiFi-legitimationshåndtering, per-enhedsidentitetsprovisionering, hardwarekompatibilitetstest på tværs af snesevis af laptopmodeller og en flashingworkflow, som en ikke-teknisk person kan udføre.
187
+
188
+
Det sandsynlige arbejde på kort sigt er prosaisk men kritisk:
189
+
190
+
\begin{itemize}
191
+
\item \textbf{Per-bruger WiFi-lagring}: flytning af hardkodede SSID'er ud af JavaScript-pieces og ind i persistente per-enheds-konfigurationsfiler, der overlever OTA-opdateringer
192
+
\item \textbf{Hardwarekompatibilitetsmatrix}: systematisk test på tværs af ThinkPad X1/T/L-serien, HP EliteBook 800-serien, Dell Latitude 5000/7000-serien
193
+
\item \textbf{Enkommando-flashing}: en USB-imagebygning, der tager et handle, farver og WiFi-legitimationsoplysninger og producerer et bootbart drev
194
+
\item \textbf{A/B-kernepladser}: dual-partition boot med automatisk rollback, hvis den nye kerne fejler sundhedstjek
195
+
\end{itemize}
196
+
197
+
Disse er ikke glamourøse funktioner. De er forskellen mellem et kunstprojekt og et infrastrukturprojekt. Kodebasens kurs---OTA-opdateringer fungerer allerede, buildnavne genereres allerede, enhedsidentitet indskrives allerede i bootpartitionen---tyder på, at @jeffrey forstår denne forskel og bevæger sig mod infrastruktursiden.
198
+
199
+
\subsection{50-dollar-instrumentet (2027--2028)}
200
+
201
+
Hvis det operationelle arbejde lander, bliver det økonomiske argument meget højlydt: et komplet kreativt computing-instrument---personaliseret, selvopda\-terende, uden behov for nogen IT-infrastruktur---til prisen af en brugt laptop og et USB-drev. Ingen Chromebook-tilmelding. Intet Apple ID. Intet abonnement.
202
+
203
+
OLPC-projektet~\citep{kraemer2009olpc} demonstrerede, at hardware-først-tilgange til computing-adgang fejler på omkostninger og logistik. Raspberry Pi adresserede omkostninger (\$35) men kræver \$150 i tilbehør. \ac{}'s forslag er anderledes: hardwaren eksisterer allerede, har allerede en skærm, et tastatur, et batteri og WiFi og bliver kasseret i millionvis. Softwaren fylder 89\,MB.
204
+
205
+
Det sandsynlige resultat i 2028 er ikke masseadoption men \emph{bevispunkter}: en håndfuld klasseværelser, fællesskabscentre eller workshopkontekster, hvor flåder af 10--30 brugte maskiner kører \acos{}, og resultaterne dokumenteres. Disse bevispunkter bliver evidensgrundlaget for ansøgninger om støtte, institutionelle partnerskaber og bæredygtighedsargumenterne beskrevet i \S\ref{sec:sustainability}.
206
+
207
+
% ============ 3. PLANETARISKE ENSEMBLER ============
208
+
209
+
\section{Planetariske ensembler}
210
+
\label{sec:ensembles}
211
+
212
+
PLOrk-artiklen~\citep{scudder2026plork} fremsætter et argument, som den eksisterende kodebase allerede understøtter: laptoporkestre har været musikalsk legitime, siden Princetons PLOrk beviste konceptet i 2006~\citep{trueman2006plork}, men modellen er fanget i universiteter til \$1.500+ per plads. \acos{} på overskydende hardware reducerer omkostningerne til \$50/plads. Spørgsmålet er, om nogen vil spille.
213
+
214
+
\subsection{notepat som ensembleinstrument (2026--2027)}
215
+
216
+
\np{} er allerede et polyfonisk keyboardinstrument med 32-stemmers syntese, rumklang og bølgetypevalg~\citep{scudder2026notepat}. Det kører på bare metal ved 192\,kHz. Den manglende ingrediens for ensembleperformance er ikke lydkvalitet men \emph{koordinering}: synkroniseret tempo, delt harmonisk rum og en dirigentgrænseflade.
217
+
218
+
Den sandsynlige udviklingssti:
219
+
220
+
\begin{itemize}
221
+
\item \textbf{UDP-ensemblesync}: udvidelse af den eksisterende dobbeltkanals-netværksforbindelse (WebSocket + UDP) til at synkronisere beat-ure på tværs af enheder i et lokalt netværk
222
+
\item \textbf{Dirigent-piece}: et nyt piece, der viser ensembletilstanden og lader en dirigent sætte tempo, toneart og dynamik
223
+
\item \textbf{Spatialisering}: brug af de fysiske positioner af brugte laptops som distribuerede højttalere---ensemblet \emph{er} lydsystemet, efter Turinos deltagende musikmodel~\citep{turino2008music}
224
+
\end{itemize}
225
+
226
+
Denne tråd har åbenlyst konferenceappel. En live-demonstration af 10 brugte ThinkPads, der spiller et koordineret musikstykke---hver med spillerens handle i regnbuetekst, hver bidragende en stemme til et distribueret lydfelt---er den slags demo, der vinder omtale ved Ars Electronica og NIME-indsendelser.
227
+
228
+
\subsection{Ud over musik (2028--2031)}
229
+
230
+
Ensemblemodellen generaliserer ud over musik. Et netværk af brugte maskiner, der kører koordinerede pieces, kunne være:
231
+
232
+
\begin{itemize}
233
+
\item En \textbf{distribueret tegnevæg}: hver skærm viser en sektion af et større lærred, deltagere tegner lokalt, og netværket sammensætter resultatet
234
+
\item Et \textbf{kollaborativt KidLisp-miljø}: studerende skriver generative programmer, der føder ind i et delt visuelt rum
235
+
\item En \textbf{performancepartitur}: maskinerne udfører et grafisk partitur~\citep{scudder2026pieces}, hvor hver fortolker den samme notation gennem forskellige pieces
236
+
\end{itemize}
237
+
238
+
Infrastrukturen for alt dette eksisterer allerede: WebSocket-relay, UDP-broadcast, per-enheds-identitet og en piece-model, der understøtter enhver kombination af grafik, lyd og input. Det, der mangler, er \emph{koreografien}---selve piecesne og de sociale former omkring dem.
239
+
240
+
% ============ DEN TREDJE DIMENSION ============
241
+
242
+
\section{Den tredje dimension}
243
+
\label{sec:3d}
244
+
245
+
\ac{} opfattes i vid udstrækning som et 2D-system. Den immediate-mode grafik-API---\texttt{wipe}, \texttt{ink}, \texttt{line}, \texttt{box}---og pixelkunstæstetikken i de fleste pieces forstærker dette indtryk. Men infrastrukturen fortæller en anden historie. En fuld software-3D-rasterizer eksisterer allerede, et multiplayer-FPS leveres allerede, og de arkitektoniske valg i bare-metal OS'et positionerer 3D som den næste store udtryksmæssige grænse.
246
+
247
+
\subsection{Hvad der allerede virker}
248
+
249
+
Bare-metal OS'et inkluderer \texttt{graph3d.c}, en ~600-linjers CPU-softwarerasterizer med perspektivprojektion, frustum-klipning (Sutherland-Hodgman mod 6 klipplaner), dybdebuffer, per-vertex-farveinterpolation og teksturmapping med perspektivkorrekte barycentriske koordinater. JavaScript-API'en eksponerer dette gennem en \texttt{Form}-konstruktør: pieces skaber meshes med vertexpositioner, farver og teksturkoordinater og renderer dem med \texttt{ink(r,g,b).form(mesh)}.
250
+
251
+
To produktions-pieces demonstrerer systemet. \texttt{fps.mjs} leverer et førstepersonskamera med pointer lock, WASD-bevægelse, teksturerede grundplaner og roterende kuber. \texttt{1v1.mjs} udvider dette til et multiplayer-FPS med hitscan-våben, bot-AI (patrulje-/forfølgelses-/flugttilstande), drabssporing og dobbeltkanals-netværksmønsteret (WebSocket for pålidelige spilbegivenheder, UDP for lav-latens positionssynkronisering). Browserstien bruger Three.js (r0.182) med WebGL-rendering og inkluderer VR/XR-sessionsunderstøttelse~\citep{sutherland1968head}.
252
+
253
+
Systemet har altså to parallelle 3D-stier: en softwarerasterizer på bare metal (kun CPU, ingen GPU) og en hardwareaccelereret sti i browseren (WebGL/Three.js, med WebGPU-infrastruktur på plads). API-overfladen er identisk set fra piece-forfatterens perspektiv.
254
+
255
+
\subsection{GPU-spørgsmålet på bare metal (2026--2028)}
256
+
257
+
Softwarerasterizeren er elegant men fundamentalt begrænset. Hver brugt ThinkPad og EliteBook i målflåden har en Intel-integreret GPU, der kan OpenGL 4.x eller Vulkan 1.x, og som sidder ubrugt. Kernens DRM-delsystem styrer allerede skærmen via KMS-modesetting; at udvide det til at eksponere en rendernode for GPU-accelereret rasterisering er en kendt ingeniørmæssig sti (EGL på DRM eller Vulkan via \texttt{/dev/dri/renderD128}).
258
+
259
+
Den sandsynlige kurs er forsigtig. @jeffreys designinstinkt favoriserer softwarekontrol over hardwaredelegering---hele bare-metal OS-filosofien er ``kend enhver instruktion mellem tænding og pixel.'' GPU-drivere introducerer uigennemsigtighed: firmware-blobs, driverbug, leverandørspecifik opførsel. Softwarerasterizer-ens dyd er, at den er \emph{læsbar}: pipelinen fra vertex til pixel er 600 linjer C, som en studerende kan læse.
260
+
261
+
Det sandsynlige kompromis: GPU-acceleration som en opt-in-sti for pieces, der har brug for det, med softwarerasterizeren som standard og referenceimplementering. Dette afspejler browserarkitekturen, hvor WebGPU eksisterer ved siden af 2D-canvas men ikke erstatter det.
262
+
263
+
\subsection{3D som kreativt medie (2028--2031)}
264
+
265
+
Det mere interessante spørgsmål er ikke teknisk men udtryksmæssigt. Hvad betyder 3D i et system designet omkring begrænsning, umiddelbarhed og enkelt-fil-pieces?
266
+
267
+
Forgængerprojekterne giver et fingerpeg. @jeffreys arbejde har altid handlet om \emph{maleri}: No Paint, JeffreyPaint, thePRBAT, Radical Digital Painting-forelæsningsturnen. 3D-infrastrukturen bygger ikke mod en spilmotor eller et CAD-værktøj. Den bygger mod \emph{rumligt maleri}---evnen til at placere mærker, farver og former i tredimensionelt rum med den samme umiddelbarhed, som \texttt{ink(255,0,0).line(0,0,100,100)} giver i to dimensioner.
268
+
269
+
De pieces, der vil betyde noget, er ikke dem, der ligner Unity-demoer. De er dem, hvor 3D bruges, som @jeffrey bruger 2D: som råmateriale til instrumenter, til performances, til ting, der spilles frem for forbruges. Et 3D \np{}, hvor noder har rumlig position, og rumklangen er bogstavelig---lyd, der udstråler fra former fordelt i virtuelt rum. Et 3D KidLisp, hvor \texttt{(box 0 0 0 50 50 50)} placerer en kube, som \texttt{(rect 0 0 50 50)} placerer et rektangel. En flåde af brugte laptops, der hver renderer en anden kameravinkel af den samme distribuerede 3D-scene.
270
+
271
+
Konvergensen med ensembler (\S\ref{sec:ensembles}) er, hvor 3D bliver genuint nyt. Synkroniserede 3D-scener på tværs af netværksbaserede brugte maskiner---hver skærm et vindue ind i et delt virtuelt rum, hver spillers input påvirker scenen for alle deltagere---er en form, som hverken spilmotorer eller kreative kodningsværktøjer har udforsket til \$50/plads-prisklassen. Netværket er allerede bevist (\texttt{1v1.mjs}). Hardwaren er allerede tilgængelig (\S\ref{sec:surplus}). Det manglende stykke er den kunstneriske vision for, hvordan et distribueret rumligt instrument bør føles, og det er netop den slags spørgsmål, @jeffrey har brugt 94 projekter på at lære at besvare.
272
+
273
+
% ============ 5. DEN AKADEMISKE VENDING ============
274
+
275
+
\section{Den akademiske vending}
276
+
\label{sec:scholarly}
277
+
278
+
Mellem 3. marts og 20. marts 2026 producerede @jeffrey 19 forskningsartikler på fire sprog. Dette er ikke normal opførsel for en soloutvikler. Det signalerer en bevidst vending mod akademisk legitimitet---et forsøg på at opbygge, hvad RESEARCH-DIRECTION.md-filen kalder en ``forskningsvoldgrav'' omkring projektet.
279
+
280
+
\subsection{Artikelfabrikken (2026--2027)}
281
+
282
+
Artikelinfrastrukturen er allerede industriel: en tilpasset \LaTeX{}-skabelon med AC-skrifttyper, automatiseret PDF-bygning via en server (``ovnen''), et kortformat til enkeltarks udskrifter og en oversættelsespipeline, der producerer danske, spanske og kinesiske udgaver af hver artikel. Biblioteket med 40+ læsninger leverer citationsgrundlaget. Pipelinen er designet til at producere, ikke til at prototypeudvikle.
283
+
284
+
Kursen på kort sigt er indsendelse: ACM C\&C Demos (16. april), ICCC Short Papers (24. april), JOSS softwareartikler (løbende). Hvis nogen af disse lander, opnår projektet et akademisk fodfæste, som de fleste kreative kodningsværktøjer aldrig opnår. Processing~\citep{reas2007processing} og Scratch~\citep{resnick2009scratch} opbyggede deres akademiske legitimitet over år; @jeffrey forsøger at komprimere den tidslinje ved at producere volumen og målrette flere fora samtidigt.
285
+
286
+
\subsection{Kunstner-forsker-identitet (2028--2031)}
287
+
288
+
CalArts-artiklen argumenterer for, at en kunstskole er et operativsystem---at de strukturer af nærhed, kritik og disciplinær kontaminering, der karakteriserer institutioner som CalArts, kan porteres ind i software. Hvis @jeffrey fortsætter med at publicere i dette tempo, bliver artiklerne selv et værk: ikke dokumentation af et softwareprojekt, men et vedvarende argument om, hvad kreativ computing er, og hvem det er til.
289
+
290
+
Det sandsynlige 5-årsresultat er et af to scenarier:
291
+
292
+
\begin{enumerate}
293
+
\item \textbf{Voldgraven holder}: 6--10 artikler publiceres i peer-reviewede fora, @jeffrey inviteres til at tale ved konferencer, og \ac{} indtræder i kanon ved siden af Processing, Scratch og Sonic Pi~\citep{aaron2016sonic} som et anerkendt kreativt computing-miljø. Artiklerne skaber en feedbackloop: akademisk opmærksomhed bringer brugere, brugere skaber pieces, pieces genererer nye artikler.
294
+
\item \textbf{Voldgraven holder ikke}: indsendelser afvises, soloforfattermønstret vækker bedømmernes opmærksomhed, og artikelinfrastrukturen går i dvale. Koden overlever; den akademiske identitet gør det ikke. Dette er det mere almindelige resultat for kunstner-programmører.
295
+
\end{enumerate}
296
+
297
+
Det ærlige bud er et sted imellem: nogle få publikationer lander, nok til at etablere troværdighed i nicheforummer (NIME, xCoAx, ICLC), men de toneangivende HCI- og PL-konferencer forbliver uden for rækkevidde uden medforfattere og brugerstudier.
298
+
299
+
% ============ 5. KIDLISPS EGET LIV ============
300
+
301
+
\section{KidLisps eget liv}
302
+
\label{sec:kidlisp}
303
+
304
+
KidLisp er en 118-funktioners Lisp-dialekt til generativ kunst~\citep{scudder2026kidlisp}. Den er sandboxed (ingen fil-I/O, intet netværk), kører i browseren og har allerede akkumuleret 16.779 gemte programmer og en blockchain-prægningsintegration via Tezos. Sproget er lille nok til at passe på et kartotekskort.
305
+
306
+
\subsection{Sprogfællesskab (2026--2028)}
307
+
308
+
Tezos ``keeps''-systemet---hvor KidLisp-programmer præges som on-chain kunstværker for 2,5 XTZ---skaber et økonomisk incitament til at skrive KidLisp. Keeps-kontrakten (v11) er live, prægnings-UI'et eksisterer på keeps.kidlisp.com, og 5 tokens er allerede præget og migreret. Hvis det generative kunstmarked forbliver aktivt, vedligeholder denne tråd sig selv.
309
+
310
+
Den mere interessante mulighed er pædagogisk. KidLisps begrænsninger---ingen tilstandsmutation, ingen sideeffekter ud over tegning, 118 funktioner, kører i en browser---gør det til en kandidat til undervisningsmiljøer. Et KidLisp-pensum bygget omkring kortformatet (enkeltarks-programmer, som studerende kan holde i hænderne) stemmer overens med Paperts konstruktionisme~\citep{papert1980mindstorms} og projektets eksisterende infrastruktur.
311
+
312
+
\subsection{Sprogevolution (2028--2031)}
313
+
314
+
KidLisp vil møde pres for at vokse. Brugere vil ønske tilstand, animation, interaktivitet, lyd. Designspørgsmålet er, om sproget absorberer disse funktioner (og bliver et generelt kreativt sprog) eller forbliver bevidst minimalt (et ``haiku-sprog'' for statisk generativ kunst, med JavaScript til alt andet).
315
+
316
+
Projektets historie tyder på det sidstnævnte. @jeffreys designinstinkt, synligt på tværs af 94 forgængerprojekter, favoriserer skarpe begrænsninger over funktionsakkumulering. Piece-modellen selv---enkelt fil, livscyklusfunktioner, immediate-mode grafik~\citep{scudder2026pieces}---er et begrænsnings-først-design. KidLisp vil sandsynligvis forblive lille. Den interessante vækst vil være i, hvad folk laver med det, ikke hvad sproget tilføjer.
317
+
318
+
% ============ 6. BÆREDYGTIGHED ============
319
+
320
+
\section{Bæredygtighedsspørgsmålet}
321
+
\label{sec:sustainability}
322
+
323
+
Enhver tråd beskrevet ovenfor afhænger af, at en enkelt person fortsætter med at arbejde. \ac{} har ingen venturekapital, ingen institutionel opbakning og ingen ansatte ud over @jeffrey. AestheticAnts-vedligeholdelsessystemet automatiserer rutineopgaver, men arkitekturbeslutninger, artikelskrivning, hardwaretest og fællesskabspleje kræver menneskelig opmærksomhed.
324
+
325
+
\subsection{Finansieringslandskabet (2026--2028)}
326
+
327
+
Projektet har identificeret finansieringskilder: Creative Capital (\$50.000 projektbevillinger), Prix Ars Electronica (\texteuro10.000), Gary Marsden Travel Awards og GitHub Sponsors. Artikelfabrikken er delvist en ansøgningsstrategi: et projekt med 19 artikler, konferencedemoer og en dokumenteret brugerbase er en stærkere ansøger end et med kun kode.
328
+
329
+
Tezos-keeps giver en lille indtægtsstrøm. Tryk (20 bestilt per marts 2026) giver en anden. Ingen af dem er tilstrækkelige til at opretholde fuldtidsudvikling.
330
+
331
+
Den ærlige fremskrivning: i 2028 sikrer projektet sig enten en bevilling eller institutionel tilknytning (en residency, en undervisningsstilling, et forskningsstipendium) eller det nedsættes til vedligeholdelsesudvikling. Dette er ikke et fejlscenario---mange vigtige kreative værktøjer vedligeholdes deltids af deres skabere i årtier. Men de ambitiøse tråde (planetariske ensembler, flåder af overskydende hardware, akademisk voldgrav) kræver fuldtidsopmærksomhed.
332
+
333
+
\subsection{Soloforfattarrisikoen (2028--2031)}
334
+
335
+
Illichs ``værktøjer til konvivialitet''~\citep{illich1973tools} argumenterer for, at gode værktøjer bør kunne betjenes uden specialiseret ekspertise. \ac{} tilstræber dette for sine brugere, men projektet selv er ikke konvivialt i Illichs forstand: det kræver @jeffreys ekspertise at vedligeholde. Busfaktoren er én.
336
+
337
+
Afbødningen er allerede delvist på plads: kodebasen er open source, arkitekturen er dokumenteret i 19 artikler, piece-API'en er designet til enkelt-fil-enkelhed, og AestheticAnts-systemet håndterer rutinevedligeholdelse autonomt. Men forskellen mellem ``koden er åben'' og ``en anden kan lede projektet'' er enorm.
338
+
339
+
Den sandsynlige 5-årskurs: @jeffrey forbliver den eneste arkitekt. Et lille fællesskab af piece-forfattere bidrager med indhold (265 publicerede pieces og stigende). En eller to bidragydere indsender pull requests til specifikke funktioner. Projektet opnår ikke ``tusind bidragydere''-modellen fra Processing eller p5.js, men det behøver heller ikke---dets værdiforslag er ikke bredde men dybde: en enkelt vision, omhyggeligt vedligeholdt, der tager kreativ computing steder hen, som komité-designede værktøjer ikke kan nå.
340
+
341
+
% ============ 7. KONVERGENSEN ============
342
+
343
+
\section{Konvergensen}
344
+
\label{sec:convergence}
345
+
346
+
De syv tråde beskrevet ovenfor er ikke parallelle spor. De konvergerer.
347
+
348
+
94-projekternes historie (\S\ref{sec:history}) etablerer den kurs, der gør de andre tråde læsbare. Overskydende hardware (\S\ref{sec:surplus}) leverer materialegrundlaget for planetariske ensembler (\S\ref{sec:ensembles}). 3D-infrastrukturen (\S\ref{sec:3d}) udvider ensemblemodellen til rumlig performance. Artiklerne (\S\ref{sec:scholarly}) dokumenterer og legitimerer alt det. KidLisp (\S\ref{sec:kidlisp}) leverer et sikkert indgangspunkt for nye brugere, der ankommer gennem enhver af disse kanaler. Bæredygtighed (\S\ref{sec:sustainability}) afgør, om konvergensen overhovedet sker---og \S\ref{sec:giveup} undersøger, hvad der sker, hvis den ikke gør.
349
+
350
+
Det mest sandsynlige 5-årsscenarie er dette: i 2031 er \ac{} et anerkendt men niche kreativt computing-miljø med:
351
+
352
+
\begin{itemize}
353
+
\item \textbf{5.000--10.000 registrerede brugere}, op fra 2.812, drevet af notepat-viralitet, konferencedemoer og klasseværelsesudrulninger
354
+
\item \textbf{Et bare-metal OS} deployeret på 100--500 brugte maskiner på tværs af 5--15 steder (skoler, fællesskabscentre, kunstresidencies, workshops)
355
+
\item \textbf{3--5 publicerede artikler} i peer-reviewede fora, der etablerer et minimalt akademisk fodaftryk
356
+
\item \textbf{50.000+ KidLisp-programmer}, med et lille men aktivt generativt kunstfællesskab, der præger keeps på Tezos
357
+
\item \textbf{Ensembleperformances} ved 2--3 festivaler eller konferencer, med flåder af brugte laptops som distribuerede instrumenter
358
+
\item \textbf{En enkelt vedligeholder}, der stadig skriver det meste af koden, med AI-assisteret vedligeholdelse, der håndterer en stigende andel af rutinearbejdet
359
+
\end{itemize}
360
+
361
+
Dette er hverken det mest ambitiøse resultat eller det mest konservative. Det er det resultat, der er konsistent med et projekt, der har truffet specifikke, bevidste valg om, hvad det bekymrer sig om---dybde over bredde, instrumenter over IDE'er, vedligeholdelse over disruption---og som har infrastrukturen til at følge op på disse valg i det tempo, en soloutvikler kan opretholde.
362
+
363
+
% ============ 8. HVAD DER KUNNE ÆNDRE ALT ============
364
+
365
+
\section{Hvad der kunne ændre alt}
366
+
\label{sec:wildcards}
367
+
368
+
Fremskrivninger baseret på momentum er pålidelige netop fordi de ignorerer diskontinuiteter. Fire jokere kunne ændre kursen totalt:
369
+
370
+
\subsection{Et institutionelt hjem}
371
+
372
+
Hvis @jeffrey tager en undervisningsstilling på en kunstskole eller et forskningsuniversitet, opnår \ac{} noget, det i øjeblikket mangler: studerende. En årgang af 15--30 studerende, der bruger \ac{} som deres primære kreative computing-miljø i et semester, ville producere flere pieces, flere fejlrapporter, flere brugscases og mere forskning end et årti af soloutvkling. CalArts-artiklens argument---at en kunstskole er et operativsystem---virker i den modsatte retning: operativsystemet kunne blive en skole.
373
+
374
+
\subsection{Et viralt øjeblik}
375
+
376
+
\np{} blev postet på Hacker News og modtog opmærksomhed. Et andet viralt øjeblik---en TikTok af et klasseværelse fuldt af brugte laptops, der spiller musik sammen, en tweet-tråd om det kreative instrument til \$50, en konferencedemo, der filmes og deles---kunne bringe tusindvis af brugere på en uge. Infrastrukturen (URL-adresserbare pieces, øjeblikkelig registrering, sociale funktioner) er designet til at absorbere dette. Om @jeffrey \emph{ønsker} at absorbere det, er et separat spørgsmål. Projektets anti-platformholdning~\citep{fisher2009capitalist} antyder ambivalens over for vækst-for-vækstens-skyld.
377
+
378
+
\subsection{AI som samarbejdspartner}
379
+
380
+
AestheticAnts-systemet bruger allerede AI til rutinevedligeholdelse. Agenthukommelsessystemet logger interaktioner og opretholder kontinuitet på tværs af samtaler. Hvis AI-kapaciteterne fortsætter med at avancere, kunne en fremtidig version af dette system gøre mere end vedligeholdelse: det kunne skrive pieces, generere KidLisp-programmer, komponere ensemblepartiturer og udarbejde artikler. Soloforfattarrisikoen (\S\ref{sec:sustainability}) mindskes, hvis ``soloforfatteren'' er forstærket af en AI-samarbejdspartner, der forstår projektets historie, filosofi og kodebase.
381
+
382
+
Dette er ikke spekulativt på den måde, de andre scenarier er. Det sker allerede. Spørgsmålet er et spørgsmål om grad: i 2031, håndterer AI 10\% af det kreative arbejde, eller 50\%? Svaret vil afhænge af de valg, @jeffrey træffer om, hvad han delegerer, og hvad han insisterer på at gøre selv. Projektets vægt på personlig stemme, på de ``PSYCHO''-artikler, der bærer forfatterens temperatur, tyder på, at det vigtigste arbejde forbliver menneskeligt. Infrastrukturen omkring det gør det måske ikke.
383
+
384
+
\subsection{Hvad hvis han stopper}
385
+
\label{sec:giveup}
386
+
387
+
Fremskrivningerne ovenfor antager fortsat indsats. Men 94-projekternes historie (\S\ref{sec:history}) indeholder et mønster, der må nævnes: @jeffrey har forladt ting før. No Paint havde fem inkarnationer. Hver enkelt blev forladt, ikke fordi idéen mislykkedes, men fordi implementeringen stivnede---fordi kløften mellem, hvad værktøjet \emph{var}, og hvad det \emph{burde være}, blev uudholdelig. Genstarterne var ikke fejl i engagement. De var udtryk for det.
388
+
389
+
Risikoen for \ac{} er ikke, at @jeffrey mister interessen. Femten års kredsen om de samme problemer udelukker tilfældig opgivelse. Risikoen er \emph{strukturel udmattelse}: ophobningen af operationel vægt---serverregninger, brugersupport, hardwaretest, artikelindsendelser, ansøgninger om støtte, afhængighedsopdateringer---indtil vedligeholdelseslasten fortrænger det kreative arbejde, der gør projektet værd at vedligeholde. Ukeles~\citep{ukeles1969manifesto} argumenterede for, at vedligeholdelse er kunst, men selv Ukeles anerkendte, at vedligeholdelse uden anerkendelse bliver usynligt arbejde.
390
+
391
+
Tre scenarier for ophør fortjener overvejelse:
392
+
393
+
\begin{enumerate}
394
+
\item \textbf{Den stille bortfaden}: udviklingen aftager til sporadiske commits, serverne forbliver oppe, men fællesskabet driver væk, og \ac{} slutter sig til den lange liste af ambitiøse personlige værktøjer, der eksisterer som arkiver snarere end levende systemer. Dette er det mest almindelige resultat for soloforfattede kreative computing-projekter. Det er ikke dramatisk. Det er standarden.
395
+
396
+
\item \textbf{Det bevidste stop}: @jeffrey erklærer projektet færdigt ved en naturlig grænse---måske når OS'et starter pålideligt på et dusin laptopmodeller, eller når artikelantallet når et rundt tal, eller når det 100. piece publiceres af en anden end ham. Han vender tilbage til at male på lærred (Venice Family Clinic-udstillingen i maj 2026 tyder på, at denne tråd allerede er aktiv). Koden forbliver åben. Nogen forker den måske. Mest sandsynligt gør ingen det.
397
+
398
+
\item \textbf{Den 95. genstart}: @jeffrey forlader \ac{} for at bygge dens efterfølger. Dette er det mønster, historien forudsiger stærkest. No Paint blev til \ac{}. \ac{} kunne blive til noget andet---noget, der absorberer lektionerne fra OS'et, piece-modellen, ensemblenetværket og 3D-rasterizeren, men kaster den akkumulerede infrastrukturvægt af. Det nye projekt starter rent, i en enkelt fil, og cyklussen begynder igen. Udefra ligner dette fiasko. Indefra i den 94 projekters linje ligner det processen, der virker præcis som designet.
399
+
\end{enumerate}
400
+
401
+
Den ærlige vurdering: scenarie 3 er usandsynligt inden for 5 år, fordi \ac{} har opnået flugthastighed på måder, No Paint aldrig gjorde---en registreret brugerbase, et bare-metal OS, en blockchain-integration, 19 artikler, et sprog med 16.000+ programmer. Den investerede indsats er for stor til en ren genstart. Men scenarie 1 er fuldt ud muligt, hvis bæredygtighedsspørgsmålet (\S\ref{sec:sustainability}) forbliver ubesvaret. Et projekt af denne ambition, vedligeholdt af én person uden stabil finansiering, er altid ét dårligt år fra den stille bortfaden.
402
+
403
+
Afbødningen er den samme, der har opretholdt projektet indtil nu: at gøre selve arbejdet tilstrækkeligt givende til, at den operationelle byrde er til at bære. Artiklerne, performancerne, 3D-rasterizeren skrevet fra bunden, bare-metal-boot, der tager 7 sekunder---disse er ikke funktioner på en køreplan. De er den kreative praksis. Hvis praksis ophører med at være interessant, stopper projektet. Hvis den forbliver interessant, overlever projektet alt andet end at lyset slukkes.
404
+
405
+
% ============ 10. KONKLUSION ============
406
+
407
+
\section{Konklusion}
408
+
409
+
Aesthetic Computer er et projekt, der ved, hvad det er. Det søger ikke produktmarkedsfit, pivoter ikke mod enterprise og optimerer ikke for vækstmetrikker. Det er et personligt kreativt computing-instrument, der bygges offentligt af en enkelt person, som har lavet versioner af det i mere end et årti på tværs af 94 forgængerprojekter.
410
+
411
+
De næste fem år vil blive formet af kræfter, der er både interne (det tempo @jeffrey kan opretholde, den finansiering han kan sikre) og eksterne (240 millioner brugte pc'er, den generative kunstøkonomi, den akademiske konferencecyklus). Projektets infrastruktur---bare-metal OS, artikelfabrik, piece-model, socialt netværk, blockchain-prægning---er bygget til at absorbere disse kræfter. Om det vil, er et spørgsmål om udholdenhed, held og verdens vilje til at bekymre sig om kreative computing-værktøjer, der ikke ejes af en platform.
412
+
413
+
Nelson skrev i 1974, at ``du kan og skal forstå computere NU''~\citep{nelson1974computerlib}. Illich skrev i 1973, at værktøjer bør udvide personlig autonomi, ikke kræve institutionel formidling~\citep{illich1973tools}. Ukeles skrev i 1969, at vedligeholdelse er kunst~\citep{ukeles1969manifesto}. \ac{} er syntesen: et værktøj, der er personligt, konvivialt og vedligeholdt som en kreativ praksis. Væddemålet er, at denne syntese, anvendt på overskydende hardware og opretholdt over tid, skaber noget, der varer.
414
+
415
+
Om det gør, er det eneste interessante spørgsmål. Denne artikel tilbyder intet svar, kun en aflæsning af de kræfter i spil. Koden vil afgøre det.
416
+
417
+
\vspace{0.5em}
418
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
419
+
420
+
\vspace{0.5em}\noindent\textit{Oversat fra engelsk. Originalversion tilgængelig på \url{https://papers.aesthetic.computer}}
421
+
422
+
% ============ REFERENCES ============
423
+
424
+
\bibliographystyle{plainnat}
425
+
\bibliography{references}
426
+
427
+
\end{document}
+427
papers/arxiv-futures/futures-es.tex
+427
papers/arxiv-futures/futures-es.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
11
+
\setmainfont{Latin Modern Roman}
12
+
\setsansfont{Latin Modern Sans}
13
+
14
+
% Custom AC fonts
15
+
\newfontfamily\acbold{ywft-processing-bold}[
16
+
Path=../../system/public/type/webfonts/,
17
+
Extension=.ttf
18
+
]
19
+
\newfontfamily\aclight{ywft-processing-light}[
20
+
Path=../../system/public/type/webfonts/,
21
+
Extension=.ttf
22
+
]
23
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
24
+
25
+
% === PACKAGES ===
26
+
\usepackage{xcolor}
27
+
\usepackage{titlesec}
28
+
\usepackage{enumitem}
29
+
\usepackage{booktabs}
30
+
\usepackage{tabularx}
31
+
\usepackage{fancyhdr}
32
+
\usepackage{hyperref}
33
+
\usepackage{graphicx}
34
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
35
+
\usepackage{ragged2e}
36
+
\usepackage{microtype}
37
+
\usepackage{natbib}
38
+
\usepackage[colorspec=0.92]{draftwatermark}
39
+
40
+
% === COLORS (AC palette) ===
41
+
\definecolor{acpink}{RGB}{180,72,135}
42
+
\definecolor{acpurple}{RGB}{120,80,180}
43
+
\definecolor{acdark}{RGB}{64,56,74}
44
+
\definecolor{acgray}{RGB}{119,119,119}
45
+
\definecolor{draftcolor}{RGB}{180,72,135}
46
+
47
+
% === DRAFT WATERMARK ===
48
+
\DraftwatermarkOptions{
49
+
text=WORKING DRAFT,
50
+
fontsize=3cm,
51
+
color=draftcolor!18,
52
+
angle=45,
53
+
pos={0.5\paperwidth, 0.5\paperheight}
54
+
}
55
+
56
+
% === HYPERREF ===
57
+
\hypersetup{
58
+
colorlinks=true,
59
+
linkcolor=acpurple,
60
+
urlcolor=acpurple,
61
+
citecolor=acpurple,
62
+
pdfauthor={@jeffrey},
63
+
pdftitle={Cinco años a partir de ahora: En qué probablemente se convierte Aesthetic Computer},
64
+
}
65
+
66
+
% === SECTION FORMATTING ===
67
+
\titleformat{\section}
68
+
{\normalfont\bfseries\normalsize\uppercase}
69
+
{\thesection.}
70
+
{0.5em}
71
+
{}
72
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
73
+
74
+
\titleformat{\subsection}
75
+
{\normalfont\bfseries\small}
76
+
{\thesubsection}
77
+
{0.5em}
78
+
{}
79
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
80
+
81
+
% === HEADER/FOOTER ===
82
+
\pagestyle{fancy}
83
+
\fancyhf{}
84
+
\renewcommand{\headrulewidth}{0pt}
85
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{Borrador de trabajo --- no citar}}
86
+
\fancyfoot[C]{\footnotesize\thepage}
87
+
88
+
% === CUSTOM COMMANDS ===
89
+
\newcommand{\ac}{\textsc{Aesthetic Computer}}
90
+
\newcommand{\acos}{\textsc{AC Native OS}}
91
+
\newcommand{\np}{\textsc{notepat}}
92
+
93
+
% === LIST SETTINGS ===
94
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
95
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
96
+
97
+
% === COLUMN SEPARATION ===
98
+
\setlength{\columnsep}{1.8em}
99
+
100
+
% === PARAGRAPH SETTINGS ===
101
+
\setlength{\parindent}{1em}
102
+
\setlength{\parskip}{0.3em}
103
+
104
+
% Hyphenation for narrow two-column layout
105
+
\tolerance=800
106
+
\emergencystretch=1em
107
+
\hyphenpenalty=50
108
+
109
+
\begin{document}
110
+
111
+
% ============ TITLE BLOCK ============
112
+
113
+
\twocolumn[{%
114
+
\begin{center}
115
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
116
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} Cinco años a partir de ahora}\par
117
+
\vspace{0.2em}
118
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} En qué probablemente se convierte Aesthetic Computer}\par
119
+
\vspace{0.3em}
120
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} Hardware excedente, instrumentos espaciales y el juego largo de una herramienta personal}\par
121
+
\vspace{0.6em}
122
+
{\normalsize @jeffrey}\par
123
+
{\small\color{acgray} Aesthetic.Computer}\par
124
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
125
+
\vspace{0.3em}
126
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
127
+
\vspace{0.6em}
128
+
\rule{\textwidth}{1.5pt}
129
+
\vspace{0.5em}
130
+
\end{center}
131
+
132
+
\begin{center}
133
+
{\small\color{acpink}\textbf{[ borrador de trabajo --- no citar ]}}
134
+
\end{center}
135
+
\vspace{0.3em}
136
+
137
+
\begin{quote}
138
+
\small\noindent\textbf{Resumen.}
139
+
Este artículo extrapola los próximos cinco años (2026--2031) de \ac{} basándose en la trayectoria actual del proyecto, la infraestructura existente, las ambiciones declaradas y las fuerzas---económicas, culturales y materiales---que actúan sobre él. Argumentamos que el proyecto probablemente evolucionará a lo largo de siete ejes convergentes: (1)~la continuidad de un linaje creativo de 94 proyectos que restringe el espacio de futuros probables, (2)~la maduración de \acos{} en un instrumento desplegable para hardware excedente a escala, (3)~la emergencia de ensambles distribuidos de portátiles como forma musical y pedagógica, (4)~la expansión del 3D desde rasterizador por software a medio creativo espacial, (5)~la profundización de una identidad académica a través de la producción sostenida de artículos, (6)~el crecimiento de KidLisp en una comunidad creativa lingüística autosuficiente, y (7)~un ajuste de cuentas con la sostenibilidad---incluyendo la posibilidad del cese deliberado o involuntario del proyecto---que determinará si sobrevive a sus propias ambiciones. Esto no es una hoja de ruta. Es una lectura del impulso---un intento de preguntar en qué \emph{quiere convertirse} un proyecto basándose en lo que ya ha elegido hacer.
140
+
\end{quote}
141
+
\vspace{0.5em}
142
+
}]
143
+
144
+
% ============ 1. INTRODUCCIÓN ============
145
+
146
+
\section{Introducción}
147
+
148
+
\ac{} es un entorno de ejecución mobile-first y una red social para la computación creativa, que comprende 359 programas interactivos integrados (``pieces''), un sistema operativo Linux bare-metal que arranca cualquier máquina x86\_64 como instrumento creativo, un dialecto Lisp mínimo para arte generativo y una comunidad creciente de 2.812 usuarios registrados~\citep{scudder2026ac}. El proyecto es escrito y mantenido principalmente por un solo desarrollador, @jeffrey, con mantenimiento asistido por IA (``AestheticAnts'') encargándose de las tareas rutinarias.
149
+
150
+
A marzo de 2026, el proyecto ha producido 19 artículos de investigación en cuatro idiomas, un SO bare-metal que arranca en 7,3 segundos~\citep{scudder2026os}, una integración blockchain para acuñar obras de arte generativo, y un instrumento musical de 7.912 líneas (\np{}) que se ha convertido en la puerta de entrada del sistema~\citep{scudder2026notepat}. La base de código traza su linaje a través de 94 proyectos predecesores que abarcan más de una década de fabricación de herramientas.
151
+
152
+
Este artículo no propone lo que \ac{} \emph{debería} hacer. Intenta leer lo que \emph{probablemente hará}, basándose en el impulso ya visible en el código, los artículos, las decisiones de infraestructura y los compromisos filosóficos que han dado forma al proyecto hasta la fecha.
153
+
154
+
% ============ 2. NOVENTA Y CUATRO PROYECTOS ============
155
+
156
+
\section{Noventa y cuatro proyectos y contando}
157
+
\label{sec:history}
158
+
159
+
Cualquier proyección del futuro de \ac{} debe confrontar la profundidad de su pasado. El proyecto no es una startup pivotando hacia el ajuste producto-mercado. Es la iteración número 95 de una única investigación sostenida: \emph{¿qué debería ser un instrumento personal de computación creativa?}
160
+
161
+
\subsection{El linaje del software de dibujo (2011--2020)}
162
+
163
+
El artículo de arqueología~\citep{scudder2026archaeology} traza \ac{} a través de 94 proyectos predecesores que abarcan dos cuentas de GitHub (más de 50 repositorios), un archivo de servidor legado de 109\,GB y un corpus de Dropbox. La trayectoria comienza con \textbf{thePRBAT} (Polygon Replicating Bitmap Authoring Tool, 2011), una herramienta de imagen digital basada en Flash construida como tesis de BFA en Ringling College, y llega a \ac{} a través de una década de variantes de software de dibujo: \textbf{JeffreyPaint} (2014, JavaScript + Unity), \textbf{Finger Quilt} (2016, iOS/Swift), \textbf{Dot} (2017, una aplicación de trazado que prefigura el disco \texttt{plot} de AC), y lo más importante \textbf{No Paint} (2014--2020), que pasó por cinco encarnaciones---Rails, shim JavaScript, prototipo WebGL, iOS/Cordova, sitio Vercel---antes de ser absorbido en \ac{}.
164
+
165
+
Esta no es una historia de proyectos abandonados. Es una historia de \emph{reinicios}: la misma persona, haciendo la misma pregunta, eligiendo empezar de nuevo en lugar de acumular funcionalidades. El patrón es visible en \ac{} mismo: el modelo de pieces (archivo único, funciones de ciclo de vida, gráficos en modo inmediato) es un diseño que prioriza las restricciones y que \emph{previene} la acumulación de funcionalidades que mató iteraciones anteriores.
166
+
167
+
\subsection{El giro performático (2016--2018)}
168
+
169
+
Entre 2016 y 2018, @jeffrey realizó giras con Goodiepal \& Pals por más de 65 escenarios en Europa, construyendo herramientas de performance en tiempo real: interfaces de participación del público, renderizadores de notación musical, pantallas de subtítulos para conferencias en vivo. Estas herramientas---construidas rápido, usadas una vez, descartadas---establecieron un principio de diseño que persiste en \ac{}: software como instrumento, no como producto. Las herramientas se tocaban, no se enviaban.
170
+
171
+
La influencia de Goodiepal va más allá de la colaboración. El artículo sobre Goodiepal~\citep{scudder2026goodiepal} identifica cinco hilos que se trasladan a \ac{}: diseño que prioriza el instrumento, comunidad organizada por afinidad en lugar de institución, obras diseñadas para resistir la reproducción digital y pedagogía radical a través del compromiso directo en lugar del currículo.
172
+
173
+
\subsection{Por qué la historia importa para la proyección}
174
+
175
+
La historia de 94 proyectos restringe nuestra proyección de dos maneras. Primero, hace improbables los giros repentinos. @jeffrey ha estado orbitando los mismos problemas---herramientas personales, instrumentos creativos, diseño basado en restricciones---durante 15 años. Los próximos 5 años casi con certeza permanecerán dentro de esta órbita. Segundo, hace improbable el abandono por las razones por las que la gente suele abandonar proyectos (aburrimiento, pérdida de interés, atracción por algo más brillante). El riesgo no es la distracción; es el agotamiento. Volvemos a esto en \S\ref{sec:giveup}.
176
+
177
+
% ============ 3. LA OLA DE HARDWARE EXCEDENTE ============
178
+
179
+
\section{La ola de hardware excedente}
180
+
\label{sec:surplus}
181
+
182
+
La mayor fuerza individual que actúa sobre el futuro de \ac{} es externa: en octubre de 2025, Microsoft finalizó el soporte para Windows 10, convirtiendo en obsoletos según estándares institucionales unos 240 millones de PC estimados~\citep{ewaste2024monitor}. Estas máquinas no están rotas. Son ThinkPads, EliteBooks y Latitudes con 8--16\,GB de RAM, pantallas 1080p, WiFi y baterías de 6--10 horas. Cuestan \$30--80 en el mercado de excedentes. Son la materia prima para todo lo que sigue.
183
+
184
+
\subsection{De prototipo a flota (2026--2027)}
185
+
186
+
\acos{} ya arranca en hardware excedente~\citep{scudder2026os}. La brecha entre ``arranca en dos ThinkPads en el apartamento de @jeffrey'' y ``arranca en 30 máquinas en un aula'' no es principalmente técnica. Es operativa: gestión de credenciales WiFi, aprovisionamiento de identidad por dispositivo, pruebas de compatibilidad de hardware en docenas de modelos de portátiles y un flujo de trabajo de flasheo que una persona no técnica pueda ejecutar.
187
+
188
+
El trabajo probable a corto plazo es prosaico pero crítico:
189
+
190
+
\begin{itemize}
191
+
\item \textbf{Almacenamiento WiFi por usuario}: mover los SSID codificados fuera de los pieces JavaScript a archivos de configuración persistentes por dispositivo que sobrevivan actualizaciones OTA
192
+
\item \textbf{Matriz de compatibilidad de hardware}: pruebas sistemáticas en las series ThinkPad X1/T/L, HP EliteBook 800, Dell Latitude 5000/7000
193
+
\item \textbf{Flasheo con un solo comando}: un constructor de imagen USB que tome un handle, colores y credenciales WiFi y produzca una unidad arrancable
194
+
\item \textbf{Slots de kernel A/B}: arranque de doble partición con reversión automática si el nuevo kernel falla las comprobaciones de salud
195
+
\end{itemize}
196
+
197
+
Estas no son funcionalidades glamurosas. Son la diferencia entre un proyecto artístico y un proyecto de infraestructura. La trayectoria de la base de código---las actualizaciones OTA ya funcionan, los nombres de compilación ya se generan, la identidad del dispositivo ya se inscribe en la partición de arranque---sugiere que @jeffrey comprende esta distinción y se está moviendo hacia el lado de la infraestructura.
198
+
199
+
\subsection{El instrumento de 50 dólares (2027--2028)}
200
+
201
+
Si el trabajo operativo se materializa, el argumento económico se vuelve muy elocuente: un instrumento de computación creativa completo---personalizado, autoactualizable, sin requerir infraestructura de TI---por el precio de un portátil excedente y una unidad USB. Sin matriculación Chromebook. Sin Apple ID. Sin suscripción.
202
+
203
+
El proyecto OLPC~\citep{kraemer2009olpc} demostró que los enfoques de hardware primero para el acceso a la computación fracasan en costos y logística. La Raspberry Pi abordó el costo (\$35) pero requiere \$150 en accesorios. La propuesta de \ac{} es diferente: el hardware ya existe, ya tiene pantalla, teclado, batería y WiFi, y está siendo descartado por millones. El software ocupa 89\,MB.
204
+
205
+
El resultado probable para 2028 no es la adopción masiva sino \emph{puntos de prueba}: un puñado de aulas, centros comunitarios o contextos de talleres donde flotas de 10--30 máquinas excedentes ejecutan \acos{} y los resultados se documentan. Estos puntos de prueba se convierten en la base de evidencia para solicitudes de subvenciones, alianzas institucionales y los argumentos de sostenibilidad descritos en \S\ref{sec:sustainability}.
206
+
207
+
% ============ 3. ENSAMBLES PLANETARIOS ============
208
+
209
+
\section{Ensambles planetarios}
210
+
\label{sec:ensembles}
211
+
212
+
El artículo sobre PLOrk~\citep{scudder2026plork} presenta un argumento que la base de código existente ya respalda: las orquestas de portátiles han sido musicalmente legítimas desde que el PLOrk de Princeton demostró el concepto en 2006~\citep{trueman2006plork}, pero el modelo está atrapado en universidades a \$1.500+ por plaza. \acos{} sobre hardware excedente reduce el costo a \$50/plaza. La pregunta es si alguien tocará.
213
+
214
+
\subsection{notepat como instrumento de ensamble (2026--2027)}
215
+
216
+
\np{} ya es un instrumento de teclado polifónico con síntesis de 32 voces, reverberación de sala y selección de tipo de onda~\citep{scudder2026notepat}. Corre sobre bare metal a 192\,kHz. El ingrediente que falta para la performance en ensamble no es la calidad de audio sino la \emph{coordinación}: tempo sincronizado, espacio armónico compartido y una interfaz de director.
217
+
218
+
La ruta de desarrollo probable:
219
+
220
+
\begin{itemize}
221
+
\item \textbf{Sincronización UDP de ensamble}: extender la red de doble canal existente (WebSocket + UDP) para sincronizar relojes de tempo entre dispositivos en una red local
222
+
\item \textbf{Piece de director}: un nuevo piece que muestre el estado del ensamble y permita al director establecer tempo, tonalidad y dinámica
223
+
\item \textbf{Espacialización}: usar las posiciones físicas de los portátiles excedentes como altavoces distribuidos---el ensamble \emph{es} el sistema de sonido, siguiendo el modelo de música participativa de Turino~\citep{turino2008music}
224
+
\end{itemize}
225
+
226
+
Este hilo tiene un evidente atractivo para conferencias. Una demostración en vivo de 10 ThinkPads excedentes tocando una pieza musical coordinada---cada uno mostrando el handle del intérprete en texto arcoíris, cada uno contribuyendo una voz a un campo sonoro distribuido---es el tipo de demo que gana menciones en Ars Electronica y presentaciones en NIME.
227
+
228
+
\subsection{Más allá de la música (2028--2031)}
229
+
230
+
El modelo de ensamble se generaliza más allá de la música. Una red de máquinas excedentes ejecutando pieces coordinados podría ser:
231
+
232
+
\begin{itemize}
233
+
\item Un \textbf{muro de dibujo distribuido}: cada pantalla muestra una sección de un lienzo mayor, los participantes dibujan localmente y la red compone el resultado
234
+
\item Un \textbf{entorno colaborativo de KidLisp}: los estudiantes escriben programas generativos que alimentan un espacio visual compartido
235
+
\item Una \textbf{partitura de performance}: las máquinas ejecutan una partitura gráfica~\citep{scudder2026pieces}, cada una interpretando la misma notación a través de diferentes pieces
236
+
\end{itemize}
237
+
238
+
La infraestructura para todo esto ya existe: relay WebSocket, broadcast UDP, identidad por dispositivo y un modelo de pieces que soporta cualquier combinación de gráficos, audio e input. Lo que falta es la \emph{coreografía}---los propios pieces y las formas sociales a su alrededor.
239
+
240
+
% ============ LA TERCERA DIMENSIÓN ============
241
+
242
+
\section{La tercera dimensión}
243
+
\label{sec:3d}
244
+
245
+
\ac{} es ampliamente percibido como un sistema 2D. La API gráfica en modo inmediato---\texttt{wipe}, \texttt{ink}, \texttt{line}, \texttt{box}---y la estética pixel-art de la mayoría de los pieces refuerzan esta impresión. Pero la infraestructura cuenta una historia diferente. Un rasterizador 3D por software completo ya existe, un FPS multijugador ya se distribuye, y las decisiones arquitectónicas tomadas en el SO bare-metal posicionan el 3D como la próxima gran frontera expresiva.
246
+
247
+
\subsection{Lo que ya funciona}
248
+
249
+
El SO bare-metal incluye \texttt{graph3d.c}, un rasterizador por software CPU de ~600 líneas con proyección en perspectiva, recorte de frustum (Sutherland-Hodgman contra 6 planos de recorte), buffer de profundidad, interpolación de color por vértice y mapeo de texturas con coordenadas baricéntricas con corrección de perspectiva. La API JavaScript expone esto a través de un constructor \texttt{Form}: los pieces crean mallas con posiciones de vértices, colores y coordenadas de textura, luego las renderizan con \texttt{ink(r,g,b).form(mesh)}.
250
+
251
+
Dos pieces de producción demuestran el sistema. \texttt{fps.mjs} proporciona una cámara en primera persona con bloqueo de puntero, movimiento WASD, planos de suelo texturizados y cubos giratorios. \texttt{1v1.mjs} extiende esto a un FPS multijugador con armas hitscan, IA de bots (estados de patrulla/persecución/huida), seguimiento de bajas y el patrón de red de doble canal (WebSocket para eventos de juego confiables, UDP para sincronización de posición de baja latencia). La ruta del navegador usa Three.js (r0.182) con renderizado WebGL e incluye soporte de sesión VR/XR~\citep{sutherland1968head}.
252
+
253
+
El sistema tiene así dos rutas 3D paralelas: un rasterizador por software en bare metal (solo CPU, sin GPU) y una ruta acelerada por hardware en el navegador (WebGL/Three.js, con infraestructura WebGPU preparada). La superficie de API es idéntica desde la perspectiva del autor del piece.
254
+
255
+
\subsection{La cuestión de la GPU en bare metal (2026--2028)}
256
+
257
+
El rasterizador por software es elegante pero fundamentalmente limitado. Cada ThinkPad y EliteBook excedente en la flota objetivo tiene una GPU integrada Intel capaz de OpenGL 4.x o Vulkan 1.x, inactiva. El subsistema DRM del kernel ya gestiona la pantalla mediante modesetting KMS; extenderlo para exponer un nodo de renderizado para rasterización acelerada por GPU es un camino de ingeniería conocido (EGL sobre DRM, o Vulkan vía \texttt{/dev/dri/renderD128}).
258
+
259
+
La trayectoria probable es cautelosa. El instinto de diseño de @jeffrey favorece el control por software sobre la delegación al hardware---toda la filosofía del SO bare-metal es ``conocer cada instrucción entre el encendido y el píxel.'' Los controladores de GPU introducen opacidad: blobs de firmware, errores de controladores, comportamiento específico del fabricante. La virtud del rasterizador por software es que es \emph{legible}: la cadena desde el vértice hasta el píxel son 600 líneas de C que un estudiante puede leer.
260
+
261
+
El compromiso probable: aceleración GPU como ruta opcional para pieces que lo necesiten, con el rasterizador por software permaneciendo como predeterminado y la implementación de referencia. Esto refleja la arquitectura del navegador, donde WebGPU existe junto al canvas 2D pero no lo reemplaza.
262
+
263
+
\subsection{3D como medio creativo (2028--2031)}
264
+
265
+
La pregunta más interesante no es técnica sino expresiva. ¿Qué significa el 3D en un sistema diseñado en torno a la restricción, la inmediatez y los pieces de archivo único?
266
+
267
+
Los proyectos predecesores ofrecen una pista. El trabajo de @jeffrey siempre ha tratado sobre \emph{pintura}: No Paint, JeffreyPaint, thePRBAT, la gira de conferencias Radical Digital Painting. La infraestructura 3D no se construye hacia un motor de juegos o una herramienta CAD. Se construye hacia la \emph{pintura espacial}---la capacidad de colocar marcas, colores y formas en el espacio tridimensional con la misma inmediatez que \texttt{ink(255,0,0).line(0,0,100,100)} proporciona en dos dimensiones.
268
+
269
+
Los pieces que importarán no son los que parecen demos de Unity. Son aquellos donde el 3D se usa como @jeffrey usa el 2D: como materia prima para instrumentos, para performances, para cosas que se tocan en lugar de consumirse. Un \np{} 3D donde las notas tienen posición espacial y la reverberación de sala es literal---sonido emanando de formas distribuidas en el espacio virtual. Un KidLisp 3D donde \texttt{(box 0 0 0 50 50 50)} coloca un cubo como \texttt{(rect 0 0 50 50)} coloca un rectángulo. Una flota de portátiles excedentes, cada uno renderizando un ángulo de cámara diferente de la misma escena 3D distribuida.
270
+
271
+
La convergencia con los ensambles (\S\ref{sec:ensembles}) es donde el 3D se vuelve genuinamente nuevo. Escenas 3D sincronizadas a través de máquinas excedentes en red---cada pantalla una ventana a un espacio virtual compartido, el input de cada jugador afectando la escena para todos los participantes---es una forma que ni los motores de juegos ni las herramientas de codificación creativa han explorado al precio de \$50/plaza. La red ya está probada (\texttt{1v1.mjs}). El hardware ya está disponible (\S\ref{sec:surplus}). La pieza que falta es la visión artística de cómo debería sentirse un instrumento espacial distribuido, y esa es precisamente el tipo de pregunta que @jeffrey ha pasado 94 proyectos aprendiendo a responder.
272
+
273
+
% ============ 5. EL GIRO ACADÉMICO ============
274
+
275
+
\section{El giro académico}
276
+
\label{sec:scholarly}
277
+
278
+
Entre el 3 y el 20 de marzo de 2026, @jeffrey produjo 19 artículos de investigación en cuatro idiomas. Este no es un comportamiento normal para un desarrollador en solitario. Señala un giro deliberado hacia la legitimidad académica---un intento de construir lo que el archivo RESEARCH-DIRECTION.md llama un ``foso de investigación'' alrededor del proyecto.
279
+
280
+
\subsection{La fábrica de artículos (2026--2027)}
281
+
282
+
La infraestructura de artículos ya es industrial: una plantilla \LaTeX{} personalizada con fuentes de AC, construcción automatizada de PDF vía un servidor (``el horno''), un formato de tarjetas para impresiones de una sola hoja, y un pipeline de traducción que produce ediciones en danés, español y chino de cada artículo. La biblioteca de más de 40 lecturas proporciona la base de citaciones. El pipeline está diseñado para producir, no para prototipar.
283
+
284
+
La trayectoria a corto plazo es la presentación: ACM C\&C Demos (16 de abril), ICCC Short Papers (24 de abril), artículos de software JOSS (continuo). Si alguno de estos resulta aceptado, el proyecto gana un punto de apoyo académico que la mayoría de las herramientas de codificación creativa nunca alcanzan. Processing~\citep{reas2007processing} y Scratch~\citep{resnick2009scratch} construyeron su legitimidad académica a lo largo de años; @jeffrey intenta comprimir esa línea temporal produciendo volumen y apuntando a múltiples foros simultáneamente.
285
+
286
+
\subsection{Identidad artista-académico (2028--2031)}
287
+
288
+
El artículo sobre CalArts argumenta que una escuela de arte es un sistema operativo---que las estructuras de proximidad, crítica y contaminación disciplinaria que caracterizan instituciones como CalArts pueden portarse al software. Si @jeffrey continúa publicando a este ritmo, los artículos mismos se convierten en un cuerpo de obra: no documentación de un proyecto de software, sino un argumento sostenido sobre qué es la computación creativa y para quién es.
289
+
290
+
El resultado probable a 5 años es uno de dos escenarios:
291
+
292
+
\begin{enumerate}
293
+
\item \textbf{El foso se mantiene}: 6--10 artículos se publican en foros con revisión por pares, @jeffrey es invitado a hablar en conferencias, y \ac{} entra en el canon junto a Processing, Scratch y Sonic Pi~\citep{aaron2016sonic} como un entorno de computación creativa reconocido. Los artículos crean un ciclo de retroalimentación: la atención académica trae usuarios, los usuarios crean pieces, los pieces generan nuevos artículos.
294
+
\item \textbf{El foso no se mantiene}: las presentaciones son rechazadas, el patrón de autor único levanta sospechas entre los revisores, y la infraestructura de artículos se vuelve latente. El código sobrevive; la identidad académica no. Este es el resultado más común para artistas-programadores.
295
+
\end{enumerate}
296
+
297
+
La apuesta honesta está en algún punto intermedio: unas pocas publicaciones son aceptadas, suficientes para establecer credibilidad en foros de nicho (NIME, xCoAx, ICLC), pero las conferencias principales de HCI y PL permanecen fuera de alcance sin colaboradores y estudios de usuarios.
298
+
299
+
% ============ 5. LA VIDA PROPIA DE KIDLISP ============
300
+
301
+
\section{La vida propia de KidLisp}
302
+
\label{sec:kidlisp}
303
+
304
+
KidLisp es un dialecto Lisp de 118 funciones para arte generativo~\citep{scudder2026kidlisp}. Está aislado (sin I/O de archivos, sin red), corre en el navegador y ya ha acumulado 16.779 programas almacenados y una integración de acuñación blockchain vía Tezos. El lenguaje es lo suficientemente pequeño como para caber en una ficha.
305
+
306
+
\subsection{Comunidad lingüística (2026--2028)}
307
+
308
+
El sistema ``keeps'' de Tezos---donde los programas KidLisp se acuñan como obras de arte on-chain por 2,5 XTZ---crea un incentivo económico para escribir KidLisp. El contrato keeps (v11) está activo, la UI de acuñación existe en keeps.kidlisp.com, y 5 tokens ya han sido acuñados y migrados. Si el mercado de arte generativo permanece activo, este hilo se sostiene por sí solo.
309
+
310
+
La posibilidad más interesante es pedagógica. Las restricciones de KidLisp---sin mutación de estado, sin efectos secundarios más allá del dibujo, 118 funciones, corre en un navegador---lo convierten en candidato para entornos de enseñanza. Un currículo de KidLisp construido alrededor del formato de tarjetas (programas de una sola hoja que los estudiantes pueden sostener en sus manos) se alinea con el construccionismo de Papert~\citep{papert1980mindstorms} y la infraestructura existente del proyecto.
311
+
312
+
\subsection{Evolución del lenguaje (2028--2031)}
313
+
314
+
KidLisp enfrentará presión para crecer. Los usuarios querrán estado, animación, interactividad, sonido. La pregunta de diseño es si el lenguaje absorbe estas funcionalidades (convirtiéndose en un lenguaje creativo de propósito general) o permanece deliberadamente mínimo (un ``lenguaje haiku'' para arte generativo estático, con JavaScript manejando todo lo demás).
315
+
316
+
La historia del proyecto sugiere lo segundo. El instinto de diseño de @jeffrey, visible a través de 94 proyectos predecesores, favorece restricciones agudas sobre la acumulación de funcionalidades. El modelo de pieces en sí---archivo único, funciones de ciclo de vida, gráficos en modo inmediato~\citep{scudder2026pieces}---es un diseño que prioriza las restricciones. KidLisp probablemente permanecerá pequeño. El crecimiento interesante estará en lo que la gente haga con él, no en lo que el lenguaje añada.
317
+
318
+
% ============ 6. SOSTENIBILIDAD ============
319
+
320
+
\section{La cuestión de la sostenibilidad}
321
+
\label{sec:sustainability}
322
+
323
+
Cada hilo descrito arriba depende de que una sola persona continúe trabajando. \ac{} no tiene financiación de capital riesgo, ni respaldo institucional, ni empleados más allá de @jeffrey. El sistema de mantenimiento AestheticAnts automatiza tareas rutinarias, pero las decisiones arquitectónicas, la escritura de artículos, las pruebas de hardware y el cultivo de la comunidad requieren atención humana.
324
+
325
+
\subsection{El panorama de financiación (2026--2028)}
326
+
327
+
El proyecto ha identificado fuentes de financiación: Creative Capital (subvenciones de proyecto de \$50.000), Prix Ars Electronica (\texteuro10.000), Gary Marsden Travel Awards y GitHub Sponsors. La fábrica de artículos es en parte una estrategia de solicitud de subvenciones: un proyecto con 19 artículos, demos en conferencias y una base de usuarios documentada es un solicitante más fuerte que uno con solo código.
328
+
329
+
Los keeps de Tezos proporcionan un pequeño flujo de ingresos. Las impresiones (20 pedidas a marzo de 2026) proporcionan otro. Ninguno es suficiente para sostener el desarrollo a tiempo completo.
330
+
331
+
La proyección honesta: para 2028, el proyecto o asegura una subvención o afiliación institucional (una residencia, un puesto docente, una beca de investigación) o se ralentiza a desarrollo en modo mantenimiento. Este no es un escenario de fracaso---muchas herramientas creativas importantes son mantenidas a tiempo parcial por sus creadores durante décadas. Pero los hilos ambiciosos (ensambles planetarios, flotas de hardware excedente, foso académico) requieren atención a tiempo completo.
332
+
333
+
\subsection{El riesgo del autor único (2028--2031)}
334
+
335
+
Las ``herramientas para la convivialidad'' de Illich~\citep{illich1973tools} argumentan que las buenas herramientas deberían ser operables sin experiencia especializada. \ac{} aspira a esto para sus usuarios, pero el proyecto en sí no es convivial en el sentido de Illich: requiere la experiencia de @jeffrey para mantenerse. El factor autobús es uno.
336
+
337
+
La mitigación ya está parcialmente en su lugar: la base de código es de código abierto, la arquitectura está documentada en 19 artículos, la API de pieces está diseñada para la simplicidad de archivo único, y el sistema AestheticAnts maneja el mantenimiento rutinario de forma autónoma. Pero la diferencia entre ``el código es abierto'' y ``alguien más puede liderar el proyecto'' es vasta.
338
+
339
+
La trayectoria probable a 5 años: @jeffrey sigue siendo el único arquitecto. Una pequeña comunidad de autores de pieces contribuye contenido (265 pieces publicados y en aumento). Uno o dos colaboradores envían pull requests para funcionalidades específicas. El proyecto no alcanza el modelo de ``mil colaboradores'' de Processing o p5.js, pero no lo necesita---su propuesta de valor no es amplitud sino profundidad: una visión única, rigurosamente mantenida, que lleva la computación creativa a lugares donde las herramientas diseñadas por comité no pueden llegar.
340
+
341
+
% ============ 7. LA CONVERGENCIA ============
342
+
343
+
\section{La convergencia}
344
+
\label{sec:convergence}
345
+
346
+
Los siete hilos descritos arriba no son pistas paralelas. Convergen.
347
+
348
+
La historia de 94 proyectos (\S\ref{sec:history}) establece la trayectoria que hace legibles los otros hilos. El hardware excedente (\S\ref{sec:surplus}) proporciona la base material para los ensambles planetarios (\S\ref{sec:ensembles}). La infraestructura 3D (\S\ref{sec:3d}) extiende el modelo de ensamble a la performance espacial. Los artículos (\S\ref{sec:scholarly}) documentan y legitiman todo. KidLisp (\S\ref{sec:kidlisp}) proporciona un punto de entrada seguro para nuevos usuarios que llegan a través de cualquiera de estos canales. La sostenibilidad (\S\ref{sec:sustainability}) determina si la convergencia sucede en absoluto---y \S\ref{sec:giveup} examina qué pasa si no sucede.
349
+
350
+
El escenario más probable a 5 años es este: para 2031, \ac{} es un entorno de computación creativa reconocido pero de nicho con:
351
+
352
+
\begin{itemize}
353
+
\item \textbf{5.000--10.000 usuarios registrados}, desde los 2.812 actuales, impulsado por la viralidad de notepat, demos en conferencias y despliegues en aulas
354
+
\item \textbf{Un SO bare-metal} desplegado en 100--500 máquinas excedentes en 5--15 sitios (escuelas, centros comunitarios, residencias artísticas, talleres)
355
+
\item \textbf{3--5 artículos publicados} en foros con revisión por pares, estableciendo una huella académica mínima
356
+
\item \textbf{Más de 50.000 programas KidLisp}, con una comunidad pequeña pero activa de arte generativo acuñando keeps en Tezos
357
+
\item \textbf{Performances en ensamble} en 2--3 festivales o conferencias, usando flotas de portátiles excedentes como instrumentos distribuidos
358
+
\item \textbf{Un único mantenedor} que sigue escribiendo la mayor parte del código, con mantenimiento asistido por IA manejando una proporción creciente del trabajo rutinario
359
+
\end{itemize}
360
+
361
+
Este no es el resultado más ambicioso, ni el más conservador. Es el resultado consistente con un proyecto que ha tomado decisiones específicas y deliberadas sobre lo que le importa---profundidad sobre amplitud, instrumentos sobre IDEs, mantenimiento sobre disrupción---y que tiene la infraestructura para cumplir con esas decisiones al ritmo que un desarrollador en solitario puede sostener.
362
+
363
+
% ============ 8. QUÉ PODRÍA CAMBIARLO TODO ============
364
+
365
+
\section{Qué podría cambiarlo todo}
366
+
\label{sec:wildcards}
367
+
368
+
Las proyecciones basadas en el impulso son confiables precisamente porque ignoran las discontinuidades. Cuatro comodines podrían alterar la trayectoria por completo:
369
+
370
+
\subsection{Un hogar institucional}
371
+
372
+
Si @jeffrey acepta un puesto docente en una escuela de arte o universidad de investigación, \ac{} gana algo que actualmente le falta: estudiantes. Una cohorte de 15--30 estudiantes usando \ac{} como su entorno principal de computación creativa durante un semestre produciría más pieces, más reportes de errores, más casos de uso y más investigación que una década de desarrollo en solitario. El argumento del artículo sobre CalArts---que una escuela de arte es un sistema operativo---funciona a la inversa: el sistema operativo podría convertirse en una escuela.
373
+
374
+
\subsection{Un momento viral}
375
+
376
+
\np{} fue publicado en Hacker News y recibió atención. Un segundo momento viral---un TikTok de un aula llena de portátiles excedentes tocando música juntos, un hilo de tweets sobre el instrumento creativo de \$50, una demo en conferencia que se filma y comparte---podría traer miles de usuarios en una semana. La infraestructura (pieces direccionables por URL, registro instantáneo, funciones sociales) está diseñada para absorber esto. Si @jeffrey \emph{quiere} absorberlo es una pregunta separada. La postura anti-plataforma del proyecto~\citep{fisher2009capitalist} sugiere ambivalencia respecto al crecimiento por el crecimiento mismo.
377
+
378
+
\subsection{IA como colaborador}
379
+
380
+
El sistema AestheticAnts ya usa IA para mantenimiento rutinario. El sistema de memoria del agente registra interacciones y mantiene continuidad entre conversaciones. Si las capacidades de IA continúan avanzando, una versión futura de este sistema podría hacer más que mantenimiento: podría escribir pieces, generar programas KidLisp, componer partituras de ensamble y redactar artículos. El riesgo de autor único (\S\ref{sec:sustainability}) disminuye si el ``autor único'' está aumentado por un colaborador de IA que comprende la historia, la filosofía y la base de código del proyecto.
381
+
382
+
Esto no es especulativo de la manera en que lo son los otros escenarios. Ya está sucediendo. La pregunta es de grado: para 2031, ¿la IA maneja el 10\% del trabajo creativo, o el 50\%? La respuesta dependerá de las decisiones que @jeffrey tome sobre qué delega y qué insiste en hacer él mismo. El énfasis del proyecto en la voz personal, en los artículos ``PSYCHO'' que portan la temperatura del autor, sugiere que el trabajo más importante seguirá siendo humano. La infraestructura a su alrededor quizás no.
383
+
384
+
\subsection{¿Qué pasa si se detiene?}
385
+
\label{sec:giveup}
386
+
387
+
Las proyecciones anteriores asumen esfuerzo continuado. Pero la historia de 94 proyectos (\S\ref{sec:history}) contiene un patrón que debe nombrarse: @jeffrey ha abandonado cosas antes. No Paint tuvo cinco encarnaciones. Cada una fue abandonada, no porque la idea fracasara, sino porque la implementación se calcificó---porque la brecha entre lo que la herramienta \emph{era} y lo que \emph{debería ser} se volvió intolerable. Los reinicios no fueron fracasos de compromiso. Fueron expresiones de él.
388
+
389
+
El riesgo para \ac{} no es que @jeffrey pierda interés. Quince años orbitando los mismos problemas descarta el abandono casual. El riesgo es el \emph{agotamiento estructural}: la acumulación de peso operativo---facturas de servidores, soporte de usuarios, pruebas de hardware, presentaciones de artículos, solicitudes de subvenciones, actualizaciones de dependencias---hasta que la carga de mantenimiento desplaza el trabajo creativo que hace que el proyecto valga la pena mantener. Ukeles~\citep{ukeles1969manifesto} argumentó que el mantenimiento es arte, pero incluso Ukeles reconoció que el mantenimiento sin reconocimiento se convierte en trabajo invisible.
390
+
391
+
Tres escenarios de cese merecen consideración:
392
+
393
+
\begin{enumerate}
394
+
\item \textbf{El desvanecimiento silencioso}: el desarrollo se reduce a commits esporádicos, los servidores siguen activos pero la comunidad se dispersa, y \ac{} se une a la larga lista de herramientas personales ambiciosas que existen como archivos en lugar de sistemas vivos. Este es el resultado más común para proyectos de computación creativa de autor único. No es dramático. Es el caso por defecto.
395
+
396
+
\item \textbf{La parada deliberada}: @jeffrey declara el proyecto completo en algún límite natural---quizás cuando el SO arranca de manera confiable en una docena de modelos de portátiles, o cuando la cuenta de artículos alcanza un número redondo, o cuando el piece número 100 es publicado por alguien distinto a él. Regresa a pintar sobre lienzo (la exposición en Venice Family Clinic en mayo de 2026 sugiere que este hilo ya está activo). El código permanece abierto. Alguien podría bifurcarlo. Lo más probable es que nadie lo haga.
397
+
398
+
\item \textbf{El reinicio número 95}: @jeffrey abandona \ac{} para construir su sucesor. Este es el patrón que la historia predice con más fuerza. No Paint se convirtió en \ac{}. \ac{} podría convertirse en otra cosa---algo que absorba las lecciones del SO, el modelo de pieces, la red de ensamble y el rasterizador 3D, pero se deshaga del peso de infraestructura acumulado. El nuevo proyecto comienza limpio, en un solo archivo, y el ciclo empieza de nuevo. Desde fuera, esto parece un fracaso. Desde dentro del linaje de 94 proyectos, parece el proceso funcionando exactamente como fue diseñado.
399
+
\end{enumerate}
400
+
401
+
La evaluación honesta: el escenario 3 es improbable dentro de 5 años porque \ac{} ha alcanzado velocidad de escape de maneras que No Paint nunca logró---una base de usuarios registrados, un SO bare-metal, una integración blockchain, 19 artículos, un lenguaje con más de 16.000 programas. El costo hundido es demasiado alto para un reinicio limpio. Pero el escenario 1 es totalmente posible si la cuestión de sostenibilidad (\S\ref{sec:sustainability}) queda sin respuesta. Un proyecto así de ambicioso, mantenido por una persona sin financiación estable, siempre está a un mal año del desvanecimiento silencioso.
402
+
403
+
La mitigación es la misma que ha sostenido el proyecto hasta ahora: hacer que el trabajo en sí sea lo suficientemente gratificante como para que la carga operativa sea tolerable. Los artículos, las performances, el rasterizador 3D escrito desde cero, el arranque bare-metal que toma 7 segundos---estos no son funcionalidades en una hoja de ruta. Son la práctica creativa. Si la práctica deja de ser interesante, el proyecto se detiene. Si sigue siendo interesante, el proyecto sobrevive a todo menos a que se apaguen las luces.
404
+
405
+
% ============ 10. CONCLUSIÓN ============
406
+
407
+
\section{Conclusión}
408
+
409
+
Aesthetic Computer es un proyecto que sabe lo que es. No busca ajuste producto-mercado, no pivota hacia la empresa, no optimiza para métricas de crecimiento. Es un instrumento personal de computación creativa siendo construido en público por una sola persona que ha estado haciendo versiones de él durante más de una década a través de 94 proyectos predecesores.
410
+
411
+
Los próximos cinco años serán moldeados por fuerzas tanto internas (el ritmo que @jeffrey puede sostener, la financiación que puede asegurar) como externas (240 millones de PC excedentes, la economía del arte generativo, el ciclo de conferencias académicas). La infraestructura del proyecto---SO bare-metal, fábrica de artículos, modelo de pieces, red social, acuñación blockchain---está construida para absorber estas fuerzas. Si lo hará es una cuestión de resistencia, suerte y la disposición del mundo a importarle las herramientas de computación creativa que no son propiedad de una plataforma.
412
+
413
+
Nelson escribió en 1974 que ``puedes y debes entender las computadoras AHORA''~\citep{nelson1974computerlib}. Illich escribió en 1973 que las herramientas deberían expandir la autonomía personal, no requerir mediación institucional~\citep{illich1973tools}. Ukeles escribió en 1969 que el mantenimiento es arte~\citep{ukeles1969manifesto}. \ac{} es la síntesis: una herramienta que es personal, convivial y mantenida como práctica creativa. La apuesta es que esta síntesis, aplicada a hardware excedente y sostenida en el tiempo, crea algo que perdura.
414
+
415
+
Si lo hace es la única pregunta interesante. Este artículo no ofrece respuesta, solo una lectura de las fuerzas en juego. El código decidirá.
416
+
417
+
\vspace{0.5em}
418
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
419
+
420
+
\vspace{0.5em}\noindent\textit{Traducido del inglés. Versión original disponible en \url{https://papers.aesthetic.computer}}
421
+
422
+
% ============ REFERENCES ============
423
+
424
+
\bibliographystyle{plainnat}
425
+
\bibliography{references}
426
+
427
+
\end{document}
+429
papers/arxiv-futures/futures-zh.tex
+429
papers/arxiv-futures/futures-zh.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\usepackage{xeCJK}
11
+
\setCJKmainfont{Droid Sans Fallback}
12
+
13
+
\setmainfont{Latin Modern Roman}
14
+
\setsansfont{Latin Modern Sans}
15
+
16
+
% Custom AC fonts
17
+
\newfontfamily\acbold{ywft-processing-bold}[
18
+
Path=../../system/public/type/webfonts/,
19
+
Extension=.ttf
20
+
]
21
+
\newfontfamily\aclight{ywft-processing-light}[
22
+
Path=../../system/public/type/webfonts/,
23
+
Extension=.ttf
24
+
]
25
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
26
+
27
+
% === PACKAGES ===
28
+
\usepackage{xcolor}
29
+
\usepackage{titlesec}
30
+
\usepackage{enumitem}
31
+
\usepackage{booktabs}
32
+
\usepackage{tabularx}
33
+
\usepackage{fancyhdr}
34
+
\usepackage{hyperref}
35
+
\usepackage{graphicx}
36
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
37
+
\usepackage{ragged2e}
38
+
\usepackage{microtype}
39
+
\usepackage{natbib}
40
+
\usepackage[colorspec=0.92]{draftwatermark}
41
+
42
+
% === COLORS (AC palette) ===
43
+
\definecolor{acpink}{RGB}{180,72,135}
44
+
\definecolor{acpurple}{RGB}{120,80,180}
45
+
\definecolor{acdark}{RGB}{64,56,74}
46
+
\definecolor{acgray}{RGB}{119,119,119}
47
+
\definecolor{draftcolor}{RGB}{180,72,135}
48
+
49
+
% === DRAFT WATERMARK ===
50
+
\DraftwatermarkOptions{
51
+
text=WORKING DRAFT,
52
+
fontsize=3cm,
53
+
color=draftcolor!18,
54
+
angle=45,
55
+
pos={0.5\paperwidth, 0.5\paperheight}
56
+
}
57
+
58
+
% === HYPERREF ===
59
+
\hypersetup{
60
+
colorlinks=true,
61
+
linkcolor=acpurple,
62
+
urlcolor=acpurple,
63
+
citecolor=acpurple,
64
+
pdfauthor={@jeffrey},
65
+
pdftitle={五年之后：Aesthetic Computer 可能会变成什么},
66
+
}
67
+
68
+
% === SECTION FORMATTING ===
69
+
\titleformat{\section}
70
+
{\normalfont\bfseries\normalsize\uppercase}
71
+
{\thesection.}
72
+
{0.5em}
73
+
{}
74
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
75
+
76
+
\titleformat{\subsection}
77
+
{\normalfont\bfseries\small}
78
+
{\thesubsection}
79
+
{0.5em}
80
+
{}
81
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
82
+
83
+
% === HEADER/FOOTER ===
84
+
\pagestyle{fancy}
85
+
\fancyhf{}
86
+
\renewcommand{\headrulewidth}{0pt}
87
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{工作草稿 --- 请勿引用}}
88
+
\fancyfoot[C]{\footnotesize\thepage}
89
+
90
+
% === CUSTOM COMMANDS ===
91
+
\newcommand{\ac}{\textsc{Aesthetic Computer}}
92
+
\newcommand{\acos}{\textsc{AC Native OS}}
93
+
\newcommand{\np}{\textsc{notepat}}
94
+
95
+
% === LIST SETTINGS ===
96
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
97
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
98
+
99
+
% === COLUMN SEPARATION ===
100
+
\setlength{\columnsep}{1.8em}
101
+
102
+
% === PARAGRAPH SETTINGS ===
103
+
\setlength{\parindent}{1em}
104
+
\setlength{\parskip}{0.3em}
105
+
106
+
% Hyphenation for narrow two-column layout
107
+
\tolerance=800
108
+
\emergencystretch=1em
109
+
\hyphenpenalty=50
110
+
111
+
\begin{document}
112
+
113
+
% ============ TITLE BLOCK ============
114
+
115
+
\twocolumn[{%
116
+
\begin{center}
117
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
118
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} 五年之后}\par
119
+
\vspace{0.2em}
120
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} Aesthetic Computer 可能会变成什么}\par
121
+
\vspace{0.3em}
122
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} 剩余硬件、空间乐器与个人工具的长期博弈}\par
123
+
\vspace{0.6em}
124
+
{\normalsize @jeffrey}\par
125
+
{\small\color{acgray} Aesthetic.Computer}\par
126
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
127
+
\vspace{0.3em}
128
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
129
+
\vspace{0.6em}
130
+
\rule{\textwidth}{1.5pt}
131
+
\vspace{0.5em}
132
+
\end{center}
133
+
134
+
\begin{center}
135
+
{\small\color{acpink}\textbf{[ 工作草稿 --- 请勿引用 ]}}
136
+
\end{center}
137
+
\vspace{0.3em}
138
+
139
+
\begin{quote}
140
+
\small\noindent\textbf{摘要。}
141
+
本文基于项目当前的发展轨迹、现有基础设施、明确的雄心以及作用于其上的经济、文化和物质力量，推断\ac{}未来五年（2026--2031）的发展方向。我们认为，该项目可能沿着七个汇聚的轴线演进：(1)~一条由94个项目组成的创作谱系的延续，限制了可能未来的空间；(2)~\acos{}成熟为一种可大规模部署于剩余硬件的工具；(3)~分布式笔记本电脑合奏作为音乐和教学形式的出现；(4)~3D从软件光栅化器扩展为空间创作媒介；(5)~通过持续的论文产出深化学术身份；(6)~KidLisp成长为自给自足的创作语言社区；以及(7)~对可持续性的清算---包括项目主动或被动终止的可能性---将决定它能否在自身的雄心中存活。这不是一份路线图。这是对动量的解读---试图根据一个项目已经选择做的事情，来追问它\emph{想要成为}什么。
142
+
\end{quote}
143
+
\vspace{0.5em}
144
+
}]
145
+
146
+
% ============ 1. 引言 ============
147
+
148
+
\section{引言}
149
+
150
+
\ac{}是一个移动优先的运行时和创意计算社交网络，包含359个内置交互程序（"pieces"）、一个可将任何x86\_64机器启动为创意工具的裸机Linux操作系统、一种用于生成艺术的极简Lisp方言，以及一个拥有2,812名注册用户的不断壮大的社区~\citep{scudder2026ac}。该项目主要由单一开发者@jeffrey编写和维护，AI辅助维护系统（"AestheticAnts"）负责处理日常维护工作。
151
+
152
+
截至2026年3月，该项目已产出19篇四种语言的研究论文、一个7.3秒启动的裸机操作系统~\citep{scudder2026os}、一个用于铸造生成艺术作品的区块链集成，以及一个7,912行的音乐乐器（\np{}），它已成为系统的入口~\citep{scudder2026notepat}。代码库的谱系可追溯到94个前身项目，跨越十多年的工具制作历程。
153
+
154
+
本文不提议\ac{}\emph{应该}做什么。它试图解读它\emph{可能会}做什么，基于代码、论文、基础设施决策和塑造该项目至今的哲学承诺中已经可见的动量。
155
+
156
+
% ============ 2. 九十四个项目 ============
157
+
158
+
\section{九十四个项目，仍在继续}
159
+
\label{sec:history}
160
+
161
+
对\ac{}未来的任何预测都必须面对其过去的深度。该项目不是一个正在寻找产品市场契合度的初创公司。它是一个持续探究的第95次迭代：\emph{个人创意计算工具应该是什么样的？}
162
+
163
+
\subsection{绘图软件谱系（2011--2020）}
164
+
165
+
考古论文~\citep{scudder2026archaeology}追溯\ac{}经历的94个前身项目，涵盖两个GitHub账户（50多个仓库）、一个109\,GB的遗留服务器档案和一个Dropbox语料库。轨迹从\textbf{thePRBAT}（Polygon Replicating Bitmap Authoring Tool，2011）开始——一个基于Flash的数字图像工具，作为Ringling学院的BFA论文而构建——经过十年的绘图软件变体到达\ac{}：\textbf{JeffreyPaint}（2014，JavaScript + Unity）、\textbf{Finger Quilt}（2016，iOS/Swift）、\textbf{Dot}（2017，一个预示AC \texttt{plot}磁盘的绘图应用），以及最重要的\textbf{No Paint}（2014--2020），经历了五次化身——Rails、JavaScript填充、WebGL原型、iOS/Cordova、Vercel站点——最终被吸收进\ac{}。
166
+
167
+
这不是一部废弃项目的历史。这是一部\emph{重启}的历史：同一个人，提出同一个问题，选择重新开始而不是累积功能。这种模式在\ac{}本身中可见：piece模型（单文件、生命周期函数、即时模式图形）是一种限制优先的设计，\emph{阻止}了杀死早期迭代的功能累积。
168
+
169
+
\subsection{表演转向（2016--2018）}
170
+
171
+
在2016年至2018年间，@jeffrey与Goodiepal \& Pals在欧洲65多个场地巡演，构建实时表演工具：观众参与界面、音乐记谱渲染器、现场讲座字幕显示。这些工具——快速构建、使用一次、随后丢弃——确立了一个在\ac{}中延续的设计原则：软件作为乐器，而非产品。这些工具是被演奏的，不是被交付的。
172
+
173
+
Goodiepal的影响比合作更深。Goodiepal论文~\citep{scudder2026goodiepal}识别出延续到\ac{}的五条线索：乐器优先设计、通过亲和力而非机构组织的社区、设计为抵抗数字复制的作品，以及通过直接参与而非课程设置的激进教育学。
174
+
175
+
\subsection{历史对预测为何重要}
176
+
177
+
94个项目的历史以两种方式限制了我们的预测。首先，它使突然的转向变得不太可能。@jeffrey围绕同样的问题——个人工具、创意乐器、基于限制的设计——已经运转了15年。接下来的5年几乎肯定会停留在这个轨道内。其次，它使因人们通常放弃项目的原因（无聊、失去兴趣、被更闪亮的东西吸引）而放弃变得不太可能。风险不是分心，而是疲惫。我们将在\S\ref{sec:giveup}中回到这一点。
178
+
179
+
% ============ 3. 剩余硬件浪潮 ============
180
+
181
+
\section{剩余硬件浪潮}
182
+
\label{sec:surplus}
183
+
184
+
作用于\ac{}未来的最大单一外部力量：2025年10月，微软终止了对Windows 10的支持，按机构标准使估计2.4亿台PC过时~\citep{ewaste2024monitor}。这些机器没有坏。它们是配备8--16\,GB RAM、1080p屏幕、WiFi和6--10小时续航电池的ThinkPad、EliteBook和Latitude。它们在剩余市场上售价\$30--80。它们是后续一切的原材料。
185
+
186
+
\subsection{从原型到车队（2026--2027）}
187
+
188
+
\acos{}已经可以在剩余硬件上启动~\citep{scudder2026os}。从"在@jeffrey公寓的两台ThinkPad上启动"到"在教室的30台机器上启动"之间的差距主要不是技术性的。它是运营性的：WiFi凭据管理、每台设备的身份配置、在数十种笔记本型号上的硬件兼容性测试，以及一个非技术人员可以执行的刷机工作流。
189
+
190
+
近期可能的工作是平凡但关键的：
191
+
192
+
\begin{itemize}
193
+
\item \textbf{每用户WiFi存储}：将硬编码的SSID从JavaScript pieces移到持久的每设备配置文件中，使其在OTA更新后保持不变
194
+
\item \textbf{硬件兼容性矩阵}：系统性地测试ThinkPad X1/T/L系列、HP EliteBook 800系列、Dell Latitude 5000/7000系列
195
+
\item \textbf{单命令刷机}：一个USB镜像构建器，接收handle、颜色和WiFi凭据，产出一个可启动驱动器
196
+
\item \textbf{A/B内核槽}：双分区启动，如果新内核健康检查失败则自动回滚
197
+
\end{itemize}
198
+
199
+
这些不是令人瞩目的功能。它们是艺术项目和基础设施项目之间的区别。代码库的轨迹——OTA更新已经工作、构建名称已经生成、设备身份已经刻入启动分区——表明@jeffrey理解这一区别，正在向基础设施方向迈进。
200
+
201
+
\subsection{五十美元的乐器（2027--2028）}
202
+
203
+
如果运营工作落地，经济论证将变得非常有力：一个完整的创意计算工具——个性化、自更新、不需要任何IT基础设施——只需一台剩余笔记本电脑和一个USB驱动器的价格。无需Chromebook注册。无需Apple ID。无需订阅。
204
+
205
+
OLPC项目~\citep{kraemer2009olpc}证明了硬件优先的计算访问方案在成本和后勤方面会失败。树莓派解决了成本问题（\$35），但需要\$150的配件。\ac{}的主张不同：硬件已经存在，已经有屏幕、键盘、电池和WiFi，而且正在被数百万台地丢弃。软件只有89\,MB。
206
+
207
+
到2028年的可能结果不是大规模采用，而是\emph{验证点}：若干教室、社区中心或工作坊场景，其中10--30台剩余机器的车队运行\acos{}，结果被记录下来。这些验证点成为申请资助、机构合作伙伴关系以及\S\ref{sec:sustainability}中描述的可持续性论证的证据基础。
208
+
209
+
% ============ 3. 行星合奏 ============
210
+
211
+
\section{行星合奏}
212
+
\label{sec:ensembles}
213
+
214
+
PLOrk论文~\citep{scudder2026plork}提出了一个现有代码库已经支持的论点：自普林斯顿的PLOrk于2006年证明这一概念以来，笔记本电脑管弦乐队已经是音乐上合法的~\citep{trueman2006plork}，但该模式以每席位\$1,500+的价格被困在大学里。剩余硬件上的\acos{}将成本降至\$50/席位。问题是是否有人会演奏。
215
+
216
+
\subsection{notepat作为合奏乐器（2026--2027）}
217
+
218
+
\np{}已经是一个具有32声部合成、房间混响和波形类型选择的复音键盘乐器~\citep{scudder2026notepat}。它在裸机上以192\,kHz运行。合奏表演缺少的要素不是音频质量，而是\emph{协调}：同步的节拍、共享的和声空间和指挥界面。
219
+
220
+
可能的开发路径：
221
+
222
+
\begin{itemize}
223
+
\item \textbf{UDP合奏同步}：扩展现有的双通道网络（WebSocket + UDP），以在本地网络的设备间同步节拍时钟
224
+
\item \textbf{指挥piece}：一个新的piece，显示合奏状态并允许指挥设置节拍、调性和力度
225
+
\item \textbf{空间化}：利用剩余笔记本电脑的物理位置作为分布式扬声器——合奏本身\emph{就是}音响系统，遵循Turino的参与式音乐模型~\citep{turino2008music}
226
+
\end{itemize}
227
+
228
+
这条线索具有明显的会议吸引力。10台剩余ThinkPad演奏一首协调音乐作品的现场演示——每台显示演奏者的handle（以彩虹文字），每台为分布式声场贡献一个声部——是那种能赢得Ars Electronica提名和NIME投稿的演示。
229
+
230
+
\subsection{超越音乐（2028--2031）}
231
+
232
+
合奏模型可以推广到音乐之外。一个运行协调pieces的剩余机器网络可以是：
233
+
234
+
\begin{itemize}
235
+
\item 一面\textbf{分布式绘画墙}：每块屏幕显示更大画布的一个部分，参与者在本地绘画，网络合成结果
236
+
\item 一个\textbf{协作KidLisp环境}：学生编写生成程序，汇入一个共享视觉空间
237
+
\item 一份\textbf{表演总谱}：机器执行一份图形总谱~\citep{scudder2026pieces}，每台通过不同的pieces诠释相同的记谱
238
+
\end{itemize}
239
+
240
+
所有这些的基础设施已经存在：WebSocket中继、UDP广播、每设备身份，以及支持任意图形、音频和输入组合的piece模型。缺少的是\emph{编排}——pieces本身以及围绕它们的社会形式。
241
+
242
+
% ============ 第三维度 ============
243
+
244
+
\section{第三维度}
245
+
\label{sec:3d}
246
+
247
+
\ac{}被广泛认为是一个2D系统。即时模式图形API——\texttt{wipe}、\texttt{ink}、\texttt{line}、\texttt{box}——以及大多数pieces的像素艺术美学强化了这种印象。但基础设施讲述了一个不同的故事。一个完整的软件3D光栅化器已经存在，一个多人FPS已经发布，裸机操作系统中的架构选择将3D定位为下一个重要的表达前沿。
248
+
249
+
\subsection{已经可以工作的部分}
250
+
251
+
裸机操作系统包含\texttt{graph3d.c}，一个约600行的CPU软件光栅化器，具有透视投影、视锥体裁剪（针对6个裁剪平面的Sutherland-Hodgman算法）、深度缓冲、逐顶点颜色插值和具有透视校正重心坐标的纹理映射。JavaScript API通过\texttt{Form}构造器暴露此功能：pieces创建具有顶点位置、颜色和纹理坐标的网格，然后用\texttt{ink(r,g,b).form(mesh)}渲染它们。
252
+
253
+
两个生产pieces展示了该系统。\texttt{fps.mjs}提供了一个具有指针锁定、WASD移动、纹理地面和旋转立方体的第一人称摄像机。\texttt{1v1.mjs}将其扩展为一个多人FPS，具有命中扫描武器、机器人AI（巡逻/追击/逃跑状态）、击杀追踪和双通道网络模式（WebSocket用于可靠游戏事件，UDP用于低延迟位置同步）。浏览器路径使用Three.js（r0.182）进行WebGL渲染，并包含VR/XR会话支持~\citep{sutherland1968head}。
254
+
255
+
因此，系统具有两条并行的3D路径：裸机上的软件光栅化器（纯CPU，无GPU）和浏览器中的硬件加速路径（WebGL/Three.js，WebGPU基础设施已就绪）。从piece作者的角度来看，API接口是相同的。
256
+
257
+
\subsection{裸机上的GPU问题（2026--2028）}
258
+
259
+
软件光栅化器优雅但从根本上受限。目标车队中的每台剩余ThinkPad和EliteBook都有一个支持OpenGL 4.x或Vulkan 1.x的Intel集成GPU，闲置不用。内核的DRM子系统已经通过KMS模式设置管理显示；扩展它以暴露用于GPU加速光栅化的渲染节点是一条已知的工程路径（DRM上的EGL，或通过\texttt{/dev/dri/renderD128}的Vulkan）。
260
+
261
+
可能的轨迹是谨慎的。@jeffrey的设计本能倾向于软件控制而非硬件委托——整个裸机操作系统的哲学是"知道从通电到像素之间的每一条指令"。GPU驱动程序引入不透明性：固件blob、驱动程序bug、厂商特定行为。软件光栅化器的优点在于它是\emph{可读的}：从顶点到像素的流水线是600行学生可以阅读的C代码。
262
+
263
+
可能的妥协方案：GPU加速作为需要它的pieces的可选路径，软件光栅化器保持为默认和参考实现。这反映了浏览器架构，其中WebGPU与2D canvas并存但不取代它。
264
+
265
+
\subsection{3D作为创作媒介（2028--2031）}
266
+
267
+
更有趣的问题不是技术性的而是表达性的。在一个围绕限制、即时性和单文件pieces设计的系统中，3D意味着什么？
268
+
269
+
前身项目提供了线索。@jeffrey的工作始终围绕\emph{绘画}：No Paint、JeffreyPaint、thePRBAT、Radical Digital Painting巡回讲座。3D基础设施不是朝着游戏引擎或CAD工具构建的。它朝着\emph{空间绘画}构建——以\texttt{ink(255,0,0).line(0,0,100,100)}在二维中提供的同样即时性，在三维空间中放置标记、颜色和形式的能力。
270
+
271
+
重要的pieces不会是那些看起来像Unity演示的。它们将是那些以@jeffrey使用2D的方式使用3D的：作为乐器的原材料，作为表演的原材料，作为被演奏而非被消费的东西。一个3D \np{}，其中音符具有空间位置，房间混响是字面意义上的——声音从分布在虚拟空间中的形体发出。一个3D KidLisp，其中\texttt{(box 0 0 0 50 50 50)}放置一个立方体，就像\texttt{(rect 0 0 50 50)}放置一个矩形一样。一队剩余笔记本电脑，每台渲染同一分布式3D场景的不同摄像机角度。
272
+
273
+
与合奏的汇聚（\S\ref{sec:ensembles}）是3D变得真正新颖的地方。跨网络剩余机器的同步3D场景——每块屏幕是通向共享虚拟空间的窗口，每位玩家的输入影响所有参与者的场景——是一种游戏引擎和创意编程工具都未在\$50/席位的价位上探索过的形式。网络已经被验证（\texttt{1v1.mjs}）。硬件已经可用（\S\ref{sec:surplus}）。缺少的是对分布式空间乐器应该是什么感觉的艺术愿景，而这正是@jeffrey花了94个项目学习如何回答的那类问题。
274
+
275
+
% ============ 5. 学术转向 ============
276
+
277
+
\section{学术转向}
278
+
\label{sec:scholarly}
279
+
280
+
在2026年3月3日至20日之间，@jeffrey以四种语言产出了19篇研究论文。这对于一个独立开发者来说不是正常的行为。它标志着一个向学术合法性的刻意转向——一个试图围绕项目建立RESEARCH-DIRECTION.md文件所称的"研究护城河"的尝试。
281
+
282
+
\subsection{论文工厂（2026--2027）}
283
+
284
+
论文基础设施已经是工业化的：一个带有AC字体的自定义\LaTeX{}模板、通过服务器（"烤箱"）自动化PDF构建、一种用于单页打印的卡片格式，以及一条翻译管线，为每篇论文生产丹麦语、西班牙语和中文版本。40多篇阅读材料的图书馆提供引用基础。该管线被设计用于生产，而非原型开发。
285
+
286
+
近期轨迹是投稿：ACM C\&C Demos（4月16日）、ICCC短论文（4月24日）、JOSS软件论文（滚动征稿）。如果其中任何一个被接受，该项目将获得大多数创意编程工具从未达到的学术立足点。Processing~\citep{reas2007processing}和Scratch~\citep{resnick2009scratch}花了数年建立其学术合法性；@jeffrey试图通过产出数量和同时瞄准多个场所来压缩这一时间线。
287
+
288
+
\subsection{艺术家-学者身份（2028--2031）}
289
+
290
+
CalArts论文认为，艺术学校是一个操作系统——像CalArts这样的机构所特有的邻近性、批评和学科交叉污染的结构可以被移植到软件中。如果@jeffrey继续以这种速度发表，论文本身就成为一个作品集：不是一个软件项目的文档，而是关于创意计算是什么以及它为谁服务的持续论证。
291
+
292
+
可能的5年结果是两个场景之一：
293
+
294
+
\begin{enumerate}
295
+
\item \textbf{护城河保住了}：6--10篇论文在同行评审场所发表，@jeffrey被邀请在会议上发言，\ac{}与Processing、Scratch和Sonic Pi~\citep{aaron2016sonic}一起进入经典序列，成为公认的创意计算环境。论文创造了一个反馈循环：学术关注带来用户，用户创建pieces，pieces产生新论文。
296
+
\item \textbf{护城河没保住}：投稿被拒绝，单一作者模式引起审稿人的疑虑，论文基础设施进入休眠。代码存活；学术身份没有。这是艺术家-程序员更常见的结果。
297
+
\end{enumerate}
298
+
299
+
诚实的预测介于两者之间：几篇发表物被接受，足以在小众场所（NIME、xCoAx、ICLC）建立信誉，但没有合作者和用户研究，主流HCI和PL会议仍然遥不可及。
300
+
301
+
% ============ 5. KIDLISP的自有生命 ============
302
+
303
+
\section{KidLisp的自有生命}
304
+
\label{sec:kidlisp}
305
+
306
+
KidLisp是一种具有118个函数的Lisp方言，用于生成艺术~\citep{scudder2026kidlisp}。它是沙箱化的（无文件I/O，无网络），在浏览器中运行，已经积累了16,779个存储的程序和一个通过Tezos的区块链铸造集成。该语言小到可以写在一张索引卡上。
307
+
308
+
\subsection{语言社区（2026--2028）}
309
+
310
+
Tezos的"keeps"系统——KidLisp程序以2.5 XTZ铸造为链上艺术品——为编写KidLisp创造了经济激励。keeps合约（v11）已上线，铸造UI存在于keeps.kidlisp.com，5个代币已被铸造和迁移。如果生成艺术市场保持活跃，这条线索可以自我维持。
311
+
312
+
更有趣的可能性是教育方面的。KidLisp的限制——无状态变异、除绘图外无副作用、118个函数、在浏览器中运行——使其成为教学环境的候选者。一个围绕卡片格式（学生可以拿在手中的单页程序）构建的KidLisp课程，与Papert的建构主义~\citep{papert1980mindstorms}和项目现有的基础设施相一致。
313
+
314
+
\subsection{语言演进（2028--2031）}
315
+
316
+
KidLisp将面临增长的压力。用户会想要状态、动画、交互性、声音。设计问题是该语言是否吸收这些功能（成为通用创作语言）还是保持刻意的极简（一种用于静态生成艺术的"俳句语言"，JavaScript处理其余一切）。
317
+
318
+
项目的历史暗示是后者。@jeffrey的设计本能，在94个前身项目中可见，倾向于锐利的限制而非功能累积。piece模型本身——单文件、生命周期函数、即时模式图形~\citep{scudder2026pieces}——是限制优先的设计。KidLisp可能会保持小规模。有趣的增长将在于人们用它做什么，而不是语言添加什么。
319
+
320
+
% ============ 6. 可持续性 ============
321
+
322
+
\section{可持续性问题}
323
+
\label{sec:sustainability}
324
+
325
+
上述每条线索都取决于一个人继续工作。\ac{}没有风险投资、没有机构支持、除@jeffrey外没有雇员。AestheticAnts维护系统自动处理日常任务，但架构决策、论文写作、硬件测试和社区培育需要人类的关注。
326
+
327
+
\subsection{资金格局（2026--2028）}
328
+
329
+
该项目已确定资金来源：Creative Capital（\$50,000项目资助）、Prix Ars Electronica（\texteuro10,000）、Gary Marsden Travel Awards和GitHub Sponsors。论文工厂在一定程度上是一种资助申请策略：一个拥有19篇论文、会议演示和文档化用户基础的项目，比只有代码的项目更有竞争力。
330
+
331
+
Tezos keeps提供了一小笔收入。印刷品（截至2026年3月已订购20份）提供了另一笔。两者都不足以维持全职开发。
332
+
333
+
诚实的预测：到2028年，项目要么获得资助或机构附属关系（驻留、教职、研究奖学金），要么放缓为维护模式开发。这不是失败的场景——许多重要的创意工具由其创作者兼职维护数十年。但雄心勃勃的线索（行星合奏、剩余硬件车队、学术护城河）需要全职关注。
334
+
335
+
\subsection{单一作者风险（2028--2031）}
336
+
337
+
Illich的"用于共生性的工具"~\citep{illich1973tools}认为，好的工具应该无需专业知识即可操作。\ac{}对其用户抱有这样的期望，但项目本身在Illich的意义上并非共生的：它需要@jeffrey的专业知识来维护。巴士因子为一。
338
+
339
+
缓解措施已部分到位：代码库是开源的，架构在19篇论文中有文档记录，piece API被设计为单文件的简洁性，AestheticAnts系统自主处理日常维护。但"代码是开放的"和"其他人可以领导该项目"之间的差距是巨大的。
340
+
341
+
可能的5年轨迹：@jeffrey继续担任唯一架构师。一个小型piece作者社区贡献内容（265个已发布pieces，且在增长）。一两个贡献者为特定功能提交pull request。该项目不会达到Processing或p5.js的"千人贡献者"模式，但也不需要——它的价值主张不是广度而是深度：一个单一愿景，严格维护，将创意计算带到委员会设计的工具无法到达的地方。
342
+
343
+
% ============ 7. 汇聚 ============
344
+
345
+
\section{汇聚}
346
+
\label{sec:convergence}
347
+
348
+
上述七条线索不是平行轨道。它们汇聚。
349
+
350
+
94个项目的历史（\S\ref{sec:history}）确立了使其他线索可读的轨迹。剩余硬件（\S\ref{sec:surplus}）为行星合奏（\S\ref{sec:ensembles}）提供物质基础。3D基础设施（\S\ref{sec:3d}）将合奏模型扩展到空间表演。论文（\S\ref{sec:scholarly}）记录和合法化这一切。KidLisp（\S\ref{sec:kidlisp}）为通过这些渠道到达的新用户提供安全的入口。可持续性（\S\ref{sec:sustainability}）决定了汇聚是否会发生——而\S\ref{sec:giveup}考察了如果不发生会怎样。
351
+
352
+
最可能的5年场景是：到2031年，\ac{}是一个被认可但小众的创意计算环境，拥有：
353
+
354
+
\begin{itemize}
355
+
\item \textbf{5,000--10,000名注册用户}，从2,812增长，由notepat的病毒式传播、会议演示和课堂部署驱动
356
+
\item \textbf{一个裸机操作系统}部署在5--15个地点（学校、社区中心、艺术驻留、工作坊）的100--500台剩余机器上
357
+
\item \textbf{3--5篇已发表论文}在同行评审场所，建立最小的学术足迹
358
+
\item \textbf{50,000+个KidLisp程序}，有一个小而活跃的生成艺术社区在Tezos上铸造keeps
359
+
\item \textbf{合奏表演}在2--3个节日或会议上，使用剩余笔记本电脑车队作为分布式乐器
360
+
\item \textbf{一个单一维护者}仍在编写大部分代码，AI辅助维护处理越来越多的日常工作
361
+
\end{itemize}
362
+
363
+
这既不是最雄心勃勃的结果，也不是最保守的。它是与一个做出了关于其所关心之事的具体、刻意选择——深度优于广度、乐器优于IDE、维护优于颠覆——并且拥有按独立开发者可持续的节奏跟进这些选择的基础设施的项目相一致的结果。
364
+
365
+
% ============ 8. 什么可能改变一切 ============
366
+
367
+
\section{什么可能改变一切}
368
+
\label{sec:wildcards}
369
+
370
+
基于动量的预测之所以可靠，恰恰因为它们忽略了不连续性。四张外卡可能完全改变轨迹：
371
+
372
+
\subsection{一个机构之家}
373
+
374
+
如果@jeffrey在艺术学校或研究型大学获得教职，\ac{}将获得它目前缺乏的东西：学生。一个由15--30名学生组成的群体，在一个学期中使用\ac{}作为主要创意计算环境，将产出比十年独立开发更多的pieces、更多的错误报告、更多的用例和更多的学术成果。CalArts论文的论点——艺术学校是一个操作系统——反过来也成立：操作系统可以成为一所学校。
375
+
376
+
\subsection{一个病毒式时刻}
377
+
378
+
\np{}曾被发布到Hacker News并受到关注。第二个病毒式时刻——一个教室里满是剩余笔记本电脑一起演奏音乐的TikTok、一个关于\$50创意乐器的推文串、一个被录制和分享的会议演示——可能在一周内带来数千名用户。基础设施（可通过URL访问的pieces、即时注册、社交功能）被设计来吸收这些。@jeffrey是否\emph{想要}吸收它是另一个问题。项目的反平台立场~\citep{fisher2009capitalist}暗示了对为增长而增长的矛盾态度。
379
+
380
+
\subsection{AI作为协作者}
381
+
382
+
AestheticAnts系统已经使用AI进行日常维护。代理记忆系统记录交互并在对话之间保持连续性。如果AI能力继续进步，该系统的未来版本可能不仅仅是维护：它可以编写pieces、生成KidLisp程序、编排合奏总谱和起草论文。如果"独立作者"由一个理解项目历史、哲学和代码库的AI协作者增强，那么单一作者风险（\S\ref{sec:sustainability}）就会减少。
383
+
384
+
这不像其他场景那样是推测性的。它已经在发生。问题是程度问题：到2031年，AI处理10\%的创作工作，还是50\%？答案取决于@jeffrey关于委托什么和坚持自己做什么的选择。项目对个人声音的强调，对那些承载作者温度的"PSYCHO"论文的强调，表明最重要的工作将保持人类的。围绕它的基础设施可能不会。
385
+
386
+
\subsection{如果他停下来会怎样}
387
+
\label{sec:giveup}
388
+
389
+
上述预测假设持续的努力。但94个项目的历史（\S\ref{sec:history}）包含一个必须命名的模式：@jeffrey以前放弃过东西。No Paint有五次化身。每一次都被放弃了，不是因为想法失败了，而是因为实现固化了——因为工具\emph{是什么}和它\emph{应该是什么}之间的差距变得无法忍受。重启不是承诺的失败。它们是承诺的表达。
390
+
391
+
\ac{}的风险不是@jeffrey失去兴趣。十五年围绕同样问题的运转排除了随意放弃。风险是\emph{结构性疲惫}：运营负担的累积——服务器账单、用户支持、硬件测试、论文投稿、资助申请、依赖更新——直到维护负担挤掉了使项目值得维护的创作工作。Ukeles~\citep{ukeles1969manifesto}认为维护是艺术，但即使Ukeles也承认，没有认可的维护会变成隐形劳动。
392
+
393
+
三种终止场景值得考虑：
394
+
395
+
\begin{enumerate}
396
+
\item \textbf{悄然消退}：开发减少到零星的提交，服务器保持运行但社区逐渐流失，\ac{}加入那长长的雄心勃勃的个人工具名单——它们作为档案而非活的系统而存在。这是单一作者创意计算项目最常见的结果。它并不戏剧性。它是默认。
397
+
398
+
\item \textbf{刻意停止}：@jeffrey在某个自然边界宣布项目完成——也许是当OS在一打笔记本型号上可靠启动时，或当论文数量达到一个整数时，或当第100个piece由他以外的人发布时。他回到画布上绘画（2026年5月的Venice Family Clinic展览表明这条线索已经活跃）。代码保持开放。有人可能会分叉它。最可能的是，没有人会。
399
+
400
+
\item \textbf{第95次重启}：@jeffrey离开\ac{}去构建它的继任者。这是历史最强烈预测的模式。No Paint变成了\ac{}。\ac{}可能变成别的东西——吸收OS的教训、piece模型、合奏网络和3D光栅化器，但甩掉累积的基础设施负担。新项目从零开始，在一个文件中，循环重新开始。从外部看，这像是失败。从94个项目谱系的内部看，它像是设计运作完全如预期。
401
+
\end{enumerate}
402
+
403
+
诚实的评估：场景3在5年内不太可能，因为\ac{}已经以No Paint从未达到的方式达到了逃逸速度——注册用户基础、裸机操作系统、区块链集成、19篇论文、一种拥有16,000多个程序的语言。沉没成本太高，无法进行干净的重启。但如果可持续性问题（\S\ref{sec:sustainability}）得不到回答，场景1完全可能。一个如此雄心勃勃的项目，由一个没有稳定资金的人维护，总是距离悄然消退只有一个糟糕的年份。
404
+
405
+
缓解方法与迄今为止维持项目的方法相同：使工作本身足够有回报，使运营负担可以忍受。论文、表演、从零编写的3D光栅化器、7秒的裸机启动——这些不是路线图上的功能。它们是创作实践。如果实践不再有趣，项目就会停止。如果它保持有趣，项目就能经受住除了灯灭之外的一切。
406
+
407
+
% ============ 10. 结论 ============
408
+
409
+
\section{结论}
410
+
411
+
Aesthetic Computer是一个知道自己是什么的项目。它没有在寻找产品市场契合度，没有向企业转型，没有为增长指标优化。它是一个个人创意计算工具，由一个在94个前身项目中制作了十多年版本的人公开构建。
412
+
413
+
未来五年将由内部力量（@jeffrey能维持的节奏、他能获得的资金）和外部力量（2.4亿台剩余PC、生成艺术经济、学术会议周期）共同塑造。项目的基础设施——裸机操作系统、论文工厂、piece模型、社交网络、区块链铸造——被建来吸收这些力量。它是否会，取决于耐力、运气，以及世界是否愿意关注不属于某个平台的创意计算工具。
414
+
415
+
Nelson在1974年写道，"你可以而且必须现在就理解计算机"~\citep{nelson1974computerlib}。Illich在1973年写道，工具应该扩展个人自主权，而不是要求机构中介~\citep{illich1973tools}。Ukeles在1969年写道，维护是艺术~\citep{ukeles1969manifesto}。\ac{}是这些的综合：一个个人的、共生的、作为创作实践来维护的工具。赌注是，这种综合，应用于剩余硬件并随时间持续，能创造出持久之物。
416
+
417
+
它是否会是唯一有趣的问题。本文不提供答案，只提供对场中力量的解读。代码将决定。
418
+
419
+
\vspace{0.5em}
420
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
421
+
422
+
\vspace{0.5em}\noindent\textit{翻译自英文。原始版本可在 \url{https://papers.aesthetic.computer} 获取}
423
+
424
+
% ============ REFERENCES ============
425
+
426
+
\bibliographystyle{plainnat}
427
+
\bibliography{references}
428
+
429
+
\end{document}
+577
papers/arxiv-identity/identity-da.tex
+577
papers/arxiv-identity/identity-da.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
11
+
\setmainfont{Latin Modern Roman}
12
+
\setsansfont{Latin Modern Sans}
13
+
14
+
% Custom AC fonts
15
+
\newfontfamily\acbold{ywft-processing-bold}[
16
+
Path=../../system/public/type/webfonts/,
17
+
Extension=.ttf
18
+
]
19
+
\newfontfamily\aclight{ywft-processing-light}[
20
+
Path=../../system/public/type/webfonts/,
21
+
Extension=.ttf
22
+
]
23
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
24
+
25
+
% === PACKAGES ===
26
+
\usepackage{xcolor}
27
+
\usepackage{titlesec}
28
+
\usepackage{enumitem}
29
+
\usepackage{booktabs}
30
+
\usepackage{tabularx}
31
+
\usepackage{multicol}
32
+
\usepackage{fancyhdr}
33
+
\usepackage{hyperref}
34
+
\usepackage{graphicx}
35
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
36
+
\usepackage{ragged2e}
37
+
\usepackage{microtype}
38
+
\usepackage{listings}
39
+
\usepackage{natbib}
40
+
\usepackage[colorspec=0.92]{draftwatermark}
41
+
42
+
% === COLORS (AC palette) ===
43
+
\definecolor{acpink}{RGB}{180,72,135}
44
+
\definecolor{acpurple}{RGB}{120,80,180}
45
+
\definecolor{acdark}{RGB}{64,56,74}
46
+
\definecolor{acgray}{RGB}{119,119,119}
47
+
\definecolor{draftcolor}{RGB}{180,72,135}
48
+
49
+
% === DRAFT WATERMARK ===
50
+
\DraftwatermarkOptions{
51
+
text=WORKING DRAFT,
52
+
fontsize=3cm,
53
+
color=draftcolor!18,
54
+
angle=45,
55
+
pos={0.5\paperwidth, 0.5\paperheight}
56
+
}
57
+
58
+
% === JS SYNTAX COLORS ===
59
+
\definecolor{jskw}{RGB}{119,51,170}
60
+
\definecolor{jsfn}{RGB}{0,136,170}
61
+
\definecolor{jsstr}{RGB}{170,120,0}
62
+
\definecolor{jsnum}{RGB}{204,0,102}
63
+
\definecolor{jscmt}{RGB}{102,102,102}
64
+
65
+
% === HYPERREF ===
66
+
\hypersetup{
67
+
colorlinks=true,
68
+
linkcolor=acpurple,
69
+
urlcolor=acpurple,
70
+
citecolor=acpurple,
71
+
pdfauthor={@jeffrey},
72
+
pdftitle={Handle-identitet på AT Protocol: Fra Auth0 til decentraliseret login},
73
+
}
74
+
75
+
% === SECTION FORMATTING ===
76
+
\titleformat{\section}
77
+
{\normalfont\bfseries\normalsize\uppercase}
78
+
{\thesection.}
79
+
{0.5em}
80
+
{}
81
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
82
+
83
+
\titleformat{\subsection}
84
+
{\normalfont\bfseries\small}
85
+
{\thesubsection}
86
+
{0.5em}
87
+
{}
88
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
89
+
90
+
% === HEADER/FOOTER ===
91
+
\pagestyle{fancy}
92
+
\fancyhf{}
93
+
\renewcommand{\headrulewidth}{0pt}
94
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{Arbejdsudkast --- ikke til citation}}
95
+
\fancyfoot[C]{\footnotesize\thepage}
96
+
97
+
% === CUSTOM COMMANDS ===
98
+
\newcommand{\acdot}{{\color{acpink}.}}
99
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
100
+
\newcommand{\atproto}{\textsc{AT Protocol}}
101
+
102
+
% === LISTINGS ===
103
+
\lstdefinelanguage{acjs}{
104
+
morekeywords=[1]{function,export,const,let,var,return,if,else,new,async,await,import,from},
105
+
morekeywords=[2]{wipe,ink,line,box,circle,write,screen,params,colon,jump,send,store,net,sound,speaker,system},
106
+
sensitive=true,
107
+
morecomment=[l]{//},
108
+
morestring=[b]",
109
+
morestring=[b]',
110
+
morestring=[b]`,
111
+
escapeinside={|}{|},
112
+
}
113
+
114
+
\lstdefinestyle{acjsstyle}{
115
+
language=acjs,
116
+
keywordstyle=[1]\color{jskw}\bfseries,
117
+
keywordstyle=[2]\color{jsfn}\bfseries,
118
+
commentstyle=\color{jscmt}\itshape,
119
+
stringstyle=\color{jsstr},
120
+
}
121
+
122
+
\lstset{
123
+
basicstyle=\ttfamily\small,
124
+
breaklines=true,
125
+
frame=single,
126
+
rulecolor=\color{acgray!30},
127
+
backgroundcolor=\color{acgray!5},
128
+
xleftmargin=0.5em,
129
+
xrightmargin=0.5em,
130
+
aboveskip=0.5em,
131
+
belowskip=0.5em,
132
+
}
133
+
134
+
% === LIST SETTINGS ===
135
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
136
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
137
+
138
+
% === COLUMN SEPARATION ===
139
+
\setlength{\columnsep}{1.8em}
140
+
141
+
% === PARAGRAPH SETTINGS ===
142
+
\setlength{\parindent}{1em}
143
+
\setlength{\parskip}{0.3em}
144
+
145
+
% Hyphenation for narrow two-column layout
146
+
\tolerance=800
147
+
\emergencystretch=1em
148
+
\hyphenpenalty=50
149
+
150
+
\begin{document}
151
+
152
+
% ============ TITLE BLOCK ============
153
+
154
+
\twocolumn[{%
155
+
\begin{center}
156
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
157
+
{\acbold\fontsize{24pt}{28pt}\selectfont\color{acdark} Handle-identitet på AT Protocol}\par
158
+
\vspace{0.2em}
159
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} Fra Auth0 til decentraliseret login på Aesthetic Computer}\par
160
+
\vspace{0.3em}
161
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} ATProto OAuth, handle-verifikation og portabel kreativ identitet}\par
162
+
\vspace{0.6em}
163
+
{\normalsize @jeffrey}\par
164
+
{\small\color{acgray} Aesthetic.Computer}\par
165
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
166
+
\vspace{0.3em}
167
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
168
+
\vspace{0.6em}
169
+
\rule{\textwidth}{1.5pt}
170
+
\vspace{0.5em}
171
+
\end{center}
172
+
173
+
\begin{center}
174
+
{\small\color{acpink}\textbf{[ arbejdsudkast --- ikke til citation ]}}
175
+
\end{center}
176
+
\vspace{0.3em}
177
+
178
+
\begin{quote}
179
+
\small\noindent\textbf{Abstrakt.}
180
+
Aesthetic Computer autentificerer i øjeblikket brugere gennem Auth0 og opretholder en parallel identitet på en selvhostet AT Protocol Personal Data Server (PDS) på \texttt{at.aesthetic.computer}. Hver verificeret bruger modtager en DID og et PDS-handle, men autentificering foregår gennem en centraliseret OAuth-udbyder. Vi foreslår at sammenlægge denne duale identitetsarkitektur ved at adoptere AT Protocol OAuth~\citep{atproto2024oauth} som primær login-metode, hvilket gør det muligt for alle med en Bluesky- eller ATProto-identitet at autentificere sig direkte og få det tilsvarende handle på Aesthetic Computer. Denne artikel gennemgår \atproto{}-identitetsstakken---DID'er, handle-verifikation, OAuth 2.1 med DPoP og PAR---undersøger, hvordan pckt.blog og andre ATProto-native applikationer implementerer decentraliseret login~\citep{pcktblog2025}, kortlægger den nuværende AC-autentificeringsarkitektur og foreslår en faseinddelt migration fra Auth0-afhængighed til \atproto{}-først-identitet. Det centrale argument: på en platform, der allerede kører sin egen PDS og udsteder sine egne DID'er, er den centraliserede identitetsudbyder det vestigiale organ. At fjerne den forenkler stakken, eliminerer en betalt afhængighed og gør AC til en førsteklasses borger i det fødererede sociale web.
181
+
\end{quote}
182
+
\vspace{0.5em}
183
+
}]
184
+
185
+
% ============ 1. INTRODUKTION ============
186
+
187
+
\section{Introduktion}
188
+
189
+
Identitet på webben er et udlejerproblem. Du ejer ikke dit handle på Twitter, dit brugernavn på Instagram eller dit login på nogen platform, der kan slette din konto. AT Protocol~\citep{atproto2024spec}---den decentraliserede sociale netværksprotokol bag Bluesky---foreslår en anden ordning: din identitet er et kryptografisk nøglepar, dit handle er et domænenavn, du kontrollerer, og dine data ligger på en Personal Data Server, som du kan flytte mellem udbydere.
190
+
191
+
Aesthetic Computer har opereret med et hybrid identitetssystem siden 2024. Auth0~\citep{auth0spa} håndterer autentificering: OAuth 2.0 med PKCE, refresh tokens og en administreret brugerdatabase. Separat udsteder en selvhostet PDS på \texttt{at.aesthetic.computer} ATProto-identiteter for hver verificeret bruger. Resultatet er et fordoblet system: to identiteter per bruger, to credential-lagre, to handle-synkroniseringsveje og et betalt Auth0-abonnement, der bygger bro over kløften.
192
+
193
+
Denne artikel spørger: hvad nu hvis PDS'en \emph{er} identitetsudbyderen?
194
+
195
+
Svaret er ikke hypotetisk. pckt.blog~\citep{pcktblog2025}, en blogplatform bygget på \atproto{}, autentificerer brugere udelukkende gennem \atproto{} OAuth. Brugere logger ind med deres Bluesky-handle, deres selvhostede PDS eller enhver kompatibel identitetsudbyder. Ingen Auth0, ingen Firebase, ingen centraliseret brugerdatabase. Indholdet synkroniseres til brugerens egen PDS ved hjælp af delte lexicons fra Standard.site~\citep{standardsite2025}.
196
+
197
+
Vi undersøger, hvordan denne model gælder for Aesthetic Computer---en kreativ computing-platform med 600+ interaktive pieces, multiplayer-sessioner, et KidLisp-programmeringssprog og et native bare-metal OS~\citep{scudder2026os}---og foreslår en faseinddelt migration, der bevarer bagudkompatibilitet, mens den bevæger sig mod decentraliseret identitet.
198
+
199
+
% ============ 2. DEN NUVÆRENDE AC-IDENTITETSARKITEKTUR ============
200
+
201
+
\section{Nuværende arkitektur}
202
+
\label{sec:current}
203
+
204
+
\subsection{Auth0 som identitetsudbyder}
205
+
206
+
Autentificering foregår gennem Auth0's SPA SDK. Ved sideindlæsning tjekker \texttt{boot.mjs} localStorage for cached Auth0-tilstand. Hvis en session eksisterer (eller et OAuth-callback detekteres), initialiserer den Auth0-klienten med PKCE og refresh tokens, udveksler autorisationskoder for access tokens og henter brugerprofilen. Auth0's \texttt{sub}-felt (f.eks. \texttt{auth0|abc123} eller \texttt{google-oauth2|xyz}) fungerer som den interne brugeridentifikator.
207
+
208
+
\begin{lstlisting}[style=acjsstyle]
209
+
// boot.mjs: current Auth0 flow
210
+
const auth0 = await createAuth0Client({
211
+
domain: |\textcolor{jsstr}{"hi.aesthetic.computer"}|,
212
+
clientId: |\textcolor{jsstr}{"LVdZaM..."}|,
213
+
cacheLocation: |\textcolor{jsstr}{"localstorage"}|,
214
+
useRefreshTokens: true,
215
+
});
216
+
const user = await auth0.getUser();
217
+
// { sub, email, email_verified, ... }
218
+
\end{lstlisting}
219
+
220
+
\subsection{Handle-systemet}
221
+
222
+
Handles gemmes i en MongoDB \texttt{@handles}-collection, der mapper Auth0 \texttt{sub} til en streng på 1--16 alfanumeriske tegn (med \texttt{.} og \texttt{\_} tilladt). Validering håndhæver ingen indledende/afsluttende tegnsætning, case-insensitiv unikhed og profanitetsfiltrering. Handles er den primære brugervendte identitet: URL-adresserbare (\texttt{@handle/piece-name}), synlige i chat og oplæst af AC Native OS.
223
+
224
+
\subsection{ATProto-skyggeidentitet}
225
+
226
+
Ved første e-mail-verifikation udløser en Auth0-webhook \texttt{createAtprotoAccount()}, som:
227
+
228
+
\begin{enumerate}
229
+
\item Genererer en adgangskode på 32 tegn
230
+
\item Opretter en invitationskode på PDS'en
231
+
\item Opretter en konto på \texttt{handle.at.aesthetic.computer}
232
+
\item Gemmer DID, handle og krypteret adgangskode i MongoDB (\texttt{users.atproto})
233
+
\end{enumerate}
234
+
235
+
Når en bruger ændrer sit AC-handle, synkroniserer \texttt{updateAtprotoHandle()} ændringen til PDS'en. Indhold (malerier, stemninger, KidLisp-snippets, tapes, nyheder) spejles til PDS'en via seks brugerdefinerede lexicons (\texttt{computer.aesthetic.*}). ATProto-identiteten er reel og funktionel---men brugeren autentificerer sig aldrig gennem den. Det er en skyggeidentitet: til stede, synkroniseret, men ikke suveræn.
236
+
237
+
\subsection{Duplikeringsproblemet}
238
+
239
+
Denne arkitektur medfører:
240
+
241
+
\begin{itemize}
242
+
\item To credential-lagre (Auth0 + PDS)
243
+
\item To handle-navnerum (AC-handles + PDS-handles)
244
+
\item To synkroniseringsveje (handle-ændringer propagerer Auth0 $\to$ MongoDB $\to$ PDS)
245
+
\item En betalt afhængighed (Auth0-abonnement)
246
+
\item Ingen interoperabilitet (en Bluesky-bruger kan ikke logge ind på AC med sin eksisterende identitet)
247
+
\end{itemize}
248
+
249
+
PDS'en ved allerede, hvem hver bruger er. Den gemmer allerede deres DID, deres handle, deres indhold. Auth0-laget tilføjer omkostninger og kompleksitet uden at tilføje kapabilitet, som PDS'en ikke kan levere.
250
+
251
+
% ============ 3. AT PROTOCOL-IDENTITETSSTAKKEN ============
252
+
253
+
\section{AT Protocol-identitetsstakken}
254
+
\label{sec:atproto}
255
+
256
+
At forstå migrationen kræver forståelse af de tre lag i \atproto{}-identitet: DID'er, handles og OAuth.
257
+
258
+
\subsection{Decentraliserede identifikatorer (DID'er)}
259
+
260
+
En DID~\citep{w3cdid2022, atproto2024did} er en persistent, kryptografisk verificerbar identifikator. \atproto{} bruger primært \texttt{did:plc}, en metode designet til stærk konsistens, høj tilgængelighed og nøglerotation uden tab af identitet. Hver DID opløses til et dokument, der indeholder:
261
+
262
+
\begin{itemize}
263
+
\item En \textbf{signeringsnøgle} (P-256 eller K-256)~\citep{atproto2024crypto} til autentificering af repository-opdateringer
264
+
\item \textbf{Rotationsnøgler} til kontogendannelse
265
+
\item Et \textbf{PDS-endpoint} URL
266
+
\item Brugerens aktuelle \textbf{handle}
267
+
\end{itemize}
268
+
269
+
DID'en er den stabile identitet. Handles ændrer sig; nøgler roteres; PDS-udbydere kommer og går. DID'en forbliver. AC udsteder allerede DID'er for hver bruger gennem sin PDS. Infrastrukturen eksisterer.
270
+
271
+
\subsection{Handle-verifikation}
272
+
273
+
Et \atproto{}-handle~\citep{atproto2024handle} er et domænenavn, der opløses bidirektionelt til en DID. Verifikation bruger to metoder:
274
+
275
+
\textbf{DNS TXT}: Placer en record på \texttt{\_atproto.example.com}:
276
+
\begin{lstlisting}
277
+
_atproto.example.com TXT "did=did:plc:abc..."
278
+
\end{lstlisting}
279
+
280
+
\textbf{HTTPS Well-Known}: Server DID'en på:
281
+
\begin{lstlisting}
282
+
GET /.well-known/atproto-did
283
+
Response: did:plc:abc...
284
+
\end{lstlisting}
285
+
286
+
Begge metoder kræver, at handlet opløses til DID'en \emph{og} at DID-dokumentet hævder handlet tilbage. Denne bidirektionelle verifikation betyder: hvis du kontrollerer domænet, kontrollerer du handlet. Ingen central myndighed tildeler handles; DNS er myndigheden.
287
+
288
+
For AC betyder dette, at \texttt{jeffrey.at.aesthetic.computer} er et reelt, verificerbart ATProto-handle, fordi AC kontrollerer både DNS'en og PDS'en. Men det betyder også, at en bruger, der allerede ejer \texttt{alice.bsky.social} eller \texttt{alice.dev}, har en kryptografisk verificeret identitet, som AC kan stole på uden en adgangskode.
289
+
290
+
\subsection{ATProto OAuth}
291
+
292
+
\atproto{} OAuth-specifikationen~\citep{atproto2024oauth} udvider OAuth 2.1 med tre obligatoriske sikkerhedsmekanismer:
293
+
294
+
\textbf{PKCE} (Proof Key for Code Exchange)~\citep{rfc7636pkce}: Forhindrer aflytning af autorisationskoder. Klienten genererer en tilfældig verifier, sender dens hash med autorisationsforespørgslen og beviser besiddelse af den originale verifier under token-udveksling.
295
+
296
+
\textbf{PAR} (Pushed Authorization Requests)~\citep{rfc9126par}: Klienten indsender autorisationsparametre via POST til autorisationsserveren \emph{inden} brugeren omdirigeres. Dette forhindrer parameter-manipulation i omdirigerings-URL'en.
297
+
298
+
\textbf{DPoP} (Demonstrating Proof of Possession)~\citep{rfc9449dpop}: Hver forespørgsel inkluderer en signeret JWT, der beviser, at klienten besidder den private nøgle associeret med tokenet. Selv hvis et access token lækkes, kan det ikke bruges af en anden klient.
299
+
300
+
\subsubsection{Klientidentifikation}
301
+
302
+
I modsætning til traditionel OAuth kræver \atproto{} ikke forhåndsregistrering hos hver autorisationsserver. I stedet publicerer klienter metadata på en offentlig HTTPS-URL:
303
+
304
+
\begin{lstlisting}[style=acjsstyle]
305
+
// aesthetic.computer/oauth/client-metadata.json
306
+
{
307
+
|\textcolor{jsstr}{"client\_id"}|: |\textcolor{jsstr}{"https://aesthetic.computer/..."}|,
308
+
|\textcolor{jsstr}{"client\_name"}|: |\textcolor{jsstr}{"Aesthetic Computer"}|,
309
+
|\textcolor{jsstr}{"redirect\_uris"}|: [|\textcolor{jsstr}{"https://..."}|],
310
+
|\textcolor{jsstr}{"grant\_types"}|: [|\textcolor{jsstr}{"authorization\_code"}|],
311
+
|\textcolor{jsstr}{"dpop\_bound\_access\_tokens"}|: true
312
+
}
313
+
\end{lstlisting}
314
+
315
+
Enhver PDS kan opdage og verificere klienten ved at hente denne URL. Ingen forhåndsdelte hemmeligheder, ingen app store-registrering, ingen API-nøgle-administration.
316
+
317
+
\subsubsection{Flowet}
318
+
319
+
\begin{enumerate}
320
+
\item Brugeren indtaster sit handle (f.eks. \texttt{alice.bsky.social})
321
+
\item Klienten opløser handle $\to$ DID $\to$ PDS-endpoint $\to$ autorisationsserver
322
+
\item Klienten pusher autorisationsparametre via PAR
323
+
\item Brugeren omdirigeres til sin PDS's autorisations-UI
324
+
\item Brugeren godkender; PDS'en omdirigerer tilbage med autorisationskode
325
+
\item Klienten udveksler kode for DPoP-bundet access token
326
+
\item Klienten verificerer, at den returnerede DID matcher den forventede identitet
327
+
\end{enumerate}
328
+
329
+
Den afgørende forskel fra Auth0: brugeren autentificerer sig med \emph{sin egen server}. AC ser aldrig en adgangskode. PDS'en---hvad enten det er Bluesky's, AC's egen eller en selvhostet instans---er identitetsmyndigheden.
330
+
331
+
% ============ 4. SÅDAN GØR PCKT.BLOG ============
332
+
333
+
\section{Casestudie: pckt.blog}
334
+
\label{sec:pckt}
335
+
336
+
pckt.blog~\citep{pcktblog2025} er en blogplatform, der autentificerer udelukkende gennem \atproto{} OAuth. Dens implementering demonstrerer den praktiske levedygtighed af ATProto-only-autentificering for en indholdsplatform.
337
+
338
+
\subsection{Autentificering}
339
+
340
+
Brugere logger ind ved at indtaste deres ATProto-handle. pckt.blog opløser handlet, opdager autorisationsserveren og igangsætter OAuth-flowet. Brugeren godkender på sin PDS (Bluesky, Blacksky, en selvhostet server). pckt.blog modtager et DPoP-bundet access token og brugerens DID. Ingen adgangskoder gemmes. Ingen separat brugerdatabase vedligeholdes.
341
+
342
+
\subsection{Datasuverænitet}
343
+
344
+
Indhold synkroniseres til brugerens egen PDS ved hjælp af Standard.site-lexicons~\citep{standardsite2025}:
345
+
346
+
\begin{itemize}
347
+
\item \texttt{site.standard.publication} --- blogsamlinger
348
+
\item \texttt{site.standard.document} --- individuelle artikler
349
+
\item \texttt{site.standard.graph.subscription} --- følge-relationer
350
+
\end{itemize}
351
+
352
+
Hvis pckt.blog forsvinder, forbliver brugerens indhold på deres PDS, tilgængeligt for enhver kompatibel læser. Dette er løftet fra ATProto: platformen er en visning, ikke en silo.
353
+
354
+
\subsection{Implikationer for AC}
355
+
356
+
pckt.blog beviser, at en indholdsorienteret platform kan operere udelukkende på ATProto-identitet. Parallellerne til AC er direkte:
357
+
358
+
\begin{itemize}
359
+
\item pckt.blog publicerer artikler; AC publicerer pieces, malerier og stemninger
360
+
\item pckt.blog bruger Standard.site-lexicons; AC har seks brugerdefinerede \texttt{computer.aesthetic.*}-lexicons
361
+
\item pckt.blog's brugere ejer deres indhold på deres PDS; AC spejler allerede indhold til sin PDS
362
+
\item Begge er Node.js/JavaScript-applikationer
363
+
\end{itemize}
364
+
365
+
Kløften: pckt.blog blev bygget ATProto-nativt. AC har en eksisterende Auth0-brugerbase, der skal migreres elegant.
366
+
367
+
% ============ 5. FORESLÅET MIGRATION ============
368
+
369
+
\section{Foreslået migration}
370
+
\label{sec:migration}
371
+
372
+
\subsection{Fase 1: ATProto OAuth som sekundær login}
373
+
374
+
Tilføj ``Log ind med Bluesky'' ved siden af Auth0, uden at fjerne Auth0.
375
+
376
+
\textbf{Infrastruktur:}
377
+
\begin{enumerate}
378
+
\item Publicer klientmetadata på \texttt{aesthetic.computer/oauth/client-metadata.json}
379
+
\item Tilføj \texttt{@atproto/oauth-client-node}~\citep{npmAtprotoOauth} til backend'en
380
+
\item Opret to nye Netlify-funktioner:
381
+
\begin{itemize}
382
+
\item \texttt{POST /api/atproto-auth/start} --- opløs handle, PAR, omdiriger
383
+
\item \texttt{GET /api/atproto-auth/callback} --- kodeudveksling med DPoP
384
+
\end{itemize}
385
+
\item Gem sessioner i Redis (DID, handle, DPoP-nøglepar, tokens)
386
+
\end{enumerate}
387
+
388
+
\textbf{Klientflow:} En ny ``Log ind med Bluesky''-knap i \texttt{boot.mjs} udløser ATProto OAuth-flowet. Ved succes udfyldes \texttt{window.acUSER} fra ATProto-sessionen (DID som \texttt{sub}, handle, ingen e-mail medmindre brugeren angiver en). Piece API-overfladen er identisk---pieces ser en bruger med et handle, uanset hvilken auth-sti der oprettede sessionen.
389
+
390
+
\subsection{Fase 2: Handle-brobygning}
391
+
392
+
Når en bruger logger ind via ATProto, byg bro for deres handle til AC:
393
+
394
+
\begin{enumerate}
395
+
\item Udtræk brugernavnet fra ATProto-handlet (f.eks. \texttt{alice} fra \texttt{alice.bsky.social})
396
+
\item Tjek tilgængelighed mod AC \texttt{@handles}-collection'en
397
+
\item Hvis tilgængelig og gyldig (1--16 tegn, alfanumerisk), tilbyd ét-klik-reservation
398
+
\item Hvis optaget, tjek om den eksisterende ejers e-mail matcher---tilbyd kontosammenkobling
399
+
\item Hvis optaget af en anden, bed om et alternativ
400
+
\item Gem en DID $\leftrightarrow$ AC sub-mapping i MongoDB til fremtidige logins
401
+
\end{enumerate}
402
+
403
+
Brugerdefinerede domæne-handles (f.eks. \texttt{alice.dev}) kræver, at brugeren manuelt vælger et AC-handle, da domænet i sig selv muligvis ikke mapper til en gyldig handle-streng.
404
+
405
+
\subsection{Fase 3: Identitetssammenkobling}
406
+
407
+
Eksisterende Auth0-brugere kan koble deres ATProto-identitet:
408
+
409
+
\begin{enumerate}
410
+
\item Fra kontoindstillinger, igangsæt ATProto OAuth
411
+
\item Ved succes, gem den eksterne DID sammen med Auth0 sub
412
+
\item Fremtidige logins accepterer begge auth-stier
413
+
\item Indhold kan valgfrit synkroniseres til brugerens eksterne PDS (ikke kun AC's PDS)
414
+
\end{enumerate}
415
+
416
+
Denne fase forvandler det eksisterende \texttt{users.atproto}-felt fra en skyggeidentitet til en førsteklasses identitetskobling.
417
+
418
+
\subsection{Fase 4: ATProto-primær}
419
+
420
+
Når migrationen er valideret:
421
+
422
+
\begin{enumerate}
423
+
\item Nye tilmeldinger bruger som standard ATProto OAuth (opretter konti på AC's PDS)
424
+
\item Auth0 forbliver som en legacy-sti for eksisterende brugere
425
+
\item Gradvis udfasning af Auth0 efterhånden som brugere kobler deres ATProto-identiteter
426
+
\item Fjern Auth0-afhængighed, eliminer abonnementsomkostning
427
+
\end{enumerate}
428
+
429
+
\subsection{PDS-routing}
430
+
431
+
En central arkitektonisk beslutning: hvor skal indholdet hen?
432
+
433
+
\begin{itemize}
434
+
\item \textbf{Auth0-only-brugere}: indhold synkroniseres til AC's PDS (nuværende adfærd)
435
+
\item \textbf{ATProto-brugere med ekstern PDS}: indhold synkroniseres til \emph{deres} PDS
436
+
\item \textbf{ATProto-brugere på AC's PDS}: indhold forbliver på AC's PDS
437
+
\end{itemize}
438
+
439
+
Dette betyder, at backend-synkroniseringsfunktionerne (\texttt{media-atproto.mjs}, \texttt{painting-atproto.mjs} osv.) har brug for en betinget sti: opløs brugerens PDS-endpoint fra deres DID-dokument og skriv til det endpoint i stedet for at antage AC's PDS.
440
+
441
+
% ============ 6. HANDLE-SEMANTIK ============
442
+
443
+
\section{Handle-semantik}
444
+
\label{sec:handles}
445
+
446
+
Handlet er den mest menneskesynlige del af identitetsstakken, og migrationen rejser spørgsmål om, hvad et handle \emph{betyder}.
447
+
448
+
\subsection{Nuværende handle-model}
449
+
450
+
I dag er et AC-handle:
451
+
\begin{itemize}
452
+
\item En streng på 1--16 tegn, først til mølle
453
+
\item Unikt inden for AC-navnerummet
454
+
\item Brugt til URL'er (\texttt{@alice/painting}), chat og OS-personalisering
455
+
\item Gemt i MongoDB, cached i Redis
456
+
\item Spejlet til PDS'en som \texttt{alice.at.aesthetic.computer}
457
+
\end{itemize}
458
+
459
+
\subsection{ATProto-handle-model}
460
+
461
+
Et ATProto-handle er:
462
+
\begin{itemize}
463
+
\item Et domænenavn (ethvert gyldigt DNS-navn)
464
+
\item Verificeret bidirektionelt mod en DID
465
+
\item Globalt unikt via DNS-autoritet
466
+
\item Portabelt på tværs af tjenester
467
+
\end{itemize}
468
+
469
+
\subsection{Brobygning mellem modellerne}
470
+
471
+
Forslaget: et AC-handle er et \emph{alias}, der mapper til en DID. Sandhedskilden flyttes fra MongoDB til DID-laget. Flere login-metoder (Auth0, ATProto OAuth) opløses til den samme DID, som opløses til det samme AC-handle.
472
+
473
+
For AC Native OS~\citep{scudder2026os}, hvor handlet er indskrevet i \texttt{config.json} på boot-partitionen, betyder dette, at enhedens identitet er understøttet af en kryptografisk identitet. ``Hej @alice'' på boot-skærmen betyder Alices DID, Alices signeringsnøgle, Alices portabel identitet---ikke blot en streng i en konfigurationsfil.
474
+
475
+
% ============ 7. ÅBNE SPØRGSMÅL ============
476
+
477
+
\section{Åbne spørgsmål}
478
+
\label{sec:questions}
479
+
480
+
\textbf{Handle-prioritet.} Hvis \texttt{alice} er ureserveret på AC, men \texttt{alice.bsky.social} logger ind, skal hun så automatisk få det? Først til mølle er simpelt, men tillader squatting. ATProto-verificeret prioritet er mere retfærdigt, men tilføjer kompleksitet.
481
+
482
+
\textbf{E-mail-krav.} Auth0 leverer verificeret e-mail til kontogendannelse. ATProto OAuth garanterer ikke e-mail. Skal AC kræve en e-mail til fulde kontofunktioner (køb, notifikationer)?
483
+
484
+
\textbf{Multi-tenant.} AC driver en anden tenant (\texttt{sotce}) med separat Auth0. Hvordan mapper ATProto-identiteter på tværs af tenants? DID'en er tenant-agnostisk, hvilket kan forenkle identitet på tværs af tenants.
485
+
486
+
\textbf{Sessionsserver.} Realtidsfunktioner (chat, multiplayer) autentificerer via Auth0-tokens videresendt gennem WebSocket. Sessionsserveren skal acceptere ATProto-udstedte tokens eller et samlet sessions-token.
487
+
488
+
\textbf{Enhedsparring.} AC Native OS parrer via en 6-tegns kode udvekslet gennem Auth0. ATProto-ækvivalenten: scan en QR-kode, der igangsætter et OAuth-flow på telefonen og leverer tokens til enheden.
489
+
490
+
\textbf{Admin-identitet.} Admin er i øjeblikket \texttt{handle === "jeffrey" \&\& sub === ADMIN\_SUB}. Under ATProto-først-auth er admin \texttt{did === admin\_did}---renere, kryptografisk forankret.
491
+
492
+
% ============ 8. RELATERET ARBEJDE ============
493
+
494
+
\section{Relateret arbejde}
495
+
\label{sec:related}
496
+
497
+
\textbf{Decentraliseret identitet.} W3C DID-specifikationen~\citep{w3cdid2022} udgør den formelle ramme for decentraliserede identifikatorer. AT Protocols \texttt{did:plc}-metode~\citep{atproto2024did} udvider dette med stærke konsistensgarantier og en centraliseret-men-auditerbar mappe på \texttt{plc.directory}. Dette er et pragmatisk kompromis: fuld decentralisering af identitetsopløsning forbliver et åbent problem, og \texttt{did:plc} bytter noget decentralisering for operationel pålidelighed.
498
+
499
+
\textbf{ATProto-native applikationer.} pckt.blog~\citep{pcktblog2025} demonstrerer blogging; Leaflet.pub og Offprint.app samarbejder om delte lexicons via Standard.site~\citep{standardsite2025}. Disse applikationer beviser levedygtigheden af ATProto-only-auth for indholdsplatforme.
500
+
501
+
\textbf{OAuth-sikkerhed.} DPoP~\citep{rfc9449dpop} forhindrer token-tyveri; PAR~\citep{rfc9126par} forhindrer parameter-manipulation; PKCE~\citep{rfc7636pkce} forhindrer kode-aflytning. Tilsammen repræsenterer de state of the art inden for browserbaseret OAuth-sikkerhed---betydeligt stærkere end det Auth0 SPA-flow, som AC i øjeblikket bruger.
502
+
503
+
\textbf{Konvivial identitet.} Illichs værktøjer til konvivialitet~\citep{illich1973tools} rammer spørgsmålet: udvider identitetssystemet personlig autonomi, eller kræver det afhængighed af en udbyder? Auth0 er en administreret tjeneste---bekvem men afhængig. ATProto-identitet er portabel, selv-verificerbar og udbyderuafhængig. Nelsons vision om personlig computing~\citep{nelson1974computerlib} udvides naturligt til personlig identitet: du bør eje dit navn på netværket.
504
+
505
+
% ============ 9. KONKLUSION ============
506
+
507
+
\section{Konklusion}
508
+
509
+
Aesthetic Computer kører allerede en PDS, udsteder DID'er, synkroniserer indhold til ATProto-records og publicerer brugerdefinerede lexicons. Den eneste manglende brik er at lade brugere autentificere sig gennem den infrastruktur i stedet for at gå omvejen gennem Auth0. Migrationen er ikke en omskrivning---den er fjernelsen af en workaround.
510
+
511
+
Den faseinddelte tilgang (ATProto som sekundær login $\to$ handle-brobygning $\to$ identitetssammenkobling $\to$ ATProto-primær) sikrer, at ingen eksisterende bruger forstyrres. Sluttilstanden: en kreativ computing-platform, hvor dit handle er en kryptografisk identitet, dit indhold lever på en server, du kontrollerer, og at logge ind betyder at bevise, at du ejer dine nøgler---ikke at stole på en tredjepart til at indestå for dig.
512
+
513
+
PDS'en kører allerede. DID'erne er allerede udstedt. Lexiconerne er allerede publiceret. Det er tid til at lade brugere logge ind gennem hoveddøren.
514
+
515
+
% ============ REFERENCER ============
516
+
517
+
\vspace{0.5em}
518
+
\noindent\rule{\columnwidth}{0.5pt}
519
+
520
+
\subsection*{Referencelinks}
521
+
522
+
\noindent\small
523
+
524
+
\textbf{AT Protocol-specifikationer:}
525
+
\begin{itemize}
526
+
\item \url{https://atproto.com/specs} --- Fuld protokolspecifikation
527
+
\item \url{https://atproto.com/specs/oauth} --- OAuth-specifikation
528
+
\item \url{https://atproto.com/specs/handle} --- Handle-opløsning
529
+
\item \url{https://atproto.com/specs/cryptography} --- Kryptografiske metoder
530
+
\item \url{https://web.plc.directory/spec/v0.1/did-plc} --- DID PLC-specifikation
531
+
\item \url{https://atproto.com/guides/lexicon} --- Lexicon-skema-system
532
+
\item \url{https://atproto.com/guides/oauth-patterns} --- OAuth-implementeringsmønstre
533
+
\end{itemize}
534
+
535
+
\textbf{Implementeringsguider:}
536
+
\begin{itemize}
537
+
\item \url{https://docs.bsky.app/blog/oauth-atproto} --- Byg ATProto OAuth-apps
538
+
\item \url{https://docs.bsky.app/docs/advanced-guides/resolving-identities} --- Identitetsopløsning
539
+
\item \url{https://docs.bsky.app/docs/advanced-guides/oauth-client} --- OAuth-klientguide
540
+
\end{itemize}
541
+
542
+
\textbf{NPM-pakker:}
543
+
\begin{itemize}
544
+
\item \texttt{@atproto/oauth-client-node} --- Node.js OAuth-klient
545
+
\item \texttt{@atproto/oauth-client-browser} --- Browser OAuth-klient
546
+
\item \texttt{@atproto/api} --- TypeScript XRPC-klient
547
+
\item \texttt{@atproto/identity} --- DID/handle-opløsning
548
+
\item \texttt{@atcute/oauth-browser-client} --- Let alternativ
549
+
\end{itemize}
550
+
551
+
\textbf{Referenceimplementeringer:}
552
+
\begin{itemize}
553
+
\item \url{https://github.com/pilcrowonpaper/atproto-oauth-example} --- Astro OAuth-eksempel
554
+
\item \url{https://github.com/bluesky-social/atproto} --- Officielt ATProto-monorepo
555
+
\item \url{https://standard.site/docs/introduction/} --- Standard.site delte lexicons
556
+
\end{itemize}
557
+
558
+
\textbf{Applikationer der bruger ATProto Auth:}
559
+
\begin{itemize}
560
+
\item pckt.blog --- Blogging på det åbne sociale web
561
+
\item Leaflet.pub --- Langt format-publicering
562
+
\item Offprint.app --- Kollaborativ skrivning
563
+
\end{itemize}
564
+
565
+
\textbf{IETF-standarder:}
566
+
\begin{itemize}
567
+
\item RFC 9449 --- DPoP (Demonstrating Proof of Possession)
568
+
\item RFC 7636 --- PKCE (Proof Key for Code Exchange)
569
+
\item RFC 9126 --- PAR (Pushed Authorization Requests)
570
+
\end{itemize}
571
+
572
+
\vspace{0.5em}
573
+
574
+
\bibliographystyle{plainnat}
575
+
\bibliography{references}
576
+
577
+
\end{document}
+577
papers/arxiv-identity/identity-es.tex
+577
papers/arxiv-identity/identity-es.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
11
+
\setmainfont{Latin Modern Roman}
12
+
\setsansfont{Latin Modern Sans}
13
+
14
+
% Custom AC fonts
15
+
\newfontfamily\acbold{ywft-processing-bold}[
16
+
Path=../../system/public/type/webfonts/,
17
+
Extension=.ttf
18
+
]
19
+
\newfontfamily\aclight{ywft-processing-light}[
20
+
Path=../../system/public/type/webfonts/,
21
+
Extension=.ttf
22
+
]
23
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
24
+
25
+
% === PACKAGES ===
26
+
\usepackage{xcolor}
27
+
\usepackage{titlesec}
28
+
\usepackage{enumitem}
29
+
\usepackage{booktabs}
30
+
\usepackage{tabularx}
31
+
\usepackage{multicol}
32
+
\usepackage{fancyhdr}
33
+
\usepackage{hyperref}
34
+
\usepackage{graphicx}
35
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
36
+
\usepackage{ragged2e}
37
+
\usepackage{microtype}
38
+
\usepackage{listings}
39
+
\usepackage{natbib}
40
+
\usepackage[colorspec=0.92]{draftwatermark}
41
+
42
+
% === COLORS (AC palette) ===
43
+
\definecolor{acpink}{RGB}{180,72,135}
44
+
\definecolor{acpurple}{RGB}{120,80,180}
45
+
\definecolor{acdark}{RGB}{64,56,74}
46
+
\definecolor{acgray}{RGB}{119,119,119}
47
+
\definecolor{draftcolor}{RGB}{180,72,135}
48
+
49
+
% === DRAFT WATERMARK ===
50
+
\DraftwatermarkOptions{
51
+
text=WORKING DRAFT,
52
+
fontsize=3cm,
53
+
color=draftcolor!18,
54
+
angle=45,
55
+
pos={0.5\paperwidth, 0.5\paperheight}
56
+
}
57
+
58
+
% === JS SYNTAX COLORS ===
59
+
\definecolor{jskw}{RGB}{119,51,170}
60
+
\definecolor{jsfn}{RGB}{0,136,170}
61
+
\definecolor{jsstr}{RGB}{170,120,0}
62
+
\definecolor{jsnum}{RGB}{204,0,102}
63
+
\definecolor{jscmt}{RGB}{102,102,102}
64
+
65
+
% === HYPERREF ===
66
+
\hypersetup{
67
+
colorlinks=true,
68
+
linkcolor=acpurple,
69
+
urlcolor=acpurple,
70
+
citecolor=acpurple,
71
+
pdfauthor={@jeffrey},
72
+
pdftitle={Identidad de handle en el AT Protocol: De Auth0 al inicio de sesión descentralizado},
73
+
}
74
+
75
+
% === SECTION FORMATTING ===
76
+
\titleformat{\section}
77
+
{\normalfont\bfseries\normalsize\uppercase}
78
+
{\thesection.}
79
+
{0.5em}
80
+
{}
81
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
82
+
83
+
\titleformat{\subsection}
84
+
{\normalfont\bfseries\small}
85
+
{\thesubsection}
86
+
{0.5em}
87
+
{}
88
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
89
+
90
+
% === HEADER/FOOTER ===
91
+
\pagestyle{fancy}
92
+
\fancyhf{}
93
+
\renewcommand{\headrulewidth}{0pt}
94
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{Borrador de trabajo --- no citar}}
95
+
\fancyfoot[C]{\footnotesize\thepage}
96
+
97
+
% === CUSTOM COMMANDS ===
98
+
\newcommand{\acdot}{{\color{acpink}.}}
99
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
100
+
\newcommand{\atproto}{\textsc{AT Protocol}}
101
+
102
+
% === LISTINGS ===
103
+
\lstdefinelanguage{acjs}{
104
+
morekeywords=[1]{function,export,const,let,var,return,if,else,new,async,await,import,from},
105
+
morekeywords=[2]{wipe,ink,line,box,circle,write,screen,params,colon,jump,send,store,net,sound,speaker,system},
106
+
sensitive=true,
107
+
morecomment=[l]{//},
108
+
morestring=[b]",
109
+
morestring=[b]',
110
+
morestring=[b]`,
111
+
escapeinside={|}{|},
112
+
}
113
+
114
+
\lstdefinestyle{acjsstyle}{
115
+
language=acjs,
116
+
keywordstyle=[1]\color{jskw}\bfseries,
117
+
keywordstyle=[2]\color{jsfn}\bfseries,
118
+
commentstyle=\color{jscmt}\itshape,
119
+
stringstyle=\color{jsstr},
120
+
}
121
+
122
+
\lstset{
123
+
basicstyle=\ttfamily\small,
124
+
breaklines=true,
125
+
frame=single,
126
+
rulecolor=\color{acgray!30},
127
+
backgroundcolor=\color{acgray!5},
128
+
xleftmargin=0.5em,
129
+
xrightmargin=0.5em,
130
+
aboveskip=0.5em,
131
+
belowskip=0.5em,
132
+
}
133
+
134
+
% === LIST SETTINGS ===
135
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
136
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
137
+
138
+
% === COLUMN SEPARATION ===
139
+
\setlength{\columnsep}{1.8em}
140
+
141
+
% === PARAGRAPH SETTINGS ===
142
+
\setlength{\parindent}{1em}
143
+
\setlength{\parskip}{0.3em}
144
+
145
+
% Hyphenation for narrow two-column layout
146
+
\tolerance=800
147
+
\emergencystretch=1em
148
+
\hyphenpenalty=50
149
+
150
+
\begin{document}
151
+
152
+
% ============ TITLE BLOCK ============
153
+
154
+
\twocolumn[{%
155
+
\begin{center}
156
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
157
+
{\acbold\fontsize{24pt}{28pt}\selectfont\color{acdark} Identidad de handle en el AT Protocol}\par
158
+
\vspace{0.2em}
159
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} De Auth0 al inicio de sesión descentralizado en Aesthetic Computer}\par
160
+
\vspace{0.3em}
161
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} ATProto OAuth, verificación de handles e identidad creativa portátil}\par
162
+
\vspace{0.6em}
163
+
{\normalsize @jeffrey}\par
164
+
{\small\color{acgray} Aesthetic.Computer}\par
165
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
166
+
\vspace{0.3em}
167
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
168
+
\vspace{0.6em}
169
+
\rule{\textwidth}{1.5pt}
170
+
\vspace{0.5em}
171
+
\end{center}
172
+
173
+
\begin{center}
174
+
{\small\color{acpink}\textbf{[ borrador de trabajo --- no citar ]}}
175
+
\end{center}
176
+
\vspace{0.3em}
177
+
178
+
\begin{quote}
179
+
\small\noindent\textbf{Resumen.}
180
+
Aesthetic Computer actualmente autentica a los usuarios a través de Auth0 y mantiene una identidad paralela en un Personal Data Server (PDS) autoalojado del AT Protocol en \texttt{at.aesthetic.computer}. Cada usuario verificado recibe un DID y un handle en el PDS, pero la autenticación pasa por un proveedor OAuth centralizado. Proponemos colapsar esta arquitectura de identidad dual adoptando AT Protocol OAuth~\citep{atproto2024oauth} como método principal de inicio de sesión, permitiendo que cualquier persona con una identidad de Bluesky o ATProto se autentique directamente y reclame el handle equivalente en Aesthetic Computer. Este artículo revisa la pila de identidad de \atproto{}---DIDs, verificación de handles, OAuth 2.1 con DPoP y PAR---examina cómo pckt.blog y otras aplicaciones nativas de ATProto implementan el inicio de sesión descentralizado~\citep{pcktblog2025}, mapea la arquitectura de autenticación actual de AC y propone una migración por fases desde la dependencia de Auth0 hacia una identidad \atproto{}-first. El argumento central: en una plataforma que ya ejecuta su propio PDS y acuña sus propios DIDs, el proveedor de identidad centralizado es el órgano vestigial. Eliminarlo simplifica la pila, elimina una dependencia de pago y convierte a AC en un ciudadano de primera clase de la web social federada.
181
+
\end{quote}
182
+
\vspace{0.5em}
183
+
}]
184
+
185
+
% ============ 1. INTRODUCCIÓN ============
186
+
187
+
\section{Introducción}
188
+
189
+
La identidad en la web es un problema de arrendador. No eres dueño de tu handle en Twitter, tu nombre de usuario en Instagram ni tu inicio de sesión en ninguna plataforma que pueda eliminar tu cuenta. El AT Protocol~\citep{atproto2024spec}---el protocolo de red social descentralizada detrás de Bluesky---propone un arreglo diferente: tu identidad es un par de claves criptográficas, tu handle es un nombre de dominio que tú controlas, y tus datos viven en un Personal Data Server que puedes mover entre proveedores.
190
+
191
+
Aesthetic Computer ha operado un sistema de identidad híbrido desde 2024. Auth0~\citep{auth0spa} gestiona la autenticación: OAuth 2.0 con PKCE, refresh tokens y una base de datos de usuarios administrada. Por separado, un PDS autoalojado en \texttt{at.aesthetic.computer} acuña identidades ATProto para cada usuario verificado. El resultado es un sistema duplicado: dos identidades por usuario, dos almacenes de credenciales, dos rutas de sincronización de handles y una suscripción de pago a Auth0 que cubre la brecha.
192
+
193
+
Este artículo pregunta: ¿y si el PDS \emph{es} el proveedor de identidad?
194
+
195
+
La respuesta no es hipotética. pckt.blog~\citep{pcktblog2025}, una plataforma de blogging construida sobre \atproto{}, autentica a los usuarios exclusivamente a través de \atproto{} OAuth. Los usuarios inician sesión con su handle de Bluesky, su PDS autoalojado o cualquier proveedor de identidad compatible. Sin Auth0, sin Firebase, sin base de datos de usuarios centralizada. El contenido se sincroniza con el PDS del propio usuario utilizando lexicons compartidos de Standard.site~\citep{standardsite2025}.
196
+
197
+
Examinamos cómo este modelo se aplica a Aesthetic Computer---una plataforma de computación creativa con más de 600 piezas interactivas, sesiones multijugador, un lenguaje de programación KidLisp y un sistema operativo nativo bare-metal~\citep{scudder2026os}---y proponemos una migración por fases que preserva la compatibilidad hacia atrás mientras avanza hacia la identidad descentralizada.
198
+
199
+
% ============ 2. LA ARQUITECTURA DE IDENTIDAD ACTUAL DE AC ============
200
+
201
+
\section{Arquitectura actual}
202
+
\label{sec:current}
203
+
204
+
\subsection{Auth0 como proveedor de identidad}
205
+
206
+
La autenticación fluye a través del SDK SPA de Auth0. Al cargar la página, \texttt{boot.mjs} verifica localStorage en busca de estado Auth0 en caché. Si existe una sesión (o se detecta un callback OAuth), inicializa el cliente Auth0 con PKCE y refresh tokens, intercambia códigos de autorización por access tokens y recupera el perfil del usuario. El campo \texttt{sub} de Auth0 (p. ej., \texttt{auth0|abc123} o \texttt{google-oauth2|xyz}) sirve como identificador interno del usuario.
207
+
208
+
\begin{lstlisting}[style=acjsstyle]
209
+
// boot.mjs: current Auth0 flow
210
+
const auth0 = await createAuth0Client({
211
+
domain: |\textcolor{jsstr}{"hi.aesthetic.computer"}|,
212
+
clientId: |\textcolor{jsstr}{"LVdZaM..."}|,
213
+
cacheLocation: |\textcolor{jsstr}{"localstorage"}|,
214
+
useRefreshTokens: true,
215
+
});
216
+
const user = await auth0.getUser();
217
+
// { sub, email, email_verified, ... }
218
+
\end{lstlisting}
219
+
220
+
\subsection{Sistema de handles}
221
+
222
+
Los handles se almacenan en una colección MongoDB \texttt{@handles}, que mapea el \texttt{sub} de Auth0 a una cadena alfanumérica de 1--16 caracteres (con \texttt{.} y \texttt{\_} permitidos). La validación impone que no haya puntuación inicial/final, unicidad insensible a mayúsculas y filtrado de contenido ofensivo. Los handles son la identidad principal orientada al usuario: direccionables por URL (\texttt{@handle/piece-name}), visibles en el chat y pronunciados por AC Native OS.
223
+
224
+
\subsection{Identidad sombra ATProto}
225
+
226
+
En la primera verificación de correo electrónico, un webhook de Auth0 activa \texttt{createAtprotoAccount()}, que:
227
+
228
+
\begin{enumerate}
229
+
\item Genera una contraseña de 32 caracteres
230
+
\item Crea un código de invitación en el PDS
231
+
\item Crea una cuenta en \texttt{handle.at.aesthetic.computer}
232
+
\item Almacena el DID, el handle y la contraseña cifrada en MongoDB (\texttt{users.atproto})
233
+
\end{enumerate}
234
+
235
+
Cuando un usuario cambia su handle de AC, \texttt{updateAtprotoHandle()} sincroniza el cambio con el PDS. El contenido (pinturas, estados de ánimo, fragmentos de KidLisp, cintas, noticias) se replica en el PDS a través de seis lexicons personalizados (\texttt{computer.aesthetic.*}). La identidad ATProto es real y funcional---pero el usuario nunca se autentica a través de ella. Es una identidad sombra: presente, sincronizada, pero no soberana.
236
+
237
+
\subsection{El problema de la duplicación}
238
+
239
+
Esta arquitectura significa:
240
+
241
+
\begin{itemize}
242
+
\item Dos almacenes de credenciales (Auth0 + PDS)
243
+
\item Dos espacios de nombres de handles (handles de AC + handles de PDS)
244
+
\item Dos rutas de sincronización (los cambios de handle se propagan Auth0 $\to$ MongoDB $\to$ PDS)
245
+
\item Una dependencia de pago (suscripción a Auth0)
246
+
\item Sin interoperabilidad (un usuario de Bluesky no puede iniciar sesión en AC con su identidad existente)
247
+
\end{itemize}
248
+
249
+
El PDS ya sabe quién es cada usuario. Ya almacena su DID, su handle, su contenido. La capa de Auth0 añade coste y complejidad sin añadir capacidad que el PDS no pueda proporcionar.
250
+
251
+
% ============ 3. LA PILA DE IDENTIDAD DEL AT PROTOCOL ============
252
+
253
+
\section{La pila de identidad del AT Protocol}
254
+
\label{sec:atproto}
255
+
256
+
Comprender la migración requiere comprender las tres capas de identidad de \atproto{}: DIDs, handles y OAuth.
257
+
258
+
\subsection{Identificadores descentralizados (DIDs)}
259
+
260
+
Un DID~\citep{w3cdid2022, atproto2024did} es un identificador persistente y criptográficamente verificable. \atproto{} utiliza principalmente \texttt{did:plc}, un método diseñado para consistencia fuerte, alta disponibilidad y rotación de claves sin pérdida de identidad. Cada DID se resuelve a un documento que contiene:
261
+
262
+
\begin{itemize}
263
+
\item Una \textbf{clave de firma} (P-256 o K-256)~\citep{atproto2024crypto} para autenticar actualizaciones del repositorio
264
+
\item \textbf{Claves de rotación} para recuperación de cuenta
265
+
\item Una URL de \textbf{endpoint PDS}
266
+
\item El \textbf{handle} actual del usuario
267
+
\end{itemize}
268
+
269
+
El DID es la identidad estable. Los handles cambian; las claves rotan; los proveedores de PDS van y vienen. El DID persiste. AC ya acuña DIDs para cada usuario a través de su PDS. La infraestructura existe.
270
+
271
+
\subsection{Verificación de handles}
272
+
273
+
Un handle de \atproto{}~\citep{atproto2024handle} es un nombre de dominio que se resuelve bidireccionalmente a un DID. La verificación utiliza dos métodos:
274
+
275
+
\textbf{DNS TXT}: Colocar un registro en \texttt{\_atproto.example.com}:
276
+
\begin{lstlisting}
277
+
_atproto.example.com TXT "did=did:plc:abc..."
278
+
\end{lstlisting}
279
+
280
+
\textbf{HTTPS Well-Known}: Servir el DID en:
281
+
\begin{lstlisting}
282
+
GET /.well-known/atproto-did
283
+
Response: did:plc:abc...
284
+
\end{lstlisting}
285
+
286
+
Ambos métodos requieren que el handle se resuelva al DID \emph{y} que el documento DID reclame el handle de vuelta. Esta verificación bidireccional significa: si controlas el dominio, controlas el handle. Ninguna autoridad central asigna handles; el DNS es la autoridad.
287
+
288
+
Para AC, esto significa que \texttt{jeffrey.at.aesthetic.computer} es un handle ATProto real y verificable porque AC controla tanto el DNS como el PDS. Pero también significa que un usuario que ya posee \texttt{alice.bsky.social} o \texttt{alice.dev} tiene una identidad criptográficamente verificada en la que AC puede confiar sin una contraseña.
289
+
290
+
\subsection{ATProto OAuth}
291
+
292
+
La especificación OAuth de \atproto{}~\citep{atproto2024oauth} extiende OAuth 2.1 con tres mecanismos de seguridad obligatorios:
293
+
294
+
\textbf{PKCE} (Proof Key for Code Exchange)~\citep{rfc7636pkce}: Previene la interceptación de códigos de autorización. El cliente genera un verificador aleatorio, envía su hash con la solicitud de autorización y demuestra posesión del verificador original durante el intercambio de tokens.
295
+
296
+
\textbf{PAR} (Pushed Authorization Requests)~\citep{rfc9126par}: El cliente envía los parámetros de autorización mediante POST al servidor de autorización \emph{antes} de redirigir al usuario. Esto previene la manipulación de parámetros en la URL de redirección.
297
+
298
+
\textbf{DPoP} (Demonstrating Proof of Possession)~\citep{rfc9449dpop}: Cada solicitud incluye un JWT firmado que demuestra que el cliente posee la clave privada asociada al token. Incluso si un access token se filtra, no puede ser utilizado por otro cliente.
299
+
300
+
\subsubsection{Identificación del cliente}
301
+
302
+
A diferencia del OAuth tradicional, \atproto{} no requiere prerregistro con cada servidor de autorización. En su lugar, los clientes publican metadatos en una URL HTTPS pública:
303
+
304
+
\begin{lstlisting}[style=acjsstyle]
305
+
// aesthetic.computer/oauth/client-metadata.json
306
+
{
307
+
|\textcolor{jsstr}{"client\_id"}|: |\textcolor{jsstr}{"https://aesthetic.computer/..."}|,
308
+
|\textcolor{jsstr}{"client\_name"}|: |\textcolor{jsstr}{"Aesthetic Computer"}|,
309
+
|\textcolor{jsstr}{"redirect\_uris"}|: [|\textcolor{jsstr}{"https://..."}|],
310
+
|\textcolor{jsstr}{"grant\_types"}|: [|\textcolor{jsstr}{"authorization\_code"}|],
311
+
|\textcolor{jsstr}{"dpop\_bound\_access\_tokens"}|: true
312
+
}
313
+
\end{lstlisting}
314
+
315
+
Cualquier PDS puede descubrir y verificar el cliente obteniendo esta URL. Sin secretos precompartidos, sin registro en tiendas de aplicaciones, sin gestión de claves API.
316
+
317
+
\subsubsection{El flujo}
318
+
319
+
\begin{enumerate}
320
+
\item El usuario introduce su handle (p. ej., \texttt{alice.bsky.social})
321
+
\item El cliente resuelve handle $\to$ DID $\to$ endpoint PDS $\to$ servidor de autorización
322
+
\item El cliente envía los parámetros de autorización mediante PAR
323
+
\item El usuario es redirigido a la UI de autorización de su PDS
324
+
\item El usuario aprueba; el PDS redirige de vuelta con el código de autorización
325
+
\item El cliente intercambia el código por un access token vinculado con DPoP
326
+
\item El cliente verifica que el DID devuelto coincide con la identidad esperada
327
+
\end{enumerate}
328
+
329
+
La diferencia crítica respecto a Auth0: el usuario se autentica con \emph{su propio servidor}. AC nunca ve una contraseña. El PDS---ya sea el de Bluesky, el propio de AC o una instancia autoalojada---es la autoridad de identidad.
330
+
331
+
% ============ 4. CÓMO LO HACE PCKT.BLOG ============
332
+
333
+
\section{Caso de estudio: pckt.blog}
334
+
\label{sec:pckt}
335
+
336
+
pckt.blog~\citep{pcktblog2025} es una plataforma de blogging que autentica exclusivamente a través de \atproto{} OAuth. Su implementación demuestra la viabilidad práctica de la autenticación solo-ATProto para una plataforma de contenido.
337
+
338
+
\subsection{Autenticación}
339
+
340
+
Los usuarios inician sesión introduciendo su handle ATProto. pckt.blog resuelve el handle, descubre el servidor de autorización e inicia el flujo OAuth. El usuario aprueba en su PDS (Bluesky, Blacksky, un servidor autoalojado). pckt.blog recibe un access token vinculado con DPoP y el DID del usuario. No se almacenan contraseñas. No se mantiene una base de datos de usuarios separada.
341
+
342
+
\subsection{Soberanía de datos}
343
+
344
+
El contenido se sincroniza con el PDS del propio usuario utilizando lexicons de Standard.site~\citep{standardsite2025}:
345
+
346
+
\begin{itemize}
347
+
\item \texttt{site.standard.publication} --- colecciones de blog
348
+
\item \texttt{site.standard.document} --- artículos individuales
349
+
\item \texttt{site.standard.graph.subscription} --- relaciones de seguimiento
350
+
\end{itemize}
351
+
352
+
Si pckt.blog desaparece, el contenido del usuario permanece en su PDS, accesible para cualquier lector compatible. Esta es la promesa de ATProto: la plataforma es una vista, no un silo.
353
+
354
+
\subsection{Implicaciones para AC}
355
+
356
+
pckt.blog demuestra que una plataforma orientada al contenido puede operar enteramente sobre identidad ATProto. Los paralelismos con AC son directos:
357
+
358
+
\begin{itemize}
359
+
\item pckt.blog publica artículos; AC publica piezas, pinturas y estados de ánimo
360
+
\item pckt.blog usa lexicons de Standard.site; AC tiene seis lexicons personalizados \texttt{computer.aesthetic.*}
361
+
\item Los usuarios de pckt.blog poseen su contenido en su PDS; AC ya replica contenido en su PDS
362
+
\item Ambas son aplicaciones Node.js/JavaScript
363
+
\end{itemize}
364
+
365
+
La brecha: pckt.blog fue construido nativo de ATProto. AC tiene una base de usuarios Auth0 existente que debe migrarse elegantemente.
366
+
367
+
% ============ 5. MIGRACIÓN PROPUESTA ============
368
+
369
+
\section{Migración propuesta}
370
+
\label{sec:migration}
371
+
372
+
\subsection{Fase 1: ATProto OAuth como inicio de sesión secundario}
373
+
374
+
Añadir ``Iniciar sesión con Bluesky'' junto a Auth0, sin eliminar Auth0.
375
+
376
+
\textbf{Infraestructura:}
377
+
\begin{enumerate}
378
+
\item Publicar metadatos del cliente en \texttt{aesthetic.computer/oauth/client-metadata.json}
379
+
\item Añadir \texttt{@atproto/oauth-client-node}~\citep{npmAtprotoOauth} al backend
380
+
\item Crear dos nuevas funciones Netlify:
381
+
\begin{itemize}
382
+
\item \texttt{POST /api/atproto-auth/start} --- resolver handle, PAR, redirigir
383
+
\item \texttt{GET /api/atproto-auth/callback} --- intercambio de código con DPoP
384
+
\end{itemize}
385
+
\item Almacenar sesiones en Redis (DID, handle, par de claves DPoP, tokens)
386
+
\end{enumerate}
387
+
388
+
\textbf{Flujo del cliente:} Un nuevo botón ``Iniciar sesión con Bluesky'' en \texttt{boot.mjs} activa el flujo ATProto OAuth. En caso de éxito, \texttt{window.acUSER} se llena desde la sesión ATProto (DID como \texttt{sub}, handle, sin correo electrónico a menos que el usuario lo proporcione). La superficie de la API de piezas es idéntica---las piezas ven un usuario con un handle, independientemente de qué ruta de autenticación creó la sesión.
389
+
390
+
\subsection{Fase 2: Puente de handles}
391
+
392
+
Cuando un usuario inicia sesión mediante ATProto, crear un puente para su handle hacia AC:
393
+
394
+
\begin{enumerate}
395
+
\item Extraer el nombre de usuario del handle ATProto (p. ej., \texttt{alice} de \texttt{alice.bsky.social})
396
+
\item Verificar disponibilidad contra la colección \texttt{@handles} de AC
397
+
\item Si está disponible y es válido (1--16 caracteres, alfanumérico), ofrecer reclamación con un clic
398
+
\item Si está ocupado, verificar si el correo del propietario existente coincide---ofrecer vinculación de cuentas
399
+
\item Si está ocupado por otra persona, solicitar una alternativa
400
+
\item Almacenar un mapeo DID $\leftrightarrow$ AC sub en MongoDB para futuros inicios de sesión
401
+
\end{enumerate}
402
+
403
+
Los handles de dominio personalizado (p. ej., \texttt{alice.dev}) requieren que el usuario elija manualmente un handle de AC, ya que el dominio en sí puede no corresponder a una cadena de handle válida.
404
+
405
+
\subsection{Fase 3: Vinculación de identidad}
406
+
407
+
Los usuarios existentes de Auth0 pueden vincular su identidad ATProto:
408
+
409
+
\begin{enumerate}
410
+
\item Desde la configuración de la cuenta, iniciar ATProto OAuth
411
+
\item En caso de éxito, almacenar el DID externo junto al sub de Auth0
412
+
\item Los futuros inicios de sesión aceptan ambas rutas de autenticación
413
+
\item El contenido puede sincronizarse opcionalmente con el PDS externo del usuario (no solo con el PDS de AC)
414
+
\end{enumerate}
415
+
416
+
Esta fase transforma el campo existente \texttt{users.atproto} de una identidad sombra a un vínculo de identidad de primera clase.
417
+
418
+
\subsection{Fase 4: ATProto-primario}
419
+
420
+
Una vez validada la migración:
421
+
422
+
\begin{enumerate}
423
+
\item Los nuevos registros utilizan ATProto OAuth por defecto (creando cuentas en el PDS de AC)
424
+
\item Auth0 permanece como ruta legacy para usuarios existentes
425
+
\item Descontinuación gradual de Auth0 a medida que los usuarios vinculan sus identidades ATProto
426
+
\item Eliminar la dependencia de Auth0, eliminar el coste de suscripción
427
+
\end{enumerate}
428
+
429
+
\subsection{Enrutamiento de PDS}
430
+
431
+
Una decisión arquitectónica clave: ¿a dónde va el contenido?
432
+
433
+
\begin{itemize}
434
+
\item \textbf{Usuarios solo-Auth0}: el contenido se sincroniza con el PDS de AC (comportamiento actual)
435
+
\item \textbf{Usuarios ATProto con PDS externo}: el contenido se sincroniza con \emph{su} PDS
436
+
\item \textbf{Usuarios ATProto en el PDS de AC}: el contenido permanece en el PDS de AC
437
+
\end{itemize}
438
+
439
+
Esto significa que las funciones de sincronización del backend (\texttt{media-atproto.mjs}, \texttt{painting-atproto.mjs}, etc.) necesitan una ruta condicional: resolver el endpoint PDS del usuario desde su documento DID y escribir en ese endpoint en lugar de asumir el PDS de AC.
440
+
441
+
% ============ 6. SEMÁNTICA DE HANDLES ============
442
+
443
+
\section{Semántica de handles}
444
+
\label{sec:handles}
445
+
446
+
El handle es la parte más visible para los humanos de la pila de identidad, y la migración plantea preguntas sobre lo que un handle \emph{significa}.
447
+
448
+
\subsection{Modelo de handle actual}
449
+
450
+
Hoy, un handle de AC es:
451
+
\begin{itemize}
452
+
\item Una cadena de 1--16 caracteres, por orden de llegada
453
+
\item Único dentro del espacio de nombres de AC
454
+
\item Usado para URLs (\texttt{@alice/painting}), chat y personalización del OS
455
+
\item Almacenado en MongoDB, cacheado en Redis
456
+
\item Replicado en el PDS como \texttt{alice.at.aesthetic.computer}
457
+
\end{itemize}
458
+
459
+
\subsection{Modelo de handle ATProto}
460
+
461
+
Un handle ATProto es:
462
+
\begin{itemize}
463
+
\item Un nombre de dominio (cualquier nombre DNS válido)
464
+
\item Verificado bidireccionalmente contra un DID
465
+
\item Globalmente único por autoridad DNS
466
+
\item Portátil entre servicios
467
+
\end{itemize}
468
+
469
+
\subsection{Puente entre los modelos}
470
+
471
+
La propuesta: un handle de AC es un \emph{alias} que mapea a un DID. La fuente de verdad se desplaza de MongoDB a la capa DID. Múltiples métodos de inicio de sesión (Auth0, ATProto OAuth) se resuelven al mismo DID, que se resuelve al mismo handle de AC.
472
+
473
+
Para AC Native OS~\citep{scudder2026os}, donde el handle está inscrito en \texttt{config.json} en la partición de arranque, esto significa que la identidad del dispositivo está respaldada por una identidad criptográfica. ``Hola @alice'' en la pantalla de arranque significa el DID de Alice, la clave de firma de Alice, la identidad portátil de Alice---no solo una cadena en un archivo de configuración.
474
+
475
+
% ============ 7. PREGUNTAS ABIERTAS ============
476
+
477
+
\section{Preguntas abiertas}
478
+
\label{sec:questions}
479
+
480
+
\textbf{Prioridad de handles.} Si \texttt{alice} no está reclamado en AC pero \texttt{alice.bsky.social} inicia sesión, ¿debería obtenerlo automáticamente? El orden de llegada es simple pero permite el acaparamiento. La prioridad verificada por ATProto es más justa pero añade complejidad.
481
+
482
+
\textbf{Requisito de correo electrónico.} Auth0 proporciona correo electrónico verificado para recuperación de cuentas. ATProto OAuth no garantiza correo electrónico. ¿Debería AC requerir un correo electrónico para funcionalidades completas de la cuenta (compras, notificaciones)?
483
+
484
+
\textbf{Multi-tenant.} AC opera un segundo tenant (\texttt{sotce}) con Auth0 separado. ¿Cómo se mapean las identidades ATProto entre tenants? El DID es agnóstico al tenant, lo que puede simplificar la identidad entre tenants.
485
+
486
+
\textbf{Servidor de sesiones.} Las funcionalidades en tiempo real (chat, multijugador) se autentican mediante tokens Auth0 reenviados a través de WebSocket. El servidor de sesiones debe aceptar tokens emitidos por ATProto o un token de sesión unificado.
487
+
488
+
\textbf{Emparejamiento de dispositivos.} AC Native OS empareja mediante un código de 6 caracteres intercambiado a través de Auth0. El equivalente en ATProto: escanear un código QR que inicia un flujo OAuth en el teléfono, entregando tokens al dispositivo.
489
+
490
+
\textbf{Identidad de administrador.} El administrador actualmente es \texttt{handle === "jeffrey" \&\& sub === ADMIN\_SUB}. Bajo autenticación ATProto-first, el administrador es \texttt{did === admin\_did}---más limpio, fundamentado criptográficamente.
491
+
492
+
% ============ 8. TRABAJO RELACIONADO ============
493
+
494
+
\section{Trabajo relacionado}
495
+
\label{sec:related}
496
+
497
+
\textbf{Identidad descentralizada.} La especificación DID del W3C~\citep{w3cdid2022} proporciona el marco formal para identificadores descentralizados. El método \texttt{did:plc} del AT Protocol~\citep{atproto2024did} lo extiende con garantías de consistencia fuerte y un directorio centralizado-pero-auditable en \texttt{plc.directory}. Este es un compromiso pragmático: la descentralización completa de la resolución de identidad sigue siendo un problema abierto, y \texttt{did:plc} intercambia algo de descentralización por fiabilidad operativa.
498
+
499
+
\textbf{Aplicaciones nativas de ATProto.} pckt.blog~\citep{pcktblog2025} demuestra el blogging; Leaflet.pub y Offprint.app colaboran en lexicons compartidos a través de Standard.site~\citep{standardsite2025}. Estas aplicaciones demuestran la viabilidad de la autenticación solo-ATProto para plataformas de contenido.
500
+
501
+
\textbf{Seguridad OAuth.} DPoP~\citep{rfc9449dpop} previene el robo de tokens; PAR~\citep{rfc9126par} previene la manipulación de parámetros; PKCE~\citep{rfc7636pkce} previene la interceptación de códigos. Juntos representan el estado del arte en seguridad OAuth basada en navegador---significativamente más fuerte que el flujo Auth0 SPA que AC utiliza actualmente.
502
+
503
+
\textbf{Identidad convivial.} Las herramientas para la convivialidad de Illich~\citep{illich1973tools} enmarcan la pregunta: ¿el sistema de identidad expande la autonomía personal, o requiere dependencia de un proveedor? Auth0 es un servicio administrado---conveniente pero dependiente. La identidad ATProto es portátil, autoverificable e independiente del proveedor. La visión de Nelson de la computación personal~\citep{nelson1974computerlib} se extiende naturalmente a la identidad personal: deberías ser dueño de tu nombre en la red.
504
+
505
+
% ============ 9. CONCLUSIÓN ============
506
+
507
+
\section{Conclusión}
508
+
509
+
Aesthetic Computer ya ejecuta un PDS, acuña DIDs, sincroniza contenido con registros ATProto y publica lexicons personalizados. La única pieza que falta es permitir que los usuarios se autentiquen a través de esa infraestructura en lugar de pasar por Auth0. La migración no es una reescritura---es la eliminación de un parche.
510
+
511
+
El enfoque por fases (ATProto como inicio de sesión secundario $\to$ puente de handles $\to$ vinculación de identidad $\to$ ATProto-primario) asegura que ningún usuario existente sea perturbado. El estado final: una plataforma de computación creativa donde tu handle es una identidad criptográfica, tu contenido vive en un servidor que tú controlas, e iniciar sesión significa demostrar que posees tus claves---no confiar en un tercero para que responda por ti.
512
+
513
+
El PDS ya está funcionando. Los DIDs ya están acuñados. Los lexicons ya están publicados. Es hora de dejar que los usuarios inicien sesión por la puerta principal.
514
+
515
+
% ============ REFERENCIAS ============
516
+
517
+
\vspace{0.5em}
518
+
\noindent\rule{\columnwidth}{0.5pt}
519
+
520
+
\subsection*{Enlaces de referencia}
521
+
522
+
\noindent\small
523
+
524
+
\textbf{Especificaciones del AT Protocol:}
525
+
\begin{itemize}
526
+
\item \url{https://atproto.com/specs} --- Especificación completa del protocolo
527
+
\item \url{https://atproto.com/specs/oauth} --- Especificación OAuth
528
+
\item \url{https://atproto.com/specs/handle} --- Resolución de handles
529
+
\item \url{https://atproto.com/specs/cryptography} --- Métodos criptográficos
530
+
\item \url{https://web.plc.directory/spec/v0.1/did-plc} --- Especificación DID PLC
531
+
\item \url{https://atproto.com/guides/lexicon} --- Sistema de esquemas Lexicon
532
+
\item \url{https://atproto.com/guides/oauth-patterns} --- Patrones de implementación OAuth
533
+
\end{itemize}
534
+
535
+
\textbf{Guías de implementación:}
536
+
\begin{itemize}
537
+
\item \url{https://docs.bsky.app/blog/oauth-atproto} --- Construir aplicaciones ATProto OAuth
538
+
\item \url{https://docs.bsky.app/docs/advanced-guides/resolving-identities} --- Resolución de identidades
539
+
\item \url{https://docs.bsky.app/docs/advanced-guides/oauth-client} --- Guía del cliente OAuth
540
+
\end{itemize}
541
+
542
+
\textbf{Paquetes NPM:}
543
+
\begin{itemize}
544
+
\item \texttt{@atproto/oauth-client-node} --- Cliente OAuth para Node.js
545
+
\item \texttt{@atproto/oauth-client-browser} --- Cliente OAuth para navegador
546
+
\item \texttt{@atproto/api} --- Cliente TypeScript XRPC
547
+
\item \texttt{@atproto/identity} --- Resolución de DID/handle
548
+
\item \texttt{@atcute/oauth-browser-client} --- Alternativa ligera
549
+
\end{itemize}
550
+
551
+
\textbf{Implementaciones de referencia:}
552
+
\begin{itemize}
553
+
\item \url{https://github.com/pilcrowonpaper/atproto-oauth-example} --- Ejemplo OAuth con Astro
554
+
\item \url{https://github.com/bluesky-social/atproto} --- Monorepo oficial de ATProto
555
+
\item \url{https://standard.site/docs/introduction/} --- Lexicons compartidos de Standard.site
556
+
\end{itemize}
557
+
558
+
\textbf{Aplicaciones que usan ATProto Auth:}
559
+
\begin{itemize}
560
+
\item pckt.blog --- Blogging en la web social abierta
561
+
\item Leaflet.pub --- Publicación de formato largo
562
+
\item Offprint.app --- Escritura colaborativa
563
+
\end{itemize}
564
+
565
+
\textbf{Estándares IETF:}
566
+
\begin{itemize}
567
+
\item RFC 9449 --- DPoP (Demonstrating Proof of Possession)
568
+
\item RFC 7636 --- PKCE (Proof Key for Code Exchange)
569
+
\item RFC 9126 --- PAR (Pushed Authorization Requests)
570
+
\end{itemize}
571
+
572
+
\vspace{0.5em}
573
+
574
+
\bibliographystyle{plainnat}
575
+
\bibliography{references}
576
+
577
+
\end{document}
+592
papers/arxiv-identity/identity-zh.tex
+592
papers/arxiv-identity/identity-zh.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\usepackage{xeCJK}
11
+
\setCJKmainfont{Droid Sans Fallback}
12
+
13
+
\setmainfont{Latin Modern Roman}
14
+
\setsansfont{Latin Modern Sans}
15
+
16
+
% Custom AC fonts
17
+
\newfontfamily\acbold{ywft-processing-bold}[
18
+
Path=../../system/public/type/webfonts/,
19
+
Extension=.ttf
20
+
]
21
+
\newfontfamily\aclight{ywft-processing-light}[
22
+
Path=../../system/public/type/webfonts/,
23
+
Extension=.ttf
24
+
]
25
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
26
+
27
+
% === PACKAGES ===
28
+
\usepackage{xcolor}
29
+
\usepackage{titlesec}
30
+
\usepackage{enumitem}
31
+
\usepackage{booktabs}
32
+
\usepackage{tabularx}
33
+
\usepackage{multicol}
34
+
\usepackage{fancyhdr}
35
+
\usepackage{hyperref}
36
+
\usepackage{graphicx}
37
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
38
+
\usepackage{ragged2e}
39
+
\usepackage{listings}
40
+
\usepackage{natbib}
41
+
\usepackage[colorspec=0.92]{draftwatermark}
42
+
43
+
% === COLORS (AC palette) ===
44
+
\definecolor{acpink}{RGB}{180,72,135}
45
+
\definecolor{acpurple}{RGB}{120,80,180}
46
+
\definecolor{acdark}{RGB}{64,56,74}
47
+
\definecolor{acgray}{RGB}{119,119,119}
48
+
\definecolor{draftcolor}{RGB}{180,72,135}
49
+
50
+
% === DRAFT WATERMARK ===
51
+
\DraftwatermarkOptions{
52
+
text=WORKING DRAFT,
53
+
fontsize=3cm,
54
+
color=draftcolor!18,
55
+
angle=45,
56
+
pos={0.5\paperwidth, 0.5\paperheight}
57
+
}
58
+
59
+
% === JS SYNTAX COLORS ===
60
+
\definecolor{jskw}{RGB}{119,51,170}
61
+
\definecolor{jsfn}{RGB}{0,136,170}
62
+
\definecolor{jsstr}{RGB}{170,120,0}
63
+
\definecolor{jsnum}{RGB}{204,0,102}
64
+
\definecolor{jscmt}{RGB}{102,102,102}
65
+
66
+
% === HYPERREF ===
67
+
\hypersetup{
68
+
colorlinks=true,
69
+
linkcolor=acpurple,
70
+
urlcolor=acpurple,
71
+
citecolor=acpurple,
72
+
pdfauthor={@jeffrey},
73
+
pdftitle={AT Protocol上的Handle身份：从Auth0到去中心化登录},
74
+
}
75
+
76
+
% === SECTION FORMATTING ===
77
+
\titleformat{\section}
78
+
{\normalfont\bfseries\normalsize\uppercase}
79
+
{\thesection.}
80
+
{0.5em}
81
+
{}
82
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
83
+
84
+
\titleformat{\subsection}
85
+
{\normalfont\bfseries\small}
86
+
{\thesubsection}
87
+
{0.5em}
88
+
{}
89
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
90
+
91
+
% === HEADER/FOOTER ===
92
+
\pagestyle{fancy}
93
+
\fancyhf{}
94
+
\renewcommand{\headrulewidth}{0pt}
95
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{工作草稿 --- 请勿引用}}
96
+
\fancyfoot[C]{\footnotesize\thepage}
97
+
98
+
% === CUSTOM COMMANDS ===
99
+
\newcommand{\acdot}{{\color{acpink}.}}
100
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
101
+
\newcommand{\atproto}{\textsc{AT Protocol}}
102
+
103
+
% Random caps for Aesthetic.Computer branding
104
+
\newcount\acrandtmp
105
+
\newcommand{\acrandletter}[2]{%
106
+
\acrandtmp=\uniformdeviate 2\relax
107
+
\ifnum\acrandtmp=0\relax#1\else#2\fi%
108
+
}
109
+
\newcommand{\acrandname}{%
110
+
\acrandletter{a}{A}\acrandletter{e}{E}\acrandletter{s}{S}\acrandletter{t}{T}%
111
+
\acrandletter{h}{H}\acrandletter{e}{E}\acrandletter{t}{T}\acrandletter{i}{I}%
112
+
\acrandletter{c}{C}{\color{acpink}.}\acrandletter{c}{C}\acrandletter{o}{O}%
113
+
\acrandletter{m}{M}\acrandletter{p}{P}\acrandletter{u}{U}\acrandletter{t}{T}%
114
+
\acrandletter{e}{E}\acrandletter{r}{R}%
115
+
}
116
+
117
+
% === LISTINGS ===
118
+
\lstdefinelanguage{acjs}{
119
+
morekeywords=[1]{function,export,const,let,var,return,if,else,new,async,await,import,from},
120
+
morekeywords=[2]{wipe,ink,line,box,circle,write,screen,params,colon,jump,send,store,net,sound,speaker,system},
121
+
sensitive=true,
122
+
morecomment=[l]{//},
123
+
morestring=[b]",
124
+
morestring=[b]',
125
+
morestring=[b]`,
126
+
escapeinside={|}{|},
127
+
}
128
+
129
+
\lstdefinestyle{acjsstyle}{
130
+
language=acjs,
131
+
keywordstyle=[1]\color{jskw}\bfseries,
132
+
keywordstyle=[2]\color{jsfn}\bfseries,
133
+
commentstyle=\color{jscmt}\itshape,
134
+
stringstyle=\color{jsstr},
135
+
}
136
+
137
+
\lstset{
138
+
basicstyle=\ttfamily\small,
139
+
breaklines=true,
140
+
frame=single,
141
+
rulecolor=\color{acgray!30},
142
+
backgroundcolor=\color{acgray!5},
143
+
xleftmargin=0.5em,
144
+
xrightmargin=0.5em,
145
+
aboveskip=0.5em,
146
+
belowskip=0.5em,
147
+
}
148
+
149
+
% === LIST SETTINGS ===
150
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
151
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
152
+
153
+
% === COLUMN SEPARATION ===
154
+
\setlength{\columnsep}{1.8em}
155
+
156
+
% === PARAGRAPH SETTINGS ===
157
+
\setlength{\parindent}{1em}
158
+
\setlength{\parskip}{0.3em}
159
+
160
+
% Hyphenation for narrow two-column layout
161
+
\tolerance=800
162
+
\emergencystretch=1em
163
+
\hyphenpenalty=50
164
+
165
+
\begin{document}
166
+
167
+
% ============ TITLE BLOCK ============
168
+
169
+
\twocolumn[{%
170
+
\begin{center}
171
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
172
+
{\acbold\fontsize{24pt}{28pt}\selectfont\color{acdark} AT Protocol上的Handle身份}\par
173
+
\vspace{0.2em}
174
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} 从Auth0到Aesthetic Computer上的去中心化登录}\par
175
+
\vspace{0.3em}
176
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} ATProto OAuth、Handle验证与可移植创意身份}\par
177
+
\vspace{0.6em}
178
+
{\normalsize @jeffrey}\par
179
+
{\small\color{acgray} Aesthetic.Computer}\par
180
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
181
+
\vspace{0.3em}
182
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
183
+
\vspace{0.6em}
184
+
\rule{\textwidth}{1.5pt}
185
+
\vspace{0.5em}
186
+
\end{center}
187
+
188
+
\begin{center}
189
+
{\small\color{acpink}\textbf{[ 工作草稿 --- 请勿引用 ]}}
190
+
\end{center}
191
+
\vspace{0.3em}
192
+
193
+
\begin{quote}
194
+
\small\noindent\textbf{摘要。}
195
+
Aesthetic Computer目前通过Auth0对用户进行身份验证，并在自托管的AT Protocol个人数据服务器（PDS）\texttt{at.aesthetic.computer}上维护一个并行身份。每个已验证用户都会获得一个DID和一个PDS handle，但身份验证流经一个集中式OAuth提供者。我们建议通过采用AT Protocol OAuth~\citep{atproto2024oauth}作为主要登录方法来合并这种双重身份架构，使任何拥有Bluesky或ATProto身份的人都能直接进行身份验证，并在Aesthetic Computer上获取相应的handle。本文审视了\atproto{}身份栈——DID、handle验证、带有DPoP和PAR的OAuth 2.1——考察了pckt.blog及其他ATProto原生应用如何实现去中心化登录~\citep{pcktblog2025}，映射了当前AC身份验证架构，并提出了从Auth0依赖到\atproto{}-优先身份的分阶段迁移方案。核心论点是：在一个已经运行自己的PDS并铸造自己的DID的平台上，集中式身份提供者是退化器官。移除它可以简化技术栈，消除付费依赖，并使AC成为联邦社交网络的一等公民。
196
+
\end{quote}
197
+
\vspace{0.5em}
198
+
}]
199
+
200
+
% ============ 1. 引言 ============
201
+
202
+
\section{引言}
203
+
204
+
网络上的身份是一个房东问题。你不拥有你在Twitter上的handle、在Instagram上的用户名，或在任何可以删除你账户的平台上的登录凭证。AT Protocol~\citep{atproto2024spec}——Bluesky背后的去中心化社交网络协议——提出了一种不同的安排：你的身份是一个密码学密钥对，你的handle是你控制的域名，你的数据存储在一个你可以在提供者之间迁移的个人数据服务器上。
205
+
206
+
Aesthetic Computer自2024年以来一直运行着一个混合身份系统。Auth0~\citep{auth0spa}处理身份验证：带有PKCE的OAuth 2.0、刷新令牌和一个托管用户数据库。另外，一个自托管的PDS在\texttt{at.aesthetic.computer}上为每个已验证用户铸造ATProto身份。结果是一个重复的系统：每个用户两个身份、两个凭证存储、两条handle同步路径，以及一个付费的Auth0订阅来弥合差距。
207
+
208
+
本文提出的问题是：如果PDS\emph{就是}身份提供者呢？
209
+
210
+
答案不是假设性的。pckt.blog~\citep{pcktblog2025}是一个构建在\atproto{}上的博客平台，完全通过\atproto{} OAuth对用户进行身份验证。用户使用他们的Bluesky handle、自托管的PDS或任何兼容的身份提供者登录。没有Auth0，没有Firebase，没有集中式用户数据库。内容使用来自Standard.site~\citep{standardsite2025}的共享词汇表同步到用户自己的PDS。
211
+
212
+
我们考察这一模型如何适用于Aesthetic Computer——一个拥有600多个交互作品、多人游戏会话、KidLisp编程语言和原生裸机操作系统~\citep{scudder2026os}的创意计算平台——并提出一个保持向后兼容性的分阶段迁移方案，同时向去中心化身份迈进。
213
+
214
+
% ============ 2. 当前AC身份架构 ============
215
+
216
+
\section{当前架构}
217
+
\label{sec:current}
218
+
219
+
\subsection{Auth0作为身份提供者}
220
+
221
+
身份验证通过Auth0的SPA SDK进行。页面加载时，\texttt{boot.mjs}检查localStorage中缓存的Auth0状态。如果存在会话（或检测到OAuth回调），它将使用PKCE和刷新令牌初始化Auth0客户端，交换授权码获取访问令牌，并检索用户配置文件。Auth0的\texttt{sub}字段（例如\texttt{auth0|abc123}或\texttt{google-oauth2|xyz}）作为内部用户标识符。
222
+
223
+
\begin{lstlisting}[style=acjsstyle]
224
+
// boot.mjs: current Auth0 flow
225
+
const auth0 = await createAuth0Client({
226
+
domain: |\textcolor{jsstr}{"hi.aesthetic.computer"}|,
227
+
clientId: |\textcolor{jsstr}{"LVdZaM..."}|,
228
+
cacheLocation: |\textcolor{jsstr}{"localstorage"}|,
229
+
useRefreshTokens: true,
230
+
});
231
+
const user = await auth0.getUser();
232
+
// { sub, email, email_verified, ... }
233
+
\end{lstlisting}
234
+
235
+
\subsection{Handle系统}
236
+
237
+
Handle存储在MongoDB的\texttt{@handles}集合中，将Auth0的\texttt{sub}映射到1--16个字母数字字符的字符串（允许\texttt{.}和\texttt{\_}）。验证强制要求不能以标点符号开头/结尾、不区分大小写的唯一性和不良内容过滤。Handle是面向用户的主要身份：可通过URL访问（\texttt{@handle/piece-name}）、在聊天中可见、由AC Native OS朗读。
238
+
239
+
\subsection{ATProto影子身份}
240
+
241
+
在首次电子邮件验证时，Auth0 webhook触发\texttt{createAtprotoAccount()}，该函数：
242
+
243
+
\begin{enumerate}
244
+
\item 生成一个32字符的密码
245
+
\item 在PDS上创建邀请码
246
+
\item 在\texttt{handle.at.aesthetic.computer}上创建账户
247
+
\item 在MongoDB中存储DID、handle和加密密码（\texttt{users.atproto}）
248
+
\end{enumerate}
249
+
250
+
当用户更改其AC handle时，\texttt{updateAtprotoHandle()}将更改同步到PDS。内容（绘画、心情、KidLisp片段、磁带、新闻）通过六个自定义词汇表（\texttt{computer.aesthetic.*}）镜像到PDS。ATProto身份是真实且功能完备的——但用户从未通过它进行身份验证。它是一个影子身份：存在的、同步的，但不是主权的。
251
+
252
+
\subsection{重复问题}
253
+
254
+
这种架构意味着：
255
+
256
+
\begin{itemize}
257
+
\item 两个凭证存储（Auth0 + PDS）
258
+
\item 两个handle命名空间（AC handle + PDS handle）
259
+
\item 两条同步路径（handle变更传播 Auth0 $\to$ MongoDB $\to$ PDS）
260
+
\item 一个付费依赖（Auth0订阅）
261
+
\item 没有互操作性（Bluesky用户无法使用其现有身份登录AC）
262
+
\end{itemize}
263
+
264
+
PDS已经知道每个用户是谁。它已经存储了他们的DID、他们的handle、他们的内容。Auth0层增加了成本和复杂性，却没有增加PDS无法提供的能力。
265
+
266
+
% ============ 3. AT PROTOCOL身份栈 ============
267
+
268
+
\section{AT Protocol身份栈}
269
+
\label{sec:atproto}
270
+
271
+
理解迁移需要理解\atproto{}身份的三个层次：DID、handle和OAuth。
272
+
273
+
\subsection{去中心化标识符（DID）}
274
+
275
+
DID~\citep{w3cdid2022, atproto2024did}是一个持久的、可加密验证的标识符。\atproto{}主要使用\texttt{did:plc}，这是一种为强一致性、高可用性和不丢失身份的密钥轮换而设计的方法。每个DID解析为一个包含以下内容的文档：
276
+
277
+
\begin{itemize}
278
+
\item 用于验证仓库更新的\textbf{签名密钥}（P-256或K-256）~\citep{atproto2024crypto}
279
+
\item 用于账户恢复的\textbf{轮换密钥}
280
+
\item \textbf{PDS端点} URL
281
+
\item 用户当前的\textbf{handle}
282
+
\end{itemize}
283
+
284
+
DID是稳定的身份。Handle会变；密钥会轮换；PDS提供者来来去去。DID持续存在。AC已经通过其PDS为每个用户铸造DID。基础设施已经存在。
285
+
286
+
\subsection{Handle验证}
287
+
288
+
\atproto{} handle~\citep{atproto2024handle}是一个双向解析到DID的域名。验证使用两种方法：
289
+
290
+
\textbf{DNS TXT}：在\texttt{\_atproto.example.com}放置一条记录：
291
+
\begin{lstlisting}
292
+
_atproto.example.com TXT "did=did:plc:abc..."
293
+
\end{lstlisting}
294
+
295
+
\textbf{HTTPS Well-Known}：在以下地址提供DID：
296
+
\begin{lstlisting}
297
+
GET /.well-known/atproto-did
298
+
Response: did:plc:abc...
299
+
\end{lstlisting}
300
+
301
+
两种方法都要求handle解析到DID，\emph{且}DID文档声明该handle。这种双向验证意味着：如果你控制域名，你就控制了handle。没有中央机构分配handle；DNS就是权威。
302
+
303
+
对于AC，这意味着\texttt{jeffrey.at.aesthetic.computer}是一个真实的、可验证的ATProto handle，因为AC同时控制DNS和PDS。但这也意味着已经拥有\texttt{alice.bsky.social}或\texttt{alice.dev}的用户拥有一个AC可以信任的密码学验证身份——无需密码。
304
+
305
+
\subsection{ATProto OAuth}
306
+
307
+
\atproto{} OAuth规范~\citep{atproto2024oauth}扩展了OAuth 2.1，增加了三个强制性安全机制：
308
+
309
+
\textbf{PKCE}（Proof Key for Code Exchange）~\citep{rfc7636pkce}：防止授权码拦截。客户端生成一个随机验证器，随授权请求发送其哈希值，并在令牌交换时证明持有原始验证器。
310
+
311
+
\textbf{PAR}（Pushed Authorization Requests）~\citep{rfc9126par}：客户端在重定向用户\emph{之前}通过POST向授权服务器提交授权参数。这防止了重定向URL中的参数篡改。
312
+
313
+
\textbf{DPoP}（Demonstrating Proof of Possession）~\citep{rfc9449dpop}：每个请求包含一个签名JWT，证明客户端持有与令牌关联的私钥。即使访问令牌泄露，也不能被其他客户端使用。
314
+
315
+
\subsubsection{客户端标识}
316
+
317
+
与传统OAuth不同，\atproto{}不要求在每个授权服务器上预注册。相反，客户端在公共HTTPS URL上发布元数据：
318
+
319
+
\begin{lstlisting}[style=acjsstyle]
320
+
// aesthetic.computer/oauth/client-metadata.json
321
+
{
322
+
|\textcolor{jsstr}{"client\_id"}|: |\textcolor{jsstr}{"https://aesthetic.computer/..."}|,
323
+
|\textcolor{jsstr}{"client\_name"}|: |\textcolor{jsstr}{"Aesthetic Computer"}|,
324
+
|\textcolor{jsstr}{"redirect\_uris"}|: [|\textcolor{jsstr}{"https://..."}|],
325
+
|\textcolor{jsstr}{"grant\_types"}|: [|\textcolor{jsstr}{"authorization\_code"}|],
326
+
|\textcolor{jsstr}{"dpop\_bound\_access\_tokens"}|: true
327
+
}
328
+
\end{lstlisting}
329
+
330
+
任何PDS都可以通过获取此URL来发现和验证客户端。没有预共享密钥，没有应用商店注册，没有API密钥管理。
331
+
332
+
\subsubsection{流程}
333
+
334
+
\begin{enumerate}
335
+
\item 用户输入其handle（例如\texttt{alice.bsky.social}）
336
+
\item 客户端解析 handle $\to$ DID $\to$ PDS端点 $\to$ 授权服务器
337
+
\item 客户端通过PAR推送授权参数
338
+
\item 用户被重定向到其PDS的授权界面
339
+
\item 用户批准；PDS带着授权码重定向回来
340
+
\item 客户端交换授权码获取DPoP绑定的访问令牌
341
+
\item 客户端验证返回的DID与预期身份匹配
342
+
\end{enumerate}
343
+
344
+
与Auth0的关键区别：用户使用\emph{自己的服务器}进行身份验证。AC永远不会看到密码。PDS——无论是Bluesky的、AC自己的还是自托管的实例——就是身份权威。
345
+
346
+
% ============ 4. PCKT.BLOG的做法 ============
347
+
348
+
\section{案例研究：pckt.blog}
349
+
\label{sec:pckt}
350
+
351
+
pckt.blog~\citep{pcktblog2025}是一个完全通过\atproto{} OAuth进行身份验证的博客平台。它的实现证明了ATProto-only身份验证对内容平台的实际可行性。
352
+
353
+
\subsection{身份验证}
354
+
355
+
用户通过输入其ATProto handle来登录。pckt.blog解析handle，发现授权服务器，并启动OAuth流程。用户在其PDS上批准（Bluesky、Blacksky、自托管服务器）。pckt.blog接收DPoP绑定的访问令牌和用户的DID。不存储密码。不维护单独的用户数据库。
356
+
357
+
\subsection{数据主权}
358
+
359
+
内容使用Standard.site词汇表~\citep{standardsite2025}同步到用户自己的PDS：
360
+
361
+
\begin{itemize}
362
+
\item \texttt{site.standard.publication} --- 博客集合
363
+
\item \texttt{site.standard.document} --- 单篇文章
364
+
\item \texttt{site.standard.graph.subscription} --- 关注关系
365
+
\end{itemize}
366
+
367
+
如果pckt.blog消失，用户的内容仍保留在其PDS上，可被任何兼容的阅读器访问。这就是ATProto的承诺：平台是一个视图，而不是一个孤岛。
368
+
369
+
\subsection{对AC的启示}
370
+
371
+
pckt.blog证明了面向内容的平台可以完全基于ATProto身份运行。与AC的相似之处是直接的：
372
+
373
+
\begin{itemize}
374
+
\item pckt.blog发布文章；AC发布作品、绘画和心情
375
+
\item pckt.blog使用Standard.site词汇表；AC有六个自定义\texttt{computer.aesthetic.*}词汇表
376
+
\item pckt.blog的用户在其PDS上拥有其内容；AC已经将内容镜像到其PDS
377
+
\item 两者都是Node.js/JavaScript应用程序
378
+
\end{itemize}
379
+
380
+
差距在于：pckt.blog是ATProto原生构建的。AC有一个现有的Auth0用户群，需要优雅地迁移。
381
+
382
+
% ============ 5. 提议的迁移方案 ============
383
+
384
+
\section{提议的迁移方案}
385
+
\label{sec:migration}
386
+
387
+
\subsection{第一阶段：ATProto OAuth作为辅助登录}
388
+
389
+
在Auth0旁边添加"使用Bluesky登录"，而不移除Auth0。
390
+
391
+
\textbf{基础设施：}
392
+
\begin{enumerate}
393
+
\item 在\texttt{aesthetic.computer/oauth/client-metadata.json}发布客户端元数据
394
+
\item 将\texttt{@atproto/oauth-client-node}~\citep{npmAtprotoOauth}添加到后端
395
+
\item 创建两个新的Netlify函数：
396
+
\begin{itemize}
397
+
\item \texttt{POST /api/atproto-auth/start} --- 解析handle、PAR、重定向
398
+
\item \texttt{GET /api/atproto-auth/callback} --- 带DPoP的授权码交换
399
+
\end{itemize}
400
+
\item 在Redis中存储会话（DID、handle、DPoP密钥对、令牌）
401
+
\end{enumerate}
402
+
403
+
\textbf{客户端流程：}\texttt{boot.mjs}中新的"使用Bluesky登录"按钮触发ATProto OAuth流程。成功后，\texttt{window.acUSER}从ATProto会话填充（DID作为\texttt{sub}、handle、除非用户提供否则没有电子邮件）。作品API表面是相同的——作品看到一个有handle的用户，无论哪条身份验证路径创建了会话。
404
+
405
+
\subsection{第二阶段：Handle桥接}
406
+
407
+
当用户通过ATProto登录时，将其handle桥接到AC：
408
+
409
+
\begin{enumerate}
410
+
\item 从ATProto handle中提取用户名（例如从\texttt{alice.bsky.social}中提取\texttt{alice}）
411
+
\item 对照AC的\texttt{@handles}集合检查可用性
412
+
\item 如果可用且有效（1--16个字符，字母数字），提供一键认领
413
+
\item 如果已被占用，检查现有所有者的电子邮件是否匹配——提供账户关联
414
+
\item 如果被其他人占用，提示选择替代方案
415
+
\item 在MongoDB中存储DID $\leftrightarrow$ AC sub映射，用于未来登录
416
+
\end{enumerate}
417
+
418
+
自定义域名handle（例如\texttt{alice.dev}）要求用户手动选择AC handle，因为域名本身可能不映射到有效的handle字符串。
419
+
420
+
\subsection{第三阶段：身份关联}
421
+
422
+
现有Auth0用户可以关联其ATProto身份：
423
+
424
+
\begin{enumerate}
425
+
\item 从账户设置中启动ATProto OAuth
426
+
\item 成功后，将外部DID与Auth0 sub一起存储
427
+
\item 未来的登录接受两条身份验证路径
428
+
\item 内容可以选择性地同步到用户的外部PDS（不仅限于AC的PDS）
429
+
\end{enumerate}
430
+
431
+
这一阶段将现有的\texttt{users.atproto}字段从影子身份转变为一等身份关联。
432
+
433
+
\subsection{第四阶段：ATProto-优先}
434
+
435
+
迁移验证完成后：
436
+
437
+
\begin{enumerate}
438
+
\item 新注册默认使用ATProto OAuth（在AC的PDS上创建账户）
439
+
\item Auth0作为现有用户的遗留路径保留
440
+
\item 随着用户关联其ATProto身份，逐步淘汰Auth0
441
+
\item 移除Auth0依赖，消除订阅费用
442
+
\end{enumerate}
443
+
444
+
\subsection{PDS路由}
445
+
446
+
一个关键的架构决策：内容去哪里？
447
+
448
+
\begin{itemize}
449
+
\item \textbf{仅Auth0用户}：内容同步到AC的PDS（当前行为）
450
+
\item \textbf{拥有外部PDS的ATProto用户}：内容同步到\emph{他们的}PDS
451
+
\item \textbf{在AC PDS上的ATProto用户}：内容保留在AC的PDS上
452
+
\end{itemize}
453
+
454
+
这意味着后端同步函数（\texttt{media-atproto.mjs}、\texttt{painting-atproto.mjs}等）需要一个条件路径：从用户的DID文档中解析用户的PDS端点，并写入该端点而不是假定AC的PDS。
455
+
456
+
% ============ 6. HANDLE语义 ============
457
+
458
+
\section{Handle语义}
459
+
\label{sec:handles}
460
+
461
+
Handle是身份栈中对人类最可见的部分，迁移引发了关于handle\emph{含义}的问题。
462
+
463
+
\subsection{当前Handle模型}
464
+
465
+
今天，一个AC handle是：
466
+
\begin{itemize}
467
+
\item 一个1--16个字符的字符串，先到先得
468
+
\item 在AC命名空间内唯一
469
+
\item 用于URL（\texttt{@alice/painting}）、聊天和OS个性化
470
+
\item 存储在MongoDB中，缓存在Redis中
471
+
\item 镜像到PDS为\texttt{alice.at.aesthetic.computer}
472
+
\end{itemize}
473
+
474
+
\subsection{ATProto Handle模型}
475
+
476
+
一个ATProto handle是：
477
+
\begin{itemize}
478
+
\item 一个域名（任何有效的DNS名称）
479
+
\item 双向验证对应一个DID
480
+
\item 通过DNS权威全局唯一
481
+
\item 跨服务可移植
482
+
\end{itemize}
483
+
484
+
\subsection{桥接两种模型}
485
+
486
+
提议：AC handle是映射到DID的\emph{别名}。真相来源从MongoDB转移到DID层。多种登录方法（Auth0、ATProto OAuth）解析到同一个DID，后者解析到同一个AC handle。
487
+
488
+
对于AC Native OS~\citep{scudder2026os}，handle被写入启动分区的\texttt{config.json}中，这意味着设备身份由密码学身份支撑。启动屏幕上的"你好 @alice"意味着Alice的DID、Alice的签名密钥、Alice的可移植身份——而不仅仅是配置文件中的一个字符串。
489
+
490
+
% ============ 7. 开放问题 ============
491
+
492
+
\section{开放问题}
493
+
\label{sec:questions}
494
+
495
+
\textbf{Handle优先级。}如果\texttt{alice}在AC上未被认领，但\texttt{alice.bsky.social}登录了，她应该自动获得它吗？先到先得很简单但允许抢注。ATProto验证优先更公平但增加了复杂性。
496
+
497
+
\textbf{电子邮件要求。}Auth0提供经过验证的电子邮件用于账户恢复。ATProto OAuth不保证电子邮件。AC是否应该要求电子邮件才能使用完整的账户功能（购买、通知）？
498
+
499
+
\textbf{多租户。}AC运营第二个租户（\texttt{sotce}），使用独立的Auth0。ATProto身份如何跨租户映射？DID与租户无关，这可能简化跨租户身份。
500
+
501
+
\textbf{会话服务器。}实时功能（聊天、多人游戏）通过WebSocket转发Auth0令牌进行身份验证。会话服务器必须接受ATProto发行的令牌或统一的会话令牌。
502
+
503
+
\textbf{设备配对。}AC Native OS通过Auth0交换6字符代码进行配对。ATProto等效方案：扫描QR码，在手机上启动OAuth流程，将令牌传送到设备。
504
+
505
+
\textbf{管理员身份。}管理员目前是\texttt{handle === "jeffrey" \&\& sub === ADMIN\_SUB}。在ATProto-优先身份验证下，管理员是\texttt{did === admin\_did}——更简洁，有密码学基础。
506
+
507
+
% ============ 8. 相关工作 ============
508
+
509
+
\section{相关工作}
510
+
\label{sec:related}
511
+
512
+
\textbf{去中心化身份。}W3C DID规范~\citep{w3cdid2022}为去中心化标识符提供了正式框架。AT Protocol的\texttt{did:plc}方法~\citep{atproto2024did}通过强一致性保证和位于\texttt{plc.directory}的集中但可审计的目录对其进行了扩展。这是一个务实的折衷：身份解析的完全去中心化仍然是一个开放问题，\texttt{did:plc}用一些去中心化换取了运营可靠性。
513
+
514
+
\textbf{ATProto原生应用。}pckt.blog~\citep{pcktblog2025}展示了博客功能；Leaflet.pub和Offprint.app通过Standard.site~\citep{standardsite2025}在共享词汇表上协作。这些应用证明了ATProto-only身份验证对内容平台的可行性。
515
+
516
+
\textbf{OAuth安全性。}DPoP~\citep{rfc9449dpop}防止令牌盗窃；PAR~\citep{rfc9126par}防止参数篡改；PKCE~\citep{rfc7636pkce}防止授权码拦截。它们共同代表了基于浏览器的OAuth安全的最新技术——显著强于AC目前使用的Auth0 SPA流程。
517
+
518
+
\textbf{共生身份。}伊利奇的共生工具~\citep{illich1973tools}框定了这个问题：身份系统是扩展个人自主性，还是要求依赖于提供者？Auth0是一个托管服务——方便但依赖。ATProto身份是可移植的、可自我验证的、独立于提供者的。纳尔逊的个人计算愿景~\citep{nelson1974computerlib}自然延伸到个人身份：你应该拥有你在网络上的名字。
519
+
520
+
% ============ 9. 结论 ============
521
+
522
+
\section{结论}
523
+
524
+
Aesthetic Computer已经运行着一个PDS，铸造DID，将内容同步到ATProto记录，并发布自定义词汇表。唯一缺失的部分是让用户通过该基础设施进行身份验证，而不是绕道Auth0。迁移不是重写——而是移除一个变通方案。
525
+
526
+
分阶段方法（ATProto作为辅助登录 $\to$ handle桥接 $\to$ 身份关联 $\to$ ATProto-优先）确保不会打扰任何现有用户。最终状态：一个创意计算平台，你的handle是密码学身份，你的内容存储在你控制的服务器上，登录意味着证明你拥有你的密钥——而不是信任第三方为你担保。
527
+
528
+
PDS已经在运行。DID已经被铸造。词汇表已经发布。是时候让用户从正门登录了。
529
+
530
+
% ============ 参考文献 ============
531
+
532
+
\vspace{0.5em}
533
+
\noindent\rule{\columnwidth}{0.5pt}
534
+
535
+
\subsection*{参考链接}
536
+
537
+
\noindent\small
538
+
539
+
\textbf{AT Protocol规范：}
540
+
\begin{itemize}
541
+
\item \url{https://atproto.com/specs} --- 完整协议规范
542
+
\item \url{https://atproto.com/specs/oauth} --- OAuth规范
543
+
\item \url{https://atproto.com/specs/handle} --- Handle解析
544
+
\item \url{https://atproto.com/specs/cryptography} --- 密码学方法
545
+
\item \url{https://web.plc.directory/spec/v0.1/did-plc} --- DID PLC规范
546
+
\item \url{https://atproto.com/guides/lexicon} --- Lexicon模式系统
547
+
\item \url{https://atproto.com/guides/oauth-patterns} --- OAuth实现模式
548
+
\end{itemize}
549
+
550
+
\textbf{实现指南：}
551
+
\begin{itemize}
552
+
\item \url{https://docs.bsky.app/blog/oauth-atproto} --- 构建ATProto OAuth应用
553
+
\item \url{https://docs.bsky.app/docs/advanced-guides/resolving-identities} --- 身份解析
554
+
\item \url{https://docs.bsky.app/docs/advanced-guides/oauth-client} --- OAuth客户端指南
555
+
\end{itemize}
556
+
557
+
\textbf{NPM包：}
558
+
\begin{itemize}
559
+
\item \texttt{@atproto/oauth-client-node} --- Node.js OAuth客户端
560
+
\item \texttt{@atproto/oauth-client-browser} --- 浏览器OAuth客户端
561
+
\item \texttt{@atproto/api} --- TypeScript XRPC客户端
562
+
\item \texttt{@atproto/identity} --- DID/handle解析
563
+
\item \texttt{@atcute/oauth-browser-client} --- 轻量级替代方案
564
+
\end{itemize}
565
+
566
+
\textbf{参考实现：}
567
+
\begin{itemize}
568
+
\item \url{https://github.com/pilcrowonpaper/atproto-oauth-example} --- Astro OAuth示例
569
+
\item \url{https://github.com/bluesky-social/atproto} --- ATProto官方单体仓库
570
+
\item \url{https://standard.site/docs/introduction/} --- Standard.site共享词汇表
571
+
\end{itemize}
572
+
573
+
\textbf{使用ATProto Auth的应用：}
574
+
\begin{itemize}
575
+
\item pckt.blog --- 开放社交网络上的博客
576
+
\item Leaflet.pub --- 长文发布
577
+
\item Offprint.app --- 协作写作
578
+
\end{itemize}
579
+
580
+
\textbf{IETF标准：}
581
+
\begin{itemize}
582
+
\item RFC 9449 --- DPoP (Demonstrating Proof of Possession)
583
+
\item RFC 7636 --- PKCE (Proof Key for Code Exchange)
584
+
\item RFC 9126 --- PAR (Pushed Authorization Requests)
585
+
\end{itemize}
586
+
587
+
\vspace{0.5em}
588
+
589
+
\bibliographystyle{plainnat}
590
+
\bibliography{references}
591
+
592
+
\end{document}
+562
papers/arxiv-kidlisp-cards/kidlisp-cards-da.tex
+562
papers/arxiv-kidlisp-cards/kidlisp-cards-da.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
11
+
\setmainfont{Latin Modern Roman}
12
+
\setsansfont{Latin Modern Sans}
13
+
14
+
% Custom AC fonts
15
+
\newfontfamily\acbold{ywft-processing-bold}[
16
+
Path=../../system/public/type/webfonts/,
17
+
Extension=.ttf
18
+
]
19
+
\newfontfamily\aclight{ywft-processing-light}[
20
+
Path=../../system/public/type/webfonts/,
21
+
Extension=.ttf
22
+
]
23
+
\newfontfamily\kidlispfont{ComicRelief-Regular}[
24
+
Path=../arxiv-kidlisp/fonts/,
25
+
Extension=.ttf
26
+
]
27
+
\newfontfamily\kidlispbold{ComicRelief-Bold}[
28
+
Path=../arxiv-kidlisp/fonts/,
29
+
Extension=.ttf
30
+
]
31
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
32
+
33
+
% === PACKAGES ===
34
+
\usepackage{xcolor}
35
+
\usepackage{titlesec}
36
+
\usepackage{enumitem}
37
+
\usepackage{booktabs}
38
+
\usepackage{tabularx}
39
+
\usepackage{fancyhdr}
40
+
\usepackage{hyperref}
41
+
\usepackage{graphicx}
42
+
\graphicspath{{figures/}{../arxiv-kidlisp/figures/}}
43
+
\usepackage{ragged2e}
44
+
\usepackage{microtype}
45
+
\usepackage{listings}
46
+
\usepackage{natbib}
47
+
\usepackage[colorspec=0.92]{draftwatermark}
48
+
49
+
% === COLORS (AC palette) ===
50
+
\definecolor{acpink}{RGB}{180,72,135}
51
+
\definecolor{acpurple}{RGB}{120,80,180}
52
+
\definecolor{acdark}{RGB}{64,56,74}
53
+
\definecolor{acgray}{RGB}{119,119,119}
54
+
\definecolor{klbrand}{RGB}{205,92,155}
55
+
\definecolor{klcyan}{RGB}{112,214,255}
56
+
\definecolor{kldark}{RGB}{48,43,58}
57
+
\definecolor{draftcolor}{RGB}{205,92,155}
58
+
59
+
% === DRAFT WATERMARK ===
60
+
\DraftwatermarkOptions{
61
+
text=ARBEJDSUDKAST,
62
+
fontsize=3cm,
63
+
color=draftcolor!18,
64
+
angle=45,
65
+
pos={0.5\paperwidth, 0.5\paperheight}
66
+
}
67
+
68
+
% === KIDLISP SYNTAX COLORS ===
69
+
\definecolor{klfn}{RGB}{0,136,170}
70
+
\definecolor{klform}{RGB}{119,51,170}
71
+
\definecolor{klrepeat}{RGB}{170,0,170}
72
+
\definecolor{klnum}{RGB}{204,0,102}
73
+
\definecolor{klstr}{RGB}{170,120,0}
74
+
\definecolor{klcmt}{RGB}{102,102,102}
75
+
\definecolor{klmath}{RGB}{0,136,0}
76
+
\definecolor{klvar}{RGB}{204,102,0}
77
+
\definecolor{klembed}{RGB}{0,136,0}
78
+
79
+
% KidLisp inline color macros
80
+
\newcommand{\kn}[1]{\textcolor{klnum}{#1}}
81
+
\newcommand{\kt}[1]{\textcolor{klstr}{#1}}
82
+
\newcommand{\kv}[1]{\textcolor{klvar}{#1}}
83
+
\newcommand{\ke}[1]{\textcolor{klembed}{\textbf{#1}}}
84
+
\newcommand{\km}[1]{\textcolor{klmath}{#1}}
85
+
86
+
% === HYPERREF ===
87
+
\hypersetup{
88
+
colorlinks=true,
89
+
linkcolor=acpurple,
90
+
urlcolor=acpurple,
91
+
citecolor=acpurple,
92
+
pdfauthor={@jeffrey},
93
+
pdftitle={KidLisp-kort: Programmer der kan v\ae re p\aa\ et kort},
94
+
}
95
+
96
+
% === SECTION FORMATTING ===
97
+
\titleformat{\section}
98
+
{\normalfont\bfseries\normalsize\uppercase}
99
+
{\thesection.}
100
+
{0.5em}
101
+
{}
102
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
103
+
104
+
\titleformat{\subsection}
105
+
{\normalfont\bfseries\small}
106
+
{\thesubsection}
107
+
{0.5em}
108
+
{}
109
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
110
+
111
+
% === HEADER/FOOTER ===
112
+
\pagestyle{fancy}
113
+
\fancyhf{}
114
+
\renewcommand{\headrulewidth}{0pt}
115
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{Arbejdsudkast --- ikke til citation}}
116
+
\fancyfoot[C]{\footnotesize\thepage}
117
+
118
+
% === CUSTOM COMMANDS ===
119
+
\newcommand{\acdot}{{\color{acpink}.}}
120
+
\newcommand{\kidlisp}{\textsc{KidLisp}}
121
+
122
+
% === LISTINGS ===
123
+
\lstdefinelanguage{kidlisp}{
124
+
morekeywords=[1]{wipe,ink,line,box,circle,tri,plot,flood,shape,zoom,scroll,spin,blur,contrast,embed,layer,width,height,frame,time,wiggle,melody,mic,suck,sort,form,trans,cube,move,scale,hop,overtone,resolution,write,text,type,stamp,paste,point,poly,noise,fade,pan,unpan,mask,unmask,flip,crawl,left,right,up,down,goto,face,outline,fill,stroke},
125
+
morekeywords=[2]{def,let,if,cond,once,later,lambda,do},
126
+
morekeywords=[3]{repeat},
127
+
morekeywords=[4]{random,sin,cos,tan,floor,ceil,round,abs,sqrt,min,max},
128
+
sensitive=true,
129
+
morecomment=[l]{;},
130
+
morestring=[b]",
131
+
escapeinside={|}{|},
132
+
}
133
+
\lstset{
134
+
language=kidlisp,
135
+
basicstyle=\ttfamily\small,
136
+
keywordstyle=[1]\color{klfn}\bfseries,
137
+
keywordstyle=[2]\color{klform}\bfseries,
138
+
keywordstyle=[3]\color{klrepeat}\bfseries,
139
+
keywordstyle=[4]\color{klmath},
140
+
commentstyle=\color{klcmt}\itshape,
141
+
stringstyle=\color{klstr},
142
+
breaklines=true,
143
+
frame=single,
144
+
rulecolor=\color{acgray!30},
145
+
backgroundcolor=\color{acgray!5},
146
+
xleftmargin=0.5em,
147
+
xrightmargin=0.5em,
148
+
aboveskip=0.5em,
149
+
belowskip=0.5em,
150
+
}
151
+
152
+
\lstdefinelanguage{python}{
153
+
morekeywords={def,return,import,from,class,if,else,for,in,with,as,try,except,None,True,False,self,and,or,not,lambda,yield,pass,break,continue,raise,while},
154
+
sensitive=true,
155
+
morecomment=[l]{\#},
156
+
morestring=[b]",
157
+
morestring=[b]',
158
+
}
159
+
\lstset{
160
+
language=kidlisp,
161
+
}
162
+
163
+
% === LIST SETTINGS ===
164
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
165
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
166
+
167
+
% === COLUMN SEPARATION ===
168
+
\setlength{\columnsep}{1.8em}
169
+
170
+
% === PARAGRAPH SETTINGS ===
171
+
\setlength{\parindent}{1em}
172
+
\setlength{\parskip}{0.3em}
173
+
174
+
\tolerance=800
175
+
\emergencystretch=1em
176
+
\hyphenpenalty=50
177
+
178
+
\begin{document}
179
+
180
+
% ============ TITLE BLOCK ============
181
+
182
+
\twocolumn[{%
183
+
\begin{center}
184
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
185
+
{\kidlispbold\fontsize{24pt}{28pt}\selectfont\color{kldark} Kid{\color{klbrand}Lisp}-kort}\par
186
+
\vspace{0.2em}
187
+
{\kidlispfont\fontsize{11pt}{13pt}\selectfont\color{klbrand} Programmer der kan v\ae re p\aa\ et kort}\par
188
+
\vspace{0.6em}
189
+
{\normalsize @jeffrey}\par
190
+
{\small\color{acgray} Aesthetic\acdot Computer}\par
191
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
192
+
\vspace{0.3em}
193
+
{\small\color{acpurple} \url{https://kidlisp.com} \enspace$\cdot$\enspace \url{https://aesthetic.computer}}\par
194
+
\vspace{0.6em}
195
+
\rule{\textwidth}{1.5pt}
196
+
\vspace{0.5em}
197
+
\end{center}
198
+
199
+
\begin{center}
200
+
{\small\color{acpink}\textbf{[ arbejdsudkast --- ikke til citation ]}}
201
+
\end{center}
202
+
\vspace{0.3em}
203
+
204
+
\begin{quote}
205
+
\small\noindent\textbf{Abstrakt.}
206
+
\kidlisp{}-programmer er korte. Et typisk program best\aa r af 2--4 linjer S-udtryk, der producerer en komplet visuel komposition---en stjerneburst, en spiral, et t\ae ppe, en fraktal. Denne korthed er ikke tilf\ae ldig men designet: sproget udelader brugerdefinerede funktioner, rekursion og abstraktionsmekanismer, s\aa\ programmer forbliver flade og l\ae sbare. Vi observerer, at denne fladhed skaber en naturlig korrespondance mellem programmer og fysiske kort. Et \kidlisp{}-program, dets kildekode og dets renderede output kan sameksistere p\aa\ et enkelt trykt kort. Denne artikel beskriver \emph{KidLisp Cards}-formatet---et s\ae t programmer organiseret efter visuel kategori---og en Python-renderingspipeline (PIL-baseret fortolker), der producerer kortbilleder uden for browseren. Vi diskuterer, hvad kort er nu (en kurateret notesbog af visuelle koaner), hvad de kunne blive (byttekort, p\ae dagogiske sekvenser, trykte partiturer, postkunst), og hvordan kortbegr\ae nsningen p\aa virker sprogdesignet.
207
+
\end{quote}
208
+
\vspace{0.5em}
209
+
}]
210
+
211
+
% ============ 1. INTRODUKTION ============
212
+
213
+
\section{Introduktion}
214
+
215
+
De fleste programmeringssprog producerer programmer, der er for lange til at trykke p\aa\ et kartotekskort. Dette er en konsekvens af abstraktion: generelle programmeringssprog opmuntrer til nedbrydning i funktioner, klasser, moduler og filer. Programmet er fordelt over en kodebase. Ingen enkelt artefakt fanger helheden.
216
+
217
+
\kidlisp{} er anderledes. Dets programmer er typisk 1--6 linjer lange. En komplet animeret scene, et geometrisk m\o nster, en rekursiv fraktal eller et moir\'{e}-interferensm\o nster kan v\ae re i f\aa\ S-udtryk. Dette er ikke en begr\ae nsning men et designvalg: \kidlisp{} udelader brugerdefinerede funktioner, rekursion (undtagen gennem \texttt{later}), mutable datastrukturer og imports. Programmer er flade sekvenser af tegnekommandoer, l\o kker og betingelser.
218
+
219
+
Denne fladhed skaber en mulighed. Hvis kildekoden til et program kan v\ae re p\aa\ et kort, og det visuelle output af det program kan v\ae re p\aa\ det samme kort, s\aa\ bliver kortet en selvst\ae ndig artefakt: et program du kan holde, give til nogen, s\ae tte p\aa\ en v\ae g eller sende med posten. Kortet er b\aa de dokumentation og eksekverbart. Det er et \emph{partitur}---instruktioner til at producere en visuel begivenhed.
220
+
221
+
Denne artikel beskriver KidLisp Cards-formatet (\S\ref{sec:format}), offline-renderingspipelinen (\S\ref{sec:pipeline}), det aktuelle kortkatalog (\S\ref{sec:catalog}), layoutvariationer og deres sociale og fysiske affordanser (\S\ref{sec:layouts}) samt spekulative fremtider for formatet (\S\ref{sec:futures}).
222
+
223
+
% ============ 2. KORTFORMATET ============
224
+
225
+
\section{Kortformatet}
226
+
\label{sec:format}
227
+
228
+
Et KidLisp-kort har tre elementer:
229
+
230
+
\begin{enumerate}
231
+
\item \textbf{Titel.} Et kort navn der fremkalder det visuelle output: ``Starburst,'' ``Honeycomb,'' ``Spiral Walk.''
232
+
\item \textbf{Renderet output.} Et pixel-art-billede (160$\times$120 standardopl\o sning, opskaleret 3$\times$ med nearest-neighbor-interpolation for at bevare skarpe kanter).
233
+
\item \textbf{Kildekode.} Det komplette \kidlisp{}-program, typisk 1--4 linjer, vist i monospace under billedet.
234
+
\end{enumerate}
235
+
236
+
Kortet er selvst\ae ndigt: enhver der l\ae ser kildekoden kan reproducere billedet pr\ae cist, i enhver \kidlisp{}-fortolker. Der er ingen eksterne afh\ae ngigheder, ingen imports, ingen konfiguration. Programmet \emph{er} kortet.
237
+
238
+
\subsection{Kortdimensioner}
239
+
240
+
Det renderede billede fylder et 160$\times$120 pixel-l\ae rred (4:3-format), svarende til standard \kidlisp{}-opl\o sningen. Ved 3$\times$ opskalering producerer dette et 480$\times$360 pixel-billede egnet til sk\ae rmvisning. Til tryk er kort dimensioneret som 4$\times$6 tommer (standard kartotekskort / postkort), med billedet i den \o vre del og kildekoden nedenunder.
241
+
242
+
\subsection{Hvad g\o r et godt kort}
243
+
244
+
Ikke ethvert \kidlisp{}-program giver et godt kort. De bedste kort deler egenskaber:
245
+
246
+
\begin{itemize}
247
+
\item \textbf{Korthed.} 1--4 linjer. Hvis kildekoden ikke passer komfortabelt under billedet, er programmet for langt til formatet.
248
+
\item \textbf{Overraskelse.} Outputtet b\o r v\ae re mere komplekst eller smukt end kildekoden antyder. Et tre-linjers program der producerer et moir\'{e}-m\o nster belønner n\ae rmere inspektion.
249
+
\item \textbf{L\ae sbarhed.} En l\ae ser b\o r kunne f\o lge fra kilde til output uden at k\o re programmet. Forbindelsen mellem kode og billede b\o r v\ae re synlig, selv om den ikke er umiddelbart indlysende.
250
+
\item \textbf{Uafh\ae ngighed.} Ingen \texttt{\$code}-indlejringer, ingen ekstern tilstand. Kortet skal fungere isoleret.
251
+
\end{itemize}
252
+
253
+
\begin{figure}[t]
254
+
\centering
255
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-starburst.png}}%
256
+
\hfill%
257
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-moire.png}}
258
+
\caption{To programkort renderet af Python-fortolkeren: ``Starburst'' (72 radiale linjer, 3 linjer kode) og ``Moir\'{e}'' (overlappende koncentriske cirkler, 3 linjer). Disse er trivielle eksempler---de demonstrerer kortformatets struktur men repr\ae senterer ikke sprogets udtryksevne eller formatets ambitioner.}
259
+
\label{fig:program-cards}
260
+
\end{figure}
261
+
262
+
% ============ 3. RENDERINGSPIPELINE ============
263
+
264
+
\section{Offline-renderingspipeline}
265
+
\label{sec:pipeline}
266
+
267
+
KidLisp-kort renderes med en Python-fortolker der k\o rer uden for browseren. Dette muligg\o r batch-rendering, trykproduktion og notesbog-baseret kuratering uden at kr\ae ve den fulde Aesthetic\acdot Computer-runtime.
268
+
269
+
\subsection{Python-fortolkeren}
270
+
271
+
Fortolkeren (\texttt{notebooks/ac.py}, 452 linjer) implementerer en delm\ae ngde af \kidlisp{} tilstr\ae kkelig til statisk kortrendering:
272
+
273
+
\begin{itemize}
274
+
\item \textbf{Tegning:} \texttt{wipe}, \texttt{ink}, \texttt{line}, \texttt{box}, \texttt{circle}, \texttt{tri}, \texttt{plot}, \texttt{shape}, \texttt{flood}
275
+
\item \textbf{Skildpadde:} \texttt{crawl}, \texttt{left}, \texttt{right}, \texttt{goto}, \texttt{face}, \texttt{up}, \texttt{down}
276
+
\item \textbf{Kontrol:} \texttt{repeat}, \texttt{if}, \texttt{def}, \texttt{later}, \texttt{do}
277
+
\item \textbf{Matematik:} fuld aritmetik, trigonometri, \texttt{abs}, \texttt{sqrt}, \texttt{min}, \texttt{max}
278
+
\item \textbf{L\ae rred:} \texttt{resolution}, \texttt{fill}, \texttt{outline}, \texttt{stroke}
279
+
\end{itemize}
280
+
281
+
Fortolkeren bruger PIL (Pillow) til rendering. Hvert kort tegnes p\aa\ et RGBA-l\ae rred, opskaleres med nearest-neighbor-interpolation og eksporteres som PNG. Python-implementeringen er bevidst simplere end browser-evaluatoren (15.161 linjer)---den udelader animation, lyd, indlejring og timing-syntaks og fokuserer udelukkende p\aa\ den delm\ae ngde der er n\o dvendig for statisk visuelt output.
282
+
283
+
\subsection{Jupyter Notebook-arbejdsgang}
284
+
285
+
Det prim\ae re kurateringsv\ae rkt\o j er en Jupyter-notesbog (\texttt{notebooks/kidlisp-cards.ipynb}). Funktionen \texttt{show\_card()} renderer et program og viser det inline som et HTML-kort:
286
+
287
+
\begin{lstlisting}[language=python,basicstyle=\ttfamily\footnotesize]
288
+
show_card("Starburst", """(wipe black)
289
+
(ink white)
290
+
(repeat 72 i
291
+
(line 80 60
292
+
(+ 80 (* 55 (cos (* i 0.087))))
293
+
(+ 60 (* 55 (sin (* i 0.087))))))""")
294
+
\end{lstlisting}
295
+
296
+
Hvert kald producerer et kort med m\o rk baggrund med titel, renderet billede og kildekode vist inline. Notesbogen fungerer b\aa de som udviklingsmilj\o\ og galleri---at scrolle gennem notesbogen er som at bladre i et s\ae t kort.
297
+
298
+
\subsection{To fortolkere, \'{e}t sprog}
299
+
300
+
Eksistensen af to uafh\ae ngige fortolkere (JavaScript i browseren, Python i notesbogen) tjener som en krydsvalideringsmekanisme. Hvis et program renderes identisk i begge, er dets adf\ae rd bestemt udelukkende af sprogets semantik snarere end implementeringsdetaljer. Programmer der afh\ae nger af browserspecifikke funktioner (animation, lyd, indlejrede lag) udelukkes fra kortformatet pr. konstruktion---de renderer simpelthen ikke i Python-fortolkeren.
301
+
302
+
% ============ 4. KORTKATALOG ============
303
+
304
+
\section{Kortkataloget}
305
+
\label{sec:catalog}
306
+
307
+
Den aktuelle notesbog indeholder 28 kort organiseret i syv kategorier. Hver kategori udforsker et andet aspekt af sproget gennem minimale eksempler. Disse programmer er bevidst trivielle---tegne\o velser, matematiske illustrationer, skildpaddeg\aa ture. De etablerer kortformatets struktur men repr\ae senterer ikke dets udtryksm\ae ssige potentiale. De interessante kort er endnu ikke lavet. Formatets v\ae rdi vil fremkomme fra programmer der bruger korthed til at sige noget v\ae rd at sige, ikke fra geometriske demoer.
308
+
309
+
\subsection{Linjer}
310
+
311
+
Linjekort demonstrerer \texttt{repeat} og trigonometri. En stjerneburst udsender 72 linjer fra centrum. En krydsarkering overlejrer vandrette og lodrette gitre med lav opacitet.
312
+
313
+
\begin{figure}[h]
314
+
\centering
315
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-starburst.png}}%
316
+
\hfill%
317
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-crosshatch.png}}
318
+
\caption{``Starburst'' og ``Crosshatch'' --- linjekort.}
319
+
\label{fig:lines}
320
+
\end{figure}
321
+
322
+
\begin{lstlisting}
323
+
; Starburst — 72 radial lines
324
+
(wipe |\kt{black}|)
325
+
(ink |\kt{white}|)
326
+
(repeat |\kn{72}| |\kv{i}|
327
+
(line |\kn{80}| |\kn{60}|
328
+
(|\km{+}| |\kn{80}| (|\km{*}| |\kn{55}| (|\km{cos}| (|\km{*}| |\kv{i}| |\kn{0.087}|))))
329
+
(|\km{+}| |\kn{60}| (|\km{*}| |\kn{55}| (|\km{sin}| (|\km{*}| |\kv{i}| |\kn{0.087}|))))))
330
+
\end{lstlisting}
331
+
332
+
\subsection{Cirkler}
333
+
334
+
Cirkelkort bruger \texttt{outline}-tilstand og indlejrede \texttt{repeat}-l\o kker. ``Ripple'' tegner 30 koncentriske cirkler med bl\aa skiftende farve.
335
+
336
+
\begin{figure}[h]
337
+
\centering
338
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-ripple.png}}%
339
+
\hfill%
340
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-mondrian.png}}
341
+
\caption{``Ripple'' (cirkler) og ``Mondrian'' (bokse).}
342
+
\label{fig:circles-boxes}
343
+
\end{figure}
344
+
345
+
\subsection{Bokse \& komposition}
346
+
347
+
``Mondrian'' genskaber det prim\ae rfarvede gitter med fire farvede rektangler. ``Nest'' tegner 10 indrykkede rektangler med skiftende nuancer.
348
+
349
+
\subsection{Matematik \& kurver}
350
+
351
+
Disse kort bruger \texttt{plot} med matematiske funktioner. ``Lissajous'' tegner en Lissajous-figur med 600 punkter. ``Spiral'' plotter en pol\ae r spiral.
352
+
353
+
\begin{figure}[h]
354
+
\centering
355
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-lissajous.png}}%
356
+
\hfill%
357
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-sierpinski.png}}
358
+
\caption{``Lissajous'' (matematiske kurver) og ``Sierpinski'' (bitwise AND-fraktal).}
359
+
\label{fig:math}
360
+
\end{figure}
361
+
362
+
\subsection{Farve \& gradienter}
363
+
364
+
``Sierpinski'' bruger bitwise AND til at generere Sierpinski-trekanten: \texttt{(if (= 0 (\& x y)) (plot (+ 16 x) y))}. ``Sunflower'' plotter 500 punkter langs en gylden-vinkel-spiral med cykliske farver.
365
+
366
+
\subsection{Skildpaddegrafik}
367
+
368
+
Skildpaddekort bruger \texttt{crawl}, \texttt{left}, \texttt{right} og \texttt{face}. En femtakket stjerne bruger \texttt{(right 144)}. Et tr\ae\ bruger \texttt{later} til rekursiv forgrening. En snefnug indlejrer Koch-kurvesegmenter.
369
+
370
+
\begin{figure}[h]
371
+
\centering
372
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-star.png}}%
373
+
\hfill%
374
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-tree.png}}
375
+
\caption{``Star'' og ``Tree'' --- skildpaddegrafikkort.}
376
+
\label{fig:turtle}
377
+
\end{figure}
378
+
379
+
\begin{lstlisting}
380
+
; Star — 5 sides, 144-degree turns
381
+
(wipe |\kt{navy}|)
382
+
(ink |\kt{yellow}|)
383
+
(repeat |\kn{5}| |\kv{i}| (crawl |\kn{50}|) (right |\kn{144}|))
384
+
\end{lstlisting}
385
+
386
+
\subsection{Minimale koaner}
387
+
388
+
De korteste kort i s\ae ttet. ``Horizon'' er tre linjer: m\o rk himmel, gylden jord. ``Pip'' er en enkelt r\o d prik p\aa\ sort. Disse kort n\ae rmer sig det minimale levedygtige program---den mindste m\ae ngde kode der producerer et genkendeligt billede.
389
+
390
+
\begin{figure}[h]
391
+
\centering
392
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-horizon.png}}%
393
+
\hfill%
394
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-pip.png}}
395
+
\caption{``Horizon'' og ``Pip'' --- minimale koaner (2--3 linjer hver).}
396
+
\label{fig:koans}
397
+
\end{figure}
398
+
399
+
\begin{lstlisting}
400
+
; Pip — the minimum card
401
+
(wipe |\kt{black}|)
402
+
(ink |\kt{red}|)
403
+
(circle |\kn{80}| |\kn{60}| |\kn{4}|)
404
+
\end{lstlisting}
405
+
406
+
\begin{figure*}[t]
407
+
\centering
408
+
\fbox{\includegraphics[height=5.5cm]{card-nest.png}}%
409
+
\hfill%
410
+
\fbox{\includegraphics[height=5.5cm]{card-sunflower.png}}%
411
+
\hfill%
412
+
\fbox{\includegraphics[height=5.5cm]{card-snowflake.png}}%
413
+
\hfill%
414
+
\fbox{\includegraphics[height=5.5cm]{card-spiral.png}}
415
+
\caption{Fire komplette kort der viser formatet: titel, renderet output og kildekode. Fra venstre mod h\o jre: ``Nest,'' ``Sunflower,'' ``Snowflake,'' ``Spiral.'' Hvert kort er selvst\ae ndigt---kildekoden under billedet er det komplette program. Disse er trivielle tegne\o velser, ikke udtryk for formatets potentiale.}
416
+
\label{fig:four-cards}
417
+
\end{figure*}
418
+
419
+
% ============ 5. LAYOUTS ============
420
+
421
+
\section{Layouts}
422
+
\label{sec:layouts}
423
+
424
+
Kortformatet har intet fast layout. Hvordan de tre elementer (titel, output, kilde) arrangeres bestemmer hvad kortet afforderer---hvad du kan g\o re med det fysisk og socialt. Dette afsnit udforsker layoutvariationer og deres konsekvenser.
425
+
426
+
\begin{figure*}[t]
427
+
\centering
428
+
\includegraphics[width=\textwidth]{layout-comparison.png}
429
+
\caption{Tre layoutstrategier. \textbf{Vertikal:} titel / billede / kilde stablet fra top til bund, optimeret til telefonsk\ae rme og portr\ae ttryk. \textbf{Horisontal:} billede til venstre, titel og kilde til h\o jre, velegnet til landskabskort og side-om-side-gennemsyn. \textbf{Postkort:} renderet output p\aa\ forsiden, kildekode og metadata p\aa\ bagsiden---et kort der kan sendes med posten, hvor programmet er skjult indtil man vender det.}
430
+
\label{fig:layouts}
431
+
\end{figure*}
432
+
433
+
\subsection{Vertikal (sk\ae rm / tryk)}
434
+
435
+
Standardlayoutet stabler titel, billede og kilde fra top til bund. Dette er notesbog-layoutet---det scroller naturligt p\aa\ en telefon eller i en Jupyter-notesbog. Til tryk passer det til et 4$\times$6 tommers kort i portr\ae tformat. L\ae serens \o je bev\ae ger sig nedad fra navn til billede til kode og f\o lger forholdet mellem programmet og dets output.
436
+
437
+
\subsection{Horisontal (s\ae t / landskab)}
438
+
439
+
Et landskabslayout placerer det renderede billede til venstre og kildekoden til h\o jre. Dette fungerer til at sprede kort ud over et bord, til pr\ae sentationer og til sammenligning side om side. To kort placeret ved siden af hinanden skaber et diptyk---betragteren kan sammenligne programmer og output samtidigt.
440
+
441
+
\subsection{Postkort (postkunst)}
442
+
443
+
Postkortlayoutet adskiller forside fra bagside. Forsiden viser kun det renderede billede, fuld udblødning, ingen tekst. Bagsiden viser kildekoden, forfatterens handle, kortkoden (\texttt{\$xyz}) og et frim\ae rkeomr\aa de. Modtageren ser billedet f\o rst---en visuel artefakt. At vende kortet afsl\o rer programmet: instruktionerne der producerede det. Kortet er b\aa de kunstobjekt og eksekverbart partitur, afh\ae ngigt af hvilken side man l\ae ser.
444
+
445
+
\begin{figure*}[h]
446
+
\centering
447
+
\includegraphics[width=\textwidth]{layout-affordances.png}
448
+
\caption{Sociale og fysiske affordanser ved kortformatet. Hver affordans f\o lger af kortets materialitet: det kan \textbf{deles} fra h\aa nd til h\aa nd, \textbf{sendes} som postkort, \textbf{byttes} og samles, \textbf{undervises} fra i p\ae dagogiske sekvenser, \textbf{opf\o res} som et grafisk partitur eller \textbf{s\ae ttes op} p\aa\ en galleriv\ae g.}
449
+
\label{fig:affordances}
450
+
\end{figure*}
451
+
452
+
\subsection{S\ae tarrangementer}
453
+
454
+
Kort er ikke enkeltobjekter. De danner s\ae t, og arrangementet af et s\ae t skaber mening. En \emph{p\ae dagogisk sekvens} ordner kort efter koncept: bokse f\o rst (koordinater), derefter linjer (trigonometri), derefter cirkler (radius og gentagelse), derefter matematiske kurver (plot og sinus), derefter skildpaddegrafik (relativ bev\ae gelse) og til sidst koaner (minimalt udtryk). Et \emph{gallerigitter} arrangerer kort rumligt p\aa\ en v\ae g og inviterer til sammenligning p\aa\ tv\ae rs af kategorier. Et \emph{blandet s\ae t} randomiserer r\ae kkef\o lgen og producerer uventede sammenstillinger mellem en fraktal og en horisont, mellem et tr\ae\ og en prik.
455
+
456
+
\begin{figure}[h]
457
+
\centering
458
+
\includegraphics[width=\columnwidth]{layout-decks.png}
459
+
\caption{S\ae tarrangementer. Venstre: kort spredt ud efter kategori (linjer, cirkler, bokse, matematik, skildpadde, koaner) med flere kort stablet per kategori. H\o jre: et gallerigitter hvor kort er arrangeret rumligt til gennemsyn.}
460
+
\label{fig:decks}
461
+
\end{figure}
462
+
463
+
% ============ 6. KORT I DEN VIRKELIGE VERDEN ============
464
+
465
+
\section{Kort i den virkelige verden}
466
+
\label{sec:wild}
467
+
468
+
Notesbogskortene er \o velser. Det egentlige \kidlisp{}-korpus---16.000+ programmer skabt af 59 forfattere---indeholder v\ae rker der bruger den fulde runtime: animation, lyd, indlejrede lag, gradientfading, tilf\ae ldig placering og timing-syntaks. Disse v\ae rker er korte nok til kortformatet men langt mere udtryksfulde end notesbog-eksemplerne. Deres forh\aa ndsvisningsbilleder renderes af oven-tjenesten (Puppeteer-baseret sk\ae rmoptagelse) og serveres via CDN.
469
+
470
+
\begin{figure*}[t]
471
+
\centering
472
+
\includegraphics[height=7cm]{user-card-bop.png}%
473
+
\hfill%
474
+
\includegraphics[height=7cm]{user-card-roz.png}%
475
+
\hfill%
476
+
\includegraphics[height=7cm]{user-card-cow.png}%
477
+
\hfill%
478
+
\includegraphics[height=7cm]{user-card-r2f.png}
479
+
\caption{Fire kort fra det levende \kidlisp{}-korpus, renderet af oven-tjenesten. Fra venstre mod h\o jre: \texttt{\$bop} (12.188 afspilninger---det mest popul\ae re v\ae rk, 4 linjer), \texttt{\$roz} (7.064 afspilninger, 3 linjer), \texttt{\$cow} (5.980 afspilninger---en komposition der indlejrer to andre v\ae rker via \texttt{\$39i} og \texttt{\$r2f}), \texttt{\$r2f} (4.413 afspilninger, 3 linjer med tilf\ae ldig boksplacering). Alle af @jeffrey. Disse programmer bruger funktioner der ikke findes i Python-fortolkeren---animation, tilf\ae ldighed (\texttt{?}), gradientfading (\texttt{fade:}), indlejrede lag (\texttt{\$code})---men deres kildekode passer stadig p\aa\ et kort.}
480
+
\label{fig:user-cards}
481
+
\end{figure*}
482
+
483
+
\subsection{Hvad rigtige v\ae rker tilf\o jer}
484
+
485
+
Notesbogskortene bruger en statisk delm\ae ngde af \kidlisp{}. Rigtige v\ae rker p\aa\ \texttt{kidlisp.com} bruger den fulde runtime:
486
+
487
+
\begin{itemize}
488
+
\item \textbf{Animation.} Programmer re-evalueres hvert frame. \texttt{frame} og \texttt{time} \ae ndres automatisk. Et enkelt-frame-sk\ae rmbillede fanger \'{e}t \o jeblik af et levende v\ae rk.
489
+
\item \textbf{Tilf\ae ldighed.} \texttt{?}-operatoren producerer en tilf\ae ldig v\ae rdi fra en liste hvert frame. \texttt{(ink (? red blue green))} flimrer mellem farver.
490
+
\item \textbf{Gradientfading.} \texttt{fade:red-blue-black} interpolerer en fler-stops-gradient over l\ae rredet, drevet af \texttt{frame}-t\ae llingen. \'{E}t udtryk erstatter sider af manuel farvematematik.
491
+
\item \textbf{Indlejring.} \texttt{(\$cow)} henter v\ae rket \texttt{cow} fra MongoDB, evaluerer det i en offscreen-buffer og sammens\ae tter resultatet. V\ae rker bygger p\aa\ v\ae rker.
492
+
\item \textbf{Timing.} \texttt{1s... (zoom 0.5)} anvender en zoom hvert sekund. Ingen eksplicit animationsl\o kke.
493
+
\end{itemize}
494
+
495
+
Disse funktioner holder programmer korte mens de dramatisk udvider hvad de kan udtrykke. \texttt{\$bop}---det mest afspillede v\ae rk med 12.188 visninger---er fire linjer: en lilla baggrund, regnbueflikrende bl\ae k, en tilf\ae ldig linje og en sl\o ring. P\aa\ et kort ligner det et frosset \o jeblik af et kinetisk maleri. I browseren er det \'{e}t.
496
+
497
+
\subsection{Kortet som \o jebliksbillede}
498
+
499
+
Et kort af et animeret v\ae rk er n\o dvendigvis ufuldst\ae ndigt. Det fanger \'{e}t frame af en temporal proces. Denne ufuldst\ae ndighed er en del af formatet: kortet inviterer dig til at taste koden og se hvad den rent faktisk g\o r. Det statiske billede er et l\o fte. Kildekoden er opfyldelsen. Kortkoden (\texttt{\$bop}) er broen---tast den ind p\aa\ \texttt{kidlisp.com} og kortet kommer til live.
500
+
501
+
% ============ 7. HVAD KORT KUNNE BLIVE ============
502
+
503
+
\section{Hvad kort kunne blive}
504
+
\label{sec:futures}
505
+
506
+
Kortformatet er ungt. Den aktuelle notesbog er et proof of concept---28 programmer renderet offline. Men korrespondancen mellem korte programmer og fysiske kort antyder flere retninger.
507
+
508
+
\subsection{Byttekort}
509
+
510
+
Et KidLisp-kort er samlev\ae rdigt p\aa\ en m\aa de som det meste software ikke er. Hvert kort har et navn, en visuel identitet, en kortkode (\texttt{\$xyz}) og en forfatter. Kort kunne trykkes, nummereres og byttes. Sj\ae ldne kort kunne bruge obskure sprogfunktioner eller producere uventet komplekst output fra minimal kode. ``Sj\ae ldenheden'' af et kort er dets informationst\ae thed: hvor meget visuel kompleksitet der opst\aa r fra hvor f\aa\ tegn.
511
+
512
+
\subsection{P\ae dagogiske sekvenser}
513
+
514
+
De syv kategorier i den aktuelle notesbog antyder en undervisningsr\ae kkef\o lge: start med bokse (simple koordinater), g\aa\ videre til linjer (trigonometri), cirkler (radius og gentagelse), matematiske kurver (plot og sinus), skildpaddegrafik (relativ bev\ae gelse) og til sidst koaner (minimalt udtryk). Hvert kort underviser i \'{e}t koncept. En l\ae rer kunne give elever et fysisk s\ae t og bede dem reproducere hvert kort, modificere det eller skabe et nyt kort i samme kategori.
515
+
516
+
\subsection{Trykte partiturer}
517
+
518
+
I musik er et partitur instruktioner til at producere en temporal begivenhed. Et KidLisp-kort er instruktioner til at producere en visuel begivenhed. Kort kunne fungere som grafiske partiturer i traditionen fra Cornelius Cardew, John Cage og Fluxus-begivenhedspartiturer. En opf\o rer modtager et kort, fortolker koden (ved at taste den ind p\aa\ \texttt{kidlisp.com}, ved at l\ae se den h\o jt, ved at tegne den i h\aa nden) og producerer en begivenhed. Kortet er partituret. Renderingen er \'{e}n mulig realisering.
519
+
520
+
\subsection{Postkunst}
521
+
522
+
Ved 4$\times$6 tommer er et KidLisp-kort et postkort. Forsiden viser det renderede billede. Bagsiden viser kildekoden, forfatterens handle og kortkoden til at sl\aa\ det op online. Postkunst med eksekverbart indhold---modtageren kan taste koden og se billedet genskabt p\aa\ deres sk\ae rm. Det fysiske kort og det digitale program er det samme v\ae rk i to medier.
523
+
524
+
\subsection{Generativt papirvarer}
525
+
526
+
Fordi Python-fortolkeren er deterministisk og selvst\ae ndig, kan kort batch-renderes til trykproduktion uden netv\ae rksadgang. Et s\ae t kort kunne trykkes som et h\ae fte, et zine eller et s\ae t i \ae ske. Pipelinen \texttt{cards-convert.mjs} producerer allerede 4$\times$6 tommers PDF-kort fra papirformatet; at udvide dette til at inkludere renderet programoutput sammen med kildekode er et naturligt n\ae ste skridt.
527
+
528
+
\subsection{Begr\ae nsning som generativt princip}
529
+
530
+
Den mest interessante konsekvens af kortformatet er hvordan det p\aa virker sproget. Programmer der ikke passer p\aa\ et kort antyder manglende abstraktioner---eller antyder at programmet g\o r for meget. Kortbegr\ae nsningen opmuntrer til \o konomi: find tre-linjers-programmet der producerer det mest interessante billede. Dette er en generativ begr\ae nsning i Oulipo-traditionen---vilk\aa rlige formelle restriktioner der producerer uventede kreative resultater.
531
+
532
+
% ============ 6. RELATERET ARBEJDE ============
533
+
534
+
\section{Relateret arbejde}
535
+
536
+
\textbf{Trykt kode.} Demoscene-traditionen med ``sizecoding'' (programmer under 256 bytes) deler \ae stetikken med minimale programmer der producerer maksimalt output. \kidlisp{}-kort er t\ae ttere p\aa\ ``kodedigt''-traditionen, hvor selve kildekoden l\ae ses som tekst sammen med dens output.
537
+
538
+
\textbf{Grafiske partiturer.} Cardews \emph{Treatise} (1967) og Cages \emph{Notations} (1969) etablerede at visuel notation kan tjene som opf\o relsesinstruktioner uden at foreskrive en specifik realisering. KidLisp-kort adskiller sig ved at de er fuldt eksekverbare---renderingen er deterministisk, ikke \aa ben for fortolkning. Men kort-som-partitur-indramningen inviterer til genfortolkning: hvad nu hvis man ``spiller'' kortet anderledes hver gang?
539
+
540
+
\textbf{Byttekortspil.} Spil som \emph{Magic: The Gathering} (1993) demonstrerede at kort med strukturerede metadata (navn, type, regeltekst, kunst) skaber rige kombinatoriske rum. KidLisp-kort har naturlige metadata (titel, kategori, funktionsantal, linjeantal, output-kompleksitet) der kunne underst\o tte lignende spilmekanikker.
541
+
542
+
\textbf{Beregningsmæssige notesbøger.} Jupyter-notesbøger kombinerer allerede kode og output. KidLisp Cards-notesbogen er en Jupyter-notesbog, men med en specifik begr\ae nsning: hver celle er et selvst\ae ndigt kort snarere end et trin i en l\ae ngere beregning. Notesbogen er et galleri, ikke en fort\ae lling.
543
+
544
+
% ============ 7. KONKLUSION ============
545
+
546
+
\section{Konklusion}
547
+
548
+
KidLisp-kort udspringer af en simpel observation: n\aa r programmer er korte nok, passer de p\aa\ kort. Kortformatet---titel, billede, kilde---g\o r programmer til fysiske artefakter der kan trykkes, sendes med posten, samles, undervises fra og opf\o res. Python-renderingspipelinen muligg\o r offline batchproduktion. Kataloget med syv kategorier giver et kurateret indgangspunkt til sproget.
549
+
550
+
Formatet er et igangv\ae rende arbejde. Det aktuelle s\ae t p\aa\ 28 kort er et udgangspunkt, ikke en f\ae rdig samling. Sp\o rgsm\aa let er ikke hvor mange kort der skal laves, men hvilke programmer der fortjener at v\ae re kort---hvilke tre-linjers kompositioner der producerer billeder v\ae rd at holde i h\aa nden.
551
+
552
+
Notesbogen, fortolkeren og kortkataloget er tilg\ae ngelige p\aa\ \url{https://github.com/whistlegraph/aesthetic-computer}. Programmer kan oprettes og deles p\aa\ \url{https://kidlisp.com}.
553
+
554
+
\vspace{0.5em}
555
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
556
+
557
+
% ============ REFERENCER ============
558
+
559
+
\bibliographystyle{plainnat}
560
+
\bibliography{references}
561
+
562
+
\end{document}
+562
papers/arxiv-kidlisp-cards/kidlisp-cards-es.tex
+562
papers/arxiv-kidlisp-cards/kidlisp-cards-es.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
11
+
\setmainfont{Latin Modern Roman}
12
+
\setsansfont{Latin Modern Sans}
13
+
14
+
% Custom AC fonts
15
+
\newfontfamily\acbold{ywft-processing-bold}[
16
+
Path=../../system/public/type/webfonts/,
17
+
Extension=.ttf
18
+
]
19
+
\newfontfamily\aclight{ywft-processing-light}[
20
+
Path=../../system/public/type/webfonts/,
21
+
Extension=.ttf
22
+
]
23
+
\newfontfamily\kidlispfont{ComicRelief-Regular}[
24
+
Path=../arxiv-kidlisp/fonts/,
25
+
Extension=.ttf
26
+
]
27
+
\newfontfamily\kidlispbold{ComicRelief-Bold}[
28
+
Path=../arxiv-kidlisp/fonts/,
29
+
Extension=.ttf
30
+
]
31
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
32
+
33
+
% === PACKAGES ===
34
+
\usepackage{xcolor}
35
+
\usepackage{titlesec}
36
+
\usepackage{enumitem}
37
+
\usepackage{booktabs}
38
+
\usepackage{tabularx}
39
+
\usepackage{fancyhdr}
40
+
\usepackage{hyperref}
41
+
\usepackage{graphicx}
42
+
\graphicspath{{figures/}{../arxiv-kidlisp/figures/}}
43
+
\usepackage{ragged2e}
44
+
\usepackage{microtype}
45
+
\usepackage{listings}
46
+
\usepackage{natbib}
47
+
\usepackage[colorspec=0.92]{draftwatermark}
48
+
49
+
% === COLORS (AC palette) ===
50
+
\definecolor{acpink}{RGB}{180,72,135}
51
+
\definecolor{acpurple}{RGB}{120,80,180}
52
+
\definecolor{acdark}{RGB}{64,56,74}
53
+
\definecolor{acgray}{RGB}{119,119,119}
54
+
\definecolor{klbrand}{RGB}{205,92,155}
55
+
\definecolor{klcyan}{RGB}{112,214,255}
56
+
\definecolor{kldark}{RGB}{48,43,58}
57
+
\definecolor{draftcolor}{RGB}{205,92,155}
58
+
59
+
% === DRAFT WATERMARK ===
60
+
\DraftwatermarkOptions{
61
+
text=BORRADOR,
62
+
fontsize=3cm,
63
+
color=draftcolor!18,
64
+
angle=45,
65
+
pos={0.5\paperwidth, 0.5\paperheight}
66
+
}
67
+
68
+
% === KIDLISP SYNTAX COLORS ===
69
+
\definecolor{klfn}{RGB}{0,136,170}
70
+
\definecolor{klform}{RGB}{119,51,170}
71
+
\definecolor{klrepeat}{RGB}{170,0,170}
72
+
\definecolor{klnum}{RGB}{204,0,102}
73
+
\definecolor{klstr}{RGB}{170,120,0}
74
+
\definecolor{klcmt}{RGB}{102,102,102}
75
+
\definecolor{klmath}{RGB}{0,136,0}
76
+
\definecolor{klvar}{RGB}{204,102,0}
77
+
\definecolor{klembed}{RGB}{0,136,0}
78
+
79
+
% KidLisp inline color macros
80
+
\newcommand{\kn}[1]{\textcolor{klnum}{#1}}
81
+
\newcommand{\kt}[1]{\textcolor{klstr}{#1}}
82
+
\newcommand{\kv}[1]{\textcolor{klvar}{#1}}
83
+
\newcommand{\ke}[1]{\textcolor{klembed}{\textbf{#1}}}
84
+
\newcommand{\km}[1]{\textcolor{klmath}{#1}}
85
+
86
+
% === HYPERREF ===
87
+
\hypersetup{
88
+
colorlinks=true,
89
+
linkcolor=acpurple,
90
+
urlcolor=acpurple,
91
+
citecolor=acpurple,
92
+
pdfauthor={@jeffrey},
93
+
pdftitle={Tarjetas KidLisp: Programas que caben en una tarjeta},
94
+
}
95
+
96
+
% === SECTION FORMATTING ===
97
+
\titleformat{\section}
98
+
{\normalfont\bfseries\normalsize\uppercase}
99
+
{\thesection.}
100
+
{0.5em}
101
+
{}
102
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
103
+
104
+
\titleformat{\subsection}
105
+
{\normalfont\bfseries\small}
106
+
{\thesubsection}
107
+
{0.5em}
108
+
{}
109
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
110
+
111
+
% === HEADER/FOOTER ===
112
+
\pagestyle{fancy}
113
+
\fancyhf{}
114
+
\renewcommand{\headrulewidth}{0pt}
115
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{Borrador de trabajo --- no citar}}
116
+
\fancyfoot[C]{\footnotesize\thepage}
117
+
118
+
% === CUSTOM COMMANDS ===
119
+
\newcommand{\acdot}{{\color{acpink}.}}
120
+
\newcommand{\kidlisp}{\textsc{KidLisp}}
121
+
122
+
% === LISTINGS ===
123
+
\lstdefinelanguage{kidlisp}{
124
+
morekeywords=[1]{wipe,ink,line,box,circle,tri,plot,flood,shape,zoom,scroll,spin,blur,contrast,embed,layer,width,height,frame,time,wiggle,melody,mic,suck,sort,form,trans,cube,move,scale,hop,overtone,resolution,write,text,type,stamp,paste,point,poly,noise,fade,pan,unpan,mask,unmask,flip,crawl,left,right,up,down,goto,face,outline,fill,stroke},
125
+
morekeywords=[2]{def,let,if,cond,once,later,lambda,do},
126
+
morekeywords=[3]{repeat},
127
+
morekeywords=[4]{random,sin,cos,tan,floor,ceil,round,abs,sqrt,min,max},
128
+
sensitive=true,
129
+
morecomment=[l]{;},
130
+
morestring=[b]",
131
+
escapeinside={|}{|},
132
+
}
133
+
\lstset{
134
+
language=kidlisp,
135
+
basicstyle=\ttfamily\small,
136
+
keywordstyle=[1]\color{klfn}\bfseries,
137
+
keywordstyle=[2]\color{klform}\bfseries,
138
+
keywordstyle=[3]\color{klrepeat}\bfseries,
139
+
keywordstyle=[4]\color{klmath},
140
+
commentstyle=\color{klcmt}\itshape,
141
+
stringstyle=\color{klstr},
142
+
breaklines=true,
143
+
frame=single,
144
+
rulecolor=\color{acgray!30},
145
+
backgroundcolor=\color{acgray!5},
146
+
xleftmargin=0.5em,
147
+
xrightmargin=0.5em,
148
+
aboveskip=0.5em,
149
+
belowskip=0.5em,
150
+
}
151
+
152
+
\lstdefinelanguage{python}{
153
+
morekeywords={def,return,import,from,class,if,else,for,in,with,as,try,except,None,True,False,self,and,or,not,lambda,yield,pass,break,continue,raise,while},
154
+
sensitive=true,
155
+
morecomment=[l]{\#},
156
+
morestring=[b]",
157
+
morestring=[b]',
158
+
}
159
+
\lstset{
160
+
language=kidlisp,
161
+
}
162
+
163
+
% === LIST SETTINGS ===
164
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
165
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
166
+
167
+
% === COLUMN SEPARATION ===
168
+
\setlength{\columnsep}{1.8em}
169
+
170
+
% === PARAGRAPH SETTINGS ===
171
+
\setlength{\parindent}{1em}
172
+
\setlength{\parskip}{0.3em}
173
+
174
+
\tolerance=800
175
+
\emergencystretch=1em
176
+
\hyphenpenalty=50
177
+
178
+
\begin{document}
179
+
180
+
% ============ TITLE BLOCK ============
181
+
182
+
\twocolumn[{%
183
+
\begin{center}
184
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
185
+
{\kidlispbold\fontsize{24pt}{28pt}\selectfont\color{kldark} Kid{\color{klbrand}Lisp} Tarjetas}\par
186
+
\vspace{0.2em}
187
+
{\kidlispfont\fontsize{11pt}{13pt}\selectfont\color{klbrand} Programas que caben en una tarjeta}\par
188
+
\vspace{0.6em}
189
+
{\normalsize @jeffrey}\par
190
+
{\small\color{acgray} Aesthetic\acdot Computer}\par
191
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
192
+
\vspace{0.3em}
193
+
{\small\color{acpurple} \url{https://kidlisp.com} \enspace$\cdot$\enspace \url{https://aesthetic.computer}}\par
194
+
\vspace{0.6em}
195
+
\rule{\textwidth}{1.5pt}
196
+
\vspace{0.5em}
197
+
\end{center}
198
+
199
+
\begin{center}
200
+
{\small\color{acpink}\textbf{[ borrador de trabajo --- no citar ]}}
201
+
\end{center}
202
+
\vspace{0.3em}
203
+
204
+
\begin{quote}
205
+
\small\noindent\textbf{Resumen.}
206
+
Los programas de \kidlisp{} son cortos. Un programa t\'ipico consta de 2--4 l\'ineas de S-expresiones que producen una composici\'on visual completa---una explosi\'on estelar, una espiral, un mosaico, un fractal. Esta brevedad no es incidental sino dise\~nada: el lenguaje omite funciones definidas por el usuario, recursi\'on y mecanismos de abstracci\'on, de modo que los programas permanecen planos y legibles. Observamos que esta planitud crea una correspondencia natural entre programas y tarjetas f\'isicas. Un programa de \kidlisp{}, su c\'odigo fuente y su salida renderizada pueden coexistir en una sola tarjeta impresa. Este art\'iculo describe el formato \emph{KidLisp Cards}---una baraja de programas organizados por categor\'ia visual---y un pipeline de renderizado en Python (int\'erprete basado en PIL) que produce im\'agenes de tarjetas fuera del navegador. Discutimos qu\'e son las tarjetas ahora (un cuaderno curado de koans visuales), en qu\'e podr\'ian convertirse (tarjetas coleccionables, secuencias pedag\'ogicas, partituras impresas, arte postal), y c\'omo la restricci\'on de la tarjeta retroalimenta el dise\~no del lenguaje.
207
+
\end{quote}
208
+
\vspace{0.5em}
209
+
}]
210
+
211
+
% ============ 1. INTRODUCCI\'ON ============
212
+
213
+
\section{Introducci\'on}
214
+
215
+
La mayor\'ia de los lenguajes de programaci\'on producen programas demasiado largos para imprimir en una ficha. Esto es consecuencia de la abstracci\'on: los lenguajes de prop\'osito general fomentan la descomposici\'on en funciones, clases, m\'odulos y archivos. El programa se distribuye a trav\'es de una base de c\'odigo. Ning\'un artefacto individual captura el todo.
216
+
217
+
\kidlisp{} es diferente. Sus programas tienen t\'ipicamente 1--6 l\'ineas de largo. Una escena animada completa, un patr\'on geom\'etrico, un fractal recursivo o un patr\'on de interferencia moir\'{e} cabe en unas pocas S-expresiones. Esto no es una limitaci\'on sino una elecci\'on de dise\~no: \kidlisp{} omite funciones definidas por el usuario, recursi\'on (excepto a trav\'es de \texttt{later}), estructuras de datos mutables e importaciones. Los programas son secuencias planas de comandos de dibujo, bucles y condicionales.
218
+
219
+
Esta planitud crea una oportunidad. Si el c\'odigo fuente de un programa cabe en una tarjeta, y la salida visual de ese programa cabe en la misma tarjeta, entonces la tarjeta se convierte en un artefacto autocontenido: un programa que puedes sostener, pasar a alguien, clavar en una pared o enviar por correo. La tarjeta es tanto documentaci\'on como ejecutable. Es una \emph{partitura}---instrucciones para producir un evento visual.
220
+
221
+
Este art\'iculo describe el formato KidLisp Cards (\S\ref{sec:format}), el pipeline de renderizado offline (\S\ref{sec:pipeline}), el cat\'alogo actual de tarjetas (\S\ref{sec:catalog}), las variaciones de disposici\'on y sus affordances sociales y f\'isicas (\S\ref{sec:layouts}), y futuros especulativos para el formato (\S\ref{sec:futures}).
222
+
223
+
% ============ 2. EL FORMATO DE TARJETA ============
224
+
225
+
\section{El formato de tarjeta}
226
+
\label{sec:format}
227
+
228
+
Una tarjeta KidLisp tiene tres elementos:
229
+
230
+
\begin{enumerate}
231
+
\item \textbf{T\'itulo.} Un nombre corto que evoca la salida visual: ``Starburst,'' ``Honeycomb,'' ``Spiral Walk.''
232
+
\item \textbf{Salida renderizada.} Una imagen de pixel art (resoluci\'on predeterminada de 160$\times$120, escalada 3$\times$ con interpolaci\'on de vecino m\'as cercano para preservar bordes n\'itidos).
233
+
\item \textbf{C\'odigo fuente.} El programa \kidlisp{} completo, t\'ipicamente 1--4 l\'ineas, mostrado en monoespaciado debajo de la imagen.
234
+
\end{enumerate}
235
+
236
+
La tarjeta es autocontenida: cualquiera que lea el c\'odigo fuente puede reproducir la imagen exactamente, en cualquier int\'erprete de \kidlisp{}. No hay dependencias externas, no hay importaciones, no hay configuraci\'on. El programa \emph{es} la tarjeta.
237
+
238
+
\subsection{Dimensiones de la tarjeta}
239
+
240
+
La imagen renderizada ocupa un lienzo de 160$\times$120 p\'ixeles (proporci\'on 4:3), coincidiendo con la resoluci\'on predeterminada de \kidlisp{}. A 3$\times$ de escala, esto produce una imagen de 480$\times$360 p\'ixeles adecuada para visualizaci\'on en pantalla. Para impresi\'on, las tarjetas miden 4$\times$6 pulgadas (ficha est\'andar / postal), con la imagen en la parte superior y el c\'odigo fuente debajo.
241
+
242
+
\subsection{Qu\'e hace una buena tarjeta}
243
+
244
+
No todo programa de \kidlisp{} produce una buena tarjeta. Las mejores tarjetas comparten propiedades:
245
+
246
+
\begin{itemize}
247
+
\item \textbf{Brevedad.} 1--4 l\'ineas. Si el c\'odigo fuente no cabe c\'omodamente debajo de la imagen, el programa es demasiado largo para el formato.
248
+
\item \textbf{Sorpresa.} La salida debe ser m\'as compleja o bella de lo que sugiere el c\'odigo fuente. Un programa de tres l\'ineas que produce un patr\'on moir\'{e} recompensa la inspecci\'on.
249
+
\item \textbf{Legibilidad.} Un lector deber\'ia poder trazar desde la fuente hasta la salida sin ejecutar el programa. La conexi\'on entre c\'odigo e imagen debe ser discernible, aunque no sea inmediatamente obvia.
250
+
\item \textbf{Independencia.} Sin incrustaciones \texttt{\$code}, sin estado externo. La tarjeta debe funcionar de forma aislada.
251
+
\end{itemize}
252
+
253
+
\begin{figure}[t]
254
+
\centering
255
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-starburst.png}}%
256
+
\hfill%
257
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-moire.png}}
258
+
\caption{Dos tarjetas de programa renderizadas por el int\'erprete Python: ``Starburst'' (72 l\'ineas radiales, 3 l\'ineas de c\'odigo) y ``Moir\'{e}'' (c\'irculos conc\'entricos superpuestos, 3 l\'ineas). Estos son ejemplos triviales---demuestran la estructura del formato de tarjeta pero no representan el rango expresivo del lenguaje ni las ambiciones del formato.}
259
+
\label{fig:program-cards}
260
+
\end{figure}
261
+
262
+
% ============ 3. PIPELINE DE RENDERIZADO ============
263
+
264
+
\section{Pipeline de renderizado offline}
265
+
\label{sec:pipeline}
266
+
267
+
Las tarjetas KidLisp se renderizan usando un int\'erprete Python que se ejecuta fuera del navegador. Esto permite el renderizado por lotes, la producci\'on para impresi\'on y la curaci\'on basada en cuadernos sin requerir el runtime completo de Aesthetic\acdot Computer.
268
+
269
+
\subsection{El int\'erprete Python}
270
+
271
+
El int\'erprete (\texttt{notebooks/ac.py}, 452 l\'ineas) implementa un subconjunto de \kidlisp{} suficiente para el renderizado est\'atico de tarjetas:
272
+
273
+
\begin{itemize}
274
+
\item \textbf{Dibujo:} \texttt{wipe}, \texttt{ink}, \texttt{line}, \texttt{box}, \texttt{circle}, \texttt{tri}, \texttt{plot}, \texttt{shape}, \texttt{flood}
275
+
\item \textbf{Tortuga:} \texttt{crawl}, \texttt{left}, \texttt{right}, \texttt{goto}, \texttt{face}, \texttt{up}, \texttt{down}
276
+
\item \textbf{Control:} \texttt{repeat}, \texttt{if}, \texttt{def}, \texttt{later}, \texttt{do}
277
+
\item \textbf{Matem\'aticas:} aritm\'etica completa, trigonometr\'ia, \texttt{abs}, \texttt{sqrt}, \texttt{min}, \texttt{max}
278
+
\item \textbf{Lienzo:} \texttt{resolution}, \texttt{fill}, \texttt{outline}, \texttt{stroke}
279
+
\end{itemize}
280
+
281
+
El int\'erprete usa PIL (Pillow) para el renderizado. Cada tarjeta se dibuja en un lienzo RGBA, se escala con interpolaci\'on de vecino m\'as cercano y se exporta como PNG. La implementaci\'on en Python es intencionalmente m\'as simple que el evaluador del navegador (15.161 l\'ineas)---omite animaci\'on, audio, incrustaci\'on y sintaxis de temporizaci\'on, centr\'andose solo en el subconjunto necesario para la salida visual est\'atica.
282
+
283
+
\subsection{Flujo de trabajo con Jupyter Notebook}
284
+
285
+
La herramienta principal de curaci\'on es un cuaderno Jupyter (\texttt{notebooks/kidlisp-cards.ipynb}). La funci\'on \texttt{show\_card()} renderiza un programa y lo muestra en l\'inea como una tarjeta HTML:
286
+
287
+
\begin{lstlisting}[language=python,basicstyle=\ttfamily\footnotesize]
288
+
show_card("Starburst", """(wipe black)
289
+
(ink white)
290
+
(repeat 72 i
291
+
(line 80 60
292
+
(+ 80 (* 55 (cos (* i 0.087))))
293
+
(+ 60 (* 55 (sin (* i 0.087))))))""")
294
+
\end{lstlisting}
295
+
296
+
Cada llamada produce una tarjeta con fondo oscuro con el t\'itulo, la imagen renderizada y el c\'odigo fuente mostrados en l\'inea. El cuaderno sirve tanto como entorno de desarrollo como galer\'ia---desplazarse por el cuaderno es como hojear una baraja de tarjetas.
297
+
298
+
\subsection{Dos int\'erpretes, un lenguaje}
299
+
300
+
La existencia de dos int\'erpretes independientes (JavaScript en el navegador, Python en el cuaderno) sirve como mecanismo de validaci\'on cruzada. Si un programa se renderiza de forma id\'entica en ambos, su comportamiento est\'a determinado enteramente por la sem\'antica del lenguaje y no por detalles de implementaci\'on. Los programas que dependen de caracter\'isticas espec\'ificas del navegador (animaci\'on, audio, capas incrustadas) quedan excluidos del formato de tarjeta por construcci\'on---simplemente no se renderizan en el int\'erprete Python.
301
+
302
+
% ============ 4. CAT\'ALOGO DE TARJETAS ============
303
+
304
+
\section{El cat\'alogo de tarjetas}
305
+
\label{sec:catalog}
306
+
307
+
El cuaderno actual contiene 28 tarjetas organizadas en siete categor\'ias. Cada categor\'ia explora un aspecto diferente del lenguaje a trav\'es de ejemplos m\'inimos. Estos programas son deliberadamente triviales---ejercicios de dibujo, ilustraciones matem\'aticas, caminatas de tortuga. Establecen la estructura del formato de tarjeta pero no representan su potencial expresivo. Las tarjetas interesantes a\'un no se han hecho. El valor del formato surgir\'a de programas que usen la brevedad para decir algo que valga la pena decir, no de demos geom\'etricas.
308
+
309
+
\subsection{L\'ineas}
310
+
311
+
Las tarjetas de l\'ineas demuestran \texttt{repeat} y trigonometr\'ia. Una explosi\'on estelar irradia 72 l\'ineas desde el centro. Un entrecruzado superpone rejillas horizontales y verticales con baja opacidad.
312
+
313
+
\begin{figure}[h]
314
+
\centering
315
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-starburst.png}}%
316
+
\hfill%
317
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-crosshatch.png}}
318
+
\caption{``Starburst'' y ``Crosshatch'' --- tarjetas de l\'ineas.}
319
+
\label{fig:lines}
320
+
\end{figure}
321
+
322
+
\begin{lstlisting}
323
+
; Starburst — 72 radial lines
324
+
(wipe |\kt{black}|)
325
+
(ink |\kt{white}|)
326
+
(repeat |\kn{72}| |\kv{i}|
327
+
(line |\kn{80}| |\kn{60}|
328
+
(|\km{+}| |\kn{80}| (|\km{*}| |\kn{55}| (|\km{cos}| (|\km{*}| |\kv{i}| |\kn{0.087}|))))
329
+
(|\km{+}| |\kn{60}| (|\km{*}| |\kn{55}| (|\km{sin}| (|\km{*}| |\kv{i}| |\kn{0.087}|))))))
330
+
\end{lstlisting}
331
+
332
+
\subsection{C\'irculos}
333
+
334
+
Las tarjetas de c\'irculos usan el modo \texttt{outline} y bucles \texttt{repeat} anidados. ``Ripple'' dibuja 30 c\'irculos conc\'entricos con color que cambia hacia el azul.
335
+
336
+
\begin{figure}[h]
337
+
\centering
338
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-ripple.png}}%
339
+
\hfill%
340
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-mondrian.png}}
341
+
\caption{``Ripple'' (c\'irculos) y ``Mondrian'' (cajas).}
342
+
\label{fig:circles-boxes}
343
+
\end{figure}
344
+
345
+
\subsection{Cajas y composici\'on}
346
+
347
+
``Mondrian'' recrea la rejilla de colores primarios con cuatro rect\'angulos coloreados. ``Nest'' dibuja 10 rect\'angulos insertados con tonos cambiantes.
348
+
349
+
\subsection{Matem\'aticas y curvas}
350
+
351
+
Estas tarjetas usan \texttt{plot} con funciones matem\'aticas. ``Lissajous'' dibuja una figura de Lissajous con 600 puntos. ``Spiral'' traza una espiral polar.
352
+
353
+
\begin{figure}[h]
354
+
\centering
355
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-lissajous.png}}%
356
+
\hfill%
357
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-sierpinski.png}}
358
+
\caption{``Lissajous'' (curvas matem\'aticas) y ``Sierpinski'' (fractal AND a nivel de bits).}
359
+
\label{fig:math}
360
+
\end{figure}
361
+
362
+
\subsection{Color y gradientes}
363
+
364
+
``Sierpinski'' usa AND a nivel de bits para generar el tri\'angulo de Sierpinski: \texttt{(if (= 0 (\& x y)) (plot (+ 16 x) y))}. ``Sunflower'' traza 500 puntos a lo largo de una espiral de \'angulo \'aureo con colores c\'iclicos.
365
+
366
+
\subsection{Gr\'aficos de tortuga}
367
+
368
+
Las tarjetas de tortuga usan \texttt{crawl}, \texttt{left}, \texttt{right} y \texttt{face}. Una estrella de cinco puntas usa \texttt{(right 144)}. Un \'arbol usa \texttt{later} para ramificaci\'on recursiva. Un copo de nieve anida segmentos de curva de Koch.
369
+
370
+
\begin{figure}[h]
371
+
\centering
372
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-star.png}}%
373
+
\hfill%
374
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-tree.png}}
375
+
\caption{``Star'' y ``Tree'' --- tarjetas de gr\'aficos de tortuga.}
376
+
\label{fig:turtle}
377
+
\end{figure}
378
+
379
+
\begin{lstlisting}
380
+
; Star — 5 sides, 144-degree turns
381
+
(wipe |\kt{navy}|)
382
+
(ink |\kt{yellow}|)
383
+
(repeat |\kn{5}| |\kv{i}| (crawl |\kn{50}|) (right |\kn{144}|))
384
+
\end{lstlisting}
385
+
386
+
\subsection{Koans m\'inimos}
387
+
388
+
Las tarjetas m\'as cortas de la baraja. ``Horizon'' son tres l\'ineas: cielo oscuro, tierra dorada. ``Pip'' es un solo punto rojo sobre negro. Estas tarjetas se acercan al programa m\'inimo viable---la menor cantidad de c\'odigo que produce una imagen reconocible.
389
+
390
+
\begin{figure}[h]
391
+
\centering
392
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-horizon.png}}%
393
+
\hfill%
394
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-pip.png}}
395
+
\caption{``Horizon'' y ``Pip'' --- koans m\'inimos (2--3 l\'ineas cada uno).}
396
+
\label{fig:koans}
397
+
\end{figure}
398
+
399
+
\begin{lstlisting}
400
+
; Pip — the minimum card
401
+
(wipe |\kt{black}|)
402
+
(ink |\kt{red}|)
403
+
(circle |\kn{80}| |\kn{60}| |\kn{4}|)
404
+
\end{lstlisting}
405
+
406
+
\begin{figure*}[t]
407
+
\centering
408
+
\fbox{\includegraphics[height=5.5cm]{card-nest.png}}%
409
+
\hfill%
410
+
\fbox{\includegraphics[height=5.5cm]{card-sunflower.png}}%
411
+
\hfill%
412
+
\fbox{\includegraphics[height=5.5cm]{card-snowflake.png}}%
413
+
\hfill%
414
+
\fbox{\includegraphics[height=5.5cm]{card-spiral.png}}
415
+
\caption{Cuatro tarjetas completas que muestran el formato: t\'itulo, salida renderizada y c\'odigo fuente. De izquierda a derecha: ``Nest,'' ``Sunflower,'' ``Snowflake,'' ``Spiral.'' Cada tarjeta es autocontenida---el c\'odigo fuente debajo de la imagen es el programa completo. Estos son ejercicios de dibujo triviales, no expresiones del potencial del formato.}
416
+
\label{fig:four-cards}
417
+
\end{figure*}
418
+
419
+
% ============ 5. DISPOSICIONES ============
420
+
421
+
\section{Disposiciones}
422
+
\label{sec:layouts}
423
+
424
+
El formato de tarjeta no tiene una disposici\'on fija. C\'omo se organizan los tres elementos (t\'itulo, salida, fuente) determina lo que la tarjeta permite---lo que puedes hacer con ella f\'isica y socialmente. Esta secci\'on explora variaciones de disposici\'on y sus consecuencias.
425
+
426
+
\begin{figure*}[t]
427
+
\centering
428
+
\includegraphics[width=\textwidth]{layout-comparison.png}
429
+
\caption{Tres estrategias de disposici\'on. \textbf{Vertical:} t\'itulo / imagen / fuente apilados de arriba a abajo, optimizado para pantallas de tel\'efono e impresi\'on en retrato. \textbf{Horizontal:} imagen a la izquierda, t\'itulo y fuente a la derecha, adecuado para tarjetas en paisaje y navegaci\'on de baraja lado a lado. \textbf{Postal:} salida renderizada en el frente, c\'odigo fuente y metadatos en el reverso---una tarjeta enviable por correo donde el programa est\'a oculto hasta que la volteas.}
430
+
\label{fig:layouts}
431
+
\end{figure*}
432
+
433
+
\subsection{Vertical (pantalla / impresi\'on)}
434
+
435
+
La disposici\'on predeterminada apila t\'itulo, imagen y fuente de arriba a abajo. Esta es la disposici\'on del cuaderno---se desplaza naturalmente en un tel\'efono o en un cuaderno Jupyter. Para impresi\'on, corresponde a una tarjeta de 4$\times$6 pulgadas en orientaci\'on retrato. El ojo del lector se mueve hacia abajo desde el nombre hasta la imagen y el c\'odigo, trazando la relaci\'on entre el programa y su salida.
436
+
437
+
\subsection{Horizontal (baraja / paisaje)}
438
+
439
+
Una disposici\'on en paisaje coloca la imagen renderizada a la izquierda y el c\'odigo fuente a la derecha. Esto funciona para desplegar tarjetas sobre una mesa, para presentaciones y para comparaci\'on lado a lado. Dos tarjetas colocadas una junto a otra crean un d\'iptico---el espectador puede comparar programas y salidas simult\'aneamente.
440
+
441
+
\subsection{Postal (arte postal)}
442
+
443
+
La disposici\'on postal separa el frente del reverso. El frente muestra solo la imagen renderizada, a sangre completa, sin texto. El reverso muestra el c\'odigo fuente, el handle del autor, el c\'odigo corto (\texttt{\$xyz}) y un \'area para sello. El destinatario ve la imagen primero---un artefacto visual. Voltear la tarjeta revela el programa: las instrucciones que lo produjeron. La tarjeta es tanto objeto art\'istico como partitura ejecutable, dependiendo de qu\'e lado leas.
444
+
445
+
\begin{figure*}[h]
446
+
\centering
447
+
\includegraphics[width=\textwidth]{layout-affordances.png}
448
+
\caption{Affordances sociales y f\'isicas del formato de tarjeta. Cada affordance se deriva de la materialidad de la tarjeta: puede \textbf{compartirse} de mano en mano, \textbf{enviarse} como postal, \textbf{intercambiarse} y coleccionarse, \textbf{ense\~narse} en secuencias pedag\'ogicas, \textbf{interpretarse} como partitura gr\'afica o \textbf{colgarse} en la pared de una galer\'ia.}
449
+
\label{fig:affordances}
450
+
\end{figure*}
451
+
452
+
\subsection{Arreglos de baraja}
453
+
454
+
Las tarjetas no son objetos individuales. Forman barajas, y el arreglo de una baraja crea significado. Una \emph{secuencia pedag\'ogica} ordena tarjetas por concepto: cajas primero (coordenadas), luego l\'ineas (trigonometr\'ia), luego c\'irculos (radio y repetici\'on), luego curvas matem\'aticas (plot y seno), luego gr\'aficos de tortuga (movimiento relativo) y finalmente koans (expresi\'on m\'inima). Una \emph{cuadr\'icula de galer\'ia} arregla tarjetas espacialmente en una pared, invitando a la comparaci\'on entre categor\'ias. Una \emph{baraja mezclada} aleatoriza el orden, produciendo yuxtaposiciones inesperadas entre un fractal y un horizonte, entre un \'arbol y un punto.
455
+
456
+
\begin{figure}[h]
457
+
\centering
458
+
\includegraphics[width=\columnwidth]{layout-decks.png}
459
+
\caption{Arreglos de baraja. Izquierda: tarjetas desplegadas por categor\'ia (l\'ineas, c\'irculos, cajas, matem\'aticas, tortuga, koans) con m\'ultiples tarjetas apiladas por categor\'ia. Derecha: una cuadr\'icula de galer\'ia donde las tarjetas est\'an arregladas espacialmente para su navegaci\'on.}
460
+
\label{fig:decks}
461
+
\end{figure}
462
+
463
+
% ============ 6. TARJETAS EN EL MUNDO REAL ============
464
+
465
+
\section{Tarjetas en el mundo real}
466
+
\label{sec:wild}
467
+
468
+
Las tarjetas del cuaderno son ejercicios. El verdadero corpus de \kidlisp{}---m\'as de 16.000 programas creados por 59 autores---contiene piezas que usan el runtime completo: animaci\'on, audio, capas incrustadas, gradientes, colocaci\'on aleatoria y sintaxis de temporizaci\'on. Estas piezas son lo suficientemente cortas para el formato de tarjeta pero mucho m\'as expresivas que los ejemplos del cuaderno. Sus im\'agenes de vista previa son renderizadas por el servicio oven (captura de pantalla basada en Puppeteer) y servidas v\'ia CDN.
469
+
470
+
\begin{figure*}[t]
471
+
\centering
472
+
\includegraphics[height=7cm]{user-card-bop.png}%
473
+
\hfill%
474
+
\includegraphics[height=7cm]{user-card-roz.png}%
475
+
\hfill%
476
+
\includegraphics[height=7cm]{user-card-cow.png}%
477
+
\hfill%
478
+
\includegraphics[height=7cm]{user-card-r2f.png}
479
+
\caption{Cuatro tarjetas del corpus vivo de \kidlisp{}, renderizadas por el servicio oven. De izquierda a derecha: \texttt{\$bop} (12.188 reproducciones---la pieza m\'as popular, 4 l\'ineas), \texttt{\$roz} (7.064 reproducciones, 3 l\'ineas), \texttt{\$cow} (5.980 reproducciones---una composici\'on que incrusta dos otras piezas v\'ia \texttt{\$39i} y \texttt{\$r2f}), \texttt{\$r2f} (4.413 reproducciones, 3 l\'ineas de colocaci\'on aleatoria de cajas). Todos por @jeffrey. Estos programas usan caracter\'isticas ausentes del int\'erprete Python---animaci\'on, aleatoriedad (\texttt{?}), gradientes (\texttt{fade:}), capas incrustadas (\texttt{\$code})---pero su c\'odigo fuente a\'un cabe en una tarjeta.}
480
+
\label{fig:user-cards}
481
+
\end{figure*}
482
+
483
+
\subsection{Qu\'e a\~naden las piezas reales}
484
+
485
+
Las tarjetas del cuaderno usan un subconjunto est\'atico de \kidlisp{}. Las piezas reales en \texttt{kidlisp.com} usan el runtime completo:
486
+
487
+
\begin{itemize}
488
+
\item \textbf{Animaci\'on.} Los programas se re-eval\'uan cada fotograma. \texttt{frame} y \texttt{time} cambian autom\'aticamente. Una captura de un solo fotograma captura un momento de una pieza viva.
489
+
\item \textbf{Aleatoriedad.} El operador \texttt{?} produce un valor aleatorio de una lista cada fotograma. \texttt{(ink (? red blue green))} parpadea entre colores.
490
+
\item \textbf{Gradientes.} \texttt{fade:red-blue-black} interpola un gradiente de m\'ultiples paradas a trav\'es del lienzo, impulsado por el conteo de \texttt{frame}. Una expresi\'on reemplaza p\'aginas de matem\'aticas de color manuales.
491
+
\item \textbf{Incrustaci\'on.} \texttt{(\$cow)} obtiene la pieza \texttt{cow} de MongoDB, la eval\'ua en un b\'ufer fuera de pantalla y compone el resultado. Las piezas se construyen sobre piezas.
492
+
\item \textbf{Temporizaci\'on.} \texttt{1s... (zoom 0.5)} aplica un zoom cada segundo. Sin bucle de animaci\'on expl\'icito.
493
+
\end{itemize}
494
+
495
+
Estas caracter\'isticas mantienen los programas cortos mientras expanden dram\'aticamente lo que pueden expresar. \texttt{\$bop}---la pieza m\'as reproducida con 12.188 vistas---son cuatro l\'ineas: un fondo morado, tinta parpadeante arco\'iris, una l\'inea aleatoria y un desenfoque. En una tarjeta, parece un momento congelado de una pintura cin\'etica. En el navegador, lo es.
496
+
497
+
\subsection{La tarjeta como instant\'anea}
498
+
499
+
Una tarjeta de una pieza animada es necesariamente incompleta. Captura un fotograma de un proceso temporal. Esta incompletitud es parte del formato: la tarjeta te invita a teclear el c\'odigo y ver qu\'e hace realmente. La imagen est\'atica es una promesa. El c\'odigo fuente es el cumplimiento. El c\'odigo corto (\texttt{\$bop}) es el puente---tecl\'ealo en \texttt{kidlisp.com} y la tarjeta cobra vida.
500
+
501
+
% ============ 7. EN QU\'E PODR\'IAN CONVERTIRSE LAS TARJETAS ============
502
+
503
+
\section{En qu\'e podr\'ian convertirse las tarjetas}
504
+
\label{sec:futures}
505
+
506
+
El formato de tarjeta es joven. El cuaderno actual es una prueba de concepto---28 programas renderizados offline. Pero la correspondencia entre programas cortos y tarjetas f\'isicas sugiere varias direcciones.
507
+
508
+
\subsection{Tarjetas coleccionables}
509
+
510
+
Una tarjeta KidLisp es coleccionable de una manera que la mayor\'ia del software no lo es. Cada tarjeta tiene un nombre, una identidad visual, un c\'odigo corto (\texttt{\$xyz}) y un autor. Las tarjetas podr\'ian imprimirse, numerarse e intercambiarse. Las tarjetas raras podr\'ian usar caracter\'isticas oscuras del lenguaje o producir salidas inesperadamente complejas a partir de c\'odigo m\'inimo. La ``rareza'' de una tarjeta es su densidad de informaci\'on: cu\'anta complejidad visual emerge de cu\'an pocos caracteres.
511
+
512
+
\subsection{Secuencias pedag\'ogicas}
513
+
514
+
Las siete categor\'ias del cuaderno actual sugieren un orden de ense\~nanza: comenzar con cajas (coordenadas simples), pasar a l\'ineas (trigonometr\'ia), c\'irculos (radio y repetici\'on), curvas matem\'aticas (plot y seno), gr\'aficos de tortuga (movimiento relativo) y finalmente koans (expresi\'on m\'inima). Cada tarjeta ense\~na un concepto. Un profesor podr\'ia entregar a los estudiantes una baraja f\'isica y pedirles que reproduzcan cada tarjeta, la modifiquen o creen una nueva tarjeta en la misma categor\'ia.
515
+
516
+
\subsection{Partituras impresas}
517
+
518
+
En m\'usica, una partitura son instrucciones para producir un evento temporal. Una tarjeta KidLisp son instrucciones para producir un evento visual. Las tarjetas podr\'ian funcionar como partituras gr\'aficas en la tradici\'on de Cornelius Cardew, John Cage y las partituras de eventos Fluxus. Un int\'erprete recibe una tarjeta, interpreta el c\'odigo (tecle\'andolo en \texttt{kidlisp.com}, ley\'endolo en voz alta, dibuj\'andolo a mano) y produce un evento. La tarjeta es la partitura. El renderizado es una realizaci\'on posible.
519
+
520
+
\subsection{Arte postal}
521
+
522
+
A 4$\times$6 pulgadas, una tarjeta KidLisp es una postal. El frente muestra la imagen renderizada. El reverso muestra el c\'odigo fuente, el handle del autor y el c\'odigo corto para buscarlo en l\'inea. Arte postal con contenido ejecutable---el destinatario puede teclear el c\'odigo y ver la imagen regenerarse en su pantalla. La tarjeta f\'isica y el programa digital son la misma obra en dos medios.
523
+
524
+
\subsection{Papeler\'ia generativa}
525
+
526
+
Dado que el int\'erprete Python es determinista y aut\'onomo, las tarjetas pueden renderizarse por lotes para producci\'on de impresi\'on sin acceso a la red. Un conjunto de tarjetas podr\'ia imprimirse como folleto, fanzine o set en caja. El pipeline \texttt{cards-convert.mjs} ya produce tarjetas PDF de 4$\times$6 pulgadas desde el formato del art\'iculo; extender esto para incluir la salida renderizada del programa junto con el c\'odigo fuente es un pr\'oximo paso natural.
527
+
528
+
\subsection{La restricci\'on como principio generativo}
529
+
530
+
La consecuencia m\'as interesante del formato de tarjeta es c\'omo retroalimenta el lenguaje. Los programas que no caben en una tarjeta sugieren abstracciones faltantes---o sugieren que el programa hace demasiado. La restricci\'on de la tarjeta fomenta la econom\'ia: encontrar el programa de tres l\'ineas que produce la imagen m\'as interesante. Esta es una restricci\'on generativa en la tradici\'on de Oulipo---restricciones formales arbitrarias que producen resultados creativos inesperados.
531
+
532
+
% ============ 6. TRABAJO RELACIONADO ============
533
+
534
+
\section{Trabajo relacionado}
535
+
536
+
\textbf{C\'odigo impreso.} La tradici\'on de la demoscene de ``sizecoding'' (programas de menos de 256 bytes) comparte la est\'etica de programas m\'inimos que producen salida m\'axima. Las tarjetas de \kidlisp{} est\'an m\'as cerca de la tradici\'on del ``poema de c\'odigo'', donde el c\'odigo fuente mismo se lee como texto junto con su salida.
537
+
538
+
\textbf{Partituras gr\'aficas.} El \emph{Treatise} de Cardew (1967) y las \emph{Notations} de Cage (1969) establecieron que la notaci\'on visual puede servir como instrucciones de interpretaci\'on sin prescribir una realizaci\'on espec\'ifica. Las tarjetas KidLisp difieren en que son completamente ejecutables---el renderizado es determinista, no abierto a interpretaci\'on. Pero el encuadre de tarjeta-como-partitura invita a la reinterpretaci\'on: \textquestiondown qu\'e pasa si ``tocas'' la tarjeta de manera diferente cada vez?
539
+
540
+
\textbf{Juegos de tarjetas coleccionables.} Juegos como \emph{Magic: The Gathering} (1993) demostraron que las tarjetas con metadatos estructurados (nombre, tipo, texto de reglas, arte) crean ricos espacios combinatorios. Las tarjetas KidLisp tienen metadatos naturales (t\'itulo, categor\'ia, n\'umero de funciones, n\'umero de l\'ineas, complejidad de salida) que podr\'ian soportar mec\'anicas de juego similares.
541
+
542
+
\textbf{Cuadernos computacionales.} Los cuadernos Jupyter ya combinan c\'odigo y salida. El cuaderno de KidLisp Cards es un cuaderno Jupyter, pero con una restricci\'on espec\'ifica: cada celda es una tarjeta autocontenida en lugar de un paso en un c\'alculo m\'as largo. El cuaderno es una galer\'ia, no una narrativa.
543
+
544
+
% ============ 7. CONCLUSI\'ON ============
545
+
546
+
\section{Conclusi\'on}
547
+
548
+
Las tarjetas KidLisp surgen de una observaci\'on simple: cuando los programas son lo suficientemente cortos, caben en tarjetas. El formato de tarjeta---t\'itulo, imagen, fuente---convierte los programas en artefactos f\'isicos que pueden imprimirse, enviarse por correo, coleccionarse, ense\~narse y ejecutarse. El pipeline de renderizado en Python permite la producci\'on offline por lotes. El cat\'alogo de siete categor\'ias proporciona un punto de entrada curado al lenguaje.
549
+
550
+
El formato es un trabajo en progreso. La baraja actual de 28 tarjetas es un punto de partida, no una colecci\'on terminada. La pregunta no es cu\'antas tarjetas hacer sino qu\'e programas merecen ser tarjetas---qu\'e composiciones de tres l\'ineas producen im\'agenes que vale la pena sostener en la mano.
551
+
552
+
El cuaderno, el int\'erprete y el cat\'alogo de tarjetas est\'an disponibles en \url{https://github.com/whistlegraph/aesthetic-computer}. Los programas pueden crearse y compartirse en \url{https://kidlisp.com}.
553
+
554
+
\vspace{0.5em}
555
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
556
+
557
+
% ============ REFERENCIAS ============
558
+
559
+
\bibliographystyle{plainnat}
560
+
\bibliography{references}
561
+
562
+
\end{document}
+564
papers/arxiv-kidlisp-cards/kidlisp-cards-zh.tex
+564
papers/arxiv-kidlisp-cards/kidlisp-cards-zh.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\usepackage{xeCJK}
11
+
\setCJKmainfont{Droid Sans Fallback}
12
+
13
+
\setmainfont{Latin Modern Roman}
14
+
\setsansfont{Latin Modern Sans}
15
+
16
+
% Custom AC fonts
17
+
\newfontfamily\acbold{ywft-processing-bold}[
18
+
Path=../../system/public/type/webfonts/,
19
+
Extension=.ttf
20
+
]
21
+
\newfontfamily\aclight{ywft-processing-light}[
22
+
Path=../../system/public/type/webfonts/,
23
+
Extension=.ttf
24
+
]
25
+
\newfontfamily\kidlispfont{ComicRelief-Regular}[
26
+
Path=../arxiv-kidlisp/fonts/,
27
+
Extension=.ttf
28
+
]
29
+
\newfontfamily\kidlispbold{ComicRelief-Bold}[
30
+
Path=../arxiv-kidlisp/fonts/,
31
+
Extension=.ttf
32
+
]
33
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
34
+
35
+
% === PACKAGES ===
36
+
\usepackage{xcolor}
37
+
\usepackage{titlesec}
38
+
\usepackage{enumitem}
39
+
\usepackage{booktabs}
40
+
\usepackage{tabularx}
41
+
\usepackage{fancyhdr}
42
+
\usepackage{hyperref}
43
+
\usepackage{graphicx}
44
+
\graphicspath{{figures/}{../arxiv-kidlisp/figures/}}
45
+
\usepackage{ragged2e}
46
+
\usepackage{microtype}
47
+
\usepackage{listings}
48
+
\usepackage{natbib}
49
+
\usepackage[colorspec=0.92]{draftwatermark}
50
+
51
+
% === COLORS (AC palette) ===
52
+
\definecolor{acpink}{RGB}{180,72,135}
53
+
\definecolor{acpurple}{RGB}{120,80,180}
54
+
\definecolor{acdark}{RGB}{64,56,74}
55
+
\definecolor{acgray}{RGB}{119,119,119}
56
+
\definecolor{klbrand}{RGB}{205,92,155}
57
+
\definecolor{klcyan}{RGB}{112,214,255}
58
+
\definecolor{kldark}{RGB}{48,43,58}
59
+
\definecolor{draftcolor}{RGB}{205,92,155}
60
+
61
+
% === DRAFT WATERMARK ===
62
+
\DraftwatermarkOptions{
63
+
text=工作草稿,
64
+
fontsize=3cm,
65
+
color=draftcolor!18,
66
+
angle=45,
67
+
pos={0.5\paperwidth, 0.5\paperheight}
68
+
}
69
+
70
+
% === KIDLISP SYNTAX COLORS ===
71
+
\definecolor{klfn}{RGB}{0,136,170}
72
+
\definecolor{klform}{RGB}{119,51,170}
73
+
\definecolor{klrepeat}{RGB}{170,0,170}
74
+
\definecolor{klnum}{RGB}{204,0,102}
75
+
\definecolor{klstr}{RGB}{170,120,0}
76
+
\definecolor{klcmt}{RGB}{102,102,102}
77
+
\definecolor{klmath}{RGB}{0,136,0}
78
+
\definecolor{klvar}{RGB}{204,102,0}
79
+
\definecolor{klembed}{RGB}{0,136,0}
80
+
81
+
% KidLisp inline color macros
82
+
\newcommand{\kn}[1]{\textcolor{klnum}{#1}}
83
+
\newcommand{\kt}[1]{\textcolor{klstr}{#1}}
84
+
\newcommand{\kv}[1]{\textcolor{klvar}{#1}}
85
+
\newcommand{\ke}[1]{\textcolor{klembed}{\textbf{#1}}}
86
+
\newcommand{\km}[1]{\textcolor{klmath}{#1}}
87
+
88
+
% === HYPERREF ===
89
+
\hypersetup{
90
+
colorlinks=true,
91
+
linkcolor=acpurple,
92
+
urlcolor=acpurple,
93
+
citecolor=acpurple,
94
+
pdfauthor={@jeffrey},
95
+
pdftitle={KidLisp 卡片：一张卡片装得下的程序},
96
+
}
97
+
98
+
% === SECTION FORMATTING ===
99
+
\titleformat{\section}
100
+
{\normalfont\bfseries\normalsize\uppercase}
101
+
{\thesection.}
102
+
{0.5em}
103
+
{}
104
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
105
+
106
+
\titleformat{\subsection}
107
+
{\normalfont\bfseries\small}
108
+
{\thesubsection}
109
+
{0.5em}
110
+
{}
111
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
112
+
113
+
% === HEADER/FOOTER ===
114
+
\pagestyle{fancy}
115
+
\fancyhf{}
116
+
\renewcommand{\headrulewidth}{0pt}
117
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{工作草稿 --- 请勿引用}}
118
+
\fancyfoot[C]{\footnotesize\thepage}
119
+
120
+
% === CUSTOM COMMANDS ===
121
+
\newcommand{\acdot}{{\color{acpink}.}}
122
+
\newcommand{\kidlisp}{\textsc{KidLisp}}
123
+
124
+
% === LISTINGS ===
125
+
\lstdefinelanguage{kidlisp}{
126
+
morekeywords=[1]{wipe,ink,line,box,circle,tri,plot,flood,shape,zoom,scroll,spin,blur,contrast,embed,layer,width,height,frame,time,wiggle,melody,mic,suck,sort,form,trans,cube,move,scale,hop,overtone,resolution,write,text,type,stamp,paste,point,poly,noise,fade,pan,unpan,mask,unmask,flip,crawl,left,right,up,down,goto,face,outline,fill,stroke},
127
+
morekeywords=[2]{def,let,if,cond,once,later,lambda,do},
128
+
morekeywords=[3]{repeat},
129
+
morekeywords=[4]{random,sin,cos,tan,floor,ceil,round,abs,sqrt,min,max},
130
+
sensitive=true,
131
+
morecomment=[l]{;},
132
+
morestring=[b]",
133
+
escapeinside={|}{|},
134
+
}
135
+
\lstset{
136
+
language=kidlisp,
137
+
basicstyle=\ttfamily\small,
138
+
keywordstyle=[1]\color{klfn}\bfseries,
139
+
keywordstyle=[2]\color{klform}\bfseries,
140
+
keywordstyle=[3]\color{klrepeat}\bfseries,
141
+
keywordstyle=[4]\color{klmath},
142
+
commentstyle=\color{klcmt}\itshape,
143
+
stringstyle=\color{klstr},
144
+
breaklines=true,
145
+
frame=single,
146
+
rulecolor=\color{acgray!30},
147
+
backgroundcolor=\color{acgray!5},
148
+
xleftmargin=0.5em,
149
+
xrightmargin=0.5em,
150
+
aboveskip=0.5em,
151
+
belowskip=0.5em,
152
+
}
153
+
154
+
\lstdefinelanguage{python}{
155
+
morekeywords={def,return,import,from,class,if,else,for,in,with,as,try,except,None,True,False,self,and,or,not,lambda,yield,pass,break,continue,raise,while},
156
+
sensitive=true,
157
+
morecomment=[l]{\#},
158
+
morestring=[b]",
159
+
morestring=[b]',
160
+
}
161
+
\lstset{
162
+
language=kidlisp,
163
+
}
164
+
165
+
% === LIST SETTINGS ===
166
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
167
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
168
+
169
+
% === COLUMN SEPARATION ===
170
+
\setlength{\columnsep}{1.8em}
171
+
172
+
% === PARAGRAPH SETTINGS ===
173
+
\setlength{\parindent}{1em}
174
+
\setlength{\parskip}{0.3em}
175
+
176
+
\tolerance=800
177
+
\emergencystretch=1em
178
+
\hyphenpenalty=50
179
+
180
+
\begin{document}
181
+
182
+
% ============ TITLE BLOCK ============
183
+
184
+
\twocolumn[{%
185
+
\begin{center}
186
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
187
+
{\kidlispbold\fontsize{24pt}{28pt}\selectfont\color{kldark} Kid{\color{klbrand}Lisp} 卡片}\par
188
+
\vspace{0.2em}
189
+
{\kidlispfont\fontsize{11pt}{13pt}\selectfont\color{klbrand} 一张卡片装得下的程序}\par
190
+
\vspace{0.6em}
191
+
{\normalsize @jeffrey}\par
192
+
{\small\color{acgray} Aesthetic\acdot Computer}\par
193
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
194
+
\vspace{0.3em}
195
+
{\small\color{acpurple} \url{https://kidlisp.com} \enspace$\cdot$\enspace \url{https://aesthetic.computer}}\par
196
+
\vspace{0.6em}
197
+
\rule{\textwidth}{1.5pt}
198
+
\vspace{0.5em}
199
+
\end{center}
200
+
201
+
\begin{center}
202
+
{\small\color{acpink}\textbf{[ 工作草稿 --- 请勿引用 ]}}
203
+
\end{center}
204
+
\vspace{0.3em}
205
+
206
+
\begin{quote}
207
+
\small\noindent\textbf{摘要。}
208
+
\kidlisp{} 程序很短。一个典型的程序只有2--4行S-表达式，即可产生一幅完整的视觉构图------一个星芒、一条螺旋、一幅拼布、一个分形。这种简短不是偶然的，而是刻意设计的：该语言省略了用户定义函数、递归和抽象机制，因此程序保持扁平且可读。我们观察到，这种扁平性在程序与物理卡片之间创造了一种自然的对应关系。一个 \kidlisp{} 程序、其源代码和渲染输出可以共存于一张印刷卡片上。本文描述了 \emph{KidLisp Cards} 格式------一组按视觉类别组织的程序卡牌------以及一个 Python 渲染管线（基于 PIL 的解释器），可在浏览器外生成卡片图像。我们讨论了卡片目前是什么（一本精心策划的视觉公案笔记本）、它们可能成为什么（集换卡、教学序列、印刷乐谱、邮寄艺术），以及卡片约束如何反馈到语言设计中。
209
+
\end{quote}
210
+
\vspace{0.5em}
211
+
}]
212
+
213
+
% ============ 1. 引言 ============
214
+
215
+
\section{引言}
216
+
217
+
大多数编程语言产生的程序太长，无法打印在一张索引卡上。这是抽象的结果：通用编程语言鼓励将程序分解为函数、类、模块和文件。程序分散在整个代码库中。没有单一的制品能够捕捉全貌。
218
+
219
+
\kidlisp{} 不同。它的程序通常只有1--6行。一个完整的动画场景、一个几何图案、一个递归分形或一个莫尔干涉图案只需几个S-表达式。这不是一种限制，而是一种设计选择：\kidlisp{} 省略了用户定义函数、递归（除了通过 \texttt{later}）、可变数据结构和导入。程序是绘图命令、循环和条件的扁平序列。
220
+
221
+
这种扁平性创造了一个机会。如果一个程序的源代码能放在一张卡片上，而该程序的视觉输出也能放在同一张卡片上，那么卡片就成为一个自包含的制品：一个你可以拿在手中、递给别人、钉在墙上或邮寄的程序。卡片既是文档又是可执行的。它是一份\emph{乐谱}------产生视觉事件的指令。
222
+
223
+
本文描述了 KidLisp Cards 格式（\S\ref{sec:format}）、离线渲染管线（\S\ref{sec:pipeline}）、当前卡片目录（\S\ref{sec:catalog}）、布局变体及其社会和物理可供性（\S\ref{sec:layouts}），以及该格式的推测性未来（\S\ref{sec:futures}）。
224
+
225
+
% ============ 2. 卡片格式 ============
226
+
227
+
\section{卡片格式}
228
+
\label{sec:format}
229
+
230
+
一张 KidLisp 卡片有三个元素：
231
+
232
+
\begin{enumerate}
233
+
\item \textbf{标题。}一个简短的名称，唤起视觉输出的意象：``Starburst''、``Honeycomb''、``Spiral Walk''。
234
+
\item \textbf{渲染输出。}一张像素艺术图像（默认分辨率160$\times$120，使用最近邻插值3$\times$放大以保持锐利边缘）。
235
+
\item \textbf{源代码。}完整的 \kidlisp{} 程序，通常1--4行，以等宽字体显示在图像下方。
236
+
\end{enumerate}
237
+
238
+
卡片是自包含的：任何阅读源代码的人都可以在任何 \kidlisp{} 解释器中精确复现图像。没有外部依赖，没有导入，没有配置。程序\emph{就是}卡片。
239
+
240
+
\subsection{卡片尺寸}
241
+
242
+
渲染图像占据160$\times$120像素的画布（4:3比例），与 \kidlisp{} 的默认分辨率一致。在3$\times$放大时，产生480$\times$360像素的图像，适合屏幕显示。用于打印时，卡片尺寸为4$\times$6英寸（标准索引卡/明信片），图像占据上部，源代码在下方。
243
+
244
+
\subsection{什么构成好卡片}
245
+
246
+
不是每个 \kidlisp{} 程序都能成为好卡片。最好的卡片共享以下特征：
247
+
248
+
\begin{itemize}
249
+
\item \textbf{简短。}1--4行。如果源代码不能舒适地放在图像下方，程序对这种格式来说就太长了。
250
+
\item \textbf{惊喜。}输出应该比源代码所暗示的更复杂或更美丽。一个产生莫尔图案的三行程序值得仔细审视。
251
+
\item \textbf{可读性。}读者应该能够在不运行程序的情况下从源代码追踪到输出。代码和图像之间的联系应该是可辨识的，即使不是立即显而易见的。
252
+
\item \textbf{独立性。}没有 \texttt{\$code} 嵌入，没有外部状态。卡片必须独立运行。
253
+
\end{itemize}
254
+
255
+
\begin{figure}[t]
256
+
\centering
257
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-starburst.png}}%
258
+
\hfill%
259
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-moire.png}}
260
+
\caption{Python 解释器渲染的两张程序卡片：``Starburst''（72条径向线，3行代码）和``Moir\'{e}''（重叠的同心圆，3行）。这些是简单的示例------它们展示了卡片格式的结构，但并不代表语言的表达范围或格式的雄心。}
261
+
\label{fig:program-cards}
262
+
\end{figure}
263
+
264
+
% ============ 3. 渲染管线 ============
265
+
266
+
\section{离线渲染管线}
267
+
\label{sec:pipeline}
268
+
269
+
KidLisp 卡片使用在浏览器外运行的 Python 解释器进行渲染。这使得批量渲染、印刷制作和基于笔记本的策展成为可能，而无需完整的 Aesthetic\acdot Computer 运行时。
270
+
271
+
\subsection{Python 解释器}
272
+
273
+
解释器（\texttt{notebooks/ac.py}，452行）实现了 \kidlisp{} 的一个子集，足以进行静态卡片渲染：
274
+
275
+
\begin{itemize}
276
+
\item \textbf{绘图：} \texttt{wipe}、\texttt{ink}、\texttt{line}、\texttt{box}、\texttt{circle}、\texttt{tri}、\texttt{plot}、\texttt{shape}、\texttt{flood}
277
+
\item \textbf{海龟：} \texttt{crawl}、\texttt{left}、\texttt{right}、\texttt{goto}、\texttt{face}、\texttt{up}、\texttt{down}
278
+
\item \textbf{控制：} \texttt{repeat}、\texttt{if}、\texttt{def}、\texttt{later}、\texttt{do}
279
+
\item \textbf{数学：}完整的算术、三角函数、\texttt{abs}、\texttt{sqrt}、\texttt{min}、\texttt{max}
280
+
\item \textbf{画布：} \texttt{resolution}、\texttt{fill}、\texttt{outline}、\texttt{stroke}
281
+
\end{itemize}
282
+
283
+
解释器使用 PIL（Pillow）进行渲染。每张卡片在 RGBA 画布上绘制，使用最近邻插值放大，并导出为 PNG。Python 实现有意比浏览器评估器（15,161行）更简单------它省略了动画、音频、嵌入和定时语法，仅专注于静态视觉输出所需的子集。
284
+
285
+
\subsection{Jupyter Notebook 工作流}
286
+
287
+
主要的策展工具是一个 Jupyter 笔记本（\texttt{notebooks/kidlisp-cards.ipynb}）。\texttt{show\_card()} 函数渲染程序并将其作为 HTML 卡片内联显示：
288
+
289
+
\begin{lstlisting}[language=python,basicstyle=\ttfamily\footnotesize]
290
+
show_card("Starburst", """(wipe black)
291
+
(ink white)
292
+
(repeat 72 i
293
+
(line 80 60
294
+
(+ 80 (* 55 (cos (* i 0.087))))
295
+
(+ 60 (* 55 (sin (* i 0.087))))))""")
296
+
\end{lstlisting}
297
+
298
+
每次调用都会生成一张深色背景的卡片，内联显示标题、渲染图像和源代码。笔记本既是开发环境又是画廊------滚动浏览笔记本就像翻阅一副卡牌。
299
+
300
+
\subsection{两个解释器，一种语言}
301
+
302
+
两个独立解释器（浏览器中的 JavaScript、笔记本中的 Python）的存在起到了交叉验证的作用。如果一个程序在两者中渲染结果相同，则其行为完全由语言语义而非实现细节决定。依赖浏览器特定功能（动画、音频、嵌入层）的程序在构造上被排除在卡片格式之外------它们在 Python 解释器中根本无法渲染。
303
+
304
+
% ============ 4. 卡片目录 ============
305
+
306
+
\section{卡片目录}
307
+
\label{sec:catalog}
308
+
309
+
当前笔记本包含28张卡片，分为七个类别。每个类别通过最小示例探索语言的不同方面。这些程序是刻意选择的简单练习------绘图练习、数学插图、海龟漫步。它们建立了卡片格式的结构，但并不代表其表达潜力。有趣的卡片尚未制作。格式的价值将从那些用简短来表达值得表达之事的程序中涌现，而不是从几何演示中。
310
+
311
+
\subsection{线条}
312
+
313
+
线条卡片演示 \texttt{repeat} 和三角函数。一个星芒从中心辐射72条线。一个交叉阴影以低透明度叠加水平和垂直网格。
314
+
315
+
\begin{figure}[h]
316
+
\centering
317
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-starburst.png}}%
318
+
\hfill%
319
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-crosshatch.png}}
320
+
\caption{``Starburst'' 和 ``Crosshatch'' --- 线条卡片。}
321
+
\label{fig:lines}
322
+
\end{figure}
323
+
324
+
\begin{lstlisting}
325
+
; Starburst — 72 radial lines
326
+
(wipe |\kt{black}|)
327
+
(ink |\kt{white}|)
328
+
(repeat |\kn{72}| |\kv{i}|
329
+
(line |\kn{80}| |\kn{60}|
330
+
(|\km{+}| |\kn{80}| (|\km{*}| |\kn{55}| (|\km{cos}| (|\km{*}| |\kv{i}| |\kn{0.087}|))))
331
+
(|\km{+}| |\kn{60}| (|\km{*}| |\kn{55}| (|\km{sin}| (|\km{*}| |\kv{i}| |\kn{0.087}|))))))
332
+
\end{lstlisting}
333
+
334
+
\subsection{圆形}
335
+
336
+
圆形卡片使用 \texttt{outline} 模式和嵌套 \texttt{repeat} 循环。``Ripple'' 绘制30个同心圆，颜色向蓝色渐变。
337
+
338
+
\begin{figure}[h]
339
+
\centering
340
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-ripple.png}}%
341
+
\hfill%
342
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-mondrian.png}}
343
+
\caption{``Ripple''（圆形）和 ``Mondrian''（方块）。}
344
+
\label{fig:circles-boxes}
345
+
\end{figure}
346
+
347
+
\subsection{方块与构图}
348
+
349
+
``Mondrian'' 用四个彩色矩形重现原色网格。``Nest'' 绘制10个内嵌矩形，色调逐渐变化。
350
+
351
+
\subsection{数学与曲线}
352
+
353
+
这些卡片使用 \texttt{plot} 与数学函数。``Lissajous'' 用600个点绘制利萨如图形。``Spiral'' 绘制极坐标螺旋线。
354
+
355
+
\begin{figure}[h]
356
+
\centering
357
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-lissajous.png}}%
358
+
\hfill%
359
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-sierpinski.png}}
360
+
\caption{``Lissajous''（数学曲线）和 ``Sierpinski''（位与分形）。}
361
+
\label{fig:math}
362
+
\end{figure}
363
+
364
+
\subsection{颜色与渐变}
365
+
366
+
``Sierpinski'' 使用位与运算生成谢尔宾斯基三角形：\texttt{(if (= 0 (\& x y)) (plot (+ 16 x) y))}。``Sunflower'' 沿黄金角螺旋绘制500个点，颜色循环变化。
367
+
368
+
\subsection{海龟图形}
369
+
370
+
海龟卡片使用 \texttt{crawl}、\texttt{left}、\texttt{right} 和 \texttt{face}。一个五角星使用 \texttt{(right 144)}。一棵树使用 \texttt{later} 进行递归分支。一片雪花嵌套科赫曲线段。
371
+
372
+
\begin{figure}[h]
373
+
\centering
374
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-star.png}}%
375
+
\hfill%
376
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-tree.png}}
377
+
\caption{``Star'' 和 ``Tree'' --- 海龟图形卡片。}
378
+
\label{fig:turtle}
379
+
\end{figure}
380
+
381
+
\begin{lstlisting}
382
+
; Star — 5 sides, 144-degree turns
383
+
(wipe |\kt{navy}|)
384
+
(ink |\kt{yellow}|)
385
+
(repeat |\kn{5}| |\kv{i}| (crawl |\kn{50}|) (right |\kn{144}|))
386
+
\end{lstlisting}
387
+
388
+
\subsection{极简公案}
389
+
390
+
卡组中最短的卡片。``Horizon'' 是三行：深色天空，金色大地。``Pip'' 是黑色上的一个红点。这些卡片接近最小可行程序------产生可识别图像所需的最少代码量。
391
+
392
+
\begin{figure}[h]
393
+
\centering
394
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-horizon.png}}%
395
+
\hfill%
396
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-pip.png}}
397
+
\caption{``Horizon'' 和 ``Pip'' --- 极简公案（各2--3行）。}
398
+
\label{fig:koans}
399
+
\end{figure}
400
+
401
+
\begin{lstlisting}
402
+
; Pip — the minimum card
403
+
(wipe |\kt{black}|)
404
+
(ink |\kt{red}|)
405
+
(circle |\kn{80}| |\kn{60}| |\kn{4}|)
406
+
\end{lstlisting}
407
+
408
+
\begin{figure*}[t]
409
+
\centering
410
+
\fbox{\includegraphics[height=5.5cm]{card-nest.png}}%
411
+
\hfill%
412
+
\fbox{\includegraphics[height=5.5cm]{card-sunflower.png}}%
413
+
\hfill%
414
+
\fbox{\includegraphics[height=5.5cm]{card-snowflake.png}}%
415
+
\hfill%
416
+
\fbox{\includegraphics[height=5.5cm]{card-spiral.png}}
417
+
\caption{四张完整卡片展示格式：标题、渲染输出和源代码。从左到右：``Nest''、``Sunflower''、``Snowflake''、``Spiral''。每张卡片都是自包含的------图像下方的源代码就是完整程序。这些是简单的绘图练习，而非格式潜力的表达。}
418
+
\label{fig:four-cards}
419
+
\end{figure*}
420
+
421
+
% ============ 5. 布局 ============
422
+
423
+
\section{布局}
424
+
\label{sec:layouts}
425
+
426
+
卡片格式没有固定布局。三个元素（标题、输出、源代码）的排列方式决定了卡片的可供性------你可以用它在物理上和社会上做什么。本节探讨布局变体及其后果。
427
+
428
+
\begin{figure*}[t]
429
+
\centering
430
+
\includegraphics[width=\textwidth]{layout-comparison.png}
431
+
\caption{三种布局策略。\textbf{纵向：}标题/图像/源代码从上到下堆叠，针对手机屏幕和纵向打印优化。\textbf{横向：}图像在左，标题和源代码在右，适合横向卡片和并排浏览。\textbf{明信片：}正面是渲染输出，背面是源代码和元数据------一张可邮寄的卡片，翻转后才能看到程序。}
432
+
\label{fig:layouts}
433
+
\end{figure*}
434
+
435
+
\subsection{纵向（屏幕/打印）}
436
+
437
+
默认布局将标题、图像和源代码从上到下堆叠。这是笔记本布局------在手机或 Jupyter 笔记本中自然滚动。用于打印时，对应4$\times$6英寸纵向卡片。读者的目光从名称向下移动到图像再到代码，追踪程序与其输出之间的关系。
438
+
439
+
\subsection{横向（卡组/风景）}
440
+
441
+
横向布局将渲染图像放在左边，源代码放在右边。这适用于在桌子上展开卡片、用于幻灯片演示以及并排比较。两张卡片并排放置形成双联画------观者可以同时比较程序和输出。
442
+
443
+
\subsection{明信片（邮寄艺术）}
444
+
445
+
明信片布局将正面与背面分开。正面仅显示渲染图像，满版出血，无文字。背面显示源代码、作者署名、短代码（\texttt{\$xyz}）和邮票区域。收件人先看到图像------一个视觉制品。翻转卡片揭示程序：产生它的指令。卡片既是艺术品又是可执行乐谱，取决于你阅读的是哪一面。
446
+
447
+
\begin{figure*}[h]
448
+
\centering
449
+
\includegraphics[width=\textwidth]{layout-affordances.png}
450
+
\caption{卡片格式的社会和物理可供性。每种可供性源于卡片的物质性：它可以手递手\textbf{分享}，作为明信片\textbf{邮寄}，\textbf{交换}和收藏，在教学序列中\textbf{用于教学}，作为图形乐谱\textbf{演奏}，或\textbf{钉}在画廊墙上。}
451
+
\label{fig:affordances}
452
+
\end{figure*}
453
+
454
+
\subsection{卡组编排}
455
+
456
+
卡片不是单独的物件。它们组成卡组，卡组的编排创造意义。一个\emph{教学序列}按概念排序卡片：先是方块（坐标），然后线条（三角函数），圆形（半径和重复），数学曲线（plot 和正弦），海龟图形（相对运动），最后是公案（极简表达）。一个\emph{画廊网格}在墙上空间排列卡片，邀请跨类别比较。一副\emph{洗牌卡组}随机化顺序，在分形和地平线之间、在树和点之间产生意想不到的并置。
457
+
458
+
\begin{figure}[h]
459
+
\centering
460
+
\includegraphics[width=\columnwidth]{layout-decks.png}
461
+
\caption{卡组编排。左：按类别展开的卡片（线条、圆形、方块、数学、海龟、公案），每个类别有多张卡片堆叠。右：一个画廊网格，卡片按空间排列供浏览。}
462
+
\label{fig:decks}
463
+
\end{figure}
464
+
465
+
% ============ 6. 现实中的卡片 ============
466
+
467
+
\section{现实中的卡片}
468
+
\label{sec:wild}
469
+
470
+
笔记本卡片是练习。真正的 \kidlisp{} 语料库------59位作者创建的16,000多个程序------包含使用完整运行时的作品：动画、音频、嵌入层、渐变淡出、随机放置和定时语法。这些作品足够短，适合卡片格式，但远比笔记本示例更具表现力。它们的预览图像由 oven 服务（基于 Puppeteer 的屏幕捕获）渲染，并通过 CDN 提供。
471
+
472
+
\begin{figure*}[t]
473
+
\centering
474
+
\includegraphics[height=7cm]{user-card-bop.png}%
475
+
\hfill%
476
+
\includegraphics[height=7cm]{user-card-roz.png}%
477
+
\hfill%
478
+
\includegraphics[height=7cm]{user-card-cow.png}%
479
+
\hfill%
480
+
\includegraphics[height=7cm]{user-card-r2f.png}
481
+
\caption{来自 \kidlisp{} 活跃语料库的四张卡片，由 oven 服务渲染。从左到右：\texttt{\$bop}（12,188次播放------最受欢迎的作品，4行），\texttt{\$roz}（7,064次播放，3行），\texttt{\$cow}（5,980次播放------通过 \texttt{\$39i} 和 \texttt{\$r2f} 嵌入其他两个作品的组合），\texttt{\$r2f}（4,413次播放，3行随机方块放置）。全部出自 @jeffrey。这些程序使用了 Python 解释器中不存在的功能------动画、随机性（\texttt{?}）、渐变淡出（\texttt{fade:}）、嵌入层（\texttt{\$code}）------但它们的源代码仍然放得下一张卡片。}
482
+
\label{fig:user-cards}
483
+
\end{figure*}
484
+
485
+
\subsection{真实作品增添了什么}
486
+
487
+
笔记本卡片使用 \kidlisp{} 的静态子集。\texttt{kidlisp.com} 上的真实作品使用完整运行时：
488
+
489
+
\begin{itemize}
490
+
\item \textbf{动画。}程序每帧重新求值。\texttt{frame} 和 \texttt{time} 自动变化。单帧截图捕捉一个活跃作品的一个瞬间。
491
+
\item \textbf{随机性。}\texttt{?} 运算符每帧从列表中产生一个随机值。\texttt{(ink (? red blue green))} 在颜色间闪烁。
492
+
\item \textbf{渐变淡出。}\texttt{fade:red-blue-black} 在画布上插值多停点渐变，由 \texttt{frame} 计数驱动。一个表达式替代了数页手动颜色数学。
493
+
\item \textbf{嵌入。}\texttt{(\$cow)} 从 MongoDB 获取作品 \texttt{cow}，在离屏缓冲区中求值，并合成结果。作品构建于作品之上。
494
+
\item \textbf{定时。}\texttt{1s... (zoom 0.5)} 每秒应用一次缩放。无需显式动画循环。
495
+
\end{itemize}
496
+
497
+
这些功能使程序保持简短，同时极大地扩展了其表达能力。\texttt{\$bop}------播放次数最多的作品，12,188次观看------只有四行：紫色背景、彩虹闪烁的墨水、一条随机线和一个模糊。在卡片上，它看起来像动态绘画的一个冻结瞬间。在浏览器中，它确实是。
498
+
499
+
\subsection{卡片作为快照}
500
+
501
+
动画作品的卡片必然是不完整的。它捕捉了一个时间过程的一帧。这种不完整性是格式的一部分：卡片邀请你输入代码，看看它实际做了什么。静态图像是承诺。源代码是兑现。短代码（\texttt{\$bop}）是桥梁------在 \texttt{kidlisp.com} 中输入它，卡片就会活过来。
502
+
503
+
% ============ 7. 卡片可能成为什么 ============
504
+
505
+
\section{卡片可能成为什么}
506
+
\label{sec:futures}
507
+
508
+
卡片格式还很年轻。当前笔记本是概念验证------28个离线渲染的程序。但短程序与物理卡片之间的对应关系暗示了几个方向。
509
+
510
+
\subsection{集换卡}
511
+
512
+
KidLisp 卡片具有大多数软件所不具备的可收藏性。每张卡片有名称、视觉身份、短代码（\texttt{\$xyz}）和作者。卡片可以印刷、编号和交换。稀有卡片可能使用晦涩的语言特性，或从最少的代码产生意想不到的复杂输出。卡片的"稀有度"就是其信息密度：从多少个字符中涌现出多少视觉复杂性。
513
+
514
+
\subsection{教学序列}
515
+
516
+
当前笔记本中的七个类别暗示了一种教学顺序：从方块开始（简单坐标），进而到线条（三角函数）、圆形（半径和重复）、数学曲线（plot 和正弦）、海龟图形（相对运动），最后是公案（极简表达）。每张卡片教授一个概念。教师可以给学生一副实体卡牌，要求他们复现每张卡片、修改它或在同一类别中创建新卡片。
517
+
518
+
\subsection{印刷乐谱}
519
+
520
+
在音乐中，乐谱是产生时间事件的指令。KidLisp 卡片是产生视觉事件的指令。卡片可以作为图形乐谱发挥作用，延续 Cornelius Cardew、John Cage 和 Fluxus 事件乐谱的传统。演奏者收到一张卡片，解读代码（在 \texttt{kidlisp.com} 上输入、大声朗读、手绘），然后产生一个事件。卡片就是乐谱。渲染是一种可能的实现。
521
+
522
+
\subsection{邮寄艺术}
523
+
524
+
4$\times$6英寸的 KidLisp 卡片就是一张明信片。正面展示渲染图像。背面展示源代码、作者署名和用于在线查找的短代码。带有可执行内容的邮寄艺术------收件人可以输入代码，在自己的屏幕上看到图像重新生成。物理卡片和数字程序是同一作品的两种媒介。
525
+
526
+
\subsection{生成式文具}
527
+
528
+
由于 Python 解释器是确定性的且独立运行的，卡片可以在没有网络访问的情况下批量渲染用于印刷制作。一套卡片可以印刷成小册子、独立出版物或盒装套件。\texttt{cards-convert.mjs} 管线已经能从论文格式生成4$\times$6英寸的 PDF 卡片；将其扩展为同时包含渲染的程序输出和源代码是自然的下一步。
529
+
530
+
\subsection{约束作为生成原则}
531
+
532
+
卡片格式最有趣的后果是它如何反馈到语言中。放不进卡片的程序暗示着缺失的抽象------或者暗示程序做得太多。卡片约束鼓励经济性：找到产生最有趣图像的三行程序。这是 Oulipo 传统中的生成性约束------任意的形式限制产生意想不到的创造性结果。
533
+
534
+
% ============ 6. 相关工作 ============
535
+
536
+
\section{相关工作}
537
+
538
+
\textbf{印刷代码。}演示场景中的"sizecoding"传统（256字节以下的程序）与最小程序产生最大输出的美学一脉相承。\kidlisp{} 卡片更接近"代码诗"传统，其中源代码本身作为文本与其输出一起被阅读。
539
+
540
+
\textbf{图形乐谱。}Cardew 的 \emph{Treatise}（1967）和 Cage 的 \emph{Notations}（1969）确立了视觉符号可以作为演奏指令而不规定特定实现。KidLisp 卡片的不同之处在于它们是完全可执行的------渲染是确定性的，不开放解读。但卡片即乐谱的框架邀请重新诠释：如果你每次以不同方式"演奏"卡片会怎样？
541
+
542
+
\textbf{集换卡游戏。}\emph{Magic: The Gathering}（1993）等游戏证明，具有结构化元数据（名称、类型、规则文本、插图）的卡片创造了丰富的组合空间。KidLisp 卡片具有自然的元数据（标题、类别、函数数量、行数、输出复杂度），可以支持类似的游戏机制。
543
+
544
+
\textbf{计算笔记本。}Jupyter 笔记本已经将代码和输出结合在一起。KidLisp Cards 笔记本是一个 Jupyter 笔记本，但有一个特定的约束：每个单元格是一张自包含的卡片，而不是更长计算中的一个步骤。笔记本是画廊，不是叙事。
545
+
546
+
% ============ 7. 结论 ============
547
+
548
+
\section{结论}
549
+
550
+
KidLisp 卡片源于一个简单的观察：当程序足够短时，它们就能放在卡片上。卡片格式------标题、图像、源代码------将程序变成可以打印、邮寄、收藏、用于教学和演奏的物理制品。Python 渲染管线实现了离线批量制作。七个类别的目录提供了进入语言的策展入口。
551
+
552
+
该格式是一项进行中的工作。当前28张卡片的卡组是起点，不是完成的收藏。问题不在于制作多少张卡片，而在于哪些程序值得成为卡片------哪些三行构图产生的图像值得握在手中。
553
+
554
+
笔记本、解释器和卡片目录可在 \url{https://github.com/whistlegraph/aesthetic-computer} 获取。程序可在 \url{https://kidlisp.com} 上创建和分享。
555
+
556
+
\vspace{0.5em}
557
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
558
+
559
+
% ============ 参考文献 ============
560
+
561
+
\bibliographystyle{plainnat}
562
+
\bibliography{references}
563
+
564
+
\end{document}
+433
papers/arxiv-open-schools/open-schools-da.tex
+433
papers/arxiv-open-schools/open-schools-da.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[11pt, a4paper]{article}
3
+
4
+
\usepackage{fontspec}
5
+
\usepackage{unicode-math}
6
+
\setmainfont{Latin Modern Roman}
7
+
\setsansfont{Latin Modern Sans}
8
+
\setmonofont{Latin Modern Mono}[Scale=0.88]
9
+
10
+
\usepackage{graphicx}
11
+
\graphicspath{{figures/}{../arxiv-ac/figures/}}
12
+
\usepackage{booktabs}
13
+
\usepackage{tabularx}
14
+
\usepackage{ragged2e}
15
+
\usepackage{microtype}
16
+
\usepackage{natbib}
17
+
\usepackage{multicol}
18
+
19
+
\usepackage[
20
+
top=2.2cm, bottom=2.5cm, left=2.0cm, right=2.0cm
21
+
]{geometry}
22
+
23
+
\makeatletter
24
+
\def\input@path{{../}}
25
+
\makeatother
26
+
\usepackage{ac-paper-layout}
27
+
28
+
\newcommand{\acos}{\textsc{AC Native OS}}
29
+
30
+
\hypersetup{
31
+
pdftitle={Få lukket kildekode ud af skolerne: Hver Chromebook er en nægtet adgang},
32
+
}
33
+
34
+
\begin{document}
35
+
36
+
\thispagestyle{empty}
37
+
\vspace*{\fill}
38
+
\begin{center}
39
+
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
40
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Få lukket kildekode ud af skolerne}\par
41
+
\vspace{0.3em}
42
+
{\fontsize{10pt}{12pt}\selectfont\color{acpink} Hver Chromebook er en nægtet adgang}\par
43
+
\vspace{0.8em}
44
+
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
45
+
{\small\color{acgray} Aesthetic.Computer}\par
46
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
47
+
\vspace{0.8em}
48
+
\rule{0.6\textwidth}{1pt}\par
49
+
\vspace{0.4em}
50
+
{\small\color{acpink!40}\textit{arbejdsudkast --- ikke til citation}}\par
51
+
\vspace{0.3em}
52
+
{\footnotesize\color{acgray} Marts 2026}\par
53
+
\end{center}
54
+
\vspace*{\fill}
55
+
\clearpage
56
+
57
+
\begin{multicols}{2}
58
+
59
+
% ============================================================
60
+
% ABSTRACT
61
+
% ============================================================
62
+
63
+
\begin{abstract}
64
+
\noindent
65
+
Der er over 50 millioner Chromebooks i amerikanske skoler. Hver eneste er en kapabel computer, der kører et låst, lukket styresystem, som kanaliserer enhver elevinteraktion gennem Googles overvågningsinfrastruktur. Eleven kan ikke se, hvordan maskinen fungerer. Eleven kan ikke ændre maskinen. Eleven kan ikke eje maskinen i nogen meningsfuld forstand. I en tid med store sprogmodeller---hvor ``alle er programmører'' ikke længere er et slogan, men en materiel virkelighed---er dette en pædagogisk forsømmelse. Denne artikel argumenterer for, at enhver elev fortjener en fri og åben styresystemstak: én hvor Chromebooken bliver en port til elevens egen vej gennem logik, kreativitet, internettet, fællesskab og det computationelle landskab som helhed. Vi præsenterer de tekniske, pædagogiske, økonomiske og politiske argumenter for at erstatte lukket skolecomputerinfrastruktur med åbne alternativer, idet vi trækker på internationale præcedenser fra Kerala, Slesvig-Holsten og Frankrig, miljødata om planlagt forældelse, føderale og statslige retssager mod elevers overvågning, samt ny forskning i AI-assisteret programmeringsundervisning. Vi præsenterer \acos{}~\citep{scudder2026acos} som én konkret implementering af denne vision.
66
+
\end{abstract}
67
+
68
+
% ============================================================
69
+
% 1. THE CHROMEBOOK PROBLEM
70
+
% ============================================================
71
+
72
+
\section{Chromebook-problemet}
73
+
74
+
I 2012 begyndte Google aggressivt at markedsføre Chromebooks til amerikanske skoledistrikter. Budskabet var enkelt: billig hardware, ingen IT-overhead, alt i skyen. I 2026 udgør Chromebooks ca.\ 60\% af enhederne leveret til amerikanske K--12-skoler med en installeret base på over 50 millioner enheder~\citep{google2024chromeos}. En hel generation af amerikanske elever bliver uddannet på maskiner, de ikke kan forstå, ikke kan ændre og ikke ejer---selv når skolen har betalt for dem.
75
+
76
+
ChromeOS er proprietær software. Kildekoden er ikke tilgængelig til inspektion. Browseren er hele grænsefladen. Hvert dokument lever i Google Drev. Enhver søgning går gennem Google. Enhver interaktion logges, analyseres og bruges til at opbygge adfærdsprofiler, der følger eleven ind i voksenlivet~\citep{zuboff2019surveillance}.
77
+
78
+
Dette er ikke en bekymring i periferien. Dette er \emph{arkitekturen} bag, hvordan amerikanske børn lærer at bruge computere. Mediet er budskabet~\citep{mcluhan1964understanding}: Chromebooken lærer, at en computer er en enhed til forbrug af cloudtjenester ejet af en virksomhed. Den lærer, at dit arbejde lever på en andens server. Den lærer, at maskinen ikke er din at forstå.
79
+
80
+
\subsection{Hvad eleven ikke kan gøre}
81
+
82
+
På en Chromebook i skolen kan en elev ikke:
83
+
84
+
\begin{itemize}
85
+
\item Installere et programmeringssprog-runtime (Python, Node.js, GCC)
86
+
\item Køre en lokal webserver eller kompilere kode
87
+
\item Inspicere styresystemets kildekode
88
+
\item Ændre opstartsekvensen
89
+
\item Tilslutte hardwareperiferiudstyr til fysisk computing
90
+
\item Bruge maskinen offline til seriøst arbejde
91
+
\item Opbevare sine data på enheden uden cloudsynkronisering
92
+
\item Vælge sin egen software
93
+
\item Forstå, hvad maskinen gør med deres opmærksomhed
94
+
\end{itemize}
95
+
96
+
ChromeOS inkluderer en Linux-container (Crostini), der i teorien kunne levere disse muligheder, men skolernes IT-administratorer deaktiverer den næsten altid. Maskinen leveres med en terminal og låser den derefter. Hver af disse restriktioner er en lukket dør. Hver lukket dør er en vej, eleven aldrig vil opdage. Chromebooken er ikke en port---den er en \emph{låge}.
97
+
98
+
\subsection{Skyen som udlejer}
99
+
100
+
Når en elevs arbejde lever i Google Drev, er de lejere, ikke ejere. Google kan ændre servicevilkårene. Google kan nedlægge produkter. Google kan tilbagekalde adgangen. Eleven dimitterer og mister sin Google-skolekonto---og med den hvert dokument, hvert projekt, hvert kreativt artefakt, de producerede under deres uddannelse.
101
+
102
+
Dette er ikke hypotetisk. Det sker hvert år i hvert skoledistrikt. Elever mister adgang til års arbejde, fordi den institution, der købte deres cloudkonto, afvikler den. Arkitekturen \emph{garanterer} dette resultat: eleven havde aldrig sine filer. De havde tilladelse til at tilgå filer på Googles servere, og den tilladelse blev tilbagekaldt.
103
+
104
+
Freire kaldte dette ``bankmodellen'' for uddannelse~\citep{freire1970pedagogy}: viden indsat i elever af autoriteter. Chromebooken gør metaforen bogstavelig. Elevens arbejde indsættes i en bank, de ikke kontrollerer, ikke kan revidere og til sidst vil blive låst ude af.
105
+
106
+
\subsection{Planlagt forældelse: AUE-problemet}
107
+
108
+
Hver Chromebook leveres med en Auto Update Expiration (AUE)-dato, hvorefter Google ikke leverer sikkerhedsopdateringer, funktionsopdateringer eller browseropdateringer. Historisk sat til 6,5 år fra \emph{platformens} første udgivelse---ikke købsdatoen---kan en skole, der køber en Chromebook sent i en platformscyklus, kun modtage 3--4 års opdateringer. Google forlængede dette til 10 år for enheder lanceret i 2024, men den installerede base af kortlivede maskiner er stadig enorm.
109
+
110
+
U.S. PIRG Education Fund estimerede, at AUE-politikker ville tvinge den for tidlige bortskaffelse af 21,5 millioner funktionelt fungerende Chromebooks inden 2024, hvilket ville koste skoler ca.\ \$1,8 milliarder i unødvendige udskiftninger~\citep{pirg2023chromebook}. Disse er maskiner med fungerende processorer, fungerende skærme, fungerende tastaturer---gjort forældede af en softwarepolitik, ikke af hardwarefejl.
111
+
112
+
Kontrasten med Linux er absolut. En 2015 ThinkPad med Ubuntu LTS modtager fortsat sikkerhedsopdateringer på ubestemt tid. Der er ingen kunstig udløbsdato knyttet til hardwaremodellen. Maskinen forbliver nyttig, så længe hardwaren fungerer.
113
+
114
+
% ============================================================
115
+
% 2. THE SURVEILLANCE MACHINE
116
+
% ============================================================
117
+
118
+
\section{Overvågningsmaskinen}
119
+
\label{sec:surveillance}
120
+
121
+
Google leverer Chromebooks til skoler under kostpris, fordi elever er et fanget marked for adfærdsdata~\citep{zuboff2019surveillance, doctorow2020attack}. En elev, der vokser op i Googles økosystem---Gmail, Google Docs, Google Drev, Google Classroom, YouTube---er en kunde for livet. Chromebooken er ikke en velgørende donation. Det er en kundeerhvervelsesstrategi rettet mod børn.
122
+
123
+
\subsection{Hvad Google indsamler}
124
+
125
+
De data, der indsamles fra elevers Chromebooks, inkluderer:
126
+
127
+
\begin{itemize}
128
+
\item Enhver søgeforespørgsel og hvert besøgt websted
129
+
\item Hvert dokument åbnet, redigeret og delt
130
+
\item Hver YouTube-video set og i hvor lang tid
131
+
\item Tastetryk-timing-mønstre og loginfrekvens
132
+
\item Placeringsdata (på cellulære modeller)
133
+
\item Sociale grafer (hvem samarbejder med hvem i Google Docs)
134
+
\item Enhedsdiagnostik og app-brugstelemetri
135
+
\end{itemize}
136
+
137
+
Google hævder, at data indsamlet under Workspace for Education ``kernetjenester'' ikke bruges til reklame. Men ``yderligere tjenester''---YouTube, Google Søgning, Google Maps når man er logget ind---opererer under andre vilkår. Elever på skole-Chromebooks bruger disse yderligere tjenester konstant, og dataen strømmer til Googles reklameinfrastruktur.
138
+
139
+
\subsection{Retssager}
140
+
141
+
Retssagerne tegner et dystert billede. I 2019 betalte Google \$170 millioner til FTC og New Yorks statsadvokat for YouTubes COPPA-overtrædelser---indsamling af data fra børn uden forældresamtykke~\citep{google2019coppa}. I 2020 sagsøgte New Mexicos statsadvokat Hector Balderas Google direkte for at indsamle personlige data fra børn, der bruger Chromebooks i skoler~\citep{newmexico2020google}. EFF indgav en FTC-klage i 2015, der dokumenterede, at Google dataminerede elevers browsingaktivitet gennem Chromebooks~\citep{eff2015chromebook}. I 2024 indgav en koalition af digitale rettighedsorganisationer yderligere FTC-klager vedrørende fortsat elevers overvågning~\citep{eff2024monitoring}. Gruppesøgsmål vedrørende biometrisk dataindsamling fra elever under Illinois' BIPA-lov er igangværende.
142
+
143
+
Disse data indsamles fra mindreårige, i et institutionelt miljø hvor deltagelse er obligatorisk, på maskiner eleven ikke valgte og ikke kan konfigurere. Eleven kan ikke fravælge. Forælderen kan ofte ikke fravælge. Skoledistriktet underskrev en kontrakt, og børnene er bundet af den.
144
+
145
+
\subsection{Overvågningssoftware}
146
+
147
+
Ud over Googles egen dataindsamling lægger skoledistrikter yderligere overvågningssoftware---Gaggle, GoGuardian, Securly---oven på Chromebooks. EFF dokumenterede, at disse værktøjer overvåger privat kommunikation og uforholdsmæssigt rammer udsatte, minoritets- og LGBTQ-unge~\citep{eff2024monitoring}. Af 152 ed-tech-tjenester undersøgt af EFF havde kun 118 offentliggjort privatlivspolitikker; langt færre adresserede dataopbevaring, kryptering eller afidentificering.
148
+
149
+
Winner argumenterede for, at artefakter har politik~\citep{winner1980artifacts}. Chromebookens politik er klar: den er et overvågningsinstrument indsat i en kontekst, hvor de overvågede ikke har noget valg, ingen mulighed for klage og ingen forståelse af, hvad der tages fra dem.
150
+
151
+
Et frit og åbent styresystem indsamler ingen telemetri. Det ringer ikke hjem til nogen virksomhed. Det opbygger ingen adfærdsprofil. Elevens opmærksomhed, deres nysgerrighed, deres fejl, deres udforskning---alt dette forbliver privat, fordi maskinen ikke har noget økonomisk incitament til at observere dem.
152
+
153
+
% ============================================================
154
+
% 3. THE LLM INFLECTION
155
+
% ============================================================
156
+
157
+
\section{Alle er programmører nu}
158
+
159
+
Store sprogmodeller har ændret programmering\-ens økonomi. En elev, der kan beskrive, hvad de vil have, i naturligt sprog, kan producere fungerende kode. Barrieren for computationel skabelse er kollapset fra ``års teknisk uddannelse'' til ``evnen til at formulere en idé.'' Karpathys observation om, at ``det hotteste nye programmeringssprog er engelsk,'' er ikke længere overdrivelse---det er en beskrivelse af materiel virkelighed.
160
+
161
+
Dette er det vigtigste skift i computing siden den personlige computer. Og det gør Chromebook-problemet \emph{katastrofalt værre}.
162
+
163
+
\subsection{Den nye læsefærdighed}
164
+
165
+
Hvis alle kan programmere, så er programmering læsefærdighed. Og læsefærdighed kræver værktøjer, som den læsefærdige person kan eje. Man lærer ikke et barn at læse ved at give dem en låst bog, der kun kan åbnes i en bestemt bygning med en bestemt virksomhedskonto. Man giver dem bogen. De tager den med hjem. De læser den i sengen. De skriver i margenerne. De låner den til en ven.
166
+
167
+
En elev med en LLM og et åbent styresystem kan:
168
+
169
+
\begin{itemize}
170
+
\item Bygge et værktøj til at organisere deres lektier
171
+
\item Skrive et spil og dele det med klassekammerater
172
+
\item Automatisere en gentagende opgave, som deres lærer giver
173
+
\item Skabe en lille virksomhed, der sælger software til deres lokalsamfund
174
+
\item Bidrage til open source-projekter, der tjener menneskeheden
175
+
\item Forstå og ændre de systemer, der styrer deres digitale liv
176
+
\item Udforske logik, matematik og sprog gennem direkte manipulation
177
+
\item Bygge instrumenter til kunstnerisk udtryk
178
+
\end{itemize}
179
+
180
+
En elev med en LLM og en Chromebook kan bruge Google Docs hurtigere.
181
+
182
+
Ko (University of Washington) har argumenteret for, at hvis AI kan skrive kode, må CS-uddannelse skifte mod systemtænkning, debugging og evaluering---alt sammen kræver adgang til rigtige udviklingsmiljøer, ikke sandkassebrowsere~\citep{denny2024computing}. Krishnamurthi (Brown University) har været kritisk over for tilgange, der reducerer programmering til prompting. Den fremvoksende konsensus i CS-uddannelsesforskning er, at LLM'er gør fuld stack-adgang \emph{vigtigere}, ikke mindre~\citep{prather2024robots}: elever skal kunne køre, debugge, ændre og forstå genereret kode. Chromebooks gør alle fire sværere.
183
+
184
+
\subsection{Chromebooken kan ikke eksekvere}
185
+
186
+
Her er det konkrete svigt: LLM'en producerer et Python-script, og Chromebooken kan ikke køre det. LLM'en genererer en webserver, og Chromebooken kan ikke hoste den. LLM'en skriver C-kode, og Chromebooken har ingen compiler. LLM'en lærer eleven, hvordan et styresystem fungerer, og Chromebooken lader dem ikke inspicere ét.
187
+
188
+
På en typisk skole-Chromebook (MediaTek- eller Celeron-processor, 4\,GB RAM) kæmper selv Linux-containeren---når den er aktiveret---med at køre basale udviklingsværktøjskæder. At køre en lokal LLM er fysisk umuligt: selv en kvantiseret 1B-parametermodel kræver mere hukommelse, end de fleste skole-Chromebooks har.
189
+
190
+
Alternativet er trivielt. En brugt ThinkPad med 8\,GB RAM, der kører Linux, kan eksekvere enhver LLM-genereret kode, køre en lokal 3B-parametermodel via Ollama med interaktive hastigheder, hoste en webserver, kompilere programmer og give eleven root-adgang til hele systemet. Hardwaren eksisterer. Softwaren er gratis. Chromebooken er flaskehalsen.
191
+
192
+
\subsection{Den åndelige dimension}
193
+
194
+
Dette handler ikke kun om økonomi eller karriereforberedelse. Der er en åndelig dimension ved computing, som Chromebook-arkitekturen udsletter.
195
+
196
+
Når en elev skriver et program, der gør noget, de ikke forventede---når maskinen overrasker dem med emergent adfærd fra regler, de selv definerede---oplever de noget dybtgående. De møder grænsen mellem intention og konsekvens. De lærer, at systemer har deres egen logik. De udvikler et forhold til abstraktion selv.
197
+
198
+
Papert forstod dette~\citep{papert1980mindstorms}: Logo handlede ikke om at undervise i programmering. Det handlede om at give børn et medium til at tænke over tænkning. Skildpadden var et middel til erkendelse.
199
+
200
+
LLM'er forstærker dette tusinddobbelt. En elev kan nu have en \emph{samtale} med det computationelle medium. De kan spørge ``hvad nu hvis?'' og få svar på sekunder. De kan iterere på ideer med tankens hastighed. De kan udforske veje, som ingen læseplan forudså.
201
+
202
+
Men kun hvis maskinen lader dem. En Chromebook lader dem ikke. En Chromebook siger: du må forbruge tjenester. Du må ikke skabe infrastruktur. Du må ikke køre din egen kode på din egen måde på din egen maskine.
203
+
204
+
% ============================================================
205
+
% 4. WHAT STUDENTS DESERVE
206
+
% ============================================================
207
+
208
+
\section{Hvad enhver elev fortjener}
209
+
210
+
Enhver elev fortjener en computer, der:
211
+
212
+
\begin{enumerate}
213
+
\item \textbf{De kan forstå.} Styresystemets kildekode bør være tilgængelig til inspektion. Ikke som et abstrakt princip, men som en praktisk realitet: eleven bør kunne læse den kode, der kører, når de trykker på en tast.
214
+
215
+
\item \textbf{De kan ændre.} Hvis eleven vil ændre, hvordan maskinen opfører sig, bør de kunne det. Ikke gennem en app-butik, ikke gennem et indstillingspanel, men ved at ændre koden.
216
+
217
+
\item \textbf{De kan eje.} Elevens arbejde bør leve på elevens maskine. Ikke på en virksomhedsserver, ikke i en cloudkonto, der bliver afviklet, når de dimitterer.
218
+
219
+
\item \textbf{De kan dele.} Eleven bør kunne give sin software til en ven. Ikke gennem en platform, ikke gennem en markedsplads, men ved at kopiere en fil.
220
+
221
+
\item \textbf{De kan ødelægge.} Eleven bør kunne ødelægge maskinen og reparere den. Sådan lærer man. Et system, der ikke kan ødelægges, kan ikke forstås.
222
+
223
+
\item \textbf{De kan tage med sig.} Når eleven forlader skolen, følger computeren---og alt på den---med dem. Deres computationelle liv er ikke lejet. Det er deres.
224
+
225
+
\item \textbf{Respekterer deres opmærksomhed.} Styresystemet bør ikke indeholde reklame, adfærdssporing eller engagementsoptimering. Elevens opmærksomhed tilhører eleven.
226
+
227
+
\item \textbf{Forbinder dem med fællesskab.} Eleven bør kunne bidrage til det computationelle landskab---skrive kode, som andre bruger, deltage i open source-projekter, bygge værktøjer, der tjener deres fællesskab og opretholder deres livsstil og velbefindende.
228
+
\end{enumerate}
229
+
230
+
Hvert eneste af disse krav overtrædes af ChromeOS. Hvert eneste af dem opfyldes af et frit og åbent styresystem.
231
+
232
+
% ============================================================
233
+
% 5. IT ALREADY WORKS
234
+
% ============================================================
235
+
236
+
\section{Det virker allerede: Internationale præcedenser}
237
+
238
+
Indvendingen om, at open source-skolecomputing er uafprøvet, er falsk. Det er blevet testet i stor skala på tre kontinenter.
239
+
240
+
\subsection{Kerala, Indien: 16.000 skoler}
241
+
242
+
Keralas KITE-program (Kerala Infrastructure and Technology for Education) gik fuldt over til fri software i 2007 på tværs af 16.000+ offentlige skoler. KITE GNU/Linux 22.04, udgivet i august 2024, kører på over 300.000 skolecomputere~\citep{kite2024gnulinux}. Distributionen inkluderer uddannelsessoftware (Krita, GCompris, PictoBlox), grundlæggende AI/ML-undervisningsværktøjer og en Wayland-displayserver. De estimerede besparelser: 30 milliarder INR (ca.\ \$400 millioner). Over 150.000 grundskolelærere er blevet uddannet. Indiens National Law School udråbte KITE som den nationale standard for open source-transformation i uddannelse.
243
+
244
+
Dette er ikke et pilotprogram. Det er en statslig udrulning, der betjener millioner af elever og har kørt kontinuerligt i næsten to årtier.
245
+
246
+
\subsection{Slesvig-Holsten, Tyskland: 30.000 PC'er}
247
+
248
+
Ved udgangen af sommeren 2025 afsluttede den tyske delstat Slesvig-Holsten migrering af næsten 30.000 statslige PC'er fra Microsoft til Linux, med yderligere 30.000 offentlige skolelærere forventet at følge~\citep{schleswig2025linux}. Erstatningerne inkluderer LibreOffice, Nextcloud, Open-Xchange og Mozilla Thunderbird. Estimerede besparelser: 15 millioner EUR alene i 2026. Danmark annoncerede en lignende overgang mellem juni og november 2025.
249
+
250
+
\subsection{Frankrig: National open source-strategi}
251
+
252
+
Frankrigs strategi for digital uddannelse 2023--2027, ledet af Alexis Kauffmann i Uddannelsesministeriet, sigter eksplicit mod digital suverænitet og reduceret afhængighed af Microsoft og Google~\citep{france2023digital}. Den nationale platform \texttt{apps.education.fr} leverer open source-værktøjer til alle franske lærere. I 2025 vedtog Frankrig et interoperabilitetsdekret, der kræver, at skoler bruger digitale værktøjer, der overholder åbne standarder---hvilket skaber en strukturel fordel for open source-løsninger.
253
+
254
+
\subsection{Penn Manor, Pennsylvania: 1.725 Linux-bærbare}
255
+
256
+
I USA udrullede Penn Manor School District i Lancaster, PA 1.725 Ubuntu-bærbare til elever i 9.--12.\ klasse~\citep{pennmanor2024linux}. Programmet inkluderer et elevstyret reparationsinitiativ, hvor elever lærer at reparere deres egne maskiner. Dette er ikke et specialdistrikt med specialfinansiering. Det er et offentligt skoledistrikt, der traf et andet valg.
257
+
258
+
\subsection{Bevægelsen ``Offentlige penge, offentlig kode''}
259
+
260
+
Free Software Foundation Europes kampagne ``Public Money? Public Code!''---der argumenterer for, at software udviklet med offentlige midler bør udgives under frie licenser---har samlet over 200 civilsamfundsorganisationer og 31.000 individuelle underskrivere~\citep{fsfe2024publiccode}. UNESCOs Dubai-erklæring om åbne uddannelsesressourcer fra 2024 forpligter formelt underskriverne til at fremme åbne ressourcer gennem AI og nye teknologier~\citep{unesco2024oer}. Global Digital Compact forpligter sig til at ``udvikle, udbrede og vedligeholde open source-software, åbne data, åbne AI-modeller og åbne standarder, der gavner samfundet.''
261
+
262
+
Disse er ikke marginale bevægelser. De er retningen for international politik.
263
+
264
+
% ============================================================
265
+
% 6. THE ECONOMICS
266
+
% ============================================================
267
+
268
+
\section{Økonomien}
269
+
270
+
\subsection{Omkostningsundskyldningen}
271
+
272
+
Chromebooks er billige. Men det er brugte bærbare med Linux også. En brugt ThinkPad T480 eller Dell Latitude 5400 koster \$100--180 i bulk og er en overlegen maskine i enhver dimension bortset fra ``administreret af Google.'' Omkostningsargumentet for Chromebooks er et argument for Googles økosystem, ikke for hardwaren.
273
+
274
+
\begin{table}[H]
275
+
\small
276
+
\centering
277
+
\begin{tabular}{lrr}
278
+
\toprule
279
+
\textbf{Tilgang} & \textbf{Omkostning} & \textbf{Eleven ejer den} \\
280
+
\midrule
281
+
Chromebook (ny) & \$250--350 & Nej \\
282
+
Chrome Edu Upgrade & +\$38/enhed & Nej \\
283
+
Google Workspace Plus & +\$5/elev/år & Nej \\
284
+
iPad (edu) & \$299+ & Nej \\
285
+
\midrule
286
+
Brugt bærbar + Linux & \$100--180 & \textbf{Ja} \\
287
+
Brugt bærbar + AC OS & \$100--180 & \textbf{Ja} \\
288
+
\bottomrule
289
+
\end{tabular}
290
+
\caption{Omkostnings- og ejerskabssammenligning. Chromebook-omkostninger ekskluderer overvågningssoftware (GoGuardian: \$5--10/enhed/år) og tvungne AUE-udskiftninger.}
291
+
\label{tab:cost}
292
+
\end{table}
293
+
294
+
Når man medregner Googles Chrome Education Upgrade (\$38/enhed), Workspace for Education Plus (\$5/elev/år), overvågningssoftware og den tvungne udskiftningscyklus fra AUE, kan de samlede ejerskabsomkostninger for en Chromebook over 5 år nå \$450--550/enhed. En brugt ThinkPad med Linux: \$100--180, med nul løbende licensomkostninger, ingen kunstig udløbsdato, og eleven beholder den.
295
+
296
+
\subsection{Udbuddet}
297
+
298
+
Maskinerne eksisterer. Anslået 50--60 millioner erhvervs-PC'er pensioneres årligt i USA. Virksomhedsleasingcyklusser pensionerer millioner af funktionelle bærbare hvert 3.--5.\ år---maskiner med moderne processorer, 8--16\,GB RAM, WiFi og 6--10 timers batteri. Organisationer som PCs for People (100.000+ enheder/år), Human-I-T (50.000+/år), Kramden Institute, Free Geek og det føderale Computers for Learning-program renoverer og distribuerer allerede disse maskiner.
299
+
300
+
Et klasseværelse med 30 kreative computinginstrumenter kan anskaffes for \$3.000--5.400 i hardware. Intet løbende abonnement. Ingen IT-supportkontrakt. Ingen administrerede konti.
301
+
302
+
\subsection{Miljøargumentet}
303
+
304
+
En typisk bærbar producerer 300--400 kg CO$_2$e i fremstilling---70--80\% af dens samlede livstids-CO$_2$-aftryk. Renovering tilføjer ca.\ 5--15 kg CO$_2$e. Circular Computings uafhængigt reviderede analyse fandt 316 kg CO$_2$e sparet per genfremstillet bærbar~\citep{circularcomputing2023carbon}. FNs Global E-waste Monitor 2024 rapporterer, at USA genererer ca.\ 7,2 Mt e-affald årligt, hvoraf kun 25\% genanvendes korrekt~\citep{un2024ewaste}.
305
+
306
+
Googles AUE-politik tvinger skoler til at kassere millioner af fungerende Chromebooks. Ret-til-reparation-lovgivning begynder at adressere dette: Oregons lov (gældende fra januar 2025) kræver, at producenter leverer dele og reparationsinformation~\citep{oregon2024repair}; New Hampshires HB1701 dækker eksplicit skoleutleverede bærbare~\citep{newhampshire2024repair}. Men lovgivning kan ikke rette en softwarepolitik, der erklærer funktionel hardware forældet.
307
+
308
+
Linux har ingen AUE. En bærbar, der kører et frit styresystem, forbliver nyttig, så længe hardwaren fungerer.
309
+
310
+
% ============================================================
311
+
% 7. THE OPEN STACK
312
+
% ============================================================
313
+
314
+
\section{Den åbne stak}
315
+
316
+
\subsection{Enhver Chromebook er allerede en Linux-maskine}
317
+
318
+
Her er det absurde: enhver Chromebook kører allerede Linux-kernen. ChromeOS er Linux med et låst brugerrum, der tvinger al interaktion gennem Googles browser. Hardwaren er fuldt i stand til at køre et frit styresystem. Google tog en fri kerne, indpakkede den i proprietære restriktioner og solgte den til skoler som en besparelsesforanstaltning.
319
+
320
+
Befrielsen af disse maskiner kræver ikke ny hardware. Den kræver at flashe ny software. Mange Chromebooks kan låses op og reflashes med en standard Linux-distribution eller med \acos{}. Maskinen \emph{vil allerede gerne være fri}. Google er låsen.
321
+
322
+
\subsection{IT-undskyldningen}
323
+
324
+
Skolernes IT-afdelinger vælger Chromebooks, fordi de er ``nemme at administrere.'' Det er sandt. Det er nemt at administrere en maskine, der ikke gør noget. Det er nemt at administrere en flåde, når hver enhed er en tynd klient for en enkelt virksomheds tjenester. Administrationsletheden er en direkte konsekvens af maskinens magtesløshed.
325
+
326
+
Spørgsmålet er: nemt for hvem? Nemt for IT-afdelingen, bestemt. Men katastrofalt for eleven. IT-afdelingens bekvemmelighed købes med elevens autonomi. Det er en dårlig handel.
327
+
328
+
Open source-administrationsværktøjer eksisterer. NixOS leverer reproducerbare systemkonfigurationer. Ansible automatiserer flådedeployment. PXE-boot muliggør nul-berørings-klargøring. \acos{}~\citep{scudder2026acos} demonstrerer, at et helt styresystem kan deployes ved at flashe et USB-drev på under et minut, med OTA-opdateringer der kræver ingen IT-infrastruktur. Penn Manor driver 1.725 Linux-bærbare med et mindre IT-team end sammenlignelige Chromebook-distrikter~\citep{pennmanor2024linux}. ``Administrationsproblemet'' er løst. Hvad der er tilbage, er institutionel inerti og et kontraktforhold med Google, der tjener institutionen, ikke eleven.
329
+
330
+
\subsection{LLM-infrastrukturen}
331
+
332
+
Et åbent system muliggør et fundamentalt anderledes forhold til AI. En enkelt brugt server (32--64\,GB RAM, eller en brugt NVIDIA T4 GPU til \$100--200) kan køre Ollama og betjene et helt klasseværelse af elever via Open WebUI---en gratis, open source LLM-frontend. Elever forbinder fra deres bærbare via en browser rettet mod den lokale server. Modeller som Llama 3.2 3B (passer i 4\,GB), DeepSeek Coder 6.7B eller Qwen 2.5 Coder 7B leverer stærk kodegenereringskapacitet.
333
+
334
+
Dette er lokal AI-infrastruktur, som skolen ejer, der ikke indsamler telemetri, der ikke sender data til nogen virksomhed, og som elever kan inspicere, ændre og lære af. Alternativet---Google Gemini integreret i Workspace for Education---tilføjer endnu et lag af virksomhedsafhængighed, endnu en datapipeline, endnu et abonnementsgebyr.
335
+
336
+
% ============================================================
337
+
% 8. THE LLM GATEWAY
338
+
% ============================================================
339
+
340
+
\section{Eleven som forfatter}
341
+
342
+
På et åbent system med LLM-adgang kan eleven:
343
+
344
+
\begin{itemize}
345
+
\item Bede LLM'en forklare styresystemets kildekode
346
+
\item Generere programmer, der kører lokalt, med fuld hardwareadgang
347
+
\item Bygge webservere, databaser, API'er---rigtig infrastruktur
348
+
\item Skabe værktøjer, der løser virkelige problemer i deres lokalsamfund
349
+
\item Lære ethvert programmeringssprog ved at bygge med det
350
+
\item Forstå LLM'en selv ved at undersøge dens input og output
351
+
\item Skabe en piece på \ac{}~\citep{scudder2026ac}, som alle i verden kan køre
352
+
\end{itemize}
353
+
354
+
LLM'en bliver en tutor med uendelig tålmodighed, tilgængelig 24 timer i døgnet, der møder eleven præcis dér, hvor de er~\citep{khan2024bravenew}. Men denne tutor kan kun være effektiv, hvis eleven har en maskine, der kan \emph{eksekvere}, hvad tutoren producerer.
355
+
356
+
Chromebook-modellen siger: du er en bruger. Den åbne model siger: du er en forfatter. I LLM-alderen er forskellen mellem disse to rammer forskellen mellem digital læsefærdighed og digital livegenskab.
357
+
358
+
% ============================================================
359
+
% 9. A PATH FORWARD
360
+
% ============================================================
361
+
362
+
\section{En vej frem}
363
+
364
+
\subsection{Fase 1: Bevidsthed}
365
+
366
+
Forældre, lærere og skolebestyrelsesmedlemmer skal forstå, hvad en Chromebook faktisk er: en overvågningsenhed, der lærer tillært hjælpeløshed. Det første skridt er oplysning---ikke af børnene, men af de voksne, der køber maskinerne. EFFs ``Spying on Students''-dokumentation, U.S. PIRGs ``Chromebook Churn''-rapport og New Mexico-statsadvokatens retssag giver konkret bevismateriale, der kan præsenteres ved skolebestyrelsesmøder.
367
+
368
+
\subsection{Fase 2: Pilotprogrammer}
369
+
370
+
Skoledistrikter bør pilottest open source-alternativer efter Penn Manors model:
371
+
372
+
\begin{itemize}
373
+
\item 30 brugte bærbare med Linux eller \acos{}, anskaffet for \$3.000--5.400
374
+
\item En lokal LLM-server (én brugt arbejdsstation, \$200--500) med Ollama + Open WebUI
375
+
\item En LLM-assisteret læseplan, hvor elever bygger rigtig software
376
+
\item Elevejerskab: maskinen tager med hjem med eleven
377
+
\item Et elevstyret reparationsprogram (Penn Manors elever reparerer deres egne maskiner)
378
+
\item Ingen cloudafhængighed: arbejde gemmes lokalt og sikkerhedskopieres af eleven
379
+
\item Åben evaluering: elevens portfolio er kode, de skrev, værktøjer, de byggede, bidrag, de gav
380
+
\end{itemize}
381
+
382
+
\subsection{Fase 3: Politik}
383
+
384
+
Stater og distrikter bør vedtage politikker, der kræver, at:
385
+
386
+
\begin{enumerate}
387
+
\item Al software implementeret på elevers enheder er open source eller source-available
388
+
\item Elever har root-adgang til deres egne maskiner
389
+
\item Ingen adfærdstelemetri indsamles fra elevers enheder
390
+
\item Elever bevarer ejerskab over alt arbejde produceret på skolens enheder
391
+
\item Dimitterende elever beholder deres enheder
392
+
\item Indkøb af enheder prioriterer renoveret hardware over nyfremstilling
393
+
\end{enumerate}
394
+
395
+
Over 40 stater har vedtaget love om elevdatasikkerhed. Californiens SOPIPA forbyder brug af elevdata til målrettet reklame. De nye COPPA-regler (gældende fra juni 2025) styrker børns databeskyttelse. Disse lovgivningsmæssige tendenser støtter argumentet for åben, ikke-overvågende skolecomputerinfrastruktur.
396
+
397
+
\subsection{Fase 4: Befrielse}
398
+
399
+
Slutmålet er ikke en politikændring. Det er et kulturskifte. Slutmålet er en generation af elever, der forstår, at en computer ikke er et produkt, de forbruger, men et instrument, de spiller---et medium for tanke, skabelse og bidrag. Elever, der kan læse kildekode, som de læser bøger. Elever, der kan ændre deres værktøjer, som en tømrer ændrer en arbejdsbænk. Elever, der ser computing ikke som en virksomhedstjeneste, men som en offentlig fælled, som de både bidrager til og tilhører.
400
+
401
+
Nelson skrev i 1974~\citep{nelson1974computerlib}: ``Du kan og skal forstå computere NU.'' Halvtreds år senere har vi fejlet dette imperativ præcis som Nelson frygtede---ved at overdrage maskinerne til virksomheder og kalde det fremskridt.
402
+
403
+
LLM-øjeblikket gør denne fejl synlig. Enhver elev har nu \emph{evnen} til at programmere. Hvad de mangler, er en \emph{maskine, der lader dem}. Dette er et løseligt problem. Teknologien er gratis. Hardwaren er overskud. Det eneste, der står mellem enhver elev og deres egen computationelle vej, er et virksomhedsstyresystem, der aldrig var designet til at tjene dem.
404
+
405
+
% ============================================================
406
+
% 10. CONCLUSION
407
+
% ============================================================
408
+
409
+
\section{Konklusion}
410
+
411
+
Enhver Chromebook i enhver amerikansk skole er en Linux-maskine i lænker. Hardwaren kan køre et frit styresystem. Eleven kan lære at programmere med en LLM. Det brugte bærbarmarked leverer maskiner til \$100--180. Hele open source-stakken er tilgængelig til nul omkostninger. Kerala har gjort det for 300.000 computere. Slesvig-Holsten har gjort det for 30.000. Penn Manor har gjort det for 1.725. Det virker.
412
+
413
+
Hvad vi mangler, er ikke teknologi. Vi mangler den politiske vilje til at prioritere elevautonomi over institutionel bekvemmelighed og virksomhedsprofit.
414
+
415
+
Illich skrev, at værktøjer bør udvide personlig autonomi snarere end kræve specialiseret ekspertise~\citep{illich1973tools}. Papert skrev, at computere bør være instrumenter til at tænke over tænkning~\citep{papert1980mindstorms}. Stallman skrev, at brugere fortjener at kontrollere den software, de kører~\citep{stallman2002free}. Postman advarede om, at teknologi i skoler uden formål tjener teknologien, ikke barnet~\citep{postman1995end}. Disse er ikke marginale holdninger. De er grundprincipperne for personlig computing, og vi har forladt dem det ene sted, de betyder mest: uddannelsen af børn.
416
+
417
+
Få lukket kildekode ud af skolerne. Giv enhver elev et frit og åbent styresystem. Lad Chromebooken være, hvad den altid var i stand til at være: ikke en låge, men en \emph{port}---til logik, kreativitet, fællesskab, åndelighed og enhver elevs egen vej gennem det computationelle landskab.
418
+
419
+
I LLM-alderen er dette ikke idealisme. Det er den mindste levedygtige uddannelse.
420
+
421
+
\vspace{0.5em}
422
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
423
+
424
+
\end{multicols}
425
+
426
+
% ============================================================
427
+
% REFERENCES
428
+
% ============================================================
429
+
430
+
\bibliographystyle{plainnat}
431
+
\bibliography{references}
432
+
433
+
\end{document}
+433
papers/arxiv-open-schools/open-schools-es.tex
+433
papers/arxiv-open-schools/open-schools-es.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[11pt, a4paper]{article}
3
+
4
+
\usepackage{fontspec}
5
+
\usepackage{unicode-math}
6
+
\setmainfont{Latin Modern Roman}
7
+
\setsansfont{Latin Modern Sans}
8
+
\setmonofont{Latin Modern Mono}[Scale=0.88]
9
+
10
+
\usepackage{graphicx}
11
+
\graphicspath{{figures/}{../arxiv-ac/figures/}}
12
+
\usepackage{booktabs}
13
+
\usepackage{tabularx}
14
+
\usepackage{ragged2e}
15
+
\usepackage{microtype}
16
+
\usepackage{natbib}
17
+
\usepackage{multicol}
18
+
19
+
\usepackage[
20
+
top=2.2cm, bottom=2.5cm, left=2.0cm, right=2.0cm
21
+
]{geometry}
22
+
23
+
\makeatletter
24
+
\def\input@path{{../}}
25
+
\makeatother
26
+
\usepackage{ac-paper-layout}
27
+
28
+
\newcommand{\acos}{\textsc{AC Native OS}}
29
+
30
+
\hypersetup{
31
+
pdftitle={Saquen el código cerrado de las escuelas: Cada Chromebook es una puerta denegada},
32
+
}
33
+
34
+
\begin{document}
35
+
36
+
\thispagestyle{empty}
37
+
\vspace*{\fill}
38
+
\begin{center}
39
+
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
40
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Saquen el código cerrado de las escuelas}\par
41
+
\vspace{0.3em}
42
+
{\fontsize{10pt}{12pt}\selectfont\color{acpink} Cada Chromebook es una puerta denegada}\par
43
+
\vspace{0.8em}
44
+
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
45
+
{\small\color{acgray} Aesthetic.Computer}\par
46
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
47
+
\vspace{0.8em}
48
+
\rule{0.6\textwidth}{1pt}\par
49
+
\vspace{0.4em}
50
+
{\small\color{acpink!40}\textit{borrador de trabajo --- no citar}}\par
51
+
\vspace{0.3em}
52
+
{\footnotesize\color{acgray} Marzo 2026}\par
53
+
\end{center}
54
+
\vspace*{\fill}
55
+
\clearpage
56
+
57
+
\begin{multicols}{2}
58
+
59
+
% ============================================================
60
+
% ABSTRACT
61
+
% ============================================================
62
+
63
+
\begin{abstract}
64
+
\noindent
65
+
Hay más de 50 millones de Chromebooks en las escuelas estadounidenses. Cada una es una computadora capaz que ejecuta un sistema operativo cerrado y bloqueado que canaliza cada interacción del estudiante a través de la infraestructura de vigilancia de Google. El estudiante no puede ver cómo funciona la máquina. El estudiante no puede modificar la máquina. El estudiante no puede poseer la máquina en ningún sentido significativo. En la era de los grandes modelos de lenguaje---cuando ``todos somos programadores'' ya no es un eslogan sino una realidad material---esto es un acto de negligencia educativa. Este artículo argumenta que cada estudiante merece una pila de sistema operativo libre y abierto: una donde el Chromebook se convierta en una puerta de entrada al propio camino del estudiante a través de la lógica, la creatividad, internet, la comunidad y el paisaje computacional en su conjunto. Presentamos los argumentos técnicos, pedagógicos, económicos y políticos para reemplazar la infraestructura informática escolar de código cerrado con alternativas abiertas, basándonos en precedentes internacionales de Kerala, Schleswig-Holstein y Francia, datos ambientales sobre la obsolescencia programada, acciones legales federales y estatales contra la vigilancia estudiantil, e investigación emergente sobre educación en programación asistida por IA. Presentamos \acos{}~\citep{scudder2026acos} como una implementación concreta de esta visión.
66
+
\end{abstract}
67
+
68
+
% ============================================================
69
+
% 1. THE CHROMEBOOK PROBLEM
70
+
% ============================================================
71
+
72
+
\section{El problema del Chromebook}
73
+
74
+
En 2012, Google comenzó a comercializar agresivamente los Chromebooks a los distritos escolares estadounidenses. La propuesta era simple: hardware barato, cero sobrecarga de TI, todo en la nube. Para 2026, los Chromebooks representan aproximadamente el 60\% de los dispositivos enviados a las escuelas K--12 de EE.\,UU., con una base instalada que supera los 50 millones de unidades~\citep{google2024chromeos}. Toda una generación de estudiantes estadounidenses está siendo educada en máquinas que no pueden entender, no pueden modificar y no poseen---incluso cuando la escuela pagó por ellas.
75
+
76
+
ChromeOS es software propietario. Su código fuente no está disponible para inspección. El navegador es toda la interfaz. Cada documento vive en Google Drive. Cada búsqueda pasa por Google. Cada interacción es registrada, analizada y utilizada para construir perfiles de comportamiento que siguen al estudiante hasta la edad adulta~\citep{zuboff2019surveillance}.
77
+
78
+
Esto no es una preocupación marginal. Esta es la \emph{arquitectura} de cómo los niños estadounidenses aprenden a usar computadoras. El medio es el mensaje~\citep{mcluhan1964understanding}: el Chromebook enseña que una computadora es un dispositivo para consumir servicios en la nube propiedad de una corporación. Enseña que tu trabajo vive en el servidor de otra persona. Enseña que la máquina no es tuya para entenderla.
79
+
80
+
\subsection{Lo que el estudiante no puede hacer}
81
+
82
+
En un Chromebook escolar, un estudiante no puede:
83
+
84
+
\begin{itemize}
85
+
\item Instalar un entorno de ejecución de lenguaje de programación (Python, Node.js, GCC)
86
+
\item Ejecutar un servidor web local o compilar código
87
+
\item Inspeccionar el código fuente del sistema operativo
88
+
\item Modificar la secuencia de arranque
89
+
\item Conectar periféricos de hardware para computación física
90
+
\item Usar la máquina sin conexión para trabajo serio
91
+
\item Mantener sus datos en el dispositivo sin sincronización en la nube
92
+
\item Elegir su propio software
93
+
\item Entender qué está haciendo la máquina con su atención
94
+
\end{itemize}
95
+
96
+
ChromeOS incluye un contenedor Linux (Crostini) que teóricamente podría proporcionar estas capacidades, pero los administradores de TI escolares casi universalmente lo desactivan. La máquina viene con una terminal y luego la cierra con llave. Cada una de estas restricciones es una puerta cerrada. Cada puerta cerrada es un camino que el estudiante nunca descubrirá. El Chromebook no es una puerta de entrada---es una \emph{barrera}.
97
+
98
+
\subsection{La nube como arrendador}
99
+
100
+
Cuando el trabajo de un estudiante vive en Google Drive, son inquilinos, no propietarios. Google puede cambiar los términos de servicio. Google puede descontinuar productos. Google puede revocar el acceso. El estudiante se gradúa y pierde su cuenta escolar de Google---y con ella, cada documento, cada proyecto, cada artefacto creativo que produjo durante su educación.
101
+
102
+
Esto no es hipotético. Sucede cada año, en cada distrito escolar. Los estudiantes pierden acceso a años de trabajo porque la institución que compró su cuenta en la nube la desactiva. La arquitectura \emph{garantiza} este resultado: el estudiante nunca tuvo sus archivos. Tenía permiso para acceder a archivos en los servidores de Google, y ese permiso fue revocado.
103
+
104
+
Freire llamó a esto el ``modelo bancario'' de la educación~\citep{freire1970pedagogy}: conocimiento depositado en los estudiantes por autoridades. El Chromebook literaliza la metáfora. El trabajo del estudiante se deposita en un banco que no controlan, no pueden auditar y del que eventualmente serán excluidos.
105
+
106
+
\subsection{Obsolescencia programada: El problema del AUE}
107
+
108
+
Cada Chromebook viene con una fecha de Expiración de Actualización Automática (AUE), después de la cual Google no proporciona parches de seguridad, actualizaciones de funciones ni actualizaciones del navegador. Históricamente fijada en 6,5 años desde el \emph{primer lanzamiento de la plataforma}---no desde la fecha de compra---una escuela que compra un Chromebook tarde en el ciclo de una plataforma podría recibir solo 3--4 años de actualizaciones. Google extendió esto a 10 años para dispositivos lanzados en 2024, pero la base instalada de máquinas con vida más corta sigue siendo enorme.
109
+
110
+
El U.S. PIRG Education Fund estimó que las políticas de AUE forzarían la eliminación prematura de 21,5 millones de Chromebooks funcionalmente operativos para 2024, costando a las escuelas aproximadamente \$1.800 millones en reemplazos innecesarios~\citep{pirg2023chromebook}. Estas son máquinas con procesadores funcionando, pantallas funcionando, teclados funcionando---convertidas en obsoletas por una política de software, no por fallo de hardware.
111
+
112
+
El contraste con Linux es absoluto. Un ThinkPad de 2015 ejecutando Ubuntu LTS continúa recibiendo actualizaciones de seguridad indefinidamente. No hay fecha de expiración artificial vinculada al modelo de hardware. La máquina sigue siendo útil mientras el hardware funcione.
113
+
114
+
% ============================================================
115
+
% 2. THE SURVEILLANCE MACHINE
116
+
% ============================================================
117
+
118
+
\section{La máquina de vigilancia}
119
+
\label{sec:surveillance}
120
+
121
+
Google proporciona Chromebooks a las escuelas por debajo del costo porque los estudiantes son un mercado cautivo para datos de comportamiento~\citep{zuboff2019surveillance, doctorow2020attack}. Un estudiante que crece en el ecosistema de Google---Gmail, Google Docs, Google Drive, Google Classroom, YouTube---es un cliente de por vida. El Chromebook no es una donación caritativa. Es una estrategia de adquisición de clientes desplegada contra niños.
122
+
123
+
\subsection{Lo que Google recopila}
124
+
125
+
Los datos recopilados de los Chromebooks de los estudiantes incluyen:
126
+
127
+
\begin{itemize}
128
+
\item Cada consulta de búsqueda y cada sitio web visitado
129
+
\item Cada documento abierto, editado y compartido
130
+
\item Cada video de YouTube visto y por cuánto tiempo
131
+
\item Patrones de temporización de pulsaciones de teclas y frecuencia de inicio de sesión
132
+
\item Datos de ubicación (en modelos celulares)
133
+
\item Grafos sociales (quién colabora con quién en Google Docs)
134
+
\item Diagnósticos del dispositivo y telemetría de uso de aplicaciones
135
+
\end{itemize}
136
+
137
+
Google afirma que los datos recopilados bajo los ``servicios principales'' de Workspace for Education no se utilizan para publicidad. Pero los ``servicios adicionales''---YouTube, Búsqueda de Google, Google Maps cuando se ha iniciado sesión---operan bajo términos diferentes. Los estudiantes en Chromebooks escolares usan estos servicios adicionales constantemente, y los datos fluyen hacia la infraestructura publicitaria de Google.
138
+
139
+
\subsection{Acciones legales}
140
+
141
+
El registro legal es condenatorio. En 2019, Google pagó \$170 millones a la FTC y al Fiscal General de Nueva York por las violaciones de COPPA de YouTube---recopilar datos de niños sin consentimiento parental~\citep{google2019coppa}. En 2020, el Fiscal General de Nuevo México, Hector Balderas, demandó directamente a Google por recopilar datos personales de niños que usan Chromebooks en escuelas~\citep{newmexico2020google}. La EFF presentó una queja ante la FTC en 2015 documentando que Google estaba extrayendo datos de la actividad de navegación de los estudiantes a través de los Chromebooks~\citep{eff2015chromebook}. En 2024, una coalición de organizaciones de derechos digitales presentó quejas adicionales ante la FTC sobre la vigilancia continua de estudiantes~\citep{eff2024monitoring}. Las demandas colectivas que alegan recopilación de datos biométricos de estudiantes bajo el estatuto BIPA de Illinois están en curso.
142
+
143
+
Estos datos se recopilan de menores, en un entorno institucional donde la participación es obligatoria, en máquinas que el estudiante no eligió y no puede configurar. El estudiante no puede optar por no participar. El padre a menudo no puede optar por no participar. El distrito escolar firmó un contrato, y los niños están obligados por él.
144
+
145
+
\subsection{Software de monitoreo}
146
+
147
+
Más allá de la propia recopilación de datos de Google, los distritos escolares superponen software de vigilancia adicional---Gaggle, GoGuardian, Securly---en los Chromebooks. La EFF documentó que estas herramientas vigilan comunicaciones privadas y afectan desproporcionadamente a jóvenes desfavorecidos, de minorías y LGBTQ~\citep{eff2024monitoring}. De 152 servicios de tecnología educativa encuestados por la EFF, solo 118 tenían políticas de privacidad publicadas; muchos menos abordaban la retención de datos, el cifrado o la desidentificación.
148
+
149
+
Winner argumentó que los artefactos tienen política~\citep{winner1980artifacts}. La política del Chromebook es clara: es un instrumento de vigilancia desplegado en un contexto donde los vigilados no tienen opción, no tienen recurso y no entienden lo que se les está quitando.
150
+
151
+
Un sistema operativo libre y abierto no recopila telemetría. No llama a ninguna corporación. No construye ningún perfil de comportamiento. La atención del estudiante, su curiosidad, sus errores, sus exploraciones---todo esto permanece privado, porque la máquina no tiene incentivo económico para observarlos.
152
+
153
+
% ============================================================
154
+
% 3. THE LLM INFLECTION
155
+
% ============================================================
156
+
157
+
\section{Todos somos programadores ahora}
158
+
159
+
Los grandes modelos de lenguaje han cambiado la economía de la programación. Un estudiante que puede describir lo que quiere en lenguaje natural puede producir código funcional. La barrera para la creación computacional ha colapsado de ``años de formación técnica'' a ``la capacidad de articular una idea.'' La observación de Karpathy de que ``el nuevo lenguaje de programación más popular es el inglés'' ya no es una hipérbole---es una descripción de la realidad material.
160
+
161
+
Este es el cambio más importante en la informática desde la computadora personal. Y hace que el problema del Chromebook sea \emph{catastróficamente peor}.
162
+
163
+
\subsection{La nueva alfabetización}
164
+
165
+
Si todos pueden programar, entonces la programación es alfabetización. Y la alfabetización requiere herramientas que la persona alfabetizada pueda poseer. No se enseña a un niño a leer dándole un libro cerrado que solo puede abrirse en un edificio específico con una cuenta corporativa específica. Se le da el libro. Se lo lleva a casa. Lo lee en la cama. Escribe en los márgenes. Se lo presta a un amigo.
166
+
167
+
Un estudiante con un LLM y un sistema operativo abierto puede:
168
+
169
+
\begin{itemize}
170
+
\item Construir una herramienta para organizar sus tareas
171
+
\item Escribir un juego y compartirlo con compañeros de clase
172
+
\item Automatizar una tarea repetitiva que su profesor asigna
173
+
\item Crear un pequeño negocio vendiendo software a su comunidad
174
+
\item Contribuir a proyectos de código abierto que sirvan a la humanidad
175
+
\item Entender y modificar los sistemas que gobiernan su vida digital
176
+
\item Explorar la lógica, las matemáticas y el lenguaje a través de la manipulación directa
177
+
\item Construir instrumentos para la expresión artística
178
+
\end{itemize}
179
+
180
+
Un estudiante con un LLM y un Chromebook puede usar Google Docs más rápido.
181
+
182
+
Ko (University of Washington) ha argumentado que si la IA puede escribir código, la educación en ciencias de la computación debe orientarse hacia el pensamiento sistémico, la depuración y la evaluación---todo lo cual requiere acceso a entornos de desarrollo reales, no navegadores aislados~\citep{denny2024computing}. Krishnamurthi (Brown University) ha sido crítico con los enfoques que reducen la programación a la generación de prompts. El consenso emergente en la investigación sobre educación en ciencias de la computación es que los LLMs hacen que el acceso completo a la pila sea \emph{más} importante, no menos~\citep{prather2024robots}: los estudiantes necesitan ejecutar, depurar, modificar y entender el código generado. Los Chromebooks dificultan las cuatro cosas.
183
+
184
+
\subsection{El Chromebook no puede ejecutar}
185
+
186
+
Aquí está el fallo concreto: el LLM produce un script de Python, y el Chromebook no puede ejecutarlo. El LLM genera un servidor web, y el Chromebook no puede alojarlo. El LLM escribe código C, y el Chromebook no tiene compilador. El LLM enseña al estudiante cómo funciona un sistema operativo, y el Chromebook no les permite inspeccionar uno.
187
+
188
+
En un Chromebook escolar típico (procesador MediaTek o Celeron, 4\,GB de RAM), incluso el contenedor Linux---cuando está habilitado---lucha por ejecutar cadenas de herramientas de desarrollo básicas. Ejecutar un LLM local es físicamente imposible: incluso un modelo cuantizado de 1B parámetros requiere más memoria de la que poseen la mayoría de los Chromebooks escolares.
189
+
190
+
La alternativa es trivial. Un ThinkPad excedente con 8\,GB de RAM ejecutando Linux puede ejecutar cualquier código generado por un LLM, ejecutar un modelo local de 3B parámetros vía Ollama a velocidades interactivas, alojar un servidor web, compilar programas y dar al estudiante acceso root a todo el sistema. El hardware existe. El software es gratuito. El Chromebook es el cuello de botella.
191
+
192
+
\subsection{La dimensión espiritual}
193
+
194
+
Esto no se trata solo de economía o preparación profesional. Hay una dimensión espiritual de la computación que la arquitectura del Chromebook aniquila.
195
+
196
+
Cuando un estudiante escribe un programa que hace algo que no esperaba---cuando la máquina los sorprende con comportamiento emergente de reglas que ellos definieron---experimentan algo profundo. Encuentran el límite entre la intención y la consecuencia. Aprenden que los sistemas tienen su propia lógica. Desarrollan una relación con la abstracción misma.
197
+
198
+
Papert entendió esto~\citep{papert1980mindstorms}: Logo no se trataba de enseñar programación. Se trataba de dar a los niños un medio para pensar sobre el pensamiento. La tortuga era un vehículo para la epistemología.
199
+
200
+
Los LLMs amplifican esto mil veces. Un estudiante ahora puede tener una \emph{conversación} con el medio computacional. Pueden preguntar ``¿qué pasaría si?'' y obtener una respuesta en segundos. Pueden iterar sobre ideas a la velocidad del pensamiento. Pueden explorar caminos que ningún currículo anticipó.
201
+
202
+
Pero solo si la máquina se lo permite. Un Chromebook no se lo permite. Un Chromebook dice: puedes consumir servicios. No puedes crear infraestructura. No puedes ejecutar tu propio código a tu manera en tu propia máquina.
203
+
204
+
% ============================================================
205
+
% 4. WHAT STUDENTS DESERVE
206
+
% ============================================================
207
+
208
+
\section{Lo que cada estudiante merece}
209
+
210
+
Cada estudiante merece una computadora que:
211
+
212
+
\begin{enumerate}
213
+
\item \textbf{Puedan entender.} El código fuente del sistema operativo debería estar disponible para inspección. No como un principio abstracto, sino como una realidad práctica: el estudiante debería poder leer el código que se ejecuta cuando presiona una tecla.
214
+
215
+
\item \textbf{Puedan modificar.} Si el estudiante quiere cambiar cómo se comporta la máquina, debería poder hacerlo. No a través de una tienda de aplicaciones, no a través de un panel de configuración, sino cambiando el código.
216
+
217
+
\item \textbf{Puedan poseer.} El trabajo del estudiante debería vivir en la máquina del estudiante. No en un servidor corporativo, no en una cuenta en la nube que será desactivada cuando se gradúen.
218
+
219
+
\item \textbf{Puedan compartir.} El estudiante debería poder dar su software a un amigo. No a través de una plataforma, no a través de un mercado, sino copiando un archivo.
220
+
221
+
\item \textbf{Puedan romper.} El estudiante debería poder romper la máquina y repararla. Así es como se aprende. Un sistema que no puede romperse no puede entenderse.
222
+
223
+
\item \textbf{Puedan llevar consigo.} Cuando el estudiante deja la escuela, la computadora---y todo lo que contiene---se va con ellos. Su vida computacional no está alquilada. Es suya.
224
+
225
+
\item \textbf{Respete su atención.} El sistema operativo no debería contener publicidad, rastreo de comportamiento ni optimización del engagement. La atención del estudiante pertenece al estudiante.
226
+
227
+
\item \textbf{Los conecte con la comunidad.} El estudiante debería poder contribuir al paisaje computacional---escribir código que otros usen, participar en proyectos de código abierto, construir herramientas que sirvan a su comunidad y mantengan su estilo de vida y bienestar.
228
+
\end{enumerate}
229
+
230
+
Cada uno de estos requisitos es violado por ChromeOS. Cada uno de ellos es satisfecho por un sistema operativo libre y abierto.
231
+
232
+
% ============================================================
233
+
% 5. IT ALREADY WORKS
234
+
% ============================================================
235
+
236
+
\section{Ya funciona: Precedentes internacionales}
237
+
238
+
La objeción de que la informática escolar de código abierto no ha sido probada es falsa. Ha sido probada, a escala, en tres continentes.
239
+
240
+
\subsection{Kerala, India: 16.000 escuelas}
241
+
242
+
El programa KITE de Kerala (Kerala Infrastructure and Technology for Education) migró completamente a software libre en 2007 en más de 16.000 escuelas públicas. KITE GNU/Linux 22.04, lanzado en agosto de 2024, funciona en más de 300.000 computadoras escolares~\citep{kite2024gnulinux}. La distribución incluye software educativo (Krita, GCompris, PictoBlox), herramientas básicas de enseñanza de IA/ML y un servidor de visualización Wayland. El ahorro estimado: 30.000 millones de INR (aproximadamente \$400 millones). Más de 150.000 maestros de primaria han sido capacitados. La Escuela Nacional de Derecho de India aclamó a KITE como el referente nacional para la transformación de código abierto en educación.
243
+
244
+
Esto no es un programa piloto. Es un despliegue estatal que atiende a millones de estudiantes, funcionando continuamente durante casi dos décadas.
245
+
246
+
\subsection{Schleswig-Holstein, Alemania: 30.000 PCs}
247
+
248
+
Para finales del verano de 2025, el estado alemán de Schleswig-Holstein completó la migración de casi 30.000 PCs gubernamentales de Microsoft a Linux, con otros 30.000 maestros de escuelas públicas esperados a continuación~\citep{schleswig2025linux}. Los reemplazos incluyen LibreOffice, Nextcloud, Open-Xchange y Mozilla Thunderbird. Ahorro estimado: 15 millones de EUR solo en 2026. Dinamarca anunció una transición similar entre junio y noviembre de 2025.
249
+
250
+
\subsection{Francia: Estrategia nacional de código abierto}
251
+
252
+
La Estrategia de Educación Digital 2023--2027 de Francia, liderada por Alexis Kauffmann en el Ministerio de Educación, apunta explícitamente a la soberanía digital y la reducción de la dependencia de Microsoft y Google~\citep{france2023digital}. La plataforma nacional \texttt{apps.education.fr} proporciona herramientas de código abierto a todos los docentes franceses. En 2025, Francia promulgó un decreto de interoperabilidad que requiere que las escuelas utilicen herramientas digitales que cumplan con estándares abiertos---creando una ventaja estructural para las soluciones de código abierto.
253
+
254
+
\subsection{Penn Manor, Pensilvania: 1.725 portátiles Linux}
255
+
256
+
En Estados Unidos, el Distrito Escolar de Penn Manor en Lancaster, PA, desplegó 1.725 portátiles Ubuntu a estudiantes de los grados 9--12~\citep{pennmanor2024linux}. El programa incluye una iniciativa de reparación dirigida por estudiantes donde los alumnos aprenden a reparar sus propias máquinas. Este no es un distrito especial con financiamiento especial. Es un distrito escolar público que tomó una decisión diferente.
257
+
258
+
\subsection{El movimiento ``Dinero público, código público''}
259
+
260
+
La campaña ``Public Money? Public Code!'' de la Free Software Foundation Europe---que argumenta que el software desarrollado con fondos públicos debería publicarse bajo licencias libres---ha reunido a más de 200 organizaciones de la sociedad civil y 31.000 firmantes individuales~\citep{fsfe2024publiccode}. La Declaración de Dubái de la UNESCO de 2024 sobre Recursos Educativos Abiertos compromete formalmente a los signatarios a promover recursos abiertos a través de la IA y las tecnologías emergentes~\citep{unesco2024oer}. El Pacto Digital Global se compromete a ``desarrollar, difundir y mantener software de código abierto, datos abiertos, modelos de IA abiertos y estándares abiertos que beneficien a la sociedad.''
261
+
262
+
Estos no son movimientos marginales. Son la dirección de la política internacional.
263
+
264
+
% ============================================================
265
+
% 6. THE ECONOMICS
266
+
% ============================================================
267
+
268
+
\section{La economía}
269
+
270
+
\subsection{La excusa del costo}
271
+
272
+
Los Chromebooks son baratos. Pero también lo son los portátiles excedentes con Linux. Un ThinkPad T480 o Dell Latitude 5400 retirado cuesta \$100--180 en volumen y es una máquina superior en todas las dimensiones excepto ``gestionado por Google.'' El argumento del costo a favor de los Chromebooks es un argumento a favor del ecosistema de Google, no del hardware.
273
+
274
+
\begin{table}[H]
275
+
\small
276
+
\centering
277
+
\begin{tabular}{lrr}
278
+
\toprule
279
+
\textbf{Enfoque} & \textbf{Costo} & \textbf{El estudiante lo posee} \\
280
+
\midrule
281
+
Chromebook (nuevo) & \$250--350 & No \\
282
+
Chrome Edu Upgrade & +\$38/dispositivo & No \\
283
+
Google Workspace Plus & +\$5/estudiante/año & No \\
284
+
iPad (edu) & \$299+ & No \\
285
+
\midrule
286
+
Portátil excedente + Linux & \$100--180 & \textbf{Sí} \\
287
+
Portátil excedente + AC OS & \$100--180 & \textbf{Sí} \\
288
+
\bottomrule
289
+
\end{tabular}
290
+
\caption{Comparación de costos y propiedad. Los costos del Chromebook excluyen software de monitoreo (GoGuardian: \$5--10/dispositivo/año) y reemplazos forzados por AUE.}
291
+
\label{tab:cost}
292
+
\end{table}
293
+
294
+
Al incluir el Chrome Education Upgrade de Google (\$38/dispositivo), Workspace for Education Plus (\$5/estudiante/año), software de monitoreo y el ciclo de reemplazo forzado por AUE, el costo total de propiedad de un Chromebook durante 5 años puede alcanzar \$450--550/dispositivo. Un ThinkPad excedente ejecutando Linux: \$100--180, con cero costos de licencia recurrentes, sin expiración artificial, y el estudiante se lo queda.
295
+
296
+
\subsection{La oferta}
297
+
298
+
Las máquinas existen. Se estima que 50--60 millones de PCs empresariales se retiran anualmente en Estados Unidos. Los ciclos de arrendamiento corporativo retiran millones de portátiles funcionales cada 3--5 años---máquinas con procesadores modernos, 8--16\,GB de RAM, WiFi y baterías de 6--10 horas. Organizaciones como PCs for People (100.000+ dispositivos/año), Human-I-T (50.000+/año), Kramden Institute, Free Geek y el programa federal Computers for Learning ya reacondicionan y distribuyen estas máquinas.
299
+
300
+
Un aula de 30 instrumentos de computación creativa puede aprovisionarse por \$3.000--5.400 en hardware. Sin suscripción recurrente. Sin contrato de soporte de TI. Sin cuentas gestionadas.
301
+
302
+
\subsection{El argumento ambiental}
303
+
304
+
Un portátil típico produce 300--400 kg de CO$_2$e en fabricación---70--80\% de su huella de carbono total durante su vida útil. El reacondicionamiento añade aproximadamente 5--15 kg de CO$_2$e. El análisis auditado independientemente de Circular Computing encontró 316 kg de CO$_2$e ahorrados por portátil remanufacturado~\citep{circularcomputing2023carbon}. El Monitor Global de Residuos Electrónicos 2024 de la ONU informa que EE.\,UU. genera aproximadamente 7,2 Mt de residuos electrónicos anuales, con solo el 25\% reciclado adecuadamente~\citep{un2024ewaste}.
305
+
306
+
La política de AUE de Google obliga a las escuelas a desechar millones de Chromebooks funcionales. La legislación de derecho a reparar está comenzando a abordar esto: la ley de Oregón (vigente desde enero de 2025) requiere que los fabricantes proporcionen piezas e información de reparación~\citep{oregon2024repair}; el HB1701 de New Hampshire cubre explícitamente los portátiles proporcionados por las escuelas~\citep{newhampshire2024repair}. Pero la legislación no puede arreglar una política de software que declara obsoleto el hardware funcional.
307
+
308
+
Linux no tiene AUE. Un portátil que ejecuta un sistema operativo libre sigue siendo útil mientras el hardware funcione.
309
+
310
+
% ============================================================
311
+
% 7. THE OPEN STACK
312
+
% ============================================================
313
+
314
+
\section{La pila abierta}
315
+
316
+
\subsection{Cada Chromebook ya es una máquina Linux}
317
+
318
+
Aquí está lo absurdo: cada Chromebook ya ejecuta el kernel de Linux. ChromeOS es Linux con un espacio de usuario bloqueado que fuerza toda la interacción a través del navegador de Google. El hardware es perfectamente capaz de ejecutar un sistema operativo libre. Google tomó un kernel libre, lo envolvió en restricciones propietarias y lo vendió a las escuelas como una medida de ahorro.
319
+
320
+
La liberación de estas máquinas no requiere nuevo hardware. Requiere flashear nuevo software. Muchos Chromebooks pueden desbloquearse y reflashearse con una distribución Linux estándar o con \acos{}. La máquina \emph{ya quiere ser libre}. Google es el candado.
321
+
322
+
\subsection{La excusa de TI}
323
+
324
+
Los departamentos de TI escolares eligen Chromebooks porque son ``fáciles de gestionar.'' Esto es cierto. Es fácil gestionar una máquina que no hace nada. Es fácil administrar una flota cuando cada dispositivo es un cliente ligero para los servicios de una sola corporación. La facilidad de gestión es una consecuencia directa de la impotencia de la máquina.
325
+
326
+
La pregunta es: ¿fácil para quién? Fácil para el departamento de TI, ciertamente. Pero catastrófico para el estudiante. La conveniencia del departamento de TI se compra con la autonomía del estudiante. Es un mal trato.
327
+
328
+
Las herramientas de gestión de código abierto existen. NixOS proporciona configuraciones de sistema reproducibles. Ansible automatiza el despliegue de flotas. El arranque PXE permite el aprovisionamiento sin intervención. \acos{}~\citep{scudder2026acos} demuestra que un sistema operativo completo puede desplegarse flasheando una unidad USB en menos de un minuto, con actualizaciones OTA que no requieren infraestructura de TI. Penn Manor opera 1.725 portátiles Linux con un equipo de TI más pequeño que los distritos comparables con Chromebooks~\citep{pennmanor2024linux}. El ``problema de gestión'' está resuelto. Lo que queda es inercia institucional y una relación contractual con Google que sirve a la institución, no al estudiante.
329
+
330
+
\subsection{La infraestructura de LLM}
331
+
332
+
Un sistema abierto habilita una relación fundamentalmente diferente con la IA. Un solo servidor excedente (32--64\,GB de RAM, o una GPU NVIDIA T4 usada a \$100--200) puede ejecutar Ollama y servir a un aula entera de estudiantes vía Open WebUI---un frontend de LLM gratuito y de código abierto. Los estudiantes se conectan desde sus portátiles vía un navegador apuntando al servidor local. Modelos como Llama 3.2 3B (cabe en 4\,GB), DeepSeek Coder 6.7B o Qwen 2.5 Coder 7B proporcionan una fuerte capacidad de generación de código.
333
+
334
+
Esta es infraestructura de IA local que la escuela posee, que no recopila telemetría, que no envía datos a ninguna corporación, y que los estudiantes pueden inspeccionar, modificar y aprender. La alternativa---Google Gemini integrado en Workspace for Education---añade otra capa de dependencia corporativa, otro pipeline de datos, otra cuota de suscripción.
335
+
336
+
% ============================================================
337
+
% 8. THE LLM GATEWAY
338
+
% ============================================================
339
+
340
+
\section{El estudiante como autor}
341
+
342
+
En un sistema abierto con acceso a LLM, el estudiante puede:
343
+
344
+
\begin{itemize}
345
+
\item Pedir al LLM que explique el código fuente del sistema operativo
346
+
\item Generar programas que se ejecuten localmente, con acceso completo al hardware
347
+
\item Construir servidores web, bases de datos, APIs---infraestructura real
348
+
\item Crear herramientas que resuelvan problemas reales en su comunidad
349
+
\item Aprender cualquier lenguaje de programación construyendo con él
350
+
\item Entender el LLM mismo examinando sus entradas y salidas
351
+
\item Crear una pieza en \ac{}~\citep{scudder2026ac} que cualquier persona en el mundo pueda ejecutar
352
+
\end{itemize}
353
+
354
+
El LLM se convierte en un tutor con paciencia infinita, disponible las 24 horas del día, que encuentra al estudiante exactamente donde está~\citep{khan2024bravenew}. Pero este tutor solo puede ser efectivo si el estudiante tiene una máquina que pueda \emph{ejecutar} lo que el tutor produce.
355
+
356
+
El modelo Chromebook dice: eres un usuario. El modelo abierto dice: eres un autor. En la era de los LLMs, la diferencia entre estos dos marcos es la diferencia entre la alfabetización digital y la servidumbre digital.
357
+
358
+
% ============================================================
359
+
% 9. A PATH FORWARD
360
+
% ============================================================
361
+
362
+
\section{Un camino hacia adelante}
363
+
364
+
\subsection{Fase 1: Concienciación}
365
+
366
+
Los padres, los docentes y los miembros de las juntas escolares deben entender lo que un Chromebook realmente es: un dispositivo de vigilancia que enseña indefensión aprendida. El primer paso es la educación---no de los niños, sino de los adultos que compran las máquinas. La documentación ``Spying on Students'' de la EFF, el informe ``Chromebook Churn'' del U.S. PIRG y la demanda del Fiscal General de Nuevo México proporcionan evidencia concreta que puede presentarse en las reuniones de las juntas escolares.
367
+
368
+
\subsection{Fase 2: Programas piloto}
369
+
370
+
Los distritos escolares deberían pilotar alternativas de código abierto, siguiendo el modelo de Penn Manor:
371
+
372
+
\begin{itemize}
373
+
\item 30 portátiles excedentes ejecutando Linux o \acos{}, aprovisionados por \$3.000--5.400
374
+
\item Un servidor LLM local (una estación de trabajo excedente, \$200--500) ejecutando Ollama + Open WebUI
375
+
\item Un currículo asistido por LLM donde los estudiantes construyen software real
376
+
\item Propiedad estudiantil: la máquina se va a casa con el estudiante
377
+
\item Un programa de reparación dirigido por estudiantes (los estudiantes de Penn Manor reparan sus propias máquinas)
378
+
\item Sin dependencia de la nube: el trabajo se almacena localmente y el estudiante hace copias de seguridad
379
+
\item Evaluación abierta: el portafolio del estudiante es código que escribió, herramientas que construyó, contribuciones que hizo
380
+
\end{itemize}
381
+
382
+
\subsection{Fase 3: Política}
383
+
384
+
Los estados y distritos deberían adoptar políticas que requieran que:
385
+
386
+
\begin{enumerate}
387
+
\item Todo el software desplegado en dispositivos estudiantiles sea de código abierto o con código fuente disponible
388
+
\item Los estudiantes tengan acceso root a sus propias máquinas
389
+
\item No se recopile telemetría de comportamiento de los dispositivos estudiantiles
390
+
\item Los estudiantes retengan la propiedad de todo el trabajo producido en dispositivos escolares
391
+
\item Los estudiantes que se gradúan conserven sus dispositivos
392
+
\item La adquisición de dispositivos priorice el hardware reacondicionado sobre la nueva fabricación
393
+
\end{enumerate}
394
+
395
+
Más de 40 estados han aprobado leyes de privacidad de datos estudiantiles. SOPIPA de California prohíbe el uso de datos estudiantiles para publicidad dirigida. Las nuevas reglas de COPPA (vigentes desde junio de 2025) fortalecen las protecciones de datos de los niños. Estas tendencias legislativas respaldan el caso de una infraestructura informática escolar abierta y sin vigilancia.
396
+
397
+
\subsection{Fase 4: Liberación}
398
+
399
+
El objetivo final no es un cambio de política. Es un cambio cultural. El objetivo final es una generación de estudiantes que entiendan que una computadora no es un producto que consumen, sino un instrumento que tocan---un medio para el pensamiento, la creación y la contribución. Estudiantes que puedan leer código fuente como leen libros. Estudiantes que puedan modificar sus herramientas como un carpintero modifica un banco de trabajo. Estudiantes que vean la computación no como un servicio corporativo, sino como un bien común al que tanto contribuyen como pertenecen.
400
+
401
+
Nelson escribió en 1974~\citep{nelson1974computerlib}: ``Puedes y debes entender las computadoras AHORA.'' Cincuenta años después, hemos fallado este imperativo precisamente como Nelson temía---entregando las máquinas a las corporaciones y llamándolo progreso.
402
+
403
+
El momento LLM hace visible este fracaso. Cada estudiante ahora tiene la \emph{capacidad} de programar. Lo que les falta es una \emph{máquina que se los permita}. Este es un problema resoluble. La tecnología es gratuita. El hardware es excedente. Lo único que se interpone entre cada estudiante y su propio camino computacional es un sistema operativo corporativo que nunca fue diseñado para servirles.
404
+
405
+
% ============================================================
406
+
% 10. CONCLUSION
407
+
% ============================================================
408
+
409
+
\section{Conclusión}
410
+
411
+
Cada Chromebook en cada escuela estadounidense es una máquina Linux encadenada. El hardware puede ejecutar un sistema operativo libre. El estudiante puede aprender a programar con un LLM. El mercado de portátiles excedentes proporciona máquinas por \$100--180. Toda la pila de código abierto está disponible a costo cero. Kerala lo ha hecho para 300.000 computadoras. Schleswig-Holstein lo ha hecho para 30.000. Penn Manor lo ha hecho para 1.725. Funciona.
412
+
413
+
Lo que nos falta no es tecnología. Nos falta la voluntad política para priorizar la autonomía estudiantil sobre la conveniencia institucional y el beneficio corporativo.
414
+
415
+
Illich escribió que las herramientas deberían expandir la autonomía personal en lugar de requerir experiencia especializada~\citep{illich1973tools}. Papert escribió que las computadoras deberían ser instrumentos para pensar sobre el pensamiento~\citep{papert1980mindstorms}. Stallman escribió que los usuarios merecen controlar el software que ejecutan~\citep{stallman2002free}. Postman advirtió que la tecnología en las escuelas sin propósito sirve a la tecnología, no al niño~\citep{postman1995end}. Estas no son posiciones marginales. Son los principios fundacionales de la computación personal, y los hemos abandonado en el único lugar donde más importan: la educación de los niños.
416
+
417
+
Saquen el código cerrado de las escuelas. Den a cada estudiante un sistema operativo libre y abierto. Dejen que el Chromebook sea lo que siempre fue capaz de ser: no una barrera, sino una \emph{puerta de entrada}---a la lógica, la creatividad, la comunidad, la espiritualidad y el propio camino de cada estudiante a través del paisaje computacional.
418
+
419
+
En la era de los LLMs, esto no es idealismo. Es la educación mínima viable.
420
+
421
+
\vspace{0.5em}
422
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
423
+
424
+
\end{multicols}
425
+
426
+
% ============================================================
427
+
% REFERENCES
428
+
% ============================================================
429
+
430
+
\bibliographystyle{plainnat}
431
+
\bibliography{references}
432
+
433
+
\end{document}
+435
papers/arxiv-open-schools/open-schools-zh.tex
+435
papers/arxiv-open-schools/open-schools-zh.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[11pt, a4paper]{article}
3
+
4
+
\usepackage{fontspec}
5
+
\usepackage{unicode-math}
6
+
\usepackage{xeCJK}
7
+
\setCJKmainfont{Droid Sans Fallback}
8
+
\setmainfont{Latin Modern Roman}
9
+
\setsansfont{Latin Modern Sans}
10
+
\setmonofont{Latin Modern Mono}[Scale=0.88]
11
+
12
+
\usepackage{graphicx}
13
+
\graphicspath{{figures/}{../arxiv-ac/figures/}}
14
+
\usepackage{booktabs}
15
+
\usepackage{tabularx}
16
+
\usepackage{ragged2e}
17
+
\usepackage{microtype}
18
+
\usepackage{natbib}
19
+
\usepackage{multicol}
20
+
21
+
\usepackage[
22
+
top=2.2cm, bottom=2.5cm, left=2.0cm, right=2.0cm
23
+
]{geometry}
24
+
25
+
\makeatletter
26
+
\def\input@path{{../}}
27
+
\makeatother
28
+
\usepackage{ac-paper-layout}
29
+
30
+
\newcommand{\acos}{\textsc{AC Native OS}}
31
+
32
+
\hypersetup{
33
+
pdftitle={让闭源软件离开学校：每一台Chromebook都是一扇被关闭的大门},
34
+
}
35
+
36
+
\begin{document}
37
+
38
+
\thispagestyle{empty}
39
+
\vspace*{\fill}
40
+
\begin{center}
41
+
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
42
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} 让闭源软件离开学校}\par
43
+
\vspace{0.3em}
44
+
{\fontsize{10pt}{12pt}\selectfont\color{acpink} 每一台Chromebook都是一扇被关闭的大门}\par
45
+
\vspace{0.8em}
46
+
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
47
+
{\small\color{acgray} Aesthetic.Computer}\par
48
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
49
+
\vspace{0.8em}
50
+
\rule{0.6\textwidth}{1pt}\par
51
+
\vspace{0.4em}
52
+
{\small\color{acpink!40}\textit{工作草稿 --- 请勿引用}}\par
53
+
\vspace{0.3em}
54
+
{\footnotesize\color{acgray} 2026年3月}\par
55
+
\end{center}
56
+
\vspace*{\fill}
57
+
\clearpage
58
+
59
+
\begin{multicols}{2}
60
+
61
+
% ============================================================
62
+
% ABSTRACT
63
+
% ============================================================
64
+
65
+
\begin{abstract}
66
+
\noindent
67
+
美国学校中有超过5000万台Chromebook。每一台都是一台性能可靠的计算机，运行着一个封闭的、闭源的操作系统，将学生的每一次交互都引导至Google的监控基础设施。学生无法看到机器是如何运作的。学生无法修改机器。学生无法在任何有意义的层面上拥有这台机器。在大语言模型时代——当"人人都是程序员"不再是口号而是物质现实——这是一种教育上的失职。本文论证每个学生都应拥有一个自由开放的操作系统栈：一个让Chromebook成为学生通向逻辑、创造力、互联网、社区以及整个计算景观的大门。我们提出了用开放替代方案取代闭源学校计算基础设施的技术、教育、经济和政治论据，借鉴了来自喀拉拉邦、石勒苏益格-荷尔斯泰因和法国的国际先例、关于计划性报废的环境数据、针对学生监控的联邦和州法律行动，以及AI辅助编程教育的新兴研究。我们展示\acos{}~\citep{scudder2026acos}作为这一愿景的一个具体实现。
68
+
\end{abstract}
69
+
70
+
% ============================================================
71
+
% 1. THE CHROMEBOOK PROBLEM
72
+
% ============================================================
73
+
74
+
\section{Chromebook问题}
75
+
76
+
2012年，Google开始积极向美国学区推销Chromebook。宣传很简单：廉价硬件、零IT开销、一切在云端。到2026年，Chromebook约占美国K--12学校设备出货量的60\%，装机量超过5000万台~\citep{google2024chromeos}。整整一代美国学生正在他们无法理解、无法修改、不拥有的机器上接受教育——即使学校为它们付了钱。
77
+
78
+
ChromeOS是专有软件。其源代码不可供查阅。浏览器就是全部界面。每份文档都存在Google云端硬盘中。每次搜索都经过Google。每次交互都被记录、分析，并用于构建跟随学生进入成年的行为档案~\citep{zuboff2019surveillance}。
79
+
80
+
这不是边缘性的隐私问题。这是美国儿童如何学习使用计算机的\emph{架构}。媒介即信息~\citep{mcluhan1964understanding}：Chromebook教导学生，计算机是一种消费企业所有云服务的设备。它教导你的工作存在别人的服务器上。它教导这台机器不是你能理解的。
81
+
82
+
\subsection{学生不能做什么}
83
+
84
+
在学校的Chromebook上，学生不能：
85
+
86
+
\begin{itemize}
87
+
\item 安装编程语言运行时（Python、Node.js、GCC）
88
+
\item 运行本地Web服务器或编译代码
89
+
\item 查看操作系统源代码
90
+
\item 修改启动序列
91
+
\item 连接硬件外设进行物理计算
92
+
\item 在离线状态下进行严肃的工作
93
+
\item 在设备上保存数据而不同步到云端
94
+
\item 选择自己的软件
95
+
\item 了解机器在如何利用他们的注意力
96
+
\end{itemize}
97
+
98
+
ChromeOS包含一个Linux容器（Crostini），理论上可以提供这些功能，但学校IT管理员几乎普遍将其禁用。机器自带终端，然后将其锁住。这些限制中的每一个都是一扇关闭的门。每扇关闭的门都是一条学生永远不会发现的路。Chromebook不是一扇大门——它是一道\emph{栅栏}。
99
+
100
+
\subsection{云作为房东}
101
+
102
+
当学生的作品存在Google云端硬盘中时，他们是租户，而非业主。Google可以更改服务条款。Google可以停止产品。Google可以撤销访问权限。学生毕业后失去了学校Google账户——随之失去的是他们在受教育期间创作的每一份文档、每一个项目、每一件创意作品。
103
+
104
+
这不是假设。这每年都在每个学区发生。学生失去了对多年作品的访问权限，因为购买其云账户的机构将其停用。这种架构\emph{保证}了这个结果：学生从来没有拥有过他们的文件。他们只是拥有访问Google服务器上文件的许可，而该许可被撤销了。
105
+
106
+
弗莱雷将此称为教育的"银行模式"~\citep{freire1970pedagogy}：知识由权威者存入学生体内。Chromebook将这个隐喻字面化了。学生的作品被存入一家他们无法控制、无法审计、最终会被锁在门外的银行。
107
+
108
+
\subsection{计划性报废：AUE问题}
109
+
110
+
每台Chromebook都附带一个自动更新到期（AUE）日期，此后Google不再提供安全补丁、功能更新或浏览器更新。历史上设定为\emph{平台}首次发布后6.5年——不是购买日期——一所在平台周期后期购买Chromebook的学校可能只能获得3--4年的更新。Google将2024年发布的设备延长至10年，但生命周期较短的机器装机量仍然庞大。
111
+
112
+
美国PIRG教育基金估计，AUE政策将在2024年前迫使2150万台功能正常的Chromebook提前报废，给学校造成约18亿美元的不必要更换费用~\citep{pirg2023chromebook}。这些机器的处理器正常工作、屏幕正常工作、键盘正常工作——被一项软件政策而非硬件故障宣布为过时。
113
+
114
+
与Linux的对比是绝对的。一台运行Ubuntu LTS的2015年ThinkPad可以无限期地继续接收安全更新。没有与硬件型号绑定的人为过期日期。只要硬件能运行，机器就仍然有用。
115
+
116
+
% ============================================================
117
+
% 2. THE SURVEILLANCE MACHINE
118
+
% ============================================================
119
+
120
+
\section{监控机器}
121
+
\label{sec:surveillance}
122
+
123
+
Google以低于成本的价格向学校提供Chromebook，因为学生是行为数据的圈养市场~\citep{zuboff2019surveillance, doctorow2020attack}。一个在Google生态系统中长大的学生——Gmail、Google Docs、Google云端硬盘、Google Classroom、YouTube——是终身客户。Chromebook不是慈善捐赠。它是一种针对儿童部署的客户获取策略。
124
+
125
+
\subsection{Google收集什么}
126
+
127
+
从学生Chromebook收集的数据包括：
128
+
129
+
\begin{itemize}
130
+
\item 每一次搜索查询和每一个访问的网站
131
+
\item 每一份打开、编辑和共享的文档
132
+
\item 每一个观看的YouTube视频及观看时长
133
+
\item 击键时间模式和登录频率
134
+
\item 位置数据（蜂窝版机型）
135
+
\item 社交图谱（谁在Google Docs中与谁协作）
136
+
\item 设备诊断和应用使用遥测数据
137
+
\end{itemize}
138
+
139
+
Google声称在Workspace for Education"核心服务"下收集的数据不用于广告。但"附加服务"——YouTube、Google搜索、登录状态下的Google地图——在不同的条款下运营。学校Chromebook上的学生不断使用这些附加服务，数据流向Google的广告基础设施。
140
+
141
+
\subsection{法律行动}
142
+
143
+
法律记录令人震惊。2019年，Google因YouTube违反COPPA——未经家长同意收集儿童数据——向FTC和纽约州总检察长支付了1.7亿美元~\citep{google2019coppa}。2020年，新墨西哥州总检察长Hector Balderas直接起诉Google，指控其通过学校Chromebook收集儿童个人数据~\citep{newmexico2020google}。EFF于2015年向FTC提交投诉，记录了Google通过Chromebook对学生浏览活动进行数据挖掘~\citep{eff2015chromebook}。2024年，一个数字权利组织联盟就持续的学生监控向FTC提交了额外投诉~\citep{eff2024monitoring}。指控根据伊利诺伊州BIPA法规从学生处收集生物识别数据的集体诉讼正在进行中。
144
+
145
+
这些数据是从未成年人那里收集的，在一个参与是强制性的机构环境中，使用的是学生没有选择且无法配置的机器。学生无法选择退出。家长通常也无法选择退出。学区签了合同，孩子们受其约束。
146
+
147
+
\subsection{监控软件}
148
+
149
+
除了Google自身的数据收集之外，学区还在Chromebook上叠加了额外的监控软件——Gaggle、GoGuardian、Securly。EFF记录了这些工具监视私人通信，并不成比例地针对弱势群体、少数族裔和LGBTQ青年~\citep{eff2024monitoring}。在EFF调查的152项教育科技服务中，只有118项发布了隐私政策；更少的涉及数据保留、加密或去标识化。
150
+
151
+
Winner认为技术制品具有政治性~\citep{winner1980artifacts}。Chromebook的政治性很明确：它是一种在被监控者没有选择、没有救济途径、也不了解什么被夺走的情境中部署的监控工具。
152
+
153
+
一个自由开放的操作系统不收集任何遥测数据。它不向任何公司发送信息。它不建立任何行为档案。学生的注意力、好奇心、错误、探索——所有这些都保持私密，因为机器没有经济动机去观察它们。
154
+
155
+
% ============================================================
156
+
% 3. THE LLM INFLECTION
157
+
% ============================================================
158
+
159
+
\section{人人都是程序员了}
160
+
161
+
大语言模型改变了编程的经济学。一个能用自然语言描述需求的学生就能产出可用的代码。计算创造的门槛已从"多年的技术训练"降至"表达想法的能力"。Karpathy的观察——"最热门的新编程语言是英语"——已不再是夸张，而是对物质现实的描述。
162
+
163
+
这是自个人电脑以来计算领域最重要的变革。而它使Chromebook问题变得\emph{灾难性地更糟}。
164
+
165
+
\subsection{新的素养}
166
+
167
+
如果人人都能编程，那么编程就是素养。而素养需要识字者能够拥有的工具。你不会通过给孩子一本只能在特定建筑物中用特定企业账户打开的锁住的书来教他们阅读。你把书给他们。他们带回家。在床上阅读。在页边空白处写字。借给朋友。
168
+
169
+
一个拥有LLM和开放操作系统的学生可以：
170
+
171
+
\begin{itemize}
172
+
\item 构建一个工具来整理作业
173
+
\item 编写一个游戏并与同学分享
174
+
\item 自动化老师布置的重复性任务
175
+
\item 创建一个向社区销售软件的小企业
176
+
\item 为服务人类的开源项目做贡献
177
+
\item 理解和修改管理其数字生活的系统
178
+
\item 通过直接操作探索逻辑、数学和语言
179
+
\item 构建艺术表达的工具
180
+
\end{itemize}
181
+
182
+
一个拥有LLM和Chromebook的学生可以更快地使用Google Docs。
183
+
184
+
Ko（华盛顿大学）认为，如果AI能写代码，计算机科学教育必须转向系统思维、调试和评估——所有这些都需要访问真正的开发环境，而非沙盒浏览器~\citep{denny2024computing}。Krishnamurthi（布朗大学）批评了将编程简化为提示词的方法。计算机科学教育研究中正在形成的共识是，LLM使全栈访问变得\emph{更加}重要，而非不那么重要~\citep{prather2024robots}：学生需要运行、调试、修改和理解生成的代码。Chromebook使这四点都更加困难。
185
+
186
+
\subsection{Chromebook无法执行}
187
+
188
+
这是具体的失败：LLM生成了一个Python脚本，而Chromebook无法运行它。LLM生成了一个Web服务器，而Chromebook无法托管它。LLM编写了C代码，而Chromebook没有编译器。LLM教学生操作系统是如何工作的，而Chromebook不让他们查看。
189
+
190
+
在典型的学校Chromebook（MediaTek或Celeron处理器，4\,GB内存）上，即使Linux容器——当启用时——也难以运行基本的开发工具链。运行本地LLM在物理上是不可能的：即使是量化的1B参数模型也需要超过大多数学校Chromebook所拥有的内存。
191
+
192
+
替代方案是显而易见的。一台拥有8\,GB内存、运行Linux的二手ThinkPad可以执行任何LLM生成的代码，通过Ollama以交互速度运行本地3B参数模型，托管Web服务器，编译程序，并给予学生对整个系统的root访问权限。硬件存在。软件是免费的。Chromebook是瓶颈。
193
+
194
+
\subsection{精神维度}
195
+
196
+
这不仅仅关乎经济或职业准备。计算有一个精神维度，而Chromebook的架构将其消灭了。
197
+
198
+
当学生编写的程序做了一些他们没有预料到的事情——当机器以他们定义的规则所产生的涌现行为让他们惊讶时——他们体验到了一些深刻的东西。他们遇到了意图与结果之间的边界。他们学到系统有其自身的逻辑。他们发展出了与抽象本身的关系。
199
+
200
+
Papert理解这一点~\citep{papert1980mindstorms}：Logo不是关于教编程。它是关于给孩子一个思考思维的媒介。海龟是认识论的载体。
201
+
202
+
LLM将此放大了千倍。学生现在可以与计算媒介进行\emph{对话}。他们可以问"如果怎样？"并在几秒钟内得到答案。他们可以以思维的速度迭代想法。他们可以探索任何课程都未预见到的路径。
203
+
204
+
但前提是机器允许他们这样做。Chromebook不允许。Chromebook说：你可以消费服务。你不能创建基础设施。你不能在自己的机器上以自己的方式运行自己的代码。
205
+
206
+
% ============================================================
207
+
% 4. WHAT STUDENTS DESERVE
208
+
% ============================================================
209
+
210
+
\section{每个学生应得的}
211
+
212
+
每个学生都应拥有一台：
213
+
214
+
\begin{enumerate}
215
+
\item \textbf{他们能理解的}计算机。操作系统的源代码应该可供查阅。不是作为抽象原则，而是作为实际现实：学生应该能够阅读当他们按下一个键时运行的代码。
216
+
217
+
\item \textbf{他们能修改的}计算机。如果学生想改变机器的行为方式，他们应该能够做到。不是通过应用商店，不是通过设置面板，而是通过修改代码。
218
+
219
+
\item \textbf{他们能拥有的}计算机。学生的作品应该存在学生的机器上。不是在企业服务器上，不是在毕业后就会被停用的云账户中。
220
+
221
+
\item \textbf{他们能分享的}计算机。学生应该能够把他们的软件给朋友。不是通过平台，不是通过市场，而是通过复制文件。
222
+
223
+
\item \textbf{他们能弄坏的}计算机。学生应该能够弄坏机器并修复它。这就是学习的方式。一个不能被弄坏的系统是不能被理解的。
224
+
225
+
\item \textbf{他们能带走的}计算机。当学生离开学校时，计算机——以及上面的一切——跟着他们走。他们的计算生活不是租来的。是他们自己的。
226
+
227
+
\item \textbf{尊重他们注意力的}计算机。操作系统不应包含广告、行为追踪或参与度优化。学生的注意力属于学生。
228
+
229
+
\item \textbf{将他们与社区连接的}计算机。学生应该能够为计算景观做贡献——编写他人使用的代码，参与开源项目，构建服务社区、维护其生活方式和福祉的工具。
230
+
\end{enumerate}
231
+
232
+
ChromeOS违反了这些要求中的每一项。自由开放的操作系统满足了每一项。
233
+
234
+
% ============================================================
235
+
% 5. IT ALREADY WORKS
236
+
% ============================================================
237
+
238
+
\section{它已经在运作了：国际先例}
239
+
240
+
开源学校计算未经测试的反对意见是错误的。它已经在三大洲进行了大规模测试。
241
+
242
+
\subsection{印度喀拉拉邦：16,000所学校}
243
+
244
+
喀拉拉邦的KITE（Kerala Infrastructure and Technology for Education）项目于2007年在16,000多所公立学校全面转向自由软件。2024年8月发布的KITE GNU/Linux 22.04运行在超过300,000台学校计算机上~\citep{kite2024gnulinux}。该发行版包括教育软件（Krita、GCompris、PictoBlox）、基本的AI/ML教学工具和Wayland显示服务器。估计节省：300亿印度卢比（约4亿美元）。超过150,000名小学教师接受了培训。印度国家法律学院将KITE誉为教育领域开源转型的国家标杆。
245
+
246
+
这不是试点项目。这是一个服务数百万学生的全邦部署，已持续运行近二十年。
247
+
248
+
\subsection{德国石勒苏益格-荷尔斯泰因：30,000台PC}
249
+
250
+
到2025年夏末，德国石勒苏益格-荷尔斯泰因州完成了近30,000台政府PC从Microsoft到Linux的迁移，预计另有30,000名公立学校教师将跟进~\citep{schleswig2025linux}。替代方案包括LibreOffice、Nextcloud、Open-Xchange和Mozilla Thunderbird。估计节省：仅2026年就达1500万欧元。丹麦于2025年6月至11月间宣布了类似的转型。
251
+
252
+
\subsection{法国：国家开源战略}
253
+
254
+
法国2023--2027年数字教育战略由教育部的Alexis Kauffmann领导，明确以数字主权和减少对Microsoft和Google的依赖为目标~\citep{france2023digital}。国家平台\texttt{apps.education.fr}向所有法国教师提供开源工具。2025年，法国颁布了互操作性法令，要求学校使用符合开放标准的数字工具——为开源解决方案创造了结构性优势。
255
+
256
+
\subsection{宾夕法尼亚州Penn Manor：1,725台Linux笔记本}
257
+
258
+
在美国，宾夕法尼亚州兰开斯特的Penn Manor学区向9--12年级的学生部署了1,725台Ubuntu笔记本~\citep{pennmanor2024linux}。该项目包括一个学生主导的维修计划，学生学习修理自己的机器。这不是一个拥有特殊资金的特殊学区。这是一个做出了不同选择的公立学区。
259
+
260
+
\subsection{"公共资金，公共代码"运动}
261
+
262
+
欧洲自由软件基金会的"Public Money? Public Code!"运动——主张用公共资金开发的软件应以自由许可证发布——已汇集了200多个民间社会组织和31,000名个人签署者~\citep{fsfe2024publiccode}。联合国教科文组织2024年迪拜开放教育资源宣言正式承诺签署国通过AI和新兴技术推进开放资源~\citep{unesco2024oer}。全球数字契约承诺"开发、传播和维护造福社会的开源软件、开放数据、开放AI模型和开放标准。"
263
+
264
+
这些不是边缘运动。它们是国际政策的方向。
265
+
266
+
% ============================================================
267
+
% 6. THE ECONOMICS
268
+
% ============================================================
269
+
270
+
\section{经济学}
271
+
272
+
\subsection{成本借口}
273
+
274
+
Chromebook很便宜。但运行Linux的二手笔记本也一样。一台退役的ThinkPad T480或Dell Latitude 5400批量价格为\$100--180，在除"由Google管理"之外的每个维度上都是更优秀的机器。支持Chromebook的成本论据是支持Google生态系统的论据，而非支持硬件的论据。
275
+
276
+
\begin{table}[H]
277
+
\small
278
+
\centering
279
+
\begin{tabular}{lrr}
280
+
\toprule
281
+
\textbf{方案} & \textbf{成本} & \textbf{学生拥有它} \\
282
+
\midrule
283
+
Chromebook（新） & \$250--350 & 否 \\
284
+
Chrome Edu Upgrade & +\$38/台 & 否 \\
285
+
Google Workspace Plus & +\$5/学生/年 & 否 \\
286
+
iPad（教育版） & \$299+ & 否 \\
287
+
\midrule
288
+
二手笔记本 + Linux & \$100--180 & \textbf{是} \\
289
+
二手笔记本 + AC OS & \$100--180 & \textbf{是} \\
290
+
\bottomrule
291
+
\end{tabular}
292
+
\caption{成本与所有权比较。Chromebook成本不包括监控软件（GoGuardian：\$5--10/台/年）和强制AUE更换。}
293
+
\label{tab:cost}
294
+
\end{table}
295
+
296
+
计入Google的Chrome Education Upgrade（\$38/台）、Workspace for Education Plus（\$5/学生/年）、监控软件以及AUE强制更换周期后，一台Chromebook5年的总拥有成本可达\$450--550/台。一台运行Linux的二手ThinkPad：\$100--180，零持续许可费用，无人为过期日期，学生可以保留。
297
+
298
+
\subsection{供应}
299
+
300
+
机器是存在的。据估计，美国每年有5000--6000万台商用PC退役。企业租赁周期每3--5年淘汰数百万台功能正常的笔记本——配备现代处理器、8--16\,GB内存、WiFi和6--10小时电池的机器。PCs for People（每年10万台以上）、Human-I-T（每年5万台以上）、Kramden Institute、Free Geek以及联邦Computers for Learning项目等组织已在翻新和分发这些机器。
301
+
302
+
一间30台创意计算工具的教室可以用\$3,000--5,400的硬件来配置。无持续订阅。无IT支持合同。无托管账户。
303
+
304
+
\subsection{环境论据}
305
+
306
+
一台典型的笔记本在制造过程中产生300--400公斤CO$_2$e——占其总生命周期碳足迹的70--80\%。翻新增加约5--15公斤CO$_2$e。Circular Computing独立审计的分析发现每台再制造笔记本节省316公斤CO$_2$e~\citep{circularcomputing2023carbon}。联合国2024年全球电子废物监测报告称美国每年产生约720万吨电子废物，其中仅25\%得到妥善回收~\citep{un2024ewaste}。
307
+
308
+
Google的AUE政策迫使学校丢弃数百万台可用的Chromebook。维修权立法正在开始解决这个问题：俄勒冈州法律（2025年1月生效）要求制造商提供零件和维修信息~\citep{oregon2024repair}；新罕布什尔州的HB1701明确涵盖学校提供的笔记本~\citep{newhampshire2024repair}。但立法无法修复一项将功能正常的硬件宣布为过时的软件政策。
309
+
310
+
Linux没有AUE。运行自由操作系统的笔记本在硬件能运行的情况下就仍然有用。
311
+
312
+
% ============================================================
313
+
% 7. THE OPEN STACK
314
+
% ============================================================
315
+
316
+
\section{开放栈}
317
+
318
+
\subsection{每台Chromebook已经是一台Linux机器}
319
+
320
+
荒谬的是：每台Chromebook已经在运行Linux内核。ChromeOS是带有锁定用户空间的Linux，强制所有交互通过Google的浏览器进行。硬件完全有能力运行自由操作系统。Google拿了一个自由内核，用专有限制包装它，然后作为节约成本的措施卖给学校。
321
+
322
+
解放这些机器不需要新硬件。只需要刷入新软件。许多Chromebook可以解锁并用标准Linux发行版或\acos{}重新刷写。这台机器\emph{本来就想要自由}。Google是那把锁。
323
+
324
+
\subsection{IT借口}
325
+
326
+
学校IT部门选择Chromebook是因为它们"易于管理"。这是事实。管理一台什么都不做的机器确实很容易。当每台设备都是单一公司服务的瘦客户端时，管理一个设备群确实很容易。管理的便利性是机器无能的直接后果。
327
+
328
+
问题是：对谁而言容易？对IT部门当然容易。但对学生来说是灾难性的。IT部门的便利是以学生的自主权为代价购买的。这是一笔糟糕的交易。
329
+
330
+
开源管理工具是存在的。NixOS提供可复现的系统配置。Ansible自动化设备群部署。PXE启动实现零接触配置。\acos{}~\citep{scudder2026acos}证明了整个操作系统可以通过在不到一分钟内刷入USB驱动器来部署，OTA更新无需任何IT基础设施。Penn Manor用比同等Chromebook学区更小的IT团队运行1,725台Linux笔记本~\citep{pennmanor2024linux}。"管理问题"已经解决。剩下的是制度惯性和与Google的合同关系——它服务于机构，而非学生。
331
+
332
+
\subsection{LLM基础设施}
333
+
334
+
开放系统使得与AI建立根本不同的关系成为可能。一台二手服务器（32--64\,GB内存，或一块\$100--200的二手NVIDIA T4 GPU）可以运行Ollama并通过Open WebUI——一个免费的开源LLM前端——为整个教室的学生提供服务。学生通过浏览器从笔记本连接到本地服务器。Llama 3.2 3B（4\,GB即可运行）、DeepSeek Coder 6.7B或Qwen 2.5 Coder 7B等模型提供强大的代码生成能力。
335
+
336
+
这是学校拥有的本地AI基础设施，不收集遥测数据，不向任何公司发送数据，学生可以查看、修改和学习。替代方案——集成在Workspace for Education中的Google Gemini——增加了又一层企业依赖、又一条数据管道、又一笔订阅费。
337
+
338
+
% ============================================================
339
+
% 8. THE LLM GATEWAY
340
+
% ============================================================
341
+
342
+
\section{学生作为创作者}
343
+
344
+
在一个拥有LLM访问权限的开放系统上，学生可以：
345
+
346
+
\begin{itemize}
347
+
\item 让LLM解释操作系统的源代码
348
+
\item 生成在本地运行的、具有完全硬件访问权限的程序
349
+
\item 构建Web服务器、数据库、API——真正的基础设施
350
+
\item 创建解决社区真实问题的工具
351
+
\item 通过实际构建来学习任何编程语言
352
+
\item 通过检查LLM的输入和输出来理解LLM本身
353
+
\item 在\ac{}~\citep{scudder2026ac}上创建一个世界上任何人都可以运行的作品
354
+
\end{itemize}
355
+
356
+
LLM成为一个有无限耐心的导师，全天24小时可用，在学生所在的位置精确地与其对接~\citep{khan2024bravenew}。但这个导师只有在学生拥有一台能够\emph{执行}导师产出的机器时才能有效。
357
+
358
+
Chromebook模式说：你是用户。开放模式说：你是创作者。在LLM时代，这两种框架之间的区别就是数字素养与数字农奴制之间的区别。
359
+
360
+
% ============================================================
361
+
% 9. A PATH FORWARD
362
+
% ============================================================
363
+
364
+
\section{前进之路}
365
+
366
+
\subsection{第一阶段：认知}
367
+
368
+
家长、教师和学校董事会成员必须理解Chromebook到底是什么：一种教授习得性无助的监控设备。第一步是教育——不是教育孩子，而是教育那些购买机器的成年人。EFF的"Spying on Students"文档、美国PIRG的"Chromebook Churn"报告以及新墨西哥州总检察长的诉讼提供了可以在学校董事会会议上展示的具体证据。
369
+
370
+
\subsection{第二阶段：试点项目}
371
+
372
+
学区应参照Penn Manor的模式试点开源替代方案：
373
+
374
+
\begin{itemize}
375
+
\item 30台运行Linux或\acos{}的二手笔记本，采购费用\$3,000--5,400
376
+
\item 一台本地LLM服务器（一台二手工作站，\$200--500）运行Ollama + Open WebUI
377
+
\item 一套LLM辅助的课程，让学生构建真正的软件
378
+
\item 学生所有权：机器跟学生一起带回家
379
+
\item 学生主导的维修项目（Penn Manor的学生修理自己的机器）
380
+
\item 无云依赖：作品本地存储，由学生自行备份
381
+
\item 开放评估：学生的作品集是他们写的代码、构建的工具、做出的贡献
382
+
\end{itemize}
383
+
384
+
\subsection{第三阶段：政策}
385
+
386
+
州和学区应采纳要求以下事项的政策：
387
+
388
+
\begin{enumerate}
389
+
\item 部署在学生设备上的所有软件必须是开源或源代码可用的
390
+
\item 学生对自己的机器拥有root访问权限
391
+
\item 不从学生设备收集行为遥测数据
392
+
\item 学生保留在学校设备上产出的所有作品的所有权
393
+
\item 毕业学生保留其设备
394
+
\item 设备采购优先考虑翻新硬件而非新制造
395
+
\end{enumerate}
396
+
397
+
超过40个州已通过学生数据隐私法。加利福尼亚州的SOPIPA禁止将学生数据用于定向广告。新的COPPA规则（2025年6月生效）加强了儿童数据保护。这些立法趋势支持了开放、无监控的学校计算基础设施的论证。
398
+
399
+
\subsection{第四阶段：解放}
400
+
401
+
最终目标不是政策变化。而是文化转变。最终目标是一代理解计算机不是他们消费的产品而是他们演奏的乐器的学生——一种思考、创造和贡献的媒介。能像阅读书籍一样阅读源代码的学生。能像木匠改造工作台一样修改工具的学生。将计算视为公共资源而非企业服务的学生——他们既贡献于此，也归属于此。
402
+
403
+
Nelson在1974年写道~\citep{nelson1974computerlib}："你现在就能够而且必须理解计算机。"五十年后，我们恰恰以Nelson所担忧的方式辜负了这一命令——将机器交给企业，然后称之为进步。
404
+
405
+
LLM时刻使这种失败变得可见。每个学生现在都有编程的\emph{能力}。他们缺少的是一台\emph{允许他们这样做的机器}。这是一个可以解决的问题。技术是免费的。硬件是剩余的。每个学生与他们自己的计算道路之间唯一的障碍是一个从未被设计来服务他们的企业操作系统。
406
+
407
+
% ============================================================
408
+
% 10. CONCLUSION
409
+
% ============================================================
410
+
411
+
\section{结论}
412
+
413
+
美国每所学校中的每一台Chromebook都是一台被锁链束缚的Linux机器。硬件可以运行自由操作系统。学生可以借助LLM学习编程。二手笔记本市场提供\$100--180的机器。整个开源栈可以零成本获得。喀拉拉邦已为300,000台计算机做到了。石勒苏益格-荷尔斯泰因已为30,000台做到了。Penn Manor已为1,725台做到了。它有效。
414
+
415
+
我们缺的不是技术。我们缺的是将学生自主权置于制度便利和企业利润之上的政治意愿。
416
+
417
+
Illich写道，工具应该扩展个人自主权而非要求专业知识~\citep{illich1973tools}。Papert写道，计算机应该是思考思维的工具~\citep{papert1980mindstorms}。Stallman写道，用户应有权控制他们运行的软件~\citep{stallman2002free}。Postman警告说，学校中没有目的的技术服务的是技术而非孩子~\citep{postman1995end}。这些不是边缘立场。它们是个人计算的基本原则，而我们在它们最重要的地方放弃了它们：儿童教育。
418
+
419
+
让闭源软件离开学校。给每个学生一个自由开放的操作系统。让Chromebook成为它一直有能力成为的东西：不是一道栅栏，而是一扇\emph{大门}——通向逻辑、创造力、社区、精神性，以及每个学生在计算景观中的独特道路。
420
+
421
+
在LLM时代，这不是理想主义。这是最低限度的可行教育。
422
+
423
+
\vspace{0.5em}
424
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
425
+
426
+
\end{multicols}
427
+
428
+
% ============================================================
429
+
% REFERENCES
430
+
% ============================================================
431
+
432
+
\bibliographystyle{plainnat}
433
+
\bibliography{references}
434
+
435
+
\end{document}
+261
papers/arxiv-score-analysis/score-analysis-da.tex
+261
papers/arxiv-score-analysis/score-analysis-da.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\setmainfont{Latin Modern Roman}
11
+
\setsansfont{Latin Modern Sans}
12
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
13
+
\newfontfamily\acbold{ywft-processing-bold}[
14
+
Path=../../system/public/type/webfonts/,
15
+
Extension=.ttf
16
+
]
17
+
\newfontfamily\aclight{ywft-processing-light}[
18
+
Path=../../system/public/type/webfonts/,
19
+
Extension=.ttf
20
+
]
21
+
22
+
% === PACKAGES ===
23
+
\usepackage{xcolor}
24
+
\usepackage{titlesec}
25
+
\usepackage{enumitem}
26
+
\usepackage{booktabs}
27
+
\usepackage{tabularx}
28
+
\usepackage{fancyhdr}
29
+
\usepackage{hyperref}
30
+
\usepackage{graphicx}
31
+
\usepackage{ragged2e}
32
+
\usepackage{microtype}
33
+
\usepackage{natbib}
34
+
\usepackage[colorspec=0.92]{draftwatermark}
35
+
36
+
% === COLORS ===
37
+
\definecolor{acpink}{RGB}{180,72,135}
38
+
\definecolor{acpurple}{RGB}{120,80,180}
39
+
\definecolor{acdark}{RGB}{64,56,74}
40
+
\definecolor{acgray}{RGB}{119,119,119}
41
+
\definecolor{draftcolor}{RGB}{180,72,135}
42
+
43
+
% === DRAFT WATERMARK ===
44
+
\DraftwatermarkOptions{
45
+
text=WORKING DRAFT,
46
+
fontsize=3cm,
47
+
color=draftcolor!18,
48
+
angle=45,
49
+
pos={0.5\paperwidth, 0.5\paperheight}
50
+
}
51
+
52
+
% === HYPERREF ===
53
+
\hypersetup{
54
+
colorlinks=true,
55
+
linkcolor=acpurple,
56
+
urlcolor=acpurple,
57
+
citecolor=acpurple,
58
+
pdfauthor={@jeffrey},
59
+
pdftitle={At l\ae se partituret},
60
+
}
61
+
62
+
% === SECTION FORMATTING ===
63
+
\titleformat{\section}
64
+
{\normalfont\bfseries\normalsize\uppercase}
65
+
{\thesection.}
66
+
{0.5em}
67
+
{}
68
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
69
+
70
+
\titleformat{\subsection}
71
+
{\normalfont\bfseries\small}
72
+
{\thesubsection}
73
+
{0.5em}
74
+
{}
75
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
76
+
77
+
% === HEADER/FOOTER ===
78
+
\pagestyle{fancy}
79
+
\fancyhf{}
80
+
\renewcommand{\headrulewidth}{0pt}
81
+
\fancyhead[C]{\footnotesize\color{draftcolor}\textit{Arbejdsudkast --- ikke til citation}}
82
+
\fancyfoot[C]{\footnotesize\thepage}
83
+
84
+
% === LIST SETTINGS ===
85
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
86
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
87
+
88
+
% === COLUMN SEPARATION ===
89
+
\setlength{\columnsep}{1.8em}
90
+
91
+
% === PARAGRAPH SETTINGS ===
92
+
\setlength{\parindent}{1em}
93
+
\setlength{\parskip}{0.3em}
94
+
95
+
% Hyphenation for narrow two-column layout
96
+
\tolerance=800
97
+
\emergencystretch=1em
98
+
\hyphenpenalty=50
99
+
100
+
\begin{document}
101
+
102
+
% === TITLE ===
103
+
\twocolumn[
104
+
\begin{center}
105
+
{\acbold\LARGE At l\ae se partituret: En kritisk analyse af\\SCORE.md som styring, gr\ae nseflade og kreativ form\par}
106
+
\vspace{0.4em}
107
+
{\large @jeffrey}\\
108
+
{\small\color{acgray} ORCID: 0009-0007-4460-4913}\\
109
+
{\small\color{acgray} \url{https://aesthetic.computer}}
110
+
\vspace{0.3em}
111
+
112
+
\rule{0.6\textwidth}{0.5pt}
113
+
\vspace{0.3em}
114
+
115
+
\begin{minipage}{0.85\textwidth}
116
+
\small
117
+
\textbf{Abstrakt.}
118
+
Aesthetic Computer-projektet erstattede sin README med et dokument kaldet SCORE.md.
119
+
Denne artikel unders\o ger, hvad den omd\o bning gjorde --- og hvad den efterlod ugjort.
120
+
Med udgangspunkt i femten artikler skrevet fra projektets forskningsplatte l\ae ser vi
121
+
partituret op mod dets egne ambitioner: som styringsdokument, som teknisk reference,
122
+
som kreativ form. Vi finder, at partituret lykkes som organiserende metafor, men
123
+
k\ae mper som dokument --- fanget mellem kravene fra AI-agenter, nye bidragydere,
124
+
projektets egen historie og forfatterens kreative praksis. Vi identificerer seks
125
+
sp\ae ndinger i det nuv\ae rende partitur og foresl\aa r en revisionsramme, der tager
126
+
den musikalske metafor alvorligt: et partitur b\o r fort\ae lle dig, hvordan du skal
127
+
udf\o re, ikke blot hvad instrumenterne er.
128
+
\end{minipage}
129
+
\vspace{1em}
130
+
\end{center}
131
+
]
132
+
133
+
\section{Hvad er et partitur?}
134
+
135
+
I musik er et partitur et s\ae t instruktioner til at producere en tidslig begivenhed. Det er ikke selve begivenheden --- det er dokumentet, der g\o r begivenheden reproducerbar. Et partitur b\ae rer i sig en implicit teori om, hvad der er vigtigt: hvilke parametre der skal specificeres, og hvilke der kan overlades til ud\o verens sk\o n.
136
+
137
+
Da Aesthetic Computer-projektet omd\o bte sin README.md til SCORE.md i begyndelsen af marts 2026, importerede det hele denne ramme. Bev\ae gelsen var bevidst. Projektet forstod allerede sine programmer som ``stykker'' snarere end applikationer~\citep{scudder2026pieces}, sin gr\ae nseflade som et instrument~\citep{scudder2026notepat}, og sin grafiske notation (Whistlegraph) som et viralt partitur~\citep{scudder2026whistlegraph}. At omd\o be styringsdokumentet var en m\aa de at sige: dette er ogs\aa\ noget, der skal udf\o res fra.
138
+
139
+
Men et partitur foruds\ae tter ud\o vere. Og sp\o rgsm\aa let, denne artikel stiller, er: hvem udf\o rer fra SCORE.md, og hj\ae lper dokumentet dem faktisk?
140
+
141
+
\section{Platten og partituret}
142
+
143
+
Aesthetic Computers forskningsplatte rummer i \o jeblikket sytten artikler, organiseret i en papirm\o lle med automatiserede builds, overs\ae ttelser til fire sprog og et kortformat til fysisk distribution~\citep{scudder2026cards}. At l\ae se p\aa\ tv\ae rs af disse artikler afsl\o rer et projekt med betydelig ambition og intern sammenh\ae ng --- men ogs\aa\ et projekt, hvis selvbeskrivelse (partituret) ikke har fulgt med dets selvforst\aa else (artiklerne).
144
+
145
+
Artiklerne fort\ae ller en historie, som partituret ikke g\o r. Overvej:
146
+
147
+
\begin{itemize}
148
+
\item Artiklen ``Pieces Not Programs''~\citep{scudder2026pieces} argumenterer for, at ordet ``stykke'' importerer en musikalsk ramme, hvor v\ae rker er forfattede, opf\o rbare og iterbare. Partituret n\ae vner stykker, men forklarer aldrig denne rammes\ae tning.
149
+
\item Notepat-artiklen~\citep{scudder2026notepat} dokumenterer fem feedback-l\o kker, hvorigennem et enkelt stykke trak en hel platform ind i eksistens. Partituret lister notepat som \' et stykke blandt 359.
150
+
\item B\ae redygtighedsartiklen~\citep{scudder2026sustainability} identificerer en median p\aa\ 8 \aa rs kl\o ft mellem v\ae rkt\o jsskabelse og b\ae redygtig finansiering, med casestudier der ender i handicap og d\o d. Partituret har sponsorbadges.
151
+
\item Native OS-artiklen~\citep{scudder2026os} argumenterer for, at overskuds-x86\_64-b\ae rbare til \$50 stykket er det materielle grundlag for et planet\ae rt kreativt instrument. Partituret lister build-kommandoer.
152
+
\item KidLisp Cards-artiklen~\citep{scudder2026cards} demonstrerer, at programkorthed producerer et nyt publiceringsformat --- kortet som eksekverbart partitur. Partituret n\ae vner ikke kort.
153
+
\end{itemize}
154
+
155
+
I hvert tilf\ae lde formulerer artiklen en tese, der giver mening til det, partituret blot katalogiserer. Partituret har fakta, men ikke argumentet.
156
+
157
+
\section{Seks sp\ae ndinger}
158
+
159
+
At l\ae se partituret op mod artiklerne afsl\o rer seks sp\ae ndinger, som en revision b\o r adressere.
160
+
161
+
\subsection{Publikumsforvirring}
162
+
163
+
Partituret \aa bner med en besked til AI-agenter (``If you find something interesting\ldots leave a breadcrumb'') og skifter derefter straks til menneskelig onboarding (``press the top left of the screen''). Afsnittet ``Front Door'' henvender sig til slutbrugere. Afsnittet ``Back Door'' henvender sig til udviklere. Afsnittet ``Ant Guidance'' henvender sig til automatiserede agenter. Afsnittet ``Embodiments'' fors\o ger at forene alle tre.
164
+
165
+
Dette er ikke forkert --- et partitur kan henvende sig til flere ud\o vere. Men et musikalsk partitur g\o r ud\o verens stemme l\ae selig med et blik. SCORE.md kr\ae ver, at l\ae seren selv finder ud af, hvilke dele der er til dem. Et dirigentpartitur og en violinstemme er forskellige dokumenter af god grund.
166
+
167
+
\subsection{Katalog vs. argument}
168
+
169
+
Partituret er organiseret som et katalog: arkitektur, kommandoer, endpoints, backlogs, markedsforesp\o rgsler. Dette er nyttigt referencemateriale, men det kommunikerer intet om, \emph{hvorfor} projektet eksisterer, eller hvilke principper der styrer dets udvikling.
170
+
171
+
Artiklerne formulerer tilsammen mindst fem kerneargumenter:
172
+
\begin{enumerate}
173
+
\item Kreativ software b\o r designes som et instrument, ikke et v\ae rkt\o j~\citep{scudder2026goodiepal}.
174
+
\item ``Stykket'' er en enhed for kreativ kognition, ikke et program~\citep{scudder2026pieces}.
175
+
\item Begr\ae nsning (i sprogdesign, i formfaktor) er generativ, ikke begr\ae nsende~\citep{scudder2026kidlisp, scudder2026cards}.
176
+
\item Overskudshardware + tilpasset OS = planet\ae r adgang~\citep{scudder2026os, scudder2026plork}.
177
+
\item Kreative v\ae rkt\o jer kr\ae ver \o konomiske modeller, der ikke sl\aa r deres skabere ihjel~\citep{scudder2026sustainability}.
178
+
\end{enumerate}
179
+
180
+
Ingen af disse argumenter optr\ae der i partituret. En f\o rstegangsl\ae ser af SCORE.md ville vide, \emph{hvad} Aesthetic Computer er (en runtime med stykker, en prompt, nogle servere), men ikke \emph{hvorfor} det eksisterer, eller hvad det tror p\aa .
181
+
182
+
\subsection{Backlog-problemet}
183
+
184
+
Partituret indeholder et ``AC Native Backlog''-afsnit med syv punkter, der blander f\ae rdige opgaver (``Claude native binary'') med ambiti\o se funktioner (``A/B kernel slots with auto-rollback''). Dette er et projektstyringsartefakt, ikke et partitur. Det kommunikerer taktisk tilstand, ikke strategisk retning.
185
+
186
+
Myrefilosofien (i \texttt{ants/mindset-and-rules.md}) advarer eksplicit mod spekulativt arbejde: ``IDLE is valid---wandering is the job, not failure.'' Alligevel er backloggen i partituret netop spekulativt arbejde, pr\ae senteret som om det var projektets plan. Underpartiturer (fedac/native/SCORE.md, papers/SCORE.md) h\aa ndterer dette bedre ved at adskille vejledning fra opgavelister.
187
+
188
+
\subsection{Keeps-markedsblokken}
189
+
190
+
Partituret dedikerer 90 linjer til Tezos/Objkt GraphQL-foresp\o rgsler til at tjekke Keeps NFT-markedsstatistikker. Dette er operationelt v\ae rkt\o j for \' en bidragyder (forfatteren). Det er v\ae rdifuldt referencemateriale, men det dominerer partiturets sidste halvdel og sender et utilsigtet signal: at NFT-markedsoverv\aa gning er en kernebekymring for projektet, p\aa\ linje med arkitektur og udviklingsworkflow.
191
+
192
+
Artiklen ``Dead Ends''~\citep{scudder2026deadends} kategoriserer eksplicit Tezos/Keeps som et monetiseringseksperiment med usikker fremtid. Partituret pr\ae senterer det som etableret infrastruktur.
193
+
194
+
\subsection{Manglende stemmer}
195
+
196
+
Artiklen ``Network Audit''~\citep{scudder2026audit} afsl\o rer, at AC har 2.811 registrerede handles, men kun 2,1\% skriver KidLisp, og 0,7\% publicerer stykker. Artiklen ``Diversity''~\citep{scudder2026diversity} anerkender, at 80\% af citerede forfattere er vestlige m\ae nd. Artiklen ``Sustainability''~\citep{scudder2026sustainability} dokumenterer den menneskelige omkostning ved ust\o ttet v\ae rkt\o jsskabelse.
197
+
198
+
Partituret engagerer sig ikke med noget af dette. Det pr\ae senterer adoptionstal (``2812 registered handles, 265 user-published pieces'') som pr\ae station snarere end som data, der kr\ae ver fortolkning. Artiklerne er mere \ae rlige end partituret.
199
+
200
+
\subsection{Underpartiturer vs. hovedpartitur}
201
+
202
+
Projektet har nu seks SCORE.md-filer: rod, papers, fedac, fedac/native, opinion og vault. Underpartiturer er generelt bedre dokumenter end hovedpartituret. Papers-partituret indleder med en ``Mill Mission'', der forklarer, \emph{hvorfor} det eksisterer. Native-partituret definerer ``shipped'' med fem verificerbare kriterier. Vault-partituret kortl\ae gger sikkerhedsstillingen.
203
+
204
+
Hovedpartituret fors\o ger derimod at v\ae re alt: README, arkitekturdokument, udviklerguide, operationel runbook og NFT-dashboard. Underpartiturer lykkedes ved at v\ae re specifikke. Hovedpartituret k\ae mper ved at v\ae re alt-omfattende.
205
+
206
+
\section{Partiturmetaforen, taget alvorligt}
207
+
208
+
Hvis SCORE.md er et partitur, hvilken slags partitur b\o r det da v\ae re? Den musikalske analogi antyder flere egenskaber:
209
+
210
+
\textbf{Et partitur fort\ae ller dig, hvordan du begynder.} Det nuv\ae rende partiturs ``Front Door'' g\o r dette tilstr\ae kkeligt for slutbrugere, men ikke for bidragydere eller agenter. En ud\o ver, der tager et partitur op, beh\o ver at vide: hvilket instrument spiller jeg? Hvor kommer jeg ind? Hvad er tempoet?
211
+
212
+
\textbf{Et partitur har stemmer.} Forskellige ud\o vere l\ae ser forskellige stemmer. Det nuv\ae rende partitur blander alle stemmer i \' et dokument. Underpartiturer er i realiteten individuelle stemmer, der er blevet udtrukket. Hovedpartituret b\o r v\ae re dirigentpartituret: et overblik der peger p\aa\ stemmer, ikke en sammenf\o jning af alle stemmer.
213
+
214
+
\textbf{Et partitur foruds\ae tter en opf\o relsespraxis.} Der er konventioner om, hvordan man l\ae ser og udf\o rer et partitur, som ikke er skrevet i selve partituret. Myrefilosofi-dokumentet tjener denne funktion for AI-agenter. Intet tilsvarende eksisterer for menneskelige bidragydere.
215
+
216
+
\textbf{Et partitur kan revideres.} Partiturer har udgaver. Det nuv\ae rende SCORE.md har ingen versionshistorik eller \ae ndringslog i selve dokumentet. Det l\ae ses, som om det altid har v\ae ret s\aa dan, n\aa r det faktisk var en README indtil for to uger siden.
217
+
218
+
\textbf{Et partitur er ikke opf\o relsen.} Partituret b\o r ikke fors\o ge at indeholde projektet. Det b\o r v\ae re det minimale dokument, hvorfra projektet kan udf\o res. Alt andet --- backlogs, markedsforesp\o rgsler, operationelt v\ae rkt\o j --- h\o rer hjemme i stemmer eller appendikser.
219
+
220
+
\section{Hvad artiklerne ved, som partituret ikke g\o r}
221
+
222
+
Det mest sl\aa ende fund ved at l\ae se alle sytten artikler op mod partituret er, hvor meget rigere projektets selvforst\aa else er i artiklerne end i partituret. Artiklerne indeholder:
223
+
224
+
\begin{itemize}
225
+
\item En teori om kreativ kognition (stykker som perceptions-handlingscyklusser)
226
+
\item En politisk \o konomi for v\ae rkt\o jsskabelse (hvem betaler, hvem br\ae nder ud, hvem d\o r)
227
+
\item En designfilosofi (instrument-f\o rst, begr\ae nsning-som-generativ, flad-over-dyb)
228
+
\item Et materielt argument om hardware (overskudsb\ae rbare som planet\ae rt instrument)
229
+
\item En \ae rlig revision af fejl (16 blindgyder, 50\% bidragsrate)
230
+
\item En forpligtelse til citationsdiversitet med specifikke m\aa l
231
+
\item En publiceringsinfrastruktur (m\o llen) med sin egen missionsbeskrivelse
232
+
\end{itemize}
233
+
234
+
Partituret indeholder intet af dette. Det er et teknisk dokument, der tilf\ae ldigvis hedder et partitur. Revisionen b\o r g\o re det til et faktisk partitur: et dokument der b\ae rer projektets argumenter, ikke blot dets arkitektur.
235
+
236
+
\section{Mod et revideret partitur}
237
+
238
+
Et revideret SCORE.md b\o r:
239
+
240
+
\begin{enumerate}
241
+
\item \textbf{Indlede med hvorfor.} Angiv hvad projektet tror p\aa , og hvorfor det eksisterer, med udgangspunkt i argumenterne formuleret p\aa\ tv\ae rs af artiklerne. Mill mission i papers/SCORE.md er en model for dette.
242
+
\item \textbf{Adskille stemmer fra dirigentpartituret.} Flyt operationelle detaljer (Keeps-foresp\o rgsler, backlog-punkter, kommandoreferencer) til underpartiturer eller appendikser. Hovedpartituret b\o r kunne l\ae ses p\aa\ fem minutter.
243
+
\item \textbf{Navngive sine publikummer.} Henvend dig eksplicit til de tre ud\o vertyper (slutbrugere, menneskelige bidragydere, AI-agenter) med klare indgangspunkter for hver.
244
+
\item \textbf{Inkludere de \ae rlige tal.} Pr\ae sent\' er adoptionsdata med fortolkning, ikke blot som badges. 2,1\% KidLisp-forfatterskab er et faktum, der betyder noget --- partituret b\o r sige hvad.
245
+
\item \textbf{Referere til artiklerne.} Platten eksisterer. Partituret b\o r pege p\aa\ den som projektets udvidede selvforst\aa else, ikke ignorere den.
246
+
\item \textbf{Anerkende sin egen historie.} Bem\ae rk at dette dokument var en README indtil marts 2026, og at omd\o bningen i sig selv var en kreativ handling med konsekvenser.
247
+
\item \textbf{V\ae re kortere.} Det nuv\ae rende partitur er 361 linjer. Et partitur, der tager sig selv alvorligt, b\o r v\ae re t\ae ttere p\aa\ l\ae ngden af et stykke, der kan v\ae re p\aa\ et kort.
248
+
\end{enumerate}
249
+
250
+
\section{Konklusion}
251
+
252
+
SCORE.md er et godt navn for det, Aesthetic Computer-projektet har brug for: et dokument der g\o r projektet opf\o rbart. Men det nuv\ae rende partitur er et katalog, ikke en komposition. Det lister, hvad projektet indeholder, uden at argumentere for, hvad det betyder. Artiklerne p\aa\ forskningsplatten --- skrevet i de samme uger som partituret --- indeholder argumenterne, de \ae rlige vurderinger og de kreative rammer, som partituret mangler.
253
+
254
+
Den mest produktive revision ville ikke tilf\o je til partituret, men tr\ae kke fra det, flytte operationelle detaljer til underpartiturer og erstatte dem med projektets faktiske overbevisninger. Underpartiturer (papers, native, vault) demonstrerer allerede denne tilgang. Hovedpartituret b\o r l\ae re af sine egne stemmer.
255
+
256
+
Et partitur er ikke en beskrivelse af et orkester. Det er den minimale notation, der kr\ae ves for at producere musik. SCORE.md b\o r str\ae be efter den samme \o konomi.
257
+
258
+
\bibliographystyle{plainnat}
259
+
\bibliography{references}
260
+
261
+
\end{document}
+261
papers/arxiv-score-analysis/score-analysis-es.tex
+261
papers/arxiv-score-analysis/score-analysis-es.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\setmainfont{Latin Modern Roman}
11
+
\setsansfont{Latin Modern Sans}
12
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
13
+
\newfontfamily\acbold{ywft-processing-bold}[
14
+
Path=../../system/public/type/webfonts/,
15
+
Extension=.ttf
16
+
]
17
+
\newfontfamily\aclight{ywft-processing-light}[
18
+
Path=../../system/public/type/webfonts/,
19
+
Extension=.ttf
20
+
]
21
+
22
+
% === PACKAGES ===
23
+
\usepackage{xcolor}
24
+
\usepackage{titlesec}
25
+
\usepackage{enumitem}
26
+
\usepackage{booktabs}
27
+
\usepackage{tabularx}
28
+
\usepackage{fancyhdr}
29
+
\usepackage{hyperref}
30
+
\usepackage{graphicx}
31
+
\usepackage{ragged2e}
32
+
\usepackage{microtype}
33
+
\usepackage{natbib}
34
+
\usepackage[colorspec=0.92]{draftwatermark}
35
+
36
+
% === COLORS ===
37
+
\definecolor{acpink}{RGB}{180,72,135}
38
+
\definecolor{acpurple}{RGB}{120,80,180}
39
+
\definecolor{acdark}{RGB}{64,56,74}
40
+
\definecolor{acgray}{RGB}{119,119,119}
41
+
\definecolor{draftcolor}{RGB}{180,72,135}
42
+
43
+
% === DRAFT WATERMARK ===
44
+
\DraftwatermarkOptions{
45
+
text=WORKING DRAFT,
46
+
fontsize=3cm,
47
+
color=draftcolor!18,
48
+
angle=45,
49
+
pos={0.5\paperwidth, 0.5\paperheight}
50
+
}
51
+
52
+
% === HYPERREF ===
53
+
\hypersetup{
54
+
colorlinks=true,
55
+
linkcolor=acpurple,
56
+
urlcolor=acpurple,
57
+
citecolor=acpurple,
58
+
pdfauthor={@jeffrey},
59
+
pdftitle={Leyendo la partitura},
60
+
}
61
+
62
+
% === SECTION FORMATTING ===
63
+
\titleformat{\section}
64
+
{\normalfont\bfseries\normalsize\uppercase}
65
+
{\thesection.}
66
+
{0.5em}
67
+
{}
68
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
69
+
70
+
\titleformat{\subsection}
71
+
{\normalfont\bfseries\small}
72
+
{\thesubsection}
73
+
{0.5em}
74
+
{}
75
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
76
+
77
+
% === HEADER/FOOTER ===
78
+
\pagestyle{fancy}
79
+
\fancyhf{}
80
+
\renewcommand{\headrulewidth}{0pt}
81
+
\fancyhead[C]{\footnotesize\color{draftcolor}\textit{Borrador de trabajo --- no citar}}
82
+
\fancyfoot[C]{\footnotesize\thepage}
83
+
84
+
% === LIST SETTINGS ===
85
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
86
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
87
+
88
+
% === COLUMN SEPARATION ===
89
+
\setlength{\columnsep}{1.8em}
90
+
91
+
% === PARAGRAPH SETTINGS ===
92
+
\setlength{\parindent}{1em}
93
+
\setlength{\parskip}{0.3em}
94
+
95
+
% Hyphenation for narrow two-column layout
96
+
\tolerance=800
97
+
\emergencystretch=1em
98
+
\hyphenpenalty=50
99
+
100
+
\begin{document}
101
+
102
+
% === TITLE ===
103
+
\twocolumn[
104
+
\begin{center}
105
+
{\acbold\LARGE Leyendo la partitura: Un an\'alisis cr\'itico de\\SCORE.md como gobernanza, interfaz y forma creativa\par}
106
+
\vspace{0.4em}
107
+
{\large @jeffrey}\\
108
+
{\small\color{acgray} ORCID: 0009-0007-4460-4913}\\
109
+
{\small\color{acgray} \url{https://aesthetic.computer}}
110
+
\vspace{0.3em}
111
+
112
+
\rule{0.6\textwidth}{0.5pt}
113
+
\vspace{0.3em}
114
+
115
+
\begin{minipage}{0.85\textwidth}
116
+
\small
117
+
\textbf{Resumen.}
118
+
El proyecto Aesthetic Computer reemplaz\'o su README con un documento llamado SCORE.md.
119
+
Este art\'iculo examina qu\'e hizo ese cambio de nombre --- y qu\'e dej\'o sin hacer.
120
+
Bas\'andonos en quince art\'iculos escritos desde la bandeja de investigaci\'on del proyecto,
121
+
leemos la partitura frente a sus propias aspiraciones: como documento de gobernanza,
122
+
como referencia t\'ecnica, como forma creativa. Encontramos que la partitura tiene
123
+
\'exito como met\'afora organizadora pero tiene dificultades como documento --- atrapada
124
+
entre las demandas de agentes de IA, nuevos colaboradores, la propia historia del
125
+
proyecto y la pr\'actica creativa del autor. Identificamos seis tensiones en la
126
+
partitura actual y proponemos un marco de revisi\'on que toma en serio la met\'afora
127
+
musical: una partitura debe decirte c\'omo interpretar, no solo cu\'ales son los instrumentos.
128
+
\end{minipage}
129
+
\vspace{1em}
130
+
\end{center}
131
+
]
132
+
133
+
\section{?`Qu\'e es una partitura?}
134
+
135
+
En m\'usica, una partitura es un conjunto de instrucciones para producir un evento temporal. No es el evento en s\'i --- es el documento que hace el evento reproducible. Una partitura lleva dentro de s\'i una teor\'ia impl\'icita de lo que importa: qu\'e par\'ametros deben especificarse y cu\'ales pueden dejarse al criterio del int\'erprete.
136
+
137
+
Cuando el proyecto Aesthetic Computer renombr\'o su README.md a SCORE.md a principios de marzo de 2026, import\'o todo este marco. El gesto fue deliberado. El proyecto ya entend\'ia sus programas como ``piezas'' en lugar de aplicaciones~\citep{scudder2026pieces}, su interfaz como un instrumento~\citep{scudder2026notepat}, y su notaci\'on gr\'afica (Whistlegraph) como una partitura viral~\citep{scudder2026whistlegraph}. Renombrar el documento de gobernanza fue una manera de decir: esto tambi\'en es algo desde lo cual se interpreta.
138
+
139
+
Pero una partitura implica int\'erpretes. Y la pregunta que este art\'iculo plantea es: ?`qui\'en interpreta desde SCORE.md, y el documento realmente les ayuda?
140
+
141
+
\section{La bandeja y la partitura}
142
+
143
+
La bandeja de investigaci\'on de Aesthetic Computer contiene actualmente diecisiete art\'iculos, organizados en un molino con compilaciones automatizadas, traducciones a cuatro idiomas y un formato de tarjetas para distribuci\'on f\'isica~\citep{scudder2026cards}. Leer a trav\'es de estos art\'iculos revela un proyecto de considerable ambici\'on y coherencia interna --- pero tambi\'en un proyecto cuya autodescripci\'on (la partitura) no ha seguido el ritmo de su autocomprensi\'on (los art\'iculos).
144
+
145
+
Los art\'iculos cuentan una historia que la partitura no cuenta. Consid\'erese:
146
+
147
+
\begin{itemize}
148
+
\item El art\'iculo ``Pieces Not Programs''~\citep{scudder2026pieces} argumenta que la palabra ``pieza'' importa un marco musical donde las obras son de autor\'ia, interpretables e iterables. La partitura menciona piezas pero nunca explica este encuadre.
149
+
\item El art\'iculo sobre notepat~\citep{scudder2026notepat} documenta cinco bucles de retroalimentaci\'on a trav\'es de los cuales una sola pieza atrajo a toda una plataforma a la existencia. La partitura lista notepat como una pieza entre 359.
150
+
\item El art\'iculo sobre sostenibilidad~\citep{scudder2026sustainability} identifica una mediana de 8 a\~nos de brecha entre la creaci\'on de herramientas y la financiaci\'on sostenible, con estudios de caso que terminan en discapacidad y muerte. La partitura tiene insignias de patrocinadores.
151
+
\item El art\'iculo sobre Native OS~\citep{scudder2026os} argumenta que los port\'atiles x86\_64 excedentes a \$50 cada uno son la base material para un instrumento creativo planetario. La partitura lista comandos de compilaci\'on.
152
+
\item El art\'iculo KidLisp Cards~\citep{scudder2026cards} demuestra que la brevedad program\'atica produce un nuevo formato de publicaci\'on --- la tarjeta como partitura ejecutable. La partitura no menciona las tarjetas.
153
+
\end{itemize}
154
+
155
+
En cada caso, el art\'iculo articula una tesis que da significado a lo que la partitura simplemente cataloga. La partitura tiene los hechos pero no el argumento.
156
+
157
+
\section{Seis tensiones}
158
+
159
+
Leer la partitura frente a los art\'iculos revela seis tensiones que una revisi\'on deber\'ia abordar.
160
+
161
+
\subsection{Confusi\'on de audiencia}
162
+
163
+
La partitura abre con un mensaje para agentes de IA (``If you find something interesting\ldots leave a breadcrumb'') y luego cambia inmediatamente a la incorporaci\'on humana (``press the top left of the screen''). La secci\'on ``Front Door'' se dirige a usuarios finales. La secci\'on ``Back Door'' se dirige a desarrolladores. La secci\'on ``Ant Guidance'' se dirige a agentes automatizados. La secci\'on ``Embodiments'' intenta reconciliar los tres.
164
+
165
+
Esto no est\'a mal --- una partitura puede dirigirse a m\'ultiples int\'erpretes. Pero una partitura musical hace legible la parte del int\'erprete de un vistazo. SCORE.md requiere que el lector descubra qu\'e partes son para \'el. Una partitura de director y una parte de viol\'in son documentos diferentes por buenas razones.
166
+
167
+
\subsection{Cat\'alogo vs. argumento}
168
+
169
+
La partitura est\'a organizada como un cat\'alogo: arquitectura, comandos, endpoints, backlogs, consultas de mercado. Este es material de referencia \'util, pero no comunica nada sobre \emph{por qu\'e} existe el proyecto o qu\'e principios gobiernan su desarrollo.
170
+
171
+
Los art\'iculos articulan colectivamente al menos cinco argumentos centrales:
172
+
\begin{enumerate}
173
+
\item El software creativo deber\'ia dise\~narse como un instrumento, no como una herramienta~\citep{scudder2026goodiepal}.
174
+
\item La ``pieza'' es una unidad de cognici\'on creativa, no un programa~\citep{scudder2026pieces}.
175
+
\item La restricci\'on (en dise\~no de lenguajes, en factor de forma) es generativa, no limitante~\citep{scudder2026kidlisp, scudder2026cards}.
176
+
\item Hardware excedente + SO personalizado = acceso a escala planetaria~\citep{scudder2026os, scudder2026plork}.
177
+
\item Las herramientas creativas requieren modelos econ\'omicos que no maten a sus creadores~\citep{scudder2026sustainability}.
178
+
\end{enumerate}
179
+
180
+
Ninguno de estos argumentos aparece en la partitura. Un lector primerizo de SCORE.md sabr\'ia \emph{qu\'e} es Aesthetic Computer (un runtime con piezas, un prompt, algunos servidores) pero no \emph{por qu\'e} existe o en qu\'e cree.
181
+
182
+
\subsection{El problema del backlog}
183
+
184
+
La partitura contiene una secci\'on ``AC Native Backlog'' con siete elementos que mezclan tareas completadas (``Claude native binary'') con funciones aspiracionales (``A/B kernel slots with auto-rollback''). Esto es un artefacto de gesti\'on de proyectos, no una partitura. Comunica estado t\'actico, no direcci\'on estrat\'egica.
185
+
186
+
La filosof\'ia de las hormigas (en \texttt{ants/mindset-and-rules.md}) advierte expl\'icitamente contra el trabajo especulativo: ``IDLE is valid---wandering is the job, not failure.'' Sin embargo, el backlog en la partitura es precisamente trabajo especulativo, presentado como si fuera el plan del proyecto. Las sub-partituras (fedac/native/SCORE.md, papers/SCORE.md) manejan esto mejor separando la gu\'ia de las listas de tareas.
187
+
188
+
\subsection{El bloque del mercado Keeps}
189
+
190
+
La partitura dedica 90 l\'ineas a consultas GraphQL de Tezos/Objkt para verificar las estad\'isticas del mercado de Keeps NFT. Esto es herramienta operativa para un solo colaborador (el autor). Es material de referencia valioso, pero domina la segunda mitad de la partitura y env\'ia una se\~nal no intencionada: que el monitoreo del mercado NFT es una preocupaci\'on central del proyecto, al mismo nivel que la arquitectura y el flujo de trabajo de desarrollo.
191
+
192
+
El art\'iculo ``Dead Ends''~\citep{scudder2026deadends} categoriza expl\'icitamente Tezos/Keeps como un experimento de monetizaci\'on con futuro incierto. La partitura lo presenta como infraestructura establecida.
193
+
194
+
\subsection{Voces ausentes}
195
+
196
+
El art\'iculo ``Network Audit''~\citep{scudder2026audit} revela que AC tiene 2.811 handles registrados, pero solo el 2,1\% escribe KidLisp y el 0,7\% publica piezas. El art\'iculo ``Diversity''~\citep{scudder2026diversity} reconoce que el 80\% de los autores citados son hombres occidentales. El art\'iculo ``Sustainability''~\citep{scudder2026sustainability} documenta el costo humano de la creaci\'on de herramientas sin apoyo.
197
+
198
+
La partitura no se involucra con nada de esto. Presenta n\'umeros de adopci\'on (``2812 registered handles, 265 user-published pieces'') como logro en lugar de como datos que requieren interpretaci\'on. Los art\'iculos son m\'as honestos que la partitura.
199
+
200
+
\subsection{Sub-partituras vs. partitura principal}
201
+
202
+
El proyecto ahora tiene seis archivos SCORE.md: ra\'iz, papers, fedac, fedac/native, opinion y vault. Las sub-partituras son generalmente mejores documentos que la partitura principal. La partitura de papers abre con una ``Mill Mission'' que explica \emph{por qu\'e} existe. La partitura native define ``shipped'' con cinco criterios verificables. La partitura vault mapea la postura de seguridad.
203
+
204
+
La partitura principal, en cambio, intenta ser todo: README, documento de arquitectura, gu\'ia para desarrolladores, runbook operativo y panel de NFT. Las sub-partituras tuvieron \'exito siendo espec\'ificas. La partitura principal tiene dificultades por ser comprehensiva.
205
+
206
+
\section{La met\'afora de la partitura, tomada en serio}
207
+
208
+
Si SCORE.md es una partitura, ?`qu\'e tipo de partitura deber\'ia ser? La analog\'ia musical sugiere varias propiedades:
209
+
210
+
\textbf{Una partitura te dice c\'omo empezar.} La ``Front Door'' de la partitura actual hace esto adecuadamente para usuarios finales, pero no para colaboradores o agentes. Un int\'erprete que toma una partitura necesita saber: ?`qu\'e instrumento toco? ?`D\'onde entro? ?`Cu\'al es el tempo?
211
+
212
+
\textbf{Una partitura tiene partes.} Diferentes int\'erpretes leen diferentes partes. La partitura actual mezcla todas las partes en un solo documento. Las sub-partituras son, en efecto, partes individuales que han sido extra\'idas. La partitura principal deber\'ia ser la partitura del director: una visi\'on general que apunta a las partes, no una uni\'on de todas las partes.
213
+
214
+
\textbf{Una partitura implica una pr\'actica de interpretaci\'on.} Existen convenciones sobre c\'omo leer y ejecutar una partitura que no est\'an escritas en la partitura misma. El documento de filosof\'ia de las hormigas cumple esta funci\'on para agentes de IA. No existe nada equivalente para colaboradores humanos.
215
+
216
+
\textbf{Una partitura puede ser revisada.} Las partituras tienen ediciones. El SCORE.md actual no tiene historial de versiones ni registro de cambios dentro del documento mismo. Se lee como si siempre hubiera sido as\'i, cuando en realidad era un README hasta hace dos semanas.
217
+
218
+
\textbf{Una partitura no es la interpretaci\'on.} La partitura no deber\'ia intentar contener el proyecto. Deber\'ia ser el documento m\'inimo desde el cual el proyecto pueda ser interpretado. Todo lo dem\'as --- backlogs, consultas de mercado, herramientas operativas --- pertenece a partes o ap\'endices.
219
+
220
+
\section{Lo que los art\'iculos saben que la partitura no}
221
+
222
+
El hallazgo m\'as sorprendente al leer los diecisiete art\'iculos frente a la partitura es cu\'anto m\'as rica es la autocomprensi\'on del proyecto en los art\'iculos que en la partitura. Los art\'iculos contienen:
223
+
224
+
\begin{itemize}
225
+
\item Una teor\'ia de la cognici\'on creativa (piezas como ciclos de percepci\'on-acci\'on)
226
+
\item Una econom\'ia pol\'itica de la creaci\'on de herramientas (qui\'en paga, qui\'en se agota, qui\'en muere)
227
+
\item Una filosof\'ia de dise\~no (instrumento-primero, restricci\'on-como-generativa, plano-sobre-profundo)
228
+
\item Un argumento material sobre hardware (port\'atiles excedentes como instrumento planetario)
229
+
\item Una auditor\'ia honesta de fracasos (16 callejones sin salida, 50\% de tasa de contribuci\'on)
230
+
\item Un compromiso con la diversidad de citas con metas espec\'ificas
231
+
\item Una infraestructura de publicaci\'on (el molino) con su propia declaraci\'on de misi\'on
232
+
\end{itemize}
233
+
234
+
La partitura no contiene nada de esto. Es un documento t\'ecnico que resulta llamarse partitura. La revisi\'on deber\'ia convertirlo en una partitura real: un documento que lleve los argumentos del proyecto, no solo su arquitectura.
235
+
236
+
\section{Hacia una partitura revisada}
237
+
238
+
Un SCORE.md revisado deber\'ia:
239
+
240
+
\begin{enumerate}
241
+
\item \textbf{Comenzar con el porqu\'e.} Declarar en qu\'e cree el proyecto y por qu\'e existe, bas\'andose en los argumentos articulados a trav\'es de los art\'iculos. La mill mission en papers/SCORE.md es un modelo para esto.
242
+
\item \textbf{Separar partes de la partitura del director.} Mover detalles operativos (consultas de Keeps, elementos del backlog, referencias de comandos) a sub-partituras o ap\'endices. La partitura principal deber\'ia ser legible en cinco minutos.
243
+
\item \textbf{Nombrar a sus audiencias.} Dirigirse expl\'icitamente a los tres tipos de int\'erpretes (usuarios finales, colaboradores humanos, agentes de IA) con puntos de entrada claros para cada uno.
244
+
\item \textbf{Incluir los n\'umeros honestos.} Presentar datos de adopci\'on con interpretaci\'on, no solo como insignias. El 2,1\% de autor\'ia en KidLisp es un hecho que significa algo --- la partitura deber\'ia decir qu\'e.
245
+
\item \textbf{Referenciar los art\'iculos.} La bandeja existe. La partitura deber\'ia se\~nalarla como la autocomprensi\'on extendida del proyecto, no ignorarla.
246
+
\item \textbf{Reconocer su propia historia.} Notar que este documento era un README hasta marzo de 2026, y que el cambio de nombre fue en s\'i mismo un acto creativo con consecuencias.
247
+
\item \textbf{Ser m\'as breve.} La partitura actual tiene 361 l\'ineas. Una partitura que se tome en serio deber\'ia estar m\'as cerca de la longitud de una pieza que cabe en una tarjeta.
248
+
\end{enumerate}
249
+
250
+
\section{Conclusi\'on}
251
+
252
+
SCORE.md es un buen nombre para lo que el proyecto Aesthetic Computer necesita: un documento que haga el proyecto interpretable. Pero la partitura actual es un cat\'alogo, no una composici\'on. Lista lo que el proyecto contiene sin argumentar lo que significa. Los art\'iculos en la bandeja de investigaci\'on --- escritos en las mismas semanas que la partitura --- contienen los argumentos, las evaluaciones honestas y los marcos creativos que la partitura carece.
253
+
254
+
La revisi\'on m\'as productiva no a\~nadir\'ia a la partitura sino que restar\'ia de ella, moviendo detalles operativos a sub-partituras y reemplaz\'andolos con las creencias reales del proyecto. Las sub-partituras (papers, native, vault) ya demuestran este enfoque. La partitura principal deber\'ia aprender de sus propias partes.
255
+
256
+
Una partitura no es una descripci\'on de una orquesta. Es la notaci\'on m\'inima requerida para producir m\'usica. SCORE.md deber\'ia aspirar a la misma econom\'ia.
257
+
258
+
\bibliographystyle{plainnat}
259
+
\bibliography{references}
260
+
261
+
\end{document}
+260
papers/arxiv-score-analysis/score-analysis-zh.tex
+260
papers/arxiv-score-analysis/score-analysis-zh.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\usepackage{xeCJK}
11
+
\setCJKmainfont{Droid Sans Fallback}
12
+
\setmainfont{Latin Modern Roman}
13
+
\setsansfont{Latin Modern Sans}
14
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
15
+
\newfontfamily\acbold{ywft-processing-bold}[
16
+
Path=../../system/public/type/webfonts/,
17
+
Extension=.ttf
18
+
]
19
+
\newfontfamily\aclight{ywft-processing-light}[
20
+
Path=../../system/public/type/webfonts/,
21
+
Extension=.ttf
22
+
]
23
+
24
+
% === PACKAGES ===
25
+
\usepackage{xcolor}
26
+
\usepackage{titlesec}
27
+
\usepackage{enumitem}
28
+
\usepackage{booktabs}
29
+
\usepackage{tabularx}
30
+
\usepackage{fancyhdr}
31
+
\usepackage{hyperref}
32
+
\usepackage{graphicx}
33
+
\usepackage{ragged2e}
34
+
\usepackage{microtype}
35
+
\usepackage{natbib}
36
+
\usepackage[colorspec=0.92]{draftwatermark}
37
+
38
+
% === COLORS ===
39
+
\definecolor{acpink}{RGB}{180,72,135}
40
+
\definecolor{acpurple}{RGB}{120,80,180}
41
+
\definecolor{acdark}{RGB}{64,56,74}
42
+
\definecolor{acgray}{RGB}{119,119,119}
43
+
\definecolor{draftcolor}{RGB}{180,72,135}
44
+
45
+
% === DRAFT WATERMARK ===
46
+
\DraftwatermarkOptions{
47
+
text=WORKING DRAFT,
48
+
fontsize=3cm,
49
+
color=draftcolor!18,
50
+
angle=45,
51
+
pos={0.5\paperwidth, 0.5\paperheight}
52
+
}
53
+
54
+
% === HYPERREF ===
55
+
\hypersetup{
56
+
colorlinks=true,
57
+
linkcolor=acpurple,
58
+
urlcolor=acpurple,
59
+
citecolor=acpurple,
60
+
pdfauthor={@jeffrey},
61
+
pdftitle={阅读总谱},
62
+
}
63
+
64
+
% === SECTION FORMATTING ===
65
+
\titleformat{\section}
66
+
{\normalfont\bfseries\normalsize\uppercase}
67
+
{\thesection.}
68
+
{0.5em}
69
+
{}
70
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
71
+
72
+
\titleformat{\subsection}
73
+
{\normalfont\bfseries\small}
74
+
{\thesubsection}
75
+
{0.5em}
76
+
{}
77
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
78
+
79
+
% === HEADER/FOOTER ===
80
+
\pagestyle{fancy}
81
+
\fancyhf{}
82
+
\renewcommand{\headrulewidth}{0pt}
83
+
\fancyhead[C]{\footnotesize\color{draftcolor}\textit{工作草稿 --- 请勿引用}}
84
+
\fancyfoot[C]{\footnotesize\thepage}
85
+
86
+
% === LIST SETTINGS ===
87
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
88
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
89
+
90
+
% === COLUMN SEPARATION ===
91
+
\setlength{\columnsep}{1.8em}
92
+
93
+
% === PARAGRAPH SETTINGS ===
94
+
\setlength{\parindent}{1em}
95
+
\setlength{\parskip}{0.3em}
96
+
97
+
% Hyphenation for narrow two-column layout
98
+
\tolerance=800
99
+
\emergencystretch=1em
100
+
\hyphenpenalty=50
101
+
102
+
\begin{document}
103
+
104
+
% === TITLE ===
105
+
\twocolumn[
106
+
\begin{center}
107
+
{\acbold\LARGE 阅读总谱：对SCORE.md作为治理、界面\\与创作形式的批判性分析\par}
108
+
\vspace{0.4em}
109
+
{\large @jeffrey}\\
110
+
{\small\color{acgray} ORCID: 0009-0007-4460-4913}\\
111
+
{\small\color{acgray} \url{https://aesthetic.computer}}
112
+
\vspace{0.3em}
113
+
114
+
\rule{0.6\textwidth}{0.5pt}
115
+
\vspace{0.3em}
116
+
117
+
\begin{minipage}{0.85\textwidth}
118
+
\small
119
+
\textbf{摘要。}
120
+
Aesthetic Computer项目用一个名为SCORE.md的文档取代了其README。
121
+
本文考察了这次更名所做的事情——以及它留下的未竟之事。
122
+
基于从项目研究盘中撰写的十五篇论文，我们将总谱与其自身的抱负进行对照阅读：
123
+
作为治理文档、作为技术参考、作为创作形式。我们发现总谱作为组织性隐喻是成功的，
124
+
但作为文档却陷入困境——被AI代理、新贡献者、项目自身历史和作者创作实践的
125
+
多重需求所裹挟。我们识别了当前总谱中的六种张力，并提出一个认真对待音乐隐喻的
126
+
修订框架：总谱应当告诉你如何演奏，而不仅仅是告诉你乐器有哪些。
127
+
\end{minipage}
128
+
\vspace{1em}
129
+
\end{center}
130
+
]
131
+
132
+
\section{什么是总谱？}
133
+
134
+
在音乐中，总谱是一组用于产生时间事件的指令。它不是事件本身——它是使事件可复现的文档。总谱内含一种关于什么重要的隐性理论：哪些参数必须明确指定，哪些可以留给演奏者判断。
135
+
136
+
当Aesthetic Computer项目在2026年3月初将其README.md更名为SCORE.md时，它导入了整个框架。这一举动是刻意的。项目已经将其程序理解为"作品"而非应用程序~\citep{scudder2026pieces}，将其界面理解为乐器~\citep{scudder2026notepat}，将其图形记谱法（Whistlegraph）理解为一种病毒式传播的总谱~\citep{scudder2026whistlegraph}。重命名治理文档是一种表达：这也是需要据以演奏的东西。
137
+
138
+
但总谱意味着演奏者。本文提出的问题是：谁在从SCORE.md演奏，这份文档真的帮助了他们吗？
139
+
140
+
\section{研究盘与总谱}
141
+
142
+
Aesthetic Computer的研究盘目前包含十七篇论文，组织在一个具有自动化构建、四种语言翻译和用于实体分发的卡片格式的论文工坊中~\citep{scudder2026cards}。通读这些论文揭示了一个具有相当雄心和内部一致性的项目——但也是一个自我描述（总谱）未能跟上自我理解（论文）的项目。
143
+
144
+
论文讲述了总谱未曾讲述的故事。考虑以下情况：
145
+
146
+
\begin{itemize}
147
+
\item "Pieces Not Programs"论文~\citep{scudder2026pieces}论证了"作品"一词引入了一个音乐框架，其中作品是有作者的、可演奏的、可迭代的。总谱提到了作品，但从未解释这一框架。
148
+
\item notepat论文~\citep{scudder2026notepat}记录了五个反馈循环，通过这些循环，一个单独的作品将整个平台拉入存在。总谱将notepat列为359个作品中的一个。
149
+
\item 可持续性论文~\citep{scudder2026sustainability}确认了工具创建与可持续资金之间存在中位数为8年的差距，案例研究以残疾和死亡告终。总谱有赞助商徽章。
150
+
\item Native OS论文~\citep{scudder2026os}论证了每台50美元的剩余x86\_64笔记本电脑是全球性创意乐器的物质基础。总谱列出了构建命令。
151
+
\item KidLisp Cards论文~\citep{scudder2026cards}证明了程序的简洁性产生了一种新的出版格式——卡片作为可执行的总谱。总谱没有提到卡片。
152
+
\end{itemize}
153
+
154
+
在每种情况下，论文阐述了一个赋予总谱仅仅编目之物以意义的论点。总谱有事实，但没有论证。
155
+
156
+
\section{六种张力}
157
+
158
+
将总谱与论文对照阅读揭示了修订应当解决的六种张力。
159
+
160
+
\subsection{受众困惑}
161
+
162
+
总谱以一条给AI代理的消息开头（"If you find something interesting\ldots leave a breadcrumb"），然后立即切换到人类引导（"press the top left of the screen"）。"Front Door"部分面向最终用户。"Back Door"部分面向开发者。"Ant Guidance"部分面向自动化代理。"Embodiments"部分试图调和这三者。
163
+
164
+
这并没有错——总谱可以面向多个演奏者。但音乐总谱让演奏者的声部一目了然。SCORE.md要求读者自己弄清楚哪些部分是给他们的。指挥总谱和小提琴声部是不同的文档，这是有充分理由的。
165
+
166
+
\subsection{编目与论证}
167
+
168
+
总谱被组织为一个目录：架构、命令、端点、待办事项、市场查询。这是有用的参考材料，但它没有传达关于项目\emph{为什么}存在或什么原则支配其发展的任何信息。
169
+
170
+
论文共同阐述了至少五个核心论点：
171
+
\begin{enumerate}
172
+
\item 创意软件应被设计为乐器，而非工具~\citep{scudder2026goodiepal}。
173
+
\item "作品"是创意认知的单位，而非程序~\citep{scudder2026pieces}。
174
+
\item 约束（在语言设计中、在形式因素中）是生成性的，而非限制性的~\citep{scudder2026kidlisp, scudder2026cards}。
175
+
\item 剩余硬件 + 定制操作系统 = 全球性访问~\citep{scudder2026os, scudder2026plork}。
176
+
\item 创意工具需要不会杀死其创造者的经济模式~\citep{scudder2026sustainability}。
177
+
\end{enumerate}
178
+
179
+
这些论点均未出现在总谱中。SCORE.md的初次读者会知道Aesthetic Computer\emph{是什么}（一个有作品、有提示符、有一些服务器的运行时），但不知道它\emph{为什么}存在或它相信什么。
180
+
181
+
\subsection{待办事项问题}
182
+
183
+
总谱包含一个"AC Native Backlog"部分，其中七个项目混合了已完成的任务（"Claude native binary"）和理想中的功能（"A/B kernel slots with auto-rollback"）。这是项目管理工件，不是总谱。它传达的是战术状态，而非战略方向。
184
+
185
+
蚂蚁哲学（在\texttt{ants/mindset-and-rules.md}中）明确警告不要进行投机性工作："IDLE is valid---wandering is the job, not failure。"然而总谱中的待办事项恰恰是投机性工作，被呈现为仿佛是项目的计划。子总谱（fedac/native/SCORE.md、papers/SCORE.md）通过将指导与任务列表分离来更好地处理这个问题。
186
+
187
+
\subsection{Keeps市场区块}
188
+
189
+
总谱用90行来展示Tezos/Objkt GraphQL查询，用于检查Keeps NFT市场统计数据。这是一个贡献者（作者）的操作工具。它是有价值的参考材料，但它主导了总谱的后半部分，并发出了一个无意的信号：NFT市场监控是项目的核心关注点，与架构和开发工作流同等重要。
190
+
191
+
"Dead Ends"论文~\citep{scudder2026deadends}明确将Tezos/Keeps归类为未来不确定的货币化实验。总谱将其呈现为已建立的基础设施。
192
+
193
+
\subsection{缺失的声音}
194
+
195
+
"Network Audit"论文~\citep{scudder2026audit}揭示AC有2,811个注册用户名，但只有2.1\%编写KidLisp，0.7\%发布作品。"Diversity"论文~\citep{scudder2026diversity}承认80\%的被引作者是西方男性。"Sustainability"论文~\citep{scudder2026sustainability}记录了无支持的工具制作的人力成本。
196
+
197
+
总谱没有涉及任何这些问题。它将采用数据（"2812 registered handles, 265 user-published pieces"）呈现为成就，而非需要解读的数据。论文比总谱更诚实。
198
+
199
+
\subsection{子总谱与主总谱}
200
+
201
+
项目现在有六个SCORE.md文件：根目录、papers、fedac、fedac/native、opinion和vault。子总谱通常是比主总谱更好的文档。papers总谱以"Mill Mission"开头，解释它\emph{为什么}存在。native总谱用五个可验证的标准定义"shipped"。vault总谱映射了安全态势。
202
+
203
+
相比之下，主总谱试图成为一切：README、架构文档、开发者指南、操作手册和NFT仪表板。子总谱因具体而成功。主总谱因全面而挣扎。
204
+
205
+
\section{认真对待总谱隐喻}
206
+
207
+
如果SCORE.md是一份总谱，它应该是什么样的总谱？音乐类比暗示了几个属性：
208
+
209
+
\textbf{总谱告诉你如何开始。}当前总谱的"Front Door"对最终用户做到了这一点，但对贡献者或代理则没有。拿起总谱的演奏者需要知道：我演奏什么乐器？我从哪里进入？节拍是什么？
210
+
211
+
\textbf{总谱有声部。}不同的演奏者阅读不同的声部。当前总谱将所有声部混合在一个文档中。子总谱实际上是已被提取的单独声部。主总谱应该是指挥总谱：指向声部的概述，而非所有声部的合集。
212
+
213
+
\textbf{总谱意味着一种演奏实践。}关于如何阅读和执行总谱的惯例并未写在总谱本身中。蚂蚁思维文档为AI代理提供了这一功能。对于人类贡献者，没有等效的东西存在。
214
+
215
+
\textbf{总谱可以修订。}总谱有版本。当前的SCORE.md在文档本身中没有版本历史或变更日志。它读起来好像一直如此，而实际上两周前它还是一个README。
216
+
217
+
\textbf{总谱不是演奏本身。}总谱不应试图包含整个项目。它应该是项目据以演奏的最小文档。其他一切——待办事项、市场查询、操作工具——属于声部或附录。
218
+
219
+
\section{论文知道而总谱不知道的}
220
+
221
+
将所有十七篇论文与总谱对照阅读，最引人注目的发现是项目在论文中的自我理解比在总谱中丰富得多。论文包含：
222
+
223
+
\begin{itemize}
224
+
\item 一种创意认知理论（作品作为感知-行动循环）
225
+
\item 一种工具制作的政治经济学（谁付费、谁耗尽、谁死去）
226
+
\item 一种设计哲学（乐器优先、约束即生成、扁平优于纵深）
227
+
\item 一个关于硬件的物质论证（剩余笔记本电脑作为全球性乐器）
228
+
\item 一次对失败的诚实审计（16条死胡同、50\%贡献率）
229
+
\item 一个具有具体目标的引用多样性承诺
230
+
\item 一个具有自身使命宣言的出版基础设施（工坊）
231
+
\end{itemize}
232
+
233
+
总谱不包含任何这些内容。它是一份碰巧被称为总谱的技术文档。修订应使其成为真正的总谱：一份承载项目论证而非仅承载其架构的文档。
234
+
235
+
\section{迈向修订后的总谱}
236
+
237
+
修订后的SCORE.md应当：
238
+
239
+
\begin{enumerate}
240
+
\item \textbf{以"为什么"开头。}陈述项目相信什么以及它为什么存在，借鉴跨论文阐述的论点。papers/SCORE.md中的mill mission是这方面的范例。
241
+
\item \textbf{将声部与指挥总谱分离。}将操作细节（Keeps查询、待办事项、命令参考）移至子总谱或附录。主总谱应能在五分钟内读完。
242
+
\item \textbf{命名其受众。}明确面向三种演奏者类型（最终用户、人类贡献者、AI代理），为每种类型提供清晰的入口点。
243
+
\item \textbf{包含诚实的数字。}呈现带有解读的采用数据，而不仅仅是徽章。2.1\%的KidLisp创作率是一个有意义的事实——总谱应说明其含义。
244
+
\item \textbf{引用论文。}研究盘存在。总谱应将其指向为项目的扩展自我理解，而非忽视它。
245
+
\item \textbf{承认自身历史。}指出这份文档直到2026年3月还是一个README，且更名本身是一个有后果的创作行为。
246
+
\item \textbf{更简短。}当前总谱有361行。一份认真对待自己的总谱应更接近于一张卡片上一个作品的长度。
247
+
\end{enumerate}
248
+
249
+
\section{结论}
250
+
251
+
SCORE.md对于Aesthetic Computer项目所需要的东西来说是一个好名字：一份使项目可被演奏的文档。但当前的总谱是一份目录，而非一部作品。它列出了项目包含什么，却没有论证它意味着什么。研究盘上的论文——与总谱在同几周内撰写——包含了总谱所缺乏的论证、诚实的评估和创作框架。
252
+
253
+
最有成效的修订不是向总谱添加内容，而是从中删减，将操作细节移至子总谱，并用项目的实际信念取而代之。子总谱（papers、native、vault）已经展示了这种方法。主总谱应向自己的声部学习。
254
+
255
+
总谱不是对管弦乐队的描述。它是产生音乐所需的最小记谱。SCORE.md应追求同样的简约。
256
+
257
+
\bibliographystyle{plainnat}
258
+
\bibliography{references}
259
+
260
+
\end{document}