Tuesday, Oct 4, 2011, 5:00 PMI was a reluctant panelist at today's public hearing for HB 1011 aka FOSS Act of 2010. Some folks did not do their homework and there was a lot of classic FUD going around, which I thought went out of fashion ten years ago.

Thursday, Aug 11, 2011, 8:11 AMLive migrated 20 virtual machines from US to UK in under 5 minutes. Yeah!

Monday, Aug 1, 2011, 1:08 AMLinux® Day is a global celebration of Linux's 20th anniversary. Join the network and start making plans for August 27, 2011. Check out linuxday.org for more information!

Wednesday, May 25, 2011, 12:35 AMPsylocke designed a GPU computer with almost 200 effective cores for her ECE 12 (Computer-Aided Design) subject a few days ago. Her teacher thinks it's impossible to build such a machine.

For the record, we have an actual unit at home.

ASUS, Dell, and Microway (among others) have been offering similar products abroad for a while now.

Aside from the usual GPGPU applications (Psylocke used TeraChem), we also explored KGPU:

"KGPU is a GPU computing framework for the Linux kernel. It allows Linux kernel to call CUDA programs running on GPUs directly. The motivation is to augment operating systems with GPUs so that not only userspace applications but also the operating system itself can benefit from GPU acceleration. It can also free the CPU from some computation intensive work by enabling the GPU as an extra computing device.

Modern GPUs can be used for more than just graphics processing; they can run general-purpose programs as well. While not well-suited to all types of programs, they excel on code that can make use of their high degree of parallelism. Most uses of so-called "General Purpose GPU" computation have been outside the realm of systems software. However, recent work on software routers and encrypted network connections has given examples of how GPGPUs can be applied to tasks more traditionally within the realm of operating systems. These uses are only scratching the surface. Other examples of system-level tasks that can take advantage of GPUs include general cryptography, pattern matching, program analysis, and acceleration of basic commonly-used algorithms."

Really cool stuff! Visit github.com/wbsun/kgpu for more information and a white paper on KGPU.

And oh yes, impossible is nothing.

Monday, May 23, 2011, 5:23 PMI'll be handling Total Linux 41 this June: http://bluepoint.com.ph/enroll/

Lock and load!

Sunday, Jan 9, 2011, 11:30 AMAfter using Gitosis for almost 3 years, I have made the switch to Gitolite ... and it über rocks!

Tuesday, May 25, 2010, 11:13 PMFedora 13 has been released: http://fedoraproject.org/wiki/Fedora_13_announcement

Congratulations to the Fedora Project!

Tuesday, Nov 17, 2009, 11:14 PMFedora 12 has been released: http://fedoraproject.org/wiki/Fedora_12_Announcement

Congratulations to the Fedora Project!

Monday, Nov 16, 2009, 11:32 PM

Magie, Herson, and I met with fellow Fedora Ambassador (and Red Hat Community Architecture team member) Mel Chua tonight at the University of the Philippines Techno Hub in Quezon City.

After dinner at Razon's (thanks Mel!), we chanced upon Herson's fraternity brod (and Mozilla Philippines Community organizer) Regnard Raquedan at the Coffee Bean (thanks Maj!).

Thanks for coordinating the meet up Herson! It was great to have some face time with comrades in Open Source.

Thursday, Jul 9, 2009, 10:24 AMI can't wait to see how this pans out:

http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html

Introducing the Google Chrome OS
7/07/2009 09:37:00 PM

It's been an exciting nine months since we launched the Google Chrome browser. Already, over 30 million people use it regularly. We designed Google Chrome for people who live on the web — searching for information, checking email, catching up on the news, shopping or just staying in touch with friends. However, the operating systems that browsers run on were designed in an era where there was no web. So today, we're announcing a new project that's a natural extension of Google Chrome — the Google Chrome Operating System. It's our attempt to re-think what operating systems should be.

Google Chrome OS is an open source, lightweight operating system that will initially be targeted at netbooks. Later this year we will open-source its code, and netbooks running Google Chrome OS will be available for consumers in the second half of 2010. Because we're already talking to partners about the project, and we'll soon be working with the open source community, we wanted to share our vision now so everyone understands what we are trying to achieve.

