--- In mygentoo@yahoogroups.com, "Mohammad Marjan Al-Jeffry"
<linuxlah@...> wrote:
>
> the answer regarding your stage1 and stage2 questions..
> http://www.gentoo.org/doc/en/faq.xml#stage12
>


this should be precise:
http://www.gentoo.org/news/en/gwn/20051128-newsletter.xml
http://thread.gmane.org/gmane.linux.gentoo.devel/33245

--------BEGIN SNIPPET-----------

"We have received *numerous* complaints from users about the decision to
remove stage 1 and 2 from the installation documentation.  I realize it's
still available if users are willing to dig for it, but not all users do.

In my years of monitoring www <at> gentoo.org, we've received the most
complaints about this decision than any other single decision.  Is there a
way we can re-introduce the stages into the installation documentation,
perhaps with gigantic warnings saying, "for advanced users only" or
"use at
your own risk"?

--kurt"

--------END OF SNIPPET-----------

hi.

aku baru try install gentoo kat machine aku last few week.. tapi
memandangkan aku guna Pentium III,dan mula hilang sabar aku deinstall
dengan FC 6 :D


Ada beberapa perkembangan  aku tengok:

1-Gentoo ada Summer Code macam Freebsd-ada mentor mentee
2-Gentoo encourage stage 3 installation (kenapa-adakah stage 1 & 2
akan dilupuskan sebab takde sebab untuk diteruskan?)

haaaa???


--- In mygentoo@yahoogroups.com, "md_najmi" <md_najmi@...> wrote:
>
> http://tech.groups.yahoo.com/group/mypenguin99/message/15346
>
> testing testing
>

http://tech.groups.yahoo.com/group/mypenguin99/message/15346

testing testing

Baru release, dated semalam 10/10/2006.. br download
PDF format dia..

http://us3.samba.org/samba/docs/

PDF leh download sini ( dalam 900 pages gak )

http://us3.samba.org/samba/docs/Samba3-HOWTO.pdf
http://us3.samba.org/samba/docs/Samba3-ByExample.pdf

but sesapa byk duit leh la beli ehehehe..

previously last year my frens kasik link PDF buku abt
Postfix.. mmg best giler dan powerful sgt2.. TQ to
him...

-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=ZnJvc3RfbHVjaWZlcjk3Mzg%3D

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Baru release, dated semalam 10/10/2006.. br download
PDF format dia..

http://us3.samba.org/samba/docs/


PDF leh download sini ( dalam 900 pages gak )

http://us3.samba.org/samba/docs/Samba3-HOWTO.pdf
http://us3.samba.org/samba/docs/Samba3-ByExample.pdf

but sesapa byk duit leh la beli ehehehe..

previously last year my frens kasik link PDF buku abt
Postfix.. mmg best giler dan powerful sgt2.. TQ to
him...



-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=ZnJvc3RfbHVjaWZlcjk3Mzg%3D

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

selamat juga kepada semua penganut2 Islam.. moga lebih
ceria dan lebih bermakna kali ini :)



--- md_najmi <najmi.zabidi@...> wrote:

> assalamualaikum/salah sejahtera.
>
> selamat menyambut ramadhan 1427H.
>
> moga ramadhan penuh maghfirah wa rahmah.
>
>
>
>
>
>


-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=ZnJvc3RfbHVjaWZlcjk3Mzg%3D

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

I wish someone will sponsor me a laptop with a powerful graphic card for me to try this out....:(

On 9/22/06, Ahmad Arafat < trunasuci_74@yahoo.com> wrote:

Yups..
think so.. during last PCFAIR on OSS booth.. run on SLED (Suse Linux
Enterprise Desktop 10 ) TQ to KenMing for showing me how to play and
rotate the display.. lots of people been impressed!!!

--- In mygentoo@yahoogroups.com, "Mohammad Jeffry" <linuxlah@...>
wrote:
>
> some ppl said XGL is hot nowdays in GNU/Linux world. Any early
testers here?
> Some vid of XGL capabilities
> http://www.youtube.com/watch?v=uTm2nl0XuEg
>
> --
> And whoever does an atom's weight of evil will see it.
>

--
"This visage, no mere veneer of vanity, is it vestige of the vox populi, now vacant, vanished, as the once vital voice of the verisimilitude now venerates what they once vilified. However, this valorous visitation of a by-gone vexation, stands vivified, and has vowed to vanquish these venal and virulent vermin vanguarding vice and vouchsafing the violently vicious and voracious violation of volition. The only verdict is vengeance; a vendetta, held as a votive, not in vain, for the value and veracity of such shall one day vindicate the vigilant and the virtuous. Verily, this vichyssoise of verbiage veers most verbose vis-à-vis an introduction, and so it is my very good honor to meet you and you may call me V.", V for Vendetta

Yups..
think so.. during last PCFAIR on OSS booth.. run on SLED (Suse Linux
Enterprise Desktop 10 ) TQ to KenMing for showing me how to play and
rotate the display.. lots of people been impressed!!!




--- In mygentoo@yahoogroups.com, "Mohammad Jeffry" <linuxlah@...>
wrote:
>
> some ppl said XGL is hot nowdays in GNU/Linux world. Any early
testers here?
> Some vid of XGL capabilities
> http://www.youtube.com/watch?v=uTm2nl0XuEg
>
> --
> And whoever does an atom's weight of evil will see it.
>

Cluster Programming: You Can't Always Get What You
Want

Written by Douglas Eadline
Tuesday, 19 September 2006


Page 1 of 2

But it does not stop me from asking

Fifteen years ago I wrote a short article in a now
defunct parallel computing magazine (Parallelogram)
entitled "How Will You Program 1000 Processors?" Back
then it was a good question that had no easy answer.
Today, it is still a good question that still has no
easy answer. Except now it seems a bit more urgent as
we step into the "mulit-core" era. Indeed, when I
originally wrote the article, using 1000 processors
was a far off, but real possibility. Today, 1000
processors are a reality for many practitioners of
HPC. As dual cores hit the server rooms, effectively
doubling the processor counts, many more people will
be joining the 1000P club very soon.

So let's get adventurous and ask, "How will you
program 10,000 processors?" As I realized fifteen
years ago, such a question may never really have a
complete answer. In the history of computers, no one
has ever answered the question to my liking -- even
when considering ten processors. Of course there are
plenty of methods and ideas like threads, messages,
barrier synchronization, etc., but when I have to
think more about the computer than about my problem,
something is wrong.

Having spent many a night trying to program parallel
computers (the most recent incarnation being clusters)
I have come up with a list of qualities that I want in
a parallel programming language. Since I am wish for
the moon, I may be asking for the impossible, but I
believe some of the features I describe below are
going to be necessary before using large number of
processors will become feasible for the unwashed
masses of potential HPC users.
Failure Is an Option
It is said, that the Buddha's last words were "decay
is inherent in all complex/component things." And,
Buddha was not even a system administrator. Clusters
are complex/component things. The bigger the cluster,
the more things that can decay. A program that
routinely uses over 1000 processors will experience
component failures at some point. As an hypothetical
example, if you have 1000 cluster nodes with a MTBF
(Mean Time Between Failure) of 10,000 hours (1.1
years) that means you can expect one node to fail
every ten hours. Given that the MTBF is fixed for
most computer hardware, using more and more processors
for your program ultimately becomes a losing
proposition.

In the future, I expect clusters to have constant (and
expected) failures. Furthermore, the cost to increase
the MTBF will probably be prohibitive and adapting to
failure will be an easier solution.

I then have to ask, "How the heck do write a program
for hardware you know is going to fail at some point?"
The answer is quite simple, the program will have to
tolerate hardware failures. In other words software
must become fault tolerant. And, here is the important
part, I the programmer should not have write this into
my program.
Dynamic Scalability
One way to make a program fault tolerant is to make it
dynamically scalable. That is, it can change the
number of processors it is using on the fly. Adding
fault tolerance means redoing work so some mechanism
is will be needed to dynamically assign processors.
Dynamic scalability is therefore, the next thing I
want in my program. The idea is quite simple, I want
one program that can run on 10,000 processors as well
as one processor. Of course, large problem sizes may
not be feasible on one processor. After all, if a
large problem requires 10,000 processors for an hour
it would take 1 processor 10, hours (assuming their
was enough memory). I should, however, be able to run
a small data set on one processor and then scale the
same binary up to a maximal number of processors for
that given problem size (and everything in between).

For example, if I should be able to develop a program
on my laptop and move the same binary over to a
sixteen processor cluster and run it without any
modification. If the cluster is running other programs
at the same time and there are only four idle
processors, then my program should start using these
four. As other processors become available it should
grow only to the point that adding more processors
does not help performance. At a later point in time,
if I want to run my program with a larger problem size
on 1000 processors, I should be able able to run the
same program.
No More Standing in Line
Because my program is now dynamically scalable, I
assume yours is as well. In this case our programs
should be able to co-operate with one another. If we
both have a program to run at the same time we should
share resources optimally. In many cases, the need to
schedule or queue jobs will not be necessary because
the programs will manage themselves. My program will
constantly negotiate with the other running programs
to get the best set of cluster resources. For
instance, my program might negotiate to wait while
others run, if it can get exclusive access to 100
processors for one hour. I don't care how the programs
do it, I just want them to behave this way and I don't
want to have to write such behavior into my program.

Additionally, as part of this dynamic scheme there
should be no central point of control. Programs should
behave independently and not have to rely on a single
resource. Indeed, within the programs themselves
subparts should be as autonomous as possible.
Centrally managing sixteen processors seems
reasonable, managing sixteen hundred and having some
time to do computation is a real challenge.
And then Some
Finally, I want an expressive language that is free of
any artifacts due to the underlying hardware. I want
to be as close to the application I am coding as
possible. Thinking in "my problem space" is where I
want to live. Concerning myself with memory
management, numbers of processors, and other such
details takes me away from my problem domain. In
short, that is my wish list; fault tolerant,
dynamically scalable, co-operative, and expressive. A
simple wish, but a tall order. Realizing that I seldom
get what I want, I have set my expectations high so
maybe, just maybe, I'll get what I need. How are we
going to get to this software nirvana? I thought you
would never ask. I have some ideas, but first, lets
address a few issues that always seem to come up when
I talk about this topic.
Prev Page - Next Page >>

Last Updated ( Tuesday, 19 September 2006 )

What about MPI?
Let me be clear. MPI (Message Passing Interface), and
PVM (Parallel Virtual Machine) for that matter, are
wonderful ideas. They have allowed me and countless
others to use collections of processors to achieve
great things. Rest assured message passing will not be
eclipsed by a new "programming" technology any time
soon. Indeed, it will in all likelihood be at the core
of most parallel applications in the future because
you cannot have parallel computing without
communication. As important as MPI is to the HPC
world, it does represent a barrier to the domain
expert. That is, programming in MPI is too much of an
investment for Joe Sixpack programmer. It requires not
only code changes, testing and debugging are harder,
and possible major re-writes may be necessary. For
those cheering on the sidelines, threads and OpenMP
are in the same boat. Sure the results can be
impressive, but complexity is the cost one pays for
working at this level.

Even if we manage to produce an army of MPI
programmers, there is another more subtle issue that
must be addressed. As written, most parallel programs
cannot provide a guarantee of efficient execution on
every computer. There is no assurance that when I
rebuild my MPI/Pthreads/OpenMP program on a different
computer it will run optimally. A discussion of this
topic is beyond the scope of this column, but let me
just say, that each cluster or SMP machine has a
unique ratio of computation to communication. This
ratio determines efficiency and should be considered
when making decisions about parallelization. For some
applications like rendering, this ratio makes little
difference, in others it can make a huge difference in
performance and determine the way you slice and dice
your code. unfortunately, your slicing and dicing may
work well on one system, but there is no guarantee it
will work well on all systems.

MPI has often been called the machine code for
parallel computers. I would have to agree. It is
portable, powerful, and unfortunately, in my opinion,
too close to the wires for everyday programming. In my
parallel computing utopia, MPI and other such methods
are as hidden as register loads are in a bash script.
Abstract Art
Climbing above the MPI layer will not come without a
cost. Just as there is loss of possible performance
when going from assembly language to C, there will be
a loss of efficiency when programming without explicit
messages. The term often used is a "higher abstraction
level". The reasons high level languages are so
popular is because they provide a high level of
abstraction above the hardware. Programmers move
closer to their application and farther away from the
the computer.

In my long forgotten article, I made the case that in
the early days of computing there was a huge debate
concerning the use of a new language, called FORTRAN,
instead of assembly language (machine code). Yes, in
those dark early days, there was no Perl or Python and
the new FORmula TRANslation language was a
breakthrough idea because it abstracted away some of
the machine and let non-programmers like scientists
easily program formulas. The argument went something
like this:

Assembly Code Wonk: "If I use FORTRAN instead of
assembly language, I loose quite a bit of performance,
so I will stick with loading my registers thank you."

FORTRAN Wonk: "Yes, but when the new computer comes
next year, I will not have to rewrite my program in a
new machine code. And, besides, the new FORTRAN II
compiler will optimize my code."

Assembly Code Wonk: "Only time will tell us the best
solution. By the way, is that new pencil thin neck tie
you are wearing with a new white short sleeve shirt?"


Time did tell us what happened. FORTRAN (or now
written as Fortran) allowed many more people to write
code. It also allowed code to spread quicker as new
machines came on line. Suddenly there was, and still
is by the way, vast amounts of Fortran programs doing
all kinds of useful things.

If we are going to open up parallel computing to the
domain experts we need to introduce a new abstraction
level in which to express their problem. My wish is
that once the problem is described (or declared) in a
new language, compilers and run-time agents can
deliver the features I described above.
Cliff Hanging
Now that I have you on the edge of your seat, I need
to stop for now. Not to worry though, next time I will
provide some real alternatives to MPI and even suggest
some wild ideas. And maybe if we start thinking and
talking about these issues and ideas, we may find an
answer to my question. I am optimistic, after all
Buddha also said, "What we think, we become."

This article was originally published in Linux
Magazine. It has been updated and formatted for the
web. If you want to read more about HPC clusters and
Linux you may wish to visit Linux Magazine.

Douglas Eadline is editor of ClusterMonkey and does
wear a pencil thin necktie, although there is one in
his closet somewhere.



-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=ZnJvc3RfbHVjaWZlcjk3Mzg%3D

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

http://dot.kde.org/1158661315/

KDE Thanks Rob Levin

Posted by Jes Hall on Tuesday 19/Sep/2006, @03:21
from the we'll-miss-you dept.
We knew him as lilo. He was the founder of the
Freenode IRC network, a place where many open source
projects established a real-time meeting ground.
Freenode is where we work, play, and share. It is
where many a small idea has grown into a large
project. It is where we are all enriched by the
experience and diversity of a group of people from
many cultures who all have in common a love of open
source.

KDE has benefited greatly from this virtual
meeting-hall. We have dozens of channels where ideas
are discussed, contributors are mentored and users are
supported. Many more recent KDE sub-projects had their
start on Freenode and still flourish there. lilo was a
common fixture in most of these channels, personally
dealing with issues like harassment or spamming,
making Freenode a safer environment for all.

What KDE owes to Freenode cannot be expressed easily
or lightly.

Thank you Rob Levin. You will be sorely missed.



-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=ZnJvc3RfbHVjaWZlcjk3Mzg%3D

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Nice article.. nuthing to related with "mygentoo"
group :)



