[Raion]

Hey mx,

That's a good idea but ultimately I'm very hesitant to directly get hpe involved. Not only do large corporate American companies have a poor track record of being fair, but involving them directly could restrict aspects that I'm uncomfortable with.

Regardless I respect your opinion. There's nothing wrong with making the suggestion of course.

[fuel]

I saw this post following a link from hackernews, I'm interested to work on this project, but I think the first step would be resurrect adding the ability to run irix 6.5.x (preferably .30) to qemu (there were some initiatives, the code is still around) which is perfectly legal regardless of the Irix license constraints; then it would make it easier for me to work on a fork. I'm not interested to work on the 32bits version of irix, if I'm making a clone it's going to be a clone of the 6.5.x kernel including its abis (o64, n64 maybe n32 as well). lmk.

[Raion]

Welcome to the forums fuel, I appreciate the support!

> I think the first step would be resurrect adding the ability to run irix 6.5.x (preferably .30) to qemu

.30 is very much not the exact pinnacle. Between post .19 versions the differences are mostly drivers/API. .30 has some bugs for older systems and doesn't support say, DPS, or other features .22 does. I'd compare it to say, Amiga OS 3.1 vs Hyperion's OS 3.1 -- not but so many differences!

The qemu-irix stuff works, with a bunch of caveats that make it unacceptable for all but compiler work (which is what the SM64 dudes were doing, using IDO 5.3). There's no X support, and implementing that would be impractical/difficult, and it can't emulate any graphics hardware or even support later CPUs. The fact is, IRIX is an "all in one" system and can't really be decoupled from the graphics stack it uses. Even the Onyx4 has an inferior experience since it uses XF86 instead of XSGI and has no IRISGL compatibility.

ABI-wise it's also limited to one ABI (they used o32 for sm64, but later stuff uses n32 or n64 ABIs)

> then it would make it easier for me to work on a fork. I'm not interested to work on the 32bits version of irix, if I'm making a clone it's going to be a clone of the 6.5.x kernel including its abis (o64, n64 maybe n32 as well). lmk.

MAME is currently the only way that really works accurately. Talk to flygoat here (Hatsune Miku avatar) he's a MAME contributor and MIPS guy.

As far as 5.3 vs 6.x, the main differences:

No vnode subsystem.

Retains COFF support from 4.x

No C99 support in libc and Cfront-only C++ support I think

No CXFS, trusted IRIX, attribute support and EFS, not XFS is the default FS.

That's a start, at least. But API-wise it's still not too dissimilar, so this would be a step towards IRIX 6.5 and up. We'll eventually go for it.

Lastly, a general statement:

For anyone DMing me, it is Memorial day weekend in the US, I'll be mostly spending time with friends. I'll catch up Monday and Tuesday!

[DrShuppet]

This is definitely an interesting and ambitious project, documenting closed-source software in detail always requires some cleverness to be able to "see in the dark".

I'm curious about a few things:

• Where is the timeline estimate coming from? Do you have a rough outline of what steps you need to do to achieve your goal and an estimate of the diffuculties that might arise?
  
• Are you going to improve the kernel once you have reverse engineered it? IRIX 5.3 was released in 1995, there were many advancements in operating system theory since then in memory allocation, scheduling etc.
  
• What do you expect to get from reverse engineering the IRIX 5.3 kernel? Do you want e.g. to document its distinguishing features from other contemporary derivatives of SVR3/SVR4 and see if maybe something is interesting even today, or are you just doing it because of nostalgia and retro-computing fun (not saying that is wrong, quite the opposite)?
  
• How many people are planned to be working on the project?
  

I won't hide that I'm a little worried about the ambiguity in the initial post, I'd want to believe that after making the annoucement you are really taking it seriously - I know from my own past with attempting to do hard things that one cannot run on pure enthusiasm, since with this kind of work you are eventually going to get to the ugly stuff, and I wouldn't like to see the project just fading into obscurity because it not having proper motivation and organization.

Given that, I saw many amazing projects that have succeeded in this community, including Dodoid's DFRD remote viewing and TruHobbyist's File Looper and patchMLOADBLK, hence I believe there is an non-negligible chance of this project going well (unlike what some people online say). Anyway good luck, and don't get dissuaded by haters, somehow the IRIX community is prone to unnecessary drama :/. I might want to contribute myself when I'll see it's going somewhere and I'll have some time.

[Raion]

DrShuppet,

Thank you for your questions and post.

I will answer what I can but as a reminder, as the spokesperson involved with this my main goal is to ensure that I provide correct and accurate information to the best of my ability and at the same time protect the people who have trusted me with identifying information.

Because of that I can't exactly reveal how many people are involved in the team but I can tell you that it is more than a few. My primary role besides acting as the public face of the team is to help direct priorities and act as the intermediary between divisions in the team.

The timeline is a best estimate based on the estimated number of lines of code that are involved in the project and on estimates from people who have undertaken similar projects. These are subject to change of course but we have an obligation to provide some type of a ballpark up front.

We have a sort of road map and timeline that we are planning to try to adhere to, and to ensure trust it'll be my job to provide preliminary forms of documentation that come out as a result of our study. I'm also one of the few technical writers involved with the group so my job is to ensure that we have uniform clarity throughout the writing and ensure that the final published specifications and references (potentially including charts, graphics and such) are of the same quality.

> Are you going to improve the kernel once you have reverse engineered it?

Without specifically making promises we can't keep I would very much like to explore us documenting potential serious bugs that we will mark down as todos with what to fix. As far as changing things like the internal scheduler and such that really just depends upon our priorities once our original goals are met. If there's a demand for it and the team members are up for it I am more than happy to continue facilitating cooperation.

> What do you expect to get from reverse engineering the IRIX 5.3 kernel?

I'm not sure if you read the articles involved but one of the main goals is to figure out how drivers interact with the kernel of IRIX, and by working on an older version of the OS we can simply when we start going towards the 6.5 kernel fill in the missing blanks and adapt our writing to it so we won't be starting from scratch.

Besides that if there's any sort of assistance that we can offer to the devs of MAME or other projects we will do our best to provide pertinent information in a timely fashion.

One of the other aspects involved is that if we can find out subsystems that are identical or similar to say Solaris/illumos we might be able to adapt to those subsystems instead of writing code from scratch. I can't make any promises though it's just some of the goals that we have in mind.

Doing the same thing for 6.5 would have been quite financially untenable by comparison. If we can keep the conversation rolling and deliver on a smaller target like this, the main theory is that we would have secured enough community trust and a track record of delivering on our promises so that we can embark on a much larger scope of a project and hopefully secure greater cooperation.

In plain terms, I didn't want this project to end up being some sort of pie in the sky thing with a massive budget up front that we would need people to be forking over massive sums. We get 200 people donating $25 each, that is a much more attainable goal than something along the lines of 1000 people donating $50-60 each. Assuming we get within 75-80% of our goals it might be possible for me to source the rest from other investors. Some people I spoke with were hesitant to be upfront investors unless we had other people who were guaranteed to be part of the operation.

If this project doesn't work out it's not the biggest deal in the world and I do have multiple contingency plans in place that might be able to preserve some of the goals that we are stating here but those plans in particular are actually far more logistically challenging than what I'm asking for here.

[soviet]

Wonder why any thread in forums this days are converted into "armchair lawyer" discussion, SGI is dead why worry so much.
Now hope the project can move forward, can donate some cash for the project.

[Raion]

It's people being very well intentioned and basically not wanting disaster to happen. Nothing is guaranteed, but both Sega v. Accolade and Sony v. Connectix case law are on our side here. Even if somebody issues a C&D against us or demands us to turn over what we have there is really nothing other than talks between me and team members. Those in and of themselves are not criminal or even civil in nature.

I'm still researching the best platform for fundraising but unfortunately it is proving to be a bit of a pain because of the specialized nature of this.

[Raion]

It seems like hackaday picked us up, so let me clarify a few points raised in comments:

1. I am not working with HPE. They no longer hold a claim to the trademark. There is nothing stopping us from using IRIX as a name.

2. We are essentially re-implementing the OS, or proposing to. I am taking the opportunity to reuse the well-known name.

3. No part of the money is being used for attorney fees. The person who is involved with this is being very fair and not asking for much because they know that I don't come from a place of means.

4. Some people can work for free and work off of enthusiasm but some of the people that I'm working with are not able to. In order to get this done in a somewhat timely fashion it would be necessary for us to come up with the cash. Otherwise, I have contingencies, but the primary result of those would be a significant delay of our plans maybe on the order of 5-10 years, something I really don't want to do because it doesn't take that long for the steam to burn out on a community.

5. I signed up for the comments there but I don't know if I will be able to comment or not. Please post your questions here if you want me to see them

[nuclear]

So if I understand it correctly, your intention is to make an entirely new UNIX system from scratch, inspired by, or as close as possible to IRIX. Correct? Is the plan to make this for SGI hardware or modern PCs?

Writing an operating system, or even just a kernel (are you writing the whole system or just a kernel?) is certainly a fun project. I like it, and I have done similar projects a few times. But even taking it to the point where it's functional and advanced enough for any similarities or differences to any specific UNIX system like IRIX to come through, will take an enormous amount of effort. Like years. Isn't it a bit pre-mature to call this anything other than "a new homebrew UNIX-like OS project"?

[Raion]

Hey Nuclear. Not really on point.

The fundraiser primarily is so that we can create a technical manual of the IRIX 5.3 kernel. From there we are going to reconstruct an IRIX compatible kernel after using the manual to verify if there's any bits that we can simply drop in from another existing open source OS. Anything that we can't will simply be recreated based on the contents of the manual.

This is not a homebrew project. I'm not working on this directly, rather I have assembled a team including people from outside of the community who I have known over the years with the primary intention of producing this quicker than simply relying on a community which has proven to lack the critical mass to come together on a coherent project at this point in time. There might be some pieces I'm able to take care of myself when the time comes but I have no reverse engineering skills myself and have mostly relied on the work of outside people helping me to say, get libfam v1 or libdisk or a mount(1) command for IRIX working.