Non mi è sembrato di vedere nessuna discussione sul forum simile, quindi ne vorrei iniziare una io:
Usiamo questo topic per mettere in evidenza/rendere noto/scambiarci/o anche segnalare per meriti e-o demeriti particolari, oltre ache ai repo ufficiali, anche quelli che non lo sono e quelli che si estinguono?
Ovviamente sia quelli a 32 che a 64 bit 
Un'altra piccola domandina:
Visto che la distro usa gli .rpm, è possibile usare i repo di altre distro come mandriva, mageia, fedora, etc. per scaricare programmi ed aggiornamenti, inclusi kernel e librerie?
Evidentemente con un rpm ci fai quello che credi, anche incasinarti fino agli orecchi, se ti fa piacere.
Io sono dell'idea che queste distro così user friendly paghino comunque qualcosa in termini di leggerezza e configurabilità col vantaggio di essere pronte all'uso.
Forse a chi vuole smanettare gli conviene le canoniche Debian, gentoo, slack...
che voi sappiate, gli .rpm, sia a 32 che a 64 bit, dei repository delle altre distribuzioni che adottano tale formato (opensuse, fedora, mandriva,etc.) sono compatibili con PCLinuxOS?
No, non lo sono. Nel senso che rischi, se installi, di incasinarti PCLinuxOS... Maggiore "compatibilità" puoi magari trovare fra "distro" come Scientific Linux e CentOS (entrambe basate su Red Hat) e, al limite (ma comunque assai meno) anche Fedora...
Dipende naturalmente da pacchetto a pacchetto; ovvero da quanto dovrà interagire con tutto il resto.
Se il pacchetto contiene un programma a sé con poca roba a corredo probabilmente non avrai problemi.
Se ti installi una versione di xorg diversa da quella che il sistema si è già configurato sei più a rischio.
Se ti sostituisci pezzi del DE e librerie di sistema è quasi certo che qualche bel problema te lo rimedi.
Io penso che i pacchetti siano quasi sempre il più cross possibile e quindi la possibilità di incasinarsi per davvero sia mediamente abbastanza esigua.
Vedi te.
Ma possibile che il software dei repo ufficiali non basti?
Altra domandina.....
ci sono attualmente disponibili dei kernel pae nei repositories di pclinuxos? (intendo quelli che ospitano pacchetti a 32 bit)
Scusate se a avolte sono "casinista" nei miei post, forse dovrei darmi una calmata...
Sì, il Kernel PAE è disponibile (in due versioni; una è il normale PAE, l'altra è il PAE.BFS [non saprei dirti esattamente in che cosa differiscan, ma io utilizzo proprio quest'ultima -Processore a 32 bit e 4 Gb di RAM- e debbo dire che mi trovo assai bene]).
...starei pensando di installare pclinuxos a 64 bit. Al riguardo:
1) I repo che sono contenuti in esso (di default) sono gli sessi di quelli per le vers. a 32 bit? Quindi c sono tutti i pacchetti insieme, 32 e 64 bit?
Se si, per far funzionare i pacchetti a 32 bit dovrei installare apposite librerie di emulazione. Sapete nei repo pclinuxos come si chiamano?
Se no, poreste postarmi gli indirizzi dei repo 64 bit, pare che su pclinuxos.com non ne abbia visti (sarà stata la mia incapacità?)
No, al momento soltanto una parte (non "maggioritaria") dei pacchetti già disponibili per la versione a 32 bit esiste anche per la versione a 64 bit.
Dato che la versione attuale di PCLinuxOS x86_64 è in piena fase di test, non l'ho ancora installata (oltretutto, penso che disponga solo di KDE... mentre io preferisco di gran lunga LXDE, XFCE e ZENmini Gnome. KDE non l'ho mai apprezzata molto), per cui non ho davvero idea di come siano messi i correlati Repository. Ma, se proprio la vuoi installare (penso sia solo in lingua inglese, fra l'altro), poi, aprendo Synaptic potrai veder tutti i Repository che ci sono.
ok, allora da quello che mi pare di capire, e dopo diversi smanettamenti con synaptic:
1) non è che sinao tanti (diversi) repository, ma soloamente uno, e quelli che sono in /etc/apt/sources.list sono mirrors?
2) l'unco altro repositori "separato" dal principale è il megamames repository?
I repository li trovi tutti elencati in Synaptic (apri la finestra di Synaptic e clicchi -mi pare- su Impostazioni/Archivi dei pacchetti). Sono svariati, ma ne va impostato UNO soltanto (più uno qualunque dei due Megagames... se hai già "tradotto" in Sistema nella tua lingua).
Le pocchissime eventuali compatibilità co altra ditro le puoi avere attualmente solo da pacchetti mandriva 2010.2 , purchè non abbiano dipendenze si sistema , a livello kernel quello ricompilato da PcLinux è ormai versione molto più attuale e più completo a livello driver nativi , usare quello di mandriva2010.2 ora non avrebbe il benchè minimo senso .
Per assicucurarsi che i pacchetti scaricati dal server di Mandriva siano totalmente compatibili senza incorrere nel rischio di crearsi problemi di conflitto versione e cacciare nel guai il SO , dopo averlo scaricato l' rpm mandriva , lo copi nella cartella /var/cache/apt , poi avvii synaptic lo cerchi da li , se è critico synaptic ti avverte subito restituendoti gli errori versione dipendenze possibili . E ti impedisce di installarlo .
No fidarti a tentare di procedere da console son apt ed opzion force , bene vada avresti solo perso tempo.
Per quanto riguarda il kernel , se proprio lo vuoi aggiornare e lo sai fare , pclinux ha un compilatore favoloso e velocissimo , invece di ingrullire a cercare precompilati senza sapere da chi e come , vai in kernel.org ti scarichi il sorgente dell' ultimo rilascio stabile ufficiale e te lo ricompili da te .
Francofait, per questa ricomplazione ce lo faresti un howtoino da tenere di conto in documentazione?
Credo che sarebbe apprezzata mica solo da me.
Appoggio l'idea e non sarebbe assolutamente una brutta cosa sapere come fare anche per KDE; mi prenderei una partizione e aggiornerei la mia pclos kde...
Guide per la compilazione del kernel ce ne sono unpò ovunque , dal momento che però sono per lo più mirate a debian e derivate compresa ubuntu , nonostante la procedura sia essenziale per la compilazione sia identica per qualuque distribuzione sia linux che unix , icludono anche la procedura per la pacchettizazione nel formati .deb , che le rende barbose e conoscendovi come nemici acerrimi della console , vi passerebbe la voglia alla svelta.
Richiesta accolta , nei prossimi giorni vedo di preparare qualcosina di buono , e nei limiti del possibile semplice .
Per per ottenere anche il pacchetto rpm , se ne fa un discorso a se , perchè l' rpmbuilder di pclinuxos merita una guida a se stante .
Il mio blog lo conoscete , lo tenete d' occhio , appena è pronta e posso ritenerla almeno soddisfacente la publico li .
@francofait:
Grz.
Ma non glielo andare a dire a monsee che odio la riga di comando: gli smonti una certezza.
@mikronimo
Cioè?
Cioè mi piacerebbe provare ad aggiornare oltre che il kernel anche kde e una volta fatto, reinstallerei (lì sta il bello, non avendo mai fato una cosa del genere: cioè ricompilare kernel e de) il tutto su una partizione a parte per vedere come va; una rolling stabile come pclos ha molti vantaggi e pochissimi svantaggi, ma vorrei vedere come viene una volta "rintinteggiata"; questo volevi capire?
Ma perchè vuoi ricompilare kde? Non lo puoi aggiornare semplicemente da apt?
Mai un giorno che non mi riesca di fare la figura del co....ne!
Ero rimasto all'unica possibilità di aggiornare tramite synaptic e (ammetto che sono un paio di settimane che non riapro, e riaggiorno, la pclos kde, ma è in programma tra oggi e domani) non mi risultava che ci fosse altro che la 4.6.5. Inoltre il metodo che indichi l'ho sempre sentito solo nominare e, ehm, al momento mi sfugge il suo funzionamento in pclos...
Uscire da Synaptic e andare ad aggiornare i softwares da "riga di comando" comporta -com'è naturale- il fatto che non sarà più Synaptic a reggere il gioco delle dipendenze... Il che può essere un rischio, giacché -con il trascorrere del tempo- esiste una maggiore possibilità che nascano problemi nel Sistema.
Ma vuoi una kde più avanzata di quella presente nel repo?
Puoi andare a vedere sul sito di kde se l'hanno rilasciata.
Personalmente preferirei tirarmi una martellata sulle gengive, farà più male ma almeno poi passa.
Se invece ti accontenti di quello che passa il convento, che è stabile, sicuro e pclos, non fai altro che tenere aggiornato il sistema.
Synaptic è un'interfaccia molto ben fatta per usare apt senza avere lo scomodo di usare una shell ma non c'è nulla in synaptic che non ci sia in apt e in /etc/apt/sources.list.
Se poi una riga di comando non ti dà le vertigini, puoi inserire:
# apt-get update && apt-get dist-upgrade
e aggiornare il sistema oppure restringere l'azione a kde tentando per esempio
# apt-get install kdebase4
ma nel caso di un DE io mi fiderei più di synaptic che di andare a tentoni.
Monsee, non è synaptic a 'reggere il gioco delle dipendenze' ma apt.
Zafran, in PCLinuxOS le cose stanno diversamente: il Synaptic di PCLinuxOS non è lo stesso "ferro da stiro" che si trova in Debian opure in UBUNTU. Ed è Synaptic (in PCLi8nuxOS) a reggere le dipendenze in modo talmente efficace (agire da apt equivale a correre rischi: non l'ho inventato io, è una raccomandazione -arcinota- fatta di frequente dallo stesso Texstar... e non da lui solamente).
Ogni volta che ciò è possibile, in PCLinuxOS qualsivoglia ricorso alla 2rigfa di comando" o al Terminale, è sempre da evitarsi. Di gran lunga meglio usar sempre Synaptic e mai il Terminale.
Mo' m'informo ma secondo me è come per la storia di kde.
Cioè se non sai quale è il pacchetto chiave da invocare rischi di fare casino e quindi è meglio chiarirsi le idee graficamente.
Su openSUSE (12.1 tumbleweed, cioé rolling), ho abilitato i repos kde 4.8 da una settimana o giù di lì (o sono già due?); tutti i giorni o quasi arrivano degli aggiornamenti dagli sviluppatori/pacchettizzatori di suse; da che ho installato pclos kde a giugno non mi sono mai minimamente preoccupato di avere kernel e kde freschissimi, ma dai discorsi che emergevano dal post in cui chiedevi a francofait di preparare un guidina per la compilazione del kernel, mi pareva di essermi perso l'occasione di aggiornare kde, che ora come ora, con la 4.8, sembra aver risolto alcuni problemi che aveva (instabilità del pannello superiore se settato "a scomparsa", una migliore integrazione di alcune applet, come gmail-plasmoid e veromix e comunque una maggiore stabilità generale); la riga di comando non la evito come la peste, in particolare per cose di tale semplicità (come i comandi che, ora ricordo, conoscevo, mi hai suggerito), ma preferisco sempre una gui, se c'è; in effetti protrei pure provare a vedere cosa succede applicando i comandi, visto che stando sulla chiavetta, la pclos kde non è la mia distro base (sul pc ci sono installate kahelos e pclos zen-mini, aggiornate quasi tutti i giorni) e non mi metterei a piangere se qualcosa andasse storto.
Apt4rpm è uno solo e synaptic senza Apt non serve a niente , Ha ragione Zafran , anche con PcLinux la gestione dei pacchetti è compito di Apt e synaptic svolge solo funzione di interfaccia grafica , come tutte le utiliti di sistema , neppure esiste possibilità di intervenire sul SO senza passare per la console. Non esiste categorigamente con nessun pc e con nessun SO .
Che poi le gui siano utiliti e sempifichino le operazioni , evitandoti le formulette magiche , che sono meno amate di quanto si pensi anche dagli addetti ai lavori , nessuno ne disscute , altrimenti non avrebbero neppur motivo di esistere .
Apt4rpm nella sua attuale versione inoltre se vai ad osservarti bene la sua configurazione gestisce le eccezioni in totale autonomia , non più attraverso l' uso obbligato di synaptic che neppure aveva senso tenenendo presente che oltretutto PCLinuxOS gestisce tutto tramite un solo ed unico server repositorio , e non accetta repositry di terze parti .
Ma allora, ipotizzo (nel caso sia in errore ditemelo spudoratamente), se proprio uno volesse metterci le mani (a suo rischio e pericolo), non converrebbe compilarsi il de (se questo assicura che vengano soddisfatte le dipendenze)? Effettuando un esperimento (per installare una versione di midori non presente nei repos), ho potuto constatare che mi venivano segnalate le dipendenze mancanti e così alla fine ho completato prima la configurazione e poi la compilazione, per poi alla fine poter installare il tutto.
[ la pclos kde non è la mia distro base (sul pc ci sono installate kahelos e pclos zen-mini, aggiornate quasi tutti i giorni) e non mi metterei a piangere se qualcosa andasse storto.[/quote]
La compilazione di kde4.8 è da sorgenti è lunga è complessa non puoi utilizzare i precompilati , ne di OpenSuse , ne di Mandriva , ne di Rosa , purtoppo fanno uso di versione diversa ed incompatibile sia del compilatore che di gcc , senza contare che in Opensuse è diversa pure l' architettura delle directory , di conseguenza kde4.8 per poterlo avere in PClinuxOS va per forza ricompilato da sorgenti rispettando le direttive di compilazione utilizzate per l' intero SO , altrimenti poi non funziona nulla.
@ francofait
Amo quell'uomo!
@ mikronimo
Il bello di linux è che te lo puoi incasinare quanto e come ti pare.
Io insisto a non capire cosa c'entri il kernel con il DE. Il tuo discorso mi suona un po' come: 'visto che rifaccio la testata, rivernicio anche la carrozzeria'.
Pclos è lentino negli aggiornamenti sostanziosi, quindi prima di passare a una nuova versione di kde ci mette più di altre più avventurose distribuzioni e meno di altre più conservative.
Con un po' di pazienza, kde 4.8 ti verrà scodellato bello bello nel repo.
Altro discorso è per il kernel, visto che quello che viene rilasciato è un generico che funziona comunque dal momento che la ram è abbondante, ma andrebbe sicuramente meglio se venisse personalizzato e quindi compilato sulla macchina.
Operazione non necessaria ma sicuramente interessante tanto più se davvero, come dice francofait, pclos dispone di un compilatore particolarmente ben riuscito.
La compilazione di kde4.8 è da sorgenti è lunga è complessa non puoi utilizzare i precompilati , ne di OpenSuse , ne di Mandriva , ne di Rosa , purtoppo fanno uso di versione diversa ed incompatibile sia del compilatore che di gcc , senza contare che in Opensuse è diversa pure l' architettura delle directory , di conseguenza kde4.8 per poterlo avere in PClinuxOS va per forza ricompilato da sorgenti rispettando le direttive di compilazione utilizzate per l' intero SO , altrimenti poi non funziona nulla.[/quote]
Per il kernel il discorso è meno complicato , l' unico momento critico che richiede massima attenzione è la preparazione nel file di configurazione che poi il compilatore usera per svolgere il suo lavoro tutto da se . Il kernel inoltre non ha dipendenze di sistema , e basta avere il buon senso di non sopprimere il kernel vecchio prima di aver testato più che bene quello nuovo. Se il nuovo al riavvio finale fa cilecca , o nel corso d' uso restituisce problemi , avendo sempre il vecchio dal quale poter riavviare , sei sempre al sicuro , se invece l vecchio lo vai subito ad eliminare , ti sei fregato con le tue stesse mani .
S è vero , e neppure non dovrebbe tardare molto ad arrivare , in lavorazione c'è , ma la pappa scodellata dal ristorante non ha mai lo stesso buon sapore di quela fatta in casa con le proprie mani e a suon di pappa scodellata si finisce per saper usare il cervello solo per fare mouseclic , mentre invece pochissimi altri mezzi come il computer danno la possibilità di manterlo in forma
Vanno compilati con lo stesso ordine di successione come sono disposti sul server di kde.org . Non necessariamete da console , anzi per kde e sue applicazioni , Codeblock è tutto sommato preferibile .
Mi aveva incuriosito il discorso di francofait per il kernel; pclos in questi mesi che lo uso ha aggiornato un po' di tutto salvo kernel e de; lo so che sono diversi e prima o poi verranno aggiornati, ma visto che il kernel sta a 3.2.6 e kde a 4.8, ero solo curioso di vedere cosa di oteva fare, a puro titolo sperimentale (dubito di poter fare un buon lavoro e sicuramente aspetterò texstar per avere una distro ben funzionante). Vedrò quando francofai pubblicherà la guida sul suo blog.
NON è affatto quel che mi risulta. Ha TORTO Zafran e hai TORTO tu. Su questa cosa, intendo.
La pacchettizzazione di PCLinuxOS (e, nello specifico, l'intera gestione raffinatissima delle dipendenze) si basa su un sistema realizzato da un pacchettizzatorie italiano, il quale lo ha incardinato esattamente su Synaptic (in una nota intervista, Texstar gliele riconosce pieno merito e suggerisce di NON affidarsi al Terminale per la gestione dei pacchetti in PCLinuxOS).
Certe volte ti ammiro, veramente.
Non ti arrendi nemmeno davanti all'evidenza.
Apri il man di synaptic di pclos e leggi:
Giusto?
Ho appena incollato il man di synaptic della debian lenny da cui sto scrivendo.
Synaptic è synaptic, cioè nulla.
Quello che conta è apt nelle sue forme apt-get apt-cache e varianti apt-rpm o apt4rpm, com'è configurato.
Perché ti conforti tanto pensare che synaptic sia in grado di fare qualcosa in autonomia mi resta un mistero.
C'è poco da ammirare... Il punto è che il synaptic di PCLinuxOS gestisce le dipendenze MEGLIO (costituisce, insomma, un MIGLIORAMENTO rispetto all'analogo -che ha lo stesso nome- di Debian e di UBUNTU). Infatti, laddove gli altri package-manager incorrono spesso e volentieri in problemi (anche quelli di UBUNTU e di Debisn), ciò non accade praticamente mai al buon Synaptic di PCLinuxOS. Lo stesso Texstar raccomanda di utilizzare Synaptic (e non il terminale o altro) per far gli aggiornamenti.
PCLinuxOS ha allo studio (eìoltre che sotto test) ormai da un pezzo anche altri Gestori di Pacchetti (SMART-Package-Manager, YUM [Yum eXtender] e altri), ma nessuno -finora- che riesca a gesti le dipendenze bene come lo sa fare il Synaptic di PCLinuxOS.
suggerisce di NON affidarsi al Terminale per la gestione dei pacchetti in PCLinuxOS).[/quote]
Monsee , non lo suggerisce a caso , la pagina di sinaptic restituisce vita morte e miracoli di ogni pacchetto che vai ad abilitàre per l' installazione restituendoti a video tutte le sue dipendenze, ed è lì la sua fondamentale utilità , in modo particolare se di pacchetti ne devi installare diversi . Son più di 30000 in tutto , sapere in nome esatto a memoria di tutti per poter fare a meno di un' intefaccia che li descriva , è impossibile . Prima che arrivasse synaptic in X , veniva usato aptitude che è presente anche nel pacchetto apt4rpm , ed è intefaccia semigrafica per l' uso diretto con la console .
La necessità di mettersi in condizione di evitare pasticci minimizzando la necessità di usare il prompt dei comandi , è sempre stata sentita , non è nata per la sola gloria dell' utente finale.
Se incappi in problemi da linea di comando , sei te che sbagli nel dare i comandi , non il compiuter che li esegue male .
apt-get -f dist-upgrade , in pclinuxos di fresca installazione , aggiorna gli stessi identici pacchetti che aggiorna synaptic , non uno in più e non uno in meno . Nell' istante in cui dai applica , in synapic viene aperta una console in background ,viene attivato apt con il processo di download remoto dal server repositoryo indicato nel suo sources.list .
Ne può accettare solo uno per il solo motivo che suno tutti uguali , di conseguenza con due apt restituirebbe un replicate error .
Che sia con debian o ubuntu o anche PcLinux o qualsivoglia distro , nei pasticci col gestore dei pacchetti ci vai se si azzarda configurando nel sources list fritto misto con repositry non ufficiali ed insicure , ma se uno pur di avere l' ultima novità vuol rischiare , se poi stoppa , non può certo darne colpa alla console , può solo fare un bel mea culpa , me la son cercata.
PCLinuxOS non è piacevole perchè la console non serve , è piacevole all' utente finale , perchè forniscie pachetti compilati e testati bene . Se decide di disegnare una gui per semplificare il lavoro al niubbu , la fa meglio che può sapendo benissimo che introduce nel SO un elemento di disturbo in più , che essendo tale va evitato a priori che crei più problemi di quanti ne deve semplificare
Concordo, Franco. Certo: se si inseriscono dei Repository "instabili" o dei pacchetti "azzardati", poi, ne deriveran problemi.
Ho usato Synaptic in Debian e UBUNTU (e in svariate loro derivate). Ho usato openSuSE (e il suo Yast), delle derivate di Slackware (e il loro Gslapt), ho usato Smart-PackageManager (in Unity-Linux) e YUM e Yum eXtender in Fedora, Scientific Linux e CentOS, ho usato Pacman (in ConnochaetOS, derivata di ArchLinux) e ho usato perfino Conary (in Foresight Linux)... e mai nessuno di tali Gestori di Pacchetti m'ha dato prestazioni affidabili e sicure com'è accaduto -sempre,- invece, col Synaptic di PCLinuxOS. Certo: non ho impostato Repositories "instabili". Ma non l'ho fatto MAI, nemmeno in altri casi: non l'ho mai fatto in Xubuntu, mai in Fedora, mai in OpenSuSE, mai, in nessunissimo caso... E -tuttavia- tutti gli altri gestori di pacchetti, o prima o dopo, han dato problemi con le dipendenze. Soltanto PCLinuxOS non ne ha mani dati. E questo è importantissimo in una "distro" che è anche "rolling", ossia che -una volta installata- non si dovrebbe più dover reinstallare (e deve, dunque, funzionare con la precisione di un orologio svizzero specie per quel che concerne la gestione delle dipendenze).
Il punto che mi preme di sottolineare, inoltre, è il seguente: andare a consigliare di usare il terminale per effettuar installazioni e aggiornamenti in PCLinuxOS è come suggerire a chi sta usando un'auto col cambio automatico di metterci un bel cambio "a mano" e poi andarci "smanettando" con le marce... "perchè tanto il meccanismo che collega il motore alle ruote è sempre uguale"... Il che sarà anche vero, ma a smanettar di cloche su un'auto progettata per usar le marce automatiche finisci col bruciare, prima o dopo, la frizione (come minimo)...
PCLinuxOS può essere agevolmente usato da tutti, ma io non nutro dubbio circa il fatto che sia particolarmente adatto ai principianti (ai "principianti di GNU/Linux", sì, ma anche a chi sta principiando adesso nell'uso generale del computer). Quello che PCLinuxOS offre all'Utente che non si è mai avvicinato prima al PC è un Sistema stabile e affidabile, solido e user-friendly per davvero, pensato per chi, senza esperienza o con ben scarsa esperienza, desidera avere un PC col quale poter fare le sue cose (navigare in Rete in sicurezza, scrivere, studiare, iscriversi a questo o quel Social Network, elaborar le proprie foto, ascoltar musica e quant'altro), non per chi con il proprio computer, essendo già abbastanza esperto, ci vuol semplicemente "smanettare" per imparare, un poco meglio, interessanti cose di informatica.
Se vuoi un'auto con cui smanettare "di cloche", è assai meglio usare un'auto che proprio per cambiar le marce usando la cloche è stata progettata (nel complesso, costa meno e dura di più... e insegna anche di più, probabilmente).
Se vuoi una "distro" adatta a "smanettare", ce n'è di assai belle: Gentoo (l'originale, intendo) e ArchLinux in testa a tutte. Se queste sono "troppo in alto" ce ne son altre che posson comunque andare molto bene: da Debian a Slackware a CentOS fino a UBUNTU (meglio -direi- Xubuntu, ma è anche questione di gusti). Ma andare a "smanettare" usando una "distro" come -ad esempio- Foresight Linux (che poggia interamente sulla propria personalizzazione di Conary per la gestione dei pacchetti) o PCLinuxOS (che ha proprio nella straordinaria precisione della gestione delle dipendenze garantita da Synaptic il suo più grande e interessante punto di forza) è un po' come comprare un'auto progettata espressamente per i principianti -e pensata sino dal progetto "con il cambio automatico",- sol per poi far dell'esercizio di "smanettamento estremo" usando il cambio a cloche...
Che a un novizio si possa cercare di facilitare le cose con un linguaggio semplice è esperienza che qualsiasi genitore o maestro fa continuamente ma deve essere pronto in qualsiasi momento a tornare a ragionare nei termini reali.
Altrimenti diventa un mistificatore, non un maestro.
Qui si stava discutendo con mikronimo.
Ti sembra che lui abbia bisogno di novelline e baubau?
Una cosa è dire a uno che non l'ha mai fatto "apri synaptic".
Ben diverso è dire a chi si sta informando "synaptic di pclos è diverso da quello di debian" il che è un falso e porta fuori strada.
Tu stai usando pclos per un progetto tuo, meritorio e condivisibile, di diffondere l'uso di linux nell'utenza non specializzata, ma che può anche non essere quello di altri.
E comunque non puoi evitare di descrivere le cose ANCHE per quello che sono.
Compito del SO non è quello di fare da motore del computer , ma di renderne possibile il suo uso , non è il SO il motore del computer ma la sua stessa architettura hardware.
La differenza fra le varie distribuzioni non stà nel modo di guidare il computer , non esiste alcun altro modo di guidarlo per alcun SO al di fuori di quelle che sono le esigenze intrinseche di un qualunque sistema di calcolo.
La scheda grafica nel computer , è un elemento addizionale del quale non solo il computer non ha sostanzialmente alcun bisogno , ma avendo bisogno di comunicare con il sistema di calcolo ne sottrae inevitabilmente parte delle sue risorse .
Non per altro le schede grafiche vengo dodate di processore proprio , di propria ram e di un proprio chipset , per poter ottenere dalla scheda grafica elevate prestazioni è indiscpensabile far si che lavorino impegnando quanto meno possibile le risorse reali del pc e del sistema di calcolo . Che gestisce in tutto e per tutto la comunicazione da e verso il sistema di calcolo nel computer qualunque sia e sempre e solo quell' area comunemente chiamata console , che ha il preciso compito di convertire tutte le istrizioni date al computer in codice assembly , ( quindi esadecimale , in binario , l' unico linguaggio che il microproocessore può elaborare) e viceversa da binario ad assembly quelle restituite dai processi di calcolo e destinate al controllo delle periferiche , scheda video (se presente , è solo un optional anche se nel comune uso è difatto indispensabile) , inclusa e per prima.
Non esiste intefaccia di supporto alla gestione del software esente da problemi, come del resto non esiste neppure software totalmente esente da problemi , scrivere migliaia di righe senza che qualche errore sia pur non critico ci scappi è semplicemente impossibile per chiunque, Synaptic viene rivisitato e rimesso on line per aggiornamento , mediamente non meno di 4 volte ogni anno , inevitabilmente deve essere riviistato ed aggiornato anche ogni qualvolta viene aggiornato il paccheto apt4rom , è sua dipendenza se non la si aggiorna assieme poi neppure può funzionare.
Synaptic non gestisce dipendenze di alcun tipo , con la versione in aggiornamento attuale non gestisce più neppure le eccezzioni , sono state differite per intero alla configurazione di apt anche quelle.
Synaptic a sola funzione interfaccia verso il dabase per apt , ne più ne meno che come yumex in fedora eèpura gui e niente altro per yum , e e yast2 pura gui per zypper e niente altro in Suse ,
Smart package manager , che è caduto in disgrazia con tutti è da tanti anni , ha avuto vita breve . Ora stan sempre discutendo su zypper e yum , con relative intefacce , non sono nle intefacce a gestire le dipendenze . come non lo è synaptic .
La scelta si presenta spinosa e non poco perchè comporta inevitabilmente la riorganizzazione di sana pianta di tutti i server repositori e relativi servizi di mirroring on line , non per questo o quel gestore dei pacchetti in se. (magari il problema fosse tutto li )
Vorrei dire un'ultima cosa in merito alla questione; secondo me, il problema non è che si metta in guardia una persona dai rischi di procedure "extra" rispetto a quelle canoniche e ritenute sicure (cosa anzi giustissima, a qualunque livello la si faccia, verso il novizio o esperto che sia), ma tanto il fatto che (non me ne vogliano, se credono di ascoltare una mia modistissima opinione) sia monsee che francofait (un volta uno, una volta l'altro, in questa occasione o prima o dopo) sentano sempre la necessità impellente di fare la "ramanzina", di fare una sorta di crociata pro o contro un qualcosa (generalmente la famigerata riga di comando e le cose di contorno, che io non odio, ma evito, dove mi complica le cose, per poi usarla se mi conviene, come il sistema di aggiornamento di openSUSE: "zypper up, zypper dup", infinitamente più semplice che un'evenutale metodo da gui), in maniera perentoria e dogmatica, perdendo spesso il punto reale della discussione in corso; da entrambi posso solo imparare (e spesso lo ho fatto), ma voglio far notare che proprio perché esperti ed appassionati del mondo linux (e, quasi per definizione, anti win e/o mac, mondi blindati), dovrebbero essere più rivoluzionari che reazionari, e prendere posizioni troppo rigide, non solo non mi pare molto sensato, ma neanche molto produttivo; nel momento che io stesso ho detto: " voglio fare un esperimento e compilarmi il kernel e magari anche il de (dove il primo parrebbe essere più fattibile, del secondo), per poi applicarli, in partizione separata, ad una distro (ipotizzo pclos, ma può valere anche un'altra)", un breve accenno ai rischi che quella specifica distro, così rimaneggiata, corre nella sua separata partizione (ed eventuali soluzioni), seguita (avendone le conoscenze e la voglia) da una corposa spiegazione di come fare, e non il contrario, sarebbe la maniera giusta di far avanzare le conoscenze, mie nello specifico, e di tutta quella parte di comunità (al momento all'oscuro di queste cose, di pclos), in generale. Quando contesto un certo modo di vedere linux, troppo indirizzato alla riga di comando, lo faccio perché mi complica le cose e non per una mia visione filosofica dell'uso del pc; sono una persona dallo spiccatissimo senso pratico e, dove un'alternativa esiste, scelgo la via più diretta, che sia santa o diabolica; a volte, però, progetto anche di andarmi ad impelagare in qualche esperimento e quello che mi serve (ma immagino un po' a tutti) sono informazioni e soluzioni; il resto cade nel campo delle opinioni: ognuno le sue e nessuna assoluta e perfetta, se non per chi la esprime. Buon fine settimana a tutti.
Infine no metto in dubbio che la gestione dei pachetti nelle grandi distribuzioni riesca a volte a dare problemi , è verissimo purtroppo la colpa non è ne del SO ne del gestore dei pacchetti che si stà usando , ma immancabilmente e sempre , dei vari maintener che gestiscono ed amministrano i server repository . In debian , sono tristemete noti da sempre come eterni bisticcioni , con la conseguenza che le uniche repostritry affidabili e stabile sono solo ed escusivamente quelle di Debian Stable , in ubuntu non sono bisticcioni ma casinisti a non finire , con lo stesso identico risultato finale , pacchetti che finiscono su repositry diverse da quelle in cui dovrebbero essere collocate, e fin che non viene posto rimedio , per il povero utente , bravo che sia son rotture di bal per forza , non per colpa ne sua ne del SO , ne del suo gestore dei pacchetti .
Il punto è semplice, chiaro e netto: il Synaptic di PCLinuxOS è assai più efficace del Synaptic di Debian o di UBUNTU (e anche di qualsivoglia altro Gestore di Pacchetti).
NON "informo male", dicendo che evitare di usare Synaptic conduce a correr rischi.
Informo benissimo, invece.
Synaptic da se non gestisce un bel niente , zero totale . E nessuno ti stà dicendo che fai male a consigliarne l' uso , tantopiù a chi linux lo affronta per la sua prima volta. Come fa a conoscere a memoria , nome cogome , paternita e maternità di ogni singolo pacchetto per poter installare direttamente da console con apt, chiaro come il sole che ha stoppare in qualche madornale errore ci finisce alla svelta.
Per quanto riguarda la gestione dei pacchetti nelle ditribuzioni maggiori e di più comune uso anche da partedi newby , credo di essere stato più che esaruiente con la risposta precedente . Se i maintener incaricati di gestire ed amministrare i server repository lo fanno con i piedi , non esiste per alcun utente e per alcun gestore di pacchetti locale , la benchè minima possibilità di evitare guai che non sono ne colpa sua ne della distribuzione che sta usando e del relativo gestore dei pacchetti .
La grande ed inesauribile risorsa di PCLinux non è di potersi inventare impossibili soluzioni che se ne possano infischiare di come è organizzata la struttura hardware e delle sue conseguenti esigenze , ma quella di lavorare con calma , di comune accordo e testare a fondo il suo lavoro prima di renderlo di pubblico dominio , il gestore dei pacchetti in PCLinuxOS , non da problemi perchè i sui server repositori li mantiene e li gestisce altrettanto bene , con lo stesso impegno con cui lavora sulla distribuzione stessa .
Ho provato ad applicare i comandi su zen-mini (tanto che la stavo aggiornando), dopo aver fatto il classico aggiornamento da synaptic: con il secondo aveva aggiornato firefox, lomanager e un altro paio di cose; con il terminale non ha trovato nulla; la prossima provo il contrario, ma credo che troverò degli aggiornamenti con il terminale, applicati i quali, non troverò nulla con sinaptic; se questo caso si dovesse verificare (come credo) si avrebbe la dimostrazione che le due procedure sono del tutto identiche; non è che ne dubitassi, ma tutta la discussione avvenuta in questo thread, sembrava dire che in realtà le due cose erano distinte, quando io già sospettavo che non lo fossero e ci si trovasse davanti ad un malintendimento: synaptic è "solo" un front-end grafico ad apt.
Difatti neppure deve cambiare nulla , qualora fosse è solo il caso di porre il problema all' attenzione sul forum principale , perchè sarebbe riuscito a sfuggire qualche problema a livello repository . Cosa fin qui almeno a me mai successa , pari pari come a Monsee . Al quale dico vai tranquillo e dal momento che a richiedere il tuo aiuto sono proprio essenziamente newby al loro primo approccio con linux , continua pure giustamente a consigliare di appoggiarsi a synaptic , prima che imparino a memoria la sintassi precisa di ogni pacchetto di cui han bisogni , di acqua da far passar sotto i loro ponti ne avranno tanta ed anche di più.
le repositry di base ad accesso predefinito nel sources list sono :
main updates nonfree kde4 games xfce4
possibili da includere liberamente aggiungendole sulla lista /sezioni.i di synaptic o direttamente in /etc/apt/sources.list sono
testing special unstable
In unstable non ci sono aggiornamenti validi attuali di alcun tipo l' ultimo aggiornamento in unstable risale all' 11/06/2011 e riguarda unicamente lo sviluppo di yum e di smart , per il resto contiene solo la prima pacchettizazione di kde4.6.0 .
Ergo essendo temporaneamente del tutto inutilizzata , del tutto inutile aggiungerla alla lista . Inutile installare sia yum che smart , non vi sono repositry pclinuxos che li supportino , ne l' uno , ne l' altro.
Gli aggiornamenti che normalmente prima di essere posti in ubdate passano per special e per testing , sono già in update da ieri assieme , comprendevano l' upgrade firefox 10.0.2 e il pachetto completo dell' ultima versione stabile libreoffice 3.5
La 64bit del SO , è su repositorio diverso /2011 ultimo aggiornamento gllobale è fresco di ieri notte , interamente datato 17/02/2012
A questo punto direi che sarebbe il caso di interrompere ogni disquisizione , indipendentemente dal sua testardaggine , Monsee che considero pure persona squisita , a raccomndarsi con il chi gli chiede aiuto quasi sempre perchè il SO non lo conosce , di usare il mezzo più congegnale per la sua sicurezza non ha torto , e per me l' importatnte che vale è questo. Quindi le disquisizioni per me si fermano qui e passo ad altro .
Mi rivolgo invece a chi il SO lo conosce , non teme la console e non didegna affatto utilizzare una installazione del SO a se stante per sprimentare e zazzicare e spremere le proprie meningi.
Mai smettere di sperimentare , mai smettere di zazzicare , provare tutte le risorse che pclinux rende disponibili, dalla compilazione di software da sorgenti alla sperimentazione di pacchetti di provenienza diversa ( tramite yum nulla impedisce di farlo puntare alle repostry della community di fedora (non oltre fedora fc15 , altrimenti il SO va in palle di bruto praticamente subito)
Oppure anche ad usare il frontend grafico per alien cioe ' package converter che è presente da reposirtri ufficiali pclinux32 - (per la 64 ancora non c' è) , scoprire se vi sono pacchetti utili convertibili in .rpm per pclinux su server repository di altre distribuzioni.
PAE.BFS aggiunge la path di kolivas , preferibilmente da evitare con i portatili , raccomandabile invece su fisso. Su portatile e preferibile evitarla a causa della dell' estrema compattezza a scarsa ventilazione dei portatili in genere.
Anche secondo me va bene così.
Ci siamo ripetuti più volte e chi non vuol cambiare idea, non credo che lo farà.
Non vorrei sembrare retorico ma vorrei ringraziarvi comunque.