A600 + CF + partizione PFS3AIO + installazione di MI1: error

[AMG_Novice_Usr]

In generale non ha più senso oggi rendere i comandi residenti vista la velocità raggiunta
dalle memoria di massa; era un meccanismo utile quando c'erano ancora i floppy disk e quindi
lasciare un comando in RAM dopo l'esecuzione poteva essere vantaggioso; oggi è sostanzialmente inutile

Certo, ma facciamo un esempio:

se un comando, il cui file (binario, eseguibile) si trova su un floppy, non è reso residente, ogni volta che il sistema necessita
di questo comando, il sistema deve accedere al floppy, con tanto di tempo di rotazione + tempo di avanzamento sulla traccia (0 ... 79) + tempo di prelievo dei bytes ... tempi meccanico/geologici!

Viene prelevato il comando, messo in ram, poi viene utilizzato, poi la ram a lui dedicata viene disallocata, pertanto al successivo
utilizzo di quel comando, il sistema deve ripetere l'accesso al floppy.
Da qui, la ovvia constatazione che rendere residente quel comando è molto meglio per i tempi di esecuzione.

Se però abbiamo che quel comando, il file di quel comando, anzichè risiedere su un floppy disk, magari risiede su una CF, le cose cambiano.
Il concetto è lo stesso del floppy, quindi ogni volta che il sistema necessita di quel comando, il comando va prelevato dalla memoria di
massa, ma essendo tale memoria di massa molto più veloce del floppy disk (la CF è basata su memorie flash, accessibili a banchi, come le flash di una penna USB o di una SD-card ... giusto?), ecco che l'accesso al comando ad ogni suo utilizzo non pesa troppo sulle prestazioni complessive, essendo un indirizzamento puramente elettronico, a stato solido insomma, e non più meccanico, pertanto lasciamo pure il comando su CF, non perdiamo molto in termini di prestazioni, e in più risparmiamo preziosa RAM, che su Amiga reali non espansi/poco espansi non è mai abbastanza ...

A partire dal KickStart 2.x, sia il Comando Resident, CD, Librerie ed altro sono stati inseriti nel Kickstart,
questo a mio avviso è molto meglio che averli su file, prima perchè si trovano al sicuro da corruzioni o infezioni
e secondo perchè a mio avviso velocizzano il sistema e garantiscono stabilità.

Se io ho i comandi sul drawer invisibile (= privo del corrispondente file icona.info) chiamato C, ovvero:

Sys: C

e la finestrella di protezione floppy è aperta, ovvero il floppy è write-protected, posso affermare che anche così stiamo proteggendo i comandi dentro C del floppy da corruzioni o infezioni, giusto? Voglio dire, la protezione non è raggiungibile solo dal fatto che nessun virus può scrivere nella ROM del kick fisico, ma anche la write-protezione del floppy che ospita tali comandi offre la stessa protezione ... è corretto?

