Newsgroup: it.comp.os.dibattiti
Titolo: Cosa non va in Linux........

1 ) copia, spesso perfeziona, raramente innova.
2 ) ha uno sviluppo caotico che spreca risorse.
3 ) vuole competere con win. E' un grande
    come server, per lo sviluppo, per il calcolo.
    Non capisco perchè dovrebbere competere con win.
 4 ) Odio che qualunque distibuzione ti installa 1.5 GB di
    semi-pattume.
 5 ) Non mi piace la politica commerciale di molte distro.
    Mi pare siano un tantinello parassitarie.
Che ne dite ?
ciao
PS: il so più interessante oggi è OSX , ma ti devi comprare un mac. Chissa
se si riesce ad installare su un gameCube?

 Che ne dite ?
 
Che ho visto troll migliori.

 Che ho visto troll migliori.
Mi spiace che la prendi cosě, il  mio č un discorso serio.
Uso linux da un pň di anni, per lavorare non userei mai win.
Ci sono cose che non mi piacciono e volevo vedere se sono solo mie
impressioni.
Sto pensando di passare a freeBSD. Se non altro non istalla 1.5GB a gratis,
spero.
ciao

 Se non altro non istalla 1.5GB a gratis, spero.
 
Finchè non imparerai a usare un programma di installazione ne dubito...

  Che ho visto troll migliori
Non e' un troll, e' un cagnaccio che ti fa un culo cosi' a RTCW.

 Non e' un troll, e' un cagnaccio che ti fa un culo cosi' a RTCW.
ROTFL :DD
-- 
il Vide - ICQ# 5301833
Togli OE per rispondermi
IAMM - it.arti.musica.metal 
IAMMol webzine: 
http://www.iammol.com

 2 ) ha uno sviluppo caotico che spreca risorse.
[..]
Cosa non va in te:
- sei un troll
- in quanto troll sei stupido
- invece che trascinarti in autostrada legato sarebbe stato meglio
  incatenarti in un recinto pieno di pitbull incazzati
- segnalazione all'abuse follows
- levati dalle palle, f/u & *plonk*
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 Non e' un troll, e' un cagnaccio che ti fa un culo cosi' a RTCW.
Ahahah


 spero.
Se tu sei un incapace oltre che un troll e non sai scegliere una
distribuzione decente non e' mica colpa di Linux, dovresti pensare
seriamente di darti all'agricoltura.
P.S. Ovviamente sei gia' nel killfile quindi risparmiati la fatica di
rispondere.


 seriamente di darti all'agricoltura.
Secondo me esageri... non puoi considerare "troll" ogni persona che non
parla bene di linux. Fermo restando che ha detto molte cazzate. La prendi
come un'offesa personale...
ciao

 spero.
Dai, confessa di esser stato tentato dal mac! Eh? Invidioso!


Mi piacerebbe che qualcuno mi spiegasse cosa ho scritto
di offensivo. Tra l'altro non ho nemmeno criticato linux
come tale, che uso e apprezzo da anni. In questo ng si discute di sistemi
operativi o no?
Devo fare una dichiarazione di fede per non essere insultato?
Sinceramente mi pare assurdo.

 - sei un troll
Thori, mi sta che stai invecchiando. Hai toppato, non sai piu' 
distinguere i Troll dal resto.
E riposto:
 > 1 ) copia, spesso perfeziona, raramente innova.
 > 2 ) ha uno sviluppo caotico che spreca risorse.
Opionioni opinabili.
 > 3 ) vuole competere con win. E' un grande
 >     come server, per lo sviluppo, per il calcolo.
 >     Non capisco perchč dovrebbere competere con win.
Un Troll non direbbe mai questo.
 >  4 ) Odio che qualunque distibuzione ti installa 1.5 GB di
 >     semi-pattume.
Sta parlando delle dribuzioni che fanno cio' (concordo in questo con lui).
 >  5 ) Non mi piace la politica commerciale di molte distro.
 >     Mi pare siano un tantinello parassitarie.
Sta sempre parlando delle dribuzioni che fanno cio'. Ad esempio, 
qualcuno accusa Mandrake di non contribuire abbastanza, ad esempio allo 
sviluppo del kernel (non e' opinione mia ma di altri). Dove hai visto 
scritto "tutte le distro di linux fanno cacare"?
Se vuoi ripassarti la lezione sui Troll, fatti un giretto nei forum di P.I.

 Che ho visto troll migliori.
In questo NG il troll e' "quello che esprime un'opinione diversa dalla mia"
? Devo ricordarmelo.
Saluti.

 ringhio wrote:

Beh sicuramente il Mac _a gratis_ non installa un bel NULLA :DD 



Lascia stare, se avessi 2000/3000 euro a buttare mi comprerei un mac. Con il
nuovo OSX a mio parere
ha allargato il potenziale bacino di utenti enormemente.
Primai mac non mi avevano mai tentato, ma con
questo fai /usr/bin/perl e ti senti a casa.
Quello che non capisco è cosa se ne fa l'utente medio
apple di una shell?
Per me è il capostipite di una nuova generazione so.
ciao

 di offensivo. Tra l'altro non ho nemmeno criticato linux
la (1) e' da flame, xche' si e' gia' discusso MOLTO in questo NG (anzi, si 
e' litigato proprio ^__^ ) sul concetto di "innovazione" nel campo degli 
OS.
La (2) per molti e' un pregio invece che un difetto.
la (3) beh, per prima cosa nel campo server e' Windows che vuole competere, 
mentre nel campo desktop si stanno facendo grossi passi avanti (io utilizzo 
 Linux Mandrake abitualmente e ci faccio tutto quello che potrei farci con 
Windows)
la (4) non ha puramente senso xche' le distro le installi come piu' ti 
pare. Se vuoi ti metto su una Mandrake da meno di 100 MB con comunque un 
po' di roba su.
La 5 non e' molto ben chiara. Inoltre mancano le motivazioni, che e' cosa 
tipica da troll. (nn sto dicendo che tu lo sia, cmq!)


 Beh sicuramente il Mac _a gratis_ non installa un bel NULLA :DD
Sicuramente, non mette il rompimento di coglioni come simpatico gadget 
in omaggio tutti quelli che acquisteranno il prodotto.

 apple di una shell?
Impara ad usarla. Ueh, c'e' la mia meta' che e' tutta contenta perche' 
sa fare cd, ls, pwd, cat, man...

 Sinceramente mi pare assurdo.
Vedi, la prima affermazione che hai fatto andrebbe
un po' giustificata.
Cosa copia Linux?
E` Linux l'unico a copiare?
E` sbagliato copiare?
Spesso "copiare" ha un senso negativo, non mi pare
un buon inizio per una discussione rilassata.
Perche` non parti dai risultati? Se faccio un file
server con tecnologia di 10 anni fa e questo va
bene o meglio di un file server di oggi, a cosa mi
serve l'innovazione?
Insomma direi che hai posto la questione in
maniera un po' troppo aggressiva, senza reale
cognizione di causa, senza far capire cosa
realmente volevi dire, lasciando pensare alla
provocazione.
Poteva andare se lo facevi con win :-)
bye,
-- 
  Piergiorgio Sartor

 tipica da troll. (nn sto dicendo che tu lo sia, cmq!)
Siccome credo di sapere di cosa sta parlando, ho gia' messo un post in 
proposito.

 Le distro *non* sono Linux.
Gia', ma usi linux attraverso le distro, quindi sempre con loro devi 
avere a che fare.

     semi-pattume.
Qualunque??? no, qualunque no, tralasciando che ogni distro ha una
installazione selettiva, non mi risulta che una slack o una debian installi
quintalate di roba se non è l'utente ad averle scelta.
-- 
| /
| \Byte - Andrea Briganti - 
kbyt...@freemail.it
http://www.kbytesystem.fasturl.it
 ICQ: 40872731
*** Chi non ha rispetto non merita considerazione

 Se vuoi ripassarti la lezione sui Troll, fatti un giretto nei forum di P.I.
Mi sa che ne hai bisogno tu o quantomeno di comprare un trollometro
nuovo, il mio funziona benissimo.


 avere a che fare.
E` *possibile* usare Linux attraverso le distro,
e` *comodo*, e` *raccomandabile*, ma non e` *necesario*.
E comunque, eventuali difetti delle distro, non
sono difetti di Linux.
Anche considerando che li distro installano anche
applicativi (mozilla, abiword, etc.).
Quindi se installi RH e ti ritrovi con 2GB di roba,
non hai 2GB *solo* di SO, ma hai anche altro.
bye,
-- 
  Piergiorgio Sartor

 proposito.
mmmh..dove? :)


 sono difetti di Linux.
Una distro e' linux + altra roba. Non capisco perche' i difetti debbano 
andare a finire solo nel + e nel secondo operando.
Comunque, e' evindente che Ringhio usava linux in modo improprio e 
riferendosi a qualcosa che va al di la del solo kernel e che includendo 
vari aspetti comuni alle distro.

 sensazione...
 
Cosa che non capirň mai visto che scegliendo i pacchetti singoli ti
indica ogni singolo kbyte... La lista č lě in bella vista :P
L'unica cosa discutibile č che la lista "ad albero" non contiene tutti i
pacchetti, alcuni si trovano nella lista "esplosa" (tra l'altro anche
cose molto interessanti)

 avere a che fare.
Non c'entra una sega: a voler essere pignoli (ed e' stato ripetuto tante
volte, qui) Linux sarebbe _solo_ il kernel. La distribuzione e' una
raccolta di SW messa attorno al kernel col quale, palesemente, da solo
non fai niente.


 mai sicuro di cosa mi abbia realmente installato. Sara' una sensazione...
Finche' continuerai a credere che distribuzione Linux == Mandreik
faresti meglio a lasciar stare con queste affermazioni.


 nuovo, il mio funziona benissimo.
Visto che lo conosco, so benissimo che non e' un troll.

 La 5 non e' molto ben chiara.
Ho provato red hat, suse, mandrake,  ora sto usando red hat al lavoro e
mandrake a casa.
Capisco che i soldi investiti devono tornare a casa ma trovo odioso che, per
esempio
i tool di configurazione e installazione siano sempre proprietari. Io la
vivo come un
tradimento. Alla fine le disto fanno ben poco, ok red hat sviluppa, suse
anche, ma
sono gocce in un oceano. Mettere dei vincoli alla ridistribuzione lo trovo
osceno.
Infatti ieri mi sono scaricato Debian 2.2rev6 e appena posso la installo al
posto
di red hat e di mandrake. Sto pensando anche a freeBSD ma lavorando con java
ho qualche remora.
ciao

 quanti hanno la voglia/tempo/conoscenza per farlo?
 
Ma se non sai quello che vuoi e selezioni ad esempio "WorkStation
Ufficio"+"Gnome"+"KDE" e così via non puoi lamentarti che installa molta
roba, è ovvio che se vuoi fare un'installazione ridotta all'osso devi
sapere cosa vuoi, no?

 avere a che fare.
Ma fare un discorso generale su Linux, equiparando tutte le distro, e`
sbagliato. Quindi, o si fa un discorso /per distribuzione/ oppure si fa
un discorso su Linux.
+++
E.g.: ringhio dice che le distro installano 1.5GB di roba inutile. La
mia Debian no, e non per questo e` meno (o piu`) "Linux" di un'altra
{ci sarebbe da dire che, facendo attenzione, nessuna distribuzione ti
installa 1.5GB di roba inutile}.
Bye,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.d2g.com/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 andare a finire solo nel + e nel secondo operando.
Perche' i difetti che vengono imputati a Linux (come SO), al 90% sono
difetti delle distribuzioni o delle applicazioni (quindi non del SO).


 che puo' essere il Packet Manager sia chiaro..anche se io lo odio)
Quella minchia di RPM!

 vari aspetti comuni alle distro.
Probabile.
bye,
-- 
  Piergiorgio Sartor

 faresti meglio a lasciar stare con queste affermazioni.
Le affermazioni erano rivolte proprio a quel genere di distribuzioni.
Io, forse l'ho gia' detto, sono stato piacevolmente colpito dalla Debian.

 spostare una directory.
Andiamo, basta un semplice rpm -i, fa tutto lui,
e se non lo fa lui, lo fa l'installer di turno.
bye,
-- 
  Piergiorgio Sartor

 i tool di configurazione e installazione siano sempre proprietari. Io la
Beh, saranno proprietari, ma sono Open Source.
Inoltre rpm viene usato da SuSE, da Mandrake e
da altri, non mi pare troppo proprietario.
bye,
-- 
  Piergiorgio Sartor

 e se non lo fa lui, lo fa l'installer di turno.
Come ti chiarito, e' un meccanismo che complica il sistema e lo rende 
potenzialmente bacato. E soprattutto, si capisce tutto quello che 
succede senza dover andare a studiare cosa fa e come si comporta il 
package manager.

 Visto che lo conosco, so benissimo che non e' un troll.
Sara' ma il suo post puzza di trolleggio, perlomeno per come e' stato
esposto.. e' che non c'e' la classe dei troll di una volta (vedi Rosco,
per esempio) pero' ripeto, se piu' persone hanno avuto la medesima
impressione forse qualcosa nella tua sicurezza di conoscerlo puo' essere
sbagliato.


 Io, forse l'ho gia' detto, sono stato piacevolmente colpito dalla Debian.
Questo lo stai dicendo _ora_ mentre prima sembrava proprio che per te
non esistessero altre distro oltre le due citate.


 ho qualche remora.
???

 strumento piu' adatto rimane Uindous.
Qui' hai un po' di presunzione nel pensare che tutti quanti abbiano il 
tempo di studiarsi quella documentazione o ne abbiano voglia piu' di 
farsi quattro scopate.

 se si riesce ad installare su un gameCube?
OSX ha un kernel unix

 > ho qualche remora.
Mi pare siano indietro con il supporto a java.
Sun sviluppa per win, linux e solaris.
Dovrei provare, ci vuole tempo.
Ciao

 package manager.
Mica lo devi studiare, il packet manager.
bye,
-- 
  Piergiorgio Sartor

 Se devo giocare uso M$, linux non potrą mai superare win in questo campo.
Anzi, non e` solo questionabile, e` proprio falso.
Vorrei ricordare solo qual'e` l'ambiente di
sviluppo di una diffusa console per videogame.
Non la Xbox.
bye,
-- 
  Piergiorgio Sartor

 farsi quattro scopate.
Probabilmente confondi lo scopare (cioe' usare Linux ovvero fare
qualcosa essendo consapevoli di cio' che si fa) col farsi le seghe (fare
qualcosa senza voler nemmeno provare a cercare se ci possa essere una
fonte di piacere superiore)


 > vari aspetti comuni alle distro.
Confermo mi riferivo alle distro non al kernel come tale.
Le critiche che ho fatto effetivamente le intendo al modo di gestire le
distribuzioni da parte di molte soluzioni commerciali, diciamo le più
commerciali.
La responsabilità del kernel per fortuna è centralizzata.
ciao

 Mica lo devi studiare, il packet manager.
No, ma vorrei avere sotto controllo il sistema, quindi capire cio' che 
fa quando installa un package: che file mette, dove, cosa mi sostituisce 
o aggiorna...

 altro filesystem..
E perché mai? I filesystem case sensitive sono la cosa più inutile che 
uno possa immaginare, che avevano senso solo quando anche la maggiore 
velocità di strcmp() rispetto a strcasecmp() era significativa: elencami 
sono un caso in cui vorrei dare due nomi uguali, differenti sono nel 
case, a due file diversi.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 se si riesce ad installare su un gameCube?
ehm... dubito che sia fattibile facilmente

 o aggiorna...
Io, di solito, vado dentro l'rpm a vedere
cosa e come fa :-)
bye,
-- 
piergiorgio

 ? Devo ricordarmelo.
Non preoccuparti non ragionano tutti cosi... gli estremisti ci sono da ogni
parte...
ciao

 case, a due file diversi.
Il case insensitive puo' essere implementato benissimo in userspace, per 
chi lo vuole.  find & grep sono un esempio.
Il kernel deve solo fornire un servizio essenziale e un fs case sesitive e' 
piu' generale di un fs case insensitive.
-- 
Lorenzo

 case, a due file diversi.
pippo e Pippo :-)
Saro` libero di dare i nomi che voglio
ai file, o no?
Perche` devo essere costretto a limitare
la mia possibilita` di scelta?
bye,
-- 
piergiorgio

 piu' generale di un fs case insensitive.
Un FS case insensitive non serve ad una cippa, la generalità non c'entra 
nulla.


 la mia possibilita` di scelta?
Una "possibilità" che nessuno usa mai non esiste. Ti dirò di più, i FS 
case sensitive complicano la vita in modo assurdo, perché ti costringono 
a ricordare non solo il nome del file, ma anche le maiuscole e le 
minuscole usate nel scriverlo! Non ci potrebbe essere nulla di meno 
intuitivo.


 Gia', lo fanno in molti. Sicuramente quelli che non hanno tempo da perdere.
Objection, istallare linux "from  scratch" ha un valore  didattico che
puo` valere  tutto quanto  il tempo perso. 
 
-- 
ciao | Antispam in pillole: (LART 1)  Luser  Attitude Readjustment Tool;
cf   | La  segnalazione  al  provider  dello  spammer, l'unico mezzo che 
-----+ abbiamo a disposizione per combattere attivamente lo spammer. Nel 
numero l'efficacia del  LART  e`  devastante, fai anche tu la tua parte!

 intuitivo.
Cioe`, secondo te, in generale, la
distinzione maiuscole/minuscole e`
antiintuitiva?
Se nessuno usa questa distinzione,
che problemi vi sono ad usare un FS
case sensitive?
bye,
-- 
piergiorgio

 puo` valere  tutto quanto  il tempo perso. 
Per uno studente in informatica, può darsi, non certo per uno che il 
computer lo vuole solo usare come mezzo per andare in internet e 
stamparci la lettera.


 utenti enormemente. 
www.macexchange.it
ci ho preso un bel titanium usato e se pazirnti qualcosa a buon prezzo 
trovi.
Non avrei mai ri-comperato un mac se non fosse uscito il system x
Ciao
Marco

 
Che se avesti  lurkato gli ultimi 2-3mesi avresti risposto  da solo alle
domende che poni...
-- 
Renato "Hitman" Salzano  /  
http://spazioweb.inwind.it/hitman
ICQ #75729987 / IHGGer #778 / NapolICErs #2 / Druido della BUBBLE
"Sull'altare dei miei sogni hai bruciato un sogno in più / se ripenso
 che la nostra storia l'hai voluta tu / dovevo dirti di no"(V.Giovagnini)

Windows)
Giustamente. Sui server windows vuole competere, sui desktop invece
linux fa passi avanti. 
Ovviamente linux quando insegue non compete. 


Sono tutte distro commerciali. 
Prova Debian, cosi provi LA distro non commerciale per eccellenza...



Netscape usava delle sue libc, e  ti assicuro che le usa senza problemi.
Il resto del sistema non usa quelle librerie, senza complicazioni.
Se poi intendi che un certo programma  può usare una sua versione di una
certa libreria _con la stessa versione_ di un installata nel sistema, si
può con LD_PRELOAD (basta passarlo prima di chiamare il programma...).


sono difetti di Linux.
A meno che non devi costruire una statistica a confronto per vedere i
bugs presenti in windows e linux :-p
Fa' comodo contare piu' volte lo stesso errore (fino a 174 [*] volte
mi pare). Se si tiene conto che si possono aggiungere anche gli errori
degli applicativi la situazione e' davvero rosea ........ 
[*] e' il numero di distribuzioni basate su kernel linux elencate su
un sito (fra abbandonate e supportate)
-- 
Le razioni di cioccolata verranno aumentate a 20 grammi
dal film/libro:1984 - George Orwell (grazie Skip)
(nel film questa frase sostituisce: le razioni di cioccolata non verrano abbassate sotto i 25 grammi)

 case sensitive?
Stai quindi proponendo di abolire l'uso delle maiuscole o minuscole nei 
nomi dei file? Se no, cosa vuoi dire?


 Ovviamente linux quando insegue non compete. 
Che Linux non abbia un cazzo che competere con Uindous nel campo server
perche' palesemente superiore non mi pare sia nemmeno da discutere. m$
nel campo server e' sempre stata una chiavica perche' non e' mai stata
capace di distinguere il desktop dal server in modo serio.


 antiintuitiva?
Sě, lo č, ed č causa di numerosi problemi.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 Dovrei provare, ci vuole tempo.
http://www.freebsd.org/java/


 nomi dei file? Se no, cosa vuoi dire?
Questa e` la conclusione in base a
quello che sostieni tu.
bye,
-- 
  Piergiorgio Sartor


Questo e' falso. Basta trasformare tutto in maiuscolo (o minscolo) prima
del confronto.
Comunque non credo che che i file system case sensitive esistano per motivi
di performance, perche ' se cosi' fosse sarebbe bastato ammettere solo nomi
di file con maiuscole (o minuscole).
Alessandro.

 solo nomi di file con maiuscole (o minuscole).
 
Cosa che peraltro sarebbe dannosa per la leggibilità dei file. A volte si
può risparmiare molto spazio nei nomi (e quindi evitare di dover avere un
monitor da 1600x1200 per leggere un ls) eliminando
spaziature/underscore/trattini vari e mettendo all'inizio di ogni parola
la maiuscola.

 Ovviamente linux quando insegue non compete. 
Dicendo "passi avanti" mi pare scontato il fatto che Linux sia indietro su 
quel lato..
-- 
il Vide - ICQ# 5301833
Togli OE per rispondermi
IAMM - it.arti.musica.metal 
IAMMol webzine: 
http://www.iammol.com

 
http://www.freebsd.org/java/
Azz non lo sapevo, confesso che mi ero informato frettolosamente. Bene, ora
ho tre cd di debian e
tre cd di freeBSD tutti da provare.
Mi sa che la mia morosa si sentirą un pochino trascurata questo fine
settimana :-)
grazie

 postfix, proftpd, gnome e kde ecc ecc) e hai SCELTA.
