However the problem is that we don't apply the update to the existing stable kernel, the patch is always applied on top of the progressing kernel, meaning we also end up shipping a lot of other things such as bugfixes, updates to the latest upstream STABLE tree and various other things. This however is confronted with one problem, the kernels in between the current stable and next update are not all being pushed to updates-testing - only selected kernel updates are. In cases where we then have to release a security fix we are forced to ship a bunch of stuff additionally which is not likely to have been tested extensively.

It occures to me that catching these bugs before they become a problem for average users could be accompliced by making better use of updates-testing, testers are normally willing to experience a degree of breakage and are qualified to file bugs for the most part. Then at least when an urgent update is required we will not likely be surprised by massive unrelated breakage - it might still occure but we can warn people if avoiding massive breakage is impossible and reverting the offending patches is impossible prior to release.

An additional problem caused by this is that when an urgent release contains bugs we will be urged to ship another update straight afterwards. Opening us to even more bugs from another untested delta (since other development is likely to have gone on along side the bugfix) and having our users suck down a second kernel package shortly after the original update.

The other option would be applying the security update to the current stable kernel and not carrying the current delta in the update, but this is expensive in terms of man power and time, it also goes counter to the rapidly developing nature of Fedora in general. This is the realm of the enterprise distros, if people want this approach something like RHEL/CentOS is likely a better fit for them.

While Symbian focuses on ease of use and rich features, Android focuses on complete touch functionality with several applications. Till now, Android only has test versions out, which are a little buggy. An official stable release is expected later this year. So who will be the king of the mobile platform?

Personally, I feel that a mobile platform cannot be judged on the basis of emulator performance and sadly that is what I had to work on. I have used Symbian OS since the launch of the 3650. Needless to say it was quite an improvement when compared to my old 3310. The old Symbian OS had several problems, like slow software, somewhat erratic operation. The new one however, is pretty good. It boasts of better performance and stable software.

The Android, which is still in development stages, has some problems at the moment. I couldn't even figure out how to turn off Google Maps :D.

Just when Android was looking to be the leader of the mobile platform, Symbian went open source. This will be a major bump to Android, since Symbian already has a decent market share.

In my humble opinion, it will be very hard for Android to capture the market initially, since the hardware that it uses is somewhat similar to the Windows Mobile Platform, and it does not come cheap! Symbian may continue with their current hardware (eg. ARM in case of Nokia).

Symbian has its own structure, but Android uses the rock solid Linux Kernel 2.6.x. This will definitely invite geeks and technology enthusiasts like us to choose Android over Symbian.

It will be an interesting battle to say the least. Let's all look forward to it.. :D

El Kernel 2.6.27 dará soporte a más de 100 webcams. El estándar UVC(USB Video Class) es requerido para obtener la certificación "Windows Vista" así que los fabricantes de hardware deben incluirla. Entre los periféricos incluidos se encuentra webcams, "camcorders" digitales, conversores de video analógico y sintonizadores de televisión, entre otros. Esto significa que tendremos soporte automático para dispositivos, lo que significa que si tienes una webcam en tu portátil, ésta funcionará de manera automática.

Fuente | Linux para todos

Linux adalah sistem operasi open source yang paling populer, namun ternyata umurnya termasuk muda dibanding sistem operasi lain. Di masa awal komputer, programer membuat program berlandaskan bahasa untuk hardware yang bersangkutan. Tanpa sistem operasi, di suatu waktu hanya satu aplikasi (dan satu orang) yang bisa memakai perangkat keras yang super mahal. Sistem operasi mulai dikembangkan di tahun 1950an untuk lebih menyederhanakan proses pengembangan aplikasi. Contoh sistem operasi di era pertama adalah General Motors Operating System (GMOS) yang dibuat untuk mesin IBM 701 dan FORTRAN Monitor System (FMS) yang dibuat oleh North American Aviation untuk mesin IBM 709.

Pada dasawarsa 1960, Massachusetts Institute of Technology (MIT) bersama beberapa perusahaan mengembangkan sistem operasi bernama Multics (Multiplexed Information and Computing Service) untuk mesin GE-645. Salah satu pihak pengembang, yaitu AT&T, keluar dari proyek Multics dan mengembangkan sistem operasi mereka sendiri di tahun 1970 dan diberi nama Unics. Bahasa pemrograman C kemudian dibuat untuk Unics, sehingga pengembangan sistem operasi menjadi portable.

Dua puluh tahun kemudian, Andrew Tanenbaum membuat versi microkernel dari UNIX® dan diberi nama MINIX (singkatan dari minimal UNIX). MINIX dirancang untuk komputer personal. Sistem operasi inilah yang memberi inspirasi kepada Linus Torvalds memulai pengembangan Linux di awal 1990 (lihat gambar).

