Raspberry Pi als Tor Relay

Hinweise zur Installation von Tor auf einem Raspberry Pi.

  • Raspberry Pi OS via Raspberry Pi Imager auf die micro SD Karte schreiben (SSH aktivieren!)
  • Ethernetverbindung und Stromversorgung herstellen
  • Via SSH einloggen
  • Pakete aktualisieren:
    apt-get install update
    apt-get install upgrade
  • Tor installieren
    apt-get install tor
  • /etc/tor/torrc:

SocksPort 0
Log notice file /var/log/tor/notices.log
RunAsDaemon 1
DataDirectory /var/lib/tor
ORPort 9001 IPv4Only
ExitPolicy reject *:*

  • Auf dem Router Port 9001 öffnen
  • systemctl restart tor@default.service
  • Auf einem schwachbrüstiger Raspberry Pi kann tor von systemd beendet werden, weil tor nicht innerhalb von 5min einen erfolgreichen Start signalisierte (zu erkennen in den Logs, wenn inmitten des Bootstrapping das Programm neu gestartet wird). Lösung: Erhöhung der TimeoutStartSec (z.B. von 300 auf 600) in /lib/systemd/system/tor@default.service.

Unix Pipes

Doug McIlroy beschreibt Pipes, lange bevor Unix das Licht der Welt erblickte.

            Summary--what's most important.
    To put my strongest concerns into a nutshell:
1. We should have some ways of coupling programs like
garden hose--screw in another segment when it becomes when
it becomes necessary to massage data in another way.
This is the way of IO also.
2. Our loader should be able to do link-loading and
controlled establishment.
3. Our library filing scheme should allow for rather
general indexing, responsibility, generations, data path
4. It should be possible to get private system components
(all routines are system components) for buggering around with.

                                                M. D. McIlroy
                                                October 11, 1964 

Goodbye Hostpoint, Hello Hetzner

Seit Anbeginn anno 2006 war dieser Blog bei Hostpoint im schönen Rapperswil gehostet. Das billigste Webhosting Angebot beläuft sich bei diesem Anbieter unterdessen auf CHF 12.90/Monat (CHF 154.80/Jahr). Bisschen teuer für das bescheidene Datenaufkommen, der dieser Blog verursacht.

Kann man heutzutage bei gleicher Qualität weitaus billiger haben, zum Beispiel bei Hetzner für rund 25 Stutz pro Jahr (EUR 1.8/Monat). Deshalb kurzerhand Umzug. Auch gleich noch alles aktualisiert. Bisher nichts zu Beklagen. Daumen hoch.

Farewell from Rusty Russell (kernel.org)

To my fellow maintainers: stay harsh on code and don’t be afraid to say “No” or “Why?”; there really are more bad ideas than good ones, and complexity is such a bright candle for us hacker-moths. But be gentle, kind and forgiving of your peers: respect from people you respect is really the only reward that sticks.

Farewell all, and I look forward to crossing your paths again!


commit: ed875ea1fcc6c34ea232610c3041d0978e327bbe

A Declaration of the Independence of Cyberspace

by John Perry Barlow, RIP

Governments of the Industrial World, you weary giants of flesh and steel, I come from Cyberspace, the new home of Mind. On behalf of the future, I ask you of the past to leave us alone. You are not welcome among us. You have no sovereignty where we gather.

We have no elected government, nor are we likely to have one, so I address you with no greater authority than that with which liberty itself always speaks. I declare the global social space we are building to be naturally independent of the tyrannies you seek to impose on us. You have no moral right to rule us nor do you possess any methods of enforcement we have true reason to fear.

Governments derive their just powers from the consent of the governed. You have neither solicited nor received ours. We did not invite you. You do not know us, nor do you know our world. Cyberspace does not lie within your borders. Do not think that you can build it, as though it were a public construction project. You cannot. It is an act of nature and it grows itself through our collective actions.

You have not engaged in our great and gathering conversation, nor did you create the wealth of our marketplaces. You do not know our culture, our ethics, or the unwritten codes that already provide our society more order than could be obtained by any of your impositions.

