BeOS/Haiku: Thread ufficiale

[PatchWorKs]

Originariamente inviato da pabloski

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

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]

Originariamente inviato da PatchWorKs

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

[Mory]

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

[fano]

Penso anch'io così... infondo è quello che fa più meno APPLE e mi pare funzioni egregiamente

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

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 ( ) yum... non ha --force!!! ... e allora usiamo RPM --force e speriamo che man non abbia dipendenze se no le deve risolvere a mano

Ciò vi rendete conto? "man" ha un conflitto

[TTklaz]

Originariamente inviato da Mory

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]

Originariamente inviato da fano

Penso anch'io così... infondo è quello che fa più meno APPLE e mi pare funzioni egregiamente

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

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 ( ) yum... non ha --force!!! ... e allora usiamo RPM --force e speriamo che man non abbia dipendenze se no le deve risolvere a mano

Ciò vi rendete conto? "man" ha un conflitto

e se una libreria ha un bug di sicurezza, che si fa? aggiorniamo tutti i pacchetti che usano quella libreria?

[Mory]

Originariamente inviato da trapanator

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]

Originariamente inviato da Mory

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]

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

[hexaae]

Originariamente inviato da Slayer86

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.

[wisher]

Qualcuno l'ha testato su PC vecchi (Io ho ad esempio un Pentium II su cui forse potrei fare qualche prova)

[fano]

Originariamente inviato da hexaae

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

/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

[Slayer86]

Originariamente inviato da fano

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

/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

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

[fano]

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 ) senza le dipendenze potrei anche accettarlo anche se nulla batte il sistema di copiare il programma in una cartella alla APPLE per certi versi

[hexaae]

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.

[fano]

Originariamente inviato da hexaae

Linux e Windows NON sono buoni esempi e sono "dinamici" quanto un elefante molto stupido.

OK, ma io solo questi esempi vedo

... e non mi pare funzioni granché come dici anche tu

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

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
2) ... quindi si deve usare il terminale (e già mi incazzo )
3) ravana per ora scaricando migliaia di file e calcolando dipendenze su dipendenze
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 ) e orrore: non va più il syntax highlighting, il soft tab e tutte le varie personalizzazioni sono andate perse

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

[pabloski]

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

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]

Originariamente inviato da fano

Penso anch'io così... infondo è quello che fa più meno APPLE e mi pare funzioni egregiamente

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

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 ( ) yum... non ha --force!!! ... e allora usiamo RPM --force e speriamo che man non abbia dipendenze se no le deve risolvere a mano

Ciò vi rendete conto? "man" ha un conflitto

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.

[hexaae]

Originariamente inviato da Xemertix

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

[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