Software and hardware annotations q3 2006

Today we were given a chance to see the first prototype wafer they will be using for production of 80-core processors. Each CPU like that will have 80 simple floating-point dies and each die is capable of teraflop performance and can transfer terabytes of data per second. They claim that it will be commercially available in a 5-year window and will be ideal for such tasks as real-time speech translation or massive search, for instance.

#!/bin/sh

SP='[:space:]'

: '
  Copyright (C) 2006 PeterG. This program is free software: you
  can redistribute it and/or modify it under the terms of the
  GNU General Public License as published by the Free Software
  Foundation, either version 2 of the License, or (at your
  option) any later version. This program is distributed in the
  hope that it will be useful, but WITHOUT ANY WARRANTY; without
  even the implied warranty of MERCHANTABILITY or FITNESS FOR A
  PARTICULAR PURPOSE.

  We need to look up the key to find type, options and device to
  mount. This means we need the name of an "fstab" file and the
  prefix under which the key appears in it. These can be different
  depending on the "autofs" mount point, under which this script
  is run.
'
case "$PWD" in
*)	FSTAB='/etc/fstab'; FSPFX="$PWD/";; 
esac

KEY="$1"

grep '^['"$SP"']*[^\#'"$SP"']\+['"$SP"']\+'"$FSPFX$KEY"'/\?['"$SP"']' \
  "$FSTAB" | if read DEV DIR TYPE OPTS REST
    then
      case "$TYPE" in ?*)
	case "$OPTS" in
	'') OPTS="fstype=$TYPE";;
	?*) OPTS="fstype=$TYPE,$OPTS";;
        esac;;
      esac
      case "$DEV" in *':'*) :;; *) DEV=":$DEV";; esac

      : '
	We must omit the key in a map program like this.
      	key -[fstype=TYPE,][OPTION]* [HOST]:RESOURCE
      '
      echo "-$OPTS $DEV"
    fi

af:2345:wait:/usr/sbin/automount -t 300 /media program /etc/auto.fstab

I have been able to try out a dual-dual-core Opteron machine, and it flies.
In fact, it flies so well that we ordered one that day. So, in short £3k's worth of dual-opteron beat the living daylights out of our Xeon monster. I can't praise the Opteron enough, and I've always been a firm Intel pedant - the HyperTransport stuff must really be doing wonders. I typically see 500ms searches on it instead of 1000-2000ms on the Xeon)

Actually, believe it or not, a coworker just saw HT double the performance of pgbench on his desktop machine.
Granted, not really a representative test case, but it still blew my mind. This was with a database that fit in his 1G of memory, and running windows XP. Both cases were newly minted pgbench databases with a scale of 40. Testing was 40 connections and 100 transactions. With HT he saw 47.6 TPS, without it was 21.1.

• That the Opteron and the Cell BE will not be on the same board, but in entirely separate computers. I could have imagined using the Cell BE as a coprocessor for the Opteron.
• That not only the Opteron and Cell elements will be distinct, but that the Opteron ones are based on a different physical format, even if there are pretty good looking Opteron based blades for the BladeCenter H infrastructure used for the Cell based systems.

Roadrunner's construction will involve the creation of advanced "Hybrid Programming" software which will orchestrate the Cell B.E.-based system and AMD system and will inaugurate a new era of heterogeneous technology designs in supercomputing. These innovations, created collaboratively among IBM and LANL engineers will allow IBM to deploy mixed-technology systems to companies of all sizes, spanning industries such as life sciences, financial services, automotive and aerospace design.

Polipo is a small and fast caching web proxy (a web cache, an HTTP proxy, a proxy server) designed to be used by one person or a small group of people. I like to think that is similar in spirit to WWWOFFLE, but the implementation techniques are more like the ones ones used by Squid.
Polipo has some features that are, as far as I know, unique among currently available proxies:

• Polipo will use HTTP/1.1 pipelining if it believes that the remote server supports it, whether the incoming requests are pipelined or come in simultaneously on multiple connections (this is more than the simple usage of persistent connections, which is done by e.g. Squid);
• Polipo will cache the initial segment of an instance if the download has been interrupted, and, if necessary, complete it later using Range requests;
• Polipo will upgrade client requests to HTTP/1.1 even if they come in as HTTP/1.0, and up- or downgrade server replies to the client's capabilities (this may involve conversion to or from the HTTP/1.1 chunked encoding);
• Polipo has complete support for IPv6 (except for scoped (link-local) addresses).
• Polipo can optionally use a technique known as Poor Man's Multiplexing to reduce latency even further.

