Newsgroup: it.comp.os.dibattiti
Titolo: OS stile unix: forse un po vecchio ?

Ciao a tutti.
E' da un po' di tempo che mi sforzo di utilizzare Linux la lavoro e 
differentemente da quello che ho studiato all'universita' non mi sembra 
che la filosofia unix sia vincente: forse è un po vecchia.
L'idea dei tanti programmini che si utilizzano a vicenza scolorisce 
molto di fronte alla presenza ambienti integrati come Eclipse, Open 
Office, ecc.
Effettivamente questi ambienti integrati sono molti confortevoli e molto 
piu' produttivi di tanti programmini ma il difetto e' che non riciclano 
niente di cio' che è gia' presente nel sistema. Il risultato e' una 
occupazione di memoria pazzesca.
Almeno in Windows le .dll vengono utilizzate da parecchi programmi e 
sinceramente la filosofia mi sembra piu' al passo con i tempi.
OK mi direte che in Linux ci sono i .so che fanno la stessa funzione ma 
la grande varieta' e personalizzazione di questi .so li rende poco 
riutilizzabili.
Cosa ne pensate ?

 Office, ecc.
"automazione" e' la parola chiave.
La filosofia unix rende piu' difficile, anche molto piu' difficile, fare una
cosa nuova la prima volta.
Parlo di compiti di amministrazione del pc (server) e lavoro di
programmazione e/o similia,
non della redazione di una lettera.
Poi pero' puoi automatizzare il tutto, parametrizzarlo, e tutte le N volte
successive
non dovrai fare altro che fornire i parametri al job (se ne ha) e lanciare
il batch che fa da "collante"
ai vari programmini che collaborano, e per fortuna che collaborano.
Sotto windows che prevede solo un'interfaccia grafica e' molto facile fare
una cosa la prima volta.
Poi, *se gli autori del programma non hanno pensato a qualcosa -tipo macro-*
devi perdere lo stesso tempo ogni benedetta volta che devi fare
l'operazione.
Esempio: se vuoi applicare una sequenza di filtri grafici ad un sacco di
immagini,
con linux ti fai uno script bash e lo fai, usando i piccoli programmini che
manipolano le immagini,
poi magari vuoi rinominarli tutti con un certo criterio, e poi spostarli.
Con windows forse il programma prevede una funzione per applicare una macro
ad una intera cartella di files (ma siamo gia' nelle rarita')
ma comunque ti resta il resto del lavoro manuale.

 riutilizzabili.
Esempio?
bye G.L.
-- 
« E' assolutamente evidente che l'arte del cinema
  si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)

 
Be diciamo che le librerie per il sistema grafico, per esempio, possono 
essere GTK, MOTIF, GNOME,e forse altre ognuna delle quali contiene 
svrariati .so ma tutte hanno come unico scopo quello di generare 
finestre e pulsanti.
Questo e' il primo esempio che mi viene in mente ma se vai, per esempio, 
in /usr/lib e fai un ls ti stupirai di quante sono ed e' estremamente 
improbabile che nella maggior percentuale siano utilizzate da piu' di 1 
programma (forse molte sono proprio inutilizzate).
Ciao.

 inutilizzate).
Per cui? Il problema e` che hai disco occupato? I 700MB che occupa
/usr/lib sono troppi perche` devi fare spazio ai 45GB di
film/mp3/ogg/pornazzi che scarichi? Non capisco dove stia il
problema...
A parte poi che qualsiasi distribuzione decente pulisce o fornisce un
programma per pulire le librerie non usate. E che nella stragrande
maggioranza dei casi la meta` di quello che c'e` in /usr/lib/ sono
link simbolici...
Io ho solo le GTK installate, GNOME non e` una libreria grafica (e
gia` questo lascia molto intendere cosa ne sai...).
Per windows esistono le MFC, le windows.Forms, le wxWidgets, fltk, tk,
gtk (che stupore!!! anche li`!!!) ecc ecc.
Proprio non capisco dove stia il tuo problema.
-- 
Valentino Volonghi aka Dialtone
Linux User #310274, Proud Gentoo User
Blog: 
http://vvolonghi.blogspot.com
Home Page: 
http://xoomer.virgilio.it/dialtone/

 programma (forse molte sono proprio inutilizzate).
Perche', la stessa cosa non succede anche in windows?


 gia` questo lascia molto intendere cosa ne sai...).
non coindivido per niente la posizione di andrea, ma su questo hai torto
su. Gnome ha al suo interno anche delle librerie che si basano sulle gtk,
per esempio la libgnomeui, dove sono racchiuse tutti i widget realizzati
con le gtk nel look&feel di gnome. Perché con gtk non ci fai solo gnome.

 riutilizzabili.
