BeOS/Haiku: Thread ufficiale

[hexaae]

Originariamente inviato da TTklaz

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 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...

[del_sys]

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!

[fano]

Originariamente inviato da TTklaz

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/showpo...&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

Fatemi sapere come va...
Portando l'esempio ad Haiku non credo esso gradirebbe se gli sostituisco (o cancello) libbe... penso smetterebbe di funzionare

Questo a che fare anche con quello che io chiamo "security by design"

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 )
# 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
http://www.haiku-os.org/blog/scottmc..._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

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 ...

Non ha senso per me

[wisher]

I driver indipendenti dal sistema operativo sarebbero una grandissima cosa per la diffusione dei sistemi operativi alternativi

[fano]

Già, ma a Richard Stallman non piacque e UDI fu boicottato

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?

[guyver]

Originariamente inviato da fano

Una versione semplificata di quanto avevo proposto io qui:
http://www.hwupgrade.it/forum/showpo...&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

Fatemi sapere come va...
Portando l'esempio ad Haiku non credo esso gradirebbe se gli sostituisco (o cancello) libbe... penso smetterebbe di funzionare

Questo a che fare anche con quello che io chiamo "security by design"

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 )
# 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
http://www.haiku-os.org/blog/scottmc..._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

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 ...

Non ha senso per me

magari!!!!

[$Raf$]

buongiorno a tutti
sapete se beos/haiuko supporta il modem conexant accessrunner usb?
nel caso sia compatibile esiste una guida su come configurarlo?

[pabloski]

credo proprio di no...quel modem ha dato rogne per anni su linux, figuriamoci se si sognano di portare i driver su haiku

[$Raf$]

Originariamente inviato da pabloski

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]

Originariamente inviato da $Raf$

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

[fano]

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

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

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 ( ) inutile dirvi che su un 46" non è il massimo...
Forse mi serve questa:
http://www.bebits.com/app/1401
ma, ovviamente, il link è rotto

Attaccando l'HDMI da solo posso almeno selezionare 1280*720 @60 Hz, 1920*1080 il log dice che non è supportato e invece lo è

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 e non ho avuto il coraggio di tentare i 120 Hz (il mio HDTV dovrebbe avere il controllo... e non esplodere però )

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 )

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

Fosse facile, eh?

[fano]

Bundle o non bundle?

Sembra di sì
http://dev.haiku-os.org/wiki/PackageManagerIdeas

che bello

[trapanator]

Originariamente inviato da fano

Forse mi serve questa:
http://www.bebits.com/app/1401
ma, ovviamente, il link è rotto

Dalla R2 questi driver saranno inutili, visto che sarà tutto compilato con GCC4.

[trapanator]

Originariamente inviato da fano

Bundle o non bundle?

Sembra di sì
http://dev.haiku-os.org/wiki/PackageManagerIdeas

che bello

In sostanza come su Mac e BSD

[gash]

Vogliono usare libalpm, che è la libreria che sta dietro a pacman, Arch rulez!!!!!!!
http://dev.haiku-os.org/wiki/Package...rIdeas#libalpm
http://stud4.tuwien.ac.at/~e0725517/...-haiku.log.txt

[fano]

Originariamente inviato da trapanator

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:

1. I 2 schermi devono avere la stessa risoluzione e siccome uno è 4:3 vanno a 800*600
2. 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à

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

Vabbeh almeno sono riuscito a veder qualcosa con la VGA il ticket si può chiudere... il DualHead è un di più
Magari è più corretto che ne apra un altro...

Originariamente inviato da trapanator

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
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

@hexaae un'altra ipotesi è copiare da AMIGA
http://www.freelists.org/post/haiku-...re-and-assigns

[hexaae]

Originariamente inviato da fano

@hexaae un'altra ipotesi è copiare da AMIGA
http://www.freelists.org/post/haiku-...re-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, 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! ) dovrebbe trarre molta più ispirazione da Amiga che dal mondo Unix, cosa che BeOS saggiamente per dichiarazione dello stesso Gassé intendeva fare...

[fano]

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

[TTklaz]

Originariamente inviato da fano

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

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

[hexaae]

Originariamente inviato da TTklaz

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

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...