Bom dia, depois de algum tempo OFF, volto com uma documentação com aquela tradução meia boca pra galera…
Então… isto aqui serve apenas para você ter um melhor proveito de sua placa de vídeo INTEL, e conseguir rodar aplicações que exigem um pouco mais dela.

Hardware Suportado

Os drivers da Intel para Linux, suportam os seguintes chipsets:

Nome

intel – Intel chipsets gráficos integrados

Sinopse

Section “Device”
Identifier “devname”
Driver “intel”
…
EndSection

Descrição

intel é um driver do xorg para chipsets de gráficos integrados. O drive suporta intensidade de cores de 8, 15, 16 e 24. Todos os modos visuais são suportados em 8. Para o i810/i815 outras profundidades de cores suportam os visuais de TrueColor e DirectColor. Para o i830M e posterior, apenas o TrueColor é suportado para profundidade de cores maiores que 8. O drive suporta aceleração 3D via o Direct Rendering Infrastructure (DRI), mas apenas em profundidade de cores 16 para o i810/i815 e profundidade de cores 16 e 24 para o 830M e posterior.

Hardware Suportado

intel suporta o i810, i810-DC100, i810e, i815, i830M, 845G, 852GM, 855GM, 865G, 915G, 915GM, 945G, 945GM, 965G, 965Q, 946GZ, 965GM, 945GME, G33, Q33, e Q35 chipsets.

Detalhes de Configaração

Por favor veja a documentação do xorg.conf(5) para detalhes de configurações gerais. Esta seção apenas irá informar configurações referentes ao drive da intel.

Os chipsets de familia 8xx e 9xx tem uma arquitetura de memória unificada e usa a memória do sistema para a memória de vídeo. Para a família dos i810 e i815. Isso geralmente é definido pelo “agpgart” ou “agp” kernel driver. Linux, FreeBSD, OpenBSD, NetBSD, e Solaris tem esses drivers do kernel disponíveis.

Por padrão, o i810 usará 8 megabytes da memória do sistema para gráficos. Para o 830M e posterior, o driver ira alocar a memória automaticamente. A opção VideoRam, que era utilizada para definir um tamanho maior de memória para vídeo, agora é ignorada.

As seguintes Options de drivers são suportadas

Option “NoAccel” “boolean”
Desabilita ou Habilita a aceleração. Padrão: aceleração é habilitada.

Option “SWCursor” “boolean”
Desabilita ou Habilita o cursor de software. Padrão: cursor de software é desabilitado e um cursor de hardware é utilizado para configurações onde o cursor de hardware esta disponível.

Option “ColorKey” “integer”
Define o valor padrão de pixel para a chave de YUV vídeo overlay. Padrão: não definido.

Option “CacheLines” “integer”
Este permite o usuário mudar a quantidade de memória gráfica utilizada em aceleração 2D e vídeo quando a aceleração XAA esta habilitada. Diminuindo a quantidade garante mais para texturas 3D. Aumentando isto, pode melhorar a performance 2D pelo preço de sua performance 3D. Padrão: depende da resolução, intensidade de cor, e memória de vídeo disponível. O driver aloca espaço para 3 ecrãs de pixmaps mais um HD-sized XV video. O padrão utilizado para uma configuração específica  pode ser encontrado examinando o log do arquivo Xorg.

Option “DRI” “boolean”
Desabilita ou Habilita o suporte a DRI. Padrao: DRI é habilitado para configurações que ele é suportado.

Option “DDC” “boolean”

Desabilita ou Habilita o suporte a DDC. Padrão: habilitado. (é suportado apenas para os chipsets i810 e i815)

Option “Dac6Bit” “boolean”
Habilita ou Desabilita 6-bits por RGB para modo 8-bit. Padrao: 8-bits por RGB para modo 8-bit.

Option “XvMCSurfaces” “integer”
Esta opção habilita o XvMC. O parâmetro inteiro define o numero de superfícies para usar. Valores válidos são 6 e 7. Padrão: XvMC é desabilitado.

Option “VideoKey” “integer”

Este é o mesmo que “ColorKey”. É utilizado para a compatibilidade de outros drivers.(é suportado para os chipsets 830M e posterior)

Option “XVideo” “boolean”
Desabilita ou habilita o suporte ao XVideo. Padrão: XVideo é habilitado para configurações que é suportado.

Option “Legacy3D” “boolean”
Habilita o suporte ao driver 3D i915_dri.so. Irá, entre outras coisas, fazer o driver 2D chamar o libGL para carregar o driver 3D i915_dri.so ao invés do novo i915tex_dri.so. Esta opção é apenas utilizada para chipsets entre i830-i945. Padrão para as series de chipsets i830-i945: Habilitado para as versões de drm do i915  < 1.7.0. Caso contrario desabilitado. Padrão para o i810: A opção não é utilizada. Padrão para o i965: A opção é sempre true.

Option “AperTexSize” “integer”
Define o tamanho em kiB da area de abertura AGP que é reservada para o gerenciamento de memória DRM presente na drm i915 desde a versao 1.7.0 e posterior, e isto é usado no driver 3D no Mesa desde a versão 6.5.2 e posterior. Se o valor é muito grande para fazer a alocação da VideoRam, o driver tentará reduzir isto automaticamente. Se você utiliza apena o Mesa ou DRM antigos, você definirá este valor para zero, e ativa o pool de textura de legado (veja Option “Legacy3D” ). Se você roda programas 3D com um requerimento de memória alto, Você ganhará alguma performance aumentando este valor. Padrão: 32768.

Option “PageFlip” “boolean”
Habilita o suporte para lançamento de página. Este talvez aumente a performance 3D ao custo de uma perda de performance com 2D e 3D juntos. Entretanto note que isto não beneficiará sem corresponder o suporte ao Mesa 3D driver e talvez não dará benefícios totais sem o triple buffering (veja Option “TripleBuffer” ). Padrão para i810: A opção não é utilizada. Padrão para i830 e posterior: Desabilitada (Esta opção atualmente é instável).

Option “TripleBuffer” “boolean”
Habilita o suporte para triple buffering. Este aumentará a performance 3D ao custo de uma perda de performance em 2D e 3D juntos. Entretanto note que isto não beneficiará sem corresponder o suporte ao Mesa 3D driver e talvez não dará nenhum benefício sem o lançamento de páginas  (veja Option “PageFlip” ). Padrão para i810: A opção não é utilizada. Padrão para i830 e posterior: Desabilitada.

Option “AccelMethod” “string”
Escolhe a arquitetura do modo de aceleração, entre “XAA” ou “EXA”. XAA é o antigo (mas estável) baseado na arquitetura de aceleração do XFree86. EXA é uma nova e simples arquitetura de aceleração designado para uma melhor aceleração da extensão X Render. Padrão: “XAA”.

Option “ModeDebug” “boolean”
Habilita informações detalhadas sobre debuggin no log do servidor.

O 830M e posterior suportam as seguintes saídas no RandR 1.2:

VGA

Saída VGA analógica

LVDS

Painel do laptop

TV

Saída de TV integrada

TMDS-1 Primeira saída DVI SDVO

TMDS-2 Segunda saída DVI SDVO

saídas SDVO e DVO TV não são suportadas pelo driver desta vez.

referencia: http://alcor.concordia.ca/manpages/sys4/intel.4.html

Olá

Provavelmente alguém já deve ter passado este caso onde tens o interesse de ver qual o procedimento adotado em um pacote debian, mas opa perai, você não usa debian então como proceder para ver o conteúdo do package?? Instalar aquela pilha de programas ….

Não é preciso, basta você utilizar o comando ar (existente na maioria das distros), pois apesar de quando você roda o comando “file” em um package.deb, ele dizer que é um “Debian binary package”, seu real tipo (minha opinião) é um ar file, arquivos do tipo ar são como tar, arquivadores de arquivos ( sim ficou estranho mas é isto), são somente arquivos juntados sem compactação.

