[ENC]BladeXP's Blog

Was die Welt nicht alles braucht!

Einträge in der Kategorie „Windows”

KNX Plugins

geschrieben von encbladexp am 13.01.2012 22:00:00.

Heute wird ja auch im privaten Wohnungsbau zunehmend mit der sog. Gebäudeautomatisierung gearbeitet, man baut also keine dummen Geräte mehr ein, sondern Geräte die eine gewisse Intelligenz haben, also Geräte welche neue Funktionen nur durch eine Änderung der jeweiligen Software ermöglichen.

Das ganze hat im Zweckbau den Sinn das man mit möglichst wenig Aufwand etwas verändern kann, früher hat man für eine Treppenhausschaltung in der Elektroverteilung etwas ändern müssen, heute stellt man in einem sog. Aktor (vereinfacht gesagt ein programmierbares Relais) einfach den entsprechenden Parameter um.

Im privaten Wohnungsbau werden mit dieser Technik bevorzugt Komfortlösungen realisiert, z.B. ein Zentral-Aus Schalter neben der Ausgangstür, oder die Wetter- und Jahreszeitabhängige künstliche Beschattung von Gebäuden um Energie zu sparen.

Nehmen wir einfach mal an ein Bauherr entscheidet sich 2010 sein Gebäude mit derartiger Technik auszurüsten, er bekommt viele tolle Geräte rein und alles wird miteinander verknüpft:

  • Die Waschmaschine erkennt ob sie beladen wurden, und startet Nachts automatisch den Waschgang.
  • Im Sommer werden Tagsüber die Rolladen automatisch gesenkt um eine unnötige Aufheizung des Gebäudes zu vermeiden, im Winter wird automatisch die Rollade aufgefahren um die Wärme der Sonne zur Unterstützung der Heizung zu nutzen.
  • Jeder Raum hat einen Raumtemperaturregler welcher verschiedene Temperaturen in Abhängigkeit von Benutzerspezifischen Parametern ansteuert, auch dies dient dem Komfort vor allem aber dem Sparen von (teurer) Energie.
Das ganze funktioniert auch, der Bauherr ist zufrieden, er spart Energie und die Frau hat Funktionen die in der alten Mietwohnung nicht vorhanden waren.

2020 hat die Familie Nachwuchs bekommen, die Tochter hat durch eine Verkettung mehr oder weniger gewollter Umstände ein Kind bekommen, der Freund der Tochter möchte auch mit ins Haus... Es verändert sich alles, die Räume werden anders genutzt, das ganze Haus muss jetzt auch Kleinkindertauglich gemacht werden usw...

Da man ja EIB / KNX im Haus hat ist dies alles kein Problem, ein Anruf bei der zuständiges Elektrofachkraft und schon kommt eine nette Person vorbei welche für Geld die gewünschten Änderungen an der Steuerung vornimmt. Doch damit fangen die Probleme der tollen Lösung an: Viele der modernen Geräte aus 2010 haben sog. Plugins benötigt, welche in die Programmiersoftware ETS eingebunden werden und auch sonst recht viel Sachen im Betriebssystem installieren. Die alte Steuerung wurde auch 2010 noch mit Windows XP programmiert, der Anbieter der Hardware hat ja versprochen das er auch für alte Produkte ein Update auf Windows 7 64-Bit und ETS4 (statt 3) anbieten wird.

Im Jahr 2020 hat aber (hoffentlich) niemand mehr Windows XP 32-Bit im Einsatz, noch dazu benötigen die alten Plugins zwingend das Microsoft .Net Framework 1.1 für welches es schon seit 2013 keinen Support mehr gibt, und welches sich auf dem neuen Notebook mit Windows 10 64-Bit nicht mehr installieren lässt.

