The collected works of skywriter - Page 5

the imac is awesome! i got an extra airport extreme to cover the property with wifi. got an N card for my mini and have my 4TB iomega ix4-200d on order:



and the cheap htpc:



and a couple long cat6 cables to upgrade the house backbone for 1gbe.

a nice start to a new year

http://forums.nekochan.net/viewtopic.php?f=2&t=16717997

or use the 'more smilies' in full post editor.

so, i want to run gphoto2 on my mac and that needs darwin ports, but darwin ports gives me this message that other people have fixed by loading xcode (again). well... i did that and it still doesn't work. i really want to just control my new (used) camera from osx.

sh-3.2$ sudo port -d selfupdate
dlopen(/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib, 10): no suitable image found. Did find:
/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib: no matching architecture in universal wrapper
while executing
"load /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib"
("package ifneeded Pextlib 1.0" script)
invoked from within
"package require Pextlib 1.0"
(file "/opt/local/bin/port" line 40)
sh-3.2$ hostname

i've found the atom is an awesome chip. the performance killed all my other pc's i had been using. of course i never stayed up to date with pc's because they change so fast. but, cheap, fast, portable - what a refreshing intel experience for me. with the atom i could save the real cash for an imac

hrm... i downloaded macports, and it seems to be going ahead based on that rather than darwin ports.
i forgot to mention this is a snow leopard 10.6.2. i'll be doing the mini with leopard 10.5.8 if it makes sense after this experiment. the mini is the real platform.

i do run osx on it! that's how i got hooked on the imac, and other apple products

afaik chris although the might be the 'module owner', he hasn't actually done anything with irix blender for years. it's been done solely on nekochan by hard working enthusiasts that donate the binary back to blender foundation. (as it should be).

why would you want one at time point?

pix!

have fun

the dallas carrier is the battery. they either come like that or the battery is embedded in with the ram. dallas is the vendor that make those battery backed rams in that era.

those EPROMS are generally even/odd address pairs. the LSB of the address is used as a part select. 4 parts would mean two even/odd pairs.

they're only spec for ten year usually.

most often than not it's code they bought and built the business processes around that prevents change. this is the main source of stickiness the IE6 has in the corporate world. internal web apps they bought from another company that either doesn't exist anymore, or want money the company doesn't have, and really doesn't need unless they require change. and change is the one thing established companies are not good at.

at least above the janitorial level.

so speak for yourself.

basura in, basura out! i always say!

of course he was vilified. or did your propaganda machine miss the whole story?

what i object to the constant harping on US politics, policy, business, and celebrities as if they were the only sources of ethical misconduct, or the accusation by extension that my family has no honor. anyone who thinks that can have my personal boot up his ass, no charge. i'm proud of my family, my nation, it's history, and even my company. if you want to think ill of us, i advise you to look at your own nations history. there is not one that doesn't have some atrocity in it's history.

on the subject of alphastations: i had a friend i used to work with from DEC look for an interview at my current company. he still worked at the DEC/HP at the time, and had an in at the department that dispositioned returned equipment. i was going to trade him an interview for a lead on a nice big alphaserver. even with strings pulled on the inside i couldn't get a good machine cheap. for some reason DEC equipment seems to hold it's value longer than most any other computer. i should have saved my VAX 11/750. oh well.

oh the ultimate in abominations...

