Microsoft rilascia dettagli e preview per WinFX [Archivio]

^-fidel-^

19-01-2006, 17:37

Inoltre... trovo simpatica l'idea di un desktop 3D, un po' meno simpatica l'idea
che con le schede video attuali usare un desktop 3D significa abilitare
l'accelerazione 3D anche per i contenuti desktop (e col 3D attivo i chips scaldano
e le ventole urlano...)

Non credo proprio, anzi... Sara' un grande vantaggio avere un desktop 3D, dal momento che l'hardaware delle nuove schede (da almeno tre anni a questa parte) e' composto al 98% da componentistica per il 3D e da un solo piccolo chip per il 2D...
In questo modo, sara' possibile sfruttare la potenza delle schede video anche con i normali programmi e non solo con i videogiochi.
Per quanto riguarda il riscaldamento... ok, scaldera' un po' di piu', ma non sara' mica come giocare a Call of Duty 2 !!! La cosa sara' impercettibile...

Non a caso, in ambiente Linux e Mac si sta gia' lavorando a questo progetto da circa un anno.

^-fidel-^

19-01-2006, 17:41

Ah dimenticavo...

Invece imho la convergenza di 2d e 3d (o meglio, la scomparsa del 2d) sarà un bene, in quanto a scrittura dei drivers.

Non mi risulta che i drivers centrino qualcosa. E' tutto un discorso di layer grafico gestito direttamente dal sistema operativo. Un layer ben fatto fornira' nuove funzioni API per le finestre 3D, e wrapper di conversione automatica 2D-3D per le vecchie applicazioni. Vedremo i signori Microsoft cosa sapranno fare :)

Adios

jedi1

19-01-2006, 17:45

No io voglio Windows con ologrammi 3d!

BlackBird77

19-01-2006, 17:58

Ormai ci sono arrivati tutti, il 2D va fatto sfruttando l'accelerazione della GPU, bisogna finirsela di ciucciare preziose risorse alla CPU...
Per quanto riguarda linux, beh... farebbero bene a guardare qua: http://www.amanith.org , che è pure crossplatform.

sirus

19-01-2006, 18:00

sempre più voglioso di provare il SO :)

^-fidel-^

19-01-2006, 18:07

Per quanto riguarda linux, beh... farebbero bene a guardare qua: http://www.amanith.org , che è pure crossplatform.

Emh mi sa che hai preso un granchio :eek:

Il progetto Amanith riguarda un framework per il disegno vettoriale che si appoggia ad OpenGl invece che alle librerie 2D di Xfree/Xorg, e non ha nulla a che vedere con il desktop 3D...

Pe maggiori informazioni sul progetto desktop 3D su Linux, andate sul sito della X.org foundation

http://www.x.org

^-fidel-^

19-01-2006, 18:25

Dimenticavo ancora per gli utenti Linux.
E' da tempo possibile avere effetti grafici avanzati per le finestre del desktop (come ad esempio trasparenza ed ombre) gestite direttamente dal server grafico. Basta avere una versione di X >= 6.8 . Poi con i nuovi Kde (superiori alla 3.4) si gestisce il tutto dal centro di controllo.
Ok non e' ancora perfetto, ma gia' funziona piuttosto bene.
Non per fare flame, ma se si dice Win Vista sara' "rivoluzionario"...

bjt2

19-01-2006, 18:43

Ma le modifiche all'interfaccia grafica sono il meno delle novita' di Vista... Qualcuno ha detto nuovo kernel, nuova gestione processi memoria e cache ecc...???

samslaves

19-01-2006, 18:47

>>

Windows Communication Foundation (WCF), conosciuto anche come Indigo, che promette lo scambio di dati tra applicazioni senza utilizzare risorse del Web Services.

<<

Mi puzza di Distributed Objects. Se e' cosi, roba vecchissima.

WTF!

tommy781

19-01-2006, 18:54

^-fidel-^

19-01-2006, 19:00

Ma le modifiche all'interfaccia grafica sono il meno delle novita' di Vista... Qualcuno ha detto nuovo kernel, nuova gestione processi memoria e cache ecc...???

Beh le grosse modifiche sono gia' descritte nell'articolo...
Onestamente niente di innovativo in generale, sicuramente innovativo per Windows.
Per come sono pensate, le innovazioni sono comunque promettenti, dal momento che introducono (come di consueto per windows) funzionalita' avanzate come la condivisione intelligente dei files in un modo semplice da usare. Il problema che in molti hanno sollevato e', come al solito, che l'eccessiva automazione di alcuni processi rischi di essere un boomerang per quanto riguarda la sicurezza, ed anche nelle abitudini di utilizzo di windows. Non mi dilungo nei particolari, per questo potete anche consultare vecchi post di HWUpgrade o andare direttamente sul sito Microsoft.

Vedremo...

^-fidel-^

19-01-2006, 19:09

tanto finirà come con xp...tanto denigrato ma poi tutti a correre a procurarsi una copia non tanto perchè migliore ma perchè "figo" sono sicuro che ad un mese dal lancio qui troveremo tutti a discutere di vista da utenti...come poi tutti abbiano il nuovo os sarà il solito mistero inspiegabile....

Hai ragione... Chissa' se TUTTI gli users di Windows dovessero COMPRARE il sistema operativo... Per non parlare di TUTTE le applicazioni che vengono usate (solo comprando Office e Photoshop ci vorrebbero per lo meno 1000 euro).
Per quanto mi riguarda, lo uso solo per giocare :D

ppagno2

19-01-2006, 19:16

... a mio parere sono anni che non si vedono rivoluzioni lato software!!!
Gira che ti rigira è sempre la solita minestra, OK milgiorata, ma sempre la stessa cosa.

A proposito avete mai sentito parlare di "3D Project Looking Glass"?
Se non lo conoscete andate a dargli un'occhiata;
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/lookingglass/
http://www.sun.com/software/looking_glass/demo.xml

E' un progetto di 2 anni fa.

^-fidel-^

19-01-2006, 19:21

A proposito avete mai sentito parlare di "3D Project Looking Glass"?
Se non lo conoscete andate a dargli un'occhiata;
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/lookingglass/
http://www.sun.com/software/looking_glass/demo.xml

E' un progetto di 2 anni fa.

Bravissimo, era proprio qeullo a cui accennavo prima, hai fato bene a mettere un link :)
E' previsto per Mac e Linux nel prossimo futuro (diverse features almeno per Linux sono gia' presenti, per Mac non mi pronuncio dal momento che lo consco poco).

frankie

19-01-2006, 20:14

tanto finirà come con xp...tanto denigrato ma poi tutti a correre a procurarsi una copia non tanto perchè migliore ma perchè "figo" sono sicuro che ad un mese dal lancio qui troveremo tutti a discutere di vista da utenti...come poi tutti abbiano il nuovo os sarà il solito mistero inspiegabile....

Xp infatti non l'ho (2k) e in un altro pc ho da poco meno di un anno fatto l'upgrade da 95 a 98 (mi hanno regalato la licenza)

Io non corro a prendere sempre l'ultimo s.o. aspetto che sia un po' stabile (vedi sp2)

erupter

19-01-2006, 20:27

Tra non prendere l'ultimo so e vantarsi di essere neanderthaliani ce ne corre...
Win XP è il miglior SO che MS abbia fatto finora, a mio parere...

^-fidel-^

19-01-2006, 20:48

Win XP è il miglior SO che MS abbia fatto finora, a mio parere...

Sono d'accordo. Appena uscito, WinXP era un campione di instabilita' e bugs, ma senza voler sparare (come al solito) a zero su MS, e' pur vero che XP segnava un cambiamento netto nei sistemi Windows, creando un ibrido tra Win 98 e le versioni NT. Ma dopo piu' di 3 anni di patch, service pack eccetera, a fine 2004 e' finalmente diventato stabile. Ok, ha ancora diverse pecche (ma chi non ce le ha :) ) ma e' davvero molto stabile ora (nel senso che non si pianta spesso come altre versioni precedenti). Da non-utente windows pero' mi chiedo: con windows Vista si ricomincia tutto da capo? (cioe primo anno di sistema instabile, poi 2 anni di patch per avere nel 2009 un sistema operativo realmente stabile).

Penso che sarebbe una buona idea, per gli utenti windows, restare ad XP come minimo un anno dopo l'uscita di Vista: la corsa al nuovo sistema operativo e', a mio parere, inutile e addiritura controproducente con windows.

Ma sono sicuro che per molti non sara' cosi', tanto l'importante e' che sia piu' figo :O

^-fidel-^

19-01-2006, 20:51

Dimenticavo... C'e' un punto contro il mio ragionamento precedente: ok XP e' stabile, pero' e' gia' piuttosto vecchio! E' infatti del 2001, e ormai altri sistemi operativi sono molto avanti rispetto a lui come features e facilita' d'uso.

Vedremo questo Vista, spero che, con tutto il tempo che MS ci sta mettendo a tirarlo fuori, che sara' piu' stabile del primo XP :p

zani83

19-01-2006, 22:45

prima c'èra Athlon XP e Windows XP
adesso c'è l'Athlon FX e WinFX

secondo me per le sigle ci ragionano parecchio...

dr-omega

19-01-2006, 23:33

Sono d'accordo. Appena uscito, WinXP era un campione di instabilita' e bugs, ma senza voler sparare (come al solito) a zero su MS, e' pur vero che XP segnava un cambiamento netto nei sistemi Windows, creando un ibrido tra Win 98 e le versioni NT.

Mi permetto di dissentire, Windows 2000 è il migliore s.o. prodotto da MS.
Per fare andare decentemente XP devi installare la versione sp2 e poi disabilitare un fottio di servizi inutili oppure devi farti un cd di installazione con nLite.
2000 invece una volta patchato a dovere è a posto così.Stabilissimo, sufficentemente leggero, non invasivo...(scommetto che in XP hai disabilitato il cane, il firewall, messenger associato ad OE, il centro di controllo, il ripristino di sistema, le richieste di invio segnalazioni errori ed i palloni pop-up con i messaggi,almeno...)

Ma dopo piu' di 3 anni di patch, service pack eccetera, a fine 2004 e' finalmente diventato stabile. Ok, ha ancora diverse pecche (ma chi non ce le ha :) ) ma e' davvero molto stabile ora (nel senso che non si pianta spesso come altre versioni precedenti).

Quindi si pianta ancora...andiamo bene!!! ;)
Tengo sotto controllo una trentina di pc assemblati da hardware misto, tutti con 2000 e non ricordo quando è avvenuto l'ultimo blocco di sistema!

Da non-utente windows pero' mi chiedo: con windows Vista si ricomincia tutto da capo? (cioe primo anno di sistema instabile, poi 2 anni di patch per avere nel 2009 un sistema operativo realmente stabile).

Ommioddio NO!!!
Se non escono software che obbligatoriamente richiedono XP o Vista (come Adobe Premiere), io resto bello comodo e pacioso a 2000.E chi mi muove più!
Inoltre non sarò bersagliato dai virus, dato che il target, cioè Vista, sarà ambito da molti. ;)

bartolomeo_ita

20-01-2006, 07:38

Tra non prendere l'ultimo so e vantarsi di essere neanderthaliani ce ne corre...
Win XP è il miglior SO che MS abbia fatto finora, a mio parere...

il migliore è il 2000, però è anche vero che ho XP Pro. per adeguarmi a quello che il mondo domanda da me. Non potevo perdermi ogni volta che mi trovavo a trafficare con il "menù nuovo di xp."

Pare una cavolata, però...

^-fidel-^

20-01-2006, 08:28

Quindi si pianta ancora...andiamo bene!!! ;)
Tengo sotto controllo una trentina di pc assemblati da hardware misto, tutti con 2000 e non ricordo quando è avvenuto l'ultimo blocco di sistema!

E' vero, Win 2000 e' molto stabile, ma pensi che un normale utente possa sostituire windows XP con 2000? Onestamente non credo (giacche' un normale utente di solito piu' che (o oltre che) lavorare col pc, ci gioca e ci fa del multimedia (hai infatti parlato di photoshop per esempio...)
Rettifico allora che XP e' "il piu' stabile dei sistemi windows destinato a tutti gli utenti" :D

però è anche vero che ho XP Pro. per adeguarmi a quello che il mondo domanda da me. Non potevo perdermi ogni volta che mi trovavo a trafficare con il "menù nuovo di xp."

Beh io uso un roccioso Suse linux 9.1 da due anni, l'ho aggiornato alla versione 10 col sistema 'apt' (o con Yast, come mi gira:) ) senza spendere un centesimo e devo dire che il sistema si adatta perfettamente a quello che il mondo domanda a me :D E ti dico che in due anni di uso giornaliero (in media e' acceso 16 ore su 24) si e' piantato UNA sola volta (tra l'altro per un bug video causato dai drivers della scheda video ATI che da un bel pezzo e' stato corretto), e non ho mai formattato... E ci faccio TUTTO (tranne giocare con i grandi giochi che ci sono su Win, escluse poche eccezioni). Quindi Win lo uso solo per giocare :D

Se pensi che devi usare XP perche' non puoi farne a meno ti assicuro che ti sbagli. Poi scegliere il S.O. che preferisci e' solo una tua scelta (Win, Linux, Solaris, ecc...)
NOn farti ingabbiare dall'idea voluta da MS che se non usi XP sei fuori!

Ciauz ;)

max5

20-01-2006, 08:35

io per ora tengo i miei 2 XP Pro, 1 a 32 bit e l'altro a 64 bit almeno fino a che non uscirà Vista col nuovo file system, non voglio correre il rischio di spedere 2 volte, poi è sempre meglio aspettare che esca il 1° SP.....(l'esperienza "dovrebbe" insegnare) ;)

Nevermind

20-01-2006, 08:53

Sono d'accordo. Appena uscito, WinXP era un campione di instabilita' e bugs, ma senza voler sparare (come al solito) a zero su MS, e' pur vero che XP segnava un cambiamento netto nei sistemi Windows, creando un ibrido tra Win 98 e le versioni NT. Ma dopo piu' di 3 anni di patch, service pack eccetera, a fine 2004 e' finalmente diventato stabile. Ok, ha ancora diverse pecche (ma chi non ce le ha ) ma e' davvero molto stabile ora (nel senso che non si pianta spesso come altre versioni precedenti). Da non-utente windows pero' mi chiedo: con windows Vista si ricomincia tutto da capo? (cioe primo anno di sistema instabile, poi 2 anni di patch per avere nel 2009 un sistema operativo realmente stabile).

Penso che sarebbe una buona idea, per gli utenti windows, restare ad XP come minimo un anno dopo l'uscita di Vista: la corsa al nuovo sistema operativo e', a mio parere, inutile e addiritura controproducente con windows.

Ma sono sicuro che per molti non sara' cosi', tanto l'importante e' che sia piu' figo

Lungi da me voler difendere M$ ma a me xp fin da subito è funzionato benissimo e te credo in fin dei conti è un wind 2000 alla base.
Per dire il mio xp è da + di 3 anni che è installato sul mio pc ed ha resistito pure ad un cambio di motherboard!! e ha ancora il sp1 perchè il due non mi convince.
Se vuoi un sistema veramente instabile prova le prime versioni di osx roba da mettersi le mani nei capelli :D

diabolik1981

20-01-2006, 09:29

Mi permetto di dissentire, Windows 2000 è il migliore s.o. prodotto da MS.
Per fare andare decentemente XP devi installare la versione sp2 e poi disabilitare un fottio di servizi inutili oppure devi farti un cd di installazione con nLite.
2000 invece una volta patchato a dovere è a posto così.Stabilissimo, sufficentemente leggero, non invasivo...(scommetto che in XP hai disabilitato il cane, il firewall, messenger associato ad OE, il centro di controllo, il ripristino di sistema, le richieste di invio segnalazioni errori ed i palloni pop-up con i messaggi,almeno...)

Quindi per avere un buon 2000 devi patcharlo come XP, quindi già decade la semplicità di installazione. Poi tutte le cose da disabilitare non vedo perchè debbano essere disabilitate per forza. Io ho disattivato solo il messenger, e cmq con tutta una serie di servizi che partono in automatico all'avvio (Avast, AsusProbe, MSN Messenger, pannello di controllo scheda acquisizione video, getright, logitech assistent) e il sistema occupa 340 MB. Quindi è anche leggero.

Quindi si pianta ancora...andiamo bene!!! ;)
Tengo sotto controllo una trentina di pc assemblati da hardware misto, tutti con 2000 e non ricordo quando è avvenuto l'ultimo blocco di sistema!

Unici problemi di crash avuti sono stati causati da un banco di memoria.

Se non escono software che obbligatoriamente richiedono XP o Vista (come Adobe Premiere), io resto bello comodo e pacioso a 2000.E chi mi muove più!
Inoltre non sarò bersagliato dai virus, dato che il target, cioè Vista, sarà ambito da molti. ;)

Contento tu, contenti tutti.

diabolik1981

20-01-2006, 09:30

il migliore è il 2000, però è anche vero che ho XP Pro. per adeguarmi a quello che il mondo domanda da me. Non potevo perdermi ogni volta che mi trovavo a trafficare con il "menù nuovo di xp."

Pare una cavolata, però...

Basta passare alla visualizzazione old-style ed è identico al 2000.

dr-omega

20-01-2006, 09:55

E' vero, Win 2000 e' molto stabile, ma pensi che un normale utente possa sostituire windows XP con 2000? Onestamente non credo (giacche' un normale utente di solito piu' che (o oltre che) lavorare col pc, ci gioca e ci fa del multimedia (hai infatti parlato di photoshop per esempio...)
Rettifico allora che XP e' "il piu' stabile dei sistemi windows destinato a tutti gli utenti" :D

Noi in azienda abbiamo aggiornato i 2 ultimi portatili da Xp Pro a 2000 multiboot (4 2000, uno per Siemens, uno per Rockwell automation, uno per i pannellini hmi ed un altro per i test), inoltre sotto dominio aziendale (Win 2000 server) è più pratico l'accesso e la creazione utenti rispetto ad Xp
No, non ho parlato di Photoshop, quello funziona perfettamente come del resto migliaia di programmi, io ho parlato di Premiere, un software per il montaggio video.Io infatti uso Pinnacle Studio per fare queste cose.
Ad ogni modo per me 2000 è il più stabile e, permettimi di aggiungere anche DRM free, il che vuole dire che l'accoppiamento Win2000+Office2000+hardware attuale+software CAD che abbiamo ora ci permette di fare tutto quello che vogliamo, senza tempi morti, senza neccessità di upgrade verso altro software/hardware DRM ready.
Io quella roba non la voglio.
;)

dr-omega

20-01-2006, 10:08

Quindi per avere un buon 2000 devi patcharlo come XP, quindi già decade la semplicità di installazione.

Quindi eventualmente saremo sullo stesso livello, ovvero bisogna patcharli tutti e 2, solamente che mentre il SP4 di 2000 è installato sul 100% dei pc con 2000 senza controindicazioni, il SP2 di XP non è gradito a molti, per cui o ti fermi al SP1 ma devi proteggerti in modo adeguato, oppure subisci il SP2 disabilitando molte "features" con l'idea che quando uscirà il SP3 ci sarà pure dentro un bel DRM e chissà quali altre schifezze.
Io con 2000 posso permettermi di lasciare l'autoupdate di MS attivo senza paura di incorrere nel download di qualche "feature" dannosa per l'utente(il proprietario del pc).

Poi tutte le cose da disabilitare non vedo perchè debbano essere disabilitate per forza. Io ho disattivato solo il messenger, e cmq con tutta una serie di servizi che partono in automatico all'avvio (Avast, AsusProbe, MSN Messenger, pannello di controllo scheda acquisizione video, getright, logitech assistent) e il sistema occupa 340 MB. Quindi è anche leggero.

Naturalmente uno disattiva quello che vuole.Se ad uno piace XP con tutto attivo io non ho mica problemi.
Personalmente però se dovessi usare XP (e ogni tanto purtroppo devo farlo per l'assistenza)disabiliterei una marea di cose inutili.IMHO ;)

Contento io?
Ci puoi scommettere, con 2000 la vita mi sorride :D (e non scherzo). ;)

soft_karma

20-01-2006, 10:19

Anche io non sono uno di quelli che corre a prendere l'ultimo S.O., ma ormai il 2000 lascia il tempo che trova. A parte il fatto che Microsoft non rilascia più patch per questo sistema, ma per utenti casalinghi è sicuramente il più pratico e stabile. Per gli utenti un po' più "competenti" è necessario togliere un po' di servizi e schifezze grafiche, ma per l'utente medio ha una serie di messaggi di avvertimento che ti evitano gli errori più comuni.

diabolik1981

20-01-2006, 10:23

Quindi eventualmente saremo sullo stesso livello, ovvero bisogna patcharli tutti e 2, solamente che mentre il SP4 di 2000 è installato sul 100% dei pc con 2000 senza controindicazioni, il SP2 di XP non è gradito a molti, per cui o ti fermi al SP1 ma devi proteggerti in modo adeguato, oppure subisci il SP2 disabilitando molte "features" con l'idea che quando uscirà il SP3 ci sarà pure dentro un bel DRM e chissà quali altre schifezze.
Io con 2000 posso permettermi di lasciare l'autoupdate di MS attivo senza paura di incorrere nel download di qualche "feature" dannosa per l'utente(il proprietario del pc).

E basta col terrorismo informatico, che ne puoi sapere di DRM e simili? E poi come fai a dire che sono dannose per l'utente?. SP2 ha dato un po di problemi con hw datato e soprattutto con software capriccioso, ma l'ho installato sulle macchine più disparate (tra cui anche un Duron 800) e non ho avuto mai alcun problema.

dr-omega

20-01-2006, 10:41

Anche io non sono uno di quelli che corre a prendere l'ultimo S.O., ma ormai il 2000 lascia il tempo che trova. A parte il fatto che Microsoft non rilascia più patch per questo sistema, ma per utenti casalinghi è sicuramente il più pratico e stabile.

Di aggiornamenti per la sicurezza ne rilascia eccome!!!E quando la MS chiuderà i rubinetti non sarà un problema, visto che i virus writers avranno altro a cui pensare.E comunque basta avere buon senso, un antivirus sempre aggiornato e un browser internet+client di posta diversi da IE e OE per avere il sedere ben protetto.

dr-omega

20-01-2006, 10:58

E basta col terrorismo informatico, che ne puoi sapere di DRM e simili?

Vero, per il momento si legge molto vaporware e qualche cosa giusta, come l'hardware TCPA installato si pc nuovi.(Segui il link in firma)
Però se permetti, prima di cascarci e sbatterci la faccia, preferisco mettere le mani avanti.
Comunque la mia non è una guerra di religione.IMHO (ovvero secondo me) win2000 è il migliore s.o. MS, con 2000 faccio tutto ciò che voglio senza impazzire, senza blocchi, ecc ecc
Ognuno è libero di pensare e fare come vuole: se per te Xp è good, allora anche per me è ok.Il drm non è un problema adesso?Nessun problema!
Diciamoci la verità, io a casa mia, prima di avere il Commodore 64 vivevo comunque benissimo, i miei genitori sono cresciuti senza pc e credo che se arriverà Vista a dirmi che non posso ascoltare gli mp3 scaricati dal torrent (che non partirà), bhè, poco male, troverò altro da fare e ascoltare e come i miei nonni ed i nonni dei nonni, continuerò a vivere.

E poi come fai a dire che sono dannose per l'utente?. SP2 ha dato un po di problemi con hw datato e soprattutto con software capriccioso, ma l'ho installato sulle macchine più disparate (tra cui anche un Duron 800) e non ho avuto mai alcun problema.

Ma si, dato che i drivers per XP non ci sono ne approfitto per buttare nel cesso tutto l'hardware vecchio e perfettamente funzionante e ricomprare tutto nuovo.
Ottima idea, w il consumismo!
E se anche Vista costringerà alla medesima operazione???
Nessun problema, butteremo tutto e riacquisteremo ancora. :stordita:

diabolik1981

20-01-2006, 11:06

Vero, per il momento si legge molto vaporware e qualche cosa giusta, come l'hardware TCPA installato si pc nuovi.(Segui il link in firma)
Però se permetti, prima di cascarci e sbatterci la faccia, preferisco mettere le mani avanti.

Discorso che non condivido molto, ma sono opinioni personali. :D

Comunque la mia non è una guerra di religione.IMHO (ovvero secondo me) win2000 è il migliore s.o. MS, con 2000 faccio tutto ciò che voglio senza impazzire, senza blocchi, ecc ecc

Forse non hai avuto un ottimo impatto con XP, può capitare. :)

Ognuno è libero di pensare e fare come vuole: se per te Xp è good, allora anche per me è ok.Il drm non è un problema adesso?Nessun problema!
Diciamoci la verità, io a casa mia, prima di avere il Commodore 64 vivevo comunque benissimo, i miei genitori sono cresciuti senza pc e credo che se arriverà Vista a dirmi che non posso ascoltare gli mp3 scaricati dal torrent (che non partirà), bhè, poco male, troverò altro da fare e ascoltare e come i miei nonni ed i nonni dei nonni, continuerò a vivere.

Su questo non ci piove, ma chi sta usando la Beta di Vista non ha riscontrato alcuno di questi problemi, oltretutto credo che alla MS non siano tanto stupidi da mettere tali vincoli.

Ma si, dato che i drivers per XP non ci sono ne approfitto per buttare nel cesso tutto l'hardware vecchio e perfettamente funzionante e ricomprare tutto nuovo.
Ottima idea, w il consumismo!
E se anche Vista costringerà alla medesima operazione???
Nessun problema, butteremo tutto e riacquisteremo ancora. :stordita:

Più che consumismo lo chiamerei Evoluzione. Purtroppo in informatica la vita dell'hardware nei migliori dei casi raggiunge i 5 anni, e parliamo già di casi davvero unici. Poi molto dipende anche dai produttori che non forniscono supporto alle proprie periferiche, quindi non darei la colpa a MS, ma ai produttori di HW. Com questo non volgio dire che MS sia il nuovo redentore, ma che spesso si addebitano colpe che non sono sue.

fek

20-01-2006, 11:15

Ma si, dato che i drivers per XP non ci sono ne approfitto per buttare nel cesso tutto l'hardware vecchio e perfettamente funzionante e ricomprare tutto nuovo.
Ottima idea, w il consumismo!
E se anche Vista costringerà alla medesima operazione???
Nessun problema, butteremo tutto e riacquisteremo ancora. :stordita:

Oppure non installi XP o Vista sulle macchine in cui hai hardware non supportato ma che vuoi ancora utilizzare. Non ti ha ordinato il medico di installare XP o Vista e nessuno ti punta la pistola alla tempia.

bjt2

20-01-2006, 11:19

Mi permetto di dire che tutto l'hardware che ho avuto modo di installare su vari XP miei e di miei conoscenti, che non avevano driver specifici per XP, funzionavano perfettamente con i drivers per windows 2000, a parte il messaggio che chiedeva conferma se installarli o meno...

^-fidel-^

20-01-2006, 11:30

Più che consumismo lo chiamerei Evoluzione. Purtroppo in informatica la vita dell'hardware nei migliori dei casi raggiunge i 5 anni, e parliamo già di casi davvero unici. Poi molto dipende anche dai produttori che non forniscono supporto alle proprie periferiche, quindi non darei la colpa a MS, ma ai produttori di HW. Com questo non volgio dire che MS sia il nuovo redentore, ma che spesso si addebitano colpe che non sono sue.

Spero tu stia scherzando! Forse non sai o non vuoi sapere che MS e i produttori hardware (almeno i maggiori) elaborano strategie commerciali INSIEME. Ad esempio, come descritto in un precedente post di HWUpgrade, Vista trainera' il mercato delle nuove schede video con MINIMO 256 mega di ram onboard, giusto per attivare senza rallentamenti tutte le nuove feature grafiche (trasparenze di finestre ecc.). Ti dico solo che in altri sistemi operativi (ad esempio Linux ma non solo) queste features ci sono gia' e 64 mega di ram su scheda video sono piu' che sufficienti per farle funzionare.
Allora io non credo che i programmatori Microsoft siano tanto incapaci da implmentare cose gia' esistenti sfruttando il QUADRUPLO delle risorse harware richieste... Forse lo fanno apposta? Io dico di si (anzi ci metto la mano sul fuoco dopop quello che ti ho detto...).
Tra un po' dovremo comprare PC della NASA per lanciare Vista senza rallentamenti... probabilmente esagero, ma la situazione commerciale sta esattamente cosi'. Invece di sfruttare al massimo i PC esistenti, che si fa? Si spinge l'utente a comprare nuovo hardware sempre piu' potente (che altrimenti sarebbe inutile nel mercato consumer, magari meglio produrlo per fare ricerca), tanto poi dei rifiuti di silicio chissenefrega? Vanno tutti in africa ed in cina...
Continuiamo cosi'...

^-fidel-^

20-01-2006, 11:34

Dimenticavo...

Potete obiettarmi: "Ma io posso anche disabilitare le nuove features grafiche!".
Vero, ma scommettiamo che molti utenti cambieranno come minimo la scheda video per attivarle, perche' e' piu' figo e cosi' si vede la differenza con XP? :muro:

^-fidel-^

20-01-2006, 11:39

Oppure non installi XP o Vista sulle macchine in cui hai hardware non supportato ma che vuoi ancora utilizzare. Non ti ha ordinato il medico di installare XP o Vista e nessuno ti punta la pistola alla tempia.

Vero, ma aspetta un anno e vedrai... Quando molti siti richiederanno software (tipo Windows media player 11 o 12) per vedere i contenuti multimediali, o nuovi browser, e per 2000 questi non saranno compatibili (leggi 'non installabili'), che farai? O fai a meno di quelle funzioni, o aggiorni. O cambi S.O. MS ha il monopolio, e se vuole farti "comprare" Vista ci riesce. Poi dipende da quello che fai col pc, se tutto il tuo lavoro ed il tuo divertimeno col PC viene risolto con Win 2000 ad esempio, tanto meglio. Ma solo se giochi con i vari videogames, vedrai tra un anno le nuove directX 10 compatibili SOLO con Vista...

Chi vivra' vedra'

diabolik1981

20-01-2006, 11:51

diabolik1981

20-01-2006, 11:53

Vero, ma aspetta un anno e vedrai... Quando molti siti richiederanno software (tipo Windows media player 11 o 12) per vedere i contenuti multimediali, o nuovi browser, e per 2000 questi non saranno compatibili (leggi 'non installabili'), che farai? O fai a meno di quelle funzioni, o aggiorni. O cambi S.O. MS ha il monopolio, e se vuole farti "comprare" Vista ci riesce. Poi dipende da quello che fai col pc, se tutto il tuo lavoro ed il tuo divertimeno col PC viene risolto con Win 2000 ad esempio, tanto meglio. Ma solo se giochi con i vari videogames, vedrai tra un anno le nuove directX 10 compatibili SOLO con Vista...

Chi vivra' vedra'

Ti ripeto evoluzione. Per l'uso che ne fa la maggior parte degli utenti del PC, è più che sufficiente il mio 286 con Windows 3.11. PErò si voglio anche features avanzate che richiedono hardware avanzato. Se ti sta bene è così, altrimenti se vuoi ti vendo il mio 286. :) , con le mirabolanti capacità di: 1 MB di Ram, 20 MB di HD, scheda video EGA.

MenageZero

20-01-2006, 12:01

Sono d'accordo. Appena uscito, WinXP era un campione di instabilita' e bugs, ma senza voler sparare (come al solito) a zero su MS, e' pur vero che XP segnava un cambiamento netto nei sistemi Windows, creando un ibrido tra Win 98 e le versioni NT.

come architettura di sistema 9x e gli NT(e discendenti, xp incluso) sono parenti molto lontani (se "parenti" veri si possono definire), di "grosso" oltre ad aspetto e organizzazione della gui, hanno in comune solo un sottoinsieme delle api (più come interfaccia, apunto, che come implementazione).

non c'è nulla di ibrido con 98 in xp, è solo che finalmente nel 2001 ms ha "concesso" l'architettura nt anche alla fascia di mercato "home".

su instabilità e bugs agli esordi, bho che dire... ad es la mia esperienza diretta è sempre stata positiva... ma i singoli casi non fanno una "regola"...

certo se dovessimo andare a cercare statistiche ho i miei dubbi che xp, anche poco dopo il rilascio, risulti effettivamente un caso anomalo(intendo molto oltre una plausibile "media" per un os di quel tipo) per grande instabilità
ed evelvata "concertrazione" di bug

MenageZero

20-01-2006, 12:43

Mi permetto di dissentire, Windows 2000 è il migliore s.o. prodotto da MS.
Per fare andare decentemente XP devi installare la versione sp2 e poi disabilitare un fottio di servizi inutili oppure devi farti un cd di installazione con nLite.
2000 invece una volta patchato a dovere è a posto così.Stabilissimo, sufficentemente leggero, non invasivo...(scommetto che in XP hai disabilitato il cane, il firewall, messenger associato ad OE, il centro di controllo, il ripristino di sistema, le richieste di invio segnalazioni errori ed i palloni pop-up con i messaggi,almeno...)
ovviamente ognuno ha le sue preferenze ed esperienze...

ad esempio a me xp va decentemente anche su un "archeologico" p2 350 con 128 di ram, per un utilizzo essenzialmente "da ufficio", così come è senza curare nessun dettaglio (a parte distattivare il "ripristino config. di sistema" perché l'hd è di soli 4gb), nemmeno sp e patch di sicurezza (per pigrizia e perché tanto tale pc non è connesso a internet o lan)

poi cmq come kernel
win2000 -> (nt)5.0
xp -> (nt)5.1

ovvero xp rispetto a win 2000 è essenzialmente una minor release successiva dello stesso os con alcune lib, apps, e servizi in più (questi utlimi appunto se sono "sgraditi" li disattivi, apps se non vuoi non le usi) quindi mi pare difficile sostenere una qualche superiorità tecnologica intrinseca del 2000 rispetto ad xp

cmq è ovvio che se uno ritiene win2000 ciò che meglio risponde alle sue esigenze per qualunque motivo, è logico che lo usi e lo mantenga finché ritiene opportuno, confrontavo la "natura" dei due os ma non volevo certo sostenere l'opportunità di aggiornare ad xp i sistemi precedenti a priori
:)

dr-omega

20-01-2006, 13:30

Oppure non installi XP o Vista sulle macchine in cui hai hardware non supportato ma che vuoi ancora utilizzare. Non ti ha ordinato il medico di installare XP o Vista e nessuno ti punta la pistola alla tempia.

Buon fek hai ragione.Però l'avevo già detto anche io nei post precedenti. :D
Il problema nascerà se un dato software richiederà obbligatoriamente la presenza di xp o vista e se questo software sarà necessario, ad es. per lavoro.
Io spero tanto di no, è così bello poter scegliere! ;)

dr-omega

20-01-2006, 13:47

dr-omega

20-01-2006, 13:58

Vero, ma aspetta un anno e vedrai... Quando molti siti richiederanno software (tipo Windows media player 11 o 12) per vedere i contenuti multimediali, o nuovi browser, e per 2000 questi non saranno compatibili (leggi 'non installabili'), che farai? O fai a meno di quelle funzioni, o aggiorni. O cambi S.O. MS ha il monopolio, e se vuole farti "comprare" Vista ci riesce. Poi dipende da quello che fai col pc, se tutto il tuo lavoro ed il tuo divertimeno col PC viene risolto con Win 2000 ad esempio, tanto meglio. Ma solo se giochi con i vari videogames, vedrai tra un anno le nuove directX 10 compatibili SOLO con Vista...

Chi vivra' vedra'

Sono d'accordo.

Io MP9 (perchè il 10 è only XP) non lo uso affatto perchè l'ho sostituito dai codecs alternativi e dal MPclassic, però è capitato di finire su un sito (software cad)dove per vedere dei filmati era richiesto MP10.
La cosa mi ha fatto girare a manetta gli ammenicoli, perchè esclusi i pc con xp, nessuno, con 2k,98,me,95,osx,linux può vedere quei video.
Vi pare corretto?
A me no... :muro:

Una volta si facevano gli standard per creare interoperabilità, ora si fanno gli standard per escludere.Robe da matti

p.s.Per la cronaca ho fatto a meno di vedere i video e mi sono arrangiato.

dr-omega

20-01-2006, 14:18

Ti ripeto evoluzione. Per l'uso che ne fa la maggior parte degli utenti del PC, è più che sufficiente il mio 286 con Windows 3.11. PErò si voglio anche features avanzate che richiedono hardware avanzato. Se ti sta bene è così, altrimenti se vuoi ti vendo il mio 286. :) , con le mirabolanti capacità di: 1 MB di Ram, 20 MB di HD, scheda video EGA.

Alt, con il tuo pc non riesci a maneggiare le foto della fotocamera digitale, e neppure quelle del telefonino (credo che il 95% di chi ha il pc abbia l'una o l'altro o tutti e due), quindi se permetti :) io alzerei il limite per un utilizzo home (office+internet+mp3+foto+dvd/xvid) ad un pc con xp2200(o equivalenti) con 512mb di ram ed un disco da 40Gb.La scheda video può essere una qualsiasi da max 128Mb di ram e con un costo attuale sulle 300 euro e si può giocare bene a tanto.Ho escluso le schede strapompate per gli fps perchè la maggior parte degli utenti (quindi anche le casalinghe), non giocano a F.E.A.R.
Per un utilizzo home, la potenza e le feature sbandierate ora sono inutili orpelli.
Non sto facendo come quel tizio semisconisciuto che sbandierava l'inutilità di avere oltre 128k di ram (o una cosa così), però obbiettivamente per un utilizzo home non potete dire che 2 sli servono!!!
Meglio sarebbe utilizzare questa tecnologia per offrire prodotti con minor consumo e miglior impatto ambientale.

diabolik1981

20-01-2006, 14:25

Alt, con il tuo pc non riesci a maneggiare le foto della fotocamera digitale, e neppure quelle del telefonino (credo che il 95% di chi ha il pc abbia l'una o l'altro o tutti e due), quindi se permetti :) io alzerei il limite per un utilizzo home (office+internet+mp3+foto+dvd/xvid) ad un pc con xp2200(o equivalenti) con 512mb di ram ed un disco da 40Gb.La scheda video può essere una qualsiasi da max 128Mb di ram e con un costo attuale sulle 300 euro e si può giocare bene a tanto.

Ok, allora ti posso offrire, sempre perfettamente funzionante per uso office:

P2 350, Asus P2B, 256 MB Ram, Matrox Millennium 2 8MB Vram, HD IBM 9.6 GB (il primo disco mai prodotto a 7200 RPM), masterizzatore CD Yamaha 16x10x40 Windows 98. Con questo ci fai tutto il necessario per uso Office-Home tranne giocare, cosa che non tutti fanno e per la quale è necessario avere HW molto potente. Questo PC è del 1997 e va ancora bene, ci puoi vedere foto, film, attaccare il cell (aveva già le USB).

dr-omega

20-01-2006, 15:00

Ok, allora ti posso offrire, sempre perfettamente funzionante per uso office:

P2 350, Asus P2B, 256 MB Ram, Matrox Millennium 2 8MB Vram, HD IBM 9.6 GB (il primo disco mai prodotto a 7200 RPM), masterizzatore CD Yamaha 16x10x40 Windows 98. Con questo ci fai tutto il necessario per uso Office-Home tranne giocare, cosa che non tutti fanno e per la quale è necessario avere HW molto potente. Questo PC è del 1997 e va ancora bene, ci puoi vedere foto, film, attaccare il cell (aveva già le USB).

Abbiamo in ufficio un p3 500 con 98se 512mb di ram e hdd da 10gb forse 5400 che è lentoooooooo, così non va bene.
No no grazie, devo declinare l'offerta,anche perchè io il pc ce l'ho, ho un XP barattolo2500 ed una nf7-s con 1Gb di ram, 180Gb di hdd ed una 6800LE sveglia.
Di più onestamente, per quello che devo fare, non mi serve.

Resto dell'idea che un pc con le caratteristiche che ho elencato nel post precedente sia il meglio per l'home-office.

ekerazha

21-01-2006, 01:03

Carino Avalon, ci sto giocando da qualche mese... è possibile disegnare interfacce grafiche attraverso una sorta di XML, compresi oggetti vettoriali in 3D etc. :)

cdimauro

21-01-2006, 04:36

Vero, per il momento si legge molto vaporware e qualche cosa giusta, come l'hardware TCPA installato si pc nuovi.(Segui il link in firma)
Spazzatura terroristica.

cdimauro

21-01-2006, 04:38

Hai ragione, e questo discorso va avanti da quando c'è stato il passaggio dai primi home-pc come il C64 e l'Amiga ai pc che usiamo oggi (nelle sue vari evoluzioni).
Non so quante volte ho sentito dire la frase:"Non c'è più l'ottimizzazione dei sotware che c'era una volta..." oppure "non si è più capaci di sfruttare l'hardware a fondo..."
So che è una mezza verità, dato che una volta, i pc si compravano preassemblati (mai provato ad aggiornare il SID del C64??? :D ), e quindi fare sw per delle scatole chiuse era molto più facile, però ora forse si tende ad esagerare un tantino, magari sbandierando la retrocompatibilià.
E' una mezza verità, perché di software poco o per niente ottimizzati ce n'erano molti anche per C64 e Amiga.

Rispetto al passato è vero che c'è un sacco di hardware diverso, ma l'ottimizzazione non manca di certo.

Non mi venire a dire che:
uso di assembly -> ottimizzazione
perché, ripeto, non è affatto vero.

mjordan

21-01-2006, 04:42

Non voglio fare polemica, semplicemente sono curioso: non riesco ad immaginare uno scenario in cui si debba voler modificare a 4 mani un documento. Penso ad un foglio di lavoro, un documento di testo o una presentazione(Ovviamente i database sono un discorso completamente differente). In generale sono abituato a lavorare "per versioni", con io che scrivo il pezzo A, poi aggiungi tu il pezzo B e cambi revisione, e così via. O magari ci dividiamo il lavoro e tu fai la prima parte ed io la seconda, procedendo al termine con un bel merge e produzione del documento finale.

Qualcuno ne sa di +?

Scusa ma che c'entra tutto ciò con la news? :confused:

mjordan

21-01-2006, 04:52

Ah dimenticavo...
Non mi risulta che i drivers centrino qualcosa. E' tutto un discorso di layer grafico gestito direttamente dal sistema operativo. Un layer ben fatto fornira' nuove funzioni API per le finestre 3D, e wrapper di conversione automatica 2D-3D per le vecchie applicazioni. Vedremo i signori Microsoft cosa sapranno fare :)
Adios

Se non ti risulta allora informati. :)
Attualmente tu puoi gestire esclusivamente un processo grafico alla volta. Questo significa che se tu dovessi usare la scheda grafica per l'interfaccia grafica 3D, non potresti far partire un gioco, in quanto la scheda risulta già occupata.
Il nuovo driver model di Windows Vista gioca un ruolo fondamentale in questo, quindi i driver sono il pilastro cardine di questa nuova tecnologia:

Ti quoto a tal proposito quanto detto da Microsoft:

Inside New Visuals: An Application Developer's View

A new graphics driver model has been introduced with Windows Vista that is stable and secure; it has built-in fault tolerance to enable constant use of the graphics processor unit (GPU) for the rich graphics sported by the operating system and the applications. The GPU memory manager and scheduler in this driver model enable multiple graphics applications to use the GPU to run simultaneously.

Inoltre un'altra grandeconseguenza del nuovo driver model è appunto la DirectX 10, che consentirà l'uso di applicazioni GPGPU per sfruttare a dovere la sempre maggiore potenza dei processori grafici. Chissà che non riusciamo a fare del sano postprocessing su ogni frame di un'immagine senza perdere troppo in prestazioni... Chissà che effetti che ne usciranno fuori...

mjordan

21-01-2006, 04:57

Sono d'accordo. Appena uscito, WinXP era un campione di instabilita' e bugs, ma senza voler sparare (come al solito) a zero su MS, e' pur vero che XP segnava un cambiamento netto nei sistemi Windows, creando un ibrido tra Win 98 e le versioni NT. Ma dopo piu' di 3 anni di patch, service pack eccetera, a fine 2004 e' finalmente diventato stabile. Ok, ha ancora diverse pecche (ma chi non ce le ha :) ) ma e' davvero molto stabile ora (nel senso che non si pianta spesso come altre versioni precedenti). Da non-utente windows pero' mi chiedo: con windows Vista si ricomincia tutto da capo? (cioe primo anno di sistema instabile, poi 2 anni di patch per avere nel 2009 un sistema operativo realmente stabile).

Io non so che problemi hai avuto tu, ma a me come a qualche altra decina di milioni di persone Windows XP è sempre funzionato bene, dalla prima versione fino all'attuale Service Pack 2. Faccio le normali operazioni di amministrazione e manutenzione e vanto un'installazione vecchia di 2 anni senza aver mai formattato.

Penso che sarebbe una buona idea, per gli utenti windows, restare ad XP come minimo un anno dopo l'uscita di Vista: la corsa al nuovo sistema operativo e', a mio parere, inutile e addiritura controproducente con windows.

Ma sono sicuro che per molti non sara' cosi', tanto l'importante e' che sia piu' figo :O

Bhà... Controproducente... :rolleyes:

mjordan

21-01-2006, 05:06

Spero tu stia scherzando! Forse non sai o non vuoi sapere che MS e i produttori hardware (almeno i maggiori) elaborano strategie commerciali INSIEME. Ad esempio, come descritto in un precedente post di HWUpgrade, Vista trainera' il mercato delle nuove schede video con MINIMO 256 mega di ram onboard, giusto per attivare senza rallentamenti tutte le nuove feature grafiche (trasparenze di finestre ecc.). Ti dico solo che in altri sistemi operativi (ad esempio Linux ma non solo) queste features ci sono gia' e 64 mega di ram su scheda video sono piu' che sufficienti per farle funzionare.

Questo è un discorso trito e ritrito su questo forum, ogni volta lo stesso discorso del menga. Windows Vista è un sistema operativo che farà girare i PC dei prossimi 5 anni. Quindi i suoi requisiti hardware sono piu' che leciti per quando sarà uscito (fine 2006) e chissà che non subirà pure qualche ritardo.
Inoltre i sistemi operativi sono fatti per l'hardware presente e futuro, non puoi pretendere di far girare Vista su un merdoso PC del 2002 pagato pure poco. Se Vista ha requisiti troppo grossi per il PC in questione, significa che deve continuare ad usare XP. Si sbaglia a pensare che un nuovo sistema operativo soppianti il precedente. Questo non è vero. Se il tuo computer non riesce a supportare Windows Vista, significa che deve continuare a usare Windows XP. Microsoft ti darà altri 2 anni di supporto in attesa che quel cioccolo lo butti e lo stesso faranno i produttori nelle loro applicazioni software.
Quindi tutto il resto è polemica.
P.S: Sei cosi sicuro che non si possano avere trasparenze sotto Windows XP? :rolleyes: Pare che parli delle trasparenze neanche fosse una super caratteristica da hardware Cray Supercomputers... Tutto sto polverone per un canale alpha...

Allora io non credo che i programmatori Microsoft siano tanto incapaci da implmentare cose gia' esistenti sfruttando il QUADRUPLO delle risorse harware richieste... Forse lo fanno apposta? Io dico di si (anzi ci metto la mano sul fuoco dopop quello che ti ho detto...).

Ma che stai a di? :asd: :asd:

Tra un po' dovremo comprare PC della NASA per lanciare Vista senza rallentamenti... probabilmente esagero, ma la situazione commerciale sta esattamente cosi'. Invece di sfruttare al massimo i PC esistenti, che si fa? Si spinge l'utente a comprare nuovo hardware sempre piu' potente (che altrimenti sarebbe inutile nel mercato consumer, magari meglio produrlo per fare ricerca), tanto poi dei rifiuti di silicio chissenefrega? Vanno tutti in africa ed in cina...
Continuiamo cosi'...

Fermatelo vi prego :rotfl:
Dimmi un po', tu come "sfrutteresti al massimo i PC esistenti"?
Ricordati che devi essere tecnico nella dissertazione. Mi devi spiegare per filo e per segno come sfrutteresti al massimo i PC esistenti. Altrimenti puoi chiudere il discorso, perchè se non hai capacità tecniche di illustrare ciò che decanti significa solo che stai spalando merda a gratis (cioè che non capisci nemmeno quello che stai dicendo). Attendo con ansia questa illuminazione...
Ah, tu che sei un super esperto di Linux... Lo sai che se il tuo PC non è in grado di far girare decentemente Vista, probabilmente avrà molta difficoltà a far girare KDE 4? Hai visto il progetto Plasma? Hai provato a ricompilarti le librerie QT 4.1 e a lanciare i demo? Hai visto in definitiva cosa significa avere una GUI basata su grafica vettoriale? :rotfl:

Non te la prendere, sono anche io un utente Linux di vecchissima data eh! ;)

^-fidel-^

26-01-2006, 08:56

Fermatelo vi prego :rotfl:
Dimmi un po', tu come "sfrutteresti al massimo i PC esistenti"?
Ricordati che devi essere tecnico nella dissertazione. Mi devi spiegare per filo e per segno come sfrutteresti al massimo i PC esistenti. Altrimenti puoi chiudere il discorso, perchè se non hai capacità tecniche di illustrare ciò che decanti significa solo che stai spalando merda a gratis (cioè che non capisci nemmeno quello che stai dicendo). Attendo con ansia questa illuminazione...
Ah, tu che sei un super esperto di Linux... Lo sai che se il tuo PC non è in grado di far girare decentemente Vista, probabilmente avrà molta difficoltà a far girare KDE 4? Hai visto il progetto Plasma? Hai provato a ricompilarti le librerie QT 4.1 e a lanciare i demo? Hai visto in definitiva cosa significa avere una GUI basata su grafica vettoriale? :rotfl:

Non te la prendere, sono anche io un utente Linux di vecchissima data eh! ;)

Non preoccuparti non me la prendo, ognuno ha le sue idee :)

Comunque se vuoi andare sul tecnico... Ho installato una SuSE con kde 3.5 su un pentium 3 1,5 GigaHz e va una favola (e come ben sai kde 3.5 e' parecchio superiore ad XP e paragonabile a Vista). Con KDE 4 il lavoro che si sta facendo e' rendere "omogeneo" l'accesso alle periferiche di rete ed a quelle estraibili (vera "pecca" per gli utenti che sono abituati a Win): bada bene, non e' che non funzionino, anzi... ma avere un layer hardware indipendente come c'e' in windows sara' una manna (Se ti installi HAL + D-bus su linux vai gia' alla grande).
Sul suddetto pentium 3 ho pure provato le QT 4.0 e ti devo dire che non le ho trovate cosi' lente come dici, anzi... per essere ancora in beta (cosi' come usate da KDE bada bene). Il lavoro che si sta facendo e' proprio rendere snello l'uso delle nuove QT con il nuovo KDE: non puoi valutare le prestazioni di un sistema ancora in beta, che sara' definitivo almeno tra 6 mesi!!! Basta guardare il KDE 3.x: dalla 3.2 alla 3.5 sono state aggiunte un sacco di features, ed il sistema e' PIU' VELOCE!
Se non conosci lil significato della parola "ottimizzazione" non e' mica colpa mia...
Come sfruttare le risorse del pc al massimo?