Hat man nur 1-2 derartige Geräte die Plugins benötigen kann man die gegen einen gewissen Geldbetrag noch austauschen, hat man aber Geräte von z.b. Busch & Jäger gekauft welche sogar für viele Lichtschalter schon diese tollen Plugins benötigen kann man mal eben die komplette Installation austauschen, das gute: Die Kabel können so liegen bleiben und auch passive Komponenten wie Spannungsversorgung, Linienkoppler und Programmierschnittstelle können weiter genutzt werden.

Ich persönlich mache derartige Steuerungen / Lösungen nur für den Zweckbau, da ist es nicht so extrem Schlimm wenn ich nach 10 Jahren ~5 Touchpanels a 1500€ austauschen muss weil diese derartige Plugins benötigen. Im Zweckbau erschlage ich auch 90% meiner Anforderungen mit Hardware für die ich keine Plugins brauche, aber im privaten Wohnungsbau dürfte das Gespräch zwischen Bauherr und Elektrofachkraft ähnlich Emotional werden wie eine Diskussion über das Bedingungslose Grundeinkommen.

Daher folgender Richtwert: Vermeide Geräte in der Gebäudeautomatisierung mit EIB / KNX wenn diese Plugins brauchen, und es Alternativen gibt welche die gleichen Anforderungen erfüllen können, das sorgt zum einen für mehr Druck bei den Herstellern die derartigen Müll an Kunden verkaufen möchten, und spart einem im besten Fall in 10 Jahren viel Erklärungsarbeit bei einem Kunden der dafür einfach kein Verständnis hat ;-)

Zusätzlich Gerät, je mehr von einem bestimmten Gerät man verbaut, desto weniger Interesse hat man daran das man für dieses Gerät Plugins braucht!

Symbolische Verknüpfungen unter Windows

geschrieben von encbladexp am 02.11.2011 16:30:00.

Bei uns im Unternehmen wir von der Firma Hager die Software Tebis Visualisierung verwendet. Mal abgesehen davon das die Usability grausam ist gibt es mir dieser Software auch noch 2-3 lustige Bugs bei denen man sich eigentlich an den Kopf fassen muss.

Heute durfte ich z.B. feststellen das Hager bzw. der Entwickler dieser "tollen" Software, wann immer es möglich ist absolute Pfadangaben verwendet. D.h. man verlinkt in einem Projekt eine Grafik, und diese wird mit dem Absoluten Pfad in einem proprietärem Format verlinkt.

So lange man das Projekt an dem Ort lässt wo es ist gibt es kein Problem, allerdings ist das Projekt nur ein Ordner mit einem Haufen .mdb und anderen Dateien drin, u.a. auch meine schönen Grafiken.

Die Konsequenz ist das beim verschieben des Projektordner von der Visualisierung keine Grafiken mehr gefunden werden, den diese wurden ja unter Verwendung der absoluten Pfadangabe gespeichert. Dieser Pfad passt jetzt aber nicht mehr, und somit kann auch die verlinkte Datei nicht geöffnet werden.

Selbst wenn man das Projekt im Installationsverzeichnis belässt hat man ein Problem sobald man auf dem einen System 64-Bit und auf dem anderen 32-Bit Windows verwendet. Den 32-Bit Windows verwendet für 32-Bit Anwendungen c:\Programme\ während aber ein 64-Bit Windows hierfür C:\Programme (x86)\ verwendet. Den Installationspfad kann man aber nur als Administrator ändern, keine gute Voraussetzung in großen Firmen.

Ich habe mich daher entschieden das Problem mit, auch unter Windows vorhandenen, symbolischen Verknüpfungen (Softlinks) zu lösen.

Folgendes genügt hierzu, man benötigt aber auch hier eine Shell mit Administratorrechten (cmd.exe und dann Als Administrator ausführen):

mklink /d "C:\Program Files\Hager Tehalit\" "C:\Program Files (x86)\Hager Tehalit"
Und schon können auch derart kaputte Programme ihre Daten an dem verlinkten Ort im System finden.

