-
Notifications
You must be signed in to change notification settings - Fork 0
Home
NOTE some of this page will be things that some of the users of RISC OS outside of the USA may see differently. Like the lack of regulation in implementing extension modules (on the other side of the Atlantic creek it seems they believe in central authority model that used to be foreign to USA users).
RISC OS has always been easier to use, and program for than other OS's. That is using the actual OS and its API/ABI. Even today I can not find any Linux, Win32, Win16, OS/2, BeOS/Haiku, MROS, Menuette OS, Macintosh System Software, Mac OS X, or Unix based systems. No other OS that quite lives up to RISC OS in ease of use and ease of writing applications for (though Amiga OS comes in a very close second place).
This is true to the point that every time I promise to attempt to use another OS (usually in response to hype about other systems being better, or other RISC OS users putting down RISC OS) I end up giving up on the other OS and sticking to RISC OS.
WIP : This document is a Work In Progress, and will go into details of the reasons I feel RISC OS is a better OS (including the fact that teaching those that have not used desktop computers before to use there first system is easiest accomplished with RISC OS).
Do not get me wrong there are other OS's I use from time to time, and one that I use quite a bit. I would never say I do not like an Operating System unless I had given it a good chance.
Amiga OS is very much a decent OS that I do use, nearly as much as RISC OS.
I also enjoy using the Classic Macintosh Operating System. This is one of the great systems for what it contributed to the world of computing from the point of view of resource management and clipping algorithm improvements for fast graphics.
Then there are other great OS's that did not get updated to handle more RAM, or the CPU's on which they run are not updated anymore. Many of these I still use (often in emulation). These include GEOS (8-bit for the 6502), GS/OS, SOS, ProDOS, CBM-DOS+KERNAL+MS-BASIC, Lunix, QDOS (680x0 OS) and clones, MacMINT, and MINIX 1.5 (68K).
Some of these are no longer maintained, though some are updated.
GS/OS is well maintained to this day, and has all of the advantages of the Macintosh Operating System plus some that are unique to GS/OS.
ProDOS is likely one of the best early generation command line single tasking Operating Systems around. ProDOS is much more than just a Disk and File OS, it also provides good support for many device types, and reasonable extras.
SOS is a very well thought out OS and the original implementation of what we know as the ProDOS File System.
GEOS shows how little space and memory is needed to implement a full Operating System including a Windowing System. GEOS has some limits, though for an Operating System that runs well in 64KB of RAM and extremely good with 128KB of RAM it is quite an accomplishment. Some of the modern clones and extensions bring GEOS to a level that is extraordinary.
CBMDOS+KERNAL+MS-BASIC (CBM internal OS is spelled KERNAL with the A) is a very simple though effective combination of operating systems working together. KERNAL is a full HW abstraction OS that is running on the main computer (Commodore 8-bit). MS-BASIC provides the user interface, along with some OS functionality (more with later versions). CBMDOS is the Operating System that runs on the disk drives, and understands the Disk and Files. You use KERNAL to send commands to CBMDOS and the two communicate over a serial bus (parallel in the PET), thus eliminating the need for the computers OS to know details about disks and files.
LUnix (Little Unix) and LNG (LUnix the Next Generation) is a good small Unix like OS that provides all the features of a real Unix (not this POSIX bloat, we are talking Unix as it was in the early through mid 1970s (when it ran on PDP-7 and PDP-11 computers with less than 30K Words of RAM). These are great little Operating Systems' that embody the Unix philosophy in the positive direction very well (unlike most modern POSIX like and Unix like Operating Systems').
QDOS was a very good set of core concepts, as far as the low level Operating System. Things like how it handled a lot of I/O tasks as separate tasks in its Preemptive Multitasking environment. Unfortunately there were issues with the builtin UI, as well as the original computers being very slow do to using an 8-bit bus version of the 68000 known as the 68008.
SMSQ/E is a QDOS clone, and the one I am most familiar with. This is mostly compatible with QDOS, though much improved in many ways. It also was ported to faster 680x0 computers, including the Atari STE (where I first used it). From this (and by way of this from QDOS) come many of the concept I put into task management on YASDOE (though not all). The SuperBASIC implementation is a good language, if lacking when comapared to BBC-BASIC V (though almost all BASIC's are lacking when compared to BBC-BASIC v).
MacMINT gives a crude bit of TOS and Unix on Macintosh computers.
MINIX 1.5 is one of the best Unix like Operating Systems for personal computers that use 16 or 32-bit CPU's. It is unfortunate that this branch of MINIX is no longer updated.
Fewer Lockups:
Even though RISC OS is a cooperative multitasking OS with limited memory protection, it is much less likely that a program running on RISC OS will lock up on you than it is on most other systems. This is likely largely do to the OS being cooperative multitasking, and thus giving programmers good incentive to do a good job at remaining responsive (and it is easy to do it correctly in RISC OS).
Think about how often you have a program lock up on your modern OS, regardless of what OS that may be. On some OS's this is truly terrible, as the program will lock up becoming a zombie, and depending on the nature of the task you may not be able to kill it.
On RISC OS it is extremely rare for an application to lock up. Applications that run in single tasking (thus stopping all others) are known to do so, so the user tends to know to quit other tasks, or expect them to freeze while single tasking though resume normal operation as soon as you return to the WIMP (single tasking applications are almost universally full screen). Multitasking applications just work, being extremely rare to see a lock up or application crash.
When using a modern Linux with the ROX Desktop Environment and equivalent applications to what I would use in RISC OS, the applications tend to go zombie multiple times per week, this does not happen with the RISC OS applications that do the same thing. I have tried many different applications in each category to eliminate the possibility of just being one bad program. The same goes for Win32 programs (though much more often than on Linux), be it on an MS-Windows system, Wine, or ReactOS (though ReactOS is better than the other two).
Even with Haiku OS or BeOS this is a notable issue, and more common than one would like. When I attempt to be productive on BeOS or Haiku OS programs go zombie about once to twice per week.
Though on RISC OS a zombie is nearly never seen. And on the once every few months occasion that you do see one take over when it is not supposed to, it is usually a UnixLib application ported from another OS.
Fewer System Crashes:
Again thanks to programmers taking the time to think, it is much more of a rare event for the OS to crash than it is on most other Operating Systems.
With BSD full system crashes are about 3 times per year with the workload I consider normal. On MINIX 3 this is about twice per year. On a Linux System this is about 8 times per year.
On the most stable Windows NT System I have yet used (Windows NT 4 SP3) the system crashes about twice per month or more (depending on specifics). On the current common Windows NT systems (Windows 10 and Windows 11) crashes can be expected about one to two times per week, and a bit more often with each update (assuming you have well behaved HW and drivers, more often if not). This is my experience. Windows NT is a trademark of MicroSoft, this site is not associated with MicroSoft in any way shape or form.
The only times I get a full system crash in RISC OS are either when running software that dereferences null pointers (a no no for any programmer) without having zero page protected or when I do something in programming that is a big no no. In either case it is still rare to bring down RISC OS even with these kinds of mistakes.
More Productive:
For this part there is another that did a much better job at explaining this than I can. Please see: Why I stay with RISC OS. By Paul Vigay
Easier to use:
Many whom are familiar with other modern Operating Systems and Windowing Systems complain about it being difficult to learn RISC OS. This is only because they are familiar with other Desktop OS's and Windowing Environments that are nearly identical to each other (Macintosh System Software, Amiga OS, Win32, most Linux/Unix desktop environments, BeOS, etc are near identical in use) and they are not accustomed to how easy RISC OS is. I can say this having taught people to use there first Desktop OS and Windowing Environment having to use a number of different options.
You take a group of young people that have never used a "Desktop" system and teach them to use there first Desktop System, if that system is RISC OS they quickly pick it up, in a way that allows for dynamic usage. If it is another System it is difficult to get them to pick it up in a dynamic usage way (this is regardless of the preference of the teacher, as it has been tested with teachers that are most accustom to Win32 as well). This is still an ongoing area, as many young people have only used touch interfaces like tablets and smart-phones. This goes to show what Desktop OS really is easy to use.
There is one other Operating System that is almost (though not quite) as easy to learn for a person that has no experience with any Desktop Operating System, though this one requires a bit of an investment in HW to run natively. This is Amiga OS (up through 3.1 (and add 3.2)). For a modern computer to run Amiga OS you can purchase a Vampire V4+ (based on the Apollo 68080 CPU with modern updated versions of the AGA chipset with extensions), or you can buy the OS and emulate the HW to run it. Though RISC OS is still a bit easier than even Amiga OS for complete Desktop OS new comers to pick up.
The User Interface
This is a huge topic, so just a few brief comments here.
Less Bloatware
Generally speaking RISC OS programs are many times less memory hungry, many times less CPU hungry, and take much less disk space to do the same thing as giant programs on other systems. This is with the RISC OS version being better at doing the task at hand.
##. When to Use Other Systems:
There are times that I use other Operating Systems. Generally this comes in two parts, one being that I enjoy Amiga (been using it longer than RISC OS), the other is when I do not have the needed software available for RISC OS.
For the case of software needed that I do not have on RISC OS; I will instead use another OS until I am able to get the appropriate software for RISC OS, or until I can write the needed software (if said software is simple enough to so do). Once I am able to do the same thing on RISC OS I use RISC OS for the given task.
Traditionally I have used Macintosh System Software for things that I can not do on RISC OS or Amiga OS. This being because the 680x0 CPU is a good CISC design, and Macintosh System Software is not too bad to work with.
It has reaches a point where needing another OS is very rare, as more of the software from the European and British side of the Atlantic Creek is available to us now. There are still some types of applications that only seem to exist in the USA, and unfortunately do not have a clear license of distribution (as we passed stuff around on disks at meets until about 10 years ago for RISC OS in the United States of America).
In the case of using Amiga: I use Amiga computers because I like Amiga OS and the computers it runs on. I also like doing things in Amiga OS. It is also the case that I will go to Amiga OS as the workspace for tings that I do not have the RISC OS software though do have the Amiga OS equivalent.
Scripting:
Unfortunately whoever designed the web interface for GitHub decided that they are going to use client side scripting. This eliminates the ability to use real web browser, having to use bloat browsers instead. Also many browsers today treat JS as a local application in many ways, including memory management, and many of the scripts used tend to be leaky.
There is very rarely a good reason to use JavaScript (AKA ECMA Script), and in the cases where it does have a use there is always the ability to accomplish the same task without using JS. This goes for all things, weather it being file upload/download/management on a remote system, Video Streaming, Audio Streaming, secure submission of data, file editing, etc, etc. All these things can be done in HTML without any client side scripts, especially now that video formats are part of the standard for embedded objects.
If a web page is enough of an application to need to be an application (and github is not such) running in a browse, it should not be a web page, it should be an application that can be run stand alone on the local computer. Be it a game, graphics program, conversion utility, whatever any full program does not belong in a web page (more on this somewhere else, this is a big issue today).
There is nothing wrong with using JavaScript in a site, though always provide a fallback for those of us that enjoy using the site and do not want to waste the memory, bandwidth, and CPU time that JS takes. Requiring JS is just another way of locking out users that are perfectly able to handle the protocols and encryption needed for all things on the web. Further there is almost never any value added by using JavaScript in any way, shape, or form, as almost all the things JS is used for can be accomplished without using JS. Also by using pure HTML without any client side scripting at all, you will save anywhere from a few milliWatt Minutes up to a few Watt hours for every single person that uses your site, and if you have a lot of users (like GitHub does) you could save more than a few MegaWatt Hours every month, thus having a huge positive impact on worldwide energy consumption.
Github other complaint:
Then there is this new method of having to bend over backwards and not use your password to use a command line Git client on github. This is wrong, it does not add any value, it does not add any security to the system, and it is another attempt to lock out users.
Result for me:
As such GitHub is becoming more of a tertiary for my usage, more likely I am to put files on a normal web site first. Though some stuff will make it here eventually.
Unfortunately I find that to fulfill a promise I made I am having to interact with GitHub a good amount in order to slowly write documentation in another GitHub Wiki for another project. Once the other projects documentation is complete, and an initial version of the code is on github it is likely that future versions will be way ahead of the GitHub version on other distribution avenues.