La velocizzazione del sistema non è dettata tanto dal fatto che i comandi sono localizzati in kick-ROM, ma dal fatto che questi vengano resi residenti in ram, e quindi fatti girare in ram, tenuti sempre in ram (in stile TSR).
Forse (non sono un esperto in materia) se al posto di una ROM-kick, avessimo una memoria FLASH, quindi un chip di kick-flash, forse la CPU indirizzerebbe i comandi più velocemente in kick-flash piuttosto che in chip-ram, poichè le memorie flash vengono indirizzate a banchi, e non a singoli bytes, ma al tempo c'erano le ROM, e poi le EPROM, e poi le EEPROM, tutte memorie indirizzabili a byte, "byte-wise" in gergo, quindi indirizzamenti lenti, credo più lenti delle SDRAM con cui era fatta la chip-ram (detto meglio, la chip-ram era DRAM), pertanto forse è più veloce indirizzare i comandi in ram piuttosto che direttamente sul chip fisico del kick-ROM, da cui il vantaggio di avere un comando interno "residente", ma la residenza di un comando interno la ottieni gratis, all'accensione, quando cioè il kick-FW viene copiato da ROM a chip-ram (i comandi interni, che sono parte di questo FW, di conseguenza vengono portati in ram, quindi un comando interno all'accensione diventa necessariamente residente).

E' possibile renderlo residente (con "Resident CD", funziona anche su Icaros) ma sia io che lui abbiamo dubbi sul reale
vantaggio di renderlo residente visto che è già un comando interno, occupa poca memoria e la shell gestisce il cambio di directory senza usare il CD.

è un comando interno, e dato che tutto/quasi tutto il kick è stato copiato da ROM a chip-ram, quindi dato che il kick è tutto/quasi tutto residente, di conseguenza anche i comandi interni sono residenti, quindi anche CD è residente.
Rendere residente il CD da file, significherebbe copiare CD da file:

Sys: C/ CD

alla chip-ram.

Ma in chip-ram abbiamo già un CD, proveniente dal kick-ROM (questo CD è parte del kick-ROM-FW), quindi possiamo evitare di scrivere nella startup-sequence:

Resident CD

Riguardo KickStart 1.3 i Comandi residenti si possono utilizzare solo dalla Shell e non con il CLI !
...
inoltre anche il CLI e meno evoluto della Shell, anche qui dal Kick 2.x i due comandi sono stati "unificati".

Che differenza c'è fra Shell e CLI?

Lo domando perchè io tendo a pensare questi 2 oggetti come la stessa cosa, chiamata con 2 sinonimi, ma forse non è così ...

Posso azzardare un pensiero, che tu rettificherai meglio:

MS-DOS (che io non ho mai usato, il mio primo OS su PCx86 è stato Windows XP) era mono-tasking, e alla fine del processo di bootstrap, veniva eseguito/lanciato il processo "command.com", di fatto il cmd.exe che abbiamo anche oggi sulle ultime versioni di Windows, e tale processo di command line interface (CLI) era l'unico processo in running consentito da MS-DOS (correggi ogni virgola, se non dico cose corrette).

Quando io sulla CLI di command.com richiedevo all'OS di lanciare un certo programma/un certo comando, MS-DOS eseguiva il comando, però essendo mono-tasking, il controllo passava a questo comando/programma "figlio", mentre il "padre", ovvero command.com, veniva "congelato", e la sua esecuzione riprendeva solo dopo che il comando/programma figlio ritornava, ovvero terminava definitivamente, quindi solo dopo il "return" di tale comando, command.com riprendeva, fino al lancio del comando successivo ... pertanto non c'era una schedulazione a divisione di tempo che conosciamo oggi, riscontrabile, in quel periodo, solo nei sistemi unix avanzati ... e in Amiga.

Quindi la differenza fra CLI di Amiga (ho parlato della CLI di MS-DOS, ovvero command.com, solo per creare un background, a titolo di spunto per la discussione) e Shell di Amiga, quale è esattamente?

Forse che di CLI ce ne può essere una sola, e di Shell tante? Oppure il contrario?
A pensarci bene però, esistono entrambi i comandi, e sono pure interni a partire dal kick2.04 in poi, ovvero:

NewCLI
NewShell

che aprono un'altra finestra, che è un processo concorrente assolutamente indipendente da quello chiamante, e si vede anche dal numero indicato nel simbolo del prompt:
1>
2>
ecc ...

Anticipo che il kick1.3 non mostra nessun comando residente come preventivato, mostra qualcosa solo dopo aver avviato il sistema,
questo solo grazie ai comandi resi residenti dalla startup.

Probabilmente era anche una questione di spazio.

Fino al kick1.3 avevamo chip di ROM di capienza standard 256KB, e dentro a questa "ridicola" (per gli standards di oggi) memoria, ci stava già uno dei migliori OS del mondo, almeno per quanto attiene agli OS dell'allora nascente mondo degli home-computers (mi sarebbe piaciuto vivere quella fase storica!).
Dicevo, già ci stava dentro Amiga OS (Exec, Intuition a AmigaDOS) ... i comandi non ci entravano (oltre a tanti altri moduli e librerie, patches in generale), pertanto ecco la necessità di avere tutta questa roba esterna e non interna, ovvero su floppy, su files insomma.

A partire dal kick2.04, ecco che abbiamo i primi chip-ROM a 512KB, pertanto diverse cose che prima risiedevano su files, su floppy, poterono essere messe internamente alla ROM del kick.
Ho visto il file del kick1.3 di Carlo, output di Resident, quindi abbiamo capito che nessun comando era interno al kick1.3, tutti i comandi erano su files, su floppy, e potevano eventualmente essere resi residenti in chip-ram importandoli dai rispettivi files immagazzinati, ad esempio, in:

Sys: C

alla fine però sapere come funziona l'avvio dell'Amiga non ti aiuta poi nell'installare o ottimizzare il sistema.
Concentrati di più su cose terra terra come far funzionare i programmi perchè poi tutto il resto diventa solo teoria
e non interessa proprio niente se non sei un ingegnere che deve costruire un clone di un Amiga o un nuovo hardware
basato su questa filosofia.
Da quello che scrivi è chiaro che non sei un principiante, ma un livello conoscitivo molto avanzato,
ma poi ti perdi nell'uso quotidiano di un Amiga e relative periferiche.

Neppure Amiga in realtà mi serve, se è di "utilità" che parliamo, nel senso che non ci lavoro, è solo un'affascinante
hobby/speculazione, che mi concedo (come credo quasi tutti noi) nel pochissimo tempo libero che la vita lavorativa ci concede.
Sono in questo forum per imparare da voi che ne sapete più di me, e poi chissà ... un giorno potrò a mia volta dare una mano a qualcuno, ma non ancora: adesso sono nella fase di apprendimento, che deve durare alcuni anni, per lo meno.

[clros]

In generale non ha più senso oggi rendere i comandi residenti vista la velocità raggiunta
dalle memoria di massa; era un meccanismo utile quando c'erano ancora i floppy disk e quindi
lasciare un comando in RAM dopo l'esecuzione poteva essere vantaggioso; oggi è sostanzialmente inutile

Certo, ma facciamo un esempio:

se un comando, il cui file (binario, eseguibile) si trova su un floppy, non è reso residente, ogni volta che il sistema necessita
di questo comando, il sistema deve accedere al floppy, con tanto di tempo di rotazione + tempo di avanzamento sulla traccia (0 ... 79) + tempo di prelievo dei bytes ... tempi meccanico/geologici!

[...]

Se però abbiamo che quel comando, il file di quel comando, anzichè risiedere su un floppy disk, magari risiede su una CF, le cose cambiano.
[...] ecco che l'accesso al comando ad ogni suo utilizzo non pesa troppo sulle prestazioni complessive, essendo un indirizzamento puramente elettronico, a stato solido insomma, e non più meccanico, pertanto lasciamo pure il comando su CF, non perdiamo molto in termini di prestazioni, e in più risparmiamo preziosa RAM, che su Amiga reali non espansi/poco espansi non è mai abbastanza ...

Si, il concetto è proprio questo; non ha tanto senso rendere i comandi residenti proprio perchè ormai i dischi sono tutti molto veloci.
Forse un piccolo vantaggio ci sarebbe ed è quello della (mancata) frammentazione della memoria che con i comandi residenti non avverrebbe. Ma anche questo ormai è un falso problema vista la grande quantità di memoria RAM disponibile sulle machine moderne (parlo in generale, non di Amiga) e il ricorso ad allocatori sempre più sofisticati o gestori di risorse che "ricompattano" la memoria senza incidere sulle prestazioni. Ci sarebbe un mondo di cose da dire su questo; AmigaOS è bello perchè è semplice e "accademico"; puoi vederci tutti gli aspetti di un sistema semplice e fare il confronto con OS moderni. Anche se primitivo, una delle cose che comunque continuano a piacermi di AmigaOS è la cura con cui tutti i componenti sono "amalgamati", a mio avviso molto migliore rispetto Linux (per esempio, per l'unicità della GUI). Ma siamo fuori tema ;)

La velocizzazione del sistema non è dettata tanto dal fatto che i comandi sono localizzati in kick-ROM, ma dal fatto che questi vengano resi residenti in ram, e quindi fatti girare in ram, tenuti sempre in ram (in stile TSR).

Esatto.

Forse (non sono un esperto in materia) se al posto di una ROM-kick, avessimo una memoria FLASH, quindi un chip di kick-flash, forse la CPU indirizzerebbe i comandi più velocemente in kick-flash [...]

Sarebbe più veloce di una ROM tradizionale, ma più lento della RAM.
Non posso dirlo con sicurezza, ma delle semplici EEPROM che sto usando nel mio progetto le indirizzo direttamente indicando l'indirizzo e ottenendo il dato.
Per le SD Card invece è differente, devo indirizzare il banco e l'offset rispetto all'inizio di quel banco; un po' come tu stai dicendo delle Flash Memory.

, ma la residenza di un comando interno la ottieni gratis, all'accensione, quando cioè il kick-FW viene copiato da ROM a chip-ram (i comandi interni, che sono parte di questo FW, di conseguenza vengono portati in ram, quindi un comando interno all'accensione diventa necessariamente residente).

No. un comando per essere residente non basta copiarlo in RAM. Innanzitutto l'eseguibile deve rispettare certe convenzioni e poi deve essere aggiunto ad una lista speciale mantenuta da Exec o dal DOS che indica che da qualche parte in memoria c'è quel determinato eseguibile.
Scrivere moduli/comandi residenti era abbastanza difficile da quello che ricordo, c'erano diversi articoli su Amiga Transactor moltissimi anni fa, non l'ho mai fatto personalmente ma ricordo che era abbastanza complesso. Parlo comunque dl 1991/92 circa quando c'era ancora l'1.3, se poi le cose sono cambiate non saprei

dirlo.


è un comando interno, e dato che tutto/quasi tutto il kick è stato copiato da ROM a chip-ram, quindi dato che il kick è tutto/quasi tutto residente, di conseguenza anche i comandi interni sono residenti, quindi anche CD è residente.

No, non dovrebbe essere automatica la cosa.

[clros]

Detto più precisamente:

appena do potenza, il 68K copia il FW/bios/OS "Kickstart" dal chip di ROM fisico alla chip-RAM, ad esempio nel caso del kick 2.x,

Io sinceramente non l'ho mai capito; non so dire se la ROM venga copiata integralmente in RAM o se resta tutto lì dove si trova (In ROM).
Sui vecchi sistemi x86, il processore iniziava il fetch ad un indirizzo che coincideva con la ROM e in queste locazioni era contenuto il POST.

Non saprei dire se venisse copiata in RAM; dal mio punto di vista non ce n'è bisogno, è vero che la ROM è lenta ma è pure vero che si accede raramente (??) rispetto alla RAM.
Su Amiga possiamo prendere l'esempio delle librerie. Quelle interne, ogni volta che vengono aperte, vengono copiate in RAM (integralmente o solo la jump table??) e vengono poi cancellate quando non servono più (almeno di non renderle residenti )
Quindi se funziona così per le library, perchè dovrebbe funzionare diversamente per il resto dei moduli? Probabilmente qualcosa verrà copiato in RAM (di sicuro i vari processi dell'OS) ma che venga copiata tutta la ROM...ecco su questo non sono sicuro.

la CPU 68K esegue (fetch/decode/execute) le primissime istruzioni della ROM kick2.x, e l'esecuzione di queste prime righe di FW determinano il copiaggio dei 512KB di kick2.x (o una grande parte di questi ... come stanno le cose? viene copiato tutto il kick, oppure una parte di questo? a me risulta quasi tutto, non tutto ... fra un attimo dico il perchè*) dalla ROM alla chip-ram.

Appunto, secondo me non viene copiato tutto...
Cmq c'era in rete (e si trova ancora oggi) il disassemblato di Exec 1.2 commentato. Se ne parlò anche su un articolo su AmigaMAgazine in italiano.
Se non ricordo male, le prime istruzioni ad essere eseguite all'accensione erano proprio quelle di Exec e venivano eseguite direttamente da ROM.
(dovrebbe essere il numero 27 di amigaMAgazine da pag. 35 che trovi qui: https://www.amigamagazine.info/ .
Dire che è una lettura stra-interessante è poco!

Il fatto che si possa digitare il nome di una directory senza specificare CD è una
caratteristica combinata del funzionamento della shell e del fatto che CD sia un comando interno.

Sono d'accordo.

Sai che invece qui devo ricredermi?
Stavo pensando che probabilmente il comando CD non serve in questo caso; si tratta solo di una caratteristica della shell.
E' probabile che la libreria DOS metta a disposizione una funzione tipo ChangeDirectory()* che può essere direttamente richiamata dalla shell quando si accorge che in nome digitato è quello di una directory.
Questo per dire che il comando CD non serve alla shell; serve sicuramente all'utente della shell.

*Mi piacerebbe andare a controllare la documentazione, ma chissà dove saranno gli Autodoc! :D Non programmo su amiga da decenni ormai!
Gli amanti dell'openSource potrebbero controllare i sorgenti di Aros direttamente per sapere se è come sto pensando!

[clros]

Da quello che scrivi è chiaro che non sei un principiante, ma un livello conoscitivo molto avanzato, ma poi ti perdi nell'uso quotidiano di un Amiga e relative periferiche.

Bhe, una cosa è essere un ingegnere e avere conoscenze molto avanzate sulla struttura di un sistema operativo e un'altra cosa è essere un utente e avere una conoscenza avanzata di come si usa quel sistema operativo! E le due cose non sono sempre intercambiabili - anzi, non lo sono quasi mai!
(come dicevo una volta ad una ragazza: il fatto che tu sappia usare benissimo una lavatrice non vuol dire che tu sappia come funzioni o che ne sappia costruire/progettare una! )

[AMIGASYSTEM]

è un comando interno, e dato che tutto/quasi tutto il kick è stato copiato da ROM a chip-ram,

Questo accadeva sui vecchi sistemi Amiga non espansi e senza una Scheda Grafica, con i sistemi RTG anche super configurati come il mio AfA One una volta caricato il Workbench la Chip RAM non viene neanche toccata, quindi avendo molta Fast RAM possiamo far risiedere tutto quello che vogliamo e anche ad una più grande velocità.

Guarda il mio Screenshot quanta ChipRAM è stata consumata dei 2MB dal Workbench disponibili nonostante ci sono icone PNG di una qualità che Windows si sogna, poi ci sono App animate, uno Slideshow fotografico e altre App :)

Che differenza c'è fra Shell e CLI?

Tanta, il CLI del 1.3 è preistorico in tutto, prova ad utilizzarlo, un esempio su tutti non puoi richiamare i comandi digitati precedentemente !

Lo domando perchè io tendo a pensare questi 2 oggetti come la stessa cosa, chiamata con 2 sinonimi, ma forse non è così ...

Come detto dal 2.x sono la stessa cosa, prima due cose diverse e indipendenti.
Oltre alle piccole dimensioni della ROM , la differenza era data anche dal fatto che prima del Kick1.3 esisteva solo il CLI e la Shell non era stata ancora creata, quindi la presenza delle due era motivata anche per la retrocompatibilità per chi usava software OS 1.3 su OS 1.2 o OS 1.1

MS-DOS (che io non ho mai usato, il mio primo OS su PCx86 è stato Windows XP) era mono-tasking, e alla fine del processo di bootstrap, veniva eseguito/lanciato il processo "command.com", di fatto il cmd.exe che abbiamo anche oggi sulle ultime versioni di Windows, e tale processo di command line interface (CLI) era l'unico processo in running consentito da MS-DOS (correggi ogni virgola, se non dico cose corrette).

Sono passati tanti anni adesso non ricodo bene dovrei fare una ripassata, in ogni caso il CLI era simile al propt di MS-DOS e quindi meno evoluto della nuova Shell. Su MS-DOS quando si formattava un floppy per renderlo avviabile il sistema copiava sul floppy command.com e "IO.SYS" un comando nascosto che molti utenti MS-DOS non sapevano di averlo, poi dal prompt potevi eseguire solo i comandi DOS e non applicazioni Windows.

NewCLI
NewShell

Sui sistemi più aggiornati il Comando è uno solo ovvero CLI quello che cambia sono le impostazioni, la Shell per esempio non esiste è solo una icona, quello che cambia è quello impostato nel suo Toltype, nella directory S ci sono degli script che possono cambiare comportamento della Shell colore etc..

Sono in questo forum per imparare da voi che ne sapete più di me, e poi chissà ... un giorno potrò a mia volta dare una mano a qualcuno, ma non ancora: adesso sono nella fase di apprendimento, che deve durare alcuni anni, per lo meno.

Sono sicuro che riuscirai visto la tua tenacia e ne sono contento, AROS sarebbe il posto giusto per farlo visto che parliamo di un OS Open source

[AMG_Novice_Usr]

Forse un piccolo vantaggio ci sarebbe ed è quello della (mancata) frammentazione della memoria che con i
comandi residenti non avverrebbe. Ma anche questo ormai è un falso problema
vista la grande quantità di memoria RAM disponibile sulle machine moderne (parlo in generale, non di Amiga)

Questo discorso non mi è chiaro, se puoi spiegare meglio.
Stai dicendo che il piccolo vantaggio di rendere i comandi residenti starebbe nel fatto che se li rendiamo residenti, non avremmo
più frammentazione della memoria? Cosa intendi esattamente?

La frammentazione è un problema che affligge un disco, ovvero un file sparso un pò qui e un pò là, pezzi ovunque dello stesso file, quindi quando il sistema necessita di leggere quel file, di portarlo diciamo dal disco a tracce HDD, oppure dal floppy (su un floppy in OFS oppure in FFS ci può essere frammentazione?) alla ram, le testine di lettura sulle varie heads del disco devono viaggiare qui e là, passando dalla traccia X alla traccia Y, da un settore all'altro, un moto meccanico "impazzito", discontinuo nello spazio, non compatto, e da qui la grande dissipazione di tempo.

Nel caso di dischi a stato solido, vedi gli SSD, oppure le semplici memorie flash, vedi le CF, a parità di livello di frammentazione, il problema è molto meno impattante, dato che abbiamo un indirizzamento elettronico (un indirizzo su n bit, espresso da una parola a n bit -> un decoder degli indirizzi -> 2^n segnali, cioè 2^n "fili", parole diciamo, oppure righe di parole, nel caso di organizzazione matriciale della memoria in questione, vedi le DRAM), e non meccanico, quindi abbiamo si da indirizzare qui e là, per leggere un file, ma non abbiamo una testina meccanica che fa su e giù in modo impazzito, quindi su un SSD oppure una CF la frammentazione è molto meno negativamente impattante ...

e il ricorso ad allocatori sempre più sofisticati

Stai parlando della componente di un OS, forse anche di AmigaOS, chissà, che riserva un pezzo di ram per allocarci dentro il codice, l'op-code insomma, di un certo comando che è appena stato prelevato, ad esempio, da Sys: C , e messo appunto in chip-ram, e lo stesso modulo dell'OS che ovviamente, oltre ad allocare in ram "normale" il codice.bin del comando/programma, devo anche allocargli un pò di stack ... intendi questo, come "allocatori" ... giusto?

è, in un certo senso, il lavoro egregio che hanno fatto gli sviluppatori di FreeRTOS, ad esempio, partendo da heap1.h, fino ad arrivare a heap5.h, con quest'ultima versione di allocatore dinamico, con la quale adesso l'OS FreeRTOS (per il mondo ARM/Cortex) è in grado di allocare dinamicamente memoria in modo che gli heaps richiesti (tramite le chiamate stile calloc/malloc/new), da più tasks o co-routines, siano contigui fra di loro, in modo compatto, quindi non frammentato in ram, e così ne giova anche la successiva disallocazione (chiamate stile free/delete).

o gestori di risorse che "ricompattano" la memoria senza incidere sulle prestazioni

Questo è il caso di AmigaOS 3.x operante su filesystem SFS (solo per memorie di massa, non per la RAM, essendo un filesystem, quindi parliamo del sistema dei files sul disco).

Lo SmartFileSystem ha, fra le sue notevoli caratteristiche (PFS3AIO non c'è l'ha questo pregio, per esempio), la possibilità di avere un demone che in background opera una deframmentazione del volume inizializzato e formattato con SFS appunto, questa deframmentazione è "on-the-fly", eseguita in background mentre tu lavori, e sopratutto tale deframmentazione applica il journaling non solo ai metadati, ma anche ai dati, vista la delicatezza dell'operazione di taglia e incolla di frammenti di un file da un settore all'altro del disco, in modo da ricompattare appunto tale file.

Per inciso, è l'unico caso in cui SFS\00 opera il journaling (tramite il file speciale di rollback) anche ai dati, e non solo ai metadati.

una delle cose che comunque continuano a piacermi di AmigaOS è la cura con cui tutti i componenti sono "amalgamati",
a mio avviso molto migliore rispetto Linux (per esempio, per l'unicità della GUI). Ma siamo fuori tema ;)

Sperando che gli admin ci consentano questi voli pindarici (stiamo pur sempre parlando di Amiga/OS/informatica), dicci qualcosa in più su questo aspetto.
Cosa ha Amiga di migliore, rispetto a GNU/Linux (es: Ubuntu/Raspberry ecc ...), per quanto riguarda l'amalgama dei vari componenti?
Fa degli esempi pratici, per favore ...

per esempio, per l'unicità della GUI

dicci di più su questo ...

[AMG_Novice_Usr]

Sarebbe più veloce di una ROM tradizionale, ma più lento della RAM.
Non posso dirlo con sicurezza

è difficile in effetti fare valutazioni, bisogna vedere come si accede al dato, se in modo seriale (SPI meglio, I2C peggio ...), oppure in modo parallelo tradizionale, ad esempio come nel caso delle DRAM che si trovano sugli Amiga reali, dove bisogna generare un indirizzo A15 ... A0, poi latchare /RAS basso per selezionare una riga, poi generare un altro indirizzo A15 ... A0, poi strobare /CAS basso per la colonna, a quel punto si può latchare il dato D31 ... D0 in lettura o scrittura.

Queste tempistiche andrebbero comparate con le analoghe di accesso al dato per un chip di ROM del kicstart, che funziona non in modo matriciale come le DRAM, oppure con le tempistiche analoghe di un chip di flash ... non è facile dire cosa è più veloce.

un comando per essere residente non basta copiarlo in RAM. Innanzitutto l'eseguibile deve rispettare certe convenzioni
e poi deve essere aggiunto ad una lista speciale mantenuta da Exec o dal DOS che indica che da qualche parte
in memoria c'è quel determinato eseguibile.
Scrivere moduli/comandi residenti era abbastanza difficile da quello che ricordo

Non lo sapevo, pensavo che un comando in ram, che sta lì fintanto che la macchina è accesa, che sta lì anche dopo essere terminato (es: in MS-DOS, tale comando, terminando, scatena l'IRQ 0x27 anzichè l'IRQ 0x21, così che l'OS sappia che il controllo deve tornare a command.com, ma l'OS non deve dichiarare la porzione di ram occupata da quel comando come "libera") potesse essere considerato "residente".

Ho capito, non è automatica la cosa ...

Io sinceramente non l'ho mai capito; non so dire se la ROM venga copiata integralmente in RAM o se resta tutto lì dove si trova (In ROM).
Sui vecchi sistemi x86, il processore iniziava il fetch ad un indirizzo che coincideva con la ROM e in queste locazioni era contenuto il POST.

Si, secondo me è così, il primo accesso macchina, il primo fetch, eseguito da una CPU, x86 o 68K che sia, ovviamente deve essere un indirizzo fisico convenzionale nel chip di ROM (es: il kickstart, nel caso di Amiga), e lì, in queste prime righe di FW, secondo me è probabile, come dici giustamente tu, che sia subito la routine di POST, e non quella di copia/incolla del FW/kick stesso da ROM a RAM, e questo per un motivo molto semplice:

durante il POST, il FW deve testare anche la RAM.

Sarebbe un controsenso che le prime righe del FW/Kick che vengono fetchate dalla CPU siano il copia/incolla dello stesso FW/Kick da ROM a ram, dopodichè vengono fetchate le routines del FW sulla ram, e adesso si avvii il POST, che comprende anche il test della ram: e se la ram non funziona bene?

Di conseguenza tutto la fase di POST sarebbe invalidata (probabilmente crasherebbe il POST stesso) ...

No, bisogna prima che la CPU, fetchando direttamente dalla ROM, faccia il POST, e quando l'HW è stato validato, e in particolare quando anche la RAM è stata validata, allora verranno fetchate le routines, in ROM, che determinano il copia/incolla di grosse parti del FW/kick dalla ROM alla ram, e da adesso in poi, a copiaggio finito, il FW/kick viene sempre acceduto/eseguito dalla ram.

Non saprei dire se venisse copiata in RAM; dal mio punto di vista non ce n'è bisogno, è vero che la ROM è
lenta ma è pure vero che si accede raramente (??) rispetto alla RAM.

Il FW/kick, ovvero il cuore di AmigaOS (Exec, AmigaDOS), secondo me viene acceduto continuamente, in particolare Exec, ovvero lo schedulatore dei processi concorrenti, deve essere estremamente efficiente, poichè Exec valuta il cambio di contesto ad ogni tick di sistema, es: ogni 80ms, e lo schedulatore sarà sicuramente scritto in assembly, vista l'alta efficienza richiesta, quindi deve essere in ram, sicuramente ... non credo che venga acceduto direttamente dalla ROM.

Secondo me è come dici tu: alcuni moduli importanti del kickstart (es: Exec) vengono portati da ROM a ram, dopo il POST, ed in ram vengono eseguiti, altri moduli, libs, devices ecc ..., meno cruciali, forse potrebbero rimanere in ROM, risparmiando quindi preziosa ram, ed acceduti dal 68K in ROM.

E' probabile che la libreria DOS metta a disposizione una funzione tipo ChangeDirectory() che può essere direttamente richiamata
dalla shell quando si accorge che il nome digitato è quello di una directory.

Si, ha molto senso ... ho capito.

con i sistemi RTG anche super configurati come il mio AfA One una volta caricato il Workbench la Chip RAM non viene neanche toccata,
quindi avendo molta Fast RAM possiamo far risiedere tutto quello che vogliamo e anche ad una più grande velocità.
Guarda il mio Screenshot quanta ChipRAM è stata consumata dei 2MB dal Workbench disponibili nonostante ci sono icone PNG
di una qualità che Windows si sogna, poi ci sono App animate, uno Slideshow fotografico e altre App

Ma comunque una parte di kick.rom, ovvero il kernel dell'OS diciamo, oltre a tutta la OS-GUI, ovvero il Workbench, insomma tutto questo ben di Dio deve pur risiedere in qualche ram, giusto?

Pertanto, se la chip-ram non viene toccata (in effetti dallo screenshot si vede bene che la chip-ram è solo sfiorata), vuol dire che il tutto risiede in fast-ram, da qualcuno chiamata anche cpu-ram, così che la chip-ram, ovvero la ram acceduta dai chips grafici e audio, tramite i canali DMA offerti da Agnus, non conosca conflitti temporali fra Agnus appunto e CPU, che se la contenderebbero così.

il CLI del 1.3 è preistorico in tutto, prova ad utilizzarlo, un esempio su tutti non puoi richiamare i comandi digitati precedentemente !

Ho capito, quindi la Shell è una CLI più moderna/avanzata, poi da OS2.x in poi Shell = CLI_nuova = terminale avanzato.
Vedi per esempio un caso di grande avanzamento, ovvero la KingCON, la regina delle consoles, dove addirittura abbiamo il completamento automatico dei paths sulla battitura tramite pressione del tasto TAB, come ce li abbiamo sulla shell-bash di Linux oppure su cmd.exe di Windows.
Per inciso, la KingCON, o comunque una Shell di simili prestazioni, l'ho ritrovata di default anche su Kick3.2, intendo proprio internamente al kick3.2.

Dico questo perchè su un mio A600 con CF su porta IDE-44, facendogli fare bootstrap da CF, su una partizione vuota, dove quindi non ho installato WB3.2, sul prompt vedo che il riempimento automatico su shell c'è l'ho subito, e in quel momento in chip-ram ho solo il kick3.2, nella sua quasi interezza (480.000 bytes circa).

Un altro piccolo merito che ho notato su OS3.2, è che basta cliccare due volte sull'icona di un .adf per montare l'adf subito, automaticamente, all'interno del sistema dei files, così da poterci entrare e navigare dentro, come se avessi inserito fisicamente il floppy disk!

[AMIGASYSTEM]

Pertanto, se la chip-ram non viene toccata (in effetti dallo screenshot si vede bene che la chip-ram è solo sfiorata), vuol dire che il tutto risiede in fast-ram, da qualcuno chiamata anche cpu-ram, così che la chip-ram, ovvero la ram acceduta dai chips grafici e audio, tramite i canali DMA offerti da Agnus, non conosca conflitti temporali fra Agnus appunto e CPU, che se la contenderebbero così.

Be si viene utilizzata la FastRam o la RAM della Scheda Video, le prefs caricate dalla ENVARC vengono copiate nella ENV, in RAM restano device, librerie, font ed altro, anche se è possibile smontare o ripulire come per le librerie quando bisogna testarne delle altre senza riavviare il sistema come si fa su PC.

[clros]

Forse un piccolo vantaggio ci sarebbe ed è quello della (mancata) frammentazione della memoria che con i
comandi residenti non avverrebbe. Ma anche questo ormai è un falso problema
vista la grande quantità di memoria RAM disponibile sulle machine moderne (parlo in generale, non di Amiga)

Questo discorso non mi è chiaro, se puoi spiegare meglio.
Stai dicendo che il piccolo vantaggio di rendere i comandi residenti starebbe nel fatto che se li rendiamo residenti, non avremmo
più frammentazione della memoria? Cosa intendi esattamente?

Voglio dire che se un determinato comando/modulo non è residente, ogno volta che viene usato dall'utente l'OS deve:
1) Caricare l'eseguibile dal disco o da ROM in memoria
2) "eseguirlo" (il programma diventa così un processo)
3) liberare la memoria ad esso associata

