HP promette maggior supporto all' open source [Archivio]

jappilas

01-06-2004, 18:48

Originariamente inviato da KAISERWOOD
ogni anno sento dire la stessa cosa, penso che fra 20 anni la situazione sarà la stessa :rolleyes: :cry: :(

dipende quale "panorama" vi piace di più ...
1) tutto il mondo usa linux
2) linux rimane per (relativamente) pochi "eletti" appassionati, e i server

caso 1) tutto il mondo vuol dire *TUTTI* , compresi i bambini di 5 anni e i pensionati di 70 (che magari in 40 anni di vita lavorativa in ufficio hanno sempre visto sistemi MS...)
il che vuol dire che Linux deve diventare come Win e oltre Win... dalla GUI al kernel, passando per le società che su di esso sono vissute e continueranno a vivere, le quali finiranno per assomigliare sempre di più a M$ (d' altra parte non è che fossero fondazioni senza scopo di lucro)

però ci sarà bisogno di grandi cambiamenti e del coraggio di rinnovare un tantino la codebase... perchè per far diventare linux il nuovo Winzozz è necessario modificare alcune cose di base... attualmente alcuni dettagli d' implementazione mi sembrano semplici tapulli.... :rolleyes:

caso 2) Linux rimane così com'è ora, anzi magari in futuro lo si farà tornare allo spirito originario di spartanità e semplicità per distinguerlo definitivamente da altri sistemi operativi che a quel punto saranno diventati (se possibile) ancora più "dummy oriented" ...
abbandonando così ogni speranza di conquistare il mondo, ma rimenendo nel cuore di un' elite di esperti, che non vedrà il suo affezionato OS stravolto e snaturato...

Kralizek

01-06-2004, 18:59

jappilas... potresti spiegarmi quali sono i dettagli che vorresti cambiare al caso 1?

HexDEF6

01-06-2004, 19:01

jappilas

01-06-2004, 19:19

Originariamente inviato da Kralizek
jappilas... potresti spiegarmi quali sono i dettagli che vorresti cambiare al caso 1?

alcune cose che a voialtri sembreranno banali, da ignorante o fuori luogo...
per es spostamento dal paradigma "tool/ modulo command line + front end che gli prepara una riga di comando"
a quello "programma che chiama una funzione esterna in una libreria"
spostare la console in una applicazione
IPC tramite messaggi almeno per l' esecuzione in locale (io resto convinto che usare il sistema client server X11 per applicazioni locali, sia un' aberrazione)
...
...
...

Ikitt_Claw

01-06-2004, 19:21

Originariamente inviato da jappilas
(io resto convinto che usare il sistema client server X11 per applicazioni locali, sia un' aberrazione)

Vai con i dettagli.

Ikitt_Claw

01-06-2004, 19:23

Originariamente inviato da jappilas
dipende quale "panorama" vi piace di più ...
1) tutto il mondo usa linux
2) linux rimane per (relativamente) pochi "eletti" appassionati, e i server

3) la naturale evoluzione di Linux porta ad avere un'allargamento della base di utenti, senza per questo mendicare visibilita` ne`, peraltro, intaccare fortemente il monopolio windows.
Diciamo una cosa tipo 70% windows 20%linux 5% mac 5% altri.

abbandonando così ogni speranza di conquistare il mondo, ma rimenendo nel cuore di un' elite di esperti, che non vedrà il suo affezionato OS stravolto e snaturato...

Detta cosi` e` un tantinello parziale ;)

ilsensine

01-06-2004, 20:49

Originariamente inviato da jappilas
alcune cose che a voialtri sembreranno banali, da ignorante o fuori luogo...
per es spostamento dal paradigma "tool/ modulo command line + front end che gli prepara una riga di comando"
a quello "programma che chiama una funzione esterna in una libreria"
spostare la console in una applicazione
IPC tramite messaggi almeno per l' esecuzione in locale (io resto convinto che usare il sistema client server X11 per applicazioni locali, sia un' aberrazione)

Potresti spiegarti meglio?

jappilas

01-06-2004, 21:45

... avevo la sensazione che avrei sollevato un po' di polvere...
premettendo che non volevo nè sembrare di parte nè scatenare flame e che ogni mio post contiene mie idee "malate"...

