Debian 8 i targetes grafiques AGP

2017-11-30 Conversa Narcis Garcia 
Protesto una vegada més.
Tot i que sovint no tinc raó, almenys aquesta llista serveix per
contrastar el què un percep quan confronta la teoria amb la realitat.

Tinc 6 models diferents (9 si comptem els repetits) de targeta gràfica
AGP que funcionen amb les 2 plaques base diferents que tinc per «Socket
7», on s'hi endollen els «Intel Pentium» famosos (i586).

Doncs bé, amb Debian 8 (jessie) tot i suposadament mantenir el suport
per i586, es van retirar els controladors gràfics (si, si, privatius)
per la majoria de targetes que s'endollen en aquesta generació d'ordinadors.
En el meu cas m'afecten: s3virge, savage, nvidia-legacy-96xx i
nvidia-legacy-173xx (nouveau no hi funciona). Matrox o targetes PCI ja
«ni te cuento».

El nucli i/o aplicacions compilats per i586 (8/jessie) semblen tirar una
mica més ràpid que els compilats per i486 (7/wheezy), però això no
compensa la falta d'acceleració gràfica per un ús acceptable de les
finestres.
Així que m'hauré de quedar amb Debian 7!

La meva conclusió és que Debian 8 per i586 no va tenir gaire sentit amb
aquesta retirada de paquets: Per escriptori és majoritàriament inviable
pel tema gràfic, i sense escriptori en aquest maquinari* es nota bastant
més ràpida l'arrencada amb el System V de Debian 7.

(*) Molta RAM, disc dur ràpid... l'únic coll d'ampolla: el processador.

(deb-cat) Debian 8 i targetes grafiques AGP

2017-11-30 Conversa Narcis Garcia 
Protesto una vegada més.
Tot i que sovint no tinc raó, almenys aquesta llista serveix per
contrastar el què un percep quan confronta la teoria amb la realitat.

Tinc 6 models diferents (9 si comptem els repetits) de targeta gràfica
AGP que funcionen amb les 2 plaques base diferents que tinc per «Socket
7», on s'hi endollen els «Intel Pentium» famosos (i586).

Doncs bé, amb Debian 8 (jessie) tot i suposadament mantenir el suport
per i586, es van retirar els controladors gràfics (si, si, privatius)
per la majoria de targetes que s'endollen en aquesta generació d'ordinadors.
En el meu cas m'afecten: s3virge, savage, nvidia-legacy-96xx i
nvidia-legacy-173xx (nouveau no hi funciona). Matrox o targetes PCI ja
«ni te cuento».

El nucli i/o aplicacions compilats per i586 (8/jessie) semblen tirar una
mica més ràpid que els compilats per i486 (7/wheezy), però això no
compensa la falta d'acceleració gràfica per un ús acceptable de les
finestres.
Així que m'hauré de quedar amb Debian 7!

La meva conclusió és que Debian 8 per i586 no va tenir gaire sentit amb
aquesta retirada de paquets: Per escriptori és majoritàriament inviable
pel tema gràfic, i sense escriptori en aquest maquinari* es nota bastant
més ràpida l'arrencada amb el System V de Debian 7.

(*) Molta RAM, disc dur ràpid... l'únic coll d'ampolla: el processador.





__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Re: (deb-cat) microcode per CPU = ? privatiu

2017-11-30 Conversa Xavi Drudis Ferran 
El Thu, Nov 30, 2017 at 07:46:32PM +0100, Narcis Garcia deia:
> He fet més de 10 instal·lacions de Debian 8 a l'ordinador i586, i unes
> quantes de Debian 7. Totes des de zero (disc en blanc):
> $ dd if=/dev/zero of=/dev/sda
>

Ok. 
 
> Tant Debian 7 com Debian 8 arrenquen, però el cas és que el nucli
> «linux-image-586» de Debian 8 té una fuga d'informació:
> A algun mantenidor se li ha colat el «microcode» privatiu de la
> linux-image-686 i aleshores aquest fa una alerta en arrencar quan no és
> un i686.
>

