1 puan yazan GN⁺ 2023-08-11 | 2 yorum | WhatsApp'ta paylaş
  • Microsoft Teams’te ekipler, kanallar, sohbetler, toplantılar ve dosya paylaşımı genelinde ayrıntılı işletim sınırları bulunur; kanal adlarında CON, PRN, AUX, NUL, COM1~COM9, LPT1~LPT9 gibi MS-DOS aygıt adları kullanılamaz
  • Ekip başına üye sınırı 25.000, kullanıcı başına ekip üyeliği sınırı 1.000, ekip başına kanal sınırı 1.000’dir; silinen kanallar da 30 günlük kurtarma süresi boyunca sınıra dahil edilmeye devam eder
  • Sohbet için temel sınırlar özel sohbette 250 kişi, sohbet tabanlı sesli/görüntülü aramada 20 kişi, 10 ek ve 100 MB dosyadır; 20 kişi aşıldığında arama, yazıyor göstergesi ve okundu bilgisi gibi özellikler kapatılır
  • Toplantılar plana bağlı olarak en fazla 300 veya 1.000 kişiyle düzenlenebilir; Teams toplantıları, web seminerleri ve town hall etkinliklerinde 30 saatlik sınır vardır; küçük grup odaları yalnızca 300 kişiden az katılımcılı toplantılarda oluşturulabilir
  • Dosya paylaşımı SharePoint ve OneDrive for Business’a bağlı olduğundan SharePoint’in devre dışı olduğu kiracılarda kısıtlamalar oluşur; Teams dosyaları site veya grup başına 25 TB, dosya yüklemeleri ise dosya başına 250 GB’a kadar desteklenir

Ekip ve kanal sınırları

  • Bir kullanıcının oluşturabileceği ekip sayısı, Microsoft Entra ID’nin 250 nesne sınırına tabidir; genel yöneticiler bu sınırın dışındadır
  • Bir kullanıcının üye olarak katılabileceği ekip sayısı, arşivlenmiş ekipler dahil olmak üzere 1.000 ile sınırlıdır
  • Ekip düzeyindeki başlıca sınırlar şöyledir
    • Üye: 25.000 kişi
    • Sahip: 100 kişi
    • Kuruluş genelindeki ekip: kiracı başına 5 adet
    • Kuruluş genelindeki ekip üyeleri: 10.000 kişi
    • Microsoft 365 veya Office 365 kuruluşundaki ekip sayısı: 500.000
    • Genel yöneticinin oluşturabileceği ekip sayısı: 500.000
  • Ekip başına kanal sayısı en fazla 1.000’dir; buna standart kanallar ve paylaşılan kanalların birleşimi ile en fazla 30 özel kanal dahildir
  • Silinen kanallar 30 gün boyunca geri yüklenebilir ve bu süre içinde ekip başına kanal sınırına ve özel kanal sınırına dahil edilmeye devam eder
  • Kanal konuşma gönderileri gönderi başına yaklaşık 100 KB ile sınırlıdır; gövde, görsel bağlantıları, @bahsetmeler, bağlayıcı sayısı ve tepkiler buna dahildir
    • base64 kodlu görseller 100 KB sınırına dahil değildir

Paylaşılan kanal kısıtlamaları

  • Paylaşılan kanallar ekip başına en fazla 1.000 adet olabilir; silinen kanallar 30 günlük kurtarma süresi boyunca dahil edilir
  • Tek bir paylaşılan kanal, üst ekip hariç en fazla 50 ekiple paylaşılabilir
  • Paylaşılan kanal üyeleri en fazla 5.000 doğrudan üye olabilir; paylaşılan ekipler sınır hesaplamasında ekip başına 1 kişi olarak sayılır
    • Gerçek zamanlı güncellemeler aynı anda yalnızca 25.000 kişiye sağlanır
    • Kanal listesinde yalnızca 25.000 kişi gösterilir
  • Dış katılımcılar için yalnızca Microsoft Entra iş veya okul hesapları desteklenir
  • Paylaşılan kanallar sekmeleri destekler; ancak Stream, Planner ve Forms hariçtir
  • Botlar, bağlayıcılar ve mesaj uzantıları paylaşılan kanallarda desteklenmez
  • Kuruluş genelindeki ekipler paylaşılan kanal üyesi olarak eklenemez
  • Mevcut bir ekipten yeni ekip oluştururken mevcut ekibin paylaşılan kanalları kopyalanmaz
  • Paylaşılan kanal bildirimleri kaçırılan etkinlik e-postalarına dahil edilmez
  • Paylaşılan kanallar sınıf ekiplerinde desteklenmez

