There used to be a meme going around to the effect that Linux isn't Unixand you shouldn't call it one (I say 'used to be' because I haven't seenit recently). This has always irritated me; not particularly because I'ma Linux partisan, but because it's such a small minded claim for Unixpeople to make.

When you ask people to support this, they generally point at tworeasons: Linux is not entitled to use the Unix trademark,

For my own future reference if nothing else, here's someproperties relevant to finding what superclass supplies a method :

On super() objects, we have:

This week, we:

• got 10,112 messages from 256 different IP addresses.
• handled 17,652 sessions from 1,101 different IP addresses.
• received 154,723 connections from at least 52,588 different IPaddresses.
• hit a highwater of 10 connections being checked at once.

Volume is definitely down compared to last week , although the connection highwater is the same.In fact I believe this is about the lowest it

One of the interesting issues of working at a university is thatit's amazingly hard to throw obsolete equipment away. Which, inits own way, illustrates how universities are peculiar places , since in a company you can at leasttheoretically get rid of things by throwing them in a dumpster.

Part of the problem is just that relatively scarce money causes peopleto reflexively cling to working (or theoretically working) equipmentlong past its best before date. Even when something's not working, whenyou are babying other

It turns out that there are some situations in Python where it is useful toknow what your superclass is. In particular, itwould be nice for mixin classes to be able to know when they are aboutto call methods on object() instead of on some actual user class.

It would be nice if the objects returned by super() directly exposed away of determining this. Unfortunately they do not, and they don't evendirectly expose what the next superclass is, although given a super object you

The yearly on-campus technical conference has just wrapped up for anotheryear, so it seems a good time to write down my rules of thumb forpicking what conference talks to go to, in the hopes that I'll rememberthem for next year. (This year, I only remembered them about halfwaythrough.)

First, I should note that this is about picking interesting talks, notrelevant ones. With rare exceptions, I don't go to talks at our localtechnical conference to be educated,

On modern machines, the temptation is to make heroically big swap sizes;you'll hardly notice giving your swap 5G or 10G, and it means that youcan just forget about the whole worry that you've madeit too small. But this can be counterproductive, because too much swapcan be dangerous.

The problem with a too large swap is that it lets your system thrashitself more and more into overload, instead of outright exploding andthen recovering. When a system is overloaded enough,

The amount of memory that a program needs in order to actually get somework done is called its Resident Set Size (RSS). The total amount ofvirtual memory a program uses is called various things; ps uses VSZ(Virtual Size, presumably), for example.

The premise of paging things out to your swap space is that mostprograms don't need to use all of their memory all of the time;their RSS will be smaller than their VSZ. The difference can bepushed out to swap space

There is a persistent general belief that your minimum swap size shouldbe two times the amount of memory your system has (sometimes it is therecommended swap size). Much like the myth of multiple sync commands , it stems from a bit of history carried forwardwithout full understanding.

The original Research Unix up through V7 did not have paged virtualmemory (I believe that PDP-11s may have lacked the hardware for it);when it ran short of memory, it swapped out an entire process.