In short, Polipo uses a plethora of techniques to make web browsing (seem) faster.

<IfModule mod_proxy.c>
  ProxyRequests         on
  Listen                *:3128

  NoProxy               127.0.0.1
  NoProxy               192.0.2.0/24
  NoProxy               .sabi.co.UK
  ProxyDomain           .sabi.co.UK
  ProxyVia              on
  ProxyTimeout          50

  <Proxy *>
    Satisfy             any
    Order               deny,allow
    Deny from           all
    Allow from          127.0.0.1
    Allow from          192.0.2.
  </Proxy>
</IfModule>

<IfModule mod_cache.c>
  CacheDefaultExpire            3600
  CacheMaxExpire                86400
  CacheLastModifiedFactor       0.1
  CacheIgnoreNoLastMod          on
  CacheIgnoreCacheControl       off

  <IfModule mod_disk_cache.c>
    CacheEnable                 disk http://

    CacheRoot                   /var/cache/httpd
    CacheDirLength              1
    CacheDirLevels              2
    CacheMinFileSize            1
    CacheMaxFileSize            900000
  </IfModule>

  <IfModule mod_mem_cache.c>
    CacheEnable                 mem /

    MCacheSize                  10000
    MCacheMinObjectSize         1
    MCacheMaxObjectSize         200000
    MCacheMaxObjectCount        2000
  </IfModule>

  CacheDisable                  http://[::1]/
  CacheDisable                  http://127.0.0.1/
  CacheDisable                  http://localhost/
  CacheDisable                  http://ip6-localhost/
  CacheDisable                  http://example.com/
  CacheDisable                  http://.example.com/
</IfModule>

• The / pattern would match both local and proxy URIs.
• No way to match all subdomains of a domain.
• Anyhow, proxy URIs could otherwise only be matched by fully specifying the hostname part of the URI, that is http:// would match no URIs.