Io ci metterei anche JBOSS che è un application server fantastico,
superiore a tutte le soluzioni commerciali da decine di migliaia di euro.
Tra l'altro ho uno slogan mitico : "sale in fretta e rimane su a lungo".
Sono comunque tutti esempi di sviluppo alquanto centralizzato, di team
organizzati. Secondo me sono la dimostrazione che i grandi
risultati, quelli che danno sostanza e reputazione all'open source
necessitano di
coordinazione.
ciao

Silver Drake :

Quando parlavo di solo maiuscole (o minuscole) mi riferivo solo ai caratteri
alfabetici, gli altri rimarrebbero uguali.
Alessandro

 caratteri alfabetici, gli altri rimarrebbero uguali.
 
Io mi riferivo proprio ai caratteri alfabetici infatti.

 del confronto.
Certo, ovvio, ma questo non cambia quello che ho detto: le performances 
verrebbero abbattute, perché la ricerca dei file dovrebbe essere 
implementata tutta in userspace, per mezzo di 
opendir()/readdir()/closedir() o simili (non considero neanche l'ipotesi 
di chiamare open() per ogni combinazione di maiuscole/minuscole...). 
Questo, evidentemente, porta ad un'abbattimento delle prestazioni, anche 
perché bypassa e rende inutile qualsiasi meccanismo evoluto di 
indicizzazione attuato dal filesystem.
Ci sarebbe anche un altro problema: un filesystem non case sensitive 
permette che due file con lo stesso nome, che differiscono solo nel 
case, possano coeistere nella stessa directory: una open("pippo"), quale 
dei due "PiPPO" e "pippO" aprirà?


 quello che sostieni tu.
E' una conclusione errata, tratta da una lettura errate delle mie 
parole, condita con una buona dose di preconcetti :)



Se il file system non e' case sensitive "PiPPO" e "pippO" sono lo stesso file.
Comunque, come ho gia' detto, se il problema fossero le performance basterebbe
trasformare tutti in nomi di file in maiuscolo (o minuscolo): del resto DOS
come fa?
Alessandro.

 Se il file system non e' case sensitive "PiPPO" e "pippO" sono lo stesso file.
si parlava di filesystem case sensitive sui quali, in userspace, si 
implementa uno strato NON case sensitive.


 Sto pensando di passare a freeBSD. Se non altro non istalla 1.5GB a gratis,
Secondo me tu manco riesci a metterlo su, freebee.
-- 
GHERdO, happy GNU/linux user.
"E sempre allegri bisogna stare...
	... che il nostro piangere fa male al RE!"

 ? Devo ricordarmelo.
Non credo. Credo invece che per criticare (positivamente o negativamente
non  importa)  sia  necessaria  una  certa  'cognizione  di  causa'  che
assolutamente  non  traspariva nel  messaggio  che  ha originato  questo
simpatico thread.


 Sta parlando delle dribuzioni che fanno cio' (concordo in questo con lui).
eh??? A casa mia "qualunque distibuzione" vuol dire proprio *qualunque*.
Seguendo il tuo  ragionamento, si puo` ipotizzare che  il suddetto abbia
infilato una volta il CD di Mandrake  e abbia lasciato il default. E qui
si arriva  a quello che dico  io: tale utente non  puo` portare critiche
FONDATE.


 invece il tuo compito e' finire un certo lavoro in tempo, chiaro che ti 
Aaaah, a questo siamo! 
Se  il discorso  e`  cosi`, se  serve  per lavoro  MA NON  SE  NE HA  LA
CAPACITA', la strada e` una sola:
			* PAGARE UN SISTEMISTA *
"tempo da perdere per capire" e` la battuta migliore che abbia sentito!



Ah, si?. Non la vedo una cosa molto sensata in effetti.
Chi avrebbe adottato una soluzione del genere?
Alessandro.

 a quel paese le "maggiori possibilità".
Bene, quindi il problema non si pone.
bye,
-- 
  Piergiorgio Sartor

 Chi avrebbe adottato una soluzione del genere?
Spero nessuno, ma era quello che si auspicava nel messaggio al quale io 
ho risposto.


 simpatico thread.
Non mi sembra proprio. E anche altri la pensano come me.
Saluti.

 Bene, quindi il problema non si pone.
Uh? Il problema si pone e come! Perché mai dovrei limitarmi alle sole 
minuscole?


 minuscole?
Uh? Mica sei "limitato".
bye,
-- 
  Piergiorgio Sartor

 nulla.
Capisco che abbiamo opinioni molto diverse ma e' un dato di fatto che un fs 
case sesitive sia piu' generale un fs case insensitive e molte applicazioni
richiedono il primo, come e' naturale.
Quelle che vogliono il case insensitive se lo fanno da sole con trascurabili
perdite di performance, come ti ho appena dimostrato e tu stesso hai detto 
2 post fa.
Riguardo invece all'utilita' di un fs case sensitive, distinguere tra 
maiuscole e minuscole permette di digitare di meno, cioe' e' piu' veloce e 
piu' semplice.
Prendi i sorgenti di Linux, troverai 'Documentation' e 'drivers', entrambi 
cominciano con la 'd', mi basta D<tab> e ho fatto. Con un fs case 
insensitive avrei dovuto digitare un tasto in piu'.  Esempio semplice e 
banale ma che dimostra che un fs case sensitive puo' aiutare l'utente, al 
contrario di un fs case insensitive.  Non mi ricordo se un file si chiama 
"pippo.c" o "Pippo.c" oppure "pippo.C"?  Usa -iname per find.
Dov'e' il problema?
-- 
Lorenzo


Secondo me vi siete capiti male :-)
Alessandro.

 Secondo me tu manco riesci a metterlo su, freebee.
Se lo dici tu sarà vero, non sono un sistemista ma ho comunque usato solaris
per un paio
d'anni, linux dalla red hat 5.1 o 5.2 non mi ricordo, mandrake e suse ( che
rimane la mia preferita ).
Con l'aiuto di dio conto di installare anche freeBSD.

 Dov'e' il problema?
A prescindere dal fatto che richiedere uno strumento in più per fare una 
cosa che con un altro sistema non l'avrebbe richiesto, è quello che io 
chiamo spreco di MIE risorse e scarsità di usabilità, se il problema 
sussiste in un programma? Ovvero, se è da un programma che devo aprire 
un file di cui non ricordo o semplicemente non posso conoscere il case?


 Secondo me vi siete capiti male :-)
Non credo proprio...


serve.
Dipende dalla distribuzione. Debian se gli dici di installare il minimo
occupa pochissimo (forse meno di 50Mb, sicuramente meno di 100Mb).
Slackware credo lo stesso.
Del resto dimmi tu quanto occupa una installazione minima di windows.
Ho sentito anche parlare di una distribuzione che prevede l'installazione
"on demand", cioe' fa' finta che il pacchetto sia installato ma lo installa
solo al primo uso di un suo componente.
http://www.distrowatch.com/review-sourcerer.php
Alessandro

 Uh? Mica sei "limitato".
Ah, no? Io mi autolimito ad usare solo parole con lettere minuscole, e 
non sarei limitato?
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism


Con ricerca lineare che secondo me in molti casi (cioe' quando non ci sono
centinaia di file nella directory) non e' cosi' pesante.
Ma tu non sei d'accordo, lo so.
Alessandro.

 Ma tu non sei d'accordo, lo so.
Non si tratta di essere d'accordo o meno, si tratta di usare gli 
strumenti adeguati per le problematiche in esame.


 rimane la mia preferita ).
Ah! Ah! E con tutto questo popo` di background da hacker non hai risolto
il problema dell'1.5GB di ciarpame installato? R.O.T.F.L.
Finisco qui. Ciao Ciao :)
-- 
GHERdO, happy GNU/linux user.
"E sempre allegri bisogna stare...
	... che il nostro piangere fa male al RE!"


Si ma rimane il fatto che, al momento, cio' che per te e' adeguato per me 
non lo e' e viceversa.
Alessandro

 non lo e' e viceversa.
Non è adeguato e basta, in questo contesto. Linux non userebbe un hash 
table, altrimenti, userebbe un albero come quello che tu descrivi.


 preferisci così, buon per te.
 
L'utente che fa una "installazione di default" è un utente che,
ovviamente, non ha le idee molto chiare su quello che vuole avere sul
suo PC. A questo punto mi sembra pure sensato che una distribuzione
cerchi di dargli una dotazione più possibile completa (tenendo conto che
una MDK se installi veramente tutto arriva quasi al doppio della
fantomatica "installazione di default" che citi), anche perchè vista la
scelta in fase di installazione non mi pare che questo utente abbia
molta voglia di andare a scaricarsi uno per uno tutti i programmi da
usare. Nel caso voglia farlo allora tanto vale che scelga
l'installazione minima (che, sorpresa sorpresona, esiste! e occupa meno
di 100 mega) e poi scelga i programmi che vuole.
Tra l'altro la scelta in questione è facilitata perchè i programmi sono
raggruppati in categorie e quindi se non si vuole ad esempio avere
server basta deselezionare la casella apposita.
Per il resto bisogna avere pazienza: il giorno che i PC sapranno leggere
nel pensiero sarà giusto lamentarsi se di fronte a una nostra voglia di
non dargli indicazioni scelgono qualcosa di diverso da quello che
vogliamo.
Nell'attesa tanto vale prendere delle decisioni minime, visto che una
scelta tra una decina di pulsantini tondi con didascalia non ha mai
ucciso nessuno...

 c'č un filesystem virtuale che in pratica fa da wrapper a quello ospite.
[...]
non č un filesystem č un semplice wrapper!

 non è un filesystem è un semplice wrapper!
E' un filesystem. Ed ora, per piacere, se vuoi dire qualche altra cosa 
in merito, sei pregato di studiarti i sorgenti di AROS.


in merito, sei pregato di studiarti i sorgenti di AROS.
Si sua Santità! Studierò le sacre scritture dei sistemi operativi!
Non ci sarà altro filesystem che quello di AROS!
Non avrò mai tentazione di usare un case sensitive!
PS.
ma chi ti credi di essere?
*non preoccuparti a rispondere ti ho già messo nel kill*
addio


Ma, guarda, vai a cagare, dal profondo dell'anima... Ma perché tutti i 
coglioni patentate me li devo beccare io, eh? Qualcuno mi dica perché...


 descrivi.
Non posso accettare questo per principio d'autorita'.
Questa e' una soluzione che si e' ritenuto di adottare ma non
vuol dire che sia la migliore in assoluto (a meno che non lo si
dimostri) e che non ce ne siano di alternative.
Volendo accettare l'uso di hash table e tornando all'origine
della nostra discussione, non vedo nulla che impedisca l'uso di
hash table nel caso di file system non case sensitive, basta normalizzare i
nomi dei file prima di calcolarne la chiave.
--
Alessandro Staltari
staltari(a)
geocities.com

 nomi dei file prima di calcolarne la chiave.
Ancora una volta ti ripeto che non era questo in discussione, quello che 
era in discussione è l'uso di un wrapper che renda case insensitive un 
filesystem case sensitive.


quel lato..
Questo non importava che lo dicessi, è sotto la luce del sole.
Quello che non riesco a sentire dalle vostre voci è che nel settore
desktop linux oltre ad essere indietro è anche in competizione
(nonostante la scimmiottazione di windows e i "passi avanti" lo stanno
a dimostrare), perchè nella competizione chi sta dietro perde. 
E' ridicolo come Fonzie che non riusciva a dire "ho sbagliato".

 desktop linux oltre ad essere indietro è anche in competizione
 
Personalmente non lo trovo affatto indietro.

 da provare.
Usa solo il primo CD di FreeBSD. Installa dai ports e non dai
package che trovi negli altri CD.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 un tasto in piu'.
Esempio *molto* falsato, perché prevede che tu sappia
perfettamente se quello che stai cercando inizia con una
maiuscola od una minuscola, cosa che raramente avviene,
costringendoti, di fatto, a più digitazioni che in caso di un
fs case insensitive.


 * PAGARE UN SISTEMISTA *
Me li dai tu i soldi?


 insensitive un filesystem case sensitive.
Non era quello in discussione con Allegrucci, ma era quello su cui io sono
intervenuto. Se ho sbagliato... pardon!
Alessandro.

 perché...
Affinita' elettive?
-- 
                     Davide Inglima - limaCAT
            "Mana is rapidly disappearing from the world"
              "Even the Mana Tree has begun to wither"
 
http://digilander.iol.it/nekochan/

 Affinita' elettive?
Non so. Tu che sembri esperto, che ne dici?


 Alessandro

 un file di cui non ricordo o semplicemente non posso conoscere il case?
Indubbiamente la soluzione userspace e' meno efficiente di quella del kernel
ma nell'uso normale direi che e' accettabile.
Il problema che poni tu esiste, ma e' piu' un problema teorico che reale:
1) In molti casi l'applicazione che vuole aprire il file ne conosce gia' il 
nome, o perche' se lo crea o per altri motivi.
2) Se per sfortuna sei costretto a fare piu' di 2 o 3 tentativi con le 2^n
combinazioni allora il problema e' di chi ha chiamato il file "pipPo.c"
invece di "pippo.c" :)
Unix ti da abbastanza controllo per spararti sui piedi, e' risaputo, ad 
alcuni piace e non hanno grossi problemi, altri invece no.
In altre parole, se e' lecito mischiare minuscole con maiuscole, non vuol 
dire che sia buon stile.
Si potrebbe dire lo stesso del C/C++ e Pascal, per esempio.
Anche li siamo case sensitive vs. case insensitive, ma scommetto che ora
verra' HPL a dirci che il case sensitive del C/C++ e' una cosa buona :)
(sulla quale sarei d'accordo..)
La diatriba sul case risale nella notte dei tempi dell'informatica, se 
siamo ancora qui a discuterne forse vorra' dire che e' proprio una 
questione di gusti personali..
-- 
Lorenzo

 fs case insensitive.
Hai *perfettamente* ragione, quando cerco qualcosa vado
sempre alla cieca.
-- 
Lorenzo

Personalmente non lo trovo affatto indietro.
Si, lo so. Perchè tu ci fai tutto quello che devi fare.
Sfortunatamente quello che tu devi fare non è tutto quello che si può
fare sul desktop, e come lo fai non è detto che non ci sia in
circolazione un modo migliore.
Vuoi un esempio?
Uso una macchina server windows 2000, con oracle 9i e file sharing con
altre macchine windows. Se facessi lo stesso ragionamento, ti direi
che personalmente windows non lo trovo affatto indietro come server.
Non lo dico perchè per fortuna non mi fermo allo stretto punto di
vista personale.


...o che non abbiamo nulla di piu' importante da fare ;-P
Alessandro

 migliore.
 
Infatti ho detto "personalmente".
Ma non vedo perchè a questo punto dovrei dire che è indietro, non ti
pare?

pare?
Tu *non* *devi* dire che è indietro. Dovresti solo evitare di essere
palesemente soggettivo quando confuti una valutazione oggettiva.
Altrimenti viene fuori che la panda non è inferiore alla ferrari
perchè a qualcuno basta la panda, e che il due non è inferiore al tre
perchè a qualcuno basta il due... <g>

 questione di gusti personali..
Diciamo che è una questione di abitudine...


 non sarei limitato?
Mai detto questo, sei tu che vuoi scrivere
minuscolo.
bye,
-- 
piergiorgio

>>>     Mi pare siano un tantinello parassitarie.
La SuSE contribuisce allo sviluppo di molto sw per linux (kernel,
ReiserFS, ALSA...). Redhat porta avanti l'ext3. Mdk ha acquistato
Bochs e lo ha rilasciato opensource. Per te sono dei parassiti?
Henryx

 Bochs e lo ha rilasciato opensource. Per te sono dei parassiti?
Non nega il punto 5), che parla di "molte" distro, non di "tutte" le distro.
Tutto sommato, credo che ti stai rivolgendo all'interlocutore sbagliato.
Saluti.

 Me li dai tu i soldi?
E perche` mai?  Non ho capito cosa  c'e` di scandaloso in  quello che ho
detto. Quando si rompe la macchina,  si paga un meccanico che la rimetta
a posto.
Che differenza c'e` in questo caso? Nessuna direi.
-- 
GHERdO, happy GNU/linux user.
"E sempre allegri bisogna stare...
	... che il nostro piangere fa male al RE!"

di utilizzare linux in campo desktop e` un altro discorso
Nessuno l'avrà detto, però lo fanno. 
Lo negherai, perchè anche tu sei fra quelli che non lo dicono.

 Non so. Tu che sembri esperto, che ne dici?
Esperto? Suvvia, non esageriamo... lo sai che in realta' basta 
solamente postare qui per attirarsele certe cose O:)


 
Non è detto: potrei ribattere dicendo che _quel_ modello di sviluppo
probabilmente ha complessivamente _più_ risorse complessive, e quindi
rende meglio. 
-- 
Renato "Hitman" Salzano  /  
http://spazioweb.inwind.it/hitman
ICQ #75729987 / IHGGer #778 / NapolICErs #2 / Druido della BUBBLE
"Sull'altare dei miei sogni hai bruciato un sogno in più / se ripenso
 che la nostra storia l'hai voluta tu / dovevo dirti di no"(V.Giovagnini)

 
La *non* distinzione può esserlo. 
Vedi l'esempio (ben portato) dell'uso del maiuscolo nella lingua
tedesca.
E non dire che i tedeschi non contano, dimostrersi solo di essere un
idiota.



Allora tutto il mondo del software e' caotico.
Anche, e forse soprattutto, per quanto riguarda i prodotti commerciali, solo
che in quel caso la gente parla di libero mercato e concorrenza.
Tu probabilmente ti aspetteresti che chi sviluppa su Linux debba
necessariamente unire i propri sforzi con gli altri per "la causa comune",
ma spesso la causa comune non e' Linux ma qualche cos'altro tant'e' vero che
molti dei progetti sviluppati per Linux non hanno Linux come unico target
(pensa a Samba, il compilatore GNU, mozilla, OpenOffice.org, ma anche alcuni
driver di periferica).
Alessandro

 Sě, lo č, ed č causa di numerosi problemi.
Guarda, devono ancora dirmi il perche` di cio`...
Comunque, visto che si parlava anche di
ergonomicita` e del fatto che ci si ricorda
il nome, ma non come e` scritto, vorrei
fare un po' di considerazioni.
Se ho un build tree, con decine di dir e
centinaia, se non migliaia, di file, non
solo non ricordo il "case", ma non ricordo
neanche i nomi dei file.
Non ricordo se il driver USB si chiama
"usb-driver.c", "driver-usb.c", "usb.c",
"USB.c", "uhci-usb.c", "usb-ohci.c", etc.
Per trovarlo devo per prima cosa aver organizzato
il tree in maniera decente, con una dir "driver"
e magari un sub-dir "usb" (ma potrebbe non essere
cosi` semplice, dato che "usb-storage.c" potrebbe
stare in driver/scsi). Poi usero` un po' di tool,
tipo "find", "grep", etc. per trovare il file.
Questo avviene, forse anche piu` comodamente, su
NT (ed immagino con tutta la famiglia), dove il
"find" consente di cercare per nome e per contenuto.
Come dice il buon Lorenzo, sono i tool in user
space che devono occuparsi di fornire tutto il
necessario per trovare le informazioni nel FS,
questo deve semplicemente fornire la massima
flessibilita` e potenza.
Tempo fa vidi un esempio di shell per Unix che
si preoccupava, usando anche algoritmi euristici,
di proporre il/i comandi piu` probabili nel caso
l'utente non avesse scritto il nome correttamente.
Questo va oltre il discorso case sensitive/insensitive,
e` un discorso di interfaccia utente, spesso discusso
anche qui.
Che viene risolto in user space, come meglio
si crede, per soddisfare le necessita` del caso.
Immagino, tra l'altro, che un utente normale
non debba neanche sapere che c'e` un FS, deve
solo sapere come realizzare la persistenza dei
dati. Quindi la (G)UI deve occuparsi di fornire
tutto il necessario per gestire la cosa, con
tutti i tool (integrati o meno) del caso.
Il "power user" non ha problemi in nessun caso.
bye,
-- 
piergiorgio

rende meglio. 
Beh, immagino che non volevi usare esattamente il verbo "rendere", in
questo contesto a parità di risultato se hai più risorse il rendimento
è peggiore, non migliore.
Però credo di aver capito, probabilmente intendevi dire che più
risorse ottengono un risultato maggiore e in minor tempo. 
Questo non è vero, è dimostrato il contrario. Cioè, se per un progetto
servono cinque persone, il miglior risultato lo ottieni con cinque
persone e non con sei, sette o risorse infinite. Questo tanto nel
closed che nell'open source. 

 Me li dai tu i soldi?
Perche', pensi di non averne bisogno in ogni caso?


 Perche', pensi di non averne bisogno in ogni caso?
Sarà, ma i 4 PC che ho a casa funzionano tutti alla
perfezione, e non ho mai chiamato un sistemista (ed io
*non* sono certo un sistemista, anzi...)



Premetto che a me il file system case sensitive sta piu' che bene, ma non
insisterei su questo punto per giustificarne l'uso.
Se si sa a priori che il file system non e' case sensitive, si sa che quella
parola puo' avere diversi significati a seconda della grafia originale, (se
la parola e' scritta tutta in maiuscolo il dubbio sarebbe piu' che legittimo
no?).
Inoltre pur accontentando i tedeschi i cinesi probabilmente avrebbero
comunque qualcosa da recriminare.
Il nome di un file serve fondamentalmente per distinguerlo dagli altri, se
possibile deve essere facile da ricordare ma non deve necessariamente
descriverne esattamenete il contenuto.
Piu' che la correttezza grammaticale e' importante avere la possibilita' di
definire delle convenzioni ragionevoli per dare un nome ai file e poter
disporre di piu' caratteri puo' essere un vantaggio.
D'altronde il voler essere troppo aderenti alla lingua naturale puo'
comportare dei problemi, pensiamo alle difficolta' derivanti all'uso di nomi
dei file con spazi nelle shell, oppure dall'uso di caratteri non facilemente
digitabili da tastiera.
Alessandro


E che ci fai qui allora? ;-P
Alessandro.

 Il "power user" non ha problemi in nessun caso.
Questo non è affatto vero. Ti pare di trovarti al meglio
perché hai solo quel modo di funzionamento.


 Che differenza c'e` in questo caso? Nessuna direi.
Moltissima, invece. Ma è un discorso trito e ritrito e non ho
voglia di ricominciare da capo.


 sempre alla cieca.
Non riesco a comprendere il senso della risposta, comunque...


 sviluppo applicazioni, ecc...) dovrebbe essere C-I.
Ma anche limitare il FS e` sbagliato,
e direi anche di piu`.
bye,
-- 
piergiorgio

 *non* sono certo un sistemista, anzi...)
Umm... Mi pareva che Gothmog parlasse di lavoro (sottintendendo:
realta' aziendale) e GHERdO gli avesse risposto nel contesto :)
Ovvio che se a casa tua hai quattro pc e girano piu' che bene per
l'uso chei vuoi fare bla bla bla...



Credo che H.P.L. si riferisse al linguaggio parlato.
Purtroppo attualmente noi comunichiamo con i computer
ancora attraverso la scrittura, e non usiamo neanche
il linguaggio naturale, ma solo linguaggi artificiali.
L'uso di maiuscole nei nomi di file e' raramente fatto
per rispettare le regole grammaticali, ma spesso per
altre esigenze.
Per esempio i file README hanno nome maiuscolo per
sottolinearne l'importanza e attirare l'attenzione
dell'utente (i file con le maiuscole spesso precedono
quelli con le minuscole quando vengono elencati a causa
del valore ASCII dei caratteri).
L'importante e' assumere delle convenzioni ragionevoli
nella denominazione dei file in modo che  non sia necessario
doverne ricordare a memoria la grafia esatta.
Capire questo non credo che sia la principale difficolta'
che un utente alle prime armi possa incontrare.
Alessandro

 e direi anche di piu`.
Come ho detto il fs può fare quello che vuole, quello che
conta è che il modo di interazione con l'utente sia C-I.


 risposto nel contesto :)
Sinceramente mi pare che la critica a linux non sia mai stata
riferita all'ambito lavorativo, ma che fosse generale.


 conta è che il modo di interazione con l'utente sia C-I.
Uhm, io direi che quello che conta e`
che l'interazione con l'utenti sia come
la vuole l'utente.
E non e` una questione di CS/CI, ripeto,
ma ben piu` complessa.
Comunque noi si parlava di FS, non di UI.
bye,
-- 
piergiorgio


Seguendo lo stesso ragionamento potrei argomentare che non e' intuitivo che
possano esistere due file pippo.txt distinti in uno stesso sistema (magari
in posizioni diverse).
(in questo senso Windows a volte e' umano e ci impedisce di cancellare un
file perche' c'e' un suo omonimo che risulta in uso :-)
Alessandro.

 diverse).
No, questo è ben diverso. Per quale motivo si dovrebbe poter
distinguere fra pippo.txt e Pippo.txt? Non ha senso nel
linguaggio umano e non deve (perché l'utilizzo sia intuitivo)
averne nell'interazione con il computer (il fs -o quello che
ci sta sopra- in questo caso).


 Comunque noi si parlava di FS, non di UI.
Si parlava di fs, ma ci si riferiva al suo interfacciarsi con
l'utente, quindi...



Hai dei link al riguardo?
Alessandro


"Google is your friend" :)
A parte gli scherzi, cerca con google anche negli archivi di questo NG: 
se ne è già parlato. Cerca anche negli archivi di it.comp.os.amiga. E 
non dimenticare di cercare nel web :)
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 problema tecnico, non di interfaccia.
Fai un rm di qualche file installato con rpm e poi dimmi se funziona 
bene ancora.

 uno possa immaginare...
Hei, non mi pare il caso di farcene una discussione. Ho citato questa 
storia del filesystem non case sensitive solo per chiarire che su OSX 
certe cose potrebbero essere differenti. Ho omesso di dire che le 
differenze piu' importanti tra HFS+ e UFS sono altre.

 Cazzate, stavi parlando di Linux quindi che c'entra?
Nel senso che mi sono preso un mac appunto per evitare una serie di cose.


Si ci avevo provato ma solo per AmigaDE e non avevo trovato riferimenti alla
persistenza ortogonale. Adesso sui newsgroup ho trovato.
Alessandro

In un messaggio del Mon, 20 May 2002 15:49:03 +0200 Gothmog scriveva:


Allora deciditi, vuoi fare un discorso applicato solo a te stesso oppure
per l'utonto in generale? Poi quando avrai deciso comunicamelo !
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 per l'utonto in generale? Poi quando avrai deciso comunicamelo!
Non l'ho ancora capito!
A Thorin e a tutti gli altri: a quando pizza e birra?

 A Thorin e a tutti gli altri: a quando pizza e birra?
Io veramente vorrei organizzare una pizzata ma ancora non so per
quando..


 Non riesco a comprendere il senso della risposta, comunque...
Era una risposta sarcastica :)
-- 
Lorenzo

 Diciamo che è una questione di abitudine...
 
Suvvia, il mondo e' pieno di OS case insensitive, non facciamo le vittime :)
-- 
Lorenzo

 ...o che non abbiamo nulla di piu' importante da fare ;-P
Questo e' sott'inteso :)
-- 
Lorenzo

 un certo lavoro senza complicarti la vita.
-- 
GHERdO, happy GNU/linux user.
"E sempre allegri bisogna stare...
	... che il nostro piangere fa male al RE!"

 Si chiamano "personal computer" per qualche ragione, direi.



Complimenti. Sei anche razzista, che pensi che i tedeschi siano meno
"uomini" di noi?
O qualunque popolo che abbia la distinzione maiuscole/minuscole nella
propria lingua?
E a questo punto, che ne pensi di quelli che l'alfabeto latino non lo
usano proprio? 
Ma vaffanculo, va... 
-- 
Renato "Hitman" Salzano  /  
http://spazioweb.inwind.it/hitman
ICQ #75729987 / IHGGer #778 / NapolICErs #2 / Druido della BUBBLE
"Sull'altare dei miei sogni hai bruciato un sogno in più / se ripenso
 che la nostra storia l'hai voluta tu / dovevo dirti di no"(V.Giovagnini)


Che cazzo ne sai te, che hai ampiamente dimostrato di non saperne di
queste cose, se per qualcuno quella distinzione abbia senso?
Hint: per qualcuno quella distinzione _HA_ senso. Per cui togliere le
maiuscole/minuscole significherebbe emarginare utenti.
Fine del discorso. 


 
Se Bunderslaughten e bunderslaughten sono parole diverse in tedesco (ho
preso due parole a caso, eh!) basta questo per rendere una cazzata
l'idea di togliere la distinzione maiuscolo/minuscolo dal FS.
Ma credo sia inutile fartelo capire: sarebbe come parlare con il muro.



Non regge neanche: in tal caso ci sono mancanze ben peggiori negli
attuali FS: ad esempio non si ci sono simpoli per esprimere
adeguatamente il tono o gli accenti delle parole.
Hint: usare maiuscole/minuscole nella scrittura non è una cosa fatta a
caso. 


 
Infatti la rappresentazione del nome del file _DEVE_ essere una cosa
ben separata dal significato del nome del file per il FS.
E quest'ultima deve essere più ampia possibile, comprendendo più
possibilità possibili (e non meno, come qualche stolto continua a
proporre).


 
Sicuro? Il successo dell'OpenSource forse dovrebbe far ridiscutere
questo principio. Forse, visti gli strumenti ormai a disposizione, e la
possibilità di comunicazioni rapide e veloci da ogni parte del mondo,
questo principio non è pìù vero.
E cmq volevo anche dire che essendoci in _complessivo_ più risorse,
queste possono "distribuirsi" su un numero di progetti maggiore, ognuno
facente meno funzioni, ma che si integrano fra loro in maniera da
ottenere un sistema di maggior funzionalità.
(com'era? "Divide et impera" se ben ricordo)


 Era una risposta sarcastica :)
L'avevo capito, ma il sarcasmo potrebbe avere più significati
in quella risposta...


 "freeBSD unleashed".
Dai uno sguardo su 
www.gufi.org
.


 l'unica possibile.
readme e readme.testo per esempio, ma anche readme_testo, o
readme-testo, ecc...
Con quale criterio (intuitivo) potresti stabilire che il
readme maiuscolo debba contenere il testo e quello minuscolo
(o viceversa) visualizzarlo?


 (com'era? "Divide et impera" se ben ricordo)
Nessuno Impera nell'open source, si divide e *forse* ognuno fa il compitino
che deve fare. Ma non e' detto che poi vada a finire cosi'.
Saluti.

 come aggettivo, per esempio "Il buon Samaritano".
E allora? Preservare maiuscole e minuscole è consigliabile, anche in
nome dell'ortografia, ma non strettamente vitale. Si tratta di un
artificio legato alla scrittura; per il cervello è una categoria
secondaria ed acquisita, di non facile memorizzazione. Per migliaia di
anni se n'è tranquillamente fatto a meno. Le lingue naturali sono
comunque ambigue - anche senza badare alle lettere: in italiano 'cane'
e 'cane' sono cose diverse - e fanno ricorso all'intuito degli
interlocutori per ricostruire il significato dal contesto.
Il tuo è un altro esempio forzato che tiene conto di una casisitica
ristretta: va bene, usi "Buono" e "buono" come nomi per i tuoi due
file. Ora però hai bisogno di altri due file, per "Buono per la Mensa"
e "Il buon Predicatore", come li chiami? Buon e buo? [dillo ad un
toscano] Non hai risolto granché.
Distinguere tra maiuscole e minuscole è una deformazione professionale
(mentale?) tipica di chi lavora troppo al computer - o scrive
programmi. È un sintomo (preoccupante?) di alienazione, di perdita di
contatto dalla realtà: il resto del mondo funziona diversamente. Gli
esseri umani non funzionano come un computer, men che meno un
computer programmato da gente incapace o pigra (nei fatti o
intellettualmente). Perché abbassarsi al livello di una macchina? Non
ha senso. Capirei se costruissimo macchine ad uso e consumo di altre
macchine, ma per il momento non mi pare sia questo il caso.
Se qualcuno ti desse un bigliettino con la scritta "Buste paga",
chiedendoti di cercare la cartella con tale nome e tu ti azzardassi a
dire che non c'è, perché c'è solo quella "Buste Paga", l'altra persona
ti darebbe dell'ingegnIere, del mentecatto o tutt'e due. Avrebbe pure
ragione.
-- 
 "Perfection is attained not when there is no longer anything to add,
 but when there is no longer anything to take away" (A de Saint-Exupery)
 Rudi Chiarito                                            
ru...@amiga.com


No, invece. Perchè nessuno impone a  nessuno di lavorare su un progetto.
Se  qualcuno  ci lavora,  è  implicito  che  la  condizione "fa  il  suo
compitino" sia assolta.
In pratica l'OS è bottom-up e  non top-down, ma nessuno dei due approcci
porta in pratica vantaggi uno sull'altro.


 ...e che il due non è inferiore al tre perchè a qualcuno basta il due... 
Beh, con due sufficientemente grande...
Marco

In preda a raptus test ha osato scrivere...

Cerca qualcosa relativamente a Keykos, oppcos, EROS e Grasshopper per
cominciare. Poi in it.comp.os.amiga ci fu una discussione qualche mese
fa (a dirla tutta proprio a partire da una discussione con Rudi Chiarito
ho iniziato a documentarmi in modo piu' approfondito sull'argomento e
adesso qui in azienda stiamo facendo alcune considerazioni se aprire
un branch di implementazion sperimentale per uno dei nostri sistemi).
Marco

 Suvvia, il mondo e' pieno di OS case insensitive, non facciamo le vittime :)
E chi fa la vittima?
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 cosa fatta a caso.
E' vero sia nella lingua scritta che nella denominazione dei file, ma spesso
il criterio non e' lo stesso.
Alessandro.

 continua a proporre).
Si ma se mi trovassi a dover digitare il nome di un file costituito da
ideogrammi non mi sentirei molto a mio agio.
Alessandro.


Solitamente in unix i comandi sono minuscoli, mentre mettere un file col
nome maiuscolo sicuramente attira l'attenzione di chi legge la lista dei
files.
Nel tuo esempio hai mostrato un'altra fonte di ambiguita' nella
denominazione dei file, quello dell'uso o meno di separatori come '-', '_',
'.' o ' ' (che non sono emoticons:-).
Alessandro.

 emoticons:-).
Perché ambiguità?


 Ma vaffanculo, va... 
ORATOR FIT, POETA NASCITUR!



Intendo dire che se anche elimini il dubbio README vs. readme o varianti ti
scontri ancora con  readme.testo vs. readme_testo o varianti.
Cioe' in assenza di convenzioni c'e' sempre modo di far confusione, non e'
solo questione di maiuscole/minuscole.
Alessandro.

Beh, con due sufficientemente grande...
Mi spiace, ma due è minore di tre. 


Marco, l'altro Marco faceva una battuta :)


 di maiuscole/minuscole.
No, no, un momento. Tra nomi significativi le ambiguità
possibili sono decisamente ridotte. Fra README e readme *non*
c'è *alcuna* differenza che possa essere intuita o compresa se
non stabilita ed imparata a priori.


 ORATOR FIT, POETA NASCITUR!
LOL :) Rudi, tu devi postare di più! :)



Tra readme-testo e readme_testo invece la differenza e' lampante !
;-P
Alessandro.

 ragione.
Dipende, in Germania potresti sbagliare
a non fare la distinzione.
In Giappone faresti molto meglio a farla.
bye,
-- 
  Piergiorgio Sartor

 l'utente, quindi...
Non vorrei sembrare un po' controcorrente,
ma direi che, in caso di problemi ergonomici,
il FS *non* dovrebbe mai interfacciarsi con
l'utente, dovrebbe sempre esserci qualcosa
di altro in mezzo.
bye,
-- 
  Piergiorgio Sartor

 NESSUNA LINGUA DISTINGUE TRA MAIUSCOLE E MINUSCOLE. SOLO L'ORTOGRAFIA
Ma il namespace del FS e` *ortografia*, non
e` lingua parlata, per ora almeno, quando
lo sara`, nel ridiscuteremo.
bye,
-- 
  Piergiorgio Sartor

 storia del filesystem non case sensitive solo per chiarire che su OSX
Ma era un buon aggancio per un flame ;-)
bye,
-- 
  Piergiorgio Sartor

 NON C'È BISOGNO DI SCOMODARE I TEDESCHI, IN ITALIANO "Lecco" E "lecco"
[...]
Perche' gridi?
<g>
-- 
il Vide - ICQ# 5301833
Togli OE per rispondermi
IAMM - it.arti.musica.metal 
IAMMol webzine: 
http://www.iammol.com

                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  
E mbhe? Un personal computer non puo' essere usato per lavoro?

 PER "Rudi" E "rudi". IL CHE NON DIMOSTRA GRANCHÉ: NELLA LINGUA PARLATA
Chiunque sia stato gli levi quelle due dita dal gufo cosi' la smette
di gridare..
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 E mbhe? Un personal computer non puo' essere usato per lavoro?
Certo. 
-- 
GHERdO, happy GNU/linux user.
"E sempre allegri bisogna stare...
	... che il nostro piangere fa male al RE!"

 bene ancora.
No, questo non vale.
Io intendo mandare in palla rpm usando rpm.
Chiaro che se cancello file a caso, i risultati
possono essere non prevedibili, in tutti i
casi, non solo per rpm.
bye,
-- 
  Piergiorgio Sartor

 di gridare..
Come al solito Thorin non capisce una mazza... :D



Probabilmente un giapponese, un cinese o un koreano invece si
sentirebbero a proprio agio.
bye
Gianluca
-- 
We are the opensource. Existence as you know it is over. We will add
your proprietary features and technological distinctiveness to own
opensource project. Resistence is futile. Windows is closed.

 
E'  orrendo come  stile,  ma  essendo italiano  come  te  non ho  avuto.
problemi. Dubito un cinese, o un tedesco avrebbero capito qualcosa.
Ovvero: stai  facendo un confronto che  non c'entra un kaizer,  e dubito
che lo capirai.
-- 
Renato "Hitman" Salzano  /  
http://spazioweb.inwind.it/hitman
ICQ #75729987 / IHGGer #778 / NapolICErs #2 / Druido della BUBBLE
"Sull'altare dei miei sogni hai bruciato un sogno in più / se ripenso
 che la nostra storia l'hai voluta tu / dovevo dirti di no"(V.Giovagnini)


Tu  non devi  digitare  ideogrammi, se  non setti  una  shell in  lingua
cinese/giapponese o altra lingua che li usa.
Ma il FS deve prevedere anche quella possibilità, e ridurne i codici è
una sciocchezza a priori proprio per questo.



Se un orientale mi manda un file cosa dovrebbe accadere?
Il sistema doverebbe traslitterare gli ideogrammi? Non credo che ci sia
una corrispondenza uno a uno con le lettere.
A questo  punto potrebbe occuparsi anche della traduzione allora :-)
Alessandro


Anche io comincio ad disperare di poter capire...
Alessandro.

 ragione.
Mi viene anche in mente un'altra cosa:
e se ti chiedessero (a voce) la pratica
"de filippi" e tu trovassi "de Filippi"
e "De Filippi", chiederesti spiegazioni?
bye,
-- 
  Piergiorgio Sartor

 Cioe' le maiuscole cambiano il tono?
Sì, perché, non lo sapevi? LOL :))



Chiedo scusa, ma a me 'sta cosa del "de" minuscolo e maiuscolo mi giunge 
completamente nuova. Puoi farmi un esempio reale? Il nome di qualcuno?


 che lo capirai.
A me sembra sia tu quello tra noi due che abbia scarsa conoscenza
delle lingue, della scrittura e della loro storia.


 casi, non solo per rpm.
Tuttavia, se l'utente puo' facilmente accedere a tutte le informazioni 
necessarie per la manutenzione del sistema (cosi' come il sistema le 
offre), avrebbe piu' possibilita' di rendersi conto della pericolosita' 
di una certa azione. Insomma, mi pare un problema la coesistenza di 
operazioni macroscopiche come rpm e di quelle microscopiche come mv, rm 
e cosi' via.

 lo sara`, nel ridiscuteremo.
Dillo ad un non vedente che si fa aiutare da un sintetizzatore vocale
per usare il suo computer. Non si tratta di una novità e ormai da un
bel pezzo.


 e cosi' via.
Non necessariemente, dato che rpm ha anche una interfaccia
grafica, con gnome, credo.
bye,
-- 
  Piergiorgio Sartor

 completamente nuova. Puoi farmi un esempio reale? Il nome di qualcuno?
Il "de" e` nobiliare, il "De" e` "plebeo" :-),
l'esempio "de Filippi" e "De Filippi" e`
perfettamente valido.
Tra l'altro, giusto per pettegolezzo, vi sono
persono che hanno cambiato, all'anagrafe, il
"De" in "de"... :-)
bye,
-- 
  Piergiorgio Sartor


Sarà, ma esiste un "de Filippi" *e* un "De Filippi"?


 bel pezzo.
Cosa dovrei dirgli? Che il FS e` scritto e
lui lo sta sottoutilizzando?
Prova a dirgli di risolvere un'equazione od
un integrale, al non vedente.
Oppure di tracciare una tangente di una funzione.
Ci sono problemi enormi di "interfacciamento",
in questi casi, problemi che limitano fortemente
l'accesso, per esempio, alle facolta` scientifiche,
dove non "vedere" funzioni, equazioni rende la
vita difficilissima, se non impossibile.
Non venirmi a raccontare queste storie, che
non c'entrano nulla con la questione se il
FS (ed il FS, non la UI) debba essere CS o CI.
bye,
-- 
  Piergiorgio Sartor

 FS (ed il FS, non la UI) debba essere CS o CI.
Avresti perfettamente ragione se il filesystem fosse totalmente
invisibile all'utente (come, nel 99% delle volte, gli inode). In tal
caso, non solo non dovresti preoccuparti di maiuscole e minuscole, ma
potresti pure fare uso di caratteri non stampabili, come si fa coi 32
bit di un indirizzo IPv4 e i 128 di un indirizzo IPv6 o di un UID.
Nella realtà il filesystem è visibile e come all'utente, con tutti
i problemi che ne derivano.


 che lo capirai.
Mi metto nel (presumibilmente) lungo elenco di quelli che non hanno capito.
Marco.
P.S. Parlando di poesia: perchè i poeti mettono le maiuscole dove meglio
preferiscono e nessuno s'offende per le regole distrutte? Eppure proprio
i poeti, a volte, colgono il senso più profondo delle cose al di là delle
maiuscole, delle regole e del tono.


Non mi sembra un problema irrisolvibile pero' :-)
Alessandro.

 lampante ! ;-P
No, no, no. Evidentemente non mi sono spiegato. La differenza
non è nel carattere di separazione ("-", "_", ".", ecc...), ma
in quello che scrivi *dopo* il carattere.
readme-testo indicherà il file che contiene il testo e README
il file che visualizza il testo.
Come vedi utilizzi le maiuscole per attirare l'attenzione, ma
la distinzione la fai nel nome, non utilizzando maiscole
minuscole.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 cosi` in basso come nel FS.
Sinceramente, se non mi sbaglio, qualcuno in questo NG (Juliet
forse) aveva scritto che il fs di Windows (credo solo NTFS)
*è* CS. Eppure tu non te ne accorgi. In Unix le cose sono ben
diverse.



Ah, certo:
Testo:          "ReAdMe"
Sintetizzatore: "R maiuscola, e minuscola, A maiuscola, d minuscola, M
                  maiuscola, e minuscola"
Utente:         "E che cavolo, dillo che è 'reame', no?!"


 No, no, no. Evidentemente non mi sono spiegato.
Quello l'avevo capito, ma la mia obiezione era che pur usando un file sistem
non case sensitive i problemi che vorresti risolvere rimangono per i
separatori, cioe' devo comunque ricordarmi se il file si chiamava
readme-testo o readme_testo.
Alessandro


Questa e' *una* delle soluzioni.
Alessandro.


Altra soluzione:
Testo:          "ReAdMe"
Sintetizzatore: "readme"
Utente:         <capisce 'readme'>
Sintetizzatore: "Aspe', dove corri... In ordine di apparizione: R
                  maiuscola, e minuscola, A maiuscola, d minuscola, M 
                  maiuscola, e minuscola".
Utente:         "E che c%&$ me ne frega?!"


 diverse.
Beh, questo non fa altro che confermare
cio` che scrivo, no? :-)
bye,
-- 
piergiorgio

 readme_testo.
Questo è un altro discorso (ed un altro problema).
Il fatto è che anche se visualizzo il contenuto di una
directory (per cui i nomi li ho sotto il naso), trovarmi
davanti README e readme non mi da alcuna indicazione sul
significato dei file, mentre il "-testo" o "_testo" sì. Nulla
ti vieta di chiamare i tue file con nomi diversi anche in caso
di fs CS (cosa che andrebbe comunque fatta), ma un fs CI (od
un'interfaccia al fs CI) ti *impedisce* di chiamare due file
con lo stesso nome, evitandoti successiva confisione.


Altra soluzione:
[snip :-) ]
Oppure una shell dedicata che si occupi di diambiguare i nomi in caso
possano risultare ambigui. In caso file "omonimi" fa lo spelling, negli
altri casi no. E' scandaloso?
Del resto oggi ho scaricato un file che si chiama IBM-Java2-JDK-131.tgz come
viene letto da un sintetizzatore questo?
Alessandro.

 invisibile all'utente (come, nel 99% delle volte, gli inode). In tal
Questo e` quello che dovrebbe essere,
alla fine.
Il device driver e` invisibili, non si
capisce perche`, al giorno d'oggi, non
debba anche esserlo il FS, ed astrarre
i concetti di fili, o metafile a questo
punto, ad un livello superiore.
bye,
-- 
piergiorgio

 In Giappone faresti molto meglio a farla.
In Giappone? Non hanno nemmeno il concetto di maiuscole e minuscole.
In compenso sanno bene cosa siano gli omofoni.


 cio` che scrivo, no? :-)
Conferma piů quello che dico io, cioč che l'approccio CI deve
essere su tutti i fronti (ed in Unix non č cosě), tanto da far
ritenere CI il fs.


 Questo è un altro discorso (ed un altro problema).
Allora non ho capito *quale* e' il problema.
Riassunto delle puntate precedenti:
Io avevo capito che il problema fosse che il file system case sensitive
permette di scrivere lo stesso nome in modi diversi senza identificarli.
La soluzione suggerita sembrava che fosse quella di passare ad un file
system non case sensitive.
Dal controesempio con '-' e '_' sembrerebbe che la soluzione non sia
risolutiva (e' ancora possibile fare confusione).
Per te puo' essere comunque una soluzione valida (hai dimostrato l'utilita'
di un file system non case sensitive) per me non lo e' perche' ci sono
ancora dei casi nei quali si presenta il problema che si voleva risolvere.
Alessandro.

 DEFILI~2
Certo che devi usare altri artifici. Mai stato in una classe con due
studenti con lo stesso nome e cognome? Il tuo filesystem non sarebbe
di alcun aiuto. Faresti come gli altri hanno sempre fatto: aggiungi
altra informazione, ad es. scrivendo nel registro (o chiamando i tuoi
file) "Mario Rossi in Luigi" e "Mario Rossi in Giuseppe". Chiunque
proponga distinzioni basate su maiuscole e minuscole ha evidentemente
passato troppo tempo di fronte al computer ed è solo in cerca di guai.


 In compenso sanno bene cosa siano gli omofoni.
Non era quello il senso...
Prova a chiedere qualcosa ad un giapponese
e vedi cosa succede...
bye,
-- 
piergiorgio

 ritenere CI il fs.
...che pero` e` CS...
bye,
-- 
piergiorgio

 una sciocchezza a priori proprio per questo.
finalmente una cosa sensata sulla diatriba case o noncase
concordo!
chi ha tirato fuori discorsi sulla complessita sbandierando con arroganza
un wrapper!
chi dice di ricordare a memoria i nomi di tutti i file nell'harddisk...
...certe discussioni servono più che altro a selezione chi deve
andare nella kill-list

 Certo che devi usare altri artifici. Mai stato in una classe con due
Appunto, non e` scopo del FS implementare
questi artifici, o no?
Il CI e` uno di questi.
bye,
-- 
piergiorgio

 maiuscola?".
Lavori troppo col computer. :) Nella vita reale il problema in casi
del genere viene risolto alla radice scrivendo il nome oltre che il
cognome. O semplicemente assegnando un numero progressivo ad ogni
cliente. Conosco più di un ragioniere che usa sovente numeri per
riferirsi ai clienti (e spesso ne ricorda una buona parte a memoria).



In questi casi si può usare il set più ampio possibile, e arrivare ad un
1-1, credo (UTF?).
Altrimenti si mappa quello che si può, e si fa uscire alla meglio il
resto.
Ma il concetto base non cambia. 
Più importante: se _tu_ mandi un file ad un orientale, lui potrebbe
vederlo con gli i kanji giusti, magari (se esistono kanji corrispondenti
alle nostre lettere).
-- 
Renato "Hitman" Salzano  /  
http://spazioweb.inwind.it/hitman
ICQ #75729987 / IHGGer #778 / NapolICErs #2 / Druido della BUBBLE
"Sull'altare dei miei sogni hai bruciato un sogno in più / se ripenso
 che la nostra storia l'hai voluta tu / dovevo dirti di no"(V.Giovagnini)


CVD. 


 
Se avesse  usato maiuscole _e_  minuscole, un tedesco non  avrebbe avuto
problemi.


 viene letto da un sintetizzatore questo?
non so, ma di certo non fa distinzione tra minuscole e maiuscole.



Ecco, appunto, si fa quel che si puo'.
Alessandro.


Mi dispiace solo di non avere un tedesco a portata di video.
Alessandro.

 risolvere.
No, il problema è diverso, perché come ho scritto sopra non
c'è modo di impedirti di dare nomi insignificanti ai file, e
questo problema non sarà mai risolto. Ma ne risolvi una buona
parte.



ERROR 404
File ibiemme-giava2-jdicappa-131.tiggizeta not found on this server.
Alessandro


Ho visto il risultato di operazioni simili (mi ostino a non voler scaricare
il supporto per le lingue orientali ne  mio browser :-)
Mi sa che mi conviene studiare il giapponese...
Alessandro

 ...che pero` e` CS...
Mi spiego meglio. Per avere un sistema intuitivo non č
importante che il fs sia CI, ma che lo siano le sue interfacce
verso l'utente.
Poter dare a due file lo stesso nome, distinguendoli solo per
il case, significa che una qualche interfaccia *non* č CI. E
questo porta ad un sistema *non* intuitivo da utilizzare.


 (e spesso ne ricorda una buona parte a memoria).
Certo, è chiaro. Era un esempio su misura per quello che
diceva Piergiorgio.
Infatti scrivendo il nome (ed/od eventualmente qualche altra
informazione) diventa del tutto superfluo un fs CS.


 File ibiemme-giava2-jdicappa-131.tiggizeta not found on this server.
Ma di che cavolo stai parlando?
Fabio Alemagna

 togliere possibilità utili all'utente? 
Utili a cosa?


 problemi.
Balla cosmica. Parlo tutti i giorni con tedeschi che scrivono in
inglese e tedesco usando perfino solo minuscole. Sei l'unico al mondo
convinto che senza le maiuscole ai nomi un tedesco avrebbe problemi.
Haarsträubende Dinge!


 sintetizzatore glieli pronuncia alla stessa identica maniera.
 
Se me lo dicevi qualche mese fa ti facevo rispondere da un programmatore
non vedente di cui ho seguito un breve corso. E che io sappia i linguaggi
di programmazione SONO case sensitive.
(io non stavo molto attento al suo sintetizzatore vocale, ma visto che i
nomi li leggeva lettera per lettera bastava che usasse un tono diverso,
per farti un esempio:
ERRE e a di emme e
erre a a di emme e)
E se uno è in grado di scrivere codice con un sistema del genere
significa che può anche distinguere tra maiuscole e minuscole.
See you,
        Silver Drake
E Dio disse: "Fiat Tux"... e vide che era cOSa buona.
http://www.iammol.com


Niente, facevo lo spiritoso, lascia stare...
Alessandro.

 Sarà, ma esiste un "de Filippi" *e* un "De Filippi"?
Con "Filippi" non saprei, pero` ho conosciuto
un "de Giorgi" ed un "De Giorgi".
Il problema, pero`, potrebbe essere di natura
un pelo diversa, ad es. due file:
sarto.doc
sartor.doc
sartori.doc
sartore.doc
In una dir si possono facilmente confondere,
quindi o leggo attentamente il contenuto, o
trovo qualche altro mezzo per aumentare
l'informazione che mi serve per decidere.
Il problema, se non si fosse capito, e` che
non tutti i file del mio HD, anzi assai pochi
a pensarci bene, sono generati da me.
Il *controllo* sui nomi e` molto parziale e
limitato, alla fine.
Tornando al "readme", si puo` trovare:
readme
readme.txt
readme.doc
read.me
leggimi
lesenmich
Quindi io *non* come il file si chiama, non e`
che lo so a meno del case.
Quindi *devo* avere altri tool per trovare quello
che mi interessa, ed a questo punto, cioe` avendo
questi tool, il CI puo` essere implementato in
essi ed anche molto di piu`, alla fine.
bye,
-- 
  Piergiorgio Sartor

 riferirsi ai clienti (e spesso ne ricorda una buona parte a memoria).
Perche` no il codice fiscale?
Tanto se lo ricordano tutti a memoria!!! :-)
Il problema, nella vita reale, *non* viene
risolto con gli archivi cartacei, con quelli
informatici, avendo potenti DB, ci si avvicina
di piu` alla soluzione.
bye,
-- 
  Piergiorgio Sartor

 questo porta ad un sistema *non* intuitivo da utilizzare.
Si parla di FS, non di UI.
Si parla del fatto che il FS, in quanto
oggetto di basso livello (nei sistemi attuali),
non puo` essere limitato di suo.
La UI, invece, dovrebbe poter consentire
all'utente un accesso al FS controllabile.
bye,
-- 
  Piergiorgio Sartor

 poi inevitabilmente qualcuno finirą nei pasticci.
[...]
Una curiosita':
te _parli_ col computer o leggi e scrivi per interagire col computer?
Capisco il discorso che se te scrivi il mio nome ViDe oppure Vide oppure 
vide ecc ecc io capisco lo stesso che ti stai riferendo a me. Pero', 
forzando un po' il ragionamento - lo ammetto - , io capisco che ti 
riferisci a me anche se mi chiami \/ide, ad esempio.
-- 
il Vide - ICQ# 5301833
Togli OE per rispondermi
IAMM - it.arti.musica.metal 
IAMMol webzine: 
http://www.iammol.com

 significa che può anche distinguere tra maiuscole e minuscole.
Uhmm... davvero un vel sistema, specialmente molto "umano". Un 
sintetizzatore che legge lettera per lettera... evviva! Immagino lo 
sforzo che dovrà fare.
E, cmq, se la cosa può avere un senso per i linguaggi di programmazione 
che, ahimé e ahinoi, sono case sensitive (non tutti lo sono, cmq), non 
vedo perché un tale scempio debba spandersi in altri ambiti.
Immagina un libro che ti viene letto lettera per lettera... Che felicità!


 esistono le maiuscole (penso di no).
Potrebbe darsi che il braille, una volta imparato, possa essere una 
soluzione efficace, ma il braille non fa distinzione tra maiuscole e 
minuscole.
D'altronde, maiuscole e minuscole sono solo una invenzione *stilistica*.


 Immagina un libro che ti viene letto lettera per lettera... Che felicità!
Oh, beh, anche letto "parola per parola", con
un sintetizzatore vocale, dopo un po' ti fa
impazzire.
Non e` il massimo, migliora le cose, ma e`
diverso da un libro letto da una persona
(cioe` letto da una persona per un non vedente).
bye,
-- 
  Piergiorgio Sartor


Vero. Ma credo che lo siano anche le accentate ed, in un certo senso,
la punteggiatura.
Alessandro.


LOL. Cosi' dai ragione ad Hitman :-P
Alessandro.

 suono più sommesso e dolce, Rudi più autoritario e rude.
AHAHAHAHAHAHAHAHAHAH!...
Le risate si sono sentite anche in Italia?!?  :o)
Ti ricordavo ignorante, presuntuoso e senza vergogna ma non hai mancato di
stupirmi una volta ancora...
Pierpaolo

 minuscole.
Sei sicuro di questo?
Mi pare di ricordare una distinzione tra due
tipo di braille, con un numero diverso di punto.
Il secondo, dovrebbe consentire l'uso di maiuscole
e minuscole.
bye,
-- 
  Piergiorgio Sartor

 D'altronde, maiuscole e minuscole sono solo una invenzione *stilistica*.
Come ti ho gia` detto, c'e` chi distingue
parole e parole in base a questa "invenzione".
byem,
-- 
  Piergiorgio Sartor

 LOL. Cosi' dai ragione ad Hitman :-P
 
Infatti sono convinto che il case sensitive sia cosa buona e giusta, e
visto che non crea problemi nemmeno a chi è costretto a sentirsi
"leggere" i file...


 sforzo che dovrą fare.
Tornaimo all'esempio della IBM-jdk-1.2-ecc-ecc ?
Come lo leggi questo? E' un nome file possibile, d'altronde..
Direi che lo spelling in certi casi e' l'unica soluzione possibile..


 esistono le maiuscole (penso di no).
In Braille le maiuscole esistono, sono codificate con due caratteri.


 la punteggiatura.
Per nulla. Gli accenti hanno un corrispondente vocale, così come la 
punteggiatura. Sono strumenti usati per rendere con segni scritti 
aspetti del linguaggio prettamente fonetici.


 parole e parole in base a questa "invenzione".
No. La distinzione non è vitale, altrimenti ci dovrebbe essere anche 
quando la lingua è parlata, non solo scritta. E' una pura convenzione 
stilistica, che non aggiunge nessuna informazione in più al testo scritto.


 Direi che lo spelling in certi casi e' l'unica soluzione possibile..
Una cosa sono le eccezioni, ed un'altra le regole. Non vedo perché per 
colpa di un'eccezione bisogna mandare a quel paese l'usabilità generale 
del sistema.


 In Braille le maiuscole esistono, sono codificate con due caratteri.
Ok, ho toppato io allora.



Si, ma non sono vitali, come dici tu.
Se ci fai caso gli accenti vengono scritti (almeno in italiano) solo sulle
parole tronche (con l'accento sull'ultima vocale), ma tutte le parole hanno
il loro accento (te lo dice uno il cui cognome viene sempre pronunciato con
l'accento sbagliato ;-).
Alessandro.

 E chi fa la vittima?
Era una battuta..
-- 
Lorenzo

 in quella risposta...
Il sarcasmo ha sempre il significato contrario di quello che si dice 
letteralmente, IMO :)
Comunque, la mia tesi principale non era una condanna a priori del CI,
bensi' se il CI sia possibile averlo con diverse soluzioni (tra le quali in 
userspace), in un ambiente tipicamente CS.
Il CI e' utile in molti ambiti, non a caso molti protocolli di rete sono CI
e non sono cosi' ingenuo da ritenere degli idioti quelli che li hanno 
progettati, tuttavia nei fs mi piace il CS e mi trovo bene.
Se altre persone non si trovano bene allora si cercano soluzioni ma a patto
che queste non siano una limitazione per altri.
-- 
Lorenzo

 l'accento sbagliato ;-).
