3 ms·
A company I worked for sent me along with two senior colleagues to a shop which was showing both the NeXT cube and the NeXTStep system ported on x86 hardware, a
by squarefoot 7y ago
A company I worked for sent me along with two senior colleagues to a shop which was showing both the NeXT cube and the NeXTStep system ported on x86 hardware, and the experience was totally worth the early morning (late night) wake up plus following 5 hours train trip; it was about 1993 or 1994. The cube was absolutely gorgeous looking, and being then myself an Amiga fan its Motorola CPU to me was something to be proud of.
The demonstration wasn't the usual smoke and mirrors wrapped in corporate speech: the guy wrote some code on the cube and built a small GUI program to show the development system and libraries, then he took the same code, copied it to a x86 machine nearby running the ported OS and built it to obtain the same program. Just wow! Back then running different hardware and CPU architectures meant sort of living on a different planet, and we just saw someone building a space bridge between two distant planets, making software development much easier.
We eventually got back with some promo material and the idea that we were did indeed experience a milestone in the IT development, but the price tag was something a very small company could not invest for research alone, so they abandoned the idea.
About WindowMaker: I loved it and used it extensively both at home and work in the early 2k. In one project I had to build the simplest possible user interface for roughly 50 remote stations hundreds of kilometers away where the users were mostly completely new to computers, therefore the risk of clogging the support seat with panic calls was really high.
Luckily WindowMaker and its kiosk mode came to rescue: I built a really basic desktop screen in which the user could not alter the system in any way, providing buttons for simple tasks like running a browser, fetch or send mail using a client, ask for remote support, print documents we sent through scp or mail attachments, shutdown/reboot etc.
An interesting challenge was easing the support login since all those terminals had dynamic IP, and we simply couldn't ask to the operators to start a reverse ssh from their side, but thanks to some Ruby scripts in the background, each remote machine would obtain and send its public IP and some more information to the local server in which a Ruby+Glade GTK app would add them to a list, so that the support operator would click on a station name and the ssh to that machine would open in seconds.
In the end it worked so well that the support colleague spent most of her time twiddling thumbs.
- asveikau 7y agoI used WindowMaker for years and liked it too, but to be fair, pretty much all decent WMs of the 1990s could implement a custom menu in the way you describe. It wasn't unique to wmaker. These days it seems like people are coming up not realizing that X desktops can be anything else than what Ubuntu gives on a default install, as if a full DE is mandatory. They don't know about launching a simple wm from ~/.xsession or ~/.xinitrc or editing the menus in such a WM.
- pantulis 7y agoAnd let's not forget WindowMaker's daddy, AfterStep.
- squarefoot 7y ago"It wasn't unique to wmaker." True but I wanted to avoid menus so that users would have immediately the options at hand, and other WMs, most of them at least, didn't allow fixed buttons on the desktop. If I recall there was also a kiosk mode on KDE which was more advanced than WindowMaker's but at that time one would have to double the system RAM just to run KDE without swapping, while Wmaker (as AfterStep before, thanks to another commenter for mentioning it) was much faster and less memory hungry. There was also a less known WM, probably Openbox or a similar named one which could be arranged with a kiosk mode, but turned out to be less stable and less udser friendly, so in the end WindowMaker made the best compromise. The purpose was essentially to give users a panel with buttons, to avoid those errors most of us would never think as possible but non technical users often do, like losing icons by dropping them into windows they then close, or call a software with the wrong argument by dropping an icon onto another icon, delete them accidentally, clogging the desktop with files, etc. A powerful unrestricted desktop environment in the hands of a non technical user can turn into many otherwise unneeded support calls, so it was necessary in that context.