Muli Ben-Yehuda's journal

The Kernel Korner articles in Linux Journal are usually pretty good. This month’s, however, discusses an in-kernel ftp server (signs of danger), does not check memory allocations and overwrites sys_call_table from a module. I stopped reading at that point.

Fourth Annual Workshop on Systems and Storage Technology
December 11, 2005
Organized by the IBM Research Lab in Haifa

You are cordially invited to participate in a one-day workshop on
Systems and Storage Technology, to be held on Sunday, December 11,
2005 at the IBM Research Lab in Haifa, located on the Haifa University
campus, Mount Carmel, Haifa, Israel.

This annual full-day workshop provides a venue for the research and
development communities from both academia and industry to share their
work, exchange ideas, and discuss issues, problems, works-in-progress,
and future research directions and trends.

This year’s workshop emphasizes the concepts of virtualization and
scale-out that have recently become hot topics in the IT industry.

Virtualization is a collective term used for software and hardware
technologies that aim at consolidating organizational computing
resources, often heterogeneous and scattered over multiple physical
locations, into a unified computing infrastructure. A virtualized
system facilitates resource sharing and management, thus improving
utilization and operational costs. Virtualization seeks to present
computing resources so that users and applications can easily benefit
from them, rather than presenting them in a way dictated by their
implementation, geographic location, or physical packaging. In other
words, virtualization provides a logical rather than physical view of
data, computing power, storage capacity, and other resources.

Scale-out computing leverages the pay-as-you-grow hardware acquisition
model. Its goal is to facilitate seamless integration of newly
acquired components into existing systems, and optimize the
utilization of those components for better load balancing, high
availability, and workload partitioning.

Topics of interest include, but are not limited to, the following
subjects:

• Server virtualization
• Virtualization and scale-out technologies (networking, blade centers, VMware, etc.)
• Server migration
• Remote deployment
• Remote software distribution and upgrade
• Clustering for virtualization and scale-out
• Scale-out and virtualization in grid computing
• Storage virtualization
• Network virtualization
• Virtualization through Web services
• High availability
• System and network management
• Autonomy and self-management: self-healing, self-protection, self-configuration, self-optimization, etc.
• Interfacing to virtualized systems and services (ubiquitous
  computing)

The workshop will take place in the auditorium (room L100) of the IBM
Research Lab in Haifa. A detailed agenda and participation information
will be distributed at a later date. The official language of the
workshop is English.

Please feel free to distribute this invitation to students and fellow
researchers/developers.

Important Dates

• November 12, 2005: Abstracts due
• November 27, 2005: Notification of paper acceptance
• December 11, 2005: Workshop gathering and presentations (Sunday)

What to Submit: Please send an abstract (up to one page in 11
pt. font) describing your work in either PDF, Postscript, or MS-Word
format.

How to Submit: Email your submission to: David Breitgand
(davidbr[at]il.ibm.com), Gregory Chockler (chockler[at]il.ibm.com), Eyal
Gordon (gordon[at]il.ibm.com)

Workshop Organizers: Alain Azagury (azagury[at]il.ibm.com), David
Breitgand (davidbr[at]il.ibm.com), Gregory Chockler
(chockler[at]il.ibm.com), Amiram Hayardeny (amiram[at]il.ibm.com), Eyal
Gordon (gordon[at]il.ibm.com), Hillel Kolodner (kolodner[at]il.ibm.com),
Kalman Meth (meth[at]il.ibm.com), Yaron Wolfsthal
(wolfstal[at]il.ibm.com)

Your favorite distro’s motivational poster is available at http://www.arouse.net/despair-linux/.

The latest Everybody Loves Eric Raymond is awesome as usual.

Happy 60’th Birthday IBM Research!

(it’s cool, awe inspiring and somewhat frightening to be a part of something this big. Mostly cool, though.)

Just heard on a conference call:
Q: “Can you guys understand me?” (on a line with horrible audio quality)
A: “No!”

Cites You Like is neat. You can find cites I like under ‘muli’, or via this RSS feed: http://www.citeulike.org/rss/user/muli (citesmulilikes on lj).

When I started working at HRL, one of the first things I set up was
printing from Linux. It turned out to be pretty simple: create
postscript, and use a proprietary “pdpr” program on Linux to send the
postscript file to the printer. All was good and well, until while I
was abroad, new printers were installed that didn’t work with pdpr any
more, thus leading me to experiment with printing the modern
way. After installing the necessary packages and running a script to
set everything up (all thoughtfully provided by our system team!)
printing from mozilla, openoffice and the command line worked. I was a
happy camper.

Then I decided to go all the way and get printing from (x)emacs
working directly (rather than C-u M-x ps-print-buffer -> create a .ps
file -> print from the command line). A couple of hours spent
debugging ps-print.el, I had a script called “emacsprint”
which worked. Its contents?

muli@rhun:~$ cat bin/emacsprint
#!/bin/bash

lpr $*

That’s all. Naturally, just calling lpr directly did not work. I
decided to leave it for the night and wait for
inspiration. Inspiration came today.

Compare and contrast:

"lpr" "-P [printername]"

with

"lpr" "-P[printername]"

If it’s not obvious, consider:

"lpr" "-P" "[printername]"

“-P [printername]” was getting passed to lpr as one argument, rather
than two, which lpr then did not know what to do with. When expanding
it via the wrapper script and $*, it was properly passed as two
arguments.

It’s good to be home!

Linus on specifications. All I can say is – amen. The rest of the thread is amusing in a horrifying way, an Adaptec guy ranting and raving and Just Not Getting It. If this is any indication of Adaptec engineers… I know which storage vendor I will not be buying from.

How we do the SW is indeed up to us, but I want to step in on your first point.

Again.

A “spec” is close to useless. I have _never_ seen a spec that was both big enough to be useful _and_ accurate.

And I have seen _lots_ of total crap work that was based on specs. It’s _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality.

So there’s two MAJOR reasons to avoid specs:

– they’re dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW. When reality and specs clash, the spec has zero meaning. Zilch. Nada. None.

It’s like real science: if you have a theory that doesn’t match experiments, it doesn’t matter _how_ much you like that theory. It’s wrong. You can use it as an approximation, but you MUST keep in mind that it’s an approximation.

– specs have an inevitably tendency to try to introduce abstractions levels and wording and documentation policies that make sense for a written spec. Trying to implement actual code off the spec leads to the code looking and working like CRAP.

The classic example of this is the OSI network model protocols. Classic spec-design, which had absolutely _zero_ relevance for the real world. We still talk about the seven layers model, because it’s a convenient model for _discussion_, but that has absolutely zero to do with any real-life software engineering. In other words, it’s a way to _talk_ about things, not to implement them.

And that’s important. Specs are a basis for _talking_about_ things. But they are _not_ a basis for implementing software.

So please don’t bother talking about specs. Real standards grow up _despite_ specs, not thanks to them.

Linus