pentium wrote: I'm pretty sure that a lot of that money went towards the bag.
absolutely, for 2 indys that's way out of line
r-a-c.de
The collected works of foetz - Page 21
absolutely, for 2 indys that's way out of line
Silicon Graphics Hardware:
Indigo 2
Fire
what's a fire?
r-a-c.de
you could install the older one to an alternative location (inst/swmgr option -r) and put the files that have different names than what comes with the current version of the lib into one of your library paths
r-a-c.de
just use GraphicsMagick then
r-a-c.de
yeah the symlink is worth a try. for some libs that's enough
r-a-c.de
nongrato wrote: Solaris uses a tool called "crle" to set up library paths.
https://blogs.oracle.com/ali/entry/avoi ... y_path_the
well that blog article seems like defending the leave of a common path and searching excuses for doing so.
i've never used anything else but LD_LIBRARY_PATH and never had problems. as with most things, if used right you're fine. that whole thing reminds me of linux as in adding more stuff for doing the same just so that maybe it gets a little more dummy proof.
i don't like the direction solaris has taken in recent years. instead of useful stuff they added more bloat with not only zero advantages over previous methods but making it actually more messy and unhandy. replacing the init scripts with all that svc junk is a good example. ever tried adding a new start up service manually? what a pita
r-a-c.de
nongrato wrote:foetz wrote: well that blog article seems like defending the leave of a common path and searching excuses for doing so.
Well, my initial message was just a question. I didn't mean to say everyone should avoid ld_lib_path even on IRIX.
of course, my comment wasn't aimed at your direction
r-a-c.de
hamei wrote: http://xahlee.info/UnixResource_dir/_/ldpath.html
eeww that's almost worst than the first article.
"In general, the whole concept of Unix's environment variables are bad. It is a symptom of unix's “solve it simply, quickly, brainlessly” philosophy." this sentence alone disqualifies the whole thing. the only brainless thing in this case is the author
env vars are very flexible and handy but it needs a tiny amount of brain power to use them right. a person not up to that shouldn't be admin of anything.
r-a-c.de
oh yeah, something named "...haters" should be very objective and well founded
on a more serious note, of course as with most things you can find good and bad attributes. the crucial part is the weighting.
but no matter what it's about the vast majority of cases come down to who is using it and how. a program created with a humble dose of common sense used by somebody in a similar way should be just fine. and with slightly more common sense env vars can even offer neat possibilities
on a more serious note, of course as with most things you can find good and bad attributes. the crucial part is the weighting.
but no matter what it's about the vast majority of cases come down to who is using it and how. a program created with a humble dose of common sense used by somebody in a similar way should be just fine. and with slightly more common sense env vars can even offer neat possibilities
r-a-c.de
ClassicHasClass wrote: Really? It built out of the box for me on my G5.
same here, not a single prob even without gcc
r-a-c.de
if it worked on the fuel it works on the o350, too. you might wanna run it from dbx and see what's the problem
r-a-c.de
hamei wrote: I thought sure you'd be an er user
avid was pretty much at the end of the list of what i used. if i have some time over the weekend i'll give it a try
r-a-c.de
hamei wrote:foetz wrote: avid was pretty much at the end of the list of what i used.
Is there something else for morphing ? I did one or two things a long time ago with this, it was pretty easy (was doing simple stuff tho.)
I can see why you would not like Matador. That program makes DOS look good
i actually used matador a little more because i simply had no need for ER. morphing was either a default part of the compositing programs or by plugin
r-a-c.de
vishnu wrote: source code from 1992 attached for everyone's viewing pleasure
they had stdbool.h in 1992
welcome llama, seems you're set up quite well already
using a "real" unix should also be something you can benefit from for your job as it lacks most of the dummy features most linux version come with.
using a "real" unix should also be something you can benefit from for your job as it lacks most of the dummy features most linux version come with.
r-a-c.de
haha nice bg. well so if you had that in 2006 i'd like to see your current one
r-a-c.de
alright, checked it out and it worked fine; the demo version tho.
anyhow it wasn't flawless. turned out to be incomplete inst prereqs:
if you install er with the required dependencies the following happens:
running er_anim leads to:
the regular er produces a proper error telling what's missing. er_anim however doesn't and just crashes. obviously the missing hiip parts are the problem. here's what i had installed at the end (working fine then):
anyhow it wasn't flawless. turned out to be incomplete inst prereqs:
if you install er with the required dependencies the following happens:
Code: Select all
Can't find 'loaders' file in HIIP directory '/var/avid/hiip'.
running er_anim leads to:
Code: Select all
er_anim[4]: 1973 Memory fault
the regular er produces a proper error telling what's missing. er_anim however doesn't and just crashes. obviously the missing hiip parts are the problem. here's what i had installed at the end (working fine then):
Code: Select all
I avid 1001003000 Avid Admin, 1.3
I avid.sw 1001003000 Avid Admin Software
I avid.sw.lib 1001003000 Avid Support Libraries
I er 1003000009 Elastic Reality, 3.0
I er.sw 1003000009 Elastic Reality Software
I er.sw.er 1003000009 Elastic Reality Software
I hiip 1001006008 HIIP, 1.6.8
I hiip.sw 1001006008 HIIP Software
I hiip.sw.hiip 1001006008 HIIP Support Utilities
I hiip.sw.lib 1001006008 HIIP Libraries
I hiip.sw.loaders 1001006008 HIIP Loaders
I hiip.sw.savers 1001006008 HIIP Savers
r-a-c.de
llama wrote: Is there a way to get csh to source ~/.profile
no and it wouldn't work either. csh doesn't eat ksh stuff let alone specific extras like bash comes with.
or am I better off switching shells?
indeed, nobody needs bash. if you want it fancy use zsh and if you want it solid use tcsh. that btw does not only apply to irix but any unix.
Also need some basic things like a music player, video player
that might get difficult. for music xmms is a great thing but video is tricky. at least assuming you wanna play videos using "modern" codecs such as xvid or x264.
it's been a while since I used a system that didn't have anti-aliased fonts
late irix versions did come with anti aliased fonts and so do gtk2 based programs
would I be able to do something like dd the 2GB install on to the 9GB drive? Is there anything else needed to get it to boot off it?
search ftw:
viewtopic.php?p=35760#p35760
r-a-c.de
llama wrote: I'm certainly not married to bash, I guess I just need to set up tcsh (or similar) properly so I have the things I'm now used to (up arrow history, tab completion with choices, ctrl-c break, etc etc). Is there a list of shells available on the system (eg an /etc/shells equivalent)? I seem to have a limited selection but I'm only eyeballing the bin directory so maybe they're stashed somewhere else?
if you wanna see which shells are there by default just have a look into /usr/bin and /sbin.
tcsh does cover what you listed except for tab completion with multiple choices. if that's a must you need to grab zsh from nekoware. if the nekoware zsh should cause problems because you're on 6.5.14 you can alternatively use mine for 6.2 which works fine with all 6.5.x versions.
r-a-c.de
duck wrote: I gave up zsh for ksh
not sure which ksh you had but ksh88 as well as ksh93 pretty much suck for interactive use and don't come even close to zsh. for scripts however it's different
r-a-c.de
duck wrote: pdksh (where pd equals public domain)
ah yup of course that's different
r-a-c.de
johnmccrea wrote: Thanks for linking to my post. I've got a lot more planned.
thanks for that stuff john and welcome here
r-a-c.de
no prob just run a virus scanner
r-a-c.de
oh yeah, indigo2 with an r4400/250 is neat. it's one of the most compatible systems. if you switch the impact with a pre-mgras card you can run everything from irix4 up to 6.5.22.
and yes, running 6.5.x on this makes little sense since any older version will be a boost in comparison. with 5.3 this one will fly and you can even run coff
and yes, running 6.5.x on this makes little sense since any older version will be a boost in comparison. with 5.3 this one will fly and you can even run coff
r-a-c.de
jodys wrote: Since I'd like to do some development on this machine, what is the last version of the SGI compilers to run on 5.3? I've got quite a few discs to look through. I assume that 5.3 is not compatible with Impact, right?
it is. there's a special version of 5.3 that supports impact. the only rub is that it doesn't support xfs but that might not be a problem. however in case of the r4400/250 you'd need an older cpu to install it because that one only works after installing a few patches. funny enough the indigo2 version of irix4 does work due to seemingly less thorough checks
as for the compilers, 5.3 had the mips compilers i.e. not mipspro yet. namely mips c 3.19, c++ 4 and fortran77. the c++ is pre c++98 meaning there's no stl and other things common today. the f77 is pretty good because it supports a lot of extras beyond what's defined by fortran77.
bottom line if you're not much interested in c++ or write your own stuff so that it works there 5.3 makes for a nice dev platform. and for the odd case there's still gcc.
EDIT: the proper names are as follows
Code: Select all
I ftn_dev 1021572033 Fortran 77, 4.0.2
I c++_dev 1021572035 C++, 4.0
I c_dev 1021572033 C, 3.19
r-a-c.de
- pwgen.bz2
the famous password generator. as usual works fine on 5.x as well
r-a-c.de
5.3
6.2
microline are the original netscape widgets and bcpp is a c++ source beautifier
- microline_xml.tar.bz2
6.2
- microline_xml.tar.bz2
- bcpp_20131209.tardist
microline are the original netscape widgets and bcpp is a c++ source beautifier
r-a-c.de
never use dhcp unless you
need
it for some weird reason.
the resolv.conf of 6.5.x doesn't need the domain entry. i'd just leave it out and get the rest sorted in hosts
the resolv.conf of 6.5.x doesn't need the domain entry. i'd just leave it out and get the rest sorted in hosts
r-a-c.de
- microline_xml.tar.bz2
- openssh_33.tar.bz2
the original netscape XmL widgets with the one exception that i had to remove the arrows when sorting grid columns because irix4's motif doesn't have that.
ssh 3.3, well, might not provide tight security anymore but what the hell it works at least
r-a-c.de
didn't find a fitting thread but if there's one please merge
as you've probably noticed i've been playing around with all kinds of irix versions starting from 4 lately and naturally at some point i wondered about the benefits of all the upgrades over time. namely coff, (o)32 and n32 so i ran a little test with gzip:
these are average values to keep it fair. i ran each test a couple of times to determine the average.
no surprises so far you might say but only at first sight. all gzip builds i used i compiled using the original mips(pro) compilers for each irix version. but only the compiler i used for the n32 version does support -O3 for object files i.e. all others i built using -O2. not fair you might say and that's what i thought as well so i built the n32 version with -O2, too and the result was 2.19! and that although it's mips3 and all others are just mips1.
so i went ahead and compiled a mips1 -O2 version on 6.2 and to my surprise that one beat all others except for the n32 getting a 2.09. might be the result of the newer compiler i have for 6.2 compared to the ones for 5.3 and 4.
intrigued by that i built one more gzip but this time taking the detour and doing a 2 phase build; ucode first and then the final link. the only way to use -O3 for mips1 o32 if there's more than one source file. did that and ran the test once more: 2.05!
so the good old mips1 build with just using -O3 could compete with the fancy n32 mips3 build built with not just -O3 but the whole spiffy -OPT:Olimit=0:roundoff=3:div...
sure, the test is far from comprehensive but still interesting i think.
as you've probably noticed i've been playing around with all kinds of irix versions starting from 4 lately and naturally at some point i wondered about the benefits of all the upgrades over time. namely coff, (o)32 and n32 so i ran a little test with gzip:
- irix4.0.5, coff: 2.12
- irix5.3, coff: 2.12
- irix5.3, o32: 2.12
- irix6.2, n32: 2.04
- irix6.2, o32: 2.12
these are average values to keep it fair. i ran each test a couple of times to determine the average.
no surprises so far you might say but only at first sight. all gzip builds i used i compiled using the original mips(pro) compilers for each irix version. but only the compiler i used for the n32 version does support -O3 for object files i.e. all others i built using -O2. not fair you might say and that's what i thought as well so i built the n32 version with -O2, too and the result was 2.19! and that although it's mips3 and all others are just mips1.
so i went ahead and compiled a mips1 -O2 version on 6.2 and to my surprise that one beat all others except for the n32 getting a 2.09. might be the result of the newer compiler i have for 6.2 compared to the ones for 5.3 and 4.
intrigued by that i built one more gzip but this time taking the detour and doing a 2 phase build; ucode first and then the final link. the only way to use -O3 for mips1 o32 if there's more than one source file. did that and ran the test once more: 2.05!
so the good old mips1 build with just using -O3 could compete with the fancy n32 mips3 build built with not just -O3 but the whole spiffy -OPT:Olimit=0:roundoff=3:div...
sure, the test is far from comprehensive but still interesting i think.
r-a-c.de
6.2
the always popular set of gfx tools
- Perl-Magick-4.27.tar.bz2
- imagemagick_427.tardist
the always popular set of gfx tools
r-a-c.de
hamei wrote:foetz wrote: so the good old mips1 build with just using -O3 could compete with the fancy n32 mips3 build built with not just -O3 but the whole spiffy -OPT:Olimit=0:roundoff=3:div...
sure, the test is far from comprehensive but still interesting i think.
What happens if you do something more floatingpointy ? for integer, a p-iii will kick Irix butt every which way but loose ...
sure, as i said it's a simple test but i have no idea how a p3 matters here. this was meant to see the differences between the irix binary types, nothing else. so, obviously, anything else but what runs irix is irrelevant.
r-a-c.de
hamei wrote:foetz wrote: i have no idea how a p3 matters here.
'cuz even a p-iii is so much faster than any MIPS cpu at integer that it doesn't seem like they'd have spent much effort optimizing for integer ? If one were going to write integer-heavy apps you'd have to be a lunatic to choose Irix ...
hehe yes true but again missing the point. this test was solely meant for getting a quick impression of how much the different irix binary types (and only them) differ and not how fast or slow irix is compared to whatever else under whichever conditions.
and as i said 2 times already now there could of course be many more tests like that to give a better picture
r-a-c.de
hamei wrote: Cropping to a defined size is such a pita
...
What other programs are available with this feature but hopefully more conducive to an Irix build ?
gimp can do it. also the 1.x versions if you wanna avoid the gtk2 bloat.
and not to forget irix' very own ImageWORKS. it doesn't keep the fixed size but you can crop/expand by numbers
r-a-c.de
hamei wrote: Even better idea .. in fact, I think I've seen mention of earlier Motif versions ... hmmm
gtk1 is light and not even too basic
last motif based version was 0.54. you made me curious now so i'll give it a try
EDIT: did so (see my 5.3 packages) but it's not what you have in mind. the crop dimensions are just shown based on what you select but you can't enter them yourself. so a late gimp 1.x is probably the best call
r-a-c.de
- vim_53.tar.bz2
with motif based gui of course
r-a-c.de
5.3
6.2
the last one of the first gimp generation based on motif. for historical reasons and for hamei
- gimp_0541.tar.bz2
6.2
- vim_62.tardist
the last one of the first gimp generation based on motif. for historical reasons and for hamei
r-a-c.de
josehill wrote:foetz wrote: the last one of the first gimp generation based on motif. for historical reasons and for hamei
You're a good man, foetz!
thaaaanks
vishnu wrote:foetz wrote: microline are the original netscape widgets...
Speaking of which, if anyone wants the full set of netscape's motif add-on widgets I've got them, and I've even semi-autoconfed the source tree, which is to say the I've gotten the library itself to compile with autoconf but not all the other subdirectories, which are tests and whatnot. If there's an interest I could possibly be moved to autoconf the whole thing...
me me me ... me
on a more serious note: me
and no worries about autoconf, i don't care. i.e. no need to spend more time on that at least as far as i'm concerned. would really appreciate the package
gocram wrote: Thank you very much for these packaged ports, I really appreciate that.
By the way, speaking of GIMP, has pressure-sensitive (e.g. Wacom) digitizer/tablet input ever been implemented for IRIX? I remember it didn't work for some (?) Nekoware releases.
i have no idea. never used that with a tablet.
r-a-c.de
vishnu wrote: If it's 11 it's as easy as falling off a log
in terms of dry humor you definitely deserve the forum's badge of honor.
no offence hamei, you get most other badges
r-a-c.de
hmm these seem different from the ones i have. my stuff was just the XmL pack having just a couple of widgets. anyway comparing the progress widgets my surce looks different.
anyhow i wouldn't mind the paper bag release anyway
anyhow i wouldn't mind the paper bag release anyway
r-a-c.de