You claim there are problems among us that you need to solve. You use this claim as an excuse to invade our precincts. Many of these problems don’t exist. Where there are real conflicts, where there are wrongs, we will identify them and address them by our means. We are forming our own Social Contract. This governance will arise according to the conditions of our world, not yours. Our world is different.

Cyberspace consists of transactions, relationships, and thought itself, arrayed like a standing wave in the web of our communications. Ours is a world that is both everywhere and nowhere, but it is not where bodies live.

We are creating a world that all may enter without privilege or prejudice accorded by race, economic power, military force, or station of birth.

We are creating a world where anyone, anywhere may express his or her beliefs, no matter how singular, without fear of being coerced into silence or conformity.

Your legal concepts of property, expression, identity, movement, and context do not apply to us. They are all based on matter, and there is no matter here.

Our identities have no bodies, so, unlike you, we cannot obtain order by physical coercion. We believe that from ethics, enlightened self-interest, and the commonweal, our governance will emerge. Our identities may be distributed across many of your jurisdictions. The only law that all our constituent cultures would generally recognize is the Golden Rule. We hope we will be able to build our particular solutions on that basis. But we cannot accept the solutions you are attempting to impose.

In the United States, you have today created a law, the Telecommunications Reform Act, which repudiates your own Constitution and insults the dreams of Jefferson, Washington, Mill, Madison, DeToqueville, and Brandeis. These dreams must now be born anew in us.

You are terrified of your own children, since they are natives in a world where you will always be immigrants. Because you fear them, you entrust your bureaucracies with the parental responsibilities you are too cowardly to confront yourselves. In our world, all the sentiments and expressions of humanity, from the debasing to the angelic, are parts of a seamless whole, the global conversation of bits. We cannot separate the air that chokes from the air upon which wings beat.

In China, Germany, France, Russia, Singapore, Italy and the United States, you are trying to ward off the virus of liberty by erecting guard posts at the frontiers of Cyberspace. These may keep out the contagion for a small time, but they will not work in a world that will soon be blanketed in bit-bearing media.

Your increasingly obsolete information industries would perpetuate themselves by proposing laws, in America and elsewhere, that claim to own speech itself throughout the world. These laws would declare ideas to be another industrial product, no more noble than pig iron. In our world, whatever the human mind may create can be reproduced and distributed infinitely at no cost. The global conveyance of thought no longer requires your factories to accomplish.

These increasingly hostile and colonial measures place us in the same position as those previous lovers of freedom and self-determination who had to reject the authorities of distant, uninformed powers. We must declare our virtual selves immune to your sovereignty, even as we continue to consent to your rule over our bodies. We will spread ourselves across the Planet so that no one can arrest our thoughts.

We will create a civilization of the Mind in Cyberspace. May it be more humane and fair than the world your governments have made before.

Davos, Switzerland
February 8, 1996

Zen and the Art of Making

Vor einigen Wochen habe ich einen bemerkenswerten Artikel von Phillip Torrone gelesen, einem der Väter der DIY- und Open-Hardware-Bewegung.

Hier ist der Link.

Um die Wichtigkeit des Artikels zu betonen, sei er hier nochmals in voller Länge abgedruckt:


This week for my bi-weekly soapbox column, I thought I’d share some of my notes I’ve jotted down recently about making things, working with and supporting beginners. Lately, I’ve been thinking about how much fun it is when you’re a beginner at something as opposed to being an “expert.”

At some point, we all become experts at something. I really want to avoid being an expert in some things, only so I can continually look forward to learning more without the overhead of being an expert. Being an expert means your journey is somewhat over. I was going to call this column the “expert problem” but I hope you enjoy this semi stream of conscience collected over the last few weeks. Be sure to post up in the comments about your experiences with learning a new skill and how you keep motivated to keep learning more.

I thought I’d start with a favorite quote:

Begin at the beginning and go on till you come to the end; then stop.
— Alice in Wonderland

