Hallo Besucher, der Thread wurde 16k mal aufgerufen und enthält 23 Antworten

letzter Beitrag von Kongo-Otto am

Ein Mac Noob fragt

  • Hallo,


    ich arbeite teilweise an einem Mac Mini auf der Arbeit. Installiert ist Mavericks. Der Mac ist Mitglied in der Windows-Domäne, was schon ziemliches Gewürge war. Ich habe jetzt ein Problem mit den Passwörtern. Auf der Arbeit kann ich niemanden fragen, weil die Admin-Kollegen nur Windows können. Ich melde mich mit einem Passwort lokal am Mac an. Wenn ich auf mein Windows-Home-Share zugreifen will, muss ich mein Domänenkennwort benutzen. Wenn ich den Browser öffne, fragt mich der Kasten nach einem weiteren Passwort (ich glaube das ist dieser Schlüsselbund). Ergo: Ich habe jetzt drei Passwörter mit denen ich herum jongliere. Ich finde irgendwie keinen Weg, die Passwörter auf eins zu vereinen. Mir würde schon helfen, wenn ich mein lokales Mac-Kennwort auf das Domänen-Kennwort setzen könnte. In den Systemeinstellungen habe ich eine Einstellung für Passwörter gefunden, aber das Ändern klappt nciht, weil ein Server (welcher?) nicht gefunden werden könne. Ich vermute, dass der Mac das Domänenkennwort setzen will. Mir fällt gerade ein, ob es mit passwd in der Konsole klappen könnte, um das lokale Passwort zu ändern?


    Dann bräuchte ich noch einen Tipp. Ich arbeite oft aus dem Homeoffice heraus und würde dann gerne auch den Mac remote nutzen. Soweit ich verstanden habe, kann OS X von Haus aus nur VNC als Remoteverbindung. Allerdings ist VNC per Policy bei uns verboten. Erlaubt ist nur Remote Desktop nach microsoftscher Lesart. Ich finde aber nur Remotedesktop Clients für den Mac. Ich kenne von Linux her xrdp. Ich wundere mich nur, warum niemand das für den Mac portiert hat. Gibts da noch was besseres?

  • Zu ersterem Problem kann ich leider nicht gross helfen, aber wenn beim Browser ein Login verlangt wird: Ist deine Startseite eine Intranetseite? Es kann sein, dass der Zugriff eben Domänenlogin-Zugriff benötigt. Ist z.B. auch der Fall, wenn ich vom Mac oder iPad auf SQL Reporting Server zugreife.


    Zum zweiten Problem: Einen RDP Client hast du auf dem Mac mit MS Office 2011 dabei oder auch im Mac App Store. Aber AFAIK nur als Client, also com Mac aus nach Windows. Ob der Zugriff auch vom PC aus nach Mac funktioniert, weiss ich nicht, vermutlich nicht.


    TeamViewer lässt sich bei der Vollversion unter Windows als VPN Server einrichten, so kann man von z.B. zuhause aus auf einen Server/PC per TeamViewer zugreifen. Ob das die Mac Version auch kann, weiss ich leider nicht. Edit: Sollte gehen: klickmich


    Das Problem wird aber auch sein, dass dir die IT den Zugriff/Ports etc. von aussen erlaubt/einrichtet. Ohne VPN ist das eher kaum der Fall. TeamViewer als VPN Server kann das zwar umgehen, wenn's nicht aktiv blockiert wird, aber das könnte auch sonst schon Ärger geben, wenn Du das ungefragt machst.

  • Ich melde mich mit einem Passwort lokal am Mac an. Wenn ich auf mein Windows-Home-Share zugreifen will, muss ich mein Domänenkennwort benutzen. Wenn ich den Browser öffne, fragt mich der Kasten nach einem weiteren Passwort


    Ich kenne mich mit Windows-Domänen nicht aus – glücklicherweise habe ich damit nichts zu tun. Normalerweise ist das Schlüsselbund-Kennwort am Mac identisch mit dem Anmeldepasswort und der Schlüsselbund kann anderen Anwendungen spezifische Passwörter zukommen lassen (und sie sogar generieren). Leider weiß ich nicht, was ein Windows-Home-Share ist – wird darauf per Finder, per Browser oder mit einer Microsoft-Anwendung vom Mac aus zugegriffen? Safari legt z.B. einmal angelegte Passwörter auf Wunsch im System-Schlüsselbund ab und kann danach die Anmeldung automatisieren. Andere Programme können sich, so sie denn den Mac OS Schlüsselbund unterstützen, ähnlich komfortabel anmelden.


    In den Systemeinstellungen habe ich eine Einstellung für Passwörter gefunden, aber das Ändern klappt nciht, weil ein Server (welcher?) nicht gefunden werden könne.


    Hast du irgendwo (versehentlich) einen Schlüsselbund-Server aktiviert? Das muss meines Wissens ein externer Mac-OS-X-Server sein, den du nicht hast. Du willst ja nur deine lokalen Schlüssel bearbeiten. Zum Bearbeiten deiner Schlüssel rufst du am Besten die "Schlüsselbundverwaltung" auf. Am leichtesten, wenn du die ersten Buchstaben einfach in Spotlight (Cmd-Space) eingibst.


    Allerdings ist VNC per Policy bei uns verboten. Erlaubt ist nur Remote Desktop nach microsoftscher Lesart


    Dann ist das einfach zu beantworten. Ein Mac kann natürlich nicht mit MS Remote Desktop gesteuert werden – ist ja kein Windows. Es gibt nur einen Client von MS für dieses proprietäre Protokoll, um mit dem Mac den Windows-Rechner zu steuern. Bei Apple kommt VNC zum Einsatz oder gerne auch Team-Viewer – aber das ist bei euch ja nicht erlaubt.

  • TeamViewer lässt sich bei der Vollversion unter Windows als VPN Server einrichten, so kann man von z.B. zuhause aus auf einen Server/PC per TeamViewer zugreifen. Ob das die Mac Version auch kann, weiss ich leider nicht. Edit: Sollte gehen: klickmich


    Danke für den Tipp, aber Teamviewer is' nicht. Das ist so evil bei uns (Bankenumfeld), das ich es nicht erwähnt habe. Auf dem Terminalserver, bei dem ich mich über VPN einlogge (es gibt nur den Weg), "kann" ich nur mstsc aufrufen (selbst das war ein Kampf). Das heisst, um auf den Mac remote zugreifen zu können, brauche ich einen RDP-Server auf dem Mac. xrdp ist so eine Implementierung für Unix. Finde aber kein Package dafür. Selber portieren per Mac-Ports geht auch nicht wegen der Firewall. Die machen da rsync für die Sourcen und damit komme ich nicht durch die Firewall. Für die Umstellung auf HTTP habe ich ein How-To gefunden, was aber auch nicht funktioniert.


    Meine Mac-Experience ist im Augenblick etwas mau. Ich frage mich ernsthaft, wie Macs in Großunternehmen mit Windows-Infrastrukturen integriert werden sollen. Bei Apple finde ich nicht viel dazu. Gibt es professionelle Lösungen oder ist das auch alles nur halbgares Gebastel?

  • Ich frage mich ernsthaft, wie Macs in Großunternehmen mit Windows-Infrastrukturen integriert werden sollen.


    Ich kenne mich nicht aus, was diesen ganzen proprietären MS-Domänen-Kram angeht (den MS wahrscheinlich erfunden hat, um es Fremdsystemen schwerer zu machen, sich dort einzuklinken). Ich schätze, dass in Firmen und Organisationen, die nicht ausschließlich auf MS setzen und einen höheren Anteil von unixoiden Systemen (also Mac OS X, Linux, BSD ...) integriert haben (also ein heterogenes Netzwerk), nicht unbedingt (ausschließlich) auf MS-Techniken setzen, was die Vernetzung und Rechteverwaltung angeht und deshalb auch keine großen Probleme haben. Wenn man aber erstmal zu 99% auf Microsoft setzt, ist es sicherlich schwieriger, Fremdsysteme zu integrieren, zumal in solchen Firmen auch keine Expertise existiert, die das handhaben könnte (wie man ja bei euch sieht).

  • Machst du das mit der Anmeldung eigentlich, wie hier beschrieben oder gibt es da noch andere Wege?



    Zitat

    Gibt es professionelle Lösungen oder ist das auch alles nur halbgares Gebastel?


    Hier hat auch jemand Probleme bei der Integration eines Macs in eine Windows-Domäne und es konnte ihm geholfen werden. Da wurde auch ein professionelles Tool namens Admitmac (von Thursby) erwähnt, welches letztendlich aber nicht benötigt wurde.

  • Machst du das mit der Anmeldung eigentlich, wie hier beschrieben oder gibt es da noch andere Wege?


    Ja, die Variante mit der Domänenanmeldung ist in etwa der Weg. Der Unterschied ist, dass mein User auf dem Mac schon existierte und dann erst die Domänenmitgliedschaft eingerichtet wurde. Der lokale User heisst jetzt genau so, wie der der Domäne. Daher wohl das Passwort kuddelmuddel bei der Anmeldung. Mir ist nur nicht klar, wie ich beiden Passwörter synchronisieren kann.

  • Hast du irgendwo (versehentlich) einen Schlüsselbund-Server aktiviert? Das muss meines Wissens ein externer Mac-OS-X-Server sein, den du nicht hast. Du willst ja nur deine lokalen Schlüssel bearbeiten.


    Wie kann ich das wieder deaktivieren, wenn ich das gemacht haben sollte?

  • Wie kann ich das wieder deaktivieren, wenn ich das gemacht haben sollte?


    Ich habe mich da wohl falsch erinnert. Es gibt anscheinend keinen Schlüsselbund-Server (mehr?). Meine Antwort dahingehend war also Grütze. Aber wenn es Probleme beim Setzen des Kennworts gibt, hilft evtl. dieser Tipp?

  • Das heisst, um auf den Mac remote zugreifen zu können, brauche ich einen RDP-Server auf dem Mac.


    Also MacOS hat einen VNC Server integriert. Kannst du in den Systemeinstellungen unter Sharing aktivieren.
    Dann kannst du von einem Windows-Rechner mit jedem VNC-Client (TightVNC, UltraVNC, ...) auf den Mac zugreifen.


  • Also MacOS hat einen VNC Server integriert. Kannst du in den Systemeinstellungen unter Sharing aktivieren.
    Dann kannst du von einem Windows-Rechner mit jedem VNC-Client (TightVNC, UltraVNC, ...) auf den Mac zugreifen.


    Nö, seeeeehr unwahrscheinlich, dass es ohne VPN und Port-Freigabe von zuhause aus funktioniert. Gerade in seinem Umfeld... :whistling:
    Innerhalb des eigenen Netzwerks aber sicher eine Möglichkeit.

  • Ein paar Gedanken/Fakten zu den Beiträgen hier im Thread:


    Ein Homeshare in einer Windows-Domäne ist eine Netzwerkfreigabe, die über das Userobjekt der Domäne (Benutzerkonto) definiert wird, es gibt da im Benutzerprofil eine extra Seite auf der man unter anderem das einstellen kann. Oder man bindet das Share über ein per Gruppenrichtlinie zugewiesenes Loginscript ein. Das kann dann z.B. \\servername\user$\%username% sein, wobei auf dem Server nur ein verstecktes Share user$ mit Unterordnern existiert, die den Anmeldenamen des Domänenusers tragen.


    Alternativ zum Servernamen\user$ könnte es auch ein DFS-Name (Distributed Filesystem, eine sehr schöne Sache für die es unter Linux oder beim Mac keine Entsprechnung gibt, das ist sozusagen ein Aliasname, der dann auf das oder die (!) Server mit der bzw. den (!) Shares verweist. Der Vorteil ist, dass so ein DFS-Alias ruckzuck auf einen anderen Server bzw. NAS umziehbar ist, ohne dass man auf allen möglichen Maschinen den Pfad anpassen muss, den DFS-Alias an einer Stelle zu ändern oder zu dem Alias weitere Server hinzufügen reicht. Aber das nur am Rande.) Meistens geht man dann noch her und biegt über eine Gruppenrichtlinie den Link zu "Eigene Dokumente/Bilder/...) für alle User noch auf das Homeshare um, so dass keine Userdaten auf dem PC gespeichert werden. (Bei Notebooks macht man das natürlich nicht, außer man nutzt zusätzlich die Offline-Syncronisation...)


    So ein Homeshare ist dann an jedem PC, an dem man sich anmeldet, verfügbar. Egal an welchem Platz man gerade sitzt, hat man seine eigenen Dateien. Mit "Servergespeicherten Profilen" kann man das dann noch auf die Spitze treiben, dann wird alles was der User unter "c:\benutzer\<userename>" ablegt und auf seinem Desktop ändert usw. auf einen Server syncronsiert, und wenn man sich an einem anderen PC anmeldet, wird das von dort auch dahin syncronsisiert und man bekommt exakt die gleiche Arbeitsumgebung einschließlich Fensterfarben, Desktopverknüpfungen und was auch immer! (Auf den PCs muss nur überall die gleiche Software installiert sein, was aber über "Zentrale Softwareverteilung" auch kein Problem ist. Sowas gibts von Microsoft (System Center) oder von Drittanbietern (Empirum von Matrix42, OCS-Inventory (Opensource!), usw.)


    xrdp ist ein Paket, was es für OS-X garnicht geben kann, das sagt einfach schon die Logik, denn das "x" in xrdp weist auf das X-Window-System hin, auf dem alle grafischen Oberflächen unter Linux und anderen Unixen (derzeit noch) basieren, xrdp ist ein optionaler Bestandteil von X und übrigens nur ein Wrapper von xvnc auf das rdp-Protokoll. Da OS-X, auch wenn da ein "X" im Namen vorkommt, das X-Window-System nicht als Basis für die grafische Oberfläche nutzt, gibts da auch kein xrdp. (X-Anwendungen können bekanntlich unter OS-X allerdings dennoch genutzt werden, weil es eine X-Kompatiblitäts-Schicht für Mac-OS gibt, u.a. Open-Office/Libre-Office nutzte das sehr lange, vielleicht aktuell immer noch, keine Ahnung.). Aber nur mal kurz nach "rdp server os-x" googeln führt zu einer kommerziellen Lösung: klick


    Ich warne allerdings davor, zu "basteln", gerade im Bankenumfeld. Ein VPN ist auch kein Generalschlüssel zu einem LAN, denn das VPN endet normalerweise immer an einer Firewall, welche bestimmt, welche Protokollle sie durchlässt. Und dort wird auch nur das durchgelassen, was mal festgelegt wurde, wenn VNC nicht geht, dann gehts nicht. In solchen Landschaften wird die Client- und Netzwerksicherheit auf die Spitze getrieben, sogar Firewalls zwischen einzelnen Netzwerksegmenten sind keine Seltenheit. Diese IT-Abteilungen arbeiten dort - speziell im Bankensektor - mit sehr hohen Sicherheitsstandards nach ITIL, BSI usw. Dort mit Protokollen an den dort definierten Standards vorbei zu "basteln" kann ganz schnell in die Hose gehen, sprich da gibts dann irgendwelche komischen Einträge in den Firewall-Logs oder sonstigen Intrusion-Systemen und dann werden die Admins dort ganz schnell hellhörig und aktiv wie ein Ameisenhaufen wo man einen Stock reingesteckt hat. Was dir dann blühen kann, willst du garnicht wissen! Also, solche Sachen immer mit denen absprechen und sich an deren Spielregeln halten, am besten dort beauftragen und die das machen lassen, sonst ist mitunder auch der Mac ganz schnell weg. (Softwareseitig gibts ohnehin keinen Grund, unbedingt einen Mac zu benutzen, alle gängigen Business-Anwendungen auf dem Mac gibts auch unter Windows. Also, immer schön unauffällig bleiben!)


    Zur generellen Intergration von Macs in Windows-Domänen: Ich kenne die Windows-Active-Directory Funktionalität in vielen (aber trotz vieler Berufsjahre als Admin immer noch nicht in allen) Details und habe da schon vieles gemacht, erlebt und spezielle Lösungen erarbeitet (ist aber nicht mein Spezialgebiet), die es in vergleichbarer Form weder bei Unixen (auch Linux) und Mac-OS nichtmal ansatzweise gibt. Und ich entdecke deswegen immer wieder neues! Es ist wirklich erstaunlich, was man alles inzwischen in einer Domäne alles so zentral über die User/Gruppen-Verwaltung im Zusammenhang mit den AD-Gruppenrichtlinien so alles steuern kann. (Banale Beispiele: Einstellung des Proxy-Servers und Startseite auf allen Internet-Explorern auf allen Clients, zentrale Verwaltung und Zuweisung von Software-Updates (WSUS), Softwareverteilung, Lizenzen, Loginscripte, Netzlaufwerkszuweisungen (abhängig von Benutzergruppen, Standort, Organisation-Unit (OU), ...) ...) Und mit jeder Windows-Version wird es mehr, und selbst andere Softwarehersteller steuern weitere Möglichkeiten über ADMX-Plugins zur zentralen Verwaltung aus den Microsoft-Tools heraus bei, z.B. die ganzen zusätzlichen Richtlinien für virtuelle Desktops von Citrix (XenDesktop) und VMware (Horizon), selbst Google liefert inzwischen Erweiterungen, mit denen man AD-Richtlinien für Chrome und Google-Cloud-Apps in der Cloud zentral für alle User steuern kann, bei.


    In eine solche Umgebung einen Mac oder einen Linux-Rechner (selbst mit Samba 4) einzufügen, und zwar so dass er und der dort angemeldete User genau wie die Windows-Maschinen und deren User zentral administrierbar sind, dass die Gruppenrichtlinien dort genauso wie bei den Windows-PCs greifen, usw., das ist so einfach noch nicht möglich, es funktionieren Out-of-The-Box nur ein paar Basics (Domänen-Benutzer anmelden statt lokales Konto und ein bischen mehr). Das heißt für die Admins, dass sie alles was sie in einer Windows-Domäne zentral festlegen, das müssen die ein zweites oder drittes Mal auf der Mac- oder Linux-Seite nochmal mit dortigen Möglichkeiten nachbauen, mit ganz anderen Werkzeugen (z.B. Shellsprachen für Loginscripts, Satellite statt WSUS) und teils zusätzlichem Fachwissen. Deswegen sind Macs und Linux-Desktops bei den meisten Windows-Domänen-Admins ziemlich unbeliebt, weil eben diese Sonderlinge teils enorme Zusatzarbeit erfordern.


    Vielfach habe ich in solchen Umfeldern gesehen, dass wenn User unbedingt einen Mac "brauchen", aber auch Sachen in der Windows-Domäne arbeiten sollen, entweder Windows als Dual-Boot oder als virtuelle Maschine (Parallels) bekommen, oder einen virtuellen Windows-Desktop (XenDesktop, Horizon PC-over-IP), und dieses Windows ist dann vollständiges Domänenmitglied und ohne Zusatzarbeit administrierbar. Das selbe kann man natürlich auch mit Linux machen, entweder Dual-Boot, oder Windows oder Linux als virtuelle Maschine im anderen System, je nachdem was häufiger oder mit mehr Performance gebraucht wird, oder - das habe ich auch schon umgesetzt, die Linux-Maschine steht im Rechenzentrum und der User greift per (Turbo-)xVNC, xRDP oder XDMCP-over-SSH (mit OpenGL-Unterstützung der Clientgrafikkarte!) darauf zu (sozusagen ein Terminalserver). (Bitte das hier nicht als Anregung zu einer Diskussion für/wieder von Linux-Desktops oder Macs verstehen!)


    Man kann all das was die Windows Active Directory Funktionalität so leistet, ahnungslos als "proprietär" bezeichnen, da sie aber wahrscheinlich in über 90% aller Unternehmen der Standard ist, würde ich sie nicht unbedingt als Proprietär sondern als "gängige Praxis" ("Best Practise") bezeichen, zumal Microsoft an der Entwicklung von Samaba 4 mitgearbeitet hat, so dass ein Samba 4 Server all diese AD-Funktionen zumindestens als Server in der Domäne an die Clients und User ausliefern kann. Samba 4 als Client funktioniert inzwischen auch schon ganz gut, aber die meisten Gruppenrichtlinen aus der Windows-Domäne sind halt nicht auf Linux-Desktops übertragbar... Der Samba 4 Server lässt sich sogar mit den Management-Konsolen verwalten, die man bei Windows XP/Vista/7/8.x Pro als Feature (sofern der PC Mitglied einer Domäne ist) jederzeit von der Windows-CD nachrüsten kann (AD User und Gruppen, Computerverwaltung, Gruppenrichtlinien und vieles mehr!). Ein Samba 4 Server kann einen Windows Domänencontroller inzwischen zu 100% ersetzen, man muss nur wissen, wie! Damit ist zumindestens die Funktionalität (und der zusammenhängende Quellcode) mit Samba 4 "Open Source" unter GPL Lizenz, und damit ein inzwischen offener Standard. Also eigentlich keineswegs "Proprietär".

  • Wenn ich den Browser öffne, fragt mich der Kasten nach einem weiteren Passwort (ich glaube das ist dieser Schlüsselbund).

    Das kenne ich vom Mac, wenn ein Proxy mit Authentifizierung genutzt wird.

    Danke für den Tipp, aber Teamviewer is' nicht. Das ist so evil bei uns (Bankenumfeld), das ich es nicht erwähnt habe.


    Ich warne allerdings davor, zu "basteln", gerade im Bankenumfeld.

    Ich kann 1st1 da nur zustimmen: am besten die Finger davon lassen und die Leute ihre Arbeit machen, die davon Ahnung haben. Wenn man die Sicherheitspolicy in einem Unternehmen, gerade im Bankenumfeld, untergräbt, dann kann das (zu Recht) ganz schnell verdammt viel Ärger geben.

  • Man kann all das was die Windows Active Directory Funktionalität so leistet, ahnungslos als "proprietär" bezeichnen, da sie aber wahrscheinlich in über 90% aller Unternehmen der Standard ist, würde ich sie nicht unbedingt als Proprietär [...] bezeichen


    Danke für deine Ausführungen – sie waren teils sehr erhellend. Allerdings muss ich dir an dieser Stelle widersprechen, denn "propritär" und "Standard" schließen sich nicht aus. Proprietär bedeutet nicht "eigenbrötlerisch" oder "gegen den Standard", wie du vielleicht meinst, sondern "in Eigentum befindlich". Wenn MS also nicht sämtliche Rechte an Active Directory freigegeben hat (im Zuge der Samba 4 Unterstützung), dann ist der "Standard" "proprietär", womit ich mit meiner Aussage richtig läge. Und mit meiner Einschätzung, dass MS seine Marktmacht bei Betriebssystemen mal wieder missbraucht hat, um sich gegen Alternativen abzuschotten, wahrscheinlich auch. ;)

  • [offtopic]Naja, Apple hat ja auch das Apple Remote Desktop, welche ja auch kostet, und nur von/auf anderen Mac connecten kann.
    Gerade Apple macht sich unter Powerusern, die etwas offen durch die Welt gehen, unbeliebt, weil diverse Standards nicht unterstützt werden, aber eigener, propiertärer Mist "erfunden" wird, nur um das eigene, closed-Box Dogma durchzupeitschen. [/offtopic]


  • Was hat das jetzt genau mit meiner und 1st1s Aussagen zu tun? ;)


    Na, Du kannst ja nicht das RDP als propiertär und MS "Marktmacht" kritisieren, ohne auch zu sehen, dass das Äequivalent von Apple (und andere Sachen von denen) genauso closed ist und nur in den eigenen vier Macwänden funktioniert. Ich weiss, dass das ARD auf VNC basiert, aber es ist trotzdem nicht offen und verfügbar als von Apple verfügbares, installierbares Paket für Win und Linux. Immerhin: der MS RDP Client ist auch für MacOSX verfügbar, wird bei uns auch verwendet im Büro.

  • 1ST1 Vielen Dank für das Posting, aber habe nach dem ersten Absatz aufgehört zu lesen. Sorry.


    Ich bin jetzt über das hier gestolpert: http://forums.macrumors.com/showthread.php?t=1770325. Mal sehen, ob das funktioniert.


    Einerseits hast du meine Ausführugen nicht verstanden, andererseits willst du einen rdp-Server selber kompilieren. Selbst kompilierte Software aus Forenquelle in einem Banken-Umfeld, ein rdp-Server bedeutet einen offenen Port auf deinem Mac, ein Angriffsvektor für Viren, Trojaner, ... Elefant im Porzelanladen... Für mich passt das nicht so recht. Und außerdem hast du den Weblink mit einer fertigen Lösung in meinem Beitrag übersehen. Ich schlage dir vor, wenn du etwas in meinem Postig nicht verstanden hast ("Was ist eine AD-Gruppenrichtlinie?" "Was ist ein AD-Benutzerobjekt?" "Was ist ein Computerkonto?" "Was kann man mit einer AD-Gruppe anstellen und was ist das überhaupt?" ...), frage, ich erkläre es gerne.

  • [offtopic]

    Na, Du kannst ja nicht das RDP als propiertär und MS "Marktmacht" kritisieren, ohne auch zu sehen, dass das Äequivalent von Apple ...


    Tu ich ja nicht. Nur muss ich ja nicht immer, wenn ich an was an MS kritisiere, gleich noch einen Rundumschlag Richtung Apple und Google und Oracle und Amazon usw. durchführen, oder? Aber wenn du gerne möchtest:


    Du hast natürlich Recht, dass Microsoft, Apple und Google (und auch viele andere Firmen) immer lieber eigene Standards durchsetzen als sich an evtl. schon vorhandenes anzupassen oder mit anderen zusammen etwas zu definieren. Open Source wird ohnehin immer nur dann unterstützt, wenn es der Firma nutzt. Google gibt eine Technologie auch nur frei, wenn das mehr nutzt, als selber die Hand drauf zu halten. Deren Suchmaschine, YouTube, G+, GMail, Play Store, Google-Maps, Analytics, Picasa (man könnte die Liste endlos fortsetzen) und fast alle der 20 Goggle-Apps, die bei Android mitgeliefert werden müssen, sind proprietär, ClosedSource und mit Patenten abgesichert. Gerade mal das immer weiter ausgehöhlte Basis-System Android ist frei erhältlich und einsehbar. Apple nutzt zwar den BSD-Kernel, OpenGL, VNC und viele andere OS-Technologien und hat WebKit, OpenCL, Bonjour, GCD und andere OS-Technolgien auf den Weg gebracht – aber natürlich auch nur, wenn es Vorteile gegenüber proprietären Technologien bringt. MS hasst ohnehin Linux und OpenSource (Ballmer: "Krebsgeschwür") und hat seit jeher versucht, Konkurrenten (auch mit nicht ganz sauberen Methoden) nicht zum Schuss kommen zu lassen. Das ist für Unternehmen auch völlig normal – aber man muss es als Konsument erkennen und auch mal laut sagen dürfen. Windows und alle darin enthaltenen Technologien sind proprietär und werden nur gegen gutes Geld (wie z.B. bei FAT) lizenziert oder eben genutzt, um sich die Wettbewerber vom Hals zu halten. Und das ist (nur) solange erlaubt, wie man seine marktbeherrschende Stellung (oder eben Monopol) nicht gegen die Konkurrenz (in anderen Feldern) ausnutzt. In der Hinsicht ist MS schon mehrfach verurteilt, bestraft und überwacht worden. Viele Nutzer merken eben nur nicht, dass sie die ganze Zeit proprietäre Technologien nutzen, weil der Microsoft-Käfig größer ist als der von Apple – trotzdem ist Microsoft (noch mehr als Apple) vor allem zu sich selbst kompatibel.


    Kurz: Alles Schlampen (außer Mutti) und MS kackt im Desktop-Bereich immer noch den größten Haufen.


    So einen Disclaimer kann ich natürlich immer an ein Posting hängen, wenn ich den Begriff proprietär in Kombination mit Microsoft verwende. ;)
    [/offtopic]