Videoconferencing is een blijvertje, maar willen we daarvoor afhankelijk blijven van big tech? Gelukkig bestaan er ook opensourcealternatieven die je op je Linux-server kunt installeren, zoals Jitsi Meet.
Zoom, Microsoft Teams, Google Meet, Cisco Webex Meetings, tijdens de coronacrisis hebben velen van ons er voor het eerst mee leren werken of er heel wat meer uren in gesleten dan ze van tevoren gewend waren. Videoconferencingsoftware is een blijvertje, maar daarmee is ook de macht van big tech op ons leven weer vergroot. Je data gaan door de servers van een bedrijf dat sowieso al veel over ons weet.
Gelukkig bestaan er ook allerlei alternatieve videoconferencingoplossingen, veel daarvan zijn open source. Een voorbeeld is Jitsi Meet. Je installeert dit op je Linux-server, maakt gebruik van de gratis server https://meet.jit.si, of een van de andere door de community onderhouden servers, of betaalt voor Jitsi-as-a-service zoals die van 8x8. Dit bedrijf heeft het Jitsi-project in 2018 overgenomen en bouwt zijn videoconferencingoplossing 8x8 Meet op basis van Jitsi Meet.
Architectuur
Jitsi Meet is het zichtbare deel van de videoconferencingoplossing. Het is een WebRTC-compatibele JavaScript-toepassing die je toelaat om te videobellen in je webbrowser. WebRTC is een opensourceproject gebaseerd op open standaarden dat JavaScript-api's aanbiedt voor alle grote webbrowsers voor realtime communicatie met video, audio en generieke data.
De centrale component is echter Jitsi Videobridge, ofwel JVB, een WebRTC-compatibele server die de videostreams van deelnemers aan een videoconferentie routeert. Jitsi Conference Focus, ofwel Jicofo, is verantwoordelijk voor het beheer van de mediasessies tussen de deelnemers en JVB. Nadat een nieuwe conferentie is aangemaakt en een deelnemer is binnengekomen, maakt Jicofo een Jingle-sessie tussen JVB en de deelnemer aan. Jingle is een uitbreiding van het Extensible Messaging and Presence Protocol, ofwel XMPP, met peer-to-peersignaling voor multimedia.
Een andere, optionele, component is Jitsi Gateway to SIP, ofwel Jigasi. Deze laat SIP-clients toe om in te bellen en aan een Jitsi Meet-conferentie deel te nemen. Jigasi registreert zichzelf ook als SIP-client bij een SIP-server. Je kunt hiermee ook vanuit een Jitsi Meet-conferentie anderen via SIP opbellen. En Jigasi kan ook live transcriptie van spraak aanbieden via een externe spraak-naar-tekstdienst zoals Google Cloud Speech-to-Text of Vosk Server, een offline systeem voor spraakherkenning dat je op een server kunt installeren. Jitsi Broadcasting Infrastructure, ofwel Jibri, voorziet dan weer, optioneel, in het opnemen of streamen van een Jitsi Meet-conferentie.
Tot slot maakt Jitsi in zijn architectuur ook gebruik van de XMPP-server Prosody. Bij XMPP denk je misschien in eerste instantie aan een chatserver, maar Jitsi gebruikt XMPP als communicatieprotocol tussen zijn verschillende services. Prosody is in een standaardinstallatie van Jitsi niet extern toegankelijk: het wordt alleen gebruikt voor de interne communicatie.
Jitsi Meet ondersteunt end-to-endencryptie. Daarvoor gebruikt het de WebRTC-functie Insertable Streams die Chrome heeft geïmplementeerd, maar Firefox nog niet.
Jitsi heeft een modulaire architectuur. Bron: Jitsi Meet Handbook
Wat heb je nodig?
Om je Jitsi-server op te zetten, heb je een Linux-server nodig die publiek toegankelijk is. Omdat WebRTC alleen over HTTPS werkt, heb je een TLS-certificaat voor je server nodig. Hoewel dat in principe met een zelfondertekend certificaat gaat en ook met een server op een intern netwerk, maakt het dit allemaal wat gecompliceerder. De eenvoudigste optie is dan ook om Jitsi op een virtual private server, ofwel vps, te installeren met een TLS-certificaat voor een domein dat naar het IP-adres van de vps verwijst.
De vereisten voor een professionele Jitsi-installatie zijn niet altijd eenvoudig te berekenen: ze hangen van veel factoren af, waaronder de architectuur. Je kunt meerdere Jitsi-videobridges elk op een eigen server draaien om een Jitsi Meet-server op te schalen. We gaan er hier van uit dat je een Jitsi-server opzet voor een kleine vriendenkring of kleine organisatie.
De belangrijkste vereiste is voldoende netwerkbandbreedte. Volgens de ontwikkelaars moet je bij hd, een resolutie van 720p, per deelnemer op 2,5Mbps rekenen en voor 4k op 10Mbps. Bekijk dus zeker de netwerkbandbreedte die je vps beschikbaar heeft, voordat je daarop een Jitsi-server gaat installeren. Heeft je server 1Gbps netwerkbandbreedte, dan kun je daarmee videoconferenties voor 100 deelnemers in 4k of 400 deelnemers in hd houden.
De ontwikkelaars raden 8GB ram aan, maar voor kleine conferenties zou 4GB en voor heel kleine conferenties zou 2GB mogelijk zijn. Voor de cpu raden ze vier cores aan en voor opslag een harde schijf van 250GB. Een ssd is niet noodzakelijk.
Omdat Jibri aan video encoding doet, zijn de vereisten voor de ram en cpu daarvoor nog hoger. Het is niet aan te raden om Jibri en Jitsi Meet op dezelfde server te draaien, omdat het de prestaties van die laatste negatief beïnvloedt.
Voor dit artikel hebben we een vps geconfigureerd met 4GB ram, twee cores op 80 procent, 160GB ssd-opslag en 1Gbps netwerkbandbreedte. We installeerden daarop Ubuntu Server 22.04 LTS. Op dat verse Ubuntu-systeem installeerden we daarna Jitsi zonder Jigasi en zonder Jibri.
Je hebt een krachtige vps-configuratie nodig om een Jitsi-server te draaien.
Voorbereiding van de installatie
Het Jitsi Meet Handbook biedt installatie-instructies in zijn Self-Hosting Guide voor Debian of Ubuntu, openSUSE, Docker of manuele stappen. Wij kozen voor de installatie op Ubuntu, die ook door de ontwikkelaars aangeraden wordt voor wie snel aan de slag wil met Jitsi.
Als eerste raden we aan om de Universe-repositorytoe te voegen en je systeem up-to-date te maken:
We dienen nu nog twee repository’s toe te voegen. De eerste voor die van Prosody, die een nieuwere versie van de XMPP-server bevat dan die in de repository van Ubuntu:
wget -qO- https://packages.prosody.im/debian/pubkey.asc | sudo tee /etc/apt/keyrings/prosody.asc echo "deb [signed-by=/etc/apt/keyrings/prosody.asc] http://packages.prosody.im/debian $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/prosody.list
We voegen hier eerst de publieke sleutel toe die de ontwikkelaars van Prosody gebruiken om de pakketten in hun repository mee te ondertekenen, en daarna verwijzen we in de definitie van de repository naar die sleutel.
Doe nu hetzelfde voor de repository van Jitsi:
wget -qO- https://download.jitsi.org/jitsi-key.gpg.key | sudo tee /etc/apt/keyrings/jitsi.asc echo 'deb [signed-by=/etc/apt/keyrings/jitsi.asc] https://download.jitsi.org stable/' | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
Update dan de pakketbronnen weer met sudo apt update. Als alles goed is, zou je nu met apt search jitsi allerlei Jitsi-pakketten moeten zien, en Prosody is beschikbaar in versie 0.12.
Jitsi heeft zijn eigen repository met pakketten voor Debian en Ubuntu.
De installatie en een zelfondertekend certificaat
Stel dan nu de firewall in. Ubuntu gebruikt een uncomplicated firewall, ofwel ufw, maar die is standaard inactief, zoals je ziet in de uitvoer van sudo ufw status. Open dan de poorten die Jitsi Meet nodig heeft, en de poort voor SSH, zodat je nog kunt inloggen:
TCP-poort 22 is voor SSH en 80 voor HTTP, dat hebben we nodig om een TLS-certificaat bij Let’s Encrypt aan te vragen en te vernieuwen. TCP-poort 443 is voor de webinterface van Jitsi Meet over HTTPS, UDP-poort 3478 is voor communicatie met de STUN-server, TCP-poort 5349 is voor de video en audio als UDP-poort 10000 geblokkeerd is, en over die laatste verloopt normaal alle video en audio.
Activeer dan de firewall en bekijk de status. Die zou nu alle bovenstaande poorten als open moeten tonen, zowel voor IPv4 als IPv6:
sudo ufw enable sudo ufw status
Zet alle benodigde poorten in de firewall open voor Jitsi.
Domein
Je Jitsi Meet-server heeft een domein nodig. We gaan er in de rest van dit artikel van uit dat je het fictieve domein example.com hebt en bij je DNS-registrar het subdomein ontmoet.example.com aanmaakt. Voeg dan voor dat domein een A-record toe dat je naar het publieke IPv4-adres van je vps laat verwijzen, en een AAAA-record dat je naar het publieke IPv6-adres laat verwijzen. Beide IP-adressen vind je in de uitvoer van de opdracht ip a op je server, na inet voor IPv4 en na inet6 voor IPv6, of in de beheerinterface van je vps-provider. Let op: een IPv6-adres dat begint met fe80 is een link-local adres, niet het publieke adres waarop je vps van buitenaf bereikbaar is.
Als alles goed is, kun je je VPS nu bereiken, en er bijvoorbeeld via SSH op inloggen, via de fully qualified domain name, ofwel fqdn, ontmoet.example.com. Nu moet je deze ook als hostname instellen op je vps, want het installatieprogramma van Jitsi gaat die gebruiken voor zijn configuratie. Dat doe je als volgt:
sudo hostnamectl set-hostname ontmoet.example.com
De opdracht hostname moet hierna ontmoet.example.com tonen.
Koppel daarna zowel het IPv4- als het IPv6-adres aan het domein ontmoet.example.com in het bestand /etc/hosts:
echo IPV4ADDRESS ontmoet.example.com | sudo tee -a /etc/hosts echo IPV6ADDRESS ontmoet.example.com | sudo tee -a /etc/hosts
Vervang in bovenstaande opdrachten IPV4ADDRESS en IPV6ADDRESS door het publieke IPv4- en IPv6-adres van de server.
Installatie
Dan is nu alles klaar om Jitsi Meet op je server te installeren:
sudo apt install jitsi-meet
Vul als om de hostname wordt gevraagd het domein ontmoet.example.com in. Op de vraag om een SSL-certificaat te gebruiken, kies je de optie 'Generate a new self-signed certificate'. We gaan dit na de installatie vervangen door een certificaat van Let’s Encrypt.
Nadat de installatie is voltooid, is Jitsi Meet al bereikbaar, maar dan met het zelfondertekende certificaat, dat een waarschuwing in je webbrowser oplevert. Installeer daarom eerst de ACME-client van Let’s Encrypt:
Dit vraagt een certificaat bij Let’s Encrypt aan via een HTTP-01-challenge, vernieuwt dit ook regelmatig, en configureert je webserver om dit te gebruiken. Vul je e-mailadres in.
Kies tijdens de installatie eerst een zelfondertekend certificaat om daarna een certificaat bij Let’s Encrypt aan te vragen.
De eerste gasten in je vergadering
Gebruik inperken
Als je nu in je webbrowser je domein bezoekt, kun je een vergadering starten. Maar iedereen kan dit nu doen, en iedereen in de hele wereld kan dus met anderen praten en de resources van je server gebruiken. Dat wil je waarschijnlijk niet, dus laten we eerst het gebruik inperken.
Open het bestand /etc/prosody/conf.avail/ontmoet.example.com.cfg.lua en zoek naar de regel VirtualHost "ontmoet.example.com". Daarachter staat de volgende regel:
authentication = "anonymous"
Vervang die door:
authentication = "internal_hashed"
Hierdoor kunnen alleen personen die zich aanmelden met een geldige gebruikersnaam en wachtwoord een vergadering aanmaken of eraan deelnemen.
Die authenticatie moet je ook nog in Jicofo inschakelen. Dat kan door in /etc/jitsi/jicofo/jicofo.conf een nieuwe sectie authentication aan te maken binnen jicofo {:
Bij het aanmaken van of deelnemen aan een vergadering moet je nu een gebruikersnaam en wachtwoord invoeren.
Om te voorkomen dat iedereen zomaar je Jitsi-server kan gebruiken, voeg je authenticatie toe.
Gastgebruikers toelaten
Meestal wil je ook dat gasten kunnen deelnemen aan je vergaderingen: je wilt niet dat je voor elke persoon die je ooit wilt spreken een account moet aanmaken. Daarom kun je Jitsi zo configureren dat het gastgebruikers toelaat. Die kunnen geen vergadering aanmaken, maar wel deelnemen aan een aangemaakte vergadering via een URL die ze als uitnodiging krijgen.
Open daarvoor weer het bestand /etc/prosody/conf.avail/ontmoet.example.com.cfg.lua en zoek weer naar de regel VirtualHost "ontmoet.example.com". Voeg nu onder dit blok, dus vóór de regel die begint met Component, het volgende blok toe:
De guest.ontmoet.example.com lijkt op een subdomein van je domein ontmoet.example.com dat naar je vps verwijst, maar je hoeft hier geen DNS-record voor aan te maken. Dit wordt alleen intern door Jitsi gebruikt. Je moet natuurlijk wel de ontmoet.example.com vervangen door het juiste domein van je server.
Open nu het bestand /etc/jitsi/meet/ontmoet.example.com-config.js. In het begin zie je dat er enkele hosts gedefinieerd worden. Vervang de volgende regel:
// anonymousdomain: 'guest.example.com',
door:
anonymousdomain: 'guest.ontmoet.example.com',
Je verwijdert dus de commentaartekens (//) en vervangt het domein door hetzelfde virtuele subdomein dat je in de configuratie van Prosody hebt ingesteld voor gastgebruikers.
Als je nu in je webbrowser surft naar het domein van je Jitsi-server, creëert Jitsi Meet automatisch een willekeurige naam voor een vergadering. Klik daarnaast op 'Vergadering starten'. Je krijgt nu de vraag om je te authenticeren als de host of om te wachten tot de host aanwezig is. Heb je een account, klik dan op 'Ik ben de host', vul je gebruikersnaam en wachtwoord in, en klik op 'Login'.
Als host kun je nu gastgebruikers uitnodigen. Klik daarvoor ofwel op het icoontje 'Deelnemers' (de twee personen) en dan op 'Iemand uitnodigen', ofwel op het icoontje 'Meer acties' (de drie puntjes) en dan op 'Personen uitnodigen'. Je krijgt nu een link naar de vergadering te zien waarmee je anderen kunt uitnodigen. Die bestaat gewoon uit de URL van je Jitsi-server met als pad de willekeurige naam voor je vergadering. Die URL geef je aan de gastgebruikers. Als je als gast een dergelijke URL krijgt, hoef je die slechts in je webbrowser te openen om aan de vergadering deel te nemen.
Extra beveiliging
Standaard biedt dit gedrag relatieve veiligheid. Als je niet zelf een naam voor je vergadering kiest, bestaat die naam uit vier willekeurige woorden en is die dus niet zomaar te raden door anderen. Maar iedereen die de URL weet die je aan de gastgebruikers geeft, kan ook zomaar in de vergadering binnenwandelen.
Daarom kun je het beste naar 'Meer acties / Beveiligingsopties' gaan. Als je daar de lobbymodus inschakelt, komen deelnemers altijd eerst in een lobby terecht. Pas wanneer een moderator, standaard iedereen in de vergadering, de deelnemer toelaat, komt hij in de vergadering. Een andere beveiligingsoptie is een wachtwoord. Daarmee heeft een gastgebruiker niet alleen de URL nodig om deel te nemen aan de vergadering, maar ook het bijbehorende wachtwoord. Ook end-to-endencryptie kun je hier inschakelen.
Jitsi heeft enkele beveiligingsopties.
Dagelijks gebruik
In het dagelijks gebruik van Jitsi Meet moet je er rekening mee houden dat iedereen in de vergadering standaard moderator is. Zodra een gastgebruiker in de vergadering aanwezig is, heeft die dus dezelfde rechten als de organisator van de vergadering. Iedereen kan dus de microfoon van andere gebruikers dempen of hun camera uitzetten, of extra personen uitnodigen. Dat is allemaal wel te configureren, maar onvoldoende gedocumenteerd. Een tool als Jitsi Admin kan daarbij helpen, maar is voor kleinere organisaties waarschijnlijk een overkill.
Verder bevat Jitsi Meet alle elementaire functionaliteit die je in een videoconferencingtool verwacht. Je kunt je scherm delen (in onze test op een Ubuntu 20.04-desktop werkte dat nog niet helemaal goed samen met Wayland), chatten, een poll starten en een achtergrond kiezen. Heb je Jibri geïnstalleerd, dan kun je ook een opname of livestream starten. Je kunt de webinterface gebruiken in elke moderne webbrowser of een van de mobiele clients voor Android en iOS.
Er is ook een Electron-app voor de desktop, zowel voor Windows als macOS en Linux. De interface is bijna identiek aan de webinterface. Je vult daar gewoon de volledige URL van je Jitsi-vergadering in, of je vult in de instellingen van het programma je server-URL in, waarna je de naam van de vergadering eenvoudig kunt invullen in het hoofdscherm.
Jitsi werkt eenvoudig in elke moderne webbrowser.
Conclusie
Je eigen Jitsi Meet-server opzetten voor videovergaderingen is niet zo moeilijk. Je bent daardoor niet afhankelijk van big tech en behoudt de controle over wat er met je data gebeurt. Heb je geavanceerdere functionaliteit nodig, dan is het wat meer werk en is het niet allemaal zo duidelijk gedocumenteerd. Hulp vind je dan op het forum van het project.
De vraag is natuurlijk ook wanneer je server het begeeft. Wat heb ik nodig voor een meeting met 50 mensen? Of 100? Wanneer werkt 10 nog? Want op een rpi zal 10 video streams heen en weer sturen ook al niet meer gaan lijkt me.
aangezien hij eigenlijk enkel de streams routeerd.
Ik denk dat je heel erg onderschat hoeveel CPU-kracht het kost om data te ontsleutel en versleutelen. Als je bijvoorbeeld een conferencecall met 20 mensen doet is dat best een boel platte data die door de server verwerkt moet worden en aangezien alles versleuteld is, moet de server dus de inkomende videostream ontsleutelen en 19 keer versleutelen naar de individuele gebruikers.
Tenzij er een soort preshared key wordt uitgewisseld tussen alle clients en dat de server echt alleen maar routeerd, maar dan nog is het multiplexen van data (van 1 naar 19) nog altijd best een heftige aangelegenheid voor een CPU of NIC (afhankelijk van de mogelijkheid tot ofloading van dataduplicatie)
Daar heb je zeker een punt! Had ik even niet aan gedacht. Veel mainstream CPU's hebben dat inderdaad.
Uit m'n hoofd hebben op dit moment geen van de raspberry-pi CPUs aes-versnelling, maar dat is dan natuurlijk ook niet een algemeen target-platform voor iets als dit. Ook zijn er volgens mij nog wel wat virtualisatieplatformen die hier niet optimaal mee omgaan, maar ook veel weer wel.
Het komt er in elk geval op neer dat je goed moet opletten op wat voor platform je zoiets als dit installeert.
Ik heb tijdens pandemie heel wat jitsi calls opgezet voor meetings in clubs (wekelijkse video apero) en bestuursvergaderingen waar de sportclub of vzw geen andere abonnementen heeft.
Vermits het WebRTC ondersteunt is het ook heel handig bij klanten die geen clients mogen installeren, militair, overheid,...
Op het werk gebruiken we het al 1.5+ jaar naar volle tevredenheid, het is erg stabiel (we hebben momenteel een jitsi sessie die 3000+ uur onafgebroken bemand is). Dit op een self-hosted instance. zo houden we controle over waar onze gespreksdata heen gaat.
Ik kan zelf ook de publieke jitsi server van de nluug aanbevelen, als je het gewoon even wil proberen zonder de boel eerst zelf te moeten installeren:
Het is mij onduidelijk wat je hiermee opschiet afgezien van 'minder afhankelijk zijn van big tech'. Op zich een nobel streven maar specifiek op video conferencing zie ik niet zo in waarom ik minder afhankelijk van big tech zou moeten zijn.
De vraag is een beetje hoe je omgeving hierop gaat reageren. Mensen zijn toch gewoontedieren en inmiddels gewend aan teams en (in mindere mate) zoom. Als je nu ineens met een andere tool aankomt zal dat mensen oncomfortabel maken.
Vanuit de zakenwereld denk ik ook dat er weinig interesse zal zijn. De kosten voor een teams licentie zullen snel weg te strepen zijn tegenover een beheerder die dit opzet en moet onderhouden.
Potentieel minder bespied worden door big tech en bij extensie overheden.
Heb ik zoveel te verbergen? Nee ik heb niet zo veel te delen.
Geen licentie kosten, geen vendor lock in, ja het kost de beheerder wel tijd om op te zetten en onderhouden.
Het overgrote merendeel van het bedrijfsleven houdt zich niet bezig met "bespieding door big tech". Men wil een betrouwbare dienst en dat is wat er wordt geleverd door de MSen en Googles van deze wereld. Deze partijen zeggen daarbij de privacy te garanderen en dat is voldoende tot het tegendeel wordt bewezen.
Daarnaast is vendor lock in, vooral bij MS, een gegeven in het bedrijfsleven. Teams komt daar gewoon "gratis" bij. Niemand maakt zich daar druk over, het zijn immers tools die efficiënt werken mogelijk maken.
Bedrijven zitten over het algemeen helemaal niet te wachten op self hosted applicaties. Beheer is tegenwoordig iets wat een ander voor je doet, er zelf uren instoppen is zonde.
Potentieel minder bespied worden door big tech en bij extensie overheden.
Geen licentie kosten
De meeste bedrijven hebben al iets van een Office 365-abonnement, dus daar zit het al bij in. (uiteraard betaal je er dan voor, want je krijgt niks gratis, maar je hebt het al)
geen vendor lock in
Dat hoor ik vaker, maar hoe is dat slecht in dit geval? (N.B. In het geval van Teams is er volgens mij geen vendor lock-in. Je kan prima een willekeurige andere tool gebruiken, of bedoel je wat anders?)
Ik maak even de vergelijking met Teams. De meeste bedrijven hebben al Windows desktops met de bijbehorende servers en de de facto standaard Office van Microsoft. Het is dan logisch dat je ook Teams gebruikt. Teams integreert makkelijk en relatief volledig in het geheel. Je moet het niet gebruiken, maar het is wel makkelijker in veel gevallen.
Stel dat er iets niet lukt, of stuk is, dan hoef je maar naar één toko te klagen, in plaats van dat de officetoko zegt dat je naar de videoconferencingtoko moet en andersom. Een vendor lock-in kan ook heel prettig zijn.
Stel dat er iets niet lukt, of stuk is, dan hoef je maar naar één toko te klagen, in plaats van dat de officetoko zegt dat je naar de videoconferencingtoko moet en andersom. Een vendor lock-in kan ook heel prettig zijn.
Nu praat je wartaal. Het kan heel fijn zijn om voor al je IT-gerelateerde zaken bij dezelfde partij aan te kunnen kloppen. Dat je nooit meer naar een andere partij kunt switchen (de lock-in) lijkt mij op geen enkele manier prettig.
Dat je nooit meer naar een andere partij kunt switchen (de lock-in) lijkt mij op geen enkele manier prettig.
Even los van dat Teams de facto geen vendor lock-in bevat. (je kan tenslotte ook Zoom of welke andere tool dan ook gebruiken. Al zal de integratie met andere diensten dan minder goed zijn gebouwd, maar dat is dan (deels?) een bewuste keuze. (afwegen wat belangrijker is voor de organisatie)
Maar goed: ik snap uiteraard wat je bedoeld, en het is natuurlijk ook niet 100% geweldig (probeerde ik niet te suggereren), maar soms wordt er gedaan alsof het het slechtste is wat je kan hebben. Men lijkt wel is te vergeten dat het ook rust biedt. Als je niet 'kan' switchen, is er dus ook nooit sprake van 'keuzestress' of allerlei langdradige onderzoeken naar welk product het best lijkt voor jouw toko.
Je hebt ook de facto vanuit de vendor gezien, altijd een 'standaard-omgeving'. De betreffende vendor kan dus betere ondersteuning bieden (want ze weten wat je hebt) en creëert daarmee dus ook automatisch een verantwoordelijkheid voor je, want ze bieden geen keuzes. Die ene vendor is verantwoordelijk dat haar product het ook altijd doet in combinatie met hun andere product.
Simpel voorbeeld:
Als je Red Hat Enterprise Linux gebruikt, moet je de facto Red Hat Satellite gebruiken voor je package-management. (Ja er zijn andere tools, of je kan al je servers aan het internet hangen en ze naar de cloud servers van Red Hat laten praten, maar dat is natuurlijk lang niet altijd wenselijk. Je hebt in de praktijk een lock-in naar Satellite). Red Hat biedt effectief alleen support als je je RHEL servers met Satellite laat praten. Technisch gezien kan het prima met Oracle Linux Manager (Spacewalk met een Oracle sausje) of Spacewalk. Echter. Red Hat biedt niet op een ondersteunde manier aan om hier mee te werken (o.a. de software repositories daarmee te synchroniseren, enz, enz, enz)
Er is dus een vendor lock-in met het gebruik van Red Hat Satellite als je RHEL gebruikt. Red Hat ondersteund alleen de volledige standaard stack, niet een afwijkende, ook al is het technisch gezien allemaal kinderlijk simpel om te doen.
Ook andersom is het net zo. Red Hat ondersteund alleen RHEL-clients voor Red Hat Satellite. Je kan prima Oracle Linux servers laten praten met Satellite. Werkt prima. Technisch makkelijk om uit te voeren. Alleen heb je geen ondersteuning en is het dus niet wenselijk om te doen. (het wordt overigens ook niet vanuit Oracle ondersteund. Die wil weer per se dat je OLM gebruikt (of platte RPM repos), dat is hun Vendor Lock-in)
De vraag is: Is dit per definitie erg? Het enige waar dit vervelend voor is, is dat je nu twee servers moet hebben. Één met Satellite en één met OLM. Anders dan dat heb je nergens last van.
Ja, lock-in is per definitie erg. Een leverancier die je een goed ecosysteem biedt is niet hetzelfde als een leverancier die je gijzelt. Er zit ongetwijfeld veel overlap in, maar het leuke (voor een vendor) bij een echte lock-in is dat je niet weg kúnt, en ze dus geen cent uit hoeven te geven aan een goede gebruikerservaring voor de klant.
Ik ben persoonlijk niet bekend met enige 'vendor lock-ins' waar je niet weg kunt. De enige lockins die ik ken zijn meer gebaseerd op een soort verplichte koppelverkoop.
Dus denk aan specifieke bajonetsluitingen van objectieven voor cameras, of bepaalde apparatuur die controleert of je een 'originele accu' hebt. Ik ben niet bekend met verdor-lockins waar je (effectief) niet weg kan/gegijzeld bent?.
Ik ben niet bekend met verdor-lockins waar je (effectief) niet weg kan/gegijzeld bent?.
Stel je voor, je maakt documenten. En je maakt die in Word. Dan zul je voor altijd aan Microsoft geld moeten geven om Word te kunnen gebruiken, want geen enkel ander programma kan .doc (of zelfs .docx)-bestanden fatsoenlijk weergeven. Dat is een lock-in. Doordat Word alleen werkt op MacOS of Windows, zit je ook redelijk vast aan Windows, ook een lock-in. Natuurlijk zou je voldoende hebben aan Word 97, maar die ondersteunt Microsoft niet meer, je moet de nieuweste Office 365 afnemen. Dat is niet vrijwillig. Microsoft kan de prijzen van office verhogen, terwijl ze al heel lang geen echt nieuwe features aan Word hebben toegevoegd, maar dat maakt niet uit, je moet blijven betalen. Lock-in.
Ben de .doc-indeling ben ik het deels met je eens. Microsoft heeft dat formaat vrijgegeven (weliswaar onder hoge druk), maar er is inderdaad nooit een derde partij gekomen die het voor elkaar kreeg om het goed te reverse-engineeren.
(( Aan de andere kant, als je inderdaad een garantie wil hebben dat je documenten tot in het einde der tijden leesbaar blijven is denk ik PDF een beter rijk-formaat (al is dat een andere discussie ) ))
Maar jij noemt het een vendor lock-in als derde partijen het niet voor elkaar krijgen om een open, vrij gedocumenteerde standaard (conform ISO-standaardisatie) niet kunnen implementeren? Dan gaat het nogal hard natuurlijk
PDF, en dat zeg ik blijkbaar niet vaak genoeg, is een fantastisch formaat voor printers. Ik heb het niet over documenten die je alleen wilt printen. Dus @xSNAKEX heeft feitelijk gelijk dat je niet aan enige lock-in kunt ontkomen en dat is geen goed ding. Als ik me de kritiek goed kan herinneren was de docx-specificatie ook een wassen neus met aanwijzingen als 'marges net zo renderen als in Word4.0'.
Nou ja, mijn punt is gemaakt, vendor lock-in is nooit wenselijk.
Bij welk documentformaat is dat niet zo? Zelfs ODF verpest het afhankelijk van de editor waar je het in opent.
De beste uitwisseling die ik tot nu toe heb gezien is in docx tussen MS Word en OnlyOffice. Niet perfect, maar toch. Maakt je voorbeeld overigens ook al weer wat minder.
edit: zie net dat ik te weinig van je post heb gelezen. Neem het maar met een flink korrel zout wat ik heb gezegd
edit2: Ah, threaded beperkingen. Mijn punt was al enigzins gemaakt. Lekker wakker ben ik.
[Reactie gewijzigd door xSNAKEX op 22 juli 2024 18:51]
Dit heb ik ook een beetje.
Ik snap prima dat er individuën zijn die het leuk vinden om zelf een servertje te hebben, of om principieel 'iets anders dan gebruikelijk' te hebben (snap ik oprecht, zelf ben ik er niet zo van. Ik zoek naar het product dat het beste bij mijn wensen past, en als dat een mainstreamproduct is, pak ik dat).
Misschien leuk voor een studentenhuis of universiteit die dit soort dingen graag in huis host? Of misschien als je een bedrijf hebt die volledig niets met Microsoft doet om welke reden dan ook (geen waardeoordeel natuurijk. Er kunnen prima redenen voor zijn) en Zoom niet fijn vindt, dan snap ik dat dit een fijn product kan zijn.
Echter. Wat ik zo lees is dat dit zuiver en alleen een videoconferencingtool is. Als je bijvoorbeeld naar Teams kijkt, dan integreert dit perfect (of in elk geval minimaal best goed) in Office. Dus voor bedrijven die toch al Microsoft Office gebruiken is het onlogisch om een product als dit te gebruiken. Althans. Dat lijkt mij.
Toen we bij mijn vorige werkgever initieel Teams gingen gebruiken (voornamelijk voor communicatie) vond ik het gelijk al best tekort schieten. Daarna heb ik het echt wel een kans gegeven, Veel beperkingen en tekortkomingen puur als chat en webconference app bestaan echter tot op de dag van vandaag nog steeds. O.a. traagheid, slecht zoeken, slechte browser implementatie (Firefox compatibiliteit) --, geen Webrtc, geen SSO met de rest van O365
Toen ik kort daarna een kale Debian VM voor een klant installeerde voor Mattermost en ze hun implementatie lieten zien hoe goed dit werkte, wat het allemaal voor ze deed en vooral hoeveel beter het werkte dan Teams was ik echt met stomheid geslagen. Waarom krijgt MS dit niet gewoon goed voor elkaar?
Het blijft gewoon de vloek. Intergratie is soms wat meer werk. Maar "best of breed" > "best of suite"
Als mensen niet oncomfortabel worden van Microsoft maar wel van een on-premise applicatie vind ik dat wel "bijzonder".
De één is programma van en lopende op infra van een gezichtloos bedrijf in het buitenland met anderhalve ton werknemers.
En de ander is een open source applicatie dat loopt op de infra van het bedrijf waar je mee wil praten met een herkenbaar persoon/team aan de knoppen.
zie ik niet zo in waarom ik minder afhankelijk van big tech zou moeten zijn.
<knip>
De kosten voor een teams licentie zullen snel weg te strepen zijn tegenover een beheerder die dit opzet en moet onderhouden.
Wat denk je dat de kosten doen zodra je echt afhankelijk bent?
De vraag is een beetje hoe je omgeving hierop gaat reageren. Mensen zijn toch gewoontedieren en inmiddels gewend aan teams en (in mindere mate) zoom. Als je nu ineens met een andere tool aankomt zal dat mensen oncomfortabel maken.
Een van de voordelen van Jitsi is dat het erg goed werkt in je browser zonder apps. Je klikt op de link en het werkt. Dat maakt de adoptie erg makkelijk.
Maar eerlijk gezegd vind ik de reactie van de omgeving niet zo interessant. De omgeving is laltijd tegen vernieuwing, doet er niet toe wat, zeker als er geen grote nieuwe features zijn. Het is aan ons om de wereld te overtuigen van de onzichtbare voordelen die "gewone" gebruikers niet belangrijk (denken te) vinden.
Vanuit de zakenwereld denk ik ook dat er weinig interesse zal zijn.
De video zelf is inderdaad niet zo boeiend. Dat gaan ze echt niet opslaan, want dat kost gewoon teveel. Maar big tech zal vast zijn AI loslaten om bots te trainen en services te optimaliseren voor winstbejag. Maar de data eromheen, de chats, de bestanden, wie met wie contact heeft. Dat is natuurlijk allemaal wel interessant voor diverse partijen (om door te verkopen).
Het is jammer dat dit weer linux-only is. Docker is leuk, maar vreet toch meer resources dan je eigenlijk wilt (10% idle load is voor 24/7 standby toch nog prijzig). Maar de resources an sich is vrij hoog om dit aan een groot team uit te rollen imo. Ja voor een hello world tutorial op Tweakers zal het vast goed te doen zijn, maar dit soort services laten zich altijd maar lastig schalen. 100 deelnemers is voor veel bedrijven peanuts als je alleen al kijkt naar de stand-up sessies van alle ontwikkel teams in de ochtend.
Verder is het fijn om een webclient te zien. Ik denk dat dit voor de meesten wel de beste oplossing is. Ook externen kun je dan gewoon een linkje sturen.
Dit artikel beschrijft vooral het opzetten van een eigen server. Zijn er mensen die praktische ervaring hebben met Jitsi via de bestaande community servers?
Verschil/overeenkomsten met 'the usual niet zo privacy minded aanbieders (Teams/Skype/etc)'?
Ervaringen met grote groepen en de diverse community servers?
Wat is de toegevoegde waarde vd 8x8 Meet service/app?
Ik heb ooit naar Jitsi gekeken en wat links verzameld, maar ben er nooit verder mee gegaan (jammer, want volgens mij heeft het veel potentie).
Jitsi is geweldig. De performance is zo enorm veel beter dan dat stroperige gedrocht MS Teams dat we op het werk gebruiken. En het prioritiseert frame rate over beeldkwaliteit en dat is fijn want daardoor kan je subtiele uitdrukkingen makkelijker herkennen. De laatste maanden kan Teams niet eens meer goed de status van gesprekspartners bijhouden, die blijft vaak hangen en als je dan op zo'n gesprek klikt dan wordt de status opeens bijgewerkt naar de huidige.
En het heeft niet de smerige trucjes van Zoom dat bijvoorbeeld een rootkit installeerde op Macs. En nog weigerde die te verwijderen ook todat Apple dat voor ze deed. Omgekeerde wereld.
Overigens heb ik het niet self hosted, ik gebruik gewoon de open server https://meet.jit.si
[Reactie gewijzigd door GekkePrutser op 22 juli 2024 18:51]
Werkt goed, op mijn werk gebruiken we het sinds begin Corona (vanwege veiligheid) voor bepaalde meetings i.p.v. Teams. In de eerste paar maanden was het nog wat vallen en opstaan, maar tegenwoordig een goed programma.
https://meet.jit.si/ kwaliteit is zelfs bij 1 op 1 van dial-up kwaliteit of minder. Ik hoor al jaren hoog opgegeven worden van Jitsi, maar in de praktijk is de ervaring zo, dat je zegt alles behalve Jitsi.
Eens kijken of ik bij de reacties blijf kunnen want dit is gratis artikel 1.
Ik pas Jitsi al toe sinds het begin van de pandemie in de GGZ instelling waar ik werk. Ik had het gelukkig al veel eerder ontdekt waardoor ik binnen een paar dagen de behandelaren aan het videobellen had. Het moeilijkste was om genoeg webcams bij elkaar te sprokkelen
De behandelaren zijn er zeer over te spreken en de cliënten ook, alleen videobellen als vervanger van fysieke sessies is er niet bij behandelaren en cliënten.
Een aantal behandelaren vroegen hoe dit gratis kon zijn zonder dat er informatie verkocht wordt. Zie je maar weer hoe mensen denken over Big Tech en hun verdienmodel.