Flight-Control
S | M | T | W | F | T | S | |
---|---|---|---|---|---|---|---|
52 | 22 22 | 23 | 24 | 25 | 26 | 27 | 28 |
01 | 29 | 30 | 31 | 01 | 02 | 03 | 04 |
02 | 05 | 06 | 07 | 08 | 09 | 10 | 11 |
03 | 12 | 13 | 14 | 15 | 16 | 17 | 18 |
04 | 19 | 20 | 21 | 22 | 23 | 24 | 25 |
|
Hot Projects
S | M | T | W | F | T | S | |
---|---|---|---|---|---|---|---|
52 | 22 22 22 | 23 23 | 24 24 | 25 25 | 26 26 | 27 27 | 28 28 |
01 | 29 29 | 30 30 | 31 31 | 01 01 | 02 02 | 03 03 | 04 04 |
02 | 05 05 | 06 06 | 07 07 | 08 08 | 09 09 | 10 10 | 11 11 |
03 | 12 12 | 13 13 | 14 14 | 15 15 | 16 16 | 17 17 | 18 18 |
04 | 19 19 | 20 20 | 21 21 | 22 22 | 23 23 | 24 24 | 25 25 |
|
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.
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.
A lot is happening and a a few more people have started to contribute their time, skills and knowledge to push DSpace into the realm of reality.
Last Saturday, Niklas Cathor, also a strong supporter of federated technology, dropped by and joined the hackparty to just start hacking on moving us to amd.
Alice and elf-pavlik have continued working on DSpace, fixing a lot of issues and we moved the client to something almost usable. The UI will receive another major overhaul, targeting mobile usage on smaller screens with intuitive touch gestures instead.
It was great to be sitting in a bus and see the Tikiman (our current development mascot, representing the users location) move on the map. It will be even greater when we can share our positions and movements :)
Today a new tileset for Munich was put into production, which hopefully will make rendering on low end devices and small bandwidth connections even faster. The new map reduces the amount of data transfered to the client by over 60%. As always, you can see the development progress live on the demo-site:
After the fruitful session on the weekend, we used the opportunity of still being together in Munich to scheme up the new internal structure and models/views:
Changes in the develop branch to follow the new model are already underway and DSpace is now an official Apollo-NG R&D project, so everything will start moving into the dspace namespace from now on.
3 nights and two days of hacking have come to a very successful end. It was a great experience, none of us ever participated in a hackparty/hackathon so we really didn't know how to go about it. On Friday we tried to establish a common ground and basic guidelines where to go and what to do, on Saturday we were all over the place and we mostly refined the way we are going to handle the repos and from Sunday morning we really digged into it. At this point I really want to personally thank all people, who joined together and helped to make the hard bootstrapping of a system like this possible, by sharing their time, knowledge, resources and even food :)
All preliminary mockup code has been replaced by a beautiful model/view approach in backbone/ender.js. That should make further development much more straightforward, cleaner and faster.
A working example of the basic results of this hackparty can be viewed on:
The git repos are up and running, more information on the pad for now:
With more manpower and additional resources we've managed to finish refactoring the initial mockup client code to use the ender javascript “package manager” and decided to go with qwery, bean, bonzo, underscore, backbone, handlebars and domready instead of a fully bloated js framework like jquery or extjs.
For comparison, just jquery without any other needed jquery plugin weighs 32kb after minifying and compression. Our ender package comes down to 28kb including everything else we seem to need. Maps often seem to be perceived as “annoying” by users if the map responsiveness is less than optimal, so we should always keep in mind to make this as lean and lightweight as possible and use other trickery to “emulate” a fluid experience.
Additionally ruebezahl dedicated some of his available storage and computing resources for the cause and now we already have the first public tileserver and the first version of a couchdb based overlay-server running. Great stuff :)
The git repos are up and running, more information on the pad for now:
Today we managed to test the local providers, tile rendering, tile delivery and successfully consolidated the options for the next steps. We still have one seat failing on us, but it's good to know, that we all can buckle our seat-belts. It's been great fun, as always :)
In the past several months it sometimes just so happened, that the geoipupdate tool, available on many GNU/Linux systems to update MaxMind's GeoIP databases just failed. It exited fine but left a corrupt database, unreadable to the application depending on it. In this particular environment, GeoIP lookup is a mission-critical dependency, so it was time to come up with a little cron/logger/geoipupdate assisted bash magic, to update MaxMind's GeoIP Databases automatically and with two fallback safeties, in case the new DB is corrupt or the download failed somehow.
It performed very well for the last several weeks, never raised an alert and is published now, as it might be useful for someone else out there, confronted with the same problem. You could spend your time elsewhere, instead of re-inventing something that is already here and which doesn't rely on alerts, to get a human's attention but tries to fix it by itself in an automated process:
Batteries in general and lithium based batteries in particular require special attention, when it comes to charging and balancing. For this reason, the lab has a Junsi iCharger 1010B+, which offers a complete battery management solution for virtually every battery technology out there and some non-battery related features as well (like DC-Motor burn-in and foam-cutting programs).
It has proved itself as reliable hardware for over a year, especially taking care of the custom made LiPo battery packs for the orion. It even offers a USB port for software updates and data-logging. Unfortunetaly, until now, only LogView users could get the logging data, but that would require a closed-source non-free operating system to run, which isn't available here (see Apollo-NG's Code of Conduct). Additionally, while LogView itself may be free (as in free beer), it doesn't seem to be open-source, so another solution was due…
When you offer free services, funny things do happen: Some people seem to have found their way to the Apollo-NG pads and started to collaboratively work on a document about software and hardware ecosystems as a permanent sustainable culture.
So if you're interested in the subject and would like to participate, please join the discussion on the mentioned pad:
https://apollo.open-resource.org/pad/permanent-software-hardware-culture