L’articolo di oggi è un articolo personale, nato dalle mie esperienze passate, che mi piacerebbe condividere con i miei lettori. Come ormai avrete incominciato ad intuire mi piace vivere a contatto con le varie comunità che producono codice aperto. Mi piace perché è un ambiente stimolante, un sottobosco estremamente vivo, che brulica di novità che forse un giorno saliranno alla ribalta, conquisteranno una nicchia o semplicemente scompariranno. Mi piace soprattutto per il rapporto diretto con chi sviluppa. Poter parlare con uno sviluppatore di una determinata caratteristica praticamente senza intermediari non ha prezzo. Il rapporto umano ovviamente diventa centrale e proprio di questo vorrei parlare in questo articolo.
Sento spesso dire che le comunità che sviluppano codice aperto sono solite trattar male i nuovi arrivati. È opinione diffusa che tali comunità siano formate da bizzarri personaggi che vivono in un mondo tutto loro e godano nel “mangiare” chiunque faccia loro una domanda o sollevi qualche dubbio. Alcune persone appartenenti a questa categoria esistono, sarebbe stupido nasconderlo, ma in generale ho trovato persone che sanno ascoltare chi propone e pone problemi pertinenti.
Ed è proprio questo il punto… imparare a essere pertinenti. Il contatto diretto con lo sviluppatore toglie il filtro con un eventuale servizio di aiuto. Se si conosce il problema in maniera accurata questo è assolutamente un pregio. Sono sicuro che molti di voi hanno almeno una volta nella vita telefonato ad un servizio di assistenza tecnica sperando che dall’altra parte del filo ci fosse qualcuno *almeno* al vostro livello di competenza (rimanendo spesso delusi).
Gentilezza o competenza? questo è il dilemma!
Il lato positivo di avere un intermediario pagato per fare quel lavoro è che anche se non sapete niente dell’argomento di cui vi state lamentando difficilmente vi beccherete un insulto o un RTFM ma avrete la fortuna di poter ascoltare una bella “soluzione preconfezionata” che magari non risolverà il problema ma vi riempirà di autostima.
Nel contatto diretto invece lo sviluppatore non è obbligato in alcun modo a rispondere a chi non si è preso nemmeno la briga di capire di cosa sta parlando. Per molti questo potrebbe essere un difetto ma questa attitudine mi ha insegnato in qualche modo a crescere. Le prime volte, quando ti becchi un RTFM, incominci a credere che chi ti parla abbia un qualcosa contro di te… come quando per la prima volta vieni sbattuto fuori dalla porta a scuola (esperienza fatta diverse volte durante scuole elementari medie e superiori). In quella fase in cui prendi l’affronto sul personale pensi a tutto tranne ad una cosa: Fare quello che ti è stato detto, magari con poco tatto, di fare. Andando avanti ti accorgi che quando in maniera scontrosa ti dicono di leggere un manuale è perchè la soluzione spesso è nel manuale.
Leggere il manuale potrebbe salvarti la vita!
E piano piano incominci a capire come risolvere da solo i problemi con tutta una serie di strumenti che sono stati costruiti allo scopo. Scopri che se nella cartella dei sorgenti di un progetto il file README.txt non è stato messo “tanto per mettere un file in più”. E scopri che quando ad un brutto e cattivo sviluppatore fai una domanda pertinente che non trova risposta in manuali, wiki, readme e altre risorse il 99% delle volte troverai in lui una persona disposta ad ascoltarti e aiutarti.
Secondo me la verità sta nel mezzo. Chi chiede dovrebbe sforzarsi un minimo di andare oltre a “ho premuto il pulsante e non s’accende” ma anche lo sviluppatore dovrebbe provare a mettersi nei panni dell’utente e cercare di capire dove voleva arrivare.
In fin dei conti se non stiamo parlando di qualcosa di super professionale dove si presume che l’utente finale abbia un minimo di cognizione di causa di cosa vuole combinare, ma proprio del tostapane della vignetta, lo sviluppatore dovrebbe proprio ricordarsi che l’utente ultimo di un elettrodomestico non dev’essere per forza un genio dell’informatica quindi se lo tratta a pesci in faccia, il minimo che si prende indietro è un sono vaffa, senza tanti filtri da customers care. Ci sono poi quelli che rispondono male perchè scambiano idee secondo loro controverse a livello di filosofia del programma con ignoranza e mancanza di voglia. Se una persona ti fa notare che è più comodo o più stabile che le cose funzionino in un dato modo (magari portando in dote fior di esempi), almeno un minimo di senso critico ed ammettere che la strada attualmente intrapresa è sbagliata o anche solo discutibile ci può stare. Invece più si prova ad avere un contatto e più si chiudono a riccio.
Non voglio dire, ma guardiamo la maggior parte delle gui su linux: sono quasi tutte palesi imitazioni di windows e osx. Anche quelle che nascono con uno stile proprio tipo xfce, finiscono per darsi una presentazione degna di una vecchia versione di explorer. La freschezza di idee delle prime gui, dei primi window manager sembra scomparsa da tempo. Chi porta ancora avanti Window Maker ?
Ai tempi probabilmente qualcuno avrà osato far notare che certe soluzioni sono carine ma poco comode e la discussione non è andata lontano poi, passano gli anni e causa “mercato schiaccia sassi” lo sviluppatore s’è trovare costretto a cercare di recuperare ed è finito per scopiazzare in blocco uno dei desktop di riferimento.
Qualcuno dovrà anche leggersi il manuale, far finta di leggerlo almeno, ma qualcun altro dovrebbe anche fare il piacere di scendere dal piedistallo.
@[D] perfettamente d’accordo.
Alle superiori facevo informatica, e per una relazione di fine anno dovevamo produrre un software abbastanza complesso (in visual basic o in c…) che servisse a qualcosa e appunto relazionare il tutto.
Io produssi una piccola utility per rinominare automaticamente i file mp3 appartenendti ad un dato album, partendo dalla lista tracce del CDDB.
Il programma fra le altre cose aveva dei pulsanti per riordinare manualmente la lista tracce prima che venisse rinominata. Per me era del tutto naturale aggiustare manualmente la lista file.
Feci vedere una versione semi definitiva, beta, dell’applicazione al professore che subito mi disse “ma non puoi farlo fare automaticamente?” Ammetto che in un primo momento pensai “ma come ti costa tanto ordinare a mano?!” Poi mi resi conto che effettivamente una tale feature sarebbe stata molto comoda per un utente e la aggiunsi (lasciando cmq la possibilità di aggiustamento manuale).
Piccolo esempio di come molto spesso uno sviluppatore in quanto tale deve sforzarsi di assumere il punto di vista di un utente, anche se difficilmente potrà coprire tutti gli aspetti.
Per questo come giustamente dici ci vorrebbe la pazienza e il buon senso di ascoltare i feedback degli utenti, anche quelli più niubbi.
Il fatto è che spesso vengono fatte richieste che nel “mondo normale” suonerebbero come qualcosa di questo tipo:
Utente: “Salve ingegnere che progetta tostapane… sono un suo cliente e vorrei che il suo tostapane facesse anche lo spremi agrumi perché a me piace bere una bella spremuta con il toast. L’azienda X
lo fa e sarebbe nettamente meglio fare qualcosa del genere.”
Per come sono fatto io non riuscirei a rispondere male nemmeno a chi si presentasse con una pretesa di questo tipo (per me qualsiasi tipo di feedback è importante)… ma non riesco a biasimare chi preso da sconforto ogni tanto risponda per le rime.
Quello che volevo evidenziare è che nella mia esperienza di sviluppatori che stanno sul piedistallo ne ho trovati veramente pochi. Ho trovato magari persone molto convinte delle proprie scelte (giuste o sbagliate non sta a me o a te deciderlo) che anche senza intenzione di cambiare idea ti spiegano la loro visione. Magari sono stato fortunato.
E se io leggo e non capisco?
Quando al liceo facevo informatica – con il solito, caro, Turbo Pascal – non capivo gli array.
Chiedendo alla mia prof la risposta fu “studiati il libro”.
Io il libro l’avevo studiato, ma continuavo a NON capire.
Per quanto possa esistere il manuale non è detto che il manuale sia sempre comprensibile per tutti…
@Federica
Vedrai che se hai letto il manuale e non hai capito qualcosa (cosa normalissima che succede a tutti), l’atteggiamento di chi ti sta di fronte cambierà radicalmente.
Questo fa di lei una pessima professoressa. Una professoressa vera non direbbe mai una cosa del genere ma una semplice frase estremamente potente: “Spiegami cosa non capisci e vediamo di arrivarci insieme.”
Il manuale non è una panacea, ma provare a leggerlo in moltissimi casi aiuta a risolvere i problemi.
““Salve ingegnere che progetta tostapane… sono un suo cliente e vorrei che il suo tostapane facesse anche lo spremi agrumi perché a me piace bere una bella spremuta con il toast. L’azienda X
lo fa e sarebbe nettamente meglio fare qualcosa del genere.””
Beh la risposta potente in questo caso potrebbe essere.
“ci lasci il suo recapito. Quando presenteremo il -colazionetutinuno- sarà nostra premura ricontattarla”
Poi chi lo sente più il tizio, ma sempre meglio che riempirlo di insulti perchè non vuol capire che il tostapane deve fare il tostapane
Per esperienza personale (da anni su un forum che tratta di software video), non posso che condividere il parere espresso nell’articolo.
E’ normale che ci siano utenti alle prime armi che chiedono cose “stupide” per chi utilizza da molto un software.
Ma, con pazienza e tempo, si possono spiegare anche le cose più basilari; che, una volta risolto il problema, finiscono nella sezione “F.A.Q. & beginners”.
Il problema inizia a presentarsi quando ogni mese c’è almeno un nuovo utente che, avvicinandosi per la prima volta al software, chiede le stesse cose.
In quel caso più che un invito a leggere il manuale, l’invito è a leggere ALMENO le sezioni del forum!
“Su, Nuovo Utente, dimostra almeno un pò di buona volontà nell’apprendere.
Usa la funzione ‘Cerca’ del forum e scoprirai che altri 50 nuovi utenti hanno chiesto la tua stessa cosa e gli è già stata data risposta”
In una delle aziende in cui ho lavorato, visto che i nostri clienti diretti erano gli installatori e non gli utenti finali, e visto che eravamo praticamente leader del settore, avevamo adottato una politica di assistenza piuttosto pragmatica.
– XXXXX buongiorno, sono Drizzt
– Ciao, sono l’installatore Sempronio. Sono dal cliente, sto installando il software, non riesco a fare [una qualche cosa]. Come si risolve?
– La cosa che stai cercando di fare e’ spiegata chiaramente nel manuale.
– Si, ma sono dal cliente, non posso mettermi a leggere il manuale adesso
– Infatti dovevi leggerlo PRIMA di andare dal cliente. Ciao, buona giornata.
mi sembra che, spesso, chi critica un rtfm, confonda un tecnico, quale puo’ essere un ingegnere od un programmatore, con un responsabile del customer care.
Drizzt scrive:
– Si, ma sono dal cliente, non posso mettermi a leggere il manuale adesso
– Infatti dovevi leggerlo PRIMA di andare dal cliente. Ciao, buona giornata.
Beh però se mi rispondi così ti tengo stretto per i capelli e ti tiro una tripla testata sul naso fino a quando non ho riempito un becher da 200 ml di tuo sangue!
:P
“Il problema inizia a presentarsi quando ogni mese c’è almeno un nuovo utente che, avvicinandosi per la prima volta al software, chiede le stesse cose.”
Forse a quel punto sarebbe il caso di riguardare un po’ com’è fatto quel programma e chiedersi come mai tutti incappano sempre nello stesso problema.
Qualche tempo fa a Voyager parlavano di quelle impronte preistoriche scoperte in Sicilia e lo studioso che le analizzava si stupiva come a distanza di millenni, un’eventuale persona che fosse scesa dallo stesso tratto di montagna avrebbe ripercorso esattamente gli stessi passi con le stesse identiche orme, appoggi, scivoloni… Questo significa che la gente generalmente tende a ragionare allo stesso modo o che c’è una logica di fondo alla quale non si sfugge. Se in un anno 365 persone, una a settimana, ti chiedono sempre la stessa cosa, forse c’è qualcosa che effettivamente non torna.
http://www.joelonsoftware.com/uibook/fog0000000249.html la bibbia …
l’ utente non ha voglia (o tempo, o qualsiasi altra cosa) di leggere il manuale – questo è un fatto ormai assodato con cui chi progetta deve imparare a convivere (se vuole che la sua applicazione venga usata da un’ utenza il più vasta possibile, cioè)
ma questo non vuol dire che l’ utente sia completamente ignorante o sprovveduto rispetto all’ uso dello strumento o al campo applicativo dello strumento – spesso è effettivamente così, ma è un grave errore darlo per scontato (cionondimeno, molti sviluppatori -per restare in ambito sw- lo commettono, e il risultato a volte è una GUI “dumbed down”, per certi versi più offensiva dell’ rtfm)
l’ assunto da cui si dovrebbe partire è che l’ utente sia in possesso di un certo bagaglio di conoscenze (attinenti se non il particolare strumento, quantomeno l’ ambito applicativo per cui ne necessita) e di un certo modello mentale
l’ aspetto interessante è che quanto più si avvicina il modello concreto del programma o prodotto ( l’ unico su cui si può realisticamente intervenire) a quello mentale dell’ utente (cambiare il quale è implausibile, o quantomeno molto arduo – anche perchè superata una certa soglia, l’ utente guarda a soluzioni differenti) tanto meno è indispensabile leggere il manuale prima di essere produttivi
i problemi nascono quando i due modelli divergono – a quel punto vale la pena indagare sul perchè divergano, e se tale divergenza sia necessaria o inevitabile…
durante lo sviluppo è mancato l’ apporto di esperti (o anche solo competenze) in psicologia, neuroscienze e usabilità? (e questo perchè? non lo si è reputato utile o necessario – quando invece è parecchio determinante, e praticamente tutto il sw di un certo livello, su cui l’ utenza in effetti si orienta, è sviluppato giovandosene)
lo/gli sviluppatore/i hanno preferito seguire una concezione di usabilità e “come il programma deve funzionare” propria, e imporre questa all’ utente , piuttosto che chiedere l’ opinione dei potenziali utenti? (e questo perchè? non c’è stato il tempo di farlo ? o la volontà? o magari gli utenti sono per definizione degli ignoranti e la “conoscenza” è appannaggio esclusivo degli sviluppatori? )
[D]
bingo
una cosa che si constata spesso laddove più alta è la concentrazione di RTFM (forum di supporto a linux o altro sw open source) è la tendenza, di fonte a tanti che lamentano uno stesso problema, a implicare che vi siano tanti utenti ignoranti/incapaci/pigri/ malcondizionati (da altro sw)/altro, in giro
cioè a partire dal presupposto che la \colpa\ stia sempre dalla parte dell’ utente, mai da quella del programma, sviluppato in modo poco intuitivo (o magari come capita per il sw di derivazione unix, in base a modelli api e paradigmi anacronistici) …
ma questo è in effetti un approccio tipico della \comunità\, laddove il sw e il supporto annesso sono forniti pro bono da gente che lavora in base a priorità e valori personali
in un ‘azienda (ma in effetti ovunque si possa seguire un maggiore pragmatismo) la logica sarebbe:
x% dell’ utenza si lamenta di problemi con la feature Y del mio prodotto, ergo se riprogetto la feature Y avrò x% lamentele in meno dalla versione successiva
ergo ogni feedback da parte dell’ utenza è utile anche solo a fini statistici e di triaging dei difetti
triaging che non posso far fare direttamente agli sviluppatori che hanno creato il programma perchè loro tenderanno a ritenere perfetto il proprio lavoro (motivo per cui non andrebbe affidato a loro il supporto agli utenti finali – ma invece è quello che avviene regolarmente nel mondo FOSS, ed è quello che causa frustrazioni da entrambe le parti)
motivo per cui infatti in azienda (o comunque team organizzati) l’ utenza e sviluppatori sono disaccoppiati da almeno due livelli (feedback statistici e classificazione bug, triaging) e i primi non intervengono mai nelle discussioni riservate ai secondi e viceversa…
Molto bello quell’articolo, una vera e propria bibbia. Riguardo alla considerazione finale su dove si pensa che stia la conoscenza, mestamente concordo.
Basta pensare quante volte in fase di progettazione di un prodotto assistiamo ad un comportamento al quanto scorretto dove si decide al posto dell’utente se una cosa gli servirà o meno. Non che si dice “sta cosa funziona, ma noi pensiamo di poterla fare meglio” semplicemente si va di forbici dando per scontato che chi comprerà il pacchetto appartiene alla stessa categoria di scimmie fatte con lo stampino.
Basta vedere le pesanti limitazioni che accompagnano da sempre gli iphone e adesso i windows phone 7, o leggere le dichiarazioni di jobs riguardo lion, ballmer che risponde con un app store per windows 8 o canonical che taglia dritto e decide per noi che unity è meglio di gnome e che il tempo di file e cartelle è finito (affermazione veramente assurda dal momento che non reputo canonical capace di realizzare qualcosa di simile al tanto favoleggiato winfs)
a me sembra che state confondendo cosa sia un rtfm.
se un utente chiede come si usa una funzione, spiegata benissimo nel manuale, o si lamenta dell’assenza di una funzione presente, o riporta un malfunzionamento inesistente, un rtfm e’, oserei dire, doveroso.
non ho mai visto un rtfm rivolto ad un suggerimento riguardante l’ergonomia di un programma. possono nascere altri tipi di discussioni, ma un rtfm suonerebbe un po’ strano, non vi pare?
a meno che uno si lamenta che un programma non funziona bene, intendendo che l’ergonomia non e’ buona. ma in questo caso e’ l’utente che dovrebbe farsi capire meglio, anche perche’, ribadisco, state parlando con un programmatore, non con un customer care.
@Piererentolo:
Sei un installatore il cui lavoro e’ di andare in giro ad installare quel software. Hai ricevuto il manuale ed il software con mesi d’anticipo.
Studiare il manuale e’ il tuo lavoro. Vai dal cliente senza aver letto il manuale? Sei un coglione e ti attacchi.
Non ti sta bene? Ci troviamo un altro distributore, mica problemi. Saremo stati anche in Italia, ma ogni tanto qualche azienda che si ricordava come si lavora seriamente c’era.
@Drizzt:
Il problema con quel genera di apporccio è che quando arriva un concorrente con una politica di costumer care un po’ più accorta, poi la società si ritrova senza venditori. E in mutande.
@j
Seguo da tempo Joel Spolsky (preferisco però il blog di Jeff Atwood… mi sta più simpatico).
Comunque credo che una parte di commento di Dubbioso abbia colto in pieno il mio pensiero:
E ribadisco che questo articolo è frutto delle mie esperienze personali e niente più. Non vuole essere una bibbia e nemmeno un vangelo (sono abbastanza allergico alla categoria). ;-)
@ [D]
“Forse a quel punto sarebbe il caso di riguardare un po’ com’è fatto quel programma e chiedersi come mai tutti incappano sempre nello stesso problema.”
No. Si tratta semplicemente di NON VOGLIA.
Perchè se mi chiedi per la prima volta in che codec si esporta o che segnale passa da un cavo Composito, posso anche spiegartelo perchè il post poi finisce in “F.A.Q. & beginners” e tutti gli utenti potranno leggerlo ed evitare di chiedere.
Ma se sei il quindicesimo che lo chiede, significa che:
1- Non hai letto il manuale originale (e stiamo parlando solo di 35 pagine con esempi e tante immagini) dove è spiegato davvero molto chiaramente.
2- Non hai letto nemmeno la versione italiana che, a titolo gratuito, abbiamo tradotto e messo a disposizione di tutti gli altri utenti che non masticano bene l’inglese.
3- Non hai consultato nemmeno il forum ufficiale del produttore, dove dei moderatori, addetti solo a quello, rispondono decine di volte alla stessa domanda.
4- Non ti sei nemmeno preoccupato di leggere nel nostro forum le sezioni dedicate al tuo problema, per trovare la risposta.
5- Non conosci la funzione del tasto “Cerca” dei forum.
6- Non conosci Google.
7- Non sai utilizzare Wikipedia.
Ergo, se questo è l’approccio, rinuncia e vattene.
Io dispenso parecchi RTFM pure nella vita reale a madri, fidanzate e amici che effettivamente non si documentano mai, ma rompono i c******i subito.
Secondo me è dovuto al fatto che molti manuali ti prendono per deficiente e dopo un po’ la gente pensa che sia una cosa da deficienti leggerli. Nell’open source non è così, ma altrove sì.
“a me sembra che state confondendo cosa sia un rtfm.”
E’ un insulto, ecco cos’è…
Ti chiedo una mano e mi dici di leggermi il FOTTUTO manuale ?
A prescindere che il programma sia stato fatto bene o meno, che il manuale risulti chiaro e completo e che io abbia o meno voglia di leggerlo, preparati che il mio FOTTUTO piede, sta per entrare nel tuo FOTTUTO culo, così sentirai un FOTTUTO dolore ed impari nella maniera più FOTTUTA possibile che il FOTTUTO rispetto è dovuto.
Adesso, aldilà di tanti bei discorsetti va proprio detto che se certe comunità non hanno incontrato la benevolenza del pubblico e quindi del mercato è stato in larga parte merito della maleducazione che serpeggiava e serpeggia al loro interno.
“Non hai letto il manuale originale (e stiamo parlando solo di 35 pagine con esempi e tante immagini) dove è spiegato davvero molto chiaramente.
Non hai letto nemmeno la versione italiana che, a titolo gratuito, abbiamo tradotto e messo a disposizione di tutti gli altri utenti che non masticano bene l’inglese.”
Di cosa stai parlando ? Quali 35 pagine ? Quali esempi e quali immagini. Non stiamo mica discutendo di un particolare programma, ma di uno generico con un generico manuale che genericamente potrebbe essere monolingua, senza immagini ed esempi degni di nota.
“Non hai consultato nemmeno il forum ufficiale del produttore, dove dei moderatori, addetti solo a quello, rispondono decine di volte alla stessa domanda.”
Hai una vaga idea di quanto sia difficile risalire da post scritti da altri al tuo problema se è effettivamente lo stesso o varia abbastanza da rendere l’eventuale risposta non adatta ? Ci sono giusto passato qualche tempo fa per un problema di installazione di niente meno che ubuntu su un pc vecchiotto. Forum, google… tutto inutile alla fine a forza di andare per funghi ho avuto un’illuminazione.
“Ergo, se questo è l’approccio, rinuncia e vattene.”
Ergo se questo è l’approccio, mi trovo un altro programma e se te in qualche modo ci mangiavi sopra, questo mese ti fai pane e acqua. Ti piace ? ETFB (Eat the Fucking Bread) :P
Certe volte però bisognerebbe anche capire quando si ha a che fare con un gergo colorito e goliardico. Le parole vanno prese anche nel contesto in cui sono dette. Sono sicuro che se ti spedissi un RTFM di fronte ad una birra in un pub lo prenderesti con una risata. :D
Si ma il punto è proprio quello. Tu in qualche modo ti sei documentato da solo e poi magari hai fatto una domanda. Qualcuno fa la domanda, ottiene gentilmente una risposta e magari consigli su come cavarsela autonomamente la volta successiva, e te lo ritrovi a iterare lo stesso atteggiamento per mesi e mesi(sono scene a cui ho assistito).
Detto questo ci sono anche personaggi che mascherano la propria incompetenza con un RTFM e quelli sono in assoluto i peggiori. Quella è una sorta di elitarismo che mal sopporto.
“Certe volte però bisognerebbe anche capire quando si ha a che fare con un gergo colorito e goliardico. Le parole vanno prese anche nel contesto in cui sono dette. Sono sicuro che se ti spedissi un RTFM di fronte ad una birra in un pub lo prenderesti con una risata. :D”
Beh tra amici è un conto, tra perfetti estranei, fottuto di qui, fottuto di lì, possono restare tranquillamente fuori dal discorso soprattutto se dall’altra parte chi chiede è già incavolato di suo perchè magari s’era fatto conto di risolvere un certo problema in fretta ed invece finisce contro un muro di gomma. Non per dire ma non c’è un solo programma open source che non si presenta come la panacea di tutti i mali (in particolare quando i concorrenti sono commerciali e closed). Uno può anche cascarci, crederci, poi si trova nei guai, chiede aiuto e riceve rtfm ?
Le risate sono l’ultima cosa che gli passa per la testa.
“Qualcuno fa la domanda, ottiene gentilmente una risposta e magari consigli su come cavarsela autonomamente la volta successiva, e te lo ritrovi a iterare lo stesso atteggiamento per mesi e mesi(sono scene a cui ho assistito).”
Beh dev’essere proprio di coccio se riesce a chiedere più volte la stessa domanda ma spesso gli rtfm vengono sparati direttamente al primo contatto e questo non si fa.
“Detto questo ci sono anche personaggi che mascherano la propria incompetenza con un RTFM e quelli sono in assoluto i peggiori. Quella è una sorta di elitarismo che mal sopporto.”
I campioni della specie, quelli per i quali si fabbricano ancora gli scarponi anti infortunistici
Che Linux sia basato su modelli, api e paradigmi anacronistici questo lo dici tu, non c’è scritto da nessuna parte.
Un paio di esempi:
http://www.hwupgrade.it/forum/showpost.php?p=33406367&postcount=625
http://www.hwupgrade.it/forum/showpost.php?p=33422254&postcount=628
E la “bibbia” sull’argomento (ma è più generale): http://simson.net/ref/ugh.pdf
Ma i primi due sono sempre dello stesso autore?
Dello stesso autore del post in questo articolo intendo dire.
May be. :-P
@Pluto
Non sono mie considerazioni ma alcune sono ampiamente condivisibili. Anche se non sono così critico nei confronti di Unix, d’altra parte ne utilizzo un “famoso clone” da diverso tempo senza pormi troppi problemi a riguardo. ;-)
@Cesare
:D
Il lo programmo per hobby il “famoso clone”, (solo per me, non ho mai rilasciato niente,) ma non mi sono mai scontrato con le problematiche che descrive l’autore di post lincati.
per prima cosa io scrivevo testualmente
e mi sembrava chiaro che mi stessi riferendo a sistema operativo ma principalmente userland sviluppata in seno alla comunità open source/foss (per lo scopo qui la distinzione non occorre), quindi nell’ ambito di una monocultura centrata su unix
quindi potevo riferirmi a BSD, a Solaris, o whatever, “Linux” non so dove tu l’ abbia letto…
comunque sì, Unix, e quindi Linux che ne vuole essere un clone (peraltro ancora incompleto e non certificato) è un sistema concettualmente vecchio di 30 se non 40 anni (unix @ Bell Labs – 1969) :D
se lo cloni, mantenendone in vita API native con le loro simpatiche idiosincrasie e ambiguità (basta vedere i danni fatti da open, close, fclose, sync, fsync e flush e da generazioni di programmatori che usavano indistintamente le une o le altre salvo poi ritrovarsi con i file troncati come emerso recentemente :D – non essendo a conoscenza della differenza o dei motivi storici per cui esistono le une e le altre), il process model imposto alle applicazioni, il modello di sicurezza originario (tutto o niente, con buona pace di permessi a granularità fine, capabilities, e quant’ altro inventato nei decenni successivi) per quante nuove feature, o algoritmi e codice ottimizzati tu introduca, non ottieni per magia un sistema concettualmente “nuovo”
ottieni solo un’ implementazione ottimizzata e con qualche feature in più, di un sistema vecchio come era quello di partenza
Ve be lo dici tu, io non lo trovo vecchio solo perché è passato del tempo.
@Pluto: non serve chiudersi nelle proprie convinzioni… se continui a sviluppare su unix e cloni, con progetti sempre più grandi e dedicando tempo e studio, arriverai da solo alle stesse identiche conseguenze. Parli così solo perchè lo conosci poco ;-)
ehm… volevo dire “conclusioni” al posto di conseguenze… mi sa che il neurone mi si è addormentato… la notte dovrebbe essere fatta per dormire, non per il late-night coding… xD
Bisognerebbe attaccarlo al muro su un post-it. :D
ho una lavagna bianca in camera, userò quella per i promemoria…
Ok, le due parti hanno le loro buone ragioni, ma mettiamola così: senza RTFM, nel male e nel bene, saremmo ancora appesi agli alberi con la coda a mangiare banane!
@Scolapasta:
[…] senza RTFM, nel male e nel bene, saremmo ancora appesi agli alberi con la coda a mangiare Quiche.
(fixed)
ahaha, scusate il nerdismo, ma non ho saputo resistere :D
@TheKaneB
Guarda che molto probabilimente sono nato dopo di te.
@Pluto: l’età nel nostro campo non è una variabile strettamente indicativa. Generalmente un uomo di 40 anni, di cui 25 passati a programmare sarà molto più esperto e preparato di me che ne ho 25, di cui 10 passati a programmare… ma ho anche visto situazioni opposte, di ragazzi geniali che a 15-16 anni hanno fatto le scarpe a guru ben più stagionati (qualcuno ha detto per caso Marcelo Tosatti?).
Comunque il senso della mia frase è che tutti i programmatori che arrivano ad un livello sufficiente di esperienza su unix, e che non siano degli esaltati filoreligiosi ma gente con una mente aperta ed obiettiva, arrivano a trarre le stesse medesime conclusioni. Cioè che Unix è un concetto obsoleto per fare sistemi operativi, anche se alcune particolari implementazioni tendono a svecchiarlo, pur rimanendo l’implementazione moderna di una cosa obsoleta.
E’ come costruire una biga con i cerchi in lega, le paratie in fibra di carbonio e le sospensioni idrauliche… sicuramente andrà più lenta della mia panda :-D
Bene, assodato che Linux usa API oramai obsolete, perché questa interfaccia è giunta fino a me quasi immutata e praticamente immutabile? Invece, API più recenti, come quella di AmigaOS, io non so neanche cosa siano perché la storia le ha concellate?
Lo so che sono fuori tema, chiedo perdono, ma la domanda è troppo forte.
AmigaOS ha subito la sorte della compagnia Commodore che la sviluppava. Commodore è fallita nel 94, e quindi Amiga ha smesso di essere sviluppata (ai tempi comunque molti usavano Amiga ed erano entusiasti).
Unix invece è sopravvissuto perchè è nato in una università ed è sempre andato di moda dentro le università, a prescindere dalle decine di compagnie che ne hanno sviluppato negli anni delle versioni diverse tra loro (e anche incompatibili), ma che ne condividono i principi e la struttura di base.
Se oggi dovesse scomparire Solaris (cosa probabile dopo il passaggio da Sun a Oracle), continueremmo a vedere ugualmente Unix anche dentro Linux, FreeBSD, MacOS X, HP-UX e tanti altri sistemi proprietari.
La storia è piena di esempi in cui tecnologie migliori sono scomparse a favore di tecnologie più “scadenti”, per questioni di fortuna/sfortuna o per altri motivi diversi. Ad esempio Betamax vs VHS, 68k vs x86, energia nucleare vs combustibili fossili, ecc…