Newsgroup: it.comp.os.dibattiti
Titolo: Bello il ng alt.os.development

ho trovato molte info tecniche oltre a gente molto competente.....
suppongo che anche questo ng era stato pensato in quei termini, ma poi 
ahimè troppi troll in giro fanno male :D


Oddio, qui e` it.comp.os.dibattiti non it.comp.os.sviluppo... Credo che
qui parlare di APIC, IRC, context switch e compagnia bella sia pure un
po' off topic.

Lemon Tree ha scritto:

beh però trollare a raffica pure è OT

Lemon Tree ha scritto:

però solo per puntualizzare, si chiama it.comp.os.dibattiti, quindi i 
dibattiti potrebbero essere pure di natura tecnica.....
non mi sembrano dibattiti costruttivi cose del tipo windows ce l'ha più 
lungo di linux....

 lungo di linux....
Ovviamente ti riferisci al tempo di boot :-D
Alessandro.

 lungo di linux....
Per fortuna che sei arrivato tu con "Linux ce l'ha piu' lungo di Windows",
finalmente un po' di originalita'.
  ngw

 dibattiti potrebbero essere pure di natura tecnica.....
Tanto tempo fa lo erano... 8-)
-- 
Lawrence - 
http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 
ah ecco quindi avevo capito bene che la natura di questo ng era di 
dibattere di tematiche tecniche e non di cazzate pseudo-informatiche

 Tanto tempo fa lo erano... 8-)
Frequento questo NG da circa 10 annni e la mi opinione su questo punto
conta parecchio: mi spiace ma quello che dici non e' vero.
i dibatti sono sempre stati di questo tenore qui.
GdG puo' confermare quello che dico: lui e' un'altro dei grandi vecchi di
icod :D
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

pabloski ha scritto:

In teoria dovrebbe servire a discutere di qualsiasi
cosa abbia a che fare coi SO, forse è stato fatto
anche per dirottare trollate e flame war via dai
gruppi più tecnici... alla fine ne viene fuori che
è praticamente IT tutto ciò che riguarda i SO, tranne
richieste d'aiuto e thread puramente tecnici che non
implichino opinioni personali e preferenze, 
p.es
.,
sarebbe OT postare una pura descrizione di un context
switch, senza commenti, ma IT se nel contesto di una
discussione su pregi e difetti dei vari meccanismi
di context switch.
Dire che un SO ci fa schifo perché, per fare
un esempio, ci provoca un'irritazione al colon,
comunque, sembrerebbe IT, secondo il manifesto ;-)
Alberto
-- 
rimuovere/remove         "Calm yourself!  Man who argue with cow
WLATOPA                      on wall is like plane without wings--
per rispondere/to reply    very soon get nowhere." (Peter Sellers)

 implichino opinioni personali e preferenze
Quoto.
In effetti io considerdo off topic i post di ngw quando parla di ruby,
di web, e quelli di Vegeta riguardanti il nanodesktop.
Se si obietta: "ma se non scrivo qui, dove scrivo per questioni tecniche?"
La risposta e': "esistono NG in inglese al'altezza di ogni situazione."


 icod :D
Non diciamo cazzate, ai tempi di Giovanni Sartori, Xelloss e Endymion si
facevano belle discussioni. Magari flame, ma almeno non si parlava di
te, cipria o ginopilotino o di quante distro ci sono per Linux. 


 te, cipria o ginopilotino o di quante distro ci sono per Linux.
Quoto, ricordo decine di discussioni tecniche molto interessanti.
Erano anche i tempi di Leonardo Serni, Giambo e KJK::Hyperion...
Bei tempi!
SALUTONI,
WindoM 

 ha scritto nel 
messaggio news:4506db93$0$29079$5fc...@news.tiscali.it...

Beh, oddio.... anche oggi i Sensei, gli Ottavio Campana, ngw, qualche
volta io.... qualche post tecnico sugli os lo facciamo.....
Saluti
Pegasus

 volta io.... qualche post tecnico sugli os lo facciamo.....
Lungi da me sminuire gli attuali frequentatori del newsgroup, ma una volta
c'era un nucleo di persone attivamente coinvolte nello sviluppo,
nell'hacking e/o nel reverse engineering di vari sistemi operativi.
Oggi quel nucleo manca: buona parte degli avventori odierni si occupa di
tutt'altro, e le discussioni ne risentono. Non è un caso che spesso si
finisca col parlare di linguaggi e di sviluppo web (nella migliore delle 
ipotesi)...
SALUTONI,
WindoM 



Fabio, senza nulla togliere a Serni, credo che le discussioni non fossero
tecniche nemmeno a quel tempo.
O meglio, bisogna vedere cosa si intende per "tecnico".
Forse non si dicusteva di ruby, css, e non si sparlava di java o amenita'
simili, e questo era gia' un gran bel  vantaggio, ma questo non e' mai
stato un NG dove si dibattevano *in dettaglio* tecniche di programmazione
del kernel.
Considero quasi quasi nanodesktop piu' in topic di molte altre discussioni,
anche se oenstamente, questo non e' il posto per venire a cercare aiuto di
quel tipo.



Non e' cosi'.
Le persone vanno e vengono e il livello e' piu' o sempre quello.
Per quel che mi riguarda, non partecipo a discussioni inerente la
programmazione perche', ahime', non programmo. Conosco poco il C e poco
linguaggi di scripting TCl, perl, shell varie (non ruby), ma non vengo in
un NG dove si parla di OS per parlare di tcl o ruby ... sarebbe oltremodo
ridicolo. 



Sai chi mi manca di piů? Juliet.
Era la migliore di tutti. Sia come programmatrice che come
conoscitrice degli internals di Windows.....

 Conosco poco il C e poco linguaggi di scripting
volevo dire: "pochi" non "poco" :)



http://groups.google.it/group/it.comp.os.dibattiti/browse_frm/thread/251d4da7d965c8d1/5d28b5a1ee34b700?lnk=st&q=periferica+video+remota+it.comp.os.dibattiti&rnum=2&hl=it#5d28b5a1ee34b700
saluti
Pegasus

 quel tipo.
Concordo sul fatto che sia molto più in topic di altre discussioni.
SALUTONI,
WindoM 

 Endymion
C'e` anche oggi non e` che sta nei bei tempi andati.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 Concordo sul fatto che sia molto più in topic di altre discussioni.
Eppure Vegeta ha preso badilate di merda per quel thread, guarda un po'.
  ngw

 Eppure Vegeta ha preso badilate di merda per quel thread, guarda un po'.
Non mi sembra ne abbia prese perché OT, molto più probabilmente perché
GalaxyOS non si dimentica e il ragazzo scopre il fianco alle badilate non
riconoscendone la paternità... ;-)
Comunque, non ne ha prese da me.
SALUTONI,
WindoM 



Filippo, spero ti renderai conto che su questo NG sono transitati milioni
di messaggi. Chiaramente intendevo nella media.


 conoscitrice degli internals di Windows.....
Che la sua figura abbia ispirato quella di Anna? ;-P
Pardon, non ho resistito.
SALUTONI,
WindoM 

 said:

Oddio, a *quei* tempi c'era pure Thorin che ti bastonava a sangue solo 
per aver osato toccare linux, e le cose non sono cambiate molto sotto 
questo punto di vista.
C'era chi conosceva gli internals di alcuni OS, vero. Oggi io non posso 
che parlare delle mie conoscenze che si basano su altri internals 
(afs/kerberos) in un OS. Diverso, molto diverso.
I troll c'erano sempre comunque.
-- 
Sensei <senseiwa@Apple's mail>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.


Per ripuntualizzare, il primo post che ho visto su alt.os.development
era uno sul context switch con codice assembly e commenti del tipo "ma
hai fatto push di questo" ma il selector di qua, lo stack di la? etc.
Questo newsgroup mi sembra piu` per discussioni, anche tecniche, di
alto livello e poco adatto per il codice. Ma forse mi sbaglio.

 te, cipria o ginopilotino o di quante distro ci sono per Linux. 
Evidentemente ricordi male perche' c'ero anche io.
Ciao ... Dino

 I troll c'erano sempre comunque.
Mai mancati. :-)
SALUTONI,
WindoM 

 ahimè troppi troll in giro fanno male :D
Fra ciprie, rossetti, fard e rimmel qua non si campa più..

 vecchi di icod :D
C'erano le mazzate, ma erano più che altro un diversivo. 

 Non diciamo cazzate, ai tempi di Giovanni Sartori,
Forse intendevi Piergiorgio Sator? :)
Anche per me sono ormai 8 anni e mi ricordo delle bellissime discussioni.

 Non e' cosi'.
io le discussioni sull'hyper threading di Sartori o sull'architettura di
Windows di Xelloss me le ricordo ancora.


 Evidentemente ricordi male perche' c'ero anche io.
Lo so che c'eri anche tu, ma non si parlava *di* te :D


 io le discussioni sull'hyper threading di Sartori
Ma Sartori non era l'inventore/CEO dell'Hyper Transport?
O ricordo male?
-- 
BArrYZ
" There's no such thing as talent; you just have to work hard enough."
                                       [David Mamet]

 La risposta e': "esistono NG in inglese al'altezza di ogni situazione."
Direi, non sarebbe male avere anche a mente il manifesto di questo gruppo:
news:HELP.it.comp.os...@id.news.nic.it
"Il manifesto del newsgroup è il seguente:
si potranno intavolare discussioni sulla bontà dei vari sistemi operativi
comparati tra loro, discutendone:
 - la robustezza
 - l'affidabilità
 - le prestazioni
 - il software disponibile
 - l'usabilità
 - la connettività
 - quant'altro riguarderà il confronto tra i vari sistemi operativi"
L'obbligatorieta' nel dover snocciolare questioni di carattere strettamente 
tecnico (che poi *tecnico* puo' voler dire tutto e niente, in realta') non 
la vedo proprio. Il tratto distintivo mi sembra, piu' che altro, fare delle 
comparazioni (e quindi intavolare le conseguenti discussioni) su basi quanto 
piu' possibili oggettive.


 O ricordo male?
No appunto.



ma si, non dico che tra centinaia di migliaia di thread non ce ne siano
stati di squisitamente tecnici, e pure interessanti.
Mettiamola cosi:
poniamo che esiste un ipotetico NG it.automobili.dibattiti (non
it.automodili.progettazione) e su quel gruppo invece di esserci io e te,
ci saranno Schumacher, Jan todt e Ross Brown.
E' chiaro che se Ross Brown inizia a parlare tecnico Schumacher non ha
possibilita' di replica e farebbe solo magre figure. Ma in fin dei conti
tra questi tre personaggi, chi e' meglio in grado di definire la vettura
e' migliore? Nell'ordine: quello che conosce meno tecnologia e' in grado
di definire qual e' la migliore vettura. Chiaramente non parliamo di un
utilizzatore qualsiasi di automobili.
torniamo qui, su ICOD.
Un sistemista, che conosce poco di OS internals (che si e'
semi-addormentato al training di hp-ux internals :)), che non ha mai avuto
necessita' in vita sua di scrivere nemmeno un array multidimensionale, ma
che nel suo lavoro ha messo insieme una grande quantita' di esperienze
(*), puo' dire la sua sulla qualita' di un OS, molto ma molto meglio di uno
che fa esperimenti demenziali su una playstation e fa ridere i polli
parlando di "embedded vision". Su questo NON ci piove.
(*) non ho grandissime cose da vantare, ma probabilmente qui sono l'unico
in grado di poter capire da dove e venuto fuori il sistema dei domini di
windows200, in cosa consiste veramente un mainframe e cosa sono il
protocollo SNA e un gateway SNA/TCP, cosa e' UNIX, cosa e' Linux.
In tal senso mi sento pronto a sfidare tutti i Vegeta e gli Lawrence
Oluyede di questo mondo e senza bisogno di parlare di ruby edel tcl, che
in tutto questo c'entrerebbe peggio dei cavoli a merenda.


 O ricordo male?
Ma Gabriele non Piergiorgio e poi e` Piergiorgio Sartor non Sartori.
Piergiorgio lavora(va?) per Sony.de. Gabriele Sartori qua non ci ha mai
messo piede e ha lavorato per Olivetti, Quantum, AMD e ora una startup
dell'opto-elettronica.




ma si parlava di OS internals e adesso non se ne parla piu'?
A me pare sempre la stessa identica cosa.


"Max_Adamo" <maxa...@KEINESPAMiol.it> ha scritto nel messaggio 
news:45071bfb$1...@x-privat.org...

Sì.... ovvio.... Adamo rules the world.....
Il tuo problema è che, a differenza di me, non sei solo molto ignorante
su qualsiasi cosa non sia strettamente attinente al tuo lavoro, ma sei
anche un arrogantello che ama spararle a raffica.
Io invece cerco di non insultare la gente in modo gratuito, posso non
saperne su alcune cose (non a caso sono un elettronico) ma non mi
metto a sparare a raffica giudizi tipo i tuoi (posso dire ad uno, al 
massimo,
che non capisce un tubo, ma certo non scrivo giudizi tipo i tuoi).
Per dare un giudizio su un sistema, bisogna avere una conoscenza di
quel sistema. Sapere COME si ottiene quella sicurezza, capire COME si
ottengono quelle performance, capire COME si ottiene la retrocompatibilità.
Quando non si hanno sufficienti informazioni sugli internals, si discute con
chi magari ne sa più di te.
Un os non è un insieme di protocolli di rete, ci sono decine di altri 
componenti
che devono collaborare tra loro: interfaccia, kernel, sottosistemi, sistema 
grafico,
librerie. Di quello si deve discutere: la conoscenza di un insieme di 
protocolli
di rete + l'uso della bash e di apt su Ubuntu **non** sono sufficienti per
dire che si è esperti di sistemi operativi.
Altrimenti io ti racconto che siccome conosco il protocollo di segnalazione
SS7 saprei costruire una rete telefonica da zero e ci prendiamo in giro a
vicenda.....
Secondo problemuccio: sei un cretino.
Al di là di tutto:
/cite/
molto ma molto meglio di uno che fa esperimenti demenziali su una
playstation e fa ridere i polli parlando di "embedded vision"
/cite/
Citami dove ho parlato di embedded vision. Voglio la citazione.
Embvision project è un acronimo per Vision for embedded platforms.
Dove ho parlato di embedded vision?
Ho parlato di visione artificiale, che è una branca ben precisa della
scienza, su cui lavorano una cinquantina di centri di ricerca in
tutto il mondo. Chi ha fatto ridere i polli e le galline, è l'ignorante
Adamo che non sa che cosa è la visione artificiale, e credeva che
visione artificiale significasse guardare le fotografie.
Conclusione: studia di più, non mettere il becco nelle cose che non
capisci/comprendi/conosci, e vedi di non fare ridere ancora ngw e
me....

 
daiii abbiamo un altro NGW.
Non cito un ca$$o. Non perdo tempo con nessuno a rovistare nei messaggi.
Dovreste essere contenti: vi lascio questa ultima chance. CITAMI.




in effetti con qualche BWAHBWAHBWAH in meno saremmo tutti piu' felici :)


 Non mi serve l'OS internals 
per evitare ulteriori turpiloqui, devo citare il fatto che mi sono quasi
addormentato al training di internals su hp-ux, non tanto perche' la
materia non mi andava a genio, quanto perche' ho avuto la sfiga di dover
seguire il corso con un docente dell'universita' di praga che parlava
l'inglese con inflessione ceca e pronuncia tedesca e che non era in grado
di rendere interessante nessun tipo di conversazione.


 Dovreste essere contenti: vi lascio questa ultima chance. CITAMI.
No, scimunito, non citi un cazzo perchè sai benissimo che non puoi
citare un cazzo: sei tu che hai parlato di embedded vision, io non
ho mai scritto questo in nemmeno mezzo post.
Ma come al solito, la tecnica tua non cambia: mettere in bocca agli
altri stronzate e poi attaccarli sulle stronzate che gli metti in bocca
tu stesso.

 dell'opto-elettronica.
Allora mi sono confuso io, perche' Sartori su Usenet, e qui sulla *.it in 
particolare, ci ha bazzicato una sacco in passato (ricordo su 
it.media.video.produzione e anche su it.comp.hardware.cpu, se non sbaglio).
-- 
BArrYZ
[_Sign?_]

 it.media.video.produzione e anche su it.comp.hardware.cpu, se non sbaglio).
Gabriele Sartori pure ha bazzicato su Usenet ma non qui su icod.
Piergiorgio Sartor invece ha bazzicato anche qua oltre che su usenet in
generale.


 Lo so che c'eri anche tu, ma non si parlava *di* te :D
E da quando sono una celebrita'? :D
Io ricordo che pirla da competizione ce ne erano anche anni fa (thorin 
dove sei finito? :D). E ci si scontrava un po' sempre per le stesse 
cose. Probabilmente fin dal 1991 c'era qualcuno che pontificava linux e 
qualcun altro che gli gettava merda addosso :)
Ciao ... Dino
-- 
"Berlusconi e' una di quelle malattie che si curano con il vaccino" (I. 
Montanelli)

 E da quando sono una celebrita'? :D
Non lo sei, infatti nessuno ti caga.
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 
ma  ti sei letto tutte le 40 miglioni di righe di linux per dire che e'
tanto al chilo
pero' su 500 supercomputer del mondo dei veri mostri di calcolo ci sono
molti linux
evidentemente molti che non sono solo studentelli saputelli ,che non
hanno mai fatto niente nella vita non la pensano come te
e tutte le cose che ci sono in windows fatte da ingegneri che la pensano
come te che sanno come si fa un OS e non come quelli del bazar
sono riusciti a fare un sistema che si rompe dopo 15 minuti se e' messo
in rete senza antivirus e anti tutto
-- 
|L|E|L|E|

 Non lo sei, infatti nessuno ti caga.
Grazie, ora sono piu' tranquillo :D
Ciao ... Dino

 Grazie, ora sono piu' tranquillo :D
Dai, che un poco ti rode... Hanno citato quasi tutti tranne te.
:-D


 pervasivo? Se il codice è ottimizzato per SIMD? Se esiste un HAL?
"HAL"? Dai spiegami cosa intendi per HAL.
Secondo me fai confusione a livello concettuale.
In linux io ho questo:
http://www.freedesktop.org/Software/hal
sys-apps/hal -> Hardware Abstraction Layer
ma altro non e' che una pipe per alcuni processi, programmi, atta a
semplificare la scrittura dei programmi stessi.
Ma in sostanza? Ma ti pare che stai parlando di cose che esistono solo
nella teoria dell'universita' di messina o magari stai parlando di cose
oggi banali, che in fondo in fondo non cambiano i criteri per giudicare un
OS.


 piu' possibili oggettive.
aRi-Quoto :)


 e' Linux.
Beh, proprio l'unico non direi.
Saluti.

 codice è ottimizzato per SIMD? Se esiste un HAL?
Cazz hai dimenticato l'ottimizzazione positronica dei gradienti fasici.
Saluti.

 Tanto tempo fa lo erano... 8-)
Dov'č che si firma per convincere Serni e Obelix (tanto per dirne due) a 
tornare?
Ciao!
-- 
"La pulitica, tasse e stipendi che varu pi ni niente
i partě che sna sbatu dr' Italia e di tutta la gente
e ti che et vurrii büteje na bumba
scutme mi lasa perde, pitost balte na rumba" da Saguiandotele, Tre Lilu
Muttley (ICQ: 63051387) 

 te, cipria o ginopilotino o di quante distro ci sono per Linux.
Be, il buon Ginopilotino gią c'era
-- 
"La pulitica, tasse e stipendi che varu pi ni niente
i partģ che sna sbatu dr' Italia e di tutta la gente


 Dai, che un poco ti rode... Hanno citato quasi tutti tranne te.
No, sono stato citato, in modo errato (accostato a quel babbione di
cipria) ma citato. Quindi un po' sono vips, pure troppo per i miei gusti :D
Ciao ... Dino

 Sono comunque contributi molto apprezzati, davvero.
Beh, Juliet ad esempio sapeva benissimo di windows, e quello era utile. 
Flame interminabili su qualunque questione!
<serious_mode> In realta`, ragazzi, qualunque NG e` una porta catartica 
che tutti noi usiamo </serious_mode> come ansiolitico, antidepressivo, 
antiinfiammatorio, procrastinatorio, antibiotico, antitroll, ...
-- 
Sensei <senseiwa@Apple's mail>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 volevo dire: "pochi" non "poco" :)
Freud? :D


 Cazz hai dimenticato l'ottimizzazione positronica dei gradienti fasici.
Superscazzola con il doppio scappellamento a destra?


 A me pare sempre la stessa identica cosa.
Se devo essere sincero se ne parlava poco di piu` di ora. C'erano flame 
e questi contenevano alcune tecnicita` molto buone, ma la media...
Diciamo cosi`, che mediamente e` rimasta uguale, ma vi erano alcuni 
outlier, e questo fa pensare che vi sia una differenza sostanziale... 
siamo ugualmente troll + conoscenza + religione.


 Superscazzola con il doppio scappellamento a destra?
L'ottimizzazione positronica dei gradienti fasici permette di ottenere tempi 
di compattamento delle singolarià torioniche di ordini di grandezza 
inferiori rispetto a quelli ottenibili normalmente e soprattutto senza 
incappare in un decadimento della bicomplessità molecolare con relativa 
scomposizione della curvatura spazio-temporale.

 Pegasus wrote:


ROTFL! :-D Si ricade, al solito, a questo link:
http://alnitak.ctt.it/lserni/woowoo/
bye G.L.
-- 
Renaissance, aka Gian Luca Sole
Per rispondere, togli nospam al contrario, e cambia nazione
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 
Concordo solo in parte, quando la discussione
è su "usabilità" e "quant'altro", le basi della
discussione possono diventare parecchio soggettive.
Anzi, veramente lo sono sempre, visto che dei SO,
come di qualsiasi altra cosa, conosciamo solo
il fenomeno, non il noumeno :-D
Alberto
-- 
rimuovere/remove         "Calm yourself!  Man who argue with cow
WLATOPA                      on wall is like plane without wings--
per rispondere/to reply    very soon get nowhere." (Peter Sellers)

 tornare?
Obelix non è scomparso in una grotta dopo aver
trafugato l'ultima copia esistente di OS/2 dalla
sala macchine di un credito agricolo? :-)


 il fenomeno, non il noumeno :-D
non e' che concordi solo in parte; stai dicendo anche tu che c'e' spazio
per qualsiasi tipo di discussione, senza obbligo di parlare (cit. GdG) per
forza de "l'ottimizzazione positronica dei gradienti fasici".
E guarda che se il NG fosse veramente a quei livelli ce ne potremmo andare
*tutti*.
ngw tornerebbe su comp.lang.ruby, io su *linux.sys, vegeta su
it.giochi.playstation, tu non so dove :)


 sala macchine di un credito agricolo? :-)
Ma ROTFL!!! :-)


 OS.
Ben svegliato... capito tutto tu....
HAL è uno pseudonimo per Hardware Abstract Layer: ce l'hanno i sistemi
operativi della famiglia NT, nonchè NetBSD (veramente ce l'ha anche
Nanodesktop ma quello è un altro discorso, perchè ND è una libreria
e non un OS....).
Senonchè, se un sistema operativo è HAL-based, diventa 100.000 volte
più facile portarlo su qualsiasi cosa abbia un processore. Infatti ti scrivi
un nuovo HAL (e non tutto il kernel), e gli strati superiori del sistema
si adattano automaticamente.
Se invece un sistema operativo **non** è HAL-Based (Linux), tu certamente
puoi portarlo, ma diventa molto più difficoltoso: invece di metterci 2 mesi
ci metti 2 anni.
Quindi, se tu vuoi discutere sul fatto che un OS sia più o meno portabile, 
prima
dovresti sapere che cosa è un HAL e vedere se il tale OS ce l'ha.
Naturalmente tu non sai che cosa è un HAL e quindi hai concluso che è
perfettamente inutile il sistema più HAL-based del pianeta, che è
NetBSD.
Saluti
Pegasus

 ci metti 2 anni.
Dici? Beh tu sei un'autorita' in fatto di tempistica per la
realizzazione di S.O.


 Linux la compatibilità binaria non è garantita.
Coglione 1: in Linux il problema eventualmente non e' un kernel vecchio ma
le glibc,
Coglione 2: il sottosistema di UNIX/Linux e' in pratica il 'chroot'.
L'unica cosa che puo' crearti problemi di retrocompatibilita' e' la glibc,
ma tu puoi installare una diversa glibc in un ambiente chroot e far girare
quindi diversi programmi.
Tu giochi con le parole senza capirne il significato.
I sottosistemi sono in AS400, quello che microsoft chiama sottosistema per
me (visto che il codice non lo conosciamo) potrebbe anche essere un
emulatore.
per il resto degli argomenti, la situazione e' uguale, ma mi secca
discutere con te. Quella tua teoria su hal e' una cosa che non perdo tempo
a discutere con te, perche' non capisci un cazzo.
Tornare a giocare con la playstation.


 emulatore.
difatti, rinfrescando un po' la memoria mi torna in mente che la DOS Box
da windows nt in poi si chiama VDM .... virtual dos machine e non "SDM"
che potrebbe essere subsystem dos machine.
potrebbe essere un indizio.



senza dejanews, mi ricordo anche io: Pergiorgio Sartor.


 realizzazione di S.O.
Lui usa 2 IDE uno piu' potente dell'altro: power point e starimpress


 Ma anche io se č per questo, e seguo il NG solo dal 2002 o giů di lě.
Confermo anche io.


 Linux la compatibilità binaria non è garantita.
Aggiungo un problema sorto oggi.
Gentoo (serve l'ottimizzazione...), Matlab SP2. Update di gentoo, 
Matlab sfancula in segmentation fault perche` e` cambiata la glibc. 
Tocca aspettare di avere in mano Matlab SP3... quanto m'ha roso...


 E dopo i Blues Brother...Amici Miei 2000
Altri livelli caro, altri livelli!! :)


 Tocca aspettare di avere in mano Matlab SP3... quanto m'ha roso...
e pensa che su bsd lo devi lanciare in emulazione linux. Pensa che bello
:)
Cmq a parte i tips and tricks per farlo girare, se fai "esearch -S matlab",
vedo che ci sono dei cloni di matlab. Non oserei dire se scilab e' allo
stesso livello.


 a discutere con te, perche' non capisci un cazzo.
No, Adamo, perchè tu non sai che cos'è uno strato di astrazione 
dell'hardware.
Questa è la vera questione, che tu non sai un cazzo, e le batoste che prendi
da Wieland ed ora da me lo dimostrano in pieno.
Quella dell'HAL non è una mia teoria, scimunito, è un fatto che chiunque
abbia scritto tre righe di codice C capisce **immediatamente**: se vuoi
creare un sistema operativo portabile, è cosa buona e giusta che sia HAL-
based. Punto.

 Win16 di 15 anni fa senza alcun problema.
Questo avviene nei tuoi sogni proibiti, quelli da cui ti svegli
tutto bagnato. Ho qualche esempiuccio sulla macchina di programma
che tra NT e XP ha smesso di funzionare (pertanto ha molto meno di
15 anni). E di programmi (fatti a cazzo) che funzionavano su DOS
e che con NT non ne hanno voluto sapere, posso mandaretene qualche
CD.


 based. Punto.
Spiegaci perche' windows gira solo su x86 e il porting mips alpha del
server NT e' durato pochissimo tempo..... visto che era cosi' facile,
potevano continuare.



Sei un cretino (1):
Come sanno anche i piccioni del mio tetto, quando Windows NT fu progettato,
venne messa in cantiere una versione per microprocessori x86 ed una versione
per microprocessori Alpha (ed infatti Windows 2000 per Alpha è stato 
supportato
fino al 1999):
http://en.wikipedia.org/wiki/Windows_NT
Sei un cretino (2):
Non si comprende che cosa cazzo significa secondo Adamo, che
"Windows gira in modo zoppo su x86_64 (senza driver e senza software)".
Ora, uno ci mette 40 anni a capire una frase simile. Che cazzo significa?
BOH.
Intanto l'HAL serve per consentire la creazione di sistemi operativi
portabili su sistemi totalmente diversi (da x86 a MIPS, Alpha, PowerPC),
e non serve per portare un sistema da ambiente a 32 ad ambiente a
64 bit (dove basta qualche piccolo aggiustamento e la ricompilazione del
sistema).
In secondo luogo, ci sono fior di applicazioni per XP64 e ci sono drivers
per XP64. Ok, c'è poco interesse da parte dei costruttori, ma questo è
colpa dell'architettura di Windows? C'entra qualcosa con ciò a cui serve
o non serve l'HAL?
Sei un cretino (3):
Il vantaggio dell'HAL, nei sistemi operativi HAL-based, è che per portare
il sistema su una nuova piattaforma non è necessario rivedere il codice di
tutto il sistema operativo, ma è semplicemente necessario scrivere un nuovo
HAL. Ed infatti, NetBSD, che è HAL based (il suo HAL si chiama MPL,
Module Portability Layer) supporta praticamente qualsiasi
cosa. Maggiore spiegazioni sul problema si trovano qui:
http://www.wasabisystems.com/pdfs/Linux_or_BSD.pdf#search=%22netbsd%20hardware%20abstraction%22
Leggitelo e vedi se riesci a capire qualcosa in vita tua....
Naturalmente ora, dimostrato che NetBSD gira su qualsiasi cosa (e,
guarda che caso, è HAL based) facciamo scomparire NetBSD dalla
discussione, e ci concentriamo su Windows, giusto?


Certo, Adamo, ovviamente non ti viene in mente manco un secondo che
sia stata una scelta esclusivamente *commerciale* giusto?
Perchè invece non parliamo di NetBSD, che guarda che coincidenza
strana, è HAL-based?
Vediamo quali sono le conseguenze di avere un sistema operativo HAL-
based:
http://www.wasabisystems.com/pdfs/Linux_or_BSD.pdf#search=%22netbsd%20hardware%20abstraction%22
/cite/
NetBSD's fast portability is due to its unique Modular Portability Layer 
(MPL). With the MPL, the driver is completely isolated from the hardware 
platform, I/O instructions or no I/O instructions, interlocking, retry error 
recovery, bounce buffers, memory type boundaries, scatter/gather maps in 
host bridges, even peripherals which use pseudo-dma to write a buffer RAM 
with host CPU copyin and copyout all -- are transparently handled beneath 
the driver layer. Moreover, several embedded systems using NetBSD have 
required no additional software development other than toolchain and target 
rehost.
With Linux, however, device driver code must be reworked for every new 
architecture. As a consequence, in recent porting efforts by NetBSD and 
Linux developers, NetBSD has taken as little as 10% of the time to port to 
new hardware. Engineers ported NetBSD to the SuperH processor core in under 
six weeks; Linux took three months. NetBSD was ported to the AMD x86-64 in 
about a month; Linux took six months. As a result, NetBSD supports fifty one 
supported architectures from the same source tree.
/cite/
Ma guarda: non serve ad un cazzo ai fini della portabilità avere un sistema
HAL-based, no, no, no.....


Due precisazioni.
Per i programmi Dos, credo che la cosa non faccia testo, per
evidentissime ragioni (a cui puoi arrivare facilmente anche tu....).
Per i programmi Windows, quello che io apprezzo è che quantomeno
si sono posti il problema ed hanno cercato di fare qualcosa.
Ben diverso dall'idea alla base di Linux che è "fottiamocene.".
Sotto Windows XP, non solo funziona quasi tutto il parco
software di NT, non solo esiste un sottosistema Win16,
ma qualora non bastasse, esiste un software
chiamato WOWSERV che si occupa di incrementare la
compatibilità di XP con le vecchie applicazioni, incapsulando
il vecchio processo in un layer di traduzione che si aggiunge
all'attività di traduzione dei sottosistemi.
Che poteva fare MS di più?

 new hardware. 
Prima di tutto ti faccio una domanda: se e' cosi' facile portare tutto a
64bit anche in windows, come lo spieghi il fatto che ancora oggi non sono
disponibili tutti i driver 64bit per windows?
tornando a linux questo problema e' innegabile, come e' innegabile il fatto
che il driver in linux richiede la ricompilazione ad ogni cambio di kernel
(senza cambiare architettura) e causa il fatto che molti produttori non
rilasciano i driver. Linux ha questi problemi di fondo, ma questi problemi
di fondo (scusa l'evidenza), non toccano per niente l'utente finale, ma
toccano lo sviluppatore. Difatti, il numero di piattaforme sulle quali
gira il kernel linux e' piu' che sufficiente, ginopilotino puo' giocare
con netbsd sul vax (per farci non so cosa) e il resto degli utenti puo'
continuare ad usare linux su piattaforme in uso nel mondo contemporaneo.
Ergo: questo problema non intacca la scelta di un OS.


 Che poteva fare MS di più?
diciamo che era meglio se avesse fatto di meno, ma molto di meno, anzi
niente.


 
sai che significa?
Che nonostante sto cazzo di HAL, ad oggi non ci sono ancora tutti i driver
a 64bit per windows.



Cioè, tradotto: Linux non ha HAL, e quindi di sicuro non serve ad un
cazzo.



Non serve un sistema del genere. Devi premettere che il 99,9% del software
per linux gira a 64 bit (le eccezioni sono veramente eccezioni).
E non so se si puo' fare quello che dici tu, ma ripeto, per 2 o 3 software
non vale la pena (ripeto: flashplayer non va, per guardare i filmati wmv
devo installare pure a 32 bit perche' uso il codec di windos, e openoffice
e' in progress).
I binari, non compilati staticamente, contengono i link alle librerie, e un
binario e 32bit su un sistema a 64bit contiene un link alle librerie
situate nella "chroot jail". esempio:
ldd /opt/firefox/firefox-bin (che e' a 32 bit):
.... cut ....
libgtk-x11-2.0.so.0 => /emul/linux/x86/usr/lib/libgtk-x11-2.0.so.0 (0xf7c82000)
libgdk-x11-2.0.so.0 => /emul/linux/x86/usr/lib/libgdk-x11-2.0.so.0 (0xf7c03000)
libatk-1.0.so.0 => /emul/linux/x86/usr/lib/libatk-1.0.so.0 (0xf7be9000)
libgdk_pixbuf-2.0.so.0 => /emul/linux/x86/usr/lib/libgdk_pixbuf-2.0.so.0 (0xf7bd4000)
libpangoxft-1.0.so.0 => /emul/linux/x86/usr/lib/libpangoxft-1.0.so.0 (0xf7bcd000)
libpangox-1.0.so.0 => /emul/linux/x86/usr/lib/libpangox-1.0.so.0 (0xf7bc1000)
libpango-1.0.so.0 => /emul/linux/x86/usr/lib/libpango-1.0.so.0 (0xf7b8a000)
libgobject-2.0.so.0 => /emul/linux/x86/usr/lib/libgobject-2.0.so.0 (0xf7b52000)
libgmodule-2.0.so.0 => /emul/linux/x86/usr/lib/libgmodule-2.0.so.0 (0xf7b4f000)
libglib-2.0.so.0 => /emul/linux/x86/usr/lib/libglib-2.0.so.0 (0xf7acd000)
..... cut.....


 (0xf7c8200
ma aggiungiamo una cosa e addio:
Linux on POWER binary compatibility is made possible by conforming to an
Application Binary Interface (ABI). An ABI is the interface by which a
compiled binary gets access to an operating system and its services. When
multiple operating environments support the same ABI, it allows for the
same binary to run on these multiple environments. More information on the
64-bit supplement to the PowerPC® Executable and Linking Format (ELF) ABI
can be found in the "64-bit PowerPC ELF Application Binary Interface
Supplement 1.7" document (IBM). (See Resources.) 
Binary compatibility is the ability to take a binary and run it on
multiple environments of a given processor family. These environments
could be different versions of the same Linux distribution or they could
be completely different distributions. One example includes running a
binary that is compiled and run on a POWER4™ processor-based system
running SLES9 and executing it on a POWER5™ processor-based system, also
running SLES9. Another example is taking a binary that is compiled and run
on a POWER4 processor-based system running RHEL3 and executing the same
binary on a POWER5 processor-based system running SLES9. 




scusa ma tu hai citato il fatto (tramite una cosa che hai copia-incollato)
che il problema in linux e' che i driver devono essere "reworked", e li
dice, a causa della mancanza dell'hal. Mi chiedo come mai windows continui
a non avere i driver a 64 bit, nonostante questo vantaggio di partenza.
ri-cite:
With Linux, however, device driver code must be reworked for every new 
architecture... NetBSD was ported to the AMD x86-64 in about a month;
Linux took six months. 
fine.



Vediamo se riesco a farti capire in questo modo (impresa disperata
farti capire qualcosa, ma proviamo...).
Prima questione: tu puoi scrivere una applicazione bypassando completamente
la libc ed usando direttamente le syscalls. E questo ti provoca qualche 
problemino,
come vedremo poi......
Seconda questione: la questione sottosistema non è risolvibile in termini di
librerie (addirittura tu sparavi allegramente che il sottosistema te lo fai 
tu).
Supponiamo di compilare a 32 bit questo pezzo di codice:
main ()
{
   char *a;
   a=malloc (sizeof(char));
   *a=1;
}
Attenzione: ora abbiamo compilato a 32 bit questo pezzo di codice
ed è diventato il file prova32.elf.
Il problema è l'indirizzo restituito da malloc. Se questo pezzo di codice
è a 32 bit, allocherà un registro a 32 bit per ricevere il risultato di 
malloc.
Su un sistema a 32 bit, è facile facile: malloc è contenuta nella libc, e
chiede al kernel di allocare una certa area di memoria in uno spazio
di indirizzamento che è comunque a 32 bit. Tutto ok.
Ma proviamo ora ad eseguire prova32.elf su un sistema a 64 bit.
Sono cazzi. Infatti, la syscall richiamata da malloc deve restituire un
indirizzo a 32 bit quando il processo chiamante è a 32 bit, e deve
restituire un indirizzo a 64 bit quando il processo chiamante è a
64 bit.
Questo significa due cose:
a) il kernel deve tenere traccia di quali processi sono a 32 bit, e quali
sono a 64 bit;
b) le syscall del kernel devono cercare di allocare l'area al di sotto del
limite di 2^32 bit preferibilmente ai processi a 32 bit, mentre l'eventuale 
area
superiore deve essere allocata esclusivamente ai processi a 64 bit.
Bene: questo NON può essere gestito esclusivamente per mezzo di
librerie. E' necessario che vi sia un supporto all'interno del kernel,
soprattutto per la questione a).
Il problema è che un API a 32 bit restituisce risultati a 32 bit alla
routine chiamante, mentre un API a 64 bit restituisce risultati a 64 bit
alla routine chiamante. Certo, se si ricompila il problema si risolve,
ma se vogliamo la compatibilità binaria dobbiamo necessariamente
garantire che i processi a 32 bit possano interagire solo con API
a 32 bit ed i processi a 64 bit possano interagire solo con API a
64 bit.
Si potrebbe pensare di coprire questo al processo per mezzo di
opportune librerie. Che è il metodo seguito da Linux.
Pertanto, quando il processo è a 32 bit lo linkiamo ad una libc a
32 bit (che esegue internamente le conversioni 32/64 bit), mentre
quando il processo è a 64 bit lo linkiamo ad una libc a 64 bit.
Perchè il metodo basato sui sottosistemi è migliore?
Il problema è che una libreria può essere bypassata. Il processo può
essere stato scritto in modo da usare direttamente le syscalls del
kernel (kernel API) senza usare le librerie di sistema. Se questo accade,
è chiaro che il cambiamento della kernel API (che passa 64 bit), ha
effetti devastanti sul processo.
Inoltre, tutto questo presuppone che le librerie siano comunque linkate
dinamicamente (quindi che il loro codice non sia dentro prova32.elf),
così io posso cambiare la libreria qlib.lib con cui è stato compilato
prova32.elf nell'originario sistema Linux 32 bit, con una libreria qlib.lib
(32 bit>>64) nel nuovo sistema Linux 64 bit, **senza** che prova32.elf
se ne accorga.
Questo metodo, invece, fallisce miseramente quando abbiamo a che fare
con un binario in cui il codice delle librerie di sistema è stato linkato
staticamente (rarissimo ma teoricamente possibile).
Nei sistemi operativi che hanno i sottosistemi, invece, le cose stanno
diversamente. Ogni processo comunica (sia per mezzo delle librerie,
sia per mezzo del proprio codice che ora può usare direttamente le
syscalls), con un processo (il server di ambiente), che emula il
comportamento di un kernel e che fornisce un API del tutto compatibile.
Quindi, il sottosistema Win16 fornirà delle API a 16 bit alle applicazioni
Windows 3.x, il sottosistema Win32 fornisce API a 32 bit (anche sotto
WinXP 64), ed il sottosistema Win64 fornisce API a 64 bit ai relativi
processi. Ogni sottosistema incapsula i processi di propria competenza,
che non hanno modo di parlare con il kernel centrale del sistema, ma
comunicano esclusivamente con il loro server di ambiente di competenza.
Chiaro ora?

 HAL-based, no, no, no.....
Perlomeno non sono due anni, come affermavi, e comunque non c'e' mai
da riscrivere tutto il kernel, come sembrava dessi a intendere
(volutamente o involontariamente, non saprei)...
In realta' una forma di hal ce l'ha anche linux, solo non e' esplicita,
ovvero non l'ahnno seprata e modularizzata esplicitamente: tant'e' che
Il pacco di sorgenti e' unico per tutte le piattaforme.
bye G.L.
-- 
Renaissance, aka Gian Luca Sole
Per rispondere, togli nospam al contrario, e cambia nazione
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 Il pacco di sorgenti e' unico per tutte le piattaforme.
Aggungo, in riferimento a quanto dici in un altro post: in realta' il
layer hal serve molto anche per i driver (e cosi' mi risulta anche su
netbsd), altrimenti IMHO non si avrebbero grandi vantaggi se non
astrarre il resto del codice del kernel dalle sole peculiarita'
architetturali costituite dal memory management, dal sistema degli
interrupt, dalla gestione del bus e poche altre cose. E' infatti IMHO
un controsenso dover mettere mano, ad esempio, sul driver rtl8139 per
far si' che esso funzioni sia su x86 e bus pci che su ultrasparc con bus
pci.
Non mi vorrei sbagliare, ma pure su NT l'hal e' anche per i driver, e
infatti, al contrario di quanto affermi:
http://support.microsoft.com/default.aspx?scid=kb%3Bit%3B99588


 fine.
Lì il confronto è tra Linux e NetBSD. Che cosa c'entra Windows?
Ma non è tanto questo il problema, tu ancora non hai capito che
l'HAL non aiuta minimamente nel passaggio 32/64 bit (e quindi la questione
è totalmente malposta): l'HAL aiuta nel passaggio da una piattaforma
(per esempio PC x86), ad una piattaforma differente (per esempio
Amiga).
Nei sistemi operativi di tipo HAL-Based, le routine non presuppongono
mai nulla sull'hardware. Non presuppongono che ci sia un BIOS per
visualizzare il logo del kernel, che ci sia una VGA, che ci sia una
interfaccia VESA, che ci sia una tastiera, ecc. ecc. tutte queste cose
devono essere messe in "dubbio preventivo" da chi scrive la routine.
Quando la routine deve sfruttare qualcuna di queste funzionalità, essa
richiama sempre un'apposita routine dell'HAL, che risponde indicando
se la relativa funzionalità è disponibile su quella piattaforma. Se non lo
è, l'HAL tenta di emularla via software e se questo non è possibile,
viene segnalato alla routine chiamante che la funzionalità hardware
richiesta non è disponibile.
Questo meccanismo si associa a svariate scelte di codestyle percui, ad
esempio, si ha la certezza che il codice del kernel che gira ai layers
superiori all'HAL non farà mai cose come cercare di accedere direttamente
ai registri del controller della tastiera (proprio perchè sennò quel
pezzo di codice crasherebbe dopo essere stato ricompilato per
un decoder satellitare goldbox, ad esempio....).
Il vantaggio dell'HAL, è il fatto che se ho NetBSD, per portarlo sul
mio lettore satellitare GoldBox è sufficiente scrivere un nuovo HAL
e ricompilare il kernel.
Se invece voglio fare la stessa cosa con Linux, devo riguardare tutto
il codice del kernel, perchè ovunque ci possono essere routines che
hanno senso su un x86, ma non hanno senso su un GoldBox, o su
un VAX, o su una Sparc.
Questo è il concetto di HAL in generale.
Poi, NetBSD, estremizza il concetto, ed in questo è un'eccezione, perchè
fornisce delle funzionalità che consentono di astrarre il funzionamento dei
bus, percui il medesimo driver (dopo ricompilazione), potrebbe girare
sia sulla porta parallela del mio PC, sia sulla porta parallela del decoder
satellitare GoldBox su cui ho portato NetBSD.
Ma, tendo a ribadire, questo non c'entra proprio niente con il problema
del passaggio da 32 a 64 bit. Sia quando il sistema lavora a 32 bit,
che quando lavora a 64 bit, i chip che gestiscono USB, PCI, AGP
restano gli stessi ed i relativi registri restano gli stessi. Ecco perchè 
HAL
lì non da alcun aiuto, non c'entra nulla.
Diverso il caso se parli di portare Windows, tanto per fare un esempio,
da x86 a piattaforma PowerPC. Lì i registri del controller dell'hard
disk sono diversi (come sono diversi i registri per il controller della
tastiera, come sono diversi i registri per il controller DMA, nel senso
che funziona in modo totalmente diverso), ed allora un sistema operativo
HAL-Based include questo tutto questo codice platform-specific nel
componente HAL, invece di sparpagliarlo per tutto il codice del
kernel. In questo modo, per portare l'OS da x86 a... altro esempio....
PegasOS Machine, non è necessario riscrivere/riguardare tutto il
kernel, ma è solo sufficiente riscrivere l'HAL.
Capito ora?