Se il comando viene eseguito molte volte (es. CD), allora i passi sopra indicati verranno eseguiti più volte.
Il caricamento del programma in memoria (punto 1) comporta che l'OS deve cercare una zona di memoria libera delle corrette dimensioni, marcarla come "occupata", leggere le istruzioni che compongono il programma da disco (o da ROM) e copiarle nella zona RAM appena allocata e iniziare l'esecuzione di tale programma (ovviamente sto descrivendo la cosa in maniera estremamente semplificata!)
Quando il programma termina la sua esecuzione, l'OS deve marcare la zona di memoria ad esso assegnata come "libera" e inserire quel blocco di memoria in una apposita struttura (una lista, un albero, ...) che contiene l'elenco delle zone di memoria libere, pronte per essere assegnate a chi ne faccia richiesta.
Questo processo, ripetuto un certo numero di volte, genera tanti "buchi" in memoria che spesso non sono più utilizzabili perchè troppo piccoli. Capita quindi che pur avendo un ammontare di memoria libera abbastanza grande per far funzionare alcuni programmi, questa memoria è frammentata/spezzettata in tante parti (anche contigue!) e quindi inutilizzabili come un unico blocco.
Si rende quindi necessario adottare delle strategie di allocazione che prevengano la frammentazione o usare delle tecniche che consentano di fondere blocchi liberi contigui ma appartenenti a nodi differenti della lista delle zone libere, in modo da creare blocchi più grandi e quindi realmente utilizzabili.

Ci sarebbe anche in questo caso da scrivere un mondo di cose!

La frammentazione è un problema che affligge un disco, ovvero un file sparso un pò qui e un pò là,

Nel caso della memoria RAM , per frammentazione si intende l'avere tanti pezzetti di memoria libera ma troppo piccoli per essere utilizzabili.

e il ricorso ad allocatori sempre più sofisticati

Stai parlando della componente di un OS, forse anche di AmigaOS, chissà, che riserva un pezzo di ram per allocarci dentro il codice, l'op-code insomma, di un certo comando che è appena stato prelevato, ad esempio, da Sys: C , e messo appunto in chip-ram, e lo stesso modulo dell'OS che ovviamente, oltre ad allocare in ram "normale" il codice.bin del comando/programma, devo anche allocargli un pò di stack ... intendi questo, come "allocatori" ... giusto?

Si, esatto. Oltre a cercare e riservare un "pezzo" di RAM ai programmi che devono essere caricati ed eseguiti (quindi soddisfare le richieste del loader dell'OS), l'allocatore si occupa anche si cercare e riservare richieste di memoria che arrivano direttamente dai programmi in fase di esecuzione, le chiamate alle funzioni C/C++ malloc() e new() e amigaOS AllocMem().

è, in un certo senso, il lavoro egregio che hanno fatto gli sviluppatori di FreeRTOS, ad esempio, partendo da heap1.h, fino ad arrivare a heap5.h, con quest'ultima versione di allocatore dinamico, con la quale adesso l'OS FreeRTOS (per il mondo ARM/Cortex) è in grado di allocare dinamicamente memoria in modo che gli heaps richiesti (tramite le chiamate stile calloc/malloc/new), da più tasks o co-routines, siano contigui fra di loro, in modo compatto, quindi non frammentato in ram, e così ne giova anche la successiva disallocazione (chiamate stile free/delete).

Non conosco FreeRTOS, ma il funzionamento di un buon allocatore è proprio quello che hai descritto

una delle cose che comunque continuano a piacermi di AmigaOS è la cura con cui tutti i componenti sono "amalgamati",
a mio avviso molto migliore rispetto Linux (per esempio, per l'unicità della GUI). Ma siamo fuori tema ;)

Sperando che gli admin ci consentano questi voli pindarici (stiamo pur sempre parlando di Amiga/OS/informatica), dicci qualcosa in più su questo aspetto.
Cosa ha Amiga di migliore, rispetto a GNU/Linux (es: Ubuntu/Raspberry ecc ...), per quanto riguarda l'amalgama dei vari componenti?
Fa degli esempi pratici, per favore ...

Premessa importante: queste sono solo mie considerazioni personali!

Da ex programmatore AmigaOS sono passato in tempi successivi a programmare per un brevissimo periodo per AmigaDE e poi per Linux, fino a passare definitivamente su Windows (adesso in realtà il lavoro di programmazione è diventato secondario)

Oggi uso sia AmigaOS che Linux in macchine virtuali, con poco/zero interesse verso questi OS se non quello di pura curiosità. Ma nel confronto tra i due, nonostante Linux sia un OS moderno e AmigaOS un OS "sempliciotto e primitivo" continuo a preferire AmigaOS per diversi motivi.
L'impressione che ho è quella di un OS che puoi realmente studiare secondo quelli che sono i concetti appresi alle superioni (nel corso di sistemi) sia all'università (Sistemi operativi) per cui hai subito un esempio concreto di quello che studiai relativamente all'architettura degli OS.
Per quanto per una singola persona sia estremamente difficile cogliere anche solo parte degli aspetti implementativi, è facile riconoscere i vari componenti dell'OS stesso (Scheduler, strap, allocatori, filesystem, ecc.), sembra quasi un OS "accademico", senza nessuna pretesa di essere un OS di ricerca ma solo "didattico".
Ed è anche relativamente facile programmarlo. Ai tempi di AmigaOS1.3 (ma anche 2.0) era abbastanza facile conoscere quasi tutti gli aspetti dell'OS.

Chiaramente Linux essendo molto più evoluto è diventato anche estremamente complesso e questo a discapito della facilità di comprensione del funzionamento dell'OS stesso.
Anche Windows è estremamente complesso (molto più di Linux) ma ha dalla sua il fatto diversi aspetti che per me sono importanti:
1) C'è un'unica azienda madre alle spalle che ne cura lo sviluppo e detta regole chiare sulle direzioni da intraprendere in un determinato momento
2) Gli ambienti/tool di sviluppo sono il massimo di quanto si possa chiedere. I framework (.NET /RT, ecc.) sono estremamente efficaci e integrati con l'OS stesso
3) Affidabilità; non ho mai perso nulla sotto Windows, sotto Linux invece ... ho perso lavoro e dati personali e nessuno mi ha mai saputo dire il perchè (anche sui forum ufficiali)
4) relativa facilità di programmazione; C# è meno prolisso di Java (che rimane un ottimo linguaggio ma per scopi a mio avviso didattici), facile da imparare estremamente produttivo.
5) Windows (ma anche amigaOS) hanno pochi framework GUI predefiniti. Questo a mio avviso è un grande vantaggio sia per il programmatore che per l'utente. Linux poi si è talmente tanto frammentato che secondo me non ha nemmeno senso di parlare di un unico sistema operativo; ogni distribuzione è quesi un OS a sè stante. Gli utenti, ma anche i programmatori, apprezzano il fatto che le gui siano coerenti, non hanno voglia e nemmeno tempo di usare/programmare per GUI differenti, ce ne deve essere una che sia di riferimento e che funzioni bene. Perchè perdere tempo con millemila cose differenti?
6) File di configurazioni presenti su Linux in millemila formati differenti, non si capisce niente! Windows e AmigaOS hanno solo pochi formati di config, AmigaOS usa/usava l'IFF mentre ora si stanno tutti orientando verso XML o JSON. Su Linux permangono ancora file di config testuali ma senza omogeneità di formato/semantica.

Cmq, non amo molto scrivere, se vuoi ci possiamo qualche volta anche sentire, sono argomenti per me molto interessanti (soprattutto quelli relativi al funzionamento e alla struttura dell'OS) !

[AMIGASYSTEM]

clros hai fatto la giusta fotografia su Linux, quello che non capisco e come mai gente poca esperta senza la giusta conoscenza parla un gran bene di Linux anche se parliamo del solito 2% mondiale, ma forse perchè non ci fanno nulla oltre ad eseguire qualche semplice App.

[clros]

clros hai fatto la giusta fotografia su Linux, quello che non capisco e come mai gente poca esperta senza la giusta conoscenza parla un gran bene di Linux anche se parliamo del solito 2% mondiale, ma forse perchè non ci fanno nulla oltre ad eseguire qualche semplice App.

Mi sono fatto un'idea in proposito.
La maggior parte della gente che parla di Linux (senza poi realmente usarlo) si *fa figa* dicedo a destra e a manca che linux è bello perchè è open, è free, è libero e non ci sono virus.

Chiedendo a queste persone argomenti concreti a sostegno, però non ho ottenuto nessuna risposta convincente, sono sparate da fan-boy che non sa realmente di cosa si sta parlando. Nello specifico:

1) Open (si intende che è open source, cioè che è disponibile il codice sorgente). La gente che ne parla come un grande vantaggio non conosce la differenza tra un compilatore e un interprete. Dicono che essendo Open è più facile trovare i bug, ma non saranno certo loro a trovarli e poi i bug vengono fuori usando i programmi, non andandosi a guardare chilometri e chilometri di codice. Dicono che si può imparare a programmare dal codice open. Io dico che un team molto bravo e ben pagato può apportare le modifiche che possono essere utili all proprio business, ma una singola persona non saprebbe nemmeno dove andare a cercare. Se si vuole imparare qualcosa dal codice di un sistema operativo, è molto meglio Aros restando in tema amigoso.

