The future of the Hobbyist Program concerns me even more, especially since they brought it back inside HP. It would be nice not to have to violate terms etc in order to get fresh PAKs and continue using these systems.
The collected works of smj - Page 11
I'm waiting for when they are considered old and obsolete so I can get one to sit with my NeXT cube and G4 cube.
I think it's a consistent move for Apple - eliminate options, preclude life-extending upgrades, wait for refresh revenue. If performance doesn't drive that in three years, dropping support for it from OSX a few years after that will. It's their model, it works well, so why not?
I think it's a consistent move for Apple - eliminate options, preclude life-extending upgrades, wait for refresh revenue. If performance doesn't drive that in three years, dropping support for it from OSX a few years after that will. It's their model, it works well, so why not?
SAQ wrote:
Ah, Mensys. The company that picked up PDP-11 stuff ages ago.
Perhaps they'll get OVMS now as well?
Perhaps they'll get OVMS now as well?
I think that was Mentec .
"It is by instruction set extensions alone I virtualize my infrastructure.
The extensions intercept I/O instructions, the handlers support abstraction,
abstraction becomes virtualization. It is by the instruction set extensions
alone I virtualize my infrastructure."
(inspired by the Mentat chant written for Piter DeVries by David Lynch)
The extensions intercept I/O instructions, the handlers support abstraction,
abstraction becomes virtualization. It is by the instruction set extensions
alone I virtualize my infrastructure."
(inspired by the Mentat chant written for Piter DeVries by David Lynch)
jwp wrote:
If HP wanted to succeed with VMS, they should have open sourced it and let the community take over the bulk of new development.
Not to bash community efforts, but somebody pays for the heavy lifting of innovation. University or government projects. All the scaled up multiprocessor stuff that SGI paid for, XFS, JFS, yadda yadda. DEC spent good money supporting Linux on the Alpha, and porting to a 64 bit platform under that support really helped mature the kernel. Go ask John "Maddog" Hall about that.
No, HP's lack of vision and investment avoided success with VMS - perhaps with reason, based on customers and market trends, and perhaps not. But slashing your R&D budget below industry norms across the board is a more likely culprit...
jwp wrote:
I never quite understood the great rationale for sudo. The extra keystrokes are annoying...
No competent sysadmin should be barred from using "sudo tcsh" or similar. The point is to not have to memorize all the root passwords, not to try to restrict what full-fledged sysadmins can do. Yes, systems requiring root password to enter single-user threw a bit of a wrench into this, but I still find it plenty convenient. And if your site chooses to use only a few root passwords across many machines, you can at least limit the exposure from every sysadmin typing those passwords all the time, to each using their own all the time. May be futile in cases where that really matters, e.g. shoulder surfing, but it's a small improvement.
jwp wrote:
Personally I prefer "nvi", the BSD reimplementation of Bill Joy's original vi -- no special features, just vi.
We call that "vi" - vim is vim, and I don't care for replacing vi with not-vi. But I acknowledge this is a personal preference.
What vi really has going for it is universality. I prefer to use emacs for serious editing, like coding/scripting. But as a sysadmin I needed to be able to edit files on any random UNIX-like system, and that meant being able to get the job done with vi (and sometimes ed! Thank you Ultrix installer/miniroot...).
Let's say you find, buy, or inherit two or more Altix 350 modules. You connect everything up, but it just won't seem to make it to the EFI shell - in fact it dumps you into the Power On Diagnostics (POD) instead. It might look something like this:
As frequently happens you may have received these modules in pieces, and everything is suspect. Did you get the right RAM? Are the NUMAlink cables good? Was there some other step you were supposed to take? You may have some or all of those issues, but we're going to tackle the fact that the two modules have different versions of the PROM.
If you look at the snippet above you'll see " 001c01#0c: SGI SAL Version 4.43 " which indicates that the brick 001c01 (probably your base module) has PROM version 4.43, whereas the line " 001c08#0a: SGI SAL Version 3.25 " indicates that module 001c08 has PROM version 3.25. Not only is PROM 3.25 too old to work with version 4.43, it's too old to work with version 2.6 of the Linux kernel...
Fortunately there's a way to fix this even if you can't get to the EFI shell, where the documentation from SGI tells you that you can use the "flash" command to reprogram a module's PROM from a binary file. And many thanks to forum member rosmaniac for sharing the method shown below in this thread .
Though nobody has reported seeing documentation on the POD, there is a "help" command, and the help command tells you about another command: the "flash" command. It's not quite the same as the EFI Shell command of the same name - instead of flashing a PROM image stored in a file, it burns the PROM image from the master node into the node you select.
How do you tell the "flash" command which node to act on? You need something called the node's NASID, and there's another command the POD provides - "pcfg" - that will tell you what those are. So first, let's see how the "pcfg" command does that.
First thing I do is run the "version" command just to make sure that the POD is using or part of the correct PROM version.
You can see that when I run the "pcfg" command the output contains two Entry blocks, one for each module. Check the entries for the module name you want (" Module=001c08 "), confirm that this module has the version of the PROM you want to replace (" Prom=3.25 "), and then note the value of the NASID for this entry (" Nasid=2 ").
Now you're ready to flash the newer PROM to the out-of-date module, using the NASID, Make sure that the command you've entered is the one you want, the "flash" command will not ask you to confirm !!
That's it - the newer PROM image from module 001c01 has been written to module 001c08. But it won't take effect until you reset everything:
Note that both modules are now reporting PROM version 4.43!
And now not only are the modules running the same version of the PROM, the system can start the EFI Shell and you can take the next steps in troubleshooting this system.
Code:
SGI SN1 L1 Controller
Firmware Image B: Rev. 1.26.9, Built 02/12/2004 13:59:52
001c01-L1>* pwr up
001c01-L1>
entering console mode 001c01 CPU0, <CTRL_T> to escape to L1
INFO: console subchannel changed: 001c08 CPU2
001c08#0c: SGI SAL Version 3.25 rel040225 IP41 built 12:01:43 PM Feb 25, 2004
INFO: console subchannel changed: 001c08 CPU0
001c08#0a: SGI SAL Version 3.25 rel040225 IP41 built 12:01:43 PM Feb 25, 2004
001c01#0c: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
001c01#0a: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
Probing memory DIMMs ...............Found I/O brick attached to module/001c01/sl
ab/0/node
Probing memory DIMMs ........................ DONE
Initializing memory controller ............ DONE
Testing memory .............................. DONE
Initializing memory controller ............ DONE
Testing memory ............................ DONE
Initializing memory .................... DONE
.Switching to RAM and testing CPU .......... DONE
Discovering NUMAlink connectivity ......... DONE
Found 2 objects (2 chipsets, 0 routers, 0 iochipsets) in 3909 usec
Waiting for peers to complete discovery.... .. DONE
Initializing memory ....................... DONE
Switching to RAM and testing CPU .......... DONE
Discovering NUMAlink connectivity ......... DONE
Found 2 objects (2 chipsets, 0 routers, 0 iochipsets) in 15722 usec
Waiting for peers to complete discovery.... DONE
DONE
tree barrier at module/001c01/slab/0/node timed out
POD entered via MCA, using Cac mode
INFO: console subchannel changed: 001c08 CPU2
POD entered via MCA, using Cac mode
INFO: console subchannel changed: 001c08 CPU0
0 002: POD SysCt Cac> INFO: console subchannel changed: 001c08 CPU2
2 002: POD SysCt Cac> *** module/001c08/slab/0/node has taken an exception! Cont
inuing...
Discovering local I/O on nasid 0 ......... DONE
Checking partitioning information ......... DONE
Erecting partition fences ................. DONE
POD entered via MCA, using Cac mode
0 000: POD SysCt Cac> POD entered via MCA, using Cac mode
2 000: POD SysCt Cac>
Firmware Image B: Rev. 1.26.9, Built 02/12/2004 13:59:52
001c01-L1>* pwr up
001c01-L1>
entering console mode 001c01 CPU0, <CTRL_T> to escape to L1
INFO: console subchannel changed: 001c08 CPU2
001c08#0c: SGI SAL Version 3.25 rel040225 IP41 built 12:01:43 PM Feb 25, 2004
INFO: console subchannel changed: 001c08 CPU0
001c08#0a: SGI SAL Version 3.25 rel040225 IP41 built 12:01:43 PM Feb 25, 2004
001c01#0c: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
001c01#0a: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
Probing memory DIMMs ...............Found I/O brick attached to module/001c01/sl
ab/0/node
Probing memory DIMMs ........................ DONE
Initializing memory controller ............ DONE
Testing memory .............................. DONE
Initializing memory controller ............ DONE
Testing memory ............................ DONE
Initializing memory .................... DONE
.Switching to RAM and testing CPU .......... DONE
Discovering NUMAlink connectivity ......... DONE
Found 2 objects (2 chipsets, 0 routers, 0 iochipsets) in 3909 usec
Waiting for peers to complete discovery.... .. DONE
Initializing memory ....................... DONE
Switching to RAM and testing CPU .......... DONE
Discovering NUMAlink connectivity ......... DONE
Found 2 objects (2 chipsets, 0 routers, 0 iochipsets) in 15722 usec
Waiting for peers to complete discovery.... DONE
DONE
tree barrier at module/001c01/slab/0/node timed out
POD entered via MCA, using Cac mode
INFO: console subchannel changed: 001c08 CPU2
POD entered via MCA, using Cac mode
INFO: console subchannel changed: 001c08 CPU0
0 002: POD SysCt Cac> INFO: console subchannel changed: 001c08 CPU2
2 002: POD SysCt Cac> *** module/001c08/slab/0/node has taken an exception! Cont
inuing...
Discovering local I/O on nasid 0 ......... DONE
Checking partitioning information ......... DONE
Erecting partition fences ................. DONE
POD entered via MCA, using Cac mode
0 000: POD SysCt Cac> POD entered via MCA, using Cac mode
2 000: POD SysCt Cac>
As frequently happens you may have received these modules in pieces, and everything is suspect. Did you get the right RAM? Are the NUMAlink cables good? Was there some other step you were supposed to take? You may have some or all of those issues, but we're going to tackle the fact that the two modules have different versions of the PROM.
If you look at the snippet above you'll see " 001c01#0c: SGI SAL Version 4.43 " which indicates that the brick 001c01 (probably your base module) has PROM version 4.43, whereas the line " 001c08#0a: SGI SAL Version 3.25 " indicates that module 001c08 has PROM version 3.25. Not only is PROM 3.25 too old to work with version 4.43, it's too old to work with version 2.6 of the Linux kernel...
Fortunately there's a way to fix this even if you can't get to the EFI shell, where the documentation from SGI tells you that you can use the "flash" command to reprogram a module's PROM from a binary file. And many thanks to forum member rosmaniac for sharing the method shown below in this thread .
Though nobody has reported seeing documentation on the POD, there is a "help" command, and the help command tells you about another command: the "flash" command. It's not quite the same as the EFI Shell command of the same name - instead of flashing a PROM image stored in a file, it burns the PROM image from the master node into the node you select.
How do you tell the "flash" command which node to act on? You need something called the node's NASID, and there's another command the POD provides - "pcfg" - that will tell you what those are. So first, let's see how the "pcfg" command does that.
Code:
2 000: POD SysCt Cac> version
SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
2 000: POD SysCt Cac> pcfg
NUMAlink Topology: (node 0):
Entry 0: SHub 001c01#0 Chiprev=3 Route=0x0
Module=001c01 Slab=0 Partition=0 Space=RESET
Nasid=0 Flags=0x100000 Syssize=0 Prom=4.43
Port 1 connection: Entry 1 SHub 001c08#0 port 2
Port 1 status: UP NF
Port 2 connection: Entry 1 SHub 001c08#0 port 1
Port 2 status: UP NF
Entry 1: SHub 001c08#0 Chiprev=3 Route=0x1
Module=001c08 Slab=0 Partition=0 Space=RESET
Nasid=2 Flags=0x1110000 Syssize=0 Prom=3.25
Port 1 connection: Entry 0 SHub 001c01#0 port 2
Port 1 status: UP NF
Port 2 connection: Entry 0 SHub 001c01#0 port 1
Port 2 status: UP NF
2 000: POD SysCt Cac>
SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
2 000: POD SysCt Cac> pcfg
NUMAlink Topology: (node 0):
Entry 0: SHub 001c01#0 Chiprev=3 Route=0x0
Module=001c01 Slab=0 Partition=0 Space=RESET
Nasid=0 Flags=0x100000 Syssize=0 Prom=4.43
Port 1 connection: Entry 1 SHub 001c08#0 port 2
Port 1 status: UP NF
Port 2 connection: Entry 1 SHub 001c08#0 port 1
Port 2 status: UP NF
Entry 1: SHub 001c08#0 Chiprev=3 Route=0x1
Module=001c08 Slab=0 Partition=0 Space=RESET
Nasid=2 Flags=0x1110000 Syssize=0 Prom=3.25
Port 1 connection: Entry 0 SHub 001c01#0 port 2
Port 1 status: UP NF
Port 2 connection: Entry 0 SHub 001c01#0 port 1
Port 2 status: UP NF
2 000: POD SysCt Cac>
First thing I do is run the "version" command just to make sure that the POD is using or part of the correct PROM version.
You can see that when I run the "pcfg" command the output contains two Entry blocks, one for each module. Check the entries for the module name you want (" Module=001c08 "), confirm that this module has the version of the PROM you want to replace (" Prom=3.25 "), and then note the value of the NASID for this entry (" Nasid=2 ").
Now you're ready to flash the newer PROM to the out-of-date module, using the NASID, Make sure that the command you've entered is the one you want, the "flash" command will not ask you to confirm !!
Code:
2 000: POD SysCt Cac> flash 2
Flashing node 2
...erasing sectors
................................................................................
................Done.
...copying prom
source address : 0x80000087ffa00000
destination address: 0x8000008fffa00000
size (bytes) : 0x0000000000600000
...programming
................................................................................
................Flash of node 2 complete.
Waiting for all flash operations to complete...DONE.
2 000: POD SysCt Cac>
Flashing node 2
...erasing sectors
................................................................................
................Done.
...copying prom
source address : 0x80000087ffa00000
destination address: 0x8000008fffa00000
size (bytes) : 0x0000000000600000
...programming
................................................................................
................Flash of node 2 complete.
Waiting for all flash operations to complete...DONE.
2 000: POD SysCt Cac>
That's it - the newer PROM image from module 001c01 has been written to module 001c08. But it won't take effect until you reset everything:
Code:
2 000: POD SysCt Cac> reset
001c08#0c: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
001c01#0c: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
INFO: console subchannel changed: 001c08 CPU0
001c08#0a: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
001c01#0a: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
Probing memory DIMMs ..............Found I/O brick attached to module/001c01/slab/0/node
001c08#0c: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
001c01#0c: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
INFO: console subchannel changed: 001c08 CPU0
001c08#0a: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
001c01#0a: SGI SAL Version 4.43 rel051202 IP41 built 02:14:24 PM Dec 2, 2005
Probing memory DIMMs ..............Found I/O brick attached to module/001c01/slab/0/node
Note that both modules are now reporting PROM version 4.43!
Code:
Probing memory DIMMs ............................. DONE
Initializing memory controller ............ DONE
Initializing memory controller ............ DONE
DONE
Testing memory .........................Testing memory .........................
... DONE
.Initializing memory .................... DONE
Switching to RAM and testing CPU .......... DONE
..Discovering NUMAlink connectivity ......... DONE
Found 2 objects (2 chipsets, 0 routers, 0 iochipsets) in 3912 usec
Waiting for peers to complete discovery.... DONE
Initializing memory ..................... DONE
Switching to RAM and testing CPU .......... DONE
Discovering NUMAlink connectivity ......... DONE
Found 2 objects (2 chipsets, 0 routers, 0 iochipsets) in 3910 usec
Waiting for peers to complete discovery.... DONE
DONE
Discovering local I/O on nasid 0 ......... DONE
Checking partitioning information ......... Checking partitioning
information ......... DONE
DONE
Erecting partition fences ................. Syncing EFI var. store (
module/001c01/slab/0/node->module/001c08/slab/0/node) ...DONE
4 CPUs on 2 nodes found.
...........-
..... DONE
Decompressing SAL runtime ................. DONE
Loading SAL runtime ....................... DONE
Decompressing EFI ......................... DONE
Loading EFI ............................... DONE
Altix IO Topology Information
*****************************
Serial Number:R200****
PCI SEGMENT PCIBUS NUMBER BRICK RACK:SLOT BUS CONNECTION TOPOLOGY
----------- ------------- --------------------- -------------------
0x0000 0x01 OPbrick 001:01 01 001c01:slot0:slab0:widget15:bus0
0x0000 0x02 OPbrick 001:01 02 001c01:slot0:slab0:widget15:bus1
EFI version 1.10 [14.62] Build flags: EFI64 Running on Intel(R) Itanium Processor EFI_DEBUG
EFI IA-64 SDV/FDK (No BIOS ) [Dec 2 2005 14:10:20] - INTEL
Copyright (c) 2000-2005 Broadcom Corporation
Broadcom NetXtreme Gigabit Ethernet EFI driver v8.1.1
Seg: 0 Bus: 1 Dev: 1 Func: 0 - SGI IOC4 ATA detected: Firmware Rev 79
Seg: 0 Bus: 1 Dev: 3 Func: 0 - Qlogic 12160 SCSI Controller detected: Firmware Rev 6
(Pun 1,Lun 0): FUJITSU MAP3735NC 5605
Broadcom NetXtreme Gigabit Ethernet (BCM5701) is detected (PCI)
EFI Boot Manager ver 1.10 [14.62]
Partition 0: Enabled Disabled
CBricks 2 Nodes 2 0
RBricks 0 CPUs 4 0
IOBricks 2 Mem(GB) 6 0
Loading device drivers
Please select a boot option
SUSE Linux Enterprise Server 11 SP1
EFI Shell [Built-in]
Boot option maintenance menu
Use ^ and v to change option(s). Use Enter to select an option
EFI Shell [Built-in]
Loading.: EFI Shell [Built-in]
EFI Shell version 1.10 [14.62]
Device mapping table
fs0 : Acpi(PNP0A03,1)/Pci(3|0)/Scsi(Pun1,Lun0)/HD(Part1,Sig3B6D7BAE-C470-476E
-BC5D-F3F974DB367E)
blk0 : Acpi(PNP0A03,1)/Pci(3|0)/Scsi(Pun1,Lun0)
blk1 : Acpi(PNP0A03,1)/Pci(3|0)/Scsi(Pun1,Lun0)/HD(Part1,Sig3B6D7BAE-C470-476E
-BC5D-F3F974DB367E)
blk2 : Acpi(PNP0A03,1)/Pci(3|0)/Scsi(Pun1,Lun0)/HD(Part2,Sig5FEB84EE-6CD6-4687
-8004-D119966337C7)
blk3 : Acpi(PNP0A03,1)/Pci(3|0)/Scsi(Pun1,Lun0)/HD(Part3,SigA5D5C908-46E3-44B9
-984F-B7C3C24FF740)
Shell>
Initializing memory controller ............ DONE
Initializing memory controller ............ DONE
DONE
Testing memory .........................Testing memory .........................
... DONE
.Initializing memory .................... DONE
Switching to RAM and testing CPU .......... DONE
..Discovering NUMAlink connectivity ......... DONE
Found 2 objects (2 chipsets, 0 routers, 0 iochipsets) in 3912 usec
Waiting for peers to complete discovery.... DONE
Initializing memory ..................... DONE
Switching to RAM and testing CPU .......... DONE
Discovering NUMAlink connectivity ......... DONE
Found 2 objects (2 chipsets, 0 routers, 0 iochipsets) in 3910 usec
Waiting for peers to complete discovery.... DONE
DONE
Discovering local I/O on nasid 0 ......... DONE
Checking partitioning information ......... Checking partitioning
information ......... DONE
DONE
Erecting partition fences ................. Syncing EFI var. store (
module/001c01/slab/0/node->module/001c08/slab/0/node) ...DONE
4 CPUs on 2 nodes found.
...........-
..... DONE
Decompressing SAL runtime ................. DONE
Loading SAL runtime ....................... DONE
Decompressing EFI ......................... DONE
Loading EFI ............................... DONE
Altix IO Topology Information
*****************************
Serial Number:R200****
PCI SEGMENT PCIBUS NUMBER BRICK RACK:SLOT BUS CONNECTION TOPOLOGY
----------- ------------- --------------------- -------------------
0x0000 0x01 OPbrick 001:01 01 001c01:slot0:slab0:widget15:bus0
0x0000 0x02 OPbrick 001:01 02 001c01:slot0:slab0:widget15:bus1
EFI version 1.10 [14.62] Build flags: EFI64 Running on Intel(R) Itanium Processor EFI_DEBUG
EFI IA-64 SDV/FDK (No BIOS ) [Dec 2 2005 14:10:20] - INTEL
Copyright (c) 2000-2005 Broadcom Corporation
Broadcom NetXtreme Gigabit Ethernet EFI driver v8.1.1
Seg: 0 Bus: 1 Dev: 1 Func: 0 - SGI IOC4 ATA detected: Firmware Rev 79
Seg: 0 Bus: 1 Dev: 3 Func: 0 - Qlogic 12160 SCSI Controller detected: Firmware Rev 6
(Pun 1,Lun 0): FUJITSU MAP3735NC 5605
Broadcom NetXtreme Gigabit Ethernet (BCM5701) is detected (PCI)
EFI Boot Manager ver 1.10 [14.62]
Partition 0: Enabled Disabled
CBricks 2 Nodes 2 0
RBricks 0 CPUs 4 0
IOBricks 2 Mem(GB) 6 0
Loading device drivers
Please select a boot option
SUSE Linux Enterprise Server 11 SP1
EFI Shell [Built-in]
Boot option maintenance menu
Use ^ and v to change option(s). Use Enter to select an option
EFI Shell [Built-in]
Loading.: EFI Shell [Built-in]
EFI Shell version 1.10 [14.62]
Device mapping table
fs0 : Acpi(PNP0A03,1)/Pci(3|0)/Scsi(Pun1,Lun0)/HD(Part1,Sig3B6D7BAE-C470-476E
-BC5D-F3F974DB367E)
blk0 : Acpi(PNP0A03,1)/Pci(3|0)/Scsi(Pun1,Lun0)
blk1 : Acpi(PNP0A03,1)/Pci(3|0)/Scsi(Pun1,Lun0)/HD(Part1,Sig3B6D7BAE-C470-476E
-BC5D-F3F974DB367E)
blk2 : Acpi(PNP0A03,1)/Pci(3|0)/Scsi(Pun1,Lun0)/HD(Part2,Sig5FEB84EE-6CD6-4687
-8004-D119966337C7)
blk3 : Acpi(PNP0A03,1)/Pci(3|0)/Scsi(Pun1,Lun0)/HD(Part3,SigA5D5C908-46E3-44B9
-984F-B7C3C24FF740)
Shell>
And now not only are the modules running the same version of the PROM, the system can start the EFI Shell and you can take the next steps in troubleshooting this system.
Have you checked the flags set on the system serving the filesystem being mounted as "/" on the client where you're running inst? You may already know there have long been options to allow the remote root user to be mapped to different UIDs, but I wonder if the serving system may have added more fine-grained controls. I can imagine that just as the serving system might have mounted the underlying filesystem with "-o noatime" -- it might have exported it with some new default like "nosetuid". And if it's Linux, I have no idea what SELinux might be doing...
Or of course, it could just be a bug in inst. I don't know how many IRIX systems would have been run in a traditional diskless configuration after the 90s...
Or of course, it could just be a bug in inst. I don't know how many IRIX systems would have been run in a traditional diskless configuration after the 90s...
hamei wrote:
Here's an example from fontconfig :
While here's a listing of the files in neko_zlib
6 ... hmmm. It must come from somewhere. 1+2+5 =8, no. 1+2+5+1=9 ... hmm. 9/2=4.5, no. 9 -1 = 8, no. 9-3=6, hey ! We gottit ! Add all the integers from all the available version numbers together. Now take the sum of the two leftmost digits of the largest version number and subtract from the sum of all versions. Right ? Or does this number come from the Assyrian calendar somehow ?
This has to have some explanation but as I'm not from an alien planet, the clues escape me. And I'm not stoopid enough to expect Techpubs or the Help tutorial to explain it. Been there, done that.
Where's canavan ? he uses this mess, he should understand it .... this is the worst-explained part of making a tardist so if someone could describe it and we got it into the wiki, that'd be a big help for the future. What future ? okay, okay ...
Code:
prereq {
neko.zlib.sw.lib 6 maxint
}
neko.zlib.sw.lib 6 maxint
}
While here's a listing of the files in neko_zlib
Code:
neko_zlib.sw.lib
/usr/nekoware/lib/libz.a
/usr/nekoware/lib/libz.so
/usr/nekoware/lib/libz.so.1
/usr/nekoware/lib/libz.so.1.2.5
/usr/nekoware/lib/pkgconfig/zlib.pc
/usr/nekoware/lib/libz.a
/usr/nekoware/lib/libz.so
/usr/nekoware/lib/libz.so.1
/usr/nekoware/lib/libz.so.1.2.5
/usr/nekoware/lib/pkgconfig/zlib.pc
6 ... hmmm. It must come from somewhere. 1+2+5 =8, no. 1+2+5+1=9 ... hmm. 9/2=4.5, no. 9 -1 = 8, no. 9-3=6, hey ! We gottit ! Add all the integers from all the available version numbers together. Now take the sum of the two leftmost digits of the largest version number and subtract from the sum of all versions. Right ? Or does this number come from the Assyrian calendar somehow ?
This has to have some explanation but as I'm not from an alien planet, the clues escape me. And I'm not stoopid enough to expect Techpubs or the Help tutorial to explain it. Been there, done that.
Where's canavan ? he uses this mess, he should understand it .... this is the worst-explained part of making a tardist so if someone could describe it and we got it into the wiki, that'd be a big help for the future. What future ? okay, okay ...
I thought this was explained in the wiki page on packaging - each package built for inst has it's own internal version number used specifically for prerequisite and upgrade processing. It is explicitly independent of the version of the software being packaged, so Emacs 64.16 could have a package number of 2 when first uploaded to Nekoware in 2015Q1, 3 when rebuilt to use a new libxpm in 2015Q2, etc.
These were the versions that came into play with libidn when I was testing out a beta package of neko_wget, see here: viewtopic.php?f=15&t=16727394#p7360542
Edit : Right, on the Packaging Software wiki page, section on Versioning :
Quote:
Every package will have two version numbers that should never be confused: the package version and the software version.
The package version is assigned to all children of the root node on the first worksheet of the Software Packager. This number is incremented for each build of this package independantly of the software version contained within the package.
For example, the software version of this application is 1.2.3, however the initial package version is 1. If, in the future, another package is built for this software, the package version will be incremented to 2. In this future package, the software version may be 2.0, 1.2.4 or remain at 1.2.3.
Remember: a package's version is independant of the version of the software it contains.
Also, all package version numbers must be equal within a package. If, for example, the execution-only subsystem has changed in a new package, all other subsystem's must have the version numbers incremented, as well. This holds true even if no other subsystems have changed between package versions.
The package version is assigned to all children of the root node on the first worksheet of the Software Packager. This number is incremented for each build of this package independantly of the software version contained within the package.
For example, the software version of this application is 1.2.3, however the initial package version is 1. If, in the future, another package is built for this software, the package version will be incremented to 2. In this future package, the software version may be 2.0, 1.2.4 or remain at 1.2.3.
Remember: a package's version is independant of the version of the software it contains.
Also, all package version numbers must be equal within a package. If, for example, the execution-only subsystem has changed in a new package, all other subsystem's must have the version numbers incremented, as well. This holds true even if no other subsystems have changed between package versions.
It then continues with a section on dependencies using those package versions, though to be sure it isn't all that lengthy.
I just dug up what
rosmaniac
had shared, or else I'd be unable to use more than the base module. Amusingly I bookmarked his thread when I saw it two years ago, but had forgotten all about it - I had to find his tip by searching for anything about Altix' and PROMs...
And for completeness' sake: After I did this to bring one downrev module even with the base module at v4.43, I updated both to PROM 5.04 using the documented "flash -a shub1snprom.bin" procedure in the EFI Shell. Then when I hooked up other CM modules to the base module I was successful using the same procedure described above to bring those 3.25 modules directly to 5.04.
And for completeness' sake: After I did this to bring one downrev module even with the base module at v4.43, I updated both to PROM 5.04 using the documented "flash -a shub1snprom.bin" procedure in the EFI Shell. Then when I hooked up other CM modules to the base module I was successful using the same procedure described above to bring those 3.25 modules directly to 5.04.
Nyebodnye wrote:
The world needs more MIPS Irix up to date software/code maintainers.
Everything seems to have ground to a halt around 2006-8.
Everything seems to have ground to a halt around 2006-8.
There's activity if you look over in the SGI: Development forum ( viewforum.php?f=15 )
Granted it could always use more - thanks for volunteering! Seriously, you're welcome to help out. Best if you take a look at the wiki page on packaging software for nekoware over here . You'll probably have questions - don't be shy but use SGI: Development.
hamei wrote:
smj wrote:
I thought this was explained in the wiki page on packaging - each package built for inst has it's own internal version number
Woo-hoo ! SMJ's been busy on the wiki ! Thanks, fella. That didn't use to be there.
Thanks, but I think credit goes to Regan - I've only made one very small change to that page, and that was about including release notes etc. And I think it was Alver that supplied the original guide...
ClassicHasClass wrote:
This sounds like a DEC joke, actually ...
Nah - Then the doc would have a 2-5-2 part number, probably starting with "EK," and there would be discussion of highly improbable "/FOO=" options instead of jokes about space-separated spaces...
Well, in the interest of furthering education and all that... Here's what I can offer without starting anything up that wasn't already running.
FreeBSD 8.1:
FreeBSD 8.2:
FreeBSD 9.1:
Fedora 18:
OSX 10.8.4:
FreeBSD 8.1:
Code:
soekris# ./proc-count
FreeBSD soekris.crash.com 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Sun Nov 21 18:22:10 PST 2010 [email protected]:/usr/obj/usr/src/sys/TINYBSD i386
1
soekris#
FreeBSD soekris.crash.com 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Sun Nov 21 18:22:10 PST 2010 [email protected]:/usr/obj/usr/src/sys/TINYBSD i386
1
soekris#
FreeBSD 8.2:
Code:
285 io% ./proc-count
FreeBSD io.crash.com 8.2-STABLE-201105 FreeBSD 8.2-STABLE-201105 #0: Tue May 17 05:18:48 UTC 2011 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64
4
286 io%
FreeBSD io.crash.com 8.2-STABLE-201105 FreeBSD 8.2-STABLE-201105 #0: Tue May 17 05:18:48 UTC 2011 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64
4
286 io%
FreeBSD 9.1:
Code:
9 emt% ./proc-count
FreeBSD emt.crash.com 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64
8
10 emt%
FreeBSD emt.crash.com 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64
8
10 emt%
Fedora 18:
Code:
209 abort% proc-count
Linux abort.crash.com 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
4
210 abort%
Linux abort.crash.com 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
4
210 abort%
OSX 10.8.4:
Code:
46 shiny% ./proc-count
Darwin shiny.crash.com 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
Error: unknown platform!
47 shiny%
Darwin shiny.crash.com 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
Error: unknown platform!
47 shiny%
Hold that thought - I'd like to move this into a dedicated thread on Altix OS choices.
(Edit: Link )
(Edit: Link )
It seems like we're building up a decent amount of Altix information, but there are still some frequent questions that might benefit from being centralized. One of those is the question of operating system support for Altix systems. I've incorporated what I could find into the
Altix 350 wiki page
, but it seemed like it would be good to create a thread for reporting and Q&A.
Note that I linked to the Altix 350 page versus the generic Altix page in part because of the differences that exist and are expected to grow between the older Itanium-based models and the newer x86_64-based models. As of this writing most of the questions have been about the Altix 350 and Prism, but this will probably change as more of these machines are released into the aftermarket. So we can expect to overhaul the Altix pages as it becomes necessary.
SGI officially supported the following Linux distros on Altix at different times:
SGI Advanced Linux Environment (based on RedHat Enterprise Linux Advanced Server releases)
RedHat Enterprise Linux (4.x - 6.4)
SuSE Linux Enterprise Server (8 - 11 SP2)
Forum members have reported successful installs of the following additional distros:
CentOS ( 5.5 through 5.9 so far)
Debian (5.x - 6.x)
Scientific Linux CERN 5.x
Support for the Prism platform is a little different if you want support for the graphics cards. It appears that support ended with ProPack 4 (SP4?) according to this thread , which means Prism owners might be able to run SuSE Linux Enterprise Server 9 SP3. However without graphics odds are good a Prism will run any OS that any other Altix 3000-based system will run.
Note that I linked to the Altix 350 page versus the generic Altix page in part because of the differences that exist and are expected to grow between the older Itanium-based models and the newer x86_64-based models. As of this writing most of the questions have been about the Altix 350 and Prism, but this will probably change as more of these machines are released into the aftermarket. So we can expect to overhaul the Altix pages as it becomes necessary.
SGI officially supported the following Linux distros on Altix at different times:
SGI Advanced Linux Environment (based on RedHat Enterprise Linux Advanced Server releases)
RedHat Enterprise Linux (4.x - 6.4)
SuSE Linux Enterprise Server (8 - 11 SP2)
Forum members have reported successful installs of the following additional distros:
CentOS ( 5.5 through 5.9 so far)
Debian (5.x - 6.x)
Scientific Linux CERN 5.x
Support for the Prism platform is a little different if you want support for the graphics cards. It appears that support ended with ProPack 4 (SP4?) according to this thread , which means Prism owners might be able to run SuSE Linux Enterprise Server 9 SP3. However without graphics odds are good a Prism will run any OS that any other Altix 3000-based system will run.
bluecode wrote:
Will OpenVMS run on those?
Will OpenVMS run on an Altix ? I don't believe so, and I would not expect so.
But oddly enough, I was going to reply to ClassicHasClass suggesting he could look at an HP Integrity RX1600 or RX2600 if he wanted to add Itanium to his herd. Played right I think you can have your choice of HP/UX, Tru64 Unix , or OpenVMS on those boxes as well as the FOSS/Linux offerings.
Edit: Brain fart re: Tru64.
astouffer wrote:
What all is needed hardware wise to run a rackmount Altix? Someone on ebay is selling them for $100 each but looking at the pictures there doesn't appear to be a built in ethernet port. Only a serial console and RJ45 console port. So you'd need a supported ethernet card?
You're asking about a specific eBay auction - that listing will disappear forever in a few months, which makes for a lousy reference. But from what I think is on eBay at the moment, you're likely seeing Altix 350 compute-memory bricks with no base I/O at that price, plus S&H. But let me speak to the general topic of minimal Altix configurations for those reading this thread in future...
I think the smallest option would be an Altix 330. That would require at least a single 1U "base compute module" and gets you one or two Itanium 2 CPUs, up to 16GB of RAM, one PCI/PCI-X slot, a slim DVD-ROM, up to two internal SAS/SATA hard drives, and two gigabit Ethernet ports.
For an Altix 350 you'd need at least one unit ("brick") that has a PCI/PCI-X backplane and an IO9 or IO10 installed in the bottom PCI slot. This gives you basic I/O like the Ethernet port and either Ultra160 SCSI (IO9) or SATA (IO10). While the IO9 gives you separate internal and external SCSI busses, the IO10 gives you SAS/SATA ports for internal disks and a handful of serial ports through a small external connector.
For an Altix 3000 system, you'd need at least one C brick (CPUs, memory), one IX brick (I/O), and a power bay to feed them with 48VDC.
With the Altix 450 I believe you'd need one Individual Rack Unit (IRU). You'd need at least one IA64 compute/memory blade and an "IA" or "IA2" base I/O blade in slot 0 of that IRU. That should get you one or two Itanium 2 CPUs, 12 DIMM slots for memory, and then the usual I/O features: one or two SAS/SATA II HDDs, a DVD, two PCI-X slots, two GigE ports, 4 USB ports, etc. It looks like these used modular PSUs designed to run off of typical local residential service, rather than Origin/Altix 3000-style power bays, which is nice.
Aside from the A350 I'm picking this info out of TechPubs, and since the later/larger models are decreasingly likely to turn up at my house any time soon, I'll stop with the 450. But if you're curious, by all means continue reading with the Altix 4700 or Altix UV100 System User Guides.
I'm more familiar with using
DINA
, a packaged VM that's (mostly) configured to handle netbooting IRIX systems. Looking at my DINA VM, it uses ISC DHCPD to handle the bootp requests rather than a literal bootp server, so maybe not helpful as a guide.
However, basics - wha'ts your /etc/bootptab look like? Have you used tcpdump or similar to check the bootp requests and see that there are responses from your FreeBSD server? Checked the logs on that server for output from bootpd? Used a commandline tftp client to verify the server is responding?
However, basics - wha'ts your /etc/bootptab look like? Have you used tcpdump or similar to check the bootp requests and see that there are responses from your FreeBSD server? Checked the logs on that server for output from bootpd? Used a commandline tftp client to verify the server is responding?
Always a good idea to check Ian's guides.
I would still use a command-line TFTP client to make sure you're actually getting the file from the server. Also recommend again checking /var/adm/messages (or whatever) on your FreeBSD server. If you aren't getting messages from bootpd, change the config so you can see what it's doing.
It would also be good to verify that the files survived the copy operation intact. Maybe get a sum/md5 from that fx.64 binary and compare it with somebody's known-good copy. Unfortunately I don't have 6.5.15 - not sure how often they would have changed fx.64 between releases...
I would still use a command-line TFTP client to make sure you're actually getting the file from the server. Also recommend again checking /var/adm/messages (or whatever) on your FreeBSD server. If you aren't getting messages from bootpd, change the config so you can see what it's doing.
It would also be good to verify that the files survived the copy operation intact. Maybe get a sum/md5 from that fx.64 binary and compare it with somebody's known-good copy. Unfortunately I don't have 6.5.15 - not sure how often they would have changed fx.64 between releases...
Code:
dina# pwd
/irix/6.5.19/o1/stand
dina# md5 fx.64
MD5 (fx.64) = fa3037fbb3f5cd0324b98d700149fbbf
dina# sum fx.64
42690 505 fx.64
dina#
dina# cd /irix/6.5.30/o1/stand
dina# md5 fx.64
MD5 (fx.64) = 6d352e91069596304ed1302e6876e9e9
dina# sum fx.64
26953 505 fx.64
dina#
/irix/6.5.19/o1/stand
dina# md5 fx.64
MD5 (fx.64) = fa3037fbb3f5cd0324b98d700149fbbf
dina# sum fx.64
42690 505 fx.64
dina#
dina# cd /irix/6.5.30/o1/stand
dina# md5 fx.64
MD5 (fx.64) = 6d352e91069596304ed1302e6876e9e9
dina# sum fx.64
26953 505 fx.64
dina#
Sorry, I haven't seen a write-up for using DINA with VirtualBox. But there is a Wiki article describing how to setup DINA under VMware player - if you review the steps maybe it will help show where you might be having a problem with your setup.
Using DINA for network installation of IRIX
Using DINA for network installation of IRIX
I could use up to four short NUMAlink cables suitable for use with Origin 3x0/3x000 or Altix 350/3x00 systems. Specifically:
018-1110-00x - 0.75 meter
013-3100-00x - 1.0 meter
Best prices I can find are over $30 per cable shipped, but that's more than current budget allows. If you can do markedly better than that, let me know. If not, no hard feelings but I'll have to wait.
Thanks,
--Steve.
018-1110-00x - 0.75 meter
013-3100-00x - 1.0 meter
Best prices I can find are over $30 per cable shipped, but that's more than current budget allows. If you can do markedly better than that, let me know. If not, no hard feelings but I'll have to wait.
Thanks,
--Steve.
Well, I'm glad progress is being made. You don't need to run an X server in the DINA VM - it's handy, but not required by any means. But see the note about wscons.conf on the wiki page - the console is probably using a Swedish keyboard layout, which might cause some issues.
DINA needs to "see" broadcasts on your Ethernet network - like BOOTP requests, DHCP requests, etc. If it can do that with the NAT settings you've got, great, but that's why it's normally set to bridged networking instead.
As for using network 10 versus network 192.168.1, etc - you've got to use what's right for your local network. Obviously for the write-up you can't know what every reader is using in advance, and perhaps unfortunately I'm not using what 90% of folks will be using. I did try to flag this, but it should probably be discussed as a Before You Start item or something.
Anyway sorry you've been having such a hard time with this. You definitely don't need to have your O2 running in order to sync Nekoware. If the DINA VM can reach the outside world, just use option 1 from the menu when you login as root to get it going.
DINA needs to "see" broadcasts on your Ethernet network - like BOOTP requests, DHCP requests, etc. If it can do that with the NAT settings you've got, great, but that's why it's normally set to bridged networking instead.
As for using network 10 versus network 192.168.1, etc - you've got to use what's right for your local network. Obviously for the write-up you can't know what every reader is using in advance, and perhaps unfortunately I'm not using what 90% of folks will be using. I did try to flag this, but it should probably be discussed as a Before You Start item or something.
Using_DINA_for_network_installation_of_IRIX wrote:
At this point I needed to reconfigure the DINA network addressing.
If you use network 192.168.1, or will be running DINA and your SGI machines on an isolated or bridged network, you may not need to change anything.
Since I use a different network number and wanted to have the DINA appliance reachable from the rest of the network, I needed to change the network settings.
Anyway sorry you've been having such a hard time with this. You definitely don't need to have your O2 running in order to sync Nekoware. If the DINA VM can reach the outside world, just use option 1 from the menu when you login as root to get it going.
hamei wrote:
bluecode wrote:
Is there any way they could make Itanic even less useful than it apparently already is?
They could make it run Windows
They could, but I don't see that they have for Itanium-based Altix - but Windows Server 2008 is certified on the Altix UV 1000. I mentioned before, I was at an SGI & Intel briefing in San Jose and they had Dr. Goh connecting to a big Altix running acceptance tests at a university somewhere and showing us a Windows instance with a multiple terabytes of RAM.
Check it: The 16 Terabyte PC - SGI Bets on Exascale
bluecode wrote:
ClassicHasClass wrote:
Yes, my understanding is that the Altixes (Alticies?) only run the big L, though I wouldn't be surprised if there were a NetBSD port brewing somewhere. (The prerequisite for that is getting the ia64 port working and I understand that is still very experimental.)
Thanks. That's sounds like a colossal waste of time and money for whoever dreamed that one up. Is there any way they could make Itanic even less useful than it apparently already is? The mind boggles.
Just to clarify, there's nothing about Itanium that precludes other OSes. What OS did you want?
Whatever we may think of the decision, SGI decided to only support the IA64 Altix through the Linux kernel. They weren't going to keep IRIX going, and while HP, Sun, et al did ports to Itanium you can't be that surprised none of them opted to port to a competitor's high-end architecture.
FreeBSD has an Itanium port, with ISO images available for download, and I just found an announcement of a working snapshot for the Altix 350 in this post from January 2013. Maybe I'll swap disks and give that a shot, though I expect you'd give up everything from the ProPacks, the Intel compilers, etc. (Build from that post has disappeared, but I found a June snapshot here .)
On this front FreeBSD is ahead of NetBSD - I don't see anything but old, possibly incomplete support for an Itanium emulator in NetBSD/ia64. Not much activity on the ports-ia64 mailing list in the past several years either.
Can you think of any other realistic candidates?
You're most welcome, and good luck with the install. If you notice particular points that could use improvement, whether they're in DINA or the partial write-up we have so far, feel free to post them to this thread. One of these days, if somebody doesn't beat me to it, I'll try to incorporate these and other points into the wiki page.
When I spotted the mecha in the early teaser commercial I was praying for something like
Titan Maximum
. Then was disappointed when they seemed to be taking it seriously in the next wave of ads. Just recently though, when I recognized Charlie Day in the latest commercials, I started to wonder again if it might not be worth taking a chance on it...
As SAQ pointed out, Altix was a scale-up, Single System Image (SSI) platform for High Performance Computing (HPC). If you wanted to have 256 CPUs with serious floating point performance and a fast low-latency interconnect in 2003, this was a good option. Very often for this end of the market programmer time is cheap compared to bringing enough compute power to bear, so if you've got to port your code, or the libraries you use, you do it to make the jobs run within a week instead of a month. And frankly with so much HPC work happening on Linux in loosely-coupled clusters in the '90s, it's not such an oddball choice of OS.
Remember that AMD only released the first 64-bit Opteron in April 2003. Today is there a reason to choose Itanium over x86_64 for net-new systems? Perhaps for some specific cases - and not considering recent vendor games around support for the architecture. But ten years ago, that was a different equation.
And regardless, I started this thread so we could work out what OS options were available for hobbyists who were getting their hands on used SGI Altix platforms today, as they become more common on eBay, etc. Not anybody shopping for new hardware.
PR link announcing Altix 3000 in 2003
Pre-release SGI Itanium announcements focus on Cray, NEC supers (2002)
The Reg on Altix 3k and technical computing (2003)
Remember that AMD only released the first 64-bit Opteron in April 2003. Today is there a reason to choose Itanium over x86_64 for net-new systems? Perhaps for some specific cases - and not considering recent vendor games around support for the architecture. But ten years ago, that was a different equation.
And regardless, I started this thread so we could work out what OS options were available for hobbyists who were getting their hands on used SGI Altix platforms today, as they become more common on eBay, etc. Not anybody shopping for new hardware.
PR link announcing Altix 3000 in 2003
Pre-release SGI Itanium announcements focus on Cray, NEC supers (2002)
The Reg on Altix 3k and technical computing (2003)
Kudos!
If you can get 6.5.3 on there, you can download the 6.5.22 overlays for free with your Supportfolio account (free to register). That would put you in shape to take advantage of Nekoware, if you wanted. OTOH, maybe you'd like to put those CPUs to work and build your own packages...
If you can get 6.5.3 on there, you can download the 6.5.22 overlays for free with your Supportfolio account (free to register). That would put you in shape to take advantage of Nekoware, if you wanted. OTOH, maybe you'd like to put those CPUs to work and build your own packages...
Welcome to Nekochan, LgnLndstrm!
bluecode: Thanks for stepping up, that's what immediately stood out to me as well.
LgnLndstrm: If removing that extra colon doesn't work, have you made some basic connectivity checks - can you ping google.com from the O2 ? Can you reach Yahoo with Netscape/Mozilla? I see you already have nekoware's rsync installed, but did you download it with another machine, then transferred it to your O2? Or did you download it directly to the O2?
bluecode: Thanks for stepping up, that's what immediately stood out to me as well.
LgnLndstrm: If removing that extra colon doesn't work, have you made some basic connectivity checks - can you ping google.com from the O2 ? Can you reach Yahoo with Netscape/Mozilla? I see you already have nekoware's rsync installed, but did you download it with another machine, then transferred it to your O2? Or did you download it directly to the O2?
So I actually shelled out for IMAX 3D on this one, and I have to say... it was fun. Either they managed to pull it off, or I've got permanent damage from trying to figure out Eureka 7 based on a few episodes seen out of order.
vishnu wrote:
Because then I could compile it into my Linux xserver, and I'd be
winning,
and things would suck
less
and that would be
good.
Don't forget to re-enable the network functionality of the X server while you're in there. Seems to be removed/disabled from most Linux distros I run across. (Or I failed the "You must be at least this tall to go on this ride" test...)