SD version 1.0 released

[D M]

As an end of the year gift to the multivalue community, Don M and Mark B are happy to announce version 1.0 of SD, the multivalue string database. This release contains various bug fixes and new features. We have moved the install and delete scripts into their own repository.  The install script now handles everything needed to install SD on Fedora and Debian/Ubuntu based distros.  In addition, much better error trapping has been added.

Mark has fixed several outstanding bugs in the core SD code base. Included are fixes for the termio.h problem and consistency in OS level file naming . He also has added many new functions for embedded python.  PROC is now supported and TAPE and ACCOUNT.RESTORE functionality is available as an optional feature, and there is better handling of Messages.  The repositories are:

https://github.com/stringdatabase/sdb64
https://github.com/stringdatabase/sd-scripts

If you are a developer, clone or download the sdb64 repository.

You can download the install and delete scripts from the GitHub sd-scripts repository or download a zip file containing the two scripts at:

https://u.pcloud.link/publink/show?code=XZsk7x5ZpwWPPooCElf8waiNp03rJQGV61yV

To install SD, just download the zip file, extract the scripts, make the scripts executable if needed and then run installsd.sh.  The installer will handle installation of required packages, downloading and compiling of source, installation of SD into the proper directories and deletion of the temporary files.

[Steven Davies-Morris]

Thank you Don & Mark.  I will definitely grab this and import an
application system and some data accounts (POS for dry cleaning).   I'll
give it a whirl on Ubuntu.

> directories and deletion of the temporary files. --
> You received this message because you are subscribed to
> the "Pick and MultiValue Databases" group.
> To post, email to: mvd...@googlegroups.com
> To unsubscribe, email to: mvdbms+un...@googlegroups.com
> For more options, visit http://groups.google.com/group/mvdbms
> ---
> You received this message because you are subscribed to the Google
> Groups "Pick and MultiValue Databases" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mvdbms+un...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/mvdbms/78a77bb8-b329-441f-86c6-ced918e654b6n%40googlegroups.com
> <https://groups.google.com/d/msgid/mvdbms/78a77bb8-b329-441f-86c6-ced918e654b6n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
SDM a 21st century schizoid man in SoCal
Systems Theory website www.systemstheory.net
Through The Looking Glass radio show at www.deepnuggets.com
Email "The Cleaner System" at cleaner...@yahoo.com

[Dick Eshelman]

Thank you Don and Mark!  I will install it on Ubuntu right away.

[Peter Gonzalez]

Thank  you. 

[D M]

The install script for SD has been updated to support Arch Linux based distributions.  The updated share link on pcloud is:

https://u.pcloud.link/publink/show?code=XZMXnx5Z7XTaY4dBt2QgXUuky0GWwhAd88gV

Or  you can download directly from the github repository mentioned in the first message in this thread.

[D M]

I have been testing the install of SD on a variety of Linux distros using a Virtualbox VM running under Linux.  Each instance has 8 Gig of memory assigned and 6 virtual CPUs.  So far I have found that Debian without a GUI does not reliably start SD at boot.  Linux Mint 22.2 with GUI installs correctly and SD is reliable.  Ubuntu 25.10 has problems installing the OS.  Ubuntu 24.04 server installs correctly and SD is reliable.  Manjaro 26.0 does not  complete the install of the OS.  Cachy OS without a GUI installs and SD is reliable.  Fedora Server installs without issues and SD is reliable.

[D M]

The install script now supports installation to openSuse 16 and openSuse Tumbleweed.

[Steven Martin Trimble]

great work!!

thanks

CDMI

Steven Trimble

(501) 772-3450 cell/text

cdm...@gmail.com

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/e152219f-b6c4-47db-a632-2c4243a41596n%40googlegroups.com.

[D M]

There are reasons why each user may decide that either ScarletDME or SD is the best for their situation:

ScarletDME is basically QM 2.6.6 with a few features such as encription missing because of never being ported from commercial openQM.

So, if compatibility with the features found in openQM 2.6.6 is your primary desire, then ScarletDME will likely be your choice.

SD is designed to provide new features, better security, easier installation and some enhancements.  However, it also removes some features that are available in ScarletDME.

Removed features include:

Pick compatibility.  SD focuses on the  Pr1me Information features elusively.

Form and menu design features.

Telnet access.  Remote access is through ssh.

