UFFICIALE L'OT di Linux e altri OS

Pubblicità
lele.deb ha detto:
1) Per noi utenti finali non cambia molto usare Mir o Wayland, neanche ci accorgiamo quale usiamo.
2) Per i vari sviluppatori, non c'è molto da fare nel supportare sia Mir che Wayland, perché entrambi fanno uso di OpenGL e delle API EGL. L'esempio è unity3D, che per supportare sia Xorg + Mir + Wayland si è appoggiato a SDL2 che supporta tutti e 3, in questo modo supporta tutti i server grafici.

https://www.phoronix.com/scan.php?page=news_item&px=Unity-SDL-Port

Ripeto, possiamo fare lo stesso discorso sul package manager, prendiamo Arch, l'ultima arrivata delle distro principali, ha creato un altro package manager, invece di usare quelli esistenti, possiamo fare delle critiche anche su questo.
Clicca per espandere...
Beh, c'é scritto che il tizio dopo qualche trick é riuscito a far andare l'engine di Unity e non é detto che tutti gli sviluppatori siano disposti a farlo, ed inoltre conta semre più la qualità che la quantità, per cui bisogna vedere in che modo supporti tutti e tre i server grafici.
Ad ogni modo stiamo a vedere.

Comunque l'esempio di Arch non regge molto in piedi. Stiamo parlando di un package manager(che tra l'altro trovo essere il migliore fra quelli binari), non di un server grafico.
La differenza, in questo caso, è che uno é un problema di chi gestisce la distro, mentre l'altro crea solo difficoltà a tutti(soprattutto ai developers)
 
Ultima modifica da un moderatore:
AES ha detto:
Beh, c'é scritto che il tizio dopo qualche trick é riuscito a far andare l'engine di Unity e non é detto che tutti gli sviluppatori siano disposti a farlo, ed inoltre conta semre più la qualità che la quantità, per cui bisogna vedere in che modo supporti tutti e tre i server grafici.
Ad ogni modo stiamo a vedere.

Comunque l'esempio di Arch non regge molto in piedi. Stiamo parlando di un package manager(che tra l'altro trovo essere il migliore fra quelli binari), non di un server grafico.
La differenza, in questo caso, è che uno é un problema di chi gestisce la distro, mentre l'altro crea solo difficoltà a tutti(soprattutto ai developers)
Clicca per espandere...
Il problema dei package manager è un problema di non poco conto, come lo può essere un server grafico ,che in questo caso per supportare tutti e due basta pochissimo(EGL). Invece per il package manager ogni sviluppatore deve creare il pacchetto per ogni singola distro, cioè deve fare lo stesso lavoro minimo 4 volte, con la differenza che ognuno funziona in maniera diversa... Ecco perché ci sono snap e flatpak, per rimuovere questo problema.
PS: pacman di sicuro ha le sue qualità, è ottimo, ma non il migliore, APT è un package manager molto ma molto avanzato.
 
lele.deb ha detto:
Il problema dei package manager è un problema di non poco conto, come lo può essere un server grafico ,che in questo caso per supportare tutti e due basta pochissimo(EGL). Invece per il package manager ogni sviluppatore deve creare il pacchetto per ogni singola distro, cioè deve fare lo stesso lavoro minimo 4 volte, con la differenza che ognuno funziona in maniera diversa... Ecco perché ci sono snap e flatpak, per rimuovere questo problema.
PS: pacman di sicuro ha le sue qualità, è ottimo, ma non il migliore, APT è un package manager molto ma molto avanzato.
Clicca per espandere...
A dire il vero anche i maintainer delle distro se ne occupano, tant'é che uno li ha definiti pure "impacchettatori a tempo perso".
La questione, in questo caso, é un'altra, dal momento che se i developers utilizzano ubuntu come distro di riferimento, c'é il rischio di tagliare fuori le altre, e, come ti ho detto, non conta quanti server grafici supporti, ma il MODO.
APT é così avanzato che ho il tempo di farmi un caffé con la caffettiera quando devo installare qualcosa.
 
AES ha detto:
A dire il vero anche i maintainer delle distro se ne occupano, tant'é che uno li ha definiti pure "impacchettatori a tempo perso".
La questione, in questo caso, é un'altra, dal momento che se i developers utilizzano ubuntu come distro di riferimento, c'é il rischio di tagliare fuori le altre, e, come ti ho detto, non conta quanti server grafici supporti, ma il MODO.
APT é così avanzato che ho il tempo di farmi un caffé con la caffettiera quando devo installare qualcosa.
Clicca per espandere...
Esagerato... APT è uno dei più veloci, se lo paragoniamo al gestore pacchetti di OpenSuse Fedora etc... Con pacman la differenza è poca e in alcuni casi nulla.

Poi paragoniamo un gestore pacchetti che è usato a livello enterprise(Debian Ubuntu LTS) con un gestore pacchetti che è usato da nerd e a livello home.
 
AES ha detto:
Mboh, sarà.....con Debian ci misi una vita per installare i driver Nvidia.
Clicca per espandere...
E cosa c'entra... :boh:
Comunque, non parole mie, ma di un dipendente Google, e sul perché hanno scelto in azienda Ubuntu e non altre distro...

Bushnell, inoltre, ha spiegato che la scelta è ricaduta proprio su Ubuntu (e non su Fedora, Red Hat e simili) innanzitutto per via del meccanismo di pacchettizzazione basato su apt che, per citare le parole di Bushnell stesso, «è avanti anni luce rispetto, ad esempio, ad RPM». Inoltre «Canonical offre un servizio di aggiornamenti ed un servizio di supporto fatti davvero come si deve»: non solo, quindi, in Google utilizzano Ubuntu ma… Google è anche un cliente pagante di Canonical per quello che riguarda il servizio di support
Clicca per espandere...
 
lele.deb ha detto:
E cosa c'entra... :boh:
Comunque, non parole mie, ma di un dipendente Google, e sul perché hanno scelto in azienda Ubuntu e non altre distro...
Clicca per espandere...
Che con pacman ci metto meno ad installare le cose..:boh:?
Adesso..giuro che non lo faccio per qualcosa di personale contro Canonical, ma ovviamente essendo un'azienda, può offrire cose che le altre non offrono(Fedora ed OpenSuse sono principalmente community-driven), per cui se fa cose "speciali" per Google, in maniera tale che entrambe ci guadagnino, cosa potrebbe mai dire un dipendente di Google :lol:?
 
@AES
In che senso meno tempo ad installare le cose??
Perchè se parliamo di grandezza di repo, quello di arch è piuttosto piccolo (6000 pacchetti contro i 50000 di debian) dato che la maggiorparte dei pacchetti sta su aur, quindi l'update del repo è ovviamente più veloce (a parità di connessione/velocità dei server).
 
cdtux ha detto:
@AES
In che senso meno tempo ad installare le cose??
Perchè se parliamo di grandezza di repo, quello di arch è piuttosto piccolo (6000 pacchetti contro i 50000 di debian) dato che la maggiorparte dei pacchetti sta su aur, quindi l'update del repo è ovviamente più veloce (a parità di connessione/velocità dei server).
Clicca per espandere...
No no, parlo proprio dei tempi che servono per installare un programma.
 
lele.deb ha detto:
Poi paragoniamo un gestore pacchetti che è usato a livello enterprise(Debian Ubuntu LTS) con un gestore pacchetti che è usato da nerd e a livello home.
Clicca per espandere...

questo solo perché arch è meno diffusa e non pensata propriamente per uso server... altrimenti voglio proprio vedere se pacman fosse stato scartato in favore di apt
 
AES ha detto:
No no, parlo proprio dei tempi che servono per installare un programma.
Clicca per espandere...

a ok..
onestamente non ho mai fatto particolarmente caso se ci fosse tutta questa differenza, comunque mi sono sempre sembrati abbastanza veloci entrambi, pacman forse un po di più, ma niente di così evidente..
Alla prima occasione ci presterò più attenzione..
 
Pacaman è legegrmente più leggere perché non ha i controlli che ha APT/dpkg, essendo una distro non pensata per uso workstation, è leggero e semplice. Su apt puoi avere dei ritardi se ci sono post inst script che aggiungono repo etc.. Tipo i trigger: https://manpages.debian.org/jessie/dpkg-dev/deb-triggers.5.en.html
Parliamo di un gestore pacchetti che è nato ieri(pacman) con uno che è nato da parecchi anni(16 agosto 1998)...
 
lele.deb ha detto:
Pacaman è legegrmente più leggere perché non ha i controlli che ha APT/dpkg, essendo una distro non pensata per uso workstation, è leggero e semplice. Su apt puoi avere dei ritardi se ci sono post inst script che aggiungono repo etc.. Tipo i trigger: https://manpages.debian.org/jessie/dpkg-dev/deb-triggers.5.en.html
Parliamo di un gestore pacchetti che è nato ieri(pacman) con uno che è nato da parecchi anni(16 agosto 1998)...
Clicca per espandere...
Che tipo di controlli esattamente? Perchè ad esempio il controllo dell'integrità lo fa pure pacman.
 
Pubblicità
Pubblicità
Indietro
Top