http://www.linux.com/article.pl?sid=06/09/12/213246



-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=ZnJvc3RfbHVjaWZlcjk3Mzg%3D

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

http://www.desktoplinux.com/news/NS3109588956.html

Sep. 18, 2006

Tollef Fog Heen of the Ubuntu development team on
Sept. 16 announced the third alpha release (codenamed
"Knot CD") of Ubuntu 6.10. The new Ubuntu version
features a 2.6.17 Linux kernel and comes with the
GNOME desktop environment.

"The primary changes from Knot 2 have been finalizing
of feature goals and bugfixing," Heen wrote in the
release announcement. "Common to all variants, we have
changed the init system from the venerable sysvinit to
upstart which is an event-driven init script system.
In addition, all derivatives have new artwork, both
for usplash as well as for login managers and default
backgrounds."

In Ubuntu, GNOME has been updated to 2.16.0, Heen
said. In Kubuntu, Konversation 1.0 has been added. For
Xubuntu, the XFce core applications have been upgraded
to 4.4 release candidate 1, he added.

Standard features in Ubuntu, as listed by the team,
include:
OpenOffice.org 2.03
GAIM 2.0 messenger
GIMP 2.2.13 graphics editor
MySQL 5.0.22 database
"Desktop" and "Alternate" CD images (668MB) for three
architectures can be downloaded from the project's
main download server here.

CD images for Kubuntu, Edubuntu, and Xubuntu are also
available.

Screen shots can be viewed on the Ubuntu site and at OSDir.com.

-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=ZnJvc3RfbHVjaWZlcjk3Mzg%3D

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

check it out!


http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=193001498



EE Times Europe
(09/18/2006 6:55 AM EDT)

LONDON — Simply RISC, a team of engineers formerly
with STMicroelectronics NV, has revealed plans to
provide design services around its offering of a free
64-bit processor core. Simply RISC's release of the
OpenSPARC T1-based processor is intended to show
potential customers the team's capability as well as
providing a building block for future system-on-chip
and network-on-chip design work.

"Simply RISC is a design center. We haven't plans to
sell chips. What we can offer is our time and our
expertise," said Fabrizio Fazzino, who described
himself as chief system architect, in an email to EE
Times. Fazzino went on to say that companies can come
to Simply RISC to develop SoC and NoC integrated
circuits using either ASIC or field-programmable gate
array implementation. "The IP cores we develop are
fully released under the GPL, unless a customer asks
us to do otherwise," Fazzino added referring to the
GNU General Public License.

The S1 is a "cut-down" version of the OpenSPARC T1
multiprocessor, previously codenamed Niagara, which
targets embedded devices such as PDAs, set-top boxes
and digital cameras. The S1 comprises a single
four-thread processor core, rather than the eight
four-thread cores present on the T1. However, it is
still early days for Simply RISC, which is seeking
funding and comprises just five engineers at present.

Fazzino himself worked for ST in Catania, Sicily,
between 1998 and 2001 in the group which developed the
ST20 and ST40 processors. The group was formed as a
result of the acquisition, in 1989 of Inmos Ltd., a
U.K. semiconductor company based in Bristol, England,
and well-known for having developed a parallel
processor known as the transputer.

Fazzino decided to leave ST in 2001 to become a
free-lance chip designer, but with the idea to found a
company with some former colleagues. "We are all
Italian and we work in Italy. However, we are
receiving many contacts from all over the world from
people who want to help, especially from India and
China," said Fazzino. "I would like to include also
them in the head count and I probably will in the
future."

Fazzino said that the original intention was for
Simply RISC to develop its own simple RISC processor
targeted towards small embedded devices. However, the
company changed tack and opted to develop an
OpenSPARC-derivative processor.
Page 2: Following in Gaisler's footsteps

Page 1 2



-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=ZnJvc3RfbHVjaWZlcjk3Mzg%3D

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

awal2 pagi aku dah dpt email from the FreeBSD team..
thanx to them pasal rajin concern hal2 security patch
nih.. bulan sep nih saja mau ada 3-4 security patch yg
agak kritikal gak ( bind, openssl ) dan sebelum tu ppp
dsb..

anyway nih le mendanya.. gud luck dan selamat
"menampal" server2 anda!



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

=============================================================================
FreeBSD-SA-06:21.gzip
      Security Advisory

     The FreeBSD Project

Topic:          Multiple vulnerabilities in gzip

Category:       contrib
Module:         gzip
Announced:      2006-09-19
Credits:        Tavis Ormandy, Google Security Team
Affects:        All FreeBSD releases.
Corrected:      2006-09-19 14:02:30 UTC (RELENG_6,
6.2-PRERELEASE)
                  2006-09-19 14:03:26 UTC (RELENG_6_1,
6.1-RELEASE-p7)
                  2006-09-19 14:04:13 UTC (RELENG_6_0,
6.0-RELEASE-p12)
                  2006-09-19 14:06:21 UTC (RELENG_5,
5.5-STABLE)
                  2006-09-19 14:07:13 UTC (RELENG_5_5,
5.5-RELEASE-p5)
                  2006-09-19 14:08:10 UTC (RELENG_5_4,
5.4-RELEASE-p19)
                  2006-09-19 14:09:09 UTC (RELENG_5_3,
5.3-RELEASE-p34)
                  2006-09-19 14:11:35 UTC (RELENG_4,
4.11-STABLE)
                  2006-09-19 14:13:53 UTC (RELENG_4_11,
4.11-RELEASE-p22)
CVE Name:       CVE-2006-4334, CVE-2006-4335,
CVE-2006-4336, CVE-2006-4337,
                  CVE-2006-4338

For general information regarding FreeBSD Security
Advisories,
including descriptions of the fields above, security
branches, and the
following sections, please visit
<URL:http://security.FreeBSD.org/>.

I.   Background

gzip is a file compression utility.

II.  Problem Description

Multiple programming errors have been found in gzip
which can be
triggered when gzip is decompressing files.  These
errors include
insufficient bounds checks in buffer use, a NULL
pointer dereference,
and a potential infinite loop.

III. Impact

The insufficient bounds checks in buffer use can cause
gzip to crash,
and may permit the execution of arbitrary code.  The
NULL pointer
deference can cause gzip to crash.  The infinite loop
can cause a
Denial-of-Service situation where gzip uses all
available CPU time.

IV.  Workaround

No workaround is available.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to 4-STABLE,
5-STABLE, or 6-STABLE,
or to the RELENG_6_1, RELENG_6_0, RELENG_5_5,
RELENG_5_4, RELENG_5_3,
or RELENG_4_11 security branch dated after the
correction date.

2) To patch your present system:

The following patches have been verified to apply to
FreeBSD 4.11, 5.3,
5.4, 5.5, 6.0, and 6.1 systems.

a) Download the relevant patch from the location
below, and verify the
detached PGP signature using your PGP utility.

# fetch
http://security.FreeBSD.org/patches/SA-06:21/gzip.patch
# fetch
http://security.FreeBSD.org/patches/SA-06:21/gzip.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/gnu/usr.bin/gzip
# make obj && make depend && make && make install

VI.  Correction details

The following list contains the revision numbers of
each file that was
corrected in FreeBSD.

Branch
           Revision
    Path
-
-------------------------------------------------------------------------
RELENG_4
    src/gnu/usr.bin/gzip/gzip.h
            1.3.12.1
    src/gnu/usr.bin/gzip/inflate.c
             1.8.2.2
    src/gnu/usr.bin/gzip/unlzh.c
             1.5.2.1
    src/gnu/usr.bin/gzip/unpack.c
             1.6.2.1
RELENG_4_11
    src/UPDATING
      1.73.2.91.2.23
    src/sys/conf/newvers.sh
      1.44.2.39.2.26
    src/gnu/usr.bin/gzip/gzip.h
            1.3.36.1
    src/gnu/usr.bin/gzip/inflate.c
         1.8.2.1.2.1
    src/gnu/usr.bin/gzip/unlzh.c
            1.5.30.1
    src/gnu/usr.bin/gzip/unpack.c
            1.6.30.1
RELENG_5
    src/gnu/usr.bin/gzip/gzip.h
             1.4.2.1
    src/gnu/usr.bin/gzip/inflate.c
             1.9.2.1
    src/gnu/usr.bin/gzip/unlzh.c
            1.5.26.1
    src/gnu/usr.bin/gzip/unpack.c
            1.6.26.1
RELENG_5_5
    src/UPDATING
      1.342.2.35.2.5
    src/sys/conf/newvers.sh
       1.62.2.21.2.7
    src/gnu/usr.bin/gzip/gzip.h
            1.4.14.1
    src/gnu/usr.bin/gzip/inflate.c
            1.9.14.1
    src/gnu/usr.bin/gzip/unlzh.c
            1.5.40.1
    src/gnu/usr.bin/gzip/unpack.c
            1.6.40.1
RELENG_5_4
    src/UPDATING
     1.342.2.24.2.28
    src/sys/conf/newvers.sh
      1.62.2.18.2.24
    src/gnu/usr.bin/gzip/gzip.h
             1.4.6.1
    src/gnu/usr.bin/gzip/inflate.c
             1.9.6.1
    src/gnu/usr.bin/gzip/unlzh.c
            1.5.32.1
    src/gnu/usr.bin/gzip/unpack.c
            1.6.32.1
RELENG_5_3
    src/UPDATING
     1.342.2.13.2.37
    src/sys/conf/newvers.sh
      1.62.2.15.2.39
    src/gnu/usr.bin/gzip/gzip.h
             1.4.4.1
    src/gnu/usr.bin/gzip/inflate.c
             1.9.4.1
    src/gnu/usr.bin/gzip/unlzh.c
            1.5.28.1
    src/gnu/usr.bin/gzip/unpack.c
            1.6.28.1
RELENG_6
    src/gnu/usr.bin/gzip/gzip.h
             1.4.8.1
    src/gnu/usr.bin/gzip/inflate.c
             1.9.8.1
    src/gnu/usr.bin/gzip/unlzh.c
            1.5.34.1
    src/gnu/usr.bin/gzip/unpack.c
            1.6.34.1
RELENG_6_1
    src/UPDATING
      1.416.2.22.2.9
    src/sys/conf/newvers.sh
       1.69.2.11.2.9
    src/gnu/usr.bin/gzip/gzip.h
            1.4.12.1
    src/gnu/usr.bin/gzip/inflate.c
            1.9.12.1
    src/gnu/usr.bin/gzip/unlzh.c
            1.5.38.1
    src/gnu/usr.bin/gzip/unpack.c
            1.6.38.1