they are stable (because they don't depend on your ISP),

• If one gets an IPv6 prefix from an ISP, assigns addresses under it to nodes, and then changes ISP, one gets a different prefix, and has to change the address of all nodes.
• If one uses from the beginning a private prefix, changes in ISP only require changes at the border gateways that remap the private prefix into the changing global one, not all nodes.

• Since IPv4 private addresses are ambiguous, and they are drawn from well known address ranges, even if datagrams carrying them leak onto the Internet they are not routable because no Internet router (hopefully) will accept routes for those well known address ranges, and most will simply drop packets to or from such addresses (which are listed in well known bogon list).
• Since IPv4 private addresses are ambiguous and thus not routable on the Internet, a node with only a private address must use a NAT proxy to access the Internet, and viceversa, and this means that administrators can control and monitor all traffic from and to the Internet for nodes which only have an IPv4 private address.

Note: it is of course possible to create a separate intranet which reuses the full 32 bit address space of IPv4 instead of just the private address ranges. But while the latter only requires NAT one way (because the intranet and the Internet address sets then do not overlap, only the intranet addresses at different sites overlap), a full separate internet would require two way NAT, mapping in-use Internet addresses to a subset of the intranet's address space, as well as in-use intranet addresses to a subset of the Internet's address space, and addresses in the DNS protocol would have to be mapped too.

The only alternative is to sacrifice a deterministic notion of identity by using random identifiers to approximate global uniqueness with a known probability of failure (which can be made arbitrarily small if the overall size of the system is known in advance).

• In XEmacs, often, after doing a regular expression based search and replace, the next search and replace does not match its target. If I repeat it identically it does.
• In KDE's Konsole after a while I use the 8 key stops having an effect.
• In Fedora the Yum dependency manager as a rule does not clean after itself, even if one uses the clean all command, sometimes leaving hundreds of MiBs of data in its cache.

The blackhole servers generally answer thousands of queries per second. In the past couple of years the number of queries to the blackhole servers has increased dramatically.
It is believed that the large majority of those queries occur because of "leakage" from intranets that are using the RFC 1918 private addresses. This can happen if the private intranet is internally using services that automatically do reverse queries, and the local DNS resolver needs to go outside the intranet to resolve these names.
For well-configured intranets, this shouldn't happen.

Users are not always able to make crucial performance decisions correctly. For example, the INGRES system catalogs are accessed very frequently and in a predictable way.
There are clear instructions concerning how the system catalogs should be physically structured (they begin as heaps and should be hashed when their size becomes somewhat stable). Even so, some users fail to hash them appropriately.
Of course, the system continues to run; it just gets slower and slower. We have finally removed this particular decision from the user's domain entirely. It makes me a believer in automatic database design (e.g., [11]).

For an example of that on the customer side, we want to improve performance. The engineers said: "Rather than guessing what's bottlenecking performance, let's go and measure what's actually going on." We instrumented all the Steam clients, and the answer was surprising. We thought that we should go and build a deferred level-loader, so that levels would swap in. It turned out that the real issue was that gamers' hard drives were really fragmented, and all of the technology we wanted wouldn't have made a difference, as we were spending all our time waiting on the disk-heads spinning round.

The solution that we're trying is to break things into smaller chunks and to do them more regularly. So far, it seems to be working. When we look at how long it took us to build a minute of gameplay for Half-Life 2, versus how many man-months it takes us to build a minute of gameplay for Episode One or Episode Two, we seem to be about four times as productive. But we'll go through all three episodes to see... We sort of made a commitment to do it three times and then assess.

What is the split between sales of Episode One via Steam and boxed sales?
Gabe Newell: That isn't something that we've talked about. It's something we're keeping to ourselves.
So, how do you manage your relationship with EA when you're selling games via Steam?
Gabe Newell: Our relationship with EA is fine. I think that retailers are really frightened of these kinds of changes in the industry, and I think that we're learning stuff that is going to be very important for them. For example, Steam enables new ways of doing promotion: [ ... ] I think retailers are starting to understand that communicating more efficiently with customers is a way, not of taking money away from them, but of driving people into stores. It's not a way of cutting them out of the equation.

Right now, I think the benchmark game in the industry is World of Warcraft, and every platform could be measured against its ability to give advantage, or fail to give advantage, to building a better World of Warcraft.

One of the primary features is that the moving parts were all in the *plug* (all connectors have moving parts ... those little springy bits that apply pressure and make sure the connection is good and tight). This way the part of the connector/socket system that wears out is in the cable. When something goes wrong (as it will in any mechanical system), you throw out the cheap, easily replaceable component ... i.e., the cable.

This feature can also be used to debug a machine whose operating system has crashed, and in some systems for remote-console operations. On FreeBSD, the dcons driver provides both, with using gdb as debugger. Under Linux, firescope and fireproxy exist.

• Direct IPv6 support by the ISP: Some ISPs support it directly, for example in the UK there are Andrew & Arnold at a retail level, Bytemark for web hosting, and UK6X (an offshoot of BT) at a wholesale level. ISP direct support in theory allows configuring an IPv6 only system, but since most servers are still IPv4 only, it is necessary to configure a dual stack as those ISPs that do support IPv6 rarely also provide an IPv4-to-IPv6 proxy.
• IPv6-in-IPv4 using protocol 41: this can use the convenient 2002 prefix encapsulation for IPv4 addresses and then it is usually autorouted or explicitly configured and routed via a tunnel broker. Except in rare cases it is not supported by consumer grade ADSL/cable gateways, but can be used if one connects to the Internet via a simple PtP connection via a modem (either a phone or ADSL one). Autorouting usually results in poor performance, so registering with a 6in4 tunnel broker is usually better.
• IPv6-in-UDP (or TCP or SCTP, but UDP is much better, which means using the Teredo protocol, supported natively by MS Windows and by Miredo under GNU/Linux, or the AYIAY scheme, supported by AICCU. These schemes rely on the fact that UDP must work for Internet access to happen. The overhead of encapsulating both within UDP and IPv4 is regrettable, but buys simplicity.

The only timer source of use at SME bandwidths are the high performance timers available in post-PentiumPro CPUs. These allow bandwidth estimation and policying at speeds lower than 64K on FreeBSD (with the HZ raised beyond 2KHz) and lower than 128K on Linux (at 1KHz HZ).

At the same time, cards that are considered "horrid" like Realtek 8139 (rl) provide much more interrupts and much more scheduling opportunities. As a result they provide considerably better estimator precision and policy performance. The difference is especially obvious on speeds under 2MBit. It is nearly impossible to achieve a working ALTQ hierarchy where some classes are in the sub-64Kbit range for a 2MB (E1) using Intel EtherExpress Pro (fxp). It is hard, but possible on a Tulip (dc). It is trivial to do this using Realtek (rl).
Linux estimator entry points differ from BSD. As a result, the effects of hardware are less pronounced and system is more dependant on the precision of the timer source. Still, the same rules are valid for Linux as well. QoS on low bandwidth links (sub-2MB) cannot be performed on server class network hardware.

In reality the diagram is likely to contain 16-20 classes for an average company or 5-10 classes for an average home office network.

HTB is not a good choice for an SME or hobby network. Bandwidth will not be utilised fully and the link efficiency is considerably worse. Its only advantage is that its "ease of understanding" and "predictability" are easier to express in a subletting agreement.

• Lots of addresses. Never do NAT.
• Better autoconfiguration, especially nice for temporary and mobile clients.
• Better performance over high bandwidth and/or high latency links (jumbograms, incorporates the common TCP extensions).
• Fairly easy to convert applications to use it, alone or with IPv4, by using getaddrinfo.
• Cheaper to process in high traffic routers.

• It is completely incompatible with IPv4, which means that various encapsulation options are needed to pass IPv6 traffic through IPv4-only networks.
• Its security architecture is based on IPSEC which is complicated.
• Minimum packet length is somewhat longer.
• Addresses are quite long to write.
• Having globally unique addresses without NAT makes it much easier to track usage by PC, which often means by user.
• The dynamic autoconfiguration abilities are sort of pointless if one has to configure the same host for both IPv6 and IPv4 operation, because then the IPv4 must be configured explicitly anyhow.

• It is possible to assign IPv6 addresses where the lower 64 bits are randomly generated, thus creating a fairly strong measure of security via sparse capabilities against networking scanning attacks.
• More weakly, given the relative scarcity of IPv6 targets, security attacks against IPv6-only hosts are rather more unlikely than against IPv4 hosts.

In fact, any process on the system may send events to the init daemon over its control socket (subject to security restrictions, of course) so there is no limit.

BCI's gCORE processors employ a new Grid on Chip architecture which arranges system elements such as processor cores, memory, and peripherals on an internal "grid" network. gCORE is one of the first commercial applications of "network on chip" technology, that has been at the forefront of research at leading universities in recent years. It is widely accepted that traditional bus architectures are no longer valid for large scale system on chip implementations in the sub 90 nanometer geometries. Traditional buses become too large, and too slow to support 16 or more processor cores. Ease of use has been one of the biggest obstacles for the widespread adoption of multi-core processors. BCI has taken an unique approach of incorporating a "Time Machine" module in the chip to dynamically assign tasks to each of the processor cores. By alleviating the need to explicitly program each core, this approach greatly simplifies the software development process.

<cite>Smith</cite> is an engineer, not a smith.

<cite class="corp">Oracle</cite>'s main product is
<cite class="thing">Oracle</cite>, and only an oracle can
predict whether they will release a similarly name Linux distribution.

A <q class="toa">type of discourse</q> can be recognized
because it must be read in a non-<q class="nlq">plain</q> way
to get the correct meaning: in <cite class="thing">French</cite>
the word <q class="fl">chair</q> does not mean
<q>chair</q>, but <q>flesh</q>.

• with the option -dpi dpi in the X server's command line (usually X server command lines are specified in the display manager's configuration file);
• or by specifying the right screen area size in millimeters in the X configuration file's relevant Monitor section's DisplaySize directive.

Every once in a long while, I read about an idea that is a stroke of brilliance, and I think to myself, "I wish I had thought of that, it's genius!" Microformats are just that kind of idea. You see, for a while now, people have tried to extract structured data from the unstructured Web. You hear glimmers of these when people talk about the "semantic Web," a Web in which data is separated from formatting. But for whatever reason, the semantic Web hasn't taken off, and the problem of finding structured data in an unstructured world remains. Until now.
Microformats are one small step forward toward exporting structured data on the Web. The idea is simple. Take a page that has some event information on it -- start time, end time, location, subject, Web page, and so on. Rather than put that information into the Hypertext Markup Language (HTML) of the page in any old way, add some standardized HTML tags and Cascading Style Sheet (CSS) class names. The page can still look any way you choose, but to a browser looking for one of these formatted -- or should I say, microformatted -- pieces of HTML, the difference is night and day.

I'll spare myself the DTDs, but consider two instances/examples of two
hypothetical SGML architectural forms; the first is called MarkDown:

  <ELEMENT TAG=html>

    <ELEMENT TAG=head>
      <ELEMENT TAG=title TEXT="A sample MarkDown document"></>
    </>

    <ELEMENT TAG=body ATTRS="bgcolor" ATTVALS="#ffffff">
      <ELEMENT TAG=h1 ATTRS="center" ATTVALS="yes" TEXT="What is MarkDown?"></>
      <ELEMENT TAG=p>
        MarkDown is a caricature of SGML; it is an imaginary
        architectural form whose semantics are document markup, where
        the <ELEMENT TAG=code TEXT="tag"></> attribute is the one to
        which the MarkDown semantics are attached.
      </>
    </>
  </>

Now this is a monstrosity, but I hope the analogy is clear, even if a
bit forced in some respects.

    <div class="vevent">
      <a class="url" href="http://myevent.com">
        <abbr class="dtstart" title="20060501">May 1</abbr> - 
        <abbr class="dtend" title="20060502">02, 2006</abbr>
        <span class="summary">My Conference opening</span> - at
        <span class="location">Hollywood, CA</span>
      </a>
      <div class="description">The opening days of the conference</div>
    </div>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <style><!--
      dt			{ font-weight: bold; }
      cite.title:before		{ content: open-quote; }
      cite.title:after		{ content: close-quote; }
      cite.location:before	{ content: "["; }
      cite.location:		{ font-style: normal; }
      cite.location:after	{ content: "]"; }
      q.abstract:before		{ content: ""; }
      q.abstract		{ display: block; font-size:90%; }
      q.abstract:after		{ content: "."; }
      --></style>
  </head>
  <body>
    <dl class="vevent">
      <dt id="20060501-20060502">
	<a href="http://WWW.MyEvent/#opening">
	  <abbr class="dtstart" title="May 1 2006">20060501</abbr> to
	  <abbr class="dtend" title="May 2 2006">20060502</abbr></a></dt>
      <dd><cite class="title">My Conference opening</cite>
	<cite class="location">Hollywood, CA</cite>:
	<q class="abstract">The opening days of the conference.</q></dd>

      <dt id="20060503-20060504">
	<a href="http://WWW.MyEvent/#closing">
	  <abbr class="dtstart" title="May 3 2006">20060503</abbr> to
	  <abbr class="dtend" title="May 4 2006">20060504</abbr></a></dt>
      <dd><cite class="title">My Conference closing</cite>
	<cite class="location">Hollywood, CA</cite>:
	<q class="abstract">The closing days of the conference.</q></dd>
    </dl>
  </body>
</html>

Exmap is a memory analysis tool which allows you to accurately determine how much physical memory and swap is used by individual processes and shared libraries on a running system. In particular, it accounts for the sharing of memory and swap between different processes.
To my knowledge, other tools can determine that some memory is shared, but can't determine how many processes are making use of that memory and so fairly apportion the cost between the processes making use of it.

Exmap uses a loadable kernel module to assign a unique id to each physical or swap page in use by each process. This information is then collated and 'effective' usage numbers calculated.

/usr/bin/updatedb

DBDIRS='/etc/updatedb.dirs'

if test -e "$DBDIRS"
then
  grep -v '^[ \t]*#\|^[ \t]*$' "$DBDIRS" \
  | while read DIR DB
  do : ${DB:="$DIR/mlocate.db"}
    /usr/bin/updatedb -U "$DIR" -o "$DB"
  done
fi

if test -e "$DBDIRS"
then
  export LOCATE_PATH

  dbdirspath() {
    DBPATH="$1"; DBDIRS="$2"

    { grep -v '^[ \t]*#\|^[ \t]*$' "$DBDIRS"; echo ''; } \
    | while read DIR DB
    do
      case "$DIR" in
      '') echo "$DBPATH";;
      ?*) : ${DB:="$DIR/mlocate.db"}
	case "$DBPATH" in
	'') DBPATH="$DB";;
	?*) DBPATH="$DBPATH:$DB";;
	esac;;
      esac
    done

    unset DBPATH
    unset DIR
    unset DB
  }

  LOCATE_PATH="`dbdirspath \"$LOCATE_PATH\" \"$DBDIRS\"`"