2) E' free. Vero, ma altri OS non è che costino poichè chissà quanto. Un utente normale non adotta un OS perchè è gratis, ma perchè ha delle caratteristiche che servono al proprio business.Un utente professionista sa inoltre che oltre al costo dell'OS deve considerare anche il costo di gestione.

3) E' libero. I "linuxari" hanno uno strano modo di intendere la libertà; per me si tratta di una imposizione di alcune idee relative alla distribuzione dei programmi che potrebbero benissimo essere definite dittatoriali. La libertà è ben altra cosa.

4) E' esente da virus. Ma non diciamo minch*ate

Anche secondo me in realtà non ci fanno niente se non eseguire qualche semplice app.

Alle considerazioni sulle "differenze" tra linux e Windows/AmigaOS fatte nel post precedente ad AMG_Novice_Usr, vorrei aggiungere anche queste:

7) incoerenza nella gestione delle azioni della GUI: anche con programmi professionali (io uso/usavo KiCad e LTSpice), fare azioni semplicissime come il copia incolla è un macello o non è proprio possibile. uesto accade anche nelle versioni windows di tali programmi perchè si portano dietro l'inesistente gestione delle azioni della GUI da parte di qualche strambo framework di Linux.
E' snervante non poter usare copia/incolla anche per le cose più semplici. E' snervante non trovare i comandi dove ci si aspetta che siano (i vari menù, quando presenti,hanno una organizzazione "ad cazzum", seguono una logica del tutto sconosciuta).

