Rustic Retreat
Hot Projects
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.
Subscribe to our new main project Rustic Retreat on the projects own website.
When you leave the commercial/proprietary software ecosphere and jump into open-source operating systems, you will have to learn how to handle daemons. And once you've created a couple of those daemons yourself, taught them what to do and let them work in production, you gain a lot of experience and confidence in dealing with all kinds of daemons.
Yesterday, a couple of friends from the awesome http://co-munity.net/ecobytes project seemed to be in some sort of possible DDoS trouble and asked for my advice and experience to mitigate the issue. Now, to me, it is a very amazing experience to simply get root access to a lot of machines lately, operated by people which I have never physically met but in this case we are connected by elf-pavlik. And in today's world, voluntarily giving root access to someone else, is the ultimate token of trust or/and friendship. So I'd like to thank you guys for that vote of confidence.
Since it was supposed to be a DDoS, I've had my input filters clamped too early and saw that something was going on and a lot of traffic was moving but it somehow seemed wrong compared to other DDoS investigations I had to do in the past. After some failed attempts to block/null-route a couple of offensive networks, our analysis focus shifted to traffic distribution where we saw that one of the VMs seemed to be the top talker. And it also became clear that the traffic wasn't coming in, it was going out. I didn't take care to look at flow direction at all because I already assumed it was incoming traffic (DDoS).
Here's where Dashboards like this come in handy. You have all relevant metrics at a glance and can compare the current to some “normal” state in the past. Matching graphs and colors visually takes much less time than working on the console to aggregate everything manually for a quick situation overview.
It then quickly became apparent, that one of the VMs was the top talker so we moved onto that box and what started out as DDoS mitigation turned into digital exorcism. You know, when there are daemons that are possessed and controlled by some evil spirit to create some form havoc, mostly motivated purely by the ultimate overlord of all evil: Financial Profit. And what do you do when dealing with evil daemons? You go Exorcist on them.
chrono : Uhhhh, H0u5t0n, I have some good and some bad news
H0u5t0n : Bad news
chrono : I think we have a problem with F3l1ks
H0u5t0n : Could you be a bit more specific?
chrono : Well, seems as if the beige plastic element of extruder 0 melted
H0u5t0n : You mean the beige PEEK insulator between the hot- and cold-end?
chrono : Affirmative
H0u5t0n : How did that happen?
chrono : I was prepping him for a new job, manually set the target temp of
ext0 to 220°C for a quick cleaning extrusion of about 30mm of
filament when I noticed a sizzling sound which turned out to be
something dropping from the insulator onto the hot-end. A second
or so later, the whole hot-end started to drop out of the PEEK
insulator, at which point I set F3l1ks to standby to stop him
H0u5t0n : Did you check the temperature at that point?
chrono : Yeah, unfortunately, I didn't take a screenshot due to the hectic
of the moment and octoprint doesn't offer a history function to
get some hard data. All I can offer is a glimpse I had after I
stopped him and saw some obvious overshoot ranging somewhere
between 240-250°C. Did you guys ever verify the thermistor
readouts with an external reference thermometer?
H0u5t0n : Uhhhm, no... I suppose we did not
chrono : Ok, I'll have to do that then. Could you put a spare PEEK into
the next supply launch? I've already unmounted and secured ext0
so we should be able to continue printing in the meantime with
ext1 - after a couple of more safety tests
chrono : Which brings us to the good news:
H0u5t0n : Let me guess, you figured out a way to collect and ship F3l1ks's
metrics into the VFCC, to significantly reduce the risk of having
to work without more reliable data again?
chrono : Errr, yeah... exactly
Since the VFCC already offers all the features needed to store, retrieve and visualize all metrics of the 3D Print Robot, it was only a matter of an hour to install and configure collectd on the Odroid C1 to gather all system and printing related metrics, ship them into InfluxDB and mash up this fancy Live - F3l1ks - 3D Print Robot Stats Dashboard
Freedom of speech is nothing if there is no freedom to use language in every way we individually see fit. After all, in the end, language is nothing but a crude tool to transfer knowledge, a meaning or just the state of our rational/emotional mindset to someone else. The more cryptic or inhibited the sender is, when translating thought patterns or trying to communicate an emotional state, the more likely the chance of communication failure becomes: The receiver must rely heavily on interpretation and interpolation. This problem seems to be even bigger when people from different cultures communicate, since their social and language training is different, making interpretation even harder due to a lack of common training ground (also beautifully depicted in https://en.wikipedia.org/wiki/Darmok).
But after watching http://www.imdb.com/title/tt0486585/, I really kept wondering, if the life of those people really is so fucked up, that they're rather wasting their lifetime trying to pretend to be “decent” and “on the moral high-ground” while at the same time they just go home to eagerly receive the next ass-smacking from their wives to get one up. Fucking hypocrites. Now get the fuck out or not, I don't actually give a fuck because we have way more pressing problems to solve than allocating time and resources on debating/censoring the use of the word FUCK or any other for that matter.
And if you're often feeling offended by something someone says, ask yourself or even the sender (verify) if it was actually intended as an offence, before trying to censor words and oppress people, to distract and hide the deeper issues you're having but obviously seem unwilling to resolve yourself. Unwanted reflection of subconscious things, building up from too much exposure to double-think standards, can often be triggered by words associated with that. Sex probably is still one of the biggest contexts/meanings associated to the word family of fuck. As fucks can be used or (not) given in a plethora of meanings for amplification, a huge number of readily established and available idioms or even as simple expression deriving its meaning entirely from context or intonation it is the perfect candidate for a “War on Fucks”. For the children, of course.
Go read Bukowskis poetry if you want to see how even the most “offending” and brutish words showing things how they actually are without any fake metaphoric surface to shine things up. And still, this raw and honest way of working with words turned out very beautiful poetry worthwhile reading instead of some shit you think you're supposed to read in order to be accepted intellectually. Fuck that.
Hello H0u5t0n, thanks for giving me a heads-up about the solar eclipse today… NOT.
It must have been around 0935, when I couldn't escape the feeling of some environmental anomaly.
The light was just “not right”. I couldn't see the sun, since there was no quick access to southbound vantage points but a glimpse out of the northbound window revealed almost clear, blue sky and the apparent shadow/contrast and sharpness indicated no clouds in between. Yet, somehow, it was as if I was wearing dark sunglasses or as if we were suddenly much farther away from the sun.
This is going to be very experimental and sorry for the short notice :) Since we now have a relatively efficient video stream relaying capability thanks to mjpeg-relay and a highly anticipated set of carbon sheets arrived today, it is time to remove the Kapton-Tape from the the 3D printer and replace it with a 0.5 mm carbon sheet. So, if you're interested, put on some music you like and watch the process live on live.
For a long time, all machines in Apollo-NG's infrastructure use chrony as a replacement for the usual ntpd package. chrony can be compared to ntpd like nginx can be compared to Apache, newer, much more lightweight approach and some additional very nice features. While nginx has replaced most of the Apache installations these days, chrony still isn't adopted as a good alternative by most people yet.
During the NTPD reflection attack time and the mysql/kernel/ntpd leap second bug, it was nice to see how chrony really saved a lot of time and grief by not being affected. It has been working here - and in many other scenarios - absolutely flawlessly until today.
Soon after the release of RTL-SDR a lot of people started to play with software defined radios. Although the Elonics E4000 tuner and the Realtek RTL2832U Chip are a long way from the quality and performance/stability of an USRP(2), the price of $11 - EUR30 makes these devices an ideal beginners device for SDR experiments, without having to invest +$1k into hardware.
As soon as the new OsmoSDR is finished and available, it will provide a very cost-effective device, filling the gap between the funcube, with only 96kHz bandwith - some people lovingly call it the sadcube these days - and the USRP. The OsmoSDR approach seems to be the best compromise of both worlds and the osmocom team is doing a real kick-ass job, putting it together.
Right now, not only hackers, but old-school hams and other people are drawn to gnuradio and rtlsdr but sometimes find it hard to leave their known world behind and dive into the new world of doing radio in software. In order to make the transition easier, good examples are desperately needed. The following setup is an easy to understand, uncluttered narrow band FM receiver, that most hams and radio related people should be able to grasp and tweak.
Here is another beautiful automated reflow toaster oven build, which makes use of our open-sourced picoreflow DIY PID conrolled Reflow Oven Software and some bootstrapping concepts & ideas:
http://www.cube37.com/projects/reflow_toaster/design
It's great to see how the concept and software are spreading fast and spawn a whole new generation of inexpensive, modular and autonomous/remote-controlled PID temperature control approaches for all different kinds of applications, perfectly easy to adapt under DIY conditions, because they were developed under DIY conditions.
From the project's perspective we'll need your feedback, issues and ideas to come up with a rough plan to prioritize a couple of milestones we can fragment into work packages to organize a hackathon to push picoReflow's development further into the direction of an even more universal controller (picoPID) that won't even need to be hacked in order to do something else than just reflow soldering :)
So, please join us on picoPID Development Roadmap Pad and share your feedback & needs.
In order to reliably calibrate any kind of mechanical system, a dial-gauge really is a necessary tool. Today our Mitutoyo 2046S arrived and will be tasked directly to calibrate the bed of our 3D printer.
Mitutoyo seems to have a similar reputation level for measurement tools like Makita has for battery powered power tools: A very high price/performance ratio. The lab already carries a couple of other Mitutoyo tools, a large set of Makita tools and both have already proven themselves in terms of quality and reliability on many occasions.
You can even use them in the kitchen to drive mixers etc., this hack was successfully tested in the prototype-galley to create a number of dough's and mix all kinds of things with a Makita BHP459 (18V) while saving precious space and weight, a separate set of kitchen power tools would add. Better to make creative use of equipment which is already on-board, i.e. a battery powered motor with some sort of adapter we can put tools in.
In order to update the firmware of our 3D printer for dual head extrusion and to compile Cura (an alternative gcode slicer) a working AVR crossdev toolchain was needed.
The printer firmware uses the Arduino toolkit so the dependency was obvious, the Cura build unfortunately needs a working avr-gcc as well (not that obvious), because it also ships with Ultimaker firmware, which cannot be disabled, even if you don't have an Ultimaker (kinda stupid).
Currently, the stable crossdev avr-gcc suite with gcc 4.8.3 did not compile so it was a bit of a hassle to get it running again. In order to save somebody else the time to figure this out, here's the install trace that was already tested verbatim on another gentoo amd64 box and worked as well.
Let's start with a clean slate and unmerge any cross-avr chain:
crossdev -C avr
This was used originally:
USE="multilib -cxx" crossdev -v -s1 --without-headers --target avr --gcc 4.5.2 --binutils 2.21 --libc 1.7.0 USE="multilib cxx" crossdev -v -s4 --target avr --gcc 4.5.2 --binutils 2.21 --libc 1.7.0
As of 2015-04-05 the above combination doesn't work anymore, please use this instead:
USE="multilib -cxx" crossdev -v -s1 --without-headers --target avr --gcc 4.5.4 --binutils 2.21.1-r1 --libc 1.7.0 USE="multilib cxx" crossdev -v -s4 --target avr --gcc 4.5.4 --binutils 2.21.1-r1 --libc 1.7.0
And to finish it up:
ln -nsf /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts /usr/avr/lib/ldscripts ln -nsf /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts /usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.20.1/ldscripts cd /usr/avr/lib ln -nsf avr5/crtm328p.o . ln -nsf avr6/crtm2561.o . ln -nsf avr6/crtm2560.o . mkdir -p /usr/share/arduino/hardware/tools/avr/bin/ ln -s /usr/bin/avr-gcc /usr/share/arduino/hardware/tools/avr/bin/avr-gcc ln -s /usr/bin/avr-g++ /usr/share/arduino/hardware/tools/avr/bin/avr-g++ ln -s /usr/bin/avr-objcopy /usr/share/arduino/hardware/tools/avr/bin/avr-objcopy ln -s /usr/bin/avr-ar /usr/share/arduino/hardware/tools/avr/bin/avr-ar ln -s /usr/bin/avr-as /usr/share/arduino/hardware/tools/avr/bin/avr-as ln -s /usr/bin/avr-size /usr/share/arduino/hardware/tools/avr/bin/avr-size
If you want to use the Software Serial and monitoring feature, you need to install rxtx-2.2_pre2 or newer. This version is still masked in the main portage tree, so you will need to unmask it by adding
=dev-java/rxtx-2.2_pre2 ~x86 ~amd64
to /etc/portage/package.keywords/arduino and then (re)emerge it
$ emerge dev-java/rxtx
Also, if you don't want to use the crappy JAVA based Arduino IDE, you can simply use a Makefile like this: https://github.com/sudar/Arduino-Makefile