Questo č assolutamente falso. In parole tronche si segna l'elisione )come
in po') e quasi nessuna delle parole che ha l'accento finale č tronca.
L'accento
č proprio della metrica (naturale e poetica) di una lingua e qualifica anche
la
pronuncia di una vocale o di un gruppo fonetico completo e VA
OBBLIGATORIAMENTE scritto ogni volta che si presenti un'ambiguitŕ
semantica: prěncipi e princěpi, bňtte e botte, včnti e vénti.
Allo stesso modo la punteggiatura ha valore puramente di pausa, con
ricaduta diretta sul ritmo e indiretta sull'intonazione. E' lo "stratagemma"
grafico per rendere sicuro il significato di una frase. In assenza di
punteggiatura
che cosa significherebbe la frase "Una vecchia porta la sbarra"? Forse una
vecchia porta sbarra qualcosa o una vecchietta porta a spasso una sbarra?
La frase non č presa a caso.
Pensa al cambio repentino di significato di una frase come "Magna Roma"
(altri tempi...) se interpunta con "Magna, Roma" (tempi assai recenti).
Il ruolo che la punteggiatura e l'accentazione svolgono (in molte lingue
assai
piů complessa che nella lingua del Belpaese) non ha riscontro nella
differenziazione tra maiuscole e minuscole. Si č deciso, arbitrariamente, di
qualificare i nomi propri, gli inizi di frase e poche altre occorrenze con
lettera
maiuscola iniziale ma ciň non ha nessuna implicazione sulla pronuncia o sul
modo
in cui intonare una parola. Proprio nessuno e, anche con un po' di ricerche
in
giro e sui libri di mia sorella (che č glottologa all'universitŕ di Bologna)
non
sono riuscito a trovare nessuna teoria in merito.
Marco

 l'accento sbagliato ;-).
ecco vedi allora che se ci fosse stato laccento lavrebbero pronunciato 
bene quinti e a tutti gli effetti vitale per una buona comprensione del 
testo


 del sistema.
E' un'eccezione che per i nomi file puo' essere molto di regola..
E poi cmq quella della sintesi vocale e' una cosa assolutamente in user-
space SOPRA a tutto il resto, x cui puo' implementare quel che vuole, no?


Questo è assolutamente falso. In parole tronche si segna l'elisione
Certo, ma non io non intendevo le perole troncate, ma mi riferivo proprio
all'accento.
Ricordo dalla scuola media (un po' appannato, ma sper di non sbagliare):
"si dicono tronche le parole con l'accento sull'ultima sillaba,
piane quelle con l'accento sulla penultima,
sdrucciole quelle con l'accento sulla terzultima (come il mio cognome)
e bisdrucciole qualle sulla quartultima"
(Mamma mia quanto stiamo andando OT!).
Alessandro.
P.S.
A proposito di ambiguita' se ti dico "guarda, lecco!" cosa ti aspetti 
di vedere?


Era una provocazione sul concetto di "vitale".
Alessandro.


E lo è, per una corretta compensione di un concetto senza farti venire i 
mal di testa.



Dei file sul tuo computer, quanti hanno come nome una frase di senso compito?
Alessandro.


Di quelli che creo io, tutti.



Tipo:
"Questo e' l'appunto che ho scritto questa mattina."
"La lettera che devo spedire alla mamma in occasione del suo compleanno."
"Tutti i nomi di file con la virgola che mi dovessero venire in mente 
sono scritti qua dentro"
Alessandro.
P.S.
L'ultimo file e' ancora vuoto, ma, lo so, e' solo questione di tempo.

 di vedere?
Una città in prima istanza. Spero di non stare mai in altri contesti :o)
Il significato è sempre in un contesto. Se mi scrivessi la frase "guarda,
lecco"
questa difficilmente avrebbe un senso compiuto: se me lo scrivi,
probabilmente,
io e te non siamo nello stesso posto quindi la virgola altera il senso
della frase fino a renderla insensata per me sia se intendi indicare la
città
sia se intendi indicare un'azione. Se mi avessi scritto "guarda lecco" il
senso
sarebbe stato immediatamente quello di un esortazione a guardare la città.
Non vedo ambiguità a meno di lettura frettolosa e superficiale.
Marco
P.S. Hai ragione, ormai l'OT è abissale :o)

se intendi indicare la città sia se intendi indicare un'azione.
Potrebbe essere scritta sul retro di una foto :-P (scusa mi e' scappata).
Se anche questo esempio non calzasse sono quasi sicuro che se ne potrebbe
trovare un'altro.
Alessandro.

 "La lettera che devo spedire alla mamma in occasione del suo compleanno."
"Lettera per il compleanno di mamma"



Quindi niente verbi e, soprattutto, niente punteggiatura :-)
Alessandro.


Neanche tu avevi messo la punteggiatura. Ma questo cosa c'entra con 
quello di cui si parlava? Ovviamene il nome del file deve essere il più 
descrittivo possibile con il minimo uso di parole e simboli vari e senza 
richiedere la conoscenza di convenzioni create appositamente all'uopo.


 No. La distinzione non è vitale, altrimenti ci dovrebbe essere anche
Infatti non c'e`.
In tedesco esistono frasi scritti che non
possono essere parlate.
Cioe` esistono casi in cui una frase scritta,
per essere capita chiaramente, deve essere
"detta" in modo diverso, oppure bisogna
contestualizzarla di piu`.
Non tutte le lingue hanno una mappatura
1:1 tra scritto e parlato.
La nostra, quelle latine, sono molto forti
in questo, quelle sassoni sono piu` deboli.
bye,
-- 
  Piergiorgio Sartor

 possono essere parlate.
Un (o più di uno) esempio?


quello di cui si parlava? 
Si parlava di cose superflue e da eliminare.
Per scandalizzarti, volevo dimostrare che i caratteri relativi alla
punteggiatura potevano essere eliminati dall'insieme di quelli ultilizzabili
per nominare i file in quanto "non vitali" e fonte di possibile confusione
se male utilizzati.
Alessandro.

 stilistica, che non aggiunge nessuna informazione in più al testo scritto.
Beh, questo non è vero. Maiuscole e minuscole possono aggiungere informazione a
un testo scritto (non a un testo orale ovviamente). Capita spesso anche nella
poesia. 
Mi viene in mente Emily Dickinson, che spesso cominciava in maiuscolo dei
sostantivi ai quali voleva dare un particolare risalto, ma gli esempio
sarebbero tantissimi. E' anche vero il contrario, come giustamente segnalato per
lingue antiche o non occidentali (latino, ebraico)
Parlando poi di linguaggi formali, perchè è di questo che si sta
discutendo, molti linguaggi - penso a Java - consigliano una convenzione
del tipo isEmpty, getOffset. La convenzione non è scelta a caso. Per
l'occhio, percettivamente, quella maiuscola aiuta la leggibilità, dà una
senzazione di staccato e quant'altro. Poi la cosa è in parte soggettiva. A
molti una convenzione simile fa cagare, però non si può discutere che in
linea generale la logica percettiva che ci sta dietro non sia sensata.
Sempre parlando di linguaggi formali, personalmente sono assolutamente per
i linguaggi case-sensitive. Spinge all'ordine, alla chiarezza. Ho
programmato, pochissimo, in VB e io stesso tendevo a cambiare i case qua e
là, proprio perchè il linguaggio mi spingeva all'istintivo disordine. La
nostra mente è case-insensitive, probabilmente il concetto stesso di scrittura 
non è istintivo, ma una macchina o un linguaggio formale sono altra cosa.
Quello che intendo dire è che non ha senso portare ad esempio
l'innaturalità del case contro chi - come me - sostiene che un FS cs sia
preferibile.
Poi ci vuole buon senso. Se uno comincia a chiamare i file pIpPO, PiPPo e
così via, probabilmente è malato. Mi sembra invece lecito trovare una
differenza semantica (originata da una percezione puramente visiva) e
sfruttarla, tra FILE (struttura dati)  e file (variabile di passaggio).
ciao,
-- 
Rd
"Anche il suo silenzio sconcertava la gente, ma per lui il linguaggio era un
mezzo di comunicazione difettoso, quindi preferiva usare bandierine di
segnalazione anche per i colloqui più intimi"


Per  nulla.  Come  ricordato  la  grammatica  tedesca  usa  maiuscole  e
minuscole per distinguere parole con valenza ambigua.
Ma  come detto,  ho  l'impressione di  parlare con  un  muro per  giunta
saccente.
-- 
Renato "Hitman" Salzano  /  
http://spazioweb.inwind.it/hitman
ICQ #75729987 / IHGGer #778 / NapolICErs #2 / Druido della BUBBLE
"Sull'altare dei miei sogni hai bruciato un sogno in più / se ripenso
 che la nostra storia l'hai voluta tu / dovevo dirti di no"(V.Giovagnini)

 
A dare nomi utili ai files, ad esempio.
DATI e dati possono indicare due cose simili, ma diverse, ad esempio.



Ovvero si deve complicare la vita usando artifizi extra e innaturali.
Bella semplificazione all'utente finale.
Get a life!



O che sia una interfaccia che in questi casi aiuti l'utente.
Che quando cerchi defilippi ti segnali che ne esistano 2 e ti dia dati
per vedere qual'è che cercavi.
Ma che ti  dia la possibilità che se  cerchi un file di cui  sai il nome
(CS) ti riporti subito quello.
Ma come detto, il FS in sè deve essere il più esteso possibile, perchè
tutte le possibilità potrebbero servire. Che poi la shell sovrastante
non le usi, non è interesse suo.
[ora mi aspetto un'altro post delirante dalla coppia Fabio/Rudi, il
nuovo duo comico]



Il che  può essere  utile. Togliere questa  possibilità è  solo togliere
qualcosa di utile all'utente.


 distinguesse avrebbe semplificato molto le cose?
Si, ma indipendentemente da come tu chiami i file e dal fatto che il tuo
fs sia case sensitive o meno.
E' il nome del file che fornisce poche informazioni. Del resto su un
file system case insensitive, dovresti chiamare in modo diverso il file
e questo forse provocherebbe altri problemi.
E' come chiamare i file 
de_filippi_1
de_filippi_2
Riesci a capire al volo che file voglio se ti chiedo il file di De
Filippi ?
bye
Gianluca
-- 
We are the opensource. Existence as you know it is over. We will add
your proprietary features and technological distinctiveness to own
opensource project. Resistence is futile. Windows is closed.

 riferirsi ai clienti (e spesso ne ricorda una buona parte a memoria).
Vero. Ma nella vita reale e' un utente a decidere che nome dare al suo
file. Se mette i nomi dei file a casaccio o in una maniera poco furba,
non e' che un fs CI risolva i problemi...


 all'utente un accesso al FS controllabile.
Non sei tu che hai detto chi il fs *deve* essere CS per non essere
limitato? per poter distinguere fra "de Filippi" e "De Filippi"? Se
hai la possibilità di salvare due file con lo stesso nome, che
differiscano solo per il case, hai un sistema poco intuitivo. Se
l'interfaccia con il fs non ti permette di fare ciò, cosa cambia
avere un fs CS o CI? Nulla, perché questa "funzionalità" non potrà
mai venire utilizzata.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 Filippi ?
Certamente no, ma io non ho mai detto che un fs CI sia la panacea.
Ma impedisce di fatto un particolare comportamento sbagliato (nel
senso di poco intuitivo). Ora, se il nome dei file fosse dato solo
ed esclusivamente da me, non ci sarebbero problemi, potrei scegliere
sempre un nome significativo, ma visto che alla maggior parte dei
file non sono io a dare il nome... Chiaro che nulla potrà mai
impedire che vengano dati nomi assurdi ai file.


 mai venire utilizzata.
Ma l'interfaccia e` modificabile, primo, secondo
posso sempre accedere al FS a basso livello.
In generale, niente nel sistema deve porre
limitazioni, l'utente deve decidere cosa
limitare e cosa no.
E non venirmi a raccontare la favola del:
"e` fatto per il tuo (nel senso di utente) bene"
perche` non me la bevo :-)
Io, utente, voglio poter decidere da me cosa
e`, per me, intuitivo e cosa non lo e`.
Per esempio io ho sempre trovato la GUI di
win poco intuitiva, quella di GNOME/enlightment/saw...
e` ancora peggio.
Trovo, invece, molto intuitiva la shell.
Quindi la mia idea di "intuitivita`" e`
molto diversa dalla tua, immagino.
Ed il sistema, non io, ne` tu, deve adattarsi
alle esigenze di entrambi.
In quest'ottica il FS non puo` essere CI, un
eventuale strato superiore puo` esserlo, purche`
sia "selezionabile" a piacere.
bye,
-- 
  Piergiorgio Sartor

 sfruttarla, tra FILE (struttura dati)  e file (variabile di passaggio).
Io immaginavo che il concetto di "file" non
fosse neanche da considerare, dal punto di
vista dell'intuitivita`.
Alla fine, uno potrebbe basarsi su icone, o magari
su descrizioni piu` estese (quando il puntatore del
mouse passa sopra l'icona) e cosi` via.
Se vuoi parlare direttamente col FS, dovresti avere
buone ragioni per farlo.
Se sei un "tecnico", CS non dovrebbe essere un
problema, spero.
D'altro canto, mi pare di capire, che il problema
maggiore e` che non sappiamo ancora cosa farcene
di questo FS, cioe` a che scopo deve servire (a parte
archviare file).
bye,
-- 
  Piergiorgio Sartor

 trovare un'altro.
Altrettanto confutabile. La lingua italiana è complessa ma se si sta alle
regole
è più precisa di quanto si vada dicendo. A questo punto però siamo OT
anche rispetto all'OT.
Marco

 Un (o più di uno) esempio?
Devo recuperare il giornale...
...se lo ho ancora...
Per farti un esempio _inventato_,
uno potrebbe dire:
Ho comprato bene
Ho comprato (un) Bene
Nel primo caso si intende che la
transazione e` stata favorevole,
nel secondo che hai comprato qualcosa.
In italiano ci sarebbe "un" a distinguere,
ma se non fosse necessario o non fosse
addirittura da usarsi, avresti un problema.
La lingua parlata aggira la cosa usando
un'altra frase, per esempio:
Ho bene comprato
Ho comprato (un) Bene.
Quella scritta consente la prima ambiguita`,
poiche` la risolve con la "B".
Non che succeda spesso, sia chiaro, anzi
sono rari casi. Il problema in tedesco si
pone anche a causa delle declinazioni.
Dato che le parole sono declinate, hanno
piu` versioni, che si sovrappongono fra
di loro ed, a volte, con altre parole
(ed a volte tra maschile e femminile...).
Ti faccio un esempio in inglese, che ha un
simile problema, sempre a causa della differente
evoluzione tra la lingua scritta e quella parlata:
Spice tea
Spy's tea
Praticamente stessa pronuncia (forse impercettibile
differenza), significato totalmente diverso.
Mind's eye
Mind's I
Anche qui la pronuncia e` praticamente identica,
la scrittura non lo e`.
Chiaramente qui non vi e` problema di "case", ma,
spero, renda l'idea del fatto che non vi e`
mappatura 1:1 tra lingua scritta e parlata.
Le lingue latine sono molto piu` "forti", dato
che l'evoluzione scritto/parlato e` sempre
stata legata strettamente, per cui esistono
regole di pronuncia fortemente connesse al
modo in cui scrivi, riducendo cosi` le
ambiguita`. In realta`, se scrivessimo tutti
gli accenti correttamente, forse annulleremo
completamente le ambiguita`.
bye,
-- 
  Piergiorgio Sartor

 in questo, quelle sassoni sono piu` deboli.
???? Non riesco proprio ad immaginare una frase scritta o detta che non
sia "leggibile" o "interpretabile" leggendola o udendola. Scrivere un
libro di azione composto solo dei dialoghi è comprensibile nella stessa
misura in cui lo sarebbe ascoltare alla radio "Arma Letale 4". Manca il
contesto ma il contesto, in questo caso, è esterno alla lingua in sè e
dovremmo chiamarlo un po' più ampiamente "ambiente". D'altro canto
è sempre possibile esprimere a parole concetti non riconducibili ad una
rappresentazione grafica o sonora mentre non è vero il contrario.
Pensa a "M'illumino d'immenso" e a quanto non rappresentabile sia il
significato di una frase che è a prima lettura semplicissima e che nasconde
un significato (o più significati) quasi completamente inafferrabili e
sfuggenti.
Marco


Non sono d'accordo (visto l'OT segue spiegazione per e-mail).
Alessandro.

 Avro` capito male io...
Non è lo stesso Rudi. Fai attenzione :)


 misura in cui lo sarebbe ascoltare alla radio "Arma Letale 4". Manca il
Sei sicuro?
Riporto l'esempio di Hofdstatter:
Mind's I
Mind's eye
"eye" e "I" hanno la stessa identica pronuncia,
ma un significato diverso.
Se lo ascolti, non capisci, se lo leggi, capisci.
bye,
-- 
  Piergiorgio Sartor

 Non č lo stesso Rudi. Fai attenzione :)
Azz.
E poi ci incartiamo sul CS/CI :-)
Vabbe`, mea culpa...
bye,
-- 
  Piergiorgio Sartor

 Se lo ascolti, non capisci, se lo leggi, capisci.
Se un altoatesino mi legge un testo in italiano ricco di parole ambigue come
venti (movimenti d'aria), botte (del vino),... continuo a capire anche se
pronuncia
(lui sì nello stesso modo) queste parole come quelle di significato diverso
(il numero, le percosse).
Per il resto mi arrendo, quando si prende la via delle antinomìe è dura
uscirne ed
io non sono certo un linguista. Quel poco che so attiene più al senso e al
significato e viene solo da un esame di Filosofia del Diritto, quindi non
posso
parlare che di Lacan e combriccola. Ma da quel poco che so e che ho potuto
(ehm, dovuto) studiare posso dire di non aver mai visto accenni in accademia
a quanto si va dicendo qui da qualche giorno.
Ovviamente non sono come la divina biblioteca di Babele... non contengo e
non
ho letto tutto ;o)
Marco

 a quanto si va dicendo qui da qualche giorno.
Ma per l'italiano il problema non si pone
o si pone in maniera insignificante.
-- 
  Piergiorgio Sartor

 diversa.
Mi correggo subito da solo: la fonetica è la stessa [ai]. In effetti la
cadenza di pronuncia varia con la parola che segue (come da regole
della lingua inglese) ma in questo caso non c'è parola a seguire...
Mi ritiro per deliberare :o)))
Marco

 erre a a di emme e)
In alcuni ambienti si può avere (mutuando dal Braille) un suono prima
di una maiuscola e un doppio suono prima di una parola tutta in
maiuscolo. Un po' meglio, certo, ma sempre una perdita di tempo,
tant'è che perlopiù lo usano i programmatori, perché costretti da
certi linguaggi.
-- 
 "Perfection is attained not when there is no longer anything to add,
 but when there is no longer anything to take away" (A de Saint-Exupery)
 Rudi Chiarito                                            
ru...@amiga.com

 sia "selezionabile" a piacere.
I vantaggi di un fs CS sono inesistenti...


 "intuitività" a sproposito.
Lo utilizzo per me.
bye,
-- 
  Piergiorgio Sartor

 I vantaggi di un fs CS sono inesistenti...
Quindi non c'e` motivo per non usarlo :-)
bye,
-- 
  Piergiorgio Sartor

 mappatura 1:1 tra lingua scritta e parlata.
Perdonami, ma mi pare una emerita caxxata. Il fatto che si possano
fare simili "giochi di parole" è totalmente indipendente dal fatto
che esista la lingua scritta.
D'altra parte ti potrei fare l'esempio opposto:
se io scrivo "ancora" cosa voglio dire, àncora o ancòra? Parlando
l'accento non lascerebbe adito a dubbi...


 Quindi non c'e` motivo per non usarlo :-)
No, perché ci sono vantaggi in un fs CI...


 l'accento non lascerebbe adito a dubbi...
Questo e` esattamente il contrario,
confermo che non hai capito.
Rispiego:
"I" ed "eye" hanno la _stessa_ pronuncia,
non si distinguono per accenti o simili.
Se la dizione dell'oratore e` corretta, *non*
puoi distinguerli.
Se scritti, invece, sono totalmente distinguibili.
La tua ancora, invece, si scrive e si legge
in maniera diversa, come "pane" e "pasta",
quindi non c'entra proprio un bel nulla.
bye,
-- 
  Piergiorgio Sartor

 No, perché ci sono vantaggi in un fs CI...
Ancora devono spiegarmeli.
P.S.: smettila di provocare, se la
giornata ti e` andata storta, vedi
di sfogarti altrove.
bye,
-- 
  Piergiorgio Sartor

 Lo utilizzo per me.
No, tu non stai parlando di intuitività, ma di altre
caratteristiche. Perché una shell testuale non può essere intuitiva,
per la definizione stessa di intuitività. E non è una cosa
soggettiva, per nessuno *mai* una shell testuale potrà essere
intuitiva.


 quindi non c'entra proprio un bel nulla.
????????????????????????????????????
Si scrive in maniera differente?
Ancora ed ancora si scrivono in maniera differente?


 di sfogarti altrove.
???
Potrei dire lo stesso...


 Ancora ed ancora si scrivono in maniera differente?
L'accento, l'accento, va scritto, proprio
per specificare.
bye,
-- 
  Piergiorgio Sartor

 archviare file).
Dal punto di vista utente dovrebbe fare solo questo, IMHO, dove per archiviare 
intendo anche archiviare in maniera razionale e organizzata
Che poi l'utente medio metta tutto in "documenti" è un altro discorso :-)
Paradossalmente ho notato che persone disordinatissime (io per esempio) sono 
invece molto ordinate e attente a come organizzano i propri dati su un 
calcolatore, mentre persone molto ordinate tendono ad apportarvi disordine, 
cacciando tutti i file che gestiscono sotto la stessa directory senza alcun 
criterio (parlo di uso home, o cmq non molto controllato, tipo segretaria 
piccola impresa). La cosa è assurda: come comprare un motorino e poi usarlo a 
pedali!
 
-- 
Rd

 per specificare.
In italiano non è affatto obbligatorio scrivere l'accento (lo è solo
sull'ultima lettera), anzi... non si scrive mai.


 sull'ultima lettera), anzi... non si scrive mai.
E` obbligatorio scriverlo nei casi anomali.
Come l'ultima lettera... o la prima.
bye,
-- 
  Piergiorgio Sartor

 intendo anche archiviare in maniera razionale e organizzata
La domanda e` se il FS debba fornire altri
supporti, per esempio uno spell checker,
per assicurare che i nomi siano in qualche
modo consistenti.
Oppure se lo spell checker debba essere
eventualmente in un altro strato.
bye,
-- 
  Piergiorgio Sartor

 Come l'ultima lettera... o la prima.
<dizionario>
accento:
[...]
segno grafico che si usa per indicare la vocale tonica;
nell'ortografia italiana è obbligatorio sui polisillabi tronchi
(andò, carità), sui monosillabi con dittongo ascendente (più, può)
o, puramente grafico (già, ciò), su alcuni monosillabi per
distinguerli da altri (là avv. da la art., sé pron. da se cong); è
invece facoltativo su parole omografe, p. e. nòcciolo e nocciòlo,
pésca e pèsca
[...]
</dizionario>


 <dizionario>
Strano, avro` un dizionario diverso...
Restano comunque due fatti:
Il primo e` che l'accento *esiste* per
distinguere le due parole, non e` che
non hai alcun mezzo per farlo.
Il fatto che sia "facoltativo", secondo
il tuo dizionario (purtroppo non ho qui
la grammatica...), non vuol dire che vi
sia confusione: se uno ha dei dubbi puo`
evitarli, esiste una regola per farlo.
Il secondo e` che le due parole che porti
ad esempio si scrivono uguali, ma si
pronunciano diversamente. Il mio esempio
e` il contrario, le due parole si scrivono
diversamente e si pronunciano uguali.
Considera che l'intonazione della frase e`
gia` una differenziazione tra parlato e
scritto, il che e` naturale, il contrario
(come il caso inglese "I", "eye") lo e` meno,
ma sta ad indicare (questo e` i punto di
partenza), che la lingua scritta puo` avere
piu` potenza espressiva, in alcuni casi, di
quella parlata.
Allo stesso modo, maiuscole e minuscole,
proprie dello scritto, non sono "inutili"
solo perche` nel parlato non si riconoscono,
cosi` come nel parlato non ricosci "I" da "eye".
bye,
-- 
  Piergiorgio Sartor

 ambiente tipicamente CS.
Sia chiaro che io non sto dicendo che un fs CS sia sbagliato,
ma che sia poco intuitivo. E questo è un dato di fatto, non
una mia opinione.


 Il mio esempio e` il contrario
Lo so... l'ho scritto due volte (questa č la terza) che ho
fatto l'esempio opposto...



Pero' a vederli scritti ReAdMe e rEaDmE non sembrano cosi' uguali :-P
La mia e' un'opinione, non un dato di fatto.
Ma anche la mia opinione e' un dato di fatto :-)
Ciao
Alessandro.

 uguali :-P
Perché? Sono entrambi readme. Non si capisce perché debbano
essere differenti uno dall'altro, visto che il nome è lo
stesso. E comunque non è per nulla evidente quale debba essere
la differenza fra uno e l'alrto


Perché? Sono entrambi readme.
Hai uno spirito di osservazione troppo (o troppo poco?) sviluppato.
Se non sapessi leggere diresti lo stesso?
Alessandro.

 intuitiva.
Guarda che "intuitivita`" *e`" soggettiva,
per definizione...
A meno che tu non parli di "intuitivita`"
media, o dell'utente medio, in questo caso
puo` essere diverso...
Il solo ambiente culturale cambia il
concetto di cosa e` intuitivo e cosa
non lo e`.
Un botanico puo` trovare intuitivo
catalogare icone di file con fiori,
che per me potrebbero sembrare tutti
uguali.
bye,
-- 
piergiorgio

 fatto l'esempio opposto...
