The motivation for creating UNX.BZ was to help people get set up with a REAL shell environment on an Internet facing machine with the minimum amount of friction possible. You don't have to install a full distro or make a VM. You can just create an account, login and get to experimenting in a live, persistent Unix-like environment.

Because it is an always on and always Internet connected computer, you can use it to do periodic tasks (cron jobs) that need Internet access, or as a connection point you can reach out to from some other Internet connected device at any time. The HowTos have guides on the basics like setting up a website under your public_html directory.

1. Generate an SSH key pair. ed25519 is the most modern and secure key type and the server supports it. How-To: Generate, secure and use ssh keys
2. Sign Up and provide your PUBLIC KEY. You will get an email at the address you signed up with when your account is accepted and made active.
3. Login to your new shell account using your ssh key and the username you signed up with username@unx.bz

• Consider adjusting your .plan an .project files immediately: HowTo
• There is a list of installed tools on the sysInfo page.
• Articles on how to use the more important tools are in the HowTo pages.

Check out the Bash Tutorial at w3schools to get you started. It's a fantastic intro to the shell and the basic commands you need to get around on any Unix-like system. Bash is not the default shell on UNX.BZ (the default is the more basic sh Bourne Shell) but you can set your shell to be Bash if you like as it is one of the shells installed on the system.

We ask that you keep the total footprint of your files to 1GB or less. Going a bit higher is fine as long as it is temporary (temporary as in, a single work session where you free up the space immediately after the end of your work session). We ask that you strive to make your web pages as compact as practicable. Stick to text and thoughtfully compressed, reasonable resolution images.

Please run any CPU intensive jobs you have with a high nice level. This is particularly true for batch and cron jobs.

We have to pay for outbound bandwidth beyond a certain threshold and that expense comes out of pocket for us. If we find that people can't be trusted to be good citizens we will put hard quotas in place.

Don't put sensitive or proprietary information on the server.

File access by local users (users logged into the system) is governed by traditional Unix file permissions. The permissions are set such that other users logged in to the system have read access to files in your /home directory unless you change the default settings (using the chmod command) to stop them from having read access. You can change the settings of umask in your shell env to make the access bits set to your preference on newly create files also. Examples of situations where it is useful to allow other users read acces to your files are your .plan and .project files, or using your home dir to collaborate on a project with another user.

While you can adjust directories or files to be readable by only yourself they are not fully private as server administrators will of course still have access. And of course, in the very unfortunate event the server is ever compromised by a malicious attacker, any files on the server would also be compromised.

Other users also have access to data related to your login id stored in the /etc/passwd file. In a work or academic environment, /etc/passwd would typically store a user's real name and contact information. (That is optional on UNX.BZ)

We will of course do the best we can to keep unauthorized users from gaining access to the server or compromising it but it is important for you to understand this is a shared system in the first place and under the default settings other logged-in users will have access to many files in your /home dir BY DESIGN.

CONSIDERATIONS WORTH THINKING ABOUT:

If you put your real name in the GECOS field of /etc/passwd that will be discoverable by other logged in users. This is the normal behavior of a Unix-like system and the only way to opt-out is to not put your real name into /etc/passwd . You have the option to include or not include your real name when you sign up and you can change the info in the GECOS field yourself after your account is set up using the chpass command.

There is a recursive backroym for it now however:
UNX.BZ is Not X86 . BSD Zone

There was a time when the Internet ran on a wild array of hardware: VAX, 68k, SPARC, MIPS, POWER, PA‑RISC, Alpha and more—mostly running Unix as the operating system. One aspect that many of the hardware architectures the early Unix systems shared was the use of RISC (Reduced Instruction Set Computer) based CPUs. I’d go so far as to say that the bulk of early Internet servers were RISC based and only a fraction of them were CISC, the most noteworthy exception being the first web server, which ran on a Motorola 68030‑based NeXTcube workstation. NeXT machines were never common as Internet servers due to their high cost relative to their performance and intended use as workstations rather than servers but that particular machine is a example of one that was a server! In any case, the architectural diversity of the early Internet is part of what made it fun. The hardware and operating systems of both the servers and the clients were very diverse. You might have connected to a Sun Solaris SPARC based server from an Amiga or connected to an HP-UX PA-RISC server from a Mac. It didn’t matter so long as you had a terminal emulator and some kind of a dial up connection.

With the rise of Linux, and with some delay FreeBSD, Internet servers switched over to mostly X86 (Intel) architecture. By then most of the alternative home computer systems (Atari, Amiga, etc.) were dead or dying, the only real contenders still in the running were Windows and just hanging on (in that era) Mac. The diverse array of mostly RISC based hardware used for servers largely disappeared as the legacy server lines were crushed by the R&D economy of scale of X86, which as most people know is also the CPU architecture used in “PC” computers. At one point around 2010 the Internet was almost entirely served from X86-64 servers, many in hyper-scale clouds or data centers. However, around the same time, something interesting started to happen... ARM, which had been mostly used in mobile devices up to that point, had grown to become a viable server architecture. ARM CPUs are RISC based. Things had come full circle!

Server class CPUs based on ARM started to ship around 2018. Clients responded. The power savings and lower cost per unit of compute delivered attracted users. By some time around 2019-2020, ARM had really started gaining traction in the cloud, taking back some of the Internet. Now every hyperscaler cloud offers ARM servers, many of them using chips of their own design. (ARM licenses its ISA and CPU IP to third parties for inclusion into their own designs)

ARM was never used in the early days of the Internet for servers but ever since its rise in public clouds it has become increasingly powerful and grown to become a popular server architecture. Many hyperscalers and tech companies have migrated large portions of their workloads to ARM due to its power efficiency. RISC is back! (Well, it never really left...it just took a hiatus from the data‑center for a while.)

Now that ARM powers serious servers, we believe it deserves some first‑class Small Web and pubnix love. It's also just more... fun. What fun is it running the same exact setup as everyone else?

For many years now it’s been possible to host a shared server at a very reasonable cost. Why isn’t this format more common?

UNX.BZ is like stepping into an alternate reality where:

• BSD won the Unix wars rather than the (ironically) in the end less free GNU/Linux
• RISC never took a hiatus from server‑class machines
• “Social Media” and hyper-scale cloud providers never took over the Internet
• Go and Caddy were invented but...
• the old way of building web pages never got buried under a pile of React and front‑end JS "framework" hell.

Looking at it through that lens, UNX.BZ is like an anachronistic mash-up of the old and the new. It's more a spiritual successor rather than a literal retro-computing reproduction of a 90's pubnix. We run Caddy web server with PHP, CGI bin + Go native templating, which is vastly more powerful than the Apache mod_include style server side includes (SSI) due to the fact it ALSO has the ability to do runtime markdown rendering in the bargain. Much like the combination of a public access server running FreeBSD on ARM, these particular combinations of software are anachronistic relative to early 1990’s shared Unix hosting experience. HOWEVER...they are in the spirit of the common template of that era and what we imagine one logical alternate reality might have looked like. I mean, we deployed them in combination, right? So it’s an alternate reality that now actually exists!