The collected works of Kumba - Page 1

Diego wrote:
Dubhthach wrote:
Diego wrote: Yes, the project is a cool thing, besides the Cosmos hating; more interesting even if anyone could add a work about the O2 platform too... :)


Linux boots on R5K O2's from what i remember, there's supposedly some issue with R10K's one though. I just had a look at the netbsd page and they say they support both R5k and R10k O2's
http://netbsd.org/Ports/sgimips/



Oh yeah. I see. I was in this page a few times. But I'm meaning "Full Support" (i.e.: framebuffer, ethernet, ICE module, MVP...)

...well, ok!, if a good only-framebuffer support is there I'll take it! ;)

I cand put one O2 only to testing purposes....



Hrmm, should watch this forum more often...

Anyways, O2 support in Linux is what I'd call in the semi-functional stage. Nothing near the support of Linux on an indy, but it's functional enough. Here's a quick run-down of what is and isn't supported in O2/Linux:

Supported:
  • SCSI (in PIO mode, MMIO is still buggy last I checked)
  • R5000 (RM5200 Untested, but should work, given Cobalt systems use the same exact CPU model)
  • Meth ethernet
  • Serial Ports, PS/2, Parallel (I've never tested it personally, but in theory...)
Semi-supported (i.e., experimental ...)
  • GBE Framebuffer (I think works if configured for 2MB, But unsure. O2 can run X for remote X sessions, however, I've seen a guy run GNOME on it under Linux via a remote session)
  • PCI Slot (mostly works I think, but still has glitches, and not every PCI card will work (i.e., PCI Vid Cards)
Unsupported:
  • VICE module
  • RM7000 (Issues with ternary cache, I believe)
  • R10000/R12000 (Issues regarding speculative execution; requires a workaround which is currently being explored)
  • Add-on modules (Dual-head, maybe, I'll be getting one in soon, so I can test it. Flat Panel display, unknown, possibly not, but really unsure).
  • Booting off the harddrive. Booting from the Volume Header is doing something funky inside the machine, and arcboot, a IP22 bootloader (originally) made by a debian guy needs some more hammering with a large blunt object before working properly. Thus, only Netboot works, and only when the O2 wants it to work. My experience has shown that depending on the toolchain used (gcc/binutils), the time of day, kernel options, and alignment of the stars all play a role in determining if the O2 PROM will netboot a linux kernel or not. Once it boots though, the machine is rather stable, able to do silly things like survive gcc/glibc compiles rather easily.


Overall, very nice machines. my O2 running Gentoo definitely smokes my Indigo2, Indy(s), and RaQ2 also running Gentoo, and provided I can ever get my hands on an RM5200 for really cheap prices on eBay, I can maybe get it to run even faster. Atleast until R10K/R12K is semi usable, then I'll have to hunt one of those models down. If you're willing to suffer with serial console, O2's run rather stable.

And for reference :)

Code: Select all

# uname -a
Linux valinor 2.6.6-mipscvs-20040510 #1 Mon May 10 22:20:53 EDT 2004 mips64 R5000 V2.1  FPU V1.0 SGI IP32 GNU/Linux

# uptime
03:35:06 up 13 days,  5:11,  1 user,  load average: 0.00, 0.00, 0.08



--Kumba
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
I took my Tezro apart to clean it, and I think I broke something (yeah, laugh at me), but I am not 100% certain. I suspect I damaged a few pins on the I/O connector linking the node board (CPU/memory) to the system board. Does the below output from the L1 seem to agree? I can't find a lot of info on some of the status codes returned by "leds":

Code:
001c01-L1>leds
CPU  A: 0x00: PLED_RESET:  Slave loop (0x00/0x45=okay, solid 0x00=possibly hung)
CPU  B: 0x80:   POD Mode (0x80/0xBC=okay, solid 0x80=possibly hung polling UART)
CPU  C: 0x00: PLED_RESET:  Slave loop (0x00/0x45=okay, solid 0x00=possibly hung)
CPU  D: 0x80:   POD Mode (0x80/0xBC=okay, solid 0x80=possibly hung polling UART)

I am assuming that since just one of the two connectors is damaged, That would explain why CPU A and CPU C are in the PLED_RESET state and apparently never boot up (I think). If I fully deenergize the system, then plug it back in w/o powering up, "leds" has all four CPUs in the PLED_RESET state, but after "pwr u", only CPU B and CPU D enter POD Mode.

Seems like the I/O connector is maybe a $10-$20 part, but I've found just one distributor of of it in the UK. SGI P/N is 9210288. Sent them a message, so hopefully they have a few of these pieces kicking around.

I also inspected the pins on the system board, and they look fine. On the node board, those also look fine. It seems that the "fingers" on one side of the I/O connector are a bit...fickle. I tried bending them back ever-so-carefully under a magnifying glass, but it seems one or more just aren't getting the connection they need for the system to boot up.

Other things I noticed are the 3.3V line is NC in "margin":
Code:
001c01-L1>margin
Supply          State Voltage    Margin  Value Index
--------------  ----- ---------  ------- ----- -----
1.8V     on    1.875V     high     2   0
3.3V     NC    3.492V     high     1   1
2.5V     on    2.626V     high     2   2
XIO 2.5V     on    2.574V     high     2   3
NODE0 SRAM     on    2.600V     high     0   4
NODE0 1.5V     on    1.565V     high     0   5
NODE0 CPU     on    1.297V     high    11   6

But this seems normal, from what bits on Google I've dug up.

And under "power", I get quite a few more "NC" states:
Code:
001c01-L1>power
Supply          State Voltage    Margin  Value
--------------  ----- ---------  ------- -----
1.8V     on    1.875V     high     2
12V     on   12.063V      N/A
12V     NC   12.188V      N/A
3.3V     NC    3.509V     high     1
2.5V     on    2.626V     high     2
12V IO     NC   12.063V      N/A
5V aux     NC    5.070V      N/A
3.3V aux     NC    3.268V      N/A
5V     NC    5.070V      N/A
XIO 12V bias     NC   12.063V      N/A
XIO 5V     NC    5.070V      N/A
XIO 2.5V     on    2.574V     high     2
XIO 3.3V aux     NC    3.302V      N/A
NODE0 3.3V aux     NC    3.285V      N/A
NODE0 5V aux     NC    5.044V      N/A
NODE0 12V     NC   12.063V      N/A
NODE0 SRAM     on    2.600V     high     0
NODE0 1.5V     on    1.565V     high     0
NODE0 CPU     on    1.297V     high    11


Any suggestions other than hunting down that one I/O connector some place? It'll be a while before another Tezro pops onto eBay for cheap. I read somewhere that the node board also fits into an Origin 350, but I don't know if that system uses this same connector or not.

_________________
"The universe is a song sung by a deaf man."
"What is the pearl without the oyster?"
"A shadow cannot live in darkness."

--"Koshisms": Kosh Naranek, Vorlon Ambassador to Babylon 5
Kumba wrote:
I took my Tezro apart to clean it, and I think I broke something (yeah, laugh at me), but I am not 100% certain. I suspect I damaged a few pins on the I/O connector linking the node board (CPU/memory) to the system board. ...

Looks like I managed to successfully bend the pins enough to make contact w/ the other set of pins on the node board. I'll still hunt down a spare of 9210288, but I atleast got the system working again. Glad they moved off of those compression connectors in the Octane/Origin systems. I damage one of those, there's no hope of fixing w/o scavenging off another part.

_________________
"The universe is a song sung by a deaf man."
"What is the pearl without the oyster?"
"A shadow cannot live in darkness."

--"Koshisms": Kosh Naranek, Vorlon Ambassador to Babylon 5
For me, I was somewhere between 8 and 11 years old, and was leaving a military hospital after a basic check up (I'm a military brat). Twas a quiet day on the air base, and as me and my dad were walking back to the car, we saw over in an adjacent parking lot, this large, all-black semi-truck with the big SGI cube logo on the side of the trailer, in silver. I had to go have a look, so, begrudgingly, my dad walked me over there to see if they'ed let us look inside. Sure enough, they had no problem, so we walked up the stairs into one side of the trailer into a fully carpeted room with a whole slew of SGI systems on a table, all running demos and the like. Couldn't touch anything, but I remember they at least had Indy and Indigo2 systems up and running. Spent about 5-10mins just staring at systems I thought were totally out of this world (all I had at home was an IBM PC/XT that booted MS-DOS 3.0 and a Commodore 64), then left and headed home.

That's all it took, and I've made it my life goal not only to acquire as many SGI systems as I have room for, but to try and get a few of them to run and do things. Throw in getting to use an Indy at Epcot Innoventions in the mid-90's, the Nintendo 64 being a joint Nintendo/SGI thing, and my childhood can be partially defined as having an SGI obsession.

Running IRIX on them is easy, but that's a dead OS now (I know a lot of people here don't like hearing that). Unless SGI/Rackable dumps the source code at some point (support ended Dec 2013, so...), it's going to get progressively harder to try new things on these systems. So...Linux! Which is not easy, because I am not a kernel hacker and it can take me days of puzzling over hardware documentation to get something to work that more seasoned programmers could do blind and with one hand.

I only recently started to resurrect Linux on the Octane, and that was tough to try and decipher how the HEART ASIC works, how to update Stan's old code, and how to wire in new Linux subsystem changes to make it all tick. Still stuck on getting SMP to boot, but all in time. Linux/MIPS has been somewhat taken over by commercial interests lately, and there just doesn't seem to be a lot of the old hobbyist crowd around anymore. So maybe I can put some spark back into that side of things soon. I still have to unify portions of the IOC3 driver with the IP27 side, and try to send in patches and not get shredded on the LKML over it. Then, big maaaaaaaaaybe, try to tackle IP35 support.

When people puzzle over why this interests me, I ask them if they've ever met someone that collects old cars. That's when the light bulb comes on and they understand my love for these old machines.

PS, in terms of going for SGI rarities, I acquired this off of eBay recently and hung it on the wall above the Tezro:
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
Now I suddenly want to hunt down an affordable 3d printer...
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
TeamBlackFox wrote: It won't, you're going to break the distro trying to remove it... You can always move to another distro, but I'm sure thats not something you're wanting to do. Gentoo and Slackware currently do not utilise systemd, but thats probably not gonna change. Take it from me - I left GNU/Linux for BSD, not only for systemd, but for other reasons.
Debian has experimantal OpenRC support, the sysvinit wrapper deal that Gentoo developed. Not sure on the status of it, though. Personally, I use "file-rc" in my Debian VM and like it quite nicely. It wraps sysvinit, but gives you the convenience of editing a simple text file to change the start/stop order of services, then you just run Debian's update-rc.d script to make the changes active.

That said, as a current Gentoo developer, I can tell you that we're working towards supporting both OpenRC (default) and systemd in our distro. Choice is a big deal in Gentoo, which can sometimes drive people insane :). When the udev/systemd merger was announced, it was a few of our devs that kickstarted the eudev project off to maintain a version of udev that wasn't slaved to systemd. And in a pinch, you can finagle busybox's "mdev" into working well as a udev replacement, too.


TeamBlackFox wrote: Re sluggishness its probably not the WM, but Systemd. The overhead it adds will slow down your computer. I'd suggest rolling back to Wheezy or else migrating to another distro. There is no reason that a clean OS install/upgrade should be any slower, especially with LXDE.
I've got my beef with systemd as well, but systemd the software apparently runs pretty fast. I haven't heard of slowdowns much due to it. Many of its problems seem to stem more from its design choices, such as it replacing your system logger, cron daemon, init system, and a bunch of other stuff. Plus the whole logging to binary formats that really rankles old-school UNIX people. Now, the people behind systemd....yeah, I won't go there. I think their various statements on the public mail archives on the web speaks for itself regarding their attitude. I plan on sticking with OpenRC as long as feasibly possible. If Linux becomes permanently wedded to systemd in the future...well, we'll just have to see if we get there.


TeamBlackFox wrote: Re desktop environment, CDE is always an option, and with some tuning you can make it look/operate like 4DWM.
I tried the 2.2.1 cut of CDE after someone wrote a basic Gentoo ebuild for it. It's got a *lot* of work ahead of it. I heard the 2.2.2 release came out not long ago, so I probably need to try that soon to see what got fixed. But in a nutshell, CDE is its own X server I believe (right now, anyways), and carries its own copies of common X11 tools, many of which were never compiled with gcc and thus, tend to really irk the compiler off which causes build failures. I hope it sees active development, as I found CDE to be quite usable when I had to maintain an HP-UX server once. And I've grown somewhat attached to the Motif look of it.

As for faking the 4DWM look, since that Maxx desktop project appears to be dead, the other option is fvwm. Supposed to be a very highly-configurable X11 WM, and there's at least one IRIX-like theme that I know of for it.


TeamBlackFox wrote: Also, Enlightenment is another I've used, very appealing but also lightweight.
I think you're talking about Enlightenment 0.16. Enlightenment 0.17 and up basically have an entire framework behind them now which is supposed to be pretty good. So maybe not lightweight anymore. Dunno, haven't tried to install 0.17+ yet. Doesn't seem to get as much attention as Gnome or KDE, though :/
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
I did a net install of IRIX from Linux once. Captain Phil Harris, formerly of the Cornelia Marie on the Deadliest Catch TV show once said "You're not a man until you pull a tooth out with a pair of pliers."

I don't think he ever tried doing a net install of IRIX from Linux.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
Check the real-time clock chip, too -- make sure it's not loose or anything. The Power Active Bar (PAB) pin is used to power down both Octanes and O2's (both use the same RTC), and might be sensitive to powering back up if they're not working right. When I decided to upgrade my Octane's DS1687-5 RTC to a newer Maxim DS17887-5 chip, I discovered that the Octane refused to power on at first, and I had the exact same symptoms as you -- relay click from inside the PSU module when I pressed the power button, but no activity. I *think* the PSU fan spun up, though, but the lightbar didn't light up. Cycled it a couple of times, and even held the power button down for several seconds on one power up, and it just suddenly came back to life after a couple of tries. It's been working fine ever since.

I suspect that since the new RTC was completely blank, maybe the NVRAM on it needs some kind of preparation by the PROM. Not really sure. I wonder if with the age of your Octane, the RTC might be dead. If you manage to determine that, you can use any of the DS17287-5, DS17487-5, or DS17887-5 P/Ns as a valid replacement -- IRIX shouldn't know the difference (the ARCS PROM sure doesn't). The DS17*87 implies the DIP package model and the -5 is the voltage. They're plentiful on Digikey.

Also, never touch the compression connectors on the system board. The oil on your fingers will effectively destroy the pads unless you've got access to a carbon bath or such. If you suspect that is the problem, you can try to hunt down another system board or just scavenge compression connectors off of used XIO boards on eBay. The pads in questions are on both sides of the connector if you go the scavenging route, so you have to be extra careful when removing them and working with them.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
ajw99uk wrote:
TeamBlackFox wrote: It won't, you're going to break the distro trying to remove it...

Hence the ";-)". I'd prefer to stick with jessie, having recently installed it on my parents' ex-XP laptop (figured a few months of "testing" status before going stable would be easier for them than a "dist-upgrade", having had one of those go pear-shaped myself).

TeamBlackFox wrote: You can always move to another distro, but I'm sure thats not something you're wanting to do. Gentoo and Slackware currently do not utilise systemd, but thats probably not gonna change. Take it from me - I left GNU/Linux for BSD, not only for systemd, but for other reasons.

Can't say I tried the full range before settling on Debian; one attraction was the prospect of the same distro on ARM as well as x86 as it seemed to have the most developed RiscPC support ten years ago, and now there's raspbian for the Pi. Ironically I've had more success installing NetBSD on the RiscPC where at least the acorn32 port is still going (nominally at least - not sure how active) whereas the RiscPC branch of debian-arm disappeared several major versions ago (I forget which was the last). But a RiscPC is much better as a RISC OS machine than anything else!

Long way of saying I'm not especially wedded to Debian if there's a better "fit".

Not having full 686 instructions limits things a little among Linuces, and trying to avoid systemd means avoiding Debian-based distros and Arch - so BSD is certainly a contender.
I don't think you have to avoid Debian. systemd is just going to be selected as the default init system upon install. You should be able to replace it with sysvinit after the install is complete. I haven't verified this, but that would seem to fit with Debian's other practices. I know that irritates some, as it's just another step to do after the install (and carries a risk of wasting the time spent doing the install if something buggers up), but it's still better than not having any choice on other distros between init systems.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
wenp wrote: On old 20th-century machines, I've sometimes had to revert to Squeeze and kernel 2.6 for good performance, but I doubt you want to do that. For convenience and stability, I think Debian is still probably your best choice. The Red Hat derived distros have a heavier basic configuration and are hard to slim down. The RPM-based package ecosystem is very limited and awkard compared to Debian.
Agreed, yup. That's one of Gentoo's perks, is the ridiculous amount of USE flags lets you customize virtually every package to only the bits you want. It can sometimes be a time-consuming process, though, and that's not something that RedHat can afford, so they have a very shallow amount of configuration. I.e., want a desktop on a server for management? You'll probably get stuck with music and movie applications as a side-effect because of RedHat's dependence on Gnome and the difficulty of configuring Gnome w/o sound support (which might not even be possible anymore).

Even Debian has some odd dependency requirements at times. I think their mysql package requires Hungarian language support because their mysql maintainer is Hungarian. WAY more configurable than RedHat, though.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
Then there's this surprise:
IRIX for x86 and the 700MHz O2
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
TeamBlackFox wrote: At this point I just hate to see the source of IRIX remain unreleased and bitrotting in Rackable's hands. IRIX under BSD or CDDL would be awesome.
Reportedly, some amount of source code from an early IRIX 6.5 version got dumped on the Internet somehow. Anyone with a brain will stay away from it, though.

That said, SGI probably faces similar problems as Sun did when open-sourcing Solaris many years ago. With Solaris, you basically got the core kernel and basic system elements, but a lot of auxiliary stuff was kept closed-source due to MOA's, NDA's, copyright and other agreements. Not to mention the whole "Who owns UNIX" ordeal that SCO put the world through 10 years ago. As much as I'd love SGI to put IRIX source out under some OSI-approved license, this would likely require a lot of internal effort and man-hours, something that wouldn't have much of a return on investment.

What I'm hoping for instead is that they become more receptive to requests for internal hardware documentation, such as programming info for various ASICs like HEART, BRIDGE, XBOW, XBRIDGE, BUZZ, etc. That'll be of better use to both Linux and *BSD efforts to port code to these platforms by implementing functionality without having to worry about code contamination.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
hamei wrote: In twenty years the open source people could easily have created their own version of 4Dwm. If Rackable freed their willy, the only thing the open source people would do to 4Dwm would be to fuck it up.
Technically, someone in open-source did: MaxxDesktop. Seems dead, though. I sent the only e-mail address I found a note asking if the project really is dead or not, but no reply thus far. If another open-source project tried to re-implement it, I worry they'll do silly things like tie it to systemd or such.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
TeamBlackFox wrote: Maxxdesktop/5DWM is useless for non GNU/Linux users. I for one don't want an awesome interface over a CLI that is anti user by design and pisses all over what makes UNIX great
CLI that is anti-user by design? Do you mean bash?
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
TeamBlackFox wrote: All inclusive of the GNU commandline tools included with a GNU/Linux distro. Examples:

Sed: BSD and Solaris sed don't have issues with syntax, which makes commands portable between them. However I ALWAYS have to make adjustments to the -i syntax when testing on GNU/Linux.

Bash: Slow and adds useless features to a shell ( pdksh and zsh user here )

Awk: GNU Awk, again incompatible with BSD awk and nawk, meaning I have to add checks for each, or else pollute the other systems with GPL code.

While you do point out known issues between the GNU and BSD worlds, I tend to view it a little differently in that...variety is the spice of life. I do not see GNU polluting BSD nor BSD polluting GNU as necessarily bad things. At the core, I think software licensing in general is a pointless thing. But, we're only human, and it's likely part of our DNA that makes us apt to stake ownership over things, including specific arrangements of very transient electrons.

Personally, I would like to see greater integration of GNU and BSD capabilities. There are some things GNU does very well and some things BSD does very well. Competition is a healthy thing.


TeamBlackFox wrote: GCC/binutils: Memory hogging, slow to compile, breaks binaries run as -O3 ( Clang doesn't )

gcc, the C compiler, is actually pretty efficient with C, from my observations. And quick, too. g++, on the other hand, is a bit of a hog, but that's been getting better. I can't speak for the Fortran, Java, Go, or ADA compilers. As for O3, why do you need it? I don't know if Clang does the same optimizations for O3 that gcc does, but O3 generally turns on things like loop-unrolling (inflates code size), -ffast-math (can break floating point and/or precision), and a variety of other excessive optimizations. We've analyzed a lot of this in Gentoo already, because, yes, we've had those users that swear up and down that -O666 really is faster than -O3 (among other things), and it's generally accepted now that -O2 contains a reasonable amount of optimizations. Most code out there works fine with O2 and a few extra switches.

Don't make GNU into the enemy you want it to be. It's not. It's a big world we live in with a lot of people from all walks of life. GNU and BSD adherents and their licensed code have both contributed to the successes of open-source we have today, and there are many more successes ahead for both camps.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
TeamBlackFox wrote: Understand Kumba I'm not against individual developers of GNU/Linux, but all my research points to real innovation coming from BSD, and only questionable enhancement from the GNU/Linux side that takes several attempts to get a half-working solution.

I think both camps have had their moments of innovation. gcc was, by and large, the first freely-available C compiler. Though, gcc largely worked out fine until GPLv3, whose more restrictive licensing led Apple to kickstart the LLVM project and then Clang. Ironically, I see that as a good thing because now Clang's existence gives gcc some competition. And both teams do work together from time-to-time, too.

On the BSD side, you've got the old debacle of XFree86 when they switched to that extra-clause BSD-like license that caused everyone to run back to the original X.Org. This led to XFree86 being abandoned and a lot of problems that had been "stuck" for a long time (namely its build system and lack of modularity) getting addressed in the X.Org releases. We even have X11R7! How long were things stuck on X11R6? This also led to spinoffs like Wayland and Unity. I have yet to check them out, but again, more competition and different projects trying different ideas out.

Mind you, there's also the case of too much competition. There's a thin line between too little and too much competition. This is why on one hand, I welcome systemd, but on the other hand, dislike it. But more on that later.



TeamBlackFox wrote: Device handling: Devfs did need replacement, but HAL made the situation worse with its constant polling and dirty hacks. Udev fixed the problem mostly, but now that's tangled into Systemd. Before you say eudev, I used Arch prior to moving to BSD, and by far it was the best GNU/Linux experience to date. I used eudev, sysvinit and netcfg for device, init and network over systemd for all three. However this broke half of the packages for Arch, made the Arch build system break, and D-bus constantly misbehaved. Point is, I'd love to use a solution that WORKS and doesn't involve me going into Gentoo level of difficulty ( BSD is far easier than Gentoo to setup, even with 'shortcuts' ) On BSD, they now have devd, which can use HAL, but isn't made to, and choosing to not use something like HAL won't break half your packages/ports.

To be honest, I like FreeBSD's idea of device management. You've got the kernel piping out a stream of text data to /dev/klog and a listener can monitor that stream and handle device events as they come through. That's how I saw it explained in a nutshell, anyways. And their devfs/devd rule syntax looks a lot cleaner than what you use in udev. It fits with my idea of the kernel dealing with the actual hardware notifications (which is kind of the kernel's job) and allowing a user-space daemon to manage setting up that hardware. I think it'd be interesting to see that ported to Linux, if someone ever gets the incentive to do so.

HAL, I don't know much about because I never used it. I am very minimalist in my approach to systems, and I prefer to start small and build up, instead of start with everything and strip it down. This is why Gentoo works well for me (and in a pinch, Debian). While I wish your experience with Arch was a lot better, I believe they have cast their lot in with the systemd crowd and so, that will be your only option as an init package. But, given the complexities of maintaining a binary-only distro, I'm not entirely surprised at their decision, either. A lot of Linux distro developers, like their BSD counterparts, aren't paid for this, so sacrifices have to be made somewhere.



TeamBlackFox wrote: Init system: Sysvinit, if configured BSD-style, didn't have any serious problems other than the method of action, Runit and OpenRC works, but Systemd doesn't! Why the hell does my server need D-BUS if its just a frigging webserver??? Literally on OpenBSD I can fire up NGINX within minutes as it is in base, add my files after some config, good to go!

You will find me in agreement on this. But, like gcc and clang, I think systemd's positive aspect (if it is possible for it to have one) is that it added competition. Sysvinit was great for many, many years. It's a pity that OpenRC wasn't more widely known about years ago -- maybe that would have put off systemd's creation a bit longer.

But sysvinit's main flaw was its lack of parallelization and to a lesser extent, a dependency-based startup model. OpenRC largely fixed the latter problem in a sane fashion, but the parallelization bit is a tough nut to crack with a shell language. Personally, I don't care much for parallelization. I use Windows in my daily work and it's startup speed leaves a lot to be desired. My Octane can boot Linux in about ~20 seconds, and that is plenty fast for me. People pining for 2-second bootup times befuddle me, but humans are weird, yo.

So that's why we have systemd now. As a technical project, it's refreshing to see new ideas being tested out, and maybe we'll see core sysvinit development fire up again as people finally have an incentive to go back and look at the old code. What I don't like is the culture around systemd. Many of its proponents could use a few lessons in tact, at a minimum. Especially needing to accept that not everyone wants or needs systemd's capabilities. Here's a fine example of the arrogance that pervades the systemd culture:

https://wiki.debian.org/Debate/initsystem/systemd :
Systemd is becoming the de facto standard init system for Linux. It replaces the venerable SysV init with a clean and efficient design, and brings a stream of new functionality that makes the life of users, administrators and packagers easier. It is better than existing alternatives for all of Debian’s current use cases:

  • Application and infrastructure servers benefit from reliable and easy service management, cleaner dependencies, service monitoring, security features and global system integration.
  • Desktops, laptops and session servers benefit from session management, multi-seat, unified system interfaces, as well as integration with udev, D-Bus and other system services.
  • Embedded systems benefit from speed improvements, shell-less design, ability to remove optional components, and lower memory footprint.

Systemd represents a leap in terms of functionality, one that is comparable to Debian’s existing improvements over other operating systems. People are starting to expect this functionality when running Linux, and missing it could, in the long term, make Debian lose its purpose.
That last line, especially. The veiled, unsubstantiated threat of future doom if they don't switch to systemd. That's an eye-roller if I ever had to pick one.



TeamBlackFox wrote: D-bus: I'm gonna get flak here, I know, but I don't see the point. Sockets by themselves work fine for IPC, and while adding a common way for processes to communicate is cool, why not just implement message passing as DragonFly BSD is doing? AmigaOS proves the message passing model works.

Another component that I avoid using if I can. I believe there is talk of migrating a portion of dbus into the Linux kernel (kdbus), but I don't know the status on that. I've half a mind to wonder if maybe this isn't something IPv6 can solve. With trillions upon trillions of addresses available, just take advantage of the fact that most systems have a loopback device and use the existing network stack to dynamically assign each application a device address. Then just pass messages using whatever transport protocol of choice you want. But, eh well.



TeamBlackFox wrote: In any case, I have no problem using MIT/BSD licenced kit from the GNU project or any of the GNU/Linux distros, as all of it I have come along is innovative, good material. The same can't be said for GPL stuff, its more like, there's nothing better to use, if you have to use it. Nobody uses it because they want to. Nobody on the OpenBSD project builds code for VAX, Alpha or another dead architecture on GCC because it's good, it's because there's no real option!

And sometimes, nothing better to use is the case because no one cared enough to make something better. Humans can be an amazingly lazy species sometimes, and "good enough" often works very well for large numbers of people. If more people would stop accepting "good enough" and be willing to go those extra few miles to make "good enough" into "fuck yeah, Seaking!", you'd see a lot better code and projects out there.



TeamBlackFox wrote: In regards to how GCC mangles code under -O3, all I know is, when I'm running code through -O3 to ensure I've not overlooked any bugs at that level of optimisation, the same program run under clang doesn't fall apart when run at that high level of optimisation, but GCC does, quite frequently. I don't care to learn enough x86 asm on my server to understand the code, all I care is: Does it break?

Odds are likely it's not the compiler that's breaking, but you're just compiling code that had certain assumptions built in. The most common assumption being no one uses anything above -O2. I don't know if it's still this way, but it used to be that if you joined the #gaim channel on freenode (what pidgin used to be called), and started asking questions about why something wasn't working, and then the devs find out you're a Gentoo user, they permabanned you, no questions asked. Usually because that user used -O3, along with a whole bunch of other obtuse gcc flags, built the code, and then assumed that the code was just broken, not their choice of flags, and the devs just wouldn't have any of that. They coded things to be used with a certain optimization level and anything else is broken and wrong.

This isn't something specific to gaim/pidgin either. FreeBSD has dedicated an entirely separate variable for compiler optimization flags for the kernel ($COPTFLAGS), and they're pretty clear that -O2 is the highest you should go. I'm sure other examples exist out there, too.

Keep in mind the insane job that a compiler has to do. In the case of gcc, it's got to take a largely architecture-neutral coding language (C) and output architecture-specific assembler code for a dizzying number of different machine architectures. And with MIPS being a prime example, an even further dizzying number of ABIs and ISAs. You're going to get bugs in there at some point (as my discovery of the R10000 regression in PR61538 is a key example of).

Clang is a new approach to the same old problem. It has an advantage in that, it is able to avoid many of the mistakes that gcc has encountered and solved over the last 20+ years. But in time, Clang will encounter its own problems and they'll have to be fixed. Maybe gcc will borrow that fix, or maybe gcc will be what inspires or contributes the fix? Time will tell.



TeamBlackFox wrote: Let me say this though: the GPL's viral nature as a licence that anything it touches must be GPL too is the single most aggravating thing about it. I have less of a problem, significantly less, with the LGPL and CDDL. What pisses me off further is that some people take pride in that and say it's in the name of freedom. By that statement, they're no better than the police officers who abuse people in there custody and say it's in the name of freedom. If the GPL backed off that then I'd just licence my contributions under the ISC licence and build a patch against the original program.

And this is the point upon which many disagreements have been discovered. GPL and BSD are both free software licenses, in a sense. I think what it boils down to is that GPL is more idealistic in its design than BSD is. GPL wants to ensure that code remains free, open, and accessible. GPL wants to make sure that everyone's contributions are recognized. It's a very.... kumbayah kind of thought process. Borderline socialism if you ask me.

BSD, I think, is more designed by realists. BSD places extremely few restrictions on the code developer, so it is arguably the more "free" license. It prefers that code remain open and free, but it doesn't require it. It's a very relaxed license, in my opinion.

Also, if you look around, you'd be surprised at the number of camps that hijack the word "freedom" for their own use. Freedom is an idea that can never be truly realized by an organic species that desires to survive. True freedom is chaos, anarchy, high entropy. That is not compatible with life as we know it. Freedom with restrictions placed upon it, now that is something that a species like ourselves can survive in. It's just a question of how many or how few restrictions do you place. Everyone has different tolerances of freedom. Some like things to be highly ordered, rigid, stoic (less freedoms), while others like things to be very fluid, dynamic, spontaneous (more freedoms). Some like salt and pepper on their eggs, while others like Tabasco sauce. Some like the GPL and others like BSD.

So next time you see someone chortling on that the GPL is more (or less) free, ignore them. Don't let it get to you. Enjoy whatever it is that you like the best.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
hamei wrote:
vishnu wrote: Linux has something better ...

And the Space Shuttle is an excellent vehicle for a trip to the grocery store :P

Eh, I think the Crawler-Transporter that used to take the shuttles out to the launch pads works better. At least parking isn't a problem...
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
Ironically, I *think* NetWare 6.5 is affected, too. It comes with bash-3.0 and several other GNU/BSD utilities built as NLMs (NetWare Loadable Modules). I tested the original CVE-2014-6271 exploit on it, and it doesn't work immediately, but if you exit and reload BASH.NLM, it seems to suddenly process the environment var set and partially execute the bug. Haven't seen a patch from Novell yet to address the issue. I might go badger them just for fun...
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
hec Compucases are well-built, solid PC cases. Not meant to be lookers, but if you just need a solidly-built case, poke around their offerings some:
http://hecgroupusa.com

I wish the 6AR6BB2F was still available so I could buy another one or two more. That's what both my desktop and Linux machine are built with. It's an extra-wide case so there's more room for managing cables and such. Here's the old listing on Newegg:
http://www.newegg.com/Product/Product.a ... 6811121066

Get yourself a decent hardware SATA RAID controller (not that onboard crap) and drop one of these into two of the 5.25" slots:
http://www.startech.com/HDD/Mobile-Rack ... TSASBAY3BK

Then add three single-platter spinning HDDs, And you'll have a pretty sturdy system.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
jwp wrote: ...Big business software has mostly moved to Java, or to the Web...
This is the part that makes me sad. This shoehorning of "The Web" as some kind of OS, and Java as if it was a C library. You can barely get by loading a Java app up these days without about five different security nag screens bugging you, then browsers force-disabling Java when a new version comes out, then the Java update resetting your security prompts when you tell it not to. Makes me miss the days of Geocities for hosting, <HR> & <BLINK> as attention-getters, <FRAME> for layout, and Crescendo to play a snazzy MIDI file. Simpler times.

jwp wrote: Then everyone will sail away into the future with Plan 9...
8-)
I actually just installed 9front into a VM the other day. I don't think I have fiddled with an OS that weird/different since my first crack at NetWare a few years ago. 9term needs a bit of work, and that noscroll functionality has got to bloody go, or at least become optional. But outside of that, it's a neat OS.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
uunix wrote: Advanced Novell NetWare 286 v2.0a

Now there's a classic. I don't think you can even run that in an emulator because most of those only go down to the i386 level.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
nongrato wrote: Very cool, thanks for sharing!

Btw, does anyone have Octane ads and posters?

No ads, but I have an Octane refrigerator magnet on my fridge, and a mini-Octane keychain in storage some place. Also an inflatable O2.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
vishnu wrote: At one point a few years ago he seemed to think that SGI was going to let him start releasing at least some of the source but apparently that never happened...

If this was true, you'd think they wouldn't mind releasing some hardware documentation on the older systems and their chips, like what's on the Indy, O2, and Octane. I tried contacting SGI support for R14k/R16k docs, and they really didn't know what I was talking about. Instead, they directed me to see what is available on Techpubs.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
TeamBlackFox wrote: I shudder to think what he did with it.

Hopefully he passed it on, whole, to someone else in some form. I saw an eBay auction years ago of a nicely-decked out Octane. Someone won it for about $500 or so. About eight hours later, the *same* Octane was parted out on eBay by that buyer, each part priced astronomically above what he paid for the machine as a whole. I was able to compare the pictures of one of the parts to the original listing, and the S/N's matched up. Twas quite sad :/

It is for those people, I am certain, that Dante created a tenth circle.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
I am probably shooting myself in the foot on my own chance at getting this, but I want to make sure it goes to a good home and not parted out on eBay:
http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... 1205472826

It's an Indigo Elan "Spielberg Edition", and judging by the "1/1" marking, this is the only one of its kind. See the auction for the other details.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
R-ten-K wrote:
Kumba wrote: If this was true, you'd think they wouldn't mind releasing some hardware documentation on the older systems and their chips, like what's on the Indy, O2, and Octane. I tried contacting SGI support for R14k/R16k docs, and they really didn't know what I was talking about. Instead, they directed me to see what is available on Techpubs.


Unfortunately, I'm willing to bet a lot of those HW docs are long lost. :cry:

Nothing is ever truly lost. It just waits to be found again.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
chicaneuk wrote: Did it go to anyone on here?

Not me. I got sidetracked and my programmed snipe failed to fire because whoever that one bidder is cranked the price up past the snipe value before I noticed.

Dante needs a tenth circle for people like that...
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
hamei wrote: The graphics were far superior to anything available in the DOS world, while being much cheaper than the Evans & Sutherland stuff.

People in the PC demo/mod scene in the early 90's were doing some *insane* things with low-grade 386/486 hardware. If you haven't heard of nor seen Unreal ][ - The 2nd Reality, take ~15mins out of your day and watch it here:
http://www.youtube.com/watch?v=rFv7mHTf0nA

Wikipedia entry (has links to a download location and source code):
http://en.wikipedia.org/wiki/Second_Reality
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
pentium wrote: Wasn't the majority of the x86 demoscene heavily reliant on a assembly and hardware constraint? It was the era when clones were still everywhere.

I believe C and ASM were the preferred choices of programming languages. Looks like Unreal ][ also used TurboPascal as well. They used DOS' memory manager, but basically wrote their own video and sound drivers to directly interact w/ the hardware. Still very impressive to pull off some of the effects that they did on low-end hardware. 3D Mark (FutureMark) and other companies were founded by former members of Future Crew, and you can still find Purple Motion (Jonne Valtonen) composing music in the form of symphonic recreations of classic video game music:
http://www.youtube.com/watch?v=IV0ycCKRT1E
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
Pontus wrote:
Kumba wrote:
chicaneuk wrote: Did it go to anyone on here?

Not me. I got sidetracked and my programmed snipe failed to fire because whoever that one bidder is cranked the price up past the snipe value before I noticed.

Dante needs a tenth circle for people like that...


So you didn't get it because you were outbid? sounds like a proper auction to me.

eBay hasn't had "proper auctions" ever since they instituted that "anonymous" bidding system. I used to be able to look at bidder's profiles and past wins to gauge if I stood a chance competing with them or not. Actually went up against 3ddoc a couple of times on a few auctions and lost sorely because he runs a business selling SGI gear, whereas I'm just a hobbyist/collector. So I learned to watch out for him, and if he put up a bid on something, that meant it was better for me to move on to other items. Now, it's just like everyone's got a bag over their head so you can't really know whose bidding against you. Some might like it better that way, but not me. I like to know who my competition is.

If anything, I view eBay now more like an open-market bazaar with on-the-spot bartering.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
jpstewart wrote:
vishnu wrote: Is classic shell a separate install or a mode of the existing windows explorer?

It's a separate (third-party) install. http://www.classicshell.net/

I've been using ClassicShell for the last five years. Works great on everything from Vista (NT 6.0) to Windows 8.1 (NT 6.3), including the server releases. Still baffled by the "flat" look in Win8/Win2012R2. The border is too thick, but there's a registry setting that can fix that. I am curious to see what MS does to Win10's start menu, now that they've come to their senses (somewhat) and added it back. Though, I suspect I'll find something annoying about it and just install an updated ClassicShell to cover it up.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
vishnu wrote: Windows Explorer is a great file manager but really there's no functionality it has, even in Windows 8, that you can't get from a host of Linux or Unix filemanagers, or for that matter even from the 10-years-since-it's-been-updated TkDesk for graciousness sake... :|

Hmm, I'll have to play with TkDesk some. I've been designing a small app in Python/Tkinter and while it looks great in Windows, it looks like crap on Linux. I've been pondering trying to use the Motif theme across both Windows and Linux for consistency (and a homage to old school UNIX), but never found solid code examples for this. I think TkDesk might just offer that. Have to brush up on my Tcl, though...

Also, the ability to use regular expressions in filename searches is something Explorer has never had. I don't know why the hell MS keeps trying to force Windows Search down their user's throats. Popping open a cmd.exe shell and running "dir <file mask> /s" works 10x faster than Search ever has, especially on mapped network drives located halfway across the country.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
If I am not mistaken, I think the VW systems are the reason why the NT kernel uses ARC naming for raw device access. MS included some of the ARC (note, ARC is little-endian, ARCS is big-endian) standard in NT, especially for NTLDR and BOOT.INI (until they moved that into the registry in Vista).

I also believe that, hardware-wise, the VW's, at least the 320, is based on the same shared memory architecture as the O2. Both use the Graphics Backend chipset (in Linux, the gbefb driver). Not sure if the same applies to the 540, though.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
ClassicHasClass wrote: And here's oulu saying hi to its previous owner (NetBSD can define a /dev/lcd):

http://www.floodgap.com/iv/1864

It's amazingly very power thrifty. At idle, 16W, at load, 21W. But it's essentially just a 150MHz R5K and NetBSD doesn't detect any L2, so stuff like Texapp brings it to its knees. My slow-by-any-other-standard 200MHz PPC 604e in the Apple Network Server runs rings around it, and the 1MB L2 probably makes more difference than the clock speed. On the other hand, the RaQ uses 1/6th the power.

And it uses EDO RAM. Effectively, a RaQ2/Qube2 is just PC motherboard with a QED RM5231 MIPS CPU, a Galileo (now Marvell) Northbridge, and a VIA 686B Southbridge. Linux can even detect the presence of USB1.0 on the southbridge, but there aren't any visible leads to wire a port up for it.

Btw, the firmware on a Cobalt RaQ2 and Qube2 is a butchered Linux-2.0.34 kernel. I believe the Linux bits were used for the NFS booting when holding the buttons down on the front panel and all. Some missing kind of proprietary blob of code that hooked into this butchered kernel that actually set the hardware up, then the whole thing would get unloaded when the kernel on the disk was booted. It's a crappy firmware, too. Some weird limitations, like a maximum kernel image size of ~617KB, which is why it took a lot of work to finally get Linux 2.6 to boot on the damn thing. Peter Horst wrote a brand-new firmware from scratch, called CoLo (CObalt LOader), that can either replace the original firmware entirely, or be chainloaded by it. It's nicer, better, and should boot Linux and the BSDs (though I never tried the BSDs):

http://www.colonel-panic.org/cobalt-mips/
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
TeamBlackFox wrote: I am in the market for these for my Octane2. I am located in the US, east coast. PM me if you have these.

These things are bloody rare. I finally found a pair on eBay a few days ago, and with 6x 128MB modules, it gave my Octane a nice bump to 3.5GB of memory, but Linux seems to have issue with that much memory on this platform. Hard lockup (not even a panic/oops message) on any heavy disk I/O activity, which points the finger at XFS, MD-RAID, qla1280, generic SCSI, the I/O scheduler (though I tried two of them), or the block layer (or any combination thereof). Not really in the mood to debug that by putting my filesystem at risk, so I pulled them for now until I can attempt to figure out what's wrong w/ the IP30 memory code.

That said, if you're wondering what these chips look like for a visual reference, look for memory modules that have "stacked" chips. I don't mean the dual PCB 128MB modules. 1GB modules literally have two memory chip stacked on one another on a single PCB module.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
Trippynet wrote: Ian has them listed on his site as in-stock, but at £225 for two 1GB modules, they aren't cheap!

I got mine at a steal then. $130 for the pair.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
I've got an RM5200 stashed in the closet somewhere. I'd be interested in one of these to see how well Linux plays with it. I assume this RM7k chip wouldn't have any L3 cache available, right? I know on the 350MHz RM7k, the L3 cache is externally mounted on the CPU board.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
TeamBlackFox wrote: The IR Graphics are a league above IMPACT and VPro. I've spent a little time on an Onyx2, IR3, quad 400MHz and 8GB RAM. Its very fast, but what IR is good for primarily is for is high performance 3D visualization and rasterization, you wouldn't want an IR workstation as your everyday system, the desksides consume over a kW of power, and the rackmounts require 220V power. Plus my friend told me an Onyx2 weighs in at over 300lbs.

I've been running my Onyx2 for the last 3 weeks straight compiling Gentoo stages. Pulls about ~700W (on 120VAC) if I remove two of the drives. I imagine that jumps up a fair bit if I could actually engage the Kona graphics under Linux, though, but I am pleasantly surprised with it as a buildbox. Electric bill will average my usual for the summer months, so its manageable. And for a machine of that size, it's amazingly quiet.

Most of the weight in an Onyx2 appears to be in the PSU and fan tray. Once you pull those two components out, the thing is surprisingly agile. Pull some of the boards if you want to further lighten it up. The wheels screech like the tortured cries of a hundred suffering children, though.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
hamei wrote:
Kumba wrote: The wheels screech like the tortured cries of a hundred suffering children, though.

Mm, there's this stuff called "oil" ? :D

I have carpet...gravity would invariably do its thing and I'd wind up with oil stains in the carpet. Need to just hunt some thick grease down at some point. Though I don't look forward to getting the bottom carrier apart again to get the grease where it'd be the most useful...
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
ivelegacy wrote: let me say "sorry", really "sorry".

A lot of time ago (2009) I was given an IP30 equipped with 8 modules of 1Gbyte each, for a total of 8Gbyte of ram (1), but, as the fact the Xbov v1.4 is not well known in linux (i am afraid its documentation is still under NOX), i had to remove 6 modules for a total of 2Gbyte of ram. It was fine without SMP and without PCI, but when i added the PCI cadge i had an other issue, and in order to open a window to the XIO-PCI (in order to have a PCI_USB NEC EHCI chip on) i had to

- get out all my 1Gbyte ram modules
- get in 8x256Mbyte modules

Hmm, in other words, any memory >2GB of RAM on an XBow 1.4 had issues in Linux? I may have ran into this trying to run 3.5GB. I guess I'll have to hunt for XBow information/documentation. I wonder if any of the old Altix code might shed some light. I don't suppose you've come across any XBow documentation?

As for the PCI card cage, that issue might have been the Linux/MIPS PCI scanning code detecting the cardcage first in its bus probe and stopping after that. I have a fix in the mips-sources ebuild now, but it hasn't been accepted upstream yet.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic