Exhaustive list of SPDX (Software Package Data Exchange) licenses: https://spdx.org/licenses/
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
As configured in my dotfiles.
start new:
tmux
start new with session name:
#!/usr/bin/env python3 | |
''' | |
A script to recursively compare two directories (including file size and file hash changes) | |
Usage: python3 compare_dirs.py DIR1 DIR2 | |
''' | |
import os, sys, hashlib, unicodedata | |
COMPARE_FILES = True # should file sizes be compared if their names are the same? |
These 'notes' were primarily intended for my own consumption but since there have been surprisingly many comments to it over the years I wanted to do some updates and clarifications. Thanks for all comments.
These instructions will require you to have connection to internet from your pi, WiFi, Ethernet or by some other means like a 3G USB dongle or something.
#!/bin/bash | |
# | |
# ~/.local/bin/btswitch | |
# | |
# wait a second this is too fast for udev | |
sleep 1 | |
btdev="$(pactl list sinks|grep Name|grep 'bluez.*.a2dp.sink'|sed 's/Name: //'|sed 's/\s//')" | |
if [ -n "$btdev" ]; then |
#!/usr/bin/env bash | |
# fresh-chrome | |
# | |
# Use this script on OS X to launch a new instance of Google Chrome | |
# with its own empty cache, cookies, and user configuration. | |
# | |
# The first time you run this script, it will launch a new Google | |
# Chrome instance with a permanent user-data directory, which you can | |
# customize below. Perform any initial setup you want to keep on every |
Mozilla is doing it again: detering the addon developers who once made it „big“ (last time was when they forced them from XUL to their new „stable API“ for „long-time compatibility“ – which then proved to change as often as the XUL did before). So again, many of them are „jumping boat“, as they a) have no time to migrate to the new WebExtensions, b) WebExtensions don't offer the APIs required to perform the tasks needed by their addon, c) WebExtensions not even being ready yet (with just a couple of weeks left to the deadline, the API is still changing and far from being completed).
I won't start a rant on „if I wanted a browser that looks like Chrome (Aurora with FF29), behaves like Chrome (only signed addons via a central store), and now feels like Chrome, I'd use Chrome“. Of course that's true, and having to re-configure ~80% of the browser of course lets me consider changing to a different browser (certainly not Chrome, though). But first let's look where we stand (comments, additions and suggestions wel
function requestPermission() { | |
return new Promise(function(resolve, reject) { | |
const permissionResult = Notification.requestPermission(function(result) { | |
// Handling deprecated version with callback. | |
resolve(result); | |
}); | |
if (permissionResult) { | |
permissionResult.then(resolve, reject); | |
} |