Speed, simplicity and security are the key aspects of Google Chrome OS. We're designing the OS to be fast and lightweight, to start up and get you onto the web in a few seconds. The user interface is minimal to stay out of your way, and most of the user experience takes place on the web. And as we did for the Google Chrome browser, we are going back to the basics and completely redesigning the underlying security architecture of the OS so that users don't have to deal with viruses, malware and security updates. It should just work.

Google Chrome OS will run on both x86 as well as ARM chips and we are working with multiple OEMs to bring a number of netbooks to market next year. The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies. And of course, these apps will run not only on Google Chrome OS, but on any standards-based browser on Windows, Mac and Linux thereby giving developers the largest user base of any platform.

Google Chrome OS is a new project, separate from Android. Android was designed from the beginning to work across a variety of devices from phones to set-top boxes to netbooks. Google Chrome OS is being created for people who spend most of their time on the web, and is being designed to power computers ranging from small netbooks to full-size desktop systems. While there are areas where Google Chrome OS and Android overlap, we believe choice will drive innovation for the benefit of everyone, including Google.

We hear a lot from our users and their message is clear — computers need to get better. People want to get to their email instantly, without wasting time waiting for their computers to boot and browsers to start up. They want their computers to always run as fast as when they first bought them. They want their data to be accessible to them wherever they are and not have to worry about losing their computer or forgetting to back up files. Even more importantly, they don't want to spend hours configuring their computers to work with every new piece of hardware, or have to worry about constant software updates. And any time our users have a better computing experience, Google benefits as well by having happier users who are more likely to spend time on the Internet.

We have a lot of work to do, and we're definitely going to need a lot of help from the open source community to accomplish this vision. We're excited for what's to come and we hope you are too. Stay tuned for more updates in the fall and have a great summer.

Update on 7/8/2009: We have posted an FAQ on the Google Chrome Blog.

Posted by Sundar Pichai, VP Product Management and Linus Upson, Engineering Director

Tuesday, Mar 17, 2009, 11:00 AMWhat started out as an initiative to get fedora.ph last January 15 resulted in ph.fedoracommunity.org being assigned to Fedora Philippines today.

Fedora Philippines is being hosted by Bluepoint Foundation on a Xen VM using fedora.bluepoint.com.ph as interim domain.

My original request was for the delegation of ph.fedoracommunity.org to Bluepoint's DNS servers via a couple of glue and NS records.

But hey, I'll take a single A record anytime.

Sunday, Jun 8, 2008, 8:00 PMIt's a Sunday, but Magie and I went online for a meeting of APAC Fedora Ambassadors at freenode earlier today.

The meeting was announced 3 weeks in advance, but there were only 5-6 attendees. I cannot help but echo Susmit Shannigrahi's sentiments: "In APAC there is a lack of people seriously trying to contribute. A lot of people join but a few continues."

At the local level, Magie tried to initiate a meeting of the 7 Fedora Ambassadors in the Philippines at least 3 times during the last 6 months. Only one bothered to reply and actually show up everytime. Me.

I hope things get better.

Friday, Nov 16, 2007, 6:00 PMThis is a very timely reminder!

[Devel] [PATCH][DOCUMENTATION] The namespaces compatibility list doc

---------------------------- Original Message ----------------------------
Subject: [Devel] [PATCH][DOCUMENTATION] The namespaces compatibility list doc
From: "Pavel Emelyanov" <xemul@openvz.org>
Date: Fri, November 16, 2007 5:34 pm
To: "Andrew Morton" <akpm@osdl.org>
Cc: "Linux Containers" <containers@lists.osdl.org>
"Cedric Le Goater" <clg@fr.ibm.com>
"Theodore Tso" <tytso@mit.edu>
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
--------------------------------------------------------------------------

From time to time people begin discussions about how the namespaces are working/going-to-work together.

Ted T'so proposed to create some document that describes what problems user may have when he/she creates some new namespace, but keeps others shared. I liked this idea, so here's the initial version of such a document with the problems I currently have in mind and can describe somewhat audibly - the "namespaces compatibility list".

The Documentation/namespaces/ directory is about to contain more docs about the namespaces stuff.

Thanks to Cedirc for notes and spell checks on the doc.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>

---

commit 83061c56e1c4dcd54d48a62b108d219a7f5279a0
Author: Pavel <pavel@xemulnb.sw.ru>
Date: Fri Nov 16 12:25:53 2007 +0300