Schöner wäre es wenn die Software entweder relativ auf das Projektverzeichnis verlinkt, oder aber die verlinkten Grafiken direkt importiert und somit der Dateiname keine Rolle mehr spielt.

Windows Update - Der engültige Proxy Fail

geschrieben von encbladexp am 28.04.2011 21:33:00.

Windows ab Vista hat ja (endlich) ein neues Windows Update spendiert bekommen. Die veraltete Browseroberfläche wurden durch ein neues Programm ausgetauscht das sowohl von der Benutzbarkeit als auch vom sonstigen Verhalten, deutlich verbessert wurde.

Leider ist mir damit auch aufgefallen das man damit keinen Proxy mehr verwenden kann der eine Authentifizierung erfordert, das hat mit dem alten Tool nämlich noch prima funktioniert. Ich vermute Microsoft hat sich gedacht das nur große Firmen nen Proxy mit Authentifizierung haben, und diese ja sowieso WSUS haben.

Entweder fehlt diese Funktion wirklich, oder Proxy Auth ist schon sowas von 1980 das es einfach keiner aus mir mehr braucht :-/

Übrigens sind auch etliche andere Programme zu blöd einen Proxy mit Authentifizierung zu verwenden, dazu gehören auch gängige Security Albträume wie z.b. Adobe Flash oder auch der gute alte Adobe Reader!

Netzlaufwerk Drama

geschrieben von encbladexp am 01.04.2011 17:53:00.

In der Firma für die ich Hauptberuflich tätig bin haben wir normalerweise Windows XP Professional auf den Clients installiert, allerdings haben wir neue Notebooks (Tablets) bekommen, welche natürlich mit Windows 7 Professional 64-Bit verwendet werden. Dies hat vor allem den Grund das wir Techniker unsere Geräte in der Regel 5-6 Jahre lang nutzen, und wir natürlich vor haben mehr als 4GB Arbeitsspeicher zu verwenden. Gleichzeitig benötigen wir viele Rechte auf den Geräten, weshalb hier eine sog. Standalone Installation gemacht wurde, bei welchem das Gerät ohne Anbindung an die Domäne verwendet wird.

Zum Datenaustausch mit den anderen Clients ist es natürlich erforderlich das man auch ab und an auf die Netzlaufwerke zugreifen kann, was technisch eigentlich kein Problem sein sollte aber in unserem Fall sehr viel Zeit gekostet hat.

Problem war das Windows 7 die zuvor verbundenen Netzlaufwerke nicht mehr verbinden wollte und idr. sogar den Domänenaccount gesperrt hat mit welchem die Laufwerke zuvor verbunden wurden. Das ganze kommt daher das Windows die Anmeldung an Netzlaufwerken in einer bestimmten Reihenfolge durchgeht, was natürlich in unserem Fall zu den oben genannten Problemen führte.

Aber natürlich habe ich auch dafür wie auch für alle anderen Probleme eine Lösung gefunden (*scnr*).

Man sollte folgende Bedingungen beachten, damit das auch wie bei mir funktioniert, es ist übrigens keine Lösung sondern eigentlich eher ein Workaround für ein etwas komisches Betriebssystem:

  1. Lokaler Benutzername darf nicht der gleiche sein wie der von der Domäne
  2. Lokales Benutzerpasswort muss das gleiche sein wie das von der Domäne
Punkt 1 hat den Grund das Windows nicht einfach HOSTNAME\username probiert und damit in sehr kurzer Zeit beim durchprobieren den Account der Domäne sperrt. Punkt 2 wird benötigt damit Windows nicht das lokale Benutzerpasswort probiert, wenn man einige Shares hat wird auch hier ruckzuck der Domänenaccount gesperrt.

Das war der erste Teil, der nächste ist es auf fest eingebundene Netzlaufwerke zu verzichten und diese bei Bedarf mit einem Script (darf man das unter Windows so nennen?) zu Verbinden. Folgendes habe ich zum Verbinden verwendet:

