Artikel mit Tag support
Verwandte Tags
boards blog captchas flame foren howto idioten kiddies killfile kindergarten mailinglisten narf opensource registrierung spam usenet cheap fast good ajax awk backup bsd bugs firefox flavors fun gnu screen gravatar hotlinking html irc irssi javascript less lighttpd linux mustread netbsd news openbsd perl php pics ports rant s9y security slrn slrnface sqlite tmux userguide veraltet video vim vsftpd w3c weihnachten windows x-face youtube zsh bloatware hacken mail oje outlook scoring Security tin trojaner vollpfosten admin blackberry facebook git grml handy zsh-lovers redhat tshirt vortrag serial vmware browser anzugtraeger cam cygwin desktop-manager firmware Flyakite OSX japan job laptop lenovo linus lizenz microsoft router server upgrades usb vigor vista vorteile wuerzburgVielen dank VMware
Submitted by Christian Schneider on Di, 2008-01-22 14:36

Dafuer das es unter Linux zu solchen Problemen kommen kann, es aber unter Windows funktioniert. Ist ja auch kein Problem. Ich kaufe mir ja gerne Software damit ich sie nicht nutzen kann, weil die Serial die der Software beiliegt, nicht angenommen wird. Besonderen Dank an den Vorschlag eine Free 30-day evaluation serial number zu nutzen.
Good, cheap, fast
Submitted by Christian Schneider on Mo, 2007-10-29 08:26