Kanal adı yasak kuralları

  • Kanal adlarında şu karakterler kullanılamaz
    • ~ # % & * { } + / \ : < > ? | ' " , ..
  • Şu karakter aralıkları da kullanılamaz
    • 0~1F
    • 80~9F
  • Şu sözcükler kanal adlarında kullanılamaz
    • forms
    • CON, CONIN$, CONOUT$
    • PRN, AUX, NUL
    • COM1~COM9
    • LPT1~LPT9
    • desktop.ini
    • _vti_
  • Kanal adları alt çizgi _ veya nokta . ile başlayamaz ve nokta . ile bitemez

Mesajlaşma ve sohbet

  • Teams sohbet listesine dahil edilen konuşmalar, katılımcıların Exchange Online posta kutusunda saklanır
  • Bir yöneticinin sohbet konuşmalarını araması veya saklaması için katılımcıların bulut tabanlı Exchange Online posta kutusuna sahip olması gerekir
    • Exchange hibrit dağıtımında, şirket içi posta kutusu kullanıcıları Teams sohbetine katılabilir
    • Bu durumda ilgili konuşma içeriği aranamaz veya saklanamaz
  • Özel sohbetin başlıca sınırları şöyledir
    • Kişi sayısı: 250 kişi
    • Grup sohbetine tek seferde eklenebilecek üye: 200 kişi
    • Sohbetten başlatılan sesli/görüntülü arama: 20 kişi
    • Ek dosya: 10 adet
    • Dosya boyutu: 100 MB
    • Sohbet gönderisi boyutu: yaklaşık 100 KB
  • Sohbette kişi sayısı 20’yi aşarsa şu özellikler kapatılır
    • Outlook otomatik yanıtları ve Teams durum iletisi
    • Yazıyor göstergesi
    • Sesli/görüntülü arama
    • Paylaşım
    • Okundu bilgisi
    • Set Delivery Options düğmesi
  • Mesaj teslim başarı oranını artırmak için mesajın kendi boyutunun 80 KB içinde tutulması önerilir
  • Deneme aboneliği kiracıları, kötüye kullanımı önlemek için daha sıkı mesajlaşma sınırlamalarına tabi olabilir ve sınırlar önceden haber verilmeksizin ayarlanabilir
  • Dış erişimde yalnızca güvenilen etki alanlarına izin veren yöneticiler en fazla 4.000 güvenilen etki alanı ekleyebilir

Kanal e-postası

  • Kanal e-posta adresine gönderilen e-postalar kanalın parçası olur ve herkes yanıt vererek konuşma başlatabilir
  • Kanala e-posta gönderirken sınırlar şöyledir
    • Mesaj boyutu: 24 KB
    • Ek dosya: 20 adet
    • Ek dosya başına boyut: 10 MB’tan az
    • Satır içi görsel: 50 adet
  • Sınır aşıldığında davranış değişir
    • Mesaj 24 KB’ı aşarsa bir önizleme mesajı oluşturulur ve kullanıcıların sağlanan bağlantıdan özgün e-postayı indirip görüntülemesi gerekir
    • Ek dosya veya görsel sayısı sınırı aşarsa hata mesajı gösterilir
  • Kanal e-postası için hız sınırı uygulanır
    • Kanal başına kullanıcı bazında 10 saniyede 6 e-posta
    • Kiracı başına kullanıcı bazında 10 saniyede 8 e-posta
  • Kanal e-postası Office GCC/GCCH/DOD kuruluşlarına yönelik Teams’te kullanılamaz

