Archive for the 'FreeBSD' Category


Xsokoban on NetBSD

Having been busy and stressed out lately I haven’t had much time for tinkering or gaming. This is where smaller games that you can play as a quick distraction can help, as they are easy to squeeze in between other jobs, and todays game is one such game.

Xsokoban is obviously a clone of the old classic game sokoban. The original was made for the PC-8801 way back in 1982 by Thinking Rabbit. It has since been implemented and ported to pretty much every system, Xsokoban is one such port for Unix systems running X windows.

There isn’t anything really remarkable about this particular port. The quality of the graphics is quite reasonable, and it works well on pretty much any system I’ve tried it on including my older machines such as the Sparcstation 20. I’ve even played it over SSH via my comparatively slow ADSL2 connection, and it worked really quite well.

Interestingly the game has been studied in the field of computer science, it turns out it’s quite a difficult problem computationally, being PSPACE-complete. Lots of different researchers have worked on different algorithms for solving and producing optimal solutions. The complexity certainly makes me feel better about getting temporarily stuck on level 6!

As far as enjoyment goes, it’s really enjoyable for the puzzle solver in me, even when I’m stuck. It doesn’t take a huge commitment to play for a short while, and is quite challenging! This particular port isn’t any better or worse than any other, so don’t go out of your way, but NetBSD and FreeBSD users will find it easy to get running.

This slideshow requires JavaScript.


Some words on X windows

I’ve recently been reading about and watching a few videos about the replacement for X called Wayland. Now I know very little about Wayland itself, but I’ve been a user of X since about 1999 when I first went to university, so I can’t help it, I feel moved to write about my current and old experiences. X is actually really quite an old protocol and was designed with different goals in mind than those modern desktop environments have today. The history is written all over the internet so I won’t repeat it, but it is evident that X was originally meant for the X-terminal connected to a mainframe case that was so very common at the point of its inception.

One of the questions asked was “what does X do well?”

Lincity via SSH

Lincity via SSH

The core of the X protocol is based around drawing primitives such as lines and circles but also includes pixmaps (bitmaps for those who don’t speak X). Here is an example screen shot of a program, lincity, that was one of the first games I wrote about here on my blog. In this case I’m running it through an SSH tunnel over an ADSL line with a maximum upload rate (to the X server) of about 75Kb/s. Because of the way X works lincity is not only able to draw to my remote display, but is able to animate the play area at a reasonable rate. This situation is something which VNC and RDP just can’t do over my connection. The remote machine running lincity is my old Sparcstation 20 with 2x 50Mhz supersparc processors, running a pkgsrc build at the same time.

Working remotely

Working remotely

Here is another screenshot of me monitoring my old Sparc, again doing a pkgsrc build (they take a long time with only 50Mhz you know). I’m able to get real time performance graphs and interactive terminals, all using about 5-7Kb/s data through a SSH tunnel, and much less when the remote windows are not visible on the screen. This kind of use if very common for me, not just to old machines, but also modern ones that are around my workplace, X and SSH makes it easy to start a program from any machine. This is very handy for testing and I can run software from home or work as I need.

XDMCP Chooser

XDMCP Chooser

My machines at home are running NetBSD, FreeBSD and Gentoo currently and whilst some of them are capable, none currently have a head attached. So I frequently use XDMCP and a X server on my windows machine to access them, and it works basically flawlessly. I realise this is a less common situation now, but with thin clients becoming all the rage in different forms, it seems this feature of X could be exploited more.

FVWM on my Sparc

FVWM on my Sparc

I love that there is so much variety in window managers and that there are light ones that make even my oldest machine quite usable with recent operating systems. Pictured here is my nostalgic favourite FVWM, which incidentally is still being maintained and developed. Windowmaker, openbox, fluxbox, etc, all deserve to exist and have a dedicated user base. They are interesting and useful, but mostly truly light-weight, making using older hardware viable. People like myself who collect and use old hardware find this useful to keep life in their old pride-and-joys.

No matter how it is implemented under the hood, for users the network feature of X is seamless and very easy to use, in no small part due to the hard work of the X11 developers, many of whom are working on Wayland. So what motivated the big change?