When you start out making something, you usually don’t end up where you thought you would. It’s usually some place better. A beginner can imagine more than an expert because a beginner doesn’t see constraints yet. Kids are the same way — they approach things with an open mind because they haven’t been told “you can’t do that” yet. Beginners aren’t billing someone for their time — it’s not a job, and time doesn’t matter. Beginners (and kids) usually have more time than money. Beginners aren’t collecting trophies (yet) — they’re exploring. If you don’t know the boundaries of something, for a brief time your ideas are boundless.

Maybe becoming experts in things is just in our destiny — we all specialize, growing old is unavoidable — but retaining things from our childhood is possible; it’s just a struggle sometimes. This is why a lot of us have safe places, like a workshop or an electronics bench, where we can protect them. If you’re a self-proclaimed expert in something, you’ll end up defending your work from other experts. The internet is an amplifier of this phenomenon. I think it’s important to have places where beginners can help each other, and the experts are there to not only share information, but share how they discovered things (sometimes the how is more important than the what). The best experts I know open the door, but you enter yourself.

Experts stay still; beginners are constantly moving. An expert can point out the difficulty in every project, while the beginner can only see possibilities (and later many ways to make mistakes). The reward for beginners is not the stuff they make, it’s the person they become because of the stuff they make and share. Beginners need to practice a lot; experts need to talk more than practice usually. Beginners do very simple things before they understand what they are doing, but they are simplistic. Experts struggle to make things simple because they want to put everything they know in something, to demonstrate their expertise.

Beginners share their mistakes; experts hide them. Knowledge is one of the few things that doesn’t diminish the more you share it. I probably read about 1,000 messages a day across mailing lists, forums, customer support emails, Google+, Twitter, and more. Beginners can celebrate failure while experts rarely admit it. For a beginner, all the obstacles, failures, and challenges are the path ahead. Beginners usually do not have any fear; they just make things — maybe it doesn’t work out, maybe it does — but they don’t have the same risk aversion experts tend to have.

Beginners get the satisfaction of solving many small problems that are wonderful milestones to keep motivated. Experts build bigger and for longer, so when something goes wrong it can really crash hard. The little problems a beginner solves are like weeds in a garden: you find them and use them for mulch — they’re fuel. Eventually you might have a manicured estate, but I think the small garden is more fun and approachable. More people can participate because the fence is lower, or not there at all.

Once you get enough experts together, that’s when the in-fighting usually starts. Even The Beatles fought with each other about who was the best. Experts start to see the tiniest differences between each other and (usually) fork their efforts. It might be over-phrasing or titles of efforts, what licenses they use or don’t use, who is more pure than someone else. Beginners don’t know enough to care about these things yet — it’s the freedom beginners enjoy, even if it’s just for a short while. Beginners tend to see what they have in common with each other; experts can only see the differences. Many experts don’t want to share their knowledge, and beginners don’t have anything to share yet other than encouragement and enthusiasm for other beginners. Experts like to defeat each other, often publicly; beginners conquer themselves and their own challenges, and the experience cannot be taken away by anyone. Beginners don’t have strong opinions — they can’t effectively bother each other yet.

Relating this specifically to electronics, projects with Arduino are now practically ubiquitous. If you are beginning in electronics, when something is always around beginners, like Arduino, interesting things can happen. Beginners bend things, break things, they do things that the experts couldn’t imagine — and that’s a good thing. Some of the most disruptive innovations came from people tinkering, not exactly knowing what they’re doing, and later becoming experts only to be usurped by a new crop of tinkerers. It’s an endless cycle of people doing weird things because “they didn’t know any better.”

Electronics is full of problems, but it’s also full of people overcoming those problems — those are fun people to be around. They’re convinced that if they try, they can figure it out. Over the years I’ve tried to collect all the stories people would write in to me from Hack-a-Day, MAKE, or Adafruit about how, in a short time, they went from not knowing anything about electronics to being able to make something they always wanted, and how they discovered they had the potential all along. All they had to do was listen to their own voice and not someone else telling them they couldn’t do it for one reason or another.