Toplantılar ve aramalar

  • Microsoft 365 Business Basic, Business Standard, Business Premium, Microsoft Teams Essentials ve Microsoft 365 A1 planları, Teams çevrimiçi toplantılarını ve görüntülü aramaları en fazla 300 kişiyle barındırabilir
  • Microsoft 365 F1/F3/E3/E5/A3/A5/G3/G5, Office 365 E1/E3/E5/A3/A5/G1/G3/G5 ve Microsoft Teams EEA planlarında sınır en fazla 1.000 kişiye çıkar
  • Toplantılarla ilgili başlıca sınırlar şöyledir
    • Sohbetten başlatılan sesli/görüntülü arama: 20 kişi
    • PowerPoint dosyası azami boyutu: 2 GB
    • Microsoft Stream’e yüklenmemiş toplantı kayıtlarının yerel olarak indirilebilme süresi: 20 gün
    • Toplantı kaydı azami uzunluğu: 4 saat veya 1,5 GB
  • Kayıt azami uzunluğa veya kapasiteye ulaştığında kayıt sona erer ve otomatik olarak yeniden başlar
  • Küçük grup odaları yalnızca katılımcı sayısı 300 kişiden az olan toplantılarda oluşturulabilir
    • Küçük grup odaları oluşturulduğunda toplantı katılımcı sayısı otomatik olarak 300 kişiyle sınırlandırılır
  • Teams toplantıları, web seminerleri ve town hall etkinliklerinde 30 saatlik süre sınırı vardır

Toplantı süresinin dolması

  • Toplantı süresinin dolması; PSTN telefonla katılma numaraları, CVI koordinatları, varsayılan toplantı ilkesi ve ayarları için geçerlidir
  • Süresi dolmadan önce toplantıya katılınır veya toplantı güncellenirse, Meet now toplantıları hariç olmak üzere süre sonu sınırına 60 gün eklenir
  • Genel önizleme ölçütlerine göre yeni bağlantılar ve toplantılar koşullara bağlı olarak süre sonunda sona erer; süre dolduktan sonra bağlantıyla katılmak mümkün değildir
    • Zamanlanmış tek seferlik toplantı: zamanlanmış toplantı saatinden 60 gün sonra
    • Takvimden veya kanaldan zamanlanmış Meet now: bağlantı oluşturulduktan 60 gün sonra
    • Grup sohbetinden zamanlanmış Meet now: geçerli değil
    • Bitiş tarihi olan yinelenen toplantı: bitiş tarihinden 60 gün sonrası veya son gerçekleşme tarihinden 60 gün sonrası; hangisi daha uzunsa
    • Bitiş tarihi olmayan yinelenen toplantı: son erişim, katılım veya toplantı güncellemesinden 1 yıl sonra

Canlı etkinlikler

  • Teams canlı etkinlikleri Temmuz 2026’da sona erecek
    • Önceden zamanlanmış etkinlikler 28 Şubat 2027’ye kadar desteklenecek
    • Microsoft, büyük ölçekli dijital ve hibrit etkinlikler için Teams town hall kullanılmasını önerir
  • Varsayılan canlı etkinlik sınırları şöyledir
    • Katılımcı: en fazla 10.000 kişi
    • Etkinlik uzunluğu: 4 saat
    • Microsoft 365 veya Office 365 kuruluşunda aynı anda çalıştırılabilen canlı etkinlik: 15 adet
  • Bir yapımcı canlı etkinliğe katıldığı anda etkinlik çalışıyor kabul edilir
      1. canlı etkinliğe katılmaya çalışan yapımcı hata alır
  • Geçici sınır artışı, ek duyuruya kadar uzatılmıştır
    • En fazla 20.000 katılımcı
    • Kiracı genelinde 50 eşzamanlı etkinlik
    • Yayın başına 16 saat
  • Microsoft 365 assistance program aracılığıyla en fazla 100.000 katılımcılı canlı etkinlik planlanabilir; ekip her isteği değerlendirerek mümkün seçenekleri belirler

Depolama ve dosya paylaşımı

  • Her Teams ekibinin bir SharePoint ekip sitesi vardır ve her kanal için varsayılan ekip sitesi belge kitaplığında bir klasör oluşturulur
  • Konuşmalarda paylaşılan dosyalar otomatik olarak belge kitaplığına eklenir; SharePoint’te ayarlanan izinler ve dosya güvenliği seçenekleri Teams’e yansıtılır
  • Her özel kanalın ayrı bir SharePoint sitesi vardır
  • Kiracıda SharePoint etkin değilse Teams kullanıcıları ekiplerde her zaman dosya paylaşamayabilir
  • Özel sohbetlerde dosya paylaşmak için SharePoint lisansıyla bağlantılı OneDrive for Business gerekir
  • Teams dosya paylaşımı SharePoint arka ucunda çalıştığından, Teams’in Files bölümüne SharePoint sınırlamaları uygulanır
  • Gösterilen planların depolama sınırları şöyledir
    • Kuruluş başına 1 TB + satın alınan lisans başına 10 GB
    • Office 365 Enterprise F1 için kuruluş başına 1 TB
    • Teams Files için site veya grup başına en fazla 25 TB
    • Dosya yükleme sınırı dosya başına 250 GB
  • Kanallar, ekipler için SharePoint sitesindeki klasörlerle desteklendiğinden, kanalın dosyalar sekmesi ait olduğu ekibin depolama sınırını paylaşır

