NetSurf 2.6 ai nastri di partenza

Le nostre news in homepage

Moderatore: Newser

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda m3x » lun ott 04, 2010 9:12 pm

ShInKurO ha scritto:Assolutamente non era mia intenzione pormi un gradino sopra Nube o altri, ma il dato di fatto è questo: non è semplice spiegare a un utente certe cose, e mi pare più scorretto fargli credere che non cambi nulla dall'usare uno shared object o libreria statica (visto che parli della versione per OS3 immagino tu intenda quella) rispetto a usare un datatype...
Chiedo scusa se ho usato un tono saccente, ma ripeto, per me non è corretto nei confronti di chi legge far passare per "buone" certe inesattezze... tutta questa indulgenza verso inesattezze più o meno evidenti tende a mostrare la comunità Amiga come un gruppo di fanatici secondo me...

Quindi secondo il tuo punto di vista, nel caso del porting di una applicazione, è meglio usare un datatype che potrebbe avere funzionalità limitate e basato su una vecchia versione, per esempio, della libpng, piuttosto che una link o shared library che può essere aggiornata in qualsiasi momento in cui ne esce una nuova?

E sempre dal tuo punto di vista meglio che colui che porta l'applicazione perda tempo a convertire il codice, con la certezza di andare ad usare un codice (quello del datatype) vecchio, che cmq al suo interno utilizza codice simile a quello che lui sta rimuovendo (quindi replicato) e sul quale non ha controllo (al contrario di una shared o link library che può aggiornare lui stesso) ?

Secondo il mio punto di vista, un conto è usare i datatype per una applicazione nativa, scritta dal nulla, un conto invece è perde tempo nel convertire un codice di un'altra piattaforma per "amighizzarlo" (conversione che è puramente formale e non sostanziale perchè non si fa altro che spostare il codice dalla applicazione al datatype)
Avatar utente
m3x

Admin
 
Messaggi: 2250
Iscritto il: mer set 10, 2003 11:30 pm
Località: Roma

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda cdimauro » lun ott 04, 2010 9:30 pm

m3x ha scritto:
cdimauro ha scritto:A questo punto mi viene anche il dubbio che questi sviluppatori nemmeno conoscano come funzioni AmigaOS. :no:

Bah ! png.datatype utilizza internamente libpng (vedi ad esempio PNGdt44.lha per OS3.x su Aminet)

Usa quello che gli serve del codice sviluppato per leggere i dati del PNG. Lo stesso per il datatype JPEG, ecc.
Quindi un programmatore che porta un programma su amiga che utilizza libpng, (ma anche jpeg ecc..) deve perdere tempo ad usare invece i datatype che poi cmq al loro interno utilizzano lo stesso libpng ?

La libpng è una libreria shared, non è un datatype, e non ti ci interfacci allo stesso modo.

Comunque se un'applicazione utilizza altri formati oltre PNG cosa fa? Utilizza n librerie shared, duplicando il codice per leggere (e magari scrivere) le immagini?

I datatype nascono per astrarre e fornire UNA sola interfaccia per leggere questo tipo di informazioni, estendibile all'infinito senza toccare una sola riga di codice di TUTTE le applicazioni che ne fanno uso.
Con lo svantaggio aggiuntivo che magari la versione di libpng usata nel datatype è molto più vecchia di una disponbile in versione shared o linkabile e quindi magari non supporta nuove fatures introdotte in nuove versioni di libpng ??

A maggior ragione: si aggiorna il datatype e automaticamente tutte le applicazioni che ne fanno uso beneficeranno della versione più aggiornata.

Senza nemmeno richiedere la compilazione delle applicazioni (che a volte non è nemmeno possibile).
Alla faccia della programmazione efficiente...

A me pare che, al contrario, sia un sistema più efficiente e flessibile.

Io vedo solo vantaggi nell'usare i datatype, anziché inventarsi continuamente la ruota e aggiungere n-mila volte lo stesso codice alle n-mila applicazioni che ne usano queste lib*, che magari si portano dietro le loro versioni, e capita pure che funzionino solo con quelle versioni...

Per il resto concordo con ShInKurO.
Avatar utente
cdimauro

Eroe
 
Messaggi: 2454
Iscritto il: mer giu 16, 2010 9:00 pm
Località: Germania

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda m3x » lun ott 04, 2010 9:47 pm

cdimauro ha scritto:Comunque se un'applicazione utilizza altri formati oltre PNG cosa fa? Utilizza n librerie shared, duplicando il codice per leggere (e magari scrivere) le immagini?

