Uno spazio dei nomi per i comandi UNIX

[TheSnowBoarder]

ma che ve frega dei nomi?......... ma che ve frega della gente che si allontana solo perhce' invece di chiamarsi msn si chiama gaim? se e' per sto motivo meglio che non utilizzi linux......

Ma che tristezza leggere queste parole !

Ma secondo voi per quale ragione Gates è diventato il più ricco del pianeta ?
Perché Gates a queste cose ci pensa !, e sono cose importanti !
MSN Messenger ha un nome chiarissimo:
anche uno che non ha mai acceso un computer potrà capire da subito che potrà comunicare; GAIM, a prima vista, non vuol dire nulla.

Per favore, usciamo dalla mentalità secondo cui un sistema GNU / Linux debba essere usato solo da una cerchia esoterica di conoscitori informatici: se continuamo a dire di queste stronzate ci facciamo del male da noi stessi !

/var/log/ è ok, qual è il problema?

I nomi di questi file di log ti sembrano seguire una qualche convenzione ?
A me sembra un'accozzaglia .....

Codice: Seleziona tutto

myself@amd-debian:/var/log$ ls
aptitude             fontconfig.log           news
auth.log             gdm                      nvidia-installer.log
base-config.log      kern.log                 samba
base-config.timings  ksymoops                 scrollkeeper.log
btmp                 lastlog                  syslog
cups                 localization-config.log  user.log
daemon.log           lpr.log                  uucp.log
debian-installer     mail.err                 wtmp
debug                mail.info                XFree86.0.log
dirmngr.log          mail.log                 XFree86.0.log.old
dmesg                mail.warn                XFree86.20.log
exim4                messages                 XFree86.20.log.old

Ho programmato con entrambi i linguaggi, anche se a C++ ho dedicato poco tempo. Java invece lo uso quasi quotidianamente.

E allora conoscerai sicuramente le eleganti convenzioni che legano il nome di qualsiasi cosa: Package, Classe, istanza di classe.
Addirittura in Java ciascuna classe non solo è identificata dal proprio nome qualificato, ma vi è una corrispondenza biunivoca tra il nome stesso della classe e la directory in cui verrà a trovarsi il binario della classe stessa. Perciò com.pippo.Dvdplayer sarà com/pippo/Dvdplayer.class .

Queste convenzioni sui nomi sono state create da sun e mi sembrano raffinatissime e piene di logica. Per quale ragione sollevare una problematica sui nomi sembra a molti una "questione di lana caprina" ?

[gallows]

anche uno che non ha mai acceso un computer potrà capire da subito che potrà comunicare; GAIM, a prima vista, non vuol dire nulla.

Continuo a non essere d'accordo, a prima vista trovi scritto "Gaim Internet Messenger", cosa vuoi di più?
Addirittura kde (correggetemi se sbaglio) nel menu da la descrizione del programma del tipo «Web Browser» «Client di Posta» ecc..

I nomi di questi file di log ti sembrano seguire una qualche convenzione ?
A me sembra un'accozzaglia .....

A me no, si capisce al volo a cosa si riferiscono.. cos'è che non va?

Per quale ragione sollevare una problematica sui nomi sembra a molti una "questione di lana caprina" ?

Io te l'ho spiegato, secondo me è un falso problema. Un utente esperto sa come si chiamano i programmi, ad un utente poco esperto non interessa, ha il suo bel launcher che fa tutto. (Ovviamente anche un utente esperto può avere il launcher eheh).

[Firetux]

concordo con quanto appena detto da Gallows...ti assicuro che ho provato a far usare linux a gente che di computer non ne sa proprio niente ed è riuscita tranquillamente ad aprire tutti i programmi che gli servivano!

[useless]

il giorno che mi trovo anche solo la nomenclatura di java nel mio sistema mi impicco.

[TheSnowBoarder]

E allora prepara la corda,
perché secondo molti Java è il futuro

[useless]

be', il fatto che msdos/windows sia diventato il futuro schiacciando unix/macos/amigaos, il fatto che l'x86 abbia schiacciato i 680x0... effettivamente mi suggeriscono che sarà così. la soluzione peggiore è sempre quella che sopravvive!

