Responder 
 
Avaliação do Tópico:
  • 0 Votos - 0 Média
  • 1
  • 2
  • 3
  • 4
  • 5
Miscelânio em Modo de Texto
21/05/2010, 10:24
Resposta: #16
Re: Por que o driver proprietário tem que ser o correto?
É chegado o momento de dar seguimento às instruçẽos enviadas por
dmatrix (Mensagempor dmatrix em Qui Mai 20, 2010 10:24). Estive, e estou,
ainda confuso sobre qual é a diferença entre um processador de 32 bits e um
de 64 bits no momento em que se vai escolher a versão correta da distro
para ser baixada. Já tenho as configurações do Xorg que preciso e é chegada a hora
de baixar o BRDESKTOP. Hoje, verificando o manual do processador Dual Core Celeron,
verifiquei que é 64. A segunda versão do BRDESKTOP que baixei não deu o boot:

ISOLINUX 3.71 Debian - 2008.09.06 1994-2000 H. Peter Anvin
Boot failed: press a key to retry.
Falhou o arranque: precione qualquer tecla para tentar novamente

Eu, sempre distraído, novamente baixei esta segunda distro atual do BRDESKTOP
sem olhar se era para 32 ou 64 bits, então abri a .iso da distro e verifiquei, no
arquivo README.html:

Debian GNU/Linux testing "Lenny" - Official Snapshot i386 NETINST Binary-1 20090208-03:19 . It contains programs ("binaries") for `i386' computers.

ENTÃO EU BAIXEI UM "Lenny" para i386.
A PERGUNTA É, o Lenny para i386 dá boot em processadores Intel 64?
Se der, então vou ter que verificar o arquivo md5sum.txt.
Aqui esta:
Ele vêm com uma lista de todos os CHECKSUM e o comando:
'md5sum -c md5sum.txt'

Se esta versão que baixe é a errada, terei que usar o comando acima e
descobri como se faz o CHECKSUM para o disco todo, vou tentar
fazer isto pela primeira vez.
Ok, se receber a confirmação que esta distro não é apropriada para
o Intel 64, tenho aqui, no arquivo README.mirrors.html
o sítio:
Brazil http://ftp.br.debian.org/debian/ alpha amd64 arm armel hppa hurd-i386 i386 ia64 mips mipsel powerpc s390 sparc

Lá poderei baixar o amd64, caso este seja o apropriado para o dual core
celeron da Intel, o qual é, já verifiquei, 64.
Ocorre que esta foi a distro inicial com a qual comecei, e que dava o Xorg Vasio
e que entra em modo gráfico de texto VESA para fins de instalação e não entra no Desktop em Vesa a não ser que sejam feitos os devidos ajustes de configuração manualmente.

Preciso ter a certeza de qual das duas versões do BRDESKTOP é a apropriada
no meu caso, para, então, proceder com a instrução do dmatrix:

aptitude search intel | grep xorg

Estarei relendo as orientações do dmatrix, porque é possivel que ele já tenha esclarecido qua a versão correta e eu, na confusão, me perdi.
Visitar o website do usuário Encontrar todas as respostas deste usuário
Citar esta mensagem em uma resposta
21/05/2010, 12:06
Resposta: #17
Re: Por que o driver proprietário tem que ser o correto?
me parece que essa mensagem é má gravação da iso em cd, não estou certo se processadores do tipo Dual core podem ser considerado como 64, sei que Turion 64 é e Core Duo é, Dual core não tenho certeza. A iso i386 serve para ambas arquiteturas, mas iso amd64 somente para processadores de 64.

"Na caixa dizia: Requer MS Windows ou superior, então eu instalei Debian/GNU
Linux!"

.
Antes de postar use a busca e veja o Wiki.
Busca do FD
Wiki do FD
Visitar o website do usuário Encontrar todas as respostas deste usuário
Citar esta mensagem em uma resposta
23/05/2010, 12:23
Resposta: #18
Re: Por que o driver proprietário tem que ser o correto?
Um livecd que pode dar certo seria o da Distro Fedora Spin o qual promete contar com o broffice para ser usando sem hd.
http://www.projetofedora.org/novidades_ ... office_f12

"Na caixa dizia: Requer MS Windows ou superior, então eu instalei Debian/GNU
Linux!"

.
Antes de postar use a busca e veja o Wiki.
Busca do FD
Wiki do FD
Visitar o website do usuário Encontrar todas as respostas deste usuário
Citar esta mensagem em uma resposta
24/05/2010, 16:39
Resposta: #19
Re: Por que o driver proprietário tem que ser o correto?
Obrigado dmatrix pela dica. Chega em boa hora. Estou estudando um pouco
o Debian, ele carrega em modo de texto, dá para fazer muita coisa, aí aproveito para ver se aprendo o que é o Bash. Estive tomand uma surra do MBR. Após perder vários HD's, não instalo mais nada em MBR. É um mistério, dá um problema de MBR conconmitantemente com uma trinha modificada em setor do disco, e o resultado é um HD inutilzado. Estou tentando dar o boot, a partida fora da MBR, como não tenho nem disquetes e nem pen drive, estudei um jeito de dar o boot por cd, levando a bios a acreditar que o cd é o disquete. A estágio um e dois do grub ficam no grub CD LIVE de boot e deveriam apontar para o setor do HD onde coloquei o boot. Se tu souberes algo sobre esse assunto, já não diria saber, porque tu és exímio, se tu tiveres paciência e tempo, me deixa umas dicas uma hora destas. O princípio seria o do DVD de múltiplas distros, aquele dvd que roda live com três, quatro, cinco distros:

mkdir /tentativa/iso
mkdir /tentativa/iso/ubunto-boot
mkdir /tentativa/iso/fedora-boot
mkdir /tentativa/iso/mint-boot
mkdir /tentativa/iso/mandriva-boot
mkdir /tentativa/iso/slax-boot
mkdir /tentativa/iso/pmagic-boot
mkdir /tentativa/iso/systemcd-boot

[email protected]:~$ cat /tentativa/munduruku/Desktop/mountiso
umount /mnt/cdrom
mount -t iso9660 -o ro,loop=/dev/loop0 $1 /mnt/cdrom

[email protected]:~$

/bin/bash mountiso slax-6.0.0-rc5.iso

umount /mnt/cdrom
mount -t iso9660 -o ro,loop=/dev/loop0 $1 /mnt/cdrom

[email protected]:~$

Então este é o comecinho para se criar o multidistro dvd live e
o grub vai dentro do cd, apenas que, no caso de quem está traumatizado com
a corrupção na MBR, este DVD vai adaptado para que o grub tenha a opção extra de dar o boot do HD, quando solicitado. GRAVAR GRUB EM MBR NUNCA MAIS!
Bem amigo linux, esta manha chorei, fazia tempo que não chorava; recebi uma mensaem de um Norte-Americano civil em um dos foruns que participo e
a brutal verdade que ele declarou, confirmou as os anseios e expectativas que já tinha, vi que não estava sozinho na questão dos drivers proprietários e Hardware. Foi colocar a fala do Norte-Americano aqui para demonstrar que
o mais importante é que o Linux é uma comunicade de seres humanos pensantes que podem e devem contribuir para um mundo melhor:

O tópico está no url:

http://www.murga-linux.com/puppy/viewto ... 523#420523

(...) " think he was suggesting more along the lines of a new common standard that would incorporate items that are shared amongst all capable modern video cards. For instance adding OpenGL, OpenEXR, CG (& unfortunately probably D3DX) to a new vesa spec with a standardize way of interfacing. This would allow most common acceleration methods to work for all video cards even with a "failsafe" driver. It may have actually worked back in the days when there were 100+ video card manufacturers, but these days the few that are left are always feuding and would probably never agree to any standard in the hopes that they can make the other companies fail. It is so backwards - why should it be easier to make 100 people come to a compromise than 3? This is why business and politics are more important than we IT and engineering types want to believe. Those in power do not want a level playing field - new competitors would cut into their profit margins. You are more likely to see Apple, Microsoft and other legal teams combine forces to sue every individual linux user for IP infringement than Intel, AMD and nVidia coming together to agree on an open standard. Businesses want less competition, not more. Having an open standard would make it easier for new start-ups to compete and thus cut into their profit margins." (...)

Eu iniciei o tópico mas não pensei que teria uma resposta positiva dos Norte-Americanos civis, ao que tudo indica, eles estão sofrendo lá tanto quanto nós aqui no Brazil.

Estou levando o que estou aprendendo para o forum:

http://spo-ovnilogia.com/foruns/index.php?topic=126.195

Estarei testando o BROFFICE na distro que tu me indicaste, após o quê,
poderei ver como funcionam os dicionários, a correção de ortográfica em
português do Brasil e tudo o mais de bom que o BROFFICE oferece.
Visitar o website do usuário Encontrar todas as respostas deste usuário
Citar esta mensagem em uma resposta
24/05/2010, 21:22
Resposta: #20
Re: Por que o driver proprietário tem que ser o correto?
Olha num sei por que esse receio com relação a instalação do grub, já instalei em várias maquinas o grub na mbr e nenhum problema até hoje, mas sempre usei a opção do instalador, ele quem instala lá por padrão, nunca tive problemas e é a primeira vez que vejo alguem com medo de instalar o grub na mbr. Talvez as distro que utilizou e deixou gravar na mbr num sejam do tipo profissionais como o Debian. Pode ser tb que sua placa mãe tenha alguma proteção contra virus e qualquer alteração na mbr seja bloqueada, mas aí é só desabilitar isso na bios. Ao contrário só tive dificuldade para gravar o grub em mbr de hds tipo scsi, esses sim tive que instalar o grub pela console de recuperação pois a tentativa pelo instalador falhava.

"Na caixa dizia: Requer MS Windows ou superior, então eu instalei Debian/GNU
Linux!"

.
Antes de postar use a busca e veja o Wiki.
Busca do FD
Wiki do FD
Visitar o website do usuário Encontrar todas as respostas deste usuário
Citar esta mensagem em uma resposta
25/05/2010, 14:06
Resposta: #21
Re: Por que o driver proprietário tem que ser o correto?
Fui até o url do FEDORA BRASIL. Fui meio desconfiado, porque
já haviam me dito que fedora, já o próprio nome diz, está associado
a projetos federais contrarios a liberdade de pensamento. Eu fui lá
e baixei a distro. O SHU1SUM dava sempre errado, quer dizer o softer
chegava mexido. Então fui no forum do fedora, coloquei minha foto,
meus dados, tudo o que pediram, e pedi orientações de como baixar
o CD correto, uma vez que têm havido, se sabe, o RIP, nos protocolos
TCP/IP. Retornando ao forum, não houvera feito nenhum comentário
especial, apenas relatando a dificuldade de baixar a distro que chega
do URL da UNICAMP com o checksum errado, verifique que havia sido
expulso da comunidade:
http://www.fedora.org.br/gate.html?name=Your_Account
SUA CONTA ESTÁ SUSPENSA.
E QUANDO TENTO UMA NOVA SENHA OU PASSWORD no url
http://www.fedora.org.br/gate.html?name=Your_Account
A RESPOSTA É:
Você tem que informar seu username e seu endereço de e-mail.

MESMO APÓS TER INFORMADO O E-MAIL E O NOME DE USUÁRIOS
CORRETAMENTE.
O fato do FEDORA discriminar um Brasileiro, no caso eu, que me recusei
a usar um FEDORA alterado, não deve ser exceção. Faz muito tempo que
não querem que os Brasileiros tenham o conhecimento necessário para
ter um BROFFICE e, quando surge uma distro, no caso do FEDORA, parece
estar relacionada a ULTRA DIREITA, se assim não fosse, por que expulsariam
Brasileiros que questionam uma coisa tão simples como o SHU1SUM?

Resumindo, Fedora é a distro da ULTRA DIREITA, não quero mais
saber de FEDORA, vou procurar encontrar o GENUÍNO BROFFICE
feito, criado e mantido, por gente boa, brasileiros de verdade,
Fedora, nem me viu, Fedora nunca mais.
Visitar o website do usuário Encontrar todas as respostas deste usuário
Citar esta mensagem em uma resposta
26/05/2010, 08:30
Resposta: #22
Re: Por que o driver proprietário tem que ser o correto?
Não entendi porque vc foi no site e forum do fedora, o link que lhe passei é pra baixar a iso via torrent direto http://torrent.fedoraproject.org/spins/ ... ce.torrent mas tem que instalar um cliente torrent tipo o Deluge http://deluge-torrent.org/ para fazer isso. A propósito vc deve estar enganado quanto a ter sido expluso, conta suspensa é uma coisa diferente, talvez faltou confirmar o cadastro ou coisa parecida. Mas para baixa a iso vc num precisa entrar lá, além disso acho que essa iso customizada com o broffice vc só deve conseguir baixando pelo torrent. Me parece que vc tem uma visão ou conceito não muito correto sobre o projeto fedora, já trabalhei com o fedora e desconheço tal visão negativa, apenas não me agradava o fato da distro ter como ambiente gráfico o KDE que era muito pesado na época.

"Na caixa dizia: Requer MS Windows ou superior, então eu instalei Debian/GNU
Linux!"

.
Antes de postar use a busca e veja o Wiki.
Busca do FD
Wiki do FD
Visitar o website do usuário Encontrar todas as respostas deste usuário
Citar esta mensagem em uma resposta
26/05/2010, 10:11
Resposta: #23
Re: Por que o driver proprietário tem que ser o correto?
Vamos começar pelo que pude descobrir hoje.

Ao baixar uma distro, vou pegar como exemplo provisório
o fedora 13, pelo delugetorrente, recebi a distro e um
long número, um tal de SHA256SUM

acf91d9cde004b7322fc08a5a037ac52745176da878600798e64cb4176245d10 *Fedora-13-i686-Live-BrOffice.iso

Esse número, assim como a distro, vieram pelo bitorrente, e eu ainda não
tenho como confirmar se são verdadeiros.

Eu entro no ubunto 9.10, ou big linux 5, e no terminal
digito # sha5sum Fedora-13-i686-Live-BrOffice.iso

e o ubunto ou big linux 5 indicam que, após verificar a distro baixada,
o fedora, realmente o número fecha, resulta em

acf91d9cde004b7322fc08a5a037ac52745176da878600798e64cb4176245d10



O verificar se as distros chegam BATIZADAS
pelo bitorrent, com algumas propriedades alteradas segundo o usurário e
números de IP, fica possível se o padrão universal que garante que a
distro é cem porcento igual para todos os usuários não estiver garantida
na fonte. Então fui em busca da fonte: lá no sítio do fedora ( estou tomando
como exemplo, poderia ser qualquer distribuição) encontrei:

http://torrent.fedoraproject.org:6969/

HASH : Fedora-13-i686-Live-BrOffice

22d846974385f0bdd32f81075d9eaed8830208e1

A ÚNICA CERTEZA, PORTANTO, QUE TENHO DE A DISTRO QUE BAIXEI
NÃO ESTAR BATIZADA, É O HASH OFERECIDO ACIMA, O QUAL COMEÇA
COM 22 E TERMINA COM 8e1. O teste básico, o primeiro que fiz,
indicou que a distro não estava estragada, contudo a função do SHA256,
não é essa, isso qualquer programa de checksum faz, a função do
SHA256 é garantir que a mídia não esteja BATIZADA. Então fui
no terminal e digitei # sha1sum Fedora-13-i686-Live-BrOffice
E RESULTOU EM:
251ae2ec4a7bb2c0df6ee84dfbff5705ce7a1187
DIFERENTE DO SHA1, A FONTE, OFERECIDA PELO FEDORA, QUE É:
22d846974385f0bdd32f81075d9eaed8830208e1

Abaixo eu coloco, como exemplo, o PGP que o bitorrente me
enviou junto com a distro baixada, a qual, repito, só teria valor
se resultasse no HASH que o fedora indica na fonte, o
22d846974385f0bdd32f81075d9eaed8830208e1

Então, alguém pode me dar uma ajuda?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

# The image checksum(s) are generated with sha256sum.
# The PGP checksum uses sha1sum.
acf91d9cde004b7322fc08a5a037ac52745176da878600798e64cb4176245d10 *Fedora-13-i686-Live-BrOffice.iso
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iQIVAwUBS/SGpH7catbo5A/eAQJ5WBAAsMjyKLw2uWdCPlcbNgMQS4nh8xuaxk2C
Y+HFxU2PHniHN45I3w47WRxifzUSMcw4pNIOu4YvJbL/yYzsy5q8IDDGjyYqshla
eeqsuX3JAkff8/S0tAwGJ1mSzM8AtoTu4VzokNRnkznA7fHWv8Yvnh2/qtjyV27N
wI5c1l6iJCp3oq5MFGWmSJQq6FkCDsNy1Cu1opyUePU/KMxFUk+HxirNNVYQMH3M
CPNE+GGiGov7uS0n1/9vt8XudU/G83a6zlBGHfpvRkdXJli2mpzm2lufb1edJpQU
HCGNXu8RdE6rdT1qs8RUZWG36M6XVXGpKURe9yaqWjuSVJZjHvoZ22+AKNy6wIiQ
q10vMtueKlUQVMNiQAJq7FnKHFh9pFxsMfBN2DU79IB9HyO60Mz/OvfiwYXC7+s6
PmLXSgBeYtdrtcdRM8S9RyaCtZjX4UL15tQrtU1Q1RH68dYmxWK7zYMxmXe08pNy
THOVQBd1XR7byjfkzLGbvVLe+ySuhO+9NQ9Ds6Zo6pQzBSPSi5o/PO7gxkNkbGbA
wCxGPYudVXVKC0p5PEOWFAshrq0M5/b1n7Csj0TctDHyty6AnHqkrLVYPN79rqBB
Vr44KpjAosChsczqbBgbAvSXrMcOFGg189o7tjx7LcViTce4BDDFijKfwctkKhTW
kEFCOUzrOc8=
=Rkkr
-----END PGP SIGNATURE-----





Como posso ter certeza disto? O fato do SHA5SUM fechar



Querido Amigo Linux dmatrix, exitem dois tipos de comunidades,

aquelas que acreditam na liberdade de expressão e nas limitações

que cada ser humano tem ao expressar-se. O meu desabafo frente

ao Fedora não se sustenta, foi um ato emocional de quem se vê

banido de uma comunidade por não ter conseguido explicar alguma coisa

ou ser mal interpretado por aquele segunto tipo de comunidade, que

por ser de ultra direita, não quer ouvir aos cidadãos e cidadãs.

O contexto é muito importante quando se quer

entender um questionamento, por isso, aqui no fórum Debian, as vezes

parece que fujo to tópico; isso, contudo, é uma estratégia para contextualizar

o problema, permitindo a quem lê, dar um desconto. Agradeço novamente

a tua habilidade de moderador em compreender minhas limitações.

O site do qual fui expulso não me requisitou confirmação; a pessoa faz o

cadastro e participa do fórum. O que deve ter aborrecido eles é que eu

mando a informação com as devidas minúncias. Dou-te um exemplo, sou

professor de Inglês, então fui nos sítios Norte-Americanos e verifiquei

que nem eles lá sabem direito o que é o SHA-256, quer dizer fazer o

CHECKSUM se torna algo cheio de mistério até para os Norte-Americanos.

Antes do Fedora 11, o SHA1 já apresentava falhas, quer dizer, tinha gente

mal intencionada querendo burlar o programa que garantia a integridade

para enviar pela internet um KERNEL hackeado. O Banco do Brasil, já utiliza

e fornece seu próprio UBUNTO, porque não aceitam e nem poderiam aceitar

serem feitos de idiotas. Muitas empresas Norte-Americanas, os empresarios, são prejudicados pelo monopolismo estatal Norte-Americano, o qual incentiva a quebra
das chaves de segurança, vou colocar aqui o exemplo de um cidadão que provou que o SHA1 estava sendo sabotado pelo próprio Governo Federal Monopolista Norte-Americano, o qual, todo voltado para a guerra, não quer permitir o uso da internet para fins pacíficos (http://blog.n01se.net/?p=40):

SHA1 broken by US Government
July 7th, 2009 by agriffis

...but not in the way you might expect. One of us noisers (Gerry Leach) tried to use the Argonne National Laboratory's implementation of SHA1 to double-check his own computations. What he found was a bit of a surprise, to say the least...

Given the input string 1316798755 the above site returns DA39A3EE5E6B4BD3255BFEF95601890AFD879. One wouldn't normally question this result, coming from a national laboratory, except that it didn't match Gerry's local tests, nor does it match mine:

$ echo -n 1316798755 | sha1sum | tr '[:lower:]' '[:upper:]'
A897C3B9E5A64D609A1D7DB3D1D7F4C03C3F00A1 -

Bob Bell quickly pointed out the similarity of the site's computation to the SHA1 of the empty string:

$ sha1sum </dev/null | tr '[:lower:]' '[:upper:]'
DA39A3EE5E6B4B0D3255BFEF95601890AFD80709 -
DA39A3EE5E6B4BD3255BFEF95601890AFD879 (output from ANL)

After a few more tests, Bob enumerated the issues with the site's computation:

* First, it strips any non-alpha characters from the input, including digits and whitespace.
* Then it converts lowercase input to uppercase, so the result for "foobar" is the same as the result for "FOOBAR", but even so the final answer is wrong because...
* It prints the result as a string of bytes using %X instead of %02X, so the output drops leading zeroes in the hex representation of each byte.

I wonder what Argonne is doing with this particular calculator... Dare we hope for... nothing?


O usuário atento, bem instruído, e na America do Norte

têm muitos, alí pelo fedora 10, baixava o arquivo do Fedora, fazia o SHA1 e

e verificava que o CHECKSUM estava errado, e, contudo, o CD dava boot

e funcionava, aparentemente, de forma correta. As estatísticas deste fenômeno

provaram que hackers do mal já haviam achado uma maneira de burlar o

SHA1, e agora temos o SHA256, que dizem, é mais seguro. As melhores

distros mantém uma estatística, por exemplo, o DESKTOP-PARANÁ

(http://www.desktopparana.pr.gov.br/desk ... 3_i386.iso) tem uma

página onde se encontra o relatório dos DOWNLOADS que falharam,

procurando verificar os motivos, e os DOWNLOADS que funcionara,

a distro chegou com o número certo de bites e, contudo, mexida, com

CHECKSUM, errada, o que indica sabotagem. As estatísticas dependem

de o usuário ser minuncioso e enviar o relatório e os administradores serem

competentes e honestos, disponibilizarem a estatística, o que diminuiria

o TCP/IP RIPPING, ou hacking com finalidades negativas. A internet

tem muita malandragem. Usei o BITORRENT do big linux para baixar

o Fedora-13-i686-Live-BrOffice.torrent. O download nunca terminava, contudo

a velocidade era boa, em três horas estaria terminado; passado o tempo

correto, o download indicando 60,1 e mudando devagarinho 60,2, devagarinho

demais, interrompi o download e verifiquei, em outro sistema, que o download

já estava completo, e algum MALANDRO, no sistema BITTORRENT, estava

querendo ficar um tempo a mais no computador; e não é só isso, uma das

partições do HD indicava vazia, e quando examinada, estava cheia de arquivos

ocultos, os quais já haviam ocupado toda uma partição a qual, misteriosamente,

para o leigo, pelo gerenciadores de arquivos, indicava vazia.

Então veja, computação é

cheio de truques e malandragens, se dormir no ponto, já era, te passam a perna.

Então a distro que já havia baixado, o caso acima mencionado, recuperei e

entrou com o SHU256:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

# The image checksum(s) are generated with sha256sum.
# The PGP checksum uses sha1sum.
acf91d9cde004b7322fc08a5a037ac52745176da878600798e64cb4176245d10 *Fedora-13-i686-Live-BrOffice.iso
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iQIVAwUBS/SGpH7catbo5A/eAQJ5WBAAsMjyKLw2uWdCPlcbNgMQS4nh8xuaxk2C
Y+HFxU2PHniHN45I3w47WRxifzUSMcw4pNIOu4YvJbL/yYzsy5q8IDDGjyYqshla
eeqsuX3JAkff8/S0tAwGJ1mSzM8AtoTu4VzokNRnkznA7fHWv8Yvnh2/qtjyV27N
wI5c1l6iJCp3oq5MFGWmSJQq6FkCDsNy1Cu1opyUePU/KMxFUk+HxirNNVYQMH3M
CPNE+GGiGov7uS0n1/9vt8XudU/G83a6zlBGHfpvRkdXJli2mpzm2lufb1edJpQU
HCGNXu8RdE6rdT1qs8RUZWG36M6XVXGpKURe9yaqWjuSVJZjHvoZ22+AKNy6wIiQ
q10vMtueKlUQVMNiQAJq7FnKHFh9pFxsMfBN2DU79IB9HyO60Mz/OvfiwYXC7+s6
PmLXSgBeYtdrtcdRM8S9RyaCtZjX4UL15tQrtU1Q1RH68dYmxWK7zYMxmXe08pNy
THOVQBd1XR7byjfkzLGbvVLe+ySuhO+9NQ9Ds6Zo6pQzBSPSi5o/PO7gxkNkbGbA
wCxGPYudVXVKC0p5PEOWFAshrq0M5/b1n7Csj0TctDHyty6AnHqkrLVYPN79rqBB
Vr44KpjAosChsczqbBgbAvSXrMcOFGg189o7tjx7LcViTce4BDDFijKfwctkKhTW
kEFCOUzrOc8=
=Rkkr
-----END PGP SIGNATURE-----

O NOVO SHA-256, QUE SUBSTITUIU O JÁ SUPERADO, SHA1, PARECE QUE PRECISA DE UMA CHAVE DE SEGURANÇA,
QUE É PUXADA ATRAVÉS DO GnuPG, estou estudando um exemplo que encontrei:

Assinaturas GnuPG:

$ gpg -sba NVIDIA-Linux-x86-96.43.01-pkg1.run

You need a passphrase to unlock the secret key for
user: "xxx [email protected]"
1024-bit DSA key, ID XXXXXX, created XXXX-XX-XX

$ cat NVIDIA-Linux-x86-96.43.01-pkg1.run.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHL1WSt8sGflRVPosRAi/ZAJ93uYQOnElux2rvb4/oZK7ADuohxQCgldX4
sPAodGM4R8keKe2MOnJqCUk=
=T/pb
-----END PGP SIGNATURE-----

Importando a chave pública:

$ gpg --recv-keys XXXXXX
gpg: requesting key XXXXXX from hkp server subkeys.pgp.net
gpg: key XXXXXX: "XXX [email protected]" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

Verificando a assinatura:

$ gpg --verify NVIDIA-Linux-x86-96.43.01-pkg1.run.asc
gpg: Signature made Mon 05 Nov 2007 03:40:34 PM BRST using DSA key ID XXXXXX
gpg: Good signature from "XXX [email protected]"

XXXXXX é a ID da chave.

A QUESTÃO, É QUE NÃO SEI AINDA, COMO VERIFICAR O SHA256,

ESTOU APRENDENDO. PROCUREI NO PROJETOFEDORA E NÃO ENCONTREI,

É TUDO MEIO MISTERIOSO; ELES, QUE DEVERIAM SOLICITAR DO USUÁRIO

QUE SE ENVIASSEM RELATÓRIOS PARA BOAS ESTATÍSTICAS, NÃO

COLOCAM A INFORMAÇÃO DE FORMA MUITO VISÍVEL, E TÊM MUITA

CONFUSÃO, COMO DISSE, ATÉ NA AMÉRICA DO NORTE; ACHEI O

SHA256 PARA O FEDORA EM INGLÊS NO SITE NORTE-AMERICANO,

MAIS NO PROJETOFEDORA DITO BRASILEIRO, ESTOU PROCURANDO.


Sai, dei uma pesquisada, voltei. Parece que a diferença entre o MD5 e o SHA1
fica relevante em um ambiente dinâmico de troca de informações,
quando é possível que a ISO enviada seja interceptada e duplicada durante
a sua transmissão. Então, em um ambiente fechado, um pc off-line (
verificar se não está sendo hackeado wireless), nest pc off-line, fisicamente
desconectado da internet, o MD5 e o SHA1 poder verificar de forma competente
se arquivos estão duplicados e não há possibilidade de erro, o problema ocorre quando alguém que já quebrou o MD5 ou o SHA1, tem o tempo suficiente para
duplicar os arquivos no TCP/IP RIPPING, e é por isso que se começa a utilizar
o SHA-256. Isso eu não posso confirmar, estou aprendendo. Então vejamos,
teria que pesquisar HASH ( SHA-256) para o Fedora-13-i686-Live-BrOffice.iso
seria, segundo o url:

http://torrent.fedoraproject.org:6969/
47ccc37db256387b70857f53a6067e8d50e692c9aa85e45e63e5190c5d1e0942 *Fedora-13-i686-Live.iso

Agora, para testar a integridade da ISO:

$ sha256sum -c *-CHECKSUM
Acima no checksum vai o número comprido que começa com o 47 e termina em 42.

Eu ainda não aprendi a pegar o CHECKSUM diretament utilizando o
comando:

$ curl https://fedoraproject.org/static/fedora.gpg | gpg --import

$ gpg --verify *-CHECKSUM

O estudo acima me ajudara a estudar o Debian, que, segundo pude ler,
já adotou o SHA-256 e está convidando os usuários a migrarem para
este novo sistema, dando os apt-gets necessários. Se estiviver
faland bobagem, lembrem-se, isso aqui é treino, não tenho autoridade
no assunto.

Fui e testei o md5sum e sha256sum; o big linux 4.2 aceitou a mídia errada baixada
pelo bitorrent, ela veio com o número certo de bites e enganou o md5sum do
biglinux 4.2, o qual não detectou que a midia estava adulterada, marcou
dee80ea179d99f9dc47122e8570345eb
Existe uma vantagem, contudo, nisso, porque o UBUNTO, simplesmente diz que
a mídia está errada, mas não REGISTRA o md5 errado, com o KERNEL HACKEADO, que
pode estar sendo passado, como o mesmo dee80ea179d99f9dc47122e8570345eb para
outra vítimas, prejudicando portando, as estatísticas, e favorecendo aos perpetradores.
O ponto positivo do UBUNTO 9.10 foi que ele não permitiria, sequer, que o usurário
quimasse o CD a partir daquela mídia adulterada.
Compreendo, agora, porque, ao baixar pelo bitorrent o aquivo Fedora-13-i686-Live-BrOffice.torrent.
ele preencheu a ISO primeiro e ficou indo muito devagar em desproporção com a
velocidade dos dados. Reiniciando o download da mesma mídia, essa a
dee80ea179d99f9dc47122e8570345eb pelo bit torrent, o Bittorrent reconheceu o erro
e começou a corrigir o arquivo, vou ter que esperar para fazer novos testes e ver
se chego a uma conclusão. se a mídia dee80ea179d99f9dc47122e8570345eb
fora acidentalmente ou maliciosamente, alterada. Todo o principiante, que não
entende nada de Linux e está começando, acha que está sendo hackeado, quer
dizer, o que vale aqui, no meu caso, é aprender os comandos, hoje aprendi
o md5sum e sha256sum, o restante é aquela velha confusão de quem
está aprendendo, afinal de contas se a mídia dee80ea179d99f9dc47122e8570345eb, esta ISO, fosse
queimada no cd e funcionasse, desse o boot certinho, confirmar-se-íam as suspeitas,
então por via das dúvidas, economizo um CD paaa testar a mídia que o bitorrent está
corrigindo e deixo, em um segundo plano, àquela primeira, caso as coisas não melhorem,
poderemos gerar uma ESTATÍSTICA. Então, porque estou ainda querendo
descobrir o que é o SHA256SUM, resolvir ir veridicando os critérios de
cada distro. Hoje tentei o Zenwalk, o arquivo zenwalk-6.2.iso possuia, apenas,
o MD5, não encontrei nenhum SHA1, ou SHA256SUM na fonte. Eu poderia
pegar a ISO que baixei e criar um SHA1 ou SHA256SUM para ele, e contudo,
possuir um HASH, não significa dizer que tenha chegado a mídia certa. Fiquei
desconfiado do Zenwalk, uma distro que não se preocupa em fornecer o
SHA1, ou SHA256SUM na fonte, não poderia se preocupar muito com a segurança,
assim mesmo baixei o arquivo, na ora de queimar o cd, nem precisei, a ISO
de pouco menos de 500 Mb surgia no DVD a quimar com 4Gb, era obvio,
que se acionasse o K3B perderia o cd, e nem precisaria utilizar o MD5, a mídia
houvera sido explicitamente corrompida durante o download, ainda
que indicasse os bites certos, no K3B, indicava que não caberia nem no
DVD. Busquei uma outra ISO, comecei a baixar o CDlinux_CE-0.9.6.1.iso,
antes de baixar, verifiquei se a distribuição era séria:
Esta distro chinesa fornecia o MD5 bb3110a8999716806f6de0ea684ae0f4
bem visível no sítio de download e, igualmente, o SHA1
8a755e6eee909305b9ae5297c4466af2c5b9808b. Esto me fez crer que era
uma distro responsável, imagina quanto tempo se perde a se procurar
por estas informações e as vezes nem se encontra. Esta distro, não
fez como o Fedora, que vai um passo adiante, chega até o SHA256SUM. O
SHA256SUM do Fedora, infelizmente, provou não ser de muita utilidade, porque
conferindo o CD que baixei pelo torrent, que deu o mesmo SHA256SUM oferecido pelo mesmo torrent, com um CD original
vendido nas lojas distribuidoras do Fedora, verifico que o SHA256SUM
que o torrent ofereceu como genuino resultou diferente do SHA256SUM
original do CD comprado na loja. Então vejamos, recebi to bitorrente, um SHA256SUM que conferiu certo
com o que gerou o computador ao ler o CD, e memo assim o cd que
vei somou diferente do cd vendido na loja, e dava, realmente, o cd baixado pela
rede, umas travadas, certo que houvera sido BATIZADO. Acredito, então,
que cometi um erro de principiante, porque além de verificar se os
dois SHA256SUM estavam certos, uma coisa que a própria MD5 antiga, poderia
ter feito, eu deveria ter conferido o SHA1 do Fedora Baixado com o SHA1
que o Fedora oferece em seu site, e eu fiz isso, e as somas deram
diferentes, portanto eu já tinha todas as evidências para crer que o cd
havia cido BATIZADO, se fosse um erro de mídia, o CD não entraria no K3B e
não daria o boot. Ocorre então que o SHA256SUM melhora a segurança
se for CORRETAMENTE usado, o que o bittorrente faz, é dar um SHA256SUM
não autenticado para o usuário, um SHA256SUM que vêm pelos usuários
P2P, e o bittorrente chera, no usuário, a fantasia de ele, usuário, está utilizando
esta nova e podera ferramenta, o SHA256SUM, quando, em verdade, o que
o bittorrent faz é usar o SHA256SUM como se fosse um mero MD5. Pergunto-me
o porque de a Fedora não disponibilizar o SHA256SUM oficial em seu sitío,
é uma pergunta de principiante, reconheço, porque isso é atribuição da
GPG, ou seja, é uma questão de chave pública; o usuário, então, tem que
correr atrás da chave pública, ora bolas, se a rede não é segura, como é
que vai chegar um chave pública segura? Aí está o milagre da tecnologia,
teoricamente, deveria chegar e o usuário não precisaria ter que comprar
ou pedir o cd original da loja emprestado para poder provar que os
cd's de distros que estão circulando pela rede são, o mais das vezes,
BATIZADOS, e o sujeito pensa que o erro é dos programadores, do Linux, e foi,
em verdade, uma SABOTAGEM. O cidadão usuário de intenet não quer
ser feito de bobo, ele se pergunta, qual é a minha certeza? Tenho um CD,
uma distro que baixei, a única CERTEZA que tenho, é o MD5SUM, SHA1SUM,
SHA256SUM que posso gerar a partir do linux que estou rodando. Agora que
tenho estes dados, o que faço? Primeiro, não posso confiar nos dados
enviados junto com a distro que baixei, os quais vieram com o bittorrente,
porque se eu fosse crédulo e não estivesse a questinar a integridade
da distro baixada, nem precisaria do CHECKSUM; então o primeiro passo
é colocar em dúvida tudo o que chegou pela internet enviado pelo torrent,
inclusive a chave pública, que , sem uma confirmação, não passa de
uma BRUXARIA. Ok, coloco de lado a distro baixada e os dados de chave publica
enviados pelo torrent, o que é normal, pois a eles me cabe questionar,
pego a CERTEZA que tenho, e vou na fonte. A fonte foi o FEDORA, eles
tem a SHA1, ora bolas, se a SHA1 que tenho está diferente da deles não
há o que duvidar, vou ter que baixar a distro novamente ou arriscar
utilizá-la batizada mesmo. A pouco mencionei o ZENWALK, a palavra ZEN é
uma palavra bonita, significa, simplicidade, e o software é Francês, vocês
já viram algum Francês burro? Amigos, na França só tem AVIÃO, então será
que o ZENWALK simplificou as coisas e so forneceu o MD5 por achar que
a palavra Zem é feia e os Franceses não gostam de Vinho? É óbvio que o usuário final sendo feito de otário por não saber utilizar o SHA256SUM, por ser crédulo
e acreditar que tudo o que vem pelo P2P é perfeito, não vai precisar nunca de nada que seja mais sofisticado que um simples MD5. Se eu tivesse um simples MD5
do Fedora, que é a FONTE, e conferisse com o MD5 gerando pelo meu linux
que está rodando, parabéns à França, eu teria muitos melhores resultados do que conferir um SHA256SUM oferecido pelo torrent para ser absurdamente
checado em sima de sim mesmo. Enquanto não houver conhecimento e os perpetradores se aproveitarem das superstições dos usuários e as novas tecnologias, aí incluindo o SHA256SUM forem usadas como benzedura, vale
a opção do Zenwalk, vamos de MD5, que esse pai de santo aqui faz o mesmo
milagre e cobra menos.
Visitar o website do usuário Encontrar todas as respostas deste usuário
Citar esta mensagem em uma resposta
27/05/2010, 09:01
Resposta: #24
Re: Miscelânio em Modo de Texto
bb3110a8999716806f6de0ea684ae0f4 CDlinux_CE-0.9.6.1.iso
O k3b aind me fornece o id do publicador Cdlinux.info
e o id do preparador [email protected]

A palavra chave é em quem confiar
e4e3ec0b86428e1cac8973d2e6e96dbcfca4d8a7d9c0c9b13b1c99940fc0abb5

[email protected]:/media/3A273-35AJ$ sha1sum CDlinux_CE-0.9.6.1.iso
8a755e6eee909305b9ae5297c4466af2c5b9808b CDlinux_CE-0.9.6.1.iso
8a755e6eee909305b9ae5297c4466af2c5b9808b

Baixado de uma fonte, confiável, porque tem uma
reputação, alquem para quem se poderia relatar
em caso de suspeita de mídia maliciosmente alterada.

O teste final, o mais forte, seria o
e4e3ec0b86428e1cac8973d2e6e96dbcfca4d8a7d9c0c9b13b1c99940fc0abb5

porque, os hackers já conseguiram gerar cds que tem
MD5 igual e conteúdos diferentes, já geraram um SHA1 iguais
com um conteúdo diferente, são códicos que continuam funcionando
mas que não dão uma garantia total, porque já foram quebrados.

Então a garantia total de que o cd não tenha sido BATIZADO,
dependeria de o usuário pegar a distro baixada, com tudo
conferido, usar um DD, para comparar o cd baixado, aparentemente
correto, como o enviado pelo IBÍBLIO, e provarm, ATRAVES
COMPARANDO COM O CD ORIGINAL COMPRADO NA LOJA, que as trilhas
não coincidem. Isso feito, obrigaria as pessoas a mais prontamente
exigirem a conferência SHA256SUM, mesmo porque as CHAVES PÚBLICAS,
só pode garantir a segurança do usuário, se não estiverem
misturadas na transmissão dos dados as chaves antigas com as novas,
quer dizer, continurão os dados seguros caminhando por avenidas
inseguras até que todos estejam desarmados com as novas chaves
públicas padronizadas.

Entao tudo deu certo baixando direto da Fonte, e me parece, agora, a alternativa
baixar as distros direto da fonte, alguem para quem se possa relatar os problemas,
a IBIBLIO esta de parabens, o que falta eh disponibilizar o SHA256SUM de forma organizada
em um banco de dados facil de conferir para todas as distros de forma organizada, do jeito
que esta ate parece um caos, cada distro quer colocar ou o MD5SUM, ou o SHA1SUM, ou o SHA256SUM,
em lugares diferentes, deveriam existir bibliotecas universais de acesso publico onde todos
estes CHECKSUMS estivessem faceis de achar. Eu, que sou usuario comum, nao sou servidor,
nao tenho tanta necessidade de utilizar CHAVES PUBLICAS DE SEGURANCA GPG, sei que
os servidores quando as bem utilizam em certa medida nos protegem, tavez ate um dia entenda
o que eh uma GPG, no momento, o que preciso sao dos SHA256SUM, que as distros brasileiras
e ate as internacionais, nao forncem de maneira organizada
Visitar o website do usuário Encontrar todas as respostas deste usuário
Citar esta mensagem em uma resposta
27/05/2010, 17:36
Resposta: #25
Re: Miscelânio em Modo de Texto
:shock:

"Na caixa dizia: Requer MS Windows ou superior, então eu instalei Debian/GNU
Linux!"

.
Antes de postar use a busca e veja o Wiki.
Busca do FD
Wiki do FD
Visitar o website do usuário Encontrar todas as respostas deste usuário
Citar esta mensagem em uma resposta
27/05/2010, 18:18
Resposta: #26
Re: Miscelânio em Modo de Texto
Querido Amigo Linux, estou lendo tudo o que posso, confesso
que quanto mais leio menos entendo, assim mesmo vale a pena.
Estou estudando o Kernel, peguei um livro no rapidshare, o
Understanding_the_linux_kernel.pdf, são quinhentas páginas,
talvez daqui uns dois anos, um possa ter uma idéia mínima sobre o
assunto, achei alguma coisa sobre os o modo grafico aqui:

fbdev: intelfb: add support for the Intel Integrated Graphics Controller 965G/965GM
author Maik Broemme <[email protected]>
Mon, 28 Apr 2008 09:15:43 +0000 (02:15 -0700)
committer Linus Torvalds <[email protected]>
Mon, 28 Apr 2008 15:58:41 +0000 (08:58 -0700)
commit 0e170c72c0c55bd78213a0f5053bd9a1dde403b7
tree f117d430e70e16aea175a4e7c74fa38e31f93094 tree | snapshot
parent 0aa163418edfb96ca3b39133979d8e4352aaac3c commit | diff
fbdev: intelfb: add support for the Intel Integrated Graphics Controller 965G/965GM

Add support for the 965G and 965GM graphic chipsets to the intelfb driver. I
have a notebook with an Intel Mobile GM965/GL960 Integrated Graphics
Controller and with the attached patch the framebuffer comes up. I have
tested it a bit with DirectFB to make sure it is working stable.

I also have an Intel Mobile GM945 and I compared the results, the programming
interface of the 9xx series from Intel is mostly the same, so I think the
patch should add all the functionality which the 945GM has.

Signed-off-by: Maik Broemme <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Antonino Daplas <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Krzysztof Halasa <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Documentation/fb/intelfb.txt diff | blob | history
drivers/video/Kconfig diff | blob | history
drivers/video/intelfb/intelfb.h diff | blob | history
drivers/video/intelfb/intelfb_i2c.c diff | blob | history
drivers/video/intelfb/intelfbdrv.c diff | blob | history
drivers/video/intelfb/intelfbhw.c diff | blob | history
Visitar o website do usuário Encontrar todas as respostas deste usuário
Citar esta mensagem em uma resposta
Responder 


Ir ao Fórum:


Usuários visualizando este tópico: 1 Visitantes

Entre em Contato | Fórum Debian | Voltar ao Topo | Voltar ao Conteúdo | Modo Leve (Arquivo) | Feeds RSS