Namespaces compatibility list

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 910e511..3ead06b 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -262,6 +262,8 @@ mtrr.txt
- how to use PPro Memory Type Range Registers to increase performance.
mutex-design.txt
- info on the generic mutex subsystem.
+namespaces/
+ - directory with various information about namespaces
nbd.txt
- info on a TCP implementation of a network block device.
netlabel/
diff --git a/Documentation/namespaces/compatibility-list.txt b/Documentation/namespaces/compatibility-list.txt
new file mode 100644
index 0000000..9c9e5c1
--- /dev/null
+++ b/Documentation/namespaces/compatibility-list.txt
@@ -0,0 +1,33 @@
+ Namespaces compatibility list
+
+This document contains the information about the problems user
+may have when creating tasks living in different namespaces.
+
+Here's the summary. This matrix shows the known problems, that
+occur when tasks share some namespace (the columns) while living
+in different other namespaces (the rows):
+
+ UTS IPC VFS PID User Net
+UTS X
+IPC X 1
+VFS X
+PID 1 1 X
+User 2 X
+Net X
+
+1. Both the IPC and the PID namespaces provide IDs to address
+ object inside the kernel. E.g. semaphore with ipcid or
+ process group with pid.
+
+ In both cases, tasks shouldn't try exposing this id to some
+ other task living in a different namespace via a shared filesystem
+ or IPC shmem/message. The fact is that this ID is only valid
+ within the namespace it was obtained in and may refer to some
+ other object in another namespace.
+
+2. Intentionnaly, two equal user ids in different user namespaces
+ should not be equal from the VFS point of view. In other
+ words, user 10 in one user namespace shouldn't have the same
+ access permissions to files, beloging to user 10 in another
+ namespace. But currently this is not so.
+

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

_______________________________________________
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel

Saturday, Sep 8, 2007, 7:24 PMSome of my former students asked me about the status of Buhawi after our SFD07 planning session earlier today. I still don't know when the development of Bluepoint's meta-distro will resume, but the next release will definitely be for x86_64 and will showcase the following:

openvz
heartbeat
csync2
lighttpd
pureftpd

Tuesday, Aug 7, 2007, 6:33 PMI'm now playing with Varnish, a state-of-the-art, high-performance HTTP accelerator. Looks good so far!

Notes from the Architect
http://varnish.projects.linpro.no/wiki/ArchitectNotes

Once you start working with the Varnish source code, you will notice that Varnish is not your average run of the mill application.

That is not a coincidence.

I have spent many years working on the FreeBSD kernel, and only rarely did I venture into userland programming, but when I had occation to do so, I invariably found that people programmed like it was still 1975.

So when I was approached about the Varnish project I wasn't really interested until I realized that this would be a good opportunity to try to put some of all my knowledge of how hardware and kernels work to good use, and now that we have reached alpha stage, I can say I have really enjoyed it.

So what's wrong with 1975 programming?

here isn't anything new The really short answer is that computers do not have two kinds of storage any more.

It used to be that you had the primary store, and it was anything from acoustic delaylines filled with mercury via small magnetic dougnuts via transistor flip-flops to dynamic RAM.

And then there were the secondary store, paper tape, magnetic tape, disk drives the size of houses, then the size of washing machines and these days so small that girls get disappointed if think they got hold of something else than the MP3 player you had in your pocket.

And people program this way.

They have variables in "memory" and move data to and from "disk".

Take Squid for instance, a 1975 program if I ever saw one: You tell it how much RAM it can use and how much disk it can use. It will then spend inordinate amounts of time keeping track of what HTTP objects are in RAM and which are on disk and it will move them forth and back depending on traffic patterns.

Well, today computers really only have one kind of storage, and it is usually some sort of disk, the operating system and the virtual memory management hardware has converted the RAM to a cache for the disk storage.

So what happens with squids elaborate memory management is that it gets into fights with the kernels elaborate memory management, and like any civil war, that never gets anything done.

What happens is this: Squid creates a HTTP object in "RAM" and it gets used some times rapidly after creation. Then after some time it get no more hits and the kernel notices this. Then somebody tries to get memory from the kernel for something and the kernel decides to push those unused pages of memory out to swap space and use the (cache-RAM) more sensibly for some data which is actually used by a program. This however, is done without squid knowing about it. Squid still thinks that these http objects are in RAM, and they will be, the very second it tries to access them, but until then, the RAM is used for something productive.

This is what Virtual Memory is all about.

If squid did nothing else, things would be fine, but this is where the 1975 programming kicks in.

After some time, squid will also notice that these objects are unused, and it decides to move them to disk so the RAM can be used for more busy data. So squid goes out, creates a file and then it writes the http objects to the file.

Here we switch to the high-speed camera: Squid calls write(2), the address i gives is a "virtual address" and the kernel has it marked as "not at home".

So the CPU hardwares paging unit will raise a trap, a sort of interrupt to the operating system telling it "fix the memory please".

The kernel tries to find a free page, if there are none, it will take a little used page from somewhere, likely another little used squid object, write it to the paging poll space on the disk (the "swap area") when that write completes, it will read from another place in the paging pool the data it "paged out" into the now unused RAM page, fix up the paging tables, and retry the instruction which failed.

Squid knows nothing about this, for squid it was just a single normal memory acces.

So now squid has the object in a page in RAM and written to the disk two places: one copy in the operating systems paging space and one copy in the filesystem.

Squid now uses this RAM for something else but after some time, the HTTP object gets a hit, so squid needs it back.

First squid needs some RAM, so it may decide to push another HTTP object out to disk (repeat above), then it reads the filesystem file back into RAM, and then it sends the data on the network connections socket.

Did any of that sound like wasted work to you ?

Here is how Varnish does it:

Varnish allocate some virtual memory, it tells the operating system to back this memory with space from a disk file. When it needs to send the object to a client, it simply refers to that piece of virtual memory and leaves the rest to the kernel.

If/when the kernel decides it needs to use RAM for something else, the page will get written to the backing file and the RAM page reused elsewhere.

When Varnish next time refers to the virtual memory, the operating system will find a RAM page, possibly freeing one, and read the contents in from the backing file.

And that's it. Varnish doesn't really try to control what is cached in RAM and what is not, the kernel has code and hardware support to do a good job at that, and it does a good job.

Varnish also only has a single file on the disk whereas squid puts one object in its own separate file. The HTTP objects are not needed as filesystem objects, so there is no point in wasting time in the filesystem name space (directories, filenames and all that) for each object, all we need to have in Varnish is a pointer into virtual memory and a length, the kernel does the rest.

Virtual memory was meant to make it easier to program when data was larger than the physical memory, but people have still not caught on.

More caches.

But there are more caches around, the silicon mafia has more or less stalled at 4GHz CPU clock and to get even that far they have had to put level 1, 2 and sometimes 3 caches between the CPU and the RAM (which is the level 4 cache), there are also things like write buffers, pipeline and page-mode fetches involved, all to make it a tad less slow to pick up something from memory.

And since they have hit the 4GHz limit, but decreasing silicon feature sizes give them more and more transistors to work with, multi-cpu designs have become the fancy of the world, despite the fact that they suck as a programming model.

Multi-CPU systems is nothing new, but writing programs that use more than one CPU at a time has always been tricky and it still is.

Writing programs that perform well on multi-CPU systems is even trickier.

Imagine I have two statistics counters:

unsigned n_foo;
unsigned n_bar;

So one CPU is chugging along and has to execute n_foo++

To do that, it read n_foo and then write n_foo back. It may or may not involve a load into a CPU register, but that is not important.

To read a memory location means to check if we have it in the CPUs level 1 cache. It is unlikely to be unless it is very frequently used. Next check the level two cache, and let us assume that is a miss as well.

If this is a single CPU system, the game ends here, we pick it out of RAM and move on.

On a Multi-CPU system, and it doesn't matter if the CPUs share a socket or have their own, we first have to check if any of the other CPUs have a modified copy of n_foo stored in their caches, so a special bus-transaction goes out to find this out, if if some cpu comes back and says "yeah, I have it" that cpu gets to write it to RAM. On good hardware designs, our CPU will listen in on the bus during that write operation, on bad designs it will have to do a memory read afterwards.

Now the CPU can increment the value of n_foo, and write it back. But it is unlikely to go directly back to memory, we might need it again quickly, so the modified value gets stored in our own L1 cache and then at some point, it will end up in RAM.

Now imagine that another CPU wants to n_bar+++ at the same time, can it do that ? No. Caches operate not on bytes but on some "linesize" of bytes, typically from 8 to 128 bytes in each line. So since the first cpu was busy dealing with n_foo, the second CPU will be trying to grab the same cache-line, so it will have to wait, even through it is a different variable.

Starting to get the idea ?

Yes, it's ugly.

How do we cope ?

Avoid memory operations if at all possible.

Here are some ways Varnish tries to do that:

When we need to handle a HTTP request or response, we have an array of pointers and a workspace. We do not call malloc(3) for each header. We call it once for the entire workspace and then we pick space for the headers from there. The nice thing about this is that we usually free the entire header in one go and we can do that simply by resetting a pointer to the start of the workspace.

When we need to copy a HTTP header from one request to another (or from a response to another) we don't copy the string, we just copy the pointer to it. Provided we do not change or free the source headers, this is perfectly safe, a good example is copying from the client request to the request we will send to the backend.

When the new header has a longer lifetime than the source, then we have to copy it. For instance when we store headers in a cached object. But in that case we build the new header in a workspace, and once we know how big it will be, we do a single malloc(3) to get the space and then we put the entire header in that space.

We also try to reuse memory which is likely to be in the caches.

The worker threads are used in "most recently busy" fashion, when a workerthread becomes free it goes to the front of the queue where it is most likely to get the next request, so that all the memory it already has cached, stack space, variables etc, can be reused while in the cache, instead of having the expensive fetches from RAM.

We also give each worker thread a private set of variables it is likely to need, all allocated on the stack of the thread. That way we are certain that they occupy a page in RAM which none of the other CPUs will ever think about touching as long as this thread runs on its own CPU. That way they will not fight about the cachelines.

If all this sounds foreign to you, let me just assure you that it works: we spend less than 18 system calls on serving a cache hit, and even many of those are calls tog get timestamps for statistics.

These techniques are also nothing new, we have used them in the kernel for more than a decade, now it's your turn to learn them :-)

So Welcome to Varnish, a 2006 architecture program.

Poul-Henning Kamp, Varnish architect and coder.

Monday, May 21, 2007, 2:04 PMI've been using OpenVZ since it's first release. It's time to join devel.

So far, I'm learning a lot from the community, especially from Linux luminaries like Ingo Molnar, Rusty Russel, Andrew Morton, and even Linus Torvalds!

Friday, May 4, 2007, 7:04 PMGaim is now Pidgin! Following a legal settlement with AOL, Gaim has been renamed Pidgin and its 2.0.0 release is now available.

Monday, Mar 19, 2007, 12:00 PMNews from Debian Master Ian Murdock:

http://ianmurdock.com/2007/03/19/joining-sun/

I saw my first Sun workstation about 15 years ago, in 1992. I was a business student at Purdue University, and a childhood love for computers had just been reawakened. I was spending countless hours in the basement of the Math building, basking in the green phosphorescent glow of a Z29 and happily exploring every nook and cranny of the Sequent Symmetry upstairs. It didn’t take too long to discover, though, just a short walk away in the computer science building, several labs full of Sun workstations. Suddenly, the Z29 didn’t have quite the same allure. A few months later, I walked over to the registrar’s office and changed my major to computer science. (OK, advanced tax accounting had something to do with it too.)

Everything I know about computing I learned on those Sun workstations, as did so many other early Linux developers; I even had my own for a while, after I joined the University of Arizona computer science department in 1997. But within a year, the Suns were starting to disappear, replaced by Pentiums running Red Hat Linux. More and more people coming through university computer science programs were cutting their teeth on Linux, much as I had on Sun. Pretty soon, Sun was increasingly seen by this new generation as the vendor who didn’t “get it”, and Sun’s rivals did a masterful job running with that and painting the company literally built on open standards as “closed”. To those of us who knew better, it was a sad thing to watch.

The last several years have been hard for Sun, but the corner has been turned. As an outsider, I’ve watched as Sun has successfully embraced x86, pioneered energy efficiency as an essential computing feature, open sourced its software portfolio to maximize the network effects, championed transparency in corporate communications, and so many other great things. Now, I’m going to be a part of it.