Commands that were never supported in the open source version of QM.

Some additional changes:

1) SD is installed to /usr/local/sdsys.

2) Install and remove  scripts  are  provided with support for current Debian, Fedora, openSuse and Arch based dstributions.  Users have reported successful installations on WSL and Raspberry Pi.

3) Accounts are grouped under /home/sd and can be declared as "user" (personal access) or "group" (shared" access).

4) Sudo and systemd are required for installation.

5) SD accounts with admin rights are tied to Linux accounts that have sudo access.  So Linux users without admin capabilities are also blocked from being administrators of SD.

6) The Linux Micro editor is supported through the MICRO Tcl command.  It can be used to edit SD Basic, Dictionary and VOC entries.  Also available are the ED and SED editors.

7) Embedded Python  is supported.

8) There are no "binary bits" in the Github repository. Everything can be audited.

9) While online ScarletDME/QM 2.6.6 documentation is available at https://scarl.cdmiweb.com/ and can be useful for SD users, we are also in the process of developing our own documentation site at https://stringdatabase.com.

10) All system C and Basic code has been reviewed for bugs.  Several have been found and fixed.

11) Based on user feedback; In version 1.0 PROC support has been added back and the TAPE/RESTORE feature is available as an option during installation.

12) Remote access using the remote API through sdclilib.so on remote Linux clients is supported.

13) Replacement encryption and decryption commands are included.

14) SD is based on the foundation of the wonderful work of those involved with ScarletDM and openQM.  However we have totally removed the ScarletDME and openQM branding (and retained the appropriate copyright notices) as we have made so many changes that we do not want the developers of ScarletDME or openQM to be held responsible.  Some may find SD to be an improvement and some may find it lacking.  It is a different vision of what a multi value database can be.

15) SD code is released under GPL 3 and LGPL 3 as appropriate.

Note: we were able to remove all binary bits as Mark B developed a Basic compiler written in Python that removed the need for compiled Basic code during the installation.

If you are interested in helping out with development you can use git to clone the github.com/stringdatabase/sdb64 repository.  If you just want to install SD you can clone the github.com/stringdatabase/sd-scripts repository which contains scripts to install and remove SD.  When using the install script, the SD repository is downloaded into a temporary directory and then deleted at the end of the install.  This is great for testing or for a production installation.  Your development repository should not be stored as sdb64 under your home directory as ~/sdb64 is the temporary directory used during the install and will be deleted at the end of the install.  We may  change the install script in  the future to remove this limitation. 

[D M]

Forgot to mention, SD is 64 bit only.  ScarletDME is available as either 32 or 64 bit.  SD would not exist if Gene B had not done the initial port of ScarletDME to 64 bit.  Thanks Gene.

[D M]

When writing the last post I realized that if a developer was using ~/sdb64 as their development directory, then it would be overwritten during an install.  The install script has been modified to use ~/.sdb64tmp as the temporary directory during install and then delete it at the end of the install.  This change has been made as of 1/8/2026.

On Thursday, December 18, 2025 at 3:50:01 PM UTC-8 D M wrote:

[Steven Martin Trimble]

yes thanks!

CDMI

Steven Trimble

(501) 772-3450 cell/text

cdm...@gmail.com

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/fb528c1c-fa4a-4c98-8433-09664eca6871n%40googlegroups.com.

[Gene Buckle]

On 1/7/2026 6:23 PM, D M wrote:
> Forgot to mention, SD is 64 bit only.  ScarletDME is available as
> either 32 or 64 bit.  SD would not exist if Gene B had not done the
> initial port of ScarletDME to 64 bit.  Thanks Gene.
>

Happy to do it.  I just wish I had more time to work on things. The good
news is that the 64 bit version is now the "main" version folks get when
cloning the repository.

FYI, the encryption stuff was *stripped* from the OpenQM code prior to
the open source release.  I've got 60+ pages of notes on stuff that has
to get either added back or added as new in order to bring ScarletDME up
to feature parity with OpenQM 4.

SD helps keep things moving forward, and that's very much appreciated.

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.

I'm not crazy, I'm plausibly off-nominal!

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
https://github.com/geneb/ScarletDME - Get it _today_!

[Jay LaBonte]

Is there an email or group to submit suggestion for enhancements to ScarletDME or SD? If not I would be happy to set something up on the MultiValue.World site.