@echo off
echo "Verbinde Laufwerk T:..."
net use T: \\server\sharet /USER:DOMAIN\username /PERSISTENT:NO
pause
Und nachfolgendes um die Verbindung der Netzlaufwerke wieder zu trennen:
@echo off
echo "Trenne Laufwerk T:..."
net use T: /DELETE
pause
Die pause am Ende habe ich nur gemacht damit man die Ausgabe vom Terminal im Fehlerfall lesen kann und weis warum es nicht geklappt hat.

Windows nimmt in diesem Fall den im Script Angegebenen Domänenuser als Benutzer und das lokale Passwort zur Authentifizierung, d.h. man muss ab jetzt einfach nur das lokale Passwort ändern wenn sich das Domänenpasswort geändert hat und schon funktioniert das Verbinden zu den Laufwerken wieder.

Mir ist es übrigens Schleierhaft warum Windows einfach mal so verschiedene Kombinationen aus Username/Domain/Password probiert anstatt einfach zu Fragen wenn man das Passwort eben nicht speichern wollte. Auch konnte ich hierzu keine Einstellung in der Registry finden, vermutlich an einem anderen Ort versteckt oder ich bin wirklich der einzige wo mit diesem Verhalten ein Problem hat.

Kurztipp: Datendurchsatz auf der Shell für dd & Co

geschrieben von encbladexp am 15.02.2011 18:41:00.

Häufig hat man das Problem das man nicht weis wie lange den ein dd noch brauchen wird um die Platte zu spiegeln, oder wie schnell der Datentransfer via netcat überhaupt läuft. Genau hierfür wurde das kleine Tool pv geschrieben welches den Datendurchsatz von pipes messen kann.

Ich selbst muss leider gestehen das ich dieses prima Tool bis letzten Sonntag noch nicht mal kannte und eher zufällig von guten bekannten davon erfahren habe.

pv ist bei Ubuntu im universe, bei Debian im main und bei Arch im community Repository zu finden. Es benötigt nur wenige KByte auf der Festplatte und ist daher auf jedem System verwendbar.

Ich werde hier nicht die Manpage 1:1 runterleiern und nur die 2 häufigsten Verwendungsarten anschneiden, welche man im täglichen Alltag verwenden dürfte.

Das eine ist ein Ersatz für das gute alte cat welches wohl jeder Leser dieses Blog kennen dürfte:

pv dateiname | nc -w 1 serveradresse portnummer
Hier erkennt pv selbständig wie groß dateiname eigentlich ist und baut einen schönen Ladebalken damit der anzeigt wie lange der Transfer bzw. die Verarbeitung noch dauert. Bei Special Files wie z.b. named Pipes oder einfach nur Device Files wird dies natürlich nicht gehen und man sieht nur einen Balken der hin und her wandert, wie man es von zahlreichen grafischen Oberflächen gewöhnt ist.

Die andere Variante hängt Inline in der Pipe und zeigt natürlich die gleichen Daten an:

cat dateiname | pv | nc -w 1 serveradresse portnummer
Nachteilig ist natürlich das man hier nicht sieht wie lange der Transfer noch dauert, was logisch ist da über die Pipes ja keine Größeninformationen ausgetauscht werden. Wenn man natürlich weis welche Datenmenge übertragen wird kann man das pv mit auf den Weg geben:
cat dateiname | pv -s 200m | nc -w 1 serveradresse portnummer
Und schon hat man wieder den schönen Ladebalken, wenn man Sachen natürlich zuvor durch ein Kompressionstool wie gzip,bzip2 oder xz jagt ist der Ladebalken natürlich bestenfalls ein Schätzeisen im Glastkugelmodus.

Es gibt noch einige zusätzliche Schalter in der Manpage von pv, doch die wird man eher selten benötigen ;-)

Mit Windows XP von VirtualBox nach KVM

geschrieben von encbladexp am 22.08.2010 15:07:00.

