BeOS/Haiku: Thread ufficiale

[submax]

Originariamente inviato da trapanator

Occhio che OpenOffice per funzionare non ha bisogno delle JDK.

ok ma se portano le JDK dovrebbero portare anche la JRE o mi sbaglio?

[trapanator]

Originariamente inviato da submax

ok ma se portano le JDK dovrebbero portare anche la JRE o mi sbaglio?

certo.

[submax]

Ma a che stato è il supporto alla WPA per il wifi e relativa interfaccia di configurazione ?

non ci sono state più news a riguardo...

[submax]

Originariamente inviato da submax

Ma a che stato è il supporto alla WPA per il wifi e relativa interfaccia di configurazione ?

non ci sono state più news a riguardo...

?????

[Slayer86]

Seganlo la recensione di Haiku r1 alpha 2 su pollycoke.org
LINK
Sempre interessante leggere le opinioni di felipe!
Ho da poco scoperto haiku e non ho ancora intenzione di provarlo! Però diciamo che se il progetto procede sono felice...

[Tanner]

Ma basta che installi virtualbox in Ubuntu o usi Qemu in Windows per provarlo, questione di 10 minuti... Fai un tentativo vale la pena!

p.s. ammazza quante pagine il topicuzzo su Haiku 5 anni di reply

[Slayer86]

è tornato Tanner?????


sisi immgaino ci vogliano 5 minuti... e prometto che lo farò appena avrò 5 minuti liberi!
Ora sto facendo la tesi!

[BeBarrett]

Tanner è una vita che non ti fai vivo! Ai tempi dell'itbug eri uno degli utenti più attivi! Spero tu possa tornare a partecipare su haiku-it : )

Comunque Haiku Italia ha bisogno di aiuto, se volete sostenere il progetto, una piccola donazione è il massimo :
http://www.haiku-os.it/?q=node/789
Inoltre cerchiamo persone disposte ad aiutarci con la documentazione e gli articoli!

[guyver]

nettop compatibile haiku alpha2 al 100% ?
quali?

[Kanon]

Microsoft ha comprato Novell, o almeno la parte che più riguarda Unix.

Tra il catastrofismo generale che si sta facendo nell'universo *nix, pensavo... Haiku sarà completamente immune da questa faccenda vero?


PS: era per uppare il thread che mi pare sia andato in letargo ultimamente

[pabloski]

haiku non è unix, poi è chiaro che se dovesse prendere piede i troll di redmond comincerebbe a spargere fud pure su haiku

del resto il bello della legge è che puoi denunciare chiunque senza avere a priori uno straccio di prova in mano.....tanto i processi sono lunghi e costosi e solo chi c'ha i soldi da buttare può permetterseli

e meno male che i cittadini sono tutti uguali di fronte alla legge

[hexaae]

Mah... credo che buona parte del codice (già) circolante sotto GPL sia cmq al sicuro anche in questi casi...
Haiku continuerà semplicemente ad usare, se necessario, quel codice libero.
Sono curioso invece di vedere come reagirà Canonical che da domani rischia di doversi rimboccare le maniche più che in passato, magari accollandosi gran parte dello sviluppo per "staccarsi" da eventuali bastoni fra le ruote messi da MS...

[pabloski]

canonical si è buttata su gnome e gnome su mono e logicamente ne viene fuori una bella frittata

è strano che gli stessi dirigenti di canonical qualche mese fa hanno ventilato l'ipotesi di passare a kde....chissà che ne verrà fuori, speriamo bene

comunque la faccenda dei brevetti è ormai arrivata al limite del ridicolo, mi chiedo quel presidente dalla risata facile se e quando ha intenzione di cambiare le regole

[fano]

Se andate ogni tanto a vedere nella Home di Haiku avrete il piacere di scoprire 3 cose:

1. C'è stato una specie di referendum tra gli user su quello che "blocca" R1
2. Dicono che la cosa più bloccante è l'assenza di un package manager ( ) boh a me blocca il fatto che non si senta l'audio...
3. ... e quindi hanno deciso di pagare qualcuno per portare da Linux un package manager

Come vedete l'opposizione è stata fortissima 180 risposte!
Ma ormai sembra tardi... la decisione è presa!

Io non riesco davvero a capire perchè copiare una strada che dimostrato su Linux di NON funzionare

Son tanto belli i bundle della Apple... ci clicco sopra e vanno li copio in Application e li ho belli che installati... cosa c'è di più semplice?

Mi dicano ehh, ma se poi un'applicazione usa QT debbo mettercelo dentro (sì le applicazioni che usano QT su Apple fanno così... e se ne battono la ciolla) e diventa un mostro di 190 MB... poi installo un'altra applicazione QT e ottengo di nuovo una belva di 190 MB...

Certo uno potrebbe condividere le lib... ma se poi a seguito di un aggiornamento una delle 2 smette di funzionare senza alcun motivetto?

Sì abbiamo risparmiato 190 MB, ma ora una delle 2 applicazioni (se sono fortunato, magari non va nessuna delle 2 ) che avevo installato non va più...