fi

• Kill all the dæmons that are in the source state but not the destination state.
• Run the once only commands for the destination state.
• Start the dæmons unique to the destination state.

• There is no way to specify simple commands to execute on leaving a run state.
• Every possible run state combination must be well defined.

• Add the ability to specify commands to be executed on exit from a run state, not just on entry (as in once, wait).
• Add the ability to include all the files in a directory.
• Add some way to tell dæmons that a state change is occurring, to avoid stopping them on leaving a state only to restart them on entering the next.

      for (unit = 0; unit < MAX_DRIVES; ++unit) {
              ide_drive_t *drive = &hwif->drives[unit];
              if (hwif->no_io_32bit)
                      drive->no_io_32bit = 1;
              else
                      drive->no_io_32bit = drive->id->dword_io ? 1 : 0;
      }

      {
	      const ide_drive_t *const end = &hwif->drives[MAX_DRIVES];
	      ide_drive_t *drive;
	      for (drive = &hwif->drives[0]; drive < end; drive++)
		      drive->no_io_32bit = hwif->no_io_32bit || drive->id->dword_io;
      }

# vim:nowrap:ts=8:sw=8:noet:ft=conf
#MOUNTP -fstype=TYPE[,OPTION]*                                  :RESOURCE

# Host independent
##################