Eğitim için sınıf ekipleri ve etiketler

  • Microsoft Teams for Education, sınıf dersi gibi eğitim senaryoları için şablonlar sağlar
  • Sınıf ekiplerini kullanmak için Office 365 Education lisansı gerekir
  • Sınıf ekipleri genel ekip üye sınırlarına tabidir, ancak belirli uygulamalar için ayrı sınırlamalar vardır
    • Assignments uygulaması kullanımı: 1.000 üye
    • OneNote Class Notebook uygulaması kullanımı: 300 üye
  • Sınıf ekipleri daha fazla üyeyi destekleyebilir, ancak Assignments veya Class Notebook kullanılması planlanıyorsa yukarıdaki sınırların altında tutulmalıdır
  • Etiket sınırları şöyledir
    • Ekip başına etiket: 200 adet
    • Ekip başına önerilen varsayılan etiket: 25 adet
    • Bir etikete atanabilecek ekip üyesi: 200 kişi
    • Kullanıcı başına ekip içinde atanmış etiket: 25 adet

Kişiler ve tarayıcı desteği

  • Teams, kuruluşun Active Directory kişilerini ve kullanıcının Outlook varsayılan klasörüne eklediği kişileri kullanır
  • Teams kullanıcıları, kuruluşun Active Directory’sindeki herkesle iletişim kurabilir ve Chat > Contacts veya Calls > Contacts üzerinden kişi listesine ekleyebilir
  • Kuruluş Active Directory’sinde bulunmayan kişiler de Calls > Contacts üzerinden kişi olarak eklenebilir
  • Outlook’ta Teams presence, Outlook 2013 masaüstü uygulaması ve sonrasında desteklenir
  • Tarayıcı desteği özelliğe göre değişir
    • Internet Explorer 11 aramaları desteklemez ve yalnızca PSTN koordinatları olan toplantıları sınırlı şekilde destekler
    • Güncel Microsoft Edge Chromium ve Google Chrome, aramaları ve toplantıları tam olarak destekler
    • Firefox aramaları desteklemez ancak toplantıları destekler; tam destek için OpenH264 eklentisi gerekir
    • Safari sürümüne bağlı olarak 1:1 arama, video ve paylaşım destek kapsamı değişir
  • Tarayıcıda Teams toplantıları tek akışla sınırlıdır; yalnızca mevcut konuşmacının gelen videosu veya ekran paylaşımından biri gösterilir
  • Paylaşım sırasında denetimi almak ve vermek için her iki tarafın da Teams masaüstü istemcisini kullanması gerekir; tarayıcıda desteklenmez

2 yorum

 
xguru 2023-08-11

Windows ile geriye dönük uyumluluk yüzünden böyle yapmışlar gibi görünüyor.

Ama günümüz geliştiricileri COM, LPT, PRN gibi şeyleri biliyor mudur, emin değilim haha.