RELENG_6_0
    src/UPDATING
      1.416.2.3.2.17
    src/sys/conf/newvers.sh
       1.69.2.8.2.13
    src/gnu/usr.bin/gzip/gzip.h
            1.4.10.1
    src/gnu/usr.bin/gzip/inflate.c
            1.9.10.1
    src/gnu/usr.bin/gzip/unlzh.c
            1.5.36.1
    src/gnu/usr.bin/gzip/unpack.c
            1.6.36.1
-
-------------------------------------------------------------------------

VII. References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4334
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4335
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4336
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4337
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4338

The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-06:21.gzip.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFFD/6bFdaIBMps37IRAgMGAJ9f7rYLs32ZEAKWwhcPqAWrp6fNwACgg2Wj
fw3izMEcpupfqNkkQKizV5g=
=xYxa
-----END PGP SIGNATURE-----

-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=ZnJvc3RfbHVjaWZlcjk3Mzg%3D

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

--- In mypenguin99@yahoogroups.com, "Ahmad Arafat" <trunasuci_74@...>
wrote:

Baru keluar arinih.. jom cepat patch your server/box!

=============================================================================
FreeBSD-SA-06:20.bind                                       Security
Advisory
                                                            The
FreeBSD Project

Topic:          Denial of Service in named(8)

Category:       contrib
Module:         bind
Announced:      2006-09-06
Credits:        The Measurement Factory
Affects:        FreeBSD 5.3 and later.
Corrected:      2006-09-06 21:18:26 UTC (RELENG_6, 6.1-STABLE)
                  2006-09-06 21:19:21 UTC (RELENG_6_1, 6.1-RELEASE-p6)
                  2006-09-06 21:20:08 UTC (RELENG_6_0, 6.0-RELEASE-p11)
                  2006-09-06 21:20:54 UTC (RELENG_5, 5.5-STABLE)
                  2006-09-06 21:21:50 UTC (RELENG_5_5, 5.5-RELEASE-p4)
                  2006-09-06 21:22:39 UTC (RELENG_5_4, 5.4-RELEASE-p18)
                  2006-09-06 21:23:16 UTC (RELENG_5_3, 5.3-RELEASE-p33)
CVE Name:       CVE-2006-4095, CVE-2006-4096

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://security.freebsd.org/>.

I.   Background

BIND 9 is an implementation of the Domain Name System (DNS) protocols.
The named(8) daemon is an Internet domain name server.  DNS Security
Extensions (DNSSEC) are additional protocol options that add
authentication and integrity to the DNS protocols.

II.  Problem Description

For a recursive DNS server, a remote attacker sending enough recursive
queries for the replies to arrive after all the interested clients
have left the recursion queue will trigger an INSIST failure in the
named(8) daemon.  Also for a a recursive DNS server, an assertion
failure can occour when processing a query whose reply will contain
more than one SIG(covered) RRset.

For an authoritative DNS server serving a RFC 2535 DNSSEC zone which
is queried for the SIG records where there are multiple SIG(covered)
RRsets (e.g. a zone apex), named(8) will trigger an assertion failure
when it tries to construct the response.

III. Impact

An attacker who can perform recursive lookups on a DNS server and is
able
to send a sufficiently large number of recursive queries, or is able
to
get the DNS server to return more than one SIG(covered) RRsets can
stop
the functionality of the DNS service.

An attacker querying an authoritative DNS server serving a RFC 2535
DNSSEC zone may be able to crash the DNS server.

All of the above issues will result in a Denial of Service situation.

IV.  Workaround

A possible workaround is to only allow trusted clients to perform
recursive
queries.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to 5-STABLE, or 6-STABLE, or to the
RELENG_6_1, RELENG_6_0, RELENG_5_5, RELENG_5_4, or RELENG_5_3 security
branch dated after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 5.3, 5.4,
5.5, 6.0, and 6.1 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch http://security.FreeBSD.org/patches/SA-06:20/bind.patch
# fetch http://security.FreeBSD.org/patches/SA-06:20/bind.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/bind
# make obj && make depend && make && make install
# cd /usr/src/usr.sbin/named
# make obj && make depend && make && make install

c) Restart the named application:

# /etc/rc.d/named restart

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Branch
Revision
    Path
- --------------------------------------------------------------------
-----
RELENG_5
    src/contrib/bind9/bin/named/query.c
1.1.1.1.2.3
    src/contrib/bind9/lib/dns/resolver.c
1.1.1.1.2.5
RELENG_5_5
    src/UPDATING
1.342.2.35.2.4
    src/sys/conf/newvers.sh
1.62.2.21.2.6
    src/contrib/bind9/bin/named/query.c
1.1.1.1.2.2.2.1
    src/contrib/bind9/lib/dns/resolver.c
1.1.1.1.2.4.2.1
RELENG_5_4
    src/UPDATING
1.342.2.24.2.27
    src/sys/conf/newvers.sh
1.62.2.18.2.23
    src/contrib/bind9/bin/named/query.c
1.1.1.1.2.1.4.1
    src/contrib/bind9/lib/dns/resolver.c
1.1.1.1.2.2.2.1
RELENG_5_3
    src/UPDATING
1.342.2.13.2.36
    src/sys/conf/newvers.sh
1.62.2.15.2.38
    src/contrib/bind9/bin/named/query.c
1.1.1.1.2.1.2.1
    src/contrib/bind9/lib/dns/resolver.c
