[HN Gopher] MaXX Interactive Desktop: A Re-Implementation of the...
___________________________________________________________________
MaXX Interactive Desktop: A Re-Implementation of the IRIX
Interactive Desktop
Author : rbanffy
Score : 144 points
Date : 2020-07-04 12:00 UTC (11 hours ago)
(HTM) web link (maxxinteractive.com)
(TXT) w3m dump (maxxinteractive.com)
| als0 wrote:
| Does anyone know what's the best way to try out an original IRIX
| system? Aside from buying an Indigo and disks.
| rbanffy wrote:
| I think qemu had good MIPS emulation, enough, at least, to
| pretend to be a DEC workstation. Not sure anyone tried an SGI
| one.
| opencl wrote:
| There's a guide for setting up IRIX emulation on MAME at
| https://sgi.neocities.org/
|
| Unfortunately it's pretty slow.
| PaulHoule wrote:
| I remember a prof who bought a purple SRI workstation that didnt
| have enough RAM, he plugged into the Ethernet, couldn't get work
| done with it, left it plugged in anyway.
|
| I found out two years later that the root password was the empty
| string.
|
| Then there was the time I went to Syracuse for the first
| conference on Java for scientific computing and Geoff Fox had two
| identical twins from eastern Europe to run a demo on two
| workstations hooked up to a big SGI computer unsuccessfully which
| Geoff answer with 'never buy a gigabyte of cheap RAM'.
| octorian wrote:
| I actually have two SGI machines kicking around (an Indigo2 and
| an Octane2), and I really wish I had a better idea of what to do
| with them beyond poking around at the desktop for 10 minutes.
|
| One big problem with all these old "workstation" computers, is
| that while us hobbyists still have our ways of getting the OS
| installed... The actual applications people ran on them almost
| seem lost to time. When software is so unbelievably expensive
| during its heyday, it tends to not make the jump over to
| "abandonware" repositories once its time has passed. This
| unfortunately makes demos of these old machines far more boring
| than demos of old PCs.
| nix23 wrote:
| Slap OpenBSD or NetBSD on it.
| octorian wrote:
| I hate to say it, but that's even more useless than a vanilla
| IRIX installation. By far.
|
| One big problem with running a 3rd party OS on these old
| machines (specifically SGI, Sun doesn't have this issue) is
| that they tend to not really support any of the hardware that
| actually makes these machines interesting.
| asveikau wrote:
| I have some old machines too, and that thought occurs. But
| that is also slightly boring. What can I do on those that I
| can't do on amd64 at higher speeds?
| nix23 wrote:
| Well nothing, i see it to preserve a bit of history, turn
| it on once in a while, maybe help netbsd to support it
| (patch etc) and port stuff over.
| asveikau wrote:
| Porting and hacking on low level stuff is probably the
| most interesting thing I can think of for it. That is
| probably why I keep the machines around. In practice
| though I hardly have the time to use them.
| weinzierl wrote:
| I think CATIA V4 (CAD software) was _big_ on SGI - at least
| that 's what I used an Indy for back in the day. I believe V4
| didn't run on the PC, so you needed a workstation anyway. Don't
| know if one can find a copy anywhere but I think it would be
| fun to use it again. It was solid software with a good UI,
| quite different from CATIA V5 which (also) ran on the PC and
| had a _very_ colorful and noisy UI.
|
| EDIT: After googling SGI workstation models I think what I used
| was actually most likely an O2[1]. Great design, I remembered
| its distinct look even after so many years.
|
| [1] https://en.wikipedia.org/wiki/SGI_O2
| mhd wrote:
| Heh, I was doing CAD workstation support about 15 years ago,
| when there was the big switch between CATIA V4 and V5. SGIs
| were mostly Octanes plus a few bigger irons, I think, but it
| also ran on HP-UX and some Sun workstations.
|
| There wasn't a lot of movement in the 3D workstation space at
| the time, whereas PC 3D accelerators were taking off big
| time. So you ended up with a system that was faster, _a lot_
| cheaper and where the regular PC maintenance software and
| infrastructure could be used (boy, homogenous Unix devops was
| a nightmare).
|
| Having said that, CATIA was more a workhorse CAD and CAE
| software, so probably not the best to show off neat UIs, and
| amongst engineers it had a somewhat ponderous reputation.
| armitron wrote:
| Almost all of the software worth preserving is preserved. It
| may not be openly available (though odds are it will eventually
| be dumped openly on the net) but you can find pretty much
| anything you want if you put in some effort. It comes down to
| you getting access to one of many private repositories that are
| dedicated to software preservation.
| nitrogen wrote:
| You probably have zero chance of getting your hands on the
| software, but in the late 90s TV ststions ran their weather
| graphics off of SGI workstations with some software based in
| part on something called Inventor. The software was incredibly
| easy to use for building 3D animations, which were baked to
| video with built-in loops and pauses for the weather segment.
|
| If your meteorologist didn't want to hold a remote, the weather
| producer would have to sit in front of the workstation with
| their hand over the spacebar waiting for the right cues to
| advance to the next loop/pause point.
| reaperducer wrote:
| _If your meteorologist didn 't want to hold a remote, the
| weather producer would have to sit in front of the
| workstation with their hand over the spacebar waiting for the
| right cues to advance to the next loop/pause point._
|
| At some stations, it wasn't about the talent not wanting to
| hold the remote, it was about the station not having an
| engineer on staff who could rig up the remote.
|
| At many stations in the 90's, and even some today, the
| "remote" is nothing fancier than a garage door opener, with
| the relays hooked into a breakout box to a DB25 serial port.
| teleforce wrote:
| From reading the comments it seems this effort is more on the
| nostalgic sentiment for reliving the IRIX desktop.
|
| I'm more interested on reliving the CEDAR/Tioga interactive
| desktop environment pioneered by the Xerox R&D team back in
| 1980s/1990s for their in-house productivity tools [1]. The system
| still have some productivity enabling features that are still not
| widely used as of now. Xerox also managed to port the system to
| SunOS at the time.
|
| Anyone aware of any effort or clone that can enable CEDAR/Tioga
| to run on or emulated Linux?
|
| [1] https://news.ycombinator.com/item?id=22375449
| tpmx wrote:
| Nostalgia:
|
| At my first software development job in the mid 90s, the "cool"
| basement room with all of the smart/weird developers in it had a
| a mix of Sun SPARCstation 10/20 and Sun Ultra 1 workstations.
|
| There was also this one weird SGI O2 they had just bought to port
| their software to the IRIX platform, but noone wanted really
| wanted to use it, because of IRIX. So I picked that workstation,
| just to be in that room. Smartest decision of my life - what I
| learned in there defined my career.
|
| The Irix Interactive Desktop (based on Motif) felt so incredibly
| responsive on the O2, compared to Motif/CDE on the Sun
| workstations. It was almost BeOS-like in that regard. It was the
| little touches that mattered. A random example: the CPU usage
| monitor updated at like 10-20 Hz, instead of like 1 Hz on the Sun
| workstations.
|
| Not that anyone really used CDE in normal work - other window
| managers were far more efficient. I ended up using
| http://www.lysator.liu.se/~marcus/amiwm.html on this O2.
| icedchai wrote:
| Neat! I have an SGI system in my collection (an O2 workstation.)
| Back in the 90's, I had an SGI Indy on my desk. Those systems
| were fasttttt...
| Keyframe wrote:
| I had luck to pretty much grew up around SGI and Amigas. This is
| awesome to see, we'll see how useful from day to day though
| compared to GNOME.
| bonaldi wrote:
| This is extremely well done; I thought I was looking at Irix
| until I spotted the Slack icon. (My god, the thought of that on
| the Indy; it would have crippled it for weeks).
|
| I wonder if it has the Twilight background
| Lammy wrote:
| Is that ROX-Filer I see in the screenshot? :)
|
| https://en.wikipedia.org/wiki/ROX_Desktop
| pjmlp wrote:
| This brings back memories back in the early days of OpenGL and
| ISO C++ ongoing standardization I spent quite some time reading
| SGI documentation.
|
| For the youngsters, back when we had multiple prototypes of
| Stepanov's work for the C++ STL library, SGI was one of the
| companies hosting the documentation.
|
| And then there was OpenGL, while ARB was formed in the process to
| standardize IrisGL into OpenGL, reading the documentation from
| the source was much better.
| nabla9 wrote:
| And there was WRML (Virtual Reality Modeling Language) and SGI
| was trying to make that happen.
| pjmlp wrote:
| Yeah, forgot about that one.
| peatmoss wrote:
| I poked around on an old Indy at a vintage computer show a couple
| years back, and the main takeaway I had was, "holy crap the UI
| elements feel instantaneous."
|
| I know it's been posted here many times about how computers have
| become perceptually slow, but that Indy after a couple minutes of
| poking around really drove the point home in a way that no
| numbers ever could.
|
| Computers have gained a lot, for sure, but they've also lost a
| lot. I wonder if it's even possible to make a modern computer
| fast in a way that feels fast again.
| whoopdedo wrote:
| There was a revelation a while back that instantaneous UX can
| be detrimental. If the action occurs so quickly that the users
| can't see it happening, they have a tendency to assume it
| didn't happen. Programmers had to introduce intentional latency
| through elements such as the file copy animation.
| blattimwind wrote:
| I disagree. What you describe is a problem of interaction
| design founded on bad assumptions; with good interaction
| design I don't have to show the user that the computer is
| doing something for the user to be able to tell it happened.
| This is a problem of the system not showing its state
| transparently and relying on the user to notice a change in
| hidden state indicated by a transient window.
|
| Windows Explorer gets your particular example right: When you
| copy a bunch of files into a folder, it will highlight all of
| the copied files after it is done, so it doesn't matter if
| you saw the progress bar or not.
| derefr wrote:
| That was indeed a while back--we had fewer ways to
| communicate change back then. Given all the fancy
| technologies in a modern laptop/mobile device, I wonder how
| much more we could tell the user _without_ slowing down to
| give visual feedback--instead communicating by haptic and /or
| 3D-audio feedback after the fact (the same way that e.g.
| macOS plays a sound effect after-the-fact when you put
| something in the Trash--but with a procedurally-synthesized
| soundscape, rather than the static "it went to the bottom-
| right.")
| bonestormii_ wrote:
| Oooo. So I think this is a terrible idea for most people,
| but something I would personally love. I'm a big fan of 3
| monitors in a slight "wrapping" formation, but there are
| times when some event occurs on a screen which is literally
| behind me if I'm looking at one of the far monitors. It
| would be so cool to have 3D audio feedback that lets you
| calibrate to the layout of your monitors.
| cellularmitosis wrote:
| > Programmers had to introduce intentional latency
|
| Hmm, perhaps if you replace the word "latency" with
| "duration"?
| weinzierl wrote:
| I worked with an Indy for some time and what was really cool -
| besides the smooth and fast reaction to user input you
| mentioned - was that the UI elements were scalable. If I
| remember correctly they were vector and not bitmaps. Back then
| I thought that this will soon be the norm. I'd never imagined
| that we would still be struggling with this more than 20 years
| later.
|
| EDIT: After googling SGI workstation models I think what I used
| was actually most likely an O2[1]. Great design, I remembered
| its distinct look even after so many years.
|
| [1] https://en.wikipedia.org/wiki/SGI_O2
| derefr wrote:
| It certainly is. Most of the reason modern computers don't feel
| instantaneous is actually a trade-off: old computers were less
| adaptive to change.
|
| In old GUIs (e.g. Windows 3.1), many things--file associations,
| program launchers, etc.--got loaded from disk into memory
| _once_ --usually at GUI startup--and then the state of those
| things was maintained entirely in memory, with programs that
| updated the on-disk state of those things either 1. _also
| independently_ updating the in-memory state with a command sent
| to the relevant state-database-keeper; or 2. requiring that you
| log out and back in to see changes.
|
| Today, we _don 't_ have everything sitting around loaded into
| memory--but in exchange, we have soft-realtime canonicity,
| where the things you see in the GUI reflect the way things
| _are_ , rather than a snapshot of the way things _were_ plus
| (voluntary, possibly missable /skippable) updates. Install a
| program that has higher-than-default-binding file associations?
| The files in your file manager will update their icons and
| launch actions, without the program needing to do anything.
|
| There's ways to eat your cake and have it too--to have on-disk
| canonicity _and_ instant updates--but this require a very
| finicky programming model+, so we haven 't seen any GUI toolkit
| offer this, let alone one of the major OSes do so.
|
| + Essentially, you'd need to turn your Desktop Environment into
| a monolithic CQRS/ES aggregate, where programs change the DE's
| state by sending it commands, which it reacts to by changing
| in-memory state (the in-memory aggregate), and then persists a
| log of the events resulting from those commands as the
| canonical on-disk state (with other aggregates fed from those
| to build OLAPable indices / domain-state snapshots for fast
| reload.) This gets you "Smalltalk windowing semantics, but on a
| Unix filesystem substrate rather than a VM memory-image
| substrate."
| StillBored wrote:
| While you might be slightly right, my experience tuning
| windows machines leads me to believe your missing the mark.
|
| I'm going to say the three largest contributions to general
| desktop lag are:
|
| Animations and intentional delays. It can't be said, how much
| faster a machine feels when something like MenuShowDelay is
| decreased to 0, or the piles of animations are sped up.
|
| Too many layers between the application draw commands and the
| actual display. All this compositing, vsync, and minimal 2d
| acceleration creates a low level persistent lag. Disabling
| aero on a win7 machine does wonders to its responsiveness.
| But even then pre-vista much of the win32 GDI/drawing API was
| basically implemented in hardware on the GPU. If you get an
| old 2d win32 API benchmark, you will notice that modern
| machines don't tend to fare well in raw API call performance.
| 30 seconds poking around on youtube, should find you a bunch
| of comparisons like this
| https://www.youtube.com/watch?time_continue=25&v=ay-
| gqx18UTM.... Keep in mind that even in 2020 pretty much every
| application on the machine is still relying on GDI (same as
| linux apps relying on xlib).
|
| Input+processing lag, USB is polling with a fairly slow poll
| interval rate (think a hundred or so ms). Combined with the
| fact that the keystrokes/events then end up queued/scheduled
| through multiple subsystems before eventually finding their
| way to the correct window, and then having to again
| reschedule and get the application to retrieve and process it
| via GetMessage()/etc. Basically, this is more a function of
| modern software bloat, where all those layers of correct
| architecture add more overhead than the old school get the
| ps2 interrupt, post a message to the active window queue,
| schedule the process managing the window messages.
| (https://social.technet.microsoft.com/Forums/windows/en-
| US/b1...)
|
| There are a number of other issues, but you can retune those
| three areas to some extent, and the results are a pretty
| noticeable improvement. Having someone at MS/etc go in and
| actually focus on fixing this might have a massive effect
| with little effort. But that doesn't appear to be in the
| cards, since they appear to be more interested in telemetry
| and personal assistants.
| derefr wrote:
| Sure. Mind you, my argument wasn't comparing _Windows_ to
| these sorts of "lightning-fast" systems--(modern) Windows
| isn't even a contender. Nor is macOS, nor KDE or GNOME.
|
| My points were under the mode of thought where you look at
| a modern system already _aimed_ at being "fast because
| it's lightweight" (e.g. XFCE), and then you ask why it
| _still feels laggy_ compared to BeOS /AmigaOS/etc.
|
| Where such "lightweight" DEs _do_ have perceivable latency,
| that latency mostly comes down to operations hitting the
| disk where these older systems didn 't. (Also the input
| stack, yes, but that's not universal: modern hardware still
| has PS/2 ports, and modern OSes still access those with
| rather direct reads. Many gamers swear by PS/2 peripherals
| --though probably mostly for cargo-cult reasons.)
|
| Some of the minimal-est Linux WMs, e.g. Fluxbox, _are_ run
| entirely from memory once started, and so are comparably
| fast--but need an explicit restart /reload to do anything.
| Plus, the apps launched _in_ the WM aren 't designed with
| the same paradigm, so most of your experience there is
| still slow.
| vidarh wrote:
| To expand on your point, one of my favourite examples of
| how slow a lot of software has become: A few years back I
| tested load time for a default Ubuntu emacs install _in a
| console_ against "booting" the Linux-hosted version of
| AROS (an AmigaOS reimplementation) with a customized
| startup-sequence (AmigaOS boot script) that started
| FrexxEd (an AmigaOS editor co-written by the author of
| Curl).
|
| AROS goes through the full AmigaOS-style boot,
| registering devices, and everything.
|
| It handily beat my Emacs startup.
|
| Now, you can make Emacs start quicker, and FrexxEd is not
| by default as capable (but it's scriptable with a C-like
| scripting language), but there's no wonder people feel
| software has gotten slower, because so often the
| _defaults_ assume we 're prepared to wait.
|
| E.g. one of my pet peeves with typical Emacs
| installations: Try misconfiguring your DNS and watch it
| hang until the DNS lookups fail.... It's not an inherent
| flaw in Emacs; you can certainly prevent it from
| happening, but so many systems have Emacs installations
| where you face a _long_ wait. Normally of course this is
| not a _big_ issue, but those setups still have a DNS
| lookup in the critical path for startup that adds yet one
| more little delay.
|
| All of these things add up very quickly. In the cases
| where these things are an issue in older software, they
| tend to either need to be explicitly enabled, or there is
| concurrency.
|
| I submitted some patches to AROS years ago, to implement
| scrollback buffers and cut and paste in the terminal, and
| one of the things it really brought back is how cautious
| AmigaOS was in making everything painstakingly concurrent
| all over the place. At the cost of _throughput_ but
| cutting apparent responsiveness.
|
| E.g. when you cut and paste from a console window on
| AmigaOS, data about the copied region gets passed to a
| daemon that will write it to a clips: device. It gets
| passed to a separate daemon because the clips: device
| that the clibboards are stored to, like everything else
| in AmigaOS can be "assigned" to another location. By
| default it is stored in T: (temporary). By default T:
| points to a RAM disk. However, clips: or T: could very
| well have been reassigned to MyClipboardFloppy:. In which
| case copying would prompt you to insert the floppy
| labeled MyClipboardFloppy: after which writing the copied
| section would take way too long. (That actual write to
| the floppy would happen in yet another task)
|
| So copying as a high level system service is handled in a
| separate task (thread).
|
| _Everywhere_ throughout the system everything that could
| ever potentially be _slow_ , and on a 7.16MHz 68k machine
| with floppies and limited RAM that was a _lot of things_
| , would be done in separate tasks so that at least the
| user could just get on with other things in the meantime.
| "Other things" then as a consequence often meant "just
| keep using the current application" because the
| concurrency would mean a lot of these things would lazily
| happen in the background.
|
| For e.g. a typical shell session, just pressing a key
| will involve half a dozen tasks or so, e.g. gradually
| "cooking" the input from a raw keyboard event, to an
| event for a specific window, to a event to a specific
| console device attached to a window, to an event to a
| high level "console handler" that handles complex events
| such as e.g. auto-complete, to the shell itself. It is
| inefficient in terms of throughput, but because the
| system will preempt high priority tasks (including user
| input related ones), and react with low latency and
| offload less latency critical tasks to other tasks, the
| system _feels_ fast.
|
| A key to this was that on a system that slow, a lot of
| the things that _could_ be slow, would _regularly be
| slow_ for the developers and would get fixed so that you
| 'd opt in to the slow behaviour. E.g. I doubt most people
| using Emacs are ever aware if their installation is
| slowed down by DNS lookups on startup for example,
| because most of the time it's fast _enough_ that you won
| 't really notice that one extra little papercut.
| zozbot234 wrote:
| > Everywhere throughout the system everything that could
| ever potentially be slow, and on a 7.16MHz 68k machine
| with floppies and limited RAM that was a lot of things,
| would be done in separate tasks so that at least the user
| could just get on with other things in the meantime.
|
| BeOS also has this design. Modern programming languages
| and platforms do make async and event-based programming a
| lot more intuitive, so we might well see this paradigm
| make a comeback.
| justin66 wrote:
| USB is polling at 1000hz now if the devices support it,
| it's really not bad. On the hardware side, displays are
| really the part that still needs some work in terms of
| latency, and FreeSync and G-Sync are evidence that the
| problems are at least being considered. The hardware in the
| PC itself is pretty good.
|
| On the software side, operating systems, desktop
| environments, GUI SDKs, frameworks, and so on could all
| take the problem a lot more seriously, but I wouldn't hold
| my breath waiting for that. There are too many people
| involved who believe it's reasonable to pause and play a
| little animation before doing what the user asked for.
| blattimwind wrote:
| > Animations and intentional delays. It can't be said, how
| much faster a machine feels when something like
| MenuShowDelay is decreased to 0, or the piles of animations
| are sped up.
|
| These animations effectively increase the input lag
| significantly. Even with them turned off there are extra
| frames of lag between a click and the updated widget fully
| rendering.
|
| (Everything below refers to a 60 Hz display)
|
| For example, opening a combo-box in Windows 10 with
| animations disabled takes two frames; the first frame draws
| just the shadow, the next frame the finished open box. With
| animations enabled, it seems to depend on the number of
| items, but generally around 15 frames. That's effectively a
| _quarter second_ of extra input lag.
|
| A menu fading in takes about ~12 frames (0.2 seconds), but
| at least you can interact with it partially faded in.
|
| Animated windows? That'll be another 20 frame delay, a
| third of a second. Without animations you're down to six,
| again with some half-drawn weirdness where the empty window
| appears in one frame and is filled in the next. (So if you
| noticed pop-ups looking slightly weird in Windows, that's
| why).
|
| I assume these two-frame redraws are due to Windows Widgets
| / GDI and DWM not being synchronized at all, much like the
| broken redraws you can get on X11 with a compositor.
|
| > USB is polling with a fairly slow poll interval rate
| (think a hundred or so ms).
|
| The lowest polling rate typically used by HID input devices
| is 125 Hz (bInterval=8), while gaming hardware usually
| defaults to 500 or 1000 Hz (bInterval=2 or 1). Most input
| devices aren't that major a cause of input lag, although
| curiously a number of even new products implement
| debouncing incorrectly, which adds 5-10 ms; rather
| unfortunate.
|
| https://epub.uni-
| regensburg.de/40182/1/On_the_Latency_of_USB...
| cellularmitosis wrote:
| > Disabling aero on a win7 machine does wonders to its
| responsiveness.
|
| Tragically, it seems the only way to completely get rid of
| tearing in youtube is to re-enable Aero :( (at least with
| nvidia hardware). RIP classic.
| StillBored wrote:
| I don't know if this still works, but nvidia had a
| "program settings" override, where you could select a
| .exe and force vsync on for particular programs. Might
| try messing with that. I did that for media player
| classic a long time ago.
| zozbot234 wrote:
| The thing is, you will always have tearing if you disable
| vsync (and compositing) for the sake of low latency. But
| tearing is only really perceivable when watching full-
| screen videos and animations, which is quite a different
| use case from general computer use.
| dialamac wrote:
| Not entirely sure your analysis passes muster. While it is
| true pigs like chrome and slack are the norm, computers still
| have many orders of magnitude more memory than 20 years ago
| and even if a large GUI app keeps state on disk most of it
| should be hot in some kind of cache whether an explicit cache
| or just the OS page cache.
|
| There are other forces at work.
|
| For instance on my primary workstation after a period of time
| from cold boot, pretty much everything is sitting comfortably
| in 32 GB of memory. A lot of time is more due to the
|
| 1) sheer volume of crap that has to be shuttled in memory,
| because memory accesses still aren't free 2) there's a
| surprising amount of repetitive CPU intensive tasks just to
| get a program started up on merely bookkeeping tasks like
| linking, conversion, parsing.
|
| In addition to all the built in latencies already mentioned.
|
| To prove this you can setup a system using a RAM disk and
| notice that responsiveness is often still subpar.
| tarsinge wrote:
| > It certainly is. Most of the reason modern computers don't
| feel instantaneous is actually a trade-off: old computers
| were less adaptive to change.
|
| To the point that old Macs had most of the system routines in
| ROM[0].
|
| [0]https://en.wikipedia.org/wiki/Macintosh_Toolbox
| rayiner wrote:
| This is true even on more recent vintage stuff. Little stutters
| are far more common on my iPhone XR with iOS 13 than they were
| on my old 6S Plus, much less the iPhone 5.
| cellularmitosis wrote:
| (straying slightly off-topic) I recently had the same
| experience with an Apple eMac. Grab a window, shake it around
| as fast as you can, or just move the mouse cursor around in
| circles quickly.
|
| "Whoa, why does this seem so much more responsive than my
| modern machines?" Two things, I think: 1) the mouse cursor is
| being updated with _every_ vertical refresh (80Hz), and 2) the
| latency of the CRT must be lower than an LCD.
|
| Not bad for a 700MHz, 18 year old machine!
| blattimwind wrote:
| CRTs are "dumb" devices, they literally just amplify the
| R/G/B analog signal while deflecting a beam using
| electromagnets according to some timing signals. As far as
| input lag goes, they're the baseline. For fast motion they
| have some advantages at leat over poor LCD screens as well,
| since non-strobing LCDs quite literally crossfade under
| constant backlight between the current image and the new
| image; we perceive this crossfading as additional blurring. A
| strobing LCD on the other hand shifts the new image into the
| pixel array and lets the pixels transition while the
| backlight is turned off. The obvious problem - it's
| flickering.
|
| LCDs that aren't optimized for low latency will generally
| just buffer a full frame before displaying it, coupled with a
| slow panel these will typically have 25-35 ms of input lag at
| 60 Hz. LCDs meant for gaming offer something called
| "immediate mode" or similar, where the controller buffers
| just a few lines or so, which makes the processing delay
| irrelevant (<1 ms). The image is effectively streamed through
| the LCD controller directly into the pixel array.
| jordache wrote:
| >holy crap the UI elements feel instantaneous.
|
| I seriously doubt it's an SGI optimization.
|
| I had an SGI Octane (multiple levels higher than an Indy). I've
| never felt IRIX's UI was noticeably more performant the
| contemporaneous Windows running on standard consumer PC
| hardware..
| cameldrv wrote:
| The weird thing is that I remember the Indy being perceptually
| very slow at the time compared to Windows or Solaris.
|
| I just started using Linux part time on the desktop, and it's
| significantly more responsive than MacOS, to the point that I
| prefer using it, even though the Linux UI otherwise stinks in a
| lot of ways.
| walkingolof wrote:
| It would be interesting to measure this perceived performance
| with a camera to get hard numbers.
| still_grokking wrote:
| https://danluu.com/input-lag/
|
| https://news.ycombinator.com/item?id=16001407
| Lutzb wrote:
| Just yesterday I started a VM of beta2 of HaikuOS for a good
| dose of nostalgia. Some observations: the responsiveness of the
| UI is instantaneous. So much so that it feels alien nowadays.
| Also the UI does not waste space, but at the same time it does
| not feel cluttered. Laying out windows feels more organized
| than Windows 10 or recent macOS. I can't really point out why.
| Lastly, having dedicated window borders is so useful for aiming
| the mouse pointer when reszing. At some point our UIs became
| more a design than a utility.
| keithnoizu wrote:
| I was really sad to see BeOS go the way of the dodo as a kid,
| was a great os.
| sabujp wrote:
| irix was my first unix that i really cut my teeth on
| cygned wrote:
| I had an internship at an IBM reseller and consultancy couple
| years back. When we were at a client's after finishing a project,
| they showed me their basement full of decommissioned computers
| and they let me take one home for free. I picked an SGI Indigo2,
| purple version, running IRIX. I had no idea what to do with it,
| so I played around for a couple of months and then made the
| mistake of throwing it away. (That still bugs me). I still love
| the interface and the way things were organized in the system,
| the file manager in particular. It ran nedit as editor and I used
| that on Linux for a couple of years going on. Nostalgia...
|
| edit: Remembering, I got the machine with original SGI keyboard,
| mouse and screen.
| exikyut wrote:
| Do you maybe have any viable excuses to say hello to that
| particular client again?
| bluedino wrote:
| I had a purple one and a green one! I'd play Doom (which didn't
| use the 3D hardware), played around with a few of the OpenGL
| demos, barely surged the internet with the ancient version of
| Netscape, then didn't do much else because I didn't have the
| CD's that came with it or the knowledge to try and build
| anything else.
| Erlich_Bachman wrote:
| Can someone please explain what are the main hypothetical
| advantages of this desktop environment? Even the article itself
| does a poor job of explaining this, it seems to assume that the
| reader already knows what IRIX/whatever is, and why did (do?)
| people use it over other environments?
| morganvachon wrote:
| As others have said, it's mostly nostalgia, and perhaps an
| effort to go back to what was a comfortable and sensible
| working environment from 25-30 years ago. It's the same reason
| the Haiku operating system is being developed: Nostalgia for an
| operating system that was far more advanced and beautiful than
| its contemporaries in the late 90s and early 2000s.
| rbanffy wrote:
| You can check https://maxxinteractive.com/ for more
| information.
| xvector wrote:
| It doesn't really help. What is SGI? What makes MaXX better
| than other desktops today? The page assumes too much
| background and doesn't really do anything to convince a new
| reader.
|
| That said the desktop looks amazing! Love the theme.
| rbanffy wrote:
| Maybe it's intended for people who used Silicon Graphics
| IRIX workstations in the past and liked the streamlined
| desktop experience.
| tomxor wrote:
| Neither myself or xvector have used IRIX, so descriptors
| like "streamlined" are not concrete enough.
|
| I feel like my i3wm setup is extremely streamlined for
| instance.
| pantalaimon wrote:
| I think nostalgia is a big factor here. With this you
| don't have to lug around an old workstation to experience
| it.
| pjmlp wrote:
| SGI is like Amiga, NeXT, Atari and plenty of other
| systems, there is only so much that one can put into
| words, without actually having used one, the reader will
| never get the whole point of it.
| tomxor wrote:
| I used to have an Atari ST, i love that little green
| crappy desktop for irrational reasons, but I wouldn't
| argue it's more streamlined than my modern setup.
|
| That's why I keep Hatari installed... but I don't try to
| use it as my development environment.
| reaperducer wrote:
| _I used to have an Atari ST, i love that little green
| crappy desktop for irrational reasons_
|
| Didn't the ST run GEM? Now that I think about it, I
| believe GEM could run on a bunch of different computers.
| I'll have to see if I can find a version to install on
| one of my banger laptops.
| hakfoo wrote:
| You can definitely put together a GEM on top of FreeDOS
| stack.
|
| I got some janky 486 laptops for note-taking in
| university and swapped between that and OS/2 3.0 with its
| rudimentary pack-in wordprocessor. PC/GEOS would have
| been even better, but was not readily available at thwe
| time, as I think it was still a commercial product
| targeted towards schools using hand-me-down PCs.
| Theodores wrote:
| IRIX 4Dwm was like the Rolls Royce of desktops. It didn't
| get in the way of what you were trying to do. This was in
| a time when you only ran one application on your SGI
| machine, e.g. 3D modelling. Compared to Windows, Sun and
| other desktops it was just nicer to use. The
| responsiveness, the cool fonts and the 3D bits with no
| anti-virus pop ups or other nonsense made it a joy to
| use. The icons were Susan Kate originals done in vectors
| before SVG was a thing.
|
| Things like the CPU performance monitor were a joy to see
| and haven't been improved on. Same goes for the screen
| savers, not that we have them now.
|
| There was nothing clunky about the magical desktop and
| normally your applications were tools that cost tens of
| thousands. Mere mortals thought they were seeing the
| future and what a brilliant future that was. The web was
| going to be VRML 3D in those days but we ended up with 2D
| bloat.
|
| The tools you have shape how you think and SGI just made
| your thinking creative and imaginative. Everyone else was
| on Windows which had great apps like MS Office but an SGI
| machine had none of those civilian programs.
|
| IMHO Ubuntu has a desktop that falls short of what SGI
| had even though it is an environment that doesn't
| distract in the way that Windows does.
|
| How I see it is that you have consumer operating systems
| such as Windows, ChromeOS and OSX and you have
| professional operating systems such as what classic UNIX
| machines had. Linux desktops are in this professional
| mould.
| abrowne wrote:
| > _The icons were Susan Kate originals done in vectors
| before SVG was a thing._
|
| Susan Ka _r_ e?
| aspenmayer wrote:
| Seems like it was Susan Kare. Probably an autocorrect
| fail, as I had the exact same thing happen to me when I
| typed her name just now.
|
| More information about her work on SGI:
|
| https://news.ycombinator.com/item?id=7527488
| Theodores wrote:
| Yep, autocorrect! Thanks for the link.
| aspenmayer wrote:
| Oh wow, I just noticed I quoted OP from years ago. I love
| how HN is able to come full-circle in this way. What a
| small world.
| abrowne wrote:
| Thanks for that link. I couldn't find anything searching
| her name plus "Silicon Graphics", "SGI" or "IRIX".
| richardjdare wrote:
| I bet a lot of the interest is from people like me who
| grew up with home computers in the 80s and 90s.
|
| In the old days Silicon Graphics had this almost mythical
| reputation. As a kid with a home computer I used to
| daydream about one day getting my hands on an SGI, what
| kind of games I'd be able to make on it.
|
| The computer scene was more fragmented back then.
| Graphics Workstations sat apart from home computers, and
| the ordinary Amiga or C64 user would only read about them
| in magazines or see them featured in TV shows about movie
| special effects.
|
| If you liked computer graphics, these TV shows and
| articles were like glimpses ten years into the future.
| Because of this, SGI became a byword for "amazingly cool
| computer with powerful, exotic graphics hardware that I
| will never get my hands on" Many of us hoped that one day
| we'd be playing video games on an SGI home computer or vr
| deck.
| owl57 wrote:
| In Pelevin's Generation <<P>>, published in 1999, all the
| politicians and other celebrities are not real people,
| but rendered for TV on SGI computers, complete with some
| comments on events that require more computing power to
| render and thus "happen" rarely or only in richer
| countries. No other brand (even an entirely made-up one)
| would look as natural in this myth.
| pkphilip wrote:
| SGI is Silicon Graphics - they were the pioneers in 3D
| animation especially for the movies, research etc. Jurassic
| Park was entirely rendered in SGI workstations.
|
| These workstations were incredibly powerful and extremely
| expensive (think > $250,000 for the higher end gear in the
| 1990s) but pretty amazing.
|
| Also, for the time it had very advanced user interfaces.
| SGI Irix was the name of the OS which ran on these
| machines.
|
| https://www.youtube.com/watch?v=Bo3lUw9GUJA
| trimbo wrote:
| It's a unix system, demoed in Jurassic Park:
|
| https://www.youtube.com/watch?v=dxIPcbmo1_U
| goatinaboat wrote:
| _What is SGI?_
|
| Seeing this question asked makes me sad. If you are
| browsing this on Linux then you're probably using code
| descended from Netscape which was developed by a guy called
| Zawinski on an SGI Indy.
|
| Or if you have seen a movie, then all the special effects
| are descended from work done on SGI machines.
|
| If you have fuel in your car, the oil field was probably
| originally found after running seismic analysis on an SGI.
| They were famous for their movie work but Oil & Gas was
| actually a far bigger market for them.
|
| If you have flown anywhere, the pilot was trained on a
| simulator descended from technology developed by SGI.
|
| If you program C++ then STL comes from SGI. As does the XFS
| filesystem.
|
| If you have seen a weather forecast on TV, that probably
| was done on a Cray, who for a while were owned by SGI and
| who developed a lot of their tech. Many TV stations used
| SGIs to render the forecast on the green screen behind the
| presenter too.
|
| If you have played Nintendo, the MIPS processor in it was
| developed by SGI. If you play games on PC, OpenGL was
| developed by SGI.
|
| They were once one of the most influential computing
| companies in the world. Now they are merely a legend, and a
| fading one at that :-(
| asveikau wrote:
| > If you program C++ then STL comes from SGI
|
| Been a while and I had nearly forgotten! It used to be
| that when you googled an STL container, SGI documentation
| came up first. This was occasionally annoying as there
| were a few things that were slightly different from what
| was standardized. If memory serves, they had a better
| hash table before the standard did...
| ajmarsh wrote:
| Most of the early image guided surgery systems were
| powered by SGI's as well.
| nix23 wrote:
| And dont forget Jurassic park:
|
| http://www.sgistuff.net/funstuff/hollywood/jpark.html
| nix23 wrote:
| >Seeing this question asked makes me sad.
|
| Me too, Irix, XFS (The Redhat std FS) and so much more
| was made by SGI.
| dazzawazza wrote:
| Reminds me of many months programming and learning the N64 before
| the PC based devkits were available.
| rbanffy wrote:
| Around 2000 or so Dell screwed up the delivery of a couple
| desktops right after I was hired. I ended up using an O2 to
| read my email, read documentation and to get up to speed with
| our tech stacks. I used it for about a month. Very nice
| machine, exceedingly responsive.
| op03 wrote:
| Don't get cheap on me, Dodgson!
| betimsl wrote:
| What a great way to preserve old UIs that one would rarely
| experience by other ways :)
| jasoneckert wrote:
| IRIX was my favourite UNIX flavour in the 1990s. As a result, I
| was tempted to try MaXX out after reading this post for purely
| nostalgic reasons. I keep an SGI Fuel in my basement (running
| IRIX 6.5.30 and everything from Nekochan) for when I need a
| nostalgia kick.
|
| However, after thinking about whether I'd actually use MaXX over
| GNOME for a few minutes, I decided that there was no compelling
| reason to do so other than nostalgia.
|
| Has anyone tried this out and decided to use it as their daily
| desktop? If so, I'm interested to hear your experiences and
| rationale. Cheers!
| easygenes wrote:
| Never used IRIX, but I genuinely really like the icon set in
| that first screenshot. Also, SGI Screen is still one of my
| favorite fixed width fonts.
|
| Also I think FVWM was heavily inspired from this, and I've used
| that as a very efficient UI over VNC (gradients, images,
| rounded corners, etc. are expensive in terms of bandwidth. The
| minimalist aesthetic of this interface conveys a lot of
| structure in little data).
| hakfoo wrote:
| FVWM was more a mwm (Motif) clone. It dates to the '90s, back
| before OpenMotif or Lesstif and having something with even
| that aesthetic was a step up.
| dilandau wrote:
| Looks pretty cool. There is interest in CDE as well lately, it
| seems (NsCDE as well as CDE proper).
|
| Beyond aesthetic reasons, it's hard to understand when one would
| really use these for daily driving. Anyone using this or CDE able
| to offer insight?
| themodelplumber wrote:
| I used CDE more than Irix (so I can't speak too much to Irix),
| and generally preferred it for its clean look. And that's the
| reason I'd use it for what I call Rebasing. Similar to bullet
| journaling, you find a clean slate that helps bring you to some
| sense of organization and the big picture again.
|
| Also similar to bullet journaling, it doesn't take a modern DE
| to do so. An old one with a usable text editor will do fine.
|
| In fact the clean lines, sensible design, and visible pixels
| give some of us a mental cue toward a simpler, gentler
| productivity reset. I find that my main DE is much less
| compelling in that way, modern though it may be.
| rbanffy wrote:
| How long does CDE to start on a modern workstation?
| danmg wrote:
| CDE started basically instantly on 90s workstations after
| login.
| ris wrote:
| "I know this! It's UNIX!"
| [deleted]
| ptx wrote:
| The website has instructions for building on FreeBSD, but how
| does that square with the license agreement that "permits The
| MaXX Desktop to be deployed and executed ONLY on the following
| Linux platforms; x86, x86-64 and IA-64"?
|
| (And there won't be an ARM version, I guess?)
___________________________________________________________________
(page generated 2020-07-04 23:00 UTC)