BeOS/Haiku: Thread ufficiale

[Slayer86]

Originariamente inviato da hexaae

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

[TTklaz]

Originariamente inviato da hexaae

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

[hexaae]

Originariamente inviato da TTklaz

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

[fano]

Una libreria dovrebbe essere sempre retrocompatibile peccato purtroppo sta cosa dai tempi di AMIGA si sia un po' persa

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 "

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

[hexaae]

Originariamente inviato da fano

Una libreria dovrebbe essere sempre retrocompatibile peccato purtroppo sta cosa dai tempi di AMIGA si sia un po' persa

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 "

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

Ma tanto già lo so come finisce... dannata l'influenza del pinguino che sta rovinando l'informatica libera (eh eh)!

[fano]

Speriamo di no... considero Haiku l'ultima speranza... non voglio più usare Windows

Carina l'immagine del pinguino borghizzato

[hexaae]

Originariamente inviato da Slayer86

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

[guyver]

Originariamente inviato da fano

Una libreria dovrebbe essere sempre retrocompatibile peccato purtroppo sta cosa dai tempi di AMIGA si sia un po' persa

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 "

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

[fano]

Infatti... personalmente non ci vedo nulla di male in questo

Piuttosto che incasinarsi con package manager incasinati e conflitti

[pabloski]

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

[fano]

Originariamente inviato da pabloski

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

Originariamente inviato da pabloski

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?

Originariamente inviato da pabloski

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

[TTklaz]

Originariamente inviato da fano

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

[fano]

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

[ezln]

Originariamente inviato da fano

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

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

[trapanator]

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.

[fano]

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

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

[M4rk191]

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?

[TTklaz]

Originariamente inviato da M4rk191

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

[fano]

Anche con VMware... non so se VirtualBox sia molto supportato al momento

Magari prova con VMware (il player è gratis e ci sarà anche per MAC).

[TTklaz]

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