One of the major factors is X is becoming too large and difficult a project to develop and manage. A contributing factor to this is the explosion in extensions to it that made it kind of bloated. It seems they were sort of added willy-nilly (mostly during the Xfree86 days) to meet the demands of people developing the more eye-candy based style desktop environments we see now. Fortunately the X developers have been cutting much of the debris out of the extensions and have made the X server modular. Now if only the X server was actually installed/packaged in separate modules for each extension and the core it might make having a slimmer server easier, but as far as I know that’s not possible.

Personally I’ve not had much trouble with X. I mostly had problems with getting proprietary drivers to work for my GPU back in the Xfree86 days, but I’ve not had that problem in ages. I have only really seen the flickering that has been talked about over high latency network connections, never over any LAN I’ve ever used. I understand that it probably does have huge design flaws, and that a newer system and design is needed to meet the needs of new desktop environments. I just feel somehow, that when it’s gone I’ll miss X.


WindowMaker on FreeBSD

The basic WindowMaker interface plus a few applications.

WindowMaker on FreeBSD

This weekend I decided it was time to upgrade the software on the two functional Sun Sparc systems I have. I have FreeBSD on the newer of the two machines, and had been trying various window managers to use. The older Sparc has FVWM (recently upgraded to the latest version) on it so whilst it is really my favourite for reasons of nostalgia, I felt I’d like something different. I had tried XFce, but many features of it were broken on the FreeBSD/Sparc64 platform. So I installed a few other window managers to see what they were like.

I had never installed WindowMaker before but had certainly heard of it. I remember looking through many package lists to see many of the dock apps, and wondering about the window manager itself. WindowMaker has a similar style to the old NeXT workstations operating system called NeXTStep the system that would eventually become mac OSX.

The first thing I noticed when I fired it up was how minimalist it appeared to be. I found the root menu relatively quickly and managed to work out most of how it works within a few hours. I was quite impressed with how fast the interface responded when I clicked on items, although FVWM is a slight bit faster but not by much. There is a very nifty configuration program built-in that controls pretty much everything you could want to change. This makes it very newb friendly, I was able to set up my desktop the way I wanted it very quickly.

It isn’t the most pretty of window managers however, and there is no pager built-in. Workspaces are managed by the clip icon, usually at the top left of the screen. When using it via X on the local network it was quite fast, but over a VPN or SSH connection it became quite sluggish when FVWM maintains reasonable speed. I’ve heard that it can get slow if you have a large number of dock apps running.

Overall I quite like WindowMaker, whilst it isn’t a replacement for FVWM for me, it will be a nifty interface for my newer sparc machine. I like that I can configure most things with the user interface, and the large number of dock apps available for it. It isn’t so useful when I’m connecting into my machine externally however as the speed drops of significantly. It’s available on all the different distributions and the various BSD systems.


Freeciv on FreeBSD

Main Menu

Main Menu

Quite some time ago I worked at a radio telescope for 3 months as part of my work experience for my engineering degree. During that time I had an incredibly old machine as my work station, it was an original Pentium running at 77 Mhz. Because it was so old and because of the job I was doing I installed Linux on it. I used my favourite old school window manager (FVWM) and had it set up pretty sweet.

One of my duties for a short period of time was looking after the telescope after hours. This was called being the duty astronomer and was something everyone did at sometime during the year. Basically you were on call for if something happened to the equipment that the remote astronomer couldn’t handle. Most of the people using the telescope were often some distance away and did observations remotely thanks to the power of the net.

The main view

The main view

So I was spending many hours at my workstation after work hours, not working, and watching the telescope and waiting for something to happen. This is when I installed freeciv and started playing. Surprisingly even on that hideously old machine the game played quite well and was quite enjoyable.

The city screen

The city screen

Recently I compiled and installed it on my sun fire R280 machine which is running FreeBSD. The machine is headless so I was accessing the machine via XDMCP in order to play. There are too many graphics to play the game via a VPN connection, but it works very well over a LAN connection, mine is 100Mbps so it would be significantly better on gigabit.

City production

City production

I was playing on the standard GTK based client, but there are other clients with support for the Xaw, Xaw3d and SDL toolkits so you can get it to work on systems without GTK installed. Most of the clients look pretty much the same with the exception of the SDL client which imitates the interface of the newer civilization games.

Research tree

Research tree

The graphics for units and the terrain are consistent across all the clients so you won’t be confused trying to identify units or terrain. There are several tile-sets to choose from as well so you can customise the way the game looks. Unfortunately the newer versions of freeciv don’t have as many tile-sets available as the older ones. Some times I have found some of the text is difficult to read because it is so small.

