Taskwarrior is command line time management and reporting utility. I use taskwarrior for tasks that need a longer phase of planning before this task is prepared to be done and can really be accomplished. Also it happens that tasks over here can not be finished at all, because the prerequisites have failed or the testing phase has shown that this task can not be finished as has been intentionally thought or even better, the task is rubbish and will never be finished.

Whatever reasons are there to use taskwarrior, there is a command line setting I would like to write down here, because I use it seldom. This is needed to assign or change priority to a certain task:

task 13 modify priority:M
task 42 modify priorify:L
task 1  modify priority:H

While using the GNS3 network simulator, in certain labs it was needed to use special hosts, with provisioned and preconfigured software f.e. to test AAA with RADIUS or TACACS+, or to provide services like syslog or a webserver. These tasks are quite time consuming if virtual end devices are not at hand when you need them. Along with it they are even more time consuming if one does not the right tool at hand.

For a copy/paste installation a working terminal like xterm or urxvt is the tool. QEMU at default starts with VGA emulation, where mouse buffers might not work be working properly in X, if the right commands have not been used.

Starting a virtual host with QEMU a serial console and bind it the lo loopback interface , here TCP port 4321:

Append this line at the end:

-serial telnet:localhost:4321,server,nowait

While the guest is starting run following command to verify the TCP ports:

Now connecting to to the guest serial console running on loopack device should be working:

This method will also work by binding to the serial console to prefixes like f.e.: 0.0.0.0 and 192.0.2.1.

While doing regular system maintanance with eix one notification looked not as regular:

user@host % eix-test-obsolete quick

No non-matching entries in /etc/portage/package.keywords
No non-matching entries in /etc/portage/package.accept_keywords
No non-matching entries in /etc/portage/package.mask
No non-matching entries in /etc/portage/package.unmask
No non-matching or empty entries in /etc/portage/package.use
No non-matching or empty entries in /etc/portage/package.env
No non-matching or empty entries in /etc/portage/package.license
No non-matching or empty entries in /etc/portage/package.accept_restrict
No non-matching or empty entries in /etc/portage/package.cflags
The following installed packages are not in the database:
x11-proto/inputproto
x11-proto/xextproto
x11-proto/xproto

Running eix for search of a particlular package reported the same:

user@host % eix x11-proto/inputproto
No matches found

Asking in the official #gentoo IRC channel at freenode brought up more interesting portage commands, on how to search for orphans

user@host % emerge -cpv x11-proto/xproto

Calculating dependencies                ... done!
  x11-proto/xproto-7.0.31-r1 pulled in by:
    x11-wm/fvwm-2.6.7 requires x11-proto/xproto

>>> No packages selected for removal by depclean
...

The usage of the command emerge -c (depclean) -p (pretend) -v (verbose) orphan-package/name is really great in that example. Since it pinpoints the source of the issue. At that point it is necessary to rebuild the package here x11-wm/fvwm-2.6.7. And after that rebuild the dependency should be gone. If it is not gone you either hit a bug, or this ebuild causing this is from an overlay, which could be not well maintained.

Also emerge displays a hint what would be the correct action in such a case:

 root@host % emerge -C =x11-proto/xproto-7.0.31-r1 =x11-proto/inputproto-2.3.2-r1
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean <atom>` to check for reverse dependencies before
 * removing packages.

It is always a good to have the right tool at the right time, and to know how to use it. Gentoo's emerge is such a tool.

BGP today is 29 years old, but as BGP went 18, in year 2007 Yakov Rekhter, one of the authors of the first BGP RFC, gave a great talk at google about the history of BGP and its evolution over the time. He explains the initial problems BGP tried to solve as it has been the very first draft, version 1. The history of the BGP routing protocol is a history of the internet as we know it today.

This talk covers also following topic:

• NSFNET Backbone
• ARPANET and EGP-2
• CIDR Classless Inter Domain Routing
• Hub-and-Spoke(https://www.rfc-editor.org/rfc/rfc7024.txt)
• TCP/IP, UDP
• Address families
• unicast, broadcast, multicast (BUM traffic)
• BGP Confederations and BGP Route Reflection

Far more. It shows a additional view on how to approach technical problems, getting information, analysing data, defining realistic goals, designing, implementing a solution, testing, moving forward.

This is the conclusion of the talk Yakov Rekhter presented at the end of the presentation:

• Short-term solution tend to stay for a long time; long-term solutions tend to never happen
• "Good Enough" solutions are sufficient; "perfect" solutions are not necessary
• Meet market needs and accommodate technical progress by focusing on flexibility and extendibility, not by depending on the "crystal ball"
• Do not be afraid to question and violate, if needed, "architectural" principles (or any other dogmas)

From retrospective I can say for sure, this tech-talk is the best BGP explanation I have seen, it gives a solid overview over the protocol history, and its design goals at certain periods, how it went from version 1 to version 4, and why it still at version 4, BGP-4 since almost 20 years.

If you are getting first experience using BGP and want to learn about this protocol. Watch this presentation first then get more specific information by reading white papers, books and technical publications.

From the year 2007 until today there has been 104 RFC's published with the topic BGP. f.e.:

• Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
• BGP MPLS-Based Ethernet VPN
• Use of BGP for Routing in Large-Scale Data Centers

"Everything You Always Wanted to Know about BGP (and the Internet) * But Were Afraid to Ask (2007)".