"Sabit disk neden C’den başlar?" gibi sorular da ara sıra görülüyor...

 
GN⁺ 2023-08-11
Hacker News yorumları
  • 1998 civarında ergen bir Linux fanatiği olarak LAN partilerine Linux makinesi götürürdüm; gerçekten de gayet iyi çalışırdı.
    O zamanlar WINE neredeyse Starcraft desteği için vardı; Quake 2 ise yerel olarak çalışıyordu ve bu ikisi insanların oynadığı oyunların %95’ini kapsıyordu.
    Bir keresinde ağdaki tüm Windows paylaşımlarını dolaşıp CON/CON açmayı deneyen bir shell script çalıştırmanın komik olacağını düşündüm; her makine anında mavi ekran verdi ve arkadaşlarım nedense bunu eğlenceli bulmadı.

    • O günleri hatırlattı. Her LAN buluşmasında mutlaka böyle bir arkadaş olurdu.
      Ağ sorunlarını çözmekte iyi olan ve yedek CAT-5 kablosunu her zaman yanında getiren BSD arkadaşım gibi olsaydın, bunu fazlasıyla telafi ederdin.
    • Bu IPX üzerinden mi olmuştu? Linux’ta IPX yapılandırdığımı hatırlamıyorum.
      Wine ile Starcraft çalıştıracak kadar Linux kullandığım dönemde sanırım artık IP desteği vardı.
    • Bu hikâyeyi gerçekten sevdim. WINE’ın o kadar eskiye dayandığını ve Starcraft gibi oyunları çalıştırabildiğini bilmiyordum.
      Eskiden arkadaşlarımla Starcraft oynadığım günlere dair çok güzel anılarım var; oyun da ortaokulda kapılıp üniversitede tekrar içine düşebileceğim kadar uzun ömürlüydü.
    • LAN partilerinde insanlara ping flood atmak, herkesin yapabileceği türden hack’lerin en iyisiydi.
      Eski güzel anılar.
    • Altın çağdı. Farklı olan biz miydik, yoksa etrafımızdaki dünya mıydı, bilmiyorum.
  • Bunun nedeni büyük olasılıkla Windows dosya sisteminde bu adların dosya veya klasör adı olarak kullanılamaması.
    MS Teams kanalı, dosya eklerinin saklandığı SharePoint içinde buna karşılık gelen bir klasör oluşturur.

    • Microsoft bir sorunla karşılaşınca “tamam, bunu SharePoint üzerine kuralım” diye düşünüyor gibi.
    • Windows tabanlı bir alım satım sistemi kullanan bir bankada çalıştım; bir nedenle her defterin ayrıntılarını içeren klasörler oluşturuyordu.
      Bir trader defter adını LPT1 koyunca sorun çıktı.
    • Burada başka açıklar da var gibi. Yine de % ve .. karakterlerini de kara listeye alıyor gibiler.
    • Karşılık gelen bir Active Directory grubu da oluşturuluyor.
      Kullanıcıların destek bileti açmadan kaynak erişim izinlerini yönetmesini sağlayan çok kolay bir yol olduğu için kullanılması oldukça mantıklı.
    • SharePoint, Microsoft’un derinlerine pençelerini geçirmiş durumda ve sonsuza kadar onların Aşil topuğu olarak kalacak.
  • Başta şöyle diyecektim: “Bu, içeride korkunç bir şeyler olduğunu fiilen sızdırmak değil mi? Bunu açıkça söylemekten utanmaları gerekir. %s ya da $PS1 kullanılamıyor demeye benziyor; neden olmasın? Kullanıcı girdisiyle tam olarak ne yapıyorsunuz?”
    Ama mesele, kanal adının başka yerlerde nasıl ele alınacağıyla ilgili de olabilir. İnsanlar bunu her yere kopyalayıp yapıştırabilir; Windows kullanıcılarının cmd, PowerShell veya WSL’ye yapıştırırken kendi dizgilerini bizzat escape etmesini beklemiyorlar sanırım.
    Teams kodunun kendisi muhtemelen bunu düzgün işleyebilir; sorun, kanal adını ele alabilecek dışarıdaki her türden bilinmeyen ve özensiz araç olabilir.
    Başkaları kanala bağlı SharePoint klasörüne işaret etmiş; ama dizinler için güvenli bir sürüm oluşturmak üzere escape etmek, dönüştürmek veya encode etmek kolay olduğundan şahsen bunu mazur görmekte zorlanıyorum. Yine de bir yerlerde kanal adıyla dizin adının aynı olmasının önemli olduğu durumlar olabilir.
    Yalnızca uygulama içinde kullanılıyorsa, kanal adı ve dizin adı aynı şekilde encode/decode edilip kullanıcıdan tamamen gizlenebilir; ancak dizin uygulama dışında da kullanılıyorsa URL encoding gibi biçimler olduğu gibi görünür ve kötü durur.
    Sonuçta dizin adının diğer her şey için güvenli olması gerekir; bu yüzden kanal adının da öyle olması gerekir. Ara sıra çirkin dizin adları kullanmak yerine bu kısıtlamayı seçmişler; nihayetinde bu, güvenlik ya da bozulma sorunundan çok görünüm sorununa yakın. Encoding gerektirecek karakterlere hiç izin vermediklerinden tüm dizinler her zaman doğal ve güzel görünüyor.

    • Ham DNS NXDOMAIN pasif DNS (PDNS) akışını görme fırsatınız olursa gerçekten çok fazla bozuk şey var; bazıları da epey ürkütücü.
      Ad hizmetleri birbirine dönüştürülürken böyle şeyler olur. Ad hizmetlerinin genelde bir kapsamı vardır ve bir bağlamdaki ad başka bir bağlamda farklı yorumlanır.
      Bobby Tables iyi bilinir, peki ya özel dosya adı -rf? Bir dönem Active Directory’nin normal yolu, dosya paylaşımı gibi yerlerde DNS alan adlarına neredeyse örtük biçimde güveniyordu. O “sürücüde” çalıştırılabilir dosyalar olabileceğini fark edene kadar kulağa iyi geliyordu.
      Açıkçası o belgede MS-DOS dizgesini bulamadım. Düzeltme: CON, LPT1 gibi referansları buldum.
    • Bu sadece SharePoint klasör adı kısıtlamasının yukarıya sızması. Özel bir şey değil.
    • “Kullanıcının kendi dizgesini escape etmesini beklemiyorlar” mı? Hangi sistemin kullanıcıları ne zaman böyle bir beklentiyi karşılamaya başladı? Öyle bir ütopya sistemi nerede?
    • AWS’de neredeyse her şey için karakter kısıtlamaları var.
      SQS mesaj gövdesinde bile hangi boşluk karakterlerinin kullanılabileceği kısıtlı.
    • Bu bir SharePoint kısıtlaması. Teams, SharePoint üzerine kurulu; bu ne sır ne de utanılacak bir şey.
  • Neden çoğu sohbet/toplantı uygulaması sonunda berbat hale geliyor? Teams'in düzgün bir uygulama olduğu zamanları hatırlıyorum. Linux masaüstü istemcisi de vardı.
    Slack'in gerçekten hızlı olduğu zamanları da hatırlıyorum; Skype out'un cep telefonu aramalarımdan daha kararlı olduğu zamanları da.
    Şimdi Slack, birkaç organizasyon ekleyince aşırı yavaşlıyor. Yine de birden fazlasını ekleyebiliyorsunuz.
    Teams, Linux masaüstü istemcisini kaldırdı; Linux'ta kullanmak için Chrome üzerinden gitmek gerekiyor. Ama Office365/SharePoint'in bir parçası olarak kullanınca “bazı” SharePoint bağlantıları Firefox gerektiriyor.
    Sonunda her zaman 2 tarayıcı gerekiyor. Teams'in ekran paylaşımı ve görüntülü görüşmesi için Chrome, bazı SharePoint bağlantıları için Firefox kullanmak zorundasınız.

    • İnanması zor olabilir ama sohbet/toplantı uygulamaları, WeChat gibi her şey uygulamasına giden en kolay kapı.
      Sonuçta sohbet/toplantı uygulaması internetin küçültülmüş hali.
      Sohbet uygulaması harika; peki ya ses klibi gönderip paylaşabilseydik, video klip de, canlı video da, para da, toplantı da, takvim daveti de, yemek siparişi isteği de, oyun oturumu da, X de paylaşabilseydik diye devam ediyor.
      X'in sınırı yok. İnternet X'i paylaşmaktır; sohbet uygulaması da X'i paylaşmaktır, bu yüzden pratikte ne kadar büyüyeceğine dair bir sınır yok.
    • Esas mesele, en baştan berbat ve basit yapmak. IRC, 30 yıl önce olduğu gibi bugün de aynı derecede kötü çalışıyor.
    • Bunun bir kısmı sürekli özellik ekleme baskısından kaynaklanıyor gibi.
      Sohbet ve video çalışıyor; peki arka plan bulanıklaştırma da eklesek? Kahretsin, Zoom'da anket var, bizim de anket eklememiz lazım. Böyle özellikleri boca edip hızlı yineleme yapacaksak Electron kullansak da olur, gibi bir akış.
    • Piyasa, uygulama kullanılabilir olduğu sürece performansı değil özellikleri ve entegrasyonları ödüllendiriyor. Geliştiriciler geliştirme… hayır özellik, özellik, özellik yapıyor.
    • Çevik ve üretken bir startup ekibi herkesin sevdiği bir uygulama yapıyor, sonra çok yatırım alıyor ve gereksiz binlerce yazılım geliştirici işe alıyor.
      Sonra da onlara yaptıracak iş bulmaları gerekiyor.
  • Bu çok iyi. Bu yeni şeyin bana 90'ların en başında, 086 veya 286'da çalışan MS-DOS'un ilk dönemlerini hatırlatmasını seviyorum.
    Microsoft'un geriye dönük uyumluluk takıntısına saygı duymak gerek. Sanki MS Teams'in yerel portu MS-DOS 3.1 için yapılacakmış gibi imkânsız bir hayal. Daha olası olan, MS Teams sunucusunun antik, tuhaf, tescilli bir MS-DOS 3.1 mainframe'inde çalıştığını hayal etmek olabilir; ama bu da elbette saçma.
    Bu aygıt adı kısıtlamasının Windows dosya adları için de geçerli olduğunu bildiğimden, eğlenceyi daha az arayan biriyseniz çok şaşırtıcı değil. Ama eğlenceyi seviyorsanız yukarıdaki hayali kurabilirsiniz.
    İlgili bağlantı: https://learn.microsoft.com/en-us/microsoftteams/limits-spec...

    • “MS-DOS'un 086 veya 286'da çalıştığı 90'ların en başı” yaklaşık 10 yıl kadar yanlış.
      MS-DOS 80'lerin başında 8086'da çalışıyordu.
    • Şaşırtıcı aslında. WSL'de böyle dosyalar oluşturabiliyorsunuz ama Windows'ta oluşturamıyor veya silemiyorsunuz; mantıklı değil.
      Windows 10 veya 11'de artık DOS katmanı da yok; daha çok Microsoft'un böyle sorunları düzeltmeye niyeti olmaması gibi.
    • Geriye dönük uyumluluk övgüye değer bir hedef ve bu çabayı takdir ediyorum.
      Yine de bunun, parolaları saçma derecede kısa uzunluklarla veya aşırı kısıtlı karakter kümeleriyle sınırlamayı içermemesini isterim.
  • “Windows 7”, “8”den sonra “9”u atlayıp “10” olmasının nedeninin, kod tabanının bir yerinde şöyle bir kod olmasından korkmaları olduğu söylentisi aklıma geldi:
    if(version.StartsWith(“Windows 9”)) { /* 95 and 98 */ ... }

    • Windows sürümü hiç Windows API'de string olarak sunuldu mu?
      Windows deneyimim yok ama biraz tuhaf geliyor. Bir yandan Microsoft'un geriye dönük uyumluluk için yapabileceği bir şey; diğer yandan sunması garip bir API gibi görünüyor.
      GetVersion[1]'ı buldum; bu sürümü iki sayı olarak döndürüyor.
      [1] https://learn.microsoft.com/en-us/windows/win32/api/sysinfoa...
  • Yasaklı kelimeler: forms, CON, CONIN$, CONOUT$, PRN, AUX, NUL, COM1 ile COM9 arası, LPT1 ile LPT9 arası, desktop.ini, _vti_

    • İlk başta “Bu, içeride korkunç bir şeyler olduğunu fiilen sızdırmak değil mi? Bunu açıkça söylemekten utanmak gerekir. %s veya $PS1 kullanılamaz demeye benziyor; neden olmasın? Kullanıcı girdisiyle tam olarak ne yapıyorsunuz?” diyecektim.
      Ama kanal adının başka yerlerde nasıl ele alınacağıyla ilgili bir sorun da olabilir. İnsanlar bunu her yere kopyalayıp yapıştırabilir; Windows kullanıcılarının cmd, PowerShell, WSL'ye yapıştırırken kendi string'lerini bizzat escape etmesini beklemiyorlar gibi.
    • 90'ların ortasında, mIRC gibi IRC istemcilerinin DCC ile dosyaları otomatik kabul edecek şekilde ayarlanabildiği kısa ve eğlenceli bir dönem vardı.
      Üstelik LPT1 gibi adlara da seve seve yazarlardı; doğal olarak o veri doğrudan alıcının yazıcısına giderdi.
    • Gerçekten LPT9 takılı makineler var mıydı merak ettim. COM9'u zar zor hayal edebiliyorum.
  • Kullanıcı verilerini yapılandırırken genel tavsiye, mümkünse bunları opak bir yığın gibi ele almaktır
    Şifrelenmiş olduğunu, çıktısının da insan tarafından okunmasının da mümkün olmadığını hayal edebilirsiniz
    forms, CON, CONIN$, CONOUT$, PRN, AUX, NUL, COM1’den COM9’a, LPT1’den LPT9’a, desktop.ini, _vti_
    Kullanıcı girdisi dosya sistemine olduğu gibi giriyorsa ve bu yüzden böyle şeyleri kısıtlamanız gerekiyorsa, işi berbat etmişsiniz demektir. Kullanıcı girdisini doğrudan kullanmak yerine güvenli bir ID vermeliydiniz. Bu uuid4 olabilir ya da kanal adının bir özeti gibi bir şey olabilir
    Biri “bu karakter kullanılamaz” dediğinde bunun kötü koktuğunu düşünürüm. Otomatik olarak “Neden olmasın? Bunu kodlanmamış düz metin olarak kullanıyor olamazlar, değil mi?” diye düşünürüm. Parolalar, kullanıcı adları, yorumlar gibi web sayfasında gösterilecek içerikler buna örnektir
    Gerçi tüm bunlar yanlış yapılmış bir easter egg de olabilir. Belki de sadece biraz eğlence katmaya çalışırken işler sarpa sarmıştır

  • Kötü olduğu doğru ama dürüst olmak gerekirse hedef ne? Kanal adları dahil insanların istedikleri herhangi bir adı verebilmesi mi? Örneğin "rm -rf /*" gibi bir ad
    Daha iyisi de var. O rm -rfyi RLO sağdan sola yön değiştirme karakteriyle fr- mr gibi görünecek şekilde yazmak
    Gerçekten hedef bu mu olmalı? Hiç sorun çıkmayacağına güvenerek?
    Neyse ki Linux’ta https://example.org adında bir dosya oluşturamazsınız. Windows’ta da öyle değil mi?
    Ciddi olarak sorarsak, bu gerçekten bir sorun mu? Sorunsa çizgi nereye çekilmeli?
    Kod noktası 0 ne olacak? Hangul doldurma karakteri ve RLO karakteri? Bunları reddeden uygulamaları berbat mı sayıyorsunuz?
    Neyse ki dosya adlarına girebilecek şeylerde kısıtlamalar var. Üstelik mevcut kısıtlamaların yeterince sıkı bile olmadığını düşünüyorum. Kullanıcı adları, kanallar ve gerçekten pek çok başka şey için de aynı
    Örneğin Twitter’ın yalnızca görünen alfasayısal karakterlere ve alt çizgiye izin verip en fazla 15 karakterle sınırlamasını gerçekten sorun olarak gören var mı?
    Bu bana çok akıllıca bir yaklaşım gibi görünüyor. Kullanıcı adlarında ve kanal adlarında kaka emojisi kullanabilmeyi arzulamaktan çok daha iyi

    • https://example.org adında bir dosya oluşturamazsınız ama böyle bir yol kesinlikle oluşturabilirsiniz
      Çünkü içerideki tekrarlı eğik çizgiler yok sayılır ve https: adlı bir dizin ile example.org adlı bir dosya oluşturulabilir
    • Verileri silmek için rf yerine dd kullanmanın daha iyi olduğunu düşünüyorum
  • Kanal başlığı SharePoint klasörü olarak kullanılıyorsa, bu tür dizgiler için standart bir escape yöntemi olmaması şaşırtıcı
    Böyle sihirli aygıt dosyalarına dayanan uygulamalarla uyumluluk bozulur ama SharePoint’in gerçekten COM1 ile iletişim kurmak istemesi kesinlikle söz konusu olmamalı
    Bunun zaten SharePoint’te ele alınmıyor olması garip

    • SharePoint, Windows dosya sistemiyle senkronize olabiliyor ve Windows/Win32 geriye dönük uyumluluk nedeniyle bu adları desteklemiyor