After quite a few years using OS X (after SGI decision to drop IRIX), I realize NeXTSTEP had many things that sweetly solved the (very few) things that weren't convenient in IRIX. For example:

-app-bundles (turning it unnecessary to install applications... they're seen as an icon in the desktop, but they're actually a directory holding all the binaries, libs, data, etc that make the application).

-fat binaries. I don't understand why this feature has so many detractors (although most detractors are also binary-distribution detractors, so it's understandable that people who push for a world where everything was source code would be detractors for fat binaries, because they hate binaries in the first place). If IRIX was resurrected, I'd love it to adopt fat binaries as the path for supporting multiple architectures.

-what you can do with DMG images in OS X is shockingly powerful. Yes, today we have FUSE as an equivalent outside of OS X, but back in the years when I was a daily IRIX developer there was no equivalent.

So, in conclusion, I guess the OS of my dreams would be a merging of IRIX with NeXTSTEP... well I believe most of it would be IRIX, but I'd adopt the app-bundle paradigm in the desktop, I'd link some of the MACH kernel into the IRIX kernel (perhaps in a similar way to what the XNU kernel does in OS X: it's not the MACH kernel, it's another kernel which links stuff from MACH as a library), and I'd make disk image mounting as a very central service.

That would be a terrible idea. Mach has shitty performance. If you want to resurrect IRIX do it with a BSD kernel as the base not the abomination and unspeakable horror that is Mach. It's performance sucks, it's UNIX compatibility is shockingly underwhelming and MacOS and to an extent NeXTSTEP are garbage. Fuck launchd, fuck libnotify, fuck Aqua, fuck Darwin and XNU and fuck the entirety of Apple because they don't care about power users and they abandon their customers with overpriced and underpowered hardware and what little code they do release is under the shitty Apache 2.0 license.

Your point about app bundles is good but you can do this theoretically on BSD with jails or chroot or other setups.

The internationalization support is a good point but with noto fonts on BSD I can do most anything besides input methods which Google Translate has me covered for Chinese and Japanese.

Fat binaries aren't an Apple originating invention. IBM i is essentially architecture independent due to its binary format.

.dmg images were always so annoying I'd much prefer applications and source to be distributed in a tarball with xz or bzip2 compression.

For a new IRIX release I would take from BSD, specifically FoxBSD, NetBSD and OpenBSD the following features:

PF firewall JailsCGDVeriexecPKGSRC or XBPSAnd for the GUI the primary changes I'd implement:

Alright, so I got bored over the weekend and decided to replicate the (photoshopped) interface shown above as a real thing using my Kronos platform. This is a real interface, running on Linux on a spare ThinkPad T60, and it really does work alongside normal Linux applications running in windows (though it's toolchest is full of placeholder menu items right now). IRIX 7 w/ FoxBSD anyone ?

Kronos is essentially a python program using Webkit and GTK connected to a local Apache2 server with PHP. The goal is to write desktop applications (or, in this case, the desktop itself!) using web languages. If anyone has seen the video about the Pegasus X on my channel, it uses an early version of Kronos with no window manager (and therefore practically no usability for normal, local software running in windows other than the main Kronos one). I often refer to it as "pure Kronos". Somewhere I have a version of pure Kronos that does windowing using iframes and JavaScript in the main window, but again only Kronos applications and it's slow. The newer version, which I often call "Kronos 2" or "Openbox Kronos" uses a window manager (I tend to use Openbox) to place Kronos applications in regular XWindows windows, which the window manager allows you to move around as normal. On Kronos 2, the Kronos desktop (which, in this case, contains the toolchest, desktop background, and so on) is a large window configured to stay behind everything else, not allow movement or resizing, and never show borders. JavaScript + PHP allows Kronos applications to access the underlying system (performing file operations or running shell commands for example).

Anyway, basically what it means is that I can throw together something like this "modern IRIX" UI very quickly, have it interface with the system through PHP, and have it look good thanks to CSS3.

Running on my desk with a uxterm open. Openbox windows still have the default window decoration theme.

Closeup of screen. Stunning 1024x768 resolution, courtesy of Lenovo.

Toolchest is functional and translucent, just like the original design.

I've named it Project IRENKA, which stands for "IRIX-like ENvironment with Kronos Applications". Any thoughts? I quite like it, and hope to do a bit more work on it soon.

Dans34 wrote:I really like the look of this kronos app thing , what do we need to get it running ?

Pure Kronos w/ Pegasus X software (and PXEM Pegasus X emulator) is available at http://rittybox.com/pegasus. Kronos 2 has not yet been publicly released. I'm hoping to release it alongside the Kronos API (kapi), which I don't feel is secure enough to release. Right now, the Kronos API can be accessed with no limitations so long as the connection originates from localhost. While this stops the guy across the room from messing with your machine through the API, it means that a webpage you load in Firefox could use Javascript to connect to the API at localhost, and because it's coming from your sytem, the API would trust it. Working on code to provide Kronos applications with a key as a JavaScript variable when they are loaded, which they can use to access the API. Applications running in a browser would not have access to the key, because Firefox/Chrome/whatever would not be passing it to the page when it loads, so any attempt they make to use the API would be denied (and probably logged).

Basically, it sucks to use Kronos 2 without the standard API, and the API is insecure. Should be ready for release soon. Note that Pure Kronos does not have the API and is mostly unable to run a decent browser anyway, so this risk should not be a factor (I can think of one potential vulnerability that would allow apps to be installed by a malicious website, but the user would still have to run them in order for them to execute code and I'm not sure if it would work to begin with).