A year ago I took a look at what password manager options there were out there for RISC OS, that article covered Passman from Kevin Wells as well as Qupzilla’s built-in password manager. I didn’t however cover !Passwords by John Peachey, who’s recently updated it to work on newer hardware such as the Raspberry Pi and Titanium – so without further ado, let’s take a look…
Passwords can be downloaded from John’s website, it requires the WBModule to run, which can also be downloaded from the same page.
Installation is as easy as you might expect for a small application like this, you unpack !Passwords from its zip file and drop it to where you want on your system.
When run, it opens up an icon on the icon bar, where you can click into the main password database or open up a configuration menu that allows you to hide the main window on display or to enable/disable the application’s ability to open up the password prompt to view your passwords when the application runs (by default you need to click on the icon bar menu to get a prompt to login to the password database and view/amend your passwords).
Adding, removing and amending passwords in the database once you’ve entered your password to login is as straightforward as you’d expect. There’s an option to name your password (i.e. Facebook login) and an option to add the username for that particular site/system, an optional comment and of course the password itself.
You’re given a default password to login to Passwords to begin with. You can change that password by clicking into the main passwords screen, middle-clicking and selecting ‘Change’. The password isn’t stored in plain-text within !Passwords or anywhere else on the system which is good.
The passwords themselves are stored in an encrypted format, although I can’t for the life of me identify what form of encryption has been used, they don’t appear to be hashed (MD5, SHA1 etc.) so I’m going to hazard a guess that they’re being compressed in some form or another. I wouldn’t bank on it being uncrackable but it gets the job done.
That’s all there is to tell really. Passwords is a nice, small little password manager that does exactly what it says on the tin, it stores your passwords safely.
Back in February 2017, Timothy Baldwin announced on the RISC OS Open forums that he was working on an experimental port of RISC OS to Linux. Fast forward a year and a half later and the project’s progress has been impressive.
This port allows you to run RISC OS directly from within Linux, without the need for an emulator such as RPCEmu or Qemu.
The main advantage of running RISC OS directly means that, unlike virtual machines such as RPCEmu, there is no restriction on what RISC OS programs can do to the Linux environment, beyond that provided by Linux itself.
So the interaction between RISC OS and the host system will be similar to that of the Linux Subsystem that is implemented in modern versions of Windows. This allows for RISC OS to be able to interact with the host directly, rather than having to treat is as a separate machine on a LAN like you would with an emulator.
RISC OS Open Limited’s Desktop Development Enviroment (DDE) is required to build RISC OS. So this is required if you want to build this Linux port yourself. The DDE is proprietary software that can be bought from RISC OS Open directly.
This port can be built in a similar fashion to the traditional method as documented on ROOL’s website, it is not necessary to run InstallTools as the relevant files will be accessed from the DDE without copying. However this will not build the SDL front-end which connects RISC OS to the Linux graphics system, without it RISC OS is limited to a text only interface.
The port is by no means complete at the moment, but it does allow for a usable RISC OS desktop with working networking and domain resolution.
What this symbolises to me is – in a similar vein to how the emergence of the Raspberry Pi and similar boards a few years ago completely changed the way people use RISC OS for the better – this could open up much more opportunities for RISC OS later on down the line as the project progresses.
Since June 2002 I have been offering software from my website, http://www.wra1th.plus.com/, to the RISC OS community, namely RiscLua, a port of Lua. New versions have come and gone, http://www.wra1th.plus.com/lua/version.html, to keep up with developments in Lua, and because I have often changed my mind about the best way to present the software for the user’s convenience.
This article is not about Lua but about packaging; it just happens that RiscLua is the only template that I have for discussing the subject. There are many possibilities; I am by no means sure that any of the ones that I have chosen in the past are optimal. In the end it is the user who must be the arbiter of that. So I certainly welcome feedback, and not just from users of RiscLua.
So what does the package contain? There are five main ingredients:
- Executables – in this case lua, the interpreter, and luac, a bytecode compiler and disassembler.
- System variables – defining a filetype run-action, so that programs can be run by doubleclicking the icon of a file – LUA_INIT for prelude code, run before any program – LUA_PATH to tell the require function where to find libraries of Lua code, and LUA_CPATH to do the same job for dynamic linking libraries (a feature not available before 2015, and probably of little relevance in the RISC OS context).
- Utilities – for running in a Taskwindow, for displaying intermediate bytecode, and for linking in libraries and interpreter to produce standalone executables.
- An HTML/CSS manual for the current version of Lua, with an extension for the non-standard, and in particular the RISC OS, parts of RiscLua.
- Example programs and tutorial material.
At one point, in 2003, I implemented the interpreter as a relocatable module and used the Resource Filing System for the Obey files setting up the system variables. However I gave up this option when I realized that it was easier to keep other tasks insulated from errors if I implemented it as an application, even in the case of interpreting wimp-tasks. Besides, RISC OS has the convenient system of !Boot files for setting up system variables, defining filetypes and their run-actions and RMEnsuring the existence of resources. It would be daft not to take advantage of this.
To begin with I called the application !Lua. Later, as the versions multiplied and the chances grew that different versions would interfere with each other, I started to use the version number as part of the name, at least for the binary files. So the latest version is named !rlua7. Then there is the question of where you put the other stuff: the documentation, the utilities and the examples? Inside the application, or outside? These choices are important for ease of updating, both for me and the user.
You might not want to download the whole package just for some trivial correction to the manual. It has been my habit to upload zip files to my website with FTP, so do I have one big zip file or lots of smaller ones? Writing tutorial material is, for me anyhow, a gradual process of many small steps. I suddenly get interested in this or that topic and fire off an addition to the tutorial material or to the examples.
A particularly thorny aspect for me has been the question of software libraries. Luckily Lua has by tradition taken the road of minimalism – provide as little extra possible and leave it to the user to write their own libraries. Provide possibilities not solutions. Lua is often compared unfavorably with Python on this score. But libraries bring into play the question of authority. In a small user-base each user may prefer to knit their own jersey rather than get one off the peg.
So I have been in two minds about providing libraries, not wishing to set them in concrete. This is particularly true of libraries for writing wimp-tasks or for the toolbox where I have had second thoughts about the best approach quite frequently. Fortunately it is very easy for the user to set up their own libraries, because the require function discovers where to find them by using the strings package.path and package.cpath which the user can modify at the start of her program. The system variables LUA_PATH and LUA_CPATH are only used to initialise these strings.
The way that RiscLua is packaged is actually irrelevant for most uses, which only need to know where the Lua interpreter is and what its commandline arguments should be. A vital consideration, however, is whether the platform on which you use RISC OS has VFP or not. Until 2015 RISC OS only handled floating point calculations in software. In consequence it was never a good choice for intensive number-crunching. But things are different now and so RiscLua has to come in two packages, one for use with VFP and the other for use with the older ARM chips without it.