Lange Zeit habe ich VirtualBox als Virtualisierung, auch gerne auf Servern, verwendet. Dies hatte vor allem den Grund das VirtualBox schon 2007/2008 viele Funktionen hatte die ich bei KVM noch vermisst habe. Insbesondere libvirt steckte damals ja noch in den Kinderschuhen.

Das hat sich meiner Meinung nach deutlich verbessert, gleichzeitig versuche ich Aufgrund der aktuellen Ereignisse Oracle Produkte wenn möglich und sinnvoll zu vermeiden.

Aktuell verwende ich auf meinen Server noch Debian Lenny, welches leider ein KVM verwendet das mir viel zu alt ist. Gut das es in den Backports schon wesentlich neuere KVM Versionen gibt!

Da die Installation natürlich 1:1 in vielen Wikis erklärt wird gehe ich darauf nicht weiter ein, stattdessen hier noch ein Tipp wie man Windows Gäste von VirtualBox auf KVM portiert.

Zuerst sollte man alle Snapshots löschen und auch die VirtualBox Gasterweiterungen deinstallieren, ein Backup sollte ohnehin immer erstellt werden bevor man "mal eben" die Virtualisierung austauscht.

Der nächste Schrift ist eine Konvertierung der virtuellen Platte, welches mit diesem Befehl erledigt werden kann:

VBoxManage clonehd --format RAW datei-alt.vdi datei-neu.img
Man sollte dabei beachten das eine 40GB große Platten dann auch wirklich 40GB an Platz benötigt und das VirtualBox für diese Konvertierung einiges an Zeit benötigen kann.

Der erste Start mit KVM funktioniert mit dieser Platte dann erstmal prima, aber man sollte unbedingt noch folgende Keys in der Registry vom Windows auf 4 stellen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Processor\Start
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Intelppm\Start
Den zweiten Key gibt es nicht auf jedem System. Nach einem reboot und der erneuten Produktaktivierung sollte nun alles wieder wie gewohnt funktionieren.

Laufwerk D

geschrieben von encbladexp am 08.04.2010 18:04:00.

Viele von euch haben bestimmt schon mal einen Rechner in der Standardkonfiguration gesehen wie ihn so manche Hersteller ausliefern.

Ist euch dabei eigentlich schon mal aufgefallen das es meistens ein Laufwerk D gibt, welches sehr gerne als Daten oder Sicherung beschriftet ist? Ich finde das von den Herstellern sehr Verantwortungslos!

Folgende Gründe möchte ich hierfür nennen:

  • Viele Anwender denken das jedes Icon ein extra Laufwerk ist, so werden auf diese Partition dann auch Datensicherungen gemacht. Geht die Festplatte kaputt ist somit auch das Backup hinüber.
  • Programme die auf diese Partition installiert werden funktionieren nachdem man das Betriebssystem neu installiert hat auch oft nicht mehr da wichtige Einträge in der Systemregistrierung fehlen.

Das wollte ich nur mal gesagt haben...

Dell geht auf Nummer sicher

geschrieben von encbladexp am 09.07.2009 23:42:00.

Dell geht wohl in Zukunft auf Nummer sicher und sorgt dafür das man sowohl Windows XP in der Ubuntu 8.04 Variante bekommt, also auch eine Möglichkeit auf Windows 7 upzugraden.

Auf der anderen Seite kann es natürlich sein das Dell mal wieder beim Marketing gepennt hat. Irgendwie hatte Dell noch nie Glück mit Ubuntu, welches am Anfang schon mal als Windows XP verkauft wurde. Aber auch Windows 8.04 hatten die schon mal im Angebot ;-)

Unterordner im Offlineordner

geschrieben von encbladexp am 21.05.2009 10:43:00.

Windows hat ja so ne Prima Funktion mit dem Namen Offline Dateien, gemeint ist damit eine Synchronisation mit Netzwerkfreigaben. Man kann also (soweit die Theorie) sagen das man gerne das Laufwerk //server/share Offline haben möchte (oder nur einen Unterordner davon). Sobald man wieder an das Netz geht wird automatisch alles abgeglichen!