1.1.1.1.2.1.2.1
RELENG_6
    src/contrib/bind9/bin/named/query.c
1.1.1.1.4.2
    src/contrib/bind9/lib/dns/resolver.c
1.1.1.2.2.3
RELENG_6_1
    src/UPDATING
1.416.2.22.2.8
    src/sys/conf/newvers.sh
1.69.2.11.2.8
    src/contrib/bind9/bin/named/query.c
1.1.1.1.4.1.2.1
    src/contrib/bind9/lib/dns/resolver.c
1.1.1.2.2.2.2.1
RELENG_6_0
    src/UPDATING
1.416.2.3.2.16
    src/sys/conf/newvers.sh
1.69.2.8.2.12
    src/contrib/bind9/bin/named/query.c
1.1.1.1.6.1
    src/contrib/bind9/lib/dns/resolver.c
1.1.1.2.2.1.2.1
- --------------------------------------------------------------------
-----

VII. References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4095
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4096
http://www.kb.cert.org/vuls/id/697164
http://www.kb.cert.org/vuls/id/915404
http://www.niscc.gov.uk/niscc/docs/re-20060905-00590.pdf?lang=en

The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-06:20.bind.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFE/0NLFdaIBMps37IRApD/AKCczWj2UJ64iVlXWSLaN1BNA52nnQCgkvJY
XIxfELRi5H7taKVtMJFK2tU=
=4n+j
-----END PGP SIGNATURE-----













=============================================================================
FreeBSD-SA-06:19.openssl                                    Security
Advisory
                                                           The FreeBSD
Project

Topic:          Incorrect PKCS#1 v1.5 padding validation in crypto(3)

Category:       contrib
Module:         openssl
Announced:      2006-09-06
Affects:        All FreeBSD releases.
Corrected:      2006-09-06 21:18:26 UTC (RELENG_6, 6.1-STABLE)
                 2006-09-06 21:19:21 UTC (RELENG_6_1, 6.1-RELEASE-p6)
                 2006-09-06 21:20:08 UTC (RELENG_6_0, 6.0-RELEASE-p11)
                 2006-09-06 21:20:54 UTC (RELENG_5, 5.5-STABLE)
                 2006-09-06 21:21:50 UTC (RELENG_5_5, 5.5-RELEASE-p4)
                 2006-09-06 21:22:39 UTC (RELENG_5_4, 5.4-RELEASE-p18)
                 2006-09-06 21:23:16 UTC (RELENG_5_3, 5.3-RELEASE-p33)
                 2006-09-06 21:24:04 UTC (RELENG_4, 4.11-STABLE)
                 2006-09-06 21:24:54 UTC (RELENG_4_11, 4.11-RELEASE-
p21)
CVE Name:       CVE-2006-4339

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://security.freebsd.org/>.

I.   Background

FreeBSD includes software from the OpenSSL Project.  The OpenSSL
Project is
a collaborative effort to develop a robust, commercial-grade, full-
featured,
and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/
v3)
and Transport Layer Security (TLS v1) protocols as well as a full-
strength
general purpose cryptography library.

PKCS#1 v1.5 is a standard for "padding" data before performing a
cryptographic operation using the RSA algorithm.  PKCS#1 v1.5
signatures
are for example used in X.509 certificates.

RSA public keys may use a variety of public exponents, of which 3,
17, and
65537 are most common.  As a result of a number of known attacks,
most keys
generated recently use a public exponent of at least 65537.

II.  Problem Description

When verifying a PKCS#1 v1.5 signature, OpenSSL ignores any bytes
which
follow the cryptographic hash being signed.  In a valid signature
there
will be no such bytes.

III. Impact

OpenSSL will incorrectly report some invalid signatures as valid.
When
an RSA public exponent of 3 is used, or more generally when a small
public
exponent is used with a relatively large modulus (e.g., a public
exponent
of 17 with a 4096-bit modulus), an attacker can construct a signature
which
OpenSSL will accept as a valid PKCS#1 v1.5 signature.

IV.  Workaround

No workaround is available.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to 4-STABLE, 5-STABLE, or 6-STABLE,
or to the RELENG_6_1, RELENG_6_0, RELENG_5_5, RELENG_5_4, RELENG_5_3,
or RELENG_4_11 security branch dated after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 4.11,
5.3,
5.4, 5.5, 6.0, and 6.1 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch http://security.FreeBSD.org/patches/SA-06:19/openssl.patch
# fetch http://security.FreeBSD.org/patches/SA-06:19/openssl.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch

c) Recompile the operating system as described in
<URL: http://www.freebsd.org/handbook/makeworld.html> and reboot the
system.

NOTE: Any third-party applications, including those installed from the
FreeBSD ports collection, which are statically linked to libcrypto(3)
should be recompiled in order to use the corrected code.

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Branch
Revision
   Path
- --------------------------------------------------------------------
-----
RELENG_4
   src/crypto/openssl/crypto/rsa/rsa_sign.c
1.1.1.1.2.6
RELENG_4_11
   src/UPDATING
1.73.2.91.2.22
   src/sys/conf/newvers.sh
1.44.2.39.2.25
   src/crypto/openssl/crypto/rsa/rsa_sign.c
1.1.1.1.2.5.6.1
RELENG_5
   src/crypto/openssl/crypto/rsa/rsa_sign.c