And, so, I’m excited to announce that, as of today, I’m joining Sun to head up operating system platform strategy. I’m not saying much about what I’ll be doing yet, but you can probably guess from my background and earlier writings that I’ll be advocating that Solaris needs to close the usability gap with Linux to be competitive; that while as I believe Solaris needs to change in some ways, I also believe deeply in the importance of backward compatibility; and that even with Solaris front and center, I’m pretty strongly of the opinion that Linux needs to play a clearer role in the platform strategy.

It is with regrets that I leave the Linux Foundation, but if you haven’t figured out already, Sun is a company I’ve always loved, and being a part of it was an opportunity I simply could not pass up. I think the world of the people at the LF, particularly my former FSG colleagues with whom I worked so closely over the past year and a half: Jim Zemlin, Amanda McPherson, Jeff Licquia, and Dan Kohn. And I still very much believe in the core LF mission, to prevent the fragmentation of the Linux platform. Indeed, I’m remaining in my role as chair of the LSB—and Sun, of course, is a member of the Linux Foundation.

Anyway. Watch this space. This is going to be fun!

Tuesday, Mar 13, 2007, 6:18 PM

From: hpa@transmeta.com (H. Peter Anvin)
Newsgroups: comp.os.linux.announce
Subject: FTP: New Linux FTP site: ftp.kernel.org
Date: 13 Mar 1997 18:18:28 GMT
Organization: Transmeta Corporation, Santa Clara CA
Approved: linux-announce@news.ornl.gov (Lars Wirzenius)
Message-ID: <pgpmoose.199703132018.30874@liw.clinet.fi>
Reply-To: hpa@transmeta.com (H. Peter Anvin)
iQBVAwUBMyhE8jiesvPHtqnBAQGxkAH/dfxpXww+7WnWReKpoVi0E2NKrxbXfEi5
W5la7Ubk/vaVUeBN0qET/NLIUZJxsBsI4MTGLL61CQgZ23vp23vFGQ==
=vrr+
Lines: 48
Xref: nntpfeed.doc.ic.ac.uk comp.os.linux.announce:6836

-----BEGIN PGP SIGNED MESSAGE-----

Transmeta Corporation is proud to sponsor a new Linux FTP site:

ftp.kernel.org

Currently, ftp.kernel.org contains the Linux kernel and a set of
mirror sites; in the future, we hope to make space available for users
to publish packages directly.

We are currently connected via a T1; plans are to upgrade to 10 Mbit/s
in the near future.

This site is accessible via:

FTP ftp://ftp.kernel.org/pub
HTTP http://ftp.kernel.org/pub
NFS ftp.kernel.org:/pub
SMB/CIFS \\ftp.kernel.org\pub

Enjoy...

-hpa

- --
This space intentionally has nothing but text explaining why this
space has nothing but text explaining that this space would otherwise
have been left blank, and would otherwise have been left blank.



- --
This article has been digitally signed by the moderator, using PGP.
http://www.iki.fi/liw/lars-public-key.asc has PGP key for validating signature.
Send submissions for comp.os.linux.announce to: linux-announce@news.ornl.gov
PLEASE remember a short description of the software and the LOCATION.
This group is archived at http://www.iki.fi/liw/linux/cola.html

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBMyhE6IQRll5MupLRAQGNRgQAv/wGUYin2qUo8D7IJsmzf1bC6eEHw1vA
LP14sLiFmELRq7hLYHBWN02vZ50+hnv3j8dul/PX796KUFbOD3W+lXw1dAAxW5CY
qK3q7QgC+kCfvE8h5V2bNW3ktcFPhKLwFMX8PxRFrwkHYlcOy8DZqOjR6nzgWr2f
sxRluTk0PlY=
=PLxE
-----END PGP SIGNATURE-----

Wednesday, Feb 21, 2007, 5:30 PMI caused a kernel panic while playing around with some ReiserFS parameters on my Fedora Core 6 Athlon64 X2 test box. Instead of freezing as expected, Linux continued to run! I managed to duplicate the error. The box froze this time. I found out that the first kernel panic only took out one of the cores. This was why Linux continued to run. It took a second panic to take out the other core and crash the box. Cool!

Thursday, Jan 25, 2007, 5:50 PMFrom: "Fyodor" <fyodor@insecure.org>
Subject: Seclists.Org shut down by Myspace and GoDaddy
Date: Thu, January 25, 2007 5:47 pm
To: nmap-hackers@insecure.org

