1 Punkte von GN⁺ 2023-08-11 | 2 Kommentare | Auf WhatsApp teilen
  • Microsoft Teams hat enge Betriebsgrenzen für Teams, Kanäle, Chats, Meetings und Dateifreigabe insgesamt; für Kanalnamen dürfen keine MS-DOS-Gerätenamen wie CON, PRN, AUX, NUL, COM1~COM9 oder LPT1~LPT9 verwendet werden
  • Pro Team liegt das Limit bei 25.000 Mitgliedern, pro Benutzer bei 1.000 Team-Mitgliedschaften und pro Team bei 1.000 Kanälen; auch gelöschte Kanäle zählen während der 30-tägigen Wiederherstellungsfrist weiter auf das Limit
  • Für Chats gelten als Richtwerte 250 Personen in privaten Chats, 20 Personen für chatbasierte Sprach- und Videoanrufe, 10 Anhänge und 100 MB pro Datei; ab mehr als 20 Personen werden Funktionen wie Anrufe, Tippanzeige und Lesebestätigungen deaktiviert
  • Meetings können je nach Plan mit bis zu 300 oder 1.000 Teilnehmern veranstaltet werden; für Teams-Meetings, Webinare und Townhalls gilt ein 30-Stunden-Limit, und Breakout-Räume können nur für Meetings mit weniger als 300 Teilnehmern erstellt werden
  • Die Dateifreigabe hängt von SharePoint und OneDrive for Business ab; in Mandanten mit deaktiviertem SharePoint gibt es daher Einschränkungen, und für Teams-Dateien gelten 25 TB pro Website oder Gruppe sowie bis zu 250 GB pro Datei-Upload

Limits für Teams und Kanäle

  • Die Anzahl der Teams, die ein Benutzer erstellen kann, folgt dem Limit von 250 Objekten in Microsoft Entra ID; globale Administratoren sind von diesem Limit ausgenommen
  • Ein Benutzer kann Mitglied in bis zu 1.000 Teams sein, einschließlich archivierter Teams
  • Wichtige Limits auf Teamebene sind wie folgt
    • Mitglieder: 25.000
    • Besitzer: 100
    • organisationsweite Teams: 5 pro Mandant
    • Mitglieder in organisationsweiten Teams: 10.000
    • Anzahl der Teams in einer Microsoft-365- oder Office-365-Organisation: 500.000
    • Anzahl der Teams, die ein globaler Administrator erstellen kann: 500.000
  • Pro Team sind maximal 1.000 Kanäle möglich, einschließlich einer Kombination aus Standardkanälen und freigegebenen Kanälen sowie bis zu 30 privaten Kanälen
  • Gelöschte Kanäle können 30 Tage lang wiederhergestellt werden und zählen in dieser Zeit weiter auf das Kanal- und Privatkanal-Limit pro Team
  • Kanalbeiträge dürfen pro Beitrag etwa 100 KB umfassen; darin enthalten sind Textkörper, Bildlinks, @Erwähnungen, Anzahl der Connectors und Reaktionen
    • base64-kodierte Bilder zählen nicht zum 100-KB-Limit

Einschränkungen bei freigegebenen Kanälen

  • Freigegebene Kanäle sind pro Team bis maximal 1.000 möglich; gelöschte Kanäle werden während der 30-tägigen Wiederherstellungsfrist mitgezählt
  • Ein freigegebener Kanal kann zusätzlich zum übergeordneten Team mit maximal 50 Teams geteilt werden
  • Mitglieder freigegebener Kanäle sind bis zu 5.000 direkte Mitglieder; geteilte Teams werden bei der Limitberechnung mit einer Person pro Team gezählt
    • Echtzeit-Updates werden jeweils nur an 25.000 Personen bereitgestellt
    • In der Kanalliste werden nur 25.000 Personen angezeigt
  • Externe Teilnehmer unterstützen nur Microsoft-Entra-Geschäfts- oder Schulkonten
  • Freigegebene Kanäle unterstützen Tabs, jedoch nicht Stream, Planner oder Forms
  • Bots, Connectors und Nachrichtenerweiterungen werden in freigegebenen Kanälen nicht unterstützt
  • Organisationsweite Teams können nicht als Mitglieder freigegebener Kanäle hinzugefügt werden
  • Beim Erstellen eines neuen Teams aus einem bestehenden Team werden freigegebene Kanäle des bestehenden Teams nicht kopiert
  • Benachrichtigungen aus freigegebenen Kanälen sind nicht in E-Mails über verpasste Aktivitäten enthalten
  • Freigegebene Kanäle werden in Klassenteams nicht unterstützt

Verbotene Regeln für Kanalnamen

  • Für Kanalnamen dürfen die folgenden Zeichen nicht verwendet werden
    • ~ # % & * { } + / \\ : < > ? | ' \" , ..
  • Die folgenden Zeichenbereiche sind ebenfalls nicht zulässig
    • 0~1F
    • 80~9F
  • Die folgenden Wörter dürfen nicht in Kanalnamen verwendet werden
    • forms
    • CON, CONIN$, CONOUT$
    • PRN, AUX, NUL
    • COM1~COM9
    • LPT1~LPT9
    • desktop.ini
    • _vti_
  • Kanalnamen dürfen nicht mit einem Unterstrich _ oder einem Punkt . beginnen und nicht mit einem Punkt . enden

Messaging und Chat

  • Unterhaltungen, die in der Teams-Chatliste enthalten sind, werden im Exchange-Online-Postfach der Teilnehmer gespeichert
  • Damit Administratoren Chat-Unterhaltungen durchsuchen oder aufbewahren können, benötigen Teilnehmer ein cloudbasiertes Exchange-Online-Postfach
    • Benutzer mit On-Premises-Postfächern in einer Exchange-Hybridbereitstellung können zwar an Teams-Chats teilnehmen
    • In diesem Fall können die Inhalte dieser Unterhaltungen jedoch nicht durchsucht oder aufbewahrt werden
  • Die wichtigsten Limits für private Chats sind wie folgt
    • Personenanzahl: 250
    • Mitglieder, die auf einmal zu einem Gruppenchat hinzugefügt werden können: 200
    • Sprach- und Videoanrufe, die aus einem Chat gestartet werden: 20
    • Anhänge: 10
    • Dateigröße: 100 MB
    • Größe eines Chatbeitrags: etwa 100 KB
  • Wenn ein Chat mehr als 20 Personen umfasst, werden die folgenden Funktionen deaktiviert
    • automatische Antworten in Outlook und Teams-Statusnachrichten
    • Tippanzeige
    • Sprach- und Videoanrufe
    • Freigabe
    • Lesebestätigungen
    • Schaltfläche Set Delivery Options
  • Um die Erfolgsquote bei der Nachrichtenzustellung zu erhöhen, wird empfohlen, die eigentliche Nachrichtengröße auf 80 KB oder weniger zu beschränken
  • Mandanten mit Testabonnements können zur Missbrauchsvermeidung strengeren Messaging-Limits unterliegen; diese Limits können ohne Vorankündigung angepasst werden
  • Administratoren, die beim externen Zugriff nur vertrauenswürdige Domänen zulassen, können bis zu 4.000 vertrauenswürdige Domänen hinzufügen

Kanal-E-Mail

  • E-Mails, die an die Kanal-E-Mail-Adresse gesendet werden, werden Teil des Kanals, und jeder kann darauf antworten, um eine Unterhaltung zu starten
  • Für das Senden von E-Mails an einen Kanal gelten die folgenden Limits
    • Nachrichtengröße: 24 KB
    • Anhänge: 20
    • Größe pro Anhang: weniger als 10 MB
    • Inline-Bilder: 50
  • Bei Überschreitung der Limits ändert sich das Verhalten
    • Wenn eine Nachricht 24 KB überschreitet, wird eine Vorschau-Nachricht erzeugt, und Benutzer müssen die ursprüngliche E-Mail über den bereitgestellten Link herunterladen und ansehen
    • Wenn die Anzahl der Anhänge oder Bilder das Limit überschreitet, wird eine Fehlermeldung angezeigt
  • Für Kanal-E-Mails gilt ein Ratenlimit
    • 6 E-Mails pro 10 Sekunden und Benutzer pro Kanal
    • 8 E-Mails pro 10 Sekunden und Benutzer pro Mandant
  • Kanal-E-Mails können in Teams für Office-GCC-/GCCH-/DOD-Organisationen nicht verwendet werden

Meetings und Anrufe

  • Die Pläne Microsoft 365 Business Basic, Business Standard, Business Premium, Microsoft Teams Essentials und Microsoft 365 A1 können Teams-Online-Meetings und Videoanrufe mit bis zu 300 Teilnehmern hosten
  • In den Plänen Microsoft 365 F1/F3/E3/E5/A3/A5/G3/G5, Office 365 E1/E3/E5/A3/A5/G1/G3/G5 und Microsoft Teams EEA steigt das Limit auf bis zu 1.000 Teilnehmer
  • Wichtige Meeting-Limits sind wie folgt
    • Sprach- und Videoanrufe, die aus einem Chat gestartet werden: 20
    • maximale Größe von PowerPoint-Dateien: 2 GB
    • Zeitraum für den lokalen Download von Meetingaufzeichnungen, die nicht in Microsoft Stream hochgeladen wurden: 20 Tage
    • maximale Länge einer Meetingaufzeichnung: 4 Stunden oder 1,5 GB
  • Wenn eine Aufzeichnung die maximale Länge oder Größe erreicht, endet die Aufzeichnung und startet automatisch erneut
  • Breakout-Räume können nur in Meetings mit weniger als 300 Teilnehmern erstellt werden
    • Wenn Breakout-Räume erstellt werden, wird die Teilnehmerzahl des Meetings automatisch auf 300 begrenzt
  • Für Teams-Meetings, Webinare und Townhalls gilt ein Zeitlimit von 30 Stunden

Ablauf von Meetings

  • Der Meeting-Ablauf gilt für PSTN-Einwahlnummern, CVI-Koordinaten sowie Standard-Meetingrichtlinien und -einstellungen
  • Wenn vor dem Ablauf an einem Meeting teilgenommen wird oder das Meeting aktualisiert wird, wird das Ablauflimit — außer bei Meet-now-Meetings — um 60 Tage verlängert
  • Laut Public Preview verfallen neue Links und Meetings je nach Bedingung; nach dem Ablauf ist eine Teilnahme über den Link nicht mehr möglich
    • einmalig geplantes Meeting: 60 Tage nach der geplanten Meetingzeit
    • Meet now, geplant im Kalender oder Kanal: 60 Tage nach Erstellung des Links
    • Meet now, geplant in einem Gruppenchat: nicht zutreffend
    • wiederkehrendes Meeting mit Enddatum: 60 Tage ab Enddatum oder 60 Tage ab dem letzten Auftreten, je nachdem, welcher Zeitraum länger ist
    • wiederkehrendes Meeting ohne Enddatum: 1 Jahr nach letztem Zugriff, letzter Teilnahme oder letzter Meetingaktualisierung

Live-Events

  • Teams-Live-Events werden voraussichtlich im Juli 2026 eingestellt
    • Bereits geplante Events werden bis zum 28. Februar 2027 unterstützt
    • Microsoft empfiehlt für große digitale und hybride Events die Verwendung von Teams-Townhalls
  • Die Standardlimits für Live-Events sind wie folgt
    • Teilnehmer: bis zu 10.000
    • Eventdauer: 4 Stunden
    • gleichzeitig laufende Live-Events in einer Microsoft-365- oder Office-365-Organisation: 15
  • In dem Moment, in dem ein Produzent an einem Live-Event teilnimmt, gilt das Event als aktiv
    • Ein Produzent, der an einem 16. Live-Event teilnehmen möchte, erhält einen Fehler
  • Die vorübergehende Erhöhung der Limits wird bis auf weitere Ankündigung verlängert
    • bis zu 20.000 Teilnehmer
    • 50 gleichzeitige Events mandantenweit
    • 16 Stunden pro Broadcast
  • Über das Microsoft 365 assistance program können Live-Events mit bis zu 100.000 Teilnehmern geplant werden; das Team bewertet jede Anfrage und entscheidet über die möglichen Optionen

Speicher und Dateifreigabe

  • Jedes Teams-Team hat eine SharePoint-Teamwebsite, und für jeden Kanal wird ein Ordner in der Dokumentbibliothek der Standard-Teamwebsite erstellt
  • In Unterhaltungen freigegebene Dateien werden automatisch zur Dokumentbibliothek hinzugefügt, und in SharePoint festgelegte Berechtigungen sowie Dateisicherheitsoptionen werden in Teams übernommen
  • Jeder private Kanal verfügt über eine eigene SharePoint-Website
  • Wenn SharePoint im Mandanten nicht aktiviert ist, können Teams-Benutzer Dateien in Teams nicht immer freigeben
  • Um Dateien in privaten Chats freizugeben, ist OneDrive for Business mit einer SharePoint-Lizenz erforderlich
  • Die Dateifreigabe in Teams arbeitet auf dem SharePoint-Backend, daher gelten für den Bereich Files in Teams die SharePoint-Limits
  • Für die angezeigten Pläne gelten die folgenden Speicherlimits
    • 1 TB pro Organisation + 10 GB pro gekaufter Lizenz
    • Office 365 Enterprise F1: 1 TB pro Organisation
    • Teams Files: maximal 25 TB pro Website oder Gruppe
    • Upload-Limit: 250 GB pro Datei
  • Da Kanäle durch Ordner innerhalb der SharePoint-Website des Teams abgebildet werden, teilt sich die Registerkarte Dateien eines Kanals das Speicherlimit des zugehörigen Teams

Klassenteams für Bildung und Tags

  • Microsoft Teams for Education bietet Vorlagen für Bildungsszenarien wie Unterricht im Klassenraum
  • Für die Nutzung von Klassenteams ist eine Office-365-Education-Lizenz erforderlich
  • Klassenteams folgen dem allgemeinen Mitgliederlimit für Teams, aber für bestimmte Apps gelten separate Beschränkungen
    • Nutzung der App Assignments: 1.000 Mitglieder
    • Nutzung der App OneNote Class Notebook: 300 Mitglieder
  • Klassenteams können mehr Mitglieder unterstützen, aber wenn Assignments oder Class Notebook verwendet werden sollen, sollte man unter den oben genannten Grenzen bleiben
  • Für Tags gelten die folgenden Limits
    • Tags pro Team: 200
    • vorgeschlagene Standard-Tags pro Team: 25
    • Teammitglieder, die einem Tag zugewiesen werden können: 200
    • einem Benutzer innerhalb eines Teams zuweisbare Tags: 25

Kontakte und Browser-Unterstützung

  • Teams verwendet die Active-Directory-Kontakte der Organisation sowie Kontakte, die der Standardordner von Outlook des Benutzers enthält
  • Teams-Benutzer können mit jeder Person kommunizieren, die im Active Directory der Organisation vorhanden ist, und diese unter Chat > Contacts oder Calls > Contacts zur Kontaktliste hinzufügen
  • Auch Personen, die nicht im Active Directory der Organisation vorhanden sind, können unter Calls > Contacts als Kontakte hinzugefügt werden
  • Teams presence in Outlook wird ab der Outlook-2013-Desktop-App unterstützt
  • Die Browser-Unterstützung unterscheidet sich je nach Funktion
    • Internet Explorer 11 unterstützt keine Anrufe und unterstützt nur eingeschränkt Meetings mit PSTN-Koordinaten
    • aktuelles Microsoft Edge Chromium und Google Chrome unterstützen Anrufe und Meetings vollständig
    • Firefox unterstützt keine Anrufe, aber Meetings; für vollständige Unterstützung ist das OpenH264-Plugin erforderlich
    • Je nach Safari-Version unterscheidet sich der Unterstützungsumfang für 1:1-Anrufe, Video und Freigabe
  • Teams-Meetings im Browser sind auf einen einzelnen Stream beschränkt; angezeigt wird nur entweder das empfangene Video des aktuell Sprechenden oder die Bildschirmfreigabe
  • Um während einer Freigabe die Steuerung zu übergeben oder zu übernehmen, müssen beide Seiten den Teams-Desktopclient verwenden; im Browser wird dies nicht unterstützt

2 Kommentare

 
xguru 2023-08-11

Ich vermute, das wurde wegen der Abwärtskompatibilität mit Windows so gemacht.

Aber ich frage mich, ob heutige Entwickler überhaupt noch Dinge wie COM, LPT oder PRN kennen, haha.

