Utilizzo diretto di SQL

[Mario]

Be', sei fai un "file" sui file .so nelle rispettive cartelle a volte trovi oggetti a 64 bit, o comunque non riconosciuti dai programmi nati a 32 bit.
Quando ho un attimo ti posto il risultato :)
Sinceramente il perché non lo so, ma a volte mi capita di non avere "fortuna" con certi programmi e non riuscire a installarli sulla macchina di produzione (quella che uso adesso), mentre su altre che sono 386 va benissimo...

[md9327]

In realtà, Linux è super nei sistemi a 64 bit, il problema è legato solo ai programmi; alcuni stanno subendo parecchi ritardi nell'adattamento.

Anche io non ho mai messo mano ai 64 nei miei sistemi, proprio per questi motivi; inoltre il consumo di risorse è maggiore, anche se la velocità è un bel compromesso, ma per questo è necessario che giri tutto a 64.

Ho potuto vedere il comportamento di una distro linux su un sistema multiprocessore 64bit, non i dual o i quad core, e devo dire che le prestazioni spaventano, al contrario di altri sistemi operativi (ovviamente tirando fuori Unix, anche se in qualche caso Linux ha un qualcosina in più...).

Per i miei computer ho sempre ritenuto più affidabile e più standard il processore Intel, rispetto ad AMD; in effetti qualche tempo fà la differenza era evidente, forse oggi non lo è più così tanto, ma comunque nelle caratteristiche che forniscono per AMD non vedo ancora parametri stabiliti, ovvero si comportano in modo diverso a seconda delle situazioni, e questo a me pare strano.

Comunque, sono due processori molto potenti, ovviamente discorso a parte per xeon e similari...

[Mario]

Eccomi :)

Guardate per esempio questi due file che hanno lo stesso nome ma si trovano in directory diverse, la lib32 e la lib64

in lib64

Codice: [Seleziona]

file libasound.so.2.0.0 
libasound.so.2.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), stripped

in lib32

Codice: [Seleziona]

file libasound.so.2.0.0 
libasound.so.2.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped

Il grosso problema è sui programmi che puntano a una libreria come quella e si aspettano di trovare il file per i 32bit, trovando invece l'altro...
Ovviamente si può bypassare il problema creando ambienti di esecuzione con la corretta lista di librerie, ma non sempre è facile e a volte non è proprio possibile.

[md9327]

Il voler integrare sullo stesso sistema, due ambienti 32 e 64 bit è, secondo me, una forzatura, che può portare a dei bei casini...
E' come voler unificare un windoz con linux... sono due cose completamente separate, e funzionanti in maniera completamente diversa; stessa cosa per i 32/64 bit, a meno che non venga creata una struttura tale da renderli separati e al contempo accessibili dai diversi programmi.

Ma anche se fosse, il problema è che tutti i programmi dovrebbero seguire strettamente questa logica, ma al momento c'è troppa confusione al riguardo, e questo è un periodo di transizione, e molte persone prendono sotto gamba il problema.

Il mio pensiero è che, o si decide per 32 o per 64, e poi si continua su quella strada; il cambiamento in corsa può causare grossi problemi.
Decidere per 64bit al momento, vuol dire intraprendere un discorso più orientato all'avere un sistema più prestazionale, e orientato generalmente a fare da server.
Per chi, invece, usa il pc come strumento di lavoro, di studio o per sviluppo, non ha la necessità impellente di un supercomputer con un consumo doppio di risorse, e su cui molti programmi ancora non girano... a meno di non essere spinti a seguire anche qui la moda del momento...

[Mario]

Che poi, volendo essere pignoli, con le macchine intel 32bit che ci sono in giro adesso (dual core, quad core, si parla anche di otto core, ma non so come li chiameranno: otta core? :-D ), e ram da 4 Gb, penso che nessuno possa dire che una workstation sia "lenta"... :-)

[md9327]

Bè, la velocità non è che dipenda poi solo dal processore, anzi, diciamo che se questo non è ben supportato, tanto vale metterci un 386...

Ormai credo che nessuno si preoccupi più di sviluppare programmi, tenendo conto delle possibili risorse a disposizione; con tutte le possibilità offerte oggi dal mercato hardware, metter sù un sistema mediamente potente, non "sembra" più un problema.
A questo punto, i programmi se ne fregano assolutamente, e per fare le stesse cose di qualche anno fà, richiedono sempre più risorse (processore, memoria, dischi, ecc...).

La potenza di calcolo di questi ultimi processori (io per esempio ho un quad-core), è mostruosa ma...
Tempo fà mi sono divertito a far girare due programmi di elaborazione video, su due dei miei pc, di cui un 486 800Mhz 512Mbyte ram e sistema dischi scsii, e l'altro un dual core 2GHz 2Gbyte ram e dischi sataII... bè, ti dirò che la differenza non è stata poi molta, il nuovo pc ha terminato un minuto prima (dopo 30minuti di elaborazione)...
L'unica cosa che posso dirti su questo test, è che il 486 aveva uan struttura hardware che supportava il processore oltre 80%, diversamente dal dual-core che, seppur di marca, si perdeva nei meandri dei colli di bottiglia del sistema.

Oviamente questo mio esempio è solo tanto per parlare, ma dà un'idea della situazione odierna...
Diciamo che i processori hanno raggiunto, come dicevo pocanzi, potenze esagerate, ma poi il resto che fà? Che ci facciamo di 8core, se poi il software non li prevede? Il processore che fà, si diverte a passarsi i dati da un core e l'altro? A che serve elaborare gigabyte di dati in un secondo, se poi ci vuole mezz'ora per salvarli su disco?

...così, tanto per parlare...

[ccc]

Sono felice che qualcun altro oltre a me pensi che questa situazione sia assurda. Io ho un Pentium 3. Dopo l'ultimo aggiornamento del kernel, il mio computer si riavvia o si spegne (sceglie casualmente una di queste due azioni) dopo 5 minuti di inattività, o di attività di cui non tiene conto (un click su una cartella non è un'attività). Cambiare le impostazioni del risparmio energetico non influenza questa sua simpatica abitudine. Ci ho messo diverso tempo a capire che era colpa del nuovo kernel: nella mia ingenuità non avrei mai creduto possibile che àLinux avrebbe introdotto un bug del genere, eppure non c'è altra spiegazione, e la dimostrazione è che usando il kernel vecchio il bug scompare.

Considerazione I: qualche anno fa si diceva che per chi ha un computer vecchio era molto meglio usare GNU/Linux anzichè Windows; oggi è il contrario.

Avete presente Balazar? E' un giochino. Niente di particolare, è nei repo di Ubuntu e Debian, ha una grafica 3D nettamente inferiore a quella della maggior parte dei giochi scritti per 486. Chi avesse dei dubbi lo provi e poi si vada a rivedere, per esempio, Doom. Bene, vi informo che su un Pentium 3 Balazaar non è utilizzabile.

Considerazione II: i requisiti di sistema si basano su quanto è vecchio un processore al momento in cui è stato scritto il programma e non hanno niente a che vedere con la sua potenza. Se ne fossi in grado, riscriverei un programma per 8086, con le stesse funzionalità, compilandolo su un qualsiasi supercomputer IBM. Sono convinto che sui modelli che usciranno fra pochissimi anni (5 anni?) tale programma non funzionerebbe o risulterebbe troppo lento per essere utilizzato.

Tornando ai 32/64 bit nello specifico, sarò un sempliciotto, o magari avrò provato i 64 bit sui computer sbagliati... fatto sta che non vedo differenza. Del resto, non so se qualcuno si ricorda l'Itanium. Era molto più lento dei computer della stessa "epoca" a 32 bit e Intel venne definita con molti aggettivi poco affettuosi. Se il buongiorno si vede dal mattino...

La differenza tra i 32 e i 64 però c'è ed è quella di cui si è parlato finora: la compatibilità. Allora io dico: forse inizialmente lo scopo dei 64 bit era la velocità, e se fosse rimasto lo scopo principale per tutti questi anni significherebbe che i dirigenti Intel e AMD sono dei cretini che hanno sperperato miliardi su miliardi per ottenere un risultato risibile. Se fosse così però chiunque sarebbe in grado di mettere su un'azienda e superarli nel giro di 2 settimane, cosa che non è ancora successa. Allora lo scopo dei 64 bit non sarà semplicemente obbligarci ad aggiornare hardware e software che altrimenti avremmo potuto non aggiornare per anni e anni e anni e anni a venire? Del resto, è dall'epoca del 486 che un aggiornamento dell'hardware non ha nessuna utilità per l'utente domestico se non migliorare la compatibilità con i nuovi software...

[md9327]

Bè, quando ero piccolino, sperimentavo con l'elettronica, e poi con i pc, che mi autocostruivo e che ancora adesso mi assemblo da solo, scegliendo ogni singolo pezzetto hardware. Questo per dire, che un pò ne capisco, e che con gli anni ho incrementato abbastanza le mie conoscenze, da poter affermare quello che ho scritto.

Ma a parte questo, non credo al discorso tra kernel linux o windoz, ma sicuramente credo che tutti i sistemi operativi si adattano e si evolvono attorno all'hardware; uniformandosi a questa situazione, tengono tutti ad abbandonare le compatiblità precedenti, a favore di miglioramenti per i nuovi supporti. Questo sottintende che è sicuramente probabile che si verifichino incampitibilità con vecchi hardware, tanto sono pochi che ancora lo usano, per cui a chi frega di continuarne lo sviluppo o di manutenere quello esistente?
Ad oggi non penso ci siano ancora persone che usando i dischi analogici di decenni fà, e tra qualche anno ci dimenticheremo i quelli IDE, ed ancora tra qualche decennio esisteranno nuovi sistemi che soppianteranno i precedenti, e così via. E' ovvio pensare che questo tipo di evoluzione, non possa mantenere a lungo compatibilità di sistemi che ormai sono estinti.

Però, rispetto alla II, devo darti conferma che il fondamento vero su cui si basano i cambiamenti, ovvero la reale spinta morale, non è l'evoluzione e il miglioramento, bensì il vile denaro. Il fatto che ogni due mesi tocca cambiare telefonino (è un esempio, ma reale), perchè quello nuovo ha un pelo in più che lo fà diventare di tecnologia superiore, e che comunque si sà che è già possibile costruire microcomputer che già fanno tutto quello che i produttori ci stanno propinando, a goccia a goccia, è già possibile farlo, ma che sarebbe molto poco economico... bè, dire che è una cosa schifosa è dire ancora nulla...

...

me è tanto per parlare, no?

[milio]

Mi intrometto nella discussione per segnalare che ho avuto lo stesso problema.
Ho da poco aggiornato il mio pc (con processore AMD 64) alla versione di kubuntu 8.10 64 bit ed installato i relativi driver odbc per mssql (freetds) e firebird. Ebbene con isql funziona tutto perfettamente ma con gambas si mi apre la connessione ma al momento di passargli l'istruzione con la function .exec mi da l'errore che ha dato a overhill.
Avete per caso notizie fresche per questo baco?