Regards,
Jay LaBonte
President & CEO

P: 561-705-3688 |:: jlab...@paradigm-systems.us
2234 North Federal Hwy, Suite 1056, Boca Raton, FL 33481
www.paradigm-systems.us

--
You received this message because you are subscribed to the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/1bcc222f-25b1-4310-b7b0-557b07bc57b3%40deltasoft.com.

[Wol]

On 08/01/2026 02:17, D M wrote:
> 4) Sudo and systemd are required for installation.

Sorry. I think sudo is a *massive* mistake. Systemd, well that is
standard amongst pretty much all distros now. But sudo? It's an
*application*, not something that's guaranteed to be installed, or
configured and working.

That's why it was removed from ScarletDME.

And really, why do you need it IN THE INSTALL SCRIPT? ScarletDME can run
most of the make file as an ordinary user, so it lets you run it as an
ordinary user. That's basic security.

The bits that need root, you can either su, which I do, or sudo if
that's what you do. Basic security - if you don't need root - don't use it!

Cheers,
Wol

[Wol]

On 08/01/2026 05:43, D M wrote:
> When writing the last post I realized that if a developer was using ~/
> sdb64 as their development directory, then it would be overwritten
> during an install.  The install script has been modified to use
> ~/.sdb64tmp as the temporary directory during install and then delete it
> at the end of the install.  This change has been made as of 1/8/2026.

Something I jumped on when working on the install - if you've truly
copied INFORMATION you won't have this problem but ...

INFORMATION doesn't have a central ACCOUNTS directory, so you can't
overwrite and corrupt it. Pretty much every other MV database I know of
HAS copied that central database from original Pick. What strategies do
you have to avoid trashing any central config in that ACCOUNTS
directory, if you do have it?

Cheers,
Wol

[D M]

The install program does not overwrite the running SD directory. The way it was originally written, it might remove a development directory if the development directory had been cloned to ~/sdb64 - that is why it now creates a temporary directory during installation and then deletes it when it is done.

SD installs to /usr/local/sdsys.  The only change from QM was to install it under /usr/local rather than directly under /usr. There is an ACCOUNTS file, just as QM has.  It contains information about accounts, with some additions compared to QM.

There are some changes from QM.  If I remember right, you can gain administrative rights by logging to QMSYS from within QM. You can also directly login in to other accounts.  This is not true in SD.  Only people who are members of the sudo group  can act as administrators.  Normally the admin user enters  "sudo sd" to have administrative access.  If you are not a member of sudo, you can not do any administrative tasks such as create or delete accounts. When the user logs in using "sudo sd" their account is SDSYS and they have just as much access to SD as they do to the underlying OS.  The rational is that if a user is trusted at the OS level, they are also trusted within SD.

So SD itself does not use sudo, but the user uses sudo to gain administrative access.

Accounts can be either USER or GROUP accounts. OS level users are tightly linked to the equivalent SD account.  So if the administrator creates a new SD user named "JIM", an OS user named "jim" is also created.  When "jim" logs into linux and enters the command "sd", his current directory becomes /home/sd/user_accounts/jim. Assuming the user has TCL access, If he exits to the OS using "!" or "SH", he will be in the /home/sd/user_accounts/jim directory.  One  goal is to tie SD more tightly to the underlying OS.  Lynx, less and micro are currently used within SD as appropriate.  Eventually the idea is that all necessary OS management will happen from within SD.  Right now, when you create a new user in SD, it also creates the matching user in the OS.  We are looking to increase the this linkage.

The user can not log to other USER accounts from within SD. However, administrators have access to all accounts. Users can however log to any GROUP accounts that they have been given access to.   

Our goal was to make SD more secure than in QM.  We have done that by getting rid of accounts spread all over the file system as in QM.  You can not create a new account simply by logging into SD from a directory. Only the SD administrator(s) can create, update and delete accounts and give access to GROUP accounts. By default all the home SD directories are created either under /home/sd/user_accounts or /home/sd/group_accounts.  Appropriate OS level directory and file permissions are assigned on account creation. If an OS user does not have a matching SD account, entering the "sd" command will result in a message that the user is not allowed  to access SD. We also got rid of telnet access. Remote access is only allowed using ssh. 

On Thursday, December 18, 2025 at 3:50:01 PM UTC-8 D M wrote: