Questa è la prima parte di risposta... la seconda arriva tra un po'.
ZeuS ha scritto:Si ma allora io perchè sto qua a scrivere? Devo andare a cercare io per te i miei post?
Non hai risposto a un post per intero e altre cosette le hai omesse non so poi il perchè.
Ti basta tornare indietro di qualche post e trovi tutto quello che serve.
Io sono in buona fede e mi pare di avere risposto a quello cui andava risposto. Come detto altrove, quando ti manca qualche punto, segnalamelo.
Forse ho capito quale post intendi, ovvero l'ultimo. Ma visto che ne hai ripreso qua i concetti, rispondo in toto.
Volendo fare un riassunto di tutta la discussione si è partiti con il fatto che è impossibile scrivere in maniera sicura NTFS. Ora caro RIKO, mi spieghi che senso ha dare contro la comunità open, che nonostante i problemi di specifiche, cerca in tutti i modi di dare supporto anche a quel fs?
Non è questione di "dare contro". È questione che è un enorme scomodità.
Allora, il punto qui non è condannare MS per non avere rilasciato le specifiche, comportamento che io trovo *comunque* esecrabile.
Il punto è che è un enorme scomodità. MacOS X legge di default NTFS senza problemi, *ma* non lo scrive. Questa è una scomodità che in buona sostanza costringe a formattare i dischi esterni in FAT oppure i nHFS+ e acquistare un costoso sw per Windows che da a Win la capacità di leggere HFS+.
È indubbiamente scomodo. È un problema noto e più volte evidenziato (nelle comunità Mac).
Questo problema è presente in buona sostanza anche con Linux (anche se è in via di scomparsa, mano mano che i driver miglioreranno). Ma il problema diventa parecchio più seccante in quanto molti usano il dual boot.
Credo si possa dire che la maggioranza degli utenti linux iniziano in dual boot. E in queste condizioni la mancanza di capacità di scrittura è abbastanza una cosa scomoda.
Su tutto c'è il supporto sostanzialmente carente (o meglio, eccellente, ma troppo "sicuro" ) per i permessi. Per esempio quando da GNU/Linux monto un disco, quasi sempre devo ricorrere alla cli. Spesso viene montato con permessi di root (e quindi non è accessibile dalla gui come utente qualsiasi) e roba simile.
Ora è mia intenzione installare SuSE 10.1 che è quella cui tu fai riferimento. Ci sono controindicazioni nell'usare l'installazione da network? Se no, procedo con quella e vedere come hanno risolto il problema.
Tornando a NTFS: non è un problema insormontabile. È un fastidio, ma se tu continui a sommare fastidi su fastidi, ottieni un sistema che risulta *scomodo* da usare. Ergo non è amichevole.
Poi come dicevo, per qualcuno che ci prova gusto, è sicuramente accettabile. Ma io GNU/Linux lo voglio dare in mano a chiunque: quindi deve essere altrettanto comodo delle alternative, altrimenti rimane un oggetto soprattutto per tecnici di settore, come me, o per appassionati.
Il problema dopo qualche post è diventato quello delle dipendenze...cioè è un problema il fatto che quando si installa un programma vengano installate delle librerie. Ora dimmi tu che cazzo te ne frega se per esempio se quando installi vlc si tira dietro lib_mad, una libreria di pochi kb.
Detto questo il problema è diventato questo. Se installi un programma kde e usi gnome si tira dietro MEZZO (o in certi post addirittura TUTTO) kde.
Per quanto possa sembrare sorprendente a chi si è assuefatto alle comodità dei sistemi di pacchettizzazione sotto GNU/Linux (io li trovo davvero fantastico quello di Ubuntu, ma vabbè), l'utente comune li trova abbastanza scomodi.
L'utente comune si trova meglio a fare doppioclick sull'installer o (meglio ancora) trascianre il .app dentro la cartella applicazioni.
Francamente in parte lo capisco.
Entrambi i sistemi hanno vantaggi e svantaggi, non li elenco, ma facendo mente locale si capiscono facilmente. Specie il sw open trae vantaggio (per come è pensato) dai sistemi di pacchettizzazione automatica alla "GNU/Linux" (ad alto livello urpmi/yum/yast/apt-get si comportano un po' tutti allo stesso modo) oppure alla BSD (Ports, emerge). Io personalmente preferisco i secondi ai primi, ma ancora una volta, de gustibus.
Pensando il sw in altro modo d'altra parte si riesce a risolvere il problema con installatori meno raffinati.
Ma tornando all'utente comune, gli viene più istintivo fare doppioclick sul suo file scaricato. Non so perchè sia così: dopo tutto cercare il nome in synaptic/yast e lasciare che sia lui a scaricarlo installarlo sembrerebbe più facile. Io non ti so dire perchè: sicuramente molti utenti comuni sostengono essere più comodo il metodo "a la windows". Un campione meno significativo numericamente (ovvero quelli che sono passati a MacOS X) si trova meglio con questo sistema (quasi tutti i membri del campione, ma come dicevo il campione è piccolo).
Il casino oggettivo viene se si vuole installare qualcosa che sia fuori dai repository. Spesso ci sono problemi di varia natura, piccole incompatibilità sulle varietà delle librerie. Tempo fa (forse tu non c'eri) problemi di compatibilità binaria fra compilatori (adesso cercano di evitarli, ma potrebbero riaccadere alla prossima major del gcc).
Il punto chiave è che il sw open è pensato per essere installato dai sorgenti. I sistemi di pacchettizzazione cercano di rendere "la via binaria" altrettanto praticabile. Funzionano eccellentemente, per altro. Ma funzionano bene "a repository".
Io da parte mia sono in una posizione "previlegiata": sono utente *e* sviluppatore per tutti e tre i sistemi. Quello che posso dire è sia per uno sviluppatore che per un utente i vantaggi e gli svantaggi dei vari sistemi si equivalgono allo stato attuale delle cose.
Se però uno va a vedere come funzionano *davvero* le librerie in MacOS X e tutto, si scopre che è il sistema "perfetto". Purtroppo la maggior parte del sw open (che serve) non crea framework e non è al 100% integrato con MacOS X. Ovvero tratta MacOS X come un qualunque altro sistema con interfaccia di tipo BSD, ma senza usarne *davvero* le peculiarità.
Questo è IMHO un peccato, ed è per questa ragione che abbiamo bisogno di Fink/DarwinPorts, altrimenti basterebbe un sistema molto pià grezzo, ma vabbè.
Ora vogliamo criticare anche questo? Vogliamo criticare il fatto che i due DM sono DIVERSI e si basano su librerie diverse? A te può sembrare una cosa da criticare a me sembra un'ottima cosa perchè rende più vasto e completo tutto il panorama di GNU/linux e bada bene che non sto difendendo l'indifendibile.
Non necessariamente da gassare. Sicuramente da criticare, per vedere quali sono i problemi, e individuatili, cercare di risolverli. Il problema più ovvio è l'interoperabilità fra applicazioni. Negli ultimi due anni hanno fatto passi da gigante, sia sul versante del look che su quello del feel.
È un po' un peccato che certe cose non siano state fatte prima. Inoltre molti componenti dei due ambienti sono fondamentalmente ridondanti, e non parlo solo della GUI: come certo saprai KDE e GNOME sono set di librerie che tendono a coprire tutte le esigenze tipiche di un'applicazione di base (e quindi non solo gui).
Ci sono componenti ripetuti... penso ad Arts, ormai quasi inutilizzato, e all'ottimo ma complessissimo gstreamer. Adesso KDE ha deciso che scriverà un wrapper semplificato (nel senso che per il programmatore sarà facile fare le cose banali) che potrà usare come backend quasi qualsiasi cosa (fra cui gstreamer).
Una scelta saggia.
Insomma avere due ambienti totalmente distinti a livello di libreria e di componenti è IMHO una cosa spiacevole. Avere due ambienti distinti a livello di comportamento è invece una cosa positiva (ognuno sceglie il suo).
Anche perchè la principale critica ai sistemi di installazione "standard" a la windows e alla MacOS è che in questo modo si tendono a duplicare librerie. Comportamento teoricamente possibile, anche se all'atto pratico non verificato: pochi programmi per MacOS X usano molte librerie "universali" al di fuori di quelle dell'OS [nel senso che sono librerie stand-alone e non semplice parte del progetto specifico ], e generalmente non ce ne sono due diversi che userebbero le stesse. Su Win il problema è più sentito perchè c'era un po' di casino con le dll, casino che dicono risolto in massima parte.
IMHO la strada (lunga) è cercare di rendere gli ambienti più interoperabili possibile, non solo a livello utente, ma anche a livello di backend.
Poi ora sto usando gnome dopo parecchio tempo e non mi è mai capitato di dover installare un sw kde. Dite che è necessario installare k3b perchè non c'è una controparte decente su gnome ma non è vero. Uso gnomebaker e l'unico inconveniente è che che non supporta l'overburning ma sul sito il creatore fa sapere che l'opzione sarà disponibile a breve. Scrivo parecchio in overburning e allora ho deciso di installare bonfire e fino ad ora non ho trovato difetti.
Non è questione di "essere obbligatorio". Non fare l'errore di dire "a me gnome-baker basta quindi è un sostituto di k3b". Gnome-baker è un buon programma, per carità, ma non è un sostituto di k3b.
Gnome baker masterizza fondamentalmente immagini disco e le crea. Non so nemmeno se crea cd audio (nel senso che dall'interfaccia sembra di no, ma non ho provato e sono relativamente sicuro che lo capisce da solo se uno gli tira su dei file mp3, se ti va di provare, fammi sapere, ad ogni modo la cosa non si sposta di molto.).
Di sicuro non fa DVD video e queste cose qua, oltre che sembra meno modulare (per esempio k3b ha un fottio di filtri di importazione per masterizzare tracce audio in svariati formati direttamente, che è decisamente comodo).
Ma il punto non è sul *singolo* programma: stabiliamo anche che k3b e gnome-baker siano uguali.
Pensa allo sviluppo in modo globale, pensa alle varie funzionalità e programmi che uno si aspetta in un sistema. Ci sono due scenari possibili: il miglior programma per gnome e per kde fanno le stesse identiche cose. Bene: questo è uno sforzo inutile, doppio delle ore uomo per avere la stessa cosa, solo perchè le librerie di base sono diverse.
L'altro scenario è che per ciascun "settore" il top sia di una delle due piattaforme. In questo caso se uno vuole usare il "migliore" di tutto, dovrà stare in ambiente misto.
Sostituiamo il concetto problematico di "migliore" con "il suo preferito" e non cambia nulla di una virgola.
Ora io sono assolutamente favorevole alla varietà: funziona in biologia, immagino che funzioni anche nel campo del software (e sembra funzionare). Quello che dico è che *oggi* è un peccato avere tutto basato su due set librerie (specie visti i motivi per cui sono nate).
Il top sarebbe avere una base comune e poi tutti i vari DE, programmi etc uniformi. Alternativamente bisogna continuare a lavorare sulla compatibilità (e viste le linee guida secondo cui è sviluppato X11, questo porta alcuni problemi).
Ora il fatto che probabilmente con KDE 4 e Gnome 3 (o con i loro successori) si avrà la stessa integrazione che si avrebbe con un unico set di libreria è un altro discorso.
Gambas (un IDE Basic) funziona solo sotto KDE. KDevelop pure (e se uno si trova bene con KDevelop, non necessariamente si trova bene con Anjuta e vice versa).
In molti giurano che Amarok sia il miglior player audio sotto GNU/Linux. Altri possono dire lo stesso di Rythmbox (non entro in nessuna di queste dispute).
Diciamo soltanto che effettivamente i casi in cui si ha un po' di tutti e due sono frequenti. A me personalmente è sempre capitato, e che io ne sappia non sono certo l'unico.
Certo se uno vuole evitarlo, si può sacrificare un pochetto e stare uniforme.
Poi si è detto delle periferiche non supportate. Cioè, non mi stancherò mai di dirlo, ma cosa c'entra il fatto che alcune periferiche non siano supportate con il lato desktop di linux??? Mi si dice "è difficile far funzionare una periferica non supportata"
Il problema è che GNU/Linux è anche visto come drop-in replacement per Windows (e in quel contesto si diffonde). Chi decidesse di cambiare e passare a MacOS (ovvero di cambiare macchina) potrebbe non avere problemi a spendere qualche decina di euro in più per un paio di periferiche non compatibili (a parte il fatto che in pratica io la non compatibilità l'ho incontrata solo con le webcam, che ora sono integrate).
Ma chi provasse GNU/Linux sul proprio PC e vedesse che "non va un cazzo" (ovvero il modo di dire del niubbo per indicare che c'è qualche problema) potrebbe ricevere una pessima impressione dal fatto che le varie cose non fungono o non fungono "altrettanto bene".
Pessima impressione, qualche problema suo di apprendimento, qualche altra magagnetta qua e la, e via, si passa oltre "linux è difficile". Come credi che nascano i luoghi comuni.
E poi tu spiegagli la congiura dei produttori di hw che fanno solo per winsows. Non credo che gli interessi di chi è la colpa quando le cose non vanno.
Certo che è difficile cavolo, se non è supportata come la usiamo? Prendi una periferica supportata invece, che ci vuole a installarla? Due click o anche meno se l'attacchi al momento dell'installazione dell'os.
Spero che non si stia suggerendo di reinstallare ad ogni aggunta di periferica...
Tornando a noi... si in generale si. Salvo quando i malfunzionamenti gettano messaggi di errore chiarissimi per gli sviluppatori e arabi per gli utenti, che non riescono a metterli sulla strada per la risoluzione del problema.
Tranne quando le GUI per configurare la periferica o non ci sono, o sono fatte da schifo.
Allora a questo punto si dice che è impossibile al momento dell'acquisto sapere se è compatibile con linux
. Clone ha dato uno dei siti sui quali controllare oppure molto più semplicemente si apre yast o chi per lui e si controlla nell'elenco hw una periferica a caso delle supportate dagli elenchi. Poi si procede all'acquisto. Questa è l'unica rottura ma non si può fare altrimenti. Daltronde anche con OSX per alcune periferiche sensibili bisogna informarsi prima dell'acquisto ma questo non mi pare un limite al lato desktop di osx...ne convieni?
Il problema è prima di tutto soprattutto con le periferiche che si hanno in casa. In secondo luogo la parola "compatibilità" non è spesso digerita dall'utente.
Per esempio se vai a leggere, si scopre che certe multifunzione (escluse le HP che per quanto ne so funzionano perfette) cristano. O va poco lo scanner, o altro ... ho vaga memoria di diversi thread trovati in giro riguardo alla stampante della mia ragazza. Che alla fine qualcuno riesce a fare funzionare tutto, qualcuno no, qualcunaltro segue le istruzioni e non funziona nulla e magari propone un cammino alternativo.
Ancora ricordo quando per un modem USB c'erano in giro 4 o 5 tutorial tutti incompatibili fra loro (e per inciso tutti incompleti o addirittura sbagliati). Alla fine il modem lo vedeva (dopo che avevo messo le mani nei sorgenti del driver "a sentimento"). A quel punto mi sarei dovuto mettere a lavorare pure sul protocollo e capire perchè il modem non parlava con la centralina.
Tenendo conto di quanto "costi" un'ora del mio tempo, ho preferito acquistare un modem ethernet e via. Ma insomma...
E la cosa assurda è che il modem veniva sempre "quasi" visto. Solo che poi non funzionava una fava, ma dalla GUI l'impressione era che sarebbe dovuto funzionare.
Per tornare alle stampanti mulyi...
Che fare andare si fanno andare, ma per c'è da sudare per alcuni modelli. Su tutto lei voleva una con inchiostri separabili, quindi Epson o Canon, non HP. In offerta era quella, non un altra.
Insomma, IMHO la fai troppo facile. Sono problemi che dovrebbero essere quanto più possibile ridotti.
E ribadisco, il problema non è la colpa. Il problema è che continuando ad assommare fastidi, si finisce solo per allontanare l'utente.
Da qui si è spaziato su tanti fronti ma non si è detto nulla fino al tuo post (il primo dei due costruttivi) dove c'erano i problemi nell'audio accettati in toto, i problemi dei moduli del kernel veri in parte e dei quali dedico un capoverso dopo.
Dovresti cercare di dimostrare perchè i problemi al kernel sono "veri in parte". La compatibilità binaria nel kernel è una teoria solo tua, se chiedi ad uno svilippatore qualunque ti dirà che loro *non* la garantiscono.
Ovvero, il mio problema nell'installazione di iTele sul mac che mi ha fatto smadonnare almeno quanto l'installazione del modem usb quando iniziai a usare linux.
Software rognoso ne esiste per tutte le piattaforme: il punto è vedere quanto spesso accade e quanti altri problemi ci sono.
Quello che io vorrei che tu capissi è che per l'uso desktop d linux non esiste un *singolo* problema insormontabile. Sono tanti piccoli problemi, qualche problema un po' più grande e una miriade di fastidi.
Questo non ferma chi ha intenzione di fare un certo uso del sistema, chi è curioso, chi è appassionato o chi ha certe motivazioni ideologiche.
Ma queste sono una minoranza delle persone. Per portare GNU/Linux a quote di mercato decenti, bisogna ancora lavorare molto.
In USA per esempio stanno cominciando a vendere PC iper low-cost con GNU/Linux preinstallato. Di solito sono linspire o roba del genere. Apparentemente funziona: sono PC super-economici per persone con necessità iper base. Sono quasi pià delle appliances qualunque che dei computer. Poi nessuno ha modo di sapere se girato l'angolo il cuggino installa windows pirata.
e come critica spunta CUPS
, altro esempio interessante
No? Non lo trovi interessante?
Ti ho già detto, e non hai risposto per esempio, che anche su OSX certe periferiche non sono supportate nonostante tu dica che next è una tecnologia più modulabile ecc...
Non è che lo dico io. Chiunque abbia un minimo di infarinatura su come funziona un kernel ti dirà lo stesso. Poi i dice modulare, non modulabile. È un'altra cosa.
Se poi vuoi
Lo vuoi capire che alle Case non gliene fotte una mazza del misero mercato di questi due OS??? Le grandi case danno supporto e investono su questi due os ma alcune se ne strafregano ed è questo il problema, è tua la mancanza di onestà intellettuale quando superficialmente ti limiti a dire che è un problema di concepimento del kernel
Resta il fatto che quando Apple vuole che una data periferica sia supportata, paga e gli forniscono il driver binario. Punto e morta li. Poi riempiti la bocca di onestà intellettuale e tutto, ma il fatto è questo.
firefox,openoffice e gwenview mi danno dialoghi di stampa uguali comunque ho capito cosa vuoi dire anche se...di preciso il problema?
Sono diversi e penso che tu lo sappia perchè sono gui che si interfacciano con un comando e ognuno può fare la gui che più gli piace.
Ti prego, non costringermi a postare gli screenshot. Devo farlo? Ok.
Sono diversi perchè chiamano librerie diverse. Ogni ambiente di programmazione di alto livello offre i dialoghi standard già fatti (stampa, apri, salva).
Questo perchè uno dei principi di tutte le linee guida di usabilità richiedono che cose uguali devono essere uguali. È un fondamento.
Inoltre se uno imposta dei default, questi vengono mantenuti (o dovrebbero esserlo) fra le applicazioni che usano gli stessi dialoghi.
Io sull'acrobat 7 non ho nessuna linea di comando
. Anzi è un dialogo di stampa molto windows-like, in alto scelgo una stampante e sotto scelgo scale, profondità di colore, il centraggio, il numero di copie, le pagine da fare ecc...
Ti posto lo screenshot anche di questo, non c'è problema.
Cosa vuol dire non stampa?
Quel spesso e volentieri mi fa capire che il tuo acrobat è dotato della capacità di intendere e di volere
Quale sommo umorismo! *Non* stampa vuole dire una cosa sola: uno da il comando di stampa e il foglio non esce.
Il punto è che acrobat in buona sostanza si limita a passare un pdf (eventualmente elaborato) a lpr. Punto e basta. Invece gnome si interfaccia direttamente a cups, al server, senza passare per il client lpr.
Ergo può benissimo essere che uno stampi e l'altro no. Succede quando il server non si è configurato bene, per cui lpr passa il file ad una coda che non è quella di stampa.
E poi riko anche Anteprima funziona con l'80% delle immagini su, e non ho mai avuto problemi di stampa. Mandami il file che ti da problemi che provo io a stampare.
Anteprima funziona con l'80% delle immagini? Non dire assurdità. Anteprima funziona con tutte le immagini valide dei formati che supporta. Se hai bisogno di supporto per qualche formato che Anteprima non gestisce, GraphicConverter gestisce di tutto.
Tornando a noi, il problema di "stampare male" (che è distinto dal non stampare) accade semplicemente perchè mancano i font per la stampa (o meglio, manca il font usato da chi ha preparato il pdf: o meglio gli viene sostituito un font che ha diverso kerning di base. Il risultato è che i caratteri sono accavallati).
Ma dove? Ma quando? Certo che li cambio al volo e con tutte le applicazioni che hai elencato.
Il tutte le interfacce di stampa io ho sempre le stesse opzioni e in tutti puoi scegliere se stampare in scala di grigi o a colori, la profondità ecc e non capisco cosa vuol dire "richiedono la coda di stampa fatta apposta in bianco e nero"
Allora: adesso posto gli screenshot che ti fanno vedere che *non* è vero che i dialoghi di stampa sono tutti uguali.
E comunque se vuoi cambiare la risoluzione della stampante (stampare a 600dpi invece che a 300, oppure lavorare sulla "qualità" -- quello che dice qualità bassa, media, alta -- e sta roba), *non* ci sono le opzioni. Qualcuna sul sw KDE, ma gnome, open office e firefox *no*.
Riguardo al bianco e nero, molti programmi lo supportano, ma non tutti. E per altro - se tanto mi da tanto, visto che sembrano non interagire con il server cups, ma piuttosto passare dati grezzi - creano loro una versione in bw dell'immagine, ma non settano la stampante per stampare bw. Su quest'ultimo punto posso sbagliare.
Resta il fatto che la maggior parte delle opzioni non sono gestite. Se non ti è chiaro cosa vuole dire "creare una coda di stampa", vai a leggere il manuale di CUPS.
A me non piace proprio invece, io è col mac che non ho ancora capito come stampare in bozza
e infatti col mac non stampo mai. Non so poi come fai a dire che quella ti pare una gui ben fatta, va beh sono gusti però è veramente limitata.
Si fa nel modo ovvio. Che stampante hai? Io ho due HP:
sulla getto di inchiostro varo in
"Paper Type/Quality" e selezioni la qualità desiderata
sulla laser vado in
Image Quality e seleziono la risoluzione più bassa.
Le piccole differenze sono dovute al fatto che (giustamente) MacOS X sfrutta il driver di stampa sottostante e quindi ne offre le opzioni.
Peraltro non è un caso se la quasi totalità delle tipografie usa MacOS e MacOS X per la stampa.
. Ma di questo non serve parlare, insisto sul fatto che non è colpa di linux e cerco di farlo capire anche perchè c'è poco da fare.
ok, era un pò confuso il posto a cui rispondeva Clone: l'esempio di Matlab era il mio, ma è stato usato per citare ncc come troll, ora mi è piu' chiaro