Stiamo parlando nello specifico di Netsurf, una applicazione di cui è stato fatto il porting, e che quindi al suo interno il codice per leggere le immagini è già presente.
Quindi colui che ha portato il codice non ha dovuto modificare nulla, se non usare il lavoro già svolto da chi ha scritto l'applicazione originaria.

A maggior ragione: si aggiorna il datatype e automaticamente tutte le applicazioni che ne fanno uso beneficeranno della versione più aggiornata.

Senza nemmeno richiedere la compilazione delle applicazioni (che a volte non è nemmeno possibile).

A parte che i datatype come PNG sono entrati a far parte direttamente del sistema operativo (quindi l'aggiornamento non sarebbe cosi immediato in quanto occorre attendere un eventuale aggiornamento del SO stesso), il discorso è analogo (come già detto in precedenza) per una libpng che può essere aggiornata direttamente da chi ha effettuati il porting dell'applicazione in questione, in questo caso di Netsurf
A me pare che, al contrario, sia un sistema più efficiente e flessibile.

Io vedo solo vantaggi nell'usare i datatype, anziché inventarsi continuamente la ruota e aggiungere n-mila volte lo stesso codice alle n-mila applicazioni che ne usano queste lib*, che magari si portano dietro le loro versioni, e capita pure che funzionino solo con quelle versioni...

Per il resto concordo con ShInKurO.

Di nuovo, stiamo parlando di applicazioni non native, per cui il codice è già presente.
Ma cmq capisco che è inutile insistere, se si fa del qualunquismo, invece che rimanere nello specifico, cioè del porting di Netsurg e dell'utilizzo delle libxxx al suo interno...
Avatar utente
m3x

Admin
 
Messaggi: 2250
Iscritto il: mer set 10, 2003 11:30 pm
Località: Roma

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda cdimauro » lun ott 04, 2010 10:04 pm

m3x ha scritto:
cdimauro ha scritto:Comunque se un'applicazione utilizza altri formati oltre PNG cosa fa? Utilizza n librerie shared, duplicando il codice per leggere (e magari scrivere) le immagini?

Stiamo parlando nello specifico di Netsurf, una applicazione di cui è stato fatto il porting, e che quindi al suo interno il codice per leggere le immagini è già presente.
Quindi colui che ha portato il codice non ha dovuto modificare nulla, se non usare il lavoro già svolto da chi ha scritto l'applicazione originaria.

Questo è pacifico, ma non è un'applicazione integrata nel sistema e si porta dietro codice duplicato, appunto.
A maggior ragione: si aggiorna il datatype e automaticamente tutte le applicazioni che ne fanno uso beneficeranno della versione più aggiornata.

Senza nemmeno richiedere la compilazione delle applicazioni (che a volte non è nemmeno possibile).

A parte che i datatype come PNG sono entrati a far parte direttamente del sistema operativo (quindi l'aggiornamento non sarebbe cosi immediato in quanto occorre attendere un eventuale aggiornamento del SO stesso),

Opinabile. Anche i datatype forniti col s.o. si possono cambiare, se arriva una versione migliore.
il discorso è analogo (come già detto in precedenza) per una libpng che può essere aggiornata direttamente da chi ha effettuati il porting dell'applicazione in questione, in questo caso di Netsurf

Ma non serve. Se utilizzi i datatype aggiorni l'applicazione e ti dimentichi di come leggere le immagini. Hai meno dipendenze.
A me pare che, al contrario, sia un sistema più efficiente e flessibile.

Io vedo solo vantaggi nell'usare i datatype, anziché inventarsi continuamente la ruota e aggiungere n-mila volte lo stesso codice alle n-mila applicazioni che ne usano queste lib*, che magari si portano dietro le loro versioni, e capita pure che funzionino solo con quelle versioni...

Per il resto concordo con ShInKurO.

Di nuovo, stiamo parlando di applicazioni non native, per cui il codice è già presente.

E non è detto che debba rimanerci.
Ma cmq capisco che è inutile insistere, se si fa del qualunquismo, invece che rimanere nello specifico, cioè del porting di Netsurg e dell'utilizzo delle libxxx al suo interno...

Allora è meglio il qualunquismo alla leggerezza con cui si affronta il tema dei port.

Se tutti i port si fanno allo stesso modo, lasciando il codice così com'è "perché tanto è già stato scritto", gli effetti sono tre:

1) non ti integri col s.o.;
2) perdi i vantaggi che ne derivano;
3) per ogni applicazione avrai codice duplicato tante volte quante sono le applicazioni e il numero di formati che leggono.
Ultima modifica di cdimauro il lun ott 04, 2010 10:07 pm, modificato 1 volta in totale.
Avatar utente
cdimauro