Mi era sfuggito, si vede.
Comunque mi e` venuta in menta un'altra
situazione...
Parliamo di MB/s e di Mb/s :-)
In italiano, parlato, si estende la
sigla, perche` altrimenti non si capirebbe
nulla, cioe` si dice "mega bait al secondo"
oppure "mega bit al second".
(NDR: concordo con te che in casi come
questo l'ambiguita scritta sia pessima cosa).
In inglese si dice "em bi second", per il primo
caso, "mega bit per second" nel secondo caso,
cioe` si mantiene la pronuncia scritta in un
caso, si estende nell'altro per evitare ambiguita`.
Ma vi puo` essere un'altra variante, immagina
che si debba scrivere un report sulla velocita`
di trasmissione di certi dati, potrei avere:
report_MB_sec.doc
report_Mb_sec.doc
Ora, chiaramente, se entrambi i report
fossero fatti dalla stessa persona, si
potrebbe contestare che questa sia un
po' tonta a dare due nomi del genere.
Pero` potrebbe essere che i due report
provengano da due persone *diverse*, che
hanno *entrambe* utilizzato una convenzione
*corretta* e *comunemente usata* per
esprimere un concetto *diverso*.
I due file devono poter coesistere, anche
se la cosa puo` essere fastidiosa, anzi,
in questo caso ti confermo che lo e` realmente.
bye,
-- 
piergiorgio

 Se non sapessi leggere diresti lo stesso?
Non direi nulla, perché non capirei nulla...
Ma, ancora una volta: secondo quale logica potresti
comprendere il significato e quindi la differenza fra ReaDmE e
rEadMe?
Avere la "r", la "d" e la "e" maiuscole può forse avere un
qualche significato comprensibile?


 uguali.
No. tutto quello che hai scritto dimostra che continui a *non*
parlare di intuitività.
Intuire significa comprendere *senza* utilizzare logica e
conoscenza, ed è (deve essere) quindi *assolutamente*
indipendente dal contesto sociale e culturale.
Metti chi non ha mai visto un computer davanti una shell
testuale e vediamo cosa riesce ad intuire. Nulla, nulla,
nulla. Perché una shell testuale presuppone la conoscenza dei
comandi (almeno quelli base) per poter essere utilizzata.


 I due file devono poter coesistere
Perché? Tu stesso scrivi che la cosa è fastidiosa. Ed infatti
il fs CI ti mette a riparo da questi problemi.
Comunque, basta cambiare nome...



Vedi sopra.
Alessandro.

 Comunque un motivo potrebbe essere che ho scelto ...
Aspetta, aspetta, aspetta...
Stiamo parlando di *intuitività*, cioè comprendere *senza*
sapere. Se io scelgo una certa convenzione per i nomi dei file
è chiaro che, conoscendo la convenzione, capirò a cosa essi si
riferiscono.
Se non conosco la convenzione *non* capirò mai nulla.
Differenziare i nomi solo per il case è una convenzione e
pertanto *non* intuitiva.


 ambiguita`. In realta`, se scrivessimo tutti
Non sempre. Il francese, che è filologicamente la lingua romanza più
evoluta, ove evoluta non si intende in termini di "maggior valore", è pieno di
omofoni, e a livello di singoli vocaboli, e a livello di intere frasi. La
lingua parlata è completamente scissa da quella scritta e secondo alcuni la
sua evoluzione porterà a una nuova linga scritta in cui intere frasi
diventeranno parole. 
-- 
Rd
"E da loro si attese diritto, ed ecco delitto,
 giustizia ed ecco lamento"

 La pronuncia non è la stessa e l'orecchio attento la percepisce. Ma non devi
No no. La pronuncia è identica (nell'alfabetico fonetico I e eye sono
rappresentati dagli stessi segni, cioè sono lo stesso fonema).
Inglese e francese sono pieni di omofonie dove il prefisso omo va inteso
proprio in senso stretto.
-- 
Rd
"Siamo tutti nella stessa barca. Siamo comparse. Nullità.
 E faremo tutti una brutta fine. Esigenze di copione."

 eventualmente in un altro strato.
Forse mi sono perso dei msg. A me sembra che la soluzione FS cs e programmi
utente con switch CI sia la più comoda e sensata. 
Evidentemente molti trovano comodo il FS ci e no ci si può far niente, 
secondo me facilita la creazione di disordine (cosa bella e talvolta creativa
nella vita :-) ma IMHO da evitare in una macchina)
L'unico argomento che mi ha un po' spiazzato dalle mie convinzioni è stato
quello dei non vedenti. Effettivamente non mi ero mai posto il problema. In
quel caso il CS può complicare la vita. E' anche vero che è un caso estremo
che va trattato per forza di cose a parte, poichè basandosi sull'ipotesi che
l'utente non ci veda, si può criticare tutto (il concetto stesso di GUI non ha
senso in simili circostanze)
-- 
Rd
"I'll take a rusty nail
 And scratch your initials on my arm
 And I'll show you how to sneak up on the roof
 Of the drugstore"

 la differenza fra uno e l'alrto
Immagina di dover implemetare un algoritmo che lavori sui polinomi
Ax^2 + Bx + C  e  ax^2 + bx + c.
E' abbastanza frequente trovare maiuscole e minuscole nel linguaggio 
matematico, anzi e' proprio la regola direi.
Se devo memorizzare i valori dei coefficienti con un fs CS non ho problemi
e posso farlo senza cambiare i nomi.
Con un fs CI devo cambiare i nomi, come per esempio: a_1,... e a_2...
che potrebbero avere dei significati totalmente diversi anche all'interno 
dello stesso algoritmo con il rischio di cambiare nomi di nuovo.
Alla fine potro' si trovare dei nomi senza collisioni, anche descrittivi,
ma resta il fatto che devo cambiarli e se l'algoritmo e' complesso le cose
si fanno piu' impegnative e meno intuitive.
-- 
Lorenzo

 sapere.
Ti viene in mente qualcosa di piu' intuitivo per l'esempio
che ti ho fatto (quello del logo)?
E se anche a te venisse in mente e a me no, dovrei rinunciare
a dare un nome al file perche' quello che mi e' venuto in mente
secondo te e' inadeguato?
Alessandro.

 non ho problemi e posso farlo senza cambiare i nomi.
Scusami, ma non credo di avere capito bene: tu vorresti
memorizzare il valore di ogni coefficiente in un file con il
nome del coefficiente stesso?


 venuto in mente secondo te e' inadeguato?
Beh, se vogliamo tirare fuori esempi improponibili per
giustificare i vantaggi di un fs CS...



Qualunque esempio che giustifichi i vantaggi di un fs CS
sarebbe giudicato improponibile da te :-)
Ciao
Alessandro.

 nome del coefficiente stesso?
Si, perche' no?
Immagina che quei coefficienti siano degli interi a precisione multipla
(decine di cifre).  Immagina anche di avere un programma di fattorizzazione 
(MPQS) che prende come input il numero contenuto nel file.
Se voglio conoscere i fattori di A faccio 'mpqs <A' e ho il risultato.
-- 
Lorenzo

 saccente.
Io ho fornito motivazioni con abbondanti riferimenti. Sei libero di
verificare quello che ho detto. Tu invece ti ostini a difendere le tue
posizioni perché così hai detto e basta.
-- 
 "Perfection is attained not when there is no longer anything to add,
 but when there is no longer anything to take away" (A de Saint-Exupery)
 Rudi Chiarito                                            
ru...@amiga.com

 punto, ad un livello superiore.
Una volta che l'hai nascosto, però, al filesystem restano ben pochi
motivi per cui esistere. ;)


 comandi (almeno quelli base) per poter essere utilizzata.
E` piu` intuitiva, per me, in base al mio
background culturale.
bye,
-- 
  Piergiorgio Sartor

 Comunque, basta cambiare nome...
Eccerto, quello e` sempre possibile...
bye,
-- 
  Piergiorgio Sartor

 senso in simili circostanze)
Infatti.
Il punto e` che un non vedente, per forza di
cose, si trova ad avere delle limitazioni,
in certe situazioni.
Sarebbe bello poter aver machine assolutamente
indipendenti dalle nostre capacita`, ma al
momento non e` cosi`.
D'altronde, parlando di UI, si potrebbe chiedere
l'opinione di persone tipo Stephen Hawkings,
immagino che avrebbero qualcosa da dire, forse
molto piu` "interessante", delle nostre elucubrazioni
su CS/CI.
bye,
-- 
  Piergiorgio Sartor

 motivi per cui esistere. ;)
Non esattamente.
Io voglio avere entrambe le possibilita`,
voglio poter accedere al disco (non parlo
piu` di FS) a diversi livelli.
Per fare un backup potrei voler fare cose
del tipo:
dd if=/dev/hda bs=1k | gzip -c -9 > backup.hda.zip
Cioe` voglio poter accedere al disco a livello
di blocchi.
Cosi` voglio poterlo fare a livello di FS,
oppure a livello di "metafile" (tipo Amiga,
con i .info ed il resto).
In generale l'utente deve poter decidere dove
posizionarsi, a mio avviso.
Questo e` il senso, il CI nel FS e` un
"intelligenza" aggiunta in un posto dove non
ha senso essere.
Senza poi considerare altre cose che potrebbero
essere "insensitive".
Per esempio "i" e "j" in italiano. Potrei volere
un FS "ijy-insensitive", dato che non mi ricordo
se la tipa dell'altra sera si chiama Jaana, Iaana,
Yaana ed il file che documenta il tutto, di
conseguenza, sara` "[IJY]aana.mpg" :-).
bye,
-- 
  Piergiorgio Sartor

 
Non ci sono prove serie a tuo sostegno. 
Ergo, è una tua opinione, nulla più.
-- 
Renato "Hitman" Salzano  /  
http://spazioweb.inwind.it/hitman
ICQ #75729987 / IHGGer #778 / NapolICErs #2 / Druido della BUBBLE
"Sull'altare dei miei sogni hai bruciato un sogno in più / se ripenso
 che la nostra storia l'hai voluta tu / dovevo dirti di no"(V.Giovagnini)


La scrittura stessa è una convenzione, quindi...



Un FS CS può anche essere usato come CI, ma non viceversa.
Logica elementare dice che il FS CI è un insieme più limitato di quello
CS.
Fine della dimostrazione.


 
Ci sono tanti vantaggi, solo che non *vuoi* vederli.


 
No, hai solo elencato i vantaggi di una shell CI, non ho visto *nessuno*
elencare i vantaggi di un FS CI, che non siano opinioni risibili.



Direi che basta questo a considerare una fesseria l'idea di un FS CI.


 compitino" sia assolta.
E perche'? Se non ci sono vincoli contrattuali, scadenze precise, io potrei
lavorare su qualcosa e poi interrompere la mia collaborazione. Lasciando
pendenti tutte le mie attivita', che sarebbero poi riprese (questo si') da
qualcun altro, il quale impiegherebbe di sicuro un po' per adattarsi al mio
lavoro (e, quasi sicuramente, rifarebbe tutto da capo).
Saluti.

 matematico, anzi e' proprio la regola direi.
Non solo maiuscole e minuscole: la mole di simboli è tale che si
trovano anche caratteri in corsivo, in neretto, in altre fonti. Basta
guardare la gamma di simboli predefiniti di LaTeX. Che facciamo
allora, includiamo anche elementi HTML come <I> e <FONT> nei nomi dei
file?
Gli insiemi di numeri normalmente si indicano con maiuscole con doppio
tratto. "N" cos'è, una costante o l'insieme |\\| dei numeri naturali?
"R" cos'è, una costante, un integrale di Riemann (una R manoscritta) o
l'insieme |R dei numeri reali?  "i" cos'è, una variabile o l'unità
immaginaria (i corsiva)? "H" cos'è, una costante, uno spazio di
Hilbert (H 'gotica'), l'insieme |H dei quaternioni o una hamiltoniana
(H manoscritta)?


 (H manoscritta)?
Ehm si, mi aspettavo un'obiezione del genere ed ha perfettamente senso.
Tuttavia, se i simboli ASCII scarseggiano, perche' limitarli ancora di piu'?
BTW, non conosco unicode, per caso c'e' qualche simbolo matematico?
-- 
Lorenzo

 senso in simili circostanze)
Non serve essere non vedenti per avere problemi: basta anche essere
dislessici o avere disturbi dell'attenzione. Dislessico non vuol dire
stupido: Edison e Negroponte ne sono l'esempio.
O ancora: basta avere una mobilità delle mani limitata (o non
averla... o non avere le mani tout court). Per una persona con tutte e
dieci le dita funzionanti non è un gran problema usare il tasto
maiuscole o il blocco maiuscole, ma per chi non è altrettanto
fortunato lo sforzo è maggiore. Ci sono pure persone per le quali ogni
pressione di tasti aggiuntiva è un grosso sforzo in più.
O ancora: basta anche soltanto essere soprappensiero, stressati,
scarsamente concentrati o tentare di fare più cose allo stesso tempo
(il motivo non conta) per avere meno successo con l'imbroccare le
maiuscole giuste.


 Get a life!
Quando non sai portare avanti una discussione con argomentazioni solide
passi sempre all'insulto del tuo interlocutore?


 DATI e dati possono indicare due cose simili, ma diverse, ad esempio.
Diverse in che modo? In italiano si familiarizza con le maiuscole a
inizio di frase o nome proprio studiandole a lungo e vedendole usate
sistematicamente. La cosa funziona, sebbene forzata, perché adottata
da tutti. Se fosse così naturale non ci sarebbe nemmeno bisogno di
andare a scuola, verrebbe da sé come - Chomsky insegna - succede per
la lingua.
Distinguere tra "DATI" e "dati" è un'altra forzatura ed in questo caso
non è nemmeno una convenzione universale.


 conseguenza, sara` "[IJY]aana.mpg" :-).
Documenta cosa? Zozzone :)


 BTW, non conosco unicode, per caso c'e' qualche simbolo matematico?
Certo. E con Unicode 3.2 sono state aggiunte nel piano 1 (quindi non
propriamente supportati in sistemi che prevedano solo codifiche a soli
16bit o comunque codici fino a 65535) versioni in corsivo, grassetto,
Fraktur (gotico), manoscritto, doppio tratto, ecc. dell'alfabeto
romano.
Un principio fondamentale di Unicode, quasi sempre rispettato, è che
gli stili del testo non sono un suo scopo. Se una applicazione vuole
memorizzare una "f" in corsivo o con un determinato tipo di carattere,
deve usare meccanismi come quello di HTML (<I>f</I>).  Altrimenti
Unicode avrebbe dovuto fornire un codice per ogni lettera in ogni
stile (quelli classici, più magari sottolineato, ombreggiato,
ecc.). Nel caso di Unicode 3.2 i nuovi codici sono stati assegnati per
uso prettamente simbolico e matematico, non per scrivere testo
generico.



Non credo che sia solo un problema di maiuscole.
Alessandro


Prova a giudicare con l'occhio: sono cosi' uguali?
Alessandro.


1) Si suppone  che se inizi un progetto Free/PD/ecc.  sia per risolverti
un problema, e mi  sembra poco logico (a meno di  cause esterne di forza
maggiore) che lo abbandoni prima che ti risolva il problema.
2) Spesso capita  che si lavora in più  di uno, e al momento  in cui uno
abbandona, il resto del team va avanti lo stesso, come hai anche detto.


 Non ci sono prove serie a tuo sostegno. 
Ne hai tu a tuo sostegno, invece? Dimostra che la mente umana
non ha problemi con situazioni virtualmente identiche, eccetto che
per piccole differenze. Tu forse all'istante scovi le differenze
nel gioco della Settimana Enigmistica, ma noi altri mortali
impiegamo un po' di tempo.
Linee guide per le interfacce dei sistemi di combattimento della
marina americana:
http://hsi.spawar.navy.mil/Publications/CSFAB/CSFAB_Information_Coding.html#IC_Alphanumerics
 "Case-sensitive coding should be avoided except for passwords."
(si suppone che i sistemi di combattimento siano in mano a gente
addestrata)
Psicologia della programmazione, "Usability Issues in Programming
Languages":
http://www-2.cs.cmu.edu/~NatProg/langeval.html
 # Many languages are case sensitive, and some conventions encourage
   using the same symbol with different capitalization for different
   meanings (e.g., the type Foo vs. a variable of that type foo vs. a
   constant FOO).


 maiuscole giuste.
Beh, la disattenzione - patologica o momentanea - mal si adatta
all'utilizzo di un computer.
-- 
Rd
"'Tis now the very witching time of night,
 When churchyards yawn and hell itself breathes out 
 Contagion to this world."


Certo, infatti nel nostro alfabeto le maiuscole non esistono, vero? 
E la gente non le usa mai, gia... 
Bah, mi chiedo che senso ha ancora discutere con te.



Questo fa saltare anche _tutti_ gli  esempi dell'utilità di un FS CI che
sono stati portati finora.
Come se qualcuno avesse ancora dubbi che fossero esempi validi...



Sono fatti dell'utente. Tu non  devi condizionarlo, solo offrirgli tutte
le possibilità che puoi.
Invece vedo  nelle tue parole  e citazioni  solo voglia di  obbligare il
mondo a seguire delle idee e schemi precostruiti nella tua testa.
Notizia 1: il fatto che esista un  FS CS non obbliga gli utenti a usarlo
per forza come CS, possono benissimo usare nomi di file solo minuscoli.
Notizia 2: su un FS CS puoi costruire una shell CI, non il viceversa.
Io sono  per lasciare la scelta  all'utente, a te evidentemente  la cosa
non piace. Dice molto sulle tue idee, direi.


 maiuscole e minuscole.
 
Non c'è dubbio che per molte persone non sia molto immediato muoversi in un
file system CS, lo ammetto :-)
E' innegabile e lo si nota anche senza fare esperimenti. Non staremmo neanche
qui a discuterne. D'altro canto, non è neanche una difficoltà insormontabile, 
perchè cmq il concetto di maiuscola/minuscola è molto chiaro nella testa di
un uomo occidentale alfabetizzato. Ed esiste anche chi, come me e molto
altri, preferisce l'ordine e l'univocità di un filesystem CS. Se domani
tutti i filesystem diventassero CI non ne farei cmq una tragedia. Una cosa
che però non tollero è un filesystem CI che modifica forzatamente la
rappresentazione che ho dato io a un nome. Se non sbaglio windows fa così.
Scrivo un nome con dei mixed case che per me sono significativi, e mi forza
visivamente tutto in in lower o in upper. Mi sta bene che internamente non
gli faccia alcuna differenza, ma come l'ho scritto voglio vederlo!
Un altra cosa su cui sono dogmatico, è quella dei linguaggi. Un linguaggio
CI è imho una stronzata. Permette troppe inutili libertà, portatrici di
disordine e imprecisione.


non deve impedire a chi le possiede di poterle sfruttare.
Appunto, sfruttarle. Sfruttarle = trarne frutto, qual'è il frutto?
Nei linguaggi il case sensitive portano a delle convenzioni (tipo
costanti in maiuscolo, variabili in minuscolo, funzioni in minuscolo o
con regole precise) che facilitano la scrittura e la lettura. 
In assenza di convenzioni il cs moltiplica esponenzialmente  le
probabilità di non trovare l'informazione che si sta cercando, quindi
il vantaggio deve essere davvero grosso.

non piace. Dice molto sulle tue idee, direi.
Va beh, quì si sconfina nelle solite sciocchezze. Certo che finchè
continui a insinuare che certe convenzioni sono imposizioni fasciste
si discute male.
Vogliamo aggiungere la regola antisemita di scrivere da sinistra a
destra? 
PS: comunque te ne do atto, quella delle esclamazioni in maiuscolo mi
ha fatto fare una gran bella risata...

 Documenta cosa? Zozzone :)
Scambio inter-culturale Finlandia-Italia... :-)
bye,
-- 
piergiorgio

 dove ho messo cosa...
Questo anche perché non hai riferimenti visuali o spaziali.


 risultato.
A parte le obiezioni che ti hanno già fatto, non è questo il
punto. Ci possono evidentemente essere (pochi) casi in cui
serve veramente poter distinguere due file solo per il case.
Solo che questo viene fatto per casi in cui una simile
distinzione non solo è inutile, ma è addirittura dannosa (vedi
i README, readme, Readme, ecc...)
Infatti io non ho mai detto che un fs debba essere CI, o che
sia un errore un fs CS, ma ho detto (a ragione) che un fs CS è
poco intuitivo.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 sarebbe giudicato improponibile da te :-)
No, non nego che possa avere certi vantaggi. Quello che dico è



In fatto che sia opportuno assumere delle convenzioni e' indipendente
dall'uso di file system case sensitive o meno.
Aggiungo un'osservazione personale:
E' raro che io cerchi un file per nome.
Piuttosto e' importante che mi ricordi approssimativamante dove e'
collocato (cioe' la sequenza delle directory da visitare per raggiungerlo),
e un buon file manager risolve agevolmente il problema anche se non
ricordo esattamente in nomi (e non solo il loro case).
Se devo accedere ad un file da riga di comando non ho maggiori difficolta'
su Linux (case sensitive) che su Windows (case insensitive), anzi magari
il contrario perche' sul secondo i nomi utilizzati sono generalmente piu'
lunghi e spesso contengono degli spazi.
Alessandro.

 background culturale.
Non ci siamoooo....


 imprecisione.
Dal punto di vista dell'intuitività è la stessa cosa.


lunghi e spesso contengono degli spazi.
Su linux l'unica vera facilitazione è il tab, per il resto non vedo
come e perchè possa essere più semplice. 


Si ma *che* cosa? Anche premendo i tasti succede *qualcosa*.
Alessandro.
P.S.
Pigiare tasti IMHO e' spesso piu' immediato (infatti nei POS
sono piu' diffusi i touch screen che le trackball).
Il mouse dichiede molto piu' addestramento, mira, e rifessi
(pensa al doppio click).

 Dal punto di vista dell'intuitività è la stessa cosa.
Che c'entra? Anche "for (i=0; i<sz; i++)" non è intuitivo. Non esageriamo con
l'osanna dell'"intuitività", "è intuitivo allora è migliore", "intuitivo is
better" (a mo' di slogan :-)
Non c'è nulla di meno intuitivo di un computer o di un automobile o di mille altre
cose che qualunque essere umano è in grado di fare con un minimo di preparazione. 
Il mouse, di cui si è parlato, non è affatto intuitivo (lo è un touch-screen forse),
ma questo non vuol dire che non sia comodo e che non sia stato una grande
invenzione. 
Il punto è accordarsi su convenzioni "ragionevoli" e uniformi (in modo da
poter riapplicare intuitivamene con un componente, ciò che si è appreso durante 
l'interazione con un altro componente).
Il CS su un linguaggio è poi banalissimo. Al primo tentativo canni, capisci che
WHILE non compila e while sì, e basta. Afferri il formalismo e sei a posto,
perchè se la differenza maiuscola/minuscola non è innata - e su questo siamo tutti
d'accordo - non è neppure così estranea alla nostra percezione come sembri
sostenere (è una convenzione espressiva di cui tutti siamo partecipi, chi
più chi meno)
-- 
Rd
"The fair breeze blew, the white foam flew,
 The furrow followed free;
 We were the first that ever burst
 Into that silent sea."


Un miliardo di alfabetizzati che usano maiuscole e minuscole senza
problemi direi che bastano.
Il resto è fuffa, o pippe mentali di poche persone, che hanno perso
spesso il contatto con il mondo.



Non prendevo neanche in considerazione il tab completion (non lo uso quasi
mai).
Il perche' te l'ho gia' detto: su windows i nomi utilizzati sono generalmente
piu' lunghi e spesso contengono degli spazi.
Alessandro.

 e a premere i suoi pulsanti... e qualcosa combinerà.
Terza cosa non vera...
Sia come risultati, che come concetto di "intuitivita`".
bye,
-- 
  Piergiorgio Sartor

 lingua non familiare) č decisamente miope.
Giusto, non devi usarlo, ma la possibilita`
di nomenclatura non puo` risiedere nel FS.
bye,
-- 
  Piergiorgio Sartor

 abbandona, il resto del team va avanti lo stesso, come hai anche detto.
Questo invece e' un pregio. Ma puo' accadere anche in una azienda CS.
Saluti.

 certe categorie di persone, che non includono tutti.
Usabilità, non intuitività...


 di slogan :-)
Ho forse detto questo? Ho solo affermato che un linguaggio CS
è meno intuitivo di uno CI. Non ho mai detto (e non l'ho mai
detto neppure a proposito del fs) che sia migliore.


 Pigiare tasti IMHO e' spesso piu' immediato
Certo, è immediato e naturale, ma cosa scrivere?
Da questo punto di vista la shell di Windows è nettamente
migliore, perché digitando help ottengo la lista dei comandi,
mentre in Unix digitando help ottengo solo un "command not
found".


 poco intuitivo.
Probabilmente un fs CS e' poco intuitivo per molte persone, ma non per me 
quindi per quanto mi riguarda il "case" e' chiuso :)
Battute a parte, un utente dovrebbe adottare un fs in base alle proprie 
effettive esigenze e non in base a qualche studio di ergonomia.
-- 
Lorenzo

 generico.
Interessante.
-- 
Lorenzo


Adesso non stavamo parlando di shell ma di interfaccia utente.
Comunque sul mio Linux "help" mi da' l'help della shell, "info" da'
l'accesso alla documentazione dei comandi del sistema (oltre che su una
barcata di altre cose).
Alessandro

 detto neppure a proposito del fs) che sia migliore.
Mi sembrava che il giudizio di valore fosse implicito, vista la dinamica
della discussione (meglio CI o CS? perchè?). L'intuitività sembrava appunto la tua
argomentazione principale a favore del fs CI. Ho capito male.
-- 
Rd
"Aujourd'hui l'espace est splendide!
 Sans mors, sans éperons, sans bride,
 Partons à cheval sur le vin
 Pour le ciel féerique et divin!"

 found".
E' una battuta? nomecomando --help | -h è la prima cosa che impari!
Cmq la shell di windows è innaturale a priori: il backslash come separatore è
chiaramente dissonante, se scrivi da sx verso dx. Lo slash, visivamente,
scorre meglio (non c'entra molto ed è una considerazione paranoica, lo ammetto, 
però non è infondata).


 
Probabilmente perchè di base la sua struttura file è più ordinata.



Lasciando il  FS CS dò libertà  all'utente sui suoi file  di fare quello
che vuole, compreso usare solo le maiuscole o minuscole.
Imponendo il FS CI, ho tolto una libertà all'utente.
Concordi su questo semplice fatto?


 passi sempre all'insulto del tuo interlocutore?
Tra l'altro fuori contesto. Temo che con l'inglese riproponga gli stessi
grossi problemi che ha con l'italiano.  :o)
Intendeva forse "get with it"? "Get it together"? Nella West Coast, cmq,
l'espressione usata dal ns linguista è molto "colloquiale", nel senso di non
essere particolarmente aggressiva. E, perlopiù, intesa nel senso delle 2
altre espressioni che ho riportato sopra.
Ma dubito che il Salzano abbia fatto di queste considerazioni, copiando ed
incollando il suo "inglese da newsgroup"...
Ciao, Pierpaolo.
P.S. Che ci fai ancora negli States? Il tuo obiettivo è sempre riuscire a
tornare in Italia nel giro di un paio d'anni?  :o)
P.P.S. Da un paio di mesi ho lasciato la California e sono, diciamo, in (una
lunga) vacanza con abbastanza tempo libero, ora che ho individuato una certa
"routine". Se ti va (il tuo scambio con il Salzano mi suggerisce che forse
hai anche tu abbastanza tempo da perdere... :o) ) mi piacerebbe riprendere
la ns discussione di circa 1 anno fa. Ricordi?
Il tema mi stava molto a cuore e mi è spiaciuto doverla sospendere, anche
per il fatto che l'interlocutore è uno dei pochi degni di stima sui NG della
gerarchia *.it  :o)
Eventualmente, scegli un NG "compatibile" (anche di lingua inglese, se
credi) o l'e-mail.
Naturalmente, se nel frattempo hai cambiato idea...
:o))))

 Usabilità, non intuitività...
Nono, proprio "intuitivita`", che a volte
si puo` sovrapporre/confondere con "usabilita`",
dato che se e` poco intuitivo e` anche poco
usabile od usabile malamente.
Dato che si misura quasi sempre un tempo,
cioe` il tempo che ci si mette per fare una
certa serie di operazioni, cosa si misuri
realmente non e` proprio chiarissimo.
bye,
-- 
  Piergiorgio Sartor


be sotto unix per avere la documentazione e' sufficiente fare man
<nomecomando>
-- 
Sidewinder  
---------------------------------------------------------------------
If you teach your children to like computers and to know how to gamble
then they'll always be interested in something and won't come to no real harm.
---------------------------------------------------------------------

>found".
Direi che questa nel panorama delle immense minchiate che si leggono su
questo newsgroup da parte di alcuni personaggi rientra al top della
classifica fra le migliori che siano mai passate perche' solo uno con
gravi turbe psichiche potrebbe pensare di confrontare la shell UNIX con
il command prompt del Dos ed anche le man pages o le info in formato
ipertestuale con uno stupido
C:\>HELP DIR
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 non piace. Dice molto sulle tue idee, direi.
Stai cadendo proprio in basso: visto che non ti riesce parlare di
altro perchй _non hai prove_, cerchi di dipingere te come un buono
(Robin Hood? no, lui non era pure un genio a livello multimediale come
te) e me come un cattivo.
Sei per lasciare la scelta all'utente? Allora pensi che dovremmo avere
nomi di file con caratteri maiuscoli, minuscoli, in corsivo,
grassetto, lilla, verdi, in Helvetica, ecc.? Pure quelli potrebbero
tornare utili all'utente, sebbene possano dare problemi ad impediti
come me. Sempre in nome della libertа di scelta dell'utente, non
dovremmo lasciare quest'ultimo libero di usare le estensioni HTML che
vuole? Impediti come me potrebbero avere noie con altri browser, ma
tanto tu hai dimostrato che non и un tuo problema.
-- 
 "Perfection is attained not when there is no longer anything to add,
 but when there is no longer anything to take away" (A de Saint-Exupery)
 Rudi Chiarito                                            
ru...@amiga.com

 Bah, mi chiedo che senso ha ancora discutere con te.
Discutere? Magari questa fosse una discussione. Se avessi portato
qualche prova rigorosa di quel che dici sarei stato ben felice di
ricredermi, ma finora ho solo visto impressioni spacciate per fatti.


 Prova a giudicare con l'occhio: sono cosi' uguali?
No, ma per il cervello si tratta degli stessi fonemi. Il cervello
è due volte più efficiente a stabilire se due parole rimano...


 O sarebbe stato meglio che si fosse rimasti alla tradizione orale?
Negroponte è direttore del Media Lab al MIT. :) Detto ciò, solo un
terzo delle lingue che conosciamo ha una propria forma scritta. Chissà
quante in sola forma orale sono scomparse senza ovviamente lasciare
traccia.
Tanto per fare un esempio, la civiltà Inca prosperò per almeno un
millennio parlando il quechua, ma usando la scrittura solo per i
numeri. Solo con l'arrivo dei conquistatori spagnoli e dei missionari
la popolazione si è frammentata in un numero di comunità, così come la
lingua, dando origine a una serie di scritture l'una diversa
dall'altra.
Anche in Europa del resto parte della nostra cultura è stata
tramandata per secoli in forma prettamente orale.
-- 
 Perfection is attained not when there is no longer anything to add,
 but when there is no longer anything to take away (A. de Saint-Exupery)
 Rudi Chiarito                                            
ru...@amiga.com


Se non fosse stato tramandato in forma scritta, secondo te,
cosa ci sarebbe pervenuto del pensiero di Aristotele?
Hai idea di quale sia il contributo dell'esitenza della scritura
al progresso culturale e tecnologico delle civilta'?
Alessandro.

No, ma per il cervello si tratta degli stessi fonemi.
Trattandosi di comunicazione scritta pero' la differnza e' evidente :-)
Alessandro.

 ovviamente non ha.
C'e` anche da dire che i bambini sono "esposti"
alla lingua (madre) prima ancora di nascere.
Verso gli ultimi mesi di gravidanza, sono in
grado di ascoltare, percepire ed assimilare la
lingua (ed i suoni, quali la musica, per esempio)
parlata "esternamente".
Questa e` una delle ragioni per cui la prima
lingua viene "acquisita".
Altra considerazione riguarda il modo in cui il
cervello processa i suoni, non solo nei bambini.
La primissima cosa che viene fatta e` la separazione
tra "parlato" ed altro (musica, rumore, altra lingua).
Vi e` un pre-pre-filtro che separa i "dati" e li invia
in diverse aree del cervello, a posteriori vengono
fatti tutti gli altri "processamenti" del caso.
E` anche vero che alcune parti dell'analisi linguistica
che il cervello fa, sono comuni allo scritto ed al parlato.
Come ad esempio le connessione/correlazioni semantiche.
Detto cio`, mi sa che siamo ancora fuori scopo, dato
che il FS e` *scritto*, che piaccia o no, che sia sempre
comodo o no.
Quindi le argomentazioni sulla lingua "parlata", non sono
troppo proprie, bisognerebbe tirare in ballo la memoria
"visiva", non quella "acustica". Magari argomentare quanto
forte o debole questa sia nel caso dei nomi.
bye,
-- 
  Piergiorgio Sartor

 spesso il contatto con il mondo.
ROTFLASTIC :))) Ma, dico, quando lo rinchiudono?
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 italiana?
Il mio vocabolario di italiano include solo 9 vocaboli stranieri entrati 
a far parte della lingua italiana. Nessuno di essi si può scrivere con 
la "i" o con la "y" al posto della "j". Inoltre, questo è quello che 
dice a proposito di "j":
"j, consonante propria di molte lingue _straniere_; si conserva nella 
scrittura di _forestierismi_."
Inoltre dice che in passato la "j" faceva parte della lintgua italiana, 
ma ormai è stata completamente rimpiazzata dalla "i".



E' un'idea, solo che al contrario delle maiuscole/minuscole, non ci sono
ancora abbastanza utenti che realmente le usano e le vogliono.
Infatti  nessun  FS è  stato  creato  con simili  caratteristiche.  Eck,
neanche, a dire  il vero: i FS con metadati  in fondo sono un'estensione
generale di questo.



Se lo fosse realmente, non sarebbe nell'alfabeto.
Evidentemente  non  lo  è,  o  è un  problema  irrilevante  rispetto  ai
vantaggi.


 male.
In effetti non ho mai chiarito bene.


 qualche studio di ergonomia.
Come ho già risposto ad altri, io ho solo affermato che un fs
CS è poco intuitivo (cosa vera e dimostrata da studi). Non ho
mai detto che sia uno sbaglio, o che un fs CI sia migliore,
anche se comunque ritengo che i vantaggi di un fs CS siano
veramente pochissimi e relativi a pochi casi particolari.


 ammetto, però non è infondata).
Mah, sinceramente potrà essere visivamente brutto, ma non vedo
alcun (valido) motivo per cui uno debba essere preferito
all'altro.


 usabile od usabile malamente.
Ma non è per nulla vero. Usabilità ed intuitività hanno poco a
che fare.
Quello che è vero è che ciò che è poco intuitivo sarà
difficile da utilizzare da chi non ha pratica.


 fare man <nomecomando>
Senza polemica, ma se la prossima volta, prima di rispondere,
leggi attentamente... :-P
Scrivere man nomecomando è cosa semplicissima, non lo metto in
dubbio, ma presuppone:
1) Conoscere il comando man
2) Conoscere il comando del quale si cercano informazioni.
Visto che io ha fatto l'esempio, per contestarne l'intuitività
(e non utilizzabilità), di chi viene messo davanti ad una
shell testuale senza "saperne" nulla, la tua risposta non ha
molto senso ;-)


 
Beh, infatti non lo č (č nell'alfabeto ASCII - artificiale - non nell'alfabeto 
tout-court). 
IHVHO, se non fate una netta distinzione tra lingua scritta (artificiale e naturale)
e lingua parlata, non ne uscite piů :-) 
-- 
Rd
"I mattini musicali degli gnomi dei boschi erano disturbati soltanto
 da boscaioli mancini che cercavano di abbattere gli alberi con
 l'accetta stretta nella mano destra. Sangue nella selva, si sarebbe
 potuta chiamare quella scena."

 difficile da utilizzare da chi non ha pratica.
Questo è un prezzo da pagare, molto spesso. Meglio l'usabilità che
l'intuitività. Chiamare un indice "indice_loop_esterno_array" è più intuitivo di
"i", per uno sprovveduto, ma è chiaramente poco usabile (i.e. poco pratico)


 all'altro.
Perchè è visivamente più intuitivo lo slash, più armonico con la direzione
della scrittura e dello sguardo di un occidentale (considerazione personale non
suffragata da esperimenti)


 A me non lo fa...
 
Ora ricordo meglio. Lo fa solo sulle directory. Non ti torna? Appena ho
l'occasione provo (tra l'altro se non sbaglio, NTFS su win2000 č case-sensitive, ma
non essendolo le API win32 la cosa č mascherata)


Concordi su questo semplice fatto?
No.
Semplice fatto? Direi un bel concentrato di retorica.
Guarda, per il decoro della discussione è meglio se cambi
l'argomentazione... non vorrei arrivare a sentire che guidare a destra
o avvitare le viti verso destra è una tremenda limitazione della
libertà.

ragione.
IN EFFETTI E' VERO. NELLA COMUNICAZIONE AUDIO+VIDEO BISOGNA USARE I
LIMITI MAGGIORI - CHE SONO QUELLI AUDIO (DOVE INFATTI NON C'E' MODO
DI DISTINGUERE FRA MAIUSCOLO O MINUSCOLO).
A BEN PENSARCI, SAREBBE PIU' INTUITIVO UN FILE SYSTEM SOUNDEX, DATO
CHE MI POTREBBERO CHIEDERE GLI ELENCHI "OURS" E "THEIRS", MA POTREI
TROVARE SOLO "OURS" E "THIERS" (QUALCUNO CI HA MAI PENSATO?)
HO IL SOSPETTO CHE CONTINUANDO SU QUESTA STRADA ARRIVEREMMO PRIMA O
POI ALLA CONCLUSIONE CHE PIU' LIBERTA' SI DA' ALL'UTENTE, PIU' TALE
UTENTE E' LIBERO DI SBAGLIARE. ED E' UNA DISCUSSIONE GIA' SENTITA.
LEONARDO "A VOLTE RITORNA"
-- 
Microsoft Outlook: il primo news reader con supporto messaggistica RAID 1.

 LO VUOLE.
E come già dimostrato si abbatterebbero le prestazioni. Bella mossa.


molto senso ;-)
Ma anche uno che si metta davanti ad una GUI senza saperne nulla (ne'
delle GUI in generale), ha poche possibilita'.
Magari guarda accigliato lo schermo e dice perentorio: "Computer! Dai
inizio ad una simulazione... Computer? Computer?"
A quel punto prende il mouse in mano, lo avvicina alla bocca, e tutto
soddisfatto riprende: "Ah-hem! Computer?"
Ci vorra' il minimo di input di qualcuno li' vicino che abbia pieta',
e gli suggerisca "Forse... usando la tastiera..." [1]
Leonardo
[1] si', si', lo so.


maiuscole e minuscole.
Ah. OK, *ora* capisco. Quella particolare obiezione del precedente post
considera che me la sia rimangiata :-)
Leonardo d'accordo


 [1] si', si', lo so.
Ah, ecco... :)


completamente le ambiguita`.
Ti servirebbe un segno in piu' per indicare la pausa.
	Una vecchia (pausa) porta la sbarra
	Una vecchia porta (pausa) la sbarra
Leonardo


l'alluminio trasparente...
Soprattutto tastiera :-)
Mi pare che dopo aver tentato di usalo come microfono, si sia dimenticato
del mouse, almeno in base al rumore in sottofondo :-)
Alessandro.

 E come già dimostrato si abbatterebbero le prestazioni. Bella mossa.
Dimostrato da chi? Io ero giunto alla conclusione che bastava tener conto
nella noncasesensitivity nella ricerca e si rimaneva nello stesso ordine di
complessita' (sia in assenza di indicizzazione che con l'uso delle hash
table).
Alessandro.

 l'usabilità che l'intuitività.
Dipende... Bisogna valutare, a seconda delle situazioni, se
sia meglio un'interfaccia utilizzabile senza pratica, ma
magari meno efficiente, od un'interfaccia meno immediata, ma
utilizzabile con maggior proficuità a seguito di un certo
apprendimento. Poi, non è detto che sia possibile, se riesci a
renderla immediata e ben utilizzabile... otterrai il massimo.


 esperimenti)
Bah, tutto ciò mi lascia perplesso, comunque... :-)


 (tra l'altro se non sbaglio, NTFS su win2000 č
case-sensitive
Sě, mi pare anche a me.


 nulla (ne' delle GUI in generale), ha poche possibilita'.
Io sono convinto che non sia cosě. Per tentativi, per caso,
per rabbia, prima o poi qualcosa ottieni. Da una shell
testuale nulla.


 un certo punto.
Una GUI fornisce, per costruzione, più informazioni di una CLI, di 
conseguenza si può più facilmente *dedurre* cosa fare, anziché doverlo 
studiare.


 table).
Siccome un filesystem CS non tiene conto della non case sensitiviness - 
altrimenti non sarebbe un FS CS - si ha l'abbattimento delle 
prestazioni: implementare una open() CI come wrapper ad una CS forza la 
linearizzazione dell'algoritmo di ricerca utilizzato dal FS sottostante, 
qualunque sia.



No, se vuoi e' solo questione di tempo.
Una shell ben fatta, che ti dia suggerimenti (gui o non gui), ti
permetterebbe ugualmente di cavarne qualcosa.
Di certo, le shell non sono usualmente concepite per chi comincia da zero,
ma non e' questione di GUI o CLI.
Alessandro.

 Sono quattro nozioni messe in croce, per *venire a conoscenza* delle
 > quali basta una sfogliata del manuale.
Se un po' contraddittorio, non ti pare?-)
Alessandro.

 qualunque sia.
Ti ricordi di me? Son quello che ha detto che in assenza di indicizzazione
la ricerca e' comunque lineare (sia per CS che CI) e se indicizzi basta che
calcoli le chiavi sulla versione CI della stringa da indicizzare.
E' sbagliato?
Alessandro.


Per nulla: sono 4 paginette nel manuale di AmigaOS.
Putroppo non posso sapere con certezza cosa sarebbe successo se non 
avessi letto il manuale, siccome l'ho letto, ma posso con sicurezza 
affermare che non mi ci sarebbe voluto molto per capire a cosa serviva 
il tasto sinistro, quello destro, e a come trascinare gli oggetti sullo 
schermo: basta provare e vedere che succede, dopo di che dedurre.



In teoria no, in pratica si, siccome non esiste alcun filesystem che non 
indicizza, ed i filesystem CS indicizzano sulla versione CS della 
stringa, altrimenti non sarebbero CS.



Se non puoi farlo fare al file system, e se la caduta di prestazioni lo
giustifica, nessuno ti impedisce di indicizzare in userspace (magari con un
demone che di risoluzione dei path).
Alessandro.


Cioè stai proponendo di riscrivere un altro filesystem sopra al 
filesystem già esistente?
Spero tu stia scherzando.


Spero tu stia scherzando.
Non l'intero file system, solo il meccanismo di risoluzione dei path e
qualora lo si ritenga necessario. Il demone si potrebbe limitare a tradurre
il path CI in CS e poi passato al FS.
Non e' un'ipotesi che io caldeggi, perche' a me il FS sta bene CS, ma se si
volesse fase CI su CS non credo che le performance siano il problema.
Alessandro.

 simile prima.
il mio primo computer e' stato un mac lcIII.
mai usato altro prima. In bundle c'era una applicazione che si chiamava 
"benvenuto" e un manualetto di pochissime pagine.
In 1 ora sapevo quello che era necessario sapre per lavorare.
Una sola ora!!
ciao
Marco

 qualunque sia.
Mi è capitata tra le mani l'ultima edizione del Tanenbaum, e parlando di NTFS
in win 2000 scrive proprio:
"NTFS fully support case sensitive names (so foo is different from FOO [...])
Unfortunately, the Win32 API does not fully support case-sensitivity for
file names and not at all for directory names ..."
Quindi, a meno di una svista di Tanenbaum - non ho altre fonti - anche NTFS è 
CS, seppur CI in user space. Eppure non si ha l'impressione di complessità
lineare nelle ricerche.
-- 
Rd
"I libri dovrebbero stare incustoditi nei posti pubblici e spostarsi
insieme ai passanti che se li portano dietro per un poco [...] strappati dai
bambini per farne barchette, insomma ovunque dovrebbero morire tranne che di
noia e di proprietà privata, condannati a vita in uno scaffale."

 renderla immediata e ben utilizzabile... otterrai il massimo.
In teoria sì, però mi sembra irrealizzabile. Qualsiasi rappresentazione
simbolica della realtà è astratta e non intuitiva. Tanto più è potente e in
grado di riprodurre la realtà, tanto più è lontana dalla realtà stessa. 
Pensa all'algebra. Cosa c'è di meno intuitivo di ax+bx/c+d? I bastoncini o il
pallottolliere sono intuitivi.
Eppure con la prima rappresentazione, lontanissima dall'intuizione, puoi
rappresentare tutto o quasi, con la seconda, comprensibile a un bambino,
sei limitato.
Pensa al linguaggio stesso, inteso come lingua madre. E' la cosa più
complessa che apprendiamo e che mai apprenderemo. Talmente complessa che
tutti gli sforzi di formalizzarne la genesi e le strutture sono stati in 
qualche modo vani o limitati (si è citata la grammatica generativa di Chomsy,
in qualche msg).
Non ce ne rendiamo conto perchè lo apprendiamo per gradi e in tutta calma, 
chi prima chi dopo. 
Forse i miei esempi sono un po' estremi, però credo che anche su piccola
scala il principio non cambi. 
L'intuitività prima o poi va a cozzare contro l'usabilità, e la seconda alla
lunga paga. (questo non significa certo che allora bisogna essere criptici e 
complicati per forza :-)


 studiare.
Senza dubbio. Se la mettiamo proprio da un punto di vista "tabula rasa",
credo anche che ci sia anche un non trascurabile aspetto ludico nella cosa. 
Provare a schiacciare un po' di bottoni a caso su un'immagine più o meno 
gradevole e vedere cosa succede può essere divertente. Accetti anche dei
fallimenti, tanto qualcosa succede, e piano piano capisci che se schiacci
lì si chiude, e così via.
Un prompt che più che stampare "command not found " qualsiasi cosa tu
schiacci, ti fa passare la voglia al secondo tentativo. 
C'è da dire che anche cose che ci sembrano scontate e intuitive in una GUI,
lo sono meno di quello che pensiamo. Io per esempio ho notato che per molte 
persone la riduzione di una finestra a barra sulla taskbar è fonte di 
interrogativi ed evidente confusione (dov'è? L'ho chiusa? No. E allora cosa
devo fare?). E' buffo, ma l'ho notato più di una volta. Ovviamente poi
capiscono il meccanismo, però non così rapidamente come ci si aspetterebbe,
o cmq ti danno l'impressione di non essere molto convinti della dinamica di
questa trasformazione. 


 lineare nelle ricerche.
"non si ha l'impressione"? Prova a fare benchmarks, e poi vedi.
Ho già mostrato perché è così: non credo che le impressioni valgano più 
dei fatti. O sbaglio?


 questa trasformazione. 
Questo significa solo che l'iconizzazione non è una cosa "intuitiva". 
Se, d'altro canto, l'iconizzazione non fosse istantanea, ma fosse 
accompagnata da un'animazione che visibilmente riduce le dimensioni 
della finestra a quella di una icona sul desktop o una voce in un menu, 
allora la questione diventa differente, e sfido chiunque a non capire 
cosa sia successo.


 dei fatti. O sbaglio?
E' cosi' come? Se mi dici che e' piu' pesante sono d'accordo, se dici che e'
computazionalmente piu' complesso, non e' vero.
Alessandro.

 Questo significa solo che l'iconizzazione non è una cosa "intuitiva".
Ma dimostra anche che l'intuitivita' non e' solo questione di GUI o CLI, ma
di come e' costruita l'interfaccia utente.
La shell non e' intuitiva, ma non ci prova neanche perche' non e' stata
progettata per questo.
Io credo che sarebbe possibile costruire una shell intutiva anche usando
CLI, ma per le shell normalmente si privilegiano altri aspetti, lasciando
alle altre applicazioni (siano esse CLI o GUI) questo compito.
Alessandro.

 computazionalmente piu' complesso, non e' vero.
Altroché se è vero. Vuoi anche negare l'evidenza, adesso?


 progettata per questo.
E che significa?


 comincia da zero, ma non e' questione di GUI o CLI.
Lo è, perché una shell testuale può dare solo un minimo di
suggerimenti. Immaginati se ogni volta che sbagli a scrivere
un comando uscisse fuori tutta una pappardella su come
utilizzare la shell...


 In teoria sì, però mi sembra irrealizzabile.
Non saprei, non ne sono del tutto convinto. Secondo me, su
questo aspetto dello sviluppo del sw (che è oltretutto uno dei
meno tenuti in considerazione, soprattutto su Unix), si
possono fare ancora molti passi avanti. e secondo me ci
potrebbero aspettare certe sorprese.


 fornisce piů informazioni.
Su questo sono d'accordo. E' palese. Prima volevo solo segnalare che anche
apprendere a usare *correttamente* una GUI, per soggetti poco portati all'
interazione con una macchina, puň richiedere un aiuto esterno. Ho visto persone
spostare finestre o chiudere e riaprire applicazioni piuttosto che
iconificarle. 
Poi č incontestabile che sia piů semplice capire quelle 2 o 3 dinamiche che
imparare dei comandi. 
-- 
Rd
"Quando vedi la luna circondata da un alone, c'č un re che viaggia da qualche
 parte in quel chiarore."

 dei fatti. O sbaglio?
vedi risposta di test. Dovrebbe essere possibile mantenere l'indicizzazione
senza quindi abbattere le prestazioni nel caso medio. Cosa poi facciano in NTFS non
ne ho idea. 
Cmq sono d'accordo che rendere possibile la scelta della case-sensitivity o meno, 
fatti 2 conti non sia una buona idea, più complesso da implementare per
ottenere il risultato di confondere ancora di più l'utente, che un giorno si
trova su una macchina CS e un altro su una CI
-- 
Rd
"Quando vedi la luna circondata da un alone, c'è un re che viaggia da qualche
 parte in quel chiarore."

 cosa sia successo.
Sì però così credo che diventerebbe molto fastidioso, una volta capito il 
meccanismo :-)



Basterebbe che ti suggerisse come ottenere la guida in linea.
E poi se la si volesse rendere intuitiva l'utente non dovrebbe digitare
comandi ma scegliere opzioni, o rispondere a domande, per esempio.
Alessandro.

 E che significa?
Che non puoi darle colpe che non ha ;-P
Alessandro.

 Altroché se è vero. Vuoi anche negare l'evidenza, adesso?
Non ne avevamo gia' parlato?
Alessandro.


Argomenta tu, ma spiega bene perchè _togliere_ possibilità all'utente
sia un aumento della sua libertà.
Dubito che ci riuscirai, a meno di non inventare argomentazioni
fallaci.
-- 
Renato "Hitman" Salzano | web site: 
http://spazioweb.inwind.it
GdG #6 / Fan di Mexico '86 #2 / Transbassista dei 2ofSpades
"All'altare dei miei sogni hai bruciato un sogno in più/se penso che
 la nostra storia l'hai voluta tu/dovevo dirti di no" - V.Giovagnini


Perchè hai l'idea che la UI/Shell sia un oggetto insostituibile. Il
fatto che il FS sia CS permette di avere con facilità sia UI/Shell CI
che CS. Poi l'utente si sceglie quale usare, avendo maggiore libertà
di adattare il proprio sistema alle _proprie_ esigenze.



Come detto, l'intuitività non è un problema di competenza dei FS. I FS
hanno altri scopi, che con l'utente non c'azzeccano nulla.


 generale di questo.
Ma che dici? I metadati sono informazioni addizionali, come "Autore",
"Tipo", "Versione", "Mittente", "Formato". Il nome resta quello che è.
Un filesystem con metadati non ti permette di avere un nome di file
analogo a "<FONT COLOR='red'>P</FONT><FONT FACE='times'>i</FONT>ppo".
Altrimenti cita il nome di anche uno solo dei filesystem che ne sia
capace.
-- 
 Perfection is attained not when there is no longer anything to add,
 but when there is no longer anything to take away (A. de Saint-Exupery)
 Rudi Chiarito                                            
ru...@amiga.com

 rispondere a domande, per esempio.
Certo, ma ciò non toglie che la shell attuale *non* lo sia.


 Rimangono qualche decina di milioni di persone.
Sentite, chi a chi bisogna rivolgersi per far internare un pazzo, visto 
che i manicomi sono chiusi?


 UTENTE E' LIBERO DI SBAGLIARE. ED E' UNA DISCUSSIONE GIA' SENTITA.
a voler essere capziosi, anche i filesystem simil-unix impongono una
limitazione: un nome di file/directory non può contenere né slash né
caratteri zero. ammesso che il filesystem sia invisibile agli utenti
(principio che sottoscrivo, ma che purtroppo non corrisponde affatto
alla realtà dei sistemi odierni) in questo caso si limitano comunque
i nomi a disposizione dei programmi. ;) alcuni sistemi operativi per
mainframe usavano e - nel caso di ibm - credo usino tuttora stringhe
binarie per indirizzare file.
p.s.:
il tuo stile fa molto cicerone. io oggi mi sento bauhaus. sarà forse
questo tempaccio da svagellà.


a voler essere capziosi, anche i filesystem simil-unix impongono una
POSIX.
-- 
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.bofh.it

 vantaggi.
I vantaggi sono in fase di acquisizione ed infatti è giusto scrivere
come si scrive ora. Da qui a fare lo stesso con i nomi di file si
tratta di un altro paio di maniche, essendo le situazioni diverse. Se
un paio di guanti da giardiniere sono perfetti per le rose non vuol
dire per forza che sia una buona idea usarli in chirurgia cardiaca...


 utenti di ripartizionare il disco. forse usava un sistema analogo?!?
UMSDOS.


 No, usava umsdos che è un layer POSIX sopra FAT.
Appunto.


E come gią dimostrato si abbatterebbero le prestazioni. Bella mossa.
"Abbattere" le prestazioni, addirittura! Ohibo'!
Vediamo, quante fopen(...,'w') faro' sul mio sistema? E' un server, ha
circa mille utenti simultanei... voglio darmi limitazioni ragionevoli,
e supporro' che ogni utente apra non piu' di dieci documenti Word ogni
minuto, senza mai fermarsi per pranzo o andare in bagno.
Ci saranno zilioni di altri files aperti in _lettura_ - ma questi, non
ci interessano.
Quindi siamo a diecimila creazioni di files al minuto... penso che non
si possa negare che questo sia il carico di lavoro tipico d'un sistema
medio. Lo dovro' dotare di un Ultra SCSI e di dieci giga di RAM, se no
m'affoga, anyway...
Dunque, il processore centrale che tiene su i dieci giga di RAM, RAID,
e altra fuffa, e' un baldanzoso Pentium 75 MHz.
Cambiare l'istruzione
	call	fopen_raw
in
	push	bx
	mov	bx, ds:[handler]
	call	bx
	pop	bx
che e' poi tutto quello che si deve fare, mi costa 11 microsecondi.
Ma, attenzione! - l'abbattimento e' ancora piu' drastico: infatti, non
stiamo parlando di 11 microsecondi cosi' alla vole', ma di *DIECIMILA*
volte tanto in un minuto, i.e. ben 110 millisecondi ogni minuto.
Dopo la tipica giornata di lavoro in cui sono stati creati (o comunque
modificati e _salvati_) quasi cinque milioni di documenti Word, scopro
di aver perso ben cinquantatre' secondi.
Due scelte drastiche mi si parano davanti: riscrivere il file system o
passare al Pentium 90?
+++
In realta' tutto cio' e' risibile, perche' anche nei file systems case
insensitive, esiste il problema di i18n (charset); e percio', anche su
quei sistemi, la routine non e' la versione ottimizzata n. 1, ma ha, a
monte, uno stadio di filtro che usa un array di traduzione. Bastera' a
runtime allargare di 26 posizioni l'array di traduzioni ed ecco che il
file system diventa automagicamente case insensitive.
Certo, il costo di traduzione, con le look tables piu' ampie, aumenta;
puo' essere che per riuscire a mantenere quei cinque megafiles al di',
uno debba upgradare anche al Pentium 100. Se lo trova, s'intende.
Leonardo
-- 
Microsoft Outlook: il primo news reader con supporto messaggistica RAID 1.

stringa, altrimenti non sarebbero CS.
Appunto; la mia posizione e' che un file system CS puo' essere reso CI
a runtime, magari all'installazione. Da quel momento in poi, indicizza
in CI, come diceva <test>, e la "perdita di prestazioni" e' risibile.
Cosi', con lo stesso FS, chi lo vuole CI ce l'ha CI, e chi lo vuole CS
ce l'ha CS.
Certo, passare dall'uno all'altro sara' un po' scomodo, visto che ogni
indice andra' rigenerato. Costera' quanto uno scandisk. E c'e' il caso
che compaiano collisioni sul namespace ridotto; risolubili dall'utente
se lo vorra', o in automatico.
D'altra parte, il fatto che se lo possa vibrare sulle balle non e' una
buona ragione per non dare un martello ad uno scultore :-)


questo tempaccio da svagellà.
Probabile :-)


Certo, ma ciň non toglie che la shell attuale *non* lo sia.
La shell della bash. Non per esempio quella di AS/400 (che e' ostica
per altri versi, senza dubbio).


 file system diventa automagicamente case insensitive.
Certo certo... facci vedere come si fa.


 in CI, come diceva <test>, e la "perdita di prestazioni" e' risibile.
uh? Che significa può essere reso CI a runtime? Un FS CS indicizza in 
modalità CS, altrimenti non è CS, punto e basta. Se lo fai indicizzare 
in modalità CI non è più CS. Trasformare a runtime un FS CS in uno CI, 
senza perdita di prestazioni, *non* è possibile per le motivazioni da me 
già riportate.


 e' ostica per altri versi, senza dubbio).
Non parlo di cose che non conosco...


già riportate.
Si', "con perdita di prestazioni zero" in effetti e' impossibile. Io
sostengo pero' che esista una "perdita di prestazioni accettabile" e
identifico (io) tale perdita come un "rallentamento inferiore ad una
parte su centomila".
La legge di Amdahl mi assicura che avere un FS polimorfico, anche in
casi abbastanza estremi, non mi crea perdite di prestazioni tali che
superino l'accettabilita'.


 superino l'accettabilita'.
Forse non ci siamo capiti: mi spieghi perché esistono algoritmi di 
ricerca con complessità inferiore a O(n), e perché ci si prodighi tanto 
per ideare FS che li sfruttano, se poi li si linearizza con un wrapper CI?


Certo certo... facci vedere come si fa.
Leonardo


 FS_IS_CS, usi page00, e quando no, usi una neonata "page00ci".
Come detto, tutto ciò va bene per FS che già usano una ricerca lineare 
di loro, e comunque richiede la modifica dei FS stessi.


 per ideare FS che li sfruttano, se poi li si linearizza con un wrapper CI?
Ma il wrapper CI lo usi solo con la UI, cioe`
solo con le persone che vogliono questa condizione.
In tutti gli altri casi il wrapper non c'e`.
Dato che un utente non apre 10.000 file al
secondo, mentre magari un applicativo si,
il problema delle prestazioni e` ininfluente.
In tutto il discorso stiamo sovrapponendo il
concetto di FS, con i suoi problemi prestazionali,
con il concetto di UI, con i suoi problemi
di "intuitivita`".
A mio avviso sono cose che andrebbero distinte.
bye,
-- 
  Piergiorgio Sartor

 solo con le persone che vogliono questa condizione.
1) Non è quello che Leonardo auspicava (lui vuole cambiare tutte le
    funzioni che maneggiano nomi di file)
2) Come risultato avresti un sistema totalmente incoerente, con
    applicazioni che possono ancora leggere/scrivere in CS, con la
    conseguenza che alcuni file potrebbero non essere accessibili in
    modalita CI


     modalita CI
Dipende da cosa ci fai.
Un server web, magari, puo` avere un certo
tipo di configurazione (CS), una macchina
desktop un'altra (CI).
La distinzione potrebbe essere per directory,
per esempio, oppure altro.
Stiamo elucubrando su cose, senza aver
specificato quali siano i requisiti che
vogliamo ottenere.
Il discorso della UI che vede i file CI, si
applica solo nel caso vi sia una UI...
bye,
-- 
  Piergiorgio Sartor


Nessuno ci costringe a linearizzare solo per usare il CI.
Gli stessi algoritmi per il CS possono essere adottatti per il CI.
Alessandro.


Mi sembra di parlare al vento... Quello che dici non può avvenire se non 
si modifica il FS, ovvero se non si rende il FS CI.



Ho la stessa impressione. :-)
L'idea era quella di un demone userspace che si occupa della risoluzione dei
path che e si gestisca una sua hash table.
Alessandro.


Non funzionerebbe, non può funzionare. Cosa fa esattamente questo 
demone? Come lo fa? Spiega a parole tue, poi capirai perché non può 
funzionare.


 può funzionare.
L'unico motivo per il quale potrebbe non funzionare bene quanto dici tu e'
quello nel caso in cui il file system memorizzi le hash table su disco.
Ci sono dei file system che fanno questo?
Se e' cosi' puoi fare dei nomi?
Se no dammi un indizio perche' non mi piace tirare a indovinare.
Alessandro.

 Se no dammi un indizio perche' non mi piace tirare a indovinare.
Ti ho chiesto di spiegare, a parole tue, come funzionrebbe questo demone 
e cosa dovrebbe fare esattamente. Provaci, vedrai che non può funzionare.


 e cosa dovrebbe fare esattamente. Provaci, vedrai che non può funzionare.
Come gia' detto il demone gestisce una hash table in cui la chiave viene
calcolata sulla versione maiuscola del path ed il valore ad essa associato
sara' il path CS corrispondente.
Al'inizio la hash table e' vuota.
Per ogni richiesta di risoluzione del path si calcola la chiave sulla sua
versione maiuscola del path da risovere e si verifica se c'e' un valore gia'
inserito nella cache per quella chiave.
- Se c'e' il valore si tenta di aprire il path CS cosi' ottenuto. Se ha
successo viene restituito il valore che era memorizzato nella hash table,
altrimenti viene rimosso dalla hash table e lo si risolve come se non fosse
stato presente nell'hash table.
- Se non c'e' questo valore il path viene risolto con l'algoritmo da te
presentato qualche tempo fa. Una volta risolto il path si calcola la chiave
sulla versione maiuscola del path e si inserisce per quella chiave il valore
del path CS cosi' ottenuto che poi viene restituito come risultato.
E' abbastanza?
Alessandro.


Dovrebbe essere abbastanza per farti capire che o non può funzionare o 
non è per nulla efficiente come tu credi sia, ed il motivo consiste nel 
fatto che, per funzionare correttamente, l'approccio da te suggerito 
richiede che un file venga aperto sempre due volte, dimezzando, 
pertanto, le prestazioni del filesystem. Ti spiego perché.
Avere una cache di nomi di path già risolti, permettendo che comunque le 
applicazioni possano ancora creare file in modalità CS, solleva problemi 
di coerenza che devono essere affrontati, come tu stesso dici, provando 
ad aprire il file usando il path trovato in cache, ma siccome non c'è 
garanzia che il file abbia ancora quel nome, bisogna contemplare la 
possibilità di dover ricercare il file e rimettere il suo nome nella cache.
Ora, tu potresti dire che questa è un'eventualità che si presenterebbe 
molto raramente, e su questo hai ragione, ma ciò non toglie che il 
demone dovrebbe comunque cercare di aprire il file, il che significa che 
il file viene aperto due volte: una dal demone, e l'altra 
dall'applicazione, questo perché il demone non può aprire il file per 
conto dell'applicazione, per cui tutto quello che può fare è passare il 
path giusto all'applicazione, previa verifica della sua validità, che 
implica l'apertura del file.
inoltre tu sembri non considerare affatto l'overhead dovuto all'IPC 
necessaria per comunicare con il demone, nè il fatto che questa 
soluzione consuma più memoria di un semplice FS CI. Alla fine avresti 
che sarebbe più veloce fare direttamente ogni volta la ricerca lineare 
del file.



La mia obiezione riguardava *solo* la necessita' di linearizzare la ricerca nel
caso si volesse implementare CI su CS. Tu obietterai che la risoluzione dei
path non in cache e' comunque lineare, ma lo e' per molti file-system in
circolazione.
Sul fatto che poi sia piu' pesante siamo d'accordo.
Ho qualche dubbio circa leffettivo impatto di questo appesantimento per
le prestazioni globali del sistema, specie per le applicazioni interattive,
ma su questo non mi sento di discutere.
Ciao.
Alessandro.


"non mi sento di discutere" vuol dire non "non insisto" :-)
Alessandro.

per ideare FS che li sfruttano, se poi li si linearizza con un wrapper CI?
Questa e' un'altra domanda, e merita una risposta differente.
La risposta alla domanda e': non lo so; e io non userei mai un wrapper
CI perche' anche a me pare non avere senso; e farei in un altro modo.


di loro
No, il metodo con uni2charset() va bene per tutti, pero' fa nascere quel
problema di cui si diceva, se la stessa directory contiene Readme con il
suo omologo README.
In quel caso o si mette un ulteriore check a fopen(...'w') e rename() in
modo da renderlo impossibile, oppure ci vuole un "case clash bit" dentro
_ogni_ directory.
E' fattibile, e prestazionalmente non e' il massacro che pareva.
Suggerirei di chiamare quel bit "Insensitivity Quandary"... se un utente
ha IQ nullo, avra' problemi; se ha un IQ diverso da zero, no.
Cio' semplifichera' anche le chiamate dell'help desk.
"Non le apre il file, eh? Ma lei che IQ ha?"
"Zero"
"Ahiahiahiahiahiahiahiahià!"