0       -fstype=ext2,user,rw,defaults,noatime,nosuid,nodev      :/dev/fd0
a       -fstype=vfat,user,rw,nocase,showexec,noatime,umask=077  :/dev/fd0
A       -fstype=msdos,user,rw,noatime,umask=077                 :/dev/fd0

1       -fstype=ext2,user,rw,defaults,noatime,nosuid,nodev      :/dev/fd1
b       -fstype=vfat,user,rw,nocase,showexec,noatime,umask=077  :/dev/fd1
B       -fstype=msdos,user,rw,noatime,umask=077                 :/dev/fd1

sda1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/sda1
sdb1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/sdb1
sdc1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/sdc1
sdd1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/sdd1
sde1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/sde1
sdf1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/sdf1

uba1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/uba1
ubb1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/ubb1
ubc1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/ubc1
ubd1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/ubd1
ube1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/ube1
ubf1    -fstype=vfat,user,ro,nocase,showexec,noatime,umask=077  :/dev/ubf1

pkt     -fstype=udf,user,rw                                     :/dev/pktcdvd/0
udf     -fstype=udf,user,ro                                     :/dev/cdrom
cd      -fstype=cdfs,user,ro,mode=0775,exec                     :/dev/cdrom
iso     -fstype=iso9660,user,ro,mode=0775,exec                  :/dev/cdrom
r       -fstype=iso9660,user,ro,mode=0774,norock                :/dev/cdrom