A veure. Jo sóc més del pal de linux-libre que de linux, per tant no
vull defensar la infraestrutura que té linux per carregar programari
privatiu. Tanmateix, penso (no estic segur) que el linux-image-* de
debian no inclou codi privatiu (gràcies, Robert). El que inclou és
codi lliure preparat per carregar programari (o microcodi, que no sé
si tothom considera programari) privatiu a la CPU. Potser és aquest
codi el que es queixa que en aquesta CPU no ho pot fer. 

Tampoc estic segur que linux-image-**5**86 i "microcode: intel cpu
family 0x**5** not supported" vulguin dir el mateix. Diria que 
linux-image-586 és sense PAE i linux-image-686 és amb PAE. Si la CPU 
no té PAE, el linux-image-686 no funciona, si en té funcionarien 
els dos. No trobo ara una taula de codis de familia del CPUID i 
PAE. 

Jo no diria que el missatge sigui una "fuita d'informació". Entenc 
que t'emprenyi, això sí. 
 
> Això és el què delata (em sembla a mi) que no importa si t'instal·les o
> no el paquet intel-microcode doncs el nucli distribuit per Debian porta
> programari privatiu d'Intel tant si t'agrada com si no.
> 

Diria que no, però no ho he mirat. Si tu l'has trobat, doncs deu ser
com dius. Però jo no deduiria això només del missatge. 

Segurament hi ha codi que era un mòdul i ara està compilat dins el
nucli.  Abans potser hi havia alguna funció "probe" que decidia si
carregar el mòdul i en els models de CPU que no funcionava ja no el
carregava. Ara ja està carregat, intenta actualitzar programari quan
vol triar de quina manera ho ha de fer, descobreix que per aquest
model de CPU no en sap i ensenya el missatge d'error. Però no ho sé,
em fa mandra mirar-me el codi.

> Si la meva deducció és correcta, la meva queixa és: Ja sé que la
> tecnologia és una muntanya de problemes que creix, però això no vol dir
> que des de Debian a sobre els ajudem.
>

És l'argument de linux-libre, sí. No estic segur que tinguem clars els
fets, però el cas és que les distribucions recomanades per la FSF
tenen bastanta menys gent treballant-hi que Debian. I és veritat que
Debian fa el que pot perquè la seva feina la pugui aprofitar la gent
que està d'acord amb els seus criteris i el màxim de gent que no.
Per això tenen tants downstream...

Re: (deb-cat) microcode per CPU = ? privatiu

2017-11-30 Conversa Ernest Adrogué 
2017-11-30, 19:46 (+0100); Narcis Garcia escriu:
> A algun mantenidor se li ha colat el «microcode» privatiu de la
> linux-image-686 i aleshores aquest fa una alerta en arrencar quan no és
> un i686.
> 
> Això és el què delata (em sembla a mi) que no importa si t'instal·les o
> no el paquet intel-microcode doncs el nucli distribuit per Debian porta
> programari privatiu d'Intel tant si t'agrada com si no.

Tot això ho dedueixes a partir d'observar un simple missatge?

Em sembla que abans d'atribuir intencions malicioses o errades cal fer
un mínim d'investigació per confirmar les sospites.  I de fet no costa
gaire localitzar el missatge en qüestió en el codi font de Linux [1] i
veure que no hi ha res anormal o sospitós: el missatge apareix sempre
que el xip sigui anterior a 686.

En resum, de res d'això es desprèn que "el nucli distribuit per Debian
porta programari privatiu d'Intel".

[1] 
https://github.com/torvalds/linux/blob/master/arch/x86/kernel/cpu/microcode/intel.c

Re: (deb-cat) microcode per CPU = ? privatiu

2017-11-30 Conversa Narcis Garcia 
La versió d'aquest nucli matisa tal afirmació:

https://es.wikipedia.org/wiki/Linux-libre