Fragen wie „Warum beginnt die Festplatte eigentlich bei C?“ sieht man ja auch immer wieder ...

 
GN⁺ 2023-08-11
Hacker-News-Kommentare
  • Um 1998 herum schleppte ich als Teenager und Linux-Fanatiker meinen Linux-Rechner zu LAN-Partys mit, und das funktionierte tatsächlich ziemlich gut.
    WINE existierte damals praktisch vor allem, um Starcraft zu unterstützen, Quake 2 lief nativ, und mit diesen beiden waren 95 % der Spiele abgedeckt, die die Leute spielten.
    Einmal dachte ich, es wäre lustig, ein Shell-Skript laufen zu lassen, das alle Windows-Freigaben im Netzwerk durchgeht und CON/CON öffnet; jede Maschine zeigte sofort einen Blue Screen, und meine Freunde fanden das seltsamerweise nicht so witzig.

    • Erinnert mich an diese Zeit. Bei jedem LAN-Treffen gab es genau so einen Freund.
      Wenn er so gut beim Beheben von Netzwerkproblemen gewesen wäre wie mein BSD-Freund und immer ein paar CAT-5-Kabel als Reserve dabeigehabt hätte, hätte er das wohl locker wieder gutmachen können.
    • Lief das über IPX? Ich kann mich nicht erinnern, IPX unter Linux eingerichtet zu haben.
      Als ich Linux schon genug nutzte, um Starcraft mit Wine laufen zu lassen, hatte es meiner Erinnerung nach bereits IP-Unterstützung.
    • Ich liebe diese Geschichte. Ich wusste nicht, dass WINE schon so lange existierte und sogar Spiele wie Starcraft ausführen konnte.
      Ich habe sehr schöne Erinnerungen daran, früher mit Freunden Starcraft gespielt zu haben, und dieses Spiel hatte genug Ausdauer, dass ich in der Mittelstufe davon besessen war und an der Uni wieder hineingezogen wurde.
    • Das beste waren die Hacks, die wirklich jeder konnte: Leute auf LAN-Partys mit einem Ping Flood bombardieren.
      Gute alte Zeiten.
    • Es war ein goldenes Zeitalter. Ich weiß nicht, ob wir anders waren oder ob die Welt um uns herum anders war.
  • Das liegt wahrscheinlich daran, dass man solche Namen im Windows-Dateisystem nicht für Dateien oder Ordner verwenden kann.
    Ein MS-Teams-Kanal erstellt einen entsprechenden Ordner in SharePoint, in dem Dateianhänge gespeichert werden.

    • Microsoft scheint bei jedem Problem zu denken: „Alles klar, bauen wir das auf SharePoint.“
    • Ich arbeitete in einer Bank mit einem Windows-basierten Trading-System, das aus irgendeinem Grund Ordner mit den Details zu jedem Buch anlegte.
      Probleme gab es, als ein Trader sein Buch LPT1 nannte.
    • Ich vermute, dass es hier noch andere Schwachstellen gibt. Allerdings scheinen auch % und .. auf der Blacklist zu stehen.
    • Es wird auch eine entsprechende Active-Directory-Gruppe erstellt.
      Das ist eine sehr einfache Möglichkeit, Nutzer Zugriffsrechte auf Ressourcen verwalten zu lassen, ohne dass sie ein Support-Ticket eröffnen müssen; die Verwendung ist also ziemlich sinnvoll.
    • SharePoint hat seine Krallen tief in Microsoft geschlagen und wird für immer ihre Achillesferse bleiben.
  • Zuerst wollte ich sagen: „Leakt das nicht praktisch, dass intern irgendetwas Grauenhaftes vor sich geht? Man sollte sich schämen, so etwas öffentlich zu sagen. Das ist ähnlich wie zu sagen, man könne %s oder $PS1 nicht verwenden — warum denn nicht? Was zum Teufel macht ihr mit Nutzereingaben?“
    Aber es könnte auch darum gehen, wie Kanalnamen anderswo behandelt werden. Leute können sie überallhin kopieren und einfügen, und man kann wohl nicht erwarten, dass Windows-Nutzer ihre Strings selbst escapen, wenn sie sie in cmd, PowerShell oder WSL einfügen.
    Der Teams-Code selbst kann damit wahrscheinlich gut umgehen, aber das Problem könnten all die unbekannten, schlampigen externen Tools sein, die mit Kanalnamen arbeiten können.
    Andere haben auf den mit dem Kanal verbundenen SharePoint-Ordner hingewiesen; persönlich fällt es mir schwer, das als Entschuldigung gelten zu lassen, denn es ist einfach, für Verzeichnisse eine sichere Version durch Escaping, Umformung oder Encoding zu erzeugen. Allerdings könnte es irgendwo wichtig sein, dass Kanalname und Verzeichnisname identisch sind.
    Wenn es nur innerhalb der App verwendet würde, könnte man Kanal- und Verzeichnisnamen einfach auf dieselbe Weise encodieren/decodieren und das vor dem Nutzer vollständig verbergen. Wenn das Verzeichnis aber auch außerhalb der App genutzt wird, werden Dinge wie URL-Encoding sichtbar und sehen hässlich aus.
    Am Ende muss der Verzeichnisname für alles andere sicher sein, und deshalb muss der Kanalname es auch sein. Man hat sich also für diese Einschränkung entschieden, statt gelegentlich hässliche Verzeichnisnamen zu haben; letztlich ist es eher ein Darstellungsproblem als ein Sicherheits- oder Ausfallproblem. Weil Zeichen, die Encoding erfordert hätten, gar nicht erst erlaubt sind, sehen alle Verzeichnisse immer natürlich und ordentlich aus.

    • Wenn man einmal einen rohen DNS-NXDOMAIN-Feed aus passivem DNS (PDNS) zu sehen bekommt, findet man dort wirklich viel kaputtes Zeug, und manches davon ist ziemlich unheimlich.
      So etwas passiert, wenn Namensdienste ineinander übersetzt werden. Namensdienste haben normalerweise einen Geltungsbereich, und ein Name aus einem Kontext wird in einem anderen Kontext anders interpretiert.
      Bobby Tables ist bekannt, aber was ist mit dem speziellen Dateinamen -rf? Früher vertraute ein normaler Pfad in Active Directory bei Dingen wie Dateifreigaben DNS-Domainnamen nahezu implizit. Das sieht in Ordnung aus, bis man merkt, dass auf diesem „Laufwerk“ ausführbare Dateien liegen könnten.
      Ehrlich gesagt konnte ich die Zeichenkette MS-DOS in diesem Dokument nicht finden. Nachtrag: Verweise wie CON und LPT1 habe ich gefunden.
    • Es ist einfach eine SharePoint-Beschränkung bei Ordnernamen, die nach oben durchscheint. Nichts Besonderes.
    • „Man erwartet nicht, dass Nutzer ihre Strings selbst escapen“ — haben Nutzer irgendeines Systems jemals angefangen, diese Erwartung zu erfüllen? Wo genau befindet sich dieses utopische System?
    • AWS hat praktisch überall Zeichenbeschränkungen.
      Selbst beim Body einer SQS-Nachricht ist eingeschränkt, welche Whitespace-Zeichen verwendet werden dürfen.
    • Das ist eine SharePoint-Einschränkung. Teams basiert auf SharePoint, und das ist weder ein Geheimnis noch etwas, wofür man sich schämen müsste.
  • Warum werden die meisten Chat-/Meeting-Apps am Ende eigentlich furchtbar? Ich erinnere mich noch an Zeiten, in denen Teams eine ganz brauchbare App war. Es gab sogar einen Linux-Desktop-Client.
    Ich erinnere mich auch daran, als Slack tatsächlich schnell war, und daran, dass Skype Out stabiler war als meine Handytelefonate.
    Heute wird Slack extrem langsam, sobald man nur ein paar Organisationen hinzufügt. Immerhin kann man mehr als eine hinzufügen.
    Teams hat den Linux-Desktop-Client eingestellt, und unter Linux muss man es über Chrome nutzen. Wenn man es aber als Teil von Office 365/SharePoint verwendet, brauchen „einige“ SharePoint-Links Firefox.
    Am Ende braucht man also immer zwei Browser. Für Bildschirmfreigabe und Video in Teams Chrome, für manche SharePoint-Links Firefox.

    • Kaum zu glauben, aber Chat-/Meeting-Apps sind das naheliegendste Einfallstor zur Alles-App im Stil von WeChat.
      Letztlich ist eine Chat-/Meeting-App eine Miniaturausgabe des Internets.
      Chat-Apps sind großartig, aber was, wenn man auch Audioclips senden und teilen könnte, Videoclips, Live-Video, Geld, Meetings, Kalendereinladungen, Essenslieferungsanfragen, Gaming-Sessions, X?
      Für X gibt es keine Grenze. Das Internet besteht darin, X zu teilen, und Chat-Apps bestehen ebenfalls darin, X zu teilen; es gibt also keine echte Grenze dafür, wie groß das werden kann.
    • Der Kern ist, sie von Anfang an furchtbar und simpel zu machen. IRC funktioniert heute noch genauso mies wie vor 30 Jahren.
    • Ein Teil davon scheint vom Druck zu kommen, immer weiter Features hinzuzufügen.
      Chat und Video funktionieren, aber wie wäre es mit Hintergrundunschärfe? Verdammt, Zoom hat Umfragen, also brauchen wir auch Umfragen. Und wenn man so Features raushaut und schnell iteriert, kann man ja auch Electron nehmen — genau diese Dynamik.
    • Der Markt belohnt Features und Integrationen, nicht Performance, solange die App gerade brauchbar genug ist. Entwickler entwickeln dann … nein, Features, Features, Features.
    • Ein schlankes, produktives Startup-Team baut eine App, die alle mögen, bekommt viel Investment und stellt dann Tausende überflüssige Softwareentwickler ein.
      Danach muss man eben Arbeit für sie finden.
  • Das ist großartig. Mir gefällt, dass dieses neue Ding an die frühen MS-DOS-Zeiten ganz am Anfang der 90er erinnert, als es auf 086- oder 286-Maschinen lief.
    Microsofts Besessenheit von Abwärtskompatibilität muss man respektieren. Es ist die unmögliche Vorstellung, als würde ein nativer Port von MS Teams für MS-DOS 3.1 gebaut. Etwas plausibler wäre die Vorstellung, dass die MS-Teams-Server auf einem uralten, absonderlichen proprietären MS-DOS-3.1-Mainframe laufen, aber auch das ergibt natürlich keinen Sinn.
    Ich wusste, dass diese Beschränkung für Gerätenamen auch für Windows-Dateinamen gilt, daher ist es nicht besonders überraschend, wenn man weniger auf Spaß aus ist. Wenn man Spaß mag, kann man sich aber die obige Vorstellung ausmalen.
    Zugehöriger Link: https://learn.microsoft.com/en-us/microsoftteams/limits-spec...

    • „Ganz am Anfang der 90er, als MS-DOS auf 086 oder 286 lief“ liegt ungefähr 10 Jahre daneben.
      MS-DOS lief Anfang der 80er auf dem 8086.
    • Überraschend ist es schon. Unter WSL kann man solche Dateien erstellen, aber unter Windows weder erstellen noch löschen; das ergibt keinen Sinn.
      Windows 10 oder 11 haben keine DOS-Schicht mehr, und es wirkt eher so, als habe Microsoft kein Interesse, solche Probleme zu beheben.
    • Abwärtskompatibilität ist ein lobenswertes Ziel, und der Aufwand dafür ist anerkennenswert.
      Ich wünschte nur, das würde nicht auch einschließen, Passwörter auf absurd kurze Längen oder lächerlich eingeschränkte Zeichensätze zu begrenzen.
  • Das erinnert an das Gerücht, dass der Grund, warum nach „Windows 7“ und „8“ die „9“ übersprungen wurde und es „10“ wurde, die Angst war, dass irgendwo in der Codebasis so etwas steht:
    if(version.StartsWith(“Windows 9”)) { /* 95 and 98 */ ... }

    • Wurde die Windows-Version in der Windows-API jemals als String offengelegt?
      Ich habe keine Windows-Erfahrung, aber das wirkt etwas seltsam. Einerseits wäre es etwas, das Microsoft der Abwärtskompatibilität wegen tun würde, andererseits wirkt es wie eine merkwürdige API.
      Ich habe GetVersion[1] gefunden; das gibt die Version als zwei Zahlen zurück.
      [1] https://learn.microsoft.com/en-us/windows/win32/api/sysinfoa...
  • Verbotene Wörter: forms, CON, CONIN$, CONOUT$, PRN, AUX, NUL, COM1 bis COM9, LPT1 bis LPT9, desktop.ini, _vti_

    • Zuerst wollte ich sagen: „Das lässt doch praktisch durchsickern, dass intern irgendetwas Schreckliches passiert. So etwas öffentlich zuzugeben, sollte einem peinlich sein. Das ist ähnlich wie zu sagen, man dürfe %s oder $PS1 nicht verwenden — warum nicht? Was zum Teufel macht ihr mit Nutzereingaben?“
      Aber es könnte auch darum gehen, wie Kanalnamen an anderer Stelle behandelt werden. Leute können sie überallhin kopieren und einfügen, und offenbar erwartet man nicht, dass Windows-Nutzer ihre Strings selbst escapen, wenn sie sie in cmd, PowerShell oder WSL einfügen.
    • Mitte der 90er gab es eine kurze, unterhaltsame Phase, in der IRC-Clients wie mIRC so konfiguriert werden konnten, dass sie Dateien per DCC automatisch annahmen.
      Und sie schrieben bereitwillig auch auf Namen wie LPT1, wodurch die Daten natürlich direkt auf dem Drucker des Empfängers landeten.
    • Ich frage mich, ob es tatsächlich Maschinen mit LPT9 gab. COM9 kann ich mir gerade noch vorstellen.
  • Ein allgemeiner Tipp beim Strukturieren von Nutzerdaten ist, sie nach Möglichkeit als undurchsichtige Blobs zu behandeln.
    Man sollte sich vorstellen, sie seien verschlüsselt und weder ausgebbar noch für Menschen lesbar.
    forms, CON, CONIN$, CONOUT$, PRN, AUX, NUL, COM1 bis COM9, LPT1 bis LPT9, desktop.ini, _vti_
    Wenn man solche Dinge einschränken muss, weil Nutzereingaben direkt ins Dateisystem gelangen, hat man es vermasselt. Statt Nutzereingaben direkt zu verwenden, hätte man eine sichere ID vergeben sollen. Das könnte uuid4 sein oder etwa ein Digest des Kanalnamens.
    Wenn jemand sagt: „Dieses Zeichen kann nicht verwendet werden“, riecht das für mich verdächtig. Automatisch denke ich: „Warum nicht? Ihr verwendet das doch nicht etwa als unkodierten Klartext?“ Beispiele dafür sind Passwörter, Benutzernamen oder Kommentare – Inhalte also, die auf einer Webseite angezeigt werden.
    Allerdings könnte das Ganze auch einfach ein missglücktes Easter Egg sein. Vielleicht wollte man nur ein bisschen Spaß einbauen, und dann ist es schiefgelaufen.

  • Es ist zwar schlecht, aber mal ehrlich: Was ist das Ziel? Dass Leute beliebige Namen vergeben können, auch für Kanalnamen? Zum Beispiel einen Namen wie "rm -rf /*"?
    Es geht noch besser: Man schreibt dieses rm -rf mit dem RLO-Zeichen zur Rechts-nach-links-Überschreibung so, dass es wie fr- mr aussieht.
    Sollte das wirklich das Ziel sein? In der Annahme, dass dabei schon keine Probleme entstehen?
    Zum Glück kann man unter Linux keine Datei mit dem Namen https://example.org erstellen. Unter Windows doch auch nicht, oder?
    Ernsthaft gefragt: Ist das wirklich ein Problem? Und wenn ja, wo zieht man die Grenze?
    Codepoint 0? Hangul-Füllzeichen und RLO-Zeichen? Findet man Anwendungen mies, die so etwas ablehnen?
    Zum Glück gibt es Einschränkungen dafür, was in Dateinamen vorkommen darf. Und ich finde, die aktuellen Einschränkungen sind nicht einmal streng genug. Dasselbe gilt für Benutzernamen, Kanäle und wirklich vieles andere.
    Sieht zum Beispiel wirklich jemand ein Problem darin, dass Twitter nur sichtbare alphanumerische Zeichen und Unterstriche erlaubt und die Länge auf maximal 15 Zeichen begrenzt?
    Das wirkt wie ein sehr kluger Ansatz. Viel besser, als sich danach zu sehnen, in Benutzernamen und Kanalnamen das Kackhaufen-Emoji verwenden zu können.

    • Eine Datei namens https://example.org kann man zwar nicht erstellen, einen solchen Pfad aber sehr wohl.
      Denn doppelte Schrägstriche im Inneren werden ignoriert, und man kann ein Verzeichnis namens https: sowie eine Datei namens example.org erstellen.
    • Zum Löschen von Daten ist dd meiner Meinung nach besser geeignet als rf.
  • Wenn der Kanaltitel als SharePoint-Ordner verwendet wird, überrascht es, dass es für genau solche Zeichenketten kein standardisiertes Escaping-Verfahren gibt.
    Das würde zwar die Kompatibilität mit Anwendungen brechen, die auf solche magischen Gerätedateien angewiesen sind, aber SharePoint sollte wirklich niemals mit COM1 kommunizieren wollen.
    Es ist seltsam, dass SharePoint das nicht ohnehin bereits behandelt.

    • SharePoint kann mit dem Windows-Dateisystem synchronisiert werden, und Windows/Win32 unterstützt solche Namen aus Gründen der Abwärtskompatibilität nicht.