Sempre negli anni '90 Microsoft introdusse una serie di innovazioni che consentivano di avere una GUI coerente; i comandi copia/taglia e Incolla erano usabili nello stesso modo da qualsiasi applicativo, grazie al supporto del'OS. Anche in AmigaOS questi tre semplici comandi sono implementati sempre e come ci si aspetterebbe, anche se in maniera più semplice che su Windows. in Linux invece...
Sembra una cavolata ma è la base dell'ergonomia di utilizzo; gli utenti si aspettano che le operazioni di base esistano e funzionino nello stesso modo su ogni applicazione; è talmente scontato che nessuno ci fa più caso al fatto che sia presente un caratteristica così basilare. E invece, su Linux no...
A dirla tutta un ragionamento simile si può fare per i comandi a linea di comando; esiste uno "stile" unico per l'invocazione dei comandi CLI sia su MS-DOS che su AamigaOS. Su Linux invece ognuno implementa quello che vuole come vuole.

8) programmi sempre in beta. é vero che il fatto che un programma che abbia come numero di versione qualcosa tipo 0.99.95 potrebbe essere perfettamente funzionante, ma il fatto che abbiano un numero di ver/rev così basso ti fa sempre sospettare che qualcosa non sia a posto, non sia completo, che ci sia qualche big. Psicologicamente non sono tanto portato ad usare un programma con un numero di versione simile.

[AMIGASYSTEM]

Chiedendo a queste persone argomenti concreti a sostegno, però non ho ottenuto nessuna risposta convincente, sono sparate da fan-boy che non sa realmente di cosa si sta parlando. .

Infatti memorizzano qualche stringa oppure usano terminologia molto tecnica (magari inventata) per dimostrare la loro grande esperienza informatica e poi magari si perdono se devono creare qualcosa anche elementare.

Io sono un autodidatta, mi ritengo uno "zappatore dell' informatica" che grazie ad un Amiga 500Plus comprato a mio figlio mi sono appassionato per poi fare la stessa cosa su PC e gestire tanti utenti e una rete intera per 10 anni nella mia Amministrazione, nonostante tutto questo ho ancora tanto da imapare età permettendo ormai vicino ai 70 anni.

[AMG_Novice_Usr]

le prefs caricate dalla ENVARC vengono copiate nella ENV

Vediamo se ho capito qualcosa ...

Quando io setto qualche preferenza, es: 19200 di baud-rate della porta seriale Rs232, anzichè il valore di default di 9600, e sopratutto se clicco sul bottone SAVE (non USE, clicco proprio su SAVE), allora Amiga salva questo settaggio, ed in generale tutte le mie customizzazioni di prefs, nel path:

Sys: Prefs/Env-Archive

nel mio caso particolare, dato che la mia installazione di OS3.2 si trova per mia scelta nella partizione UDH0 della CF, posso dire:

UDH0: Prefs/EnvArc

Bene, al momento ho salvato su CF, quindi in modo non volatile, le mie prefs in EnvArc.

