Years ago, while the GPLv3 was still being drafted, I got a chance to attend a presentation by Richard Stallman. He did his whole routine as St IGNUcius, and then at the end said he would be answering questions in a separate room off to the side. While the more causal nerds shuffled out of the presentation room, I went along with a small group of free software aficionados that followed our patron saint into the inner sanctum.
When my turn came to address the free software maestro, I asked what advantages the GPLv3 would have to a lowly hacker like myself? I was familiar with the clause about “Tivoization“, the idea that any device running GPLv3 code from the manufacturer should allow the user to be able to install their own software on it, but this didn’t seem like the kind of thing most individuals would ever need to worry about. Was there something in the new version of the GPL that would make it worth adopting in personal or hobby projects?
Interestingly, a few years after this a GPLv2 program of mine was picked up by a manufacturer and included in one of their products (never underestimate yourself, folks). So the Tivoization clause was actually something that did apply to me in the end, but that’s not the point of this story.
Mr. Stallman responded that he believed the biggest improvement GPLv3 made over v2 for the hobbyist programmer was the idea of “forgiveness” in terms of licensing compliance. Rather than take a hard line approach like the existing version of the GPL, the new version would have grace periods for license compliance. In this way, legitimate mistakes or misunderstandings of the requirements of the GPL could be resolved more easily.
The old saying is if your data isn’t backed up at least twice, it’s not backed up at all. For those not wise enough to heed this adage, there are a number of options available to you if you wish your data to be recovered. Assuming the drive itself is just corrupted somehow (maybe a malicious attack, maybe a user error) and not damaged beyond physical repair, the first step is to connect the drive to another computer. If that fails, it might be time to break out the computer forensics skills.
[Luis]’s guide is focused on Linux-specific drives and recovery tools, so this isn’t necessarily a general-purpose how-to. That being said, there is a lot of information in this guide such as how to mount the target drive’s partitions, how to set up various timelines, and which of the Linux system’s logs are important for the forensic analysis. This specific example in the guide also goes into detail about noticing which of the recent files had been accessed, what they might have done, and different approaches to piecing the mystery of this corrupted drive together.
[Luis] points out that the world of Linux forensics is much different from that of Windows, but for anyone looking to get started he suggests starting with a clean Linux install and going from there. There are many other avenues of digital forensics, as well; the field has as many avenues of exploration as there are different types of computers.
The platform is a quad-core Calxeda EnergyCore ARM SoC. Each chip draws only 5 Watts at full load, with eight chips weighing in at just 40 Watts. The circuit to power the server started as a solar charger, which was easy to convert just by transitioning from panels to a generator that works just like a bicycle trainer (the rear wheel presses against a spin wheel which drives the generator shaft).
So, the bicycle generator powers the solar charger, which is connected to an inverter that feeds a UPS. After reading the article and watching the video after the break we’re a bit confused on the actual setup. We would think that the inverter would feed the charger but that doesn’t seem to be the case here. If you can provide some clarity on how the system is connected please feel free to do so in the comments.