Soweit wie gesagt die Theorie, hat man aber in //server/share nur Dateien drin und legt jetzt während z.B. das Notebook Offline ist nen Ordner mit Dateien drin an (was man halt so normalerweise mit Ordner macht) bekommt Windows nichts davon mit (klar, erst Online gehen sonst macht es ja keinen Sinn).

Gab es aber in dem Share schon nen Ordner, wir man gefragt ob man alle Unterordner auch Offline haben will!

Damit automatisch alle Unterordner von Offlineordner abonniert werde kann man aber (ganz einfach) mit regedit ein wenig was an der Registry verändern:

  1. Diese Baum aufklappen (fehlt was dann anlegen!):
    1. HKEY_LOCAL_MACHINE
    2. Software
    3. Policies
    4. Microsoft
    5. Windows
    6. NetCache
  2. Hier einen Key mit vom Typ DWORD anlegen der den Namen AlwaysPinSubFolders hat.
  3. Nun kann man diesem Key einen Wert geben:
    • 0 » Windows wird (sollte) Nachfragen ob Unterordner auch abonniert werden sollen.
    • 1 » Windows abonniert automatisch alle Unterordner (mein Favorit!).

War doch eigentlich ganz Simpel und genau so wie man es erwartet!

Linux nicht reif für den Desktop?

geschrieben von encbladexp am 19.05.2009 00:24:00.

Unter linuxfonts.narod.ru findet man Gründe warum Linux nichts für den Desktop ist, zumindest nicht im Moment.

Nun, einige Punkte mögen Stimmen, aber andere werden einfach nur gepusht damit man mal wieder was zu jammern hat ;-)

Das ganze fängt schon recht Lustig mit dem Punkt 0 auf dieser Seite an. Soll das ein Witz sein? Komplizierte Software die Spiele und Datenbanken werden immer Closed Source sein? Sehr komische Einstellungen welche die da haben! Den Datenbanken gibt es genug im OpenSource Bereich, man denke nur mal an MySQL oder noch eher PostgreSQL! Klar, bei Spielen ist aktuell die Entwicklung noch nicht so Stark, aber auch hier hat sich die letzten Jahre einiges getan!

Der Punkt 1 fällt mal wieder so richtig über das so schlechte Soundsystem von Linux her. Nur warum? Sound ist im Gegensatz zu dem Stand vor einigen Jahren nicht mehr das große Problem unter Linux. In 90% der Fällen läuft alles Out-Of-Box! Und dafür das irgendwelche alten und Proprietären Programme von PulseAudo, ALSA & Co noch nichts gehört haben können wir nun wirklich nichts! Wenn Microsoft mal eine Schnittstelle über den Haufen wird heult den alten Programmen ja auch keiner hinterher.

Punkt 2 geht mal wieder an X11, war ja klar. Eigentlich dachte ich das dies der Schwachpunkt an Linux schlechthin wäre, aber so kann man sich täuschen. Wir haben keine guten APIs für GUI Programmierung? Nein, Qt und Gtk+ ändern natürlich alle 3 Monate komplett ihre Schnittstellen. So langsam frage ich mich da schon wer da Recherche Betrieben hat (oder was der dabei gesoffen hat). Auch ist GUI laut dem Autor sehr langsam und nur an wenigen Stellen beschleunigt. Von Double-Buffering weiß ein Linux User angeblich auch nichts.