Hi everyone,

Many of you reported that our SecLists.Org security mailing list archive was down most of yesterday (Wed), and all you really need to know is that we're back up and running! But I'm going into rant mode
anyway in case you care for the details.

I woke up yesterday morning to find a voice message from my domain registrar (GoDaddy) saying they were suspending the domain SecLists.org. One minute later I received an email saying that SecLists.org has "been suspended for violation of the GoDaddy.com Abuse Policy". And also "if the domain name(s) listed above are private, your Domains By Proxy(R) account has also been suspended." WTF??! Neither the email nor voicemail gave a phone number to reach them at, nor did they feel it was worth the effort to explain what the supposed violation was. They changed my domain nameserver to
"NS1.SUSPENDED-FOR.SPAM-AND-ABUSE.COM". Cute, eh?

I called GoDaddy several times, and all three support people I spoke with (Craig, Ricky, then Wael) said that the abuse department doesn't take calls. They said I had email abuse@godaddy.com (which I had
already done 3 times) and that I could then expect a response "within 1 or two business days". Given that tens of thousands of people use SecLists.Org every day, I didn't take that well. When they realized I
was going to just keep calling until they did something, they finally persuaded the abuse department to explain why they cut me off: Myspace.Com asked them to.

Apparently Myspace is still reeling from all the news reports more than a week ago about a list of 56,000 myspace usernames+passwords making the rounds. It was all over the news, and reminded people of a
completely different list of 34,000 MySpace passwords which was floating around last year. MySpace users fall for a LOT of phishing scams. They are basically the new AOL. Anyway, everyone has this
latest password list now, and it was even posted (several times) to the thousands of members of the fulldisclosure mailing list more than a week ago. So it was archived by all the sites which archive
full-disclosure, including SecLists.Org.

Instead of simply writing me (or abuse@seclists.org) asking to have the password list removed, MySpace decided to contact (only) GoDaddy and try to have the whole site of 250,000 pages removed because they don't like one of them. And GoDaddy cowardly and lazily decided to simply shut down the site rather than actually investigating or giving me a chance to contest or comply with the complaint. Needless to say, I'm in the market for a new registrar. One who doesn't immediately bend over for any large corporation who asks. One who considers it their job just to refer people to the SecLists.Org nameserver at 205.217.153.50, not to police the content of the services hosted at the domains. The GoDaddy ToS forbids hosting what they call "morally objectionable activities".

It is way too late for MySpace to put the cat back in the bag anyway. The bad guys already have the file, and anyone else who wants it need only Google for "myspace1.txt.bz2" or "duckqueen1". Is MySpace going to try and shut down Google next?

For some reason, this is only one of a spate of bogus Seclists removal requests. I do remove material that is clearly illegal or inappropriate for SecLists.org (like the bonehead who keeps posting furry porn to fulldisclosure). But one company sent a legal threat demanding[1] that I remove a 7-year old Bugtraq posting which was a complaint about previous bogus legal threats they had sent. Another guy[2] last week sent a complaint to my ISP saying that an image was child porn and declaring that he would notify the FBI. When asked why he thought the picture was of a child, he tried a different tack: sending a DMCA complaint declaring under penalty of perjury that he is the copyright holder of the photo! Michael Crook told me on the phone that he sent the DMCA request, but when I forwarded the info to the EFF (who is already suing this guy for sending other bogus DMCA complaints), he changed his mind and wrote that "after further review, I can find no record" or mailing the complaint.

Most of the censorship attempts are for the full-disclosure list. It would be easiest just to cease archiving that list, but I do think it serves an important purpose in keeping the industry honest. And many good postings do make it through if you can filter out all the junk. So I'm keeping it, no matter how "morally objectionable" GoDaddy and MySpace may think it to be!

In much happier Nmap news, I'm pleased to report that the Nmap project now has a public SVN server so you can always check out the latest version. Due to a bug in SVN, we use a username as "guest" with no password rather than anonymous. So check it out with the command:

svn co --username guest --password "" svn://svn.insecure.org/nmap

Then do the normal:
./configure
make

And install it or set NMAPDIR to "." to run in place. Among other goodies, this release includes the Nmap scripting language[3].

If you want to follow Nmap development on a check-in by check-in basis, there is a new nmap-svn mailing list[4] for that. But be prepared for some high traffic as you'll get every patch!