1.1.1.6.4.1
RELENG_5_5
   src/UPDATING
1.342.2.35.2.4
   src/sys/conf/newvers.sh
1.62.2.21.2.6
   src/crypto/openssl/crypto/rsa/rsa_sign.c
1.1.1.6.16.1
RELENG_5_4
   src/UPDATING
1.342.2.24.2.27
   src/sys/conf/newvers.sh
1.62.2.18.2.23
   src/crypto/openssl/crypto/rsa/rsa_sign.c
1.1.1.6.8.1
RELENG_5_3
   src/UPDATING
1.342.2.13.2.36
   src/sys/conf/newvers.sh
1.62.2.15.2.38
   src/crypto/openssl/crypto/rsa/rsa_sign.c
1.1.1.6.6.1
RELENG_6
   src/crypto/openssl/crypto/rsa/rsa_sign.c
1.1.1.6.10.1
RELENG_6_1
   src/UPDATING
1.416.2.22.2.8
   src/sys/conf/newvers.sh
1.69.2.11.2.8
   src/crypto/openssl/crypto/rsa/rsa_sign.c
1.1.1.6.14.1
RELENG_6_0
   src/UPDATING
1.416.2.3.2.16
   src/sys/conf/newvers.sh
1.69.2.8.2.12
   src/crypto/openssl/crypto/rsa/rsa_sign.c
1.1.1.6.12.1
- --------------------------------------------------------------------
-----

VII. References

http://www.openssl.org/news/secadv_20060905.txt
http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4339

The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-06:19.openssl.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFE/0FzFdaIBMps37IRApq5AJ9LYe7MpHgG+fGWs9zNaFWrTd5mFQCgj5k8
0lBDO5lDb8jCB5vrjvfhyGY=
=ihRT
-----END PGP SIGNATURE-----

--- End forwarded message ---

aku rasa org yg maybe terlibat adalah en kedai
/bakhtiar ( Mr Zope/Plone ) :)..

mungkin boleh try tanya dia..




--- Mohammad Jeffry <linuxlah@...> wrote:

> yupe.. dia orang tukar tukar server.. hari dia orang
> pakai CentOS laks..
> cool!!!! Nanti bila dia org rotate balik gentoo aku
> screenshot one more time
> :D
>
> On 9/3/06, Mohammad Jeffry <linuxlah@...>
> wrote:
> >
> > argh crap fedora.. :D.. maybe they have multiple
> server???
> >
> >
> > On 9/3/06, yan <retroguy_8@...> wrote:
> > >
> > > dude... not sure if this is right...checkout the
> bottom of the page..
> > > you might want to sweep scan using nmap...no
> enuf time to do that as i'm at
> > > starbucks and its bloody cold in here.
> > >
> > >  http://www.bharian.com.my/images/
> > >
> > >
> > >
> > >
> > > *Mohammad Jeffry < linuxlah@...>* wrote:
> > >
> > >
> > >
>
http://marjan.blogsome.com/2006/09/03/berita-harian-online-uses-gentoo-linux/
> > >
> > > Can anybody with a friend in Berita Harian
> confirm this?
> > >
> > > --
> > > And whoever does an atom's weight of evil will
> see it.
> > >
> > >
> > > ------------------------------
> > > Do you Yahoo!?
> > > Everyone is raving about the all-new Yahoo!
>
Mail.<http://us.rd.yahoo.com/evt=42297/*http://advision.webevents.yahoo.com/mail\
beta>
> > >
> > >
> > >
> >
> >
> > --
> > And whoever does an atom's weight of evil will see
> it.
> >
>
>
>
> --
> And whoever does an atom's weight of evil will see
> it.
>


-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=ZnJvc3RfbHVjaWZlcjk3Mzg%3D

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

http://marjan.blogsome.com/2006/09/03/berita-harian-online-uses-gentoo-linux/

Can anybody with a friend in Berita Harian confirm this?

--
And whoever does an atom's weight of evil will see it.

yes surely still :)



--- Kn <cl8ner@...> wrote:

> Alive maaa.. I've done live cd.. gentoo based.. 31
> MB.. purely boot in RAM.. initially boot using
> cdrom..
>
>   and Completed my fiance final project....
>
>   heh
>
>   Now i'm thinking of putting gentoo inside BIOS
> chip..
>
>   hehehe
>
> Mohammad Jeffry <linuxlah@...> wrote:
>           I still, but not my gentoo linux os..
> attached is my current os due to office requirement
> and I don't have time for hobbist os anymore :p
>
>
>   On 8/2/06, md_najmi <md_najmi@...> wrote:
> hi,
>
> yoo hoo.
> anyone still survive here?
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
> --
> And whoever does an atom's weight of evil will see
> it.
>
>
>
>
> ---------------------------------
> How low will we go? Check out Yahoo! Messenger’s low
>  PC-to-Phone call rates.


-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=ZnJvc3RfbHVjaWZlcjk3Mzg%3D

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

I still, but not my gentoo linux os.. attached is my current os due to office requirement and I don't have time for hobbist os anymore :p

On 8/2/06, md_najmi <md_najmi@yahoo.com> wrote:

hi,

yoo hoo.
anyone still survive here?







Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/mygentoo/

<*> To unsubscribe from this group, send an email to:
    mygentoo-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

--
And whoever does an atom's weight of evil will see it.