Other civilisations

Other civilisations

If your platform supports sound there are some sound effects for events such as combat. On the sun machine I didn’t have sound, however I do have it working on my macbook running the SDL client for freeciv. The sound is reasonably good, but not essential to game play. There isn’t any music in the game, but this leaves you room to play some of your own.

The SDL client

The SDL client

The game play is of course very much like civilization. The default rules most resemble the rules of civilization II with some differences. There are different rule sets that you can use, for instance there is a rule set for the first civilization game. There are unfortunately many subtle differences in game play that may annoy some players. The main draw card here is that multiplayer games are supported. This is reflected in the way diplomacy works differently to the commercial games.

Personally I actually prefer the original civ II game play, graphics and sound, but freeciv has some merit of its own. There are some features that are nice such as extremely large maps, and many more players in one game. The rules are subtly different which can change some of the strategies for play, but for the most part the same strategies will work. It still is fun to play for me, but it really will be a matter of personal preference as to whether you enjoy it or not.

This slideshow requires JavaScript.


XBlast on NetBSD

XBlast was created by Oliver Vogel and Garth Denley between 1993 and 2006. It is a multi-player game that is based on the Bomberman games which were popular on many old home consoles as early as 1983. I had never previously played a Bomberman game before so I have very little frame of reference for comparison to the older original games,  many of which I’ve read about have a similar multi-player facility. I built XBlast on my old Sparc hardware as I have done for many of the old X based Unix game. It built with out any problems and seems to run quite well even via XDMCP over the network. I haven’t tried building it on other platforms but I suspect that it would work on most Unix like systems.

The graphics for the game are colourful, and look fairly nice. Like I said they seem to work over the network with very little to no performance issues at all. The user interface has many options and I found it a little confusing to use, in particular when trying to use the network play options on what they call central. The game has an option for sound, but that did not work for me on the Sun platform so I can’t really comment on the quality of it.

There is no single player option really for this game, you can play multi-player games over a LAN, the internet, or on the local machine by sharing a keyboard or using multiple controllers. I wasn’t really able to get multi-player working, either because there is no-one on-line or because I couldn’t work out how to get the internet play working properly. I was able to play against an AI on the local machine and found the game was a little confusing to play at first. The controls for movement seemed to worked fine, but when I tried dropping bombs I’d find that it was a bit slow to do so, or wouldn’t do it at all for some unexplained reason. The game basically involves running around trying to get power-ups whilst avoiding bombs and laying your own to get your opponent. There was little of any kind of puzzle element and after a period of time the level space would start shrinking until some one gets killed or caught in the new wall sections appearing. There are many different levels/arenas for you to play in each with it’s own rules for game play. Some are quite large whilst others are relatively small. They change your strategy in where you try to place your bombs, and how you go about avoiding bombs placed by other players.

I think the software itself and the graphics are crafted quite well, but the game does get old fairly quickly. I think that it would definitely benefit from having a single player campaign with puzzle elements much like the original Bomberman games. I found myself getting bored fairly quickly, and I didn’t really enjoy the experience. This may be different for you if you liked the multi-player elements of the Bomberman games, or if you were a fan of them. Otherwise I’d suggest you’d probably be better off finding another way to entertain yourself.


Xboing on NetBSD

Xboing is a breakout style game for the X windows systems, it was written by Justin C. Kibell in the years 1993 – 1997. It is written using the basic X toolkit libraries so will run on pretty much any Unix system with a half decent compiler set. The game models itself after an arcade machine, and even goes as far as having an attract mode (or demo) to show the basics of the game.

The graphics are very colourful and pleasing, and I’m happy to report it works very well even on very old hardware, or via an XDMCP session over the local network. I found it worked quite well on my old sparcstation. The animations and movement of the paddle and ball are fast and this helps the controls be responsive.

Sound didn’t work very well for me, it froze the game on the sparc, which could be caused by any number of issues. The game doesn’t suffer for not having sound, so if you have similar issues, I’d just turn the sound off.

Gameplay is very similar to all the other break out classics around with some differences. For instance, the power ups do not drop out of bricks when they are broken. Instead they themselves are bricks that when you break them give you the power up contained therein. You get a limited supply of bullets in the game to help you clear areas faster. This is very handy when there are only a handful of bricks left that are quite hard to hit with the ball. That being said, because you have a limited supply, you aren’t tempted to go shooting down every brick in a level as it will affect how much ammunition you carry over to the next level. Interestingly you can accidentally shoot your ball and end your game if you aren’t careful. I’ve also noticed you can squeeze the bullets up between columns of blocks to hit something at the top of the screen. This was useful when the “eyeball dude” went past, I had a chance to shoot him for points.

