pippo.com / knowledge

Sharing Knowledge

Whenever I have acquired enough expertise to truly understand a system, sooner or later I have felt the need to produce something that would allow other people to understand it, use it, or build on top of it.

In 1992 it was a guide to the Internet. Later came FAQs, articles and technical documentation. Then infrastructure, educational material, experimental results, frameworks, datasets and code. The tools changed. The underlying movement remained remarkably stable.

understand deeply → synthesise → share knowledge → build in the open

Before the network

This mechanism predates the Internet. As a child I took apart furniture, radios and broken televisions because I needed to understand how they were built and how their parts worked together. At four or five, I knew enough about the things I had explored that when my mother found a stray screw, she would often ask me where it belonged.

That story is not the centre of this page, but it explains the method: before I can simplify a system, I need to understand it deeply enough to separate what is essential from what is not. Once that internal model exists, explaining and sharing tends to become the next step.

A note, not a biography
This page does not reconstruct my career. It collects what I produced and made public as I acquired enough competence to feel I could explain it, document it, or make it reusable.

The network as a culture of knowledge

When I encountered the Internet in the early 1990s, I found an environment built almost exactly around this mechanism. Technical documentation, mailing lists, newsgroups, FAQs, software and source code circulated because someone had decided to make what they had learned public.

Being largely self-taught, that shared knowledge did more than help me learn: it contributed to building my professional competence. Sharing what I eventually understood became a way of giving something back to the same network from which I had received so much.

The artefacts: what knowledge produced

1992–1997

GUIDE · HYPERTEXT

Guide to the Internet and Virtual Reality

Internet · cyberspace · protocols · services · online communities

The first public expression of this impulse was a guide created when the Internet was still difficult to access and even harder to explain. Version 0.1, written in 1992, actually began for a very simple reason: I wanted to explain to my friend Ludovica what it meant to organise information as hypertext and give her some basic grounding in the Internet. The Web itself had only just appeared: the first public CERN website dated from the previous year. From that personal experiment, the guide grew into an attempt to reassemble fragmented, mostly technical and usually English-language documentation into an understandable structure: not only which commands to type, but what the Internet was, how it worked and why it could become something important.

OUTPUT → more than 300 pages, freely distributed as hypertext and now preserved in the historical pippo.com archive. It was 1992, nine years before Wikipedia was launched: not the same thing, of course, but already driven by the same idea that attracted me to the network, that knowledge could be organised, linked and made directly accessible to other people.

→ explore the guide

1993–2000

COMMUNITIES · FAQS · TECHNICAL WRITING

Turning recurring questions into reusable knowledge

Usenet · Linux · Unix · Internet · security · computer magazines

Usenet worked as a vast distributed memory: someone asked a question, others answered, answers were corrected, accumulated and eventually turned into FAQs. For several years I maintained reference Italian Linux FAQs, participated in technical communities and produced guides and documents on Unix, the Internet, security and hacker culture. During the same period I also began writing professionally as a Technical Editor and contributor to Italian computer magazines.

OUTPUT → FAQs, guides, technical documentation and articles that made knowledge transferable because they were grounded in actually using the technologies being described.

→ historical documents → 1990s articles → Linux FAQs and guides

1995–1997

INFRASTRUCTURE · SYSTEM ADMINISTRATION

Internet Force: from understanding systems to running them

SunOS · TCP/IP · DNS · mail · routing · Cisco · firewalls · dial-up

By the mid-1990s that knowledge stopped being only something to study and explain. With Internet Force, one of the first commercial Internet Service Providers in Italy, it became infrastructure to design, build and operate. Internet Force was launched in 1995 with what was, for the time, an unusually ambitious approach: rather than reproducing the still frequently improvised model of early local access services, we deliberately tried to adopt the best practices of US Internet providers. Sun servers, Cisco routers, Check Point firewalls, rack-organised infrastructure and connectivity towards US backbones were part of that design choice. For me, this meant being immersed in an unusually rich technical environment in which Unix, TCP/IP, DNS, email, routing, security, dial-up access, hardware and geographic connectivity had to be understood as parts of one system. In the Italian market of 1995, these skills were still relatively rare and concentrated mainly in universities, research centres and the first Internet operators. In practice, my role was system and network administration at a time when those roles were still becoming recognisable professions.

OUTPUT → Internet Force was also an extraordinary learning accelerator. Working on infrastructure built with that level of ambition forced me to develop end-to-end technical knowledge that directly shaped the next stages of my career: infrastructure, engineering, technology risk, governance and cybersecurity.

→ historical repository → interactive documentation

2026

OPEN TECHNICAL ARCHIVE

Returning to Internet Force to explain how it worked

technical archaeology · configurations · procedures · DNS · mail · routing

Thirty years later I returned to that same infrastructure. This time, not to administer it or bring it back into production, but to turn what I had once needed to learn in order to make it work into knowledge that could be shared. The repository preserves configurations, documentation, source code, operating procedures and original material, while adding learning sections that reconstruct the context: how DNS and mail worked, how networks exchanged traffic, how servers and access systems were organised, and how Internet infrastructure was administered before the cloud.

OUTPUT → the historical material shows what we did; the contemporary documentation tries to explain how and why it worked.

→ explore the repository → learning paths

2012–2018

EDTECH · EVIDENCE

EdiTouch: sharing what we learn by building

inclusive design · field experimentation · methodology · results

With EdiTouch, building the product was not enough. We needed to know whether it actually worked. That meant working with students, families, teachers, specialists and researchers, running a field trial, and documenting methodology and outcomes. EdiTouch was not an open-source project, but it strengthened a principle that still matters to me: a product can remain proprietary; the knowledge produced by building and evaluating it does not necessarily have to.

OUTPUT → product, field trial, presentations, methodology and evidence now preserved in a public historical archive.

→ EdiTouch archive → materials and publications

2026 →

OPEN RESEARCH · CODE · DATA

Making the process verifiable, not just the result

L×M×C · SLEF · datasets · benchmarks · specifications · reference implementations

In my recent work on educational AI, the same principle becomes even more explicit. Publishing a conclusion is not enough if others cannot see how it was reached. Frameworks, experimental environments, datasets, benchmarks and reference implementations are therefore published with persistent identifiers and, where possible, reusable code and data. The goal is not merely to make something free, but to make it inspectable, criticisable and reproducible.

OUTPUT → L×M×C, SLEF and other research artefacts open to verification, criticism and reuse.

→ L×M×C → SLEF → research and publications

1990s → today

WRITING · PUBLIC EXPLANATION

Writing to understand, writing to share

technical magazines · articles · AI · education · governance · human systems

In recent years I have returned continuously to an activity I first pursued in the 1990s: writing for publications aimed at a broader audience. The subjects have changed; the method has not changed very much. First, understand a problem well enough not to reduce it to a slogan. Then try to give it back in a form that remains intelligible to people who did not follow the entire path required to get there.

OUTPUT → from technical articles in the 1990s to current writing on AI, education, cognitive and relational safety, governance and technology.

→ Writing & Publications

Open source as a consequence

Open source has never meant only attaching a licence to a repository for me. It is one form of a broader principle: knowledge becomes more useful when other people can access it, understand it, verify it and build on it.

Not everything should be public. Intellectual property, sensitive data, security and responsibility all matter. But when what we are producing is knowledge, the ability to see how that knowledge was built becomes part of its value.

The debt to the network

Much of what I know, I learned because someone before me decided to make an explanation, a FAQ, a document, some code, or simply a good newsgroup answer public.

Continuing to document and share what I learn has never felt particularly extraordinary. It has always felt, simply, like the way the network is supposed to work.