Interesting to see it all play out through the post.. OpenIndiana is virtualized, the Sun Ray connects to it and runs like a thin client.
I hadn't heard of "Sun Ray" until today, but it reminds me a lot of the idea behind Linux Terminal Server Project (LTSP) - which I used on our school's IT lab back then at a teen. Set up an old i386 machine with the various netbooting daemons. Then on each host - boot from floppy disk, remove disk, insert in next machine until 20 hosts were running from that poor old hard drive.
The nice thing was that the installed OS on each was unaffected, and each machine was running X11 over the network.
Seems like those solutions were optimising for a time where hardware was overly expensive.
Today if we say "open an xterm and type this command" we mean to start a program that runs in a window that has a text interface with a command line.
Here is an X terminal from around 1990.
https://en.wikipedia.org/wiki/X_terminal
It displayed everything over the network via X11 from a more powerful workstation / server.
> Datapro wrote in 1991 that X terminals could provide windowing capability, high-resolution graphics and relatively fast processing for prices starting around US$1,500, compared with workstations that could cost more than US$10,000.
Used these at work at my first job. A dozen developers, each with an HP X Terminal all booting/running programs off of a central HPUX server that was less powerful and had less RAM than a basic desktop PC of today.
Similar situation at my first job. I got yelled at for running Xeyes because it chewed up too much CPU.
I got yelled at for running xeyes on a 5 metre video wall. Couldn't resist.
Ps I got in serious shit but it was worth it :) I was young but I probably would do it again.
When I got to the university, we had a DG/UX server, the usual green and ambar phosphor text terminals, and the few lucky ones IBM X Windows terminals, which were mostly used to manage several xterms, given the choice of applications at the time.
When I was in Uni our IT department had rolled out Sun Ray systems and they were actually pretty cool. You'd have a smart card you'd insert into the device which would give you a login page. You'd log in, use your apps. If you had to leave, you pulled the smart card and left. Then you could go to another Sun Ray, maybe in another building, and insert your smart card and your session would pop up with your apps still open, etc.
It was very much like running an X11 server/terminal, except the session could stay open while you moved to another physical terminal. This was great for universities where you might be working on something, have to rush off to class, then could head back to a terminal to pick up where you left off. Also handy if you have long-running tasks that you don't want to interrupt.
Theoretically, given a sufficient networking configuration/VPN/etc., you could pull your smart card out of the Sun Ray in your university office, go home, and then drop your smart card into a Sun Ray at home and still have everything back where you left off.
It was basically the last great innovation of the mainframe/terminal server paradigm, as far as I'm aware. A little late to the party, since by that time most students in CS had laptops and the rest used computers at home, but still very cool.
We had this at a job I had many years ago. We had a Sun Niagara system with some Sun Rays attached, and I had a Sun Ray laptop at home, on the other side of the world. Office in London, home in Melbourne. It wasn't even that slow.
> Theoretically, given a sufficient networking configuration/VPN/etc., you could pull your smart card out of the Sun Ray in your university office, go home, and then drop your smart card into a Sun Ray at home and still have everything back where you left off.
They (well, the late models) had a Cisco compatible VPN client built in. Worked like a charm at my place of work in the late naughts.
I remember how cool it felt that I pulled out my smartcard from my SunRay on my desk in California, flew to Tokyo, plugged in my smartcard to a SunRay there and just like that, there was my desktop ready to keep working!
This was perfectly normal at the time, my first UNIX developer experience was the traditional timesharing experience, one server for everyone.
Ironically cloud based development is nothing other than going back to these days, just with other set of technologies.
Remember, "The Network is the Computer" (1984).
The thing that Sun Ray added was the ability to move to a new physical terminal without logging out of your existing session, closing your apps, reopening them, picking up where you left off, etc. Could see it being great for e.g. university professors who have to leave halfway through grading a paper and didn't want to lose their place, or a long-running process that you didn't (or couldn't) put in a screen or tmux session.
It took me a long time to adjust to a PC environment after being minicomputer/mainframe-based for a lot of my key years (from age 15 through 22, my main access to computing was through college/university systems running VAX/VMS, VM/CMS and a bit of Unix. TBH, other than its lack of pipes and a command path, I generally preferred VMS to Unix, with the VAXstation being my preferred working environment.
Never worked with VAX/VMS, however have spent enough time reading through its manuals.
Systems programming with compiled BASIC, its Extended Pascal version, the API surface that somehow we can find traces where Windows NT got its design inspiration from, really leaves some space for what ifs, in the operating systems adoption evolution.
The VMS influence is also why DOS and NT used / for options rather than - like Unix. I was a big fan of the CLD method of defining commands. It provided a nice standardized way of parsing command line arguments that was going to be consistent between all applications.
DOS uses / because programs written for CP/M, and which were subsequently ported to MS-DOS, used forward slashes.
when PC/MS-DOS 2.0 was released, with support for directories, it supported both forward and backward slashes for directory separator because Microsoft programmers wanted to use forward slashes (bringing them over from Xenix, including adding virtual "DEV" directory with device files), but for compatibility and user friendliness the default was \ for directories and / for options
Oops, the influence was a bit higher up the ancestry chain on both sides. CP/M uses / under the influence of VMS’s ancestor, TOPS-10. That’s what I get on relying on old memories of things I was told that were probably inaccurate from the start.