The default setting for the game is quite fast, so you will probably want to slow it down. Don’t slow it down too much however as this impacts your ability to score and get bonus score for completing a level quickly. Control is via the mouse, and is very responsive and quick. The only problem I had was when I accidentally moved my mouse out of focus and the paddle stopped moving. This may not be a problem for you depending on your window manager, I could always configure mine to improve the situation!

I found that the game was quite fun, and offered something different to the other breakout games out there that mostly follow after the classic Arkanoid. The challenge is high enough depending on the speed you set, and you shouldn’t find yourself bogged down trying to get that last one or two bricks for very long. So if you are a fan of breakout games, have a Unix system, and want to play a good breakout game, I’d recommend giving Xboing a try.


Xpilot on Mac OS

Xpilot is a game very much like Thrust on the C64, but with many more complicated features and game-play. The game is one of the pioneering games in internet gaming, it was one of the first to include in game chat and different game modes such as capture the flag. It was written for unix workstations, and the first public release was made back in 1992 by Bjørn Stabell and Ken Schouten. Xpilot runs on most unix systems including Linux, FreeBSD, NetBSD, Mac OS, ans Sun OS that I know of, in theory if the X libraries are installed Xpilot should run on it. You can build it under cygwin for windows, but I believe that there is a proper windows port you can use.

I built the game on my macbook which runs Mac OSX Lion. It was fairly straight forward to build, but I needed to install the imake utility from macports to make my life easier. I also had to modify some source code very slightly for it to work on my computer, so I would suggest using the version of it in Fink. I have previously built and ran the game on NetBSD, Linux and FreeBSD without any issues.

The games system requirements for getting it to work are fairly low, but it’s a good idea to not run it on very old hardware. Anything younger than about 10 years old should be fine. It can demand a lot of the X server, and can require a lot of your network if your X server isn’t local to where the game is running. I tried running the game on my old sparcstation to see how well it would work, it seemed fine, but the server used all of one CPU and the client a good part of the other. I was running the X server on my desktop machine which was taking some of the load off, so it would be unlikely that the old machine could have coped very well with the full load of the game unless I upgrade it.

Because of the systems the game was meant to run on originally, there is no audio as many X terminals never had sound and there wasn’t a uniform way to access audio hardware when it was first written.

The game play seems very complicated at first, there are tons of controls, options and bonus pickups to learn about. The initial keyboard controls are a bit unintuitive, so it is a very good idea for you to change them before hand. This can be a little difficult because you need to modify your configuration file to do it. Once you have changed to controls to something that suites you better, it is a much easier and better game to play. I found I was woefully outgunned against a bunch of robots, and I am still pretty much a newbie at piloting. My scores often go negative. Very negative. I have occasionally done better but that was weirdly enough when testing on the sparcstation.

If you’re looking for more information about how to play or configure the game there are numerous newbie guides of which I found this one to be quite good. The game is very addictive and quite fun (more so against humans than robots!) and many people still play it today. There are also a couple of newer ports that are partly compatible with the original called xpilot-ng and xpilot5. I’ve also noted there is a java client available on source forge and an app for the iPhone available. I tried xpilot-ng quite a while ago and think it’s pretty alright, but I haven’t tried the others for comparison.


Xtris for NetBSD

Xtris was written by Roger Espel Llima, and the release that I have was completed in 1996. It is a Tetris clone for X windows on unix like systems. It works on most Unix systems and I played it on NetBSD. The game plays pretty much as you would expect a Tetris game to play with one major difference.

Xtris is essentially multiplayer, the program automatically starts a server and connects players on the same machine together for competitive play. The rules are pretty much the same as ordinary Tetris, except when a player makes enough lines another player has some blocks added to their play area at the bottom pushing what they have up. This can fill up a players play area quite quickly if they are unlucky, and obviously cause their game to be over. The game continues until there is only one player left and after a few seconds a new game begins.

If you find that you are alone on the machine you are able to start-up some AI players (called bots) to play against. The AI isn’t as good as human players and I can pretty easily beat it by basically playing faster than it does. This is obviously a lot more difficult to do on faster speed settings, so if you want a challenge increase the speed. Also if you are not interested in playing against other players you can choose not to. Although this does require a command line switch.

The graphics are pretty simple, and travel over the network (via X) without any trouble at all. I used my Sparc station to play the game, and had no performance issues at all. I didn’t have any other people to play against so I can’t comment on what it’s like playing against other people. Playing against the bots is challenging, but not overwhelmingly difficult.


Xmris on NetBSD

I had not heard of Xmris before I installed NetBSD on my sparc. I found the game when looking through package source for games that I could install and test out. It turns out that it will work on pretty much any Unix that has X windows installed. I played it and found that it was very similar to the DOS game Digger , and found upon looking into the manual page that they are actually both a clone of the arcade game called Mr Do! Xmris was written by Nathan Sidwell back in 1992 originally, but updated until 1999 at version 4.05. Luckily for us Nathan seems to have put the code up on sourceforge here for all of us to enjoy. You seem to be able to run it on any Unix system that has X windows installed and was very easy to compile. I ran it on NetBSD on my sparc, and found the performance quite good on old hardware and using X across the network. From what I have seen Xmris is a much more faithful clone/port of the arcade game. From the games man page…

You control a gnome, who can walk around a garden, along paths  already
marked,  or  create  new paths wherever you wish. You also have a ball,
which can be thrown in the direction you’re facing, towards the gnome’s
feet.  Points  are scored for collecting cherries (if you collect eight
cherries without stopping or  pushing  an  apple,  you  get  a  bonus),
killing monsters (by squashing them, or throwing the ball at them), and
collecting the prize left when all the monsters have come out of  their

Much like Digger the level ends when you collect all the cherries or kill all the monsters who do not seem to re-spawn. The game play is slower and a bit less frantic than Digger, and seems to be a bit easier in the early levels. In later levels you get more monsters and the game appears to speed up increasing the challenge significantly. It can be very difficult to get a high score as strategies that help you survive do not help you score points. If you are on a system with many other users on it you will notice that there is a shared high score table that everyone can compete to get to the top of. You also have a separate personal best list, so if you do not make the system wide table you can still see how well you are doing. I quite enjoyed trying to beat my own scores and trying out different strategies to survive longer or get more points.

The graphics in game are quite pleasing but also functional. If you are unfortunate enough to not have a colour X terminal it will also run in monochrome. Playing from a XDMCP session is quite good, and does not seem to over use the network bandwidth or resources on the X server. Unfortunately there is no sound to speak of, but given that most X terminals do not support sound this is not surprising. This game also has some nice features, like customisable controls and a level editor. I found it was a good idea to customise your controls as the default ones did not make much sense to me. The level editor is pretty easy to use and lets you add comments and names to each of your levels. You can play custom levels by using command line options to load them.

In conclusion Xmris is a good arcade action clone, and if you have a linux or unix system I would recommend you give it a try.


FreeBSD 9.0

I downloaded a copy of FreeBSD 4.7 many years ago intending to try it out, but never did for lack of spare hardware. Along with its siblings (NetBSD and OpenBSD) to be the closest descendant of the early BSD systems made through out the 80’s and late seventies. I won’t go into details about the history, as I’ll be terribly inaccurate, and there are a lot of documents around the web already detailing the history of Unix and BSD. Here are a couple of links.

The Wikipedia page

The Open Group: Unix History and Time line

Recently I installed NetBSD to run on my old sparc, which re-sparked my interest in the BSD platforms. This week I installed FreeBSD 9.0 on my virtual machine I have on my Macbook Pro as a matter of experimentation to find out what it was like.


Installation was relatively simple and performed via a text mode using simple keyboard commands. There wasn’t much to configure, but also not many options for the base system, which I think is because of the nature of how slim the initial install is. Most of the installation is dealing with setting up the disks and partitions, and which basic services are enabled. I did note that there was no option to install the X windows portion off the disk. Like NetBSD it is important to know your Unix stuff before jumping in, you should be able to use a shell and preferably also know the basics about building software. The amount of disk space you need will depend on the software you intend to install. The base system once installed is quite slim requiring very little in the way of disk space and other resources to run quite well.

Adding More Software