1) scrivere drivers e layer di astrazione in assembler (o almeno in parte per le funzioni di core)
2) uso parsimonioso della memoria (vera pecca di windows, che ha una gestione garbage collection da schifo)
3) minimizzazione dell'uso del file di swap (che e' un collo di bottiglia: con WinXp e' migliorato, ma siamo ancora lontani...)
4) Avere un filesistem DECENTE (e non NTFS che fa letteralmente schifo: se non sei convinto vatto a fare una ricerca su google delle comparative tra NTFS ed altri filesystem e vedrai, ci trovi pure i perche' NTFS e' lento)
5) Stanno ormai diffondendosi i PC con architettura a 64 bit: ci rendiamo conto cosa significa avere registri di dimensione DOPPIA? Tornando al punto 1, se si usasse un po' di piu' l'assembler invece che il C#, vedresti che vantaggi.

E potrei continuare.

Ciao :cool:

cdimauro

26-01-2006, 09:27

Se non conosci lil significato della parola "ottimizzazione" non e' mica colpa mia...
Come sfruttare le risorse del pc al massimo?

1) scrivere drivers e layer di astrazione in assembler (o almeno in parte per le funzioni di core)
Si scrive assembly, compagnero.
2) uso parsimonioso della memoria (vera pecca di windows, che ha una gestione garbage collection da schifo)
Su questo ci sarebbe non poco da disquisire. Per l'uso desktop trovo più reattivo XP rispetto a FC4 con la stessa quantità di memoria (512MB) quando passo ad applicazioni che non uso da un po' di tempo.
3) minimizzazione dell'uso del file di swap (che e' un collo di bottiglia: con WinXp e' migliorato, ma siamo ancora lontani...)
Lontani da cosa?
4) Avere un filesistem DECENTE (e non NTFS che fa letteralmente schifo: se non sei convinto vatto a fare una ricerca su google delle comparative tra NTFS ed altri filesystem e vedrai, ci trovi pure i perche' NTFS e' lento)
Link?
5) Stanno ormai diffondendosi i PC con architettura a 64 bit: ci rendiamo conto cosa significa avere registri di dimensione DOPPIA?
Io sì, e tu? Non mi sembra proprio. :rolleyes:
Tornando al punto 1, se si usasse un po' di piu' l'assembler invece che il C#, vedresti che vantaggi.
Si scrive assembly (e due).

Solo che se si usasse più assembly, per mettere in produzione un'applicazione i tempi aumenterebbero a dismisura.

Inoltre con la compilazione dinamica anche il C# (in generale la piattaforma .NET) risulta abbastanza efficiente.

Diciamo che preferisco perdere un 20% di prestazioni piuttosto che 20 volte il tempo per rilasciare un'applicazione.
E potrei continuare.

Ciao :cool:
Continua pure. ;)

fek

26-01-2006, 09:54

1) scrivere drivers e layer di astrazione in assembler (o almeno in parte per le funzioni di core)
2) uso parsimonioso della memoria (vera pecca di windows, che ha una gestione garbage collection da schifo)
3) minimizzazione dell'uso del file di swap (che e' un collo di bottiglia: con WinXp e' migliorato, ma siamo ancora lontani...)
4) Avere un filesistem DECENTE (e non NTFS che fa letteralmente schifo: se non sei convinto vatto a fare una ricerca su google delle comparative tra NTFS ed altri filesystem e vedrai, ci trovi pure i perche' NTFS e' lento)
5) Stanno ormai diffondendosi i PC con architettura a 64 bit: ci rendiamo conto cosa significa avere registri di dimensione DOPPIA? Tornando al punto 1, se si usasse un po' di piu' l'assembler invece che il C#, vedresti che vantaggi.

1) Che senso avrebbe scrivere un layer di astrazione in un linguaggio a basso livello?

2) Lo sai che usare meno memoria e' spesso e volentieri indirettamente proporizionale alla velocita' d'esecuzione? (tralasciando i discorsi sulla coerenza degli accessi alla cache)

3) Non vuol dire nulla detto cosi'

4) Link?

5) Si', vuol dire avere puntatori di dimensione doppia e mediamente piu' cache miss, quindi andare piu' lenti (vedi punto 2)

6) E' vero l'esatto contrario. Il 99% delle ottimizzazioni sono a livello algoritmico. Scrivere tutto in assembly, oltre alla follia insita nel concetto, significherebbe avere codice talmente ingestibile da rendere sostanzialmente impossibile qualunque ottimizzazione algoritmica, tradotto: scrivere tutto in assembly produce software piu' lento che scrivendo con linguaggi ad alto livello (C++/C#/Java).

^-fidel-^

26-01-2006, 10:23

A parte il fatto che "assembler" è perfettamente corretto (poveri noi...), non a caso MS MASM sta per Microsoft Macro Assembler, quello intel pure, ecc... Per favore non corregete l'uso di parole esatte, assembly invece è scorretto.

Per quanto riguarda i link, ho pure scritto "fatevi una ricerca su google"...

E comunque il layer di ASTRAZIONE non e' detto che vada scritto in un linguaggio di alto livello! Il layer di ASTRAZIONE rende astratto l'hardware per il programmatore che scrive applicazione "on top", il layer stesso invece puo' benissimo essere scritto in assembler, ovviamente non tutto, sarebbe da pazzi ed ingestibile, ma almeno le funzionalita' 'core'. I linguaggi di alto livello invece al 99% creano codice macchina piu' lungo (porca miseria ma perche' parlate di cose di cui evidentemente ignorate il significato, senza offesa...). C/C++ crea un codice macchina efficiente ma e' davvero una mosca bianca.

Per quanto riguarda .NET, la piattaforma e' nata per SEMPLIFICARE la programmazione, PERMETTERE anche a programmatori meno esperti di scrivere codice complesso e rendere OMOGENEO l'uso di diversi linguaggi di programmazione in un unico progetto, questo al COSTO di una velocita' di esecuzione minore (dal momento che gli eseguibili .NET sono in realta degli oggetti in metalinguaggio, da interpretare grazie al framework (MS ha praticamente reinventato Java...).

Ottimizzazione algoritmica? ma sapete di cosa parlate si'? chi ha detto che in assembler non si fa ottimizzazione algoritmica? ma sapete programmare in assembler?

Poi, certo che usare piu' memoria significa andare piu' veloci, infatti per uso parsimonioso della memoria non intendo "usarla di meno" bensi' "NON SPRECARLA". Non a caso nel mondo Unix si dice "La memoria non utilizzata e' cattiva memoria", proprio perche' la memoria e' il dispositivo di IO piu' veloce. ma se tu allchi 50 mega di memoria e la deallochi solo alla chiusura del programma, anche se la tua app l'ha usata per 10 secondi, questa e' buona gestione della memoria?? Con .NET, non si alloca memoria manualmente, lo fa il framework, ed il programmatore ha controllo 0 sul processo: se il framework e' fatto bene ok, altrimenti... E comunque il processo automatico e' sicuramente meno efficiente (testato personalmente, ma potete farlo pure voi il test, eseguite una app .NET ed una uguale scritta ad esempio in C++ con parti in Asm e fatemi sapere).

Minimizzazione dell'uso del file di swap significa appunto "se uso meglio la memoria, uso meno il file di swap).

XP NON e' paragonabile a FC4, dal momento che XP e' un S.O. del 2001, con la meta' di features presenti in FC4... Vuoi mettere?!??! e' come paragonare Win 98 con Win XP... Se poi intendi la velocita' di avvio... Ovvio che Linux ci mette 15 secondi in piu' ad avviarsi, proprio perche' usa meglio la memoria, ed i processi di sistema si precaricano all'avvio. Ance XP ha un sistema di prefetch, ma onestamente non e' il massimo della vita.

64 bit non e' una buona cosa se usati bene? Andatevi a ripassare un po' di architettura dei calcolatori e poi ne riparliamo.

In definitiva: certo che e' piu' comodo scrivere con linguaggi di altissimo livello, ci perdo la meta' del tempo, ma pi non ci lamentiamo di dover prendere il PC all'ultimo grido con minimo 1 giga di ram per ragionare... Gia con XP 512 Mb erano "d'obbligo" per farlo rendere al meglio...

Fine dello sfogo.

Ciao :) ah, sempre senza offesa!

mjordan

26-01-2006, 10:24

Azz mi avete fregato :rotfl:

^-fidel-^

26-01-2006, 10:31

Dimenticavo...
Ovviamente, tutto il discorso NON nasce dal solito flame contro Microsoft, anzi... E' una semplice disquisizione sull'efficienza dei metodi di programmazione degli uomini di Redmond. Nessuno ha mai detto che tutti i programmi MS fanno schifo, ci mancherebbe. Quello che almeno io obietto e' che, oltre a programmare meglio, potrebbere fare qualcosa di davvero innovativo per i loro sistemi (invece che reinventare l'acqua calda come spesso e' stato fatto).
Spero che con il nuovo Windows (visto il tempo che ci mettono per tirarlo fuori) le cose cambino. Secondo me, se ci fosse piu' concorrenza (ed il mercato informatico e' davvero un'anomalia nel mercato internazionale), avremmo visto un sistema Windows sicuramente migliore di quello che c'e' adesso (mi ero illuso con win 2000, ma poi e' andato nel dimenticatoio per il futuro).

Vedremo Vista, spero in meglio.

diabolik1981

26-01-2006, 10:36

^-fidel-^

26-01-2006, 10:39

Ancora una cosa (emh sono un po' pedante lo ammetto).

Caro fek, ognuno ha le sue idee, pero' non puoi dire che un programma scritto con un linguaggio di alto livello sia piu' veloce di uno scritto in assembler... Cioe', proprio non sta in piedi, per la natura stessa del linguaggio asm, che e' la cosa piu' vicina alla macchina, e permette il controllo completo sullo stesso. Certo, non puoi mica fare tutto in asm!! sarebbe impossibile non solo per la difficolta', ma anche per la struttura dei nuovi S.O.: non a caso, anche in assembler e' possibile richiamere le funzioni fornite dalle API del S.O. con l'asm di Microsoft e' una consuetudine (mica mi metto a disegnare ad esempio una finestra pixel per pixel, e' improponibile (oltre che impossibile se voglio che compaia una finestra con le caratteristiche pensate dai programmatori MS).

Riciao

mjordan

26-01-2006, 10:40

A parte il fatto che "assembler" è perfettamente corretto (poveri noi...), non a caso MS MASM sta per Microsoft Macro Assembler, quello intel pure, ecc... Per favore non corregete l'uso di parole esatte, assembly invece è scorretto.

No. L'assembler è il programma che "assembla" le istruzioni mnemoniche che si chiamano "assembly". Il MASM è un'assembler che crea codice oggetto dal codice assembly.

E comunque il layer di ASTRAZIONE non e' detto che vada scritto in un linguaggio di alto livello! Il layer di ASTRAZIONE rende astratto l'hardware per il programmatore che scrive applicazione "on top", il layer stesso invece puo' benissimo essere scritto in assembler, ovviamente non tutto, sarebbe da pazzi ed ingestibile, ma almeno le funzionalita' 'core'. I linguaggi di alto livello invece al 99% creano codice macchina piu' lungo (porca miseria ma perche' parlate di cose di cui evidentemente ignorate il significato, senza offesa...). C/C++ crea un codice macchina efficiente ma e' davvero una mosca bianca.

Mamma mia che presunzione... :asd: Sei uno di quelli che nel 2006 crede di riuscire a scrivere codice assembly migliore di quello che genera un compilatore?
Hai mai sentito parlare di autovettorizzazione, hot and cold partitioning, SSA ...
Ma per favore... Senza contare che i compilatori sono per primo strumenti di diagnosi.
Quello che parla di cose che non conosce sei proprio tu...

Ottimizzazione algoritmica? ma sapete di cosa parlate si'? chi ha detto che in assembler non si fa ottimizzazione algoritmica? ma sapete programmare in assembler?

Mi posti uno spezzone di codice che implementa una tabella hash a indirizzamento aperto con risoluzione di conflitto mediante hashing digitale? Programmata in assembly :rotfl:

In definitiva: certo che e' piu' comodo scrivere con linguaggi di altissimo livello, ci perdo la meta' del tempo, ma pi non ci lamentiamo di dover prendere il PC all'ultimo grido con minimo 1 giga di ram per ragionare... Gia con XP 512 Mb erano "d'obbligo" per farlo rendere al meglio...

Fine dello sfogo.

Ciao :) ah, sempre senza offesa!

Se oggi dovessimo scrivere in assembly, la maggiorparte dei programmi non vedrebbero mai la luce. Jeff Duntemann, Assembly Language Step-by-Step, John Wiley & Sons.
:rotfl:

mjordan

26-01-2006, 10:46

Ancora una cosa (emh sono un po' pedante lo ammetto).

Caro fek, ognuno ha le sue idee, pero' non puoi dire che un programma scritto con un linguaggio di alto livello sia piu' veloce di uno scritto in assembler... Cioe', proprio non sta in piedi, per la natura stessa del linguaggio asm, che e' la cosa piu' vicina alla macchina, e permette il controllo completo sullo stesso.

Non consideri una cosa che banale non è. La complessità. Qualsiasi algoritmo di complessità non banale probabilmente viene generato molto piu' efficientemente da un compilatore che non uno scritto a mano. Ma forse tu parlavi dei cicli che stampano "Hello World" sullo schermo... :asd:

^-fidel-^

26-01-2006, 10:48

Perchè non mandi il tuo curriculum a Microsoft? Chissà che non migliorino le cose (TM)

Ci lavoro gia', ma non nell'ambito del S.O. Per lavorare su Windows devi trasferirti in america... Per quanto concesso dalle mie possibilita', faccio il possibile, ma ti ricordo: non ho detto che MS non sa programmare (basta vedere il set di API che forniscono, e' molto buono). Reputo solo che ci siano degli aspetti a livello di progetto del SO che (a mio parere ripeto) possono essere migliorati. Ah, guarda che l'asm in Microsoft si usa eccome, solo che va scomparendo (dal momento che il know-how dei programmatori va ahimè diminuendo col tempo - ora non fraintendetemi, non voglio dire che so programmare solo io, per favore!).Tra l'altro, mica tutti i migliori programmatori lavorano in Microsoft! Anzi, a mio parere degli ottimi programmatori li trovate nelle realta' piu' piccole.

^-fidel-^

26-01-2006, 11:01

No. L'assembler è il programma che "assembla" le istruzioni mnemoniche che si chiamano "assembly". Il MASM è un'assembler che crea codice oggetto dal codice assembly.

Possiamo disquisire a lungo, e' solo un problema di terminologia. Su alcuni libri viene chiamato assembler sia il linguaggio che il compilatore, in altri invece si fa distinzione tra assembler ed assembly, ma sono inezie...

Mamma mia che presunzione... :asd: Sei uno di quelli che nel 2006 crede di riuscire a scrivere codice assembly migliore di quello che genera un compilatore?
Hai mai sentito parlare di autovettorizzazione, hot and cold partitioning, SSA ...
Ma per favore... Senza contare che i compilatori sono per primo strumenti di diagnosi.
Quello che parla di cose che non conosce sei proprio tu...

Aridaje... Ma guarda che ho detto che in asm si scrivono solo PARTI di programma (o direttamente nel codice con opportuni tag, o in moduli separati richiamabili come funzioni... E' ovvio che un programma complesso non puo' essere scritto in Asm, senno' che cosa sono stati creati a fare i compilatori? Conoscere come un compilatore genere determinate istruzioni serve proprio a sostituire quelle parti meno efficienti con codice Asm scritto a mano.
Hai perfettamenete ragione con il tuo discorso, peccato che hai travisato le mie parole (o sono stao io poco chiaro).

Mi posti uno spezzone di codice che implementa una tabella hash a indirizzamento aperto con risoluzione di conflitto mediante hashing digitale? Programmata in assembly :rotfl:

Idem come sopra... Cmq se vuoi ti posto un rootkit scritto completamente in assempler (o assembly che dir si voglia). Questo non per dire che in Asm si fa tutto, anzi, e' la peggiore idea che un programmatore possa avere. Pero' non bisogna scartere l'asm a priori.

Se oggi dovessimo scrivere in assembly, la maggiorparte dei programmi non vedrebbero mai la luce. Jeff Duntemann, Assembly Language Step-by-Step, John Wiley & Sons.
:rotfl:

Appunto :)

mjordan

26-01-2006, 11:01

Ci lavoro gia', ma non nell'ambito del S.O. Per lavorare su Windows devi trasferirti in america... Per quanto concesso dalle mie possibilita', faccio il possibile, ma ti ricordo: non ho detto che MS non sa programmare (basta vedere il set di API che forniscono, e' molto buono). Reputo solo che ci siano degli aspetti a livello di progetto del SO che (a mio parere ripeto) possono essere migliorati. Ah, guarda che l'asm in Microsoft si usa eccome, solo che va scomparendo (dal momento che il know-how dei programmatori va ahimè diminuendo col tempo - ora non fraintendetemi, non voglio dire che so programmare solo io, per favore!).Tra l'altro, mica tutti i migliori programmatori lavorano in Microsoft! Anzi, a mio parere degli ottimi programmatori li trovate nelle realta' piu' piccole.

Perchè per lavorare sul solitario invece basta stare in Italia? :rotfl: :rotfl: :rotfl:
TUTELATELO!!!!! :rotfl:

^-fidel-^

26-01-2006, 11:06

^-fidel-^

26-01-2006, 11:08

Perchè per lavorare sul solitario invece basta stare in Italia? :rotfl: :rotfl: :rotfl:
TUTELATELO!!!!! :rotfl:

Vabbè se siamo a 'sto livello allora... No comment

mjordan

26-01-2006, 11:21

Vabbè se siamo a 'sto livello allora... No comment

Non ti offendere, siamo in tono scherzoso. ;)
Il problema è che tu asserisci delle cose come dati di fatto, quando magari quelle cose sono già state fatte (sicuramente già state fatte). Parli di "metodi di ottimizzazione" neanche il codice Windows fosse rilasciato sotto GPL. E disquisisci sul fatto che i sistemi Microsoft siano "lenti" quando ti ho detto che quello è un SO che esce fra un anno e deve far girare i computer dei prossimi 5 anni. Inoltre non ho capito che ci azzecca la questione "garbage collection" delle applicazioni se stiamo parlando di SO.

fek

26-01-2006, 11:34

A parte il fatto che "assembler" è perfettamente corretto (poveri noi...), non a caso MS MASM sta per Microsoft Macro Assembler, quello intel pure, ecc... Per favore non corregete l'uso di parole esatte, assembly invece è scorretto.

Assembler significa 'assemblatore', Microsoft Macro Assembler e' l'assemblatore di macro di Microsoft. Mentre assembly e' il linguaggio :)

Per quanto riguarda i link, ho pure scritto "fatevi una ricerca su google"...

Powered by Gughel?

Ottimizzazione algoritmica? ma sapete di cosa parlate si'? chi ha detto che in assembler non si fa ottimizzazione algoritmica? ma sapete programmare in assembler?

Ehm, un pochetto si'.

64 bit non e' una buona cosa se usati bene? Andatevi a ripassare un po' di architettura dei calcolatori e poi ne riparliamo.

Ehm, hai capito quello che ho scritto sui puntatore di dimensione doppia che occupano piu' memoria quindi causano piu' cache-miss?

Ancora una cosa (emh sono un po' pedante lo ammetto).

Caro fek, ognuno ha le sue idee, pero' non puoi dire che un programma scritto con un linguaggio di alto livello sia piu' veloce di uno scritto in assembler...

Oh ma certo che lo posso dire. Ti dico di piu', con i moderni processori non c'e' assolutamente modo che tu possa scrivere codice assembly che sia piu' veloce di cio' che puo' produrre un compilatore, e questo per svariati motivi:

- Nessun umano puo' conoscere per intero il modello prestazionale di una CPU, non puo' conoscere le latenze di tutte le istruzioni, non puo' conoscere le condizioni in cui queste latenze si modificano; inoltre un umano non e' in grado di fare un'analisi globale del codice per capire come posizionare il codice per limitare i cache miss, l'ordine nel quale effettuare gli accessi alla memoria, come posizionare i blocchi di dati per evitare l'aliasing delle linee di cache, etc etc... Tutto questa base di nozioni e' invece inserita man mano nel compilatore, cosa che un singolo essere umano non puo' fare.

- Un umano non e' in grado di ottimizzare l'allocazione dei registri come puo' farlo un compilatore (e' un problema NP-Completo per altro). Anche avendo tutta la base di nozioni di cui sopra, un compilatore sara' inevitabilmente piu' performante nell'allocare i registri di quanto possa essere un qualunque umano. Questo e' ancora piu' importante sulle architetture X86.

- Un umano non e' in grado di fare un analisi del codice basata sul suo profiling e decidere come sistemare i codepath di conseguenza per migliorare gli accessi alla cache.

Ma a me la teoria piace poco, sono un praticone: ti do' una ventina di righe di C++ che fanno parte di un inner loop che ho dovuto ottimizzare in passato. Scrivi in assembly del codice piu' veloce se ci riesci, ti do' anche una settimana di tempo. Ho scritto quel codice in 20 minuti in C++ ed ho passato due settimane per ottimizzarlo in assembly... alla fine ho tenuto la versione C++, non c'era modo di scrivere codice migliore di quello prodotto dal compilatore. Come l'ho fatto andare due volte piu' veloce? Facendo assunzioni sul dominio del problema e sulla natura della memoria nella quale stavo scrivendo (AGP) e codificando queste assunzioni in C++.

E correggo leggermente la mia affermazione precedente: anche tralasciando le ottimizzazioni algoritmiche che per ovvi motivi su codice assembly sono offuscate dalla mancanza di struttura del codice, nel 99.99% dei casi non riuscirai a scrivere comunque un metodo piu' veloce di cio' che produce un ottimo compilatore C++ oppure un ottimo JIT per Java/C#.

Qui non si tratta di avere proprie idee o meno, qui si tratta di sapere di che cosa si sta parlando ;)

fek

26-01-2006, 11:40

Non consideri una cosa che banale non è. La complessità. Qualsiasi algoritmo di complessità non banale probabilmente viene generato molto piu' efficientemente da un compilatore che non uno scritto a mano. Ma forse tu parlavi dei cicli che stampano "Hello World" sullo schermo... :asd:

E' proprio questo il punto infatti :)

Produrre codice a basso livello performante e' un'attivita' che il cervello umano non gradisce, perche' e' un'attivita' inerentemente algoritmica nella stragrande maggioranza delle situazioni. E il cervello umano non e' granche' con gl'algoritmi. Dove il cervello umano ha il vantaggio e' nel conoscere dettagli del problema da risolvere che permettono scorciatoie e poi deve codificare questi dettagli in un linguaggio il piu' possibile ad alto livello. Da qui in poi e' compito del compilatore il passo algoritmico per produrre il codice a basso livello migliore possibile, cosa nella quale la macchina eccelle.

Con la complessita' raggiunta dalle architetture odierne, un uomo non e' piu' in grado di fare quell'ultimo passo in maniera anche solo paragonabile a come lo puo' fare una macchina. Chiunque ha dato un'occhiata a VTune (ci ho passato le notti sigh) sa di quanti e quali parametri bisogna tenere conto e quanto sia complesso il modello prestazionale di una CPU X86. Non e' piu' un Pentium a 90mhz o un 486 a 66 sui quali scrivevo sempre codice assembly piu' veloce di qualunque compilatore, perche' il modello prestazionale era banale :)

^-fidel-^

26-01-2006, 11:42

Non ti offendere, siamo in tono scherzoso. ;)
Ok come non detto :)
Il problema è che tu asserisci delle cose come dati di fatto, quando magari quelle cose sono già state fatte (sicuramente già state fatte). Parli di "metodi di ottimizzazione" neanche il codice Windows fosse rilasciato sotto GPL. E disquisisci sul fatto che i sistemi Microsoft siano "lenti" quando ti ho detto che quello è un SO che esce fra un anno e deve far girare i computer dei prossimi 5 anni.

Verissimo, hai ragione. Allora puntualizzo. Penso che un SO che esce, mettiamo, nel 2006, deve girare bene sui computer che nel 2006 sono di fascai media, e meravigliosamente sui computer di fascia alta. Non dico mica che debbano girare sui 486 eh ;) Ma MS che fa? Tira fuori un SO che gira bene sui PC di fascia alta-top della gamma e gira male (o al meglio discretamente) su pc di fascia media, ed in 5 anni tira fuori solo patch di correzione bug o 2/3 nuove features con i vari SP. Poi girera' meravigliosamente sui pc dell 2007/2008. Forse perche' l'ottimizzazione non e' il loro obiettivo? Questo volevo dire... Non farebbero forse meglio a ragionare come in Mac? Cioe' tirare fuori un SO che va gia' benissimo sui pc esistenti, e con gli anni fare delle SP che oltre a correggere errori inseriscono nuove features per stare al passo con i tempi e sfruttare le nuove capacita' di calcolo permesse dai nuovi PC. Non a caso, XP non e' migliorato quasi per nulla in termini di features dal 2001, e senza presunzione si vede... (fatti appunto un giro con Mac o con KDE 3.5 per linux).