non è vero. La strgrande maggior parte degli so viene riutilizzato più
di un volta. Ovvio che se tu aumenti il tipo di programmi che usi devi
considerare che questi necessiteranno di più librerie, ma la situazione
è uguale a quella di qualsiasi altro sistema operativo che supporti le
librerie dinamiche.
Personalmente reputo che sostenere che unix sia vecchio per via degli so
sia assurdo, visto che per questo aspetto è uguale agli altri sistemi
operativi.

 con le gtk nel look&feel di gnome. Perché con gtk non ci fai solo gnome.
libgnomeui non e` GNOME e men che meno una libreria grafica, mancano
un po` troppi componenti per definirlo interfaccia grafica.
Sono solo template di codice GTK preconfezionati da usare per
sviluppare velocemente le interfacce grafiche di GNOME.
GNOME e` un DE, dire che e` una libreria grafica e` sbagliato.
Non esiste il look&feel di GNOME, esiste il look&feel delle GTK+ e
basta. Tali GTK+ supportano l'utilizzo di temi per skinnare la GUI e
basta. GNOME ha un suo tema di default, come altri hanno il loro tema
di default. Si tratta di roba che fa parte delle GTK+.
Con le GTK+ non ci fai solo gnome appunto, gnome usa le GTK per se
stessa ma le GTK non dipendono da gnome direttamente (in realta` gli
sviluppatori di gnome guidano e direzionano il percorso di sviluppo
delle GTK, GNOME si crea una sorta di framework partendo dalle GTK e
usando solo quelle.


 Perche', la stessa cosa non succede anche in windows?
 
Quoto. Che provi ad andare in C:\WINNT\system32 e dare un dir e vedere
quanta roba ci sia...;)
-- 
il Vide - ICQ #5301833
http://www.heavy-metal.it
Le cose che possiedi, alla fine ti possiedono. (Tyler Durden)
NP: Blind Guardian - The Script For My Requiem (AmaroK)

 quanta roba ci sia...;)
Con nomi 8.3, e con regole molto meno razionali di *nix
nel scegliere la loro denominazione. Tie'!   :-)))


 che la filosofia unix sia vincente: forse è un po vecchia.
E' vecchia come lo e' la macchina di touring , se passiamo alla macchina di
boltzmann allora vecchia saremo noi.

 sembra che la filosofia unix sia vincente: forse è un po vecchia.
Perchè mi viene in mente che all'Università hai studiato uno Unix
di 30 anni fa?
Saluti.

 operativi.
Infatti ho detto che un po' datata e' la filosofia dei "tanti 
programmini" ma ho trovato che mi ha giustificato in parte questa cosa.
Comunque sarebe bello che i grossi IDE o Office vari utilizzassero tutti 
quei programmi piu' piccoli e piu' flessibili che sono presenti di 
default in uno unix in modo da avere maggiore integrazione.
In Windows, con i programmi che seguono il modello COM (la maggior 
parte) il riutilizzo non solo delle librerie ma anche degli stessi e' 
piu' conveniente e mi sembra una filosofia che regge bene ai tempi anche 
se chiaramente tutto cio', in Windows, e' molto confuso senza una linea 
guida, legato alla compatibilita' e quindi poco promettente.

  Cosa ne pensate ?
Usa Eclipse e vivi felice.
-- 
Francesco Romani - Ikitt   (signature under [re]construction)
'A geek is someone who spends time being "social" on a computer.'
'In fact, users don't read /anything/'                         -- Joel Spolsky


Error: Keyboard not found. Press F1 to continue...

 default in uno unix in modo da avere maggiore integrazione.
Guarda che succede..
-- 
il Vide - ICQ# 5301833
http://www.heavy-metal.it
"There is no stronger drug than reality"

 Usa Eclipse e vivi felice.
:P
Credo che sia sbagliata come risposta: non è un ng di domande, ma di
discussioni. Non è che il fatto che lui usi o meno i programmi che dice
di preferire inficia sul discorso di fondo.
Cmq la strategia dei "programmini" rende molto più facile la gestione,
più snello l'aggiornamento, più automatizzabili le procedure,più facile
aumentare il numero di applicativi (mo creo un programma che usa
st'algoritmo visto che non ho il tempo materiale di mantenere un progetto
di programma di grafica) e più customizzabile il tutto laddove si usano 
standard!
-- 
Giepi The Great | Linux User #33229 | Powered By Fedora Core 1.0
Impossibile cancellare il file. Spazio su disco insufficente. Cancellare qualche file e riprovare.
(A)rgh (P)anico (F)ormatta (U)pgrada ora la tua licenza a eXPensive User!

  Credo che sia sbagliata come risposta: [...]
Lo so, ma so anche che il discorso, esteso e adeguatamente trattato,
sarebbe estremamente lungo ed estremamente fiammogeno.
Per cui, per adesso seguo il thread da osservatore...


 guida, legato alla compatibilita' e quindi poco promettente.
mmm... non riesco a capire una cosa, probabilmente perché non conosco
windows bene. Mi fai un esempio di programma che si basa su com che viene
integralmente riutilizzato da un altro programma?
E soprattuto cosa renderebbe diverso il riciclo di un programma fatto con
com rispetto al classico unix fork + exec ?

 usando solo quelle.