Gambar: Rilis kernel Linux vs jumlah baris program

Linux dengan cepat berevolusi dari karya perseorangan menjadi proyek sedunia yang melibatkan ribuan developer. Ini terjadi karena Linux mengadopsi lisensi model GPL (GNU General Public License). Dengan lisensi GPL, kernel Linux terlindungi dari eksploitasi komersial dan mendapatkan keuntungan dari paket-paket yang dikembangkan oleh proyek GNU (oleh Richard Stallman, jumlah kode GNU jauh lebih kecil dibanding kernel Linux), misalnya paket GCC (GNU Compiler Collection) dan shell.

disadur dari: Anatomy of the Linux kernel

Download here

Features:
Num 1 | Name Tags
Num 2 | Wallhack
Num 3 | NoRecoil + NoSpread
Num 4 | RadarHack
Num 5 | NoFlash + NoShellShock
Num 6 | NoSmoke + NoFog
Num 7 | CVAR Bypass
Num 8 | Crosshairhack
Num 9 | Laser

CVars:
/r_fullbright 1

Download

Features:
Num 1 | Name Tags
Num 2 | Wallhack
Num 3 | NoRecoil + NoSpread
Num 4 | RadarHack
Num 5 | NoFlash + NoShellShock
Num 6 | NoSmoke + NoFog
Num 7 | CVAR Bypass
Num 8 | Crosshairhack
Num 9 | Laser

CVars:
/r_fullbright 1

Download

Features:
Num 1 | Name Tags
Num 2 | Wallhack
Num 3 | NoRecoil + NoSpread
Num 4 | RadarHack
Num 5 | NoFlash + NoShellShock
Num 6 | NoSmoke + NoFog
Num 7 | CVAR Bypass
Num 8 | Crosshairhack
Num 9 | Laser

CVars:
/r_fullbright 1

Download

Os invitamos consultar también la Listado de cambios o "Changelog" de esta nueva entrega del Kernel.

Información sobre el Kernel en la Wikipedia.
FAQS o preguntas frecuentes sobre el Kernel Linux.

Descargar Kernel Linux.

Fuente | daboweb

I've found that booting the target system or virtual machine every time you want to replace a driver file with an updated build and then rebooting to have the new driver loaded significantly prolongs the cycle. Therefore, I was happy to discover Windbg's .kdfiles command.

The .kdfiles command configure's the kernel debugger's driver replacement map. Whenever the NT Memory Manager attempts to load a driver image, it consults the kernel debugger, if attached, asking it for an alternative driver image. If the debugger has one, it is transmitted over the kernel debugging connection from the host to the target, and used in lieu of the target's local driver image.

Using the driver replacement map makes it easier to replace a driver with an updated version. However, in its usual form, the replacement map feature has a significant limitation - it cannot replace boot load drivers.

To understand the logic behind this restriction, one must consider the nature of boot driver loading. While demand-start drivers are started by the user-mode Service Control Manager (SCM) and system-start drivers are loaded by NTOSKRNL's IoInitSystem function, boot drivers are, as their name suggests, required for the system to boot and are therefore loaded by osloader, a part of ntldr (this description is for pre-Vista systems).

By the time the NT kernel is up and its Memory Manager consults the kernel debugger and its driver replacement map, it is far too late to do anything about those drivers which have been pre-loaded by the OS loader. The initial breakpoint offered by the kernel debugger is simply too late.

Fortunately, Microsoft recognized the importance of providing a driver replacement map for boot load drivers and provides a somewhat esoteric solution in the form of the debug version of NTLDR.

The debug version of NTLDR expects the kernel debugger to attach to it during system startup. Unlike the kernel debugger, it is not configured with the boot.ini file and is always configured to a 115,200 baud connection on the COM1 serial port.

The documentation for .kdfiles points out that the Windows Driver Kit (WDK) bundles a debug version of NTLDR in the debug subdirectory. However, such a file is nowhere to be found there, probably because the WDK now contains the Vista checked kernel in its debug directory and the modern Vista boot loader is distinct from NTLDR. More on Windows Vista later, but for now let's concentrate on Windows XP.

Failing to locate the debug NTLDR in the WDK, I turned back in time to the Windows Server 2003 SP1 IFS Kit, a variant of the Windows Server 2003 SP1 DDK for file system and file system filter developers. I was glad to find the ntldr_dbg file in its debug subdirectory.

