Re: RISC-V: quanta parte del processore ha licenza libera?
> "MB" == Marco Bodrato writes: MB> Saluton Marco, Il 2021-03-10 19:54 Marco Ciampa ha scritto: >> Concordo pienamente (lacrimuccia pensando allo Z80 e ai bei tempi >> dell'assembler...) MB> Son quasi dieci anni che non tocco l'assembler dello Z80, ma MB> ricordo con certezza che usa i flag; anzi, c'è proprio il registro MB> F, ad 8-bit come tutti gli altri! Credo che fosse una "costante" dei processori. Lo Z80 non lo conosco, ma c'era sul 6502 (un RISC senza registri :) ), PDP-11, 68000... -- Gian Friends will be friends right to the end!
Re: RISC-V: quanta parte del processore ha licenza libera?
Non ho conosciuto quello dello Z80, però mi ricordo quello del Commodore 64 è passato un po' di tempo! Stefano On 11/03/21 08:53, Marco Bodrato wrote: Saluton Marco, Il 2021-03-10 19:54 Marco Ciampa ha scritto: Concordo pienamente (lacrimuccia pensando allo Z80 e ai bei tempi dell'assembler...) Son quasi dieci anni che non tocco l'assembler dello Z80, ma ricordo con certezza che usa i flag; anzi, c'è proprio il registro F, ad 8-bit come tutti gli altri! Ma m'hai fatto venir voglia di riguardare quell'algoritmo di divisione scritto allora per sdcc... Ĝis, m
Re: RISC-V: quanta parte del processore ha licenza libera?
Saluton Marco, Il 2021-03-10 19:54 Marco Ciampa ha scritto: Concordo pienamente (lacrimuccia pensando allo Z80 e ai bei tempi dell'assembler...) Son quasi dieci anni che non tocco l'assembler dello Z80, ma ricordo con certezza che usa i flag; anzi, c'è proprio il registro F, ad 8-bit come tutti gli altri! Ma m'hai fatto venir voglia di riguardare quell'algoritmo di divisione scritto allora per sdcc... Ĝis, m
Re: RISC-V: quanta parte del processore ha licenza libera?
On Wed, Mar 10, 2021 at 11:27:54AM +0100, Gian Uberto Lauri wrote: > Ma diamine, quanto mi mancava leggere cose del genere... Concordo pienamente (lacrimuccia pensando allo Z80 e ai bei tempi dell'assembler...) -- Saluton, Marco Ciampa
Re: RISC-V: quanta parte del processore ha licenza libera?
> "AR" == Alessandro Rubini writes: AR> riscv-spec-20191213.pdf pagina 23 (ricordavo bene): AR>The conditional branches were designed to include arithmetic AR> comparison operations between two registers (as also done in AR> PA-RISC, Xtensa, and MIPS R6), rather than use condition codes AR> (x86, ARM, SPARC, PowerPC), or to only compare one register AR> against zero (Alpha, MIPS), or two registers only for equality AR> (MIPS). This design was motivated by the observation that a AR> combined compare-and-branch instruction fits into a regular AR> pipeline, avoids additional condition code state or use of a AR> temporary register, and reduces static code size and dynamic AR> instruction fetch traffic. Another point is that comparisons AR> against zero require non-trivial circuit delay (especially after AR> the move to static logic in advanced processes) and so are almost AR> as expensive as arithmetic magnitude compares. Another advantage AR> of a fused compare-and-branch instruction is that branches are AR> observed earlier in the front-end instruction stream, and so can AR> be predicted earlier. There is perhaps an advantage to a design AR> with condition codes in the case where multiple branches can be AR> taken based on the same condition codes, but we believe this case AR> to be relatively rare. Lo so, non si fa, non si cita un grosso blocco di testo per un commento di due righe... Ma diamine, quanto mi mancava leggere cose del genere... GRAZIE! -- /\ ___Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_ African word //--\| | \| | Integralista GNUslamicomeaning "I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso...Debian" Warning: gnome-config-daemon considered more dangerous than GOTO
Re: RISC-V: quanta parte del processore ha licenza libera?
>> La differenza e` che riscV e` stato pensato tenendo in >> considerazione tutta l'esperienza del settore, prendendo il meglio di >> tutte le idee precedenti e scartando gli errori (per esempio, se >> ricordo bene, non ha un registro "flags", e il manuale spiega >> perche`). > > Questa è interessante, dove la trovo? riscv-spec-20191213.pdf pagina 23 (ricordavo bene): The conditional branches were designed to include arithmetic comparison operations between two registers (as also done in PA-RISC, Xtensa, and MIPS R6), rather than use condition codes (x86, ARM, SPARC, PowerPC), or to only compare one register against zero (Alpha, MIPS), or two registers only for equality (MIPS). This design was motivated by the observation that a combined compare-and-branch instruction fits into a regular pipeline, avoids additional condition code state or use of a temporary register, and reduces static code size and dynamic instruction fetch traffic. Another point is that comparisons against zero require non-trivial circuit delay (especially after the move to static logic in advanced processes) and so are almost as expensive as arithmetic magnitude compares. Another advantage of a fused compare-and-branch instruction is that branches are observed earlier in the front-end instruction stream, and so can be predicted earlier. There is perhaps an advantage to a design with condition codes in the case where multiple branches can be taken based on the same condition codes, but we believe this case to be relatively rare. [...] saluti /alessandro
Re: RISC-V: quanta parte del processore ha licenza libera?
On Sat, Mar 06, 2021 at 12:17:35PM +0100, Alessandro Rubini wrote: [...] Grazie Ale, come sempre esaustivo... > open-risc, lm32, zpu, anche sparc e` stato liberato (e di sparc32 > esistono implementazioni libere), piu` sicuramente mille altri che non > conosco. La differenza e` che riscV e` stato pensato tenendo in > considerazione tutta l'esperienza del settore, prendendo il meglio di > tutte le idee precedenti e scartando gli errori (per esempio, se > ricordo bene, non ha un registro "flags", e il manuale spiega > perche`). Questa è interessante, dove la trovo? -- Saluton, Marco Ciampa
Re: RISC-V: quanta parte del processore ha licenza libera?
aggiungo a questo thread alcune info su RISC-V o collegate a questa e a Debian. Ho letto questo articolo: https://hardware.slashdot.org/story/21/03/08/2117238/mips-technologies-joins-risc-v-moves-to-open-source-isa-standard non ho capito se è un bene o no quanto riporta rispetto a RISC-V. Però c'è da dire che mips 8 sembra che sarà basato su RISC-V e quindi sarà un'architettura hardware differente rispetto alla versione precedente... quindi Debian offrirà pacchetti per mips 8 su un'altra architettura hardware... e l'architettura mips attuale sarà a lungo andare abbandonata... Ma leggendo i commenti ho trovato altri siti interessanti: * https://www.crowdsupply.com/eoma68/micro-desktop/updates ho guardato velocemente e sembrano esserci progetti hardware interessanti, alcuni montano Debian come sistema operativo. Notare che tutti i progetti hardware sono finanziati con crowfounding e spesso hanno versato molto più del richiesto, a volte fino a quasi 4 volte tanto... * https://openrisc.io/ questo però sembra non più aggiornato dal 2019 * https://libre-soc.org/ anche questo sembra interessante... nel tutorial dice: installate Debian :-) in questo sito c'è un'attività per Parerga :-) Also, individuals with experience in formal mathematical verification are quite welcome. Ciao Davide -- Fate una prova di guida ... e tenetevi la macchina!: http://linguistico.sf.net/wiki/doku.php?id=usaooo2 Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: RISC-V: quanta parte del processore ha licenza libera?
> Sì, ma mi sembra che l'argomentazione sia, se mi permettete la metafora, > che è come avere il kernel libero senza il sistema operativo libero. Esatto. Ma c'e` anche chi ha fatto il resto. > E qui mi dichiaro semplicemente incompetente, cioè: ci sono tante > alternative libere alle altre componenti? Tante no, ma ci sono alcune realta` (anche italiane) che ci lavorano. Ho partecipato a due conferenze di opern risc (orconf) -- un'altra achitettura libera -- ma alla fine si parlava piu` di riscV che di ORsoc. Adesso non so fare nomi, ma ce ne sono una dozzina in cui le parti chiuse sono veramente limitate (per esempio la RAM o altri blocchi "standard" del produttore di silicio da cui si va). L'altro uso interessante e` nelle FPGA, in cui puoi avere un sistema completamente libero, col "solo" limite che sei inchiodato mani e piedi (e corona di spine) al chi fa le tue FPGA. I sistemi "white rabbit" del cern per esempio, sono completamente liberi (software gateware e hardware) ma l'fpga e` un po' un paletto. Ormai ci sono solo due venditori importanti di fpga, e il laboratorio che usa white rabbit sull'altra marca ha avuto le sue non piccole difficolta` iniziali. [nessun riferimento, wikipedia mi flagellerebbe] Anche qui, la ram e altri blocchi standard (PLL e cose cosi`) si prendono a scatola chiusa dai moduli nella FPGA in uso. Si, l'autore del video parla di fpga, solo che non e` un settore di nicchia come lo dipinge. E lo stesso codice che prima compili per fpga poi lo compili per fare il silicio con modifiche marginali(lo dice anche lui, mi sono accorto). Poi, come si diceva, per fare il silicio serve l'azienda. Anche i PCB li disegno con kicad ma poi devo pagare per produrli, e i costi fissi si vedono; quelli per il silicio sono enormi. [128 bit] > Beh, qualche processore ha almeno la somma a 128 (l'architettura Z dei > processori dei mainframe)... Non e` come avere l'archiettura a 128 bit. > vedo che state tenendo in considerazione soprattutto > l'indirizzamento della memoria, Per numero di bit dell'architettura solitamente si intende la dimensione "naturale" dei registri macchina e dei bus interni al micro. Quinti atmega (arduino) e PIC sono 8 bit, come lo z80 e il 6502, anche se hanno alcune operazioni a 16 bit. Il motivo per cui oggi si preferisce il 64 bit e` esclusivamente la memoria: con i puntatori a 32 bit vedi solo 4GB, infatti il PC ha fatto l'accrocchio chiamato PAE (page address extension), che e` solo una rivisitazione del vecchio "high memory" del dos, dove un processore con 20 bit di indirizzamento esterno non bastava piu`. Io preferisco il 32 bit, personalmente, perche` gli eseguibili sono piu` piccoli e il sistema piu` veloce. Dopo di che il mondo PC e` obeso e installo anch'io a 64. > ma per la crittografia non guasterebbe una bella istruzione per > calcolare in una botta sola il prodotto di due registri a 128 bit > :-) Non lo metto in dubbio. Cosi` come chi ha la virgola mobile in hardware solitamente implementa IEEE-754 a 80 bit, ma questo non ne fa processori "a 80 bit". > Comunque, di insiemi di istruzioni per una CPU che siano libere, ne > esistono anche altre, oltre a Risc-V... open-risc, lm32, zpu, anche sparc e` stato liberato (e di sparc32 esistono implementazioni libere), piu` sicuramente mille altri che non conosco. La differenza e` che riscV e` stato pensato tenendo in considerazione tutta l'esperienza del settore, prendendo il meglio di tutte le idee precedenti e scartando gli errori (per esempio, se ricordo bene, non ha un registro "flags", e il manuale spiega perche`). grazie, saluti /alessandro
Re: RISC-V: quanta parte del processore ha licenza libera?
Ciao, Il 2021-03-05 18:50 Alessandro Rubini ha scritto: Tutti sono entusiasti di risc-V perche` e` libero, mentre la tesi di Andreas Speiss e` che la parte libera e` trascurabile sul totale e i chip li trovi fatti dai soliti vendor che prendono un pezzo libero e lo blindano nel loro mondo proprietario. Sì, ma mi sembra che l'argomentazione sia, se mi permettete la metafora, che è come avere il kernel libero senza il sistema operativo libero. E` vero, ma non ci sono solo loro. E qui mi dichiaro semplicemente incompetente, cioè: ci sono tante alternative libere alle altre componenti? In ogni caso, anche se fosse solo una componente, è comunque interessante. Inoltre riscV e` l'unica architettura gia` definita nella sua versione a 128 bit. A 128-bit port is simply not realistic at this time. Certo. Non e` un problema di risc-V, e` il mondo che non e` pronto. Beh, qualche processore ha almeno la somma a 128 (l'architettura Z dei processori dei mainframe)... vedo che state tenendo in considerazione soprattutto l'indirizzamento della memoria, ma per la crittografia non guasterebbe una bella istruzione per calcolare in una botta sola il prodotto di due registri a 128 bit :-) Comunque, di insiemi di istruzioni per una CPU che siano libere, ne esistono anche altre, oltre a Risc-V... Ĝis, m
Re: RISC-V: quanta parte del processore ha licenza libera?
On Fri, Mar 05, 2021 at 06:50:50PM +0100, Alessandro Rubini wrote: > > io lo vedo l'articolo, ma è davvero stringato > > Ok, anch'io. Non lo chiamo articolo, per me e` l'occhiello del video. > > > purtroppo io conosco poco di hardware e non ho capito cosa intendi per > > "rema contro". > > Tutti sono entusiasti di risc-V perche` e` libero, mentre la tesi di > Andreas Speiss e` che la parte libera e` trascurabile sul totale e i > chip li trovi fatti dai soliti vendor che prendono un pezzo libero e > lo blindano nel loro mondo proprietario. > > E` vero, ma non ci sono solo loro. Secondo me qui tutti state facendo un po' di confusione. È l'architettura ISA (instruction set architecture) che è libera, non la sua implementazione. Questo vuol dire che chiunque potrà fare un risc-v open o closed ma _nessuno_ potrà chiedere royalties a nessun altro se si parte da una implementazione originale. Posso fare altrettanto con ARM? No. Se si fa un ARM "open" bisogna comunque dare l'obolo a ARM (in futuro NVidia) e difatti non ci sono implementazioni ARM libere, né in silicio né sottoforma di macro VHDL, Verilog o altro, perché ci sono royalties sull'ISA che _non_ è open. Quindi l'intera questione su se un processore sia o meno open non ha molto senso: se il produttore lo farà open, allora lo sarà. E se uno vuole, può farselo open, nessuno glielo potrà impedire, ma solo per RISC-V. -- Saluton, Marco Ciampa
Re: RISC-V: quanta parte del processore ha licenza libera?
> io lo vedo l'articolo, ma è davvero stringato Ok, anch'io. Non lo chiamo articolo, per me e` l'occhiello del video. > purtroppo io conosco poco di hardware e non ho capito cosa intendi per > "rema contro". Tutti sono entusiasti di risc-V perche` e` libero, mentre la tesi di Andreas Speiss e` che la parte libera e` trascurabile sul totale e i chip li trovi fatti dai soliti vendor che prendono un pezzo libero e lo blindano nel loro mondo proprietario. E` vero, ma non ci sono solo loro. >> Inoltre riscV e` l'unica architettura gia` definita nella sua versione >> a 128 bit. > > questo lo avevo visto e mi ero stupito... ma non avevo indagato oltre Cito sotto. > A 128-bit port is simply not realistic at this time. > https://wiki.debian.org/RISC-V Certo. Non e` un problema di risc-V, e` il mondo che non e` pronto. Sull'idea di avere un 128 bit gia` definito, cito la specifica dell'architettura: Although 64-bit address spaces are a requirement for larger systems, we believe 32-bit address spaces will remain adequate for many embedded and client devices for decades to come and will be desirable to lower memory traffic and energy consumption. In addition, 32-bit address spaces are sufficient for educational purposes. A larger flat 128-bit address space might eventually be required, so we ensured this could be accommodated within the RISC-V ISA framework. E piu` avanti: The primary reason to extend integer register width is to support larger address spaces. It is not clear when a flat address space larger than 64 bits will be required. At the time of writing, the fastest supercomputer in the world as measured by the Top500 benchmark had over 1 PB of DRAM, and would require over 50 bits of address space if all the DRAM resided in a single address space. Some warehouse-scale computers already contain even larger quantities of DRAM, and new dense solid-state non-volatile memories and fast interconnect technologies might drive a demand for even larger memory spaces. Exascale systems research is targeting 100 PB memory systems, which occupy 57 bits of address space. At historic rates of growth, it is possible that greater than 64 bits of address space might be required before 2030. History suggests that whenever it becomes clear that more than 64 bits of address space is needed, architects will repeat intensive debates about alternatives to extending the address space, including segmentation, 96-bit address spaces, and software workarounds, until, finally, flat 128- bit address spaces will be adopted as the simplest and best solution. We have not frozen the RV128 spec at this time, as there might be need to evolve the design based on actual usage of 128-bit address spaces. Non ho parole. Chapeau. saluti /alessandro
Re: RISC-V: quanta parte del processore ha licenza libera?
On 05/03/21 09:55, Alessandro Rubini wrote: Leggendo questo articolo: https://hackaday.com/2021/02/27/exploring-the-open-source-that-really-goes-into-a-risc-v-chip/ Non ho trovato l'articolo, solo il filmato. Qualcuno mi aiuta? io lo velo l'articolo, ma è davvero stringato quando non vedo un sito web o quando un sito web richiede troppi javascript e altro di terze parti o inizia a chiederti di verificare che tu non sia un robot io lo guardo tramite archive: https://archive.org/web/ in questo caso per quella pagina web: https://web.archive.org/web/20210228231904/https://hackaday.com/2021/02/27/exploring-the-open-source-that-really-goes-into-a-risc-v-chip/ https://www.youtube.com/watch?v=VdPsJW6AHqc Non dice nulla di sbagliato (e meno male che si puo` guardare a 2x), puoi anche scaricartelo con youtube-dl e guardarlo con mpv dove hai il pieno controllo su velocità e molto altro ma chiaramente vuole far passare il suo punto di vista, che non e` per forza oggettivo. Anche perche` remare contro oggi e` l'unico modo non cruento o volgare per avere visibilita` -- poi, ripeto, rema contro molto correttamente. purtroppo io conosco poco di hardware e non ho capito cosa intendi per "rema contro". Inoltre riscV e` l'unica architettura gia` definita nella sua versione a 128 bit. questo lo avevo visto e mi ero stupito... ma non avevo indagato oltre guardando adesso vedo che: 1) the 128-bit ISA remains "not frozen" intentionally, because there is yet so little practical experience with such large memory systems https://en.wikipedia.org/wiki/RISC-V 2) While 32-bit and 128-bit implementations are possible, there are problems with this: [...] A 128-bit port is simply not realistic at this time. https://wiki.debian.org/RISC-V Quindi in pratica non avresti qualcosa di usabile Sono profondamente convinto che riscV sia la strada giusta, ma non possiamo seguirla senza grossi investimenti sul silicio per i quali e` necessaria una pesante collaborazione aziendale. Ma il rischio del monopolio e` molto minore che in tutte le altre strade. è l'idea che mi sono fatto anch'io, anche vedendo quel filmato... Ciao Davide -- Motivi per non comprare/usare ms-windows7: http://windows7sins.org/ Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: RISC-V: quanta parte del processore ha licenza libera?
On Fri, Mar 05, 2021 at 09:55:24AM +0100, Alessandro Rubini wrote: [...] > Sono profondamente convinto che riscV sia la strada giusta, ma non > possiamo seguirla senza grossi investimenti sul silicio per i quali > e` necessaria una pesante collaborazione aziendale. Ma il rischio > del monopolio e` molto minore che in tutte le altre strade. Idem, la penso esattamente allo stesso modo. -- Saluton, Marco Ciampa
Re: RISC-V: quanta parte del processore ha licenza libera?
> Leggendo questo articolo: > https://hackaday.com/2021/02/27/exploring-the-open-source-that-really-goes-into-a-risc-v-chip/ Non ho trovato l'articolo, solo il filmato. Qualcuno mi aiuta? > e guardando il filmato indicato (purtroppo è in inglese): > https://www.youtube.com/watch?v=VdPsJW6AHqc > > è possibile capire molto di più cosa sia RISC-V e come sono distribuite > le sue componenti. Non dice nulla di sbagliato (e meno male che si puo` guardare a 2x), ma chiaramente vuole far passare il suo punto di vista, che non e` per forza oggettivo. Anche perche` remare contro oggi e` l'unico modo non cruento o volgare per avere visibilita` -- poi, ripeto, rema contro molto correttamente. > Leggendo vari articoli mi ero fatto l'idea che l'intero RISC-V più tutto > quello che gli gira attorno fosse distribuito con licenze libere... Ci sono dei mondi liberi, e dei mondi meno. Anche linux sta dentro android, ma senza tutta la fuffa sopra non puoi usarlo. > ...vedendo però il filmato si capisce che non è affatto così, anche se > vi sono degli spunti positivi che potrebbero di avere in un futuro, > purtropo non troppo vicino, un hardware con licenze completamente libere. Ci sono, ci sono. Sono prodotti di nicchia, ma qualcuno che ha fatto il silicio bene c'e`. Certo, non puoi metterlo nel portatile di tutti i giorni. Le potenzialita` sono enormi. Anche se "riscV" e` *solo* la ISA, e` fatta molto molto molto bene: un mio collega ha scritto un riscV in un fine settimana, passando tutti i test (no, non e` nella media dei progettisti). Invece non condivido questo entusiasmo per le fpga: sara` anche tutto libero il gateware che ci gira, ma il contentitore e` blindatissimo e si e` comunque dipendenti da un'unica azienda e dalle sue politiche di prezzi e produzione (si, il riscV del collega e` per fpga, e per farlo andare ci sono tante dipendenze dal vendor e modello specifico di chip in cui viene istanziato). Inoltre riscV e` l'unica architettura gia` definita nella sua versione a 128 bit. Consiglio caldamente a chi si interessa di ISA di passare una serata a leggersi quella riscV, magari poi ne scrive uno il fine settimana dopo, come il mio collega. Ah, quando l'ho conosciuto, stava scrivendo un cortex-M3. Peccato che sia piu` vietato dell'omicidio. Tutto il codice, e tutti i compilatori, che abbiamo scritto per ARM dipendono pesantemente dall'invidia di ARM. Sono profondamente convinto che riscV sia la strada giusta, ma non possiamo seguirla senza grossi investimenti sul silicio per i quali e` necessaria una pesante collaborazione aziendale. Ma il rischio del monopolio e` molto minore che in tutte le altre strade.
Re: RISC-V: quanta parte del processore ha licenza libera?
On Mon, Mar 01, 2021 at 08:56:36PM +0100, Davide Prina wrote: > Leggendo questo articolo: > https://hackaday.com/2021/02/27/exploring-the-open-source-that-really-goes-into-a-risc-v-chip/ > > e guardando il filmato indicato (purtroppo è in inglese): > https://www.youtube.com/watch?v=VdPsJW6AHqc > > è possibile capire molto di più cosa sia RISC-V e come sono distribuite le > sue componenti. > > Leggendo vari articoli mi ero fatto l'idea che l'intero RISC-V più tutto > quello che gli gira attorno fosse distribuito con licenze libere... > > ...vedendo però il filmato si capisce che non è affatto così, anche se vi > sono degli spunti positivi che potrebbero di avere in un futuro, purtropo > non troppo vicino, un hardware con licenze completamente libere. > > C'è anche una parte dove si parla di Debian, con un errore nel sito > visualizzato. Mi sono accorto che ogni distro si è fatta una fama e tutti > dichiarano per vero tale fama, anche se non è così ora o non è mai stato > così (un po' come l'errore di pubblicazione sugli spinaci che gli davano una > quantità di ferro astronomica, quando in realtà vi sono altri vegetali che > ne contengono di più, ma ormai per tutti gli spianaci sono i vegetali che > hanno più ferro di qualsiasi altro). > > In generale Debian è ritenuta: > * contenere solo software libero (quindi se vuoi/devi installare parti > proprietarie è sconsigliata, non funziona su determinati hardware, ...) > * contenere software non aggiornato da tanto tempo (parlano di stable... e > quindi sconsigliano l'uso per chi non vuole avere software obsoleto che non > funziona su hardware recente) > * viene rilasciata ogni morte di papa e non si sa mai la data in cui sarà > rilasciata (questa era la politica del rilascio di stable) > * è usata/usabile solo per server > * ... Concordo ma alcune delle cose che dici _erano_ vere tanto tempo fa, come gli spinaci, per un po' è stato un errore "ufficiale". È l'inerzia dell'informazione. Come la gente che scarica le batterie al litio (rovinandole) credendo che sia come per le vecchie nichel-cadmio... -- Saluton, Marco Ciampa
Re: RISC-V: quanta parte del processore ha licenza libera?
Il 01/03/21 20:56, Davide Prina ha scritto: [...] In generale Debian è ritenuta: * contenere solo software libero (quindi se vuoi/devi installare parti proprietarie è sconsigliata, non funziona su determinati hardware, ...) * contenere software non aggiornato da tanto tempo (parlano di stable... e quindi sconsigliano l'uso per chi non vuole avere software obsoleto che non funziona su hardware recente) * viene rilasciata ogni morte di papa e non si sa mai la data in cui sarà rilasciata (questa era la politica del rilascio di stable) * è usata/usabile solo per server non si capisce perché molti parlino ed esprimano giudizi su cose che non conoscono... Ma in effetti non c'è da stupirsene... Piviul
