n der Welt der Softwareentwicklung existiert ein grauenhafter Ort namens “Dependency Hell”. Um so größer ein Projekt wird und je mehr Pakete in die Software integriert werden, desto wahrscheinlicher ist es, dass dieser fürchterliche Ort eines Tages betreten wird.

In Projekten mit vielen Abhängigkeiten kann das Aktualisieren abhängiger Pakete schnell zum Albtraum werden. Sind die Abhängigkeitsspezifikationen des Pakets zu strikt, besteht die Gefahr des “Version Lock” (die Unfähigkeit ein Paket zu aktualisieren, ohne, dass alle abhängigen Pakete dieses Pakets ebenfalls aktualisiert werden müssen). Wenn die Abhängigkeiten des Pakets allerdings zu lasch definiert sind, wird sehr wahrscheinlich ein Problem, das sich “Version Promiscuity” nennt (das Paket gibt vor, mit mehr zukünftigen Versionen seiner abhängigen Pakete kompatibel zu sein, als angemessen ist), eintreten. Dependency Hell bezeichnet die Situation, in der entweder Version Lock oder Version Promiscuity, oder beides den Entwicklungsprozess des Projekts beeinträchtigt.

Als Lösung für dieses Problem schlage ich ein einfaches Regelwerk vor, welches definiert wie Versionsnummern gewählt und erhöht werden. Diese Regeln basieren auf bereits existierenden und weit verbreiteten Verfahren, welche sowohl bei der Entwicklung von Closed- als auch von Open-Source Software verwendet werden, aber beschränken sich nicht zwingend auf diese. Um dieses System nutzen zu können, muss zuerst eine öffentliche API definiert werden. Diese kann entweder in Form einer Dokumentation existieren oder durch den Code selbst erzwungen werden. Egal auf welche Art und Weise die API umgesetzt wird, es ist wichtig, dass sie übersichtlich und präzise ist. Sobald die öffentliche API erstellt wurde, werden Änderungen an dieser durch bestimmten Veränderungen an der Versionsnummer vermittelt. Nimm ein Versionsnummernformat von X.Y.Z (Major.Minor.Patch) an. Bei Einführung von Bugfixes, welche die öffentliche API nicht beeinflussen, wird die Patch Version erhöht, API-kompatible Ergänzungen oder Änderungen erhöhen die Minor Versionsnummer, und Änderungen, welche nicht kompatibel zur aktuellen öffentlichen API sind, erhöhen die Major Version.

Ich nenne dieses System “Semantic Versioning”. Versionsnummern, die nach diesem Schema gewählt und erhöht werden, geben direkten Aufschluss über den entsprechenden Code und was sich von einer zur anderen Version verändert hat.

Three weeks ago I blogged about how to get rid of non-free Google services and moving to free software on my Android phone. I’ve got a lot of feedback via email, lwn, and Google+, many thanks to all of you for helpful hints! As this is obviously important to many people, I want to tie up some lose ends and publish the results of these discussions.

FRRouting (FRR) is an IP routing protocol suite for Linux and Unix platforms which
includes protocol daemons for BGP, IS-IS, LDP, OSPF, PIM, and RIP.

FRR’s seamless integration with the native Linux/Unix IP networking stacks
makes it applicable to a wide variety of use cases including connecting
hosts/VMs/containers to the network, advertising network services, LAN
switching and routing, Internet access routers, and Internet peering.

FRR has its roots in the Quagga project. In fact, it was started by many
long-time Quagga developers who combined their efforts to improve on
Quagga's well-established foundation in order to create the best routing
protocol stack available. We invite you to participate in the FRRouting
community and help shape the future of networking.

Join the ranks of network architects using FRR for ISPs, SaaS infrastructure,
web 2.0 businesses, hyperscale services, and Fortune 500 private clouds.

In data center topologies, right cabling is a time-consuming endeavor and is error prone. Prescriptive Topology Manager (PTM) is a dynamic cabling verification tool to help detect and eliminate such errors. It takes a graphviz-DOT specified network cabling plan (something many operators already generate), stored in a topology.dot file, and couples it with runtime information derived from LLDP to verify that the cabling matches the specification. The check is performed on every link transition on each node in the network. It also detects forwarding path failures using Bidirectional Forwarding Detection (BFD).

You can customize the topology.dot file to control ptmd at both the global/network level and the node/port level.

PTM runs as a daemon, named ptmd.

afeOBJ is a most advanced formal specification language which inherits many advanced features (e.g. flexible mix-fix syntax, powerful and clear typing system with ordered sorts, parameteric modules and views for instantiating the parameters, and module expressions, etc.) from OBJ (or more exactly OBJ3) algebraic specification language.

CafeOBJ is a language for writing formal (i.e. mathematical) specifications of models for wide varieties of software and systems, and verifying properties of them. CafeOBJ implements equational logic by rewriting and can be used as a powerful interactive theorem proving system. Specifiers can write proof scores also in CafeOBJ and doing proofs by executing the proof scores.
afeOBJ is a most advanced formal specification language which inherits many advanced features (e.g. flexible mix-fix syntax, powerful and clear typing system with ordered sorts, parameteric modules and views for instantiating the parameters, and module expressions, etc.) from OBJ (or more exactly OBJ3) algebraic specification language.

CafeOBJ is a language for writing formal (i.e. mathematical) specifications of models for wide varieties of software and systems, and verifying properties of them. CafeOBJ implements equational logic by rewriting and can be used as a powerful interactive theorem proving system. Specifiers can write proof scores also in CafeOBJ and doing proofs by executing the proof scores.