However, my happiness quickly turned to disappointment when I replaced the original NTLDR with ntldr_dbg in a Windows XP virtual machine. The system refused to boot, claiming that NTLDR was corrupt. Since the debug directory in the IFS kit contains checked kernel binaries for Windows Server 2003 SP1, I figured that the provided version of ntldr_dbg is a match for that version, as well.

I turned to the archives, so to speak, and dusted off old MSDN Subscription CDs. I eventually turned up the rather antiquated Windows XP SP1 DDK. In there, I found another version of ntldr_dbg. I placed it as required and this time the system booted successfully.

It is unfortunate that one has to dig up the DDK of yore to locate the boot debugger. It really ought to be more accessible.

With the debug version of NTLDR is in place, when you boot the system, right before the OS loader menu appears, you see the following message:
Boot Debugger Using: COM1 (Baud Rate 115200)

Once the message is displayed, NTLDR blocks waiting for a kernel debugger to connect. I start the kernel debugger the way I'd usually start it:
windbg -b -k com:pipe,port=\\.\pipe\com_1

Soon enough, however, it is evident that this is no ordinary kernel debugging session:

Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\pipe\com_1
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 2600 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established. (Initial Breakpoint requested)
Symbol search path is: C:\WINDOWS\Symbols;SRV*E:\SymStore*http://referencesource.microsoft.com/symbols;SRV*E:\SymStore*http://msdl.microsoft.com/download/symbols
Executable search path is:
Module List address is NULL - debugger not initialized properly.
WARNING: .reload failed, module list may be incomplete
KdDebuggerData.KernBase < SystemRangeStart
Windows Boot Debugger Kernel Version 2600 UP Checked x86 compatible
Primary image base = 0x00000000 Loaded module list = 0x00000000
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
0041cf70 cc int 3
kd>

Windbg has attached to the Windows Boot Debugger, a debugging environment provided by the debug version of NTLDR at a very early stage of system startup, well before the NT kernel has been loaded. Indeed, the initial breakpoint at the boot debugger occurs before an OS to start has been selected at the loader boot menu.

With the boot debugger at its initial breakpoint, we can set up the driver replacement map as desired. For instance, we can replace NTFS and NDIS with their counterparts from the checked build of Windows XP:

kd> .kdfiles -m \WINDOWS\system32\drivers\Ntfs.sys C:\Stuff\xpsp3checked\Ntfs.sys
Added mapping for '\WINDOWS\system32\drivers\Ntfs.sys'
kd> .kdfiles -m \WINDOWS\system32\drivers\Ndis.sys C:\Stuff\xpsp3checked\Ndis.sys
Added mapping for '\WINDOWS\system32\drivers\Ndis.sys'
kd> g
BD: osloader.exe base address 00400000
BD: \WINDOWS\system32\NTKRNLMP.CHK base address 80A02000
BD: \WINDOWS\system32\HALMACPI.CHK base address 80100000
BD: \WINDOWS\system32\KDCOM.DLL base address 80010000
BD: \WINDOWS\system32\BOOTVID.dll base address 80001000
BD: \WINDOWS\system32\DRIVERS\ACPI.sys base address 8014C000
BD: \WINDOWS\system32\DRIVERS\WMILIB.SYS base address 80007000
BD: \WINDOWS\system32\DRIVERS\pci.sys base address 80062000
BD: \WINDOWS\system32\DRIVERS\isapnp.sys base address 80012000
BD: \WINDOWS\system32\DRIVERS\compbatt.sys base address 80009000
BD: \WINDOWS\system32\DRIVERS\BATTC.SYS base address 8000C000
BD: \WINDOWS\system32\DRIVERS\intelide.sys base address 8001C000
BD: \WINDOWS\system32\DRIVERS\PCIIDEX.SYS base address 8017A000
BD: \WINDOWS\System32\Drivers\MountMgr.sys base address 80181000
BD: \WINDOWS\system32\DRIVERS\ftdisk.sys base address 8018C000
BD: \WINDOWS\System32\drivers\dmload.sys base address 8001E000
BD: \WINDOWS\System32\drivers\dmio.sys base address 801AB000
BD: \WINDOWS\System32\Drivers\PartMgr.sys base address 801D1000
BD: \WINDOWS\System32\Drivers\VolSnap.sys base address 801D6000
BD: \WINDOWS\system32\DRIVERS\atapi.sys base address 801E3000
BD: \WINDOWS\system32\DRIVERS\vmscsi.sys base address 80073000
BD: \WINDOWS\system32\DRIVERS\SCSIPORT.SYS base address 801FB000
BD: \WINDOWS\system32\DRIVERS\disk.sys base address 80213000
BD: \WINDOWS\system32\DRIVERS\CLASSPNP.SYS base address 8021C000
BD: \WINDOWS\system32\drivers\fltmgr.sys base address 80229000
BD: \WINDOWS\system32\DRIVERS\sr.sys base address 802A7000
BD: \WINDOWS\System32\Drivers\KSecDD.sys base address 802B9000
KD: Accessing 'C:\Stuff\xpsp3checked\Ntfs.sys' (\WINDOWS\System32\Drivers\Ntfs.sys)
File size 814K.... ....BD: Loaded remote file \WINDOWS\System32\Drivers\Ntfs.sys