Entenc que la decisió ha estat: «com que els microcodis intel/amd ja no
es poden proveïr com a opció (mòdul), deixem-los encastats de forma
permanent».

Aquesta mena de decisions és el què abans es criticava d'Ubuntu.



__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 29/11/17 a les 20:14, Josep Lladonosa ha escrit:
> Al final del document diu "it cannot be a module anymore in recent Linux
> kernels".

Re: (deb-cat) microcode per CPU = ? privatiu

2017-11-30 Conversa Narcis Garcia 
He fet més de 10 instal·lacions de Debian 8 a l'ordinador i586, i unes
quantes de Debian 7. Totes des de zero (disc en blanc):
$ dd if=/dev/zero of=/dev/sda

Tant Debian 7 com Debian 8 arrenquen, però el cas és que el nucli
«linux-image-586» de Debian 8 té una fuga d'informació:
A algun mantenidor se li ha colat el «microcode» privatiu de la
linux-image-686 i aleshores aquest fa una alerta en arrencar quan no és
un i686.

Això és el què delata (em sembla a mi) que no importa si t'instal·les o
no el paquet intel-microcode doncs el nucli distribuit per Debian porta
programari privatiu d'Intel tant si t'agrada com si no.

Si la meva deducció és correcta, la meva queixa és: Ja sé que la
tecnologia és una muntanya de problemes que creix, però això no vol dir
que des de Debian a sobre els ajudem.




__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 30/11/17 a les 18:44, Xavi Drudis Ferran ha escrit:
> Tornant al microcodi. No sé. Si el paquet et diu que no funciona amb
> la teva CPU, doncs desinstal·la el paquet (i regenera el initramfs si
> no t'ho fes ell solet, que suposo que ho fa). No sé quina versió de
> microcodi tens ni quina necessites, perquè és tot massa secret per
> saber-ho, però dubto que Intel encara tregui actualitzacions per a la
> CPU que tens. En aquella època diria que la majoria de la gent no
> actualitzava el microcodi mai. Al menys la gent no actualitzava la
> BIOS, per tant l'actualització de microcodi hauria de sortir d'alguna
> altra banda.
> 
> El que no he entés és si només et treu un missatge que no t'agrada 
> o el problema que tens és que no arrenca o alguna cosa així. Dius que
> el intel-microcode és un paquet requerit ? No pot ser si és a non-free, no ? 
> O vols dir que el nucli que porta Debian té l'actualització de microcodi
> configurada ? Jo em pensava que això no era greu si no trobava el microcodi
> al directori on el busca (o sia si intel-microcode no està instal·lat). 
> Pot ser que t'hagi quedat el directori brut d'una instal·lació anterior 
> o alguna cosa així ?

Re: (deb-cat) microcode per CPU =? privatiu

2017-11-30 Conversa Xavi Drudis Ferran 
El Thu, Nov 30, 2017 at 12:52:13PM +0100, Narcis Garcia deia:
> He llegit que Intel amb els fabricants de BIOS modernes ja executen un
> sistema operatiu «a l'ombra», com una mena de BIOS amb la seva
> interfície virtual de xarxa però poc detectable des de l'entorn
> d'usuari. Amb això podria ser que, amb els darrers processadors i3/i5/i7
> el sistema operatiu d'usuari s'estigui executant com una màquina virtual
> per sobre d'aquesta capa creada pel maquinari.
> 
> https://www.youtube.com/watch?v=iffTJ1vPCSo
>

Sí, ja és això. Més que "poc detectable" diria "gens detectable", però 
sí, potser es podria arribar a detectar si ho busques molt bé. 
 
> No crec que ambdues coses tinguin relació, però... Com es pot aclarir de
> forma fàcil i neta a un usuari que la distribució Debian no fa que
> l'usuari se sotmeti a les necessitats despòtiques d'Intel (o AMD) ?
> Això s'assemblaria molt a distribuïr M.Firefox amb Adobe Flash
> preinstal·lat perquè «it cannot be an extension anymore in recent
> Mozilla browsers»
> 

És que amb distribució Debian o sense un usuari d'Intel o AMD està
sotmes a que Intel, AMD, el seu govern, els seus atacants o desertors,
la clientela de qualssevol d'aquests quan es venguin les claus o atacs
al mercat negre, etc. puguin fer el que els doni la gana amb
l'ordinador de l'usuari.  Debian no ho pot arreglar, això. Si elimines
el programari maliciós de la BIOS/UEFI la CPU no arrenca (o s'apaga al
cap de mitja hora, o no accedeix a la RAM, etc.). El Minnich i
companyia han fet el que han pogut per treure el màxim possible de
porqueria privativa que hi ha a l'UEFI, i substituir-ho per codi
lliure i més lleuger (per intentar que tingui menys forats de
seguretat). Però al principi de tot hi ha codi que no poden tocar
perquè està signat. I si Google no pot arreglar els seus servidors
dubto que pugui jo. 

Per dir-ho d'alguna manera no han aconseguit executar Debian en nadiu 
per comptes de en una màquina virtual, sinó que han canviat la màquina 
virtual per una de menys cutre. 

Si volen tenir control el millor que poden fer és no fer servir ordinadors
(tot i que igualment es relacionaran amb gent o institucions que els 
facin servir, o poden no saber que fan servir ordinadors perquè avui en dia
en posen a tot arreu, al DNI, per exemple... fins i tot et poden atacar 
per la peixera...
https://theconversation.com/the-internet-of-things-is-sending-us-back-to-the-middle-ages-81435
). Si insisteixen en fer servir ordinadors i a més volen controlar-los, 
bé, les opcions serien una mica les que deien a 

https://lists.fsfe.org/pipermail/discussion/2016-April/010912.html

Teniu en compte però que RISC-V ha avançat una mica des de l'abril (encara 
verd per anar a una botiga a comprar-ne, però va prometent)