infatti gnome nella gerarchia delle librerie è superiore, non inferiore.
Ma se capisco bene il tuo ragionamento allora per coerenza nemmeno gtk
dovrebbe essere una libreria grafica visto che il plot lo fa gdk

 integralmente riutilizzato da un altro programma?
Per esempio puoi fare un programma che apre Excel (non necessariamente
visualizzandone l'interfaccia), riempie n fogli di calcolo, esporta il
risultato oppure lo stampa.
-- 
Faber
http://www.faberbox.com
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it. -- Brian W. Kernighan

 dovrebbe essere una libreria grafica visto che il plot lo fa gdk
Non hai capito il mio ragionamento neanche di striscio... Una libreria
grafica fornisce dei widget. La struttura di rendering puoi
considerarla parte della libreria grafica ma non e` fondamentale
perche` puoi avere diversi tipi di rendering (infatti le GTK sono
pensate per girare anche su cairo).
Cio` che crei con quei widget, per quanto complesso puo` essere al
massimo uno scheletro di interfaccia grafica, che realizzi prima per
comodita` e congruenza. Non e` una libreria grafica.


 risultato oppure lo stampa.
E dove sta la rivoluzione del riuso?
Come gia` detto, io posso fare un programma che genera jpg e passarlo
a un programma che le stampa. 
Oppure un programma che genera jpg, che le fa diventare pdf, che lo
combina in un documento pdf, che lo divide a 2 pagine per foglio, che
lo stampa.
e milioni (davvero) di altre combinazioni...


 risultato oppure lo stampa.
ah, perché sotto unix non si fa? Per esempio, leggendo nella manpage di
oofice:
OPTIONS
       These arguments are passed directly to the real  start  binary  by  the
       wrapper.
 
       -accept=
              This command line parameter provides an uno accept string to the
              office. The accept string is used to create an acceptor  thread.
 
              "socket,"  =  Uses the socket implementation to create an accep-
              tor.  Currently used by scripting clients to access the  OpenOf-
 
fice.org
 API.
socket, una bella ipc. 

 puoi skinnare xfce per essere uguale a GNOME lo dimostra).
gli oggetti di stok non sono skin!

 gli oggetti di stok non sono skin!
Attenzione, anche qua tu parli di altro credendo di parlare
dell'attuale argomento...
Look&feel significa 100 cose. Ma il look&feel delle GTK+ e` una
cosa. I look&feel di gnome e` una cosa diversa, in questo senso:
Il look&feel di una libreria grafica e` il modo in cui vengono
renderizzati i widget, come li vedi, le loro reazioni ai tuoi eventi
ecc ecc.
Il look&feel di un DE comprende anche il layout dell'applicazione ecc
ecc.
Ovviamente sono diversi, ma dato che tu parlavi di _tema_ di GNOME,
stai sbagliando. Esistono i temi delle GTK+, non di gnome, se non ti
va di capire questo, pace, mi arrendo, ma sappi che sbagli, che poi tu
non voglia capire, la cosa ha perso di interesse per me.


 E dove sta la rivoluzione del riuso?
Ehi, non ho mica detto che COM sia una panacea o che sia espressione del
Migliore dei Mondi Possibili (cit.)   :)
Ottavio ha chiesto un esempio di COM, e gliel'ho semplicemente fatto  :)
-- 
Faber
http://www.faberbox.com
Anyone who slaps a 'this page is best viewed with Browser X' label on a Web
page appears to be yearning for the bad old days, before the Web, when you
had very little chance of reading a document written on another computer,
another word processor, or another network. -- Tim Berners-Lee

 socket, una bella ipc.
OpenOffice non è affatto nella norma (rispetto allo standard Windows),
proprio perché è multipiattaforma e ha una storia alle spalle molto
particolare; solitamente chi scrive un'applicazione per Windows non ha
molto interesse a renderla utilizzabile tramite automazione, tranne casi
dove in effetti l'interfaccia COM è fondamentale per rendere il prodotto
completo (per esempio AutoCAD) o più competitivi.
-- 
Faber
http://www.faberbox.com
Only wimps use tape backup: _real_ men just upload their important stuff
on ftp and let the rest of the world mirror it  -- Linus Torvalds

 Per cui, per adesso seguo il thread da osservatore...
Eddai Francesco, esponiti pure un po'! Si è qua apposta per flamm..ehm, 
discutere ;)


 completo (per esempio AutoCAD) o più competitivi.
ok, ma il mio esempio era per dire che le ipc esistono da un sacco di
tempo sotto unix e mediante esse si possono far comunicare anche processi
che non sono stati esplicitamente programmati per essere invocavibili da
altri (pensa alle pipe)

 voglia capire, la cosa ha perso di interesse per me.
no! io ti sto parlando dei widget. sei tu che hai tirato fuori il
discorso sui temi. discorso che non centra un cazzo.

 discorso sui temi. discorso che non centra un cazzo.