BlLoadImageEx: Pulled \WINDOWS\System32\Drivers\Ntfs.sys from Kernel Debugger
BD: \WINDOWS\System32\Drivers\Ntfs.sys base address 802D0000
KD: Accessing 'C:\Stuff\xpsp3checked\Ndis.sys' (\WINDOWS\System32\Drivers\NDIS.sys)
File size 424K.... ....BD: Loaded remote file \WINDOWS\System32\Drivers\NDIS.sys

BlLoadImageEx: Pulled \WINDOWS\System32\Drivers\NDIS.sys from Kernel Debugger
BD: \WINDOWS\System32\Drivers\NDIS.sys base address 804DC000
Shutdown occurred...unloading all symbol tables.
Waiting to reconnect.

We can see that the boot debugger picked up our driver replacements and transferred them from the host to the target through the kernel debugger connection. Alas, this can be a lengthy process for an obese driver over the 115,200 baud link...

Beyond being useful for replacing your own drivers, which is what I had in mind when I looked into this feature, the boot debugger can be used to easily go back and forth between Windows free build and checked build operating system components, as illustrated above. However, such use is not without its problems.

For one, replacing the kernel and the HAL with their checked counterparts through the driver replacement map does not work. An error citing kernel corruption results from such an attempt. The traditional way of using a checked kernel, by placing an appropriate entry in boot.ini, is still required.

When testing a file system filter driver, apart from using the checked version of the I/O Manager through the use of the checked NT kernel, it is advantageous to use checked versions of underlying file system drivers such as NTFS. The checked versions can assert when you pass on requests to them in a way which violates the file system's locking hierarchy and which may lead to deadlocks. Replacing the NTFS driver with the driver replacement map feature worked as expected, apart from causing NDIS to bugcheck during system boot with some sort of paging error. The issue was resolved by replacing NDIS with its checked counterpart through the driver replacement map, as well.

However, for a reason I do not understand, when placing the checked build of the Filter Manager, useful for debugging file system minifilters, there was no such luck. The boot loader complained after transferring the checked Filter Manager that the NTFS driver was corrupt. I disabled System File Protection and replaced the free drivers with the checked drivers on disk, the traditional way and the system booted with the checked NTFS and Filter Manager successfully. So it appears that the boot-time driver replacement map feature can be a bit flaky...

It is probably best to place checked operating system components the traditional way and only replace your own, frequently modified drivers with the boot debugger and the driver replacement map.

So much for Windows XP and the legacy NTLDR. But what about Windows Vista?

At first, the situation looked promising. In Windows Vista, the boot debugger is built-in. It can, for instance, be enabled for an existing boot entry with the Boot Configuration Database editor from an elevated command prompt:

C:\Windows\system32>bcdedit /enum

Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=C:
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
displayorder {current}
{5761b19a-1e8a-11dd-bcd4-000c29797dc6}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description Microsoft Windows Vista
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows
resumeobject {694d30db-e737-11dc-814f-e01223f3682a}
nx OptIn

Windows Boot Loader
-------------------
identifier {5761b19a-1e8a-11dd-bcd4-000c29797dc6}
device partition=C:
path \Windows\system32\winload.exe
description Debugging
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows
resumeobject {694d30db-e737-11dc-814f-e01223f3682a}
nx OptIn
debug Yes

C:\Windows\system32>bcdedit /bootdebug {5761b19a-1e8a-11dd-bcd4-000c29797dc6} ON

The operation completed successfully.

Unlike the XP boot debugger, the Vista boot debugger is set for a specific boot loader menu entry. Once we reboot and pick the entry for which boot debugging is enabled, we can attach:

Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\pipe\com_1
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 6001 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established. (Initial Breakpoint requested)
Symbol search path is: C:\WINDOWS\Symbols;SRV*E:\SymStore*http://referencesource.microsoft.com/symbols;SRV*E:\SymStore*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Boot Debugger Kernel Version 6001 UP Free x86 compatible
Primary image base = 0x00584000 Loaded module list = 0x00684e78
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
winload!RtlpBreakWithStatusInstruction:
005bce88 cc int 3
kd> k
ChildEBP RetAddr
00120c6c 005b0862 winload!RtlpBreakWithStatusInstruction
00120e84 005b0760 winload!vDbgPrintExWithPrefixInternal+0x100
00120e94 0058bdaf winload!DbgPrint+0x11
00120eb0 0058bf6d winload!BlBdStart+0x81
00120f48 005a2f88 winload!BlBdInitialize+0x172
00120f64 005a28c2 winload!InitializeLibrary+0x168
00120f7c 0058513a winload!BlInitializeLibrary+0x42
00120fe8 0044646a winload!OslMain+0x13a
WARNING: Frame IP not in any known module. Following frames may be wrong.
00000000 f000ff53 0x44646a
00000000 00000000 0xf000ff53