http://rise.cse.iitm.ac.in/shakti.html
https://www.wdc.com/about-wd/newsroom/press-room/2017-11-28-western-digital-to-accelerate-the-future-of-next-generation-computing-architectures-for-big-data-and-fast-data-environments.html

(o fer servir maquinari vell, per tornar a l'inici del fil tot i que
per estar tranquil probablement calgui canviar BIOS per libreboot o
coreboot o el que es pugui)

Més noticies (però una mica redundant, és més del mateix).

https://arstechnica.com/information-technology/2017/11/intel-warns-of-widespread-vulnerability-in-pc-server-device-firmware/
http://www.theregister.co.uk/2017/11/09/chipzilla_come_closer_closer_listen_dump_ime/
https://www.eff.org/deeplinks/2017/05/intels-management-engine-security-hazard-and-users-need-way-disable-it

Amb això no vull dir que Debian no serveixi, només que no pot
transformar màgicament la CPU en una altra. És millor Debian que
moltes altres alternatives, és només que no és suficient. Conduir un
Volvo (o un tanc) no garanteix que no caiguis per un precipici si no
mires per on vas...

Tornant al microcodi. No sé. Si el paquet et diu que no funciona amb
la teva CPU, doncs desinstal·la el paquet (i regenera el initramfs si
no t'ho fes ell solet, que suposo que ho fa). No sé quina versió de
microcodi tens ni quina necessites, perquè és tot massa secret per
saber-ho, però dubto que Intel encara tregui actualitzacions per a la
CPU que tens. En aquella època diria que la majoria de la gent no
actualitzava el microcodi mai. Al menys la gent no actualitzava la
BIOS, per tant l'actualització de microcodi hauria de sortir d'alguna
altra banda.

El que no he entés és si només et treu un missatge que no t'agrada 
o el problema que tens és que no arrenca o alguna cosa així. Dius que
el intel-microcode és un paquet requerit ? No pot ser si és a non-free, no ? 
O vols dir que el nucli que porta Debian té l'actualització de microcodi
configurada ? Jo em pensava que això no era greu si no trobava el microcodi
al directori on el busca (o sia si intel-microcode no està instal·lat). 
Pot ser que t'hagi quedat el directori brut d'una instal·lació anterior 
o alguna cosa així ?

Re: (deb-cat) microcode per CPU =? privatiu

2017-11-30 Conversa Narcis Garcia 
Això que ha trobat en Josep ho trobo molt greu, tractant-se de paquets
d'execució requerida i del repositori principal (main).

- A Debian 7, el Linux 3.2 de 32 bits era compilat per i486, i no passava.
- A Debian 8, el Linux 3.16 de 32 bits era compilat per i586, i ja amb
el «microcode» privatiu de Intel (que només va amb i686).
- A Debian 9 el Linux 4.9 de 32 bits és compilat per i686, i no es nota
perquè no es queixa, ja que no es pot arrencar amb processadors anteriors.

He llegit que Intel amb els fabricants de BIOS modernes ja executen un
sistema operatiu «a l'ombra», com una mena de BIOS amb la seva
interfície virtual de xarxa però poc detectable des de l'entorn
d'usuari. Amb això podria ser que, amb els darrers processadors i3/i5/i7
el sistema operatiu d'usuari s'estigui executant com una màquina virtual
per sobre d'aquesta capa creada pel maquinari.

https://www.youtube.com/watch?v=iffTJ1vPCSo

No crec que ambdues coses tinguin relació, però... Com es pot aclarir de
forma fàcil i neta a un usuari que la distribució Debian no fa que
l'usuari se sotmeti a les necessitats despòtiques d'Intel (o AMD) ?
Això s'assemblaria molt a distribuïr M.Firefox amb Adobe Flash
preinstal·lat perquè «it cannot be an extension anymore in recent
Mozilla browsers»



__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

El 29/11/17 a les 20:14, Josep Lladonosa ha escrit:
>
> Sí. Em vaig trobar amb algunes versions de nucli (tant recents com
> antigues) que ja inclouen en la seva compilació l'intel-microcode.
>
> He trobat això:
>
>
http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_README.Debian
>
> Al final del document diu "it cannot be a module anymore in recent Linux
> kernels".
> Imagino que hi ha hagut versions de nucli anteriors que també
> l'incorporaven dins.
>
> Salutacions,
> Josep
>
>

Re: (deb-cat) microcode per CPU =? privatiu

2017-11-30 Conversa Narcis Garcia 
Això ho trobo molt greu, tractant-se de paquets d'execució requerida i
del repositori principal (main).

- A Debian 7, el Linux 3.2 de 32 bits era compilat per i486, i no passava.
- A Debian 8, el Linux 3.16 de 32 bits era compilat per i586, i ja amb
el «microcode» privatiu de Intel (que només va amb i686).
- A Debian 9 el Linux 4.9 de 32 bits és compilat per i686, i no es nota
perquè no es queixa, ja que no es pot arrencar amb processadors anteriors.

He llegit que Intel amb els fabricants de BIOS modernes ja executen un
sistema operatiu «a l'ombra», com una mena de BIOS amb la seva
interfície virtual de xarxa però poc detectable des de l'entorn
d'usuari. Amb això podria ser que, amb els darrers processadors i3/i5/i7
el sistema operatiu d'usuari s'estigui executant com una màquina virtual
per sobre d'aquesta capa creada pel maquinari.

https://www.youtube.com/watch?v=iffTJ1vPCSo

No crec que ambdues coses tinguin relació, però... Com es pot aclarir de
forma fàcil i neta a un usuari que la distribució Debian no fa que
l'usuari se sotmeti a les necessitats despòtiques d'Intel (o AMD) ?
Això s'assemblaria molt a distribuïr M.Firefox amb Adobe Flash
preinstal·lat perquè «it cannot be an extension anymore in recent
Mozilla browsers»



__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 29/11/17 a les 20:14, Josep Lladonosa ha escrit:
> 
> 
> On 29 November 2017 at 19:55, Narcis Garcia  > wrote:
> 
> Com vaig esmentar un altre dia, assajo coses amb un «Intel Pentium MMX»
> (i586).
> M'he adonat que, tant el Live-CD "standard" de Debian 8 com en una
> instal·lació ja completada, l'arrencada manifesta:
> 
> microcode: intel cpu family 0x5 not supported
> 
> Sembla que això signifiqui que el nucli predeterminat ja ve amb això
> preinstal·lat:
> https://packages.debian.org/jessie/intel-microcode
> 
> (ja he verificat que el paquet no hi estigui)
> 
> 
> Sí. Em vaig trobar amb algunes versions de nucli (tant recents com
> antigues) que ja inclouen en la seva compilació l'intel-microcode.
> 
> He trobat això:
> 
> http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_README.Debian
> 
> Al final del document diu "it cannot be a module anymore in recent Linux
> kernels".
> Imagino que hi ha hagut versions de nucli anteriors que també
> l'incorporaven dins.
> 
> Salutacions,
> Josep
> 
>  
> 
> 
> --
> 
> 
> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> 
> 
> 
> 
> -- 
> --
> Salutacions...Josep
> --

Re: (deb-cat) microcode per CPU =? privatiu

2017-11-30 Conversa Narcis Garcia 
Això ho trobo molt greu, tractant-se de paquets d'execució requerida i
del repositori principal (main).

- A Debian 7, el Linux 3.2 de 32 bits era compilat per i486, i no passava.
- A Debian 8, el Linux 3.16 de 32 bits era compilat per i586, i ja amb
el «microcode» privatiu de Intel (que només va amb i686).
- A Debian 9 el Linux 4.9 de 32 bits és compilat per i686, i no es nota
perquè no es queixa, ja que no es pot arrencar amb processadors anteriors.

He llegit que Intel amb els fabricants de BIOS modernes ja executen un
sistema operatiu «a l'ombra», com una mena de BIOS amb la seva
interfície virtual de xarxa però poc detectable des de l'entorn
d'usuari. Amb això podria ser que, amb els darrers processadors i3/i5/i7
el sistema operatiu d'usuari s'estigui executant com una màquina virtual
per sobre d'aquesta capa creada pel maquinari.

https://www.youtube.com/watch?v=iffTJ1vPCSo

No crec que ambdues coses tinguin relació, però... Com es pot aclarir de
forma fàcil i neta a un usuari que la distribució Debian no fa que
l'usuari se sotmeti a les necessitats despòtiques d'Intel (o AMD) ?
Això s'assemblaria molt a distribuïr M.Firefox amb Adobe Flash
preinstal·lat perquè «it cannot be an extension anymore in recent
Mozilla browsers»



__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 29/11/17 a les 20:14, Josep Lladonosa ha escrit:
> 
> 
> On 29 November 2017 at 19:55, Narcis Garcia  > wrote:
> 
> Com vaig esmentar un altre dia, assajo coses amb un «Intel Pentium MMX»
> (i586).
> M'he adonat que, tant el Live-CD "standard" de Debian 8 com en una
> instal·lació ja completada, l'arrencada manifesta:
> 
> microcode: intel cpu family 0x5 not supported
> 
> Sembla que això signifiqui que el nucli predeterminat ja ve amb això
> preinstal·lat:
> https://packages.debian.org/jessie/intel-microcode
> 
> (ja he verificat que el paquet no hi estigui)
> 
> 
> Sí. Em vaig trobar amb algunes versions de nucli (tant recents com
> antigues) que ja inclouen en la seva compilació l'intel-microcode.
> 
> He trobat això:
> 
> http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_README.Debian
> 
> Al final del document diu "it cannot be a module anymore in recent Linux
> kernels".
> Imagino que hi ha hagut versions de nucli anteriors que també
> l'incorporaven dins.
> 
> Salutacions,
> Josep
> 
>  
> 
> 
> --
> 
> 
> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> 
> 
> 
> 
> -- 
> --
> Salutacions...Josep
> --