The main package management system for FreeBSD is called ports, it is one of the older package distribution systems and as such has more packages available for it than the other BSD systems, and more than many of the Linux distributions with some notable exceptions. You have two options for installing packages, one is installing binaries provided to you by either CDROM, or download. I wanted to try out the ports system for automatic download and building of packages and I wasn’t disappointed. First I installed bash and nano as the base system didn’t have either of these two there by default. The build process was pretty simple, you just located the directory of the port you want to install, and then type make install. During the build process you are asked about the options you want to use when building the software. This is better than pkgsrc as it required you to edit some files to change what options you wish to use. I went on to build X and attempted to build Gnome 2. I must have changed an option that gnome didn’t like as I couldn’t get it to build completely, but I am sure this was my mistake, I just couldn’t work out how to fix it within the limited time frame. I had a bit of trouble getting gdm to work as well, but that was solved after a bit of reading on the FreeBSD website, but other software such as xdm and FVWM were very simple to get up and running. Xfce built, installed and ran quite well, and to me looks like the best option for user interfaces as it is lighter than both Gnome and KDE, but has many of the features that most users want out of a modern operating system. If you’re after a minimalist user interface, FVWM is a good choice and has one of the later versions in ports as compared to pretty much all the other systems out there. In doing all this I found that it can be a very lengthy process to build the larger bits of software from source, the upside being when it is done, it’s optimized by the compiler for your hardware, and you get the latest version if you keep your ports collection up to date. Otherwise you should pick the binary install option as this will save you alot of time.


FreeBSD is better supported than its cousins NetBSD and OpenBSD, and as such has more in the way of packages that are updated more frequently. FreeBSD and it’s siblings have the advantage over Linux in that they seem to have a more mature and stable code base. For instance, in the time that I’ve been using Linux, the kernel and supporting utilities have changed dramatically, making some older software completely un-buildable now, where as the BSD systems seem to move slower and are keeping compatibility for older software alive. I think this contributes to them being more mature than Linux as the software has time to have the bugs worked out. I’d say this methodology also affects how the design and user interface is built. Configuration via configuration files seems to be easier than Linux, as all the files were generated by humans and as such are easier to read. For instance setting up gdm to start with the system required only adding two lines to the rc.config file.


It seems that some software creators for various reasons are dropping support for BSD and various other Unixes in favour of only supporting Linux. I think some of it is ideological, which I disagree with. Some of it is because of the problems supporting multiple platforms, this particularly applies to projects that are supposed to be libraries or system utilities for other programs. This has a ripple effect making software further down the line also incompatible with non-Linux systems. What is the point in using a library or package that interfaces with the kernel for you if it doesn’t support many kernels/operating systems? You might as well write it yourself! You may have heard that Gnome is officially only going to support Linux in its future releases. I’m not sure how true this is, but it could be quite an inconvenience for a good many BSD users as well as people on Solaris and commercial Unixes that use Gnome. It seems the root cause is that the automounter package used by gnome and a few others (Xfce for example) have decided to drop support for the other operating systems. I hope I’m wrong, as I’d hate to see the community of free software developers divided.

BSD versus Linux

There seems to be a difference in how both the communities view what an operating system should be. The bigger Linux distributions take the view that everything is part of the operating system, which is very evident in something like Ubuntu. There also seems to be a move towards hiding the traditional Unix portions of the operating system from users, which can be a good thing when not over done. BSD seems to see the operating system in a minimalist kinda sense, where the base system is small, stable and mature. Everything else including the user interface is up to the end-user to customise. It’s also not afraid of being a traditional Unix system.

There are also some differences in licenses, but that’s not really something I’ve ever really cared about. I only want to know that the system is free, and the source is available and can be modified.


FreeBSD is a good place to go if you’ve been curious about BSD systems and have some experience with the command line on something like Linux. You’ll find there are more packages, that are updated more often than its siblings NetBSD and OpenBSD. However it’s not as well suited as NetBSD is for using on exotic hardware such as the sparc platform, so you will want to run it on a PC or PC compatible. There is very little in the way of cruft in the base system which means there are few points of entry for hackers, so it would actually be a better option for running a server than many other systems. But you do have to set up all the components yourself, which does give you more control, but also takes more time to do. To use it as a desktop system workstation again needs a lot of time to set it up initially, but you’ll have exactly what you want.

Enter your email address to follow this blog and receive notifications of new posts by email.

Mister G Kids

A daily comic about real stuff little kids say in school. By Matt Gajdoš

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.


retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way