Google CodeSearch geht allerdings über die üblichen Volltext und Metadaten suchen hinaus. CodeSearch erlaubt mit Reguar Expression die Formuierung von Such-Ausdrücken die komplexe Beziehungen abprüfen. Dieses ermöglicht Data Mining in Unmengen von Quellcode, sehr praktisch für Untersuchungen zu Patterns oder Bug-Patterns.
Da bekommt man Lust dieses mit dem eigenen Code zu tun. Aber wer diesen nicht offenlegen will muss wohl vorerst mit Alternativen Vorlieb nehmen (die gängigen Code Inspection und Style Checker Tools haben auch Regeln in denen man den Quellcode durchsuchen kann).
Hier auch ein Beispiel: einige meiner Open Source Beiträge. Wie man sehen kann sind einige Duplikate dabei...
In der digitalen Welt, in der die Massenbedürfnisse abgedeckt sind, und auch die Distributionskosten für digitale Güter keine Rolle spielen (oder auch die Methoden und Kosten für die Pflege einer Community geringer sind) gibt es jedoch noch einen anderen Markt: The Long Tail. Die Idee dahinter ist, dass viele kleine Kategorien und Nischen existieren die für sich genommen wenige Anhänger haben, das Gesamtvolumen dieser Märkte aber nicht unerheblich ist.
Es ist kein Zufall dass "The Long Tail" (ein Begriff geprägt 2004 von Chris Anderson in einem Artikel im Wired magazine) oft im Zusammenhang mit Web 2.0 genannt wird: Web 2.0 Anwendungen zeichnen sich dadurch aus, dass es Plattformen sind in denen Gazillionen von Micro-Communities sich selbst organisieren. Die Communities sorgen sogar für den Digitalen Content der konsumiert wird, und dank Mund-zu-Mund Propaganda sind die Erschließungskosten für den Markt gering.
Wichtig dafür sind nur: Eine Community Agnostische Plattform, Selbstorganisation, Verknüpfung von Services (Mashups und APIs), Benutzerfreundlichkeit und Offenheit.
Was übrigens ganz Un-2.0 ist sind: zentralistische Strukturen, proprietäre Protokolle, Zwangsregistrierung und vorgekauter Content. Ich denke dabei zum Beispiel an einen Sachverhalt der auch im Computerwoche Notizblog schon beschrieben wurde: ComBOTS vermarktet Herr der Ringe Avatare.
ComBOTs wird das große Problem haben den Long Tail nicht besetzen zu können da es keine Plattform gibt die als Katalysator für Communities wirken wird: kein Chat, kein Verzeichnis, keine Social Networking Gemeinde, keine Foren. Und einfache Voice Kommunikation über IP waren zu Zeiten von Skype noch genug, dass sich alle Communities danach gerissen haben, eine Online Gemeinschaft irgendwo wird sich nur selten ohne Not für ComBOTs entscheiden. Zumindest nicht wegen den bisher existierenden Features. Von daher hoffe ich (ganz im Sinne der klassischen lokalen Wirtschaft 1.0) dass sich hier noch etwas tun wird. z.B. URLs zum Direktanruf und Flash Status Applets die man auch in Foren nutzen darf. Und dazu eine hosted Foren-Lösung - für Micro Communities. Ich denke auch Google Apps for Domains wird sich dahingehend entwickeln.
Pssst! Bei Google kannst Du Wörter kaufen! Jedenfalls denkt Google darüber nach der Forschergemeinde Wortkombinationen (sogenannte N-Gramme) zur Verfügung zu stellen. Diese werden bei Forschungen wie z.B. Text-Erkennung oder automatisierte Übersetzungen benötigt.
Als Ergebniss einer umfangreichen Auswertung in den Google Rechenzentren wurden 1.011.582.453.213 Wörter verarbeitet und dabei eine Liste mit 1.146.580.664 5-Wort-Kombinationen erstellt. Hintergrund der Aktion kann im offiziellen Google Research Blog nachgelesen werden. Das Ergebnis steht auf 6 DVDs zur Verfügung.
Als Ergebniss einer umfangreichen Auswertung in den Google Rechenzentren wurden 1.011.582.453.213 Wörter verarbeitet und dabei eine Liste mit 1.146.580.664 5-Wort-Kombinationen erstellt. Hintergrund der Aktion kann im offiziellen Google Research Blog nachgelesen werden. Das Ergebnis steht auf 6 DVDs zur Verfügung.
Geschrieben von Bernd Eckenfels
in Blogging, SW Entwicklung, Technik, Vernetzung
| Kommentare (0)
| Trackbacks (0)
Robot
Via Channel 9.msdn.com habe ich den Programmierwettbewerb von Microsoft gefunden, bei dem es darum geht einen Bot für den MSN Messenger zu schreiben.
Immerhin unterstützen die Angebotenen SDKs auch Java (Akonix SDK), aber eigentlich will man so was ja eher auf einem Framework aufsetzen, das mehrere IM Protokolle unterstützt. (oder zumindest XMPP verwendet und damit über Jabber Server transports sich auch an andere Netze anmelden kann)
Im Gesundheitsbereich ist für IT Software Hersteller und Dienstleister weltweit ein lukrativer Markt vorhanden. Trotz knappen Budgets - wie kann das sein? Nun das liegt zum Großteil an der Gesetzgebung und behördlichen Auflagen. Großangelegte Programme der Regierungen wie HIPAA/HL7 in den USA oder diverse Europäische Verordnungen und Deutsche ("Modernisierungs")-Gesetze haben zu einer komplexen Landschaft geführt. Behörden, Leistungserbringer, Dienste und Clearingstellen müssen aus einem sehr kleinen Angebot von hochpreisigen und altertümlichen Lösungen das richtige Produkt finden.
Dabei kann man weder den Lösungsanbietern böse sein (da die ein riessigen Aufwand treiben müssen um die Regulierungen zu verstehen) wenn sie Ihre Marktposition ausnutzen, noch kann man die Regulation per-se verteufeln. Denn Arzneimittelsicherheit, Rohstoffüberwachung, Pharma-Zulassungsverfahren, Geräteüberwachungen oder auch nur Datenaustausch-Vereinheitlichung sind ja durchaus Bereiche in denen Vorgaben sinnvoll und notwendig sind. Immerhin geht es hier um Menschenleben. Und ganz nebenbei auch um riesige Goldtöpfe die es zwischen den Interessengruppen aufzuteilen gilt. Allen vorweg(?) an die "Leistungsbezieher".
Dabei kann man weder den Lösungsanbietern böse sein (da die ein riessigen Aufwand treiben müssen um die Regulierungen zu verstehen) wenn sie Ihre Marktposition ausnutzen, noch kann man die Regulation per-se verteufeln. Denn Arzneimittelsicherheit, Rohstoffüberwachung, Pharma-Zulassungsverfahren, Geräteüberwachungen oder auch nur Datenaustausch-Vereinheitlichung sind ja durchaus Bereiche in denen Vorgaben sinnvoll und notwendig sind. Immerhin geht es hier um Menschenleben. Und ganz nebenbei auch um riesige Goldtöpfe die es zwischen den Interessengruppen aufzuteilen gilt. Allen vorweg(?) an die "Leistungsbezieher".
"(Heil)Kostentreiber IT?" vollständig lesen
Bei InformIT gibt es einen Artikel von John Tränkenschuh über die Sicherheitsprobleme die man sich mit SSH einfangen kann:
SSH Issues: Does Installing SSH Enable More Exploits Than it Solves? (26. Mai)
Natürlich ist ein verschlüsselter Shell Zugang auf jeden Fall vorzuziehen, aber es gibt eine ganz erschreckende Anzahl von Fehlern und Fallen die unbedarfte Administratoren beim SSH Einsatz machen, so dass es durchaus schon fast zu einem "würdigen" rsh nachfolger (was die Unsicherheit angeht) geworden ist.
Ein Must Read für Nachwuchsadministratoren, die alten Hasen wollen den Link unbedingt abspeichern zum weitergeben.
SSH Issues: Does Installing SSH Enable More Exploits Than it Solves? (26. Mai)
Natürlich ist ein verschlüsselter Shell Zugang auf jeden Fall vorzuziehen, aber es gibt eine ganz erschreckende Anzahl von Fehlern und Fallen die unbedarfte Administratoren beim SSH Einsatz machen, so dass es durchaus schon fast zu einem "würdigen" rsh nachfolger (was die Unsicherheit angeht) geworden ist.
Ein Must Read für Nachwuchsadministratoren, die alten Hasen wollen den Link unbedingt abspeichern zum weitergeben.
Geschrieben von Bernd Eckenfels
in Infrastruktur, Sicherheit, Technik
| Kommentare (0)
| Trackbacks (0)
Interessant an der Sache ist die Frage, wann TeleGeo Research wohl im 21sten Jahrhundert ankommt, und ganz Web 2.0-like das Poster zum Download anbietet, um damit mehr für sich zu werben, als sie mit 100 verkauften Kopien jemals verdienen können.
Angekündigt sind auch die aktualisierten Karten für IP-Traffic und Untersehkabel Kapazitäten.
Persönlich fänd ich ein Diagramm spassig, dass den Rückgang der internationalen Telefonminuten (durch VoIP) zeigt.
Was Tschibo und Sun Microsystems miteinander zu tun haben? Nun beide ermöglichen Ihren Kunden den verantwortungsvollen Umganz mit Energie. Bei Tschibo ist das in Form eines Watt-Meters. Jörn berichtet darüber in seinem Blog: EDV - Ende der Vernunft: Part1, Part2.
Geschrieben von Bernd Eckenfels
in Enterprise IT, Hardware, Technik
| Kommentare (0)
| Trackbacks (0)
In meiner Freizeit pflege ich die net-tools für Linux. Das ist eine Sammlung der grundlegenden Netzwerk Konfigurationsbefehle wie netstat, arp und ifconfig.
Deswegen bekomme ich öfters Anfragen und Fehlermeldungen wegen unerwartetem Verhalten dieser (und anderer) Netzwerk Programme, bei der Eingabe von IPv4-Addressen mit führenden Nullen, wie zum Beispiel: 010.010.010.010 oder 120.130.130.099.
In der Literatur (RFC790 macht dies falsch), und vor allem beim Umgang mit dem Rechner sollte man diese formatierungen vermeiden (besonders fatal ist es, wenn Programme diese Art von formatierung selbst verwenden!). Der Grund: eine Reihe von Implementierungen erlauben traditionell eine gaze Reihe von Schreibweisen für IPv4 Addressen. Darunter fällt auch die Interpretation der einzelnen Punkt-getrennten Nummern als Octalzahlen (statt Decimal), wenn diese eine führende null besitzen (oder hexadezimale Interpretation bei einem 0x Prefix, wie in C üblich).
Nicht alle Programme erlauben diese Schreibweise, und noch weniger Menschen ist diese geläufig. Das ist wohl auch ein guter Grund, warum man diese nicht verwenden sollte. Allerdings sollte man sich bewusst sein, dass manche Software die Zahlen anders interpretiert (oder sogar abweist, weil 100.100.100.09 keine gültige Octal-Zahl ist)
(Das Windows XP Ping.exe verhält sich übrigens genauso). Für Techniker: traditionell wird in der Unix Welt die Umsetzung von Strings in IPV4 Addressen mit der C-Library Funtion inet_aton(3) gemacht, die diese Interpretation vornimmt. Diese Function erlaubt auch die Angabe einer IP Addresse in Hexadezimalschreibweise 0x08080808 oder mit einer 16bit Komponente: 8.8.2056 oder eben mit Octal/Hexadecimal Prefix.
Übrigens erlaubt RFC3986 (der den Syntax für URLs angibt) diese Schreibweise nicht, und definiert nur Decimal-Zahlen. Das ist auch eine Konsequenz aus den Angriffen auf String-basierende URL Fillter die sich zu leicht durch die vielen unterschiedlichen Schreibweisen haben auf das Kreuz legen lassen.
Im Zuge der Umstellung auf IPv6 wurde die Fähigkeit der alternativen Schreibweisen übrigens in den meisten Implementierungen entfernt, z.b. inet_ntop weist diese Funktion nicht auf.
Die IPv6 RFCs (RFC3531) haben den selben Fehler wie die IPv4 RFCs gemacht, und vergessen die IPv6 Literale formal zu definieren (keine BNF Definition), auch dies wurde in RFC3986 nachgeholt.
Deswegen bekomme ich öfters Anfragen und Fehlermeldungen wegen unerwartetem Verhalten dieser (und anderer) Netzwerk Programme, bei der Eingabe von IPv4-Addressen mit führenden Nullen, wie zum Beispiel: 010.010.010.010 oder 120.130.130.099.
In der Literatur (RFC790 macht dies falsch), und vor allem beim Umgang mit dem Rechner sollte man diese formatierungen vermeiden (besonders fatal ist es, wenn Programme diese Art von formatierung selbst verwenden!). Der Grund: eine Reihe von Implementierungen erlauben traditionell eine gaze Reihe von Schreibweisen für IPv4 Addressen. Darunter fällt auch die Interpretation der einzelnen Punkt-getrennten Nummern als Octalzahlen (statt Decimal), wenn diese eine führende null besitzen (oder hexadezimale Interpretation bei einem 0x Prefix, wie in C üblich).
Nicht alle Programme erlauben diese Schreibweise, und noch weniger Menschen ist diese geläufig. Das ist wohl auch ein guter Grund, warum man diese nicht verwenden sollte. Allerdings sollte man sich bewusst sein, dass manche Software die Zahlen anders interpretiert (oder sogar abweist, weil 100.100.100.09 keine gültige Octal-Zahl ist)
# ifconfig lo 010.010.010.010
# ifconfig lo | grep inet
inet addr:8.8.8.8 Mask:255.0.0.0
# ping -c 1 010.010.010.010
PING 010.010.010.010 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=64 time=0.070 ms
# ping -c 1 0x08080808
PING 0x08080808 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=64 time=0.078 ms
(Das Windows XP Ping.exe verhält sich übrigens genauso). Für Techniker: traditionell wird in der Unix Welt die Umsetzung von Strings in IPV4 Addressen mit der C-Library Funtion inet_aton(3) gemacht, die diese Interpretation vornimmt. Diese Function erlaubt auch die Angabe einer IP Addresse in Hexadezimalschreibweise 0x08080808 oder mit einer 16bit Komponente: 8.8.2056 oder eben mit Octal/Hexadecimal Prefix.
Übrigens erlaubt RFC3986 (der den Syntax für URLs angibt) diese Schreibweise nicht, und definiert nur Decimal-Zahlen. Das ist auch eine Konsequenz aus den Angriffen auf String-basierende URL Fillter die sich zu leicht durch die vielen unterschiedlichen Schreibweisen haben auf das Kreuz legen lassen.
Im Zuge der Umstellung auf IPv6 wurde die Fähigkeit der alternativen Schreibweisen übrigens in den meisten Implementierungen entfernt, z.b. inet_ntop weist diese Funktion nicht auf.
Die IPv6 RFCs (RFC3531) haben den selben Fehler wie die IPv4 RFCs gemacht, und vergessen die IPv6 Literale formal zu definieren (keine BNF Definition), auch dies wurde in RFC3986 nachgeholt.
Tekrati ist immer wieder interessant. Analysten veröffentichen Ihre Arbeiten und Tekrati berichtet darüber. Leider wollen die Analysten nicht für Freiheit und Bier arbeiten. So muß man sich mit dem Vorschau-Content zufrieden geben.
Manchmal frage ich mich aber wirklich, wer würde $3.995 (oder $12.995) zahlen für eine Untersuchung der größten Colocation Facilities und Anbieter der Welt? Ist das die Art, wie man eine strategische Entscheidung vorbereitet?
Anyway, TeleGeography bietet auch einige freie Ressourcen an. Wer Karten und Bilder mag kann sich dort ja mal umsehen (Registrierung notwendig).

Manchmal frage ich mich aber wirklich, wer würde $3.995 (oder $12.995) zahlen für eine Untersuchung der größten Colocation Facilities und Anbieter der Welt? Ist das die Art, wie man eine strategische Entscheidung vorbereitet?
Anyway, TeleGeography bietet auch einige freie Ressourcen an. Wer Karten und Bilder mag kann sich dort ja mal umsehen (Registrierung notwendig).

« vorherige Seite
(Seite 3 von 4, insgesamt 31 Einträge)
nächste Seite »
Layout by Ricky Wilson | Serendipity Template by Carl Galloway | Login
Impressum
Bernd Eckenfels
Mörscher Str. 8
76185 Karlsruhe
bernd-2012@eckenfels.net
Read More

Kommentare