When you’re learning something about electronics, you usually don’t know what’s “enough” until you discover what’s “too much.” Beginners are filled with uncertainty on how things will turn out — that’s the fun part — the surprise, the unexpected, how knowledge is made. Experts have expectations. Beginners can adapt themselves because they’re not set in their ways yet; experts tend to be more rigid and demand the same of others. Experts value what they have; beginners value what they don’t have yet.

Beginners can take more risks than experts — they start with zero, so there’s nothing to lose. Experts worry that if they’re an expert in one thing, they’ll need to be an expert in other things, otherwise their expertise could be questioned. For experts a lot of things are easy because they’ve done it so many times. Experts become impatient (with themselves and with others); beginners are patient and brave, because they don’t yet know it will become easy. Experts have pride; beginners can’t deceive themselves so easily.

Starting out now with making things is fantastic. With 3D printers, laser cutters, Maker Faires, hackerspaces, Techshops, Instructables, open source hardware, it’s never been a better time. I’m sure every generation says that, but I really think it’s true. Starting out now, you get to explore more, faster, cheaper, and with more people. This is all new stuff too — it’s hard for anyone to be an expert yet. This happened with homebrew computers, and it happened with the web. In the maker world, we’re all still figuring a lot of this out. There’s still plenty of time before we’re all experts at one thing or another.

Some of the most talented and prolific people I know have dozens of interests and hobbies. When I ask them about this, the response is usually something like “I love to learn.” I think the new discoveries and joys of learning are the crux of this beginner thing I’ve been thinking about. Sure, when you’ve mastered something it’s valuable, but then part of your journey is over — you’ve arrived, and the trick is to find something you’ll always have a sense of wonder about. I think this is why scientists and artists, who are usually experts, love what they do: there is always something new ahead. It’s possible to be an expert but still retain the mind of a beginner. It’s hard, but the best experts can do it. In making things, in art, in science, in engineering, you can always be a beginner about something you’re doing — the fields are too vast to know it all.

Since I started with Lewis Carroll, I figured I’d end it here too:

Alice came to a fork in the road. “Which road do I take?” she asked.
“Where do you want to go?” responded the Cheshire cat.
“I don’t know,” Alice answered.
“Then,” said the cat, “it doesn’t matter.”
– Alice in Wonderland

Linus On Specifications

Pointierte Einschätzung des grossen Meisters.

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into
Date: Thu, 29 Sep 2005 20:03:14 UTC
Message-ID: <fa.g0a33ji.m0e6ii@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.58.0509291247040.3308@g5.osdl.org>

On Thu, 29 Sep 2005, Arjan van de Ven wrote:
> a spec describes how the hw works... how we do the sw piece is up to
> us ;)

How we do the SW is indeed up to us, but I want to step in on your first


A "spec" is close to useless. I have _never_ seen a spec that was both big
enough to be useful _and_ accurate.

And I have seen _lots_ of total crap work that was based on specs. It's
_the_ single worst way to write software, because it by definition means
that the software was written to match theory, not reality.

So there's two MAJOR reasons to avoid specs:

 - they're dangerously wrong. Reality is different, and anybody who thinks
   specs matter over reality should get out of kernel programming NOW.
   When reality and specs clash, the spec has zero meaning. Zilch. Nada.

   It's like real science: if you have a theory that doesn't match
   experiments, it doesn't matter _how_ much you like that theory. It's
   wrong. You can use it as an approximation, but you MUST keep in mind
   that it's an approximation.

 - specs have an inevitably tendency to try to introduce abstractions
   levels and wording and documentation policies that make sense for a
   written spec. Trying to implement actual code off the spec leads to the
   code looking and working like CRAP.

   The classic example of this is the OSI network model protocols. Classic
   spec-design, which had absolutely _zero_ relevance for the real world.
   We still talk about the seven layers model, because it's a convenient
   model for _discussion_, but that has absolutely zero to do with any
   real-life software engineering. In other words, it's a way to _talk_
   about things, not to implement them.

   And that's important. Specs are a basis for _talking_about_ things. But
   they are _not_ a basis for implementing software.

So please don't bother talking about specs. Real standards grow up
_despite_ specs, not thanks to them.