QBASIC is software for the orignal Microsoft DOS which allows you to program in the language BASIC (Beginners All purpose Symbolic Instruction Code), I have been learning basic program structure, such as PRINT,IF,WHILE,INPUT and FOR, aswell as learning how to make subroutines

Above is ADDSUB.BAS, a program i wrote in QBASIC in which you enter 2 numbers then chose between addition and subtraction, I made it using IF statements to check if the input was ADDITION, SUBTRACTION or something else, aswell as using variables for the input sections.

Making my site dynamic

What this means

I recently made my site dynamic, meaning that i am using python to allow me to do alot more things on my site, this also means i am using more than just static HTML, i have also recently moved my site onto Github this makes editing the site much more convenient and keeps constant backups of it every time it is edited. I have used various tools to do this that it will cover in this section.

What Github is

Github is a website that is a DVCS - Dynamic Version Control System this means that it saves every version of any project (usually programming though) this is incredibly useful and is used massively worldwide, i am using it to store and transfer the source code for my site.

you can conveniently store and acseess older versions and also push new changes as commits, a commit is one small change (such as (in this case) adding this section of my IT page), after you make commits, you "push" them to the server meaning you always have a back-up, github can be used by lots of people who are all working on one project, such as in a company, to accomplish this effectively it has things called "branches", and this is how they work, Github stores all the commits (changes) in a timeline, this is normally in one long line, but with branches you can have seperate timelines and then merge them with the main timeline after testing them, it is considered bad practice to edit the main timeline without testing your code first.

With Github you make changes and add files and make commits from the command lines, for example, when you first add a file you use "git add (filename here)" to add that file so that the next commit can contain it, this is useful as sometimes you want certain files to not be added to Github like compiled code, passwords, etc, these are things you do not want Github to store for various reasons, to tell Github that you dont want it to even be able to see those files, you can use a ".gitignore" file which is a text file that tells Github to ignore certain files or even all files of a certain format (like .pyc files).

You can use the command "git commit" to make a commit with a small message, with this command, you can commit single files at a time or commit all the recent changes you made to add them to the timeline, with your commits you add a short message to describe them, you generally need to keep commits to a certain size, it is very bad practice to have multiple changes in a commit, and it also makes things a lot more complicated if you want to revert back to an older version. After you make each commit, it is stored locally on your computer until you "push" it to the Github servers with git push, this uploads it to Github so that it can be brought to the host servers or downloaded by someone or anything else, it also means you have a backup. git checkout is used to restore single files, or revert to the state of the last commit, this is useful but can also be dangerous as it will delete the current version that you have (funny story, i nearly lost the note files i have beacuse of that). and finally there's git diff which shows you all the differences between a single file or the whole project between the last commit and the current state.


HTTP stands for Hyper Text Transfer Protocol and is the basis of how the internet operates and has been as long as the internet's existed. HTTP has 2 parts, the client, and the server, (the client is the internet browser) the client uses "verbs" to tell the server what it wants to do, normally only 2 verbs will be used, GET and POST, and these are a lot less complicated than they seem.

HTTP verbs

GET is used to tell the server to send the client files such as the HTML for the website so that it can be displayed to the user. The POST verb is used to send files such as forms (for logging in) and images on social media, these are the two main verbs and the only ones that will probably ever be used, an example of another verb is DELETE which deletes a file or a folder, but it is rarely used. Every verb sent to the server has a response, usually the response will be a webpage telling the user what happened, for example saying that a tweet was posted, or a 404 page. A response from a server is in 2 parts, the headers and other files, the headers tell the internet browser what happened while the files are normally HTML telling the user what happened, headers contain a response code to tell the browser what happened simply, for example there is 200 (OK) this means that everything went well, a famous example of this is 404 which means the file could not be found 404 is sent when the URL is invalid and the body explains this to the user, another common error is 500 meaning internal error, there are far too many response codes to list but another common one is 403 FORBIDDEN, this is normally if you're not logged in.


SSH is a method for connecting to a remote server securely using encryption, it's similar to using a password but the remote server does not need to know the pasword to verify it.

How it works

SSH uses encryption to make a very secure system for verifying your identity, it has 2 parts, the private key and the public key, this is how it works, the remote server knows your public key, and only you know your private key, your computer generates a complicated sequence of numbers based on your private key and your public key, this number can only be generated based on your private key but can not be used to extrapolate your private key, this is much more secure than a password as the remote server also has to know your password and it has to be sent across the internet every time you want to log in. is a python module for developing webapps, i am using it for my site and it allows my to run my site using python so that i can have templating and other useful dynamic features. with you write code for each URL that responds with something, ie. a webpage. it allows for alot of dynamic things like passing URL variables into the HTML which can take advantage of complicated links.