Se io spengo e poi riaccendo Amiga, AmigaDOS (dopo tutta una serie di azioni precedenti, già discusse in questo thread) interpreta la startup-sequence, nella quale troviamo (riporto solo i passaggi che mi interessano adesso):

C: MakeDir RAM: Env
C: Assign >NIL: Env: RAM: Env
C: Copy >NIL: EnvArc: Env: ALL NOREQ

pertanto, viene prima creato il drawer invisibile Env in RAM: , o meglio in RamDisk, poi gli viene assegnato il nome che vogliamo (Env: ), e poi viene copiato tutto il contenuto delle prefs, salvate da noi in precedenza, dentro il path su CF:

Sys: Prefs/Env-Archive

in RamDisk: Env

Pertanto in RAM, o meglio in RamDisk, noi abbiamo tutti i settaggi.

Poi non so se RamDisk è una porzione di ram ricavata dalla chip-ram oppure dalla fast-ram, oppure nel caso di un Amiga emulato su PC/x86-x64/WinUAE, dalla G-RAM, ad ogni modo una parte di ram è impegnata nel tenere "residenti" (forse il termine è un pò improprio qui, vista la discussione che abbiamo tenuto finora, ma passatemelo lo stesso, è per capirci) le prefs.

Se io, nel settaggio per esempio delle caratteristiche cinetiche del mouse, imposto speed = 3 con accelerazione, dopodichè anzichè cliccare sul bottone SAVE, clicco semplicemente il bottone USE, tale preferenza custom viene scritta solo su:

RamDisk: Env

vale a dire su:

RAM: Env

o detto più semplicemente, in virtù dell'assign di prima:

Env:

ma NON viene scritto anche su memoria di massa, ovvero su:

Sys: Prefs/Env-Archive

pertanto se spengo e poi riaccendo, è chiaro che ritrovo le prefs del mouse predefinite, dato che Env: viene sovrascritto dal copy nella startup-sequence, partendo dall'ENVARC.

Domanda 1:

se io e te abbiamo 2 Amiga uguali, intendo ad esempio due A600, e io voglio configurare le mie prefs uguali identiche alle tue, è sufficiente che tu mi passi il contenuto del tuo:

Sys: Prefs/Env-Archive

ed io lo sostituisco al mio? tutto qui?

Domanda 2:

Dentro " Sys: Prefs/Env-Archive " ci vanno solo le prefs del WB, quando io clicco SAVE anzichè USE, oppure ci vanno anche le preferenze salvate di applicazioni/programmi che non siano prettamente il WB?

Domanda 3:

è davvero indispensabile rendere "residente" (= mettere in ram, in ram-disk) il contenuto di:

Sys: Prefs/Env-Archive

in:

RAM: Env

??

dopo chiaramente aver creato quest'ultimo path ... oppure si potrebbe dire ad Amiga "Amiga, te ed il programma IPrefs fate riferimento non a RAM: Env, bensì al path su memoria di massa Sys: Prefs/Env-Archive".

Per sistemi con poca RAM, forse sarebbe auspicabile ... non so ... ma bisogna vedere se è tecnicamente possibile ...

[AMG_Novice_Usr]

Gli ambienti/tool di sviluppo sono il massimo di quanto si possa chiedere.
I framework (.NET /RT, ecc.) sono estremamente efficaci e integrati con l'OS stesso

Pensa che il framework .NET (non ricordo bene se 3.5 o giù di lì, è un'esperienza che ho fatto mesi e mesi fa, e per me sono tanti) mi si è installato ed era pure funzionante su Raspberry PI 4, con sopra girante non Rasbian, bensì una distro non ufficiale di Windows10, appartenente al progetto WoR, ovvero Windows On Raspberry, quindi tutta la potenza/familiarità/semplicità di Win10, e non su architettura x86 o x64, ma sulla piattaforma ARM-Raspberry, adatta ad esempio ad un mondo industriale/embedded con velleità di industria 4.0 + IoT.

Le app scritte con MS-VisualStudio per PC/x86, giravano anche su .NET su Raspberry Pi 4.
Avevo solo un grosso problema con i drivers per i dongle USB / Rs232 ... problema che non ho mai risolto, poi sono passato ad altro ... e tutto è rimasto floating ... se sei interessato a saperne di più, ci possiamo sentire nel merito.

Cmq, non amo molto scrivere, se vuoi ci possiamo qualche volta anche sentire, sono argomenti
per me molto interessanti (soprattutto quelli relativi al funzionamento e alla struttura dell'OS) !

Magari, sarebbe bello: avrei l'occasione di imparare molto!

Linux vs Windows

Alcuni miei colleghi/amici linuxiani mi hanno sempre detto che su Linux non abbiamo frammentazione su memorie di massa fatte da dischi classici a tracce, HDD quindi.

Mi informai alla bene e meglio sulla cosa, e in effetti pareva, da una lettura che feci, che Linux implementa "on-the-fly" un meccanismo che impedisce di fatto la frammentazione, purchè i files non siano eccessivamente grossi, su dischi meccanici a tracce.

In sostanza Linux tiene ciascun file separato dagli altri, con uno spazio su disco di pre-file ed uno di post-file diciamo, degli spazi
di guardia, abbastanza grandi, in modo che anche se l'utente, durante una sessione di lavoro, ingrandisce abbastanza quel file, il file
non è mai costretto a cercare ulteriore spazio altrove nel disco, frammentandosi.

Essendo lo spazio su disco prima di quel file e lo spazio su disco dopo il file belli grossi (una specie di back e front porch, se il file fosse una riga visibile sul CRT), il file per frammentarsi dovrebbe ingigantirsi enormemente durante una sessione di editing, e comunque Linux realizza dei controlli ed è in grado di rimodulare (aumentare) questi due spazi di pre e di post-file all'occorrenza ... insomma ... con Linux non abbiamo frammentazione.

Invece Windows non possiede tale meccanismo.

Così mi è stata propinata la cosa.
Ti risulta?

[AMG_Novice_Usr]

3) E' libero. I "linuxari" hanno uno strano modo di intendere la libertà; per me si tratta di una imposizione di alcune idee relative alla distribuzione dei programmi che potrebbero benissimo essere definite dittatoriali. La libertà è ben altra cosa.

Ho riletto le tue idee sul discorso di Linux in bocca ai finti esperti ... posso essere d'accordo su un pò tutta la linea.
Vorrei tuttavia una spiegazione sul punto 3 ... me lo spieghi meglio?
Stai parlando della GPL/GPL3 o fac-simili?

Premetto che io non ho mai letto le GPL di GNU/Linux e app affini, le MS-EULA ecc ... non mi sono mai interessato a questi aspetti: di lavoro scrivo FW per microcontrollori, quindi il mio interesse è rivolto assai di più su altre cose, tuttavia se puoi sintetizzare il concetto in modo semplice e chiaro, per me è tutta cultura che entra, e ti ringrazio in anticipo per questo! ;-)