No no... Allora non sai proprio cio` di cosa parli...
Non hai idea di come funziona tutta la baracca e parli di look&feel
dei widget di GNOME? Te lo ripeto, perche` sono buono: sei sicuro che
tu non stessi parlando di layout (cosa definita appunto nelle HIG) e
non di look&feel di semplici widget (che non dipende neanche da
lontano da GNOME, ma solo dalle GTK)?
Pensaci bene stavolta!


 oofice:
Uhm... Diro' fessate, ma il sistema per *nix piu' vicino
a quanto dice Faber mi sembra:
http://www.cs.wustl.edu/~schmidt/corba-overview.html
Non saprei pero' se stiamo divagando rispetto alle metodiche
di riutilizzo del codice, che chiaramente non sono solo i shared
object o le dynamic linked libraries. Mi sembra comunque di no.


 object o le dynamic linked libraries. Mi sembra comunque di no.
Non conosco CORBA, ma in effetti sembra molto vicino a COM come concezione
di riutilizzo.
-- 
Faber
http://www.faberbox.com
When replying to a message, include enough original material to be
understood but no more. It is extremely bad form to simply reply to a
message by including all the previous message: edit out all the irrelevant
material. -- S. Hambridge, RFC 1855

 di riutilizzo.
Neanch'io lo conosco, ma per quanto ne ho sentito parlare anni fa,
vuole essere il corrispondente di windows dde, ole, com, in ambiente
unix. Cio' di cui mi sembra si parlasse, passando dal concetto del
riutilizzo e della condivisione del codice, erano "le modalita'" di
riutilizzo, condivisione e "disponibilita'" del codice.
Non solo quindi librerie
condivise, ma mezzi ancor piu' evoluti. Come quello di rendere
appunto disponibili "pezzi di codice" residenti in altro programmi
attraverso l'esportazione di "interfacce", in un ambiente a oggetti
(a oggetti almeno a livello applicativo, non necessariamente a
sistema).
Comunque, unix ha IMHO disponibili i mezzi per realizzare cio'.
Ottavio ha parlato di ipc, ma non mi sembra sufficiente. Se ci
mettiamo di mezzo rpc, secondo me ci avviciniamo maggiormente...
(eseguire un procedura remota, cio' che poi fa COM: ovviamente
il discorso vale anche in locale. Se n'era parlato anche in passato)
(n.b.: nessuna responsabiita' delle ca**ate che posso dire: non
sono un programmatore, e la mia esperienza dentro e al di fuori
della programmazione e' limitata...).


 di riutilizzo.
Vedi gnome-bonobo.
HAND,
  ngw

 vuole su come fare quel widget particolare.
daccordo sull'inutile tirarla lunga. Quindi sarò conciso
1) allora fai un selettore di colore a partire da un bottone se è csì
facile con solo una manciata di righe di codice.
2) il discorso è nato da, quoto:
"Io ho solo le GTK installate, GNOME non e` una libreria grafica (e
gia` questo lascia molto intendere cosa ne sai...)."
Adesso ti chiedo: libgnomeui fa parte di gnome? E, come tu hai ammesso,
contiene o no lo gnomecanvas? E lo gnome canvas è o no un widget?
pensaci bene tu stavolta :-)

 
http://www.cs.wustl.edu/~schmidt/corba-overview.html
a me personalmente corba non piace moltissimo. Mi sembra troppo grosso per
quello che fa. 
Comunque, a parte quello che è un mio giudizio personale, vorrei far
notare che unix prevede dalla sua nascita svariate forme di ipc proprio
per questo. Ok, corba è più evoluto anche grazie al fatto che è venuto
dopo e ha potuto prendere il buono di ipc e rpc, ma non è un altro
pianeta, anzi.

 mettiamo di mezzo rpc, secondo me ci avviciniamo maggiormente...
daccordo, solo che ho tirato fuori le ipc giusto perché mi era capitato
sotto mano l'esempio di openoffice. E' senza dubbio che le ipc non bastano
per un software distribuito. Per quanto, per esempio, il Bach mette nelle
ipc di AT&T Unix anche i socket e quindi la divisione non è troppo netta.

 ipc di AT&T Unix anche i socket e quindi la divisione non è troppo netta.
Beh, ipc non e' compresa nei socket?   :-)
Mi pare che quando hanno dovuto espandere il set di primitive unix
in viste del networking, hanno fatto una cosa il piu' generale
possibile.


 pensaci bene tu stavolta :-)
Ok, una libreria grafica e` un widget. E dire che tanta gente si
scanna su quale sia il migliore... Tanto e` un widget.


 si basasse su corba....
no dcom si basa su dce-rpc per maggiori info
http://my.execpc.com/~gopalan/misc/compare.html
-- 
ITHost (your host company)
Technical Manager
C. Paparelli (MCSE,MCSD,MCDBA)
http://www.ithost.ch

 Esempio?
c'è quello per lib5, quello per glibc, quello per GCC 2 e quello per 
GCC 3, ecc. La compatibilità binaria non è mai stata il loro forte. 
Anche i port per Windows che fanno sono comicamente rotti in questo 
senso

 inutilizzate).
che razza di argomentazione č?
D:\Documents and Settings\Administrator>pushd "%SystemRoot%\system32\" & dir /s /b *.dll *.ocx | wc -l & popd
   1737

 Sotto windows che prevede solo un'interfaccia grafica 
braccia rubate alla miniera

 di default in uno unix in modo da avere maggiore integrazione
ooops, hai indossato il tuo ragionamento dal rovescio

 stati esplicitamente programmati per essere invocavibili da altri
no

 no
e le pipe a cosa servono?

 e le pipe a cosa servono?
a far comunicare programmi programmati per comunicare su pipe

  a far comunicare programmi programmati per comunicare su pipe
e quindi popen() non funziona?
-- 
Francesco Romani - Ikitt   (signature under [re]construction)
'A geek is someone who spends time being "social" on a computer.'
'In fact, users don't read /anything/'                         -- Joel Spolsky

 a far comunicare programmi programmati per comunicare su pipe
non solo. Puoi bene fare cominicare programmi che all'inizio onn sono nati
per farlo. Anzi, chi ha inventato le pipe lo ha fatto proprio per questo....

 per questo.... 
alla luce di tutto ciò, giustifica l'esistenza di /dev/stdout

 Multics)
E gne gne non ce lo mettiamo?


 senso
Non e' fondamentale ai fini del discorso, ce l'hai ficcato
col martello... I porting di programmi ms per unix
funzionano molto peggio (foxpro unix...) Comunque il layer
dll cygwin di emulazione api unix funziona bene quanto basta.


 Multics)
Quello e' passato a scrivere i messaggi di errore per Windows:
"Keyboard not found. Please press F1 to continue."
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 C:\>iao Angelo
http://www.multicians.org/hodie-natus-est.html
;-)


 Xwindow
piuttosto questa è una osservazione intelligente. Ma più che discutere
sul design di unix si può parlare del design del sistema grafico.


bott@banach:~$ ls /dev/stdout -al
lrwxrwxrwx    1 root     root           15 2004-05-24 17:22 /dev/stdout -> /proc/self/fd/1
bott@banach:~$
non è altro che un puntatore ad un file descriptor, non è un device
file. Tra parentesi, è un link allo stdout del processo leggente, quindi
non sostituisce per niente le pipe. 

>Xwindow

Non penso che le inferiori prestazioni di Xwindow siano
da addebitare all'uso di ipc, quanto piuttosto ad altri motivi.


 Multics)
Ora che ci penso: se vogliamo ironizzare sui bagni di sangue
per il timesharing, che fra Multics (livelli di ring e target
incentrato sulla sicurezza) e Virtual machine di ibm (altro modo
originale di affrontare il timesharing "sicuro"), ci hanno portato
nell'informatica moderna a cavallo fra i '60 e i'70, nonostante il
primo sia morto con poche installazioni, e l'altro sopravviva (piu'
che altro grazie alle banche...) fino ad adesso, ti rendo noto
(e mi sembrava di averlo gia' fatto) che windows prende le sue
caratteristiche piu' innovative da VMS e digital unix, grazie
all'apporto degli ingegneri digital confluiti in microsoft (please
non fatemi relinkare la pagina, cercate su google "windows NT VMS").


 quindi non sostituisce per niente le pipe. 
Leggi Il Cazzo Di Manuale (TM)

 I porting di programmi ms per unix
chissenefrega, non è una gara. E io non ho mai parlato di Microsoft. 
Pensavo a me e al port Windows di Samba-TNG, e a problemi che, se non 
fosse per me, agli sviluppatori di TNG non sarebbero nemmeno venuti in 
mente

 mente
Quali, se non sono troppo curioso?
P.S. ma voi sviluppatori di ReactOS siete tutti cosi caustici?
ciao!

 chissenefrega, non è una gara. E io non ho mai parlato di Microsoft.
No? E allora perche' hai menzionato i port di programmi
*nix su windows?
A parte che il discorso c'entrava poco, visto che si parlava di
problemi su binari e librerie *all'interno* delle rispettive
piattaforme.
[SNIP]


 ciao!


 Leggi Il Cazzo Di Manuale (TM)
 ****   ADDITIONAL /dev DIRECTORY ENTRIES
 
This section details additional entries that should or may exist in
the /dev directory.  It is preferred that symbolic links use the same
form (absolute or relative) as is indicated here.  Links are
classified as "hard" or "symbolic" depending on the preferred type of
link; if possible, the indicated type of link should be used.
 
 
        Compulsory links
 
These links should exist on all systems:
 
/dev/fd         /proc/self/fd   symbolic        File descriptors
/dev/stdin      fd/0            symbolic        stdin file descriptor
/dev/stdout     fd/1            symbolic        stdout file descriptor
/dev/stderr     fd/2            symbolic        stderr file descriptor
/dev/nfsd       socksys         symbolic        Required by iBCS-2
/dev/X0R        null            symbolic        Required by iBCS-2

  ****   ADDITIONAL /dev DIRECTORY ENTRIES
[...]
l'altro manuale. Quello che dice che servono per lavorare con i 
programmi che non scrivono sull'output standard

 Xwindow
usa i semafori UNIX? ci credo quando lo vedo

 piattaforme.
nel momento in cui mi rispondi accetti e assecondi il mio cambio di 
argomento

 argomento
Ah, beh, d'accordo. Avevo pero' espresso sin dal principio
il mio disappunto...
bye G.L.


 usa i semafori UNIX? ci credo quando lo vedo
Ne so poco, ma ho trovato questo schemino in pdf:
www.cs.iastate.edu/~cs554/lec_notes/unix_ipc.pdf
Non usa i semafori, ma usando delle pipe atttaverso
l'apertura di unix Domain socket, usa certamente una
delle diverse forme implementative di ipc su unix.
Le pipe sono usate per scambiare grosse quantita' di dati,
mentre i semafori sono usati per scambiare piccole quantita'
di dati con l'obbiettivo di sincronizzare fra loro due o
piu' processi.


 usa i semafori UNIX? ci credo quando lo vedo
www.public.asu.edu/~mujtaba/Articles%20and%20Papers/cse532.pdf
Questo e' un po' piu' approfondito, con qualche raffronto
fra le implementazioni di ipc windows, bsd e sysV.




e quale manuale sarebbe? comunque ti ripeto, che punto a /proc/self/fd/1,
quindi è quello del processo corrente, non quello degli altri processi.

 implementative di ipc su unix.
se la mettiamo cosě, anche un ponte radio di mezzo metro č IPC. Io ho 
detto UNIX IPC (in contrapposizione a *POSIX* IPC), non IPC su UNIX

 detto UNIX IPC (in contrapposizione a *POSIX* IPC), non IPC su UNIX
senti un po', spiega bene la differenza tra unix ipc e posix ipc, per
piacere.

 Io ho detto UNIX IPC (in contrapposizione a *POSIX* IPC), non IPC su UNIX
Se hai letto nei link che ho postato, anche la comunicazione in rete
e' ipc. Tant'e che in X, a parte le prestazioni, trasparentemente
non cambia granche' che il processo comunichi con X in locale o
attraverso un network. _Inter-process-Communication_, comunicazione
fra processi, cos'altro diamine puo' essere?
Tant'e' che ipc e network son state mi sembra una novita' pressoche'
contemporanea nel mondo unix, anche notando il fatto che
aprire un socket e' analogo all' aprire un flusso, una stream,
e alla fine... un file.   ;-)
Mi e' poi incomprensibile , a che pro tu, ai fini del discorso, voglia
differenziare fra unix ipc e posix ipc... Ti rimando a tal proposito
alla domanda di Ottavio.
Peraltro tu hai messo in mezzo i semafori, come se apparentemente
fossero inprescindibili dalla ipc, quando sono meccanismi di
sincronizzazione fra processi oltreche' di scambio/condivisione di
dati, ma di cui evidentemente X non abbisogna nel merito di cio'
di cui stiamo parlando (perche' la shared memory e' invece utilizzata
quando possibile dal client e dal server, ma su questo non mi addentro
per manifesta ignoranza...)


 e' ipc.
no. Vedi dei PID spuntare dalle funzioni per le socket? vedi un modo 
per scambiare file descriptor su una socket? o per impersonare l'user 
id del client? Sono IPC solo incidentalmente, e comunque alla lontana. 
E in ogni caso non continuerò quella che è solo una discussione sulla 
terminologia. La mia era una polemica sterile sull'insolita bruttezza 
di un'API UNIX, un'API apparentemente uscita dal nulla, che non ha 
niente a che vedere con tutto il resto e contraddice alcuni principi 
pressochè universali (come il reference counting delle risorse)

 implementazioni di ipc windows, bsd e sysV.
non parla dei semafori nè della memoria condivisa. Tutte cose che, 
messe assieme, mi suggeriscono che avevo visto giusto: nessuno li usa. 
Nè nessuno implementa POSIX IPC, comunque, quindi chi usa UNIX IPC 
magari lo fa perchè non ha scelta. La storia si ripete: belli gli 
standard, mettiamoli sulla mensola del caminetto e vantiamoci. Usarli? 
non se ne parla nemmeno
Cerca la documentazione di queste funzioni e prova a indovinare quali 
sono quelle POSIX:
msgget
ftok
mq_notify
shmat
sem_open
semop
shm_unlink

 pressochè universali (come il reference counting delle risorse)
senti, leggiti il libro del Bach alla voce ipc, dove spiega come e perché
hanno implemenato le cose e qual'è la logica che sta alla base delle ipc.
Tra parentesi scambiare i pid nelle ipc è una cosa pessima, perché
rischi di giocarti la portabilità e l'interoperabilità tra sistemi
operativi diversi. I socket, una delle varie forme di ipc, sono nati per
permettere anche a sistemi operativi diversi di comunicare. Dopotutto le
ipc nell'ottica del Bach non erano solo confinate in un computer.

 computer.
Di' un po', ma questo libro ha per caso le pagine in cartone colorato e 
un pulsante che fa il verso della mucca? o l'hai letto alzando troppo 
il gomito? Quella roba si chiama RPC

> piu' processi.
KJK::Hyperion
 > se la mettiamo così, anche un ponte radio di mezzo metro è IPC.
---------------------------
Renaissance:
 > Infatti... (andiamo avanti)
KJK::Hyperion:
Io ho detto UNIX IPC (in contrapposizione a *POSIX* IPC), non IPC su UNIX
Renaissance:
 > Se hai letto nei link che ho postato, anche la comunicazione in rete
 > e' ipc.
no. Vedi dei PID spuntare dalle funzioni per le socket? vedi un modo
per scambiare file descriptor su una socket? o per impersonare l'user
id del client? Sono IPC solo incidentalmente, e comunque alla lontana.
E in ogni caso non continuerò quella che è solo una discussione sulla
terminologia. La mia era una polemica sterile sull'insolita bruttezza
di un'API UNIX, un'API apparentemente uscita dal nulla, che non ha
niente a che vedere con tutto il resto e contraddice alcuni principi
pressochè universali (come il reference counting delle risorse)
bye G.L.


  buon senso
Il buon senso e ricordare l'"anni dopo".
-- 
Francesco Romani - Ikitt   (signature under [re]construction)
'A geek is someone who spends time being "social" on a computer.'
'In fact, users don't read /anything/'                         -- Joel Spolsky

 Il buon senso e ricordare l'"anni dopo".
viene *comunque* da chiedersi chi fumasse cosa quando č saltata fuori 
ftok. Permettere direttamente di dare *nomi* agli oggetti IPC era un 
concetto cosě alieno? o crearli come file su un filesystem speciale, 
come "suggerisce" la nuova API POSIX? Sarebbe dovuto essere cosě sin 
dall'inizio - dov'era il famoso principio "tutto č un file" quando 
AT&T/Microsoft/SCO/vattelapesca ha tirato fuori quell'obbrobrio?

  AT&T/Microsoft/SCO/vattelapesca ha tirato fuori quell'obbrobrio?
Da quando sono a venuto a conoscienza di quella 'roba' mi e` subito
parsa una pezza messa su li a integrazione zero, ma il mio parere
in questo campo ha un valore (molto) relativo.


 o l'hai letto alzando troppo il gomito? Quella roba si chiama RPC
