Oh no, not that kind of quickie you might think about! Rumpel an me decided more or less spontaneously to go to Bonn and visit one of our former employee Martin and additionally take a little look at SIGINT in Cologne.
So we rent a car at Sixt on Friday morning and met Martin at 5 pm in his flat. Of course our trip was very analog, we didn’t have any navigation device, just printed a route calculated by Google maps and rely to male instinct on the way through Germany and the high traffic in Ruhr Valley at Friday afternoon before holiday… What should I say, of course everything went totally well and we had a lot of fun in our little car! You can see some pictures at picasa.
|Quickie through Germany|
Of course it was a great weekend! We’ve seen a lot of fascination places of Bonn and Cologne like Cologne cathedral, big ships on Rhine or Media Center in Cologne. The events at SIGINT were also interesting, where it cannot be compared with the Chaos Communcation Congress in Berlin. In Cologne you’ll always get a chair and the queues are very short. Nevertheless the topics are of high quality.
All in all it was an excellent trip, even it was very expensive.
One of the people that are working with me on some crazy stuff always forgets to pull the newest revision of the repository before changing the content and so he has very often trouble with different versions when he decides to push his work to the master repository. His actual workaround is to check out the complete repository in a new directory and merge his changes by hand into this revision… Here is a little instruction to maximize his productivity and minimize the network traffic.
Lets assume we have a repository, created like this:
And we have one user, that clones this new repository and inits:
So we have some content in our root repo. Another user (our bad guy) clones that repository too:
So let a bit of time elapse, while user one is changing the root repository so that the
testfile may look like this:
And of course, the changer commits his changes:
Ok, nothing bad happened, but now our special friend decides to work:
What do you think will happen if he tries to push his changes to the master repo? Your right, nothing but a error:
Mmmh, so lets try to pull the root repo:
Our friend would now check out the whole repository and insert his changes by hand, but whats the better solution? Merging the file!
Git has a function called
mergetool , you can merge the conflicts with a program of your choice. Some examples are
emerge or also for GUI lovers
In this post I’ll use
So change the conflicting file(s), you will also see the changes made in root’s and in your local revision. If you’re done just save it and commit your merge:
Great, now there is nothing that prevents you from pushing your changes to the root repository:
I think this way of solving such conflicts maybe much more efficient than cloning the whole repository again and again and again ;)
One week passed since I got a package of Spots, this weekend I found some time to hack a little bit with this funny components.
First of all I programmed a tool that visualizes the Spots movement in an OpenGL frame that draws a virtual Spot. Nice for demonstrations, but nothing spectacular.
After that I developed a little mouse emulator, that translates Spot movement to mouse motions on the screen. Here the Spot isn’t doing anything intelligent, it only sends its tilt status every 25 ms as well as switch events to broadcast. Another Spot, working as basestation connected to my machine, is listening to this talking Spot and my host analyzes the received values. To move the mouse on the screen or to generate a click I use the Robot class of the Java AWT package. Long story short, a video may explain it more understandable (via YouTube):
I will continue with working on these libraries before I publish them in another post. So look forward to the release ;-)
Before I wrongful blame my preferred Debian release called Sid I have to acknowledge I don’t know whether this feature is also available in other releases… Here is a small program to test/reproduce:
Compilation shouldn’t fail, but if you try to launch it you’ll get an exception like that:
This is caused by one little line in
/etc/sysctl.d/bindv6only.conf saying you want to explicitly bind via IPv6. But my connection (maybe yours too) communicates still over IPv4, so this method of networking of course fails. To change this behavior you have to choose between two solutions.
Solution 1: Permanent modification (needs to be root)
You can change this behavior for the whole system by editing the file
After that just type
invoke-rc.d procps restart in your terminal to let your changes take effect. Your next run should work fine.
Solution 2: Change it for this single example
If your are not allowed to change system settings, you can add
-Djava.net.preferIPv4Stack=true to your execution command:
This causes your actual runtime to connect the network via IPv4, no matter to system preferences. I hope this could save some time of developers like me ;-)
Fuck FLASH!! Need the flash-trick...
I didn’t heard about that trick before, but now he told me that feature.
If Flash kills your SunRay session you have to type
Ctrl+Alt+Moon , relogin and your session will revive. With running Flash!
As far as I know this happens very often when he is using his browser because unfortunately the whole web is contaminated with this fucking Flash… The Flash-Trick is very nice, but a flashblock plugin would be more user friendly!?