Quindi ho ragione io: lo standard c'è, ma ognuno fa come gli pare.
Vabbe', hai ragione.
rik70 ha scritto:e i binari dove li metto: /usr/bin/, /bin/ /opt/bin ?
GNU/Linux è già da diverso tempo che sta facendo il merge / - /usr.
E in ogni caso /opt va usato solo con software closed non pacchettizzato e software compilati custom o statici, /bin se sono software che dovrebbero girare anche in runlevel 1 e /usr/bin se è roba multi-user.
La hier ha definito i ruoli di queste directory più di trent'anni fa. Non penso che nel 2015 ci sia ancora bisogno di farsi 'ste domande.
Se c'è ancora qualcuno che se lo chiede allora mi sa che questa gente ha ben altri problemi.
Di queste cose se ne parla da più di un decennio e siamo ancora a questo punto.
Veramente le cose stanno cambiando già da un po'.
E non soltanto come fusione di parte dell'hier, ma proprio come metodo di packaging che va a sostituire completamente l'organizzazione attuale.
E guarda caso le cose stanno cambiando proprio su RH e Ubuntu.
Ma tu ragioni più dal punto di vista "business", come se tutti dovessero prendere da subito una specializzazione in qualcosa, e seguendo il tuo ragionamento dovremmo usare tutti Unity, perché ubuntu è lo standard de facto. Ma se vale il ragionamento, lo standard de-facto per il mondo desktop è Windows: quindi che perdo tempo a fare con Linux?
È quantomai evidente che tu non vuoi capire il discorso che sto facendo.
Non parlo di business, ma di ciò che OGGI è considerato il riferimento.
Se io devo imparare una piattaforma vado nell'ambiente che più lo rappresenta. Non vado su una distro che non ha legami con l'ecosistema attuale e che ha una politica di evoluzione propria. È stupido quasi quanto pensare che se imparassi OpenBSD allora potrei usare Debian senza problemi perché la prima è più UNIX.
Non servirebbe a niente. Non ti darebbe la conoscenza di nulla, perché gli strumenti che poi andresti ad usare NON CI SONO.
Il che vuol dire che quando andrai ad usare distro mainstream dovrai riprendere il manuale e la documentazione come un principiante qualsiasi e ti renderai conto che tutto il bagaglio acquisito su Slackware è stato quasi interamente sprecato.
L'unica cosa di cui al massimo ti darebbe conoscenza sono i soliti comandi unix, ma se è quella la conoscenza a cui stai mirando allora ti basta pure Windows + CygWin.
E non è che imparare a capire come funzionano gli SlackBuild ti darebbe qualche vantaggio con gli SPEC File. Non li capiresti comunque perché sono basati su un framework che estende bash con delle macro.
Acquisire la "forma mentis" di GNU/Linux è una cosa che non puoi fare più su Slackware perché GNU/Linux oggi è un sistema completamente diverso.
GNU/Linux non è più modularità, non è più decentralizzazione degli strumenti e messa in comunicazione tramite pipe e redirezione, non è più scelta e flessibilità, non è più un preferire l'uso di testo al binario.
GNU/Linux oggi è integrazione assoluta, accentramento in poche parti che diventano critiche ed evoluzione continua anche a scapito della rottura delle tradizioni.
Slackware continua a seguire i principi di design UNIX. GNU/Linux no. Anzi, ormai si sta sputando in faccia a tutto ciò che ha caratterizzato UNIX per cinquant'anni.
Ti faccio un esempio, dato che continui a non capire.
Tu parli di imparare a costruire un pacchetto, eppure questa tra pochi anni sarà una conoscenza obsoleta.
In ambiente RH e Ubuntu si stanno sviluppando soluzioni in stile bundle comprensivo di dipendenze (o a compilazione statica), e caratterizzato da una forte integrazione del package manager con il file system, con systemd, con Docker e con framework di sicurezza SELinux/AppArmor.
Perché? Perché la compilazione dinamica sta mostrando i suoi limiti, perché si è arrivati al punto che bisogna separare lo spazio applicativo dal sistema, perché ad oggi non c'è un metodo di rollback che garantisca efficienza, perché c'è uno scarso legame tra le tecnologie che compongono l'ambiente sottostante ecc.
Questo è il futuro in ambiente GNU/Linux. E questo è ciò che un domani diventerà lo standard. E l'idea del pacchettino + dipendenze sarà una cosa che ci lasceremo alle spalle.
Pensi che Slackware adotterebbe subito un cambio di modus operandi così di punto in bianco? No, non lo farebbe. Anzi, rimarrebbe con i pkgtools finché ci sarebbe la possibilità di mantenere questo tipo di infrastruttura. Proprio come sta facendo con systemd.
Quindi quanto di questo know how saresti in grado di ottenere con Slackware?
Quanta della "forma mentis" necessaria?
Penso che chiunque con un po' onestà intellettuale e senza visioni offuscate dal fanboyismo direbbe zero.
Ubuntu è e sarà in grado di fornirti il know how? Sì
Red Hat/Fedora? Sì
(Open)SUSE? Sì
Slackware? No
Punto. Non ci sono altre discussioni.
Red Hat ti permette di apprendere oggi questa piattaforma perché lì nascono molte delle evoluzioni che vengono esportate nelle altre distro.
In SUSE e Ubuntu idem.
In Slackware no. In Slackware questi cambiamenti o non arrivano o se lo fanno arrivano nettamente in ritardo.
Che non vuol dire che sia una mossa sbagliata, anzi per certi versi è anche corretta perché mantiene un workflow coerente nel tempo.
Tuttavia non posso più pensare a Slackware come un punto di riferimento per apprendere un sistema che muta ogni giorno.
Oggi Slackware la si può considerare una distro GNU/Linux quasi quanto Android.
Per me non ha nemmeno più senso chiamarla distro. Andrebbe chiamata direttamente "sistema operativo basato su Linux" perché il legame che c'è oggi tra questa nostra distribuzione e ciò che OGGI è GNU/Linux è talmente blando che stiamo su due mondi completamente differenti.
In ogni caso io la chiudo qui. Non mi va di ripetere sempre le stesse cose.
...