Eroe
 
Messaggi: 2454
Iscritto il: mer giu 16, 2010 9:00 pm
Località: Germania

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda ShInKurO » lun ott 04, 2010 10:06 pm

m3x ha scritto:Secondo il mio punto di vista, un conto è usare i datatype per una applicazione nativa, scritta dal nulla, un conto invece è perde tempo nel convertire un codice di un'altra piattaforma per "amighizzarlo" (conversione che è puramente formale e non sostanziale perchè non si fa altro che spostare il codice dalla applicazione al datatype)


Mi avrebbe fatto un favore duplicando il codice come dici tu e usando il datatype png, in questo modo da utente non mi avrebbe sputtanato timberwolf, non credi? :ammicca:

Vista la mia ignoranza in materia: che genere di vantaggi in termini di caratteristiche comporta usare lo shared object piuttosto che il datatype (intendo nel caso del png, non in generale). Dici che il codice del png datatype risulta più obsoleto, ma in che contesto?

Cesare ti ha ovviamente risposto quello che penso anch'io: visto che l'OS è sviluppato in teoria si aggiorna il datatype e si punta sull'infrastruttura nativa piuttosto che abbandonarsi al codice dello .so... o al massimo si cambia il datatype... soprattutto perchè a quest'ora mi funzionerebbe ancora Timberwolf (eheh, mi spiace, ma questo avvenimento dimostra come una delle caratteristiche vantaggiose degli .so rispetto alle library Amiga non sia stata completamente sfruttata, e cioè il poter mantenere più versioni della stessa libreria in memoria e avere nella directory del programma i propri .so, quindi è inevitabile che lo rimarchi :eheh: )
Avatar utente
ShInKurO

Eroe
 
Messaggi: 1428
Iscritto il: dom mar 14, 2004 3:10 pm

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda afxgroup » lun ott 04, 2010 10:20 pm

E' tutta questione di chi impacchetta i programmi visto che se Chris avesse creato una cartella SObjs/ dentro netsurf e ci avesse installato i suoi sobjs non avrebbe sputtanato nulla.
Lo sputtanamento lo avevi anche in passato se cambiavi una .library con un'altra. Non vedo dove stia la differenza. Idem per i Datatypes. Se ti installavi un datatype buggato sputtanavi il tutto. Che differenza c'è?
Riguardo i Datatypes.. beh ce lo vedo che mi cambio il codice di un gioco per fare il figo e leggere i png/jpeg via datatypes..
Cioè devo cambiare codice (con la possibilità di commettere errori) solo perchè devo dire! "Guarda Freespace 2 per AmigaOS usa i Datatypes per leggere le immagini!"
I Datatypes sono utili per i programmi nativi vedi Aweb che hanno sin dall'inizio il loro supporto e dove c'è una astrazione nel caricamento dei mime types. Ovvio che non tutti i programmi del mondo (diciamo il restante 99.9999999999999999999%) sa che esistono i datatypes..
Ma noi dobbiamo fare i fighi e non usare programmi provenienti da Linux. uhm.. chissà se OWB x MOS usa i datatypes.. e strano a dirsi.. ma usa Freetype.. che strano.. o magari curl.. non mi sembrano cose "Amigose". Idem per Cairo.. perchè non reinventarsi una libreria "Amigosa" invece di rubare sempre da linux?
Ritornando ai datatypes. Nessuno dice che non siano utili. Anzi è una peculiarità di AmigaOS. Ma lo posso capire per programmi tipo Editor grafici & co ma non per tutti i software solo perchè devo dire di averli utilizzati

Vabbè.. torno nel loculo..
Avatar utente
afxgroup

Admin
 
Messaggi: 3647
Iscritto il: ven giu 11, 2004 9:49 am
Località: Taranto

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda ShInKurO » lun ott 04, 2010 10:39 pm

afxgroup ha scritto:E' tutta questione di chi impacchetta i programmi visto che se Chris avesse creato una cartella SObjs/ dentro netsurf e ci avesse installato i suoi sobjs non avrebbe sputtanato nulla.
Lo sputtanamento lo avevi anche in passato se cambiavi una .library con un'altra. Non vedo dove stia la differenza. Idem per i Datatypes. Se ti installavi un datatype buggato sputtanavi il tutto. Che differenza c'è?


La differenza c'è ed è enorme: le library amiga (e dunque le classi boopsi/reactio/mui/datatype) quando stanno in memoria e sono utilizzate da un programma non le puoi smontare, mentre il vantaggio principale degli shared object è soprattutto quello di avere più versioni in memoria in un contesto come quello di AmigaOS.
Il tuo programma su AmigaOS può anche avere tutte le librerie che gli servono nella propria directory con tutte le versioni corrette (YAM e NoWinED per esempio), ma se in memoria c'è un altro programma che utilizza le librerie richieste, ma di una versione precedente a quella utile beh, allora sei fregato. Devi avvisare l'utente che dovrà chiudere il programma incriminato, lanciare il tuo e sperare che il programma precedente funzioni bene anche con le librerie aggiornate (nel senso che non faccia assunzioni strane sulla versione vecchia che utilizzava prima).
Gli shared object per come sono pensati su UNIX risolvono questa situazione, permettendoti di avere per ogni programma una propria versione di libreria in memoria se ce ne fosse bisogno. Dunque ti permettono di creare pacchetti software sicuri che non dovrebbero inquinare il sistema.

Vabbè.. torno nel loculo..

Statte qua :ammicca:
Avatar utente
ShInKurO

Eroe
 
Messaggi: 1428
Iscritto il: dom mar 14, 2004 3:10 pm

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda guruman » lun ott 04, 2010 10:53 pm

Beh, e' vero anche secondo me che nel contesto di un port puo' non aver senso modificare pesantemente il codice e le interfacce. Tuttavia a questo punto, visto che tanto questi Shared Objects su AmigaOS 4 sono shared solo nel nome, in quanto viene caricata un'istanza in memoria per ogni applicazione aperta, e linkata al runtime, perche' quel codice non viene direttamente linkato staticamente eliminando alla radice il problema? Tanto i GB di HD vengono un tanto al kilo ormai, semmai preziosa sarebbe la memoria RAM in un sistema a 32/31 bit come Amiga, ma come detto gli .so in memoria non sono shared...
Invece, se si volesse una soluzione che preservi le interfacce, e dunque permetta di effettuare port velocemente, e che sia "efficiente" nel senso "amighista" del termine, una classica .library sarebbe la via maestra. Questi .so, implementati cosi', sembrano ne carne ne pesce.

Ram Disk:> version png.library full
png.library 51.14 (16-Lug-2009)
using libpng 1.2.38

/me se ne va fischiettando...

Saluti,
Andrea
Avatar utente
guruman

Eroe
 
Messaggi: 960
Iscritto il: sab giu 28, 2003 4:58 pm

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda afxgroup » lun ott 04, 2010 11:00 pm

ShInKurO ha scritto:La differenza c'è ed è enorme: le library amiga (e dunque le classi boopsi/reactio/mui/datatype) quando stanno in memoria e sono utilizzate da un programma non le puoi smontare, mentre il vantaggio principale degli shared object è soprattutto quello di avere più versioni in memoria in un contesto come quello di AmigaOS.

E quindi? Se riavvii, un software che si aspetta un'altra libreria si sputtana. Dove sta la differenza? Che prima del riavvio non la puoi smontare e ti funziona?
Con i .so invece non hai questo problema perchè sai che il programma ti funzionerà sempre (se crei la sotto cartella in PROGDIR:) e se una .so ha qualche problema basta che la sostituisci e ti funziona comunque tutto. E' normale che per le .so più comuni bisognerebbe usare delle librerie "standard". Ovvero, una volta che sai che funzionano bene le metti nell'SDK e usi quelle e non che ti ricompili la tua.

Il tuo programma su AmigaOS può anche avere tutte le librerie che gli servono nella propria directory con tutte le versioni corrette (YAM e NoWinED per esempio), ma se in memoria c'è un altro programma che utilizza le librerie richieste, ma di una versione precedente a quella utile beh, allora sei fregato. Devi avvisare l'utente che dovrà chiudere il programma incriminato, lanciare il tuo e sperare che il programma precedente funzioni bene anche con le librerie aggiornate (nel senso che non faccia assunzioni strane sulla versione vecchia che utilizzava prima).
Gli shared object per come sono pensati su UNIX risolvono questa situazione, permettendoti di avere per ogni programma una propria versione di libreria in memoria se ce ne fosse bisogno. Dunque ti permettono di creare pacchetti software sicuri che non dovrebbero inquinare il sistema.