We can see that in Vista, the boot debugger's initial break is in the new winload.exe, replacing the osloader.exe embedded in ntldr of yesteryear. At this point the boot load drivers have yet to be loaded, so it would be perfect to set the .kdfiles driver replacement map at this point.

Alas, no such luck. It turns out the boot load driver replacement map feature is MIA in Windows Vista. This is confirmed by Microsoft's Doron Holan in a reply to a post (free registration required) in OSR's WINDBG mailing list. It is unclear what is the point of bundling the boot debugger with the regular operating system, unlike in the case of the hard to find ntldr_dbg for XP, only for it to be completely useless... Anyone using the boot debugger for purposes other than boot load driver replacement is probably working for Microsoft, so why should the boot debugger be a part of the OS if it is now missing what seems to be its most important functionality?

Hopefully the boot load driver replacement map will make a comeback in the Windows 7 boot debugger...

Prosegue il lavoro di Chris Wright e Greg Kroah-Hartman, che coordinano il gruppo per la manutenzione del Kernel 2.6.25.
E' stata rilasciata la versione, la 2.6.25.10, che si occupa della correzione di numerosi problemi. Gli sviluppatori si raccomandano di apssare il prima possibile a questa versione.
Potete visitare questa pagina per vedere il changelog, oppure fare il download

Fonte: Linux Valley

Antes de falarmos sobre comandos, vamos entender um pouco da arquitetura do Linux, que basicamente trabalha em camadas:

Na camada mais interna da figura, temos o hardware, que é representado pelos dispositivos físicos (por exemplo, HD, cdrom, etc).

Em seguida, temos a camada do kernel, que é o coração (núcleo) do sistema operacional e que interage com o hardware. Algumas tarefas do kernel são:

* Implementar o sistema de arquivos e meios de acesso (leitura, escrita e execução);

* Gerenciar a swap

* Gerenciar software que implementa serviços de rede;

* Gerenciar comunicação entre processos;

* Prover facilidades para criar, examinar e modificar processos;

* Prover funções que tornam os recursos do sistema disponíveis aos processos.

Fechando essa camada, temos o shell. Basicamente, shell é um nome comum para um conjunto de programas que tem o propósito de fornecer uma interface interativa com o usuário, onde comandos podem ser digitados, tarefas podem ser controladas, manipuladas, etc.

Por outro lado, os shells também funcionam como linguagem de programação (interpretadas) e são uma forma relativamente eficiente de se executarem tarefas complexas.

Entre os shells conhecidos temos o bash, o csh, sh, ksh. O shell padrão do Linux é o bash.

As diversas faces do Linux

O Linux é um sistema operacional multiusuário, multitarefa e multiprocessado. Além de tudo isto, ele segue o padrão POSIX/UNIX, o que garante que temos no Linux todo sistema de proteção do núcleo do kernel, ficando um pouco difícil um programa travar em Linux. (Sim! Apesar de ser difícil um Linux pode travar... ;)).

Linux multiusuário

Um sistema multiusuário é capaz de atender a vários usuários interativos simultaneamente. Isto é bem diferente de diversos usuários conectados a um servidor Novell ou NT. Esses usuários são apenas clientes do servidor de arquivos do Netware ou do NT, não são usuários interativos. Aliás, esses dois sistemas são monousuários.

A vantagem disso é que o Linux pode ser distribuído como um servidor de aplicativos; ou seja, Os usuários podem acessar um servidor Linux através da rede local e executar aplicativos no próprio servidor.

Linux multitarefa

Um sistema multitarefa é capaz de executar simultaneamente vários programas, garantindo a melhor distribuição de recursos entre esses programas. Por exemplo, você pode editar a planilha do seu fluxo de caixa enquanto baixa os seus e-mails.

Linux multiprocessado

Um sistema multiprocessado é capaz de tirar proveito de placas-mãe com várias CPUs, ou seja, permite o uso de mais de um processador.

O Linux reconhece mais de um processador e trabalha com SMP (Multiprocessamento Simétrico), clusters de máquinas, na qual uma máquina central controla os processadores das outras para formar uma “única” máquina, principalmente nas versões de kernel mais atuais (graças ao Linux, o Titanic afundou ;))

E além disso...

O Linux oferece diversas vantagens para que o utiliza. A primeira vista, pode parecer um sistema operacional complicado e difícil de trabalhar. Mas aprender Linux, é como aprender um novo idioma... no começo, as palavras são estranhas, não dá pra entender nada e parece que nunca vamos aprender.

Depois de um tempo, com dedicação,começamos arriscar umas palavrinhas, e, quando menos esperamos estamos tagarelando no novo idioma.

Assim é com o Linux. Aprende um comando aqui, um jeito de usar o gerenciador de janelas acolá... quando formos ver, estaremos utilizando o sistema... e o melhor de tudo: sempre aprendendo coisas novas; afinal de contas, no Linux não existe só um jeito pra se fazer as coisas!

Ah, e se não gostar do Linux, não se preocupe: o máximo que vai acontecer é você aprender algo novo! =)

* Se ha encontrado un fallo en las rutinas de copia de memoria en el kernel de Linux al ejecutarse en ciertos sistemas AMD64. Si falla un intento de copia de memoria del kernel, las rutinas no ponen a cero las porciones de memoria que fueron copiadas en destino, lo que podría ser aprovechado por un atacante para ganar acceso a información sensible.

* Se ha descubierto una condición de carrera en ptrace que podría ser aprovechada por un atacante local para causar una denegación de servicio en el sistema (kernel hang).

* Existe un fallo en la emulación de los kernel de 32 y 64 bits que podría ser aprovechado por un atacante para causar una fuga de datos por medio de un binario especialmente manipulado.

* Se ha descubierto que el kernel de Linux manejaba las operaciones de cadenas de una forma opuesta a la de GNU Compiler Collection (GCC). Esto podría ser aprovechado por un atacante local sin privilegios para causar la corrupción de la memoria.

La actualización también solventa otro fallo de menor importancia.

Se recomienda actualizar a través de las herramientas automáticas
up2date.

Fuente:
http://www.hispasec.com

Más Información:

kernel security and bug fix update
Advisory: RHSA-2008:0508-21
https://rhn.redhat.com/errata/RHSA-2008-0508.html

Добавлены заметки о пересборке ядра для Debian EEE.

Смотреть тут ]]> http://genlinux.wordpress.com/?p=164 Thu, 03 Jul 2008 12:22:39 +0000 Cross http://genlinux.wordpress.com/?p=164 Este GowTo se trata de explicar la manera más simple de eliminar entradas múltiples de el menú de GRUB en el arranque.

Vale, si te has atrevido a seguir hasta aquí, significa que realmente quieres eliminar esa entrada que está de más en el menú. Advertencia Para la Salud de Linux: Editar el menú de GRUB podría ser peligroso si no se hace lo que se debe.

Una vez dicho esto, podemos proseguir.

La mayoría de vosotr@s sabreís que el menú de GRUB está en /boot/grub/menu.lst (Sino es así, poner locate menu.lst) una vez tengamos localizado nuestro menu.lst deberemos editarlo.

gedit /boot/grub/menu.lst (En este caso he elejido Gedit pero podeis usar el que querais).

Nos apareceran las opciones que NO debemos tocar si no sabemos lo que estamos haciendo.
Tendremos que bajar (Scroll Down) hasta encontrarnos con una línea que diga

## ## End Default Options ##

Ahora deberíamos ir viendo líneas parecidas a esta:

title        Ubuntu x.xx.x, kernel 2.x.xx-xx-generic
root        (hd0,0)
kernel        /boot/vmlinuz-2.x.xx-xx-generic root=UUID=XXXXX
initrd        /boot/initrd.img-2.x.xx-xx-generic
quiet

Ok, hasta aquí bien, imaginemos que quiero eliminar esa entrada (arriba) y que no aparezca cuando arranco el ordenador. ¿Cómo? simple, comentaremos las líneas necesarias así;

# title        Ubuntu xxxx, kernel 2.x.xx-xx-generic
# root        (hd0,0)
# kernel        /boot/vmlinuz-x.xx-xx-generic root=UUID=XXXXX
# initrd        /boot/initrd.img-2.x.xx-xx-generic
# quiet

Y si lo hemos hecho bien, al reiniciar no debería quedar rastro de el que hayamos comentado.
Espero que os haya ayudado este pequeño GowTo. Cualquier duda/problema, comentarmelo.

