abstract: These files are not specific to rhocoin. They are a collection of notes on setting up operating systems and tools. Every time I mess around and encounter some grief, I add to this pile of notes, which has become inconveniently long and broken up into separate files.
For a gpt partition table, sixteen MiB fat32 partition with boot and efi flags set, one gigabyte linux swap, and the rest your ext4 root file system.
With an efi-gpt partition table, efi handles multiboot, so if you have windows, going to need a bigger boot-efi partition. (grub takes a bit over four MiB)
For an ms-dos (non efi) partition table, fivehundred and twelve MIB ext4 partition with the boot flag set, (linux uses 220 MiB) one gigabyte linux swap, and the rest your ext4 root file system.
In `gparted’ an msdos partition table for a linux system should look something like this
And a gpt partition table for a linux system should look something like this
See Linux desktop for desktop memory management (earlyoom), browser choices, coupling GUI applications to the Linux desktop, and Flatpak sandboxing.
See Virtual Box for setting up Ubuntu, Devuan, Debian, OpenWrt, and Windows 10 in VirtualBox, as well as virtual disk management.
See Cloud server for setting up an actual server, a VM pretending to be a cloud server, SSH setup, cloud server security, backing up a cloud server, your SSH client configuration, and Debian on the cloud.
/usr
/usr/bin- Non-essential command binaries (not needed in single user mode); for all users.
/usr/include- Standard include files grouped in subdirectories, for example
/usr/include/boost/usr/lib- Libraries for the binaries in /usr/bin and /usr/sbin.
/usr/lib<qual>- Alternate format libraries, e.g. /usr/lib32 for 32-bit libraries on a 64-bit machine (option)
/usr/local- Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin, lib, share.
/usr/sbin- Non-essential system binaries, e.g., daemons for various network-services. Blockchain daemon goes here.
/usr/share- Architecture-independent (shared) data. Blockchain goes in a subdirectory here.
/usr/src- Source code. Generally release versions of source code. Source code that the particular user is actively working on goes in the particular user’s
~/src/directory, not this directory.~/.<program>- Data maintained by and for specific programs for the particular user, for example in unix
~/.Bitcoinis the equivalent of%APPDATA%\Bitcoinin Windows.~/.config/<program>- Config data maintained by and for specific programs for the particular user, so that the users home directory does not get cluttered with a hundred
.<program>directories.~/.local/<program>- Files maintained by and for specific programs for the particular user.
~/src/- Source code that you, the particular user, are actively working on, the equivalent of
%HOMEPATH%\src\in Windows.
~/src/include- header files, so that they can be referenced in your source code by the expected header path, thus for example this directory will contain, by copying or hard linking, the
boostdirectory so that standard boost includes work.
See Cloud server for SSH setup, installing minimum standard software, and remote graphical access.
See Web servers for Apache virtual hosting, LEMP stack (nginx, MariaDB, PHP), SSL/DNSSEC with certbot, WordPress installation and migration, and logging with awstats.
See Email server for Postfix and Dovecot email server setup.
The cross platform open source gcc compiler produces the best object code, but is not debugger friendly. The cross platform CLang is debugger friendly, but this is not that useful unless you are using an ide designed for Clang. Visual Studio has the best debugger – but you are going to have to debug on windows.
In Clang and gcc, use valgrind.
In Visual Studio, enable the CRT debugger.
#ifdef _MSC_VER
#ifdef _DEBUG
// Testing for memory leaks under Microsoft Visual Studio
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#endif
#endifAt the start of program
#ifdef _MSC_VER
#ifdef _DEBUG
// Testing for memory leaks under Microsoft Visual Studio
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
#endif
#endifAt the end of program
#ifdef _MSC_VER
#ifdef _DEBUG
// Testing for memory leaks under Microsoft Visual Studio
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );
#endif
#endifHowever, this memory leak detection is incompatible with wxWidgets, which does its own memory leak detection.
And since you are going to spend a lot of time in the debugger, Windows Visual Studio recommended as the main line of development. But, for cross compilation, wxWidgets recommended.
Code::Blocks (wxSmith GUI developer) is one open source cross platform which may be out of date.
wxSQLite3 incorporates SQLite3 into wxWidgets, also provides ChaCha20 Poly1305 encryption. There is also a wrapper that wraps SQLite3 into modern (memory managed) C++.
wxSQLite3 is undergoing development right now, indicating that wxWidgets
and SQLite3 are undergoing development right now. wxSmith is dead
Tk is still live, but you get confusingly directed to the dead version.
This design pattern separates the UI program from the main program, which is thus more environment independent and easier to move between different operating systems.
The Model-view-controller design pattern makes sense with peers on the server, and clients on the end user’s computer. But I am not sure it makes sense in terms of where the power is. We want the power to be in the client, where the secrets are.
So, a common design pattern is to put as much of the code as possible into the daemon, and as little into the gui.
Now it makes sense that the Daemon would be assembling and checking large numbers of transactions, but the client has to be assembling and checking the end user’s transaction, so this model looks like massive code duplication.
If we follow the Model-View-Controller architecture then the Daemon provides the model, and, on command, provides the model view to a system running on the same hardware, the model view being a subset of the model that the view knows how to depict to the end user. The GUI is View and Command, a graphical program, which sends binary commands to the model.
Store the master secret and any valuable secrets in GUI, since wxWidgets provides a secret storing mechanism. But the daemon needs to be able to run on a headless server, so needs to store its own secrets – but these secrets will be generated by and known to the master wallet, which can initialize a new server to be identical to the first. Since the server can likely be accessed by lots of people, we will make its secrets lower value.
We also write an (intentionally hard to use) command line view and command line control, to act as prototypes for the graphical view and control, and test beds for test instrumentation.
CMake is the best cross platform build tool, but my experience is that it is too painful to use, is not genuinely cross platform, and that useful projects rely primarily on autotools to build on linux, and on Visual Studio to build on Windows.
And since I rely primarily on a pile of libraries that rely primarily on autotools on linux and Visual Studio on windows …
Cmake in theory provides a universal build that will build stuff on both Windows and linux, but when I tried using it, was a pain and created extravagantly fragile and complicated makefiles.
Libsodium does not support CMake, but rather uses autotools on linux like systems and visual studio project files on Windows systems.
wxWidgets in theory supports CMake, but I could not get it working, and most people use wxWidgets with autotools on linux like systems, and visual studio project files on Windows systems. Maybe they could not get it working either.
Far from being robustly environment agnostic and shielding you from the unique characteristics of each environment, CMake seems to require a whole lot of hand tuning to each particular build environment to do anything useful.
Install 7zip.
Install Notepad++.
Install MinGW using TDM-GCC, as the MinGW install is user hostile, and the Code::Blocks install of MinGW broken. Also, wxWidgets tells you to use the TDM environment.
Download Git from Git for Windows and install it. (This is the successor to msysgit, which has a walkthrough.) Select Notepad++ as the editor.
Note that in any command line environment where one can issue Git
commands, the commands git gui and git gui citool are available.
Install MinGW using TDM-GCC, as the MinGW install is user hostile, and the Code::Blocks install of MinGW broken.
Download your target project using Git.
Open a Windows PowerShell and navigate to the folder where you just put your target project.
Execute the following commands:
cd build
cmake .. -G "MinGW Makefiles"
mingw32-makeThere is no satisfactory android running under Oracle Virtual Box. However, Google supports development environments running under windows.
Trouble is, for android clients, you will want to develop primarily in JavaScript with a bit of Java.
JavaScript delivers the write once, run anywhere, promised by Java, and, unlike Java,delivers distributed computing. This, however, requires the entire java ecology, plus html and css. And I don’t know JavaScript. But more importantly, I don’t know the JavaScript ecology:
The JavaScript ecology is large and getting larger, as parodied by Hackernoon.
For an intro into JavaScript and the accompanying (large) ecology, telling you what small parts of the forest you actually need to get an app up: A study plan to cure JavaScript fatigue.
See Git for setting up Git repositories on the cloud, Git workflow, and sharing repositories (Git Daemon, Gitweb, Gitolite, Gitea, Phabricator, GitLab).
See Linux desktop for coupling GUI applications to the Linux desktop and Flatpak sandboxing.
See Tor for installing and configuring Tor services and the Tor browser.
See Censorship resistant internet for notes on Tox, Zeronet, Bitmessage, and Freenet.
See Network file system for setting up NFS server and client.
«example.com» gpg key 154588427F2709CD9D7146B01C99BB982002C39F
This work is licensed under the Creative Commons Attribution 4.0 International License.