pkt1    -fstype=udf,user,rw                                     :/dev/pktcdvd/1
udf1    -fstype=udf,user,ro                                     :/dev/cdrom1
cd1     -fstype=cdfs,user,ro,mode=0775,exec                     :/dev/cdrom1
iso1    -fstype=iso9660,user,ro,mode=0775,exec                  :/dev/cdrom1
s       -fstype=iso9660,user,ro,mode=0774,norock                :/dev/cdrom1

# Host dependent
################

home    -fstype=jfs,defaults,noatime                            :/dev/hda2

c       -fstype=vfat,rw,nocase,showexec,noatime,umask=02        :/dev/hda3
d       -fstype=ext3,rw,defaults,noatime                        :/dev/hda6
e       -fstype=ext3,rw,defaults,noatime                        :/dev/hda7

# vim:nowrap:ts=8:sw=8:noet:
#DEVICE         MOUNT           TYPE    OPTIONS                   DUMP PASS

# Host independent
##################

none            /proc           proc    auto,defaults                   0 0
none            /sys            sysfs   auto,defaults                   0 0
none            /dev/pts        devpts  auto,mode=0620,gid=tty          0 0
none            /proc/bus/usb   usbfs   auto,defaults                   0 0

none            /proc/nfs/nfsd          nfsd    noauto                  0 0
none            /var/lib/nfs/rpc_pipefs pipefs  noauto                  0 0