Inoltre non ho capito che ci azzecca la questione "garbage collection" delle applicazioni se stiamo parlando di SO.
Oltre a parlare di SO, parlavo pure delle applicazioni per MS scritte con linguaggi tipo C#, che non sono il massimo per quanto riguarda la gestione della memoria. Questo non vuol dire ovviamente che non esistano programmi davvero ben fatti sotto windows (ok costano migliaia di euro, ma Autocad ad esempio e' fantastico, o Matlab, ecc...)

Ciao

fek

26-01-2006, 11:44

non voglio dire che so programmare solo io, per favore!.

Ecco, non dirlo :asd:

fek

26-01-2006, 11:45

Oltre a parlare di SO, parlavo pure delle applicazioni per MS scritte con linguaggi tipo C#, che non sono il massimo per quanto riguarda la gestione della memoria.

E perche' mai? Ti sfido a gestire la memoria di un'applicazione che non sia un Hello World meglio di quanto faccia il Garbage Collector di .NET oppure quello della JVM di Sun. Sai come funzionano vero?

diabolik1981

26-01-2006, 11:52

Verissimo, hai ragione. Allora puntualizzo. Penso che un SO che esce, mettiamo, nel 2006, deve girare bene sui computer che nel 2006 sono di fascai media, e meravigliosamente sui computer di fascia alta. Non dico mica che debbano girare sui 486 eh ;) Ma MS che fa? Tira fuori un SO che gira bene sui PC di fascia alta-top della gamma e gira male (o al meglio discretamente) su pc di fascia media, ed in 5 anni tira fuori solo patch di correzione bug o 2/3 nuove features con i vari SP.

Fai qualche esempio perchè io ne ho 2 freschi freschi. XP è uscito nel 2001, l'ho installato per la prima volta su un Pentium 2 350 MHZ con 256 Ram, ed andava davvero lento,ma parlo di una macchina di fine 1997, ovvero vecchia di 4 anni e quindi di fascia bassissima. Poi l'ho installato su un Duron 800 del 2001 con 256 Ram e li andava bene, e di certo il Duron 800 non era il rop di gamma del 2001 come processore. Successivamente l'ho messo su un XP 2800+ e sull'attuale A64 3500+, con incrementi non molto avvertibile tra il 2800 e il 3500 (nonostante il raddoppio della RAM), ora 1 GB). Quindi mi sa che l'hai detta grossa.

^-fidel-^

26-01-2006, 11:52

E' proprio questo il punto infatti :)

Produrre codice a basso livello performante e' un'attivita' che il cervello umano non gradisce, perche' e' un'attivita' inerentemente algoritmica nella stragrande maggioranza delle situazioni. E il cervello umano non e' granche' con gl'algoritmi. Dove il cervello umano ha il vantaggio e' nel conoscere dettagli del problema da risolvere che permettono scorciatoie e poi deve codificare questi dettagli in un linguaggio il piu' possibile ad alto livello. Da qui in poi e' compito del compilatore il passo algoritmico per produrre il codice a basso livello migliore possibile, cosa nella quale la macchina eccelle.

Con la complessita' raggiunta dalle architetture odierne, un uomo non e' piu' in grado di fare quell'ultimo passo in maniera anche solo paragonabile a come lo puo' fare una macchina. Chiunque ha dato un'occhiata a VTune (ci ho passato le notti sigh) sa di quanti e quali parametri bisogna tenere conto e quanto sia complesso il modello prestazionale di una CPU X86. Non e' piu' un Pentium a 90mhz o un 486 a 66 sui quali scrivevo sempre codice assembly piu' veloce di qualunque compilatore, perche' il modello prestazionale era banale :)

Verissimo, e infatti l'asm si usa raramente. Io inizialmente parlavo di Ams sull'interfacciamento alle periferiche, oppure in alcune fasi della gestione dati. Il linguaggio di programmazione ad alto livello e' necessario (e ripeto necessario) per implementare algoritmi complessi, da qui la necessita' di utilizzare un buon compilatore (non a caso il linguaggio C/C++ con il relativo compilatore e' il piu' usato, Watcom ancora in cima, quelo MS rincorre).
Pero' vorrei aggiungere: fermo restando quelo che ho scritto nei precedenti post, non sono mica un teorizzatore del ritorno all'asm come linguaggio principale! Oltre al fatto che asm andrebbe usato sicuramente di piu' a mio avviso per alcune funzionalita', dipende pure da come una persona programma! Per implementare un algoritmo, ci sono tanti modi per farlo. Per non parlare poi dell'algoritmo stesso. Nella mia non lunghissima carriera da programmatore, ho visto algoritmi implementati in maniere molto diverse, con conseguenti diversita' di prestazioni. Ottimizzare significa proprio rendere migliore un qualcosa fatto in prima battuta. Mi limito a dire che, a mio parere, molti aspetti del SO Windows sono implementati con la finalita' "basta che funzioni", magari pero' e' lento (e non e' detto che funzioni benissimo). Infatti, se e' vero che nessun programma e' esente da bug, e' anche vero che molti programmi MS sono davvero troppo pieni di bug per essere programmi commerciali.
Sembra pero' che con Vista non stiano facendo il solito errore, a guardare il ritardo della sua uscita. Sto apsettando infatti per constatare se sara' cosi' oppure no. Sicuramente una cosa la penso: che Windows sia da molti sopravvalutato (che non vuol dire che non sia un buon prodotto eh!). Pero' non mi spiego come mai sia cosi' largamente usato (non me lo psiego se mi fermo a pensare ai motivi tecnici :))

^-fidel-^

26-01-2006, 12:00

E perche' mai? Ti sfido a gestire la memoria di un'applicazione che non sia un Hello World meglio di quanto faccia il Garbage Collector di .NET oppure quello della JVM di Sun. Sai come funzionano vero?

Secondo me JVM gestisce meglio che .NET. Poi se proprio dobbiamo fare un raffronto, la gestione "classica" della memoria (fatta cioe' a mano, con le 'malloc' in C o con le 'new' in C++) per poi liberare i puntatori ancora a mano e' cmq piu' efficiente (non a caso i programmi 'mission critical' non sono mica scritti in .NET o Java...). Magari tra uno o due d'anni, quando la differenza tra un uso della memoria automatico ed uno manuale non sara' percettibile (data la crescente velocita' dei pc) allora tutti useranno .NET (o framework similari, che garantiscono un progetto di programma complesso a fronte di una semplicita' realizzativa).
Poi perche' sfidarmi? Se la gestione della memoria in .NET fosse cosi' grandiosa, tutti lo userebbero, ma non mi sembra sia cosi' al momento. Sembra che questo discorso lo faccia solo io in tutto il mondo...

fek

26-01-2006, 12:01

Verissimo, e infatti l'asm si usa raramente. Io inizialmente parlavo di Ams sull'interfacciamento alle periferiche, oppure in alcune fasi della gestione dati. Il linguaggio di programmazione ad alto livello e' necessario (e ripeto necessario) per implementare algoritmi complessi, da qui la necessita' di utilizzare un buon compilatore (non a caso il linguaggio C/C++ con il relativo compilatore e' il piu' usato, Watcom ancora in cima, quelo MS rincorre).

Veramente per architetture Intel il VC2005 e' secondo solo al compilatore Intel (per ovvi motivi). Sia come codice prodotto sia come aderenza allo standard, il VC2005 e' un mostro. E lo comprendo visto che il team lead e' il chairmain del comitato di standardizzazione del C++ (Herb Sutter).

Oltre al fatto che asm andrebbe usato sicuramente di piu' a mio avviso per alcune funzionalita', dipende pure da come una persona programma!

Ma proprio no. Uno puo' programmare un po' come gli pare ma non riuscira' nel 99.99% dei casi a produrre codice migliore di un ottimo compilatore C++. Non ha piu' alcun senso scrivere praticamente nulla in assembly. Ho scritto alcune centinaia di migliaia di righe di codice in BW2 e ne ho scritte forse una decina in assembly, ma giusto perche' non avevo alcun modo di fare quella cosa li'. E non posso dire di non aver avuto alcune strette necessita' prestazionali :D

Infatti, se e' vero che nessun programma e' esente da bug, e' anche vero che molti programmi MS sono davvero troppo pieni di bug per essere programmi commerciali.

E di nuovo. Hai delle statistiche precise o parli per sentito dire? Mi fai vedere l'analisi dei difetti per linea di codice sul software Microsoft dal quale stai attingendo per questa affermazione?

^-fidel-^

26-01-2006, 12:05

Fai qualche esempio perchè io ne ho 2 freschi freschi. XP è uscito nel 2001, l'ho installato per la prima volta su un Pentium 2 350 MHZ con 256 Ram, ed andava davvero lento,ma parlo di una macchina di fine 1997, ovvero vecchia di 4 anni e quindi di fascia bassissima. Poi l'ho installato su un Duron 800 del 2001 con 256 Ram e li andava bene, e di certo il Duron 800 non era il rop di gamma del 2001 come processore. Successivamente l'ho messo su un XP 2800+ e sull'attuale A64 3500+, con incrementi non molto avvertibile tra il 2800 e il 3500 (nonostante il raddoppio della RAM), ora 1 GB). Quindi mi sa che l'hai detta grossa.

Non credo, dal momento che mi sembra che hai ribadito il concetto che ho espresso prima.
Mi dici che XP andava bene su un pc di fascia media del 2001, e magari andava meravigliosamente (che e' diverso da 'bene' per me) su un pentium 3. Ovvio che poi sui pc del 2004 il SO non puo' piu' migliorare come prestazioni, se lo stesso rimane immutato: prima o poi raggiunge il massimo delle prestazioni.
O ho capito male?
Io asserivo proprio che, a mio parere, doveva andare benissimo su un Duron 800 del 2001, per poi essere potenziato con i SP per sfruttare al meglio un Athlon tra il 2800 ed il 3500. Senno' il nuovo PC non te lo godi :D
Invece cosi' te lo godi al meglio uno/due anni dopo che e' uscito il SO, e poi negli anni successivi il PC piu' potente ti serve solo per o videogiochi (o con programmi mission critical come Photoshop ad alti livelli o Matlab)

fek

26-01-2006, 12:07

Secondo me JVM gestisce meglio che .NET. Poi se proprio dobbiamo fare un raffronto, la gestione "classica" della memoria (fatta cioe' a mano, con le 'malloc' in C o con le 'new' in C++) per poi liberare i puntatori ancora a mano e' cmq piu' efficiente (non a caso i programmi 'mission critical' non sono mica scritti in .NET o Java...).

Eh ma grazie, quasi tutti i mission critical devono avere garanzie strette sui tempi di esecuzione, non possono avere un GC sotto che interrompa il processo per definizione in maniera asincrona e non possono neppure girare sotto Windows o Linux (non sono kernel real-time).
E leggi bene, avere garanzie sui tempi di esecuzione non vuol dire che debbano essere il piu' ottimizzati possibile, significa che se un task deve terminare entro un tempo X, devo essere garantito che lo faccio e non mi interessa che termini in meta' di X.
La cosa si puo' comunque risolvere parzialmente con .NET 2.0 ma mi sembra che il GC ancora non garantisca tempi di esecuzione fissi per ogni sweep di generazione. Ci devo guardare.

Dal punto di vista dell'efficienza, invece, sta dicendo un'enormita'. Specifica in quali condizioni la gestione esplicita' della memoria e' piu' efficiente di un garbage collector. Nella maggior parte dei casi e' vero l'esatto contrario (modelli con frequenti allocazioni di oggetti di piccole dimensioni). Lo sai che matematicamente non esiste un algoritmo di allocazione/deallocazione della memoria che e' sempre piu' efficiente di tutti gl'altri? C'e' sempre un caso patologico che stende qualunque algoritmo di allocazione.

Sembra che questo discorso lo faccia solo io in tutto il mondo...

E la cosa dovrebbe farti sorgere un dubbio :D

^-fidel-^

26-01-2006, 12:16

Veramente per architetture Intel il VC2005 e' secondo solo al compilatore Intel (per ovvi motivi). Sia come codice prodotto sia come aderenza allo standard, il VC2005 e' un mostro. E lo comprendo visto che il team lead e' il chairmain del comitato di standardizzazione del C++ (Herb Sutter).
Si' hai ragione, sono rimasto a vecchi dati :) Il VC2005 e' ottimo (tra l'altro anch'io uso quello), e Watcom l'ho abbandonato. Ho scritto una cosa che magari andava bene 4 anni fa :D

Ma proprio no. Uno puo' programmare un po' come gli pare ma non riuscira' nel 99.99% dei casi a produrre codice migliore di un ottimo compilatore C++. Non ha piu' alcun senso scrivere praticamente nulla in assembly. Ho scritto alcune centinaia di migliaia di righe di codice in BW2 e ne ho scritte forse una decina in assembly, ma giusto perche' non avevo alcun modo di fare quella cosa li'. E non posso dire di non aver avuto alcune strette necessita' prestazionali :D

Si', infatti ho parlato anche di "come una pesona programma" nel senso di scrivere un codice efficiente. Oltre ad usare un buon compilatore (e siamo d'accordo), ok, si puo' usare Asm a mio parere per migliorar ulteriormente, ma gia' programmando bene senza sare l'asm sarebbe un grande passo in avanti (e molti a mio parere programmano senza tenere conto dell'ottimizzazione). Vorrei chiarire, non intendo ottimizzazione=scrivere in asm! Asm puo' aiutare (e molto inalcune situazioni) ma non e' lo strumento necessario per scrivere codice ottimizzato. Spero di essere stato piu' chiaro ora :)

E di nuovo. Hai delle statistiche precise o parli per sentito dire? Mi fai vedere l'analisi dei difetti per linea di codice sul software Microsoft dal quale stai attingendo per questa affermazione?
Vedo di postartele a breve. Onestamente, a parita' di complessita', non ho ancora visto un qualunque programma cosi' pieno di bug come un SO MS appena uscito (almeno prima di Vista). Anche loro sanno fare meglio! (vedi le varie suite Office). Se solo conti quante patch sono uscite negli anni per WinXP... Cmq ripeto, vedo di postarti i dati, se parliamo piu' approfonditamente dei difetti per riga di codice.

fek

26-01-2006, 12:24

Si', infatti ho parlato anche di "come una pesona programma" nel senso di scrivere un codice efficiente. Oltre ad usare un buon compilatore (e siamo d'accordo), ok, si puo' usare Asm a mio parere per migliorar ulteriormente, ma gia' programmando bene senza sare l'asm sarebbe un grande passo in avanti (e molti a mio parere programmano senza tenere conto dell'ottimizzazione). Vorrei chiarire, non intendo ottimizzazione=scrivere in asm! Asm puo' aiutare (e molto inalcune situazioni) ma non e' lo strumento necessario per scrivere codice ottimizzato. Spero di essere stato piu' chiaro ora :)

Ripeto: non c'e' alcun modo tale che tu possa produrre codice asm per Intel migliore di quello prodotto da un VS2005 oppure dal compilatore Intel. Questo e' proprio insuperabile perche' usa nozioni sull'architettura che loro non rendono note all'esterno.

Prova, prendi un qualunque algoritmo in C++ e prova a scriverlo piu' velocemente in asm. Poi postami il codice C++ e la tua versione asm che controllo ;)

Vedo di postartele a breve. Onestamente, a parita' di complessita', non ho ancora visto un qualunque programma cosi' pieno di bug come un SO MS appena uscito (almeno prima di Vista). Anche loro sanno fare meglio! (vedi le varie suite Office). Se solo conti quante patch sono uscite negli anni per WinXP... Cmq ripeto, vedo di postarti i dati, se parliamo piu' approfonditamente dei difetti per riga di codice.

Mi faresti un favore a postare quei dati perche' io non li ho mai visti. E francamente non penso che li vedro' mai visto che questa analisi non esiste pubblica :D

^-fidel-^

26-01-2006, 12:28

Eh ma grazie, quasi tutti i mission critical devono avere garanzie strette sui tempi di esecuzione, non possono avere un GC sotto che interrompa il processo per definizione in maniera asincrona e non possono neppure girare sotto Windows o Linux (non sono kernel real-time).
Emh puoi essere piu' chiaro? Il discorso mi interessa particolarmente :)

Dal punto di vista dell'efficienza, invece, sta dicendo un'enormita'. Specifica in quali condizioni la gestione esplicita' della memoria e' piu' efficiente di un garbage collector. Nella maggior parte dei casi e' vero l'esatto contrario (modelli con frequenti allocazioni di oggetti di piccole dimensioni). Lo sai che matematicamente non esiste un algoritmo di allocazione/deallocazione della memoria che e' sempre piu' efficiente di tutti gl'altri? C'e' sempre un caso patologico che stende qualunque algoritmo di allocazione.
Si lo so, ma evidentemente ho usato in modo errato la parola "efficienza". Parlavo della rapidita' dell'esecuzione di un processo in media, poi e' normale che alcuni modelli vadano meglio con una gestione di tipo garbage, soprattutto quando la quantita' di memoria presente sulla macchina non e' un problema. Parlavo semplicemente dei porgrammi usati comunemente, ma anche di molte apps mission critical (non riesco a farti nomi espliciti giacche' mi riferisco ad apps 'ad hoc' scritte per le aziende su richiesta, caso per caso. Convengo quindi quando parli di allocazione manuale come il sistema non assolutamente migliore: pero' nella media si' :)

E la cosa dovrebbe farti sorgere un dubbio :D
Di dubbi ne ho piu' di uno ;) Per ora penso questo, ma sono sicuro che i metodi automatici saranno non tra molto tempo davvero efficienti (e si studia proprio questo, dal momento che le apps, sempre piu' complesse, non possono essere scritte allocando la memoria manualmente, senno' si finisce di scrivere codice in 2 anni invece che in 6 mesi!).

^-fidel-^

26-01-2006, 12:39

Prova, prendi un qualunque algoritmo in C++ e prova a scriverlo piu' velocemente in asm. Poi postami il codice C++ e la tua versione asm che controllo ;)
Ci provo, e ti mando tutto. ;) magari pero' meglio se mi dici che algoritmo devo usare per questo test! :)
Esattamente un anno e mezzo fa la prova l'ho gia' fatta, e quello in asm risultava piu' rapido. Sicuramente ora lo stesso algoritmo andra' in modo identico sia fatto in C che in asm, vista la potenza acquisita dai PC in un anno e mezzo (roba che quelle 100 istruzioni in piu' ovviamente non vedi neanche che ci sono...). Magari ora le cose non stanno piu' cosi', e quindi scrivere in Asm e' perfettamente inutile (per quanto riguarda l'ottimizzazione intendo, perche' come anche hai detto tu prima per alcune cose va ancora usato necessariamente se si vuole risparmiare tempo). Sicuramente provero' :D
Cmq poi stiamo parlando di C/C++, che e' il miglior compilatore, per come genera il codice eseguibile. Ma credi che tutti usano il C/C++? Per quanto riguarda il SO, sicuramente si', ma poi bisogna vedere COME si programma in C. Per le altre apps invece... Vedo molti usare ancora Visual Basic Per grosse apps...
Comunque ribadisco, a prescindere se asm possa rendere piu' efficiente un programma, il modo migliore per creare un programma efficiente e' saper scrivere bene il codice (e non tutti sono preparati come te purtroppo).

fek

26-01-2006, 12:41

Emh puoi essere piu' chiaro? Il discorso mi interessa particolarmente :)

L'idea di un task real time (per un'applicazione mission critical) e' quella di garantire che il suo tempo di esecuzione sia minore di un tempo X. Immagina un software che gestisce l'ABS: se un task calcola che da qui all'impatto passeranno 0.5s e fa partire il task che agisce sui freni, il task deve garantire di finire entro 0.5s, altrimenti la macchina si schianta :D
Allo scheduler non interessa che il task finisca in 0.4s o in 0.000001s, gli interessa che finisca prima di 0.5s. Ovvero, non gli interessa quanto sia ottimizzato, gli interessa che garantisca il tempo di esecuzione. Se durante l'esecuzione del task entra un GC asincrono che magari impiega un secondo, la macchina si schianta :D

Ecco perche' i GC asincroni senza garanzie non sono adatti ad applicazioni real time. Nota che ne' Linux ne' Windows ti garantiscono che nessun interrupt venga lanciato e gestito e non ti garantiscono i tempi di esecuzione degl'handler: sia Linux sia Windows possono teoricamente prendersi tutta la CPU per un tempo indefinito.

Il software mission critical e real time non devono essere necessariamente ottimizzati, devono essere "precisi".

Si lo so, ma evidentemente ho usato in modo errato la parola "efficienza". Parlavo della rapidita' dell'esecuzione di un processo in media, poi e' normale che alcuni modelli vadano meglio con una gestione di tipo garbage, soprattutto quando la quantita' di memoria presente sulla macchina non e' un problema. Parlavo semplicemente dei porgrammi usati comunemente, ma anche di molte apps mission critical (non riesco a farti nomi espliciti giacche' mi riferisco ad apps 'ad hoc' scritte per le aziende su richiesta, caso per caso. Convengo quindi quando parli di allocazione manuale come il sistema non assolutamente migliore: pero' nella media si' :)

Non lo e' neppure nella media. Diciamo che non lo e' quasi mai. In un modello di programmazione OOP si tende a fare molte allocazioni di piccole dimensioni e questo scenario e' proprio il caso patologico degl'algoritmi implementati nelle malloc, che vanno bene in scenari con poche allocazioni di grandi dimensioni e disalocazione in ordine inverso.

Di dubbi ne ho piu' di uno ;) Per ora penso questo, ma sono sicuro che i metodi automatici saranno non tra molto tempo davvero efficienti (e si studia proprio questo, dal momento che le apps, sempre piu' complesse, non possono essere scritte allocando la memoria manualmente, senno' si finisce di scrivere codice in 2 anni invece che in 6 mesi!).

E' vero l'esatto contrario. Ho appena finito di lavorare su un'applicazione piuttosto complessa (alcuni milioni di righe di codice), con allocazione totalmente manuale. I bug piu' frequenti erano, in ordine:

- doppie deallocazioni
- memory scribbler
- memory leak

E se mi dici ancora che le applicazioni complesse hanno bisogno di allocazione manuale altrimenti ci vuole piu' tempo mi arrabbio, perche' le notti a cercare le doppie deallocazioni le passavo io :D

fek

26-01-2006, 12:45

Ci provo, e ti mando tutto. ;) magari pero' meglio se mi dici che algoritmo devo usare per questo test! :)

Un loop di skinning ad una bone :)

Prendi un numero di vertici (posizione, normale, texture coordinate, indice nelle bone) in ingresso, un vettore di matrici e trasformi ogni vertice per la matriche indicata dal suo indice nelle bone. Sono 20 righe di codice in C++, divertiti :D

^-fidel-^

26-01-2006, 12:52

fek

26-01-2006, 13:01

Ah un'ultima cosa sul garbage collection:

(piccola nota da un manuale .NET):
"Una cosa da ricordare però è che un'oggetto deputato alla distruzione non lo è immediatamente ma soltanto quando il garbage collector viene attivato ed inizia la ricerca di oggetti non utilizzati.
Quando si crea un nuovo oggetto ricordarsi sempre di implementare il metodo Dispose() per la distruzione delle risorse inutili."

Ergo, per rendere il garbage collection davvero efficiente (e far funzionare bene il garbage collector della piattaforma) bisogna comunque saper programmare bene. Se io no implemento il metodo Dispose() il mio programma funzionera', ma intanto utilizzera' male la memoria, addirittura peggio do come il garbage collector puo' fare se usato bene!

Sicuramente tu queste cose le sai gia', ma bisogna vedere in quanti lo sanno. E' una questione di metodo, e sicuramente non bisogna improvvisarsi programmatori: mica poi sono cose dell'altro mondo, pero' un po' di studio per chi si reputa un programmatore (e magari si e' limitato a leggere un paio di manuali rapidi) ci vorrebbe ;)

E' verissimo che il GC non e' la panacea di tutti i mali :D
Ad esempio contrariamente a quanto si pensa non risolve i memory leak.

Qui sta dicendo che il metodo Dispose va implementato se l'oggetto mantiene un reference a risorse che devono essere distrutte derministicamente (oggetti non managed, connessioni, file, etc etc). Per quanto riguarda la memoria, invece, anche senza Dispose questa viene rilasciata dal GC quando l'oggetto non ha piu' reference associate.

^-fidel-^

26-01-2006, 13:02

L'idea di un task real time (per un'applicazione mission critical) e' quella di garantire che il suo tempo di esecuzione sia minore di un tempo X. Immagina un software che gestisce l'ABS: se un task calcola che da qui all'impatto passeranno 0.5s e fa partire il task che agisce sui freni, il task deve garantire di finire entro 0.5s, altrimenti la macchina si schianta :D
Allo scheduler non interessa che il task finisca in 0.4s o in 0.000001s, gli interessa che finisca prima di 0.5s. Ovvero, non gli interessa quanto sia ottimizzato, gli interessa che garantisca il tempo di esecuzione. Se durante l'esecuzione del task entra un GC asincrono che magari impiega un secondo, la macchina si schianta :D

Ecco perche' i GC asincroni senza garanzie non sono adatti ad applicazioni real time. Nota che ne' Linux ne' Windows ti garantiscono che nessun interrupt venga lanciato e gestito e non ti garantiscono i tempi di esecuzione degl'handler: sia Linux sia Windows possono teoricamente prendersi tutta la CPU per un tempo indefinito.

Il software mission critical e real time non devono essere necessariamente ottimizzati, devono essere "precisi".
Ecco, non consideravo un interrupt sul kernel... Si', un kernel non realtime ha questi rischi. Ora e' tutto chiaro.