(via Email)
Warum ein Anruf bei Microsoft 85,68 Euro kostet
Submitted by Christian Schneider on Fr, 2007-09-21 17:10
http://www.welt.de/[..]/Warum_ein_Anruf_bei_Microsoft_8568_Euro_kostet.html*bruahaaaaaaa*
Probleme mit Windows Vista oder Office 2007? Das kann teuer werden: Wer die Hotline des Herstellers Microsoft anruft, zahlt für eine einzelne Anfrage 85,68 Euro. Der Software-Konzern findet den Preis in Ordnung. Die Mitarbeiter im Call-Center seien eben hoch qualifiziert.
[...]
Eine einzelne telefonische Anfrage zum Thema Windows Vista oder dem Büropaket Office 2007 kostet 85,68 Euro. Die Kunden dürfen allerdings mehrmals anrufen, wenn der Mitarbeiter das Problem nicht beim ersten Mal lösen kann – das kostet dann nichts extra. „Der Verdacht liegt nahe, dass Microsoft gar nicht will, dass die Kunden anrufen“, sagt Carola Elbrecht,
Support wird eingestellt
Submitted by Christian Schneider on Do, 2007-08-23 10:15
Und zwar der von mir. Ich hab keine Lust mehr..
- irgendwelchen ahnungslosen Vollpfuschern zu erklaeren wieso sie die Finger von einem Root-Server und dessen Administration lassen sollen.
- den ach so armen Newbies die Anleitungen rektal zu verabreichen und ihnen die Manpages vor zu lesen.
- von Outlook Express geschrottete ToFu-Postings mit mehrzeiliger Attributionline und nicht deklarierten Umlauten zu lesen, weil ihre Benutzer zu dumm/faul sind sich einen brauchbaren Newsreader zuzulegen oder ihren richtig zu konfigurieren.
- mir staendig irgendwelches Geschwafel anzuhoeren das jeder mal angefangen hat.
- mich beleidigen zu lassen wenn ich auf Anleitungen/Suchmaschinen verweise.
OpenSource-Projekte unterstuetzen
Submitted by Christian Schneider on Do, 2007-07-19 15:33
Diese Woche hatte ich einen interessanten Mailaustausch mit einem Newbie, der seit einem Jahr Linux nutzt und Fragen zu meinen Konfigurationsdateien hatte. In einer Mail hatte ich "Free software: Contribute nothing, expect nothing." als Signatur stehen und als Antwort kam von ihm
Jetzt muss ich dazu sagen, dass mir persoenlich ein User der "zugibt" nicht programmieren zu koennen lieber ist, als 100 User die meinen sie koennten es, aber egal. Man muss nicht programmieren koennen um OpenSource zu unterstuetzen. In der Mail mit dem Subjekt Greyday? Eher ein Tag zum Feiern. von Kristian Koehntopp steht wie er "zu Linux gekommen ist". Es gibt etliche Moeglichkeiten wie man OpenSource unterstuetzten kann.
Dokumentationen:
Jeder User kann Dokumentationen schreiben! Wichtig dabei ist nur, dass sie uebersichtlich und technisch korrekt sind. Mit "$foo herunterladen und installieren!" kann ein Anfaenger nicht sonderlich viel anfangen. Schreibt den genauen Vorgang; am besten fuegt die von euch eingegebenen Kommandos via copy&paste ein und erklaert sie kurz.
Ueberlegt euch was ihr dokumentieren wollt. Niemand braucht die 2342. Erklaerung wie man ein rpm-Paket installiert oder wie man ein tar.gz-Archiv entpackt; sowas sollte allenfalls der Vollstaendigkeit halber in einer Anleitung erwaehnt werden. Sorgt dafuer das der Text uebersichtlich bleibt und hebt wichtige Passagen hervor (pre, blockquote, ..). Korrekturlesen! Das ist besonders bei technischen Dokumentationen unverzichtbar! Einige User arbeiten mit copy&paste; wenn ein Leser nach diesem Prinzip vorgeht, sorgt ein Fehler in einer Kommandozeile u. U. dafuer, dass er entweder sein System schrottet oder die Anleitung als "unbrauchbar" einstuft (auch wenn der Rest korrekt ist).
Wenn man eine Dokumentation schreibt, sollte man dazu sagen auf welches System sich nachfolgende Anleitung bezieht oder ob sie "Distributionsunabhaengig" ist. In beiden Faellen sollte man angeben welche Programme benoetigt werden, welche Programmversionen eingesetzt wurden und woher man diese beziehen kann (bzw. wie man diese ggf. installiert). Gebt dem Leser die Moeglichkeit euch kontaktieren zu koennen. Auch Dokumentationen ziehen Support nach sich. Man bekommt immer wieder Mails in denen Fragen gestellt werden oder man auf Fehler aufmerksam gemacht wird. Interessant ist auch noch der Text Irgendwann wie Stevens schreiben aus der Datenschleuder des CCC. mikas Artikel Die Gesetze von OpenSource... sind ebenfalls lesenswert (auch wenn sie auf eine andere Zielgruppe bezogen sind).
Konfigurationsdateien/Scripte:
Dokumentiert und veroeffentlicht die Konfigurationsdateien der von euch eingesetzten Programme. Je ausfuehrlicher, desto besser. Aber auch ein kurzer Kommentar traegt zum besseren Verstaendnis bei. Innerhalb von Scripten sollte man function()en aussagekraeftige Namen zuweisen. Mit
Gleiches gilt auch fuer Scripte. Wenn ihr Scripte veroeffentlicht, dann spart nicht mit Kommentaren; Kommentare sind genauso wichtig wie uebersichtlich formatierter Quelltext. Und bevor elise mich jetzt wieder schimpft: Ja. Auch wenn das notwendig ist halte ich mich selber selten daran. Kommentierter und uebersichtlich formatierter Quelltext erleichtert das Lesen und Verstehen erheblich.
Der groesste "Fehler" der bei Shellscripten gemacht wird, ist das ueberfluessige Benutzen einer Shebang-Zeile, welche die Bash aufruft. Die Bash ist nur ein Standard; nicht *der* Standard! Oder - um genauer zu werden - die Bash ist nur auf GNU/Linux - Systemen die Standardshell (und selbst hier nicht auf allen Distributionen). Ein Shellscript, welches /bin/bash als Interpreter nutzt, wird unter Free-/Open-/NetBSD, AIX, IRIX, SunOS und HP-UX nicht funktionieren. Verzichtet also wenn moeglich auf
Mailinglisten/Foren:
Tragt euch in den offiziellen Mailinglisten ein und/oder registriert euch in den Foren. Dort koennt ihr Fragen stellen (nachdem ihr die FAQ bzw. HowTo RTFM gelesen habt) und anderen Usern bei Problemen helfen. Je mehr Arbeit ihr den Developern abnehmt, desto mehr Zeit haben diese ihre Software weiter zu entwickeln. Anfaengern hilft man am besten, wenn man ihnen Hilfe zur Selbsthilfe gibt. Ein "Lies Dir das Handbuch durch (http://link.zum.handbuch/abschnitt.html)!" ist sinnvoller als eine Step-by-Step - Anleitung.
Man sollte sich auch darueber im Klaren sein, dass eine "Step-by-Step" - Anleitung u. U. andere User faul werden laesst. Wenn sie wissen wer ihnen das Denken abnimmt, werden sie mit Sicherheit nicht selbst anfangen Eigeninitiative zu entwickeln. Diverse Kiddies reagieren zwar etwas .. komisch darauf aber solche Reaktionen sind Gott sei Dank nicht die Mehrheit. Schweigen mit arrogantem Unterton ist manchmal die beste Antwort.
Push it, don't hype / Werbung:
Jeder hat sein favorisiertes Programm; nur sollte man nicht davon ausgehen das andere User die gleichen Vorlieben haben. Menschen Programmieren und Menschen machen Fehler; ergo sollte man auch eingestehen koennen, dass $FOO auch Vorteile gegenueber $BAR hat. Linux/Unix - User finden immer wieder einen Grund einen Holy war zu beginnen (Es wurde zwar schon ueber jedes Thema einer gefuehrt, aber egal. Da gehts ums Prinzip.); laecherlich wird es erst, wenn ein Teilnehmer die Scheuklappen aufsetzt und entgegen aller Argumente "sein" System verteidigt.
Aehnliches gilt auch fuer Werbung; es spricht absolut nichts dagegen wenn man fuer "seine" Software Werbung macht, jedoch sollte man dann auch die Nachteile auflisten, damit andere User auch wissen ob das Programm fuer sie geeignet ist. Meine Meinung ueber Debian sollte hinreichend bekannt sein, aber Debian steht im Gegensatz zu dem Grossteil der Benutzer wenigstens dazu nicht perfekt zu sein.
Schön und gut, aber wie soll ich freie Software unterstüzen? Ich kann nicht programmieren und hab auch nicht soviel Kohle das ich was spenden könnte.
Jetzt muss ich dazu sagen, dass mir persoenlich ein User der "zugibt" nicht programmieren zu koennen lieber ist, als 100 User die meinen sie koennten es, aber egal. Man muss nicht programmieren koennen um OpenSource zu unterstuetzen. In der Mail mit dem Subjekt Greyday? Eher ein Tag zum Feiern. von Kristian Koehntopp steht wie er "zu Linux gekommen ist". Es gibt etliche Moeglichkeiten wie man OpenSource unterstuetzten kann.
Dokumentationen:
Jeder User kann Dokumentationen schreiben! Wichtig dabei ist nur, dass sie uebersichtlich und technisch korrekt sind. Mit "$foo herunterladen und installieren!" kann ein Anfaenger nicht sonderlich viel anfangen. Schreibt den genauen Vorgang; am besten fuegt die von euch eingegebenen Kommandos via copy&paste ein und erklaert sie kurz.
Ueberlegt euch was ihr dokumentieren wollt. Niemand braucht die 2342. Erklaerung wie man ein rpm-Paket installiert oder wie man ein tar.gz-Archiv entpackt; sowas sollte allenfalls der Vollstaendigkeit halber in einer Anleitung erwaehnt werden. Sorgt dafuer das der Text uebersichtlich bleibt und hebt wichtige Passagen hervor (pre, blockquote, ..). Korrekturlesen! Das ist besonders bei technischen Dokumentationen unverzichtbar! Einige User arbeiten mit copy&paste; wenn ein Leser nach diesem Prinzip vorgeht, sorgt ein Fehler in einer Kommandozeile u. U. dafuer, dass er entweder sein System schrottet oder die Anleitung als "unbrauchbar" einstuft (auch wenn der Rest korrekt ist).
Wenn man eine Dokumentation schreibt, sollte man dazu sagen auf welches System sich nachfolgende Anleitung bezieht oder ob sie "Distributionsunabhaengig" ist. In beiden Faellen sollte man angeben welche Programme benoetigt werden, welche Programmversionen eingesetzt wurden und woher man diese beziehen kann (bzw. wie man diese ggf. installiert). Gebt dem Leser die Moeglichkeit euch kontaktieren zu koennen. Auch Dokumentationen ziehen Support nach sich. Man bekommt immer wieder Mails in denen Fragen gestellt werden oder man auf Fehler aufmerksam gemacht wird. Interessant ist auch noch der Text Irgendwann wie Stevens schreiben aus der Datenschleuder des CCC. mikas Artikel Die Gesetze von OpenSource... sind ebenfalls lesenswert (auch wenn sie auf eine andere Zielgruppe bezogen sind).
Konfigurationsdateien/Scripte:
Dokumentiert und veroeffentlicht die Konfigurationsdateien der von euch eingesetzten Programme. Je ausfuehrlicher, desto besser. Aber auch ein kurzer Kommentar traegt zum besseren Verstaendnis bei. Innerhalb von Scripten sollte man function()en aussagekraeftige Namen zuweisen. Mit
function hurga() { perl -ne 'while ( m/"((www|ftp|http):\/\/.*?)"/gic ) { print $1, "\n"; }' $* } werden die wenigsten User was anfangen koennen, waehrend ein# PERL: Get all www/ftp/http- URIs of a given filemehr oder weniger selbsterklaerend ist.
function getlinks() { perl -ne 'while ( m/"((www|ftp|http):\/\/.*?)"/gic ) { print $1, "\n"; }' $* }
Gleiches gilt auch fuer Scripte. Wenn ihr Scripte veroeffentlicht, dann spart nicht mit Kommentaren; Kommentare sind genauso wichtig wie uebersichtlich formatierter Quelltext. Und bevor elise mich jetzt wieder schimpft: Ja. Auch wenn das notwendig ist halte ich mich selber selten daran. Kommentierter und uebersichtlich formatierter Quelltext erleichtert das Lesen und Verstehen erheblich.
Der groesste "Fehler" der bei Shellscripten gemacht wird, ist das ueberfluessige Benutzen einer Shebang-Zeile, welche die Bash aufruft. Die Bash ist nur ein Standard; nicht *der* Standard! Oder - um genauer zu werden - die Bash ist nur auf GNU/Linux - Systemen die Standardshell (und selbst hier nicht auf allen Distributionen). Ein Shellscript, welches /bin/bash als Interpreter nutzt, wird unter Free-/Open-/NetBSD, AIX, IRIX, SunOS und HP-UX nicht funktionieren. Verzichtet also wenn moeglich auf
#!/bin/bash als Shebang und verwendet stattdessen #!/bin/sh. /bin/sh ist naemlich auf jedem Linux/Unix vorhanden.Mailinglisten/Foren:
Tragt euch in den offiziellen Mailinglisten ein und/oder registriert euch in den Foren. Dort koennt ihr Fragen stellen (nachdem ihr die FAQ bzw. HowTo RTFM gelesen habt) und anderen Usern bei Problemen helfen. Je mehr Arbeit ihr den Developern abnehmt, desto mehr Zeit haben diese ihre Software weiter zu entwickeln. Anfaengern hilft man am besten, wenn man ihnen Hilfe zur Selbsthilfe gibt. Ein "Lies Dir das Handbuch durch (http://link.zum.handbuch/abschnitt.html)!" ist sinnvoller als eine Step-by-Step - Anleitung.
Man sollte sich auch darueber im Klaren sein, dass eine "Step-by-Step" - Anleitung u. U. andere User faul werden laesst. Wenn sie wissen wer ihnen das Denken abnimmt, werden sie mit Sicherheit nicht selbst anfangen Eigeninitiative zu entwickeln. Diverse Kiddies reagieren zwar etwas .. komisch darauf aber solche Reaktionen sind Gott sei Dank nicht die Mehrheit. Schweigen mit arrogantem Unterton ist manchmal die beste Antwort.
Push it, don't hype / Werbung:
Jeder hat sein favorisiertes Programm; nur sollte man nicht davon ausgehen das andere User die gleichen Vorlieben haben. Menschen Programmieren und Menschen machen Fehler; ergo sollte man auch eingestehen koennen, dass $FOO auch Vorteile gegenueber $BAR hat. Linux/Unix - User finden immer wieder einen Grund einen Holy war zu beginnen (Es wurde zwar schon ueber jedes Thema einer gefuehrt, aber egal. Da gehts ums Prinzip.); laecherlich wird es erst, wenn ein Teilnehmer die Scheuklappen aufsetzt und entgegen aller Argumente "sein" System verteidigt.
Aehnliches gilt auch fuer Werbung; es spricht absolut nichts dagegen wenn man fuer "seine" Software Werbung macht, jedoch sollte man dann auch die Nachteile auflisten, damit andere User auch wissen ob das Programm fuer sie geeignet ist. Meine Meinung ueber Debian sollte hinreichend bekannt sein, aber Debian steht im Gegensatz zu dem Grossteil der Benutzer wenigstens dazu nicht perfekt zu sein.













Last ten comments: