29 March 2020

Remember Git passwords securely

Typing your password again and again when using git with remote repo is tiring.

Git will integrate with your OS-level password storage easily enough though.

Macs

I'm under the impression that on Macs, it just works.  It's built into git to interface with Mac's Keychain service.

Or else just install Git-Credential-Manager-for-Mac-and-Linux from Microsoft.  You'll need Homebrew, which is a great package manager for Macs for various development tools.  Then follow the instructions: it's super easy.

Windows

Super easy.  Just download and install the .exe for Git-Credential-Manager-for-Windows from Microsoft.

Linux

There's 3 possibilities:

use Git-Credential-Manager-for-Mac-and-Linux

You can install Git-Credential-Manager-for-Mac-and-Linux from Microsoft.  You'll need Linuxbrew, a package manager I've never heard of before today.  Then follow the instructions: it's looks easy.

But this is not my favorite option because:
  1. never heard of Linuxbrew
  2. MS Git-Credential-Manager sends telemetry to Microsoft.  Not much telemetry data, and I'm trusting of MS more or less, but if you're using Linux, I'm going to guess you might see "telemetry" and "MS" and wonder why it's needed for using Git.
  3. someone's tried it a year ago and it didn't work

use Libsecret (best option)
It's 3 lines of commands to run:

sudo apt-get install libsecret-1-0 libsecret-1-dev
sudo make --directory=/usr/share/doc/git/contrib/credential/libsecret
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

This saves your credentials encrypted in ~/.local/share/keyrings.

Yes, you're downloading and compiling it yourself as it's not built-in... in 2020. Crazy.  But is apparently still The Way to go with Ubuntu or Lubuntu 19.10.

use the built-in store (totally insecure and NOT encrypted)

Totally built-in.  Nothing to install.  One line to set up:

git config --global credential.helper store

It stores your passwords in PLAIN text in a file in your home directory.  Don't do this.  Anyone can read your password.  I can read your password.  So don't do this.

25 March 2020

One way to use SemVer for software versioning

Everyone has their own system for versioning in their software development process.

Semantic Versioning is very popular of course.  It basically takes the form of:

major.minor.patch-prerelease+build
  • Major for breaking changes.
  • Minor for backwards compatible feature additions.
  • Patch for bugfixes meant to be backwards compatible.
  • Pre-release tags for internal versioning, building up to a release.
  • Build for internal build numbers, useful if you build a lot.
There is a precedence order to SemVer numbers to essentially designate which version is "newer" in some sense.

Pre-release and Build tags do not participate in the precedence order.   So when specifying ranges of versions, those pre-release tags are kind of ignored in things like NPM contrary to precedence order as SemVer defines it --- reality is different than theory, right?

Pre-release tags are great for Designating development stages but when they are removed to do a non-pre-release release (e.g. a final release), it messes up the lexicographical ordering --- i.e. messes up the order in which they show up in my file browser. haha.

How I use SemVer

So I'm trying a SemVer compatible system that respects the 2nd and 3rd laws: "Don’t mess with math", and "Make friends with infinity.  In other words, don’t be afraid to increment".

The basic idea is: keep pre-releases to a patch level, release at the next patch level.

The rules are:
  1. Start at 0.1.0.
  2. Increment patch number to make a release
  3. Increment major, minor, or patch (whichever you're targeting for next) to make pre-releases
  4. Pre-releases are tagged a1, a2, ..., b1, b2, ..., rc1, rc2, etc.
  5. Use increasing build numbers if you need
  6. Use a "." then another build field if you must, like for adding a non-increasing alphanumeric build field (e.g. a SHA)

Example

So you'll get versions of WildApp like these, e.g.:
  • WildApp 0.1.0-a1
  • WildApp 0.1.0-a2
  • WildApp 0.1.0-b1
  • WildApp 0.1.0-b2
  • WildApp 0.1.0-b3
  • WildApp 0.1.0-rc1
  • WildApp 0.1.0-rc2
  • WildApp 0.1.1
  • WildApp 1.0.0-a1
  • WildApp 1.0.0-a2
  • WildApp 1.0.0-b1
  • WildApp 1.0.0-b2
  • WildApp 1.0.0-b3
  • WildApp 1.0.0-rc1
  • WildApp 1.0.0-rc2
  • WildApp 1.0.1
I'm going to give it a try at least.

29 February 2020

Productivity software I like to install after upgrading to Lubuntu 19.10

I installed Lubuntu 19.10 and copied over my old /home/user from my 19.04 system.

Now I need to reinstall some software, so it's good to revisit and update my old migration notes.


In Summary...

I like to:

add-apt-repository ppa:libreoffice/ppa

apt-get install restic chrony file-roller gedit xournal evince nomacs graphicsmagick ghostwriter emacs gimp gimp-plugin-registry gimp-gmic default-jdk gcc make ttf-mscorefonts-installer ruby libsecret-1-0 libsecret-1-dev

sudo make --directory=/usr/share/doc/git/contrib/credential/libsecret
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret


snap install code --classic
snap install aws-cli --classic

Note: ttf-mscorefonts-installer requires user interaction to install, so don't walk away from it overnight thinking everything will be done by morning.

Then install by hand Chrome, Netbeans, and LibreOffice dictionaries etc.

Oh, for chrony, I like to also have added to /etc/chrony/chrony.conf : server time.apple.com iburst because where I am it's hard to get to a time server except Apple's.

See more info about each below.

22 February 2020

LibreOffice's multiFormatSave extension is broken

multiFormatSave broken as GlobalScope.DialogLibraries.isLibraryLoaded(EXTENSION_NAME) not working

Not sure when this became an issue as it used to work. At some point LibreOffice must've updated to version 6.3.4.2 on Lubuntu 19.04 while I had MultiFormatSave 1.5.6 installed. Then it stopped working:

The error occurs on line 78 (or 76 if viewed in LO macro editor) in multiFormatSave.xba. Specifically GlobalScope.DialogLibraries.isLibraryLoaded(EXTENSION_NAME) throws a NoSuchElementException.

This problem occurs despite removing and re-adding the extension, with re-opening LO between each step.

I did figure out a work-around: open ~/.config/libreoffice/4/user/basic/dialog.xlc and ensure it's contents is:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE library:libraries PUBLIC "-//OpenOffice.org//DTD OfficeDocument 1.0//EN" "libraries.dtd">
<library:libraries xmlns:library="http://openoffice.org/2000/library" xmlns:xlink="http://www.w3.org/1999/xlink">
 <library:library library:name="multiFormatSave" xlink:href="$(USER)/uno_packages/cache/uno_packages/lu23853otd9xi.tmp_/multiFormatSave_v1-5-6.oxt/multiFormatSave/dialog.xlb/" xlink:type="simple" library:link="false"/>
</library:libraries>

The lu23853otd9xi.tmp_ must match where LO installed the multiFormatSave extension, of course.

Unfortunately, I'm not sure if that file existed before my bug hunting, or whether my debugging created that file since I created a Dialog in the LO macro editor as part of the bug hunt.

In any case, the key line xlink:href="$(USER)/uno_packages/cache/uno_packages/lu23853otd9xi.tmp_/multiFormatSave_v1-5-6.oxt/multiFormatSave/dialog.xlb/" seems to be the "active ingredient", letting LO know where to find the proper dialog.xlb file as it could've find it before.

18 October 2019

Why are these 3 open source licenses best?

I've already said that these 3 licenses are best for open source nowadays for me:
  1. Apache License 2.0 --- Apache-2.0 @ SPDX, ChooseALicense
  2. Mozilla Public License 2.0 --- MPL-2.0 @ SPDX, ChooseALicense
  3. GNU General Public License 3.0 or later --- GPL @ SPDX, ChooseALicense
But WHY??

The open source community has basically settled on 4 styles of sharing, and with it 4 genres of open source licenses.  The list above is my pick of what I think is best in each of the first 3 genres.  Let's talk about each one in turn:

1. Software developers are free to do whatever they want with my code in building their software.

These licenses are about the freedom of the developers of the software.

Look for MIT, BSD, Apache licenses, etc.

But I think Apache License 2.0 is the best because

2. Users are free to do whatever they want with my code and any modifications to my code in the software they received, even if they can't with the software's other proprietary code.

These licenses are all about the freedom of the end users who have the software, in a piecemeal fashion.

Look for MPL, EPL, LGPL licenses, etc.

But I think MPL 2.0 is best because
  • compared to MPL and EPL, the LGPL basically makes the distinction that static linking of code equals modifications to that code, but dynamic linking is not.  That just seems like a needless distinction for a license to make, and MPL and EPL doesn't make that distinction.  And I like static linking.
  • EPL 2.0 is basically a very new update to EPL 1.0 that makes the EPL even more complicated than it already was.  The main purpose was to (1) change the boundary of what counts as "my code" from a module based distinction to a file based distinction, which is what the community has standardized on, (2) make it more internationally usable, and (3) add in GPL compatibility as an opt-in.

    Unfortunately, GPL compatibility is opt-in and not default making it even more complicated when mixing EPL 2.0 with/without GPL secondary license, and EPL 1.0 code which was never GPL compatible.

    So if your community has settled on EPL (like many in Java or Clojure), then maybe sticking with what the community is using is easiest.  Otherwise, it's hard to make an informed use of the EPL as an individual, unless you've got lawyers on retainer... which is maybe why the EPL is very well regarded by businesses?
  • It is compatible with Apache 2.0.
MPL 2.0 on the other hand has GPL compatibility by default, unless opted-out of.  It's much older so it's better known and understood, still very well regarded, and used by large projects like Mozilla for Firefox, Adobe for Flex, LibreOffice, etc.  And it's relatively short and easy to understand, so MPL 2.0 it is! 


3. Users are free to do whatever they want with all of the code in the software they got from the software developers.

These licenses are all about the freedom of the end users who have the software, not about the developers'.

Look for GPL.

This is the classic "viral copyleft" thing, although talking about strong/viral copyleft is kind of more confusing than helpful (see Weak or Strong is Wrong) because, philosophical discussions aside, it's really just about what kind of code sharing you want to take place with your code you authored.

Having said that, if you incorporate MPL 2.0 or Apache 2.0 code into a GPL code base, the whole code base has to be distributed as GPL moving forward.


4. Users are free to do whatever they want with all of the code in the software they use from the software developers.

These licenses are all about the freedom of the end users using the software over a network.

Look for AGPL, SSPL, etc.

GPL had a SaaS loophole / ASP loophole:  what happens if the end users never got the software, because they only used it running in the "cloud" (i.e. on computers they don't own)?

AGPL is supposed to close that loophole so that if an organization modifies AGPL software, any end user using that AGPL software in the cloud must be able to do anything they want with its' code.

More recently, AGPL was found to have a no-modification loophole: what happens if an organization just uses and doesn't modify AGPL software?  The AGPL doesn't compel code sharing in that case!

So companies could containerize AGPL software, build an API around it to use it internally, etc., and as long as they never modify the actual AGPL software, then they could use without ever sharing any code.

Some patched that loophole with the Commons Clause.  MongoDB took a different path by creating the SSPL.

I don't know enough about this genre of sharing to suggest any license as best.  Reading SSPL Was Not Commons Clause, it's clear this is still cutting edge licensing legal stuff.  If you're looking for a license for this genre of sharing for any serious work, you'd probably have your own lawyers anyway.

And I'm definitely not a lawyer, so let's just agree to take this as entertainment.  :)