
Re: But will it run Crysis?
No, Crysis *3* now. And I actually consider this important since games are one reasons people like myself are stuck with Windows.
OpenBSD developers might be keen on the 1980s in their artwork, but not in their operating system: Version 6.0 has just landed, and the maintainers have killed off VAX support. Apart from a logo that pays homage to the cover art for the iconic album The Wall, there's a fair amount of new stuff landing in OpenBSD 6.0. W^X – …
This post has been deleted by its author
Probably not, makes a fine firewall though. The only method I can think of is VirtualBox and a suitable OpenGL driver, but I'm not sure if VirtualBox is fine on OpenBSD, and there are no binary drivers due to OpenBSD's code policy, so OpenGL and general driver support is lacking a bit.
It will however run the open GTA 3 engine, if you're that way inclined.
I remember when we got on of these - a hole fucking MIP!!! We ran about 2 dozen chip designers and support coders on it and later added 120 secretaries doing 'word processing' on VT100 terminals.I had a lovely bit of code that crashed and left me in admin mode so I could up the priority of my small batch jobs so they would run in a minute or two instead of a couple of hours. Pissed of the admins but I dont think they ever worked out why everyone else went a bit slow.
Title says it really.
The big question now is whether I upgrade the mail server in-situ (oh how you envy those of us who live on the edge), or do a clean one on hardware that's actually from this century.
Or go the ultimate dead-fancy route and get a new machine that's a tenth of the price of the old box, at least fifty times faster, and uses a quarter of the power... hmm... I'm seeing the glimmer of an excuse here...
Also probably quieter, cooler, and using modern storage that basically 'just works'.
In the near future I'm going to replace my home firewall, a pentium 3 system with compact flash card, and an ISA graphics card, with one of these : http://www.pcengines.ch/apu2c4.htm. Looks shiny, definitely works, with an AMD chip in it that doesn't suck.
The only possible breakage that comes to mind is wxallowed (ikely) needed for /usr/local - if your /usr/local is *not* on a separate partition, you will need to either make it so before upgrading or reinstall. Otherwise upgrades from N.m to N.m++ tend to be ultra-smooth.
The simple sysmerge cases are even handled by rc.firstboot, and you will be notified by email to root of anything that needs another sysmerge run. Most of my 'keeping your system in trim' blog post should stil apply - http://bsdly.blogspot.com/2012/07/keeping-your-openbsd-system-in-trim.html - but it's probably time to give that a freshening up as well.
When discussing editors, there's always a bit of touchiness around "what do you call decent?"
If you have real Vax, running a real Vax OS (VMS), you could use TPU, especially with the EDT keybindings for those who started out in KED. If you like that, but want more OS-agnosticism, you might look into the hacked micro-emacs that has been around for yonks. I've used it on everything from CP/M-68K to OS X, via System III, Linux, DOS (x86, not S/360) and others I have forgotten.
And of course there's always Teco (already mentioned) vi, and emacs. I used xemacs under VMS back in the day, as well as under Irix. One guy I knew used a WILBUR clone written in FORTH in PDP-11 emulation mode, but I think that he was just yanking our chains.
I love how long it took Intel / AMD / ARM to implement some kind of method to keep Executable code and Data separate, and the vast majority of software still doesn't support it. The vast majority of exploits nowadays exist only because a machine can be tricked into running user data in a privileged context. It makes me sad to see a complete lack of Harvard-Architecture machines out in the world (I have VHDL skills and a couple FPGA dev kits, if anyone wants to join me in building a Harvard-Arch general-purpose computer).
The StrongARM was the first ARM to have separate instruction and data caches with no automatic synchronisation, which broke execution of code written in to data areas as well as self modifying code, mainly affected games.
But with RISC OS being a friendly place with hardly any malware over its history, a friend of mine wrote a very clever bit of code called StrongGuard which detected attempts to execute code in memory that had been modified in the data cache, and synchronised the instruction cache. It the cache syncing was quite slow, but as the old code was coming from ARM 3/6/7s and the StrongARM was between 20x and 7x faster, games still had to be slowed down to be playable.