l'ottica del Bach è meno miope della tua. Lui stesso scrive che quando
fai comunicare due processi il problema se risiedono sulla stessa macchina
o meno non si dovrebbe porre, o almeno dovrebbe essere il più trasparente
possibile alle applicazioni. Non a caso il suo libro finisce con
un'analisi dei sistemi distribuiti.

 Forse č meglio se fai un giro su 
www.unix.org
ROTFL. Beata ignoranza

 ROTFL. Beata ignoranza
il riso abbonda sulla bocca degli stolti.

  >>>>> e nessuno le usa perchè sono degli orrori inefficienti
vero, infatti ad esempio...
# ipcs 
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x0052e2c1 0          postgres  600        10436608   1                       
0x00000000 32769      root      777        49152      1                       
0x00000000 65538      root      777        16384      1                       
0x00000000 131075     piccia    600        393216     2          dest         
0x00000000 163844     piccia    600        393216     2          dest         
0x00000000 196613     piccia    600        393216     2          dest         
0x00000000 229382     piccia    600        393216     2          dest         
0x00000000 262151     piccia    600        393216     2          dest         
0x00000000 294920     piccia    600        393216     2          dest         
0x00000000 327689     piccia    600        393216     2          dest         
0x00000000 360458     piccia    600        393216     2          dest         
0x00000000 393227     piccia    600        393216     2          dest         
0x00000000 425996     piccia    600        393216     2          dest         
0x00000000 458765     piccia    600        393216     2          dest         
------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x0052e2c1 0          postgres  600        17        
0x0052e2c2 32769      postgres  600        17        
0x0052e2c3 65538      postgres  600        17        
0x0052e2c4 98307      postgres  600        17        
0x0052e2c5 131076     postgres  600        17        
0x0052e2c6 163845     postgres  600        17        
0x0052e2c7 196614     postgres  600        17        
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    
gli shared memory in questione sono usati da postgres, X, gnome-session,
gnome-terminal, metacity, gnome-panel, nautilus, mixer_applet2, wnck-applet.
I semafori sono di postgresql.
-- 
addio, e grazie per tutto il pesce

 il riso abbonda sulla bocca degli stolti.