Per tutto il resto che hai scritto: mi sa che hai frainteso. Che tu abia scritto un programma di milioni di righe di codice con allocazione manuale della memoria non fa che sottolineare quello che ho detto prima (e mi sa che ti sei contraddetto): al giorno d'oggi, allocare manualmente la memoria e' ancora normalmente piu' conveniente (e tu ne sei una prova :)) mentre, in ambito OOP, data la complessita' dei programmi, puo' essere piu' semplice usare il garbage collector, anche se le prestazioni non saranno le stesse: pero' non perdi delle notti per correggere il tutto ;)
Quindi dipende da come intendi la programmazione: continuo a dire che in media e' meglio il modo manuale: e' piu' complicato, ma i risultati sono normalmente migliori in termini di prestazioni. Il garbage collection e' invece piu' semplice, ma raramente garantisce una buona prestazione (se confrontata con l'allocazione manuale).

^-fidel-^

26-01-2006, 13:07

Si' quello che hai detto su Dispose() e' vero. Ah una domanda, ma lavori al Black&White studios? :)

^-fidel-^

26-01-2006, 13:15

Per fek:

Ah, approposito di sistemi realtime, leggiti questa:

http://www.linuxhelp.it/modules.php?name=News&file=article&sid=3259

:D

fek

26-01-2006, 13:17

Per tutto il resto che hai scritto: mi sa che hai frainteso. Che tu abia scritto un programma di milioni di righe di codice con allocazione manuale della memoria non fa che sottolineare quello che ho detto prima (e mi sa che ti sei contraddetto): al giorno d'oggi, allocare manualmente la memoria e' ancora normalmente piu' conveniente (e tu ne sei una prova :))

E' l'esatto contrario ti dico, e' molto piu' conveniente non farlo in termini di tempi di sviluppo e anche di efficienza :)

Si' quello che hai detto su Dispose() e' vero. Ah una domanda, ma lavori al Black&White studios? :)

Non piu'.

^-fidel-^

26-01-2006, 13:34

E' l'esatto contrario ti dico, e' molto piu' conveniente non farlo in termini di tempi di sviluppo e anche di efficienza :)

Uhuh solo ora scopro che hai fatto la tesi con Montuschi :) il mio prof preferito senza dubbio!
Cmq ora capisco le tue posizioni (visto anche l'algoritmo di esempio che mi hai dato da implementare...): come 3D engineer e' normale non usare l'asm, con tutte le librerie grafiche che ci sono, e gli algoritmi 3d sono normalmente molto complessi. Nell'ambito 3D al giorno d'oggi l'asm e' praticamente inutile :D
Io invece mi occupo di reti, e li' l'asm mi e' tornato utile in molte occasioni (soprattutto nella gestione delle scede di rete), mentre il GC lo evito nella gestione dei buffer di comunicazione.... Sicuramente emerge questo: ogni ambiente di sviluppo ha le sue prerogative, e non c'e' metodo migliore per TUTTI gli ambiti di lavoro. Io ad esempio parlavo del non uso del GC come una buona scelta nella programmazione di rete (che e' un campo molto vasto, ma e' cmq una parte del mondo informatico).

Ciao :D

^-fidel-^

26-01-2006, 13:50

E di nuovo. Hai delle statistiche precise o parli per sentito dire? Mi fai vedere l'analisi dei difetti per linea di codice sul software Microsoft dal quale stai attingendo per questa affermazione?

Io inizierei a leggere questo (http://blogs.borland.com/davidi/archive/2005/10/09/21652.aspx).

Se e' vero che comunque Windows Vista conta circa 50 milioni di righe di codice, onestamente il 5% mi sembra eccessivo per una compagnia grande ed importante come Microsoft.
5% vuol dire 2,5 milioni di bug: non ti sembrano un po' tanti per un SO che costa centinaia di euro e che verra' distribuito in milioni di copie? Forse dovrebbero fare qualcosa in termini di organizzazione del processo produttivo per ridurre questa percentuale...

fek

26-01-2006, 13:52

Io inizierei a leggere questo (http://blogs.borland.com/davidi/archive/2005/10/09/21652.aspx).

Se e' vero che comunque Windows Vista conta circa 50 milioni di righe di codice, onestamente il 5% mi sembra eccessivo per una compagnia grande ed importante come Microsoft.
5% vuol dire 2,5 milioni di bug: non ti sembrano un po' tanti per un SO che costa centinaia di euro e che verra' distribuito in milioni di copie? Forse dovrebbero fare qualcosa in termini di organizzazione del processo produttivo per ridurre questa percentuale...

Mi porti delle statistiche effettive e non una stima in un blog basata su un numero come il 5% tirato totalmente a caso :)

^-fidel-^

26-01-2006, 14:00

Mi porti delle statistiche effettive e non una stima in un blog basata su un numero come il 5% tirato totalmente a caso :)

Veramente quel numero proviene da questo (http://www.embedded.com/showArticle.jhtml?articleID=171203287) articolo. Poi se cerchi una quantificazione ufficiale fatta da microsoft, allora puoi aspettare quanto vuoi, non uscira' mai (credo ;)). E' ovviamente una stima, onestamente ben argomentata, che non mi sembra smentita dai fatti, visti gli ultimi prodotto MS destinati al mondo consumer. Ma ti ricordi XP appena uscito? Parecchio instabile, crashava spesso, e finalmente dopo 3/4 anni e' diventato un buon sistema operativo, soprattutto finalmente stabile.
Nulla mi fa presagire il contrario per Vista (tranne forse il tempo di sviluppo), ma ripeto, non mi sembra che MS abbia come obiettivo societario l'efficienza (intesa sia come velocita' che come stabilita'), almeno per i prodotti nuovi.

diabolik1981

26-01-2006, 14:10

Un loop di skinning ad una bone :)

Ma almeno queste BONE... hanno una 4 di reggiseno? :D :D

Questa non riuscivo a trattenerla... :ciapet:

fek

26-01-2006, 14:12

Veramente quel numero proviene da questo (http://www.embedded.com/showArticle.jhtml?articleID=171203287) articolo. Poi se cerchi una quantificazione ufficiale fatta da microsoft, allora puoi aspettare quanto vuoi, non uscira' mai (credo ;)). E' ovviamente una stima, onestamente ben argomentata, che non mi sembra smentita dai fatti, visti gli ultimi prodotto MS destinati al mondo consumer. Ma ti ricordi XP appena uscito? Parecchio instabile, crashava spesso, e finalmente dopo 3/4 anni e' diventato un buon sistema operativo, soprattutto finalmente stabile.
Nulla mi fa presagire il contrario per Vista (tranne forse il tempo di sviluppo), ma ripeto, non mi sembra che MS abbia come obiettivo societario l'efficienza (intesa sia come velocita' che come stabilita'), almeno per i prodotti nuovi.

Per favore, leggiamo gli articoli prima di postarli :)

Well-written C and C++ code contains some 5 to 10 errors per 100 LOC after a clean compile, but before inspection and testing. At a 5% rate any 50 MLOC program will start off with some 2.5 million bugs.

Allora, quest'analisi dei bug per linea di codice nel software Microsoft dov'e'?

Motosauro

26-01-2006, 14:24

Non piu'.
AARRRGGHHHHHH!!! E come si fa adesso? B&W3 avrà più bug e un'acqua che sembrerà fatta di lastre di alluminio :cry:

Se non lo programma fek non gioco più a nulla :O

Scherzi a parte buona fortuna qualsiasi cosa tu stia facendo.

Per tornare all'OT
Mi spiegate perfavore la differenza concettuale fra C e Assembly?
In sostanza quello che non capisco è questo: so che parto da un sorgente ma che quello che in realtà viene eseguito è del codice binario. È il make che mi trasforma (tramite compilatore) il sorgente in binario?
Mi sono perso qualche passaggio?
Io programmo solo in linguaggi di scripting: sono un niubbo totale in quello di cui state parlando.
A tal proposito, ma allora, i linguaggi di scripting vengono compilati in realtime?

che ignoranza la mia... :fagiano:

^-fidel-^

26-01-2006, 15:09

Mi spiegate perfavore la differenza concettuale fra C e Assembly?
In sostanza quello che non capisco è questo: so che parto da un sorgente ma che quello che in realtà viene eseguito è del codice binario. È il make che mi trasforma (tramite compilatore) il sorgente in binario?
Mi sono perso qualche passaggio?
Io programmo solo in linguaggi di scripting: sono un niubbo totale in quello di cui state parlando.
A tal proposito, ma allora, i linguaggi di scripting vengono compilati in realtime?

che ignoranza la mia... :fagiano:
L'importante e' la voglia di imparare ;)

Ti spiego in soldoni il funzionamento di un compilatore e da qui le diffeneze tra c ed asm.
Come puoi immaginare, sarebbe impossibile per una persona scrivere in linguaggio macchina :) Quindi e' necessario un linguaggio, il piu' vicino possibile alla logica umana, per dialogare con la macchina. E' qui che entra in gioco il compilatore. Un compilatore non fa altro che trasformare un particolare linguaggio di dialogo tra uomo e macchina in una forma comprensibile per la macchina. In particolare, un compilatore genera da un file sorgente (in formato testo) un file in un linguaggio intermedio, chiamato file oggetto. Tale file oggetto non e' ancora computabile dalla macchina, in quanto non contiene ancora tutte le informazioni necessarie: infatti un programma puo' essere formato da piu' oggetti (provenienti da altri file di testo), contiene riferimenti a funzioni scritte da altri (le cosiddette funzioni di libreria) ecc. Quindi dopo la compilazione e' necessario un ulteriore passaggio, detto linking. il linker non fa altro che mettere insieme tutti gli offetti necessari, risolvere i riferimenti alle funzioni esterne (ad esempio quele di libreria) e generare il codice eseguibile risultante, contenente anche quelle informazioni che prima mancavano (come ad esempio "In quale locazione di memoria caricare il programma?", oppure "la variamile di nome 'pippo' a quale locazione di memoria fa riferimento?") Il codice eseguibile in realta' no e' ancora codice macchina, bensi' una forma comprensibile al sistema operativo, che lo carichera e lo eseguira' tramite il loader. E' infatti solo il SO che sa come trattare l'hardware della macchina per far eseguire le operazioni elencate nel codice eseguibile (ecco perche' un eseguibile ad esempio di Windows non "gira" su una macchina con SO linux, e viceversa).
La differenza tra C e Asm risiede nel fatto che, mentre il C, come altri, usa un linguaggio simile a quello umano, che viene interpretato a dovere dal compilatore, l'assembly e' un linguaggio in cui ogni riga di codice rappresenta una istruzione implementata nel processore della macchina. Quindi programmare in assember significa dire "nel dettaglio" le singole istruzioni (codificate in hardware dalla cpu) che la macchina deve eseguire. Con l'assembler quindi si ha accesso ad esempio ai singoli registri presenti nella cpu, e quindi risulta piu' complicato programmare, ma si ha accesso diretto all'architettura della macchina in questione. Un normale linguaggio di programmazione invece, trasforma una singola operazione (come una somma) in una serie di istruzioni macchina tali da eseguire effettivamente una somma (ma la cpu non fa una somma con una signola operazione, ma dovra' ad esempio prima caricare i valori da sommare nei suoi registri interni). La bonta' di un compilatore infatti si misura dal numero di istruzioni macchina (vedi istruzioni assembler) che genera per eseguire una singola operazione: meno ne genera, meglio e'.
Da questo punto di vista, il C/C++ risulta essere il piu' efficiente (almeno cosi' mi risulta ;))

I linguaggi di scripting sono piu' o meno come li hai descritti tu: in modo molto semplificato, l'interprete legge lo script e trasforma in tempo reale lo script (o meglio solo le operazioni da compiere) in linguaggio macchina. Ci sono pregi e difetti in questo approccio, che esulano dalla mia semplice spiegazione dei fatti :D

fek

26-01-2006, 15:13

Scherzi a parte buona fortuna qualsiasi cosa tu stia facendo.

Grazie :D

Mi spiegate perfavore la differenza concettuale fra C e Assembly?
In sostanza quello che non capisco è questo: so che parto da un sorgente ma che quello che in realtà viene eseguito è del codice binario. È il make che mi trasforma (tramite compilatore) il sorgente in binario?
Mi sono perso qualche passaggio?

No, e' giusto. In realta' concettualmente non esiste differenza fra C/C++/Assembly, sono tutti linguaggi che vengono tradotto in un'altra forma (linguaggio macchina). I compilatori in realta' andrebbero chiamati traduttori piu' correttamente.

A tal proposito, ma allora, i linguaggi di scripting vengono compilati in realtime?

Dipende :)
Alcuni si', altri no.

^-fidel-^

26-01-2006, 15:15

Per favore, leggiamo gli articoli prima di postarli :)

Well-written C and C++ code contains some 5 to 10 errors per 100 LOC after a clean compile, but before inspection and testing. At a 5% rate any 50 MLOC program will start off with some 2.5 million bugs.

Allora, quest'analisi dei bug per linea di codice nel software Microsoft dov'e'?

Beh, come dicevo prima un'analisi sul codice microsoft e' impossibile, giacche' il codice MS e' closed source e quindi qualunque analisi deve essere fatta da MS (che se le fa non le pubblica), quindi e' possibile solo una stima. Vedo di cercare le statistiche dlla percentuale di bugs per righe di codice after inspection and testing, ok? :D Cosi' almeno ci facciamo un'idea piu' precisa. Secondo me, vista l'esperienza che non solo io ho con i prodotti consumer di microsoft, la percentuale non sara' cosi' bassa come dovrebbe essere.

^-fidel-^

26-01-2006, 15:19

fek

26-01-2006, 15:20

Beh, come dicevo prima un'analisi sul codice microsoft e' impossibile,

Quindi parlavi solo per sentito dire :)

Vedo di cercare le statistiche dlla percentuale di bugs per righe di codice after inspection and testing, ok?

Ok.

Quell'articolo mi fa ridere perche' sembra che in MS scrivano 50 milioni di righe di codice e poi... vediamo un po' se funzionano, toh, ci sono due milioni di bug :D

Non funziona proprio cosi'.

^-fidel-^

26-01-2006, 15:32

Per i vogliosi di approfondimento, ecco un esempio semplice che esplica la differenza tra C ed asm.
Voglio fare una somma tra due interi. in C faro' una cosa del genere: (// indica il commento)

int addendo 1, addendo2; //i due addendi
int somma; //il risultato della somma

addendo1 = 5; //assegno un valore ai due addendi
addendo2 = 7;

somma = addendo1 + addendo 2; //'somma' conterra' il risultato

Il compilatore tradurra' la riga 'somma = addendo1 + addendo 2;' nelle seguenti istruzioni macchina:

- Leggi il valore contenuto nell'indirizzo di memoria puntata da 'addendo1' e mettilo nel
registro interno A.
- Leggi il valore contenuto nell'indirizzo di memoria puntata da 'addendo2' e mettilo nel
registro interno B.
- Somma il valore del registro B a quello di A e metti nel registro A il risultato.
- Scrivi il valore contenuto nel registro A nella locazione di memoria puntata da 'somma'.

Bene, in assembler per fare una somma bisogna semplicemente scrivere tutte le istruzioni che il processore dovra' eseguire per fare la somma: non potro' scrivere 'somma = addendo1 + addendo 2;' ma dovro' scrivere le istruzioni corrispondenti alla sequenza di operazioni descritte prima.
Ne consegue che, piu' istruzioni la CPU ha implementate in hardware, piu' ricco sara' il lessico permesso ne linguaggio assembler (che appunto e' costituito - nella sua forma base -, dalle sole istruzioni hardware permesse dalla cpu).

^-fidel-^

26-01-2006, 15:42

Quell'articolo mi fa ridere perche' sembra che in MS scrivano 50 milioni di righe di codice e poi... vediamo un po' se funzionano, toh, ci sono due milioni di bug :D

Non funziona proprio cosi'.

Beh ci mancherebbe altro :D Piu' che per sentito dire, ripeto, si puo' fare una stima (tra l'altro il modello CMMI serve proprio a questo). Quindi possiamo semplicemente stimare quanti bugs possono esserci in un qualunque programma che segue quel modello di progetto e sviluppo. Mi puoi obiettare: MS segue il CMMI?
Risposta: non credo, quindi il tutto rimane pur sempre una stima. Pero' (almeno dalla mia esperienza personale) un SO Microsoft appena uscito mi tira fuori minimo un errore ogni 2 giorni (tra bug minori e crash di sistema), io non sono molto contento, e sono quindi portato a credere che quelle stime non siano poi cosi' campate in aria.
Nota bene, questo non e' il solito stupido attacco a MS, ma solo una constatazione. Tra l'altro, io non uso SO Microsoft, ma credimi sarei molto contento per chi usa Windows se questo fosse piu' stabile, per lo meno nelle nuove versioni. Io infatti (almeno per giocare eheh) uso XP, che dopo anni di patch e' davvero stabile, e non correrei il rischio di cambiare subito, vista la tendenza di MS a irare fuori sistemi instabili.
Poi ripeto ancora una volta, questa volta per Vista la MS sta facendo piu' test del solito e quindi spero in bene, ma resto ancora scettico, prima lo faccio provare agli amici :Prrr:
Poi se funziona bene saro' il primo a consigliarlo (o a non sconsigliarlo eheheh).

fek

26-01-2006, 15:47

Beh ci mancherebbe altro :D Piu' che per sentito dire, ripeto, si puo' fare una stima (tra l'altro il modello CMMI serve proprio a questo). Quindi possiamo semplicemente stimare quanti bugs possono esserci in un qualunque programma che segue quel modello di progetto e sviluppo. Mi puoi obiettare: MS segue il CMMI?

Si' :)
Leggi il primo commento al blog che hai postato.

Nota bene, questo non e' il solito stupido attacco a MS, ma solo una constatazione. Tra l'altro, io non uso SO Microsoft, ma credimi sarei molto contento per chi usa Windows se questo fosse piu' stabile, per lo meno nelle nuove versioni. Io infatti (almeno per giocare eheh) uso XP, che dopo anni di patch e' davvero stabile, e non correrei il rischio di cambiare subito, vista la tendenza di MS a irare fuori sistemi instabili.

Allora puoi dormire sonni tranquilli: XP e' stabilissimo.

^-fidel-^

26-01-2006, 15:56

Allora puoi dormire sonni tranquilli: XP e' stabilissimo.

Infatti, ma io dormo sonni tranquillissimi, perche con XP sto a posto (tanto lo uso per giocare) e comunque e' finalmente davvero stabile. Quando poi i nuovi giochi richiederanno DirectX 10 e magari queste saranno solo su Vista (sono solo voci, onestamente mi sembra il classico spauracchio, ma vedremo) il mio pc sara' gia' obsoleto e dovro' cambiarlo se vorro' giocare, saranno passati 2 anni fino ad allora, e fino a quel momento Vista sara' sicuramente piu' stabile, e quindi lo installero' tranquillamente per continuare a giocare :D

Nel frattempo sono soddisfatto nell'usare suse linux (XP e' si stabile, ma e' cambiato poco dal 2001 come features, hanno incrementato la stabilita' ma per il resto nisba), almeno ho un sistema del 2005, che implementa le nuove idee per l'"ergonomia" del dektop e la produttivita' del lavoro quotidiano. Se solo penso che in XP non ho i desktop multipli e il gestione risorse con finestra divisibile (stile Midnight commander) vado in ansia :D

^-fidel-^

26-01-2006, 16:01

Si' :)
Leggi il primo commento al blog che hai postato.

Beh allora mi aspetto un numero di bug nell'ordine delle decine migliaia, non delle centinaia di migliaia (o addirittura dei milioni, ma onestamente se su 50 milioni di linee di codice ci sono piu' di 1 milione di bug mi getto dal 6 piano).
Vedremo, nel frattempo vedo le statistiche CMMI su un codice che compila liscio e gia' riveduto e corretto, e vi faccio sapere.

mjordan

27-01-2006, 05:32

E se mi dici ancora che le applicazioni complesse hanno bisogno di allocazione manuale altrimenti ci vuole piu' tempo mi arrabbio, perche' le notti a cercare le doppie deallocazioni le passavo io :D

Nel 2005 mi chiedo ancora perchè devo scrivere i distruttori
Copyright(C) 2005 Fek Computer Corporation.

:sofico:

cdimauro

27-01-2006, 05:35

I linguaggi di alto livello invece al 99% creano codice macchina piu' lungo (porca miseria ma perche' parlate di cose di cui evidentemente ignorate il significato, senza offesa...). C/C++ crea un codice macchina efficiente ma e' davvero una mosca bianca.
Non è una mosca bianca, perché i compilatori moderni ormai sono divisi in due parti: il front-end, che analizza il sorgente e genera un albero "astratto" e il back-end che lo analizza, applica le ottimizzazioni ad alto livello (es: elementi invarianti nei loop, costanti che possono essere precalcolate, ecc.) e poi quelle a basso livello che dipendono dall'architettura target.

GNU è un chiaro esempio di ciò: i parser dei vari linguaggi non sono altro che front-end, che utilizzano poi tutta l'infrastruttura di back-end che è in comune.
Minimizzazione dell'uso del file di swap significa appunto "se uso meglio la memoria, uso meno il file di swap).
Bisogna sempre vedere il contesto. Nella mia esperienza di utente "desktop" non ho avuto rallentamenti o problemi relativi all'uso del file di swap con XP rispetto a sistemi Linux con configurazione hardware similare.
XP NON e' paragonabile a FC4, dal momento che XP e' un S.O. del 2001, con la meta' di features presenti in FC4... Vuoi mettere?!??! e' come paragonare Win 98 con Win XP...
Anche per FC2 vale la stessa cosa. Fortunatamente FC2 era più leggera di FC4, ma con XP ho sempre lavorato meglio a livello desktop.
Se poi intendi la velocita' di avvio... Ovvio che Linux ci mette 15 secondi in piu' ad avviarsi, proprio perche' usa meglio la memoria, ed i processi di sistema si precaricano all'avvio. Ance XP ha un sistema di prefetch, ma onestamente non e' il massimo della vita.
Ma fa bene il suo lavoro. Se Linux usasse meglio la memoria come dici, dovrebbe metterci di meno a caricare proprio per questo motivo.
64 bit non e' una buona cosa se usati bene?
Non cercare di rigirare la frittata. Tu hai detto questo:

"Stanno ormai diffondendosi i PC con architettura a 64 bit: ci rendiamo conto cosa significa avere registri di dimensione DOPPIA?"

Sì, io mi rendo perfettamente conto di cosa vuol dire avere registri di dimensione doppia.

Tu adesso mi vieni a parlare di "usarli bene": evidentemente non sai cosa vuol dire usare bene dei registri a 64 bit, visto che la maggior parte degli algoritmi ne fanno volentieri a meno. Chissà perché. Ma questo ce lo dirai tu, visto che ti vanti di essere un superprogrammatore "assembler" (non assembly, eh! Quello è sbagliato! Tu lavora pure in linguaggio assemblatore, io continuerò a farlo in linguaggio assembly).
Andatevi a ripassare un po' di architettura dei calcolatori e poi ne riparliamo.
Non ne ho avuto bisogno quando ho sostenuto l'esame, tanto meno ne ho adesso, visto che so bene di cosa parlo, a differenza di te.

Tant'è che hai anche parlato genericamente di PC a 64 bit: come se tutte le architetture a 64 bit fossero uguali.
In definitiva: certo che e' piu' comodo scrivere con linguaggi di altissimo livello, ci perdo la meta' del tempo,
Anche 1/10. Anche di più.
ma pi non ci lamentiamo di dover prendere il PC all'ultimo grido con minimo 1 giga di ram per ragionare...
Evidentemente non sai quello che dici. Io lavoro abitualmente in Python, che è un linguaggio che offre costrutti di livello molto alto (qualunque cosa è un oggetto, tipo SmallTalk e altri linguaggi similari), e l'overhead nell'uso comune è impercettibile.

Per "uso comune" intendo che faccio girare tranquillamente applicazioni che fanno da server web, server db, server ICE, ecc. client che macinano dati da database, mega e mega di file XML, ecc. ecc.

Poi è chiaro che se mi prendi il caso particolare avrai ragione, ma mi sembra ovvio.
Gia con XP 512 Mb erano "d'obbligo" per farlo rendere al meglio...
Mi sembra ovvio: più memoria hai, meglio risponde il sistema (fino a un certo punto). Ma XP gira ancora su 2 PC con 64MB di ram, e io l'ho fatto girare per un bel po' di tempo su un PC con 128MB di ram, dandomi non poche soddisfazioni rispetto al precedente 98SE.

cdimauro

27-01-2006, 05:48

Ma MS che fa? Tira fuori un SO che gira bene sui PC di fascia alta-top della gamma e gira male (o al meglio discretamente) su pc di fascia media,
L'esperienza che ho avuto mi porta ad affermare il contrario: XP andava già bene nei computer di fascia di media, e col passare del tempo ha funzionato sempre meglio.
ed in 5 anni tira fuori solo patch di correzione bug o 2/3 nuove features con i vari SP. Poi girera' meravigliosamente sui pc dell 2007/2008. Forse perche' l'ottimizzazione non e' il loro obiettivo? Questo volevo dire... Non farebbero forse meglio a ragionare come in Mac? Cioe' tirare fuori un SO che va gia' benissimo sui pc esistenti,
Assolutamente falso. Le prime versioni di OS X erano delle vere ciofeche: praticamente inutilizzabili.