Dateando en la paqueteria de debian, encontre una aplicacion ReContraSuperArchi interesante...jeje, Les presento Windows Wireless Drivers (ndisgtk), y no es mas q lo mismo q decian en los foros, pero con la diferencia q es atravez de una interface de usuario, ademas la misma aplicacion se encarga de cargarlos al kernel... y toda la chicha de instalar un driver.

Bueno, les dateo loq hice, nada de otro mundo, recuerda q debemos tener el driver de la wifi(el de windows), mas q driver debemos tener el archivo ".conf", es decir, no vamos a windows y buscamos el archivo, o nos bajamos el driver de la wifi para windows. Yo utilice este metodo porq, mi wifi es una atheros 5112, y no pude encontrar un controlador libre, todos las formas eran aprovechando el driver privativo.

En fin ahy les va:

$su
#apt-get install ndisgtk

Listo! vamos sistema/administracion/Windows Wireless Drivers, o la terminal

#ndisgtk

Muy intutivo, solo agregamos elarchivo ".inf", y listo, Ya esta!.

Q emocion, ya tengo mi wifi instalada, ahora ya podre practicar seguridad...jeje, espero le ayude a mas de uno.

Saludos

De acuerdo a este hilo de discusiones en la lista de correo de >uvcvideo (USB Video Class Driver) del Kernel Linux, si todo sale según lo esperado, podemos esperar ver soporte para más de 100 tipos de webcams nuevas y dispositivos similares en el próximo Kernel 2.6.27. De acuerdo a la lista mencionada, el estándar UVC es requerido para obtener "certificación Windows Vista", así que los fabricantes de hardware deben incluirla. Entre los periféricos incluídos en esta categoría se encuentran además de webcams, "camcorders" digitales, conversores de video analógico y sintonizadores de televisión, entre otros.

La buena noticia es que esto significaría soporte automático para todos esos dispositivos, lo que representa a su vez casi todas las webcams incluídas en las computadoras portátiles modernas, y seguramente también las webcams USB más recientes.

Via: Viva Linux

Il 30 giugno Microsoft ha ritirato il suo vecchio sistema operativo dai vendor di Pc e Vista riparte dalle 140 milioni di copie vendute, senza più il rivale imbattibile. Non solo Windows: Microsoft lavora anche su Singularity, MinWin e Midori. Da oggi, come annunciato, chi compra un Pc trova solo sistemi equipaggiati con Windows Vista, e se vuole Xp deve acquistare un netbook (un mini
notebook) oppure sperare in un downgrade da Vista (versioni Ultimate e Business).

Come già spiegato, Xp non va proprio in pensione: il supporto tecnico completo scadrà solo nel 2009 e il rilascio di update di sicurezza finirà nel 2014, quando Xp compirà i 13 anni. Chi vorrà saltare Vista, come Intel nella sua azienda, potrà aspettare Windows 7, atteso per il 2010. La petizione Save Xp, che voleva salvare il vecchio sistema operativo di Microsoft, è arrivata al traguardo di 210,000 firme, tuttavia non ha commosso Microsoft, troppo impegnata a fare largo a Vista. Windows Vista infine riparte dalle 140 milioni di copie vendute, senza più il rivale imbattibile, quale è stato Xp: le milioni di copie vendute di Xp sembrano tantissime, ma non sono così tante in un mercato Pc a doppia cifra.
Intanto c'è chi dice che Microsoft abbia bisogno di aria fresca, invece che pensare solo a Windows: e a livello di ricerca, lavora su Singularity Os e su una derivazione, nome in codice Midori, oltre che sul kernel MinWin. Non c'è solo Windows: di Singularity Os sappiamo che è un sistema operativo sperimentale, che non sarà l'evoluzione di Vista. Singularity Os assicura isolamento dei processi di sistema, è scritto in codice guidato e punta a realizzare un sistema operativo dalla massima affidabilità. Ma di più, per ora non abbiamo notizia: tuttavia Microsoft sta sviluppando altri approcci al sistema operativo e potrebbe anche riguardare indietro, come Apple ha saputo rinnovarsi in pochi anni con Mac Os X. ]]> http://inforux.wordpress.com/?p=218 Tue, 01 Jul 2008 02:08:43 +0000 inforux http://inforux.wordpress.com/?p=218 Como ustedes sabran ADOBE, hasta el momento aun no ha implementado pligin de flash para maquinas de 64 bits, y como linuxeros q somos, casi siempre tenemos la solucion ... jeje

Por eso, despues de goglear un buen ratoooooo... mostrare como logre instalarlo en mi iceweasel, (supongo q sera lo mismo para fierefox...en fin, es cuestion de intentarlo).

