OpenBSD 6.0 lands

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.

Re: But will it run Crysis?

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.

Re: But will it run Crysis?

PS3 can play Crysis (was free on PS+ once)

PS3 runs CellOS

CellOS is based on BSD

Interesting to realise we ran whole companies on the sort of power now available in the average individual smartphone...

I've had no success installing it on my VAX, but it still does a lovely job of cleaning the carpets.

It never ran on VAXen that old, MicroVAX 2000/VAXStation 2000 was about the oldest hardware they supported, the rest of the list was 3000/4000 series.

@Bugger

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.

There's always NetBSD

That's what NetBSD is for. Install 6.1, or wait for 8 because the toolchain in NetBSD 7 can't generate binaries beyond super simple things.

Re: Yay!

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.

Re: Yay!

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.

Use FreeBSD. Linux compatibility was removed from OpenBSD because no one used it, and it wasn't very good. If I remember correctly it only ever worked on 32 bit x86 OpenBSD, too..

Alternatively use Slackware, Salix, or Gentoo with OpenRC

The emulation stuff was pretty limited in what you could run, and wasn't all that stable when I tried to use it - no great loss there.

You can run Arch Linux, or even Manjaro with OpenRC. In fact, that's what I'm doing atm.

Linux on VAX

Some people have tried:

http://vax-linux.org

Re: Does anyone know

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.

Re: W^X is for weenies on Von Neuman machines

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.

Re: W^X – write or execute

Oops - i see what they mean - as you were