[TheSnowBoarder]

be', il fatto che msdos/windows sia diventato il futuro schiacciando unix/macos/amigaos,

Lasciami dire che hai detto delle assurdità pazzesche !

Cominciamo intanto con la disputa msdos / windows:
ms-dos e windows sono due cose distinte; anzi, più di due.
Fino a Win95 ms-dos era effettivamente il cuore del sistema operativo; windows era solo il sistema grafico.
Con Windows 2000 le cose cambiano radicalmente; Windows 2000 viene scritto sulla base di Windows NT, e non bisogna assuolutamente scordare che Windows NT è stato scritto assolutamente da zero; non ha più alcun legame con il codice di MS-DOS.
Senza prendere le difese delle successive versioni di Windows, voglio spezzare un'asta in favore di MS-DOS.

MS-DOS nasce per equipaggiare il primi personal computer della IBM, e a quell'epoca i pc erano davvero "personal": il tuo pc, punto e basta; internet, come la conosciamo oggi, non esisteva. Sono dell'idea che MS-DOS è stato l'OS giusto nel momento giusto. Tu avresti messo uno UNIX su un 286 ?

UNIX nasce dando per scontata la multiutenza, con tutto quello che questo comporta, e non è assolutamente poco. Figurati che il primo processore su cui Torwalds cominciò a scrivere Linux fu il 386, proprio perché il 386 introduceva nella famiglia x86 delle caratteristiche hardware che rendevano possibili implementare un sistema UNIX; prima non sarebbe stato possibile. Gestire un sistema multi-tasking con un 8086 ? Impossibile. MS-DOS, per l'epoca andava più che bene.

MS-DOS era un sistema "scarso" tagliato su misura per macchine "scarse", quindi era ottimo.
Il grosso errore della microsoft è stato quello di non dare un taglio netto con il passato quando l'hardware è cominciato a diventare più potente. Per i primi PC, un file system organizzato a partire da C:\ andava più che bene: i computer avevano un solo disco rigido, a volte neanche quello, quindi non c'era possibilià di confondersi. Al giorno d'oggi, mantenere un file system caotico e disomogeneo come quello di Win Xp è un assurdità.

Linux ha avuto la grandissima fortuna di trovarsi addosso l'eredità pluridecennale dei più importanti sistemi UNIX. Se non sbaglio, Linux viene scritto nel '91, ma UNIX esisteva già dal 1970. E le macchine su cui UNIX ha sempre lavorato sono state sempre le ferrari dell'epoca, dotazione di qualche azienda o grossa università; non certo 8086.

Il futuro è ancora tutto da decidere.
Se UNIX saprà evolvere restando coerente con la propria filosofia di fondo, sono fiducioso di vederlo anche fra i prossimi 15 anni.

il fatto che l'x86 abbia schiacciato i 680x0

Beh, dimentichi che Apple, prima ancora di migrare ai processori x86, aveva abbandonato i 68k per passare ai PowerPC.

la soluzione peggiore è sempre quella che sopravvive!

Argomentazione discutibilissima.
Linux sopravvive, vive e si evolve. Fa schifo ?

Java sarebbe la soluzione peggiore ?
Java ha sicuramente diverse scelte discutibili, ma la sua impalcatura è estremamente coerente ed elegante.
Dire che proprio Java sia al momento la soluzione peggiore mi sembra parecchio fuori luogo, tantissimo.

Secondo me Java ha delle soluzione geniali.

Portami delle motivazioni tecniche per le quali Java fa schifo, poi magari ne riparliamo.

[Firetux]

Portami delle motivazioni tecniche per le quali Java fa schifo, poi magari ne riparliamo.

...se vuoi delle motivazioni di useless "contro" java basta che ricerchi nel forum...ne trovi di roba!

[useless]

il problema principale di java è la lentezza. e che nessuno dica che non è vero. java è un chiodo. certo, questa cosa ha i suoi motivi, ma siamo sicuri che i pro di java valgano il prezzo della lentezza e pesantezza che questo si porta dietro? è un'impalcatura mostruosamente grande, che la maggior parte delle volte viene utilizzata in minima parte, e quindi se ne potrebbe fare benissimo a meno. quando discuto di questo con qualcuno, la cosa che mi sento rispondere in 9 casi su 10 è: "ma java ha già un mucchio di cose (liste, thread, interazione db, parsing xml, tanto x citare alcune caratteristiche), è tutto pronto, devi solo usarlo!". ora... avete mai provato glib? be', glib porta nel C/C++ tutto ciò che java ha ed è di comune utilizzo, ed è pure rilasciata sotto LGPL, il che la rende perfettamente utilizzabile anche x il sw non libero. a questo punto mi si dice "java è + facile". ma + facile x chi!? x un avvocato? x un economista!? ma questi non devono mica programmare, chi deve programmare è qualcuno che deve essere specializzato nel fare questo, e quindi può benissimo essere obbligato ad impararsi il C/C++, cosa da cui sicuramente guadagnerebbero sia il sw stesso che i suoi utenti. ma poi, diciamocela tutta: è davvero + facile fare:

Codice: Seleziona tutto

java.text.NumberFormat formatter 
   = java.text.NumberFormat.getNumberInstance();
formatter.setMinimumFractionDigits(2);
formatter.setMaximumFractionDigits(2);
String s = formatter.format(x);
for (int i = s.length(); i < 10; i++)
   System.out.print(' ');
System.out.print(s);

piuttosto che:

Codice: Seleziona tutto

printf("%10.2f", x);

? (vedere http://www.horstmann.com x maggiori info ).

il punto è che si cerca di far passare java x la panacea di tutti i mali programmatori, ma nessuno si preoccupa di guardare se ci sono alternative. (e già che ci sono, non ditemi che solo in java le gui si fanno comodamente, xké gtk+ e qt non hanno nulla da invidiare, anzi... e non parlatemi nemmeno di portabilità, xké C/C++ scritti con un po' di senno sono 99% portabili. non a livello binario, d'accordo, ma quanto viene usata questa caratteristica di java?).


quanto al discorso msdos/win, niente da obiettare, è tutto sensatissimo, x carità, ma non mi hai detto cosa avevano in + l'amiga o il mac che gli permetteva di avere OS decisamente migliori e con moooolte meno limitazioni (pensate ai 640kb, pensate al monotasking, pensate ai filename 8+3 caratteri, pensate al solo testo...). è vero che alcune di queste costrizioni erano dovute alla macchina stessa su cui girava msdos, ma allora... perché non è morta quell'architettura e sono sopravvissute le altre? amiga, in particolare, era avanti di 20 anni (pensate ai chip custom dedicati a grafica e suono... non è esattamente quello che avviene sui pc oggi?), ma è morto .

insomma, non volevo scatenare chissà quale battaglia, volevo solo fare notare che quel che abbiamo oggi non si è evoluto da ciò che c'era di migliore prima, e io, sinceramente, non capisco xké!

[Harp]

Si capisce il perchè, si capisce!
Anche troppo bene purtroppo.

[TheSnowBoarder]

il problema principale di java è la lentezza. e che nessuno dica che non è vero.

Su questo non si discute.

quando discuto di questo con qualcuno, la cosa che mi sento rispondere in 9 casi su 10 è: "ma java ha già un mucchio di cose (liste, thread, interazione db, parsing xml, tanto x citare alcune caratteristiche), è tutto pronto, devi solo usarlo!". ora... avete mai provato glib? be', glib porta nel C/C++ tutto ciò che java ha ed è di comune utilizzo, ed è pure rilasciata sotto LGPL, il che la rende perfettamente utilizzabile anche x il sw non libero.

Anche qui concordo con te, ma il problema è dato dai "programmatori", non dal linguaggio; nelle librerie standard del C e del C++ ci sono un casino di funzioni e template. Ciascun sistema GNU viene fornito con gli header file e i binari di qualsiasi libreria desiderabile al mondo, se poi la gente motiva la propria scelta di usare Java per le ragioni che tu citi vuol dire che non conosce il resto.

a questo punto mi si dice "java è + facile". ma + facile x chi!? x un avvocato? x un economista!?

Più che facile, io direi "molto più sicuro".
In un programma C/C++ creare una vulnerabilità da buffer overflow è un attimo. Per non parlare poi del fatto che la gestione della memoria in C/C++ è pareccio complessa, così come "complessa" è la gestione di librerie rientranti.

Codice: Seleziona tutto

char * foo(void) ;

/* Questa funzione deve ritornare un char * 
 * quindi devo per forza usare un buffer allocato con malloc 
  
 * La funzione che verrà dopo dovrà decidere quando invocare
 * free() , e lì saranno problemi ....

oppure

Codice: Seleziona tutto

#include <stdio.h>
#include <stdlib.h>
#define BUFFER_SIZE 20 

int main(int argc, char **argv) {

FILE * printer; 
char * string; 

printer = fopen("/dev/lp0", "w" ); 
if (!printer) exit(1); 

while(1) {

string = (char  *) malloc( BUFFER_SIZE );  
puts("Inserisci una stringa, lettera X per uscire \n"); 
scanf("%s", string ); 
if ( *string == 'X') break; 
fprintf(printer, "%s", string ); 
}

}

Questo pezzo di codice è estremamente babbo: chiede ogni volta di scrivere qualcosa sulla tastiera, e poi lo stampa immediatamente sulla stampante. Per quanto babbo possa sembrare, presenta delle vulnerabilità gravissime:

1) - Ad ogni ciclo while viene allocato un buffer di 20 char, che però non vengono mai deallocati ! Questo crea un Memory Leak !

2) - Viene usata la funzione scanf, quindi nessun controllo sulle dimensioni del buffer; se l'utente inserisci 21 caratteri è già buffer overflow.

Questo codice che ho scritto è una cavolta, giusto per far vedere che anche quando si pensa di scrivere un codice corretto, basta in C una piccola distrazione per creare un potenziale disastro.

Creare vulnerabilità di questo genere nel proprio programma Java è impossibile: non ha senso preoccuparsi dell'allocazione della memoria perché a quello ci pensa il Garbage Collector. Non ha senso preoccuparsi di eventuali buffer overflow perché nel qual caso viene immediatamente sollevata un'eccezione ed il programma termina, togliendo quindi ai maligni la possibilità di inniettare codice in posti proibiti ed assumere il controllo della macchina.

Tutto questo non è poco !
Apprezzo di Java la già citate convenzioni sui nomi di Package, Classi etc.

Starei ancora a parlare di tante altre cose, ma non posso perché devo scappare adesso, alla prossima !

[useless]

Be', il bounds checking si potrebbe benissimo implementare anche in C (e in ogni linguaggio), semplicemente non si fa normalmente xké la sicurezza si paga con la lentezza. idem x la gestione della memoria: il garbage collector sarà comodo, ma si paga con la maggiore occupazione di memoria quando non serve.
sul codice rientrante in C non ci sono grossi problemi, basta stabilire qualche convenzione. ti garantisco che il paradigma OO si può tranquillamente utilizzare anche in C, sebbene questo non faciliti certo la cosa. x risolvere il problema c'è il C++ (che comunque è già + lento).

hai detto un'ottima cosa comunque: " il problema è dato dai "programmatori", non dal linguaggio". è sulla scia di quel che dicevo io, che nessuno di preoccupa di valutare le alternative alla "comodità" di java. xò il sw con questo ci rimette: azureus sarà bello e pieno di funzioni, ma è un chiodo mostruosoooooooooo! l'unico modo x renderlo decente credo sia compilarlo in codice nativo con gcj, ma allora si perde l'unico lato positivo che riconosco di java, ossia la portabilità dei "binari".

io penso che il programmatore non dovrebbe preoccuparsi della facilità o della (sua) comodità, ma di fare quello che fa in modo efficiente (e oculato). se in C è facile introdurre bachi di sicurezza, ci deve stare attento, e stop. peccato però che sembra che io vada controcorrente (e questo lo dico da quasi-ing. inf. che vede cosa finiscono a fare tutti i suoi colleghi neolaureati...) .