2007 will be a good year for Nmap!

Cheers,
Fyodor

[1] http://seclists.org/nmap-dev/2006/q4/0302.html
[2] http://seclists.org/nmap-dev/2007/q1/0067.html
[3] http://insecure.org/nmap/nse/
[4] http://cgi.insecure.org/mailman/listinfo/nmap-svn

_______________________________________________
Sent through the nmap-hackers mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-hackers
Archived at http://seclists.org

Monday, Jan 22, 2007, 4:08 PMThe Open Source Developer Labs and the Free Standards Group have merged today as the Linux Foundation.

Friday, Jan 12, 2007, 11:00 PMChinese Professor Cracks Fifth Data Security Algorithm
SHA-1 added to list of "accomplishments"

Central News Agency
http://en.epochtimes.com/news/7-1-11/50336.html

Jan 11, 2007

Associate professor Wang Xiaoyun of Beijing's Tsinghua University and Shandong University of Technology has cracked SHA-1, a widely used data security algorithm.

TAIPEI—Within four years, the U.S. government will cease to use SHA-1 (Secure Hash Algorithm) for digital signatures, and convert to a new and more advanced "hash" algorithm, according to the article "Security Cracked!" from New Scientist . The reason for this change is that associate professor Wang Xiaoyun of Beijing's Tsinghua University and Shandong University of Technology, and her associates, have already cracked SHA-1.

Wang also cracked MD5 (Message Digest 5), the hash algorithm most commonly used before SHA-1 became popular. Previous attacks on MD5 required over a million years of supercomputer time, but Wang and her research team obtained results using ordinary personal computers.

In early 2005, Wang and her research team announced that they had succeeded in cracking SHA-1. In addition to the U.S. government, well-known companies like Microsoft, Sun, Atmel, and others have also announced that they will no longer be using SHA-1.

Two years ago, Wang announced at an international data security conference that her team had successfully cracked four well-known hash algorithms—MD5, HAVAL-128, MD4, and RIPEMD—within ten years.

A few months later, she cracked the even more robust SHA-1.

Focus and Dedication

According to the article, Wang's research focusses on hash algorithms.

A hash algorithm is a mathematical procedure for deriving a 'fingerprint' of a block of data. The hash algorithms used in cryptography are "one-way": it is easy to derive hash values from inputs, but very difficult to work backwards, finding an input message that yields a given hash value. Cryptographic hash algorithms are also resistant to "collisions": that is, it is computationally infeasible to find any two messages that yield the same hash value.

Hash algorithms' usefulness in data security relies on these properties, and much research focusses in this area.

Recent years have seen a stream of ever-more-refined attacks on MD5 and SHA-1—including, notably, Wang's team's results on SHA-1, which permit finding collisions in SHA-1 about 2,000 times more quickly than brute-force guessing. Wang's technique makes attacking SHA-1 efficient enough to be feasible.

MD5 and SHA-1 are the two most extensively used hash algorithms in the world. These two algorithms underpin many digital signature and other security schemes in use throughout the international community. They are widely used in banking, securities, and e-commerce. SHA-1 has been recognized as the cornerstone for modern Internet security.

According to the article, in the early stages of Wang's research, there were other researchers who tried to crack it. However, none of them succeeded. This is why in 15 years hash research had become the domain of hopeless research in many scientists' minds.

Wang's method of cracking algorithms differs from others'. Although such analysis usually cannot be done without the use of computers, according to Wang, the computer only assisted in cracking the algorithm. Most of the time, she calculated manually, and manually designed the methods.

"Hackers crack passwords with bad intentions," Wang said. "I hope efforts to protect against password theft will benefit [from this]. Password analysts work to evaluate the security of data encryption and to search for even more secure … algorithms."

"On the day that I cracked SHA-1," she added, "I went out to eat. I was very excited. I knew I was the only person who knew this world-class secret."

Within ten years, Wang cracked the five biggest names in cryptographic hash algorithms. Many people would think the life of this scientist must be monotonous, but "That ten years was a very relaxed time for me," she says.

During her work, she bore a daughter and cultivated a balcony full of flowers. The only mathematics-related habit in her life is that she remembers the license plates of taxi cabs.

With additional reporting by The Epoch Times.