allora: dal basso di quello che ho visto finora, una libreria ( "DLL" ) dovrebbe essere una raccolta di funzioni esportate, più una tabella , contente gli indirizzi (o magari offset) a cui tale funzioni vengono allocate in memoria : un programma che ha bisogno di una funzione chiede all' os di caricargli la DLL che la contiene, se questa non è ancora allocata, si vede a che address inizia la routine e si fa una jump ...
(a grandi linee e se non toppo da qualche parte)

ma cmq mi pare un meccanismo più ... anche solo elegante per realizzare programmi in più componenti...
più di un frontend che interagisce con un eseguibile che gira in background, passandogli gli stessi comandi che potrei immettere a mano da console...
e infatti nato (il frontend) per riciclare quell' eseguibile anche in ambiente grafico ... se mi sembra un "tapullo" non ci posso fare nulla... :p

console: in un OS per desktop, secondo alcuni la strada migliore sarebbe integrare il più possibile la UI, almeno i suoi componenti di basso livello, col kernel ...
se si volesse far prendere questa strada a linux, implicherebbe operare scelte di (re)design a livello medio/basso: ad es si potrebbero relegare alcune cose in "servizi" e utilities, ad esempio i desktop remoti e ottimizzare la UI per il locale
la virtualizzazione data dal protocollo X11 sarebbe superflua, utilizzando una DLL o un server a messaggi si "dovrebbe " risparmiare l' overhead indotto (secondo come me lo hanno spiegato) dall' uso dei socket
e la CLI in una finestra/desktop, come atheos e amiga, oltre che su win...

ilsensine

01-06-2004, 21:53

Originariamente inviato da jappilas
... avevo la sensazione che avrei sollevato un po' di polvere...
Affatto, chiedevo seriamente il tuo parere.

allora: dal basso di quello che ho visto finora, una libreria ( "DLL" ) dovrebbe essere una raccolta di funzioni esportate, più una tabella , contente gli indirizzi (o magari offset) a cui tale funzioni vengono allocate in memoria : un programma che ha bisogno di una funzione chiede all' os di caricargli la DLL che la contiene, se questa non è ancora allocata, si vede a che address inizia la routine e si fa una jump ...
(a grandi linee e se non toppo da qualche parte)
Quello che su windows si chiama ".dll" (dynamic link library) sotto linux si chiama ".so" (shared object). Sono sostanzialmente la stessa cosa, se non per il fatto che su linux è più facile farli e utilizzarli. Sì, esistono in abbondanza e vengono usati comunemente. Cosa c'è che non va?

ma cmq mi pare un meccanismo più ... anche solo elegante per realizzare programmi in più componenti...
più di un frontend che interagisce con un eseguibile che gira in background, passandogli gli stessi comandi che potrei immettere a mano da console...
Sì sotto linux si usano i pipe per questo, che sono molto più flessibili che su windows. E' comune anzi che un programma ne controlli un altro tramite pipe, come se l'utente lo stesse utilizzando da tastiera. Semplice da programmare, flessibile da usare. Ancora, cosa c'è che non va in questo?

console: in un OS per desktop, secondo alcuni la strada migliore sarebbe integrare il più possibile la UI, almeno i suoi componenti di basso livello, col kernel ...
Non è una buona scelta. Dubito fortemente che gli oggetti GUI di windows girino in kernel space.

la virtualizzazione data dal protocollo X11 sarebbe superflua, utilizzando una DLL o un server a messaggi si "dovrebbe " risparmiare l' overhead indotto (secondo come me lo hanno spiegato) dall' uso dei socket

Mai sentito parlare di xShm? (X shared memory)

Ikitt_Claw

02-06-2004, 08:03

Originariamente inviato da jappilas
[cos'e` una dll]
(a grandi linee e se non toppo da qualche parte)
Come detto, ci sono anche su Linux e vengono usate in gran copia, a volte anche troppo (!!)

e infatti nato (il frontend) per riciclare quell' eseguibile anche in ambiente grafico ... se mi sembra un "tapullo" non ci posso fare nulla... :p
In certi casi (vedi alla voce cdrecord) sarebbe stato indubbiamente piu` elegante avere una libreria condivisa e due front-end, uno testuale e uno grafico; Ma questa situazione non e` poi cosi` comune, considerando che
estrarre la parte "di libreria" da un progetto -magari nato per essere usato da linea di comando- non e` cosi` banale, e a volte puo` implicare riscrittura totale o parziale. Benissimo, si puo` fare, ma e` una cosa da pianificare nel lungo termine, e si introducono una selva di bug (inevitabile) senza peraltro migliorare significativamente l'uso del programma. E questo, oltretutto, non ha senso farlo per _tutti_ i programmi pilotati via pipe da un frontend.

Ma, a conti fatti, all'utente finale che glie frega se il programma e` pilotato via pipe o se ha due frontend nativi che usano la stessa libreria?
La pipe non e` piu` lenta, e il frontend puo` essere ugualmente integrato bene in un eventuale desktop.

console: in un OS per desktop, secondo alcuni la strada migliore sarebbe integrare il più possibile la UI, almeno i suoi componenti di basso livello, col kernel ...

E perche`?

si potrebbero relegare alcune cose in "servizi" e utilities, ad esempio i desktop remoti e ottimizzare la UI per il locale

Questo vuol dire riscriverla da zero, praticamente, e doverne usare due diverse una per il remoto e una per il locale...

la virtualizzazione data dal protocollo X11 sarebbe superflua, utilizzando una DLL o un server a messaggi si "dovrebbe " risparmiare l' overhead indotto (secondo come me lo hanno spiegato) dall' uso dei socket

Il server X in locale usa una marea di sporchi trucchi per velocizzare le operazioni...
Comunque, se gli sviluppi sul server X saranno quelli promessi (e sono tanti e interessanti), una buona parte delle critiche mosse al suddetto andranno a sparire, credo. XFree86 risente della sua eta`, e ha vari problemi noti.

e la CLI in una finestra/desktop, come atheos e amiga, oltre che su win...

La CLI si intravede per una manciata di secondi all'avvio e poi volendo mai piu`, se uno e` terrorizzato anche da quei momenti si puo` mettere una schermata grafica a mascherarli...

jappilas

02-06-2004, 16:50

Originariamente inviato da Ikitt_Claw
Come detto, ci sono anche su Linux e vengono usate in gran copia, a volte anche troppo (!!)

ok tanto meglio ;)

In certi casi (vedi alla voce cdrecord) sarebbe stato indubbiamente piu` elegante avere una libreria condivisa e due front-end, uno testuale e uno grafico; Ma questa situazione non e` poi cosi` comune, considerando che
estrarre la parte "di libreria" da un progetto -magari nato per essere usato da linea di comando- non e` cosi` banale, e a volte puo` implicare riscrittura totale o parziale. Benissimo, si puo` fare, ma e` una cosa da pianificare nel lungo termine, e si introducono una selva di bug (inevitabile) senza peraltro migliorare significativamente l'uso del programma. E questo, oltretutto, non ha senso farlo per _tutti_ i programmi pilotati via pipe da un frontend.

Ma, a conti fatti, all'utente finale che glie frega se il programma e` pilotato via pipe o se ha due frontend nativi che usano la stessa libreria?
La pipe non e` piu` lenta, e il frontend puo` essere ugualmente integrato bene in un eventuale desktop.

che all' utente normale non gliene freghi sono d' accordo ;)
ma purtroppo la mia mente ottenebrata non riesce a trascurare dettagli di questo genere e sottilizza, nella convinzione che fossero necessari cicli cpu in più per parsare il comando ricevuto sulla pipe ...

E perche`?
Questo vuol dire riscriverla da zero, praticamente, e doverne usare due diverse una per il remoto e una per il locale...

ma forse (secondo quello che mi immaginavo) si eviterebbe un po' di ridondanza e occupazione di memoria usando solo quella che serve in un certo momento... o forse no..

Il server X in locale usa una marea di sporchi trucchi per velocizzare le operazioni...
Comunque, se gli sviluppi sul server X saranno quelli promessi (e sono tanti e interessanti), una buona parte delle critiche mosse al suddetto andranno a sparire, credo. XFree86 risente della sua eta`, e ha vari problemi noti.

ma sono appunto trucchi, quelli che in america chiamano "hacks", che si agiungono via via a un sistema che ritenevo potesse essere un po' snellito...

La CLI si intravede per una manciata di secondi all'avvio e poi volendo mai piu`, se uno e` terrorizzato anche da quei momenti si puo` mettere una schermata grafica a mascherarli...

