View Full Version : BeOS/Haiku: Thread ufficiale
Per averlo durante puoi premere la barra spaziatrice mentre appare - lampeggiante... e scegli la seconda voce e poi "debugging output"....
Comunque visto che è il filesystem è parzialmente "POSIX" trovi un bel sylog in /var/log :D
Se ci riesco domani provo l'ultima ALPHA vediamo se riesco almeno a far andare il mio mouse senza fili :D :D :D
Per quanto riguarda la mancanza di flash è una spina nel c*lo... io spero che HTML 5 abbia successo al più presto così lo facciamo fuori... finalmente c'è il supporto diretto al TAG video... così si usa il player nativo del SO si possono fare eventuali acelerazione hardware... insomma speriamo di liberarcene al più presto :eek:
ALtro probelma è la mancanza di JAVA che blocca di conseguenza il porting di OpenOffice purtroppo è l'unica alternativa decente a Office della Microsoft... peccato che sia pesantissimo :cry:
Magari llvm potrà darci una mano anche in questo!!!
trapanator
05-09-2009, 19:45
Per quanto riguarda la mancanza di flash è una spina nel c*lo... io spero che HTML 5 abbia successo al più presto così lo facciamo fuori... finalmente c'è il supporto diretto al TAG video... così si usa il player nativo del SO si possono fare eventuali acelerazione hardware... insomma speriamo di liberarcene al più presto :eek:
forse non sai che il codec per il tag VIDEO non è stato definito da w3c... ognuno si comporta come vuole!
ALtro probelma è la mancanza di JAVA che blocca di conseguenza il porting di OpenOffice purtroppo è l'unica alternativa decente a Office della Microsoft... peccato che sia pesantissimo :cry:
Magari llvm potrà darci una mano anche in questo!!!
sarà, ma se vai su phoronix vedrai un paragone tra LLVM e GCC. I risultati non sono ovvii come si credono, anzi. GCC strabatte LLVM.
forse non sai che il codec per il tag VIDEO non è stato definito da w3c... ognuno si comporta come vuole!
Bhe meglio ognuno sceglie quello che preferisce... flv infondo non era altro che Mpeg4/H264 solo che per leggerlo (almeno via web) si doveva usare il loro player flash pesantissimo e - peggio - proprietario!
In futuro quando Youtube passerà a HTML5 potrò vedere i video anche con Haiku o con qualunque OS voglia... per il supporto ai codec direi che Haiku non è così malmesso... hanno portato molto di ffmpeg dentro a MediaKit :D
sarà, ma se vai su phoronix vedrai un paragone tra LLVM e GCC. I risultati non sono ovvii come si credono, anzi. GCC strabatte LLVM.
Beh GCC ha anche anni di esperienza sulle spalle... LLVM è relativamente giovane magari migliorerà... poi anche a discapito di una certa lentezza i vantaggi di LLVM me lo fanno preferire comunque... già avere un interprete JAVA che mi compila nel codice macchina nativo al volo deve essere una figata :D
pabloski
05-09-2009, 21:08
calma calma, llvm-gcc è ha perso contro gcc, vedremo quando confronteranno gcc con llvm-clang se la situazione rimarrà inalterata
riguardo java penso proprio che llvm vincerebbe facilmente
infatti nel caso gcc contro llvm il confronto era tra eseguibili compilati AOT, mentre contro java il confronto sarebbe tra eseguibili compilati JIT
llvm ha un'euristica molto sofisticata e riesce ad ottimizzare meglio quando sa per quale ISA andrà a compilare
BeBarrett
05-09-2009, 21:17
In ogni caso ci sarà un motivo se la apple ha deciso di passare a clang ; ) comunque Haiku è scritto in c++ in massima parte e leggevo che non esiste un front-end c++ decente per ora, ma potrei sbagliarmi.
pabloski
05-09-2009, 21:44
vero, infatti c'è solo llvm-gcc che usa gcc come backend e c'è clang che ovviamente, per ora, ha il supporto completo solo per objective-c
lo stack wireless è stato fatto, con un layer di compatibilità rispetto i driver di freebsd, prossimamente verrà incluso nel sistema, riguardo flash per ora c'è gnash che funziona bene ma ovviamente non vale il flash ufficiale (purtroppo).
http://adek336.republika.pl/haiku-gnash/
http://www.haiku-os.it/immagini/news/gnash-yt_p.png
http://dev.osdrawer.net/repositories/show/haiku-wifi
Quindi, come dicevo, allo stato attuale non posso usare stabilmente il sistema, perchè gnash fa relativamente schifo e lo stack non c'è (si ok, in FUTURO le cose cambieranno... il relativamente facile porting, non è stato implementato quindi probabilmente non è così banale...)
Niente, così non posso usarlo :(
BeBarrett
05-09-2009, 22:24
Passi per gnash ma lo stack c'è eccome e funziona anche. Ti ho dato il link al sorgente.
Finalmente ci sono anche le ISO... ufficiali :D
La ALPHA è vicina:
http://haiku-files.org/releases/R1Alpha1/
trapanator
06-09-2009, 08:06
Niente, così non posso usarlo :(
e non sarai il solo.
indovinate cosa han postato su haiku-os.it :) ..... per i più impazienti incollo direttamente qui il link all'articolo originale :)
http://www.phoronix.com/scan.php?page=news_item&px=NzUxMg (http://www.phoronix.com/scan.php?page=news_item&px=NzUxMg)
Gallium supporta ufficialmente haiku os :)
pabloski
06-09-2009, 11:24
effettivamente già sul forum di haiku ci sono dibattiti da un pò di tempo su gallium o non gallium
ovviamente i pessimisti non mancano mai e sparavano cose tipo 2-3 anni prima di avviare il porting di gallium, ecc....
invece imho hanno fatto bene ad avviarne l'implementazione adesso, visto che entro 1 anno il grosso dei driver linux si sposterà su dri2/gallium
quel che è certo è che con l'implementazione di gallium sarà possibile avere il pieno supporto a tutte le gpu intel, via, amd e matrox
rimarrà da vedere cosa succederà per nvidia, visto che nouveau non è esattamente avanzatissimo :D
Passi per gnash ma lo stack c'è eccome e funziona anche. Ti ho dato il link al sorgente.
Ma se c'è, perchè non lo trovo già compilato nella alpha?!?
BeBarrett
06-09-2009, 13:07
Perchè ancora non è abbastanza maturo, lo vedrai prossimamente, giusto per farti un esempio uno sviluppatore sta scrivendo le preferenze wireless.
In ogni caso il grande vantaggio con gallium sarà di avere dei driver quasi platform indipendent, inoltre abbiamo già un driver accelerato nvidia(lo sviluppatore lavora in NVidia), probabilmente verrà portato su Gallium3D così potranno beneficiarne sia linux che Haiku.
Mi spiego meglio, perchè non vorrei essere frainteso: se il sorgente è completo e funzionante, perchè non viene già incluso nel sistema?
Io di compilazione sotto Haiku non ho esperienza...
Inoltre, l'altro mio dubbio, sono i driver. Sto provando Haiku nel mio netbook e tutto ciò che mi interessa risulta funzionante (sebbene il driver della GMA950 non è accelerato... quantomeno la risoluzione 1024x600 è rispettata). La scheda etherne viene identificata (una realtek), ma il wireless, anche volendo, secondo me non sarà compatibile in quanto è una RTL8187... già una soluzione con ndiswrapper mi consentirebbe un uso sufficiente (per quanto anche li, voglio vedere come si comporterebbe su rete WEP/WPA...)
Insomma, troppi punti interrogativi. Quello che so è che con ZetaOs, dove lo stack wireless è di sistema, ho provato un notebook con la scheda wireless intel 2100 che risulta nella lista delle schede supportate, e nemmeno li funzionava... veniva identificata ma non scansionava le reti visibili... (stessa cosa su un desktop con una ACX100/111 che era supportata, visibile nel pannello wireless, ma non trovava reti...)
Insomma per me il wireless è davvero fondamentale e non ho ancora trovato un qualsiasi sistema BeOs-based che lo sappia far funzionare anche un minimo...
Perchè ancora non è abbastanza maturo, lo vedrai prossimamente, giusto per farti un esempio uno sviluppatore sta scrivendo le preferenze wireless.
Se per maturo intendi incompleto, allora perfavore non consigliate sorgenti da compilare, se poi si sa già non sia funzionante...
Non la prendere come un attacco, solo che bisogna saper consigliare che fare. Nel "caso" wireless, allo stato attuale, l'unico consiglio è quello di aspettare. Compilare non serve certamente ad ottenere un qualche risultato.
Ho appena finito di guardare bene il link con i sorgenti del wireless e il caso vuole che come driver ci sono esattamente la ipw2100 e la atheros, esattamente i due driver che ho utilizzato in ZetaOs e che non mi funzionavano nemmeno "li"...
Insomma, speranze zero che riesca ad usare il wireless nel breve periodo... (tantomeno nel mio netbook)
pabloski
06-09-2009, 15:19
lo stack wifi è in pieno sviluppo e basta guardare i log postati da colin ( quello che sta facendo il porting )
è chiaro che per ora non c'è verso di far funzionare il wireless
però in un anno credo che sia fattibilissimo e probabilmente la R1 avrà questa funzionalità
Quello che mi impressiona positivamente è che lo sviluppo avviene molto velocemente su Haiku a giudicare dalle news che si susseguono, almeno rispetto agli OS alternativi di una volta in cui tra l'annuncio e la riuscita del bounty passavano anche 1-2 anni...
Vabbeh vado a provare la iso della pre-alpha... vediamo se mi va il mouse wireless e la VGA :D
Poi vi racconto :fagiano:
Ecchime qua.. son già tornato :ciapet:
Beh un passo avanti è stato fatto con questa ISO... finalmente il mio mouse wireless funziona... ce lo vado subito a dire a mmlr chissà come sarà contento di chiudere il ticket :D :D :D
Invece il driver NVIDIA continua a darmi "Out of Range" devo andare in VESA :muro: :muro: :muro: ce lo vado subito a dire a rudolfc... ahh non glielo dico :D
Hi there,
Please disregard the previous message and upgrade to r32958. Now the fix seems complete. Please test and let me know!
Thanks!
Rudolf.
Boh io ovviamente la 32598 non la trovo... speriamo la 32959 vada bene lo stesso :p
Comunque devono fare qualcosa poer il LiveCd è lentissimo al limite dell'inusabile... non è un buon biglietto da visita per Haiku :muro:
BeBarrett
06-09-2009, 22:36
Detto per inciso non ho consigliato a nessuno di compilare nulla, ne ho detto che è completo. Ho soltanto risposto a chi diceva che ancora non c'è (smettiamola con questa aria da cortina di ferro per favore).
Lo stack funziona, ho visto uno screenshot del developer e lo vedrete integrato prima della R1.
ciao
pabloski
06-09-2009, 22:50
beh del resto haiku è un sistema in sviluppo, non si può pretendere che ci sia già tutto
pensiamo a quanto linux è più vecchio e a quante centinaia di sviluppatori ha in più
il wifi non è un problema perchè tra lo stack freebsd, le specifiche pubbliche dei vari atheros, zydas e compagnia basta solo incrementare il numero di sviluppatori è si fa presto ad aggiungere un supporto wifi maturo al sistema
mi lascia perplessa piuttosto la deriva linuxiana di alcuni membri della comunità haiku....dicevo in uno dei post precedenti di un tipo che sul forum di haiku ha proposto il porting di dri su haiku
guardatevi bene dal portare qualsiasi cosa che riguardi lo stack grafico di linux, altrimenti haiku finirà per diventare un casino con 10.000 modi diversi e 3.000 framework che fanno la stessa cosa
e poi ovviamente un pò di pubblicità in più ci vorrebbe e spero che l'alpha che uscirà tra una settimana faccia conoscere haiku al pubblico degli smanettoni
BeBarrett
06-09-2009, 22:55
non c'è pericolo stiamo alla larga da linux per concezione, non abbiamo nulla da spartire con linux, a parte qualche progetto che a noi fa comodo, Haiku ha una sua storia e una sua filosofia in quanto OpenBeOS.
non c'è pericolo stiamo alla larga da linux per concezione, non abbiamo nulla da spartire con linux, a parte qualche progetto che a noi fa comodo, Haiku ha una sua storia e una sua filosofia in quanto OpenBeOS.
Mi raccomando :p
Prendete quello che serve, ma non "immischiatevi" troppo...
Comunque i driver NVIDIA continuano a non andare :cry: :cry: :cry:
trapanator
07-09-2009, 08:58
- non riesco a spostare il tracker in modo da avere la barra come windows, è sempre bloccata in alto a destra. Come si fa?
- dov'è il programma che mostra l'attività di CPU come in Beos? quello con istogrammi verdi laterali per intenderci...
trapanator
07-09-2009, 08:59
Comunque i driver NVIDIA continuano a non andare :cry: :cry: :cry:
ma con questi driver esiste l'accelerazione 3D hardware? o è solo per il 2D?
Guarda nel manuale postato pagine addietro mi pare spieghino come sistema la barra del traker come Windows... è anche risolto un tuo cruccio il traker che apre una finestra per ogni dir... è possibile settarlo per avere UNA sola finestra...
Il programma che ti indica l'uso di CPU lo trovi in Desktop Applet mi pare si chiami ProcessorController...
Il driver mi sa che ha solo l'accelerazione 2D... per il 3D ci vorrà Gallium...
Il problema è che avendo un dirver bacato haiku tenta comunque di usarlo e mi becco lo schermo nero ogni volta che boota... devo sempre ricordarmi di premere la barra spaziatrice e selezionare "Fail safe mode"... io sinceramente se avessi solo la WI-FI che non va sarei pure contento :D
Forse perchè della Wi-FI non me ne faccio una sega :eek:
trapanator
07-09-2009, 10:23
Guarda nel manuale postato pagine addietro mi pare spieghino come sistema la barra del traker come Windows...
bello il manuale, complimenti a chi l'ha scritto
Il programma che ti indica l'uso di CPU lo trovi in Desktop Applet mi pare si chiami ProcessorController...
però è diverso da quello di Beos... con quello potevi addirittura disabilitare una CPU o un CORE...
pabloski
07-09-2009, 12:01
i driver nvidia di haiku sono vecchiotti e non sperate in gallium, perchè bisognerà comunque creare un driver specificio per haiku e nvidia non credo lo farà
gallium può permetterti di portare la componente logica del driver, quello che viene chiamato il gallium driver, ma anche in questo caso bisogna comunque ricompilare e modificare per supportare i meccanismi di ioctl di haiku
il problema di nvidia è che è tutto chiuso
seriamente per chi ha intenzione di usare haiku in futuro è forse opportuno puntare su ati
trapanator
07-09-2009, 13:31
seriamente per chi ha intenzione di usare haiku in futuro è forse opportuno puntare su ati
oppure su nouveau.
trapanator
07-09-2009, 13:43
guardatevi bene dal portare qualsiasi cosa che riguardi lo stack grafico di linux, altrimenti haiku finirà per diventare un casino con 10.000 modi diversi e 3.000 framework che fanno la stessa cosa
Beh non puoi impedirlo; tra l'altro se vuoi portare un po' di applicazioni multipiattaforma ci vogliono almeno le librerie GTK/QT/Wxwidgets che girino su Haiku. Tra l'altro, QT è un bel framework e non so se è stato portato su Haiku. E' più semplice per un programmatore utilizzare un framwerok che giri su più piattaforme che non fare una versione ad hoc per Haiku.
trapanator
07-09-2009, 13:44
Poi un'ultima cosa: dalla FAQ leggo questo
What license is Haiku released under?
Haiku is released under the very liberal MIT License. Some third party components (e.g.: some media codecs) may use other licenses.
voi credete che non ci saranno altre distribuzioni basate su Haiku? Secondo me sì, come è capitato pure a FreeBSD.
librerie GTK/QT/Wxwidgets
Questo sono come le definisci anche tu librerie che non c'entrano con lo stack grafico, credo pabloski intenda Xorg.
pabloski
07-09-2009, 14:24
oppure su nouveau.
mi piacerebbe, ma obiettivamente nouveau c'ha gli stessi problemi che ha avuto il driver radeon per anni o che anno ancora oggi i driver per le schede audio creative
il reverse engineering non è il modo migliore per avere supporto all'hardware e infatti usare nouveau seriamente su linux è praticamente impossibile
Beh non puoi impedirlo; tra l'altro se vuoi portare un po' di applicazioni multipiattaforma ci vogliono almeno le librerie GTK/QT/Wxwidgets che girino su Haiku. Tra l'altro, QT è un bel framework e non so se è stato portato su Haiku. E' più semplice per un programmatore utilizzare un framwerok che giri su più piattaforme che non fare una versione ad hoc per Haiku.
il problema è che dri è un hack per garantire a xorg il supporto 3d, quindi tecnicamente è inutile su haiku e per questo servirebbe solo ad appesantire il sistema
qt vedo che c'è un porting in corso, non so quanto abbiano ottenuto http://dev.osdrawer.net/news/show/26
in generale i framework grafici si appoggiano su una specifica api grafica e quindi sono per fortuna indipendenti da dri
ovviamente necessitano dell'api xvideo e anche qui, per fortuna, gallium permetterà di implementare quell'api come una piccola libreria più che altro un wrapper
la cosa interessante di gallium è che da un lato s'interfaccia direttamente col sistema operativo tramite una cosa simile al kernel mode setting, dall'altro sfrutta tanti wrapper per implementare le più disparate api
il tutto fisicamente viene gestito tramite la componente 3d della scheda grafica e il gpgpu
Poi un'ultima cosa: dalla FAQ leggo questo
What license is Haiku released under?
Haiku is released under the very liberal MIT License. Some third party components (e.g.: some media codecs) may use other licenses.
voi credete che non ci saranno altre distribuzioni basate su Haiku? Secondo me sì, come è capitato pure a FreeBSD.
non è un male avere delle distribuzioni, purchè si mantengano dei vincoli di compatibilità
per esempio avere tanti formati di pacchetti è inutile, così come cambiare la struttura del filesystem da una distribuzione all'altra
le distribuzioni haiku potrebbero essere orientati a specifici usi, quindi con particolari interfacce grafiche e programmi preinstallati
non penso abbia senso spingersi oltre....è chiaro che vedremo nascere anche lì tante distribuzioni la cui unica differenza è lo sfondo :D
Detto per inciso non ho consigliato a nessuno di compilare nulla, ne ho detto che è completo. Ho soltanto risposto a chi diceva che ancora non c'è (smettiamola con questa aria da cortina di ferro per favore).
Lo stack funziona, ho visto uno screenshot del developer e lo vedrete integrato prima della R1.
ciao
Mi pare di aver scritto "non lo prendere come un attacco"... ma non sembra aver sortito l'effetto sperato...
Non c'è nessuna aria da cortina di ferro, però consentimi di poterti dire di non consigliare di compilare uno stack wireless cha hai visto in uno screenshot di un developer, se quantomeno quello stack non è funzionante almeno un minimo!
Per funzionante intendo che, anche via terminale, in qualche modo riesco a far funzionare la rete.
Questa cosa, allo stato attuale non è possibile, quindi penso di non essere pazzo a chiederti di non consigliarlo alla compilazione...
o no?
Non me la prendo con te, ti ho solo dato un consiglio.
Il wireless può anche essere inutile per qualcuno (come simpaticamente qualcuno ha fatto notare), per me invece lo è. Proprio in questo momento ti stò rispondendo dal letto e avere un cavo ethernet che arriva fino a letto mi da noia! Andandomi l'audio e il video decentemente (vesa), l'unica necessità è la connessione internet.
Alla stessa maniera, potrei dire "chemmefrega" del driver 3D... pare che devo giocare... il computer lo uso "uso ufficio" (web, posta, documenti, p2p...)
Il flash mi serve invece per vedere i film in streaming o le cazzatine che mi mandano su facebook... (quindi è meno fondamentale...)
Non mi sembra di fare un uso del computer diverso da quello del 90% del pianeta.
Questo problema e mezzo, mi impediscono un uso quasi normale di un sistema operativo che apprezzo molto (dopodichè uso esclusivamente Linux e Mac Os X). Un vero peccato :(
BeBarrett
07-09-2009, 22:22
Mi pare di aver scritto "non lo prendere come un attacco"... ma non sembra aver sortito l'effetto sperato...
Non c'è nessuna aria da cortina di ferro, però consentimi di poterti dire di non consigliare di compilare uno stack wireless cha hai visto in uno screenshot di un developer, se quantomeno quello stack non è funzionante almeno un minimo!
Per funzionante intendo che, anche via terminale, in qualche modo riesco a far funzionare la rete.
Questa cosa, allo stato attuale non è possibile, quindi penso di non essere pazzo a chiederti di non consigliarlo alla compilazione...
o no?
Non me la prendo con te, ti ho solo dato un consiglio.
Ti ripeto non ho consigliato a nessuno di compilare nulla lol.
I driver nvidia di Haiku hanno l'accelerazione 3D ma al momento è disattivata per questioni varie(rudolf lavora in nvidia).
Il programma a cui vi riferite, per disattivare i core e cose simili non è ProcessController ma Pulse, ed è incluso in Haiku, riguardo invece al tracker che apriva una finestra per ogni directory è una caratteristica di BeOS ma sia il suo tracker che quello di Haiku hanno sempre avuto l'opzione per avere il navigator, inoltre avevo proposto alla ml di integrare le funzioni presenti nei vari tracker in giro creati basandosi su OpenTracker (il codice originale della Be Inc.) e prossimamente verrà fatto.
trapanator
08-09-2009, 08:19
inoltre avevo proposto alla ml di integrare le funzioni presenti nei vari tracker in giro creati basandosi su OpenTracker (il codice originale della Be Inc.) e prossimamente verrà fatto.
Ho visto il sito di OpenTracker, perché non usano direttamente quel codice?
BeBarrett
08-09-2009, 13:53
Quello di Haiku è OpenTracker.
Passi per gnash ma lo stack c'è eccome e funziona anche. Ti ho dato il link al sorgente.
Tu questo avevi scritto...
Cmq sia, visto che hai intrapreso questa strada e non ho voglia di polemizzare, la chiudo qui.
BeBarrett
08-09-2009, 20:58
Tu questo avevi scritto...
Cmq sia, visto che hai intrapreso questa strada e non ho voglia di polemizzare, la chiudo qui.
E' meglio finirla, ti faccio vedere comunque lo screenshot di un paio di mesi fa:
http://www.haiku-os.org/blog/coling/2009-07-12/wifi_stack_prototype_works
: )
walter sampei
08-09-2009, 21:42
ragassssssssss, calmaaaaaaaaaaaaaaaaaaaaaa ;) ;) ;)
per favore, un attimo di pausa tutti :)
PatchWorKs
10-09-2009, 12:32
il computer lo uso "uso ufficio" (web, posta, documenti, p2p...)
Il flash mi serve invece per vedere i film in streaming o le cazzatine che mi mandano su facebook...
Non mi sembra di fare un uso del computer diverso da quello del 90% del pianeta.
Ecco, questo è l'esempio pratico per cui ho criticato molto (e continuo a farlo) gli sviluppatori di Haiku: la deriva "general purpose" (in cui temo che Windows sia imbattibile).
Io, invece, sarei felicissimo di rinuciare a tutto pur di riuscire a fare editing video multicam (con almeno 4 streams AVCHD) col mio glorioso Athlon 3000+/512Mb/RAID0.
E invece (con Windows XP 64) mi è toccato metter su un Dual Core @ 3400 MHz con 2x2gb RAM e la CPU arriva al 98% con 3 streams... :doh:
walter sampei
10-09-2009, 13:44
scusate la domanda: se la potenza di un processore in fin dei conti e' quella, come fa haiku a visualizzare fluidi n video quando magari windows o linux si impantanano con un paio???
in teoria la decodifica, a parte l'efficienza del codec, dei driver, e della gestione dello stesso da parte del del so, e' sempre quella :confused: :confused: :confused:
trapanator
10-09-2009, 14:16
scusate la domanda: se la potenza di un processore in fin dei conti e' quella, come fa haiku a visualizzare fluidi n video quando magari windows o linux si impantanano con un paio???
in teoria la decodifica, a parte l'efficienza del codec, dei driver, e della gestione dello stesso da parte del del so, e' sempre quella :confused: :confused: :confused:
questione di architettura del kernel, nonché di ottimizzazioni.
walter sampei
10-09-2009, 14:43
questione di architettura del kernel, nonché di ottimizzazioni.
tradotto, riesce a sfruttare meglio il processore? con il semproncino si 42 del mio porcatile riuscirei a vedere un 1080p pesante???
trapanator
10-09-2009, 15:01
tradotto, riesce a sfruttare meglio il processore? con il semproncino si 42 del mio porcatile riuscirei a vedere un 1080p pesante???
boh! prova, ci sono i livecd :D però al 100% non hai il driver accelerato per la tua scheda video...
pabloski
10-09-2009, 15:03
non è tanto questione di sfruttare il processore, settore nel quale linux è senza pari
il punto sono gli algoritmi che vengono usati e il software che li implementa che non è ridondante, ha il minor numero di librerie linkate staticamente, per questo consuma poca memoria, che a turno si traduce in minori tempi di caricamento, migliore sfruttamente delle cache, non uso della memoria virtuale ( che rallenta in maniera bestiale )
a ciò aggiungi il fatto che non ci sono strani accrocchi come mesa/xrender/dri....per esempio mi aspetto che linux con gallium e dri2 riesca a fare qualcosa di simile, soprattutto perchè si rimuoverà quella zavorra chiamata xorg con le sue strane capacità quanto inutili ( almeno per il 90% degli utenti ) capacità di networking
trapanator
10-09-2009, 15:50
non è tanto questione di sfruttare il processore, settore nel quale linux è senza pari
Beh, diciamo che le differenze di uso della CPU tra i vari OS sono trascurabili a breve-medio termine (non così per i grandi calcoli a lungo termine, infatti i supercomputer girano quasi tutti su Linux/BSD)
il punto sono gli algoritmi che vengono usati e il software che li implementa che non è ridondante, ha il minor numero di librerie linkate staticamente, per questo consuma poca memoria, che a turno si traduce in minori tempi di caricamento, migliore sfruttamente delle cache, non uso della memoria virtuale ( che rallenta in maniera bestiale )
Non è una questione di minor numero di librerie linkate. Ogni software viene scritto con delle librerie, tipo GTK+, QT etc ma queste esulano dal sistema operativo. Infatti se uso FVWM o WindowMaker ottengo una velocità senza pari rispetto a GNOME e a KDE.
a ciò aggiungi il fatto che non ci sono strani accrocchi come mesa/xrender/dri....per esempio mi aspetto che linux con gallium e dri2 riesca a fare qualcosa di simile, soprattutto perchè si rimuoverà quella zavorra chiamata xorg con le sue strane capacità quanto inutili ( almeno per il 90% degli utenti ) capacità di networking
dipende anche da quanto impattano queste cose sulle performance (performance, non sul caricamento dei moduli...)
Guardate che l'uso del processore non c'entra niente ma è tutta questione di architettura del kernel sviluppato con in mente sin dall'inizio la gestione di flussi multimediali che non impattino con il resto dei processi in multitasking... si parla di porte messaggi e tempi di risposta infinitesimi.
È tutto merito dell'efficientissima architettura del kernel.
Ricordo la gente che restava sbalordita anche ai tempi dell'Amiga che per bontà di Exec di soli 50KB (il cuore del kernel AmigaOS) e certamente per l'architettura HW particolare (chipset e bus dedicati etc. quello che 10 anni dopo hanno fatto su mother boards x86) in multitasking ha/aveva prestazioni incredibili a confronto del quale kernel Linux o Win sono dei pachidermi sotto sonnifero (effetto quasi real-time)...
pabloski
10-09-2009, 21:35
linux l'hanno rovinato col completely fair scheduler....aveva ragione Colivas quando criticò i kernel developer per quella scelta
haiku dal canto suo implementa isr realtime e centellina sugli algoritmi per ridurli a complessità lineare
un lavoro straordinario di ottimizzazione che fa la differenza tra software come prodotto e software come arte
walter sampei
11-09-2009, 01:36
ok, lancio un esempio estremo: se con haiku aprissi un video 1080p con un k6-2 500 :sofico: :sofico: :sofico: vedrei qualcosa? se si, con che problemi? (immagino giustamente perdita di frames)
trapanator
11-09-2009, 07:55
ok, lancio un esempio estremo: se con haiku aprissi un video 1080p con un k6-2 500 :sofico: :sofico: :sofico: vedrei qualcosa? se si, con che problemi? (immagino giustamente perdita di frames)
bisogna fare dei test dal vivo, è inutile fare ipotesi.
trapanator
11-09-2009, 15:10
Salve a tutti,
ho voluto fare la prova dei video in contemporanea utilizzando l'ultima alpha disponibile di Haiku (la snapshot di ieri) messa su una chiavetta USB da 4 GB.
Come video di test ho scaricato da questa pagina il primo:
http://www.stereomaker.net/sample/index.html
e precisamente:
http://www.stereomaker.net/sample/rose.zip
ebbene, dopo averlo scompattato e fatto avviare 3 MediaPlayer che facevano vedere lo stesso video... la visualizzazione del video andava a scatti.
Lo stesso capita sotto Windows, pur utilizzando VLC che è più pesante del MediaPlayer fornito di serie. (ATTENZIONE: con VLC ho impostato l'uscita video GDI, cioè non accelerato)
Vi dico la configurazione hardware:
Pentium Centrino Dothan 1,7 Ghz
1 GB RAM
Nvidia Geforce 5200 Go (sotto Haiku ho impostato i drivers VESA)
quindi se scatta con questo processore, figuriamoci su un vecchio processore... certo che quei famosi 6 video in contemporanea sono stati fatti su un Core 2 Duo...
pabloski
11-09-2009, 15:13
e riguardo i driver? usavi i vesa?
da come c'è scritto sembrerebbe che fosse in vesa, invece per quanto riguarda il resto del sistema era ancora fluido (mentre vsionavi i 3 filmati)?
P.S.: c'è anche da considerare la qualità della chiavetta usb, notoriamente alcune sono più lente di altre :), cerco di tirar acqua al mulino di haiku :)
trapanator
11-09-2009, 15:17
e riguardo i driver? usavi i vesa?
sì, l'ho scritto sopra.
Credo anche quelli di Haiku che avevano messo i vesa su quel computer DELL, perché se è un computer recente... non esistono driver di Haiku per nessuna scheda video recente.
trapanator
11-09-2009, 15:18
da come c'è scritto sembrerebbe che fosse in vesa, invece per quanto riguarda il resto del sistema era ancora fluido (mentre vsionavi i 3 filmati)?
Il resto non era tanto fluido, anche il mouse faticava, come se lo stessi muovendo sopra il cemento :D
farò lo stesso test sotto ArchLinux, poi vi faccio sapere.
trapanator
11-09-2009, 15:20
P.S.: c'è anche da considerare la qualità della chiavetta usb, notoriamente alcune sono più lente di altre :), cerco di tirar acqua al mulino di haiku :)
rispondo al tuo EDIT :D il filmato occupava 2,5 MB scarsi, sicuramente era ancora nella cache della memoria (ho 1 GB). L'avevo appena estratto nella home e lanciato subito 3-4 mediaplayer in contemporanea.
Il 4o mediaplayer rendeva il sistema completamente inusabile (1 o 2 filmati si erano addirittura fermati).
La mia penna USB da 4 GB ha una velocità di 11 MB / secondo in lettura.
allora aspettiam i test con archlinux :):):)
trapanator
11-09-2009, 15:27
allora aspettiam i test con archlinux :):):)
Rieccomi.
Sotto ArchLinux e impostato Gnome-Mplayer in modo che visualizzi su X11 con 4 video in contemporanea i filmati scattano un po' (anche se meno che sotto Haiku).
Però voglio fare un'ultima prova: lanciare X.org in VESA. Appena lo faccio vi faccio sapere.
p.s. secondo me questi risultati sono un po' ovvii: tutto sta nella potenza della CPU se non si usa l'accelerazione video.
trapanator
11-09-2009, 15:34
rieccomi, con ArchLinux sotto VESA. I risultati non cambiano.
Però dobbiamo considerare che Haiku è in alpha, aspettiamo quando sarà nella finale :D
giusto anche il discorso della non perfetta ottimizzazione di haiku, è ancora in alpha :)
Cmq ho voluto fare anche io qualche prova (sotto virtualbox però :)) ho estrapolato circa 20 secondi da un divx con il media converter incluso in haiku :) .... e ho fatto partire 5 video in contemporanea (con 4 erano fluidi) e scattavano un po', però il mouse viaggiava che era un piacere tant'è che ho fatto partire anche la teiera girante e la scritta haiku in 3d (il mouse filava ancora ma girava solo la teiera il resto era quasi fisso :))
trapanator
11-09-2009, 15:59
mi sono dimenticato di dirvi che ho provato a montare la partizione (in sola lettura) di Windows (NTFS). Ebbene, dopo aver lanciato il sottomenu "Mount" la CPU restava costantamente al 100%. A voi è capitato?
trapanator
11-09-2009, 16:05
giusto anche il discorso della non perfetta ottimizzazione di haiku, è ancora in alpha :)
Cmq ho voluto fare anche io qualche prova (sotto virtualbox però :)) ho estrapolato circa 20 secondi da un divx con il media converter incluso in haiku :) .... e ho fatto partire 5 video in contemporanea (con 4 erano fluidi) e scattavano un po', però il mouse viaggiava che era un piacere tant'è che ho fatto partire anche la teiera girante e la scritta haiku in 3d (il mouse filava ancora ma girava solo la teiera il resto era quasi fisso :))
Virtualbox, girando sotto Windows e usando i suoi driver video, sfrutta l'accelerazione (2D) della scheda video.
i test è meglio farli su un sistema "liscio" :D
BeBarrett
13-09-2009, 13:14
rispondo al tuo EDIT :D il filmato occupava 2,5 MB scarsi, sicuramente era ancora nella cache della memoria (ho 1 GB). L'avevo appena estratto nella home e lanciato subito 3-4 mediaplayer in contemporanea.
Il 4o mediaplayer rendeva il sistema completamente inusabile (1 o 2 filmati si erano addirittura fermati).
La mia penna USB da 4 GB ha una velocità di 11 MB / secondo in lettura.
Puoi ripetere il test usando un hard disk? lo stack usb di Haiku ha ancora alcuni problemi a seconda della pennetta, e non ha senso paragonare un linux su hard disk contro un Haiku su usb.
trapanator
13-09-2009, 14:07
Puoi ripetere il test usando un hard disk? lo stack usb di Haiku ha ancora alcuni problemi a seconda della pennetta, e non ha senso paragonare un linux su hard disk contro un Haiku su usb.
Giustamente, hai ragione tu. Purtroppo non ho hard disk ne' partizioni da provare.
trapanator
14-09-2009, 10:05
Oggi è uscita la alpha 1.
In questo momento nella chat IRC stanno dicendo che la R2 non supporterà più la GCC2 ma sarà interamente GCC4 (e mi pare giusto... vuoi mantenere ancora GCC2 quando tra poco uscira GCC5???).
Però questo provocherà l'incompatibilità e l'impossibilità di eseguire applicazioni scritte con BeOS.
non sarebbe male se hwupgrade ne facesse un articolo :):) ... mi sa che è voler troppo :):)
trapanator
14-09-2009, 12:00
non sarebbe male se hwupgrade ne facesse un articolo :):) ... mi sa che è voler troppo :):)
perché no? Basta chiedere a qualcuno...
dici che basti mandare un e-mail alla redazione?
buona ho scritto un e-mail alla redazione
pabloski
14-09-2009, 16:39
ragassuoli oggi ho fatto un piccolo esperimento
innanzitutto ho scaricato l'alpha1, installata sull'hard disk del mio minipc nvidia ion con atom 330 e ho provato la cosa dei video
sono arrivato a 7 video divx in contemporanea senza intoppi nè blocchi o rallentamenti del sistema
giudicate voi stessi http://www.youtube.com/watch?v=W3dsDf_DkII
il video è un divx di 704x396px, nulla di incredibile o minimamente vicino ai video hd, ma abbastanza per mandarmi in palla mint linux
in quest'ultimo caso infatti, nonostante usassi i driver nvidia proprietari, sono riuscito ad avviare i 7 video ma a turno 4 si bloccavano totalmente e altri 3 venivano riprodotti normalmente
in entrambi i casi è stato usato vlc come riproduttore
nel caso di linux il problema è stato che la cpu andava a palla e il sistema era praticamente bloccato
durante l'apertura ho avuto problemi dal quinto video in poi perchè l'avvio di vlc e l'apertura del video richiedevano sui 15-20 secondi
la chiusura è stata tragica....cliccando su una delle finestre di vlc ha impiegato 17 secondi per riprendersi e riuscire a chiudere la finestra
da lì in poi è stato più facile ma comunque fino alla chiusura del terzo video era tutto molto scattoso
da lì in poi è cominciato a filare di nuovo liscio
tengo a precisare che i driver nvidia in questione usano VDPAU per accelerare i video
inoltre su haiku ovviamente ho dovuto usare i driver vesa e purtroppo la risoluzione 1280x1024 nonostante il monitor fosse un 23" fullhd
restava un altro 20% di cpu libera sotto haiku, ma lo schermo era già affollato per cui non ho spinto oltre l'esperimento ma credo che almeno un altro video c'entrava senza problemi :D
p.s. le uniche cose che non funzionano sono il wifi (ovviamente), l'audio e chiaramente non c'è uno straccio di driver video
però il sistema funziona bene se non fosse che a qualche frichettone è venuto in mente di metterci quella cosa informe chiamata BeZillaBrowser....per carità avvisate gli sviluppatori, chiamate l'ONU, firefox non deve avvicinarsi ad haiku.....netsurf è buono ma non reinventiamo ogni volta la ruota....c'è un motore di rendering stupendo che si chiama webkit e non serve altro ad haiku
trapanator
14-09-2009, 16:55
ragassuoli oggi ho fatto un piccolo esperimento
bellissimo test, complimenti!
p.s. le uniche cose che non funzionano sono il wifi (ovviamente), l'audio e chiaramente non c'è uno straccio di driver video
però il sistema funziona bene se non fosse che a qualche frichettone è venuto in mente di metterci quella cosa informe chiamata BeZillaBrowser....
Mi sembra che sia basato su Firefox 2.x, che è molto più lento della 3.x.
per carità avvisate gli sviluppatori, chiamate l'ONU, firefox non deve avvicinarsi ad haiku.....netsurf è buono ma non reinventiamo ogni volta la ruota....c'è un motore di rendering stupendo che si chiama webkit e non serve altro ad haiku
webkit è nelle QT
trapanator
14-09-2009, 16:56
Purtroppo io avendo solo un core non posso visualizzare 7 video in contemporanea :D
pabloski
14-09-2009, 17:29
è vero, ho provato con quella demo del campo stellato che ti permette di disabilitare il multithreading
col threading disattivato si dimezzava la velocità
è chiaro che haiku sfrutta al massimo il multithreading e quindi l'ht e i core multipli
questo indica pure che gli altri sistemi operativi sottoutilizzano di brutto il processore
si possono anche disattivare/attivare i core dal controllore dei processi o da pulse e il tutto avviene in maniera indolore (calano ovviamente le prestazioni disabilitando processori :)).
peccato invece che la redazione non abbia accolto la mia richiesta di scrivere due righe su haiku :(
trapanator
14-09-2009, 18:09
peccato invece che la redazione non abbia accolto la mia richiesta di scrivere due righe su haiku :(
e cosa ti ha detto? :D
AnonimoVeneziano
14-09-2009, 18:18
è vero, ho provato con quella demo del campo stellato che ti permette di disabilitare il multithreading
col threading disattivato si dimezzava la velocità
è chiaro che haiku sfrutta al massimo il multithreading e quindi l'ht e i core multipli
questo indica pure che gli altri sistemi operativi sottoutilizzano di brutto il processore
Non ho capito cosa vuoi provare con questo. Non è haiku che sfrutta il multithreading , ma l'applicazione stessa che è stata scritta per sfruttarlo. Non diamo meriti al sistema operativo che bisognerebbe dare all'applicazione
pabloski
14-09-2009, 18:39
certo l'applicazione sfrutta il multithreading, ma se non ha il supporto del sistema operativo può fare poco o nulla
per esempio io ho aperto 7 istanze di vlc ( quindi 7 processi )
ognuno di questi processi è in grado di istanziare vari thread, ma lo scheduling dei processi viene fatto dal sistema operativo non da vlc
infatti lo stesso vlc su linux si comporta molto peggio
il punto è che haiku è in grado di ridurre i tempi di praticamente tutte le operazioni di sistema....lo scheduling è il primo ( motivo per cui Colivas ha maledetto Torvalds :D ), poi ci sono le ISR che vanno gestite nel minor tempo possibile, poi ci sono gli algoritmi per la gestione dell'i/o che possono essere più o meno performanti
tutte queste cose insieme ad un player come vlc che certamente è il top producono quel risultato
ma il merito non va solo a vlc, senza contare che vlc non usa una sua libreria di threading su haiku ma usa i thread nativi di haiku
per esempio su linux fino all'avvento di pthreads eravamo costretti o ad usare processi multipli ( molto dispendioso ) o inserire un gestore di thread nell'applicazione stessa ( ma ovviamente non è la stessa cosa perchè il sistema operativo non sa che ci sono dei thread e quindi ha meno informazioni da usare per scegliere come schedulare i processi/thread )
AnonimoVeneziano
14-09-2009, 18:50
certo l'applicazione sfrutta il multithreading, ma se non ha il supporto del sistema operativo può fare poco o nulla
per esempio io ho aperto 7 istanze di vlc ( quindi 7 processi )
ognuno di questi processi è in grado di istanziare vari thread, ma lo scheduling dei processi viene fatto dal sistema operativo non da vlc
infatti lo stesso vlc su linux si comporta molto peggio
il punto è che haiku è in grado di ridurre i tempi di praticamente tutte le operazioni di sistema....lo scheduling è il primo ( motivo per cui Colivas ha maledetto Torvalds :D ), poi ci sono le ISR che vanno gestite nel minor tempo possibile, poi ci sono gli algoritmi per la gestione dell'i/o che possono essere più o meno performanti
tutte queste cose insieme ad un player come vlc che certamente è il top producono quel risultato
ma il merito non va solo a vlc, senza contare che vlc non usa una sua libreria di threading su haiku ma usa i thread nativi di haiku
per esempio su linux fino all'avvento di pthreads eravamo costretti o ad usare processi multipli ( molto dispendioso ) o inserire un gestore di thread nell'applicazione stessa ( ma ovviamente non è la stessa cosa perchè il sistema operativo non sa che ci sono dei thread e quindi ha meno informazioni da usare per scegliere come schedulare i processi/thread )
E su linux che usi? KDE o Gnome?
e cosa ti ha detto? :D
non mi han detto niente :)
pabloski
14-09-2009, 19:21
E su linux che usi? KDE o Gnome?
gnome, ma non fa differenza perchè la riproduzione viene fatta da xvideo in combutta con i driver della scheda grafica
se proprio ci sono dubbi si può provare con pekwm o fluxbox, ma il risultato non cambierà
AnonimoVeneziano
14-09-2009, 19:37
gnome, ma non fa differenza perchè la riproduzione viene fatta da xvideo in combutta con i driver della scheda grafica
se proprio ci sono dubbi si può provare con pekwm o fluxbox, ma il risultato non cambierà
Invece potrebbe, perchè Haiku è un sistema ridotto all'osso allo stato attuale. Non ha molti dei servizi che un sistema operativo moderno come linux ha attivi di default e che permettono di avere le funzionalità di un desktop moderno, come FAM, HAL, servizi di comunicazione interprocesso varie ... etc .
Ma usare fluxbox non basta, facendo la prova assicurati anche di disabilitare i suddetti servizi che possono partire all'avvio e in caso disabilita anche il VDPAU (o come si chiama) che potrebbe anche essere la causa del problema
Ciao
pabloski
14-09-2009, 19:55
i servizi assurdi li ho già disabilitati ( figurati se faccio girare portmap su un desktop :D )
il vdpau è interno al driver nvidia e non so se sia disabilitabile tramite un'opzione passata via xorg.conf
in ogni caso il vdpau permette di decodificare i video tramite gpu, quindi a rigor di logica velocizza la riproduzione non la rallenta
ho provato con i driver vesa però e nemmeno lo spostamento delle finestre sul monitor è fluido, i video sono un disastro :D
per quanto riguarda gnome ho avviato una sessione X senza DE e comunque si guadagna pochissimo, ma il risultato finale non cambia
ovviamente Xorg è fortemente responsabile del problema performance, tant'è che tutti lo vogliono alla forca da almeno 10 anni
...Mi pare lapalissiano cmq che in fatto di threading e multitasking Haiku sia decisamente meglio del (datato?) kernel Linux. Senza neanche bisogno di fare questi bench sui video che coinvolgono cmq molti elementi diversi fra OS... E senza contare che Haiku, come il BeOS sono concepiti in partenza con una spiccata propensione per i flussi multimediali a livello di design del kernel.
pabloski
14-09-2009, 21:20
il mio test era mirato a vedere cosa cambiava installandolo sull'hard disk
infatti trapanator aveva provato la stessa cosa ma da pendrive ( e lì son dolori ) e i risultati non erano stati entusiasmanti
devo anche dire di avere 2 GB di ram, ma durante la riproduzione ne usava 180
sono d'accordo che un test simile coinvolge molti elementi ma forse proprio questa è la parte interessante
è mai possibile che un OS in alpha ( quindi non ottimizzato ) superi OS stra-ottimizzati e testati come linux e windows?
il problema di linux sono i troppi wrapper, layer, deviazioni e compagnia....è mai possibile che dobbiamo avere dri solo perchè mesa e xrender fanno a pugni?
quella è roba che consuma cicli cpu ed è perfettamente evitabile
gallium purtroppo non migliorerà la situazione ma aggiungerà un ulteriore livello di astrazione e redirezione dei flussi dati
e ieri sera è arrivata una bella doccia fredda da uno sviluppatore amd che mi ha detto che avrebbero comunque usato il codice di xorg rattoppandolo per farlo girare come state tracker di gallium
del resto windows non fa meglio visto che si porta dietro librerie e funzioni del millennio scorso
se poi guardiamo macos c'è solo da piangere :cry:
AnonimoVeneziano
14-09-2009, 21:29
A rega, si chiama evoluzione.
Se si vuole andare avanti bisogna aggiungere cose , espandere funzionalità , creare quei "layers" di cui parlate, perchè semplicemente non è possibile prendere quello che c'è già e cancellarlo e ripartire da 0.
Windows necessita della compatibilità con le applicazioni vecchie Win16 come Linux necessità della compatibilità con Xorg come OSX con Carbon o PowerPC con Rosetta ... etc.
Eventualmente se mai Haiku avrà un successo non vi preoccupate che sarà destinato anche lui a diventare così o rimarrà per sempre una alpha o una demo .
E poi linux datato? L'ultima release è datata 9 settembre 2009 ed è in continuo sviluppo, non lo chiamerei proprio datato ...
trapanator
14-09-2009, 21:46
infatti trapanator aveva provato la stessa cosa ma da pendrive ( e lì son dolori ) e i risultati non erano stati entusiasmanti
Però devo farti notare una cosa.
Il video occupava solamente 2MB scarsi e sicuramente erano già interamente "cachati" da Haiku (avevo appena decompresso il filmato e poi eseguito subito i 4 MoviePlayer). Ho 1 GB di RAM.
del resto windows non fa meglio visto che si porta dietro librerie e funzioni del millennio scorso
Da Vista non si porta più un saccoddi cose; per questo ci sono alcune incompatibilità con software datato.
se poi guardiamo macos c'è solo da piangere :cry:
Tipo? Fammi qualche esempio.
p.s. ti ricordo che uno dei sviluppatori oggi su IRC ha detto che la R2 sarà interamente compilata con GCC4, ciò significa addio ai binari/driver compilati con BeOS se non si dispone dei sorgenti.
pabloski
14-09-2009, 21:51
beh però l'evoluzione la si può fare anche evitando di sacrificare aspetti importanti
e linux è maestro nel rompere la retrocompatibilità proprio per difendere le performance
poi ci sono ovviamente scelte algoritmiche dietro le performance di haiku, a partire da com'è strutturato il filesystem, come sono gestite le isr, fino al meccanismo di chiamata al kernel e alla complessità computazionale dello scheduler
per esempio Kon Colivas che non è certo il primo arrivato sta bestemmiando da 2 anni riguardo la scelta del CFS come scheduler per la versione client di linux....CFS non è male però si può fare di meglio
poi è vero che c'è la retrocompatibilità, ma in tutti i settori prima o poi bisogna tagliare e andare avanti, altrimenti rischiamo di avere le automobili con le balestre in aggiunta agli ammortizzatori :D
linux cambiò di punto in bianco l'intero stack wifi creando non pochi problemi, non penso non possano abbandonare quella creatura storpia chiamata Xorg ( senza contare che il grosso delle applicazioni lo uso attraverso qt e gtk, quindi basterebbe modificare questi ultimi due )
però complessivamente gallium permetterà di far convivere varie api e può benissimo darsi che l'api xorg verrà man mano abbandonata in favore di wayland ad esempio
pabloski
14-09-2009, 22:00
Da Vista non si porta più un saccoddi cose; per questo ci sono alcune incompatibilità con software datato.
cavolo e con tutto ciò sono riuscito a creare l'os più pesante della storia :D
Tipo? Fammi qualche esempio.
beh un assurdo che ho trovato è avere carbon e cocoa, che poi s'intrecciano ad un livello più basso con quartz, con quartz3d che è parallelo a quartz e per questo hanno adottato una soluzione a la dri di linux
se parliamo del kernel mi son messo le mani nei capelli guardando che sono 3 sistemi operativi in 1 ( freebsd col suo userland, mach che gestisce il "bare metal" e bsd 4.3 che fornisce le policy di gestione del sistema, il tutto collegato al resto del sistema tramite driver kit
già di per sè l'uso di mach è opinabile, però bisogna capire che all'epoca non c'era di meglio, anche se quando next entrò in apple c'era beos appunto
poi si prende un microkernel, lo si ingabbia e lo si va diventare monolitico tramite mille api e librerie di sistema per comunicare con l'userland
ricordo la prima volta che presi in mano Xcode e guardai nella documentazione la struttura dell'api di macos mi venne un colpo :D
p.s. ti ricordo che uno dei sviluppatori oggi su IRC ha detto che la R2 sarà interamente compilata con GCC4, ciò significa addio ai binari/driver compilati con BeOS se non si dispone dei sorgenti.
non è una cattiva idea, se consideri che la r2 non arriverà domani e che loro sperano di usare l'alpha1 della r1 per indurre molta gente a portare il software
del resto non si può usare gcc2 perdendo tutti i vantaggi di gcc4
per i driver non è che ce ne siano moltissimi per beos, quindi non è un problema, considerando poi che sono per hardware che ormai sta in qualche megadiscarica
non è credibile l'ipotesi di recuperare i vecchi software e driver beos
da poco Colin ha dato il via ai test sul wireless, per chi fosse interessato a provare :):) leggetevi questo wiki:
http://dev.osdrawer.net/wiki/haiku-wifi/How_to_become_a_tester
trapanator
15-09-2009, 10:52
volete la barra laterale di VISTA su Haiku?
http://leaf.eu.pn/index.php?option=com_content&view=article&id=15&Itemid=21
:stordita:
E poi linux datato? L'ultima release è datata 9 settembre 2009 ed è in continuo sviluppo, non lo chiamerei proprio datato ...
Non è questione di data di release ma di design del kernel che non è proprio nato ieri...
anche se quando next entrò in apple c'era beos appunto
Già... Jobs con una mossa molto mafiosa ;) convinse Apple a riprenderlo pagandogli a caro prezzo Next invece della proposta di Gassée con l'innovativo e fantastico BeOS...
AnonimoVeneziano
15-09-2009, 11:46
Non è questione di data di release ma di design del kernel che non è proprio nato ieri...
Il design del kernel viene modificato ogni giorno . Infatti lo scheduler su linux è stato cambiato dal vecchio O(1) all'attuale CFS e poi tante altre modifiche sono state fatte al design e potranno essere fatte in futuro, l'importante è che l'interfaccia verso le applicazioni sia sempre la stessa, poi per il resto all'interno possono anche cambiare tutto.
Da Vista non si porta più un saccoddi cose; per questo ci sono alcune incompatibilità con software datato.
Infatti... con la nascita del progetto MinWin che si prefigge proprio lo scopo di snellire finalmente il vecchio kernel NT riscrivendone completamente molte parti tra cui scheduler e gestione della memoria la situazione anche su Windows è nettamente migliorata, da Vista in poi...
A onor del vero, Vista e Win7 hanno una gestione dei processi nettamente migliore, non ci sono più grossi stalli e "crawling" del sistema sotto sforzo intenso della CPU come poteva avvenire in XP: http://www.youtube.com/watch?v=eK2Suw7yVek
Nessuno l'ha mai pensato possibile ma anche Windows, finalmente, dall'NT6.x in poi sta migliorando molto tecnicamente (sia lode al giorno in cui MS acquisì società esterne con gente con i OO tipo Russinovich di Sysinternals)...
BTW, 7 video su Vista Home Premium SP2 x86 senza il minimo rallentamento e diminuzione delle prestazioni e CPU intorno al 50% (con accelerazione video però...e con antiviurs ;)) su Core Duo T5800 2GHz, 4GB RAM, GeForce9600M GT (512MB dedicati)
http://h.imagehost.org/t/0272/7_videos_Vista.jpg (http://h.imagehost.org/view/0272/7_videos_Vista)
A volte anche il diavolo ci mette i coperchi... ;)
Il design del kernel viene modificato ogni giorno . Infatti lo scheduler su linux è stato cambiato dal vecchio O(1) all'attuale CFS e poi tante altre modifiche sono state fatte al design e potranno essere fatte in futuro, l'importante è che l'interfaccia verso le applicazioni sia sempre la stessa, poi per il resto all'interno possono anche cambiare tutto.
Come avviene per tutti gli OS in realtà... peccato che molte cose siano state aggiunte solo negli anni recenti (vedi più su discorso sui thread). Cambiare e aggiungere qualcosa qua e là non lo rendono un kernel "nuovo" ai miei occhi. Di certo non come quello di Haiku ad esempio, pregettato in tempi ben più moderni... Sennò sarebbero tutti "nuovi".
AnonimoVeneziano
15-09-2009, 13:37
Come avviene per tutti gli OS in realtà... peccato che molte cose siano state aggiunte solo negli anni recenti (vedi più su discorso sui thread). Cambiare e aggiungere qualcosa qua e là non lo rendono un kernel "nuovo" ai miei occhi. Di certo non come quello di Haiku ad esempio, pregettato in tempi ben più moderni... Sennò sarebbero tutti "nuovi".
Ma perchè questo astio verso il miglioramento di cose già esistenti? E' solo una cosa psicologica, una cosa che parte da zero non è necessariamente migliore di un qualcosa che invece è stato migliorato nel tempo ,altrimenti nel 2009 non staremmo ancora usando Unix
pabloski
15-09-2009, 15:00
no per carità nessun odio verso il cambiamento, tant'è che il kernel di linux le suona a parecchi altri kernel
il problema è quando si cerca di aggiungere il nuovo sul vecchio, cosa in cui xorg è maestro, che nascono i problemi
poi c'è l'architettura che può essere adatta o no a determinati usi....haiku utilizza un meccanismo zero copy per la gestione dei flussi multimediali, facendo ampio uso di memoria condivisa
xorg copia di tutto e di più avanti e indietro per la ram
il problema è che cambiare questo stato di cose significa cambiare l'architettura di X, che a turno significa rompere la retrocompatibilità
quindi o si fa come quelli del team di kde che hanno rotto tutte le uova e ricominciato da zero oppure decidi di mantenere il vecchio trasformando però il tuo software in un bradipo
trapanator
15-09-2009, 19:29
http://punto-informatico.it/2708851/PI/News/spirito-beos-rivive-haiku.aspx
ora manca solo quello su Hwupgrade :D
pabloski
15-09-2009, 20:49
e vedo che come al solito su pi hanno subito trasformato l'articolo in una guerra windows contro linux :D
che c'entrerà poi linux in quell'articolo, boh !
trapanator
15-09-2009, 20:56
e vedo che come al solito su pi hanno subito trasformato l'articolo in una guerra windows contro linux :D
che c'entrerà poi linux in quell'articolo, boh !
parli dei commenti? quelli mica li ho letti.
pabloski
15-09-2009, 21:21
parli dei commenti? quelli mica li ho letti.
e fai bene sono allucinanti :D
c'è il tizio che dice che haiku è veloce perchè è in alpha e che tecnologicamente è come windows nt4 :D :D
NT4 :D :D :D
Ora scarico la ISO... alla facciazza sua :D
Certo che la redazione di hwupgrade potrebbe scrivere qualcosina a riguardo :(
pabloski
17-09-2009, 11:57
sono troppo impegnati a creare articoloni pubblicitari pro-microsoft :D
Più che altro sono troppo impegnati a fare focus news e articoli su qualunque cosa abbia una mela morsicata :D
E se ai tempi a Cuppertino avessero scelto BeOS invece di Darwin? Non oso immaginare che progressi avrebbe fatto BeOS con un colosso economico come Apple alle spalle...
Come è ora è poco più di un esercizio di stile e non è una valida alternativa per computer che devono produrre.
Il fatto è che ha delle potenzialità IMPRESSIONANTI e forse è l'unico OS che si possa ritenere MODERNO.
Dietro basterebbe una società della potenza economica della Canonical per fare in modo che si possa muovere qualcosa.
Io lo vedrei benissimo come OS in WorkStation grafiche e/o audio.
Un saluto a tutti...
masand
Invece, bastano solo tanti sviluppatori in più :).
Questa alpha è stata rilasciata con l'intento di raccogliere gente, sperando che tanti sviluppatori linuxari siano attratti :)
Al momento è impensabile che una società grossa li finanzi, purtroppo
walter sampei
17-09-2009, 14:13
IMHO e' lo stesso problema di reactos (e, dato che ros e haiku sono in ottimi rapporti, l'uno potrebbe aiutare l'altro e viceversa)
PatchWorKs
17-09-2009, 19:24
Dietro basterebbe una società della potenza economica della Canonical per fare in modo che si possa muovere qualcosa.
Io qualche anno fà scrissi ad AMD (e non solo, in verità) esortandoli ad investire nell'open source (ed in particolare in Haiku, ReactOS, etc), che sicuramente avrebbe portato loro più clienti rispetto alla sponsorizzazione della Ferrari... :nono:
...comunque credo che Google guardi con un certo interesse al progetto: non sò se conoscete questo video (http://video.google.it/videoplay?docid=236331448076587879). :eek:
Google "sponsorizza" direttamente Haiku nel Summer of Code, ma approfondendo l'argomento si scopre che Haiku è uno dei 500 progetti su cui BigG ha messo gli occhi e le mani cacciando qualche spicciolo... :rolleyes:
trapanator
17-09-2009, 21:33
Google "sponsorizza" direttamente Haiku nel Summer of Code, ma approfondendo l'argomento si scopre che Haiku è uno dei 500 progetti su cui BigG ha messo gli occhi e le mani cacciando qualche spicciolo... :rolleyes:
scusa cosa c'entra... finanzia lo studente mica il progetto :)
Beh, non è che li finanzia per girarsi i pollici ma per portare a termine un progetto inerente a qualcosa, e in tra quei 500 qualcosi ci sono anche elementi di Haiku :p. Direi che si applica la proprietà transitiva del finanziamento :D
pabloski
17-09-2009, 21:43
google ha sempre avuto questa politica anche internamente
finanzia i progetti che possono avere qualche sbocco di suo interesse e sicuramente haiku è in buona posizione
non è incredibile pensare che in un prossimo futuro possano esserci android, chrome e haiku tra le offerte di google
Vien da chiedersi perchè Haiku sia sotto licenza MIT-BSD... La licenza GPL non potrebbe tutelare meglio il codice dell'os (di cui parti sono state usate tempo addietro da SkyOS) ?
O mio dio :) ... la redazione ha scritto un articolo ... grandi :)
Per la licenza credo abbiano scielto la MIIT per non chiudersi nessuna porta futura
Per la licenza credo abbiano scielto la MIIT per non chiudersi nessuna porta futura
Se cresce bene come Os molte sue parti possono essere facilmente trafugate...
Xemertix
19-09-2009, 03:36
Ho provato ad installare haiku alpha in una partizione preparata da gparted (ho provato sia con una vuota,che formattata in fat32,ext2 etc),ma mi dà initialization failed :general system error quando tento di inizializzarla col filesystem bfs,sia da installer grafico che da riga di comando (mkfs)
Il sistema (vado a memoria) è un pentium3 450mhz,128mb di ram,matrox g200,hd samsung da 8gb,mb asus con chipset intel..nel bios ho disattivato pure le opzioni pnp os e l'ultra dma ma niente..
Non si può creare un fs bfs da una livecd linux? gparted non lo supporta,ma so che esiste questo vecchio driver http://befs-driver.sourceforge.net/about.php Ho provato pure con cfdisk,che pare supportare il befs,ma niente.
Zeta invece non si avvia proprio con quella configurazione.
trapanator
19-09-2009, 08:31
Non si può creare un fs bfs da una livecd linux? gparted non lo supporta,ma so che esiste questo vecchio driver http://befs-driver.sourceforge.net/about.php Ho provato pure con cfdisk,che pare supportare il befs,ma niente.
Zeta invece non si avvia proprio con quella configurazione.
Dal tuo sito:
In August of 2001, I started rewriting the BeFS driver for the 2.4 linux kernel. I got it working well enough to release in October of that year. The development was moved to Sourceforge in November.
L'ultima versione è del 2002. Se clicco su Mailing Lists da errore di pagina non trovata.
Non credo sia più mantenuto, ormai...
pabloski
19-09-2009, 09:29
puoi però provare dalla live di haiku con drivesetup
puoi però provare dalla live di haiku con drivesetup
é con drivesetup che gli esce quell'errore, ho visto fare la stessa cosa cercando di installarlo su qemu. Prova ad avviare la live disabilitando il dma.
Al momento del boot, prima che escano fuori le sette icone, premi barra spaziatrice.
Nella schermata che ti esce, vai alla seconda voce (Select safe mode options) eppoi selezione disable ide dma, o prova disabilitando altre voci tipo sul acpi.
Ciao
Xemertix
19-09-2009, 22:59
Bene,installato con successo e faccio il boot col livecd,riesce a connettersi anche ad internet,non riconosce la vecchia scheda audio pci maestro,ma ho installato oss e vedrò di fare qualche prova..
L'avvio è molto rapido,ma i 128mb di ram sono appena sufficienti,anche perché firefox2 ne richiede molta (ci vorebbe dillo2).
L'assenza di un pulsante 'minimizza tutto' è fastidiosa,nel tracker mi sembra si possa minimizzare solo un'applicazione alla volta.
Ho 'installato' (copiato una cartella) per ora vlc e un package manager preso da haikuware,in seguito proverò ad installare anche i driver matrox per beos.A mio parere,uno dei primi programmi 'core' che potrebbero portare è wine (un tempo bewine),che già da solo permette di avere accesso allo sterminato parco software di windows,per proseguire con firefox3,vlc1,mplayer,openoffice,amarok,amule,amsn,k3b etc piuttosto che riscrivere programmi da zero.
Sto provandolo in live su un centrino 1.6Ghz e 1Gb di ram dal quale sto scrivendo. Visto così è ne più ne meno come beosR5 di qualche anno fa. Cmq ha riconosciuto audio, video e rete ovviamente solo cablata senza problemi.
Allo stato attuale quindi sembra che non sia stato fatto niente di che rispetto ad anni fa ma a quanto sembra è solo apparenza visto che sotto è praticamente tutto nuovo...vedremo nei prox mesi... :cool:
io non direi praticamente :) ... è stato riscritto da zero :)
Bene,installato con successo e faccio il boot col livecd,riesce a connettersi anche ad internet,non riconosce la vecchia scheda audio pci maestro,ma ho installato oss e vedrò di fare qualche prova..
L'avvio è molto rapido,ma i 128mb di ram sono appena sufficienti,anche perché firefox2 ne richiede molta (ci vorebbe dillo2).
Beh diciamo che Firefox è un corpo estraneo... poi è anche la versione 2, la 3 è già di per se leggermente più leggera!
Comunque stanno lavorando a un browser nativo basato su WebKit :D
L'assenza di un pulsante 'minimizza tutto' è fastidiosa,nel tracker mi sembra si possa minimizzare solo un'applicazione alla volta.
In effetti quello mi sa che manca...
A mio parere,uno dei primi programmi 'core' che potrebbero portare è wine (un tempo bewine),che già da solo permette di avere accesso allo sterminato parco software di windows,per proseguire con firefox3,vlc1,mplayer,openoffice,amarok,amule,amsn,k3b etc piuttosto che riscrivere programmi da zero.
Da un lato hai ragione, ma allo stesso tempo hai torto :D
Vedi le applicazioni portate (o peggio emulate da wine!) non mostrano appieno le potenzialità di Haiku... potrebbero non essere Multithread o necissitare di cose che in Haiku sono bestemmie (k3b vorrà almeno KDE... e forse anche X :eek:)...
Comuque Firefox e VLC son rimasti indietro a causa di GCC2 ora che c'è il sistema ibrido (e quindi si può cmpilare anche per GCC4) auspico che si modernizzino :D
Io preferirei usare il player nativo (Mediaplayer) che usa MediaKIT piuttosto che VLC (che poi ha dentro di sè un doppione dello stesso MediaKIT... ovvero FFMPEG :p )...
OpenOffice invece è necessario (riscrivere un coso del genere da capo non è banale) però richiede JAVA... e per ora Haiku non ce l'ha (ma ci stanno lavorando)...
Insomma ci vorrà tempo :D
Comunque la buona notizia da parte mia è che son riuscito ad aver il log della scheda video, finalmente!!!
Spero che presto la mia 6150 sia supportata...
Testato anche su EEEBOX al lavoro e qui andava molto bene la scheda video è supportata nativamente senza problemi!
Credo HAIKU sarebbe proprio il sistema ideale per quei giocattolini solo 100 MB di RAM occupati in IDLE... cache compresa....
Delusione invece per il portatile ACER... la GPU è supportata, ma non vanno né tastiera né il "mouse"... posso capire per il "mouse" (anche WhiteBox 4 non lo gradiva...), ma almeno la tastiera dovrebbe andare :confused:
Mah....finalmente una versione che almeno si avvia su un normalissimo intel core 2 duo E6420. Però, porco demonio, niente audio ne rete (cablata); e sì che un hda-intel e una intel e1000 non mi paiono hardware esoterici...:(
Siam lontani, imho, da un sistema utilizzabile come desktop per un utilizzzo di tutti i giorni....:muro:
Mi sa di sì!
Oltre ai driver anche Mediaplayer ha molti problemi... gli mkv di fatto non li legge e si emoziona con un semplice audio AC3 (non fa il passtrhought... di conseguenza non si ode una mazza :p )
Visto che per me la parte multimediale è la più importante (più che il desktop in quanto tale) è ancora più grave... io sogno di avere un Mediacenter basato su Haiku un giorno :p
Sul mio PC a parte la GPU va tutto (audio, rete...) sull'EEBOX non ho potuto provare la parte audio (non avevo cuffie e soprattutto file da fargli leggere!), ma il resto era OK, mentre sul portatile ACER c'erano grossi problemi né la tastiera né il touchpad funzionavano :muro:
trapanator
22-09-2009, 09:48
Mi sa di sì!
Oltre ai driver anche Mediaplayer ha molti problemi... gli mkv di fatto non li legge e si emoziona con un semplice audio AC3 (non fa il passtrhought... di conseguenza non si ode una mazza :p )
Visto che per me la parte multimediale è la più importante (più che il desktop in quanto tale) è ancora più grave... io sogno di avere un Mediacenter basato su Haiku un giorno :p
Sul mio PC a parte la GPU va tutto (audio, rete...) sull'EEBOX non ho potuto provare la parte audio (non avevo cuffie e soprattutto file da fargli leggere!), ma il resto era OK, mentre sul portatile ACER c'erano grossi problemi né la tastiera né il touchpad funzionavano :muro:
Secondo me va data la possibilità di un minimo di "smanettamento" da parte dell'utente per far andare hardware particolare. Non si può predentere di aver un S.O. che funzioni al primo colpo con tutto l'hardware esistente.
trapanator
22-09-2009, 09:54
sarebbe bello avere GAMBAS anche su Haiku... ci sarebbe un'esplosione di applicazioni :eek:
sarebbe bello avere GAMBAS anche su Haiku... ci sarebbe un'esplosione di applicazioni :eek:
Beh ci sarebbe YAB :), solo che mi sembra fermo come progetto, anche se cmq si può utilizzare per creare qualche programma :)
trapanator
22-09-2009, 12:04
Beh ci sarebbe YAB :), solo che mi sembra fermo come progetto, anche se cmq si può utilizzare per creare qualche programma :)
progetto morto da 2 anni:
http://sourceforge.net/projects/yab-interpreter/
anche se credo ci sarà una ripresa a breve
Fermo è fermo :), però da quel che ho letto dovrebbe essere completo, ci hanno fatto diversi programmini.
Per zeta hanno fatto un programma di masterizzazione jaber (o una cosa del genere) utilizzando yab.
Per provarlo penso sia meglio scaricarsi le varie immagini di Senryu, (haiku pieno di programmi) da haikuware.com
http://www.haikuware.com/directory/view-details/development/app-installation/senryu-personal-edition-vmware-image-monthly (http://www.haikuware.com/directory/view-details/development/app-installation/senryu-personal-edition-vmware-image-monthly)
Allora il lavoro sui driver NVIDIA prosegue... praticamente il povero Rudolf lavora per me :D
Con l'ultimo driver finalmente ho visto qualcosa con il suo driver... con la DVI funziona... e devo dire che almeno visivamente la qualità migliora...
Speriamo ora riesca a farmi andare la VGA... la DVI la usa il TV LCD (via convertitore HDMI :D ) così il primo (piccolo blocco) verso l'HTPC lo abbiamo messo :D
La prossima mossa è vedere se riesce a vedere il TV fino a 1920*1080p e, soprattutto, avere 2 desktop totalmente separati (cosa per il momento, mi sa, non supportata a livello di OS)!
Poi probabilmente cambierò scheda video (ATI 5x00) e si ricomincerà da capo :p
trapanator
26-09-2009, 18:54
Poi probabilmente cambierò scheda video (ATI 5x00) e si ricomincerà da capo :p
Delle ATI 5x00 non sono ancora uscite le specifiche libere.
Beh dopotutto sono uscite da pochissimi giorni... anche se se assomigliano abbastanza alle 4000 (e quelle saranno supportate? Boh...) potrebbero magari funzionare lo stesso con gli stessi driver.
Credo la parte audio saranno dolori in quel caso... convincere Haiku che la GPU è anche una scheda audio non sarà banale :D
E' normale che appena installato su macchina virtuale non riesca a leggere degli mp3?
Novità su un LiveCD Haiku? È da un po' che non bazzico nel thread...
pabloski
06-10-2009, 10:50
E' normale che appena installato su macchina virtuale non riesca a leggere degli mp3?
si non ha un lettore di mp3
però si risolve facilmente installando videolan
trapanator
06-10-2009, 11:16
Novità su un LiveCD Haiku? È da un po' che non bazzico nel thread...
c'è già quello dell'alpha1, che puoi scaricare dalla home di Haiku.
non condivido la scelta degli sviluppatori di non rilasciare più le immagini RAW/VMWARE dell'ultima snapshot... hanno sviluppato moltissimo codice dall'alpha 1 e corretto tanti bug.
si non ha un lettore di mp3
però si risolve facilmente installando videolan
Ok grazie ora provo
c'è già quello dell'alpha1, che puoi scaricare dalla home di Haiku.
non condivido la scelta degli sviluppatori di non rilasciare più le immagini RAW/VMWARE dell'ultima snapshot... hanno sviluppato moltissimo codice dall'alpha 1 e corretto tanti bug.
Meglio di niente: il link alla roadmap per avere un idea dello stato di Haiku
http://dev.haiku-os.org/roadmap
c'è già quello dell'alpha1, che puoi scaricare dalla home di Haiku.
Ma è utilizzabile come LiveCD (anche se con modeste prestazioni) o è solo "da installazione"?
trapanator
06-10-2009, 13:19
Ma è utilizzabile come LiveCD (anche se con modeste prestazioni) o è solo "da installazione"?
sia Live CD che install CD
sia Live CD che install CD
Ah! Sapevo di essermi perso qualcosa... :)
pabloski
06-10-2009, 18:09
le prestazioni però ti convinceranno che è meglio installarlo :D
le prestazioni però ti convinceranno che è meglio installarlo :D
Sai com'è, anche solo per farlo vedere in giro...
Non che su qEmu le prestazioni siano ottime, eh... Però rimane usabile, stessa cosa sotto VirtualBox
Le compilazioni notturne :):), ci sono ancora ... http://haiku-files.org/.
Sto scaricando quella di ieri :)
trapanator
07-10-2009, 13:12
Le compilazioni notturne :):), ci sono ancora ... http://haiku-files.org/.
Sto scaricando quella di ieri :)
aha buono a sapersi :D grazie!
E' normale che appena installato su macchina virtuale non riesca a leggere degli mp3?
Cerca meglio Mediaplayer legge anche gli MP3, non serve VLC :D
Legge pure DIVX e MKV se è per quello... anche se sugli MKV la compatibilità non è ancora altissima :D
trapanator
15-10-2009, 16:03
http://www.haiku-os.it/?q=node/636
Ottimo questo dovrebbe facilitare il porting di molte applicazioni dal mondo Linux... e sta volta sembra sia stato fatto nel modo giusto :D
Senza portarsi dietro X :p
Buono per allargare la base di software ma a me personalmente questo trend Linux-everywhere non piace molto... Haiku deve sfruttare al meglio LE SUE superiori potenzialità, non diventare un OS con software back-ported da Linux. A che scopo sennò uno userebbe Haiku e non Linux? Il sistema poi rischia di non decollare...
Buono per allargare la base di software ma a me personalmente questo trend Linux-everywhere non piace molto... Haiku deve sfruttare al meglio LE SUE superiori potenzialità, non diventare un OS con software back-ported da Linux. A che scopo sennò uno userebbe Haiku e non Linux? Il sistema poi rischia di non decollare...
Beh Gnu non è linux....
qt4 non è linux...
Ricreare tutte le applicazioni ex novo sarebbe uno sforzo enorme...se fosse possibile trasportare alcune applicazioni linux (ma non solo) su haiku con il minimo sforzo potrebbe essere una buona spinta in avanti...
Beh Gnu non è linux....
qt4 non è linux...
E infatti non l'ho mai detto...
Ricreare tutte le applicazioni ex novo sarebbe uno sforzo enorme...se fosse possibile trasportare alcune applicazioni linux (ma non solo) su haiku con il minimo sforzo potrebbe essere una buona spinta in avanti...
Come ho detto IMHO c'è il rischio che in questo modo le applicazioni diventino solo un clone di quelle già disponibili, e forse più aggiornate, per Linux. Ciò rischia di non attirare mai sviluppatori e semplici utenti su Haiku che preferiranno continuare a usare Linux. L'ho già visto succedere su altri OS che hanno iniziato a fare porting pesante di tutto quello che c'era per Linux ed è stato un lento suicidio. Il rovescio della medaglia insomma...
My 7 days using Haiku
http://www.osnews.com/story/22354/My_7_Days_Using_Haiku_Alpha_Release_1
Buono per allargare la base di software ma a me personalmente questo trend Linux-everywhere non piace molto... Haiku deve sfruttare al meglio LE SUE superiori potenzialità, non diventare un OS con software back-ported da Linux. A che scopo sennò uno userebbe Haiku e non Linux? Il sistema poi rischia di non decollare...
La penso anch'io così... anche se, se Haiku, sarà quello che spero ci sarebbero comunque vantaggi ad usare su Haiku applicazioni portate da GNU/Linux... per esempio spero il modo di installare le applicazioni sarà più semplice (il "dependency hell" va evitato! E' il male...) e le applicazioni anche se non native potrebbero essere comunque più veloci... essendo Haiku indubbiamente più efficiente di Linux...
Per dirvi sto seguendo per motivi lavorativi il progetto Moblin ebbene con X e tutto il tempo di boot è ridotto al valore record di 25 secondo (e per Linux son pochi, molto pochi) ebbene ho cronometrato l'ultima build di Haiku... 12 secondi :D
Ahh Moblin era installato nativamente e su HW compatibile (EEEPC)... Haiku era su VMWARE... con il PC che aveva Firefox (con 52 tab aperte :p ), Mediaportal, 12 finestre di EXPLODER... insomma uno scontro non proprio corretto... nei confronti di... Haiku eppure VINCE :Prrr: :Prrr: :Prrr:
Poi non mi funzionava la scheda di rete di VMWARE (e le versioni precedenti andavano), ma questo è un altro discorso :ciapet:
Slayer86
24-10-2009, 21:09
La penso anch'io così... anche se, se Haiku, sarà quello che spero ci sarebbero comunque vantaggi ad usare su Haiku applicazioni portate da GNU/Linux... per esempio spero il modo di installare le applicazioni sarà più semplice (il "dependency hell" va evitato! E' il male...) e le applicazioni anche se non native potrebbero essere comunque più veloci... essendo Haiku indubbiamente più efficiente di Linux...
Per dirvi sto seguendo per motivi lavorativi il progetto Moblin ebbene con X e tutto il tempo di boot è ridotto al valore record di 25 secondo (e per Linux son pochi, molto pochi) ebbene ho cronometrato l'ultima build di Haiku... 12 secondi :D
Ahh Moblin era installato nativamente e su HW compatibile (EEEPC)... Haiku era su VMWARE... con il PC che aveva Firefox (con 52 tab aperte :p ), Mediaportal, 12 finestre di EXPLODER... insomma uno scontro non proprio corretto... nei confronti di... Haiku eppure VINCE :Prrr: :Prrr: :Prrr:
Poi non mi funzionava la scheda di rete di VMWARE (e le versioni precedenti andavano), ma questo è un altro discorso :ciapet:
si ma come fai a pargonare una qualsiasi distribuziona linux con una alpha con praticamente NIENTE incluso...
L'immagine di haiku è 110mb... una qualsiasi distro installata è almeno 1 gb.... questo cosa significa... che haiku ha pochissimi servizi all'avvio... per esempio... ha il gestore bluetooth?? gestione energetica???
ecco allora è inutile dire boota in 10 secondi... anche una qualsiasi distro linux boota in 10 secondi se cavi tutto!!! Il lavoro svolto da intel per mobilin è ottimo in quanto una distro completa fa il boot in 25 secondi...
i vantaggi dell'architettura di haiku li vedi in altre cose!!!
Infatti far bootare Linux in 25 secondi è un miracolo :D
Un lavoro davvero enorme... d'altra parte Linux fa partire anche servizi inutili per un uso desktop (come detto dagli stessi ingegneri Intel) sendmail, cups, la rete (mai provato a far bootare Linux con la rete staccata? Ci sta 15 MINUTI :p )...
La gestione energetica se intendi l'Intel Speedstep o l'equivalente Cool & Quiet di AMD c'è "CPUFrequency" che dovrebbe fare qualcosa del genere (anche se non so se funziona).
Se intendi invece l'ACPI (Standby, Ibernazione...) allora mancano... anche se bootando in 12 secondi per ora non serve!
Secondo gli ingegneri Intel il più possibile dei servizi non dovrebbero essere comunque parte del processo di boot (CUPS, Bluetooth...), ma partire su richiesta... cosa sensata che Haiku deve prendere come esempio... se io non ho stampanti o periferiche Bluetooth perché devo attendere 1-2 secondi durante il boot che parta un servizio che non userò mai?
Quindi il kernel di Haiku sta già facendo partire ciò che serve... il resto su richiesta :p
P.S. Lo scontro non era con una "qualsiasi distribuzione Linux", ma con Moblin... su hardware stra ottimizzato e con MOLTI servizi e programmi già raschiati via... solo senza X vinceva: 5 secondi!
Ma io sono su VMWARE su Hardware nativo sarà ancora meno... e Haiku è alpha con il codice compilato in modalità debug (più lento, quindi!)
Slayer86
24-10-2009, 21:34
Infatti far bootare Linux in 25 secondi è un miracolo :D
Un lavoro davvero enorme... d'altra parte Linux fa partire anche servizi inutili per un uso desktop (come detto dagli stessi ingegneri Intel) sendmail, cups, la rete (mai provato a far bootare Linux con la rete staccata? Ci sta 15 MINUTI :p )...
La gestione energetica se intendi l'Intel Speedstep o l'equivalente Cool & Quiet di AMD c'è "CPUFrequency" che dovrebbe fare qualcosa del genere (anche se non so se funziona).
Se intendi invece l'ACPI (Standby, Ibernazione...) allora mancano... anche se bootando in 12 secondi per ora non serve!
Secondo gli ingegneri Intel il più possibile dei servizi non dovrebbero essere comunque parte del processo di boot (CUPS, Bluetooth...), ma partire su richiesta... cosa sensata che Haiku deve prendere come esempio... se io non ho stampanti o periferiche Bluetooth perché devo attendere 1-2 secondi durante il boot che parta un servizio che non userò mai?
Quindi il kernel di Haiku sta già facendo partire ciò che serve... il resto su richiesta :p
Asp... i servizi non centrano niente con il kernel... sono dei server che partono e rimangono in ascolto... da una qualsiasi distro linux puoi togliere tutti i servizi che vuoi...io sulla mia gentoo per esempio ho tolto cups,buetooth, dhcp (è quello che ti ferma 15 secondi se non c'è il cavo di rete inserito!!!) e poi altri che non ricordo...quando mi servono li avvio io a mano!!! cmq in 90 secondi ho gnome avviato e pronto all'uso... (90 secondi non sono tanti...) non so cosa intendi per boot... ma l'avvio del DE è quello più impegnativo e mi porta via almeno una 50ina di secondi!!!
edit: cmq per esempio l'acpi serve... come fai a far funzionare i tasti fn dei notebook? serve l'alimentazione ecc... quindi dovrà essere implementato anche in haiku...
Haiku da come se ne parla sembra ottimo... ma sinceramente vista la complessità di un sistema moderno penso che almeno altri 5 anni di sviluppo serviranno tutti per ernderlo utilizzabile...
Tra 5 anni cosa avremo per le mani lato linux, osx e windows???
Asp... i servizi non centrano niente con il kernel... sono dei server che partono e rimangono in ascolto... da una qualsiasi distro linux puoi togliere tutti i servizi che vuoi...
Dove ho parlato di Kernel riferendomi ai servizi :confused:
io sulla mia gentoo per esempio ho tolto cups,buetooth, dhcp (è quello che ti ferma 15 secondi se non c'è il cavo di rete inserito!!!) e poi altri che non ricordo...quando mi servono li avvio io a mano!!! cmq in 90 secondi ho gnome avviato e pronto all'uso... (90 secondi non sono tanti...) non so cosa intendi per boot... ma l'avvio del DE è quello più impegnativo e mi porta via almeno una 50ina di secondi!!!
Io il tempo di boot lo misuro così aspetto che il bios faccia le sue cose (non è corretto contare anche lui) e quando vedi o il - lampeggiante o scegli la voce dal bootloader inizio a contare... conto fino a che parte il desktop e il sistema è realmente USABILE (per dire se misurassi il povero XP andrei sui 10 minuti... il Desktop magari appare presto, ma è tutto bloccato mentre partono i SERVIZI, le iconcine nella taskbar, ecc...)
Comunque come dici tu la maggiornanza del tempo è preso da X... infatti stanno tentando di riscriverlo se ne sono accorti che è "rotto" ormai :D
edit: cmq per esempio l'acpi serve... come fai a far funzionare i tasti fn dei notebook? serve l'alimentazione ecc... quindi dovrà essere implementato anche in haiku...
Certo che serve la mia era una battuta... per ora non c'è: verrà in seguito quando il sistema sarà più funzionante!
Haiku da come se ne parla sembra ottimo... ma sinceramente vista la complessità di un sistema moderno penso che almeno altri 5 anni di sviluppo serviranno tutti per ernderlo utilizzabile...
Tra 5 anni cosa avremo per le mani lato linux, osx e windows???
Lo so ci vorrà molto tempo... la speranza è che riescano ad ottenere più aiuto magari da transfughi del mondo Linux... c'è Linus Torwald che si lamenta che Linux "ha il kernel gonfio" magari lo si potrebbe arruolare :ciapet:
Pensare che Linux è 11 anni che è in giro... e spesso è ancora inutilizzabile è inquetante :cry:
Speriamo bene... io Windows non lo voglio usare più, ma Linux non è un buon sostituto... purtroppo :cry:
trapanator
25-10-2009, 08:46
La penso anch'io così... anche se, se Haiku, sarà quello che spero ci sarebbero comunque vantaggi ad usare su Haiku applicazioni portate da GNU/Linux... per esempio spero il modo di installare le applicazioni sarà più semplice (il "dependency hell" va evitato! E' il male...)
Anche sotto Haiku ci sono le dipendenze (le librerie condivise...).
Non è come *BSD che con i suoi ports si porta tutto dietro.
Poi sinceramente non capisco cosa ci trovi di così eccitante portarti N copie di una stessa libreria per ogni applicazione, a parte lo spreco di spazio su disco.
pabloski
25-10-2009, 10:11
Poi sinceramente non capisco cosa ci trovi di così eccitante portarti N copie di una stessa libreria per ogni applicazione, a parte lo spreco di spazio su disco.
i winari potrebbero risponderti meglio
non pensi all'eccitazione di avere un installer da 150 MB per installare un banale programma che masterizza delle iso :D
Per dirvi sto seguendo per motivi lavorativi il progetto Moblin ebbene con X e tutto il tempo di boot è ridotto al valore record di 25 secondo (e per Linux son pochi, molto pochi) ebbene ho cronometrato l'ultima build di Haiku... 12 secondi :D
Ancora con questa inutile storia del boot veloce... Tanto vince comunque AmigaOS/MorphOS con meno di 10 secondi per un sistema COMPLETO: http://www.youtube.com/watch?v=usceTXybNbA e su HW di 10 anni fa (G4 a meno di 1GHz e BUS e Memorie MOLTO lente rispetto alle attuali DDR2-3, quindi immaginiamo quanto farebbe su HW "moderno") :Prrr:
i winari potrebbero risponderti meglio
Beh, il mio Vista Home Premium x86, Sp2, completo di tutto (nessuno dei 147 servizi o niente altro disattivato) boota in meno di 40 secondi (ma uso sempre l'ibernazione o sospensione nell'arco della settimana quindi di solito "booto" in meno di 30...), cmq meglio dei 90 secondi del nostro amico Slayer86 con la sua Gentoo pure ottimizzata (il mio modesto HW è in firma) ;)
non pensi all'eccitazione di avere un installer da 150 MB per installare un banale programma che masterizza delle iso :D
Sì certi programmi sono scandalosi per Win e cmq occupano sempre troppo, ma fortunatamente esistono anche IMGBurn (http://www.imgburn.com/) & soci che con 2MB di installar fanno tutto quello che serve... ;) Diciamo che nel mondo Win bisogna sapersi muovere (cosa che l'utente medio punta e clicca non sa fare).
Anche sotto Haiku ci sono le dipendenze (le librerie condivise...).
Non è come *BSD che con i suoi ports si porta tutto dietro.
Poi sinceramente non capisco cosa ci trovi di così eccitante portarti N copie di una stessa libreria per ogni applicazione, a parte lo spreco di spazio su disco.
Pensa al divertimento quando usi yum (che dovrebbe calcolare le dipendenze) e dichiara dopo 10-20 minuti che frulla di non esserci riuscito :muro: :muro: :muro:
O quando il programma installa libsarcazzo 1.25 in /lib e rompe tutte le altre applicazioni installate nel sistema che usano la 1.24 :D
Per me il sistema delle dipendenze è MALE! Almeno per come è fatto su Linux... io preferisco come è fatto ora: scarico il programma lo butto in una cartella e funziona! Peccato che anche qui inizino a parlare di Package Manager:
http://www.haikuware.com/directory/view-details/development/app-installation/packager
pabloski
25-10-2009, 14:19
il problema non sono le dipendenze di per sè ma come vengono gestite
se si facesse più uso del concetto di interfaccia ( come definito in objective-c ) allora molti problemi sarebbero risolti
purtroppo gli sviluppatori sono allergici alla programmazione ad oggetti, a quella generica, al multithreading, ai microkernel, all'ipc, alla memoria condivisa e al message passing
ah, dimenticavo il codice managed e i compilatori jit, visti come il male assoluto ( capirai per quel 3-4% di performance in meno si farebbero scannare )
p.s. che fortunato che sono....si parla di bloating, dependency hell, ecc... e ti scovo una proposta a dir poco assurda http://www.phoronix.com/scan.php?page=news_item&px=NzYyNQ
Infatti io sono un po' una mosca bianca... uso il C, ma spesso mi sta sulle palle... azz devi crearti tutto a mano! Manco le stringhe ci sono (i char * io li considero un HACK :Prrr: )...
Eppure i miei colleghi di C++ non vogliono sentir parlare... dicono che è inefficiente... eppure permette di fare tante cose in più gli oggetti!
Far le stesse cose in C è possibile, ma devi usare costrutti alquanto complicati.
Anche le [m]alloc() e free() come le odio... soprattutto quando me le scordo :Prrr:
Che belli sti flatELF... il peggio dei 2 mondi avremo binari giganteschi e contemporaneamente ci terremo il "dependency hell" :muro:
Che fi*ata :Prrr:
trapanator
25-10-2009, 22:13
Pensa al divertimento quando usi yum (che dovrebbe calcolare le dipendenze) e dichiara dopo 10-20 minuti che frulla di non esserci riuscito :muro: :muro: :muro:
O quando il programma installa libsarcazzo 1.25 in /lib e rompe tutte le altre applicazioni installate nel sistema che usano la 1.24 :D
Per me il sistema delle dipendenze è MALE! Almeno per come è fatto su Linux... io preferisco come è fatto ora: scarico il programma lo butto in una cartella e funziona! Peccato che anche qui inizino a parlare di Package Manager:
http://www.haikuware.com/directory/view-details/development/app-installation/packager
Guarda che anche per Linux (veramente anche per un qualsiasi programma) si possono compilare programmi in modo STATICO cioè includendo nel programma le librerie necessarie e portandole dove vuoi.
Il package manager è molto comodo, non è colpa di chi ha fatto il manager ma il pacchetto.
PatchWorKs
26-10-2009, 10:13
i winari potrebbero risponderti meglio
non pensi all'eccitazione di avere un installer da 150 MB per installare un banale programma che masterizza delle iso :D
Dai, non siamo assurdi, anche su windows esistono i "portable" e, specie quando sono open source, hanno dimensioni molto ragionevoli.
Es.
http://infrarecorder.org/
http://cdrtfe.sourceforge.net/
http://www.winpenpack.com/
pabloski
26-10-2009, 18:17
Dai, non siamo assurdi, anche su windows esistono i "portable" e, specie quando sono open source, hanno dimensioni molto ragionevoli.
Es.
http://infrarecorder.org/
http://cdrtfe.sourceforge.net/
http://www.winpenpack.com/
certo, ma non sono la norma
la norma sono i megapacchettoni, con eseguibili da decine di megabytes e millemila dll al seguito
Io sono per il megapacchettone tutto zippato. L'installer mi chiede solo in che cartella deve unzippare il tutto e aggiunge i link nei menu, stop! Il programma non mi piace? Non serve disinstallarlo, cancello link e cartella e nn c'è più! Tutti i file con le impostazioni si trovano nella cartella di ciascun programma, quindi spariscono con esso.
In questo modo posso installare decine di programmi e se mi stufo cancello ogni cartella e i vari link nei menu e mi ritrovo il sistema operativo come appena installato.....pura utopia oggi!
Le librerie condivise avevano un senso anni fa quando i Mb costavano cari, oggi non è più un problema e sarebbe ora di rivedere il tutto
Penso anch'io così... infondo è quello che fa più meno APPLE e mi pare funzioni egregiamente :D
Sembra che siamo i soli però... ad altri piace da matti l'idea dei package manager e di incasinarsi con le librerie condivise e le dipendenze :cry:
Bha per me se finiamo per avere un sistema di pacchetti e soprattutto di dipendenze anche su Haiku vuol dire che si è presa la via sbagliata!
Diciamo pure che il 90% delle volte funziona, ma è un hack non stiamo a nasconderci dietro a un dito.
L'altro giorno abbiamo tentato di installare il "man" completo su moblin e il gestore di dipendenze "giocattolo" diceva che c'era un conflitto e non dava la possibilità di fare un bel force... quindi si deve usare il terminale (:muro: ) yum... non ha --force!!! ... e allora usiamo RPM --force e speriamo che man non abbia dipendenze se no le deve risolvere a mano :D
Ciò vi rendete conto? "man" ha un conflitto :Prrr: :Prrr: :Prrr:
Tutti i file con le impostazioni si trovano nella cartella di ciascun programma, quindi spariscono con esso.
Non sarebbe meglio una cartelle nella home utente dedicata alle impostazioni dei programmi?
trapanator
28-10-2009, 08:32
Penso anch'io così... infondo è quello che fa più meno APPLE e mi pare funzioni egregiamente :D
Sembra che siamo i soli però... ad altri piace da matti l'idea dei package manager e di incasinarsi con le librerie condivise e le dipendenze :cry:
Bha per me se finiamo per avere un sistema di pacchetti e soprattutto di dipendenze anche su Haiku vuol dire che si è presa la via sbagliata!
Diciamo pure che il 90% delle volte funziona, ma è un hack non stiamo a nasconderci dietro a un dito.
L'altro giorno abbiamo tentato di installare il "man" completo su moblin e il gestore di dipendenze "giocattolo" diceva che c'era un conflitto e non dava la possibilità di fare un bel force... quindi si deve usare il terminale (:muro: ) yum... non ha --force!!! ... e allora usiamo RPM --force e speriamo che man non abbia dipendenze se no le deve risolvere a mano :D
Ciò vi rendete conto? "man" ha un conflitto :Prrr: :Prrr: :Prrr:
e se una libreria ha un bug di sicurezza, che si fa? aggiorniamo tutti i pacchetti che usano quella libreria?
e se una libreria ha un bug di sicurezza, che si fa? aggiorniamo tutti i pacchetti che usano quella libreria?
A sto punto l'ideale è nessun pacchettone, ma repository con programmi e librerie come fa ora x esempio debian, quando si installa si scarica il programma con le relative librerie tutto in una cartella, se si installa un secondo programma che usa la stessa libreria si scaricherà ancora quella libreria e si metterà nella cartella del secondo programma e così via. Nel momento che viene rilevato un bug si aggiorna il sistema che andrà a sostituire la libreria incriminata in tutte le cartelle dove è stata installata, non è così complicato. Certo questo sistema può funzionare tranquillamente su linux che già usa i repository, su windows invece necessita l'aggiornamento di ogni programma come dici tu
PatchWorKs
29-10-2009, 09:36
Certo questo sistema può funzionare tranquillamente su linux che già usa i repository, su windows invece necessita l'aggiornamento di ogni programma come dici tu
Anche qua 'sto problema non lo vedo: ormai quasi tutti gli applicativi hanno l'autoupdater, che semplifica molto la vita...
Eventualmente si potrebbe pensare ad un package manager che fà anche da autoupdater...
Slayer86
29-10-2009, 12:18
Cmq io non ho dubbi al riguardo il sistema con librerie condivise e packet-manager è inifnitamente più comodo!!!
La prima cosa che mi ha piacevolmente sorpreso rispetto a windows è proprio qesto... un sistema di update centralizzato(non un updater per applicazione che fa i cazzi suoi!!!) che gestisce ogni aspetto del sistema!!! Altra cosa che non mi piacerebbe è la replica delle librerie... non capisco il perchè se una applicazione che è una semplice gui deve pesare 100mb quando 95mb di librerie sono condivise... bha...
Cmq io non ho dubbi al riguardo il sistema con librerie condivise e packet-manager è inifnitamente più comodo!!!
...IMHO è solo bloating e problemi di gestione. La via delle librerie centralizzate, condivise e aggiornate che mantiene il sistema pulito, leggero, e non spreca l'HD è la migliore. D'altra parte vengo dal mondo Amiga che ha questa filosofia da 20 anni e più, e funziona da dio... e non per niente BeOS stesso si ispirava ad Amiga in molte cose.
Qualcuno l'ha testato su PC vecchi (Io ho ad esempio un Pentium II su cui forse potrei fare qualche prova)
...IMHO è solo bloating e problemi di gestione. La via delle librerie centralizzate, condivise e aggiornate che mantiene il sistema pulito, leggero, e non spreca l'HD è la migliore. D'altra parte vengo dal mondo Amiga che ha questa filosofia da 20 anni e più, e funziona da dio... e non per niente BeOS stesso si ispirava ad Amiga in molte cose.
Mah io non dico che si debba buttar completamente a mare il concetto delle librerie sharate magari si può studiare un sistema a livelli:
/boot/system/lib (con sottodir gcc2/gcc4 se è un hybrid) contiene quelle di sistema: solo HAIKU INC. può aggiornarle! Nessun altro :p
/boot/system/apps/VENDOR/lib (per esempio Mozilla metterebbe le librerie fatte da loro che possono usare Firefox, Seamonkey, Thunderbird...)
/boot/system/apps/VENDOR/APPLICATION/lib (per esempio Firefox schiaffa qui le sue proprie specifiche librerie).
Analoga alberatura quando Haiku diverrà multiutente:
/boot/home/USER/lib
/boot/home/USER/VENDOR/lib
/boot/home/USER/VENDOR/APPLICATION/lib
Ora tu mi dirai, ma se l'applicazione tal dei tali usa la versione 1.5 di una libreria che si trova in system, ma in versione 1.4? O si aspetta che Haiku aggiorni la libreria o semplicemente mette la propria versione in una delle dir "dedicate"!
Poi se non è un baco di sicurezza o la nuova versione aggiunge funzionalità esotiche si potrebbe anche tenere la 1.4...
A me spesso mi da l'impressione che almeno su LINUX spesso non cambia nulla a parte il numero di versione :p
Slayer86
31-10-2009, 19:23
Mah io non dico che si debba buttar completamente a mare il concetto delle librerie sharate magari si può studiare un sistema a livelli:
/boot/system/lib (con sottodir gcc2/gcc4 se è un hybrid) contiene quelle di sistema: solo HAIKU INC. può aggiornarle! Nessun altro :p
/boot/system/apps/VENDOR/lib (per esempio Mozilla metterebbe le librerie fatte da loro che possono usare Firefox, Seamonkey, Thunderbird...)
/boot/system/apps/VENDOR/APPLICATION/lib (per esempio Firefox schiaffa qui le sue proprie specifiche librerie).
Analoga alberatura quando Haiku diverrà multiutente:
/boot/home/USER/lib
/boot/home/USER/VENDOR/lib
/boot/home/USER/VENDOR/APPLICATION/lib
Ora tu mi dirai, ma se l'applicazione tal dei tali usa la versione 1.5 di una libreria che si trova in system, ma in versione 1.4? O si aspetta che Haiku aggiorni la libreria o semplicemente mette la propria versione in una delle dir "dedicate"!
Poi se non è un baco di sicurezza o la nuova versione aggiunge funzionalità esotiche si potrebbe anche tenere la 1.4...
A me spesso mi da l'impressione che almeno su LINUX spesso non cambia nulla a parte il numero di versione :p
ed eccovi servito windows svista...con tutti i suoi miglioni di dll che vanno in conflitto tra loro...
no grazie!!! se ci si muovesse in questa direzione haiku non mi interesserebbe più! Io spero in una gestione linux-like...
Lo ammetto un po' è può sembrare simile a SvistA, ma non capisco perché parli di conflitti tra ... .so ogni programma userebbe o quelle del sistema (e la maggior parte faranno così) se vorranno avranno in più le proprie... nessun conflitto!
A me non piace l'idea delle dipendenze se si potesse avere un package manager (se fosse una cosa leggera, spesso sono cosi pesantissimi :muro: ) senza le dipendenze potrei anche accettarlo anche se nulla batte il sistema di copiare il programma in una cartella alla APPLE per certi versi :Prrr:
Ribadisco: le librerie condivise sono la via per un sistema efficiente, che occupa poco su HD e facile da mantenere (basta aggiornarle dato che sono centralizzate). Esattamente come su AmigaOS da 20 anni e oltre a questa parte... Sono i programmatori (anche delle stesse librerie!) che non devono essere idioti e fare compilazioni e/o versioni "esclusive" e statiche. Va da sè che anche le librerie vanno sviluppate tenendo conto di una retro-compatibilità...
Linux e Windows NON sono buoni esempi e sono "dinamici" quanto un elefante molto stupido.
Linux e Windows NON sono buoni esempi e sono "dinamici" quanto un elefante molto stupido.
OK, ma io solo questi esempi vedo :D
... e non mi pare funzioni granché come dici anche tu :p
AmigaOS purtroppo non ho mai avuto seriamente la possibilità di usarlo ci ho solo giocato un po' con WinUAE, ma non è la stessa cosa.
Avrei tanto voluto un AMIGA, ma mi son deciso troppo tardi quando volevo comprarmelo stava iniziando già il fallimento :cry: :cry: :cry:
Io so solo che l'altro giorno si è tentato di aggiornare UBUNTU alla nuova versione... a parte che:
1) Il sistema di aggiornamento via GUI si è rifiutato di funzionare :confused:
2) ... quindi si deve usare il terminale (e già mi incazzo :muro: )
3) ravana per ora scaricando migliaia di file e calcolando dipendenze su dipendenze :ciapet:
4) Alla fine di tutto sto casino mi pare sia cambiato solo lo sfondo di default... apriamo GVIM (ricominciamo a lavorare sul serio che abbiamo perso una mattinata con sto trusco :D ) e orrore: non va più il syntax highlighting, il soft tab e tutte le varie personalizzazioni sono andate perse :Prrr: :Prrr: :Prrr:
Davvero comodissimo, no?
Vabbhe vediamo cosa decidono di fare speriamo imparino dagli errori degli altri SO (Linux e... Windows).
Un altra cosa a cui tengo è il SO "sicuro by design" facile a dirsi molto molto complicato a farsi mi sa :D
pabloski
31-10-2009, 22:27
il problema di linux, e anche di windows, è l'arte del programmare ad capocchiam, ovvero voglio che il software sappia tutto delle sue dipendenze
fu inventato, tanti tanti anni fa, una cosa chiamata programmazione ad oggetti e ben presto la cosa fu migliorata introducendo il concetto di interfaccia, poi di passaggio di messaggi, segnali, ecc....
ad oggi si usa ancora il modello di programmazione procedurale per implementare interi sistemi operativi
questo è uno dei maggiori motivi del dependency hell....se non posso aver fiducia che tra la versione 2.5 e la 2.6 della libreria vatte-la-pesca l'interfaccia rimane retrocompatibile, allora è finita
i microkernel portano questo concetto all'estremo, implementando vari server che comunicano tramite messaggi....in pratica è lo stesso discorso....i messaggi sono i metodi dell'interfaccia, ma come vengono elaborati è solo affare del server che li riceve
oppure se pensi al perchè spesso linux ha incompatibilità con i suoi driver e i vari sottosistemi che lo compongono, pensa che ognuno dei moduli del kernel deve manipolare le strutture dati del kernel....e lì si tratta di partire ad esempio dall'offset 0 e spostarsi di n byte ( dove presumibilmente è localizzato un certo elemento della struttura )....ovviamente cambi la struttura e boom, esplode tutto
linux ha risolto racchiudendo nel kernel ( e nella ricompilazione per la quale tutti i winari ci prendono in giro ) tutti gli elementi che toccano le strutture dati del kernel stesso
solo che poi tra kernel e userland dovrebbe esserci un metodo chiaro per comunicare e soprattutto resistente agli aggiornamenti
windows risolve invece installando tutte le versioni necessarie di una data libreria e multiplexandole in modo che possano accedere alle stesse risorse contemporaneamente....spesso funziona, ma a volte fa un bel botto :D
il giorno in cui impareranno da apple e dall'objective-c, forse le cose cambieranno....
p.s. l'esempio di amiga è calzante, visto che è stato il primo os a fare un uso serio e mirato delle astrazioni a tutti i livelli...basti pensare a come vengono gestiti i tipi dati per capire che siamo su un altro livello rispetto alla massa degli os più diffusi
Xemertix
31-10-2009, 22:56
Penso anch'io così... infondo è quello che fa più meno APPLE e mi pare funzioni egregiamente :D
Sembra che siamo i soli però... ad altri piace da matti l'idea dei package manager e di incasinarsi con le librerie condivise e le dipendenze :cry:
Bha per me se finiamo per avere un sistema di pacchetti e soprattutto di dipendenze anche su Haiku vuol dire che si è presa la via sbagliata!
Diciamo pure che il 90% delle volte funziona, ma è un hack non stiamo a nasconderci dietro a un dito.
L'altro giorno abbiamo tentato di installare il "man" completo su moblin e il gestore di dipendenze "giocattolo" diceva che c'era un conflitto e non dava la possibilità di fare un bel force... quindi si deve usare il terminale (:muro: ) yum... non ha --force!!! ... e allora usiamo RPM --force e speriamo che man non abbia dipendenze se no le deve risolvere a mano :D
Ciò vi rendete conto? "man" ha un conflitto :Prrr: :Prrr: :Prrr:
Sono d'accordo,quello di Apple sembra un buon esempio per un sistema desktop..meglio lasciare i programmi,per quanto possibile,totalmente indipendenti gli uni dagli altri piuttosto che risolvere ogni volta casini con le librerie dinamiche ed avere applicazioni che smettono di funzionare improvvisamente dopo l'aggiornamento di una di quelle librerie (un castello di carte,ne togli una,crolla tutto) e senza necessità di aggiornare tutta la distro per poter usare l'ultima versione di un programma etc..Roba che "it just works" e del resto gli hd sono sempre più economici;prestazionalmente,a parte l'impiego maggiore di spazio su disco,non credo dovrebbe esserci molta differenza su una macchina non troppo vecchia..
Per chi preferisce l'altro metodo ci sono già i tanti derivati di Unix,mentre sono pochi i sistemi liberi o open source ad utilizzare i pacchetti autocontenuti.
Il package manager però direi di mantenerlo,perché è di una comodità fondamentale (i tanti programmi su windows che hanno ognuno una propria funzione di autoupdate sono piuttosto fastidiosi) e del resto,se non erro,anche Pc-Bsd,che impiega il formato pbi,ne ha uno.
Sono d'accordo,quello di Apple sembra un buon esempio per un sistema desktop..meglio lasciare i programmi,per quanto possibile,totalmente indipendenti gli uni dagli altri piuttosto che risolvere ogni volta casini con le librerie dinamiche ed avere applicazioni che smettono di funzionare improvvisamente dopo l'aggiornamento di una di quelle librerie (un castello di carte,ne togli una,crolla tutto)
...Questo dipende da come è fatta la libreria in questione e dal suo modello di sviluppo, nonché dall'applicazione stessa che magari poco furbescamente cerca le chiamate sempre agli stessi offset invece di interrogare prima dove sono rilocate...
Il sistema funziona perfettamente senza nessun problema per le applicazioni, se tutto è fatto seguendo un certo modello e filosofia/linee guida di sviluppo, come AmigaOS può testimoniare. Non c'è niente di più facile ad es. che aggiornare il file LIBS:openurl.library con una nuova versione per vedere tutte le applicazioni che la usano funzionare meglio e più efficientemente, altro che avere 12 copie di varie versioni sparse su HD e ogni programma che carica e usa la sua col rischio di esplodere. Inefficienza, lentezza, memoria sprecata, HD sprecato, download inutilmente grandi etc...
e senza necessità di aggiornare tutta la distro per poter usare l'ultima versione di un programma etc..Roba che "it just works" e del resto gli hd sono sempre più economici;prestazionalmente,a parte l'impiego maggiore di spazio su disco,non credo dovrebbe esserci molta differenza su una macchina non troppo vecchia..
Personalmente aborro tale concezione...
La butto qui: un'organizzazione delle librerie in:
/boot/system/lib - librerie condivise di sistema;
/boot/home/user/lib - librerie condivise dell'utente;
/program dir/programma/lib - librerie specifiche del programma.
All'avvio del programma, l'applicazione cerca le librerie prima nella dir /lib nella sua cartella, poi in quelle condivise dell'utente e infine in quelle condivise di sistema
La butto qui: un'organizzazione delle librerie in:
/boot/system/lib - librerie condivise di sistema;
/boot/home/user/lib - librerie condivise dell'utente;
/program dir/programma/lib - librerie specifiche del programma.
All'avvio del programma, l'applicazione cerca le librerie prima nella dir /lib nella sua cartella, poi in quelle condivise dell'utente e infine in quelle condivise di sistema
...Suggerirei il contrario per mantenere più coerenza ed invogliare programmatori e utenti all'uso delle lib condivise e centralizzate che rende tutto più semplice (gestione/manutenzione): proprio come fa AmigaOS ;) che, se non l'ha già caricata in memoria precedentemente (notare che AmigaOS carica e scarica dalla memoria librerie non più rimaste "aperte e in uso" dinamicamente per risparmiare risorse! Puoi persino forzare la liberazione con un comando da shell: "Flush"!), prima cerca in LIBS: (= root/libs, quelle di default di sistema condivise...), se non trova lì cerca in home_dir_programma/libs.
Non esiste invece una /user/lib per tenere ancora più ordinate le cose, ma è tranquillamente creabile su quest'OS con un semplice comando:
assign <miopath> LIBS: ADD ("add" = l'opzione, come -xxx per Linux o /x per MS-DOS, solo molto più comprensibile per esteso (http://winuaehelp.back2roots.org/background/amigados.htm) e non limitato a 2-3 caratteri da imparare a memoria dopo - oppure / :)) che varrà esattamente come fosse LIBS: (= se un programma cerca come di default in LIBS: la trova! :) Questo concetto è espandibile a tutti i percorsi predefiniti di sistema...) come fosse una sua clavicola.
Quando si dice che AmigaOS era avanti (eppure ha oltre 20 anni!)...
Io da sempre lo considero l'evoluzione più intelligente mai concepita per un OS di tipo Unix-like...
Iscritto, molto interessante - per ora ho provato Haiku solo su VirtualBox per testarlo in modo superficiale, e sembra molto carino e di un certo potenziale, credo. Ah, i tempi del BeOs... peccato non aver fatto in tempo a provarlo!
La butto qui: un'organizzazione delle librerie in:
/boot/system/lib - librerie condivise di sistema;
/boot/home/user/lib - librerie condivise dell'utente;
/program dir/programma/lib - librerie specifiche del programma.
All'avvio del programma, l'applicazione cerca le librerie prima nella dir /lib nella sua cartella, poi in quelle condivise dell'utente e infine in quelle condivise di sistema
Una versione semplificata di quanto avevo proposto io qui:
http://www.hwupgrade.it/forum/showpost.php?p=29504357&postcount=943
Per me però ci son directory che non devono essere scritte dai programmi che "appartengono" al sistema... per dire vorreste che firefox vi aggiornasse la glibc? Provateci un po'... e poi fate ls :Prrr:
Fatemi sapere come va...
Portando l'esempio ad Haiku non credo esso gradirebbe se gli sostituisco (o cancello) libbe... penso smetterebbe di funzionare :D
Questo a che fare anche con quello che io chiamo "security by design" :p
Comunque stavo leggendo la riunione che hanno avuto i "mentori" degli OS non Linux del Google Summer of code ovvero:
# Minix
# Plan 9
# Haiku (ovviamente :ciapet: )
# OpenSolaris
# NetBSD
# DragonflyBSD
# RTEMS
stanno pensando a una cosa che se ci riescono potrebbe essere l'idea più interessante dopo l'invezione del pane imburrato ( ;) ): perchè non ci inventiamo un modello unificato per scrivere i driver?
Così i driver sono 1 e vanno su tutti come per magia...
Stanno pensando di ritirar fuori un progetto davvero interessante: UDI (http://www.projectudi.org/).
Ecco il link al report dell'incontro :D
http://www.haiku-os.org/blog/scottmc/2009-11-01_2009_google_summer_code_mentor_summit
In particolare UDI sembra molto interessante peccato che sembra un po' arenato sembra gli ultimi lavori siano stati fatti nel 2000... spero i "non allineati" possano ri-prendere in mano il progetto... almeno si evita di ricominciar da capo ogni volta :Prrr:
Ehh io che come al solito davo la colpa alla M*crosoft invece...:
http://en.wikipedia.org/wiki/Uniform_Driver_Interface
The Uniform Driver Interface (UDI) is a defunct project developed by several companies to define a portable interface for device drivers.
[OMISSIS]
While UDI could potentially benefit open source operating systems such as Linux and *BSD by providing more driver support from companies, some open source/free software advocates feared that UDI would cause a proliferation of closed source drivers and a reduction in open source support by companies, undermining the purpose of the free software and open source movements. Richard Stallman (the leader of the free software movement) has claimed that the project does not benefit the free software movement.
Bha che assurdo modo di pensare... chi se ne frega se i driver son proprietari? Io la vedo così l'importante è che ci siano (e funzionano) poi che mi li dia ATI/AMD o il super hacker minc*iaConsumata :D ...
Non ha senso per me :muro:
I driver indipendenti dal sistema operativo sarebbero una grandissima cosa per la diffusione dei sistemi operativi alternativi
Già, ma a Richard Stallman non piacque e UDI fu boicottato :muro:
Speriamo questa gente che forse ha meno grilli per la testa riesca a ottenere qualocosa di buono.
Per me sarebbe un po' come il "santo graal"... il problema di questi OS alternativi è sempre quello... Haiku può esser bello quanto volete, ma se poi la mia VGA da un grazioso schermo nero che me ne faccio?
Una versione semplificata di quanto avevo proposto io qui:
http://www.hwupgrade.it/forum/showpost.php?p=29504357&postcount=943
Per me però ci son directory che non devono essere scritte dai programmi che "appartengono" al sistema... per dire vorreste che firefox vi aggiornasse la glibc? Provateci un po'... e poi fate ls :Prrr:
Fatemi sapere come va...
Portando l'esempio ad Haiku non credo esso gradirebbe se gli sostituisco (o cancello) libbe... penso smetterebbe di funzionare :D
Questo a che fare anche con quello che io chiamo "security by design" :p
Comunque stavo leggendo la riunione che hanno avuto i "mentori" degli OS non Linux del Google Summer of code ovvero:
# Minix
# Plan 9
# Haiku (ovviamente :ciapet: )
# OpenSolaris
# NetBSD
# DragonflyBSD
# RTEMS
stanno pensando a una cosa che se ci riescono potrebbe essere l'idea più interessante dopo l'invezione del pane imburrato ( ;) ): perchè non ci inventiamo un modello unificato per scrivere i driver?
Così i driver sono 1 e vanno su tutti come per magia...
Stanno pensando di ritirar fuori un progetto davvero interessante: UDI (http://www.projectudi.org/).
Ecco il link al report dell'incontro :D
http://www.haiku-os.org/blog/scottmc/2009-11-01_2009_google_summer_code_mentor_summit
In particolare UDI sembra molto interessante peccato che sembra un po' arenato sembra gli ultimi lavori siano stati fatti nel 2000... spero i "non allineati" possano ri-prendere in mano il progetto... almeno si evita di ricominciar da capo ogni volta :Prrr:
Ehh io che come al solito davo la colpa alla M*crosoft invece...:
Bha che assurdo modo di pensare... chi se ne frega se i driver son proprietari? Io la vedo così l'importante è che ci siano (e funzionano) poi che mi li dia ATI/AMD o il super hacker minc*iaConsumata :D ...
Non ha senso per me :muro:
magari!!!!
buongiorno a tutti
sapete se beos/haiuko supporta il modem conexant accessrunner usb?
nel caso sia compatibile esiste una guida su come configurarlo?
pabloski
05-11-2009, 18:16
credo proprio di no...quel modem ha dato rogne per anni su linux, figuriamoci se si sognano di portare i driver su haiku
credo proprio di no...quel modem ha dato rogne per anni su linux, figuriamoci se si sognano di portare i driver su haiku
su debian e derivate i driver sono gia incluse ormai da molto tempo e basta copiare un file per avere la connessione a internet
pabloski
05-11-2009, 18:48
su debian e derivate i driver sono gia incluse ormai da molto tempo e basta copiare un file per avere la connessione a internet
vero, ma ricordo che 4-5 anni fa era impossibile far andare quel modem a dovere con i driver a metà che c'erano
Buone notizie!
Rudolf ha trovato una NVIDIA 6200 (quella si avvicina di più alla mia 6150 integrata) ed è riuscito a riprodurre il problema e, soprattutto, a risolverlo :D
Ora, finalmente, l'uscita VGA funziona... come da lui stesso suggerito il secondo passo è il dualhead... ovvero Monitor via VGA a 1280*1024 e HDTV a 1920*1080p contemporaneamente :p
Ovviamente era forse chiedere troppo... prima di tutto la DVI è primaria e quando la colleghi la VGA si disabilita... va a 800*600 @ 72.4 Hz (:confused: ) inutile dirvi che su un 46" non è il massimo...
Forse mi serve questa:
http://www.bebits.com/app/1401
ma, ovviamente, il link è rotto :muro: :muro: :muro:
Attaccando l'HDMI da solo posso almeno selezionare 1280*720 @60 Hz, 1920*1080 il log dice che non è supportato e invece lo è :Prrr:
La cosa strana è che posso selezionare refresh rate molto esotici manca il 24p, ma in compenso posso scegliere 48, 72 e persino 100 (120 non so se era disponibile!) mi sono emozionato a vederlo andare a 100 Hz :D :D :D e non ho avuto il coraggio di tentare i 120 Hz (il mio HDTV dovrebbe avere il controllo... e non esplodere però :eek: )
Non so se è vero o no (l'OSD del tv non dice nulla sulla frequenza di refresh) il driver di Windows non permette minimamente questi refresh rate... se lo fa veramente il driver di Haiku è pure meglio sotto questo aspetto (ho alcuni mkv che sono VFR - variable frame rate e l'unico modo decente per vederli sarebbe di andare a 120 Hz... se fosse vero :D )
Beh se si riesce a sistemare questo mi manca il supporto per il mio SoundGraph Imon (display + telecomando) e un qualcosa di simile a Mediaportal e per me è pronto all'uso :ciapet:
Fosse facile, eh?
Bundle o non bundle?
Sembra di sì :D
http://dev.haiku-os.org/wiki/PackageManagerIdeas
che bello :p :p :p
trapanator
12-11-2009, 08:40
Forse mi serve questa:
http://www.bebits.com/app/1401
ma, ovviamente, il link è rotto :muro: :muro: :muro:
Dalla R2 questi driver saranno inutili, visto che sarà tutto compilato con GCC4.
trapanator
12-11-2009, 08:41
Bundle o non bundle?
Sembra di sì :D
http://dev.haiku-os.org/wiki/PackageManagerIdeas
che bello :p :p :p
In sostanza come su Mac e BSD
Vogliono usare libalpm, che è la libreria che sta dietro a pacman, Arch rulez!!!!!!!
http://dev.haiku-os.org/wiki/PackageManagerIdeas#libalpm
http://stud4.tuwien.ac.at/~e0725517/using-pacman-on-haiku.log.txt
Dalla R2 questi driver saranno inutili, visto che sarà tutto compilato con GCC4.
Perché inutili?
Basterà ricompilarli per GCC4!
Potrebbero diventare inutili per altri motivi (se riescono a fare i driver unificati con Rosetta o se/quando passeranno a Gallium), ma non certo per GCC4...
Comunque ho provato anche il DualHead con l'applicazione apposita... bhe è alquanto immaturo:
I 2 schermi devono avere la stessa risoluzione e siccome uno è 4:3 vanno a 800*600
Haiku vede i 2 schermi come un desktop esteso e mi apre le "MessageBox" al centro tra i 2 schermi... cioè il bottone OK sta a metà :D
Del resto si vede che è una sorta di "hack" dovrebbe stare dentro "Screen" non in una cosa a parte, dopo averlo usato mi pare tra l'altro Screen non mi permette più di cambiare la risoluzione :cry:
Vabbeh almeno sono riuscito a veder qualcosa con la VGA il ticket si può chiudere... il DualHead è un di più :p
Magari è più corretto che ne apra un altro...
In sostanza come su Mac e BSD
Esatto si avvicina molto a quello che auspicavo... anche se comunque il package manager vogliono farlo lo stesso... mah speriamo che non succedano i casini che capitano con gli altri sistemi operativi.
Interessante anche l'altra idea del "pakageFS" utile sopratutto per i "porting" che hanno la bella abitudine di spargere file un po' ovunque... in directory che in Haiku/BeOs manco hanno senso (/etc /usr/bin /usrl/local/bin...).
Sono tutti concordi che una cosa del genere fa abbastanza schifo :p
D'altro canto possiamo rinunciare a python o apache?
Quindi hanno pensato a sto pakageFS praticamente, se ho capito bene, pyton sarebbe un "immagine" (concettualmente simile al bundle, alla fine) e ogni volta che serve o la prima che lo invochi viene "montato" e ha l'illusione di aver sparso bratta per tutto il FS, ma è un illusione in realtà alla chiusura del programma verrà smontato e tutto tornerà come prima :p
@hexaae un'altra ipotesi è copiare da AMIGA :D
http://www.freelists.org/post/haiku-development/Pathrelocatable-software-and-assigns
@hexaae un'altra ipotesi è copiare da AMIGA :D
http://www.freelists.org/post/haiku-development/Pathrelocatable-software-and-assigns
Sarebbe meglio... ma pare che siano più portati al solito macchinoso packet manager di ispirazione *nix recenti purtroppo. Gli approcci Amiga sono sempre i più semplici, eleganti e versatili (= offrono poi la possibilità di usarli anche per altro (http://www.freelists.org/post/haiku-development/Pathrelocatable-software-and-assigns,12), a cui al momento non si pensa perché il concetto è di lavorare sulla libertà e flessibilità dell'OS potenziandolo dall'interno, non nel creare soluzioni ad hoc e quindi limitate a risolvere i problemi nei singoli casi, per buone che siano...), ma purtroppo pochi conoscevano bene AmigaOS...
IMHO Haiku (in realtà TUTTI gli OS! :D) dovrebbe trarre molta più ispirazione da Amiga che dal mondo Unix, cosa che BeOS saggiamente per dichiarazione dello stesso Gassé intendeva fare...
Infatti la cosa di dover avere il package manager non la capisco... allora il bundle a cosa serve? Mah spero che non prendano una cattiva strada copiando troppo dal mondo UNIX.
Io continuo a non vederci nulla di male se nel bundle c'erano pure le dipendenze...
Mha speriamo che in un futuro non saremo qui a morderci le mani dopo aver installato un programma ed esserci accorti che ha aggiornato una libreria rompendo tutto il resto :mad:
Mha speriamo che in un futuro non saremo qui a morderci le mani dopo aver installato un programma ed esserci accorti che ha aggiornato una libreria rompendo tutto il resto :mad:
La mia idea sul fatto che il programma dovrebbe cercare la libreria prima nella sua cartella (es: programma vuole libc.so v1.5 e l'os per funzionare decentemente la 1.4, essendo alcune funzioni della 1.4 deprecate nella 1.5) non e' così male alla fine :D
La mia idea sul fatto che il programma dovrebbe cercare la libreria prima nella sua cartella (es: programma vuole libc.so v1.5 e l'os per funzionare decentemente la 1.4, essendo alcune funzioni della 1.4 deprecate nella 1.5) non e' così male alla fine :D
Io questo discorso non l'ho mai capito. Su AmigaOS è prassi che le nuove versioni di libreria siano sempre compatibili con le precedenti. Tutto ciò che devi fare e essere sicuro che in LIBS: ci sia l'ultima versione per essere sicuro di non avere problemi ed essere aggiornato. Nuove funzioni dovrebbero essere separate, nuove appunto, non stravolte lasciando la stessa chiamata che però restituisce valori completamente diversi. È un modo caotico di sviluppare software e porta appunto ad avere l'HD pieno di robaccia doppione su Win e Linux con clash di librerie con versione.revisione differenti, requisiti di memoria maggiori (10 volte la stessa libreria in varie versioni caricata), inefficienza, spazio sprecato...
Efficienza attraverso la semplicità era il motto Amiga, a ragione. Esisteva persino una Style Guide di riferimento per tutti i programmatori sul come comportarsi...
Slayer86
20-11-2009, 18:30
Io questo discorso non l'ho mai capito. Su AmigaOS è prassi che le nuove versioni di libreria siano sempre compatibili con le precedenti. Tutto ciò che devi fare e essere sicuro che in LIBS: ci sia l'ultima versione per essere sicuro di non avere problemi ed essere aggiornato. Nuove funzioni dovrebbero essere separate, nuove appunto, non stravolte lasciando la stessa chiamata che però restituisce valori completamente diversi. È un modo caotico di sviluppare software e porta appunto ad avere l'HD pieno di robaccia doppione su Win e Linux con clash di librerie con versione.revisione differenti, requisiti di memoria maggiori (10 volte la stessa libreria in varie versioni caricata), inefficienza, spazio sprecato...
Efficienza attraverso la semplicità era il motto Amiga, a ragione. Esisteva persino una Style Guide di riferimento per tutti i programmatori sul come comportarsi...
Una domanda (non voglio essere provocatorio...) ma se amiga os è tanto superiore perchè non viene preso ad esempio??? evidentemente ha dei limiti non indifferenti... uno è quello di vincolare lo sviluppo di librerie (nel senso che devono sempre essere retro-compatibili)...
Io questo discorso non l'ho mai capito. Su AmigaOS è prassi che le nuove versioni di libreria siano sempre compatibili con le precedenti. Tutto ciò che devi fare e essere sicuro che in LIBS: ci sia l'ultima versione per essere sicuro di non avere problemi ed essere aggiornato. Nuove funzioni dovrebbero essere separate, nuove appunto, non stravolte lasciando la stessa chiamata che però restituisce valori completamente diversi. È un modo caotico di sviluppare software e porta appunto ad avere l'HD pieno di robaccia doppione su Win e Linux con clash di librerie con versione.revisione differenti, requisiti di memoria maggiori (10 volte la stessa libreria in varie versioni caricata), inefficienza, spazio sprecato...
Efficienza attraverso la semplicità era il motto Amiga, a ragione. Esisteva persino una Style Guide di riferimento per tutti i programmatori sul come comportarsi...
Idealmente ok, ma nella realtà...
Idealmente ok, ma nella realtà...
Nella realtà mi auguro che per Haiku mantengano lo sviluppo omogeneo come promesso. Quindi potrebbero dettare benissimo delle ferree linee guida da seguire... è il solito discorso, e il solito rischio di finire come le caotiche distro Linux che vanificherebbe la bontà di questo OS diventando "come gli altri"...
Una libreria dovrebbe essere sempre retrocompatibile peccato purtroppo sta cosa dai tempi di AMIGA si sia un po' persa :p
hexaae mettiamo che le librerie fatte da Haiku o per Haiku sono fatte nel modo giusto... cosa si fa della roba portata da Linux/Unix?
Se la lib_sarcazzo.1.0.4 e lib_sarcazzo.1.0.5 sono due cose completamente diverse come si può pensare minimamente che poi tutto funzioni ancora?
O si decide che non si prende NULLA da là partendo dall'assunto che "l'è tutto sbagliato, l'è da rifare" (cosa che magari può pure esser vera, tra l'altro!) o si decide "NO noi si resta alla lib_sarcazzo.1.0.4 per ora: sviluppatori adeguatevi di conseguenza... quando NOI aggiorniamo alla lib_sarcazzo.1.0.5 lo fate anche voi :p"
... o se un programma vuol usare per forza lib_sarcazzo.1.0.5 la schiaffa nella sua dir senza romper le palle a tutti gli altri!
Una libreria dovrebbe essere sempre retrocompatibile peccato purtroppo sta cosa dai tempi di AMIGA si sia un po' persa :p
hexaae mettiamo che le librerie fatte da Haiku o per Haiku sono fatte nel modo giusto... cosa si fa della roba portata da Linux/Unix?
Se la lib_sarcazzo.1.0.4 e lib_sarcazzo.1.0.5 sono due cose completamente diverse come si può pensare minimamente che poi tutto funzioni ancora?
O si decide che non si prende NULLA da là partendo dall'assunto che "l'è tutto sbagliato, l'è da rifare" (cosa che magari può pure esser vera, tra l'altro!) o si decide "NO noi si resta alla lib_sarcazzo.1.0.4 per ora: sviluppatori adeguatevi di conseguenza... quando NOI aggiorniamo alla lib_sarcazzo.1.0.5 lo fate anche voi :p"
... o se un programma vuol usare per forza lib_sarcazzo.1.0.5 la schiaffa nella sua dir senza romper le palle a tutti gli altri!
Io sono per la linea dura e la soluzione elegante e che si regolino di conseguenza gli sviluppatori idioti! :mad:
Se non si decidono subito queste cose e con fermezza si finisce nel caos che contraddistingue le distro del pinguino...
Per i port è relativamente semplice: saranno linkate staticamente nell'eseguibile se questo è il pessimo modo di programmare per gli altri OS! :ciapet:
Ma tanto già lo so come finisce... dannata l'influenza del pinguino che sta rovinando l'informatica libera (eh eh)! :nera:
http://i.techrepublic.com.com/blogs/tux-borg%281%29_bg.jpg
Speriamo di no... considero Haiku l'ultima speranza... non voglio più usare Windows :cry: :cry:
Carina l'immagine del pinguino borghizzato :D
Una domanda (non voglio essere provocatorio...) ma se amiga os è tanto superiore perchè non viene preso ad esempio???
Veramente per testuali parole di P. Gassè il BeOS vi si ispirava profondamente...
evidentemente ha dei limiti non indifferenti... uno è quello di vincolare lo sviluppo di librerie (nel senso che devono sempre essere retro-compatibili)...
Non esiste l'OS perfetto ma AmigaOS ci andava molto vicino, se non altro come concept moderno ed evoluto... ;)
Se a te poi sembra un limite che esista solo una libreria di riferimento a cui stare dietro con un semplice numero di versione.revisione invece di impazzire dietro a 10 "doppioni" inutili che occupano memoria e spazio nascosti su HD, e che causano clash...
Una libreria dovrebbe essere sempre retrocompatibile peccato purtroppo sta cosa dai tempi di AMIGA si sia un po' persa :p
hexaae mettiamo che le librerie fatte da Haiku o per Haiku sono fatte nel modo giusto... cosa si fa della roba portata da Linux/Unix?
Se la lib_sarcazzo.1.0.4 e lib_sarcazzo.1.0.5 sono due cose completamente diverse come si può pensare minimamente che poi tutto funzioni ancora?
O si decide che non si prende NULLA da là partendo dall'assunto che "l'è tutto sbagliato, l'è da rifare" (cosa che magari può pure esser vera, tra l'altro!) o si decide "NO noi si resta alla lib_sarcazzo.1.0.4 per ora: sviluppatori adeguatevi di conseguenza... quando NOI aggiorniamo alla lib_sarcazzo.1.0.5 lo fate anche voi :p"
... o se un programma vuol usare per forza lib_sarcazzo.1.0.5 la schiaffa nella sua dir senza romper le palle a tutti gli altri!
una soluzione potrebbe essere quella di creare un gestore tipo apt get o vari.. che quando si accorge del conflitto senza troppe "seghe mentali" installa la libreria nuova solo per quel programma che la richiede... e ogni volta che si aggiorna controlla se il conflitto può essere rimediato.. senza panico o fisime varie...
se si può rimediare tutto il sistema passa a lib_sarcazzo.1.0.5 altrimenti verrà usata solo dai programmi che la richiedono... e il sistema resta a lib_sarcazzo.1.0.4 :D
Infatti... personalmente non ci vedo nulla di male in questo :p
Piuttosto che incasinarsi con package manager incasinati e conflitti :muro: :muro: :muro:
pabloski
26-11-2009, 18:11
il problema è che una cosa del genere non è realizzabile
primo, nel filesystem non ci sono le informazioni necessarie per implementare un modello del genere
e poi la cosa si sarebbe già potuta fare, imponendo l'import di specifiche versioni delle librerie
per esempio se voglio usare libusb-0.1.so.4.4.4 a che mi serve libusb-0.1.so.4? e per di più al linker si chiede di importare libusb senza nemmeno specificare la versione
questo perchè chi fa un programma pensa di approfittare dell'evoluzione delle librerie ed è pure logico ( pensate ai bugfix )
il problema è che chi progetta le librerie non è abbastanza responsabile da mantenerle consistenti
ovviamente proceduralmente è praticamente impossibile mantenere la consistenza nell'interfaccia di una libreria, ma il paradigma ad oggetti ci dà questa possibilità....solo che nel mondo dei sistemi operativi due parole equivalgono a bestemmie e sono OOP e Microkernel
il problema è che una cosa del genere non è realizzabile
primo, nel filesystem non ci sono le informazioni necessarie per implementare un modello del genere
Non capisco perché dici questo... non so cosa accade con quel "casinaro" di Linux, ma con Windows se un programma richiede una .dll io la posso mette indifferentemente in "." (la dir del programma cioè) o in C:/Windows/system32 e il programma parte senza problemi.
Basta dire al loader che quando cerca una libreria deve guardare prima in "." poi nelle directory di sistema...
il problema è che chi progetta le librerie non è abbastanza responsabile da mantenerle consistenti
Già questo è il "peccato originale" in questo modo le librerie perdono di scopo... se non sono intercambiabili tra di loro a che servono?
ovviamente proceduralmente è praticamente impossibile mantenere la consistenza nell'interfaccia di una libreria, ma il paradigma ad oggetti ci dà questa possibilità....solo che nel mondo dei sistemi operativi due parole equivalgono a bestemmie e sono OOP e Microkernel
Infatti ne parlavo giusto con un mio collega l'altro giorno a cui spiegavo cos'è Haiku e quando ho accennato al fatto che è tutto C++ si è emozionato tutto dicendo che è pesante... infatti noi continuamo a usare il C e quello degli anni '80 :muro: :muro: :muro:
Nel frattempo Haiku fa il boot in 8 secondi... solo ora Moblin è riuscito ad eguagliarlo, ma dopo anni...
Mi sa che mi toccherà impararmelo da solo il C++ magari Haiku mi sarà da stimolo in questo :sofico:
Nel frattempo Haiku fa il boot in 8 secondi... solo ora Moblin è riuscito ad eguagliarlo, ma dopo anni...
Non male per un os ALPHA contro uno che seppur non ancora completo ha comunque solide basi di kernel Linux :D
... e comunque fin'ora solo Moblin ha il boot veloce Ubuntu avrebbe dovuto averlo, ma ci sta comunque i suoi buoni 40 secondi... sempre meno di CentOS 5.4 che ci sta un bel po' di minuti :muro:
... e comunque fin'ora solo Moblin ha il boot veloce Ubuntu avrebbe dovuto averlo, ma ci sta comunque i suoi buoni 40 secondi... sempre meno di CentOS 5.4 che ci sta un bel po' di minuti :muro:
Ciao.
Certo non si possono confrontare due os come bubuntu e CentOS, l'uno concepito per un utenza prettamente desktop e l'altro con ben altre caratteristiche di livello professionale....e di stabilità ed affidabilità. O perlomeno, questo è il mio parere.
Mi scuso per l'OT da paura....:D
trapanator
29-11-2009, 15:34
e che palle il boot...............
40 secondi contro 8 secondi non fa una grandissima differenza. Il pc non lo usi mica per 1 minuto e poi lo spegni.
E' stupidità confrontare 2 sistemi operativi per il boot, così come Office è sempre più veloce di OpenOffice a lanciarsi, eppure uso OpenOffice da più di 4 anni e ho buttato Office nel cestino.
Intanto: sono riusciti a portare Firefox 3.0a1 ad Haiku. Le versioni successive non possono essere portate perché manca il supporto a Cairo.
OK so solo che il mio PC da ufficio non lo spengo mai proprio per evitare di attendere il tempo di boot... ma quello è un EEEPC con XP non è proprio il caso di fare un confronto (dopo 15 minuti il sistema non è ancora usabile... il desktop c'è, ma di fatto io non posso farci nulla :muro: ).
A caso uso lo standby, ma in ufficio non posso... tutte le connessioni cadono e i 12 terminali e i 56 GVim aperti lo seguono... non molto comodo :D
Ottima cosa che ora si possa usare un browser un po' più nuovo Bon Echo è un po' troppo anziano... in attesa del nuovo browser nativo (a proposito hanno deciso come diavolo si chiama :D ?)
Ho provato ad avviare Haiku come SO ospite tramite Virtualbox dal mio MacBook (OSX of course), purtroppo non funziona ne trackpad ne stastiera. Qualcuno è riuscito ad avviarlo tramite vm?
Ho provato ad avviare Haiku come SO ospite tramite Virtualbox dal mio MacBook (OSX of course), purtroppo non funziona ne trackpad ne stastiera. Qualcuno è riuscito ad avviarlo tramite vm?
Su Windows con qEmu gira tranquillo
Anche con VMware... non so se VirtualBox sia molto supportato al momento :mad:
Magari prova con VMware (il player è gratis e ci sarà anche per MAC).
O magari se hai fortuna puoi provarlo come cd live... Almeno se ti parte e funziona spero tu abbia più fortuna di me che solo con il modo video Vesa riesce a partire :D
ieri ho provato ad installare haiku sul portatile..
ho usato il cd live ma dopo il post si è bloccato sulla schermata della scelta tra installazione e desktop... mouse e tastiera morti... in una delle prove che ho fatto sono riuscito ad entrare in installazione premendo SPACE e navigando con TAB ma solo quella volta li...
o è il cd masterizzato che è venuto male o era difettoso o c'è qualche incompatibilità con la scheda madre dell acer....
Stesso problema rilevato sull'Acer dell'ufficio... sembrava funzionare tutto a parte tastiera e mouse!
Direi che è un bug che andrebbe segnalato in trac :p
PatchWorKs
15-12-2009, 10:10
Premessa: "OT" necessario. :stordita:
e che palle il boot...............
40 secondi contro 8 secondi non fa una grandissima differenza.
...anche perché sennò KolibriOS (http://www.kolibrios.org/) "mangia in testa" a tutti (ho bootato l'ultima versione da USB - la 0.7.7.0 , peraltro uscita proprio qualche giorno fà - in circa 2 SECONDI :eek: ).
Se quei "testoni" russi degli sviluppatori si concentrassero - come da me suggerito più volte nel forum - sull'implementazione 100% assembly dei codecs (FFMPEG o solo MPEG1/2 e x264, ma anche Theora/Vorbis e Dirac), invece di "perdere tempo" coi demos/giochi, potremmo avere un mini OS che codifica (2pass) in tempo reale un DVD/BD mentre lo si vede, anche sun un Atom Diamondville: non sò se mi spiego...
...chissà se un giorno lo vedremo embeddato nei decoder/player/HTPC :angel:
Scusate per l'OT, ma volevo sfogarmi da qualche parte.
Premessa: "OT" necessario. :stordita:
...anche perché sennò KolibriOS (http://www.kolibrios.org/) "mangia in testa" a tutti (ho bootato l'ultima versione da USB - la 0.7.7.0 , peraltro uscita proprio qualche giorno fà - in circa 2 SECONDI :eek: ).
Leggo che KolibriOS è interamente scritto in ASM!! Tanto di cappello (e un Amighista come me sa bene cosa significhi spremere in questo modo le vere potenzialità della macchina) ma un po' anacronistico e suicida nel 2009.
Solo dei russi squattrinati e con poche risorse HW potevano farlo oggigiorno! ;)
Per soluzioni embedded certo può andare, anzi, ma se si tratta di farlo girare un po' ovunque...
trapanator
15-12-2009, 19:14
Leggo che KolibriOS è interamente scritto in ASM!! Tanto di cappello (e un Amighista come me sa bene cosa significhi spremere in questo modo le vere potenzialità della macchina) ma un po' anacronistico e suicida nel 2009.
Solo dei russi squattrinati e con poche risorse HW potevano farlo oggigiorno! ;)
Per soluzioni embedded certo può andare, anzi, ma se si tratta di farlo girare un po' ovunque...
Infatti, se vuoi farlo girare sui 64 bit... dovresti riscrivere un bel po' di codice. Senza contare le decine di migliaia di ottimizzazioni diverse sui vari processori (MMX, SSE, SSE2 ---> SSE4.1/4.2)
PatchWorKs
17-12-2009, 08:57
Siamo OT, comunque:
Infatti, se vuoi farlo girare sui 64 bit... dovresti riscrivere un bel po' di codice. Senza contare le decine di migliaia di ottimizzazioni diverse sui vari processori (MMX, SSE, SSE2 ---> SSE4.1/4.2)
...appunto, non sarebbe meglio puntare direttamente ad un target embedded ?
Come detto, KOS lo vedrei molto bene sopra un box multimediale tipo questo:
http://www.lc-power.de/typo3temp/pics/18ca24fc61.jpg (http://www.lc-power.de/index.php?id=145&L=1) (guardatevi sul manuale (http://www.lc-power.de/fileadmin/user_upload/Handbuecher/englisch/LC-PRO-35MPR-HDMI_english.pdf) le schermate di configurazione/uso: molto meglio KOS !)
Credo che riuscirebbe a spremerne ben bene le potenzialità oltre ad ampliarne i possibili usi (con una tastiera ed un mouse si trasformerebbe in un mini-pc con possibilità di far girare qualche semplice gioco - hanno già implementato DosBOX ed un'emulatore NES, mo' vediamo di chiedere il porting del MAME - e navigare anche in internet...). :sofico:
trapanator
17-12-2009, 09:11
Come detto, KOS lo vedrei molto bene sopra un box multimediale tipo questo:
http://www.lc-power.de/typo3temp/pics/18ca24fc61.jpg (http://www.lc-power.de/index.php?id=145&L=1) (guardatevi sul manuale (http://www.lc-power.de/fileadmin/user_upload/Handbuecher/englisch/LC-PRO-35MPR-HDMI_english.pdf) le schermate di configurazione/uso: molto meglio KOS !)
Ehm....... ho visto il manuale, ma cosa centra usare un sistema operativo rispetto ad un altro?
Qui si tratta di semplice interfaccia grafica e della sua intuitività: puoi usare anche il commodore 64 e fare un software interfaccia più intuitiva di un altro programma che gira su Windows .......... :)
PatchWorKs
18-12-2009, 10:19
No, io parlavo delle schermate del firmware da pag. 9 in poi...
non sembra male... vediamo cosa succede :D
EDIT: pensavo di leggere gli ultimi post invece leggevo la prima pagina del 2005 :) ... cmq ho provato in Vbox e sembra funzionante beos... solo un po complicato, poco intuitivo.
Novità dal team di sviluppo?
trapanator
29-12-2009, 08:02
Novità dal team di sviluppo?
http://dev.haiku-os.org/timeline
PatchWorKs
30-12-2009, 09:53
http://dev.haiku-os.org/timeline
Uhm... questo èmolto più comprensibile:
http://cia.vc/stats/project/OpenBeOS :cool:
Speravo in qualcosina di nuova per Natale, invece nulla :D
Del resto il team Haiku non ha delle "release date" come fanno altri, ma basa i rilasci sulle feature... è pronto quando... è pronto :p
E prima della R1 la strada è ancora lunga:
http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&group=milestone&order=priority
Del resto il team Haiku non ha delle "release date" come fanno altri, ma basa i rilasci sulle feature... è pronto quando... è pronto :p
Un pò alla Debian :sofico:
trapanator
07-01-2010, 09:46
Un pò alla Debian :sofico:
beh dai, loro al massimo in 2 anni :sofico:
pabloski
19-01-2010, 12:14
le novità ci sono, ma in pieno stile haiku sono nascoste http://www.osnews.com/story/22757/Haiku_Gets_KOffice_Port :D
comunque sia stanno lavorando sullo stack wifi e sulla grafica anche se in quest'ultimo caso non vedremo nulla di concreto fino all'avvento di gallium
trapanator
19-01-2010, 12:20
le novità ci sono, ma in pieno stile haiku sono nascoste http://www.osnews.com/story/22757/Haiku_Gets_KOffice_Port :D
Quelli che lavorano al porting di QT per KDE riscontrano al momento problemi di prestazioni.
comunque sia stanno lavorando sullo stack wifi
al momento c'è già una bella lista di schede supportate.
e sulla grafica anche se in quest'ultimo caso non vedremo nulla di concreto fino all'avvento di gallium
riguardo la grafica puoi aggiornarmi?
pabloski
19-01-2010, 15:14
riguardo la grafica puoi aggiornarmi?
beh sono almeno arrivati alla conclusione che si può usare gallium e dri2 per portare i driver linux su haiku
ci sono alcune resistenze però e non tutti sono d'accordo
a livello di codice c'è un port di gallium e il winsys per haiku che si appoggia all'infrastruttura grafica di haiku
ed è qui che molti sostengono che in fondo dri2 è fatto bene e tanto vale fare il porting
senza il porting bisognerebbe riscrivere le parti di driver che in linux implementano il drm e il kernel mode setting
Gallium l'hanno (o lo stanno...?) portato anche su AmigaOS 4.x... ;)
pabloski
19-01-2010, 21:05
Gallium l'hanno (o lo stanno...?) portato anche su AmigaOS 4.x... ;)
ho sentito che hyperion sta per lanciare l'amiga one x1000 con tanto di processore basato forse su power6 e un misterioso coprocessore della xmos
sento che il 2010 sarà un anno interessante :P
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.