Para tanto o procedimento de extração

ar xo package.deb

Onde:
o – mantém o arquivo .deb
x – extraí o conteudo do ar

Bom daí em diante é a estrutura de um pacote debian…..

Estou postando isto pois precisei ver o conteúdo de um pacote debian e bom, não lembrava mais disto e tive que procurar para tanto agora já sei onde encontrar

O QUE É SQL INJECTION ?

A técnica de injetar um código malicioso em um trecho de código de tratamento SQL.
A maioria das tentativas de SQL Injection irão ser realizadas em um input form, de seu código html, mas também podem ser manipuladas atraves das urls de seu site.

O comando mais básico de SQL Injection é parecido com este:

	Variável' or 1=1--

Vamos supor agora que temos um form de login, e que ele irá receber esta variável na forma em que foi escrita, sem nenhum tratamento.

Portanto, o código SQL que seria executado ficaria assim:

SELECT * FROM users WHERE username = 'Variável' or 1=1--'

Viu como o código serve como uma luva no nosso SQL Injection ? O resultado irá nos dar acesso a um usuário, levando em conta que retornara verdadeiro, porque ? porque 1=1.

E o ‘–’ ? Isto serve para dizer ao SQL que ele irá ignorar qualquer outro comando SQL que foi colocado no final, portanto isso ira garantir que nenhum outro código SQL feito na programação interfira em nosso SQL Injection.

Algumas outras sintaxes comuns de SQL Injection são:

    ') or ('1'='1
    "or "1"="1
    ' or '1'='1
    Or 1=1--
    " or 1=1--
    ' or 1=1--

SQL INJECTION, ATACANDO ATRAVÉS DE URLS:

Você sabia que é possivel fazer um ataque de SQL Injection através de URLs ? E isso com certeza é mais perigoso. Geralmente quando utilizamos PHP + SQL, nossas urls ficam no formato:

http://YourWebsite.com/login.php?id=2

e adicionando o código sql ao final da url poderia ficar assim:

http://YourWebsite.com/login.php?id=2‘; DROP TABLE login; #

o caracter # é que nem o — que utilizamos anteriormente…

TÉCNICAS DE PREVENÇÃO DE SQL INJECTION

Editando o tamanho das nossas forms:
Isto apenas irá dar um trabalho a mais ao atacante, neste caso ele teria que refazer os formulários, removendo o tamanho, levando em consideração que os forms são feitos em html puro, portanto qualquer um pode ver seu código…

Validação do tipo de dado:
Uma outra boa idéia é fazer a verificação de dados, quando são digitados na form, portanto, se houver caracteres estranhos, como ‘, ; ou até mesmo um #, já pode acusar erro e não executar o código SQL

Privilégios de usuários:
Uma técnica que deve ser praticada também é de nunca acessar o banco de dados como root, e sim como um usuário que tenha certos privilégios, por exemplo, para pesquisas podemos fazer um usuário que seja apenas leitura, assim quando entramos com dados na form, mesmo que seja executado um comando sql malicioso, o usuário ira apenas poder ler dados, impedindo-o de inserir ou deletar registros.

A Verdadeira solução:
Utiliza-se a função ‘mysql_real_scape_string();’, veja como ele funciona:

 $name = "John";
    $name = mysql_real_escape_string($name);
    $SQL = "SELECT * FROM users WHERE username = '$name'";

portanto, quando um alguém mal intencionado tenta executar o SQL Injection, com esta função ele ficaria da seguinte forma:

    $malcious_input = "' OR 1'";
    // Não se assuste!!
    // Com o uso de mysql_real_escape_string()
    // o seguinte é retornado:
	\' OR 1\'

    // Veja como os contra barras escapam as aspas!
    // Agora usuários não podem colocar dados maliciosos...

CONCLUSÃO:
a função mysql_real_escape_string() – não tem um nome tão incrivelmente mágico, mas estes 24 caracteres são a bondade do SQL Injection, o que salva os programadores descuidados… agora, é só aplicar a teoria em seus projetos ;D