ssshtupido č chi lo ssshtupido fa (cit.)
		       ________________________ 
		      < Corri FORREST! Corri!! >
		       ------------------------ 
			 \
			  \
			      .--.
			     |o_o |
			     |:_/ |
			    //   \ \
			   (|     | )
			  /'\_   _/`\
			  \___)=(___/
	      FORREST-HOWTO (piuma non inclusa).
(cit. da <slrn9vj4pb...@olgeni.olgeni>)

 I semafori sono di postgresql.
Ooohh... aspettavo questo.    :-)
Questione chiusa, almeno da questo versante.


  ssshtupido č chi lo ssshtupido fa (cit.)
Autogol nell'aria?


 Autogol nell'aria?
non raccogliere le provocazioni, accoglile

 ssshtupido è chi lo ssshtupido fa (cit.)
Openssh, o ssh versione commerciale?  ;-)


 Tutt'orecchi.
di corsa: le costanti di errno.h non sono necessariamente universali, 
di errno non ce n'č necessariamente un'unica istanza, malloc non č 
sempre l'unico allocatore, esporre dei FILE * all'esterno non č mai una 
buona idea, e cosě via. E' solo un po' di lavoro in piů

 prodotto completo (per esempio AutoCAD) o più competitivi.
Ma tu pensi che COM serva solo per l'automazione delle applicazioni?
Insomma, dovresti leggerti qualche articolo su COM.
Ma .NET e Java sono meglio.
Saluti.

 non fatemi relinkare la pagina, cercate su google "windows NT VMS").
