On Mon, Dec 14, 2020 at 7:48 PM Mihai Badici <mi...@badici.ro> wrote:
> > Debian mai are o problemă pe care de exemplu slackware nu o avea, că > dacă li se pare lor că un driver nu e political correct îl scot din > kernel, pe când slackware e pe filozofia "unmodified packages" . Asta se > traduce în diverse probleme cu plăci wireless mai noi, destul de > supărătoare, mai ales că de cele mai multe ori chinezul care a scris > driverul nici nu știe ce a scris în disclaimerul ăla :) > > Sincer, chestia asta nu e o inconvenienta asa mare. Dincolo de aspectele filozofico-metafizico-culturale (unde sincer imi convine sa pot numara pe degete chestiile not rms-friendly de pe sistem), din punct de vedere practic, e vorba de rulat 2-3 comenzi in plus si atat. Pachetul se publica in non-free sau contrib (in functie de cat de tare e legat de blobul cu pricina), eventual te pune sa agreezi explicit la ceva licente non-free sau are helper scripts care sa-ti traga blobul de pe net daca n-are voie sa fie redistribuit si cam aia e. Iar la chestiile gen drivere de kernel care ar fi mandatory la instalare (placi de retea), exista intretinuta imagine care contine firmware-urile alea in ea, trebuie sa iei la cunostinta ca o sa planga un pinguin cand o downloadezi (pana acum a mers pe orice laptop pe care am incercat). Filozofia aia cu modificat upstream e iarasi o chestie pozitiva in opinia mea (repet, imho, subiectiv, discutabil). Unul din lucrurile pentru care ma simt in elementul meu pe Debian e ca impune maintainerilor sa intretina cat de cat documentatie intr-un anume fel (ai mereu in /usr/share/doc/$pachet macar ceva, macar readme.md-ul de pe github si niste scuze ca atata vrea upstream sa intretina; binarele au in general man page, ocazional patchuri care sa suporte config.d folders unde sa poti lasa fragmente de config diferite, etc). In ultima vreme sunt cateva discutii despre cum sa se intretina soaftele care au prin natura lor ciclu de viata mult mai mic decat release cycles de Debian, pana acum am vazut debate-ul asta despre browsere si kubernetes (si ocazional cauzeaza titluri de scandal gen "debian vrea sa scoata chrome si firefox"). Alta problema semi-metafizica curenta e ca by policy pachetele Debian se buildeaza in Debian si asta tinde sa fie o problema in ecosisteme cu fractal foarte adanc de dependinte, gen Go sau NPM, de un potential maintainer trebuie sa faca packaging la tot carnatul de dependinte inainte de pachetul pe care-l voia (sau sa se certe pe liste cu security si ftpmasters samd despre de ce e o idee buna sa vendorizeze), iarasi ceva ce nu prea conteaza pt. userul final (altfel decat "softul X nu e in debian, va trebui sa-l iau ca animalele din alt repo" - dar problema asta e mult mai rara decat era pe alte distrouri si poate de-aia e enervanta). Sincer, daca nu erai toata ziua cu surubelnita in matele os-ului, diferentele sunt relativ minore, cateva tooluri care se cheama putin altfel (dpkg si rpm au mult mai multe asemanari decat diferente, apt si yum la fel), cateva defaults care sunt altfel dar se rezolva cu niste dotfiles (stiu oameni care sunt convinsi ca rm pe centos e altul decat pe debian, doar pentru ca sunt niste aliasuri default cu -i, parca), si niste configuri care nu-s chiar in acelasi loc si forma dar esenta e aceeasi ( daca eu am gasit in general prin /etc/sysconfig tot ce cautam prin /etc/default, banuiesc ca merge si invers). On top of this, cateva pachete care nu se cheama chiar la fel sau sunt impartite nitel altfel. All in all nu sunt schimbari mult mai mari decat intre Centos6 si Centos7 de exemplu. -- Petre, proudly defaulting to Debian since 2004. -- _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