CafeOBJ has state-of-art rigorous logical semantics based on institutions. The CafeOBJ cube shows the structure of the various logics underlying the combination of the various paradigms implemented by the language. Proof scores in CafeOBJ are also based on institution based rigorous semantics, and can be constructed using a complete set of proof rules.
CafeOBJ has state-of-art rigorous logical semantics based on institutions. The CafeOBJ cube shows the structure of the various logics underlying the combination of the various paradigms implemented by the language. Proof scores in CafeOBJ are also based on institution based rigorous semantics, and can be constructed using a complete set of proof rules.

This tutorial provides a basic Python programmer’s introduction to working with gRPC.

By walking through this example you’ll learn how to:

Define a service in a .proto file.
Generate server and client code using the protocol buffer compiler.
Use the Python gRPC API to write a simple client and server for your service.

It assumes that you have read the Overview and are familiar with protocol buffers. Note that the example in this tutorial uses the proto3 version of the protocol buffers language, which is currently in beta release: you can find out more in the proto3 language guide and Python generated code guide, and see the release notes for the new version in the protocol buffers Github repository.

Elixir ❤️ Embedded

Nerves is an open-source platform that combines the rock-solid BEAM virtual machine and Elixir ecosystem to easily build and deploy production embedded systems.

“Cloud native” is a term used to describe applications designed specifically to run on a cloud-
based infrastructure. Typically, cloud-native applications are developed as loosely coupled
microservices running in containers managed by platforms. These applications anticipate
failure, and they run and scale reliably even when their underlying infrastructure is experiencing outages.
To offer such capabilities, cloud-native platforms impose a set of contracts and
constraints on the applications running on them. These contracts ensure that the applications
conform to certain constraints and allow the platforms to automate the management of the
containerized applications. Many organizations understand the necessity and importance of
becoming cloud native, but do not know where to start. Ensuring that cloud-native platforms
and the containerized applications that run on them work seamlessly together provides the
ability to anticipate failure and the reliability to run and scale even when the underlying
infrastructure experiences outages. This whitepaper describes a number of principles that
containerized applications must comply with in order to become good cloud-native citizens.

Adhering to these principles will help ensure that your applications are suitable for
automation in cloud-native platforms such as Kubernetes.

Almost any sensor yields more interesting results if mounted on a moving platform. Remember scanning thermometer? It’s time to mount TOF LIDAR (Time Of Flight / Light Imaging, Detection, And Ranging) on two precision rotary stages arranged for pan and tilt operation. Rig provides real-time position data along with distance to an obstacle. Using simple math we can calculate position in Cartesian coordinate system. Data is collected point by point to reconstruct 3D object model.

Wer kennt es nicht: Man startet ein neues Softwareprojekt oder steigt bei der Entwicklung eines bestehenden Projektes mit ein und muss erst mal zahlreiche Compiler, Interpreter, Editoren, Abhängigkeiten und Weiteres installieren. Dabei heißt es nicht selten, man soll davon die Version 1.2.24-50rc4 mit Bugfix-Patch 19 installieren, sonst funktioniert es nicht.

Six provides simple utilities for wrapping over differences between Python 2 and Python 3. It is intended to support codebases that work on both Python 2 and 3 without modification. six consists of only one Python file, so it is painless to copy into a project.

Six can be downloaded on PyPi. Its bug tracker and code hosting is on GitHub.

The name, “six”, comes from the fact that 2*3 equals 6. Why not addition? Multiplication is more powerful, and, anyway, “five” has already been snatched away by the (admittedly now moribund) Zope Five project.

A single distribution of libraries that automatically collects traces and metrics from your app, displays them locally, and sends them to any analysis tool.

The key features of OpenCensus include:

• Standard wire protocols and consistent APIs for handling trace and metric data.
• A single set of libraries for many languages, including Java, C++, Go, .Net, Python, PHP, Node.js, Erlang, and Ruby.
• Included integrations with web and RPC frameworks, making traces and metrics available out of the box.
• Included exporters for storage and analysis tools. Right now the list includes Zipkin, Prometheus, Datadog, Stackdriver, and Azure App Insights.
• Full open source availability for additional integrations and export options.
• No additional server or daemon is required to support OpenCensus.
• In process debugging: an optional agent for displaying request and metrics data on instrumented hosts.

BGP Tools, BGP Software, BGP Utilities

The Language Server protocol is used between a tool (the client) and a language smartness provider (the server) to integrate features like auto complete, go to definition, find all references and alike into the tool

About a week ago many users may have noticed instability on our hosted ZeroTier Central. Network controllers would flicker on and off, and eventually the whole service needed to be restarted across our cluster. 500 errors and timeouts were a thing.

CalDAVTester is a test and performance application designed to work with CalDAV and / or CardDAV servers and tests various aspects of their protocol handling as well as performance.

CalDAVTester basically executes HTTP requests against a server and verifies the responses returned by the server. Suites of tests are defined in xml configuration files, and an additional xml configuration file is used to define variables used whilst running (e.g., server address, user accounts to use etc).

A test suite configuration file comprises the following items:

A start section where resources needed for the tests can be created
A set of test suites, comprising:
    A set of tests, each of which can have:
        A set of HTTP request/response/verify tests.
An end section to do clean-up after the tests are all done.

The source code to CalDAVTester is available via GIT.