Profile

Cover photo
Harald Bongartz
224 followers|124,898 views
AboutPostsPhotos

Stream

Harald Bongartz

Shared publicly  - 
 
As a physicist, I can relate.
 
This story has got to be the best use of tungsten carbide ever. 

(However, I must offer a correction to the story: Nobody would ever mistake that for Uranium. That would very clearly be mistaken for spheres of Plutonium, which for numerous reasons are even more alarming.)

It reminds me a bit of some things I did to mess with my students, back when I was a physicist. Once, I was teaching the advanced freshman lab, and since we were soon going to be doing radiation experiments, I started drilling them on radiation safety a few weeks in advance, because you have to know this stuff when you're a physicist. The core point of that training was all "the stuff we're working with here is all quite safe, so long as you don't do anything radically stupid."

Now, on the day of the first lab, I showed up in the room pushing our biggest source on a cart -- a big blue barrel full of paraffin shielding around a neutron source.

And, as it happened, I knew someone who owned an NBC suit -- the full-body rubber bunny-suit-with-visor sort of thing. An NBC suit I could borrow.

So I walk into a roomful of freshmen, casually wheeling in the source and talking to them, while wearing a full-body radiation suit.

"Um... you said this stuff was safe, right?"
"Oh, yeah, certainly."
"So why are you wearing that?"
"Oh, this? Just for safety's sake, you know."
"No... I mean, why are you wearing that?"
"Ah. Well you see, there's one of me, and there are twenty of you. And there's one bunny suit."

Just to make it worse, I was getting ready to do this to another class, and just as I had finally gotten in to that damned suit, the fire alarm went off.

I decided to take the time to remove the suit before evacuating the building, on the theory that a fire alarm in the physics building followed by someone leaving quickly while wearing an NBC suit was likely to alarm people a little bit.

h/t to +Amber Yust for finding the lovely story linked...
45 comments on original post
1
Add a comment...

Harald Bongartz

Shared publicly  - 
 
Hatte ich noch in einem Tab offen, muss ich unbedingt weitergeben.

+Kristian Köhntopp​ über #Virtualisierung, #Container, #SDN, #SDS, #Docker und #DevOps, und das alles kurz und verständlich.
 ·  Translate
 
Mehr oder weniger uneditiert aus dem Gehirn in den Channel genauen, weil jemand eine Diskussion vom Zaun gebrochen hat. Mal sehen, was draus wird.

Sag mal, Kris, wenn dieses Cloudzeugs so kaputt ist, wieso machst Du das dann eigentlich?

Hast Du Dir aktuelle Rechner mal angesehen? Für einen Server legst Du ab 3k Euro hin, wenn Du eine kleine Kiste zu einem guten Preis bekommen willst und für 10K Euro bekommst Du weitaus mehr Rechner, als Du brauchen kannst - 40-50 Cores, 1/4 Terabyte RAM und an die 50 TB Platten plus 2 Ports mit 10GBit-Interfaces. Wenn Du also große Maschinen kaufst, kriegst Du viel mehr Bumms für Dein Geld.

Aber: Das ist zu groß für alles. In der Tat reicht es leicht für 15-20 Produktionsinstanzen von irgendwas, oder für 200 Entwickler-Instanzen von demselben Zeugs.

Und hast Du die Mühle dann mal montiert und angeschaltet? Das tut weh. Die zählt Dir fünf Minuten lang ihre BIOSe, Herstellerlogos und Karten vor, bevor sie in die Gänge kommt. Hardware ist noch immer so ein Dreck wie 1980.

Wenn Du mit dieser Hardware was machen willst, dann muß da ein Kondom drumrum. Virtualisierung oder Container sind dieses Kondom - sie standardisieren Dir die Hardware in etwas, das sich immer gleich verhält und immer dieselben Nicht-Treiber braucht und sie erlauben es Dir, den Monsterbrocken in Stückchen klein zu schneiden, mit denen Du was anfangen kannst.

Container oder Virtualisierung?

Virtualisierung heißt, Du simulierst einen eigenen Rechner mit einem eigenen File System Buffer Cache, einer relativ festen Menge von CPUs und RAM und einer eigenen Gast-Kernel-Instanz. Im Gast einer virtuellen Maschine kannst Du ein komplett anderes Betriebssystem booten als im Host.