Poi sto concetto incasinato di packageFS... ti monto a runtime mentre sei distratto...

Sapete che cos'è un Apple bundle? Dopo un'estenuante ricerca scopro che è... rullo di tumburi.... una directory!
http://developer.apple.com/library/m...123i-CH100-SW1

Semplicemente lì metti tutto quello che serve all'applicazione per girare (il binario ovviamente, risorse, librerie...) per forza che va ovunque

Non so mi pare che ci sia un po' troppo emozionati... Haiku non deve copiare Linux, ma Apple!

Se ho il package manager, upgrade che mi spaccano le applicazioni, dependency hell... beh allora continuo con il mio XP (pensavate che avrei detto uso Linux, vero? Ve lo scordate )

[pabloski]

concordo sul fatto che ci sia bisogno di tutt'altro e non certo di un package manager

però non capisco perchè dici che quel metodo è stato fallimentare su linux....apple aveva quei bei pacchetti dmg, ma qualche giorno fa sono passati all'appstore e ai package manager

ms farà lo stesso con windows 8, in pratica stanno tutti passando ai repository

Mi dicano ehh, ma se poi un'applicazione usa QT debbo mettercelo dentro (sì le applicazioni che usano QT su Apple fanno così... e se ne battono la ciolla) e diventa un mostro di 190 MB... poi installo un'altra applicazione QT e ottengo di nuovo una belva di 190 MB...


Certo uno potrebbe condividere le lib... ma se poi a seguito di un aggiornamento una delle 2 smette di funzionare senza alcun motivetto?

questo è uno dei problemi dei dmg, cioè le dimensioni assurde e l'occupazione di disco

riguardo i problemi di retrocompatibilità, beh, se certi programmatori la smettessero di essere psicotici si risolverebbero....prendi kde, ogni tre per quattro stravolgono tutto e mi ritrovono con kmail inavviabile perchè a qualcuno gli è parso opportuno di eliminare una funzione da kdelibs

il problema di certi programmi non sono le librerie condivise ma la scarsa cultura della retrocompatibilità

Se ho il package manager, upgrade che mi spaccano le applicazioni, dependency hell... beh allora continuo con il mio XP (pensavate che avrei detto uso Linux, vero? Ve lo scordate )

il dependency hell è praticamente irrisolvibile e windows ne afflitto come gli altri, con l'unica differenza che lì è tutto ufficiale, l'api viene freezata all'istante X, fanfare a tutto spiano, si mette in commercio il software e si pubblica l'API

poi ovviamente che c'è stato bisogno di riscrivere un mare di software da xp a vista a loro non frega nulla

[hexaae]

Veramente il "DLL dependency hell" su Win è risolto dai tempi di XP con il servizio SideBySide (quella cosa strana in C:\Windows\WinSxS, sapete...) che in pratica permette all'utente di ignorare le dipendenze: le applicazioni hanno un manifest all'interno che ne definisce (se necessario) l'esatta versione di dll da usare, che verrà pescata da WinSxS dove vengono messe in realtà fisicamente tutte le versioni che l'utente installa (che finirebbero per sovrascrivere ogni volta quella in System32). È poi l'OS che si cura quindi di far caricare al programma la "giusta" DLL, se quella condivisa (solitamente l'ultima versione.revisione) non va bene e viene espressamente richiesta nel manifest una certa DLL. Questo fa crescere la dir WinSxS ma evita un sacco di problemi e rischi di dipendenze e sovrascritture e in sintesi per l'utente è la soluzione migliore: si hanno a disposizione sia lib condivise per risparmiare risorse, che se necessario specifiche versioni per specfici eseguibili. Infine Windows è in grado di utilizzare la libreria presente nella homedir del programma lanciato, se si volesse forzare in modo molto semplice l'uso di una certa versione.
C'è molta (totale?) disinformazione su Windows, che con tutti i suoi difetti, certe cose non le fa malissimo....

IMHO la semplice e pulita soluzione AmigaOS cmq è teoricamente la migliore in assoluto: niente dependency, semplicemnte una libreria contiene tutte le API vecchie insieme alle nuove. La responsabilità si sposta sul prorammatore della libreria che deve creare nuove funzioni (es. VecchiaApriFile() insieme alla nuova NewApriFile(), preferibile. Deprecata la vecchia che nel tempo sparirà dall'uso nei programmi e quindi verrà eventualmente rimossa anche dall'autore/i della libreria quando sarà opportuno). Su HD mantieni un solo e unico file in LIBS: (SYS:Libs/) sebbene ingrassi un po' col tempo finché non si decide di tagliare col passato (non ha senso supportare app di 10 anni fa).... ma su Amiga si può fare perché la comunità è più unita e c'è Aminet da prima che nascesse Linux (diciamo il proto-repository globale di riferimento). In realtà AmigaOS permette anche di forzare l'uso di una lib specifica leggendola direttamente da una sua sottodirectory PROGDIR:libs (PROGDIR: su AmigaOS è un device logico virtuale e riferito alla homedir del programma avviato), nel caso sia presente e non già condivisa (è possibile flushare dalla memoria quella condivisa una volta chiusa da tutti i programmi anche con un semplice comando da shell). Su Linux con 100000 fork e spin off è un caos totale, ragion per cui è nata la (IMHO molto criticabile) soluzione dei package manager per cercare di fare ordine mantenendo la gerarchia std del fs tipica degli *nix...

Perché prendere il peggio dall'onnipresente Linux? Non lo so, peccato....

[fano]

Già assolutamente un peccato... io su Windows non ho mai avuto depency hell quindi... raccontante frescacce, dai
Su MacOSX beh per la stessa definizione dei bundle non può proprio succedere...

Ora spiegatemi qual è il vantaggio di tutto sto bordello, OK per un'applicazione QT che magari mi diventa di 190 MB o OpenOffice con Java dentro, ma perchè Firefox mi deve sostituire una libreria condivisa rischiando di spaccare tutto il resto? Lasciategli dentro di se ste lib e buona notte, no?
Mi ci vuole un bestio che frulla per ora per installare un'applicazione per cosa, poi? Uhh ho risparmiato 20 MB?
Wow

@hexaae sinceramente più che il "sistema Amiga"... a me le librerie hanno insegnato a farle così... peccato che poi tutti gli altri le rendano incompatibili ogni 2 per tre... OK aggiunge nuove funzionalità, ma perchè toglierle?

Una nuova versione di libreria non compatibile con la precedente è un ossimoro.

Boh del resto in Linux questo si applica a tutto Kernel, Gnomi e sarc@zzi questo significa che ogni volta che si upgrada l'OS tutte le applicazioni (e peggio i driver) vadano ricompilati...

Speriamo che non si arrivi anche a questo in Haiku certo avere il PM potrebbe anche incoraggiare questo... tanto ormai è Linux al 75%... manca poco

P.S. per inciso ho scoperto di aver scaricato tempo fa bsnes 0.70 tempo fa (per Windows ovviamente):

1. E' portabile nel senso che la decomprimo dove mi pare, clicco 2 volte sopra e funziona... non sputtana il registro nè sparge dll per il sistema come fosse antani
2. E' un'applicazione QT
3. ... ci sono tante DLL, 2 hanno chiaramente QT nel nome... altro che 180 MB... son 3 MB

Quindi in totale BSNES occupa la fantastica dimensione di.... 10 MB, e quindi devo rompermi gli zibedei per risparmiare 3 MB? Non so se sul povero Linux quelle 2 DLL occupa centinai di MB... o su OSX, ma sinceramente ne dubito... quindi ci stianmo emozionando per questo?
Se ne "installassi" centinaia avrei sprecato 300 MB... ma avrei anche installato 100 applicazioni!

Direi un'immagine parla più di mille parole, come sempre:

[hexaae]

Beh mi sembra la strada più semplice, logica ed elegante.... e mantieni pure la rigidità della gerarchia del fs! Basta solo una "style guide" a cui attenersi da parte dei programmatori, e... fine delle dependency hell che affliggono Linux e che hanno dato vita per necessità ai package manager e che ogni utente Linux propone come la soluzione (più complicata e rischiosa per la stabilità complessiva) migliore del mondo!
Forse perché non conoscono bene gli altri sistemi operativi e a loro sembra così intelligente e logica? In pratica un demerito che diventa paradossalmente una virtù ("...perché così con un semplice apt-get aggiorni anche tutte le lib e stai sicuro", ignorando l'esistenza di rischi, potenziali problemi e incompatibilità, forzando la ricompilazione di diverse applicazioni e parti dell'OS, ma attenzione! "Automaticamente", quindi va bene ed "è la migliore")!
Non lo capirò mai, visto che ci sono modelli e idee migliori senza le restrizioni imposte dai dogmi Linux...

Nel caso specifico, Haiku poteva benissimo evitare e adottare la prima soluzione, la soluzione dei bundle (che però ingrassa l'HD e non permette l'intelligente concetto di librerie condivise) o persino quella alla Windows che cmq mi sembra più logica e lineare ma sopratutto sgravano completamente l'utente dai rischi e problemi, creando poi un sistema di auto-update con database centralizzato.

[trapanator]

Originariamente inviato da fano

Già assolutamente un peccato... io su Windows non ho mai avuto depency hell quindi... raccontante frescacce, dai

Io sì e TANTE VOLTE, mentre su Linux (che uso da una vita)... mai.

Su MacOSX beh per la stessa definizione dei bundle non può proprio succedere...

E neanche su *BSD (da cui deriva MacOSX, per l'appunto). Ma teoricamente anche su Linux: basta compilare in modo statico, e il compilatore "infila" le librerie necessarie dentro l'eseguibile e lo puoi "portare" in giro (ovviamente rispettando l'architettura)

[hexaae]

Originariamente inviato da trapanator

Io sì e TANTE VOLTE, mentre su Linux (che uso da una vita)... mai.

Spiega come e quando hai avuto problemi di dll dependency hell con Windows che da XP in poi gestisce la cosa tramite il SideBySide. Forse su Win 2000 e precedenti....