ok THAT was the ultimate in abominations :(

we vax fans also consider vms on alpha as an abomination.

i loved the old cabinets. origin is not so impressive looking, although the interconnect performance is much better.

the models in the beginning moving around on a dolly in a warehouse is pretty funny. not at all convincing., but typical marketing fodder.

they could have done much worse:
http://www.youtube.com/watch?v=tW1S2tsxVHg

pretty much if you do the work for open source tools. do you still have to use libtool? *shudder*

isn't that what was asked? :)

this guy is nuts!

oh good. that libtool phase was tiresome.

incidentally, has Ton switched of mac to windows or linux? irix suppport droped of when he switched from irix to mac. then mac seemed to have graphics driver support last time i looked; 2+ 2 = 4.

wow, i totally missed that one.

hamei is partly right. this acquisition is not an sgi preogative, it's clearly rackable strategy. COPAN is known for building 'green' storage systems. which is a big strategy driving rackable technology (what there is of it, packaging in my mind has little or no IP). the systems operate by maintaining a certain percentage of the drives spun down to reduce the power foot print of the system. this works fairly well since many, if not all, workloads exhibit strong locality of reference, and large skew. what does this mean? a large portion of IO is too a small percentage of devices, and within those devices there is a small percentage of data accessed. the trade of you have to make is in not being able to take advantage of wide striping. as a result you have a power efficient system with low performance, with a small number of useful power states. this reduces the applicability of the system as a whole to specific purposes. it's a pretty novel implementation so far, but soon will become just another feature of other systems as green gets more momentum, which is coming like a tidal wave. so this is a marginal purchase over all at best.

part of rackable's strategy seems to be buying dead companies super cheap and diversifying. hopefully the products and technology they bought, that weren't doing well with the strategy that killed them, are applicable to rackable's new strategy which seems to be focusing on selling into cloud storage and the like.


doesn't seem right to call them sgi since, well... they're not.

the thing with client lists and HW vendors is that a customer asks about system, the vendor offers to let them use one on evaluation. Bing the customer goes on the client list. the customer say "eh, it was ok, but not really worth the money" and sends it back. does their name get removed from the client list? ....no.

COPAN was basically bankrupt. you don't get that way unless you're failing somehow. a HW vendor fails when they don't make enough margins on their systems. COPAN did not sell a lot of stuff, they did not make great margins. they went out of business because of it.

does that mean they suck? no. they solve a problem. However, that problem doesn't justify an entire company, maybe a product from a company with a larger product line will do. perhaps rackable will make some money off selling them as a storage option.

this just says that the design commodity DIMMS results in an error rate larger than the sum of the error rates of the constituent DRAMS. the DRAMS are the parts that have a 'known' Single Upset error rate. the assumption when calculating reliability is that the DIMM will only contribute faults associated with mechanical faults.

the most likely suspect power plane noise, follows by signal cross talk. each is an inexact science to calculate, measure, and address.

my memory designs never had error rate anywhere near this type of rate.

the most useful metric is number of errors per bit or Single Bit Error Rate for correctable errors (not all DRAM errors are correctable unfortunately). my observation has been that the SBER has gone down as bits per package have gone up. each new generation of DRAM size sets off a 'fear of impending doom' that the system error rates will go up. but this doesn't happen.

however, this is a oboservation for a system that is very well designed. not a commodity part. that is one difference in custom hardware you don't get in off-the-shelf junk which is what google bases their observation on.

here's an excellent example of someone with little tolerance for social norms, poor grammar, and inflated sense of self worth, typical weblog angst. i like the description of "everyone's uncle", and "good morning!".

http://kotaku.com/5484581/japan-its-not-funny-anymore

you would not have appreciated Clutch Cargo, or Roger Ramjet.

i did a bus and tag controller. went all the way up to 4.5mb/sec. woohoo!

stuffy british accents!

yeah, more rackable products hiding under very old sgi branding.

oh man, you're right! what a total crock...

but have you ever been to Kamloops!

it's cheaper.

QPI does not scale beyond a single board. you may spend the money to do the design work to make connectors and cables capable of doing it electrically, but the QPI protocol does not withstand a HW fault in the interconnect or processor end points. you can't even hot-plug it.

SGI/IRIX ccNUMA also added a bunch of high level memory/fabric operations for atomicity, barrier synchronization, and remote execution that HT and QPI are only primitive by comparison.

the sweet spot for intel design is the 'couple of sockets'. eight socket topology is the most i've seen for QPI. ultraviolet scales to 32k sockets. fwiw UV only uses numalink between boards, QPI is used between sockets on the same card. the ccnuma of UV is provided by numalink is an extension of QPI.

as noted in the other thread, it's just a crappy rebadged intel server. way to bastardize the hallowed name of Origin. what's next? Indigo? Indy?

maybe we'll get the fabled Indy2! a crappy desktop with 'sgi' scrawled on it

or finally that suitcase Indy; a crappy laptop with 'sgi' scrawled on it.

see the pattern yet?

basically correct. this system is termed 'pair and spare'. when an unrecoverable error is detected in one fault domain (the pair of lock step cpus's), there is a remaining fault domain that probabilistically should remain fault free (another pair in the system). you can read up on the very, very, basics here http://en.wikipedia.org/wiki/Fault-tolerant_system . a couple if issues with a design like this is determining a reliable method for comparing circuits. the method requires single or multiple detection circuits to compare the outputs of two fault domains. if there is a mismatch in output, both domains are declared failed. the limiting issue with doing this with high speed processors, is three-fold:
1) the more complicated the detection, the more apt for the detector to signal a false error reducing the reliability of the method.
2) high speed events require local synchronization which can increase the error detection latency beyond useful delays. this reduces the speed at which processing can occur.
3) most processors use probabilistic techniques like branch prediction to increase performance. this introduces arbitrary differences in the execution path of the pair of cpu's and thus a different set of observable events.
these three issues reduce the viability of the technique beyond a certain processing rate.