Punkt 3 geht mal wieder an die Distributoren. Den jeder Kocht hier sein eigenes Süppchen was Konfiguration, Installation, Softwareverwaltung und Updates angeht. Hier wünscht sich der Autor ein einheitliches System, und der nervige Dreisatz ist für User auch eine Zumutung. Ist das wirklich so? Nun, kaum ein normaler Office & Internet Anwender wird wohl jemals ein Paket selbst kompilieren müssen. Das machen in der Regel nur Leute die eine spezielle Version brauchen die noch nicht in den Paketquellen ist, oder welche wo einfach nur Featuregeil sind. Was der Author aber verschweigt ist das es auch unter Windows kein einheitliches Installationskonzept gibt, zumal man unter Windows ja schon genug Probleme hat eine Software wieder sauber aus dem System zu bringen. Eine Zentrale Architektur um alle installierte Software zu aktualisieren gibt es bei Microsoft ja immer noch nicht ;-)

Punkt 4 erwartet das es doch bei einem modernen Betriebssystem möglich sein muss alles über eine GUI zu erledigen. Dieser Wunsch wird von vielen "Fachzeitschriften" immer wieder mal abgedruckt. Dabei wird aber oft vergessen in welchem Fall man mal als normaler User wirklich ne Shell braucht. Auch wird verschwiegen welche Vorteile das eine Shell in verschiedenen Szenarien hat (Serverkonfiguration, Replikation, ...). Das man unter Windows bestimmte Sachen nur durch Setzen von Umgebungsvariablen oder Registry Keys erreicht juckt ja mal wieder niemanden.

Punkt 5 ist mal wieder ein Hard und Softwarerundumschlag. Zum einen fehlen die Treiber (die für Windows ja auch der Hersteller liefert) zum anderen wird kritisiert das Windows Programme und Spiele ja nicht unter Linux gehen. Selbst Schuld wenn der Softwareanbieter die Software nur für eine Proprietäre Schnittstelle aus dem Hause Microsoft anbietet. Linux ist mal wieder nicht reif für den Desktop weil Hersteller keine Standards einhalten? Linux ist schuld weil es GDI-Drucker gibt?

Punkt 6 ist mein Liebling, da wird auf Regressionen im Kernel eingegangen. Es gibt dem Autor zu folge zu wenige Regressionstests bei der Entwicklung vom Kernel. Selbst in der Geschichte von Microsoft gab es und gibt es Regressionen (MS-IIS und Unicode lässt Grüßen). Auch wird verschwiegen das diese Regressionen recht schnell gefixt werden, bei anderen Herstellern von Betriebssystemen ist sowas nicht selbstverständlich. Man kauft halt neue Hardware, was solls.

Punkt 7 könnte man eigentlich auch unter Punkt 6 schreiben, hier geht es um Bugs die schon ewig (10 Jahre usw...) offen sind, etliche Duplikate haben aber einfach nicht gefixt werden wollen. Ist sich der Autor sicher das es wirklich Bugs sind? Langsam zweifle ich an dessen Verstand... unter Windows gibt es auch (fragt google) lange Listen von Fehlern und wie man diese Umgehen kann. Dort nennt man sowas aber nicht Bug (wird ja eh nicht alles öffentlich dokumentiert) sonder man spricht von einer Unzulänglichkeit für die es ein Workaroung gibt.

Punkt 8 geht auf die Zusammenarbeit der verschiedenen Programme ein, gut den Punkt lasse ich mal wirklich zählen. Aber auch hierfür gibt es mittlerweile Standards wie die von freedesktop.org! Aber bei Punkt 8.1 muss ich mir an den Kopf fassen: Most distros don't allow you to easily set up a server with e.g. such a configuration: Samba, SMTP/POP3, Apache HTTP Auth and FTP where all users are virtual. Das sich aber easy und diese Arten von Server schon fast Gegenseitig ausschließen wird vergessen. Klar, Samba kann man ja schon mit GUIs machen. Aber wer bitte schön tut sich freiwillig eine Unflexible GUI an um einen Apache zu Konfigurieren? Oder gar einen Mailserver *grusel*.

Punkt 9 ist auch ein Brüller. Hier geht es darum wie langsam doch Linux ist. Als Beispiel wird OpenOffice genannt, welches unter Windows ja viel viel schneller als unter Linux ist. Aber auch nur wenn man den Autostart verwendet (steht so aber nicht im Artikel). Und der Linker von Linux ist lahm, aber es wird vergessen das dieser Problemlos mehre Versionen einer Library nebeneinander dulden und Verwalten kann. Wer das schon mal unter Windows versucht hatte weis was man da vor sich hat! Auch das nicht Verzögerte Laden von System Diensten wird stark kritisiert, aber warum? Wenn ich meinen Desktop sehe will ich damit was arbeiten und nicht erst noch 5 Minuten warten bis die Festplatten-LED sich wieder beruhigt hat. Die Bootzeit von Linux wurde in den letzten Jahren immer wieder mal überarbeitet! Aber der Brüller bei diesem Punkt ist das Linux sehr lange braucht bis es sich endlich mal heruntergefahren hat. Ich habe mal nachgemessen, mein Linux braucht ca. 21 Sekunden für einen Shutdown. Auf der gleichen Maschine benötigt ein Windows XP je nach Lust und Laune (Solarstürme als Ursache?) gerne mal 90 Sekunden, ab und an auch mal nur 30.

Punkt 10 geht auf die Fehlermeldungen ein, ein Knaller wie ich finde. Lustige Fehlermeldungen kennt man ja von Windows mehr als genug :-D

Punkt 11 geht auf die schlechte Dokumentation ein, natürlich wurde in der Windows Welt jeder Registry Key und Button schön Dokumentiert. Warum man bei vielen Knöpfen aber mit der Direkthilfe keine Hilfe bekommt kann mir irgendwie keiner so richtig erklären.

Punkt 12 kümmert sich um das Sicherheitsmodell von Linux, welches ja sehr fragwürdig ist. Auf diesen Punkt gehe ich jetzt einfach mal nicht weiter ein, sonst wird dieser Blog Eintrag länger als Harry Potter.

Punkt 13 hat es mit der Abwärts- und Aufwärtskompatibilität zu tun. Also Abwärtskompatible kenne ich, das geht bei vielen Sachen ganz prima egal welches OS man hat. Aber die Behauptung das sogar noch viele Windows 95 noch prima unter Windows 7 laufen wage ich doch Stark zu bezweifeln! Aber was ist eigentlich eine Aufwärtskompatibilität? Sowas habe ich bei Software bisher noch nicht gesehen, den fast jede Software die ich kenne Konvertiert Daten in das neue Format, nicht aber wieder zurück in das alte Format.

Punkt 14 (Sie haben Ihr Ziel erreicht!) geht auf Probleme einer Einheitlichen Zentralen Verwaltung ein. Das aber eine Einheitliche Policy kaum alle Probleme Lösung kann wird verschwiegen ;-)

So, ich habe fertig. Meiner Meinung nach wäre es wirklich schade wenn jemand den Mist von diesem Autor auch noch ausdruckt. Futter für die doofen könnte man sagen, den genauso schlecht wie ich Argumentiert habe wurde auch in dem verlinkten Artikel Argumentiert. Wenn man einen Fehler sucht, dann wird man auch einen Finden könnte man wohl meinen. Den viele seiner Argumentationen bzw. Behauptungen kann man mit nur 3 anderen Wörtern auch auf Windows oder sogar Mac OS X anwenden.

Merkeregel: Wer im Glashaus sitzt sollte nicht mit Steinen werfen (welche ein Ironie wenn man an Windows dabei denkt).

Fazit

Linux nicht reif für den Desktop? Ist es nicht eher andersrum? Ich denke eher das die Hardwarehersteller und die User nicht bereit sind für Linux. Den viele Suchen eine Alternative zu Windows, und genau das ist auch das Problem. Die Leute sollen keine Alternative zu Windows Suchen wo genauso ist wie Windows, die Leute müssen einfach mal kapieren das Linux und Windows 2 Unterschiedliche Betriebssystem sind. Linux soll und will kein Windows sein, dafür gibt es schon ReactOS.