User Tools

Site Tools


Navigation Menu

Rustic Retreat

Live broadcasts and documentation from a remote tech outpost in rustic Portugal. Sharing off-grid life, the necessary research & development and the pursuit of life, without centralized infrastructure.

Rustic RetreatSubscribe to our new main project Rustic Retreat on the projects own website.

Hot Projects

SEEDStack

SEEDStack - Open 3D printable seed/sprouting systemDIY Food Hacking

UCSSPM

UCSSPM - Unified Clear-Sky Solar Prediction ModelOpen Solar Power

picoReflow

picoReflow - DIY PID Reflow Oven Controller based on RaspberryPiDIY Reflow Soldering

PiGI

PiGI - DIY Geiger Counter based on RaspberryPiRasPi Geiger Counter

DIY ARA-2000

Active Wideband Receiver Antenna for SDR - ARA-2000Wideband Antenna

DSpace

DSPace - Map everythingMap everything!

Mission-Tags

Apollo-NG Mobile Hackbase

Apollo-NG Hackerspacecraft

Apollo-NG is a mobile, self-sustainable, independent and highly-experimental Hackbase, focused on research, development and usage of next-generation open technology while visiting places without a resident, local Hackerspace and offering other Hackers the opportunity to work together on exciting projects and to share fun, food, tools & resources, knowledge, experience and inspiration.

Latest Mission-Log Entries

Random numbers: The fast and the furious

The expression security = usability-1 can be interpreted in many ways. Either things become far too complicated, so that regular users just don't want to be bothered with them or the amount of energy it takes to complete a security-related task is just insane.

To wipe a 1TB (1024GB) disk with random data or prep a disk for encryption, it takes a little more than 4 days (97 hours) when utilizing /dev/urandom. Who would want to wait 4 days for a supporting task like this to finish? Just considering the energy it takes, to keep the whole system up and running, only to write random data to a disk, clearly demands higher random data bitrates without sacrificing quality. Hardware-RNG's are good alternative but not always available, so you might want to give /dev/frandom a try.

→ Read more...

2025-05-02 06:26

Ubuntu IPv4-IPv6 Dual-Stack name resolution fix

In case you're up to date and want to offer v4 and v6 services in order to promote v6 you may have run into the issue, that apt-get and git and a lot of other programs on your box won't work properly anymore. The main reason why this is happening, is that many upstream services already resolve AAAA but the services attached are not properly configured. Ubuntu's repos are one of the best examples for that. Apt-get failed on half of their own hostnames because it used v6 by default. The solution is quite simple really:

Add the following to /etc/gai.conf:

precedence ::ffff:0:0/96  100

This will prefer local v4 resolution and will get us through the nasty phase of having to deal with both v4 and v6.

2013-02-06 13:41 · chrono

Apollo, we have a problem...

Another Hackathon-Weekend passed by and the DSpace-Client and its backends are really shaping up nicely. A lot of code was refactored during the weekend, taking full advantage of amd, backbone and ender now. The first real-time data sharing overlay was tested successfully as well, so we managed to get a lot of the basic features we imagine to have in DSpace working.

Due to the demo build deploy, the nodejs installation was updated to 0.8.17 but the etherpad-lite, which serves the Apollo-NG pads was too old for the switch. Etherpad-Lite was updated to latest, but the db-data of the old pads wasn't compatible to migrate from old format sqlite3 to new MySQL storage. All pads that weren't obviously marked as abandoned have been restored (content only - no history).

More people and groups like the MuCCC and RBOSE seem to have been using the Apollo-NG pads than expected 2 years ago. After 24 hours of downtime of the pads everything is up and running again, offering new features, like import/export functions and the ability to save revision points in the timeline. Since the data changed from sqlite to MySQL there should also be a small gain in performance and long-time reliability. Sorry for the inconvenience, hopefully, the new pads will run as stable for the next 2 years, as the other one did before.

If you are missing a pad or data from it, just drop a note. The data of the old pad will be stored for the next 14 days, afterwards it will be purged.

2013-02-04 12:20 · chrono