Ti passo  VMS ma Ultrix non c'entra un piffero con NT.
Saluti.

 dcom si basasse su corba....
Non esageriamo.....I concetti sono simili.
Ma perchè confondete IPC con meccanismi RPC?
Saluti.

 Ma .NET e Java sono meglio.
'somma. Java *poteva* essere meglio, ma ha conservato alcune delle cose 
più brutte di COM (interfacce callback per la gestione degli eventi e 
stub compiler per RPC le prime che mi vengono in mente). E i generic 
sono stati una delusione, anzi, una vera truffa

 Ma .NET e Java sono meglio.
Di che? Per cosa? In che ambito? Java e meglio sono troppo vicini.
-- 
Valentino Volonghi aka Dialtone
Linux User #310274, Proud Gentoo User
Blog: 
http://vvolonghi.blogspot.com
Home Page: 
http://xoomer.virgilio.it/dialtone/

 generic sono stati una delusione, anzi, una vera truffa
Che pretendi da SUN?
Sun è o non è quella che dopo che Microsoft presentò le webclass di VB 6 nel
1998
rilasciò le .jsp nel 2001? O quella che dopo aver visto 
ASP.NET
  nel 2000 ha
rilasciato
JavaServer Faces nel 2004....
Non spariamo sulla Croce Rossa :-)

 Di che? Per cosa? In che ambito? Java e meglio sono troppo vicini.