E ti ricordo che OS X è nato nel 2001, esattamente come XP.
e con gli anni fare delle SP che oltre a correggere errori inseriscono nuove features per stare al passo con i tempi e sfruttare le nuove capacita' di calcolo permesse dai nuovi PC. Non a caso, XP non e' migliorato quasi per nulla in termini di features dal 2001, e senza presunzione si vede... (fatti appunto un giro con Mac o con KDE 3.5 per linux).
Questo perché MS ha avuto altro da fare (Vista). Inoltre dovresti sapere che dopo l'uscita di Vista molte delle sue tecnologie verranno passate anche a XP.
Oltre a parlare di SO, parlavo pure delle applicazioni per MS scritte con linguaggi tipo C#, che non sono il massimo per quanto riguarda la gestione della memoria. Questo non vuol dire ovviamente che non esistano programmi davvero ben fatti sotto windows (ok costano migliaia di euro, ma Autocad ad esempio e' fantastico, o Matlab, ecc...)

Ciao
Anche qui vedo che hai la malsana abitudine di rigirare le carte appena vedi che le cose si sono messe male. Tu hai scritto questo:

"2) uso parsimonioso della memoria (vera pecca di windows, che ha una gestione garbage collection da schifo)"

Ed è fin troppo chiaro che ti riferissi al s.o.. Le applicazioni le hai tirate fuori soltanto ora.

cdimauro

27-01-2006, 05:55

Mi limito a dire che, a mio parere, molti aspetti del SO Windows sono implementati con la finalita' "basta che funzioni", magari pero' e' lento (e non e' detto che funzioni benissimo).
Come fai a dirlo? Hai mai visto il sorgente di Windows?
Infatti, se e' vero che nessun programma e' esente da bug, e' anche vero che molti programmi MS sono davvero troppo pieni di bug per essere programmi commerciali.
Questa frase con quella che hai affermato prima non c'entrano assolutamente (perché hai scritto "infatti"?).

Prima parlavi di velocità, poi parli di bug, che sono due cose totalmente diverse.
Sembra pero' che con Vista non stiano facendo il solito errore, a guardare il ritardo della sua uscita.
Vista è stato ritardo anche a causa del SP2 per XP. Ma questo dovresti saperlo, visto che lavori alla MS...
Sto apsettando infatti per constatare se sara' cosi' oppure no. Sicuramente una cosa la penso: che Windows sia da molti sopravvalutato (che non vuol dire che non sia un buon prodotto eh!). Pero' non mi spiego come mai sia cosi' largamente usato
Forse perché funziona bene?
(non me lo psiego se mi fermo a pensare ai motivi tecnici :))
Quali "motivi tecnici"?

cdimauro

27-01-2006, 05:58

Se la gestione della memoria in .NET fosse cosi' grandiosa, tutti lo userebbero, ma non mi sembra sia cosi' al momento. Sembra che questo discorso lo faccia solo io in tutto il mondo...
Appunto: continui a non vedere che .NET è una tecnologia nuova, per cui ci vuole tempo prima che se ne diffonda l'uso. E nonostante tutto dovresti aver notato che ha un tasso di crescita molto elevato: praticamente quasi tutti quelli che sviluppavano in VisualBasic sono passati a VB.NET o a Visual C#, e Borland è arrivata alla terza generazione di IDE che ormai hanno in .NET il punto di riferimento.

Chissà perché.

cdimauro

27-01-2006, 06:05

Onestamente, a parita' di complessita', non ho ancora visto un qualunque programma cosi' pieno di bug come un SO MS appena uscito (almeno prima di Vista).
Io non ho avuto problemi né con XP né con XP SP1 né con XP SP2. E le uniche schermate blu che ho visto erano dovute ai miei tentativi di overclock.
Anche loro sanno fare meglio! (vedi le varie suite Office). Se solo conti quante patch sono uscite negli anni per WinXP...
E' normale. Prova a contare anche quante patch sono uscite per altri s.o., e ti metti le mani nei capelli.

Da quando ho installato FC4, circa un mese e mezzo fa, ho scaricato circa 1500 pacchetti per quasi 3GB di roba.

E' chiaro che in mezzo ci sono pure gli aggiornamenti per OpenOffice, mysql, apache, kate, ecc., ma anche 2 kernel nuovi, ad esempio.

cdimauro

27-01-2006, 06:07

Per fek:

Ah, approposito di sistemi realtime, leggiti questa:

http://www.linuxhelp.it/modules.php?name=News&file=article&sid=3259

:D
Non so tu, ma io leggo "quasi real-time".

cdimauro

27-01-2006, 06:11

Veramente quel numero proviene da questo (http://www.embedded.com/showArticle.jhtml?articleID=171203287) articolo. Poi se cerchi una quantificazione ufficiale fatta da microsoft, allora puoi aspettare quanto vuoi, non uscira' mai (credo ;)). E' ovviamente una stima, onestamente ben argomentata, che non mi sembra smentita dai fatti, visti gli ultimi prodotto MS destinati al mondo consumer.
Quindi vorresti supportare delle stime con delle argomentazioni, e per giunta parli di fatti. Ma non si tratta di fatti inerenti l'argomento, infatti passi ad altro (dopo).
Ma ti ricordi XP appena uscito? Parecchio instabile, crashava spesso, e finalmente dopo 3/4 anni e' diventato un buon sistema operativo, soprattutto finalmente stabile.
Infatti i tuoi fatti sarebbero questi.

Comunque, come ti ho già detto, con XP non ho avuto problemi nemmeno con la prima versione.

Quindi, visto che ti basi su questo tipo di fatti (e non ad argomentazioni legate alla qualità del codice, al numero di bug per linea di codice, ecc.), dovrei dedurre che XP è sempre stato un s.o. perfetto.

cdimauro

27-01-2006, 06:20

La bonta' di un compilatore infatti si misura dal numero di istruzioni macchina (vedi istruzioni assembler) che genera per eseguire una singola operazione: meno ne genera, meglio e'.
Falso (e mi sembra anche ovvio il perché).
Da questo punto di vista, il C/C++ risulta essere il piu' efficiente (almeno cosi' mi risulta ;))
Anche questo è falso (vedi quanto ho già scritto prima sul tema): evidentemente non hai mai frequentato un corso di linguaggi di programmazione e/o di linguaggi formali e compilatori.
I linguaggi di scripting sono piu' o meno come li hai descritti tu: in modo molto semplificato, l'interprete legge lo script e trasforma in tempo reale lo script (o meglio solo le operazioni da compiere) in linguaggio macchina.
Falso. In generale i linguaggi di scripting interpretano i sorgenti ed eseguono le operazioni/istruzioni senza generare alcun codice macchina da eseguire.

Al più (come Python, ad esempio) la prima volta viene generato un file in bytecode, ma anche questo comporta un'interpretazione e non una generazione di codice macchina da eseguire dopo.

cdimauro

27-01-2006, 06:22

Ah si dimenticavo... anche i programmi assembler necessitano di compilazione (non era chiaro dalla mia spiegazione in effetti): semplicemente in asm si scrivono direttamente le istruzioni che la macchina deve compiere, nei vari linguaggi di programmazione invece il tutto si esprime in un linguaggio simil-umano che poi il compilatore trasformera' (ecco perche' correttamente essi vengono chiamati "traduttori")
Questo semplicemente perché gli assemblatori che hai visto finora era tutti simili (il classico modello basato sullo "mnemonico" -> rappresentazione fedele dell'opcode).

Io un po' di anni fa ho scritto assemblatori che permettono di scrivere codice in un linguaggio simil-umano.

cdimauro

27-01-2006, 06:25

Se solo penso che in XP non ho i desktop multipli
Io non li ho mai usati: non li trovo affatto comodi. De gustibus, come si suol dire.
e il gestione risorse con finestra divisibile (stile Midnight commander) vado in ansia :D
Prova Total Commander. Soprattutto non fermarti a scaricare il solo programma, ma scaricati anche i numerosi plug-in disponibili, e vedrai che non ne potrai più fare a meno.

mjordan

27-01-2006, 06:41

Ma almeno queste BONE... hanno una 4 di reggiseno? :D :D

Questa non riuscivo a trattenerla... :ciapet:

No però hanno una SKIN cosi liscia da far impazzire... :rotfl:

^-fidel-^

27-01-2006, 08:00

Sì, io mi rendo perfettamente conto di cosa vuol dire avere registri di dimensione doppia.

Tu adesso mi vieni a parlare di "usarli bene": evidentemente non sai cosa vuol dire usare bene dei registri a 64 bit, visto che la maggior parte degli algoritmi ne fanno volentieri a meno. Chissà perché. Ma questo ce lo dirai tu, visto che ti vanti di essere un superprogrammatore "assembler" (non assembly, eh! Quello è sbagliato! Tu lavora pure in linguaggio assemblatore, io continuerò a farlo in linguaggio assembly).

Non ne ho avuto bisogno quando ho sostenuto l'esame, tanto meno ne ho adesso, visto che so bene di cosa parlo, a differenza di te.

Non preoccuparti so cosa significa "usarli bene". A parte il fatto che il discorso era nato dall'utilita' o meno di utilizzare codice asm per compiere determinate operazione o per ottimizzare parti di codice: per quanto mi riguarda, uso asm per la programmazione di device hardware (normalmente almeno per windows riesco a fare tutto tramite le funzioni dell'HAL, ma a volte si rende necessario l'asm). Evidentemente ho allargato troppo il discorso, riferendomi a tutti i modelli di programmazione che un programmatore puo' utilizzare nei vari ambiti. Tra l'altro non mi reputo un superprogrammatore (tantomeno assembler o assembly) quindi non mi mettere in bocca cose che non ho mai detto.
Per quanto riguarda i 64 bit, il problema odierno (per quanto mi risulta) è proprio l'opportunita' di ottimizzare algoritmi esistenti (che sono stati pensati per trattare variabili a 32 bit): con questo voglio dire che, ad esempio, un algoritmo numerico che usa variabili in doppia precisione su 64 bit potranno trovare una architettura hardware piu' consona per essere trattati, con conseguente aumento delle prestazioni. Ovvio che molti di essi andranno riscritti. Al momento un sistema 64 bit NON va meglio di uno a 32 bit (un minuscolo aumento di prestazioni l'ho visto solo con le versioni di linux a 64 bit, con la versione XP 64 bit non ho provato quindi non posso dire): non a caso io ho un 32 bit e per il momento non ho alcuna intenzione di comprare un pc a 64 bit. Parlavo di POSSIBILITA' (se rileggi bene quello che ho scritto invece di dovermi necessariamente contraddire).

Tant'è che hai anche parlato genericamente di PC a 64 bit: come se tutte le architetture a 64 bit fossero uguali.
E' una cosa che mi sa ripetero' piu' volte nelle risposte ai tuoi post: ho fatto un errore, che e' quello di aver messo troppa carne al fuoco. Se dobbiamo entrare nel dettaglio di tutte le cose di cui ho parlato finiremmo tra 6 mesi.

