Pointer arithmetic in C is great. The only downside is that it's only defined when pointing to an array (or an item just after the array). That is one giant downside.
Allocate a chunk of memory and you can't use pointer arithmetic. So if you are building a linked list this means you will have to allocate each item in the list separately, even if you know the total length the list will ever have.
Even K&R must have realised this was an annoying limitation. They point this out when they show how to write malloc (K&R2 8.7 Example -- A Storage Allocator)
There is still one assumption, however, that pointers to different blocks returned by sbrk can be meaningfully compared. This is not guaranteed by the standard, which permits pointer comparisons only within an array. Thus this version of malloc is portable only among machines for which general pointer comparison is meaningful.
If only the standard would have relaxed this restriction slightly (e.g. to continuously allocated regions) life would be so much better
Catherine Devlin describes it very nicely:
I finally understand Al-Qaeda's master plan, and it's freaking brilliant. [...] I'm just surprised that we're choosing to participate in the plan. I thought we were on opposite sides?
Why was it ever considered desirable to call a directory containing a __init__.py file a "package" rather then just "module". They are after all simply "modules containing other modules". It's not like that solved some sort of problem was it? But, as sad as that sometimes might be, we can't change the past.
Anyway, people are continiously confused when talking about python and all the module distributions made available on the cheeseshopPyPI by various projects. And now yet another discussion rages over at distutils-sig where they want to re-work this confusion by using unambigous terms. The only possible outcome I can think of is more confusion.
What is so hard about accepting the current status quo? The thing that would help most is documenting something like the following in distutils documentation:
The word "package" is often used to refer to a module distribution, usually it is perfectly clear form the context whether it is talking about a module distribution or a module containing other modules.
Most important thing first: the eLOM console lives on ttyS1 (9600n8). If that gets you going you do not need to read any more.
This works pretty easily, but there's isn't much information about how this works if you don't like using a keyboard and a screen (having these things appears to be the norm for x86 hardware). But the X2200 comes with this "Embedded Lights Out Manager" which, although not as good as the LOM on a T1000, does the job nicely. It allows you to connect via the serial console, IPMI and ssh. So initially I used the serial console to setup the IP configuration of the eLOM and then I could ssh to it (and more importantly sit in a quiter room far away from the rack).
Once inside the eLOM it allows you to connect to the "serial port" of the machine (with the rather obsusucre "start /SP/AgentInfo/console" command, disconnect by hitting Esc + Shift-9). This allows you to see the BIOS settings etc. Now is the time to insert the Debian CD (or netboot or whatever), if inserting the CD you'll just get a blank screen since it's displaying pretty graphics, hitting escape gives you the boot prompt as explained in the Debian installation manual. Now the serial console you're seeing will appear as the second serial port to the OS (this is configurable in the BIOS I think but I didn't play with those settings). So the correct way to start the installation is:
expert fb=false console=ttyS1,9600n8
(or "install" instead of "expert" if you prefer that)
This will start the normal install process you're used too (and which is described in other guides) with the output appearing on your terminal emulator. One tip tough is to enable the installation via ssh when it allows you to select the installer components to load. The serial console is 9600 baud and painting the dialog windows over that is just painfully slow, this is a lot nicer over ssh.
The last thing to note is that debian-installer is smart enough to enable a getty on the serial console you've used for the installation (if fact it doesn't enable any gettys on the normal ttys). But it doesn't append the console=ttyS1,9600n8 to the grub menu, so you'll want to do this yourself if you like seeing the kernel output on the console.