Di COM. Ambito qualsiasi tranne che programmatore della domenica.
Saluti.

 Insomma, dovresti leggerti qualche articolo su COM.
Se hai qualche link a proposito postalo pure, sono tutt'orecchi  :)
-- 
Faber
http://www.faberbox.com
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it. -- Brian W. Kernighan

 Se hai qualche link a proposito postalo pure, sono tutt'orecchi  :)
Quale meglio di questo?
http://www.microsoft.com/com/default.asp
COM comuque è morto o quasi.
Peccato.
Ogni scarrafone è bello a mamma soia....
Saluti con commozione per COM.

 Saluti con commozione per COM.
ActiveX crying...
-- 
Faber
http://www.faberbox.com
Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum
habetur, quomodo habenda est. -- Saint Augustinus

 Ma perchè confondete IPC con meccanismi RPC?
Nessuna confusione: anche rpc viene considerata una forma di ipc.
bye G.L.
-- 
« E' assolutamente evidente che l'arte del cinema
  si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)

 Ti passo  VMS ma Ultrix non c'entra un piffero con NT.
Non ultrix, digital unix. Non ho piu' il link, quindi
puoi considerarlo FUD, e al limite considerare fessate
quanto asserito il quel link: soprattutto VMS certo, ma anche
un paio di tecnologie mutuate da digital unix, mi sembra
riguardanti l'i/o. Nulla di strano o di impossibile, IMHO,
visto che sempre di digital e relativi ingegneri stiamo
parlando. Ovviamente non stiamo parlando di "prendere codice"
(come invece sembra sia per lo stack tcp/ip dei bsd), quanto
di ispirarsi a tecnologie preesistenti.


 COM comuque è morto o quasi.
Sembra che Don Box ne abbia ancora bisogno ;)
(giustamente)
http://www.gotdotnet.com/team/dbox/default.aspx?key=2004-06-04T07:11:55Z
-- 
Lawrence
"ain't nothin' but fun."

 Nessuna confusione: anche rpc viene considerata una forma di ipc.
concordo