La idea, es utilizar lo implementado para 32 bits... creo q eso es obvio..., pero comohacerlo? ps, ya lo hicieron, resulta q los desarroladores de debian (debian sid), ya lo tienen, asi q q esperamos... jejeje

1.- Editamos nuestro /etc/apt/sources.list y agregamos MOMENTANEAMENTE este repositorio.

• # deb http://ftp.us.debian.org/debian/ sid main contrib

# nano /etc/apt/sources.list

Una ves agregado, actualizamos e instalamos el bendito plugin, cono un simple apt.

#apt-get update
#apt-get install flashplugin-nonfree nspluginwrapper

Reiniciamos nuestro navegador, y entramos youtube(por ejmplo), y ya podremos ver los videos.... facil no?

Bueno, no olvidar comentar o eliminar el repositorio agregado.

Saludos.

Inicialmente debes instalar los driver de tu tarjeta grafica nvidia (en un post anterior mencione como Instalar driver nvidia), para loq tienen Ati, inforux, no da soporte(jeje sorry, no he tenido experiencia hasta ahora con ninguna) pero puedo darles algunos hilos realizados por Debian Total y por esDebian.

Ahora q ya tenemos instalado nuestros drivers, tenemos q comprobar q tenemos acelarion grafica ejecutamos un par de comenados, el primero " glxinfo | grep direct" , escribe esto en la terminal:

$su
#glxinfo | grep direct

Nos devolvera 2 opciones "SI" y "NO" (debe salirnos obviamente "SI", siempre y cuando hayamos instalado correctamente nustro driver. Luego nos aseguramos cuantos fpt nos muestra glxgears, escribe:

#glxgears

Aparecera, 3 ruedas rodando, esperar y mirar en la velocidad de fps, creo q a partir de 600-700 fps ya es aceptable.

Despues de haber comprobado algunos requisitos, pasamos a editar nuestro archivo sources.list,

#nano /etc/apt/sources.list

agregamos los repositoios de trevi;o.

Aqui,, elige tu repositorio, segun la version q tengas.

• Debian estable (debian etch)

#Repositorio estable:

deb http://download.tuxfamily.org/shames/debian-etch/desktopfx/stable/ ./

• Debian testing (debian lenny):

#Repositorio inestable
deb http://download.tuxfamily.org/shames/debian-lenny/desktopfx/unstable/ ./

#Repositorio estable
deb http://download.tuxfamily.org/shames/debian-lenny/desktopfx/stable/ ./

• Debian inestable(debian sid):

#Repositorio inestable
deb http://download.tuxfamily.org/shames/debian-sid/desktopfx/unstable/ ./

#Repositorio estable
deb http://download.tuxfamily.org/shames/debian-sid/desktopfx/stable/ ./

ojo Agrega solamente uno, en mi caso uso debian lenny, pero yo chico malo opte por los inestables de sid.....jeje como buena punta...jaja... y hasta no me ha dado ningun problema, pero si no quieren arriesgarse, mejro elige tu reposotorio correcto.

bien, ahora, como trevi;o firmo las fuentes, hay q bajar la llave, para luego actualizar

#wget http://download.tuxfamily.org/shames/A42A6CF5.gpg -O- | apt-key add -- 
#apt-get update
#apt-get upgrade

Ahora ya pasamos a instalar el bendito compiz,

GNome:

#apt-get install compiz-fusion-gnome

KDE

#apt-get install compiz-fusion-kde

Cualquiere entorno grafico

#apt-get install compiz-fusion-all

Bien ahy ya esta instalado,

Para ejecutarlo vamos a nuestra terminal y escribimos:

Debian lenny && sid:

#fusion-icon

Debian etch:

#compiz --replace

Aqui la muestra:

Bueno, espero, le sirva a mas de uno.

Saludos

Download

Download

Download

-- Nids de resolución: scePowerGetCpuClockFrequency. Este es el mismo error que ocurrió en 3.80 M33-1, que no suceda de nuevo

-- Soluciones del recovery de los problemas que han aparecido en versión anterior (posición incorrecta de vuelta en cadena de otros idiomas Inglés, permite, los discapacitados y las cadenas no se traduce en el plug-in es ocultar pic0 + pic1 no puede ser cambiado, el idioma en flash1 archivo no estaba trabajando ..

-- Arreglos de la traducción del recovery en Español.

Tutorial instalación parche:(yo no me hago responsable de un brickeo o de algo por el estilo debido a su mala instalación):

1. Nos descargamos el parche que se encuantra más abajo.

2. Después de descargar copias el contenido del rar a tu memory stick.

3. Vas al menu juegos y desde hay haces funcionar la aplicacion del parche.

4. Ya tendrás tu psp con el parche.

Si quieres tener el parche pincha aqui.