Der Overhead von Virtualisierung kann recht groß sein, wenn wirklich Hardware simuliert werden muß, aber in den meisten Fällen ist das nicht der Fall: Die verwendeten Treiber für Platten, Netz und so weiter machen VirtIO (http://wiki.libvirt.org/page/Virtio) und haben einen sehr geringen Overhead, weil sie genau keine Hardware simulieren, sondern Operationen an die Treiber des Hosts durchreichen. In einer solchen Umgebung kann man immer noch ein anderes Betriebssytem im Gast als im Host fahren, hat aber einen sehr geringen Virtualisierungsoverhead - jedenfalls, wenn man reale Lasten drauf tut und nicht einen Microbenchmark fährt, der designed ist, Performanceunterschiede maximal groß zu ziehen.

Container sind genau keine Virtualisierung, sondern es sind normale Unix-Prozesse, die gestartet werden. Im Gegensatz zu anderen Prozessen sind sie jedoch auf verschiedene Arten eingeschränkt: Die Menge an Systemressourcen (CPU, RAM, Netz, und so weiter), die sie nutzen können, ist durch https://en.wikipedia.org/wiki/Cgroups beschränkt und die Sicht, die sie auf das System haben, ist durch Linux Namespaces (https://lwn.net/Articles/531114/) beschränkt. Von Innen sieht ein Container also wie eine VM aus: man sieht ein eigenes Dateisystem, eigene Netzwerkinterfaces, Routingtabelle und iptables, hat eine private Prozeßliste und so weiter.

Container können ein eigenes Userland mitbringen, aber da es im Grunde nur Prozeßlisten-Subtrees mit eingeschränkten Rechten sind, ist der Kernel natürlich derselbe. Man hat also einen Redhat-Kernel mit dem Userland der Distro seiner Wahl unter dem Hintern oder wie immer die lokale Konfiguration aussieht.

Container zu starten ist fast genau so schnell wie ein normaler fork()-Systemaufruf, denn ein Container ist ja im Grunde nur ein fork() mit Zuckerguß, sollte man denken. Aber einige dieser Lagen Zuckerguß können recht dick werden und müssen auskühlen, bevor sie genießbar werden.

Das heißt in der Realität, daß ein Container oft nicht in einem Subtree des Host-Dateisystems läuft, sondern irgendeine Form von Loopback-Mount braucht, mit dem ein Image-File für den Container als Tree angemeldet wird. Ebenso hat der Container typischerweise keinen Zugriff auf die normalen Netzwerk-Interfaces des Hosts, sondern bekommt ein eigenes tun- oder tap-Interface an einer virtual Bridge und bekommt iptables-Regeln mit Firewall-Definitionen oder NAT aufgesetzt, bevor er losrennen kann. Je nach Umfang und Effizienz der Implementation hat man also schon Startzeiten für den Container, die weit über ein einfaches fork() hinausgehen, auch wenn sie wahrscheinlich unter der Setup-Zeit für eine qemu-kvm VM liegen.

Dazu kommt, daß Container-Isolation auf mehr als eine Weise nicht sehr vertrauenswürdig ist. Die in https://plus.google.com/u/0/+MathiasKrause/posts/Mj4j7UK6NSn geschilderten Probleme zum Beispiel sind nur teilweise auf LXC beschränkt - die seccomp-Fehler, die beschrieben werden, sind systemübergreifend und betreffen jeden seccomp-Clienten.

Idealerweise will man Container verwenden, wenn man keine Nicht-Linux-Gäste braucht. Aber wenn man Mandantenfähigkeit und sichere Isolation braucht, dann muß man eine Virtualisierung verwenden.

Welche Rolle spielen Quotas?

Die Ressourcen einer einzelnen Box sind beschränkt. Teilt man sie gleichmäßig auf, dann kommen auf jeden Core so und so viele GB Speicher, so und so viele IOPS und so und so viele MB/sec Platten- und Netzwerk-IO. Wenn man gegenüber seinen Gästen Zusicherungen machen möchte, etwa weil man einen SLA erfüllen muß, dann muß man seine Gäste mit Quotas ausstatten - nicht nur für CPU und RAM, sondern auch für IOPS, Disk- und Netzwerkbandbreite, Anzahl der Flows und so weiter, denn sonst kann ein einzelner Amok laufender Gast die Performance aller anderen Gäste runter ziehen.

Quotas können Token Bucket-Quotas sein, also kurze Bursts erlauben, die höher als die Quota sind, aber alle Gäste dürfen im Mittel nur so viel Ressourcen verbrauchen wie ihnen zugeteilt werden, sonst bekommt man Overcommitment und kann seine SLAs nicht einhalten.

Du redest oft von SDN und SDS. Wieso?

Wir schauen ja nicht nur auf eine Maschine. Also klar, ich kann mir eine so eine Box da hin stellen und damit rum dockern. Das ist relativ leicht. Aber wenn die Box dann umfällt, dann ist sie tot und alles, was darauf ist. Genauso, wenn ich die Maschine mal booten muß, weil Updates eingespielt worden sind und sie einen neuen Kernel laden muß - dann ist sie fünf bis zehn Minuten weg, mindestens.

SDS, Software Defined Storage, erlaubt es mir, Laufwerke zu definieren und einer VM oder einem Container bereitzustellen, und zwar idealerweise egal, wo in meinem Cluster von mehr als einer Maschine ich die VM starten möchte. Liegt auch das Bootfilesystem meiner VM auf einem solchen SDS, dann kann ich die VM beliebig in meinem Cluster starten und mit ein wenig mehr Aufwand sogar live-migrieren. Ich verliere idealerweise einen oder zwei Pings, wenn die virtuelle Maschine die letzte Phase der Migration abschließt, aber abgesehen davon merkt der Guest nichts davon, daß er nun auf einem anderen Host ist.

Das macht Wartungskonzepte für die Hosts einfacher: Ich kann einen rolling Reboot meines Computer-Clusters machen, indem ich einen Host nach dem anderen leer räume, ihn neu starte und mich dann um den nächsten Host kümmern, ohne daß die Guests übermäßig viel davon merken. Es macht auch Isolation von schädlichen Lasten einfacher: Wenn ein Host durch einen Scheduling-Fehler alle Datenbanken abbekommen hat, habe ich eine Chance, das für die Nutzer unsichtbar im Hintergrund zu reparieren.

SDN, Software Defined Netzworking, macht dasselbe für Netze: Ich kann Gastnetze beliebig definieren - Netzwerk, IP-Ranges, Ports, Firewall-Regeln und die VMs darin sind für den Gast und sein Projekt vollkommen frei definierbar. Es spielt dabei keine Rolle, daß Projekt A für sein Netzwerk A den Range 10.0.0.0/8 intern verwendet und Projekt B für sein Netzwerk B denselben Range belegt - das SDN trennt das und sortiert das auseinander, sogar dann, wenn Projekt A und Projekt B jeweils einen Gast mit 'derselben IP' auf demselben Host haben.

SDN und SDS sind harte Probleme. Sie sind mindestens so hart und komplex wie das Thema Virtualisierung selber.

Wenn man Cloud spielen möchte, also Virtualisierung mit mehr als einem großen Rechner in einem Cluster, dann braucht man eine Lösung mit einer glaubhaften, funktionierenden und skalierenden SDN und SDS-Story.

Das ist ein Problem, denn bisher haben Hersteller entweder das eine oder das andere und die im Einsatz befindlichen Open Source-Lösungen haben im Mittel gar nix.

Das hat auch damit zu tun, daß die Mengen der Leute, die Virtualisierungs-Cluster machen, und die Mengen der Leute, die ernsthaft Storage und ernsthaft Netz machen, weitgehend überlappungsfrei sind. Das sind verschiedene Dinge, die jeweils, damit man sie meistern kann, eine ganze Menge Zeit und Erfahrung brauchen.

Ports mit iptables zusammen tüdeln, Virtuelle Bridges zusammen tunneln (https://insights.ubuntu.com/2015/06/22/container-to-container-networking-the-bits-have-hit-the-fan/), hoffen, daß Open vSwitch sich auf mehr als 10 Hosts skaliert oder daß Open Daylite magisch den nötigen Code enthalten wird, der einem das macht sind halt keine wirklichen Lösungen für das Problem. Leute, die glauben, daß das dennoch der Fall ist, haben das Problem schlicht nicht verstanden. Dasselbe sinngleich bei Storage.

Punkt ist, daß man für einen Host oder drei oder maximal zehn ohne SDN und SDS-Story hinkommen mag. Danach ist alle und es tut alles beliebig weh.

Was hat Virtualisierung mit Devops zu tun?

Wenn ich alles richtig gemacht habe, und mein Underlay aus Hardware-Hosts, SDN und SDS meine Last tragen kann, ohne daß ich übermäßig darauf Rücksicht nehmen muß, welche Eigenschaften diese Last hat, dann kann ich im Overlay meine Gäste als Script schreiben.

"Mach mir ein 10/8 mit 3 VMs drin. Eine ist ein Datenbankserver, 8 Cores, 32G RAM, ein 2T Volume dran, mit diesem Ubuntu-Image und diesem Startscript, und zwei sind Webserver, 4 Cores, 8G RAM, dieses Ubuntu-Image mit jenem Startscript. Davor einen Load-Balancer Service, der mein SSL terminiert und eine externe IP mit diesem DNS-Namen hat und der nach hinten raus auf die beiden Webserver verteilt." ist ein solches Script. Mein Cluster-Manager akzeptiert das Script, schneidet sich irgendwo aus den Hosts die passenden Maschinen, legt ein Overlay-Netz drüber zieht mir das alles hoch.

Mein virtuelles Netz ist von den anderen virtuellen Netzen im Cluster isoliert - es ist egal, daß ich 10/8 verwende und ob im Netz noch weitere virtuelle Netze existieren, die auch ein eigenes, von meinem eigenen 10/8 verschiedenes 10/8 verwenden. Es ist auch egal, auf welchem Host meine Datenbank liegt, da mein SDS das Datenbank-Volume an jedem Host bereitstellen kann.

Wenn ich das so mache, und wenn ich mein Setup mit dem o.a. Script und der darauf aufsetzenden Automatisierung mit genau Null manuellen Handgriffen hochziehen kann - Code und Config auschecken, Maschinen konfigurieren, Datenbanken und Webserver hochfahren, Cluster konvergieren und Nodes in das Loadbalancer-Backend reinjoinen, dann kann ich so eine Konfiguration beliebig oft und mit Variantionen starten. Ich kann also neben dem Produktions-Setup auch Stages, Devs und so weiter produzieren und zwar schneller, als reale Hardware auch nur zum Selbsttest brauchen würde.

Wenn ich auch noch Snapshots habe, kann ich Dinge snapshotten, Tests fahren, die Modifikation der Tests wegschmeißen und mit neuem Code einen zweiten Testdurchlauf auf denselben Daten laufen lassen.

Das heißt, Dinge werden wiederholbar und reversibel zugleich und damit reproduzierbar und vergleichbar. Die ganze Ablaufkette "Hardware bereitstellen - Code verwalten - Code deployen - Code aktivieren - Code Auswirkungen messen - Code fixen" ist in Software darstellbar, scriptbar und parallelisiert ausführbar. Ich kann also Dinge risikoarm und mit geringer Latenz ausprobieren, ändern, vor- und zurückrollen und damit real ausmessen statt über hätte-könnte-müßte zu diskutieren.

Virtualisierung mit Snapshots und automatisierter Steuerung ist also ein wichtiges Hilfsmittel für Devops, wenn nicht sogar Vorraussetzung. Das geht alles Hand in Hand.

Wieso haust Du dann auf Docker ein?

Ich haue auf Container-Dateisysteme als Deliverable ein.

Die Aufgabe eines Entwicklungsprozesses ist es, etwas zu liefern, daß man in einer Produktivumgebung reproduzierbar einsetzen kann und über das man argumentieren kann. Das heißt, für eine Produktivumgebung muß ich wissen, was da in welcher Version und mit welcher Lizenz drin ist, wie es gebaut wird, was es leisten kann und wie ich es mit welchen Auswirkungen bei welcher Last wie skalieren muß.

Container-Dateisysteme verstecken solche Abhängigkeiten und machen sie einem Betrieb notlos schwer zugänglich.

Docker und sein Container-Dateisystem sind ideale Entwickler-Werkzeuge - Docker ist für Entwickler insbesondere in einem TDD-Umfeld das Beste seit geschnittenem Brot. Aber während ein Docker-Container leicht Deliverables produzieren kann - ein war, ein rpm oder deb oder sonst irgendwas sinnvoll beschreib- und verteilbares - ist der Container selber kein Deliverable und kann die Anforderungen an einen Produktionsbetrieb nicht erfüllen.

Das ist so, weil man über einen solchen Container - ein Binärblob unbekannter Herkunft, der durch andere Overlay-Blobs binär gepatched wird - nicht argumentieren kann. Welche Bestandteile in welcher Version sind drin, wer hat die gebaut, welche Lizenzen werden verwendet, was läuft intern und was konsumiert das an Speicher oder IO-Bandbreite und so weiter.

Das heißt - verwendet gerne Docker und Container-Images um Euer Zeugs zu bauen, aber baut als Ergebnis keine Images, sondern baut Pakete, und baut Euer Zeugs in Produktion aus Paketen zusammen, damit ihr versteht, wie sich das zusammensetzt und miteinander interagiert.
 ·  Translate
40 comments on original post
1
Add a comment...

Harald Bongartz

Shared publicly  - 
 
Lobos treffende Wort-für-Wort-Analyse des unten stehenden Tweets.
 ·  Translate
 
Der Parteikonvent der SPD hat sich mit 56% der Delegiertenstimmen für die Vorratsdatenspeicherung ausgesprochen. Überraschend wenig, weil natürlich nicht zufällig “Gerüchte” aufgetaucht sind, Gabriel habe mit Rücktritt im Falle der Ablehnung der VDS…
 ·  Translate
Der Parteikonvent der SPD hat sich mit 56% der Delegiertenstimmen für die Vorratsdatenspeicherung ausgesprochen. Überraschend wenig, weil natürlich nicht zufällig "Gerüchte" aufgetaucht sind, Gabri...
36 comments on original post
4
1
Henning Rogge's profile photo
Add a comment...

Harald Bongartz

Shared publicly  - 
 
Fascinating results.

/vi +stefan holzhauer 
 
All of these images were computer generated!

For the last few weeks, Googlers have been obsessed with a internal visualization tool that Alexander Mordvintsev in our Zurich office created to help us visually understand some of the things happening inside our deep neural networks for computer vision.  The tool essentially starts with an image, runs the model forwards and backwards, and then makes adjustments to the starting image in weird and magnificent ways.  

In the same way that when you are staring at clouds, and you can convince yourself that some part of the cloud looks like a head, maybe with some ears, and then your mind starts to reinforce that opinion, by seeing even more parts that fit that story ("wow, now I even see arms and a leg!"), the optimization process works in a similar manner, reinforcing what it thinks it is seeing.  Since the model is very deep, we can tap into it at various levels and get all kinds of remarkable effects.

Alexander, +Christopher Olah, and Mike Tyka wrote up a very nice blog post describing how this works:

http://googleresearch.blogspot.com/2015/06/inceptionism-going-deeper-into-neural.html

There's also a bigger album of more of these pictures linked from the blog post:

https://goo.gl/photos/fFcivHZ2CDhqCkZdA

I just picked a few of my favorites here.
25 comments on original post
2
Add a comment...

Harald Bongartz

Shared publicly  - 
 
"Für ein ausgerastetes Aufwachen"

Wenn ich nur wüsste, was eine "bofende Ehehälfte" ist ...

#spamvongesternnacht   #funnyspam  
 ·  Translate
1
Add a comment...

Harald Bongartz

Shared publicly  - 
 
Über den Unterschied zwischen "freiem WLAN" und "kostenlosem Internet".

Dass die Telekom nicht begeistert ist, wenn sich mehrere Leute einen Internetzugang teilen, ist verständlich. Dass man mit Desinformation dagegen lobbyiert, weniger.

#freifunk  
 ·  Translate
 
Es ist immer die gleiche neoliberale Mistargumentation. Niemand behauptet ja, dass Freifunk nichts kostet.

Aber es ist erschreckend, wie absurd viele Menschen die Vorstellung finden, dass man etwas teilt, das man hat (und natürlich bezahlt). In diesem Fall eben: Internet.

Freifunk ist digitale Gastfreundschaft!
 ·  Translate
View original post
1
Add a comment...
Have him in circles
224 people
Charly Kuehnast's profile photo
Michael Arcan's profile photo
Dirk Steins's profile photo
Simon Geraedts's profile photo
Christian Granert's profile photo
Hwong Guo Hung's profile photo
Jörg Henne's profile photo
Rheinwerk's profile photo
Rüstem Cetken's profile photo
 
Bavaria Studios planen laut Blickpunkt:Film unter anderem ein Remake von "Raumpatrouille".
 ·  Translate
4
Petra Ristow's profile photoHarald Bongartz's profile photoMichael Vogel (Heluecht)'s profile photo
4 comments
 
+Harald Bongartz Vielleicht wäre es eine Idee, das als Crowdfunding und Low-Budget zu machen. Dann hat es wenigstens ein wenig den Charme der alten Serie.
 ·  Translate
Add a comment...

Harald Bongartz

Shared publicly  - 
 
Nein, solche Daten stehen (bisher) nicht auf der eGK. Und die Sicherheitslücke ist auch nicht in der eGK, sondern bei der AOK (und anderen Kassen), und ausgenutzt wird sie auch hier nicht durch pöse Computerhacker - wie der Titel vermuten lässt - sondern per Social Engineering, sprich: Lügen am Telefon.

Aber die zitierte Aussage der AOK ist trotzdem einen Facepalm wert:
"(…)Im Sinne kundenorientierter Prozesse müssten Krankenkassen im Rahmen einer vertrauensvollen Kundenbeziehung Postadressen grundsätzlich als wahr annehmen können (…)“
 ·  Translate
 
Stehen Sie kurz vorm Burnout? Nehmen Sie Psychopharmaka? All diese Informationen sind auf der elektronischen Gesundheitskarte gespeichert. Nach Recherchen des heute journals sind die Daten jedoch nicht sicher.
 ·  Translate
Effizient, modern, sicher - so wird die elektronische Gesundheitskarte (eGK) gerne dargestellt. Doch ihr Sicherheitskonzept wird durch eine massive Datenschutz-Lücke ausgehebelt. Nach Recherchen des ZDF heute-journals sind sensible Patientendaten von Millionen Deutschen nicht sicher.
4 comments on original post
1
Add a comment...

Harald Bongartz

Shared publicly  - 
 
Ever wondered how a particle accelerator works? 😊


Direct link to video: http://img-9gag-fun.9cache.com/photo/aepN9qp_460sv.mp4
Click to see the pic and write a comment...
3
Add a comment...

Harald Bongartz

Shared publicly  - 
 
I think that's a frickin' cool idea. 

(Although I cannot help but imagine rainbow colored chaser lights made of those - and more like  #mlp  than on horses. Like #nyancat , but with ponies. I need to get some sleep.)
 
Horses Get Blinky Rainbow Tails #WearableWednesday  
http://adafru.it/fpM

I know the National Park Rangers in Philadelphia will be fighting to get their hands on this fun little device– Tail Lights. Yes, it’s for horses, and it brings to light (literally) the issue of them being on the road in the evening. Founder Sami Gros witnessed a hit and run which left one of her horses seriously injured–luckily her good friend that was riding actually was unharmed. She lives in an area with plenty of equestrian trails, but she says the problem is out there.

I was lucky. Each year thousands of horses and riders are injured and with some killed from automobile encounters. Another horse or rider should never be injured again because of lack of visibility.

Sami created a bundle of LED strips that wrap-mount to a horse’s tail and provide different lights and patterns for visibility. Tail Lights are currently used by some mounted patrol groups, and they often use the red/blue lights for law enforcement or yellow/SOS that can be easily recognized by airships in an emergency situation. The battery back is pretty hefty, and can run for close to 24 hours. Everything fits nicely into a Cantle Bag, which gives easy access to the controller, no matter the saddle style.

Read More  http://adafru.it/fpM
#tech   #wearables   #led   #horse  
21 comments on original post
1
1
Hans-Jürgen Lanzki's profile photo
Add a comment...

Harald Bongartz

Shared publicly  - 
 
Tracking Apps töten keine Menschen, 
Menschen töten Menschen.

Aber man sollte trotzdem vorsichtig sein, von wo man sich sein Smartphone zurückholt.
-----
Tracking apps don't kill people,
people kill people.

But you should be careful where you try to retrieve your phone from, anyway.

http://www.cbc.ca/news/canada/toronto/shooting-over-cellphone-case-is-extreme-say-police-1.3115069
 ·  Translate
 
Ein tragischer Fall, der auch zu denken gibt...
 ·  Translate
Die Möglichkeit, sein verlorenes Handy per App aufzuspüren, wurde einem 18-jährigen Kanadier zum Verhängnis. Er wurde beim Versuch, es zurückzubekommen, erschossen.
View original post
1
Add a comment...
People
Have him in circles
224 people
Charly Kuehnast's profile photo
Michael Arcan's profile photo
Dirk Steins's profile photo
Simon Geraedts's profile photo
Christian Granert's profile photo
Hwong Guo Hung's profile photo
Jörg Henne's profile photo
Rheinwerk's profile photo
Rüstem Cetken's profile photo
Basic Information
Gender
Male
Story
Tagline
It's science!
Links