vishnu wrote:The author of the Courier mail transport agent has some very enlightening things to say about IMAP in general and it's author (may he rest in peace) in particular: http://www.courier-mta.org/fud/

Thanks, vish, for destroying another illusion. Crispin was an mbox fan ? What a dick.

For anyone who is unfortunate enough to set up and run a small mail server (i.e., about 25 people) stay away from any of the worthless Unix CRAP. It's all absolutely worthless stinking idiotic shit.

Set up a little OS/2 box and run Weasel. You'll be done in an hour and it will never give you even a whiff of trouble.

Stupid Unix garbage with all their penis-stroking idiotic obscurity and pointless complexity, it's worse than ridiculous. It's an unnecessary nightmare.

I installed Communigate into Solaris a while back as well. It would have been okay if I could have found a version from back before they also went wacko. The current Communigate is half-submerged in pointless garbage that you can't get rid of, too.

Since i'm the OP, i would like to reiterate that discussions about 'x is better than y' are not helping the cause of developing software for IRIX. Yes we need some discernible difference between similar packages, but we need code that is doing the job, which also means that sometimes it is a good idea NOT to port specific code to IRIX, simply because the OS surrounding the program or even the machine itself is not up for today's infrastructure.

Let alone the fact that the hardware is unmaintained and abandoned by SGI, so running mission critical with IRIX machines is basically not a smart thing.Fortunately, Ian and Doug and enthusiasts and others are still out there and help keeping stuff running. Kudos to them.

To get back on track. I've toyed with the idea for making a list of compile errors and how to deal with them. From the recent xcircuit discussion, i've realized that many problems in porting software comes from not reading or not interpreting the compilers error messages correctly. Getting a handle on compiler errors is vital in porting code that is correct and does what it is supposed to do.

Also and this is much more concerning: People's code skills are not what it used to be ten years ago. I've noticed this on new people joining the University. It is what it is.

Let's continue with getting stuff going. Keep testing and keep reporting. The Maxwell and xcircuit threads are proof that we can do it.

dexter1 wrote:Also and this is much more concerning: People's code skills are not what it used to be ten years ago. I've noticed this on new people joining the University. It is what it is.

Even 10 years ago my code skills weren't what they used to be I've learnt new stuff over the years by just 'giving it a go'. By throwing together a few little programs, by reading the various techpubs manuals and by looking at other peoples code. It might be hopelessly naive, but the question for me is how do we get more nekochan people interested in even picking up their digital axe and having a go at the (IRIX) codeface?

Hamei, this is where you snigger and go "codeface, shmodeface, the kermunittee doesn't even test-run the stuff in nekoware/beta!"

jimmer wrote:Hamei, this is where you snigger and go "codeface, shmodeface, the kermunittee doesn't even test-run the stuff in nekoware/beta!"

Shhh ! We finally got vishnu outta the porn palace in his basement, dexter1 wandered back from his travels in the desert and there's even a few Loonies who are giving Urx programming a go. I'ma gonna keep the trap shut for the moment

dexter1 wrote:To get back on track. I've toyed with the idea for making a list of compile errors and how to deal with them. From the recent xcircuit discussion, i've realized that many problems in porting software comes from not reading or not interpreting the compilers error messages correctly. Getting a handle on compiler errors is vital in porting code that is correct and does what it is supposed to do.

I think that would be an excellent idea! It's not just the compiling, but also the setting up of the environment as well which could use a coherent tutorial. My recent forays into compilation with OpenTTD meant a lot of searching the forums for scraps of info, asking questions and relying on helpful people pointing things out before I could even start compiling the code.

There's plenty of info on setting up a good MIPSPro environment, but not much for the GCC equivalent. Plus of course differences with setting things up depending on whether you're using bash or tcsh. Then there were other bits of info I had to ask about, such as the 20k IRIX limit on command arguments which can be overridden with "systune -r ncargs 262144". Easy if you know how, but when .\configure is just bombing with an error message, it took time to figure out (with help from here). Also, simple methods of forcing gmake to be used instead of IRIX make.

I know the info is out there, but it's very fragmented. Hence, getting the info together can be a bit daunting, and it's easy for some people new to IRIX compiling to run into a few hurdles and just give up.

Add this with a nice list of compilation error fixes, and maybe a proper guide to debugging, and this might help a lot more people out there to start porting additional programs and utils to IRIX.

rosehillbob wrote:A group on the internet posts builds of the Linux kernel for the MIPS le and be built using the LLVM compiler. The kernel runs is reported to run faster than one built with GCC.What this means right now people are basically running an updated version of our MipsPro compiler under MIPS Linux!I think we should get the compiler working back under SGI!

What is the current state of LLVM for Irix? And which languages does it support?C,C++, ... ADA?

@Raion-Fox, @vishnu: Just to dispel any doubts, please see here and at the end of the page linked to in that thread, where he quotes from here out of context. That should make it quite clear that countzero was just another incarnation of our old friend Carlo.

And, indeed, please take these kind of questions / comments to us via PM or in the Nekochan.net subforum. Thanks!

The Bandito wrote:In a few years, no doubt, you'll be able to buy a computer,software and operating system that will match the capabilitiesof your current Amiga at about the price you paid for theAmiga way back when. But you can smile to yourself, knowingthat you were touching the future years before the rest ofthe world. And that other computers and operating systemswill do with brute force what the Amiga did years before withgrace, elegance and style.