Mi sembra ovvio: più memoria hai, meglio risponde il sistema (fino a un certo punto). Ma XP gira ancora su 2 PC con 64MB di ram, e io l'ho fatto girare per un bel po' di tempo su un PC con 128MB di ram, dandomi non poche soddisfazioni rispetto al precedente 98SE.
Guarda, a me XP su un pc con 128 mega di ram andava da schifo: con questo non voglio dire che doveva girare necessariamente bene per carita', ma da 128 a 512 ce ne corre (considerando i prezzi delle ram nel 2001). Per mia esperienza, i SO linux (normalmente uso suse, fedora usato poco), ho sempre avuto prestazioni migliori, sia in applicazioni server che in applicazioni desktop: poi evidentemente e' una questione di "esperienza d'uso". Ah, dire che un sistema e' piu' lento non vuol dire che faccia schifo. Ho solo constatato che (almeno per quello che e' capitato a me) andava piu' lento.

ilsensine

27-01-2006, 08:05

Per fek:

Ah, approposito di sistemi realtime, leggiti questa:

http://www.linuxhelp.it/modules.php?name=News&file=article&sid=3259

:D
Odora di marketware. Questo link è più completo (e rende l'idea di quanto sia complicato trapiantare un OS general purpose in un ambito realtime):
http://marc.theaimsgroup.com/?l=linux-kernel&m=111819790919644&w=2
In particolare il punto C.

^-fidel-^

27-01-2006, 08:15

Vista è stato ritardo anche a causa del SP2 per XP. Ma questo dovresti saperlo, visto che lavori alla MS...
A parte il il fatto che lavoro per MS, no alla MS, come dici tu Vista sta ritardando ANCHE per il SP2, ma e' un ritardo minimo rispetto agli altri problemi che hanno avuto (fondamentalmente ad instabilita' dovute all'inserimento di nuove features). Questo e' assolutamente normale, e dicevo infatti che e' solo un bene che ritardino per tirare fuori un sistema operativo piu' stabile di quello che ear XP appena uscito. E ripeto: parlo cosi' perche appena uscito, A ME (non a tutti eh) su 6 pc diversi XP ha dato un sacco di problemi. Col tempo poi e' andato migliorando. Se poi tu hai avuto una bella esperienza con XP sono contento per te.[/QUOTE]

Forse perché funziona bene?

Quali "motivi tecnici"?
Sicuramente ora XP funziona bene (anche se come ho detto prima e' diventato piu' stabile, ma le features sono in larga parte le stesse del 2001). Ma dovresti sapere che intendevo per "motivi non tecnici" la capacita' di MS di far valere il suo monopolio informatico, soprattuto sui formati dei documenti, ma anche sui protocolli di rete a livello applicazione. Per non parlare degli accordi commerciali per la produzione di drivers per i vari componenti hardware. e mi fermo senno' apriamo un altro topic apposta.
Per quanto riguarda i motivi tecnici idem, senza entrare nel dettaglio mi riferivo al fatto che tecnicamente non reputo XP migliore di altri SO (sia commerciali che non); chissa' perche' i server aziendali sono spesso unix: forse perche' a parita' di prestazioni costano meno? Questo per dire che non mi sembra che i sistemi MS siano tecnicamente superiori (cioe' non fanno meglio il lavoro rispetto ad altri sistemi operativi).

^-fidel-^

27-01-2006, 08:22

Non so tu, ma io leggo "quasi real-time".
Aridaje... Si parlava con fek di sistemi realtime, e del fatto che ne' windows ne' linux lo sono. Ho quindi postato un articolo che illustrava in soldoni i passi in avanti di un sistema linux verso una gestione realtime dei task. Ovvio che non e' totalmente realtime (sia affermava proprio il contrario)... Quindi forse facevi meglio a leggere bene il discorso che si faceva con fek prima di postare wuasto commento...

^-fidel-^

27-01-2006, 08:26

Appunto: continui a non vedere che .NET è una tecnologia nuova, per cui ci vuole tempo prima che se ne diffonda l'uso. E nonostante tutto dovresti aver notato che ha un tasso di crescita molto elevato: praticamente quasi tutti quelli che sviluppavano in VisualBasic sono passati a VB.NET o a Visual C#, e Borland è arrivata alla terza generazione di IDE che ormai hanno in .NET il punto di riferimento.

Chissà perché.

Anche qui, rileggiti il discorso fatto con fek. Non ho mai detto che .NET e' da buttare via, anzi. E' normale che col passare del tempo un framework come .NET (e ne esistono altri, anche per altri SO) si espandera' sempre piu' per ovvie ragioni, date dalla necessita' di scrivere codice piu' velocemente senza doversi preoccupare di ongi singolo aspetto, come la gestione della memoria. Si faceva un dicorso di prestazioni, non di opportunita'. E' stato anche detto che tra non molto la differenza tra GC e allocazione manuale diverra' (probabilmente) inesistente. Leggere prima di postare please...

^-fidel-^

27-01-2006, 08:32

Falso (e mi sembra anche ovvio il perché).

Anche questo è falso (vedi quanto ho già scritto prima sul tema): evidentemente non hai mai frequentato un corso di linguaggi di programmazione e/o di linguaggi formali e compilatori.

Falso. In generale i linguaggi di scripting interpretano i sorgenti ed eseguono le operazioni/istruzioni senza generare alcun codice macchina da eseguire.

Al più (come Python, ad esempio) la prima volta viene generato un file in bytecode, ma anche questo comporta un'interpretazione e non una generazione di codice macchina da eseguire dopo.

Ma ti prego.... non era mia intenzione fare un trattato su linguaggi e traduttori: era solo una semplice esposizione della differenza tra un linguaggio di alto livello e l'asm, senza andare troppo nei particolari. Evidentemente ci provi gusto a contraddirmi. Ti sembra questo forum il posto adeguato per fare lezioni di linguaggi e traduttori? Era stato chiesto "mi spiegate la differenza tra C e asm?" da parte di un utente alle prime armi in questo discorso, e non ho voluto farla troppo lunga, senno' dovevo scrvere 3 pagine di post solo per cominciare... Forse non conosci il significato della frase "in modo molto semplificato".
Non ho ne' la voglia, ne' la presunzione di fare il professore per una semplice spiegazione. Se poi uno e' interessato ad approfondire, si compra un bel libro.

^-fidel-^

27-01-2006, 08:37

Ah una precisazione: convengo sull'erronea affermazione che ho fatto:
"La bonta' di un compilatore infatti si misura dal numero di istruzioni macchina (vedi istruzioni assembler) che genera per eseguire una singola operazione: meno ne genera, meglio e'.".

In generale questo non e' vero (anche se alcune volte si'), ma non e' affatto una cosa assoluta. Sono stato preso da un "impeto di semplificazione" che mi ha portato a dire una cosa sbagliata. Sorry.

^-fidel-^

27-01-2006, 08:41

Questo semplicemente perché gli assemblatori che hai visto finora era tutti simili (il classico modello basato sullo "mnemonico" -> rappresentazione fedele dell'opcode).

Io un po' di anni fa ho scritto assemblatori che permettono di scrivere codice in un linguaggio simil-umano.

Idem come sopra: vogliamo fare un trattato sui compilatori assembler? Evidentemente ti piace fare lo "sborone" :eek: Senza offesa :D Non a caso ho pure parlato in un precedente post che gli assemblatori "moderni" permettono di richiamare funzioni delle api di windows (parlo di MASM in questo caso), ma anche (e questo da molti anni) di fare normalmete costrutti tipo for o while come in un normale linugaggio di alto livello. Ma on volevo entrare troppo nel dettaglio!

^-fidel-^

27-01-2006, 08:48

Odora di marketware. Questo link è più completo (e rende l'idea di quanto sia complicato trapiantare un OS general purpose in un ambito realtime):
http://marc.theaimsgroup.com/?l=linux-kernel&m=111819790919644&w=2
In particolare il punto C.

Molto probabile. Personalmente non mi ero soffermato sui soliti proclami "sensazionalistici" fatti dalle aziende, ma mi sembrava un punto di partenza per interessarsi all'argomento (tralasciando appunto il marketware). Ottimo il tuo link.

cdimauro

27-01-2006, 09:01

Non preoccuparti so cosa significa "usarli bene". A parte il fatto che il discorso era nato dall'utilita' o meno di utilizzare codice asm per compiere determinate operazione o per ottimizzare parti di codice: per quanto mi riguarda, uso asm per la programmazione di device hardware (normalmente almeno per windows riesco a fare tutto tramite le funzioni dell'HAL, ma a volte si rende necessario l'asm). Evidentemente ho allargato troppo il discorso, riferendomi a tutti i modelli di programmazione che un programmatore puo' utilizzare nei vari ambiti. Tra l'altro non mi reputo un superprogrammatore (tantomeno assembler o assembly) quindi non mi mettere in bocca cose che non ho mai detto.
Questo:

"dal momento che il know-how dei programmatori va ahimè diminuendo col tempo - ora non fraintendetemi, non voglio dire che so programmare solo io, per favore!"

l'hai scritto tu. E se vuoi ti riporto anche tutto il contesto del discorso.
Per quanto riguarda i 64 bit, il problema odierno (per quanto mi risulta) è proprio l'opportunita' di ottimizzare algoritmi esistenti (che sono stati pensati per trattare variabili a 32 bit): con questo voglio dire che, ad esempio, un algoritmo numerico che usa variabili in doppia precisione su 64 bit potranno trovare una architettura hardware piu' consona per essere trattati, con conseguente aumento delle prestazioni. Ovvio che molti di essi andranno riscritti.
No, perché sono ben pochi gli algoritmi che possono sfruttare i 64 bit.
Al momento un sistema 64 bit NON va meglio di uno a 32 bit
E' un discorso troppo generico: dipende dal sistema.
(un minuscolo aumento di prestazioni l'ho visto solo con le versioni di linux a 64 bit, con la versione XP 64 bit non ho provato quindi non posso dire):
XP x64 si comporta molto bene: lo trovo veloce almeno quanto XP.
non a caso io ho un 32 bit e per il momento non ho alcuna intenzione di comprare un pc a 64 bit.
Per me vale l'esatto opposto.
Parlavo di POSSIBILITA' (se rileggi bene quello che ho scritto invece di dovermi necessariamente contraddire).
No, tu hai detto questo (e te lo riporto nuovamente):

"Stanno ormai diffondendosi i PC con architettura a 64 bit: ci rendiamo conto cosa significa avere registri di dimensione DOPPIA?"

Non c'è nemmeno il sentore di una qualche "possibilità". Anche qui hai preferito sparare una frase senza valutarne pienamente il significato.

Non è questione di voler contraddire TE a tutti i costi: io valuto ciò chi scrive CHIUNQUE, e se c'è qualcosa che non mi quadra mi permetto di intervenire.
E' una cosa che mi sa ripetero' piu' volte nelle risposte ai tuoi post: ho fatto un errore, che e' quello di aver messo troppa carne al fuoco.
Allora la prossima volta mettine di meno al fuoco, e che sia quella giusta.
Se dobbiamo entrare nel dettaglio di tutte le cose di cui ho parlato finiremmo tra 6 mesi.
Guarda che per me non c'è problema: io adoro parlare di architetture degli elaboratori, compilatori, s.o. et similia. E' la mia passione, ma anche il mio mestiere.

Quindi ritieni libero di poter continuare a dire tutto quello che ti passa per la testa.
Guarda, a me XP su un pc con 128 mega di ram andava da schifo: con questo non voglio dire che doveva girare necessariamente bene per carita', ma da 128 a 512 ce ne corre (considerando i prezzi delle ram nel 2001). Per mia esperienza, i SO linux (normalmente uso suse, fedora usato poco), ho sempre avuto prestazioni migliori, sia in applicazioni server che in applicazioni desktop: poi evidentemente e' una questione di "esperienza d'uso". Ah, dire che un sistema e' piu' lento non vuol dire che faccia schifo. Ho solo constatato che (almeno per quello che e' capitato a me) andava piu' lento.
Non c'è problema: abbiamo avuto esperienze diverse.

cdimauro

27-01-2006, 09:03

Odora di marketware. Questo link è più completo (e rende l'idea di quanto sia complicato trapiantare un OS general purpose in un ambito realtime):
http://marc.theaimsgroup.com/?l=linux-kernel&m=111819790919644&w=2
In particolare il punto C.
Già:

"Strengths: Simplicity and robustness. "Good enough" realtime support for undemanding realtime applications. Excellent performance and scalability for both realtime and non-realtime applications.
Applications and administrators see a single OS instance.

Weaknesses: Poor realtime response, need to inspect the entire kernel to find issues that degrade realtime response."
Mi sembra fin troppo eloquente.

Grazie per il link, "compagno". :D

cdimauro

27-01-2006, 09:10

A parte il il fatto che lavoro per MS, no alla MS, come dici tu Vista sta ritardando ANCHE per il SP2, ma e' un ritardo minimo rispetto agli altri problemi che hanno avuto (fondamentalmente ad instabilita' dovute all'inserimento di nuove features).
Questo non si può dire: non si sa quanto abbia pesato lo sviluppo del SP2 e quanto le nuove funzionalità.
Sicuramente ora XP funziona bene (anche se come ho detto prima e' diventato piu' stabile, ma le features sono in larga parte le stesse del 2001).
Mah. Non direi. XP SP2 lo trovo diverso dal primo XP.
Ma dovresti sapere che intendevo per "motivi non tecnici" la capacita' di MS di far valere il suo monopolio informatico,
Monopolio che non esiste. Al più possiamo parlare di posizione dominante nel mercato dei s.o..
soprattuto sui formati dei documenti,
Discutibile: di Office 97, che è il più diffuso, ha pubblicato le specifiche del formato.
ma anche sui protocolli di rete a livello applicazione.
Su questo hai ragione (ti riferisci a Samba, vero?).
Per non parlare degli accordi commerciali per la produzione di drivers per i vari componenti hardware.
Link please.
e mi fermo senno' apriamo un altro topic apposta.
Se vuoi, puoi farlo tranquillamente.
Per quanto riguarda i motivi tecnici idem, senza entrare nel dettaglio mi riferivo al fatto che tecnicamente non reputo XP migliore di altri SO (sia commerciali che non); chissa' perche' i server aziendali sono spesso unix: forse perche' a parita' di prestazioni costano meno? Questo per dire che non mi sembra che i sistemi MS siano tecnicamente superiori (cioe' non fanno meglio il lavoro rispetto ad altri sistemi operativi).
Non mi occupo di server, quindi non ti so dire.

Però posso dirti che tecnicamente (e mi riferisco alla struttura del s.o., alle API, al filesystem, ecc.) non sono inferiori a nessuno.

cdimauro

27-01-2006, 09:14

Aridaje... Si parlava con fek di sistemi realtime, e del fatto che ne' windows ne' linux lo sono. Ho quindi postato un articolo che illustrava in soldoni i passi in avanti di un sistema linux verso una gestione realtime dei task. Ovvio che non e' totalmente realtime (sia affermava proprio il contrario)... Quindi forse facevi meglio a leggere bene il discorso che si faceva con fek prima di postare wuasto commento...
Ho letto TUTTI i messaggi prima di rispondere: se l'ho fatto è proprio per rimarcare lo status attuale dei sistemi.

Anche perché tu hai riportato quel link in un ben preciso contesto, e senza nemmeno commentare l'articolo. Anzi, dal tuo messaggio (con tanto di faccina sorridente) sembra che volessi affermare che, al contrario, Linux era un s.o. realtime.

Se vuoi continuare a giocare con le parole fallo pure, ma non cercare di rigirare le carte, perché è tempo perso: so tenere bene le fila di una discussione.

ilsensine

27-01-2006, 09:16

Già:

"Strengths: Simplicity and robustness. "Good enough" realtime support for undemanding realtime applications. Excellent performance and scalability for both realtime and non-realtime applications.
Applications and administrators see a single OS instance.

Weaknesses: Poor realtime response, need to inspect the entire kernel to find issues that degrade realtime response."
Mi sembra fin troppo eloquente.

Grazie per il link, "compagno". :D
Perché, ci vedi una contraddizione? :sofico:

Lì ha un pò pasticciato con le parole, per "good enough realtime support" si riferiva per applicazioni che usano (si accontentano di) uno dei due scheduler realtime "vanilla" (come i programmi di masterizzazione ecc).
"realtime" è un termite troppo "overloaded", difficile essere sempre precisi.

cdimauro

27-01-2006, 09:18

Anche qui, rileggiti il discorso fatto con fek.
Ho letto tutto, come ti ho già detto.
Non ho mai detto che .NET e' da buttare via, anzi. E' normale che col passare del tempo un framework come .NET (e ne esistono altri, anche per altri SO) si espandera' sempre piu' per ovvie ragioni, date dalla necessita' di scrivere codice piu' velocemente senza doversi preoccupare di ongi singolo aspetto, come la gestione della memoria. Si faceva un dicorso di prestazioni, non di opportunita'. E' stato anche detto che tra non molto la differenza tra GC e allocazione manuale diverra' (probabilmente) inesistente. Leggere prima di postare please...
Vedi sopra. Io leggo e capisco benissimo. Tu hai scritto questo:

"Se la gestione della memoria in .NET fosse cosi' grandiosa, tutti lo userebbero, ma non mi sembra sia cosi' al momento. Sembra che questo discorso lo faccia solo io in tutto il mondo..."

Non sono d'accordo, e ti ho scritto chiaramente anche il perché: è così difficile accettarlo?

cdimauro

27-01-2006, 09:23

Ma ti prego.... non era mia intenzione fare un trattato su linguaggi e traduttori: era solo una semplice esposizione della differenza tra un linguaggio di alto livello e l'asm, senza andare troppo nei particolari. Evidentemente ci provi gusto a contraddirmi.
No, è che hai scritto un papiro enorme, hai scritto anche altro dopo, ma in quel caso hai riportato un concetto errato che ho voluto evidenziare e correggere.

Non amo che passino delle informazioni errate, tutto qui. Perché continui a vederci un attacco personale?
Ti sembra questo forum il posto adeguato per fare lezioni di linguaggi e traduttori? Era stato chiesto "mi spiegate la differenza tra C e asm?" da parte di un utente alle prime armi in questo discorso, e non ho voluto farla troppo lunga, senno' dovevo scrvere 3 pagine di post solo per cominciare... Forse non conosci il significato della frase "in modo molto semplificato".
Non mettere in dubbio le mie capacità cognitive, cortesemente: non è il caso di spostare la discussione sul piano personale.

Come ho detto sopra, hai scritto un papiro, ma ti sei perso alla fine: potevi usare la stessa "semplicità" per spiegare il concetto in maniera corretta, come ho fatto io correggendoti (e non ho nemmeno scritto un papiro).
Non ho ne' la voglia, ne' la presunzione di fare il professore per una semplice spiegazione. Se poi uno e' interessato ad approfondire, si compra un bel libro.
Appunto. Ma se vuoi fare informazione, almeno riporta delle cose corrette.

^-fidel-^

27-01-2006, 09:41

Ho letto tutto, come ti ho già detto.

Vedi sopra. Io leggo e capisco benissimo. Tu hai scritto questo:

"Se la gestione della memoria in .NET fosse cosi' grandiosa, tutti lo userebbero, ma non mi sembra sia cosi' al momento. Sembra che questo discorso lo faccia solo io in tutto il mondo..."

Non sono d'accordo, e ti ho scritto chiaramente anche il perché: è così difficile accettarlo?

Assolutamente non e' difficile, non sono mica un muro: non a caso, se prendi solo quella frase hai perfettamente ragione, ma si e' parlato (e lo sai visto che hai letto tutto) del presente e del futuro di un framework (nello specifico di .NET). Mi pare di aver chiarito il punto che hai sottolineato gia' con il discorso con fek. Si parlava dell'oggi e del domani. ORA non reputo la gestione .NET adeguata per molti programmi (almeno per quelli di cui mi interesso io), sia perche il GC e' comunque normalmente meno efficiente per le suddette applicazioni (normalmente di rete), sia perche' il tipo di GC implementato in .NET 1.1 (nel 2.0 non ti so dire) e' di tipo 'reference-tracking', e la sua implementazione l'ho trovata da migliorare (rispetto a garbage collectors implementati a parte che ho avuto modo di utilizzare).

^-fidel-^

27-01-2006, 09:47

Non mettere in dubbio le mie capacità cognitive, cortesemente: non è il caso di spostare la discussione sul piano personale.

Ok, forse ho esagerato, niente di personale figurati.

Appunto. Ma se vuoi fare informazione, almeno riporta delle cose corrette.

Vedro' di essere piu' preciso sulle singole affermazioni, cercando di non sbagliare. Per non usare troppe parole specifiche ho detto una cosa inesatta (e mi pare di averlo gia' detto). Semplicemente non volevo mettermi a parlare di parser e cosi' via.

cdimauro

27-01-2006, 10:01

Idem come sopra: vogliamo fare un trattato sui compilatori assembler?
Idem come sopra: no, semplicemente ho corretto una tua affermazione errata.

Comunque si dice compilatori assembly, al limite. Assembler/Assemblatore = compilatore assembly, quindi non ha senso scrivere compilatore assembler, visto che l'assembler è già di per se un compilatore.
Evidentemente ti piace fare lo "sborone" :eek: Senza offesa :D
A chi credi di voler prendere in giro? Hai sbagliato persona con cui giocare. :rolleyes:
Non a caso ho pure parlato in un precedente post che gli assemblatori "moderni" permettono di richiamare funzioni delle api di windows (parlo di MASM in questo caso),
Questa capacità che citi ce l'hanno gli assemblatori da non so quanto tempo.
ma anche (e questo da molti anni) di fare normalmete costrutti tipo for o while come in un normale linugaggio di alto livello. Ma on volevo entrare troppo nel dettaglio!
Io mi riferivo ad altro, ma evidentemente non sono stato abbastanza chiaro:

module TryAssemble
section Prova code 0,255

Prova2 = 'CODE'
Prova3 = $C0DEDBAD
ByteType = byte = 128
WordType = word
LongType = longword = 16777215
OtherByte = ByteType
#Qui = -1,Quo,Qua = 3
Var1,Var2[29] : ByteType
Var3[26],Var4 : LongType
Var5 : byte = 128
Flags = p
Interrupt = i

proc Proc1

public Export1,Outside

:Export1
push Flags
call $5555
pop Flags
ret
:Outside
call Interrupt
ret Interrupt
end

Const = $ff
Zero = $55
Abs = $aaaa

data string 'Prova!'
data pstring array[3] 'OK!!!'
data cstring 'hello!'
data byte 0,Zero
data word array[8] Abs
data longword $33333333
end

section Codice code $8000,$ffff

proc ColdReset
reset i
x := #255
s := x
reset d
call ResetAudio
call ResetVideo
call ClearScreen
call ResetIO
VSync := #0
FuncNum := #0
jump DumpMem
end

Pow2Table = pc; data byte 1,2,4,8,16,32,64,128

(* Input : a = Value; Output: a = FirstChar, x := SecondChar *)
proc ByteHexToChars
x := a
and #$F
y := a
a := HexTable,y
push a
a := x
shr; shr; shr; shr
y := a
a := HexTable,y
pop x
ret
:HexTable data byte '0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'
end

(* a = Number of seconds *)
proc WaitSeconds
Seconds := a
a := #60
Delay := a
:WaitVSync
a := VSync
if = WaitVSync
VSync := #0
dec Delay
if <> WaitVSync
a := #60
Delay := a
dec Seconds
if <> WaitVSync
ret
end
end
end
E' un esempio dell'assembler 65C02 che ho scritto tempo addietro. E' UN PO' diverso dal tipico assemblatore 65C02, non trovi?

^-fidel-^

27-01-2006, 10:02

Per cdmauro:

sintetizzando quello che hai detto sulla "posizione di mercato dominante": ok Office 97, ma non esageriamo. E' arcinoto (e' addirittura uscita fuori un po' di corrispondenza interna MS sulla loro strategia "abbraccia ed espandi" sui formati e sui protocolli), che MS fa di tutto per "imporre" come standard tecniche proprietarie (quasi ignorando gli standard RFC esistendi, che gia' implementano quelle tecnologie).
Nello specifico di Office: perche' fanno di tutto per imporre il loro standard invece di acquisire lo standard OASIS opendocument? Personalmente me ne frego del formato .doc per Office 97. E si sono pure vantati di star creando uno standard open basato su XML. Esiste gia' ed e' OASIS. Perche' non implementarlo? perche' proporne uno nuovo spacciandola per novita'?
La posizione dominante si mantiene con la qualita' dei prodotti, non con queste mosse, a mio giudizio. E se MS crea dei buoni prodotti, perche' fare queste cose, invece di confrontarsi tranquillamente con gli altri produttori? Ti ricordo quello che e' stato fatto anni fa con Expolrer ai danni di Netscape.
Per quanto riguarda gli accordi commerciali per i drivers, mi riferivo alle varie "Microsoft Certified" che i produttori hardware espongono sui loro prodotti a mo' di 'garanzia'. Costa cosi' tanto fare un driver anche per un altro sistema? Mi sembra davvero strano infatti che ATI ed NVIDIA ad esempio facciano drivers per linux quando i videogames su linux praticamente non esistono, mentre altri produttori (anche solo le webcam sono un esempio) normalmente se ne fregano? A me questo sembra un modo come un altro per 'spingere' l'utente a continuare ad usare Windows, scoraggiandolo a cambiare: se all'utente viene voglia di provare un altro sistema, nel 95% dei casi (statistica personale guardando i miei clienti) le resistenze sono proprio quelle del supporto hardware (che comunque c'e', ma fatto non dalla casa costruttrice in tanti casi...). Comunque se vuoi sono pronto ad allargare il discorso sui drivers che ho introdotto fin qui.

cdimauro

27-01-2006, 10:04

Perché, ci vedi una contraddizione? :sofico:
:rotfl: Mi farai morire prima o poi. :p
Lì ha un pò pasticciato con le parole, per "good enough realtime support" si riferiva per applicazioni che usano (si accontentano di) uno dei due scheduler realtime "vanilla" (come i programmi di masterizzazione ecc).
Grazie per la precisazione. :)
"realtime" è un termite troppo "overloaded", difficile essere sempre precisi.
Vero.

^-fidel-^

27-01-2006, 10:14

Io mi riferivo ad altro, ma evidentemente non sono stato abbastanza chiaro:
--cut--
E' un esempio dell'assembler 65C02 che ho scritto tempo addietro. E' UN PO' diverso dal tipico assemblatore 65C02, non trovi?

Trovo, ma questo conferma quello che dicevo: non ho mica detto che il codice assembly e' fatto solo di opcode!!!!!!!!!!!!!!!!
Mi sembrava utile metterla cosi' per spiegare le pecularita' del linguaggio assembly, senza aprire una lunga disquisizione se al giorno d'oggi tali linguaggi sono ormai assimilabili a quelli di alto livello (come hai fatto vedere tu nel codice che hai postato). Ho poi precisato che anche in asm sono possibili costrutti di alto livello e quant'altro, ma penso che un utente alle prima armi con l'assembly sia interessato piu' agli opcode (che differenziano l'assembly dai linguaggi di alto livello) piu' che sulla possibilita' di assimilarlo ad un linguaggio di alto livello.
Senno' perche' usare l'assembly? Ovviamente e' utile avere costrutti di alto livello mantenendo la possibilita' di usare gli opcode, ma questo appunto esula a mio parere dalla semplice domanda "che differenza c'e' tra C e asm?"

cdimauro

27-01-2006, 10:20

sintetizzando quello che hai detto sulla "posizione di mercato dominante": ok Office 97, ma non esageriamo. E' arcinoto (e' addirittura uscita fuori un po' di corrispondenza interna MS sulla loro strategia "abbraccia ed espandi" sui formati e sui protocolli), che MS fa di tutto per "imporre" come standard tecniche proprietarie (quasi ignorando gli standard RFC esistendi, che gia' implementano quelle tecnologie).
Questo l'avevo già detto, mi pare (quando citavo Samba).
Nello specifico di Office: perche' fanno di tutto per imporre il loro standard invece di acquisire lo standard OASIS opendocument?
Semplicemente continuano a sviluppare la loro piattaforma, come hanno SEMPRE fatto. Ti ricordo che:
1) OpenDocument è uno standard recente;
2) scrivere filtri di importazione / esportazione per OpenDocument non è una cosa semplice, e richiede risorse e tempo;
3) il formato Office "rispecchia" molto probabilmente la struttura con cui Office memorizza le informazioni.
Personalmente me ne frego del formato .doc per Office 97. E si sono pure vantati di star creando uno standard open basato su XML. Esiste gia' ed e' OASIS. Perche' non implementarlo? perche' proporne uno nuovo spacciandola per novita'?
Probabilmente perché ci lavoravano da tempo e per il punto 3) di cui sopra.
La posizione dominante si mantiene con la qualita' dei prodotti, non con queste mosse, a mio giudizio. E se MS crea dei buoni prodotti, perche' fare queste cose, invece di confrontarsi tranquillamente con gli altri produttori? Ti ricordo quello che e' stato fatto anni fa con Expolrer ai danni di Netscape.
Se ti riferisci all'imposizione di IE come browser quando ancora non era integrato in Windows, hai ragione.
Se ti riferisci al fatto che Windows abbia poi integrato IE, sono d'accordo con MS.
Se ti riferisci alla "guerra dei browser", ti ricordo che Netscape ha tirato fuori anche più tag HTML rispetto a IE (fino a quando non ha perso la guerra, s'intende).
Per quanto riguarda gli accordi commerciali per i drivers, mi riferivo alle varie "Microsoft Certified" che i produttori hardware espongono sui loro prodotti a mo' di 'garanzia'. Costa cosi' tanto fare un driver anche per un altro sistema?
Evidentemente sì, se per altro sistema ti riferisci a Linux. Linux filosoficamente ha abbracciato (per forza di cose) un modello dei driver basato sul sorgente piuttosto che su delle ben precise specifiche (che portano a un set di driver binari), come avviene invece negli altri sistemi.
Mi sembra davvero strano infatti che ATI ed NVIDIA ad esempio facciano drivers per linux quando i videogames su linux praticamente non esistono, mentre altri produttori (anche solo le webcam sono un esempio) normalmente se ne fregano? A me questo sembra un modo come un altro per 'spingere' l'utente a continuare ad usare Windows, scoraggiandolo a cambiare: se all'utente viene voglia di provare un altro sistema, nel 95% dei casi (statistica personale guardando i miei clienti) le resistenze sono proprio quelle del supporto hardware (che comunque c'e', ma fatto non dalla casa costruttrice in tanti casi...). Comunque se vuoi sono pronto ad allargare il discorso sui drivers che ho introdotto fin qui.
Fai pure.

Il concetto per me è semplice: tirare fuori un solo driver (o al più 2, se consideriamo anche quelli per le piattaforme x86-64) non è certo la stessa cosa che tirarne fuori uno che sia compatibile con tutti i tipi di kernel con cui potrebbe avere a che fare con Linux, oppure "n" diversi per ogni tipo di kernel.

Capisci che non è una soluzione praticabile, tanto più per dei piccoli produttori di hardware. E capisci pure perché Ati e Nvidia non si facciano problemi a supportare Linux, visto che sono dei colossi.

La soluzione che "piace" alla comunità Linux è quella di avere tutte le specifiche per far da sé (al limite) i driver open source per le periferiche, ma non è una cosa che non piace ai produttori di hardware.

^-fidel-^

27-01-2006, 10:41

Semplicemente continuano a sviluppare la loro piattaforma, come hanno SEMPRE fatto. Ti ricordo che:
1) OpenDocument è uno standard recente;
2) scrivere filtri di importazione / esportazione per OpenDocument non è una cosa semplice, e richiede risorse e tempo;
3) il formato Office "rispecchia" molto probabilmente la struttura con cui Office memorizza le informazioni.

Ti ricordo che MS ha iniziato a lavorare al suo standard Open DOPO l'uscita di OASIS.
Il punto 2) non lo obietto, ma sul 3) non sono d'accordo. Soprattutto usando un formato XML, non e' un impresa titanica trasformare le strutture usate in memoria in un formato nuovo: certo non e' semplice come fare un dump della memoria, ma non ci si sta 6 mesi. E' solo una questione di volonta' (penso che per una grande azienda come MS ad implementare un nuovo formato ci stanno poco, come tra l'altro hanno dimostrato con il loro formato Open per il nuovo Office 12). Continuo a dire, avrebbero potuto implementare OASIS invece che inventare E implementare un nuovo formato Open (che poi del tutto open non e'). Se fosse tutto open, non mi creerebbe problemi, dal momento che altri produttori potrebbero facilmente creare filtri di importazione/esportazione.
La strategia di mantenimento della posizione dominante di MS continua a non piacermi (e molto spessonon piace neanche all'antitrust viste le cause perse da MS...)

Se ti riferisci al fatto che Windows abbia poi integrato IE, sono d'accordo con MS.
Io invece ero d'accordo con MS quando si parlava di DOTAZIONE predefinita del sistema Windows con un browser. Sono liberi di fare quello che vogliono ci mancherebbe. Ma da qui a renderlo parte del sitema (con la conseguente impossibilita' di disinstallarlo, o se lo disinstalli a mano perdi diverse features come gli aggiornamenti automatici) ce ne corre... Questo diviene abuso di posizione dominante. Per non parlare del rischio che si ha ad avere un browser che interagisce cosi' a fondo col SO (visto che Win e' preso particolarmente di mira da virus, worms e trojan vari)...
Se ti riferisci alla "guerra dei browser", ti ricordo che Netscape ha tirato fuori anche più tag HTML rispetto a IE (fino a quando non ha perso la guerra, s'intende).
Qui sono d'accordo.

Il concetto per me è semplice: tirare fuori un solo driver (o al più 2, se consideriamo anche quelli per le piattaforme x86-64) non è certo la stessa cosa che tirarne fuori uno che sia compatibile con tutti i tipi di kernel con cui potrebbe avere a che fare con Linux, oppure "n" diversi per ogni tipo di kernel.

Capisci che non è una soluzione praticabile, tanto più per dei piccoli produttori di hardware. E capisci pure perché Ati e Nvidia non si facciano problemi a supportare Linux, visto che sono dei colossi.

La soluzione che "piace" alla comunità Linux è quella di avere tutte le specifiche per far da sé (al limite) i driver open source per le periferiche, ma non è una cosa che non piace ai produttori di hardware.

L'ultima affermazione che dici e' verissima. Ma questo sta cambiando per i normali users di linux.
Non e' pero' vero quello che dici sui kernel: un driver scritto per un kernel 2.6.x andra' bene (nella quasi totalita' dei casi) con tutti i kernel della serie 2.6 (e la serie dura per almeno 2 anni prima di evolversi). Io ad esempio uso drivers per schede di rete fatti per i kernel 2.4... Certo non e' per tutto cosi' (per i kernel 2.6 normalmente hai bisogno di un driver per il 2.6) pero' se io ho un driver per 2.6 posso usarlo sulla 2.6.5 come sul 2.6.15: spero di essere stato chiaro ;)
Anche qui, e' una questione puramente di volonta' piu' che tecnica: al normale utente linux poco gli interessa avere un kernel "tainted" (contenente cioe' codice o moduli closed source).

^-fidel-^

27-01-2006, 10:47

Ah dimenticavo...

Fermo restando a quello che gia' avevi detto: per come si e' evoluto Linux, scrivere un driver per questo SO risulta piu' difficile rispetto a scriverne uno per Win (visto pure il nuovo modello WDF che verra' introdotto con Vista). Ma gia' con il modello WDM, in Win scrivere un driver risulta parecchio "omogeneo" (se mi permettete il termine :))

cdimauro

27-01-2006, 11:30

Ti ricordo che MS ha iniziato a lavorare al suo standard Open DOPO l'uscita di OASIS.
Hai informazioni precise in merito?
Il punto 2) non lo obietto, ma sul 3) non sono d'accordo. Soprattutto usando un formato XML, non e' un impresa titanica trasformare le strutture usate in memoria in un formato nuovo: certo non e' semplice come fare un dump della memoria, ma non ci si sta 6 mesi. E' solo una questione di volonta' (penso che per una grande azienda come MS ad implementare un nuovo formato ci stanno poco, come tra l'altro hanno dimostrato con il loro formato Open per il nuovo Office 12).
Non mi trovi d'accordo, perché l'XML è soltanto un mezzo di trasporto per le informazioni, tanto quanto un file binario o un file di testo.

In soldoni: effettuare un dump degli oggetti in memoria scrivendo su un file binario che ne rispecchi la struttura, oppure su un file xml che presenta una struttura analoga, è cosa facile. Se la struttura dell'XML è molto diversa, il lavoro non può non essere nè poco né semplice.
Continuo a dire, avrebbero potuto implementare OASIS invece che inventare E implementare un nuovo formato Open (che poi del tutto open non e').
Vedi sopra. Ti faccio un esempio pratico. Se ho un oggetto Document che contiene un oggetto Paragrafo e un oggetto Immagine, che ne faccia il dump su un file binario che sia strutturato così:

DOCUMENTO Pippo[PARAGRAFO[Hello, world!]IMMAGINE [GIF89....]]

oppure un dump su un xml che abbai la seguente struttura:

<DOCUMENTO Nome="Pippo">
<PARAGRAFO>Hello world!</PARAGRAFO>
<IMMAGINE>GIF89...</IMMAGINE>
</DOCUMENTO>

è piuttosto semplice.
Se fosse tutto open, non mi creerebbe problemi, dal momento che altri produttori potrebbero facilmente creare filtri di importazione/esportazione.
Il formato di MS è aperto, e ne sono state rilasciate le specifiche.
La strategia di mantenimento della posizione dominante di MS continua a non piacermi (e molto spessonon piace neanche all'antitrust viste le cause perse da MS...)
In tal caso si tratta di ABUSO di posizione dominante, che è stata giustamente sanzionata.

Il fatto che MS sia in posizione dominante non vuol dire che passerà il tempo a commettere abusi.
Io invece ero d'accordo con MS quando si parlava di DOTAZIONE predefinita del sistema Windows con un browser. Sono liberi di fare quello che vogliono ci mancherebbe. Ma da qui a renderlo parte del sitema (con la conseguente impossibilita' di disinstallarlo, o se lo disinstalli a mano perdi diverse features come gli aggiornamenti automatici) ce ne corre... Questo diviene abuso di posizione dominante.
Non sono d'accordo, visto che tutti gli altri s.o. integrano ben altro che un semplice broswer.
Per non parlare del rischio che si ha ad avere un browser che interagisce cosi' a fondo col SO (visto che Win e' preso particolarmente di mira da virus, worms e trojan vari)...
IE non è integrato nel sistema: semplicemente fa uso di alcuni componenti che Windows mette a disposizione. Tant'è che esistono altri browser basati su questi componenti.

Inoltre il proliferare di virus, work, ecc. è dovuto ad altri fattori (uso dell'amministratore come utenza normale, in primis).
L'ultima affermazione che dici e' verissima. Ma questo sta cambiando per i normali users di linux.
Non e' pero' vero quello che dici sui kernel: un driver scritto per un kernel 2.6.x andra' bene (nella quasi totalita' dei casi) con tutti i kernel della serie 2.6 (e la serie dura per almeno 2 anni prima di evolversi). Io ad esempio uso drivers per schede di rete fatti per i kernel 2.4... Certo non e' per tutto cosi' (per i kernel 2.6 normalmente hai bisogno di un driver per il 2.6) pero' se io ho un driver per 2.6 posso usarlo sulla 2.6.5 come sul 2.6.15: spero di essere stato chiaro ;)
Io mi riferivo ad altro, veramente. Non alla versione del kernel, ma al fatto che i kernel possono essere configurati in maniera diversa e richiedono driver che funzionano in modo diverso.

Esempio: kernel SMP e non SMP funzionano in maniera diversa per alcuni aspetti.
Anche qui, e' una questione puramente di volonta' piu' che tecnica: al normale utente linux poco gli interessa avere un kernel "tainted" (contenente cioe' codice o moduli closed source).
Al normale utente no, ma ai puristi Linux magari sì.

^-fidel-^

27-01-2006, 12:06

Hai informazioni precise in merito?
Cerco nella marea di segnalibri che ho nel browser e ti dico :)

