La serviciu folosim, în principal, două aplicații de remote desktop: TeamViewer și ISL Online. Dacă pe Debian și distribuțiile construite în jurul acesteia ambele funcționau aproape impecabil, pe CachyOS nu reușesc să folosesc niciuna în parametri optimi. TeamViewer pare că funcționează normal până în momentul în care încerci efectiv să te conectezi la un alt PC, moment în care conexiunea eșuează.
ISL Online, în schimb, are un lag atât de mare încât face utilizarea sa practic imposibilă. Este o situație frustrantă, mai ales că vin de pe o distribuție unde totul mergea „brici”. Dar această experiență mi-a reamintit, a câta oară, de una dintre cele mai mari probleme ale ecosistemului Linux: fragmentarea și lipsa standardizării.
De ce depindem de aceste soluții specifice?
Probabil vă întrebați de ce nu trecem la alte soluții. Răspunsul e simplu: constrângerile tehnice și procedurale. Prima cauză este suportul ISL pentru dispozitivele Android, care încă este foarte limitat. Aici nu mă refer doar la compatibilitatea cu diverse modele, ci și la funcționalități. TeamViewer, de exemplu, are în unele cazuri inclusiv addon-uri specifice producătorilor pentru control total.
În cazul ISL, clientul (aplicația de pe dispozitivul final) nu poate fi legat permanent de un cont pentru acces nesupravegheat în toate scenariile; trebuie generat un ID de sesiune, iar utilizatorul trebuie să introducă manual în aplicație codul temporar pe care i-l dictăm noi.
Trebuie să le am pe ambele disponibile pentru momentele când sunt de gardă și trebuie rezolvat ceva ce nu poate fi remediat prin RDP (pentru care folosesc Remmina) sau SSH. Se întâmplă frecvent ca un telefon pe care utilizatorul are permisiuni foarte limitate să refuze rularea unei aplicații, să corupă baza de date locală sau să aibă alte probleme de sistem. Utilizatorul, neavând acele permisiuni, nu poate remedia problema urmând instrucțiunile noastre verbale, așa că intervenția directă este obligatorie.
Soluția de avarie și realitatea din teren
Sincer vorbind, incompatibilitatea nu mă afectează critic, pentru că am Surface-ul. Atunci când sunt de gardă, îl iau după mine inclusiv dacă merg în parcul din apropiere. În 99% din cazuri, rezolv problema mai rapid așa decât dacă m-aș întoarce acasă (ceea ce ar dura 3-4 minute). Iar dacă problema necesită mai mult timp, găsesc o scuză banală și promit că revin cu un apel în câteva minute.
Totuși, ceea ce vreau să subliniez e ideea că nu există trei mari sisteme de operare, cum se tot spune (Windows, macOS și Linux). Există Windows, macOS și multe, foarte multe „Linux-uri”. Dezvoltatorii de software comercial care vor să fie prezenți pe Linux, adesea doar de dragul aparențelor sau pentru a bifa o cerință contractuală, aleg calea minimei rezistențe: dezvoltă o versiune stabilă pentru Debian/Ubuntu (pachete .deb) și poate una pentru Red Hat/Fedora (pachete .rpm), deoarece acestea sunt cele mai folosite în mediile corporate. Restul distribuțiilor rămân să se descurce cum pot.
Fragmentarea: O istorie a bunelor intenții eșuate
Această fragmentare este al naibii de frustrantă și nu se rezumă doar la cele două aplicații menționate, ci este o problemă sistemică. Teoretic, containerele universale trebuiau să rezolve această problemă definitiv. Promisiunea a fost simplă: „build once, run anywhere”.
În realitate, istoria s-a repetat conform meme-ului clasic xkcd despre standarde. În loc să avem un format universal, acum avem o „ciorbă” și mai mare:
- Pachetele clasice (.deb și .rpm): Rămân standardul de aur pentru stabilitate, dar sunt legate strict de distribuție și versiunile de biblioteci din sistem.
- Snap: Împins puternic de Canonical (Ubuntu), a fost printre primele încercări moderne de a crea pachete universale, cu toate dependențele incluse. Deși a prins tracțiune pe servere și IoT, natura sa centralizată și controlată de o singură companie a atras antipatia unei părți a comunității.
- Flatpak: Răspunsul comunității și al celor de la Red Hat, gândit special pentru aplicații desktop. Este descentralizat și preferat de mulți utilizatori Linux pentru că se integrează mai bine cu diverse medii desktop, dar nu toți dezvoltatorii comerciali îl adoptă oficial.
- AppImage: O abordare de tip „fișier portabil” (similar cu
.exeportabil din Windows), excelent pentru testare rapidă, dar greu de gestionat și actualizat centralizat.
Rezultatul? O nouă fragmentare. Marii dezvoltatori aleg ce li se pare mai convenabil (de obicei .deb sau poate Snap), iar utilizatorii de Arch (sau CachyOS, în cazul meu) trebuie să se bazeze pe reîmpachetări făcute de comunitate în AUR sau pe binare care nu se „pupă” perfect cu bibliotecile sistemului, rezultând în lag, erori de conexiune sau lipsa unor funcționalități.
Dacă toți giganții din industrie și comunitatea și-ar fi concentrat eforturile pe un singur format (să zicem Snap, fiind primul, sau Flatpak, fiind mai deschis), în acești 16 ani care au trecut, aveam deja un standard universal robust. Nu am mai fi vorbit astăzi despre conversii din .deb în .zst sau despre incompatibilități de biblioteci glibc. Dar nu, ideea prevalentă rămâne că Linux înseamnă „Libertate”, iar asta a fost interpretată ca „libertatea de a ne diviza în sute de grupulețe incompatibile”.
Sigur, diversitatea e bună pentru inovație, dar când vine vorba de adoptarea pe desktop și suportul software comercial, această divizare este exact motivul pentru care, probabil, Windows va rămâne acel „spyware imens” pe care toată lumea îl folosește, pur și simplu pentru că acolo lucrurile… merg.