# Host dependent
################

/dev/hda1	/		jfs	defaults,errors=remount-ro	4 1
none            /tmp            tmpfs   auto,mode=0777,size=700m,exec   0 0
none            /dev/shm        tmpfs   auto,mode=0777,size=100m,exec   0 0

/dev/loop7      swap            swap    noauto,swap,pri=8               0 0

# Use 'automount' instead of '/etc/fstab'. Local and remote maps.
af:2345:wait:/usr/sbin/automount -g -t 60 /fs file /etc/auto.fs
aa:345:wait:/usr/sbin/automount -g -t 180 /am file /etc/auto.am

• The MBR volume id, which is the 4 bytes at offset 0x1b8. There are some scattered utilities to set it, but it can be set and reset to a random value with some special options to a recent version of lilo, or perhaps best examined and changed with a binary editor like hexedit.
• The filesystem name, which most Linux file systems support, and is usually a string. Most Linux file systems have a utility that can set it at format or any other time.
• The filesystem UUID, a largish number that most Linux file systems also support, and which is as a rule generated semi-randomly.
• The UUID or name of Linux md RAID arrays or member volumes, or UUIDs for LVM2 physical volumes, volume groups and logical volumes.

The jobs all consist of some simple task that can be performed at your computer -- such as viewing pictures of shoes and tagging them based on what color they are. You get a few pennies per job

Computers suck at many tasks that are super-easy for humans. Any idiot can look at picture and instantly recognize that it's a picture of a pink shoe. Any idiot can listen to a .wav file and realize it's the sound of a dog baring. But computer scientists have spent billions trying to train software to do this, and they've utterly failed. So if you're company with a big database of pictures that need classifying, why spent tens of thousands on image-recognition software that sucks? Why not just spend a couple grand -- if that -- getting bored cubicle-dwellers and Bangalore teenagers to do the work for you, at 3 cents a picture?

$ ls -ld /sys/class/input/mice/dev /dev/input/mice
crw------- 1 root root 13, 63 Dec  4  2005 /dev/input/mice
-r--r--r-- 1 root root   4096 Jul 28 14:56 /sys/class/input/mice/dev
$ cat /sys/class/input/mice/dev
13:63

# size /sbin/udev{d,d.static}
   text    data     bss     dec     hex filename
  63821     940   10496   75257   125f9 /sbin/udevd
 741984    2236   51732  795952   c2530 /sbin/udevd.static

Devfsd provides a naming scheme which is a convenient abbreviation of the kernel-supplied namespace. In some cases, the kernel-supplied naming scheme is quite convenient, so devfsd does not provide another naming scheme. The convenience names that devfsd creates are in fact the same names as the original devfs kernel patch created (before Linus mandated the Big Name Change). These are referred to as "new compatibility entries".

Kernel Naming Scheme
Devfsd Naming Scheme
Old Compatibility Names

mount /dev/scd0 /media/dvdram/ -t udf -o rw,noatime

mount \dev\scd0 \media\dvdram /t:udf /o:rw,noatime

We were confronted with that question with GeForce 256 in 1999. That was on par with the Reality Engine supercomputer that Silicon Graphics used to sell. The fill rate, the performance, the throughput of the chips was amazing. In 1999, we were confronted with that question. I thought we made one of the most important decisions for not only our company but the entire industry. That was going to programmability. As you know, investing in programmability, which ultimately ended up in GeForce FX, made the graphics chip far more programmable. But the cost was so high. It was quite a burden on our company for a couple of years. I would calculate that the amount of profitability lost on GeForce FX was $200 million a year for two years. It was almost $500 million in lost profit. That was a half a billion dollar risk we took going to a completely programmable model.

Where are we betting? We are betting a lot on the cell phone, believing that multimedia will be an important part of these devices. With GPUs, we are betting a huge amount on programmability. GPUs are going to become more programmable, easier to write programs, and support much more complex programs.

We invest $750 million a year in R&D in graphics processing. No other company invests that much in graphics processing today. This is such an incredibly deep technology and there is so much more to do. It makes sense that in the long-term we would work on game consoles as well. The others can't keep up with the R&D that we do. That part makes perfect sense to me.