Template system and static files

I am using (as mentiond above) to add templating to my site, i am using 1 base HTML template with the CSS loading code, year etc. and each page is just the content, i am using python to set each link to send an 2 combined HTML files as one page to the client. All the static files on my site such as images and audio files are store in the staic folder.


Usually when you have a command line running in a terminal once you close it, it stops whatever is running in it, but with screen you can run programs in a virtual terminal, meaning that another terminal is opened that you can make invisible and have running in the background, this is very useful for my site and i cover how in the deployment section.


Deployment means how i am putting my site live on the internet to do this i am using a screen session running the python file that executes my site, i am also using git hub to transfer the files to my site conveniently. The server that i am hosting my site on is actually a virtual server rather than a real server as it is more convenient and much much cheaper.On the server i am using nginx which has a configuraiton file for my site, we have location blocks within this file telling it how to handle each url, this is beacuse nginx can handle static files 100x faster than python can, the other location block is for everything else, it redirects the traffic to the correct port aswell as the correct IP address which is forwarded so the code doesn't think every request is coming from the server. I use the proxy_pass directive to specify where to redirect to. Here is some of the code.


        location /static {
                root /home/skamlox/;
                autoindex on;

        location / {
                proxy_set_header X-Real-IP  $remote_addr;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Commodore 64

The commodore 64 is an 8-bit home computer released in 1982, and it is the best selling computer of all time. i have been using the multi-platform emulator, VICE, to simulate a virtual commodore 64, and i have recently been using it to experiment with the version of BASIC that is built in to the commodore 64, it is an interesting language and the commodore 64s simple memory map allows for a lot of experimenting with altering memory adresses to manipulate the computers behaviour. C64 BASIC is quite fun to program in and i have already made a few programs in it, i will show and explain them below

i made this simple text adventure game and called it adventure, i used poke commands to set the capitalization and screen colours and regular prints gotos and inputs for the rest of it. for each area in which you can take an action, there is a print command explaining the enviroment and the options of your actions, it is followed by an input command, allowing you to set the current path and action variable to your desired choice, because input commands can only accept number inputs and it also removes a lot of spelling complication. after you input the number for your desired action the program moves on to the code that checks the current path and action variable and uses a goto command to jump to the correct code for that action, the path and action variables follow the format of path x action y, named as PXAY for example the first one is P0A1 this is path 0, action 1, the first action you can take on this path, and the first action in the game. this is how most of the game works, however there are other elements, for example the sit count, this is simply a variable that checks how many times you have chosen the 3rd option on the first action, if it is ever more than one, it adds an additional print command.

this is a program i wrote that is designed to add 2 numbers together, however it does not work as intended, although you can do 1+1 and other simple things, something even like 17+5 results in a completely wrong answer, i am not completely sure why this is, but i believe it may be to do with binary addition problems with the way the commodore 64 stores variables. i will not go into detail as to how the program works, as it is incredibly simple, it is the simplest way to add 2 numbers from the user together. unfortunately the save state file i created became corrupted, meaning i no longer can open, edit and run this program, however i was able to have the save working just enough to take the screenshot above, though even it is still corrupted.

this is not a program, it has no executable code and is simply a pixelly image portrayed using one of the c64s graphics characters.

This is a program i made that write to random areas of screen and colour memory, this uses every possible character and colour to slowly turns the screen in to a mess of purely random characters of every colour, though it is not truly random as i made it to never have a character the same colour as the background, it uses the peek command to check the current colour of the background and then compares that against the value of the character it is trying to create, if the values are the same, it adds 1 to the colour of the new character, meaning it is not only 100% biased against the background colour, it is also slightly biased towards whatever colour has a value of one higher than the current background colour. additionaly, thsi program uses the RND(1) function instead of RND(0), this is because RND(1) is much closer to pure random than RND(0) is, this is because RND(0) is based of off the internal clock, and it is noticably less random and is closer to a regular pattern. in the early prototypes i made of this program, i used RND(0) and did not yet include and colours, at the time i had not had the idea yet, even earlier and i did not yet know about the RND(#) functions and just placed the characters in sequence, i also only used character number 160, which is the solid full block graphics character, this created an interesting effect though, meaning that any characters it overwrote, remained the normal blue colour instead of the white colour that a fresh character is.

The image above is one of the endless possible results from a program that writes to random memory addresses with random values, this alters random parts of how the computer operates. This means that it can cause any kind of results, this was one of the more surprising results that i have gotten from trying this, often it will simply run for a few seconds and then freeze, often overwriting part of screen memory first. I wrote this program by setting 2 variables to random values then poking the memory address corresponding to one variable with the value corresponding to the other variable.

Assebly and machine code

BASIC is not the only way to program on a commodore 64, even though it lacks a built in assembler, machine code can still be manually entered in, assembly is a language which is extremely low level, it translates directly to machine code, and machine code runs directly on the hardware itself, with no interpreters in the way, this makes it considerably faster than BASIC as BASIC needs to be very quickly translated to machine code while it is running to be able to run. i have installed a piece of software called CC65 which can translate between the slightly more recent language C and assembly, it also uses a smaller built in version of a related program named CA65 to turn the assembly into machine code for the desired machine you want to run the code on. Most programs for the commodore 64 are not made in basic as it is too slow, this is because, as i said before, the BASIC program must be translated into machine code on the fly anyway, and that makes it incredibly slow, this is why i decided to learn assembly, because writinng machine code by hand is almost impossible, writing assembly is easier, but still hard, writing in C though is considerably easier than either of those, and since C is low level enough to be translated into assembly easily, yet still used a lot today, C is the language of choice for being translated in to assebly for old computers and even games consoles, all devices with a CPU or a microprocessor have their own version of machine code, however it is often standardized to a common type of machine code by using a more well known CPU, such as the 6502, 6502 assembly is incredibly common, and used in devices from all across the 1980s and 90s. I decided to try out writing a simple "Hello World" program in C and putting it on a virtual commmodore 64, i wrote a program that simply prints the text "Hello World" on the screen, i then compiled it and ran a quick test in a terminal before coverting it to assembly, the program ran pefectly, it printed "Hello World" on the screen and the stopped. this experience taught me a lot about how low level computer languages work, i also learnt about how "If Blank Then Blank Else Blank" statements translate into assembly from higher languages such as C.

History of UNIX

What is UNIX

UNIX is a multi-tasking and multi-user OS originating from the original unnamed AT&T PDP-7 OS from 1969, however despite being so old, it is still in very wide use to this day, being the basis of operating systems such as Mac OSX, linux, BSD and many other mostly server based Operating systems. UNIX was originally invented in 1969 by Ken Thompson, Dennis Ritchie and a few others, it was originally designed because AT&T wanted a time-sharing computer system, it was originally designed for the PDP-7 minicomputer mostly because of Ken Thompsons familiarity with the system, and was soon ported to the PDP-11, it was the first of many UNIX ports in fact, UNIX has been so succesful partly because of its extreme portability and modular design.


Multics or (Multiplexed Information and Computing Service), is an influential and early time-sharing Operating System which is based on the concept of single-level memory. Almost all modern Operating Systems were strongly influenced by Multics, quite often through UNIX, Multics was made by several of the people who made UNIX, and invented many features that UNIX perfected, Multics offered quite a lot of features that are staples of UNIX, and despite its faults, was quite competent for its time. UNIX originally started as an experimental response to Multics, however, the design team thought that Multics seemed to close-minded with its programs, and they wanted to try simpler solutions, i've heard UNIX described as a metal shop, you have lots of very simple tools and can make amazing things with them, compared to Multics, where you would have very purpose-built software for each task you needed to do. Multics has been used across the world, mostly in Honeywell servers, and the very final version was amazingly released in 2016, being version 12.6f. Multics is now no longer in use, but a Multics emulator has recently been developed and is in version 1.0 although it is quite limited, it is still an amazing achievement. Multics was also the first Operating System to use a hierarchical file system, its file system also supported long names, multiple names, and removable devices. Multics was overall, pretty good, i would say that it's not as good as UNIX, and it definitely did not have the beautiful design philosophy i talk about below, but Multics was definitely succesful, if not as well know as UNIX.

UNIX design philosophy

Another reason UNIX has been so succesfull is its beautiful design philosophy, i personally believe that the UNIX design philospohy is amazing, and even beautiful, and a full description of the different staples of its design philosophy can be found "The art of unix programming", which is a book written by Eric S. Raymond, and it can be read free online, its a great book and is surprisingly unbiased, here i will talk about some of the more important philosophies, but first, is the incredibly simplified version thats been coined as the core of UNIX philosophy, K.I.S.S. which stands for "Keep It Simple, Stupid", i will go in to more detail about what that means in a moment. I will now briefly cover all of the rules:

Rule 1. Write simple modules connected by clean interfaces. This means that you should write programs that do one thing and do it well, and that can easily be strung together to do simple operations like, reading a list of files and checking the contents of certain lines, this is why the pipe (|) exists, it takes the output of one program, and "pipes" it in to the input of the next, this also ties into many other rules.

Rule 2. Clarity is better than cleverness. This means that you should prioritze the maintainability of your code above its preformance, I think the description from "The art of Unix programming", does a very good job of explaining it: "In the Unix tradition, the implications of this advice go beyond just commenting your code. Good Unix practice also embraces choosing your algorithms and implementations for future maintainability. Buying a small increase in performance with a large increase in the complexity and obscurity of your technique is a bad trade — not merely because complex code is more likely to harbor bugs, but also because complex code will be harder to read for future maintainers.", this quote quite concisely explains the premise of this rule.

Rule 3. Design programs to be connected to other programs. This means that programs should be designed so that they can easily and seamlessly be directly connected to other programs, and should avoid comlicated binary information formats, programs should simply output normal text that can easily be interpereted by other programs, as a result of this, programs should be designed to accept simple text as input and process it correctly.

Rule 4. Separate policy from mechanism; separate interfaces from engines. This means that the user interface that a regular person would be using, should not be directly built in to the complicated technical backbones of the system, they should be kept seperated, as this makes it easier to use the same reliable base system, yet use any UI, this also makes it a lot easier to maintain, tieing in to rule 2.

Rule 5. Design for simplicity; add complexity only where you must. This means that you should always aim to make a design as simple as possible, complex programs and algorithms can often cause bugs, and make it much harder to maintain and alter in the future, this is quite similar to rule 2, but this rule is more about simplicity than clarity, though in fact, simplictiy is the easiest way to make something clear. Here is another quote from "The art of Unix programming", "a software culture that knows that small is beautiful, that actively resists bloat and complexity: an engineering tradition that puts a high value on simple solutions, that looks for ways to break program systems up into small cooperating pieces, and that reflexively fights attempts to gussy up programs with a lot of chrome (or, even worse, to design programs around the chrome)." Chrome in this case, refering to needless features designed to make a product more attractive to consumers.

Rule 6. Write a big program only when it is clear by demonstration that nothing else will do. This rule is very closely related to rule 1 in that programs, should be small simple and easy to use in conjunction, big programs are much more prone to bugs and hard to fix problems, this rule is designed to encourage writing small programs that can be elegantly strung together.

Rule 7. Design for visibility to make inspection and debugging easier. This rule is quite similar to rule 2, however, it refers to making programs visibly easier to read and understand for a human who is trying to fix, maintain or add to it, a human that quite probably will be you, designing programs that are hard to read will only make them lose their usefullness sooner, as a program that can not be evolved and added to becomes useless quickly.

Rule 8. Robustness is the child of transparency and simplicity. I think that one of the easiest ways to understand the concept of this rule is another quote from "The art of Unix programming", "Software is said to be robust when it performs well under unexpected conditions which stress the designer's assumptions, as well as under normal conditions. Most software is fragile and buggy because most programs are too complicated for a human brain to understand all at once. When you can't reason correctly about the guts of a program, you can't be sure it's correct, and you can't fix it if it's broken.", Programs should be simple enough to understand mostly in a few sentences, and by consequence, simple to debug and fix problems in.

Rule 9. Fold knowledge into data so program logic can be stupid and robust. At a glance, this rule seems very complex but in actual fact, it's quite simple. The idea is that important knowledge needed to operate properly in specific conditions, should be included in the input data for the program, for example, using options for a program that runs from a command line, for example 'dd if=/dev/device of=file.img bs=4096 count = 8192' this is an example of the program, "dd" it simply takes data from a device or file, and writes it directly onto another device or file, the options are and example of "knowledge" and allow the program to a lot of things conveniently, like writing images to devices, making images from devices, copying images, copying devices, stripping image data, stripping and copying data from a device. All of those thing and several more can be done simply with "dd" a program which just copies data exactly as it is.

Rule 10. In interface design, always do the least surprising thing. This rule is fairly simple to understand, it simply means that in say, a graphical interface, a button should always do exactly what you would expect it to, if it does some random operation, using, understand, and thus fixing a program can be a nightmare, you should never surprise the user with something unexpected, it just messes everything up.

Rule 11. When a program has nothing surprising to say, it should say nothing. This one is also quite simple to understand, and it is semi-similar to rule 10, if a program is running exactly as expected and nothing of any interest or nothing abnormal is happening, a program should be silent, there is no reason for a program to output lots of extraneous data that has no importance to the operation of the program.

Rule 12. When you must fail, fail noisily and as soon as possible. This rule is slightly harder to understand, but fairly easy to explain, for example, if a program has experienced an error it should let the user know as soon as possible, it wastes a huge amount of time if a program fails early on, but continues running for a long time, the user should know immediatley if a program has experienced an error, this also ties in quite well to a later rule.

Rule 13. Programmer time is expensive; conserve it in preference to machine time. this rule is fairly simple, the use of a programmers time is much more expensive and important than the time of the computer, computers shouldn't need to waste the time of the programmer or the user on operations, this rule is very closely related to Rule 14.

Rule 14. Avoid hand-hacking; write programs to write programs when you can. This rule is very closely related to Rule 13, Programmers should not be wasting time doing lots of simple operations like repeating lots of very slightly different text in a file or having hundreds of image files in numerical order, this is why there are so many simple tools to handle operations like these very easily, and even text editors such as "vim" that can perform complicated operations on large volumes of text, programmers should not waste time on anything, especially things that can be very easily taught to computers, that is literaly the point of computers, to make life easier, better, and more convenient.

Rule 15. Prototype before polishing. Get it working before you optimize it. this rule is another fairly easy one to get, you should not begin trying to optomize code for speed until it actually works, if you do that, you will introduce bugs, and make more complicated code that is a nightmare to fix, additionaly, you don't know which parts of your code will be slowest and will need opomization, you should never try to optomize code that does not actually work yet.

Rule 16. Distrust all claims for “one true way”. This means that there will never be one true way to do something perfectly forever, people thought that flashy transparent icons everywhere was perfect, but now it seems obviously flawed and bad, what people need will change over time, excluding simple operations, like copy and delete, but then again even those may be perfected or replaced by something more suitable for modern hardware, nothing is ever truly perfect, i think another quote from "The art of Unix programming" is quite fitting here, "Even the best software tools tend to be limited by the imaginations of their designers. Nobody is smart enough to optimize for everything, nor to anticipate all the uses to which their software might be put. Designing rigid, closed software that won't talk to the rest of the world is an unhealthy form of arrogance. Therefore, the Unix tradition includes a healthy mistrust of “one true way” approaches to software design or implementation. It embraces multiple languages, open extensible systems, and customization hooks everywhere." programs are never perfect and even if they're close, they should always be able to be fixed and improved as time goes on.

Rule 17. Design for the future, because it will be here sooner than you think. you can't trust any claim for one true way, nobody ever has it, not even you, you should follow these rules and always ensure that you can read your code and understand it completely, while keeping in mind that in the future, you won't remember every detail of your program, if you design for everybody, including you to be able to easily read and understand your code, it can easily be fixed and improved as needed, and lastly, i think the most fitting way to end this whole thing is with another quote from "The art Unix programming", "When you design code, organize it so future developers will be able to plug new functions into the architecture without having to scrap and rebuild the architecture. This rule is not a license to add features you don't yet need; it's advice to write your code so that adding features later when you do need them is easy. Make the joints flexible, and put “If you ever need to...” comments in your code. You owe this grace to people who will use and maintain your code after you. You'll be there in the future too, maintaining code you may have half forgotten under the press of more recent projects. When you design for the future, the sanity you save may be your own."


What is Arduino

Arduino is a platform and product based on an AVR chip by ATMega, it is designed for use in hobby projects, using only 2 chips, one containing all the flash code storage and ram and cpu and other main components, the other chip is simply for connecting the AVR to USB, allowing for uploading from the Arduino IDE (Integrated development enviroment) on a regular computer, straight to the Arduino. The Arduino nano is what i have, and is very small, it is designed to do simple operations on loop, doing things like outputting digital or PWM (Pulse-Width-Modulation) data to devices, for simple hobby projects, it is very good for things like this. Here i will cover things that i do with the Arduino

Multi-segment screen

You have likely seen a 7-segment display before, probably in a calculator or alarm clock, they use 7 line shaped segments to display numbers and even some letters, I have several 8-segment display, they are simply 7-segment displays but with and additional pin for a decimal point next to the main segments, i love these little displays, they don't work massively well with a breadboard, and they need a resistor between them and the Arduino (I'll talk about that later), but i still like them, i find it awesome that it's possible to make numbers light up just by uploading some code from a fancy text editor. I will talk in some smaller segments about what i did with these displays.

First attempt

The very first attempt i made with these screens and an Arduino was inserting the Arduino into a breadboard and wiring up the 5 volts line from the Arduino up to the display.
It did not go well.
The moment the arduino powered on the display let out puffs of smoke and snapped electrically, after disconnecting the arduinos power, i realised that the the voltage and amperage coming from the Arduino was too much for the little display, and it needed a resistor between the two, Adding a 470 ohm resistor that was lying around allowed me to light up a single segment with a wire on a breadboard, it felt great to see that little bit of the display to light up, i then connected it to Digital pin 13, which simply turns on and off on the default program "blinky", meaning that the display segment flashed on and off repeatedly, i knew then that i needed to do more with it.

Pin mapping & bad wiring

To explain this part well, i need to mention that i only have very long breadboard wires, making even just lighting up one segment is a mess of massive stick-outy wires, so i elected to simply wire the arduino and the display with only a resistor and not even bother using wires, It was probably a bad decision, it was an absolute mess of resistors going across board and over eatchother, in a massive and possibly dangerous mess of resistors, but it worked first try, which was awsome, i could now light up each individual segment simply by turning on a digital pin wired up to the display, from there i mapped each pin to a segment in a text file, meaning that i checked which Arduino pins lit up which segments of the display.

Number counter

Once i had a mapping i could write a program to turn on specific pins to light up segments in a way that made numbers, and once i set up all the numbers i could make it count, showing 1 number after the other and looping from 1 to 9, it felt amazing to see the little screen start counting out numbers just from writing some code and pressing an upload button, and from there i had another idea.

Image here

Random number generator

After making it count at a static speed i made it start very fast and slow down to a halt, which made me think of a random number generator with the way it slows down to reveal the number, so i started thinking of ways to make it random, because previously it just started at the same number and ended at the same number each time, so i decided to connect an induction coil (or just "inductor") to one of the analog pins, this meant that that pin was picking up all the random electromagnetic signals around the Arduino, The coil is not ground because if it was, the number would be the same every time because the ground would pull down the signal too low to pick up quantum noise, from there i just read from the pin and converted it to a number between 1 and 9 to start counting from, then it slows down to a halt and shows the final random number. I like doing it this way because it is using quantum physics to generate random numbers, one funny things is that due to humans finding patterns in everything, the numbers don't always seem random, most generators secretly try to make the numbers less random but in a way that feels more random to a human.

Image here

Steam Link and how it can be exploited

Have you ever wanted to play a full PC Game on your phone, since you can't use your computer from anywhere around the house? Well Valve have come to your aid with their relatively new Steam Link service, it's an extension of their Steam Gaming platform, the revolution that let you download games on the fly, but Steam Link addresses some of the downsides of PC Gaming.

Steam Link lets you stream games to and control them from your phone, anywhere in your house (Or wherever your computer is). You simply download the app and it works, you can connect you your computer and play Steam games from your phone! but it's not all peaches and cream, only a handful of steam games are really supported by Steam Link, the vast majority of your library will simply not work, luckily for us, theres a way around that.

Since Video is streamed from your computer, and input is streamed into it theoretically you can run any program, including any Steam game from your phone, and as a dedicated hacker, gamer, and Linux user i found a way to do just that. (Note: This techniqe has not been tested on Windows, Only Linux). The process is almost too simple, simply... go to your desktop, on your computers real connected keyboard use the keyboard shortcut Ctrl+Alt+D to return to the desktop and simply use your phone as a trackpad to navigate your computer, any program can be used this way, but what about games? specifically Steam games, well i have a technique for that too.

Garry's Mod running on a phone in a controller grip

Simply starting a Steam game on the computer before connecting with the Steam Link app will allow you to continue playing the game from your phone, however, you may need to use Alt+Tab on the PCs keyboard to change from Steam to the game, however this only needs to be done once in practice since the most recently played 4 games are shown on the apps start-up screen allowing you to select them from the app.

Steam Link is overall extremely useful, and paired with a controler is an invaluable gaming tool for anyone with a phone, even games which don't support controllers can be configured with the controller options in steam, though i'd recommend not doing that from the app. So all in all, i would recommend Steam Link to anyone interested in the idea, it really is worth a download, i mean the space for one app is hardly more significant than being able to play Steam games from your phone.

© 2018,2019