Il formato di MS è aperto, e ne sono state rilasciate le specifiche.
Potresti postarmi il link? Mi risultava che si', hanno rilasciato le specifiche (come detto prima), ma queste specifiche non comprendono tutte le funzionalita'...
Sempre poi (ma qui voglio proprio pensare a male :)) che non mettano royalties sull'uso del formato :D Per FAT sembra stiano facendo cosi'... Deleterio soprattutto per MS credo, se la cosa va in porto. Abuso si', a eccesso no.

Il fatto che MS sia in posizione dominante non vuol dire che passerà il tempo a commettere abusi.
Sarei d'accordo, ma viste le ultime cause intentate a MS (tipo quella per il MediaPlayer)...
Cmq, a volte non commettono reati veri e propri, ma appunto "spingono" gli utenti all'uso dei loro prodotti (come appunto "l'imposozione" de facto di standard proprietari). Tra l'altro un'osservazione: vedo diffondersi il formato wmv per gli stream multimediali. Ti assicuro che c'e' di meglio in giro (vedi RealPlayer), che sono multipiattaforma (vedi sempre realplayer)ma gia' ho trovato alcuni siti che RICHIEDONO windows media player 10 per vedere i filmati... Ci si mettono in mezzo pure gli admin dei siti internet adesso... Questo credo nasca sempre dal fatto che Win e' sul 95% dei pc home, una cosa mai vista in altri ambiti (pensa se il 95% delle persone girassero con una Punto: non mi sembra immaginabile eheh), davvero un'anomalia.
Se "spingi" l'utente home (e non solo, basta vedere la ridicola campagna "valuta i fatti" fatta da MS nel mondo server) ad usare il tuo SO, automaticamente anche i contenuti distribuiti vengo pensati per QUEL sistema operativo, anche se ci sono alternative multipiattaforma!! Diventano contenuti distribuiti fino ad un certo punto non trovi?
Perche' usano MediaPlayer? Perche' e' gia' integrato!! Mica ti devi scaricare il realplayer apposta... Mamma mia...

IE non è integrato nel sistema: semplicemente fa uso di alcuni componenti che Windows mette a disposizione. Tant'è che esistono altri browser basati su questi componenti.
Tecnicamente si', ma nei fatti lo definirei integrato, dal momento che non puo' fare a meno di quei componenti per funzionare correttamente. Se si appoggiasse solo a quei componenti, allora non lo definirei integrato. Non a caso altri browser (tipo Opera o Firefox funzionano benissimo senza appoggiarsi a quei componenti.[/QUOTE]

Inoltre il proliferare di virus, work, ecc. è dovuto ad altri fattori (uso dell'amministratore come utenza normale, in primis).
Verissimo, io pero' intendevo che se' un componente di sistema a un bug, e quel componente e' usato da IE, vai compromettere tutto il sistema e non solo IE.

Io mi riferivo ad altro, veramente. Non alla versione del kernel, ma al fatto che i kernel possono essere configurati in maniera diversa e richiedono driver che funzionano in modo diverso.

Esempio: kernel SMP e non SMP funzionano in maniera diversa per alcuni aspetti.

Vero, ma ti diro': non ho ancora trovato alcun driver pensato specificamtamente per SMP, oppure due driver, uno per SMP ed uno non SMP. Non a caso io uso un kernel SMP (avendo un P4 HT) ed uso tutti i driver normalmente.
Le differenze ci sono per i kernel object, che vanno a far parte del kernel monolitico dopo la compilazione, ma finora tutti i driver che ho usato erano moduli kernel .so caricati da 'insmod' (per intenderci), quindi indipendenti dalle peculiarita' del kernel stesso.
Per concludere, e' vero che alcuni moduli richiedono kernel piu' nuovi, ma non mi e' ancora capitato sui moduli che implementano drivers per nuovo hardware, ma solo per driver che implementano funzionalita' software (tipo il check del filesystem per implementare in modo nativo le funzionalita di 'Google Search').

ilsensine

27-01-2006, 12:30

per come si e' evoluto Linux, scrivere un driver per questo SO risulta piu' difficile rispetto a scriverne uno per Win
Non parlare di cose che non conosci...

ilsensine

27-01-2006, 12:35

ma finora tutti i driver che ho usato erano moduli kernel .so caricati da 'insmod' (per intenderci), quindi indipendenti dalle peculiarita' del kernel stesso.
Vuoi dire che un modulo _compilato_ per un kernel SMP, funziona su un kernel non SMP e/o viceversa?

^-fidel-^

27-01-2006, 12:46

Non parlare di cose che non conosci...

Scusami mi sono espresso male :muro:
Intendevo ribadire il concetto espresso da cdmauro che "Linux filosoficamente ha abbracciato (per forza di cose) un modello dei driver basato sul sorgente piuttosto che su delle ben precise specifiche (che portano a un set di driver binari), come avviene invece negli altri sistemi. " Non volevo dire piu' difficile come scrittura del driver in se', ma come "specifiche di sviluppo". Mi manca il Linux un modello tipo il WDM di Microsoft, magari puoi illuminarmi tu.

ilsensine

27-01-2006, 12:53

Scusami mi sono espresso male :muro:
Intendevo ribadire il concetto espresso da cdmauro che "Linux filosoficamente ha abbracciato (per forza di cose) un modello dei driver basato sul sorgente piuttosto che su delle ben precise specifiche (che portano a un set di driver binari), come avviene invece negli altri sistemi. " Non volevo dire piu' difficile come scrittura del driver in se', ma come "specifiche di sviluppo". Mi manca il Linux un modello tipo il WDM di Microsoft, magari puoi illuminarmi tu.
mmm non capisco cosa intendi...linux ha il suo modello per i driver, ovviamente, e ci sono fior di documenti e libri che ne parlano...

^-fidel-^

27-01-2006, 13:00

Vuoi dire che un modulo _compilato_ per un kernel SMP, funziona su un kernel non SMP e/o viceversa?

Nono, onestamente non so se questo sia possibile. Intendevo dire che (omettendo che il driver va comunque compilato usando i sorgenti del kernel installato) lo stesso sorgente di driver compila indifferentemente sia su un kernel SMP che su uno non SMP.
Addirittura (penso ai driver ATI la compilazione viene fatta direttamente quando si installa l'RPM, quindi non c'e' nemmeno bisogno di conoscenze di compilazione manuale, basta avere installato il pacchetto contenente il sorgente del kernel.

^-fidel-^

27-01-2006, 13:04

mmm non capisco cosa intendi...linux ha il suo modello per i driver, ovviamente, e ci sono fior di documenti e libri che ne parlano...

Beh allora ti chiedo, da dove verrebbe il presunto "grande costo" nel produrre driver per linux? Continuo ad essere perplesso a questo punto... :mbe:

ilsensine

27-01-2006, 13:09

Beh allora ti chiedo, da dove verrebbe il presunto "grande costo" nel produrre driver per linux? Continuo ad essere perplesso a questo punto... :mbe:
"Grande costo"? Mi giunge nuova.
Produrre un driver è costoso un pò su tutti i s/o, non vedo perché linux debba essere più costoso degli altri...

^-fidel-^

27-01-2006, 13:25

"Grande costo"? Mi giunge nuova.
Produrre un driver è costoso un pò su tutti i s/o, non vedo perché linux debba essere più costoso degli altri...

Bene allora presumo sia la solita solfa... Non si fanno i drivers per linux perche non si vogliono fare...
Chissa' perche'...

ilsensine

27-01-2006, 13:31

Bene allora presumo sia la solita solfa... Non si fanno i drivers per linux perche non si vogliono fare...
Chissa' perche'...
Chi lo dice che non si fanno? nvidia ha investito fortune nei driver per linux. Altri non li vogliono fare, in quanto considerano linux un mercato troppo di nicchia. Non è il costo di sviluppo del driver a guidare, ma il rapporto costo/utenti.

(comunque io sono tra quelli che ha un kernel "not tainted". Non voglio i loro driver, voglio che rilascino le specifiche della ferraglia. Molti si ritroverebbero con un driver senza aver pagato neanche una lira, guarda un pò).

^-fidel-^

27-01-2006, 13:34

Ah, per completare il discorso sule "spinte" di MS fatto prima con cdmauro:
leggete questo (http://www.gamingforums.com/showthread.php?p=2193526) , soprattutto il punto 'Update 13'. Tra l'altro e' preso da fonte MS. Ecco come estromettere OpenGL dal mercato delle schede video...
E non e' un problema tecnico!
Sempre di piu' si va sul modello "se vuoi giocare devi avere Windows" (so di essere in OT :))

^-fidel-^

27-01-2006, 13:36

Chi lo dice che non si fanno? nvidia ha investito fortune nei driver per linux. Altri non li vogliono fare, in quanto considerano linux un mercato troppo di nicchia. Non è il costo di sviluppo del driver a guidare, ma il rapporto costo/utenti.

(comunque io sono tra quelli che ha un kernel "not tainted". Non voglio i loro driver, voglio che rilascino le specifiche della ferraglia. Molti si ritroverebbero con un driver senza aver pagato neanche una lira, guarda un pò).

Sono d'accordo con te quando parli di driver opensource. Pero' ti chiedo, non trovi che, continuando sul modello esistente (e nulla mi fa credere che cambiera' presto) si "tappano le ali" alle possibilita' di altri SO rispetto a quelli MS?

^-fidel-^

27-01-2006, 13:40

Chi lo dice che non si fanno? nvidia ha investito fortune nei driver per linux. Altri non li vogliono fare, in quanto considerano linux un mercato troppo di nicchia.

Peccato che i "colossi" che fanno driver per linux siano davvero una parte minima rispetto all'hardware esistente...
Ok, in qualche modo si riesce a far funzionare un po' tutto l'harware ma spesso con enormi problemi e con passaggi davvero difficile per un normale utente (che magari prima usava windows).
Personalmente per far funzionare una webcam trust nuovo modello ci sono stato 3 giorni (2 patch e ricompilazioni di kernel per ottenere 8 frame al secondo di capture...)

maxithron

27-01-2006, 13:44

Ho letto tutto, come ti ho già detto.

Vedi sopra. Io leggo e capisco benissimo. Tu hai scritto questo:

"Se la gestione della memoria in .NET fosse cosi' grandiosa, tutti lo userebbero, ma non mi sembra sia cosi' al momento. Sembra che questo discorso lo faccia solo io in tutto il mondo..."

Non sono d'accordo, e ti ho scritto chiaramente anche il perché: è così difficile accettarlo?

Quotando il quote di cdimauro che ha quotato fidel... :D

Ogni giorno che passa, mi rendo conto che sono ancora in pochi ad aver compreso alcuni aspetti del .NET in relazione alla gestione della memoria.

E mi rendo conto sempre di più che nella maggior parte dei casi davvero se ne parla per sentito dire. Ora, non è il luogo adatto per parlarne e mi scuso per l'ot, ma vorrei solo sottolineare che in .NET semplicemente si ha ANCHE lo strumento per non "preoccuparsi" di gestire la memoria. Leggasi:

C'è ANCHE il modo per preoccuparsene con ottimi risultati, entro i limiti ragionevoli per i quali il .NET si rivolge.

ilsensine

27-01-2006, 14:02

Sono d'accordo con te quando parli di driver opensource. Pero' ti chiedo, non trovi che, continuando sul modello esistente (e nulla mi fa credere che cambiera' presto) si "tappano le ali" alle possibilita' di altri SO rispetto a quelli MS?
No

...rispetto a quelli MS?
Non facciamo la guerra a MS. MS d'altronde non è l'unico s/o con driver closed source. Altri s/o con driver closed source non sono riusciti a diffondersi quanto linux. Infine, Se un produttore vuole fare il suo bel driver closed source per linux nessuno lo impedisce, la documentazione c'è e la tecnica per farlo convivere in un ambiante "open source" anche. Non credo che costi più di un driver per windows. Il fatto che questi driver ci siano graditi o meno è poco influente dal punto di vista del produttore.

mjordan

27-01-2006, 14:06

Non e' pero' vero quello che dici sui kernel: un driver scritto per un kernel 2.6.x andra' bene (nella quasi totalita' dei casi) con tutti i kernel della serie 2.6 (e la serie dura per almeno 2 anni prima di evolversi). Io ad esempio uso drivers per schede di rete fatti per i kernel 2.4... Certo non e' per tutto cosi' (per i kernel 2.6 normalmente hai bisogno di un driver per il 2.6) pero' se io ho un driver per 2.6 posso usarlo sulla 2.6.5 come sul 2.6.15: spero di essere stato chiaro ;)
Anche qui, e' una questione puramente di volonta' piu' che tecnica: al normale utente linux poco gli interessa avere un kernel "tainted" (contenente cioe' codice o moduli closed source).

Ancora una volta, non parlare di cose che non conosci...
Fidel, in tutta onestà. Non so cosa sei venuto a domostrare qui sopra, ma vedo soltanto un mucchio di imprecisioni, informazioni campate in aria e teorie personali prese come verità. In tutta franchezza, lo trovo seccante. Su questo forum ci sono persone anche abbastanza tecniche che vorrebbero qualche volta discutere in modo tecnico, senza passare il tempo a correggere castronerie passate per verità. Perchè un conto è avere l'umiltà di parlare di qualcosa, un conto e affermare cose inesatte come verità assolute. Non serve capire gli internals del kernel per sapere che questo che stai dicendo non ha senso. Io per installare i driver nVidia devo quasi sempre aspettare una nuova release dei driver ad ogni kernel.
Le chiamate a basso livello di un kernel che implementano i servizi sono la parte piu' volubile del sistema. E questo si riflette sui driver. Basta installare i driver di una scheda grafica periodicamente ad ogni release del kernel per accorgernsene, non serve capire di programmazione o cosa.

Per quanto riguarda la scrittura difficile dei moduli di Linux. Te ne scrivo uno con poche righe di codice, chiamalo fidel.c:

#include <linux/module.h>
#include <linux/kernel.h>

MODULE_LICENSE("Dual BSD/GPL");

static int lame_init(void)
{
printk(KERN_ALERT "Hi! I'm Fidel. I'm soooo lame...\n");
return 0;
}

static void lame_exit(void)
{
printk(KERN_ALERT "Removing Fidel from the system.\n");
}

module_init(lame_init);
module_exit(lame_exit);

Ora, suppongo (erroneamente) che tu sappia compilare un modulo.
Caricalo con insmod e scaricalo con rmmod. Anche senza eseguirlo si capisce subito cosa fa... :asd:

Ti quoto inoltre una frase di Alessandro Rubini, a testimonianza di quanto dico:

"Kernel interfaces often change between releases. If you are writing a module that is
intended to work with multiple versions of the kernel (especially if it must work
across major releases), you likely have to make use of macros and #ifdef constructs
to make your code build properly."

Il fatto di dover gestire i driver fra una versione di kernel e l'altra è sempre stato un topic caldo, ora in quattro righe di post c'è pure chi lo smonta (autorevolmente pure).

:rolleyes:

Vuoi un'ulteriore conferma? Eccoti un'articolo. Leggi bene ciò che dice James Smart.
http://lwn.net/Articles/144269/
Questo a testimonianza che non conosci quello che dici.
Se devi continuare a essere smentito continuamente per poi (auto)rimangiarti quello che hai detto, fai pure... La brutta figura ce la fai tu.
Ah, come dici tu: spero di essere stato chiaro. :rolleyes:

ilsensine

27-01-2006, 14:14

Peccato che i "colossi" che fanno driver per linux siano davvero una parte minima rispetto all'hardware esistente...
Proprio qui ti volevo. Sai qual'è il sistema operativo che supporta, _nativamente_, più dispositivi hardware (su più piattaforme diverse per giunta!) di chiunque altro?

mjordan

27-01-2006, 14:16

Costa cosi' tanto fare un driver anche per un altro sistema? Mi sembra davvero strano infatti che ATI ed NVIDIA ad esempio facciano drivers per linux quando i videogames su linux praticamente non esistono, mentre altri produttori (anche solo le webcam sono un esempio) normalmente se ne fregano?

Eh già, perchè i driver per le schede grafiche servono solo per giocare... :asd:
Ma sei sicuro che sei "un programmatore che lavora per Microsoft"? :doh: Ma stiamo scherzando? :eek: Costa così tanto? :doh: Quà non ci sta proprio cognizione di causa :eek:

^-fidel-^

27-01-2006, 14:17

C'è ANCHE il modo per preoccuparsene con ottimi risultati, entro i limiti ragionevoli per i quali il .NET si rivolge.

Verissimo, nessuno infatti ha detto che in .NET non si possa programmar in maniera "tradizionale" (ad esempio senza usare il GC)...

Franceloc

27-01-2006, 14:41

Ciao a tutti, il mio primo post su questo forum :)

Scusatemi ma non ho letto tutta la discussione, pero' avrei una domanda da fare:

Io per installare i driver nVidia devo quasi sempre aspettare una nuova release dei driver ad ogni kernel.
Le chiamate a basso livello di un kernel che implementano i servizi sono la parte piu' volubile del sistema. E questo si riflette sui driver. Basta installare i driver di una scheda grafica periodicamente ad ogni release del kernel per accorgernsene, non serve capire di programmazione o cosa.

Non ho capito... io ho una scheda ATI ed aggiorno periodicamente i driver forniti da ATI senza alcun problema. Il kernel è sempre lo stesso (2.6.5). Cosa volevi dire?

Franceloc

27-01-2006, 15:16

Verissimo, nessuno infatti ha detto che in .NET non si possa programmar in maniera "tradizionale" (ad esempio senza usare il GC)...

Ci mancherebbe, non penso che tutti vogliano usare codice "managed", e di norma un framework non sostituisce mai (almeno fino ad ora :))radicalmente un modello di programmazione. Tra l'altro non mi pare nemmeno sia possibile scrivere solo codice managed: ad esempio, scrivendo un programma per il controllo dei processi in Win, non ho trovato nulla nel framework .NET che mi dava informazioni sui processi come le funzioni esportate direttamente dalle API di Windows.
Poi, a seconda delle necessità, il programmatore è libero di usare codice managed o unmanaged.

Franceloc

27-01-2006, 15:34

No

I produttori però, se non ritengono economicamente valido sviluppare drivers per linux, potrebbero rilasciare quantomeno le specifiche harware necessarie a sviluppare un driver per quel periferico. Sono sicuro che cosi' il pinguino si evolverebbe ancora più rapidamente!
Mi è capitato di sviluppare un driver per linux per il controllo di un diplay a cristalli liquidi a tre righe (caratteri visualizzti a matrice di punti) di cui il produttore rilascia il datasheet, e ci sono stato neanche due giorni: non immagino cosa potrebbe fare la comunità se avesse in mano i datasheet di una scheda audio ad esempio! Comunque ho letto spesso che i produttori collaborano attivamente con la open source community, e questo è un gran bene.

ilsensine

27-01-2006, 16:24

I produttori però, se non ritengono economicamente valido sviluppare drivers per linux, potrebbero rilasciare quantomeno le specifiche harware necessarie a sviluppare un driver per quel periferico. Sono sicuro che cosi' il pinguino si evolverebbe ancora più rapidamente!
...a me lo dici? :D

Comunque ho letto spesso che i produttori collaborano attivamente con la open source community, e questo è un gran bene.
"spesso" no, "parecchi" sì. E in diverse forme (anche solo fornire documenti e supporto tecnico agli sviluppatori porta a risultati eccellenti, senza che spendono una lira). In particolare, i produttori di dispositivi di storage sono tra i più aperti.
Alcuni ci ignorano completamente, e forniscono zero documentazione.

mjordan

27-01-2006, 17:45

Ciao a tutti, il mio primo post su questo forum :)

Franceloc, benvenuto sul forum.

Scusatemi ma non ho letto tutta la discussione, pero' avrei una domanda da fare:
Non ho capito... io ho una scheda ATI ed aggiorno periodicamente i driver forniti da ATI senza alcun problema. Il kernel è sempre lo stesso (2.6.5). Cosa volevi dire?

L'esatto contrario di quello che dici tu. Prova a tenere sempre lo stesso driver e aggiornare periodicamente il kernel, invece... Vedi che un driver closed source non è poi cosi "integrato" nel kernel come uno che invece viene rilasciato libero e incluso dentro i sorgenti del kernel. In quell'articolo che ho postato c'è scritto proprio questi e si propone una soluzione. Rilasciare i sorgenti del driver di modo che possa subire un maggiore "audit" da parte degli sviluppatori e garantirsi un supporto quasi a costo zero nella manutenzione fra una release e l'altra. Come spiega quell'articolo, la kernel interface è la piu' soggetta a subire modifiche, anche fra una minor e l'altra.

-fidel-

27-01-2006, 21:13

MEGA OT!!!

Ho scoperto che c'e' un c******* che si spaccia per me su questo forum.
Ho appena letto e riletto i vari post su questo topic e sono allibito.
Sono veramente arrabbiato, se vedete il mio nick (okkio alle ^^) in altri topic non considerate i post di questo personaggio.
Penso pure di aver capito chi è...
Mi ha pure fregato l'avatar da aMSN!!

Devo per caso avvertire qualcuno? Magari per provedere alla cancellazione di quell'account.

Ciao a tutti e scusate l'intromissione.

FINE OT

:ncomment:

diabolik1981

28-01-2006, 13:55

mjordan

28-01-2006, 14:28

-fidel-

28-01-2006, 15:07

Certo, ma bada perchè se l'IP è uguale vi bannano "entrambi"... :asd:

Dai non fare ironia, qui ci perdo la faccia! Dal momento che questo nick lo uso su altri forum ed anche sulla rete messenger (avatar incluso). Comunque non mi offendo, il dubbio puo' sorgere leggittimo :mad:
Seguirò il consiglio di diabolik1981.

Ciao :)

diabolik1981

28-01-2006, 15:25

Dai non fare ironia, qui ci perdo la faccia! Dal momento che questo nick lo uso su altri forum ed anche sulla rete messenger (avatar incluso). Comunque non mi offendo, il dubbio puo' sorgere leggittimo :mad:
Seguirò il consiglio di diabolik1981.

Ciao :)

Fai attenzione, perchè il discorso di mjordan non è sbagliato. Se vi trovate dietro lo stesso IP, tipo NAT Fastweb e simili, il rischio di ban contemporaneo c'è.

mjordan

28-01-2006, 15:35

Dai non fare ironia, qui ci perdo la faccia! Dal momento che questo nick lo uso su altri forum ed anche sulla rete messenger (avatar incluso). Comunque non mi offendo, il dubbio puo' sorgere leggittimo :mad:
Seguirò il consiglio di diabolik1981.

Ciao :)

Non sto facendo ironia, ti ho solo detto che ci sono stati casi di utenti che per riguadagnarla (la faccia) hanno registrato un nuovo account simile e hanno sollevato la tua stessa questione. E visto che entrambi i cloni (anzi scusa, il clone) ha un numero di post praticamente quasi uguale al tuo e una registrazione nello stesso mese, ci devi andare accorto.
Inutile che ti dica come sia andata a finire... ;)

-fidel-

28-01-2006, 16:35

Fai attenzione, perchè il discorso di mjordan non è sbagliato. Se vi trovate dietro lo stesso IP, tipo NAT Fastweb e simili, il rischio di ban contemporaneo c'è.

Io ho fastweb! E giustamente se anche il lamer ha fastweb i mod vedono l'ip del proxy! Di conseguenza se pure lui ha fastweb mi bannano pure a me??? :muro:

-fidel-

28-01-2006, 16:42

Non sto facendo ironia, ti ho solo detto che ci sono stati casi di utenti che per riguadagnarla (la faccia) hanno registrato un nuovo account simile e hanno sollevato la tua stessa questione. E visto che entrambi i cloni (anzi scusa, il clone) ha un numero di post praticamente quasi uguale al tuo e una registrazione nello stesso mese, ci devi andare accorto.
Inutile che ti dica come sia andata a finire... ;)

Spe non capisco... Io mi sono registrato ieri (o avanti ieri non ricordo bene) perchè leggevo le news di hwupgrade via feed rss. Mi è venuta voglia di rispondere ad un topic - tra l'altro il forum mi è parso "popolato" da gente preparata e mi ha "preso" subito - e mi sono iscritto. Mi è parso subito strano che la procedura di iscrizione mi dicesse che il nome utente esisteva già. Non mi era mai capitato, col mio nick ho dovuto aggiungere gli "abbellimenti" proprio perchè comunissimo, però non mi sono soffermato alla cosa e ho postato. Poi per puro caso, girando nel menu' del forum per capire come era strutturato, mi sono imbattuto in un post di ^-fidel-^, che tra l'altro era poco benevolo. Meravigliato, ho letto tutto ed il resto lo sapete :cool:

mjordan

29-01-2006, 18:32

Spe non capisco... Io mi sono registrato ieri (o avanti ieri non ricordo bene) perchè leggevo le news di hwupgrade via feed rss. Mi è venuta voglia di rispondere ad un topic - tra l'altro il forum mi è parso "popolato" da gente preparata e mi ha "preso" subito - e mi sono iscritto. Mi è parso subito strano che la procedura di iscrizione mi dicesse che il nome utente esisteva già. Non mi era mai capitato, col mio nick ho dovuto aggiungere gli "abbellimenti" proprio perchè comunissimo, però non mi sono soffermato alla cosa e ho postato. Poi per puro caso, girando nel menu' del forum per capire come era strutturato, mi sono imbattuto in un post di ^-fidel-^, che tra l'altro era poco benevolo. Meravigliato, ho letto tutto ed il resto lo sapete :cool:

Bene allora non credo ci siano i presupposti per un bannaggio. Del resto se costui si è registrato prima di te, allora sei tu che gli hai fregato nick e avatar ( :D ).
Non credo abbia senso neanche parlare di "omonimia" perchè i nick sono diversi e visto il nick il tuo avatar è abbastnza comune.