per me non è l' essere terrorizzato, è sempre una questione di pulizia, omogeneità e modernità ;)

Ikitt_Claw

02-06-2004, 17:00

Originariamente inviato da jappilas
ma purtroppo la mia mente ottenebrata non riesce a trascurare dettagli di questo genere e sottilizza, nella convinzione che fossero necessari cicli cpu in più per parsare il comando ricevuto sulla pipe ...

Certo che e` cosi`, alla fine ci sono due passaggi di trasformazione delle informazioni in piu` (programma -> human readable -> frontend).
Ma questo e` un problema? Ed e` SEMPRE un problema?

ma forse (secondo quello che mi immaginavo) si eviterebbe un po' di ridondanza e occupazione di memoria usando solo quella che serve in un certo momento... o forse no..
Ridondanza: non ne vedo. Occupazione di memoria: dipende, i toolkit grafici sono gia` da soli l'hotspot in questo senso...

ma sono appunto trucchi, quelli che in america chiamano "hacks",
Ottimizzazioni ;)

che si agiungono via via a un sistema che ritenevo potesse essere un po' snellito...
Qui bisogna passare ad essere piu` circostanziati, altrimenti si finisce a parlare del sesso degli angeli ;)
Comunque: sulla network transparency inizia a premerci anche microsoft (hai visto mai?), rinunciarvi proprio adesso in nome di non meglio specificati benefici non mi pare granche furbo...

per me non è l' essere terrorizzato, è sempre una questione di pulizia, omogeneità e modernità ;)

Tutte cose che non vedo come possano essere danneggiate dall'esistenza di un layer CLI cui, eventualmente, si sovrappone un layer GUI.
Vedere il gestore grafico come un programma (poco piu` privilegiato) non e` forse un'aumento di omogeneita`?
Il discorso sulla pulizia e la modernita` mi sfuggono invece completamente.

ilsensine

02-06-2004, 19:51

Originariamente inviato da jappilas
ma sono appunto trucchi, quelli che in america chiamano "hacks", che si agiungono via via a un sistema che ritenevo potesse essere un po' snellito...

No non sono hacks, sono diverse modalità, ognuna con vizi e virtù.
XFree ha tanti difetti, ma anche tanti pregi. Non è un sw nato dall'oggi al domani, e direi che fa egregiamente il suo lavoro. La sua spesso sbandierata lentezza è un fake: un wm può essere molto pesante, ma di per se xfree sa essere molto veloce.

ilsensine

02-06-2004, 20:10

Originariamente inviato da jappilas
ma purtroppo la mia mente ottenebrata non riesce a trascurare dettagli di questo genere e sottilizza, nella convinzione che fossero necessari cicli cpu in più per parsare il comando ricevuto sulla pipe ...

Premesso che:
- soluzioni con librerie condivise sono anch'esse usatissime (io stesso una volta ho usato le librerie di xine -- non il _programma_ xine -- per fare un piccolo decoder divx)
- fare il parsing di una stringa utilizza pochissime risorse del processore
vedo che ti sfugge il piccolo punto fondamentale: la possibilità (non l'obbligo) di utilizzare e controllare programmi tramite altri programmi, con una flessibilità tipica dei sistemi unix che non ha pari nei sistemi win32. Ah certo, lì si sono inventati gli activeX per questo, ma...cosa dicevi a proposito di cicli CPU? :D
Cmq a parte gli scherzi: utilizzare un programma tramite un altro spesso è conveniente, per molti motivi. Non ha impatti significativi sulla velocità di esecuzione, ed è molto flessibile. Anzi, molti programmi ti lasciano scegliere il programma "plugin" da utilizzare per compiere una determinata operazione (ad es. rippare un cd), in modo che puoi usarne di particolari non previsti dal programmatore dell'interfaccia. Il tutto senza obbligare a fornire librerie con particolari formati, ecc.
Le librerie sono convenienti (e usate) soprattutto quando l'interazione tra i due programmi è particolarmente complessa (ad es. accesso a un database, ecc.)