UFFICIALE L'OT di Linux e altri OS

Pubblicità
EmanueleC ha detto:
È progettato cosi, non cambierà mai, anzi se il futuro sarà solo APP snap su Ubuntu, ilo problema aumenterà.
Gli sviluppatori lo sanno e non possono far nulla, perché "è cosi che funziona snap"..
Disinstalla snapd e metti flatpak ?
Clicca per espandere...
Snap bello purgato. Rimango come ho sempre fatto sui server, installazione manuale che quella funziona sempre e so che combina il tutto xD
 
Posso dirti il mio parere personale:
Io uso flatpak perché per installare le APP è molto più comodo rispetto ad apt/dnf oltre ad essere molto più sicuro e a prova di rotture:
- Non ho problemi di dipendenze ad ogni update dell'OS o dell'APP;
- Nessun problema a installare un APP all'ultima versione, anche su distro LTS, dove non puoi con i package perché la dipendenza X troppo inferiore alla dipendenza X che richiede l'APP;
- upgrade veloci upstream, senza aspettare il manutentore della distro X;
- Flessibilità:
posso fare backup di tutte le APP flatpak
posizionare la sua cartella su altro disco se la mia radice è piccola
Decidere se installare l'APP multi user o single user
decidere se installare l'APP sul sistema o sulla home (magari ho la home separato su altro disco, in questo modo è single user, ovviamente)

Sicurezza: https://github.com/flatpak/flatpak/wiki/Sandbox
Riproducibilità: https://docs.flatpak.org/en/latest/introduction.html#reasons-to-use-flatpak
 
bigendian ha detto:
preche usare snap/flatpack ?
Clicca per espandere...

Perchè comandano Canonical e Redhat. Canonical è l'amichetta di Microsoft. Redhat di IBM.

Quindi bisogna soggiacere o passare a FreeBSD ?

Che poi tutta sta manfrina per ottenere gli stessi risultati che si avrebbero con programmi linkati staticamente!! Solo che qui, ogni programma si tira dietro un intero sistema operativo ?

E dicono pure che è il futuro.
 
Sempre riuscito a evitare porcate simili per ora.

Un giorno inventarono le dll, uno dei motivi era non avere lo stesso codice usato da molte applicazioni e risparmiare un po' di disco. Poi arriva apple con i suoi bundle a prova di scemi e tutti a copiare le stesse filosofie. Facciano pure, ma non nel mio pc :)
 
bigendian ha detto:
Sempre riuscito a evitare porcate simili per ora.

Un giorno inventarono le dll, uno dei motivi era non avere lo stesso codice usato da molte applicazioni e risparmiare un po' di disco. Poi arriva apple con i suoi bundle a prova di scemi e tutti a copiare le stesse filosofie. Facciano pure, ma non nel mio pc.
Clicca per espandere...

Una nota simpatica sulle dll, è che la ragione ufficiale più notare circa la loro nascita, era quella di risparmiare spazio. In realtà furono create per poter modificare il comportamento dei programmi di cui non si disponeva il codice ( sfruttando i meccanismi di preloading, tipo LD_PRELOAD sotto Linux ), per il debugging/tracing ( sempre tramite LD_PRELOAD e similari ) e per implementare il caricamento/scaricamento dinamico di codice nel programma ( specialmente gli overlay, ai tempi in cui 640K di memoria erano un lusso ).

Poi è stessa introdotta ( quando le 3 di sopra vennero a cadere, tranne la seconda che è ancora utile ) la ragione che tutti conosciamo.

Il bello è che la numero 1 è sfruttabile dai malware!!
 
non per polemizzare, ma mI pare strano che M$ abbia creato le dll, di cui si componeva gran parte dei primi windows, per craccare programmi di cui non disponeva del codice, preload permette di caricare uan dll piuttosto di un altra, ma allora erano gia state inventate prima ?
 
bigendian ha detto:
non per polemizzare, ma mI pare strano che M$ abbia creato le dll, di cui si componeva gran parte dei primi windows, per craccare programmi di cui non disponeva del codice, preload permette di caricare uan dll piuttosto di un altra, ma allora erano gia state inventate prima ?
Clicca per espandere...

No, serviva a consentire l'instrumentation dei binari. Non conosco comunque le ragioni di MS, ma considerando che le librerie dinamiche esistono dai tempi di Multics, è possibile che MS abbia deciso di seguire il trend ed adeguarsi.

Ma dal loro punto di vista, le dll erano un meccanismo per dare ad utenti/sviluppatori di terze parti un modo per alterare il comportamento dei programmi MS. E ovviamente per funzionalità avanzate di debugging automatico.

Infilare delle funzioni ( repliche di funzioni della libc o di altre API, ma con delle aggiunte che servano ai propri scopi ) in un binario, senza doverlo ricompilare da sorgenti, consente di fare cose molto interessanti. Praticamente realizzi l'overriding delle funzioni di librerie!! E il tutto disponendo solo dei binari.
 
ok buono a sapersi. Certo che non hanno inventato loro le librerie dinamiche, ma che tra i motivi ci fose quello di agevolare sviluppatori o terzi, da parte di m$, in quei tempi di software piuttosto chiuso, mi stupisce.

In termini puramente ecologici, che va molto di moda, avere codice multiplo in disco e in ram non e' il top. Ma va bene, fin che le multinazionali smerxxxdano il mondo con sovraproduzioni di ogni cosa, non c'e' problema. Poi le colpe tanto le daranno a noi.
 
bigendian ha detto:
ok buono a sapersi. Certo che non hanno inventato loro le librerie dinamiche, ma che tra i motivi ci fose quello di agevolare sviluppatori o terzi, da parte di m$, in quei tempi di software piuttosto chiuso, mi stupisce.
Clicca per espandere...

Non dovrebbe stupire. Il motto di MS è sempre stato "developers, developers, developers". Sono ben coscienti del fatto che il loro successo sia dovuto al gigantesco ecosistema di software di terze parti che si è venuto a creare intorno a Windows.

bigendian ha detto:
In termini puramente ecologici, che va molto di moda, avere codice multiplo in disco e in ram non e' il top. Ma va bene, fin che le multinazionali smerxxxdano il mondo con sovraproduzioni di ogni cosa, non c'e' problema. Poi le colpe tanto le daranno a noi.
Clicca per espandere...

Il problema è che col linking statico vai a prelevare il codice solo delle funzioni che realmente usi, mentre una libreria dinamica te la tieni con tutto quello che c'è dentro.

E' un dibattito che va avanti da anni, anche a certi livelli. Per esempio, i creatori di Golang ( non esattamente i primi arrivati ) implementarono inizialmente solo il linking statico. E i binari non avevano dimensioni particolarmente preoccupanti. Poi, causa proteste di massa, dovettero implementare pure il linking dinamico.

Personalmente ho trovato veramente utili le librerie dinamiche solo in quei casi di software con architettura a plugin. La possibilità di aggiungere/togliere funzionalità o "attaccare" a runtime una certa implementazione di una particolare funzionalità, ti cambia davvero la vita. Ma parliamo di software molto grandi e sofisticati. Imho si abusa eccessivamente delle dll.
 
Per gcc, senza appositi flag di compilazioni, non incluudi solo il codice usato. Cmq, si, anche io linko statico in tutti i lavori che consegno, dove posso, per evitare problemi. Tuttavia mantengo mio sistema totalmente esente da qualsiasi filosofia che non viene con i pacchetti di base.
 
bigendian ha detto:
Per gcc, senza appositi flag di compilazioni, non incluudi solo il codice usato. Cmq, si, anche io linko statico in tutti i lavori che consegno, dove posso, per evitare problemi. Tuttavia mantengo mio sistema totalmente esente da qualsiasi filosofia che non viene con i pacchetti di base.
Clicca per espandere...

Vabbè i compilatori C++ sono noti per essere ognuno per sè. Non sono mai riusciti nemmeno a mettersi d'accordo sul metodo di mangling. Figurarsi su quali azioni intraprendere per default durante il linking.

Sarà interessante vedere cosa succederà adesso che la LTO ha cominciato a prendere piede.

Sulle distribuzioni, beh, credo sia un lavoro un pelino impegnativo creare da zero una distro dove tutto è linkato staticamente. Ne esistono un paio, ma basta guardare al ridotto numero di pacchetti disponibili, per capire che non è propriamente una strada percorribile.

E' la stessa ragione per cui, pur essendo un fan di Musl, sono costretto ad usare Glibc!!
 
A me inbtanto tocca fixare continuamente mmu per arch coldfire nel kernel


Uno dei problemi del kernel Linux e' che spesso alcuni guru fanno modifiche che coinvolgono architetture che non possono essere testate, per mancanza dell'hardware che non possiedono. Poi, chi ha l'hardware scopre che il kernel non funziona piu. E si deve smazzare la ricerca del problema.
 
Pubblicità
Pubblicità
Indietro
Top