Eh appunto.. Era quello che intendevo.. Ecco perchè ti dicevo che nè i datatypes, nè le .library di OS4 sono immuni dai problemi comuni del resto del mondo...
La soluzione sarebbe di usare tutto statico.. e amen.. se si trova un errore... si cambia l'exe.. ma almeno sai che la colpa è la tua e non di qualcuno che ti ha cambiato la .so/.library/.pippo davanti al naso.. Ma ovviamente non è una soluzione accettabile (o almeno non per tutto..)

Vabbè.. torno nel loculo..

Statte qua :ammicca:

Nah.. me ne ritorno a Flex e a ZK
Avatar utente
afxgroup

Admin
 
Messaggi: 3647
Iscritto il: ven giu 11, 2004 9:49 am
Località: Taranto

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda afxgroup » lun ott 04, 2010 11:07 pm

guruman ha scritto:Beh, e' vero anche secondo me che nel contesto di un port puo' non aver senso modificare pesantemente il codice e le interfacce. Tuttavia a questo punto, visto che tanto questi Shared Objects su AmigaOS 4 sono shared solo nel nome, in quanto viene caricata un'istanza in memoria per ogni applicazione aperta, e linkata al runtime, perche' quel codice non viene direttamente linkato staticamente eliminando alla radice il problema?

Perchè se devo aggiornare libpango.so su Wesnoth non devo riuppare 50MB di file exe ma solo pochi kilobytes che metto nella mia SObjs/ dentro wesnoth e amen.

Tanto i GB di HD vengono un tanto al kilo ormai, semmai preziosa sarebbe la memoria RAM in un sistema a 32/31 bit come Amiga, ma come detto gli .so in memoria non sono shared...

Vorrei proprio vedere quante .so uguali vengono caricate in memoria durante una normale esecuzione dell'OS... e quanta RAM occupano..

Invece, se si volesse una soluzione che preservi le interfacce, e dunque permetta di effettuare port velocemente, e che sia "efficiente" nel senso "amighista" del termine, una classica .library sarebbe la via maestra. Questi .so, implementati cosi', sembrano ne carne ne pesce.

Per creare una library devi stare a crearti le interfacce, gli stub e tutto il resto e quindi il port non è più veloce ma sicuramente è più "figo" e "amigoso" e non immune dagli sputtanamenti dell'OS anche se più efficiente e amigoso nello sputtanamento
Avatar utente
afxgroup

Admin
 
Messaggi: 3647
Iscritto il: ven giu 11, 2004 9:49 am
Località: Taranto

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda ShInKurO » mar ott 05, 2010 7:12 am

afxgroup ha scritto:Dove sta la differenza? Che prima del riavvio non la puoi smontare e ti funziona?

Si su Amiga il principale vantaggio di usare gli .so è proprio questo, e cioè che non hai i problemi di "non smontaggio" della libreria, dunque la coesistenza di più versioni in memoria della stessa libreria.
Con i .so invece non hai questo problema perchè sai che il programma ti funzionerà sempre (se crei la sotto cartella in PROGDIR:) e se una .so ha qualche problema basta che la sostituisci e ti funziona comunque tutto.

Appunto, stiamo dicendo la stessa cosa :ammicca:

E' normale che per le .so più comuni bisognerebbe usare delle librerie "standard". Ovvero, una volta che sai che funzionano bene le metti nell'SDK e usi quelle e non che ti ricompili la tua.

Ecco, su questo non sono molto d'accordo, perchè appunto si perde il principale vantaggio di avere questo .so su Amiga: l'indipendenza dei pacchetti software dalle librerie globali e il grado di inquinamento del sistema... E se qualcosa va storto (come nel mio caso) non c'è alcuna differenza pratica nell'usare uno .so invece che una library Amiga (a meno che tutti gli altri programmi che usano i .so se ne freghino dell'installazione globale, ma Timberwolf fa assunzioni sull'installazione globale, e dunque...).

Insomma il punto è questo: se si vuole migrare o integrare meglio questi .so al sistema Amiga quantomeno bisognerebbe sfruttare le loro peculiarità rispetto alle library standard Amiga. In altre parole la possibilità di creare pacchetti software indipendenti dall'installazione globale, cosa che attualmente Netsourf e Timberwolf non fanno.
Si potrebbe chiudere un occhio e lamentarsi sottovoce se certe assunzioni le facesse solo Netsurf che è mantenuto da un programmatore di terze parti, ma Timberwolf è mantenuto da chi sviluppa il kernel di OS4, ergo da chi in teoria dovrebbe dare il buon esempio.
Se gli sviluppatori di OS4 si permettono di fare pacchetti software inquinanti lo stesso sistema che sviluppano beh, decisamente non si preannuncia una buona prospettiva futura per OS4. :riflette:
Avatar utente
ShInKurO

Eroe
 
Messaggi: 1428
Iscritto il: dom mar 14, 2004 3:10 pm

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda ShInKurO » mar ott 05, 2010 7:21 am

afxgroup ha scritto:Vorrei proprio vedere quante .so uguali vengono caricate in memoria durante una normale esecuzione dell'OS... e quanta RAM occupano..


Il gatto che si mangia la coda :ammicca:
Non fare queste considerazioni alla Bill Gates e i 640Kb di memoria buoni per tutto :ammicca:

Gli sviluppatori di OS4 spingono verso gli shared object, attualmente due programmi (ma anche altri no?) presi in esame in questo thread li utilizzano. Consideriamo che in memoria tu abbia Timberwolf, OpenOffice, Thunderbird, un p2p che impiega i .so e un programma di chat basato pure sugli .so. Questo è un quadro abbastanza reale dell'utente. Consideriamo che ciascuno di questi programmi apre tre .so e richiede una versione differente di .so, totale .so in memoria = 16.
Consideriamo invece questi programmi che fanno utilizzo delle library Amiga nella versione OS4 (quindi con le interfacce, le quali come sappiamo permettono di avere diverse versioni delle funzioni di libreria in memoria, o almeno così dicono), quante library avrai in memoria? = 3.

Qual'è sempre stata la differenza tra un OS Amiga e un UNIX vantata in tutti i modi dagli amighisti, soprattutto dagli sviluppatori Amiga? È proprio quella di avere questo esiguo consumo di risorse, in questo caso di memoria.

Tra l'altro come ti ha fatto notare guruman, AmigaOS attualmente è un sistema a 31/32bit, quindi io starei molto attento a usare nel 21esimo secolo questi .so prima di aver introdotto dell'hw e un kernel che supportino i 64bit...

P.S.: lo so, mi sono lamentato anche delle interfacce delle librerie su OS4, ma in questo caso rappresentano qualcosa di positivo rispetto a un possibile uso spasmotico degli shared object su Amiga.
Avatar utente
ShInKurO

Eroe
 
Messaggi: 1428
Iscritto il: dom mar 14, 2004 3:10 pm

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda cdimauro » mar ott 05, 2010 7:27 am

ShInKurO ha scritto:Il gatto che si mangia la coda :ammicca:
Non fare queste considerazioni alla Bill Gates e i 640Kb di memoria buoni per tutto :ammicca:

Piccola precisazione: non fu Bill a pronunciare quella frase, ma un ingegnere di IBM. :ammicca:
Tra l'altro come ti ha fatto notare guruman, AmigaOS attualmente è un sistema a 31/32bit, quindi io starei molto attento a usare nel 21esimo secolo questi .so prima di aver introdotto dell'hw e un kernel che supportino i 64bit...

Per fortuna che c'è AROS... :boing:
Avatar utente
cdimauro

Eroe
 
Messaggi: 2454
Iscritto il: mer giu 16, 2010 9:00 pm
Località: Germania

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda ShInKurO » mar ott 05, 2010 8:30 am

cdimauro ha scritto:Per fortuna che c'è AROS... :boing:

Si però c'è il grosso problema di creare una distro a 64bit con annessi software, difatti hanno aperto un bounty per implementare LLVM su AROS...io la vedo dura francamente!

http://www.power2people.org/bounty_058.html
Avatar utente
ShInKurO

Eroe
 
Messaggi: 1428
Iscritto il: dom mar 14, 2004 3:10 pm

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda cdimauro » mar ott 05, 2010 8:36 am

Ma AROS non usa GCC? Perché servirebbe portare LLVM, per nuovo software che usa questo framework/runtime?
Avatar utente
cdimauro

Eroe
 
Messaggi: 2454
Iscritto il: mer giu 16, 2010 9:00 pm
Località: Germania

PrecedenteProssimo

Torna a News e rumors

Chi c’è in linea

Visitano il forum: Nessuno e 13 ospiti