Microsoft began the Xbox 360 project in late 2002.
In 2003, Microsoft decided it wanted to launch its next-generation console before Sony.
IBM put 400 engineers to develop the Xbox 360 CPU.
IBM taped out (finished the design) of the CPU in December 2004.
ATI put 300 engineers to developer the Xbox 360 GPU, aka Xenos.
ATI finished its GPU design on November 2004.

ATI had 175 engineers working on the Xenos GPU at the peak. These included architects, logic designers, physical design engineers, verification engineers, manufacturing test engineers, qualification engineers and management. The team was spread out between Orlando, Florida, Marlborough, Massachusetts and Toronto, Ontario. The team's size varied during the life of the program -- in fact, we still have about 20 engineers involved in various cost down projects.

Sony paid Nvidia about $30 million for designing the PS3's graphics chip, a fee that was paid out gradually as work on the processor was completed, Nvidia's chief financial officer Marv Burkett said.

Well the point there really is that we now have the chipset, we have CPUs, we have GPUs, and we can mix and match the appropriate level to each of those things to different customer requirements.

The whole company, well the new company wants to give as much choice to its customers as possible, so if you want an Intel CPU with an ATI GPU then great, we'll be happy with that. If you want an AMD CPU with an NVIDIA GPU then we'll be very happy with that as well.

Yeah, we want to be able to package really high performance, low power CPU with a high performance low power chipset and a really high performance low power GPU for mobile, that's really ATI's hallmark.

Over several slides on the topic, Mark laid out the reasons he thinks that PC gaming is being harmed by Intel. He pointed the finger at Intel's integrated graphics chips. Integrated chipsets are often incapable of playing the latest (and certainly next-generation) games at any kind of graphics settings. Despite this, they are wildly popular amongst retailers. According to Mark's figures, 80% of laptops and 55% of desktops (note: he failed to cite a source for these figures) feature integrated graphics.

• They are far slower and with much less memory than the typical midrange or even budget PC gaming graphics card.
• They are integrated into motherboard chipsets which end up in an overwhelming majority of laptops sold and a large number of budget desktops too.
• Laptop sales by now are larger than desktop sales (surely in money terms, and probably in unit terms too).
• Since recent consoles have graphics chips equivalent to midrange or even premium PC graphics cards, most laptops and many desktops are at a huge disadvantage.
• The PC game industry develops games that meant to be released on PCs with recent graphics cards and consoles too, and thus are nearly unsellable on most laptops and many desktops.

they are wildly popular amongst retailers. According to Mark's figures, 80% of laptops and 55% of desktops

Unreal II was released in Feb/2003. The polycounts are in general, very high. In the opening level, polycounts ranged from 20K (thousand) polys to 85K at parts. The outdoor sections had more polys on average, about 45-60K. Indoors, in the training area, the average was 35-38K. There were no enemies in these levels, which allows for more level detail.
The ship that serves as your main base of operations has slightly more detail. Since the space is smaller, it's possible to cram more polys into each area. The count ranged from 40-100K, averaging about 60K.
In the first level with enemies and core gameplay, the count ranged from 15-75K. While in combat, the average was about 25-30K polygons, including enemies. Obviously, when designing heavy combat areas, your level of geometry density will have to fall. In the third level, portions of the level (exterior, beginning) reached as high as 150-160K polys drawn onscreen at once. For most of the core gameplay, however, the count was between 50-80K polygons.

Over 100 million triangles of source content contribute to the normal maps which light this outdoor scene.

Wireframe reveals memory-efficient content comprising under 500,000 triangles.

A stable filesystem that is used by thousands and thousands of people and that isn't actually developed outside of just maintaining it IS A REALLY GOOD THING TO HAVE.

• RedHat has a program of testing and qualification for RHEL and applications running on it. For every additional file system type supported the testing and qualification would have to be repeated, which may be a big problem as to time taken and as to the effort required by the ISVs which are already struggling to qualify their applications on multiple distributions.
• Quite a bit of automated installation and maintenance software would have to be extended or rewritten to support multiple file system types and their subtle differences.
• Lack of backward compatibility with existing customer filesystems, which would have to be dumped and restored into a new file system structure.

It has been noted, repeatedly, that users very much like to be able to get new features into their filesystems without having to backup and restore the whole thing.